Re: [PATCH 1/5] hwmon: ina2xx: bail-out from ina2xx_probe() in case of configuration errors
Hi Guenter, On 26/11/2014 04:05, Guenter Roeck wrote: [...] Looking into the available documents, I am quite sure that the resistor is changed by replacing the probe, in other words by pulling the board with the ina226 and replacing it with another one. Given that, configuring the shunt resistor value with a sysfs attribute is really the wrong way to do it; you should use probe specific devicetree overlays instead. Unfortunately, that's not dynamic enough for all the use cases we need to support with the probes. In fact, most customers will rather put the shunts on their board and thus use a shunt-less version of the probe to do the measurement. In that case, there is no way we can hard code, even in a DTS, the shunt value. That's for that kind of usage that we do need to be able to set the shunt value at runtime. The probe in that case can be pluged dynamically on different board jumpers to do the measurement. Later, thanks to the web UI, the user will be able to configure the shunt value based on the way they were plugged to its boards. sysfs seems to be the easiest way to do that. I don't think DT overlay can handle that, since it is depend of the targeted system and not on the measurement system. Thanks, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Update entry for omap related .dts files to cover new SoCs
Hi Nishanth, On 21/10/2014 22:24, Nishanth Menon wrote: DRA7(including AM5x) and AM47x series are handled under OMAP umbrella. These SoC support and dts have been added since 3.14 kernel and Pull requests for these have come in from OMAP till date. So just ensure that get_maintainers can pick up this list as well. Cc: Benoît Cousson Cc: Tony Lindgren Cc: linux-o...@vger.kernel.org Cc: devicet...@vger.kernel.org Signed-off-by: Nishanth Menon Acked-by: Benoît Cousson Thanks, Benoit --- MAINTAINERS |3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a20df9b..e205bd2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6585,6 +6585,9 @@ L:devicet...@vger.kernel.org S:Maintained F:arch/arm/boot/dts/*omap* F:arch/arm/boot/dts/*am3* +F: arch/arm/boot/dts/*am4* +F: arch/arm/boot/dts/*am5* +F: arch/arm/boot/dts/*dra7* OMAP CLOCK FRAMEWORK SUPPORT M:Paul Walmsley -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
On 28/02/2014 23:17, Tony Lindgren wrote:
* Jack Mitchell [140122 03:09]:
From: Jack Mitchell
Devicetree include file for setting up the am335x mcasp bus, i2c-2
bus, and audio codec required for a functioning BeagleBone Audio Cape.
Signed-off-by: Jack Mitchell
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124 +
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++
2 files changed, 138 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
new file mode 100644
index 000..b8ec3dc
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2014 Jack Mitchell
+ *
+ * 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.
+ *
+ * In order to enable the BeagleBone Audio Cape this dtsi must be
+ * incuded in the top level dts. On BeagleBone Black hardware the
+ * status of the HDMI dts node must also be set to "disabled".
Seems like this is unsafe to merge then? This probably also needs
comments from Peter Ujfalusi, added him to Cc.
Maybe, we'd better define a new DTS board (like
am335x-boneblack-audio.dts) if we cannot use audio cape without losing
the HDMI.
Since we don't have mechanism like overlay, we don't have the choice but
defining several boards for each cape variant.
BTW, what is the conflict source with HDMI?
At some point I remember that the mcasp for audio cape was broken
because of changes in the mcasp for the HDMI, but it is not the case
anymore, thanks to the cleanup from Jyri.
+ * --- a/arch/arm/boot/dts/am335x-bone.dts
+ * +++ b/arch/arm/boot/dts/am335x-bone.dts
+ * @@ -9,6 +9,7 @@
+ *
+ * #include "am33xx.dtsi"
+ * #include "am335x-bone-common.dtsi"
+ * +#include "am335x-bone-audio-cape-reva.dtsi"
+ *
+ * &ldo3_reg {
+ * regulator-min-microvolt = <180>;
+ *
+ * On BeagleBone Black hardware the status of the HDMI dts node must
+ * also be set to "disabled"
+ *
+ * --- a/arch/arm/boot/dts/am335x-boneblack.dts
+ * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
+ * @@ -73,6 +74,6 @@
+ * pinctrl-names = "default", "off";
+ * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+ * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+ * - status = "okay";
+ * + status = "disabled";
+ * };
+ * };
+ */
+
+/ {
+ sound {
+ compatible = "ti,da830-evm-audio";
+ ti,model = "AM335x BeagleBone Audio Cape Rev. A";
+ ti,audio-codec = <&tlv320aic3106>;
+ ti,mcasp-controller = <&mcasp0>;
+ ti,codec-clock-rate = <1200>;
+ ti,audio-routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+ };
+
+ audio-cape-gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bone_audio_cape_led_pins>;
+
+ audio-led0 {
+ label = "audio:green:usr0";
+ gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ audio-led1 {
+ label = "audio:green:usr1";
+ gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ };
+};
+
+&am33xx_pinmux {
+ bone_audio_cape_led_pins: pinmux_bone_audio_cape_led_pins {
+ pinctrl-single,pins = <
+ 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a2.gpio1_18 */
+ 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a3.gpio1_19 */
+ >;
+ };
+
+ bone_audio_cape_pins: bone_audio_cape_pins {
+ pinctrl-single,pins = <
+ 0x190 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mcasp0_aclkx.mcasp0_aclkx */
+ 0x194 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mcasp0_fsx.mcasp0_fsx */
+ 0x19c (PIN_INPUT_PULLUP | MUX_MODE2)/*
mcasp0_ahclkr.mcasp0_axr2 */
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE2)/*
mcasp0_ahclkx.mcasp0_axr3 */
+ >;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
+ status = "okay";
+ clock-frequency = <10>;
+
+ tlv320aic3106: tlv320aic3106@1b {
A more generic name will be prefered here.
Re
Re: [PATCH 1/3] ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
Salut Paul,
On 08/12/2013 17:26, Paul Walmsley wrote:
Hi Benoît,
On Tue, 3 Dec 2013, Roger Quadros wrote:
Without this, the USB devices are sometimes not detected on OMAP4 Panda
with u-boot v2013.10.
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Reported-by: Tomi Valkeinen
Signed-off-by: Roger Quadros
Acked-by: Paul Walmsley
Will you pick this up for the -rc series, or do you want me or Tony to?
Roger writes that this one's pretty important.
I guess, it is better for you to take it. I don't have anything queued
for -rc.
Acked-by: Benoit Cousson
Thanks,
Benoit
- Paul
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 +++--
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e5b12c..3318cae9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2937,7 +2937,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_usb_host_hs_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -3001,15 +3001,7 @@ static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 9e08d69..e297d62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1544,7 +1544,8 @@ static struct omap_hwmod_class_sysconfig
omap54xx_usb_host_hs_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
- SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -1598,15 +1599,7 @@ static struct omap_hwmod omap54xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = "l3init_60m_fclk",
.prcm = {
.omap4 = {
--
1.8.3.2
- Paul
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ARM: dts: omap5-uevm: Audio related fixes
Hi Peter, On 23/10/2013 11:32, Peter Ujfalusi wrote: Hi, When the omap5-evm.dts file has been renamed to omap5-uevm.dts and the sEVM support got deprecated in favor of uEVM (or Panda5) the content was not validated. The reset GPIO is different on uEVM compared to sEVM and uEVM does not have support for dmic. Regards, Peter I've just applied your series, let's try to push that for 3.13. Thanks, Benoit --- Peter Ujfalusi (2): ARM: dts: omap5-uevm: Correct twl6040 reset GPIO pinmux ARM: dts: omap5-uevm: Remove pinmux for dmic pins arch/arm/boot/dts/omap5-uevm.dts | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
On 23/10/2013 10:19, Tony Lindgren wrote: * Bryan Wu [131022 10:47]: On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren wrote: * Bryan Wu [131022 10:23]: On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren wrote: * Sebastian Reichel [131022 06:02]: This patch moves the handling of the chip's enable pin from the board code into the driver. It also updates all board-code files using the driver to incorporate this change. This is needed for device tree support of the enable pin. This seems safe to merge along with the other LED patches, the changes to arch/arm/mach-omap2 should not conflict with anything. So for the arch/arm/mach-omap2 changes: Acked-by: Tony Lindgren I'm OK for LED parts, will this patch go through omap tree? If so, please add my ack. Acked-by: Bryan Wu It's probably best that you take it via with the LED patches. OK, I will do it. what about PATCH 2 of this patch set? Will you take care of it? Benoit should take that one, otherwise there's a good chance of pointless merge conflicts with the .dts files. I've just merged it. Regards, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/14] DTS: ARM: OMAP3-N900: Add misc. HW
Hi Sebastian, On 23/10/2013 00:49, Sebastian Reichel wrote: This patchset adds misc. hardware elements to the Nokia N900 DTS file. Apart from the last two patches the kernel drivers in 3.12 are already capable of handling the DT entries. The series is based on bcousson/linux-omap-dt.git:for_3.13/dts. Thanks, I've just applied the whole series. Regards, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Hi Nishanth, On 16/10/2013 17:39, Nishanth Menon wrote: Hi, This series enables the use of cpufreq-cpu0 generic driver for all OMAP and related derivatives. Only patch#8 in the series, which introduces CPU clock nodes, depends on Tero's V8 patch series for clock nodes[1] I will stop copy pasting the series complete history and point at [2]. Main changes since V6[3]: - squashed patches for a minimal set - i have organized the series such that 1 to 7 can immediately be merged if desired: - patches 1,2,3 can go to Tony's omap-for-v3.13/quirk [4] - patches 4-7 can go to Benoit's for_3.13/dts [5] I've just applied them in my DTS tree. Thanks, Benoit - patch 8 needs to depend on [1] and should eventually go to [5] NOTES: obviously without clock nodes cpufreq will not function. Test Script: http://pastebin.com/VvJPjsne Test-log: BeagleBoard-XM (OMAP36xx): http://pastebin.com/XZDNaHPf PandaBoard-ES (OMAP4460): http://pastebin.com/qQCmA2ng BeagleBone-Black(AM335x): http://pastebin.com/98FX4uYW OMAP5uEVM (OMAP5432): http://pastebin.com/NXj3L636 DRA7-EVM (DRA7xx): http://pastebin.com/0kKT3TXy J Keerthy (3): ARM: dts: dra7-evm: add smps123 supply for CPU ARM: dts: OMAP5: Add CPU OPP table ARM: dts: DRA7: Add CPU OPP table Nishanth Menon (5): ARM: OMAP3+: do not register non-dt OPP tables for device tree boot ARM: OMAP2+: add missing lateinit hook for calling pm late init ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot ARM: dts: omap5-uevm: add smps123 supply for CPU ARM: dts: OMAP3: add clock nodes for CPU [1] http://marc.info/?t=13813328426&r=1&w=2 [2] http://marc.info/?l=linux-arm-kernel&m=136804009618594&w=2 [3] http://marc.info/?l=devicetree&m=138135419203492&w=2 [4] https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.13/quirk arch/arm/boot/dts/am33xx.dtsi |4 arch/arm/boot/dts/dra7-evm.dts |4 arch/arm/boot/dts/dra7.dtsi | 13 - arch/arm/boot/dts/omap3.dtsi|5 + arch/arm/boot/dts/omap4.dtsi|5 + arch/arm/boot/dts/omap5-uevm.dts|4 arch/arm/boot/dts/omap5.dtsi| 15 ++- arch/arm/mach-omap2/board-generic.c |4 arch/arm/mach-omap2/common.h|4 arch/arm/mach-omap2/io.c| 20 arch/arm/mach-omap2/opp.c |4 arch/arm/mach-omap2/pm.c| 12 +--- 12 files changed, 89 insertions(+), 5 deletions(-) Regards, Nishanth Menon -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv3 7/7] ARM: dts: N900: Add SSI information
Hi Sebastian, On 22/10/2013 16:44, Sebastian Reichel wrote: Hi Benoit, On Tue, Oct 22, 2013 at 02:48:45PM +0200, Benoit Cousson wrote: Thanks to Tony, I've just realized that I missed all your patches, that for some reason ended-up in my junk folder :-( oh :( Can you check why they ended up in junk? I would like to prevent more mails going there. That being said, I cannot apply any of your DTS patches! What base branch are you using? Currently torvalds/master with pavel's n900 patch and some more patches from me. Mmm, looks like I missed these patches :-) Could you repost all your pending DTS patches in one series rebased on top of my for_3.13/dts? Sure. DT maintainers haven't given feedback since the last patchset [0]. Do you want to wait for feedback from them? OK, maybe not the SSI series that is still RFC, but I guess all the others ones are fine to be merged. Could you repost the whole N900 DTS patches (beside SSI) in one series rebased on top of mine? Thanks, Benoit [0] https://lkml.org/lkml/2013/9/23/529 -- Sebastian -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Add support for Newflow NanoBone board
Hi Mark,
On 04/10/2013 10:15, Mark Jackson wrote:
NanoBone Specification:
---
CPU:
TI AM335x
Memory:
256MB DDR3
128MB NOR flash
128KB FRAM
Ethernet:
2 x 10/100 connected to SMSC LAN8710 PHY
USB:
1 x USB2.0 Type A
I2C:
2Kbit EEPROM (Microchip 24AA02)
RTC (Maxim DS1338)
GPIO Expander (Microchip MCP23017)
Expansion connector:
6 x UART
1 x MMC/SD
1 x USB2.0
Signed-off-by: Mark Jackson
Reviewed-by: Javier Martinez Canillas
Thanks I've just applied it.
Regards,
Benoit
---
Changes in v3:
- Added MMC support
- Fixed regulator limits
Changes in v2:
- Reworked to use existing device nodes as suggested by Javier
MAINTAINERS |6 +
arch/arm/boot/dts/Makefile|1 +
arch/arm/boot/dts/am335x-nano.dts | 431 +
3 files changed, 438 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-nano.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index e61c2e8..8a4c9d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6062,6 +6062,12 @@ L: linux-o...@vger.kernel.org
S:Maintained
F:drivers/gpio/gpio-omap.c
+OMAP/NEWFLOW NANOBONE MACHINE SUPPORT
+M: Mark Jackson
+L: linux-o...@vger.kernel.org
+S: Maintained
+F: arch/arm/boot/dts/am335x-nano.dts
+
OMFS FILESYSTEM
M:Bob Copeland
L:linux-karma-de...@lists.sourceforge.net
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e95af3f..543e837 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+ am335x-nano.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb
diff --git a/arch/arm/boot/dts/am335x-nano.dts
b/arch/arm/boot/dts/am335x-nano.dts
new file mode 100644
index 000..9907b49
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -0,0 +1,431 @@
+/*
+ * Copyright (C) 2013 Newflow Ltd - http://www.newflow.co.uk/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+
+/ {
+ model = "Newflow AM335x NanoBone";
+ compatible = "ti,am33xx";
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&dcdc2_reg>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led@0 {
+ label = "nanobone:green:usr1";
+ gpios = <&gpio1 5 0>;
+ default-state = "off";
+ };
+ };
+};
+
+&am33xx_pinmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&misc_pins>;
+
+ misc_pins: misc_pins {
+ pinctrl-single,pins = <
+ 0x15c (PIN_OUTPUT | MUX_MODE7) /* spi0_cs0.gpio0_5 */
+ >;
+ };
+
+ gpmc_pins: gpmc_pins {
+ pinctrl-single,pins = <
+ 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad7.gpmc_ad7 */
+ 0x20 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad8.gpmc_ad8 */
+ 0x24 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad9.gpmc_ad9 */
+ 0x28 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad10.gpmc_ad10 */
+ 0x2c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad11.gpmc_ad11 */
+ 0x30 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad12.gpmc_ad12 */
+ 0x34 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad13.gpmc_ad13 */
+ 0x38 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad14.gpmc_ad14 */
+ 0x3c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad15.gpmc_ad15 */
+
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x80 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn1.gpmc_csn
Re: [RFCv3 7/7] ARM: dts: N900: Add SSI information
Hi Sebastian,
Thanks to Tony, I've just realized that I missed all your patches, that
for some reason ended-up in my junk folder :-(
That being said, I cannot apply any of your DTS patches! What base
branch are you using?
Could you repost all your pending DTS patches in one series rebased on
top of my for_3.13/dts?
Thanks,
Benoit
On 06/10/2013 22:27, Sebastian Reichel wrote:
Add SSI device tree data for OMAP3 and Nokia N900.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/omap3-n900.dts | 12 ++
arch/arm/boot/dts/omap3.dtsi | 47
2 files changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 0582356..0fbb77e 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -186,6 +186,18 @@
power = <50>;
};
+&ssi_port1 {
+ ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
+
+ ssi-char {
+ compatible = "ssi-char";
+ };
+};
+
+&ssi_port2 {
+ status = "disabled";
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..9f60b82 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -532,5 +532,52 @@
num-eps = <16>;
ram-bits = <12>;
};
+
+ ssi: ssi-controller@48058000 {
+ compatible = "ti,omap3-ssi";
+ ti,hwmods = "ssi";
+
+ reg = <0x48058000 0x1000>,
+ <0x48059000 0x1000>;
+ reg-names = "sys",
+ "gdd";
+
+ interrupts = <71>;
+ interrupt-names = "gdd_mpu";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ ssi_port1: ssi-port@0 {
+ compatible = "ti,omap3-ssi-port";
+
+ reg = <0x4805a000 0x800>,
+ <0x4805a800 0x800>;
+ reg-names = "tx",
+ "rx";
+
+ interrupt-parent = <&intc>;
+ interrupts = <67>,
+<68>;
+ interrupt-names = "mpu_irq0",
+ "mpu_irq1";
+ };
+
+ ssi_port2: ssi-port@1 {
+ compatible = "ti,omap3-ssi-port";
+
+ reg = <0x4805b000 0x800>,
+ <0x4805b800 0x800>;
+ reg-names = "tx",
+ "rx";
+
+ interrupt-parent = <&intc>;
+ interrupts = <69>,
+<70>;
+ interrupt-names = "mpu_irq0",
+ "mpu_irq1";
+ };
+ };
};
};
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: am4372: Add McASP nodes
On 22/10/2013 09:46, Peter Ujfalusi wrote:
Hi,
On 10/21/2013 10:01 PM, Sergei Shtylyov wrote:
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c328d5c..defaad1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -633,5 +633,32 @@
dma-names = "tx", "rx";
};
+mcasp0: mcasp@48038000 {
According to ePAPR spec [1], "the name of a node should be somewhat
generic, reflecting the function of the device and not its
precise programming model". In this case probably "sound"?
We use the 'sound' node name for the sound card itself. The case with McASP is
a bit complicated. It can operate in I2S mode (and similar protocols like RJM,
LJM, TDM) or it can interface with S/PDIF, IEC60958-1, AES-3 codecs.
The mode we put McASP depends on the external components, so the same McASP
can be used in I2S mode in one board while on the other it can be S/PDIF.
It would have been convenient if I could use 'i2s' as node name but it is not
true for McASP (Tegra, Exynos for example have I2S, AC97, S/PDIF as separate
IP).
IMHO the 'mcasp' is still the best node name for this IP. McASP stands for:
'Multichannel Audio Serial Port' and this is pretty much what McASP is.
Yes, I do agree, there are tons of nodes that cannot have generic name.
Moreover, we are already using that name in few OMAP dts, so for
consistency, let's keep that name.
Benoit
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: omap3-beagle: Adapt USB OTG to generic PHY framework
Hi Roger,
On 18/10/2013 14:00, Roger Quadros wrote:
Hi Benoit,
Could you please include this one for 3.13?
Without this OTG port will be broken for beagle. Thanks.
I've just applied it.
Thanks,
Benoit
cheers,
-roger
On 10/07/2013 01:46 PM, Roger Quadros wrote:
The generic PHY framewrok expects different properties than the
old USB PHY framework. Supply those properties.
Fixes USB OTG port on beagle after the Generic PHY framework was
merged in greg/usb-next. [1]
[1] - https://lkml.org/lkml/2013/9/27/581
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 7669c16..fa532aa 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -173,6 +173,8 @@
&usb_otg_hs {
interface-type = <0>;
usb-phy = <&usb2_phy>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
mode = <3>;
power = <50>;
};
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] ARM: dts: omap5: Add dr_mode for dwc3
Hi Kishon, On 16/10/2013 15:17, Kishon Vijay Abraham I wrote: Benoit, On Tuesday 15 October 2013 11:19 AM, Kishon Vijay Abraham I wrote: From: George Cherian Added dr_mode property in dwc3 and set its default mode to device. Currently dwc3 driver doesn't have support for OTG mode. So explicitly setting to peripheral even dwc3 is a OTG controller since OMAP5 has already got an EHCI host. Signed-off-by: George Cherian Signed-off-by: Kishon Vijay Abraham I Can you take this patch for 3.13? I've just applied it. Thanks, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
Hi Kishon, On 16/10/2013 15:27, Nishanth Menon wrote: On 10/16/2013 08:17 AM, Kishon Vijay Abraham I wrote: Benoit, On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote: smps10 should be enabled only in the case of host mode. So stop doing always_on, boot_on from smps10_out1. The driver will enable it in host mode. Can you take this patch too? Acked-by: Nishanth Menon I've just applied it. Thanks, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: omap4-panda-es: Do not reset gpio1
Hi Nishanth,
On 10/10/2013 18:44, Nishanth Menon wrote:
Do not reset GPIO1 at boot-up because GPIO 7 in GPIO1 block is used on
OMAP4460 PandaBoard-ES to select voltage register in TPS62361 which
supplies VDD_MPU.
Without this, OMAP4460 PandaBoard-ES boards fail to boot-up because
MPU voltage switches over to VSET0 voltage value (boot voltage) which
is not sufficient to operate the device at OPP100.
Signed-off-by: Nishanth Menon
---
As explained here: http://marc.info/?l=u-boot&m=133066647800872&w=2
GPIO1 reset causes PandaBoard-ES to stop functioning.
This depends on Patch series from Rajendra:
http://marc.info/?l=linux-doc&m=138131355520116&w=2
Applies on Benoit's for_13/dts branch:
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
I've just applied it after Rajendra's series.
Thanks,
Benoit
Tested on PandaBoard-ES without the u-boot uenv hack
arch/arm/boot/dts/omap4-panda-es.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 56c4354..816d1c9 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -62,3 +62,7 @@
gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
};
};
+
+&gpio1 {
+ti,no-reset-on-init;
+};
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: dts: omap3: Adapt USB OTG to generic PHY framework
Hi Roger, On 14/10/2013 11:20, Roger Quadros wrote: Hi Benoit, On 10/10/2013 06:34 PM, Felipe Balbi wrote: On Mon, Oct 07, 2013 at 04:28:13PM +0300, Roger Quadros wrote: The generic PHY framewrok expects different properties than the old USB PHY framework. Supply those properties. Fixes USB OTG port on GAT04 and N900 after the Generic PHY framework was merged in greg/usb-next. [1] [1] - https://lkml.org/lkml/2013/9/27/581 Signed-off-by: Roger Quadros Acked-by: Felipe Balbi Could you please pick this one for 3.13? Thanks. I don't see it in your 3.13 take 2 pull request. It was not in it. I've just applied it. Thanks Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] AM33XX crypto DTS patches
Hi Joel, n 05/10/2013 21:04, Joel Fernandes wrote: These patches are some minor fixups and changes to commit messages to the AM33XX crypto (aes, sham) patches with reference to the comments at: http://comments.gmane.org/gmane.linux.drivers.devicetree/45961 Joel Fernandes (1): ARM: dts: AM33XX: Fix AES interrupt number Mark A. Greer (2): ARM: dts: AM33XX: Add SHAM data and documentation ARM: dts: AM33XX: Add AES data and documentation .../devicetree/bindings/crypto/omap-aes.txt| 31 ++ .../devicetree/bindings/crypto/omap-sham.txt | 28 +++ arch/arm/boot/dts/am335x-bone.dts | 8 ++ arch/arm/boot/dts/am335x-evm.dts | 8 ++ arch/arm/boot/dts/am335x-evmsk.dts | 8 ++ arch/arm/boot/dts/am33xx.dtsi | 19 + 6 files changed, 102 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt I've just applied this series and the remaining ones from the previous version. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/9] am33xx: dts: Fix AES interrupt number
On 30/09/2013 17:13, Joel Fernandes wrote: Signed-off-by: Joel Fernandes Even if this is obvious, a small changelog is always recommended. Thanks, Benoit --- arch/arm/boot/dts/am33xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 0daa1b2..d7be90a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -724,7 +724,7 @@ compatible = "ti,omap4-aes"; ti,hwmods = "aes"; reg = <0x5350 0xa0>; - interrupts = <102>; + interrupts = <103>; dmas = <&edma 6 &edma 5>; dma-names = "tx", "rx"; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: AM33XX: add ethernet alias's for am33xx
Hi Dan, On 03/10/2013 01:39, Mugunthan V N wrote: On Wednesday 02 October 2013 12:58 PM, Dan Murphy wrote: Set the alias for ethernet0 and ethernet1 so that uBoot can set the MAC address appropriately. Currently uBoot cannot find the alias and there for does not set the MAC address. Signed-off-by: Dan Murphy Tested this with beagle bone black. Tested-by: Mugunthan V N Regards Mugunthan V N Thanks, pulled in my for_3.13/dts branch. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
On 03/10/2013 15:58, Roger Quadros wrote:
Hi Benoit,
On 10/03/2013 04:44 PM, Benoit Cousson wrote:
On 03/10/2013 14:05, Benoit Cousson wrote:
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
In fact it does not apply correctly on my for_3.13/dts branch :-(
error: arch/arm/boot/dts/omap3-beagle.dts: patch does not apply
Patch failed at 0004 ARM: dts: omap3-beagle: Make USB host pin naming consistent
Could you rebase it?
Looks like it was already applied before. Could you please skip that and use
the rest?
I've checked that the remaining patches apply fine on top of your for_3.13/dts
branch.
Indeed, it was already there :-)
Sorry for the noise.
Benoit
cheers,
-roger
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in
this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
-/* HS USB Port 2 RESET */
-hsusb2_reset: hsusb2_reset_reg {
-compatible = "regulator-fixed";
-regulator-name = "hsusb2_reset";
-regulator-min-microvolt = <330>;
-regulator-max-microvolt = <330>;
-gpio = <&gpio5 19 0>;/* gpio_147 */
-startup-delay-us = <7>;
-enable-active-high;
-};
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
-reset-supply = <&hsusb2_reset>;
+reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
On 03/10/2013 14:05, Benoit Cousson wrote:
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
In fact it does not apply correctly on my for_3.13/dts branch :-(
error: arch/arm/boot/dts/omap3-beagle.dts: patch does not apply
Patch failed at 0004 ARM: dts: omap3-beagle: Make USB host pin naming
consistent
Could you rebase it?
Thanks,
Benoit
Thanks,
Benoit
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in
this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
-/* HS USB Port 2 RESET */
-hsusb2_reset: hsusb2_reset_reg {
-compatible = "regulator-fixed";
-regulator-name = "hsusb2_reset";
-regulator-min-microvolt = <330>;
-regulator-max-microvolt = <330>;
-gpio = <&gpio5 19 0>;/* gpio_147 */
-startup-delay-us = <7>;
-enable-active-high;
-};
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
-reset-supply = <&hsusb2_reset>;
+reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes
regulator-boot-on;
>>> +};
>>> +
>>> +ldo2_reg: ldo2 {
>>> +/* VDD_RTCIO */
>>> +/* LDO2 -> VDDSHV5, LDO2 also goes to
>>> CAN_PHY_3V3 */
>>> +regulator-name = "ldo2";
>>> +regulator-min-microvolt = <330>;
>>> +regulator-max-microvolt = <330>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldo3_reg: ldo3 {
>>> +/* VDDA_1V8_PHY */
>>> +regulator-name = "ldo3";
>>> +regulator-min-microvolt = <180>;
>>> +regulator-max-microvolt = <180>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldo9_reg: ldo9 {
>>> +/* VDD_RTC */
>>> +regulator-name = "ldo9";
>>> +regulator-min-microvolt = <105>;
>>> +regulator-max-microvolt = <105>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldoln_reg: ldoln {
>>> +/* VDDA_1V8_PLL */
>>> +regulator-name = "ldoln";
>>> +regulator-min-microvolt = <180>;
>>> +regulator-max-microvolt = <180>;
>>> +regulator-always-on;
>>> +regulator-boot-on;
>>> + };
>>> +
>>> +ldousb_reg: ldousb {
>>> +/* VDDA_3V_USB: VDDA_USBHS33 */
>>> +regulator-name = "ldousb";
>>> +regulator-min-microvolt = <330>;
>>> +regulator-max-microvolt = <330>;
>>> +regulator-boot-on;
>>> +};
>>> +
Nit: Extra blank line not needed.
>>> +};
>>> +};
>>> +};
>>> };
Nit: You have an extra level on indentation not needed.
>>> &i2c2 {
>>>
>> Acked-by: Nishanth Menon
Beside the two minors nits, the patch looks good to me.
Since, you've been waiting for some time for it, I fixed it myself and pulled
it.
I even fixed the changelog... Lucky you :-)
You can check the updated version below.
Sorry for the delay.
Thanks,
Benoit
---
>From 3b8f02a2df475c7a48e12eb1911c014f8060b167 Mon Sep 17 00:00:00 2001
From: Keerthy
Date: Mon, 26 Aug 2013 11:06:51 +0530
Subject: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes
Add DT nodes for TPS659038 PMIC on DRA7 boards.
It is based on top of:
http://comments.gmane.org/gmane.linux.ports.arm.omap/102459.
Documentation:
- Documentation/devicetree/bindings/mfd/palmas.txt
- Documentation/devicetree/bindings/regulator/palmas-pmic.txt
Boot Tested on DRA7 d1 Board.
Signed-off-by: Keerthy
Acked-by: Nishanth Menon
[bcous...@baylibre.com: Fix indentation and changelog]
Signed-off-by: Benoit Cousson
---
arch/arm/boot/dts/dra7-evm.dts | 112 +
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ca5dab2..fbbe406 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,118 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
clock-frequency = <40>;
+
+ tps659038: tps659038@58 {
+ compatible = "ti,tps659038";
+ reg = <0x58>;
+
+ tps659038_pmic {
+ compatible = "ti,tps659038-pmic";
+
+ regulators {
+ smps123_reg: smps123 {
+ /* VDD_MPU */
+ regulator-name = "smps123";
+ regulator-min-microvolt = < 85>;
+ regulator-max-microvolt = <125>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ /* VDD_DSPEVE *
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
Thanks,
Benoit
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = "regulator-fixed";
- regulator-name = "hsusb2_reset";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio5 19 0>; /* gpio_147 */
- startup-delay-us = <7>;
- enable-active-high;
- };
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
- reset-supply = <&hsusb2_reset>;
+ reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] ARM: dts: Beaglebone MMC fixes
Hi Koen, On 12/09/2013 20:35, Koen Kooi wrote: Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 I've just applied it on top of Joel's one. Thanks, Benoit Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 564fc88cc64387af5312e2abd8019c75a13223b2 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + e5133ed98acc1c3e01c370b851041a8ca629cd15 ARM: EDMA: Fix clearing of unused list for DT DMA resources + ac71bb58605d3bdd5d14af770a639fb3ff11c612 ARM: dts: add AM33XX EDMA support + 31a8270a299c57c7de7510f44d9dc36fd1787243 ARM: dts: add AM33XX SPI DMA support + 4fa0a4cb9ea17da30cf43085c03e5ec1361a4fc2 ARM: dts: add AM33XX MMC support and documentation + 0553f50bd45f019a0cc11050e2f20bddbf07dfe0 ARM: dts: am335x-bone: add CD for mmc1 + 7d64f765630a2921a63b82f93f9959a6de37f29d ARM: dts: am335x-boneblack: add eMMC DT entry + dc96cd4003e2668d8ec7e7fe19e402e97a198f81 ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode + f8262e78830cda56c936724549ba9f04e312 ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline Changes since v3: Addressed Nishants nitpicks for commit messages Addressed Russ' comments about moving LDO3 for mmc1 out of the common dtsi Changes since v2: Missing pinmux entries for eMMC added Changes since v1: Removed ti,non-removable entry from eMMC node, see http://marc.info/?l=linux-arm-kernel&m=137889435710552&w=2 --- Alexander Holler (1): arm: bone: dts: add CD for mmc1 Koen Kooi (3): am335x-boneblack: add eMMC DT entry ARM: am335x-bone-common: switch mmc1 to 4-bit mode ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers arch/arm/boot/dts/am335x-bone-common.dtsi | 39 +++ arch/arm/boot/dts/am335x-bone.dts | 1 - arch/arm/boot/dts/am335x-boneblack.dts| 14 +++ 3 files changed, 53 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] ARM: dts: am335x-boneblack: add eMMC DT entry
Hi Tony,
On 13/09/2013 17:27, Tony Lindgren wrote:
* Koen Kooi [130912 11:43]:
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 0d95d54..bc8d1a2 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -113,6 +113,21 @@
0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
>;
};
+
+ emmc_pins: pinmux_emmc_pins {
+ pinctrl-single,pins = <
+ 0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk, INPUT_PULLUP | MODE2 */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd, INPUT_PULLUP | MODE2 */
+ 0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0, INPUT_PULLUP | MODE1 */
+ 0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1, INPUT_PULLUP | MODE1 */
+ 0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2, INPUT_PULLUP | MODE1 */
+ 0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3, INPUT_PULLUP | MODE1 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4, INPUT_PULLUP | MODE1 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5, INPUT_PULLUP | MODE1 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6, INPUT_PULLUP | MODE1 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7, INPUT_PULLUP | MODE1 */
+ >;
+ };
};
ocp {
Here you can now use just the defines to make it a bit shorter:
0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn1.mmc1_clk */
Considering that Koen has just disappeared for a 3 weeks honeymoon, I'll
fix the patch. GIT does complain about various trailing spaces and end
of file issue for this patch as well :-(
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] ARM: dts: Enable EDMA, MMC and SPI on AM33XX for v3.13
Hi Joel, Thanks for the repost. I'll applied that one now. Regards, Benoit On 10/09/2013 21:24, Joel Fernandes wrote: Here are last few patches required to add EDMA and MMC/SPI support for AM33xx. Now that all dependent DMA patches and fixes are in linux next or mainline, except for [1] which should go in for 3.12 -rc cycle, it is safe to enable MMC and SPI support and this patch series enables it. These are originally Matt Porter's patches with changes to make it work with recent kernels, addition of irq, memory resources and enable other extra properties. These patches should cleanly apply on master branch after Koen's patch [2] for basic BBB DT support is applied. MMC support is enabled for: Beaglebone, AM335x EVM and EVM-SK boards. MMC support for BBB is intentionally not added due to custom fixes and other patches that are in Koen's tree and which will be separately submitted by him. [1] http://marc.info/?l=linux-omap&m=137883926226451&w=2 [2] http://comments.gmane.org/gmane.linux.kernel.stable/63648 Matt Porter (3): ARM: dts: add AM33XX EDMA support ARM: dts: add AM33XX SPI DMA support ARM: dts: add AM33XX MMC support and documentation .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +- arch/arm/boot/dts/am335x-bone.dts | 11 arch/arm/boot/dts/am335x-evm.dts | 7 +++ arch/arm/boot/dts/am335x-evmsk.dts | 7 +++ arch/arm/boot/dts/am33xx.dtsi | 60 ++ 5 files changed, 110 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: add AM33XX EDMA support
Hi Joel,
On 31/08/2013 03:19, Joel Fernandes wrote:
Hi Benoit,
On 08/26/2013 03:36 AM, Benoit Cousson wrote:
- minus all the TI emails which are not working anymore :-(
I've just sent my previous email too soon...
Now the patch is different :-) I'll take that one.
Unfortunately this patch is still missing from your latest pull request:
Indeed, it was supposed to be applied on 3.13 only. It just came too
late for 3.12.
Regards,
Benoit
Subject "[GIT PULL] ARM: OMAP: Device Tree for 3.12 take #2"
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
tags/for_3.12/dts_signed (commit 4843be165c10f9886c87eeb20acf19a3ddec6653)
Below is a scissor patch that cleanly applies on above branch.
Thanks,
-Joel
--->8
From: Matt Porter
Subject: [PATCH] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
v2 changes:
Drop DT entries that are non-hardware-description Joel Fernandes
Discussion in [1].
v3 changes: Changed node name from "edma: edma@" to "edma: dma-controller@"
by Sebastian Andrzej Siewior
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
---
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5996d63..f5869ed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -101,6 +101,18 @@
reg = <0x4820 0x1000>;
};
+ edma: dma-controller@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
On 29/08/2013 16:23, Felipe Balbi wrote: On Thu, Aug 29, 2013 at 12:06:32PM +0200, Benoit Cousson wrote: Hi Felipe On 27/08/2013 21:56, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote: On 08/27/2013 04:05 PM, Benoit Cousson wrote: On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:57 PM, Benoit Cousson wrote: + Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? That is up to Greg. This changes sat in his usb-next tree for a while now. And before they hit Greg they were in Felipe's tree for a while. To be exact, last .dts change via USB was: Author: Sebastian Andrzej Siewior AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi CommitDate: Fri Aug 9 17:40:16 2013 +0300 usb: musb dma: add cppi41 dma driver Mmm, if that branch is supposed to be stable, I'm not sure it will be doable... Maybe we should do the other way around? And merge usb-next into arm-soc/dt. Kevin, Olof? Please be aware that I have no response so far regarding [0] from Greg. [0] http://www.spinics.net/lists/linux-usb/msg92595.html Nor will you, given that I am not the one to take these patches, Felipe is. I noticed now that you said "please route around Felipe", but sorry, no, I'm not going to do that unless there's a really good reason. Felipe seems to be around at the moment, please work with him on this. If you will still take a 'part2' pull request from me, I can send you urgent bugfixes by friday. If I have some time left, I can even try to get that sorted out by tomorrow. For 3.12 stuff, like "fixes", sure, I can take them this week, that should give us a week or so for linux-next testing, right? that's correct. I have most of them already queued up, let me just go over my linux-usb maildir again and make sure I got all the important stuff in. cheers, thanks for opening this 'window'. There are two patches in my DTS tree that conflict with the usb-next. I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and device nodes) , as suggested by Olof, since it is the biggest source of conflict from my tree. The second one is easily fixable, and Stephen already did it, but it will be even better it you could take it in your tree. This is the patch you did that I just slightly renamed (ARM: OMAP5: dts: fix reg property size). I'm done with Pull requests for Greg. If the conflict is easy to solve, what's the problem in having the conflict to start with ? Well, it is mainly the other one that is a pain to fix. Since I was about to send another pull-request, I was wondering if you'll be OK to take it. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
Hi Felipe On 27/08/2013 21:56, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 12:30:21PM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 01:37:32PM -0500, Felipe Balbi wrote: Hi, On Tue, Aug 27, 2013 at 10:37:32AM -0700, Greg KH wrote: On Tue, Aug 27, 2013 at 04:13:23PM +0200, Sebastian Andrzej Siewior wrote: On 08/27/2013 04:05 PM, Benoit Cousson wrote: On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:57 PM, Benoit Cousson wrote: + Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? That is up to Greg. This changes sat in his usb-next tree for a while now. And before they hit Greg they were in Felipe's tree for a while. To be exact, last .dts change via USB was: Author: Sebastian Andrzej Siewior AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi CommitDate: Fri Aug 9 17:40:16 2013 +0300 usb: musb dma: add cppi41 dma driver Mmm, if that branch is supposed to be stable, I'm not sure it will be doable... Maybe we should do the other way around? And merge usb-next into arm-soc/dt. Kevin, Olof? Please be aware that I have no response so far regarding [0] from Greg. [0] http://www.spinics.net/lists/linux-usb/msg92595.html Nor will you, given that I am not the one to take these patches, Felipe is. I noticed now that you said "please route around Felipe", but sorry, no, I'm not going to do that unless there's a really good reason. Felipe seems to be around at the moment, please work with him on this. If you will still take a 'part2' pull request from me, I can send you urgent bugfixes by friday. If I have some time left, I can even try to get that sorted out by tomorrow. For 3.12 stuff, like "fixes", sure, I can take them this week, that should give us a week or so for linux-next testing, right? that's correct. I have most of them already queued up, let me just go over my linux-usb maildir again and make sure I got all the important stuff in. cheers, thanks for opening this 'window'. There are two patches in my DTS tree that conflict with the usb-next. I will remove that one (ARM: dts: AM33XX: don't redefine OCP bus and device nodes) , as suggested by Olof, since it is the biggest source of conflict from my tree. The second one is easily fixable, and Stephen already did it, but it will be even better it you could take it in your tree. This is the patch you did that I just slightly renamed (ARM: OMAP5: dts: fix reg property size). Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
Hi Olof, On 27/08/2013 18:12, Olof Johansson wrote: On Tue, Aug 27, 2013 at 05:25:23PM +0200, Sebastian Andrzej Siewior wrote: On 08/27/2013 05:01 PM, Kevin Hilman wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? Unfortunately, the next/dt branch of arm-soc is not necessarily stable so should *not* be merged. In fact none of the arm-soc branches should be considered stable. As was already mentioned, this should be split up into driver changes and DTS changes through arm-soc. They'll both merge for v3.12. But splitting will break the driver until .dts & code is in sync again. BTW, how did this patch get merged without a signoff/ack from the OMAP DT maintainer in the first place? Hmm, looks like Benoit was not copied nor was linux-omap or linux-arm-kernel copied in the original mails. Hmm. I had Benoit's okay [0] to do the change "as long as Felipe is fine with it". I indeed forgot to Cc Benoit on the dts changes. For the phy-rename Felipe pinged you and we did the topic-branch, here I forgot. No. Read that email again. What Benoit said was that if Felipe was fine with the change _HE_ would take it. Huge difference, and one that would have avoided this situation. The only way to solve these things in the future is to make the driver handle both the new and the old binding. Bindings are not supposed to change in incompatible ways any more, unless for special circumstances and/or when the old binding was completely broken. The only way forward here, since Greg runs a stable tree that he doesn't rebase, is for us to rebuild without the OMAP DT branch, and ask Benoit to take out the conflicting changes. Benoit, I know this is none of your fault, but would you mind preparing a new copy of the DT branch without the conflicting patches, and hold those to 3.13? I haven't looked to see how many those were. OK, I'll do that ASAP and check how many should be removed to avoid a conflict with usb-next. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
On 27/08/2013 16:02, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:57 PM, Benoit Cousson wrote: + Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? That is up to Greg. This changes sat in his usb-next tree for a while now. And before they hit Greg they were in Felipe's tree for a while. To be exact, last .dts change via USB was: Author: Sebastian Andrzej Siewior AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi CommitDate: Fri Aug 9 17:40:16 2013 +0300 usb: musb dma: add cppi41 dma driver Mmm, if that branch is supposed to be stable, I'm not sure it will be doable... Maybe we should do the other way around? And merge usb-next into arm-soc/dt. Kevin, Olof? Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
+ Kevin, On 27/08/2013 15:53, Sebastian Andrzej Siewior wrote: On 08/27/2013 03:24 PM, Benoit Cousson wrote: Hi Sebatian, Hi Benoit, Yes. DT patches are an endless source of merge conflicts if they are merge throught different trees. Usually there are small conflicts because two people added / changed a node nearby. This patch turned the .dts file almost upside down. Yes, that's true. What was discussed with Olof and Arnd during Connect is that we should avoid merging DT patches outside arm-soc tree to avoid that kind of situation. I am aware of this now. However these changes belonged together because a) they belonged together and b) would break the driver until the .dts changes and driver code is in-sync. In future I am going to ask you for a topic branch so I can get my changes in one piece without breaking stuff in the middle. What do we do now? Cannot you just merge the stable arm-soc/dt branch into your branch before applying your patches? Regards Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the usb tree
Hi Sebatian,
On 27/08/2013 15:02, Javier Martinez Canillas wrote:
[cc'ing Benoit Cousson (OMAP DT maintainer)]
On Tue, Aug 27, 2013 at 10:54 AM, Sebastian Andrzej Siewior
wrote:
On 08/27/2013 10:13 AM, Stephen Rothwell wrote:
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/am335x-bone.dts between commit 97238b35d5bb
("usb: musb: dsps: use proper child nodes") from the tree and
commit 63f6b2550aa0 ("ARM: dts: AM33XX: don't redefine OCP bus and
device nodes") from the arm-soc tree.
I fixed it up (probably incorrectly - see below) and can carry the
fix as necessary (no action is required).
You added the OCP node back and the USB nodes as I had them which
should be fine.
How do we solve the conflict for the merge window? Is it possible for
the ARM-SOC tree to create a topic branch for this commit?
Greg: I do have a pending pull / patches [0] which also change the dts
nodes according to the latest feedback + enabling an additional USB
port in bone.
If you take this in I could update the nodes later (with the topic
branch merged) accordingly to the way it has been done in the ARM-SOC
tree - unless you have other preferences.
I think that the proper way to handle this is to split the patch-set
in two and merge all the OMAP DT related changes
(arch/arm/boot/dts/am*) through Benoit's tree and the USB changes
(drivers/usb/*) through Greg tree to prevent these kind of merge
conflicts.
Yes. DT patches are an endless source of merge conflicts if they are
merge throught different trees.
What was discussed with Olof and Arnd during Connect is that we should
avoid merging DT patches outside arm-soc tree to avoid that kind of
situation.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: add AM33XX EDMA support
- minus all the TI emails which are not working anymore :-(
I've just sent my previous email too soon...
Now the patch is different :-) I'll take that one.
Thanks,
Benoit
On 26/08/2013 10:29, Sebastian Andrzej Siewior wrote:
From: Matt Porter
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Joel: Drop DT entries that are non-hardware-description for now as discussed in
[1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
Signed-off-by: Sebastian Andrzej Siewior
---
Could someone please pick this up?
v1..v2:
- s/edma@/dma-controller@/
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
reg = <0x4820 0x1000>;
};
+ edma: dma-controller@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: add AM33XX EDMA support
Hi Sebastian,
Is this patch different from that one:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92176.html
Lokesh just pointed me this patch because it was missing for the
SHAM/AES series from Mark Greer.
Bottom-line, I've just applied the original one along with a second one
that was adding EDMA in SPI.
Regards,
Benoit
On 23/08/2013 21:06, Sebastian Andrzej Siewior wrote:
From: Matt Porter
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Joel: Drop DT entries that are non-hardware-description for now as discussed in
[1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
Signed-off-by: Sebastian Andrzej Siewior
---
Could someone please pick this up?
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..784f774 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -96,6 +96,18 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions
Hi Sekhar, On 23/08/2013 10:50, Sekhar Nori wrote: Hi Benoit, Did you get a chance to think about this, I have provided some replies below. On Friday 16 August 2013 10:03 PM, Benoit Cousson wrote: Hi Sekhar, On 16/08/2013 17:41, Sekhar Nori wrote: On 8/16/2013 7:45 PM, Benoit Cousson wrote: Hi Gururaja, On 16/08/2013 13:36, Hebbar, Gururaja wrote: The syntax of compatible property in DT is to mention the Most specific match to most generic match. Since AM335x is the platform with latest IP revision, add it 1st in the device id table. I don't understand why? The order should not matter at all. Yes, it should not. We are trying to work around a bug in the kernel where the compatible order is not honored (instead the order in of_match[] array matters). There were patches being discussed to fix this. I've tried to follow the thread you had with Mark on the v2, but AFAIK, you've never answered to his latest question. Moreover, checking the differences between the Davinci and the am3352 RTC IP, I would not claim that both are compatible. Sure you can use the am3352 with the Davinci driver, but you will lose the wakeup functionality without even being notify about that. When the kernel is fixed for the bug pointed out above, this should not happen with properly defined compatible property. For my point of view, compatible mean that the HW will still be fully functional with both versions of the driver, which is not the case here. I do not think that's the interpretation of compatible. Its goes from most specific to most generic per the ePAPR spec. That in itself says that 100% functionality is not expected if you don't find a match for the more specific property. Well, to be honest I checked as well the official documentation, and this is far from being clear: page 21 of the ePAPR: " Property: compatible Value type: Description: The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The recommended format is “manufacturer,model”, where manufacturer is a string describing the name of the manufacturer (such as a stock ticker symbol), and model specifies the model number. Example: compatible = “fsl,mpc8641-uart”, “ns16550"; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. " In this example, the generic vs specific is just about the driver. You could have one driver that manage 10 different UARTs or a specific one that manage only your HW. Right, the assumption is that a specific driver is written because there are parts of the hardware that cannot be serviced by generic driver. So ultimately its all driven by changes in hardware. Yeah, that example remind me the omap-serial driver we had done to handle the DMA mode that was not supported by the generic one. There is no assumption about the lost of functionality by using the generic version of the driver. How the user is supposed to know the amount of functionality he will lose, and if this is acceptable to him. I suppose the generic driver would return some error code like -ENOTSUP for the functionality it cannot provide. Well, I guess it depends of the added functionality add how far the IP version is forward compatible with the old driver. If the new IP version is just improving the performance by adding a DMA mode instead of the PIO, then the driver API can remain the same. But if you add a new functionality that will require an extended API, there is no way you can report such error. Except if the API itself is done with a good forward compatibility support. And if the new functionality is mandatory to make the new system operational, returning an error might just make the system not working at all. I'd rather have an error at boot saying that the driver is not compatible with the HW and thus I will have to upgrade the kernel, than booting a kernel that will not work as expected because some functionality are missing for that specific HW. If you have an update available, you can always upgrade to it. But what if there is no update available? Would you rather not have the user use the available functionality in the meanwhile while he waits for the kernel support to be developed. It depends... In the UART example, that's just a matter of performance improvement, so keeping the old version is fine. As soon as the driver is usable, and the new featur
Re: [PATCH v3 0/5] ARM: OMAP: DTS/HWMOD/defconfig changes for USB3
Hi Kishon, On 21/08/2013 16:31, Kishon Vijay Abraham I wrote: From: Felipe Balbi With these patches (plus a few others on the driver side which will be going upstream soon) I could get functional USB3 with my omap5-uevm platform. Changes since v2: - added dt properties for enabling vbus/id interrupts and fixed vbus-supply value after SMPS10 is modeled as 2 regulators Excellent, thanks for that super quick update. I've just applied it and will try to push it ASAP. I've just slightly changed the subjects to have both ARM and OMAP in capital letters for consistency. Tony, I will update my pull-request now before Kevin and Olof pulled it. Regards, Benoit Changes since v1: - split ocp2scp dts and hwmod data into separate patches - reorganize the series in order to group DTS, hwmod and defconfig changes Benoit Cousson (1): arm: omap5: hwmod: add missing ocp2scp hwmod data Felipe Balbi (4): arm: omap5: dts: fix reg property size arm: omap5: dts: fix ocp2scp DTS data arm: omap5: dts: add palmas-usb node arm: omap2plus_defconfig: enable dwc3 and dependencies arch/arm/boot/dts/omap5-uevm.dts | 12 arch/arm/boot/dts/omap5.dtsi |9 +++--- arch/arm/configs/omap2plus_defconfig |9 ++ arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 4 files changed, 71 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: am33xx: Correct gpio #interrupt-cells property
Hi Tony, On 21/08/2013 09:59, Tony Lindgren wrote: * Lars Poeschel [130821 01:04]: Hi Tony! On Wednesday 21 August 2013 at 09:50:16, Tony Lindgren wrote: Benoit, Care to take a look at this too? Benoit already applied this with Mark Rutlands Acked-By and Javier Martinez Canillas Reviewed-by. OK thanks for the update, I'm just trying to follow-up and clear my inbox a bit. I've just checked, because I thought I missed it, and this is indeed in my pull request I sent you yesterday. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] extcon: palmas: Modified the compatible type to *ti,palmas-usb-vid*
Hi Kishon,
On 19/08/2013 11:29, Kishon Vijay Abraham I wrote:
On Monday 19 August 2013 02:54 PM, Chanwoo Choi wrote:
On 08/19/2013 05:47 PM, Kishon Vijay Abraham I wrote:
On Monday 19 August 2013 10:35 AM, Kishon Vijay Abraham I wrote:
Hi,
On Saturday 17 August 2013 03:51 AM, Stephen Warren wrote:
On 08/16/2013 04:20 AM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VID detector, so modified the
compatible type to *ti,palmas-usb-vid*.
diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
That file is not yet in 3.11. Only the twl is there.
Is this one a rename of the twl one?
Regards,
Benoit
PALMAS USB COMPARATOR
Required Properties:
- - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb"
+ - compatible : Should be "ti,palmas-usb-vid".
Has the old value been published in a release kernel? If so, it makes
No. This was merged only in 3.11-rc1. So I think we should take this version?
Chanwoo can you take this patch?
Ah.. the old values will be part of 3.11 kernel. So should we retain the old
values?
What is the meaning of old value? previous value related to extcon-twl.txt?
We were discussing on whether to have "ti,palmas-usb" or "ti,twl6035-usb" in
compatible value in addition to "ti,palmas-usb-vid". Stephen wanted the old
values ("ti,palmas-usb" or "ti,twl6035-usb") if it has been published in a
release kernel.
The extcon-twl.txt was included in 3.11 kernel
Right. Since it's part of 3.11 kernel, I think we should retain the old
compatible values.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] omap4/twl6030: typical connection to omap4 as a separate dtsi file
Hi Ruslan, On 19/08/2013 08:14, Ruslan Bilovol wrote: Hi Benoit, On Fri, Aug 16, 2013 at 4:20 PM, Benoit Cousson wrote: Hi Ruslan, On 16/08/2013 14:04, Ruslan Bilovol wrote: Hi Benoit, On Wed, Aug 14, 2013 at 4:51 PM, Benoit Cousson wrote: Hi Ruslan, On 14/08/2013 10:35, Ruslan Bilovol wrote: Hello, There is no functional changes between v1 and v2 - just added the patch for omap4-var-som - Uri Yosef confirmed this board have the same connection of OMAP4<->TWL6030 as SDP4430 board The series looks good to me, but it will be good to have a test for Panda and Variscite boards before merging it. Okay, so I just verified this patch series on PandaBoard ES2. Should I resubmit this series with fixed commit message? No, that's fine, I already applied it and fixed the subject and the changelog. Here it is: commit 2e25df1e5a4af906a9b25332719ace63eb0d Author: Ruslan Bilovol Date: Wed Aug 14 11:35:47 2013 +0300 ARM: dts: twl6030: Move common configuration for OMAP4 boards in a separate dtsi file The OMAP4 SoC family uses specially-designed PMIC (power management IC) companion chip for power management needs: TWL6030/TWL6032. Therefore there is a typical connection of PMIC to OMAP4 so we can move it into separate .dtsi file and do not duplicate over board-specific files. Tested on OMAP4 SDP board and compile-tested for Panda board Just for archives: I've successfully tested it on PandaBoard ES2 last week as well. Great, I'll update the changelog before pushing it. Signed-off-by: Ruslan Bilovol Signed-off-by: Benoit Cousson Just let me know if you are OK with the updated version. Yes, this version looks good to me. Thanks for picking it up! However I cannot verify the patch for Variscite board because I do not own any such board so you can drop that patch. But maybe Uri Yosef can verify it. Uri? It seems that Uri cannot test it right now, so I will have to drop that one. Okay, let's wait for Uri's verification. I'll keep it for 3.13. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions
Hi Mark, On 16/08/2013 19:20, Mark Rutland wrote: Hi Benoit, On Fri, Aug 16, 2013 at 03:15:57PM +0100, Benoit Cousson wrote: Hi Gururaja, On 16/08/2013 13:36, Hebbar, Gururaja wrote: The syntax of compatible property in DT is to mention the Most specific match to most generic match. Since AM335x is the platform with latest IP revision, add it 1st in the device id table. I don't understand why? The order should not matter at all. I've tried to follow the thread you had with Mark on the v2, but AFAIK, you've never answered to his latest question. Moreover, checking the differences between the Davinci and the am3352 RTC IP, I would not claim that both are compatible. Sure you can use the am3352 with the Davinci driver, but you will lose the wakeup functionality without even being notify about that. Could you describe the wakeup functionality, and how it differs between the am3352-rtc and the da830-rtc? AFAIK, da830-rtc does not have that functionality at all. This is something that was added to the am3352-rtc. As I understand it, the am3352 functionality is a superset of the da830 functionality. You can use the old driver, and get some functionality, or use the new driver and get it all. Mmm, what your are saying now seems to make sense to me as well. So I'm even more confused :-) That means that am3352-rtc is compatible with da830. As long as the kernel first checks for am3352-rtc, there will be *no* loss of functionality. All this does is enable older kernels to use the hardware in some fashion, and given the older kernel didn't have support for the am3352-rtc features, this is a *gain* in functionality, not a loss. For my point of view, compatible mean that the HW will still be fully functional with both versions of the driver, which is not the case here. What? A driver for any entry in the compatible list should be able to drive the hardware to *some* level of functionality. We list from most-specific to most-general to allow a graceful degradation from fully supported to bare minimum functionality. OK, but where is it written in the DT spec that this is what the compatible is supposed to mean? I'm quoting it again: " The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. " The graceful degradation or the loss of functionality is not something that I really understand in that text. Anyway, I'm probably too tired... I'll go back home, and think about that after the week-end. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions
Hi Sekhar, On 16/08/2013 17:41, Sekhar Nori wrote: > > On 8/16/2013 7:45 PM, Benoit Cousson wrote: >> Hi Gururaja, >> >> On 16/08/2013 13:36, Hebbar, Gururaja wrote: >>> The syntax of compatible property in DT is to mention the Most specific >>> match to most generic match. >>> >>> Since AM335x is the platform with latest IP revision, add it 1st in >>> the device id table. >> >> I don't understand why? The order should not matter at all. > > Yes, it should not. We are trying to work around a bug in the kernel > where the compatible order is not honored (instead the order in > of_match[] array matters). There were patches being discussed to fix this. > >> >> I've tried to follow the thread you had with Mark on the v2, but AFAIK, >> you've never answered to his latest question. >> >> Moreover, checking the differences between the Davinci and the am3352 >> RTC IP, I would not claim that both are compatible. >> >> Sure you can use the am3352 with the Davinci driver, but you will lose >> the wakeup functionality without even being notify about that. > > When the kernel is fixed for the bug pointed out above, this should not > happen with properly defined compatible property. > >> >> For my point of view, compatible mean that the HW will still be fully >> functional with both versions of the driver, which is not the case here. > > I do not think that's the interpretation of compatible. Its goes from > most specific to most generic per the ePAPR spec. That in itself says > that 100% functionality is not expected if you don't find a match for > the more specific property. Well, to be honest I checked as well the official documentation, and this is far from being clear: page 21 of the ePAPR: " Property: compatible Value type: Description: The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The recommended format is “manufacturer,model”, where manufacturer is a string describing the name of the manufacturer (such as a stock ticker symbol), and model specifies the model number. Example: compatible = “fsl,mpc8641-uart”, “ns16550"; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. " In this example, the generic vs specific is just about the driver. You could have one driver that manage 10 different UARTs or a specific one that manage only your HW. There is no assumption about the lost of functionality by using the generic version of the driver. How the user is supposed to know the amount of functionality he will lose, and if this is acceptable to him. I'd rather have an error at boot saying that the driver is not compatible with the HW and thus I will have to upgrade the kernel, than booting a kernel that will not work as expected because some functionality are missing for that specific HW. Claiming that a piece of HW is compatible with an other one that is just a subset in term of functionality is wrong. You can claim that the ti,da830-rtc is compatible with the ti,am3352-rtc driver, but not the opposite. >> am3352 DTS must use the ti,am3352-rtc to have the expected behavior. > > Yes, that's what patch 2/2 does. > >> Using the ti,da830-rtc version will not make the board working as >> expected. So we cannot claim the compatibility. > > Ideally, the DT file was *always* written as > > compatible = "ti,am3352-rtc", "ti,da830-rtc"; > > even when there was no kernel support for AM3352 RTC. You could do that only for the davinci DTS, because it is a subset of the am3352 but you cannot do that for the am3352 as explained before. > That way, there is no need to update the .dts[i] file. As kernel gains > functionality, more features (like rtc wake) is available to users. Well, you cannot anticipate the HW evolution anyway and you did not know when Davinci DTS was done that an am3352 will exist in the future and reuse the same IP. Moreover DT is a ABI, so extending it according to the HW feature evolution is absolutely normal. Every SoC that are using a RTC with the same programing model than the da830 can claim the compatibility. A SoC that is u
Re: [PATCH v3 1/2] rtc: omap: update of_device_id to reflect latest ip revisions
Hi Gururaja,
On 16/08/2013 13:36, Hebbar, Gururaja wrote:
The syntax of compatible property in DT is to mention the Most specific
match to most generic match.
Since AM335x is the platform with latest IP revision, add it 1st in
the device id table.
I don't understand why? The order should not matter at all.
I've tried to follow the thread you had with Mark on the v2, but AFAIK,
you've never answered to his latest question.
Moreover, checking the differences between the Davinci and the am3352
RTC IP, I would not claim that both are compatible.
Sure you can use the am3352 with the Davinci driver, but you will lose
the wakeup functionality without even being notify about that.
For my point of view, compatible mean that the HW will still be fully
functional with both versions of the driver, which is not the case here.
am3352 DTS must use the ti,am3352-rtc to have the expected behavior.
Using the ti,da830-rtc version will not make the board working as
expected. So we cannot claim the compatibility.
This way, we can add new matching compatible as 1st and maintain old
compatible string for backwards compatibility.
ex:
compatible = "ti,am3352-rtc", "ti,da830-rtc";
Signed-off-by: Hebbar, Gururaja
CC: mark.rutl...@arm.com
---
Changes in v3:
- new patch
:100644 100644 dc62cc3... 2f0968c... M drivers/rtc/rtc-omap.c
drivers/rtc/rtc-omap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index dc62cc3..2f0968c 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -330,12 +330,12 @@ static struct platform_device_id omap_rtc_devtype[] = {
MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
static const struct of_device_id omap_rtc_of_match[] = {
- { .compatible = "ti,da830-rtc",
- .data = &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
- },
{ .compatible = "ti,am3352-rtc",
.data = &omap_rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
},
+ { .compatible = "ti,da830-rtc",
+ .data = &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
Bottom-line, if you get rid of the old compatible entry, you will not
have to play some trick with the entries order.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] omap4/twl6030: typical connection to omap4 as a separate dtsi file
Hi Ruslan,
On 16/08/2013 14:04, Ruslan Bilovol wrote:
> Hi Benoit,
>
> On Wed, Aug 14, 2013 at 4:51 PM, Benoit Cousson wrote:
>> Hi Ruslan,
>>
>> On 14/08/2013 10:35, Ruslan Bilovol wrote:
>>>
>>> Hello,
>>>
>>> There is no functional changes between v1 and v2 - just
>>> added the patch for omap4-var-som - Uri Yosef confirmed
>>> this board have the same connection of OMAP4<->TWL6030 as
>>> SDP4430 board
>>
>>
>> The series looks good to me, but it will be good to have a test for Panda
>> and Variscite boards before merging it.
>
> Okay, so I just verified this patch series on PandaBoard ES2. Should I
> resubmit this series with
> fixed commit message?
No, that's fine, I already applied it and fixed the subject and the changelog.
Here it is:
commit 2e25df1e5a4af906a9b25332719ace63eb0d
Author: Ruslan Bilovol
Date: Wed Aug 14 11:35:47 2013 +0300
ARM: dts: twl6030: Move common configuration for OMAP4 boards in a separate
dtsi file
The OMAP4 SoC family uses specially-designed PMIC (power management IC)
companion chip for power management needs: TWL6030/TWL6032.
Therefore there is a typical connection of PMIC to OMAP4 so we can
move it into separate .dtsi file and do not duplicate over
board-specific files.
Tested on OMAP4 SDP board and compile-tested for Panda board
Signed-off-by: Ruslan Bilovol
Signed-off-by: Benoit Cousson
Just let me know if you are OK with the updated version.
> However I cannot verify the patch for Variscite board because I do not
> own any such board so
> you can drop that patch. But maybe Uri Yosef can verify it. Uri?
It seems that Uri cannot test it right now, so I will have to drop that one.
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] omap4/twl6030: typical connection to omap4 as a separate dtsi file
Hi Uri, On 16/08/2013 14:30, Uri Yosef wrote: Hi, I am on vacation until Aug 25th, I will test it when I back. OK, but it will be too late for this merge window. I'll drop it for 3.12 then. Thanks, Benoit Regards, Uri Yosef On Fri, Aug 16, 2013 at 3:04 PM, Ruslan Bilovol mailto:ruslan.bilo...@ti.com>> wrote: Hi Benoit, On Wed, Aug 14, 2013 at 4:51 PM, Benoit Cousson mailto:bcous...@baylibre.com>> wrote: > Hi Ruslan, > > On 14/08/2013 10:35, Ruslan Bilovol wrote: >> >> Hello, >> >> There is no functional changes between v1 and v2 - just >> added the patch for omap4-var-som - Uri Yosef confirmed >> this board have the same connection of OMAP4<->TWL6030 as >> SDP4430 board > > > The series looks good to me, but it will be good to have a test for Panda > and Variscite boards before merging it. Okay, so I just verified this patch series on PandaBoard ES2. Should I resubmit this series with fixed commit message? However I cannot verify the patch for Variscite board because I do not own any such board so you can drop that patch. But maybe Uri Yosef can verify it. Uri? > > Regards, > Benoit -- Best regards, Ruslan Bilvol -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM:dts: Add devicetree for gta04 board.
Hi Marek, On 15/08/2013 22:43, Marek Belisko wrote: This adds devicetree for gta04 (Openmoko next generation board) with necessary support for mmc, usb, leds and button. Signed-off-by: Marek Belisko --- This is resurrection of patch sent in March https://lkml.org/lkml/2013/1/24/419 when I got no reply from maintainer. Patch is updated and based on linux-next (20130807) Thanks for the update. I added a missing space in the subject and fixed an indentation issue for the uart2 node. Applied in my for_3.12/dts branch. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arm: dts: AM43x: Add usb DT nodes for AM4372
On 16/08/2013 05:19, George Cherian wrote:
Hi Benoit ,
Thanks for your review.
On 8/14/2013 8:04 PM, Benoit Cousson wrote:
+ Roger
Hi George,
Yes, I had some comment about the "ti'type" in Roger's series that
will be applicable here as well.
On 14/08/2013 16:16, George Cherian wrote:
+Benoit
If you dont have any comments, can you take this for 3.12?
Regards
-George
On 7/10/2013 1:44 PM, George Cherian wrote:
This patch adds
- HS USB nodes
- phy nodes
- usb control module nodes.
Signed-off-by: George Cherian
---
changes from v2
change synopsis to snps
use simple node names
add both USB and PHY instances
add usbctrl node
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
arch/arm/boot/dts/am4372.dtsi | 58
+++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..37f196f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,63 @@
compatible = "ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+phy1: usbphy1 {
+compatible = "ti,am4372-usb2";
That's not a very good name for a phy? It looks like a usb module.
The bindings specify only ti,omap-usb2 or ti,omap-usb3 for USB2 or USB3.
I guess it should be one of them and potentially the binding should be
updated with ti,omap-usb2-phy and ti,omap-usb3-phy names while we can
still do it.
+#phy-cells = <0>;
+id = <0>;
+status = "disabled";
+};
+
+phy2: usbphy2 {
Why do you need a different node name here? It should be a generic
name to identify the function, so usbphy or usb-phy seems good enough.
There are 2 instances of usb controllers and these instances for those 2
phys, which essentially dont have any reg property. So I named it as
usbphy1 and usbphy2.
+compatible = "ti,am4372-usb2";
+#phy-cells = <0>;
+id = <1>;
+status = "disabled";
+};
+
+usbctrl: omap-control-usb@44e10620 {
+compatible = "ti,omap-control-usb";
+reg = <0x44e10620 0x10>;
+reg-names = "control_dev_conf";
+ti,type = <3>;
+status = "disabled";
+};
+
+usb1: am4372_dwc3@4838 {
+status = "disabled";
+compatible = "ti,am4372-dwc3";
+reg = <0x4838 0x200>;
+interrupts = ;
+#address-cells = <1>;
+#size-cells = <1>;
+utmi-mode = <1>;
+ranges;
A blank line here will be nice.
okay
+dwc3@4839 {
+compatible = "snps,dwc3";
+reg = <0x4839 0xd000>;
+interrupts = ;
+phys = <&phy1>;
+phy-names = "am4372-usb1";
What is the purpose of the phy-names? Is it relevant to add the SoC
name in something that usually, at least for the clocks and IRQs, is
IP specific?
The current documentation does not explain it and does not support
phys property either.
synopsys DWC3 CORE
DWC3- USB3 CONTROLLER
Required properties:
- compatible: must be "synopsys,dwc3"
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
- usb-phy : array of phandle for the PHY device
Is there some binding update ongoing for 3.12?
The phy part, especially was added with the generic phy framework in
mind. The generic phy framework uses phys and phy-names instead of usb-phy.
Also all synopsys references for compatible are being replaced with snps.
That's fine, but that was not my question. Is there any already bindings
that defined phys and phy-names in the kernel?
I couldn't find them in 3.11-rc5.
And anyway the current bindings for dwc3 is not aligned with what you
are doing here.
So you have to change the binding before using it in this DTS.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: omap5: dts: split SMPS10 dt node
On 16/08/2013 07:15, Kishon Vijay Abraham I wrote: Hi Benoit, On Tuesday 13 August 2013 08:18 PM, Benoit Cousson wrote: On 13/08/2013 16:45, Kishon Vijay Abraham I wrote: Hi, On Tuesday 13 August 2013 06:51 PM, Benoit Cousson wrote: Hi Kishon, On 12/08/2013 11:37, Kishon Vijay Abraham I wrote: SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as two regulators. The dt node is split to reflect it. Mmm, I'm curious. How is it supposed to work? Do you have dedicated control on each output? Yes. It can be controlled by setting different values to the same bit fields. You can refer [1] where we actually implement SMPS10 as two different regulators. [1] -> http://permalink.gmane.org/gmane.linux.kernel/1542521 Great, thanks. Can we merge that one safely if the driver changed are not done yet? I think it shouldn't cause any issues. However Mark has already merged the driver changes. Cool. I've just applied your patch in for_3.12/dts Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] extcon: palmas: Added a new compatible type *ti, palmas-usb-vid*
Hi Kishon, On 14/08/2013 07:24, Kishon Vijay Abraham I wrote: Hi, On Wednesday 14 August 2013 12:43 AM, Stephen Warren wrote: On 08/12/2013 11:37 PM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so added a compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible s/Dint/Didn't/ diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-twl.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb" + - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb" or + "ti,palmas-usb-vid". So are ti,palmas-usb and ti,twl6035-usb full EHCI controllers then? No. I thought I shouldn't remove those if someone is already using those compatible value. Well, I think we still have a short period of time where we can clean some badly defined bindings before it is really too late. Both kernel and DTS are still in sync for the moment, so changing both at the same time should be safe. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] Documentation: dt: bindings: TI WiLink modules
Hi Luca,
On 30/07/2013 22:21, Luciano Coelho wrote:
Add device tree bindings documentation for the TI WiLink modules.
Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
modules is supported.
Signed-off-by: Luciano Coelho
---
In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.
.../devicetree/bindings/net/wireless/ti-wilink.txt | 68 ++
1 file changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
new file mode 100644
index 000..aafebb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
@@ -0,0 +1,68 @@
+TI WiLink Wireless Modules Device Tree Bindings
+===
+
+The WiLink modules provide wireless connectivity, such as WLAN,
+Bluetooth, FM and NFC.
+
+There are several different modules available, which can be grouped by
+their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not
+currently supported with device tree.
+
+Currently, only the WLAN portion of the modules is supported with
+device tree.
+
+Required properties:
+
+
+- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8"
+- interrupt-parent: the interrupt controller
+- interrupts: out-of-band WLAN interrupt
+ See the interrupt controller's bindings documentation for
+ detailed definition.
+
+Optional properties:
+
+
+- clocks: list of clocks needed by the chip as follows:
+
+ refclock: the internal WLAN reference clock frequency (required for
+ WiLink6 and WiLink7; not used for WiLink8).
+
+ tcxoclock: the internal WLAN TCXO clock frequency (required for
+ WiLink7 not used for WiLink6 and WiLink8).
+
+ The clocks must be defined and named accordingly. For example:
+
+ clocks = <&refclock>
+ clock-names = "refclock";
+
+ refclock: refclock {
+compatible = "ti,wilink-clock";
+#clock-cells = <0>;
+clock-frequency = <3840>;
+ };
+
+ Some modules that contain the WiLink chip provide clocks in the
+ module itself. In this case, we define a "ti,wilink-clock" as shown
+ above. But any other clock could in theory be used, so the proper
+ clock definition should be used.
+
+
+Example:
+
+
+Example definition that can be used in OMAP4 Panda:
+
+wlan {
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>;/* gpio line 53 */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3840>;
+ };
+};
Everything looks good beside the location of the wlan node...
It should not float at the root of the device tree. It is physically
attached to a SDIO bus and thus must be a child of the MMC controller
for a proper HW representation. That's moreover the best way to handle
properly the dependency between the MMC controller and the wilink driver.
Please note that this is easier do say than to do :-)
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arm: dts: AM43x: Add usb DT nodes for AM4372
+ Roger
Hi George,
Yes, I had some comment about the "ti'type" in Roger's series that will
be applicable here as well.
On 14/08/2013 16:16, George Cherian wrote:
+Benoit
If you dont have any comments, can you take this for 3.12?
Regards
-George
On 7/10/2013 1:44 PM, George Cherian wrote:
This patch adds
- HS USB nodes
- phy nodes
- usb control module nodes.
Signed-off-by: George Cherian
---
changes from v2
change synopsis to snps
use simple node names
add both USB and PHY instances
add usbctrl node
changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize
arch/arm/boot/dts/am4372.dtsi | 58
+++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..37f196f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,63 @@
compatible = "ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+phy1: usbphy1 {
+compatible = "ti,am4372-usb2";
That's not a very good name for a phy? It looks like a usb module.
The bindings specify only ti,omap-usb2 or ti,omap-usb3 for USB2 or USB3.
I guess it should be one of them and potentially the binding should be
updated with ti,omap-usb2-phy and ti,omap-usb3-phy names while we can
still do it.
+#phy-cells = <0>;
+id = <0>;
+status = "disabled";
+};
+
+phy2: usbphy2 {
Why do you need a different node name here? It should be a generic name
to identify the function, so usbphy or usb-phy seems good enough.
+compatible = "ti,am4372-usb2";
+#phy-cells = <0>;
+id = <1>;
+status = "disabled";
+};
+
+usbctrl: omap-control-usb@44e10620 {
+compatible = "ti,omap-control-usb";
+reg = <0x44e10620 0x10>;
+reg-names = "control_dev_conf";
+ti,type = <3>;
+status = "disabled";
+};
+
+usb1: am4372_dwc3@4838 {
+status = "disabled";
+compatible = "ti,am4372-dwc3";
+reg = <0x4838 0x200>;
+interrupts = ;
+#address-cells = <1>;
+#size-cells = <1>;
+utmi-mode = <1>;
+ranges;
A blank line here will be nice.
+dwc3@4839 {
+compatible = "snps,dwc3";
+reg = <0x4839 0xd000>;
+interrupts = ;
+phys = <&phy1>;
+phy-names = "am4372-usb1";
What is the purpose of the phy-names? Is it relevant to add the SoC name
in something that usually, at least for the clocks and IRQs, is IP specific?
The current documentation does not explain it and does not support phys
property either.
synopsys DWC3 CORE
DWC3- USB3 CONTROLLER
Required properties:
- compatible: must be "synopsys,dwc3"
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
- usb-phy : array of phandle for the PHY device
Is there some binding update ongoing for 3.12?
+};
+};
+
+usb2: am4372_dwc3@483c {
+status = "disabled";
+compatible = "ti,am4372-dwc3";
+reg = <0x483c 0x200>;
+interrupts = ;
+#address-cells = <1>;
+#size-cells = <1>;
+utmi-mode = <1>;
+ranges;
A blank line here will be nice.
+dwc3@483d {
+compatible = "snps,dwc3";
+reg = <0x483d 0xd000>;
+interrupts = ;
+phys = <&phy2>;
+phy-names = "am4372-usb2";
+};
+};
};
};
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] omap4/twl6030: typical connection to omap4 as a separate dtsi file
Hi Ruslan, On 14/08/2013 10:35, Ruslan Bilovol wrote: Hello, There is no functional changes between v1 and v2 - just added the patch for omap4-var-som - Uri Yosef confirmed this board have the same connection of OMAP4<->TWL6030 as SDP4430 board The series looks good to me, but it will be good to have a test for Panda and Variscite boards before merging it. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] ARM: dts: omap4: update omap-control-usb nodes
Hi Roger,
On 01/08/2013 16:05, Roger Quadros wrote:
> Split otghs_ctrl and USB2 PHY power down into separate
> omap-control-usb nodes. Update ti,mode property.
Nit: I guess you mean ti,type?
> CC: Benoit Cousson
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap4.dtsi | 17 -
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 22d9f2b..9a6fa27 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -519,7 +519,7 @@
> usb2_phy: usb2phy@4a0ad080 {
> compatible = "ti,omap-usb2";
> reg = <0x4a0ad080 0x58>;
> - ctrl-module = <&omap_control_usb>;
> + ctrl-module = <&omap_control_usb2phy>;
> };
> };
>
> @@ -643,11 +643,17 @@
> };
> };
>
> - omap_control_usb: omap-control-usb@4a002300 {
> + omap_control_usb2phy: omap-control-usb@4a002300 {
> compatible = "ti,omap-control-usb";
> - reg = <0x4a002300 0x4>,
> - <0x4a00233c 0x4>;
> - reg-names = "control_dev_conf", "otghs_control";
> + reg = <0x4a002300 0x4>;
> + reg-names = "power";
> + ti,type = <2>;
Now that we can use the C preprocessor, it will be nice to use a macro instead
of the value.
TYPE1 - if it has otghs_control mailbox register (e.g. on OMAP4)
TYPE2 - if it has Power down bit in control_dev_conf register. e.g. USB2 PHY
TYPE3 - if it has DPLL and individual Rx & Tx power control. e.g. USB3 PHY or
SATA PHY
TYPE4 - if it has both power down and power aux registers. e.g. USB2 PHY on DRA7
Well, assuming you can find macro names that can explain a little bit what the
type is about :-)
That being said...
Do you really need to expose the type here? Maybe with just a set of different
compatible string you can figure out in the driver what type we are talking
about.
It is always better to minimize the amount of information we put in DT as soon
as we can infer it from the compatible string.
So instead of using a generic "ti,omap-control-usb" string + "ti,type" you can
potentially use several specific strings: ti,omap4-control-usb,
ti,dra7-control-usb...
Since the DT gurus are recommending to use specific compatible string as much
as possible, this is maybe a better approach.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/22] ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
Hi Lee,
Thanks for that cleanup.
On 14/08/2013 09:30, Tony Lindgren wrote:
* Lee Jones [130813 08:51]:
Tony, Benoit,
Poke
Looks like Benoit's new email address is bcous...@baylibre.com.
Probably best for Benoit to pick these to avoid merge conflicts.
I've just applied the 7 following patches. Let me know if I missed
something.
6b9fa1b ARM: dts: Remove '0x's from OMAP5 DTS file
79390b8 ARM: dts: Remove '0x's from OMAP4 DTS file
dd60fef ARM: dts: Remove '0x's from OMAP3430 SDP DTS file
bfef1cb ARM: dts: Remove '0x's from OMAP3 DTS file
5f547ac ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file
27939fc ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file
62eb4d1 ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
Regards,
Benoit
Regards,
Tony
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: Benoît Cousson
Cc: Tony Lindgren
Cc: linux-o...@vger.kernel.org
Signed-off-by: Lee Jones
---
arch/arm/boot/dts/omap2420-h4.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 224c08f..34cdecb 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -50,15 +50,15 @@
label = "bootloader";
reg = <0 0x2>;
};
- partition@0x2 {
+ partition@2 {
label = "params";
reg = <0x2 0x2>;
};
- partition@0x4 {
+ partition@4 {
label = "kernel";
reg = <0x4 0x20>;
};
- partition@0x24 {
+ partition@24 {
label = "file-system";
reg = <0x24 0x3dc>;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: omap5: dts: split SMPS10 dt node
On 13/08/2013 16:45, Kishon Vijay Abraham I wrote: Hi, On Tuesday 13 August 2013 06:51 PM, Benoit Cousson wrote: Hi Kishon, On 12/08/2013 11:37, Kishon Vijay Abraham I wrote: SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as two regulators. The dt node is split to reflect it. Mmm, I'm curious. How is it supposed to work? Do you have dedicated control on each output? Yes. It can be controlled by setting different values to the same bit fields. You can refer [1] where we actually implement SMPS10 as two different regulators. [1] -> http://permalink.gmane.org/gmane.linux.kernel/1542521 Great, thanks. Can we merge that one safely if the driver changed are not done yet? Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] N900: add device tree
On 13/08/2013 15:36, Pavel Machek wrote:
Hi!
I finally got released by the aliens. It took longer than expected
and beside a small scar on the back of my neck, I feel pretty OK.
Scars on neck sound scary...
The order should not matter at all in DT, it should be a static
representation of the HW, so there is probably something wrong in
the code that make the device creation order important.
I understand that there's something wrong with the code, but it turned
out not to be easy to debug. Yes, it will have to be debugged some
day, but it happens with old code, too, so it is actually orthogonal
to device tree.
Beside my comments and the ones from Javier, it looks good.
If you can repost ASAP, I'll take it right after.
It will be the first one in the list.
Thanks, here you go.
Thanks. I've just applied it after adding the prefix "ARM: dts:" to the
subject.
Regards,
Benoit
Pavel
---
This adds device tree with neccessary support to boot with functional
video (on both emulator and real N900 device).
Signed-off-by: Pavel Machek
Signed-off-by: Aaro Koskinen
---
From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
can be enabled on 3.10, and tested it on that kernel.
From v2: spelling, improved comments. Tested on 3.11-rc (0ed4402).
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a0f2365..c48b1ef 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -162,6 +162,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
+ omap3-n900.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
new file mode 100644
index 000..7ff90f8
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2013 Pavel Machek
+ * Copyright 2013 Aaro Koskinen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 (or later) as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include "omap34xx.dtsi"
+
+/ {
+ model = "Nokia N900";
+ compatible = "nokia,omap3-n900", "ti,omap3";
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vcc>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+};
+
+&i2c1 {
+ clock-frequency = <220>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ };
+};
+
+#include "twl4030.dtsi"
+
+&twl_gpio {
+ ti,pullups = <0x0>;
+ ti,pulldowns= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
+};
+
+&i2c2 {
+ clock-frequency = <40>;
+};
+
+&i2c3 {
+ clock-frequency = <10>;
+};
+
+&mmc1 {
+ status = "disabled";
+};
+
+&mmc2 {
+ status = "disabled";
+};
+
+&mmc3 {
+ status = "disabled";
+};
+
+&mcspi1 {
+ /*
+* For some reason, touchscreen is necessary for screen to work at
+* all on real hw. It works well without it on emulator.
+*
+* Also... order in the device tree actually matters here.
+*/
+ tsc2005@0 {
+ compatible = "tsc2005";
+ spi-max-frequency = <600>;
+ reg = <0>;
+ };
+ mipid@2 {
+ compatible = "acx565akm";
+ spi-max-frequency = <600>;
+ reg = <2>;
+ };
+};
+
+&usb_otg_hs {
+ interface-type = <0>;
+ usb-phy = <&usb2_phy>;
+ mode = <2>;
+ power = <50>;
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: am33xx: Correct gpio #interrupt-cells property
Hi lars, On 07/08/2013 17:11, Lars Poeschel wrote: On Wednesday 07 August 2013 at 16:53:09, Mark Rutland wrote: On Wed, Aug 07, 2013 at 12:06:32PM +0100, Lars Poeschel wrote: From: Lars Poeschel Following commit ff5c9059 and therefore other omap platforms using the gpio-omap driver correct the #interrupt-cells property on am33xx too. The omap gpio binding documentaion also states that the #interrupt-cells property should be 2. I take it there are no device nodes for which any of these nodes are an interrupt parent (which would need to be updated)? As far as I know: No. Lars If so: Acked-by: Mark Rutland Thanks, Mark. Signed-off-by: Lars Poeschel Thank, applied with Mark and Javier A-By / R-By. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: omap5: dts: split SMPS10 dt node
Hi Kishon,
On 12/08/2013 11:37, Kishon Vijay Abraham I wrote:
SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as
two regulators. The dt node is split to reflect it.
Mmm, I'm curious. How is it supposed to work?
Do you have dedicated control on each output?
Otherwise, it should be seen as one output with two potential consumers.
Regards,
Benoit
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5-uevm.dts | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..05b9b12 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,9 +334,18 @@
ti,smps-range = <0x80>;
};
- smps10_reg: smps10 {
+ smps10_out2_reg: smps10_out2 {
/* VBUS_5V_OTG */
- regulator-name = "smps10";
+ regulator-name = "smps10_out2";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps10_out1_reg: smps10_out1 {
+ /* VBUS_5V_OTG */
+ regulator-name = "smps10_out1";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-always-on;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: DTS: AM33XX: Add PMU support
Salut Alexandre, On 03/08/2013 20:00, Alexandre Belloni wrote: ARM Performance Monitor Units are available on the am33xx, add the support in the dtsi. Tested with perf and oprofile on a regular beaglebone. Signed-off-by: Alexandre Belloni Thanks, applied for 3.12. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] N900: add device tree
Hi Pavel,
I finally got released by the aliens. It took longer than expected and
beside a small scar on the back of my neck, I feel pretty OK.
I just have few cosmetic comments on top of Javier's ones.
On 11/08/2013 17:02, Javier Martinez Canillas wrote:
Hi Pavel,
some minor comments about your patch below
On Sat, Jul 13, 2013 at 2:17 PM, Pavel Machek wrote:
This adds device tree with neccessary support to boot with functional
Typo^
video (on both emulator and real N900 device).
Signed-off-by: Pavel Machek
---
From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
can be enabled on 3.10, and tested it on that kernel.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..1950aed 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -141,6 +141,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
+ omap3-n900.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
new file mode 100644
index 000..fb461bf
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2013 Pavel Machek
+ * Copyright 2013 Aaro Koskinen
+ *
+ * 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/ "omap34xx.dtsi"
+
The current trend is to use #include "omap34xx.dtsi" instead /include/
in order to use the C pre-processor and the macros defined in
include/dt-bindings.
+/ {
+ model = "Nokia N900";
+ compatible = "nokia,omap3-n900", "ti,omap3";
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vcc>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+};
+
+&i2c1 {
+ clock-frequency = <220>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ };
+};
+
+/include/ "twl4030.dtsi"
+
+&twl_gpio {
+ ti,pullups = <0x0>;
+ ti,pulldowns= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
+};
+
+&i2c2 {
+ clock-frequency = <40>;
+};
+
+&i2c3 {
+ clock-frequency = <10>;
+};
+
+&mmc1 {
+ status = "disabled";
+};
+
+&mmc2 {
+ status = "disabled";
+};
+
+&mmc3 {
+ status = "disabled";
+};
+
+&mcspi1 {
+ // For some reason, touchscreen is neccessary for screen to work at
Same typo than before---^
+ // all on real hw. It works well without it on emulator.
+ //
+ // Also... order in the device tree actually matters here.
Nit: Please use the regular Linux style comment.
The order should not matter at all in DT, it should be a static
representation of the HW, so there is probably something wrong in the
code that make the device creation order important.
+ tsc2005@0 {
+ compatible = "tsc2005";
+ spi-max-frequency = <600>;
+ reg = <0>;
+ };
+ mipid@2 {
+ compatible = "acx565akm";
+ spi-max-frequency = <600>;
+ reg = <2>;
+ // turbo_mode = 0,
+ // cs_per_word = 0
+ };
+};
You should remove these properties if they are not being used instead
of keeping them as commented.
+
+&usb_otg_hs {
+ interface-type = <0>;
+ usb-phy = <&usb2_phy>;
+ mode = <2>;
+ power = <50>;
+};
Beside my comments and the ones from Javier, it looks good.
If you can repost ASAP, I'll take it right after.
It will be the first one in the list.
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 0/3] ARM: dts: omap5-uevm: fixup wrong regulator configuration
Hi Nishanth, Thanks for the quick update. On 29/07/2013 19:03, Nishanth Menon wrote: > Due to wrong older revision of documentation used as reference, we > seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This > series is based power tree on production board 750-2628-XXX platform. > Unfortunately, the wrong voltages may be detrimental to OMAP5 as they > supply hardware blocks at voltages that are out of specification. > > Also available at: > based on v3.11-rc1 tag > http link: > https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes-v2 > git link: git://github.com/nmenon/linux-2.6-playground.git > branch: push/omap5-palmas-fixes-v2 > > Changes since V1: > - squash of patches > - picked up Ack from Keerthy > - based on v3.11-rc3 tag > > V1: http://marc.info/?t=13740798018&r=1&w=2 > > Nishanth Menon (3): > ARM: dts: omap5-uevm: document regulator signals used on the actual > board > ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC > ARM: dts: omap5-uevm: update optional/unused regulator configurations > > arch/arm/boot/dts/omap5-uevm.dts | 78 > -- > 1 file changed, 49 insertions(+), 29 deletions(-) > > Regards, > Nishanth Menon For the whole series: Acked-by: Benoit Cousson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator configuration
Hi Nishanth, On 29/07/2013 15:17, Nishanth Menon wrote: > On 07/29/2013 04:57 AM, Keerthy wrote: >> Hi Nishanth, >> >> On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote: >>> Due to wrong older revision of documentation used as reference, we >>> seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This >>> series is based power tree on production board 750-2628-XXX platform. >>> Unfortunately, the wrong voltages may be detrimental to OMAP5 as they >>> supply hardware blocks at voltages that are out of specification. >> >> This series looks good to me. >> >> Acked-by: J Keerthy > > Tony, Benoit - this series could prevent OMAP5 from being damaged on > uEVMs with current 3.11 rc - could you suggest what we need to do to > get it in? I'm still on vacation with no way to pull any patch... but I can still comment on the series quickly. It seems to me that this series contains some real fixes that might damage the board due to hihest voltage than expected and some which are just improvement like for the SMPS9 or LDO[28]. In theory they should no go necesseraly to -rc, but, I guess that's fine for that one. All the "fixes" are sharing more than 50% of the changelog content with only 2 changes in the code, so you'd better squash them into one patch to avoid repeating the same thing again and again. Beside that, I will ack the updated one to allow Tony to push them ASAP. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 wrote: >> From: Joel A Fernandes >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
Hi Tony, On 06/24/2013 12:19 PM, Tony Lindgren wrote: > Hi, > > For merging this series, I suggest the following sets: > > * Joel A Fernandes [130620 14:13]: >> >> Joel A Fernandes (3): >> edma: config: Enable config options for EDMA >> da8xx: config: Enable MMC and FS options >> ARM: davinci: Fix compiler warnings in devices-da8xx >> >> Matt Porter (8): >> dmaengine: edma: Add TI EDMA device tree binding >> ARM: edma: Add DT and runtime PM support to the private EDMA API >> ARM: edma: Add EDMA crossbar event mux support >> dmaengine: edma: enable build for AM33XX > > Sekhar should queue the above patches, I've acked the > mach-omap2/Kconfig change. > >> spi: omap2-mcspi: add generic DMA request support to the DT binding >> spi: omap2-mcspi: convert to dma_request_slave_channel_compat() > > > The spi changes should get merged via the driver list. > >> ARM: dts: add AM33XX EDMA support >> ARM: dts: add AM33XX SPI DMA support > > Benoit should queue the .dts changes. I'll do that, but do you consider them for 3.11? Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 [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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 [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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 [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
---
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
--
To unsubscribe from this list: send the line &quo
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
---
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";
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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"
> Cc: Tony Lindgren
> Cc: Russell King
> Cc: linux-o...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin
> Signed-off-by: J Keerthy
> ---
> 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
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
Cc: Russell King
Signed-off-by: Eduardo Valentin
Signed-off-by: J Keerthy
Signed-off-by: Benoit Cousson
---
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 = ;
};
};
+
+ bandgap@4a0021e0 {
+ reg = <0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c>;
+ interrupts = ;
+ compatible = "ti,omap5430-bandgap";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 [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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: dts: AM33XX: Add PWMSS device tree nodes
Hi Sebastian, On 06/18/2013 08:36 AM, Sebastian Andrzej Siewior wrote: On 06/12/2013 06:40 PM, Felipe Balbi wrote: On Wed, Jun 12, 2013 at 06:10:32PM +0200, Sebastian Andrzej Siewior wrote: On 06/06/2013 03:52 PM, Sebastian Andrzej Siewior wrote: From: Philip Avinash Add PWMSS device tree nodes in relation with ECAP & EHRPWM DT nodes to AM33XX SoC family. Also populates device tree nodes for ECAP & EHRPWM by adding necessary properties like pwm-cells, base reg & set disabled as status. Can someone please grab #2 till #4? Paul took just #1 as far as I can tell. DTS should be Benoit Cousson So, Benoit. Would you please be so kind and pick up the dts pieces? That's done. Patches are available in git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
---
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>;
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
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 */
+ };
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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-disc...@lists.ozlabs.org;
> linux-o...@vger.kernel.org; linux-kernel@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
> Signed-off-by: Graeme Gregory
> ---
> 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
> +
> +&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>;
> +
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 >> --- >> 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 = ; /* >> 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 I've just applied it with Florian's Reviewed-by. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
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>;
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
> Signed-off-by: Afzal Mohammed
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
> +
> +#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 = ;
> + };
> +
> + timer1: timer@44e31000 {
> + compatible =
> "ti,am4372-timer-1ms","ti,am335x-timer-1ms";
> + reg = <0x44e31000 0x400>;
> + interrupts = ;
> + ti,timer-alwon;
> + };
> +
> + timer2: timer@4804 {
> + compatible = "ti,am4372-timer","ti,am335x-timer";
> + reg = <0x4804 0x400>;
> + interrupts = ;
> + };
> +
> + counter32k: counter@44e86000 {
> + compatible =
> "ti,am4372-counter32k","ti,omap-counter32k";
> + reg = <0x44e86000 0x40>;
> + };
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
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>;
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 14/14] ARM: dts: AM43x: initial support
On 05/29/2013 10:57 AM, Florian Vaussard wrote:
> Hello,
>
> On 05/29/2013 10:53 AM, Benoit Cousson wrote:
>> + 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
>>> Signed-off-by: Afzal Mohammed
>>> ---
>>>
>>> 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.
>>
>
> If you pull the patch in your branch, I can take care of the changes
> when I rebase
> my series. This will allow me to clean the 'interrupts' statements below
> as well.
Ooops, thanks, I missed that one.
Thanks,
Benoit
>
> Regards,
>
> Florian
>
>> 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>;
>>> +};
>>> +};
>>> +};
>>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
> Signed-off-by: Afzal Mohammed
> ---
>
> 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>;
> + };
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
Hi Eduardo,
On 05/15/2013 06:36 PM, Eduardo Valentin wrote:
> On 15-05-2013 11:23, Benoit Cousson wrote:
>> Hi Eduardo,
>>
>> On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
>>> Include bandgap devices for OMAP4460 devices.
>>>
>>> Cc: "Benoît Cousson"
>>> Cc: Tony Lindgren
>>> Cc: Russell King
>>> Cc: linux-o...@vger.kernel.org
>>> Cc: devicetree-disc...@lists.ozlabs.org
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Eduardo Valentin
>>> ---
>>> 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?
>
> I believe it was by your suggestion :-), during the first attempts to
> send this driver. But could not find the thread link :-( sorry.
Ooops :-) I do not remember that... maybe it was long time ago, before
we had any decent binding available for GPIO and IRQ...
> I guess the reasoning to mark it as a ti specific is because it will be
> used as IRQ line to treat thermal shutdown (in SW).
Mmm, ok, so in that case, it is not even a gpio, but an interrupt entry
that is needed like that:
interrupt-parent = <&gpio3>;
interrupts = <22>; /* gpio line 86 */
Except that we already have an IRQ line connected to GIC for the
Talert... I'm not sure we can have 2 different IRQ controllers for one
device :-(
We need to check.
Regards,
Benoit
>> Where is the gpio controller phandle?
>>
>> Usually it looks like this:
>>
>> gpios = <&gpio1 8 0>;
>>
>>
>> Regards,
>> Benoit
>>
>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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"
> Cc: Tony Lindgren
> Cc: Russell King
> Cc: linux-o...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: OMAP4: HWMOD: make 'ocp2scp_usb_phy_phy_48m" as the main clock
Hi Kishon,
On 04/09/2013 10:28 AM, Kishon Vijay Abraham I wrote:
> commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
> clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
> functional clock causing regression in MUSB. But this 48MHz clock is a
> mandatory clock for usb phy attached to ocp2scp and hence made as the main
> clock for ocp2scp.
It is a fix for 3.9-rcX?
Regards,
Benoit
>
> Cc: Keerthy
> Cc: Benoît Cousson
> Cc: Paul Walmsley
> Signed-off-by: Kishon Vijay Abraham I
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 9e05765..c1fb090 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -2714,16 +2714,12 @@ static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
> { }
> };
>
> -static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
> - { .role = "48mhz", .clk = "ocp2scp_usb_phy_phy_48m" },
> -};
> -
> /* ocp2scp_usb_phy */
> static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
> .name = "ocp2scp_usb_phy",
> .class = &omap44xx_ocp2scp_hwmod_class,
> .clkdm_name = "l3_init_clkdm",
> - .main_clk = "func_48m_fclk",
> + .main_clk = "ocp2scp_usb_phy_phy_48m",
> .prcm = {
> .omap4 = {
> .clkctrl_offs =
> OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
> @@ -2732,8 +2728,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod
> = {
> },
> },
> .dev_attr = ocp2scp_dev_attr,
> - .opt_clks = ocp2scp_usb_phy_opt_clks,
> - .opt_clks_cnt = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
> };
>
> /*
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Tony, On 04/05/2013 05:43 PM, Tony Lindgren wrote: > * Benoit Cousson [130405 03:00]: >> On 04/05/2013 10:30 AM, Benoit Cousson wrote: >> >> ... >> >>>> ARM: dts: OMAP4: Add HS USB Host IP nodes >>>> ARM: dts: OMAP3: Add HS USB Host IP nodes >>>> ARM: dts: omap3-beagle: Add USB Host support >>> >>> These 3 DTS patches are good to me, but I cannot applied them on top of >>> the already existing patches I queued for 3.10. >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git >>> for_3.10/dts >>> >>> Could you rebase these 3 ones only, and I will applied them. >> >> Mmm, in fact, I've just seen the pull request from Tony :-( >> >> >> Tony, >> >> Don't you want to remove these DTS patches from the pull-request? > > Oops sorry :( Looks like I applied them mistakenly as I saved all > the patches into a mbox, then applied it. Anyways, too late to start > messing with it now. > >> Otherwise, I will have to rebase the whole DTS series on top of yours. >> That being said, if the branch is not supposed to be rebased, it is doable. > > I pulled in your for_3.10/dts for testing, and to me it looks like > it's just overlapping additions. So that should be OK to resolve while > pulling it in. > > It seems there's no need to add omap-for-v3.10/usb as a dependency for > your for_3.10/dts unless the conflict gets non-trivial with some > additional patches. The branch was not complete, with the latest additions, we do have conflict due to the addition of several new nodes at the same place. The resolution is not that hard since it is addition of node only, but the rebase on to of omap-for-v3.10/usb will avoid the issue. I have a new pre-merged branch available. for_3.10/dts_merged is based on omap-for-v3.10/usb and Paul's omap-devel-b-for-3.10 branch to get the AM33xx hwmod. Paul's branch is just needed to avoid AM33xx regression introduced by Santosh hwmod changes present in my branch. Just let me know which one you will prefer to pull. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Roger, On 04/05/2013 10:30 AM, Benoit Cousson wrote: ... >> ARM: dts: OMAP4: Add HS USB Host IP nodes >> ARM: dts: OMAP3: Add HS USB Host IP nodes >> ARM: dts: omap3-beagle: Add USB Host support > > These 3 DTS patches are good to me, but I cannot applied them on top of > the already existing patches I queued for 3.10. > > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > for_3.10/dts > > Could you rebase these 3 ones only, and I will applied them. Mmm, in fact, I've just seen the pull request from Tony :-( Tony, Don't you want to remove these DTS patches from the pull-request? Otherwise, I will have to rebase the whole DTS series on top of yours. That being said, if the branch is not supposed to be rebased, it is doable. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Roger, On 03/20/2013 04:44 PM, Roger Quadros wrote: > Hi Tony, > > These patches provide the SoC side code required to support > the changes in the OMAP USB Host drivers done in [1], [2] & [3]. > > Device tree support is added for Beagleboard only. I've removed > Panda device tree support till we have resolved the AUXCLK issue. > > NOTE: The first patch needs to be shared between the > OMAP tree and Felipe's USB tree. > > v4: > - Some more cleanup to usbhs_init_phys(). Moved repeated code into > another helper function usbhs_add_regulator(). > - Removed patch for Panda device tree support for USB host since > it is non functional. > > v3: > - Moved more functionality into usbhs_init_phys(). > > v2: > - Added helper function usbhs_init_phys() that can be used by board files > to simplify adding of PHY regulators for USB host ports. > > [1] MFD side changes to omap-usb-host and omap-usb-tll > https://lkml.org/lkml/2013/3/12/179 > [2] USB EHCI side changes to ehci-omap > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86265.html > [3] USB PHY driver changes > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86293.html > > The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: > > Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) > > are available in the git repository at: > git://github.com/rogerq/linux.git usbhost-arm-next > > Roger Quadros (21): > usb: phy: nop: Add some parameters to platform data > ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys() > ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes > ARM: OMAP3: Beagle: Adapt to ehci-omap changes > ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes > ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes > ARM: OMAP: AM3517crane: Adapt to ehci-omap changes > ARM: OMAP: AM3517evm: Adapt to ehci-omap changes > ARM: OMAP3: cm-t35: Adapt to ehci-omap changes > ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes > ARM: OMAP: devkit8000: Adapt to ehci-omap changes > ARM: OMAP3: igep0020: Adapt to ehci-omap changes > ARM: OMAP3: omap3evm: Adapt to ehci-omap changes > ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes > ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes > ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes > ARM: OMAP3: overo: Adapt to ehci-omap changes > ARM: OMAP: zoom: Adapt to ehci-omap changes > ARM: dts: OMAP4: Add HS USB Host IP nodes > ARM: dts: OMAP3: Add HS USB Host IP nodes > ARM: dts: omap3-beagle: Add USB Host support These 3 DTS patches are good to me, but I cannot applied them on top of the already existing patches I queued for 3.10. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Could you rebase these 3 ones only, and I will applied them. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 wrote: >> Hi, >> >> On 03/06/2013 06:53 PM, Tony Lindgren wrote: >>> * Anil Kumar [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-disc...@lists.ozlabs.org; linux-o...@vger.kernel.org; >>>>>> linux-kernel@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 >>>>>>> Tested-by: Thomas Weber >>>>>> >>>>>> 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 >>>> >>>> and as patch "ARM: dts: omap3-devkit8000: Enable audio support" has >>>> already got >>>> "Acked-by: Peter Ujfalusi " 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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(-) >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
