Re: [PATCH] ARM: dts: add support for Ka-Ro TX51

[Shawn Guo]

On Mon, Jun 23, 2014 at 12:18:39PM +0200, Lothar Waßmann wrote:
...
> > > + phy-handle = <&phy0>;
> > > + mac-address = []; /* will be set by U-Boot */
> > 
> > Shouldn't it be local-mac-address?
> > 
> probably yes, but both 'mac-address' and 'local-mac-address' are being
> set up by U-Boot anyway.

Okay, never mind.  I just realized kernel supports both properties.

...

> > > +&esdhc1 {
> > > + cd-gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
> > > + fsl,wp-controller;
> > 
> > Does it work for you, since the driver does not support it as of today?
> > 
> What driver doesn't support what?
> AFAICT the sdhci-esdhc-imx.c driver supports both of these properties.

That was the case before, but it's not the case since commit
89d7e5c13122 (mmc: sdhci-esdhc-imx: add runtime pm support).

http://thread.gmane.org/gmane.linux.kernel.mmc/27287

...

> > > + spidev0: spi@0 {
> > > + compatible = "spidev";
> > > + reg = <0>;
> > > + spi-max-frequency = <5400>;
> > > + };
> > > +
> > > + spidev1: spi@1 {
> > > + compatible = "spidev";
> > > + reg = <1>;
> > > + spi-max-frequency = <5400>;
> > > + };
> > 
> > I'm not sure we should have these two devices.
> > 
> Why not? With this the SPI bus can readily be used with the spidev
> driver from Documentation/spi/spidev_test.c (which is what most of our
> customers are asking for)!

Is this something that has been approved by DT maintainers?  I do not
see "spidev" documented as a compatible in any bindings doc.

Shawn
--
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

Re: [PATCH 3/4 v2] ARM: DTS: use new compatible string for thermistors in trats2

[Chanwoo Choi]

On 06/25/2014 03:29 PM, Naveen Krishna Chatradhi wrote:
> As Murata Manufactures the NTC based thermistors. The vendor
> name in the compatibility is preposed to change to "murata"
> 
> This patch uses the new compatibility string in exynos4412 based
> Trats2 board.
> 
> Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Chanwoo Choi 
> ---
> Changes since v1:
> None
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 11967f4..d35755a 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -771,7 +771,7 @@
>   };
>  
>   thermistor-ap@0 {
> - compatible = "ntc,ncp15wb473";
> + compatible = "murata,ncp15wb473";
>   pullup-uv = <180>;   /* VCC_1.8V_AP */
>   pullup-ohm = <10>;   /* 100K */
>   pulldown-ohm = <10>; /* 100K */
> @@ -779,7 +779,7 @@
>   };
>  
>   thermistor-battery@1 {
> - compatible = "ntc,ncp15wb473";
> + compatible = "murata,ncp15wb473";
>   pullup-uv = <180>;   /* VCC_1.8V_AP */
>   pullup-ohm = <10>;   /* 100K */
>   pulldown-ohm = <10>; /* 100K */
> 

Looks good to me.

Reviewed-by: Chanwoo Choi 

Thanks,
Chanwoo Choi
--
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

[PATCH 1/4 v2] devicetree: bindings: Document murata vendor prefix

[Naveen Krishna Chatradhi]

Add Murata Manufacturing Co., Ltd. to the list of device tree
vendor prefixes.

Murata manufactures NTC (Negative Temperature Coefficient) based
Thermistors for small scale applications like Mobiles and PDAs.

Signed-off-by: Naveen Krishna Chatradhi 
Acked-by: Mark Rutland 
Cc: Guenter Roeck 
---
Changes since v1:
1. Rearranged vendor-prefix alphabetically
2. Added Acked-by from Mark Rutland

 .../devicetree/bindings/vendor-prefixes.txt|1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4d7f375..46a311e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -83,6 +83,7 @@ mosaixtechMosaix Technologies, Inc.
 moxa   Moxa
 mplMPL AG
 mundoreaderMundo Reader S.L.
+murata Murata Manufacturing Co., Ltd.
 mxicy  Macronix International Co., Ltd.
 national   National Semiconductor
 neonodeNeonode Inc.
-- 
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

[PATCH 0/4 v2] hwmon: ntc_thermistor: prepose vendor prefix change

[Naveen Krishna Chatradhi]

As Murata is the manufacturer of the NTC (Negative Temperature coefficient)
based Thermistors. ntc_thermistor driver extensively used the prefix "ntc".
But, vendor-prefix should be "murata" instead of "ntc".

This patchset
1. Updates the vendor-prefix, DT bindings and Documentation,
   where ever necessary.
2. Adds thermistor nodes to Exynos5420 based Peach PIT board.

Patches:
1/4. devicetree: bindings: Document murata vendor prefix
 Adds the vendor prefix "murata" to vendor-prefixes.txt.
2/4. hwmon: ntc_thermistor: Use the manufacturer name properly
 Updates the driver, Kconfig, device tree bindings and Documentation
 with the Manufacturer/vendor information.
 Keeps the old bindings marked as  in code and Documentation
3/4. ARM: DTS: use new compatible string as per the documentation
 Updates the device node in Exynos4412 based Trats2 board
 with the new device tree bindings.
4/4. ARM: DTS: Add NTC thermistor nodes as child nodes to ADC
 Adds Thermistor nodes to Exynos5420 based Peach PIT board.

This patchset
Naveen Krishna Chatradhi (4):
  devicetree: bindings: Document murata vendor prefix
  hwmon: ntc_thermistor: Use the manufacturer name properly
  ARM: DTS: use new compatible string as per the documentation
  ARM: DTS: Add NTC thermistor nodes to Exynos5420 based Peach_PIT

 .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
 .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   20 
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 Documentation/hwmon/ntc_thermistor |8 ++---
 arch/arm/boot/dts/exynos4412-trats2.dts|4 +--
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   34 
 drivers/hwmon/Kconfig  |5 +--
 drivers/hwmon/ntc_thermistor.c |   14 +++-
 8 files changed, 72 insertions(+), 16 deletions(-)

-- 
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

[PATCH 3/4 v2] ARM: DTS: use new compatible string for thermistors in trats2

[Naveen Krishna Chatradhi]

As Murata Manufactures the NTC based thermistors. The vendor
name in the compatibility is preposed to change to "murata"

This patch uses the new compatibility string in exynos4412 based
Trats2 board.

Signed-off-by: Naveen Krishna Chatradhi 
Cc: Chanwoo Choi 
---
Changes since v1:
None

 arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 11967f4..d35755a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -771,7 +771,7 @@
};
 
thermistor-ap@0 {
-   compatible = "ntc,ncp15wb473";
+   compatible = "murata,ncp15wb473";
pullup-uv = <180>;   /* VCC_1.8V_AP */
pullup-ohm = <10>;   /* 100K */
pulldown-ohm = <10>; /* 100K */
@@ -779,7 +779,7 @@
};
 
thermistor-battery@1 {
-   compatible = "ntc,ncp15wb473";
+   compatible = "murata,ncp15wb473";
pullup-uv = <180>;   /* VCC_1.8V_AP */
pullup-ohm = <10>;   /* 100K */
pulldown-ohm = <10>; /* 100K */
-- 
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

[PATCH 2/4 v2] hwmon: ntc_thermistor: Use the manufacturer name properly

[Naveen Krishna Chatradhi]

Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses "NTC" as the vendor name.

This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt

Note: Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.

Signed-off-by: Naveen Krishna Chatradhi 
Cc: Guenter Roeck 
---
Changes since v1:
1. Kept the old compatible string marked as  in code and
   in the Documentation.

 .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
 .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   20 ++--
 Documentation/hwmon/ntc_thermistor |8 
 drivers/hwmon/Kconfig  |5 +++--
 drivers/hwmon/ntc_thermistor.c |   14 +-
 5 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..832fe8c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -48,7 +48,7 @@ adc@12D1 {
 
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
-   compatible = "ntc,ncp15wb473";
+   compatible = "murata,ncp15wb473";
pullup-uv = <180>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index c6f6667..b117b2e 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -3,11 +3,19 @@ NTC Thermistor hwmon sensors
 
 Requires node properties:
 - "compatible" value : one of
-   "ntc,ncp15wb473"
-   "ntc,ncp18wb473"
-   "ntc,ncp21wb473"
-   "ntc,ncp03wb473"
-   "ntc,ncp15wl333"
+   "murata,ncp15wb473"
+   "murata,ncp18wb473"
+   "murata,ncp21wb473"
+   "murata,ncp03wb473"
+   "murata,ncp15wl333"
+
+/* Usage of vendor name "ntc" is deprecated */
+   "ntc,ncp15wb473"
+   "ntc,ncp18wb473"
+   "ntc,ncp21wb473"
+   "ntc,ncp03wb473"
+   "ntc,ncp15wl333"
+
 - "pullup-uv"  Pull up voltage in micro volts
 - "pullup-ohm" Pull up resistor value in ohms
 - "pulldown-ohm" Pull down resistor value in ohms
@@ -21,7 +29,7 @@ Read more about iio bindings at
 
 Example:
ncp15wb473@0 {
-   compatible = "ntc,ncp15wb473";
+   compatible = "murata,ncp15wb473";
pullup-uv = <180>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
diff --git a/Documentation/hwmon/ntc_thermistor 
b/Documentation/hwmon/ntc_thermistor
index 3bfda94..057b770 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -1,7 +1,7 @@
 Kernel driver ntc_thermistor
 =
 
-Supported thermistors:
+Supported thermistors from Murata:
 * Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, 
NCP15WL333
   Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', 
'ncp15wl333'
   Datasheet: Publicly available at Murata
@@ -15,9 +15,9 @@ Authors:
 Description
 ---
 
-The NTC thermistor is a simple thermistor that requires users to provide the
-resistance and lookup the corresponding compensation table to get the
-temperature input.
+The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
+that requires users to provide the resistance and lookup the corresponding
+compensation table to get the temperature input.
 
 The NTC driver provides lookup tables with a linear approximation function
 and four circuit models with an option not to use any of the four models.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..154851b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1052,7 +1052,7 @@ config SENSORS_PC87427
  will be called pc87427.
 
 config SENSORS_NTC_THERMISTOR
-   tristate "NTC thermistor support"
+   tristate "NTC thermistor support from Murata"
depends on !OF || IIO=n || IIO
help
  This driver supports NTC thermistors sensor reading and its
@@ -1060,7 +1060,8 @@ config SENSORS_NTC_THERMISTOR
  send notifications about the temperature.
 
  Currently, this driver supports
- NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333.
+ NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333
+ from Murata.
 
  This driver can also be built as a module.  If so, the module
  will be called ntc-thermistor.
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index e76feb86..bdfbe91 10

[PATCH 4/4 v2] ARM: DTS: Add NTC thermistor nodes to Exynos5420 based Peach_PIT

[Naveen Krishna Chatradhi]

Exynos5420 based Peach PIT board has 4 NTC thermistors to measure
temperatures at various points on the board.

IIO based ADC becomes the parent and NTC thermistors are the childs,
via the HWMON interface.

Signed-off-by: Naveen Krishna Chatradhi 
Cc: Doug Anderson 
---
Changes since v1:
1. Arranged the ADC node alphabetical
2. Added "status = "okay"" to the ADC node

This patch needs
1. MAX77802 PMIC device tree nodes (for ldo9)
   https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html
2. Uses the DT documentation for NTC thermistors updated with vendor-prefix

This patch set is tested
1. On Peach PIT board via sysfs entry exposed by hwmon
localhost ~ # cat /sys/class/hwmon/hwmon*/device/temp1_input

  
37436
36449
38560
38059

2. Backward compatibility is tested by replacing "murata" with "ntc"
   in the dts nodes and running the above test.

 arch/arm/boot/dts/exynos5420-peach-pit.dts |   34 
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index b96a66a..19d733d 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -101,6 +101,40 @@
};
 };
 
+&adc {
+   status = "okay";
+   vdd-supply = <&ldo9_reg>;
+
+   ncp15wb473@3 {
+   compatible = "murata,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = <&adc 3>;
+   };
+   ncp15wb473@4 {
+   compatible = "murata,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = <&adc 4>;
+   };
+   ncp15wb473@5 {
+   compatible = "murata,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = <&adc 5>;
+   };
+   ncp15wb473@6 {
+   compatible = "murata,ncp15wb473";
+   pullup-uv = <180>;
+   pullup-ohm = <47000>;
+   pulldown-ohm = <0>;
+   io-channels = <&adc 6>;
+   };
+};
+
 &dp {
status = "okay";
pinctrl-names = "default";
-- 
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

Re: [PATCH v8 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

[David Miller]

From: Iyappan Subramanian 
Date: Fri, 20 Jun 2014 16:18:16 -0700

> This patch adds network driver for APM X-Gene SoC ethernet.
> 
> Signed-off-by: Iyappan Subramanian 
> Signed-off-by: Ravi Patel 
> Signed-off-by: Keyur Chudgar 

I really don't like how you handle the hardware descriptors in this
driver.

You copy back and forth between a software format and the hardware
format.  That's extremely wasteful and will hurt performance.

Just use the raw format throughout, you can extract the fields when
you need them.

You also make two passes when building a hardware descriptor:

1) write the values
2) endian swap

This means you make three memory accesses on every 64-bit word
in every descriptor you setup, this is really inefficient.

You should just byte swap them in-situ as you build the raw
descriptors.
--
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

Re: [PATCH 4/4] ARM: DTS: Add NTC thermistor nodes as child nodes to ADC

[Naveen Krishna Ch]

Doug,

On 25 June 2014 03:24, Doug Anderson  wrote:
> Naveen,
>
> On Tue, Jun 24, 2014 at 5:19 AM, Naveen Krishna Chatradhi
>  wrote:
>> Exynos5420 based Peach PIT and Exynos5800 based PI boards have
>> 4 NTC thermistors to measure temperatures at various points on the
>> board.
>>
>> IIO based ADC becomes the parent and NTC thermistors are the childs,
>> via the HWMON interface.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: Doug Anderson 
>> ---
>> This patch needs
>> 1. MAX77802 PMIC device tree nodes (for ldo9)
>>https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html
>> 2. Uses the DT documentation for NTC thermistors updated with vendor-prefix
>>
>>  arch/arm/boot/dts/exynos5420-peach-pit.dts |   32 
>> 
>>  1 file changed, 32 insertions(+)
>
> * You forgot: status="okay" for the ADC.  One might question how this
> patch was tested.

Will correct it.

>
> * Please also include this change for pi.

MAX77802 device node was not added for Peach_PI (exynos5800-peach-pi.dts).
I guess, Javier have a plan to send.

I will edit the commit message to remove Peach_PI for now.

Also, we have few similar nodes on Peach PI  and Peach PIT.
Any plans or discussion on merging the common nodes ?

>
> * We just got through the painful process of sorting this .dts file.
> Please sort "&adc" alphabetically.  Kukjin: please confirm that you
> will keep an eye on patches and make sure that they are sorted OK.
>
>
> Other than those problems this seems to work fine to me.
>
> -Doug

Thanks for the Review.


-- 
Shine bright,
(: Nav :)
--
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

Re: [PATCH v2 REBASED 06/10] serial/arc: remove last remanants of platform data

[Vineet Gupta]

On Wednesday 25 June 2014 02:31 AM, Rob Herring wrote:
> On Tue, Jun 24, 2014 at 3:25 AM, Vineet Gupta
>  wrote:
>> Signed-off-by: Vineet Gupta 
>> ---
>>  drivers/tty/serial/arc_uart.c | 22 ++
>>  1 file changed, 6 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c
>> index 2ffaf099691a..dc3d5db37dc4 100644
>> --- a/drivers/tty/serial/arc_uart.c
>> +++ b/drivers/tty/serial/arc_uart.c
>
>> @@ -518,21 +516,13 @@ arc_uart_init_one(struct platform_device *pdev, int 
>> dev_id)
>> }
>> uart->baud = val;
>>
>> -   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> -   if (!res)
>> -   return -ENODEV;
>> -
>> -   res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> -   if (!res2)
>> -   return -ENODEV;
>> -
>> -   port->mapbase = res->start;
>> -   port->membase = ioremap_nocache(res->start, resource_size(res));
>> +   port->membase = of_iomap(np, 0);
> ioremap is preferred over of_iomap as it is not OF specific.

I could, but much of the driver assumes OF to be selected already 
(of_property...)

>  Perhaps
> use devm_request_and_ioremap instead.

devm_request_and_ioremap has been flag day removed in favour of
devm_ioremap_resource().
However even then it would require me to retain the prior 
platform_get_resource()
call.
IMHO, of_iomap is must more concise.

>
>> if (!port->membase)
>> /* No point of dev_err since UART itself is hosed here */
>> return -ENXIO;
>>
>> -   port->irq = res2->start;
>> +   port->irq = irq_of_parse_and_map(np, 0);
>> +
> platform_get_irq should be used here.

And this again is for reducing OF dependency or is it something else.

Thx,
-Vineet

>
>> port->dev = &pdev->dev;
>> port->iotype = UPIO_MEM;
>> port->flags = UPF_BOOT_AUTOCONF;
>> --
>> 1.8.3.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

Re: [PATCH v8 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

[Dann Frazier]

On Fri, Jun 20, 2014 at 5:18 PM, Iyappan Subramanian
 wrote:
> This patch adds network driver for APM X-Gene SoC ethernet.
>
> Signed-off-by: Iyappan Subramanian 
> Signed-off-by: Ravi Patel 
> Signed-off-by: Keyur Chudgar 
> ---
>  drivers/net/ethernet/Kconfig   |   1 +
>  drivers/net/ethernet/Makefile  |   1 +
>  drivers/net/ethernet/apm/Kconfig   |   1 +
>  drivers/net/ethernet/apm/Makefile  |   5 +
>  drivers/net/ethernet/apm/xgene/Kconfig |   9 +
>  drivers/net/ethernet/apm/xgene/Makefile|   6 +
>  .../net/ethernet/apm/xgene/xgene_enet_ethtool.c| 125 +++
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 848 +++
>  drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 394 +
>  drivers/net/ethernet/apm/xgene/xgene_enet_main.c   | 939 
> +
>  drivers/net/ethernet/apm/xgene/xgene_enet_main.h   | 109 +++
>  11 files changed, 2438 insertions(+)
>  create mode 100644 drivers/net/ethernet/apm/Kconfig
>  create mode 100644 drivers/net/ethernet/apm/Makefile
>  create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig
>  create mode 100644 drivers/net/ethernet/apm/xgene/Makefile
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c
>  create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h
[...]
> +static struct xgene_enet_desc_ring *xgene_enet_create_desc_ring(
> +   struct net_device *ndev, u32 ring_num,
> +   enum xgene_enet_ring_cfgsize cfgsize, u32 ring_id)
> +{
> +   struct xgene_enet_desc_ring *ring;
> +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
> +   struct device *dev = &pdata->pdev->dev;
> +   u32 size;
> +
> +   ring = devm_kzalloc(dev, sizeof(struct xgene_enet_desc_ring),
> +   GFP_KERNEL);
> +   if (!ring)
> +   return NULL;
> +
> +   ring->ndev = ndev;
> +   ring->num = ring_num;
> +   ring->cfgsize = cfgsize;
> +   ring->id = ring_id;
> +
> +   size = xgene_enet_get_ring_size(dev, cfgsize);
> +   ring->desc_addr = dma_zalloc_coherent(dev, size, &ring->dma,
> + GFP_KERNEL);

Iyappan,
When testing this driver on a 3.16-rc2 base, I'm finding that
desc_addr gets assigned to NULL here, which results in an oops later
on (see below).

I wasn't seeing this before (3.15 base), so I'm guessing something
changed upstream, or in my config, to change this behavior. But it
does illuminate a place where we could maybe use some better error
handling (also see below).

> +   if (!ring->desc_addr)
> +   goto err;
> +   ring->size = size;
> +
> +   ring->cmd_base = pdata->ring_cmd_addr + (ring->num << 6);
> +   ring->cmd = ring->cmd_base + INC_DEC_CMD_ADDR;
> +   pdata->rm = RM3;
> +   ring = xgene_enet_setup_ring(ring);
> +   netdev_dbg(ndev, "ring info: num=%d  size=%d  id=%d  slots=%d\n",
> +  ring->num, ring->size, ring->id, ring->slots);
> +
> +   return ring;
> +err:
> +   dma_free_coherent(dev, size, ring->desc_addr, ring->dma);
> +   devm_kfree(dev, ring);
> +
> +   return NULL;
> +}
> +
> +static u16 xgene_enet_get_ring_id(enum xgene_ring_owner owner, u8 bufnum)
> +{
> +   return (owner << 6) | (bufnum & GENMASK(5, 0));
> +}
> +
> +static int xgene_enet_create_desc_rings(struct net_device *ndev)
> +{
> +   struct xgene_enet_pdata *pdata = netdev_priv(ndev);
> +   struct device *dev = &pdata->pdev->dev;
> +   struct xgene_enet_desc_ring *rx_ring, *tx_ring, *cp_ring;
> +   struct xgene_enet_desc_ring *buf_pool = NULL;
> +   u8 cpu_bufnum = 0, eth_bufnum = 0;
> +   u8 bp_bufnum = 0x20;
> +   u16 ring_id, ring_num = 0;
> +   int ret;
> +
> +   /* allocate rx descriptor ring */
> +   ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
> +   rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
> + RING_CFGSIZE_16KB, ring_id);
> +   if (IS_ERR_OR_NULL(rx_ring)) {
> +   ret = PTR_ERR(rx_ring);
> +   goto err;
> +   }

Here we test for IS_ERR_OR_NULL. In the oops I'm hitting, rx_ring is
NULL here - but PTR_ERR() apparently returns 0 in that case. So this
function ends up returning no error.

> +   /* allocate buffer pool for receiving packets */
> +   ring_id = xgene_enet_get_ring_id(RING_OWNER_ETH0, bp_bufnum++);
> +   buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
> +  RING_CFGSIZE_2KB, ring_id);
> +   if (IS_ERR_OR_NULL(buf_pool)) {
> +   ret = PTR_ERR(buf_pool);
> +

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Doug Anderson]

Tushar,

On Tue, Jun 24, 2014 at 8:09 PM, Tushar Behera  wrote:
> On 06/25/2014 04:29 AM, Doug Anderson wrote:
>> Tushar,
>>
>> On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera  wrote:
>>> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman  wrote:
 Tushar Behera  writes:

> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS.
>
> Though user manual doesn't specify this dependency, we came across
> this issue while disabling the parent of AUDSS mux clocks.
>
> Keeping the parents of AUDSS mux always enabled fixes this issue.

 While this patch works (and fixes the boot problem for me), it seems
 like it's papering over the real problem.

>>>
>>> Thanks for testing.
>>>
 Seems like the right fix is actually modelling the clocks properly so
 that enabling a child clock ensures that the parent is also enabled.

>>>
>>> Patch 2/3 was to ensure we have proper clock tree defined for
>>> Exynos5420. While testing with audio disabled, that patch alone fixed
>>> the issue. But when audio was enabled (and hence I2S0 was trying to
>>> access the clocks), we got some kernel oops during late booting, hence
>>> I came up this solution.
>>>
>>> The solution might be a little half-baked because of the urgency to
>>> push the fix, but will try to dig more into the issue on Monday when I
>>> resume office.
>>
>> Which Monday were you referring to?  ;)
>>
>
> Sorry that I couldn't get deeper into this issue. Thanks for reminding
> though.

No problem.  I know how it is.  I was trying to be funny though
sometimes that doesn't come through very well over email.


>> ...but in all seriousness do you have an official status update on
>> this patch?  It seems as if it's not needed and all you need is
>> , but it would be nice to
>> get an official confirmation.
>
> I have tested various scenarios with only patch 2/3, which seems to be
> sufficient for the time being. I have not encountered the older issue
> till now. I was thinking of testing a bit further, but given that you
> have already asked for, we can go ahead with only patch 2/3 right now.
>
> In case any further issue comes up, I will post patch 1/3 as per the
> review comments that I have got.

Sounds like a plan.  Thanks for getting the original patch sent out so
quickly after I reported it.

Hopefully Kukjin will apply pack 2/3 soon (today?)
--
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

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On 06/25/2014 04:29 AM, Doug Anderson wrote:
> Tushar,
> 
> On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera  wrote:
>> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman  wrote:
>>> Tushar Behera  writes:
>>>
 When the output clock of AUDSS mux is disabled, we are getting kernel
 oops while doing a clk_get() on other clocks provided by AUDSS.

 Though user manual doesn't specify this dependency, we came across
 this issue while disabling the parent of AUDSS mux clocks.

 Keeping the parents of AUDSS mux always enabled fixes this issue.
>>>
>>> While this patch works (and fixes the boot problem for me), it seems
>>> like it's papering over the real problem.
>>>
>>
>> Thanks for testing.
>>
>>> Seems like the right fix is actually modelling the clocks properly so
>>> that enabling a child clock ensures that the parent is also enabled.
>>>
>>
>> Patch 2/3 was to ensure we have proper clock tree defined for
>> Exynos5420. While testing with audio disabled, that patch alone fixed
>> the issue. But when audio was enabled (and hence I2S0 was trying to
>> access the clocks), we got some kernel oops during late booting, hence
>> I came up this solution.
>>
>> The solution might be a little half-baked because of the urgency to
>> push the fix, but will try to dig more into the issue on Monday when I
>> resume office.
> 
> Which Monday were you referring to?  ;)
> 

Sorry that I couldn't get deeper into this issue. Thanks for reminding
though.

> ...but in all seriousness do you have an official status update on
> this patch?  It seems as if it's not needed and all you need is
> , but it would be nice to
> get an official confirmation.

I have tested various scenarios with only patch 2/3, which seems to be
sufficient for the time being. I have not encountered the older issue
till now. I was thinking of testing a bit further, but given that you
have already asked for, we can go ahead with only patch 2/3 right now.

In case any further issue comes up, I will post patch 1/3 as per the
review comments that I have got.

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


-- 
Tushar Behera
--
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

Re: [PATCH v3 2/2] arm: dts: add support for AM437x StarterKit

[Darren Etheridge]

On 06/23/2014 01:20 PM, Felipe Balbi wrote:

Add support for TI's AM437x StarterKit Evaluation
Module.

Cc: Josh Elliot 
Cc: Darren Etheridge 
Signed-off-by: Felipe Balbi 


Tested-by: Darren Etheridge 

I tested with omap2plus_defconfig + additionally enabling OMAPDSS and 
Backlight in .config.  Working great for me with ethernet, sdcard, lcd 
panel and backlight all functional.


