Re: USB_MUSB_DA8XX with g_multi.ko
Hi Jon, On Thu, Jun 26, 2014 at 4:46 AM, Jon Ringle j...@ringle.org wrote: The only thing I needed to do was to remove the BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would have to do besides just removing BROKEN to get this accepted back into the kernel source tree? I tried to remove the BROKEN dependency in [1], but without success. See Felipe's response to my patch for more info. There was also another discussion about this, see [2]. Christian [1] http://marc.info/?t=1394061r=1w=2 [2] http://marc.info/?t=13952576757r=1w=2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] ehci_msm fixes for APQ8064 USB host support.
Is it possible to queue these patches for next rc? Thanks, srini On 18/06/14 18:00, Srinivas Kandagatla wrote: While testing usb host on Qualcomm APQ8064, I encountered few issues. These patches fixes those issues. Without these patches USB is not functional on AQ8064. All the patches are tested on IFC6410. Thanks, srini Srinivas Kandagatla (3): usb: Kconfig: make EHCI_MSM selectable for QCOM SOCs usb: phy: msm: Make phy_reset clk and reset line optional. usb: phy: msm: Do not do runtime pm if the phy is not idle drivers/usb/host/Kconfig | 2 +- drivers/usb/phy/phy-msm-usb.c | 14 -- 2 files changed, 9 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Sachin, On Thu, Jun 26, 2014 at 11:09 AM, Sachin Kamat sachin.ka...@samsung.com wrote: EHCI and OHCI drivers on Exynos platforms do not work without their corresponding SoC specific phy drivers. Hence it makes no sense to keep these phy drivers as user selectable. Instead select them from the respective USB configs to make things easier for the end user. While at it enable 5250 phy for Exynos 5420 SoC too. Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- drivers/phy/Kconfig | 37 +++-- drivers/usb/host/Kconfig | 10 ++ 2 files changed, 13 insertions(+), 34 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 16a2f067c242..7fe7ef5f1322 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -121,44 +121,21 @@ config PHY_SUN4I_USB parts, as well as the 2 regular USB 2 host PHYs. config PHY_SAMSUNG_USB2 - tristate Samsung USB 2.0 PHY driver + tristate select GENERIC_PHY select MFD_SYSCON - help - Enable this to support the Samsung USB 2.0 PHY driver for Samsung - SoCs. This driver provides the interface for USB 2.0 PHY. Support for - particular SoCs has to be enabled in addition to this driver. Number - and type of supported phys depends on the SoC. + select PHY_EXYNOS4210_USB2 if CPU_EXYNOS4210 + select PHY_EXYNOS4X12_USB2 if (SOC_EXYNOS4212 || SOC_EXYNOS4412) + select PHY_EXYNOS5250_USB2 if (SOC_EXYNOS5250 || SOC_EXYNOS5420) also || SOC_EXYNOS5800 same controller present on Exynos5800 too. config PHY_EXYNOS4210_USB2 - bool Support for Exynos 4210 - depends on PHY_SAMSUNG_USB2 - depends on CPU_EXYNOS4210 - help - Enable USB PHY support for Exynos 4210. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4210 four - phys are available - device, host, HSIC0 and HSIC1. + bool config PHY_EXYNOS4X12_USB2 - bool Support for Exynos 4x12 - depends on PHY_SAMSUNG_USB2 - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) - help - Enable USB PHY support for Exynos 4x12. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4x12 four - phys are available - device, host, HSIC0 and HSIC1. + bool config PHY_EXYNOS5250_USB2 - bool Support for Exynos 5250 - depends on PHY_SAMSUNG_USB2 - depends on SOC_EXYNOS5250 - help - Enable USB PHY support for Exynos 5250. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 5250 four - phys are available - device, host, HSIC0 and HSIC. + bool config PHY_EXYNOS5_USBDRD tristate Exynos5 SoC series USB DRD PHY driver diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 61b7817bd66b..2938807331de 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -211,10 +211,11 @@ config USB_EHCI_SH If you use the PCI EHCI controller, this option is not necessary. config USB_EHCI_EXYNOS - tristate EHCI support for Samsung S5P/EXYNOS SoC Series - depends on PLAT_S5P || ARCH_EXYNOS - help - Enable support for the Samsung Exynos SOC's on-chip EHCI controller. + tristate EHCI support for Samsung S5P/EXYNOS SoC Series + depends on PLAT_S5P || ARCH_EXYNOS + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS + help + Enable support for the Samsung Exynos SOC's on-chip EHCI controller. config USB_EHCI_MV bool EHCI support for Marvell PXA/MMP USB controller @@ -520,6 +521,7 @@ config USB_OHCI_SH config USB_OHCI_EXYNOS tristate OHCI support for Samsung S5P/EXYNOS SoC Series depends on PLAT_S5P || ARCH_EXYNOS + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS help Enable support for the Samsung Exynos SOC's on-chip OHCI controller. rest looks fine. -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Vivek, On Thu, Jun 26, 2014 at 1:39 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Hi Sachin, On Thu, Jun 26, 2014 at 11:09 AM, Sachin Kamat sachin.ka...@samsung.com wrote: EHCI and OHCI drivers on Exynos platforms do not work without their corresponding SoC specific phy drivers. Hence it makes no sense to keep these phy drivers as user selectable. Instead select them from the respective USB configs to make things easier for the end user. While at it enable 5250 phy for Exynos 5420 SoC too. snip + select PHY_EXYNOS4210_USB2 if CPU_EXYNOS4210 + select PHY_EXYNOS4X12_USB2 if (SOC_EXYNOS4212 || SOC_EXYNOS4412) + select PHY_EXYNOS5250_USB2 if (SOC_EXYNOS5250 || SOC_EXYNOS5420) also || SOC_EXYNOS5800 same controller present on Exynos5800 too. Thanks. Will add. snip @@ -520,6 +521,7 @@ config USB_OHCI_SH config USB_OHCI_EXYNOS tristate OHCI support for Samsung S5P/EXYNOS SoC Series depends on PLAT_S5P || ARCH_EXYNOS + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS help Enable support for the Samsung Exynos SOC's on-chip OHCI controller. rest looks fine. Thanks. Sachin. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Sachin, On Thursday 26 June 2014 11:09 AM, Sachin Kamat wrote: EHCI and OHCI drivers on Exynos platforms do not work without their corresponding SoC specific phy drivers. Hence it makes no sense to keep these phy drivers as user selectable. Instead select them from the respective USB configs to make things easier for the end user. While at it enable 5250 phy for Exynos 5420 SoC too. Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- drivers/phy/Kconfig | 37 +++-- drivers/usb/host/Kconfig | 10 ++ 2 files changed, 13 insertions(+), 34 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 16a2f067c242..7fe7ef5f1322 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig snip config USB_EHCI_EXYNOS - tristate EHCI support for Samsung S5P/EXYNOS SoC Series - depends on PLAT_S5P || ARCH_EXYNOS - help - Enable support for the Samsung Exynos SOC's on-chip EHCI controller. + tristate EHCI support for Samsung S5P/EXYNOS SoC Series + depends on PLAT_S5P || ARCH_EXYNOS + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS I am skeptical to add select after the problems it created during previous releases. Maybe use 'default y if ARCH_EXYNOS' in PHY_SAMSUNG_USB2 Kconfig? 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 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Vivek, On Thu, Jun 26, 2014 at 1:55 PM, Sachin Kamat sachin.ka...@samsung.com wrote: Hi Vivek, On Thu, Jun 26, 2014 at 1:39 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Hi Sachin, On Thu, Jun 26, 2014 at 11:09 AM, Sachin Kamat sachin.ka...@samsung.com wrote: EHCI and OHCI drivers on Exynos platforms do not work without their corresponding SoC specific phy drivers. Hence it makes no sense to keep these phy drivers as user selectable. Instead select them from the respective USB configs to make things easier for the end user. While at it enable 5250 phy for Exynos 5420 SoC too. snip + select PHY_EXYNOS4210_USB2 if CPU_EXYNOS4210 + select PHY_EXYNOS4X12_USB2 if (SOC_EXYNOS4212 || SOC_EXYNOS4412) + select PHY_EXYNOS5250_USB2 if (SOC_EXYNOS5250 || SOC_EXYNOS5420) also || SOC_EXYNOS5800 same controller present on Exynos5800 too. Just checked that SOC_EXYNOS5800 is dependent on SOC_EXYNOS5420. Hence explicit option for SOC_EXYNOS5800 is redundant here. Will keep it as is. Regards, Sachin. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: gr_udc: Fix check for invalid number of microframes
The invalid value that should not be let through is 0x3 (4 transactions
per microframe).
Reported-by: David Binderman dcb...@hotmail.com
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
drivers/usb/gadget/gr_udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 99a37ed..4c5faca 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -1532,7 +1532,7 @@ static int gr_ep_enable(struct usb_ep *_ep,
%s mode: multiple trans./microframe not valid\n,
(mode == 2 ? Bulk : Control));
return -EINVAL;
- } else if (nt == 0x11) {
+ } else if (nt == 0x3) {
dev_err(dev-dev, Invalid value for trans./microframe\n);
return -EINVAL;
} else if ((nt + 1) * max buffer_size) {
--
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 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Kishon, On Thu, Jun 26, 2014 at 2:19 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Sachin, On Thursday 26 June 2014 11:09 AM, Sachin Kamat wrote: EHCI and OHCI drivers on Exynos platforms do not work without their corresponding SoC specific phy drivers. Hence it makes no sense to keep these phy drivers as user selectable. Instead select them from the respective USB configs to make things easier for the end user. While at it enable 5250 phy for Exynos 5420 SoC too. Signed-off-by: Sachin Kamat sachin.ka...@samsung.com Cc: Kishon Vijay Abraham I kis...@ti.com --- drivers/phy/Kconfig | 37 +++-- drivers/usb/host/Kconfig | 10 ++ 2 files changed, 13 insertions(+), 34 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 16a2f067c242..7fe7ef5f1322 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig snip config USB_EHCI_EXYNOS - tristate EHCI support for Samsung S5P/EXYNOS SoC Series - depends on PLAT_S5P || ARCH_EXYNOS - help - Enable support for the Samsung Exynos SOC's on-chip EHCI controller. + tristate EHCI support for Samsung S5P/EXYNOS SoC Series + depends on PLAT_S5P || ARCH_EXYNOS + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS I am skeptical to add select after the problems it created during previous releases. If you could point me to some link/discussion about this, I could check if such problem is applicable here. IMHO, there shouldn't be any in this case. Maybe use 'default y if ARCH_EXYNOS' in PHY_SAMSUNG_USB2 Kconfig? I would prefer to use this option only if there is a strong objection to doing it the current way as I do not see any benefits of exposing the PHY entries that are only prerequisites for the USB functionality (in this case) to users. Regards, Sachin. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] usb: gadget: pxa27x_udc device-tree documentation
On Wed, Jun 25, 2014 at 08:54:01PM +0100, Robert Jarzmik wrote:
Mark Rutland mark.rutl...@arm.com writes:
On Sun, Jun 22, 2014 at 10:04:58AM +0100, Robert Jarzmik wrote:
index 79729a9..0e4863f 100644
--- a/Documentation/devicetree/bindings/usb/pxa-usb.txt
+++ b/Documentation/devicetree/bindings/usb/pxa-usb.txt
@@ -29,3 +29,23 @@ Example:
marvell,port-mode = 2; /* PMM_GLOBAL_MODE */
};
+UDC
+
+Required properties:
+ - compatible: Should be marvell,pxa27x-udc for USB controllers
+ used in device mode.
We typically don't like wildcard compatible strings in DT.
Same as in the other patch, marvell,pxa270-udc.
+
+Optional properties:
+ - udc-pullup-gpio - gpio activated to control the USB D+ pullup.
+ - udc-pullup-gpio-inverted - boolean inverting gpio pullup logic.
Use the GPIO bindings.
OK. I'm presuming in this case you think of something like :
udc-pullup-gpio = gpio 22 GPIO_ACTIVE_LOW
Which translates into:
udc-pullup-gpio - gpio activated to control the USB D+ pullup (see
gpio.txt)
Something like that, yes.
+
+Example:
+
+ pxa27x_udc: udc@4060 {
+ compatible = marvell,pxa27x-udc;
+ reg = 0x4060 0x1;
+ interrupts = 11;
+ clocks = pxa2xx_clks 11;
+ clock-names = pxa27x-udc;
Neither of these were mentioned above.
Ah you mean I shall describe the standard reg, interrupts as mandatory
standard
options I take it. OK.
Yes. While the properties are standard, their precise meanings (e.g.
which interrupt or address space region), and whether a particular
binding uses them is not.
The name of the clock input doesn't make sense.
I don't understand. With [1] does it make any more sense ? If not you'll have
to
expand a bit more the doesn't make sense.
My concern is that clock-names is supposed to describe the name of the
input clock line from the view of the IP block. pxa27x-udc doesn't
sound like the name of a clock input line from the view of the UDC
block.
I assume the clock input line you care about has a more specific name
than pxa27x-udc?
Cheers,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Sachin, On Thu, Jun 26, 2014 at 2:23 PM, Sachin Kamat sachin.ka...@samsung.com wrote: Hi Vivek, On Thu, Jun 26, 2014 at 1:55 PM, Sachin Kamat sachin.ka...@samsung.com wrote: Hi Vivek, On Thu, Jun 26, 2014 at 1:39 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Hi Sachin, On Thu, Jun 26, 2014 at 11:09 AM, Sachin Kamat sachin.ka...@samsung.com wrote: EHCI and OHCI drivers on Exynos platforms do not work without their corresponding SoC specific phy drivers. Hence it makes no sense to keep these phy drivers as user selectable. Instead select them from the respective USB configs to make things easier for the end user. While at it enable 5250 phy for Exynos 5420 SoC too. snip + select PHY_EXYNOS4210_USB2 if CPU_EXYNOS4210 + select PHY_EXYNOS4X12_USB2 if (SOC_EXYNOS4212 || SOC_EXYNOS4412) + select PHY_EXYNOS5250_USB2 if (SOC_EXYNOS5250 || SOC_EXYNOS5420) also || SOC_EXYNOS5800 same controller present on Exynos5800 too. Just checked that SOC_EXYNOS5800 is dependent on SOC_EXYNOS5420. Hence explicit option for SOC_EXYNOS5800 is redundant here. Will keep it as is. Aah ! right, it's fine then. Sorry for the noise. -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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: gr_udc: Fix check for invalid number of microframes
Hello there,
The invalid value that should not be let through is 0x3 (4 transactions
per microframe).
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -1532,7 +1532,7 @@ static int gr_ep_enable(struct usb_ep *_ep,
%s mode: multiple trans./microframe not valid\n,
(mode == 2 ? Bulk : Control));
return -EINVAL;
- } else if (nt == 0x11) {
+ } else if (nt == 0x3) {
dev_err(dev-dev, Invalid value for trans./microframe\n);
return -EINVAL;
} else if ((nt + 1) * max buffer_size) {
--
1.7.10.4
When some value is out of band, I usually try to arrange that
the error message shows the value and, if possible, the band limits.
Suggest rework error message in call to dev_err. Maybe
dev_err(dev-dev, Invalid value '0x3' for transactions per microframe\n);
would be better.
Regards
David Binderman
--
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 audio breaks ohci-pci
On Tue, 24 Jun 2014 15:35:06 -0400 (EDT), Alan Stern wrote: On Fri, 20 Jun 2014, Dennis New wrote: However, lsusb does not work, and I cannot kill it -- it remains in D (uninterruptible sleep) state. I am also unable to rmmod the snd_usb_audio module -- rmmod gets stuck in D state too. When I tried echoing (:00:13.0) to ohci_pci/unbind, although dmesg says: [140078.654462] ohci-pci :00:13.0: remove, state 1 [140078.654480] usb usb2: USB disconnect, device number 1 ... the echo command (a bash internal) does not terminate, and also gets stuck in D state. Although the symlink to :00:13.0 does get removed from that directory. But trying to echo this back to ohci_pci/bind doesn't work: write error: No such device Even though :00:13.0 is still listed in /sys/kernel/debug/usb/ohci. Try to cat /sys/kernel/debug/usb/devices also fails, and cat gets stuck in D state too. My usb thumbdrive also no longer works after this occurs, although I'm pretty sure it uses EHCI. I'm forced to reboot to get usb working again :s. Here's a revised patch for you to try. This is meant to apply on top of 3.15. As it turns out, when I tested this, it revealed a bug in the USB audio driver. So I'm including a work-around for that bug at the start of the patch. The bug seems to have been largely fixed with this patch!!1 Although ohci (and/or the usb audio device) does still crash, it does so gracefully. mplayer and lsusb, etc continue working, unlike before. I am still able to plug the usb device into another port, and it will work, using :00:13.1. I no longer seem to get the timeout: still 2 active urbs on EP #3 messages. [39209.542786] ohci-pci :00:13.0: HcDoneHead not written back; disabled [39209.542796] ohci-pci :00:13.0: HC died; cleaning up [39209.542898] usb 2-4: USB disconnect, device number 5 /sys/kernel/debug/usb/ohci/...13.0/registers when crashed says: bus pci, device :00:13.0 OHCI PCI host controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state halted control 0x283 RWC HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0064 RHSC FNO SF intrenable 0x0004 SF hcca frame 0x2e8d fmintvl 0x27782edf FSMPS=0x2778 FI=0x2edf fmremaining 0x04c5 FR=0x04c5 periodicstart 0x lsthresh 0x0628 hub poll timer off roothub.a 02000204 POTPGT=2 NPS NDP=4(4) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS roothub.portstatus [2] 0x0100 PPS roothub.portstatus [3] 0x00030100 PESC CSC PPS (although the hcca frame counter is stopped, the fmremaining/FR values are changing.) echo :00:13.0 /sys/bus/pci/drivers/ohci_pci/unbind [39522.284135] ohci-pci :00:13.0: remove, state 1 [39522.284152] usb usb2: USB disconnect, device number 1 [39522.285706] ohci-pci :00:13.0: USB bus 2 deregistered echo :00:13.0 /sys/bus/pci/drivers/ohci_pci/bind [39530.642947] ohci-pci :00:13.0: OHCI PCI host controller [39530.643269] ohci-pci :00:13.0: new USB bus registered, assigned bus number 2 [39530.643323] ohci-pci :00:13.0: irq 19, io mem 0xc000 [other plugged-in ohci devices (i.e. 4port hub) detected] I wonder if this unbind'ing and bind'ing should be done automatically, when a crash is detected? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: gadget: gr_udc: Fix check for invalid number of microframes
The value 0x3 (not 0x11) in the field for additional transaction/microframe
is reserved and should not be let through. Be clear in the error message about
what value caused the error return.
Reported-by: David Binderman dcb...@hotmail.com
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
drivers/usb/gadget/gr_udc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 99a37ed..c7004ee 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -1532,8 +1532,9 @@ static int gr_ep_enable(struct usb_ep *_ep,
%s mode: multiple trans./microframe not valid\n,
(mode == 2 ? Bulk : Control));
return -EINVAL;
- } else if (nt == 0x11) {
- dev_err(dev-dev, Invalid value for trans./microframe\n);
+ } else if (nt == 0x3) {
+ dev_err(dev-dev,
+ Invalid value 0x3 for additional trans./microframe\n);
return -EINVAL;
} else if ((nt + 1) * max buffer_size) {
dev_err(dev-dev, Hw buffer size %d max payload %d * %d\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: Fwd: Problem with Etron EJ168 USB3.0 Host Controller connected to USB 2.0 HUB and mouse/keyboard
On 06/26/2014 09:30 AM, Carsten Koepp wrote: Hi Mathias, at first I sent this email to Sarah, but now I found out that the maintainership has changed. Hope you can help me with the problem described below. I say best thanks in advance and looking forward to your response. Hi Carsten, Can you add xhci debugging and try with a recent kernel (preferrably 3.16 release candidate, or 3.15): Have CONFIG_DYNAMIC_DEBUG turned on and run `echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control` as root, and send me the output. I now remember there's another Etron host bug with not enought bandwidth, probably related https://bugzilla.kernel.org/show_bug.cgi?id=70531 -Mathias (keeping rest of the message here for reference) Original-Nachricht Betreff: Problem with Etron EJ168 USB3.0 Host Controller connected to USB 2.0 HUB and mouse/keyboard Datum: Tue, 24 Jun 2014 11:14:50 +0200 Von: Carsten Koepp cko...@lxco.com An: sarah.a.sh...@intel.com Hi Sarah, from what I've found on the internet your are the maintainer of the xHCI driver in the linux kernel, right? So I hope you can help me to fix the problem I've found. I'm facing a problem with the Etron EJ168 Host Controller chip. When I connect an USB-2.0 HUB with mouse and keyboard to the USB-3.0 ports on the mainboard I get this bandwith errors (pls. see below). The devices doesn't work then. Mouse and keyboard connected directly to the USB-3.0 works fine. For some reasons I need it working exactly in the setup where it fails. Using other ports (e.g. USB-2.0) or no HUB is unfortunately not a solution for me. Just for testing purpose I also tried a USB-3.0-HUB and run into the same problem. As you can see below I checked it in different combinations (wheezy, jessie, different kernel versions and different hardware) and all failed with the same error messages. If you need any further informations or I could drive some additional tests for you please tell me. Furthermore I can apply your patches, build new drivers or kernels and give you the feedback. I just say best thanks in advance and looking forward to your response. Best regards, Carsten --- Hardware (two computers with the same mainboard): Mainboard: Manufacturer: Gigabyte Technology Co., Ltd. Product Name: GA-990FXA-UD5 02:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) (prog-if 30 [XHCI]) 05:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) (prog-if 30 [XHCI]) USB-Hubs: D-Link USB 2.0, i-tec USB 2.0 and i-tec USB 3.0 Keyboard: Holtek Semiconductor, Inc. Mouse:Afilias Optical Mouse H3003 and Logitech laser mouse Software: OS: Debian wheezy and Debian jessie Linux kernel 3.13, 3.14 and 3.16. Errors with D-Link USB 2.0 HUB connected to USB 3.0 ports Mainboard USB 3.0-port - USB 2.0 HUB - mouse keyboard Jun 24 09:19:20 jessie kernel: [ 5043.828303] usb 2-1: new high-speed USB device number 12 using xhci_hcd Jun 24 09:19:20 jessie kernel: [ 5043.959146] usb 2-1: New USB device found, idVendor=05e3, idProduct=0608 Jun 24 09:19:20 jessie kernel: [ 5043.959158] usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 Jun 24 09:19:20 jessie kernel: [ 5043.959165] usb 2-1: Product: USB2.0 Hub Jun 24 09:19:20 jessie kernel: [ 5043.960030] hub 2-1:1.0: USB hub found Jun 24 09:19:20 jessie kernel: [ 5043.960480] hub 2-1:1.0: 4 ports detected Jun 24 09:19:20 jessie kernel: [ 5044.232321] usb 2-1.1: new low-speed USB device number 13 using xhci_hcd Jun 24 09:19:20 jessie kernel: [ 5044.328127] usb 2-1.1: New USB device found, idVendor=05e3, idProduct=1205 Jun 24 09:19:20 jessie kernel: [ 5044.328139] usb 2-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 Jun 24 09:19:20 jessie kernel: [ 5044.328145] usb 2-1.1: Product: USB Mouse Jun 24 09:19:20 jessie kernel: [ 5044.328464] usb 2-1.1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes Jun 24 09:19:20 jessie kernel: [ 5044.328505] usb 2-1.1: Not enough bandwidth for new device state. Jun 24 09:19:20 jessie kernel: [ 5044.328517] usb 2-1.1: can't set config #1, error -28 Jun 24 09:19:20 jessie kernel: [ 5044.400194] usb 2-1.2: new low-speed USB device number 14 using xhci_hcd Jun 24 09:19:20 jessie kernel: [ 5044.526986] usb 2-1.2: New USB device found, idVendor=04d9, idProduct=1603 Jun 24 09:19:20 jessie kernel: [ 5044.526998] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jun 24 09:19:20 jessie kernel: [ 5044.527005] usb 2-1.2: Product: USB Keyboard Jun 24 09:19:20 jessie kernel: [ 5044.527011] usb 2-1.2: Manufacturer: Jun 24 09:19:20 jessie kernel: [ 5044.527341] usb 2-1.2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes Jun 24 09:19:20
how to firing device event when SD card inserting usb card reader
hi all: I try below flow: 1. plug in usb card reader 2. wait 2 seconds 3. plug in SD card on ubuntu PC system, the udev can get SD plug in event but on my embedded system, there is no udev plug event when SD plug in. Is this issue related to media change command? if so, should I enable kernel config or do anything in user mode program? thanks for your help in advance, -- 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] Change wMaxPacketSize default value for Full Speed EP0
On Wed, 25 Jun 2014, Stalley, Sean wrote: -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Wednesday, June 25, 2014 11:46 AM To: Stalley, Sean Cc: linux-usb@vger.kernel.org; Ismail, Abdul R Subject: Re: [PATCH] Change wMaxPacketSize default value for Full Speed EP0 On Wed, 25 Jun 2014, Sean O. Stalley wrote: From: Sean O. Stalley sean.stal...@intel.com Change the default wMaxPacketSize value for EP0 of Full Speed devices from the maximum possible size (64) to the minimum (8). All full speed devices support a packet size of 8, but not all support a size of 64. You don't seem to understand what you are saying. Supporting a packet size of 8 is very different from having a maxpacket size of 8. I suppose I could have phrased that better. What I meant to say was: I do not understand why one would make the default wMaxPacketSize for EP0 of a full speed device 64. To me, making the default 8 makes more sense. Neither 8 nor 64 is the default. 64 is merely the initial value; it gets updated later when we read the correct value from the device. 8 won't work with the new initialization scheme. Consider what the scheme does: It sends a Get-Device-Descriptor request with a transfer length of 64. Since the descriptor is only 18 bytes long, the device will try to send back an 18-byte reply. If the actual maxpacket size is 64, the device will do this by sending the entire reply in a single 18-byte packet. But if we set the initial maxpacket value in the host controller to 8, the reply would fail with a Babble error because 18 8. No packet longer than 8 bytes is ever read from EP0 before this value is changed from the default. That is not true. You are right, that statement is only true when using the old scheme. Would setting wMaxPacketSize conditionally (based on using the old/new scheme) be preferred? Well, it would work. But it wouldn't be preferred. Why go to the extra trouble? It's easier to set the initial value to 64 always. 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: usb audio breaks ohci-pci
On Thu, 26 Jun 2014, Dennis New wrote: Here's a revised patch for you to try. This is meant to apply on top of 3.15. As it turns out, when I tested this, it revealed a bug in the USB audio driver. So I'm including a work-around for that bug at the start of the patch. The bug seems to have been largely fixed with this patch!!1 Although ohci (and/or the usb audio device) does still crash, it does so gracefully. mplayer and lsusb, etc continue working, unlike before. I am still able to plug the usb device into another port, and it will work, using :00:13.1. I no longer seem to get the timeout: still 2 active urbs on EP #3 messages. [39209.542786] ohci-pci :00:13.0: HcDoneHead not written back; disabled [39209.542796] ohci-pci :00:13.0: HC died; cleaning up [39209.542898] usb 2-4: USB disconnect, device number 5 That sounds like it's doing the right thing. /sys/kernel/debug/usb/ohci/...13.0/registers when crashed says: bus pci, device :00:13.0 OHCI PCI host controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state halted control 0x283 RWC HCFS=operational CBSR=3 cmdstatus 0x0 SOC=0 intrstatus 0x0064 RHSC FNO SF intrenable 0x0004 SF hcca frame 0x2e8d fmintvl 0x27782edf FSMPS=0x2778 FI=0x2edf fmremaining 0x04c5 FR=0x04c5 periodicstart 0x lsthresh 0x0628 hub poll timer off roothub.a 02000204 POTPGT=2 NPS NDP=4(4) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0100 PPS roothub.portstatus [1] 0x0100 PPS roothub.portstatus [2] 0x0100 PPS roothub.portstatus [3] 0x00030100 PESC CSC PPS (although the hcca frame counter is stopped, the fmremaining/FR values are changing.) Doesn't matter. echo :00:13.0 /sys/bus/pci/drivers/ohci_pci/unbind [39522.284135] ohci-pci :00:13.0: remove, state 1 [39522.284152] usb usb2: USB disconnect, device number 1 [39522.285706] ohci-pci :00:13.0: USB bus 2 deregistered echo :00:13.0 /sys/bus/pci/drivers/ohci_pci/bind [39530.642947] ohci-pci :00:13.0: OHCI PCI host controller [39530.643269] ohci-pci :00:13.0: new USB bus registered, assigned bus number 2 [39530.643323] ohci-pci :00:13.0: irq 19, io mem 0xc000 [other plugged-in ohci devices (i.e. 4port hub) detected] I wonder if this unbind'ing and bind'ing should be done automatically, when a crash is detected? That's a separate discussion. To a large degree it doesn't matter, because most hardware is designed not to crash during use. In fact, if you wanted to, you could write a shell script that would monitor your system, looking for one of these crashes maybe once every few seconds. When a crash occurred, the script could then do the unbind and rebind. It doesn't need to be handled automatically in the kernel. 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: USB_MUSB_DA8XX with g_multi.ko
On Thu, Jun 26, 2014 at 2:29 AM, Christian Riesch christian.rie...@omicron.at wrote: Hi Jon, On Thu, Jun 26, 2014 at 4:46 AM, Jon Ringle j...@ringle.org wrote: The only thing I needed to do was to remove the BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would have to do besides just removing BROKEN to get this accepted back into the kernel source tree? I tried to remove the BROKEN dependency in [1], but without success. See Felipe's response to my patch for more info. There was also another discussion about this, see [2]. Christian [1] http://marc.info/?t=1394061r=1w=2 [2] http://marc.info/?t=13952576757r=1w=2 Thanks for the additional info. Since my primary interest is in getting this working on the 3.12 tree, and the drivers/phy/ source directory had not been added yet at this point in the history, I am not motivated enough to implement Felipe's suggestion of moving phy_on()/phy_off() to a drivers/usb/phy-da8xx.c. If sometime down the road, we decided to move to a newer kernel release, and the work hasn't been done yet, then I'll have a greater motivation to implement something along those lines. For now I will live with just removing BROKEN from our local kernel tree. Jon -- 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: how to firing device event when SD card inserting usb card reader
On Thu, 26 Jun 2014, loody wrote: hi all: I try below flow: 1. plug in usb card reader 2. wait 2 seconds 3. plug in SD card on ubuntu PC system, the udev can get SD plug in event but on my embedded system, there is no udev plug event when SD plug in. Is this issue related to media change command? if so, should I enable kernel config or do anything in user mode program? thanks for your help in advance, What does usbmon 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
[PATCH 1/1] drivers/usb/host/fhci-dbg.c: remove unnecessary null test before debugfs_remove
This fixes checkpatch warning: WARNING: debugfs_remove(NULL) is safe this check is probably not required Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-usb@vger.kernel.org Signed-off-by: Fabian Frederick f...@skynet.be --- drivers/usb/host/fhci-dbg.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/fhci-dbg.c b/drivers/usb/host/fhci-dbg.c index f238cb3..b58e7a6 100644 --- a/drivers/usb/host/fhci-dbg.c +++ b/drivers/usb/host/fhci-dbg.c @@ -129,11 +129,7 @@ void fhci_dfs_destroy(struct fhci_hcd *fhci) if (!fhci-dfs_root) return; - if (fhci-dfs_irq_stat) - debugfs_remove(fhci-dfs_irq_stat); - - if (fhci-dfs_regs) - debugfs_remove(fhci-dfs_regs); - + debugfs_remove(fhci-dfs_irq_stat); + debugfs_remove(fhci-dfs_regs); debugfs_remove(fhci-dfs_root); } -- 1.8.4.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: [PATCH v1 6/9] usb: xhci: Add NVIDIA Tegra XHCI host-controller driver
On 06/25/2014 06:06 PM, Andrew Bresticker wrote:
On Wed, Jun 25, 2014 at 3:37 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
Add support for the on-chip XHCI host controller present on Tegra SoCs.
The driver is currently very basic: it loads the controller with its
firmware, starts the controller, and is able to service messages sent
by the controller's firmware. The hardware supports device mode as
well as runtime power-gating, but support for these is not yet
implemented here.
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
+static int tegra_xhci_set_ss_clk(struct tegra_xhci_hcd *tegra,
+ unsigned long rate)
+ switch (rate) {
+ case TEGRA_XHCI_SS_CLK_HIGH_SPEED:
+ /* Reparent to PLLU_480M. Set div first to avoid overclocking
*/
+ old_parent_rate = clk_get_rate(clk_get_parent(clk));
+ new_parent_rate = clk_get_rate(tegra-pll_u_480m);
+ div = new_parent_rate / rate;
+ ret = clk_set_rate(clk, old_parent_rate / div);
+ if (ret)
+ return ret;
+ ret = clk_set_parent(clk, tegra-pll_u_480m);
+ if (ret)
+ return ret;
Don't you need to call clk_set_rate() again after reparenting, since the
divisor will be different, and the rounding too.
Nope, the divider we set before remains in-tact after clk_set_parent().
Oh I see, the clk_set_rate() call is setting up div so it's appropriate
after the new parent is selected.
Wouldn't it be better to just stop the clock, assert reset, reparent the
clock, and then set the desired rate directly?
--
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 v1 4/9] pinctrl: tegra-xusb: Add USB PHY support
On 06/25/2014 05:30 PM, Andrew Bresticker wrote:
On Wed, Jun 25, 2014 at 3:12 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
In addition to the PCIe and SATA PHYs, the XUSB pad controller also
supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single
PCIe or SATA lane and is mapped to one of the three UTMI ports.
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
b/drivers/pinctrl/pinctrl-tegra-xusb.c
@@ -372,6 +720,193 @@ static int tegra_xusb_padctl_pinconf_group_set(struct
pinctrl_dev *pinctrl,
padctl_writel(padctl, regval, lane-offset);
break;
+ case TEGRA_XUSB_PADCTL_USB3_PORT_NUM:
+ if (value = TEGRA_XUSB_PADCTL_USB3_PORTS) {
+ dev_err(padctl-dev, Invalid USB3 port:
%lu\n,
+ value);
+ return -EINVAL;
+ }
+ if (!is_pcie_sata_lane(group)) {
+ dev_err(padctl-dev,
+ USB3 port not applicable for pin
%d\n,
+ group);
+ return -EINVAL;
+ }
+ padctl-usb3_ports[value].lane = group;
+ break;
It feels odd to use pinctrl for a SW-only purpose. In other words, that
chunk of code isn't writing the pinconf data to HW, but rather some
internal variable.
Well the mapping of lanes to USB3 ports is a hardware property and we
do use it when programming the hardware later to choose which set of
lane registers to program given a USB3 port, but it's true that it's
not some value we program into HW directly.
Perhaps it would make more sense for the DT binding to represent this
data directly in a custom property that's parsed at probe() time. That
way, pinctrl only touches real HW stuff.
I'm on the fence about this. If you or others feel strongly about
this then I can make it a separate DT property and move it out of the
pinctrl properties.
I'd certainly prefer to use pinctrl bindings only for things that get
directly written into HW. Other configuration data should be easy to
retrieve directly from properties.
--
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] Change wMaxPacketSize default value for Full Speed EP0
-Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Wednesday, June 25, 2014 8:50 PM To: Stalley, Sean Cc: Alan Stern; linux-usb@vger.kernel.org; Ismail, Abdul R Subject: Re: [PATCH] Change wMaxPacketSize default value for Full Speed EP0 On Wed, Jun 25, 2014 at 09:11:25PM +, Stalley, Sean wrote: Changing the default max packet size to 8 helps clarify that. No. Did you test this patch with full-speed devices having various maxpacket sizes? I was waiting for feedback on the patch before I did any in-depth testing. So, you want us to do your work for you? Sorry, not going to happen. *plonk* I wasn't expecting you to do the work, I am more than willing to test the change. I guess I should have released this as RFC... -- 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 v1 3/9] of: Update Tegra XUSB pad controller binding for USB
On 06/25/2014 04:25 PM, Andrew Bresticker wrote: Thanks for the review Stephen! On Wed, Jun 25, 2014 at 2:46 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/18/2014 12:16 AM, Andrew Bresticker wrote: Add new bindings used for USB support by the Tegra XUSB pad controller. This includes additional PHY types, USB-specific pinconfig properties, etc. diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt @@ -21,6 +21,12 @@ Required properties: - padctl - #phy-cells: Should be 1. The specifier is the index of the PHY to reference. See dt-bindings/pinctrl/pinctrl-tegra-xusb.h for the list of valid values. +- nvidia,xusb-mbox: Handle to the Tegra XUSB mailbox node. Why does the padctrl code need access to the XUSB mailbox? The XUSB firmware sends messages which make requests of the PHY (XUSB pad controller), such as idling/un-idling the HSIC PHYs or saving USB3 PHY context. Isn't the padctrl HW module something that provides services to the XUSB code. I would have expected the XUSB node to reference the padctrl node. The XUSB padctrl HW does provide services to the XUSB host in the form of PHYs and it is through the PHY bindings that the host references the padctrl node. If notifications need to be sent back from XUSB padctrl to XUSB, then that seems like an internal SW detail that doesn't need to be represented in DT. I think you mean notifications need to be sent back from the XUSB host to the XUSB padctrl? This is what the mailbox is for and I chose to have the padctrl refer to the mailbox since messages are sent from the mailbox which make requests to the PHY specifically and not the host (see above). I've looked at the details of the mailbox messages a bit more now. It seems that the firmware running on the XUSB controller sends a variety of different messages, some of which are relevant to the XHCI controller driver and some relevant to the PHY/PAD driver. It's a pity these different message streams are intermixed, but I guess that's not changing. As such, I think at this stage it does make sense for the mailbox to be represented as a separate node, with each of the XHCI controller and USB PADCTL nodes referring to the mailbox node by phandle. I'm still not 100% sure about whether the PHY driver is the same level of abstraction intended by the Linux kernel's PHY layer. Pending that discussion's results, the PHY message from the firmware may not go to a Linux kernel PHY but some layer above which might get subsumed into the overall XHCI controller driver, which would change my argument above a bit. -- 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 2/2] usb: chipidea: Add support for zynq usb host and device controller
Zynq soc usb controller is a synopsys IP and it is compatible
with the chipidea spec. So, reusing chipidea drivers for zynq usb
controller.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
drivers/usb/chipidea/Makefile |1 +
drivers/usb/chipidea/ci_hdrc_zynq.c | 115 +++
2 files changed, 116 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/chipidea/ci_hdrc_zynq.c
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 2f099c7..b0d6b6f 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -12,6 +12,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_msm.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
+obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zynq.o
# PCI doesn't provide stubs, need to check
ifneq ($(CONFIG_PCI),)
diff --git a/drivers/usb/chipidea/ci_hdrc_zynq.c
b/drivers/usb/chipidea/ci_hdrc_zynq.c
new file mode 100644
index 000..b3667da
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_zynq.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2014 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/usb/chipidea.h
+
+#include ci.h
+
+#define ZYNQ_USB_DMA_MASK 0xFFF0
+
+struct ci_hdrc_zynq_data {
+ struct platform_device *ci_pdev;
+ struct clk *clk;
+};
+
+static struct ci_hdrc_platform_data pdata = {
+ .name = ci_hdrc_zynq,
+ .capoffset = DEF_CAPOFFSET,
+ .flags = CI_HDRC_REQUIRE_TRANSCEIVER
+};
+
+static int ci_hdrc_zynq_probe(struct platform_device *pdev)
+{
+ struct ci_hdrc_zynq_data *data;
+ int ret;
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev, Failed to allocate ci_hdrc-imx data!\n);
+ return -ENOMEM;
+ }
+
+ data-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(data-clk)) {
+ dev_err(pdev-dev,
+ Failed to get clock, err=%ld\n, PTR_ERR(data-clk));
+ return PTR_ERR(data-clk);
+ }
+
+ ret = clk_prepare_enable(data-clk);
+ if (ret) {
+ dev_err(pdev-dev,
+ Failed to prepare or enable clock, err=%d\n, ret);
+ return ret;
+ }
+
+ ret = dma_coerce_mask_and_coherent(pdev-dev, ZYNQ_USB_DMA_MASK);
+ if (ret)
+ goto err_clk;
+
+ data-ci_pdev = ci_hdrc_add_device(pdev-dev,
+ pdev-resource, pdev-num_resources,
+ pdata);
+ if (IS_ERR(data-ci_pdev)) {
+ ret = PTR_ERR(data-ci_pdev);
+ dev_err(pdev-dev,
+ Can't register ci_hdrc platform device, err=%d\n,
+ ret);
+ goto err_clk;
+ }
+
+ platform_set_drvdata(pdev, data);
+
+ pm_runtime_no_callbacks(pdev-dev);
+ pm_runtime_enable(pdev-dev);
+ return 0;
+
+err_clk:
+ clk_disable_unprepare(data-clk);
+ return ret;
+}
+
+static int ci_hdrc_zynq_remove(struct platform_device *pdev)
+{
+ struct ci_hdrc_zynq_data *data = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(pdev-dev);
+ ci_hdrc_remove_device(data-ci_pdev);
+ clk_disable_unprepare(data-clk);
+
+ return 0;
+}
+
+static const struct of_device_id ci_hdrc_zynq_dt_ids[] = {
+ { .compatible = xlnx,zynq-usb-2.20a },
+ {},
+};
+
+static struct platform_driver ci_hdrc_zynq_driver = {
+ .probe = ci_hdrc_zynq_probe,
+ .remove = ci_hdrc_zynq_remove,
+ .driver = {
+ .name = zynq_usb,
+ .owner = THIS_MODULE,
+ .of_match_table = ci_hdrc_zynq_dt_ids,
+},
+};
+
+module_platform_driver(ci_hdrc_zynq_driver);
+
+MODULE_ALIAS(platform:zynq_usb);
+MODULE_DESCRIPTION(CI HDRC ZYNQ USB binding);
+MODULE_AUTHOR(Xilinx Inc);
+MODULE_LICENSE(GPL v2);
--
1.7.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 1/2] usb: chipidea: zynq: Add device tree binding information
Document device tree binding information as required by
the ZYNQ USB controller.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
.../devicetree/bindings/usb/ci-hdrc-zynq.txt | 23
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
b/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
new file mode 100644
index 000..54bb3b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-zynq.txt
@@ -0,0 +1,23 @@
+Xilinx Zynq usb controller based on synopsys usb IP(v2.20a)
+
+Required properties:
+- compatible: should contain xlnx,zynq-usb-2.20a
+- clocks: clock provider specifier
+- reg: offset and length of the register set in the memory map
+- interrupt-parent: the phandle for the interrupt controller that services
+interrupts for this device.
+- interrupts: interrupt-specifier for the controller interrupt.
+- phy_type: should be ulpi
+- dr_mode: should be peripheral or host
+
+Examples:
+
+ usb@e0002000 {
+ clocks = clkc 28;
+ compatible = xlnx,zynq-usb-2.20a;
+ dr_mode = host;
+ interrupt-parent = ps7_scugic_0;
+ interrupts = 0 21 4;
+ phy_type = ulpi;
+ reg = 0xe0002000 0x1000;
+ } ;
--
1.7.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 v2] USB: ehci-pci: USB host controller support for Intel Quark X1000
On Friday, June 27, 2014 8:25 PM, Alvin Chen wrote:
From: Bryan O'Donoghue bryan.odonog...@intel.com
The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000
USB host
controller, and the default value is 0x20 dwords. The in/out threshold can be
programmed
to 0x80 dwords, but only when isochronous/interrupt transactions are not
initiated by
the USB host controller. This patch is to reconfigure the packet buffer
in/out threshold
as maximal as possible, and it is 0x7F dwords since the USB host controller
initiates
isochronous/interrupt transactions.
So, what is the reason to set the value as 0x80?
1. The default value 0x20 makes some problems such as...
2. To maximize the performance, ...
3. Both
Please add the reason why 0x80 is necessary, as possible.
Then, 0x7F means 508 bytes? 'Intel Quark X1000 USB host controller'
can support 0x80 (512bytes), however, in this case, isochronous/interrupt
transactions cannot be initiated by 'Intel Quark X1000 USB host controller'.
Right?
So, 0x79 (508bytes?) should be used, because the isochronous/interrupt
transactions can be initiated by 'Intel Quark X1000 USB host controller'.
Right?
Signed-off-by: Bryan O'Donoghue bryan.odonog...@intel.com
Signed-off-by: Alvin (Weike) Chen alvin.c...@intel.com
---
changelog v2:
*Change the function name from 'usb_is_intel_qrk' to
'usb_is_intel_quark_x1000'.
*Move the functions 'usb_is_intel_quark_x1000' and 'usb_set_qrk_bulk_thresh'
from 'pci-quirks.c' to 'ehci-pci.c'.
*Remove unnecessary kernel message in the function of
'usb_set_qrk_bulk_thresh'.
*Remove 'unlikely' in the functions of 'ehci_pci_reinit'.
*Add white space after 'if'.
*Update the descriptions to make it more clearly.
*Add Micros to avoid magic number.
drivers/usb/host/ehci-pci.c | 45
+++
1 file changed, 45 insertions(+)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 3e86bf4..ca29f34 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -35,6 +35,47 @@ static const char hcd_name[] = ehci-pci;
#define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
/*-*/
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC 0x0939
+static inline bool usb_is_intel_quark_x1000(struct pci_dev *pdev)
+{
+ return pdev-vendor == PCI_VENDOR_ID_INTEL
+ pdev-device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
+
Please don't add this unnecessary line.
+}
+
+/* Register offset of in/out threshold */
+#define EHCI_INSNREG01 0x84
+/* The maximal threshold is 0x80 Dword */
+#define EHCI_MAX_THRESHOLD 0X80
s/0X80/0x80
0x80 means 512 bytes. So, how about mentioning '0x80 means 512 bytes'
in this comment or the commit message?
Maybe, how about the following?
/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80
+/* Lower word is 'in' threshold, and higher word is 'out' threshold*/
+#define EHCI_INSNREG01_THRESH \
+ ((EHCI_MAX_THRESHOLD - 1)16 | (EHCI_MAX_THRESHOLD - 1))
Um, how about the following?
/* Register offset of in/out threshold */
#define EHCI_INSNREG01 0x84
/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80
#define EHCI_THRESHOLD_508BYTES 0x79
#define EHCI_THRESHOLD_OUT_SHIFT16
#define EHCI_THRESHOLD_IN_SHIFT 0
..
/*
* In order to support the isochronous/interrupt transactions,
* 508 bytes should be used as max threshold values */
*/
val = ((EHCI_THRESHOLD_512BYTES - 1) EHCI_THRESHOLD_OUT_SHIFT |
(EHCI_THRESHOLD_512BYTES - 1) EHCI_THRESHOLD_IN_SHIFT);
writel(val, op_reg_base + EHCI_INSNREG01);
+static void usb_set_qrk_bulk_thresh(struct pci_dev *pdev)
Please, use usb_set_qrk_bulk_threshold().
The 'threshold' looks better than 'thresh'.
+{
+ void __iomem *base, *op_reg_base;
+ u8 cap_length;
+ u32 val;
+ u16 cmd;
+
+ if (!pci_resource_start(pdev, 0))
+ return;
+
+ if (pci_read_config_word(pdev, PCI_COMMAND, cmd)
+ || !(cmd PCI_COMMAND_MEMORY))
+ return;
+
+ base = pci_ioremap_bar(pdev, 0);
+ if (base == NULL)
+ return;
+
+ cap_length = readb(base);
+ op_reg_base = base + cap_length;
+
+ val = EHCI_INSNREG01_THRESH;
+ writel(val, op_reg_base + EHCI_INSNREG01);
+
+ iounmap(base);
+}
/* called after powerup, by probe or system-pm wakeup */
static int ehci_pci_reinit(struct ehci_hcd *ehci, struct pci_dev *pdev)
@@ -50,6 +91,10 @@ static int ehci_pci_reinit(struct ehci_hcd *ehci, struct
pci_dev *pdev)
if (!retval)
ehci_dbg(ehci, MWI active\n);
+ /* Reset the threshold limit */
Re: [PATCH v2] USB: ehci-pci: USB host controller support for Intel Quark X1000
On Friday, June 27, 2014 1:33 PM, Jingoo Han wrote:
On Friday, June 27, 2014 8:25 PM, Alvin Chen wrote:
From: Bryan O'Donoghue bryan.odonog...@intel.com
The EHCI packet buffer in/out threshold is programmable for Intel Quark
X1000 USB host
controller, and the default value is 0x20 dwords. The in/out threshold can
be programmed
to 0x80 dwords, but only when isochronous/interrupt transactions are not
initiated by
the USB host controller. This patch is to reconfigure the packet buffer
in/out threshold
as maximal as possible, and it is 0x7F dwords since the USB host controller
initiates
isochronous/interrupt transactions.
So, what is the reason to set the value as 0x80?
1. The default value 0x20 makes some problems such as...
2. To maximize the performance, ...
3. Both
Please add the reason why 0x80 is necessary, as possible.
Then, 0x7F means 508 bytes? 'Intel Quark X1000 USB host controller'
can support 0x80 (512bytes), however, in this case, isochronous/interrupt
transactions cannot be initiated by 'Intel Quark X1000 USB host controller'.
Right?
So, 0x79 (508bytes?) should be used, because the isochronous/interrupt
transactions can be initiated by 'Intel Quark X1000 USB host controller'.
Right?
Signed-off-by: Bryan O'Donoghue bryan.odonog...@intel.com
Signed-off-by: Alvin (Weike) Chen alvin.c...@intel.com
---
changelog v2:
*Change the function name from 'usb_is_intel_qrk' to
'usb_is_intel_quark_x1000'.
*Move the functions 'usb_is_intel_quark_x1000' and 'usb_set_qrk_bulk_thresh'
from 'pci-quirks.c' to 'ehci-pci.c'.
*Remove unnecessary kernel message in the function of
'usb_set_qrk_bulk_thresh'.
*Remove 'unlikely' in the functions of 'ehci_pci_reinit'.
*Add white space after 'if'.
*Update the descriptions to make it more clearly.
*Add Micros to avoid magic number.
drivers/usb/host/ehci-pci.c | 45
+++
1 file changed, 45 insertions(+)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 3e86bf4..ca29f34 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -35,6 +35,47 @@ static const char hcd_name[] = ehci-pci;
#define PCI_DEVICE_ID_INTEL_CE4100_USB 0x2e70
/*-*/
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC0x0939
+static inline bool usb_is_intel_quark_x1000(struct pci_dev *pdev)
+{
+ return pdev-vendor == PCI_VENDOR_ID_INTEL
+ pdev-device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
+
Please don't add this unnecessary line.
+}
+
+/* Register offset of in/out threshold */
+#define EHCI_INSNREG01 0x84
+/* The maximal threshold is 0x80 Dword */
+#define EHCI_MAX_THRESHOLD 0X80
s/0X80/0x80
0x80 means 512 bytes. So, how about mentioning '0x80 means 512 bytes'
in this comment or the commit message?
Maybe, how about the following?
/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80
+/* Lower word is 'in' threshold, and higher word is 'out' threshold*/
+#define EHCI_INSNREG01_THRESH \
+ ((EHCI_MAX_THRESHOLD - 1)16 | (EHCI_MAX_THRESHOLD - 1))
Um, how about the following?
/* Register offset of in/out threshold */
#define EHCI_INSNREG010x84
/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80
#define EHCI_THRESHOLD_508BYTES 0x79
#define EHCI_THRESHOLD_OUT_SHIFT 16
#define EHCI_THRESHOLD_IN_SHIFT 0
..
/*
* In order to support the isochronous/interrupt transactions,
* 508 bytes should be used as max threshold values */
*/
val = ((EHCI_THRESHOLD_512BYTES - 1) EHCI_THRESHOLD_OUT_SHIFT |
(EHCI_THRESHOLD_512BYTES - 1) EHCI_THRESHOLD_IN_SHIFT);
writel(val, op_reg_base + EHCI_INSNREG01);
Sorry, please refer to the following.
/* Register offset of in/out threshold */
#define EHCI_INSNREG01 0x84
/* The maximal threshold value is 0x80, which means 512 bytes */
#define EHCI_THRESHOLD_512BYTES 0x80
#define EHCI_THRESHOLD_508BYTES 0x79
#define EHCI_THRESHOLD_OUT_SHIFT16
#define EHCI_THRESHOLD_IN_SHIFT 0
..
/*
* In order to support the isochronous/interrupt transactions,
* 508 bytes should be used as max threshold values */
*/
val = (EHCI_THRESHOLD_508BYTES EHCI_THRESHOLD_OUT_SHIFT |
(EHCI_THRESHOLD_508BYTES EHCI_THRESHOLD_IN_SHIFT);
writel(val, op_reg_base + EHCI_INSNREG01);
+static void usb_set_qrk_bulk_thresh(struct pci_dev *pdev)
Please, use usb_set_qrk_bulk_threshold().
The 'threshold' looks better than 'thresh'.
Re: [PATCH 2/2] usb: chipidea: Add support for zynq usb host and device controller
On Fri, Jun 27, 2014 at 09:10:09AM +0530, Punnaiah Choudary Kalluri wrote:
Zynq soc usb controller is a synopsys IP and it is compatible
with the chipidea spec. So, reusing chipidea drivers for zynq usb
controller.
What means ... usb controller is a synopsys IP, or it should be uses
synopsys IP?
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
drivers/usb/chipidea/Makefile |1 +
drivers/usb/chipidea/ci_hdrc_zynq.c | 115
+++
2 files changed, 116 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/chipidea/ci_hdrc_zynq.c
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 2f099c7..b0d6b6f 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -12,6 +12,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_msm.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
+obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zynq.o
# PCI doesn't provide stubs, need to check
ifneq ($(CONFIG_PCI),)
diff --git a/drivers/usb/chipidea/ci_hdrc_zynq.c
b/drivers/usb/chipidea/ci_hdrc_zynq.c
new file mode 100644
index 000..b3667da
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_zynq.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2014 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/usb/chipidea.h
+
+#include ci.h
+
+#define ZYNQ_USB_DMA_MASK0xFFF0
+
+struct ci_hdrc_zynq_data {
+ struct platform_device *ci_pdev;
+ struct clk *clk;
+};
+
+static struct ci_hdrc_platform_data pdata = {
+ .name = ci_hdrc_zynq,
+ .capoffset = DEF_CAPOFFSET,
+ .flags = CI_HDRC_REQUIRE_TRANSCEIVER
+};
+
+static int ci_hdrc_zynq_probe(struct platform_device *pdev)
+{
+ struct ci_hdrc_zynq_data *data;
+ int ret;
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev, Failed to allocate ci_hdrc-imx data!\n);
hmm, you forget to delete xxx-imx.
+ return -ENOMEM;
+ }
+
+ data-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(data-clk)) {
+ dev_err(pdev-dev,
+ Failed to get clock, err=%ld\n, PTR_ERR(data-clk));
+ return PTR_ERR(data-clk);
+ }
+
+ ret = clk_prepare_enable(data-clk);
+ if (ret) {
+ dev_err(pdev-dev,
+ Failed to prepare or enable clock, err=%d\n, ret);
+ return ret;
+ }
+
+ ret = dma_coerce_mask_and_coherent(pdev-dev, ZYNQ_USB_DMA_MASK);
+ if (ret)
+ goto err_clk;
+
+ data-ci_pdev = ci_hdrc_add_device(pdev-dev,
+ pdev-resource, pdev-num_resources,
+ pdata);
+ if (IS_ERR(data-ci_pdev)) {
+ ret = PTR_ERR(data-ci_pdev);
+ dev_err(pdev-dev,
+ Can't register ci_hdrc platform device, err=%d\n,
+ ret);
+ goto err_clk;
+ }
+
+ platform_set_drvdata(pdev, data);
+
+ pm_runtime_no_callbacks(pdev-dev);
+ pm_runtime_enable(pdev-dev);
+ return 0;
+
+err_clk:
+ clk_disable_unprepare(data-clk);
+ return ret;
+}
+
+static int ci_hdrc_zynq_remove(struct platform_device *pdev)
+{
+ struct ci_hdrc_zynq_data *data = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(pdev-dev);
+ ci_hdrc_remove_device(data-ci_pdev);
+ clk_disable_unprepare(data-clk);
+
+ return 0;
+}
+
+static const struct of_device_id ci_hdrc_zynq_dt_ids[] = {
+ { .compatible = xlnx,zynq-usb-2.20a },
+ {},
+};
+
+static struct platform_driver ci_hdrc_zynq_driver = {
+ .probe = ci_hdrc_zynq_probe,
+ .remove = ci_hdrc_zynq_remove,
+ .driver = {
+ .name = zynq_usb,
+ .owner = THIS_MODULE,
+ .of_match_table = ci_hdrc_zynq_dt_ids,
+ },
+};
+
+module_platform_driver(ci_hdrc_zynq_driver);
+
+MODULE_ALIAS(platform:zynq_usb);
+MODULE_DESCRIPTION(CI HDRC ZYNQ USB binding);
+MODULE_AUTHOR(Xilinx Inc);
+MODULE_LICENSE(GPL v2);
--
1.7.4
--
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
Re: [PATCH v2 07/12] usb: chipidea: add a generic driver
On Fri, Jun 27, 2014 at 11:25:07AM +0800, Peter Chen wrote:
On Tue, Jun 24, 2014 at 12:35:16PM +0200, Antoine Ténart wrote:
Add a generic ChipIdea driver, with optional PHY and clock, to support
ChipIdea controllers that doesn't need specific functions.
+ return 0;
+}
+
+static const struct of_device_id ci_hdrc_generic_of_match[] = {
+ { .compatible = chipidea-usb },
+ { }
+};
Even as a generic driver, you can also use your own compatible string.
+MODULE_DEVICE_TABLE(of, ci_hdrc_generic_of_match);
+
+static struct platform_driver ci_hdrc_generic_driver = {
+ .probe = ci_hdrc_generic_probe,
+ .remove = ci_hdrc_generic_remove,
+ .driver = {
+ .name = chipidea-usb,
+ .owner = THIS_MODULE,
+ .of_match_table = ci_hdrc_generic_of_match,
+ },
+};
+module_platform_driver(ci_hdrc_generic_driver);
+
+MODULE_DESCRIPTION(Generic ChipIdea HDRC USB binding);
+MODULE_AUTHOR(Antoine Ténart antoine.ten...@free-electrons.com);
+MODULE_LICENSE(GPL);
--
1.9.1
--
Besides, I haven't seen dma_coerce_mask_and_coherent API calling,
where you set your dma mask?
--
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
Re: [PATCH 2/2] usb: chipidea: Add support for zynq usb host and device controller
On Fri, Jun 27, 2014 at 9:09 AM, Peter Chen peter.c...@freescale.com wrote:
On Fri, Jun 27, 2014 at 09:10:09AM +0530, Punnaiah Choudary Kalluri wrote:
Zynq soc usb controller is a synopsys IP and it is compatible
with the chipidea spec. So, reusing chipidea drivers for zynq usb
controller.
What means ... usb controller is a synopsys IP, or it should be uses
synopsys IP?
Zynq soc uses synopsys usb IP. I will correct it
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
drivers/usb/chipidea/Makefile |1 +
drivers/usb/chipidea/ci_hdrc_zynq.c | 115
+++
2 files changed, 116 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/chipidea/ci_hdrc_zynq.c
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 2f099c7..b0d6b6f 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -12,6 +12,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_msm.o
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
+obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zynq.o
# PCI doesn't provide stubs, need to check
ifneq ($(CONFIG_PCI),)
diff --git a/drivers/usb/chipidea/ci_hdrc_zynq.c
b/drivers/usb/chipidea/ci_hdrc_zynq.c
new file mode 100644
index 000..b3667da
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_zynq.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2014 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/usb/chipidea.h
+
+#include ci.h
+
+#define ZYNQ_USB_DMA_MASK0xFFF0
+
+struct ci_hdrc_zynq_data {
+ struct platform_device *ci_pdev;
+ struct clk *clk;
+};
+
+static struct ci_hdrc_platform_data pdata = {
+ .name = ci_hdrc_zynq,
+ .capoffset = DEF_CAPOFFSET,
+ .flags = CI_HDRC_REQUIRE_TRANSCEIVER
+};
+
+static int ci_hdrc_zynq_probe(struct platform_device *pdev)
+{
+ struct ci_hdrc_zynq_data *data;
+ int ret;
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev, Failed to allocate ci_hdrc-imx data!\n);
hmm, you forget to delete xxx-imx.
Oh! i will correct it and send you the v2.
Regards,
Punnaiah
+ return -ENOMEM;
+ }
+
+ data-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(data-clk)) {
+ dev_err(pdev-dev,
+ Failed to get clock, err=%ld\n, PTR_ERR(data-clk));
+ return PTR_ERR(data-clk);
+ }
+
+ ret = clk_prepare_enable(data-clk);
+ if (ret) {
+ dev_err(pdev-dev,
+ Failed to prepare or enable clock, err=%d\n, ret);
+ return ret;
+ }
+
+ ret = dma_coerce_mask_and_coherent(pdev-dev, ZYNQ_USB_DMA_MASK);
+ if (ret)
+ goto err_clk;
+
+ data-ci_pdev = ci_hdrc_add_device(pdev-dev,
+ pdev-resource, pdev-num_resources,
+ pdata);
+ if (IS_ERR(data-ci_pdev)) {
+ ret = PTR_ERR(data-ci_pdev);
+ dev_err(pdev-dev,
+ Can't register ci_hdrc platform device, err=%d\n,
+ ret);
+ goto err_clk;
+ }
+
+ platform_set_drvdata(pdev, data);
+
+ pm_runtime_no_callbacks(pdev-dev);
+ pm_runtime_enable(pdev-dev);
+ return 0;
+
+err_clk:
+ clk_disable_unprepare(data-clk);
+ return ret;
+}
+
+static int ci_hdrc_zynq_remove(struct platform_device *pdev)
+{
+ struct ci_hdrc_zynq_data *data = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(pdev-dev);
+ ci_hdrc_remove_device(data-ci_pdev);
+ clk_disable_unprepare(data-clk);
+
+ return 0;
+}
+
+static const struct of_device_id ci_hdrc_zynq_dt_ids[] = {
+ { .compatible = xlnx,zynq-usb-2.20a },
+ {},
+};
+
+static struct platform_driver ci_hdrc_zynq_driver = {
+ .probe = ci_hdrc_zynq_probe,
+ .remove = ci_hdrc_zynq_remove,
+ .driver = {
+ .name = zynq_usb,
+ .owner = THIS_MODULE,
+ .of_match_table = ci_hdrc_zynq_dt_ids,
+ },
+};
+
+module_platform_driver(ci_hdrc_zynq_driver);
+
+MODULE_ALIAS(platform:zynq_usb);
+MODULE_DESCRIPTION(CI HDRC ZYNQ USB binding);
+MODULE_AUTHOR(Xilinx Inc);
+MODULE_LICENSE(GPL v2);
--
1.7.4
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to
