Re: [PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support

[Rob Herring]

On Wed, Jan 06, 2016 at 04:19:53PM +0530, Kishon Vijay Abraham I wrote:
> Perform syscon configurations to get x2 mode to working in DRA74x and
> DRA72x. Also add a new compatible string to dfferentiate
> DRA72x and DRA74x, since b1c0 mask is different for both these platforms.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++-
>  drivers/pci/host/pci-dra7xx.c|   81 
> +-
>  2 files changed, 86 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
> b/Documentation/devicetree/bindings/pci/ti-pci.txt
> index 60e2516..0b10e84 100644
> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> @@ -1,7 +1,9 @@
>  TI PCI Controllers
>  
>  PCIe Designware Controller
> - - compatible: Should be "ti,dra7-pcie""
> + - compatible: "ti,dra7-pcie" is deprecated
> +Should be "ti,dra746-pcie" for DRA74x
> +Should be "ti,dra726-pcie" for DRA72x
>   - reg : Two register ranges as listed in the reg-names property
>   - reg-names : The first entry must be "ti-conf" for the TI specific 
> registers
>  The second entry must be "rc-dbics" for the designware pcie
> @@ -14,6 +16,10 @@ PCIe Designware Controller
>  where  is the instance number of the pcie from the HW spec.
>   - interrupts : Two interrupt entries must be specified. The first one is for
>   main interrupt line and the second for MSI interrupt line.
> + - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
> module and the
> +   register offset to specify 1 lane or 2 lane.
> + - syscon-lane-sel : phandle/offset pair. Phandle to the system control 
> module and the
> +   register offset to specify lane selection.

These should have a ti prefix.

>   - #address-cells,
> #size-cells,
> #interrupt-cells,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] phy: ti-pipe3: configure usb3 phy to be used as pcie phy

[Rob Herring]

On Wed, Jan 06, 2016 at 04:29:08PM +0530, Kishon Vijay Abraham I wrote:
> DRA72 uses USB3 PHY for the 2nd lane of PCIE. The configuration
> required to make USB3 PHY used for the 2nd lane of PCIe is done
> here.
> 
> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
>  drivers/phy/phy-ti-pipe3.c   |   30 
> +-
>  2 files changed, 31 insertions(+), 1 deletion(-)

Acked-by: Rob Herring <r...@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Rob Herring]

On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon  wrote:
> On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>>
>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>>> Hi,
>>>
>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon :
>>>
 On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> +rtc {
> +compatible = "ti,palmas-rtc";
> +interrupt-parent = <>;
> +interrupts = <8 IRQ_TYPE_NONE>;
 IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
 it had none, there'd be no interrupt, right?
>>> Well, it just translates IRQ_TYPE_NONE through
>>>
>>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>>
>>> to
>>>
>>> interrupts = <8 0>;
>>>
>>> which is given as an example in
>>>
>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>>
>>> Since I don't know anything about the rtc driver beyond the bindings
>>> documentation I assume it is correct...
>>> I have added Laxman Dewangan because he introduced this interrupts =
>>> <8 0>;
>>>
>>
>> As this is for palmas interrupt controller, it does not use the second
>> field for interrupt from RTC.
>> So there is no really any polarity. It can be set to 0.
>>
>> The second argument will be used for GPIOs mainly. However, support need
>> to be added on GPIO driver for rising/falling configuration.
>
>
> Device tree represents the hardware - not to reflect how the driver
> works. if the driver is wrong, fix it. the interrupt polarity needs to
> be described in DT. based on palmas like designs, you should probably
> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
> the SoC as it reaches Secondary interrupt handlers(SIH) registers.

If the trigger type is not programmable, then not setting the trigger
type in the DT is fine. Internal connections are often not documented.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] wlcore/wl12xx: spi: add device tree support

[Rob Herring]

On Wed, Dec 23, 2015 at 10:35:43AM +0200, Uri Mashiach wrote:
> Add DT support for the wl1271 SPI WiFi.
> 
> Add documentation file for the wl1271 SPI WiFi.
> 
> Signed-off-by: Uri Mashiach <uri.mashi...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>
> ---
>  .../bindings/net/wireless/ti,wlcore,spi.txt| 35 +++++++

For the binding:

Acked-by: Rob Herring <r...@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi

[Rob Herring]

On Wed, Dec 30, 2015 at 4:29 AM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Tue, Dec 29, 2015 at 9:54 PM, Rob Herring <r...@kernel.org> wrote:
>> On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
>>> Some displays have a reset input and/or need a regulator to function
>>> properly. Allow to specify them for panel-dpi devices.
>>>
>>> Signed-off-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>
>>> ---
>>>  Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
>>> b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> index 216c894d4f99..b52ac52757df 100644
>>> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> @@ -7,6 +7,8 @@ Required properties:
>>>  Optional properties:
>>>  - label: a symbolic name for the panel
>>>  - enable-gpios: panel enable gpio
>>> +- reset-gpios: GPIO to control the RESET pin
>>
>> The problem with this in a generic binding is what if the panel has
>> ordering requirements like enable gpio has to be inactive when reset
>> is deasserted?
>>
>>> +- vcc-supply: phandle of regulator that will be used to enable power to 
>>> the display
>>
>> What if there are 2 supplies?
>
> So it should be "vcc-supplies". Most properties containing phandles use plural
> naming, even if Linux supports a single phandle only (e.g. "power-domains").
> You also may want to add an optional "vcc-supply-names" property to
> differentiate.

True, but the regulator binding is an exception and we don't do that
with it. The prefix is the name and other supplies are not going to be
called Vcc.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] wlcore/wl12xx: spi: add device tree support

[Rob Herring]

On Mon, Dec 28, 2015 at 02:02:18PM +0200, Uri Mashiach wrote:
> Add DT support for the wl1271 SPI WiFi.
> 
> Add documentation file for the wl1271 SPI WiFi.
> 
> Signed-off-by: Uri Mashiach <uri.mashi...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>
> ---
> v1 -> v2: update interrupt documentation.
>   replace interrupts and interrupt-parent with interrupts-extended.

Why? interrupts-extended is really just for cases with 2 interrupt 
parents.

> IRQ parameters retrieved from spi_device instead of DT.
> remove redundant #ifdef CONFIG_OF
> v2 -> v3: Add MODULE_DEVICE_TABLE.
>   Remove #ifdef CONFIG_OF.
> Make the Kconfig symbol to depend on OF.
> Replace irqd_get_trigger_type() with irq_get_trigger_type().
> 
>  .../bindings/net/wireless/ti,wlcore,spi.txt| 34 

In any case:

Acked-by: Rob Herring <r...@kernel.org>

>  drivers/net/wireless/ti/wlcore/Kconfig |  2 +-
>  drivers/net/wireless/ti/wlcore/spi.c   | 47 
> --
>  3 files changed, 78 insertions(+), 5 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ti-st: use device handles and add device tree binding

[Rob Herring]

On Wed, Dec 23, 2015 at 11:38:29AM +, Reizer, Eyal wrote:
> - Add support for getting the platform data which includes the uart
>   used and gpio pin used for enable from device tree.
> 
> - Fix the implementation for using device handle for the uart and
>   gpiod for the enable pin, instead of device name (as string) used
>   for the uart and pio number which are both bad practice.
> 
> Signed-off-by: Eyal Reizer 
> ---
>  Documentation/devicetree/bindings/misc/ti-st.txt |   42 ++
>  arch/arm/mach-omap2/pdata-quirks.c   |   16 ++-
>  drivers/misc/ti-st/st_kim.c  |  159 
> --
>  drivers/misc/ti-st/st_ll.c   |   16 ++-
>  include/linux/ti_wilink_st.h |   13 +-

I'd suggest you look at commit c0bd1b9e58959c5 (Revert "ti-st: add 
device tree support") first.

>  5 files changed, 190 insertions(+), 56 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/misc/ti-st.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/ti-st.txt 
> b/Documentation/devicetree/bindings/misc/ti-st.txt
> new file mode 100644
> index 000..4490da6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/ti-st.txt
> @@ -0,0 +1,42 @@
> +TI Wilink 6/7/8 (wl12xx/wl18xx) Shared transport driver

Bindings shouldn't be describing drivers...

> +
> +TI’s Wireless Connectivity chips support Bluetooth (BT), WiFi, and GPS
> +technology cores in a single die.
> +
> +Such a multi-core combo chip will be interfaced to the application processor
> +using a single physical port (like UART).
> +
> +Shared Transport (ST) software enables BT and GPS protocols or software
> +components to interact with their respective cores over single physical port.
> +ST uses logical channels, over physical transport, to communicate with
> +individual cores.
> +
> +Logical channels 1, 2, 3, and 4 are used for BT packets, channel 8 for FM,
> +channel 9 for GPS and channels 30, 31, 32, and 33 are used for Chip Power
> +Management (PM).

All this is irrelevant for a binding. 

> +
> +This node provides properties for passing parameters to the ti shared
> +transport driver.
> +
> +Required properties:
> + - compatible: should be the following:
> +* "kim" - ti-st parameters

Who is kim? Certainly not a description of a h/w block.

> +
> +Optional properties:
> + - nshutdown-gpios : specifies attributes for gpio ping used for enabling
> + the bluetooth,gps and FM sub systems
> + - serial-device : the phandle for the phisical uart used for interacting
> + with the wilink device

There have been multiple discussions on serial slave devices recently. 
I'm not going to accept any device binding without a common uart slave 
device binding first.

> + - flow_cntrl : Indicates if uart flow control is used
> + - flow_cntrl : uart baud rate in BPS

Typo here, but these should be part of a common serial slave binding.

Don't use '_' in property names.

> +
> +Example:
> +
> +kim {
> + compatible = "kim";
> + nshutdown-gpios = < 21 GPIO_ACTIVE_HIGH>;
> + serial-device = <>;
> + flow_cntrl = <1>;
> + flow_cntrl = <300>;
> +};
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dt-bindings: bus: ti-gpmc: Add AAD timings properties

[Rob Herring]

On Mon, Dec 28, 2015 at 02:39:21PM +0100, Neil Armstrong wrote:
> In order to support advanced AAD timings, add these properties to the DT
> GPMC bindings.
> 
> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
> ---
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt | 5 +
>  1 file changed, 5 insertions(+)

Acked-by: Rob Herring <r...@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] drivers: net: cpsw: fix error messages when using phy-handle DT property

[Rob Herring]

On Tue, Dec 22, 2015 at 07:36:33PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivs...@allworx.com>
> 
> The phy-handle, phy_id, and fixed-link properties are mutually exclusive,
> and only one need be specified. However if phy-handle was specified, an
> error message would complain about the lack of phy_id or fixed-link.
> 
> Also, if phy-handle was specified and the subsequent of_phy_connect()
> failed, the error message still referenced slaved->data->phy_id, which
> would be empty. Instead, use the name of the device_node as a useful
> identifier.
> 
> Fixes: 9e42f715264f ("drivers: net: cpsw: add phy-handle parsing")
> Signed-off-by: David Rivshin <drivs...@allworx.com>
> ---
> This would require some adjustments to backport to 4.3-stable due to
> other changes in this area. Let me know if you want a version of this
> against v4.3.3.
> 
>  Documentation/devicetree/bindings/net/cpsw.txt |  4 ++--

For the binding:

Acked-by: Rob Herring <r...@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi

[Rob Herring]

On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
> Some displays have a reset input and/or need a regulator to function
> properly. Allow to specify them for panel-dpi devices.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
> b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> index 216c894d4f99..b52ac52757df 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> @@ -7,6 +7,8 @@ Required properties:
>  Optional properties:
>  - label: a symbolic name for the panel
>  - enable-gpios: panel enable gpio
> +- reset-gpios: GPIO to control the RESET pin

The problem with this in a generic binding is what if the panel has 
ordering requirements like enable gpio has to be inactive when reset 
is deasserted?

> +- vcc-supply: phandle of regulator that will be used to enable power to the 
> display

What if there are 2 supplies?

While there are limits to what can be described here, I'm okay with 
allowing these, so:

Acked-by: Rob Herring <r...@kernel.org>

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Rob Herring]

On Tue, Dec 29, 2015 at 3:26 PM, Paul Kocialkowski <cont...@paulk.fr> wrote:
> Le mardi 29 décembre 2015 à 14:02 -0600, Rob Herring a écrit :
>> On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
>> > LP872x regulators are made active via the EN pin, which might be hooked to 
>> > a
>> > GPIO. This adds support for driving the GPIO high when the driver is in 
>> > use.
>> >
>> > Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
>> > ---
>> >  .../devicetree/bindings/regulator/lp872x.txt   |  1 +
>> >  drivers/regulator/lp872x.c | 33 
>> > --
>> >  include/linux/regulator/lp872x.h   |  2 ++
>> >  3 files changed, 33 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt 
>> > b/Documentation/devicetree/bindings/regulator/lp872x.txt
>> > index 7818318..0559c25 100644
>> > --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
>> > +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
>> > @@ -28,6 +28,7 @@ Optional properties:
>> >- ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x 
>> > devices.
>> >- ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
>> >- ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
>> > +  - ti,enable-gpio: GPIO specifier for EN pin control of LP872x devices.
>>
>> Should be "-gpios" instead of "-gpio".
>
> Care to comment why? There is only one GPIO that can be used here, since
> there is only one single EN pin. I thought this matched what is done
> already with "ti,dvs-gpio".

To be consistent. We use "clocks" and "interrupts" always whether one
or more for example.

-gpio is documented as deprecated now.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Rob Herring]

On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> LP872x regulators are made active via the EN pin, which might be hooked to a
> GPIO. This adds support for driving the GPIO high when the driver is in use.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  .../devicetree/bindings/regulator/lp872x.txt   |  1 +
>  drivers/regulator/lp872x.c | 33 
> --
>  include/linux/regulator/lp872x.h   |  2 ++
>  3 files changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt 
> b/Documentation/devicetree/bindings/regulator/lp872x.txt
> index 7818318..0559c25 100644
> --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
> +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
> @@ -28,6 +28,7 @@ Optional properties:
>- ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x 
> devices.
>- ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
>- ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
> +  - ti,enable-gpio: GPIO specifier for EN pin control of LP872x devices.

Should be "-gpios" instead of "-gpio".

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

[Rob Herring]

On Sun, Dec 20, 2015 at 6:07 AM, Kishon Vijay Abraham I <kis...@ti.com> wrote:
> Hi Rob,
>
> On Sunday 20 December 2015 09:09 AM, Rob Herring wrote:
>> On Tue, Dec 15, 2015 at 02:46:08PM +0530, Kishon Vijay Abraham I wrote:
>>> Deprecate using phy-omap-control driver to power on/off the PHY,
>>> and use *syscon* framework to do the same. This handles
>>> powering on/off the PHY for the USB2 PHYs used in various TI SoCs.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>>> ---
>>>  Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
>>>  drivers/phy/phy-omap-usb2.c  |   94 
>>> ++
>>>  include/linux/phy/omap_usb.h |   23 ++
>>>  3 files changed, 107 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
>>> b/Documentation/devicetree/bindings/phy/ti-phy.txt
>>> index 49e5b0c..a3b3945 100644
>>> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
>>> @@ -31,6 +31,8 @@ OMAP USB2 PHY
>>>
>>>  Required properties:
>>>   - compatible: Should be "ti,omap-usb2"
>>> +   Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
>>> +   in DRA7x
>>
>> The 2nd instance is different somehow?
>
> yeah, the bit fields are slightly different.

Okay,

Acked-by: Rob Herring <r...@kernel.org>

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 6/9] phy: ti-pipe3: use *syscon* framework API to power on/off the PHY

[Rob Herring]

On Tue, Dec 15, 2015 at 02:46:05PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to power on/off the PHY and
> use *syscon* framework to do the same.
> 
> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |   10 ++-
>  drivers/phy/phy-ti-pipe3.c   |   90 
> ++
>  2 files changed, 85 insertions(+), 15 deletions(-)

For the binding:

Acked-by: Rob Herring <r...@kernel.org>

One comment on the driver though.

[...]

> --- a/drivers/phy/phy-ti-pipe3.c
> +++ b/drivers/phy/phy-ti-pipe3.c

[...]

> @@ -144,18 +155,53 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3 
> *phy);
>  
>  static int ti_pipe3_power_off(struct phy *x)
>  {
> + u32 val;
> + int ret;
>   struct ti_pipe3 *phy = phy_get_drvdata(x);
>  
> - omap_control_phy_power(phy->control_dev, 0);
> + if (phy->phy_power_syscon) {

Writing this as:

if (!phy->phy_power_syscon) {
...
return 0;
}

//regmap code


will make it simpler to remove the deprecated code later.


> + val = PIPE3_PHY_TX_RX_POWEROFF <<
> + PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
> +
> + ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
> +  PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
> + if (ret < 0)
> + return ret;
> + } else {
> + omap_control_phy_power(phy->control_dev, 0);
> + }
>  
>   return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 7/9] phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY

[Rob Herring]

On Tue, Dec 15, 2015 at 02:46:06PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to set PCS value of the PHY
> and start using *syscon* API to do the same.
> 
> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
> Acked-by: Roger Quadros <rog...@ti.com>
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
>  drivers/phy/phy-ti-pipe3.c   |   34 
> +-
>  2 files changed, 35 insertions(+), 1 deletion(-)

Acked-by: Rob Herring <r...@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

[Rob Herring]

On Tue, Dec 15, 2015 at 02:46:08PM +0530, Kishon Vijay Abraham I wrote:
> Deprecate using phy-omap-control driver to power on/off the PHY,
> and use *syscon* framework to do the same. This handles
> powering on/off the PHY for the USB2 PHYs used in various TI SoCs.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
>  drivers/phy/phy-omap-usb2.c  |   94 
> ++
>  include/linux/phy/omap_usb.h |   23 ++
>  3 files changed, 107 insertions(+), 18 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
> b/Documentation/devicetree/bindings/phy/ti-phy.txt
> index 49e5b0c..a3b3945 100644
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
> @@ -31,6 +31,8 @@ OMAP USB2 PHY
>  
>  Required properties:
>   - compatible: Should be "ti,omap-usb2"
> +Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
> +in DRA7x

The 2nd instance is different somehow?

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] ARM: dts: cm-t335: add support for SBC-T335

[Rob Herring]

On Sun, Dec 13, 2015 at 10:55:36AM +0200, Uri Mashiach wrote:
> Add basic support for the SBC-T335.
> 
> CompuLab SBC-T335 is a single baseboard computer.
> The SBC-T335 is based on the Texas Instruments Cortex-A8 Sitara AM3354
> SoC.
> 
> Signed-off-by: Uri Mashiach <uri.mashi...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  Documentation/devicetree/bindings/arm/omap/omap.txt |  3 +++
>  arch/arm/boot/dts/Makefile  |  1 +
>  arch/arm/boot/dts/am335x-sbc-t335.dts   | 16 
>  3 files changed, 20 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am335x-sbc-t335.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 2154f97..358e87e 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -141,6 +141,9 @@ Boards:
>  - AM335X CM-T335 : System On Module, built around the Sitara AM3352/4
>compatible = "compulab,cm-t335", "ti,am33xx"
>  
> +- AM335X SBC-T335 : single board computer, built around the Sitara AM3352/4
> +  compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx"
> +
>  - OMAP5 EVM : Evaluation Module
>compatible = "ti,omap5-evm", "ti,omap5"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 15411bc..d82ea97 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -466,6 +466,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
>   am335x-lxm.dtb \
>   am335x-nano.dtb \
>   am335x-pepper.dtb \
> + am335x-sbc-t335.dtb \
>   am335x-sl50.dtb \
>   am335x-wega-rdk.dtb
>  dtb-$(CONFIG_ARCH_OMAP4) += \
> diff --git a/arch/arm/boot/dts/am335x-sbc-t335.dts 
> b/arch/arm/boot/dts/am335x-sbc-t335.dts
> new file mode 100644
> index 000..9e98445
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-sbc-t335.dts
> @@ -0,0 +1,16 @@
> +/*
> + * am335x-sbc-t335.dts - Device Tree file for Compulab SBC-T335
> + *
> + * Copyright (C) 2014 - 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am335x-cm-t335.dts"
> +
> +/ {
> + model = "CompuLab CM-T335 on SB-T335";
> + compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx";
> +};
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Rob Herring]

On Fri, Dec 11, 2015 at 09:39:59AM +0530, Vignesh R wrote:
> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> update the binding documents for the controller to document this change.
> 
> Signed-off-by: Vignesh R <vigne...@ti.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> 
> v5: use syscon to access scm register.
> 
>  Documentation/devicetree/bindings/spi/ti_qspi.txt | 17 +
>  arch/arm/boot/dts/dra7.dtsi   |  6 --
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> index 601a360531a5..809c3f334316 100644
> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> @@ -15,6 +15,10 @@ Recommended properties:
>  - spi-max-frequency: Definition as per
>   Documentation/devicetree/bindings/spi/spi-bus.txt
>  
> +Optional properties:
> +- syscon-chipselects: Handle to system control region contains QSPI
> +   chipselect register and offset of that register.
> +
>  Example:
>  
>  qspi: qspi@4b30 {
> @@ -26,3 +30,16 @@ qspi: qspi@4b30 {
>   spi-max-frequency = <2500>;
>   ti,hwmods = "qspi";
>  };
> +
> +For dra7xx:
> +qspi: qspi@4b30 {
> + compatible = "ti,dra7xxx-qspi";
> + reg = <0x4b30 0x100>,
> +   <0x5c00 0x400>,
> + reg-names = "qspi_base", "qspi_mmap";
> + syscon-chipselects = <_conf 0x558>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + spi-max-frequency = <4800>;
> + ti,hwmods = "qspi";
> +};
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index fe99231cbde5..be91c7781c07 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1153,8 +1153,10 @@
>  
>   qspi: qspi@4b30 {
>   compatible = "ti,dra7xxx-qspi";
> - reg = <0x4b30 0x100>;
> - reg-names = "qspi_base";
> + reg = <0x4b30 0x100>,
> +   <0x5c00 0x400>;
> + reg-names = "qspi_base", "qspi_mmap";
> + syscon-chipselects = <_conf 0x558>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>   ti,hwmods = "qspi";
> -- 
> 2.6.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for 4.4 2/2] dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type

[Rob Herring]

On Wed, Dec 09, 2015 at 10:18:11AM +0200, Peter Ujfalusi wrote:
> This change makes the DT file to be easier to read since the reserved slots
> array does not need the '/bits/ 16' to be specified, which might confuse
> some people.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>

This too should have info on why you are breaking compatibility.

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  Documentation/devicetree/bindings/dma/ti-edma.txt |  5 ++--
>  drivers/dma/edma.c| 31 
> ++-
>  2 files changed, 27 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> index ae8b8f1d6e69..079b42a81d7c 100644
> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -56,9 +56,8 @@ edma: edma@4900 {
>  
>   /* Channel 20 and 21 is allocated for memcpy */
>   ti,edma-memcpy-channels = <20 21>;
> - /* The following PaRAM slots are reserved: 35-45 and 100-110 */
> - ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
> -/bits/ 16 <100 10>;
> + /* The following PaRAM slots are reserved: 35-44 and 100-109 */
> + ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
>  };
>  
>  edma_tptc0: tptc@4980 {
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 89fc17f3a6ff..a0f217349c07 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -2015,31 +2015,50 @@ static struct edma_soc_info 
> *edma_setup_info_from_dt(struct device *dev,
>   );
>   if (prop) {
>   const char pname[] = "ti,edma-reserved-slot-ranges";
> + u32 (*tmp)[2];
>   s16 (*rsv_slots)[2];
> - size_t nelm = sz / sizeof(*rsv_slots);
> + size_t nelm = sz / sizeof(*tmp);
>   struct edma_rsv_info *rsv_info;
> + int i;
>  
>   if (!nelm)
>   return info;
>  
> + tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
> + if (!tmp)
> + return ERR_PTR(-ENOMEM);
> +
>   rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
> - if (!rsv_info)
> + if (!rsv_info) {
> + kfree(tmp);
>   return ERR_PTR(-ENOMEM);
> + }
>  
>   rsv_slots = devm_kcalloc(dev, nelm + 1, sizeof(*rsv_slots),
>GFP_KERNEL);
> - if (!rsv_slots)
> + if (!rsv_slots) {
> + kfree(tmp);
>   return ERR_PTR(-ENOMEM);
> + }
>  
> - ret = of_property_read_u16_array(dev->of_node, pname,
> -  (u16 *)rsv_slots, nelm * 2);
> - if (ret)
> + ret = of_property_read_u32_array(dev->of_node, pname,
> +  (u32 *)tmp, nelm * 2);
> + if (ret) {
> + kfree(tmp);
>   return ERR_PTR(ret);
> + }
>  
> + for (i = 0; i < nelm; i++) {
> + rsv_slots[i][0] = tmp[i][0];
> + rsv_slots[i][1] = tmp[i][1];
> + }
>   rsv_slots[nelm][0] = -1;
>   rsv_slots[nelm][1] = -1;
> +
>   info->rsv = rsv_info;
>   info->rsv->rsv_slots = (const s16 (*)[2])rsv_slots;
> +
> + kfree(tmp);
>   }
>  
>   return info;
> -- 
> 2.6.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for 4.4 1/2] dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type

[Rob Herring]

On Wed, Dec 09, 2015 at 10:18:10AM +0200, Peter Ujfalusi wrote:
> This change makes the DT file to be easier to read since the memcpy
> channels array does not need the '/bits/ 16' to be specified, which might
> confuse some people.

Why? I don't see the point of this change and plus you are breaking 
compatibility with the change. There was little reason to do 16-bit 
values to start with, but that's now the ABI.
 
Rob