dmesg log attached - generated by kernel built from the repo/branch 
Felipe pointed to in the cover letter for this series and obviously 
running on an AM437x StarterKit EVM.


Darren
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.16.0-rc1-next-20140617-00935-g2072735 (darrene@build-laptop) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #5 SMP Tue Jun 24 17:42:32 CDT 2014
[0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[0.00] Machine model: TI AM437x SK EVM
[0.00] cma: CMA: reserved 16 MiB at ae80
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c0956880, node_mem_map edff1000
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00]   HighMem zone: 528 pages used for memmap
[0.00]   HighMem zone: 67584 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM437x ES1.1 (sgx neon )
[0.00] L2C: platform modifies aux control register: 0x0e03 -> 0x3e43
[0.00] L2C: DT/platform modifies aux control register: 0x0e03 -> 0x3e43
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 ID prefetch enabled, offset 1 lines
[0.00] OMAP L2C310: ROM does not support power control setting
[0.00] L2C-310 dynamic clock gating disabled, standby mode disabled
[0.00] L2C-310 cache controller enabled, 16 ways, 256 kB
[0.00] L2C-310: CACHE_ID 0x41c9, AUX_CTRL 0x7e43
[0.00] PERCPU: Embedded 9 pages/cpu @edfb5000 s14336 r8192 d14336 u36864
[0.00] pcpu-alloc: s14336 r8192 d14336 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624
[0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1005092K/1048576K available (6039K kernel code, 705K rwdata, 2388K rodata, 414K init, 8220K bss, 43484K reserved, 270336K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xffe0   (2048 kB)
[0.00] vmalloc : 0xf000 - 0xff00   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xef80   ( 760 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc0843100   (8429 kB)
[0.00]   .init : 0xc0844000 - 0xc08ab800   ( 414 kB)
[0.00]   .data : 0xc08ac000 - 0xc095c498   ( 706 kB)
[0.00].bss : 0xc095c498 - 0xc11635e0   (8221 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] GIC CPU mask not found - kernel will fail to boot.
[0.00] GIC CPU mask not found - kernel will fail to boot.
[0.00] OMAP clockevent source: timer2 at 2400 Hz
[0.12] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
[0.62] OMAP clocksource: timer1 at 2400 Hz
[0.000643] Console: colour dummy device 80x30
[0.000680] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[0.000692] ... MAX_LOCKDEP_SUBCLASSES:  8
[0.000702] ... MAX_LOCK_DEPTH:  48
[0.000711] ... MAX_LOCKDEP_KEYS:8191
[0.000720] ... CLASSHASH_SIZE:  4096
[0.000729] ... MAX_LOCKDEP_ENTRIES: 32768
[0.000738] ... MAX_LOCKDEP_CHAINS:  65536
[0.000747] ... CHAINHASH_SIZE:  32768
[0.000756]  memory used by lock dependency info: 5167 kB
[0.000765]  per task-struct memory footprint: 1152 bytes
[0.000804] Calibrating delay loop... 1993.93 BogoMIPS (lpj=9969664)
[0.119229] pid_max: default: 32768 minimum: 301
[0.

[PATCH 6/6] mailbox/omap: add a custom of_xlate function

[Suman Anna]

The mailbox framework currently does not support using the
channel phandles directly in the mbox property of client nodes,
and also expects a minimum value of 1 for the #mbox-cells in the
mailbox controller device node. Implement a custom of_xlate function
for the OMAP mailbox driver that allows phandles for the pargs
specifier instead of indexing to avoid any channel registration
order dependencies.

Cc: Jassi Brar 
Signed-off-by: Suman Anna 
---
 drivers/mailbox/omap-mailbox.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index d71e84f..4847466 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -676,6 +676,28 @@ static const struct of_device_id omap_mailbox_of_match[] = 
{
 };
 MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
 
+static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
+   const struct of_phandle_args *sp)
+{
+   phandle phandle = sp->args[0];
+   struct device_node *node;
+   struct omap_mbox_device *mdev;
+   struct omap_mbox *mbox;
+
+   node = of_find_node_by_phandle(phandle);
+   if (!node) {
+   pr_err("could not find node phandle 0x%x\n", phandle);
+   return NULL;
+   }
+
+   mdev = container_of(controller, struct omap_mbox_device, controller);
+   if (WARN_ON(!mdev))
+   return NULL;
+
+   mbox = omap_mbox_device_find(mdev, node->name);
+   return mbox ? mbox->chan : NULL;
+}
+
 static int omap_mbox_probe(struct platform_device *pdev)
 {
struct resource *mem;
@@ -835,6 +857,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->controller.ops = &omap_mbox_chan_ops;
mdev->controller.chans = chnls;
mdev->controller.num_chans = info_count;
+   mdev->controller.of_xlate = omap_mbox_of_xlate;
ret = omap_mbox_register(mdev);
if (ret)
return ret;
-- 
2.0.0

--
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

[PATCH 5/6] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes

[Suman Anna]

The '#mbox-cells' property is added to all the OMAP mailbox
nodes. This property is mandatory with the new mailbox framework.

Cc: "Benoît Cousson" 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/am33xx.dtsi   |  1 +
 arch/arm/boot/dts/am4372.dtsi   |  1 +
 arch/arm/boot/dts/dra7.dtsi | 13 +
 arch/arm/boot/dts/omap2420.dtsi |  1 +
 arch/arm/boot/dts/omap2430.dtsi |  1 +
 arch/arm/boot/dts/omap3.dtsi|  1 +
 arch/arm/boot/dts/omap4.dtsi|  1 +
 arch/arm/boot/dts/omap5.dtsi|  1 +
 8 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8c5abc7..6f8f7cf 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,7 @@
reg = <0x480C8000 0x200>;
interrupts = <77>;
ti,hwmods = "mailbox";
+   #mbox-cells = <1>;
mbox_wkupm3: wkup_m3 {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 668b404..7c9ee39 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -166,6 +166,7 @@
reg = <0x480C8000 0x200>;
interrupts = ;
ti,hwmods = "mailbox";
+   #mbox-cells = <1>;
mbox_wkupm3: wkup_m3 {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8d7626f..ec7a0f2 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -342,6 +342,7 @@
compatible = "ti,omap4-mailbox";
reg = <0x4a0f4000 0x200>;
ti,hwmods = "mailbox1";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -349,6 +350,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883a000 0x200>;
ti,hwmods = "mailbox2";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -356,6 +358,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883c000 0x200>;
ti,hwmods = "mailbox3";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -363,6 +366,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4883e000 0x200>;
ti,hwmods = "mailbox4";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -370,6 +374,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4884 0x200>;
ti,hwmods = "mailbox5";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -377,6 +382,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48842000 0x200>;
ti,hwmods = "mailbox6";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -384,6 +390,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48844000 0x200>;
ti,hwmods = "mailbox7";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -391,6 +398,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48846000 0x200>;
ti,hwmods = "mailbox8";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -398,6 +406,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4885e000 0x200>;
ti,hwmods = "mailbox9";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -405,6 +414,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x4886 0x200>;
ti,hwmods = "mailbox10";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -412,6 +422,7 @@
compatible = "ti,dra7-mailbox";
reg = <0x48862000 0x200>;
ti,hwmods = "mailbox11";
+   #mbox-cells = <1>;
status = "disabled";
};
 
@@ -419,6 +430,

[PATCH 3/6] ARM: dts: OMAP2+: Add sub mailboxes device node information

[Suman Anna]

The sub-mailbox devices are added to the Mailbox DT nodes on
OMAP2420, OMAP2430, OMAP3, AM33xx, AM43xx, OMAP4 and OMAP5
family of SoCs. This data represents the same mailboxes that
used to be represented in hwmod attribute data previously.
The node name is chosen based on the .name field of
omap_mbox_dev_info structure used in the hwmod data.

Cc: "Benoît Cousson" 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/am33xx.dtsi   | 4 
 arch/arm/boot/dts/am4372.dtsi   | 4 
 arch/arm/boot/dts/omap2420.dtsi | 8 
 arch/arm/boot/dts/omap2430.dtsi | 4 
 arch/arm/boot/dts/omap3.dtsi| 4 
 arch/arm/boot/dts/omap4.dtsi| 8 
 arch/arm/boot/dts/omap5.dtsi| 8 
 7 files changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1da3bcf..8c5abc7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,10 @@
reg = <0x480C8000 0x200>;
interrupts = <77>;
ti,hwmods = "mailbox";
+   mbox_wkupm3: wkup_m3 {
+   ti,mbox-tx = <0 0 0>;
+   ti,mbox-rx = <0 0 3>;
+   };
};
 
timer1: timer@44e31000 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 390cbb53..668b404 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -166,6 +166,10 @@
reg = <0x480C8000 0x200>;
interrupts = ;
ti,hwmods = "mailbox";
+   mbox_wkupm3: wkup_m3 {
+   ti,mbox-tx = <0 0 0>;
+   ti,mbox-rx = <0 0 3>;
+   };
};
 
timer1: timer@44e31000 {
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index e83b046..f3e6d0f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -157,6 +157,14 @@
interrupts = <26>, <34>;
interrupt-names = "dsp", "iva";
ti,hwmods = "mailbox";
+   mbox_dsp: dsp {
+   ti,mbox-tx = <0 0 0>;
+   ti,mbox-rx = <1 0 0>;
+   };
+   mbox_iva: iva {
+   ti,mbox-tx = <2 1 3>;
+   ti,mbox-rx = <3 1 3>;
+   };
};
 
timer1: timer@48028000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c4e8013..13deb71 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -247,6 +247,10 @@
reg = <0x48094000 0x200>;
interrupts = <26>;
ti,hwmods = "mailbox";
+   mbox_dsp: dsp {
+   ti,mbox-tx = <0 0 0>;
+   ti,mbox-rx = <1 0 0>;
+   };
};
 
timer1: timer@49018000 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index b2891a9..3524adf 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -332,6 +332,10 @@
ti,hwmods = "mailbox";
reg = <0x48094000 0x200>;
interrupts = <26>;
+   mbox_dsp: dsp {
+   ti,mbox-tx = <0 0 0>;
+   ti,mbox-rx = <1 0 0>;
+   };
};
 
mcspi1: spi@48098000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 55bec30..19dc11d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -654,6 +654,14 @@
reg = <0x4a0f4000 0x200>;
interrupts = ;
ti,hwmods = "mailbox";
+   mbox_ipu: mbox_ipu {
+   ti,mbox-tx = <0 0 0>;
+   ti,mbox-rx = <1 0 0>;
+   };
+   mbox_dsp: mbox_dsp {
+   ti,mbox-tx = <3 0 0>;
+   ti,mbox-rx = <2 0 0>;
+   };
};
 
timer1: timer@4a318000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3bfda16..ce54c13 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -641,6 +641,14 @@
reg = <0x4a0f4000 0x200>;
interrupts = ;
ti,hwmods = "mailbox";
+   

[PATCH 4/6] mailbox/omap: adapt to the new mailbox framework

[Suman Anna]

The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+ and TI DSP/Bridge for OMAP3) are adapted to use
the generic mailbox framework.

The main changes for the adaptation are:
  - The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
  - The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes for OMAP3.
  - The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
  - The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
  - The remoteproc and tidspbridge drivers (current clients) are adapted
to use the new API. The notifier callbacks used within these clients
are replaced with the regular callbacks from the newer framework.
  - The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel is identical in signature to the framework
API mbox_request_channel, and will be removed once OMAP3 becomes DT-boot
only.

Cc: Jassi Brar 
Cc: Ohad Ben-Cohen 
Cc: Omar Ramirez Luna 
Cc: Greg Kroah-Hartman 
Signed-off-by: Suman Anna 
---
 drivers/mailbox/omap-mailbox.c | 320 +++--
 drivers/remoteproc/omap_remoteproc.c   |  54 ++--
 drivers/staging/tidspbridge/core/_tiomap.h |   3 +-
 drivers/staging/tidspbridge/core/io_sm.c   |   7 +-
 drivers/staging/tidspbridge/core/tiomap3430.c  |  22 +-
 drivers/staging/tidspbridge/core/tiomap_io.c   |   7 +-
 .../tidspbridge/include/dspbridge/host_os.h|   1 +
 .../staging/tidspbridge/include/dspbridge/io_sm.h  |   8 +-
 include/linux/omap-mailbox.h   |  15 +-
 9 files changed, 234 insertions(+), 203 deletions(-)

diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c61435b..d71e84f 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -29,13 +29,14 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define MAILBOX_REVISION   0x000
 #define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
@@ -80,7 +81,6 @@ struct omap_mbox_queue {
spinlock_t  lock;
struct kfifofifo;
struct work_struct  work;
-   struct tasklet_struct   tasklet;
struct omap_mbox*mbox;
bool full;
 };
@@ -92,6 +92,7 @@ struct omap_mbox_device {
u32 num_users;
u32 num_fifos;
struct omap_mbox **mboxes;
+   struct mbox_controller controller;
struct list_head elem;
 };
 
