Re: 答复: Re: 答复: Re: 【PATCH】USB：add new zte 3g-dongle's pid to option.c
I am looking forward to a new blog post in this excellent series :) http://www.kroah.com/log/linux/maintainer.html http://www.kroah.com/log/linux/maintainer-02.html http://www.kroah.com/log/linux/maintainer-03.html http://www.kroah.com/log/linux/maintainer-04.html http://www.kroah.com/log/linux/maintainer-05.html http://www.kroah.com/log/linux/maintainer-06.html Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crash in dwc3 driver on module unload
Hi,
On Tue, Apr 09, 2013 at 02:36:51AM +, Paul Zimmerman wrote:
I'm getting a crash when I rmmod the dwc3-pci driver in latest Linus, and
also in 3.8.6 and 3.8.0.
Screenshot (two parts) are here:
http://ompldr.org/vaTFibQ/IMG1.jpg
http://ompldr.org/vaTFicA/IMG2.jpg
Unfortunately the very first part of the crash has scrolled off the
screen.
I've decoded the crash a bit. The call chain descends through
platform_device_unregister(glue-dwc3) in dwc3_pci_remove(). It hits the
warning in kobject_put():
void kobject_put(struct kobject *kobj)
{
if (kobj) {
if (!kobj-state_initialized)
WARN(1, KERN_WARNING kobject: '%s' (%p): is
not
initialized, yet kobject_put() is being
called.\n, kobject_name(kobj), kobj);
kref_put(kobj-kref, kobject_release);
}
}
and crashes when it tries to print the string, presumably because the
kobj-name field is either NULL or poisoned. So probably the kobject has
already been freed, or is in the process of being freed?
Any ideas? Any debugging hints?
looks like the PHY is being unregistered too early. I believe that's
because PHY's dev is just a pointer to the real dev and maybe that's
what's wrong.
Here's what happens:
devm_usb_get_phy() will find the PHY and issue a get_device(phy-dev).
phy-dev is initialized to (in your case) nop_xceiv's pdev-dev.
When you remove dwc3.ko, due to devm_usb_phy_get(),
devm_usb_phy_release() will get called which will issue a
put_device(phy-dev), and that will trigger nop_xceiv's platform_device
release, once you remove dwc3-pci.ko, you see the trigger.
I'm adding Kishon to the loop to help out figuring out what the best fix
would be.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/6] mfd: omap-usb-host: Device tree support for 3.10
Hi Roger, On Mon, Mar 25, 2013 at 12:42:04PM +0200, Roger Quadros wrote: Hi Samuel, I've rebased this now on top of 3.9-rc4. Please pull this into your next branch when appropriate. Thanks. The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7: Linux 3.9-rc4 (2013-03-23 16:52:44 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-mfd-next Roger Quadros (5): mfd: omap-usb-host: update nports in platform_data mfd: omap-usb-host: Remove PHY reset handling code mfd: omap-usb-tll: move configuration code to omap_tll_init() mfd: omap-usb-tll: Add device tree support and binding information mfd: omap-usb-host: Add device tree support and binding information I had to apply them manually, as patches #2 and #5 do not apply. I am pushing #1, #3 and #4, please rebase 2 and 5 on top of mfd-next and resend them to me. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
On Tue, Apr 09, 2013 at 01:10:49AM +0400, Sergei Shtylyov wrote: Hello. Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130405v2' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. The patches have been tested on the Marzen board. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data I'm not sure thru which tree this patchset should be merged, however it turns out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10 which would have been most convenient probably, so maybe the patchset can be merged thru Simon's tree with Felipe's and Alan Stern's ACKs. Or perhaps it now should be postponed for 3.11... I feel that it is also too late for v3.10 for my tree. I am happy to take them through my tree with appropriate acks. Or, follow acks from Morimoto-san to allow the shmobile portions to go through a different tree. -- 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] mfd: omap-usb-host: Remove PHY reset handling code
PHY reset GPIO handling will be done in the PHY driver
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/omap-usb-host.c | 28
1 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index eb5db28..138ee98 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -430,24 +430,10 @@ static unsigned omap_usbhs_rev2_hostconfig(struct
usbhs_hcd_omap *omap,
static void omap_usbhs_init(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = omap-pdata;
unsignedreg;
dev_dbg(dev, starting TI HSUSB Controller\n);
- if (pdata-phy_reset) {
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- devm_gpio_request_one(dev, pdata-reset_gpio_port[0],
-GPIOF_OUT_INIT_LOW, USB1 PHY reset);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- devm_gpio_request_one(dev, pdata-reset_gpio_port[1],
-GPIOF_OUT_INIT_LOW, USB2 PHY reset);
-
- /* Hold the PHY in RESET for enough time till DIR is high */
- udelay(10);
- }
-
pm_runtime_get_sync(dev);
reg = usbhs_read(omap-uhh_base, OMAP_UHH_HOSTCONFIG);
@@ -476,20 +462,6 @@ static void omap_usbhs_init(struct device *dev)
dev_dbg(dev, UHH setup done, uhh_hostconfig=%x\n, reg);
pm_runtime_put_sync(dev);
- if (pdata-phy_reset) {
- /* Hold the PHY in RESET for enough time till
-* PHY is settled and ready
-*/
- udelay(10);
-
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- gpio_set_value_cansleep
- (pdata-reset_gpio_port[0], 1);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- gpio_set_value_cansleep
- (pdata-reset_gpio_port[1], 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
[PATCH 2/2] mfd: omap-usb-host: Add device tree support and binding information
Allows the OMAP HS USB host controller to be specified
via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Mark Rutland mark.rutl...@arm.com
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 80 ++
drivers/mfd/omap-usb-host.c| 161 +++-
2 files changed, 235 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000..b381fa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,80 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be ti,usbhs-host
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain usb_host_hs
+
+Optional properties:
+
+- num-ports: number of USB ports. Usually this is automatically detected
+ from the IP's revision register but can be overridden by specifying
+ this property. A maximum of 3 ports are supported at the moment.
+
+- portN-mode: String specifying the port mode for port N, where N can be
+ from 1 to 3. If the port mode is not specified, that port is treated
+ as unused. When specified, it must be one of the following.
+ ehci-phy,
+ehci-tll,
+ehci-hsic,
+ohci-phy-6pin-datse0,
+ohci-phy-6pin-dpdm,
+ohci-phy-3pin-datse0,
+ohci-phy-4pin-dpdm,
+ohci-tll-6pin-datse0,
+ohci-tll-6pin-dpdm,
+ohci-tll-3pin-datse0,
+ohci-tll-4pin-dpdm,
+ohci-tll-2pin-datse0,
+ohci-tll-2pin-dpdm,
+
+- single-ulpi-bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+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;
+ };
+};
+
+usbhshost {
+ port1-mode = ehci-phy;
+ port2-mode = ehci-tll;
+ port3-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy 0 hsusb3_phy;
+};
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 138ee98..d3b6e94 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -1,8 +1,9 @@
/**
* omap-usb-host.c - The USBHS core driver for OMAP EHCI OHCI
*
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com
* Author: Keshava Munegowda keshava_mgo...@ti.com
+ * Author: Roger Quadros rog...@ti.com
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 of
@@ -27,6 +28,8 @@
#include linux/platform_device.h
#include linux/platform_data/usb-omap.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
#include omap-usb.h
@@ -137,6 +140,49 @@ static inline u8 usbhs_readb(void __iomem *base, u8 reg)
/*-*/
+/**
+ * Map 'enum usbhs_omap_port_mode' found in linux/platform_data/usb-omap.h
+ * to the device tree binding portN-mode found in
+ * 'Documentation/devicetree/bindings/mfd/omap-usb-host.txt'
+ */
+static const char * const port_modes[] = {
+ [OMAP_USBHS_PORT_MODE_UNUSED] = ,
+ [OMAP_EHCI_PORT_MODE_PHY] = ehci-phy,
+ [OMAP_EHCI_PORT_MODE_TLL] = ehci-tll,
+ [OMAP_EHCI_PORT_MODE_HSIC] = ehci-hsic,
+ [OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0] = ohci-phy-6pin-datse0,
+ [OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM] = ohci-phy-6pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0] = ohci-phy-3pin-datse0,
+ [OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM] = ohci-phy-4pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0] = ohci-tll-6pin-datse0,
+ [OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM] = ohci-tll-6pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0] = ohci-tll-3pin-datse0,
+ [OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM] =
Re: [PATCH 0/6] mfd: omap-usb-host: Device tree support for 3.10
Samuel, You had the conflicts because a patch [*] was introduced and is not required since the reset logic is being removed from the driver. Anyways, I've rebased the 2 patches on top of mfd-next, so now it shouldn't matter. cheers, -roger [*] commit 71f4b9cdfccfb82cff702fe61f4ace97a1dfb0e0 Author: Jingoo Han jg1@samsung.com Date: Wed Feb 20 18:29:30 2013 +0900 mfd: omap-usb-host: Use devm_gpio_request_one() -- 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
[Test Application PATCH 0/2] UVC gadget test application enhancements
This patchset tries to enhance the UVC gadget test application and is based on Laurent's git tree available here (project: uvc-gadget.git): git://git.ideasonboard.org/uvc-gadget.git The patch 2/2 in this patchset also adds a README file describing the UVC gadget test application, it's possible use-case scenarios and IO method support in detail. The 'linux-usb' list is also added to CC of this patchset (although this is a test application related change), as I have received interest from a number of users on the list regarding availability of this patchset. Bhupesh Sharma (2): UVC gadget: Add support for integration with a video-capture device and other fixes UVC gadget: Add a README file describing the UVC gadget test application README | 209 ++ uvc-gadget.c | 2156 -- 2 files changed, 2159 insertions(+), 206 deletions(-) create mode 100644 README -- 1.7.2.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
[Test Application PATCH 2/2] UVC gadget: Add a README file describing the UVC gadget test application
This patch adds a README file describing the UVC gadget test application, it's possible use-case scenarios and IO method support in detail. Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com --- README | 209 1 files changed, 209 insertions(+), 0 deletions(-) create mode 100644 README diff --git a/README b/README new file mode 100644 index 000..088c4b8 --- /dev/null +++ b/README @@ -0,0 +1,209 @@ +UVC gadget test application Readme + +Copyright (C) 2010 Ideas on board SPRL +Copyright (C) 2013 ST Microelectronics Ltd. + +Contacts: +Laurent Pinchart laurent.pinch...@ideasonboard.com +Bhupesh Sharma bhupesh.sha...@st.com + +Introduction + + +This README file documents the UVC gadget test application available +here git://git.ideasonboard.org/uvc-gadget.git, which can be used to +test the UVC webcam gadget driver located under drivers/usb/gadget +directory. + +Possible Use-Case scenarios +=== + +There can be a number of scenarios under which the UVC webcam gadget can +be used and each use-case can vary in the following ways: + +- Video streaming endpoint choice: + + + As per UVC specifications (Revision 1.1), either Bulk or Isochronous + USB endpoints can be used are for implementing UVC Video streaming + interface. Both have there unique challenges as: + + Isochronous video streaming interface will have two + alt-settings: + - Alt-setting 0 for zero-bandwidth mode, and + - Alt-setting 1 for full-bandwidth mode. + + This requires us to ACK status stage of SET_ALT(alt-setting = + 1), only when we have video frames available which can be queued + to UVC domain. + + Bulk video streaming interface, on the other hand will have only + one alt-setting. + + This requires us to prepare UVC gadget for streaming when we + receive a a UVC_VS_COMMIT_CONTROL command from USB host and + actually start streaming as soon as we have video frames + available which can be queued to UVC domain. + +- Availability of a video capture device: + --- + + To emulate a real UVC webcam gadget (capturing live video from a video + capture source and sending it over USB bus), it is possible to + integrate a V4L2 based video-capture device driver with the UVC gadget + test application acting as an interface between the UVC based + video-output device and V4L2 based video-capture device. + + Accordingly, there can be the following scenarios possible: + + - No video capture device available: + + In this case, there is no video capture device available + and the UVC webcam gadget is working in an standalone + environment. + + It is possible in this case to stream a dummy test + pattern from the UVC webcam gadget and view the same on + the Linux/Windows USB Host machine using standard video + capture utilities like CHEESE. + + - VIVI (Virtual Video driver) acting as a video capture source: + + In case we don't have a real video capture hardware + (e.g. sensor) available, it is still possible to + exercise the complete path from the V4L2 based + video-capture domain to UVC based video-output domain, + using the Virtual Video driver (VIVI) available here: + drivers/media/platform/vivi.c + + It is possible in this case to stream changing vertical + color bar pattern pattern from the VIVI capture device + and send it to UVC webcam gadget, which will eventually + send these frames over USB bus. + + Similar to the case above, it is possible to view the + frames on the Linux/Windows USB Host machine using + standard video capture utilities like CHEESE. + + - Real video capture hardware and corresponding V4L2 driver + available: + + In this case, we have a real video capture hardware + (e.g. CCD / CMOS sensor) available. + + Here, it is possible to exercise the complete path from + the V4L2 based video-capture driver domain to UVC based + video-output domain, using the UVC gadget test + application. + + It is possible in this case to stream real video/still + images from capture source and send it to UVC webcam + gadget, which will eventually send these frames over USB + bus. + +- IO methods supported: + + + V4L2 framework supports a number of IO methods and to achieve + zero-memcpy of video frames as they pass from V4L2 video-capture + domain to UVC video-output domain, it is important to select + appropriate
[PATCH] usb: ehci-s5p: fix: Fix null pointer dereferencing
7edb3da makes ehci-s5p as a separate driver. But, it raised an issue with its driver data. Now that 's5p_ehci_hcd' doesn't maintain pointer to 'usb_hcd' and s5p_ehci is nothing but a pointer to hcd-priv; add hcd to the driver data rather than s5p_ehci. This fixes issues with null pointer dereferencing in s5p_ehci_shutdown(), s5p_ehci_suspend(), s5p_ehci_resume(). Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Manjunath Goudar manjunath.gou...@linaro.org CC: Arnd Bergmann a...@arndb.de CC: Jingoo Han jg1@samsung.com --- drivers/usb/host/ehci-s5p.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index d8cb0ca..580548a 100644 --- a/drivers/usb/host/ehci-s5p.c +++ b/drivers/usb/host/ehci-s5p.c @@ -173,7 +173,7 @@ static int s5p_ehci_probe(struct platform_device *pdev) goto fail_add_hcd; } - platform_set_drvdata(pdev, s5p_ehci); + platform_set_drvdata(pdev, hcd); return 0; -- 1.7.6.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
[PATCH] USB: option: add a D-Link DWM-156 variant
Adding support for a Mediatek based device labelled as
D-Link Model: DWM-156, H/W Ver: A7
Also adding two other device IDs found in the Debian(!)
packages included on the embedded device driver CD.
This is a composite MBIM + serial ports + card reader device:
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2001 ProdID=7d01 Rev= 3.00
S: Manufacturer=D-Link,Inc
S: Product=D-Link DWM-156
C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=125us
I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Cc: sta...@vger.kernel.org
Signed-off-by: Bjørn Mork bj...@mork.no
---
Note: D-Link already operates with two different vendor IDs in this
driver. I did not want to define a 3rd... Using plain constants
is easier to read anyway IMHO.
drivers/usb/serial/option.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 558adfc..e1bff4b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1350,6 +1350,12 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(TPLINK_VENDOR_ID, TPLINK_PRODUCT_MA180),
.driver_info = (kernel_ulong_t)net_intf4_blacklist },
{ USB_DEVICE(CHANGHONG_VENDOR_ID, CHANGHONG_PRODUCT_CH690) },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d01, 0xff, 0x02, 0x01) },
/* D-Link DWM-156 (variant) */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d01, 0xff, 0x00, 0x00) },
/* D-Link DWM-156 (variant) */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d02, 0xff, 0x02, 0x01) },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d02, 0xff, 0x00, 0x00) },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x02, 0x01) },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/05/2013 06:58 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130405 03:44]: On 04/04/2013 07:41 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130404 00:39]: On 04/04/2013 02:42 AM, Tony Lindgren wrote: For v3.10, let's just make sure that USB works with DT as then after v3.10 we can make omap4 DT only and get rid of estimated 7K lines of code and data. I guess this is the last piece missing for that, or are we also missing something else? For panda we just need a way to map the auxclk to the USB PHY device and the relevant dts data to get USB host working with DT. Beagle USB host should work already with DT without any changes. Can't you set up a clock alias for your device so it can find the auxclk when requesting it with the dev entry? which clock is mapped to which PHY device depends on board design and that cannot be per-determined at one place. This information needs to come from the board.dts file. OK that makes sense. There was an earlier attempt to provide a way of building clock aliases at runtime from device tree [1], but the current approach is way better [1] https://lkml.org/lkml/2013/3/12/241 For the DT clock driver if needed for v3.10, how about just do a minimal drivers/clock/omap/ that uses the standard binding? Then that driver can just do clk_get() from cclock44xx_data.c I don't understand how to do it and why it is better than the current approach. Well your approach is fine as a first step moving all the clock code, but it needs to be a real driver under drivers/clock/omap. And the DT binding needs to stay the same for the driver(s) in the long term as we start moving clocks to DT + /lib/firmware. The code needs to be there were the clock structs are defined. Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4. If this all is too late for v3.10, I suggest you just set up the right clock alias for panda with machine_is_compatible flag in board-generic.c so we get EHCI working with DT for v3.10. Then it's easy to to deal with it properly for v3.11. OK, let's do it this way for Panda for 3.10. How can that driver do clk_get() from cclock44xx_data.c? from where does it get the clk_id to pass into clk_get()? Can't you just use the clock name there to get it? In device tree we don't pass around clock names. You can either get a phandle or an index to the clock. e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt for now? And then later on we'll just move all the clocks to a combination of DT + /lib/firmware. What is the benefit of moving clock data to /lib/firmware? We could as well just move it to DT only, no? DT only clocks option is naturally available with this too. It just gets easily inefficient with such a huge number of clocks. OK. e.g. auxclk are required to be specified in DT nodes for USB PHY. Without this we can't get USB host working on Panda. OK. So if the USB PHY has a dev entry, can't you just set up a clock alias in struct omap_clk omap44xx_clks[] for it? I've explained why this can't be done above. Yes I understand now, the clock is board specific. As Rajendra points out, it seems moving entire clock data to DT is not going to happen soon. So this is the simplistic way things can work. Right but seems like we can get started there without moving them all at once. What if we provide a complete clock list instead of only auxclks in dt_clks[]? This approach is similar to arch/arm/mach-imx/clk-imx35.c Device drivers can then use them as they migrate to DT. Then later we could migrate clock data to DT, without impacting device drivers. As long as the binding stays the same in the long run too, this clock remapping approach is just fine as a starting point. And the driver needs to go to drivers/clock/omap. But in the long run we just want to get the huge amounts static data out of the kernel for clocks and hwmod data to fix things for good. In that case we need to identify what clocks need to be supported. If it is all (~200) of them, is this method good enough? cheers, -roger -- 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 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/05/2013 08:56 PM, Grygorii Strashko wrote:
On 04/04/2013 07:41 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130404 00:39]:
On 04/04/2013 02:42 AM, Tony Lindgren wrote:
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/of.h
#include soc.h
#include iomap.h
@@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,cpufreq_ck,dpll_mpu_ck,CK_443X),
};
+static struct clk *scrm_clks[] = {
+auxclk0_ck,
+auxclk1_ck,
+auxclk2_ck,
+auxclk3_ck,
+auxclk4_ck,
+auxclk5_ck,
+};
Hmm I don't like the idea of specifying the auxclk both in the
cclock44xx_data.c and in DT..
Right, but till we have all clocks moved to DT we only need this
approach for general purpose clocks that are not mapped to devices
by hwmod.
For v3.10, let's just make sure that USB works with DT as then
after v3.10 we can make omap4 DT only and get rid of estimated
7K lines of code and data. I guess this is the last piece missing
for that, or are we also missing something else?
Can't you set up a clock alias for your device so it can find the
auxclk when requesting it with the dev entry?
For the DT clock driver if needed for v3.10, how about just do a
minimal drivers/clock/omap/ that uses the standard binding?
Then that driver can just do clk_get() from cclock44xx_data.c
for now? And then later on we'll just move all the clocks to a
combination of DT + /lib/firmware.
Hi Roger, Rajendra, All
Sorry that disturbing you.
Hi Grygorri,
Nothing to disturb at all ;).
I'm supporting Android OMAP4 kernels (K3.0/K3.4) and like to clarify few
points regarding this approach (having into account possible future migrations
on newer Kernels and OMAP5).
If I understand everything right, this patch series allows to create clock
binding
in DT using following syntax: clocks = aux_clks 3
Actually in v2 of the patch this would be clocks = clks 3
- does it means that in worst case there will be ~200 clock IDs defined?
I'm afraid so yes. But when I wrote this I was only thinking of generic clocks,
i.e. AUXCLKS.
So when we start talking of all clocks we might need to reconsider the approach.
- does it means that clock nodes binding using phandles (human-friendly
notation)
isn't going to be supported?
for example:
clocks = sys_clkin_ck
clocks = dss_sys_clk dss_tv_clk dss_dss_clk)
This would depend if we define the clock nodes within DT or not. From what Tony
mentioned (i.e. inefficiency) it seems that the clock nodes won't be defined
in the device tree. Then we are left with using an index.
I was horrified to think about the problems of this approach support
(in case if there would be more then ~30 IDs) - just miss with on digit
and weeks of debugging would be guaranteed.
Please, say me that i'm wrong.
It is still not written in stone so if you have a better idea we could
go that route.
cheers,
-roger
And why clock DT data can't be auto-generated like all other OMAP data
to close this questions?
Thanks.
e.g. auxclk are required to be specified in DT nodes for USB PHY.
Without this we can't get USB host working on Panda.
OK. So if the USB PHY has a dev entry, can't you just set up a
clock alias in struct omap_clk omap44xx_clks[] for it?
As Rajendra points out, it seems moving entire clock data to DT is not
going to happen soon. So this is the simplistic way things can work.
Right but seems like we can get started there without moving
them all at once.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
Hi, can someone provide a MinGW 32bits built of the last working RC, thanx in advance, best regards, Nicolas Le 04/04/13 21:12, nico a écrit : Hi, merci beaucoup to everyone for your work... Le 04/04/13 20:35, Pete Batard a écrit : On 2013.04.04 09:27, nico wrote: Making all in libusb CC libusb_1_0_la-core.lo core.c:1755:30: warning: use of logical '' with constant operand Thanks for the report, and the test. This is now fixed in RC3, along with a couple minor issues. The new RC is available from: http://sourceforge.net/projects/libusbx/files/releases/1.0.15/source/ RC3 builds fine with Clang on macOS 10.7.5 ++ Nicolas Regards, /Pete -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ libusbx-devel mailing list libusbx-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel -- 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/8] Reorganize R8A7779/Marzen USB code
Hello. On 05-04-2013 6:01, Kuninori Morimoto wrote: Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130404v2' tag and the 2 Ether patches I've reposted yesterday. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/8] ehci-platform: add init() method to platform data [3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer [4/8] rcar-phy: remove EHCI internal buffer setup [5/8] rcar-phy: correct base address [6/8] rcar-phy: add platform data [7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device [8/8] rcar-phy: handle platform data I'm not sure thru which tree this patchset should be merged, however it turns out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10, so maybe the patchset can be merged thru Simon's tree with Felipe's and Alan Stern's ACKs. I guess you already got request about patch style from Simon. When you send v2 patch, could you please add this patch is tested on bard on each patch's comment area ? I thought adding it to each patch (BTW, I didn't get what you meant: changelog or the area below ---) was a bit too much and just mentioned it in the cover letter. Then, for all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Sorry, I forgot to add this. If you still want it, I'll add it to version 3 that will be posted today. Best regards --- Kuninori Morimoto 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
[PATCH 3/5 v4] USB: enclose EHCI HCD drivers within an if USB_EHCI_HCD block
Thist patch removes the depends on USB_EHCI_HCD that the various USB EHCI HCD drivers use and encloses every driver within an if USB_EHCI_HCD / endif block. The EHCI HCD platform and Octeon drivers have been moved around to remain enclosed within this block. Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Florian Fainelli flor...@openwrt.org --- Changes in v4: - added Alan's Acked-by tag - refreshed against latest usb-next Changes in v3: - move out USB_FSL_MPH_DR_OF from the USB_EHCI_HCD block - remove depends on USB_EHCI_HCD for USB_EHCI_BIG_ENDIAN_DESC drivers/usb/host/Kconfig | 81 -- 1 file changed, 42 insertions(+), 39 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 436b682..bc9123c 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -93,14 +93,19 @@ config USB_EHCI_TT_NEWSCHED If unsure, say Y. +config USB_FSL_MPH_DR_OF + tristate + +if USB_EHCI_HCD + config USB_EHCI_PCI tristate - depends on USB_EHCI_HCD PCI + depends on PCI default y config USB_EHCI_HCD_PMC_MSP tristate EHCI support for on-chip PMC MSP71xx USB controller - depends on USB_EHCI_HCD MSP_HAS_USB + depends on MSP_HAS_USB default n select USB_EHCI_BIG_ENDIAN_DESC select USB_EHCI_BIG_ENDIAN_MMIO @@ -110,15 +115,13 @@ config USB_EHCI_HCD_PMC_MSP config USB_EHCI_BIG_ENDIAN_MMIO bool - depends on USB_EHCI_HCD config USB_EHCI_BIG_ENDIAN_DESC bool - depends on USB_EHCI_HCD config XPS_USB_HCD_XILINX bool Use Xilinx usb host EHCI controller core - depends on USB_EHCI_HCD (PPC32 || MICROBLAZE) + depends on (PPC32 || MICROBLAZE) select USB_EHCI_BIG_ENDIAN_DESC select USB_EHCI_BIG_ENDIAN_MMIO ---help--- @@ -127,12 +130,9 @@ config XPS_USB_HCD_XILINX support both high speed and full speed devices, or high speed devices only. -config USB_FSL_MPH_DR_OF - tristate - config USB_EHCI_FSL bool Support for Freescale PPC on-chip EHCI USB controller - depends on USB_EHCI_HCD FSL_SOC + depends on FSL_SOC select USB_EHCI_ROOT_HUB_TT select USB_FSL_MPH_DR_OF if OF ---help--- @@ -140,14 +140,14 @@ config USB_EHCI_FSL config USB_EHCI_MXC tristate Support for Freescale i.MX on-chip EHCI USB controller - depends on USB_EHCI_HCD ARCH_MXC + depends on ARCH_MXC select USB_EHCI_ROOT_HUB_TT ---help--- Variation of ARC USB block used in some Freescale chips. config USB_EHCI_HCD_OMAP tristate EHCI support for OMAP3 and later chips - depends on USB_EHCI_HCD ARCH_OMAP + depends on ARCH_OMAP select NOP_USB_XCEIV default y ---help--- @@ -183,7 +183,7 @@ config USB_EHCI_HCD_AT91 config USB_EHCI_MSM tristate Support for Qualcomm QSD/MSM on-chip EHCI USB controller - depends on USB_EHCI_HCD ARCH_MSM + depends on ARCH_MSM select USB_EHCI_ROOT_HUB_TT select USB_MSM_OTG ---help--- @@ -196,7 +196,7 @@ config USB_EHCI_MSM config USB_EHCI_TEGRA boolean NVIDIA Tegra HCD support - depends on USB_EHCI_HCD ARCH_TEGRA + depends on ARCH_TEGRA select USB_EHCI_ROOT_HUB_TT select USB_PHY help @@ -205,7 +205,7 @@ config USB_EHCI_TEGRA config USB_EHCI_HCD_PPC_OF bool EHCI support for PPC USB controller on OF platform bus - depends on USB_EHCI_HCD PPC_OF + depends on PPC_OF default y ---help--- Enables support for the USB controller present on the PowerPC @@ -213,21 +213,21 @@ config USB_EHCI_HCD_PPC_OF config USB_EHCI_SH bool EHCI support for SuperH USB controller - depends on USB_EHCI_HCD SUPERH + depends on SUPERH ---help--- Enables support for the on-chip EHCI controller on the SuperH. If you use the PCI EHCI controller, this option is not necessary. config USB_EHCI_S5P tristate EHCI support for Samsung S5P/EXYNOS SoC Series - depends on USB_EHCI_HCD PLAT_S5P + depends on PLAT_S5P help Enable support for the Samsung S5P and Exynos3/4/5 SOC's on-chip EHCI controller. config USB_EHCI_MV bool EHCI support for Marvell PXA/MMP USB controller - depends on USB_EHCI_HCD (ARCH_PXA || ARCH_MMP) + depends on (ARCH_PXA || ARCH_MMP) select USB_EHCI_ROOT_HUB_TT ---help--- Enables support for Marvell (including PXA and MMP series) on-chip @@ -240,13 +240,13 @@ config USB_EHCI_MV config USB_W90X900_EHCI bool W90X900(W90P910) EHCI support - depends on USB_EHCI_HCD ARCH_W90X900 + depends on ARCH_W90X900 ---help--- Enables support for the W90X900 USB controller config USB_CNS3XXX_EHCI
[PATCH 4/5 v4] USB: enclose all depends on USB_OHCI_HCD within an if USB_OHCI_HCD block
This patch removes the various depends on USB_OHCI_HCD from the OHCI HCD drivers and enclose them within an if USB_OHCI_HCD / endif block. The Octeon OHCI HCD driver has been moved around to remain in this block. Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Florian Fainelli flor...@openwrt.org --- Changes in v4: - refreshed against latest usb-next Changes in v3: - added Alan's Acked-by tag drivers/usb/host/Kconfig | 51 +++--- 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index bc9123c..76f8bbc 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -358,16 +358,18 @@ config USB_OHCI_HCD To compile this driver as a module, choose M here: the module will be called ohci-hcd. +if USB_OHCI_HCD + config USB_OHCI_HCD_OMAP1 bool OHCI support for OMAP1/2 chips - depends on USB_OHCI_HCD ARCH_OMAP1 + depends on ARCH_OMAP1 default y ---help--- Enables support for the OHCI controller on OMAP1/2 chips. config USB_OHCI_HCD_OMAP3 bool OHCI support for OMAP3 and later chips - depends on USB_OHCI_HCD (ARCH_OMAP3 || ARCH_OMAP4) + depends on (ARCH_OMAP3 || ARCH_OMAP4) default y ---help--- Enables support for the on-chip OHCI controller on @@ -375,7 +377,7 @@ config USB_OHCI_HCD_OMAP3 config USB_OHCI_ATH79 bool USB OHCI support for the Atheros AR71XX/AR7240 SoCs (DEPRECATED) - depends on USB_OHCI_HCD (SOC_AR71XX || SOC_AR724X) + depends on (SOC_AR71XX || SOC_AR724X) select USB_OHCI_HCD_PLATFORM default y help @@ -387,7 +389,7 @@ config USB_OHCI_ATH79 config USB_OHCI_HCD_PPC_OF_BE bool OHCI support for OF platform bus (big endian) - depends on USB_OHCI_HCD PPC_OF + depends on PPC_OF select USB_OHCI_BIG_ENDIAN_DESC select USB_OHCI_BIG_ENDIAN_MMIO ---help--- @@ -396,7 +398,7 @@ config USB_OHCI_HCD_PPC_OF_BE config USB_OHCI_HCD_PPC_OF_LE bool OHCI support for OF platform bus (little endian) - depends on USB_OHCI_HCD PPC_OF + depends on PPC_OF select USB_OHCI_LITTLE_ENDIAN ---help--- Enables support for little-endian USB controllers present on the @@ -404,12 +406,12 @@ config USB_OHCI_HCD_PPC_OF_LE config USB_OHCI_HCD_PPC_OF bool - depends on USB_OHCI_HCD PPC_OF + depends on PPC_OF default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE config USB_OHCI_HCD_PCI bool OHCI support for PCI-bus USB controllers - depends on USB_OHCI_HCD PCI (STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF) + depends on PCI (STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF) default y select USB_OHCI_LITTLE_ENDIAN ---help--- @@ -418,7 +420,7 @@ config USB_OHCI_HCD_PCI config USB_OHCI_HCD_SSB bool OHCI support for Broadcom SSB OHCI core (DEPRECATED) - depends on USB_OHCI_HCD (SSB = y || SSB = USB_OHCI_HCD) + depends on (SSB = y || SSB = USB_OHCI_HCD) select USB_HCD_SSB select USB_OHCI_HCD_PLATFORM default n @@ -436,7 +438,7 @@ config USB_OHCI_HCD_SSB config USB_OHCI_SH bool OHCI support for SuperH USB controller (DEPRECATED) - depends on USB_OHCI_HCD SUPERH + depends on SUPERH select USB_OHCI_HCD_PLATFORM ---help--- This option is deprecated now and the driver was removed, use @@ -447,13 +449,13 @@ config USB_OHCI_SH config USB_OHCI_EXYNOS boolean OHCI support for Samsung EXYNOS SoC Series - depends on USB_OHCI_HCD ARCH_EXYNOS + depends on ARCH_EXYNOS help Enable support for the Samsung Exynos SOC's on-chip OHCI controller. config USB_CNS3XXX_OHCI bool Cavium CNS3XXX OHCI Module (DEPRECATED) - depends on USB_OHCI_HCD ARCH_CNS3XXX + depends on ARCH_CNS3XXX select USB_OHCI_HCD_PLATFORM ---help--- This option is deprecated now and the driver was removed, use @@ -464,7 +466,6 @@ config USB_CNS3XXX_OHCI config USB_OHCI_HCD_PLATFORM bool Generic OHCI driver for a platform device - depends on USB_OHCI_HCD default n ---help--- Adds an OHCI host driver for a generic platform device, which @@ -472,23 +473,33 @@ config USB_OHCI_HCD_PLATFORM If unsure, say N. +config USB_OCTEON_OHCI + bool Octeon on-chip OHCI support + depends on CPU_CAVIUM_OCTEON + default USB_OCTEON_EHCI + select USB_OHCI_BIG_ENDIAN_MMIO + select USB_OHCI_LITTLE_ENDIAN + help + Enable support for the Octeon II SOC's on-chip OHCI + controller. It is needed for low-speed USB 1.0 device + support. All CN6XXX based chips with USB are supported. + config USB_OHCI_BIG_ENDIAN_DESC bool - depends on
[PATCH 1/5 v4] USB: regroup all depends on USB within an if USB block
This patch removes the depends on USB from all config symbols in drivers/usb/host/Kconfig and replace that with an if USB / endif block as suggested by Alan Stern. Some source ... Kconfig lines have been shuffled around to permit a better regroupment of the Kconfig files depending on config USB item. No functionnal change is introduced. Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Florian Fainelli flor...@openwrt.org --- Changes since v3: - added Alan's Acked-by tag - refreshed against usb-next Changes since v2: - properly keep USB_MUSB_HDRC dependency Changes since v1: - add missing if USB in drivers/usb/Kconfig before USB_USS720 Changes since RFC: - only remove the depends on USB conditionnals and not more as the RFC patch did drivers/usb/Kconfig| 23 +++ drivers/usb/atm/Kconfig|2 +- drivers/usb/class/Kconfig |6 +- drivers/usb/core/Kconfig |6 -- drivers/usb/host/Kconfig | 30 +++--- drivers/usb/image/Kconfig |4 +--- drivers/usb/misc/Kconfig | 21 - drivers/usb/misc/sisusbvga/Kconfig |2 +- drivers/usb/mon/Kconfig|1 - drivers/usb/musb/Kconfig |2 +- drivers/usb/renesas_usbhs/Kconfig |2 +- drivers/usb/serial/Kconfig |2 +- drivers/usb/storage/Kconfig|7 +++ drivers/usb/wusbcore/Kconfig |2 -- 14 files changed, 36 insertions(+), 74 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 2c481b8..92e1dc9 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -122,9 +122,9 @@ config USB To compile this driver as a module, choose M here: the module will be called usbcore. -source drivers/usb/core/Kconfig +if USB -source drivers/usb/dwc3/Kconfig +source drivers/usb/core/Kconfig source drivers/usb/mon/Kconfig @@ -134,8 +134,6 @@ source drivers/usb/host/Kconfig source drivers/usb/musb/Kconfig -source drivers/usb/chipidea/Kconfig - source drivers/usb/renesas_usbhs/Kconfig source drivers/usb/class/Kconfig @@ -144,12 +142,19 @@ source drivers/usb/storage/Kconfig source drivers/usb/image/Kconfig +endif + +source drivers/usb/dwc3/Kconfig + +source drivers/usb/chipidea/Kconfig + comment USB port drivers - depends on USB + +if USB config USB_USS720 tristate USS720 parport driver - depends on USB PARPORT + depends on PARPORT select PARPORT_NOT_PC ---help--- This driver is for USB parallel port adapters that use the Lucent @@ -180,10 +185,12 @@ source drivers/usb/serial/Kconfig source drivers/usb/misc/Kconfig -source drivers/usb/phy/Kconfig - source drivers/usb/atm/Kconfig +endif # USB + +source drivers/usb/phy/Kconfig + source drivers/usb/gadget/Kconfig endif # USB_SUPPORT diff --git a/drivers/usb/atm/Kconfig b/drivers/usb/atm/Kconfig index be0b8da..0f92294 100644 --- a/drivers/usb/atm/Kconfig +++ b/drivers/usb/atm/Kconfig @@ -4,7 +4,7 @@ menuconfig USB_ATM tristate USB DSL modem support - depends on USB ATM + depends on ATM select CRC32 default n help diff --git a/drivers/usb/class/Kconfig b/drivers/usb/class/Kconfig index 316aac8..bb8b736 100644 --- a/drivers/usb/class/Kconfig +++ b/drivers/usb/class/Kconfig @@ -2,11 +2,10 @@ # USB Class driver configuration # comment USB Device Class drivers - depends on USB config USB_ACM tristate USB Modem (CDC ACM) support - depends on USB TTY + depends on TTY ---help--- This driver supports USB modems and ISDN adapters which support the Communication Device Class Abstract Control Model interface. @@ -21,7 +20,6 @@ config USB_ACM config USB_PRINTER tristate USB Printer support - depends on USB help Say Y here if you want to connect a USB printer to your computer's USB port. @@ -31,7 +29,6 @@ config USB_PRINTER config USB_WDM tristate USB Wireless Device Management support - depends on USB ---help--- This driver supports the WMC Device Management functionality of cell phones compliant to the CDC WMC specification. You can use @@ -42,7 +39,6 @@ config USB_WDM config USB_TMC tristate USB Test and Measurement Class support - depends on USB help Say Y here if you want to connect a USB device that follows the USB.org specification for USB Test and Measurement devices diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index 7b7305e..8772b36 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -3,7 +3,6 @@ # config USB_DEBUG bool USB verbose debug messages - depends on USB help Say Y here if you want the USB core hub drivers to produce a bunch of debug messages to
[PATCH 5/5 v4] USB: enclose USB_XHCI_HCD related symbols within a if USB_XHCI_HCD block
This patch encloses all symbols depending on USB_XHCI_HCD within an if USB_XHCI_HCD / endif block. Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Florian Fainelli flor...@openwrt.org --- Changes in v4: - refreshed against latest usb-next Changes in v3: - added Alan's Acked-by tag drivers/usb/host/Kconfig |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 76f8bbc..c0be25c 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -25,13 +25,13 @@ config USB_XHCI_HCD To compile this driver as a module, choose M here: the module will be called xhci-hcd. +if USB_XHCI_HCD + config USB_XHCI_PLATFORM tristate - depends on USB_XHCI_HCD config USB_XHCI_HCD_DEBUGGING bool Debugging for the xHCI host controller - depends on USB_XHCI_HCD ---help--- Say 'Y' to turn on debugging for the xHCI host controller driver. This will spew debugging output, even in interrupt context. @@ -39,6 +39,8 @@ config USB_XHCI_HCD_DEBUGGING If unsure, say N. +endif # USB_XHCI_HCD + config USB_EHCI_HCD tristate EHCI HCD (USB 2.0) support depends on USB_ARCH_HAS_EHCI -- 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 0/5 v4] USB: Kconfig cleanups
These 5 patches contain my Kconfig cleanup on which I based the removal
of the USB_ARCH_HAS_* patches. They have been suggested by Alan Stern
as part of an earlier conversations.
Let me know what you think about it so I can post subsequent work based
on it.
Florian Fainelli (5):
USB: regroup all depends on USB within an if USB block
USB: remove USB_EHCI_BIG_ENDIAN_{DESC,MMIO} depends on architecture
symbol
USB: enclose EHCI HCD drivers within an if USB_EHCI_HCD block
USB: enclose all depends on USB_OHCI_HCD within an if USB_OHCI_HCD
block
USB: enclose USB_XHCI_HCD related symbols within a if USB_XHCI_HCD
block
arch/arm/Kconfig|2 +
arch/mips/Kconfig |3 +
arch/powerpc/platforms/44x/Kconfig |2 +
arch/powerpc/platforms/512x/Kconfig |2 +
arch/sparc/Kconfig |2 +
drivers/usb/Kconfig | 23 +++--
drivers/usb/atm/Kconfig |2 +-
drivers/usb/class/Kconfig |6 +-
drivers/usb/core/Kconfig|6 --
drivers/usb/host/Kconfig| 169 +--
drivers/usb/image/Kconfig |4 +-
drivers/usb/misc/Kconfig| 21 -
drivers/usb/misc/sisusbvga/Kconfig |2 +-
drivers/usb/mon/Kconfig |1 -
drivers/usb/musb/Kconfig|2 +-
drivers/usb/renesas_usbhs/Kconfig |2 +-
drivers/usb/serial/Kconfig |2 +-
drivers/usb/storage/Kconfig |7 +-
drivers/usb/wusbcore/Kconfig|2 -
19 files changed, 116 insertions(+), 144 deletions(-)
--
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 2/5 v4] USB: remove USB_EHCI_BIG_ENDIAN_{DESC,MMIO} depends on architecture symbol
Just like the OHCI counter part we just can remove the architecture
specific symbols which prevent these configuration symbols from being
selected by platforms/architectures requiring it. The original
implementation did not scale at all since it required each and every
single architecture to be added for these configuration symbols to be
selected. Now it is up to the EHCI driver and/or platform to select
these configuration symbols accordingly.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
Changes in v4:
- refreshed against latest usb-next
Changes in v2:
- added Alan's Acked-by tag
Changes since RFC:
- dropped default n for USB_EHCI_BIG_ENDIAN_{MMIO_DESC} as it is the default
- properly patch MPC521x and not MPC52xx
arch/arm/Kconfig|2 ++
arch/mips/Kconfig |3 +++
arch/powerpc/platforms/44x/Kconfig |2 ++
arch/powerpc/platforms/512x/Kconfig |2 ++
arch/sparc/Kconfig |2 ++
drivers/usb/host/Kconfig| 11 ++-
6 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cacda4..bbddefe 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -549,6 +549,8 @@ config ARCH_IXP4XX
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_PCI
select NEED_MACH_IO_H
+ select USB_EHCI_BIG_ENDIAN_MMIO
+ select USB_EHCI_BIG_ENDIAN_DESC
help
Support for Intel's IXP4XX (XScale) family of processors.
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 51244bf..3a7b395 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -404,6 +404,8 @@ config PMC_MSP
select IRQ_CPU
select SERIAL_8250
select SERIAL_8250_CONSOLE
+ select USB_EHCI_BIG_ENDIAN_MMIO
+ select USB_EHCI_BIG_ENDIAN_DESC
help
This adds support for the PMC-Sierra family of Multi-Service
Processor System-On-A-Chips. These parts include a number
@@ -1433,6 +1435,7 @@ config CPU_CAVIUM_OCTEON
select CPU_SUPPORTS_HUGEPAGES
select LIBFDT
select USE_OF
+ select USB_EHCI_BIG_ENDIAN_MMIO
help
The Cavium Octeon processor is a highly integrated chip containing
many ethernet hardware widgets for networking tasks. The processor
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 0effe9f..7be9336 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -274,6 +274,8 @@ config 440EPX
select IBM_EMAC_EMAC4
select IBM_EMAC_RGMII
select IBM_EMAC_ZMII
+ select USB_EHCI_BIG_ENDIAN_MMIO
+ select USB_EHCI_BIG_ENDIAN_DESC
config 440GRX
bool
diff --git a/arch/powerpc/platforms/512x/Kconfig
b/arch/powerpc/platforms/512x/Kconfig
index c169998..381a592 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -7,6 +7,8 @@ config PPC_MPC512x
select PPC_PCI_CHOICE
select FSL_PCI if PCI
select ARCH_WANT_OPTIONAL_GPIOLIB
+ select USB_EHCI_BIG_ENDIAN_MMIO
+ select USB_EHCI_BIG_ENDIAN_DESC
config MPC5121_ADS
bool Freescale MPC5121E ADS
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 3d361f2..66dc562 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -407,6 +407,8 @@ config SERIAL_CONSOLE
config SPARC_LEON
bool Sparc Leon processor family
depends on SPARC32
+ select USB_EHCI_BIG_ENDIAN_MMIO
+ select USB_EHCI_BIG_ENDIAN_DESC
---help---
If you say Y here if you are running on a SPARC-LEON processor.
The LEON processor is a synthesizable VHDL model of the
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1714c6d..436b682 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -110,18 +110,11 @@ config USB_EHCI_HCD_PMC_MSP
config USB_EHCI_BIG_ENDIAN_MMIO
bool
- depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX || \
- ARCH_IXP4XX || XPS_USB_HCD_XILINX || \
- PPC_MPC512x || CPU_CAVIUM_OCTEON || \
- PMC_MSP || SPARC_LEON || MIPS_SEAD3)
- default y
+ depends on USB_EHCI_HCD
config USB_EHCI_BIG_ENDIAN_DESC
bool
- depends on USB_EHCI_HCD (440EPX || ARCH_IXP4XX || XPS_USB_HCD_XILINX
|| \
- PPC_MPC512x || PMC_MSP || SPARC_LEON || \
- MIPS_SEAD3)
- default y
+ depends on USB_EHCI_HCD
config XPS_USB_HCD_XILINX
bool Use Xilinx usb host EHCI controller core
--
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] usb: ehci-s5p: fix: Fix null pointer dereferencing
Hello. On 09-04-2013 13:21, Vivek Gautam wrote: 7edb3da makes ehci-s5p as a separate driver. But, Please also provide the summary line of that commit in parens. it raised an issue with its driver data. Now that 's5p_ehci_hcd' doesn't maintain pointer to 'usb_hcd' and s5p_ehci is nothing but a pointer to hcd-priv; add hcd to the driver data rather than s5p_ehci. This fixes issues with null pointer dereferencing in s5p_ehci_shutdown(), s5p_ehci_suspend(), s5p_ehci_resume(). Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Manjunath Goudar manjunath.gou...@linaro.org CC: Arnd Bergmann a...@arndb.de CC: Jingoo Han jg1@samsung.com WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
Hello. On 09-04-2013 9:58, Kuninori Morimoto wrote: Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130405v2' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. The patches have been tested on the Marzen board. Please add this tested on xxx comment on each patch's log area, not only on [0/x]. We need it on git log I'm going to post R8A7778/BOCK-W series following this one, and all the patches in 1st series should additionally be tested on BOCK-W. Well, I probably can hold up posting version 3 until I have the second series verified. BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a ferrite bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's used or not on BOCK-W board? PHY initialization seems to work with either settings... [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data I didn't get [7/9][9/9] patch somehow Here they are in the archive: http://marc.info/?l=linux-usbm=136545680506170 http://marc.info/?l=linux-usbm=136545698906257 WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/9] ehci-platform: add pre_setup() method to platform data
Hello. On 09-04-2013 3:42, Greg KH wrote: Sometimes there is a need to initialize some non-standard registers mapped to the EHCI region before accessing the standard EHCI registers. Add pre_setup() method with 'struct usb_hcd *' parameter to be called just before ehci_setup() to the 'ehci-platform' driver's platform data for this purpose... Suggested-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com [...] Index: renesas/include/linux/usb/ehci_pdriver.h === --- renesas.orig/include/linux/usb/ehci_pdriver.h +++ renesas/include/linux/usb/ehci_pdriver.h @@ -19,6 +19,8 @@ #ifndef __USB_CORE_EHCI_PDRIVER_H #define __USB_CORE_EHCI_PDRIVER_H +#include linux/usb/hcd.h This isn't needed in the .h file, right? Only the .c file, if it hasn't already included it (hint, I bet it has...) No, it hasn't. And I wouldn't want to include this header in the platform code. Although, if you insist... It just occured to me that this file doesn't have 'struct platform_device' pre-declared either -- in the best tradition of the USB header files. :-) Yes, if the .h file doesn't need it, don't include it in the .h file. Include it in the .c file instead. The ehci_pdriver.h still needs 'struct platfrom_device' declared. It shouldn't rely on the order of other #include's in the .c file that includes it. That's simply wrong, and I'm adding incomplete declaration while I am touching this file... thanks, greg k-h WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci-s5p: fix: Fix null pointer dereferencing
Hi, On Tue, Apr 9, 2013 at 6:01 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Hello. On 09-04-2013 13:21, Vivek Gautam wrote: 7edb3da makes ehci-s5p as a separate driver. But, Please also provide the summary line of that commit in parens. Sure, will add the commit line of that patch. it raised an issue with its driver data. Now that 's5p_ehci_hcd' doesn't maintain pointer to 'usb_hcd' and s5p_ehci is nothing but a pointer to hcd-priv; add hcd to the driver data rather than s5p_ehci. This fixes issues with null pointer dereferencing in s5p_ehci_shutdown(), s5p_ehci_suspend(), s5p_ehci_resume(). Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Manjunath Goudar manjunath.gou...@linaro.org CC: Arnd Bergmann a...@arndb.de CC: Jingoo Han jg1@samsung.com WBR, Sergei -- 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
[PATCH v2] usb: ehci-s5p: fix: Fix null pointer dereferencing
7edb3da: (USB: EHCI: make ehci-s5p a separate driver) raised an issue with ehci-s5p's driver data. Now that 's5p_ehci_hcd' doesn't maintain pointer to 'usb_hcd' and s5p_ehci is nothing but a pointer to hcd-priv; add hcd to the driver data rather than s5p_ehci. This fixes issues with null pointer dereferencing in s5p_ehci_shutdown(), s5p_ehci_suspend(), s5p_ehci_resume(). Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Manjunath Goudar manjunath.gou...@linaro.org CC: Arnd Bergmann a...@arndb.de CC: Jingoo Han jg1@samsung.com --- Based on 'usb-next' drivers/usb/host/ehci-s5p.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index d8cb0ca..580548a 100644 --- a/drivers/usb/host/ehci-s5p.c +++ b/drivers/usb/host/ehci-s5p.c @@ -173,7 +173,7 @@ static int s5p_ehci_probe(struct platform_device *pdev) goto fail_add_hcd; } - platform_set_drvdata(pdev, s5p_ehci); + platform_set_drvdata(pdev, hcd); return 0; -- 1.7.6.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
[PATCH v2] staging: dwc2: toggle periodic debugging output separately
This adds a config option USB_DWC2_DEBUG_PERIODIC that allows debugging
output be suppressed for periodic transfers. This helps when debugging
non-periodic transfers while there are also periodic transfers going on
(both to make the debug output less polluted and to prevent all CPU time
going to debug messages).
In addition, a debug message from dwc2_hcd_is_status_changed is removed
entirely, since it often floods the log regardless of periodic
transfers.
Signed-off-by: Matthijs Kooijman matth...@stdin.nl
---
Since this patch touches a lot of code and I've developed all my other
patches after this one, I'm sending this patch by itself now, while I'm
reordering my other patches.
v2: fix some coding style issues
drivers/staging/dwc2/Kconfig | 10 ++
drivers/staging/dwc2/core.c | 262 +--
drivers/staging/dwc2/hcd.c | 42 ---
drivers/staging/dwc2/hcd.h | 13 ++
drivers/staging/dwc2/hcd_intr.c | 92 +-
drivers/staging/dwc2/hcd_queue.c | 6 +-
6 files changed, 284 insertions(+), 141 deletions(-)
diff --git a/drivers/staging/dwc2/Kconfig b/drivers/staging/dwc2/Kconfig
index bc4cdfe..2f75be7 100644
--- a/drivers/staging/dwc2/Kconfig
+++ b/drivers/staging/dwc2/Kconfig
@@ -39,4 +39,14 @@ config USB_DWC2_TRACK_MISSED_SOFS
Say Y here to enable logging of missed SOF events to the dmesg log.
If in doubt, say N.
+config USB_DWC2_DEBUG_PERIODIC
+ bool Enable Debugging Messages For Periodic Transfers
+ depends on USB_DWC2_DEBUG || USB_DWC2_VERBOSE
+ default y
+ help
+ Say N here to disable (verbose) debugging messages to be
+ logged for periodic transfers. This allows better debugging of
+ non-periodic transfers, but of course the debug logs will be
+ incomplete. Note that this also disables some debug messages
+ for which the transfer type cannot be deduced.
endif
diff --git a/drivers/staging/dwc2/core.c b/drivers/staging/dwc2/core.c
index f695a9b0..c52c568 100644
--- a/drivers/staging/dwc2/core.c
+++ b/drivers/staging/dwc2/core.c
@@ -717,7 +717,9 @@ static void dwc2_hc_enable_slave_ints(struct dwc2_hsotg
*hsotg,
break;
case USB_ENDPOINT_XFER_INT:
+ #ifdef CONFIG_USB_DWC2_DEBUG_PERIODIC
dev_vdbg(hsotg-dev, intr\n);
+ #endif
hcintmsk |= HCINTMSK_XFERCOMPL;
hcintmsk |= HCINTMSK_NAK;
hcintmsk |= HCINTMSK_STALL;
@@ -738,7 +740,9 @@ static void dwc2_hc_enable_slave_ints(struct dwc2_hsotg
*hsotg,
break;
case USB_ENDPOINT_XFER_ISOC:
+ #ifdef CONFIG_USB_DWC2_DEBUG_PERIODIC
dev_vdbg(hsotg-dev, isoc\n);
+ #endif
hcintmsk |= HCINTMSK_XFERCOMPL;
hcintmsk |= HCINTMSK_FRMOVRUN;
hcintmsk |= HCINTMSK_ACK;
@@ -754,7 +758,8 @@ static void dwc2_hc_enable_slave_ints(struct dwc2_hsotg
*hsotg,
}
writel(hcintmsk, hsotg-regs + HCINTMSK(chan-hc_num));
- dev_vdbg(hsotg-dev, set HCINTMSK to %08x\n, hcintmsk);
+ if (dbg_hc(chan))
+ dev_vdbg(hsotg-dev, set HCINTMSK to %08x\n, hcintmsk);
}
static void dwc2_hc_enable_dma_ints(struct dwc2_hsotg *hsotg,
@@ -767,17 +772,20 @@ static void dwc2_hc_enable_dma_ints(struct dwc2_hsotg
*hsotg,
* Interrupt is not required.
*/
if (hsotg-core_params-dma_desc_enable = 0) {
- dev_vdbg(hsotg-dev, desc DMA disabled\n);
+ if (dbg_hc(chan))
+ dev_vdbg(hsotg-dev, desc DMA disabled\n);
hcintmsk |= HCINTMSK_AHBERR;
} else {
- dev_vdbg(hsotg-dev, desc DMA enabled\n);
+ if (dbg_hc(chan))
+ dev_vdbg(hsotg-dev, desc DMA enabled\n);
if (chan-ep_type == USB_ENDPOINT_XFER_ISOC)
hcintmsk |= HCINTMSK_XFERCOMPL;
}
if (chan-error_state !chan-do_split
chan-ep_type != USB_ENDPOINT_XFER_ISOC) {
- dev_vdbg(hsotg-dev, setting ACK\n);
+ if (dbg_hc(chan))
+ dev_vdbg(hsotg-dev, setting ACK\n);
hcintmsk |= HCINTMSK_ACK;
if (chan-ep_is_in) {
hcintmsk |= HCINTMSK_DATATGLERR;
@@ -787,7 +795,8 @@ static void dwc2_hc_enable_dma_ints(struct dwc2_hsotg
*hsotg,
}
writel(hcintmsk, hsotg-regs + HCINTMSK(chan-hc_num));
- dev_vdbg(hsotg-dev, set HCINTMSK to %08x\n, hcintmsk);
+ if (dbg_hc(chan))
+ dev_vdbg(hsotg-dev, set HCINTMSK to %08x\n, hcintmsk);
}
static void dwc2_hc_enable_ints(struct dwc2_hsotg *hsotg,
@@ -796,10 +805,12 @@ static void dwc2_hc_enable_ints(struct dwc2_hsotg *hsotg,
u32 intmsk;
if (hsotg-core_params-dma_enable 0) {
- dev_vdbg(hsotg-dev, DMA enabled\n);
+ if
Re: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
On Tue, Apr 09, 2013 at 04:00:15PM +0400, Sergei Shtylyov wrote: Hello. On 05-04-2013 6:01, Kuninori Morimoto wrote: Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130404v2' tag and the 2 Ether patches I've reposted yesterday. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/8] ARM: shmobile:Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/8] ehci-platform: add init() method to platform data [3/8] ARM: shmobile: R8A7779: setup EHCI internal buffer [4/8] rcar-phy: remove EHCI internal buffer setup [5/8] rcar-phy: correct base address [6/8] rcar-phy: add platform data [7/8] ARM: shmobile: Marzen: pass platform data to USB PHY device [8/8] rcar-phy: handle platform data I'm not sure thru which tree this patchset should be merged, however it turns out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10, so maybe the patchset can be merged thru Simon's tree with Felipe's and Alan Stern's ACKs. I guess you already got request about patch style from Simon. When you send v2 patch, could you please add this patch is tested on bard on each patch's comment area ? I thought adding it to each patch (BTW, I didn't get what you meant: changelog or the area below ---) was a bit too much and just mentioned it in the cover letter. Then, for all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Sorry, I forgot to add this. If you still want it, I'll add it to version 3 that will be posted today. You can also add Acked-by: Simon Horman horms+rene...@verge.net.au I'll replace it with a Sob line if the patches end up going through my tree. Best regards --- Kuninori Morimoto WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/9] ehci-platform: add pre_setup() method to platform data
On Tue, 9 Apr 2013, Sergei Shtylyov wrote: --- renesas.orig/include/linux/usb/ehci_pdriver.h +++ renesas/include/linux/usb/ehci_pdriver.h @@ -19,6 +19,8 @@ #ifndef __USB_CORE_EHCI_PDRIVER_H #define __USB_CORE_EHCI_PDRIVER_H +#include linux/usb/hcd.h This isn't needed in the .h file, right? Only the .c file, if it hasn't already included it (hint, I bet it has...) No, it hasn't. And I wouldn't want to include this header in the platform code. Then you don't need it in this .h file either, please remove it. I do need it in the platform .c file. Well, long live multiple redeclarations of the same thing! If you do remove that line from ehci_pdriver.h, you should add a declaration of struct usb_hcd. Like this: struct usb_hcd; Otherwise the compiler will complain when it sees this structure mentioned for the first time in the parameter list of a function-pointer declaration. 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: Linux USB file storage gadget with new UDC
On Tue, 9 Apr 2013, victor yeo wrote:
Hi,
Earlier, you complained that your gadget was able to read the boot
sector but not the MBR! :-)
How do you know the reads were sending all zeros? The usbmon output
shows only the first 32 bytes of each transfer, and the gadget
debugging output doesn't show the data for READ or WRITE commands at
all.
What makes you think the gadget isn't reading the boot sector? What is
the boot sector's LBA (logical block address)?
Earlier, i used file=/dev/mmcblk0p1. Now i use
file=/mnt/sd/backing_file. This backing_file is a dummy file system
that i created. I attached two jpeg files. One show the MBR and Boot
Sector of the backing_file. Another shows the usbmon of the Linux Host
Why did you send jpeg files? Plain text files are a lot easier to work
with. Now I can't copy and paste the lines from your files into this
email message. :-(
PC. I also attached the udc log which shows the MBR and Boot Sector
content which are read from the backing_file.
The UDC log indicates that the MBR and boot sectors were read
correctly.
From the usbmon jpeg,
that first SCSI_READ_10 command got a overflow error, the second
SCSI_READ_10 command got a connection reset error. Is the overflow
error occurred because the host PC cannot handle the data returned
from the gadget device?
The usbmon log shows that the host sent the gadget a READ(10) command
for 8 sectors, which 4096 bytes. It then requested a 4096-byte
transfer on the bulk-in endpoint, expecting the gadget to reply with
eight packets, each containing 512 bytes (because the bulk-in
wMaxPacketSize is 512).
But the gadget did not reply correctly. The UDC sent a data packet
containing only 256 bytes, instead of 512 bytes. The overflow occurred
when it sent a second data packet, again containing the wrong number of
bytes.
Call the gadget driver's -reset handler. If the -reset pointer is
NULL, call the -disconnect handler instead. See the code in
net2280.c's handle_stat1_irqs() as an example.
Alan Stern
i read the net2280.c code. Is it the usb_reset() function, called by
stop_activity()? I am sorry if i understand incorrectly.
No, it is the handle_stat1_irqs() function, as I wrote above. In
particular, this part of the code, which handles both disconnects and
resets:
if (disconnect || reset) {
stop_activity(dev, dev-driver);
ep0_start(dev);
spin_unlock(dev-lock);
if (reset dev-driver-reset)
(dev-driver-reset)(dev-gadget);
else
(dev-driver-disconnect)(dev-gadget);
spin_lock(dev-lock);
return;
}
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: Linux USB file storage gadget with new UDC
On Tue, 9 Apr 2013, victor yeo wrote: Another usbmon trace showing 3 SCSI_READ_10 command. This trace shows that the READ(10) commands worked correctly. Good. But it also shows that the gadget did not respond correctly to the 0xA1 command near the end. The UDC was supposed to set the Halt feature for the bulk-in endpoint and send a STALL packet, but it didn't. 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: USB3.0 Interrupt transfer in u-boot
It sounds like u-boot already has basic xHCI support, and you should contact the u-boot developers for further support of interrupt transfers. http://lists.denx.de/mailman/listinfo/u-boot or https://lists.sourceforge.net/lists/listinfo/u-boot-users Disregard my comments about bit-banging the EHCI interfaces. Sarah Sharp On Tue, Apr 09, 2013 at 09:38:17AM +0530, Puneet Sharma wrote: Hello Sarah, Thanks a lot for the information. For your information i am successfully able to enumerate USB device(USB keyboard) over XHCI port by the help of XHCI Stack patch provided in u-boot and also able to do BULK transfer over Mass storage device. After successfully able to do CONTROL and BULK transfer i decided to go for INTERRUPT transfer which i dont know is possible or not. Definately i dont have deep knowledge about Linux USB stack and so i posted the query to get some understanding of it. Also, when you say EHCI can bit-bang the interface what do you mean by that?? Thanks Puneet On Tue, 2013-04-09 at 04:31 +0530, Sarah Sharp wrote: The Linux xHCI driver relies on the USB core for setup. You really don't want to attempt to to separate the two. You can't get just interrupts for transfers either -- you need to do a lot of xHCI host setup before you can even send a control transfer to the device (which is necessary to find out whether it *is* a keyboard). Also, xHCI is not like EHCI, where you can bit-bang the interface. You have to have MMIO and DMA set up before you can use the xHCI host. You might be able to get away without having interrupts and polling the event ring, but I've never tried using any xHCI hosts that way. Also, I don't know what the license is for uboot, but you should know that the xHCI driver is GPL v2 only, and we can't change that. If the license is ok, and you want to take a stab at using the code, it's in drivers/usb/host/xhci*, with some bits in drivers/usb/host/pci-quirks.c. I think you've got some serious yak-shaving ahead of you, so you should think about whether you actually want to add xHCI support to uboot. It's clear that you don't know much about the Linux USB stack, and I'm afraid porting the xHCI driver code over to uboot is going to be pretty painful for you. Sarah Sharp On Wed, Apr 03, 2013 at 11:23:56AM +0530, Puneet Sharma wrote: Hello Sarah, I want to test USB keyboard for XHCI in u-boot and to do that i need the Interrupt transfer code in XHCI controller driver. If possible, can you help me to give that piece of code or can you help me to figure out in kernel where can i find it so that i can try to replicate it in u-boot and make it work. Thanks Regards -- Puneet Sharma puneet.sha...@moschip.commailto:puneet.sha...@moschip.com The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -- 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 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
* Roger Quadros rog...@ti.com [130409 03:00]: On 04/05/2013 06:58 PM, Tony Lindgren wrote: Well your approach is fine as a first step moving all the clock code, but it needs to be a real driver under drivers/clock/omap. And the DT binding needs to stay the same for the driver(s) in the long term as we start moving clocks to DT + /lib/firmware. The code needs to be there were the clock structs are defined. Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4. But if you do just a passthrough driver then that should not be needed. If this all is too late for v3.10, I suggest you just set up the right clock alias for panda with machine_is_compatible flag in board-generic.c so we get EHCI working with DT for v3.10. Then it's easy to to deal with it properly for v3.11. OK, let's do it this way for Panda for 3.10. Yes otherwise we'll be delaying omap4 DT conversion again. How can that driver do clk_get() from cclock44xx_data.c? from where does it get the clk_id to pass into clk_get()? Can't you just use the clock name there to get it? In device tree we don't pass around clock names. You can either get a phandle or an index to the clock. e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt Yes I understand that. But the driver/clock/omap driver can just remap the DT device initially so the board specific clock is found from the clock alias table. Basically initially a passthrough driver that can be enhanced to parse DT clock bindings and load data from /lib/firmware. As long as the binding stays the same in the long run too, this clock remapping approach is just fine as a starting point. And the driver needs to go to drivers/clock/omap. But in the long run we just want to get the huge amounts static data out of the kernel for clocks and hwmod data to fix things for good. In that case we need to identify what clocks need to be supported. If it is all (~200) of them, is this method good enough? We should support any clock we need for booting the device with just DT bindings to get timers, console and rootfs working. Then we just need to load the complete set from /lib/firmware. It seems that the binding can be the same for all the clocks. For now, we can just use the standard clock binding and do the remapping in the clock driver. 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
Re: [PATCH v2 2/9] ehci-platform: add pre_setup() method to platform data
Hello. On 04/09/2013 07:27 PM, Alan Stern wrote: --- renesas.orig/include/linux/usb/ehci_pdriver.h +++ renesas/include/linux/usb/ehci_pdriver.h @@ -19,6 +19,8 @@ #ifndef __USB_CORE_EHCI_PDRIVER_H #define __USB_CORE_EHCI_PDRIVER_H +#include linux/usb/hcd.h This isn't needed in the .h file, right? Only the .c file, if it hasn't already included it (hint, I bet it has...) No, it hasn't. And I wouldn't want to include this header in the platform code. Then you don't need it in this .h file either, please remove it. I do need it in the platform .c file. Well, long live multiple redeclarations of the same thing! If you do remove that line from ehci_pdriver.h, you should add a declaration of struct usb_hcd. Like this: struct usb_hcd; Otherwise the compiler will complain when it sees this structure mentioned for the first time in the parameter list of a function-pointer declaration. That's what I did, thanks. I've also added 'struct platform_device;' line for the same reason. Alan Stern WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] staging: dwc2: toggle periodic debugging output separately
On Tue, Apr 09, 2013 at 05:01:36PM +0200, Matthijs Kooijman wrote: This adds a config option USB_DWC2_DEBUG_PERIODIC that allows debugging output be suppressed for periodic transfers. This helps when debugging non-periodic transfers while there are also periodic transfers going on (both to make the debug output less polluted and to prevent all CPU time going to debug messages). In addition, a debug message from dwc2_hcd_is_status_changed is removed entirely, since it often floods the log regardless of periodic transfers. Signed-off-by: Matthijs Kooijman matth...@stdin.nl why don't you just use dynamic printk instead ? -- balbi signature.asc Description: Digital signature
Re: USB to SPI driver for MCP2210
Hi, On Mon, Apr 08, 2013 at 03:59:00PM -0500, Daniel Santos wrote: My bother I are working on a project where we're planning on using these inexpensive Microchip MCP2210 USB to SPI bridge w/ GPIO devices. Mathew King at Trilithic started a driver and kindly released it on github (https://github.com/MathewKing/mcp2210-linux), but he wont be using the chip or developing the driver further, so I'm picking it up (and with his blessings even! :) However, rather than a driver written specifically for our product, I would like a generic or abstract MCP2210 driver that can be re-used by others. So how do I go about this? I'm not sure you can. There is no standardization wrt USB to SPI bridges, so your device implements a proprietary protocol (even if simple). I'm still pretty new to Linux device drivers the device driver model, so there may be existing abstractions libraries that I'm just not yet aware of. We're not planning on changing the USB vendor/product ID (as I'm sure many users of this chip will opt) and each or our devices can have different hardware wirings attached to the MCP2210. Since SPI devices cannot be auto-configured, we plan to this might cause problems. If everybody has the same idVendor/idProduct pair but functionality is different... ugh probe as follows: * In the USB probe, examine the iProduct string to match our specific product (maybe iManufacturer as well) and if it matches, to bind to the device. no, you want to match idVendor and idProduct. No need to match strings. * The MCP2210 has 9 GP pins that can each be used as either an SPI chip select, GPIO or a dedicated function (power LED, interrupt input line, etc.). Once bound, we can examine the power-up chip settings (section 3.1.7 in the datasheet -- http://ww1.microchip.com/downloads/en/DeviceDoc/22288A.pdf) and treat that as the specification as to how each GP pin is used in this device. oh, so this is actually a multifunction device. What you might be looking for is a core driver which registers itself with the MFD layer (drivers/mfd) and exposes clients based on some parameters passed to it through e.g. pinctrl framework. You can have at least three children: . an SPI bus . a GPIO/IRQ chip . LED Your core driver would instantiate each of those children devices based on what's the requested state of the pin. * Finally, retrieve the (previously stored) data from the 256 bytes of user non-volatile EEPROM. On this, we plan to store the device information that each of the GP pins configured for SPI CS lines are connected as well as the use for any GPIO lines. (Pins configured for dedicated function need no other information.) is this mandatory, or something you decided to do ? If it's mandatory to program pin assignment like that, then you can very easily figure out how to use that information to instantiate proper children during your core driver's probe routine. If it's not mandatory, then it gets tricky to support multiple users. Can users write whatever they want to EEPROM or is there a specified format ? In any case, there are ways to make it work, just some are easier to code then the others ;-) -- balbi signature.asc Description: Digital signature
Re: USB3.0 Interrupt transfer in u-boot
On Tue, 9 Apr 2013 09:31:18 -0700 Sarah Sharp sarah.a.sh...@linux.intel.com wrote: It sounds like u-boot already has basic xHCI support, and you should contact the u-boot developers for further support of interrupt transfers. http://lists.denx.de/mailman/listinfo/u-boot This is the correct U-Boot list, yes. or https://lists.sourceforge.net/lists/listinfo/u-boot-users Note that this u-boot-users list is outdated and not used any more. Thanks, Anatolij -- 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: [help] imx27 - isp1504 : unable to init transceiver, probably missing
On Mon, Apr 8, 2013 at 9:09 PM, Fabio Estevam feste...@gmail.com wrote: I know that I have to use the driver ULPI but with my configuration, I get these errors : ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing Just tested mx31pdk on a 3.8.6 kernel and I got: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller ULPI transceiver vendor/product ID 0x04cc/0x1504 Found NXP ISP1504 ULPI transceiver. ULPI integrity check: passed. mxc-ehci mxc-ehci.0: EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.0: irq 53, io mem 0x43f88000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing This board has one USB otg port and another USB Host2 port. The USB otg port probed correctly and it works in host mode. However the USB Host2 port failed in the same way as in mx27. -- 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] staging: dwc2: toggle periodic debugging output separately
Hi Felipe, This adds a config option USB_DWC2_DEBUG_PERIODIC that allows debugging output be suppressed for periodic transfers. This helps when debugging non-periodic transfers while there are also periodic transfers going on (both to make the debug output less polluted and to prevent all CPU time going to debug messages). [...] Signed-off-by: Matthijs Kooijman matth...@stdin.nl why don't you just use dynamic printk instead ? In some cases, this could help, but a lot of the prints modified by this patch are used for both periodic and non-periodic transfers. AFAIU, with dynamic printks you could only enable/disable them altogether, not based on some arbitrary condition (e.g., the urb being handled is targeted at a periodic endpoint or not). Gr. Matthijs -- 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 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
* Tony Lindgren t...@atomide.com [130409 09:54]: * Roger Quadros rog...@ti.com [130409 03:00]: On 04/05/2013 06:58 PM, Tony Lindgren wrote: Can't you just use the clock name there to get it? In device tree we don't pass around clock names. You can either get a phandle or an index to the clock. e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt Yes I understand that. But the driver/clock/omap driver can just remap the DT device initially so the board specific clock is found from the clock alias table. Basically initially a passthrough driver that can be enhanced to parse DT clock bindings and load data from /lib/firmware. Actually probably the driver/clock/omap can even do even less initially. There probably even no need to remap clocks there. As long as the DT clock driver understands that a board specific auxclk is specified in the DT it can just call clk_add_alias() so the driver will get the right auxclk from cclock44xx_data.c. Then other features can be added later on like to allocate a clock entirely based on the binding etc. 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
Power state of USB port on computer reboot
Hi, subject: Power supply interrupted on USB port (normal and Always-on) when performing reboot from any Windows version but not when rebooting from Linux or BIOS (Lenovo ThinkPad T4xx). Why the difference? According to my research there is no standard describing the power state (power on/power off) of USB port on computer reboot. Is that really so? The problem we are having is the following. We have external hardware VPN device which is powered through USB port. In order to establish VPN, one must access web page on the device and enter password. To be able to log-in to domain and apply Computer Configuration part of Group Policy assigned through AD, one must first log-in (offline, cached mode), establish VPN tunnel, perform OS reboot and log-in to domain. Since the device is USB powered it is mandatory that there is no interruption of power supply during this procedure. On Dell laptops (several models) and Apple Mac Books Pros this works perfectly. However, on Lenovo ThinkPad (tested T410 and T420), the USB power supply is interrupted during Windows OS reboot. Strangely it is not interrupted when performing reboot in Linux or when still in POST/BIOS mode. Another strange thing is that power supply is interrupted for different periods of time. T410 WinXP 225ms (525ms), T410 Win7x86 25ms(350ms), T410 Win7x64 75ms (350ms), T410 Win8 1050ms (1350ms), T420 Win7x86 5ms. The values in parenthesis denote measurements on Allways-On USB port. Is it possible to influence USB power on OS reboot? Linux and BIOS don't interrupt the power of USB port on reboot, only Windows (all versions we tested do). This along with different times of power lack leads me to conclusion that there is no standard regarding this issue. Also we are dealing with SW+HW, since we only found this issue with Lenovo ThinkPads. Blaz Malnersic -- 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 to SPI driver for MCP2210
On 04/09/2013 12:15 AM, Greg KH wrote: On Mon, Apr 08, 2013 at 03:59:00PM -0500, Daniel Santos wrote: 1. Discover that the kernel already contains an abstraction layer for an x to SPI bridge device and that I just need to write an MCP2210 driver for it! We have lots of SPI drivers in the kernel already, but no USB ones that I know of. It shouldn't be hard to create a driver for this that lives under drivers/spi/ and follows the api that it needs there. You might want to ask the Linux SPI developers about this if you have more information, they can help you better then we can. Ahh, thanks. Is there a linux-spi mailing list somewhere? I didn't find one on vger.kernel.org. Thanks! Daniel -- 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] xhci: fix list access before ini
If for whatever reason we fall into fail path in xhci_mem_init()
before bw table gets initialized we may access the uninitialized lists
in xhci_mem_cleanup().
Check for bw table before traversing lists in cleanup routine.
Reported-by: Sergey Dyasly dse...@gmail.com
Tested-by: Sergey Dyasly dse...@gmail.com
Signed-off-by: Vladimir Murzin murzi...@gmail.com
---
This patch is generated across
http://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/log/?h=for-usb-linus-queue
Changes since:
v1 - init for cancel_cmd_list and lpm_failed lists
is skipped because Sergio has already been working on
it http://marc.info/?l=linux-usbm=136509667003716w=2
- bw table is checked for existence in xhci_mem_cleanup()
routine instead of moving bw init code at beginning of
xhci_mem_init() routine (as it was proposed by Sharah}
drivers/usb/host/xhci-mem.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ffbdefc..ea44dc9 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1826,6 +1826,9 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
}
spin_unlock_irqrestore(xhci-lock, flags);
+ if (!xhci-rh_bw)
+ goto no_bw;
+
num_ports = HCS_MAX_PORTS(xhci-hcs_params1);
for (i = 0; i num_ports; i++) {
struct xhci_interval_bw_table *bwt = xhci-rh_bw[i].bw_table;
@@ -1844,6 +1847,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
}
}
+no_bw:
xhci-num_usb2_ports = 0;
xhci-num_usb3_ports = 0;
xhci-num_active_eps = 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
Re: USB to SPI driver for MCP2210
On Tue, Apr 09, 2013 at 01:24:55PM -0500, Daniel Santos wrote: On 04/09/2013 12:15 AM, Greg KH wrote: On Mon, Apr 08, 2013 at 03:59:00PM -0500, Daniel Santos wrote: 1. Discover that the kernel already contains an abstraction layer for an x to SPI bridge device and that I just need to write an MCP2210 driver for it! We have lots of SPI drivers in the kernel already, but no USB ones that I know of. It shouldn't be hard to create a driver for this that lives under drivers/spi/ and follows the api that it needs there. You might want to ask the Linux SPI developers about this if you have more information, they can help you better then we can. Ahh, thanks. Is there a linux-spi mailing list somewhere? I didn't find one on vger.kernel.org. Look in the MAINTAINERS file (hint, it's at spi-devel-gene...@lists.sourceforge.net) -- 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: Power state of USB port on computer reboot
On Tue, Apr 09, 2013 at 02:00:51PM +, Blaz Malnersic wrote: Is it possible to influence USB power on OS reboot? Linux and BIOS don't interrupt the power of USB port on reboot, only Windows (all versions we tested do). This along with different times of power lack leads me to conclusion that there is no standard regarding this issue. Also we are dealing with SW+HW, since we only found this issue with Lenovo ThinkPads. As you are having problems with Windows, not Linux, why are you asking this on a Linux mailing list? Please just file a bug with Windows if this is a needed thing for your systems (hint, you can never rely on USB power being present across a reboot, that's an undefined system state, sorry.) good luck, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB to SPI driver for MCP2210
On 04/09/2013 12:07 PM, Felipe Balbi wrote: Hi, On Mon, Apr 08, 2013 at 03:59:00PM -0500, Daniel Santos wrote: My bother I are working on a project where we're planning on using these inexpensive Microchip MCP2210 USB to SPI bridge w/ GPIO devices. Mathew King at Trilithic started a driver and kindly released it on github (https://github.com/MathewKing/mcp2210-linux), but he wont be using the chip or developing the driver further, so I'm picking it up (and with his blessings even! :) However, rather than a driver written specifically for our product, I would like a generic or abstract MCP2210 driver that can be re-used by others. So how do I go about this? I'm not sure you can. There is no standardization wrt USB to SPI bridges, so your device implements a proprietary protocol (even if simple). I'm still pretty new to Linux device drivers the device driver model, so there may be existing abstractions libraries that I'm just not yet aware of. We're not planning on changing the USB vendor/product ID (as I'm sure many users of this chip will opt) and each or our devices can have different hardware wirings attached to the MCP2210. Since SPI devices cannot be auto-configured, we plan to this might cause problems. If everybody has the same idVendor/idProduct pair but functionality is different... ugh Well, we don't have the $3500 for a vendor id. :( I presume that others may do the same thing, hopefully mostly with DIY-type of projects. probe as follows: * In the USB probe, examine the iProduct string to match our specific product (maybe iManufacturer as well) and if it matches, to bind to the device. no, you want to match idVendor and idProduct. No need to match strings. * The MCP2210 has 9 GP pins that can each be used as either an SPI chip select, GPIO or a dedicated function (power LED, interrupt input line, etc.). Once bound, we can examine the power-up chip settings (section 3.1.7 in the datasheet -- http://ww1.microchip.com/downloads/en/DeviceDoc/22288A.pdf) and treat that as the specification as to how each GP pin is used in this device. oh, so this is actually a multifunction device. What you might be looking for is a core driver which registers itself with the MFD layer (drivers/mfd) and exposes clients based on some parameters passed to it through e.g. pinctrl framework. w00t! Thanks! I think this is the device class (not sure if that's the correct term) I'm looking for. Yes, I suppose this is a multi-function device, since it exposes both an SPI master with a few chip selects as well as GPIO and some other random functionality. You can have at least three children: . an SPI bus . a GPIO/IRQ chip . LED Your core driver would instantiate each of those children devices based on what's the requested state of the pin. * Finally, retrieve the (previously stored) data from the 256 bytes of user non-volatile EEPROM. On this, we plan to store the device information that each of the GP pins configured for SPI CS lines are connected as well as the use for any GPIO lines. (Pins configured for dedicated function need no other information.) is this mandatory, or something you decided to do ? If it's mandatory to program pin assignment like that, then you can very easily figure out how to use that information to instantiate proper children during your core driver's probe routine. Well, I guess I need to be more clear about this. I'm talking about 3 separate entities really: 1. the MCP2210 chip its self, 2. the hardware device that I'm creating that makes use of this chip and 3. any hardware devices that others may create with it. So one idea of how to do this is to have generic MCP2210 driver that does pretty much nothing by its self (not 100% sure how this should work). Then, I would have a driver for my device, that would use the generic MCP2210 driver to manage all of the communication with the MCP2210 and I would simply feed it my hardware configuration (wiring, SPI timings, etc.), causing it to expose SPI devices, GPIO lines, LEDs, etc. as you described. Then, a 3rd party could do the same (hopefully, they will modify the idVendor idProduct though. :) I suppose there's room for an MCP2210 userspace driver that utilizes the generic one to interface with the chip and just provides an interface to userspace, but I'm not personally interested in such a thing myself. So I'm thinking that with my own driver, I would look for the idVendor and idProduct of the unmodified MCP2210 (because I'm a poor bastard) and then -ENODEV unless the product mfg strings also match. Then, I can read the EEPROM to cook up my config. (One complexity is that our device can have various features hardware present or not, so that's another reason for us to stick the hardware setup in the EEPROM.) Does that make sense? Also, the generic driver then becomes more of a library than an actual driver, huh? I presume If it's not mandatory, then it gets tricky to
Re: USB to SPI driver for MCP2210
On Tue, Apr 09, 2013 at 02:00:46PM -0500, Daniel Santos wrote: Well, we don't have the $3500 for a vendor id. :( I presume that others may do the same thing, hopefully mostly with DIY-type of projects. Do you know this one: http://wiki.openmoko.org/wiki/USB_Product_IDs#USB_Vendor_and_Product_IDs rsc -- 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: [PATCH v2] staging: dwc2: toggle periodic debugging output separately
From: Matthijs Kooijman [mailto:matth...@stdin.nl] Sent: Tuesday, April 09, 2013 8:02 AM This adds a config option USB_DWC2_DEBUG_PERIODIC that allows debugging output be suppressed for periodic transfers. This helps when debugging non-periodic transfers while there are also periodic transfers going on (both to make the debug output less polluted and to prevent all CPU time going to debug messages). In addition, a debug message from dwc2_hcd_is_status_changed is removed entirely, since it often floods the log regardless of periodic transfers. Hi Matthijs, This is fine by me. This should be OK while the driver is in staging, but would probably have to be removed before the driver could be moved to mainline. But at that point the plan is to remove most of the debug messages anyway. A couple of coding style problems - in the kernel, #ifdef statements always start in column 0, they are not indented with the C code like you have done. Also, instead of having #ifdef CONFIG_USB_DWC2_DEBUG_PERIODIC statements in the .c files, please add another macro, say dbg_isoc(), which is true if USB_DWC2_DEBUG_PERIODIC is defined, and use that in the .c files instead. If you fix those two things, I will take this. One question - is this meant to be applied now, or is it based on top of your previous patch series which you are redoing? -- Paul -- 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
[RFC PATCH v2 0/4] USB: OMAP: Tahvo USB support for 770
Hi, These patches add support for Tahvo USB transceiver and allow using both host and peripheral modes on Nokia 770. Patches are currently based on top of Felipe's next branch (git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git, 9b192de60b5a584ee4ed967fb6758773c75e4643). To make them work on 770, some additional OMAP1 fixes are also needed which are already present in 3.9-rc6 or queued for 3.10. Test cases were roughly following: - CONFIG_TAHVO_USB_HOST_BY_DEFAULT - ohci-hcd, omap_udc, g_ether loaded as modules during boot - check host mode functionality after boot with USB keyboard - switch to peripheral mode and check functionality with ssh - switch back to host mode - !CONFIG_TAHVO_USB_HOST_BY_DEFAULT - ohci-hcd, omap_udc, g_ether loaded as modules during boot - check peripheral mode after boot with ssh - switch to host mode and check with USB keyboard - switch back to peripheral mode - other - check USB cable on/off detection (Tahvo vbus interrupt) Changes since the first RFC (http://marc.info/?l=linux-omapm=136266725827698w=2): - retu-mfd - use i2c address to detect retu vs. tahvo - phy-omap-otg - don't mess with isp1301_omap.c - move to drivers/usb/phy, rename omap-otg - phy-omap-otg - phy-tahvo - drop illegal includes - move to drivers/usb/phy, rename tahvo-usb - phy-tahvo - serialize vbus interrupt handling - delete dummy/unimplemented functions - drop peripheral/host only config - don't use OTG interrupt, not needed - don't write to OTG_SYSCON_1/2, this is handled by board code - move OTG CTRL handling to omap-otg Please review and comment. Thanks, A. Aaro Koskinen (4): retu-mfd: support also Tahvo ARM: OMAP1: nokia770: enable Tahvo USB: OMAP: add omap-otg USB: OMAP: Tahvo USB transceiver driver arch/arm/mach-omap1/board-nokia770.c | 10 + drivers/mfd/Kconfig |6 +- drivers/mfd/retu-mfd.c | 85 ++- drivers/usb/phy/Kconfig | 24 ++ drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-omap-otg.c | 126 ++ drivers/usb/phy/phy-tahvo.c | 429 ++ include/linux/mfd/retu.h |8 +- include/linux/usb/omap-otg.h | 19 ++ 9 files changed, 695 insertions(+), 14 deletions(-) create mode 100644 drivers/usb/phy/phy-omap-otg.c create mode 100644 drivers/usb/phy/phy-tahvo.c create mode 100644 include/linux/usb/omap-otg.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
[RFC PATCH v2 1/4] retu-mfd: support also Tahvo
Tahvo is a multi-function device on Nokia 770, implementing USB
transceiver and charge/battery control.
It's so close to Retu that a single driver can support both.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/Kconfig |6 ++--
drivers/mfd/retu-mfd.c | 85 --
include/linux/mfd/retu.h |8 -
3 files changed, 85 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c346941..8628955 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1102,13 +1102,13 @@ config MFD_VIPERBOARD
The drivers do not support all features the board exposes.
config MFD_RETU
- tristate Support for Retu multi-function device
+ tristate Support for Retu and Tahvo multi-function devices
select MFD_CORE
depends on I2C GENERIC_HARDIRQS
select REGMAP_IRQ
help
- Retu is a multi-function device found on Nokia Internet Tablets
- (770, N800 and N810).
+ Retu and Tahvo are multi-function devices found on Nokia
+ Internet Tablets (770, N800 and N810).
config MFD_AS3711
bool Support for AS3711
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index 3ba0486..a183098 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -1,5 +1,5 @@
/*
- * Retu MFD driver
+ * Retu/Tahvo MFD driver
*
* Copyright (C) 2004, 2005 Nokia Corporation
*
@@ -33,7 +33,8 @@
#define RETU_REG_ASICR 0x00/* ASIC ID and revision */
#define RETU_REG_ASICR_VILMA (1 7)/* Bit indicating Vilma */
#define RETU_REG_IDR 0x01/* Interrupt ID */
-#define RETU_REG_IMR 0x02/* Interrupt mask */
+#define RETU_REG_IMR 0x02/* Interrupt mask (Retu) */
+#define TAHVO_REG_IMR 0x03/* Interrupt mask (Tahvo) */
/* Interrupt sources */
#define RETU_INT_PWR 0 /* Power button */
@@ -84,6 +85,62 @@ static struct regmap_irq_chip retu_irq_chip = {
/* Retu device registered for the power off. */
static struct retu_dev *retu_pm_power_off;
+static struct resource tahvo_usb_res[] = {
+ {
+ .name = tahvo-usb,
+ .start = TAHVO_INT_VBUS,
+ .end= TAHVO_INT_VBUS,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct mfd_cell tahvo_devs[] = {
+ {
+ .name = tahvo-usb,
+ .resources = tahvo_usb_res,
+ .num_resources = ARRAY_SIZE(tahvo_usb_res),
+ },
+};
+
+static struct regmap_irq tahvo_irqs[] = {
+ [TAHVO_INT_VBUS] = {
+ .mask = 1 TAHVO_INT_VBUS,
+ }
+};
+
+static struct regmap_irq_chip tahvo_irq_chip = {
+ .name = TAHVO,
+ .irqs = tahvo_irqs,
+ .num_irqs = ARRAY_SIZE(tahvo_irqs),
+ .num_regs = 1,
+ .status_base= RETU_REG_IDR,
+ .mask_base = TAHVO_REG_IMR,
+ .ack_base = RETU_REG_IDR,
+};
+
+static const struct retu_data {
+ char*chip_name;
+ char*companion_name;
+ struct regmap_irq_chip *irq_chip;
+ struct mfd_cell *children;
+ int nchildren;
+} retu_data[] = {
+ [0] = {
+ .chip_name = Retu,
+ .companion_name = Vilma,
+ .irq_chip = retu_irq_chip,
+ .children = retu_devs,
+ .nchildren = ARRAY_SIZE(retu_devs),
+ },
+ [1] = {
+ .chip_name = Tahvo,
+ .companion_name = Betty,
+ .irq_chip = tahvo_irq_chip,
+ .children = tahvo_devs,
+ .nchildren = ARRAY_SIZE(tahvo_devs),
+ }
+};
+
int retu_read(struct retu_dev *rdev, u8 reg)
{
int ret;
@@ -173,9 +230,14 @@ static struct regmap_config retu_config = {
static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id)
{
+ struct retu_data const *rdat;
struct retu_dev *rdev;
int ret;
+ if (i2c-addr ARRAY_SIZE(retu_data))
+ return -ENODEV;
+ rdat = retu_data[i2c-addr - 1];
+
rdev = devm_kzalloc(i2c-dev, sizeof(*rdev), GFP_KERNEL);
if (rdev == NULL)
return -ENOMEM;
@@ -190,25 +252,27 @@ static int retu_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
ret = retu_read(rdev, RETU_REG_ASICR);
if (ret 0) {
- dev_err(rdev-dev, could not read Retu revision: %d\n, ret);
+ dev_err(rdev-dev, could not read %s revision: %d\n,
+ rdat-chip_name, ret);
return ret;
}
- dev_info(rdev-dev, Retu%s v%d.%d found\n,
-(ret RETU_REG_ASICR_VILMA) ? Vilma : ,
+
[RFC PATCH v2 4/4] USB: OMAP: Tahvo USB transceiver driver
Add Tahvo USB transceiver driver.
Based on old code from linux-omap tree. The original driver was written
by Juha Yrjölä, Tony Lindgren, and Timo Teräs.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/usb/phy/Kconfig | 14 ++
drivers/usb/phy/Makefile|1 +
drivers/usb/phy/phy-tahvo.c | 429 +++
3 files changed, 444 insertions(+)
create mode 100644 drivers/usb/phy/phy-tahvo.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 8c051c2..85b2e2c 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -145,6 +145,20 @@ config OMAP_OTG
This driver can also be built as a module. If so, the module
will be called omap-otg.
+config TAHVO_USB
+ tristate Tahvo USB transceiver driver
+ depends on MFD_RETU OMAP_OTG
+ help
+ Enable this to support USB transceiver on Tahvo. This is used
+ at least on Nokia 770.
+
+config TAHVO_USB_HOST_BY_DEFAULT
+ depends on TAHVO_USB
+ boolean Device in USB host mode by default
+ help
+ Say Y here, if you want the device to enter USB host mode
+ by default on bootup.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 7e67e96..c6079ff 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -13,6 +13,7 @@ phy-fsl-usb2-objs := phy-fsl-usb.o
phy-fsm-usb.o
obj-$(CONFIG_FSL_USB2_OTG) += phy-fsl-usb2.o
obj-$(CONFIG_ISP1301_OMAP) += phy-isp1301.omap.o
obj-$(CONFIG_MV_U3D_PHY) += phy-mv-u3d-usb.o
+obj-$(CONFIG_TAHVO_USB)+= phy-tahvo.o
obj-$(CONFIG_NOP_USB_XCEIV)+= phy-nop.o
obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
new file mode 100644
index 000..51bc40e
--- /dev/null
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -0,0 +1,429 @@
+/*
+ * Tahvo USB transceiver driver
+ *
+ * Copyright (C) 2005-2006 Nokia Corporation
+ *
+ * Parts copied from isp1301_omap.c.
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2004 David Brownell
+ *
+ * Original driver written by Juha Yrjölä, Tony Lindgren and Timo Teräs.
+ * Modified for Retu/Tahvo MFD by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/io.h
+#include linux/clk.h
+#include linux/usb.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb/otg.h
+#include linux/mfd/retu.h
+#include linux/usb/gadget.h
+#include linux/usb/omap-otg.h
+#include linux/platform_device.h
+
+#define DRIVER_NAME tahvo-usb
+
+#define TAHVO_REG_IDSR 0x02
+#define TAHVO_REG_USBR 0x06
+
+#define USBR_SLAVE_CONTROL (1 8)
+#define USBR_VPPVIO_SW (1 7)
+#define USBR_SPEED (1 6)
+#define USBR_REGOUT(1 5)
+#define USBR_MASTER_SW2(1 4)
+#define USBR_MASTER_SW1(1 3)
+#define USBR_SLAVE_SW (1 2)
+#define USBR_NSUSPEND (1 1)
+#define USBR_SEMODE(1 0)
+
+#define TAHVO_MODE_HOST0
+#define TAHVO_MODE_PERIPHERAL 1
+
+struct tahvo_usb {
+ struct platform_device *pt_dev;
+ struct usb_phy phy;
+ int vbus_state;
+ struct mutexserialize;
+ struct clk *ick;
+ int irq;
+ int tahvo_mode;
+};
+
+static ssize_t vbus_state_show(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct tahvo_usb *tu = dev_get_drvdata(device);
+ return sprintf(buf, %d\n, tu-vbus_state);
+}
+static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, NULL);
+
+static void check_vbus_state(struct tahvo_usb *tu)
+{
+ struct retu_dev *rdev = dev_get_drvdata(tu-pt_dev-dev.parent);
+ int reg, prev_state;
+
+ reg = retu_read(rdev, TAHVO_REG_IDSR);
+ if (reg TAHVO_STAT_VBUS) {
+ switch (tu-phy.state) {
+ case OTG_STATE_B_IDLE:
+ /* Enable the gadget driver */
+ if (tu-phy.otg-gadget)
+ usb_gadget_vbus_connect(tu-phy.otg-gadget);
+ omap_otg_set_mode(OMAP_OTG_MODE_DEVICE);
+ tu-phy.state = OTG_STATE_B_PERIPHERAL;
+
[RFC PATCH v2 3/4] USB: OMAP: add omap-otg
Transceivers need to manage OTG controller state on OMAP1 to enable
switching between peripheral and host modes. Provide a driver for that.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/usb/phy/Kconfig| 10
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/phy-omap-otg.c | 126
include/linux/usb/omap-otg.h | 19 ++
4 files changed, 156 insertions(+)
create mode 100644 drivers/usb/phy/phy-omap-otg.c
create mode 100644 include/linux/usb/omap-otg.h
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 372db48..8c051c2 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -135,6 +135,16 @@ config USB_GPIO_VBUS
optionally control of a D+ pullup GPIO as well as a VBUS
current limit regulator.
+config OMAP_OTG
+ tristate OMAP USB OTG controller driver
+ depends on ARCH_OMAP_OTG
+ help
+ Enable this to support some transceivers on OMAP1 platforms. OTG
+ controller is needed to switch between host and peripheral modes.
+
+ This driver can also be built as a module. If so, the module
+ will be called omap-otg.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..7e67e96 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ISP1301_OMAP)+= phy-isp1301.omap.o
obj-$(CONFIG_MV_U3D_PHY) += phy-mv-u3d-usb.o
obj-$(CONFIG_NOP_USB_XCEIV)+= phy-nop.o
obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
+obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_OMAP_USB3)+= phy-omap-usb3.o
obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
new file mode 100644
index 000..cb00ffe
--- /dev/null
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -0,0 +1,126 @@
+/*
+ * OMAP OTG controller driver
+ *
+ * Based on code from tahvo-usb.c and isp1301_omap.c drivers.
+ *
+ * Copyright (C) 2005-2006 Nokia Corporation
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2004 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/io.h
+#include linux/err.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/usb/omap-otg.h
+#include linux/platform_device.h
+
+struct otg_device {
+ void __iomem*base;
+ struct mutexserialize;
+};
+static struct otg_device *otg_dev;
+
+#define OMAP_OTG_CTRL (otg_dev-base + 0x0c)
+#define OMAP_OTG_ASESSVLD (1 20)
+#define OMAP_OTG_BSESSEND (1 19)
+#define OMAP_OTG_BSESSVLD (1 18)
+#define OMAP_OTG_VBUSVLD (1 17)
+#define OMAP_OTG_ID(1 16)
+#define OMAP_OTG_XCEIV_OUTPUTS \
+ (OMAP_OTG_ASESSVLD | OMAP_OTG_BSESSEND | OMAP_OTG_BSESSVLD | \
+OMAP_OTG_VBUSVLD | OMAP_OTG_ID)
+
+static void omap_otg_ctrl(u32 outputs)
+{
+ u32 l;
+
+ l = readl(OMAP_OTG_CTRL);
+ l = ~OMAP_OTG_XCEIV_OUTPUTS;
+ l |= outputs;
+ writel(l, OMAP_OTG_CTRL);
+}
+
+void omap_otg_set_mode(enum omap_otg_mode mode)
+{
+ if (!otg_dev) {
+ WARN(1, %s: controller not present\n, __func__);
+ return;
+ }
+ mutex_lock(otg_dev-serialize);
+ switch (mode) {
+ case OMAP_OTG_MODE_DEVICE:
+ /*
+* Set B-session valid.
+*/
+ omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSVLD);
+ break;
+ case OMAP_OTG_MODE_HOST:
+ /*
+* Set A-session valid.
+*/
+ omap_otg_ctrl(OMAP_OTG_ASESSVLD);
+ break;
+ case OMAP_OTG_MODE_DISCONNECT:
+ /*
+* Set B-session end to indicate no VBUS.
+*/
+ omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSEND);
+ break;
+ default:
+ WARN(1, %s: unknown mode: %d\n, __func__, mode);
+ }
+ mutex_unlock(otg_dev-serialize);
+}
+EXPORT_SYMBOL_GPL(omap_otg_set_mode);
+
+static int omap_otg_probe(struct platform_device *dev)
+{
+ struct otg_device *odev;
+ u32 rev;
+
+ if (otg_dev)
+
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 10:43-20130409, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130409 09:54]:
* Roger Quadros rog...@ti.com [130409 03:00]:
On 04/05/2013 06:58 PM, Tony Lindgren wrote:
Can't you just use the clock name there to get it?
In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.
e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.
Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.
As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.
Then other features can be added later on like to allocate a
clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [PATCH] OMAP: add devicetree support for clock nodes.
Dummy patch based on Roger's original idea
Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi |2 +
arch/arm/mach-omap2/cclock3xxx_data.c |3 +-
arch/arm/mach-omap2/cclock44xx_data.c |3 +-
arch/arm/mach-omap2/pm.c | 11 +++-
drivers/clk/Kconfig |6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 100 +
include/linux/clk/ti.h| 30 ++
9 files changed, 157 insertions(+), 5 deletions(-)
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..a08990d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
ti,hwmods = counter_32k;
};
+ clks: clocks {
+ compatible = ti,clock;
+ #clock-cells = 1;
+ };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 75ed4ae..93c2621 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
60 135
;
clock-latency = 30; /* From legacy driver */
+ clocks = clks 249; /* index to cpufreq_ck */
+ clock-names = cpu;
};
};
};
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..d5d5ef5 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
#include linux/clk-private.h
#include linux/list.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
for (c = omap3xxx_clks; c omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
c++)
if (c-cpu cpu_clkflg) {
- clkdev_add(c-lk);
+ ti_clk_node_add(c-lk);
if (!__clk_init(NULL, c-lk.clk))
omap2_init_clk_hw_omap_clocks(c-lk.clk);
}
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 0c6834a..338ef64 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -1697,7 +1698,7 @@ int __init omap4xxx_clk_init(void)
for (c = omap44xx_clks; c omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
c++) {
if (c-cpu cpu_clkflg
USB storage disconnects on xHCI only with Renesas host and ASMedia enclosure
Hi, For some time now (at least since 3.0) I have been having issues with an USB3 to Sata enclosure and xHCI. The device (174c:55aa ASMedia Technology Inc) works perfectly fine on USB2 ports in Linux, as well as on the NEC/Renesas uPD720200(A) USB3 controller in Windows, but not so on any Linux kernels that I've tried (all mainline). Today I've built 3.8.6, enabled debugging and usbmon, and I've captured lspci, lsusb, dmesg and usbmon (both text and wireshark) data here: http://dx.infernix.net/renesas/ Device insertion happens around the 21:50:15 mark, and isn't removed during the logs. Some excerpts in no specific order: Apr 9 21:50:16 believe kernel: sd 7:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB) .. Apr 9 21:50:16 believe kernel: xhci_hcd :07:00.0: WARN halted endpoint, queueing URB anyway. .. Apr 9 21:50:59 believe kernel: xhci_hcd :07:00.0: Stalled endpoint .. Apr 9 21:51:30 believe udevd[23487]: timeout: killing '/sbin/blkid -o udev -p /dev/sdc' [23924] .. Apr 9 21:52:52 believe kernel: usb 4-2: device not accepting address 6, error -22 .. Apr 9 21:52:54 believe kernel: hub 4-0:1.0: logical disconnect on port 2 .. Apr 9 21:52:54 believe kernel: usb-storage: usb_stor_post_reset It constantly cycles into resets. From time to time in previous kernels I was able to mount it and copy some data, but after seconds of copying data it would reset and it would lose the SCSI device. With 3.8.6 I can't even do an fdisk -l /dev/sdc because it will just reset before that even happens. Plug it into an USB2 port and all is well with the world. Boot to Windows on USB3 and I can copy data with 100MByte/s to and from it. Is this device not working properly in Linux due to lack of vendor documentation for the USB3 controller, or is something else going on here? Could someone please shed some light on this? Thanks! -- 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 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 15:49-20130409, Nishanth Menon wrote:
On 10:43-20130409, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130409 09:54]:
* Roger Quadros rog...@ti.com [130409 03:00]:
On 04/05/2013 06:58 PM, Tony Lindgren wrote:
Can't you just use the clock name there to get it?
In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.
e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.
Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.
As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.
Then other features can be added later on like to allocate a
clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
Approach #2:
Here is yet another revision - here I am trying to avoid the risk of
folks messing up indexing. for example: using an older DTB with newer
kernel, clocks being inserted into existing list etc. to prevent these,
we add an DT_ID for omap clock nodes, and use it to uniquely identify
the clock node. We try to minimize(not avoidable with integer indexing)
mistakes during development/productization.
From 2b576affdc6f6bf0b51ebf9b85ef4319357a7994 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [RFC PATCH V2] OMAP: add devicetree support for clock nodes.(rev 2)
Dummy patch based on Roger's original idea
this time have lesser possibiltiy of screwing up indices. instead
use a specific integer ID to uniquely (TI SoC wide) identify an clock.
on the flip side, we do not all make clock nodes to be accesible from DT
clock indexing.
Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/clock/ti,clock.txt | 48 +++
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi|2 +
arch/arm/boot/dts/omap4.dtsi |5 ++
arch/arm/boot/dts/omap443x.dtsi|2 +
arch/arm/mach-omap2/cclock3xxx_data.c |5 +-
arch/arm/mach-omap2/cclock44xx_data.c |5 +-
arch/arm/mach-omap2/clock.h| 12 +++
arch/arm/mach-omap2/pm.c | 11 ++-
drivers/clk/Kconfig|6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 85
include/linux/clk/ti.h | 30 +++
13 files changed, 211 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti,clock.txt
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/Documentation/devicetree/bindings/clock/ti,clock.txt
b/Documentation/devicetree/bindings/clock/ti,clock.txt
new file mode 100644
index 000..53c947c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,clock.txt
@@ -0,0 +1,48 @@
+* Clock bindings for Texas Instruments clocks
+
+Required properties:
+- compatible: Should be ti,clock
+- #clock-cells: Should be 1
+
+The clock consumer should specify the desired clock by having the clock
+ID in its clocks phandle cell. The following is a list of ID reservations
+across TI SoCs
+
+ Clock ID
+ --
+ cpu clock 1
+
+The definition is used by SoC clock data using CLKDT() macro
+(example of OMAP2+).
+
+Example Steps:
+/* step 1: definiting an SoC nodes compatible with ti clocks -skip if already
done */
+clks: clocks {
+ compatible = ti,clock;
+ #clock-cells = 1;
+};
+
+/* step 2: Modify the bindings documentation to reserve an ID */
+ auxclk0_ck 2
+ auxclk1_ck 3
+ auxclk2_ck 4
+ auxclk3_ck 5
+ auxclk4_ck 6
+ auxclk5_ck 7
+etc. use an unique number not conflicting with previous reservations.
+WARNING: DONOT insert values - this breaks backward compatibility.
+/* Step 3: replace in clock data file
Re: USB to SPI driver for MCP2210
On 04/09/2013 02:06 PM, Robert Schwebel wrote: On Tue, Apr 09, 2013 at 02:00:46PM -0500, Daniel Santos wrote: Well, we don't have the $3500 for a vendor id. :( I presume that others may do the same thing, hopefully mostly with DIY-type of projects. Do you know this one: http://wiki.openmoko.org/wiki/USB_Product_IDs#USB_Vendor_and_Product_IDs rsc ooh, shiny! Thanks Robert! Daniel -- 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/9] Reorganize R8A7779/Marzen USB code
Hello. Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130410' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data I'm not sure thru which tree this patchset should be merged, however it turns out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10 (which would have been most convenient probably), and it's probably too late to merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11, unfortunately... 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
[PATCH v3 1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
USB EHCI, OHCI, and common PHY are the SoC devices but are wrongly defined and
registered in the Marzen board file. Move the data and code to their proper
place in setup-r8a7779.c; while at it, we have to rename 8a7779_late_devices[]
to 8a7779_standard_devices[] -- this seems legitimate since they are registered
from r8a7779_add_standard_devices() anyway.
Note that I'm deliberately changing the USB PHY platform device's 'id' field
from (previously just omitted) 0 to -1 as the device is a single of its kind.
Note also that the board and SoC code have to be in one patch to keep the code
bisectable...
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- added a note about bisectability to the changelog.
arch/arm/mach-shmobile/board-marzen.c | 178 -
arch/arm/mach-shmobile/include/mach/r8a7779.h |1
arch/arm/mach-shmobile/setup-r8a7779.c| 185 +-
3 files changed, 184 insertions(+), 180 deletions(-)
Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -36,10 +36,6 @@
#include linux/mmc/host.h
#include linux/mmc/sh_mobile_sdhi.h
#include linux/mfd/tmio.h
-#include linux/usb/otg.h
-#include linux/usb/ehci_pdriver.h
-#include linux/usb/ohci_pdriver.h
-#include linux/pm_runtime.h
#include mach/hardware.h
#include mach/r8a7779.h
#include mach/common.h
@@ -149,26 +145,6 @@ static struct platform_device hspi_devic
.num_resources = ARRAY_SIZE(hspi_resources),
};
-/* USB PHY */
-static struct resource usb_phy_resources[] = {
- [0] = {
- .start = 0xffe7,
- .end= 0xffe70900 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = 0xfff7,
- .end= 0xfff70900 - 1,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device usb_phy_device = {
- .name = rcar_usb_phy,
- .resource = usb_phy_resources,
- .num_resources = ARRAY_SIZE(usb_phy_resources),
-};
-
/* LEDS */
static struct gpio_led marzen_leds[] = {
{
@@ -204,161 +180,9 @@ static struct platform_device *marzen_de
sdhi0_device,
thermal_device,
hspi_device,
- usb_phy_device,
leds_device,
};
-/* USB */
-static struct usb_phy *phy;
-static int usb_power_on(struct platform_device *pdev)
-{
- if (!phy)
- return -EIO;
-
- pm_runtime_enable(pdev-dev);
- pm_runtime_get_sync(pdev-dev);
-
- usb_phy_init(phy);
-
- return 0;
-}
-
-static void usb_power_off(struct platform_device *pdev)
-{
- if (!phy)
- return;
-
- usb_phy_shutdown(phy);
-
- pm_runtime_put_sync(pdev-dev);
- pm_runtime_disable(pdev-dev);
-}
-
-static struct usb_ehci_pdata ehcix_pdata = {
- .power_on = usb_power_on,
- .power_off = usb_power_off,
- .power_suspend = usb_power_off,
-};
-
-static struct resource ehci0_resources[] = {
- [0] = {
- .start = 0xffe7,
- .end= 0xffe70400 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = gic_iid(0x4c),
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device ehci0_device = {
- .name = ehci-platform,
- .id = 0,
- .dev= {
- .dma_mask = ehci0_device.dev.coherent_dma_mask,
- .coherent_dma_mask = 0x,
- .platform_data = ehcix_pdata,
- },
- .num_resources = ARRAY_SIZE(ehci0_resources),
- .resource = ehci0_resources,
-};
-
-static struct resource ehci1_resources[] = {
- [0] = {
- .start = 0xfff7,
- .end= 0xfff70400 - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = gic_iid(0x4d),
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device ehci1_device = {
- .name = ehci-platform,
- .id = 1,
- .dev= {
- .dma_mask = ehci1_device.dev.coherent_dma_mask,
- .coherent_dma_mask = 0x,
- .platform_data = ehcix_pdata,
- },
- .num_resources = ARRAY_SIZE(ehci1_resources),
- .resource = ehci1_resources,
-};
-
-static struct
[PATCH v3 2/9] ehci-platform: add pre_setup() method to platform data
Sometimes there is a need to initialize some non-standard registers mapped to
the EHCI region before accessing the standard EHCI registers. Add pre_setup()
method with 'struct usb_hcd *' parameter to be called just before ehci_setup()
to the 'ehci-platform' driver's platform data for this purpose...
While at it, add the missing incomplete declaration of 'struct platform_device'
to linux/usb/ehci_pdriver.h...
The patch has been tested on the Marzen and BOCK-W boards.
Suggested-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- replaced #include with incomplete declarations of 'struct platform_device' and
'struct usb_hcd';
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- changed init() method to pre_setup() with different parameters and call site.
drivers/usb/host/ehci-platform.c |6 ++
include/linux/usb/ehci_pdriver.h |4
2 files changed, 10 insertions(+)
Index: renesas/drivers/usb/host/ehci-platform.c
===
--- renesas.orig/drivers/usb/host/ehci-platform.c
+++ renesas/drivers/usb/host/ehci-platform.c
@@ -46,6 +46,12 @@ static int ehci_platform_reset(struct us
ehci-big_endian_desc = pdata-big_endian_desc;
ehci-big_endian_mmio = pdata-big_endian_mmio;
+ if (pdata-pre_setup) {
+ retval = pdata-pre_setup(hcd);
+ if (retval 0)
+ return retval;
+ }
+
ehci-caps = hcd-regs + pdata-caps_offset;
retval = ehci_setup(hcd);
if (retval)
Index: renesas/include/linux/usb/ehci_pdriver.h
===
--- renesas.orig/include/linux/usb/ehci_pdriver.h
+++ renesas/include/linux/usb/ehci_pdriver.h
@@ -19,6 +19,9 @@
#ifndef __USB_CORE_EHCI_PDRIVER_H
#define __USB_CORE_EHCI_PDRIVER_H
+struct platform_device;
+struct usb_hcd;
+
/**
* struct usb_ehci_pdata - platform_data for generic ehci driver
*
@@ -50,6 +53,7 @@ struct usb_ehci_pdata {
/* Turn on only VBUS suspend power and hotplug detection,
* turn off everything else */
void (*power_suspend)(struct platform_device *pdev);
+ int (*pre_setup)(struct usb_hcd *hcd);
};
#endif /* __USB_CORE_EHCI_PDRIVER_H */
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer
Setup the EHCI internal buffer (before EHCI driver has a chance to touch the
registers) using the pre_setup() method in 'struct usb_ehci_pdata'.
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- added #include linux/usb/hcd.h;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- changed from init() platform device method to pre_setup() as per the previous
patch.
arch/arm/mach-shmobile/setup-r8a7779.c | 16
1 file changed, 16 insertions(+)
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -33,6 +33,7 @@
#include linux/sh_timer.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
+#include linux/usb/hcd.h
#include linux/usb/ehci_pdriver.h
#include linux/usb/ohci_pdriver.h
#include linux/pm_runtime.h
@@ -446,10 +447,25 @@ static void usb_power_off(struct platfor
pm_runtime_disable(pdev-dev);
}
+static int ehci_init_internal_buffer(struct usb_hcd *hcd)
+{
+ /*
+* Below are recommended values from the datasheet;
+* see [USB :: Setting of EHCI Internal Buffer].
+*/
+ /* EHCI IP internal buffer setting */
+ iowrite32(0x00ff0040, hcd-regs + 0x0094);
+ /* EHCI IP internal buffer enable */
+ iowrite32(0x0001, hcd-regs + 0x009C);
+
+ return 0;
+}
+
static struct usb_ehci_pdata ehcix_pdata = {
.power_on = usb_power_on,
.power_off = usb_power_off,
.power_suspend = usb_power_off,
+ .pre_setup = ehci_init_internal_buffer,
};
static struct resource ehci0_resources[] = {
--
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/9] rcar-phy: remove EHCI internal buffer setup
Now that the EHCI internal buffer setup is done by the platform code, we can
remove such code from this driver as it never really belonged here. We also
no longer need the 2nd memory region now (2nd EHCI controller is simply missing
in e.g. R8A7778 SoC).
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- split R8A7779 SoC file change to a separate patch.
drivers/usb/phy/rcar-phy.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -23,8 +23,6 @@
#define USBEH0 0x080C
#define USBOH0 0x081C
#define USBCTL00x0858
-#define EIIBC1 0x0094
-#define EIIBC2 0x009C
/* USBPCTRL1 */
#define PHY_RST(1 2)
@@ -40,7 +38,6 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
void __iomem *reg0;
- void __iomem *reg1;
int counter;
};
@@ -59,7 +56,6 @@ static int rcar_usb_phy_init(struct usb_
struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
struct device *dev = phy-dev;
void __iomem *reg0 = priv-reg0;
- void __iomem *reg1 = priv-reg1;
int i;
u32 val;
unsigned long flags;
@@ -97,19 +93,6 @@ static int rcar_usb_phy_init(struct usb_
iowrite32(0x, (reg0 + USBPCTRL0));
/*
-* EHCI IP internal buffer setting
-* EHCI IP internal buffer enable
-*
-* These are recommended value of a datasheet
-* see [USB :: EHCI internal buffer setting]
-*/
- iowrite32(0x00ff0040, (reg0 + EIIBC1));
- iowrite32(0x00ff0040, (reg1 + EIIBC1));
-
- iowrite32(0x0001, (reg0 + EIIBC2));
- iowrite32(0x0001, (reg1 + EIIBC2));
-
- /*
* Bus alignment settings
*/
@@ -145,14 +128,13 @@ static void rcar_usb_phy_shutdown(struct
static int rcar_usb_phy_probe(struct platform_device *pdev)
{
struct rcar_usb_phy_priv *priv;
- struct resource *res0, *res1;
+ struct resource *res0;
struct device *dev = pdev-dev;
- void __iomem *reg0, *reg1;
+ void __iomem *reg0;
int ret;
res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!res0 || !res1) {
+ if (!res0) {
dev_err(dev, Not enough platform resources\n);
return -EINVAL;
}
@@ -164,8 +146,7 @@ static int rcar_usb_phy_probe(struct pla
* this driver can't use devm_request_and_ioremap(dev, res) here
*/
reg0 = devm_ioremap_nocache(dev, res0-start, resource_size(res0));
- reg1 = devm_ioremap_nocache(dev, res1-start, resource_size(res1));
- if (!reg0 || !reg1) {
+ if (!reg0) {
dev_err(dev, ioremap error\n);
return -ENOMEM;
}
@@ -177,7 +158,6 @@ static int rcar_usb_phy_probe(struct pla
}
priv-reg0 = reg0;
- priv-reg1 = reg1;
priv-counter = 0;
priv-phy.dev = dev;
priv-phy.label = dev_name(dev);
--
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 5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource
Now that 'drivers/usb/phy/rcar-phy.c' doesn't require the second memory resource
anymore, we can remove it from the R8A7779's USB PHY platform device.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- new patch in this version, split from the previous one.
arch/arm/mach-shmobile/setup-r8a7779.c |5 -
1 file changed, 5 deletions(-)
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -406,11 +406,6 @@ static struct resource usb_phy_resources
.end= 0xffe70900 - 1,
.flags = IORESOURCE_MEM,
},
- [1] = {
- .start = 0xfff7,
- .end= 0xfff70900 - 1,
- .flags = IORESOURCE_MEM,
- },
};
static struct platform_device usb_phy_device = {
--
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/9] rcar-phy: correct base address
The memory region that is used by the driver overlaps EHCI and OHCI register
regions for absolutely no reason now -- fix it by adding offset of 0x800 to
the base address, changing the register #define's accordingly. This has extra
positive effect that we now can use devm_ioremap_resource()...
Note that the driver and the SoC code have to be in one patch to keep the code
bisectable...
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- added a note about bisectability to the changelog.
arch/arm/mach-shmobile/setup-r8a7779.c |2 +-
drivers/usb/phy/rcar-phy.c | 28 ++--
2 files changed, 11 insertions(+), 19 deletions(-)
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -402,7 +402,7 @@ static struct platform_device sata_devic
/* USB PHY */
static struct resource usb_phy_resources[] = {
[0] = {
- .start = 0xffe7,
+ .start = 0xffe70800,
.end= 0xffe70900 - 1,
.flags = IORESOURCE_MEM,
},
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -16,13 +16,13 @@
#include linux/spinlock.h
#include linux/module.h
-/* USBH common register */
-#define USBPCTRL0 0x0800
-#define USBPCTRL1 0x0804
-#define USBST 0x0808
-#define USBEH0 0x080C
-#define USBOH0 0x081C
-#define USBCTL00x0858
+/* REGS block */
+#define USBPCTRL0 0x00
+#define USBPCTRL1 0x04
+#define USBST 0x08
+#define USBEH0 0x0C
+#define USBOH0 0x1C
+#define USBCTL00x58
/* USBPCTRL1 */
#define PHY_RST(1 2)
@@ -139,17 +139,9 @@ static int rcar_usb_phy_probe(struct pla
return -EINVAL;
}
- /*
-* CAUTION
-*
-* Because this phy address is also mapped under OHCI/EHCI address area,
-* this driver can't use devm_request_and_ioremap(dev, res) here
-*/
- reg0 = devm_ioremap_nocache(dev, res0-start, resource_size(res0));
- if (!reg0) {
- dev_err(dev, ioremap error\n);
- return -ENOMEM;
- }
+ reg0 = devm_ioremap_resource(dev, res0);
+ if (IS_ERR(reg0))
+ return PTR_ERR(reg0);
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
--
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 7/9] rcar-phy: add platform data
Currently the driver hard-codes USBPCTRL0 register to 0. It is wrong since this
register contains board-specific USB ports configuration and so its value should
be somehow passed via the platform data. Add linux/usb/rcar-phy.h file with
the USBPCTRL0 bit #define's and 'struct rcar_phy_platform_data' containing the
value to be set by the driver to that register.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- added #include linux/types.h;
- added ACKs from Simon Horman and Kuninori Morimoto.
include/linux/usb/rcar-phy.h | 40
1 file changed, 40 insertions(+)
Index: renesas/include/linux/usb/rcar-phy.h
===
--- /dev/null
+++ renesas/include/linux/usb/rcar-phy.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Cogent Embedded, 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.
+ */
+
+#ifndef __RCAR_PHY_H
+#define __RCAR_PHY_H
+
+#include linux/bitops.h
+#include linux/types.h
+
+/* USBPCTRL0 register bits */
+#define USBPCTRL0_OVC2 BIT(10) /* Switches the OVC input pin for port 2: */
+ /* 1: USB_OVC2, 0: OVC2 */
+#define USBPCTRL0_OVC1_VBUS1 BIT(9) /* Switches the OVC input pin for port 1:
*/
+ /* 1: USB_OVC1, 0: OVC1/VBUS1 */
+#define USBPCTRL0_OVC0 BIT(8) /* Switches the OVC input pin for port 0: */
+ /* 1: USB_OVC0 pin, 0: OVC0 */
+#define USBPCTRL0_OVC2_ACT BIT(6) /* Host mode: OVC2 polarity: */
+ /* 1: active-high, 0: active-low*/
+ /* Function mode: be sure to set to 1 */
+#define USBPCTRL0_PENC BIT(4) /* Function mode: output level of PENC1 pin: */
+ /* 1: high, 0: low */
+#define USBPCTRL0_OVC0_ACT BIT(3) /* Host mode: OVC0 polarity: */
+ /* 1: active-high, 0: active-low*/
+#define USBPCTRL0_OVC1_ACT BIT(1) /* Host mode: OVC1 polarity: */
+ /* 1: active-high, 0: active-low*/
+ /* Function mode: be sure to set to 1 */
+#define USBPCTRL0_PORT1BIT(0) /* Selects port 1 mode:
*/
+ /* 1: function, 0: host */
+
+struct rcar_phy_platform_data {
+ u32 usbpctrl0; /* USBPCTRL0 register value */
+};
+
+#endif /* __RCAR_PHY_H */
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device
Since we're now going to setup the USBPCTRL0 register using the USB PHY device's
platform data, we now need a way to pass those platform data from the board file
to the device which is situated in setup-r8a7779.c -- and what I'm suggesting is
r8a7779_add_usb_phy_device() that will register USB PHY platform device with the
passed platform data using platform_device_register_resndata() call; creating
this function envolves deletion of 'usb_phy_device' from r8a7779_devices_dt[],
so that it will no longer be registered for the generic R8A7779 machine (where
we can't provide the platform data anyway), hence EHCI/OHCI drivers will fail
to load as well.
For the Marzen board, this new function will be called from marzen_init() to
register the USB PHY device early enough.
Note that the board and the SoC code have to be in one patch to keep the code
bisectable...
The patch has been tested on the Marzen board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- refreshed atop of the prior patches;
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
Changes since the original posting:
- added a note about bisectability to the changelog.
arch/arm/mach-shmobile/board-marzen.c |5 +
arch/arm/mach-shmobile/include/mach/r8a7779.h |2 ++
arch/arm/mach-shmobile/setup-r8a7779.c| 16
3 files changed, 15 insertions(+), 8 deletions(-)
Index: renesas/arch/arm/mach-shmobile/board-marzen.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-marzen.c
+++ renesas/arch/arm/mach-shmobile/board-marzen.c
@@ -56,6 +56,10 @@ static struct regulator_consumer_supply
REGULATOR_SUPPLY(vdd33a, smsc911x),
};
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+ .usbpctrl0 = 0,
+};
+
/* SMSC LAN89218 */
static struct resource smsc911x_resources[] = {
[0] = {
@@ -230,6 +234,7 @@ static void __init marzen_init(void)
r8a7779_pinmux_init();
r8a7779_add_standard_devices();
+ r8a7779_add_usb_phy_device(usb_phy_platform_data);
platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
}
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -4,6 +4,7 @@
#include linux/sh_clk.h
#include linux/pm_domain.h
#include linux/sh_eth.h
+#include linux/usb/rcar-phy.h
struct platform_device;
@@ -33,6 +34,7 @@ extern void r8a7779_add_early_devices(vo
extern void r8a7779_add_standard_devices(void);
extern void r8a7779_add_standard_devices_dt(void);
extern void r8a7779_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
extern void r8a7779_init_late(void);
extern void r8a7779_clock_init(void);
extern void r8a7779_pinmux_init(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -408,13 +408,6 @@ static struct resource usb_phy_resources
},
};
-static struct platform_device usb_phy_device = {
- .name = rcar_usb_phy,
- .id = -1,
- .resource = usb_phy_resources,
- .num_resources = ARRAY_SIZE(usb_phy_resources),
-};
-
/* USB */
static struct usb_phy *phy;
@@ -586,7 +579,6 @@ static struct platform_device *r8a7779_d
scif5_device,
tmu00_device,
tmu01_device,
- usb_phy_device,
};
static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -621,6 +613,14 @@ void __init r8a7779_add_ether_device(str
pdata, sizeof(*pdata));
}
+void __init r8a7779_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+ platform_device_register_resndata(platform_bus, rcar_usb_phy, -1,
+ usb_phy_resources,
+ ARRAY_SIZE(usb_phy_resources),
+ pdata, sizeof(*pdata));
+}
+
/* do nothing for !CONFIG_SMP or !CONFIG_HAVE_TWD */
void __init __weak r8a7779_register_twd(void) { }
--
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 9/9] rcar-phy: handle platform data
Set the USBPCTRL0 register from the passed platform data in rcar_usb_phy_init();
don't reset it to 0 in rcar_usb_phy_shutdown() anymore as that does not make
sense. Also, don't allow the driver's probe to succeed when the platform data
are not supplied with a device.
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Acked-by: Simon Horman horms+rene...@verge.net.au
---
Changes since version 2:
- added a note about testing to the changelog;
- added ACKs from Simon Horman and Kuninori Morimoto.
drivers/usb/phy/rcar-phy.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -1,8 +1,9 @@
/*
* Renesas R-Car USB phy driver
*
- * Copyright (C) 2012 Renesas Solutions Corp.
+ * Copyright (C) 2012-2013 Renesas Solutions Corp.
* Kuninori Morimoto kuninori.morimoto...@renesas.com
+ * Copyright (C) 2013 Cogent Embedded, 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
@@ -11,10 +12,11 @@
#include linux/delay.h
#include linux/io.h
-#include linux/usb/otg.h
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/module.h
+#include linux/usb/otg.h
+#include linux/usb/rcar-phy.h
/* REGS block */
#define USBPCTRL0 0x00
@@ -55,6 +57,7 @@ static int rcar_usb_phy_init(struct usb_
{
struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
struct device *dev = phy-dev;
+ struct rcar_phy_platform_data *pdata = dev-platform_data;
void __iomem *reg0 = priv-reg0;
int i;
u32 val;
@@ -90,7 +93,7 @@ static int rcar_usb_phy_init(struct usb_
iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1));
/* set platform specific port settings */
- iowrite32(0x, (reg0 + USBPCTRL0));
+ iowrite32(pdata-usbpctrl0, (reg0 + USBPCTRL0));
/*
* Bus alignment settings
@@ -117,10 +120,8 @@ static void rcar_usb_phy_shutdown(struct
spin_lock_irqsave(priv-lock, flags);
- if (priv-counter-- == 1) { /* last user */
- iowrite32(0x, (reg0 + USBPCTRL0));
+ if (priv-counter-- == 1) /* last user */
iowrite32(0x, (reg0 + USBPCTRL1));
- }
spin_unlock_irqrestore(priv-lock, flags);
}
@@ -133,6 +134,11 @@ static int rcar_usb_phy_probe(struct pla
void __iomem *reg0;
int ret;
+ if (!pdev-dev.platform_data) {
+ dev_err(dev, No platform data\n);
+ return -EINVAL;
+ }
+
res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res0) {
dev_err(dev, Not enough platform resources\n);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Add USB support to R8A7778/BOCK-W
Hello. Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130410' tag. It was created to add support of R8A7778/BOCK-W USB to the platform code and the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/phy/ subtrees. [1/4] rcar-phy: add R8A7778 support [2/4] ARM: shmobile: R8A7778: add USB support [3/4] ARM: shmobile: BOCK-W: add USB support [4/4] ARM: shmobile: BOCK-W: enable USB in defconfig I'm not sure thru which tree this patchset should be merged, however it turns out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10 (which would have been most convenient probably), and it's probably too late to merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11, unfortunately... 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
[PATCH 1/4] rcar-phy: add R8A7778 support
The driver currently only supports R8A7779 SoC. Compared to it, R8A7778 USB-PHY
has extra register range containing two high-speed signal quality characteristic
control registers which should be set up during USB-PHY startup depending on
whether a ferrite bead is in use or not. So, we now handle an optional second
memory range in the driver's probe method, add the 'ferrite_bead' field to the
driver's platform data, and add an extra (optional) step to the USB-PHY startup
routine which sets up the extended registers.
Also mark in the driver's Kconfig section that R8A7778 is now supported and
generally clarify that section, uppercasing the word phy, while at it...
The patch has been tested on the Marzen and BOCK-W boards.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
drivers/usb/phy/Kconfig |8
drivers/usb/phy/rcar-phy.c | 31 +++
include/linux/usb/rcar-phy.h |7 +--
3 files changed, 36 insertions(+), 10 deletions(-)
Index: renesas/drivers/usb/phy/Kconfig
===
--- renesas.orig/drivers/usb/phy/Kconfig
+++ renesas/drivers/usb/phy/Kconfig
@@ -55,13 +55,13 @@ config MV_U3D_PHY
SoC.
config USB_RCAR_PHY
- tristate Renesas R-Car USB phy support
+ tristate Renesas R-Car USB PHY support
depends on USB || USB_GADGET
select USB_OTG_UTILS
help
- Say Y here to add support for the Renesas R-Car USB phy driver.
- This chip is typically used as USB phy for USB host, gadget.
- This driver supports: R8A7779
+ Say Y here to add support for the Renesas R-Car USB common PHY driver.
+ This device is typically used as USB PHY for USB host, gadget.
+ This driver supports R8A7778 and R8A7779.
To compile this driver as a module, choose M here: the
module will be called rcar-phy.
Index: renesas/drivers/usb/phy/rcar-phy.c
===
--- renesas.orig/drivers/usb/phy/rcar-phy.c
+++ renesas/drivers/usb/phy/rcar-phy.c
@@ -26,6 +26,10 @@
#define USBOH0 0x1C
#define USBCTL00x58
+/* High-speed signal quality characteristic control registers (R8A7778 only) */
+#define HSQCTL10x24
+#define HSQCTL20x28
+
/* USBPCTRL1 */
#define PHY_RST(1 2)
#define PLL_ENB(1 1)
@@ -40,6 +44,7 @@ struct rcar_usb_phy_priv {
spinlock_t lock;
void __iomem *reg0;
+ void __iomem *reg1;
int counter;
};
@@ -59,6 +64,7 @@ static int rcar_usb_phy_init(struct usb_
struct device *dev = phy-dev;
struct rcar_phy_platform_data *pdata = dev-platform_data;
void __iomem *reg0 = priv-reg0;
+ void __iomem *reg1 = priv-reg1;
int i;
u32 val;
unsigned long flags;
@@ -76,7 +82,16 @@ static int rcar_usb_phy_init(struct usb_
/* (2) start USB-PHY internal PLL */
iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
- /* (3) USB module status check */
+ /* (3) set USB-PHY in accord with the conditions of usage */
+ if (reg1) {
+ u32 hsqctl1 = pdata-ferrite_bead ? 0x41 : 0;
+ u32 hsqctl2 = pdata-ferrite_bead ? 0x0d : 7;
+
+ iowrite32(hsqctl1, reg1 + HSQCTL1);
+ iowrite32(hsqctl2, reg1 + HSQCTL2);
+ }
+
+ /* (4) USB module status check */
for (i = 0; i 1024; i++) {
udelay(10);
val = ioread32(reg0 + USBST);
@@ -89,7 +104,7 @@ static int rcar_usb_phy_init(struct usb_
goto phy_init_end;
}
- /* (4) USB-PHY reset clear */
+ /* (5) USB-PHY reset clear */
iowrite32(PHY_ENB | PLL_ENB | PHY_RST, (reg0 + USBPCTRL1));
/* set platform specific port settings */
@@ -129,9 +144,9 @@ static void rcar_usb_phy_shutdown(struct
static int rcar_usb_phy_probe(struct platform_device *pdev)
{
struct rcar_usb_phy_priv *priv;
- struct resource *res0;
+ struct resource *res0, *res1;
struct device *dev = pdev-dev;
- void __iomem *reg0;
+ void __iomem *reg0, *reg1 = NULL;
int ret;
if (!pdev-dev.platform_data) {
@@ -149,6 +164,13 @@ static int rcar_usb_phy_probe(struct pla
if (IS_ERR(reg0))
return PTR_ERR(reg0);
+ res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (res1) {
+ reg1 = devm_ioremap_resource(dev, res1);
+ if (IS_ERR(reg1))
+ return PTR_ERR(reg1);
+ }
+
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(dev, priv data allocation
[PATCH 2/4] ARM: shmobile: R8A7778: add USB support
Add USB clock and EHCI, OHCI, and USB PHY platform devices for R8A7778 SoC; add
a function to register PHY device with board-specific platform data and register
EHCI and OHCI platfrom devices from the init_late() board method.
Also, don't forget to enable CONFIG_ARCH_HAS_[EO]HCI options for R8A7778 SoC in
Kconfig...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
arch/arm/mach-shmobile/Kconfig|2
arch/arm/mach-shmobile/clock-r8a7778.c|4
arch/arm/mach-shmobile/include/mach/r8a7778.h |3
arch/arm/mach-shmobile/setup-r8a7778.c| 108 ++
4 files changed, 117 insertions(+)
Index: renesas/arch/arm/mach-shmobile/Kconfig
===
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -40,6 +40,8 @@ config ARCH_R8A7778
select CPU_V7
select SH_CLK_CPG
select ARM_GIC
+ select USB_ARCH_HAS_EHCI
+ select USB_ARCH_HAS_OHCI
config ARCH_R8A7779
bool R-Car H1 (R8A77790)
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -59,12 +59,14 @@ static struct clk *main_clks[] = {
enum {
MSTP114,
+ MSTP100,
MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
MSTP016, MSTP015,
MSTP_NR };
static struct clk mstp_clks[MSTP_NR] = {
[MSTP114] = SH_CLK_MSTP32(clkp, MSTPCR1, 14, 0), /* Ether */
+ [MSTP100] = SH_CLK_MSTP32(clkp, MSTPCR1, 0, 0), /* USB0/1 */
[MSTP026] = SH_CLK_MSTP32(clkp, MSTPCR0, 26, 0), /* SCIF0 */
[MSTP025] = SH_CLK_MSTP32(clkp, MSTPCR0, 25, 0), /* SCIF1 */
[MSTP024] = SH_CLK_MSTP32(clkp, MSTPCR0, 24, 0), /* SCIF2 */
@@ -78,6 +80,8 @@ static struct clk mstp_clks[MSTP_NR] = {
static struct clk_lookup lookups[] = {
/* MSTP32 clocks */
CLKDEV_DEV_ID(sh-eth, mstp_clks[MSTP114]), /* Ether */
+ CLKDEV_DEV_ID(ehci-platform, mstp_clks[MSTP100]), /* USB EHCI
port0/1 */
+ CLKDEV_DEV_ID(ohci-platform, mstp_clks[MSTP100]), /* USB OHCI
port0/1 */
CLKDEV_DEV_ID(sh-sci.0, mstp_clks[MSTP026]), /* SCIF0 */
CLKDEV_DEV_ID(sh-sci.1, mstp_clks[MSTP025]), /* SCIF1 */
CLKDEV_DEV_ID(sh-sci.2, mstp_clks[MSTP024]), /* SCIF2 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -19,10 +19,13 @@
#define __ASM_R8A7778_H__
#include linux/sh_eth.h
+#include linux/usb/rcar-phy.h
extern void r8a7778_add_standard_devices(void);
extern void r8a7778_add_standard_devices_dt(void);
extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
+extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_init_late(void);
extern void r8a7778_init_delay(void);
extern void r8a7778_init_irq(void);
extern void r8a7778_init_irq_dt(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -29,6 +29,12 @@
#include linux/irqchip.h
#include linux/serial_sci.h
#include linux/sh_timer.h
+#include linux/pm_runtime.h
+#include linux/usb/phy.h
+#include linux/usb/hcd.h
+#include linux/usb/ehci_pdriver.h
+#include linux/usb/ohci_pdriver.h
+#include linux/dma-mapping.h
#include mach/irqs.h
#include mach/r8a7778.h
#include mach/common.h
@@ -88,6 +94,99 @@ static struct sh_timer_config sh_tmu1_pl
sh_tmu##idx##_platform_data, \
sizeof(sh_tmu##idx##_platform_data))
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+ DEFINE_RES_MEM(0xffe70800, 0x100),
+ DEFINE_RES_MEM(0xffe76000, 0x100),
+};
+
+void __init r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata)
+{
+ platform_device_register_resndata(platform_bus, rcar_usb_phy, -1,
+ usb_phy_resources,
+ ARRAY_SIZE(usb_phy_resources),
+ pdata, sizeof(*pdata));
+}
+
+/* USB */
+static struct usb_phy *phy;
+
+static int usb_power_on(struct platform_device *pdev)
+{
+ if (!phy)
+ return -EIO;
+
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
+
+ usb_phy_init(phy);
+
+ return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+ if (!phy)
+ return;
+
+ usb_phy_shutdown(phy);
+
+
[PATCH 3/4] ARM: shmobile: BOCK-W: add USB support
Register the USB PHY device from bockw_init(), passing the platform data to it.
Set machine's init_late() method to r8a7778_init_late() in order for [EO]HCI to
get registered too...
The patch has been tested on the BOCK-W board.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
arch/arm/mach-shmobile/board-bockw.c |7 +++
1 file changed, 7 insertions(+)
Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -53,6 +53,11 @@ static struct resource smsc911x_resource
DEFINE_RES_IRQ(irq_pin(0)), /* IRQ 0 */
};
+static struct rcar_phy_platform_data usb_phy_platform_data = {
+ .usbpctrl0 = 0,
+ .ferrite_bead = true, /* ??? */
+};
+
#define IRQ0MR 0x30
static void __init bockw_init(void)
{
@@ -61,6 +66,7 @@ static void __init bockw_init(void)
r8a7778_clock_init();
r8a7778_init_irq_extpin(1);
r8a7778_add_standard_devices();
+ r8a7778_add_usb_phy_device(usb_phy_platform_data);
fpga = ioremap_nocache(0x1820, SZ_1M);
if (fpga) {
@@ -97,4 +103,5 @@ DT_MACHINE_START(BOCKW_DT, bockw)
.init_machine = bockw_init,
.init_time = shmobile_timer_init,
.dt_compat = bockw_boards_compat_dt,
+ .init_late = r8a7778_init_late,
MACHINE_END
--
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 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'. Enable USB storage driver and SCSI disk driver that it needs as well... Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com --- arch/arm/configs/bockw_defconfig | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) Index: renesas/arch/arm/configs/bockw_defconfig === --- renesas.orig/arch/arm/configs/bockw_defconfig +++ renesas/arch/arm/configs/bockw_defconfig @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set # CONFIG_FW_LOADER is not set +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y CONFIG_NETDEVICES=y # CONFIG_NET_CADENCE is not set # CONFIG_NET_VENDOR_BROADCOM is not set @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6 CONFIG_SERIAL_SH_SCI_CONSOLE=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set -# CONFIG_USB_SUPPORT is not set +CONFIG_USB=y +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_PLATFORM=y +CONFIG_USB_EHCI_HCD_PLATFORM=y +CONFIG_USB_STORAGE=y +CONFIG_USB_RCAR_PHY=y CONFIG_UIO=y CONFIG_UIO_PDRV_GENIRQ=y # CONFIG_IOMMU_SUPPORT is not set -- 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 v4] usbnet: allow status interrupt URB to always be active
Some drivers (sierra_net) need the status interrupt URB
active even when the device is closed, because they receive
custom indications from firmware. Add functions to refcount
the status interrupt URB submit/kill operation so that
sub-drivers and the generic driver don't fight over whether
the status interrupt URB is active or not.
A sub-driver can call usbnet_status_start() at any time, but
the URB is only submitted the first time the function is
called. Likewise, when the sub-driver is done with the URB,
it calls usbnet_status_stop() but the URB is only killed when
all users have stopped it. The URB is still killed and
re-submitted for suspend/resume, as before, with the same
refcount it had at suspend.
Signed-off-by: Dan Williams d...@redhat.com
---
drivers/net/usb/usbnet.c | 79 ++
include/linux/usb/usbnet.h | 5 +++
2 files changed, 77 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 51f3192..e8b363a 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -42,7 +42,7 @@
#include linux/workqueue.h
#include linux/mii.h
#include linux/usb.h
-#include linux/usb/usbnet.h
+#include usbnet.h
#include linux/slab.h
#include linux/kernel.h
#include linux/pm_runtime.h
@@ -252,6 +252,70 @@ static int init_status (struct usbnet *dev, struct
usb_interface *intf)
return 0;
}
+/* Submit the interrupt URB if it hasn't been submitted yet */
+static int __usbnet_status_start(struct usbnet *dev, gfp_t mem_flags,
+ bool force)
+{
+ int ret = 0;
+ bool submit = false;
+
+ if (!dev-interrupt)
+ return 0;
+
+ mutex_lock(dev-interrupt_mutex);
+
+ if (force) {
+ /* Only submit now if the URB was previously submitted */
+ if (dev-interrupt_count)
+ submit = true;
+ } else if (++dev-interrupt_count == 1)
+ submit = true;
+
+ if (submit)
+ ret = usb_submit_urb(dev-interrupt, mem_flags);
+
+ dev_dbg(dev-udev-dev, incremented interrupt URB count to %d\n,
+ dev-interrupt_count);
+ mutex_unlock(dev-interrupt_mutex);
+ return ret;
+}
+
+int usbnet_status_start(struct usbnet *dev, gfp_t mem_flags)
+{
+ /* Only drivers that implement a status hook should call this */
+ BUG_ON(dev-interrupt == NULL);
+
+ if (test_bit(EVENT_DEV_ASLEEP, dev-flags))
+ return -EINVAL;
+
+ return __usbnet_status_start(dev, mem_flags, false);
+}
+EXPORT_SYMBOL_GPL(usbnet_status_start);
+
+/* Kill the interrupt URB if all submitters want it killed */
+static void __usbnet_status_stop(struct usbnet *dev, bool force)
+{
+ if (dev-interrupt) {
+ mutex_lock(dev-interrupt_mutex);
+ if (!force)
+ BUG_ON(dev-interrupt_count == 0);
+
+ if (force || --dev-interrupt_count == 0)
+ usb_kill_urb(dev-interrupt);
+
+ dev_dbg(dev-udev-dev,
+ decremented interrupt URB count to %d\n,
+ dev-interrupt_count);
+ mutex_unlock(dev-interrupt_mutex);
+ }
+}
+
+void usbnet_status_stop(struct usbnet *dev)
+{
+ __usbnet_status_stop(dev, false);
+}
+EXPORT_SYMBOL_GPL(usbnet_status_stop);
+
/* Passes this packet up the stack, updating its accounting.
* Some link protocols batch packets, so their rx_fixup paths
* can return clones as well as just modify the original skb.
@@ -725,7 +789,7 @@ int usbnet_stop (struct net_device *net)
if (!(info-flags FLAG_AVOID_UNLINK_URBS))
usbnet_terminate_urbs(dev);
- usb_kill_urb(dev-interrupt);
+ usbnet_status_stop(dev);
usbnet_purge_paused_rxq(dev);
@@ -787,7 +851,7 @@ int usbnet_open (struct net_device *net)
/* start any status interrupt transfer */
if (dev-interrupt) {
- retval = usb_submit_urb (dev-interrupt, GFP_KERNEL);
+ retval = usbnet_status_start(dev, GFP_KERNEL);
if (retval 0) {
netif_err(dev, ifup, dev-net,
intr submit %d\n, retval);
@@ -1430,6 +1494,8 @@ usbnet_probe (struct usb_interface *udev, const struct
usb_device_id *prod)
dev-delay.data = (unsigned long) dev;
init_timer (dev-delay);
mutex_init (dev-phy_mutex);
+ mutex_init(dev-interrupt_mutex);
+ dev-interrupt_count = 0;
dev-net = net;
strcpy (net-name, usb%d);
@@ -1565,7 +1631,7 @@ int usbnet_suspend (struct usb_interface *intf,
pm_message_t message)
*/
netif_device_detach (dev-net);
usbnet_terminate_urbs(dev);
- usb_kill_urb(dev-interrupt);
+ __usbnet_status_stop(dev, true);
/*
* reattach so
[PATCH 2/2 v4] sierra_net: keep status interrupt URB active
The driver and firmware sync up through SYNC messages, and the
firmware's affirmative reply to these SYNC messages appears to be the
Reset indication received via the status interrupt endpoint. Thus the
driver needs the status interrupt endpoint always active so that the
Reset indication can be received even if the netdev is closed, which is
the case right after device insertion.
Signed-off-by: Dan Williams d...@redhat.com
---
drivers/net/usb/sierra_net.c | 40
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 79ab243..c707225 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -44,7 +44,7 @@ static const char driver_name[] = sierra_net;
#include net/ip.h
#include net/udp.h
#include asm/unaligned.h
-#include linux/usb/usbnet.h
+#include usbnet.h
#define SWI_USB_REQUEST_GET_FW_ATTR0x06
#define SWI_GET_FW_ATTR_MASK 0x08
@@ -427,6 +427,13 @@ static void sierra_net_dosync(struct usbnet *dev)
dev_dbg(dev-udev-dev, %s, __func__);
+ /* The SIERRA_NET_HIP_MSYNC_ID command appears to request that the
+* firmware restart itself. After restarting, the modem will respond
+* with the SIERRA_NET_HIP_RESTART_ID indication. The driver continues
+* sending MSYNC commands every few seconds until it receives the
+* RESTART event from the firmware
+*/
+
/* tell modem we are ready */
status = sierra_net_send_sync(dev);
if (status 0)
@@ -705,6 +712,9 @@ static int sierra_net_bind(struct usbnet *dev, struct
usb_interface *intf)
/* set context index initially to 0 - prepares tx hdr template */
sierra_net_set_ctx_index(priv, 0);
+ /* prepare sync message template */
+ memcpy(priv-sync_msg, sync_tmplate, sizeof(priv-sync_msg));
+
/* decrease the rx_urb_size and max_tx_size to 4k on USB 1.1 */
dev-rx_urb_size = SIERRA_NET_RX_URB_SIZE;
if (dev-udev-speed != USB_SPEED_HIGH)
@@ -740,11 +750,6 @@ static int sierra_net_bind(struct usbnet *dev, struct
usb_interface *intf)
kfree(priv);
return -ENODEV;
}
- /* prepare sync message from template */
- memcpy(priv-sync_msg, sync_tmplate, sizeof(priv-sync_msg));
-
- /* initiate the sync sequence */
- sierra_net_dosync(dev);
return 0;
}
@@ -767,8 +772,9 @@ static void sierra_net_unbind(struct usbnet *dev, struct
usb_interface *intf)
netdev_err(dev-net,
usb_control_msg failed, status %d\n, status);
- sierra_net_set_private(dev, NULL);
+ usbnet_status_stop(dev);
+ sierra_net_set_private(dev, NULL);
kfree(priv);
}
@@ -909,6 +915,24 @@ static const struct driver_info sierra_net_info_direct_ip
= {
.tx_fixup = sierra_net_tx_fixup,
};
+static int
+sierra_net_probe(struct usb_interface *udev, const struct usb_device_id *prod)
+{
+ int ret;
+
+ ret = usbnet_probe(udev, prod);
+ if (ret == 0) {
+ struct usbnet *dev = usb_get_intfdata(udev);
+
+ ret = usbnet_status_start(dev, GFP_KERNEL);
+ if (ret == 0) {
+ /* Interrupt URB now set up; initiate sync sequence */
+ sierra_net_dosync(dev);
+ }
+ }
+ return ret;
+}
+
#define DIRECT_IP_DEVICE(vend, prod) \
{USB_DEVICE_INTERFACE_NUMBER(vend, prod, 7), \
.driver_info = (unsigned long)sierra_net_info_direct_ip}, \
@@ -931,7 +955,7 @@ MODULE_DEVICE_TABLE(usb, products);
static struct usb_driver sierra_net_driver = {
.name = sierra_net,
.id_table = products,
- .probe = usbnet_probe,
+ .probe = sierra_net_probe,
.disconnect = usbnet_disconnect,
.suspend = usbnet_suspend,
.resume = usbnet_resume,
--
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
Re: [Libusbx-devel] libusbx v1.0.15-rc2 is now available for testing
On 2013.04.09 11:39, nico wrote: can someone provide a MinGW 32bits built of the last working RC, Sure. Please have a look at the -win download from: https://sourceforge.net/projects/libusbx/files/releases/1.0.15/binaries/ The Windows binary contains the 32 and 64 bit versions of both the static library and DLL, for MSVC and MinGW. In related news, the MSCV DLLs now include the .pdb, as was recently requested. Regards, /Pete -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
Hi Sergei Please add this tested on xxx comment on each patch's log area, not only on [0/x]. We need it on git log I'm going to post R8A7778/BOCK-W series following this one, and all the patches in 1st series should additionally be tested on BOCK-W. Well, I probably can hold up posting version 3 until I have the second series verified. BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a ferrite bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's used or not on BOCK-W board? PHY initialization seems to work with either settings... I can ask it to HW team if you want me. But our local BSP is using No ferrite bead settings... Best regards --- Kuninori Morimoto -- 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: USB3.0 Interrupt transfer in u-boot
i have posted the query on the u-boot mailing list. Waiting for their response on it. Thanks Puneet On Tue, 2013-04-09 at 22:01 +0530, Sarah Sharp wrote: It sounds like u-boot already has basic xHCI support, and you should contact the u-boot developers for further support of interrupt transfers. http://lists.denx.de/mailman/listinfo/u-boot or https://lists.sourceforge.net/lists/listinfo/u-boot-users Disregard my comments about bit-banging the EHCI interfaces. Sarah Sharp On Tue, Apr 09, 2013 at 09:38:17AM +0530, Puneet Sharma wrote: Hello Sarah, Thanks a lot for the information. For your information i am successfully able to enumerate USB device(USB keyboard) over XHCI port by the help of XHCI Stack patch provided in u-boot and also able to do BULK transfer over Mass storage device. After successfully able to do CONTROL and BULK transfer i decided to go for INTERRUPT transfer which i dont know is possible or not. Definately i dont have deep knowledge about Linux USB stack and so i posted the query to get some understanding of it. Also, when you say EHCI can bit-bang the interface what do you mean by that?? Thanks Puneet On Tue, 2013-04-09 at 04:31 +0530, Sarah Sharp wrote: The Linux xHCI driver relies on the USB core for setup. You really don't want to attempt to to separate the two. You can't get just interrupts for transfers either -- you need to do a lot of xHCI host setup before you can even send a control transfer to the device (which is necessary to find out whether it *is* a keyboard). Also, xHCI is not like EHCI, where you can bit-bang the interface. You have to have MMIO and DMA set up before you can use the xHCI host. You might be able to get away without having interrupts and polling the event ring, but I've never tried using any xHCI hosts that way. Also, I don't know what the license is for uboot, but you should know that the xHCI driver is GPL v2 only, and we can't change that. If the license is ok, and you want to take a stab at using the code, it's in drivers/usb/host/xhci*, with some bits in drivers/usb/host/pci-quirks.c. I think you've got some serious yak-shaving ahead of you, so you should think about whether you actually want to add xHCI support to uboot. It's clear that you don't know much about the Linux USB stack, and I'm afraid porting the xHCI driver code over to uboot is going to be pretty painful for you. Sarah Sharp On Wed, Apr 03, 2013 at 11:23:56AM +0530, Puneet Sharma wrote: Hello Sarah, I want to test USB keyboard for XHCI in u-boot and to do that i need the Interrupt transfer code in XHCI controller driver. If possible, can you help me to give that piece of code or can you help me to figure out in kernel where can i find it so that i can try to replicate it in u-boot and make it work. Thanks Regards -- Puneet Sharma puneet.sha...@moschip.commailto:puneet.sha...@moschip.com The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Reorganize R8A7779/Marzen USB code
On Wed, Apr 10, 2013 at 02:26:08AM +0400, Sergei Shtylyov wrote: Hello. Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130410' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: R8A7779: setup EHCI internal buffer [4/9] rcar-phy: remove EHCI internal buffer setup [5/9] ARM: shmobile: R8A7779: remove USB PHY 2nd memory resource [6/9] rcar-phy: correct base address [7/9] rcar-phy: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] rcar-phy: handle platform data I'm not sure thru which tree this patchset should be merged, however it turns out that it's too late now to push it thru Felipe Balbi's USB tree for 3.10 (which would have been most convenient probably), and it's probably too late to merge thru Simon's tree for 3.10 too. So it now have to be postponed to 3.11, unfortunately... Felipe, how would you prefer to handle this? I'm happy for you to take it or to take it myself. -- 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
