Re: Linux USB file storage gadget with new UDC
Hi, On Sat, Mar 16, 2013 at 1:49 AM, Felipe Balbi wrote: > On Fri, Mar 15, 2013 at 11:00:45AM -0400, Alan Stern wrote: >> On Fri, 15 Mar 2013, Felipe Balbi wrote: >> >> > On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo wrote: >> > > Hi, >> > > >> > > > On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote: >> > > >> For bulk transfer, the new UDC driver has one problem. When SCSI >> > > >> Inquiry command is received, the UDC driver interrupt routine will >> > > >> receive it first. However, the queue function is not yet called, and >> > > >> queue buffer is not yet added. Thus, interrupt routine is not able to >> > > >> store the SCSI Inquiry command to the queue buffer. >> > > >> >> > > >> This is a serious problem, what is the way to synchronise UDC driver >> > > >> and file storage gadget driver for SCSI command bulk transfer? >> > > > >> > > > don't process the interrupt until you receive a queue. Data will be >> > > > pending in controller's FIFO until then. >> > > > >> > > >> > > change to do exactly that, bulk transfer interrupt come in, don't >> > > process, then queue function is called to add queue buffer. After >> > > that, no more bulk transfer interrupt come in. >> > >> > did you process the pending data from FIFO after queue was called ? >> >> I'm not sure about the details of how the controller hardware works. >> But what should happen is this: When the controller receives the bulk >> packet containing the INQUIRY command, it should send back NAK until it >> has a buffer ready to store the packet. > > right, with all controllers I have seen so far, this means just not > processing the interrupt, AKA not starting a transfer. > Thanks, i add processing the pending data from FIFO after queue was called. The UDC driver can process the SCSI INQUIRY command and SCSI READ FORMAT CAPACITIES command now. In the processing of SCSI READ FORMAT CAPACITIES command, there is attention condition. Then the bulk transfer stops completely and control transfer is repeated. How can i solve it? Regards, victor -- 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] usb: gadget: net2272: finally convert "CONFIG_USB_GADGET_NET2272_DMA"
The Kconfig symbol USB_GADGET_NET2272_DMA was renamed to USB_NET2272_DMA
in commit 193ab2a6070039e7ee2b9b9bebea754a7c52fd1b ("usb: gadget: allow
multiple gadgets to be built"). That commit did not convert the only
occurrence of the corresponding Kconfig macro. Convert that macro now.
Signed-off-by: Paul Bolle
---
0) Untested. I'll explain - at some length - why this patch needs testing.
1) The driver for the PLX NET2272 USB device controller and support for
its external DMA controller were added in v3.1-rc1, see commit
ceb80363b2ec1091dffd78064771e3d4679f69c7 ("USB: net2272: driver for PLX
NET2272 USB device controller").
2) Shortly after that driver and the support for its external DMA
controller (DMA support) were added, commit
193ab2a6070039e7ee2b9b9bebea754a7c52fd1b renamed the Kconfig symbol that
enables DMA support partially. It's this trivial oversight that this
patch fixes. That commit was also shipped in v3.1-rc1.
3) A consequence of all that is that it was (basically) never possible
to enable DMA support. Setting USB_NET2272_DMA had no effect. This also
makes me wonder whether DMA support is actually needed. But that is not
my call.
4) For those people still with me here, there's another reason why DMA
support couldn't be enabled from v3.1 up to v3.4. See, before commit
ed6c6f419f02a6da444e26374f3510ac57b6faf4 ("usb: gadget: conversion of
controllers choice to menu") both config USB_NET2272 and config
USB_NET2272_DMA were part of the same Kconfig choice. That means that
only one of these two could ever be selected. And selecting only
USB_NET2272_DMA, which depends on USB_NET2272, would therefore be
logically impossible. But I must admit that I couldn't be bothered to
run "make menuconfig" on the v3.4 tree to test my theory.
drivers/usb/gadget/net2272.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/net2272.c b/drivers/usb/gadget/net2272.c
index d226058..437759a 100644
--- a/drivers/usb/gadget/net2272.c
+++ b/drivers/usb/gadget/net2272.c
@@ -59,7 +59,7 @@ static const char * const ep_name[] = {
};
#define DMA_ADDR_INVALID (~(dma_addr_t)0)
-#ifdef CONFIG_USB_GADGET_NET2272_DMA
+#ifdef CONFIG_USB_NET2272_DMA
/*
* use_dma: the NET2272 can use an external DMA controller.
* Note that since there is no generic DMA api, some functions,
--
1.7.11.7
--
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: Two remain problems at chipidea driver
Peter Chen writes: > On Thu, Mar 14, 2013 at 09:53:55AM +0100, Marc Kleine-Budde wrote: >> On 03/14/2013 09:34 AM, Peter Chen wrote: >> > Hi Alex and all, >> > >> > Currently, we have two problems to block chipidea driver coming >> > development. >> > >> > As there are so many chipidea versions, we impossible to collect >> > all to make a decision, it is better to cover most of the cases, >> > and using device tree (or platform data) to cover exceptions >> > if they exist. >> > >> > 1. USB Mode Problem >> > How can we decide USB mode (gadget, host and otg) at driver, and >> > how to read OTGSC register? Below is my pinion. >> > >> > - We get gadget or host support from CAP_DCCPARAMS(DCCPARAMS_DC or >> > DCCPARAMS_HC), >> >> IIRC This is broken on mx25. The host only port gets into an error state >> if you read this register. :( > > If there is an exception, you can use DT to override it. Eg: > > if (ci->dccparams_is_error) > do not read DCCPARAMS; /* using DT dr_mode setting */ I know it's tempting to add more phandles to the device tree for every possible exception, but let's try to resist the temptation. Regards, -- Alex -- 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 v3 6/6] usb: musb: omap2430: use the new generic PHY framework
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/omap2430.c | 22 --
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..78251fd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
struct musb;
struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
struct usb_phy *xceiv;
+ struct phy *phy;
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a42a45..55f071d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -349,14 +349,24 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- if (dev->parent->of_node)
+ if (dev->parent->of_node) {
+ musb->phy = devm_of_phy_get_byname(dev->parent, "usb2-phy");
+
+ /* We can't totally remove musb->xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
"usb-phy", 0);
- else
+ } else {
musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb->phy = devm_phy_get(dev, 0);
+ }
- if (IS_ERR_OR_NULL(musb->xceiv)) {
- pr_err("HS USB OTG: no transceiver configured\n");
+ if (IS_ERR_OR_NULL(musb->xceiv) || IS_ERR_OR_NULL(musb->phy)) {
+ dev_err(dev, "no transceiver configured\n");
return -EPROBE_DEFER;
}
@@ -612,7 +622,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
omap2430_low_level_exit(musb);
- usb_phy_set_suspend(musb->xceiv, 1);
+ phy_suspend(musb->phy);
}
return 0;
@@ -628,7 +638,7 @@ static int omap2430_runtime_resume(struct device *dev)
musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
- usb_phy_set_suspend(musb->xceiv, 0);
+ phy_resume(musb->phy);
}
return 0;
--
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
[PATCH v3 4/6] ARM: OMAP: USB: Add phy binding information
In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind. The previously added usb_bind_phy
can't be removed yet because the musb controller continues to use the
old PHY library which has OTG in it (struct usb_phy has struct usb_otg
as member). Until we have a separate OTG state machine to handle all of
that, the new generic PHY framework and the old phy library will co-exist.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/board-2430sdp.c |2 ++
arch/arm/mach-omap2/board-3430sdp.c |2 ++
arch/arm/mach-omap2/board-4430sdp.c |2 ++
arch/arm/mach-omap2/board-cm-t35.c |2 ++
arch/arm/mach-omap2/board-devkit8000.c |2 ++
arch/arm/mach-omap2/board-igep0020.c |2 ++
arch/arm/mach-omap2/board-ldp.c |2 ++
arch/arm/mach-omap2/board-omap3beagle.c |2 ++
arch/arm/mach-omap2/board-omap3evm.c |2 ++
arch/arm/mach-omap2/board-omap3logic.c |2 ++
arch/arm/mach-omap2/board-omap3pandora.c |2 ++
arch/arm/mach-omap2/board-omap3stalker.c |2 ++
arch/arm/mach-omap2/board-omap3touchbook.c |2 ++
arch/arm/mach-omap2/board-omap4panda.c |2 ++
arch/arm/mach-omap2/board-overo.c|2 ++
arch/arm/mach-omap2/board-rm680.c|2 ++
arch/arm/mach-omap2/board-rx51.c |2 ++
arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
18 files changed, 36 insertions(+)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index a3e0aaa..271458b 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -265,6 +266,7 @@ static void __init omap_2430sdp_init(void)
omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+ phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ce812de..bf6ce1d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -601,6 +602,7 @@ static void __init omap_3430sdp_init(void)
omap_serial_init();
omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+ phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 35f3ad0..1a236cb 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -725,6 +726,7 @@ static void __init omap_4430sdp_init(void)
omap4_twl6030_hsmmc_init(mmc);
usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+ phy_bind("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
usb_musb_init(&musb_board_data);
status = omap_ethernet_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index af2bb21..6a2615a 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -726,6 +727,7 @@ static void __init cm_t3x_common_init(void)
omap_twl4030_audio_init("cm-t3x", NULL);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+ phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
cm_t35_init_usbh();
cm_t35_init_camera();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 53056c3..4ca7d23 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -624,6 +625,7 @@ static void __init devkit8000_init(void)
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+ phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
usbhs_init(&usbhs_bdata);
board_nand_init(devkit8000_nand_partitions,
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index bf92678..f0c28bc 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#in
[PATCH v3 3/6] usb: otg: twl4030: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework completely will break OTG. Once we have a separate OTG state machine,
we can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/twl4030-usb.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..aebcd6a 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -575,10 +576,38 @@ static int twl4030_set_host(struct usb_otg *otg, struct
usb_bus *host)
return 0;
}
+static int twl4030_usb_suspend(struct phy *phy)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+ twl4030_phy_suspend(twl, 1);
+
+ return 0;
+}
+
+static int twl4030_usb_resume(struct phy *phy)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(&phy->dev);
+
+ if (!twl->asleep)
+ return -EBUSY;
+ __twl4030_phy_resume(twl);
+ twl->asleep = 0;
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= twl4030_usb_suspend,
+ .resume = twl4030_usb_resume,
+ .owner = THIS_MODULE,
+};
+
static int twl4030_usb_probe(struct platform_device *pdev)
{
struct twl4030_usb_data *pdata = pdev->dev.platform_data;
struct twl4030_usb *twl;
+ struct phy *phy;
int status, err;
struct usb_otg *otg;
struct device_node *np = pdev->dev.of_node;
@@ -617,6 +646,13 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg->set_host = twl4030_set_host;
otg->set_peripheral = twl4030_set_peripheral;
+ phy = devm_phy_create(twl->dev, "twl4030", pdev->dev.of_node,
+ USB_PHY_TYPE_USB2, &ops, twl);
+ if (IS_ERR(phy)) {
+ dev_dbg(&pdev->dev, "Failed to create PHY\n");
+ return PTR_ERR(phy);
+ }
+
/* init spinlock for workqueue */
spin_lock_init(&twl->lock);
--
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
[PATCH v3 1/6] drivers: phy: add generic PHY framework
The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has describes the PHY (label, type etc..) and ops like init, exit, suspend, resume, poweron, shutdown. The documentation for the generic PHY framework is added in Documentation/phy.txt and the documentation for the sysfs entry is added in Documentation/ABI/testing/sysfs-class-phy. Signed-off-by: Kishon Vijay Abraham I --- Documentation/ABI/testing/sysfs-class-phy | 15 + Documentation/phy.txt | 108 ++ MAINTAINERS |7 + drivers/Kconfig |2 + drivers/Makefile |2 + drivers/phy/Kconfig | 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c| 574 + include/linux/phy/phy.h | 218 +++ 9 files changed, 944 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h diff --git a/Documentation/ABI/testing/sysfs-class-phy b/Documentation/ABI/testing/sysfs-class-phy new file mode 100644 index 000..47f17c9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-phy @@ -0,0 +1,15 @@ +What: /sys/class/phy//label +Date: Feb 2013 +KernelVersion: 3.10 +Contact: Kishon Vijay Abraham I +Description: + This is a read-only file for getting the label of the phy. + +What: /sys/class/phy//phy_bind +Date: Feb 2013 +KernelVersion: 3.10 +Contact: Kishon Vijay Abraham I +Description: + This is a read-only file for reading the phy binding + information. It contains the device name of the controller, + the index and the device name of the PHY in that order. diff --git a/Documentation/phy.txt b/Documentation/phy.txt new file mode 100644 index 000..6ba3192 --- /dev/null +++ b/Documentation/phy.txt @@ -0,0 +1,108 @@ + The Generic PHY Framework + Kishon Vijay Abraham I + +This document explains the Generic PHY Framework along with the APIs provided, +how-to-use, current status and the future work list. + +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controller has PHY functionality embedded into it and others use an external +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet, +SATA etc. + +The intention of creating this framework is to bring the phy drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and to +increase code maintainability. + +This framework will be of use only to devices that uses external PHY (PHY +functionality is not embedded within the controller). + +2. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. + +struct phy *phy_create(struct device *dev, const char *label, + struct device_node *of_node, int type, struct phy_ops *ops, + void *priv); +struct phy *devm_phy_create(struct device *dev, const char *label, + struct device_node *of_node, int type, struct phy_ops *ops, + void *priv); + +The PHY drivers can use one of the above 2 APIs to create the PHY by passing +the device pointer, label, device node, type, phy ops and a driver data. +phy_ops is a set of function pointers for performing PHY operations such as +init, exit, suspend, resume, poweron and shutdown. + +3. Binding the PHY to the controller + +The framework provides an API for binding the controller to the PHY in the +case of non dt boot. + +struct phy_bind *phy_bind(const char *dev_name, int index, + const char *phy_dev_name); + +The API fills the phy_bind structure with the dev_name (device name of the +controller), index and phy_dev_name (device name of the PHY). This will +be used when the controller requests this phy. This API should be used by +platform specific
[PATCH v3 5/6] ARM: dts: omap: update usb_otg_hs data
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
arch/arm/boot/dts/omap3.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |2 ++
3 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index abce256..3d6f9f6 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be "50". This signifies the controller can supply upto
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phy : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num_eps = <16>;
ram_bits = <12>;
ctrl-module = <&omap_control_usb>;
+ phy = <&usb2_phy>;
+ phy-names = "usb2-phy";
};
Board specific device node entry
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1e21565..cf50c18 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -405,6 +405,8 @@
interrupt-names = "mc", "dma";
ti,hwmods = "usb_otg_hs";
usb-phy = <&usb2_phy>;
+ phy = <&usb2_phy>;
+ phy-names = "usb2-phy";
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 06d044e..188d5b8 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -550,6 +550,8 @@
interrupt-names = "mc", "dma";
ti,hwmods = "usb_otg_hs";
usb-phy = <&usb2_phy>;
+ phy = <&usb2_phy>;
+ phy-names = "usb2-phy";
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
--
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
[PATCH v3 0/6] Generic PHY Framework
Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. Changes from v2: * removed phy_descriptor structure completely so changed the APIs which were taking phy_descriptor as parameters * Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used by PHY user drivers which has *phy* and *phy-names* binding in the dt data * Fixed a few typos * Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and class_dev_iter_exit for traversing through the phy list. (Note we still need phy_bind list and phy_bind_mutex). * Changed the sysfs entry name from *bind* to *phy_bind*. Changes from v1: * Added Documentation for the PHY framework * Added few more APIs mostly w.r.t devres * Modified omap-usb2 and twl4030 to make use of the new framework Did USB enumeration testing in panda and beagle. Kishon Vijay Abraham I (6): drivers: phy: add generic PHY framework usb: phy: omap-usb2: use the new generic PHY framework usb: otg: twl4030: use the new generic PHY framework ARM: OMAP: USB: Add phy binding information ARM: dts: omap: update usb_otg_hs data usb: musb: omap2430: use the new generic PHY framework Documentation/ABI/testing/sysfs-class-phy | 15 + Documentation/devicetree/bindings/usb/omap-usb.txt |5 + Documentation/phy.txt | 108 MAINTAINERS|7 + arch/arm/boot/dts/omap3.dtsi |2 + arch/arm/boot/dts/omap4.dtsi |2 + arch/arm/mach-omap2/board-2430sdp.c|2 + arch/arm/mach-omap2/board-3430sdp.c|2 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-cm-t35.c |2 + arch/arm/mach-omap2/board-devkit8000.c |2 + arch/arm/mach-omap2/board-igep0020.c |2 + arch/arm/mach-omap2/board-ldp.c|2 + arch/arm/mach-omap2/board-omap3beagle.c|2 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3logic.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |2 + arch/arm/mach-omap2/board-omap3touchbook.c |2 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |2 + arch/arm/mach-omap2/board-rm680.c |2 + arch/arm/mach-omap2/board-rx51.c |2 + arch/arm/mach-omap2/board-zoom-peripherals.c |2 + drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 drivers/usb/musb/musb_core.h |2 + drivers/usb/musb/omap2430.c| 22 +- drivers/usb/otg/twl4030-usb.c | 36 ++ drivers/usb/phy/omap-usb2.c| 47 ++ include/linux/phy/phy.h| 218 34 files changed, 1090 insertions(+), 6 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h -- 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
[PATCH v3 2/6] usb: phy: omap-usb2: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/phy/omap-usb2.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..819ba71 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,9 +120,48 @@ static int omap_usb2_suspend(struct usb_phy *x, int
suspend)
return 0;
}
+static int omap_usb_suspend(struct phy *x)
+{
+ struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+ if (!phy->is_suspended) {
+ omap_control_usb_phy_power(phy->control_dev, 0);
+ pm_runtime_put_sync(phy->dev);
+ phy->is_suspended = 1;
+ }
+
+ return 0;
+}
+
+static int omap_usb_resume(struct phy *x)
+{
+ u32 ret;
+ struct omap_usb *phy = dev_get_drvdata(&x->dev);
+
+ if (phy->is_suspended) {
+ ret = pm_runtime_get_sync(phy->dev);
+ if (ret < 0) {
+ dev_err(phy->dev, "get_sync failed with err %d\n",
+ ret);
+ return ret;
+ }
+ omap_control_usb_phy_power(phy->control_dev, 1);
+ phy->is_suspended = 0;
+ }
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= omap_usb_suspend,
+ .resume = omap_usb_resume,
+ .owner = THIS_MODULE,
+};
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
+ struct phy *generic_phy;
struct usb_otg *otg;
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
@@ -144,6 +184,13 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg= otg;
phy->phy.type = USB_PHY_TYPE_USB2;
+ generic_phy = devm_phy_create(phy->dev, "omap-usb2", pdev->dev.of_node,
+ USB_PHY_TYPE_USB2, &ops, phy);
+ if (IS_ERR(generic_phy)) {
+ dev_dbg(&pdev->dev, "Failed to create PHY\n");
+ return PTR_ERR(generic_phy);
+ }
+
phy->control_dev = omap_get_control_dev();
if (IS_ERR(phy->control_dev)) {
dev_dbg(&pdev->dev, "Failed to get control device\n");
--
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: [PATCH 3/5] usb: chipidea: udc: add the define TD_COUNT and fix all users
On Wed, Mar 20, 2013 at 09:17:06AM +0800, Peter Chen wrote:
> On Tue, Mar 19, 2013 at 01:02:59PM +0100, Michael Grzeschik wrote:
> > On Tue, Mar 19, 2013 at 09:34:54AM +0800, Peter Chen wrote:
> > > On Mon, Mar 18, 2013 at 03:28:26PM +0100, Michael Grzeschik wrote:
> > > > On Fri, Mar 08, 2013 at 05:54:37PM +0200, Alexander Shishkin wrote:
> > > > > Michael Grzeschik writes:
> > > > >
> > > > > > A static count of transfer descriptors was used everywhere in the
> > > > > > driver
> > > > > > with the fixed number 4. This patch adds a define, named TD_COUNT,
> > > > > > and
> > > > > > replaces all users of this value. This way its possible to have
> > > > > > only one
> > > > > > parameter to change and limit the amount of tds per transfer.
> > > > >
> > > > > I think Svetoslav made exactly the same patch in his patchset, but I
> > > > > think this patchset will go first.
> > > >
> > > > I did not find any patch comparable by Svetoslav. But, that patch
> > > > is superseeded by that hunk in my current branch anyway, as every TD can
> > > > maintain five DMA buffers:
> > > >
> > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > > index 09bc6ea..c961e3b 100644
> > > > --- a/drivers/usb/chipidea/udc.c
> > > > +++ b/drivers/usb/chipidea/udc.c
> > > > @@ -688,8 +688,8 @@ static int _ep_queue(struct usb_ep *ep, struct
> > > > usb_request *req)
> > > > goto done;
> > > > }
> > > >
> > > > - if (req->length > 4 *
> > > > CI13XXX_PAGE_SIZE) {
> > > > - req->length = 4 *
> > > > CI13XXX_PAGE_SIZE;
> > > > + if (req->length > 5 *
> > > > CI13XXX_PAGE_SIZE) {
> > > > + req->length = 5 *
> > > > CI13XXX_PAGE_SIZE;
> > > > retval = -EMSGSIZE;
> > > >
> > > > dev_warn(mEp->ci->dev, "request length truncated\n");
> > > > }
> > >
> > > No, 4 is ok. There are 5 buffer Pointers are dTD, but the Buffer Point 0
> > > may not 4K aligned. Eg, if the reg->length is 18KB, and the buf DMA
> > > address
> > > is 1K aligned, it needs two dTDs.
> > > The first dTD only uses: 1KB, 4KB, 4KB, 4KB, 4KB as 5 buffers space.
> >
> > When the first pointer is not aligned, then all other buffer pointers
> > will also not be.
>
> Please have a look of dTD descriptor at spec, the pointer 0 can be
> not 4k-aligned (the size is address - address & 4KB), but other
> buffer pointers are 4k-aligned required.
Can you point me to an document with exact page?
Regards,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: Two remain problems at chipidea driver
On Wed, Mar 20, 2013 at 11:11:09AM +0200, Alexander Shishkin wrote: > Peter Chen writes: > > > On Thu, Mar 14, 2013 at 09:53:55AM +0100, Marc Kleine-Budde wrote: > >> On 03/14/2013 09:34 AM, Peter Chen wrote: > >> > Hi Alex and all, > >> > > >> > Currently, we have two problems to block chipidea driver coming > >> > development. > >> > > >> > As there are so many chipidea versions, we impossible to collect > >> > all to make a decision, it is better to cover most of the cases, > >> > and using device tree (or platform data) to cover exceptions > >> > if they exist. > >> > > >> > 1. USB Mode Problem > >> > How can we decide USB mode (gadget, host and otg) at driver, and > >> > how to read OTGSC register? Below is my pinion. > >> > > >> > - We get gadget or host support from CAP_DCCPARAMS(DCCPARAMS_DC or > >> > DCCPARAMS_HC), > >> > >> IIRC This is broken on mx25. The host only port gets into an error state > >> if you read this register. :( > > > > If there is an exception, you can use DT to override it. Eg: > > > > if (ci->dccparams_is_error) > > do not read DCCPARAMS; /* using DT dr_mode setting */ > > I know it's tempting to add more phandles to the device tree for every > possible exception, but let's try to resist the temptation. Yes, as less as DT entries. Your suggestion for dr_mode is ok, but we may need additional DT entry to know if it is otg capable, as dr_mode is the working mode. > > Regards, > -- > Alex > -- Best Regards, Peter Chen -- 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] usb: xhci: Fix TRB transfer length macro used for Event TRB.
Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.
Signed-off-by: Vivek gautam
---
drivers/usb/host/xhci-ring.c | 45 +++--
drivers/usb/host/xhci.h |4 +++
2 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 8828754..fe59a30 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2027,8 +2027,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
if (event_trb != ep_ring->dequeue &&
event_trb != td->last_trb)
td->urb->actual_length =
- td->urb->transfer_buffer_length
- - TRB_LEN(le32_to_cpu(event->transfer_len));
+ td->urb->transfer_buffer_length -
+ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
else
td->urb->actual_length = 0;
@@ -2060,7 +2060,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
/* Maybe the event was for the data stage? */
td->urb->actual_length =
td->urb->transfer_buffer_length -
- TRB_LEN(le32_to_cpu(event->transfer_len));
+ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
xhci_dbg(xhci, "Waiting for status "
"stage event\n");
return 0;
@@ -2096,7 +2096,7 @@ static int process_isoc_td(struct xhci_hcd *xhci, struct
xhci_td *td,
/* handle completion code */
switch (trb_comp_code) {
case COMP_SUCCESS:
- if (TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) {
+ if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) {
frame->status = 0;
break;
}
@@ -2137,11 +2137,13 @@ static int process_isoc_td(struct xhci_hcd *xhci,
struct xhci_td *td,
cur_seg = ep_ring->deq_seg; cur_trb != event_trb;
next_trb(xhci, ep_ring, &cur_seg, &cur_trb)) {
if (!TRB_TYPE_NOOP_LE32(cur_trb->generic.field[3]) &&
- !TRB_TYPE_LINK_LE32(cur_trb->generic.field[3]))
- len +=
TRB_LEN(le32_to_cpu(cur_trb->generic.field[2]));
+ !TRB_TYPE_LINK_LE32(cur_trb->generic.field[3])) {
+ len += EVENT_TRB_LEN(le32_to_cpu
+ (cur_trb->generic.field[2]));
+ }
}
- len += TRB_LEN(le32_to_cpu(cur_trb->generic.field[2])) -
- TRB_LEN(le32_to_cpu(event->transfer_len));
+ len += EVENT_TRB_LEN(le32_to_cpu(cur_trb->generic.field[2])) -
+ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
if (trb_comp_code != COMP_STOP_INVAL) {
frame->actual_length = len;
@@ -2199,7 +2201,7 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci,
struct xhci_td *td,
case COMP_SUCCESS:
/* Double check that the HW transferred everything. */
if (event_trb != td->last_trb ||
- TRB_LEN(le32_to_cpu(event->transfer_len)) != 0)
{
+ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
xhci_warn(xhci, "WARN Successful completion "
"on short TX\n");
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
@@ -2225,20 +2227,21 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci,
struct xhci_td *td,
if (trb_comp_code == COMP_SHORT_TX)
xhci_dbg(xhci, "ep %#x - asked for %d bytes, "
"%d bytes untransferred\n",
- td->urb->ep->desc.bEndpointAddress,
- td->urb->transfer_buffer_length,
- TRB_LEN(le32_to_cpu(event->transfer_len)));
+ td->urb->ep->desc.bEndpointAddress,
+ td->urb->transfer_buffer_length,
+ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
/* Fast path - was this the last TRB in the TD for this URB? */
if (event_trb == td->last_trb) {
- if (TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
+ if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
td->urb->actual_length =
td->urb->transfer_buff
Re: Mismatch in TRB_LEN bit mask for Transfer Event TRBs
Hi Sarah, On Wed, Mar 20, 2013 at 10:17 AM, Vivek Gautam wrote: > Hi, > > > On Wed, Mar 20, 2013 at 12:51 AM, Sarah Sharp > wrote: >> On Thu, Mar 07, 2013 at 03:38:46PM +0530, Vivek Gautam wrote: >>> Hi Sarah, >>> >>> >>> While going through the code for Handling Transfer Events >>> (drivers/usb/host/xhci-ring.c), i hit upon this problem. >>> As defined in "drivers/usb/host/xhci.h" >>> >>> /* Normal TRB fields */ >>> /* transfer_len bitmasks - bits 0:16 */ >>> #define TRB_LEN(p) ((p) & 0x1) >>> >>> And the same macro i could see being used while Handling Trasfer >>> events "handle_tx_event()", and further in >>> process_ctrl_td(), process_isoc_td(), and process_bulk_intr_td(). >>> >>> However, as per XHCI specs (Rev 1.0, 5/21/10) section 6.4.2.1 for >>> Transfer event TRBs, the transfer length is bits 0:23 >>> thereby something like below could be valid: >>> >>> /* Transfer event TRB length bit mask */ >>> /* bits 0:23 */ >>> #defineEVENT_TRB_LEN(p)((p) & 0xff) >>> >>> This difference is confusing somewhat. >>> I hope the current code must be pretty much fine, and there could be >>> something that i might be stupidly missing. >> >> Nope, you've caught an honest-to-goodness bug. :) > > Hmm. > >> >> Would you like to submit a patch to fix this? It should be pretty easy >> to look at the context in xhci-ring.c and figure out whether the >> function is queueing a TRB (and thus should use the TRB_LEN macro) or >> handling a event TRB (and should be using the new EVENT_TRB_LEN macro). >> > > Sure, will send a patch for this. > Please refer to patch: usb: xhci: Fix TRB transfer length macro used for Event TRB. -- Thanks & Regards Vivek -- 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: Two remain problems at chipidea driver
Peter Chen writes: > On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: >> >> > Eg, for tablet or phone, the dr_mode may be "gadget", but the >> > otg_capable = 1. >> >> No, because dr_mode indicates controller's capability, and not the >> "current" mode of operation. Why would anyone want to put *that* in a >> DT? >> > > OK, now I totally understand your mind of this problem. In fact, dr_mode > is NOT controller's capability, even at its original place: > (Documentation/devicetree/bindings/usb/fsl-usb.txt or nvidia, > tegra20-ehci.txt) > dr_mode is the usb working mode. > > When we design USB system, the requirements are differ from products > to products. > The phone/tablet device may only wants itself as gadget > device, it needs to be no-response when there is a usb device plug in > (eg usb keyboard with Micro B-to-A cable). > > The car entertainment system or other Standard-A port system do not want > to be enumerated when it plugs to notebook using Standard A-to-A cable. Bah. Of course, you're right. We're stuck with dr_mode till people learn to design middleware stacks that can handle being both host and peripheral. > So, currently, even most of controllers are otg-capable, still most > of designs are one working mode designed. The reason why we design > the dr_mode is that we want controller working mode to be decided > by DT without re-compile the kernel by build out the host/gadget driver. Ok, so then how about introducing *one* more parameter, something like "dr_cap", which 1) when specified, supersedes DCCPARAMS, so no need to read that register any more; 2) when unspecified, use DCCPARAMS; 3) can be one of "host", "peripheral", "otg", "dual_role": - host, peripheral: initialize one role only, stick to that, no otg; - dual_role: initialize both roles, no otg; - otg: both roles, ci->is_otg == true. Another question now is, do we need "dual_role" variant for the dr_mode parameter? Regards, -- Alex -- 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: Two remain problems at chipidea driver
On 03/20/2013 12:04 PM, Alexander Shishkin wrote: > Peter Chen writes: > >> On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: >>> Eg, for tablet or phone, the dr_mode may be "gadget", but the otg_capable = 1. >>> >>> No, because dr_mode indicates controller's capability, and not the >>> "current" mode of operation. Why would anyone want to put *that* in a >>> DT? >>> >> >> OK, now I totally understand your mind of this problem. In fact, dr_mode >> is NOT controller's capability, even at its original place: >> (Documentation/devicetree/bindings/usb/fsl-usb.txt or nvidia, >> tegra20-ehci.txt) >> dr_mode is the usb working mode. >> >> When we design USB system, the requirements are differ from products >> to products. >> The phone/tablet device may only wants itself as gadget >> device, it needs to be no-response when there is a usb device plug in >> (eg usb keyboard with Micro B-to-A cable). >> >> The car entertainment system or other Standard-A port system do not want >> to be enumerated when it plugs to notebook using Standard A-to-A cable. > > Bah. Of course, you're right. We're stuck with dr_mode till people learn > to design middleware stacks that can handle being both host and > peripheral. > >> So, currently, even most of controllers are otg-capable, still most >> of designs are one working mode designed. The reason why we design >> the dr_mode is that we want controller working mode to be decided >> by DT without re-compile the kernel by build out the host/gadget driver. > > Ok, so then how about introducing *one* more parameter, something like > "dr_cap", which > 1) when specified, supersedes DCCPARAMS, so no need to read that > register any more; > 2) when unspecified, use DCCPARAMS; > 3) can be one of "host", "peripheral", "otg", "dual_role": >- host, peripheral: initialize one role only, stick to that, no otg; >- dual_role: initialize both roles, no otg; >- otg: both roles, ci->is_otg == true. > > Another question now is, do we need "dual_role" variant for the dr_mode > parameter? What's the difference between the newly proposed dr_cap and the dr_mode parameter? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/7] ARM: tegra: finalize USB EHCI and PHY bindings
Hi,
On Monday 18 March 2013 05:59 PM, Venu Byravarasu wrote:
The existing Tegra USB bindings have a few issues:
1) Many properties are documented as being part of the EHCI controller
node, yet they apply more to the PHY device. They should be moved.
2) Some registers in PHY1 are shared with PHY3, and hence PHY3 needs a
reg entry to point at PHY1's register space. We can't assume the PHY1
driver is present, so the PHY3 driver will directly access those
registers.
3) The list of clocks required by the PHY was missing some required
entries.
This patch fixes the binding definition to resolve these issues.
Signed-off-by: Venu Byravarasu
---
.../bindings/usb/nvidia,tegra20-ehci.txt | 27 +++
.../bindings/usb/nvidia,tegra20-usb-phy.txt| 27 +--
2 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
index 34c9528..df09330 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
@@ -6,27 +6,10 @@ Practice : Universal Serial Bus" with the following
modifications
and additions :
Required properties :
- - compatible : Should be "nvidia,tegra20-ehci" for USB controllers
- used in host mode.
- - phy_type : Should be one of "ulpi" or "utmi".
- - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
- activated for the bus to be powered.
- - nvidia,phy : phandle of the PHY instance, the controller is connected to.
-
-Required properties for phy_type == ulpi:
- - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
+ - compatible : Should be "nvidia,tegra20-ehci".
+ - nvidia,phy : phandle of the PHY that the controller is connected to.
+ - clocks : Contains a single entry which defines the USB controller's clock.
Optional properties:
- - dr_mode : dual role mode. Indicates the working mode for
- nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral",
- or "otg". Default to "host" if not defined for backward compatibility.
- host means this is a host controller
- peripheral means it is device controller
- otg means it can operate as either ("on the go")
- - nvidia,has-legacy-mode : boolean indicates whether this controller can
-operate in legacy mode (as APX 2500 / 2600). In legacy mode some
-registers are accessed through the APB_MISC base address instead of
-the USB controller. Since this is a legacy issue it probably does not
-warrant a compatible string of its own.
- - nvidia,needs-double-reset : boolean is to be set for some of the Tegra2
-USB ports, which need reset twice due to hardware issues.
+ - nvidia,needs-double-reset : boolean is to be set for some of the Tegra20
+ USB ports, which need reset twice due to hardware issues.
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
index 6bdaba2..7ceccd3 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
@@ -4,8 +4,24 @@ The device node for Tegra SOC USB PHY:
Required properties :
- compatible : Should be "nvidia,tegra20-usb-phy".
- - reg : Address and length of the register set for the USB PHY interface.
- - phy_type : Should be one of "ulpi" or "utmi".
+ - reg : Defines the following set of registers, in the order listed:
+ - The PHY's own register set.
+ Always present.
+ - The register set of the PHY containing the UTMI pad control registers.
+ Present if-and-only-if phy_type == utmi.
+ - phy_type : Should be one of "utmi", "ulpi" or "hsic".
dt property names generally dont have "_".
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: Two remain problems at chipidea driver
Marc Kleine-Budde writes: > On 03/20/2013 12:04 PM, Alexander Shishkin wrote: >> Peter Chen writes: >> >>> On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: > Eg, for tablet or phone, the dr_mode may be "gadget", but the > otg_capable = 1. No, because dr_mode indicates controller's capability, and not the "current" mode of operation. Why would anyone want to put *that* in a DT? >>> >>> OK, now I totally understand your mind of this problem. In fact, dr_mode >>> is NOT controller's capability, even at its original place: >>> (Documentation/devicetree/bindings/usb/fsl-usb.txt or nvidia, >>> tegra20-ehci.txt) >>> dr_mode is the usb working mode. >>> >>> When we design USB system, the requirements are differ from products >>> to products. >>> The phone/tablet device may only wants itself as gadget >>> device, it needs to be no-response when there is a usb device plug in >>> (eg usb keyboard with Micro B-to-A cable). >>> >>> The car entertainment system or other Standard-A port system do not want >>> to be enumerated when it plugs to notebook using Standard A-to-A cable. >> >> Bah. Of course, you're right. We're stuck with dr_mode till people learn >> to design middleware stacks that can handle being both host and >> peripheral. >> >>> So, currently, even most of controllers are otg-capable, still most >>> of designs are one working mode designed. The reason why we design >>> the dr_mode is that we want controller working mode to be decided >>> by DT without re-compile the kernel by build out the host/gadget driver. >> >> Ok, so then how about introducing *one* more parameter, something like >> "dr_cap", which >> 1) when specified, supersedes DCCPARAMS, so no need to read that >> register any more; >> 2) when unspecified, use DCCPARAMS; >> 3) can be one of "host", "peripheral", "otg", "dual_role": >>- host, peripheral: initialize one role only, stick to that, no otg; >>- dual_role: initialize both roles, no otg; >>- otg: both roles, ci->is_otg == true. >> >> Another question now is, do we need "dual_role" variant for the dr_mode >> parameter? > > What's the difference between the newly proposed dr_cap and the dr_mode > parameter? See the discussion above. dr_cap is what the device can actually do (host, peripheral, etc). Tells us which roles to initialize and wether we can access OTGSC on this device. dr_mode is what function of the device we'll be using on this particular board. Regards, -- Alex -- 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/7] ARM: tegra: update device trees for USB binding rework
Hi,
On Monday 18 March 2013 05:59 PM, Venu Byravarasu wrote:
This patch updates all Tegra board files so that they contain all the
properties required by the updated USB DT binding. Note that this patch
only adds the new properties and does not yet remove the old properties,
in order to maintain bisectability. The old properties will be removed
once the driver has been updated to assume the new bindings.
Signed-off-by: Venu Byravarasu
---
arch/arm/boot/dts/tegra20-colibri-512.dtsi |4 +++
arch/arm/boot/dts/tegra20-harmony.dts |8 +++---
arch/arm/boot/dts/tegra20-iris-512.dts |4 +++
arch/arm/boot/dts/tegra20-paz00.dts|8 +++---
arch/arm/boot/dts/tegra20-seaboard.dts | 13 +++---
arch/arm/boot/dts/tegra20-trimslice.dts| 12 +++---
arch/arm/boot/dts/tegra20-ventana.dts |7 +++--
arch/arm/boot/dts/tegra20.dtsi | 32 +--
8 files changed, 57 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index cb73e62..af5a7ae 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -443,6 +443,10 @@
nvidia,phy-reset-gpio = <&gpio 169 0>; /* gpio PV1 */
};
+ usb-phy@c5004000 {
This node doesn't have a *reg* property. So "@c5004000" is not needed.
This comment applies to all the nodes which doesn't have *reg* property.
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: Two remain problems at chipidea driver
On 03/20/2013 12:23 PM, Alexander Shishkin wrote: > Marc Kleine-Budde writes: > >> On 03/20/2013 12:04 PM, Alexander Shishkin wrote: >>> Peter Chen writes: >>> On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: > >> Eg, for tablet or phone, the dr_mode may be "gadget", but the >> otg_capable = 1. > > No, because dr_mode indicates controller's capability, and not the > "current" mode of operation. Why would anyone want to put *that* in a > DT? > OK, now I totally understand your mind of this problem. In fact, dr_mode is NOT controller's capability, even at its original place: (Documentation/devicetree/bindings/usb/fsl-usb.txt or nvidia, tegra20-ehci.txt) dr_mode is the usb working mode. When we design USB system, the requirements are differ from products to products. The phone/tablet device may only wants itself as gadget device, it needs to be no-response when there is a usb device plug in (eg usb keyboard with Micro B-to-A cable). The car entertainment system or other Standard-A port system do not want to be enumerated when it plugs to notebook using Standard A-to-A cable. >>> >>> Bah. Of course, you're right. We're stuck with dr_mode till people learn >>> to design middleware stacks that can handle being both host and >>> peripheral. >>> So, currently, even most of controllers are otg-capable, still most of designs are one working mode designed. The reason why we design the dr_mode is that we want controller working mode to be decided by DT without re-compile the kernel by build out the host/gadget driver. >>> >>> Ok, so then how about introducing *one* more parameter, something like >>> "dr_cap", which >>> 1) when specified, supersedes DCCPARAMS, so no need to read that >>> register any more; >>> 2) when unspecified, use DCCPARAMS; >>> 3) can be one of "host", "peripheral", "otg", "dual_role": >>>- host, peripheral: initialize one role only, stick to that, no otg; >>>- dual_role: initialize both roles, no otg; >>>- otg: both roles, ci->is_otg == true. >>> >>> Another question now is, do we need "dual_role" variant for the dr_mode >>> parameter? >> >> What's the difference between the newly proposed dr_cap and the dr_mode >> parameter? > > See the discussion above. > > dr_cap is what the device can actually do (host, peripheral, etc). Tells > us which roles to initialize and wether we can access OTGSC on this > device. > dr_mode is what function of the device we'll be using on this particular > board. Sorry, I don't get why the driver needs to know what the chipidea can do in theory (dr_cap). IMHO it should be sufficient to tell the driver what that exact hardware it runs on can do (dr_mode). What the hardware can do depends on the actual chipidea implementation used in that SoC and the board the SoC is soldered on. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
RE: [PATCH 0/7] USB: PHY: Tegra: registering TEGRA USB PHY as platform driver
> -Original Message- > From: Venu Byravarasu > Sent: Wednesday, March 20, 2013 11:30 AM > To: 'Stephen Warren' > Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu; > ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; > linux-te...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org > Subject: RE: [PATCH 0/7] USB: PHY: Tegra: registering TEGRA USB PHY as > platform driver > > > -Original Message- > > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > > Sent: Wednesday, March 20, 2013 1:22 AM > > To: Venu Byravarasu > > Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu; > > ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; > > linux-te...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org > > Subject: Re: [PATCH 0/7] USB: PHY: Tegra: registering TEGRA USB PHY as > > platform driver > > > > On 03/18/2013 06:29 AM, Venu Byravarasu wrote: > > > As part of this series, apart from patch containing changes to register > > TEGRA > > > USB PHY driver as platform driver, prepared below patches: > > > 1. Re-arranging & adding new DT properties. > > > 2. Getting various params from DT properties added. > > > 3. code clean up. > > > > Venu, I'm curious whether these patches were tested at all. I have found > > at least two significant problems with trivial testing: > > Stephen, > Initially started testing after applying each and every patch. > Like that tested till first 5 patches. > As did not see any issues till then, applied rest 2 patches at once and tested > with that. > Though did not see mouse getting vbus on the 1st boot, Vbus was coming > fine after disconnect and connect. > Hence did not test thereafter. > > After checking your current mail, tried now and observed that there seems to > be some real issue with patch#7 only. (As tried now after applying till patch# > 6 and did not see this issue). > Will debug further on patch#7 and update with proper fix after addressing > your other comments. Debugged further and found that the issue is because of http://marc.info/?l=linux-arm-kernel&m=135890098024987&w=2 On reverting that patch and applying it on top of patch#7, able to see enumeration working fine. Anyhow, will take care of your other comments and merge this change with patch#7 and resend for review. > > Thanks for the review & heads up, > venu > -- 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: Linux USB file storage gadget with new UDC
On Wed, Mar 20, 2013 at 03:41:08PM +0800, victor yeo wrote: > Hi, > > On Sat, Mar 16, 2013 at 1:49 AM, Felipe Balbi wrote: > > On Fri, Mar 15, 2013 at 11:00:45AM -0400, Alan Stern wrote: > >> On Fri, 15 Mar 2013, Felipe Balbi wrote: > >> > >> > On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo wrote: > >> > > Hi, > >> > > > >> > > > On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote: > >> > > >> For bulk transfer, the new UDC driver has one problem. When SCSI > >> > > >> Inquiry command is received, the UDC driver interrupt routine will > >> > > >> receive it first. However, the queue function is not yet called, and > >> > > >> queue buffer is not yet added. Thus, interrupt routine is not able > >> > > >> to > >> > > >> store the SCSI Inquiry command to the queue buffer. > >> > > >> > >> > > >> This is a serious problem, what is the way to synchronise UDC driver > >> > > >> and file storage gadget driver for SCSI command bulk transfer? > >> > > > > >> > > > don't process the interrupt until you receive a queue. Data will be > >> > > > pending in controller's FIFO until then. > >> > > > > >> > > > >> > > change to do exactly that, bulk transfer interrupt come in, don't > >> > > process, then queue function is called to add queue buffer. After > >> > > that, no more bulk transfer interrupt come in. > >> > > >> > did you process the pending data from FIFO after queue was called ? > >> > >> I'm not sure about the details of how the controller hardware works. > >> But what should happen is this: When the controller receives the bulk > >> packet containing the INQUIRY command, it should send back NAK until it > >> has a buffer ready to store the packet. > > > > right, with all controllers I have seen so far, this means just not > > processing the interrupt, AKA not starting a transfer. > > > > Thanks, i add processing the pending data from FIFO after queue was > called. The UDC driver can process the SCSI INQUIRY command and SCSI > READ FORMAT CAPACITIES command now. > > In the processing of SCSI READ FORMAT CAPACITIES command, there is > attention condition. Then the bulk transfer stops completely and > control transfer is repeated. How can i solve it? by fixing your driver -- balbi signature.asc Description: Digital signature
RE: [PATCH 1/7] ARM: tegra: finalize USB EHCI and PHY bindings
> -Original Message- > From: kishon [mailto:kis...@ti.com] > Sent: Wednesday, March 20, 2013 4:49 PM > To: Venu Byravarasu > Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu; > ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; > swar...@wwwdotorg.org; linux-te...@vger.kernel.org; devicetree- > disc...@lists.ozlabs.org > Subject: Re: [PATCH 1/7] ARM: tegra: finalize USB EHCI and PHY bindings > > Hi, > > On Monday 18 March 2013 05:59 PM, Venu Byravarasu wrote: > > The existing Tegra USB bindings have a few issues: > > > > 1) Many properties are documented as being part of the EHCI controller > > node, yet they apply more to the PHY device. They should be moved. > > > > 2) Some registers in PHY1 are shared with PHY3, and hence PHY3 needs a > > reg entry to point at PHY1's register space. We can't assume the PHY1 > > driver is present, so the PHY3 driver will directly access those > > registers. > > > > 3) The list of clocks required by the PHY was missing some required > > entries. > > > > This patch fixes the binding definition to resolve these issues. > > > > Signed-off-by: Venu Byravarasu > > --- > > .../bindings/usb/nvidia,tegra20-ehci.txt | 27 > > +++ > > .../bindings/usb/nvidia,tegra20-usb-phy.txt| 27 > +-- > > 2 files changed, 29 insertions(+), 25 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt > b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt > > index 34c9528..df09330 100644 > > --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt > > +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt > > @@ -6,27 +6,10 @@ Practice : Universal Serial Bus" with the following > modifications > > and additions : > > > > Required properties : > > - - compatible : Should be "nvidia,tegra20-ehci" for USB controllers > > - used in host mode. > > - - phy_type : Should be one of "ulpi" or "utmi". > > > > Optional properties: > > - - dr_mode : dual role mode. Indicates the working mode for > > index 6bdaba2..7ceccd3 100644 > > --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt > > +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt > > @@ -4,8 +4,24 @@ The device node for Tegra SOC USB PHY: > > > > Required properties : > > + - phy_type : Should be one of "utmi", "ulpi" or "hsic". > > dt property names generally dont have "_". Thanks Kishon, for your comments. Is it mandatory or optional? If it is mandatory, then I might have to change dr_mode as well along with phy_type. > > 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/7] ARM: tegra: update device trees for USB binding rework
> -Original Message-
> From: kishon [mailto:kis...@ti.com]
> Sent: Wednesday, March 20, 2013 4:53 PM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> swar...@wwwdotorg.org; linux-te...@vger.kernel.org; devicetree-
> disc...@lists.ozlabs.org
> Subject: Re: [PATCH 2/7] ARM: tegra: update device trees for USB binding
> rework
>
> Hi,
>
> On Monday 18 March 2013 05:59 PM, Venu Byravarasu wrote:
> > This patch updates all Tegra board files so that they contain all the
> > properties required by the updated USB DT binding. Note that this patch
> > only adds the new properties and does not yet remove the old properties,
> > in order to maintain bisectability. The old properties will be removed
> > once the driver has been updated to assume the new bindings.
> >
> > Signed-off-by: Venu Byravarasu
> > ---
> > arch/arm/boot/dts/tegra20-colibri-512.dtsi |4 +++
> > arch/arm/boot/dts/tegra20-harmony.dts |8 +++---
> > arch/arm/boot/dts/tegra20-iris-512.dts |4 +++
> > arch/arm/boot/dts/tegra20-paz00.dts|8 +++---
> > arch/arm/boot/dts/tegra20-seaboard.dts | 13 +++---
> > arch/arm/boot/dts/tegra20-trimslice.dts| 12 +++---
> > arch/arm/boot/dts/tegra20-ventana.dts |7 +++--
> > arch/arm/boot/dts/tegra20.dtsi | 32
> > +--
> > 8 files changed, 57 insertions(+), 31 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> > index cb73e62..af5a7ae 100644
> > --- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> > +++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> > @@ -443,6 +443,10 @@
> > nvidia,phy-reset-gpio = <&gpio 169 0>; /* gpio PV1 */
> > };
> >
> > + usb-phy@c5004000 {
> This node doesn't have a *reg* property. So "@c5004000" is not needed.
> This comment applies to all the nodes which doesn't have *reg* property.
Thanks Kishon for the comments.
As I've 3 usb-phy DT nodes, how to differentiate between them if I remove this
@Address ?
>
> 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: USB-related build errors on Tegra in next-20130319
Hi, On Tue, Mar 19, 2013 at 10:29:05AM -0600, Stephen Warren wrote: > I see the following Kconfig warnings in next-20130319: > > > warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI which > > has unmet direct dependencies (USB_SUPPORT && USB_PHY && ARM) > > warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT > > which has unmet direct dependencies (USB_SUPPORT && USB_PHY && USB_ULPI) > > include/config/auto.conf:624:warning: override: ARCH_MULTIPLATFORM changes > > choice state > > warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI which > > has unmet direct dependencies (USB_SUPPORT && USB_PHY && ARM) > > warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT > > which has unmet direct dependencies (USB_SUPPORT && USB_PHY && USB_ULPI) > > Which I believe are the cause of the following build errors: > > > drivers/built-in.o: In function `controller_resume': > > drivers/usb/host/ehci-tegra.c:556: undefined reference to > > `tegra_usb_phy_preresume' > > drivers/usb/host/ehci-tegra.c:479: undefined reference to > > `tegra_ehci_phy_restore_start' > > drivers/usb/host/ehci-tegra.c:551: undefined reference to > > `tegra_ehci_phy_restore_end' > > drivers/usb/host/ehci-tegra.c:546: undefined reference to > > `tegra_ehci_phy_restore_end' > > drivers/built-in.o: In function `tegra_ehci_probe': > > drivers/usb/host/ehci-tegra.c:734: undefined reference to > > `tegra_usb_phy_open' > > drivers/built-in.o: In function `tegra_ehci_hub_control': > > drivers/usb/host/ehci-tegra.c:162: undefined reference to > > `tegra_usb_phy_postresume' > > drivers/usb/host/ehci-tegra.c:215: undefined reference to > > `tegra_usb_phy_preresume' > > make: *** [vmlinux] Error 1 > > I pointed out at least the Kconfig problems when you posted the PHY > error handling cleanup series, so I'm not sure why those patches were > applied. Because tegra EHCI shouldn't be selecting the PHY and you didn't even have a proper PHY driver. Try patch below: From cc705d4038f6adc24dc0d2ad9a1b28a798fafb95 Mon Sep 17 00:00:00 2001 From: Felipe Balbi Date: Wed, 20 Mar 2013 14:18:28 +0200 Subject: [PATCH] arm: tegra: fix Kconfig select clauses USB_ULPI and USB_ULPI_VIEWPORT shouldn't really be selected directly by anyone, but since Tegra still needs some time before turning ulpi viewport into a proper PHY driver, we need to keep the selects in place. This patch just fixes the conditional select so that it will continue to build after merging the latest PHY layer changes. Signed-off-by: Felipe Balbi --- arch/arm/mach-tegra/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index d1c4893..dbc653e 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -18,8 +18,8 @@ config ARCH_TEGRA_2x_SOC select PL310_ERRATA_727915 if CACHE_L2X0 select PL310_ERRATA_769419 if CACHE_L2X0 select USB_ARCH_HAS_EHCI if USB_SUPPORT - select USB_ULPI if USB - select USB_ULPI_VIEWPORT if USB_SUPPORT + select USB_ULPI if USB_PHY + select USB_ULPI_VIEWPORT if USB_PHY help Support for NVIDIA Tegra AP20 and T20 processors, based on the ARM CortexA9MP CPU and the ARM PL310 L2 cache controller @@ -37,8 +37,8 @@ config ARCH_TEGRA_3x_SOC select PINCTRL_TEGRA30 select PL310_ERRATA_769419 if CACHE_L2X0 select USB_ARCH_HAS_EHCI if USB_SUPPORT - select USB_ULPI if USB - select USB_ULPI_VIEWPORT if USB_SUPPORT + select USB_ULPI if USB_PHY + select USB_ULPI_VIEWPORT if USB_PHY help Support for NVIDIA Tegra T30 processor family, based on the ARM CortexA9MP CPU and the ARM PL310 L2 cache controller -- 1.8.2 -- balbi signature.asc Description: Digital signature
RE: [PATCH 2/7] ARM: tegra: update device trees for USB binding rework
> -Original Message- > From: Stephen Warren [mailto:swar...@wwwdotorg.org] > Sent: Wednesday, March 20, 2013 1:24 AM > To: Venu Byravarasu > Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu; > ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; > linux-te...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org > Subject: Re: [PATCH 2/7] ARM: tegra: update device trees for USB binding > rework > > On 03/18/2013 06:29 AM, Venu Byravarasu wrote: > > This patch updates all Tegra board files so that they contain all the > > properties required by the updated USB DT binding. Note that this patch > > only adds the new properties and does not yet remove the old properties, > > in order to maintain bisectability. The old properties will be removed > > once the driver has been updated to assume the new bindings. > > > > Signed-off-by: Venu Byravarasu > > --- > > arch/arm/boot/dts/tegra20-colibri-512.dtsi |4 +++ > > arch/arm/boot/dts/tegra20-harmony.dts |8 +++--- > > arch/arm/boot/dts/tegra20-iris-512.dts |4 +++ > > arch/arm/boot/dts/tegra20-paz00.dts|8 +++--- > > arch/arm/boot/dts/tegra20-seaboard.dts | 13 +++--- > > arch/arm/boot/dts/tegra20-trimslice.dts| 12 +++--- > > arch/arm/boot/dts/tegra20-ventana.dts |7 +++-- > > arch/arm/boot/dts/tegra20.dtsi | 32 > > +-- > > 8 files changed, 57 insertions(+), 31 deletions(-) > > I think you forgot to update arch/arm/boot/dts/tegra20-whistler.dts in > this patch. Thanks Stephen, will add that & send updated patch for review. -- 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: phy: gpio-vbus: don't ignore regulator APIs return value
On Wed, Mar 20, 2013 at 09:26:03AM +0100, Mark Brown wrote:
> On Wed, Mar 20, 2013 at 08:12:43AM +0200, Felipe Balbi wrote:
> > Due to recent changes to regulator API, all
> > users which don't check regulator_{en,dis}able()'s
> > return value will generate compile warnings.
>
> Should only be enable that warns but it doesn't do any harm to check
> both - thanks for doing this, I thought I'd sent patches for most of the
> affected users (found several bugs while I was at it too).
Yeah, I saw your mail, but unfortunately you missed this one. No
problem.
Do I get an Acked-by to carry on ?
cheers
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 3/7] usb: phy: tegra: Get PHY mode using DT
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, March 20, 2013 1:29 AM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-te...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org
> Subject: Re: [PATCH 3/7] usb: phy: tegra: Get PHY mode using DT
>
> On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> > Added a new PHY mode to support OTG.
> > Obtained Tegra USB PHY mode using DT property.
>
> > diff --git a/drivers/usb/phy/tegra_usb_phy.c
> b/drivers/usb/phy/tegra_usb_phy.c
>
> > @@ -713,6 +712,16 @@ struct tegra_usb_phy
> *tegra_usb_phy_open(struct device *dev, int instance,
> > else
> > phy->is_ulpi_phy = true;
> >
> > + err = of_property_match_string(np, "dr_mode", "otg");
> > + if (err < 0) {
> > + err = of_property_match_string(np, "dr_mode", "gadget");
> > + if (err < 0)
>
> The binding says the 3 legal values for this property are "host",
> "peripheral", or "otg". This agrees with the usage in
> Documentation/devicetree/bindings/usb/fsl-usb.txt and
> drivers/usb/host/fsl-mph-dr-of.c. So, "gadget" is not something the code
> should be checking for.
Agree, will correct it.
>
> I'm sure I pointed this out before.
--
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/7] ARM: tegra: update device trees for USB binding rework
On Wed, Mar 20, 2013 at 05:47:46PM +0530, Venu Byravarasu wrote:
> > -Original Message-
> > From: kishon [mailto:kis...@ti.com]
> > Sent: Wednesday, March 20, 2013 4:53 PM
> > To: Venu Byravarasu
> > Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> > ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> > swar...@wwwdotorg.org; linux-te...@vger.kernel.org; devicetree-
> > disc...@lists.ozlabs.org
> > Subject: Re: [PATCH 2/7] ARM: tegra: update device trees for USB binding
> > rework
> >
> > Hi,
> >
> > On Monday 18 March 2013 05:59 PM, Venu Byravarasu wrote:
> > > This patch updates all Tegra board files so that they contain all the
> > > properties required by the updated USB DT binding. Note that this patch
> > > only adds the new properties and does not yet remove the old properties,
> > > in order to maintain bisectability. The old properties will be removed
> > > once the driver has been updated to assume the new bindings.
> > >
> > > Signed-off-by: Venu Byravarasu
> > > ---
> > > arch/arm/boot/dts/tegra20-colibri-512.dtsi |4 +++
> > > arch/arm/boot/dts/tegra20-harmony.dts |8 +++---
> > > arch/arm/boot/dts/tegra20-iris-512.dts |4 +++
> > > arch/arm/boot/dts/tegra20-paz00.dts|8 +++---
> > > arch/arm/boot/dts/tegra20-seaboard.dts | 13 +++---
> > > arch/arm/boot/dts/tegra20-trimslice.dts| 12 +++---
> > > arch/arm/boot/dts/tegra20-ventana.dts |7 +++--
> > > arch/arm/boot/dts/tegra20.dtsi | 32
> > > +--
> > > 8 files changed, 57 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> > b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> > > index cb73e62..af5a7ae 100644
> > > --- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> > > +++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> > > @@ -443,6 +443,10 @@
> > > nvidia,phy-reset-gpio = <&gpio 169 0>; /* gpio PV1 */
> > > };
> > >
> > > + usb-phy@c5004000 {
> > This node doesn't have a *reg* property. So "@c5004000" is not needed.
> > This comment applies to all the nodes which doesn't have *reg* property.
>
> Thanks Kishon for the comments.
> As I've 3 usb-phy DT nodes, how to differentiate between them if I remove
> this @Address ?
then add reg property :-)
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 2/7] ARM: tegra: update device trees for USB binding rework
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Wednesday, March 20, 2013 5:55 PM
> To: Venu Byravarasu
> Cc: kishon; gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> swar...@wwwdotorg.org; linux-te...@vger.kernel.org; devicetree-
> disc...@lists.ozlabs.org
> Subject: Re: [PATCH 2/7] ARM: tegra: update device trees for USB binding
> rework
>
> * PGP Signed by an unknown key
>
> On Wed, Mar 20, 2013 at 05:47:46PM +0530, Venu Byravarasu wrote:
> > > -Original Message-
> > > From: kishon [mailto:kis...@ti.com]
> > > Sent: Wednesday, March 20, 2013 4:53 PM
> > > To: Venu Byravarasu
> > > Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> > > ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > swar...@wwwdotorg.org; linux-te...@vger.kernel.org; devicetree-
> > > disc...@lists.ozlabs.org
> > > Subject: Re: [PATCH 2/7] ARM: tegra: update device trees for USB binding
> > > rework
> > >
> > > Hi,
> > > >
> > > > + usb-phy@c5004000 {
> > > This node doesn't have a *reg* property. So "@c5004000" is not needed.
> > > This comment applies to all the nodes which doesn't have *reg* property.
> >
> > Thanks Kishon for the comments.
> > As I've 3 usb-phy DT nodes, how to differentiate between them if I remove
> this @Address ?
>
> then add reg property :-)
Thanks Felipe, for confirming.
>
> --
> balbi
>
> * Unknown Key
> * 0x35CAA444
--
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 7/7] usb: phy: registering tegra USB PHY as platform driver
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, March 20, 2013 1:51 AM
> To: Venu Byravarasu
> Cc: gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-te...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org
> Subject: Re: [PATCH 7/7] usb: phy: registering tegra USB PHY as platform
> driver
>
> On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
> > Registered tegra USB PHY as a separate platform driver.
> >
> > diff --git a/drivers/usb/phy/tegra_usb_phy.c
> b/drivers/usb/phy/tegra_usb_phy.c
>
> > static void tegra_usb_phy_close(struct usb_phy *x)
> > {
> > if (phy->is_ulpi_phy)
> > clk_put(phy->clk);
>
> phy->clk is obtained using devm_clk_get(). This typically means you
> never need to clk_put() it, and if for some reason you really have to,
> you should use devm_clk_put() instead of plain clk_put().
Agree, will remove clk_put.
>
> > @@ -774,23 +667,53 @@ struct tegra_usb_phy
> *tegra_usb_phy_open(struct device *dev, int instance,
>
> > + err = gpio_request(phy->reset_gpio, "ulpi_phy_reset_b");
>
> I think you can use devm_gpio_request() here to simplify the error-handling.
Sure, will do.
>
> I wonder why in the ULPI case, all the code is inline here, whereas in
> the UTMI case, this simply calls a function. Wouldn't it be more
> consistent to have the following code here:
>
> if (phy->is_ulpi_phy)
> err = ulpi_open();
> else
> err = utmip_open();
> if (err)
> goto fail;
Sure, will take care of this in next patch.
>
> > +static int tegra_usb_phy_probe(struct platform_device *pdev)
>
> Hmmm. Note that in order to make deferred probe work correctly, all the
> gpio_request(), clk_get(), etc. calls that acquire resources from other
> drivers must happen here in probe() and not in tegra_usb_phy_open().
In present code tegra_usb_phy_open() is indirectly called via usb_phy_init()
from ehci-tegra.c.
Between obtaining PHY handle (and hence getting into deferred probe, when it is
not available)
and calling usb_phy_init, no other USB registers were accessed. Hence I was
doing this way.
Do you still think it would be better to move gpio and clk APIs to probe?
>
> > + err = of_property_match_string(np, "dr_mode", "otg");
> > + if (err < 0) {
> > + err = of_property_match_string(np, "dr_mode", "gadget");
>
> Again, use "peripheral", not "gadget".
Will do.
>
> > +struct usb_phy *tegra_usb_get_phy(struct device_node *dn)
> > +{
> > + struct device *dev;
> > + struct tegra_usb_phy *tegra_phy;
> > +
> > + dev = driver_find_device(&tegra_usb_phy_driver.driver, NULL, dn,
> > +tegra_usb_phy_match);
> > + if (!dev)
> > + return ERR_PTR(-EPROBE_DEFER);
> > +
> > + tegra_phy = dev_get_drvdata(dev);
> > +
> > + return &tegra_phy->u_phy;
> > +}
>
> I think you need a module_get() somewhere in there, and also need to add
> a tegra_usb_put_phy() function too, so you can call module_put() from it.
Am not clear on why to add module_get here. Can you plz provide more details?
Thanks Stephen, for the review.
--
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: phy: gpio-vbus: don't ignore regulator APIs return value
On Wed, Mar 20, 2013 at 01:27:28PM +0100, Mark Brown wrote: > On Wed, Mar 20, 2013 at 02:21:15PM +0200, Felipe Balbi wrote: > > > Do I get an Acked-by to carry on ? > > Sure if you like, I didn't think you needed one. fair enough, not necessary. I'll carry this one. cheers -- balbi signature.asc Description: Digital signature
[PATCH v2] USB: usb-skeleton.c: fix blocked forever in skel_read
From: Du Xing duxing2...@gmail.com
In skel_read,the reader blocked in wait_for_completion before submit bulk in
urb.
Using processed_urb is for retaining the completion in the case that
previous interruptible wait in skel_read was interrupted and complete before
next skel_read.
Replacing completion with waitqueue can avoid working around the counting
nature of completions
and fix the bug.
---
Signed-off-by: Du Xing duxing2...@gmail.com
---
diff --git a/drivers/usb/usb-skeleton.c b/drivers/usb/usb-skeleton.c
index ce31017..7ed3b03 100644
--- a/drivers/usb/usb-skeleton.c
+++ b/drivers/usb/usb-skeleton.c
@@ -61,11 +61,10 @@ struct usb_skel {
__u8bulk_out_endpointAddr; /* the address of the
bulk out endpoint */
int errors; /* the last request
tanked */
boolongoing_read; /* a read is going on */
- boolprocessed_urb; /* indicates we haven't
processed the urb */
spinlock_t err_lock; /* lock for errors */
struct kref kref;
struct mutexio_mutex; /* synchronize I/O with
disconnect */
- struct completion bulk_in_completion; /* to wait for an
ongoing read */
+ wait_queue_head_t bulk_in_wait; /* to wait for an
ongoing read */
};
#define to_skel_dev(d) container_of(d, struct usb_skel, kref)
@@ -185,7 +184,7 @@ static void skel_read_bulk_callback(struct urb *urb)
dev->ongoing_read = 0;
spin_unlock(&dev->err_lock);
- complete(&dev->bulk_in_completion);
+ wake_up_interruptible(&dev->bulk_in_wait);
}
static int skel_do_read_io(struct usb_skel *dev, size_t count)
@@ -206,13 +205,16 @@ static int skel_do_read_io(struct usb_skel *dev, size_t
count)
dev->ongoing_read = 1;
spin_unlock_irq(&dev->err_lock);
+ /* submit bulk in urb, which means no data to deliver */
+ dev->bulk_in_filled = 0;
+ dev->bulk_in_copied = 0;
+
/* do it */
rv = usb_submit_urb(dev->bulk_in_urb, GFP_KERNEL);
if (rv < 0) {
dev_err(&dev->interface->dev,
"%s - failed submitting read urb, error %d\n",
__func__, rv);
- dev->bulk_in_filled = 0;
rv = (rv == -ENOMEM) ? rv : -EIO;
spin_lock_irq(&dev->err_lock);
dev->ongoing_read = 0;
@@ -261,25 +263,9 @@ retry:
* IO may take forever
* hence wait in an interruptible state
*/
- rv =
wait_for_completion_interruptible(&dev->bulk_in_completion);
+ rv = wait_event_interruptible(dev->bulk_in_wait,
(!dev->ongoing_read));
if (rv < 0)
goto exit;
- /*
-* by waiting we also semiprocessed the urb
-* we must finish now
-*/
- dev->bulk_in_copied = 0;
- dev->processed_urb = 1;
- }
-
- if (!dev->processed_urb) {
- /*
-* the URB hasn't been processed
-* do it now
-*/
- wait_for_completion(&dev->bulk_in_completion);
- dev->bulk_in_copied = 0;
- dev->processed_urb = 1;
}
/* errors must be reported */
@@ -289,8 +275,6 @@ retry:
dev->errors = 0;
/* to preserve notifications about reset */
rv = (rv == -EPIPE) ? rv : -EIO;
- /* no data to deliver */
- dev->bulk_in_filled = 0;
/* report it */
goto exit;
}
@@ -526,7 +510,7 @@ static int skel_probe(struct usb_interface *interface,
mutex_init(&dev->io_mutex);
spin_lock_init(&dev->err_lock);
init_usb_anchor(&dev->submitted);
- init_completion(&dev->bulk_in_completion);
+ init_waitqueue_head(&dev->bulk_in_wait);
dev->udev = usb_get_dev(interface_to_usbdev(interface));
dev->interface = interface;
---
--
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 PATCHv2 1/1] usb: f_rndis: Avoid to use ERROR macro if cdev can be null
On Tue, Mar 19, 2013 at 02:22:56PM +0100, Michal Nazarewicz wrote: > On Tue, Mar 19 2013, oskar.and...@sonymobile.com wrote: > > The udc_irq service runs the isr_tr_complete_handler which in turn > > "nukes" the endpoints, including a call to rndis_response_complete, > > if appropriate. If the rndis_msg_parser fails here, an error will > > be printed using a dev_err call (through the ERROR() macro). > > > > However, if the usb cable was just disconnected the device (cdev) > > might not be available and will be null. Since the dev_err macro will > > dereference the cdev pointer we get a null pointer exception. > > > > Reviewed-by: Radovan Lekanovic > > Signed-off-by: Truls Bengtsson > > Signed-off-by: Oskar Andero > > Acked-by: Michal Nazarewicz > > I think this is the best solution. Adding if statements around it would > just add noise. alright, please re-send without RFC tag and with Michal's acked-by so I can apply. -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 0/7] usb: phy: twl4030-usb fixes
On Sun, Mar 17, 2013 at 08:23:20PM +0200, Grazvydas Ignotas wrote:
> I have a pandora board which has similar musb setup to beagleboard
> (OMAP3530 + TWL4030) and musb never worked well on it for me in mainline.
> Well it usually works if you plug the cable once, but as soon as you start
> replugging cables and mixing host adapter into the game it totally breaks
> and reboot is then needed. Host mode is especially broken, any replugs
> after musb has been in host mode result in dead port that needs reboot
> to recover.
>
> With this series I can switch host/peripheral cables any way I like and
> even suspend works with cable plugged with musb in peripheral mode!
> ("ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb" is
> needed that was sent separately). This also fixes power drain when cable
> is plugged an no gadget driver is loaded.
>
> Changed since v1:
> - rebased on Felipe's testing branch
> - added locking for patch 4 to take care of possible races
> between work item and IRQ
> - changed patch 6 to only disable VBUS if not runtime suspended,
> otherwise we get data abort on OMAP3
>
> Grazvydas Ignotas (7):
> usb: phy: twl4030-usb: don't enable PHY during init
> usb: phy: twl4030-usb: ignore duplicate events
> usb: phy: twl4030-usb: don't switch the phy on/off needlessly
> usb: phy: twl4030-usb: poll for ID disconnect
> usb: phy: twl4030-usb: check if vbus is driven by twl itself
> usb: musb: omap2430: turn off vbus on cable disconnect
> usb: musb: gadget: use platform callback to enable vbus
since this falls into "has never worked before" I will apply them for
v3.10. If you have any objections, let me know.
--
balbi
signature.asc
Description: Digital signature
[PATCHv2] usb: f_rndis: Avoid to use ERROR macro if cdev can be null
From: Truls Bengtsson
The udc_irq service runs the isr_tr_complete_handler which in turn
"nukes" the endpoints, including a call to rndis_response_complete,
if appropriate. If the rndis_msg_parser fails here, an error will
be printed using a dev_err call (through the ERROR() macro).
However, if the usb cable was just disconnected the device (cdev)
might not be available and will be null. Since the dev_err macro will
dereference the cdev pointer we get a null pointer exception.
Reviewed-by: Radovan Lekanovic
Signed-off-by: Truls Bengtsson
Signed-off-by: Oskar Andero
Acked-by: Michal Nazarewicz
---
drivers/usb/gadget/f_rndis.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index 71beeb8..cc9c49c 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -447,14 +447,13 @@ static void rndis_response_complete(struct usb_ep *ep,
struct usb_request *req)
static void rndis_command_complete(struct usb_ep *ep, struct usb_request *req)
{
struct f_rndis *rndis = req->context;
- struct usb_composite_dev*cdev = rndis->port.func.config->cdev;
int status;
/* received RNDIS command from USB_CDC_SEND_ENCAPSULATED_COMMAND */
// spin_lock(&dev->lock);
status = rndis_msg_parser(rndis->config, (u8 *) req->buf);
if (status < 0)
- ERROR(cdev, "RNDIS command error %d, %d/%d\n",
+ pr_err("RNDIS command error %d, %d/%d\n",
status, req->actual, req->length);
// spin_unlock(&dev->lock);
}
--
1.7.8.6
--
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: [PATCHv2 5/7] usb: phy: twl4030-usb: check if vbus is driven by twl itself
On Sun, Mar 17, 2013 at 08:23:25PM +0200, Grazvydas Ignotas wrote:
> At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
> itself. Reporting VBUS in this case confuses OMAP musb glue and charger
> driver, so check if OTG VBUS charge pump is on before reporting VBUS
> event to avoid this problem.
>
> Signed-off-by: Grazvydas Ignotas
> ---
> drivers/usb/phy/phy-twl4030-usb.c | 36 +++-
> 1 file changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> b/drivers/usb/phy/phy-twl4030-usb.c
> index 425c18a..87bf11d 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -248,11 +248,31 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg,
> u8 bits)
>
> /*-*/
>
> +static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
> +{
> + int ret;
> +
> + ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
> + if (ret < 0 || !(ret & PHY_DPLL_CLK))
> + /*
> + * if clocks are off, registers are not updated,
> + * but we can assume we don't drive VBUS in this case
> + */
> + return false;
> +
> + ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
> + if (ret < 0)
> + return false;
> +
> + return (ret & (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
> +}
> +
> static enum omap_musb_vbus_id_status
> twl4030_usb_linkstat(struct twl4030_usb *twl)
> {
> int status;
> enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
> + booldriving_vbus = false;
>
> twl->vbus_supplied = false;
>
> @@ -270,20 +290,26 @@ static enum omap_musb_vbus_id_status
> if (status < 0)
> dev_err(twl->dev, "USB link status err %d\n", status);
> else if (status & (BIT(7) | BIT(2))) {
> - if (status & (BIT(7)))
> -twl->vbus_supplied = true;
> + if (status & BIT(7)) {
> + driving_vbus = twl4030_is_driving_vbus(twl);
> + if (driving_vbus)
how about just:
if (twl4030_is_driving_vbus(twl))
status &= ~BIT(7);
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2 0/7] usb: phy: twl4030-usb fixes
On Wed, Mar 20, 2013 at 02:54:25PM +0200, Felipe Balbi wrote:
> On Sun, Mar 17, 2013 at 08:23:20PM +0200, Grazvydas Ignotas wrote:
> > I have a pandora board which has similar musb setup to beagleboard
> > (OMAP3530 + TWL4030) and musb never worked well on it for me in mainline.
> > Well it usually works if you plug the cable once, but as soon as you start
> > replugging cables and mixing host adapter into the game it totally breaks
> > and reboot is then needed. Host mode is especially broken, any replugs
> > after musb has been in host mode result in dead port that needs reboot
> > to recover.
> >
> > With this series I can switch host/peripheral cables any way I like and
> > even suspend works with cable plugged with musb in peripheral mode!
> > ("ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb" is
> > needed that was sent separately). This also fixes power drain when cable
> > is plugged an no gadget driver is loaded.
> >
> > Changed since v1:
> > - rebased on Felipe's testing branch
> > - added locking for patch 4 to take care of possible races
> > between work item and IRQ
> > - changed patch 6 to only disable VBUS if not runtime suspended,
> > otherwise we get data abort on OMAP3
> >
> > Grazvydas Ignotas (7):
> > usb: phy: twl4030-usb: don't enable PHY during init
> > usb: phy: twl4030-usb: ignore duplicate events
> > usb: phy: twl4030-usb: don't switch the phy on/off needlessly
> > usb: phy: twl4030-usb: poll for ID disconnect
> > usb: phy: twl4030-usb: check if vbus is driven by twl itself
> > usb: musb: omap2430: turn off vbus on cable disconnect
> > usb: musb: gadget: use platform callback to enable vbus
>
> since this falls into "has never worked before" I will apply them for
> v3.10. If you have any objections, let me know.
I have applied up to 'poll for ID disconnect'. Please rebase the others
against my 'testing' branch once you update based on my comments.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/6] usb: otg: mv_otg: remove unused clock
On Mon, Mar 18, 2013 at 03:55:29AM -0400, Chao Xie wrote: > The origianl understanding of clock is wrong. The OTG controller > only have one clock input. > Passing clock name by pdata is wrong. The clock is defined by device > iteself. > > Signed-off-by: Chao Xie please rebase against my 'next' branch. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] usb: musb/otg: cleanup and fixes
On Wed, Mar 13, 2013 at 02:17:05PM +0530, Kishon Vijay Abraham I wrote: > This series has some misc cleanup and fixes. The fix solves the cold > plug issue in omap3 which some have reported. Developed these patches on > Linux 3.9-rc2 after applying > http://www.spinics.net/lists/linux-usb/msg81563.html > (Grazvydas Ignotas patch series) > > Tested for g_zero enumeration in pandaboard and beagleboard in both > cold plug and hot plug case. Any kind of testing for this series is welcome. > > Kishon Vijay Abraham I (5): > usb: musb: omap: remove the check before calling otg_set_vbus > usb: musb: omap: always glue have the correct vbus/id status > usb: otg: twl4030: use devres API for regulator get and request irq > usb: musb: omap: add usb_phy_init in omap2430_musb_init > usb: otg: twl4030: fix cold plug on OMAP3 > > drivers/usb/musb/omap2430.c | 22 ++ > drivers/usb/otg/twl4030-usb.c | 35 --- > 2 files changed, 22 insertions(+), 35 deletions(-) this needs to be rebased against my 'next' branch. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb host: Faraday FUSBH200 HCD driver.
Hi, On Tue, Mar 19, 2013 at 11:48 PM, Alan Stern wrote: > On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote: > >> > What about the port_status registers? They're not between command and >> > async_next. If they aren't consistent with EHCI, it makes things a lot >> > more complicated. >> >> fusbh200 has only one port_status register with different offset, >> 0x30, and the position of some bits are different from EHCI. How about adding kernel configuration to adjust offset for FUSBH200 in ehci_def.h? So port_status would be in offset 0x20 from ehci_regs. For example, /* ASYNCLISTADDR: offset 0x18 */ u32 async_next; /* address of next async queue head */ #ifndef CONFIG_USB_EHCI_HCD_FUSBH200 u32 reserved1[2]; /* TXFILLTUNING: offset 0x24 */ u32 txfill_tuning; /* TX FIFO Tuning register */ #define TXFIFO_DEFAULT (8<<16) /* FIFO burst threshold 8 */ u32 reserved2[6]; /* CONFIGFLAG: offset 0x40 */ u32 configured_flag; #define FLAG_CF (1<<0) /* true: we'll support "high speed" */ #else u32 reserved1; #endif /* PORTSC: offset 0x44 */ u32 port_status[0]; /* up to N_PORTS */ Furthermore, there are PORT_POWER, PORT_OWNER, PORT_LED_XXX, PORT_TEST, PORT_WKCONN_E, PORT_WKDISC_E, PORT_WKOC_E absent in port_status of FUSBH200. Also PORT_OC and PORT_OCC are in another register. Is it ok to use quirk flag also? > > That's pretty nasty. Integrating that with the standard EHCI driver > would be considerably more difficult. > > Why was the FUSBH200 designed in this strange way? Why doesn't it use > the standard EHCI register layout? Were the engineers at Faraday > deliberately trying to make life harder for driver writers? > >> Also, usbmode_ex, hostpc, and txfill_tuning other than configured_flag >> are non-existent in fusbh200. They are used in both ehci-hcd.c and >> ehci-hub.c for several times. > > They are used only if the hardware supports them, that is, only if the > ehci->has_hostpc flag is set. > > Alan Stern > Thank you for your help. Yuan-Hsin -- 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: Two remain problems at chipidea driver
Marc Kleine-Budde writes: > On 03/20/2013 12:23 PM, Alexander Shishkin wrote: >> Marc Kleine-Budde writes: >> >>> On 03/20/2013 12:04 PM, Alexander Shishkin wrote: Peter Chen writes: > On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: >> >>> Eg, for tablet or phone, the dr_mode may be "gadget", but the >>> otg_capable = 1. >> >> No, because dr_mode indicates controller's capability, and not the >> "current" mode of operation. Why would anyone want to put *that* in a >> DT? >> > > OK, now I totally understand your mind of this problem. In fact, dr_mode > is NOT controller's capability, even at its original place: > (Documentation/devicetree/bindings/usb/fsl-usb.txt or nvidia, > tegra20-ehci.txt) > dr_mode is the usb working mode. > > When we design USB system, the requirements are differ from products > to products. > The phone/tablet device may only wants itself as gadget > device, it needs to be no-response when there is a usb device plug in > (eg usb keyboard with Micro B-to-A cable). > > The car entertainment system or other Standard-A port system do not want > to be enumerated when it plugs to notebook using Standard A-to-A cable. Bah. Of course, you're right. We're stuck with dr_mode till people learn to design middleware stacks that can handle being both host and peripheral. > So, currently, even most of controllers are otg-capable, still most > of designs are one working mode designed. The reason why we design > the dr_mode is that we want controller working mode to be decided > by DT without re-compile the kernel by build out the host/gadget driver. Ok, so then how about introducing *one* more parameter, something like "dr_cap", which 1) when specified, supersedes DCCPARAMS, so no need to read that register any more; 2) when unspecified, use DCCPARAMS; 3) can be one of "host", "peripheral", "otg", "dual_role": - host, peripheral: initialize one role only, stick to that, no otg; - dual_role: initialize both roles, no otg; - otg: both roles, ci->is_otg == true. Another question now is, do we need "dual_role" variant for the dr_mode parameter? >>> >>> What's the difference between the newly proposed dr_cap and the dr_mode >>> parameter? >> >> See the discussion above. >> >> dr_cap is what the device can actually do (host, peripheral, etc). Tells >> us which roles to initialize and wether we can access OTGSC on this >> device. >> dr_mode is what function of the device we'll be using on this particular >> board. > > Sorry, I don't get why the driver needs to know what the chipidea can do > in theory (dr_cap). IMHO it should be sufficient to tell the driver what > that exact hardware it runs on can do (dr_mode). What the hardware can > do depends on the actual chipidea implementation used in that SoC and > the board the SoC is soldered on. Again, see the discussion above. In real world products (that is, phones and tablets as opposed to jolly fun development boards), vendors will want to limit the usb functionality to peripheral only or host only or whatever, because the middleware stack can only do one thing or because they don't want to go through with otg certification or you name it. Meanwhile, the controller and the whole device can still support otg. And we need to know that if we're to try to detect vbus session, because that is done via OTGSC which is only available in otg configurations. The alternative is to have N more platform tweaks for * dccparams_is_borked, * otgsc_is_borked, and a lot of luck trying to get that right in the probe(). This is, of course a preferred approach for anyone who supports phandle creep in DT. I don't like either approach, but the former seems a tad less damaging. Regards, -- Alex -- 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] usb: ulpi: Define a *otg_ulpi_create no-op
From: Fabio Estevam
Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled, results
in the following error:
arch/arm/mach-imx/built-in.o: In function 'pca100_init':
platform-mx2-emma.c:(.init.text+0x6788): undefined reference to
'otg_ulpi_create'
platform-mx2-emma.c:(.init.text+0x682c): undefined reference to
'mxc_ulpi_access_ops'
Fix this by providing a no-op definition of *otg_ulpi_create for the case when
CONFIG_USB_ULPI is not defined.
Signed-off-by: Fabio Estevam
---
include/linux/usb/ulpi.h |8
1 file changed, 8 insertions(+)
diff --git a/include/linux/usb/ulpi.h b/include/linux/usb/ulpi.h
index 6f033a4..5c295c2 100644
--- a/include/linux/usb/ulpi.h
+++ b/include/linux/usb/ulpi.h
@@ -181,8 +181,16 @@
/*-*/
+#if IS_ENABLED(CONFIG_USB_ULPI)
struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
unsigned int flags);
+#else
+static inline struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
+ unsigned int flags)
+{
+ return NULL;
+}
+#endif
#ifdef CONFIG_USB_ULPI_VIEWPORT
/* access ops for controllers with a viewport register */
--
1.7.9.5
--
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: Two remain problems at chipidea driver
Hi, On Wed, Mar 20, 2013 at 03:37:01PM +0200, Alexander Shishkin wrote: > >> dr_cap is what the device can actually do (host, peripheral, etc). Tells > >> us which roles to initialize and wether we can access OTGSC on this > >> device. > >> dr_mode is what function of the device we'll be using on this particular > >> board. > > > > Sorry, I don't get why the driver needs to know what the chipidea can do > > in theory (dr_cap). IMHO it should be sufficient to tell the driver what > > that exact hardware it runs on can do (dr_mode). What the hardware can > > do depends on the actual chipidea implementation used in that SoC and > > the board the SoC is soldered on. > > Again, see the discussion above. > > In real world products (that is, phones and tablets as opposed to jolly > fun development boards), vendors will want to limit the usb > functionality to peripheral only or host only or whatever, because the > middleware stack can only do one thing or because they don't want to go > through with otg certification or you name it. Meanwhile, the controller that's not entirely true. A manufacturer can decide to skip OTG certification but still support Dual Role. Look at the whole Android Accessory Kit, for example. > and the whole device can still support otg. And we need to know that if > we're to try to detect vbus session, because that is done via OTGSC > which is only available in otg configurations. well, if it's only available in OTG configurations, then you make the same assumption in driver. If driver was compiled with OTG, you check OTGSC; otherwise don't. > The alternative is to have N more platform tweaks for > * dccparams_is_borked, > * otgsc_is_borked, > and a lot of luck trying to get that right in the probe(). This is, of > course a preferred approach for anyone who supports phandle creep in > DT. right, that'll look odd :-s -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: net22xx: fix ->disconnect reporting
On Mon, Mar 18, 2013 at 02:41:11PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 18-03-2013 12:19, Felipe Balbi wrote:
>
> >with the latest udc_start/udc_stop conversion,
> >too much code was deleted which ended up creating
> >a regression in net2272 and net2280 drivers.
>
> >To fix the regression we revert one hunk of the
> >original commits.
>
> >Signed-off-by: Felipe Balbi
> >---
> > drivers/usb/gadget/net2272.c | 7 +++
> > drivers/usb/gadget/net2280.c | 7 +++
> > 2 files changed, 14 insertions(+)
>
> [...]
> >diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
> >index a1b650e..3665e5e 100644
> >--- a/drivers/usb/gadget/net2280.c
> >+++ b/drivers/usb/gadget/net2280.c
> >@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
> >usb_gadget_driver *driver)
> > for (i = 0; i < 7; i++)
> > nuke (&dev->ep [i]);
> >
> >+/* report disconnect; the driver is already quiesced */
> >+if (driver) {
> >+spin_unlock (&dev->lock);
> >+driver->disconnect (&dev->gadget);
> >+spin_lock (&dev->lock);
>
>Spaces befere ( not allowed by scripts/checkpatch.pl.
Thanks, I have fixed it in the branch, here's newer version:
commit c934fb9e86332e596b571954171a238bf7c93561
Author: Felipe Balbi
Date: Mon Mar 18 10:14:47 2013 +0200
usb: gadget: net22xx: fix ->disconnect reporting
with the latest udc_start/udc_stop conversion,
too much code was deleted which ended up creating
a regression in net2272 and net2280 drivers.
To fix the regression we revert one hunk of the
original commits.
Signed-off-by: Felipe Balbi
diff --git a/drivers/usb/gadget/net2272.c b/drivers/usb/gadget/net2272.c
index d226058..17628337 100644
--- a/drivers/usb/gadget/net2272.c
+++ b/drivers/usb/gadget/net2272.c
@@ -1495,6 +1495,13 @@ stop_activity(struct net2272 *dev, struct
usb_gadget_driver *driver)
for (i = 0; i < 4; ++i)
net2272_dequeue_all(&dev->ep[i]);
+ /* report disconnect; the driver is already quiesced */
+ if (driver) {
+ spin_unlock(&dev->lock);
+ driver->disconnect(&dev->gadget);
+ spin_lock(&dev->lock);
+ }
+
net2272_usb_reinit(dev);
}
diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
index a1b650e..3665e5e 100644
--- a/drivers/usb/gadget/net2280.c
+++ b/drivers/usb/gadget/net2280.c
@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
usb_gadget_driver *driver)
for (i = 0; i < 7; i++)
nuke (&dev->ep [i]);
+ /* report disconnect; the driver is already quiesced */
+ if (driver) {
+ spin_unlock (&dev->lock);
+ driver->disconnect (&dev->gadget);
+ spin_lock (&dev->lock);
+ }
+
usb_reinit (dev);
}
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: gadget: net22xx: fix ->disconnect reporting
Hello.
On 20-03-2013 17:55, Felipe Balbi wrote:
with the latest udc_start/udc_stop conversion,
too much code was deleted which ended up creating
a regression in net2272 and net2280 drivers.
To fix the regression we revert one hunk of the
original commits.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/net2272.c | 7 +++
drivers/usb/gadget/net2280.c | 7 +++
2 files changed, 14 insertions(+)
[...]
diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
index a1b650e..3665e5e 100644
--- a/drivers/usb/gadget/net2280.c
+++ b/drivers/usb/gadget/net2280.c
@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
usb_gadget_driver *driver)
for (i = 0; i < 7; i++)
nuke (&dev->ep [i]);
+ /* report disconnect; the driver is already quiesced */
+ if (driver) {
+ spin_unlock (&dev->lock);
+ driver->disconnect (&dev->gadget);
+ spin_lock (&dev->lock);
Spaces befere ( not allowed by scripts/checkpatch.pl.
Thanks, I have fixed it in the branch, here's newer version:
commit c934fb9e86332e596b571954171a238bf7c93561
Author: Felipe Balbi
Date: Mon Mar 18 10:14:47 2013 +0200
usb: gadget: net22xx: fix ->disconnect reporting
with the latest udc_start/udc_stop conversion,
too much code was deleted which ended up creating
a regression in net2272 and net2280 drivers.
To fix the regression we revert one hunk of the
original commits.
Signed-off-by: Felipe Balbi
[...]
diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
index a1b650e..3665e5e 100644
--- a/drivers/usb/gadget/net2280.c
+++ b/drivers/usb/gadget/net2280.c
@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
usb_gadget_driver *driver)
for (i = 0; i < 7; i++)
nuke (&dev->ep [i]);
+ /* report disconnect; the driver is already quiesced */
+ if (driver) {
+ spin_unlock (&dev->lock);
+ driver->disconnect (&dev->gadget);
+ spin_lock (&dev->lock);
Frankly speaking, I don't see any changes. :-P
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
What driver for generic bulk to tty?
Hi, What is recomended driver to use for a USB device that provides just 2 bulk end-points, in and out, to create a TTY to talk to it? Exact data formats that are used are application-specific, so only generic IO TTY-alike device (with no control) is required from the kernel. Searching through the lists and Internet uncovered multiple posts of why "usbserial" is a wrong driver for this purpose, but nowhere did I find what the right alternative is. -- 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] usb: ulpi: Define a *otg_ulpi_create no-op
On 03/20/13 15:35, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled,
> results
> in the following error:
>
> arch/arm/mach-imx/built-in.o: In function 'pca100_init':
> platform-mx2-emma.c:(.init.text+0x6788): undefined reference to
> 'otg_ulpi_create'
> platform-mx2-emma.c:(.init.text+0x682c): undefined reference to
> 'mxc_ulpi_access_ops'
Is this patch fixes both undefined references?
It does not look so..
If it fixes only the first one, I would suggest adjusting the commit message.
>
> Fix this by providing a no-op definition of *otg_ulpi_create for the case
> when
> CONFIG_USB_ULPI is not defined.
>
> Signed-off-by: Fabio Estevam
> ---
> include/linux/usb/ulpi.h |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/usb/ulpi.h b/include/linux/usb/ulpi.h
> index 6f033a4..5c295c2 100644
> --- a/include/linux/usb/ulpi.h
> +++ b/include/linux/usb/ulpi.h
> @@ -181,8 +181,16 @@
>
> /*-*/
>
> +#if IS_ENABLED(CONFIG_USB_ULPI)
> struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
> unsigned int flags);
> +#else
> +static inline struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
> + unsigned int flags)
> +{
> + return NULL;
Would ERR_PTR(-ENXIO) do better here?
> +}
> +#endif
>
> #ifdef CONFIG_USB_ULPI_VIEWPORT
> /* access ops for controllers with a viewport register */
>
--
Regards,
Igor.
--
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: What driver for generic bulk to tty?
Hi, what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually the chips are either FTDI or something similar, and then ftdi driver should work (coupled with right parameters for "unsuported" IDs - you can then propose patch once you will see the device working). Hope this helps Petr On Wed, 20 Mar 2013 17:47:18 +0400, Sergei Organov wrote: Hi, What is recomended driver to use for a USB device that provides just 2 bulk end-points, in and out, to create a TTY to talk to it? Exact data formats that are used are application-specific, so only generic IO TTY-alike device (with no control) is required from the kernel. Searching through the lists and Internet uncovered multiple posts of why "usbserial" is a wrong driver for this purpose, but nowhere did I find what the right alternative is. -- 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: Linux USB file storage gadget with new UDC
On Wed, 20 Mar 2013, victor yeo wrote: > Thanks, i add processing the pending data from FIFO after queue was > called. The UDC driver can process the SCSI INQUIRY command and SCSI > READ FORMAT CAPACITIES command now. > > In the processing of SCSI READ FORMAT CAPACITIES command, there is > attention condition. Then the bulk transfer stops completely and > control transfer is repeated. What control transfer? > How can i solve it? First you have to figure out why it isn't working. What does the debugging information show? 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: Two remain problems at chipidea driver
Felipe Balbi writes: > Hi, > > On Wed, Mar 20, 2013 at 03:37:01PM +0200, Alexander Shishkin wrote: >> >> dr_cap is what the device can actually do (host, peripheral, etc). Tells >> >> us which roles to initialize and wether we can access OTGSC on this >> >> device. >> >> dr_mode is what function of the device we'll be using on this particular >> >> board. >> > >> > Sorry, I don't get why the driver needs to know what the chipidea can do >> > in theory (dr_cap). IMHO it should be sufficient to tell the driver what >> > that exact hardware it runs on can do (dr_mode). What the hardware can >> > do depends on the actual chipidea implementation used in that SoC and >> > the board the SoC is soldered on. >> >> Again, see the discussion above. >> >> In real world products (that is, phones and tablets as opposed to jolly >> fun development boards), vendors will want to limit the usb >> functionality to peripheral only or host only or whatever, because the >> middleware stack can only do one thing or because they don't want to go >> through with otg certification or you name it. Meanwhile, the controller > > that's not entirely true. A manufacturer can decide to skip OTG > certification but still support Dual Role. Look at the whole Android > Accessory Kit, for example. Sure, I was just making an example of how device capabilities can differ from device's intended function. >> and the whole device can still support otg. And we need to know that if >> we're to try to detect vbus session, because that is done via OTGSC >> which is only available in otg configurations. > > well, if it's only available in OTG configurations, then you make the > same assumption in driver. If driver was compiled with OTG, you check > OTGSC; otherwise don't. I'd kind of like to support different configurations in runtime and have as few compilation options as possible. Of course, if it means extra spaghetti, there's a trade off right there. Regards, -- Alex -- 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 host: Faraday FUSBH200 HCD driver.
On Wed, 20 Mar 2013, Yuan-Hsin Chen wrote: > Hi, > > On Tue, Mar 19, 2013 at 11:48 PM, Alan Stern > wrote: > > On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote: > > > >> > What about the port_status registers? They're not between command and > >> > async_next. If they aren't consistent with EHCI, it makes things a lot > >> > more complicated. > >> > >> fusbh200 has only one port_status register with different offset, > >> 0x30, and the position of some bits are different from EHCI. > > How about adding kernel configuration to adjust offset for FUSBH200 in > ehci_def.h? So port_status would be in offset 0x20 from ehci_regs. > > For example, > > /* ASYNCLISTADDR: offset 0x18 */ > u32 async_next; /* address of next async queue head */ > > #ifndef CONFIG_USB_EHCI_HCD_FUSBH200 > u32 reserved1[2]; > > /* TXFILLTUNING: offset 0x24 */ > u32 txfill_tuning; /* TX FIFO Tuning register */ > #define TXFIFO_DEFAULT (8<<16) /* FIFO burst threshold 8 */ > > u32 reserved2[6]; > > /* CONFIGFLAG: offset 0x40 */ > u32 configured_flag; > #define FLAG_CF (1<<0) /* true: we'll support "high speed" */ > > #else > u32 reserved1; > #endif > /* PORTSC: offset 0x44 */ > u32 port_status[0]; /* up to N_PORTS */ This is acceptable _only_ if it is not possible to use an FUSBH200 controller in the same computer as a normal EHCI controller. > Furthermore, there are PORT_POWER, PORT_OWNER, PORT_LED_XXX, > PORT_TEST, PORT_WKCONN_E, PORT_WKDISC_E, PORT_WKOC_E absent in > port_status of FUSBH200. Also PORT_OC and PORT_OCC are in another > register. Is it ok to use quirk flag also? Yes, those can be handled by a quirk flag. Does the FUSBH200 have a built-in Transaction Translator? 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: Reboot/shutdown failure due to "USB: EHCI: work around silicon bug in Intel's EHCI"
On Tue, 19 Mar 2013, Stephen Warren wrote:
> On 03/19/2013 04:48 PM, Stephen Warren wrote:
> > On 03/19/2013 02:07 PM, Alan Stern wrote:
> ...
> >> A dmesg log with CONFIG_USB_DEBUG enabled would be helpful. We ought
> >> to be able to tell where khubd is getting stuck.
> >
> > Hmmm. Enabling CONFIG_USB_DEBUG appears to mask the problem. I assume
> > this is some kind of timing/race condition, unless there's some code
> > with required side-effects hiding under ifdef CONFIG_USB_DEBUG somehow?
>
> Some further information: I added some printks, which are hopefully
> obvious from the text below, and in the failing case, I see:
>
> > [1.291277] single_unlink_async: qh ee31bc40 qh_state set to UNLINK_WAIT
> > [1.297960] start_iaa_cycle: qh ee31bc40 qh_state changing UNLINK_WAIT
> > -> UNLINK
> ...
> > [6.452331] ehci_urb_dequeue: qh ee31bc40 attempting dequeue (qh_stated
> > 2)
>
> This is with CONFIG_USB_DEBUG disabled. That seems to happen to the very
> first (and only) URB(?) ever issued.
There should be a call to ehci_end_async_unlink shortly after
start_iaa_cycle.
> If I enable CONFIG_USB_DEBUG, then I see the more expected:
>
> > [1.540410] single_unlink_async: qh ee0c0300 qh_state set to UNLINK_WAIT
> > [1.547094] start_iaa_cycle: qh ee0c0300 qh_state changing UNLINK_WAIT
> > -> UNLINK
> > [1.554487] start_iaa_cycle: qh ee0c0300 qh_state was UNLINK; processing
>
> followed by a whole slew of subsequent URBs being submitted and processed.
>
> Perhaps the issue is that start_iaa_cycle() (or whatever triggers it)
> only happens when there's an URB in state UNLINK, but not when there's
> only one in state UNLINK_WAIT, so that it only happens once rather than
> the required twice? I'm not sure why a timing difference would affect
> this though, unless there's some loop in the IAA processing that happens
> to do both the UNLINK_WAIT->UNLINK change, and the processing of the URB
> in the UNLINK state in one invocation sometimes, but not others?
A possible explanation for a timing difference is that the IAA
mechanism simply isn't working right on your controller, so the IAA
watchdog timer expires. It's worth pointing out that your second log
excerpt above has messages spaced at intervals of 7 ms, which is
strange considering that the second line should get printed almost
immediately after the first. Excessively long delays like this do
point in the direction of a timer expiration.
Anyway, there _is_ a mistake in the "work around silicon bug" patch; I
forgot to update the timeout handler. Does the patch below help? You
should build it without CONFIG_USB_DEBUG; I changed the ehci_vdbg to
ehci_info so that it would show up in the log regardless and we can see
if it gets triggered.
(Sven, this patch should replace the one I sent you earlier.)
Alan Stern
Index: 3.8/drivers/usb/host/ehci-timer.c
===
--- 3.8.orig/drivers/usb/host/ehci-timer.c
+++ 3.8/drivers/usb/host/ehci-timer.c
@@ -305,7 +305,8 @@ static void ehci_iaa_watchdog(struct ehc
* (a) SMP races against real IAA firing and retriggering, and
* (b) clean HC shutdown, when IAA watchdog was pending.
*/
- if (ehci->async_iaa) {
+// if (ehci->async_iaa) {
+ if (1) {
u32 cmd, status;
/* If we get here, IAA is *REALLY* late. It's barely
@@ -329,7 +330,7 @@ static void ehci_iaa_watchdog(struct ehc
ehci_writel(ehci, STS_IAA, &ehci->regs->status);
}
- ehci_vdbg(ehci, "IAA watchdog: status %x cmd %x\n",
+ ehci_info(ehci, "IAA watchdog: status %x cmd %x\n",
status, cmd);
end_unlink_async(ehci);
}
--
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: ulpi: Define a *otg_ulpi_create no-op
Hi Igor,
On Wed, Mar 20, 2013 at 11:14 AM, Igor Grinberg wrote:
> On 03/20/13 15:35, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled,
>> results
>> in the following error:
>>
>> arch/arm/mach-imx/built-in.o: In function 'pca100_init':
>> platform-mx2-emma.c:(.init.text+0x6788): undefined reference to
>> 'otg_ulpi_create'
>> platform-mx2-emma.c:(.init.text+0x682c): undefined reference to
>> 'mxc_ulpi_access_ops'
>
> Is this patch fixes both undefined references?
Yes, it fixes both.
> It does not look so..
> If it fixes only the first one, I would suggest adjusting the commit message.
Currently 'mxc_ulpi_access_ops' is defined in
arch/arm/mach-imx/ulpi.c, so if CONFIG_USB_ULPI is unselected the
unreference to 'mxc_ulpi_access_ops' will happen as reported in the
commit log.
If it makes sense I can move 'mxc_ulpi_access_ops' into
arch/arm/mach-imx/ulpi.h or even try to get rid of it and use the
generic otg_ulpi_create instead.
Either way, this should be handled by a different patch.
>> +#if IS_ENABLED(CONFIG_USB_ULPI)
>> struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
>> unsigned int flags);
>> +#else
>> +static inline struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
>> + unsigned int flags)
>> +{
>> + return NULL;
>
> Would ERR_PTR(-ENXIO) do better here?
The real *otg_ulpi_create function returns NULL on errors. Better to
keep the real and no-op version with the same return type, right?
Regards,
Fabio Estevam
--
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: What driver for generic bulk to tty?
OK. Do you know the protocol? User space - use /proc entries. See Apogee CCD driver for an example, or ask me, I might be able to reveal parts of MI CCD driver which does that. Kernel space - see some existing (FTDI,..) drivers and write your own. Petr On Wed, 20 Mar 2013 18:41:41 +0400, Sergei Organov wrote: What is recomended driver to use for a USB device that provides just 2 bulk end-points, in and out, to create a TTY to talk to it? Exact data formats that are used are application-specific, so only generic IO TTY-alike device (with no control) is required from the kernel. Searching through the lists and Internet uncovered multiple posts of why "usbserial" is a wrong driver for this purpose, but nowhere did I find what the right alternative is. what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually the chips are either FTDI or something similar, and then ftdi driver should work (coupled with right parameters for "unsuported" IDs - you can then propose patch once you will see the device working). Thanks, but this is _not_ FTDI or any other widely-known device. It's not usb-to-serial converter or modem of any kind at all. Just a device to which one can talk over 2 USB bulk end-points, and I want to get a TTY to talk to it. Maybe some user-space alternative? -- 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: Two remain problems at chipidea driver
Hi, On Wed, Mar 20, 2013 at 04:26:02PM +0200, Alexander Shishkin wrote: > >> >> dr_cap is what the device can actually do (host, peripheral, etc). Tells > >> >> us which roles to initialize and wether we can access OTGSC on this > >> >> device. > >> >> dr_mode is what function of the device we'll be using on this particular > >> >> board. > >> > > >> > Sorry, I don't get why the driver needs to know what the chipidea can do > >> > in theory (dr_cap). IMHO it should be sufficient to tell the driver what > >> > that exact hardware it runs on can do (dr_mode). What the hardware can > >> > do depends on the actual chipidea implementation used in that SoC and > >> > the board the SoC is soldered on. > >> > >> Again, see the discussion above. > >> > >> In real world products (that is, phones and tablets as opposed to jolly > >> fun development boards), vendors will want to limit the usb > >> functionality to peripheral only or host only or whatever, because the > >> middleware stack can only do one thing or because they don't want to go > >> through with otg certification or you name it. Meanwhile, the controller > > > > that's not entirely true. A manufacturer can decide to skip OTG > > certification but still support Dual Role. Look at the whole Android > > Accessory Kit, for example. > > Sure, I was just making an example of how device capabilities can differ > from device's intended function. > > >> and the whole device can still support otg. And we need to know that if > >> we're to try to detect vbus session, because that is done via OTGSC > >> which is only available in otg configurations. > > > > well, if it's only available in OTG configurations, then you make the > > same assumption in driver. If driver was compiled with OTG, you check > > OTGSC; otherwise don't. > > I'd kind of like to support different configurations in runtime and have > as few compilation options as possible. Of course, if it means extra > spaghetti, there's a trade off right there. right, that's what I did with drivers/usb/dwc3/, it helped cut down ifdeferry to a minimum. But when chromebook with Exynos5 showed up, we _had_ to allow manufacturers to ship the notebook without the peripheral side, since they'd never, ever use it. Since the code was already prepared for that, it was pretty simple and there's no ifdef hell anywhere. Below you will find original commit. The main idea is that, if you want a distro-like kernel, then you always build with everything (DRD), but if you're building a real product, as you said, you may not want to ship both modes unless you're really going to use them. commit 388e5c51135f817f01177c42261f1116a6d7f2ad Author: Vivek Gautam Date: Tue Jan 15 16:09:21 2013 +0530 usb: dwc3: remove dwc3 dependency on host AND gadget. DWC3 controller curretly depends on USB && USB_GADGET. Some hardware may like to use only host feature on dwc3, or only gadget feature. So, removing this dependency of USB_DWC3 on USB and USB_GADGET. Adding the mode of operaiton of DWC3 also here HOST/GADGET/DUAL_ROLE based on which features are enabled. [ ba...@ti.com : . make sure we have default modes for all possible Kernel configurations. . Remove the config -> menuconfig change as it's unnecessary . switch over to IS_ENABLED() ] CC: Doug Anderson Signed-off-by: Vivek Gautam Signed-off-by: Felipe Balbi diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index f6a6e07..77e3f40 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -1,6 +1,6 @@ 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_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD help @@ -12,6 +12,35 @@ config USB_DWC3 if USB_DWC3 +choice + bool "DWC3 Mode Selection" + default USB_DWC3_DUAL_ROLE if (USB && USB_GADGET) + default USB_DWC3_HOST if (USB && !USB_GADGET) + default USB_DWC3_GADGET if (!USB && USB_GADGET) + +config USB_DWC3_HOST + bool "Host only mode" + depends on USB + help + Select this when you want to use DWC3 in host mode only, + thereby the gadget feature will be regressed. + +config USB_DWC3_GADGET + bool "Gadget only mode" + depends on USB_GADGET + help + Select this when you want to use DWC3 in gadget mode only, + thereby the host feature will be regressed. + +config USB_DWC3_DUAL_ROLE + bool "Dual Role mode" + depends on (USB && USB_GADGET) + help + This is the default mode of working of DWC3 controller where + both host and gadget features are enabled. + +endchoice + config USB_DWC3_DEBUG bool "Enable Debugging Messages" help diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile index 4502648..0c7ac92
Re: [PATCH] usb: gadget: net22xx: fix ->disconnect reporting
On Wed, Mar 20, 2013 at 06:04:55PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 20-03-2013 17:55, Felipe Balbi wrote:
>
> >>>with the latest udc_start/udc_stop conversion,
> >>>too much code was deleted which ended up creating
> >>>a regression in net2272 and net2280 drivers.
>
> >>>To fix the regression we revert one hunk of the
> >>>original commits.
>
> >>>Signed-off-by: Felipe Balbi
> >>>---
> >>> drivers/usb/gadget/net2272.c | 7 +++
> >>> drivers/usb/gadget/net2280.c | 7 +++
> >>> 2 files changed, 14 insertions(+)
>
> >>[...]
> >>>diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
> >>>index a1b650e..3665e5e 100644
> >>>--- a/drivers/usb/gadget/net2280.c
> >>>+++ b/drivers/usb/gadget/net2280.c
> >>>@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
> >>>usb_gadget_driver *driver)
> >>> for (i = 0; i < 7; i++)
> >>> nuke (&dev->ep [i]);
> >>>
> >>>+ /* report disconnect; the driver is already quiesced */
> >>>+ if (driver) {
> >>>+ spin_unlock (&dev->lock);
> >>>+ driver->disconnect (&dev->gadget);
> >>>+ spin_lock (&dev->lock);
> >>
> >>Spaces befere ( not allowed by scripts/checkpatch.pl.
>
> >Thanks, I have fixed it in the branch, here's newer version:
>
> >commit c934fb9e86332e596b571954171a238bf7c93561
> >Author: Felipe Balbi
> >Date: Mon Mar 18 10:14:47 2013 +0200
>
> > usb: gadget: net22xx: fix ->disconnect reporting
>
> > with the latest udc_start/udc_stop conversion,
> > too much code was deleted which ended up creating
> > a regression in net2272 and net2280 drivers.
>
> > To fix the regression we revert one hunk of the
> > original commits.
>
> > Signed-off-by: Felipe Balbi
>
> [...]
> >diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
> >index a1b650e..3665e5e 100644
> >--- a/drivers/usb/gadget/net2280.c
> >+++ b/drivers/usb/gadget/net2280.c
> >@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
> >usb_gadget_driver *driver)
> > for (i = 0; i < 7; i++)
> > nuke (&dev->ep [i]);
> >
> >+/* report disconnect; the driver is already quiesced */
> >+if (driver) {
> >+spin_unlock (&dev->lock);
> >+driver->disconnect (&dev->gadget);
> >+spin_lock (&dev->lock);
>
>Frankly speaking, I don't see any changes. :-P
damn, forgot to commit net2280. Thanks
--
balbi
signature.asc
Description: Digital signature
Re: What driver for generic bulk to tty?
>> What is recomended driver to use for a USB device that provides just >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact >> data formats that are used are application-specific, so only generic IO >> TTY-alike device (with no control) is required from the kernel. >> Searching through the lists and Internet uncovered multiple posts of >> why "usbserial" is a wrong driver for this purpose, but nowhere did I >> find what the right alternative is. > what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually > the chips are either FTDI or something similar, and then ftdi driver > should work (coupled with right parameters for "unsuported" IDs - you > can then propose patch once you will see the device working). Thanks, but this is _not_ FTDI or any other widely-known device. It's not usb-to-serial converter or modem of any kind at all. Just a device to which one can talk over 2 USB bulk end-points, and I want to get a TTY to talk to it. Maybe some user-space alternative? -- 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] usb: gadget: net22xx: fix ->disconnect reporting
On Wed, Mar 20, 2013 at 06:04:55PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 20-03-2013 17:55, Felipe Balbi wrote:
>
> >>>with the latest udc_start/udc_stop conversion,
> >>>too much code was deleted which ended up creating
> >>>a regression in net2272 and net2280 drivers.
>
> >>>To fix the regression we revert one hunk of the
> >>>original commits.
>
> >>>Signed-off-by: Felipe Balbi
> >>>---
> >>> drivers/usb/gadget/net2272.c | 7 +++
> >>> drivers/usb/gadget/net2280.c | 7 +++
> >>> 2 files changed, 14 insertions(+)
>
> >>[...]
> >>>diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
> >>>index a1b650e..3665e5e 100644
> >>>--- a/drivers/usb/gadget/net2280.c
> >>>+++ b/drivers/usb/gadget/net2280.c
> >>>@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
> >>>usb_gadget_driver *driver)
> >>> for (i = 0; i < 7; i++)
> >>> nuke (&dev->ep [i]);
> >>>
> >>>+ /* report disconnect; the driver is already quiesced */
> >>>+ if (driver) {
> >>>+ spin_unlock (&dev->lock);
> >>>+ driver->disconnect (&dev->gadget);
> >>>+ spin_lock (&dev->lock);
> >>
> >>Spaces befere ( not allowed by scripts/checkpatch.pl.
>
> >Thanks, I have fixed it in the branch, here's newer version:
>
> >commit c934fb9e86332e596b571954171a238bf7c93561
> >Author: Felipe Balbi
> >Date: Mon Mar 18 10:14:47 2013 +0200
>
> > usb: gadget: net22xx: fix ->disconnect reporting
>
> > with the latest udc_start/udc_stop conversion,
> > too much code was deleted which ended up creating
> > a regression in net2272 and net2280 drivers.
>
> > To fix the regression we revert one hunk of the
> > original commits.
>
> > Signed-off-by: Felipe Balbi
>
> [...]
> >diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
> >index a1b650e..3665e5e 100644
> >--- a/drivers/usb/gadget/net2280.c
> >+++ b/drivers/usb/gadget/net2280.c
> >@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
> >usb_gadget_driver *driver)
> > for (i = 0; i < 7; i++)
> > nuke (&dev->ep [i]);
> >
> >+/* report disconnect; the driver is already quiesced */
> >+if (driver) {
> >+spin_unlock (&dev->lock);
> >+driver->disconnect (&dev->gadget);
> >+spin_lock (&dev->lock);
>
>Frankly speaking, I don't see any changes. :-P
another try:
commit 699412d951e6dd4dec48db88f33dc27b361582f0
Author: Felipe Balbi
Date: Mon Mar 18 10:14:47 2013 +0200
usb: gadget: net22xx: fix ->disconnect reporting
with the latest udc_start/udc_stop conversion,
too much code was deleted which ended up creating
a regression in net2272 and net2280 drivers.
To fix the regression we revert one hunk of the
original commits.
Signed-off-by: Felipe Balbi
diff --git a/drivers/usb/gadget/net2272.c b/drivers/usb/gadget/net2272.c
index d226058..17628337 100644
--- a/drivers/usb/gadget/net2272.c
+++ b/drivers/usb/gadget/net2272.c
@@ -1495,6 +1495,13 @@ stop_activity(struct net2272 *dev, struct
usb_gadget_driver *driver)
for (i = 0; i < 4; ++i)
net2272_dequeue_all(&dev->ep[i]);
+ /* report disconnect; the driver is already quiesced */
+ if (driver) {
+ spin_unlock(&dev->lock);
+ driver->disconnect(&dev->gadget);
+ spin_lock(&dev->lock);
+ }
+
net2272_usb_reinit(dev);
}
diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
index a1b650e..3105a4d 100644
--- a/drivers/usb/gadget/net2280.c
+++ b/drivers/usb/gadget/net2280.c
@@ -1946,6 +1946,13 @@ stop_activity (struct net2280 *dev, struct
usb_gadget_driver *driver)
for (i = 0; i < 7; i++)
nuke (&dev->ep [i]);
+ /* report disconnect; the driver is already quiesced */
+ if (driver) {
+ spin_unlock(&dev->lock);
+ driver->disconnect(&dev->gadget);
+ spin_lock(&dev->lock);
+ }
+
usb_reinit (dev);
}
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: ulpi: Define a *otg_ulpi_create no-op
Hi,
On Wed, Mar 20, 2013 at 11:40:10AM -0300, Fabio Estevam wrote:
> >> +#if IS_ENABLED(CONFIG_USB_ULPI)
> >> struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
> >> unsigned int flags);
> >> +#else
> >> +static inline struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
> >> + unsigned int flags)
> >> +{
> >> + return NULL;
> >
> > Would ERR_PTR(-ENXIO) do better here?
>
> The real *otg_ulpi_create function returns NULL on errors. Better to
> keep the real and no-op version with the same return type, right?
right :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: Make USB persist default configurable
On Tue, 19 Mar 2013, Julius Werner wrote: > > Yes, okay, that's true. If a new USB device is plugged in while the > > lid is shut, and then the lid is opened very briefly, it's possible > > that the system could suspend again before the new device's "persist" > > attribute is updated. Does that case really matter? The device isn't > > likely to be in use at that point. > > It does matter if the device will be used after the next resume, > because that one would use the persist code. If there was a driver > problem it would fail, and if it was a USB stick that is swapped with > a different one of the same model, you could get file system > corruption. To be honest, when it comes to filesystem corruption and lost data, you should be more worried about the consequences of leaving "persist" turned off than of leaving it on. Be that as it may... > I agree with you that buggy drivers should get fixed (and we are > trying to do that as well), but at the same time we want to be able to > have a system that can keep its policies at all times. We get a lot of > USB problems (especially around suspend/resume), and we don't want to > need to worry every time about which code path we hit and whether one > of those race conditions could have something to do with it. I'm > convinced that having this in the kernel is the cleanest solution for > us, and I just thought it might be useful to standardize a mechanism > for that (I don't really see the maintenance burden in that config > option either, as the persist mechanism itself does not look like it > was going to go away anytime soon). If you feel strongly about this, I don't have any real objection to adding the Kconfig option. Practically everyone will leave it in its default state and ignore the whole thing. Alternatively, you could keep the patch out of mainline, as an in-house addition to your own kernels. That would require more effort on your part, though. 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] usb: ulpi: Define a *otg_ulpi_create no-op
On 03/20/13 16:40, Fabio Estevam wrote:
> Hi Igor,
>
> On Wed, Mar 20, 2013 at 11:14 AM, Igor Grinberg
> wrote:
>> On 03/20/13 15:35, Fabio Estevam wrote:
>>> From: Fabio Estevam
>>>
>>> Building a kernel for imx_v4_v5_defconfig with CONFIG_USB_ULPI disabled,
>>> results
>>> in the following error:
>>>
>>> arch/arm/mach-imx/built-in.o: In function 'pca100_init':
>>> platform-mx2-emma.c:(.init.text+0x6788): undefined reference to
>>> 'otg_ulpi_create'
>>> platform-mx2-emma.c:(.init.text+0x682c): undefined reference to
>>> 'mxc_ulpi_access_ops'
>>
>> Is this patch fixes both undefined references?
>
> Yes, it fixes both.
>
>> It does not look so..
>> If it fixes only the first one, I would suggest adjusting the commit message.
>
> Currently 'mxc_ulpi_access_ops' is defined in
> arch/arm/mach-imx/ulpi.c, so if CONFIG_USB_ULPI is unselected the
> unreference to 'mxc_ulpi_access_ops' will happen as reported in the
> commit log.
>
> If it makes sense I can move 'mxc_ulpi_access_ops' into
> arch/arm/mach-imx/ulpi.h or even try to get rid of it and use the
> generic otg_ulpi_create instead.
>
> Either way, this should be handled by a different patch.
>
>>> +#if IS_ENABLED(CONFIG_USB_ULPI)
>>> struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
>>> unsigned int flags);
>>> +#else
>>> +static inline struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
>>> + unsigned int flags)
>>> +{
>>> + return NULL;
>>
>> Would ERR_PTR(-ENXIO) do better here?
>
> The real *otg_ulpi_create function returns NULL on errors. Better to
> keep the real and no-op version with the same return type, right?
I see...
So that is the real function that should have the error handling improved...
BTW, you don't change the type while using the ERR_PTR(-ENXIO), but
return an error which has a meaning.
Anyway, fare enough.
Acked-by: Igor Grinberg
--
Regards,
Igor.
--
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: What driver for generic bulk to tty?
p...@kubanek.net writes: > OK. Do you know the protocol? Yes, it's just 2 plain raw streams of bytes, in and out, for USB driver itself. Everything else is application-dependent, as I've alredy wrote. > User space - use /proc entries. See Apogee CCD driver for an example, > or ask me, I might be able to reveal parts of MI CCD driver which does > that. > > Kernel space - see some existing (FTDI,..) drivers and write your own. No available driver that is capable to handler raw in/out bulk except "usbserial"? Well, I actually wrote one a few years ago, when usbserial was really sloow, but then the latter got better and I din't care to either finish or submit my own since then. But as I now learned I shouldn't use usbserial for that (and besides it looks like it's buggy in 3.2.0 that I'm running right now). -- 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: What driver for generic bulk to tty?
On Wed, 20 Mar 2013, Sergei Organov wrote: > > >> What is recomended driver to use for a USB device that provides just > >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact > >> data formats that are used are application-specific, so only generic IO > >> TTY-alike device (with no control) is required from the kernel. > >> Searching through the lists and Internet uncovered multiple posts of > >> why "usbserial" is a wrong driver for this purpose, but nowhere did I > >> find what the right alternative is. > > > what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually > > the chips are either FTDI or something similar, and then ftdi driver > > should work (coupled with right parameters for "unsuported" IDs - you > > can then propose patch once you will see the device working). > > Thanks, but this is _not_ FTDI or any other widely-known device. It's not > usb-to-serial converter or modem of any kind at all. Just a device to > which one can talk over 2 USB bulk end-points, and I want to get a TTY > to talk to it. Maybe some user-space alternative? For something like this, usb-serial may indeed be the best solution, even though it has relatively low throughput. I don't think any of the more specific drivers are suited to this protocol. 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: What driver for generic bulk to tty?
>> What is recomended driver to use for a USB device that provides just >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact >> data formats that are used are application-specific, so only generic IO >> TTY-alike device (with no control) is required from the kernel. >> Searching through the lists and Internet uncovered multiple posts of >> why "usbserial" is a wrong driver for this purpose, but nowhere did I >> find what the right alternative is. > what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually > the chips are either FTDI or something similar, and then ftdi driver > should work (coupled with right parameters for "unsuported" IDs - you > can then propose patch once you will see the device working). Thanks, but this is _not_ FTDI or any other widely-known device. It's not usb-to-serial converter or modem of any kind at all. Just a device to which one can talk over 2 USB bulk end-points, and I want to get a TTY to talk to it. Maybe some user-space alternative? -- 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: What driver for generic bulk to tty?
p...@kubanek.net writes: > OK. Do you know the protocol? > > User space - use /proc entries. See Apogee CCD driver for an example, > or ask me, I might be able to reveal parts of MI CCD driver which does > that. I actually meant something readily available, something that can create a simple bridge between 2-bulk-usb-endpoint device and pseudo-tty, similar, e.g., to what 'socat' does for TCP connections. -- 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: What driver for generic bulk to tty?
On Wed, Mar 20, 2013 at 11:04:14AM -0400, Alan Stern wrote: > On Wed, 20 Mar 2013, Sergei Organov wrote: > > > > > >> What is recomended driver to use for a USB device that provides just > > >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact > > >> data formats that are used are application-specific, so only generic IO > > >> TTY-alike device (with no control) is required from the kernel. > > >> Searching through the lists and Internet uncovered multiple posts of > > >> why "usbserial" is a wrong driver for this purpose, but nowhere did I > > >> find what the right alternative is. > > > > > what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually > > > the chips are either FTDI or something similar, and then ftdi driver > > > should work (coupled with right parameters for "unsuported" IDs - you > > > can then propose patch once you will see the device working). > > > > Thanks, but this is _not_ FTDI or any other widely-known device. It's not > > usb-to-serial converter or modem of any kind at all. Just a device to > > which one can talk over 2 USB bulk end-points, and I want to get a TTY > > to talk to it. Maybe some user-space alternative? > > For something like this, usb-serial may indeed be the best solution, > even though it has relatively low throughput. I don't think any of the > more specific drivers are suited to this protocol. Just for the record, there's really nothing wrong with the usb-serial throughput. The days of a single read and write urb are long gone (2.6.32 if I remember correctly). The reason why one shouldn't use the generic driver for a "real" usb-serial device is that you cannot control baudrates, etc, and of course that the device-driver matching isn't automatic. For a simple device without any control commands you could use the generic driver. However, if this is a device which is others may be interested in using, adding a simple wrapper with the device is the way to go. Have a look at drivers/usb/serial/zio.c driver for an example. Johan -- 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: What driver for generic bulk to tty?
Alan Stern writes: > On Wed, 20 Mar 2013, Sergei Organov wrote: > >> >> >> What is recomended driver to use for a USB device that provides just >> >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact >> >> data formats that are used are application-specific, so only generic IO >> >> TTY-alike device (with no control) is required from the kernel. >> >> Searching through the lists and Internet uncovered multiple posts of >> >> why "usbserial" is a wrong driver for this purpose, but nowhere did I >> >> find what the right alternative is. >> >> > what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually >> > the chips are either FTDI or something similar, and then ftdi driver >> > should work (coupled with right parameters for "unsuported" IDs - you >> > can then propose patch once you will see the device working). >> >> Thanks, but this is _not_ FTDI or any other widely-known device. It's not >> usb-to-serial converter or modem of any kind at all. Just a device to >> which one can talk over 2 USB bulk end-points, and I want to get a TTY >> to talk to it. Maybe some user-space alternative? > > For something like this, usb-serial may indeed be the best solution, > even though it has relatively low throughput. I don't think any of the > more specific drivers are suited to this protocol. OK, thanks, get it. Now, if I'd like to adresss the problem from the other end, i.e., from the USB device side, what's the simplest thing I can implement so that some of the existing drivers can work with the device? What is the right thing to implement (provided it does not match the simplest one)? -- 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 0/5] usb: musb/otg: cleanup and fixes
Felipe, On Wednesday 20 March 2013 06:42 PM, Felipe Balbi wrote: On Wed, Mar 13, 2013 at 02:17:05PM +0530, Kishon Vijay Abraham I wrote: This series has some misc cleanup and fixes. The fix solves the cold plug issue in omap3 which some have reported. Developed these patches on Linux 3.9-rc2 after applying http://www.spinics.net/lists/linux-usb/msg81563.html (Grazvydas Ignotas patch series) Tested for g_zero enumeration in pandaboard and beagleboard in both cold plug and hot plug case. Any kind of testing for this series is welcome. Kishon Vijay Abraham I (5): usb: musb: omap: remove the check before calling otg_set_vbus usb: musb: omap: always glue have the correct vbus/id status usb: otg: twl4030: use devres API for regulator get and request irq usb: musb: omap: add usb_phy_init in omap2430_musb_init usb: otg: twl4030: fix cold plug on OMAP3 drivers/usb/musb/omap2430.c | 22 ++ drivers/usb/otg/twl4030-usb.c | 35 --- 2 files changed, 22 insertions(+), 35 deletions(-) this needs to be rebased against my 'next' branch. The v2 of this series is already in your testing branch. You still want it to be rebased to your 'next' branch? 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: What driver for generic bulk to tty?
On Wed, Mar 20, 2013 at 4:13 PM, Johan Hovold wrote: > The reason why one shouldn't use the generic driver for a "real" > usb-serial device is that you cannot control baudrates, etc, and of > course that the device-driver matching isn't automatic. > > For a simple device without any control commands you could use the > generic driver. However, if this is a device which is others may be > interested in using, adding a simple wrapper with the device is the way Adding a simple wrapper with the device _id_, that should be. > to go. Have a look at drivers/usb/serial/zio.c driver for an example. Johan -- 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: What driver for generic bulk to tty?
Please make sure to keep all parties CCed in your replies. On Wed, Mar 20, 2013 at 07:18:16PM +0400, Sergei Organov wrote: > Alan Stern > writes: > > > On Wed, 20 Mar 2013, Sergei Organov wrote: > > > >> > >> >> What is recomended driver to use for a USB device that provides just > >> >> 2 bulk end-points, in and out, to create a TTY to talk to it? Exact > >> >> data formats that are used are application-specific, so only generic IO > >> >> TTY-alike device (with no control) is required from the kernel. > >> >> Searching through the lists and Internet uncovered multiple posts of > >> >> why "usbserial" is a wrong driver for this purpose, but nowhere did I > >> >> find what the right alternative is. > >> > >> > what shows lsusb (e.g. what is TTY PID)? What is chip inside? Usually > >> > the chips are either FTDI or something similar, and then ftdi driver > >> > should work (coupled with right parameters for "unsuported" IDs - you > >> > can then propose patch once you will see the device working). > >> > >> Thanks, but this is _not_ FTDI or any other widely-known device. It's not > >> usb-to-serial converter or modem of any kind at all. Just a device to > >> which one can talk over 2 USB bulk end-points, and I want to get a TTY > >> to talk to it. Maybe some user-space alternative? > > > > For something like this, usb-serial may indeed be the best solution, > > even though it has relatively low throughput. I don't think any of the > > more specific drivers are suited to this protocol. > > OK, thanks, get it. > > Now, if I'd like to adresss the problem from the other end, i.e., from > the USB device side, what's the simplest thing I can implement so that > some of the existing drivers can work with the device? Use the generic driver, or add your device id to one of the pure wrapper drivers (such as zio or funsoft). > What is the right thing to implement (provided it does not match the > simplest one)? If it's not really related to any of the existing pure wrapper drivers, add a new wrapper driver. What kind of device are we talking about here? Would there be any users of a mainline-driver? Johan -- 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] Revert "USB: quatech2: only write to the tty if the port is open."
This reverts commit 27b351c5546008c640b3e65152f60ca74b3706f1. Calling tty_flip_buffer_push on an unopened tty is legal, so the driver doesn't need track if port has been opened. Reverting this allows the entire is_open logic to be removed. Signed-off-by: Bill Pemberton --- drivers/usb/serial/quatech2.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c index d643a4d..00e6c9b 100644 --- a/drivers/usb/serial/quatech2.c +++ b/drivers/usb/serial/quatech2.c @@ -661,9 +661,7 @@ void qt2_process_read_urb(struct urb *urb) __func__); break; } - - if (port_priv->is_open) - tty_flip_buffer_push(&port->port); + tty_flip_buffer_push(&port->port); newport = *(ch + 3); @@ -706,8 +704,7 @@ void qt2_process_read_urb(struct urb *urb) tty_insert_flip_string(&port->port, ch, 1); } - if (port_priv->is_open) - tty_flip_buffer_push(&port->port); + tty_flip_buffer_push(&port->port); } static void qt2_write_bulk_callback(struct urb *urb) -- 1.8.1.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 v4 06/21] ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-3630sdp.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 67447bd..20d6d81 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -53,16 +53,23 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = 126,
+ .vcc_gpio = -EINVAL,
+ },
+ {
+ .port = 2,
+ .reset_gpio = 61,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = 126,
- .reset_gpio_port[1] = 61,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -199,6 +206,8 @@ static void __init omap_sdp_init(void)
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
enable_board_wakeup_source();
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
}
--
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 v4 18/21] ARM: OMAP: zoom: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-zoom.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
index 5e4d4c9..1a3dd86 100644
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -92,14 +92,16 @@ static struct mtd_partition zoom_nand_partitions[] = {
},
};
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = ZOOM3_EHCI_RESET_GPIO,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = ZOOM3_EHCI_RESET_GPIO,
- .reset_gpio_port[2] = -EINVAL,
};
static void __init omap_zoom_init(void)
@@ -109,6 +111,8 @@ static void __init omap_zoom_init(void)
} else if (machine_is_omap_zoom3()) {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
}
--
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 v4 21/21] ARM: dts: omap3-beagle: Add USB Host support
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 71
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..02d23f1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -38,6 +38,57 @@
};
};
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb2_reset";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio5 19 0>; /* gpio_147 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb2_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&twl_gpio 18 0>;/* GPIO LEDA */
+ startup-delay-us = <7>;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = "usb-nop-xceiv";
+ reset-supply = <&hsusb2_reset>;
+ vcc-supply = <&hsusb2_power>;
+ };
+};
+
+&omap3_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusbb2_pins
+ >;
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins = <
+ 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+ 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x1aa 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x1ac 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ >;
+ };
};
&i2c1 {
@@ -65,3 +116,23 @@
&mmc3 {
status = "disabled";
};
+
+&usbhshost {
+ port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <0 &hsusb2_phy>;
+};
+
+&twl_gpio {
+ ti,use-leds;
+ /* pullups: BIT(1) */
+ ti,pullups = <0x02>;
+ /*
+* pulldowns:
+* BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
+* BIT(15), BIT(16), BIT(17)
+*/
+ ti,pulldowns = <0x03a1c4>;
+};
--
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 v4 20/21] ARM: dts: OMAP3: Add HS USB Host IP nodes
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..a14f74b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,36 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ usbhstll: usbhstll@48062000 {
+ compatible = "ti,usbhs-tll";
+ reg = <0x48062000 0x1000>;
+ interrupts = <78>;
+ ti,hwmods = "usb_tll_hs";
+ };
+
+ usbhshost: usbhshost@48064000 {
+ compatible = "ti,usbhs-host";
+ reg = <0x48064000 0x400>;
+ ti,hwmods = "usb_host_hs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ usbhsohci: ohci@48064400 {
+ compatible = "ti,ohci-omap3", "usb-ohci";
+ reg = <0x48064400 0x400>;
+ interrupt-parent = <&intc>;
+ interrupts = <76>;
+ };
+
+ usbhsehci: ehci@48064800 {
+ compatible = "ti,ehci-omap", "usb-ehci";
+ reg = <0x48064800 0x400>;
+ interrupt-parent = <&intc>;
+ interrupts = <77>;
+ };
+ };
+
};
};
--
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 v4 19/21] ARM: dts: OMAP4: Add HS USB Host IP nodes
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..b7db1a2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,35 @@
ti,hwmods = "timer11";
ti,timer-pwm;
};
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = "ti,usbhs-tll";
+ reg = <0x4a062000 0x1000>;
+ interrupts = <0 78 0x4>;
+ ti,hwmods = "usb_tll_hs";
+ };
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = "ti,usbhs-host";
+ reg = <0x4a064000 0x800>;
+ ti,hwmods = "usb_host_hs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = "ti,ohci-omap3", "usb-ohci";
+ reg = <0x4a064800 0x400>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 76 0x4>;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = "ti,ehci-omap", "usb-ehci";
+ reg = <0x4a064c00 0x400>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 77 0x4>;
+ };
+ };
};
};
--
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 v4 02/21] ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys()
This helper allows board support code to add the PHY's
VCC and RESET regulators which are GPIO controlled as well
as the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/usb-host.c | 160 +++-
arch/arm/mach-omap2/usb.h |9 ++
2 files changed, 167 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 5706bdc..aa27d7f 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,8 +22,12 @@
#include
#include
#include
-
-#include
+#include
+#include
+#include
+#include
+#include
+#include
#include "soc.h"
#include "omap_device.h"
@@ -526,3 +530,155 @@ void __init usbhs_init(struct usbhs_omap_platform_data
*pdata)
}
#endif
+
+/* Template for PHY regulators */
+static struct fixed_voltage_config hsusb_reg_config = {
+ /* .supply_name filled later */
+ .microvolts = 330,
+ .gpio = -1, /* updated later */
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1, /* updated later */
+ .enabled_at_boot = 0, /* keep in RESET */
+ /* .init_data filled later */
+};
+
+static const char *nop_name = "nop_usb_xceiv"; /* NOP PHY driver */
+static const char *reg_name = "reg-fixed-voltage"; /* Regulator driver */
+
+/**
+ * usbhs_add_regulator - Add a gpio based fixed voltage regulator device
+ * @name: name for the regulator
+ * @dev_id: device id of the device this regulator supplies power to
+ * @dev_supply: supply name that the device expects
+ * @gpio: GPIO number
+ * @polarity: 1 - Active high, 0 - Active low
+ */
+static int usbhs_add_regulator(char *name, char *dev_id, char *dev_supply,
+ int gpio, int polarity)
+{
+ struct regulator_consumer_supply *supplies;
+ struct regulator_init_data *reg_data;
+ struct fixed_voltage_config *config;
+ struct platform_device *pdev;
+ int ret;
+
+ supplies = kzalloc(sizeof(*supplies), GFP_KERNEL);
+ if (!supplies)
+ return -ENOMEM;
+
+ supplies->supply = dev_supply;
+ supplies->dev_name = dev_id;
+
+ reg_data = kzalloc(sizeof(*reg_data), GFP_KERNEL);
+ if (!reg_data)
+ return -ENOMEM;
+
+ reg_data->constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
+ reg_data->consumer_supplies = supplies;
+ reg_data->num_consumer_supplies = 1;
+
+ config = kmemdup(&hsusb_reg_config, sizeof(hsusb_reg_config),
+ GFP_KERNEL);
+ if (!config)
+ return -ENOMEM;
+
+ config->supply_name = name;
+ config->gpio = gpio;
+ config->enable_high = polarity;
+ config->init_data = reg_data;
+
+ /* create a regulator device */
+ pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
+ if (!pdev)
+ return -ENOMEM;
+
+ pdev->id = PLATFORM_DEVID_AUTO;
+ pdev->name = reg_name;
+ pdev->dev.platform_data = config;
+
+ ret = platform_device_register(pdev);
+ if (ret)
+ pr_err("%s: Failed registering regulator %s for %s\n",
+ __func__, name, dev_id);
+
+ return ret;
+}
+
+int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)
+{
+ char *rail_name;
+ int i, len;
+ struct platform_device *pdev;
+ char *phy_id;
+
+ /* the phy_id will be something like "nop_usb_xceiv.1" */
+ len = strlen(nop_name) + 3; /* 3 -> ".1" and NULL terminator */
+
+ for (i = 0; i < num_phys; i++) {
+
+ if (!phy->port) {
+ pr_err("%s: Invalid port 0. Must start from 1\n",
+ __func__);
+ continue;
+ }
+
+ /* do we need a NOP PHY device ? */
+ if (!gpio_is_valid(phy->reset_gpio) &&
+ !gpio_is_valid(phy->vcc_gpio))
+ continue;
+
+ /* create a NOP PHY device */
+ pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
+ if (!pdev)
+ return -ENOMEM;
+
+ pdev->id = phy->port;
+ pdev->name = nop_name;
+ pdev->dev.platform_data = phy->platform_data;
+
+ phy_id = kmalloc(len, GFP_KERNEL);
+ if (!phy_id)
+ return -ENOMEM;
+
+ scnprintf(phy_id, len, "nop_usb_xceiv.%d\n",
+ pdev->id);
+
+ if (platform_device_register(pdev)) {
+ pr_err("%s: Failed to register device %s\n",
+ __func__, phy_id);
+ continue;
+ }
+
+ usb_bind_phy("ehci-omap.0", phy->port - 1, phy_id);
+
+ /* Do we need RESET regulator ? */
+ if (gpio_is_valid(phy->r
[PATCH v4 14/21] ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulator
and NOP PHY device. VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3pandora.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 2bba362..1004d2a 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -346,7 +346,7 @@ static struct regulator_consumer_supply
pandora_vcc_lcd_supply[] = {
};
static struct regulator_consumer_supply pandora_usb_phy_supply[] = {
- REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
+ REGULATOR_SUPPLY("vcc", "nop_usb_xceiv.2"), /* hsusb port 2 */
};
/* ads7846 on SPI and 2 nub controllers on I2C */
@@ -561,6 +561,14 @@ fail:
printk(KERN_ERR "wl1251 board initialisation failed\n");
}
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 16,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct platform_device *omap3pandora_devices[] __initdata = {
&pandora_leds_gpio,
&pandora_keys_gpio,
@@ -569,15 +577,7 @@ static struct platform_device *omap3pandora_devices[]
__initdata = {
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 16,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -601,7 +601,10 @@ static void __init omap3pandora_init(void)
spi_register_board_info(omap3pandora_spi_board_info,
ARRAY_SIZE(omap3pandora_spi_board_info));
omap_ads7846_init(1, OMAP3_PANDORA_TS_GPIO, 0, NULL);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
+
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
gpmc_nand_init(&pandora_nand_data, NULL);
--
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 v4 15/21] ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3stalker.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 95c10b3..bf09564 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -358,19 +358,20 @@ static int __init omap3_stalker_i2c_init(void)
#define OMAP3_STALKER_TS_GPIO 175
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 21,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct platform_device *omap3_stalker_devices[] __initdata = {
&keys_gpio,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 21,
- .reset_gpio_port[2] = -EINVAL,
};
#ifdef CONFIG_OMAP_MUX
@@ -407,6 +408,8 @@ static void __init omap3_stalker_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
omap_ads7846_init(1, OMAP3_STALKER_TS_GPIO, 310, NULL);
--
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 v4 17/21] ARM: OMAP3: overo: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-overo.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..ab79a44 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -458,14 +458,16 @@ static int __init overo_spi_init(void)
return 0;
}
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = OVERO_GPIO_USBH_NRESET,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = OVERO_GPIO_USBH_NRESET,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -502,6 +504,8 @@ static void __init overo_init(void)
ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
overo_spi_init();
overo_init_smsc911x();
--
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 v4 16/21] ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3touchbook.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index bcd44fb..7da48bc 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -305,21 +305,22 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 147,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct platform_device *omap3_touchbook_devices[] __initdata = {
&leds_gpio,
&keys_gpio,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 147,
- .reset_gpio_port[2] = -EINVAL
};
static void omap3_touchbook_poweroff(void)
@@ -368,6 +369,8 @@ static void __init omap3_touchbook_init(void)
omap_ads7846_init(4, OMAP3_TS_GPIO, 310, &ads7846_pdata);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
board_nand_init(omap3touchbook_nand_partitions,
ARRAY_SIZE(omap3touchbook_nand_partitions), NAND_CS,
--
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 v4 12/21] ARM: OMAP3: igep0020: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-igep0020.c | 32 ++--
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index bf92678..95ccec0 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -527,26 +527,28 @@ static void __init igep_i2c_init(void)
omap3_pmic_init("twl4030", &igep_twldata);
}
+static struct usbhs_phy_data igep2_phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = IGEP2_GPIO_USBH_NRESET,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
+static struct usbhs_phy_data igep3_phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = IGEP3_GPIO_USBH_NRESET,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct usbhs_omap_platform_data igep2_usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL,
};
static struct usbhs_omap_platform_data igep3_usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = IGEP3_GPIO_USBH_NRESET,
- .reset_gpio_port[2] = -EINVAL,
};
#ifdef CONFIG_OMAP_MUX
@@ -642,8 +644,10 @@ static void __init igep_init(void)
if (machine_is_igep0020()) {
omap_display_init(&igep2_dss_data);
igep2_init_smsc911x();
+ usbhs_init_phys(igep2_phy_data, ARRAY_SIZE(igep2_phy_data));
usbhs_init(&igep2_usbhs_bdata);
} else {
+ usbhs_init_phys(igep3_phy_data, ARRAY_SIZE(igep3_phy_data));
usbhs_init(&igep3_usbhs_bdata);
}
}
--
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 v4 13/21] ARM: OMAP3: omap3evm: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulator
and the NOP PHY device. VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3evm.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 48789e0..2de92fa 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -496,7 +496,7 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata =
{
static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
REGULATOR_SUPPLY("VDD_CSIPHY1", "omap3isp"),/* OMAP ISP */
REGULATOR_SUPPLY("VDD_CSIPHY2", "omap3isp"),/* OMAP ISP */
- REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
+ REGULATOR_SUPPLY("vcc", "nop_usb_xceiv.2"), /* hsusb port 2 */
REGULATOR_SUPPLY("vaux2", NULL),
};
@@ -539,17 +539,16 @@ static int __init omap3_evm_i2c_init(void)
return 0;
}
-static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = -1, /* set at runtime */
+ .vcc_gpio = -EINVAL,
+ },
+};
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- /* PHY reset GPIO will be runtime programmed based on EVM version */
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -725,7 +724,7 @@ static void __init omap3_evm_init(void)
/* setup EHCI phy reset config */
omap_mux_init_gpio(21, OMAP_PIN_INPUT_PULLUP);
- usbhs_bdata.reset_gpio_port[1] = 21;
+ phy_data[0].reset_gpio = 21;
/* EVM REV >= E can supply 500mA with EXTVBUS programming */
musb_board_data.power = 500;
@@ -733,10 +732,12 @@ static void __init omap3_evm_init(void)
} else {
/* setup EHCI phy reset on MDC */
omap_mux_init_gpio(135, OMAP_PIN_OUTPUT);
- usbhs_bdata.reset_gpio_port[1] = 135;
+ phy_data[0].reset_gpio = 135;
}
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(&musb_board_data);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
board_nand_init(omap3evm_nand_partitions,
ARRAY_SIZE(omap3evm_nand_partitions), NAND_CS,
--
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 v4 11/21] ARM: OMAP: devkit8000: Adapt to ehci-omap changes
Remove deprecated USBHS platform data.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-devkit8000.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 53056c3..42fbf1e 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -437,15 +437,7 @@ static struct platform_device *devkit8000_devices[]
__initdata = {
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
--
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 v4 10/21] ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-cm-t3517.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index a66da80..6920f6cf 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -188,15 +188,22 @@ static inline void cm_t3517_init_rtc(void) {}
#define HSUSB2_RESET_GPIO (147)
#define USB_HUB_RESET_GPIO (152)
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = HSUSB1_RESET_GPIO,
+ .vcc_gpio = -EINVAL,
+ },
+ {
+ .port = 2,
+ .reset_gpio = HSUSB2_RESET_GPIO,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct usbhs_omap_platform_data cm_t3517_ehci_pdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = HSUSB1_RESET_GPIO,
- .reset_gpio_port[1] = HSUSB2_RESET_GPIO,
- .reset_gpio_port[2] = -EINVAL,
};
static int __init cm_t3517_init_usbh(void)
@@ -213,6 +220,7 @@ static int __init cm_t3517_init_usbh(void)
msleep(1);
}
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&cm_t3517_ehci_pdata);
return 0;
--
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 v4 09/21] ARM: OMAP3: cm-t35: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-cm-t35.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index af2bb21..7fda3f5 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -419,15 +419,22 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = OMAP_MAX_GPIO_LINES + 6,
+ .vcc_gpio = -EINVAL,
+ },
+ {
+ .port = 2,
+ .reset_gpio = OMAP_MAX_GPIO_LINES + 7,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = OMAP_MAX_GPIO_LINES + 6,
- .reset_gpio_port[1] = OMAP_MAX_GPIO_LINES + 7,
- .reset_gpio_port[2] = -EINVAL
};
static void __init cm_t35_init_usbh(void)
@@ -444,6 +451,7 @@ static void __init cm_t35_init_usbh(void)
msleep(1);
}
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
}
--
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 v4 01/21] usb: phy: nop: Add some parameters to platform data
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.
Signed-off-by: Roger Quadros
Acked-by: Felipe Balbi
---
include/linux/usb/nop-usb-xceiv.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index 28884c7..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -5,6 +5,11 @@
struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
+ unsigned long clk_rate;
+
+ /* if set fails with -EPROBE_DEFER if can't get regulator */
+ unsigned int needs_vcc:1;
+ unsigned int needs_reset:1;
};
#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE) &&
defined(MODULE))
--
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 v4 03/21] ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device name.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap4panda.c | 55 ---
1 files changed, 21 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b02c2f0..a71ad34 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -132,6 +133,22 @@ static struct platform_device btwilink_device = {
.id = -1,
};
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct nop_usb_xceiv_platform_data hsusb1_phy_data = {
+ /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+ .clk_rate = 1920,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = GPIO_HUB_NRESET,
+ .vcc_gpio = GPIO_HUB_POWER,
+ .vcc_polarity = 1,
+ .platform_data = &hsusb1_phy_data,
+ },
+};
+
static struct platform_device *panda_devices[] __initdata = {
&leds_gpio,
&wl1271_device,
@@ -142,49 +159,19 @@ static struct platform_device *panda_devices[] __initdata
= {
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = false,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
-};
-
-static struct gpio panda_ehci_gpios[] __initdata = {
- { GPIO_HUB_POWER, GPIOF_OUT_INIT_LOW, "hub_power" },
- { GPIO_HUB_NRESET, GPIOF_OUT_INIT_LOW, "hub_nreset" },
};
static void __init omap4_ehci_init(void)
{
int ret;
- struct clk *phy_ref_clk;
/* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
- phy_ref_clk = clk_get(NULL, "auxclk3_ck");
- if (IS_ERR(phy_ref_clk)) {
- pr_err("Cannot request auxclk3\n");
- return;
- }
- clk_set_rate(phy_ref_clk, 1920);
- clk_prepare_enable(phy_ref_clk);
-
- /* disable the power to the usb hub prior to init and reset phy+hub */
- ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
- if (ret) {
- pr_err("Unable to initialize EHCI power/reset\n");
- return;
- }
-
- gpio_export(GPIO_HUB_POWER, 0);
- gpio_export(GPIO_HUB_NRESET, 0);
- gpio_set_value(GPIO_HUB_NRESET, 1);
+ ret = clk_add_alias("main_clk", "nop_usb_xceiv.1", "auxclk3_ck", NULL);
+ if (ret)
+ pr_err("Failed to add main_clk alias to auxclk3_ck\n");
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
-
- /* enable power to hub */
- gpio_set_value(GPIO_HUB_POWER, 1);
}
static struct omap_musb_board_data musb_board_data = {
--
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 v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] & [3]. Device tree support is added for Beagleboard only. I've removed Panda device tree support till we have resolved the AUXCLK issue. NOTE: The first patch needs to be shared between the OMAP tree and Felipe's USB tree. v4: - Some more cleanup to usbhs_init_phys(). Moved repeated code into another helper function usbhs_add_regulator(). - Removed patch for Panda device tree support for USB host since it is non functional. v3: - Moved more functionality into usbhs_init_phys(). v2: - Added helper function usbhs_init_phys() that can be used by board files to simplify adding of PHY regulators for USB host ports. [1] MFD side changes to omap-usb-host and omap-usb-tll https://lkml.org/lkml/2013/3/12/179 [2] USB EHCI side changes to ehci-omap http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86265.html [3] USB PHY driver changes http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86293.html The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-arm-next Roger Quadros (21): usb: phy: nop: Add some parameters to platform data ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys() ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes ARM: OMAP3: Beagle: Adapt to ehci-omap changes ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes ARM: OMAP: AM3517crane: Adapt to ehci-omap changes ARM: OMAP: AM3517evm: Adapt to ehci-omap changes ARM: OMAP3: cm-t35: Adapt to ehci-omap changes ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes ARM: OMAP: devkit8000: Adapt to ehci-omap changes ARM: OMAP3: igep0020: Adapt to ehci-omap changes ARM: OMAP3: omap3evm: Adapt to ehci-omap changes ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes ARM: OMAP3: overo: Adapt to ehci-omap changes ARM: OMAP: zoom: Adapt to ehci-omap changes ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support arch/arm/boot/dts/omap3-beagle.dts | 71 arch/arm/boot/dts/omap3.dtsi | 31 ++ arch/arm/boot/dts/omap4.dtsi | 30 + arch/arm/mach-omap2/board-3430sdp.c| 21 +++- arch/arm/mach-omap2/board-3630sdp.c| 21 +++- arch/arm/mach-omap2/board-am3517crane.c| 24 ++--- arch/arm/mach-omap2/board-am3517evm.c | 17 ++-- arch/arm/mach-omap2/board-cm-t35.c | 20 +++- arch/arm/mach-omap2/board-cm-t3517.c | 20 +++- arch/arm/mach-omap2/board-devkit8000.c |8 -- arch/arm/mach-omap2/board-igep0020.c | 32 +++--- arch/arm/mach-omap2/board-omap3beagle.c| 32 -- arch/arm/mach-omap2/board-omap3evm.c | 25 +++-- arch/arm/mach-omap2/board-omap3pandora.c | 21 ++-- arch/arm/mach-omap2/board-omap3stalker.c | 17 ++-- arch/arm/mach-omap2/board-omap3touchbook.c | 17 ++-- arch/arm/mach-omap2/board-omap4panda.c | 55 -- arch/arm/mach-omap2/board-overo.c | 16 ++- arch/arm/mach-omap2/board-zoom.c | 16 ++- arch/arm/mach-omap2/usb-host.c | 160 +++- arch/arm/mach-omap2/usb.h |9 ++ include/linux/usb/nop-usb-xceiv.h |5 + 22 files changed, 508 insertions(+), 160 deletions(-) -- 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 v4 05/21] ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY devices.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-3430sdp.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ce812de..7eb9651 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -445,16 +445,23 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = 57,
+ .vcc_gpio = -EINVAL,
+ },
+ {
+ .port = 2,
+ .reset_gpio = 61,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = 57,
- .reset_gpio_port[1] = 61,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -606,6 +613,8 @@ static void __init omap_3430sdp_init(void)
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
enable_board_wakeup_source();
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
}
--
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 v4 04/21] ARM: OMAP3: Beagle: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3beagle.c | 32 +-
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index c3558f9..5382215 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -277,6 +278,21 @@ static struct regulator_consumer_supply
beagle_vsim_supply[] = {
static struct gpio_led gpio_leds[];
+/* PHY's VCC regulator might be added later, so flag that we need it */
+static struct nop_usb_xceiv_platform_data hsusb2_phy_data = {
+ .needs_vcc = true,
+};
+
+static struct usbhs_phy_data phy_data[] = {
+ {
+ .port = 2,
+ .reset_gpio = 147,
+ .vcc_gpio = -1, /* updated in beagle_twl_gpio_setup */
+ .vcc_polarity = 1, /* updated in beagle_twl_gpio_setup */
+ .platform_data = &hsusb2_phy_data,
+ },
+};
+
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -318,9 +334,11 @@ static int beagle_twl_gpio_setup(struct device *dev,
}
dvi_panel.power_down_gpio = beagle_config.dvi_pd_gpio;
- gpio_request_one(gpio + TWL4030_GPIO_MAX, beagle_config.usb_pwr_level,
- "nEN_USB_PWR");
+ /* TWL4030_GPIO_MAX i.e. LED_GPO controls HS USB Port 2 power */
+ phy_data[0].vcc_gpio = gpio + TWL4030_GPIO_MAX;
+ phy_data[0].vcc_polarity = beagle_config.usb_pwr_level;
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
return 0;
}
@@ -453,15 +471,7 @@ static struct platform_device *omap3_beagle_devices[]
__initdata = {
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 147,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -543,7 +553,9 @@ static void __init omap3_beagle_init(void)
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
usbhs_init(&usbhs_bdata);
+
board_nand_init(omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions), NAND_CS,
NAND_BUSWIDTH_16, NULL);
--
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 v4 08/21] ARM: OMAP: AM3517evm: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's RESET regulators
and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-am3517evm.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 9fb8590..191f976 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -274,6 +274,14 @@ static __init void am3517_evm_mcbsp1_init(void)
omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
}
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = 57,
+ .vcc_gpio = -EINVAL,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
@@ -282,12 +290,6 @@ static struct usbhs_omap_platform_data usbhs_bdata
__initdata = {
#else
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
#endif
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = 57,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -349,7 +351,6 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-
static void __init am3517_evm_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -361,6 +362,8 @@ static void __init am3517_evm_init(void)
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(57, OMAP_PIN_OUTPUT);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
/* DSS */
--
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 v4 07/21] ARM: OMAP: AM3517crane: Adapt to ehci-omap changes
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-am3517crane.c | 24 ++--
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 7d3358b..fc53911 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -47,15 +47,17 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = GPIO_USB_NRESET,
+ .vcc_gpio = GPIO_USB_POWER,
+ .vcc_polarity = 1,
+ },
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = GPIO_USB_NRESET,
- .reset_gpio_port[1] = -EINVAL,
- .reset_gpio_port[2] = -EINVAL
};
static struct mtd_partition crane_nand_partitions[] = {
@@ -131,13 +133,7 @@ static void __init am3517_crane_init(void)
return;
}
- ret = gpio_request_one(GPIO_USB_POWER, GPIOF_OUT_INIT_HIGH,
- "usb_ehci_enable");
- if (ret < 0) {
- pr_err("Can not request GPIO %d\n", GPIO_USB_POWER);
- return;
- }
-
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
}
--
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: Two remain problems at chipidea driver
On 03/20/2013 02:37 PM, Alexander Shishkin wrote: > Marc Kleine-Budde writes: > >> On 03/20/2013 12:23 PM, Alexander Shishkin wrote: >>> Marc Kleine-Budde writes: >>> On 03/20/2013 12:04 PM, Alexander Shishkin wrote: > Peter Chen writes: > >> On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: >>> Eg, for tablet or phone, the dr_mode may be "gadget", but the otg_capable = 1. >>> >>> No, because dr_mode indicates controller's capability, and not the >>> "current" mode of operation. Why would anyone want to put *that* in a >>> DT? >>> >> >> OK, now I totally understand your mind of this problem. In fact, dr_mode >> is NOT controller's capability, even at its original place: >> (Documentation/devicetree/bindings/usb/fsl-usb.txt or nvidia, >> tegra20-ehci.txt) >> dr_mode is the usb working mode. >> >> When we design USB system, the requirements are differ from products >> to products. >> The phone/tablet device may only wants itself as gadget >> device, it needs to be no-response when there is a usb device plug in >> (eg usb keyboard with Micro B-to-A cable). >> >> The car entertainment system or other Standard-A port system do not want >> to be enumerated when it plugs to notebook using Standard A-to-A cable. > > Bah. Of course, you're right. We're stuck with dr_mode till people learn > to design middleware stacks that can handle being both host and > peripheral. > >> So, currently, even most of controllers are otg-capable, still most >> of designs are one working mode designed. The reason why we design >> the dr_mode is that we want controller working mode to be decided >> by DT without re-compile the kernel by build out the host/gadget driver. > > Ok, so then how about introducing *one* more parameter, something like > "dr_cap", which > 1) when specified, supersedes DCCPARAMS, so no need to read that > register any more; > 2) when unspecified, use DCCPARAMS; > 3) can be one of "host", "peripheral", "otg", "dual_role": >- host, peripheral: initialize one role only, stick to that, no otg; >- dual_role: initialize both roles, no otg; >- otg: both roles, ci->is_otg == true. > > Another question now is, do we need "dual_role" variant for the dr_mode > parameter? What's the difference between the newly proposed dr_cap and the dr_mode parameter? >>> >>> See the discussion above. >>> >>> dr_cap is what the device can actually do (host, peripheral, etc). Tells >>> us which roles to initialize and wether we can access OTGSC on this >>> device. >>> dr_mode is what function of the device we'll be using on this particular >>> board. >> >> Sorry, I don't get why the driver needs to know what the chipidea can do >> in theory (dr_cap). IMHO it should be sufficient to tell the driver what >> that exact hardware it runs on can do (dr_mode). What the hardware can >> do depends on the actual chipidea implementation used in that SoC and >> the board the SoC is soldered on. > > Again, see the discussion above. > > In real world products (that is, phones and tablets as opposed to jolly > fun development boards), vendors will want to limit the usb > functionality to peripheral only or host only or whatever, because the > middleware stack can only do one thing or because they don't want to go > through with otg certification or you name it. Meanwhile, the controller It's very tempting to describe the software capabilities by the device tree. But the device tree is supposed to describe the hardware only. > and the whole device can still support otg. And we need to know that if > we're to try to detect vbus session, because that is done via OTGSC > which is only available in otg configurations. Do we need to access the OTGSC register on a OTG capable SoC which is limited to device-only by other hardware constraints (like no ID Pin)? In other words, is Svetoslav's patch[1] "usb: chipidea: Don't access OTG related registers" sufficient? [1] http://patchwork.linux-mips.org/patch/4940/ This patch restricts the access to the OTGSC register to the dr_mode=otg case, which of course is only valid, if the hardware (SoC, board, etc) really supports otg. > The alternative is to have N more platform tweaks for > * dccparams_is_borked, > * otgsc_is_borked, > and a lot of luck trying to get that right in the probe(). This is, of > course a preferred approach for anyone who supports phandle creep in > DT. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 01/21] usb: phy: nop: Add some parameters to platform data
On Wed, Mar 20, 2013 at 05:44:40PM +0200, Roger Quadros wrote: > Add clk_rate parameter to platform data. If supplied, the > NOP phy driver will program the clock to that rate during probe. > > Also add 2 flags, needs_vcc and needs_reset. > If the flag is set and the regulator couldn't be found > then the driver will bail out with -EPROBE_DEFER. > > Signed-off-by: Roger Quadros > Acked-by: Felipe Balbi Hi Tony, maybe you might prefer to merge commit 1f0972f from my next branch which is exactly this patch. Basically, if you: $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next $ git merge 1f0972f you get $SUBJECT and can apply the others without fear of conflicts later. cheers -- balbi signature.asc Description: Digital signature
Re: Two remain problems at chipidea driver
On 03/20/2013 03:44 PM, Felipe Balbi wrote: > Hi, > > On Wed, Mar 20, 2013 at 04:26:02PM +0200, Alexander Shishkin wrote: >> dr_cap is what the device can actually do (host, peripheral, etc). Tells >> us which roles to initialize and wether we can access OTGSC on this >> device. >> dr_mode is what function of the device we'll be using on this particular >> board. > > Sorry, I don't get why the driver needs to know what the chipidea can do > in theory (dr_cap). IMHO it should be sufficient to tell the driver what > that exact hardware it runs on can do (dr_mode). What the hardware can > do depends on the actual chipidea implementation used in that SoC and > the board the SoC is soldered on. Again, see the discussion above. In real world products (that is, phones and tablets as opposed to jolly fun development boards), vendors will want to limit the usb functionality to peripheral only or host only or whatever, because the middleware stack can only do one thing or because they don't want to go through with otg certification or you name it. Meanwhile, the controller >>> >>> that's not entirely true. A manufacturer can decide to skip OTG >>> certification but still support Dual Role. Look at the whole Android >>> Accessory Kit, for example. >> >> Sure, I was just making an example of how device capabilities can differ >> from device's intended function. >> and the whole device can still support otg. And we need to know that if we're to try to detect vbus session, because that is done via OTGSC which is only available in otg configurations. >>> >>> well, if it's only available in OTG configurations, then you make the >>> same assumption in driver. If driver was compiled with OTG, you check >>> OTGSC; otherwise don't. >> >> I'd kind of like to support different configurations in runtime and have >> as few compilation options as possible. Of course, if it means extra >> spaghetti, there's a trade off right there. > > right, that's what I did with drivers/usb/dwc3/, it helped cut down > ifdeferry to a minimum. But when chromebook with Exynos5 showed up, we > _had_ to allow manufacturers to ship the notebook without the peripheral > side, since they'd never, ever use it. Since the code was already > prepared for that, it was pretty simple and there's no ifdef hell > anywhere. Below you will find original commit. The main idea is that, if > you want a distro-like kernel, then you always build with everything > (DRD), but if you're building a real product, as you said, you may not > want to ship both modes unless you're really going to use them. With the "dr_mode" property in the DT, you can build one kernel that supports host, device and otg at the same time, but still limit a particular hardware to device only mode. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] usb: musb/otg: cleanup and fixes
On Wed, Mar 20, 2013 at 08:52:36PM +0530, kishon wrote: > Felipe, > > On Wednesday 20 March 2013 06:42 PM, Felipe Balbi wrote: > >On Wed, Mar 13, 2013 at 02:17:05PM +0530, Kishon Vijay Abraham I wrote: > >>This series has some misc cleanup and fixes. The fix solves the cold > >>plug issue in omap3 which some have reported. Developed these patches on > >>Linux 3.9-rc2 after applying > >>http://www.spinics.net/lists/linux-usb/msg81563.html > >>(Grazvydas Ignotas patch series) > >> > >>Tested for g_zero enumeration in pandaboard and beagleboard in both > >>cold plug and hot plug case. Any kind of testing for this series is welcome. > >> > >>Kishon Vijay Abraham I (5): > >> usb: musb: omap: remove the check before calling otg_set_vbus > >> usb: musb: omap: always glue have the correct vbus/id status > >> usb: otg: twl4030: use devres API for regulator get and request irq > >> usb: musb: omap: add usb_phy_init in omap2430_musb_init > >> usb: otg: twl4030: fix cold plug on OMAP3 > >> > >> drivers/usb/musb/omap2430.c | 22 ++ > >> drivers/usb/otg/twl4030-usb.c | 35 --- > >> 2 files changed, 22 insertions(+), 35 deletions(-) > > > >this needs to be rebased against my 'next' branch. > > The v2 of this series is already in your testing branch. You still > want it to be rebased to your 'next' branch? sorry, no need. I just forgot to mark this one as read. My bad. -- balbi signature.asc Description: Digital signature
Re: Two remain problems at chipidea driver
On Wed, Mar 20, 2013 at 04:58:05PM +0100, Marc Kleine-Budde wrote: > On 03/20/2013 03:44 PM, Felipe Balbi wrote: > > Hi, > > > > On Wed, Mar 20, 2013 at 04:26:02PM +0200, Alexander Shishkin wrote: > >> dr_cap is what the device can actually do (host, peripheral, etc). > >> Tells > >> us which roles to initialize and wether we can access OTGSC on this > >> device. > >> dr_mode is what function of the device we'll be using on this > >> particular > >> board. > > > > Sorry, I don't get why the driver needs to know what the chipidea can do > > in theory (dr_cap). IMHO it should be sufficient to tell the driver what > > that exact hardware it runs on can do (dr_mode). What the hardware can > > do depends on the actual chipidea implementation used in that SoC and > > the board the SoC is soldered on. > > Again, see the discussion above. > > In real world products (that is, phones and tablets as opposed to jolly > fun development boards), vendors will want to limit the usb > functionality to peripheral only or host only or whatever, because the > middleware stack can only do one thing or because they don't want to go > through with otg certification or you name it. Meanwhile, the controller > >>> > >>> that's not entirely true. A manufacturer can decide to skip OTG > >>> certification but still support Dual Role. Look at the whole Android > >>> Accessory Kit, for example. > >> > >> Sure, I was just making an example of how device capabilities can differ > >> from device's intended function. > >> > and the whole device can still support otg. And we need to know that if > we're to try to detect vbus session, because that is done via OTGSC > which is only available in otg configurations. > >>> > >>> well, if it's only available in OTG configurations, then you make the > >>> same assumption in driver. If driver was compiled with OTG, you check > >>> OTGSC; otherwise don't. > >> > >> I'd kind of like to support different configurations in runtime and have > >> as few compilation options as possible. Of course, if it means extra > >> spaghetti, there's a trade off right there. > > > > right, that's what I did with drivers/usb/dwc3/, it helped cut down > > ifdeferry to a minimum. But when chromebook with Exynos5 showed up, we > > _had_ to allow manufacturers to ship the notebook without the peripheral > > side, since they'd never, ever use it. Since the code was already > > prepared for that, it was pretty simple and there's no ifdef hell > > anywhere. Below you will find original commit. The main idea is that, if > > you want a distro-like kernel, then you always build with everything > > (DRD), but if you're building a real product, as you said, you may not > > want to ship both modes unless you're really going to use them. > > With the "dr_mode" property in the DT, you can build one kernel that > supports host, device and otg at the same time, but still limit a > particular hardware to device only mode. that's alright. We do that with dwc3 as well. But what if you want a kernel with host-only ? You don't want to waste precious memory initializing data you will never use ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 01/21] usb: phy: nop: Add some parameters to platform data
* Felipe Balbi [130320 09:00]: > On Wed, Mar 20, 2013 at 05:44:40PM +0200, Roger Quadros wrote: > > Add clk_rate parameter to platform data. If supplied, the > > NOP phy driver will program the clock to that rate during probe. > > > > Also add 2 flags, needs_vcc and needs_reset. > > If the flag is set and the regulator couldn't be found > > then the driver will bail out with -EPROBE_DEFER. > > > > Signed-off-by: Roger Quadros > > Acked-by: Felipe Balbi > > Hi Tony, > > maybe you might prefer to merge commit 1f0972f from my next branch which > is exactly this patch. Basically, if you: > > $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next > $ git merge 1f0972f > > you get $SUBJECT and can apply the others without fear of conflicts > later. OK thanks will use commit 1f0972f, so let's consider that commit immutable. Regards, Tony -- 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