@@ -116,15 +117,14 @@ struct omap_mbox_device_data {
 struct omap_mbox {
const char  *name;
int irq;
-   struct omap_mbox_queue  *txq, *rxq;
+   struct omap_mbox_queue  *rxq;
struct device   *dev;
struct omap_mbox_device *parent;
struct omap_mbox_fifo   tx_fifo;
struct omap_mbox_fifo   rx_fifo;
u32 ctx[OMAP4_MBOX_NR_REGS];
u32 intr_type;
-   int use_count;
-   struct blocking_notifier_head   notifier;
+   struct mbox_chan*chan;
 };
 
 /* global variables for the mailbox devices */
@@ -135,6 +135,14 @@ static unsigned int mbox_kfifo_size = 
CONFIG_OMAP_MBOX_KFIFO_SIZE;
 module_param(mbox_kfifo_size, uint, S_IRUGO);
 MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
 
+static struct omap_mbox *mbox_chan_to_omap_mbox(struct mbox_chan *chan)
+{
+   if (!chan || !chan->con_priv)
+   return NULL;
+
+   return (struct omap_mbox *)chan->con_priv;
+}
+
 static inline
 unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
 {
@@ -200,41 +208,14 @@ static int is_mbox_irq(struct omap_mbox *mbox, 
omap_mbox_irq_t irq)
return (int)(enable & status & bit);
 }
 
-/*
- * message sender
- */
-int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
-{
-   struct omap_mbox_queue *mq = mbox->txq;
-   int ret = 0, len;
-
-   

[PATCH 1/6] Documentation: dt: add omap mailbox bindings

[Suman Anna]

Add the device tree bindings document for OMAP2+ mailbox.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Signed-off-by: Suman Anna 
---
 .../devicetree/bindings/mailbox/omap-mailbox.txt   | 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 000..307c4bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,104 @@
+OMAP2+ Mailbox Driver
+=
+
+The OMAP mailbox hardware facilitates communication between different 
processors
+using a queued mailbox interrupt mechanism. The IP block is external to the
+various processor subsystems and is connected on an interconnect bus. The
+communication is achieved through a set of registers for message storage and
+interrupt configuration registers.
+
+Each mailbox IP block has a certain number of h/w fifo queues and output
+interrupt lines. An output interrupt line is routed to an interrupt controller
+within a processor subsystem, and there can be more than one line going to a
+specific processor's interrupt controller. The interrupt line connections are
+fixed for an instance and are dictated by the IP integration into the SoC
+(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is
+programmable through a set of interrupt configuration registers, and have a rx
+and tx interrupt source per h/w fifo. Communication between different 
processors
+is achieved through the appropriate programming of the rx and tx interrupt
+sources on the appropriate interrupt lines.
+
+The number of h/w fifo queues and interrupt lines dictate the usable registers.
+All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP
+instance. DRA7xx has multiple instances with different number of h/w fifo 
queues
+and interrupt lines between different instances. The interrupt lines can also 
be
+routed to different processor sub-systems on DRA7xx as they are routed through
+the Crossbar, a kind of interrupt router/multiplexer.
+
+Mailbox Device Node:
+
+A Mailbox device node is used to represent a Mailbox IP instance within a SoC.
+The sub-mailboxes are represented as child node of this parent node.
+
+Required properties:
+
+- compatible:  Should be one of the following,
+   "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs
+   "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs
+   "ti,am3352-mailbox" for AM33xx SoCs
+   "ti,am4372-mailbox" for AM43xx SoCs
+   "ti,omap4-mailbox" for OMAP44xx, OMAP54xx SoCs and
+  DRA7xx Mailbox1 instance
+   "ti,dra7-mailbox" for DRA7xx (except for Mailbox1
+ instance)
+- reg: Contains the mailbox register address range (base
+   address and length)
+- interrupts:  Contains the interrupt information for the mailbox
+   device. The format is dependent on which interrupt
+   controller the OMAP device uses
+- ti,hwmods:   Name of the hwmod associated with the mailbox
+
+Child Nodes:
+
+A child node is used for representing the actual sub-mailbox device that is
+used for the communication between the host processor and a remote processor.
+Each child node should have a unique node name.
+
+Required properties:
+
+- ti,mbox-tx:  sub-mailbox descriptor property defining a Tx fifo
+- ti,mbox-rx:  sub-mailbox descriptor property defining a Rx fifo
+
+Sub-mailbox Descriptor Data
+---
+Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of
+data that represent the following:
+Cell #1 (fifo_id) - mailbox fifo id used either for transmitting
+(ti,mbox-tx) or for receiving (ti,mbox-rx)
+Cell #2 (irq_id)  - irq identifier index number to use from the parent's
+interrupts data. Should be 0 for most of the cases, a
+positive index value is seen only on mailboxes that 
have
+multiple interrupt lines connected to the MPU 
processor.
+Cell #3 (usr_id)  - mailbox user id for identifying the interrupt line
+associated with generating a tx/rx fifo interrupt.
+
+Example:
+
+
+/* OMAP4 */
+mailbox: mailbox@4a0f4000 {
+   compatible = "ti,omap4-mailbox";
+   reg = <0x4a0f4000 0x200>;
+   interrupts = ;
+   ti,hwmods = "mailbox";
+   mbox_ipu: mbox_ipu {
+   ti,mbox-tx = <0

[PATCH 2/6] mailbox/omap: add support for parsing dt devices

[Suman Anna]

Logic has been added to the OMAP2+ mailbox code to parse the
mailbox dt nodes and construct the different sub-mailboxes
associated with the instance. The DT representation of the
sub-mailbox devices is different from legacy platform data
representation to allow flexibility of interrupt configuration
between Tx and Rx fifos (to also possibly allow simplex devices
in the future). The DT representation gathers similar information
that was being passed previously through the platform data, except
for the number of fifos, interrupts and interrupt type information,
which are gathered through driver compatible match data.

The non-DT support has to be maintained for now to not break
OMAP3 legacy boot, and the legacy-style code will be cleaned
up once OMAP3 is also converted to DT-boot only.

Cc: Jassi Brar 
Cc: Rob Herring 
Signed-off-by: Suman Anna 
---
 drivers/mailbox/omap-mailbox.c | 201 -
 1 file changed, 177 insertions(+), 24 deletions(-)

diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index a27e00e..c61435b 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,6 +95,24 @@ struct omap_mbox_device {
struct list_head elem;
 };
 
+struct omap_mbox_fifo_info {
+   int tx_id;
+   int tx_usr;
+   int tx_irq;
+
+   int rx_id;
+   int rx_usr;
+   int rx_irq;
+
+   const char *name;
+};
+
+struct omap_mbox_device_data {
+   u32 num_users;
+   u32 num_fifos;
+   u32 intr_type;
+};
+
 struct omap_mbox {
const char  *name;
int irq;
@@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device 
*mdev)
return 0;
 }
 
+static const struct omap_mbox_device_data omap2_data = {
+   .num_users  = 4,
+   .num_fifos  = 6,
+   .intr_type  = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data omap3_data = {
+   .num_users  = 2,
+   .num_fifos  = 2,
+   .intr_type  = MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data am335x_data = {
+   .num_users  = 4,
+   .num_fifos  = 8,
+   .intr_type  = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct omap_mbox_device_data omap4_data = {
+   .num_users  = 3,
+   .num_fifos  = 8,
+   .intr_type  = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct omap_mbox_device_data dra7_data = {
+   .num_users  = 4,
+   .num_fifos  = 12,
+   .intr_type  = MBOX_INTR_CFG_TYPE2,
+};
+
+static const struct of_device_id omap_mailbox_of_match[] = {
+   {
+   .compatible = "ti,omap2-mailbox",
+   .data   = &omap2_data,
+   },
+   {
+   .compatible = "ti,omap3-mailbox",
+   .data   = &omap3_data,
+   },
+   {
+   .compatible = "ti,am3352-mailbox",
+   .data   = &am335x_data,
+   },
+   {
+   .compatible = "ti,omap4-mailbox",
+   .data   = &omap4_data,
+   },
+   {
+   .compatible = "ti,am4372-mailbox",
+   .data   = &am335x_data,
+   },
+   {
+   .compatible = "ti,dra7-mailbox",
+   .data   = &dra7_data,
+   },
+   {
+   /* end */
+   },
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
 static int omap_mbox_probe(struct platform_device *pdev)
 {
struct resource *mem;
int ret;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
-   struct omap_mbox_dev_info *info;
+   struct omap_mbox_dev_info *info = NULL;
+   struct omap_mbox_device_data *data;
+   struct omap_mbox_fifo_info *finfo, *finfoblk;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
-   u32 intr_type;
+   struct device_node *node = pdev->dev.of_node;
+   struct device_node *child;
+   const struct of_device_id *match;
+   u32 intr_type, info_count;
+   u32 num_users, num_fifos;
+   u32 tmp[3];
u32 l;
int i;
 
-   if (!pdata || !pdata->info_cnt || !pdata->info) {
+   if (!node && (!pdata || !pdata->info_cnt || !pdata->info)) {
pr_err("%s: platform not supported\n", __func__);
return -ENODEV;
}
 
+   if (node) {
+   match = of_match_device(omap_mailbox_of_match, &pdev->dev);
+   if (!match)
+   return -ENODEV;
+   data = (struct omap_mbox_device_data *)match->data;
+
+   info_count = of_get_available_child_count(node);
+   if (!info_count) {
+   dev_err(&pdev->dev, "no available mbox devices 
fou

[PATCH 0/6] OMAP Mailbox framework adoption & DT support

[Suman Anna]

Hi,

The first 3 patches in this series adds the DT bindings and the DT-parse
support to the OMAP mailbox driver. The last 3 patches make the changes
to adopt to the v7 version of mailbox framework from Jassi Brar [1]. I
have posted all the patches together since both touch the bindings and
dictate the usage for the OMAP mailbox clients. The current OMAP mailbox
clients - omap remoteproc and tidspbridge have also been converted to use
the new api.

The DT-support patches incorporates feedback from the last DT adoption
series [2], with the following main changes:
 - Leverages more compatible strings
 - Dropped the properties "ti,mbox-num-users" and "ti,mbox-num-fifos";
   with these values retrieved through driver match data and compatible
   strings
 - Dropped the properties "ti,mbox-names" and "ti,mbox-data" that were
   used to represent the sub-mailbox devices, which are now represented
   as child nodes of the respective mailbox controller device node.

The series depends on the OMAP mailbox cleanup series [3] and the OMAP
mailbox DT/hwmod cleanup series [4].

The following shows the boot/validation logs on various OMAP platforms:
  OMAP2 (SDP2430)   : http://slexy.org/view/s20VHd3CIc
  OMAP3 (BeagleXM)  : http://slexy.org/view/s204yxxE7Q
  OMAP4 (PandaBoard): http://slexy.org/view/s20GDw9Lxq
  OMAP5 (OMAP5 uEVM): http://slexy.org/view/s201gZlzSB
  DRA7  (DRA7 EVM)  : http://slexy.org/view/s2CPnJ1Boz
  AM33xx (BeagleBone Black) : http://slexy.org/view/s20WvIuITK
  AM43xx (AM437x GP EVM): http://slexy.org/view/s213DqnSg5

[1] https://lkml.org/lkml/2014/6/12/470
[2] http://marc.info/?l=linux-omap&m=137582560717973&w=2
[3] http://marc.info/?l=linux-omap&m=140365705821115&w=2
[4] http://marc.info/?l=linux-omap&m=140365833121612&w=2

Suman Anna (6):
  Documentation: dt: add omap mailbox bindings
  mailbox/omap: add support for parsing dt devices
  ARM: dts: OMAP2+: Add sub mailboxes device node information
  mailbox/omap: adapt to the new mailbox framework
  ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
  mailbox/omap: add a custom of_xlate function

 .../devicetree/bindings/mailbox/omap-mailbox.txt   | 104 
 arch/arm/boot/dts/am33xx.dtsi  |   5 +
 arch/arm/boot/dts/am4372.dtsi  |   5 +
 arch/arm/boot/dts/dra7.dtsi|  13 +
 arch/arm/boot/dts/omap2420.dtsi|   9 +
 arch/arm/boot/dts/omap2430.dtsi|   5 +
 arch/arm/boot/dts/omap3.dtsi   |   5 +
 arch/arm/boot/dts/omap4.dtsi   |   9 +
 arch/arm/boot/dts/omap5.dtsi   |   9 +
 drivers/mailbox/omap-mailbox.c | 544 ++---
 drivers/remoteproc/omap_remoteproc.c   |  54 +-
 drivers/staging/tidspbridge/core/_tiomap.h |   3 +-
 drivers/staging/tidspbridge/core/io_sm.c   |   7 +-
 drivers/staging/tidspbridge/core/tiomap3430.c  |  22 +-
 drivers/staging/tidspbridge/core/tiomap_io.c   |   7 +-
 .../tidspbridge/include/dspbridge/host_os.h|   1 +
 .../staging/tidspbridge/include/dspbridge/io_sm.h  |   8 +-
 include/linux/omap-mailbox.h   |  15 +-
 18 files changed, 598 insertions(+), 227 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt

-- 
2.0.0

--
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

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

[Felipe Balbi]

Hi,

On Tue, Jun 24, 2014 at 04:11:48PM -0500, Rob Herring wrote:
> On Mon, Jun 23, 2014 at 1:20 PM, Felipe Balbi  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

heh, fair point. Easily editable when applying, though (?)

> phandles without using labels, but the syntax is not so obvious. I'd
> tell you what it is but offhand I don't remember. :)

something along the lines of using the full path ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/9]

[Suman Anna]

On 06/24/2014 08:00 PM, Suman Anna wrote:
> Hi Tony, Paul,

Please ignore this, resent the same message and the series with the
proper subject.

regards
Suman

> 
> This patch series adds the minimal mailbox DT nodes for the SoCs that are
> currently missing them (OMAP4, AM335x, DRA7). It also limits the legacy
> mailbox platform device creation only for non-DT boot, and cleans up the
> legacy hwmod addresses and attributes used for creating the sub-mailbox
> devices. The sub-mailboxes in DT boot are not created until the OMAP
> mailbox DT adoption series, and is not an issue since some of the other
> required hwmod data for using legacy-mode devices have already been
> cleaned up.
> 
> The patches are based on 3.16-rc2. The series do not have any order
> dependencies with the OMAP mailbox cleanup series [1], and can be applied
> in any order. The following shows the boot logs on various OMAP platforms
> with just these patches on top of 3.16-rc2:
>   OMAP2 (SDP2430)   : http://slexy.org/view/s21gGdJxXP
>   OMAP3 (BeagleXM)  : http://slexy.org/view/s2n8Pc83Rp
>   OMAP4 (PandaBoard): http://slexy.org/view/s21StNWKPz
>   OMAP5 (OMAP5 uEVM): http://slexy.org/view/s2y3t6HZtk
>   DRA7  (DRA7 EVM)  : http://slexy.org/view/s2qY23Mt97
>   AM33xx (BeagleBone Black) : http://slexy.org/view/s2ce8jj35O
>   AM43xx (AM437x GP EVM): http://slexy.org/view/s2nttmOLSq
> 
> [1] http://marc.info/?l=linux-omap&m=140365705821115&w=2
> 
> Suman Anna (9):
>   ARM: dts: OMAP4: Add mailbox node
>   ARM: dts: AM33xx: Add mailbox node
>   ARM: dts: AM4372: Correct mailbox node data
>   ARM: dts: DRA7: Add mailbox nodes
>   ARM: DRA7: hwmod_data: Add mailbox hwmod data
>   ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot
>   ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs
>   ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs
>   ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs
> 
>  arch/arm/boot/dts/am33xx.dtsi  |   7 +
>  arch/arm/boot/dts/am4372.dtsi  |   7 +-
>  arch/arm/boot/dts/dra7.dtsi|  91 ++
>  arch/arm/boot/dts/omap4.dtsi   |   7 +
>  arch/arm/mach-omap2/devices.c  |   2 +-
>  arch/arm/mach-omap2/omap_hwmod_2420_data.c |  14 -
>  arch/arm/mach-omap2/omap_hwmod_2430_data.c |  13 -
>  .../omap_hwmod_2xxx_3xxx_interconnect_data.c   |   9 -
>  .../omap_hwmod_33xx_43xx_interconnect_data.c   |  10 -
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  10 -
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 305 
> +
>  arch/arm/mach-omap2/omap_hwmod_common_data.h   |   1 -
>  12 files changed, 412 insertions(+), 64 deletions(-)
> 

--
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

[PATCH 6/9] ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot

[Suman Anna]

The legacy platform device for mailbox should not be created for
a DT boot, so adjust the platform device initialization logic
appropriately.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/devices.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 592ba0a..708eb7d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -460,9 +460,9 @@ static int __init omap2_init_devices(void)
omap_init_audio();
omap_init_camera();
omap_init_hdmi_audio();
-   omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+   omap_init_mbox();
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
-- 
2.0.0

--
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

[PATCH 5/9] ARM: DRA7: hwmod_data: Add mailbox hwmod data

[Suman Anna]

Add the hwmod data for the 13 instances of the system mailbox
IP in DRA7 SoC. The patch is needed for performing a soft-reset
while configuring the respective mailbox instance, otherwise is
a non-essential change for functionality. The modules are smart
idled on reset, and the IP module mode is hardware controlled.

Cc: Rajendra Nayak 
Cc: Paul Walmsley 
Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305 ++
 1 file changed, 305 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..e35f5b1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -939,6 +939,194 @@ static struct omap_hwmod dra7xx_i2c5_hwmod = {
 };
 
 /*
+ * 'mailbox' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_mailbox_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+  SYSC_HAS_SOFTRESET),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_mailbox_hwmod_class = {
+   .name   = "mailbox",
+   .sysc   = &dra7xx_mailbox_sysc,
+};
+
+/* mailbox1 */
+static struct omap_hwmod dra7xx_mailbox1_hwmod = {
+   .name   = "mailbox1",
+   .class  = &dra7xx_mailbox_hwmod_class,
+   .clkdm_name = "l4cfg_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX1_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4CFG_MAILBOX1_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/* mailbox2 */
+static struct omap_hwmod dra7xx_mailbox2_hwmod = {
+   .name   = "mailbox2",
+   .class  = &dra7xx_mailbox_hwmod_class,
+   .clkdm_name = "l4cfg_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX2_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4CFG_MAILBOX2_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/* mailbox3 */
+static struct omap_hwmod dra7xx_mailbox3_hwmod = {
+   .name   = "mailbox3",
+   .class  = &dra7xx_mailbox_hwmod_class,
+   .clkdm_name = "l4cfg_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX3_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4CFG_MAILBOX3_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/* mailbox4 */
+static struct omap_hwmod dra7xx_mailbox4_hwmod = {
+   .name   = "mailbox4",
+   .class  = &dra7xx_mailbox_hwmod_class,
+   .clkdm_name = "l4cfg_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX4_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4CFG_MAILBOX4_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/* mailbox5 */
+static struct omap_hwmod dra7xx_mailbox5_hwmod = {
+   .name   = "mailbox5",
+   .class  = &dra7xx_mailbox_hwmod_class,
+   .clkdm_name = "l4cfg_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX5_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4CFG_MAILBOX5_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/* mailbox6 */
+static struct omap_hwmod dra7xx_mailbox6_hwmod = {
+   .name   = "mailbox6",
+   .class  = &dra7xx_mailbox_hwmod_class,
+   .clkdm_name = "l4cfg_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX6_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4CFG_MAILBOX6_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/* mailbox7 */
+static struct omap_hwmod dra7xx_mailbox7_hwmod = {
+   .name   = "mailbox7",
+   .class  = &dra7xx_mailbox_hwmod_class,
+   .clkdm_name = "l4cfg_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX7_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4CFG_MAILBOX7_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/* mailbox8 */
+static struct omap_hwmod dra7xx_mailbox8_hwmod = {
+   .name   = "mailbox8",
+   .class  = &dra7xx_mailbox_hwmod_class,
+   .clkdm_name = "l4cfg_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX8_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4CFG_MAILBOX8_CONTEXT_OFFSET,
+   },
+   },
+};
+
+/* mailbox9 */
+static struct omap_hwmod dra7xx_mailbox9_hwmod = {
+   .name

[PATCH 8/9] ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs

[Suman Anna]

The legacy-style definition of the hwmod addr space is no longer
required after the addition of the OMAP4 mailbox DT node, so
clean up this data.

Cc: Paul Walmsley 
Cc: Benoît Cousson 
Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 41e54f7..5e61b8c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4142,21 +4142,11 @@ static struct omap_hwmod_ocp_if omap44xx_l4_wkup__kbd = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space omap44xx_mailbox_addrs[] = {
-   {
-   .pa_start   = 0x4a0f4000,
-   .pa_end = 0x4a0f41ff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_cfg -> mailbox */
 static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mailbox = {
.master = &omap44xx_l4_cfg_hwmod,
.slave  = &omap44xx_mailbox_hwmod,
.clk= "l4_div_ck",
-   .addr   = omap44xx_mailbox_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.0.0

--
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

[PATCH 7/9] ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs

[Suman Anna]

OMAP2 devices are devicetree boot only, and the legacy mode
of mailbox device creation should no longer be used, so remove
the mailbox attribute data and the hwmod addr space used for
creating mailboxes in legacy mode.

Cc: Paul Walmsley 
Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 --
 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 -
 .../mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c|  9 -
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |  1 -
 4 files changed, 37 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2f15979..65b1647 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "omap_hwmod.h"
@@ -163,18 +162,6 @@ static struct omap_hwmod omap2420_dma_system_hwmod = {
 };
 
 /* mailbox */
-static struct omap_mbox_dev_info omap2420_mailbox_info[] = {
-   { .name = "dsp", .tx_id = 0, .rx_id = 1, .irq_id = 0, .usr_id = 0 },
-   { .name = "iva", .tx_id = 2, .rx_id = 3, .irq_id = 1, .usr_id = 3 },
-};
-
-static struct omap_mbox_pdata omap2420_mailbox_attrs = {
-   .num_users  = 4,
-   .num_fifos  = 6,
-   .info_cnt   = ARRAY_SIZE(omap2420_mailbox_info),
-   .info   = omap2420_mailbox_info,
-};
-
 static struct omap_hwmod omap2420_mailbox_hwmod = {
.name   = "mailbox",
.class  = &omap2xxx_mailbox_hwmod_class,
@@ -188,7 +175,6 @@ static struct omap_hwmod omap2420_mailbox_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
},
},
-   .dev_attr   = &omap2420_mailbox_attrs,
 };
 
 /*
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 6d1b609..c2555cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "omap_hwmod.h"
@@ -161,17 +160,6 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
 };
 
 /* mailbox */
-static struct omap_mbox_dev_info omap2430_mailbox_info[] = {
-   { .name = "dsp", .tx_id = 0, .rx_id = 1 },
-};
-
-static struct omap_mbox_pdata omap2430_mailbox_attrs = {
-   .num_users  = 4,
-   .num_fifos  = 6,
-   .info_cnt   = ARRAY_SIZE(omap2430_mailbox_info),
-   .info   = omap2430_mailbox_info,
-};
-
 static struct omap_hwmod omap2430_mailbox_hwmod = {
.name   = "mailbox",
.class  = &omap2xxx_mailbox_hwmod_class,
@@ -185,7 +173,6 @@ static struct omap_hwmod omap2430_mailbox_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
},
},
-   .dev_attr   = &omap2430_mailbox_attrs,
 };
 
 /* mcspi3 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
index 0413dab..c1e98d5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
@@ -152,15 +152,6 @@ struct omap_hwmod_addr_space omap2_dma_system_addrs[] = {
{ }
 };
 
-struct omap_hwmod_addr_space omap2_mailbox_addrs[] = {
-   {
-   .pa_start   = 0x48094000,
-   .pa_end = 0x48094000 + SZ_512 - 1,
-   .flags  = ADDR_TYPE_RT,
-   },
-   { }
-};
-
 struct omap_hwmod_addr_space omap2_mcbsp1_addrs[] = {
{
.name   = "mpu",
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h 
b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 2c38c6b..11ed5a1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -33,7 +33,6 @@ extern struct omap_hwmod_addr_space omap2_mcspi1_addr_space[];
 extern struct omap_hwmod_addr_space omap2_mcspi2_addr_space[];
 extern struct omap_hwmod_addr_space omap2430_mcspi3_addr_space[];
 extern struct omap_hwmod_addr_space omap2_dma_system_addrs[];
-extern struct omap_hwmod_addr_space omap2_mailbox_addrs[];
 extern struct omap_hwmod_addr_space omap2_mcbsp1_addrs[];
 extern struct omap_hwmod_addr_space omap2_hdq1w_addr_space[];
 
-- 
2.0.0

--
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

[PATCH 9/9] ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs

[Suman Anna]

The legacy-style definition of the hwmod addr space is no longer
required as AM33xx/AM43xx are DT-boot only, and the minimal mailbox
DT nodes have been added, so clean up this data.

Cc: Paul Walmsley 
Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
index e2db378..8f5989d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -317,21 +317,11 @@ struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
.user   = OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_mailbox_addrs[] = {
-   {
-   .pa_start   = 0x480C8000,
-   .pa_end = 0x480C8000 + (SZ_4K - 1),
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4 ls -> mailbox */
 struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
.master = &am33xx_l4_ls_hwmod,
.slave  = &am33xx_mailbox_hwmod,
.clk= "l4ls_gclk",
-   .addr   = am33xx_mailbox_addrs,
.user   = OCP_USER_MPU,
 };
 
-- 
2.0.0

--
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

[PATCH 4/9] ARM: dts: DRA7: Add mailbox nodes

[Suman Anna]

DRA7xx has 13 system mailboxes, and is present on both the
DRA72x and DRA74x family of SoCs. Add the DT nodes for all
these 13 mailboxes. Except for mailbox 1, all other mailboxes
do not have interrupts mapped into the MPU GIC by default.

All the mailboxes have been disabled and the interrupts
property information is left out intentionally for now,
because of the dependencies against the crossbar driver.
These mailboxes can be enabled when a usecase arises
and the crossbar driver dependencies are met.

NOTE: The mailbox 1 is backward compatible with the mailbox
IP on OMAP4/OMAP5 with different number of mailbox fifos
and IP interrupts, and hence the omap4 compatibility string
is used.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/dra7.dtsi | 91 +
 1 file changed, 91 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c29945e..8d7626f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -338,6 +338,97 @@
status = "disabled";
};
 
+   mailbox1: mailbox@4a0f4000 {
+   compatible = "ti,omap4-mailbox";
+   reg = <0x4a0f4000 0x200>;
+   ti,hwmods = "mailbox1";
+   status = "disabled";
+   };
+
+   mailbox2: mailbox@4883a000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x4883a000 0x200>;
+   ti,hwmods = "mailbox2";
+   status = "disabled";
+   };
+
+   mailbox3: mailbox@4883c000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x4883c000 0x200>;
+   ti,hwmods = "mailbox3";
+   status = "disabled";
+   };
+
+   mailbox4: mailbox@4883e000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x4883e000 0x200>;
+   ti,hwmods = "mailbox4";
+   status = "disabled";
+   };
+
+   mailbox5: mailbox@4884 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x4884 0x200>;
+   ti,hwmods = "mailbox5";
+   status = "disabled";
+   };
+
+   mailbox6: mailbox@48842000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x48842000 0x200>;
+   ti,hwmods = "mailbox6";
+   status = "disabled";
+   };
+
+   mailbox7: mailbox@48844000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x48844000 0x200>;
+   ti,hwmods = "mailbox7";
+   status = "disabled";
+   };
+
+   mailbox8: mailbox@48846000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x48846000 0x200>;
+   ti,hwmods = "mailbox8";
+   status = "disabled";
+   };
+
+   mailbox9: mailbox@4885e000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x4885e000 0x200>;
+   ti,hwmods = "mailbox9";
+   status = "disabled";
+   };
+
+   mailbox10: mailbox@4886 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x4886 0x200>;
+   ti,hwmods = "mailbox10";
+   status = "disabled";
+   };
+
+   mailbox11: mailbox@48862000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x48862000 0x200>;
+   ti,hwmods = "mailbox11";
+   status = "disabled";
+   };
+
+   mailbox12: mailbox@48864000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x48864000 0x200>;
+   ti,hwmods = "mailbox12";
+   status = "disabled";
+   };
+
+   mailbox13: mailbox@48802000 {
+   compatible = "ti,dra7-mailbox";
+   reg = <0x48802000 0x200>;
+   ti,hwmods = "mailbox13";
+   status = "disabled";
+   };
+
timer1: timer@4ae18000 {
compatible = "ti,omap5430-timer";
reg = <0x4ae18000 0x80>;
-- 
2.0.0

--
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

[PATCH 3/9] ARM: dts: AM4372: Correct mailbox node data

[Suman Anna]

The mailbox DT node for AM4372 has been corrected to include
the correct compatible flag, and remove the other properties
that have crept in by mistake.

Fixes: 9e3269b (ARM: dts: AM4372: Add L2, EDMA, mailbox, MMC and SHAM nodes)
Cc: Lokesh Vutla 
Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/am4372.dtsi | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 49fa596..390cbb53 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -162,15 +162,10 @@
};
 
mailbox: mailbox@480C8000 {
-   compatible = "ti,omap4-mailbox";
+   compatible = "ti,am4372-mailbox";
reg = <0x480C8000 0x200>;
interrupts = ;
ti,hwmods = "mailbox";
-   ti,mbox-num-users = <4>;
-   ti,mbox-num-fifos = <8>;
-   ti,mbox-names = "wkup_m3";
-   ti,mbox-data = <0 0 0 0>;
-   status = "disabled";
};
 
timer1: timer@44e31000 {
-- 
2.0.0

--
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

[PATCH 2/9] ARM: dts: AM33xx: Add mailbox node

[Suman Anna]

The mailbox DT node data has been added for AM33xx device.
The mailbox IP in AM33xx is similar to the version found in
OMAP4+ devices.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/am33xx.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4a4e02d..1da3bcf 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -347,6 +347,13 @@
status = "disabled";
};
 
+   mailbox: mailbox@480C8000 {
+   compatible = "ti,am3352-mailbox";
+   reg = <0x480C8000 0x200>;
+   interrupts = <77>;
+   ti,hwmods = "mailbox";
+   };
+
timer1: timer@44e31000 {
compatible = "ti,am335x-timer-1ms";
reg = <0x44e31000 0x400>;
-- 
2.0.0

--
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

[PATCH 1/9] ARM: dts: OMAP4: Add mailbox node

[Suman Anna]

The mailbox DT node data has been added for OMAP44xx
devices.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/omap4.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7e26d22..55bec30 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -649,6 +649,13 @@
};
};
 
+   mailbox: mailbox@4a0f4000 {
+   compatible = "ti,omap4-mailbox";
+   reg = <0x4a0f4000 0x200>;
+   interrupts = ;
+   ti,hwmods = "mailbox";
+   };
+
timer1: timer@4a318000 {
compatible = "ti,omap3430-timer";
reg = <0x4a318000 0x80>;
-- 
2.0.0

--
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

[PATCH 0/9] OMAP Mailbox DT node/hwmod cleanup

[Suman Anna]

Hi Tony, Paul,

This patch series adds the minimal mailbox DT nodes for the SoCs that are
currently missing them (OMAP4, AM335x, DRA7). It also limits the legacy
mailbox platform device creation only for non-DT boot, and cleans up the
legacy hwmod addresses and attributes used for creating the sub-mailbox
devices. The sub-mailboxes in DT boot are not created until the OMAP
mailbox DT adoption series, and is not an issue since some of the other
required hwmod data for using legacy-mode devices have already been
cleaned up.

The patches are based on 3.16-rc2. The series do not have any order
dependencies with the OMAP mailbox cleanup series [1], and can be applied
in any order. The following shows the boot logs on various OMAP platforms
with just these patches on top of 3.16-rc2:
  OMAP2 (SDP2430)   : http://slexy.org/view/s21gGdJxXP
  OMAP3 (BeagleXM)  : http://slexy.org/view/s2n8Pc83Rp
  OMAP4 (PandaBoard): http://slexy.org/view/s21StNWKPz
  OMAP5 (OMAP5 uEVM): http://slexy.org/view/s2y3t6HZtk
  DRA7  (DRA7 EVM)  : http://slexy.org/view/s2qY23Mt97
  AM33xx (BeagleBone Black) : http://slexy.org/view/s2ce8jj35O
  AM43xx (AM437x GP EVM): http://slexy.org/view/s2nttmOLSq

[1] http://marc.info/?l=linux-omap&m=140365705821115&w=2

Suman Anna (9):
  ARM: dts: OMAP4: Add mailbox node
  ARM: dts: AM33xx: Add mailbox node
  ARM: dts: AM4372: Correct mailbox node data
  ARM: dts: DRA7: Add mailbox nodes
  ARM: DRA7: hwmod_data: Add mailbox hwmod data
  ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot
  ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs
  ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs
  ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs

 arch/arm/boot/dts/am33xx.dtsi  |   7 +
 arch/arm/boot/dts/am4372.dtsi  |   7 +-
 arch/arm/boot/dts/dra7.dtsi|  91 ++
 arch/arm/boot/dts/omap4.dtsi   |   7 +
 arch/arm/mach-omap2/devices.c  |   2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  14 -
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  13 -
 .../omap_hwmod_2xxx_3xxx_interconnect_data.c   |   9 -
 .../omap_hwmod_33xx_43xx_interconnect_data.c   |  10 -
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  10 -
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 305 +
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |   1 -
 12 files changed, 412 insertions(+), 64 deletions(-)

-- 
2.0.0

--
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

[PATCH 0/9]

[Suman Anna]

Hi Tony, Paul,

This patch series adds the minimal mailbox DT nodes for the SoCs that are
currently missing them (OMAP4, AM335x, DRA7). It also limits the legacy
mailbox platform device creation only for non-DT boot, and cleans up the
legacy hwmod addresses and attributes used for creating the sub-mailbox
devices. The sub-mailboxes in DT boot are not created until the OMAP
mailbox DT adoption series, and is not an issue since some of the other
required hwmod data for using legacy-mode devices have already been
cleaned up.

The patches are based on 3.16-rc2. The series do not have any order
dependencies with the OMAP mailbox cleanup series [1], and can be applied
in any order. The following shows the boot logs on various OMAP platforms
with just these patches on top of 3.16-rc2:
  OMAP2 (SDP2430)   : http://slexy.org/view/s21gGdJxXP
  OMAP3 (BeagleXM)  : http://slexy.org/view/s2n8Pc83Rp
  OMAP4 (PandaBoard): http://slexy.org/view/s21StNWKPz
  OMAP5 (OMAP5 uEVM): http://slexy.org/view/s2y3t6HZtk
  DRA7  (DRA7 EVM)  : http://slexy.org/view/s2qY23Mt97
  AM33xx (BeagleBone Black) : http://slexy.org/view/s2ce8jj35O
  AM43xx (AM437x GP EVM): http://slexy.org/view/s2nttmOLSq

[1] http://marc.info/?l=linux-omap&m=140365705821115&w=2

Suman Anna (9):
  ARM: dts: OMAP4: Add mailbox node
  ARM: dts: AM33xx: Add mailbox node
  ARM: dts: AM4372: Correct mailbox node data
  ARM: dts: DRA7: Add mailbox nodes
  ARM: DRA7: hwmod_data: Add mailbox hwmod data
  ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot
  ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs
  ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs
  ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs

 arch/arm/boot/dts/am33xx.dtsi  |   7 +
 arch/arm/boot/dts/am4372.dtsi  |   7 +-
 arch/arm/boot/dts/dra7.dtsi|  91 ++
 arch/arm/boot/dts/omap4.dtsi   |   7 +
 arch/arm/mach-omap2/devices.c  |   2 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  14 -
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  13 -
 .../omap_hwmod_2xxx_3xxx_interconnect_data.c   |   9 -
 .../omap_hwmod_33xx_43xx_interconnect_data.c   |  10 -
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  10 -
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 305 +
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |   1 -
 12 files changed, 412 insertions(+), 64 deletions(-)

-- 
2.0.0

--
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

Re: [PATCH v2] pinctrl: msm: Add msm8960 definitions

[Andreas Färber]

Am 24.06.2014 20:16, schrieb Bjorn Andersson:
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
> new file mode 100644
> index 000..6e79eea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
[...]
> +Example:
> +
> + msmgpio: pinctrl@80 {
> + compatible = "qcom,msm8960-pinctrl";
> + reg = <0x80 0x4000>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +interrupts = <0 32 0x4>;

This line seems space-indented while surrounding ones are tab-indented.

> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&debug_uart>;
> +
> + debug_uart: debug_uart {

While at it, might debug-uart be a better node name? That seems the
predominant convention and distinguishes from the label.

Regards,
Andreas

> + mux {
> + pins = "gpio34", "gpio35";
> + function = "gsbi8";
> + };
> +
> + tx {
> + pins = "gpio34";
> + drive-strength = <4>;
> + bias-disable;
> + };
> +
> + rx {
> + pins = "gpio35";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> + };
> + };
[snip]

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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

Re: [PATCH 1/2] regulator: max1586 add device-tree support

[Mark Brown]

On Tue, Jun 24, 2014 at 08:05:30PM +0200, Robert Jarzmik wrote:
> Mark Brown  writes:

> >> As for the "state report", this max1586 doesn't report anything, it cannot 
> >> even
> >> be queried about the current voltage, sic ...

> > It can't?  That's unfortunate, though I was able to turn up a datasheet
> > which appears to support that.

> Oh really ? Well, tell me where you read it.

I said I *was* able to turn up a datasheet which appeared to support
that.

> >> If you want me to modify this bit I need a bit more of an explanation to
> >> understand.

> > Where the driver is doing unusual things if they are actually sensible
> > then the change needs to be clearer about why.

> So would a comment like this address your comment ?

>   /* Either matched < 0 and return the error. Or matched is 0 which means
>* no init data was found, ie. no regulator is configured, and return 0
>* to caller, stating neither error nor any matched regulator.
>*/
>   if (matched <= 0)
>   return matched;

Can you include something like "...and we have no readback support in
the device so can't report status" or something please?  That's the key
bit - the point is that even unconfigured regulators should normally be
registered.


signature.asc
Description: Digital signature

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera 
> Signed-off-by: Shaik Ameer Basha 
> Reported-by: Kevin Hilman 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I've tested this myself now as well.

Tested-by: Doug Anderson 
--
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

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Doug Anderson]

Tushar,

On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera  wrote:
> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman  wrote:
>> Tushar Behera  writes:
>>
>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>>
>>> Though user manual doesn't specify this dependency, we came across
>>> this issue while disabling the parent of AUDSS mux clocks.
>>>
>>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>>
>> While this patch works (and fixes the boot problem for me), it seems
>> like it's papering over the real problem.
>>
>
> Thanks for testing.
>
>> Seems like the right fix is actually modelling the clocks properly so
>> that enabling a child clock ensures that the parent is also enabled.
>>
>
> Patch 2/3 was to ensure we have proper clock tree defined for
> Exynos5420. While testing with audio disabled, that patch alone fixed
> the issue. But when audio was enabled (and hence I2S0 was trying to
> access the clocks), we got some kernel oops during late booting, hence
> I came up this solution.
>
> The solution might be a little half-baked because of the urgency to
> push the fix, but will try to dig more into the issue on Monday when I
> resume office.

Which Monday were you referring to?  ;)

...but in all seriousness do you have an official status update on
this patch?  It seems as if it's not needed and all you need is
, but it would be nice to
get an official confirmation.

Thanks!

-Doug
--
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

Re: [PATCH 0/8] iMX6 SATA configuration

[Tejun Heo]

On Tue, Jun 24, 2014 at 11:19:01AM +0100, Russell King - ARM Linux wrote:
> Another round of these patches.  I've integrated Shawn's patch to split
> the documentation into this series so I can add the DT documentation
> on top of it.
> 
>  .../devicetree/bindings/ata/ahci-platform.txt  |   6 -
>  Documentation/devicetree/bindings/ata/imx-sata.txt |  36 
>  arch/arm/boot/dts/imx6q-cubox-i.dts|   4 +
>  drivers/ata/ahci_imx.c | 184 
> -
>  4 files changed, 216 insertions(+), 14 deletions(-)

Patches look good to me.  Shawn, can you please review the ahci_imx
portion?  How should the patches be routed?  Should I pick only the
ata parts or apply the whole thing?

Thanks.

-- 
tejun
--
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

Re: [PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Thierry Reding]

On Tue, Jun 24, 2014 at 02:52:11PM -0500, Rob Herring wrote:
> On Tue, Jun 24, 2014 at 10:06 AM, Russell King - ARM Linux 
>  wrote:
[...]
> > On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
[...]
> >> diff --git 
> >> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
> >> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
[...]
> >> @@ -0,0 +1,7 @@
> >> +Eukrea DVI-VGA (640x480 pixels) DVI output.
> >> +
> >> +Required properties:
> >> +- compatible: should be "eukrea,mbimxsd51-dvi-vga"
> >> +
> >> +This binding is compatible with the simple-panel binding, which is 
> >> specified
> >> +in simple-panel.txt in this directory.
> 
> Seems like we could just have a list of compatible strings rather than
> a mostly duplicated file.

We've been doing it this way for all other panels.

> >> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> >> b/drivers/gpu/drm/panel/panel-simple.c
> >> index a251361..adc40a7 100644
> >> --- a/drivers/gpu/drm/panel/panel-simple.c
> >> +++ b/drivers/gpu/drm/panel/panel-simple.c
> >> @@ -403,6 +403,80 @@ static const struct panel_desc edt_etm0700g0dh6 = {
> >>   },
> >>  };
> >>
> >> +static const struct drm_display_mode eukrea_mbimxsd51_cmoqvga_mode = {
> >> + .clock = 6500,
> >> + .hdisplay = 320,
> >> + .hsync_start = 320 + 38,
> >> + .hsync_end = 320 + 38 + 20,
> >> + .htotal = 320 + 38 + 20 + 30,
> >> + .vdisplay = 240,
> >> + .vsync_start = 240 + 15,
> >> + .vsync_end = 240 + 15 + 4,
> >> + .vtotal = 240 + 15 + 4 + 3,
> >> + .vrefresh = 60,
> >> + .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE |
> >> +  DRM_MODE_FLAG_POL_DE_LOW,
> 
> Why aren't you using:
> 
> Documentation/devicetree/bindings/video/display-timing.txt

Because it's redundant information. We need to have a compatible for the
panel in the device tree anyway and that already implicitly defines the
display mode.

Thierry


pgpTP3LZaxGrO.pgp
Description: PGP signature

Re: [PATCH v4 2/2] ata: Fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode command.

[Tejun Heo]

Hello,

On Mon, Jun 23, 2014 at 03:23:13PM +0530, Suman Tripathi wrote:
> This patch fixes the dma state machine lockup due to the processing
> of IDENTIFY DEVICE PIO mode command. The X-Gene AHCI controller
> has an errata in which it cannot clear the BSY bit after
> receiving the PIO setup FIS and results the dma state machine to go
> into the CMFatalErrorUpdate state resulting in the dma state
> machine lockup. This patch also removes the dma restart workaround
> from the read_id function as the read_id function is only called by
> libata layer for ATA_INTERNAL commands. But for somecases eg:
> PORT MULTIPLIER and udev, the framework will enumerate using SCSI
> commands and it will not call read_id function.

I assume that it's verified that only IDENTIFY is affected?  Please
try to explicitly follow up on the previous discussions.  It makes
keeping track a lot easier for the reviewers.

>  /**
> + * xgene_ahci_qc_issue - Issue commands to the device
> + * @qc: Command to issue
> + *
> + * Due to H/W errata, for the IDENTIFY DEVICE command controller is unable to
> + * clear the BSY bit after receiving the PIO setup FIS and results the dma
> + * state machine to go into the CMFatalErrorUpdate state resulting in the dma
> + * state machine lockup. By restarting the dma engine to move it removes the
> + * controller out of lock up state.
> + */
> +static unsigned int xgene_ahci_qc_issue(struct ata_queued_cmd *qc)
> +{
> + struct ata_port *ap = qc->ap;
> + struct ahci_host_priv *hpriv = ap->host->private_data;
> + struct xgene_ahci_context *ctx = hpriv->plat_data;
> + int rc = 0;
> +
> + /*
> +  * Restart the dma engine if the last cmd issued
> +  * is IDENTIFY DEVICE command
> +  */

I think the function comment is doing a good job of explaining and we
can lose the above comment.  Comments which explain the code itself is
useful if the logic involved is complex but I don't think that's the
case here.

> + if (unlikely(ctx->last_cmd[ap->port_no] == ATA_CMD_ID_ATA))
> + ahci_restart_engine(ap);
> +
> + rc = ahci_qc_issue(qc);
> +
> + /* Save the last command issued */
> + ctx->last_cmd[ap->port_no] = qc->tf.command;
> +
> + return rc;
> +}
...
> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> index d1c9122..1b86cf4 100644
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -68,7 +68,6 @@ static ssize_t ahci_transmit_led_message(struct ata_port 
> *ap, u32 state,
> 
>  static int ahci_scr_read(struct ata_link *link, unsigned int sc_reg, u32 
> *val);
>  static int ahci_scr_write(struct ata_link *link, unsigned int sc_reg, u32 
> val);
> -static unsigned int ahci_qc_issue(struct ata_queued_cmd *qc);
>  static bool ahci_qc_fill_rtf(struct ata_queued_cmd *qc);
>  static int ahci_port_start(struct ata_port *ap);
>  static void ahci_port_stop(struct ata_port *ap);
> @@ -1952,7 +1951,7 @@ irqreturn_t ahci_interrupt(int irq, void *dev_instance)
>  }
>  EXPORT_SYMBOL_GPL(ahci_interrupt);
> 
> -static unsigned int ahci_qc_issue(struct ata_queued_cmd *qc)
> +unsigned int ahci_qc_issue(struct ata_queued_cmd *qc)
>  {
>   struct ata_port *ap = qc->ap;
>   void __iomem *port_mmio = ahci_port_base(ap);
> @@ -1981,6 +1980,7 @@ static unsigned int ahci_qc_issue(struct ata_queued_cmd 
> *qc)
> 
>   return 0;
>  }
> +EXPORT_SYMBOL_GPL(ahci_qc_issue);

Can we please do this in the previous patch?  "implement
ahci_restart_engine() and export ahci_qc_issue()" is completely fine
with me.  Just note in the description that a following patch will
make use of them.

Thanks.

-- 
tejun
--
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

Re: [PATCH 4/4] ARM: DTS: Add NTC thermistor nodes as child nodes to ADC

[Doug Anderson]

Naveen,

On Tue, Jun 24, 2014 at 5:19 AM, Naveen Krishna Chatradhi
 wrote:
> Exynos5420 based Peach PIT and Exynos5800 based PI boards have
> 4 NTC thermistors to measure temperatures at various points on the
> board.
>
> IIO based ADC becomes the parent and NTC thermistors are the childs,
> via the HWMON interface.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Doug Anderson 
> ---
> This patch needs
> 1. MAX77802 PMIC device tree nodes (for ldo9)
>https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html
> 2. Uses the DT documentation for NTC thermistors updated with vendor-prefix
>
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |   32 
> 
>  1 file changed, 32 insertions(+)

* You forgot: status="okay" for the ADC.  One might question how this
patch was tested.

* Please also include this change for pi.

* We just got through the painful process of sorting this .dts file.
Please sort "&adc" alphabetically.  Kukjin: please confirm that you
will keep an eye on patches and make sure that they are sorted OK.


Other than those problems this seems to work fine to me.

-Doug
--
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

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Olav Haugan]

On 6/24/2014 11:11 AM, Will Deacon wrote:
> On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
>> On 6/24/2014 2:18 AM, Will Deacon wrote:
>>> On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
 We have multiple-master SMMUs and each master emits a variable number of
 StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
 for this) to the StreamIDs due to limited number of StreamID 2 Context
 Bank entries in the SMMU. If my understanding is correct we would
 represent this in the DT like this:

iommu {
#address-cells = <2>;
#size-cells = <0>;
};

master@a {
...
iommus = <&iommu StreamID0 MASK0>,
 <&iommu StreamID1 MASK1>,
 <&iommu StreamID2 MASK2>;
};
>>>
>>> Stupid question, but why not simply describe the masked IDs? What use does
>>> the `raw' ID have to Linux?
>>
>> We do describe the masked StreamID (SID) but we need to specify the mask
>> that the SMMU should apply to the incoming SIDs, right?
>>
>> We have a bus master that emits 43 unique SIDs. However, we have only 40
>> SMMU_SMRn registers in the SMMU. So we need to mask out some of the
>> incoming SID bits so that the 43 SIDs can match one of 40 entries in the
>> SMR.
> 
> Hmm, so you're talking about stream matching, right? That doesn't belong in
> the device-tree. I appreciate that the current driver does a terrible job at
> allocating the SMRs (it's bloody difficult!), but we should try to improve
> the dynamic behaviour instead of moving configuration of the SMMU out into
> device-tree, where it's inflexible at best.

I am talking about SMMU_SMRn[MASK] register bits. This is not something
that can be dynamically detected at run-time. It is configuration at the
same level as the actual StreamIDs.

Thanks,


Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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

Re: [PATCH] ARM: DTS: correct the capability string for mmc0

[Doug Anderson]

Hi,

On Mon, Jun 23, 2014 at 4:36 AM, Kukjin Kim  wrote:
> Naveen Krishna Chatradhi wrote:
>>
>> MMC capability for HS200 is parsed in mmc/core/host.c as
>> dts string "mmc-hs200-1_8v".
>>
>> This patch corrects the dts string for Exynos5420 based peach-pit
>> and Exynos5800 based peach-pi boards.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>>  arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +-
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
>> b/arch/arm/boot/dts/exynos5420-
>> peach-pit.dts
>> index 7649982..7dea480 100644
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> @@ -173,7 +173,7 @@
>>   status = "okay";
>>   num-slots = <1>;
>>   broken-cd;
>> - caps2-mmc-hs200-1_8v;
>> + mmc-hs200-1_8v;
>>   supports-highspeed;
>>   non-removable;
>>   card-detect-delay = <200>;
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
>> b/arch/arm/boot/dts/exynos5800-
>> peach-pi.dts
>> index 2c2c137..bb3ee76 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -171,7 +171,7 @@
>>   status = "okay";
>>   num-slots = <1>;
>>   broken-cd;
>> - caps2-mmc-hs200-1_8v;
>> + mmc-hs200-1_8v;
>>   supports-highspeed;
>>   non-removable;
>>   card-detect-delay = <200>;
>> --
>> 1.7.9.5
>
> Applied, thanks.

As an FYI: this patch (while correct) will likely cause sporadic boot
failures until Sonny and my patches land:

* https://patchwork.kernel.org/patch/4323921/
  mmc: dw_mmc: Make sure we don't get stuck when we get an error

* https://patchwork.kernel.org/patch/4213211/
  mmc: dw_mmc: change to use recommended reset procedure

In the very least we got sporadic boot failures locally when we
enabled hs200 and didn't have the "don't get stuck" patch.  I will
also note that it would have been nice had this patch title included
the words exynos and/or pit/pi in it.

-Doug
--
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

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  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 
> ---
>
> 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 =  @@ -279,7 +279,7 @@
> status = "disabled";
> };
>
> -   wdt@44e35000 {
> +   wdt: wdt@44e35000 {
> compatible = "ti,am4372-wdt","ti,omap3-wdt";
> reg = <0x44e35000 0x1000>;
> interrupts = ;
> @@ -871,7 +871,7 @@
> #size-cells = <1>;
> ranges;
>
> -   dispc@4832a400 {
> +   dispc: dispc@4832a400 {
> compatible = "ti,omap3-dispc";
> reg = <0x4832a400 0x400>;
> interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> --
> 2.0.0.390.gcb682f8
>
--
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

Re: [PATCH v2 REBASED 00/10] Generic earlyconsole for ARC UART Driver

[Rob Herring]

On Tue, Jun 24, 2014 at 3:25 AM, Vineet Gupta
 wrote:
> Hi,
>
> This is slightly modified repost of series posted last week
> http://www.spinics.net/lists/linux-serial/msg12884.html
>
> This series switches ARC UART from custom earlyprintk support to generic
> earlycon (many thanks to Rob for doing that). And also build on Grant's recent
> work for using DT stdout-path as default console.
>
> The motivation is to get rid of the early platform code, which in turn
> would help consolidate the init code across several ARC platforms.
>
> First 3 patches are general cleanup/refactoring, not necesarily related to
> earlycon.

Other than my comment on patch 6:

Reviewed-by: Rob Herring 

>
> v2 <- v1
> 
> * Rebased on linux-next: 20140623
> * Patch 9 split into 9 and 10 for driver/platform changes
> * Patch 10 also uses the DT stdout-path so no need for console=
>
>
> Thx,
> -Vineet
>
>
> Vineet Gupta (10):
>   serial/arc: use uart_console_write() helper
>   serial/arc: Refactor by referencing to uart_port where possible
>   serial/arc: Remove the workaround for legacy ISS
>   serial/arc: Use generic earlycon infrastructure
>   serial/arc: remove earlyprintk support and switch to earlycon
>   serial/arc: remove last remanants of platform data
>   serial/arc: inline the probe helper
>   ARC: [arcfpga] RIP early uart platform device stuff
>   serial/arc: Enable DT based earlycon
>   ARC: [arcfpga] stdout-path now suffices for earlycon/console
>
>  arch/arc/boot/dts/angel4.dts |   3 +-
>  arch/arc/plat-arcfpga/Kconfig|   7 -
>  arch/arc/plat-arcfpga/platform.c |  97 +---
>  drivers/tty/serial/Kconfig   |   1 +
>  drivers/tty/serial/arc_uart.c| 329 
> ++-
>  5 files changed, 123 insertions(+), 314 deletions(-)
>
> --
> 1.8.3.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

Re: [PATCH v2 REBASED 06/10] serial/arc: remove last remanants of platform data

[Rob Herring]

On Tue, Jun 24, 2014 at 3:25 AM, Vineet Gupta
 wrote:
> Signed-off-by: Vineet Gupta 
> ---
>  drivers/tty/serial/arc_uart.c | 22 ++
>  1 file changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c
> index 2ffaf099691a..dc3d5db37dc4 100644
> --- a/drivers/tty/serial/arc_uart.c
> +++ b/drivers/tty/serial/arc_uart.c


> @@ -518,21 +516,13 @@ arc_uart_init_one(struct platform_device *pdev, int 
> dev_id)
> }
> uart->baud = val;
>
> -   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -   if (!res)
> -   return -ENODEV;
> -
> -   res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> -   if (!res2)
> -   return -ENODEV;
> -
> -   port->mapbase = res->start;
> -   port->membase = ioremap_nocache(res->start, resource_size(res));
> +   port->membase = of_iomap(np, 0);

ioremap is preferred over of_iomap as it is not OF specific. Perhaps
use devm_request_and_ioremap instead.

> if (!port->membase)
> /* No point of dev_err since UART itself is hosed here */
> return -ENXIO;
>
> -   port->irq = res2->start;
> +   port->irq = irq_of_parse_and_map(np, 0);
> +

platform_get_irq should be used here.

> port->dev = &pdev->dev;
> port->iotype = UPIO_MEM;
> port->flags = UPF_BOOT_AUTOCONF;
> --
> 1.8.3.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

Re: [PATCH v3 2/2] arm: dts: add support for AM437x StarterKit

[Tom Rini]

On 06/23/2014 02:20 PM, Felipe Balbi wrote:
> Add support for TI's AM437x StarterKit Evaluation
> Module.
> 
> Cc: Josh Elliot 
> Cc: Darren Etheridge 
> Signed-off-by: Felipe Balbi 

Tested-by: Tom Rini 

-- 
Tom
--
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

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

[Tom Rini]

On 06/23/2014 02:20 PM, Felipe Balbi wrote:
> by providing phandles to rtc, wdt, cpu and dispc nodes,
> boards can access them to add board-specific data.
> 
> Signed-off-by: Felipe Balbi 

Tested-by: Tom Rini 

-- 
Tom
--
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

Re: OF_DYNAMIC node lifecycle

[Nathan Fontenot]

On 06/23/2014 09:48 AM, Grant Likely wrote:
> On Thu, 19 Jun 2014 10:26:15 -0500, Nathan Fontenot  
> wrote:
>> On 06/18/2014 03:07 PM, Grant Likely wrote:
>>> Hi Nathan and Tyrel,
>>>
>>> I'm looking into lifecycle issues on nodes modified by OF_DYNAMIC, and
>>> I'm hoping you can help me. Right now, pseries seems to be the only
>>> user of OF_DYNAMIC, but making OF_DYNAMIC work has a huge impact on
>>> the entire kernel because it requires all DT code to manage reference
>>> counting with iterating over nodes. Most users simply get it wrong.
>>> Pantelis did some investigation and found that the reference counts on
>>> a running kernel are all over the place. I have my doubts that any
>>> code really gets it right.
>>>
>>> The problem is that users need to know when it is appropriate to call
>>> of_node_get()/of_node_put(). All list traversals that exit early need
>>> an extra call to of_node_put(), and code that is searching for a node
>>> in the tree and holding a reference to it needs to call of_node_get().
>>>
>>> I've got a few pseries questions:
>>> - What are the changes being requested by pseries firmware? Is it only
>>> CPUs and memory nodes, or does it manipulate things all over the tree?
>>
>> The short answer, everything.
> 
> :-)
> 
>> For pseries the two big actions that can change the device tree are
>> adding/removing resources and partition migration.
>>
>> The most frequent updates to the device tree happen during resource
>> (cpu, memory, and pci/phb) add and remove. During this process we add
>> and remove the node and its properties from the device tree.
>> - For memory on newer systems this just involves updating the
>>   ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory property. Older
>>   firmware levels add and remove the memroy@XXX nodes and their properties.
>> - For cpus the cpus/PowerPC,POWER nodes and its properties are added
>>   or removed
>> - For pci/phb the pci@X nodes and properties are added/removed.
>>
>> The less frequent operation of live partition migration (and suspend/resume)
>> can update just about anything in the device tree. When this occurs and the
>> systems starts after being migrated (or waking up after a suspend) we make
>> a call to firmware to get updates to the device tree for the new hardware
>> we are running on.
>>  
>>> - How frequent are the changes? How many changes would be likely over
>>> the runtime of the system?
>>
>> This can happen frequently.
> 
> Thanks, that is exactly the information that I want. I'm not so much
> concerned with the addition or removal of nodes/properties, which is
> actually pretty easy to handle. It is the lifecycle of allocations on
> dynamic nodes that causes heartburn.
> 
>>> - Are you able to verify that removed nodes are actually able to be
>>> freed correctly? Do you have any testcases for node removal?
>>
>> I have always tested this by doing resource add/remove, usually cpu and 
>> memory
>> since it is the easiest.
> 
> Is that just testing the functionality, or do you have tests that check
> if the memory gets freed?

In general it's just functionality testing.

> 
>>> I'm thinking very seriously about changing the locking semantics of DT
>>> code entirely so that most users never have to worry about
>>> of_node_get/put at all. If the DT code is switched to use rcu
>>> primitives for tree iteration (which also means making DT code use
>>> list_head, something I'm already investigating), then instead of
>>> trying to figure out of_node_get/put rules, callers could use
>>> rcu_read_lock()/rcu_read_unlock() to protect the region that is
>>> searching over nodes, and only call of_node_get() if the node pointer
>>> is needed outside the rcu read-side lock.
>>>
>>
>> This sounds good. I like just taking the rcu lock around accessing the DT.
>> Do we have many places where DT node pointers are held that require
>> keeping the of_node_get/put calls? If this did exist perhaps we could
>> update those places to look up the DT node every time instead of
>> holding on to the pointer. We could just get rid of the reference counting
>> altogether then.
> 
> There are a few, but I would be happy to restrict reference counting to
> only those locations. Most places will decode the DT data, and then
> throw away the reference. We /might/ even be able to do rcu_lock/unlock
> around the entire probe path which would make it transparent to all
> device drivers.
> 
>>> I'd really like to be rid of the node reference counting entirely, but
>>> I can't figure out a way of doing that safely, so I'd settle for
>>> making it a lot easier to get correct.
>>>
>>
>> heh! I have often thought about adding reference counting to device tree
>> properties.
> 
> You horrible, horrible man.

Yes. I are evil :)

After looking again the work needed to add reference counts to properties
would be huge. The few properties I am concerned with are specific to powerpc
so perhaps just adding an arch specific lock around updating those

Re: OF_DYNAMIC node lifecycle

[Nathan Fontenot]

On 06/23/2014 09:58 AM, Grant Likely wrote:
> On Thu, 19 Jun 2014 11:33:20 +0300, Pantelis Antoniou 
>  wrote:
>> Hi Grant,
>>
>> CCing Thomas Gleixner & Steven Rostedt, since they might have a few
>> ideas...
>>
>> On Jun 18, 2014, at 11:07 PM, Grant Likely wrote:
>>
>>> Hi Nathan and Tyrel,
>>>
>>> I'm looking into lifecycle issues on nodes modified by OF_DYNAMIC, and
>>> I'm hoping you can help me. Right now, pseries seems to be the only
>>> user of OF_DYNAMIC, but making OF_DYNAMIC work has a huge impact on
>>> the entire kernel because it requires all DT code to manage reference
>>> counting with iterating over nodes. Most users simply get it wrong.
>>> Pantelis did some investigation and found that the reference counts on
>>> a running kernel are all over the place. I have my doubts that any
>>> code really gets it right.
>>>
>>> The problem is that users need to know when it is appropriate to call
>>> of_node_get()/of_node_put(). All list traversals that exit early need
>>> an extra call to of_node_put(), and code that is searching for a node
>>> in the tree and holding a reference to it needs to call of_node_get().
>>>
>>
>> In hindsight it appears that drivers just can't get the lifecycle right.
>> So we need to simplify things.
>>
>>> I've got a few pseries questions:
>>> - What are the changes being requested by pseries firmware? Is it only
>>> CPUs and memory nodes, or does it manipulate things all over the tree?
>>> - How frequent are the changes? How many changes would be likely over
>>> the runtime of the system?
>>> - Are you able to verify that removed nodes are actually able to be
>>> freed correctly? Do you have any testcases for node removal?
>>>
>>> I'm thinking very seriously about changing the locking semantics of DT
>>> code entirely so that most users never have to worry about
>>> of_node_get/put at all. If the DT code is switched to use rcu
>>> primitives for tree iteration (which also means making DT code use
>>> list_head, something I'm already investigating), then instead of
>>> trying to figure out of_node_get/put rules, callers could use
>>> rcu_read_lock()/rcu_read_unlock() to protect the region that is
>>> searching over nodes, and only call of_node_get() if the node pointer
>>> is needed outside the rcu read-side lock.
>>>
>>> I'd really like to be rid of the node reference counting entirely, but
>>> I can't figure out a way of doing that safely, so I'd settle for
>>> making it a lot easier to get correct.
>>>
>>
>> Since we're going about changing things, how about that devtree_lock?
> 
> I believe rcu would pretty much eliminate the devtree_lock entirely. All
> modifiers would need to grab a mutex to ensure there is only one writer
> at any given time, but readers would have free reign to parse the tree
> however they like.
> 
> DT writers would have to follow some strict rules about how to handle
> nodes that are removed (ie. don't modify or of_node_put() them until
> after rcu is syncronized), but the number of writers is very small and
> we have control of all of them.
> 
>> We're using a raw_spinlock and we're always taking the lock with
>> interrupts disabled.
>>
>> If we're going to make DT changes frequently during normal runtime
>> and not only during boot time, those are bad for any kind of real-time
>> performance.
>>
>> So the question is, do we really have code that access the live tree
>> during atomic sections?  Is that something we want? Enforcing this
>> will make our lives easier, and we'll get the change to replace
>> that spinlock with a mutex.
> 
> Yes, I believe the powerpc CPU hotplug code accesses the DT in atomic
> sections. I cannot put my finger on the exact code however. Nathan might
> know better. But, if I'm right, the whole problem goes away with RCU.

I went back through the cpu hotplug code. we do update the DT during cpu
hotplug but I don't see it happening during atomic sections.

The code is in arch/powerpc/platforms/pseries/dlpar.c

-Nathan

> 
> The design with RCU is to switch struct device_node and struct property
> to use list_head and/or hlist_head with the _rcu accessors. They allow
> items to be removed from a list without syncronizing with readers. Right
> now we have two lists that need to be modified; the allnodes list and
> the sibling list. I *think* it will be fine for the two list removals to
> be non-atomic (there will be a brief period where the node can be found
> on one list, but not the other) because it is a transient state already
> accounted for in rcu read-side critical region.
> 
> That said, I've also got a design to remove the allnodes list entirely
> and only work with the sibling list. I need to prototype this.
> 
> We'll also need a transition plan to move to RCU. I think the existing
> iterators can be modified to do the rcu locking in-line, but still require
> the of_node_get/put stuff (basically, so existing code continue to works
> unchanged). Then we can add _rcu versions that drop the need for
> of_no

Re: [PATCH v3 3/7] irqchip: atmel-aic: add new atmel AIC driver

[Jason Cooper]

On Tue, Jun 24, 2014 at 06:14:27PM +0200, Boris BREZILLON wrote:
> On 24/06/2014 14:56, Jason Cooper wrote:
...
> > Once you post the new series, I assume it's ok to apply patches 1-3 to
> > irqchip/core, or are there some dependency considerations?
> 
> Patches 6 and 7 depend on the 3 first patches, but we should be able to
> merge them through the at91/arm-soc tree (Nicolas might have to rebase
> its tree for 3.17 on irqchip/core after you have applied patches 1-3).

I'll create a topic branch for you when the time comes.  That way
arm-soc doesn't have to pull in any code it doesn't actually need (helps
with for-next testing).

Please give me a gentle reminder in the coverletter or comments when you
send the next version.

> Anyway, I'd like to wait for at91 maintainers/developers reviews before
> posting a new version.

Sure.

thx,

Jason.
--
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

Re: [PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Rob Herring]

On Tue, Jun 24, 2014 at 10:06 AM, Russell King - ARM Linux
 wrote:
> Denis,
>
> This patch creates binding documentation.  Any patch which does so
> should be copied to the DT people so they can review the bindings
> and give appropriate acks.  It would be better if you separate the
> binding documentation updates from the other functional changes too.
>
> I've added them on this reply to see whether they'll feel friendly
> enough to comment on the patch as it stands to avoid having to go
> through two more rounds on this already-fourteen revision patch set.
>
> On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
>> Signed-off-by: Denis Carikli 
>> ---
>> ChangeLog v13->v14:
>> - None
>>
>> ChangeLog v12->v13:
>> - Added a note explaining why the size is zero in
>>   the eukrea_mbimxsd51_dvi(s)vga structs.
>> ChangeLog v11->v12:
>> - Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
>>
>> ChangeLog v10->v11:
>> - New patch.
>> ---
>>  .../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt   |7 ++
>>  .../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt   |7 ++
>>  .../bindings/panel/eukrea,mbimxsd51-dvi-vga.txt|7 ++
>>  drivers/gpu/drm/panel/panel-simple.c   |   83 
>> 
>>  4 files changed, 104 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt 
>> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
>> new file mode 100644
>> index 000..03679d0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
>> @@ -0,0 +1,7 @@
>> +Eukrea CMO-QVGA (320x240 pixels) TFT LCD panel
>> +
>> +Required properties:
>> +- compatible: should be "eukrea,mbimxsd51-cmo-qvga"
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.
>> diff --git 
>> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt 
>> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
>> new file mode 100644
>> index 000..f408c9a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
>> @@ -0,0 +1,7 @@
>> +Eukrea DVI-SVGA (800x600 pixels) DVI output.
>> +
>> +Required properties:
>> +- compatible: should be "eukrea,mbimxsd51-dvi-svga"
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.
>> diff --git 
>> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
>> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
>> new file mode 100644
>> index 000..8ea90da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
>> @@ -0,0 +1,7 @@
>> +Eukrea DVI-VGA (640x480 pixels) DVI output.
>> +
>> +Required properties:
>> +- compatible: should be "eukrea,mbimxsd51-dvi-vga"
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.

Seems like we could just have a list of compatible strings rather than
a mostly duplicated file.

>> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
>> b/drivers/gpu/drm/panel/panel-simple.c
>> index a251361..adc40a7 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -403,6 +403,80 @@ static const struct panel_desc edt_etm0700g0dh6 = {
>>   },
>>  };
>>
>> +static const struct drm_display_mode eukrea_mbimxsd51_cmoqvga_mode = {
>> + .clock = 6500,
>> + .hdisplay = 320,
>> + .hsync_start = 320 + 38,
>> + .hsync_end = 320 + 38 + 20,
>> + .htotal = 320 + 38 + 20 + 30,
>> + .vdisplay = 240,
>> + .vsync_start = 240 + 15,
>> + .vsync_end = 240 + 15 + 4,
>> + .vtotal = 240 + 15 + 4 + 3,
>> + .vrefresh = 60,
>> + .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE |
>> +  DRM_MODE_FLAG_POL_DE_LOW,

Why aren't you using:

Documentation/devicetree/bindings/video/display-timing.txt

Rob
--
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

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

[Cooper Jr., Franklin]

Tested-by: Franklin Cooper Jr. 

> -Original Message-
> From: Balbi, Felipe
> Sent: Monday, June 23, 2014 1:21 PM
> To: Benoit Cousson
> Cc: robh...@kernel.org; ga...@codeaurora.org; Tony Lindgren;
> li...@arm.linux.org.uk; Nayak, Rajendra; Menon, Nishanth; R, Sricharan;
> devicetree@vger.kernel.org; Linux Kernel Mailing List; Linux OMAP Mailing
> List; Linux ARM Kernel Mailing List; Balbi, Felipe
> Subject: [PATCH v3 1/2] arm: dts: am4372: let boards access all nodes through
> phandles
> 
> by providing phandles to rtc, wdt, cpu and dispc nodes, boards can access
> them to add board-specific data.
> 
> Signed-off-by: Felipe Balbi 
> ---
> 
> 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 =  279,7 +279,7 @@
>   status = "disabled";
>   };
> 
> - wdt@44e35000 {
> + wdt: wdt@44e35000 {
>   compatible = "ti,am4372-wdt","ti,omap3-wdt";
>   reg = <0x44e35000 0x1000>;
>   interrupts = ; @@
> -871,7 +871,7 @@
>   #size-cells = <1>;
>   ranges;
> 
> - dispc@4832a400 {
> + dispc: dispc@4832a400 {
>   compatible = "ti,omap3-dispc";
>   reg = <0x4832a400 0x400>;
>   interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> --
> 2.0.0.390.gcb682f8

--
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

RE: [PATCH v3 2/2] arm: dts: add support for AM437x StarterKit

[Cooper Jr., Franklin]

Tested-by: Franklin Cooper Jr. 

> -Original Message-
> From: Balbi, Felipe
> Sent: Monday, June 23, 2014 1:21 PM
> To: Benoit Cousson
> Cc: robh...@kernel.org; ga...@codeaurora.org; Tony Lindgren;
> li...@arm.linux.org.uk; Nayak, Rajendra; Menon, Nishanth; R, Sricharan;
> devicetree@vger.kernel.org; Linux Kernel Mailing List; Linux OMAP Mailing
> List; Linux ARM Kernel Mailing List; Balbi, Felipe; Elliott, Josh; Etheridge,
> Darren
> Subject: [PATCH v3 2/2] arm: dts: add support for AM437x StarterKit
> 
> Add support for TI's AM437x StarterKit Evaluation Module.
> 
> Cc: Josh Elliot 
> Cc: Darren Etheridge 
> Signed-off-by: Felipe Balbi 
> ---
> 
> changes since v1:
>   - add pinctrl for leds and matrix keypad
>   - added i2c1 and i2c0 speeds of 400k
>   - added voltage for vdds_ddr
>   - reordered mmc1 node
> 
> left the USB supply thing out because a) the driver doesn't use it and b) the
> regulator will be automatically sitched off iff DRVVBUS signal goes low 
> (that's
> done automatically by the HW). Not to mention that there's really no benefit
> from the kernel or userland point of view.
> 
> (I do have a patch for that locally though, so if people really want it, I can
> easily fold the patch into this).
> 
> All patches are available at [1]
> 
> [1] https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=am437x-
> starterkit
> 
>  .../devicetree/bindings/arm/omap/omap.txt  |   3 +
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/am437x-sk-evm.dts| 613
> +
>  3 files changed, 617 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index d22b216..0edc903 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -129,6 +129,9 @@ Boards:
>  - AM437x GP EVM
>compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
> 
> +- AM437x SK EVM: AM437x StarterKit Evaluation Module
> +  compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
> +
>  - 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
> 621c6c5..a85a4b8 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-
> parlor.dtb \
>   omap4-var-dvk-om44.dtb \
>   omap4-var-stk-om44.dtb
>  dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
> + am437x-sk-evm.dtb \
>   am437x-gp-evm.dtb
>  dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
>   omap5-sbc-t54.dtb \
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
> b/arch/arm/boot/dts/am437x-sk-evm.dts
> new file mode 100644
> index 000..859ff3d
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -0,0 +1,613 @@
> +/*
> + * Copyright (C) 2014 Texas Instruments Incorporated -
> +http://www.ti.com/
> + *
> + * 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.
> + */
> +
> +/* AM437x SK EVM */
> +
> +/dts-v1/;
> +
> +#include "am4372.dtsi"
> +#include  #include
> + #include  #include
> +
> +
> +/ {
> + model = "TI AM437x SK EVM";
> + compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
> +
> + aliases {
> + display0 = &lcd0;
> + };
> +
> + backlight {
> + compatible = "pwm-backlight";
> + pwms = <&ecap0 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 51 53 56 62 75 101 152 255>;
> + default-brightness-level = <8>;
> + };
> +
> + sound {
> + compatible = "ti,da830-evm-audio";
> + ti,model = "AM437x-SK-EVM";
> + ti,audio-codec = <&tlv320aic3106>;
> + ti,mcasp-controller = <&mcasp1>;
> + ti,codec-clock-rate = <2400>;
> + ti,audio-routing =
> + "Headphone Jack",   "HPLOUT",
> + "Headphone Jack",   "HPROUT";
> + };
> +
> + matrix_keypad: matrix_keypad@0 {
> + compatible = "gpio-matrix-keypad";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&matrix_keypad_pins>;
> +
> + debounce-delay-ms = <5>;
> + col-scan-delay-us = <1500>;
> +
> + row-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH  /*
> Bank5, pin5 */
> + &gpio5 6 GPIO_ACTIVE_HIGH>; /* Bank5,
> pin6 */
> +
> + col-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH /*
> Bank5, pin13 */
> + &gpio5 4 GPIO_ACTIVE_HIGH>; /* Bank5,
> pin4 */
> +
> + linux,keymap 

Re: [PATCH v2] pinctrl: msm: Add msm8960 definitions

[Mark Rutland]

On Tue, Jun 24, 2014 at 07:16:06PM +0100, Bjorn Andersson wrote:
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Changes since v1:
>  - Deduplicated functions for alternative pins
> 
>  .../bindings/pinctrl/qcom,msm8960-pinctrl.txt  |  103 ++
>  drivers/pinctrl/Kconfig|8 +
>  drivers/pinctrl/Makefile   |1 +
>  drivers/pinctrl/pinctrl-msm8960.c  | 1146 
> 
>  4 files changed, 1258 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
>  create mode 100644 drivers/pinctrl/pinctrl-msm8960.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
> new file mode 100644
> index 000..6e79eea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
> @@ -0,0 +1,103 @@
> +Qualcomm MSM8960 TLMM block
> +
> +Required properties:
> +- compatible: "qcom,msm8960-pinctrl"
> +- reg: Should be the base address and length of the TLMM block.
> +- interrupts: Should be the parent IRQ of the TLMM block.
> +- interrupt-controller: Marks the device node as an interrupt controller.
> +- #interrupt-cells: Should be two.

There should be a description of valid values for the two cells of an
interrupt-specifier.

> +- gpio-controller: Marks the device node as a GPIO controller.
> +- #gpio-cells : Should be two.
> +The first cell is the gpio pin number and the
> +second cell is used for optional parameters.

And what are those optional parameters?

[...]

> +Example:
> +
> +   msmgpio: pinctrl@80 {
> +   compatible = "qcom,msm8960-pinctrl";
> +   reg = <0x80 0x4000>;
> +
> +   gpio-controller;
> +   #gpio-cells = <2>;
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +interrupts = <0 32 0x4>;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&debug_uart>;

The fact that the pinctrl block itself supports pinctrl properties was
not described above.

Thanks,
Mark.
--
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

Re: [PATCH v4 0/3] Add R8A7791/Koelsch/Henninger board PCI DT support

[Arnd Bergmann]

On Tuesday 24 June 2014 22:07:31 Sergei Shtylyov wrote:
> 
>Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
> 'renesas-devel-v3.16-rc2-20140623' tag. Here we add PCI USB device tree 
> support
> for the R8A7791-based Koelsch and Henninger boards. As the 'pci-rcar-gen2'
> driver device tree support has been merged for 3.16, this patchset can now be
> merged too... 
> 
> [1/3] ARM: shmobile: r8a7791: add internal PCI bridge nodes
> [2/3] ARM: shmobile: koelsch: enable internal PCI
> [3/3] ARM: shmobile: henninger: enable internal PCI
> 

Acked-by: Arnd Bergmann 
--
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

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Arnd Bergmann]

On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
> On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
> > On 6/24/2014 2:18 AM, Will Deacon wrote:
> > > On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
> > >> We have multiple-master SMMUs and each master emits a variable number of
> > >> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
> > >> for this) to the StreamIDs due to limited number of StreamID 2 Context
> > >> Bank entries in the SMMU. If my understanding is correct we would
> > >> represent this in the DT like this:
> > >>
> > >>iommu {
> > >>#address-cells = <2>;
> > >>#size-cells = <0>;
> > >>};
> > >>
> > >>master@a {
> > >>...
> > >>iommus = <&iommu StreamID0 MASK0>,
> > >> <&iommu StreamID1 MASK1>,
> > >> <&iommu StreamID2 MASK2>;
> > >>};
> > > 
> > > Stupid question, but why not simply describe the masked IDs? What use does
> > > the `raw' ID have to Linux?
> > 
> > We do describe the masked StreamID (SID) but we need to specify the mask
> > that the SMMU should apply to the incoming SIDs, right?
> > 
> > We have a bus master that emits 43 unique SIDs. However, we have only 40
> > SMMU_SMRn registers in the SMMU. So we need to mask out some of the
> > incoming SID bits so that the 43 SIDs can match one of 40 entries in the
> > SMR.
> 
> Hmm, so you're talking about stream matching, right? That doesn't belong in
> the device-tree. I appreciate that the current driver does a terrible job at
> allocating the SMRs (it's bloody difficult!), but we should try to improve
> the dynamic behaviour instead of moving configuration of the SMMU out into
> device-tree, where it's inflexible at best.
> 
> There have been patches previously posted by Andreas Herrmann helping here.
> I'd be glad to see them revived.

Note that there are areas where we have in the past decided that dynamic
configuration is just too hard for the kernel to do and that we're better
off putting the configuration into DT. Pinctrl and clocks are at least
partially in that category.

It's always best if you can get the kernel to do things in the ideal
way where that is possible, but getting there may be just not worth it.

I have no idea where it should be for SMMU, but it's something to consider:
if you can take reasonable shortcuts by reading parts of the configuration
from DT, you may just as well do that.

Arnd
--
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

[PATCH v2] pinctrl: msm: Add msm8960 definitions

[Bjorn Andersson]

Signed-off-by: Bjorn Andersson 
---

Changes since v1:
 - Deduplicated functions for alternative pins

 .../bindings/pinctrl/qcom,msm8960-pinctrl.txt  |  103 ++
 drivers/pinctrl/Kconfig|8 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-msm8960.c  | 1146 
 4 files changed, 1258 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
 create mode 100644 drivers/pinctrl/pinctrl-msm8960.c

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
new file mode 100644
index 000..6e79eea
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
@@ -0,0 +1,103 @@
+Qualcomm MSM8960 TLMM block
+
+Required properties:
+- compatible: "qcom,msm8960-pinctrl"
+- reg: Should be the base address and length of the TLMM block.
+- interrupts: Should be the parent IRQ of the TLMM block.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+The first cell is the gpio pin number and the
+second cell is used for optional parameters.
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Qualcomm's pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+ pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength,
+ output-low, output-high.
+
+Non-empty subnodes must specify the 'pins' property.
+Note that not all properties are valid for all pins.
+
+
+Valid values for pins are:
+  gpio0-gpio151
+Supports mux, bias, drive-strength and output level
+
+  sdc1_clk, sdc1_cmd, sdc1_data, sdc3_clk, sdc3_cmd, sdc3_data
+Supports bias and drive-strength
+
+Valid values for function are:
+  audio_pcm, bt, cam_mclk0, cam_mclk1, cam_mclk2, codec_mic_i2s,
+  codec_spkr_i2s, ext_gps, fm, gps_blanking, gps_pps_in, gps_pps_out,
+  gp_clk_0, gp_clk_1, gp_clk_2, gp_mn, gp_pdm_0, gp_pdm_1, gp_pdm_2,
+  gsbi1, gsbi1_spi_cs1_n, gsbi1_spi_cs2_n, gsbi1_spi_cs3_n, gsbi2,
+  gsbi2_spi_cs1_n, gsbi2_spi_cs2_n, gsbi2_spi_cs3_n, gsbi3, gsbi4,
+  gsbi4_3d_cam_i2c_l, gsbi4_3d_cam_i2c_r, gsbi5, gsbi5_3d_cam_i2c_l,
+  gsbi5_3d_cam_i2c_r, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10, gsbi11,
+  gsbi11_spi_cs1_n, gsbi11_spi_cs2_n, gsbi11_spi_cs3_n, gsbi12, hdmi_cec,
+  hdmi_ddc_clock, hdmi_ddc_data, hdmi_hot_plug_detect, hsic, mdp_vsync,
+  mi2s, mic_i2s, pmb_clk, pmb_ext_ctrl, ps_hold, rpm_wdog, sdc2, sdc4,
+  sdc5, slimbus1, slimbus2, spkr_i2s, ssbi1, ssbi2, ssbi_ext_gps,
+  ssbi_pmic2, ssbi_qpa1, ssbi_ts, tsif1, tsif2, ts_eoc, usb_fs1,
+  usb_fs1_oe, usb_fs1_oe_n, usb_fs2, usb_fs2_oe, usb_fs2_oe_n,
+  vfe_camif_timer1, vfe_camif_timer2, vfe_camif_timer3, vfe_camif_timer4,
+  vfe_camif_timer5, vfe_camif_timer6, vfe_camif_timer7, wlan
+
+Example:
+
+   msmgpio: pinctrl@80 {
+   compatible = "qcom,msm8960-pinctrl";
+   reg = <0x80 0x4000>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+interrupts = <0 32 0x4>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&debug_uart>;
+
+   debug_uart: debug_uart {
+   mux {
+   pins = "gpio34", "gpio35";
+   function = "gsbi8";
+   };
+
+   tx {
+   pins = "gpio34";
+   drive-strength = <4>;
+   bias-disable;
+  

[PATCH v4 3/3] ARM: shmobile: henninger: enable internal PCI

[Sergei Shtylyov]

Enable internal AHB-PCI bridges for the USB EHCI/OHCI controllers attached to
them.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 4:
- moved the PCI bridge nodes before PCIe clock/bridge nodes.

Changes in version 3:
- refreshed the patch.

 arch/arm/boot/dts/r8a7791-henninger.dts |   22 ++
 1 file changed, 22 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791-henninger.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-henninger.dts
+++ renesas/arch/arm/boot/dts/r8a7791-henninger.dts
@@ -125,6 +125,16 @@
 "msiof0_tx";
renesas,function = "msiof0";
};
+
+   usb0_pins: usb0 {
+   renesas,groups = "usb0";
+   renesas,function = "usb0";
+   };
+
+   usb1_pins: usb1 {
+   renesas,groups = "usb1";
+   renesas,function = "usb1";
+   };
 };
 
 &scif0 {
@@ -231,6 +241,18 @@
};
 };
 
+&pci0 {
+   status = "okay";
+   pinctrl-0 = <&usb0_pins>;
+   pinctrl-names = "default";
+};
+
+&pci1 {
+   status = "okay";
+   pinctrl-0 = <&usb1_pins>;
+   pinctrl-names = "default";
+};
+
 &pcie_bus_clk {
status = "okay";
 };
--
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

[PATCH v4 2/3] ARM: shmobile: koelsch: enable internal PCI

[Sergei Shtylyov]

Enable internal AHB-PCI bridges for the USB EHCI/OHCI controllers attached to
them.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 3:
- refreshed the patch.

Changes in version 2:
- refreshed the patch.

 arch/arm/boot/dts/r8a7791-koelsch.dts |   22 ++
 1 file changed, 22 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791-koelsch.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ renesas/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -279,6 +279,16 @@
renesas,groups = "i2c6";
renesas,function = "i2c6";
};
+
+   usb0_pins: usb0 {
+   renesas,groups = "usb0";
+   renesas,function = "usb0";
+   };
+
+   usb1_pins: usb1 {
+   renesas,groups = "usb1";
+   renesas,function = "usb1";
+   };
 };
 
 ðer {
@@ -426,6 +436,18 @@
};
 };
 
