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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: 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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/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-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 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-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 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-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] USB: phy: phy-nop: Manage RESET GPIO in the driver
Hi Roger, On 15/08/2013 12:18, Roger Quadros wrote: Hi, Modelling the RESET line as a regulator supply wasn't a good idea as it abuses the regulator framework and makes adaptation code/data more complex. Instead, manage the RESET gpio line directly in the driver. This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available. As of now, it doesn't seem to be making it into 3.12. *NOTE:* As there are changes to platform data, Patch 1 needs to be shared between the arm-soc tree and usb tree. Patch 1 is available at repo git://github.com/rogerq/linux.git in branch phy-reset-common Patch 2 contains the phy-nop driver changes Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. Patches 5, 6 and 7 adapt DT data to the binding changes. Patch 8 is cleanup of omap3-beagle DT. Patch 9 adds USB host support to omap3-beagle-xm using the new binding. Patches are based on v3.11-rc5. Tested leacy boot on omap3-beagle and omap3-beagle-xm Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-es v2: - Added RESET GPIO polarity feature - Changed to gpio_set_value_cansleep() cheers, -roger --- Roger Quadros (9): usb: phy: nop: Add gpio_reset to platform data usb: phy: nop: Don't use regulator framework for RESET line ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset ARM: dts: omap5-uevm: Use reset-gpios for hsusb2_reset ARM: dts: omap3-beagle: Make USB host pin naming consistent ARM: dts: omap3-beagle-xm: Add USB Host support The 5 DTS patches looks good to me, and I can apply them, but you need to be sure that the driver will be merged for 3.12 as well. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 7/8] ARM: dts: omap4: update omap-control-usb nodes
Hi Roger,
Sorry I missed something in the previous revision :-(
On 16/08/2013 15:09, Roger Quadros wrote:
Split otghs_ctrl and USB2 PHY power down into separate
omap-control-usb nodes. Get rid of ti,type property.
You should add that you update the usb_otg_hs node accordingly as well.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..a77dd0a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
- ctrl-module = omap_control_usb;
+ ctrl-module = omap_control_usb2phy;
};
};
@@ -643,12 +643,16 @@
};
};
- omap_control_usb: omap-control-usb@4a002300 {
- compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
- reg-names = control_dev_conf, otghs_control;
- ti,type = 1;
+ omap_control_usb2phy: omap-control-usb@4a002300 {
+ compatible = ti,usb2-control-usb;
+ reg = 0x4a002300 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usbotg: omap-control-usb@4a00233c {
+ compatible = ti,omap4-control-usb;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
};
usb_otg_hs: usb_otg_hs@4a0ab000 {
@@ -661,7 +665,7 @@
multipoint = 1;
num-eps = 16;
ram-bits = 12;
- ti,has-mailbox;
+ ctrl-module = omap_control_usbotg;
In omap-usb.txt, ti,has-mailbox is still marked as mandatory whereas the
ctrl-module is optional.
You should update the usb-otg-hs bindings as well.
BTW, why is that property not prefixed with ti,? Is ctrl-module really
meaningful for other arch?
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/8] usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power()
Hi Roger,
On 15/08/2013 15:15, Roger Quadros wrote:
Add support for new device types and in the process rid of ti,type
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types Mailbox, USB2, USB3 and DRA7.
Update DT binding information to reflect these changes.
Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 29 ++--
drivers/usb/phy/phy-omap-control.c | 148
drivers/usb/phy/phy-omap-usb2.c|4 +
drivers/usb/phy/phy-omap-usb3.c|6 +-
include/linux/usb/omap_control_usb.h | 24 ++--
5 files changed, 122 insertions(+), 89 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..1c6b54a 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -73,22 +73,23 @@ omap_dwc3 {
OMAP CONTROL USB
Required properties:
- - compatible: Should be ti,omap-control-usb
+ - compatible: Should be one of
+ ti,omap-control-usb - if it has otghs_control mailbox register
+ e.g. on OMAP4.
How generic is that one? I mean if this is applicable for OMAP4 only,
you'd better name it omap4-control-usb.
+ ti,usb2-control-usb - if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ ti,usb3-control-usb - if it has DPLL and individual Rx Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ ti,dra7-control-usb - if it has both power down and power aux registers
+ e.g. USB2 PHY on DRA7 platform.
+
- reg : Address and length of the register set for the device. It contains
- the address of control_dev_conf and otghs_control or phy_power_usb
- depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the
registers
- filled in reg.
- - ti,type: This is used to differentiate whether the control module has
- usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
- notify events to the musb core and omap5 has usb3 phy power register to
- power on usb3 phy. Should be 1 if it has mailbox and 2 if it has usb3
- phy power.
+ the address of otghs_control for type 1 or power register for other
types.
+ For type 4, it must also contain power_aux register.
+ - reg-names: should be otghs_control for type 1 and power for other types.
type1 and 4 are less obvious now that you have name, you should be more
explicit and name them directly.
omap_control_usb: omap-control-usb@4a002300 {
compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
- reg-names = control_dev_conf, otghs_control;
- ti,type = 1;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
};
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 3b9ee83..078c46f 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -46,61 +46,76 @@ struct device *omap_get_control_dev(void)
EXPORT_SYMBOL_GPL(omap_get_control_dev);
/**
- * omap_control_usb3_phy_power - power on/off the serializer using control
- * module
+ * omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
- * @on: 0 to off and 1 to on based on powering on or off the PHY
- *
- * usb3 PHY driver should call this API to power on or off the PHY.
+ * @on: 0 or 1, based on powering on or off the PHY
*/
-void omap_control_usb3_phy_power(struct device *dev, bool on)
+void omap_control_usb_phy_power(struct device *dev, int on)
{
- u32 val;
+ u32 val, val_aux;
unsigned long rate;
- struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+ struct omap_control_usb *control_usb;
- if (control_usb-type != OMAP_CTRL_DEV_TYPE2)
+ if (IS_ERR(dev) || !dev) {
+ pr_err(%s: invalid device\n, __func__);
return;
+ }
- rate = clk_get_rate(control_usb-sys_clk);
- rate = rate/100;
+ control_usb = dev_get_drvdata(dev);
+ if (!control_usb) {
+ dev_err(dev, %s: invalid control usb device\n, __func__);
+ return;
+ }
- val = readl(control_usb-phy_power);
+ if (control_usb-type == OMAP_CTRL_TYPE_OMAP)
+ return;
- if (on) {
- val = ~(OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_USB_PWRCTL_CLK_FREQ_MASK);
- val |=
Re: [PATCH 6/7] ARM: dts: omap4: update omap-control-usb nodes
Hi Roger,
On 01/08/2013 16:05, Roger Quadros wrote:
Split otghs_ctrl and USB2 PHY power down into separate
omap-control-usb nodes. Update ti,mode property.
Nit: I guess you mean ti,type?
CC: Benoit Cousson benoit.cous...@linaro.org
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..9a6fa27 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
- ctrl-module = omap_control_usb;
+ ctrl-module = omap_control_usb2phy;
};
};
@@ -643,11 +643,17 @@
};
};
- omap_control_usb: omap-control-usb@4a002300 {
+ omap_control_usb2phy: omap-control-usb@4a002300 {
compatible = ti,omap-control-usb;
- reg = 0x4a002300 0x4,
- 0x4a00233c 0x4;
- reg-names = control_dev_conf, otghs_control;
+ reg = 0x4a002300 0x4;
+ reg-names = power;
+ ti,type = 2;
Now that we can use the C preprocessor, it will be nice to use a macro instead
of the value.
TYPE1 - if it has otghs_control mailbox register (e.g. on OMAP4)
TYPE2 - if it has Power down bit in control_dev_conf register. e.g. USB2 PHY
TYPE3 - if it has DPLL and individual Rx Tx power control. e.g. USB3 PHY or
SATA PHY
TYPE4 - if it has both power down and power aux registers. e.g. USB2 PHY on DRA7
Well, assuming you can find macro names that can explain a little bit what the
type is about :-)
That being said...
Do you really need to expose the type here? Maybe with just a set of different
compatible string you can figure out in the driver what type we are talking
about.
It is always better to minimize the amount of information we put in DT as soon
as we can infer it from the compatible string.
So instead of using a generic ti,omap-control-usb string + ti,type you can
potentially use several specific strings: ti,omap4-control-usb,
ti,dra7-control-usb...
Since the DT gurus are recommending to use specific compatible string as much
as possible, this is maybe a better approach.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] am33xx: create child nodes for the two musb controllers
Hi Sebastian,
On 06/26/2013 05:33 PM, Sebastian Andrzej Siewior wrote:
I've been thinkig about creating two child nodes for the independent musb
controllers on the am33. I've been thinking about the following:
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8e1248f..6aa9506 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -326,21 +326,78 @@
status = disabled;
};
usb@4740 {
compatible = ti,musb-am33xx;
- reg = 0x4740 0x1000/* usbss */
-0x47401000 0x800 /* musb instance 0 */
-0x47401800 0x800; /* musb instance 1 */
- interrupts = 17/* usbss */
- 18/* musb instance 0 */
- 19; /* musb instance 1 */
- multipoint = 1;
- num-eps = 16;
- ram-bits = 12;
- port0-mode = 3;
- port1-mode = 3;
- power = 250;
+ reg = 0x4740 0x1000; /* usbss */
+ interrupts = 17;
BTW, why do have so many DMA compared to the previous version?
/* usbss */
ti,hwmods = usb_otg_hs;
+
+ usb0@0x47401000 {
+ reg = 0x47401000 0x800; /* musb
instance 0 */
+ interrupts = 18; /* musb
instance 0 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port-mode = 3;
+ power = 250;
+
+ phys = nopphy0;
+ dmas = cppi41dma 0
+ cppi41dma 1
+ cppi41dma 2
+ cppi41dma 3
+ cppi41dma 4
+ cppi41dma 32
+ cppi41dma 34
+ cppi41dma 36
+ cppi41dma 38
+ cppi41dma 40;
+ dma-names = rx1, rx2, rx3, rx4, rx5,
+ tx1, tx2, tx3, tx4, tx5;
+ };
+
+ usb0@0x47401800 {
+ reg = 0x47401800 0x800; /* musb
instance 1 */
+ interrupts = 19; /* musb
instance 1 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port-mode = 3;
+ power = 250;
+
+ phys = nopphy1;
+ dmas = cppi41dma 0
+ cppi41dma 1
+ cppi41dma 2
+ cppi41dma 3
+ cppi41dma 4
+ cppi41dma 62
+ cppi41dma 64
+ cppi41dma 66
+ cppi41dma 68
+ cppi41dma 70;
+ dma-names = rx1, rx2, rx3, rx4, rx5,
+ tx1, tx2, tx3, tx4, tx5;
+ };
+ };
Please keep in mind that his is not a proper patch it should point out
what I have in mind.
This would easy the for instance the dma channel assignment. Also, it will
move back to the port-mode property instead of portX-mode one which it has
now. This is kind of confusing since it is not a root hub or anything like
that it is a complete musb controller. Plus for the phys property could
easily take the one avaible and would not require which instance it
really it is.
I don't know the HW in detail, but that looks indeed much better and
seems to reflect the partitioning with multiple instances accurately.
If Felipe is OK with that partitioning, I'll take it.
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Tony, On 04/05/2013 05:43 PM, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [130405 03:00]: On 04/05/2013 10:30 AM, Benoit Cousson wrote: ... ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support These 3 DTS patches are good to me, but I cannot applied them on top of the already existing patches I queued for 3.10. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Could you rebase these 3 ones only, and I will applied them. Mmm, in fact, I've just seen the pull request from Tony :-( Tony, Don't you want to remove these DTS patches from the pull-request? Oops sorry :( Looks like I applied them mistakenly as I saved all the patches into a mbox, then applied it. Anyways, too late to start messing with it now. Otherwise, I will have to rebase the whole DTS series on top of yours. That being said, if the branch is not supposed to be rebased, it is doable. I pulled in your for_3.10/dts for testing, and to me it looks like it's just overlapping additions. So that should be OK to resolve while pulling it in. It seems there's no need to add omap-for-v3.10/usb as a dependency for your for_3.10/dts unless the conflict gets non-trivial with some additional patches. The branch was not complete, with the latest additions, we do have conflict due to the addition of several new nodes at the same place. The resolution is not that hard since it is addition of node only, but the rebase on to of omap-for-v3.10/usb will avoid the issue. I have a new pre-merged branch available. for_3.10/dts_merged is based on omap-for-v3.10/usb and Paul's omap-devel-b-for-3.10 branch to get the AM33xx hwmod. Paul's branch is just needed to avoid AM33xx regression introduced by Santosh hwmod changes present in my branch. Just let me know which one you will prefer to pull. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Roger, On 03/20/2013 04:44 PM, Roger Quadros wrote: Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] [3]. Device tree support is added for Beagleboard only. I've removed Panda device tree support till we have resolved the AUXCLK issue. NOTE: The first patch needs to be shared between the OMAP tree and Felipe's USB tree. v4: - Some more cleanup to usbhs_init_phys(). Moved repeated code into another helper function usbhs_add_regulator(). - Removed patch for Panda device tree support for USB host since it is non functional. v3: - Moved more functionality into usbhs_init_phys(). v2: - Added helper function usbhs_init_phys() that can be used by board files to simplify adding of PHY regulators for USB host ports. [1] MFD side changes to omap-usb-host and omap-usb-tll https://lkml.org/lkml/2013/3/12/179 [2] USB EHCI side changes to ehci-omap http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86265.html [3] USB PHY driver changes http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86293.html The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-arm-next Roger Quadros (21): usb: phy: nop: Add some parameters to platform data ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys() ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes ARM: OMAP3: Beagle: Adapt to ehci-omap changes ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes ARM: OMAP: AM3517crane: Adapt to ehci-omap changes ARM: OMAP: AM3517evm: Adapt to ehci-omap changes ARM: OMAP3: cm-t35: Adapt to ehci-omap changes ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes ARM: OMAP: devkit8000: Adapt to ehci-omap changes ARM: OMAP3: igep0020: Adapt to ehci-omap changes ARM: OMAP3: omap3evm: Adapt to ehci-omap changes ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes ARM: OMAP3: overo: Adapt to ehci-omap changes ARM: OMAP: zoom: Adapt to ehci-omap changes ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support These 3 DTS patches are good to me, but I cannot applied them on top of the already existing patches I queued for 3.10. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Could you rebase these 3 ones only, and I will applied them. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Roger, On 04/05/2013 10:30 AM, Benoit Cousson wrote: ... ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support These 3 DTS patches are good to me, but I cannot applied them on top of the already existing patches I queued for 3.10. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Could you rebase these 3 ones only, and I will applied them. Mmm, in fact, I've just seen the pull request from Tony :-( Tony, Don't you want to remove these DTS patches from the pull-request? Otherwise, I will have to rebase the whole DTS series on top of yours. That being said, if the branch is not supposed to be rebased, it is doable. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
Hi Kishon, On 03/13/2013 10:11 AM, kishon wrote: Benoit, Will you be queuing this patch series? I'm reviewing them right now. Regards, Benoit Thanks Kishon On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. Kishon Vijay Abraham I (7): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap and dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
+ Jon Hi Kishon, On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. The patches looks really good. I've just had to rebase on top of my HEAD due to some conflict with GPMC patch already applied. I cleaned as well some subject and changelog for consistency. The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Jon, You might have to rebase your series on top of the new HEAD before reposting. Thanks, Benoit Kishon Vijay Abraham I (7): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap and dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 23/24] ARM: OMAP2+: Allow clock alias provision from device tree
Hi Roger,
On 03/12/2013 12:43 PM, Roger Quadros wrote:
Currently on OMAP, it is not possible to specify a clock consumer
to any of the OMAP generated clocks using the device tree. This can pose
a problem for external devices that run off an OMAP clock as we
can't reliably provide a reference to the clock in the device tree.
I'm really confused by that statement... Why cannot you use the current
clock binding definition?
The point is that we should avoid defining temporary custom bindings.
Especially when a generic one already exist.
I know you already discussed that on the list, but I cannot really find
the rational in the previous thread.
Here is a quote from the original Subject: Re: how to specify an OMAP
clock in device tree? thread.
/* provider */
clks: omapclocks {
compatible = ti,omapclocks;
#clock-cells = 1;
};
/* consumer */
hsusb1_phy: hsusb1_phy {
compatible = usb-nop-xceiv;
clocks = clks auxclk3_ck; /* FREF_CLK3 */
clock-names = main-clk;
};
The only problem I see is that the argument to the clks phandle
cannot be a string. It needs to be u32.
In that case we need to map all clocks into a u32 index.
If we can do that only for auxclks, my problem is solved for panda.
phandle is u32 as always, but you should not care about that.
What you care about is the clock node referenced by the phandle, not the
phandle itself.
What is missing right now is a proper of_clk_add_provider call to
declare a generic OMAP clock provider and thus allow OMAP clocks to be
used with DT.
The AUXCLOCKs are managed by the SCRM which is outside the PRCM, so you
should be able to add a clock providers dedicated to the SCRM clocks only.
Regards,
Benoit
This patch allows device trees to provide a node that contains the
clock identifier, clock alias and the device phandle. The board
initialization code then creates a clock alias to this clock id,
and associates it with the device whose phandle was supplied.
Discussion
http://www.spinics.net/lists/linux-omap/msg86241.html
CC: Russell King li...@arm.linux.org.uk
CC: Rajendra Nayak rna...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/clock/ti-clock-alias.txt | 26
arch/arm/mach-omap2/board-generic.c| 67
2 files changed, 93 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti-clock-alias.txt
diff --git a/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
b/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
new file mode 100644
index 000..87ef4c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti-clock-alias.txt
@@ -0,0 +1,26 @@
+* Clock alias provision for TI OMAP2+ boards
+
+This binding allows the board's device tree file to specify a clock name,
+device phandle and clock alias so that that clock can be associated
+to the device with the alias.
+
+This is required in cases where an external device is clocked by an
+OMAP generated clock and needs to be assocated to it.
+
+NOTE: The node's name should be clock_alias
+
+Required properties
+- clock-name: The clock identifier string. Should be one of the
+ clock ids defined in OMAP common clock data.
+- clock-alias: A string specifying the alias that must be created to the
clock.
+- device: A phandle to the device this clock should be associated to.
+
+e.g. On the OMAP4 Panda board, the USB PHY device is clocked by the
+FREF_CLK3 (auxclk3_ck) from the OMAP. The PHY driver expexts the clock to
+be named main_clk. This binding can be provided like so
+
+clock_alias {
+ clock-name = auxclk3_ck;
+ clock-alias = main_clk;
+ device = hsusb1_phy;
+};
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..2fc48f9 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,9 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
+#include linux/clk.h
+#include linux/string.h
+#include linux/slab.h
#include asm/mach/arch.h
@@ -35,12 +38,76 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+static int __init omap_create_clk_alias(struct device_node *np)
+{
+ int ret = 0;
+ const char *s, *alias;
+ char *clk_id;
+ struct device_node *dev_np;
+ struct platform_device *pdev;
+
+ of_property_read_string(np, clock-name, s);
+ if (!s) {
+ pr_err(%s: couldn't find clock-name property in node %s\n,
+ __func__, np-name);
+ return -ENODEV;
+ }
+
+ clk_id = kstrdup(s, GFP_KERNEL);
+ if (!clk_id)
+ return -ENOMEM;
+
+ dev_np = of_parse_phandle(np, device, 0);
+ if (!dev_np) {
+
Re: [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
Hi Kishon, On 01/10/2013 07:19 AM, kishon wrote: On Friday 28 December 2012 12:05 AM, Aaro Koskinen wrote: Hi, On Thu, Sep 20, 2012 at 05:21:15AM +0200, Benoit Cousson wrote: On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include ARM: dts: * Added reg property and interrupt property for usb_otg_hs. Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data Thanks for the update. I've just pulled the series for 3.7. I wonder what happened to the patch #3 (Add usb_otg and glue data) of this series? Why was it dropped? I cannot see it in 3.7 or 3.8-rc1. I don't remember the context, can you repost it rebased on 3.8-rc2? Did it generate some discussion at that time? Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
Hi, On 12/14/2012 07:44 PM, Paul Walmsley wrote: Hi On Fri, 14 Dec 2012, Tony Lindgren wrote: Paul, what about this patch? Looks like you've acked the other clock patches in this series but not this one? I commented on it briefly here: https://patchwork.kernel.org/patch/1838111/ Maybe Benoît could comment here, but it looks to me (based on a superficial look at the hardware clock tree data) that these clock nodes should exist. In an ideal world, we'd be able to get back to the autogeneration of this clock data. I'm not sure to understand either the rational for that patch. What the point of merging the two nodes? I mean, we can do it, but AFAIR, we have always decided to use atomic node instead of big nodes that handle everything. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
On 12/17/2012 05:13 PM, Roger Quadros wrote: On 12/17/2012 10:13 AM, Benoit Cousson wrote: Hi, On 12/14/2012 07:44 PM, Paul Walmsley wrote: Hi On Fri, 14 Dec 2012, Tony Lindgren wrote: Paul, what about this patch? Looks like you've acked the other clock patches in this series but not this one? I commented on it briefly here: https://patchwork.kernel.org/patch/1838111/ Maybe Benoît could comment here, but it looks to me (based on a superficial look at the hardware clock tree data) that these clock nodes should exist. In an ideal world, we'd be able to get back to the autogeneration of this clock data. I'm not sure to understand either the rational for that patch. What the point of merging the two nodes? I mean, we can do it, but AFAIR, we have always decided to use atomic node instead of big nodes that handle everything. I can see a similar thing done for mcbsp clocks (e.g. /* Merged func_mcbsp1_gfclk into mcbsp1 */), mmc clocks, timer clocks, mcasp clock, and sgx clock. i.e. The clock sel (mux) is combined with clock gate. I don't see why USB host has to be done differently. Hehe, well, in fact USB is using the right approach, the others are the exceptions :-) It was done for legacy reason but should disappear once the modulemode will be be removed from the clock nodes. Were exceptions made for the above clocks in the auto generation code? The problem from driver point of view is that it has to manage an additional clock per port. Not a big deal, but I thought it could be avoided. In theory, the driver should just managed the mux. The modulemode being managed already by hwmod. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP: usb-host: Device tree support for USB Host
Hi Roger,
On 11/15/2012 03:56 PM, Roger Quadros wrote:
Provides a means for the OMAP USB host subsystem to be initialized
from Device tree. This is a first step for device tree migration where
we specify only the board specific stuff. Things like I/O address space
and interrupts are not yet specified in the device tree but can be
done as a next step.
This patch will allow boards to be booted with our without device tree
and have USB host functional.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/arm/omap/usb-host.txt | 60 +
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |2 +
arch/arm/mach-omap2/usb-host.c | 71
4 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/usb-host.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/usb-host.txt
b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
new file mode 100644
index 000..f25cfa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
@@ -0,0 +1,60 @@
+* usb-host - OMAP USB Host Subsystem
+
+The OMAP USB host subsystem consists of the following modules
+1) USBTLL (Tranceiverless interface)
+2) USBHOST (Host Controller module) which includes both EHCI and OHCI
controllers
+
+THe USB Host subsystem can be connected to the external world using 3 PORTs
that could
+be configured in various modes like UTMI+ for external PHY, ULPI
transceiverless link (TLL),
+Serial TLL, High-speed interchip (HSIC), etc.
+
+Required proprties:
+- compatible: Must be ti,usb-host;
+- num_ports: Number of physical ports available
+
+Optional properties:
+- 1 child node for each available port. These child nodes are usually
supplied by the
+ board support device tree as they are specific to how the ports are wired
on the board
+
+ - mode: Integer specifying the mode in which the port is used
+ * OMAP_USBHS_PORT_MODE_UNUSED = 0,
+ * OMAP_EHCI_PORT_MODE_PHY = 1,
+ * OMAP_EHCI_PORT_MODE_TLL = 2,
+ * OMAP_EHCI_PORT_MODE_HSIC = 3,
+ * OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0 = 4,
+ * OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM = 5,
+ * OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0 = 6,
+ * OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM = 7,
+ * OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0 = 8,
+ * OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM = 9,
+ * OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0 = 10,
+ * OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM = 11,
+ * OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0 = 12,
+ * OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM = 13,
+ - clk: Name of the clock that needs to be active when using the port
+ - clkrate: Frequency at which the above clk needs to be run at
+
+
+Example:
+
+/* In the OMAP Core tree */
+usbhost: usb-host {
+ compatible = ti,usb-host;
+ num_ports = 3;
+};
+
+/* In the Board tree */
+usbhost {
+ port@0 {
+ mode = 1;
+ clk = auxclk3_ck;
+ clkrate = 1920;
+ };
+ port@1 {
+ mode = 0;
+ };
+ port@2 {
+ mode = 0;
+ };
+};
+
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..4e53b62 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static void __init omap_generic_init(void)
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ usbhost_init_of();
You should never have to add that kind of hacks in generic board file.
Why do you need that during board init?
In theory, the of_platform_populate will create all the devices, and
during the driver probe you will create the sub nodes.
This way of initializing early from DT node is done only for critical
ARM/OMAP infrastructure stuff like GIC, L2 controller...
It should not be required for USB, that is not even a mandatory IP to
use the OMAP.
Regards,
Benoit
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 7045e4d..b301fcb 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -339,5 +339,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
struct omap2_hsmmc_info;
extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+void __init usbhost_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index bfab301..10a297d 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,6 +22,8 @@
#include linux/platform_device.h
#include linux/slab.h
Re: [PATCH 1/4] ARM: OMAP: usb-host: Device tree support for USB Host
On 11/16/2012 11:55 AM, Roger Quadros wrote:
Hi Benoit,
On 11/16/2012 12:30 PM, Benoit Cousson wrote:
Hi Roger,
On 11/15/2012 03:56 PM, Roger Quadros wrote:
Provides a means for the OMAP USB host subsystem to be initialized
from Device tree. This is a first step for device tree migration where
we specify only the board specific stuff. Things like I/O address space
and interrupts are not yet specified in the device tree but can be
done as a next step.
This patch will allow boards to be booted with our without device tree
and have USB host functional.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/arm/omap/usb-host.txt | 60 +
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |2 +
arch/arm/mach-omap2/usb-host.c | 71
4 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/usb-host.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/usb-host.txt
b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
new file mode 100644
index 000..f25cfa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
@@ -0,0 +1,60 @@
+* usb-host - OMAP USB Host Subsystem
+
+The OMAP USB host subsystem consists of the following modules
+1) USBTLL (Tranceiverless interface)
+2) USBHOST (Host Controller module) which includes both EHCI and OHCI
controllers
+
+THe USB Host subsystem can be connected to the external world using 3
PORTs that could
+be configured in various modes like UTMI+ for external PHY, ULPI
transceiverless link (TLL),
+Serial TLL, High-speed interchip (HSIC), etc.
+
+Required proprties:
+- compatible: Must be ti,usb-host;
+- num_ports: Number of physical ports available
+
+Optional properties:
+- 1 child node for each available port. These child nodes are usually
supplied by the
+ board support device tree as they are specific to how the ports are
wired on the board
+
+ - mode: Integer specifying the mode in which the port is used
+ * OMAP_USBHS_PORT_MODE_UNUSED = 0,
+ * OMAP_EHCI_PORT_MODE_PHY = 1,
+ * OMAP_EHCI_PORT_MODE_TLL = 2,
+ * OMAP_EHCI_PORT_MODE_HSIC = 3,
+ * OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0 = 4,
+ * OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM = 5,
+ * OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0 = 6,
+ * OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM = 7,
+ * OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0 = 8,
+ * OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM = 9,
+ * OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0 = 10,
+ * OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM = 11,
+ * OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0 = 12,
+ * OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM = 13,
+ - clk: Name of the clock that needs to be active when using the port
+ - clkrate: Frequency at which the above clk needs to be run at
+
+
+Example:
+
+/* In the OMAP Core tree */
+usbhost: usb-host {
+ compatible = ti,usb-host;
+ num_ports = 3;
+};
+
+/* In the Board tree */
+usbhost {
+ port@0 {
+ mode = 1;
+ clk = auxclk3_ck;
+ clkrate = 1920;
+ };
+ port@1 {
+ mode = 0;
+ };
+ port@2 {
+ mode = 0;
+ };
+};
+
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..4e53b62 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static void __init omap_generic_init(void)
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ usbhost_init_of();
You should never have to add that kind of hacks in generic board file.
Why do you need that during board init?
In theory, the of_platform_populate will create all the devices, and
during the driver probe you will create the sub nodes.
OK. I was thinking of this as a temporary fix till the USB host drivers
support OF nodes natively. Maybe I should work on fixing up the host
drivers instead.
Well, yeah, that's clearly better.
But I'm not sure how the PM runtime calls map to omap_device/hwmod
framework when device tree boot is used. I can see that the device tree
node can specify ti,hwmods = parameter. Just can't seem to figure out
how all this adds up :P
It is done auto-magically in the omap_device code. As soon as you add
the ti,hwmods: attribute, an omap_device will be created instead of a
regular platform_device. A custom PM domain is added to handle the
pm_runtime callback for OMAP IPs. And every omap_device belongs to that
PM domain.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: musb: dsps: dt binding - add resources, example
Hi Felipe, On 11/06/2012 07:22 PM, Felipe Balbi wrote: Hi, On Tue, Nov 06, 2012 at 05:58:57PM +0100, Benoit Cousson wrote: On 11/06/2012 05:44 PM, Felipe Balbi wrote: Hi, On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote: OMAP2+ family of devices are now obtaining resources via DT, earlier it was obtained from hwmod. Update binding document accrodingly, while at it add example. Signed-off-by: Afzal Mohammed af...@ti.com this looks fine to me: Reviewed-by: Felipe Balbi ba...@ti.com Benoit, do you take Documentation patches too ? Well, ideally it should go with the driver change. But if this is a simple change related to generic attribute I can take it. ok, cool. Please take this via your tree. Done. I've just applied it in my for_3.8/dts_part2 branch. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: musb: dsps: dt binding - add resources, example
On 11/06/2012 05:44 PM, Felipe Balbi wrote:
Hi,
On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote:
OMAP2+ family of devices are now obtaining resources via DT, earlier
it was obtained from hwmod. Update binding document accrodingly, while
at it add example.
Signed-off-by: Afzal Mohammed af...@ti.com
this looks fine to me:
Reviewed-by: Felipe Balbi ba...@ti.com
Benoit, do you take Documentation patches too ?
Well, ideally it should go with the driver change. But if this is a
simple change related to generic attribute I can take it.
Regards,
Benoit
---
v2: node name changed to usb
.../devicetree/bindings/usb/am33xx-usb.txt | 21
+
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index a922505..ea840f7 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -1,5 +1,7 @@
AM33XX MUSB GLUE
- compatible : Should be ti,musb-am33xx
+ - reg : offset and length of register sets, first usbss, then for musb
instances
+ - interrupts : usbss, musb instance interrupts in order
- ti,hwmods : must be usb_otg_hs
- multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
@@ -12,3 +14,22 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+Example:
+
+usb@4740 {
+compatible = ti,musb-am33xx;
+reg = 0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800; /* musb instance 1 */
+interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+multipoint = 1;
+num-eps = 16;
+ram-bits = 12;
+port0-mode = 3;
+port1-mode = 3;
+power = 250;
+ti,hwmods = usb_otg_hs;
+};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
Used of_platform_populate() to populate dwc3 core platform_device
from device tree data. Since now the allocation of unique device id is
handled by of_*, removed the call to dwc3_get_device_id.
Just for my understanding: How are these devices organized exactly?
Do we have : omap_wrapper - dwc3-omap - dwc3-core ?
The DT binding is mentioning some wrapper, but I'm not sure where it
should be located.
Maybe you should add more documentation on that. Or maybe you do have a
other series to add that part?
Regards,
Benoit
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 50
+-
1 file changed, 10 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index d51c69c..4aaeec4 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -47,6 +47,7 @@
#include linux/ioport.h
#include linux/io.h
#include linux/of.h
+#include linux/of_platform.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
@@ -133,7 +134,6 @@ struct dwc3_omap {
/* device lock */
spinlock_t lock;
- struct platform_device *dwc3;
struct platform_device *usb2_phy;
struct platform_device *usb3_phy;
struct device *dev;
@@ -276,12 +276,10 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
struct dwc3_omap_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
- struct platform_device *dwc3;
struct dwc3_omap*omap;
struct resource *res;
struct device *dev = pdev-dev;
- int devid;
int size;
int ret = -ENOMEM;
int irq;
@@ -324,34 +322,19 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
return ret;
}
- devid = dwc3_get_device_id();
- if (devid 0)
- return -ENODEV;
-
- dwc3 = platform_device_alloc(dwc3, devid);
- if (!dwc3) {
- dev_err(dev, couldn't allocate dwc3 device\n);
- goto err1;
- }
-
context = devm_kzalloc(dev, resource_size(res), GFP_KERNEL);
if (!context) {
dev_err(dev, couldn't allocate dwc3 context memory\n);
- goto err2;
+ return -ENOMEM;
}
spin_lock_init(omap-lock);
- dma_set_coherent_mask(dwc3-dev, dev-coherent_dma_mask);
- dwc3-dev.parent = dev;
- dwc3-dev.dma_mask = dev-dma_mask;
- dwc3-dev.dma_parms = dev-dma_parms;
omap-resource_size = resource_size(res);
omap-context = context;
omap-dev = dev;
omap-irq = irq;
omap-base = base;
- omap-dwc3 = dwc3;
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
@@ -396,7 +379,7 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
if (ret) {
dev_err(dev, failed to request IRQ #%d -- %d\n,
omap-irq, ret);
- goto err2;
+ return ret;
}
/* enable all IRQs */
@@ -415,28 +398,16 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_SET_1, reg);
- ret = platform_device_add_resources(dwc3, pdev-resource,
- pdev-num_resources);
- if (ret) {
- dev_err(dev, couldn't add resources to dwc3 device\n);
- goto err2;
- }
-
- ret = platform_device_add(dwc3);
- if (ret) {
- dev_err(dev, failed to register dwc3 device\n);
- goto err2;
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(pdev-dev,
+ failed to add create dwc3 core\n);
+ return ret;
+ }
}
return 0;
-
-err2:
- platform_device_put(dwc3);
-
-err1:
- dwc3_put_device_id(devid);
-
- return ret;
}
static int __devexit dwc3_omap_remove(struct platform_device *pdev)
@@ -446,7 +417,6 @@ static int __devexit dwc3_omap_remove(struct
platform_device *pdev)
platform_device_unregister(omap-usb2_phy);
platform_device_unregister(omap-usb3_phy);
- dwc3_put_device_id(omap-dwc3-id);
device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core);
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
Hi Kishon, On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include ARM: dts: * Added reg property and interrupt property for usb_otg_hs. Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data Thanks for the update. I've just pulled the series for 3.7. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: omap: Add omap-usb2 dt data
Hi Kishon,
On 09/11/2012 08:12 AM, Kishon Vijay Abraham I wrote:
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.
Could you add more details about the omap-usb2?
You must update the Documentation binding with that compatible name.
Is it already part of the driver serie? The MUSB driver is referring to
ti,musb-omap2430 only.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Applies on
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 8a780b2..bdc21f1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -302,6 +302,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
There is no ocp2scp_usb_phy in the current omap4.dtsi?
What base did you used?
You have to use lo/devel-dt branch as a base. All the latest DTS patches
an in there for 3.7.
Regards,
Benoit
+ usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x4;
+ };
};
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
On 09/11/2012 11:09 AM, Kishon Vijay Abraham I wrote:
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..3c19120 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,12 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ /* XXX: Remove this once control module driver is in place */
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi Felipe,
On 09/10/2012 05:58 PM, Felipe Balbi wrote:
Hi,
On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [120906 10:23]:
Hi,
On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
Hi,
On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+{
+.pa_start = 0x4a00233c,
+.pa_end = 0x4a00233f,
+.flags = ADDR_TYPE_RT
+},
I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.
Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.
this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.
Tony, can I get your Acked-by to this patch so I can take it together
with the rest of the series ? Thanks
ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
to merge it into your tree once I apply.
It would be best if this got acked by Benoit and Paul as they may
have some other patches queued up. I'll ack if they ack ;)
Benoit, care to ack this patch ???
Gosh, that's hard to ack something like that :-)
But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.
Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.
Then you sign the patch with your blood and that should be fine for me :-).
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
