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 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] 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 bcous...@baylibre.com Cc: Tony Lindgren t...@atomide.com Cc: linux-o...@vger.kernel.org Cc: devicet...@vger.kernel.org Signed-off-by: Nishanth Menon n...@ti.com Acked-by: Benoît Cousson bcous...@baylibre.com 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 p...@pwsan.com -- 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"
+ *
+ * _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 = <_hdmi_bonelt_pins>;
+ * pinctrl-1 = <_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 = <>;
+ ti,mcasp-controller = <>;
+ 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 = <_audio_cape_led_pins>;
+
+ audio-led0 {
+ label = "audio:green:usr0";
+ gpios = < 18 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ audio-led1 {
+ label = "audio:green:usr1";
+ gpios = < 19 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ };
+};
+
+_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 */
+ >;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+ clock-frequency = <10>;
+
+ tlv320aic3106: tlv320aic3106@1b {
A more generic name will be prefered here.
Regards,
Benoit
--
Benoît Cousson
BayLibre
Embedded Linux Technology
Re: [PATCH] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
On 28/02/2014 23:17, Tony Lindgren wrote:
* Jack Mitchell m...@embed.me.uk [140122 03:09]:
From: Jack Mitchell j...@embed.me.uk
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 j...@embed.me.uk
Signed-off-by: Matt Porter mpor...@linaro.org
---
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 j...@embed.me.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.
+ *
+ * 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.
Regards,
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 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 tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
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 bcous...@baylibre.com
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 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 1/2] leds: lp55xx: handle enable pin in driver
On 23/10/2013 10:19, Tony Lindgren wrote: * Bryan Wu coolo...@gmail.com [131022 10:47]: On Tue, Oct 22, 2013 at 10:37 AM, Tony Lindgren t...@atomide.com wrote: * Bryan Wu coolo...@gmail.com [131022 10:23]: On Tue, Oct 22, 2013 at 10:06 AM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@debian.org [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 t...@atomide.com I'm OK for LED parts, will this patch go through omap tree? If so, please add my ack. Acked-by: Bryan Wu coolo...@gmail.com 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 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 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=1=2 [2] http://marc.info/?l=linux-arm-kernel=136804009618594=2 [3] http://marc.info/?l=devicetree=138135419203492=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 = <_reg>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led@0 {
+ label = "nanobone:green:usr1";
+ gpios = < 5 0>;
+ default-state = "off";
+ };
+ };
+};
+
+_pinmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <_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_csn1 */
+
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>;
};
+_port1 {
+ ti,ssi-cawake-gpio = < 23 GPIO_ACTIVE_HIGH>; /* 151 */
+
+ ssi-char {
+ compatible = "ssi-char";
+ };
+};
+
+_port2 {
+ status = "disabled";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_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 = <>;
+ 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 = <>;
+ 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: 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: [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 s...@debian.org
---
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 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 m...@newflow.co.uk
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
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 m...@newflow.co.uk
+L: linux-o...@vger.kernel.org
+S: Maintained
+F: arch/arm/boot/dts/am335x-nano.dts
+
OMFS FILESYSTEM
M:Bob Copeland m...@bobcopeland.com
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
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 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=13813328426r=1w=2 [2] http://marc.info/?l=linux-arm-kernelm=136804009618594w=2 [3] http://marc.info/?l=devicetreem=138135419203492w=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: [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 @@
_otg_hs {
interface-type = <0>;
usb-phy = <_phy>;
+ phys = <_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] 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 rog...@ti.com
---
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 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 n...@ti.com 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 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 george.cher...@ti.com 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 george.cher...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com 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] 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=133066647800872=2
GPIO1 reset causes PandaBoard-ES to stop functioning.
This depends on Patch series from Rajendra:
http://marc.info/?l=linux-doc=138131355520116=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 = < 8 GPIO_ACTIVE_HIGH>;
};
};
+
+ {
+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 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 rog...@ti.com Acked-by: Felipe Balbi ba...@ti.com 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] 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 n...@ti.com
---
As explained here: http://marc.info/?l=u-bootm=133066647800872w=2
GPIO1 reset causes PandaBoard-ES to stop functioning.
This depends on Patch series from Rajendra:
http://marc.info/?l=linux-docm=138131355520116w=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 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 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 = < 6 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 v2 5/9] am33xx: dts: Fix AES interrupt number
On 30/09/2013 17:13, Joel Fernandes wrote: Signed-off-by: Joel Fernandes jo...@ti.com 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 = < 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 = <_reset>;
+reset-gpios = < 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <_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 = < 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 = <_reset>;
+reset-gpios = < 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <_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
egulator-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.
>>>{
>>>
>> 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 = <_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 = < 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 = <_reset>;
+ reset-gpios = < 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <_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
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 rog...@ti.com
---
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
-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 n...@ti.com
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 j-keer...@ti.com
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 j-keer...@ti.com
Acked-by: Nishanth Menon n...@ti.com
[bcous...@baylibre.com: Fix indentation and changelog]
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
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 */
+ regulator-name = smps45;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 115;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ /* VDD_GPU - over VDD_SMPS6 */
+ regulator-name = smps6;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 1250;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ /* CORE_VDD */
+ regulator-name = smps7;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 103;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ /* VDD_IVAHD */
+ regulator-name = smps8;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 125;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ /* VDDS1V8 */
+ regulator-name = smps9;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1
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 rog...@ti.com
---
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 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 rog...@ti.com
---
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: 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 dmur...@ti.com Tested this with beagle bone black. Tested-by: Mugunthan V N mugunthan...@ti.com 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 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=137889435710552=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 v4 2/4] ARM: dts: am335x-boneblack: add eMMC DT entry
Hi Tony,
On 13/09/2013 17:27, Tony Lindgren wrote:
* Koen Kooi k...@dominion.thruhere.net [130912 11:43]:
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
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 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-kernelm=137889435710552w=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 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=137883926226451=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 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-omapm=137883926226451w=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: [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 mpor...@ti.com
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 jo...@ti.com
Discussion in [1].
v3 changes: Changed node name from edma: edma@ to edma: dma-controller@
by Sebastian Andrzej Siewior bige...@linutronix.de
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
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 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 bige...@linutronix.de AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi ba...@ti.com 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
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 bige...@linutronix.de AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi ba...@ti.com 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 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
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: 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 bige...@linutronix.de 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: 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
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 bige...@linutronix.de AuthorDate: Thu Jun 20 12:13:04 2013 +0200 Commit: Felipe Balbi ba...@ti.com 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: [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] 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 m...@ti.com
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 mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
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 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 m...@ti.com
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 mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
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 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 feature is not mandatory to ensure the s
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: stringlist 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 feature is not mandatory to ensure the system
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] ARM: dts: am33xx: Correct gpio #interrupt-cells property
Hi Tony, On 21/08/2013 09:59, Tony Lindgren wrote: * Lars Poeschel poesc...@lemonage.de [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 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 ba...@ti.com 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 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 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 bcous...@baylibre.com 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 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? No, that's fine, I already applied it and fixed the subject and the changelog. Here it is: commit 2e25df1e5a4af906a9b25332719ace63eb0d Author: Ruslan Bilovol ruslan.bilo...@ti.com 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 ruslan.bilo...@ti.com Signed-off-by: Benoit Cousson bcous...@baylibre.com 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 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 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 using a newer version of the IP with
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 = _rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
- },
{ .compatible = "ti,am3352-rtc",
.data = _rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
},
+ { .compatible = "ti,da830-rtc",
+ .data = _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 = <>;
+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] 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 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 george.cher...@ti.com
---
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 = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
+#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 = GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH;
+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: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 ma...@goldelico.com --- 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 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 ruslan.bilo...@ti.com mailto:ruslan.bilo...@ti.com wrote: Hi Benoit, On Wed, Aug 14, 2013 tel:2013 at 4:51 PM, Benoit Cousson bcous...@baylibre.com 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 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 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? No, that's fine, I already applied it and fixed the subject and the changelog. Here it is: commit 2e25df1e5a4af906a9b25332719ace63eb0d Author: Ruslan Bilovol ruslan.bilo...@ti.com 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 ruslan.bilo...@ti.com Signed-off-by: Benoit Cousson bcous...@baylibre.com 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 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 gururaja.heb...@ti.com
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 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: stringlist 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 using a newer version of the IP with an extended programming model cannot claim that. Otherwise they get plain RTC functionality - but at least they get something instead of no RTC. Because you assume that this feature is not important and thus you can use the plain RTC, but what if someone is buying that HW because of this new feature. Without that feature his system will just not work
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 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 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/