+&pci0 {
+   status = "okay";
+   pinctrl-0 = <&usb0_pins>;
+   pinctrl-names = "default";
+};
+
+&pci1 {
+   status = "okay";
+   pinctrl-0 = <&usb1_pins>;
+   pinctrl-names = "default";
+};
+
 &pcie_bus_clk {
status = "okay";
 };
--
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

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Will Deacon]

On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
> On 6/24/2014 2:18 AM, Will Deacon wrote:
> > On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
> >> We have multiple-master SMMUs and each master emits a variable number of
> >> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
> >> for this) to the StreamIDs due to limited number of StreamID 2 Context
> >> Bank entries in the SMMU. If my understanding is correct we would
> >> represent this in the DT like this:
> >>
> >>iommu {
> >>#address-cells = <2>;
> >>#size-cells = <0>;
> >>};
> >>
> >>master@a {
> >>...
> >>iommus = <&iommu StreamID0 MASK0>,
> >> <&iommu StreamID1 MASK1>,
> >> <&iommu StreamID2 MASK2>;
> >>};
> > 
> > Stupid question, but why not simply describe the masked IDs? What use does
> > the `raw' ID have to Linux?
> 
> We do describe the masked StreamID (SID) but we need to specify the mask
> that the SMMU should apply to the incoming SIDs, right?
> 
> We have a bus master that emits 43 unique SIDs. However, we have only 40
> SMMU_SMRn registers in the SMMU. So we need to mask out some of the
> incoming SID bits so that the 43 SIDs can match one of 40 entries in the
> SMR.

Hmm, so you're talking about stream matching, right? That doesn't belong in
the device-tree. I appreciate that the current driver does a terrible job at
allocating the SMRs (it's bloody difficult!), but we should try to improve
the dynamic behaviour instead of moving configuration of the SMMU out into
device-tree, where it's inflexible at best.

There have been patches previously posted by Andreas Herrmann helping here.
I'd be glad to see them revived.

Will
--
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

Re: [PATCH v5 1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes

[Arnd Bergmann]

On Tuesday 24 June 2014 21:59:54 Sergei Shtylyov wrote:
> From: Ben Dooks 
> 
> Add device nodes for the R8A7790 internal PCI bridge devices.
> 
> Signed-off-by: Ben Dooks 
> Reviewed-by: Ian Molton 
> [Sergei: added several properties to the PCI bridge nodes]
> Signed-off-by: Sergei Shtylyov 

Yes, looks better, thanks for the update.

Acked-by: Arnd Bergmann 
--
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

[PATCH v4 1/3] ARM: shmobile: r8a7791: add internal PCI bridge nodes

[Sergei Shtylyov]

Add device nodes for the R8A7791 internal PCI bridge devices.

Signed-off-by: Sergei Shtylyov 

---
Changes in version 4:
- added "device_type" and "ranges" properties to the PCI bridge nodes;
- removed "0x" prefix from zero values in the "reg" properties.

Changes in version 3:
- refreshed the patch.

Changes in version 2:
- added interrupt-related properties to the PCI device nodes;
- refreshed the patch.

 arch/arm/boot/dts/r8a7791.dtsi |   40 
 1 file changed, 40 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -961,6 +961,46 @@
status = "disabled";
};
 
+   pci0: pci@ee09 {
+   compatible = "renesas,pci-r8a7791";
+   device_type = "pci";
+   clocks = <&mstp7_clks R8A7791_CLK_EHCI>;
+   reg = <0 0xee09 0 0xc00>,
+ <0 0xee08 0 0x1100>;
+   interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+   status = "disabled";
+
+   bus-range = <0 0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   ranges = <0x0200 0 0xee08 0 0xee08 0 0x0001>;
+   interrupt-map-mask = <0xff00 0 0 0x7>;
+   interrupt-map = <0x 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
+0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
+0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+   };
+
+   pci1: pci@ee0d {
+   compatible = "renesas,pci-r8a7791";
+   device_type = "pci";
+   clocks = <&mstp7_clks R8A7791_CLK_EHCI>;
+   reg = <0 0xee0d 0 0xc00>,
+ <0 0xee0c 0 0x1100>;
+   interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>;
+   status = "disabled";
+
+   bus-range = <1 1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   ranges = <0x0200 0 0xee0c 0 0xee0c 0 0x0001>;
+   interrupt-map-mask = <0xff00 0 0 0x7>;
+   interrupt-map = <0x 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
+0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
+0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+   };
+
pciec: pcie@fe00 {
compatible = "renesas,pcie-r8a7791";
reg = <0 0xfe00 0 0x8>;
--
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

mfd: sec-core requires regulators

[Arnd Bergmann]

The newly added sec-core mfd module calls the regulator_suspend_prepare()
function, which is only available if the regulator API is provided. This
matches the usage of the driver, so we can just add a Kconfig dependency.

Reported-by: Jim Davis 
Signed-off-by: Arnd Bergmann 

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 207c433..1caa3c5 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -582,7 +582,7 @@ config MFD_RC5T583
 
 config MFD_SEC_CORE
bool "SAMSUNG Electronics PMIC Series Support"
-   depends on I2C=y
+   depends on I2C=y && REGULATOR
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
--
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

[PATCH v4 0/3] Add R8A7791/Koelsch/Henninger board PCI DT support

[Sergei Shtylyov]

Hello.

   Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-v3.16-rc2-20140623' tag. Here we add PCI USB device tree support
for the R8A7791-based Koelsch and Henninger boards. As the 'pci-rcar-gen2'
driver device tree support has been merged for 3.16, this patchset can now be
merged too... 

[1/3] ARM: shmobile: r8a7791: add internal PCI bridge nodes
[2/3] ARM: shmobile: koelsch: enable internal PCI
[3/3] ARM: shmobile: henninger: enable internal PCI

WBR, Sergei
--
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

Re: [PATCH 1/2] regulator: max1586 add device-tree support

[Robert Jarzmik]

Mark Brown  writes:

> On Tue, Jun 17, 2014 at 09:16:52PM +0200, Robert Jarzmik wrote:
>> Mark Brown  writes:
>> > On Sat, Jun 14, 2014 at 04:54:24PM +0200, Robert Jarzmik wrote:
>
>> >> + matched = of_regulator_match(dev, np, rmatch, ARRAY_SIZE(rmatch));
>> >> + of_node_put(np);
>> >> + if (matched <= 0)
>> >> + return matched;
>
>> > Why is this treating zero as an error?  We should be able to at least
>> > report the current state of regulators even if none are configured in
>> > the device tree.
>
>> Euh how so an error ?
>
>> If 0 is returned, this means no regulators are found in device-tree. It's 
>> not an
>> error, it's a lack of regulators (ie. no Output_V3 and no Output_V6), and no
>> more handling is necessary in this function, while returning "ok", ie 0 ...
>
> OK, so there's just nothing to do in that case.  That's fine, but it's
> just not at all clear from the code.  A comment would help.
OK, no problem.

>
>> As for the "state report", this max1586 doesn't report anything, it cannot 
>> even
>> be queried about the current voltage, sic ...
>
> It can't?  That's unfortunate, though I was able to turn up a datasheet
> which appears to support that.
Oh really ? Well, tell me where you read it.

My personal reading from the Max1586 specs is (page 21, chapter "Serial 
Interface") :
The LSB of the address word is the read/write (R/W) bit.
R/W indicates whether the master is writing or reading
(RD/W 0 = write, RD/W 1 = read). The MAX1586/
MAX1587 only support the SEND BYTE format; there-
fore, RD/W is required to be 0.

I'm wondering if you have this sentence in your datasheet too.

>> If you want me to modify this bit I need a bit more of an explanation to
>> understand.
>
> Where the driver is doing unusual things if they are actually sensible
> then the change needs to be clearer about why.
So would a comment like this address your comment ?

/* Either matched < 0 and return the error. Or matched is 0 which means
 * no init data was found, ie. no regulator is configured, and return 0
 * to caller, stating neither error nor any matched regulator.
 */

if (matched <= 0)
return matched;

Cheers.

-- 
Robert
--
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

[PATCH v5 2/2] ARM: shmobile: lager: enable internal PCI

[Sergei Shtylyov]

From: Ben Dooks 

Enable internal AHB-PCI bridges for the USB EHCI/OHCI controllers attached to
them.

Signed-off-by: Ben Dooks 
Reviewed-by: Ian Molton 
[Sergei: enabled PCI0]
Signed-off-by: Sergei Shtylyov 

---
Changes in version 4:
- refreshed the patch.

Changes in version 3:
- refreshed the patch.

Changes in version 2:
- enabled PCI0 device;
- reworded summary and changelog;
- refreshed the patch.

 arch/arm/boot/dts/r8a7790-lager.dts |   33 +
 1 file changed, 33 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7790-lager.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7790-lager.dts
+++ renesas/arch/arm/boot/dts/r8a7790-lager.dts
@@ -219,6 +219,21 @@
renesas,groups = "i2c3";
renesas,function = "i2c3";
};
+
+   usb0_pins: usb0 {
+   renesas,groups = "usb0";
+   renesas,function = "usb0";
+   };
+
+   usb1_pins: usb1 {
+   renesas,groups = "usb1";
+   renesas,function = "usb1";
+   };
+
+   usb2_pins: usb2 {
+   renesas,groups = "usb2";
+   renesas,function = "usb2";
+   };
 };
 
 ðer {
@@ -368,3 +383,21 @@
regulator-always-on;
};
 };
+
+&pci0 {
+   status = "okay";
+   pinctrl-0 = <&usb0_pins>;
+   pinctrl-names = "default";
+};
+
+&pci1 {
+   status = "okay";
+   pinctrl-0 = <&usb1_pins>;
+   pinctrl-names = "default";
+};
+
+&pci2 {
+   status = "okay";
+   pinctrl-0 = <&usb2_pins>;
+   pinctrl-names = "default";
+};
--
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

[PATCH v5 1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes

[Sergei Shtylyov]

From: Ben Dooks 

Add device nodes for the R8A7790 internal PCI bridge devices.

Signed-off-by: Ben Dooks 
Reviewed-by: Ian Molton 
[Sergei: added several properties to the PCI bridge nodes]
Signed-off-by: Sergei Shtylyov 

---
Changes in version 5:
- added "device_type" and "ranges" properties to the PCI bridge nodes;
- removed "0x" prefix from zero values in the "reg" properties.

Changes in version 4:
- refreshed the patch.

Changes in version 3:
- added interrupt-related properties to the PCI bridge nodes;
- refreshed the patch.

Changes in version 2:
- reworded summary (fixing typo) and changelog;
- removed extra spaces before {;
- refreshed the patch.

 arch/arm/boot/dts/r8a7790.dtsi |   60 +
 1 file changed, 60 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7790.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7790.dtsi
+++ renesas/arch/arm/boot/dts/r8a7790.dtsi
@@ -930,6 +930,66 @@
status = "disabled";
};
 
+   pci0: pci@ee09 {
+   compatible = "renesas,pci-r8a7790";
+   device_type = "pci";
+   clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
+   reg = <0 0xee09 0 0xc00>,
+ <0 0xee08 0 0x1100>;
+   interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+   status = "disabled";
+
+   bus-range = <0 0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   ranges = <0x0200 0 0xee08 0 0xee08 0 0x0001>;
+   interrupt-map-mask = <0xff00 0 0 0x7>;
+   interrupt-map = <0x 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
+0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
+0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+   };
+
+   pci1: pci@ee0b {
+   compatible = "renesas,pci-r8a7790";
+   device_type = "pci";
+   clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
+   reg = <0 0xee0b 0 0xc00>,
+ <0 0xee0a 0 0x1100>;
+   interrupts = <0 112 IRQ_TYPE_LEVEL_HIGH>;
+   status = "disabled";
+
+   bus-range = <1 1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   ranges = <0x0200 0 0xee0a 0 0xee0a 0 0x0001>;
+   interrupt-map-mask = <0xff00 0 0 0x7>;
+   interrupt-map = <0x 0 0 1 &gic 0 112 IRQ_TYPE_LEVEL_HIGH
+0x0800 0 0 1 &gic 0 112 IRQ_TYPE_LEVEL_HIGH
+0x1000 0 0 2 &gic 0 112 IRQ_TYPE_LEVEL_HIGH>;
+   };
+
+   pci2: pci@ee0d {
+   compatible = "renesas,pci-r8a7790";
+   device_type = "pci";
+   clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
+   reg = <0 0xee0d 0 0xc00>,
+ <0 0xee0c 0 0x1100>;
+   interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>;
+   status = "disabled";
+
+   bus-range = <2 2>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   ranges = <0x0200 0 0xee0c 0 0xee0c 0 0x0001>;
+   interrupt-map-mask = <0xff00 0 0 0x7>;
+   interrupt-map = <0x 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
+0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
+0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+   };
+
pciec: pcie@fe00 {
compatible = "renesas,pcie-r8a7790";
reg = <0 0xfe00 0 0x8>;
--
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

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

[Olav Haugan]

On 6/24/2014 2:18 AM, Will Deacon wrote:
> On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
>> On 5/30/2014 12:06 PM, Arnd Bergmann wrote:
>>> On Friday 30 May 2014 08:16:05 Rob Herring wrote:
 Presumably the ID would be the streamID on ARM's SMMU. How would a
 master with 8 streamIDs be described? This is what Calxeda midway has
 for SATA and I would expect that to be somewhat common. Either you
 need some ID masking or you'll have lots of duplication when you have
 windows.
>>>
>>> I don't understand the problem. If you have stream IDs 0 through 7,
>>> you would have
>>>
>>> master@a {
>>> ...
>>> iommus = <&smmu 0>;
>>> };
>>>
>>> master@b {
>>> ...
>>> iommus = <&smmu 1;
>>> };
>>>
>>> ...
>>>
>>> master@12 {
>>> ...
>>> iommus = <&smmu 7;
>>> };
>>>
>>> and you don't need a window at all. Why would you need a mask of
>>> some sort?
>>
>> We have multiple-master SMMUs and each master emits a variable number of
>> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
>> for this) to the StreamIDs due to limited number of StreamID 2 Context
>> Bank entries in the SMMU. If my understanding is correct we would
>> represent this in the DT like this:
>>
>>  iommu {
>>  #address-cells = <2>;
>>  #size-cells = <0>;
>>  };
>>
>>  master@a {
>>  ...
>>  iommus = <&iommu StreamID0 MASK0>,
>>   <&iommu StreamID1 MASK1>,
>>   <&iommu StreamID2 MASK2>;
>>  };
> 
> Stupid question, but why not simply describe the masked IDs? What use does
> the `raw' ID have to Linux?

