[PATCH 0/3] ARM: OMAP: OMAP4 DTS updates
Hi Tony, Here is a small series I have done for 3.4 but never posted before. It adds GPIO node for twl4030 embedded gpio controller and some LEDs data to be able to get rid of the static init done in board file right now. It is based on arm-soc/omap/dt-missed-3.4 to get the previous patches not yet in linus/master. The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.5/dts/all Regards, Benoit Benoit Cousson (3): arm/dts: twl4030: Add twl4030-gpio node arm/dts: omap4-sdp: Add LEDs support arm/dts: omap4-panda: Add LEDs support arch/arm/boot/dts/omap4-panda.dts | 15 + arch/arm/boot/dts/omap4-sdp.dts | 43 + arch/arm/boot/dts/twl4030.dtsi|8 +++ 3 files changed, 66 insertions(+), 0 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] arm/dts: omap4-panda: Add LEDs support
Add the debug LEDs nodes for an OMAP4 PandaBoard.
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/omap4-panda.dts | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index ea6f5bb..e671361 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -17,6 +17,21 @@
device_type = "memory";
reg = <0x8000 0x4000>; /* 1 GB */
};
+
+ leds {
+ compatible = "gpio-leds";
+ heartbeat {
+ label = "pandaboard::status1";
+ gpios = <&gpio1 7 0>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ mmc {
+ label = "pandaboard::status2";
+ gpios = <&gpio1 8 0>;
+ linux,default-trigger = "mmc0";
+ };
+ };
};
&i2c1 {
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] arm/dts: omap4-sdp: Add LEDs support
Add the debug LEDs nodes for an OMAP4 SDP/Blaze.
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/omap4-sdp.dts | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 67b2e98..e5eeb6f 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -27,6 +27,49 @@
enable-active-high;
regulator-boot-on;
};
+
+ leds {
+ compatible = "gpio-leds";
+ debug0 {
+ label = "omap4:green:debug0";
+ gpios = <&gpio2 29 0>; /* 61 */
+ };
+
+ debug1 {
+ label = "omap4:green:debug1";
+ gpios = <&gpio1 30 0>; /* 30 */
+ };
+
+ debug2 {
+ label = "omap4:green:debug2";
+ gpios = <&gpio1 7 0>; /* 7 */
+ };
+
+ debug3 {
+ label = "omap4:green:debug3";
+ gpios = <&gpio1 8 0>; /* 8 */
+ };
+
+ debug4 {
+ label = "omap4:green:debug4";
+ gpios = <&gpio2 18 0>; /* 50 */
+ };
+
+ user1 {
+ label = "omap4:blue:user";
+ gpios = <&gpio6 9 0>; /* 169 */
+ };
+
+ user2 {
+ label = "omap4:red:user";
+ gpios = <&gpio6 10 0>; /* 170 */
+ };
+
+ user3 {
+ label = "omap4:green:user";
+ gpios = <&gpio5 11 0>; /* 139 */
+ };
+ };
};
&i2c1 {
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] arm/dts: twl4030: Add twl4030-gpio node
Add the twl-gpio node inside twl4030 definition.
Cc: Felipe Balbi
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/twl4030.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index a94654c..22f4d13 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -36,4 +36,12 @@
regulator-min-microvolt = <185>;
regulator-max-microvolt = <315>;
};
+
+ twl_gpio: gpio {
+ compatible = "ti,twl4030-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
Hi Sourav,
On 10/22/2012 09:29 AM, Sourav Poddar wrote:
> Currently, omap4 keypad mux settings are done in the board file.
> Populate the mux settings in the dts file for the keypad to
> work via dt.
Have you changed the driver to handle properly the dependency with the
pinctrl and thus return EPROBE_DEFER if this is not ready?
Seb Guiriec has just sent a patch to do that for the omap-i2c driver
([PATCH] i2c: omap: adopt pinctrl support).
> Cc: Felipe Balbi
> Tested on omap4430 sdp with 3.7-rc1.
>
> Signed-off-by: Sourav Poddar
> ---
> arch/arm/boot/dts/omap4-sdp.dts | 26 ++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 5b7e04f..5efb059 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -194,6 +194,27 @@
> 0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT
> | MODE0 */
> >;
> };
> +
> + keypad_pins: pinmux_keypad_pins {
> + pinctrl-single,pins = <
> + 0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
Alway use lower case for hexa value.
> + 0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN |
> OMAP_MUX_MODE1 */
> + 0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + 0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA |
> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
> + >;
> + };
> };
>
> &i2c1 {
> @@ -406,3 +427,8 @@
> &mcbsp3 {
> status = "disabled";
> };
> +
> +&keypad {
> +pinctrl-names = "default";
> +pinctrl-0 = <&keypad_pins>;
> +};
Otherwise that looks good.
Thanks,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
On 10/22/2012 10:23 AM, Sourav wrote:
> Hi Benoit,
> On Monday 22 October 2012 01:15 PM, Benoit Cousson wrote:
>> Hi Sourav,
>>
>> On 10/22/2012 09:29 AM, Sourav Poddar wrote:
>>> Currently, omap4 keypad mux settings are done in the board file.
>>> Populate the mux settings in the dts file for the keypad to
>>> work via dt.
>> Have you changed the driver to handle properly the dependency with the
>> pinctrl and thus return EPROBE_DEFER if this is not ready?
> I have send a patch[1] to the mailing list on the driver changes.
> http://www.spinics.net/lists/linux-omap/msg79985.html.
Yeah, sorry, I've just seen it :-(.
> Though, I see I have missed the following EPROBE_DEFER check..
Yes, indeed.
> + if (PTR_ERR(dev->pins) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> Will add for the above patch.
Thanks,
Benoit
>> Seb Guiriec has just sent a patch to do that for the omap-i2c driver
>> ([PATCH] i2c: omap: adopt pinctrl support).
>>
>>> Cc: Felipe Balbi
>>> Tested on omap4430 sdp with 3.7-rc1.
>>>
>>> Signed-off-by: Sourav Poddar
>>> ---
>>> arch/arm/boot/dts/omap4-sdp.dts | 26 ++
>>> 1 files changed, 26 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>>> b/arch/arm/boot/dts/omap4-sdp.dts
>>> index 5b7e04f..5efb059 100644
>>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>>> @@ -194,6 +194,27 @@
>>> 0xbc 0x100/* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT |
>>> MODE0 */
>>> >;
>>> };
>>> +
>>> +keypad_pins: pinmux_keypad_pins {
>>> +pinctrl-single,pins = <
>>> +0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>> Alway use lower case for hexa value.
> Ok. Will fix and send a new version.
>>> +0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN |
>>> OMAP_MUX_MODE1 */
>>> +0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA |
>>> OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
>>> +>;
>>> +};
>>> };
>>> &i2c1 {
>>> @@ -406,3 +427,8 @@
>>> &mcbsp3 {
>>> status = "disabled";
>>> };
>>> +
>>> +&keypad {
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <&keypad_pins>;
>>> +};
>> Otherwise that looks good.
>>
>> Thanks,
>> Benoit
> Thanks,
> Sourav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Dimitry,
On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use pinctrl. Is
> there a better place to select default pin configuration; maybe when
> instantiating platform device?
Why?
The devm_pinctrl_get_select_default is using the pinctrl.
That's why it is named "get_select_default" and not "get" only.
This API ensure that the pin will be set to the default state, and this
is all we need to do during the probe.
There is no point to change the mux if the driver is not probed, because
potentially the pin can be use be another driver.
So probe is the right place to do that for my point of view. Moreover
with DT we don't have that board static config like we had before to do
that kind of pin mux init.
But, maybe I'm missing your point.
Regards,
Benoit
>
> Thanks.
>
>>
>> Cc: Felipe Balbi
>> Cc: Dmitry Torokhov
>> Signed-off-by: Sourav Poddar
>> ---
>> v1->v2
>> - Added "PROBE_DEFER" check
>> drivers/input/keyboard/omap4-keypad.c | 11 +++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/omap4-keypad.c
>> b/drivers/input/keyboard/omap4-keypad.c
>> index c05f98c..502b832 100644
>> --- a/drivers/input/keyboard/omap4-keypad.c
>> +++ b/drivers/input/keyboard/omap4-keypad.c
>> @@ -31,6 +31,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -76,6 +77,7 @@ enum {
>>
>> struct omap4_keypad {
>> struct input_dev *input;
>> +struct pinctrl *pins;
>>
>> void __iomem *base;
>> unsigned int irq;
>> @@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct
>> platform_device *pdev)
>> goto err_release_mem;
>> }
>>
>> +keypad_data->pins = devm_pinctrl_get_select_default(&pdev->dev);
>> +if (IS_ERR(keypad_data->pins)) {
>> +if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>> +
>> +dev_warn(&pdev->dev, "did not get pins for keypad error: %li\n",
>> +PTR_ERR(keypad_data->pins));
>> +keypad_data->pins = NULL;
>> +}
>>
>> /*
>> * Enable clocks for the keypad module so that we can read
>> --
>> 1.7.1
>>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Linus, On 10/23/2012 11:13 AM, Linus Walleij wrote: > On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov > wrote: >> Hi Sourav, >> >> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote: >>> Adapt keypad to use pinctrl framework. >>> >>> Tested on omap4430 sdp with 3.7-rc1 kernel. >> >> I do not see anything in the driver that would directly use pinctrl. Is >> there a better place to select default pin configuration; maybe when >> instantiating platform device? > > The option is to use pinctrl hogs. Then the pins will be taken, > muxed and configured by the pin controller itself. > > Another option (not implemented) is to use bus notifiers. > > (I wrote about this in some other thread but can't find it now.) > > Each approach above come with its own set of problems. > > If the driver need to handle multiple states like default/idle/sleep > it is IMO better to put the handling into the driver, so if that > is what is going to happen also to this driver it could be a good > idea to actually implement that code upfront and include in > this submission so as to show that this driver is really going > to exercise its pins. > > But it's also a question of conformity: if other drivers in the > system is using different states and this is the only one > using a single "default" state, then it doesn't make sense > to have just one driver get its pins using hogs, it's just > inconsistent. > > So Sourav, please tell us a bit about your plans for this > and other drivers! Yeah, this idea is to handle pinctrl from all the drivers, and potentially change the mode during suspend when it is relevant. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 04:49 PM, Jon Hunter wrote:
> Hi Seb,
>
> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>> Add base address and interrupt line inside Device Tree data for
>> OMAP5
>>
>> Signed-off-by: Sebastien Guiriec
>> ---
>> arch/arm/boot/dts/omap5.dtsi | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>> index 42c78be..9e39f9f 100644
>> --- a/arch/arm/boot/dts/omap5.dtsi
>> +++ b/arch/arm/boot/dts/omap5.dtsi
>> @@ -104,6 +104,8 @@
>>
>> gpio1: gpio@4ae1 {
>> compatible = "ti,omap4-gpio";
>> +reg = <0x4ae1 0x200>;
>> +interrupts = <0 29 0x4>;
>> ti,hwmods = "gpio1";
>> gpio-controller;
>> #gpio-cells = <2>;
>
> I am wondering if we should add the "interrupt-parent" property to add
> nodes in the device-tree source. I know that today the interrupt-parent
> is being defined globally, but when device-tree maps an interrupt for a
> device it searches for the interrupt-parent starting the current device
> node.
>
> So in other words, for gpio1 it will search the gpio1 binding for
> "interrupt-parent" and if not found move up a level and search again. It
> will keep doing this until it finds the "interrupt-parent".
>
> Therefore, I believe it will improve search time and hence, boot time if
> we have interrupt-parent defined in each node.
Mmm, I'm not that sure. it will increase the size of the blob, so
increase the time to load it and then to parse it. Where in the current
case, it is just going up to the parent node using the already
un-flatten tree in memory and thus that should not take that much time.
That being said, it might be interesting to benchmark that to see what
is the real impact.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 05:59 PM, Jon Hunter wrote:
>
> On 10/23/2012 10:09 AM, Benoit Cousson wrote:
>> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>>> Hi Seb,
>>>
>>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>>>> Add base address and interrupt line inside Device Tree data for
>>>> OMAP5
>>>>
>>>> Signed-off-by: Sebastien Guiriec
>>>> ---
>>>> arch/arm/boot/dts/omap5.dtsi | 16
>>>> 1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>>>> index 42c78be..9e39f9f 100644
>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>> @@ -104,6 +104,8 @@
>>>>
>>>>gpio1: gpio@4ae1 {
>>>>compatible = "ti,omap4-gpio";
>>>> + reg = <0x4ae1 0x200>;
>>>> + interrupts = <0 29 0x4>;
>>>>ti,hwmods = "gpio1";
>>>>gpio-controller;
>>>>#gpio-cells = <2>;
>>>
>>> I am wondering if we should add the "interrupt-parent" property to add
>>> nodes in the device-tree source. I know that today the interrupt-parent
>>> is being defined globally, but when device-tree maps an interrupt for a
>>> device it searches for the interrupt-parent starting the current device
>>> node.
>>>
>>> So in other words, for gpio1 it will search the gpio1 binding for
>>> "interrupt-parent" and if not found move up a level and search again. It
>>> will keep doing this until it finds the "interrupt-parent".
>>>
>>> Therefore, I believe it will improve search time and hence, boot time if
>>> we have interrupt-parent defined in each node.
>>
>> Mmm, I'm not that sure. it will increase the size of the blob, so
>> increase the time to load it and then to parse it. Where in the current
>> case, it is just going up to the parent node using the already
>> un-flatten tree in memory and thus that should not take that much time.
>
> Yes it will definitely increase the size, so that could slow things down.
>
>> That being said, it might be interesting to benchmark that to see what
>> is the real impact.
>
> Right, I wonder what the key functions are we need to benchmark to get
> an overall feel for what is best? Right now I am seeing some people add
> the interrupt-parent for device nodes and others not. Ideally we should
> be consistent, but at the same time it is probably something that we can
> easily sort out later. So not a big deal either way.
For consistency, I'd rather not add it at all for the moment.
Later, when we will only support DT boot, people will start complaining
about the boot time increase and then we will start optimizing a little
bit :-)
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 06:15 PM, Sebastien Guiriec wrote:
> Hi Benoit and John,
>
> On 10/23/2012 06:07 PM, Benoit Cousson wrote:
>> On 10/23/2012 05:59 PM, Jon Hunter wrote:
>>>
>>> On 10/23/2012 10:09 AM, Benoit Cousson wrote:
>>>> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>>>>> Hi Seb,
>>>>>
>>>>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>>>>>> Add base address and interrupt line inside Device Tree data for
>>>>>> OMAP5
>>>>>>
>>>>>> Signed-off-by: Sebastien Guiriec
>>>>>> ---
>>>>>> arch/arm/boot/dts/omap5.dtsi | 16
>>>>>> 1 file changed, 16 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi
>>>>>> b/arch/arm/boot/dts/omap5.dtsi
>>>>>> index 42c78be..9e39f9f 100644
>>>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>>>> @@ -104,6 +104,8 @@
>>>>>>
>>>>>> gpio1: gpio@4ae1 {
>>>>>> compatible = "ti,omap4-gpio";
>>>>>> +reg = <0x4ae1 0x200>;
>>>>>> +interrupts = <0 29 0x4>;
>>>>>> ti,hwmods = "gpio1";
>>>>>> gpio-controller;
>>>>>> #gpio-cells = <2>;
>>>>>
>>>>> I am wondering if we should add the "interrupt-parent" property to add
>>>>> nodes in the device-tree source. I know that today the
>>>>> interrupt-parent
>>>>> is being defined globally, but when device-tree maps an interrupt
>>>>> for a
>>>>> device it searches for the interrupt-parent starting the current
>>>>> device
>>>>> node.
>>>>>
>>>>> So in other words, for gpio1 it will search the gpio1 binding for
>>>>> "interrupt-parent" and if not found move up a level and search
>>>>> again. It
>>>>> will keep doing this until it finds the "interrupt-parent".
>>>>>
>>>>> Therefore, I believe it will improve search time and hence, boot
>>>>> time if
>>>>> we have interrupt-parent defined in each node.
>>>>
>>>> Mmm, I'm not that sure. it will increase the size of the blob, so
>>>> increase the time to load it and then to parse it. Where in the current
>>>> case, it is just going up to the parent node using the already
>>>> un-flatten tree in memory and thus that should not take that much time.
>>>
>>> Yes it will definitely increase the size, so that could slow things
>>> down.
>>>
>>>> That being said, it might be interesting to benchmark that to see what
>>>> is the real impact.
>>>
>>> Right, I wonder what the key functions are we need to benchmark to get
>>> an overall feel for what is best? Right now I am seeing some people add
>>> the interrupt-parent for device nodes and others not. Ideally we should
>>> be consistent, but at the same time it is probably something that we can
>>> easily sort out later. So not a big deal either way.
>>
>> For consistency, I'd rather not add it at all for the moment.
>> Later, when we will only support DT boot, people will start complaining
>> about the boot time increase and then we will start optimizing a little
>> bit :-)
>
> I just do it like that to be consistent with what is inside OMAP4 dtsi
> for those IPs (GPIO/UART/MMC/I2C). Now after checking Peter already add
> the interrupt-parent for all audio IPs (OMAP3/4/5). But here we need
> also interrupts name. So here we should try to be consistent.
>
> So I can send back the series for OMAP5 and update the OMAP4 with
> interrupts-parent = <&gic>
No, you should not, as explained previously. You'd better remove the one
already in audio IPs for consistency.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
Hi Seb, Sorry, I missed your previous email, your v2 was the right one. We do have a single INTC in every OMAP, there is no point to repeat the same data hundred times. The DTS are already big enough. On 10/24/2012 09:07 AM, Sebastien Guiriec wrote: > Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the > address space > and interrupt line description inside dtsi file for OMAP5. This serie is > updating the > current OMAP5 IP with missing entry. > > It has been tested on OMAP5 with 3.7-audio-display feature tree. > - MMC is probing and functional > - TWL6041 probing (GPIO/I2C) > - booting (UART) > > Update since v1: > - Add Ack and review > - Fix up commit messages. > > Update since v2: > - Add interrupt-parent. I will take the previous one to avoid the duplication of attributes. On top of that I will remove the ones introduce in audio IPs for consistency on OMAP3/4/5 platforms. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
The interrupt-parent attribute does not have to be added in each
node since the DT framework will check for the parent as well to get it.
Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the
attributes from every nodes that were using it.
Signed-off-by: Benoit Cousson
Cc: Vaibhav Hiremath
Cc: Peter Ujfalusi
Cc: Sebastien Guiriec
---
This patch was triggered by the thread about Seb's patch [1].
So let's clean the current OMAP/AM stuff right now to be consistent.
The patch applies on top of the for_3.8/dts [2] branch.
Regards,
Benoit
[1] https://lkml.org/lkml/2012/10/24/85
[2] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
arch/arm/boot/dts/am33xx.dtsi | 17 +
arch/arm/boot/dts/omap2.dtsi|1 +
arch/arm/boot/dts/omap2420.dtsi |2 --
arch/arm/boot/dts/omap2430.dtsi |5 -
arch/arm/boot/dts/omap3.dtsi|6 +-
arch/arm/boot/dts/omap4.dtsi|6 --
arch/arm/boot/dts/omap5.dtsi|5 -
7 files changed, 3 insertions(+), 39 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 64c2efe..4709269 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -12,6 +12,7 @@
/ {
compatible = "ti,am33xx";
+ interrupt-parent = <&intc>;
aliases {
serial0 = &uart1;
@@ -94,7 +95,6 @@
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x44e07000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <96>;
};
@@ -106,7 +106,6 @@
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x4804c000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <98>;
};
@@ -118,7 +117,6 @@
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x481ac000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <32>;
};
@@ -130,7 +128,6 @@
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x481ae000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <62>;
};
@@ -139,7 +136,6 @@
ti,hwmods = "uart1";
clock-frequency = <4800>;
reg = <0x44e09000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <72>;
status = "disabled";
};
@@ -149,7 +145,6 @@
ti,hwmods = "uart2";
clock-frequency = <4800>;
reg = <0x48022000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <73>;
status = "disabled";
};
@@ -159,7 +154,6 @@
ti,hwmods = "uart3";
clock-frequency = <4800>;
reg = <0x48024000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <74>;
status = "disabled";
};
@@ -169,7 +163,6 @@
ti,hwmods = "uart4";
clock-frequency = <4800>;
reg = <0x481a6000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <44>;
status = "disabled";
};
@@ -179,7 +172,6 @@
ti,hwmods = "uart5";
clock-frequency = <4800>;
reg = <0x481a8000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <45>;
status = "disabled";
};
@@ -189,7 +181,6 @@
ti,hwmods = "uart6";
clock-frequency = <4800>;
reg = <0x481aa000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <46>;
status = "disabled";
};
@@ -200,7 +191,6 @@
#size-cells = <0>;
Re: [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
On 10/24/2012 11:27 AM, Sebastien Guiriec wrote: > Hi Benoit, > > On 10/24/2012 11:15 AM, Benoit Cousson wrote: >> Hi Seb, >> >> Sorry, I missed your previous email, your v2 was the right one. >> We do have a single INTC in every OMAP, there is no point to repeat the >> same data hundred times. >> The DTS are already big enough. > > So in such case we should send a series for audio IP interrupt-parent > removal for OMAP3/4/5 dtsi file in order to be coherent. Yes. AM33xx was as well using that in some other IPs. > Do you want me to do it? Thanks, but I've just done the patch, I'll sent it in a couple of minutes. Benoit > >> >> On 10/24/2012 09:07 AM, Sebastien Guiriec wrote: >>> Since kernel 3.7 the DTS data are not overwriten by hwmod data we can >>> add the address space >>> and interrupt line description inside dtsi file for OMAP5. This serie >>> is updating the >>> current OMAP5 IP with missing entry. >>> >>> It has been tested on OMAP5 with 3.7-audio-display feature tree. >>> - MMC is probing and functional >>> - TWL6041 probing (GPIO/I2C) >>> - booting (UART) >>> >>> Update since v1: >>> - Add Ack and review >>> - Fix up commit messages. >>> >>> Update since v2: >>> - Add interrupt-parent. >> >> I will take the previous one to avoid the duplication of attributes. >> >> On top of that I will remove the ones introduce in audio IPs for >> consistency on OMAP3/4/5 platforms. >> >> Regards, >> Benoit >> > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: dts: OMAP: Rename pandaES and var_som for consistency
Rename the files to have consistent names across OMAP boards.
Update the Makefile to use the new names.
Signed-off-by: Benoit Cousson
Cc: Uri Yosef
---
arch/arm/boot/dts/Makefile |4 ++--
.../dts/{omap4-pandaES.dts => omap4-panda-es.dts} |0
.../dts/{omap4-var_som.dts => omap4-var-som.dts} |0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{omap4-pandaES.dts => omap4-panda-es.dts} (100%)
rename arch/arm/boot/dts/{omap4-var_som.dts => omap4-var-som.dts} (100%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e69c921..634bd42 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -68,8 +68,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap4-panda.dtb \
- omap4-pandaES.dtb \
- omap4-var_som.dtb \
+ omap4-panda-es.dtb \
+ omap4-var-som.dtb \
omap4-sdp.dtb \
omap5-evm.dtb \
am335x-evm.dtb \
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
similarity index 100%
rename from arch/arm/boot/dts/omap4-pandaES.dts
rename to arch/arm/boot/dts/omap4-panda-es.dts
diff --git a/arch/arm/boot/dts/omap4-var_som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
similarity index 100%
rename from arch/arm/boot/dts/omap4-var_som.dts
rename to arch/arm/boot/dts/omap4-var-som.dts
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
Hi Jon,
On 10/19/2012 04:59 PM, Jon Hunter wrote:
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> Cc: Benoit Cousson
> Signed-off-by: Jon Hunter
I updated the patch to remove the interrupt-parent from the DTS nodes and the
documentation, as discussed on the list in the context of OMAP5 DTS for GPIO.
If you are OK with that version, I'll push it to Tony along with the others DTS
patches.
Regards,
Benoit
---
>From 531cc8142ecd6da7929628772c4035dcf7996fef Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Fri, 19 Oct 2012 09:59:00 -0500
Subject: [PATCH] ARM: dts: OMAP: Add timer nodes
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Add documentation for timer properties specific to OMAP.
Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
Vaibhav's original nodes adding information on which timers support a PWM
output.
Signed-off-by: Jon Hunter
[b-cous...@ti.com: Remove the interrupt-parent from nodes]
Signed-off-by: Benoit Cousson
---
.../devicetree/bindings/arm/omap/timer.txt | 31 +++
arch/arm/boot/dts/am33xx.dtsi | 54 +++
arch/arm/boot/dts/omap2.dtsi | 85 +
arch/arm/boot/dts/omap2420.dtsi|8 ++
arch/arm/boot/dts/omap2430.dtsi|8 ++
arch/arm/boot/dts/omap3.dtsi | 95
arch/arm/boot/dts/omap4.dtsi | 86 ++
7 files changed, 367 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 000..b073d89
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,31 @@
+OMAP Timer bindings
+
+Required properties:
+- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers.
+- reg: Contains timer register address range (base address and
+ length).
+- interrupts: Contains the interrupt information for the timer. The
+ format is being dependent on which interrupt controller
+ the OMAP device uses.
+- ti,hwmods: Name of the hwmod associated to the timer, "timer",
+ where is the instance number of the timer from the
+ HW spec.
+
+Optional properties:
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-dsp:Indicates the timer can interrupt the on-chip
DSP in
+ addition to the ARM CPU.
+- ti,timer-pwm:Indicates the timer can generate a PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
+ and therefore cannot be used by the kernel.
+
+Example:
+
+timer12: timer@48304000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48304000 0xfff>;
+ interrupts = <95>;
+ ti,hwmods = "timer12"
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4709269..7522e16 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -237,5 +237,59 @@
interrupts = <55>;
status = "disabled";
};
+
+ timer1: timer@44e31000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x44e31000 0x1000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@4804 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4804 0x1000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@48042000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48042000 0x1000>;
+ interrupts = <69>;
+ ti,hwmods = &quo
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Dmitry, On 10/24/2012 06:14 PM, Dmitry Torokhov wrote: > On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote: >> Hi, >> >> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote: >>> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote: >>>> Hi Dimitry, >>>> >>>> On 10/22/2012 05:50 PM, Dmitry Torokhov wrote: >>>>> Hi Sourav, >>>>> >>>>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote: >>>>>> Adapt keypad to use pinctrl framework. >>>>>> >>>>>> Tested on omap4430 sdp with 3.7-rc1 kernel. >>>>> >>>>> I do not see anything in the driver that would directly use pinctrl. Is >>>>> there a better place to select default pin configuration; maybe when >>>>> instantiating platform device? >>>> >>>> Why? >>>> The devm_pinctrl_get_select_default is using the pinctrl. >>> >>> No, I guess we ihave different understanding of what "directly use" means. >>> This particular driver does directly use interrupts: it requests it and >>> performs some actions when interrupt arrives. Same goes for IO memory - >>> it gets requested, then we access it. With pinctrl we do not do anything >>> - we just ask another layer to configure it and that is it. >> >> this is true for almost anything we do: >> >> - we ask another layer to allocate memory for us >> - we ask another layer to call our ISR once the IRQ line is asserted >> - we ask another layer to handle the input events we just received >> - we ask another layer to transfer data through DMA for us >> - we ask another layer to turn regulators on and off. > > But we are _directly_ _using_ all of these. You allocate memory and you > (the driver) stuff data into that memory. You ask for DMA and you take > the DMAed data and work with it. Not so with pinctrl in omap keypad and > other drivers I have seen so far. That's not really true. You select a pin mode and thanks to that you get the signal from an external pin that goes to your IP. And thanks to that the IP is doing what your are expecting it to do. Without that your IP will not get any input signal, which will make it a little bit useless, isn't it? >> and so on. This is just how abstractions work, we group common parts in >> a framework so that users don't need to know the details, but still need >> to tell the framework when to fiddle with those resources. >> >>> I have seen just in a few days 3 or 4 drivers having exactly the same >>> change - call to devm_pinctrl_get_select_default(), and I guess I will >>> receive the same patches for the rest of input drivers shortly. >>> This suggests that the operation is done at the wrong level. Do the >>> pin configuration as you parse DT data, the same way you set up i2c >>> devices registers in of_i2c.c, and leave the individual drivers that do >>> not care about specifics alone. >> >> Makes no sense to hide that from drivers. The idea here is that driver >> should know when it needs its pins to muxed correctly. > > The driver also needs memory controller to be initialized, gpio chip be > ready and registered, DMA subsystem ready, input core reade, etc, etc, > etc. You however do not have every driver explicitly initialize any of > that; you expect certain working environment to be already operable. The > driver does manage resources it controls, it has ultimate knowledge > about, pin configuration is normally is not it. We just need to know > that we wired/muxed properly, otherwise we won't work. So please let > parent layers deal with it. > >> 95% of the time >> it will be done during probe() but then again, so what ? >> >> doing that when parsing DT, or on bus notifiers is just plain wrong. >> Drivers should be required to handle all of their resources. > > All of _their_ resources, exactly. They do not own nor control pins so > they should not be bothered with them either. Look, when you see that > potentially _every_ driver in the system needs to set up the same object > that it doe snot use otherwise you should realize that individual driver > is not the proper place to do that. What your are missing as well in that case is the explicit dependency that this API is creating with the pinctrl driver that we are going to miss otherwise. Hence the following code. + if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER) + return -EPROBE_DEFER; If the pinctrl is not already there you defer the probe until it is th
Re: [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
Hi Vaibhav, On 10/25/2012 02:05 PM, Hiremath, Vaibhav wrote: > On Wed, Oct 24, 2012 at 21:11:13, Cousson, Benoit wrote: >> Hi Jon, >> >> On 10/19/2012 04:59 PM, Jon Hunter wrote: >>> Add the 12 GP timers nodes present in OMAP2. >>> Add the 12 GP timers nodes present in OMAP3. >>> Add the 11 GP timers nodes present in OMAP4. >>> Add the 7 GP timers nodes present in AM33xx. >>> >>> Add documentation for timer properties specific to OMAP. >>> >>> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have >>> modified >>> Vaibhav's original nodes adding information on which timers support a PWM >>> output. >>> >>> Cc: Benoit Cousson >>> Signed-off-by: Jon Hunter >> >> I updated the patch to remove the interrupt-parent from the DTS nodes and >> the documentation, as discussed on the list in the context of OMAP5 DTS for >> GPIO. >> >> If you are OK with that version, I'll push it to Tony along with the others >> DTS patches. >> >> Regards, >> Benoit >> >> --- >> From 531cc8142ecd6da7929628772c4035dcf7996fef Mon Sep 17 00:00:00 2001 >> From: Jon Hunter >> Date: Fri, 19 Oct 2012 09:59:00 -0500 >> Subject: [PATCH] ARM: dts: OMAP: Add timer nodes >> >> Add the 12 GP timers nodes present in OMAP2. >> Add the 12 GP timers nodes present in OMAP3. >> Add the 11 GP timers nodes present in OMAP4. >> Add the 7 GP timers nodes present in AM33xx. >> >> Add documentation for timer properties specific to OMAP. >> >> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have >> modified >> Vaibhav's original nodes adding information on which timers support a PWM >> output. >> >> Signed-off-by: Jon Hunter >> [b-cous...@ti.com: Remove the interrupt-parent from nodes] >> Signed-off-by: Benoit Cousson >> --- >> .../devicetree/bindings/arm/omap/timer.txt | 31 +++ >> arch/arm/boot/dts/am33xx.dtsi | 54 +++ >> arch/arm/boot/dts/omap2.dtsi | 85 + >> arch/arm/boot/dts/omap2420.dtsi|8 ++ >> arch/arm/boot/dts/omap2430.dtsi|8 ++ >> arch/arm/boot/dts/omap3.dtsi | 95 >> >> arch/arm/boot/dts/omap4.dtsi | 86 ++ >> 7 files changed, 367 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt >> > > Benoit, > > I have boot tested this on BeagleBone, so, > > Tested-By: Vaibhav Hiremath Excellent, thanks. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 6/7] usb: dwc3-omap: Minor fixes to get dt working
Hi Kishon,
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
> Includes few minor fixes in dwc3-omap like populating the compatible
> string in a correct way, extracting the utmi-mode property properly and
> changing the index of get_irq since irq of core is removed from hwmod
> entry.
> Also updated the documentation with dwc3-omap device tree binding
> information.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/dwc3/dwc3-omap.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index b84ddf3..10aad46 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -318,11 +318,10 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
> struct resource *res;
> struct device *dev = &pdev->dev;
>
> - int size;
> int ret = -ENOMEM;
> int irq;
>
> - const u32 *utmi_mode;
> + u32 utmi_mode;
> u32 reg;
>
> void __iomem*base;
> @@ -336,13 +335,13 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
>
> platform_set_drvdata(pdev, omap);
>
> - irq = platform_get_irq(pdev, 1);
> + irq = platform_get_irq(pdev, 0);
Cannot you use the name of the resource to avoid that kind of trick?
This is for that reason that we added the resource name in DTS :-)
> if (irq < 0) {
> dev_err(dev, "missing IRQ resource\n");
> return -EINVAL;
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
Same here.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/7] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
> Used of_platform_populate() to populate dwc3 core platform_device
> from device tree data. Since now the allocation of unique device id is
> handled by of_*, removed the call to dwc3_get_device_id.
Just for my understanding: How are these devices organized exactly?
Do we have : omap_wrapper -> dwc3-omap -> dwc3-core ?
The DT binding is mentioning some wrapper, but I'm not sure where it
should be located.
Maybe you should add more documentation on that. Or maybe you do have a
other series to add that part?
Regards,
Benoit
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/dwc3/dwc3-omap.c | 50
> +-
> 1 file changed, 10 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index d51c69c..4aaeec4 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -133,7 +134,6 @@ struct dwc3_omap {
> /* device lock */
> spinlock_t lock;
>
> - struct platform_device *dwc3;
> struct platform_device *usb2_phy;
> struct platform_device *usb3_phy;
> struct device *dev;
> @@ -276,12 +276,10 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
> struct dwc3_omap_data *pdata = pdev->dev.platform_data;
> struct device_node *node = pdev->dev.of_node;
>
> - struct platform_device *dwc3;
> struct dwc3_omap*omap;
> struct resource *res;
> struct device *dev = &pdev->dev;
>
> - int devid;
> int size;
> int ret = -ENOMEM;
> int irq;
> @@ -324,34 +322,19 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> - devid = dwc3_get_device_id();
> - if (devid < 0)
> - return -ENODEV;
> -
> - dwc3 = platform_device_alloc("dwc3", devid);
> - if (!dwc3) {
> - dev_err(dev, "couldn't allocate dwc3 device\n");
> - goto err1;
> - }
> -
> context = devm_kzalloc(dev, resource_size(res), GFP_KERNEL);
> if (!context) {
> dev_err(dev, "couldn't allocate dwc3 context memory\n");
> - goto err2;
> + return -ENOMEM;
> }
>
> spin_lock_init(&omap->lock);
> - dma_set_coherent_mask(&dwc3->dev, dev->coherent_dma_mask);
>
> - dwc3->dev.parent = dev;
> - dwc3->dev.dma_mask = dev->dma_mask;
> - dwc3->dev.dma_parms = dev->dma_parms;
> omap->resource_size = resource_size(res);
> omap->context = context;
> omap->dev = dev;
> omap->irq = irq;
> omap->base = base;
> - omap->dwc3 = dwc3;
>
> reg = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
>
> @@ -396,7 +379,7 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
> if (ret) {
> dev_err(dev, "failed to request IRQ #%d --> %d\n",
> omap->irq, ret);
> - goto err2;
> + return ret;
> }
>
> /* enable all IRQs */
> @@ -415,28 +398,16 @@ static int __devinit dwc3_omap_probe(struct
> platform_device *pdev)
>
> dwc3_omap_writel(omap->base, USBOTGSS_IRQENABLE_SET_1, reg);
>
> - ret = platform_device_add_resources(dwc3, pdev->resource,
> - pdev->num_resources);
> - if (ret) {
> - dev_err(dev, "couldn't add resources to dwc3 device\n");
> - goto err2;
> - }
> -
> - ret = platform_device_add(dwc3);
> - if (ret) {
> - dev_err(dev, "failed to register dwc3 device\n");
> - goto err2;
> + if (node) {
> + ret = of_platform_populate(node, NULL, NULL, dev);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to add create dwc3 core\n");
> + return ret;
> + }
> }
>
> return 0;
> -
> -err2:
> - platform_device_put(dwc3);
> -
> -err1:
> - dwc3_put_device_id(devid);
> -
> - return ret;
> }
>
> static int __devexit dwc3_omap_remove(struct platform_device *pdev)
> @@ -446,7 +417,6 @@ static int __devexit dwc3_omap_remove(struct
> platform_device *pdev)
> platform_device_unregister(omap->usb2_phy);
> platform_device_unregister(omap->usb3_phy);
>
> - dwc3_put_device_id(omap->dwc3->id);
> device_for_each_child(&pdev->dev, NULL, dwc3_omap_remove_core);
>
> return 0;
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
Hi Felipe,
On 10/26/2012 10:13 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Oct 25, 2012 at 11:37:33AM +0530, Vivek Gautam wrote:
>> Hi,
>>
>> On Tue, Oct 16, 2012 at 3:38 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Oct 16, 2012 at 03:36:43PM +0530, kishon wrote:
Hi,
On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
> On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
>> This patch adds support to parse probe data for
>> dwc3-exynos driver using device tree.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> drivers/usb/dwc3/dwc3-exynos.c | 20
>> 1 files changed, 20 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c
>> b/drivers/usb/dwc3/dwc3-exynos.c
>> index ca65978..d11ef49 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -21,6 +21,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "core.h"
>>
>> @@ -87,6 +88,8 @@ err1:
>>return ret;
>> }
>>
>> +static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
>> +
>> static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
>> {
>>struct dwc3_exynos_data *pdata = pdev->dev.platform_data;
>> @@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
>> platform_device *pdev)
>>goto err0;
>>}
>>
>> + /*
>> +* Right now device-tree probed devices don't get dma_mask set.
>> +* Since shared usb code relies on it, set it here for now.
>> +* Once we move to full device tree support this will vanish off.
>> +*/
>> + if (!pdev->dev.dma_mask)
>> + pdev->dev.dma_mask = &dwc3_exynos_dma_mask;
>
> says who ?
>
> $ git grep -e dma_mask drivers/of/
> drivers/of/platform.c: dev->dev.dma_mask = &dev->archdata.dma_mask;
> drivers/of/platform.c: dev->archdata.dma_mask = 0xUL;
> drivers/of/platform.c: dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> drivers/of/platform.c: dev->dev.coherent_dma_mask = ~0;
> drivers/of/platform.c: dev->dma_mask = ~0;
>
> -ECONFUSED
dma_mask is set under some ifdef except for "dev->dma_mask = ~0;".
However I agree with you for coherent_dma_mask case.
>>>
>>> indeed. Should we try to patch that instead ?
>>>
>>> Rob, should we set dma_mask at the driver or do you have a nicer way to
>>> handle it ??
>>>
>> Can i have suggestions here please ? :)
>
> Benoit, can you answer here since nobody else does ?
Well, I wish I could, but honestly I don't have a clue :-(
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi Roger, On 10/26/2012 05:16 PM, Roger Quadros wrote: > Hi Kishon & Benoit, > > On 09/24/2012 12:06 PM, Rabin Vincent wrote: >> 2012/9/24 ABRAHAM, KISHON VIJAY : >>> On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent wrote: USB doesn't work on pandaboard on linux-next, and bisection shows this patch. Unfortunately, I can't provide a dmesg log because USB is the only way I currently have to get one out(!), but presumably it's because this omap-usb2 device is never registered? Looks like this breaks non-dt USB on pandaboard; is that intended? >>> >>> Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the >>> old non-dt support). >> >> Well, USB used to work fine on Pandaboard without DT before the >> introduction of "omap-usb2", so one would expected it to continue >> working (until the board file is completely removed). >> >> Anyway, I've moved to DT now. >> >>> Some patches are queued only for 3.7. >>> >>> In case you want to use MUSB please use these patches on linux-next.. >>> [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp >>> [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs >>> entries (from Benoit) >>> [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) >>> [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) >> >> I got these by merging in Benoit's for_3.7/dts_part2 on top of >> next-20120921. Thanks. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > I still can't get musb to work on 3.7-rc2. Apparently it is still > missing the patches from Benoit's for_3.7/dts_part2. > > Maybe I just need to wait for it to be merged? They are now in a for_3.8/dts. Unfortunately, one patch that was adding ctrl_module address in the USB data was rejected and thus I'm not sure it will work without that. I think Tony had an idea to map the ctrl_register to regulator fmwk or something like that. > Till then, where can I get a tree where musb works on Panda? > > Benoit, > > FYI, I get merge conflicts when merging 3.7-rc2 on top of Linus's kernel > HEAD. Am I missing something? Yeah, some more patches were merged outside our tree. I fixed that. Can you try with the updated branch? Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi Paul, On 10/26/2012 07:54 PM, Paul Walmsley wrote: > On Fri, 26 Oct 2012, Benoit Cousson wrote: > >> On 10/26/2012 05:16 PM, Roger Quadros wrote: >> >>> I still can't get musb to work on 3.7-rc2. Apparently it is still >>> missing the patches from Benoit's for_3.7/dts_part2. >>> >>> Maybe I just need to wait for it to be merged? >> >> They are now in a for_3.8/dts. Unfortunately, one patch that was adding >> ctrl_module address in the USB data was rejected and thus I'm not sure >> it will work without that. > > For v3.7-rc timeframe, looks like it's waiting on an ack from you: > > http://www.spinics.net/lists/arm-kernel/msg201028.html Oups, I missed that one. But I thought Roger was mentioning the DT patch and not that one. Anyway, I will answer to Tony. Thanks for the reminder Paul. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
On 10/26/2012 07:57 PM, Benoit Cousson wrote: > Hi Paul, > > On 10/26/2012 07:54 PM, Paul Walmsley wrote: >> On Fri, 26 Oct 2012, Benoit Cousson wrote: >> >>> On 10/26/2012 05:16 PM, Roger Quadros wrote: >>> >>>> I still can't get musb to work on 3.7-rc2. Apparently it is still >>>> missing the patches from Benoit's for_3.7/dts_part2. >>>> >>>> Maybe I just need to wait for it to be merged? >>> >>> They are now in a for_3.8/dts. Unfortunately, one patch that was adding >>> ctrl_module address in the USB data was rejected and thus I'm not sure >>> it will work without that. >> >> For v3.7-rc timeframe, looks like it's waiting on an ack from you: >> >> http://www.spinics.net/lists/arm-kernel/msg201028.html > > Oups, I missed that one. But I thought Roger was mentioning the DT patch > and not that one. > > Anyway, I will answer to Tony. Thanks for the reminder Paul. Well, in fact, I cannot even find the original email in my mailbox :-( I was banned again from linux-omap around that time, so that might be the reason. Tony, So please take that hacky patch if it prevents the regression. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
> Add keypad data node in omap5-evm.
>
> Based on I2C support patch for omap5, which has been
> already posted as a different series.
>
> Tested on omap5430 evm with 3.7-rc1 kernel.
>
> Cc: Felipe Balbi
> Cc: Santosh Shilimkar
>
> Tested on omap5430 sdp with 3.7-rc1 kernel.
>
> Signed-off-by: Sourav Poddar
> ---
> arch/arm/boot/dts/omap5-evm.dts | 95
> +++
> 1 files changed, 95 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
> index c663eba..b812d6d 100644
> --- a/arch/arm/boot/dts/omap5-evm.dts
> +++ b/arch/arm/boot/dts/omap5-evm.dts
> @@ -140,3 +140,98 @@
> &mcbsp3 {
> status = "disabled";
> };
> +
> +&i2c5 {
> + clock-frequency = <40>;
> +
> + smsc@38 {
> + compatible = "smscece1099";
> + reg = <0x38>;
> + clock = <0x13>;
What does that "clock" mean?
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
Hi Avinash,
On 10/30/2012 10:41 AM, Philip, Avinash wrote:
> On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
>> On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
>>> Adds AM33XX SPI support for am335x-bone and am335x-evm.
>
> Matt,
>
> Can you build SPI DT patch with DMA support on top of SPI DT patch
> I submitted [1]. With the patch [1] SPI can work on PIO mode.
> So we can have basic SPI support available in 3.8.
>
> Benoit,
> Can you accept the SPI DT patch [1]
Yes, I've just applied it in for_3.8/dts branch
> In case if you want I will resubmit a patch with subject line modified.
No, that's fine.
Thanks,
Benoit
>
> Current subject line
> arm/dts: AM33XX: Add SPI device tree data
>
> 1. https://patchwork.kernel.org/patch/1470661/
>
> Thanks
> Avinash
>
>>>
>>> Signed-off-by: Matt Porter
>>> ---
>>> arch/arm/boot/dts/am335x-bone.dts | 17 +++
>>> arch/arm/boot/dts/am335x-evm.dts |9
>>> arch/arm/boot/dts/am33xx.dtsi | 43
>>> +
>>> 3 files changed, 69 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts
>>> b/arch/arm/boot/dts/am335x-bone.dts
>>> index 5510979..23edfd8 100644
>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>> @@ -18,6 +18,17 @@
>>> reg = <0x8000 0x1000>; /* 256 MB */
>>> };
>>>
>>> + am3358_pinmux: pinmux@44e10800 {
>>> + spi1_pins: pinmux_spi1_pins {
>>> + pinctrl-single,pins = <
>>> + 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
>>> OUTPUT_PULLUP | MODE3 */
>>> + 0x194 0x33 /* mcasp0_fsx.spi1_d0,
>>> INPUT_PULLUP | MODE3 */
>>> + 0x198 0x13 /* mcasp0_axr0.spi1_d1,
>>> OUTPUT_PULLUP | MODE3 */
>>> + 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
>>> OUTPUT_PULLUP | MODE3 */
>>> + >;
>>> + };
>>> + };
>>> +
>>
>> Change to am33xx_pinmux.
>>
>>> ocp {
>>> uart1: serial@44e09000 {
>>> status = "okay";
>>> @@ -84,3 +95,9 @@
>>> &mmc1 {
>>> vmmc-supply = <&ldo3_reg>;
>>> };
>>> +
>>> +&spi1 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi1_pins>;
>>> +};
>>> diff --git a/arch/arm/boot/dts/am335x-evm.dts
>>> b/arch/arm/boot/dts/am335x-evm.dts
>>> index d63fce8..8d5f660 100644
>>> --- a/arch/arm/boot/dts/am335x-evm.dts
>>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>>> @@ -124,3 +124,12 @@
>>> &mmc1 {
>>> vmmc-supply = <&vmmc_reg>;
>>> };
>>> +
>>> +&spi0 {
>>> + status = "okay";
>>> + spi-flash@0 {
>>> + compatible = "spansion,s25fl064k", "m25p80";
>>> + spi-max-frequency = <2400>;
>>> + reg = <0>;
>>> + };
>>> +};
>>
>> In AM335x-evm, SPI flash available in profile #2 (am335x evm specific
>> profiles).
>> So can you drop this changes as if I understood correctly, am335x-evm.dts
>> will be
>> populated for devices present only on profile #0.
>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index 26a6af7..063ecea 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -40,6 +40,15 @@
>>> };
>>> };
>>>
>>> + am3358_pinmux: pinmux@44e10800 {
>>> + compatible = "pinctrl-single";
>>> + reg = <0x44e10800 0x0238>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + pinctrl-single,register-width = <32>;
>>> + pinctrl-single,function-mask = <0x7f>;
>>> + };
>>> +
>>
>> Pin ctrl support already submitted
>> http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
>>
>> Thanks
>> Avinash
>>
>>> /*
>>> * XXX: Use a flat representation of the AM33XX interconnect.
>>> * The real AM33XX interconnect network is quite complex.Since
>>> @@ -261,6 +270,40 @@
>>> status = "disabled";
>>> };
>>>
>>> + spi0: spi@4803 {
>>> + compatible = "ti,omap4-mcspi";
>>> + ti,hwmods = "spi0";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x4803 0x400>;
>>> + interrupt-parent = <&intc>;
>>> + interrupt = <65>;
>>> + dmas = <&edma 16
>>> + &edma 17
>>> + &edma 18
>>> + &edma 19>;
>>> + dma-names = "tx0", "rx0", "tx1", "rx1";
>>> + ti,spi-num-cs = <2>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + spi1: spi@481a {
>>> + compatible = "ti,omap4-mcspi";
>>> + ti,hwmods = "spi1";
>>> + #address-cell
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On 10/31/2012 11:16 AM, Benoit Cousson wrote:
> Hi Avinash,
>
> On 10/30/2012 10:41 AM, Philip, Avinash wrote:
>> On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
>>> On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
>>>> Adds AM33XX SPI support for am335x-bone and am335x-evm.
>>
>> Matt,
>>
>> Can you build SPI DT patch with DMA support on top of SPI DT patch
>> I submitted [1]. With the patch [1] SPI can work on PIO mode.
>> So we can have basic SPI support available in 3.8.
>>
>> Benoit,
>> Can you accept the SPI DT patch [1]
>
> Yes, I've just applied it in for_3.8/dts branch
Well, in fact I did not, it does not apply :-(
Can you rebase on top of the for_3.8/dts branch? I've just applied the
RTC patch on top that was OK.
Thanks,
Benoit
>
>> In case if you want I will resubmit a patch with subject line modified.
>
> No, that's fine.
>
> Thanks,
> Benoit
>
>>
>> Current subject line
>> arm/dts: AM33XX: Add SPI device tree data
>>
>> 1. https://patchwork.kernel.org/patch/1470661/
>>
>> Thanks
>> Avinash
>>
>>>>
>>>> Signed-off-by: Matt Porter
>>>> ---
>>>> arch/arm/boot/dts/am335x-bone.dts | 17 +++
>>>> arch/arm/boot/dts/am335x-evm.dts |9
>>>> arch/arm/boot/dts/am33xx.dtsi | 43
>>>> +
>>>> 3 files changed, 69 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts
>>>> b/arch/arm/boot/dts/am335x-bone.dts
>>>> index 5510979..23edfd8 100644
>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>> @@ -18,6 +18,17 @@
>>>>reg = <0x8000 0x1000>; /* 256 MB */
>>>>};
>>>>
>>>> + am3358_pinmux: pinmux@44e10800 {
>>>> + spi1_pins: pinmux_spi1_pins {
>>>> + pinctrl-single,pins = <
>>>> + 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
>>>> OUTPUT_PULLUP | MODE3 */
>>>> + 0x194 0x33 /* mcasp0_fsx.spi1_d0,
>>>> INPUT_PULLUP | MODE3 */
>>>> + 0x198 0x13 /* mcasp0_axr0.spi1_d1,
>>>> OUTPUT_PULLUP | MODE3 */
>>>> + 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
>>>> OUTPUT_PULLUP | MODE3 */
>>>> + >;
>>>> + };
>>>> + };
>>>> +
>>>
>>> Change to am33xx_pinmux.
>>>
>>>>ocp {
>>>>uart1: serial@44e09000 {
>>>>status = "okay";
>>>> @@ -84,3 +95,9 @@
>>>> &mmc1 {
>>>>vmmc-supply = <&ldo3_reg>;
>>>> };
>>>> +
>>>> +&spi1 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&spi1_pins>;
>>>> +};
>>>> diff --git a/arch/arm/boot/dts/am335x-evm.dts
>>>> b/arch/arm/boot/dts/am335x-evm.dts
>>>> index d63fce8..8d5f660 100644
>>>> --- a/arch/arm/boot/dts/am335x-evm.dts
>>>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>>>> @@ -124,3 +124,12 @@
>>>> &mmc1 {
>>>>vmmc-supply = <&vmmc_reg>;
>>>> };
>>>> +
>>>> +&spi0 {
>>>> + status = "okay";
>>>> + spi-flash@0 {
>>>> + compatible = "spansion,s25fl064k", "m25p80";
>>>> + spi-max-frequency = <2400>;
>>>> + reg = <0>;
>>>> + };
>>>> +};
>>>
>>> In AM335x-evm, SPI flash available in profile #2 (am335x evm specific
>>> profiles).
>>> So can you drop this changes as if I understood correctly, am335x-evm.dts
>>> will be
>>> populated for devices present only on profile #0.
>>>
>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>>> index 26a6af7..063ecea 100644
>>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>>> @@ -40,6 +40,15 @@
>>>>};
>>>>};
>>>>
>>>> + am3358_pinmux: pinmux@44e10800 {
>>>> +
Re: [PATCH v2] ARM: dts: am33xx: rtc node
Hi Afzal,
On 10/30/2012 10:34 AM, Afzal Mohammed wrote:
> Add am33xx rtc node.
>
> Signed-off-by: Afzal Mohammed
> ---
> Hi Benoit,
>
> This is based on your for_3.8/dts branch.
I've just applied it in the branch with a slight change in the subject.
Thanks,
Benoit
>
> This has been tested on Beagle Bone.
>
> Bindings along with driver changes for DT has been picked by Andrew
> Morton and is now present in linux-next.
>
> Regards
> Afzal
>
> v2
> 1. Remove interrupt parent in rtc node.
> 2. Modify subject as per new convention.
>
>
> arch/arm/boot/dts/am33xx.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 70d24b8..97a7bd3 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -291,5 +291,13 @@
> ti,hwmods = "timer7";
> ti,timer-pwm;
> };
> +
> + rtc@44e3e000 {
> + compatible = "ti,da830-rtc";
> + reg = <0x44e3e000 0x1000>;
> + interrupts = <75
> + 76>;
> + ti,hwmods = "rtc";
> + };
> };
> };
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] ARM: dts: AM33xx: Add SPI node
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash
> Tested-by: Matt Porter
> ---
Applied in for_3.8/dts
Thanks,
Benoit
> Changes since v2:
> - Commit message corrected.
> - Rebase on top of for_3.8/dts
>
> Changes since v1:
> - Corrected reg offset in reg DT entry.
>
> :100644 100644 97a7bd3... 6e04789... March/arm/boot/dts/am33xx.dtsi
> arch/arm/boot/dts/am33xx.dtsi | 24
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 97a7bd3..6e04789 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -299,5 +299,29 @@
> 76>;
> ti,hwmods = "rtc";
> };
> +
> + spi0: spi@4803 {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x4803 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <65>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi0";
> + status = "disabled";
> + };
> +
> + spi1: spi@481a {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x481a 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <125>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi1";
> + status = "disabled";
> + };
> };
> };
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] ARM: dts: AM33xx: Add SPI node
Hi Avinash,
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash
> Tested-by: Matt Porter
I've just realized the interrupt-parent was still there, so I removed both.
Please find below the updated version.
Regards,
Benoit
>From 9fd3c748aac9418cd377249ca463050783d2198f Mon Sep 17 00:00:00 2001
From: Philip, Avinash
Date: Wed, 31 Oct 2012 16:21:09 +0530
Subject: [PATCH] ARM: dts: AM33XX: Add SPI node
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash
Tested-by: Matt Porter
[b-cous...@ti.com: Remove interrupt-parent]
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/am33xx.dtsi | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 97a7bd3..5dfd682 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -299,5 +299,27 @@
76>;
ti,hwmods = "rtc";
};
+
+ spi0: spi@4803 {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4803 0x400>;
+ interrupt = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi0";
+ status = "disabled";
+ };
+
+ spi1: spi@481a {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x481a 0x400>;
+ interrupt = <125>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi1";
+ status = "disabled";
+ };
};
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] ARM: dts: OMAP4/5 device-tree timer updates
Hi Jon, On 11/01/2012 04:49 PM, Jon Hunter wrote: > A few device tree timer updates for OMAP4/5 devices. > > This series adds ... > 1. MPU private addresses for OMAP4 timers > 2. Timer nodes for OMAP5 > 3. 32kHz counter node for OMAP5 Great, thanks for that update. Just in time before the pull request. > This is based upon of Benoit Cousson's OMAP device-tree branch for v3.8. > > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > for_3.8/dts > > Jon Hunter (3): > ARM: dts: Update OMAP4 timer addresses > ARM: dts: Add OMAP5 timer nodes > ARM: dts: Add OMAP5 counter node I've just updated slightly the subjects: 3b3132f ARM: dts: OMAP5: Add counter node df692a9 ARM: dts: OMAP5: Add timer nodes d03a93b ARM: dts: OMAP4: Update timer addresses There are now in my for_3.8/dts branch. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL] ARM: OMAP: DTS for 3.8
Hi Tony,
Please pull some more OMAP5 and AM33xx data for 3.8.
The branch contains as well some cleanup and the omap3-beagle support since the
previous one was in fact a beagle-xm.
Thanks,
Benoit
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linus Torvalds (1):
Linux 3.7-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.8/dts
Afzal Mohammed (1):
ARM: dts: AM33XX: Add rtc node
AnilKumar Ch (8):
ARM: dts: AM33XX: Add device tree OPP table
ARM: dts: AM33XX: Add basic pinctrl device tree data
ARM: dts: AM33XX: Add D_CAN device tree data
ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
ARM: dts: AM33XX: Add temperature sensor device tree data to am335x-evm
ARM: dts: AM33XX: Add tsl2550 ambient light sensor DT data
ARM: dts: Add am335x-evmsk.dts
Documentation: dt: i2c: Update trivial-devices list
Benoit Cousson (2):
ARM: dts: OMAP: Move interrupt-parent to the root node to avoid
duplication
ARM: dts: OMAP: Rename pandaES and var_som for consistency
Jon Hunter (6):
ARM: dts: Add omap3-beagle.dts
ARM: dts: OMAP: Add timer nodes
ARM: dts: OMAP: Add counter-32k nodes
ARM: dts: OMAP4: Update timer addresses
ARM: dts: OMAP5: Add timer nodes
ARM: dts: OMAP5: Add counter node
Kishon Vijay Abraham I (3):
ARM: dts: Add twl6030-usb data
ARM: dts: Add twl4030-usb data
ARM: dts: OMAP4: add *reg* property for ocp2scp
Philip, Avinash (1):
ARM: dts: AM33XX: Add SPI node
Sebastien Guiriec (4):
ARM: dts: omap5: Update GPIO with address space and interrupts
ARM: dts: omap5: Update I2C with address space and interrupts
ARM: dts: omap5: Update UART with address space and interrupts
ARM: dts: omap5: Update MMC with address space and interrupts
.../devicetree/bindings/arm/omap/counter.txt | 15 ++
.../devicetree/bindings/arm/omap/timer.txt | 31
.../devicetree/bindings/bus/omap-ocp2scp.txt | 18 ++
.../devicetree/bindings/i2c/trivial-devices.txt|2 +
arch/arm/boot/dts/Makefile |5 +-
arch/arm/boot/dts/am335x-bone.dts |6 +
arch/arm/boot/dts/am335x-evm.dts | 55 +++
arch/arm/boot/dts/am335x-evmsk.dts | 166
arch/arm/boot/dts/am33xx.dtsi | 139 +++--
arch/arm/boot/dts/omap2.dtsi | 86 ++
arch/arm/boot/dts/omap2420.dtsi| 16 ++-
arch/arm/boot/dts/omap2430.dtsi| 19 ++-
arch/arm/boot/dts/omap3-beagle-xm.dts |6 -
arch/arm/boot/dts/omap3-beagle.dts | 67
arch/arm/boot/dts/omap3.dtsi | 107 -
.../dts/{omap4-pandaES.dts => omap4-panda-es.dts} |0
arch/arm/boot/dts/omap4-panda.dts |4 +
arch/arm/boot/dts/omap4-sdp.dts|4 +
.../dts/{omap4-var_som.dts => omap4-var-som.dts} |0
arch/arm/boot/dts/omap4.dtsi | 105 -
arch/arm/boot/dts/omap5.dtsi | 156 +-
arch/arm/boot/dts/twl4030.dtsi | 27 +++
arch/arm/boot/dts/twl6030.dtsi |5 +
23 files changed, 989 insertions(+), 50 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/counter.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
create mode 100644 arch/arm/boot/dts/am335x-evmsk.dts
create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
rename arch/arm/boot/dts/{omap4-pandaES.dts => omap4-panda-es.dts} (100%)
rename arch/arm/boot/dts/{omap4-var_som.dts => omap4-var-som.dts} (100%)
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
Hi Lokesh, On 11/05/2012 06:58 AM, Lokesh Vutla wrote: > Hi, > On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote: >> This patch series adds Device tree data for the EMIF >> sdram controllers in OMAP5 and LPDDR2 memory devices >> in OMAP5-evm board. >> >> Testing: >> - Boot tested on OMAP5430 evm. >> - Built EMIF as a module. >> >> Changes from v1: >> * Created a seperate dtsi file for Samsung LPDDR2 memory device >>used in OMAP5-evm. >> * Passing reg and interrupt fields from dt for EMIF1 and EMIF2. > Gentle ping on this series. Sorry, I missed it. It might be too late for 3.8, since Tony wanted us to push before -rc4. I'll pull the series anyway just in case. I have a least one comment. Regards, Benoit > > Thanks > Lokesh >> >> Lokesh Vutla (3): >>ARM: dts: omap5-evm: Fix size of memory defined for EVM >>ARM: dts: omap5: EMIF device tree data for OMAP5 boards >>ARM: dts: omap5-evm: LPDDR2 memory device details for EVM >> >> arch/arm/boot/dts/omap5-evm.dts | 13 +- >> arch/arm/boot/dts/omap5.dtsi | 24 +++ >> arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 >> + >> 3 files changed, 103 insertions(+), 1 deletion(-) >> create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi >> > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/3] ARM: dts: omap5: EMIF device tree data for OMAP5 boards
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
> Adding EMIF device tree data for OMAP5 boards.
>
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/boot/dts/omap5.dtsi | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 5db33f4..445aeea 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -319,5 +319,29 @@
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp3";
> };
> +
> + emif1: emif@0x4c00 {
> + compatible = "ti,emif-4d5";
> + ti,hwmods = "emif1";
> + phy-type= <2>;
> + reg = <0x4c00 0x3ff>;
Should 0x400. This parameter is the size, not the end address.
> + interrupts = <0 110 0x4>;
> + interrupt-parent = <&gic>;
Please remove the interrupt-parent. It is not needed since DT will use
the parent node to get it. It will avoid duplicating the entry for every
nodes.
> + hw-caps-read-idle-ctrl;
> + hw-caps-ll-interface;
> + hw-caps-temp-alert;
> + };
> +
> + emif2: emif@0x4d00 {
> + compatible = "ti,emif-4d5";
> + ti,hwmods = "emif2";
> + phy-type= <2>;
Can you just add a comment to give more information. I know this is in
the binding documentation, but some more comment never hurt.
> + reg = <0x4d00 0x3ff>;
0x400 as well.
> + interrupts = <0 111 0x4>;
> + interrupt-parent = <&gic>;
Ditto.
> + hw-caps-read-idle-ctrl;
> + hw-caps-ll-interface;
> + hw-caps-temp-alert;
> + };
> };
> };
>
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 3/3] ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
> Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
> Adding timings and geometry details for Samsung's memory part and
> attaching the same to device-handle of EMIF1/2.
>
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/boot/dts/omap5-evm.dts | 11 +
> arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67
> +
> 2 files changed, 78 insertions(+)
> create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
>
> diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
> index 6f87e1a..ed1d1b5 100644
> --- a/arch/arm/boot/dts/omap5-evm.dts
> +++ b/arch/arm/boot/dts/omap5-evm.dts
> @@ -8,6 +8,7 @@
> /dts-v1/;
>
> /include/ "omap5.dtsi"
> +/include/ "samsung_k3pe0e000b.dtsi"
>
> / {
> model = "TI OMAP5 EVM board";
> @@ -82,3 +83,13 @@
> 0x020700d9>;/* SEARCH */
> linux,input-no-autorepeat;
> };
> +
> +&emif1 {
> + cs1-used;
> + device-handle = <&samsung_K3PE0E000B>;
> +};
> +
> +&emif2 {
> + cs1-used;
> + device-handle = <&samsung_K3PE0E000B>;
> +};
> diff --git a/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
> b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
> new file mode 100644
> index 000..b352d69
> --- /dev/null
> +++ b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
> @@ -0,0 +1,67 @@
> +/*
> + * Timings and Geometry for Samsung K3PE0E000B memory part
> + */
> +
> +/ {
> + samsung_K3PE0E000B: lpddr2 {
> + compatible = "Samsung,K3PE0E000B","jedec,lpddr2-s4";
> + density = <4096>;
> + io-width= <32>;
> +
> + tRPab-min-tck = <3>;
> + tRCD-min-tck= <3>;
> + tWR-min-tck = <3>;
> + tRASmin-min-tck = <3>;
> + tRRD-min-tck= <2>;
> + tWTR-min-tck= <2>;
> + tXP-min-tck = <2>;
> + tRTP-min-tck= <2>;
> + tCKE-min-tck= <3>;
> + tCKESR-min-tck = <3>;
> + tFAW-min-tck= <8>;
> +
> + timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
Nit, but the official unit is: MHz [1].
Regards,
Benoit
[1] http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
On 11/05/2012 11:51 AM, Benoit Cousson wrote: > Hi Lokesh, > > On 11/05/2012 06:58 AM, Lokesh Vutla wrote: >> Hi, >> On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote: >>> This patch series adds Device tree data for the EMIF >>> sdram controllers in OMAP5 and LPDDR2 memory devices >>> in OMAP5-evm board. >>> >>> Testing: >>> - Boot tested on OMAP5430 evm. >>> - Built EMIF as a module. >>> >>> Changes from v1: >>> * Created a seperate dtsi file for Samsung LPDDR2 memory device >>>used in OMAP5-evm. >>> * Passing reg and interrupt fields from dt for EMIF1 and EMIF2. >> Gentle ping on this series. > > Sorry, I missed it. It might be too late for 3.8, since Tony wanted us > to push before -rc4. I'll pull the series anyway just in case. > > I have a least one comment. Could you just rebase on top of the for_3.8 branch, fix the minor comments and repost ASAP. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: AM33XX: Add usbss node
+ Felipe
Hi Afzal,
On 11/05/2012 06:59 AM, Afzal Mohammed wrote:
> From: Ajay Kumar Gupta
>
> Device tree node for usbss on AM33XX. There are two musb
> controllers on am33xx platform so have port0-mode and
> port1-mode data.
>
> [af...@ti.com: reg & interrupt property addition]
>
> Signed-off-by: Ajay Kumar Gupta
> Signed-off-by: Santhapuri, Damodar
> Signed-off-by: Ravi Babu
> Signed-off-by: Afzal Mohammed
> ---
>
> Hi Benoit,
>
> This is based on your "for_3.8/dts" branch.
>
> This is made on top of "usb: musb: am335x support"
> (http://marc.info/?l=linux-omap&m=135187391904863&w=2)
> and has been tested on Beagle Bone.
That looks good to me, I just like to get an Ack from Felipe for the
accuracy of the data part.
Regards,
Benoit
>
> Regards
> Afzal
>
> arch/arm/boot/dts/am33xx.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 5dfd682..78340a5 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -321,5 +321,22 @@
> ti,hwmods = "spi1";
> status = "disabled";
> };
> +
> + usb_otg_hs@4740 {
> + compatible = "ti,musb-am33xx";
> + reg = <0x4740 0x1000/* usbss */
> +0x47401000 0x800 /* musb instance 0 */
> +0x47401800 0x800>; /* musb instance 1 */
> + interrupts = <17/* usbss */
> + 18/* musb instance 0 */
> + 19>; /* musb instance 1 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port0-mode = <3>;
> + port1-mode = <3>;
> + power = <250>;
> + ti,hwmods = "usb_otg_hs";
> + };
> };
> };
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/10] ARM: dts: AM33XX: Add device tree data
Hi Anil, On 11/05/2012 02:46 PM, AnilKumar, Chimata wrote: > On Mon, Nov 05, 2012 at 16:15:40, AnilKumar, Chimata wrote: >> Add device tree date for GPIO based various drivers matrix keypad, >> volume keys, push buttons and use leds accross three AM33XX devices >> viz EVM, BeagleBone and Starter Kit. >> >> To make it functional this series also adds pinctrl data for all >> the GPIOs used by various drivers. In this series only default state >> pinmux/conf settings are added because of sleep/idle state pinctrl >> values are not available. >> >> These patches are based on linux-omap-dt:for_3.8/dts tree and these > > My bad, small correction in this statement, these patches apply cleanly > on linux-omap-dt:for_3.8/dts tree with the below two patches. > http://www.spinics.net/lists/arm-kernel/msg204872.html > http://www.spinics.net/lists/arm-kernel/msg204873.html Mmm, this 2 patches do have dependency on some driver changes that might not be accepted for 3.8. And in fact I do have some comment on the RTC one :-) Don't you prefer to change the order to allow me to pull these ones first? Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
Hi Anil / Colin,
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
> From: Colin Foe-Parker
>
> Add system power off control to rtc driver which is the in-charge
> of controlling the BeagleBone system power. The power_off routine
> can be hooked up to "pm_power_off" system call.
>
> System power off sequence:-
> * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
> * Enable PMIC_POWER_EN in rtc module
> * Set rtc ALARM2 time
> * Enable ALARM2 interrupt
>
> Added while (1); after the above steps to make sure that no other
> process acquire cpu. Otherwise we might see an unexpected behaviour
> because we are shutting down all the power rails of SoC except RTC.
>
> Signed-off-by: Colin Foe-Parker
> [anilku...@ti.com: move poweroff additions to rtc driver]
> Signed-off-by: AnilKumar Ch
> ---
> Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
> drivers/rtc/rtc-omap.c | 79
> +++-
> 2 files changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> index b47aa41..8d9f4f9 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -6,6 +6,10 @@ Required properties:
> - interrupts: rtc timer, alarm interrupts in order
> - interrupt-parent: phandle for the interrupt controller
>
> +Optional properties:
> +- ti,system-power-controller: Telling whether or not rtc is controlling
> + the system power.
I don't know how it is connected at board level, but I'm not sure the
binding is the proper one.
It does not look super generic, and I'm wondering if we should not use
instead some regulator binding to reflect the connection of the RTC to a
regulator.
But without the board / soc spec it is hard to tell :-(
Regards,
Benoit
> +
> Example:
>
> rtc@1c23000 {
> @@ -14,4 +18,5 @@ rtc@1c23000 {
> interrupts = <19
> 19>;
> interrupt-parent = <&intc>;
> + ti,system-power-controller;
> };
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 6009714..2d90170 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -72,6 +72,14 @@
> #define OMAP_RTC_KICK0_REG 0x6c
> #define OMAP_RTC_KICK1_REG 0x70
>
> +#define OMAP_RTC_ALARM2_SECONDS_REG 0x80
> +#define OMAP_RTC_ALARM2_MINUTES_REG 0x84
> +#define OMAP_RTC_ALARM2_HOURS_REG0x88
> +#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
> +#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
> +#define OMAP_RTC_ALARM2_YEARS_REG0x94
> +#define OMAP_RTC_PMIC_REG0x98
> +
> /* OMAP_RTC_CTRL_REG bit fields: */
> #define OMAP_RTC_CTRL_SPLIT (1<<7)
> #define OMAP_RTC_CTRL_DISABLE(1<<6)
> @@ -93,15 +101,24 @@
> #define OMAP_RTC_STATUS_BUSY(1<<0)
>
> /* OMAP_RTC_INTERRUPTS_REG bit fields: */
> +#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (1<<4)
> #define OMAP_RTC_INTERRUPTS_IT_ALARM(1<<3)
> #define OMAP_RTC_INTERRUPTS_IT_TIMER(1<<2)
>
> +/* OMAP_RTC_PMIC_REG bit fields: */
> +#define OMAP_RTC_PMIC_POWER_EN_EN (1<<16)
> +
> /* OMAP_RTC_KICKER values */
> #define KICK0_VALUE 0x83e70b13
> #define KICK1_VALUE 0x95a4f1e0
>
> #define OMAP_RTC_HAS_KICKER 0x1
>
> +#define SHUTDOWN_TIME_SEC2
> +#define SECS_IN_MIN 60
> +#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
> +#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
> +
> static void __iomem *rtc_base;
>
> #define rtc_read(addr) readb(rtc_base + (addr))
> @@ -290,6 +307,58 @@ static int omap_rtc_set_alarm(struct device *dev, struct
> rtc_wkalrm *alm)
> return 0;
> }
>
> +/*
> + * rtc_power_off: Set the pmic power off sequence. The RTC generates
> + * pmic_pwr_enable control, which can be used to control an external
> + * PMIC.
> + */
> +static void rtc_power_off(void)
> +{
> + u32 val;
> + struct rtc_time tm;
> + spinlock_t lock;
> + unsigned long flags;
> +
> + spin_lock_init(&lock);
> +
> + /* Set PMIC power enable */
> + val = readl(rtc_base + OMAP_RTC_PMIC_REG);
> + writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
> +
> + /* Wait few seconds instead of rollover */
> + do {
> + omap_rtc_read_time(NULL, &tm);
> + if (WAIT_AFTER <= tm.tm_sec)
> + mdelay(WAIT_TIME_MS);
> + } while (WAIT_AFTER <= tm.tm_sec);
> +
> + /* Add shutdown time to the current value */
> + tm.tm_sec += SHUTDOWN_TIME_SEC;
> +
> + if (tm2bcd(&tm) < 0)
> + return;
> +
> + pr_info("System will go to power_off state in approx. %d secs\n",
> + SHUTDOWN_TIME_SEC);
> +
> + /* Set the ALARM2 time */
> + rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
>
Re: [PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
+ Mark
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
> From: Colin Foe-Parker
>
> Set tps65217 PMIC status to OFF if power enable toggle is
> supported. Also adds platform data flag, which should be
> passed from board init data.
>
> Signed-off-by: Colin Foe-Parker
> [anilku...@ti.com: move the additions to tps65217 MFD driver]
> Signed-off-by: AnilKumar Ch
> ---
> .../devicetree/bindings/regulator/tps65217.txt |4
> drivers/mfd/tps65217.c | 12
> 2 files changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
> b/Documentation/devicetree/bindings/regulator/tps65217.txt
> index d316fb8..4f05d20 100644
> --- a/Documentation/devicetree/bindings/regulator/tps65217.txt
> +++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
> @@ -11,6 +11,9 @@ Required properties:
>using the standard binding for regulators found at
>Documentation/devicetree/bindings/regulator/regulator.txt.
>
> +Optional properties:
> +- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
That sounds like a generic functionality to me. Don't we have some more
generic way to handle that?
If not, that should probably not be a TI only attribute.
It looks like a GPIO like kind of interface at PMIC level.
Regards,
Benoit
> +
>The valid names for regulators are:
>tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
>
> @@ -20,6 +23,7 @@ Example:
>
> tps: tps@24 {
> compatible = "ti,tps65217";
> + ti,pmic-shutdown-controller;
>
> regulators {
> dcdc1_reg: dcdc1 {
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 3fb32e6..c7f17d8 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -160,6 +160,7 @@ static int __devinit tps65217_probe(struct i2c_client
> *client,
> unsigned int version;
> unsigned int chip_id = ids->driver_data;
> const struct of_device_id *match;
> + bool status_off = false;
> int ret;
>
> if (client->dev.of_node) {
> @@ -170,6 +171,8 @@ static int __devinit tps65217_probe(struct i2c_client
> *client,
> return -EINVAL;
> }
> chip_id = (unsigned int)match->data;
> + status_off = of_property_read_bool(client->dev.of_node,
> + "ti,pmic-shutdown-controller");
> }
>
> if (!chip_id) {
> @@ -207,6 +210,15 @@ static int __devinit tps65217_probe(struct i2c_client
> *client,
> return ret;
> }
>
> + /* Set the PMIC to shutdown on PWR_EN toggle */
> + if (status_off) {
> + ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
> + TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
> + TPS65217_PROTECT_NONE);
> + if (ret)
> + dev_warn(tps->dev, "unable to set the status OFF\n");
> + }
> +
> dev_info(tps->dev, "TPS65217 ID %#x version 1.%d\n",
> (version & TPS65217_CHIPID_CHIP_MASK) >> 4,
> version & TPS65217_CHIPID_REV_MASK);
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
Hi Lokesh, On 11/05/2012 01:52 PM, Lokesh Vutla wrote: > This patch series adds Device tree data for the EMIF > sdram controllers in OMAP5 and LPDDR2 memory devices > in OMAP5-evm board. > > Testing: > - Boot tested on OMAP5430 evm. > - Built EMIF as a module. > > Changes from v2: > * Rebased on top of > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > for_3.8/dts > * Addressed few other comments from Benoit. Thanks for this quick update. I've just applied your series in my for_3.8/dts_part2 branch. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND 00/10] ARM: dts: AM33XX: Add device tree data
Hi Anil, On 11/06/2012 02:48 PM, AnilKumar Ch wrote: > Add device tree date for GPIO based various drivers matrix keypad, > volume keys, push buttons and use leds accross three AM33XX devices > viz EVM, BeagleBone and Starter Kit. > > To make it functional this series also adds pinctrl data for all > the GPIOs used by various drivers. In this series only default state > pinmux/conf settings are added because of sleep/idle state pinctrl > values are not available. > > These patches are based on linux-omap-dt:for_3.8/dts_part2 tree and > these were tested on am33xx devices according to added functionality. > > Change log: > - Rebased on for_3.8/dts_part2 Thanks for the update. Applied in for_3.8/dts_part2. BTW, I've just noticed that am335x-evmsk is not built with make dtbs. The target was missing from the arch/arm/boot/dts/Makefile. Please find below the patch to add it. Thanks, Benoit --- >From 6990451aca80a5107206688308302241f799057a Mon Sep 17 00:00:00 2001 From: Benoit Cousson Date: Tue, 6 Nov 2012 15:52:23 +0100 Subject: [PATCH] ARM: dts: Makefile: Add the am335x-evmsk target in dtbs list The EVMSK was not built with the 'make dtbs' command. Add the missing antry in the dts Makefile. Signed-off-by: Benoit Cousson --- arch/arm/boot/dts/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 634bd42..2458b69 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -73,6 +73,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ omap4-sdp.dtb \ omap5-evm.dtb \ am335x-evm.dtb \ + am335x-evmsk.dtb \ am335x-bone.dtb dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb dtb-$(CONFIG_ARCH_U8500) += snowball.dtb -- 1.7.0.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: dts: AM33XX: Add usbss node
On 11/06/2012 03:29 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Nov 06, 2012 at 07:59:38PM +0530, Afzal Mohammed wrote:
>> From: Ajay Kumar Gupta
>>
>> Device tree node for usbss on AM33XX. There are two musb
>> controllers on am33xx platform so have port0-mode and
>> port1-mode data.
>>
>> [af...@ti.com: reg & interrupt property addition]
>>
>> Signed-off-by: Ajay Kumar Gupta
>> Signed-off-by: Santhapuri, Damodar
>> Signed-off-by: Ravi Babu
>> Signed-off-by: Afzal Mohammed
>
> to my eyes, this looks ok.
>
> Reviewed-by: Felipe Balbi
Thanks Felipe. Patch applied in for_3.8/dts_part2 branch.
Regards,
Benoit
>
>> ---
>>
>> v2: node named as "usb"
>>
>> Depends on "usb: musb: dsps: dt binding - add resources, example"
>> (https://patchwork.kernel.org/patch/1704691/)
>>
>> arch/arm/boot/dts/am33xx.dtsi | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index 5dfd682..20a3f29 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -321,5 +321,22 @@
>> ti,hwmods = "spi1";
>> status = "disabled";
>> };
>> +
>> +usb@4740 {
>> +compatible = "ti,musb-am33xx";
>> +reg = <0x4740 0x1000/* usbss */
>> + 0x47401000 0x800 /* musb instance 0 */
>> + 0x47401800 0x800>; /* musb instance 1 */
>> +interrupts = <17/* usbss */
>> + 18/* musb instance 0 */
>> + 19>; /* musb instance 1 */
>> +multipoint = <1>;
>> +num-eps = <16>;
>> +ram-bits = <12>;
>> +port0-mode = <3>;
>> +port1-mode = <3>;
>> +power = <250>;
>> +ti,hwmods = "usb_otg_hs";
>> +};
>> };
>> };
>> --
>> 1.7.12
>>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
Hi Anil,
On 11/06/2012 06:07 AM, AnilKumar, Chimata wrote:
> On Mon, Nov 05, 2012 at 22:13:25, Cousson, Benoit wrote:
>> Hi Anil / Colin,
>>
>> On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
>>> From: Colin Foe-Parker
>>>
>>> Add system power off control to rtc driver which is the in-charge
>>> of controlling the BeagleBone system power. The power_off routine
>>> can be hooked up to "pm_power_off" system call.
>>>
>>> System power off sequence:-
>>> * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
>>> * Enable PMIC_POWER_EN in rtc module
>>> * Set rtc ALARM2 time
>>> * Enable ALARM2 interrupt
>>>
>>> Added while (1); after the above steps to make sure that no other
>>> process acquire cpu. Otherwise we might see an unexpected behaviour
>>> because we are shutting down all the power rails of SoC except RTC.
>>>
>>> Signed-off-by: Colin Foe-Parker
>>> [anilku...@ti.com: move poweroff additions to rtc driver]
>>> Signed-off-by: AnilKumar Ch
>>> ---
>>> Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
>>> drivers/rtc/rtc-omap.c | 79
>>> +++-
>>> 2 files changed, 83 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
>>> b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
>>> index b47aa41..8d9f4f9 100644
>>> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
>>> @@ -6,6 +6,10 @@ Required properties:
>>> - interrupts: rtc timer, alarm interrupts in order
>>> - interrupt-parent: phandle for the interrupt controller
>>>
>>> +Optional properties:
>>> +- ti,system-power-controller: Telling whether or not rtc is controlling
>>> + the system power.
>>
>> I don't know how it is connected at board level, but I'm not sure the
>> binding is the proper one.
>
> Hi Benoit,
>
> | __ ___ |
> | | || | |
> | |RTC || | |
> | |PMIC | Line | | |
> | |PWR_EN|===>|PWR_EN | |
> | |__||___| |
> | AM335x SoC TPS65217 |
> ||
> ||
> BeagleBone
>
> This is how RTC PMIC_PWR_EN is connected to PWR_EN of TPS65217 PMIC. Only when
> RTC pull low in PMIC_PWR_EN then PMIC will go to power off state provided
> TPS65217
> status should be changed to STATUS_OFF.
>
> ALARM2 event should be trigger to configure PMIC_PWR_EN properly then the
> "Line"
> driven low so that PMIC will go to shutdown mode.
Thanks for the nice diagram :-)
I'm wondering if we cannot abuse the gpio binding to describe that
connection instead of creating two custom attributes (PMIC + RTC).
Ideally we should do that without having to change the RTC to use the
gpiolib at all.
rtc: rtc@44e3e000 {
compatible = "ti,da830-rtc";
reg = <0x44e3e000 0x1000>;
interrupts = <75, 76>;
ti,hwmods = "rtc";
/* expose the PWR_EN functionality of this RTC*/
gpio-controller;
#gpio-cells = <0>; /* assuming we can use 0 ??? */
};
...
tps: tps@24 {
compatible = "ti,tps65217";
/*
* Enable the power enable feature from
* the input line if that attribute is there.
*/
gpio-power-en = <&rtc>; /* PWR_EN */
...
}
Any thought?
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] usb: musb: dsps: dt binding - add resources, example
On 11/06/2012 05:44 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote:
>> OMAP2+ family of devices are now obtaining resources via DT, earlier
>> it was obtained from hwmod. Update binding document accrodingly, while
>> at it add example.
>>
>> Signed-off-by: Afzal Mohammed
>
> this looks fine to me:
>
> Reviewed-by: Felipe Balbi
>
> Benoit, do you take Documentation patches too ?
Well, ideally it should go with the driver change. But if this is a
simple change related to generic attribute I can take it.
Regards,
Benoit
>
>> ---
>>
>> v2: node name changed to "usb"
>>
>> .../devicetree/bindings/usb/am33xx-usb.txt | 21
>> +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
>> b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
>> index a922505..ea840f7 100644
>> --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
>> +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
>> @@ -1,5 +1,7 @@
>> AM33XX MUSB GLUE
>> - compatible : Should be "ti,musb-am33xx"
>> + - reg : offset and length of register sets, first usbss, then for musb
>> instances
>> + - interrupts : usbss, musb instance interrupts in order
>> - ti,hwmods : must be "usb_otg_hs"
>> - multipoint : Should be "1" indicating the musb controller supports
>> multipoint. This is a MUSB configuration-specific setting.
>> @@ -12,3 +14,22 @@ AM33XX MUSB GLUE
>> represents PERIPHERAL.
>> - power : Should be "250". This signifies the controller can supply upto
>> 500mA when operating in host mode.
>> +
>> +Example:
>> +
>> +usb@4740 {
>> +compatible = "ti,musb-am33xx";
>> +reg = <0x4740 0x1000/* usbss */
>> + 0x47401000 0x800 /* musb instance 0 */
>> + 0x47401800 0x800>; /* musb instance 1 */
>> +interrupts = <17/* usbss */
>> + 18/* musb instance 0 */
>> + 19>; /* musb instance 1 */
>> +multipoint = <1>;
>> +num-eps = <16>;
>> +ram-bits = <12>;
>> +port0-mode = <3>;
>> +port1-mode = <3>;
>> +power = <250>;
>> +ti,hwmods = "usb_otg_hs";
>> +};
>> --
>> 1.7.12
>>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
> Hi Grant
>
> On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
>
>> On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
>> wrote:
>
> [ snip ]
>>
>> g.
>
> Since we've started talking about longer term goals, and the versioning
> provision seems to stand, I hope we address how much the fragment versioning
> thing is similar to the way board revisions progress.
>
> If a versioning syntax is available then one could create a single DT
> file for a bunch of 'almost' similar board and board revisions.
I even think that the version issue is probably much more important for the
short term than the overlay aspect. Well at least as important. We start having
as well a bunch a panda board version with different HW setup.
Having a single board-XXX.dts that will support all these versions is probably
the best approach to avoid choosing that from the bootloader.
We need to figure out a format + mechanism compatible with the current
non-versioned format to allow filtering the nodes at runtime to keep only the
relevant one.
Something that can find the driver that will provide the proper board version
or subsystem version or whatever like that:
compatible-version = "ti,panda-version", "panda";
Then at runtime we should create only the node with the correct match between
the driver version and the string version.
/* regular panda audio routing */
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
compatible-version = "ti,panda-version", "panda";
/* Audio routing */
ti,audio-routing =
"Headset Stereophone", "HSOL",
"Headset Stereophone", "HSOR",
"Ext Spk", "HFL",
"Ext Spk", "HFR",
"Line Out", "AUXL",
"Line Out", "AUXR",
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
"AFMR", "Line In";
};
/* Audio routing is different between PandaBoard4430 and PandaBoardES */
&sound {
ti,model = "PandaBoardES";
compatible-version = "ti,panda-version", "panda-es";
/* Audio routing */
ti,audio-routing =
"Headset Stereophone", "HSOL",
"Headset Stereophone", "HSOR",
"Ext Spk", "HFL",
"Ext Spk", "HFR",
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
"AFMR", "Line In";
};
Maybe some extra version match table can just be passed during the board
machine_init
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
panda_version_match_table);
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] usb: musb: dsps: dt binding - add resources, example
Hi Felipe, On 11/06/2012 07:22 PM, Felipe Balbi wrote: > Hi, > > On Tue, Nov 06, 2012 at 05:58:57PM +0100, Benoit Cousson wrote: >> On 11/06/2012 05:44 PM, Felipe Balbi wrote: >>> Hi, >>> >>> On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote: >>>> OMAP2+ family of devices are now obtaining resources via DT, earlier >>>> it was obtained from hwmod. Update binding document accrodingly, while >>>> at it add example. >>>> >>>> Signed-off-by: Afzal Mohammed >>> >>> this looks fine to me: >>> >>> Reviewed-by: Felipe Balbi >>> >>> Benoit, do you take Documentation patches too ? >> >> Well, ideally it should go with the driver change. But if this is a >> simple change related to generic attribute I can take it. > > ok, cool. Please take this via your tree. Done. I've just applied it in my for_3.8/dts_part2 branch. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/07/2012 12:02 PM, Pantelis Antoniou wrote:
> Hi Benoit,
>
> On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote:
>
>> Hi Panto,
>>
>> On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
>>> Hi Grant
>>>
>>> On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
>>>
>>>> On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
>>>> wrote:
>>>
>>> [ snip ]
>>>>
>>>> g.
>>>
>>> Since we've started talking about longer term goals, and the versioning
>>> provision seems to stand, I hope we address how much the fragment versioning
>>> thing is similar to the way board revisions progress.
>>>
>>> If a versioning syntax is available then one could create a single DT
>>> file for a bunch of 'almost' similar board and board revisions.
>>
>> I even think that the version issue is probably much more important for the
>> short term than the overlay aspect. Well at least as important. We start
>> having as well a bunch a panda board version with different HW setup.
>>
>> Having a single board-XXX.dts that will support all these versions is
>> probably the best approach to avoid choosing that from the bootloader.
>>
>> We need to figure out a format + mechanism compatible with the current
>> non-versioned format to allow filtering the nodes at runtime to keep only
>> the relevant one.
>>
>> Something that can find the driver that will provide the proper board
>> version or subsystem version or whatever like that:
>>
>> compatible-version = "ti,panda-version", "panda";
>>
>> Then at runtime we should create only the node with the correct match
>> between the driver version and the string version.
>>
>>
>
> This is exactly what we need. FWIW the capebus syntax is a little bit
> different.
>
>> /* regular panda audio routing */
>> sound: sound {
>> compatible = "ti,abe-twl6040";
>> ti,model = "PandaBoard";
>> compatible-version = "ti,panda-version", "panda";
>>
>> /* Audio routing */
>> ti,audio-routing =
>> "Headset Stereophone", "HSOL",
>> "Headset Stereophone", "HSOR",
>> "Ext Spk", "HFL",
>> "Ext Spk", "HFR",
>> "Line Out", "AUXL",
>> "Line Out", "AUXR",
>> "HSMIC", "Headset Mic",
>> "Headset Mic", "Headset Mic Bias",
>> "AFML", "Line In",
>> "AFMR", "Line In";
>> };
>>
>>
>> /* Audio routing is different between PandaBoard4430 and PandaBoardES */
>> &sound {
>> ti,model = "PandaBoardES";
>> compatible-version = "ti,panda-version", "panda-es";
>>
>> /* Audio routing */
>> ti,audio-routing =
>> "Headset Stereophone", "HSOL",
>> "Headset Stereophone", "HSOR",
>> "Ext Spk", "HFL",
>> "Ext Spk", "HFR",
>> "Line Out", "AUXL",
>> "Line Out", "AUXR",
>> "AFML", "Line In",
>> "AFMR", "Line In";
>> };
>>
>
> We use this syntax for capebus (totally non-standard of-course),
>
> sound: sound {
> compatible = "ti,abe-twl6040";
>
>
> model@0 {
> ti,model = "PandaBoard";
> ti,audio-routing =
> "Headset Stereophone", "HSOL",
> "Headset Stereophone", "HSOR",
> "Ext Spk", "HFL",
> "Ext Spk", "HFR",
> "Line Out", "AUXL",
> "Line Out", "AUXR",
> "HSMIC", "Headset Mic",
> "Headset Mic", "Headset Mic Bias",
> "AFML", "Line In",
> "AFMR", "Line In";
> };
>
> model@1 {
> ti
Re: [PATCH V4 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
Hi Mugunthan, On 11/07/2012 04:24 PM, Mugunthan V N wrote: > On 11/6/2012 11:02 PM, Mugunthan V N wrote: >> This patch-series adds support for, >> >> [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's >> >> [2/7]: Adds parent<->child relation between CPSW & MDIO module inside >> cpsw >> driver, as in case of AM33XX, the resources are shared and common >> register bit-field is provided to control module/clock >> enable/disable, >> makes it difficult to handle common resource. >> >> So the solution here is, to create parent<->child relation >> between them. >> >> [3/7]: Add hwmod entry for MDIO module, required for MDIO driver. >> >> [4/7]: cpsw: simplify the setup of the register pointers >> >> [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, >> am335x-evm.dts and am335x-bone.dts file >> >> [6/7]: Enable CPSW support to omap2plus_defconfig >> >> [7/7]: cpsw: Kernel warn fix during suspend >> >> This patch series has been created on top of net-next/master and tested >> on BeagleBone platform for NFS boot and basic ping test cases. >> >> Changes from V3: >> * Removed unnecessary flags in Davinci MDIO Hwmod entry. >> >> Mugunthan V N (4): >>ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module >>arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX >>ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support >>net: cpsw: halt network stack before halting the device during >> suspend >> >> Richard Cochran (1): >>cpsw: simplify the setup of the register pointers >> >> Vaibhav Hiremath (2): >>net: davinci_mdio: Fix typo mistake in calling runtime-pm api >>net: cpsw: Add parent<->child relation support between cpsw and mdio >> >> Documentation/devicetree/bindings/net/cpsw.txt | 34 >> arch/arm/boot/dts/am335x-bone.dts |8 + >> arch/arm/boot/dts/am335x-evm.dts |8 + >> arch/arm/boot/dts/am33xx.dtsi | 42 + >> arch/arm/configs/omap2plus_defconfig |3 + >> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 31 >> drivers/net/ethernet/ti/cpsw.c | 231 >> ++-- >> drivers/net/ethernet/ti/davinci_mdio.c |2 +- >> include/linux/platform_data/cpsw.h | 19 -- >> 9 files changed, 192 insertions(+), 186 deletions(-) >> > Paul/Benoit > > Do you any comments The DTS looks better thanks to Richard cleanup. But you did not take into account the minor cosmetic comments I did last time. Could you just clean the DTS based on last time comments and change the subject to be compliant with the other ones and I will take it in my for_3.8/dts_part2 branch. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL] ARM: OMAP: DTS for 3.8 part 2
Hi Tony, Please pull some more OMAP5 and AM33xx data for 3.8. Thanks, Benoit The following changes since commit 3b3132f7e80e3d786f8ad5d5b97d4b6122be9aaa: Jon Hunter (1): ARM: dts: OMAP5: Add counter node are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts_part2 Afzal Mohammed (1): usb: musb: dsps: dt binding - add resources, example Ajay Kumar Gupta (1): ARM: dts: AM33XX: Add usbss node AnilKumar Ch (10): ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk Benoit Cousson (1): ARM: dts: Makefile: Add the am335x-evmsk target in dtbs list Lokesh Vutla (3): ARM: dts: omap5-evm: Fix size of memory defined for EVM ARM: dts: omap5: EMIF device tree data for OMAP5 boards ARM: dts: omap5-evm: LPDDR2 memory device details for EVM Ricardo Neri (2): ARM: dts: omap4-panda: Add pinmux configuration for HDMI ARM: dts: omap4-sdp: Add pinmux configuration for HDMI .../devicetree/bindings/usb/am33xx-usb.txt | 21 + arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/am335x-bone.dts | 44 ++ arch/arm/boot/dts/am335x-evm.dts | 63 +++ arch/arm/boot/dts/am335x-evmsk.dts | 84 arch/arm/boot/dts/am33xx.dtsi | 17 arch/arm/boot/dts/omap4-panda-a4.dts | 17 arch/arm/boot/dts/omap4-panda-es.dts |9 ++ arch/arm/boot/dts/omap4-panda.dts | 18 arch/arm/boot/dts/omap4-sdp-es23plus.dts | 17 arch/arm/boot/dts/omap4-sdp.dts| 18 arch/arm/boot/dts/omap5-evm.dts| 13 +++- arch/arm/boot/dts/omap5.dtsi | 22 + arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 14 files changed, 410 insertions(+), 1 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts create mode 100644 arch/arm/boot/dts/omap4-sdp-es23plus.dts create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
Hi Mark, On 11/14/2012 08:00 AM, Mark Brown wrote: > On Wed, Nov 14, 2012 at 06:49:58AM +, AnilKumar, Chimata wrote: > >> Earlier you have a comment on this thread, I am adding my comments >> on top of it. Sorry if I am in wrong direction. > > Ah, I see. I was just commenting because Benoit was asking if this > should be supported with a standard framework feature - I'm not > convinced that it should right now as there's not any clear patterns in > hardware behaviour. I've no specific interest in this system. I was wondering that, because exposing a pin to control the whole PMIC low power mode seems to be something that should be generic enough to be handled by the regulator framework. In the current situation we do have a pwr_en pin that can be controlled by a GPIO or whatever signal from the SoC. That's very similar, at PMIC level, to the fixedregulator that allow a GPIO binding to enable it. Don't you think that should deserve a support in the fmwk? Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
Hi Vaibhav, On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote: > On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote: >> On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote: >>> As part of PWM subsystem integration, PWM subsystem are sharing >>> resources like clock across submodules (ECAP, EQEP & EHRPWM). >>> To handle resource sharing & IP integration >>> 1. Rework on parent child relation between PWMSS and >>>ECAP, EQEP & EHRPWM child devices to support runtime PM. >>> 2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional >>>clock gating from control module. >>> 3. Add HWMOD entries for EQEP PWM submodule. >>> >> >> Is there any review on this patch? >> This patch depends on ECAP & EHRPWM to work in am335x. > > First of all, I think you should break up this patch as per the 3 points > that you mentioned above. > > The usage of opt_clks for this does not look right to me. Based on your > description this clock is necessary and not optional on AM335x and on > Davinci platforms this clock does not exist. > > I think the custom activate/deactivate functions in the OMAP runtime PM > implementation was a good fit for keeping this SoC integration detail out > of the driver code. However, the current DT flow in omap_device.c seems to > assign the default activate/deactivate ops. Is that approach deprecated? The issue is that this approach is not doable anymore with DT, that's why I had to provide a default set of functions. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/3] ARM/dts: omap3: Add DT support for IGEP devices
Hi Javier, On 11/30/2012 11:08 AM, Javier Martinez Canillas wrote: > IGEP technology devices are TI OMAP3 SoC based industrial embedded > and computer-on-module boards. This patch-set adds initial device > tree support for these devices. > > The device tree allows to boot from an MMC/SD and are working all > the components that already have device tree support on OMAP3 SoCs: That's cool to have one more board DT converted. That series looks good to me, I just have a comment on the DT mux stuff. Regards, Benoit > > - MMC/SD > - UARTs > - GPIO LEDs > - TWL4030 codec audio > - pinmux/pinconf pinctrl > > Some peripheral are still not working such as Flash storage and > Ethernet but support for these will also be included once the > OMAP GPMC device tree binding patches hit mainline. > > This is a v2 of the patch-set that solves issues pointed out by > Enric Balletbo and it is composed of the following patches: > > [PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices > [PATCH v2 2/3] ARM/dts: omap3: Add support for IGEPv2 board > [PATCH v2 3/3] ARM/dts: omap3: Add support for IGEP COM Module > > Best regards, > Javier > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
On 11/30/2012 11:08 AM, Javier Martinez Canillas wrote:
> Add a generic .dtsi device tree source file for the
> common characteristics across IGEP Technology devices.
>
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Matthias Brugger
> ---
> arch/arm/boot/dts/omap3-igep.dtsi | 93
> +
> 1 files changed, 93 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi
>
> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
> b/arch/arm/boot/dts/omap3-igep.dtsi
> new file mode 100644
> index 000..a093bff
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
> @@ -0,0 +1,93 @@
> +/*
> + * Device Tree Source for IGEP Technology devices
> + *
> + * Copyright (C) 2012 Javier Martinez Canillas
> + * Copyright (C) 2012 Enric Balletbo i Serra
> + *
> + * 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/ "omap3.dtsi"
> +
> +/ {
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB */
> + };
> +
> + sound {
> + compatible = "ti,omap-twl4030";
> + ti,model = "igep2";
> + ti,mcbsp = <&mcbsp2>;
> + ti,codec = <&twl_audio>;
> + };
> +};
> +
> +&omap3_pmx_core {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &mcbsp2_pins
> + >;
Tony made a comment to avoid associating these data inside the pmx_core
and instead do that in the dedicated device part.
> +
> + uart3_pins: pinmux_uart3_pins {
> + pinctrl-single,pins = <
> + 0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
> + 0x170 0 /* uart3_tx.uart3_tx OUTPUT | MODE0 */
> + >;
> + };
> +
> + mcbsp2_pins: pinmux_mcbsp2_pins {
> + pinctrl-single,pins = <
> + 0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
> + >;
> + };
BTW, in this case, the UART3 does not seems to have any connection with
the pins settings. Sine your don't have it in the pmx_core you should
have it in side the UART3 node.
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
};
The rational is that, the mux will be done only if the driver is probed
and not unconditionally during pmx_core probe like it will be the case
otherwise.
Regards,
Benoit
> +};
> +
> +&i2c1 {
> + clock-frequency = <260>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
> +
> + vsim: regulator@10 {
> + compatible = "ti,twl4030-vsim";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <300>;
> + };
> +
> + twl_audio: audio {
> + compatible = "ti,twl4030-audio";
> + codec {
> + };
> + };
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&i2c2 {
> + clock-frequency = <40>;
> +};
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc1>;
> + vmmc_aux-supply = <&vsim>;
> + bus-width = <8>;
> +};
> +
> +&mmc2 {
> + status = "disabled";
> +};
> +
> +&mmc3 {
> + status = "disabled";
> +};
> +
> +&twl_gpio {
> + ti,use-leds;
> +};
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/3] ARM/dts: omap3: Add DT support for IGEP devices
Hi Javier, On 12/12/2012 09:25 AM, Javier Martinez Canillas wrote: > On Mon, Dec 3, 2012 at 1:41 PM, Javier Martinez Canillas > wrote: >> IGEP technology devices are TI OMAP3 SoC based industrial embedded >> and computer-on-module boards. This patch-set adds initial device >> tree support for these devices. >> >> The device trees allows to boot from an MMC and are working all the >> components that already have device tree support on OMAP3 SoCs: >> >> - MMC/SD >> - UARTs >> - GPIO LEDs >> - TWL4030 codec audio >> - pinmux/pinconf pinctrl >> >> Some peripheral are still not working such as Flash storage and >> Ethernet but support for these will also be included once the >> OMAP GPMC device tree binding patches land on mainline. >> >> This is a v3 of the patch-set that solves issues pointed out by >> Enric Balletbo and Benoit Cousson. >> >> The patch-set is composed of the following patches: >> >> [PATCH v3 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices >> [PATCH v3 2/3] ARM/dts: omap3: Add support for IGEPv2 board >> [PATCH v3 3/3] ARM/dts: omap3: Add support for IGEP COM Module >> >> Best regards, >> Javier >> -- > > Hi Benoit and Tony, > > Any comments on these? Nope, that's fine. I'll applied the series for 3.9. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.
Hi Matthias,
On 12/12/2012 04:33 PM, Matthias Brugger wrote:
> This patch is a follow-up patch for Javier Martinez effort adding initial
> device tree support to IGEP technology devices. [1]
>
> It adds uart1 and uart2 bindings to the generic dtsi for the IGEP boards.
>
> [1] http://www.spinics.net/lists/linux-omap/msg83409.html
>
> Signed-off-by: Matthias Brugger
> ---
> arch/arm/boot/dts/omap3-igep.dtsi | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
> b/arch/arm/boot/dts/omap3-igep.dtsi
> index 125fe00..c02e3c0 100644
> --- a/arch/arm/boot/dts/omap3-igep.dtsi
> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
> @@ -27,6 +27,20 @@
> };
>
> &omap3_pmx_core {
> + uart1_pins: pinmux_uart1_pins {
> + pinctrl-single,pins = <
> + 0x152 0x100 /* uart1_rx.uart1_rx INPUT | MODE0 */
> + 0x14c 0 /* uart1_tx.uart1_tx OUTPUT | MODE0 */
> + >;
> + };
> +
> + uart2_pins: pinmux_uart2_pins {
> + pinctrl-single,pins = <
> + 0x14a 0x100 /* uart2_rx.uart2_rx INPUT | MODE0 */
> + 0x148 0 /* uart2_tx.uart2_tx OUTPUT | MODE0 */
> + >;
> + };
> +
> uart3_pins: pinmux_uart3_pins {
> pinctrl-single,pins = <
> 0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
> @@ -77,6 +91,16 @@
> status = "disabled";
> };
>
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins>;
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins>;
> +};
> +
> &uart3 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart3_pins>;
>
That looks good to me. I'll apply it on top of javier's series for 3.9.
Thanks,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes
Hi Jon,
On 12/14/2012 10:18 PM, Jon Hunter wrote:
> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
>
> Please note that the node for OMAP4460 has been placed in a separate
> header file for OMAP4460, because the node is not compatible with
> OMAP4430.
But where is the omap4430 node then?
Regards,
Benoit
>
> Signed-off-by: Jon Hunter
> ---
> arch/arm/boot/dts/omap2.dtsi |5 +
> arch/arm/boot/dts/omap3.dtsi |6 ++
> arch/arm/boot/dts/omap4-panda-es.dts |2 ++
> arch/arm/boot/dts/omap4460.dtsi | 18 ++
> arch/arm/mach-omap2/pmu.c|2 ++
> 5 files changed, 33 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap4460.dtsi
>
> diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
> index 761c4b6..27f5ea1 100644
> --- a/arch/arm/boot/dts/omap2.dtsi
> +++ b/arch/arm/boot/dts/omap2.dtsi
> @@ -26,6 +26,11 @@
> };
> };
>
> + pmu {
> + compatible = "arm,arm1136-pmu";
> + interrupts = <3>;
> + };
> +
> soc {
> compatible = "ti,omap-infra";
> mpu {
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 1acc261..6c63118 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -26,6 +26,12 @@
> };
> };
>
> + pmu {
> + compatible = "arm,cortex-a8-pmu";
> + interrupts = <3>;
> + ti,hwmods = "debugss";
> + };
> +
> /*
>* The soc node represents the soc top level view. It is uses for IPs
>* that are not memory mapped in the MPU view or for the MPU itself.
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index 73bc1a6..2a6e344 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -5,7 +5,9 @@
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> +
> /include/ "omap4-panda.dts"
> +/include/ "omap4460.dtsi"
>
> /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
> &sound {
> diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
> new file mode 100644
> index 000..1270890
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4460.dtsi
> @@ -0,0 +1,18 @@
> +/*
> + * Device Tree Source for OMAP4460 SoC
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/ {
> + pmu {
> + compatible = "arm,cortex-a9-pmu";
> + interrupts = <0 54 0x4
> + 0 55 0x4>;
> + ti,hwmods = "debugss";
> + };
> +};
> diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
> index 6e620eb..1a0799c 100644
> --- a/arch/arm/mach-omap2/pmu.c
> +++ b/arch/arm/mach-omap2/pmu.c
> @@ -11,6 +11,8 @@
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
> */
> +#include
> +
> #include
>
> #include "soc.h"
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes
Hi Jon, On 12/17/2012 04:58 PM, Jon Hunter wrote: > > On 12/17/2012 02:16 AM, Benoit Cousson wrote: >> Hi Jon, >> >> On 12/14/2012 10:18 PM, Jon Hunter wrote: >>> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices. >>> >>> Please note that the node for OMAP4460 has been placed in a separate >>> header file for OMAP4460, because the node is not compatible with >>> OMAP4430. >> >> But where is the omap4430 node then? > > I have left it out deliberately because OMAP4430 is not yet supported by > PMU as it is dependent on having a driver for the cross-trigger interface. > > If you prefer to stick the node in the omap4.dtsi for now then that is > ok, but I wanted to make it clear that this is for omap4460. No, that's fine, I was just wondering. You should just add that comment in the cover letter to make it explicit. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes
On 12/17/2012 05:58 PM, Jon Hunter wrote:
>
> On 12/17/2012 10:38 AM, Mark Rutland wrote:
>> On Fri, Dec 14, 2012 at 09:26:37PM +, Jon Hunter wrote:
>>> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
>>>
>>> Please note that the node for OMAP4460 has been placed in a separate
>>> header file for OMAP4460, because the node is not compatible with
>>> OMAP4430.
>>>
>>> Signed-off-by: Jon Hunter
>>> ---
>>> arch/arm/boot/dts/omap2.dtsi |5 +
>>> arch/arm/boot/dts/omap3.dtsi |6 ++
>>> arch/arm/boot/dts/omap4-panda-es.dts |2 ++
>>> arch/arm/boot/dts/omap4460.dtsi | 18 ++
>>> 4 files changed, 31 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/omap4460.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
>>> index 761c4b6..27f5ea1 100644
>>> --- a/arch/arm/boot/dts/omap2.dtsi
>>> +++ b/arch/arm/boot/dts/omap2.dtsi
>>> @@ -26,6 +26,11 @@
>>> };
>>> };
>>>
>>> + pmu {
>>> + compatible = "arm,arm1136-pmu";
>>> + interrupts = <3>;
>>> + };
>>> +
>>> soc {
>>> compatible = "ti,omap-infra";
>>> mpu {
>>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>>> index 1acc261..6c63118 100644
>>> --- a/arch/arm/boot/dts/omap3.dtsi
>>> +++ b/arch/arm/boot/dts/omap3.dtsi
>>> @@ -26,6 +26,12 @@
>>> };
>>> };
>>>
>>> + pmu {
>>> + compatible = "arm,cortex-a8-pmu";
>>> + interrupts = <3>;
>>> + ti,hwmods = "debugss";
>>> + };
>>> +
>>> /*
>>> * The soc node represents the soc top level view. It is uses for IPs
>>> * that are not memory mapped in the MPU view or for the MPU itself.
>>> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
>>> b/arch/arm/boot/dts/omap4-panda-es.dts
>>> index 73bc1a6..2a6e344 100644
>>> --- a/arch/arm/boot/dts/omap4-panda-es.dts
>>> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
>>> @@ -5,7 +5,9 @@
>>> * it under the terms of the GNU General Public License version 2 as
>>> * published by the Free Software Foundation.
>>> */
>>> +
>>> /include/ "omap4-panda.dts"
>>> +/include/ "omap4460.dtsi"
>>>
>>> /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
>>> &sound {
>>> diff --git a/arch/arm/boot/dts/omap4460.dtsi
>>> b/arch/arm/boot/dts/omap4460.dtsi
>>> new file mode 100644
>>> index 000..1270890
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/omap4460.dtsi
>>> @@ -0,0 +1,18 @@
>>> +/*
>>> + * Device Tree Source for OMAP4460 SoC
>>> + *
>>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public License
>>> + * version 2. This program is licensed "as is" without any warranty of any
>>> + * kind, whether express or implied.
>>> + */
>>> +
>>> +/ {
>>> + pmu {
>>> + compatible = "arm,cortex-a9-pmu";
>>> + interrupts = <0 54 0x4
>>> + 0 55 0x4>;
>>
>> In other places I've seen interrupts properties written as:
>>
>> interrupts = < irq1... >,
>> < irq2... >,
>> < irqN... >;
>>
>> Where each individual interrupt is surrounded by angle brackets. This
>> produces
>> the exact same dtb, but may appear easier to read.
>>
>> This might not be the right time and place to raise it, but it'd be nice if
>> we
>> used one style consistently.
>
> I see that we do define interrupts like that for other OMAP devices and
> so I can update this to be consistent.
>
> Benoit, let me know if you want me to resend or if you want to update
> locally.
Yep, I agree with Mark, I don't like this style either.
If you don't mind, I'd prefer you resend the series...
Thanks,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/3] of: Add support for named irq and reg
Hi Grant & Rob, Following the previous patch submission [1], here is an updated series that adds the support for both reg and irq names. A small improvement is done as well on the property with multiple strings helper function. Please note that I've just realized that Russell's concern with the /proc/iomem readability might not even be valid in the DT case. I might be wrong, but it looks like devices created by of_device_alloc does not seems to call the insert_resource. It means that the /proc/iomem is mostly empty when the devices are created from device tree blob. I'm not sure it was done on purpose, but even if this is not the case, the fact is that this /proc/iomem entry does not seems to be used extensively. That does not mean it cannot be improved, but it should change the urgency to fix that with regards to that series. This series is based on 3.2-rc4 and is available here: git://gitorious.org/omap-pm/linux.git for_3.3/resource-names Comments are welcome. Auto comment: I'm not super happy with these new properties name because it is not really consistent. If you have any better idea, do not hesitate. Thanks, Benoit [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg57881.html Benoit Cousson (3): of/base: Take NULL string into account for property with multiple strings of/address: Add reg-names property to name an iomem resource of/irq: Add interrupts-names property to name an irq resource .../devicetree/bindings/interrupts-names.txt | 50 Documentation/devicetree/bindings/reg-names.txt| 48 +++ drivers/of/address.c | 16 -- drivers/of/base.c |8 +-- drivers/of/irq.c | 11 - 5 files changed, 122 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupts-names.txt create mode 100644 Documentation/devicetree/bindings/reg-names.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] of/base: Take NULL string into account for property with multiple strings
The current implementation just ignore any NULL string inserted in a
multiple strings property.
In some cases we can have a property with a fix number of strings but
not necessarily used, like for example in a list of valid pinmux modes.
prop = "uart_rx", "uart_tx", "", "", "safe_mode";
Do no skip NULL string and take them into account in
of_property_read_string_index and of_property_count_strings.
Reported-by: Tony Lindgren
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
drivers/of/base.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 9b6588e..b707243 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -752,7 +752,7 @@ int of_property_read_string_index(struct device_node *np,
const char *propname,
for (i = 0; total < prop->length; total += l, p += l) {
l = strlen(p) + 1;
- if ((*p != 0) && (i++ == index)) {
+ if (i++ == index) {
*output = p;
return 0;
}
@@ -790,11 +790,9 @@ int of_property_count_strings(struct device_node *np,
const char *propname)
p = prop->value;
- for (i = 0; total < prop->length; total += l, p += l) {
+ for (i = 0; total < prop->length; total += l, p += l, i++)
l = strlen(p) + 1;
- if (*p != 0)
- i++;
- }
+
return i;
}
EXPORT_SYMBOL_GPL(of_property_count_strings);
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] of/address: Add reg-names property to name an iomem resource
In a HW system, resources in general have name to identify them.
The is the case as well for IOMEM resources filled by DT "reg" entries.
The current DT mechanism is relying on the "reg" order to identify
the proper resource. This is error prone and not the natural way to
retrieve an information in general.
Moreover, the Linux resource system does support a name and an API to
allow a driver to retrieve the resource using the name instead of an
index.
Add a reg-names property to allow the possiblity to provide a name
to any reg entries.
If the name is available, use it to name the resource, otherwise
keep the legacy device name.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
Documentation/devicetree/bindings/reg-names.txt | 48 +++
drivers/of/address.c| 16 +--
2 files changed, 59 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/reg-names.txt
diff --git a/Documentation/devicetree/bindings/reg-names.txt
b/Documentation/devicetree/bindings/reg-names.txt
new file mode 100644
index 000..5554065
--- /dev/null
+++ b/Documentation/devicetree/bindings/reg-names.txt
@@ -0,0 +1,48 @@
+reg-names property
+
+In a HW system, resources in general have name to identify them.
+The is the case as well for register entries.
+The current DT mechanism is relying on the "reg" order to identify
+the proper resource. The reg-names is adding the possiblity to
+provide a name to reg entries.
+
+Usage:
+
+This attribute must be used along with a regular reg entry. If not
+it will be simply ignored.
+The number of entry must match otherwise the default device name will
+be used to as the resource name.
+
+
+Example:
+
+
+l4-abe {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x4800 0x1000>, /* MPU path */
+<1 0 0x4900 0x1000>; /* L3 path */
+ mcasp {
+ compatible = "ti,mcasp";
+ reg = <0 0x10 0x10>, <0 0x20 0x10>,
+ <1 0x10 0x10>, <1 0x20 0x10>;
+ reg-names = "mpu", "dat",
+ "dma", "dma_dat";
+ };
+
+ timer {
+ compatible = "ti,timer";
+ reg = <0 0x40 0x10>, <1 0x40 0x10>;
+ reg-names = "mpu", "dma";
+ };
+};
+
+
+usb {
+ compatible = "ti,usb-host";
+ reg = <0x4a064000 0x800>, <0x4a064800 0x200>,
+ <0x4a064c00 0x200>;
+ reg-names = "config", "ohci", "ehci";
+};
+
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 72c33fb..66d96f1 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -14,7 +14,7 @@
static struct of_bus *of_match_bus(struct device_node *np);
static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
- struct resource *r);
+ const char *name, struct resource *r);
/* Debug utility */
#ifdef DEBUG
@@ -215,7 +215,7 @@ int of_pci_address_to_resource(struct device_node *dev, int
bar,
addrp = of_get_pci_address(dev, bar, &size, &flags);
if (addrp == NULL)
return -EINVAL;
- return __of_address_to_resource(dev, addrp, size, flags, r);
+ return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
#endif /* CONFIG_PCI */
@@ -529,7 +529,7 @@ EXPORT_SYMBOL(of_get_address);
static int __of_address_to_resource(struct device_node *dev,
const __be32 *addrp, u64 size, unsigned int flags,
- struct resource *r)
+ const char *name, struct resource *r)
{
u64 taddr;
@@ -551,7 +551,8 @@ static int __of_address_to_resource(struct device_node *dev,
r->end = taddr + size - 1;
}
r->flags = flags;
- r->name = dev->full_name;
+ r->name = name ? name : dev->full_name;
+
return 0;
}
@@ -569,11 +570,16 @@ int of_address_to_resource(struct device_node *dev, int
index,
const __be32*addrp;
u64 size;
unsigned intflags;
+ const char *name = NULL;
addrp = of_get_address(dev, index, &size, &flags);
if (addrp == NULL)
return -EINVAL;
- return __of_address_to_resource(dev, addrp, size, flags, r);
+
+ /* Get optional "reg-names" property to add a name to a resource */
+ of_property_read_string_index(dev, "reg-names", index, &name);
+
+ return __of_address_to_resource(dev, addrp, size, flags, name, r);
}
EXPORT_SYMBOL_GPL(of_address_to_resource);
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] of/irq: Add interrupts-names property to name an irq resource
In a HW system, resources in general have name to identify them.
The is the case as well for IORESOURCE_IRQ resources filled by DT
"interrupts" entries.
The current DT mechanism is relying on the "interrupts" order to identify
the proper resource. This is error prone and not the natural way to
retrieve an information in general.
Moreover, the resource does support a name and an API is available to
allow a driver to retrieve the resource using the name instead of an
index.
Add a interrupts-names property to allow the possiblity to provide a name
to any interrupts entries.
If the name is available, use it to name the resource, otherwise
keep the legacy device full name.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
.../devicetree/bindings/interrupts-names.txt | 50
drivers/of/irq.c | 11 -
2 files changed, 60 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupts-names.txt
diff --git a/Documentation/devicetree/bindings/interrupts-names.txt
b/Documentation/devicetree/bindings/interrupts-names.txt
new file mode 100644
index 000..d9a796d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupts-names.txt
@@ -0,0 +1,50 @@
+interrupts-names property
+
+In a HW system, physical resources in general have name to identify them.
+The is the case as well for interrupt lines.
+The current DT mechanism is relying on the "interrupts" order to identify
+the proper resource. The interrupts-names is adding the possiblity to
+provide a name to interrupts entries.
+
+Usage:
+
+This attribute must be used along with a regular interrupts entry. If not
+it will be simply ignored.
+
+
+Example:
+
+
+l4-abe {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x4800 0x1000>, /* MPU path */
+<1 0 0x4900 0x1000>; /* L3 path */
+ mcasp {
+ compatible = "ti,mcasp";
+ reg = <0 0x10 0x10>, <0 0x20 0x10>,
+ <1 0x10 0x10>, <1 0x20 0x10>;
+ reg-names = "mpu", "dat",
+ "dma", "dma_dat";
+ interrupts = <11>, <12>;
+ interrupts-names = "rx", "tx";
+ };
+
+ timer {
+ compatible = "ti,timer";
+ reg = <0 0x40 0x10>, <1 0x40 0x10>;
+ reg-names = "mpu", "dma";
+ };
+};
+
+
+usb {
+ compatible = "ti,usb-host";
+ reg = <0x4a064000 0x800>, <0x4a064800 0x200>,
+ <0x4a064c00 0x200>;
+ reg-names = "config", "ohci", "ehci";
+ interrupts = <14>, <15>;
+ interrupts-names = "ohci", "ehci";
+};
+
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 19c0115..604b53f 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -346,9 +346,18 @@ int of_irq_to_resource(struct device_node *dev, int index,
struct resource *r)
/* Only dereference the resource if both the
* resource and the irq are valid. */
if (r && irq != NO_IRQ) {
+ const char *name = NULL;
+
+ /*
+* Get optional "interrupts-names" property to add a name
+* to the resource.
+*/
+ of_property_read_string_index(dev, "interrupts-names", index,
+ &name);
+
r->start = r->end = irq;
r->flags = IORESOURCE_IRQ;
- r->name = dev->full_name;
+ r->name = name ? name : dev->full_name;
}
return irq;
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
OMAP2+: Devicetree cleanup
Hi Tony, This is a trivial cleanup series the removed some useless stuff inside DTS and force DT by default in an omap2plus_config build. Patches are based 3.2-rc4 and are available here: git://gitorious.org/omap-pm/linux.git for_3.3/1_dt_base Regards, Benoit Benoit Cousson (3): ARM: OMAP2+: kconfig: Enable devicetree by default for OMAP2+ systems arm/dts: OMAP: Remove bootargs node from board files ARM: OMAP2+: board-generic: Replace #if defined by #ifdef for consistency arch/arm/boot/dts/omap3-beagle.dts |9 - arch/arm/boot/dts/omap4-panda.dts |9 - arch/arm/boot/dts/omap4-sdp.dts |9 - arch/arm/mach-omap2/Kconfig |1 - arch/arm/mach-omap2/board-generic.c |8 arch/arm/plat-omap/Kconfig |4 6 files changed, 8 insertions(+), 32 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] ARM: OMAP2+: kconfig: Enable devicetree by default for OMAP2+ systems
devicetree will become the mandatory boot method for OMAP2+. In order to avoid cluttering the OMAP code with #ifdef CONFIG_OF, select USE_OF by default for every OMAP2+ systems. Select as well the APPENDED_DTB and ATAG_DTB_COMPAT to allow legacy boot loader to keep working properly. Enable PROC_DEVICETREE as well. Signed-off-by: Benoit Cousson Cc: Tony Lindgren --- arch/arm/mach-omap2/Kconfig |1 - arch/arm/plat-omap/Kconfig |4 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index e1293aa..056a812 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -109,7 +109,6 @@ comment "OMAP Board Type" config MACH_OMAP_GENERIC bool "Generic OMAP2+ board" depends on ARCH_OMAP2PLUS - select USE_OF default y help Support for generic TI OMAP2+ boards using Flattened Device Tree. diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index aa59f42..74f41dc 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -24,6 +24,10 @@ config ARCH_OMAP2PLUS select CLKDEV_LOOKUP select GENERIC_IRQ_CHIP select OMAP_DM_TIMER + select USE_OF + select ARM_APPENDED_DTB + select ARM_ATAG_DTB_COMPAT + select PROC_DEVICETREE help "Systems based on OMAP2, OMAP3 or OMAP4" -- 1.7.0.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] arm/dts: OMAP: Remove bootargs node from board files
Since 3.2, the CONFIG_ARM_ATAG_DTB_COMPAT config allows
an old bootloader to still use ATAG to provide cmdline.
Remove chosen/bootargs from the DTS board files.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/omap3-beagle.dts |9 -
arch/arm/boot/dts/omap4-panda.dts |9 -
arch/arm/boot/dts/omap4-sdp.dts|9 -
3 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..9f72cd4 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -13,15 +13,6 @@
model = "TI OMAP3 BeagleBoard";
compatible = "ti,omap3-beagle", "ti,omap3";
- /*
-* Since the initial device tree board file does not create any
-* devices (MMC, network...), the only way to boot is to provide a
-* ramdisk.
-*/
- chosen {
- bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug earlyprintk";
- };
-
memory {
device_type = "memory";
reg = <0x8000 0x2000>; /* 512 MB */
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index c702657..9755ad5 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -13,15 +13,6 @@
model = "TI OMAP4 PandaBoard";
compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4";
- /*
-* Since the initial device tree board file does not create any
-* devices (MMC, network...), the only way to boot is to provide a
-* ramdisk.
-*/
- chosen {
- bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug";
- };
-
memory {
device_type = "memory";
reg = <0x8000 0x4000>; /* 1 GB */
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..63c6b2b 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -13,15 +13,6 @@
model = "TI OMAP4 SDP board";
compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4";
- /*
-* Since the initial device tree board file does not create any
-* devices (MMC, network...), the only way to boot is to provide a
-* ramdisk.
-*/
- chosen {
- bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug";
- };
-
memory {
device_type = "memory";
reg = <0x8000 0x4000>; /* 1 GB */
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] ARM: OMAP2+: board-generic: Replace #if defined by #ifdef for consistency
The file contains a mix of #ifdef and #if defined().
Replace the #if... by #ifdef.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-generic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index fb55fa3..09f44e0 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -92,7 +92,7 @@ static void __init omap3_init(void)
}
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#ifdef CONFIG_SOC_OMAP2420
static const char *omap242x_boards_compat[] __initdata = {
"ti,omap2420",
NULL,
@@ -110,7 +110,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened
Device Tree)")
MACHINE_END
#endif
-#if defined(CONFIG_SOC_OMAP2430)
+#ifdef CONFIG_SOC_OMAP2430
static const char *omap243x_boards_compat[] __initdata = {
"ti,omap2430",
NULL,
@@ -128,7 +128,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened
Device Tree)")
MACHINE_END
#endif
-#if defined(CONFIG_ARCH_OMAP3)
+#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
"ti,omap3",
NULL,
@@ -146,7 +146,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device
Tree)")
MACHINE_END
#endif
-#if defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_ARCH_OMAP4
static const char *omap4_boards_compat[] __initdata = {
"ti,omap4",
NULL,
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/4] ARM: OMAP2+: Interrupt controllers adaptation to DT
Hi Tony and Rob, Here is the series to take advantage of the new DT interrupt init mechanism. Thanks to Mark's CONFIG_MULTI_IRQ_HANDLER series, OMAP4 just has to use the default GIC binding and does not need some OMAP specific hacks anymore. OMAP2 and 3 are using a simple interrupt controller that can thus expose a simpler binding. This series is based on rmk/devel-stable branch to get Mark's series + a couple of OMAP fixes. An extra fix is needed before for the board-generic.c file: [PATCH] ARM: OMAP2+: board-generic: Add missing handle_irq The series with all the dependencies merged is available here for reference: git://gitorious.org/omap-pm/linux.git for_3.3/2_dt_irq Regards, Benoit Benoit Cousson (4): arm/dts: OMAP4: Update DTS file with new GIC bindings ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC ARM: OMAP2+: board-generic: Use of_irq_init API .../devicetree/bindings/arm/omap/intc.txt | 27 +++ arch/arm/boot/dts/omap3.dtsi |6 ++- arch/arm/boot/dts/omap4.dtsi |3 +- arch/arm/mach-omap2/board-generic.c| 30 + arch/arm/mach-omap2/common.h | 10 ++ arch/arm/mach-omap2/irq.c | 35 ++-- 6 files changed, 91 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/4] arm/dts: OMAP4: Update DTS file with new GIC bindings
The GIC binding was updated in 3.2 and expect 3 interrupt-cells.
- Update the #interrupt-cells
- interrupt-parent seems to be needed as well for the top level GIC
Signed-off-by: Benoit Cousson
Cc: Rob Herring
---
arch/arm/boot/dts/omap4.dtsi |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..bede009 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -95,7 +95,8 @@
gic: interrupt-controller@48241000 {
compatible = "arm,cortex-a9-gic";
interrupt-controller;
- #interrupt-cells = <1>;
+ interrupt-parent;
+ #interrupt-cells = <3>;
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/4] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller
Add a function to initialize the OMAP2/3 interrupt controller (INTC)
using a device tree node.
Replace some printk() with the proper pr_ macro.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
---
.../devicetree/bindings/arm/omap/intc.txt | 27 +++
arch/arm/mach-omap2/common.h | 10 ++
arch/arm/mach-omap2/irq.c | 35 ++--
3 files changed, 69 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt
b/Documentation/devicetree/bindings/arm/omap/intc.txt
new file mode 100644
index 000..f2583e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/intc.txt
@@ -0,0 +1,27 @@
+* OMAP Interrupt Controller
+
+OMAP2/3 are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ "ti,omap2-intc"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller@1 {
+ compatible = "ti,omap2-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ ti,intc-size = <96>;
+ reg = <0x4820 0x1000>;
+ };
+
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 012bac7..bcfccc2 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -156,6 +156,16 @@ void omap3_intc_resume_idle(void);
void omap2_intc_handle_irq(struct pt_regs *regs);
void omap3_intc_handle_irq(struct pt_regs *regs);
+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent);
+#else
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ return 0;
+}
+#endif
+
/*
* wfi used in low power code. Directly opcode is used instead
* of instruction to avoid mulit-omap build break
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 42b1d65..cafc663 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -17,6 +17,9 @@
#include
#include
#include
+#include
+#include
+#include
/* selected INTC register offsets */
@@ -166,7 +169,7 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
/* Static mapping, never released */
bank->base_reg = ioremap(base, SZ_4K);
if (!bank->base_reg) {
- printk(KERN_ERR "Could not ioremap irq bank%i\n", i);
+ pr_err("Could not ioremap irq bank%i\n", i);
continue;
}
@@ -179,8 +182,8 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
nr_banks++;
}
- printk(KERN_INFO "Total of %ld interrupts on %d active controller%s\n",
- nr_of_irqs, nr_banks, nr_banks > 1 ? "s" : "");
+ pr_info("Total of %ld interrupts on %d active controller%s\n",
+ nr_of_irqs, nr_banks, nr_banks > 1 ? "s" : "");
}
void __init omap2_init_irq(void)
@@ -236,6 +239,32 @@ asmlinkage void __exception_irq_entry
omap2_intc_handle_irq(struct pt_regs *regs
omap_intc_handle_irq(base_addr, regs);
}
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ struct resource res;
+ u32 nr_irqs;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_address_to_resource(node, 0, &res)) {
+ WARN(1, "unable to get intc registers\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, "ti,intc-size", &nr_irqs)) {
+ WARN(1, "unable to get intc-size\n");
+ return -EINVAL;
+ }
+
+ omap_init_irq(res.start, nr_irqs);
+ irq_domain_add_simple(node, 0);
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP3
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/4] arm/dts: OMAP3: Add interrupt-controller bindings for INTC
Update the DTS with the proper information required by the
INTC bindings.
- Add the number of interrupt lines
- Add the reg and the compatible entries.
Signed-off-by: Benoit Cousson
Cc: Rob Herring
---
arch/arm/boot/dts/omap3.dtsi |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..6866dc7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -54,10 +54,12 @@
ranges;
ti,hwmods = "l3_main";
- intc: interrupt-controller@1 {
- compatible = "ti,omap3-intc";
+ intc: interrupt-controller@4820 {
+ compatible = "ti,omap2-intc";
interrupt-controller;
#interrupt-cells = <1>;
+ ti,intc-size = <96>;
+ reg = <0x4820 0x1000>;
};
};
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/4] ARM: OMAP2+: board-generic: Use of_irq_init API
Use the of_irq_init API introduced in 3.2 to handle
interrupt-controller with DT.
Update the irq_match table to map the proper XXX_of_init
functions for INTC and GIC drivers.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
Cc: Rob Herring
---
arch/arm/mach-omap2/board-generic.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index a0e9595..16c301e 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -12,6 +12,7 @@
* published by the Free Software Foundation.
*/
#include
+#include
#include
#include
#include
@@ -24,6 +25,17 @@
#include "common.h"
#include "common-board-devices.h"
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = "ti,omap2-intc", .data = intc_of_init, },
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ { }
+};
+
+static void __init omap_init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+
/*
* XXX: Still needed to boot until the i2c & twl driver is adapted to
* device-tree
@@ -58,18 +70,8 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
-static struct of_device_id intc_match[] __initdata = {
- { .compatible = "ti,omap3-intc", },
- { .compatible = "arm,cortex-a9-gic", },
- { }
-};
-
static void __init omap_generic_init(void)
{
- struct device_node *node = of_find_matching_node(NULL, intc_match);
- if (node)
- irq_domain_add_simple(node, 0);
-
omap_serial_init();
omap_sdrc_init(NULL, NULL);
@@ -103,7 +105,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened
Device Tree)")
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = &omap2_timer,
@@ -122,7 +124,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened
Device Tree)")
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = &omap2_timer,
@@ -141,7 +143,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device
Tree)")
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
- .init_irq = omap3_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap3_init,
.timer = &omap3_timer,
@@ -160,7 +162,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device
Tree)")
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = gic_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = gic_handle_irq,
.init_machine = omap4_init,
.timer = &omap4_timer,
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 00/10] OMAP4: Add DT support for i2c and twl6030
Hi Tony and Rob, Here is the updated version of the i2c + twl DT adaptation. This update, compared to v1 [1], is mainly due to the merge into 3.2 of Andy's i2c cleanup series that was introducing a lot of pdata accesses at runtime. The pm.c was updated to prevent the SR / VP initialization in the DT context since none of them is DT aware for the moment. A couple of basic i2c devices are added for panda, beagle and sdp board. Patches are based on for_3.3/2_dt_irq, to get the latest GIC binding, and are available here: git://gitorious.org/omap-pm/linux.git for_3.3/3_omap_dt_i2c_twl Tested on Beagle and sdp4430. Comments are welcome. Regards, Benoit [1] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-September/007821.html Benoit Cousson (10): ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT i2c: OMAP: Add DT support for i2c controller mfd: twl-core: Add initial DT support for twl4030/twl6030 rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030 arm/dts: OMAP4: Add i2c controller nodes arm/dts: OMAP3: Add i2c controller nodes arm/dts: omap4-panda: Add twl6030 and i2c EEPROM arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM ARM: OMAP2+: board-generic: Remove i2c static init Documentation/devicetree/bindings/i2c/omap-i2c.txt | 42 .../devicetree/bindings/mfd/twl-familly.txt| 47 + Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12 +++ arch/arm/boot/dts/omap3-beagle.dts | 38 arch/arm/boot/dts/omap3.dtsi | 28 ++ arch/arm/boot/dts/omap4-panda.dts | 45 + arch/arm/boot/dts/omap4-sdp.dts| 63 arch/arm/boot/dts/omap4.dtsi | 28 ++ arch/arm/mach-omap2/board-generic.c| 48 +- arch/arm/mach-omap2/pm.c |8 ++ drivers/i2c/busses/i2c-omap.c | 100 +--- drivers/mfd/twl-core.c | 53 ++- drivers/rtc/rtc-twl.c | 10 ++- 13 files changed, 435 insertions(+), 87 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 01/10] ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT
In the case of DT, the PMIC and SR initialization will be done using
a completely different mechanism.
Disable this part if a DT blob is available.
Signed-off-by: Benoit Cousson
Cc: Kevin Hilman
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..ad4f693 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -227,6 +227,14 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
+ /*
+* In the case of DT, the PMIC and SR initialization will be done using
+* a completely different mechanism.
+* Disable this part if a DT blob is available.
+*/
+ if (of_have_populated_dt())
+ return 0;
+
/* Init the voltage layer */
omap_pmic_late_init();
omap_voltage_late_init();
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 00/10] OMAP4: Add DT support for i2c and twl6030
Hi Tony and Rob, Here is the updated version of the i2c + twl DT adaptation. This update, compared to v1 [1], is mainly due to the merge into 3.2 of Andy's i2c cleanup series that was introducing a lot of pdata accesses at runtime. The pm.c was updated to prevent the SR / VP initialization in the DT context since none of them is DT aware for the moment. A couple of basic i2c devices are added for panda, beagle and sdp board. Patches are based on for_3.3/2_dt_irq, to get the latest GIC binding, and are available here: git://gitorious.org/omap-pm/linux.git for_3.3/3_omap_dt_i2c_twl Tested on Beagle and sdp4430. Comments are welcome. Regards, Benoit [1] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-September/007821.html Benoit Cousson (10): ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT i2c: OMAP: Add DT support for i2c controller mfd: twl-core: Add initial DT support for twl4030/twl6030 rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030 arm/dts: OMAP4: Add i2c controller nodes arm/dts: OMAP3: Add i2c controller nodes arm/dts: omap4-panda: Add twl6030 and i2c EEPROM arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM ARM: OMAP2+: board-generic: Remove i2c static init Documentation/devicetree/bindings/i2c/omap-i2c.txt | 42 .../devicetree/bindings/mfd/twl-familly.txt| 47 + Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12 +++ arch/arm/boot/dts/omap3-beagle.dts | 38 arch/arm/boot/dts/omap3.dtsi | 28 ++ arch/arm/boot/dts/omap4-panda.dts | 45 + arch/arm/boot/dts/omap4-sdp.dts| 63 arch/arm/boot/dts/omap4.dtsi | 28 ++ arch/arm/mach-omap2/board-generic.c| 48 +- arch/arm/mach-omap2/pm.c |8 ++ drivers/i2c/busses/i2c-omap.c | 100 +--- drivers/mfd/twl-core.c | 53 ++- drivers/rtc/rtc-twl.c | 10 ++- 13 files changed, 435 insertions(+), 87 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 01/10] ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT
In the case of DT, the PMIC and SR initialization will be done using
a completely different mechanism.
Disable this part if a DT blob is available.
Signed-off-by: Benoit Cousson
Cc: Kevin Hilman
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..ad4f693 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -227,6 +227,14 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
+ /*
+* In the case of DT, the PMIC and SR initialization will be done using
+* a completely different mechanism.
+* Disable this part if a DT blob is available.
+*/
+ if (of_have_populated_dt())
+ return 0;
+
/* Init the voltage layer */
omap_pmic_late_init();
omap_voltage_late_init();
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 02/10] i2c: OMAP: Add DT support for i2c controller
Add initial DT support to retrieve the frequency using a
DT attribute instead of the pdata pointer if of_node exist.
Add documentation for omap i2c controller binding.
Based on original patches from Manju and Grant.
Signed-off-by: Benoit Cousson
Cc: Ben Dooks
---
Documentation/devicetree/bindings/i2c/omap-i2c.txt | 42
drivers/i2c/busses/i2c-omap.c | 100 +---
2 files changed, 107 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
diff --git a/Documentation/devicetree/bindings/i2c/omap-i2c.txt
b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
new file mode 100644
index 000..d259a17
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
@@ -0,0 +1,42 @@
+I2C for OMAP platforms
+
+Required properties :
+- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
+- ti,hwmods : Must be "i2c", n being the instance number (1-based)
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Recommended properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
+ the default 100 kHz frequency will be used.
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+- ti,flags : u32: settings or errata relative to the i2c
+0x1: OMAP_I2C_FLAG_NO_FIFO
+0x2: OMAP_I2C_FLAG_SIMPLE_CLOCK
+0x4: OMAP_I2C_FLAG_16BIT_DATA_REG
+0x8: OMAP_I2C_FLAG_RESET_REGS_POSTIDLE
+0x10: OMAP_I2C_FLAG_APPLY_ERRATA_I207
+0x20: OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK
+0x40: OMAP_I2C_FLAG_FORCE_19200_INT_CLK
+ Valid for ti,omap3-i2c only:
+0x80: OMAP_I2C_FLAG_BUS_SHIFT_1: 8 bits registers
+0x100: OMAP_I2C_FLAG_BUS_SHIFT_2: 16 bits registers
+
+Note: Current implementation will fetch base address, irq and dma
+from omap hwmod data base during device registration.
+Future plan is to migrate hwmod data base contents into device tree
+blob so that, all the required data will be used from device tree dts
+file.
+
+Examples :
+
+i2c1: i2c@0 {
+compatible = "ti,omap3-i2c";
+#address-cells = <1>;
+#size-cells = <0>;
+ti,hwmods = "i2c1";
+clock-frequency = <40>;
+ti,flags = <0x118>;
+};
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a43d002..b4a8eee 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -37,6 +37,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -182,7 +184,9 @@ struct omap_i2c_dev {
u32 latency;/* maximum mpu wkup latency */
void(*set_mpu_wkup_lat)(struct device *dev,
long latency);
- u32 speed; /* Speed of bus in Khz */
+ u32 speed; /* Speed of bus in kHz */
+ u32 dtrev; /* extra revision from DT */
+ u32 flags;
u16 cmd_err;
u8 *buf;
u8 *regs;
@@ -266,11 +270,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
- struct omap_i2c_bus_platform_data *pdata;
-
- pdata = dev->dev->platform_data;
-
- if (pdata->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
@@ -291,13 +291,10 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
- struct omap_i2c_bus_platform_data *pdata;
u16 iv;
- pdata = dev->dev->platform_data;
-
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (pdata->rev == OMAP_I2C_IP_VERSION_2)
+ if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
else
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
@@ -320,9 +317,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long timeout;
unsigned long internal_clk = 0;
struct clk *fclk;
- struct omap_i2c_bus_platform_data *pdata;
-
- pdata = dev->dev->platform_data;
if (dev->rev >= OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
@@ -373,7 +367,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
}
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- if (pdata->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
+
[PATCH v2 03/10] mfd: twl-core: Add initial DT support for twl4030/twl6030
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
platform_data information can be initialized properly.
Add documentation for the Texas Instruments TWL Integrated Chip.
Signed-off-by: Benoit Cousson
Cc: Balaji T K
Cc: Graeme Gregory
Cc: Samuel Ortiz
---
.../devicetree/bindings/mfd/twl-familly.txt| 47 +
drivers/mfd/twl-core.c | 53 ++--
2 files changed, 96 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt
b/Documentation/devicetree/bindings/mfd/twl-familly.txt
new file mode 100644
index 000..ff4cacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
@@ -0,0 +1,47 @@
+Texas Instruments TWL family
+
+The TWLs are Integrated Power Management Chips.
+Some version might contain much more analog function like
+USB transceiver or Audio amplifier.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be "ti,twl4030";
+ For Integrated power-management/audio CODEC device used in OMAP3
+ based boards
+- compatible : Must be "ti,twl6030";
+ For Integrated power-management used in OMAP4 based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the twl support several interrupts internally,
+ it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells = <1>;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the twl. The twl family is made of severals variants
+ that support a different number of features.
+ The children nodes will thus depend of the capabilty of the variant.
+
+
+Example:
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+twl@48 {
+compatible = "ti,twl6030";
+reg = <0x48>;
+interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+interrupt-controller;
+#interrupt-cells = <1>;
+interrupt-parent = <&gic>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+twl_rtc {
+compatible = "ti,twl_rtc";
+interrupts = <11>;
+reg = <0>;
+};
+};
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index bfbd660..524d9d8 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -34,6 +34,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
@@ -1183,22 +1187,53 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
int status;
unsignedi;
struct twl4030_platform_data*pdata = client->dev.platform_data;
+ struct device_node *node = client->dev.of_node;
u8 temp;
int ret = 0;
+ if (node && !pdata) {
+ /*
+* XXX: Temporary fake pdata until the information
+* is correctly retrieved by every TWL modules from DT.
+*/
+ pdata = kzalloc(sizeof(struct twl4030_platform_data),
+ GFP_KERNEL);
+ if (!pdata) {
+ status = -ENOMEM;
+ goto exit;
+ }
+
+ /*
+* XXX: For the moment the IRQs for TWL seems to be encoded in
+* the global OMAP space. That should be cleaned to allow
+* dynamically adding a new IRQ controller.
+*/
+ if ((id->driver_data) & TWL6030_CLASS) {
+ pdata->irq_base = TWL6030_IRQ_BASE;
+ pdata->irq_end = pdata->irq_base + TWL6030_BASE_NR_IRQS;
+ } else {
+ pdata->irq_base = TWL4030_IRQ_BASE;
+ pdata->irq_end = pdata->irq_base + TWL4030_BASE_NR_IRQS;
+ }
+ irq_domain_add_simple(node, pdata->irq_base);
+ }
+
if (!pdata) {
dev_dbg(&client->dev, "no platform data?\n");
- return -EINVAL;
+ status = -EINVAL;
+ goto fail_free;
}
if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) == 0) {
dev_dbg(&client->dev, "can't talk I2C?\n");
- return -EIO;
+ status = -EIO;
+ goto fail_free;
}
if (inuse) {
dev_dbg(&client->dev, "driver is already in use\n");
- return -EBUSY;
+ s
[PATCH v2 05/10] arm/dts: OMAP4: Add i2c controller nodes
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/omap4.dtsi | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bede009..9872283 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -100,5 +100,33 @@
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
+
+ i2c1: i2c@1 {
+ compatible = "ti,omap4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ };
+
+ i2c2: i2c@2 {
+ compatible = "ti,omap4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c2";
+ };
+
+ i2c3: i2c@3 {
+ compatible = "ti,omap4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c3";
+ };
+
+ i2c4: i2c@4 {
+ compatible = "ti,omap4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c4";
+ };
};
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 06/10] arm/dts: OMAP3: Add i2c controller nodes
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/omap3.dtsi | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6866dc7..81d8e2c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,5 +61,33 @@
ti,intc-size = <96>;
reg = <0x4820 0x1000>;
};
+
+ /*
+* Flags for all i2c instances: 0x118
+* APPLY_ERRATA_I207 | RESET_REGS_POSTIDLE | BUS_SHIFT_2
+*/
+ i2c1: i2c@1 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ ti,flags = <0x118>;
+ };
+
+ i2c2: i2c@2 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c2";
+ ti,flags = <0x118>;
+ };
+
+ i2c3: i2c@3 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c3";
+ ti,flags = <0x118>;
+ };
};
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 04/10] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Cousson
Cc: Alessandro Zummo
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12
drivers/rtc/rtc-twl.c | 10 --
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
new file mode 100644
index 000..596e0c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
@@ -0,0 +1,12 @@
+* TI twl RTC
+
+The TWL family (twl4030/6030) contains a RTC.
+
+Required properties:
+- compatible : Should be twl4030-rtc
+
+Examples:
+
+rtc@0 {
+compatible = "ti,twl4030-rtc";
+};
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 20687d5..d43b4f6 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -550,6 +550,11 @@ static int twl_rtc_resume(struct platform_device *pdev)
#define twl_rtc_resume NULL
#endif
+static const struct of_device_id twl_rtc_of_match[] = {
+ {.compatible = "ti,twl4030-rtc", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl_rtc_of_match);
MODULE_ALIAS("platform:twl_rtc");
static struct platform_driver twl4030rtc_driver = {
@@ -559,8 +564,9 @@ static struct platform_driver twl4030rtc_driver = {
.suspend= twl_rtc_suspend,
.resume = twl_rtc_resume,
.driver = {
- .owner = THIS_MODULE,
- .name = "twl_rtc",
+ .owner = THIS_MODULE,
+ .name = "twl_rtc",
+ .of_match_table = twl_rtc_of_match,
},
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 07/10] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
Update pandaboard dts file with required clock frequencies
for the i2c client devices existing on pandaboard.
Add the twl6030 node in i2c1 controller.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add a generic i2c EEPROM entry.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
---
arch/arm/boot/dts/omap4-panda.dts | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 9755ad5..b66bcd6 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -18,3 +18,48 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
};
+
+&i2c1 {
+ clock-frequency = <40>;
+
+ /*
+* Integrated Power Management Chip
+* http://www.ti.com/lit/ds/symlink/twl6030.pdf
+*/
+ twl@48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <40>;
+};
+
+&i2c3 {
+ clock-frequency = <10>;
+
+ /*
+* Display monitor features are burnt in their EEPROM as EDID data.
+* The EEPROM is connected as I2C slave device.
+*/
+ eeprom@50 {
+ compatible = "ti,eeprom";
+ reg = <0x50>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <40>;
+};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 08/10] arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
Update DTS file with required clock frequencies
for the i2c client devices existing on sdp4430.
Add the twl6030 node inside the i2c1 controller node.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add the RTC submodule inside the twl node.
Add tmp105 temperature sensor in i2c3
Add bh1780 Ambient Light Sensor in i2c3
Add hmc5843 3-Axis Digital Compass in i2c4
Signed-off-by: Benoit Cousson
Cc: Grant Likely
---
arch/arm/boot/dts/omap4-sdp.dts | 63 +++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 63c6b2b..0ab14cb 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -18,3 +18,66 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
};
+
+&i2c1 {
+ clock-frequency = <40>;
+
+ /*
+* Integrated Power Management Chip
+* http://www.ti.com/lit/ds/symlink/twl6030.pdf
+*/
+ twl@48 {
+ compatible = "ti,twl6030";
+ reg = <0x48>;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <40>;
+};
+
+&i2c3 {
+ clock-frequency = <40>;
+
+ /*
+* Temperature Sensor
+* http://www.ti.com/lit/ds/symlink/tmp105.pdf
+*/
+ tmp105@48 {
+ compatible = "ti,tmp105";
+ reg = <0x48>;
+ };
+
+ /*
+* Ambient Light Sensor
+* http://www.rohm.com/products/databook/sensor/pdf/bh1780gli-e.pdf
+*/
+ bh1780@29 {
+ compatible = "rohm,bh1780";
+ reg = <0x29>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <40>;
+
+ /*
+* 3-Axis Digital Compass
+* http://www.sparkfun.com/datasheets/Sensors/Magneto/HMC5843.pdf
+*/
+ hmc5843@1e {
+ compatible = "honeywell,hmc5843";
+ reg = <0x1e>;
+ };
+};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 09/10] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
Add required clock frequencies for the i2c client devices existing
on beagle board.
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/omap3-beagle.dts | 38
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 9f72cd4..b648279 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -18,3 +18,41 @@
reg = <0x8000 0x2000>; /* 512 MB */
};
};
+
+&i2c1 {
+ clock-frequency = <260>;
+
+ /*
+* Integrated Power Management Chip
+*/
+ twl@48 {
+ compatible = "ti,twl4030";
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&intc>;
+
+ twl_rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <40>;
+};
+
+&i2c3 {
+ clock-frequency = <10>;
+
+ /*
+* Display monitor features are burnt in the EEPROM
+* as EDID data.
+*/
+ eeprom@50 {
+ compatible = "ti,eeprom";
+ reg = <0x50>;
+ };
+};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 10/10] ARM: OMAP2+: board-generic: Remove i2c static init
This mainly reverts the commit that was adding the i2c static init.
Since the i2c and twl nodes are now present, there is no need
for the static initialization anymore.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-generic.c | 48 +-
1 files changed, 2 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 16c301e..63a2495 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
@@ -36,34 +35,6 @@ static void __init omap_init_irq(void)
of_irq_init(irq_match);
}
-/*
- * XXX: Still needed to boot until the i2c & twl driver is adapted to
- * device-tree
- */
-#ifdef CONFIG_ARCH_OMAP4
-static struct twl4030_platform_data sdp4430_twldata = {
- .irq_base = TWL6030_IRQ_BASE,
- .irq_end= TWL6030_IRQ_END,
-};
-
-static void __init omap4_i2c_init(void)
-{
- omap4_pmic_init("twl6030", &sdp4430_twldata);
-}
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct twl4030_platform_data beagle_twldata = {
- .irq_base = TWL4030_IRQ_BASE,
- .irq_end= TWL4030_IRQ_END,
-};
-
-static void __init omap3_i2c_init(void)
-{
- omap3_pmic_init("twl4030", &beagle_twldata);
-}
-#endif
-
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = "simple-bus", },
{ .compatible = "ti,omap-infra", },
@@ -78,21 +49,6 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
-#ifdef CONFIG_ARCH_OMAP4
-static void __init omap4_init(void)
-{
- omap4_i2c_init();
- omap_generic_init();
-}
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static void __init omap3_init(void)
-{
- omap3_i2c_init();
- omap_generic_init();
-}
-#endif
#ifdef CONFIG_SOC_OMAP2420
static const char *omap242x_boards_compat[] __initdata = {
@@ -145,7 +101,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device
Tree)")
.init_early = omap3430_init_early,
.init_irq = omap_init_irq,
.handle_irq = omap3_intc_handle_irq,
- .init_machine = omap3_init,
+ .init_machine = omap_generic_init,
.timer = &omap3_timer,
.dt_compat = omap3_boards_compat,
MACHINE_END
@@ -164,7 +120,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device
Tree)")
.init_early = omap4430_init_early,
.init_irq = omap_init_irq,
.handle_irq = gic_handle_irq,
- .init_machine = omap4_init,
+ .init_machine = omap_generic_init,
.timer = &omap4_timer,
.dt_compat = omap4_boards_compat,
MACHINE_END
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/5] ARM: OMAP2+: Interrupt controllers adaptation to DT
Hi Tony and Rob, Here is the series to take advantage of the new DT interrupt init mechanism. Thanks to Marc's CONFIG_MULTI_IRQ_HANDLER series, OMAP4 just has to use the default GIC binding and does not need some OMAP specific hacks anymore. OMAP2 and 3 are using a simple interrupt controller that can thus expose a simpler binding. This update, compared to v1 [1], is introducing the IRQ domain for the OMAP2&3 INTC by default for both DT and none-DT build. Please note that in the near future that code can even be simplier with the introduction of the domain support inside generic irq chip. This series is based on lo/dt branch to get the needed cleanup and fixes for OMAP. The series is available here for reference: git://gitorious.org/omap-pm/linux.git for_3.3/2_dt_irq Regards, Benoit [1] http://www.spinics.net/lists/linux-omap/msg61152.html Benoit Cousson (5): arm/dts: OMAP4: Update DTS file with new GIC bindings ARM: OMAP2/3: intc: Add irqdomain support ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC ARM: OMAP2+: board-generic: Use of_irq_init API .../devicetree/bindings/arm/omap/intc.txt | 27 +++ arch/arm/boot/dts/omap3.dtsi |6 ++- arch/arm/boot/dts/omap4.dtsi |3 +- arch/arm/mach-omap2/board-generic.c| 30 +++-- arch/arm/mach-omap2/common.h | 10 arch/arm/mach-omap2/irq.c | 48 ++-- 6 files changed, 103 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/5] ARM: OMAP2/3: intc: Add irqdomain support
Introduce the usage of the irqdomain to prepare the DT support.
The irq_base is still hard coded to 0 to allow non-DT drivers
to work with the previous assumption that was hwirq = irq.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
Cc: Rob Herring
---
arch/arm/mach-omap2/irq.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 42b1d65..2f65dfd 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
/* selected INTC register offsets */
@@ -57,6 +58,8 @@ static struct omap_irq_bank {
},
};
+static struct irq_domain domain;
+
/* Structure to save interrupt controller context */
struct omap3_intc_regs {
u32 sysconfig;
@@ -158,6 +161,17 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
if (WARN_ON(!omap_irq_base))
return;
+ /*
+* XXX: Use a 0 irq_base for the moment since the legacy devices
+* created statically are expected a hwirq = irq mapping.
+* A proper offset will be added later, when IRQ resource creation
+* will be handled by DT.
+*/
+ domain.irq_base = 0;
+ domain.nr_irq = nr_irqs;
+ domain.ops = &irq_domain_simple_ops;
+ irq_domain_add(&domain);
+
for (i = 0; i < ARRAY_SIZE(irq_banks); i++) {
struct omap_irq_bank *bank = irq_banks + i;
@@ -225,8 +239,10 @@ out:
irqnr = readl_relaxed(base_addr + INTCPS_SIR_IRQ_OFFSET);
irqnr &= ACTIVEIRQ_MASK;
- if (irqnr)
+ if (irqnr) {
+ irqnr = irq_domain_to_irq(&domain, irqnr);
handle_IRQ(irqnr, regs);
+ }
} while (irqnr);
}
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/5] arm/dts: OMAP4: Update DTS file with new GIC bindings
The GIC binding was updated in 3.2 and expect 3 interrupt-cells.
- Update the #interrupt-cells
- interrupt-parent seems to be needed as well for the top level GIC
Signed-off-by: Benoit Cousson
Cc: Rob Herring
---
arch/arm/boot/dts/omap4.dtsi |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..bede009 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -95,7 +95,8 @@
gic: interrupt-controller@48241000 {
compatible = "arm,cortex-a9-gic";
interrupt-controller;
- #interrupt-cells = <1>;
+ interrupt-parent;
+ #interrupt-cells = <3>;
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/5] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller
Add a function to initialize the OMAP2/3 interrupt controller (INTC)
using a device tree node.
Replace some printk() with the proper pr_ macro.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
Cc: Rob Herring
---
.../devicetree/bindings/arm/omap/intc.txt | 27 ++
arch/arm/mach-omap2/common.h | 10 ++
arch/arm/mach-omap2/irq.c | 30 ++--
3 files changed, 64 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt
b/Documentation/devicetree/bindings/arm/omap/intc.txt
new file mode 100644
index 000..f2583e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/intc.txt
@@ -0,0 +1,27 @@
+* OMAP Interrupt Controller
+
+OMAP2/3 are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ "ti,omap2-intc"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller@1 {
+ compatible = "ti,omap2-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ ti,intc-size = <96>;
+ reg = <0x4820 0x1000>;
+ };
+
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 012bac7..bcfccc2 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -156,6 +156,16 @@ void omap3_intc_resume_idle(void);
void omap2_intc_handle_irq(struct pt_regs *regs);
void omap3_intc_handle_irq(struct pt_regs *regs);
+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent);
+#else
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ return 0;
+}
+#endif
+
/*
* wfi used in low power code. Directly opcode is used instead
* of instruction to avoid mulit-omap build break
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 2f65dfd..f3722b1 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
/* selected INTC register offsets */
@@ -180,7 +182,7 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
/* Static mapping, never released */
bank->base_reg = ioremap(base, SZ_4K);
if (!bank->base_reg) {
- printk(KERN_ERR "Could not ioremap irq bank%i\n", i);
+ pr_err("Could not ioremap irq bank%i\n", i);
continue;
}
@@ -193,8 +195,8 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
nr_banks++;
}
- printk(KERN_INFO "Total of %ld interrupts on %d active controller%s\n",
- nr_of_irqs, nr_banks, nr_banks > 1 ? "s" : "");
+ pr_info("Total of %ld interrupts on %d active controller%s\n",
+ nr_of_irqs, nr_banks, nr_banks > 1 ? "s" : "");
}
void __init omap2_init_irq(void)
@@ -252,6 +254,28 @@ asmlinkage void __exception_irq_entry
omap2_intc_handle_irq(struct pt_regs *regs
omap_intc_handle_irq(base_addr, regs);
}
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ struct resource res;
+ u32 nr_irqs = 96;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_address_to_resource(node, 0, &res)) {
+ WARN(1, "unable to get intc registers\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, "ti,intc-size", &nr_irqs))
+ pr_warn("unable to get intc-size, default to %d\n", nr_irqs);
+
+ omap_init_irq(res.start, nr_irqs);
+ domain.of_node = of_node_get(node);
+
+ return 0;
+}
+
#ifdef CONFIG_ARCH_OMAP3
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/5] arm/dts: OMAP3: Add interrupt-controller bindings for INTC
Update the DTS with the proper information required by the
INTC bindings.
- Add the number of interrupt lines
- Add the reg and the compatible entries.
Signed-off-by: Benoit Cousson
Cc: Rob Herring
---
arch/arm/boot/dts/omap3.dtsi |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..6866dc7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -54,10 +54,12 @@
ranges;
ti,hwmods = "l3_main";
- intc: interrupt-controller@1 {
- compatible = "ti,omap3-intc";
+ intc: interrupt-controller@4820 {
+ compatible = "ti,omap2-intc";
interrupt-controller;
#interrupt-cells = <1>;
+ ti,intc-size = <96>;
+ reg = <0x4820 0x1000>;
};
};
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 5/5] ARM: OMAP2+: board-generic: Use of_irq_init API
Use the of_irq_init API introduced in 3.2 to handle
interrupt-controller with DT.
Update the irq_match table to map the proper XXX_of_init
functions for INTC and GIC drivers.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
Cc: Rob Herring
---
arch/arm/mach-omap2/board-generic.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e493877..2529017 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -12,6 +12,7 @@
* published by the Free Software Foundation.
*/
#include
+#include
#include
#include
#include
@@ -24,6 +25,17 @@
#include "common.h"
#include "common-board-devices.h"
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = "ti,omap2-intc", .data = intc_of_init, },
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ { }
+};
+
+static void __init omap_init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+
/*
* XXX: Still needed to boot until the i2c & twl driver is adapted to
* device-tree
@@ -58,18 +70,8 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
-static struct of_device_id intc_match[] __initdata = {
- { .compatible = "ti,omap3-intc", },
- { .compatible = "arm,cortex-a9-gic", },
- { }
-};
-
static void __init omap_generic_init(void)
{
- struct device_node *node = of_find_matching_node(NULL, intc_match);
- if (node)
- irq_domain_add_simple(node, 0);
-
omap_serial_init();
omap_sdrc_init(NULL, NULL);
@@ -103,7 +105,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened
Device Tree)")
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = &omap2_timer,
@@ -122,7 +124,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened
Device Tree)")
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = &omap2_timer,
@@ -141,7 +143,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device
Tree)")
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
- .init_irq = omap3_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap3_init,
.timer = &omap3_timer,
@@ -160,7 +162,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device
Tree)")
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = gic_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = gic_handle_irq,
.init_machine = omap4_init,
.timer = &omap4_timer,
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 00/11] OMAP4: Add DT support for i2c and twl6030
Hi Tony and Rob, Here is the updated version of the i2c + twl DT adaptation series. This update, compared to v2 [1], is adding some dedicated dtsi files for the twl PMIC and audio IC. These devices will contain a huge amount of regulator nodes and thus deserve a dedicated file to avoid every boards to redefine the same data. The twl patch is now included in Samuel's for-next branch and thus dropped from this update. The i2c binding was cleaned as suggested by Rob to avoid all the ugly hexa flags inside the DTS. The pm.c was updated to prevent the SR / VP initialization in the DT context since none of them is DT aware for the moment. A couple of basic i2c devices are added for panda, beagle and sdp board. Patches are based on for_3.3/2_dt_irq, to get the latest GIC binding, and are available here: git://gitorious.org/omap-pm/linux.git for_3.3/3_omap_dt_i2c_twl Tested on Beagle and sdp4430. Comments are welcome. Regards, Benoit [1] http://www.spinics.net/lists/linux-omap/msg61260.html Benoit Cousson (11): ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT i2c: OMAP: Add DT support for i2c controller rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030 arm/dts: OMAP4: Add i2c controller nodes arm/dts: OMAP3: Add i2c controller nodes arm/dts: twl6030: Add DTS file for twl6030 PMIC arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC arm/dts: omap4-panda: Add twl6030 and i2c EEPROM arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM ARM: OMAP2+: board-generic: Remove i2c static init Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++ Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12 +++ arch/arm/boot/dts/omap3-beagle.dts | 29 ++ arch/arm/boot/dts/omap3.dtsi | 21 arch/arm/boot/dts/omap4-panda.dts | 34 +++ arch/arm/boot/dts/omap4-sdp.dts| 53 ++ arch/arm/boot/dts/omap4.dtsi | 28 ++ arch/arm/boot/dts/twl4030.dtsi | 21 arch/arm/boot/dts/twl6030.dtsi | 22 arch/arm/mach-omap2/board-generic.c| 48 +- arch/arm/mach-omap2/pm.c |8 ++ drivers/i2c/busses/i2c-omap.c | 101 +--- drivers/rtc/rtc-twl.c | 10 ++- 13 files changed, 334 insertions(+), 83 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt create mode 100644 arch/arm/boot/dts/twl4030.dtsi create mode 100644 arch/arm/boot/dts/twl6030.dtsi ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 01/11] ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT
In the case of DT, the PMIC and SR initialization will be done using
a completely different mechanism.
Disable this part if a DT blob is available.
Signed-off-by: Benoit Cousson
Acked-by: Kevin Hilman
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..ad4f693 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -227,6 +227,14 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
+ /*
+* In the case of DT, the PMIC and SR initialization will be done using
+* a completely different mechanism.
+* Disable this part if a DT blob is available.
+*/
+ if (of_have_populated_dt())
+ return 0;
+
/* Init the voltage layer */
omap_pmic_late_init();
omap_voltage_late_init();
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 04/11] arm/dts: OMAP4: Add i2c controller nodes
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/omap4.dtsi | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bede009..9872283 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -100,5 +100,33 @@
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
+
+ i2c1: i2c@1 {
+ compatible = "ti,omap4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ };
+
+ i2c2: i2c@2 {
+ compatible = "ti,omap4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c2";
+ };
+
+ i2c3: i2c@3 {
+ compatible = "ti,omap4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c3";
+ };
+
+ i2c4: i2c@4 {
+ compatible = "ti,omap4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c4";
+ };
};
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 05/11] arm/dts: OMAP3: Add i2c controller nodes
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/omap3.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6866dc7..697b210 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,5 +61,26 @@
ti,intc-size = <96>;
reg = <0x4820 0x1000>;
};
+
+ i2c1: i2c@1 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c1";
+ };
+
+ i2c2: i2c@2 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c2";
+ };
+
+ i2c3: i2c@3 {
+ compatible = "ti,omap3-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "i2c3";
+ };
};
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 03/11] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Cousson
Cc: Alessandro Zummo
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12
drivers/rtc/rtc-twl.c | 10 --
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
new file mode 100644
index 000..596e0c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
@@ -0,0 +1,12 @@
+* TI twl RTC
+
+The TWL family (twl4030/6030) contains a RTC.
+
+Required properties:
+- compatible : Should be twl4030-rtc
+
+Examples:
+
+rtc@0 {
+compatible = "ti,twl4030-rtc";
+};
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 20687d5..d43b4f6 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -550,6 +550,11 @@ static int twl_rtc_resume(struct platform_device *pdev)
#define twl_rtc_resume NULL
#endif
+static const struct of_device_id twl_rtc_of_match[] = {
+ {.compatible = "ti,twl4030-rtc", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl_rtc_of_match);
MODULE_ALIAS("platform:twl_rtc");
static struct platform_driver twl4030rtc_driver = {
@@ -559,8 +564,9 @@ static struct platform_driver twl4030rtc_driver = {
.suspend= twl_rtc_suspend,
.resume = twl_rtc_resume,
.driver = {
- .owner = THIS_MODULE,
- .name = "twl_rtc",
+ .owner = THIS_MODULE,
+ .name = "twl_rtc",
+ .of_match_table = twl_rtc_of_match,
},
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 07/11] arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC
Add a dedicated DTS file for the twl4030/5030 Power + Audio IC.
This chip is a big SoC that will be reused in a lot of various
OMAP3 boards.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/twl4030.dtsi
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
new file mode 100644
index 000..8be5223
--- /dev/null
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2011 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.
+ */
+
+/*
+ * Integrated Power Management Chip
+ */
+&twl {
+ compatible = "ti,twl4030";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 08/11] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
Update pandaboard dts file with required clock frequencies
for the i2c client devices existing on pandaboard.
Add the twl6030 node in i2c1 controller.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add a generic i2c EEPROM entry.
Signed-off-by: Benoit Cousson
Cc: Grant Likely
---
arch/arm/boot/dts/omap4-panda.dts | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 9755ad5..29646dc 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -18,3 +18,37 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
};
+
+&i2c1 {
+ clock-frequency = <40>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-parent = <&gic>;
+ };
+};
+
+/include/ "twl6030.dtsi"
+
+&i2c2 {
+ clock-frequency = <40>;
+};
+
+&i2c3 {
+ clock-frequency = <10>;
+
+ /*
+* Display monitor features are burnt in their EEPROM as EDID data.
+* The EEPROM is connected as I2C slave device.
+*/
+ eeprom@50 {
+ compatible = "ti,eeprom";
+ reg = <0x50>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <40>;
+};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 06/11] arm/dts: twl6030: Add DTS file for twl6030 PMIC
Add a dedicated DTS file for the twl6030 Power IC.
This chip is a big SoC that will be reused in a lot of various
OMAP4+ boards.
Note: This file is supposed to be included in a board DTS that will
create the twl node in order to allow the &twl reference to work.
Exmaple:
...
&i2c1 {
twl: twl@48 {
reg = <0x48>;
interrupts = <0 7 4>;
interrupt-controller;
interrupt-parent = <&gic>;
};
};
/include/ "twl6030.dtsi"
...
Signed-off-by: Benoit Cousson
Cc: Grant Likely
Cc: Rob Herring
---
arch/arm/boot/dts/twl6030.dtsi | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/twl6030.dtsi
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
new file mode 100644
index 000..b7b4e5e
--- /dev/null
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2011 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.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+&twl {
+ compatible = "ti,twl6030";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ rtc {
+ compatible = "ti,twl4030-rtc";
+ interrupts = <11>;
+ };
+};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 09/11] arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
Update DTS file with required clock frequencies
for the i2c client devices existing on sdp4430.
Add the twl6030 node inside the i2c1 controller node.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add the RTC submodule inside the twl node.
Add tmp105 temperature sensor in i2c3
Add bh1780 Ambient Light Sensor in i2c3
Add hmc5843 3-Axis Digital Compass in i2c4
Signed-off-by: Benoit Cousson
Cc: Grant Likely
---
arch/arm/boot/dts/omap4-sdp.dts | 53 +++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 63c6b2b..17e829a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -18,3 +18,56 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
};
+
+&i2c1 {
+ clock-frequency = <40>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-parent = <&gic>;
+ };
+};
+
+/include/ "twl6030.dtsi"
+
+&i2c2 {
+ clock-frequency = <40>;
+ reg = <0x48072000 0x100>, <0x48072100 0x100>, <0x48072200 0x100>;
+};
+
+&i2c3 {
+ clock-frequency = <40>;
+
+ /*
+* Temperature Sensor
+* http://www.ti.com/lit/ds/symlink/tmp105.pdf
+*/
+ tmp105@48 {
+ compatible = "ti,tmp105";
+ reg = <0x48>;
+ };
+
+ /*
+* Ambient Light Sensor
+* http://www.rohm.com/products/databook/sensor/pdf/bh1780gli-e.pdf
+*/
+ bh1780@29 {
+ compatible = "rohm,bh1780";
+ reg = <0x29>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <40>;
+
+ /*
+* 3-Axis Digital Compass
+* http://www.sparkfun.com/datasheets/Sensors/Magneto/HMC5843.pdf
+*/
+ hmc5843@1e {
+ compatible = "honeywell,hmc5843";
+ reg = <0x1e>;
+ };
+};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