> Signed-off-by: Peter Ujfalusi 
> ---
>  Documentation/devicetree/bindings/dma/ti-edma.txt |  5 ++---
>  drivers/dma/edma.c| 22 ++
>  include/linux/platform_data/edma.h|  2 +-
>  3 files changed, 13 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> index d3d0a4fb1c73..ae8b8f1d6e69 100644
> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -22,8 +22,7 @@ Required properties:
>  Optional properties:
>  - ti,hwmods: Name of the hwmods associated to the eDMA CC
>  - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, 
> iow
> - these channels will be SW triggered channels. The list must
> - contain 16 bits numbers, see example.
> + these channels will be SW triggered channels. See example.
>  - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>   the driver, they are allocated to be used by for example the
>   DSP. See example.
> @@ -56,7 +55,7 @@ edma: edma@4900 {
>   ti,tptcs = <_tptc0 7>, <_tptc1 7>, <_tptc2 0>;
>  
>   /* Channel 20 and 21 is allocated for memcpy */
> - ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> + ti,edma-memcpy-channels = <20 21>;
>   /* The following PaRAM slots are reserved: 35-45 and 100-110 */
>   ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
>  /bits/ 16 <100 10>;
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 2af8f32bba0b..89fc17f3a6ff 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -1752,16 +1752,14 @@ static enum dma_status edma_tx_status(struct dma_chan 
> *chan,
>   return ret;
>  }
>  
> -static bool edma_is_memcpy_channel(int ch_num, u16 *memcpy_channels)
> +static bool edma_is_memcpy_channel(int ch_num, s32 *memcpy_channels)
>  {
> - s16 *memcpy_ch = memcpy_channels;
> -
>   if (!memcpy_channels)
>   return false;
> - while (*memcpy_ch != -1) {
> - if (*memcpy_ch == ch_num)
> + while (*memcpy_channels != -1) {
> + if (*memcpy_channels == ch_num)
>   return true;
> - memcpy_ch++;
> + memcpy_channels++;
>   }
>   return false;
>  }
> @@ -1775,7 +1773,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool 
> legacy_mode)
>  {
>   struct dma_device *s_ddev = >dma_slave;
>   struct dma_device *m_ddev = NULL;
> - s16 *memcpy_channels = ecc->info->memcpy_channels;
> + s32 *memcpy_channels = ecc->info->memcpy_channels;
>   int i, j;
>  
>   dma_cap_zero(s_ddev->cap_mask);
> @@ -1996,16 +1994,16 @@ static struct edma_soc_info 
> *edma_setup_info_from_dt(struct device *dev,
>   prop = of_find_property(dev->of_node, "ti,edma-memcpy-channels", );
>   if (prop) {
>   const char pname[] = "ti,edma-memcpy-channels";
> - size_t nelm = sz / sizeof(s16);
> - s16 *memcpy_ch;
> + size_t nelm = sz / sizeof(s32);
> + s32 *memcpy_ch;
>  
> - memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s16),
> + memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s32),
>GFP_KERNEL);
>   if (!memcpy_ch)
>   return ERR_PTR(-ENOMEM);
>  
> - ret = of_property_read_u16_array(dev->of_node, pname,
> -  (u16 *)memcpy_ch, nelm);
> + ret = of_property_read_u32_array(dev->of_node, pname,
> +  (u32 *)memcpy_ch, nelm);
>   if (ret)
>   return ERR_PTR(ret);
>  
> diff --git a/include/linux/platform_data/edma.h 
> b/include/linux/platform_data/edma.h
> index 105700e62ea1..0a533f94438f 100644
> --- a/include/linux/platform_data/edma.h
> +++ b/include/linux/platform_data/edma.h
> @@ -76,7 +76,7 @@ struct edma_soc_info {
>   struct edma_rsv_info*rsv;
>  
>   /* List of channels allocated for memcpy, terminated with -1 */
> - s16 *memcpy_channels;
> + s32 *memcpy_channels;
>  
>   s8  (*queue_priority_mapping)[2];
>   const s16   (*xbar_chans)[2];
> -- 
> 2.6.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH for 4.4 1/2] dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type

[Rob Herring]

On Wed, Dec 09, 2015 at 02:02:00PM -0600, Rob Herring wrote:
> On Wed, Dec 09, 2015 at 10:18:10AM +0200, Peter Ujfalusi wrote:
> > This change makes the DT file to be easier to read since the memcpy
> > channels array does not need the '/bits/ 16' to be specified, which might
> > confuse some people.
> 
> Why? I don't see the point of this change and plus you are breaking 
> compatibility with the change. There was little reason to do 16-bit 
> values to start with, but that's now the ABI.

Okay, I now see the explanation in cover letter. That should be part of 
this commit message.

Acked-by: Rob Herring <r...@kernel.org>

>  
> Rob
> 
> > Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> > ---
> >  Documentation/devicetree/bindings/dma/ti-edma.txt |  5 ++---
> >  drivers/dma/edma.c| 22 
> > ++
> >  include/linux/platform_data/edma.h|  2 +-
> >  3 files changed, 13 insertions(+), 16 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
> > b/Documentation/devicetree/bindings/dma/ti-edma.txt
> > index d3d0a4fb1c73..ae8b8f1d6e69 100644
> > --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> > +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> > @@ -22,8 +22,7 @@ Required properties:
> >  Optional properties:
> >  - ti,hwmods:   Name of the hwmods associated to the eDMA CC
> >  - ti,edma-memcpy-channels: List of channels allocated to be used for 
> > memcpy, iow
> > -   these channels will be SW triggered channels. The list must
> > -   contain 16 bits numbers, see example.
> > +   these channels will be SW triggered channels. See example.
> >  - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used 
> > by
> > the driver, they are allocated to be used by for example the
> > DSP. See example.
> > @@ -56,7 +55,7 @@ edma: edma@4900 {
> > ti,tptcs = <_tptc0 7>, <_tptc1 7>, <_tptc2 0>;
> >  
> > /* Channel 20 and 21 is allocated for memcpy */
> > -   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> > +   ti,edma-memcpy-channels = <20 21>;
> > /* The following PaRAM slots are reserved: 35-45 and 100-110 */
> > ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
> >/bits/ 16 <100 10>;
> > diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> > index 2af8f32bba0b..89fc17f3a6ff 100644
> > --- a/drivers/dma/edma.c
> > +++ b/drivers/dma/edma.c
> > @@ -1752,16 +1752,14 @@ static enum dma_status edma_tx_status(struct 
> > dma_chan *chan,
> > return ret;
> >  }
> >  
> > -static bool edma_is_memcpy_channel(int ch_num, u16 *memcpy_channels)
> > +static bool edma_is_memcpy_channel(int ch_num, s32 *memcpy_channels)
> >  {
> > -   s16 *memcpy_ch = memcpy_channels;
> > -
> > if (!memcpy_channels)
> > return false;
> > -   while (*memcpy_ch != -1) {
> > -   if (*memcpy_ch == ch_num)
> > +   while (*memcpy_channels != -1) {
> > +   if (*memcpy_channels == ch_num)
> > return true;
> > -   memcpy_ch++;
> > +   memcpy_channels++;
> > }
> > return false;
> >  }
> > @@ -1775,7 +1773,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool 
> > legacy_mode)
> >  {
> > struct dma_device *s_ddev = >dma_slave;
> > struct dma_device *m_ddev = NULL;
> > -   s16 *memcpy_channels = ecc->info->memcpy_channels;
> > +   s32 *memcpy_channels = ecc->info->memcpy_channels;
> > int i, j;
> >  
> > dma_cap_zero(s_ddev->cap_mask);
> > @@ -1996,16 +1994,16 @@ static struct edma_soc_info 
> > *edma_setup_info_from_dt(struct device *dev,
> > prop = of_find_property(dev->of_node, "ti,edma-memcpy-channels", );
> > if (prop) {
> > const char pname[] = "ti,edma-memcpy-channels";
> > -   size_t nelm = sz / sizeof(s16);
> > -   s16 *memcpy_ch;
> > +   size_t nelm = sz / sizeof(s32);
> > +   s32 *memcpy_ch;
> >  
> > -   memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s16),
> > +   memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s32),
> >  GFP_KERNEL);
> > if (!memcpy_ch)
> > return ERR_PTR(-ENOMEM);
> >  
> > -   ret = of_property_rea

Re: [PATCH V2 12/14] ARM: dts: sb-som: introduce SB-SOM baseboard

[Rob Herring]

On Tue, Dec 01, 2015 at 03:55:07PM +0200, Nikita Kiryanov wrote:
> CompuLab SB-SOM baseboard is a carrier board for multiple arm-based SoMs.
> It currently supports (with minor adjustments to assembly) CM-T43, CM-T54,
> and CM-QS600 modules. It is a building block in the SBC-T43 single board
> computer, which consists of cm-t43 on top of sb-som-t43.
> 
> Signed-off-by: Nikita Kiryanov <nik...@compulab.co.il>
> Cc: Tony Lindgren <t...@atomide.com>
> Cc: Benoit Cousson <bcous...@baylibre.com>
> Cc: Rob Herring <r...@kernel.org>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: Pawel Moll <pawel.m...@arm.com>
> Cc: Igor Grinberg <grinb...@compulab.co.il>
> Cc: Dmitry Lifshitz <lifsh...@compulab.co.il>
> Cc: Ian Campbell <ijc+devicet...@hellion.org.uk>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Changes in V2:
>   - Renamed file startek,startek-kd050c to startek,startek-kd050c.txt.
>   - s/QS-600/CM-QS600 in file compulab-boards.txt
> 
>  .../devicetree/bindings/arm/compulab-boards.txt|  5 +++
>  .../display/panel/startek,startek-kd050c.txt   |  4 +++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  arch/arm/boot/dts/compulab-sb-som.dtsi | 42 
> ++
>  4 files changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt
>  create mode 100644 arch/arm/boot/dts/compulab-sb-som.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/compulab-boards.txt 
> b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> new file mode 100644
> index 000..71172d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> @@ -0,0 +1,5 @@
> +CompuLab SB-SOM is a multi-module baseboard capable of carrying CM-T43, 
> CM-T54,
> +and CM-QS600 modules with minor modifications to the SB-SOM assembly.
> +
> +Required root node properties:
> +- compatible = should be "compulab,sb-som"
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt 
> b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt
> new file mode 100644
> index 000..70cd8d1
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt
> @@ -0,0 +1,4 @@
> +Startek Electronic Technology Co. KD050C 5.0" WVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "startek,startek-kd050c"
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 55df1d4..409b134 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -218,6 +218,7 @@ sony  Sony Corporation
>  spansion Spansion Inc.
>  sprd Spreadtrum Communications Inc.
>  st   STMicroelectronics
> +startek  Startek
>  ste  ST-Ericsson
>  stericsson   ST-Ericsson
>  synology Synology, Inc.
> diff --git a/arch/arm/boot/dts/compulab-sb-som.dtsi 
> b/arch/arm/boot/dts/compulab-sb-som.dtsi
> new file mode 100644
> index 000..402a143
> --- /dev/null
> +++ b/arch/arm/boot/dts/compulab-sb-som.dtsi
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/ {
> + model = "CompuLab SB-SOM";
> + compatible = "compulab,sb-som";
> +
> + vsb_3v3: fixedregulator-v3_3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsb_3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + enable-active-high;
> + };
> +
> + lcd0: display {
> + compatible = "startek,startek-kd050c", "panel-dpi";
> + label = "lcd";
> +
> + panel-timing {
> + clock-frequency = <3300>;
> + hactive = <800>;
> + vactive = <480>;
> + hfront-porch = <40>;
> + hback-porch = <40>;
> + hsync-len = <43>;
> + vback-porch = <29>;
>

Re: [PATCH V2 11/19] ARM: dts: am57xx: sbc-am57x: add basic board support

[Rob Herring]

On Tue, Dec 01, 2015 at 08:03:13PM +0200, Dmitry Lifshitz wrote:
> SBC-AM57x is a single board computer designed for industrial and
> embedded applications. It is based on the Texas Instruments Sitara AM57x
> system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x
> computer-on-module providing most of the functions, and SB-SOM-AM57x
> carrier board providing additional peripheral functions and connectors.
> 
> https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/
> 
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
> 
> Add basic board support, including UART3, used as a serial console.
> 
> Signed-off-by: Dmitry Lifshitz <lifsh...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> 
>   v2:
> 
>* No fuctional changes
>* Reformat subject
> 
>  .../devicetree/bindings/arm/omap/omap.txt  |  3 ++
>  arch/arm/boot/dts/Makefile |  1 +
>  arch/arm/boot/dts/am57xx-sbc-am57x.dts | 36 
> ++
>  3 files changed, 40 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index dd53c90..42cdad1 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -159,6 +159,9 @@ Boards:
>  - AM57XX CL-SOM-AM57x
>compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7"
>  
> +- AM57XX SBC-AM57x
> +  compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728", 
> "ti,dra742", "ti,dra74", "ti,dra7"
> +
>  - DRA742 EVM:  Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 803a020..4c73ab9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -479,6 +479,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
>  dtb-$(CONFIG_SOC_DRA7XX) += \
>   am57xx-beagle-x15.dtb \
>   am57xx-cl-som-am57x.dtb \
> + am57xx-sbc-am57x.dtb \
>   dra7-evm.dtb \
>   dra72-evm.dtb
>  dtb-$(CONFIG_ARCH_ORION5X) += \
> diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
> b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> new file mode 100644
> index 000..804ad72
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> @@ -0,0 +1,36 @@
> +/*
> + * Support for CompuLab SBC-AM57x single board computer
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz <lifsh...@compulab.co.il>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +#include "am57xx-cl-som-am57x.dts"
> +#include "compulab-sb-som.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
> + compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", 
> "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
> +};
> +
> +_pmx_core {
> + uart3_pins_default: uart3_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2)   
> /* uart2_ctsn.uart3_rxd */
> + DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)   
> /* uart2_rtsn.uart3_txd */
> + >;
> + };
> +};
> +
> + {
> + status = "okay";
> + interrupts-extended = <_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> +   <_pmx_core 0x3f8>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> +};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 01/19] ARM: dts: am57xx: cl-som-am57x: add basic module support

[Rob Herring]

On Tue, Dec 01, 2015 at 08:03:03PM +0200, Dmitry Lifshitz wrote:
> Add support for CompuLab CM-SOM-AM57X board.
> 
> CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
> TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.
> 
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
> 
> Add basic DT support for standalone module (without a carrier board):
> 
> * Memory configuration
> * Heartbeat led
> * I2C1 and I2C4
> * PMIC
> * SATA
> 
> Signed-off-by: Dmitry Lifshitz <lifsh...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  v3:
>  
>* Move PMIC to I2C4
>* Reformat subject
>  
>  v2: 
> 
>* Fixed voltages (for OPP_HIGH) for VDD_GPU, VDD_IVA, VDD_DSPEVE
>* Added comments for VDDA_1V8_PHYA/B
>* Add "regulator-always-on" property for ldousb_reg 
> 
>  .../devicetree/bindings/arm/omap/omap.txt  |   3 +
>  arch/arm/boot/dts/Makefile |   3 +-
>  arch/arm/boot/dts/am57xx-cl-som-am57x.dts  | 274 
> +
>  3 files changed, 279 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index da84372..dd53c90 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -156,6 +156,9 @@ Boards:
>  - AM437x SK EVM: AM437x StarterKit Evaluation Module
>compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
>  
> +- AM57XX CL-SOM-AM57x
> +  compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7"
> +
>  - DRA742 EVM:  Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5492a24..803a020 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -477,8 +477,9 @@ dtb-$(CONFIG_SOC_OMAP5) += \
>   omap5-sbc-t54.dtb \
>   omap5-uevm.dtb
>  dtb-$(CONFIG_SOC_DRA7XX) += \
> - dra7-evm.dtb \
>   am57xx-beagle-x15.dtb \
> + am57xx-cl-som-am57x.dtb \
> + dra7-evm.dtb \
>   dra72-evm.dtb
>  dtb-$(CONFIG_ARCH_ORION5X) += \
>   orion5x-lacie-d2-network.dtb \
> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
> b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> new file mode 100644
> index 000..087d62e
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> @@ -0,0 +1,274 @@
> +/*
> + * Support for CompuLab CL-SOM-AM57x System-on-Module
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz <lifsh...@compulab.co.il>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "dra74x.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x";
> + compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB - minimal 
> configuration */
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> +
> + led@0 {
> + label = "cl-som-am57x:green";
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> + };
> +};
> +
> +_pmx_core {
> + leds_pins_default: leds_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)  
> /* gpmc_a15.gpio2_5 */
> + >;
> + };
> +
> + i2c1_pins_default: i2c1_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0) 

Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Rob Herring]