We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply to the incoming SIDs, right?

We have a bus master that emits 43 unique SIDs. However, we have only 40
SMMU_SMRn registers in the SMMU. So we need to mask out some of the
incoming SID bits so that the 43 SIDs can match one of 40 entries in the
SMR.

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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

[PATCH v5 0/2] Add R8A7790/Lager board PCI USB DT support

[Sergei Shtylyov]

Hello.

   Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-v3.16-rc2-20140623' tag. Here we add PCI USB device tree support
for the R8A7790-based Lager board. As the 'pci-rcar-gen2' driver device tree
support has been merged for 3.16, this patchset can now be merged too...

[1/2] ARM: shmobile: r8a7790: add internal PCI bridge nodes
[2/2] ARM: shmobile: lager: enable internal PCI

WBR, Sergei
--
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

Re: [PATCH v2 0/8] Add Keystone PCIe controller driver

[Murali Karicheri]

On 06/24/2014 12:08 PM, Murali Karicheri wrote:

Pratyush,

On 06/23/2014 12:50 PM, Santosh Shilimkar wrote:




 Original Message 
Subject: Re: [PATCH v2 0/8] Add Keystone PCIe controller driver
On Sat, Jun 21, 2014 at 03:05:30AM +0800, Arnd Bergmann wrote:

On Friday 20 June 2014 13:11:37 Santosh Shilimkar wrote:





Arnd suggestion was to have the version 3.65 code in generic place
since
its IP specific and just in case some other vendor using the same
version
can leverage the code.


Sorry, I do not follow PCIe mailing list these days, doing something else
now. So coming to this topic a bit delayed.


My Apologies for the email format as I mysteriously lost this email and
had to resort to a forwarded email to respond to this.

Let us have the discussion on this thread as I lost the original emails.


Concern here seems toe really those name of the files. I can't think of
any other appropriate name.


We should definitely keep the version in the DT "compatible" strings
wherever we know it. Regarding a better file name, I have no idea.


In my opinion, we do not need any of dw-v3_65 files, as code in these
files will not be usable by other vendors.

Anything which is implemented in application space, will not be same
across all IP users. For example, MSI0_IRQ_ENABLE_SET has been defined
at offset 0x108 in keystone PCIe application space.Other vendor may
not have this register at the same offset. Moreover, other vendors are
not even obliged to implement MSI Enable signals in same way, so
internal bit definition of the register may change.

Therefore code is not reusable if all register offset and bit
definitions are not same across vendors. So, in case of DW driver none
of the code which are accessed using va_app_base should go to common
area.



I think based on the response far on this issue, it is best to keep
the Application specific code as part of Keystone driver and in
future if there is any driver that has similar application register
implemented. we can refactor the code and re-use.

My V3 will revert back to implementation similar to RFC. Also since this
is individual h/w specific, there is no no need for a compatibility as
well. Will use keystone specific compatibility string for this.

Arnd, hope this is fine. Please respond if you still think a
compatibility string is needed.


On a second thought, I think it is better to keep the compatibility
string to differentiate the h/w and do any old h/w specific initialization.

Thanks and regards,

Murali


Murali


Pratyush



Arnd





--
To unsubscribe from this list: send the line "unsubscribe linux-pci" 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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Initial register settings in Device Tree?

[Noralf Tronnes]

Den 23.06.2014 15:38, skrev Arnd Bergmann:

On Sunday 22 June 2014 21:27:52 Noralf Trønnes wrote:

Den 22.06.2014 20:18, skrev Arnd Bergmann:

On Sunday 22 June 2014 19:37:56 Noralf Trønnes wrote:

I see two possibilities:
* add a special marker value to separate the registers, as I do now
* add a flag to indicate a register number. So far I've only seen 8 and
16-bit register number widths: register 20h could thus be written as
1020, 120, 100020 or 10020

Example (skipped state changes from previous example):
<100B1 01 2C 2D
100B2 01 2C 2D
100B3 01 2C 2D 01 2C 2D
100B4 07 C0 A2 02 84
100C1 C5 C2 0A 00
100C3 8A 2A
100C4 8A EE
100C5 0E
10020
10036 C0
1003A 05
100E0 0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10
100E1 0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>

Is this a viable solution?

We normally use high-level descriptions of the timings that the driver
then converts into register-level settings. See
Documentation/devicetree/bindings/video/display-timing.txt and
other files in that directory for how existing drivers handle this.

Arnd


OK, that takes care of the timings. But what about power control, and
gamma registers?

The power registers usually have bitfields that map to voltages, factors
(0.7x, 1x,..) and levels (low,medium,high).

Should all these bitfiels have their own property in DT?
For some controllers this would be 20+ properties.

In some cases, it can make sense to group several values into one
multi-cell property.


Should the properties have the same name as the register and bitfield
from the datasheet?
st7735r,pwctr1-avdd
st7735r,pwctr1-vrhp
st7735r,pwctr1-vrhn
st7735r,pwctr1-mode

Should the value map directly to the bitfield or should a string be used?
st7735r,pwctr1-avdd = <6> /* 5.1v - Power pin for analog circuits */
st7735r,pwctr1-avdd = "5.1"

Or should each register have it's own property?
st7735r,pwctr1 = 

Each user-serviceable property should be abstract and use the normal
units that you'd expect to see in a data sheet: milivolts, nanoseconds,
etc. See if some other display controller already has picked names
for these properties, then use the same. If nobody has done this
before, try to use property names that would also make sense on a
different controller. If we get a couple of these, we can split out
the property parsing code into a separate helper module.

I found this example that uses regulators to specify voltage:
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
- dsi: display serial interface
- avdd-dsi-supply: phandle of a supply that powers the DSI controller

If I should use regulators, I would need to have a controller driver and
a panel driver, so to avoid that I just specify the millivolt/factor 
directly.

This way the DT controller node will contain the panel description.
(I could add a generic panel driver if regulators is the way to go)

This is how the setup could be for a ST7735R controller:

st7735r,avdd-millivolt = <4900> /* 4.9v */
st7735r,vrhp-millivolt = <4600> /* 4.6v */
st7735r,vrhn-millivolt = <4600> /* -4.6 */
st7735r,pwr-mode = <2> /* 0=2x, 1=3x, 2=auto (the datasheet doesn't say 
what this is) */

st7735r,vgh25-millivolt = <2400>
st7735r,vgh-factor = <1> /* 0=2*AVDD+VGH25, 1=3*AVDD, 2=3*AVDD+VGH25 */
st7735r,vgl-millivolt = <1> /* -10v */
/* ap,sap,pwr-freqX have to do with power consumption vs. image quality. */
st7735r,ap-factor = <1> /* Current in source driver op-amp: 0=small, 
1=medium low, 2=medium, 3=medium high, 4=large */
st7735r,sap-factor = <0> /* Current in source driver op-amp: 0=small, 
1=medium low, 2=medium, 3=medium high, 4=large */

/* Booster circuit Step-up cycle in Normal mode/ full colors */
st7735r,pwr-freq1-factor-normal = <1> /* BCLK/{1, 1.5, 2, 4} */
st7735r,pwr-freq2-factor-normal = <1>
st7735r,pwr-freq3-factor-normal = <1>
st7735r,pwr-freq4-factor-normal = <1>
st7735r,vcom-millivolt = <775> /* -0.775v */
st7735r,rotation = <0> /* Display rotation: 0,90,180,270 */
st7735r,gamma-positive = <0f 1a 0f 18 2f 28 20 22 1f 1b 23 37 00 07 02 10>
st7735r,gamma-negative = <0f 1b 0f 17 33 2c 29 2e 30 30 39 3f 00 07 03 10>


For a ILI9325 controller:

ili9325,gamma-ap-factor = <100> /* Gamma driver amplifiers constant 
current ratio: 0=1.00, 1=0.75, 2=0.50 */
ili9325,source-ap-factor = <75> /* Source driver amplifiers constant 
current ratio: 0=1.00, 1=0.75, 2=0.50 */

ili9325,vgh-factor = <4> /* Vci1 x {4,5,6} */
ili9325,vgl-factor = <3> /* -Vci x {3,4,5} */
ili9325,vci1-factor = <100> /* Vci x {1.00 - 0.70} */
ili9325,pwr-freq1-factor = <1> /* Fosc / {1, 2, 4, 8, 16, 32, 64} */
ili9325,pwr-freq2-factor = <4> /* Fosc / {4, 8, 16, 32, 64, 128, 256} */
ili9325,vci-internal /* use internal 2.5V for Vci reference, default is 
Vci pin */

ili9325,vreg1out-factor = <160> /* Vci x {1.60 - 2.00} */
ili9325,vcom-amplitude-factor = <100> /* VREG1OUT x {0.70 - 1.24} */
ili9325,vcomh-factor = <> /* VREG1OUT x {0.685 - 1.000} */
ili9325,rotation = <0>

Re: [PATCH v2 07/10] regulator: Add driver for Maxim 77802 PMIC regulators

[Javier Martinez Canillas]

Hello Mark,

On 06/23/2014 11:47 AM, Mark Brown wrote:
> On Mon, Jun 23, 2014 at 11:28:25AM +0200, Javier Martinez Canillas wrote:
>> On 06/21/2014 10:40 PM, Mark Brown wrote:
> 
>> > That's not really relevant here - I'm asking if the regulators get their
>> > own supplies rather than if anything uses them.
> 
>> Sorry if I keep misunderstanding your question but the regulators in this 
>> PMIC
>> don't have a parent supply/regulator node.
> 
> They should, I'm pretty sure the device does actually regulate one
> supply into another.
> 

Thanks a lot for the clarification. This was not evident to me when I read the
PMIC datasheet and because both the max77xxx Chrome OS 3.8 and mainline max77686
drivers used a simplistic model of the power scheme.

But Doug confirmed to me that some regulators on this PMIC do indeed use others
regulators as a power supply so I'll change this in the next version of the
patch-set.

Best regards,
Javier
--
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

Re: [PATCH v2] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi

[Javier Martinez Canillas]

Hello Doug,

