Re: Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.
2012/7/13 VIKAS SAJJAN C vikas.saj...@samsung.com: I tested same USB 2.0 device on a linux machine running 3.2.19 kernel connecting through same VIA SS hub. it works fine. now i wonder where is the issue in my 3.4.0 kernel. is it in my exynos driver or usb core... I built the 3.2.19 kernel and 3.4.0 kernel on x86. And my VIA hub works fine. I can't duplicate your issue. Maybe you can get a new one or upgrade the FW. According to your information, it seems like you tested it on embedded platform.I am not sure my environment is the same as your or what works fine on x86 definitely works fine on embedded system. I will try it under other host controller. Best Regards, Elric --- Original Message --- Sender : Elric Fuelric...@gmail.com Date : Jul 13, 2012 18:59 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. 2012/7/13 Andiry Xu andiry...@amd.com: On 07/13/2012 04:57 PM, VIKAS SAJJAN C wrote: Hi Andiry, 1. xHCI root hub --- SS hub --- some other USB 2.0 devices - I tired with 2 more usb 2.0 devices , same error comes. 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device -- i connected xHCI root hub --HS hub-- the same 2.0 device , it works fine. I dont have another SS hub to check with. SO that sounds like a hub issue. I think it seems like the hub is broken. please find the attachement fot the log. It's a VIA USB3.0 hub. I've not used it before but I heard it has several issues. So the easiest solution is to use another SS hub which passes USB-IF certification. Umm, Until now no one pass the USB-IF due to the Forum isn't ready for usb 3.0 hub. Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 17:11 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 03:50 PM, VIKAS SAJJAN C wrote: Hi Andiry, Thanks for the reply. If I connect the USB 2.0 Device directly to the USB 3.0 Port (without the SS Hub ), it works fine. It even works fine if i connect the same USB 2.0 Device through a SS Hub connected to USB 2.0 port (EHCI root hub). the Problem comes if i connect the same USB 2.0 Device through a SS Hub connected to USB 3.0 port (XHCI root hub). When a SS hub is connected to EHCI, it just works like a HS hub. No address device command is issued. Can you post the output of lsusb - and lspci -vvnn? And what occurs with the following two scnearios: 1. xHCI root hub --- SS hub --- some other USB 2.0 devices 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 16:29 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote: Hi , I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super Speed HUB , i get following error. usb 3-1.1: Device not responding to set address. usb 3-1.1: device not accepting address 3, error -71 any inputs will be of great help. Thanks and Regards Vikas Sajjan ¢éì¹» ®Þ~º¶ ¬–+-±éݶ ¥Šw®žË›±Êâmébžìn±¸§¶ ›¡Ü¨}©ž²Æ zÚj:+v‰¨¾ «‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢ f The address command is rejected by the device. What happens if you plug the device to EHCI controller or to xHCI root hub (without the SS hub)? Thanks, Andiry -- 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 -- 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
[PATCH v2 01/11] usb: musb: add musb-id to identify core instance
Added 'id' field within 'struct musb' which can be used to determine
the current instance of musb controller.
Also defined musb_ida in musb_core.c to manage the core ids.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Changes fron v1:
- Defined musb_ida to manage core ids based on Felipe's comment.
drivers/usb/musb/am35x.c | 42 --
drivers/usb/musb/blackfin.c | 26 --
drivers/usb/musb/da8xx.c | 34 --
drivers/usb/musb/davinci.c | 34 --
drivers/usb/musb/musb_core.c | 31 +++
drivers/usb/musb/musb_core.h |4
drivers/usb/musb/musb_dsps.c | 25 ++---
drivers/usb/musb/omap2430.c | 26 --
drivers/usb/musb/tusb6010.c | 26 --
drivers/usb/musb/ux500.c | 33 +++--
10 files changed, 212 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 7a95ab8..01203eb 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -468,6 +468,7 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -475,38 +476,47 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- musb = platform_device_alloc(musb-hdrc, -1);
+ /* get the musb id */
+ musbid = musb_get_id(pdev-dev, GFP_KERNEL);
+ if (musbid 0) {
+ dev_err(pdev-dev, failed to allocate musb id\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ musb = platform_device_alloc(musb-hdrc, musbid);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err2;
}
phy_clk = clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
- goto err2;
+ goto err3;
}
clk = clk_get(pdev-dev, ick);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
- goto err3;
+ goto err4;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(pdev-dev, failed to enable PHY clock\n);
- goto err4;
+ goto err5;
}
ret = clk_enable(clk);
if (ret) {
dev_err(pdev-dev, failed to enable clock\n);
- goto err5;
+ goto err6;
}
+ musb-id= musbid;
musb-dev.parent= pdev-dev;
musb-dev.dma_mask = am35x_dmamask;
musb-dev.coherent_dma_mask = am35x_dmamask;
@@ -524,38 +534,41 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
- goto err6;
+ goto err7;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(pdev-dev, failed to add platform_data\n);
- goto err6;
+ goto err7;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
- goto err6;
+ goto err7;
}
return 0;
-err6:
+err7:
clk_disable(clk);
-err5:
+err6:
clk_disable(phy_clk);
-err4:
+err5:
clk_put(clk);
-err3:
+err4:
clk_put(phy_clk);
-err2:
+err3:
platform_device_put(musb);
+err2:
+ musb_put_id(pdev-dev, musbid);
+
err1:
kfree(glue);
@@ -567,6 +580,7 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
+ musb_put_id(pdev-dev, glue-musb-id);
platform_device_del(glue-musb);
platform_device_put(glue-musb);
clk_disable(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 428e6aa..c848b82 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -471,6 +471,7 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -478,12 +479,21 @@
[PATCH v2 00/11] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg fo writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 48 .../devicetree/bindings/usb/twl-usb.txt| 41 +++ arch/arm/boot/dts/omap3-beagle.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3.dtsi |8 + arch/arm/boot/dts/omap4-panda.dts | 10 + arch/arm/boot/dts/omap4-sdp.dts| 10 + arch/arm/boot/dts/omap4.dtsi | 13 + arch/arm/boot/dts/twl4030.dtsi | 21 ++ arch/arm/boot/dts/twl6030.dtsi |6 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 107 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/Kconfig| 10 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/omap-usb2.c| 271 drivers/usb/otg/twl4030-usb.c | 26 ++- drivers/usb/otg/twl6030-usb.c | 153 +++ include/linux/usb/omap_usb.h | 45 include/linux/usb/phy_companion.h | 34 +++ 24 files changed, 706 insertions(+), 273 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/otg/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.5.4 -- 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
[PATCH v2 06/11] arm/dts: Add twl6030-usb data
Add twl6030-usb data node in twl6030 device tree file
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts |4
arch/arm/boot/dts/omap4-sdp.dts |4
arch/arm/boot/dts/twl6030.dtsi|6 ++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..7052422 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -89,3 +89,7 @@
ti,non-removable;
bus-width = 4;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..6326d7c 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,3 +158,7 @@
bus-width = 4;
ti,non-removable;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..5efd6d3 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -83,4 +83,10 @@
clk32kg: regulator@12 {
compatible = ti,twl6030-clk32kg;
};
+
+ twlusb: twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+ };
};
--
1.7.5.4
--
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
[PATCH v2 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module
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
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba24d15..c50d828 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5922,6 +5922,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.5.4
--
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
[PATCH v2 10/11] arm/dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi |8
6 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
mmc3 {
status = disable;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..f2694c9 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap3-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 7052422..dd19370 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -93,3 +93,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 6326d7c..0fc10d4 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -162,3 +162,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4d2dcc1..a3ee0f9 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
0x4a002300 0x1;
};
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
--
1.7.5.4
--
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
[PATCH v2 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 52 ---
drivers/usb/musb/omap2430.h |9 +++
drivers/usb/otg/twl6030-usb.c | 114 +
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..addbebf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue-control_otghs)
+ writel(val, glue-control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
- usb_phy_shutdown(musb-xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -366,6 +391,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue =
[PATCH v2 08/11] arm/dts: Add twl4030-usb data
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..761a5a5 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
+ vusb1v5: regulator-vusb1v5 {
+ compatible = ti,twl4030-vusb1v5;
+ };
+
+ vusb1v8: regulator-vusb1v8 {
+ compatible = ti,twl4030-vusb1v8;
+ };
+
+ vusb3v1: regulator-vusb3v1 {
+ compatible = ti,twl4030-vusb3v1;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+ };
};
--
1.7.5.4
--
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
EHCI: Centralize controller initialization
Hi Alan
kisskb is showing up a warning in drivers/usb/host/ehci-orion.c
which i think is from a change you made:
drivers/usb/host/ehci-orion.c:109:2: warning: passing argument 1 of
'ehci_setup' from incompatible pointer type [enabled by default]
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 82de107..3e41123 100644 (file)
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -106,21 +106,10 @@ static int ehci_orion_setup(struct usb_hcd *hcd)
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
int retval;
- hcd-has_tt = 1;
-
- retval = ehci_halt(ehci);
- if (retval)
- return retval;
-
- /*
-* data structure init
-*/
- retval = ehci_init(hcd);
+ retval = ehci_setup(ehci);
if (retval)
return retval;
ehci_setup() is being passed a struct ehci_hcd *, but:
811 static int ehci_setup(struct usb_hcd *hcd)
812 {
813 struct ehci_hcd *ehci = hcd_to_ehci(hcd);
814 int retval;
it seems to expect a struct usb_hcd *
Andrew
--
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
[PATCH 1/1] usb: s3c-hsotg: Add header file protection macros in s3c-hsotg.h
Adds header file protection macros.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
include/linux/platform_data/s3c-hsotg.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/platform_data/s3c-hsotg.h
b/include/linux/platform_data/s3c-hsotg.h
index 97ec12c..ff5892d 100644
--- a/include/linux/platform_data/s3c-hsotg.h
+++ b/include/linux/platform_data/s3c-hsotg.h
@@ -12,6 +12,9 @@
* published by the Free Software Foundation.
*/
+#ifndef __LINUX_USB_S3C_HSOTG_H
+#define __LINUX_USB_S3C_HSOTG_H __FILE__
+
enum s3c_hsotg_dmamode {
S3C_HSOTG_DMA_NONE, /* do not use DMA at-all */
S3C_HSOTG_DMA_ONLY, /* always use DMA */
@@ -33,3 +36,5 @@ struct s3c_hsotg_plat {
};
extern void s3c_hsotg_set_platdata(struct s3c_hsotg_plat *pd);
+
+#endif /* __LINUX_USB_S3C_HSOTG_H */
--
1.7.4.1
--
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
[PATCH v2 09/11] usb: musb: dsps: remove explicit NOP device creation
As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 18a16dd..4c59809 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -425,8 +425,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb-mregs += wrp-musb_core_offset; - /* Register NOP driver */ - usb_nop_xceiv_register(musb-id); + /* Get the NOP PHY */ musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 1.7.0.4 -- 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
[PATCH v2 06/11] arm/dts: am33xx: Add dt data for usbss
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..b572803 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ usb_otg_hs: usb_otg_hs@4740 {
+ compatible = ti,musb-am33xx;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ port0_mode = 3;
+ port1_mode = 1;
+ power = 250;
+ };
};
};
--
1.7.0.4
--
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
[PATCH v2 08/11] arm/dts: am33xx: add dt data for usb nop phy
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b572803..3bd9911 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = i2c3;
};
+ usb0_phy: phy@1 {
+ compatible = ti,nop-xceiv-usb;
+ };
+
+ usb1_phy: phy@2 {
+ compatible = ti,nop-xceiv-usb;
+ };
+
usb_otg_hs: usb_otg_hs@4740 {
compatible = ti,musb-am33xx;
ti,hwmods = usb_otg_hs;
--
1.7.0.4
--
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
[PATCH v2 10/11] usb: musb: dsps: get the PHY using phandle api
AM33xx has two PHY of same type used by each musb controller so use phandle of phy nodes to get the phy pointer. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- .../devicetree/bindings/usb/am33xx-usb.txt |2 ++ drivers/usb/musb/musb_dsps.c |4 +++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index a314720..4ed0091 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -12,6 +12,8 @@ AM33XX MUSB GLUE represents PERIPHERAL. - power : Should be 250. This signifies the controller can supply upto 500mA when operating in host mode. + - usb0-phy : phandle for usb0 NOP PHY + - usb1-phy : phandle for usb1 NOP PHY NOP USB PHY - compatible : Should be ti,nop-xceiv-usb diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 4c59809..e2b0729 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -419,6 +419,7 @@ static int dsps_musb_init(struct musb *musb) struct dsps_glue *glue = platform_get_drvdata(pdev); const struct dsps_musb_wrapper *wrp = glue-wrp; void __iomem *reg_base = musb-ctrl_base; + char name[10]; u32 rev, val; int status; @@ -426,7 +427,8 @@ static int dsps_musb_init(struct musb *musb) musb-mregs += wrp-musb_core_offset; /* Get the NOP PHY */ - musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + sprintf(name, usb%d-phy, musb-id); + musb-xceiv = devm_usb_get_phy_by_phandle(pdev-dev, name); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 1.7.0.4 -- 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
[PATCH v2 01/11] usb: musb: add musb-id to identify core instance
Added 'id' field within 'struct musb' which can be used to determine
the current instance of musb controller.
Also defined musb_ida in musb_core.c to manage the core ids.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/am35x.c | 42 --
drivers/usb/musb/blackfin.c | 26 --
drivers/usb/musb/da8xx.c | 34 --
drivers/usb/musb/davinci.c | 34 --
drivers/usb/musb/musb_core.c | 31 +++
drivers/usb/musb/musb_core.h |4
drivers/usb/musb/musb_dsps.c | 25 ++---
drivers/usb/musb/omap2430.c | 26 --
drivers/usb/musb/tusb6010.c | 26 --
drivers/usb/musb/ux500.c | 33 +++--
10 files changed, 212 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 7a95ab8..01203eb 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -468,6 +468,7 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -475,38 +476,47 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- musb = platform_device_alloc(musb-hdrc, -1);
+ /* get the musb id */
+ musbid = musb_get_id(pdev-dev, GFP_KERNEL);
+ if (musbid 0) {
+ dev_err(pdev-dev, failed to allocate musb id\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ musb = platform_device_alloc(musb-hdrc, musbid);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err2;
}
phy_clk = clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
- goto err2;
+ goto err3;
}
clk = clk_get(pdev-dev, ick);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
- goto err3;
+ goto err4;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(pdev-dev, failed to enable PHY clock\n);
- goto err4;
+ goto err5;
}
ret = clk_enable(clk);
if (ret) {
dev_err(pdev-dev, failed to enable clock\n);
- goto err5;
+ goto err6;
}
+ musb-id= musbid;
musb-dev.parent= pdev-dev;
musb-dev.dma_mask = am35x_dmamask;
musb-dev.coherent_dma_mask = am35x_dmamask;
@@ -524,38 +534,41 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
- goto err6;
+ goto err7;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(pdev-dev, failed to add platform_data\n);
- goto err6;
+ goto err7;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
- goto err6;
+ goto err7;
}
return 0;
-err6:
+err7:
clk_disable(clk);
-err5:
+err6:
clk_disable(phy_clk);
-err4:
+err5:
clk_put(clk);
-err3:
+err4:
clk_put(phy_clk);
-err2:
+err3:
platform_device_put(musb);
+err2:
+ musb_put_id(pdev-dev, musbid);
+
err1:
kfree(glue);
@@ -567,6 +580,7 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
+ musb_put_id(pdev-dev, glue-musb-id);
platform_device_del(glue-musb);
platform_device_put(glue-musb);
clk_disable(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 428e6aa..c848b82 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -471,6 +471,7 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -478,12 +479,21 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
goto err0;
[PATCH v2 03/11] usb: musb: am335x: add support for dual instance
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_dsps.c | 93 +
1 files changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2174699..a2c8a06 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
+ /* number of musb instances */
+ u8 instances;
};
/**
@@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
*/
struct dsps_glue {
struct device *dev;
- struct platform_device *musb; /* child musb pdev */
+ struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
- struct timer_list timer;/* otg_workaround timer */
- u32 __iomem *usb_ctrl;
+ struct timer_list timer[2]; /* otg_workaround timer */
+ unsigned long last_timer[2];/* last timer data for each instance */
+ u32 __iomem *usb_ctrl[2];
u8 usbss_rev;
};
/**
* musb_dsps_phy_control - phy on/off
* @glue: struct dsps_glue *
+ * @id: musb instance
* @on: flag for phy to be switched on or off
*
* This is to enable the PHY using usb_ctrl register in system control
@@ -130,11 +134,11 @@ struct dsps_glue {
* XXX: This function will be removed once we have a seperate driver for
* control module
*/
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
{
u32 usbphycfg;
- usbphycfg = __raw_readl(glue-usb_ctrl);
+ usbphycfg = __raw_readl(glue-usb_ctrl[id]);
if (on) {
if (glue-usbss_rev == MUSB_USBSS_REV_816X) {
@@ -157,7 +161,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
glue-usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
- __raw_writel(usbphycfg, glue-usb_ctrl);
+ __raw_writel(usbphycfg, glue-usb_ctrl[id]);
}
/**
* dsps_musb_enable - enable interrupts
@@ -247,7 +251,7 @@ static void otg_timer(unsigned long _musb)
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl MUSB_DEVCTL_BDEVICE)
- mod_timer(glue-timer,
+ mod_timer(glue-timer[musb-id],
jiffies + wrp-poll_seconds * HZ);
else
musb-xceiv-state = OTG_STATE_A_IDLE;
@@ -263,7 +267,6 @@ static void dsps_musb_try_idle(struct musb *musb, unsigned
long timeout)
struct device *dev = musb-controller;
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- static unsigned long last_timer;
if (!is_otg_enabled(musb))
return;
@@ -276,22 +279,23 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
musb-xceiv-state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb-controller, %s active, deleting timer\n,
otg_state_string(musb-xceiv-state));
- del_timer(glue-timer);
- last_timer = jiffies;
+ del_timer(glue-timer[musb-id]);
+ glue-last_timer[musb-id] = jiffies;
return;
}
- if (time_after(last_timer, timeout) timer_pending(glue-timer)) {
+ if (time_after(glue-last_timer[musb-id], timeout)
+ timer_pending(glue-timer[musb-id])) {
dev_dbg(musb-controller,
Longer idle timer already pending, ignoring...\n);
return;
}
- last_timer = timeout;
+ glue-last_timer[musb-id] = timeout;
dev_dbg(musb-controller, %s inactive, starting idle timer for %u
ms\n,
otg_state_string(musb-xceiv-state),
jiffies_to_msecs(timeout - jiffies));
- mod_timer(glue-timer, timeout);
+ mod_timer(glue-timer[musb-id], timeout);
}
static irqreturn_t dsps_interrupt(int irq, void *hci)
@@ -360,7 +364,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
*/
musb-int_usb = ~MUSB_INTR_VBUSERROR;
musb-xceiv-state = OTG_STATE_A_WAIT_VFALL;
- mod_timer(glue-timer,
+
[PATCH v2 04/11] usb: otg: nop: add support for multiple tranceiver
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 20
include/linux/usb/otg.h |9 +
9 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -704,7 +704,7 @@ static void __init omap3_evm_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(0);
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..eb6220f 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -364,7 +364,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -ENODEV;
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..03d081c 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -415,7 +415,7 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb-config-gpio_vrsel);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..3ce4a92 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -425,7 +425,7 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto fail;
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..d5156b3 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -385,7 +385,7 @@ static int davinci_musb_init(struct musb *musb)
void __iomem*tibase = musb-ctrl_base;
u32 revision;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto unregister;
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb-xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return -ENODEV;
}
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index a2c8a06..9fcacff 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,8 +420,8 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb-mregs += wrp-musb_core_offset;
- /* NOP driver needs change if supporting dual instance */
[PATCH v2 07/11] usb: otg: nop: add dt support
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 12
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..a314720 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be ti,nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 2e5e889..0bca4d1 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -152,12 +153,23 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = ti,nop-xceiv-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#else
+#define nop_xceiv_id_table NULL
+#endif
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
--
1.7.0.4
--
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
[PATCH v2 05/11] usb: musb: dsps: add dt support
Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt | 14 +
drivers/usb/musb/musb_dsps.c | 62 +---
2 files changed, 67 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be ti,musb-am33xx
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - port0_mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - port1_mode : Should be 1 to represent HOST. 3 signifies OTG and 2
+ represents PERIPHERAL.
+ - power : Should be 250. This signifies the controller can supply upto
+ 500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9fcacff..18a16dd 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
#include linux/init.h
#include linux/io.h
+#include linux/of.h
#include linux/err.h
#include linux/platform_device.h
#include linux/dma-mapping.h
@@ -45,6 +46,10 @@
#include musb_core.h
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
/**
* avoid using musb_readx()/musb_writex() as glue layer should not be
* dependent on musb core layer symbols.
@@ -496,6 +501,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue
*glue, u8 id)
struct device *dev = glue-dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data *pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct platform_device *musb;
struct resource *res;
struct resource resources[2];
@@ -562,14 +569,40 @@ static int __devinit dsps_create_musb_pdev(struct
dsps_glue *glue, u8 id)
glue-musb[id] = musb;
- pdata-platform_ops = dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, failed to add resources\n);
goto err2;
}
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err2;
+ }
+
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ sprintf(res_name, port%d_mode, id);
+ of_property_read_u32(np, res_name, (u32 *)pdata-mode);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-config = config;
+ }
+
+ pdata-platform_ops = dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, failed to add platform_data\n);
@@ -601,14 +634,22 @@ static void __devexit dsps_delete_musb_pdev(struct
dsps_glue *glue, u8 id)
static int __devinit dsps_probe(struct platform_device *pdev)
{
- const struct platform_device_id *id = platform_get_device_id(pdev);
- const struct dsps_musb_wrapper *wrp =
- (struct dsps_musb_wrapper *)id-driver_data;
+ struct device_node *np = pdev-dev.of_node;
+ const struct of_device_id *match;
+ const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
u32 __iomem *usbss;
int ret, i;
+ match = of_match_node(musb_dsps_of_match, np);
+ if (!match) {
+ dev_err(pdev-dev, fail to get matching of_match struct\n);
+ ret = -EINVAL;
+ goto err0;
+ }
+
[PATCH v2 02/11] usb: musb: kill global and static for multi instance
Moved global variable musb_debugfs_root and static variable
old_state to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable orig_dma_mask and filled the
dev-dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_core.c| 16 +++-
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c | 14 --
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3e09984..a5db4dd 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1802,10 +1802,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb-xceiv-state != old_state) {
- old_state = musb-xceiv-state;
+ if (musb-xceiv-state != musb-xceiv_old_state) {
+ musb-xceiv_old_state = musb-xceiv-state;
sysfs_notify(musb-controller-kobj, NULL, mode);
}
}
@@ -2115,11 +2114,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -2138,10 +2132,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev-dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status 0)
iounmap(base);
@@ -2166,7 +2156,7 @@ static int __devexit musb_remove(struct platform_device
*pdev)
iounmap(ctrl_base);
device_init_wakeup(pdev-dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev-dev.dma_mask = orig_dma_mask;
+ pdev-dev.dma_mask = (dev-dev.parent)-dma_mask;
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 69ed141..6b6cee9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -452,6 +452,10 @@ struct musb {
#endif
/* id for multiple musb instances */
u8 id;
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..b1e8f21 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s-private;
@@ -240,20 +238,24 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *root;
struct dentry *file;
int ret;
+ charname[10];
- root = debugfs_create_dir(musb, NULL);
+ sprintf(name, musb%d, musb-id);
+ root = debugfs_create_dir(name, NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
}
- file = debugfs_create_file(regdump, S_IRUGO, root, musb,
+ sprintf(name, regdump%d, musb-id);
+ file = debugfs_create_file(name, S_IRUGO, root, musb,
musb_regdump_fops);
if (!file) {
ret = -ENOMEM;
goto err1;
}
+ sprintf(name, testmode%d, musb-id);
file = debugfs_create_file(testmode, S_IRUGO | S_IWUSR,
root, musb, musb_test_mode_fops);
if (!file) {
@@ -261,7 +263,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb-debugfs_root = root;
return 0;
@@ -274,5 +276,5 @@ err0:
void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
{
- debugfs_remove_recursive(musb_debugfs_root);
+ debugfs_remove_recursive(musb-debugfs_root);
}
--
1.7.0.4
--
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/2] drivers: bus: add a new driver for omap-ocp2scp
On Tuesday 17 July 2012, ABRAHAM, KISHON VIJAY wrote: On Mon, Jul 16, 2012 at 7:43 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of creating all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY is connected to ocp2scp. This also includes device tree support for ocp2scp driver and the documentation with device tree binding information is updated. Cc: Felipe Balbi ba...@ti.com Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Arnd Bergmann a...@arndb.de Now that we've found a place for the code to live, do we know which maintainer is going to pick it up? If nobody else volunteers, we can take it through the arm-soc tree. Arnd -- 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] usb: chipidea: fix linking of udc if gadget is build as module
Hi, On Mon, Jul 16, 2012 at 09:57:27PM +0200, Marc Kleine-Budde wrote: Hello, On 07/16/2012 04:20 PM, Felipe Balbi wrote: This is not the real problem. The problem is that USB_CHIPIDEA depends on USB (which is the Host side USB). So if you make host built-in, you can make chipidea built-in regardless of the gadget setting. That's the bug you want to solve. I don't think so. Have a look at the above mentioned undefined symbols: usb_gadget_unmap_request, they are implemented in: $git grep usb_gadget_unmap_request | grep EXPORT drivers/usb/gadget/udc-core.c:EXPORT_SYMBOL_GPL(usb_gadget_unmap_request); of course... that's because chipidea can be built-in while gadget isn't. The bug is exactly allowing chipidea to be built-in with no regards to the gadget side. CONFIG_USB_CHIPIDEA=y CONFIG_USB_GADGET=m there you go. Chipidea is built-in and gadget isn't. That's exactly what my patch fixes. yeah, but you fix it the wrong way. CONFIG_USB_CHIPIDEA should not Okay. Point taken. My patch only fixes the regression which was introduced in 5e0aa49 usb: chipidea: use generic map/unmap routines. Just a minimal patch to go into the current release cycle. depend on USB to start with. If you disable USB Host side, you can't compile chipidea driver. The patch below fixes most of the failures. Now the only problem is when we have both host and gadget enabled, if one of them is built-in, chipidea can be built-in regardless of the other. But that's something from the kbuild language I guess. Hmmm...Same problem as before, but now also for the host side. I've wrapped my head around the problem and I think a found something...I'm not sure how nice the solution is. diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index fd36dc8..e43bf69 100644 --- a/drivers/usb/chipidea/Kconfig +++ b/drivers/usb/chipidea/Kconfig @@ -1,6 +1,7 @@ config USB_CHIPIDEA tristate ChipIdea Highspeed Dual Role Controller - depends on USB + depends on USB_SUPPORT ^^^ not needed as it is included from drivers/usb/Kconfig inside the big ifdef USB_SUPPORT...endif. (At least on 3.5-rc7) true. + depends on USB || USB_GADGET help Say Y here if your system has a dual role high speed USB controller based on ChipIdea silicon IP. Currently, only the @@ -10,20 +11,6 @@ config USB_CHIPIDEA if USB_CHIPIDEA -config USB_CHIPIDEA_UDC - bool ChipIdea device controller - depends on USB_GADGET - select USB_GADGET_DUALSPEED What about the select? indeed :D -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: chipidea: fix and improve dependencies if usb host or gadget support is built as module
Hi, On Mon, Jul 16, 2012 at 10:18:20PM +0200, Marc Kleine-Budde wrote: Since commit 5e0aa49 usb: chipidea: use generic map/unmap routines, the udc part of the chipidea driver needs the generic usb gadget helper functions. If the chipidea driver with udc support is built into the kernel and usb gadget is built a module, the linking of the kernel fails with: drivers/built-in.o: In function `_hardware_dequeue': drivers/usb/chipidea/udc.c:527: undefined reference to `usb_gadget_unmap_request' drivers/usb/chipidea/udc.c:1269: undefined reference to `usb_gadget_unmap_request' drivers/usb/chipidea/udc.c:1821: undefined reference to `usb_del_gadget_udc' drivers/usb/chipidea/udc.c:443: undefined reference to `usb_gadget_map_request' drivers/usb/chipidea/udc.c:1774: undefined reference to `usb_add_gadget_udc' This patch changes the dependencies, so that udc support can only be activated if the linux gadget support (USB_GADGET) is builtin or both chipidea driver and USB_GADGET are modular. Same dependencies for the chipidea host support and the linux host side USB support (USB). While there, fix the indention of chipidea the help text. Cc: Alexander Shishkin alexander.shish...@linux.intel.com Signed-off-by: Marc Kleine-Budde m...@pengutronix.de this looks like it tackles everything. didn't test myself but still: Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: chipidea: fix and improve dependencies if usb host or gadget support is built as module
Hi, On Tue, Jul 17, 2012 at 11:34:52AM +0200, Marc Kleine-Budde wrote: On 07/17/2012 11:15 AM, Felipe Balbi wrote: On Mon, Jul 16, 2012 at 10:18:20PM +0200, Marc Kleine-Budde wrote: Since commit 5e0aa49 usb: chipidea: use generic map/unmap routines, the udc part of the chipidea driver needs the generic usb gadget helper functions. If the chipidea driver with udc support is built into the kernel and usb gadget is built a module, the linking of the kernel fails with: drivers/built-in.o: In function `_hardware_dequeue': drivers/usb/chipidea/udc.c:527: undefined reference to `usb_gadget_unmap_request' drivers/usb/chipidea/udc.c:1269: undefined reference to `usb_gadget_unmap_request' drivers/usb/chipidea/udc.c:1821: undefined reference to `usb_del_gadget_udc' drivers/usb/chipidea/udc.c:443: undefined reference to `usb_gadget_map_request' drivers/usb/chipidea/udc.c:1774: undefined reference to `usb_add_gadget_udc' This patch changes the dependencies, so that udc support can only be activated if the linux gadget support (USB_GADGET) is builtin or both chipidea driver and USB_GADGET are modular. Same dependencies for the chipidea host support and the linux host side USB support (USB). While there, fix the indention of chipidea the help text. Cc: Alexander Shishkin alexander.shish...@linux.intel.com Signed-off-by: Marc Kleine-Budde m...@pengutronix.de this looks like it tackles everything. didn't test myself but still: Reviewed-by: Felipe Balbi ba...@ti.com Thanks. Is this for v3.5 or should I rebase to Greg's usb-tree? That's up to Alex and Greg. My suggestion is that this can wait for v3.6-rc cycle with a backport to stable. Greg and Alex have the final saying. -- balbi signature.asc Description: Digital signature
[PATCH RESEND v4] USB: host: Add Device tree support for ohci-exynos ehci-s5p
Adding Greg KH, and Jingoo Han in the mail thread. Reworked third patch; other two got applied to 'usb-next' branch. Changes from v3: 1) Change the function name from s5p_ehci_setup_gpio() to s5p_setup_vbus_gpio(). 2) Make s5p_setup_vbus_gpio() function to return void instead of int. 3) Return void in case of failures. Vivek Gautam (1): USB: ehci-s5p: Add vbus setup function to the s5p ehci glue layer drivers/usb/host/ehci-s5p.c | 21 + 1 files changed, 21 insertions(+), 0 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
[PATCH RESEND v4] USB: ehci-s5p: Add vbus setup function to the s5p ehci glue layer
This patch retrieves and configures the vbus control gpio via
the device tree. The suspend/resume callbacks will be later
modified for vbus control.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/host/ehci-s5p.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 37d84cf..9d8f1dd 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -15,6 +15,7 @@
#include linux/clk.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/of_gpio.h
#include plat/ehci.h
#include plat/usb-phy.h
@@ -64,6 +65,24 @@ static const struct hc_driver s5p_ehci_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static void s5p_setup_vbus_gpio(struct platform_device *pdev)
+{
+ int err;
+ int gpio;
+
+ if (!pdev-dev.of_node)
+ return;
+
+ gpio = of_get_named_gpio(pdev-dev.of_node,
+ samsung,vbus-gpio, 0);
+ if (!gpio_is_valid(gpio))
+ return;
+
+ err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, ehci_vbus_gpio);
+ if (err)
+ dev_err(pdev-dev, can't request ehci vbus gpio %d, gpio);
+}
+
static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
static int __devinit s5p_ehci_probe(struct platform_device *pdev)
@@ -92,6 +111,8 @@ static int __devinit s5p_ehci_probe(struct platform_device
*pdev)
if (!pdev-dev.coherent_dma_mask)
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ s5p_setup_vbus_gpio(pdev);
+
s5p_ehci = devm_kzalloc(pdev-dev, sizeof(struct s5p_ehci_hcd),
GFP_KERNEL);
if (!s5p_ehci)
--
1.7.0.4
--
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] usb: s3c-hsotg: Add header file protection macros in s3c-hsotg.h
On Tue, Jul 17, 2012 at 02:40:10PM +0530, Sachin Kamat wrote: Adds header file protection macros. you need to comment if you actually ran into an issue. Is there any file which ends up with double inclusion of this header or are you just trying to be safe ? Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- include/linux/platform_data/s3c-hsotg.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/linux/platform_data/s3c-hsotg.h b/include/linux/platform_data/s3c-hsotg.h index 97ec12c..ff5892d 100644 --- a/include/linux/platform_data/s3c-hsotg.h +++ b/include/linux/platform_data/s3c-hsotg.h @@ -12,6 +12,9 @@ * published by the Free Software Foundation. */ +#ifndef __LINUX_USB_S3C_HSOTG_H +#define __LINUX_USB_S3C_HSOTG_H __FILE__ you don't need to define it to __FILE__. #define __LINUX_USB_S3C_HSOTG_H is enough. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] usb: s3c-hsotg: Add header file protection macros in s3c-hsotg.h
On 17/07/2012, Felipe Balbi ba...@ti.com wrote: On Tue, Jul 17, 2012 at 02:40:10PM +0530, Sachin Kamat wrote: Adds header file protection macros. you need to comment if you actually ran into an issue. Is there any file which ends up with double inclusion of this header or are you just trying to be safe ? Yes, it is only for safety to avoid multiple inclusion. I will update the commit message accordingly. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- include/linux/platform_data/s3c-hsotg.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/linux/platform_data/s3c-hsotg.h b/include/linux/platform_data/s3c-hsotg.h index 97ec12c..ff5892d 100644 --- a/include/linux/platform_data/s3c-hsotg.h +++ b/include/linux/platform_data/s3c-hsotg.h @@ -12,6 +12,9 @@ * published by the Free Software Foundation. */ +#ifndef __LINUX_USB_S3C_HSOTG_H +#define __LINUX_USB_S3C_HSOTG_H __FILE__ you don't need to define it to __FILE__. #define __LINUX_USB_S3C_HSOTG_H is enough. Ok. I will re-send with the above suggestions. -- balbi -- With warm regards, Sachin -- 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
[PATCH Resend] usb: s3c-hsotg: Add header file protection macros in s3c-hsotg.h
Adds header file protection macros to avoid multiple inclusion.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
include/linux/platform_data/s3c-hsotg.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/platform_data/s3c-hsotg.h
b/include/linux/platform_data/s3c-hsotg.h
index 97ec12c..8b79e09 100644
--- a/include/linux/platform_data/s3c-hsotg.h
+++ b/include/linux/platform_data/s3c-hsotg.h
@@ -12,6 +12,9 @@
* published by the Free Software Foundation.
*/
+#ifndef __LINUX_USB_S3C_HSOTG_H
+#define __LINUX_USB_S3C_HSOTG_H
+
enum s3c_hsotg_dmamode {
S3C_HSOTG_DMA_NONE, /* do not use DMA at-all */
S3C_HSOTG_DMA_ONLY, /* always use DMA */
@@ -33,3 +36,5 @@ struct s3c_hsotg_plat {
};
extern void s3c_hsotg_set_platdata(struct s3c_hsotg_plat *pd);
+
+#endif /* __LINUX_USB_S3C_HSOTG_H */
--
1.7.4.1
--
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] usb: s3c-hsotg: Add header file protection macros in s3c-hsotg.h
On Tue, Jul 17, 2012 at 04:33:14PM +0530, Sachin Kamat wrote: On 17/07/2012, Felipe Balbi ba...@ti.com wrote: On Tue, Jul 17, 2012 at 02:40:10PM +0530, Sachin Kamat wrote: Adds header file protection macros. you need to comment if you actually ran into an issue. Is there any file which ends up with double inclusion of this header or are you just trying to be safe ? Yes, it is only for safety to avoid multiple inclusion. I will update the commit message accordingly. ok thanks. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 02/11] arm/dts: omap: Add omap-usb2 dt data
Hello.
On 17-07-2012 12:10, Kishon Vijay Abraham I wrote:
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bda5df3..4d2dcc1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@0x4a0ad080 {
There should be no 0x prefix here.
WBR, Sergei
--
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 08/11] arm/dts: am33xx: add dt data for usb nop phy
Hello.
On 17-07-2012 13:13, Ajay Kumar Gupta wrote:
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b572803..3bd9911 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = i2c3;
};
+ usb0_phy: phy@1 {
+ compatible = ti,nop-xceiv-usb;
+ };
+
+ usb1_phy: phy@2 {
+ compatible = ti,nop-xceiv-usb;
+ };
No reg property again, and address postfix in the node name?
WBR, Sergei
--
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 v5 08/13] ARM: imx6q: add config-on-boot gpios
On 13.06.2012 14:34, Richard Zhao wrote:
Sometimes, boards have gpios that don't own by any driver or owner
by a generic driver that don't like hacks. Such gpios is normally
output and need setup once on boot. So I introduce the config-on-boot
gpios.
Signed-off-by: Richard Zhao richard.z...@freescale.com
Cc: Shawn Guo shawn@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
---
.../devicetree/bindings/arm/config-on-boot.txt | 12 +++
arch/arm/boot/dts/imx6q-sabrelite.dts |7
arch/arm/mach-imx/mach-imx6q.c | 35
3 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/config-on-boot.txt
diff --git a/Documentation/devicetree/bindings/arm/config-on-boot.txt
b/Documentation/devicetree/bindings/arm/config-on-boot.txt
new file mode 100644
index 000..f98ed74
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/config-on-boot.txt
@@ -0,0 +1,12 @@
+* Configure on Boot
+
+Node name: config-on-boot
+ It must be in root node. config-on-boot means to describe settings that needs
+ to be set one time on boot but aren't owned by any driver, or the owned
driver
+ is too generic to handle such settings. For example, usb hub uses generic
+ driver in usb core code, a on-board usb may need deassert reset pin.
+
+Optional properties:
+- output-gpios: Output gpio array that needs to set.
+- output-gpio-values: This property is required if output-gpios is set.
+ The value is a array of 0 or 1. Total count eaquals the number of gpios.
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index e0ec929..1dd2261 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -17,6 +17,13 @@
model = Freescale i.MX6 Quad SABRE Lite Board;
compatible = fsl,imx6q-sabrelite, fsl,imx6q;
+ config-on-boot {
+ output-gpios =
+ gpio3 22 0;/* vbus reset */
+ output-gpio-values =
+ 1; /* vbus reset */
+ };
+
memory {
reg = 0x1000 0x4000;
};
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index b47e98b..577cf19 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -19,6 +19,7 @@
#include linux/irqdomain.h
#include linux/of.h
#include linux/of_address.h
+#include linux/of_gpio.h
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/pinctrl/machine.h
@@ -113,6 +114,38 @@ static void __init imx6q_sabrelite_init(void)
imx6q_sabrelite_cko1_setup();
}
+static void __init imx6q_config_on_boot(void)
+{
+ struct device_node *np;
+ struct property *pp;
+ int cnt, len, i;
+ int gpio;
+
+ np = of_find_node_by_path(/config-on-boot);
+ if (!np)
+ return;
+ cnt = of_gpio_named_count(np, output-gpios);
+ pp = of_find_property(np, output-gpio-values, len);
+ if (!pp || cnt != len / sizeof(u32)) {
+ pr_err(Invalid config-on-boot gpios!\n);
+ of_node_put(np);
+ return;
+ }
+ for (i = 0; i cnt; i++) {
+ gpio = of_get_named_gpio(np, output-gpios, i);
+ if (gpio_is_valid(gpio))
+ gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH,
+ config-on-boot);
While trying to use this code: Is there a special reason why all pins
are set to HIGH here? The contents of 'output-gpio-values' seem to be
ignored?
Best regards
Dirk
--
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: EHCI: Centralize controller initialization
On Tue, 17 Jul 2012, Andrew Lunn wrote: Hi Alan kisskb is showing up a warning in drivers/usb/host/ehci-orion.c which i think is from a change you made: drivers/usb/host/ehci-orion.c:109:2: warning: passing argument 1 of 'ehci_setup' from incompatible pointer type [enabled by default] See http://marc.info/?l=linux-usbm=134210393602434w=2 and commit 72119743651054ceddd4fdf0cce161bdb4cc4aac in Greg's usb-next branch. Alan Stern -- 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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On 2012/7/17 21:48, Oliver Neukum wrote: On Tuesday 17 July 2012 21:35:00 Lan Tianyu wrote: On 2012/7/16 22:13, Alan Stern wrote: On Mon, 16 Jul 2012, Lan Tianyu wrote: Currently, power/wakeup sysfs file can't control remote wakeup in the runtime suspend. It only depends on usb_interface-needs_remote_wakeup to determine whether enable remote wakeup or not when runtime suspending. Usr space has no choice. This patch is to enable power/wakeup to control remote wakeup in the runtime suspend. As Oliver pointed out, you need to explain why this is needed. Yeah. Lost some background introduction. I recently try to realize usb port power off mechanism for ports with device. So design, the port with device only can be power off when remote wakeup disable. But I found remote wakeup was entirely control by driver and userspace has no control. needs_remote_wakeup is set to 1 when the device is opened. But the driver will not work if you don't use remote wakeup when it needs it. Under those circumstances you better unbind the driver. hi Oliver: Thanks for reply. Why unbind driver? I am sorry I don't understand it. Can you elaborate it for me? :) When device is suspended, that means driver will not work, right? Disable remote wakeup is to keep device being suspended in some circumstances(system idle) which may be not willing to see device resuming. So that means the device's remote wakeup can not be disabled and usb port can not be powered off. So I try to provide a control of remote wakeup to userspace. When system becomes idle such as blank screen, some usb devices may be able to disable remote wakeup and power off. Yes, this is an unsoved problem. But the approach is no good. Don't disable remote wakeup behind the driver's back. Tell the driver that a reduced level of service is acceptable. How to tell the driver? Regards Oliver -- Best Regards Tianyu Lan linux kernel enabling team -- 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] usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams
On Tue, 17 Jul 2012, Laurent Pinchart wrote:
Most Logitech UVC webcams (both early models that don't advertise UVC
compatibility and newer UVC-advertised devices) require the RESET_RESUME
quirk. Instead of listing each and every model, match the devices based
on the UVC interface information.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/core/quirks.c | 86
+
1 files changed, 24 insertions(+), 61 deletions(-)
Alan, what do you think about this approach ? I'm not sure whether we need to
include the early UVC models that advertise a vendor-specific class in the
list.
The general approach is okay. The details aren't quite right.
Are the 0x08c2 - 0x08c7 products the ones with a vendor-specific class?
@@ -153,31 +116,31 @@ static const struct usb_device_id usb_quirk_list[] = {
/* INTEL VALUE SSD */
{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Logitech UVC Cameras */
+ { .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x046d,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = USB_QUIRK_RESET_RESUME },
+
usb_match_device() doesn't pay attention to the MATCH_INT_INFO flag.
Therefore this entry would end up matching every Logitech device.
In fact, at the time usb_detect_quirks() gets called we haven't yet
read in the device's config descriptors, so matching based on interface
info won't work. It looks like we need a second routine,
usb_detect_interface_quirks(), which would be called at the end of
usb_enumerate_device(), along with a second id table.
Alan Stern
--
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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Tuesday 17 July 2012 22:28:32 Lan Tianyu wrote: On 2012/7/17 21:48, Oliver Neukum wrote: But the driver will not work if you don't use remote wakeup when it needs it. Under those circumstances you better unbind the driver. hi Oliver: Thanks for reply. Why unbind driver? I am sorry I don't understand it. Can you elaborate it for me? :) The drivers don't request remote wakeup for fun or performance. The driver won't work without it. In consequence a device whose interfaces are not associated with drivers has no drivers to request remote wakeup. When device is suspended, that means driver will not work, right? No, they will work, albeit slower. That is the point of the whole exercise. Some devices, perhaps because they perform only output, don't require remote wakeup. The others do. Disable remote wakeup is to keep device being suspended in some circumstances(system idle) which may be not willing to see device resuming. Then the device will not work with a full set of features. There may be devices which may be able to operate with a reduced feature set without remote wakeup, but personally I can't think of examples. So that means the device's remote wakeup can not be disabled and usb port can not be powered off. So I try to provide a control of remote wakeup to userspace. When system becomes idle such as blank screen, some usb devices may be able to disable remote wakeup and power off. Yes, this is an unsoved problem. But the approach is no good. Don't disable remote wakeup behind the driver's back. Tell the driver that a reduced level of service is acceptable. How to tell the driver? That is the big question. In fact, it is not entirely clear whether it makes sense at all. Regards Oliver -- 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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Tuesday 17 July 2012 22:49:26 Lan Tianyu wrote: On 2012/7/17 22:26, Alan Stern wrote: What sort of driver are you talking about? An HID driver? Serial driver? I can find hid, bcm, serial, mouse, screen and some net device drivers does such thing. set needs_remote_wakeup to 1 in open() and to 0 in close(). Some net drivers will set it to 0 when network is stop. You should react this way to stop. Generally those drivers need to deal with input arriving at unpredictable times. If that can happen, you need remote wakeup. But in general, if a driver needs wakeup in order to work properly then it _won't_ work when the port is powered off. So as Oliver says, the user might as well unbind the driver first. You mean userspace app unbind the driver? But some devices maybe work properly when the port power on again and device is resumed. e.g keyboard and mouse. But they do not work while power has been cut. So why not close() before yo would cut power and open() after that? There may be a very small benefit in keeping the fd open in case you have exclusive open, but the justification is slim. You could just as well have an unplug/replug cycle, especially as the kernel usually cannot rule that out anyway. We could implement a generic ioctl() for not caring about input right now. Regards Oliver -- 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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Tue, 17 Jul 2012, Lan Tianyu wrote: Why is that? What happens if you power-off a port where the device has remove wakeup enabled? I will not power off a port where the device has remote wakeup enabled. Only when disabled, the port will power off. What about the case where the device is active (not suspended)? Remote wakeup won't be enabled then. Does that mean you're willing to power-down a device when it is active but not when it is suspended (if remote wakeup is enabled)? That doesn't make sense. But in general, if a driver needs wakeup in order to work properly then it _won't_ work when the port is powered off. So as Oliver says, the user might as well unbind the driver first. You mean userspace app unbind the driver? Yes. But some devices maybe work properly when the port power on again and device is resumed. e.g keyboard and mouse. Userspace can rebind the driver when the port is powered on. Alan Stern -- 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 RESEND 0/3] scsi: fix internal write cache issue on usb hdd.
On Tue, Jul 17, 2012 at 08:19:14AM +0100, James Bottomley wrote: On Mon, 2012-07-16 at 16:48 -0700, Greg KH wrote: On Sat, Jul 07, 2012 at 11:04:45PM -0400, Namjae Jeon wrote: From: Namjae Jeon namjae.j...@samsung.com The numbers of USB HDDs(All USB HDD I checked) does not respond correctly to scsi mode sense command for retrieving the write cache page status. Even though write cache is enabled by default, due to scsi driver assume that cache is not enabled which in turn might lead to loss of data since data still will be in cache. This result that all filesystems is not stable on USB HDD when the device is unplugged abruptly, even though these are having journaling feature. Our first trying is that scsi driver send ATA command (ATA Pass through, #85) to USB HDD after failure from normal routine to know write cache enable. We have known it is dangerous after testing several USB HDD. some of HDD is stalled by this command(A-DATA HDD). So we tried to make the patch James Bottomley's suggestion(usb quirk) on version 2 that add product ID and verdor ID of USB HDD to USB quirk list after checking write cache. All filesystem will be stable on USB HDD registered in quirk list. And it will be updated continuously. Now applied to the usb-next branch. It's been in scsi#misc for ten days with no problems. Lets leave it there rather than create merge and rebase issues. No need for rebasing. It's already in my tree, so we can handle the merge when this hits Linus's tree. thanks, greg k-h -- 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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Tue, Jul 17, 2012 at 10:49:26PM +0800, Lan Tianyu wrote: On 2012/7/17 22:26, Alan Stern wrote: On Tue, 17 Jul 2012, Oliver Neukum wrote: Yeah. Lost some background introduction. I recently try to realize usb port power off mechanism for ports with device. So design, the port with device only can be power off when remote wakeup disable. Why is that? What happens if you power-off a port where the device has remove wakeup enabled? I will not power off a port where the device has remote wakeup enabled. Only when disabled, the port will power off. The reason behind this is because we will lose remote wakeups when the port is powered off. The port power is completely removed and it looks like a physical disconnect to both the host and the device. So we can't power off a port where the device has remote wakeup enabled. Sarah Sharp -- 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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Tue, 17 Jul 2012, Sarah Sharp wrote: On Tue, Jul 17, 2012 at 10:49:26PM +0800, Lan Tianyu wrote: On 2012/7/17 22:26, Alan Stern wrote: On Tue, 17 Jul 2012, Oliver Neukum wrote: Yeah. Lost some background introduction. I recently try to realize usb port power off mechanism for ports with device. So design, the port with device only can be power off when remote wakeup disable. Why is that? What happens if you power-off a port where the device has remove wakeup enabled? I will not power off a port where the device has remote wakeup enabled. Only when disabled, the port will power off. The reason behind this is because we will lose remote wakeups when the port is powered off. The port power is completely removed and it looks like a physical disconnect to both the host and the device. So we can't power off a port where the device has remote wakeup enabled. Wouldn't it be more accurate to say you _don't want_ to power off such ports, even though you _can_? If you're giving control of port power to userspace, then it doesn't matter what _you_ want. What matters is what the _user_ wants. Furthermore, what happens if you power down a port when the attached device is active (not suspended)? Again it will look like a physical disconnect. So again, you don't want to power off such ports -- even though they don't have remote wakeup enabled. I guess this comes down to deciding how much power you want to give the user. Are you saying that the user should be prevented from powering down a port unless: there is no device attached, or the attached device is suspended with wakeup disabled? But the justification seems weak. If powering down a port looks exactly like a disconnect, then you should allow powering down to the same extent that you allow disconnects. Last time I checked, the kernel did not try to prevent users from unplugging their USB devices. :-) Alan Stern -- 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: Problems with ASMedia ASM1042 SuperSpeed USB Host
On Mon, Jul 16, 2012 at 10:56:05AM -0400, Alan Stern wrote: On Mon, 16 Jul 2012, Ingo Rohloff wrote: Hello, I have some problems with an ASM1042 SuperSpeed Host Controller. (IvyBridge + PantherPoint Motherboard). I also read some comments that this particular Host Controller might have some problems, but I could not find any details. Each URB tries to read up to 0x4000 bytes from Endpoint 0x85. The device should send 0x2FFE bytes. My assumption was, that every 12th packet only contains 0x3FE bytes and thus stops the currently active URB. It seems the ASM1042 sometimes does not stop the transfer after receiving a short packet, or at least the URB continues (stopping after 16KByte). QUESTION: Is this a known problem or am I doing something wrong ? See http://marc.info/?l=linux-usbm=134236551409964w=2 Apparently the ASM1042 reports that a transfer completed normally even when it was short (or when it was cancelled). When an URB is canceled, the xHCI driver asks the endpoint ring to be stopped. However, the transfer may be completed before the ring stops, so we can have a canceled transfer where the full buffer really was transferred. I don't see that as a bug, it's just a race condition that drivers need to deal with. xHCI controllers in general do not stop transfers after receiving a short packet. Apparently there's no way to tell them to stop under those circumstances. Yes, this really sounds like it's related to the libusb BULK_CONTINUATION flag issue. Sarah Sharp -- 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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
Alan Stern st...@rowland.harvard.edu writes: Last time I checked, the kernel did not try to prevent users from unplugging their USB devices. :-) That would be a nice feature for usb attached storage devices though :-) Bjørn -- 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
[PATCH net-next] net: qmi_wwan: make dynamic device IDs work
The usbnet API use the device ID table to store a pointer to
a minidriver. Setting a generic pointer for dynamic device
IDs will in most cases make them work as expected. usbnet
will otherwise treat the dynamic IDs as blacklisted. That is
rarely useful.
There is no standard class describing devices supported by
this driver, and most vendors don't even provide enough
information to allow vendor specific wildcard matching. The
result is that most of the supported devices must be
explicitly listed in the device table. Allowing dynamic IDs
to work both simplifies testing and verification of new
devices, and provides a way for end users to use a device
before the ID is added to the driver.
Signed-off-by: Bjørn Mork bj...@mork.no
---
I gave up on the generic solution to this problem. Different
drivers will have different needs, and even the different usbnet
minidrivers are very different. Some do mostly class based
wildcard matching and rarely need an ID table update, while
others, like qmi_wwan, will need frequent updates as new devices
hit the market.
My conclusion was that it was best to add support like this
in the few drivers actually needing it. Each driver will have
to make a policy decision wrt which data they will use for
dynamic devices. It just can't be done wholesale.
drivers/net/usb/qmi_wwan.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index bc0469e..2ea126a 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -609,10 +609,27 @@ static const struct usb_device_id products[] = {
};
MODULE_DEVICE_TABLE(usb, products);
+static int qmi_wwan_probe(struct usb_interface *intf, const struct
usb_device_id *prod)
+{
+ struct usb_device_id *id = (struct usb_device_id *)prod;
+
+ /* Workaround to enable dynamic IDs. This disables usbnet
+* blacklisting functionality. Which, if required, can be
+* reimplemented here by using a magic blacklist value
+* instead of 0 in the static device id table
+*/
+ if (!id-driver_info) {
+ dev_dbg(intf-dev, setting defaults for dynamic device id\n);
+ id-driver_info = (unsigned long)qmi_wwan_shared;
+ }
+
+ return usbnet_probe(intf, id);
+}
+
static struct usb_driver qmi_wwan_driver = {
.name = qmi_wwan,
.id_table = products,
- .probe= usbnet_probe,
+ .probe= qmi_wwan_probe,
.disconnect = usbnet_disconnect,
.suspend = qmi_wwan_suspend,
.resume = qmi_wwan_resume,
--
1.7.10.4
--
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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Tue, Jul 17, 2012 at 03:00:08PM -0400, Alan Stern wrote: On Tue, 17 Jul 2012, Sarah Sharp wrote: On Tue, Jul 17, 2012 at 10:49:26PM +0800, Lan Tianyu wrote: On 2012/7/17 22:26, Alan Stern wrote: On Tue, 17 Jul 2012, Oliver Neukum wrote: Yeah. Lost some background introduction. I recently try to realize usb port power off mechanism for ports with device. So design, the port with device only can be power off when remote wakeup disable. Why is that? What happens if you power-off a port where the device has remove wakeup enabled? I will not power off a port where the device has remote wakeup enabled. Only when disabled, the port will power off. The reason behind this is because we will lose remote wakeups when the port is powered off. The port power is completely removed and it looks like a physical disconnect to both the host and the device. So we can't power off a port where the device has remote wakeup enabled. Wouldn't it be more accurate to say you _don't want_ to power off such ports, even though you _can_? Yes. English fail due to cold symptoms. If you're giving control of port power to userspace, then it doesn't matter what _you_ want. What matters is what the _user_ wants. Furthermore, what happens if you power down a port when the attached device is active (not suspended)? Again it will look like a physical disconnect. So again, you don't want to power off such ports -- even though they don't have remote wakeup enabled. Ok, yes, point taken. I guess this comes down to deciding how much power you want to give the user. Are you saying that the user should be prevented from powering down a port unless: there is no device attached, or the attached device is suspended with wakeup disabled? Ok, here's the safe plan that we could implement in the kernel that should have no visible user impact (aside from power savings): 1. If a USB port is empty and the ACPI _UPC and _PLD indicate that it's an internal USB port that will remain empty, power off the port. 2. If an internal USB port is suspended with remote wakeup disabled, power off the port. Add code to the USB core to ignore the device disconnect in this special case, so the driver thinks the device is still suspended. Issue a reset-resume when the driver wants to resume the device. That policy would be safe, because for 1) we would never see a USB device connection, and thus wouldn't miss the connection when we powered off the port. 2) is safe because we won't miss a remote wakeup while the port is powered off, and the device can't be disconnected by the user because it's an internal USB device. There are a couple places in the USB core where we could add hooks to implement those policies. When a hub is enumerated, we could check the ACPI _UPC and _PLC for the port, and power it off if it's an internal empty port. When the USB device is suspended with remote wakeup off, we could power down the port, and repower it when the driver resumes the device. The grand master plan involves userspace knowing when a user is inactive and using the new sysfs files to power off empty external ports. I suppose we would need some sysfs files to expose the ACPI state to userspace in that case. But the justification seems weak. If powering down a port looks exactly like a disconnect, then you should allow powering down to the same extent that you allow disconnects. Last time I checked, the kernel did not try to prevent users from unplugging their USB devices. :-) Eh, sure. A libusb program could simulate a disconnect of a misbehaving USB device through the sysfs files. Which means we can't prevent userspace from powering off a port for any particular reason. Sarah Sharp -- 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
[PATCH 0/8] USB port power off mechanism
The following changes since commit 66177cc10295ffdfc613c06f59b07a577d91ee82: usb: s3c-hsotg: Add header file protection macros in s3c-hsotg.h (2012-07-17 10:54:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-next-2012-07-17 for you to fetch changes up to 9358a5663ed54aa7a7ecb7ed50f4b2d8c86bf9c1: usb : Add sysfs files to control port power. (2012-07-17 15:22:28 -0700) USB port power off patches Hi Greg, Here's a respin of Tianyu's patches to introduce the port power off mechanism for future Intel systems. I've made the commit messages more readable, and it should just be able to merge it into your usb-next branch. The patches themselves only store some basic ACPI information, and add sysfs files that allow userspace to power on or off the ports. It doesn't add any particular policy, although we might add a kernel policy later. Sarah Sharp Lan Tianyu (8): usb: make usb port a real device usb: move children to struct usb_port usb/acpi: Bind ACPI node to USB port, not usb_device. usb/acpi: Store info on device removability. xhci: Handle clear PORT_POWER feature. usb/acpi: Use ACPI methods to power off ports. usb: Fail a get config when the port is powered off. usb : Add sysfs files to control port power. Documentation/ABI/testing/sysfs-bus-usb | 31 +++ drivers/staging/usbip/usbip_common.c|3 +- drivers/usb/core/config.c |2 + drivers/usb/core/devices.c |7 +- drivers/usb/core/hub.c | 344 +++ drivers/usb/core/usb-acpi.c | 205 ++- drivers/usb/core/usb.h | 16 ++ drivers/usb/host/r8a66597-hcd.c |5 +- drivers/usb/host/xhci-hub.c | 16 ++ include/linux/usb.h | 32 +++- 10 files changed, 562 insertions(+), 99 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
[PATCH 1/8] usb: make usb port a real device
From: Lan Tianyu tianyu@intel.com
This patch turns each USB port on a hub into a new struct device. This
new device has the USB hub interface device as its parent. The port
devices are stored in a new structure (usb_port), and an array of
usb_ports are dynamically allocated once we know how many ports the USB
hub has.
Move the port_owner variable out of usb_hub and into this new structure.
A new file will be created in the hub interface sysfs directory, so
add documentation.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Lan Tianyu tianyu@intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
Documentation/ABI/testing/sysfs-bus-usb |7 +++
drivers/usb/core/hub.c | 91 +--
2 files changed, 82 insertions(+), 16 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-usb
b/Documentation/ABI/testing/sysfs-bus-usb
index 5f75f8f..f59dc8c 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -220,3 +220,10 @@ Description:
If the device doesn't support LTM, the file will read no.
The file will be present for all speeds of USB devices, and will
always read no for USB 1.1 and USB 2.0 devices.
+
+What: /sys/bus/usb/devices/.../(hub interface)/portX
+Date: July 2012
+Contact: Lan Tianyu tianyu@intel.com
+Description:
+ The /sys/bus/usb/devices/.../(hub interface)/portX
+ is usb port device's sysfs directory.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 540f20b..f704c07 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -38,6 +38,11 @@
#endif
#endif
+struct usb_port {
+ struct device dev;
+ struct dev_state *port_owner;
+};
+
struct usb_hub {
struct device *intfdev; /* the interface device */
struct usb_device *hdev;
@@ -82,7 +87,11 @@ struct usb_hub {
u8 indicator[USB_MAXCHILDREN];
struct delayed_work leds;
struct delayed_work init_work;
- struct dev_state**port_owners;
+ struct usb_port **ports;
+};
+
+struct device_type usb_port_device_type = {
+ .name = usb_port,
};
static inline int hub_is_superspeed(struct usb_device *hdev)
@@ -155,6 +164,8 @@ EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
#define HUB_DEBOUNCE_STEP25
#define HUB_DEBOUNCE_STABLE 100
+#define to_usb_port(_dev) \
+ container_of(_dev, struct usb_port, dev)
static int usb_reset_and_verify_device(struct usb_device *udev);
@@ -1221,6 +1232,48 @@ static int hub_post_reset(struct usb_interface *intf)
return 0;
}
+static void usb_port_device_release(struct device *dev)
+{
+ struct usb_port *port_dev = to_usb_port(dev);
+
+ kfree(port_dev);
+}
+
+static void usb_hub_remove_port_device(struct usb_hub *hub,
+ int port1)
+{
+ device_unregister(hub-ports[port1 - 1]-dev);
+}
+
+static int usb_hub_create_port_device(struct usb_hub *hub,
+ int port1)
+{
+ struct usb_port *port_dev = NULL;
+ int retval;
+
+ port_dev = kzalloc(sizeof(*port_dev), GFP_KERNEL);
+ if (!port_dev) {
+ retval = -ENOMEM;
+ goto exit;
+ }
+
+ hub-ports[port1 - 1] = port_dev;
+ port_dev-dev.parent = hub-intfdev;
+ port_dev-dev.type = usb_port_device_type;
+ port_dev-dev.release = usb_port_device_release;
+ dev_set_name(port_dev-dev, port%d, port1);
+
+ retval = device_register(port_dev-dev);
+ if (retval)
+ goto error_register;
+ return 0;
+
+error_register:
+ put_device(port_dev-dev);
+exit:
+ return retval;
+}
+
static int hub_configure(struct usb_hub *hub,
struct usb_endpoint_descriptor *endpoint)
{
@@ -1230,7 +1283,7 @@ static int hub_configure(struct usb_hub *hub,
u16 hubstatus, hubchange;
u16 wHubCharacteristics;
unsigned int pipe;
- int maxp, ret;
+ int maxp, ret, i;
char *message = out of memory;
hub-buffer = kmalloc(sizeof(*hub-buffer), GFP_KERNEL);
@@ -1272,9 +1325,9 @@ static int hub_configure(struct usb_hub *hub,
hdev-children = kzalloc(hdev-maxchild *
sizeof(struct usb_device *), GFP_KERNEL);
- hub-port_owners = kzalloc(hdev-maxchild * sizeof(struct dev_state *),
- GFP_KERNEL);
- if (!hdev-children || !hub-port_owners) {
+ hub-ports = kzalloc(hdev-maxchild * sizeof(struct usb_port *),
+GFP_KERNEL);
+ if (!hdev-children || !hub-ports) {
ret = -ENOMEM;
goto fail;
}
@@ -1483,6 +1536,11 @@ static int hub_configure(struct usb_hub *hub,
if
[PATCH 2/8] usb: move children to struct usb_port
From: Lan Tianyu tianyu@intel.com
The usb_device structure contains an array of usb_device children.
This array is only valid if the usb_device is a hub, so it makes no
sense to store it there. Instead, store the usb_device child
in its parent usb_port structure.
Since usb_port is an internal USB core structure, add a new function to
get the USB device child, usb_hub_find_child(). Add a new macro,
usb_hub_get_each_child(), to iterate over all the children attached to a
particular USB hub.
Remove the printing the USB children array pointer from the usb-ip
driver, since it's really not necessary.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Lan Tianyu tianyu@intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/staging/usbip/usbip_common.c |3 +-
drivers/usb/core/devices.c |7 +--
drivers/usb/core/hub.c | 73 +++---
drivers/usb/host/r8a66597-hcd.c |5 +-
include/linux/usb.h | 15 ++-
5 files changed, 68 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/usbip/usbip_common.c
b/drivers/staging/usbip/usbip_common.c
index 70f23026..95beb76 100644
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -157,8 +157,7 @@ static void usbip_dump_usb_device(struct usb_device *udev)
dev_dbg(dev, have_langid %d, string_langid %d\n,
udev-have_langid, udev-string_langid);
- dev_dbg(dev, maxchild %d, children %p\n,
- udev-maxchild, udev-children);
+ dev_dbg(dev, maxchild %d\n, udev-maxchild);
}
static void usbip_dump_request_type(__u8 rt)
diff --git a/drivers/usb/core/devices.c b/drivers/usb/core/devices.c
index d956965..f4ead12 100644
--- a/drivers/usb/core/devices.c
+++ b/drivers/usb/core/devices.c
@@ -496,6 +496,7 @@ static ssize_t usb_device_dump(char __user **buffer, size_t
*nbytes,
char *pages_start, *data_end, *speed;
unsigned int length;
ssize_t total_written = 0;
+ struct usb_device *childdev = NULL;
/* don't bother with anything else if we're not writing any data */
if (*nbytes = 0)
@@ -589,14 +590,12 @@ static ssize_t usb_device_dump(char __user **buffer,
size_t *nbytes,
free_pages((unsigned long)pages_start, 1);
/* Now look at all of this device's children. */
- for (chix = 0; chix usbdev-maxchild; chix++) {
- struct usb_device *childdev = usbdev-children[chix];
-
+ usb_hub_for_each_child(usbdev, chix, childdev) {
if (childdev) {
usb_lock_device(childdev);
ret = usb_device_dump(buffer, nbytes, skip_bytes,
file_offset, childdev, bus,
- level + 1, chix, ++cnt);
+ level + 1, chix - 1, ++cnt);
usb_unlock_device(childdev);
if (ret == -EFAULT)
return total_written;
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f704c07..672b7ce 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -39,6 +39,7 @@
#endif
struct usb_port {
+ struct usb_device *child;
struct device dev;
struct dev_state *port_owner;
};
@@ -184,7 +185,7 @@ static inline char *portspeed(struct usb_hub *hub, int
portstatus)
/* Note that hdev or one of its children must be locked! */
static struct usb_hub *hdev_to_hub(struct usb_device *hdev)
{
- if (!hdev || !hdev-actconfig)
+ if (!hdev || !hdev-actconfig || !hdev-maxchild)
return NULL;
return usb_get_intfdata(hdev-actconfig-interface[0]);
}
@@ -879,8 +880,8 @@ static int hub_port_disable(struct usb_hub *hub, int port1,
int set_state)
struct usb_device *hdev = hub-hdev;
int ret = 0;
- if (hdev-children[port1-1] set_state)
- usb_set_device_state(hdev-children[port1-1],
+ if (hub-ports[port1 - 1]-child set_state)
+ usb_set_device_state(hub-ports[port1 - 1]-child,
USB_STATE_NOTATTACHED);
if (!hub-error !hub_is_superspeed(hub-hdev))
ret = clear_port_feature(hdev, port1, USB_PORT_FEAT_ENABLE);
@@ -1036,7 +1037,7 @@ static void hub_activate(struct usb_hub *hub, enum
hub_activation_type type)
* which ports need attention.
*/
for (port1 = 1; port1 = hdev-maxchild; ++port1) {
- struct usb_device *udev = hdev-children[port1-1];
+ struct usb_device *udev = hub-ports[port1 - 1]-child;
u16 portstatus, portchange;
portstatus = portchange = 0;
@@ -1201,8 +1202,8 @@ static void hub_quiesce(struct usb_hub *hub, enum
hub_quiescing_type type)
if (type != HUB_SUSPEND) {
/* Disconnect
[PATCH 3/8] usb/acpi: Bind ACPI node to USB port, not usb_device.
From: Lan Tianyu tianyu@intel.com
In the ACPI DSDT table, only usb root hub and usb ports are ACPI device
nodes. Originally, we bound the usb port's ACPI node to the usb device
attached to the port. However, we want to access those ACPI port
methods when the port is empty, and there's no usb_device associated
with that port.
Now that the usb port is a real device, we can bind the port's ACPI node
to struct usb_port instead.
Signed-off-by: Lan Tianyu tianyu@intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/core/hub.c | 18 +++
drivers/usb/core/usb-acpi.c | 67 +-
drivers/usb/core/usb.h | 12
3 files changed, 82 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 672b7ce..5673a0e 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5064,3 +5064,21 @@ struct usb_device *usb_hub_find_child(struct usb_device
*hdev,
return hub-ports[port1 - 1]-child;
}
EXPORT_SYMBOL_GPL(usb_hub_find_child);
+
+#ifdef CONFIG_ACPI
+/**
+ * usb_get_hub_port_acpi_handle - Get the usb port's acpi handle
+ * @hdev: USB device belonging to the usb hub
+ * @port1: port num of the port
+ *
+ * Return port's acpi handle if successful, NULL if params are
+ * invaild.
+ */
+acpi_handle usb_get_hub_port_acpi_handle(struct usb_device *hdev,
+ int port1)
+{
+ struct usb_hub *hub = hdev_to_hub(hdev);
+
+ return DEVICE_ACPI_HANDLE(hub-ports[port1 - 1]-dev);
+}
+#endif
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 8947b20..47197bf 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -70,22 +70,59 @@ static int usb_acpi_check_pld(struct usb_device *udev,
acpi_handle handle)
static int usb_acpi_find_device(struct device *dev, acpi_handle *handle)
{
struct usb_device *udev;
- struct device *parent;
acpi_handle *parent_handle;
+ int port_num;
- if (!is_usb_device(dev))
- return -ENODEV;
-
- udev = to_usb_device(dev);
- parent = dev-parent;
- parent_handle = DEVICE_ACPI_HANDLE(parent);
-
- if (!parent_handle)
- return -ENODEV;
-
- *handle = acpi_get_child(parent_handle, udev-portnum);
-
- if (!*handle)
+ /*
+* In the ACPI DSDT table, only usb root hub and usb ports are
+* acpi device nodes. The hierarchy like following.
+* Device (EHC1)
+* Device (HUBN)
+* Device (PR01)
+* Device (PR11)
+* Device (PR12)
+* Device (PR13)
+* ...
+* So all binding process is divided into two parts. binding
+* root hub and usb ports.
+*/
+ if (is_usb_device(dev)) {
+ udev = to_usb_device(dev);
+ if (udev-parent)
+ return -ENODEV;
+ /* root hub's parent is the usb hcd. */
+ parent_handle = DEVICE_ACPI_HANDLE(dev-parent);
+ *handle = acpi_get_child(parent_handle, udev-portnum);
+ if (!*handle)
+ return -ENODEV;
+ return 0;
+ } else if (is_usb_port(dev)) {
+ sscanf(dev_name(dev), port%d, port_num);
+ /* Get the struct usb_device point of port's hub */
+ udev = to_usb_device(dev-parent-parent);
+
+ /*
+* The root hub ports' parent is the root hub. The non-root-hub
+* ports' parent is the parent hub port which the hub is
+* connected to.
+*/
+ if (!udev-parent) {
+ *handle = acpi_get_child(DEVICE_ACPI_HANDLE(udev-dev),
+ port_num);
+ if (!*handle)
+ return -ENODEV;
+ } else {
+ parent_handle =
+ usb_get_hub_port_acpi_handle(udev-parent,
+ udev-portnum);
+ if (!parent_handle)
+ return -ENODEV;
+
+ *handle = acpi_get_child(parent_handle, port_num);
+ if (!*handle)
+ return -ENODEV;
+ }
+ } else
return -ENODEV;
/*
@@ -102,7 +139,7 @@ static int usb_acpi_find_device(struct device *dev,
acpi_handle *handle)
static struct acpi_bus_type usb_acpi_bus = {
.bus = usb_bus_type,
- .find_bridge = NULL,
+ .find_bridge = usb_acpi_find_device,
.find_device = usb_acpi_find_device,
};
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 67875a8..4aa20f4 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -1,5 +1,9 @@
[PATCH 7/8] usb: Fail a get config when the port is powered off.
From: Lan Tianyu tianyu@intel.com
Alan Stern pointed out that a USB port could potentially get powered off
when the attached USB device is in the middle of enumerating, due to
race conditions:
http://marc.info/?l=linux-usbm=134130616707548w=2
If that happens, we need to ensure the enumeration fails. If a call to
usb_get_descriptor() fails for a reason other than a Stall, return an
error. That should handle the case where the port is powered off.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Lan Tianyu tianyu@intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/core/config.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index f4bdd0c..7199adc 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -702,6 +702,8 @@ int usb_get_configuration(struct usb_device *dev)
if (result 0) {
dev_err(ddev, unable to read config index %d
descriptor/%s: %d\n, cfgno, start, result);
+ if (result != -EPIPE)
+ goto err;
dev_err(ddev, chopping to %d config(s)\n, cfgno);
dev-descriptor.bNumConfigurations = cfgno;
break;
--
1.7.9
--
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
[PATCH 6/8] usb/acpi: Use ACPI methods to power off ports.
From: Lan Tianyu tianyu@intel.com
Upcoming Intel systems will have an ACPI method to control whether a USB
port can be completely powered off. The implication of powering off a
USB port is that the device and host sees a physical disconnect, and
subsequent port connections and remote wakeups will be lost.
Add a new function, usb_acpi_power_manageable(), that can be used to
find whether the usb port has ACPI power resources that can be used to
power on and off the port on these machines. Also add a new function
called usb_acpi_set_power_state() that controls the port power via these
ACPI methods.
When the USB core calls into the xHCI hub driver to power off a port,
check whether the port can be completely powered off via this new ACPI
mechanism. If so, call into these new ACPI methods. Also use the ACPI
methods when the USB core asks to power on a port.
Signed-off-by: Lan Tianyu tianyu@intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/core/usb-acpi.c | 62 +++
drivers/usb/host/xhci-hub.c | 12
include/linux/usb.h | 10 +++
3 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 404d86a..0ef7d42 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -19,6 +19,68 @@
#include usb.h
+/**
+ * usb_acpi_power_manageable - check whether usb port has
+ * acpi power resource.
+ * @hdev: USB device belonging to the usb hub
+ * @index: port index based zero
+ *
+ * Return true if the port has acpi power resource and false if no.
+ */
+bool usb_acpi_power_manageable(struct usb_device *hdev, int index)
+{
+ acpi_handle port_handle;
+ int port1 = index + 1;
+
+ port_handle = usb_get_hub_port_acpi_handle(hdev,
+ port1);
+ if (port_handle)
+ return acpi_bus_power_manageable(port_handle);
+ else
+ return false;
+}
+EXPORT_SYMBOL_GPL(usb_acpi_power_manageable);
+
+/**
+ * usb_acpi_set_power_state - control usb port's power via acpi power
+ * resource
+ * @hdev: USB device belonging to the usb hub
+ * @index: port index based zero
+ * @enable: power state expected to be set
+ *
+ * Notice to use usb_acpi_power_manageable() to check whether the usb port
+ * has acpi power resource before invoking this function.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int usb_acpi_set_power_state(struct usb_device *hdev, int index, bool enable)
+{
+ acpi_handle port_handle;
+ unsigned char state;
+ int port1 = index + 1;
+ int error = -EINVAL;
+
+ port_handle = (acpi_handle)usb_get_hub_port_acpi_handle(hdev,
+ port1);
+ if (!port_handle)
+ return error;
+
+ if (enable)
+ state = ACPI_STATE_D0;
+ else
+ state = ACPI_STATE_D3_COLD;
+
+ error = acpi_bus_set_power(port_handle, state);
+ if (!error)
+ dev_dbg(hdev-dev, The power of hub port %d was set to %d\n,
+ port1, enable);
+ else
+ dev_dbg(hdev-dev, The power of hub port failed to be set\n);
+
+ return error;
+}
+EXPORT_SYMBOL_GPL(usb_acpi_set_power_state);
+
static int usb_acpi_check_port_connect_type(struct usb_device *hdev,
acpi_handle handle, int port1)
{
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 03032b3..630e9e6 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -766,6 +766,12 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
temp = xhci_readl(xhci, port_array[wIndex]);
xhci_dbg(xhci, set port power, actual port %d status
= 0x%x\n, wIndex, temp);
+
+ temp = usb_acpi_power_manageable(hcd-self.root_hub,
+ wIndex);
+ if (temp)
+ usb_acpi_set_power_state(hcd-self.root_hub,
+ wIndex, true);
break;
case USB_PORT_FEAT_RESET:
temp = (temp | PORT_RESET);
@@ -868,6 +874,12 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
case USB_PORT_FEAT_POWER:
xhci_writel(xhci, temp ~PORT_POWER,
port_array[wIndex]);
+
+ temp = usb_acpi_power_manageable(hcd-self.root_hub,
+ wIndex);
+ if (temp)
+ usb_acpi_set_power_state(hcd-self.root_hub,
+ wIndex, false);
break;
default:
goto error;
diff --git a/include/linux/usb.h b/include/linux/usb.h
index e0084a1..07915a3 100644
[PATCH 4/8] usb/acpi: Store info on device removability.
From: Lan Tianyu tianyu@intel.com
In the upcoming USB port power off patches, we need to know whether a
USB port can ever see a disconnect event. Often USB ports are internal
to a system, and users can't disconnect USB devices from that port.
Sometimes those ports will remain empty, because the OEM chose not to
connect an internal USB device to that port.
According to ACPI Spec 9.13, PLD indicates whether USB port is
user visible and _UPC indicates whether a USB device can be connected to
the USB port (we'll call this connectible). Here's a matrix of the
possible combinations:
Visible Connectible
NameExample
-
Yes No Unknown (Invalid state.)
Yes Yes Hot-plugUSB ports on the outside of a laptop.
A user could freely connect and disconnect
USB devices.
No Yes Hard-wired A USB modem hard-wired to a port on the
inside of a laptop.
No No Not usedThe port is internal to the system and
will remain empty.
Represent each of these four states with an enum usb_port_connect_type.
The four states are USB_PORT_CONNECT_TYPE_UNKNOWN,
USB_PORT_CONNECT_TYPE_HOT_PLUG, USB_PORT_CONNECT_TYPE_HARD_WIRED, and
USB_PORT_NOT_USED. When we get the USB port's acpi_handle, store the
state in connect_type in struct usb_port.
Signed-off-by: Lan Tianyu tianyu@intel.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/core/hub.c | 31
drivers/usb/core/usb-acpi.c | 80 ---
drivers/usb/core/usb.h |4 ++
include/linux/usb.h |7
4 files changed, 87 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5673a0e..038ef2b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -42,6 +42,7 @@ struct usb_port {
struct usb_device *child;
struct device dev;
struct dev_state *port_owner;
+ enum usb_port_connect_type connect_type;
};
struct usb_hub {
@@ -5065,6 +5066,36 @@ struct usb_device *usb_hub_find_child(struct usb_device
*hdev,
}
EXPORT_SYMBOL_GPL(usb_hub_find_child);
+/**
+ * usb_set_hub_port_connect_type - set hub port connect type.
+ * @hdev: USB device belonging to the usb hub
+ * @port1: port num of the port
+ * @type: connect type of the port
+ */
+void usb_set_hub_port_connect_type(struct usb_device *hdev, int port1,
+ enum usb_port_connect_type type)
+{
+ struct usb_hub *hub = hdev_to_hub(hdev);
+
+ hub-ports[port1 - 1]-connect_type = type;
+}
+
+/**
+ * usb_get_hub_port_connect_type - Get the port's connect type
+ * @hdev: USB device belonging to the usb hub
+ * @port1: port num of the port
+ *
+ * Return connect type of the port and if input params are
+ * invalid, return USB_PORT_CONNECT_TYPE_UNKNOWN.
+ */
+enum usb_port_connect_type
+usb_get_hub_port_connect_type(struct usb_device *hdev, int port1)
+{
+ struct usb_hub *hub = hdev_to_hub(hdev);
+
+ return hub-ports[port1 - 1]-connect_type;
+}
+
#ifdef CONFIG_ACPI
/**
* usb_get_hub_port_acpi_handle - Get the usb port's acpi handle
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 47197bf..404d86a 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -19,20 +19,29 @@
#include usb.h
-static int usb_acpi_check_upc(struct usb_device *udev, acpi_handle handle)
+static int usb_acpi_check_port_connect_type(struct usb_device *hdev,
+ acpi_handle handle, int port1)
{
acpi_status status;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *upc;
+ struct acpi_pld pld;
int ret = 0;
- status = acpi_evaluate_object(handle, _UPC, NULL, buffer);
-
+ /*
+* Accoding to ACPI Spec 9.13. PLD indicates whether usb port is
+* user visible and _UPC indicates whether it is connectable. If
+* the port was visible and connectable, it could be freely connected
+* and disconnected with USB devices. If no visible and connectable,
+* a usb device is directly hard-wired to the port. If no visible and
+* no connectable, the port would be not used.
+*/
+ status = acpi_get_physical_device_location(handle, pld);
if (ACPI_FAILURE(status))
return -ENODEV;
+ status = acpi_evaluate_object(handle, _UPC, NULL, buffer);
upc = buffer.pointer;
-
if (!upc || (upc-type != ACPI_TYPE_PACKAGE)
|| upc-package.count != 4) {
ret = -EINVAL;
@@ -40,33 +49,20 @@ static int usb_acpi_check_upc(struct usb_device *udev,
acpi_handle handle)
}
if (upc-package.elements[0].integer.value)
-
Re: [PATCH] usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams
On 07/17/2012 10:47 PM, Alan Stern wrote: On Tue, 17 Jul 2012, Laurent Pinchart wrote: Alan, what do you think about this approach ? I'm not sure whether we need to include the early UVC models that advertise a vendor-specific class in the list. The general approach is okay. The details aren't quite right. Are the 0x08c2 - 0x08c7 products the ones with a vendor-specific class? Well, I can see at least one that was missed -- mine! ;-) Seems like Laurent unwittingly left out the first webcam in the list from uvc_driver.c (with idProduct = 0x08c1). Eric -- 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] usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams
Hi Alan,
On Tuesday 17 July 2012 10:47:39 Alan Stern wrote:
On Tue, 17 Jul 2012, Laurent Pinchart wrote:
Most Logitech UVC webcams (both early models that don't advertise UVC
compatibility and newer UVC-advertised devices) require the RESET_RESUME
quirk. Instead of listing each and every model, match the devices based
on the UVC interface information.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/core/quirks.c | 86 ---
1 files changed, 24 insertions(+), 61 deletions(-)
Alan, what do you think about this approach ? I'm not sure whether we need
to include the early UVC models that advertise a vendor-specific class in
the list.
The general approach is okay. The details aren't quite right.
Are the 0x08c2 - 0x08c7 products the ones with a vendor-specific class?
Yes they are.
@@ -153,31 +116,31 @@ static const struct usb_device_id usb_quirk_list[] =
{
/* INTEL VALUE SSD */
{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME
},
+ /* Logitech UVC Cameras */
+ { .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x046d,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = USB_QUIRK_RESET_RESUME },
+
usb_match_device() doesn't pay attention to the MATCH_INT_INFO flag.
Therefore this entry would end up matching every Logitech device.
In fact, at the time usb_detect_quirks() gets called we haven't yet
read in the device's config descriptors, so matching based on interface
info won't work. It looks like we need a second routine,
usb_detect_interface_quirks(), which would be called at the end of
usb_enumerate_device(), along with a second id table.
OK, I'll implement that and resubmit.
--
Regards,
Laurent Pinchart
--
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
some questions about usb_serial_probe
Dear all: in usb_serial_probe, we create tty_port based on max_endpoints. My questions are: 1. some callback functions, such serial_hangup, serial_carrier_raised, etc. will called by tty layer with different tty_ports. how tty layer know these tty_ports? I only found tty_port_init to initial these tty_ports, but where we register these tty_ports to tty layer? -- Regards, -- 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 PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
2. If an internal USB port is suspended with remote wakeup disabled, power off the port. Add code to the USB core to ignore the device disconnect in this special case, so the driver thinks the device is still suspended. Issue a reset-resume when the driver wants to resume the device. The problem is we can't switch remote wakeup enable -- disable at runtime now. An /sys/../power/ entry to change intf-needs_remote_wakeup may be needed. Or a remote wakeup featured device plugs into that port will cause it will be not remote wakeup featured as SET_FEATURE for remote wakeup will not be called. Best regards, Peter -- 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/PATCH v2] usb: dwc3: Introduce OTG driver for dwc3
Hi,
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Ido Shayevitz
Sent: Thursday, July 12, 2012 1:24 AM
To: ba...@ti.com
Cc: linux-usb@vger.kernel.org; i...@codeaurora.org
Subject: [RFC/PATCH v2] usb: dwc3: Introduce OTG driver for dwc3
This is first release of otg driver for the dwc3 Synopsys USB3 core.
The otg driver implements the otg final state machine and control the
activation of the device controller or host controller.
In this first implementation, only simple DRD mode is implemented,
determine if A or B device according to the ID pin as reflected in the
OSTS.ConIDSts field.
Signed-off-by: Ido Shayevitz i...@codeaurora.org
---
drivers/usb/dwc3/Kconfig |6 +-
drivers/usb/dwc3/Makefile|2 +
drivers/usb/dwc3/core.c | 15 +-
drivers/usb/dwc3/core.h | 51 -
drivers/usb/dwc3/dwc3_otg.c | 512
++
drivers/usb/dwc3/dwc3_otg.h | 38 +++
drivers/usb/dwc3/gadget.c| 63 +
drivers/usb/host/xhci-plat.c | 21 ++
drivers/usb/host/xhci.c | 13 +-
9 files changed, 708 insertions(+), 13 deletions(-)
create mode 100644 drivers/usb/dwc3/dwc3_otg.c
create mode 100644 drivers/usb/dwc3/dwc3_otg.h
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index d13c60f..0cc108d 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,9 +1,9 @@
config USB_DWC3
tristate DesignWare USB3 DRD Core Support
- depends on (USB USB_GADGET)
+ depends on (USB || USB_GADGET)
select USB_OTG_UTILS
- select USB_GADGET_DUALSPEED
- select USB_GADGET_SUPERSPEED
+ select USB_GADGET_DUALSPEED if USB_GADGET
+ select USB_GADGET_SUPERSPEED if USB_GADGET
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index d441fe4..ffb3f55 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -1,11 +1,13 @@
ccflags-$(CONFIG_USB_DWC3_DEBUG) := -DDEBUG
ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
+ccflags-y += -Idrivers/usb/host
obj-$(CONFIG_USB_DWC3) += dwc3.o
dwc3-y := core.o
dwc3-y += host.o
dwc3-y += gadget.o ep0.o
+dwc3-y += dwc3_otg.o
ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y += debugfs.o
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c34452a..5343e39 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -517,15 +517,24 @@ static int __devinit dwc3_probe(struct
platform_device *pdev)
break;
case DWC3_MODE_DRD:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+ ret = dwc3_otg_init(dwc);
+ if (ret) {
+ dev_err(dev, failed to initialize otg\n);
+ goto err1;
+ }
+
ret = dwc3_host_init(dwc);
if (ret) {
dev_err(dev, failed to initialize host\n);
+ dwc3_otg_exit(dwc);
goto err1;
}
ret = dwc3_gadget_init(dwc);
if (ret) {
dev_err(dev, failed to initialize gadget\n);
+ dwc3_host_exit(dwc);
+ dwc3_otg_exit(dwc);
goto err1;
}
break;
@@ -554,8 +563,9 @@ err2:
dwc3_host_exit(dwc);
break;
case DWC3_MODE_DRD:
- dwc3_host_exit(dwc);
dwc3_gadget_exit(dwc);
+ dwc3_host_exit(dwc);
+ dwc3_otg_exit(dwc);
break;
default:
/* do nothing */
@@ -588,8 +598,9 @@ static int __devexit dwc3_remove(struct
platform_device *pdev)
dwc3_host_exit(dwc);
break;
case DWC3_MODE_DRD:
- dwc3_host_exit(dwc);
dwc3_gadget_exit(dwc);
+ dwc3_host_exit(dwc);
+ dwc3_otg_exit(dwc);
break;
default:
/* do nothing */
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 151eca8..793758b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -50,6 +50,8 @@
#include linux/usb/ch9.h
#include linux/usb/gadget.h
+#include dwc3_otg.h
+
/* Global constants */
#define DWC3_EP0_BOUNCE_SIZE 512
#define DWC3_ENDPOINTS_NUM 32
@@ -152,8 +154,9 @@
/* OTG Registers */
#define DWC3_OCFG0xcc00
#define DWC3_OCTL0xcc04
-#define DWC3_OEVTEN 0xcc08
-#define DWC3_OSTS
Re: some questions about usb_serial_probe
On Wed, Jul 18, 2012 at 11:22:49AM +0800, loody wrote: Dear all: in usb_serial_probe, we create tty_port based on max_endpoints. Or based on the number that the driver said to create. My questions are: 1. some callback functions, such serial_hangup, serial_carrier_raised, etc. will called by tty layer with different tty_ports. how tty layer know these tty_ports? They were registered with the tty layer. I only found tty_port_init to initial these tty_ports, but where we register these tty_ports to tty layer? When we register the tty device. greg k-h -- 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: some questions about usb_serial_probe
hi: 2012/7/18 Greg KH gre...@linuxfoundation.org: On Wed, Jul 18, 2012 at 11:22:49AM +0800, loody wrote: Dear all: in usb_serial_probe, we create tty_port based on max_endpoints. Or based on the number that the driver said to create. My questions are: 1. some callback functions, such serial_hangup, serial_carrier_raised, etc. will called by tty layer with different tty_ports. how tty layer know these tty_ports? They were registered with the tty layer. I only found tty_port_init to initial these tty_ports, but where we register these tty_ports to tty layer? When we register the tty device. Would you mind to tell me which function it is? greg k-h -- Thanks a lot, -- 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 02/11] arm/dts: omap: Add omap-usb2 dt data
Hi,
On Tue, Jul 17, 2012 at 5:57 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 17-07-2012 12:10, Kishon Vijay Abraham I wrote:
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bda5df3..4d2dcc1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@0x4a0ad080 {
There should be no 0x prefix here.
Ok. Will fix it.
Thanks
Kishon
--
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 2/2] arm/dts: omap4: Add ocp2scp data
Hi,
On Tue, Jul 17, 2012 at 6:06 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 16-07-2012 18:13, Kishon Vijay Abraham I wrote:
Add ocp2scp data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..bda5df3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,13 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ocp2scp@4a0ad000 {
reg property is absent, so why do you give the node name an address
postfix?
When I was initially developing, I had reg property populated. Those
info is now obtained from *ti,hwmods*. I'll resend the patch removing
it.
Thanks
Kishon
--
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