On Sun, Nov 29, 2015 at 02:10:01PM +0200, Dmitry Lifshitz wrote:
> Hi Nishanth,
> 
> Thank you for the provided feedback.
> 
> On 11/25/2015 11:36 PM, Nishanth Menon wrote:
> >On 11/25/2015 12:39 AM, Dmitry Lifshitz wrote:
> >[...]
> >
> >>diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
> >>b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> >>new file mode 100644
> >>index 000..b11d7da
> >>--- /dev/null
> >>+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> >[...]
> >
> >>+/ {
> >>+   model = "CompuLab CL-SOM-AM57x";
> >>+   compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> >>"ti,dra74", "ti,dra7";
> >>+
> >>+   memory {
> >>+   device_type = "memory";
> >>+   reg = <0x8000 0x2000>; /* 512 MB - minimal 
> >>configuration */
> >
> >I think if you like to enable LPAE, the format might look a little
> >different..
> >
> 
> We would like to have a basic HW support in the mainline. It might be
> enhanced later, once we get to work on LPAE stuff.

I think what is meant here is the cell sizes should be 2 instead of 1. 
You can do that independent of LPAE support. I would expect the base SOC 
dtsi file to set the cell sizes correctly though.

Rob

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/14] ARM: sb-som: dts: introduce SB-SOM baseboard

[Rob Herring]

On Tue, Nov 24, 2015 at 03:19:13PM +0200, Nikita Kiryanov wrote:
> CompuLab SB-SOM baseboard is a carrier board for multiple arm-based SoMs.
> It currently supports (with minor adjustments to assembly) CM-T43, CM-T54,
> and CM-QS600 modules. It is a building block in the SBC-T43 single board
> computer, which consists of cm-t43 on top of sb-som-t43.
> 
> Signed-off-by: Nikita Kiryanov 
> Cc: Tony Lindgren 
> Cc: Igor Grinberg 
> Cc: Dmitry Lifshitz 
> Cc: Ian Campbell 
> ---
>  .../devicetree/bindings/arm/compulab-boards.txt|  5 +++
>  .../bindings/display/panel/startek,startek-kd050c  |  4 +++

.txt please.

>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  arch/arm/boot/dts/compulab-sb-som.dtsi | 42 
> ++
>  4 files changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
>  create mode 100644 arch/arm/boot/dts/compulab-sb-som.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/compulab-boards.txt 
> b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> new file mode 100644
> index 000..3e742a5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> @@ -0,0 +1,5 @@
> +CompuLab SB-SOM is a multi-module baseboard capable of carrying CM-T43, 
> CM-T54,
> +and QS-600 modules with minor modifications to the SB-SOM assembly.

All these modules have compatible strings?

> +
> +Required root node properties:
> +- compatible = should be "compulab,sb-som"
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c 
> b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> new file mode 100644
> index 000..70cd8d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> @@ -0,0 +1,4 @@
> +Startek Electronic Technology Co. KD050C 5.0" WVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "startek,startek-kd050c"
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 55df1d4..409b134 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -218,6 +218,7 @@ sony  Sony Corporation
>  spansion Spansion Inc.
>  sprd Spreadtrum Communications Inc.
>  st   STMicroelectronics
> +startek  Startek
>  ste  ST-Ericsson
>  stericsson   ST-Ericsson
>  synology Synology, Inc.
> diff --git a/arch/arm/boot/dts/compulab-sb-som.dtsi 
> b/arch/arm/boot/dts/compulab-sb-som.dtsi
> new file mode 100644
> index 000..402a143
> --- /dev/null
> +++ b/arch/arm/boot/dts/compulab-sb-som.dtsi
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/ {
> + model = "CompuLab SB-SOM";
> + compatible = "compulab,sb-som";

I would expect this to have a more specific.

> + lcd0: display {
> + compatible = "startek,startek-kd050c", "panel-dpi";
> + label = "lcd";

This isn't documented, nor do I think it is needed.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/14] ARM: am437x: cm-t43: dts: add basic support for sbc-t43

[Rob Herring]

On Tue, Nov 24, 2015 at 03:19:02PM +0200, Nikita Kiryanov wrote:
> Add basic support for SBC-T43: a CM-T43 based single board computer.
> CM-T43 is an AM437x based System-on-Module designed to serve as a building
> block in embedded applications. SBC-T43 is composed of CM-T43 module on
> top of the SB-SOM-T43 baseboard.
> Basic support includes UART, GPIO, and I2C.
> 
> Signed-off-by: Nikita Kiryanov <nik...@compulab.co.il>
> Cc: Tony Lindgren <t...@atomide.com>
> Cc: Igor Grinberg <grinb...@compulab.co.il>
> Cc: Dmitry Lifshitz <lifsh...@compulab.co.il>
> Cc: Ian Campbell <ijc+devicet...@hellion.org.uk>

Some minor nits below, otherwise:

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../devicetree/bindings/arm/omap/omap.txt  |  6 ++
>  arch/arm/boot/dts/Makefile |  6 +-
>  arch/arm/boot/dts/am437x-cm-t43.dts| 90 
> ++
>  arch/arm/boot/dts/am437x-sbc-t43.dts   | 57 ++
>  4 files changed, 157 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/am437x-cm-t43.dts
>  create mode 100644 arch/arm/boot/dts/am437x-sbc-t43.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 9f4e513..da84372 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -141,6 +141,12 @@ Boards:
>  - OMAP5 EVM : Evaluation Module
>compatible = "ti,omap5-evm", "ti,omap5"
>  
> +- AM437x CM-T43
> +  compatible = "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
> +
> +- AM437x SBC-T43
> +  compatible = 
> "compulab,am437x-sbc-t43","compulab,am437x-cm-t43","ti,am4372","ti,am43"
^
spaces

> +
>  - AM43x EPOS EVM
>compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 30bbc37..dc3b9af 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -478,9 +478,11 @@ dtb-$(CONFIG_ARCH_OMAP4) += \
>   omap4-var-stk-om44.dtb
>  dtb-$(CONFIG_SOC_AM43XX) += \
>   am43x-epos-evm.dtb \
> - am437x-sk-evm.dtb \
> + am437x-cm-t43.dtb \
> + am437x-gp-evm.dtb \
>   am437x-idk-evm.dtb \
> - am437x-gp-evm.dtb
> + am437x-sbc-t43.dtb \
> + am437x-sk-evm.dtb
>  dtb-$(CONFIG_SOC_OMAP5) += \
>   omap5-cm-t54.dtb \
>   omap5-igep0050.dtb \
> diff --git a/arch/arm/boot/dts/am437x-cm-t43.dts 
> b/arch/arm/boot/dts/am437x-cm-t43.dts
> new file mode 100644
> index 000..69887c4
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-cm-t43.dts
> @@ -0,0 +1,90 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include 
> +#include "am4372.dtsi"
> +
> +/ {
> + model = "CompuLab CM-T43";
> + compatible = "compulab,am437x-cm-t43","ti,am4372","ti,am43";
  ^
space

[...]

> diff --git a/arch/arm/boot/dts/am437x-sbc-t43.dts 
> b/arch/arm/boot/dts/am437x-sbc-t43.dts
> new file mode 100644
> index 000..f3cd76b
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-sbc-t43.dts
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am437x-cm-t43.dts"
> +
> +/ {
> + model = "CompuLab CM-T43 on SB-SOM-T43";
> + compatible = 
> "compulab,am437x-sbc-t43","compulab,am437x-cm-t43","ti,am4372","ti,am43";

spaces

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/6] ARM: OMAP2+: dts: cm-t335: add initial support

[Rob Herring]

On Tue, Nov 24, 2015 at 04:02:08PM +0200, Uri Mashiach wrote:
> From: Ilya Ledvich <i...@compulab.co.il>
> 
> Add basic support for CompuLab cm-t335 module based on AM335X SoC.
> 
> CM-T335 is a tiny computer-on-module (CoM) / system-on-module (SoM)
> The module is built around the Texas Instruments Sitara AM3352/4
> system-on-chip.
> 
> The CPU is supplemented with up-to 512MB DDR3 and up-to 1GB of on-board
> NAND storage, WiFi connected to SPI, Bluetooth, Analog audio, Gigabit
> Ethernet, CAN bus.
> 
> Current patch adds support:
> UART0 and GPIO LED
> 
> Detailed description can be found at the module site:
> http://www.compulab.co.il/products/computer-on-modules/cm-t335/
> 
> Signed-off-by: Ilya Ledvich <i...@compulab.co.il>
> [uri.mashi...@compulab.co.il: the default RAM amount reduced to
> 128MB to support also the minimal module configuration]
> Signed-off-by: Uri Mashiach <uri.mashi...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>
> ---
> v1 -> v2: integrate AM33XX_IOPAD macro in pinmux definitions

This macro is exactly the kind we should not be doing in DT files which 
are ones that expand to multiple cells. But not really much point in 
doing 1 board differently from the rest, so:

Acked-by: Rob Herring <r...@kernel.org>

Rob

> 
>  .../devicetree/bindings/arm/omap/omap.txt  |  3 ++
>  arch/arm/boot/dts/Makefile |  7 +--
>  arch/arm/boot/dts/am335x-cm-t335.dts   | 63 
> ++
>  3 files changed, 70 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/boot/dts/am335x-cm-t335.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 9f4e513..2154f97 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -138,6 +138,9 @@ Boards:
>  - AM335X phyBOARD-WEGA: Single Board Computer dev kit
>compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
>  
> +- AM335X CM-T335 : System On Module, built around the Sitara AM3352/4
> +  compatible = "compulab,cm-t335", "ti,am33xx"
> +
>  - OMAP5 EVM : Evaluation Module
>compatible = "ti,omap5-evm", "ti,omap5"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index bb8fa02..0e011dc 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -446,13 +446,14 @@ dtb-$(CONFIG_SOC_AM33XX) += \
>   am335x-base0033.dtb \
>   am335x-bone.dtb \
>   am335x-boneblack.dtb \
> - am335x-sl50.dtb \
> + am335x-chiliboard.dtb \
> + am335x-cm-t335.dtb \
>   am335x-evm.dtb \
>   am335x-evmsk.dtb \
> + am335x-lxm.dtb \
>   am335x-nano.dtb \
>   am335x-pepper.dtb \
> - am335x-lxm.dtb \
> - am335x-chiliboard.dtb \
> + am335x-sl50.dtb \
>   am335x-wega-rdk.dtb
>  dtb-$(CONFIG_ARCH_OMAP4) += \
>   omap4-duovero-parlor.dtb \
> diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
> b/arch/arm/boot/dts/am335x-cm-t335.dts
> new file mode 100644
> index 000..719658e
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-cm-t335.dts
> @@ -0,0 +1,63 @@
> +/*
> + * am335x-cm-t335.dts - Device Tree file for Compulab CM-T335
> + *
> + * Copyright (C) 2014 - 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include "am33xx.dtsi"
> +
> +/ {
> + model = "CompuLab CM-T335";
> + compatible = "compulab,cm-t335", "ti,am33xx";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x800>;   /* 128 MB */
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_led_pins>;
> + led@0 {
> + label = "cm_t335:green";
> + gpios = < 0 GPIO_ACTIVE_LOW>; /* gpio2_0 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> +
> +_pinmux {
> + pinctrl-names = "default";
> + pinctrl-0 = <>;
> +
> + gpio_led_pins: pinmux_gpio_led_pins {
> + pinctrl-single,pins = <
>

Re: [PATCH 11/18] ARM: am57xx: sbc-am57x: dts: add basic board support

[Rob Herring]

On Wed, Nov 25, 2015 at 08:39:43AM +0200, Dmitry Lifshitz wrote:
> SBC-AM57x is a single board computer designed for industrial and
> embedded applications. It is based on the Texas Instruments Sitara AM57x
> system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x
> computer-on-module providing most of the functions, and SB-SOM-AM57x
> carrier board providing additional peripheral functions and connectors.
> 
> https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/
> 
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
> 
> Add basic board support, including UART3, used as a serial console.
> 
> Signed-off-by: Dmitry Lifshitz <lifsh...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../devicetree/bindings/arm/omap/omap.txt  |  3 ++
>  arch/arm/boot/dts/Makefile |  1 +
>  arch/arm/boot/dts/am57xx-sbc-am57x.dts | 36 
> ++
>  3 files changed, 40 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index dd53c90..42cdad1 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -159,6 +159,9 @@ Boards:
>  - AM57XX CL-SOM-AM57x
>compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7"
>  
> +- AM57XX SBC-AM57x
> +  compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728", 
> "ti,dra742", "ti,dra74", "ti,dra7"
> +
>  - DRA742 EVM:  Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 803a020..4c73ab9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -479,6 +479,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
>  dtb-$(CONFIG_SOC_DRA7XX) += \
>   am57xx-beagle-x15.dtb \
>   am57xx-cl-som-am57x.dtb \
> + am57xx-sbc-am57x.dtb \
>   dra7-evm.dtb \
>   dra72-evm.dtb
>  dtb-$(CONFIG_ARCH_ORION5X) += \
> diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
> b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> new file mode 100644
> index 000..804ad72
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> @@ -0,0 +1,36 @@
> +/*
> + * Support for CompuLab SBC-AM57x single board computer
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz <lifsh...@compulab.co.il>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +#include "am57xx-cl-som-am57x.dts"
> +#include "compulab-sb-som.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
> + compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", 
> "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
> +};
> +
> +_pmx_core {
> + uart3_pins_default: uart3_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2)   
> /* uart2_ctsn.uart3_rxd */
> + DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)   
> /* uart2_rtsn.uart3_txd */
> + >;
> + };
> +};
> +
> + {
> + status = "okay";
> + interrupts-extended = <_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> +   <_pmx_core 0x3f8>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> +};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Rob Herring]

On Wed, Nov 25, 2015 at 08:39:33AM +0200, Dmitry Lifshitz wrote:
> Add support for CompuLab CM-SOM-AM57X board.
> 
> CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
> TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.
> 
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
> 
> Add basic DT support for standalone module (without a carrier board):
> 
> * Memory configuration
> * Heartbeat led
> * I2C1 bus
> * PMIC
> * SATA
> 
> Signed-off-by: Dmitry Lifshitz <lifsh...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  .../devicetree/bindings/arm/omap/omap.txt  |   3 +
>  arch/arm/boot/dts/Makefile |   3 +-
>  arch/arm/boot/dts/am57xx-cl-som-am57x.dts  | 259 
> +
>  3 files changed, 264 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index da84372..dd53c90 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -156,6 +156,9 @@ Boards:
>  - AM437x SK EVM: AM437x StarterKit Evaluation Module
>compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
>  
> +- AM57XX CL-SOM-AM57x
> +  compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7"
> +
>  - DRA742 EVM:  Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5492a24..803a020 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -477,8 +477,9 @@ dtb-$(CONFIG_SOC_OMAP5) += \
>   omap5-sbc-t54.dtb \
>   omap5-uevm.dtb
>  dtb-$(CONFIG_SOC_DRA7XX) += \
> - dra7-evm.dtb \
>   am57xx-beagle-x15.dtb \
> + am57xx-cl-som-am57x.dtb \
> + dra7-evm.dtb \
>   dra72-evm.dtb
>  dtb-$(CONFIG_ARCH_ORION5X) += \
>   orion5x-lacie-d2-network.dtb \
> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
> b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> new file mode 100644
> index 000..b11d7da
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> @@ -0,0 +1,259 @@
> +/*
> + * Support for CompuLab CL-SOM-AM57x System-on-Module
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz <lifsh...@compulab.co.il>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "dra74x.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x";
> + compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
> "ti,dra74", "ti,dra7";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB - minimal 
> configuration */
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> +
> + led@0 {
> + label = "cl-som-am57x:green";
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> + };
> +};
> +
> +_pmx_core {
> + leds_pins_default: leds_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)  
> /* gpmc_a15.gpio2_5 */
> + >;
> + };
> +
> + i2c1_pins_default: i2c1_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* i2c1_sda.sda */
> + DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* i2c1_scl.scl */
> + >;
> + };
> +
> + tps659038_pins_default: tps659038_pins_default {
> + pinctrl-single,pins = <
> + 

Re: [PATCH v2 6/8] drivers:input:ads7846(+tsc2046): recognise old binding for coordinate flipping

[Rob Herring]

On Fri, Nov 13, 2015 at 2:35 PM, H. Nikolaus Schaller  
wrote:
> By this patch we still recognise the old binding ti,swap-xy in parallel to
> the common binding touchscreen-swapped-x-y. This keeps compatibility
> to older (out-of-tree) device tree binaries.
>
> We do this in a separate patch so that it can be easily reverted in the
> future to retire the old API. A notice is printed to remind developers
> of using old API.
>
> We also fix the bindings name for all in-tree device tree sources in
> a separate patch.

This one and patch 5 should be combined, so the series is bisectable.

Rob

>
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  drivers/input/touchscreen/ads7846.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ads7846.c 
> b/drivers/input/touchscreen/ads7846.c
> index 4525f00..b9896fd 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -1259,7 +1259,11 @@ static const struct ads7846_platform_data 
> *ads7846_probe_dt(struct device *dev)
> of_property_read_u16(node, "ti,vref-mv", >vref_mv);
> pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
>
> -   pdata->swap_xy = of_property_read_bool(node, 
> "touchscreen-swapped-x-y");
> +   pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy");
> +   if (pdata->swap_xy)
> +   dev_notice(dev, "please update device tree to use 
> touchscreen-swapped-x-y");
> +   pdata->swap_xy |= of_property_read_bool(node,
> +   "touchscreen-swapped-x-y");
>
> of_property_read_u16(node, "ti,settle-delay-usec",
>  >settle_delay_usecs);
> --
> 2.5.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Rob Herring]

On Fri, Nov 13, 2015 at 09:35:52PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> This has been integrated and interpretation of the inversion (flipping)
> properties for the x and y axis has been added to accommodate any
> orientation of the touch in relation to the LCD.
> 
> By scaling the min/max ADC values to the screen size it is now possible to
> pre-calibrate the touch so that is (almost) exactly matches the LCD it is
> glued onto. This allows to well enough operate the touch before a user
> space calibration can improve the precision.
> 
> calculate_pressure has been renamed to calculate_resistance because
> that is what it is doing.
> 
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

This still looks like it will break with old dtbs. It doesn't matter if 
you update the in tree dts files, you should not force users to update 
their dtb.

Rob

> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  .../bindings/input/touchscreen/tsc2007.txt |  20 +--
>  drivers/input/touchscreen/tsc2007.c| 135 
> +
>  include/linux/i2c/tsc2007.h|   8 ++
>  3 files changed, 135 insertions(+), 28 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
> index ec365e1..6e9fd55 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
> @@ -6,6 +6,7 @@ Required properties:
>  - ti,x-plate-ohms: X-plate resistance in ohms.
>  
>  Optional properties:
> +- generic touch screen properties: see touchscreen binding [2].
>  - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
>The penirq pin goes to low when the panel is touched.
>(see GPIO binding[1] for more details).
> @@ -13,17 +14,20 @@ Optional properties:
>(see interrupt binding[0]).
>  - interrupts: (gpio) interrupt to which the chip is connected
>(see interrupt binding[0]).
> -- ti,max-rt: maximum pressure.
> -- ti,fuzzx: specifies the absolute input fuzz x value.
> -  If set, it will permit noise in the data up to +- the value given to the 
> fuzz
> -  parameter, that is used to filter noise from the event stream.
> -- ti,fuzzy: specifies the absolute input fuzz y value.
> -- ti,fuzzz: specifies the absolute input fuzz z value.
> +- ti,max-rt: maximum pressure resistance above which samples are ignored
> +  (default: 4095).
> +- ti,report-resistance: report resistance (no pressure = max_rt) instead
> +  of pressure (no pressure = 0).
> +- ti,min-x: minimum value reported by X axis ADC (default 0).
> +- ti,max-x: maximum value reported by X axis ADC (default 4095).
> +- ti,min-y: minimum value reported by Y axis ADC (default 0).
> +- ti,max-y: maximum value reported by Y axis ADC (default 4095).
>  - ti,poll-period: how much time to wait (in milliseconds) before reading 
> again the
> -  values from the tsc2007.
> +  values from the tsc2007 (default 1).
>  
>  [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>  [1]: Documentation/devicetree/bindings/gpio/gpio.txt
> +[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>  
>  Example:
>{
> @@ -35,6 +39,8 @@ Example:
>   interrupts = <0x0 0x8>;
>   gpios = < 0 0>;
>   ti,x-plate-ohms = <180>;
> + touchscreen-size-x = <640>;
> + touchscreen-size-y = <480>;
>   };
>  
>   /* ... */
> diff --git a/drivers/input/touchscreen/tsc2007.c 
> b/drivers/input/touchscreen/tsc2007.c
> index 5d0cd51..e0c7173 100644
> --- a/drivers/input/touchscreen/tsc2007.c
> +++ b/drivers/input/touchscreen/tsc2007.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define TSC2007_MEASURE_TEMP0(0x0 << 4)
>  #define TSC2007_MEASURE_AUX  (0x2 << 4)
> @@ -74,6 +75,14 @@ struct tsc2007 {
>  
>   u16 model;
>   u16 x_plate_ohms;
> + boolswap_xy;
> + boolinvert_x;
> + boolinvert_y;
> + boolreport_resistance;
> + u16 min_x;
> + u16 min_y;
> + u16 max_x;
> + u16 max_y;
>   u16 max_rt;
>   unsigned long   poll_period; /* in jiffies */
>   int fuzzx;
> @@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, 
> struct ts_event *tc)
>   tsc2007_xfer(tsc, PWRDOWN);
>  }
>  
> -static u32 

Re: [PATCH v2] regulator: tps65217: remove tps65217.dtsi file

[Rob Herring]

On Tue, Oct 27, 2015 at 01:36:36PM +0100, Heiko Schocher wrote:
> remove tps65217.dtsi and adapt all boards, which
> used it.
> 
> Signed-off-by: Heiko Schocher <h...@denx.de>
> Tested-by: Keerthy <j-keer...@ti.com>
> Acked-by: Mark Brown <broo...@kernel.org>

Acked-by: Rob Herring <r...@kernel.org>

> ---
> Suggested by Mark Brown, see:
> https://lkml.org/lkml/2015/10/21/581
> 
> Changes in v2:
> - accidentially removed tps65217.txt
>   do not remove it, add Sebastian Reichel to
>   cc, as he also deteted this.
> - add Acked-by from Mark Brown
> - add Tested-by from j-keerthy
> 
>  .../devicetree/bindings/regulator/tps65217.txt | 10 
>  arch/arm/boot/dts/am335x-bone-common.dtsi  | 14 --
>  arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +-
>  arch/arm/boot/dts/am335x-nano.dts  | 14 +-
>  arch/arm/boot/dts/am335x-pepper.dts| 14 +-
>  arch/arm/boot/dts/am335x-sl50.dts  | 13 -
>  arch/arm/boot/dts/tps65217.dtsi| 56 
> --
>  7 files changed, 68 insertions(+), 67 deletions(-)
>  delete mode 100644 arch/arm/boot/dts/tps65217.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt 
> b/Documentation/devicetree/bindings/regulator/tps65217.txt
> index 4f05d20..d181096 100644
> --- a/Documentation/devicetree/bindings/regulator/tps65217.txt
> +++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
> @@ -26,7 +26,11 @@ Example:
>   ti,pmic-shutdown-controller;
>  
>   regulators {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
>   dcdc1_reg: dcdc1 {
> + reg = <0>;
>   regulator-min-microvolt = <90>;
>   regulator-max-microvolt = <180>;
>   regulator-boot-on;
> @@ -34,6 +38,7 @@ Example:
>   };
>  
>   dcdc2_reg: dcdc2 {
> + reg = <1>;
>   regulator-min-microvolt = <90>;
>   regulator-max-microvolt = <330>;
>   regulator-boot-on;
> @@ -41,6 +46,7 @@ Example:
>   };
>  
>   dcdc3_reg: dcc3 {
> + reg = <2>;
>   regulator-min-microvolt = <90>;
>   regulator-max-microvolt = <150>;
>   regulator-boot-on;
> @@ -48,6 +54,7 @@ Example:
>   };
>  
>   ldo1_reg: ldo1 {
> + reg = <3>;
>   regulator-min-microvolt = <100>;
>   regulator-max-microvolt = <330>;
>   regulator-boot-on;
> @@ -55,6 +62,7 @@ Example:
>   };
>  
>   ldo2_reg: ldo2 {
> + reg = <4>;
>   regulator-min-microvolt = <90>;
>   regulator-max-microvolt = <330>;
>   regulator-boot-on;
> @@ -62,6 +70,7 @@ Example:
>   };
>  
>   ldo3_reg: ldo3 {
> + reg = <5>;
>   regulator-min-microvolt = <180>;
>   regulator-max-microvolt = <330>;
>   regulator-boot-on;
> @@ -69,6 +78,7 @@ Example:
>   };
>  
>   ldo4_reg: ldo4 {
> + reg = <6>;
>   regulator-min-microvolt = <180>;
>   regulator-max-microvolt = <330>;
>   regulator-boot-on;
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index fec7834..0c4bde0 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -285,10 +285,8 @@
>   };
>  };
>  
> -
> -/include/ "tps65217.dtsi"
> -
>   {
> + compatible = "ti,tps65217";
>   /*
>* Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
>* mode") at poweroff.  Most BeagleBone versions do not support RTC-only
&

Re: [PATCH 1/7] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Rob Herring]

On Fri, Nov 06, 2015 at 04:14:43PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> This has been integrated and interpretation of the inversion (flipping)
> properties for the x and y axis has been added to accommodate any
> orientation of the touch in relation to the LCD.
> 
> By scaling the min/max ADC values to the screen size it is now possible to
> pre-calibrate the touch so that is (almost) exactly matches the LCD it is
> glued onto. This allows to well enough operate the touch before a user
> space calibration can improve the precision.
> 
> calculate_pressure has been renamed to calculate_resistance because
> that is what it is doing.
> 
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  .../bindings/input/touchscreen/tsc2007.txt |  20 +--
>  drivers/input/touchscreen/tsc2007.c| 135 
> +
>  include/linux/i2c/tsc2007.h|   8 ++
>  3 files changed, 135 insertions(+), 28 deletions(-)

This one has similar problems with breaking backwards compatibility.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/7] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[Rob Herring]

On Fri, Nov 06, 2015 at 04:14:47PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> This has been integrated and interpretation of the inversion (flipping)
> properties for the x and y axis has been added to accommodate any
> orientation of the touch in relation to the LCD.
> 
> By scaling the min/max ADC values to the screen size it is now possible to
> pre-calibrate the touch so that is (almost) exactly matches the LCD it is
> glued onto. This allows to well enough operate the touch before a user
> space calibration can improve the precision.
> 
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  .../devicetree/bindings/input/ads7846.txt  |  8 ++-

The binding change looks okay, but...

> @@ -1213,7 +1259,7 @@ static const struct ads7846_platform_data 
> *ads7846_probe_dt(struct device *dev)
>   of_property_read_u16(node, "ti,vref-mv", >vref_mv);
>   pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
>  
> - pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy");
> + pdata->swap_xy = of_property_read_bool(node, "touchscreen-swapped-x-y");

This will break with old dtb's. The driver should look for either 
property.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges

[Rob Herring]

On Fri, Oct 30, 2015 at 10:00:37AM +0200, Peter Ujfalusi wrote:
> In eDMA the events are directly mapped to a DMA channel (for example DMA
> event 14 can only be handled by DMA channel 14). If the memcpy is enabled
> on the eDMA, there is a possibility that the crossbar driver would assign
> DMA event number already allocated in eDMA for memcpy. Furthermore the
> eDMA can be shared with DSP in which case the crossbar driver should also
> avoid mapping xbar events to DSP used event numbers (or channels).
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  .../devicetree/bindings/dma/ti-dma-crossbar.txt|  6 +++
>  drivers/dma/ti-dma-crossbar.c  | 47 
> --
>  2 files changed, 49 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt 
> b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
> index b152a75dceae..aead5869a28d 100644
> --- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
> +++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
> @@ -14,6 +14,10 @@ The DMA controller node need to have the following 
> poroperties:
>  
>  Optional properties:
>  - ti,dma-safe-map: Safe routing value for unused request lines
> +- ti,reserved-dma-request-ranges: DMA request ranges which should not be used
> + when mapping xbar input to DMA request, they are either
> + allocated to be used by for example the DSP or they are used as
> + memcpy channels in eDMA.

How many requests are there? I think I'd rather see this as a mask 
value.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Rob Herring]

On Tue, Nov 03, 2015 at 03:36:13PM +0530, Vignesh R wrote:
> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> update the binding documents for the controller to document this change.
> 
> Signed-off-by: Vignesh R <vigne...@ti.com>

You don't really need an example for every possibility, but

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  Documentation/devicetree/bindings/spi/ti_qspi.txt | 13 +
>  arch/arm/boot/dts/dra7.dtsi   |  6 --
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> index 601a360531a5..f05dd631bef1 100644
> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> @@ -26,3 +26,16 @@ qspi: qspi@4b30 {
>   spi-max-frequency = <2500>;
>   ti,hwmods = "qspi";
>  };
> +
> +For dra7xx:
> +qspi: qspi@4b30 {
> + compatible = "ti,dra7xxx-qspi";
> + reg = <0x4b30 0x100>, <0x4a002558 0x4>,
> +   <0x5c00 0x400>;
> + reg-names = "qspi_base", "qspi_ctrlmod",
> + "qspi_mmap";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + spi-max-frequency = <4800>;
> + ti,hwmods = "qspi";
> +};
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index e289c706d27d..13c2f10ec217 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1108,8 +1108,10 @@
>  
>   qspi: qspi@4b30 {
>   compatible = "ti,dra7xxx-qspi";
> - reg = <0x4b30 0x100>;
> - reg-names = "qspi_base";
> + reg = <0x4b30 0x100>, <0x4a002558 0x4>,
> +   <0x5c00 0x400>;
> + reg-names = "qspi_base", "qspi_ctrlmod",
> + "qspi_mmap";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   ti,hwmods = "qspi";
> -- 
> 2.6.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/5] ARM: dts: AM4372: add entry for qspi mmap region

[Rob Herring]

On Tue, Nov 03, 2015 at 03:36:14PM +0530, Vignesh R wrote:
> Add qspi memory mapped region entries for AM43xx based SoCs. Also,
> update the binding documents for the controller to document this change.
> 
> Signed-off-by: Vignesh R <vigne...@ti.com>

Acked-by: Rob Herring <r...@kernel.org>

> ---
>  Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
>  arch/arm/boot/dts/am4372.dtsi | 4 +++-
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> index f05dd631bef1..05488970060b 100644
> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> @@ -17,9 +17,10 @@ Recommended properties:
>  
>  Example:
>  
> +For am4372:
>  qspi: qspi@4b30 {
> - compatible = "ti,dra7xxx-qspi";
> - reg = <0x4790 0x100>, <0x3000 0x3ff>;
> + compatible = "ti,am4372-qspi";
> + reg = <0x4790 0x100>, <0x3000 0x400>;
>   reg-names = "qspi_base", "qspi_mmap";
>   #address-cells = <1>;
>   #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index 0447c04a40cc..1b2c545f3f2c 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -962,7 +962,9 @@
>  
>   qspi: qspi@4790 {
>   compatible = "ti,am4372-qspi";
> - reg = <0x4790 0x100>;
> + reg = <0x4790 0x100>,
> +   <0x3000 0x400>;
> + reg-names = "qspi_base", "qspi_mmap";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   ti,hwmods = "qspi";
> -- 
> 2.6.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net, can, ti_hecc: add DT support for the ti,hecc controller

[Rob Herring]

On Mon, Oct 19, 2015 at 1:58 AM, Marc Kleine-Budde  wrote:
> On 10/19/2015 08:39 AM, Heiko Schocher wrote:
>> add DT support for the ti hecc controller, used on
>> am3517 SoCs.
>
> A similar patch was posted a few days ago, see
> http://comments.gmane.org/gmane.linux.can/8616 and my comments.

I don't seem to have that in my inbox. Please send DT bindings to the
DT list and maintainers.

Rob

>
> Please coordinate with Anton Glukhov (Cc'ed) and/or pick up his patches
> as they are in better shape.
>
> Marc
>>
>> Signed-off-by: Heiko Schocher 
>> ---
>>
>>  .../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
>>  arch/arm/boot/dts/am3517.dtsi  | 13 +++
>>  drivers/net/can/ti_hecc.c  | 45 
>> +-
>>  3 files changed, 76 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt 
>> b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>> new file mode 100644
>> index 000..09fab59
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>> @@ -0,0 +1,20 @@
>> +* TI HECC CAN *
>> +
>> +Required properties:
>> +  - compatible: Should be "ti,hecc"
>
> We usually put the name of the first SoC this IP core appears in to the
> compatible.
>
>> +  - reg: Should contain CAN controller registers location and length
>> +  - interrupts: Should contain IRQ line for the CAN controller
>
> I'm missing the description of the ti,* properties. I think they are
> required, too. Although the code doesn't enforce it.
>
>> +
>> +Example:
>> +
>> + can0: hecc@5c05 {
>> + compatible = "ti,hecc";
>> + reg = <0x5c05 0x4000>;
>> + interrupts = <24>;
>> + ti,hecc_scc_offset = <0>;
>> + ti,hecc_scc_ram_offset = <0x3000>;
>> + ti,hecc_ram_offset = <0x3000>;
>> + ti,hecc_mbx_offset = <0x2000>;
>> + ti,hecc_int_line = <0>;
>> + ti,hecc_version = <1>;
>
> Versioning in the OF world is done via the compatible. Are the offsets a
> per SoC parameter? I'm not sure if it's better to put
> the offsets into the driver.
>
>> + };
>> diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
>> index 5e3f5e8..47bc429 100644
>> --- a/arch/arm/boot/dts/am3517.dtsi
>> +++ b/arch/arm/boot/dts/am3517.dtsi
>> @@ -25,6 +25,19 @@
>>   interrupt-names = "mc";
>>   };
>>
>> + can0: hecc@5c05 {
>> + compatible = "ti,hecc";
>> + reg = <0x5c05 0x4000>;
>> + interrupts = <24>;
>> + ti,hecc_scc_offset = <0>;
>> + ti,hecc_scc_ram_offset = <0x3000>;
>> + ti,hecc_ram_offset = <0x3000>;
>> + ti,hecc_mbx_offset = <0x2000>;
>> + ti,hecc_int_line = <0>;
>> + ti,hecc_version = <1>;
>> + status = "disabled";
>> + };
>> +
>>   davinci_emac: ethernet@0x5c00 {
>>   compatible = "ti,am3517-emac";
>>   ti,hwmods = "davinci_emac";
>> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
>> index c08e8ea..f1705d5 100644
>> --- a/drivers/net/can/ti_hecc.c
>> +++ b/drivers/net/can/ti_hecc.c
>> @@ -875,16 +875,56 @@ static const struct net_device_ops ti_hecc_netdev_ops 
>> = {
>>   .ndo_change_mtu = can_change_mtu,
>>  };
>>
>> +#if defined(CONFIG_OF)
>> +static const struct of_device_id ti_hecc_can_dt_ids[] = {
>> + {
>> + .compatible = "ti,hecc",
>> + }, {
>> + /* sentinel */
>> + }
>> +};
>> +MODULE_DEVICE_TABLE(of, ti_hecc_can_dt_ids);
>> +#endif
>
> Please remove the ifdef, use __maybe_unused instead.
>
>> +
>> +static const struct ti_hecc_platform_data
>> +*ti_hecc_can_get_driver_data(struct platform_device *pdev)
>> +{
>> + if (pdev->dev.of_node) {
>> + struct ti_hecc_platform_data *data;
>> + struct device_node *np = pdev->dev.of_node;
>> +
>> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return NULL;
>> +
>> + of_property_read_u32(np, "ti,hecc_scc_offset",
>> +  >scc_hecc_offset);
>> + of_property_read_u32(np, "ti,hecc_scc_ram_offset",
>> +  >scc_ram_offset);
>> + of_property_read_u32(np, "ti,hecc_ram_offset",
>> +  >hecc_ram_offset);
>> + of_property_read_u32(np, "ti,hecc_mbx_offset",
>> +  >mbx_offset);
>> + of_property_read_u32(np, "ti,hecc_int_line",
>> +  

Re: [PATCH RFC v4 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

[Rob Herring]

On Thu, Sep 24, 2015 at 5:36 AM, Jean-Francois Moine <moin...@free.fr> wrote:
> On Mon, 21 Sep 2015 10:19:18 -0500
> Rob Herring <r...@kernel.org> wrote:
>
>> On 09/18/2015 06:06 AM, Jyri Sarha wrote:
>> > From: Jean-Francois Moine <moin...@free.fr>
>> >
>> > Two kinds of ports may be declared in a DT graph of ports: video and audio.
>> > This patch accepts the port value from a video port as an alternative
>> > to the video-ports property.
>> > It also accepts audio ports in the case the transmitter is not used as
>> > a slave encoder.
>> > The new file include/sound/tda998x.h prepares to the definition of
>> > a tda998x CODEC.
>> >
>> > Signed-off-by: Jean-Francois Moine <moin...@free.fr>
>> > Signed-off-by: Jyri Sarha <jsa...@ti.com>
>> > ---
> [snip]
>> > diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
>> > b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
>> > index e9e4bce..35f6a80 100644
>> > --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
>> > +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
>> > @@ -16,6 +16,35 @@ Optional properties:
>> >
>> >- video-ports: 24 bits value which defines how the video controller
>> > output is wired to the TDA998x input - default: <0x230145>
>> > +   This property is not used when ports are defined.
>> > +
>> > +Optional nodes:
>> > +
>> > +  - port: up to three ports.
>> > +   The ports are defined according to [1].
>> > +
>> > +Video port.
>> > +   There may be only one video port.
>> > +   This one must contain the following property:
>> > +
>> > +   - port-type: must be "rgb"
>>
>> Why do you need this if there is no other choice? The port number should
>> define which one is video.
>
> There is no specific port number.
> One of the ports is video and two other ones are audio.

I saying you should define the port numbering in the binding. Port 0
is video, Port 1 is i2s, etc.

>
>> > +
>> > +   and may contain the optional property:
>> > +
>> > +   - reg: 24 bits value which defines how the video controller
>> > +   output is wired to the TDA998x input (video pins)
>> > +   When absent, the default value is <0x230145>.
>>
>> I'm failing to decode how this value works. In any case, I would keep
>> this as a vendor specific property rather than abusing reg.
>
> This has been explained in
> https://lkml.org/lkml/2014/1/20/86

Okay, so that explains how it works, but still it should not be in reg.

>
>> > +
>> > +Audio ports.
>> > +   There may be one or two audio ports.
>> > +   These ones must contain the following properties:
>> > +
>> > +   - port-type: must be "i2s" or "spdif"
>> > +
>> > +   - reg: 8 bits value which defines how the audio controller
>> > +   output is wired to the TDA998x input (audio pins)
>>
>> reg is 32-bits.
>
> This port has only 8 significant bits as explained in
> https://lkml.org/lkml/2015/1/7/362

Maybe only 8-bits are used, but the size of the data in the DTB is
32-bits unless you add 8-bit annotation. Again, reg is not appropriate
to use here.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC v4 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

[Rob Herring]

On 09/18/2015 06:06 AM, Jyri Sarha wrote:
> From: Jean-Francois Moine 
> 
> Two kinds of ports may be declared in a DT graph of ports: video and audio.
> This patch accepts the port value from a video port as an alternative
> to the video-ports property.
> It also accepts audio ports in the case the transmitter is not used as
> a slave encoder.
> The new file include/sound/tda998x.h prepares to the definition of
> a tda998x CODEC.
> 
> Signed-off-by: Jean-Francois Moine 
> Signed-off-by: Jyri Sarha 
> ---
>  .../devicetree/bindings/drm/i2c/tda998x.txt| 51 
>  drivers/gpu/drm/i2c/tda998x_drv.c  | 90 
> +++---
>  include/sound/tda998x.h|  8 ++
>  3 files changed, 140 insertions(+), 9 deletions(-)
>  create mode 100644 include/sound/tda998x.h
> 
> diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
> b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> index e9e4bce..35f6a80 100644
> --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> @@ -16,6 +16,35 @@ Optional properties:
>  
>- video-ports: 24 bits value which defines how the video controller
>   output is wired to the TDA998x input - default: <0x230145>
> + This property is not used when ports are defined.
> +
> +Optional nodes:
> +
> +  - port: up to three ports.
> + The ports are defined according to [1].
> +
> +Video port.
> + There may be only one video port.
> + This one must contain the following property:
> +
> + - port-type: must be "rgb"

Why do you need this if there is no other choice? The port number should
define which one is video.

> +
> + and may contain the optional property:
> +
> + - reg: 24 bits value which defines how the video controller
> + output is wired to the TDA998x input (video pins)
> + When absent, the default value is <0x230145>.

I'm failing to decode how this value works. In any case, I would keep
this as a vendor specific property rather than abusing reg.

> +
> +Audio ports.
> + There may be one or two audio ports.
> + These ones must contain the following properties:
> +
> + - port-type: must be "i2s" or "spdif"
> +
> + - reg: 8 bits value which defines how the audio controller
> + output is wired to the TDA998x input (audio pins)

reg is 32-bits.

> +
> +[1] Documentation/devicetree/bindings/graph.txt
>  
>  Example:
>  
> @@ -26,4 +55,26 @@ Example:
>   interrupts = <27 2>;/* falling edge */
>   pinctrl-0 = <_camera>;
>   pinctrl-names = "default";
> +
> + port@230145 {
> + port-type = "rgb";
> + reg = <0x230145>;
> + hdmi_0: endpoint {
> + remote-endpoint = <_0>;
> + };
> + };
> + port@3 {/* AP1 = I2S */

Is 3 significant? What happened to 0-2?

> + port-type = "i2s";
> + reg = <0x03>;
> + tda998x_i2s: endpoint {
> + remote-endpoint = <_i2s>;
> + };
> + };
> + port@4 { /* AP2 = S/PDIF */
> + port-type = "spdif";
> + reg = <0x04>;
> + tda998x_spdif: endpoint {
> + remote-endpoint = <_spdif1>;
> + };
> + };
>   };
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 424228b..0952eac 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>  
> @@ -47,6 +48,8 @@ struct tda998x_priv {
>   wait_queue_head_t wq_edid;
>   volatile int wq_edid_wait;
>   struct drm_encoder *encoder;
> +
> + struct tda998x_audio audio;
>  };
>  
>  #define to_tda998x_priv(x)  ((struct tda998x_priv 
> *)to_encoder_slave(x)->slave_priv)
> @@ -774,6 +777,8 @@ static void tda998x_encoder_set_config(struct 
> tda998x_priv *priv,
>   (p->mirr_f ? VIP_CNTRL_2_MIRR_F : 0);
>  
>   priv->params = *p;
> + priv->audio.port_types[0] = p->audio_format;
> + priv->audio.ports[0] = p->audio_cfg;
>  }
>  
>  static void tda998x_encoder_dpms(struct tda998x_priv *priv, int mode)
> @@ -1230,9 +1235,57 @@ static struct drm_encoder_slave_funcs 
> tda998x_encoder_slave_funcs = {
>  
>  /* I2C driver functions */
>  
> +static int tda998x_parse_ports(struct tda998x_priv *priv,
> + struct device_node *np)
> +{
> + struct device_node *of_port;
> + const char *port_type;
> + 

Re: [PATCH] Documentation: DT: cpsw: document missing compatible

[Rob Herring]

On Mon, Aug 31, 2015 at 1:21 AM, Mugunthan V N  wrote:
> CPSW driver has multiple compatibles for errata implentations but not
> documented, add necessary documentation.
>
> Signed-off-by: Mugunthan V N 

Applied. Thanks.

Rob
> ---
>
> The compatibles are added in the commit 7da1160002f1 ('drivers:
> net: cpsw: add am335x errata workarround for interrutps') which
> is present in linux-next/master
>
> ---
>  Documentation/devicetree/bindings/net/cpsw.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
> b/Documentation/devicetree/bindings/net/cpsw.txt
> index 33fe846..a9df21a 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -2,7 +2,11 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
>  --
>
>  Required properties:
> -- compatible   : Should be "ti,cpsw"
> +- compatible   : Should be one of the below:-
> + "ti,cpsw" for backward compatible
> + "ti,am335x-cpsw" for AM335x controllers
> + "ti,am4372-cpsw" for AM437x controllers
> + "ti,dra7-cpsw" for DRA7x controllers
>  - reg  : physical base address and size of the cpsw
>   registers map
>  - interrupts   : property with a value describing the interrupt
> --
> 2.5.0.474.g3a9835b
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: device: fix NULL pointer dereference on driver removal

[Rob Herring]

On Tue, Aug 25, 2015 at 2:34 PM, Felipe Balbi ba...@ti.com wrote:
 If we don't insert resources into the resource tree,
 calls to of_platform_depopulate() will end up in NULL
 pointer dereferences because the resource parent will
 be set to NULL even though we still have more resources
 to go through.

Long standing problem. A fix is in -next now and will go into 4.3 (plus stable):

commit 11c63e4718acad3d8f04601c80fddd4b3d1455b1
Author: Grant Likely grant.lik...@linaro.org
Date:   Sun Jun 7 15:20:11 2015 +0100

drivercore: Fix unregistration path of platform devices


 Without this patch, the result is as follows:

 [   28.238158] Unable to handle kernel NULL pointer dereference at virtual 
 address 0008
 [   28.246646] pgd = ed3d8000
 [   28.249480] [0008] *pgd=
 [   28.253247] Internal error: Oops: 5 [#1] SMP ARM
 [   28.258072] Modules linked in: input_leds hid_generic usbkbd usbhid
 xhci_plat_hcd xhci_hcd usbcore joydev dwc3 udc_core usb_common m25p80 evdev 
 spi_nor omapfb cfbfillrect cfbimg blt cpufreq_dt cfbcopyarea thermal_sys 
 snd_soc_simple_card leds_gpio matrix_keypad pwm_bl hwmon led_class 
 matrix_keymap panel_dpi snd_soc_tlv320aic3x snd_soc_davinci_mcasp 
 snd_soc_edma snd_soc_omap snd_soc_core omapdss snd_compress snd_pcm_dmaengine 
 snd_pcm dwc3_omap(-) extcon snd_timer pwm_tiecap snd lis3lv02d_i2c lis3lv02d 
 soundcore input_polldev rtc_omap spi_ti_qspi tps65218_pwrbutton omap_wdt 
 phy_omap_usb2 autofs4
 [   28.313186] CPU: 0 PID: 289 Comm: modprobe Not tainted 
 4.2.0-rc7-next-20150824-2-g5681a109a938-dirty #1093
 [   28.323643] Hardware name: Generic AM43 (Flattened Device Tree)
 [   28.329836] task: ed39d180 ti: ed076000 task.ti: ed076000
 [   28.335496] PC is at __release_resource+0x30/0x13c
 [   28.340501] LR is at __release_resource+0x24/0x13c
 [   28.345501] pc : [c00439e0]lr : [c00439d4]psr: 600d0013
 [   28.345501] sp : ed077e98  ip : 0007  fp : befb3e14
 [   28.357487] r10:   r9 : ed076000  r8 : c000f724
 [   28.362941] r7 :   r6 : ee6f9800  r5 : ed268d40  r4 : c094679c
 [   28.369755] r3 :   r2 : 00f4  r1 : c0648b34  r0 : 0045
 [   28.376560] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment 
 user
 [   28.384008] Control: 10c5387d  Table: ad3d8059  DAC: 0015
 [   28.390005] Process modprobe (pid: 289, stack limit = 0xed076218)
 [   28.396375] Stack: (0xed077e98 to 0xed078000)
 [   28.400924] 7e80: ed268d40 
 [   28.409455] 7ea0: befb3e14 c0640838 0001 c094679c ed268d40 ee6f9800 
 0081 c0043b1c
 [   28.417996] 7ec0: 001c 0001 ee6f9800 c03e2674 ee6f9800  
 c04d3f20 c03e26ac
 [   28.426537] 7ee0: ee6f9810 c04d3fac  c03dcf10 ee1592c0 ed268cf0 
 ee170010 ee170010
 [   28.435065] 7f00: ee170044 c04d3f08 ed268ed0 bf093208 ee170010 bf093c94 
 ee170044 c03e2754
 [   28.443607] 7f20: ee170010 bf093c94 ee170044 c03e095c ee170010 bf093c94 
 ee170044 c03e116c
 [   28.452150] 7f40: bf093c94 7f6232fc 0800 c03e04e4 bf093d00 c00c8a80 
  33637764
 [   28.460703] 7f60: 616d6f5f b6f70070 ed39d180  ed076000  
 befb3e14 c005be74
 [   28.469241] 7f80:  ed076000 7f6232c0 7f6232c0 0001 f67c 
 7f6232c0 7f6232c0
 [   28.477783] 7fa0: 0001 c000f540 7f6232c0 7f6232c0 7f6232fc 0800 
 66d19c00 
 [   28.486341] 7fc0: 7f6232c0 7f6232c0 0001 0081  0001 
 7f6232c0 befb3e14
 [   28.494903] 7fe0: b6f1c2e1 befb2a3c 7f60638f b6f1c2e6 800d0030 7f6232fc 
  
 [   28.503476] [c00439e0] (__release_resource) from [c0043b1c] 
 (release_resource+0x30/0x54)
 [   28.512299] [c0043b1c] (release_resource) from [c03e2674] 
 (platform_device_del+0x70/0x9c)
 [   28.521218] [c03e2674] (platform_device_del) from [c03e26ac] 
 (platform_device_unregister+0xc/0x20)
 [   28.530962] [c03e26ac] (platform_device_unregister) from [c04d3fac] 
 (of_platform_device_destroy+0x8c/0x98)
 [   28.541425] [c04d3fac] (of_platform_device_destroy) from [c03dcf10] 
 (device_for_each_child+0x50/0x7c)
 [   28.551430] [c03dcf10] (device_for_each_child) from [c04d3f08] 
 (of_platform_depopulate+0x2c/0x44)
 [   28.561101] [c04d3f08] (of_platform_depopulate) from [bf093208] 
 (dwc3_omap_remove+0x3c/0x5c [dwc3_omap])
 [   28.571390] [bf093208] (dwc3_omap_remove [dwc3_omap]) from [c03e2754] 
 (platform_drv_remove+0x18/0x30)
 [   28.581387] [c03e2754] (platform_drv_remove) from [c03e095c] 
 (__device_release_driver+0x88/0x114)
 [   28.591023] [c03e095c] (__device_release_driver) from [c03e116c] 
 (driver_detach+0xb4/0xb8)
 [   28.600014] [c03e116c] (driver_detach) from [c03e04e4] 
 (bus_remove_driver+0x4c/0xa0)
 [   28.608485] [c03e04e4] (bus_remove_driver) from [c00c8a80] 
 (SyS_delete_module+0x11c/0x1e4)
 [   28.617518] [c00c8a80] (SyS_delete_module) from [c000f540] 
 (ret_fast_syscall+0x0/0x54)
 [   28.626172] Code: eb0354bf e5957010 e3a020f4 e59f10f0 (e5973008)
 [   28.632722] ---[ end trace d2a21fc5d73a2dfd ]---

 Cc: 

[PATCH v3] ARM: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Gregory Clement gregory.clem...@free-electrons.com
Acked-by: Hans Ulli Kroll ulli.kr...@googlemail.com
Acked-by: Shawn Guo shawn...@kernel.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Imre Kaloz ka...@openwrt.org
Acked-by: Krzysztof Halasa khal...@piap.pl
Cc: Greg Ungerer g...@uclinux.org
Cc: Roland Stigge sti...@antcom.de
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Mack dan...@zonque.org
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Robert Jarzmik robert.jarz...@free.fr
Cc: Simtec Linux Team li...@simtec.co.uk
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-by: Wan ZongShun mcuos@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply just this patch to your tree.

Rob

 arch/arm/common/it8152.c |  2 +-
 arch/arm/common/locomo.c |  2 +-
 arch/arm/common/sa.c |  4 ++--
 arch/arm/mach-davinci/cp_intc.c  |  2 +-
 arch/arm/mach-dove/irq.c |  2 +-
 arch/arm/mach-ebsa110/core.c |  2 +-
 arch/arm/mach-footbridge/common.c|  2 +-
 arch/arm/mach-footbridge/isa-irq.c   |  8 
 arch/arm/mach-gemini/gpio.c  |  2 +-
 arch/arm/mach-gemini/irq.c   |  2 +-
 arch/arm/mach-imx/3ds_debugboard.c   |  2 +-
 arch/arm/mach-imx/mach-mx31ads.c |  2 +-
 arch/arm/mach-iop13xx/irq.c  |  2 +-
 arch/arm/mach-iop32x/irq.c   |  2 +-
 arch/arm/mach-iop33x/irq.c   |  2 +-
 arch/arm/mach-ixp4xx/common.c|  2 +-
 arch/arm/mach-ks8695/irq.c   |  2 +-
 arch/arm/mach-lpc32xx/irq.c  |  2 +-
 arch/arm/mach-netx/generic.c |  2 +-
 arch/arm/mach-omap1/fpga.c   |  2 +-
 arch/arm/mach-omap1/irq.c|  2 +-
 arch/arm/mach-pxa/balloon3.c |  2 +-
 arch/arm/mach-pxa/irq.c  |  1 -
 arch/arm/mach-pxa/lpd270.c   |  2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c |  2 +-
 arch/arm/mach-pxa/pxa3xx.c   |  2 +-
 arch/arm/mach-pxa/viper.c|  2 +-
 arch/arm/mach-pxa/zeus.c |  2 +-
 arch/arm/mach-rpc/ecard.c|  2 +-
 arch/arm/mach-rpc/irq.c  | 16 
 arch/arm/mach-s3c24xx/bast-irq.c |  2 +-
 arch/arm/mach-s3c64xx/common.c   |  2 +-
 arch/arm/mach-sa1100/neponset.c  |  4 ++--
 arch/arm/mach-w90x900/irq.c  |  2 +-
 drivers/irqchip/irq-sa11x0.c |  1 -
 35 files changed, 45 insertions(+), 47 deletions(-)

diff --git a/arch/arm/common/it8152.c b/arch/arm/common/it8152.c
index 5114b68..96dabcb 100644
--- a/arch/arm/common/it8152.c
+++ b/arch/arm/common/it8152.c
@@ -91,7 +91,7 @@ void it8152_init_irq(void)
for (irq = IT8152_IRQ(0); irq = IT8152_LAST_IRQ; irq++) {
irq_set_chip_and_handler(irq, it8152_irq_chip,
 handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..339fc41 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -205,7 +205,7 @@ static void locomo_setup_irq(struct locomo *lchip)
for ( ; irq = lchip-irq_base + 3; irq++) {
irq_set_chip_and_handler(irq, locomo_chip, handle_level_irq);
irq_set_chip_data(irq, lchip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }

diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 93ee70d..680374d 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -486,7 +486,7 @@ static int sa_setup_irq(struct sa *sachip, unsigned 
irq_base)
irq_set_chip_and_handler(irq, sa_low_chip

[PATCH v3] PCI: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Bjorn Helgaas bhelg...@google.com
Cc: Murali Karicheri m-kariche...@ti.com
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Jingoo Han jingooh...@gmail.com
Cc: Pratyush Anand pratyush.an...@gmail.com
Cc: Simon Horman ho...@verge.net.au
Cc: Michal Simek michal.si...@xilinx.com
Cc: Sören Brinkmann soren.brinkm...@xilinx.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.

Rob

 drivers/pci/host/pci-dra7xx.c  | 1 -
 drivers/pci/host/pci-keystone-dw.c | 2 --
 drivers/pci/host/pci-tegra.c   | 1 -
 drivers/pci/host/pci-xgene-msi.c   | 1 -
 drivers/pci/host/pcie-designware.c | 1 -
 drivers/pci/host/pcie-rcar.c   | 1 -
 drivers/pci/host/pcie-xilinx.c | 2 --
 7 files changed, 9 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 80db09e..1a0d124 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -155,7 +155,6 @@ static int dra7xx_pcie_intx_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, dummy_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host/pci-keystone-dw.c 
b/drivers/pci/host/pci-keystone-dw.c
index f34892e..f1d0749 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -196,7 +196,6 @@ static int ks_dw_pcie_msi_map(struct irq_domain *domain, 
unsigned int irq,
irq_set_chip_and_handler(irq, ks_dw_pcie_msi_irq_chip,
 handle_level_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
@@ -277,7 +276,6 @@ static int ks_dw_pcie_init_legacy_irq_map(struct irq_domain 
*d,
irq_set_chip_and_handler(irq, ks_dw_pcie_legacy_irq_chip,
 handle_level_irq);
irq_set_chip_data(irq, d-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 10c0571..81df0c1 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1248,7 +1248,6 @@ static int tegra_msi_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, tegra_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

tegra_cpuidle_pcie_irqs_in_use();

diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
index 2d31d4d..8e559d1 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -223,7 +223,6 @@ static int xgene_irq_domain_alloc(struct irq_domain 
*domain, unsigned int virq,
irq_domain_set_info(domain, virq, msi_irq,
xgene_msi_bottom_irq_chip, domain-host_data,
handle_simple_irq, NULL, NULL);
-   set_irq_flags(virq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 69486be..5c6b562 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -350,7 +350,6 @@ static int dw_pcie_msi_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, dw_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index c086210..7678fe0 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -664,7 +664,6 @@ static int rcar_msi_map(struct irq_domain *domain, unsigned 
int irq,
 {
irq_set_chip_and_handler(irq, rcar_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data

[PATCH v3] mfd: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Lee Jones lee.jo...@linaro.org
Acked-by: Linus Walleij linus.wall...@linaro.org
Cc: Milo Kim milo@ti.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: Andy Gross agr...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: patc...@opensource.wolfsonmicro.com
Cc: linux-arm-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.

Rob

 drivers/mfd/88pm860x-core.c |  4 
 drivers/mfd/ab8500-core.c   |  4 
 drivers/mfd/arizona-irq.c   |  7 ---
 drivers/mfd/asic3.c |  4 ++--
 drivers/mfd/db8500-prcmu.c  |  1 -
 drivers/mfd/ezx-pcap.c  |  6 +-
 drivers/mfd/htc-egpio.c |  4 ++--
 drivers/mfd/htc-i2cpld.c|  6 +-
 drivers/mfd/lp8788-irq.c|  5 -
 drivers/mfd/max8925-core.c  |  5 +
 drivers/mfd/max8997-irq.c   |  5 +
 drivers/mfd/max8998-irq.c   |  5 +
 drivers/mfd/mt6397-core.c   |  4 
 drivers/mfd/pm8921-core.c   |  5 +
 drivers/mfd/rc5t583-irq.c   |  4 +---
 drivers/mfd/stmpe.c |  7 ---
 drivers/mfd/t7l66xb.c   |  6 --
 drivers/mfd/tc3589x.c   |  7 ---
 drivers/mfd/tc6393xb.c  |  4 ++--
 drivers/mfd/tps6586x.c  |  7 ---
 drivers/mfd/tps65912-irq.c  |  8 +---
 drivers/mfd/twl4030-irq.c   | 11 +--
 drivers/mfd/twl6030-irq.c   | 13 -
 drivers/mfd/ucb1x00-core.c  |  2 +-
 drivers/mfd/wm831x-irq.c|  7 ---
 drivers/mfd/wm8350-irq.c|  8 +---
 drivers/mfd/wm8994-irq.c|  7 ---
 27 files changed, 17 insertions(+), 139 deletions(-)

diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index e03b7f4..bc0f3c0 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -558,11 +558,7 @@ static int pm860x_irq_domain_map(struct irq_domain *d, 
unsigned int virq,
irq_set_chip_data(virq, d-host_data);
irq_set_chip_and_handler(virq, pm860x_irq_chip, handle_edge_irq);
irq_set_nested_thread(virq, 1);
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif
return 0;
 }

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 000da72..fefbe4c 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -565,11 +565,7 @@ static int ab8500_irq_map(struct irq_domain *d, unsigned 
int virq,
irq_set_chip_and_handler(virq, ab8500_irq_chip,
handle_simple_irq);
irq_set_nested_thread(virq, 1);
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif

return 0;
 }
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 2b9965d5..7d66aec 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -174,14 +174,7 @@ static int arizona_irq_map(struct irq_domain *h, unsigned 
int virq,
irq_set_chip_data(virq, data);
irq_set_chip_and_handler(virq, arizona_irq_chip, handle_simple_irq);
irq_set_nested_thread(virq, 1);
-
-   /* ARM needs us to explicitly flag the IRQ as valid
-* and will set them noprobe when we do so. */
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif

return 0;
 }
diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
index 120df5c..4b54128 100644
--- a/drivers/mfd/asic3.c
+++ b/drivers/mfd/asic3.c
@@ -411,7 +411,7 @@ static int __init asic3_irq_probe(struct platform_device 
*pdev)

irq_set_chip_data(irq, asic);
irq_set_handler(irq, handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}

asic3_write_register(asic, ASIC3_OFFSET(INTR, INT_MASK),
@@ -431,7 +431,7 @@ static void asic3_irq_remove(struct platform_device *pdev)
irq_base = asic-irq_base;

for (irq = irq_base; irq  irq_base + ASIC3_NR_IRQS; irq++) {
-   set_irq_flags(irq, 0

[PATCH v3] memory: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Acked-by: Roger Quadros rog...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.

Rob

 drivers/memory/omap-gpmc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 3a27a84..9722099 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1176,8 +1176,8 @@ static int gpmc_setup_irq(void)
gpmc_client_irq[i].irq = gpmc_irq_start + i;
irq_set_chip_and_handler(gpmc_client_irq[i].irq,
gpmc_irq_chip, handle_simple_irq);
-   set_irq_flags(gpmc_client_irq[i].irq,
-   IRQF_VALID | IRQF_NOAUTOEN);
+   irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
+ IRQ_NOAUTOEN);
}

/* Disable interrupts */
@@ -1200,7 +1200,6 @@ static int gpmc_free_irq(void)
for (i = 0; i  GPMC_NR_IRQ; i++) {
irq_set_handler(gpmc_client_irq[i].irq, NULL);
irq_set_chip(gpmc_client_irq[i].irq, no_irq_chip);
-   irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
}

irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
--
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 08/13] mfd: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Lee Jones lee.jo...@linaro.org
Acked-by: Linus Walleij linus.wall...@linaro.org
Cc: Milo Kim milo@ti.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: Andy Gross agr...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: patc...@opensource.wolfsonmicro.com
Cc: linux-arm-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
 drivers/mfd/88pm860x-core.c |  4 
 drivers/mfd/ab8500-core.c   |  4 
 drivers/mfd/arizona-irq.c   |  7 ---
 drivers/mfd/asic3.c |  4 ++--
 drivers/mfd/db8500-prcmu.c  |  1 -
 drivers/mfd/ezx-pcap.c  |  6 +-
 drivers/mfd/htc-egpio.c |  4 ++--
 drivers/mfd/htc-i2cpld.c|  6 +-
 drivers/mfd/lp8788-irq.c|  5 -
 drivers/mfd/max8925-core.c  |  5 +
 drivers/mfd/max8997-irq.c   |  5 +
 drivers/mfd/max8998-irq.c   |  5 +
 drivers/mfd/mt6397-core.c   |  4 
 drivers/mfd/pm8921-core.c   |  5 +
 drivers/mfd/rc5t583-irq.c   |  4 +---
 drivers/mfd/stmpe.c |  7 ---
 drivers/mfd/t7l66xb.c   |  6 --
 drivers/mfd/tc3589x.c   |  7 ---
 drivers/mfd/tc6393xb.c  |  4 ++--
 drivers/mfd/tps6586x.c  |  7 ---
 drivers/mfd/tps65912-irq.c  |  8 +---
 drivers/mfd/twl4030-irq.c   | 11 +--
 drivers/mfd/twl6030-irq.c   | 13 -
 drivers/mfd/ucb1x00-core.c  |  2 +-
 drivers/mfd/wm831x-irq.c|  7 ---
 drivers/mfd/wm8350-irq.c|  8 +---
 drivers/mfd/wm8994-irq.c|  7 ---
 27 files changed, 17 insertions(+), 139 deletions(-)

diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index e03b7f4..bc0f3c0 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -558,11 +558,7 @@ static int pm860x_irq_domain_map(struct irq_domain *d, 
unsigned int virq,
irq_set_chip_data(virq, d-host_data);
irq_set_chip_and_handler(virq, pm860x_irq_chip, handle_edge_irq);
irq_set_nested_thread(virq, 1);
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif
return 0;
 }
 
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 000da72..fefbe4c 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -565,11 +565,7 @@ static int ab8500_irq_map(struct irq_domain *d, unsigned 
int virq,
irq_set_chip_and_handler(virq, ab8500_irq_chip,
handle_simple_irq);
irq_set_nested_thread(virq, 1);
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif
 
return 0;
 }
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 2b9965d5..7d66aec 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -174,14 +174,7 @@ static int arizona_irq_map(struct irq_domain *h, unsigned 
int virq,
irq_set_chip_data(virq, data);
irq_set_chip_and_handler(virq, arizona_irq_chip, handle_simple_irq);
irq_set_nested_thread(virq, 1);
-
-   /* ARM needs us to explicitly flag the IRQ as valid
-* and will set them noprobe when we do so. */
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif
 
return 0;
 }
diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
index 120df5c..4b54128 100644
--- a/drivers/mfd/asic3.c
+++ b/drivers/mfd/asic3.c
@@ -411,7 +411,7 @@ static int __init asic3_irq_probe(struct platform_device 
*pdev)
 
irq_set_chip_data(irq, asic);
irq_set_handler(irq, handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 
asic3_write_register(asic, ASIC3_OFFSET(INTR, INT_MASK),
@@ -431,7 +431,7 @@ static void asic3_irq_remove(struct platform_device *pdev)
irq_base = asic-irq_base;
 
for (irq = irq_base; irq  irq_base + ASIC3_NR_IRQS; irq++) {
-   set_irq_flags(irq, 0);
+   irq_set_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
irq_set_chip_and_handler(irq, NULL, NULL

[PATCH v2 09/13] PCI: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Bjorn Helgaas bhelg...@google.com
Cc: Murali Karicheri m-kariche...@ti.com
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Jingoo Han jingooh...@gmail.com
Cc: Pratyush Anand pratyush.an...@gmail.com
Cc: Simon Horman ho...@verge.net.au
Cc: Michal Simek michal.si...@xilinx.com
Cc: Sören Brinkmann soren.brinkm...@xilinx.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
v2:
- Add xgene which was added in v4.2

 drivers/pci/host/pci-dra7xx.c  | 1 -
 drivers/pci/host/pci-keystone-dw.c | 2 --
 drivers/pci/host/pci-tegra.c   | 1 -
 drivers/pci/host/pci-xgene-msi.c   | 1 -
 drivers/pci/host/pcie-designware.c | 1 -
 drivers/pci/host/pcie-rcar.c   | 1 -
 drivers/pci/host/pcie-xilinx.c | 2 --
 7 files changed, 9 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 80db09e..1a0d124 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -155,7 +155,6 @@ static int dra7xx_pcie_intx_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, dummy_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host/pci-keystone-dw.c 
b/drivers/pci/host/pci-keystone-dw.c
index f34892e..f1d0749 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -196,7 +196,6 @@ static int ks_dw_pcie_msi_map(struct irq_domain *domain, 
unsigned int irq,
irq_set_chip_and_handler(irq, ks_dw_pcie_msi_irq_chip,
 handle_level_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
@@ -277,7 +276,6 @@ static int ks_dw_pcie_init_legacy_irq_map(struct irq_domain 
*d,
irq_set_chip_and_handler(irq, ks_dw_pcie_legacy_irq_chip,
 handle_level_irq);
irq_set_chip_data(irq, d-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 10c0571..81df0c1 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1248,7 +1248,6 @@ static int tegra_msi_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, tegra_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

tegra_cpuidle_pcie_irqs_in_use();

diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
index 2d31d4d..8e559d1 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -223,7 +223,6 @@ static int xgene_irq_domain_alloc(struct irq_domain 
*domain, unsigned int virq,
irq_domain_set_info(domain, virq, msi_irq,
xgene_msi_bottom_irq_chip, domain-host_data,
handle_simple_irq, NULL, NULL);
-   set_irq_flags(virq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 69486be..5c6b562 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -350,7 +350,6 @@ static int dw_pcie_msi_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, dw_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index c086210..7678fe0 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -664,7 +664,6 @@ static int rcar_msi_map(struct irq_domain *domain, unsigned 
int irq,
 {
irq_set_chip_and_handler(irq, rcar_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);

return 0;
 }
diff --git a/drivers/pci/host

[PATCH v2 01/13] ARM: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Gregory Clement gregory.clem...@free-electrons.com
Acked-by: Hans Ulli Kroll ulli.kr...@googlemail.com
Cc: Shawn Guo shawn@linaro.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Imre Kaloz ka...@openwrt.org
Acked-by: Krzysztof Halasa khal...@piap.pl
Cc: Greg Ungerer g...@uclinux.org
Cc: Roland Stigge sti...@antcom.de
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Mack dan...@zonque.org
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Robert Jarzmik robert.jarz...@free.fr
Cc: Simtec Linux Team li...@simtec.co.uk
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-by: Wan ZongShun mcuos@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
---
 arch/arm/common/it8152.c |  2 +-
 arch/arm/common/locomo.c |  2 +-
 arch/arm/common/sa.c |  4 ++--
 arch/arm/mach-davinci/cp_intc.c  |  2 +-
 arch/arm/mach-dove/irq.c |  2 +-
 arch/arm/mach-ebsa110/core.c |  2 +-
 arch/arm/mach-footbridge/common.c|  2 +-
 arch/arm/mach-footbridge/isa-irq.c   |  8 
 arch/arm/mach-gemini/gpio.c  |  2 +-
 arch/arm/mach-gemini/irq.c   |  2 +-
 arch/arm/mach-imx/3ds_debugboard.c   |  2 +-
 arch/arm/mach-imx/mach-mx31ads.c |  2 +-
 arch/arm/mach-iop13xx/irq.c  |  2 +-
 arch/arm/mach-iop32x/irq.c   |  2 +-
 arch/arm/mach-iop33x/irq.c   |  2 +-
 arch/arm/mach-ixp4xx/common.c|  2 +-
 arch/arm/mach-ks8695/irq.c   |  2 +-
 arch/arm/mach-lpc32xx/irq.c  |  2 +-
 arch/arm/mach-netx/generic.c |  2 +-
 arch/arm/mach-omap1/fpga.c   |  2 +-
 arch/arm/mach-omap1/irq.c|  2 +-
 arch/arm/mach-pxa/balloon3.c |  2 +-
 arch/arm/mach-pxa/irq.c  |  1 -
 arch/arm/mach-pxa/lpd270.c   |  2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c |  2 +-
 arch/arm/mach-pxa/pxa3xx.c   |  2 +-
 arch/arm/mach-pxa/viper.c|  2 +-
 arch/arm/mach-pxa/zeus.c |  2 +-
 arch/arm/mach-rpc/ecard.c|  2 +-
 arch/arm/mach-rpc/irq.c  | 16 
 arch/arm/mach-s3c24xx/bast-irq.c |  2 +-
 arch/arm/mach-s3c64xx/common.c   |  2 +-
 arch/arm/mach-sa1100/neponset.c  |  4 ++--
 arch/arm/mach-w90x900/irq.c  |  2 +-
 drivers/irqchip/irq-sa11x0.c |  1 -
 35 files changed, 45 insertions(+), 47 deletions(-)

diff --git a/arch/arm/common/it8152.c b/arch/arm/common/it8152.c
index 5114b68..96dabcb 100644
--- a/arch/arm/common/it8152.c
+++ b/arch/arm/common/it8152.c
@@ -91,7 +91,7 @@ void it8152_init_irq(void)
for (irq = IT8152_IRQ(0); irq = IT8152_LAST_IRQ; irq++) {
irq_set_chip_and_handler(irq, it8152_irq_chip,
 handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }
 
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..339fc41 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -205,7 +205,7 @@ static void locomo_setup_irq(struct locomo *lchip)
for ( ; irq = lchip-irq_base + 3; irq++) {
irq_set_chip_and_handler(irq, locomo_chip, handle_level_irq);
irq_set_chip_data(irq, lchip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }
 
diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 93ee70d..680374d 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -486,7 +486,7 @@ static int sa_setup_irq(struct sa *sachip, unsigned 
irq_base)
irq_set_chip_and_handler(irq, sa_low_chip,
 handle_edge_irq);
irq_set_chip_data(irq, sachip

[PATCH v2 07/13] memory: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Acked-by: Roger Quadros rog...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
---
 drivers/memory/omap-gpmc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 8911e51..dde6f4dd 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1176,8 +1176,8 @@ static int gpmc_setup_irq(void)
gpmc_client_irq[i].irq = gpmc_irq_start + i;
irq_set_chip_and_handler(gpmc_client_irq[i].irq,
gpmc_irq_chip, handle_simple_irq);
-   set_irq_flags(gpmc_client_irq[i].irq,
-   IRQF_VALID | IRQF_NOAUTOEN);
+   irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
+ IRQ_NOAUTOEN);
}
 
/* Disable interrupts */
@@ -1200,7 +1200,6 @@ static int gpmc_free_irq(void)
for (i = 0; i  GPMC_NR_IRQ; i++) {
irq_set_handler(gpmc_client_irq[i].irq, NULL);
irq_set_chip(gpmc_client_irq[i].irq, no_irq_chip);
-   irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
}
 
irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision

[Rob Herring]

On Mon, Jul 6, 2015 at 11:20 AM, Pali Rohár pali.ro...@gmail.com wrote:
 On Monday 06 July 2015 17:22:58 Rob Herring wrote:
 On Mon, Jul 6, 2015 at 8:12 AM, Pali Rohár pali.ro...@gmail.com wrote:
  On Monday 06 July 2015 14:31:27 Tony Lindgren wrote:
  * Pali Rohár pali.ro...@gmail.com [150706 05:25]:
   into which file should I put documentation about new DT
   properties?
 
  If it's Linux generic like linux,revision, then how about
  Documentation/devicetree/bindings/revision.txt?
 
  For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt?
 
  Regards,
 
  Tony
 
  Hm... now I'm thinking into which DT field should I put atags and
  revision. In previous emails you wrote to use linux,atags, now
  arm,atags? And put them into root node? Or other?
 
  In arch/arm/boot/compressed/atags_to_fdt.c code I see that most
  atag properties are converted into /chosen node in DT...
 
  So what do you prefer for revision and what for atags?
 
  Some mentioned examples:
 
  /revision

 This one. This is a top level h/w property.

  /chosen/revision
  /linux,revision
  /chosen/linux,revision
  ...
 
  /atags
  /chosen/atags
  /linux,atags
  /chosen/linux,atags

 This one. ATAGs are a Linux data struct.

 Rob


 Ok, and how read that property /chosen/linux,atags in function
 setup_machine_fdt() from file arch/arm/kernel/devtree.c ?

 of_get_flat_dt_prop() cannot be used unless somebody get me offset to
 node /chosen...

Why can't you get the offset yourself?

However, why does this need to be early? It is only used to populate
/proc, right?

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision

[Rob Herring]

On Mon, Jul 6, 2015 at 7:31 AM, Tony Lindgren t...@atomide.com wrote:
 * Pali Rohár pali.ro...@gmail.com [150706 05:25]:

 into which file should I put documentation about new DT properties?

 If it's Linux generic like linux,revision, then how about

Just revision at the top level please. I'd prefer a string still,
but either is fine.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision

[Rob Herring]

On Mon, Jul 6, 2015 at 8:12 AM, Pali Rohár pali.ro...@gmail.com wrote:
 On Monday 06 July 2015 14:31:27 Tony Lindgren wrote:
 * Pali Rohár pali.ro...@gmail.com [150706 05:25]:
  into which file should I put documentation about new DT properties?

 If it's Linux generic like linux,revision, then how about
 Documentation/devicetree/bindings/revision.txt?

 For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt?

 Regards,

 Tony

 Hm... now I'm thinking into which DT field should I put atags and
 revision. In previous emails you wrote to use linux,atags, now
 arm,atags? And put them into root node? Or other?

 In arch/arm/boot/compressed/atags_to_fdt.c code I see that most atag
 properties are converted into /chosen node in DT...

 So what do you prefer for revision and what for atags?

 Some mentioned examples:

 /revision

This one. This is a top level h/w property.

 /chosen/revision
 /linux,revision
 /chosen/linux,revision
 ...

 /atags
 /chosen/atags
 /linux,atags
 /chosen/linux,atags

This one. ATAGs are a Linux data struct.

Rob

 /arm,atags
 /chosen/arm,atags
 ...

 --
 Pali Rohár
 pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/15] PCI: kill off set_irq_flags usage

[Rob Herring]

On Thu, Jun 18, 2015 at 11:59 AM, Bjorn Helgaas bhelg...@google.com wrote:
 On Tue, Jun 09, 2015 at 01:26:36PM -0500, Rob Herring wrote:
 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Kishon Vijay Abraham I kis...@ti.com
 Cc: Bjorn Helgaas bhelg...@google.com
 Cc: Murali Karicheri m-kariche...@ti.com
 Cc: Thierry Reding thierry.red...@gmail.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Alexandre Courbot gnu...@gmail.com
 Cc: Jingoo Han jingooh...@gmail.com
 Cc: Pratyush Anand pratyush.an...@gmail.com
 Cc: Simon Horman ho...@verge.net.au
 Cc: Michal Simek michal.si...@xilinx.com
 Cc: Sören Brinkmann soren.brinkm...@xilinx.com
 Cc: linux-omap@vger.kernel.org
 Cc: linux-...@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-te...@vger.kernel.org
 Cc: linux...@vger.kernel.org

 This is the only part of the series on linux-pci, so I assume this will be
 merged by somebody else along with the rest.

I copied you on the intro, but all the lists and all the maintainers
was too long to cc. Being late in the cycle I didn't really intend for
this to be for 4.2, but you can pick up this patch if you want to as
it doesn't have any dependencies. If you don't, then I will submit the
whole series for 4.3.

 Acked-by: Bjorn Helgaas bhelg...@google.com

Thanks.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/15] ARM: kill off set_irq_flags usage

[Rob Herring]

On Fri, Jun 12, 2015 at 9:05 AM, Hans Ulli Kroll
ulli.kr...@googlemail.com wrote:


 On Tue, 9 Jun 2015, Rob Herring wrote:

 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.


 for mach-gemini
 Signed-off-by: Hans Ulli Kroll ulli.kr...@googlemail.com

You mean acked-by, right?

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/15] memory: kill off set_irq_flags usage

[Rob Herring]

On Thu, Jun 11, 2015 at 7:18 AM, Roger Quadros rog...@ti.com wrote:
 Rob,

 On Tue, 9 Jun 2015 13:26:34 -0500
 Rob Herring r...@kernel.org wrote:

 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Roger Quadros rog...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: linux-omap@vger.kernel.org
 ---
  drivers/memory/omap-gpmc.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

 diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
 index c94ea0d..0c833e2 100644
 --- a/drivers/memory/omap-gpmc.c
 +++ b/drivers/memory/omap-gpmc.c
 @@ -1176,8 +1176,8 @@ static int gpmc_setup_irq(void)
   gpmc_client_irq[i].irq = gpmc_irq_start + i;
   irq_set_chip_and_handler(gpmc_client_irq[i].irq,
   gpmc_irq_chip, handle_simple_irq);
 - set_irq_flags(gpmc_client_irq[i].irq,
 - IRQF_VALID | IRQF_NOAUTOEN);
 + irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
 +   IRQ_NOAUTOEN);

 Shouldn't this be
 irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
   IRQ_NOAUTOEN | IRQ_NOPROBE);
 ?

Only if this needs to work on !ARM. The default for ARM is IRQ_NOPROBE set.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/15] PCI: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Murali Karicheri m-kariche...@ti.com
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Jingoo Han jingooh...@gmail.com
Cc: Pratyush Anand pratyush.an...@gmail.com
Cc: Simon Horman ho...@verge.net.au
Cc: Michal Simek michal.si...@xilinx.com
Cc: Sören Brinkmann soren.brinkm...@xilinx.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
 drivers/pci/host/pci-dra7xx.c  | 1 -
 drivers/pci/host/pci-keystone-dw.c | 2 --
 drivers/pci/host/pci-tegra.c   | 1 -
 drivers/pci/host/pcie-designware.c | 1 -
 drivers/pci/host/pcie-rcar.c   | 1 -
 drivers/pci/host/pcie-xilinx.c | 2 --
 6 files changed, 8 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 2d57e19..94cbc4d 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -160,7 +160,6 @@ static int dra7xx_pcie_intx_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, dummy_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);
 
return 0;
 }
diff --git a/drivers/pci/host/pci-keystone-dw.c 
b/drivers/pci/host/pci-keystone-dw.c
index f34892e..f1d0749 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -196,7 +196,6 @@ static int ks_dw_pcie_msi_map(struct irq_domain *domain, 
unsigned int irq,
irq_set_chip_and_handler(irq, ks_dw_pcie_msi_irq_chip,
 handle_level_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);
 
return 0;
 }
@@ -277,7 +276,6 @@ static int ks_dw_pcie_init_legacy_irq_map(struct irq_domain 
*d,
irq_set_chip_and_handler(irq, ks_dw_pcie_legacy_irq_chip,
 handle_level_irq);
irq_set_chip_data(irq, d-host_data);
-   set_irq_flags(irq, IRQF_VALID);
 
return 0;
 }
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 00e9272..36bd700 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1263,7 +1263,6 @@ static int tegra_msi_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, tegra_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);
 
tegra_cpuidle_pcie_irqs_in_use();
 
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 2e9f84f..5caa94d 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -333,7 +333,6 @@ static int dw_pcie_msi_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, dw_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);
 
return 0;
 }
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index c086210..7678fe0 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -664,7 +664,6 @@ static int rcar_msi_map(struct irq_domain *domain, unsigned 
int irq,
 {
irq_set_chip_and_handler(irq, rcar_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);
 
return 0;
 }
diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index f1a06a0..72015119 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -338,7 +338,6 @@ static int xilinx_pcie_msi_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, xilinx_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-   set_irq_flags(irq, IRQF_VALID);
 
return 0;
 }
@@ -377,7 +376,6 @@ static int xilinx_pcie_intx_map(struct irq_domain *domain, 
unsigned int irq,
 {
irq_set_chip_and_handler(irq, dummy_irq_chip, handle_simple_irq

[PATCH 01/15] ARM: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Gregory Clement gregory.clem...@free-electrons.com
Cc: Hans Ulli Kroll ulli.kr...@googlemail.com
Cc: Shawn Guo shawn@linaro.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Imre Kaloz ka...@openwrt.org
Cc: Krzysztof Halasa khal...@piap.pl
Cc: Greg Ungerer g...@uclinux.org
Cc: Roland Stigge sti...@antcom.de
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Mack dan...@zonque.org
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Robert Jarzmik robert.jarz...@free.fr
Cc: Simtec Linux Team li...@simtec.co.uk
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Wan ZongShun mcuos@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
---
 arch/arm/common/it8152.c |  2 +-
 arch/arm/common/locomo.c |  2 +-
 arch/arm/common/sa.c |  4 ++--
 arch/arm/mach-davinci/cp_intc.c  |  2 +-
 arch/arm/mach-dove/irq.c |  2 +-
 arch/arm/mach-ebsa110/core.c |  2 +-
 arch/arm/mach-footbridge/common.c|  2 +-
 arch/arm/mach-footbridge/isa-irq.c   |  8 
 arch/arm/mach-gemini/gpio.c  |  2 +-
 arch/arm/mach-gemini/irq.c   |  2 +-
 arch/arm/mach-imx/3ds_debugboard.c   |  2 +-
 arch/arm/mach-imx/mach-mx31ads.c |  2 +-
 arch/arm/mach-iop13xx/irq.c  |  2 +-
 arch/arm/mach-iop32x/irq.c   |  2 +-
 arch/arm/mach-iop33x/irq.c   |  2 +-
 arch/arm/mach-ixp4xx/common.c|  2 +-
 arch/arm/mach-ks8695/irq.c   |  2 +-
 arch/arm/mach-lpc32xx/irq.c  |  2 +-
 arch/arm/mach-netx/generic.c |  2 +-
 arch/arm/mach-omap1/fpga.c   |  2 +-
 arch/arm/mach-omap1/irq.c|  2 +-
 arch/arm/mach-pxa/balloon3.c |  2 +-
 arch/arm/mach-pxa/irq.c  |  1 -
 arch/arm/mach-pxa/lpd270.c   |  2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c |  2 +-
 arch/arm/mach-pxa/pxa3xx.c   |  2 +-
 arch/arm/mach-pxa/viper.c|  2 +-
 arch/arm/mach-pxa/zeus.c |  2 +-
 arch/arm/mach-rpc/ecard.c|  2 +-
 arch/arm/mach-rpc/irq.c  | 16 
 arch/arm/mach-s3c24xx/bast-irq.c |  2 +-
 arch/arm/mach-s3c64xx/common.c   |  2 +-
 arch/arm/mach-sa1100/irq.c   |  1 -
 arch/arm/mach-sa1100/neponset.c  |  4 ++--
 arch/arm/mach-w90x900/irq.c  |  2 +-
 35 files changed, 45 insertions(+), 47 deletions(-)

diff --git a/arch/arm/common/it8152.c b/arch/arm/common/it8152.c
index 5114b68..96dabcb 100644
--- a/arch/arm/common/it8152.c
+++ b/arch/arm/common/it8152.c
@@ -91,7 +91,7 @@ void it8152_init_irq(void)
for (irq = IT8152_IRQ(0); irq = IT8152_LAST_IRQ; irq++) {
irq_set_chip_and_handler(irq, it8152_irq_chip,
 handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }
 
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..339fc41 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -205,7 +205,7 @@ static void locomo_setup_irq(struct locomo *lchip)
for ( ; irq = lchip-irq_base + 3; irq++) {
irq_set_chip_and_handler(irq, locomo_chip, handle_level_irq);
irq_set_chip_data(irq, lchip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }
 
diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 5cc779c..139aa3c 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -486,7 +486,7 @@ static int sa_setup_irq(struct sa *sachip, unsigned 
irq_base)
irq_set_chip_and_handler(irq, sa_low_chip,
 handle_edge_irq);
irq_set_chip_data(irq, sachip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE

[PATCH 08/15] memory: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Roger Quadros rog...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
---
 drivers/memory/omap-gpmc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index c94ea0d..0c833e2 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1176,8 +1176,8 @@ static int gpmc_setup_irq(void)
gpmc_client_irq[i].irq = gpmc_irq_start + i;
irq_set_chip_and_handler(gpmc_client_irq[i].irq,
gpmc_irq_chip, handle_simple_irq);
-   set_irq_flags(gpmc_client_irq[i].irq,
-   IRQF_VALID | IRQF_NOAUTOEN);
+   irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
+ IRQ_NOAUTOEN);
}
 
/* Disable interrupts */
@@ -1200,7 +1200,6 @@ static int gpmc_free_irq(void)
for (i = 0; i  GPMC_NR_IRQ; i++) {
irq_set_handler(gpmc_client_irq[i].irq, NULL);
irq_set_chip(gpmc_client_irq[i].irq, no_irq_chip);
-   irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
}
 
irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/15] mfd: kill off set_irq_flags usage

[Rob Herring]

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Milo Kim milo@ti.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: Andy Gross agr...@codeaurora.org
Cc: David Brown dav...@codeaurora.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: patc...@opensource.wolfsonmicro.com
Cc: linux-arm-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
 drivers/mfd/88pm860x-core.c |  4 
 drivers/mfd/ab8500-core.c   |  4 
 drivers/mfd/arizona-irq.c   |  7 ---
 drivers/mfd/asic3.c |  4 ++--
 drivers/mfd/db8500-prcmu.c  |  1 -
 drivers/mfd/ezx-pcap.c  |  6 +-
 drivers/mfd/htc-egpio.c |  4 ++--
 drivers/mfd/htc-i2cpld.c|  6 +-
 drivers/mfd/lp8788-irq.c|  5 -
 drivers/mfd/max8925-core.c  |  5 +
 drivers/mfd/max8997-irq.c   |  5 +
 drivers/mfd/max8998-irq.c   |  5 +
 drivers/mfd/mt6397-core.c   |  4 
 drivers/mfd/pm8921-core.c   |  5 +
 drivers/mfd/rc5t583-irq.c   |  4 +---
 drivers/mfd/stmpe.c |  7 ---
 drivers/mfd/t7l66xb.c   |  6 --
 drivers/mfd/tc3589x.c   |  7 ---
 drivers/mfd/tc6393xb.c  |  4 ++--
 drivers/mfd/tps6586x.c  |  7 ---
 drivers/mfd/tps65912-irq.c  |  8 +---
 drivers/mfd/twl4030-irq.c   | 11 +--
 drivers/mfd/twl6030-irq.c   | 13 -
 drivers/mfd/ucb1x00-core.c  |  2 +-
 drivers/mfd/wm831x-irq.c|  7 ---
 drivers/mfd/wm8350-irq.c|  8 +---
 drivers/mfd/wm8994-irq.c|  7 ---
 27 files changed, 17 insertions(+), 139 deletions(-)

diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index d2a85cd..17984d65 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -558,11 +558,7 @@ static int pm860x_irq_domain_map(struct irq_domain *d, 
unsigned int virq,
irq_set_chip_data(virq, d-host_data);
irq_set_chip_and_handler(virq, pm860x_irq_chip, handle_edge_irq);
irq_set_nested_thread(virq, 1);
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif
return 0;
 }
 
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index c80a292..24a159b 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -565,11 +565,7 @@ static int ab8500_irq_map(struct irq_domain *d, unsigned 
int virq,
irq_set_chip_and_handler(virq, ab8500_irq_chip,
handle_simple_irq);
irq_set_nested_thread(virq, 1);
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif
 
return 0;
 }
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index d063b94..d32673d 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -174,14 +174,7 @@ static int arizona_irq_map(struct irq_domain *h, unsigned 
int virq,
irq_set_chip_data(virq, data);
irq_set_chip_and_handler(virq, arizona_irq_chip, handle_simple_irq);
irq_set_nested_thread(virq, 1);
-
-   /* ARM needs us to explicitly flag the IRQ as valid
-* and will set them noprobe when we do so. */
-#ifdef CONFIG_ARM
-   set_irq_flags(virq, IRQF_VALID);
-#else
irq_set_noprobe(virq);
-#endif
 
return 0;
 }
diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
index 977bd3a..54a133c 100644
--- a/drivers/mfd/asic3.c
+++ b/drivers/mfd/asic3.c
@@ -411,7 +411,7 @@ static int __init asic3_irq_probe(struct platform_device 
*pdev)
 
irq_set_chip_data(irq, asic);
irq_set_handler(irq, handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 
asic3_write_register(asic, ASIC3_OFFSET(INTR, INT_MASK),
@@ -432,7 +432,7 @@ static void asic3_irq_remove(struct platform_device *pdev)
irq_base = asic-irq_base;
 
for (irq = irq_base; irq  irq_base + ASIC3_NR_IRQS; irq++) {
-   set_irq_flags(irq, 0);
+   irq_set_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
irq_set_chip_and_handler(irq, NULL, NULL

Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Rob Herring]

On Tue, Mar 10, 2015 at 4:27 PM, Marek Belisko ma...@goldelico.com wrote:
 Signed-off-by: Marek Belisko ma...@goldelico.com
 ---
  .../bindings/power_supply/twl4030_madc_battery.txt | 43 
 ++
  1 file changed, 43 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt

 diff --git 
 a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 new file mode 100644
 index 000..d3dd9d8
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 @@ -0,0 +1,43 @@
 +twl4030_madc_battery
 +
 +Required properties:
 + - compatible : ti,twl4030-madc-battery

Is this a sub-node of the twl4030 or something? Please define where
this fits (hint: I would expect to be a sub node of a charging
controller or battery monitor).

 + - capacity-uah : battery capacity in uAh
 + - ti,volt-to-capacity-charging-map : list of voltage(mV):level(%) values
 +   for charging calibration (see example)
 + - ti,volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
 +   for discharging calibration (see example)

These seem like properties of the battery independent of the
battery/charging controller which is the twl4030. Ideally we would
define battery nodes generically and independent of the charge
controllers. Then there are smart batteries to consider too.

Rob

 + - io-channels: Should contain IIO channel specifiers
 +   for each element in io-channel-names.
 +- io-channel-names: Should contain the following values:
 + * temp - The ADC channel for temperature reading
 + * ichg - The ADC channel for battery charging status
 + * vbat - The ADC channel to measure the battery voltage
 +
 +Example:
 +   madc-battery {
 +   compatible = ti,twl4030-madc-battery;
 +   capacity-uah = 120;
 +   ti,volt-to-capacity-charging-map = 4200 100,
 +   4100 75,
 +   4000 55,
 +   3900 25,
 +   3800 5,
 +   3700 2,
 +   3600 1,
 +   3300 0;
 +
 +   ti,volt-to-capacity-discharging-map = 4200 100
 +  4100 95,
 +  4000 70,
 +  3800 50,
 +  3700 10,
 +  3600 5,
 +  3300 0;
 +   io-channels = twl_madc 1,
 + twl_madc 10,
 + twl_madc 12;
 +   io-channel-names = temp,
 +  ichg,
 +  vbat;
 +   };
 --
 1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dtc: parser: Add label while overriding nodes

[Rob Herring]

On Thu, Jan 8, 2015 at 8:12 AM, Nikhil Devshatwar nikhil...@ti.com wrote:
 Current device tree compiler allows to define multiple labels when defining
 the device node the first time. Typically device nodes are defined in
 DTSI files. Now these nodes can be overriden for updating some of the
 properties. Typically, device nodes are overridden in DTS files.

 When working with adapter boards, most of the time adapter board can fit to
 multiple base boards. But depending on which base board it is connected to,
 the devices on the adapter board would be children of different devices.

 e.g. On dra7-evm.dts, i2c2 is exported for expansion connector whereas
 on dra72-evm.dts, i2c5 is exported for expansion connector.
 This causes a problem when writing a generic device tree file for
 the adapter board. Because, you cannot know wheather all the devices on

s/wheather/whether/

 adpter board are present on i2c or i2c5.

s/adpter/adapter/

 The problem can be solved by adding a common label (e.g. i2cexp) in both
 of the DTS files when overriding the device nodes for i2c2 or i2c5.
 This way, generic adapter board file would override the i2cexp. And
 depending on which base board you use the adpter board, all the devices

s/adpter/adapter/

 are automatically added for correct device nodes.

 Change-Id: I3ad7247a79baed7268a91fc691360aece73d6d1b

Get rid of this Gerrit nonsense.

 Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
 ---
  scripts/dtc/dtc-parser.y |   12 
  1 file changed, 12 insertions(+)

You need to send this against upstream dtc, not the copy in the kernel.

Seems like a reasonable change, but I'm not too familar with dtc source.

 diff --git a/scripts/dtc/dtc-parser.y b/scripts/dtc/dtc-parser.y
 index f412460..d9ed3b7 100644
 --- a/scripts/dtc/dtc-parser.y
 +++ b/scripts/dtc/dtc-parser.y
 @@ -145,6 +145,18 @@ devicetree:
 {
 $$ = merge_nodes($1, $3);
 }
 +
 +   | devicetree DT_LABEL DT_REF nodedef
 +   {
 +   struct node *target = get_node_by_ref($1, $3);
 +
 +   add_label(target-labels, $2);
 +   if (target)
 +   merge_nodes(target, $4);
 +   else
 +   print_error(label or path, '%s', not found, 
 $2);
 +   $$ = $1;
 +   }
 | devicetree DT_REF nodedef
 {
 struct node *target = get_node_by_ref($1, $2);
 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe devicetree in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock

[Rob Herring]

On Thu, Jan 15, 2015 at 7:55 AM, Mark Rutland mark.rutl...@arm.com wrote:
 On Thu, Jan 15, 2015 at 01:52:01PM +, Mark Rutland wrote:
 On Wed, Jan 14, 2015 at 08:58:18PM +, Suman Anna wrote:
  This patch adds the generic common bindings used to represent
  a hwlock device and use/request locks in a device-tree build.
 
  All the platform-specific hwlock driver implementations need the
  number of locks and associated base id for registering the locks
  present within the device with the driver core. This base id
  needs to be unique across multiple IP instances of a hwspinlock
  device, so that each hwlock can be represented uniquely in a
  system.
 
  The number of locks is represented by 'hwlock-num-locks' property,
  and the base id is represented by the 'hwlock-base-id' property.
  The args specifier length is dependent on each vendor-specific
  implementation and is represented through the '#hwlock-cells'
  property. Client users need to use the property 'hwlocks' for
  requesting specific lock(s).
 
  Note that the document is named hwlock.txt deliberately to keep
  it a bit more generic.
 
  Cc: Rob Herring robh...@kernel.org
  Signed-off-by: Suman Anna s-a...@ti.com
  ---
  v7: Revised binding info for hwlock-base-id, it is mandatory now
 
   .../devicetree/bindings/hwlock/hwlock.txt  | 55 
  ++
   1 file changed, 55 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
 
  diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt 
  b/Documentation/devicetree/bindings/hwlock/hwlock.txt
  new file mode 100644
  index ..8de7aaf878f9
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
  @@ -0,0 +1,55 @@
  +Generic hwlock bindings
  +===
  +
  +Generic bindings that are common to all the hwlock platform specific 
  driver
  +implementations.
  +
  +The validity and need of these common properties may vary from one 
  platform
  +implementation to another. The platform specific bindings should 
  explicitly
  +state if an optional property is used. Please also look through the 
  individual
  +platform specific hwlock binding documentations for identifying the 
  applicable
  +properties.
  +
  +Common properties:
  +- #hwlock-cells:   Specifies the number of cells needed to represent a
  +   specific lock. This property is mandatory for all
  +   platform implementations.
  +- hwlock-num-locks:Number of locks present in a hwlock device. 
  This
  +   property is needed on hwlock devices, where the number
  +   of supported locks within a hwlock device cannot be
  +   read from a register.
  +- hwlock-base-id:  An unique base Id for the locks for a particular hwlock
  +   device. This property is mandatory for all platform
  +   implementations.

 This property makes no sense. The ID encoded in the hwlock cells is
 relative to the instance (identified by phandle), not global. So the DT
 has no global ID space.

 Why do you think you need this?

 Having looked at the way this proeprty is used, NAK.

 If you need to carve up a Linux-internal ID space, do that dynamically.
 There is no need for this property.

Better yet, don't create a Linux ID space for this. Everywhere we have
one, we want to get rid of it.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/3] core: platform: fix an invalid kfree during of_platform_depopulate

[Rob Herring]

On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
 Drivers can use of_platform_populate() to create platform devices
 for children of the device main node, and a complementary API
 of_platform_depopulate() is provided to delete these child devices.
 Any platform_data supplied for the OF devices through auxdata lookup
 data is populated directly in the device's platform_data field, unlike
 those created using platform API. The of_platform_depopulate()
 leverages the platform code for cleanup, and this will result in a
 kernel oops due to an invalid kfree on this direct populated
 platform_data.

 Fix this by resetting the platform data for OF devices during
 platform device cleanup.

We should probably copy the platform_data like is done for non-OF
platform devices. I'm sure there was some reason for it. It looks
strange doing this in release.

However, I'm inclined to not fix this and force users to move off of
auxdata. That's intended to be a temporary migration path and there
are only 54 instances of it that have platform_data. What device do
you care about?

Rob


 Signed-off-by: Suman Anna s-a...@ti.com
 ---
  drivers/base/platform.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/base/platform.c b/drivers/base/platform.c
 index 9421fed40905..129e69c8c894 100644
 --- a/drivers/base/platform.c
 +++ b/drivers/base/platform.c
 @@ -200,6 +200,8 @@ static void platform_device_release(struct device *dev)
 struct platform_object *pa = container_of(dev, struct platform_object,
   pdev.dev);

 +   if (pa-pdev.dev.of_node)
 +   pa-pdev.dev.platform_data = NULL;
 of_device_node_put(pa-pdev.dev);
 kfree(pa-pdev.dev.platform_data);
 kfree(pa-pdev.mfd_cell);
 --
 2.2.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/3] of/device: manage resources similar to platform_device_add

[Rob Herring]

On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
 Drivers can use of_platform_populate() to create platform devices
 for children of the device main node, and a complementary API
 of_platform_depopulate() is provided to delete these child platform
 devices. The of_platform_depopulate() leverages the platform API
 for performing the cleanup of these devices.

 The platform device resources are managed differently between
 of_device_add and platform_device_add, and this asymmetry causes
 a kernel oops in platform_device_del during removal of the resources.
 Manage the platform device resources similar to platform_device_add
 to fix this kernel oops.

This is a known issue and has been attempted to be fixed before (I
believe there is a revert in mainline). The problem is there are known
devicetrees which have overlapping resources and they will break with
your change.

Rob


 Signed-off-by: Suman Anna s-a...@ti.com
 ---
  drivers/of/device.c | 38 +-
  1 file changed, 37 insertions(+), 1 deletion(-)

 diff --git a/drivers/of/device.c b/drivers/of/device.c
 index 46d6c75c1404..fa27c1c71f29 100644
 --- a/drivers/of/device.c
 +++ b/drivers/of/device.c
 @@ -50,6 +50,8 @@ EXPORT_SYMBOL(of_dev_put);

  int of_device_add(struct platform_device *ofdev)
  {
 +   int i, ret;
 +
 BUG_ON(ofdev-dev.of_node == NULL);

 /* name and id have to be set so that the platform bus doesn't get
 @@ -63,7 +65,41 @@ int of_device_add(struct platform_device *ofdev)
 if (!ofdev-dev.parent)
 set_dev_node(ofdev-dev, of_node_to_nid(ofdev-dev.of_node));

 -   return device_add(ofdev-dev);
 +   for (i = 0; i  ofdev-num_resources; i++) {
 +   struct resource *p, *r = ofdev-resource[i];
 +
 +   if (!r-name)
 +   r-name = dev_name(ofdev-dev);
 +
 +   p = r-parent;
 +   if (!p) {
 +   if (resource_type(r) == IORESOURCE_MEM)
 +   p = iomem_resource;
 +   else if (resource_type(r) == IORESOURCE_IO)
 +   p = ioport_resource;
 +   }
 +
 +   if (p  insert_resource(p, r)) {
 +   dev_err(ofdev-dev, failed to claim resource %d\n,
 +   i);
 +   ret = -EBUSY;
 +   goto failed;
 +   }
 +   }
 +
 +   ret = device_add(ofdev-dev);
 +   if (ret == 0)
 +   return ret;
 +
 +failed:
 +   while (--i = 0) {
 +   struct resource *r = ofdev-resource[i];
 +   unsigned long type = resource_type(r);
 +
 +   if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
 +   release_resource(r);
 +   }
 +   return ret;
  }

  int of_device_register(struct platform_device *pdev)
 --
 2.2.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/3] of/device: manage resources similar to platform_device_add

[Rob Herring]

On Tue, Jan 13, 2015 at 3:25 PM, Suman Anna s-a...@ti.com wrote:
 Hi Rob,

 On 01/13/2015 02:38 PM, Rob Herring wrote:
 On Wed, Jan 7, 2015 at 11:30 AM, Suman Anna s-a...@ti.com wrote:
 Drivers can use of_platform_populate() to create platform devices
 for children of the device main node, and a complementary API
 of_platform_depopulate() is provided to delete these child platform
 devices. The of_platform_depopulate() leverages the platform API
 for performing the cleanup of these devices.

 The platform device resources are managed differently between
 of_device_add and platform_device_add, and this asymmetry causes
 a kernel oops in platform_device_del during removal of the resources.
 Manage the platform device resources similar to platform_device_add
 to fix this kernel oops.

 This is a known issue and has been attempted to be fixed before (I
 believe there is a revert in mainline). The problem is there are known
 devicetrees which have overlapping resources and they will break with
 your change.

 Are you referring to 02bbde7849e6 (Revert of: use
 platform_device_add)?

I believe that's the one.

 That one seems to be in registration path, and
 this crash is in the unregistration path. If so, to fix the crash,
 should we be skipping the release_resource() for now in
 platform_device_del for DT nodes, or replace platform_device_unregister
 with of_device_unregister in of_platform_device_destroy()?

IIRC, the problem is inserting a resource twice on add from 2
different nodes, not the removal path. Perhaps we could make a
collision non-fatal for in the DT case. Grant may have some ideas on
what's needed here.

 This is a common crash and we cannot use of_platform_depopulate() today
 in drivers to complement of_platform_populate().

Yes, I know.

 Also, the platform_data crash is independent of this, I could reproduce
 that one even with using of_device_unregister in a loop in driver remove.

Missed this one. I'll reply to that patch.

Rob


 regards
 Suman


 Rob


 Signed-off-by: Suman Anna s-a...@ti.com
 ---
  drivers/of/device.c | 38 +-
  1 file changed, 37 insertions(+), 1 deletion(-)

 diff --git a/drivers/of/device.c b/drivers/of/device.c
 index 46d6c75c1404..fa27c1c71f29 100644
 --- a/drivers/of/device.c
 +++ b/drivers/of/device.c
 @@ -50,6 +50,8 @@ EXPORT_SYMBOL(of_dev_put);

  int of_device_add(struct platform_device *ofdev)
  {
 +   int i, ret;
 +
 BUG_ON(ofdev-dev.of_node == NULL);

 /* name and id have to be set so that the platform bus doesn't get
 @@ -63,7 +65,41 @@ int of_device_add(struct platform_device *ofdev)
 if (!ofdev-dev.parent)
 set_dev_node(ofdev-dev, 
 of_node_to_nid(ofdev-dev.of_node));

 -   return device_add(ofdev-dev);
 +   for (i = 0; i  ofdev-num_resources; i++) {
 +   struct resource *p, *r = ofdev-resource[i];
 +
 +   if (!r-name)
 +   r-name = dev_name(ofdev-dev);
 +
 +   p = r-parent;
 +   if (!p) {
 +   if (resource_type(r) == IORESOURCE_MEM)
 +   p = iomem_resource;
 +   else if (resource_type(r) == IORESOURCE_IO)
 +   p = ioport_resource;
 +   }
 +
 +   if (p  insert_resource(p, r)) {
 +   dev_err(ofdev-dev, failed to claim resource 
 %d\n,
 +   i);
 +   ret = -EBUSY;
 +   goto failed;
 +   }
 +   }
 +
 +   ret = device_add(ofdev-dev);
 +   if (ret == 0)
 +   return ret;
 +
 +failed:
 +   while (--i = 0) {
 +   struct resource *r = ofdev-resource[i];
 +   unsigned long type = resource_type(r);
 +
 +   if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
 +   release_resource(r);
 +   }
 +   return ret;
  }

  int of_device_register(struct platform_device *pdev)
 --
 2.2.1


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/21] irqchip: gic: killing gic_arch_extn and co, slowly

[Rob Herring]

On Wed, Jan 7, 2015 at 11:42 AM, Marc Zyngier marc.zyng...@arm.com wrote:
 The gic_arch_extn hack that a number of platform use has been nagging
 me for too long. It is only there for the benefit of a few platform,
 and yet it impacts all GIC users. Moreover, it gives people the wrong
 idea (let's use it to put some new custom hack in there...).

 But now that stacked irq domains have landed in -next, the time has
 come for gic_arch_extn to meet the Big Bit Bucket.

[...]

 - This actively *breaks* existing setups. Once you boot a new kernel
   with an old DT, suspend/resume *will* be broken. Old kernels on a
   new DT won't even boot! You've been warned. This really outline the
   necessity of actually describing the HW in device trees...

Just to be clear, you need some agreement from the maintainers of
those platforms before doing this. It doesn't appear there is
disagreement, but I don't see any explicit agreement either.

This seems to model the interrupts as chained, but at least for some
cases aren't these auxiliary controllers in parallel to the GIC? In
other words, do the they require configuration for interrupts to work
for the normal non-wakeup use? I'm not sure that the h/w is being
modeled any more accurately if that is the case. However, we don't
really have a way to describe an interrupt line is connected to 2
interrupt parents in DT, so I'm not sure what else you could do here.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653

[Rob Herring]

On Wed, Dec 24, 2014 at 4:34 PM, Pavel Machek pa...@ucw.cz wrote:

 We are moving to device tree support on OMAP3, but that currently
 breaks ADP1653 driver. This adds device tree support, plus required
 documentation.

 Signed-off-by: Pavel Machek pa...@ucw.cz

 ---

 Changed -microsec to -us, as requested by devicetree people.

 Fixed checkpatch issues.

 diff --git a/Documentation/devicetree/bindings/leds/common.txt 
 b/Documentation/devicetree/bindings/leds/common.txt
 index 2d88816..2c6c7c5 100644
 --- a/Documentation/devicetree/bindings/leds/common.txt
 +++ b/Documentation/devicetree/bindings/leds/common.txt
 @@ -14,6 +14,15 @@ Optional properties for child nodes:
   ide-disk - LED indicates disk activity
   timer - LED flashes at a fixed, configurable rate

 +- max-microamp : maximum intensity in microamperes of the LED
 +(torch LED for flash devices)
 +- flash-max-microamp : maximum intensity in microamperes of the
 +   flash LED; it is mandatory if the LED should
 +  support the flash mode
 +- flash-timeout-microsec : timeout in microseconds after which the flash
 +   LED is turned off

Doesn't all this go in your flash led binding patch?

 +
 +
  Examples:

  system-status {
 @@ -21,3 +30,10 @@ system-status {
 linux,default-trigger = heartbeat;
 ...
  };
 +
 +camera-flash {
 +   label = Flash;
 +   max-microamp = 5;
 +   flash-max-microamp = 32;
 +   flash-timeout-microsec = 50;
 +}
 diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt 
 b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
 new file mode 100644
 index 000..3c7065f
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
 @@ -0,0 +1,38 @@
 +* Analog Devices ADP1653 flash LED driver
 +
 +Required Properties:
 +
 +  - compatible: Must contain one of the following
 +- adi,adp1653
 +
 +  - reg: I2C slave address
 +
 +  - gpios: References to the GPIO that controls the power for the chip.
 +
 +There are two led outputs available - flash and indicator. One led is
 +represented by one child node, nodes need to be named flash and 
 indicator.
 +
 +Required properties of the LED child node:
 +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 +
 +Required properties of the flash LED child node:
 +
 +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
 +
 +Example:
 +
 +adp1653: led-controller@30 {
 +compatible = adi,adp1653;
 +   reg = 0x30;
 +gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
 +
 +   flash {
 +flash-timeout-us = 50;
 +flash-max-microamp = 32;
 +max-microamp = 5;
 +   };
 +indicator {

These are different LEDs or different modes?

 +max-microamp = 17500;

This is a bit inconsistent. The binding says this is for flash LEDs
torch mode, but I see no reason why it can't be common. Can you update
the binding doc to be clear here.

Also, aren't you missing label properties?

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653

[Rob Herring]

On Fri, Dec 26, 2014 at 2:33 PM, Pavel Machek pa...@ucw.cz wrote:
 Hi!

  We are moving to device tree support on OMAP3, but that currently
  breaks ADP1653 driver. This adds device tree support, plus required
  documentation.
 
  Signed-off-by: Pavel Machek pa...@ucw.cz
 
  ---
 
  Changed -microsec to -us, as requested by devicetree people.
 
  Fixed checkpatch issues.
 
  diff --git a/Documentation/devicetree/bindings/leds/common.txt 
  b/Documentation/devicetree/bindings/leds/common.txt
  index 2d88816..2c6c7c5 100644
  --- a/Documentation/devicetree/bindings/leds/common.txt
  +++ b/Documentation/devicetree/bindings/leds/common.txt
  @@ -14,6 +14,15 @@ Optional properties for child nodes:
ide-disk - LED indicates disk activity
timer - LED flashes at a fixed, configurable rate
 
  +- max-microamp : maximum intensity in microamperes of the LED
  +(torch LED for flash devices)
  +- flash-max-microamp : maximum intensity in microamperes of the
  +   flash LED; it is mandatory if the LED should
  +  support the flash mode
  +- flash-timeout-microsec : timeout in microseconds after which the flash
  +   LED is turned off

 Doesn't all this go in your flash led binding patch?

 No, I should not have included this part.

  +Example:
  +
  +adp1653: led-controller@30 {
  +compatible = adi,adp1653;
  +   reg = 0x30;
  +gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
  +
  +   flash {
  +flash-timeout-us = 50;
  +flash-max-microamp = 32;
  +max-microamp = 5;
  +   };
  +indicator {

 These are different LEDs or different modes?

 flash  indicator are different LEDs. One is white, one is red. Flash
 can be used as a flash and as a torch.

  +max-microamp = 17500;

 This is a bit inconsistent. The binding says this is for flash LEDs
 torch mode, but I see no reason why it can't be common. Can you update
 the binding doc to be clear here.

 By inconsisnent, you mean you want patch below?

Yes.

 Also, aren't you missing label properties?

 label is optional, and as my driver does not yet use it, I forgot
 about it.

Based on your node names, there are obviously user defined functions
for them already. So they should have labels whether or not the driver
uses them.

Rob

 Signed-off-by: Pavel Machek pa...@ucw.cz

 index 2c6c7c5..92d4dac 100644
 --- a/Documentation/devicetree/bindings/leds/common.txt
 +++ b/Documentation/devicetree/bindings/leds/common.txt
 @@ -15,7 +15,6 @@ Optional properties for child nodes:
   timer - LED flashes at a fixed, configurable rate

  - max-microamp : maximum intensity in microamperes of the LED
 -(torch LED for flash devices)
  - flash-max-microamp : maximum intensity in microamperes of the
 flash LED; it is mandatory if the LED should
support the flash mode


 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BCM2048 bluetooth connected over OMAP serial

[Rob Herring]

On Wed, Dec 10, 2014 at 10:43 AM, Pavel Machek pa...@ucw.cz wrote:
 Hi!

 So, there's bluetooth chip that's connected to the SoC by UART and some
 GPIOs. What would be right representation in the device tree?
 Something like this?

 bluetooth {
   compatible = broadcom,bcm2048;
   uart = uart2;
   reset-gpios = gpio3 27 GPIO_ACTIVE_HIGH; /* want 91 */
   host-wakeup-gpios = gpio4 5 GPIO_ACTIVE_HIGH; /* want 
 101 */
   bluetooth-wakeup-gpios = gpio2 5 GPIO_ACTIVE_HIGH; /* 
 want 37 */
   chip-type = 3;
   bt-sysclk = 2;
   reset-gpio-shared = 0;
 };

 Is there some way to prevent OMAP tty driver from binding to the
 device and exporting the device to userspace?

Isn't the normal way for BT to work is the uart is exposed to
userspace and the BT stack is all in userspace? This is how other
Broadcom BT/WiFi combo parts work.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm/arm64: DT: Fix GICv2 CPU interface size

[Rob Herring]

On Wed, Jun 25, 2014 at 5:37 AM, Marc Zyngier marc.zyng...@arm.com wrote:
 All the Cortex-{A7,A15} implementations are using a GICv2. Same for
 the current arm64 platforms.

 Turns out that most of these platforms have described their GIC CPU
 interface size as being 4kB. while it is actually 8kB (the GICC_DIR
 register lives at offset 0x1000).

 This was found when converting the GIC driver to use EOImode==1 on
 GICv2-based systems. It uses the GICC_DIR register, and the result
 is a very early firework...

What's your plan for making the kernel change? Updating the dts files
is good, but that doesn't immediately help you if you have old dtbs.

 Signed-off-by: Marc Zyngier marc.zyng...@arm.com
 ---
  arch/arm/boot/dts/axm55xx.dtsi  | 2 +-
  arch/arm/boot/dts/dra7.dtsi | 2 +-
  arch/arm/boot/dts/ecx-2000.dts  | 2 +-

Acked-by: Rob Herring r...@kernel.org

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] arm: dts: am4372: let boards access all nodes through phandles

[Rob Herring]

On Mon, Jun 23, 2014 at 1:20 PM, Felipe Balbi ba...@ti.com wrote:
 by providing phandles to rtc, wdt, cpu and dispc nodes,
 boards can access them to add board-specific data.

Strictly speaking, you are adding labels, not phandles. You can do
phandles without using labels, but the syntax is not so obvious. I'd
tell you what it is but offhand I don't remember. :)

Rob

 Signed-off-by: Felipe Balbi ba...@ti.com
 ---

 Changes since v1:
 - added phandles to cpu and dispc

  arch/arm/boot/dts/am4372.dtsi | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
 index 49fa596..8d3c163 100644
 --- a/arch/arm/boot/dts/am4372.dtsi
 +++ b/arch/arm/boot/dts/am4372.dtsi
 @@ -30,7 +30,7 @@
 cpus {
 #address-cells = 1;
 #size-cells = 0;
 -   cpu@0 {
 +   cpu: cpu@0 {
 compatible = arm,cortex-a9;
 device_type = cpu;
 reg = 0;
 @@ -270,7 +270,7 @@
 ti,hwmods = counter_32k;
 };

 -   rtc@44e3e000 {
 +   rtc: rtc@44e3e000 {
 compatible = ti,am4372-rtc,ti,da830-rtc;
 reg = 0x44e3e000 0x1000;
 interrupts = GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH
 @@ -279,7 +279,7 @@
 status = disabled;
 };

 -   wdt@44e35000 {
 +   wdt: wdt@44e35000 {
 compatible = ti,am4372-wdt,ti,omap3-wdt;
 reg = 0x44e35000 0x1000;
 interrupts = GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH;
 @@ -871,7 +871,7 @@
 #size-cells = 1;
 ranges;

 -   dispc@4832a400 {
 +   dispc: dispc@4832a400 {
 compatible = ti,omap3-dispc;
 reg = 0x4832a400 0x400;
 interrupts = GIC_SPI 127 
 IRQ_TYPE_LEVEL_HIGH;
 --
 2.0.0.390.gcb682f8

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/18] PCI: designware: use untranslated address while programming ATU

[Rob Herring]

On Thu, May 29, 2014 at 1:38 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
 In DRA7, the cpu sees 32bit address, but the pcie controller can see only 
 28bit
 address. So whenever the cpu issues a read/write request, the 4 most
 significant bits are used by L3 to determine the target controller.
 For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller 
 but
 the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming
 the outbound translation window the *base* should be programmed as 0x000_.
 Whenever we try to write to say 0x2000_, it will be translated to whatever
 we have programmed in the translation window with base as 0x000_.

 This is needed when the dt node is modelled something like below
 axi {
 compatible = simple-bus;
 #size-cells = 1;
 #address-cells = 1;
 ranges = 0x00x2000 0x1000 // 28-bit bus
   0x5100 0x5100 0x3000;
 pcie@5100 {
 reg = 0x1000 0x2000, 0x51002000 0x14c, 0x5100 
 0x2000;
 reg-names = config, ti_conf, rc_dbics;
 #address-cells = 3;
 #size-cells = 2;
 ranges = 0x8100 0 0  0x03000 0 0x0001
   0x8200 0 0x20013000 0x13000 0 0xffed000;
 };
 };

 Here the CPU address for configuration space is 0x20013000 and the controller
 address for configuration space is 0x13000. The controller address should be
 used while programming the ATU (in order for translation to happen properly in
 DRA7xx).

This talks about config space, but the ranges field is PCI memory
space. Also, does this actually work because I though Linux expects
memory BARs to be 1MB aligned.

Getting the controller offset should work whether you specify the
address as 0x13000 with translation or the absolute address
0x20013000. In other words, the driver should know how many bits to
mask off to get the offset.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: omap: rework platform selection

[Rob Herring]

On Tue, Jun 17, 2014 at 8:57 AM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 16 June 2014, Rob Herring wrote:
  So far I have not come up with no great ideas on fixing this
  properly short of requiring all omap .config files to add
  CONFIG_ARCH_OMAP=y manually. Anybody got good ideas for that?

 I've failed to come up with anything...


 I have two ideas, but neither is great:

 a) we leave the individual per-soc options in the top-level menu
and move the sub-options under those. This is a bit or a problem
for options concerning all of OMAP, but I'm not sure how many of
those are actually required.

 b) We go back to Rob's version and make CONFIG_ARCH_OMAP the
user-selectable option, and then find another solution for
building a kernel with ARCH_OMAP set but none of individual
options. This will work for anybody who has a full .config
file, but still break the 'make savedefconfig' generated ones.

After playing with this more yesterday, I think ARCH_OMAP2PLUS instead
of ARCH_OMAP is actually a better choice to make the menuconfig item.
It still has the same defconfig issues, but doesn't affect OMAP1.

Doing your trick of a default selection with select ARCH_OMAP2 if
!(ARCH_OMAP3 || ARCH_OMAP4 || ...) in the menuconfig option can fix
the build issues. We'd actually need 2 selects for v6 and v7 only
builds.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: omap: rework platform selection

[Rob Herring]

On Tue, Jun 17, 2014 at 10:25 AM, Tony Lindgren t...@atomide.com wrote:
 * Rob Herring robherri...@gmail.com [140617 08:05]:
 On Tue, Jun 17, 2014 at 8:57 AM, Arnd Bergmann a...@arndb.de wrote:
  On Monday 16 June 2014, Rob Herring wrote:
   So far I have not come up with no great ideas on fixing this
   properly short of requiring all omap .config files to add
   CONFIG_ARCH_OMAP=y manually. Anybody got good ideas for that?
 
  I've failed to come up with anything...
 
 
  I have two ideas, but neither is great:
 
  a) we leave the individual per-soc options in the top-level menu
 and move the sub-options under those. This is a bit or a problem
 for options concerning all of OMAP, but I'm not sure how many of
 those are actually required.
 
  b) We go back to Rob's version and make CONFIG_ARCH_OMAP the
 user-selectable option, and then find another solution for
 building a kernel with ARCH_OMAP set but none of individual
 options. This will work for anybody who has a full .config
 file, but still break the 'make savedefconfig' generated ones.

 After playing with this more yesterday, I think ARCH_OMAP2PLUS instead
 of ARCH_OMAP is actually a better choice to make the menuconfig item.
 It still has the same defconfig issues, but doesn't affect OMAP1.

 Well eventually we'll have the same problem for both ARCH_OMAP1
 and ARCH_OMAP2PLUS so from that point of view it might make sense
 to use ARCH_OMAP to start with.

But OMAP1 and OMAP2PLUS are mutually exclusive being v5 and v6+. So
there would not be any user visible difference having 2 visible
options. Do you expect any of these kconfig symbols to become
obsolete?

 Doing your trick of a default selection with select ARCH_OMAP2 if
 !(ARCH_OMAP3 || ARCH_OMAP4 || ...) in the menuconfig option can fix
 the build issues. We'd actually need 2 selects for v6 and v7 only
 builds.

 Yes that or the options in mach-omap2/Makefile can be fixed up
 further for building things only when a SoC is selected.

 So really the issue is how to deal with make oldconfig for
 existing .config files. I don't know if there's any solution to
 that short of doing make CONFIG_ARCH_OMAP=y oldconfig.

.config files are the full config, so wouldn't they be okay? It is
only the reduced savedefconfig that would break.

Rob


 Regards,

 Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: omap: rework platform selection

[Rob Herring]

On Mon, Jun 16, 2014 at 9:17 AM, Tony Lindgren t...@atomide.com wrote:
 * Tony Lindgren t...@atomide.com [140616 04:31]:
 * Arnd Bergmann a...@arndb.de [140616 04:18]:
 
  Let's see if others have similar opinions Rob's patch as a whole.
  I'd still like to keep all the parts aside from the OMAP change
  and just back out the change that caused the problems.
 
  Does that seem reasonable to you?

 Yes makes sense to me if others don't have similar issues. I guess
 it should be possible to verify that by diffing the generated
 .config files compared to the old ones.

Other than exynos (which is new to MP) and OMAP, the rest are
straightforward user config to menuconfig conversions.

 If you update Rob's patch and undo the omap2+ changes, you might
 want to fold in something like the following to hide the omap
 options behind a menu.

This or reverting the OMAP part seems like the best change for now.

 So far I have not come up with no great ideas on fixing this
 properly short of requiring all omap .config files to add
 CONFIG_ARCH_OMAP=y manually. Anybody got good ideas for that?

I've failed to come up with anything...

Rob


 Regards,

 Tony

 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -1,3 +1,5 @@
 +menu TI OMAP/AM/DM/DRA Family
 +
  config ARCH_OMAP
 bool

 @@ -342,3 +344,5 @@ config OMAP4_ERRATA_I688
  endmenu

  endif
 +
 +endmenu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM / OPP: Remove ARCH_HAS_OPP

[Rob Herring]

On Fri, Jun 6, 2014 at 5:36 AM, Mark Brown broo...@kernel.org wrote:
 From: Mark Brown broo...@linaro.org

 Since the OPP layer is a kernel library which has been converted to be
 directly selectable by its callers rather than user selectable and
 requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
 has become redundant and can be removed. Do so.

 Signed-off-by: Mark Brown broo...@linaro.org

Acked-by: Rob Herring r...@kernel.org

 ---
  Documentation/power/opp.txt| 3 ---
  arch/arm/mach-exynos/Kconfig   | 1 -
  arch/arm/mach-highbank/Kconfig | 1 -
  arch/arm/mach-imx/Kconfig  | 1 -
  arch/arm/mach-omap2/Kconfig| 1 -
  arch/arm/mach-shmobile/Kconfig | 2 --
  arch/arm/mach-vexpress/Kconfig | 1 -
  arch/arm/mach-zynq/Kconfig | 1 -
  drivers/devfreq/Kconfig| 1 -
  kernel/power/Kconfig   | 3 ---
  10 files changed, 15 deletions(-)

 diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
 index a9adad8..c6279c2 100644
 --- a/Documentation/power/opp.txt
 +++ b/Documentation/power/opp.txt
 @@ -51,9 +51,6 @@ Typical usage of the OPP library is as follows:
  SoC framework  - modifies on required cases certain OPPs  - OPP layer
 - queries to search/retrieve information   -

 -Architectures that provide a SoC framework for OPP should select ARCH_HAS_OPP
 -to make the OPP layer available.
 -
  OPP layer expects each domain to be represented by a unique device pointer. 
 SoC
  framework registers a set of initial OPPs per device with the OPP layer. This
  list is expected to be an optimally small number typically around 5 per 
 device.
 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index d58995c9..3f78c45 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -103,7 +103,6 @@ config SOC_EXYNOS5440
 default y
 depends on ARCH_EXYNOS5
 select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
 -   select ARCH_HAS_OPP
 select HAVE_ARM_ARCH_TIMER
 select AUTO_ZRELADDR
 select MIGHT_HAVE_PCI
 diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
 index 830b76e..bef970f 100644
 --- a/arch/arm/mach-highbank/Kconfig
 +++ b/arch/arm/mach-highbank/Kconfig
 @@ -3,7 +3,6 @@ config ARCH_HIGHBANK
 select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
 select ARCH_HAS_CPUFREQ
 select ARCH_HAS_HOLES_MEMORYMODEL
 -   select ARCH_HAS_OPP
 select ARCH_SUPPORTS_BIG_ENDIAN
 select ARM_AMBA
 select ARM_ERRATA_764369 if SMP
 diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
 index 4cce93d..95690e4 100644
 --- a/arch/arm/mach-imx/Kconfig
 +++ b/arch/arm/mach-imx/Kconfig
 @@ -1,7 +1,6 @@
  config ARCH_MXC
 bool Freescale i.MX family if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP
 select ARCH_REQUIRE_GPIOLIB
 select ARM_CPU_SUSPEND if PM
 select CLKSRC_MMIO
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index 0ba4826..524b027 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -12,7 +12,6 @@ config ARCH_OMAP3
 bool TI OMAP3
 depends on ARCH_MULTI_V7
 select ARCH_OMAP2PLUS
 -   select ARCH_HAS_OPP
 select ARM_CPU_SUSPEND if PM
 select OMAP_INTERCONNECT
 select PM_OPP if PM
 diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
 index dbd954e..b51d142 100644
 --- a/arch/arm/mach-shmobile/Kconfig
 +++ b/arch/arm/mach-shmobile/Kconfig
 @@ -86,7 +86,6 @@ config ARCH_R8A73A4
 select SH_CLK_CPG
 select RENESAS_IRQC
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP
 select SYS_SUPPORTS_SH_CMT
 select SYS_SUPPORTS_SH_TMU

 @@ -265,7 +264,6 @@ config MACH_KZM9G
 bool KZM-A9-GT board
 depends on ARCH_SH73A0
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP
 select ARCH_REQUIRE_GPIOLIB
 select REGULATOR_FIXED_VOLTAGE if REGULATOR
 select SND_SOC_AK4642 if SND_SIMPLE_CARD
 diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
 index 90249cf..71629fe 100644
 --- a/arch/arm/mach-vexpress/Kconfig
 +++ b/arch/arm/mach-vexpress/Kconfig
 @@ -66,7 +66,6 @@ config ARCH_VEXPRESS_DCSCB
  config ARCH_VEXPRESS_SPC
 bool Versatile Express Serial Power Controller (SPC)
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP
 select PM_OPP
 help
   The TC2 (A15x2 A7x3) versatile express core tile integrates a logic
 diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
 index 573e0db..bc485f2 100644
 --- a/arch/arm/mach-zynq/Kconfig
 +++ b/arch/arm/mach-zynq/Kconfig
 @@ -1,7 +1,6 @@
  config ARCH_ZYNQ
 bool Xilinx Zynq ARM Cortex A9 Platform if ARCH_MULTI_V7
 select ARCH_HAS_CPUFREQ
 -   select ARCH_HAS_OPP

Re: [PATCH v3 1/5] sc_phy:SmartCard(SC) PHY interface to SC controller

[Rob Herring]

On Thu, May 29, 2014 at 3:34 AM, Satish Patel satish.pa...@ti.com wrote:


 On 5/29/2014 12:23 AM, Greg KH wrote:

 On Wed, May 28, 2014 at 02:27:13PM +0530, Satish Patel wrote:

 SmartCard controller uses this interface to communicate with
 SmartCard via PHY

 Some SmartCard PHY has multiple slots for cards.
 This inerface also enables controller to communicate
 with one or more SmartCard connected over phy.

 interface structure includes following APIs
 - set/get config
 - activate/deactivate smart card
 - warm reset
 - register_notify (for card insert/remove/overheat)
 - unregister_notify

 Signed-off-by: Satish Patel satish.pa...@ti.com
 ---
   Documentation/sc_phy.txt |  171
 ++
   include/linux/sc_phy.h   |  136 
   2 files changed, 307 insertions(+)
   create mode 100644 Documentation/sc_phy.txt
   create mode 100644 include/linux/sc_phy.h


 These are .h files, but where is the api functions that use
 these structures defined at?

 This is like template/wrappers, smart card phy driver will write API
 functions. And smartcard controller will call these functions.
 With proposed approach, smartcard controller can communicate with any smart
 card phy (TI/NxP) without change in code. Using DT entry smartcard and PHY
 will gets connected with each other.
 Refer diagram given @Documentation/sc_phy.txt.


 confused,

I believe the api Greg is wondering about is the notifier which as I
commented is not a good design.

There is now a phy subsystem. I don't know if it has what you need,
but you should look at it to determine if it will work or could be
extended to work.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 16/18] ARM: OMAP: Enable PCI for DRA7

[Rob Herring]

On Thu, May 29, 2014 at 1:38 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Now that we have added PCIe driver for DRA7 SOCs, enable PCI on
 DRA7 SOCs.

 Cc: Tony Lindgren t...@atomide.com
 Cc: Rob Herring robh...@kernel.org
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Kumar Gala ga...@codeaurora.org
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  arch/arm/mach-omap2/Kconfig |2 ++
  1 file changed, 2 insertions(+)

 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index cb31d43..b179e80 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -75,6 +75,8 @@ config SOC_DRA7XX
 select ARM_GIC
 select HAVE_ARM_ARCH_TIMER
 select IRQ_CROSSBAR
 +   select MIGHT_HAVE_PCI

I believe we moved or intend to move this under MULTI_PLATFORM, so you
don't need this. Will D. had a patch, but I don't think I saw a final
version to merge.

Rob

 +   select ARCH_SUPPORTS_MSI

  config ARCH_OMAP2PLUS
 bool
 --
 1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT

[Rob Herring]

On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna s-a...@ti.com wrote:
 The HwSpinlock core requires a base id for registering a bank
 of hwspinlocks. This base id needs to be unique across multiple
 IP instances of a hwspinlock device, so that each hwlock can be
 represented uniquely in a system.

 Support has been added to represent this in DT through a common
 property 'hwlock-base-id', and retrieve the value through a core
 OF helper function, of_hwspin_lock_get_base_id(). The representation
 in DT provides a uniform way of assigning a fixed base value for a
 hwspinlock device across different SoCs.

 Signed-off-by: Suman Anna s-a...@ti.com
 ---
  Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++
  drivers/hwspinlock/hwspinlock_core.c| 21 
 +
  include/linux/hwspinlock.h  |  1 +
  3 files changed, 28 insertions(+)

 diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt 
 b/Documentation/devicetree/bindings/hwlock/hwlock.txt
 index 32381cc..d538a9b 100644
 --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
 +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
 @@ -18,6 +18,12 @@ Common properties:
 property is needed on hwlock devices, where the number
 of supported locks within a hwlock device cannot be
 read from a register.
 +- hwlock-base-id:  An unique base Id for the locks for a particular 
 hwlock
 +   device. This property is mandatory ONLY if a SoC has
 +   several hwlock devices.
 +
 +   See documentation on struct hwspinlock_pdata in
 +   include/linux/hwspinlock.h for more details.

The documentation cannot refer to kernel files. Generally, creating a
global number space like this would not be accepted, but I don't
really have any better idea here.

Please put all binding docs in 1 patch and copy all the DT binding maintainers.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock

[Rob Herring]

On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna s-a...@ti.com wrote:
 This patch adds the generic common bindings used to represent
 a hwlock device and use/request locks in a device-tree build.

 All the platform-specific hwlock driver implementations need the
 number of locks and associated base id for registering the locks
 present within the device with the driver core. The number of locks
 is represented by 'hwlock-num-locks' property in DT bindings. A
 property for base id is not needed in DT binding, as it can be
 satisfied using a phandle + args specifier. The args specifier
 length is dependent on each vendor-specific implementation and
 is represented through the '#hwlock-cells' property.

 Note that the document is named hwlock.txt deliberately to keep it
 a bit more generic.

 Cc: Rob Herring robh...@kernel.org
 Signed-off-by: Suman Anna s-a...@ti.com
 ---
  .../devicetree/bindings/hwlock/hwlock.txt  | 52 
 ++
  1 file changed, 52 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt

 diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt 
 b/Documentation/devicetree/bindings/hwlock/hwlock.txt
 new file mode 100644
 index 000..32381cc
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
 @@ -0,0 +1,52 @@
 +Generic hwlock bindings
 +===
 +
 +Generic bindings that are common to all the hwlock platform specific driver
 +implementations, the retrieved values are used for registering the device
 +specific parameters with the hwspinlock core.
 +
 +The validity and need of these common properties may vary from one platform
 +implementation to another. The platform specific bindings should explicitly
 +state if a property is mandatory or optional. Please look through the
 +individual platform specific hwlock binding documentations for identifying
 +the applicable properties.
 +
 +Common properties:
 +- #hwlock-cells:   Specifies the number of cells needed to represent a
 +   specific lock.

This should never be optional.

 +- hwlock-num-locks:Number of locks present in a hwlock device. This
 +   property is needed on hwlock devices, where the number
 +   of supported locks within a hwlock device cannot be
 +   read from a register.

Do you have any users of this? The omap binding doesn't use it.
Wouldn't you typically know this based on the IP block? Similarly you
typically don't have to list how many irqs an interrupt controller
has.


 +
 +Hwlock Users:
 +=
 +
 +Nodes that require specific hwlock(s) should specify them using one or more
 +properties, each containing a phandle to the hwlock node and an args 
 specifier
 +value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
 +an array of the phandle and hwlock number specifier tuple.
 +
 +1. Example of a node using a single specific hwlock:
 +
 +The following example has a node requesting a hwlock in the bank defined by
 +the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
 +of length 1.
 +
 +   node {
 +   ...
 +   hwlocks = hwlock1 2;
 +   ...
 +   };
 +
 +2. Example of a node using multiple specific hwlocks:
 +
 +The following example has a node requesting two hwlocks, a hwlock within
 +the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
 +hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
 +
 +   node {
 +   ...
 +   hwlocks = hwlock1 2, hwlock2 0 3;
 +   ...
 +   };
 --
 1.9.2

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 09/14] Documentation: DT: omap-ssi binding documentation

[Rob Herring]

On Fri, Mar 28, 2014 at 7:31 PM, Sebastian Reichel s...@kernel.org wrote:
 Create device tree binding documentation for
 OMAP Synchronous Serial Interface (SSI) device.

 Signed-off-by: Sebastian Reichel s...@kernel.org
 ---
  Documentation/devicetree/bindings/hsi/omap-ssi.txt | 85 
 ++
  1 file changed, 85 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt

 diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt 
 b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
 new file mode 100644
 index 000..709419b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
 @@ -0,0 +1,85 @@
 +OMAP SSI controller bindings
 +
 +OMAP Synchronous Serial Interface (SSI) controller implements a legacy
 +variant of MIPI's High Speed Synchronous Serial Interface (HSI).
 +
 +Required properties:
 +- compatible:  Should include ti,omap3-ssi.
 +- reg-names:   Contains the values sys and gdd.
 +- reg: Contains a register specifier for each entry in
 +   reg-names.

You need to define the order here unless you have a strong argument
why you can't.

 +- interrupt-names:  Contains the value gdd_mpu.
 +- interrupts:  Contains interrupt information for each entry in
 +   interrupt-names.
 +- ranges:  Represents the bus address mapping between the main
 +   controller node and the child nodes below.
 +- clocks:  Contains clock specifiers for each entry in
 +clock-names.
 +- clock-names: Must include the following entries:
 +  ssi_ssr_fck: The OMAP clock of that name
 +  ssi_sst_fck: The OMAP clock of that name
 +  ssi_ick: The OMAP clock of that name
 +- #address-cells:  Should be set to 1
 +- #size-cells: Should be set to 1
 +
 +Each port is represented as a sub-node of the ti,omap3-ssi device.
 +
 +Required Port sub-node properties:
 +- compatible:  Should be set to the following value
 +ti,omap3-ssi-port (applicable to OMAP34xx devices)
 +- reg-names:   Contains the values rx and tx.
 +- reg: Contains a register specifier for each entry in
 +   reg-names.

You need to define the order here unless you have a strong argument
why you can't.

 +- interrupt-parent Should be a phandle for the interrupt controller
 +- interrupt-names: Contains the values mpu_irq0 and mpu_irq1.

Those names aren't exactly useful.

 +- interrupts:  Contains interrupt information for each entry in
 +   interrupt-names.

You need to define the order here unless you have a strong argument
why you can't.

 +- ti,ssi-cawake-gpio:  Defines which GPIO pin is used to signify CAWAKE
 +   events for the port. This is an optional 
 board-specific
 +   property. If it's missing the port will not be
 +   enabled.
 +
 +Example for Nokia N900:
 +
 +ssi-controller@48058000 {
 +   compatible = ti,omap3-ssi;
 +
 +   /* needed until hwmod is updated to use the compatible string */
 +   ti,hwmods = ssi;
 +
 +   reg = 0x48058000 0x1000,
 + 0x48059000 0x1000;
 +   reg-names = sys,
 +   gdd;
 +
 +   interrupts = 55;
 +   interrupt-names = gdd_mpu;
 +
 +   clocks = ssi_ssr_fck,
 +ssi_sst_fck,
 +ssi_ick;
 +   clock-names = ssi_ssr_fck,
 + ssi_sst_fck,
 + ssi_ick;
 +
 +   #address-cells = 1;
 +   #size-cells = 1;
 +   ranges;
 +
 +   ssi-port@0 {

Does this h/w really have more than 1 port?

This should really be ssi-port@4805a800 Or you need to fill in
ranges to have a local offset.

 +   compatible = ti,omap3-ssi-port;
 +
 +   reg = 0x4805a000 0x800,
 + 0x4805a800 0x800;
 +   reg-names = tx,
 +   rx;
 +
 +   interrupt-parent = intc;
 +   interrupts = 51,
 +52;
 +   interrupt-names = mpu_irq0,
 + mpu_irq1;
 +
 +   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
 +   }
 +}
 --
 1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 07/14] HSI: Add common DT binding for HSI client devices

[Rob Herring]

On Fri, Mar 28, 2014 at 7:31 PM, Sebastian Reichel s...@kernel.org wrote:
 Implement and document generic DT bindings for HSI clients.

 Signed-off-by: Sebastian Reichel s...@kernel.org

Seems pretty reasonable although I know little about HSI.

 ---
  .../devicetree/bindings/hsi/client-devices.txt |  44 +
  drivers/hsi/hsi.c  | 197 
 -
  include/linux/hsi/hsi.h|   2 +
  3 files changed, 241 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt

 diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt 
 b/Documentation/devicetree/bindings/hsi/client-devices.txt
 new file mode 100644
 index 000..7504cb1
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/hsi/client-devices.txt
 @@ -0,0 +1,44 @@
 +Each HSI port is supposed to have one child node, which
 +symbols the remote device connected to the HSI port. The
 +following properties are standardized for HSI clients:
 +
 +Required HSI configuration properties:
 +
 +- reg: A list of channel ids
 +
 +- hsi-rx-mode: Receiver Bit transmission mode (stream or frame)
 +- hsi-tx-mode: Transmitter Bit transmission mode (stream or 
 frame)
 +- hsi-mode:May be used instead hsi-rx-mode and hsi-tx-mode if
 +   the transmission mode is the same for receiver and
 +   transmitter
 +- hsi-speed-kbps:  Max bit transmission speed in kbit/s
 +- hsi-flow:RX flow type (synchronized or pipeline)
 +- hsi-arb-mode:Arbitration mode for TX frame (round-robin, 
 priority)
 +
 +Optional HSI configuration properties:
 +
 +- reg-names:   A list with one name per channel specified in the
 +   reg property
 +
 +
 +Device Tree node example for an HSI client:
 +
 +hsi-controller {
 +   hsi-port {
 +   modem: hsi-client {
 +   compatible = nokia,n900-modem;

Is there only 1 version of HSI? If not, then perhaps you need to know
what version a client is.

 +
 +   reg = 0, 1, 2, 3;

Where do these numbers get defined? Are they always 0-N?

I don't see much advantage to using reg. Perhaps something like
hsi-channel-ids would be better.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/5] Input: add common DT binding for touchscreens

[Rob Herring]

On Sat, Apr 5, 2014 at 5:26 PM, Sebastian Reichel s...@kernel.org wrote:
 Add common DT binding documentation for touchscreen devices and
 implement input_parse_touchscreen_of_params, which parses the common
 properties and configures the input device accordingly.

Good.


 Signed-off-by: Sebastian Reichel s...@kernel.org
 ---
  .../bindings/input/touchscreen/touchscreen.txt |  9 ++
  drivers/input/input.c  | 34 
 ++
  include/linux/input.h  |  8 +
  3 files changed, 51 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

 diff --git 
 a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt 
 b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 new file mode 100644
 index 000..a2ff0a0
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 @@ -0,0 +1,9 @@
 +General Touchscreen Properties:
 +
 +Optional properties for Touchscreens:
 + - touchscreen-size-x  : horizontal resolution of touchscreen
 + - touchscreen-size-y  : vertical resolution of touchscreen

While I like the consistency, x-size and y-size are already commonly
used. Perhaps the common binding should have both and x-size/y-size be
marked deprecated.

 + - touchscreen-max-pressure: maximum reported pressure
 + - touchscreen-fuzz-x  : horizontal noise value of the absolute 
 input device
 + - touchscreen-fuzz-y  : vertical noise value of the absolute input 
 device
 + - touchscreen-fuzz-pressure   : pressure noise value of the absolute input 
 device

What are the units or are they just an arbitrary range dependent on
the controller? Several existing bindings appear to be in pixels, but
that seems wrong to me.

There's also these various properties that should have common versions created:

ti,x-plate-resistance and ti,x-plate-ohms (tsc2007)
- rohm,flip-x : Flip touch coordinates on the X axis
 - rohm,flip-y : Flip touch coordinates on the Y axis
- x-invert: invert X axis
- y-invert: invert Y axis
- contact-threshold:
- moving-threshold:

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/5] Input: add common DT binding for touchscreens

[Rob Herring]

On Mon, Apr 7, 2014 at 3:00 PM, Sebastian Reichel s...@kernel.org wrote:
 On Mon, Apr 07, 2014 at 11:38:01AM -0500, Rob Herring wrote:
 On Sat, Apr 5, 2014 at 5:26 PM, Sebastian Reichel s...@kernel.org wrote:
  Add common DT binding documentation for touchscreen devices and
  implement input_parse_touchscreen_of_params, which parses the common
  properties and configures the input device accordingly.

 Good.

 [...]
  +Optional properties for Touchscreens:
  + - touchscreen-size-x  : horizontal resolution of touchscreen
  + - touchscreen-size-y  : vertical resolution of touchscreen

 While I like the consistency, x-size and y-size are already commonly
 used. Perhaps the common binding should have both and x-size/y-size be
 marked deprecated.

 So you want me to add something like the following?

 - x-size : deprecated name for touchscreen-size-x
 - y-size : deprecated name for touchscreen-size-y

Yes.


  + - touchscreen-max-pressure: maximum reported pressure
  + - touchscreen-fuzz-x  : horizontal noise value of the absolute 
  input device
  + - touchscreen-fuzz-y  : vertical noise value of the absolute 
  input device
  + - touchscreen-fuzz-pressure   : pressure noise value of the absolute 
  input device

 What are the units or are they just an arbitrary range dependent on
 the controller? Several existing bindings appear to be in pixels, but
 that seems wrong to me.

 x/y related properties: pixels
 pressure related properties: arbitrary range dependent on the controller

Please make this clear in the binding description.

 There's also these various properties that should have common versions 
 created:

 ti,x-plate-resistance and ti,x-plate-ohms (tsc2007)

 I think this is ti specific. But I should probably name the tsc2005
 property ti,x-plate-ohms, so that its in sync with tsc2007.

 - rohm,flip-x : Flip touch coordinates on the X axis
 - rohm,flip-y : Flip touch coordinates on the Y axis
 - x-invert: invert X axis
 - y-invert: invert Y axis

 like this?

 - touchscreen-inverted-x: X axis is inverted
 - touchscreen-inverted-y: Y axis is inverted
 - x-invert: deprecated name for touchscreen-inverted-x
 - y-invert: deprecated name for touchscreen-inverted-y

 Inverting is currently not supported by the input system, though. So
 adding support for it to input_parse_touchscreen_of_params() is not
 trivial :/

Does not matter. I'm only asking you to define the property. Linux
does not have to use it currently.

 - contact-threshold:
 - moving-threshold:

 I think those are hardware specific. The properties are currently
 used by one driver, which writes them directly into some registers.
 The DT binding does not give more information about them.

moving-threshold is probably the same as fuzz. contact-threshold is
sounds like min pressure. I remember having to tune the minimum
pressure on a touchscreen I worked on long ago. So think think is
definitely not an uncommon property.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 02/12] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller

[Rob Herring]

On Wed, Mar 26, 2014 at 8:57 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Added support for pcie controller in dra7xx. This driver re-uses
 the designware core code that is already present in kernel.

 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  Documentation/devicetree/bindings/pci/ti-pci.txt |   35 ++
  drivers/pci/host/Kconfig |   10 +
  drivers/pci/host/Makefile|1 +
  drivers/pci/host/pcie-dra7xx.c   |  411 
 ++
  4 files changed, 457 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
  create mode 100644 drivers/pci/host/pcie-dra7xx.c

 diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
 b/Documentation/devicetree/bindings/pci/ti-pci.txt
 new file mode 100644
 index 000..0528c47
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
 @@ -0,0 +1,35 @@
 +TI PCI Controllers
 +
 +PCIe Designware Controller
 +This node should have the properties described in designware-pcie.txt.
 + - compatible: Should be ti,dra7xx-pcie
 + - reg : Address and length of the register set for the device.
 + - phys : the phandle for the PHY device (used by generic PHY framework)
 + - phy-names : the names of the PHY corresponding to the PHYs present in the
 +   *phy* phandle.
 + - resets: phandle used if reset is handled be soc

s/be/by/ ?

 + - reset-names: name given to the phandle
 + - ti,device-type: Should be 1 - EP TYPE, 2 - LEG EP TYPE OR 3 - RC TYPE

I don't think this makes sense. I'd imagine we'd need the binding to
look quite a bit different if endpoint mode was actually supported. I
think I would start defining endpoint mode with a different compatible
string and go from there.

 +
 +Example:
 +pcie@5100 {
 +   compatible = ti,dra7xx-pcie;
 +   reg = 0x51002000 0x14c, 0x5100 0x2000, 0x4A002540 0x1f, 
 0x4A003c24 0x4, 0x4AE07310 0x4;

This is different number of entries from your actual dts. You need to
define how many reg entries, what they are, and the order.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/9] opp-modifier: Add opp-modifier-reg driver

[Rob Herring]

On Mon, Mar 17, 2014 at 9:30 AM, Nishanth Menon n...@ti.com wrote:
 On 03/14/2014 04:00 PM, Rob Herring wrote:
 On Fri, Mar 14, 2014 at 2:25 PM, Dave Gerlach d-gerl...@ti.com wrote:
 Driver to read from a register and depending on either set bits or
 a specific known selectively enable or disable OPPs based on DT node.

 Can support opp-modifier-reg-bit where single bits within the register
 determine the availability of an OPP or opp-modifier-reg-val where a
 certain value inside the register or a portion of it determine what the
 maximum allowed OPP is.

 The driver expects a device that has already has its OPPs loaded
 and then will disable the OPPs not matching the criteria specified in
 the opp-modifier table.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
  .../devicetree/bindings/power/opp-modifier.txt | 111 +
  drivers/power/opp/Makefile |   1 +
  drivers/power/opp/opp-modifier-reg.c   | 259 
 +
  3 files changed, 371 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt
  create mode 100644 drivers/power/opp/opp-modifier-reg.c

 diff --git a/Documentation/devicetree/bindings/power/opp-modifier.txt 
 b/Documentation/devicetree/bindings/power/opp-modifier.txt
 new file mode 100644
 index 000..af8a2e9
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/power/opp-modifier.txt
 @@ -0,0 +1,111 @@
 +* OPP-Modifier - opp modifier to selectively enable operating points
 +
 +Many SoCs that have selectively modifiable OPPs can specify
 +all available OPPs in their operating-points listing and then define
 +opp_modifiers to enable or disable the OPPs that are actually available
 +on the specific hardware.
 +
 +* OPP Modifier Provider

 Uggg. Please stop designing around the current OPP binding which has
 the problem that the OPP table is not extensible to add more data.
 Define a new OPP binding that solves these problems. This is at least
 Generically, there are three different issues with current OPP bindings:
 a) ability to enable disable certain OPPs depending on SoC OTP/Efuse
 settings.

More generically: ...depending on variety of factors.

 b) ability to reuse OPPs defined for one device node for another (cpu1
 to reuse OPP definitions of cpu0)
 c) ability to add additional information per OPP. we can argue this is
 a superset of (a), but really, the problems are different.

It is all additional data per OPP. Additional different information is
of course for different problems. That doesn't mean we need different
solutions.

 Previous proposals include making each OPP as a phandle, but there
 does not seem much traction in that direction either. - proposal here
 has nothing to do with (b) or (c).

They may have nothing to do with each other, but they all have to do
with the OPP binding. If we're going to change/extend the binding,
then all issues need to be taken into account.

 the 3rd OPP related binding addition I've seen recently. But I
 wouldn't spend a lot of effort on a new OPP binding just to add the
 functionality you are adding here because I don't like the whole
 concept in general. This might be a common way to determine valid OPPs
 on TI chips, but I think it is too low level and I don't want to see

 Not just TI chips, but iMX, now, Marvell, Xilinx as well. potentially
 more as well. doing OTP/Efuse based decision on which OPPs are valid
 on a chip is not a TI specific thing. This was the reason for us to
 try to define something generic enough to be reused by more SoCs than
 just TI.

Agreed, but I'm not convinced how different SOCs determine valid OPPs
is common enough. Certainly how to mark an entry disabled is common
though.

 bindings for every different possible way. Just add platform code to
 do the OPP setup you need.
 Errr.. adding platform code means the hardware description goes back
 to kernel. is'nt that giving up on device tree binding for describing
 hardware?

We're always going to have some platform code. I'm not saying you have
to in this case. I'm saying either come up with an OPP binding
addressing all these issues or live with the existing one and fix it
up in the kernel or bootloader.

 Frankly, I prefer the bootloader/firmware fixup the OPP table approach
 mentioned in the cpufreq-cpu0 thread. Somewhat less desirable, but the
 kernel could do the fixups as well (via of_update_property).

 a) Trying to move the hardware definition away from device tree seems
 to me a major step backwards.
 b) Allowing for definitions in platform code is a step backwards again
 for a generic solution that works for more than 1 vendor.
 c) moving the logic away to bootloader when it can easily be done in
 kernel again is adding burden to bootloader for data it does need to
 handle.

The burden has to be somewhere. Maintaining a binding forever in the
kernel is a burden as well if it is poorly designed.

Valid OPPs are not going to just be random. There's probably

Re: [RFC 2/9] opp-modifier: Add opp-modifier-reg driver

[Rob Herring]

On Fri, Mar 14, 2014 at 2:25 PM, Dave Gerlach d-gerl...@ti.com wrote:
 Driver to read from a register and depending on either set bits or
 a specific known selectively enable or disable OPPs based on DT node.

 Can support opp-modifier-reg-bit where single bits within the register
 determine the availability of an OPP or opp-modifier-reg-val where a
 certain value inside the register or a portion of it determine what the
 maximum allowed OPP is.

 The driver expects a device that has already has its OPPs loaded
 and then will disable the OPPs not matching the criteria specified in
 the opp-modifier table.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
  .../devicetree/bindings/power/opp-modifier.txt | 111 +
  drivers/power/opp/Makefile |   1 +
  drivers/power/opp/opp-modifier-reg.c   | 259 
 +
  3 files changed, 371 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/power/opp-modifier.txt
  create mode 100644 drivers/power/opp/opp-modifier-reg.c

 diff --git a/Documentation/devicetree/bindings/power/opp-modifier.txt 
 b/Documentation/devicetree/bindings/power/opp-modifier.txt
 new file mode 100644
 index 000..af8a2e9
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/power/opp-modifier.txt
 @@ -0,0 +1,111 @@
 +* OPP-Modifier - opp modifier to selectively enable operating points
 +
 +Many SoCs that have selectively modifiable OPPs can specify
 +all available OPPs in their operating-points listing and then define
 +opp_modifiers to enable or disable the OPPs that are actually available
 +on the specific hardware.
 +
 +* OPP Modifier Provider

Uggg. Please stop designing around the current OPP binding which has
the problem that the OPP table is not extensible to add more data.
Define a new OPP binding that solves these problems. This is at least
the 3rd OPP related binding addition I've seen recently. But I
wouldn't spend a lot of effort on a new OPP binding just to add the
functionality you are adding here because I don't like the whole
concept in general. This might be a common way to determine valid OPPs
on TI chips, but I think it is too low level and I don't want to see
bindings for every different possible way. Just add platform code to
do the OPP setup you need.

Frankly, I prefer the bootloader/firmware fixup the OPP table approach
mentioned in the cpufreq-cpu0 thread. Somewhat less desirable, but the
kernel could do the fixups as well (via of_update_property).

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/5] ARM: OMAP2+: timer: Add clocksource initialization and powerup support

[Rob Herring]

On Fri, Mar 14, 2014 at 4:09 PM, Kevin Hilman khil...@linaro.org wrote:
 Joel Fernandes jo...@ti.com writes:

 On 03/13/2014 04:52 PM, Rob Herring wrote:
 On Thu, Mar 13, 2014 at 3:35 PM, Joel Fernandes jo...@ti.com wrote:
 Introduce a generic omap timer initialization function that can
 be used by all SoCs for which support is available in the clocksource
 driver introduced in the series.

 The function will also be responsible for calling clock initialization
 required for everything else to work.

 Signed-off-by: Joel Fernandes jo...@ti.com

[snip]

 +void omap_generic_timer_init(void)
 +{
 +   if (!of_have_populated_dt())
 +   BUG_ON(Generic timer init should only be used for DT 
 boot\n);

 I thought omap2 is always DT boot now.

 That's right, sorry- I'll get rid of the check.

 Actually, mainline still supports legacy boot and has board files for
 OMAP3 platforms, and we shouldn't break legacy boot on purpose IMO.

It is not breaking anything. You'd have to call this function
mistakenly from a legacy machine desc or other non-DT boot path. It's
a question of how paranoid you are adding checks. IMHO, the BUG_ON is
quite pointless here. You are not likely to progress much further
anyway, and you won't see the BUG print because the serial port is not
up yet.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/5] ARM: OMAP2+: timer: Add clocksource initialization and powerup support

[Rob Herring]

On Thu, Mar 13, 2014 at 3:35 PM, Joel Fernandes jo...@ti.com wrote:
 Introduce a generic omap timer initialization function that can
 be used by all SoCs for which support is available in the clocksource
 driver introduced in the series.

 The function will also be responsible for calling clock initialization
 required for everything else to work.

 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  arch/arm/mach-omap2/common.h |1 +
  arch/arm/mach-omap2/timer.c  |   28 
  2 files changed, 29 insertions(+)

 diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
 index a6aae30..e58d9a4 100644
 --- a/arch/arm/mach-omap2/common.h
 +++ b/arch/arm/mach-omap2/common.h
 @@ -92,6 +92,7 @@ extern void omap3_secure_sync32k_timer_init(void);
  extern void omap3_gptimer_timer_init(void);
  extern void omap4_local_timer_init(void);
  extern void omap5_realtime_timer_init(void);
 +void omap_generic_timer_init(void);

  void omap2420_init_early(void);
  void omap2430_init_early(void);
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index 74044aa..08c73a0 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -324,6 +324,25 @@ static int __init omap_dm_timer_init_one(struct 
 omap_dm_timer *timer,
 return r;
  }

 +int __init omap_dmtimer_powerup(struct omap_dm_timer *timer,
 +   struct device_node *np) {

This function seems unrelated to the commit message.

 +   struct omap_hwmod *oh;
 +   const char *oh_name = NULL;
 +
 +   of_property_read_string_index(np, ti,hwmods, 0, oh_name);
 +   if (!oh_name)
 +   return -ENODEV;
 +
 +   oh = omap_hwmod_lookup(oh_name);
 +   if (!oh)
 +   return -ENODEV;
 +
 +   omap_hwmod_setup_one(oh_name);
 +
 +   omap_hwmod_enable(oh);
 +   return 0;
 +}
 +
  static void __init omap2_gp_clockevent_init(int gptimer_id,
 const char *fck_source,
 const char *property)
 @@ -615,6 +634,15 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, 
 ti,timer-alwon,
2, sys_clkin_ck, NULL);
  #endif

 +void omap_generic_timer_init(void)
 +{
 +   if (!of_have_populated_dt())
 +   BUG_ON(Generic timer init should only be used for DT 
 boot\n);

I thought omap2 is always DT boot now.

 +
 +   omap_clk_init();

Can't you use CLK_OF_DECLARE and remove this? Then you can remove the
init_time function hook completely.

 +   clocksource_of_init();
 +}
 +
  #ifdef CONFIG_ARCH_OMAP4
  #ifdef CONFIG_HAVE_ARM_TWD
  static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
 --
 1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/9] drivers: dma: Add support for dma-channel router

[Rob Herring]

On Fri, Mar 7, 2014 at 6:16 AM, Sricharan R r.sricha...@ti.com wrote:
 In some SoCs the dma request lines from the peripherals are
 routed to the dma-controller through a crossbar. With this the
 dma controller's available request lines are shared between the
 peripherals.

 This adds support to register the crossbar router associated with
 a dma-channel and let the dma-controller driver map/unmap
 the peripheral dma crossbar line to dma-controller's request
 line.

This is not a unique concept and should follow some existing pattern.
Perhaps something like interrupt-map. For the dmas property, the
parent should be the crossbar and then the crossbar block has to
translate that into the DMA controller request. All the DMA ctrlr
request connections should be described in the crossbar node. In
theory, you could have chained crossbars. This should be documented as
part of the generic DMA binding.

There are also other similar IP like CoreSight CTI which are just
signal routers. So there is probably some possibility of common code
here.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: EDMA: Use platform_get_resource functions for DT

[Rob Herring]

On Fri, Feb 21, 2014 at 11:36 AM, Joel Fernandes jo...@ti.com wrote:
 On 02/21/2014 06:15 AM, Mark Rutland wrote:
 Also, while at it get rid of the assumption in the code that CC is at reg
 index 0 in the DT and xbar is at offset 1. Instead use reg-names to get the
 memory resource in concern keeping things much cleaner and simpler. This 
 also
 makes it possible to have multiple channel controllers.

 While this is nice I think we have to have a fallback to the existing
 behaviour if there's no reg-names property present, unless we know for
 certain no-one is possibly using an existing DTB.

 Yes, its true it break existing DTBs but currently only 2 TI SoCs use EDMA 
 this
 way, the vast majority of EDMA users are yet to follow where we can do it 
 right.
  Further, the old bindings are really limiting specially the 2 CC case and if
 additionally memory maps are used in the future. So keeping the old binding is
 limiting in this regard.

 Here is what the platform_data used to look like when used by mach-davinci:

 static struct resource da850_edma_resources[] = {
 {
 .name   = edma_cc0,
 .start  = DA8XX_TPCC_BASE,
 .end= DA8XX_TPCC_BASE + SZ_32K - 1,
 .flags  = IORESOURCE_MEM,
 },
 {
 .name   = edma_tc0,
 .start  = DA8XX_TPTC0_BASE,
 .end= DA8XX_TPTC0_BASE + SZ_1K - 1,
 .flags  = IORESOURCE_MEM,
 },
 {
 .name   = edma_tc1,
 .start  = DA8XX_TPTC1_BASE,
 .end= DA8XX_TPTC1_BASE + SZ_1K - 1,
 .flags  = IORESOURCE_MEM,
 },
 {
 .name   = edma_cc1,
 .start  = DA850_TPCC1_BASE,
 .end= DA850_TPCC1_BASE + SZ_32K - 1,
 .flags  = IORESOURCE_MEM,
 },

 As you can see, there are several memory maps and different interpretations.
 Considering this, IMO- it makes sense to pay a small price to keep the 
 semantics
 sane.

Then do 1 compatible string per interpretation. That can then define
the number of CCs and TCs.


 On the other hand, the other 2 options are:
 1. We add a fallback if reg-names look up fails.

reg-names is supposed to be optional, so you should already have that fallback.

Rob

 2. We inject reg-names property into edma DT nodes that don't have them, and
 make sure all future dtsi with edma nodes mention the reg-names property.

 These 2 are a bit error prone though, for example if someone deliberately
 forgets to mention reg-names, and the code still works, but misbehaves in 
 some way.

 Regards,
 -Joel


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv1 1/6] HSI: add Device Tree support for HSI clients

[Rob Herring]

On Sun, Feb 23, 2014 at 5:49 PM, Sebastian Reichel s...@debian.org wrote:
 Add new method hsi_add_clients_from_dt, which can be used
 to initialize HSI clients from a device tree node.

 The patch also documents the DT binding for trivial HSI
 clients.

 Signed-off-by: Sebastian Reichel s...@debian.org
 ---
  .../devicetree/bindings/hsi/trivial-devices.txt| 36 +++
  drivers/hsi/hsi.c  | 70 
 +-
  include/dt-bindings/hsi/hsi.h  | 17 ++
  include/linux/hsi/hsi.h|  2 +
  4 files changed, 124 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/hsi/trivial-devices.txt
  create mode 100644 include/dt-bindings/hsi/hsi.h

 diff --git a/Documentation/devicetree/bindings/hsi/trivial-devices.txt 
 b/Documentation/devicetree/bindings/hsi/trivial-devices.txt
 new file mode 100644
 index 000..1ace14a
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/hsi/trivial-devices.txt
 @@ -0,0 +1,36 @@
 +This is a list of trivial hsi client devices that have simple
 +device tree bindings, consisting only of a compatible field
 +and the optional hsi configuration.
 +
 +If a device needs more specific bindings, such as properties to
 +describe some aspect of it, there needs to be a specific binding
 +document for it just like any other devices.
 +
 +Optional HSI configuration properties:
 +
 +- hsi,mode Bit transmission mode (STREAM or FRAME)

hsi is not a vendor prefix, so all these properties should be hsi-*.

 +   The first value is used for RX and the second one for
 +   TX configuration. If only one value is provided it 
 will
 +   be used for RX and TX.
 +   The assignments may be found in header file
 +   dt-bindings/hsi/hsi.h.
 +- hsi,channels Number of channels to use [1..16]
 +   The first value is used for RX and the second one for
 +   TX configuration. If only one value is provided it 
 will
 +   be used for RX and TX.
 +- hsi,speedMax bit transmission speed (Kbit/s)

Include the units in the prop name: hsi-speed-kbps

 +   The first value is used for RX and the second one for
 +   TX configuration. If only one value is provided it 
 will
 +   be used for RX and TX.
 +- hsi,flow RX flow type (SYNCHRONIZED or PIPELINE)
 +   The assignments may be found in header file
 +   dt-bindings/hsi/hsi.h.
 +- hsi,arb_mode Arbitration mode for TX frame (Round robin, priority)
 +   The assignments may be found in header file
 +   dt-bindings/hsi/hsi.h.
 +
 +This is the list of trivial client devices:
 +
 +Compatible Description
 +== =
 +hsi-char   HSI character device


I've gotten this far and still have no idea what HSI is.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts

[Rob Herring]

On Mon, Dec 30, 2013 at 4:10 PM, Paul Walmsley p...@pwsan.com wrote:
 Hi Grant, Rob,

 On Tue, 10 Dec 2013, Paul Walmsley wrote:

 On Sun, 24 Nov 2013, Grant Likely wrote:

  On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren t...@atomide.com wrote:
   * Tony Lindgren t...@atomide.com [131122 17:16]:
* Tony Lindgren t...@atomide.com [131122 17:09]:
 * Russell King - ARM Linux li...@arm.linux.org.uk [131122 16:56]:
  On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
   + /* See of_device_resource_notify for populating 
   interrupts */
   + for (i = 0; i  num_irq; i++, res++) {
   + res-flags = IORESOURCE_IRQ;
   + res-start = -EPROBE_DEFER;
   + res-end = -EPROBE_DEFER;
 
  NAK.  Definitely a bad idea to start introducing magic values 
  other into
  resources.  Please don't do this.

 Do you have any better ideas on how to sort out this issue then?
   
I guess we could allocate all the resources lazily here, I'll take a 
look
at that.
  
   Here's a version that allocates the resources lazily with the notifier.
   Seems to boot, need to play with it a bit more though to make sure we're
   not overwriting resources for any legacy devices.
 
  Blurg. Using a notifier really feels like we don't have a good handle on
  a reasonable solution yet. Basically it means we're hooking into the
  driver core without /looking/ like we're hooking into the driver core. I
  don't think this is any better, but I don't have a better suggestion at
  the moment.   :-(

 Unfortunately this patch, or something that accomplishes the same results,
 is somewhat high-priority for us on OMAP.  OMAP37xx got prematurely
 converted to DT booting, and now dynamic power management is broken:

 http://marc.info/?l=linux-arm-kernelm=138658294830408w=2

 Tony writes that this patch is one of the two patches needed to get things
 working again:

 http://marc.info/?l=linux-arm-kernelm=138660942506846w=2

 Is it possible to get this patch, or something similar, merged for
 v3.13-rc?

 Once something like PM is broken, it's pretty easy for other broken
 patches to make it into the tree, since it becomes very difficult to test
 without turning into a maintainer denial-of-service attack.

 Ping.  Could you please provide some guidance here about what you'd need
 to get this solved for v3.13-rc?

I agree with doing the platform_get_irq modification and feel free to
add my ack. I'm going to be offline for the next week.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: doc: Document missing binding for omap5-mpu

[Rob Herring]

On Fri, Nov 8, 2013 at 4:38 AM, Sricharan R r.sricha...@ti.com wrote:
 The binding and support for omap5-mpu which has a cortex-a15
 smp core, gic and integrated L2 cache has been existing for sometime.
 So Documenting the missing binding here.

 Cc: Benoit Cousson bcous...@baylibre.com
 Signed-off-by: Sricharan R r.sricha...@ti.com
 ---
  Documentation/devicetree/bindings/arm/omap/mpu.txt |8 
  1 file changed, 8 insertions(+)

Applied for 3.13.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/8] ARM: OMAP2+: timer: Introduce OF-friendly clocksource/clockevent system timers

[Rob Herring]

On Fri, Nov 22, 2013 at 7:12 PM, Joel Fernandes jo...@ti.com wrote:
 Adding Thomas to the thread since discussion is about clocksource, and Mark
 Rutland as discussion is related to timers and DT, thanks.

 On 11/22/2013 02:01 PM, Rob Herring wrote:
 On Fri, Nov 22, 2013 at 10:42 AM, Joel Fernandes jo...@ti.com wrote:
 On 11/22/2013 09:58 AM, Rob Herring wrote:
 On Thu, Nov 21, 2013 at 7:56 PM, Joel Fernandes jo...@ti.com wrote:
 This work is a migration effort of OMAP system timers to the
 clocksource/clockevent framework. Consider this as a first-pass in this 
 effort.
 There are few cleanups that need to be done first. The HWMOD code is
 intertwined with the timer code. HWMOD code cleanups in the future will
 hopefully make most of this code go away, so till then we separate out the
 power/clocks portion of the code from the actual timer bits.  This will
 facilitate near-future work of adapting the system timer as a clocksource.

 New functions for OF-only boot are introduced, and we can soon delete the 
 old
 versions once we migrate all platforms. Currently only AM335x is migrated 
 and
 testedA new omap_generic_timer_init function is introduced for DT 
 platforms.
 Code required earlier for non-DT platforms such as setup of timer IDs and 
 timer
 parent clock is not required.  parent clocks are automatically setup by 
 the mux
 clock driver through DT so they no longer need to be hardcoded.

 The init code will try to pick the best timer for clocksource and 
 clockevent
 however bindings are added to force a particular timer as clocksource or
 clockevent through DT.

 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  .../devicetree/bindings/arm/omap/timer.txt |  12 ++
  arch/arm/mach-omap2/common.h   |   1 +
  arch/arm/mach-omap2/timer.c| 235 
 +
  3 files changed, 248 insertions(+)

 diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt 
 b/Documentation/devicetree/bindings/arm/omap/timer.txt
 index d02e27c..6cf7a75 100644
 --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
 @@ -32,6 +32,18 @@ Optional properties:
  - ti,timer-secure: Indicates the timer is reserved on a secure OMAP 
 device
 and therefore cannot be used by the kernel.

 +- ti,timer-clockevent,
 +  ti,timer-clocksource These properties force the system timer code to 
 choose
 +   the particular timer as a clockevent or 
 clocksource.
 +   If these properties are not specified, the timer 
 code
 +   picks up a ti,timer-alwon as the clocksource 
 and a
 +   timer containing one of the following properties 
 as
 +   the clockevent in the following order:
 +   ti,timer-alwon
 +   ti,timer-dsp
 +   ti,timer-pwm
 +   ti,timer-secure

 These properties were added specifically for the reason of avoiding
 linux specific properties like these. When is this not sufficient?

 Some platforms cannot use certain timers as clockevents and clocksource, to 
 keep
 this code functionally equivalent and working, I added these properties so 
 that
 its possible to select specific timers as clockevents/sources as was being 
 done
 in the non-DT case. I'm open to suggestions for doing this in a better way 
 for DT.

 There has to be a defined reason why a given timer cannot be used. You
 are not explaining what that reason is. Define a property or set of
 properties that describe the h/w feature or quirk.

 Reason? There are HW bugs that prevent a timer from being used. See [1]. And
 there may be other reasons, I haven't written this code but I know that there
 are other HW bugs that made authors pick a specific timer such as board issues
 or accuracy.

Bugs are a feature of the h/w. Add a ti,timer-broken property if you
don't know the specific bug. Accuracy is a function of counter bit
size and frequency. The only board issues for a timer I can imagine is
you want to reserve timers with output compare or input capture pins
for other uses. These are all properties that you can describe in the
binding. If you just don't want to use a timer for some arbitrary
reason, then add a 'status = disabled;' property.


 This is nothing new, just that I'm trying to find a way to do it from DT.

 You can see the ifdef'ry below in mach-omap2/timer.c. All I'm trying to do is
 make it simpler and cleaner by adding these properties to DT so that we can
 delete this code entirely.


 #ifdef CONFIG_ARCH_OMAP2
 OMAP_SYS_32K_TIMER_INIT(2, 1, timer_32k_ck, ti,timer-alwon,
 2, timer_sys_ck, NULL);
 #endif /* CONFIG_ARCH_OMAP2 */

 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
 OMAP_SYS_32K_TIMER_INIT(3, 1, timer_32k_ck, ti,timer-alwon

Re: [PATCH 5/8] ARM: OMAP2+: timer: Introduce OF-friendly clocksource/clockevent system timers

[Rob Herring]

On Thu, Nov 21, 2013 at 7:56 PM, Joel Fernandes jo...@ti.com wrote:
 This work is a migration effort of OMAP system timers to the
 clocksource/clockevent framework. Consider this as a first-pass in this 
 effort.
 There are few cleanups that need to be done first. The HWMOD code is
 intertwined with the timer code. HWMOD code cleanups in the future will
 hopefully make most of this code go away, so till then we separate out the
 power/clocks portion of the code from the actual timer bits.  This will
 facilitate near-future work of adapting the system timer as a clocksource.

 New functions for OF-only boot are introduced, and we can soon delete the old
 versions once we migrate all platforms. Currently only AM335x is migrated and
 testedA new omap_generic_timer_init function is introduced for DT platforms.
 Code required earlier for non-DT platforms such as setup of timer IDs and 
 timer
 parent clock is not required.  parent clocks are automatically setup by the 
 mux
 clock driver through DT so they no longer need to be hardcoded.

 The init code will try to pick the best timer for clocksource and clockevent
 however bindings are added to force a particular timer as clocksource or
 clockevent through DT.

 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  .../devicetree/bindings/arm/omap/timer.txt |  12 ++
  arch/arm/mach-omap2/common.h   |   1 +
  arch/arm/mach-omap2/timer.c| 235 
 +
  3 files changed, 248 insertions(+)

 diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt 
 b/Documentation/devicetree/bindings/arm/omap/timer.txt
 index d02e27c..6cf7a75 100644
 --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
 @@ -32,6 +32,18 @@ Optional properties:
  - ti,timer-secure: Indicates the timer is reserved on a secure OMAP 
 device
 and therefore cannot be used by the kernel.

 +- ti,timer-clockevent,
 +  ti,timer-clocksource These properties force the system timer code to choose
 +   the particular timer as a clockevent or clocksource.
 +   If these properties are not specified, the timer code
 +   picks up a ti,timer-alwon as the clocksource and a
 +   timer containing one of the following properties as
 +   the clockevent in the following order:
 +   ti,timer-alwon
 +   ti,timer-dsp
 +   ti,timer-pwm
 +   ti,timer-secure

These properties were added specifically for the reason of avoiding
linux specific properties like these. When is this not sufficient?

And I agree with the comment to use OF_CLKSRC.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/8] ARM: OMAP2+: timer: Introduce OF-friendly clocksource/clockevent system timers

[Rob Herring]

On Fri, Nov 22, 2013 at 10:42 AM, Joel Fernandes jo...@ti.com wrote:
 On 11/22/2013 09:58 AM, Rob Herring wrote:
 On Thu, Nov 21, 2013 at 7:56 PM, Joel Fernandes jo...@ti.com wrote:
 This work is a migration effort of OMAP system timers to the
 clocksource/clockevent framework. Consider this as a first-pass in this 
 effort.
 There are few cleanups that need to be done first. The HWMOD code is
 intertwined with the timer code. HWMOD code cleanups in the future will
 hopefully make most of this code go away, so till then we separate out the
 power/clocks portion of the code from the actual timer bits.  This will
 facilitate near-future work of adapting the system timer as a clocksource.

 New functions for OF-only boot are introduced, and we can soon delete the 
 old
 versions once we migrate all platforms. Currently only AM335x is migrated 
 and
 testedA new omap_generic_timer_init function is introduced for DT platforms.
 Code required earlier for non-DT platforms such as setup of timer IDs and 
 timer
 parent clock is not required.  parent clocks are automatically setup by the 
 mux
 clock driver through DT so they no longer need to be hardcoded.

 The init code will try to pick the best timer for clocksource and clockevent
 however bindings are added to force a particular timer as clocksource or
 clockevent through DT.

 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  .../devicetree/bindings/arm/omap/timer.txt |  12 ++
  arch/arm/mach-omap2/common.h   |   1 +
  arch/arm/mach-omap2/timer.c| 235 
 +
  3 files changed, 248 insertions(+)

 diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt 
 b/Documentation/devicetree/bindings/arm/omap/timer.txt
 index d02e27c..6cf7a75 100644
 --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
 @@ -32,6 +32,18 @@ Optional properties:
  - ti,timer-secure: Indicates the timer is reserved on a secure OMAP 
 device
 and therefore cannot be used by the kernel.

 +- ti,timer-clockevent,
 +  ti,timer-clocksource These properties force the system timer code to 
 choose
 +   the particular timer as a clockevent or clocksource.
 +   If these properties are not specified, the timer 
 code
 +   picks up a ti,timer-alwon as the clocksource and a
 +   timer containing one of the following properties as
 +   the clockevent in the following order:
 +   ti,timer-alwon
 +   ti,timer-dsp
 +   ti,timer-pwm
 +   ti,timer-secure

 These properties were added specifically for the reason of avoiding
 linux specific properties like these. When is this not sufficient?

 Some platforms cannot use certain timers as clockevents and clocksource, to 
 keep
 this code functionally equivalent and working, I added these properties so 
 that
 its possible to select specific timers as clockevents/sources as was being 
 done
 in the non-DT case. I'm open to suggestions for doing this in a better way 
 for DT.

There has to be a defined reason why a given timer cannot be used. You
are not explaining what that reason is. Define a property or set of
properties that describe the h/w feature or quirk.


 And I agree with the comment to use OF_CLKSRC.


 There are difficulties I mentioned in a previous post [1] stating why it may 
 not
 be possible to use OF_CLKSRC macros, and still keep the code functionally
 equivalent to when it was non-DT.

Sorry, I don't buy it.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 2/2] ARM: dts: doc: Document missing binding for ti-sdma controller

[Rob Herring]

On Mon, Nov 11, 2013 at 10:06 AM, Sricharan R r.sricha...@ti.com wrote:
 The binding and support for system DMA module present in OMAP2+ Socs
 and DRA7 with dma-engine is already present. So adding the missing
 documentation for the same.

 Signed-off-by: Sricharan R r.sricha...@ti.com

Acked-by: Rob Herring rob.herr...@calxeda.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html