On 06/24/2014 06:28 PM, Doug Anderson wrote:
> Tushar,
> 
> On Mon, Jun 23, 2014 at 11:43 PM, Tushar Behera  wrote:
>> On 06/24/2014 02:19 AM, Doug Anderson wrote:
>>> This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
>>> including:
>>> * The keyboard
>>> * The i2c tunnel
>>> * The tps65090 under the i2c tunnel
>>> * The battery under the i2c tunnel
>>>
>>> To add extra motivation, it should be noted that tps65090 is one of
>>> the things needed to get display-related FETs turned on for pit and
>>> pi.
>>>
>>> Note that this relies on a few outstanding changes:
>>> * Needs (spi: s3c64xx: fix broken "cs_gpios" usage in the driver) and
>>>   (spi: s3c64xx: for DT platofrms always get the chipselect info from
>>>   DT node) to work properly and match the documented bindings.  See
>>>    and
>>>   
>>>
>>> Signed-off-by: Doug Anderson 
>>> Tested-by: Javier Martinez Canillas 
>>
>> Along with the dependency patches on next-20140623, tested keyboard on
>> Peach-Pi board.
>>
>> Tested-by: Tushar Behera 
>>
>> Some comments below.
>>
>>> ---
>>> Changes in v2:
>>> - Now just one patch since mfd patch landed.
>>> - Rebased to ToT linux-next
>>>
>>>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 145 
>>> +
>>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 145 
>>> +
>>>  2 files changed, 290 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
>>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> index 7649982..581f385 100644
>>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>
>>> + regulators {
>>> + dcdc1 {
>>> + ti,enable-ext-control;
>>> + };
>>> + dcdc2 {
>>> + ti,enable-ext-control;
>>> + };
>>> + dcdc3 {
>>> + ti,enable-ext-control;
>>> + };
>>> + fet1 {
>>
>> "tps65090_fet1: fet1 {" ?
>>
>>> + regulator-name = "vcd_led";
>>> + };
>>> + tps65090_fet2: fet2 {
>>
>> I would suggest we add similar labels to fet1, fet3, fet4, fet5 and fet6
>> also. That way it would be easy to reference them in subsequent DT nodes.
>>
>> Same comment for Peach-Pi dts file too.
> 
> OK.  I added it to all the regulators in tps65090.  That'll probably
> be useful for Javier in his max77802 work.
>

Thanks, in fact I did add both tps65090_dcdc1 and tps65090_dcdc2 labels to be
able to use these regulators as supply for some of the max77802 regulators.

Will rebase on top of this.

Best regards,
Javier

> -Doug
> 

--
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

Re: [PATCH v2] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi

[Doug Anderson]

Tushar,

On Mon, Jun 23, 2014 at 11:43 PM, Tushar Behera  wrote:
> On 06/24/2014 02:19 AM, Doug Anderson wrote:
>> This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
>> including:
>> * The keyboard
>> * The i2c tunnel
>> * The tps65090 under the i2c tunnel
>> * The battery under the i2c tunnel
>>
>> To add extra motivation, it should be noted that tps65090 is one of
>> the things needed to get display-related FETs turned on for pit and
>> pi.
>>
>> Note that this relies on a few outstanding changes:
>> * Needs (spi: s3c64xx: fix broken "cs_gpios" usage in the driver) and
>>   (spi: s3c64xx: for DT platofrms always get the chipselect info from
>>   DT node) to work properly and match the documented bindings.  See
>>    and
>>   
>>
>> Signed-off-by: Doug Anderson 
>> Tested-by: Javier Martinez Canillas 
>
> Along with the dependency patches on next-20140623, tested keyboard on
> Peach-Pi board.
>
> Tested-by: Tushar Behera 
>
> Some comments below.
>
>> ---
>> Changes in v2:
>> - Now just one patch since mfd patch landed.
>> - Rebased to ToT linux-next
>>
>>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 145 
>> +
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 145 
>> +
>>  2 files changed, 290 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> index 7649982..581f385 100644
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>
>> + regulators {
>> + dcdc1 {
>> + ti,enable-ext-control;
>> + };
>> + dcdc2 {
>> + ti,enable-ext-control;
>> + };
>> + dcdc3 {
>> + ti,enable-ext-control;
>> + };
>> + fet1 {
>
> "tps65090_fet1: fet1 {" ?
>
>> + regulator-name = "vcd_led";
>> + };
>> + tps65090_fet2: fet2 {
>
> I would suggest we add similar labels to fet1, fet3, fet4, fet5 and fet6
> also. That way it would be easy to reference them in subsequent DT nodes.
>
> Same comment for Peach-Pi dts file too.

OK.  I added it to all the regulators in tps65090.  That'll probably
be useful for Javier in his max77802 work.

-Doug
--
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

[PATCH v3] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi

[Doug Anderson]

This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
including:
* The keyboard
* The i2c tunnel
* The tps65090 under the i2c tunnel
* The battery under the i2c tunnel

To add extra motivation, it should be noted that tps65090 is one of
the things needed to get display-related FETs turned on for pit and
pi.

Note that this relies on a few outstanding changes:
* Needs (spi: s3c64xx: fix broken "cs_gpios" usage in the driver) and
  (spi: s3c64xx: for DT platofrms always get the chipselect info from
  DT node) to work properly and match the documented bindings.  See
   and
  

Signed-off-by: Doug Anderson 
Tested-by: Javier Martinez Canillas 
Tested-by: Tushar Behera 
---
Changes in v3:
- Added aliases for tps65090 regulators as per Tushar.

Changes in v2:
- Now just one patch since mfd patch landed.
- Rebased to ToT linux-next

 arch/arm/boot/dts/exynos5420-peach-pit.dts | 145 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 145 +
 2 files changed, 290 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 7649982..b2f1237 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -25,6 +25,11 @@
"google,pit", "google,peach","samsung,exynos5420",
"samsung,exynos5";
 
+   aliases {
+   /* Assign 20 so we don't get confused w/ builtin ones */
+   i2c20 = "/spi@12d4/cros-ec@0/i2c-tunnel";
+   };
+
backlight {
compatible = "pwm-backlight";
pwms = <&pwm 0 100 0>;
@@ -87,6 +92,13 @@
pinctrl-0 = <&usb301_vbus_en>;
enable-active-high;
};
+
+   vbat: fixed-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat-supply";
+   regulator-boot-on;
+   regulator-always-on;
+   };
 };
 
 &dp {
@@ -231,6 +243,20 @@
samsung,pin-drv = <0>;
};
 
+   ec_irq: ec-irq {
+   samsung,pins = "gpx1-5";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   tps65090_irq: tps65090-irq {
+   samsung,pins = "gpx2-5";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
dp_hpd_gpio: dp_hpd_gpio {
samsung,pins = "gpx2-6";
samsung,pin-function = <0>;
@@ -247,6 +273,19 @@
 };
 
 &pinctrl_3 {
+   /* Drive SPI lines at x2 for better integrity */
+   spi2-bus {
+   samsung,pin-drv = <2>;
+   };
+
+   /* Drive SPI chip select at x2 for better integrity */
+   ec_spi_cs: ec-spi-cs {
+   samsung,pins = "gpb1-2";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <2>;
+   };
+
usb300_vbus_en: usb300-vbus-en {
samsung,pins = "gph0-0";
samsung,pin-function = <1>;
@@ -266,6 +305,111 @@
status = "okay";
 };
 
+&spi_2 {
+   status = "okay";
+   num-cs = <1>;
+   samsung,spi-src-clk = <0>;
+   cs-gpios = <&gpb1 2 0>;
+
+   cros_ec: cros-ec@0 {
+   compatible = "google,cros-ec-spi";
+   interrupt-parent = <&gpx1>;
+   interrupts = <5 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&ec_spi_cs &ec_irq>;
+   reg = <0>;
+   spi-max-frequency = <3125000>;
+
+   controller-data {
+   samsung,spi-feedback-delay = <1>;
+   };
+
+   i2c-tunnel {
+   compatible = "google,cros-ec-i2c-tunnel";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   google,remote-bus = <0>;
+
+   battery: sbs-battery@b {
+   compatible = "sbs,sbs-battery";
+   reg = <0xb>;
+   sbs,poll-retry-count = <1>;
+   sbs,i2c-retry-count = <2>;
+   };
+
+   power-regulator@48 {
+   compatible = "ti,tps65090";
+   reg = <0x48>;
+
+   /*
+* Config irq to disable internal pulls
+* even though we run in polling mode.
+*/
+   pinctrl-names = "default";
+   pinctrl-0 = <&tps65090_irq>;
+
+   vsys1-supply = <&vbat>;
+  

Re: Re: [PATCH v2 0/8] Add Keystone PCIe controller driver

[Murali Karicheri]

Mohit,

On 06/23/2014 12:49 PM, Santosh Shilimkar wrote:




 Original Message 
Subject: Re: [PATCH v2 0/8] Add Keystone PCIe controller driver
Date: Mon, 23 Jun 2014 10:43:46 +0530
From: Pratyush Anand
To: Murali Karicheri

On Sat, Jun 21, 2014 at 05:17:07AM +0800, Murali Karicheri wrote:


Sorry, my previous response was in html and not sure it has made to the
list. I did
get an error as well. So resending my response.

On 6/18/2014 6:14 AM, Mohit KUMAR DCG wrote:

Hello Murali,





[...]


*pos = pos0;

@@ -349,7 +353,10 @@ static int dw_msi_setup_irq(struct msi_chip *chip,
struct pci_dev *pdev,

*/

desc->msi_attrib.multiple = msgvec;

-msg.address_lo = virt_to_phys((void *)pp->msi_data);

+if (pp->ops->get_msi_data)

+msg.address_lo = pp->ops->get_msi_data(pp);

+else

+msg.address_lo = virt_to_phys((void *)pp->msi_data);

msg.address_hi = 0x0;

msg.data = pos;


What about this code? This requires get_msi_data() as well


pp->msi_data is set in dw_pcie_msi_init, which is a global function
called from vendor specific code. You can have your own
keystone_pcie_msi_init and then you do not need above changes.


My Apologies for the email format as I lost the original email and had
to respond using a forwarded email.

If you look at my original patch, keystone driver was not calling
dw_pcie_msi_init(). However the issue is msi_chip of DW core is
re-used as most of the code is platform independent. However
code that sends write_msi_msg() can be re-used on keystone by
adding this get_msi_data() API as the only difference IMO is the
address EP writes to raise an MSI IRQ event. I don't see any
reason why the entire code needs to be duplicated on Keystone.
BTW, currently I have not tested the MSI IRQ and tested my driver
only with Legacy IRQ. I plan to test this before sending my
v3 of the patch.

Murali




-- 3rd to use pp->ops->msi_set/clear if defined.

Why not API enhancement and refactor the code in a single patch?


Yes, can be. You can send changes in 2 or 3 patches as you wish, but I
believe that should be able to solve problem in best way.

Regards
Pratyush


Murali

Pls let us know for any issue or have different opinion.

Regards
Mohit





--
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

Re: [PATCH v3 3/7] irqchip: atmel-aic: add new atmel AIC driver

[Boris BREZILLON]

Hello Jason,

On 24/06/2014 14:56, Jason Cooper wrote:
> Boris,
>
> On Sun, Jun 22, 2014 at 10:56:54PM +0200, Boris BREZILLON wrote:
>> On 20/06/2014 17:01, Boris BREZILLON wrote:
>>> Add new atmel AIC (Advanced Interrupt Controller) driver based on the
>>> generic chip infrastructure.
>>>
>>> This driver is only compatible with dt enabled board and replaces the old
>>> implementation found in arch/arm/mach-at91/irq.c.
>>>
>>> Signed-off-by: Boris BREZILLON 
>>> ---
>>>  drivers/irqchip/Kconfig |   7 +
>>>  drivers/irqchip/Makefile|   1 +
>>>  drivers/irqchip/irq-atmel-aic.c | 700 
>>> 
>>>  3 files changed, 708 insertions(+)
>>>  create mode 100644 drivers/irqchip/irq-atmel-aic.c
>>>
>>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>>> index bbb746e..6a7ad81 100644
>>> --- a/drivers/irqchip/Kconfig
>>> +++ b/drivers/irqchip/Kconfig
>>> @@ -30,6 +30,13 @@ config ARM_VIC_NR
>>>   The maximum number of VICs available in the system, for
>>>   power management.
>>>  
>> [...]
>>
>>> +
>>> +static int at91_aic_common_irq_domain_xlate(struct irq_domain *d,
>> This function should be named aic_common_irq_domain_xslate to be
>> consistent with other function names.
>> I'll fix that for the next version.
> Other than this one change, this series looks good wrt to irqchip.  When
> you respin, please adjust the patch subject lines like so:
>
>   irqchip: atmel-aic: Add new atmel AIC driver
>
> Note the capitalization.  Also, if you could add Thomas' Ack to the
> first patch, that would be appreciated.

Sure, I'll fix the commit message and add Thomas' ack.

>
> Once you post the new series, I assume it's ok to apply patches 1-3 to
> irqchip/core, or are there some dependency considerations?

Patches 6 and 7 depend on the 3 first patches, but we should be able to
merge them through the at91/arm-soc tree (Nicolas might have to rebase
its tree for 3.17 on irqchip/core after you have applied patches 1-3).

Anyway, I'd like to wait for at91 maintainers/developers reviews before
posting a new version.

Thanks for your support on this series.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

--
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

Re: Re: [PATCH v2 0/8] Add Keystone PCIe controller driver

[Murali Karicheri]

Pratyush,

On 06/23/2014 12:50 PM, Santosh Shilimkar wrote:




 Original Message 
Subject: Re: [PATCH v2 0/8] Add Keystone PCIe controller driver
On Sat, Jun 21, 2014 at 03:05:30AM +0800, Arnd Bergmann wrote:

On Friday 20 June 2014 13:11:37 Santosh Shilimkar wrote:





Arnd suggestion was to have the version 3.65 code in generic place since
its IP specific and just in case some other vendor using the same version
can leverage the code.


Sorry, I do not follow PCIe mailing list these days, doing something else
now. So coming to this topic a bit delayed.


My Apologies for the email format as I mysteriously lost this email and
had to resort to a forwarded email to respond to this.

Let us have the discussion on this thread as I lost the original emails.


Concern here seems toe really those name of the files. I can't think of
any other appropriate name.


We should definitely keep the version in the DT "compatible" strings
wherever we know it. Regarding a better file name, I have no idea.


In my opinion, we do not need any of dw-v3_65 files, as code in these
files will not be usable by other vendors.

Anything which is implemented in application space, will not be same
across all IP users. For example, MSI0_IRQ_ENABLE_SET has been defined
at offset 0x108 in keystone PCIe application space.Other vendor may
not have this register at the same offset. Moreover, other vendors are
not even obliged to implement MSI Enable signals in same way, so
internal bit definition of the register may change.

Therefore code is not reusable if all register offset and bit
definitions are not same across vendors. So, in case of DW driver none
of the code which are accessed using va_app_base should go to common
area.



I think based on the response far on this issue, it is best to keep
the Application specific code as part of Keystone driver and in
future if there is any driver that has similar application register
implemented. we can refactor the code and re-use.

My V3 will revert back to implementation similar to RFC. Also since this
is individual h/w specific, there is no no need for a compatibility as
well. Will use keystone specific compatibility string for this.

Arnd, hope this is fine. Please respond if you still think a 
compatibility string is needed.


Murali


Pratyush



Arnd





--
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

Re: randconfig build error with next-20140624, in drivers/mfd/sec-core.c

[Lee Jones]

On Tue, 24 Jun 2014, Arnd Bergmann wrote:

> On Tuesday 24 June 2014 07:39:04 Jim Davis wrote:
> > Building with the attached random configuration file,
> > 
> > drivers/built-in.o: In function `sec_pmic_suspend':
> > sec-core.c:(.text+0x31e02c): undefined reference to 
> > `regulator_suspend_prepare'
> > make: *** [vmlinux] Error 1
> 
> Reported-by: Jim Davis 
> Signed-off-by: Arnd Bergmann 
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 207c433..1caa3c5 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -582,7 +582,7 @@ config MFD_RC5T583
>  
>  config MFD_SEC_CORE
>   bool "SAMSUNG Electronics PMIC Series Support"
> - depends on I2C=y
> + depends on I2C=y && REGULATOR
>   select MFD_CORE
>   select REGMAP_I2C
>   select REGMAP_IRQ

Can you send me something I can `git am` please?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [PATCH 1/2] regulator: max1586 add device-tree support

[Mark Brown]

On Tue, Jun 17, 2014 at 09:16:52PM +0200, Robert Jarzmik wrote:
> Mark Brown  writes:
> > On Sat, Jun 14, 2014 at 04:54:24PM +0200, Robert Jarzmik wrote:

> >> +  matched = of_regulator_match(dev, np, rmatch, ARRAY_SIZE(rmatch));
> >> +  of_node_put(np);
> >> +  if (matched <= 0)
> >> +  return matched;

> > Why is this treating zero as an error?  We should be able to at least
> > report the current state of regulators even if none are configured in
> > the device tree.

> Euh how so an error ?

> If 0 is returned, this means no regulators are found in device-tree. It's not 
> an
> error, it's a lack of regulators (ie. no Output_V3 and no Output_V6), and no
> more handling is necessary in this function, while returning "ok", ie 0 ...

OK, so there's just nothing to do in that case.  That's fine, but it's
just not at all clear from the code.  A comment would help.

> As for the "state report", this max1586 doesn't report anything, it cannot 
> even
> be queried about the current voltage, sic ...

It can't?  That's unfortunate, though I was able to turn up a datasheet
which appears to support that.

> If you want me to modify this bit I need a bit more of an explanation to
> understand.

Where the driver is doing unusual things if they are actually sensible
then the change needs to be clearer about why.


signature.asc
Description: Digital signature

Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree

[Doug Anderson]

Javier,

On Tue, Jun 24, 2014 at 3:06 AM, Javier Martinez Canillas
 wrote:
> Hello Doug,
>
> On 06/24/2014 06:05 AM, Doug Anderson wrote:
> Another option is to identify DTS fragments that are common across boards and
> create .dtsi files for these specific chunks instead of trying to group all 
> set
> of common things on a single .dtsi file.
>
> For example, a quite common design for OMAP2+ based boards is to use a SMSC 
> LAN
> chip connected to OMAP's General-Purpose Memory Controller (GPMC). So the
> following files were created to reduce DTS duplication:
>
> arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
> arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
>
> Now that I think about it, is the same that what you did for
> arm/boot/dts/cros-ec-keyboard.dtsi.
>
> Maybe splitting exynos5250-cros-common.dtsi in a set of .dtsi files will make 
> it
> more flexible/reusable?

Yes, I think the config fragments can be cleaner but I think we have
to be judicious about using them.  There are definitely tradeoffs
involved.  The keyboard was such an excessively large thing and
totally duplicated, so moving it out made sense.  Other bits are less
obvious (to me) because there are so many interactions / combinations
and you end up with a bit of spaghetti in terms of which labels are
used by and provided by each fragment.  I guess possibly you could
codify that better...

A few thoughts looking at exynos5420-peach-pit:

* backlight: seems (?) too board specific
* samsung,exynos5420-oscclk: could totally be a fragment, but very small.
* power key: could be a fragment for all boards that happen to use
gpx1-2 for this
* sound: could be a fragment for all devices using
"google,snow-audio-max98090", possibly.


> Personally I think that "status = [enabled | disabled]" only makes sense for 
> IP
> blocks that are part of the SoC but may or may not be used by a board (e.g: 
> i2c
> and spi buses, sdhci and usb host controllers, etc).
>
> DTS should be a description of the hardware so I agree that having a disabled
> node for a device that is not present in the board is not right.

Right.  We'll take a look again in v2 when cros-common isn't used.  I
think this could go in steps:
1. Don't use cros-common for spring
2. Don't use cros-common for snow (fold stuff in)
3. Introduce some fragments.
--
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

Re: [PATCH v2 1/2] ASoC: cs4265: bindings: sound: Add binding for CS4265 CODEC.

[Mark Brown]

On Mon, Jun 23, 2014 at 05:29:52PM -0500, Paul Handrigan wrote:
> This patch adds binding documentation for the Cirrus Logic CS4265 I2C CODEC.

Applied both, thanks.  I suspect you'll end up needing to split the
S/PDIF mute operation but it doesn't make such a big difference at the
framework level.

> Changes for v2:
> 
> * Change DT reset pin name to "reset-gpios"

As covered in SubmittingPatches things like this should go after the
---.


signature.asc
Description: Digital signature

Re: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree

[Vincent Palatin]

Re-sending ... the text-only encoding was not properly turned on on
the previous one and irritated the mailing lists.


On Mon, Jun 23, 2014 at 9:05 PM, Doug Anderson  wrote:
>
> Andreas,
>
> On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber  wrote:
> > Hi Doug,
> >
> > Am 23.06.2014 21:47, schrieb Doug Anderson:
> >> Thanks for posting!  A first pass on this is below...
> >
> > Thanks a lot for your quick review! My first big .dts patch, and no
> > datasheets for the hardware at hand as a user.
> >
> > A first pass of replies to my defense. ;)
> >
> >> On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber  wrote:
> > [...]
> >>> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
> >>> b/arch/arm/boot/dts/exynos5250-spring.dts
> >>> new file mode 100644
> >>> index 000..e857d44
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> >>> @@ -0,0 +1,556 @@
> >>> +/*
> >>> + * Google Spring board device tree source
> >>> + *
> >>> + * Copyright (c) 2013 Google, Inc
> >>> + * Copyright (c) 2014 SUSE LINUX Products GmbH
> >>> + *
> >>> + * 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 "exynos5250.dtsi"
> >>> +#include "exynos5250-cros-common.dtsi"
> >>
> >> It is possible we may want to backpedal on the use of
> >> "exynos5250-cros-common.dtsi".  I know that Olof (now CCed) said he
> >> wasn't a fan of how it turned out.
> >>
> >> The original idea was that it should include the arbitrary set of
> >> things that are common between a chunk of Chrome OS boards.  As more
> >> boards were introduced things would need to migrate from the "common"
> >> file to the board files.
> >>
> >> At the moment the current conventional wisdom is that some duplication
> >> is better than the confusing movement of everything back and forth.
> >> See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
> >>
> >>
> >>> +/ {
> >>> +   model = "Google Spring";
> >>> +   compatible = "google,spring", "samsung,exynos5250", 
> >>> "samsung,exynos5";
> >>> +
> >>> +   pinctrl@1140 {
> >>
> >> The new best way to do things is to put this down at the bottom.  See
> >> exynos5420-peach-pit as an example:
> >>
> >> &pinctrl_0 {
> >>   ...
> >> }
> >>
> >> Note that I believe it was decided that top-level references like that
> >> should be sorted alphabetically.
> >
> > Thanks for the hint. (My chosen sort order here was by address.)
> >
> >> If you wanted to apply that run to exynos5250-snow I don't think it
> >> would be a terrible idea.
> >
> > I can of course apply changes to Snow, but I cannot test them myself.
>
> If you want to send up a patch like that I'm happy to give it a once
> over and also to test it.  ...but don't feel obligated
>
>
> >>> +   s5m8767_dvs: s5m8767-dvs {
> >>> +   samsung,pins = "gpd1-0", "gpd1-1", "gpd1-2";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <1>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +
> >>> +   s5m8767_ds: s5m8767-ds {
> >>> +   samsung,pins = "gpx2-3", "gpx2-4", "gpx2-5";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <1>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +
> >>> +   tps65090_irq: tps65090-irq {
> >>> +   samsung,pins = "gpx2-6";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <0>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +
> >>> +   s5m8767_irq: s5m8767-irq {
> >>> +   samsung,pins = "gpx3-2";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <0>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +
> >>> +   hdmi_hpd_irq: hdmi-hpd-irq {
> >>> +   samsung,pins = "gpx3-7";
> >>> +   samsung,pin-function = <0>;
> >>> +   samsung,pin-pud = <1>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>> +   };
> >>> +
> >>> +   pinctrl@1340 {
> >>> +   hsic_reset: hsic-reset {
> >>> +   samsung,pins = "gpe1-0";
> >>> +   samsung,pin-function = <1>;
> >>> +   samsung,pin-pud = <0>;
> >>> +   samsung,pin-drv = <0>;
> >>> +   };
> >>
> >> I'm pretty sure that the HSIC reset needed some funky code to make it
> >> work and I'm not sure what the status of that is upstream
> >
> > Yeah, you mentioned something along those lines. How

Re: [PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

[Russell King - ARM Linux]

Denis,

This patch creates binding documentation.  Any patch which does so
should be copied to the DT people so they can review the bindings
and give appropriate acks.  It would be better if you separate the
binding documentation updates from the other functional changes too.

I've added them on this reply to see whether they'll feel friendly
enough to comment on the patch as it stands to avoid having to go
through two more rounds on this already-fourteen revision patch set.

On Mon, Jun 16, 2014 at 12:11:22PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli 
> ---
> ChangeLog v13->v14:
> - None
> 
> ChangeLog v12->v13:
> - Added a note explaining why the size is zero in
>   the eukrea_mbimxsd51_dvi(s)vga structs.
> ChangeLog v11->v12:
> - Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
> 
> ChangeLog v10->v11:
> - New patch.
> ---
>  .../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt   |7 ++
>  .../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt   |7 ++
>  .../bindings/panel/eukrea,mbimxsd51-dvi-vga.txt|7 ++
>  drivers/gpu/drm/panel/panel-simple.c   |   83 
> 
>  4 files changed, 104 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
>  create mode 100644 
> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
>  create mode 100644 
> Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt 
> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
> new file mode 100644
> index 000..03679d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
> @@ -0,0 +1,7 @@
> +Eukrea CMO-QVGA (320x240 pixels) TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "eukrea,mbimxsd51-cmo-qvga"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git 
> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt 
> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
> new file mode 100644
> index 000..f408c9a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
> @@ -0,0 +1,7 @@
> +Eukrea DVI-SVGA (800x600 pixels) DVI output.
> +
> +Required properties:
> +- compatible: should be "eukrea,mbimxsd51-dvi-svga"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git 
> a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt 
> b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
> new file mode 100644
> index 000..8ea90da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
> @@ -0,0 +1,7 @@
> +Eukrea DVI-VGA (640x480 pixels) DVI output.
> +
> +Required properties:
> +- compatible: should be "eukrea,mbimxsd51-dvi-vga"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index a251361..adc40a7 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -403,6 +403,80 @@ static const struct panel_desc edt_etm0700g0dh6 = {
>   },
>  };
>  
> +static const struct drm_display_mode eukrea_mbimxsd51_cmoqvga_mode = {
> + .clock = 6500,
> + .hdisplay = 320,
> + .hsync_start = 320 + 38,
> + .hsync_end = 320 + 38 + 20,
> + .htotal = 320 + 38 + 20 + 30,
> + .vdisplay = 240,
> + .vsync_start = 240 + 15,
> + .vsync_end = 240 + 15 + 4,
> + .vtotal = 240 + 15 + 4 + 3,
> + .vrefresh = 60,
> + .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE |
> +  DRM_MODE_FLAG_POL_DE_LOW,
> +};
> +
> +static const struct panel_desc eukrea_mbimxsd51_cmoqvga = {
> + .modes = &eukrea_mbimxsd51_cmoqvga_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 73,
> + .height = 56,
> + },
> +};
> +
> +static const struct drm_display_mode eukrea_mbimxsd51_dvisvga_mode = {
> + .clock = 44333,
> + .hdisplay = 800,
> + .hsync_start = 800 + 112,
> + .hsync_end = 800 + 112 + 32,
> + .htotal = 800 + 112 + 32 + 80,
> + .vdisplay = 600,
> + .vsync_start = 600 + 3,
> + .vsync_end = 600 + 3 + 17,
> + .vtotal = 600 + 3 + 17 + 4,
> + .vrefresh = 60,
> + .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_POSEDGE |
> +  DRM_MODE_FLAG_POL_DE_HIGH,
> +};
> +
> +static const struct panel_desc eukrea_mbimxsd51_dvisvga = {
> + .modes = &eukrea_mbimxsd51_dvisvga_mode,
> + .num_modes = 1,
> + /* This is a DVI adapter for external displays */
> + .size = {
> + .width = 0,
> 

Re: randconfig build error with next-20140624, in drivers/mfd/sec-core.c

[Arnd Bergmann]

On Tuesday 24 June 2014 07:39:04 Jim Davis wrote:
> Building with the attached random configuration file,
> 
> drivers/built-in.o: In function `sec_pmic_suspend':
> sec-core.c:(.text+0x31e02c): undefined reference to 
> `regulator_suspend_prepare'
> make: *** [vmlinux] Error 1

Reported-by: Jim Davis 
Signed-off-by: Arnd Bergmann 

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 207c433..1caa3c5 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -582,7 +582,7 @@ config MFD_RC5T583
 
 config MFD_SEC_CORE
bool "SAMSUNG Electronics PMIC Series Support"
-   depends on I2C=y
+   depends on I2C=y && REGULATOR
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ

--
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

Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x

[Lee Jones]

On Tue, 24 Jun 2014, Arnd Bergmann wrote:
> On Tuesday 24 June 2014 13:46:34 Lee Jones wrote:
> > > > > > converting all addresses to to resources so drivers can easily pull
> > > > > > them out using platform_get_resource() and friends.  Pushing the reg
> > > > > 
> > > > > right. Can't we use of_address_to_resource here?
> > > > 
> > > > We could, but that would be an extra layer.  We'd be pulling the
> > > > address, putting it into a resource, then pulling it from the resource
> > > > for use.  If we're going to be pulling addresses out manually, we're
> > > > probably better off using of_get_address().  But again, we're just
> > > > carrying out functionality which is already provided by the
> > > > framework.
> > > 
> > > there is also of_ioremap().
> > 
> > Isn't this SPARK only?  And doesn't it require a populated resource?  
> > Which is what I'm saying is the issue here i.e. we don't have one.
> 
> Sorry, I meant of_iomap(). I think it's only for historic reaons
> that we have both. Probably of_iomap started out on powerpc with
> the same intention as the sparc of_ioremap.
> 
> of_iomap does not require a resource, just an index.

Ah, this sounds like a better solution.  I'll have a play, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

[PATCH v4 5/6] ARM: dts: imx25: mbimxsd25: Add touchscreen support.

[Denis Carikli]

Signed-off-by: Denis Carikli 
---
Changelog v3->v4:
- None

Changelog v2->v3:
- Most of the non-board specific tsc and tscadc
  parts were moved to imx25.dtsi. So this patch
  was adapted to that.
- Thanks to a fix in the tsc driver, the 
  'fsl,pen-debounce = <100>;' is not necessary anymore.
---
 .../imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts  |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts 
b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
index 68d0834..2f3bc3f 100644
--- a/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
+++ b/arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
@@ -71,3 +71,11 @@
lcd-supply = <®_lcd_3v3>;
status = "okay";
 };
+
+&tsc {
+   status = "okay";
+};
+
+&tscadc {
+   status = "okay";
+};
-- 
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

[PATCH v4 1/6] mfd: fsl imx25 Touchscreen ADC driver

[Denis Carikli]

From: Markus Pargmann 

This is the core driver for imx25 touchscreen/adc driver. The module
has one shared ADC and two different conversion queues which use the
ADC. The two queues are identical. Both can be used for general purpose
ADC but one is meant to be used for touchscreens.

This driver is the core which manages the central components and
registers of the TSC/ADC unit. It manages the IRQs and forwards them to
the correct components.

Signed-off-by: Markus Pargmann 
Signed-off-by: Denis Carikli 
Acked-by: Jonathan Cameron 
---
Changelog v3->v4:
- Added Jonathan's Ack
- ARCH_MXC Kconfigdependency removed.
- mx25_tsadc_get_regmap and mx25_tsadc_get_ipg contents have been moved
  in the caller function.
- mx25_tsadc_irq_chip has been removed.
- Register definitions are now more humain readable.
- Many other code and style cleanups.

Changelog v2->v3:
- None
---
 .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt|   46 ++
 drivers/mfd/Kconfig|8 +
 drivers/mfd/Makefile   |2 +
 drivers/mfd/fsl-imx25-tsadc.c  |  170 
 include/linux/mfd/imx25-tsadc.h|  140 
 5 files changed, 366 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
 create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
 create mode 100644 include/linux/mfd/imx25-tsadc.h

diff --git a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt 
b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
new file mode 100644
index 000..a857af0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
@@ -0,0 +1,46 @@
+Freescale mx25 ADC/TSC multifunction device
+
+This device combines two general purpose conversion queues one used for general
+ADC and the other used for touchscreens.
+
+Required properties:
+ - compatible: Should be "fsl,imx25-tsadc".
+ - reg: Memory range of the device.
+ - interrupts: Interrupt for this device as described in
+   interrupts/interrupts.txt
+ - clocks: An 'ipg' clock defined as described in clocks/clock.txt
+ - interrupt-controller: This device is an interrupt controller. It controls
+   the interrupts of both conversion queues.
+ - #interrupt-cells: Should be '<1>'.
+ - #address-cells: Should be '<1>'.
+ - #size-cells: Should be '<1>'.
+ - ranges
+
+This device includes two conversion queues which can be added as subnodes.
+The first queue is for the touchscreen, the second for general purpose ADC.
+
+Example:
+   tscadc: tscadc@5003 {
+   compatible = "fsl,imx25-tsadc";
+   reg = <0x5003 0xc>;
+   interrupts = <46>;
+   clocks = <&clks 119>;
+   clock-names = "ipg";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   tsc: tcq@50030400 {
+   compatible = "fsl,imx25-tcq";
+   reg = <0x50030400 0x60>;
+   ...
+   };
+
+   adc: gcq@50030800 {
+   compatible = "fsl,imx25-gcq";
+   reg = <0x50030800 0x60>;
+   ...
+   };
+   };
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index af0e83f..d354547 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -183,6 +183,14 @@ config MFD_DA9063
  Additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_MX25_TSADC
+   tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
+   select REGMAP_MMIO
+   help
+ Enable support for the integrated Touchscreen and ADC unit of the
+ i.MX25 processors. They consist of a conversion queue for general
+ purpose ADC and a queue for Touchscreens.
+
 config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4e2bc25..34388c4 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -78,6 +78,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
 obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
 obj-$(CONFIG_TWL6040_CORE) += twl6040.o
 
+obj-$(CONFIG_MFD_MX25_TSADC)   += fsl-imx25-tsadc.o
+
 obj-$(CONFIG_MFD_MC13XXX)  += mc13xxx-core.o
 obj-$(CONFIG_MFD_MC13XXX_SPI)  += mc13xxx-spi.o
 obj-$(CONFIG_MFD_MC13XXX_I2C)  += mc13xxx-i2c.o
diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
new file mode 100644
index 000..cebc291
--- /dev/null
+++ b/drivers/mfd/fsl-imx25-tsadc.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following location

[PATCH v4 4/6] ARM: dts: imx25: Add TSC and ADC support

[Denis Carikli]

Signed-off-by: Denis Carikli 
---
Changelog v3->v4:
- None

Changelog v2->v3:
- Added ADC controller support: making a separate patch
  for it would have been overkill.
- Moved the common TSC and ADC sub-nodes inside this patch
  instead of having a copy in each dts using it.
---
 arch/arm/boot/dts/imx25.dtsi |   30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index c174039..358c78a 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -264,13 +264,37 @@
status = "disabled";
};
 
-   tsc: tsc@5003 {
-   compatible = "fsl,imx25-adc", "fsl,imx21-tsc";
-   reg = <0x5003 0x4000>;
+   tscadc: tscadc@5003 {
+   compatible = "fsl,imx25-tsadc";
+   reg = <0x5003 0xc>;
interrupts = <46>;
clocks = <&clks 119>;
clock-names = "ipg";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
status = "disabled";
+
+   adc: adc@50030800 {
+   compatible = "fsl,imx25-gcq";
+   reg = <0x50030800 0x60>;
+   interrupt-parent = <&tscadc>;
+   interrupts = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   tsc: tcq@50030400 {
+   compatible = "fsl,imx25-tcq";
+   reg = <0x50030400 0x60>;
+   interrupt-parent = <&tscadc>;
+   interrupts = <0>;
+   fsl,wires = <4>;
+   status = "disabled";
+   };
};
 
ssi1: ssi@50034000 {
-- 
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

[PATCH v4 3/6] iio: adc: fsl,imx25-gcq driver

[Denis Carikli]

From: Markus Pargmann 

This is a conversion queue driver for the mx25 SoC. It uses the central
ADC which is used by two seperate independent queues. This driver
prepares different conversion configurations for each possible input.
For a conversion it creates a conversionqueue of one item with the
correct configuration for the chosen channel. It then executes the queue
once and disables the conversion queue afterwards.

The reference voltages are configurable through devicetree subnodes,
depending on the connections of the ADC inputs.

Signed-off-by: Markus Pargmann 
Signed-off-by: Denis Carikli 
---
Changelog v3->v4:
- Reworked the ADC reference voltage bindings.
- IIO_CHAN_INFO_SCALE is now handled.
- Lot of code and style cleanups.
- Tested by watching WIPER become 0 when the touchscreen is touched.

Changelog v2->v3:
- Fixed compilation: I forgott to tell that this IIO patch was untested
  in the previous cover letter. Now it is tested at runtime:
  I left the touchscreen connected but I configured the TSC as an ADC
  instead, set the refp to internal reference, and the refn to ngnd_adc(3)
  for the first 4 channels(xp,yp,xn,yn) and observed the values changing
  while touching the resistive 4-wire touchscreen.
- MX25_IIO_CHAN now became MX25_GCQ_CHAN and its .address is now gone
  and the code using it adapted.
- The instances of struct iio_dev were renamed from idev to indio_dev.
- regmap_read return value is now checked in mx25_gcq_read_raw.
- Comparisons with MX25_NUM_CFGS are now fixed
- Cosmetics fix in a multiline comment.
---
 .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt  |   51 +++
 drivers/iio/adc/Kconfig|7 +
 drivers/iio/adc/Makefile   |1 +
 drivers/iio/adc/fsl-imx25-gcq.c|  371 
 include/dt-bindings/iio/adc/fsl-imx25-gcq.h|   11 +
 5 files changed, 441 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
 create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
 create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h

diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt 
b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
new file mode 100644
index 000..e4a7170
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
@@ -0,0 +1,51 @@
+Freescale i.MX25 ADC GCQ device
+
+This is a generic conversion queue device that can convert any of the
+analog inputs using the ADC unit of the i.MX25.
+
+Required properties:
+ - compatible: Should be "fsl,imx25-gcq".
+ - reg: Should be the register range of the module.
+ - interrupts: Should be the interrupt number of the module.
+   Typically this is <1>.
+ - interrupt-parent: phandle to the tsadc module of the i.MX25.
+ - #address-cells: Should be <1> (setting for the subnodes)
+ - #size-cells: Should be <0> (setting for the subnodes)
+
+Optional properties:
+ - vref-supply: The regulator supplying the ADC refrence voltage.
+   Required when at least one subnode uses the external reference.
+
+Sub-nodes:
+Optionally you can define subnodes which define the reference voltage
+for the analog inputs.
+
+Required properties for subnodes:
+ - reg: Should be the number of the analog input.
+ 0: xp
+ 1: yp
+ 2: xn
+ 3: yn
+ 4: wiper
+ 5: inaux0
+ 6: inaux1
+ 7: inaux2
+ - fsl,adc-ref: specifies the reference input as defined in
+ 
+ MX25_ADC_REF_INT and MX25_ADC_REF_EXT flags are supported.
+
+Example:
+
+   adc: adc@50030800 {
+   compatible = "fsl,imx25-gcq";
+   reg = <0x50030800 0x60>;
+   interrupt-parent = <&tscadc>;
+   interrupts = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   inaux@5 {
+   reg = <5>;
+   fsl,adc-ref = ;
+   };
+   };
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a80d236..58efb8d 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -125,6 +125,13 @@ config EXYNOS_ADC
  of SoCs for drivers such as the touchscreen and hwmon to use to share
  this resource.
 
+config FSL_MX25_ADC
+   tristate "Freescale MX25 ADC driver"
+   depends on MFD_MX25_TSADC
+   help
+ Generic Conversion Queue driver used for general purpose ADC in the
+ MX25. This driver supports single measurements using the MX25 ADC.
+
 config LP8788_ADC
tristate "LP8788 ADC driver"
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9d60f2d..2767fd6 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
 obj-$(CONFIG_AD799X) += ad799x.o
 obj-$(CONFIG_AT91_ADC) += at91_adc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
+obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
 obj-$(CONFI

[PATCH v4 2/6] input: touchscreen: imx25 tcq driver

[Denis Carikli]

From: Markus Pargmann 

This is a driver for the imx25 ADC/TSC module. It controls the
touchscreen conversion queue and creates a touchscreen input device.
The driver currently only supports 4 wire touchscreens. The driver uses
a simple conversion queue of precharge, touch detection, X measurement,
Y measurement, precharge and another touch detection.

This driver uses the regmap from the parent to setup some touch specific
settings in the core driver and setup a idle configuration with touch
detection.

Signed-off-by: Markus Pargmann 
Signed-off-by: Denis Carikli 
---
Changelog v3->v4:
- Reworked the probe to handle the IRQ and the clock removal order correctly.
- Some code and style cleanups.

Changelog v2->v3:
- Fixed the 'Senitel' typo.
- Fixed input_report_key to report 1 for BTN_TOUCH events.
- Removed useless explicit casts.
- Also disable clock when devm_request_threaded_irq failed.
---
 .../bindings/input/touchscreen/fsl-mx25-tcq.txt|   29 +
 drivers/input/touchscreen/Kconfig  |6 +
 drivers/input/touchscreen/Makefile |1 +
 drivers/input/touchscreen/fsl-imx25-tcq.c  |  584 
 4 files changed, 620 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
 create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt 
b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
new file mode 100644
index 000..4214a99
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
@@ -0,0 +1,29 @@
+Freescale mx25 TS conversion queue module
+
+mx25 touchscreen conversion queue module which controls the ADC unit of the
+mx25 for attached touchscreens.
+
+Required properties:
+ - compatible: Should be "fsl,imx25-tcq".
+ - reg: Memory range of the device.
+ - interrupts: Should be the interrupt number associated with this module 
within
+   the tscadc unit (<0>).
+ - interrupt-parent: Should be a phandle to the tscadc unit.
+ - fsl,wires: Should be '<4>' or '<5>'
+
+Optional properties:
+ - fsl,pen-debounce: Pen debounce time.
+ - fsl,pen-threshold: Pen-down threshold for the touchscreen.
+ - fsl,settling-time: Settling time in nanoseconds.
+
+This device includes two conversion queues which can be added as subnodes.
+The first queue is for the touchscreen, the second for general purpose ADC.
+
+Example:
+   tsc: tcq@50030400 {
+   compatible = "fsl,imx25-tcq";
+   reg = <0x50030400 0x60>;
+   interrupt-parent = <&tscadc>;
+   interrupts = <0>;
+   fsl,wires = <4>;
+   };
diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index a23a94b..a2290b9 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -699,6 +699,12 @@ config TOUCHSCREEN_USB_COMPOSITE
  To compile this driver as a module, choose M here: the
  module will be called usbtouchscreen.
 
+config TOUCHSCREEN_MX25
+   tristate "Freescale i.MX25 touchscreen input driver"
+   depends on MFD_MX25_TSADC
+   help
+ Enable support for touchscreen connected to your i.MX25.
+
 config TOUCHSCREEN_MC13783
tristate "Freescale MC13783 touchscreen input driver"
depends on MFD_MC13XXX
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 126479d..537d591 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_TOUCHSCREEN_INEXIO)  += inexio.o
 obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)+= intel-mid-touch.o
 obj-$(CONFIG_TOUCHSCREEN_LPC32XX)  += lpc32xx_ts.o
 obj-$(CONFIG_TOUCHSCREEN_MAX11801) += max11801_ts.o
+obj-$(CONFIG_TOUCHSCREEN_MX25) += fsl-imx25-tcq.o
 obj-$(CONFIG_TOUCHSCREEN_MC13783)  += mc13783_ts.o
 obj-$(CONFIG_TOUCHSCREEN_MCS5000)  += mcs5000_ts.o
 obj-$(CONFIG_TOUCHSCREEN_MIGOR)+= migor_ts.o
diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c 
b/drivers/input/touchscreen/fsl-imx25-tcq.c
new file mode 100644
index 000..5ebeff8
--- /dev/null
+++ b/drivers/input/touchscreen/fsl-imx25-tcq.c
@@ -0,0 +1,584 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix 
+ * Based on driver from 2011:
+ *   Juergen Beisert, Pengutronix 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * This is the driver for the imx25 TCQ (Touchscreen Conversion Queue)
+ * connected to the imx25 ADC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const char mx25_tcq_name[] = "mx25-tcq";
+
+enum mx25_tcq_mode {

[PATCH v4 6/6] ARM: imx_v4_v5_defconfig: Add I.MX25 Touchscreen controller and ADC support.

[Denis Carikli]

Signed-off-by: Denis Carikli 
---
Changelog v3->v4:
- None

Changelog v2->v3:
- Added ADC support, splitting it would be overkill.
---
 arch/arm/configs/imx_v4_v5_defconfig |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/imx_v4_v5_defconfig 
b/arch/arm/configs/imx_v4_v5_defconfig
index 68abce9..43dd6e9 100644
--- a/arch/arm/configs/imx_v4_v5_defconfig
+++ b/arch/arm/configs/imx_v4_v5_defconfig
@@ -97,6 +97,7 @@ CONFIG_KEYBOARD_IMX=y
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ADS7846=m
+CONFIG_TOUCHSCREEN_MX25=y
 CONFIG_TOUCHSCREEN_MC13783=y
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=m
@@ -117,6 +118,7 @@ CONFIG_HWMON=m
 CONFIG_SENSORS_MC13783_ADC=m
 CONFIG_WATCHDOG=y
 CONFIG_IMX2_WDT=y
+CONFIG_MFD_MX25_TSADC=y
 CONFIG_MFD_MC13XXX_SPI=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
@@ -183,6 +185,8 @@ CONFIG_DMADEVICES=y
 CONFIG_IMX_SDMA=y
 CONFIG_IMX_DMA=y
 # CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_FSL_MX25_ADC=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 CONFIG_EXT4_FS=y
-- 
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

[PATCH v4 1/6] mfd: fsl imx25 Touchscreen ADC driver

[Denis Carikli]

From: Markus Pargmann 

This is the core driver for imx25 touchscreen/adc driver. The module
has one shared ADC and two different conversion queues which use the
ADC. The two queues are identical. Both can be used for general purpose
ADC but one is meant to be used for touchscreens.

This driver is the core which manages the central components and
registers of the TSC/ADC unit. It manages the IRQs and forwards them to
the correct components.

Signed-off-by: Markus Pargmann 
Signed-off-by: Denis Carikli 
Acked-by: Jonathan Cameron 
---
Changelog v3->v4:
- Added Jonathan's Ack
- ARCH_MXC Kconfigdependency removed.
- mx25_tsadc_get_regmap and mx25_tsadc_get_ipg contents have been moved
  in the caller function.
- mx25_tsadc_irq_chip has been removed.
- Register definitions are now more humain readable.
- Many other code and style cleanups.

Changelog v2->v3:
- None
---
 .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt|   46 ++
 drivers/mfd/Kconfig|8 +
 drivers/mfd/Makefile   |2 +
 drivers/mfd/fsl-imx25-tsadc.c  |  170 
 include/linux/mfd/imx25-tsadc.h|  140 
 5 files changed, 366 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
 create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
 create mode 100644 include/linux/mfd/imx25-tsadc.h

diff --git a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt 
b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
new file mode 100644
index 000..a857af0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
@@ -0,0 +1,46 @@
+Freescale mx25 ADC/TSC multifunction device
+
+This device combines two general purpose conversion queues one used for general
+ADC and the other used for touchscreens.
+
+Required properties:
+ - compatible: Should be "fsl,imx25-tsadc".
+ - reg: Memory range of the device.
+ - interrupts: Interrupt for this device as described in
+   interrupts/interrupts.txt
+ - clocks: An 'ipg' clock defined as described in clocks/clock.txt
+ - interrupt-controller: This device is an interrupt controller. It controls
+   the interrupts of both conversion queues.
+ - #interrupt-cells: Should be '<1>'.
+ - #address-cells: Should be '<1>'.
+ - #size-cells: Should be '<1>'.
+ - ranges
+
+This device includes two conversion queues which can be added as subnodes.
+The first queue is for the touchscreen, the second for general purpose ADC.
+
+Example:
+   tscadc: tscadc@5003 {
+   compatible = "fsl,imx25-tsadc";
+   reg = <0x5003 0xc>;
+   interrupts = <46>;
+   clocks = <&clks 119>;
+   clock-names = "ipg";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   tsc: tcq@50030400 {
+   compatible = "fsl,imx25-tcq";
+   reg = <0x50030400 0x60>;
+   ...
+   };
+
+   adc: gcq@50030800 {
+   compatible = "fsl,imx25-gcq";
+   reg = <0x50030800 0x60>;
+   ...
+   };
+   };
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index af0e83f..d354547 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -183,6 +183,14 @@ config MFD_DA9063
  Additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_MX25_TSADC
+   tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
+   select REGMAP_MMIO
+   help
+ Enable support for the integrated Touchscreen and ADC unit of the
+ i.MX25 processors. They consist of a conversion queue for general
+ purpose ADC and a queue for Touchscreens.
+
 config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4e2bc25..34388c4 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -78,6 +78,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
 obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
 obj-$(CONFIG_TWL6040_CORE) += twl6040.o
 
+obj-$(CONFIG_MFD_MX25_TSADC)   += fsl-imx25-tsadc.o
+
 obj-$(CONFIG_MFD_MC13XXX)  += mc13xxx-core.o
 obj-$(CONFIG_MFD_MC13XXX_SPI)  += mc13xxx-spi.o
 obj-$(CONFIG_MFD_MC13XXX_I2C)  += mc13xxx-i2c.o
diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
new file mode 100644
index 000..cebc291
--- /dev/null
+++ b/drivers/mfd/fsl-imx25-tsadc.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following location

Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x

[Arnd Bergmann]

On Tuesday 24 June 2014 13:46:34 Lee Jones wrote:
> > > > > converting all addresses to to resources so drivers can easily pull
> > > > > them out using platform_get_resource() and friends.  Pushing the reg
> > > > 
> > > > right. Can't we use of_address_to_resource here?
> > > 
> > > We could, but that would be an extra layer.  We'd be pulling the
> > > address, putting it into a resource, then pulling it from the resource
> > > for use.  If we're going to be pulling addresses out manually, we're
> > > probably better off using of_get_address().  But again, we're just
> > > carrying out functionality which is already provided by the
> > > framework.
> > 
> > there is also of_ioremap().
> 
> Isn't this SPARK only?  And doesn't it require a populated resource?  
> Which is what I'm saying is the issue here i.e. we don't have one.

Sorry, I meant of_iomap(). I think it's only for historic reaons
that we have both. Probably of_iomap started out on powerpc with
the same intention as the sparc of_ioremap.

of_iomap does not require a resource, just an index.

Arnd
--
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

Re: [PATCH 2/6] OF: Add [__]of_find_node_by_full_name

[Grant Likely]

On Mon, 23 Jun 2014 21:00:39 +0300, Pantelis Antoniou 
 wrote:
> Hi Guenter,
> 
> On Jun 23, 2014, at 8:58 PM, Guenter Roeck wrote:
> 
> > On 06/22/2014 02:40 AM, Pantelis Antoniou wrote:
> >> __of_find_node_by_full_name recursively searches for a matching node
> >> with the given full name without taking any locks.
> >> 
> >> of_find_node_by_full_name takes locks and takes a reference on the
> >> matching node.
> >> 
> >> Signed-off-by: Pantelis Antoniou 
> >> ---
> >>  drivers/of/base.c  | 58 
> >> ++
> >>  include/linux/of.h |  4 
> >>  2 files changed, 62 insertions(+)
> >> 
> >> diff --git a/drivers/of/base.c b/drivers/of/base.c
> >> index d3493e1..80fef33 100644
> >> --- a/drivers/of/base.c
> >> +++ b/drivers/of/base.c
> >> @@ -1201,6 +1201,64 @@ static void *of_find_property_value_of_size(const 
> >> struct device_node *np,
> >>  }
> >> 
> >>  /**
> >> + * __of_find_node_by_full_name - Find a node with the full name 
> >> recursively
> >> + * @node: Root of the tree to perform the search
> >> + * @full_name:Full name of the node to find.
> >> + *
> >> + * Find a node with the give full name by recursively following any of
> >> + * the child node links.
> >> + * Returns the matching node, or NULL if not found.
> >> + * Note that the devtree lock is not taken, so this function is only
> >> + * safe to call on either detached trees, or when devtree lock is already
> >> + * taken.
> >> + */
> >> +struct device_node *__of_find_node_by_full_name(struct device_node *node,
> >> +  const char *full_name)
> >> +{
> >> +  struct device_node *child, *found;
> >> +
> >> +  if (node == NULL)
> >> +  return NULL;
> >> +
> >> +  /* check */
> >> +  if (of_node_cmp(node->full_name, full_name) == 0)
> >> +  return node;
> >> +
> >> +  __for_each_child_of_node(node, child) {
> >> +  found = __of_find_node_by_full_name(child, full_name);
> >> +  if (found != NULL)
> >> +  return found;
> >> +  }
> >> +
> >> +  return NULL;
> >> +}
> >> +EXPORT_SYMBOL(__of_find_node_by_full_name);
> >> +
> >> +/**
> >> + * of_find_node_by_full_name - Find a node with the full name recursively
> >> + * @node: Root of the tree to perform the search
> >> + * @full_name:Full name of the node to find.
> >> + *
> >> + * Find a node with the give full name by recursively following any of
> >> + * the child node links.
> >> + * Returns the matching node (with a ref taken), or NULL if not found.
> >> + */
> >> +struct device_node *of_find_node_by_full_name(struct device_node *node,
> >> +  const char *full_name)
> >> +{
> >> +  unsigned long flags;
> >> +  struct device_node *np;
> >> +
> >> +  raw_spin_lock_irqsave(&devtree_lock, flags);
> >> +  np = of_find_node_by_full_name(node, full_name);
> > 
> > Should this be __of_find_node_by_full_name, or am I missing something ?
> > 
> 
> Ugh, you're not missing something. This slipped through since this is not 
> used in the current code

Then perhaps the function shouldn't exist at all.

g.

--
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

Re: [PATCH 3/4] ARM: DTS: use new compatible string as per the documentation

[Naveen Krishna Ch]

Hello Mark,

On 24 June 2014 19:03, Mark Rutland  wrote:
> On Tue, Jun 24, 2014 at 01:19:15PM +0100, Naveen Krishna Chatradhi wrote:
>> As Murata is the Manufactures the NTC thermistors. The vendor
>> name in the compatibility is preposed to change to "murata, ncpXXX"
>>
>> This patch uses the new compatibility string in exynos4412 based
>> Trats2 board.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: Chanwoo Choi 
>> ---
>> 1. Updates the thermistor node in Exynos4412 based Trats2 dts
>>using the new DT bindings for NTC thermistors updated with vendor-prefix
>>
>>  arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
>> b/arch/arm/boot/dts/exynos4412-trats2.dts
>> index 11967f4..d35755a 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -771,7 +771,7 @@
>>   };
>>
>>   thermistor-ap@0 {
>> - compatible = "ntc,ncp15wb473";
>> + compatible = "murata,ncp15wb473";
>
> So the previous patch woul have broken this board?

Will keep the deprecated binding. But, still change here.
As, this is the only board currently using the NTC thermistors.

>
> Mark.
>
>>   pullup-uv = <180>;   /* VCC_1.8V_AP */
>>   pullup-ohm = <10>;   /* 100K */
>>   pulldown-ohm = <10>; /* 100K */
>> @@ -779,7 +779,7 @@
>>   };
>>
>>   thermistor-battery@1 {
>> - compatible = "ntc,ncp15wb473";
>> + compatible = "murata,ncp15wb473";
>>   pullup-uv = <180>;   /* VCC_1.8V_AP */
>>   pullup-ohm = <10>;   /* 100K */
>>   pulldown-ohm = <10>; /* 100K */
>> --
>> 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
>>



-- 
Shine bright,
(: Nav :)
--
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

Re: [PATCH 2/4] hwmon: ntc_thermistor: Use the manufacturer name properly

[Naveen Krishna Ch]

Hello Mark,

On 24 June 2014 19:02, Mark Rutland  wrote:
> On Tue, Jun 24, 2014 at 01:19:14PM +0100, Naveen Krishna Chatradhi wrote:
>> Murata Manufacturing Co., Ltd is the vendor for
>> NTC (Negative Temperature coefficient) based Thermistors.
>> But, the driver extensively uses "NTC" as the vendor name.
>>
>> This patch corrects the vendor name also updates the
>> compatibility strings according to the vendor-prefix.txt
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: Guenter Roeck 
>> ---
>> This changes is needed for the following reasons
>>
>> 1. The vendor prefix "ntc" is not defined in vendor-prefixes.txt
>>Thus, giving an error when checked with scripts/checkpatch.pl
>> 2. Murata Manufacturing Co., Ltd. Is the vendor for the
>>NTC (Negative Temperature Coefficient) based thermistors.
>>Hence, "murata" is the right vendor-prefix, Not "ntc".
>> 3. NTC is a technology used, But the prefix "ntc" is wrongly
>>and heavily used in the driver and the documentation.
>>
>>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
>>  .../devicetree/bindings/hwmon/ntc_thermistor.txt   |   12 ++--
>>  Documentation/hwmon/ntc_thermistor |8 
>>  drivers/hwmon/Kconfig  |5 +++--
>>  drivers/hwmon/ntc_thermistor.c |   12 ++--
>>  5 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
>> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> index 5d49f2b..832fe8c 100644
>> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>> @@ -48,7 +48,7 @@ adc@12D1 {
>>
>>   /* NTC thermistor is a hwmon device */
>>   ncp15wb473@0 {
>> - compatible = "ntc,ncp15wb473";
>> + compatible = "murata,ncp15wb473";
>>   pullup-uv = <180>;
>>   pullup-ohm = <47000>;
>>   pulldown-ohm = <0>;
>> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
>> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> index c6f6667..4e9f344 100644
>> --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
>> @@ -3,11 +3,11 @@ NTC Thermistor hwmon sensors
>>
>>  Requires node properties:
>>  - "compatible" value : one of
>> - "ntc,ncp15wb473"
>> - "ntc,ncp18wb473"
>> - "ntc,ncp21wb473"
>> - "ntc,ncp03wb473"
>> - "ntc,ncp15wl333"
>> + "murata,ncp15wb473"
>> + "murata,ncp18wb473"
>> + "murata,ncp21wb473"
>> + "murata,ncp03wb473"
>> + "murata,ncp15wl333"
>
> So we're outright changing these rather than deprecating the existing
> forms?
>
> In general we've pushed back on changes like this, and requested that
> the old strings are kept in both documentation and code as deprecated
> forms.

Should have kept the old bindings as deprecated.

>
> Can you guarantee that changing this is not going to stop someone's
> board worknig properly? I suspect not.

As a result of this change, Exynos4412-Trats2 board is broken.
Will re-spin with the deprecated binding.

>
> Mark.
>
>>  - "pullup-uv"Pull up voltage in micro volts
>>  - "pullup-ohm"   Pull up resistor value in ohms
>>  - "pulldown-ohm" Pull down resistor value in ohms
>> @@ -21,7 +21,7 @@ Read more about iio bindings at
>>
>>  Example:
>>   ncp15wb473@0 {
>> - compatible = "ntc,ncp15wb473";
>> + compatible = "murata,ncp15wb473";
>>   pullup-uv = <180>;
>>   pullup-ohm = <47000>;
>>   pulldown-ohm = <0>;
>> diff --git a/Documentation/hwmon/ntc_thermistor 
>> b/Documentation/hwmon/ntc_thermistor
>> index 3bfda94..057b770 100644
>> --- a/Documentation/hwmon/ntc_thermistor
>> +++ b/Documentation/hwmon/ntc_thermistor
>> @@ -1,7 +1,7 @@
>>  Kernel driver ntc_thermistor
>>  =
>>
>> -Supported thermistors:
>> +Supported thermistors from Murata:
>>  * Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, 
>> NCP15WL333
>>Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', 
>> 'ncp15wl333'
>>Datasheet: Publicly available at Murata
>> @@ -15,9 +15,9 @@ Authors:
>>  Description
>>  ---
>>
>> -The NTC thermistor is a simple thermistor that requires users to provide the
>> -resistance and lookup the corresponding compensation table to get the
>> -temperature input.
>> +The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
>> +that requires users to provide the resistance and lookup the corresponding
>> +compensation table to get the temperature input.
>>
>>  The NTC driver provides lookup tables with a linear approximation function
>>  and four circuit models with an option not to use any of the four models.
>> diff --git a/drivers/hwmon/Kconfig b/drive

Re: [PATCH 1/4] devicetree: bindings: Document murata vendor prefix

[Naveen Krishna Ch]

Hello Mark,

On 24 June 2014 19:00, Mark Rutland  wrote:
> On Tue, Jun 24, 2014 at 01:19:13PM +0100, Naveen Krishna Chatradhi wrote:
>> Add Murata Manufacturing Co., Ltd. to the list of device tree
>> vendor prefixes.
>>
>> Murata manufactures NTC (Negative Temperature Coefficient) based
>> Thermistors for small scale applications like Mobiles and PDAs.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: Guenter Roeck 
>> ---
>> This changes is needed for the following reasons
>>
>> 1. The vendor prefix "ntc" is not defined in vendor-prefixes.txt
>>Thus, giving an error when checked with scripts/checkpatch.pl
>> 2. Murata Manufacturing Co., Ltd. Is the vendor for the
>>NTC (Negative Temperature Coefficient) based thermistors.
>>Hence, "murata" is the right vendor-prefix, Not "ntc".
>> 3. NTC is a technology used, But the prefix "ntc" is wrongly
>>and heavily used in the driver and the documentation.
>>
>>  .../devicetree/bindings/vendor-prefixes.txt|1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 4d7f375..a39b7d7 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -84,6 +84,7 @@ moxaMoxa
>>  mpl  MPL AG
>>  mundoreader  Mundo Reader S.L.
>>  mxicyMacronix International Co., Ltd.
>> +murata   Murata Manufacturing Co., Ltd.
>
> Nit: please keep this list in alphabetical order.

Sure, Will rearrange and re-spin.
>
> Otherwise, this looks fine to me. With the order fixed:
>
> Acked-by: Mark Rutland 

Thanks
>
> Mark.
>
>>  national National Semiconductor
>>  neonode  Neonode Inc.
>>  netgear  NETGEAR
>> --
>> 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
>>



-- 
Shine bright,
(: Nav :)
--
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