Re: [PATCH 0/5] AM33xx: MMC resources from DT without HWMOD data
Hi Joel, On 06/26/2013 05:28 AM, Joel A Fernandes wrote: On Tue, Jun 25, 2013 at 8:23 PM, Joel A Fernandes joelag...@ti.com wrote: From: Joel A Fernandes agnel.j...@gmail.com This series is fixes to get MMC working on AM33XX without HWMOD data. On removal of HWMOD data, interrupt and register properties need to be provided for the driver to function correctly. Please don't pull patches authored by me in this series. I have posted them with my wrong email address by mistake. I will correct my email during the next repost, after a round of review. Matt's patches in the series are still good though. In that case, please repost these in two series to avoid pulling the DTS files in the MMC tree. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: Protect pinctrl headers against multiple inclusions
Hi Florian, On 06/19/2013 04:28 AM, Florian Vaussard wrote: Hello Benoit, On 06/12/2013 06:18 PM, Cousson, Benoit wrote: Hi Florian, On 6/12/2013 8:42 AM, Florian Vaussard wrote: Hello Grant, On 06/11/2013 11:57 PM, Grant Likely wrote: On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard florian.vauss...@epfl.ch wrote: Pinctrl headers were not protected with #ifndef. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Obviously this needs to go in via whatever tree added the modified header files. I authored these files, sorry for this stupid omission. Benoit, can you take this patch? Yes, sure, I'll take it with Grant's ack. I think that you missed this one. In was in the pipe but not pushed yet. That will be done soon. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] ARM: dts: OMAP3: Updates for Overo
On 06/19/2013 04:29 AM, Florian Vaussard wrote: Hello Benoit, Any comments on this series? That series looks good to me. I've just applied it. Thanks, Benoit Regards, Florian On 06/11/2013 04:49 PM, Florian Vaussard wrote: Hello, This series performs several updates to omap3-overo and omap3-tobi. Patch 1 is necessary to patch 2 for the IRQ constant. The SMSC911X is largely taken from omap3-igep. Regards, Florian Florian Vaussard (4): ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED arch/arm/boot/dts/omap3-overo.dtsi |1 + arch/arm/boot/dts/omap3-tobi.dts | 50 +++- arch/arm/boot/dts/omap3.dtsi |1 + 3 files changed, 51 insertions(+), 1 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] Add pinmux DT nodes to CPSW for AM335x
On 06/19/2013 12:53 AM, Mugunthan V N wrote: On 6/7/2013 5:02 PM, Mugunthan V N wrote: Add pinmux DT nodes to CPSW for the following AM335x boards * AM335x Beaglebone * AM335x EVM * AM335x EVMsk default state contains the pinmux required for active mode and sleep mode contains pinmux reset values for energy saving. Mugunthan V N (3): ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM arch/arm/boot/dts/am335x-bone.dts | 67 ++ arch/arm/boot/dts/am335x-evm.dts | 64 + arch/arm/boot/dts/am335x-evmsk.dts | 92 3 files changed, 223 insertions(+) Benoit Do you have any comments on this patch series, if not can you queue it for v3.11 The series looks good to me. I've just applied it. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to
abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my
point of view. pinctrl can handle pin configuration and this is what the
pbias is in the case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep
doing that :-)
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using
the regulator in the future for controlling a gpio line.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] arm: add bandgap DT entry for OMAP5
Hi Eduardo,
On 06/18/2013 09:36 PM, Eduardo Valentin wrote:
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 8
1 file changed, 8 insertions(+)
---
Benoit,
Sorry for this very late request, but can you please consider
these patches for 3.11 still?
I completely forgot to send these on my Enable TI SoC thermal driver series.
All best,
Eduardo
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2ad63c4..5ede6e1 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -615,5 +615,13 @@
interrupts = 0 80 0x4;
ti,hwmods = wd_timer2;
};
missing blank line
+ bandgap {
You must use the first address in that case. Otherwise DT will affect a random
number and provide a non-standard device name. That does not really matter in
theory, but it will looks ugly in the /sys/devices list.
+ reg = 0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c;
+ interrupts = 0 126 4; /* talert */
Not well aligned and should use the macros.
+ compatible = ti,omap5430-bandgap;
+ };
};
};
I did the update for you :-)
Here is the version I've just applied.
Benoit
From f0160bb93467e22f2f8bc77591dcd7e35cdee999 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin eduardo.valen...@ti.com
Date: Tue, 18 Jun 2013 22:36:38 -0400
Subject: [PATCH] ARM: dts: Add bandgap DT entry for OMAP5
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Benoit Cousson benoit.cous...@linaro.org
---
arch/arm/boot/dts/omap5.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index accab62..47693c9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -696,5 +696,14 @@
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
};
};
+
+ bandgap@4a0021e0 {
+ reg = 0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c;
+ interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
+ compatible = ti,omap5430-bandgap;
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: AM43x EPOS EVM support
Hi Afzal,
On 06/14/2013 09:03 AM, Afzal Mohammed wrote:
Add AM43x ePOS EVM minimal DT source - this is a minimal one to get
it booting. Also include it in omap2plus dtbs and document bindings.
The hardware is under development.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi Benoit,
This is based on your for_3.11/dts branch.
Ideally I wanted to split this into 3 patches - first doc, second dts
and last adding build support. As changes in total is trivial, it was
made a single one.
That's fine for me. I've just applied it.
Thanks,
Benoit
Regards
Afzal
Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/am43x-epos-evm.dts| 18 ++
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am43x-epos-evm.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f8288ea..6d498c7 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -56,3 +56,6 @@ Boards:
- OMAP5 EVM : Evaluation Module
compatible = ti,omap5-evm, ti,omap5
+
+- AM43x EPOS EVM
+ compatible = ti,am43x-epos-evm, ti,am4372, ti,am43
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e50761..05da469 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -155,7 +155,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
- am3517_mt_ventoux.dtb
+ am3517_mt_ventoux.dtb \
+ am43x-epos-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
new file mode 100644
index 000..74174d4
--- /dev/null
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2013 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.
+ */
+
+/* AM43x EPOS EVM */
+
+/dts-v1/;
+
+#include am4372.dtsi
+
+/ {
+ model = TI AM43x EPOS EVM;
+ compatible = ti,am43x-epos-evm,ti,am4372,ti,am43;
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 06:03 AM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to abuse
the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks. Since there
is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
Well, at that time, it was not available either. The point is still that
using a existing fmwk that has nothing to do with the signal you need to
handle just because it works is not a very good justification.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
Yes gpio is possible. But then you need to add additional code in the driver to
parse GPIO number and polarity.
Using regulator_get() was plain simple for me.
Maybe, but it is not the right thing to do.
Can you explain me the commonality between a reset line and a regulator???
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my point of
view. pinctrl can handle pin configuration and this is what the pbias is in the
case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep doing
that :-)
I had actually thought it well and don't consider it as a mistake. It is just a
difference in opinion.
Well, I don't think so. Again, you are abusing the regulator fmwk to
enable at boot time a GPIO line that should reset the IP. I doubt the
regulator fmwk was done for that. Otherwise Mark would have named it
miscellaneous fmwk or regulator reset fmwk.
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using the
regulator in the future for controlling a gpio line.
I can re-work the phy driver. No problem. But I'm still not convinced
what it will improve. IMHO it just adds more code in the phy driver without any
benefits.
Yes, it will. It will give explicitly the reset control to the driver
that knows and needs it. Moreover, it will avoid abusing a fmwk that was
not done for that purpose.
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: omap4-panda: Add USB Host support
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator
was not the right fmwk to do that :-)
Thanks for the pointer Florian.
I guess that series should be merged for 3.11? Based on the thread, it
should to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is
possible, you should try. Otherwise, just keep the existing one, adding
that a new solution will be available soon as a disclaimer.
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: omap4-panda: Add USB Host support
Hi Tony, On 06/19/2013 07:27 AM, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [130619 03:17]: On 06/19/2013 02:46 AM, Tony Lindgren wrote: We have a similar issue with the MMC1 PBIAS. I think in the long run we should expand regulator (and possibly pinctrl) framework(s) to handle comparators. We could just assume that a comparatator is a regulator, and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. In the case of pbias, the boundary is not that clear, and it is true that writing a complete pinctrl driver is really overkill. I've tried in the past, and gave up due to the complexity of fmwk and the lack of time. I still think, it is a much better fmwk to handle pin configuration than the regulator fmwk. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. Well, in that case, this is a reset line, so it does not have anything to do with voltage :-) Anyway, thanks to Florian, we know that there is a real solution to that problem. It is just not merged now :-( 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: omap4-panda: Add USB Host support
On 06/19/2013 09:05 AM, Roger Quadros wrote:
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was not
the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it should
to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is possible,
you should try. Otherwise, just keep the existing one, adding that a new
solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
OK, sounds good.
Thanks,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 09:05 AM, Roger Quadros wrote:
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was not
the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it should
to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is possible,
you should try. Otherwise, just keep the existing one, adding that a new
solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
OK, I've just done it myself while applying your series.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3 4/6] arm: dts: add bandgap entry for OMAP4460 devices
Hi Eduardo,
On 06/18/2013 03:16 PM, Eduardo Valentin wrote:
Benoit
On 07-06-2013 16:46, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Could you please have a look on patch 3 and 4 of this series? I have
changed this one accordingly to your recommendation on v2. If nothing
else, please let me know if they can still be queued for 3.11.
I've just applied both of them in my tree for 3.11. I'll send the pull
request to Tony tomorrow.
Regards,
Benoit
I would need to rebase patch 01 to refresh on top of the thermal tree.
Thanks.
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..ea97201 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
0 55 0x4;
ti,hwmods = debugss;
};
+
+ bandgap {
+ reg = 0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18;
+ compatible = ti,omap4460-bandgap;
+ interrupts = 0 126 4; /* talert */
+ gpios = gpio3 22 0; /* tshut */
+ };
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62 +
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio2 30 0; /* gpio_62 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
If this is the case, I don't think it should be represented as a regulator.
Regards,
Benoit
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0; /* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ /**
+* FIXME:
+* put the right clock phandle here when available
+* clocks = auxclk3;
+* clock-names = main_clk;
+*/
+ clock-frequency = 1920;
+ };
};
omap4_pmx_wkup {
@@ -83,6 +119,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6030_pins: pinmux_twl6030_pins {
@@ -133,6 +170,23 @@
;
};
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_clk.usbb1_ulpiphy_clk */
+ 0x84 (PIN_OUTPUT | MUX_MODE4) /*
usbb1_ulpitll_stp.usbb1_ulpiphy_stp */
+ 0x86 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dir.usbb1_ulpiphy_dir */
+ 0x88 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt */
+ 0x8a (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 */
+ 0x8c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 */
+ 0x8e (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 */
+ 0x90 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 */
+ 0x92 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 */
+ 0x94 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 */
+ 0x96 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 */
+ 0x98 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 */
+ ;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins =
0xe2 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_scl */
@@ -283,3 +337,11 @@
mode = 3;
power = 50;
};
+
+usbhshost {
+ port1-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy;
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/10/2013 06:03 AM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-discuss@lists.ozlabs.org;
linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that it
makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by including
those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this regulator
due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom .dtsi file
for a board+pmic combination? Or have only the required properties over ridden
in the board file?
Yes, you can do that potentially if most OMAP5 boards will reuse the
same kind of settings. Kevin has just done that for OMAP3 + twl4030.
In this case, since we do have only one board, I'm not sure it worth the
effort.
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: Rename omap5-evm to omap5-uevm
Hi Sricharan,
On 06/06/2013 07:48 PM, Sricharan R wrote:
The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.
OK, so in fact you are not just renaming the board file, you are using
the previous board EVM DTS to describe a completely different board.
You are recycling the old non supported EVM.
You should update the subject and changelog to reflect that, because
that's rather confusing.
* There are no devices connected on I2C 2,3,4 buses. So remove
the pinmux data for the same.
* DDR3 memory is used in the uevm. Neither DVFS or temperature
polling is supported with DDR3. So remove the DDR3 device and
emif nodes.
You should explain why. I don't think this is obvious for people outside TI.
Regards,
Benoit
* Keypad is not supported on uevm. So remove the device node.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/Makefile |2 +-
.../arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} | 83
+---
2 files changed, 4 insertions(+), 81 deletions(-)
rename arch/arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} (73%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..13b86bf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -149,7 +149,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
- omap5-evm.dtb \
+ omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb
diff --git a/arch/arm/boot/dts/omap5-evm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
similarity index 73%
rename from arch/arm/boot/dts/omap5-evm.dts
rename to arch/arm/boot/dts/omap5-uevm.dts
index 22e9ee8..843a001 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2013 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
@@ -8,11 +8,10 @@
/dts-v1/;
#include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
/ {
- model = TI OMAP5 EVM board;
- compatible = ti,omap5-evm, ti,omap5;
+ model = TI OMAP5 uEVM board;
+ compatible = ti,omap5-uevm, ti,omap5;
memory {
device_type = memory;
@@ -88,27 +87,6 @@
;
};
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins =
- 0x178 (PIN_INPUT | MUX_MODE0) /* i2c2_scl */
- 0x17a (PIN_INPUT | MUX_MODE0) /* i2c2_sda */
- ;
- };
-
- i2c3_pins: pinmux_i2c3_pins {
- pinctrl-single,pins =
- 0x13a (PIN_INPUT | MUX_MODE0) /* i2c3_scl */
- 0x13c (PIN_INPUT | MUX_MODE0) /* i2c3_sda */
- ;
- };
-
- i2c4_pins: pinmux_i2c4_pins {
- pinctrl-single,pins =
- 0xb8 (PIN_INPUT | MUX_MODE0)/* i2c4_scl */
- 0xba (PIN_INPUT | MUX_MODE0)/* i2c4_sda */
- ;
- };
-
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins =
0x184 (PIN_INPUT | MUX_MODE0) /* i2c5_scl */
@@ -175,39 +153,6 @@
clock-frequency = 40;
};
-i2c2 {
- pinctrl-names = default;
- pinctrl-0 = i2c2_pins;
-
- clock-frequency = 40;
-
- /* Pressure Sensor */
- bmp085@77 {
- compatible = bosch,bmp085;
- reg = 0x77;
- };
-};
-
-i2c3 {
- pinctrl-names = default;
- pinctrl-0 = i2c3_pins;
-
- clock-frequency = 40;
-};
-
-i2c4 {
- pinctrl-names = default;
- pinctrl-0 = i2c4_pins;
-
- clock-frequency = 40;
-
- /* Temperature Sensor */
- tmp102@48{
- compatible = ti,tmp102;
- reg = 0x48;
- };
-};
-
i2c5 {
pinctrl-names = default;
pinctrl-0 = i2c5_pins;
@@ -215,32 +160,10 @@
clock-frequency = 40;
};
-keypad {
- keypad,num-rows = 8;
- keypad,num-columns = 8;
- linux,keymap = 0x02020073 /* VOLUP */
- 0x02030072 /* VOLDOWM */
- 0x020400e7 /* SEND */
- 0x02050066 /* HOME */
- 0x0206006b /* END */
- 0x020700d9;/* SEARCH */
- linux,input-no-autorepeat;
-};
-
mcbsp3 {
status = disabled;
};
-emif1 {
- cs1-used;
- device-handle = samsung_K3PE0E000B;
-};
-
-emif2 {
- cs1-used;
-
Re: [PATCH V2 0/4] ARM: dts: omap5: Cleanup and updates for DT files
On 06/06/2013 07:48 PM, Sricharan R wrote: uevm is the official board supported for OMAP5 soc in the mainline. This series renames the board dts file for OMAP5 accordingly and cleans up the same. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Could you update your branch before reposting, I pulled a Makefile fix for AM5xx that prevents your patches to be applied properly. Thanks, Benoit Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Rename omap5-evm to omap5-uevm arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
It looks like the board node to use palmas is missing? I cannot find it
in the previous series as well?
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
arch/arm/boot/dts/palmas.dtsi | 171
+
1 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..be631b5
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) 2013 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.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
The I2C address should be there as well. We used to put it in the board
file, but this is really an I2C device specific information and not
board specific in that case.
Regards,
Benoit
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+
Re: [PATCH V3 0/4] ARM: dts: omap5: Cleanup and updates for DT files
Thanks for the quick update. I've just applied the series in my for_3.11/dts branch. Regards, Benoit On 06/07/2013 03:22 PM, Sricharan R wrote: uevm is the only official board supported for OMAP5 soc in the mainline. This series deprecates the support for existent sevm which will no more be supported in mainline and renames the board dts file accordingly. Also a few additional device DT entry updates are done. This is on top of the below branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm after pulling in the data from below place git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git HWMOD DATA: for_3.11/omap5_data_files CLOCK DATA: out_of_tree/omap5_clk_data Dan Murphy (1): ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Roger Quadros (1): ARM: dts: omap5-uevm: Add USB Host support Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support arch/arm/boot/dts/Makefile |2 +- arch/arm/boot/dts/omap5-evm.dts | 261 arch/arm/boot/dts/omap5-uevm.dts | 311 ++ arch/arm/boot/dts/omap5.dtsi | 30 4 files changed, 342 insertions(+), 262 deletions(-) delete mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5-uevm.dts ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] ARM: dts: AM3XXX: Use preprocessor for device trees
On 06/06/2013 07:28 AM, Mohammed, Afzal wrote: Hi Benoit, On Wed, Jun 05, 2013 at 18:19:00, Cousson, Benoit wrote: + Afzal, Hi Vaibhav and Afzal, Can someone test this series before I pull it. I still don't have any AM board to do it myself :-( Tested-by: Afzal Mohammed af...@ti.com (am335x evm) Thanks Afzal. Florian, I've just pushed the series including Azal tested-by. I added as well the Makefile change you have done to add missing target with a slight change in the subject: ARM: dts: OMAP4/AM35xx: Add missing dtb in the dtbs target Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH v4 0/5] Adding pinctrl PM support for CPSW and MDIO
Hi Mugunthan, On 06/05/2013 07:08 PM, Mugunthan V N wrote: This patch series adds the following features * Adding pinctrl PM support for CPSW and MDIO for Power Optimization * Adding phy address to the CPSW node for EVMsk board Changes from initial version * Fixed the multiline function call indentation as per David Miller recommendation. Changes from v2 * Fixed the multi comment style as per net coding style * Fixed checkpatch error (more than 80 characters) Changes from v3 * Removed below patch as it has already merged to net-next ARM: dts: AM33XX: Add CPSW phy_id device tree data to am335x-evmsk * Rebased to net-next as there was a merge conflict in DT files You should try to avoid pushing DTS patches outside the arm-soc tree, it will generate a bunch a conflict when arm-soc and net trees will be merged. Could you post separately all the DTS patches and rebase them on the for_3.11/dts branch that already contains a bunch of AM33xx patches? Thanks, Benoit Hebbar Gururaja (1): net: cpsw: enhance pinctrl support Mugunthan V N (4): net: davinci_mdio: enhance pinctrl support ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM arch/arm/boot/dts/am335x-bone.dts | 38 arch/arm/boot/dts/am335x-evm.dts | 36 +++ arch/arm/boot/dts/am335x-evmsk.dts | 50 drivers/net/ethernet/ti/cpsw.c | 48 ++ drivers/net/ethernet/ti/davinci_mdio.c | 45 5 files changed, 217 insertions(+) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] ARM: dts: AM3XXX: Use preprocessor for device trees
+ Afzal,
Hi Vaibhav and Afzal,
Can someone test this series before I pull it. I still don't have any AM
board to do it myself :-(
In theory, it should be fine since Florian already checked the diff, but
just in case.
Thanks,
Benoit
On 06/03/2013 04:12 PM, Florian Vaussard wrote:
Hello,
Following my series for OMAP2+, this series makes use of the C preprocessor
when compiling AM3xxx DT files, and accomplishes some improvements to improve
overall readability.
The .dtb files were diff-tested before and after applying the series to
guarantee identity for all targets.
To enable pullup/down on the pad, the bit should be cleared on AM33xx, where
it should be set on OMAP3. This was wrong in my first version.
This series is based on Benoit's 'for_3.11/dts' branch.
Regards,
Florian
From v2:
- Rebased on Benoit's 'for_3.11/dts'
- Fixed inversed bit to enable pullups ('1' on OMAP, but '0' on AM33xx)
Florian Vaussard (4):
ARM: dts: AM3XXX: Use #include for all device trees
ARM: dts: AM33XX: Use existing constants for GPIOs
ARM: dts: AM33XX: Specific pinctrl header
ARM: dts: AM33XX: Use pinctrl constants
arch/arm/boot/dts/am335x-bone.dts | 28 ++--
arch/arm/boot/dts/am335x-evm.dts| 76 +++---
arch/arm/boot/dts/am335x-evmsk.dts | 46 +-
arch/arm/boot/dts/am33xx.dtsi |5 ++-
arch/arm/boot/dts/am3517-evm.dts|2 +-
arch/arm/boot/dts/am3517_mt_ventoux.dts |2 +-
include/dt-bindings/pinctrl/am33xx.h| 37 +++
7 files changed, 118 insertions(+), 78 deletions(-)
create mode 100644 include/dt-bindings/pinctrl/am33xx.h
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Afzal, On 06/03/2013 09:49 AM, Mohammed, Afzal wrote: Hi Benoit, On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote: And in this case, you do not introduce any new revision. There is no point to update the binding each time we add a new SoC variant that will contain the exact same IP. I think it will mainly confuse the user that will wonder what is different in that version compare to the previous one, moreover we can end up with hundred of entries for the exact same IP for nothing. The real problem is due to the introduction of the SoC name in the device compatible name. That does introduced a SoC level information that is mostly irrelevant at device level. I can understand why it was done for practical aspect when the IP version is not well identified, but that can lead to this proliferation of new pointless bindings. As opinions on $subject seems not yet to be conclusive, I plan to rebase DTS patch (14/14) over your 'for_3.11/dts' branch (that makes use of C preprocessor on OMAP DTS) and post separately dropping 11-14 patches, is that okay ? Yes, that sounds good to me. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: OMAP5: add PWM capability to timer nodes missing it
Hi Suman,
On 06/01/2013 12:17 AM, Anna, Suman wrote:
Benoit, Tony,
On 04/17/2013 06:23 PM, Suman Anna wrote:
OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
The PWM capability property is missing from the node definitions of
couple of timers, and this has been fixed.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..0d155f5 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -422,6 +422,7 @@
interrupts = 0 41 0x4;
ti,hwmods = timer5;
ti,timer-dsp;
+ ti,timer-pwm;
};
timer6: timer@4013a000 {
@@ -458,6 +459,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-pwm;
};
timer10: timer@48086000 {
@@ -465,6 +467,7 @@
reg = 0x48086000 0x80;
interrupts = 0 46 0x4;
ti,hwmods = timer10;
+ ti,timer-pwm;
};
timer11: timer@48088000 {
Make sure you copy the linux-arm and device-tree mailing lists.
Acked-by: Jon Hunter jon-hun...@ti.com
Can you include this patch in your next fixes pull request (if you haven't
already done so)? The other patch in the series is a feature change, but
this is a fix, and can go into 3.10 itself.
I've just sent a pull request with two fixes to Tony. Since -rc4 is
already there, I'll update it with this fix.
Tony,
I will resend a new pull-request rebased on -rc4 that will include this
new fix.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] ARM: dts: AM43x: initial support
On 06/03/2013 03:19 PM, Afzal Mohammed wrote:
DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
represented here are the minimal DT nodes necessary to get kernel
booting.
In DT nodes, ti,hwmod property has not been added, this would be
added along with PRCM support for AM43x.
Signed-off-by: Ankur Kishore a-kish...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Thanks Afzal. I've just applied it in my branch.
Regards,
Benoit
---
v3: Make use of C preprocessor, rebased over Benoit's 'for_3.11/dts' branch
v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer
arch/arm/boot/dts/am4372.dtsi | 68
+++
1 file changed, 68 insertions(+)
create mode 100644 arch/arm/boot/dts/am4372.dtsi
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
new file mode 100644
index 000..ddc1df7
--- /dev/null
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -0,0 +1,68 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 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.
+ */
+
+#include dt-bindings/interrupt-controller/arm-gic.h
+
+#include skeleton.dtsi
+
+/ {
+ compatible = ti,am4372, ti,am43;
+ interrupt-parent = gic;
+
+
+ aliases {
+ serial0 = uart0;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a9;
+ };
+ };
+
+ gic: interrupt-controller@48241000 {
+ compatible = arm,cortex-a9-gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48241000 0x1000,
+ 0x48240100 0x0100;
+ };
+
+ ocp {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ uart0: serial@44e09000 {
+ compatible = ti,am4372-uart,ti,omap2-uart;
+ reg = 0x44e09000 0x2000;
+ interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ timer1: timer@44e31000 {
+ compatible =
ti,am4372-timer-1ms,ti,am335x-timer-1ms;
+ reg = 0x44e31000 0x400;
+ interrupts = GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;
+ ti,timer-alwon;
+ };
+
+ timer2: timer@4804 {
+ compatible = ti,am4372-timer,ti,am335x-timer;
+ reg = 0x4804 0x400;
+ interrupts = GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ counter32k: counter@44e86000 {
+ compatible =
ti,am4372-counter32k,ti,omap-counter32k;
+ reg = 0x44e86000 0x40;
+ };
+ };
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10 1/2] ARM: dts: omap4-panda: Update the LED support for the panda DTS
Hi Dan,
On 05/31/2013 05:44 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
Thanks, I've just applied it in my branch.
Regards,
Benoit
---
v10 - Update gpio entries to use gpio macros -
https://patchwork.kernel.org/patch/2644561/
v9 - Removed comments for mux config -
https://patchwork.kernel.org/patch/2644391/
v8 - Rebase to latest and use pinctrl macros -
https://patchwork.kernel.org/patch/2629351/
v7 - Update headline to add spaces -
https://patchwork.kernel.org/patch/2583661/
v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
v5 - Provide pincrtl phandle to the gpio-led driver -
https://patchwork.kernel.org/patch/2573981/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d5d144a..800fa4e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 GPIO_ACTIVE_HIGH;
@@ -157,6 +162,15 @@
};
};
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 5cfdf19..56c4354 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e (PIN_INPUT | MUX_MODE0)/* hdmi_sda.hdmi_sda */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 (PIN_OUTPUT | MUX_MODE3) /* gpio_110 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ ;
+};
+
+leds {
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
+
+ heartbeat {
+ gpios = gpio4 14 GPIO_ACTIVE_HIGH;
+ };
+ mmc {
+ gpios = gpio1 8 GPIO_ACTIVE_HIGH;
+ };
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1] ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition
Hi Dan, On 05/31/2013 06:12 PM, Florian Vaussard wrote: Hello Dan, On 05/31/2013 05:45 PM, Dan Murphy wrote: Update the dt property ti,audpwron-gpio to use the gpio macro definition for GPIO_ACTIVE_HIGH. Signed-off-by: Dan Murphy dmur...@ti.com --- arch/arm/boot/dts/omap4-panda-common.dtsi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 800fa4e..00cbaa5 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -190,7 +190,7 @@ /* IRQ# = 119 */ interrupts = GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_2N cascaded to gic */ interrupt-parent = gic; -ti,audpwron-gpio = gpio4 31 0; /* gpio line 127 */ +ti,audpwron-gpio = gpio4 31 GPIO_ACTIVE_HIGH; /* gpio line 127 */ vio-supply = v1v8; v2v1-supply = v2v1; I missed it during the conversion, thank you. Reviewed-by: Florian Vaussard florian.vauss...@epfl.ch I've just applied it with Florian's Reviewed-by. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [GIT PULL] ARM: OMAP: dts fixes for 3.10-rc4
Hi Tony, On 05/31/2013 03:23 PM, Benoit Cousson wrote: Hi Tony, Please pull two DTS fixes for the next -rc. Please ignore that one. I'll send a new one with one more fix ASAP. Thanks, Benoit Thanks, Benoit The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b: Linus Torvalds (1): Linux 3.10-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git dts-fixes-for-3.10 Kevin Hilman (1): ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line Lars Poeschel (1): ARM: dts: AM33xx: Fix properties on gpmc node arch/arm/boot/dts/am33xx.dtsi |4 ++-- arch/arm/boot/dts/omap4-panda-common.dtsi | 20 arch/arm/boot/dts/omap4-sdp.dts | 20 3 files changed, 42 insertions(+), 2 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL v2] ARM: dts: OMAP fixes for 3.10-rc5
Hi Tony, Please pull three DTS fixes for the next -rc. Thanks, Benoit The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: Linus Torvalds (1): Linux 3.10-rc4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git dts-fixes-for-3.10 Kevin Hilman (1): ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line Lars Poeschel (1): ARM: dts: AM33xx: Fix properties on gpmc node Suman Anna (1): ARM: dts: OMAP5: Fix missing PWM capability to timer nodes arch/arm/boot/dts/am33xx.dtsi |4 ++-- arch/arm/boot/dts/omap4-panda-common.dtsi | 20 arch/arm/boot/dts/omap4-sdp.dts | 20 arch/arm/boot/dts/omap5.dtsi |3 +++ 4 files changed, 45 insertions(+), 2 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 0/5] ARM: dts: OMAP2+: Use preprocessor for device trees
Hi Florian, On 05/31/2013 02:32 PM, Florian Vaussard wrote: Hello, Following a similar proposal by Stephen Warren for tegra [1], this series makes use of the C preprocessor when compiling OMAP DT files, and accomplishes some improvements to improve overall readability. Patch 1 is a preparation for the rest of the series. Patch 2 uses existing constants for GPIOs. Patch 3 does the same for IRQs. Patch 4 creates a new header for OMAP's padmux, and patch 5 uses it to simplify pinctrl DT. As for previous versions, the .dtb files were diff-tested before and after applying the series to guarantee identity for all targets. The same series for AM3XXX will follow shortly. Best regards, Florian Thanks for the series. I've just applied it and will push the update for_3.11/dts branch ASAP. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL] ARM: OMAP: dts fixes for 3.10-rc4
Hi Tony, Please pull two DTS fixes for the next -rc. Thanks, Benoit The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b: Linus Torvalds (1): Linux 3.10-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git dts-fixes-for-3.10 Kevin Hilman (1): ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line Lars Poeschel (1): ARM: dts: AM33xx: Fix properties on gpmc node arch/arm/boot/dts/am33xx.dtsi |4 ++-- arch/arm/boot/dts/omap4-panda-common.dtsi | 20 arch/arm/boot/dts/omap4-sdp.dts | 20 3 files changed, 42 insertions(+), 2 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7] ARM: dts: omap4-panda: Update the LED support for the panda DTS
Hi Dan,
On 05/29/2013 01:20 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7clean
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
That patch was good... until Florian introduces some new constant to
improve the readability of the DTS [1].
Could you rebase on the lastest for_3.11/dts and use the macros for the
GPIO and pinctrl nodes?
Thanks,
Benoit
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89684.html
---
v7 - Update headline to add spaces -
https://patchwork.kernel.org/patch/2583661/
v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
v5 - Provide pincrtl phandle to the gpio-led driver -
https://patchwork.kernel.org/patch/2573981/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 0;
@@ -137,6 +142,15 @@
};
};
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..c968a3b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+};
+
+leds {
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
+
+ heartbeat {
+ gpios = gpio4 14 0;
+ };
+ mmc {
+ gpios = gpio1 8 0;
+ };
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] ARM: dts: OMAP4/AM35xx: Fix missing dtb in the dtbs target
On 05/31/2013 04:05 PM, Florian Vaussard wrote: When making the dtbs target on OMAP/AM35xx, some trees are not built. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Thanks for the fix Florian. I need to applied your AM series first to take that one otherwise the am3517-evm will fail since it depends on omap3.dtsi. BTW, I applied some more AM patches in my branch, and I cannot apply ARM: dts: AM33XX: Use pinctrl constants anymore. Just wait for some review from AM folks before updating the whole series. Regards, Benoit --- arch/arm/boot/dts/Makefile |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index b9f7121..8eadd4e 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -149,10 +149,13 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ omap4-panda-es.dtb \ omap4-var-som.dtb \ omap4-sdp.dtb \ + omap4-sdp-es23plus.dtb \ omap5-evm.dtb \ am335x-evm.dtb \ am335x-evmsk.dtb \ - am335x-bone.dtb + am335x-bone.dtb \ + am3517-evm.dtb \ + am3517_mt_ventoux.dtb dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
Hi Pekon,
On 05/20/2013 06:44 AM, Gupta, Pekon wrote:
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0
+ nandflash_pins_s0;
Why add this to the board level fallback (called pinctrl hogs, I think)?
This can be part of nand node you added below so that the pinctrl will
take effect when nand gets probed instead of all the time.
Yes we should have all the pinctrl entries under the related drivers.
This makes it easy remux pins during runtime if needed, and also
allows unloading pinctrl-single.ko for development.
Yes, accepted. This has been already fixed in v3 of this patch set.
If all fine, then please pull this for next merge..
http://lists.infradead.org/pipermail/linux-mtd/2013-May/046712.html
http://lists.infradead.org/pipermail/linux-mtd/2013-May/046814.html
http://lists.infradead.org/pipermail/linux-mtd/2013-May/046710.html
with regards, pekon
Request you to please accept | provide feedbacks on this patch series.
These are waiting acceptance since Jan-2013, and are necessary for
DT based configs for board having NAND support.
with regards, pekon
Sorry, I missed that series.
I'm applying it right now.
Thanks,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
On 05/30/2013 09:31 AM, Gupta, Pekon wrote: Sorry, I missed that series. I'm applying it right now. No issues.. Please pick newer v4 versions of this series. Following are rebased, updated and tested on linux-3.10-rc3 [PATCH v4,0/3] http://www.spinics.net/lists/linux-omap/msg91165.html [PATCH v4,1/3] http://www.spinics.net/lists/linux-omap/msg91166.html [PATCH v4,2/3] (please skip this one) instead pick http://www.spinics.net/lists/linux-omap/msg91161.html [PATCH v4,3/3] http://www.spinics.net/lists/linux-omap/msg91167.html Could you please rebase on for_3.11/dts and repost the whole stuff. It looks like Tony already pulled the GPMC node, and the two other ones cannot apply anymore. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Stephen, On 05/29/2013 05:27 PM, Stephen Warren wrote: On 05/29/2013 02:39 AM, Benoit Cousson wrote: Hi Afzal, On 05/29/2013 10:06 AM, Mohammed, Afzal wrote: Hi Jon, On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote: On 05/28/2013 03:25 PM, Jon Hunter wrote: ti,am335x-timer (applicable to AM335x devices) ti,am335x-timer-1ms (applicable to AM335x devices) +ti,am4372-timer-1ms, ti,am335x-timer-1ms for AM43x 1ms timer +ti,am4372-timer, ti,am335x-timer for AM43x timers other than 1ms one If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these. I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW. Stephen took words out of my finger ;) Some explanations,I don;t 1. first compatible should be exact device [A], followed by compatible model (if one) 2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase). As we both were in GPMC land earlier, an example, If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required. That's true for the DTS itself, but here your are changing the binding documentation which is supposed to reflect the driver interface in the Device Tree model description. Since the driver does not support any new compatible string, you should not update the binding. I don't agree here; the DT binding should define all the required and/or allowed values that must/should/can be present in the DT - the entire legal schema. The set of all compatible values is included in that, irrespective of whether a particular value actually (currently) defines a different HW interface or not. Well, I tend to agree on the principle, but so far it was never really done like that. That's not necessarily a good excuse, but if we start adding new bindings for the huge number of OMAP|AM variants TI has been introduced for 10 years, I'd rather use a wildcard than a exhaustive list of all the devices. Something like ti,[omap|am]*-timer for example . Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Afzal, On 05/29/2013 10:06 AM, Mohammed, Afzal wrote: Hi Jon, On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote: On 05/28/2013 03:25 PM, Jon Hunter wrote: ti,am335x-timer (applicable to AM335x devices) ti,am335x-timer-1ms (applicable to AM335x devices) + ti,am4372-timer-1ms, ti,am335x-timer-1ms for AM43x 1ms timer + ti,am4372-timer, ti,am335x-timer for AM43x timers other than 1ms one If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these. I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW. Stephen took words out of my finger ;) Some explanations,I don;t 1. first compatible should be exact device [A], followed by compatible model (if one) 2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase). As we both were in GPMC land earlier, an example, If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required. That's true for the DTS itself, but here your are changing the binding documentation which is supposed to reflect the driver interface in the Device Tree model description. Since the driver does not support any new compatible string, you should not update the binding. The driver and the binding will have to be changed the day you will have to update the driver to handle a bug / feature specific to that revision (ti,am4372-timer). Since this series does not seems to update the driver, you should not update the bindings. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/5] ARM: dts: OMAP2+: use preprocessor for device trees
Salut Florian, On 05/28/2013 10:41 AM, Florian Vaussard wrote: On 05/27/2013 04:52 PM, Florian Vaussard wrote: Hello, Following a similar proposal by Stephen Warren for tegra [1], this series makes use of the C preprocessor when compiling OMAP DT files, and accomplishes some improvements to improve overall readability. Thanks for that nice cleanup. I realized that I should also address am* devices. I will wait for comments on this version, then post a v4. Sorry for the noise. That's up to you, but I can anyway already pulled that series. That AM* patches can go later. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 14/14] ARM: dts: AM43x: initial support
+ Florian
Hi Afzal,
On 05/27/2013 04:37 PM, Afzal Mohammed wrote:
DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
represented here are the minimal DT nodes necessary to get kernel
booting.
In DT nodes, ti,hwmod property has not been added, this would be
added along with PRCM support for AM43x.
Signed-off-by: Ankur Kishore a-kish...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer
arch/arm/boot/dts/am4372.dtsi | 66
+++
1 file changed, 66 insertions(+)
create mode 100644 arch/arm/boot/dts/am4372.dtsi
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
new file mode 100644
index 000..1d58298
--- /dev/null
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -0,0 +1,66 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 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.
+ */
+
+/include/ skeleton.dtsi
You can now use the C preprocessor statement instead of this one.
Florian already started doing the change [1].
Beside that detail, that patch looks good to me.
I'll pull it separately of the series.
Regards,
Benoit
[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/98320
+
+/ {
+ compatible = ti,am4372, ti,am43;
+ interrupt-parent = gic;
+
+
+ aliases {
+ serial0 = uart1;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a9;
+ };
+ };
+
+ gic: interrupt-controller@48241000 {
+ compatible = arm,cortex-a9-gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48241000 0x1000,
+ 0x48240100 0x0100;
+ };
+
+ ocp {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ uart1: serial@44e09000 {
+ compatible = ti,am4372-uart,ti,omap2-uart;
+ reg = 0x44e09000 0x2000;
+ interrupts = 0 72 0x4;
+ };
+
+ timer1: timer@44e31000 {
+ compatible =
ti,am4372-timer-1ms,ti,am335x-timer-1ms;
+ reg = 0x44e31000 0x400;
+ interrupts = 0 67 0x4;
+ ti,timer-alwon;
+ };
+
+ timer2: timer@4804 {
+ compatible = ti,am4372-timer,ti,am335x-timer;
+ reg = 0x4804 0x400;
+ interrupts = 0 68 0x4;
+ };
+
+ counter32k: counter@44e86000 {
+ compatible =
ti,am4372-counter32k,ti,omap-counter32k;
+ reg = 0x44e86000 0x40;
+ };
+ };
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/5] ARM: dts: OMAP2+: use preprocessor for device trees
On 05/29/2013 10:53 AM, Florian Vaussard wrote: Hello Benoit, On 05/29/2013 10:46 AM, Benoit Cousson wrote: Salut Florian, On 05/28/2013 10:41 AM, Florian Vaussard wrote: On 05/27/2013 04:52 PM, Florian Vaussard wrote: Hello, Following a similar proposal by Stephen Warren for tegra [1], this series makes use of the C preprocessor when compiling OMAP DT files, and accomplishes some improvements to improve overall readability. Thanks for that nice cleanup. I realized that I should also address am* devices. I will wait for comments on this version, then post a v4. Sorry for the noise. That's up to you, but I can anyway already pulled that series. That AM* patches can go later. I saw in your for_3.11/dts branch that you have a couple of patches declaring new pinctrl bindings, so I should base my series of this branch to address these patches as well. So I will send a v4 anyway in the coming days. OK, no problem. I'll wait for the update. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
On 05/29/2013 11:58 AM, Mohammed, Afzal wrote: Hi Benoit, On Wed, May 29, 2013 at 14:09:18, Cousson, Benoit wrote: On 05/29/2013 10:06 AM, Mohammed, Afzal wrote: On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote: On 05/28/2013 03:25 PM, Jon Hunter wrote: If you are adding more compatibility strings, then this implies that the AM43x timers are not 100% compatible with any other device listed (such as am335x or any omap device). That's fine but you should state that in the changelog. If the AM43x timer registers are 100% compatible with existing devices you should not add these. I'm not sure that's true; .dts files should always include a compatible value that describes the most specific model of the HW, plus any baseline compatible value that the HW is compatible with. This allows any required quirks/fixes/... to be applied for the specific HW model later even if nobody knows right now they'll be needed. Hence, defining new compatible values doesn't necessarily mean incompatible HW. Stephen took words out of my finger ;) Some explanations,I don;t 1. first compatible should be exact device [A], followed by compatible model (if one) 2. Minor effort in getting DT right the first time may help prevent difficult effort later modifying it (if a necessity comes), considering the fact that DT sources has to move out of Kernel at some point of time. And DT is not supposed to be modified, which may cause difficulty for the users (I had been a minor victim of this during rebase). As we both were in GPMC land earlier, an example, If my memory is right, GPMC IP in am335x is rev 6, and IP has 8 chip select, but one is not pinned out. Now assume that same IP is integrated in another SoC (probably OMAP4 has rev 6). Here if we use same compatible for both, driver cannot handle it properly (w/o knowledge about platform). But if exact compatible is mentioned, without modifying DT (which should be considered as a firmware) just by modifying Kernel, deciding based on compatible would help achieve what is required. That's true for the DTS itself, but here your are changing the binding documentation which is supposed to reflect the driver interface in the Device Tree model description. Since the driver does not support any new compatible string, you should not update the binding. I have a different opinion: Binding documentation is to be considered an entity that is not a part of the Kernel, but currently is a part of the Kernel for want of a better place. And binding is to be considered OS agnostic being ignorant of any piece of software (driver here). OK, that part is correct, but instead of driver I should have said HW device. The binding is supposed to identify a specific HW device revision or family if some HW registers are there to identify the version. Binding has the authority to allow its usage in DT sources. And in this case, you do not introduce any new revision. There is no point to update the binding each time we add a new SoC variant that will contain the exact same IP. I think it will mainly confuse the user that will wonder what is different in that version compare to the previous one, moreover we can end up with hundred of entries for the exact same IP for nothing. The real problem is due to the introduction of the SoC name in the device compatible name. That does introduced a SoC level information that is mostly irrelevant at device level. I can understand why it was done for practical aspect when the IP version is not well identified, but that can lead to this proliferation of new pointless bindings. The driver and the binding will have to be changed the day you will have to update the driver to handle a bug / feature specific to that revision (ti,am4372-timer). Since this series does not seems to update the driver, you should not update the bindings. I believe that updating binding is a prerequisite for making a new DTS change, hence binding was updated first, then DTS. I don't think so, as soon as you still use at least one documented compatible binding in the DTS description. It is not anyway really armless, it just adds much more confusion that real useful information for my point of view. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] ARM: dts: omap3-igep0030: Add NAND flash support
Hi Javier,
On 05/10/2013 09:40 PM, Javier Martinez Canillas wrote:
The IGEP COM Module has an 512MB NAND flash memory.
Add a device node for this NAND and its parition layout.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- I just realized that sent a wrong version of the patch, sorry for the noise
And what about the first one? For igep0020?
Thanks,
Benoit
arch/arm/boot/dts/omap3-igep0030.dts | 50
++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 9dc48d2..f65bc3a 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -42,3 +42,53 @@
};
};
};
+
+gpmc {
+ ranges = 0 0 0x 0x2000;
+
+ nand@0,0 {
+ linux,mtd-name= micron,mt29c4g96maz;
+ reg = 0 0 0;
+ nand-bus-width = 16;
+ ti,nand-ecc-opt = bch8;
+
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 44;
+ gpmc,cs-wr-off-ns = 44;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 34;
+ gpmc,adv-wr-off-ns = 44;
+ gpmc,we-off-ns = 40;
+ gpmc,oe-off-ns = 54;
+ gpmc,access-ns = 64;
+ gpmc,rd-cycle-ns = 82;
+ gpmc,wr-cycle-ns = 82;
+ gpmc,wr-access-ns = 40;
+ gpmc,wr-data-mux-bus-ns = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ partition@0 {
+ label = SPL;
+ reg = 0 0x10;
+ };
+ partition@0x8 {
+ label = U-Boot;
+ reg = 0x10 0x18;
+ };
+ partition@0x1c {
+ label = Environment;
+ reg = 0x28 0x10;
+ };
+ partition@0x28 {
+ label = Kernel;
+ reg = 0x38 0x30;
+ };
+ partition@0x78 {
+ label = Filesystem;
+ reg = 0x68 0x1f98;
+ };
+ };
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
+ new Jon's email address.
Hi Javier,
Sorry for the delay.
On 05/09/2013 12:37 AM, Javier Martinez Canillas wrote:
On Wed, Apr 17, 2013 at 6:32 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip as a GPMC child
and all its dependencies (regulators, GPIO and pin muxs).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi|6
arch/arm/boot/dts/omap3-igep0020.dts | 53
++
2 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index f8fe3b7..d5cd504 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -62,6 +62,12 @@
0x126 0x0100/* sdmmc1_dat7.sdmmc1_dat7 INPUT |
MODE 0 */
;
};
+
+ smsc911x_pins: pinmux_smsc911x_pins {
+ pinctrl-single,pins =
+0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT |
MODE4 */
+ ;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..4bac32e 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
gpios = twl_gpio 19 1;
};
};
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
};
i2c3 {
@@ -54,3 +66,44 @@
reg = 0x50;
};
};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x100;
+ ethernet@5,0 {
+ pinctrl-names = default;
+ pinctrl-0 = smsc911x_pins;
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 186;
+ gpmc,cs-wr-off-ns = 186;
+ gpmc,adv-on-ns = 12;
+ gpmc,adv-rd-off-ns = 48;
+ gpmc,adv-wr-off-ns = 48;
+ gpmc,oe-on-ns = 54;
+ gpmc,oe-off-ns = 168;
+ gpmc,we-on-ns = 54;
+ gpmc,we-off-ns = 168;
+ gpmc,rd-cycle-ns = 186;
+ gpmc,wr-cycle-ns = 186;
+ gpmc,access-ns = 114;
+ gpmc,page-burst-access-ns = 6;
+ gpmc,bus-turnaround-ns = 12;
+ gpmc,cycle2cycle-delay-ns = 18;
+ gpmc,wr-data-mux-bus-ns = 90;
+ gpmc,wr-access-ns = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16 8;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 4;
+
+ smsc,save-mac-address;
+ };
+};
--
1.7.7.6
--
Hi Benoit,
Any comments on this patch?
Nope, it looks good to me. I've just applied it.
Thanks,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] ARM: dts: omap3-igep0030: Add NAND flash support
On 05/27/2013 10:50 AM, Javier Martinez Canillas wrote: On 05/27/2013 10:40 AM, Benoit Cousson wrote: Hi Javier, Hi Benoit, On 05/10/2013 09:40 PM, Javier Martinez Canillas wrote: The IGEP COM Module has an 512MB NAND flash memory. Add a device node for this NAND and its parition layout. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - I just realized that sent a wrong version of the patch, sorry for the noise And what about the first one? For igep0020? Thanks, Benoit For the igep0020 the first one was already correct. I just sent the wrong one for the igep0030 and that's why I had to send a v2 for this patch. Sorry for the confusion. OK, I've just applied the v1 igep0020 and v2 igep0030 after fixing the changelog typo parition. Patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/RFT] ARM: dts: add minimal DT support for Nokia N950 N9
Hi Aaro,
On 05/22/2013 09:44 PM, Aaro Koskinen wrote:
Add minimal DT support for Nokia N950 N9. The basic boot works. I can
connect to both devices with USB networking ssh. dmesg output looks OK.
That's great! Tony will like that :-)
It is too bad I just have a N900 :-(
Functionality compared to the legacy board file:
- MMC not detected - reason unknown, any tips welcome
On OMAP4 panda I used to have the similar issue due to the pbias not set
properly.
- OneNAND missing completely
The GPMC for OMAP3 support is pretty new, so maybe some tweak are still
needed.
Is it RFC because you are still working on the missing functionalities?
Otherwise the patches are already good to be merged if you want.
As soon as you don't break legacy boot, we can merge even half-working DTS.
Thanks,
Benoit
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/boot/dts/Makefile |2 +
arch/arm/boot/dts/omap3-n9.dts | 18
arch/arm/boot/dts/omap3-n950-n9.dtsi | 84
++
arch/arm/boot/dts/omap3-n950.dts | 18
4 files changed, 122 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-n9.dts
create mode 100644 arch/arm/boot/dts/omap3-n950-n9.dtsi
create mode 100644 arch/arm/boot/dts/omap3-n950.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9f7121..e7e1c82 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -144,6 +144,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
+ omap3-n9.dtb \
+ omap3-n950.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
new file mode 100644
index 000..0553b33
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -0,0 +1,18 @@
+/*
+ * omap3-n9.dts - Device Tree file for Nokia N9
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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-n950-n9.dtsi
+
+/ {
+ model = Nokia N9;
+ compatible = nokia,omap3-n9, ti,omap3;
+};
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
new file mode 100644
index 000..3f983f7
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -0,0 +1,84 @@
+/*
+ * omap3-n950-n9.dtsi - Device Tree file for Nokia N950 N9 (common stuff)
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ omap36xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000; /* 1 GB */
+ };
+
+ rm6xx_vemmc: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = VEMMC;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ gpio = gpio5 29 0; /* gpio line 157 */
+ startup-delay-us = 150;
+ enable-active-high;
+ };
+};
+
+i2c1 {
+ clock-frequency = 290;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+twl {
+ compatible = ti,twl5031;
+};
+
+twl_gpio {
+ ti,pullups = 0x01; /* BIT(0) */
+ ti,pulldowns= 0x008106; /* BIT(1) | BIT(2) | BIT(8) | BIT(15) */
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ status = disabled;
+};
+
+mmc2 {
+ vmmc-supply = rm6xx_vemmc;
+ bus-width = 4;
+ ti,non-removable;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-n950.dts
b/arch/arm/boot/dts/omap3-n950.dts
new file mode 100644
index 000..25fd9ec
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -0,0 +1,18 @@
+/*
+ * omap3-n950.dts - Device Tree file for Nokia N950
+ *
+ * Written by: Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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/
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
Hi Eduardo,
On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..e5bfbfe 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
0 55 0x4;
ti,hwmods = debugss;
};
+
+ bandgap {
+ reg = 0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18;
+ compatible = ti,omap4460-bandgap;
+ interrupts = 0 126 4; /* talert */
+ ti,tshut-gpio = 86;
Why do you need a custom attribute for GPIO? Cannot you use the standard
one?
Where is the gpio controller phandle?
Usually it looks like this:
gpios = gpio1 8 0;
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: dts: Update OMAP3430 SDP NAND and ONENAND properties
Hi Jon,
On 04/08/2013 03:17 AM, Jon Hunter wrote:
The GPMC timing properties for device-tree have been updated by adding
a -ns or -ps suffix to indicate the units of time the property
represents (as suggested by Rob Herring). Therefore, update the timing
property names for the OMAP3430 SDP NAND and ONENAND devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Hi Benoit, this is a changed that is going to be introduced for v3.10.
Feel free to squash this with the patch ARM: dts: OMAP3: Add support
for OMAP3430 SDP board that you have queued for v3.10 if you prefer.
I applied them like that. I did not want to rebase again the whole series.
Regards,
Benoit
arch/arm/boot/dts/omap3430-sdp.dts | 56
++--
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index 05cd8ba..44d2191 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -57,20 +57,20 @@
ti,nand-ecc-opt = sw;
gpmc,device-nand;
- gpmc,cs-on = 0;
- gpmc,cs-rd-off = 36;
- gpmc,cs-wr-off = 36;
- gpmc,adv-on = 6;
- gpmc,adv-rd-off = 24;
- gpmc,adv-wr-off = 36;
- gpmc,oe-on = 6;
- gpmc,oe-off = 48;
- gpmc,we-on = 6;
- gpmc,we-off = 30;
- gpmc,rd-cycle = 72;
- gpmc,wr-cycle = 72;
- gpmc,access = 54;
- gpmc,wr-access = 30;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 36;
+ gpmc,cs-wr-off-ns = 36;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 24;
+ gpmc,adv-wr-off-ns = 36;
+ gpmc,oe-on-ns = 6;
+ gpmc,oe-off-ns = 48;
+ gpmc,we-on-ns = 6;
+ gpmc,we-off-ns = 30;
+ gpmc,rd-cycle-ns = 72;
+ gpmc,wr-cycle-ns = 72;
+ gpmc,access-ns = 54;
+ gpmc,wr-access-ns = 30;
partition@0 {
label = xloader-nand;
@@ -102,20 +102,20 @@
gpmc,device-width = 2;
gpmc,mux-add-data = 2;
- gpmc,cs-on = 0;
- gpmc,cs-rd-off = 84;
- gpmc,cs-wr-off = 72;
- gpmc,adv-on = 0;
- gpmc,adv-rd-off = 18;
- gpmc,adv-wr-off = 18;
- gpmc,oe-on = 30;
- gpmc,oe-off = 84;
- gpmc,we-on = 0;
- gpmc,we-off = 42;
- gpmc,rd-cycle = 108;
- gpmc,wr-cycle = 96;
- gpmc,access = 78;
- gpmc,wr-data-mux-bus = 30;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 84;
+ gpmc,cs-wr-off-ns = 72;
+ gpmc,adv-on-ns = 0;
+ gpmc,adv-rd-off-ns = 18;
+ gpmc,adv-wr-off-ns = 18;
+ gpmc,oe-on-ns = 30;
+ gpmc,oe-off-ns = 84;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 42;
+ gpmc,rd-cycle-ns = 108;
+ gpmc,wr-cycle-ns = 96;
+ gpmc,access-ns = 78;
+ gpmc,wr-data-mux-bus-ns = 30;
partition@0 {
label = xloader-onenand;
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] ARM: OMAP: DMTIMER updates for v3.10
On 04/04/2013 08:38 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130319 10:42]: Includes: - A couple fixes for DMTIMER context loss handling. - Populating DMTIMER errata when booting with device-tree. - A new function for requesting a DMTIMER by device-tree node. Based upon v3.9-rc3. Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 Blaze and AM335x EVM. Testing includes ... 1. Booting kernel on above boards 2. Testing of various DMTIMER request APIs 3. Testing the timer overflow and match interrupts. 4. Using different clock sources to operate the timer with. Jon Hunter (4): ARM: OMAP: Force dmtimer restore if context loss is not detectable ARM: OMAP: Add function to request timer by node ARM: dts: OMAP2+: Update DMTIMER compatibility property ARM: OMAP2+: Populate DMTIMER errata when using device-tree NeilBrown (1): ARM: OMAP: Simplify dmtimer context-loss handling .../devicetree/bindings/arm/omap/timer.txt | 17 +- arch/arm/boot/dts/am33xx.dtsi | 14 +- arch/arm/boot/dts/omap2.dtsi | 22 +- arch/arm/boot/dts/omap2420.dtsi|2 +- arch/arm/boot/dts/omap2430.dtsi|2 +- arch/arm/boot/dts/omap3.dtsi | 24 +- arch/arm/boot/dts/omap4.dtsi | 22 +- arch/arm/boot/dts/omap5.dtsi | 22 +- arch/arm/mach-omap2/timer.c|7 +- arch/arm/plat-omap/dmtimer.c | 241 arch/arm/plat-omap/include/plat/dmtimer.h |1 + 11 files changed, 220 insertions(+), 154 deletions(-) For all these it sounds like it's best that Benoit queues them with the .dts changes: Acked-by: Tony Lindgren t...@atomide.com Great. Jon, I've just applied the whole series and will push it soon. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
On 04/05/2013 08:26 AM, Santosh Shilimkar wrote: On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote: The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting with some of the timer interrupts causing the allocation of timer interrupts to fail. The problem is caused by adding 32 to the interrupt number for the L3 interrupts to account for per processor interrupts (PPI) and software generated interrupts (SGI) which typically are mapped to the first 32 interrupts in the ARM GIC. This is not necessary because the first parameter of the ARM GIC interrupt property specifies the GIC interrupt type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3 interrupts by substracting 32. Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- Please note that this problem is observed in Benoit's for_3.10/dts branch [1]. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git Thats correct. I overlooked the 32 addition part. This patch should also be pulled into Benoit's 3.10 tree. Done. I've just applied it. But I will probably merge it with the original patch, because having a broken patch and the fix in the same pull request does not look right. For the patch, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
Santosh and Jon,
On 04/05/2013 10:08 AM, Benoit Cousson wrote:
On 04/05/2013 08:26 AM, Santosh Shilimkar wrote:
On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote:
The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting
with some of the timer interrupts causing the allocation of timer
interrupts to fail.
The problem is caused by adding 32 to the interrupt number for the L3
interrupts to account for per processor interrupts (PPI) and software
generated interrupts (SGI) which typically are mapped to the first 32
interrupts in the ARM GIC. This is not necessary because the first
parameter of the ARM GIC interrupt property specifies the GIC interrupt
type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3
interrupts by substracting 32.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Please note that this problem is observed in Benoit's for_3.10/dts branch
[1].
[1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
Thats correct. I overlooked the 32 addition part. This patch should
also be pulled into Benoit's 3.10 tree.
Done. I've just applied it. But I will probably merge it with the
original patch, because having a broken patch and the fix in the same
pull request does not look right.
Please find below the fixed version.
Regards,
Benoit
From 90c2d172ef86d6c3283df43358d4425f9016be48 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 26 Feb 2013 17:36:14 +0530
Subject: [PATCH] ARM: dts: OMAP4/5: Update l3-noc DT nodes
Add l3-noc node for OMAP4 and OMAP5 devices.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[jon-hun...@ti.com: Fix the problem caused by adding 32 to the interrupt
number for the L3 interrupts to account for per processor interrupts (PPI)
and software generated interrupts (SGI) which typically are mapped to the
first 32 interrupts in the ARM GIC. This is not necessary because the first
parameter of the ARM GIC interrupt property specifies the GIC interrupt
type (ie. SGI, PPI, etc). Hence, fix the interrupt number for the L3
interrupts by substracting 32]
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Benoit Cousson benoit.cous...@linaro.org
---
arch/arm/boot/dts/omap4.dtsi |5 +
arch/arm/boot/dts/omap5.dtsi |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index ddfc54a..3ae6a3f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -94,6 +94,11 @@
#size-cells = 1;
ranges;
ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+ reg = 0x4400 0x1000,
+ 0x4480 0x2000,
+ 0x4500 0x1000;
+ interrupts = 0 9 0x4,
+0 10 0x4;
counter32k: counter@4a304000 {
compatible = ti,omap-counter32k;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e539258..94b5ec9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -87,6 +87,11 @@
#size-cells = 1;
ranges;
ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+ reg = 0x4400 0x2000,
+ 0x4480 0x3000,
+ 0x4500 0x4000;
+ interrupts = 0 9 0x4,
+0 10 0x4;
counter32k: counter@4ae04000 {
compatible = ti,omap-counter32k;
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Hi Nishanth, The patches 1 to 6 looks good to me. Beside the pretty long Cc list, that should not necessarily contain all the mailing list. Since you are changing / renaming some DTS files, and to avoid any merge conflict I will apply only these 6 patches. DTS and driver changes are in theory orthogonal enough to allow merging them separately and in any order. I'll update my branch with these patches ASAP. Regards, Benoit On 03/19/2013 06:53 PM, Nishanth Menon wrote: Hi, The following version 2 of the series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the generic cpufreq-cpu0 driver to be used in device tree enabled boot while maintaining support of the legacy omap-cpufreq driver when used in non device tree enabled boot. However, in order to enable complete SoC entitlement for OMAP platforms, with this series, key features are still pending on device tree adaptation for OMAP: A) clock framework data transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series[1]. B) On processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. As a result of these pending features: - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators associated at the moment - fortunately, we boot at highest voltage, so things still work. - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added those OPPs in DT yet - this also needs alignment with iMX, AM series pending work, where certain OPPs need enabling based on efuse programmed bit sequences - since it is an add-on work, it is not addressed here. Note: At this point in time, we do not have DT entries for clock on OMAP platforms. Common Clock Framework(CCF) could also control regulators[2]. Once these conversions are complete, there will be minimal cleanup work to switch to the new data structure changes. Key benefit of the series is to allow all relevant TI platforms now to use a single cpufreq driver and equivalent frameworks in addition be part of the transition to device tree. NOTE: As a result of this series: 1. omap-cpufreq will be used only in non device tree boot scenario. we should delete this driver once the 100% DT conversion is complete. 2. Generic cpufreq-cpu0 will be used only in device tree boot scenario. boot systems. Key changes in version 2: - series now rebased on Device tree patches queued for OMAP 3.10 - cpufreq-cpu0 and omap_cpufreq will co-exist and used depending on usage of device tree. - minor wording, cleanups for the same. - omap3.dtsi and omap4.dtsi now become common dtsi which is used by omap34xx.dtsi, omap36xx.dtsi, omap443x.dtsi, omap4460.dtsi as needed. version 1 of the series: http://marc.info/?t=13632948545r=1w=2 available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1 [1] Original discussion thread which triggered this series: http://marc.info/?l=linux-pmm=136304313700602w=2 https://patchwork.kernel.org/patch/2251841/ https://patchwork.kernel.org/patch/2251851/ [2] CCF DVFS patches: https://patchwork.kernel.org/patch/2195431/ https://patchwork.kernel.org/patch/2195421/ https://patchwork.kernel.org/patch/2195451/ https://patchwork.kernel.org/patch/2195441/ https://patchwork.kernel.org/patch/2195461/ Version 2 is now based on for-3.10/dts branch from Benoit: http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts 44fab7a ARM: dts: omap3-devkit8000: Add NAND DT node Version 2 is also available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2 git link: git://github.com/nmenon/linux-2.6-playground.git branch: cpufreq-cpu0-omap-all-v2 Test coverage: test script: http://pastebin.com/zrr8ptge Platforms verified: beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/PUx5h6Jy beagleboard (rev C1D) - OMAP3430 compatible - http://pastebin.com/SycCinFb (DT) http://pastebin.com/qwJHw9Ev (no DT) omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/tVEXeVZC Pandaboard -(OMAP4430 ES2.2) verified with omapconf - http://pastebin.com/cAtytfW0 Pandaboard-ES -(OMAP4460 ES1.1) verified with omapconf - http://pastebin.com/3EymNTMp Nishanth Menon (8): ARM: dts: OMAP34xx/35xx: Add CPU OPP table ARM: dts: OMAP36xx: Add CPU OPP table ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU ARM: dts: OMAP443x: Add CPU OPP table ARM: dts: omap4-panda: move generic sections to panda-common
Re: [PATCH] ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node
Hi Philip, On 02/01/2013 06:37 AM, Philip Avinash wrote: DT field of interrupts was mentioned wrongly as interrupt in SPI node. This went unnoticed as spi-omap2 driver not making use of interrupt. Fixes the typo. Signed-off-by: Philip Avinash avinashphi...@ti.com --- arch/arm/boot/dts/am33xx.dtsi |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index fbcb90b..cece3ad 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -309,7 +309,7 @@ #address-cells = 1; #size-cells = 0; reg = 0x4803 0x400; - interrupt = 65; + interrupts = 65; ti,spi-num-cs = 2; ti,hwmods = spi0; status = disabled; @@ -320,7 +320,7 @@ #address-cells = 1; #size-cells = 0; reg = 0x481a 0x400; - interrupt = 125; + interrupts = 125; ti,spi-num-cs = 2; ti,hwmods = spi1; status = disabled; Thanks for the fix. Applied with Peter Acked-by. It will be available in the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH-V2 0/6] ARM: dts: AM33XX: Cleanup and pinctrl binding support
Hi Vaibhav, The series looks good to me, but unfortunately does not apply cleanly on top of the latest for_3.10/dts branch. Could you rebase it? Thanks, Benoit On 03/28/2013 07:42 AM, Vaibhav Hiremath wrote: This patch series fixes the numbering schema for I2C and GPIO module and adds the pin-control binding for I2C, UART, GPIO-LED across supported platforms (EVM, EVM-SK and Bone). I have divided patches based on functionality and _not_ into EVM/Board perspective. Changes from V1: (no code change from last version, except uart) - Added Acked-by from Matt Porter and Peter Korsgaard on couple of patches. - Added new patch (PATCH 5/6) in the series for UART indexing fix Vaibhav Hiremath (6): ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM ARM: dts: AM33XX: Add default pinctrl binding for I2C device ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node ARM: dts: AM33XX: Fix uart numbering to match hardware/TRM ARM: dts: AM33XX: Add default pinctrl binding for UART0 device arch/arm/boot/dts/am335x-bone.dts | 37 +- arch/arm/boot/dts/am335x-evm.dts | 50 --- arch/arm/boot/dts/am335x-evmsk.dts | 45 arch/arm/boot/dts/am33xx.dtsi | 38 +- 4 files changed, 123 insertions(+), 47 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
On 03/28/2013 02:43 PM, Nishanth Menon wrote: Hi Benoit, On Thu, Mar 28, 2013 at 6:03 AM, Benoit Cousson b-cous...@ti.com wrote: The patches 1 to 6 looks good to me. Beside the pretty long Cc list, that should not necessarily contain all the mailing list. Arrgh.. my bad. I will keep it in mind for the future. Since you are changing / renaming some DTS files, and to avoid any merge conflict I will apply only these 6 patches. DTS and driver changes are in theory orthogonal enough to allow merging them separately and in any order. I'll update my branch with these patches ASAP. Thanks. I will post a v3 of remaining patches later today. Patches after changelog cleanup are available in the following branch: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 02/14] ARM: OMAP2+: add omapdss_init_of()
Hi Tomi,
On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|2 ++
arch/arm/mach-omap2/display.c | 34 ++
3 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index a61544b..29eb085 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -41,6 +41,7 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ omapdss_init_of();
Mmm, you should not have to call that explicitly. It looks like a hack
to me. Everything in theory should be initialized during
of_platform_populate / driver probe.
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..e9ac1fd 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -293,5 +293,7 @@ extern void omap_reserve(void);
struct omap_hwmod;
extern int omap_dss_reset(struct omap_hwmod *);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ff37be1..c62aee0 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include omap_hwmod.h
@@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
Pads config should be handle by pinmux framework is possible. Otherwise
a dedicated driver will be required.
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
All that code should disappear with DT. hacking a platform device with
pdata is the old way of initializing a device.
I know that you do have some omap_pm callback, but you'd better get rid
of them in case of DT boot.
Fixing that is a generic issue, and as soon as a solution will be done
to handle these specific hooks, every drivers will be able to use that.
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver == OMAPDSS_VER_UNKNOWN) {
+ pr_err(DSS not supported on this SoC\n);
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = board_data;
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 00/14] Add DT support to OMAPDSS
Hi Tomi, On 03/27/2013 09:45 AM, Tomi Valkeinen wrote: Hi, This is an RFC for OMAPDSS DT support. I've only added support for a few boards and a few DSS outputs, but they should give quite a good range of different use cases. If these work well, I think the rest of the outputs and panels will be ok too. The purpose of this series is to get comments about the dts changes. There are still work to be done, like adding DT binding documentation. Some notes: * DSS Submodules The DSS submodules are children of the dss_core node. This is done because the submodules require the dss_core to be alive and initialized to work, even if the submodules are not really behind dss_core. Having the submodules as children will make runtime PM automatically handle the dependency to dss_core. I think usually a node being a child means that it's on the parent's bus, which is not the case here. I'm not sure if that's an issue or not. FWIW, there is a L4_DSS interconnect. It is used internally to connect all the submodules to the DSS L3 port. So this representation is perfectly valid and does represent accurately the HW. Regards, Benoit * ti,dsi-module-id There's a ti,dsi-module-id property in the dsi node. The reason for this module-id property is that we have muxes in the dss_core that route clocks to/from a particular DSI module. So we need some way to index the DSI modules. Another option would be to have a list of DSI modules (phandles) in the dss_core. Both options feel a bit wrong to me, but I went for the module-id approach as that is already used when not using DT. * Display chains Currently omapdss driver can handle only one display device connected to one OMAP SoC output. This is not right in many cases, as there may be multiple display devices in a chain, like first an external encoder and then a panel. However, I tried to model this right in the dts. So, for example, for Panda HDMI output we have the following display entities in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI connector. These are connected using the video-source property, which tells where the component in question gets its video data. You could ask why there's a separate node for HDMI connector. It's true it's not really a proper device, but we need some kind of terminator for the display chains. For HDMI we could as well have an embedded solution, having a chain like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector marks the end of the chain, and acts as a panel in a sense. * DSI lanes The DSI panels contain lanes property, which tells how the SoCs DSI pins are connected to the DSI panel. I'm not sure if the panel data is the proper place for this, or should the data be separately for the OMAP DSI node. Tomi Tomi Valkeinen (14): ARM: OMAP: remove DSS DT hack ARM: OMAP2+: add omapdss_init_of() OMAPDSS: Add DT support to DSS, DISPC, DPI OMAPDSS: Add DT support to DSI OMAPDSS: Add DT support to HDMI OMAPDSS: Taal: Add DT support OMAPDSS: TFP410: Add DT support OMAPDSS: panel-generic-dpi: add DT support ARM: omap3.dtsi: add omapdss information ARM: omap4.dtsi: add omapdss information ARM: omap4-panda.dts: add display information ARM: omap4-sdp.dts: add display information ARM: omap3-tobi.dts: add lcd (TEST) ARM: omap3-beagle.dts: add TFP410 arch/arm/boot/dts/omap3-beagle.dts | 20 + arch/arm/boot/dts/omap3-tobi.dts | 13 arch/arm/boot/dts/omap3.dtsi | 49 arch/arm/boot/dts/omap4-panda.dts| 44 +++ arch/arm/boot/dts/omap4-sdp.dts | 64 arch/arm/boot/dts/omap4.dtsi | 71 + arch/arm/mach-omap2/board-generic.c |9 +-- arch/arm/mach-omap2/common.h |2 + arch/arm/mach-omap2/display.c| 34 + arch/arm/mach-omap2/dss-common.c | 24 -- arch/arm/mach-omap2/dss-common.h |2 - drivers/video/omap2/displays/panel-generic-dpi.c | 47 drivers/video/omap2/displays/panel-taal.c| 89 ++ drivers/video/omap2/displays/panel-tfp410.c | 71 + drivers/video/omap2/dss/dispc.c |7 ++ drivers/video/omap2/dss/dpi.c|8 ++ drivers/video/omap2/dss/dsi.c| 24 +- drivers/video/omap2/dss/dss.c|7 ++ drivers/video/omap2/dss/hdmi.c |7 ++ drivers/video/omap2/dss/hdmi_panel.c | 86 - 20 files changed, 641 insertions(+), 37 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org
Re: [RFC 00/14] Add DT support to OMAPDSS
+ mturquette and Rajendra On 03/27/2013 09:45 AM, Tomi Valkeinen wrote: ... * ti,dsi-module-id There's a ti,dsi-module-id property in the dsi node. The reason for this module-id property is that we have muxes in the dss_core that route clocks to/from a particular DSI module. So we need some way to index the DSI modules. Another option would be to have a list of DSI modules (phandles) in the dss_core. Both options feel a bit wrong to me, but I went for the module-id approach as that is already used when not using DT. That's not a very nice representation. Ideally you should expose 1 clock node per DSI node, and enabling one will select the proper mux for you. Regards, Benoit * Display chains Currently omapdss driver can handle only one display device connected to one OMAP SoC output. This is not right in many cases, as there may be multiple display devices in a chain, like first an external encoder and then a panel. However, I tried to model this right in the dts. So, for example, for Panda HDMI output we have the following display entities in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI connector. These are connected using the video-source property, which tells where the component in question gets its video data. You could ask why there's a separate node for HDMI connector. It's true it's not really a proper device, but we need some kind of terminator for the display chains. For HDMI we could as well have an embedded solution, having a chain like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector marks the end of the chain, and acts as a panel in a sense. * DSI lanes The DSI panels contain lanes property, which tells how the SoCs DSI pins are connected to the DSI panel. I'm not sure if the panel data is the proper place for this, or should the data be separately for the OMAP DSI node. Tomi Tomi Valkeinen (14): ARM: OMAP: remove DSS DT hack ARM: OMAP2+: add omapdss_init_of() OMAPDSS: Add DT support to DSS, DISPC, DPI OMAPDSS: Add DT support to DSI OMAPDSS: Add DT support to HDMI OMAPDSS: Taal: Add DT support OMAPDSS: TFP410: Add DT support OMAPDSS: panel-generic-dpi: add DT support ARM: omap3.dtsi: add omapdss information ARM: omap4.dtsi: add omapdss information ARM: omap4-panda.dts: add display information ARM: omap4-sdp.dts: add display information ARM: omap3-tobi.dts: add lcd (TEST) ARM: omap3-beagle.dts: add TFP410 arch/arm/boot/dts/omap3-beagle.dts | 20 + arch/arm/boot/dts/omap3-tobi.dts | 13 arch/arm/boot/dts/omap3.dtsi | 49 arch/arm/boot/dts/omap4-panda.dts| 44 +++ arch/arm/boot/dts/omap4-sdp.dts | 64 arch/arm/boot/dts/omap4.dtsi | 71 + arch/arm/mach-omap2/board-generic.c |9 +-- arch/arm/mach-omap2/common.h |2 + arch/arm/mach-omap2/display.c| 34 + arch/arm/mach-omap2/dss-common.c | 24 -- arch/arm/mach-omap2/dss-common.h |2 - drivers/video/omap2/displays/panel-generic-dpi.c | 47 drivers/video/omap2/displays/panel-taal.c| 89 ++ drivers/video/omap2/displays/panel-tfp410.c | 71 + drivers/video/omap2/dss/dispc.c |7 ++ drivers/video/omap2/dss/dpi.c|8 ++ drivers/video/omap2/dss/dsi.c| 24 +- drivers/video/omap2/dss/dss.c|7 ++ drivers/video/omap2/dss/hdmi.c |7 ++ drivers/video/omap2/dss/hdmi_panel.c | 86 - 20 files changed, 641 insertions(+), 37 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
Hi Javier,
On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move #interrupt-cells after the
interrupt-controller property so is followed by its description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
and Documentation/devicetree/bindings/gpio/gpio.txt.
According with these docs, the order of the properties for a gpio-omap
device node should be:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
Changes since v2:
- Fix changelog that explained the opposite of what the patch was doing as
suggested by Benoit Cousson.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
any comments on this patch?
That's perfect. I've just applied it in my branch.
Thanks,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On 03/26/2013 03:10 PM, Benoit Cousson wrote:
Hi Javier,
On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move #interrupt-cells after the
interrupt-controller property so is followed by its description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
and Documentation/devicetree/bindings/gpio/gpio.txt.
According with these docs, the order of the properties for a gpio-omap
device node should be:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
Changes since v2:
- Fix changelog that explained the opposite of what the patch was doing as
suggested by Benoit Cousson.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
any comments on this patch?
That's perfect. I've just applied it in my branch.
OK, in fact it is almost perfect :-)
The patch modified the documentation and not the driver itself, so I modified
the subject to reflect that accurately.
Documentation: dt: gpio-omap: Move interrupt-controller from #interrupt-cell
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/8] ARM: dts: Various OMAP2+ device-tree updates
Hi Anil, On 03/17/2013 10:35 AM, Anil Kumar wrote: Hi Benoit, On Fri, Mar 15, 2013 at 8:00 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Jon, On 03/15/2013 02:57 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon Benoit's for_3.10/dts branch [1]. Branch available here [2]. V2 changes: - Rebased on Benoit's for_3.10/dts branch - Squashed patches adding support for OMAP3430 SDP board and patch to add flash support for OMAP3430 SDP board. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts [2] git://github.com/jonhunter/linux.git omap-dt-for-v3.10 Thanks for the repost. I've just applied your branch in my for_3.10/dts branch. I think you missed below patch which is needed for gpmc nand to work fine. Without this patch nand will not work on OMAP3430 SDP board. Jon Hunter:- ARM: OMAP2+: Fix-up gpmc merge error Well, that patch is not part of Jon's series and it looks like it was posted for 3.9-rc3. BTW, Paul W is just reporting a regression about that patch. Anyway, I'll rebase on top of -rc3 to get the latest fixes. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4] ARM: dts: add minimal DT support for DevKit8000.
Hi Anil, On 03/17/2013 06:23 AM, Anil Kumar wrote: Hi Benoit, On Thu, Mar 7, 2013 at 12:21 PM, Benoit Cousson b-cous...@ti.com wrote: Hi, On 03/06/2013 06:53 PM, Tony Lindgren wrote: * Anil Kumar anilk...@gmail.com [130305 18:40]: Hi Tony, From: linux-arm-kernel [mailto:linux-arm-kernel- boun...@lists.infradead.org] On Behalf Of Anil Kumar Sent: Wednesday, February 27, 2013 8:03 AM To: devicetree-discuss@lists.ozlabs.org; linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: li...@arm.linux.org.uk; Cousson, Benoit; Tony Lindgren; Grant Likely; Anil Kumar; tho...@tomweber.eu Subject: Re: FW: [PATCH V4] ARM: dts: add minimal DT support for DevKit8000. Hi, DevKit8000 is a beagle board clone from Timll, sold by armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D, S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and JTAG interface. This patch adds the basic DT support for devkit8000. At this time, Information of twl4030 (PMIC), MMC1, I2C1 and leds are added. Signed-off-by: Anil Kumar anilk...@gmail.com Tested-by: Thomas Weber tho...@tomweber.eu Gentle Ping. As there are no review comments on this patch, Could you please pull this patch ? Gentle Ping. This patch also got Reviewed-by: Manish Badarkhe badarkhe.man...@gmail.com and as patch ARM: dts: omap3-devkit8000: Enable audio support has already got Acked-by: Peter Ujfalusi peter.ujfal...@ti.com but it is on the top of this patch. So, Could you please pull this patch in one of your omap branch? or you want me to do rebase this patch on top of v3.9-rc1 ? Let's wait for Benoit to queue it as he has a bunch of .dts changesfor_3.10/dts already applied. Too bad we missed v3.9 merge window for those, but hopefully we can get them queued early for v3.10. Yep, sorry for having missed 3.9, I was a little bit sick at the wrong moment :-( I'm starting queuing the pending patches, and should have enough to push to you just after Linaro Connect. I think you missed below patch which is needed for gpmc nand to work fine. Jon Hunter:- ARM: OMAP2+: Fix-up gpmc merge error I have re based my changes on top of your repository to make pull easier for you. I hope you will pull these changes for 3.10. The following changes since Commit a7f7881de9c0b58de3b3aea8f01a8aef906d4ade are available in the git repository at: git://gitorious.org/devkit8000-for_3-10/devkit8000-for_3-10.git branch for_3.10/dts for you to fetch changes up to Commit 975abc8b2e7ec4ff7324d726c9775958945ccc5e Thanks, I pulled the patches and rebased that on top of -rc3 to get the missing fix from Jon. I cleaned as well some changelog / subject and pushed then in my for_3.10/dts branch. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
Hi Kishon, On 03/13/2013 10:11 AM, kishon wrote: Benoit, Will you be queuing this patch series? I'm reviewing them right now. Regards, Benoit Thanks Kishon On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. Kishon Vijay Abraham I (7): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap and dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
+ Jon Hi Kishon, On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. The patches looks really good. I've just had to rebase on top of my HEAD due to some conflict with GPMC patch already applied. I cleaned as well some subject and changelog for consistency. The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Jon, You might have to rebase your series on top of the new HEAD before reposting. Thanks, Benoit Kishon Vijay Abraham I (7): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap and dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
Mmm, your are doing the opposite :-)
I guess what we do want is that:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
So we move #interrupt-cells after the interrupt-controller description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
Any comments on this patch?
I know is just a trivial documentation fix but I think it can be quite
helpful for people referring to gpio-omap binding.
I do agree. The patch is good, but the changelog is confusing.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/8] ARM: dts: Various OMAP2+ device-tree updates
Hi Jon, On 03/15/2013 02:57 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon Benoit's for_3.10/dts branch [1]. Branch available here [2]. V2 changes: - Rebased on Benoit's for_3.10/dts branch - Squashed patches adding support for OMAP3430 SDP board and patch to add flash support for OMAP3430 SDP board. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts [2] git://github.com/jonhunter/linux.git omap-dt-for-v3.10 Thanks for the repost. I've just applied your branch in my for_3.10/dts branch. Regards, Benoit Jon Hunter (8): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes ARM: dts: OMAP2+: Add SDMA controller bindings and nodes ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio ARM: dts: OMAP3: Add support for OMAP3430 SDP board arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/omap2.dtsi | 17 arch/arm/boot/dts/omap2420.dtsi | 55 + arch/arm/boot/dts/omap2430.dtsi | 66 arch/arm/boot/dts/omap3.dtsi | 70 +++-- arch/arm/boot/dts/omap3430-sdp.dts | 141 ++ arch/arm/boot/dts/omap4-panda-es.dts |2 + arch/arm/boot/dts/omap4.dtsi | 64 +-- arch/arm/boot/dts/omap4460.dtsi | 18 + arch/arm/boot/dts/omap5.dtsi | 68 ++-- arch/arm/mach-omap2/pmu.c| 14 +++- 11 files changed, 493 insertions(+), 23 deletions(-) create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts create mode 100644 arch/arm/boot/dts/omap4460.dtsi ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
Salut Jon, On 03/08/2013 06:27 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2]. [1] https://patchwork.kernel.org/patch/2057111/ I've tried to follow the series review, and it seems that Florian was considering sending some other patches. It is not clear if this is a new version of the series or some additional patches. I still did not merge this series wondering what to do with it. Felipe's patch on this other hand is already applied in my branch. Regards, Benoit [2] https://patchwork.kernel.org/patch/2134711/ Jon Hunter (9): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes ARM: dts: OMAP2+: Add SDMA controller bindings and nodes ARM: dts: OMAP3: Add support for OMAP3430 SDP board ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP3430 SDP flash memory bindings ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio .../devicetree/bindings/dma/omap-sdma.txt | 51 +++ arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/omap2.dtsi | 17 +++ arch/arm/boot/dts/omap2420.dtsi| 55 arch/arm/boot/dts/omap2430.dtsi| 66 + arch/arm/boot/dts/omap3.dtsi | 70 +- arch/arm/boot/dts/omap3430-sdp.dts | 141 arch/arm/boot/dts/omap4-panda-es.dts |2 + arch/arm/boot/dts/omap4.dtsi | 64 - arch/arm/boot/dts/omap4460.dtsi| 18 +++ arch/arm/boot/dts/omap5.dtsi | 68 -- arch/arm/mach-omap2/pmu.c | 14 +- 12 files changed, 544 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts create mode 100644 arch/arm/boot/dts/omap4460.dtsi ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/14/2013 04:50 PM, Jon Hunter wrote: On 03/14/2013 10:45 AM, Benoit Cousson wrote: On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? Well, in theory both are supposed to be identical :-) I'm just applying a rounding to the closet power of two, that's why it cannot be 0x2d0. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
Hi Florian, On 01/28/2013 06:54 PM, Florian Vaussard wrote: Add device-tree support for the GPMC controller on the OMAP3. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Applied and pushed. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
On 03/14/2013 04:59 PM, Jon Hunter wrote: On 03/14/2013 10:45 AM, Florian Vaussard wrote: Hi Benoit, On 03/14/2013 03:57 PM, Benoit Cousson wrote: Salut Jon, On 03/08/2013 06:27 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2]. [1] https://patchwork.kernel.org/patch/2057111/ I've tried to follow the series review, and it seems that Florian was considering sending some other patches. It is not clear if this is a new version of the series or some additional patches. A bit of both. Sorry for the confusion :-) Concerning patch [1], it can be merged to add the GPMC binding for OMAP3. But please discard the rest of my original series, I will repost something later. Benoit, if you pick up Florian's patch, I will re-post my remaining patches for you to pick up. By the way, I see that you have picked up the PMU bindings, however, ideally we should merge the pmu prepare patch first. We agreed with Tony for you to take this with his ack [1]. OK, no problem, I'll remove it from the for_3.10/dts and get it when I'll merge your branch. Let me know if you just want me to re-post that one on top of your branch. I guess you will have to repost your branch anyway? Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
Hi Javier,
On 03/14/2013 05:02 PM, Javier Martinez Canillas wrote:
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson b-cous...@ti.com wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
[1] https://patchwork.kernel.org/patch/2057111/
I've tried to follow the series review, and it seems that Florian was
considering sending some other patches. It is not clear if this is a new
version of the series or some additional patches.
Hi Benoit,
According to [1] Jon suggested that it was not necessary to map all
the 16MB for the GPMC mapped register address space since in practice
is a very small fraction of that size is used.
I had the following patch but I did never post it because Jon said
that the I/O memory mapping is page-aligned and the minimum page
size for ARM is 4KB anyways, so there is no functional difference
between using 0x1000 or 0x02d0.
But now reading [2] I see that you prefer to do what the documentation
said and don't assume any the page size / alignment.
[2]: https://patchwork.kernel.org/patch/2239741/
From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 27 Feb 2013 02:30:51 +0100
Subject: [PATCH] ARM: dts: OMAP3: reduce GPMC mapped registers address space
Currently the OMAP General-Purpose Memory Controller (GPMC) device
node maps 16 MB of address space for its hardware registers.
This is because the OMAP Technical Reference Manual says that the
GPMC module register address space size is 16 MB. But in practice
the maximum address offset used by a GPMC register is 0x02d0.
So, there is no need to map such a big address space for GPMC regs.
This change was suggested by Jon Hunter [1].
[1]: https://patchwork.kernel.org/patch/2057111/
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Thanks for that super fast patch :-)
Applied.
Regards,
Benoit
---
arch/arm/boot/dts/omap3.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 2ddae38..a60eaf1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -407,7 +407,7 @@
gpmc: gpmc@6e00 {
compatible = ti,omap3430-gpmc;
ti,hwmods = gpmc;
- reg = 0x6e00 0x100;
+ reg = 0x6e00 0x02d0;
interrupts = 20;
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
___
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 Javier,
On 03/02/2013 02:52 AM, Javier Martinez Canillas wrote:
On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Matthias,
On 2/15/2013 10:35 AM, Matthias Brugger wrote:
2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:
On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
matthias@gmail.com
wrote:
Hi Benoit,
2012/12/12 Benoit Cousson b-cous...@ti.com:
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 matthias@gmail.com
---
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.
Can you pin-point me to the repository where this patches are in right
now? I tried to figure it out these days, but didn't found where to
clone the repository from.
Thanks,
Matthias
Hi Matthias,
OMAP DT tree is:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
Hi all,
unfortunately I can't find the patch in this tree.
Sorry about that. I've never pushed the latest branch, and was busy the past
month. I'll refresh the branch with all the pending patches.
Regards,
Benoit
Hi Benoit,
I realized that your for_3.9/dts branch has not landed in mainline yet
and we are near to the end of the merge window.
Are you still planing to include those changes for 3.9 or are you
going to wait until the next release?
I'm really sorry about that. I was not available to push it at the proper time.
I've just rebased it on 3.9-rc2 and pushed it to a new branch.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts
It includes the one from Matthias and yours as well. I'm still checking my
inbox to catch up on the new ones I missed.
I'm planning to push this ASAP to avoid missing the deadline again.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Resend/PATCH 0/5] omap4/5: i2c/spi: device tree data
Hi Sourav, I've just applied your branch after a minor subject cleanup for consistency. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Regards, Benoit On 03/11/2013 04:42 PM, Sourav Poddar wrote: On Monday 11 March 2013 08:02 PM, Benoit Cousson wrote: Hi Sourav, On 03/11/2013 02:44 PM, Sourav Poddar wrote: Hi Tony/Benoit, These patches had been sent couple of times before, but there were no comments on it. Sorry for that. I got a big flu in Jan and was in Linaro Connect last week. Patches look good, I just have to check that they apply nicely to the dts/for_3.9 I already prepared. Ok. Thanks!! I still have to rebase that branch on top of a recent master branch and then check your branch. If there are no comments, Can these be picked ? Cc: Andrew Mortona...@osdl.org The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: g...@gitorious.org:linux-connectivity/linux-connectivity.git omap_i2c_spi_dts_data Felipe Balbi (1): arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file Sourav Poddar (4): arm: dts: omap4-sdp: Add I2c pinctrl data arm: dts: omap5-evm: Add I2c pinctrl data arm: dts: omap4-panda: Add I2c pinctrl data arm: dts: omap5-evm: Add mcspi data Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
+ Seb G.
Hi Jon,
How to you plan to merge that series?
Seb's just posted a McBSP adaptation to SDMA binding, so I'll have to
take this one before being able to merge any other SDMA driver
adaptation patches.
I'm fine to take that one, if you are OK, to avoid merge conflict in DTS
later.
On 02/26/2013 07:27 PM, Jon Hunter wrote:
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
typo---^
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
---
.../devicetree/bindings/dma/omap-sdma.txt | 51
That's a detail, but the bindings should be introduced along with the
driver DT adaptation since it does represent its interface.
arch/arm/boot/dts/omap2.dtsi | 12 +
arch/arm/boot/dts/omap3.dtsi | 40 +++
arch/arm/boot/dts/omap4.dtsi | 41
arch/arm/boot/dts/omap5.dtsi | 41
5 files changed, 185 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt
b/Documentation/devicetree/bindings/dma/omap-sdma.txt
new file mode 100644
index 000..22aab28
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
@@ -0,0 +1,51 @@
+* TI OMAP SDMA controller
+
+Required properties:
+- compatible:Should be set to one of the following:
+
+ ti,omap2420-sdma (omap2420)
+ ti,omap2430-sdma (omap2430)
+ ti,omap3430-sdma (omap3430)
+ ti,omap3630-sdma (omap3630)
+ ti,omap4430-sdma (omap4430 omap4460 omap543x)
+
+- reg: Contains DMA registers location and length.
+- interrupts:Contains DMA interrupt information.
+- #dma-cells:Must be 1.
+- #dma-channels: Contains total number of programmable DMA channels.
+- #dma-requests: Contains total number of DMA requests.
+
+Example:
+
+ sdma: dma-controller@4A056000 {
+ compatible = ti,omap-sdma;
+ reg = 0x4A056000 0x1000;
Nit: you do have several hexa values in upper case, here and in some dts
as well.
Regards,
Benoit
+ interrupts = 0 12 0x4,
+ 0 13 0x4,
+ 0 14 0x4,
+ 0 15 0x4;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 127;
+ };
+
+
+* TI OMAP SDMA clients
+
+Required properties:
+- dmas: List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - The DMA request number associated with client device
+- dma-names: Contains one identifier string for each dma
specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
+
+Example:
+
+ mmc1: mmc@4809c000 {
+ ...
+ dmas = sdma 61, /* TX channel */
+sdma 62; /* RX channel */
+ dma-names = tx, rx;
+ ...
+ };
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..22dffa0 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -49,6 +49,18 @@
reg = 0x480FE000 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap2430-sdma, ti,omap2420-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+ 13,
+ 14,
+ 15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 64;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..4e7acb6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -75,6 +75,18 @@
reg = 0x4820 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap3630-sdma, ti,omap3430-sdma;
+
Re: [PATCH 23/24] ARM: OMAP2+: Allow clock alias provision from device tree
Hi Roger,
On 03/12/2013 12:43 PM, Roger Quadros wrote:
Currently on OMAP, it is not possible to specify a clock consumer
to any of the OMAP generated clocks using the device tree. This can pose
a problem for external devices that run off an OMAP clock as we
can't reliably provide a reference to the clock in the device tree.
I'm really confused by that statement... Why cannot you use the current
clock binding definition?
The point is that we should avoid defining temporary custom bindings.
Especially when a generic one already exist.
I know you already discussed that on the list, but I cannot really find
the rational in the previous thread.
Here is a quote from the original Subject: Re: how to specify an OMAP
clock in device tree? thread.
/* provider */
clks: omapclocks {
compatible = ti,omapclocks;
#clock-cells = 1;
};
/* consumer */
hsusb1_phy: hsusb1_phy {
compatible = usb-nop-xceiv;
clocks = clks auxclk3_ck; /* FREF_CLK3 */
clock-names = main-clk;
};
The only problem I see is that the argument to the clks phandle
cannot be a string. It needs to be u32.
In that case we need to map all clocks into a u32 index.
If we can do that only for auxclks, my problem is solved for panda.
phandle is u32 as always, but you should not care about that.
What you care about is the clock node referenced by the phandle, not the
phandle itself.
What is missing right now is a proper of_clk_add_provider call to
declare a generic OMAP clock provider and thus allow OMAP clocks to be
used with DT.
The AUXCLOCKs are managed by the SCRM which is outside the PRCM, so you
should be able to add a clock providers dedicated to the SCRM clocks only.
Regards,
Benoit
This patch allows device trees to provide a node that contains the
clock identifier, clock alias and the device phandle. The board
initialization code then creates a clock alias to this clock id,
and associates it with the device whose phandle was supplied.
Discussion
http://www.spinics.net/lists/linux-omap/msg86241.html
CC: Russell King li...@arm.linux.org.uk
CC: Rajendra Nayak rna...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/clock/ti-clock-alias.txt | 26
arch/arm/mach-omap2/board-generic.c| 67
2 files changed, 93 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti-clock-alias.txt
diff --git a/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
b/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
new file mode 100644
index 000..87ef4c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
@@ -0,0 +1,26 @@
+* Clock alias provision for TI OMAP2+ boards
+
+This binding allows the board's device tree file to specify a clock name,
+device phandle and clock alias so that that clock can be associated
+to the device with the alias.
+
+This is required in cases where an external device is clocked by an
+OMAP generated clock and needs to be assocated to it.
+
+NOTE: The node's name should be clock_alias
+
+Required properties
+- clock-name: The clock identifier string. Should be one of the
+ clock ids defined in OMAP common clock data.
+- clock-alias: A string specifying the alias that must be created to the
clock.
+- device: A phandle to the device this clock should be associated to.
+
+e.g. On the OMAP4 Panda board, the USB PHY device is clocked by the
+FREF_CLK3 (auxclk3_ck) from the OMAP. The PHY driver expexts the clock to
+be named main_clk. This binding can be provided like so
+
+clock_alias {
+ clock-name = auxclk3_ck;
+ clock-alias = main_clk;
+ device = hsusb1_phy;
+};
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..2fc48f9 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,9 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
+#include linux/clk.h
+#include linux/string.h
+#include linux/slab.h
#include asm/mach/arch.h
@@ -35,12 +38,76 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+static int __init omap_create_clk_alias(struct device_node *np)
+{
+ int ret = 0;
+ const char *s, *alias;
+ char *clk_id;
+ struct device_node *dev_np;
+ struct platform_device *pdev;
+
+ of_property_read_string(np, clock-name, s);
+ if (!s) {
+ pr_err(%s: couldn't find clock-name property in node %s\n,
+ __func__, np-name);
+ return -ENODEV;
+ }
+
+ clk_id = kstrdup(s, GFP_KERNEL);
+ if (!clk_id)
+ return -ENOMEM;
+
+ dev_np = of_parse_phandle(np, device, 0);
+ if (!dev_np) {
+
Re: [PATCH 2/2] cpufreq: cpufreq-cpu0: provide compatibility string for DT matchup
On 03/12/2013 06:07 AM, Santosh Shilimkar wrote: On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote: commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) now forces platform device to be registered for allowing cpufreq-cpu0 to be used by SoCs. example: drivers/cpufreq/highbank-cpufreq.c However, for SoCs that wish to link up using device tree, instead of platform device, provide compatibility string match: compatible = cpufreq,cpu0; You cannot add a non-HW relative binding... DT is supposed to represent the pure HW. AFAIK, cpufreq has nothing to do with the HW definition. Cc: Rafael J. Wysocki r...@sisk.pl Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Shawn Guo shawn@linaro.org Cc: linux-ker...@vger.kernel.org Cc: cpuf...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-o...@vger.kernel.org Signed-off-by: Nishanth Menon n...@ti.com --- .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |3 +++ drivers/cpufreq/cpufreq-cpu0.c |6 ++ 2 files changed, 9 insertions(+) Looks fine to me. CC'ing dt list in case some one has comments on binding updates. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Not-Acked-by-me. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] cpufreq: cpufreq-cpu0: provide compatibility string for DT matchup
On 03/12/2013 03:43 PM, Nishanth Menon wrote: On 15:28-20130312, Benoit Cousson wrote: On 03/12/2013 06:07 AM, Santosh Shilimkar wrote: On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote: commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) now forces platform device to be registered for allowing cpufreq-cpu0 to be used by SoCs. example: drivers/cpufreq/highbank-cpufreq.c However, for SoCs that wish to link up using device tree, instead of platform device, provide compatibility string match: compatible = cpufreq,cpu0; You cannot add a non-HW relative binding... DT is supposed to represent the pure HW. AFAIK, cpufreq has nothing to do with the HW definition. Ref: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/highbank-cpufreq.c#n61 there is a need for a device of some sort. in the example above, we register a dummy device for linking up with cpufreq-cpu0 driver. what we do in this patch is to indicate that SoC CPUs are managed by cpufreq-cpu0 driver. I am a bit curious to see how else would we represent drivers to manage real h/w devices like CPU? Is the highbank style the recommended way to do things? Yep, I don't think this is a very elegant way to do that, but until we do have a generic DVFS layer, I'm not sure we have any other approach. But maybe not. The CPU is the real device, but AFAIK, nobody beside OMAP is representing the CPU as the device. But I'd rather use a CPU device than a fake CPUFREQ device. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Resend/PATCH 0/5] omap4/5: i2c/spi: device tree data
Hi Sourav, On 03/11/2013 02:44 PM, Sourav Poddar wrote: Hi Tony/Benoit, These patches had been sent couple of times before, but there were no comments on it. Sorry for that. I got a big flu in Jan and was in Linaro Connect last week. Patches look good, I just have to check that they apply nicely to the dts/for_3.9 I already prepared. I still have to rebase that branch on top of a recent master branch and then check your branch. If there are no comments, Can these be picked ? Cc: Andrew Morton a...@osdl.org The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: g...@gitorious.org:linux-connectivity/linux-connectivity.git omap_i2c_spi_dts_data Felipe Balbi (1): arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file Sourav Poddar (4): arm: dts: omap4-sdp: Add I2c pinctrl data arm: dts: omap5-evm: Add I2c pinctrl data arm: dts: omap4-panda: Add I2c pinctrl data arm: dts: omap5-evm: Add mcspi data Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4] ARM: dts: add minimal DT support for DevKit8000.
Hi, On 03/06/2013 06:53 PM, Tony Lindgren wrote: * Anil Kumar anilk...@gmail.com [130305 18:40]: Hi Tony, From: linux-arm-kernel [mailto:linux-arm-kernel- boun...@lists.infradead.org] On Behalf Of Anil Kumar Sent: Wednesday, February 27, 2013 8:03 AM To: devicetree-discuss@lists.ozlabs.org; linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: li...@arm.linux.org.uk; Cousson, Benoit; Tony Lindgren; Grant Likely; Anil Kumar; tho...@tomweber.eu Subject: Re: FW: [PATCH V4] ARM: dts: add minimal DT support for DevKit8000. Hi, DevKit8000 is a beagle board clone from Timll, sold by armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D, S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and JTAG interface. This patch adds the basic DT support for devkit8000. At this time, Information of twl4030 (PMIC), MMC1, I2C1 and leds are added. Signed-off-by: Anil Kumar anilk...@gmail.com Tested-by: Thomas Weber tho...@tomweber.eu Gentle Ping. As there are no review comments on this patch, Could you please pull this patch ? Gentle Ping. This patch also got Reviewed-by: Manish Badarkhe badarkhe.man...@gmail.com and as patch ARM: dts: omap3-devkit8000: Enable audio support has already got Acked-by: Peter Ujfalusi peter.ujfal...@ti.com but it is on the top of this patch. So, Could you please pull this patch in one of your omap branch? or you want me to do rebase this patch on top of v3.9-rc1 ? Let's wait for Benoit to queue it as he has a bunch of .dts changes already applied. Too bad we missed v3.9 merge window for those, but hopefully we can get them queued early for v3.10. Yep, sorry for having missed 3.9, I was a little bit sick at the wrong moment :-( I'm starting queuing the pending patches, and should have enough to push to you just after Linaro Connect. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
+ Jon who was brave enough to take over the OMAP GPIO driver
+ New email address for Kevin since he is no longer at TI :-(.
- Tarun that left TI but I don't have his new email
Hi Linus,
On 02/28/2013 12:41 AM, Linus Walleij wrote:
On Wed, Feb 15, 2012 at 5:04 PM, Benoit Cousson b-cous...@ti.com wrote:
Gosh! That's pretty old stuff :-)
@@ -52,7 +55,8 @@ struct gpio_bank {
struct list_head node;
void __iomem *base;
u16 irq;
- u16 virtual_irq_start;
+ int irq_base;
+ struct irq_domain *domain;
This seems wrong. IRQ domains are used to avoid keeping track of
irq base offsets. I would even say it's the whole point of irq domains.
Well at that time, it was not the only point. We were trying to boot
with DT, and for that irq_domain was mandatory. At the very same time,
Grant was cleaning and consolidating the whole irq_domain
infrastructure, and thus most of the following API were not really
stabilized or even available.
So, this idea was to avoid any regression while allowing DT boot... And
obviously a lot of stuff happened since that good old time.
@@ -669,7 +673,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (!isr)
break;
- gpio_irq = bank-virtual_irq_start;
+ gpio_irqkhil...@ti.com = bank-irq_base;
for (; isr != 0; isr = 1, gpio_irq++) {
gpio_index = GPIO_INDEX(bank, irq_to_gpio(gpio_irq));
Use irq_find_mapping(irqdomain, hwirq) in this function.
@@ -915,7 +919,7 @@ static int gpio_2irq(struct gpio_chip *chip, unsigned
offset)
struct gpio_bank *bank;
bank = container_of(chip, struct gpio_bank, chip);
- return bank-virtual_irq_start + offset;
+ return bank-irq_base + offset;
Use irq_create_mapping() in this function.
+ bank-irq_base = irq_alloc_descs(-1, 0, bank-width, 0);
+ if (bank-irq_base 0) {
+ dev_err(dev, Couldn't allocate IRQ numbers\n);
+ return -ENODEV;
+ }
+
+ bank-domain = irq_domain_add_legacy(node, bank-width,
bank-irq_base,
+0, irq_domain_simple_ops,
NULL);
Use irq_domain_add_simple() and the descs will be allocated for
you as part of the domain creation, when using a pre-fixed base.
Funny, that API was removed while I was writing this patch, and is now
back in town...
If you fix this I suspect the device tree discussion also will fix
itself :-)
Mmm, I hope it is the case, but I'm not sure it will be that easy :-)
Thanks,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support
Hi Florian, On 02/26/2013 05:07 PM, Florian Vaussard wrote: Hi, On 02/07/2013 08:58 AM, Peter Ujfalusi wrote: Hi, On 02/06/2013 02:30 PM, Benoit Cousson wrote: So a patch is being merged to handle triggers in the case of pwm leds [1]. When done, we will be able to add back the default trigger. Do you want to wait on it to merge this series? What kind of dependency do we have between these two series? I mean what will happen if the DTS is merged before the pwm subsystem? If that does not generate any regression / crash, then it is OK, if not, we should take care of the order. In this series the 'linux,default-trigger' property is not added to the pwm-leds node, so it is safe to take this series. I'm sure Florian will send the update to add this flag back for 3.10 or for 3.9-rc (the needed patches for PWM and leds-pwm will be in 3.9). Yes, it is safe to take this series. I will provide a patch to add back the trigger when it is safe to. OK, great, I'll take the series then. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support
Salut Florian, On 02/04/2013 10:14 AM, Florian Vaussard wrote: Hello Benoit, On 01/24/2013 01:21 PM, Benoit Cousson wrote: + Peter who did the original PWM Hi Florian, On 01/23/2013 06:56 PM, Florian Vaussard wrote: Hello Benoit, This patchset adds some new DT supports to the Overo products. The first patch converts the PMIC LEDB output to use the pwm-leds, newly merged in your branch for_3.9/dts. The second patch adds the audio support. Excellent, that looks very good to me, but I'd like to get the feedback from Peter before merging it. So a patch is being merged to handle triggers in the case of pwm leds [1]. When done, we will be able to add back the default trigger. Do you want to wait on it to merge this series? What kind of dependency do we have between these two series? I mean what will happen if the DTS is merged before the pwm subsystem? If that does not generate any regression / crash, then it is OK, if not, we should take care of the order. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] ARM: dts: omap3-overo: Add pwm-leds and audio support
+ Peter who did the original PWM Hi Florian, On 01/23/2013 06:56 PM, Florian Vaussard wrote: Hello Benoit, This patchset adds some new DT supports to the Overo products. The first patch converts the PMIC LEDB output to use the pwm-leds, newly merged in your branch for_3.9/dts. The second patch adds the audio support. Excellent, that looks very good to me, but I'd like to get the feedback from Peter before merging it. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
Hi Santosh, On 01/23/2013 11:55 AM, Santosh Shilimkar wrote: Looping Marc, Benoit On Wednesday 23 January 2013 04:06 PM, Mark Rutland wrote: On Tue, Jan 22, 2013 at 10:05:18PM +, Kukjin Kim wrote: Mark Rutland wrote: + devicetree-discuss, Grant Likely, Rob Herring and Tony Lindgren On Tue, Jan 22, 2013 at 01:41:27AM +, Kukjin Kim wrote: From: Thomas Abraham thomas...@samsung.com Need to be changed requirements in the 'cpus' node for exynos5440 to specify all the per-cpu interrupts of arch timer. The node(s) for the arch timer should not be in the cpus/cpu@N nodes. Instead, there should be one node (in the root of the tree). Well, I don't think so. As per my understanding, the local timers are attached to every ARM cores (cpus) and it generates certain interrupt to the GIC. So the correct representation for this in device tree is to include the interrupts in the cpu nodes in dts file. Your comments refer to a limitation in the Linux kernel implementation of the arch_timer and it should not result in representing the hardware details incorrectly in the dts file. I disagree. The correct representation is whatever the devicetree binding documentation describes. It does not describe placing timer nodes in the cpu nodes. This seems to be exact same topic what is getting discussed here [1] Technically DT is suppose to represent how the hardware is rather than how the bindings are done. But as Marc pointed out, the approach taken currently is to not duplicate the banked information. The thread [1] isn't concluded yet but looks like we might want to avoid duplicating the information considering, more of such duplication needs to follow. e.g gic i/f Am still waiting on what Benoit has to say ? I agree with you :-) I'm not sure the binding was properly done to reflect the HW accurately. A local timer for my point of view should be located in the cpu node like a L1 cache. Or at least referenced in each cpu by a phandle. What was the rational to put it in the root? Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] ARM: dts: OMAP3+: PWM support for TWL and selected boards
Hi Peter, On 01/22/2013 11:11 AM, Peter Ujfalusi wrote: Hi Benoit, I have prepared for you a branch from where you can pull this set on top of mainline v3.8-rc4: Cool thanks, I'll merged it in my branch. Thanks, Benoit Regards, Péter --- The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://gitorious.org/omap-audio/linux-audio.git peter/for-benoit for you to fetch changes up to b6230ae20bc018d042d703d0667ba9e7ac027ccb: ARM: dts: omap4-sdp: Add support for pwm-backlight (2013-01-22 11:08:37 +0100) Peter Ujfalusi (5): ARM: dts: twl4030: Add PWM support ARM: dts: twl6030: Add PWM support ARM: dts: omap3-beagle-xm: Use pwm-leds for pmu_stat LED ARM: dts: omap4-sdp: Add support for pwm-leds (keypad and charging LED) ARM: dts: omap4-sdp: Add support for pwm-backlight arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++ arch/arm/boot/dts/omap4-sdp.dts | 26 ++ arch/arm/boot/dts/twl4030.dtsi| 10 ++ arch/arm/boot/dts/twl6030.dtsi| 12 4 files changed, 58 insertions(+), 4 deletions(-) On 01/18/2013 03:36 PM, Peter Ujfalusi wrote: Hi, Add the needed DT sections for twl4030 and twl6030 for the PWM childs. Update the omap4-sdp to have working backlight and keypad/charging LED support. Use the pwm-leds driver on BeagleBoard for the pmu_stat LED instead of the hacky twl403-gpio mapped PWM. Regards, Peter --- Peter Ujfalusi (5): ARM: dts: twl4030: Add PWM support ARM: dts: twl6030: Add PWM support ARM: dts: omap3-beagle-xm: Use pwm-leds for pmu_stat LED ARM: dts: omap4-sdp: Add support for pwm-leds (keypad and charging LED) ARM: dts: omap4-sdp: Add support for pwm-backlight arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++ arch/arm/boot/dts/omap4-sdp.dts | 26 ++ arch/arm/boot/dts/twl4030.dtsi| 10 ++ arch/arm/boot/dts/twl6030.dtsi| 12 4 files changed, 58 insertions(+), 4 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] ARM: dts: twl6030: Add PWM support
Hi Peter,
Just one minor typo here.
On 01/18/2013 03:36 PM, Peter Ujfalusi wrote:
Enable support for the PWMs and LED as PWM drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/twl6030.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 9996cfc..d9b8b21 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -91,4 +91,16 @@
compatible = ti,twl6030-usb;
interrupts = 4, 10;
};
+
+ twl_pwm: pwm {
+ /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
+ compatible = ti,twl6030-pwm;
+ #pwm-cells = 2;
+ };
+
+ twl_pwmled: pwmled {
+ /* provides one PWM (id 0 for Charing indicator LED) */
typo: charging.
Regards,
Benoit
+ compatible = ti,twl6030-pwmled;
+ #pwm-cells = 2;
+ };
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] ARM: dts: twl6030: Add PWM support
On 01/22/2013 11:49 AM, Peter Ujfalusi wrote:
HI Benoit,
On 01/22/2013 11:39 AM, Benoit Cousson wrote:
+
+ twl_pwm: pwm {
+ /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
+ compatible = ti,twl6030-pwm;
+ #pwm-cells = 2;
+ };
+
+ twl_pwmled: pwmled {
+ /* provides one PWM (id 0 for Charing indicator LED) */
typo: charging.
Aargh. Corrected in the branch.
Thanks,
Pulled and pushed into
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.9/dts
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/2] ARM: dts: OMAP2+: Add PMU nodes
Hi Jon,
On 12/17/2012 06:49 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. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter jon-hun...@ti.com
I've just applied this patch in my for_3.9/dts branch.
I'm wondering if there is any dependency with the previous patch? If
Tony ack it I can take it as well.
Regards,
Benoit
---
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..0a1d38b
--- /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;
+ };
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
Hi Kishon, On 01/10/2013 07:19 AM, kishon wrote: On Friday 28 December 2012 12:05 AM, Aaro Koskinen wrote: Hi, On Thu, Sep 20, 2012 at 05:21:15AM +0200, Benoit Cousson wrote: On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include ARM: dts: * Added reg property and interrupt property for usb_otg_hs. Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data Thanks for the update. I've just pulled the series for 3.7. I wonder what happened to the patch #3 (Add usb_otg and glue data) of this series? Why was it dropped? I cannot see it in 3.7 or 3.8-rc1. I don't remember the context, can you repost it rebased on 3.8-rc2? Did it generate some discussion at that time? Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: omap: Add omap-usb2 dt data
On 01/10/2013 10:31 AM, kishon wrote:
Hi Benoit,
On Wednesday 19 September 2012 04:02 PM, Kishon Vijay Abraham I wrote:
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
This patch is also missing in mainline :-(
Well, in that case this was done on purpose :-)
Thanks
Kishon
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4fbb9dc..28eaddc 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -303,6 +303,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+usb2phy@4a0ad080 {
+compatible = ti,omap-usb2;
+reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x4; /* TO BE REMOVED: SCM */
Rob and I did not agree to use that temp hack in the case of DT, so you
were supposed to repost with a proper driver for the SCM part that
control the USB.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] can: Add D_CAN raminit support to am335x-evm
Hi Anil, On 11/14/2012 07:08 PM, AnilKumar Ch wrote: This patch series adds d_can raminit support to c_can/d_can driver, which is required to init/de-init D_CAN message RAM (holds message objects). Added corresponding DT changes to get resource of RAMINIT register and device instance. These patches were tested on AM335x-EVM along with pinctrl data addition patch, which is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1. AnilKumar Ch (3): can: c_can: Add d_can raminit support ARM: dts: AM33XX: Add d_can instances to aliases ARM: dts: AM33XX: Add memory resource to d_can node I've just applied both DTS patches with Acked-by from Marc in my for_3.9/dts branch. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND] ARM: dts: AM33XX: Rename I2C and GPIO nodes
Hi Anil, On 01/02/2013 11:12 AM, AnilKumar, Chimata wrote: On Wed, Nov 21, 2012 at 17:22:17, AnilKumar, Chimata wrote: Rename I2C and GPIO nodes according to AM33XX TRM. According to AM33XX TRM device instances are starting from 0 like i2c0, i2c1 and i2c3. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com [pa...@antoniou-consulting.com: initial patch by pantelis's] Signed-off-by: AnilKumar Ch anilku...@ti.com --- Changes from first version: - Updated pantelis's patch * Modified based on linux-omap/master * Added GPIO nodes renaming as well Hi Tony/Benoit, If there are no comments could you please pull this patch? Yep, it is done. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.9/dts Regards, 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 jon-hun...@ti.com
---
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 linux/of.h
+
#include asm/pmu.h
#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 jon-hun...@ti.com
---
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
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 javier.marti...@collabora.co.uk 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 matthias@gmail.com
---
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 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 javier.marti...@collabora.co.uk
Acked-by: Matthias Brugger matthias@gmail.com
---
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 jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.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.
+ */
+/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 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
