Re: [PATCH 0/2] usb: chipidea: fixes for v3.9-rc5
Greg KH writes: > On Thu, Apr 04, 2013 at 01:13:45PM +0300, Alexander Shishkin wrote: >> Hi, >> >> This series contains two fixes, both of which are also applicable to >> -stable. >> >> Michael Grzeschik (2): >> usb: chipidea: udc: fix memory access of shared memory on armv5 >> machines >> usb: chipidea: udc: fix memory leak in _ep_nuke > > As these have been buggy for so long now (almost a year), I'm going to > put them in my -next tree and push them to Linus for 3.10-rc1, which > means they will show up in 3.9.1, ok? Hmm, looks like my mail server is withholding mail from me as I haven't seen this one earlier. Yes, this is ok, thanks! Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/11] usb: musb: add back support for host mode
Daniel > Hi all, > > here are some patches to separate the HCD and gadget part of the musb > driver so they can be deselected in Kconfig. They also make the driver > keep track of the configured port mode that is set from DT, so the > actual runtime configuration can be selected dynamically. > > One thing that is still broken is that once pm_suspend() was called on > a musb device on a USB disconnect, the port won't wake up again when a > device is plugged back in. This could be due to SESSION bit removal when root port is disconnected in otg_timer function. I doubt this is related to my patches, but I > might be wrong. If that effect rings a bell to anyone, please let me > know. > -- Ravi B -- 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 00/11] usb: musb: add back support for host mode
Hi Ravi, On 08.04.2013 09:57, B, Ravi wrote: >> Hi all, >> >> here are some patches to separate the HCD and gadget part of the musb >> driver so they can be deselected in Kconfig. They also make the driver >> keep track of the configured port mode that is set from DT, so the >> actual runtime configuration can be selected dynamically. >> >> One thing that is still broken is that once pm_suspend() was called on >> a musb device on a USB disconnect, the port won't wake up again when a >> device is plugged back in. > > This could be due to SESSION bit removal when root port is disconnected in > otg_timer function. Not sure if we are thinking about the same details, but after debuging this a further, turns out that musb_platform_try_idle() eventually switches off the entire controller, which then leads to DRVBUS going low on the board. That, in turn, prevents the interrupt from being triggered on reconnect, because the host port is not powered anymore. I don't know yet how to cope with that, but for now, I simply disabled the call from musb_stage0_irq() to musb_platform_try_idle() locally. 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
Re: Cannot open two tyyACMs at a time when using 2514b USB hub
Hi Arshad, > The driver used by the USB controller is MUSB_HDRC. Looking at musb_core.c, I've found the following comment: * * Control and bulk use dedicated endpoints, and there's as *yet no mechanism to either (a) reclaim the hardware when *peripherals are NAKing, which gets complicated with bulk *endpoints, or (b) use more than a single bulk endpoint in *each direction. * *RESULT: one device may be perceived as blocking another one. * * * Interrupt and isochronous will dynamically allocate endpoint *hardware, but (a) there's no record keeping for bandwidth; *(b) in the common case that few endpoints are available, there *is no mechanism to reuse endpoints to talk to multiple devices. * *RESULT: At one extreme, bandwidth can be overcommitted in *some hardware configurations, no faults will be reported. *At the other extreme, the bandwidth capabilities which do *exist tend to be severely undercommitted. You can't yet hook *up both a keyboard and a mouse to an external USB hub. Sounds like this could be the limitation you're running into? I'm CC'ing Felipe, who is the maintainer for the musb driver, perhaps he can comment? > > This problem sounds familiar to a problem I have observed in an Ralink > > RT3052 board, which uses the dwc_otg / dwc2 driver. Here, the problem > > was that the host controller offers four "host channels" to communicate > > with different device endpoints, but ttyUSBx interfaces which did not > > have any data to send would keep such a host channel occupied. Having > > two host channels occupied by these IN endpoints, one for the interrupt > > endpoint of the 3G device and one for the interrupt endpoint of the hub, > > occupies all four, making outgoing transfers block and timeout. > > So does this mean that having only 4 TX and RX endpoints available in the > host controller means that you can only ever have 4 USB devices plugged in > at once? No, normally a host channel is only occupied for the duration of the bulk transfer and can be reused for another USB device / endpoint after the transfer completes. The problem occurs when the transfer doesn't complete for a longer period of time (because the device keeps replying with NAK). >From the above comment, it seems that something similar might be going on for your situation. > It is very possible that I have the same problem. The actual error I get > when trying to connect multiple ttyACMx ports is: > > tty_port_close_start: tty->count = 1 port count = 0. > Open_port: Unable to open /dev/ttyACM3: Input/output error For me, I got timeouts and errors like "cat: timed out on ep0out" with USB debugging enabled, but perhaps the musb driver is actually aware that it has run out of endpoints and thus denying the opening of the device? > It seems like you managed to resolve the issue. If so, then could you please > explain how you managed to do it. It's probably not directly helpful to you since the driver is really different, but I patched up the dwc_otg driver to detect this "lockup" situation and halt a transfer that was receiving NAKs to make room for other transfers (and then retry the transfer afterwards). In case anyone is interested, the patch is available on the Fonosfera trac [1] (I hope the link is correct, since the trac seems to be down right now). I plan to port this patch, or perhaps another solution, over to the dwc2 driver in the near future as well. 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 14/41] staging: dwc2: simplify debug output in dwc_hc_init
On Sat, Apr 06, 2013 at 08:43:51PM +0400, Sergei Shtylyov wrote: > >Before, the value of the hcchar register was shifted and masked and then > >the debug output extracted the individual values out of the complete > >hcchar register again. This commit makes the debug prints directly use > >the original values instead. ... > >+dev_vdbg(hsotg->dev, " Multi Cnt: %d\n", 0); > >So it's always 0? Why use "%d" then at all? Or why even print it? Dunno, because it was already like that when I got here? It's probably an artifact of this code living somewhere else a long time ago or something, dunno. I'll remove the line altogether. Gr. -- 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 00/41] staging: dwc2: Miscellaneous cleanups and fixes
Hi Paul, > But you really need to split this into a more manageable series of > patches. It's really difficult to review when you have so many different > things all munged together like this. It's also discouraging to potential > reviewers to see one set of 41 patches, where if it was four series of 10 > patches each it seems like much less work ;) I had thought about that, but the fact that the patch series wouldn't be free of dependencies made me believe that just sending over a big lump of patches to collect some feedback first and then resend smaller series of patches with favorable reviews was a good idea. Looking back, I see your point. I'll see if I can find some themes to split up these patches. > You are using the wrong style for multi-line comments. Please read > Documentation/CodingStyle to see the right way to do it. Also, please run > all your patches thru checkpatch.pl before submitting them, that would > have caught this problem. Hmm, I guess I should re-read SubmittingPatches and SubmitChecklist, sorry for that :-) > I see in some of the patches you don't have any commit message other than > the subject line. Apparently that is a no-no, at least Felipe objected > when I submitted some patches like that. At a minimum just rephrase the > subject line a bit in the body of the patch email. Ok, willdo. I'll try to resend the patches in multiple series today. I'll also include the suggestions from Sergei right away. 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: [PATCH v2 00/11] usb: musb: add back support for host mode
Daniel > On 08.04.2013 09:57, B, Ravi wrote: > >> Hi all, > >> > >> here are some patches to separate the HCD and gadget part of the musb > >> driver so they can be deselected in Kconfig. They also make the driver > >> keep track of the configured port mode that is set from DT, so the > >> actual runtime configuration can be selected dynamically. > >> > >> One thing that is still broken is that once pm_suspend() was called on > >> a musb device on a USB disconnect, the port won't wake up again when a > >> device is plugged back in. > > > > This could be due to SESSION bit removal when root port is disconnected > in otg_timer function. > > Not sure if we are thinking about the same details, but after debuging > this a further, turns out that musb_platform_try_idle() eventually > switches off the entire controller, which then leads to DRVBUS going low > on the board. That, in turn, prevents the interrupt from being triggered > on reconnect, because the host port is not powered anymore. > > I don't know yet how to cope with that, but for now, I simply disabled > the call from musb_stage0_irq() to musb_platform_try_idle() locally. The otg_timer() gets invoked, which removes the session when no device connected to root controller, this is required in otg or dual role mode (Not for host-only mode). Because otg state is un-defined till user's connected a-side of b-side of cable. -- Ravi B -- 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 00/11] usb: musb: add back support for host mode
Hi, On Mon, Apr 08, 2013 at 12:25:38PM +0200, B, Ravi wrote: > Daniel > > > On 08.04.2013 09:57, B, Ravi wrote: > > >> Hi all, > > >> > > >> here are some patches to separate the HCD and gadget part of the musb > > >> driver so they can be deselected in Kconfig. They also make the driver > > >> keep track of the configured port mode that is set from DT, so the > > >> actual runtime configuration can be selected dynamically. > > >> > > >> One thing that is still broken is that once pm_suspend() was called on > > >> a musb device on a USB disconnect, the port won't wake up again when a > > >> device is plugged back in. > > > > > > This could be due to SESSION bit removal when root port is disconnected > > in otg_timer function. > > > > Not sure if we are thinking about the same details, but after debuging > > this a further, turns out that musb_platform_try_idle() eventually > > switches off the entire controller, which then leads to DRVBUS going low > > on the board. That, in turn, prevents the interrupt from being triggered > > on reconnect, because the host port is not powered anymore. > > > > I don't know yet how to cope with that, but for now, I simply disabled > > the call from musb_stage0_irq() to musb_platform_try_idle() locally. > > The otg_timer() gets invoked, which removes the session when no device > connected to root controller, this is required in otg or dual role > mode (Not for host-only mode). Because otg state is un-defined till > user's connected a-side of b-side of cable. Embedded hosts might also want this to save some power while no devices are connected. I guess most of those devices would rely on SRP or on a polling method to enable VBUS. By 'polling' I mean that e.g. every 2 seconds turn vbus on, if no device are enumerated in 200ms, then sleep for another 2 seconds. Or something similar. I know of some products (cellphones) which will only switch Vbus on when you open e.g. file manager. -- balbi signature.asc Description: Digital signature
RE: [PATCH v2 00/11] usb: musb: add back support for host mode
Felipe > Hi, > > On Mon, Apr 08, 2013 at 12:25:38PM +0200, B, Ravi wrote: > > Daniel > > > > > On 08.04.2013 09:57, B, Ravi wrote: > > > >> Hi all, > > > >> > > > >> here are some patches to separate the HCD and gadget part of the > musb > > > >> driver so they can be deselected in Kconfig. They also make the > driver > > > >> keep track of the configured port mode that is set from DT, so the > > > >> actual runtime configuration can be selected dynamically. > > > >> > > > >> One thing that is still broken is that once pm_suspend() was called > on > > > >> a musb device on a USB disconnect, the port won't wake up again > when a > > > >> device is plugged back in. > > > > > > > > This could be due to SESSION bit removal when root port is > disconnected > > > in otg_timer function. > > > > > > Not sure if we are thinking about the same details, but after debuging > > > this a further, turns out that musb_platform_try_idle() eventually > > > switches off the entire controller, which then leads to DRVBUS going > low > > > on the board. That, in turn, prevents the interrupt from being > triggered > > > on reconnect, because the host port is not powered anymore. > > > > > > I don't know yet how to cope with that, but for now, I simply disabled > > > the call from musb_stage0_irq() to musb_platform_try_idle() locally. > > > > The otg_timer() gets invoked, which removes the session when no device > > connected to root controller, this is required in otg or dual role > > mode (Not for host-only mode). Because otg state is un-defined till > > user's connected a-side of b-side of cable. > > Embedded hosts might also want this to save some power while no devices > are connected. I guess most of those devices would rely on SRP or on a > polling method to enable VBUS. Yes, in case of true otg, SRP wakesup the device to enable VBUS. By 'polling' I mean that e.g. every 2 > seconds turn vbus on, if no device are enumerated in 200ms, then sleep > for another 2 seconds. Yes, we had this workaround mechanism enabled on some earlier davinci platform by setting the session periodically to check any device connected for host or otg/dual-role controller to save VBUS power when no device connected. > > Or something similar. I know of some products (cellphones) which will > only switch Vbus on when you open e.g. file manager. > -- Ravi B -- 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 09/11] usb: musb: re-introduce musb->port_mode
Daniel
> Subject: [PATCH v2 09/11] usb: musb: re-introduce musb->port_mode
>
> Define MUSB_PORT_MODE_{HOST,GADGET,DUAL_ROLE} and store the
> platform-specified value in struct musb.
>
> Note that MUSB_PORT_MODE_HOST has to be set to 1 in order to match
> existing device tree bindings which are already documented but in fact
> unusued.
>
> Signed-off-by: Daniel Mack
> ---
> drivers/usb/musb/musb_core.c | 1 +
> drivers/usb/musb/musb_core.h | 7 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index fbcf5cb..2640d25 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -1821,6 +1821,7 @@ musb_init_controller(struct device *dev, int nIrq,
> void __iomem *ctrl)
> musb->board_set_power = plat->set_power;
> musb->min_power = plat->min_power;
> musb->ops = plat->platform_ops;
> + musb->port_mode = plat->mode;
I assume plat->mode is fetched from DT. You may need to over-ride mode field
from DT for host-only or gadget-only configuration through menuconfig.
Some thing like or better than this
+#ifdef CONFIG_MUSB_DUAL_ROLE
+ Musb->port_mode = plat->mode;
+#else
Force it to host or gadget only configuration
#endif
>
> /* The musb_platform_init() call:
>* - adjusts musb->mregs
> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> index 6b65847..174c097 100644
> --- a/drivers/usb/musb/musb_core.h
> +++ b/drivers/usb/musb/musb_core.h
> @@ -77,6 +77,12 @@ struct musb_ep;
> #define is_peripheral_active(m) (!(m)->is_host)
> #define is_host_active(m)((m)->is_host)
>
> +enum {
> + MUSB_PORT_MODE_HOST = 1,
> + MUSB_PORT_MODE_GADGET,
> + MUSB_PORT_MODE_DUAL_ROLE,
> +};
> +
> #ifdef CONFIG_PROC_FS
> #include
> #define MUSB_CONFIG_PROC_FS
> @@ -356,6 +362,7 @@ struct musb {
>
> u8 min_power; /* vbus for periph, in mA/2 */
>
> + int port_mode; /* MUSB_PORT_MODE_* */
> boolis_host;
>
> int a_wait_bcon;/* VBUS timeout in msecs */
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 07/11] usb: musb: add Kconfig options for HOST, GAGDET or DUAL_ROLE modes
Daniel > Subject: [PATCH v2 07/11] usb: musb: add Kconfig options for HOST, GAGDET > or DUAL_ROLE modes > > This makes building the actual object files optional to the selected > mode, which saves users who know which kind of USB mode support they > need some binary size. > > Unimplemented functions are stubbed out with static inline functions. > > Signed-off-by: Daniel Mack > --- > drivers/usb/musb/Kconfig | 29 + > drivers/usb/musb/Makefile | 10 -- > drivers/usb/musb/musb_gadget.h | 21 + > drivers/usb/musb/musb_host.h | 29 +++-- > 4 files changed, 85 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > index 47442d3..aab1568 100644 > --- a/drivers/usb/musb/Kconfig > +++ b/drivers/usb/musb/Kconfig > @@ -28,6 +28,35 @@ config USB_MUSB_HDRC > if USB_MUSB_HDRC > > choice > + bool "MUSB Mode Selection" > + default USB_MUSB_DUAL_ROLE if (USB && USB_GADGET) > + default USB_MUSB_HOST if (USB && !USB_GADGET) > + default USB_MUSB_GADGET if (!USB && USB_GADGET) > + > +config USB_MUSB_HOST > + bool "Host only mode" > + depends on USB > + help > + Select this when you want to use MUSB in host mode only, > + thereby the gadget feature will be regressed. > + > +config USB_MUSB_GADGET > + bool "Gadget only mode" > + depends on USB_GADGET > + help > + Select this when you want to use MUSB in gadget mode only, > + thereby the host feature will be regressed. > + > +config USB_MUSB_DUAL_ROLE > + bool "Dual Role mode" > + depends on (USB && USB_GADGET) > + help > + This is the default mode of working of MUSB controller where > + both host and gadget features are enabled. > + > +endchoice How do you cater for multi-instance support? Where one controller to force as host and other as device (similar to am33x beagle configuration). In general for all combination possible like etc. -- Ravi B -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: USB2 isochronous camera not working on USB3 port
Hi Jean-Philippe, On Wednesday 06 March 2013 14:21:14 jean-philippe francois wrote: > Hi, > > The company I work for is doing USB cameras, for which > I wrote the drivers (out of tree). Just out of curiosity, was there any shortcoming in the UVC specification that pushed your company to implementing a vendor protocol ? > Raw camera data are transferred using isochronous transfer. > > However when plugging the camera on an USB3 port, xhci spits the > following messages on URB submission : > > [ 1704.989785] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr > not part of current TD > > I submit 4 urbs, each containing 16 ISO frames, and have 61 or 62 > messages in the dmesg output. > > In addition, stopping the stream definitely confuse the driver or > chip, which is considered dead by the usb core (cf logs). > > USB3 host is an asmedia ASM1042. > > Please find attached the dmesg output, and the output of lsusb -v for > the device. > > This is with 3.8.2 opensuse Kernel Of The Day > > Regards, > Jean-Philippe François > > PS : I am not subscribed to the list, can I be cc'ed in the reply ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] usb: musb: add Kconfig options for HOST, GAGDET or DUAL_ROLE modes
Hi Ravi, On 08.04.2013 12:42, B, Ravi wrote: >> Subject: [PATCH v2 07/11] usb: musb: add Kconfig options for HOST, GAGDET >> or DUAL_ROLE modes >> >> This makes building the actual object files optional to the selected >> mode, which saves users who know which kind of USB mode support they >> need some binary size. >> >> Unimplemented functions are stubbed out with static inline functions. >> >> Signed-off-by: Daniel Mack >> --- >> drivers/usb/musb/Kconfig | 29 + >> drivers/usb/musb/Makefile | 10 -- >> drivers/usb/musb/musb_gadget.h | 21 + >> drivers/usb/musb/musb_host.h | 29 +++-- >> 4 files changed, 85 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig >> index 47442d3..aab1568 100644 >> --- a/drivers/usb/musb/Kconfig >> +++ b/drivers/usb/musb/Kconfig >> @@ -28,6 +28,35 @@ config USB_MUSB_HDRC >> if USB_MUSB_HDRC >> >> choice >> +bool "MUSB Mode Selection" >> +default USB_MUSB_DUAL_ROLE if (USB && USB_GADGET) >> +default USB_MUSB_HOST if (USB && !USB_GADGET) >> +default USB_MUSB_GADGET if (!USB && USB_GADGET) >> + >> +config USB_MUSB_HOST >> +bool "Host only mode" >> +depends on USB >> +help >> + Select this when you want to use MUSB in host mode only, >> + thereby the gadget feature will be regressed. >> + >> +config USB_MUSB_GADGET >> +bool "Gadget only mode" >> +depends on USB_GADGET >> +help >> + Select this when you want to use MUSB in gadget mode only, >> + thereby the host feature will be regressed. >> + >> +config USB_MUSB_DUAL_ROLE >> +bool "Dual Role mode" >> +depends on (USB && USB_GADGET) >> +help >> + This is the default mode of working of MUSB controller where >> + both host and gadget features are enabled. >> + >> +endchoice > > How do you cater for multi-instance support? Where one controller to force as > host and other as device (similar to am33x beagle configuration). > In general for all combination possible like > etc. The actual mode chosen for an instance is passed in via pdata/DT. The Kconfig options only exist in order to stub out code that certainly isn't needed for a particular platform. IOW, to reduce the binary size. So the beagleboard will have to select the DUAL_ROLE config parameters, where other board (like mine) can go for the HOST only option. If a user selects a mode as runtime parameter that is stubbed out by the chosen config, it will simply don't do anything. Just as with a driver that is referenced from DT but not compiled in. I don't think we should be over-smart here and mess with the configured platform data. If the platform data is wrong, it has to be fixed anyway. Felipe, do you agree? 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
Re: [PATCH v2 09/11] usb: musb: re-introduce musb->port_mode
On 08.04.2013 12:39, B, Ravi wrote:
>> Subject: [PATCH v2 09/11] usb: musb: re-introduce musb->port_mode
>>
>> Define MUSB_PORT_MODE_{HOST,GADGET,DUAL_ROLE} and store the
>> platform-specified value in struct musb.
>>
>> Note that MUSB_PORT_MODE_HOST has to be set to 1 in order to match
>> existing device tree bindings which are already documented but in fact
>> unusued.
>>
>> Signed-off-by: Daniel Mack
>> ---
>> drivers/usb/musb/musb_core.c | 1 +
>> drivers/usb/musb/musb_core.h | 7 +++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>> index fbcf5cb..2640d25 100644
>> --- a/drivers/usb/musb/musb_core.c
>> +++ b/drivers/usb/musb/musb_core.c
>> @@ -1821,6 +1821,7 @@ musb_init_controller(struct device *dev, int nIrq,
>> void __iomem *ctrl)
>> musb->board_set_power = plat->set_power;
>> musb->min_power = plat->min_power;
>> musb->ops = plat->platform_ops;
>> +musb->port_mode = plat->mode;
>
> I assume plat->mode is fetched from DT.
Yes, that's already done in the current mainline. The problem is that
this value is not used anywhere, though.
> You may need to over-ride mode field from DT for host-only or gadget-only
> configuration through menuconfig.
As stated in the other mail, I don't think this is a good idea at all.
The config chooses which parts of the kernel you want to build in, the
runtime config lets you select the actual mode. Mixing them up just
makes it much harder for people to understand what's going on.
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
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Tony, On 04/05/2013 05:43 PM, Tony Lindgren wrote: > * Benoit Cousson [130405 03:00]: >> On 04/05/2013 10:30 AM, Benoit Cousson wrote: >> >> ... >> ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support >>> >>> These 3 DTS patches are good to me, but I cannot applied them on top of >>> the already existing patches I queued for 3.10. >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git >>> for_3.10/dts >>> >>> Could you rebase these 3 ones only, and I will applied them. >> >> Mmm, in fact, I've just seen the pull request from Tony :-( >> >> >> Tony, >> >> Don't you want to remove these DTS patches from the pull-request? > > Oops sorry :( Looks like I applied them mistakenly as I saved all > the patches into a mbox, then applied it. Anyways, too late to start > messing with it now. > >> Otherwise, I will have to rebase the whole DTS series on top of yours. >> That being said, if the branch is not supposed to be rebased, it is doable. > > I pulled in your for_3.10/dts for testing, and to me it looks like > it's just overlapping additions. So that should be OK to resolve while > pulling it in. > > It seems there's no need to add omap-for-v3.10/usb as a dependency for > your for_3.10/dts unless the conflict gets non-trivial with some > additional patches. The branch was not complete, with the latest additions, we do have conflict due to the addition of several new nodes at the same place. The resolution is not that hard since it is addition of node only, but the rebase on to of omap-for-v3.10/usb will avoid the issue. I have a new pre-merged branch available. for_3.10/dts_merged is based on omap-for-v3.10/usb and Paul's omap-devel-b-for-3.10 branch to get the AM33xx hwmod. Paul's branch is just needed to avoid AM33xx regression introduced by Santosh hwmod changes present in my branch. Just let me know which one you will prefer to pull. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: USB2 isochronous camera not working on USB3 port
2013/4/8 Laurent Pinchart : > Hi Jean-Philippe, > > On Wednesday 06 March 2013 14:21:14 jean-philippe francois wrote: >> Hi, >> >> The company I work for is doing USB cameras, for which >> I wrote the drivers (out of tree). > > Just out of curiosity, was there any shortcoming in the UVC specification that > pushed your company to implementing a vendor protocol ? The main shortcoming in retrospect IMO is the absence of any raw format. However this shortcoming was not the main force behind going with our own protocol. - when we started (on windows) around 2002 we were not aware of UVC. - when I started to develop a driver for the linux kernel, there was no UVC stack. However the reason we did not switch to an UVC firmware is that our streaming processor (Cypress FX2LP) hasn't the capability to inspect and edit the video coming from the sensor to inject the necessary start and end code. > >> Raw camera data are transferred using isochronous transfer. >> >> However when plugging the camera on an USB3 port, xhci spits the >> following messages on URB submission : >> >> [ 1704.989785] xhci_hcd :01:00.0: ERROR Transfer event TRB DMA ptr >> not part of current TD >> >> I submit 4 urbs, each containing 16 ISO frames, and have 61 or 62 >> messages in the dmesg output. >> >> In addition, stopping the stream definitely confuse the driver or >> chip, which is considered dead by the usb core (cf logs). >> >> USB3 host is an asmedia ASM1042. >> >> Please find attached the dmesg output, and the output of lsusb -v for >> the device. >> >> This is with 3.8.2 opensuse Kernel Of The Day >> >> Regards, >> Jean-Philippe François >> >> PS : I am not subscribed to the list, can I be cc'ed in the reply ? > > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Reorganize R8A7779/Marzen USB code
Hello. On 08-04-2013 6:33, Simon Horman 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. It's not about style. I tried to keep the series copmpletely bisectable, and granting almost all requests about splitting the patches would have broken the bisection. When you send v2 patch, could you please add "this patch is tested on bard" on each patch's comment area ? I'm not sure it's worth doing v2, although in one place I can indeed readily split the patch. All patches were tested on the Marzen board, I forgot to mention that in the cover letter. Well, there's gonna be version 2 now, mainly because Alan Stern wasn't content with the patch #2. When you spin v2 could you note in the change log of each patch that includes both SoC and board of SoC and river code that the reason for this is to avoid breaking bisection? OK, but I wonder if you have read my cover letter before looking at the patches... I clearly stated that keeping the series bisectable was one of my main goals. Thanks. 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 07/11] usb: musb: add Kconfig options for HOST, GAGDET or DUAL_ROLE modes
Hi Daniel > > On 08.04.2013 12:42, B, Ravi wrote: > >> Subject: [PATCH v2 07/11] usb: musb: add Kconfig options for HOST, > GAGDET > >> or DUAL_ROLE modes > >> > >> This makes building the actual object files optional to the selected > >> mode, which saves users who know which kind of USB mode support they > >> need some binary size. > >> > >> Unimplemented functions are stubbed out with static inline functions. > >> > >> Signed-off-by: Daniel Mack > >> --- > >> drivers/usb/musb/Kconfig | 29 + > >> drivers/usb/musb/Makefile | 10 -- > >> drivers/usb/musb/musb_gadget.h | 21 + > >> drivers/usb/musb/musb_host.h | 29 +++-- > >> 4 files changed, 85 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > >> index 47442d3..aab1568 100644 > >> --- a/drivers/usb/musb/Kconfig > >> +++ b/drivers/usb/musb/Kconfig > >> @@ -28,6 +28,35 @@ config USB_MUSB_HDRC > >> if USB_MUSB_HDRC > >> > >> choice > >> + bool "MUSB Mode Selection" > >> + default USB_MUSB_DUAL_ROLE if (USB && USB_GADGET) > >> + default USB_MUSB_HOST if (USB && !USB_GADGET) > >> + default USB_MUSB_GADGET if (!USB && USB_GADGET) > >> + > >> +config USB_MUSB_HOST > >> + bool "Host only mode" > >> + depends on USB > >> + help > >> +Select this when you want to use MUSB in host mode only, > >> +thereby the gadget feature will be regressed. > >> + > >> +config USB_MUSB_GADGET > >> + bool "Gadget only mode" > >> + depends on USB_GADGET > >> + help > >> +Select this when you want to use MUSB in gadget mode only, > >> +thereby the host feature will be regressed. > >> + > >> +config USB_MUSB_DUAL_ROLE > >> + bool "Dual Role mode" > >> + depends on (USB && USB_GADGET) > >> + help > >> +This is the default mode of working of MUSB controller where > >> +both host and gadget features are enabled. > >> + > >> +endchoice > > > > How do you cater for multi-instance support? Where one controller to > force as host and other as device (similar to am33x beagle configuration). > > In general for all combination possible like > etc. > > The actual mode chosen for an instance is passed in via pdata/DT. The > Kconfig options only exist in order to stub out code that certainly > isn't needed for a particular platform. IOW, to reduce the binary size. > > So the beagleboard will have to select the DUAL_ROLE config parameters, > where other board (like mine) can go for the HOST only option. > > If a user selects a mode as runtime parameter that is stubbed out by the > chosen config, it will simply don't do anything. Just as with a driver > that is referenced from DT but not compiled in. I don't think we should > be over-smart here and mess with the configured platform data. If the > platform data is wrong, it has to be fixed anyway. Felipe, do you agree? > > I understand, this is for binary code reduction. But in multi instance case force host/device config option shall be selected only when both controller need to configured as host only or device only. like or . In any other case dual-role need to be chosen. You can explain in help section of this Kconfig option. -- Ravi B -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] usb: musb: add Kconfig options for HOST, GAGDET or DUAL_ROLE modes
Hi Ravi, On 08.04.2013 14:48, B, Ravi wrote: >> On 08.04.2013 12:42, B, Ravi wrote: Subject: [PATCH v2 07/11] usb: musb: add Kconfig options for HOST, >> GAGDET or DUAL_ROLE modes This makes building the actual object files optional to the selected mode, which saves users who know which kind of USB mode support they need some binary size. Unimplemented functions are stubbed out with static inline functions. Signed-off-by: Daniel Mack --- drivers/usb/musb/Kconfig | 29 + drivers/usb/musb/Makefile | 10 -- drivers/usb/musb/musb_gadget.h | 21 + drivers/usb/musb/musb_host.h | 29 +++-- 4 files changed, 85 insertions(+), 4 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 47442d3..aab1568 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -28,6 +28,35 @@ config USB_MUSB_HDRC if USB_MUSB_HDRC choice + bool "MUSB Mode Selection" +default USB_MUSB_DUAL_ROLE if (USB && USB_GADGET) +default USB_MUSB_HOST if (USB && !USB_GADGET) +default USB_MUSB_GADGET if (!USB && USB_GADGET) + +config USB_MUSB_HOST + bool "Host only mode" + depends on USB +help +Select this when you want to use MUSB in host mode only, +thereby the gadget feature will be regressed. + +config USB_MUSB_GADGET + bool "Gadget only mode" + depends on USB_GADGET + help + Select this when you want to use MUSB in gadget mode only, + thereby the host feature will be regressed. + +config USB_MUSB_DUAL_ROLE + bool "Dual Role mode" +depends on (USB && USB_GADGET) +help + This is the default mode of working of MUSB controller where + both host and gadget features are enabled. + +endchoice >>> >>> How do you cater for multi-instance support? Where one controller >>> to >> force as host and other as device (similar to am33x beagle >> configuration). >>> In general for all combination possible like >> device> >> etc. >> >> The actual mode chosen for an instance is passed in via pdata/DT. >> The Kconfig options only exist in order to stub out code that >> certainly isn't needed for a particular platform. IOW, to reduce >> the binary size. >> >> So the beagleboard will have to select the DUAL_ROLE config >> parameters, where other board (like mine) can go for the HOST only >> option. >> >> If a user selects a mode as runtime parameter that is stubbed out >> by the chosen config, it will simply don't do anything. Just as >> with a driver that is referenced from DT but not compiled in. I >> don't think we should be over-smart here and mess with the >> configured platform data. If the platform data is wrong, it has to >> be fixed anyway. Felipe, do you agree? >> >> > > I understand, this is for binary code reduction. But in multi > instance case force host/device config option shall be selected only > when both controller need to configured as host only or device only. > like or . In any other case dual-role > need to be chosen. Yes, agreed. > You can explain in help section of this Kconfig option. Ok, I'll wait for more comments on this series and then add this to a respin. 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
RE: [PATCH v2 09/11] usb: musb: re-introduce musb->port_mode
Daniel
> On 08.04.2013 12:39, B, Ravi wrote:
> >> Subject: [PATCH v2 09/11] usb: musb: re-introduce musb->port_mode
> >>
> >> Define MUSB_PORT_MODE_{HOST,GADGET,DUAL_ROLE} and store the
> >> platform-specified value in struct musb.
> >>
> >> Note that MUSB_PORT_MODE_HOST has to be set to 1 in order to match
> >> existing device tree bindings which are already documented but in fact
> >> unusued.
> >>
> >> Signed-off-by: Daniel Mack
> >> ---
> >> drivers/usb/musb/musb_core.c | 1 +
> >> drivers/usb/musb/musb_core.h | 7 +++
> >> 2 files changed, 8 insertions(+)
> >>
> >> diff --git a/drivers/usb/musb/musb_core.c
> b/drivers/usb/musb/musb_core.c
> >> index fbcf5cb..2640d25 100644
> >> --- a/drivers/usb/musb/musb_core.c
> >> +++ b/drivers/usb/musb/musb_core.c
> >> @@ -1821,6 +1821,7 @@ musb_init_controller(struct device *dev, int nIrq,
> >> void __iomem *ctrl)
> >>musb->board_set_power = plat->set_power;
> >>musb->min_power = plat->min_power;
> >>musb->ops = plat->platform_ops;
> >> + musb->port_mode = plat->mode;
> >
> > I assume plat->mode is fetched from DT.
>
> Yes, that's already done in the current mainline. The problem is that
> this value is not used anywhere, though.
>
> > You may need to over-ride mode field from DT for host-only or gadget-
> only configuration through menuconfig.
>
> As stated in the other mail, I don't think this is a good idea at all.
> The config chooses which parts of the kernel you want to build in, the
> runtime config lets you select the actual mode. Mixing them up just
> makes it much harder for people to understand what's going on.
>
My concern is , what if user selects HOST only mode thru menu config and
provide DT port-mode bindings wrongly.
--
Ravi B
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On 2013/3/30 4:24, Alan Stern wrote: On Fri, 29 Mar 2013, Sarah Sharp wrote: Also, bear in mind that the proposed patch does not give userspace a way to power off ports via usbfs. What the new code does is a power-off reset -- it turns off power to the port, waits a short time, and then turns power back on. I think we need two separate IOCTLs: turn off the port power and turn it on. Then we get the manual port power off for our QA testing, distros can make interesting policies about manually powering off ports, and userspace can choose how long they want the port to be off. After all, different devices may need a longer powered-off period than others. Or one port-power IOCTL that takes the setting as an argument. Yes, this would be more flexible than a power-off reset. Hi Alan & Sarah: I just recall why I put power off and power on in one ioctl. At first, I also tried to make power on and power off into two ioctls. But I found after powering off a device, the usbfs device node will be removed and so can't power on the port via the same usbfs node. For this point, we should add usbfs node for usb port? Alan Stern -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/11] usb: musb: re-introduce musb->port_mode
On 08.04.2013 14:55, B, Ravi wrote:
> Daniel
>> On 08.04.2013 12:39, B, Ravi wrote:
Subject: [PATCH v2 09/11] usb: musb: re-introduce musb->port_mode
Define MUSB_PORT_MODE_{HOST,GADGET,DUAL_ROLE} and store the
platform-specified value in struct musb.
Note that MUSB_PORT_MODE_HOST has to be set to 1 in order to match
existing device tree bindings which are already documented but in fact
unusued.
Signed-off-by: Daniel Mack
---
drivers/usb/musb/musb_core.c | 1 +
drivers/usb/musb/musb_core.h | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/musb/musb_core.c
>> b/drivers/usb/musb/musb_core.c
index fbcf5cb..2640d25 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1821,6 +1821,7 @@ musb_init_controller(struct device *dev, int nIrq,
void __iomem *ctrl)
musb->board_set_power = plat->set_power;
musb->min_power = plat->min_power;
musb->ops = plat->platform_ops;
+ musb->port_mode = plat->mode;
>>>
>>> I assume plat->mode is fetched from DT.
>>
>> Yes, that's already done in the current mainline. The problem is that
>> this value is not used anywhere, though.
>>
>>> You may need to over-ride mode field from DT for host-only or gadget-
>> only configuration through menuconfig.
>>
>> As stated in the other mail, I don't think this is a good idea at all.
>> The config chooses which parts of the kernel you want to build in, the
>> runtime config lets you select the actual mode. Mixing them up just
>> makes it much harder for people to understand what's going on.
>>
>
> My concern is , what if user selects HOST only mode thru menu config
> and provide DT port-mode bindings wrongly.
As I said - this is the same as disabling a driver but referencing it
from DT.
After all, we're not dealing with end-users here but with people who
integrate the kernel for a special kind of device. I'd say we can expect
them to provide the correct data in their DT. Fixing it up is not the
job of the driver IMO.
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
Re: Cannot open two tyyACMs at a time when using 2514b USB hub
> > It seems like you managed to resolve the issue. If so, then could you please > > explain how you managed to do it. > It's probably not directly helpful to you since the driver is really > different, but I patched up the dwc_otg driver to detect this "lockup" > situation and halt a transfer that was receiving NAKs to make room for > other transfers (and then retry the transfer afterwards). > > In case anyone is interested, the patch is available on the Fonosfera > trac [1] (I hope the link is correct, since the trac seems to be down > right now). I plan to port this patch, or perhaps another solution, over > to the dwc2 driver in the near future as well. w00ps, forgot the link to the patch: [1]: http://trac.fonosfera.org/fon-ng/browser/trunk/openwrt/target/linux/fonera2n/patches-2.6.21/105-USB-nak-free-host-channel.patch -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Hi, On Thursday 04 April 2013 05:24 AM, Stephen Warren wrote: On 04/03/2013 06:53 AM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has describes the PHY (label, type etc..) and ops like init, exit, suspend, resume, power_on, power_off. The documentation for the generic PHY framework is added in Documentation/phy.txt and the documentation for the sysfs entry is added in Documentation/ABI/testing/sysfs-class-phy and the documentation for dt binding is can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h +extern struct phy *devm_phy_create(struct device *dev, const char *label, + struct device_node *of_node, int type, struct phy_ops *ops, + void *priv); Can't the function get of_node from dev->of_node? I wonder if we shouldn't split up the registration a bit though: A function which registers a PHY object itself. That's the function above. A function which registers a DT-based PHY provider. Then, the of_xlate op would be part of the PHY provider, not part of some random PHY that happens to exist on that node. So: Yeah. Makes sense to me. By this we can avoid struct phy * to represent two different things (phy provider and phy instance). Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > On 2013/3/30 4:24, Alan Stern wrote: > >On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > >>>Also, bear in mind that the proposed patch does not give userspace a > >>>way to power off ports via usbfs. What the new code does is a > >>>power-off reset -- it turns off power to the port, waits a short time, > >>>and then turns power back on. > >> > >>I think we need two separate IOCTLs: turn off the port power and turn it > >>on. Then we get the manual port power off for our QA testing, distros > >>can make interesting policies about manually powering off ports, and > >>userspace can choose how long they want the port to be off. After all, > >>different devices may need a longer powered-off period than others. > > > >Or one port-power IOCTL that takes the setting as an argument. Yes, > >this would be more flexible than a power-off reset. > Hi Alan & Sarah: > I just recall why I put power off and power on in one ioctl. > At first, I also tried to make power on and power off into two ioctls. > But I found after powering off a device, the usbfs device node will > be removed and so can't power on the port via the same usbfs node. > > For this point, we should add usbfs node for usb port? No. -- 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
[help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi everyone, I need some help to understand how USB is configured. I am updating an old kernel (2.6.32 !) to the version 3.8.2. I am self-taught on Linux kernel so, sometimes, I need the help of the community to understand it :) The SoC is a IMX27. For the USB side, we have a NXP ISP1504. 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 " I think that I have understood that it uses the structure usb_otg that we have to create with the function "imx_otg_ulpi_create". --> But I did not understand the difference with the structures "usb_otg" and "usb_phy". --> And how / when the "usb_phy" is initialized ? I have checked with some printks and the problem of ULPI polling is during the function "ulpi_read" for a "wait for completion". --> What is the "wait for completion" ? --> What I am missing to make it work ? Thank you in advance to help me to understand it. -- Mylène JOSSERAND Navocap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On 2013/4/1 23:12, Alan Stern wrote: On Mon, 1 Apr 2013, Lan Tianyu wrote: On 2013年03月30日 01:23, Alan Stern wrote: On Fri, 29 Mar 2013, Sarah Sharp wrote: However, what happens if you echo 0 to pm_qos_no_power_off, the power/control is set to auto, and there's a suspended USB device attached to the port with remote wakeup enabled? Will the port be powered off? I don't think it will with the current patchset, but I will have to double check. It shouldn't be, because remote wakeup is enabled. But what about the case where remote wakeup is disabled? Will writing a 0 to pm_qos_no_power_off cause the power to be turned off? Or what about the case where there's no device attached to the port? I guess both questions amount to the same thing: When the user writes to a pm_qos_* file, does the code call pm_runtime_idle? Usb port's initial usage count is 0. For port attached with usb port, when usb device is connected, the usb port's usage count is increased by one. During device's suspend, its usage count would be decreased to 0 and powered of only when remote wakeup disable, persist enable and PM Qos NO_POWER_OFF unsetting. I already know all this. During pm_qos_* file changing, pm_runtime_get_sync/put(port_dev) will be done in the dev_pm_qos_update_flags(). The port's usage count would be increased and decreased by 1. Whether the port's pm_runtime_idle would be called depends on port's usage count to be set to 0. That answers my question. If the usb port has already been powered off(port usage count is already set to 0), it would be powered on first and powered off depending the PM Qos NO_POWER_OFF flag value. Obviously. If the usb port wasn't powered off, this mean the usb port didn't meet power off condition() and its usage count was still greater than 0 So during changing flag, only usage count was changed and no actual operation. No, because one of the power off conditions is that the NO_POWER_OFF flag must be clear. If that flag was set, the port won't be powered off even though the usage count is equal to 0. If the write to the pm_qos_* file then clears the flag, the port _will_ get powered off. Hi Alan: I think current code can't achieve that power off port(whose child device was already suspended but it was not powered off due to NO_POWER_OFF flag setting.) via clearing NO_POWER_OFF flag. Because at that moment, its usage count can't be 0. At last, it should be 1 or large. port's pm_runtime_idle will not be called. Further thinking, now we call pm_runtime_put_sync() in the usb_port_suspend() when persist enable, do_remote_wakeup disable and PM Qos NO_POWER_OFF flag cleared. But PM Qos NO_POWER_OFF flag will also will be checked in the usb_port_runtime_suspend(). This seems redundant. From my opinion, the PM Qos check in the usb_port_suspend() should be removed and port usage count will reach 0 when persist enable and remote_wakeup disable. Whether power off or not totally depends on the PM Qos flag in the usb_port_runtime_suspend(). For NO_POWER_OFF flag setting case during usb device being suspend, the port's usage count will be 0 but its runtime status is still active due to flag being set and usb_port_runtime_suspend() returns -EAGAIN. At this time, clearing the flag and the port can be powered off. Does this make sense? For empty port, Only when PM Qos NO_POWER_OFF flag value is set to 0, the port will be power off. Alan Stern -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xhci: fix list access before init
On Fri, Apr 05, 2013 at 08:52:53AM -0700, Aguirre Rodriguez, Sergio A wrote: > On Fri, Apr 05, 2013 at 06:51:21AM +0400, Vladimir Murzin wrote: > > On Thu, Apr 04, 2013 at 12:29:25PM -0700, Sarah Sharp wrote: > > What about picking up Sergio's patch and bw table part of this patch > > as separate commits? > > I'm ok to take your patch instead too, since is already addressing what > I'm doing. It's basically, my patch + similar change for bw tables, so > it's an improvement :) > > Sarah, > > I'll propose to ignore my patch, and take this one instead. Ok, sounds good. I'll queue it up shortly, but we're getting close to the 3.10 merge window, so I don't know if Greg is still taking bug fixes. The patch may have to wait a couple weeks. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xhci: fix list access before init
On Mon, Apr 08, 2013 at 08:18:44AM -0700, Sarah Sharp wrote: > On Fri, Apr 05, 2013 at 08:52:53AM -0700, Aguirre Rodriguez, Sergio A wrote: > > On Fri, Apr 05, 2013 at 06:51:21AM +0400, Vladimir Murzin wrote: > > > On Thu, Apr 04, 2013 at 12:29:25PM -0700, Sarah Sharp wrote: > > > What about picking up Sergio's patch and bw table part of this patch > > > as separate commits? > > > > I'm ok to take your patch instead too, since is already addressing what > > I'm doing. It's basically, my patch + similar change for bw tables, so > > it's an improvement :) > > > > Sarah, > > > > I'll propose to ignore my patch, and take this one instead. > > Ok, sounds good. I'll queue it up shortly, but we're getting close to > the 3.10 merge window, so I don't know if Greg is still taking bug > fixes. The patch may have to wait a couple weeks. I can take bugfixes for a few more days. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: xhci-dbg: Display endpoint number and direction in context dump
On Thu, Apr 04, 2013 at 02:03:04PM -0700, Julius Werner wrote: > When CONFIG_XHCI_HCD_DEBUGGING is activated, the XHCI driver can dump > device and input contexts to the console. The endpoint contexts in that > dump are labeled "Endpoint N Context", where N is DCI - 1... this is > very confusing, especially for people who are not that familiar with > the XHCI specification. Let's change this to display the endpoint number > and direction, which are much more commonly used concepts in USB (and > map to XHCI DCIs 1-to-1). Thanks for the patch, I think it's a good idea, however... > Signed-off-by: Julius Werner > --- > drivers/usb/host/xhci-dbg.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c > index 5f3a7c7..98b1bee 100644 > --- a/drivers/usb/host/xhci-dbg.c > +++ b/drivers/usb/host/xhci-dbg.c > @@ -507,7 +507,8 @@ static void xhci_dbg_ep_ctx(struct xhci_hcd *xhci, > dma_addr_t dma = ctx->dma + > ((unsigned long)ep_ctx - (unsigned long)ctx->bytes); > > - xhci_dbg(xhci, "Endpoint %02d Context:\n", i); > + xhci_dbg(xhci, "Endpoint %02d %s Context:\n", > + DIV_ROUND_UP(i, 2), i % 2 ? "OUT" : "IN"); ...could you create two macros in xhci.h to translate the xHCI endpoint context number to USB formated endpoint numbers, and IN vs. OUT? I suspect that there will be other places in the code where you'll want to print the USB formatted endpoint numbers. Having macros for later use would be helpful. Also, this patch is too late for the 3.10 merge window, so it will have to wait for 3.11. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] xhci - clarify compliance mode debug messages
Applied, thanks!
On Fri, Apr 05, 2013 at 02:27:07PM -0400, Tony Camuso wrote:
> There are no functional changes in this patch. However, because the
> compliance mode timer can be deleted in more than one function, it
> seemed expedient to include the function name in the debug strings.
>
> Also limited the use of capitals to the first word in the compliance
> mode debug messages, except after a function name where all words
> start with lower case, in keeping with the style prevalent elsewhere
> in xhci.c.
>
> Signed-off-by: Tony Camuso
> ---
> drivers/usb/host/xhci.c | 14 +-
> 1 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 53b8f89..5bb1a6a 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -417,9 +417,9 @@ static void compliance_mode_recovery(unsigned long arg)
>* Compliance Mode Detected. Letting USB Core
>* handle the Warm Reset
>*/
> - xhci_dbg(xhci, "Compliance Mode Detected->Port %d!\n",
> + xhci_dbg(xhci, "Compliance mode detected->port %d\n",
> i + 1);
> - xhci_dbg(xhci, "Attempting Recovery routine!\n");
> + xhci_dbg(xhci, "Attempting compliance mode recovery\n");
> hcd = xhci->shared_hcd;
>
> if (hcd->state == HC_STATE_SUSPENDED)
> @@ -457,7 +457,7 @@ static void compliance_mode_recovery_timer_init(struct
> xhci_hcd *xhci)
> set_timer_slack(&xhci->comp_mode_recovery_timer,
> msecs_to_jiffies(COMP_MODE_RCVRY_MSECS));
> add_timer(&xhci->comp_mode_recovery_timer);
> - xhci_dbg(xhci, "Compliance Mode Recovery Timer Initialized.\n");
> + xhci_dbg(xhci, "Compliance mode recovery timer initialized\n");
> }
>
> /*
> @@ -733,8 +733,11 @@ void xhci_stop(struct usb_hcd *hcd)
>
> /* Deleting Compliance Mode Recovery Timer */
> if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
> - (!(xhci_all_ports_seen_u0(xhci
> + (!(xhci_all_ports_seen_u0(xhci {
> del_timer_sync(&xhci->comp_mode_recovery_timer);
> + xhci_dbg(xhci, "%s: compliance mode recovery timer deleted\n",
> + __func__);
> + }
>
> if (xhci->quirks & XHCI_AMD_PLL_FIX)
> usb_amd_dev_put();
> @@ -930,7 +933,8 @@ int xhci_suspend(struct xhci_hcd *xhci)
> if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
> (!(xhci_all_ports_seen_u0(xhci {
> del_timer_sync(&xhci->comp_mode_recovery_timer);
> - xhci_dbg(xhci, "Compliance Mode Recovery Timer Deleted!\n");
> + xhci_dbg(xhci, "%s: compliance mode recovery timer deleted\n",
> + __func__);
> }
>
> /* step 5: remove core well power */
> --
> 1.7.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Active URB submitted twice in pegasus driver
On Fri, Apr 05, 2013 at 08:01:03PM +0300, Petko Manolov wrote: > On Wed, 27 Mar 2013, Petko Manolov wrote: > >On Tue, 26 Mar 2013, Sarah Sharp wrote: > The new driver actually compiles and runs fine with Pegasus-II based > device. Please let me know if you run into problems. I'm away for a week, so I won't be able to test for a while. I'll let you know the results when I get back. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > On 2013/3/30 4:24, Alan Stern wrote: > > >On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > > > >>>Also, bear in mind that the proposed patch does not give userspace a > > >>>way to power off ports via usbfs. What the new code does is a > > >>>power-off reset -- it turns off power to the port, waits a short time, > > >>>and then turns power back on. > > >> > > >>I think we need two separate IOCTLs: turn off the port power and turn it > > >>on. Then we get the manual port power off for our QA testing, distros > > >>can make interesting policies about manually powering off ports, and > > >>userspace can choose how long they want the port to be off. After all, > > >>different devices may need a longer powered-off period than others. > > > > > >Or one port-power IOCTL that takes the setting as an argument. Yes, > > >this would be more flexible than a power-off reset. > > Hi Alan & Sarah: > > I just recall why I put power off and power on in one ioctl. > > At first, I also tried to make power on and power off into two ioctls. > > But I found after powering off a device, the usbfs device node will > > be removed and so can't power on the port via the same usbfs node. > > > > For this point, we should add usbfs node for usb port? > > No. I agree that we shouldn't add more usbfs files without thinking very carefully about it, since lots of tools like libusb use them. However, we do need a way to manually power off a port, wait a variable length of time (or perhaps for a distro-specific event like screen unblank), and turn the port on. So how do we turn the port power back on with the options we have? Would userspace have to turn the port power off via usbfs, and then manually back on by setting the port's sysfs power/control to 'on'? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote: > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > > On 2013/3/30 4:24, Alan Stern wrote: > > > >On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > > > > > >>>Also, bear in mind that the proposed patch does not give userspace a > > > >>>way to power off ports via usbfs. What the new code does is a > > > >>>power-off reset -- it turns off power to the port, waits a short time, > > > >>>and then turns power back on. > > > >> > > > >>I think we need two separate IOCTLs: turn off the port power and turn it > > > >>on. Then we get the manual port power off for our QA testing, distros > > > >>can make interesting policies about manually powering off ports, and > > > >>userspace can choose how long they want the port to be off. After all, > > > >>different devices may need a longer powered-off period than others. > > > > > > > >Or one port-power IOCTL that takes the setting as an argument. Yes, > > > >this would be more flexible than a power-off reset. > > > Hi Alan & Sarah: > > > I just recall why I put power off and power on in one ioctl. > > > At first, I also tried to make power on and power off into two ioctls. > > > But I found after powering off a device, the usbfs device node will > > > be removed and so can't power on the port via the same usbfs node. > > > > > > For this point, we should add usbfs node for usb port? > > > > No. > > I agree that we shouldn't add more usbfs files without thinking very > carefully about it, since lots of tools like libusb use them. However, > we do need a way to manually power off a port, wait a variable length of > time (or perhaps for a distro-specific event like screen unblank), and > turn the port on. > > So how do we turn the port power back on with the options we have? > Would userspace have to turn the port power off via usbfs, and then > manually back on by setting the port's sysfs power/control to 'on'? Whatever method we use, it should be the same interface for both on and off, so I would prefer to just use the sysfs one, as usbfs does not represent ports, only USB devices. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] retu-mfd: support also Tahvo
Hi Aaro, On Thu, Mar 07, 2013 at 04:40:18PM +0200, Aaro Koskinen wrote: > 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 > Cc: Samuel Ortiz > --- > drivers/mfd/Kconfig |6 +-- > drivers/mfd/retu-mfd.c | 95 > +++--- > include/linux/mfd/retu.h |8 +++- > 3 files changed, 92 insertions(+), 17 deletions(-) Overall the patch looks good, but could you please adress Felipe's comments on it ? 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 0/5 v3] USB: Kconfig cleanups
On Thu, Apr 04, 2013 at 05:57:23PM +0200, Florian Fainelli wrote: > > 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. This series doesn't apply to my tree at the moment. Can you refresh it based on linux-next and resend it, with Alan's acks added? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, 8 Apr 2013, Greg KH wrote: > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote: > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > > > On 2013/3/30 4:24, Alan Stern wrote: > > > > >On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > > > > > > > >>>Also, bear in mind that the proposed patch does not give userspace a > > > > >>>way to power off ports via usbfs. What the new code does is a > > > > >>>power-off reset -- it turns off power to the port, waits a short > > > > >>>time, > > > > >>>and then turns power back on. > > > > >> > > > > >>I think we need two separate IOCTLs: turn off the port power and turn > > > > >>it > > > > >>on. Then we get the manual port power off for our QA testing, distros > > > > >>can make interesting policies about manually powering off ports, and > > > > >>userspace can choose how long they want the port to be off. After > > > > >>all, > > > > >>different devices may need a longer powered-off period than others. > > > > > > > > > >Or one port-power IOCTL that takes the setting as an argument. Yes, > > > > >this would be more flexible than a power-off reset. > > > > Hi Alan & Sarah: > > > > I just recall why I put power off and power on in one ioctl. > > > > At first, I also tried to make power on and power off into two ioctls. > > > > But I found after powering off a device, the usbfs device node will > > > > be removed and so can't power on the port via the same usbfs node. > > > > > > > > For this point, we should add usbfs node for usb port? > > > > > > No. > > > > I agree that we shouldn't add more usbfs files without thinking very > > carefully about it, since lots of tools like libusb use them. However, > > we do need a way to manually power off a port, wait a variable length of > > time (or perhaps for a distro-specific event like screen unblank), and > > turn the port on. > > > > So how do we turn the port power back on with the options we have? > > Would userspace have to turn the port power off via usbfs, and then > > manually back on by setting the port's sysfs power/control to 'on'? > > Whatever method we use, it should be the same interface for both on > and off, so I would prefer to just use the sysfs one, as usbfs does not > represent ports, only USB devices. There is a way we can do it using the existing usbfs framework. The new ioctls could be sent to the parent hub, instead of the device attached to the port. Rather like USBDEVFS_CLAIM_PORT and USBDEVFS_RELEASE_PORT. 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: xHCI ShortPacket Correct Behaviour
If the xHCI spec is contradictory, please contact xhcisupp...@intel.com. Sarah Sharp On Mon, Apr 01, 2013 at 10:48:35AM +, Ankit wrote: > With respect to latest xHCI spec : > Revision 1.0 > with errata to 8/14/12 > > Page 114: > Note: Consider the case where there are multiple TDs posted for pipe for a > single data transfer and a > Short Packet or other condition on one TD means that the data transfer is > terminated, > and that the subsequent TDs associated with the data transfer are now > invalid. > The xHC may have > read ahead on the Transfer Ring and cached the subsequent TDs. To ensure that > xHC frees any > cached information associated with a pipe in a timely manner (so that it can > reuse the cache space > for other pipes), software shall issue a Set TR Dequeue Pointer Command for > the > pipe when the > data transfer is terminated, vs. waiting for the next data transfer to be > ready > before issuing the > command. > Note: If software issues a Set TR Dequeue Pointer Command that points to a > TRB > that had previously > been partially completed TD, the xHC shall treat that TRB as the first TRB of > the TD. i.e. any prior > state associated with a partially completed TRB is lost. > > Looking at this description, I interpret that when the ShortPacket is > received, > xHC should stop executing the transfer and should wait for the driver for > next > command or doorbell. > > Page 130: > Note: If the xHC receives a short packetShort Packet from a device, then it > shall retire the current TD. If > another TD is defined on the Transfer Ring, the xHC shall advance to it and > begin IN transactions. > > Looking at this description, I interpret that when the ShortPacket is > received, > xHC should discard the current TD and start executing the next TD if > available. > > Page 172: > If a Short Packet is detected during the execution of a multi-TRB TD, the xHC > shall advance to the first > TRB of the next TD or the Enqueue Pointer (i.e.Cycle bit transition), > whichever > is encountered first. > > Looking at this description, I interpret that when the ShortPacket is > received, > xHC should discard the current TD and start executing the next TD if > available. > > These descriptions are contradictory. > > Which is the correct xHCI behavior when ShortPacket is received? > -Ankit > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
On Mon, 8 Apr 2013, victor yeo wrote: > Hi, > > >> Now i insmod g_file_storage gadget with file=/mnt/sd/backing_file, the > >> SCSI_READ_10 command is still not working properly. > > > > What makes you think that? > > Because the SCSI_READ_10 is able to read the MBR from the backing > file, and after that, SCSI_READ_10 reads all zeroes (fails to read > boot sector). 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)? > >> g_file_storage gadget: ep0-setup, length 8: > >> : 80 06 00 01 00 00 40 00 > >> g_file_storage gadget: get device descriptor > > > > But something is definitely wrong here. Before sending this > > Get-Device-Descriptor request, the host should have done a USB port > > reset. Either the host isn't performing the reset correctly or else > > your UDC driver didn't inform g_file_storage when the reset occurred. > > Yes, the UDC driver didn't inform g_file_storage when the reset > occurred. What is to be done to inform g_file_storage when the reset > occurs? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/6] USB: EHCI multiplatform for 3.10
On Tue, Apr 02, 2013 at 06:23:58PM +0200, Arnd Bergmann wrote: > Hi Greg, > > Here are the EHCI patches that I think are good for inclusion in 3.10, > I hope you are willing to include them after the debacle over these > patches in 3.9. > > The patches are all logically independent but sorted by priority, > so decide for yourself how many you want to take, starting at the > first one. The first six patches all have an Ack from Alan Stern > and from the respective ARM platform maintainers. I don't see an ACK for the 6th patch from Alan, any reason for that? I've applied the first 5 for now, if you want the 6th one applied, please resend. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, 8 Apr 2013, Lan Tianyu wrote: > Hi Alan: > I think current code can't achieve that power off port(whose > child device was already suspended but it was not powered off due to > NO_POWER_OFF flag setting.) via clearing NO_POWER_OFF flag. Because > at that moment, its usage count can't be 0. At last, it should be > 1 or large. port's pm_runtime_idle will not be called. > > Further thinking, now we call pm_runtime_put_sync() in the > usb_port_suspend() when persist enable, do_remote_wakeup disable and > PM Qos NO_POWER_OFF flag cleared. But PM Qos NO_POWER_OFF flag will > also will be checked in the usb_port_runtime_suspend(). This seems > redundant. > > From my opinion, the PM Qos check in the usb_port_suspend() > should be removed and port usage count will reach 0 when persist enable > and remote_wakeup disable. Whether power off or not totally depends on > the PM Qos flag in the usb_port_runtime_suspend(). For NO_POWER_OFF flag > setting case during usb device being suspend, the port's usage count > will be 0 but its runtime status is still active due to flag being set > and usb_port_runtime_suspend() returns -EAGAIN. At this time, clearing > the flag and the port can be powered off. Does this make sense? Yes, that's the right thing to do. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/6] USB: EHCI multiplatform for 3.10
On Mon, 8 Apr 2013, Greg KH wrote: > On Tue, Apr 02, 2013 at 06:23:58PM +0200, Arnd Bergmann wrote: > > Hi Greg, > > > > Here are the EHCI patches that I think are good for inclusion in 3.10, > > I hope you are willing to include them after the debacle over these > > patches in 3.9. > > > > The patches are all logically independent but sorted by priority, > > so decide for yourself how many you want to take, starting at the > > first one. The first six patches all have an Ack from Alan Stern > > and from the respective ARM platform maintainers. > > I don't see an ACK for the 6th patch from Alan, any reason for that? The last patch was different from all the others. It changed ohci-hcd, not ehci-hcd. I haven't had time yet to go through it in detail; lots of other things on my plate. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/21] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Benoit Cousson [130408 05:11]: > Hi Tony, > > On 04/05/2013 05:43 PM, Tony Lindgren wrote: > > * Benoit Cousson [130405 03:00]: > >> On 04/05/2013 10:30 AM, Benoit Cousson wrote: > >> > >> ... > >> > ARM: dts: OMAP4: Add HS USB Host IP nodes > ARM: dts: OMAP3: Add HS USB Host IP nodes > ARM: dts: omap3-beagle: Add USB Host support > >>> > >>> These 3 DTS patches are good to me, but I cannot applied them on top of > >>> the already existing patches I queued for 3.10. > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > >>> for_3.10/dts > >>> > >>> Could you rebase these 3 ones only, and I will applied them. > >> > >> Mmm, in fact, I've just seen the pull request from Tony :-( > >> > >> > >> Tony, > >> > >> Don't you want to remove these DTS patches from the pull-request? > > > > Oops sorry :( Looks like I applied them mistakenly as I saved all > > the patches into a mbox, then applied it. Anyways, too late to start > > messing with it now. > > > >> Otherwise, I will have to rebase the whole DTS series on top of yours. > >> That being said, if the branch is not supposed to be rebased, it is doable. > > > > I pulled in your for_3.10/dts for testing, and to me it looks like > > it's just overlapping additions. So that should be OK to resolve while > > pulling it in. > > > > It seems there's no need to add omap-for-v3.10/usb as a dependency for > > your for_3.10/dts unless the conflict gets non-trivial with some > > additional patches. > > The branch was not complete, with the latest additions, we do have > conflict due to the addition of several new nodes at the same place. OK > The resolution is not that hard since it is addition of node only, but > the rebase on to of omap-for-v3.10/usb will avoid the issue. > > I have a new pre-merged branch available. for_3.10/dts_merged is based > on omap-for-v3.10/usb and Paul's omap-devel-b-for-3.10 branch to get the > AM33xx hwmod. > Paul's branch is just needed to avoid AM33xx regression introduced by > Santosh hwmod changes present in my branch. > > Just let me know which one you will prefer to pull. If the merge conflicts are non-trivial, then let's do the pre-merged branch. That will be easier to test also in this case for am33xx. 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 V5 0/6] USB: EHCI multiplatform for 3.10
On Monday 08 April 2013, Greg KH wrote: > On Tue, Apr 02, 2013 at 06:23:58PM +0200, Arnd Bergmann wrote: > > Hi Greg, > > > > Here are the EHCI patches that I think are good for inclusion in 3.10, > > I hope you are willing to include them after the debacle over these > > patches in 3.9. > > > > The patches are all logically independent but sorted by priority, > > so decide for yourself how many you want to take, starting at the > > first one. The first six patches all have an Ack from Alan Stern > > and from the respective ARM platform maintainers. > > I don't see an ACK for the 6th patch from Alan, any reason for that? > > I've applied the first 5 for now, if you want the 6th one applied, > please resend. Thanks a lot! I had mentioned the fact that the last one is missing the ack in my email, maybe not prominently enough when I wrote: > > * The final patch is from me and still waiting for an Ack from Alan > > Stern, so please wait for his feedback before applying that one. It would be nice to get that in, but it's not as important for 3.10 since the only conflict between backends I expect is between Exynos and SPEAr. SPEAr is not widely used for all I can tell, and whether Exynos actually makes the multiplatform conversion is still an open question, since there are a number of missing patches and we are about to close the window for arm-soc patches as well. In 3.11, things will look quite different. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with xHCI, uvcvideo driver, and "Unknown event condition, HC probably busted"
Hi Ryan, I'm the xHCI driver author. It helps if you Cc maintainers (listed in the MAINTAINERS file), otherwise emails do get lost: http://lxr.linux.no/#linux/MAINTAINERS Comments below. On Tue, Mar 26, 2013 at 02:55:48PM -0700, Ryan Press wrote: > I'm working to get the 3.9-rc1 kernel working on the Globalscale > Mirabox > http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx. > The PCIe driver by Thomas Petazzoni is not in mainline yet but I have > his latest patch; this is required for the FL1009 host controller. > > I have everything mostly working. A USB 3.0 SSD works great, I tested > un-buffered speed at 120 MB/s. I am trying to get a USB 2.0 video > capture device working and I'm running into problems. So far I have > tested using the uvcvideo and stk1160. They both fail with "xhci_hcd > :02:00.0: ERROR Unknown event condition, HC probably busted", > although the uvcvideo device does work for perhaps a minute with > smooth video. Sometimes it resets the host controller and the > attached SSD goes offline. > > On a different ARM box running 3.8-rc1 kernel the stk1160 is known > working, albeit it has only a USB 2.0 host controller. So I don't > suspect this driver necessarily. I don't suppose you have a different USB 3.0 host controller to attach the camera to? > Below is my dmesg log. I would think the PCIe driver could be the > problem but because the USB 3.0 SSD works perfectly I'm not sure this > is the case. Does anyone have insight into what's going on? The dmesg looks worrisome. It looks like something is wrong with the xHCI driver after the endpoint rings are expanded: > xhci_hcd :02:00.0: ERROR no room on ep ring, try ring expansion > xhci_hcd :02:00.0: ring expansion succeed, now has 4 segments > xhci_hcd :02:00.0: Miss service interval error, set skip flag > ... > xhci_hcd :02:00.0: Miss service interval error, set skip flag > xhci_hcd :02:00.0: overrun event on endpoint > xhci_hcd :02:00.0: Overrun Event for slot 2 ep 2 still with TDs queued? > xhci_hcd :02:00.0: All tds on the ep_ring skipped. Clear skip flag. > xhci_hcd :02:00.0: ERROR Unknown event condition, HC probably busted > xhci_hcd :02:00.0: Miss service interval error, set skip flag > ... I'm concerned that the ring dequeue pointer somehow got out of sync with the hardware dequeue pointer here. > xhci_hcd :02:00.0: Miss service interval error, set skip flag > xhci_hcd :02:00.0: overrun event on endpoint > xhci_hcd :02:00.0: Overrun Event for slot 2 ep 2 still with TDs queued? > xhci_hcd :02:00.0: All tds on the ep_ring skipped. Clear skip flag. > xhci_hcd :02:00.0: ERROR Unknown event condition, HC probably busted That error will only print when there's a vendor-specific error code, or some other completion code that the xHCI driver doesn't understand. > xhci_hcd :02:00.0: ep 0x87 - asked for 16 bytes, 7 bytes untransferred > usb 3-2: Driver uses different interval (8 microframes) than xHCI (128 > microframes) > xhci_hcd :02:00.0: Miss service interval error, set skip flag > xhci_hcd :02:00.0: Found td. Clear skip flag. > xhci_hcd :02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD This error code may be due to a short packet (we have a known issue with the Linux xHCI driver not properly handing extra events for short packets on xHCI 1.0 hosts), or it may indicate the ring expansion was causing issues, or it may indicate the device was just suspended. > xhci_hcd :02:00.0: Miss service interval error, set skip flag > xhci_hcd :02:00.0: ERROR Unknown event condition, HC probably busted > xhci_hcd :02:00.0: Found td. Clear skip flag. > xhci_hcd :02:00.0: Miss service interval error, set skip flag > ... > xhci_hcd :02:00.0: Miss service interval error, set skip flag > xhci_hcd :02:00.0: overrun event on endpoint > xhci_hcd :02:00.0: Overrun Event for slot 2 ep 2 still with TDs queued? > xhci_hcd :02:00.0: All tds on the ep_ring skipped. Clear skip flag. > xhci_hcd :02:00.0: ERROR Unknown event condition, HC probably busted > xhci_hcd :02:00.0: ep 0x87 - asked for 16 bytes, 9 bytes untransferred > usb 3-2: Driver uses different interval (8 microframes) than xHCI (128 > microframes) > ... > xhci_hcd :02:00.0: URB transfer length is wrong, xHC issue? req. > len = 97920, act. len = 4294965524 I wonder if you're running into the event transfer length issue that was fixed in recent 3.9 kernels: commit 1c11a172cb30492f5f6a82c6e118fdcd9946c34f Author: Vivek Gautam Date: Thu Mar 21 12:06:48 2013 +0530 usb: xhci: Fix TRB transfer length macro used for Event TRB. Use proper macro while extracting TRB transfer length from Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23) for the same, and use it instead of TRB_LEN (bits 0:16) in case of event TRBs. This patch should be backported to kernels as old as 2.6.31, that
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, Apr 08, 2013 at 09:01:44AM -0700, Greg KH wrote: > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote: > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > > > Hi Alan & Sarah: > > > > I just recall why I put power off and power on in one ioctl. > > > > At first, I also tried to make power on and power off into two ioctls. > > > > But I found after powering off a device, the usbfs device node will > > > > be removed and so can't power on the port via the same usbfs node. > > > > > > > > For this point, we should add usbfs node for usb port? > > > > > > No. > > > > I agree that we shouldn't add more usbfs files without thinking very > > carefully about it, since lots of tools like libusb use them. However, > > we do need a way to manually power off a port, wait a variable length of > > time (or perhaps for a distro-specific event like screen unblank), and > > turn the port on. > > > > So how do we turn the port power back on with the options we have? > > Would userspace have to turn the port power off via usbfs, and then > > manually back on by setting the port's sysfs power/control to 'on'? > > Whatever method we use, it should be the same interface for both on > and off, so I would prefer to just use the sysfs one, as usbfs does not > represent ports, only USB devices. I would prefer that as well. However, the port power sysfs file power/control is created by the runtime PM core, and I think it doesn't have a way to manually turn power off. All we get with the current framework is 'on' or 'auto'. There may be times when userspace wants to override the kernel's policy for 'auto' and force a port power off. Perhaps the runtime PM core needs to be extended to have a way to allow userspace to manually force a device into a lower power state? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
Cc-ing the linux-pm list and some Intel power devs, as I think this specific discussion could benefit from a broader audience. On Mon, Apr 08, 2013 at 12:33:00PM -0400, Alan Stern wrote: > On Mon, 8 Apr 2013, Greg KH wrote: > > > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote: > > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > > > > On 2013/3/30 4:24, Alan Stern wrote: > > > > > >On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > > > Hi Alan & Sarah: > > > > > I just recall why I put power off and power on in one ioctl. > > > > > At first, I also tried to make power on and power off into two ioctls. > > > > > But I found after powering off a device, the usbfs device node will > > > > > be removed and so can't power on the port via the same usbfs node. > > > > > > > > > > For this point, we should add usbfs node for usb port? > > > > > > > > No. > > > > > > I agree that we shouldn't add more usbfs files without thinking very > > > carefully about it, since lots of tools like libusb use them. However, > > > we do need a way to manually power off a port, wait a variable length of > > > time (or perhaps for a distro-specific event like screen unblank), and > > > turn the port on. > > > > > > So how do we turn the port power back on with the options we have? > > > Would userspace have to turn the port power off via usbfs, and then > > > manually back on by setting the port's sysfs power/control to 'on'? > > > > Whatever method we use, it should be the same interface for both on > > and off, so I would prefer to just use the sysfs one, as usbfs does not > > represent ports, only USB devices. > > There is a way we can do it using the existing usbfs framework. The > new ioctls could be sent to the parent hub, instead of the device > attached to the port. Rather like USBDEVFS_CLAIM_PORT and > USBDEVFS_RELEASE_PORT. That could work. However, we have to think about future platform power changes as well. Coming up with a USB specific way to work around the runtime PM core will hurt us in the long run, if we end up having to change the runtime PM core for another kernel user. Len, Rafael, and Kristen, is there a need from any of the future power work to have an 'off' mechanism added to the runtime PM core, so that power/control would have 'on', 'auto', and 'off' options? It currently only has 'on' and 'auto'. The kernel is always going to be more conservative about what policies cause the 'auto' option to turn off USB ports. A Linux distro may want to override those policies and force the port off, or power off a misbehaving device for a hard reset. That's why we need an 'off' extension to power/control to bypass the runtime PM usage counts and power something off. Are there analogous needs for other users of power/control? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v3] USB: Kconfig cleanups
Le 08/04/2013 18:32, Greg KH a écrit : On Thu, Apr 04, 2013 at 05:57:23PM +0200, Florian Fainelli wrote: 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. This series doesn't apply to my tree at the moment. Can you refresh it based on linux-next and resend it, with Alan's acks added? Sure, it was based on usb-next, I will refresh that, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v3] USB: Kconfig cleanups
On Mon, Apr 08, 2013 at 08:16:46PM +0200, Florian Fainelli wrote: > Le 08/04/2013 18:32, Greg KH a écrit : > >On Thu, Apr 04, 2013 at 05:57:23PM +0200, Florian Fainelli wrote: > >> > >>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. > > > >This series doesn't apply to my tree at the moment. Can you refresh it > >based on linux-next and resend it, with Alan's acks added? > > Sure, it was based on usb-next, I will refresh that, thanks! usb-next is best, sorry, I didn't realize that. That's what I need to apply it to, but it didn't work due to changes in the gadget tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] net: cdc_ncm: demote "unexpected notification" to debug level
Receiving unhandled notifications is most certainly not an error and should not be logged as one. Knowing that the device sends notifications we don't handle is useful for developers, but there is very little a user can do about this. The message is therefore just annoying noise to most users with devices sending unhandled notifications like e.g. USB_CDC_NOTIFY_RESPONSE_AVAILABLE Cc: Alexey Orishko Signed-off-by: Bjørn Mork --- drivers/net/usb/cdc_ncm.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 44a989c..67012cb 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -1124,8 +1124,9 @@ static void cdc_ncm_status(struct usbnet *dev, struct urb *urb) break; default: - dev_err(&dev->udev->dev, "NCM: unexpected " - "notification 0x%02x!\n", event->bNotificationType); + dev_dbg(&dev->udev->dev, + "NCM: unexpected notification 0x%02x!\n", + event->bNotificationType); break; } } -- 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 2/4] usb: introduce usb force power off mechanism
On Monday, April 08, 2013 10:33:54 AM Sarah Sharp wrote: > On Mon, Apr 08, 2013 at 09:01:44AM -0700, Greg KH wrote: > > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote: > > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > > > > Hi Alan & Sarah: > > > > > I just recall why I put power off and power on in one ioctl. > > > > > At first, I also tried to make power on and power off into two ioctls. > > > > > But I found after powering off a device, the usbfs device node will > > > > > be removed and so can't power on the port via the same usbfs node. > > > > > > > > > > For this point, we should add usbfs node for usb port? > > > > > > > > No. > > > > > > I agree that we shouldn't add more usbfs files without thinking very > > > carefully about it, since lots of tools like libusb use them. However, > > > we do need a way to manually power off a port, wait a variable length of > > > time (or perhaps for a distro-specific event like screen unblank), and > > > turn the port on. > > > > > > So how do we turn the port power back on with the options we have? > > > Would userspace have to turn the port power off via usbfs, and then > > > manually back on by setting the port's sysfs power/control to 'on'? > > > > Whatever method we use, it should be the same interface for both on > > and off, so I would prefer to just use the sysfs one, as usbfs does not > > represent ports, only USB devices. > > I would prefer that as well. However, the port power sysfs file > power/control is created by the runtime PM core, and I think it doesn't > have a way to manually turn power off. All we get with the current > framework is 'on' or 'auto'. There may be times when userspace wants to > override the kernel's policy for 'auto' and force a port power off. > > Perhaps the runtime PM core needs to be extended to have a way to allow > userspace to manually force a device into a lower power state? We actually considered that when the PM core's runtime PM framework was being implemented and the answer was "no". The reason being that user space has no idea whether or not the device *can* be turned off at the given time, so the kernel can't guarantee any requests to turn devices off to be satisfied at any given time. I believe this is the case for USB ports too. I don't think anything has changed in that respect since then. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, 8 Apr 2013, Sarah Sharp wrote: > That could work. However, we have to think about future platform power > changes as well. Coming up with a USB specific way to work around the > runtime PM core will hurt us in the long run, if we end up having to > change the runtime PM core for another kernel user. > > Len, Rafael, and Kristen, is there a need from any of the future power > work to have an 'off' mechanism added to the runtime PM core, so that > power/control would have 'on', 'auto', and 'off' options? It currently > only has 'on' and 'auto'. I can't say anything about future power work -- Len, Rafael, et al. will have to speak to that -- but the current design of the runtime PM core doesn't allow for a distinction between "low power" and "no power". As far as the core is concerned, either the device is fully active or else it isn't (i.e., it is suspended). To change this would be a major rewrite. > The kernel is always going to be more conservative about what policies > cause the 'auto' option to turn off USB ports. A Linux distro may want > to override those policies and force the port off, or power off a > misbehaving device for a hard reset. That's why we need an 'off' > extension to power/control to bypass the runtime PM usage counts and > power something off. > > Are there analogous needs for other users of power/control? In fact, some other people have made similar requests. I can't remember the exact contexts now... One of them may have been related to the PCI D4cold stuff. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Monday, April 08, 2013 10:55:19 AM Sarah Sharp wrote: > Cc-ing the linux-pm list and some Intel power devs, as I think this > specific discussion could benefit from a broader audience. > > On Mon, Apr 08, 2013 at 12:33:00PM -0400, Alan Stern wrote: > > On Mon, 8 Apr 2013, Greg KH wrote: > > > > > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote: > > > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > > > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > > > > > On 2013/3/30 4:24, Alan Stern wrote: > > > > > > >On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > > > > Hi Alan & Sarah: > > > > > > I just recall why I put power off and power on in one ioctl. > > > > > > At first, I also tried to make power on and power off into two > > > > > > ioctls. > > > > > > But I found after powering off a device, the usbfs device node will > > > > > > be removed and so can't power on the port via the same usbfs node. > > > > > > > > > > > > For this point, we should add usbfs node for usb port? > > > > > > > > > > No. > > > > > > > > I agree that we shouldn't add more usbfs files without thinking very > > > > carefully about it, since lots of tools like libusb use them. However, > > > > we do need a way to manually power off a port, wait a variable length of > > > > time (or perhaps for a distro-specific event like screen unblank), and > > > > turn the port on. > > > > > > > > So how do we turn the port power back on with the options we have? > > > > Would userspace have to turn the port power off via usbfs, and then > > > > manually back on by setting the port's sysfs power/control to 'on'? > > > > > > Whatever method we use, it should be the same interface for both on > > > and off, so I would prefer to just use the sysfs one, as usbfs does not > > > represent ports, only USB devices. > > > > There is a way we can do it using the existing usbfs framework. The > > new ioctls could be sent to the parent hub, instead of the device > > attached to the port. Rather like USBDEVFS_CLAIM_PORT and > > USBDEVFS_RELEASE_PORT. > > That could work. However, we have to think about future platform power > changes as well. Coming up with a USB specific way to work around the > runtime PM core will hurt us in the long run, if we end up having to > change the runtime PM core for another kernel user. > > Len, Rafael, and Kristen, is there a need from any of the future power > work to have an 'off' mechanism added to the runtime PM core, so that > power/control would have 'on', 'auto', and 'off' options? It currently > only has 'on' and 'auto'. There's no such work for the reason given in another message a while ago. > The kernel is always going to be more conservative about what policies > cause the 'auto' option to turn off USB ports. A Linux distro may want > to override those policies and force the port off, or power off a > misbehaving device for a hard reset. That's why we need an 'off' > extension to power/control to bypass the runtime PM usage counts and > power something off. Then please make it USB-specific. Although I believe it would be dangerous, too, if used without care (say, for a storage device attached via USB). I *think* it might be better to have a "force power cycle" interface for USB ports that would be clearly named and documented so that there's no confusion as to what it is for. > Are there analogous needs for other users of power/control? No, there aren't. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, Apr 08, 2013 at 09:39:07PM +0200, Rafael J. Wysocki wrote: > On Monday, April 08, 2013 10:55:19 AM Sarah Sharp wrote: > > Cc-ing the linux-pm list and some Intel power devs, as I think this > > specific discussion could benefit from a broader audience. > > > > On Mon, Apr 08, 2013 at 12:33:00PM -0400, Alan Stern wrote: > > > On Mon, 8 Apr 2013, Greg KH wrote: > > > > > > > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote: > > > > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote: > > > > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote: > > > > > > > On 2013/3/30 4:24, Alan Stern wrote: > > > > > > > >On Fri, 29 Mar 2013, Sarah Sharp wrote: > > > > > > > Hi Alan & Sarah: > > > > > > > I just recall why I put power off and power on in one ioctl. > > > > > > > At first, I also tried to make power on and power off into two > > > > > > > ioctls. > > > > > > > But I found after powering off a device, the usbfs device node > > > > > > > will > > > > > > > be removed and so can't power on the port via the same usbfs node. > > > > > > > > > > > > > > For this point, we should add usbfs node for usb port? > > > > > > > > > > > > No. > > > > > > > > > > I agree that we shouldn't add more usbfs files without thinking very > > > > > carefully about it, since lots of tools like libusb use them. > > > > > However, > > > > > we do need a way to manually power off a port, wait a variable length > > > > > of > > > > > time (or perhaps for a distro-specific event like screen unblank), and > > > > > turn the port on. > > > > > > > > > > So how do we turn the port power back on with the options we have? > > > > > Would userspace have to turn the port power off via usbfs, and then > > > > > manually back on by setting the port's sysfs power/control to 'on'? > > > > > > > > Whatever method we use, it should be the same interface for both on > > > > and off, so I would prefer to just use the sysfs one, as usbfs does not > > > > represent ports, only USB devices. > > > > > > There is a way we can do it using the existing usbfs framework. The > > > new ioctls could be sent to the parent hub, instead of the device > > > attached to the port. Rather like USBDEVFS_CLAIM_PORT and > > > USBDEVFS_RELEASE_PORT. > > > > That could work. However, we have to think about future platform power > > changes as well. Coming up with a USB specific way to work around the > > runtime PM core will hurt us in the long run, if we end up having to > > change the runtime PM core for another kernel user. > > > > Len, Rafael, and Kristen, is there a need from any of the future power > > work to have an 'off' mechanism added to the runtime PM core, so that > > power/control would have 'on', 'auto', and 'off' options? It currently > > only has 'on' and 'auto'. > > There's no such work for the reason given in another message a while ago. > > > The kernel is always going to be more conservative about what policies > > cause the 'auto' option to turn off USB ports. A Linux distro may want > > to override those policies and force the port off, or power off a > > misbehaving device for a hard reset. That's why we need an 'off' > > extension to power/control to bypass the runtime PM usage counts and > > power something off. > > Then please make it USB-specific. Although I believe it would be > dangerous, too, if used without care (say, for a storage device attached > via USB). All right, then let's make this USB specific. Alan's idea of making the ioctls bind to the parent hub makes sense. And yes, userspace will have to take care about which ports it powers off. I think we currently expose enough information about what devices are attached to which ports to allow Linux distros to make smart decisions about what to allow to be powered off. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: cdc_ncm: demote "unexpected notification" to debug level
From: Bjørn Mork Date: Mon, 8 Apr 2013 20:26:23 +0200 > Receiving unhandled notifications is most certainly not an error > and should not be logged as one. Knowing that the device sends > notifications we don't handle is useful for developers, but there > is very little a user can do about this. The message is therefore > just annoying noise to most users with devices sending unhandled > notifications like e.g. USB_CDC_NOTIFY_RESPONSE_AVAILABLE > > Cc: Alexey Orishko > Signed-off-by: Bjørn Mork Applied. -- 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
USB to SPI driver for MCP2210
Hello! 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 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 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. * 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. * 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.) I'm not yet settled on the exact mechanism, format, etc. for this "device information" on the EEPROM, but between this and what the driver knows it must specify unambiguously what devices are connected to what CS pins, how to talk to them (timings, etc.). So once we know what we're connected to and how to talk to it, we can do our SPI probe. While I anticipate this to work great for my stuff, it would be absurd to impose this schema on somebody else using this chip (with the original vendor/product id or not). Thus, I'm not sure how to go about coding the MCP2210 driver as an abstract interface to take care of the details of this device, accepting an external configuration during the USB probe and exposing what is actually needed to other drivers (or *cringe* userspace), rending the code both attractive and reusable. Here are the things I've thought of: 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! 2. Create my own abstract x to SPI bridge API (or "KPI") and then implement my MCP2210 driver as a provider for said API -- not a very attractive option for my expertise level! Not that I can't do it, I just question how attractive it will be for to others to use. :) 3. Write the MCP2210 driver code as a generic C library used to *create* other drivers, but not create a specific MCP2210 driver, and then implement my driver using the generic MCP2210 driver library. Obviously, by far, option 1 would be the best! Also, I'm intentionally ignoring userspace options via generic-hid (there is already a user-space library for using this chip -- https://github.com/kerrydwong/MCP2210-Library). If somebody strongly feels that there's merit to doing this from userspace, please speak up. :) Other options, opinions and/or advice would be greatly appreciated! Thanks, Daniel Santos -- 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 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-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... 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 v2 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...
Suggested-by: Alan Stern
Signed-off-by: Sergei Shtylyov
---
Changes since the original posting:
- changed init() method to pre_setup() with different parameters abd call site.
drivers/usb/host/ehci-platform.c |6 ++
include/linux/usb/ehci_pdriver.h |3 +++
2 files changed, 9 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,8 @@
#ifndef __USB_CORE_EHCI_PDRIVER_H
#define __USB_CORE_EHCI_PDRIVER_H
+#include
+
/**
* struct usb_ehci_pdata - platform_data for generic ehci driver
*
@@ -50,6 +52,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 v2 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'.
Signed-off-by: Sergei Shtylyov
---
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 | 15 +++
1 file changed, 15 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
@@ -446,10 +446,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 v2 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).
Signed-off-by: Sergei Shtylyov
---
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
Re: [PATCH v2 2/9] ehci-platform: add pre_setup() method to platform data
On Tue, Apr 09, 2013 at 01:20:00AM +0400, Sergei Shtylyov 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
> Signed-off-by: Sergei Shtylyov
>
> ---
> Changes since the original posting:
> - changed init() method to pre_setup() with different parameters abd call
> site.
>
> drivers/usb/host/ehci-platform.c |6 ++
> include/linux/usb/ehci_pdriver.h |3 +++
> 2 files changed, 9 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,8 @@
> #ifndef __USB_CORE_EHCI_PDRIVER_H
> #define __USB_CORE_EHCI_PDRIVER_H
>
> +#include
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...)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 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
---
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
@@ -405,11 +405,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 v2 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...
Signed-off-by: Sergei Shtylyov
---
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
@@ -401,7 +401,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
#include
-/* 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 v2 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 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
---
include/linux/usb/rcar-phy.h | 39 +++
1 file changed, 39 insertions(+)
Index: renesas/include/linux/usb/rcar-phy.h
===
--- /dev/null
+++ renesas/include/linux/usb/rcar-phy.h
@@ -0,0 +1,39 @@
+/*
+ * 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
+
+/* 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 v2 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...
Signed-off-by: Sergei Shtylyov
---
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
#include
#include
+#include
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
@@ -407,13 +407,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;
@@ -585,7 +578,6 @@ static struct platform_device *r8a7779_d
&scif5_device,
&tmu00_device,
&tmu01_device,
- &usb_phy_device,
};
static struct platform_device *r8a7779_standard_devices[] __initdata = {
@@ -620,6 +612,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 v2 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.
Signed-off-by: Sergei Shtylyov
---
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
+ * 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
#include
-#include
#include
#include
#include
+#include
+#include
/* 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
Re: [PATCH v2 2/9] ehci-platform: add pre_setup() method to platform data
Hello. On 04/09/2013 01:26 AM, 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 Signed-off-by: Sergei Shtylyov [...] 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 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. 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 v2 2/9] ehci-platform: add pre_setup() method to platform data
On 04/09/2013 01:51 AM, Sergei Shtylyov wrote: Hello. On 04/09/2013 01:26 AM, 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 Signed-off-by: Sergei Shtylyov [...] 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 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. :-) 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, Apr 09, 2013 at 01:51:08AM +0400, Sergei Shtylyov wrote: > Hello. > > On 04/09/2013 01:26 AM, 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 > >>Signed-off-by: Sergei Shtylyov > >> > [...] > >>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 > >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. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Pull Request] xHCI misc cleanup patches for 3.10
The following changes since commit 505bdbc79d20f8f2a56c02498f079bb23b0ef756: USB: driver.c: processing failure, maching resume condition with suspend condition (2013-04-01 12:32:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-next-2012-04-08 for you to fetch changes up to 58b1d7999e15e61f314c2ff746ffb9dd8e07eba6: xhci - clarify compliance mode debug messages (2013-04-08 08:42:58 -0700) xHCI misc cleanup patches for 3.10 Hi Greg, Here's three cleanup patches for 3.10. Nothing big here, just some debugging output changes, a macro rename, and a math macro change that should have no behavioral effects. Tested on the Intel Panther Point xHCI host, with USB storage and mouse, with xHCI debugging turned on. I don't have the TI host that causes the debugging output changes to trigger. Sarah Sharp David Howells (2): xhci: Use ilog2() rather than __ffs() for calculating SEGMENT_SHIFT xhci: Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.h Tony Camuso (1): xhci - clarify compliance mode debug messages drivers/usb/host/xhci-mem.c | 16 drivers/usb/host/xhci.c | 14 +- drivers/usb/host/xhci.h |4 ++-- 3 files changed, 19 insertions(+), 15 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] xhci: Use ilog2() rather than __ffs() for calculating SEGMENT_SHIFT
From: David Howells
Use ilog2() rather than __ffs() for calculating SEGMENT_SHIFT as ilog2() can
be worked out at compile time, whereas __ffs() must be calculated at runtime.
Signed-off-by: David Howells
cc: Sarah Sharp
cc: Greg Kroah-Hartman
cc: linux-usb@vger.kernel.org
Signed-off-by: Sarah Sharp
---
drivers/usb/host/xhci.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 6358271..ca550dd 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1239,7 +1239,7 @@ union xhci_trb {
/* Allow two commands + a link TRB, along with any reserved command TRBs */
#define MAX_RSVD_CMD_TRBS (TRBS_PER_SEGMENT - 3)
#define SEGMENT_SIZE (TRBS_PER_SEGMENT*16)
-#define SEGMENT_SHIFT (__ffs(SEGMENT_SIZE))
+#define SEGMENT_SHIFT (ilog2(SEGMENT_SIZE))
/* TRB buffer pointers can't cross 64KB boundaries */
#define TRB_MAX_BUFF_SHIFT 16
#define TRB_MAX_BUFF_SIZE (1 << TRB_MAX_BUFF_SHIFT)
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] xhci: Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.h
From: David Howells
Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.h.
Signed-off-by: David Howells
cc: Sarah Sharp
cc: Greg Kroah-Hartman
cc: linux-usb@vger.kernel.org
Signed-off-by: Sarah Sharp
---
drivers/usb/host/xhci-mem.c | 16
drivers/usb/host/xhci.h |4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 6dc238c..965b539 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -51,7 +51,7 @@ static struct xhci_segment *xhci_segment_alloc(struct
xhci_hcd *xhci,
return NULL;
}
- memset(seg->trbs, 0, SEGMENT_SIZE);
+ memset(seg->trbs, 0, TRB_SEGMENT_SIZE);
/* If the cycle state is 0, set the cycle bit to 1 for all the TRBs */
if (cycle_state == 0) {
for (i = 0; i < TRBS_PER_SEGMENT; i++)
@@ -467,7 +467,7 @@ struct xhci_ring *xhci_dma_to_transfer_ring(
{
if (ep->ep_state & EP_HAS_STREAMS)
return radix_tree_lookup(&ep->stream_info->trb_address_map,
- address >> SEGMENT_SHIFT);
+ address >> TRB_SEGMENT_SHIFT);
return ep->ring;
}
@@ -478,7 +478,7 @@ static struct xhci_ring *dma_to_stream_ring(
u64 address)
{
return radix_tree_lookup(&stream_info->trb_address_map,
- address >> SEGMENT_SHIFT);
+ address >> TRB_SEGMENT_SHIFT);
}
#endif /* CONFIG_USB_XHCI_HCD_DEBUGGING */
@@ -514,7 +514,7 @@ static int xhci_test_radix_tree(struct xhci_hcd *xhci,
cur_ring = stream_info->stream_rings[cur_stream];
for (addr = cur_ring->first_seg->dma;
- addr < cur_ring->first_seg->dma + SEGMENT_SIZE;
+ addr < cur_ring->first_seg->dma +
TRB_SEGMENT_SIZE;
addr += trb_size) {
mapped_ring = dma_to_stream_ring(stream_info, addr);
if (cur_ring != mapped_ring) {
@@ -662,7 +662,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct
xhci_hcd *xhci,
cur_stream, (unsigned long long) addr);
key = (unsigned long)
- (cur_ring->first_seg->dma >> SEGMENT_SHIFT);
+ (cur_ring->first_seg->dma >> TRB_SEGMENT_SHIFT);
ret = radix_tree_insert(&stream_info->trb_address_map,
key, cur_ring);
if (ret) {
@@ -693,7 +693,7 @@ cleanup_rings:
if (cur_ring) {
addr = cur_ring->first_seg->dma;
radix_tree_delete(&stream_info->trb_address_map,
- addr >> SEGMENT_SHIFT);
+ addr >> TRB_SEGMENT_SHIFT);
xhci_ring_free(xhci, cur_ring);
stream_info->stream_rings[cur_stream] = NULL;
}
@@ -764,7 +764,7 @@ void xhci_free_stream_info(struct xhci_hcd *xhci,
if (cur_ring) {
addr = cur_ring->first_seg->dma;
radix_tree_delete(&stream_info->trb_address_map,
- addr >> SEGMENT_SHIFT);
+ addr >> TRB_SEGMENT_SHIFT);
xhci_ring_free(xhci, cur_ring);
stream_info->stream_rings[cur_stream] = NULL;
}
@@ -2305,7 +2305,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
* so we pick the greater alignment need.
*/
xhci->segment_pool = dma_pool_create("xHCI ring segments", dev,
- SEGMENT_SIZE, 64, xhci->page_size);
+ TRB_SEGMENT_SIZE, 64, xhci->page_size);
/* See Table 46 and Note on Figure 55 */
xhci->device_pool = dma_pool_create("xHCI input/output contexts", dev,
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index ca550dd..29c978e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1238,8 +1238,8 @@ union xhci_trb {
#define TRBS_PER_SEGMENT 64
/* Allow two commands + a link TRB, along with any reserved command TRBs */
#define MAX_RSVD_CMD_TRBS (TRBS_PER_SEGMENT - 3)
-#define SEGMENT_SIZE (TRBS_PER_SEGMENT*16)
-#define SEGMENT_SHIFT (ilog2(SEGMENT_SIZE))
+#define TRB_SEGMENT_SIZE (TRBS_PER_SEGMENT*16)
+#define TRB_SEGMENT_SHIFT (ilog2(TRB_SEGMENT_SIZE))
/* TRB buffer pointers can't cross 64KB boundaries */
#define TRB_MAX_BUFF_SHIFT 16
#define TRB_MAX_BUFF_SIZE (1 << TRB_MAX_BUFF_SHIFT)
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-
[PATCH 3/3] xhci - clarify compliance mode debug messages
From: Tony Camuso
There are no functional changes in this patch. However, because the
compliance mode timer can be deleted in more than one function, it
seemed expedient to include the function name in the debug strings.
Also limited the use of capitals to the first word in the compliance
mode debug messages, except after a function name where all words
start with lower case, in keeping with the style prevalent elsewhere
in xhci.c.
Signed-off-by: Tony Camuso
Signed-off-by: Sarah Sharp
---
drivers/usb/host/xhci.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5156b72..b4aa79d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -417,9 +417,9 @@ static void compliance_mode_recovery(unsigned long arg)
* Compliance Mode Detected. Letting USB Core
* handle the Warm Reset
*/
- xhci_dbg(xhci, "Compliance Mode Detected->Port %d!\n",
+ xhci_dbg(xhci, "Compliance mode detected->port %d\n",
i + 1);
- xhci_dbg(xhci, "Attempting Recovery routine!\n");
+ xhci_dbg(xhci, "Attempting compliance mode recovery\n");
hcd = xhci->shared_hcd;
if (hcd->state == HC_STATE_SUSPENDED)
@@ -457,7 +457,7 @@ static void compliance_mode_recovery_timer_init(struct
xhci_hcd *xhci)
set_timer_slack(&xhci->comp_mode_recovery_timer,
msecs_to_jiffies(COMP_MODE_RCVRY_MSECS));
add_timer(&xhci->comp_mode_recovery_timer);
- xhci_dbg(xhci, "Compliance Mode Recovery Timer Initialized.\n");
+ xhci_dbg(xhci, "Compliance mode recovery timer initialized\n");
}
/*
@@ -733,8 +733,11 @@ void xhci_stop(struct usb_hcd *hcd)
/* Deleting Compliance Mode Recovery Timer */
if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
- (!(xhci_all_ports_seen_u0(xhci
+ (!(xhci_all_ports_seen_u0(xhci {
del_timer_sync(&xhci->comp_mode_recovery_timer);
+ xhci_dbg(xhci, "%s: compliance mode recovery timer deleted\n",
+ __func__);
+ }
if (xhci->quirks & XHCI_AMD_PLL_FIX)
usb_amd_dev_put();
@@ -930,7 +933,8 @@ int xhci_suspend(struct xhci_hcd *xhci)
if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
(!(xhci_all_ports_seen_u0(xhci {
del_timer_sync(&xhci->comp_mode_recovery_timer);
- xhci_dbg(xhci, "Compliance Mode Recovery Timer Deleted!\n");
+ xhci_dbg(xhci, "%s: compliance mode recovery timer deleted\n",
+ __func__);
}
/* step 5: remove core well power */
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/9] ehci-platform: add pre_setup() method to platform data
Hello. On 04/09/2013 02:07 AM, 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 Signed-off-by: Sergei Shtylyov [...] 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 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! 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] xhci: fix list access before init
On Thu, Apr 04, 2013 at 08:31:26PM +0400, Vladimir Murzin wrote:
> Commits
> 9574323 xHCI: test USB2 software LPM
> b92cc66 xHCI: add aborting command ring function
> introduce useful functions which involves lists manipulations.
>
> If for whatever reason we fall into fail path in xhci_mem_init() we
> may access the lists in xhci_mem_cleanup() before they get
> initialized.
>
> The same init-fail-cleanup case is applicable to bw tables too.
>
> Fix this by moving list initialization code to the beginning of
> xhci_mem_init()
Hmm, in looking at this patch again, I don't think it's wise to fix the
issue with accessing the bandwidth table lists in this manner. What
will happen if someone decides to place more allocation code before the
rh_bw allocation code? I will probably forget why we moved that code
up, and then we'll run into the same bug again.
Moving up the init code for xhci->cancel_cmd_list and
xhci->lpm_failed_devs made sense, since it's allocated as part of the
xhci_hcd structure. However, since rh_bw is dynamically allocated,
xhci_mem_cleanup needs to be able to handle it being NULL.
Instead, I think this patch should fix xhci_mem_cleanup to check for a
NULL rh_bw structure here:
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;
for (j = 0; j < XHCI_MAX_INTERVAL; j++) {
struct list_head *ep = &bwt->interval_bw[j].endpoints;
while (!list_empty(ep))
list_del_init(ep->next);
}
}
for (i = 0; i < num_ports; i++) {
struct xhci_tt_bw_info *tt, *n;
list_for_each_entry_safe(tt, n, &xhci->rh_bw[i].tts, tt_list) {
list_del(&tt->tt_list);
kfree(tt);
}
}
Just skip those two for loops if rh_bw is NULL. Once rh_bw is non-null,
we know xhci_mem_init will have initialized the bandwidth table lists.
So, Sergio, I'm applying your v3 patch to my for-usb-linus-queue branch:
http://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/log/?h=for-usb-linus-queue
Vladimir, please use that branch to create a new patch that fixes
xhci_mem_cleanup.
That way you both get a patch in. :)
Sarah Sharp
>
> Reported-by: Sergey Dyasly
> Tested-by: Sergey Dyasly
> Signed-off-by: Vladimir Murzin
> ---
> drivers/usb/host/xhci-mem.c | 37 -
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 6dc238c..7b5d2f5 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -2123,7 +2123,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd
> *xhci, gfp_t flags)
> __le32 __iomem *addr;
> u32 offset;
> unsigned int num_ports;
> - int i, j, port_index;
> + int i, port_index;
>
> addr = &xhci->cap_regs->hcc_params;
> offset = XHCI_HCC_EXT_CAPS(xhci_readl(xhci, addr));
> @@ -2138,18 +2138,6 @@ static int xhci_setup_port_arrays(struct xhci_hcd
> *xhci, gfp_t flags)
> if (!xhci->port_array)
> return -ENOMEM;
>
> - xhci->rh_bw = kzalloc(sizeof(*xhci->rh_bw)*num_ports, flags);
> - if (!xhci->rh_bw)
> - return -ENOMEM;
> - for (i = 0; i < num_ports; i++) {
> - struct xhci_interval_bw_table *bw_table;
> -
> - INIT_LIST_HEAD(&xhci->rh_bw[i].tts);
> - bw_table = &xhci->rh_bw[i].bw_table;
> - for (j = 0; j < XHCI_MAX_INTERVAL; j++)
> - INIT_LIST_HEAD(&bw_table->interval_bw[j].endpoints);
> - }
> -
> /*
>* For whatever reason, the first capability offset is from the
>* capability register base, not from the HCCPARAMS register.
> @@ -2253,7 +2241,25 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
> u64 val_64;
> struct xhci_segment *seg;
> u32 page_size, temp;
> - int i;
> + int i, j, num_ports;
> +
> + INIT_LIST_HEAD(&xhci->cancel_cmd_list);
> + INIT_LIST_HEAD(&xhci->lpm_failed_devs);
> +
> + num_ports = HCS_MAX_PORTS(xhci_readl(xhci,
> &xhci->cap_regs->hcs_params1));
> +
> + xhci->rh_bw = kzalloc(sizeof(*xhci->rh_bw)*num_ports, flags);
> + if (!xhci->rh_bw)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_ports; i++) {
> + struct xhci_interval_bw_table *bw_table;
> +
> + INIT_LIST_HEAD(&xhci->rh_bw[i].tts);
> + bw_table = &xhci->rh_bw[i].bw_table;
> + for (j = 0; j < XHCI_MAX_INTERVAL; j++)
> + INIT_LIST_HEAD(&bw_table->interval_bw[j].endpoints);
> + }
>
> page_size = xhci_readl(xhci, &xhci->op_regs->page_size);
> xhci_dbg(xhci, "Supported page size register = 0x%x\n", page_size
Re: USB3.0 Interrupt transfer in u-boot
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 mailto: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: Fwd: USB2 isochronous camera not working on USB3 port
Hi Jean-Philippe, On Monday 08 April 2013 14:08:09 jean-philippe francois wrote: > 2013/4/8 Laurent Pinchart : > > On Wednesday 06 March 2013 14:21:14 jean-philippe francois wrote: > >> Hi, > >> > >> The company I work for is doing USB cameras, for which I wrote the > >> drivers (out of tree). > > > > Just out of curiosity, was there any shortcoming in the UVC specification > > that pushed your company to implementing a vendor protocol ? > > The main shortcoming in retrospect IMO is the absence of any raw format. > However this shortcoming was not the main force behind going with our > own protocol. > - when we started (on windows) around 2002 we were not aware of UVC. > - when I started to develop a driver for the linux kernel, there was > no UVC stack. > > However the reason we did not switch to an UVC firmware is that our > streaming processor (Cypress FX2LP) hasn't the capability to inspect and > edit the video coming from the sensor to inject the necessary start and end > code. Thank you for the information. I've heard about that issue before. AFAIK, that's why (some versions of) the Apple iSight camera isn't UVC-compliant. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xhci: fix list access before init
On Mon, Apr 08, 2013 at 03:53:19PM -0700, Sarah Sharp wrote:
> On Thu, Apr 04, 2013 at 08:31:26PM +0400, Vladimir Murzin wrote:
> > Commits
> > 9574323 xHCI: test USB2 software LPM
> > b92cc66 xHCI: add aborting command ring function
> > introduce useful functions which involves lists manipulations.
> >
> > If for whatever reason we fall into fail path in xhci_mem_init() we
> > may access the lists in xhci_mem_cleanup() before they get
> > initialized.
> >
> > The same init-fail-cleanup case is applicable to bw tables too.
> >
> > Fix this by moving list initialization code to the beginning of
> > xhci_mem_init()
>
> Hmm, in looking at this patch again, I don't think it's wise to fix the
> issue with accessing the bandwidth table lists in this manner. What
> will happen if someone decides to place more allocation code before the
> rh_bw allocation code? I will probably forget why we moved that code
> up, and then we'll run into the same bug again.
>
> Moving up the init code for xhci->cancel_cmd_list and
> xhci->lpm_failed_devs made sense, since it's allocated as part of the
> xhci_hcd structure. However, since rh_bw is dynamically allocated,
> xhci_mem_cleanup needs to be able to handle it being NULL.
>
> Instead, I think this patch should fix xhci_mem_cleanup to check for a
> NULL rh_bw structure here:
>
> 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;
> for (j = 0; j < XHCI_MAX_INTERVAL; j++) {
> struct list_head *ep = &bwt->interval_bw[j].endpoints;
> while (!list_empty(ep))
> list_del_init(ep->next);
> }
> }
>
> for (i = 0; i < num_ports; i++) {
> struct xhci_tt_bw_info *tt, *n;
> list_for_each_entry_safe(tt, n, &xhci->rh_bw[i].tts, tt_list)
> {
> list_del(&tt->tt_list);
> kfree(tt);
> }
> }
>
> Just skip those two for loops if rh_bw is NULL. Once rh_bw is non-null,
> we know xhci_mem_init will have initialized the bandwidth table lists.
>
> So, Sergio, I'm applying your v3 patch to my for-usb-linus-queue branch:
>
> http://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/log/?h=for-usb-linus-queue
>
> Vladimir, please use that branch to create a new patch that fixes
> xhci_mem_cleanup.
>
> That way you both get a patch in. :)
Cool!
Thanks, Sarah! :)
Regards,
Sergio
>
> Sarah Sharp
>
> >
> > Reported-by: Sergey Dyasly
> > Tested-by: Sergey Dyasly
> > Signed-off-by: Vladimir Murzin
> > ---
> > drivers/usb/host/xhci-mem.c | 37 -
> > 1 file changed, 20 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> > index 6dc238c..7b5d2f5 100644
> > --- a/drivers/usb/host/xhci-mem.c
> > +++ b/drivers/usb/host/xhci-mem.c
> > @@ -2123,7 +2123,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd
> > *xhci, gfp_t flags)
> > __le32 __iomem *addr;
> > u32 offset;
> > unsigned int num_ports;
> > - int i, j, port_index;
> > + int i, port_index;
> >
> > addr = &xhci->cap_regs->hcc_params;
> > offset = XHCI_HCC_EXT_CAPS(xhci_readl(xhci, addr));
> > @@ -2138,18 +2138,6 @@ static int xhci_setup_port_arrays(struct xhci_hcd
> > *xhci, gfp_t flags)
> > if (!xhci->port_array)
> > return -ENOMEM;
> >
> > - xhci->rh_bw = kzalloc(sizeof(*xhci->rh_bw)*num_ports, flags);
> > - if (!xhci->rh_bw)
> > - return -ENOMEM;
> > - for (i = 0; i < num_ports; i++) {
> > - struct xhci_interval_bw_table *bw_table;
> > -
> > - INIT_LIST_HEAD(&xhci->rh_bw[i].tts);
> > - bw_table = &xhci->rh_bw[i].bw_table;
> > - for (j = 0; j < XHCI_MAX_INTERVAL; j++)
> > - INIT_LIST_HEAD(&bw_table->interval_bw[j].endpoints);
> > - }
> > -
> > /*
> > * For whatever reason, the first capability offset is from the
> > * capability register base, not from the HCCPARAMS register.
> > @@ -2253,7 +2241,25 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
> > u64 val_64;
> > struct xhci_segment *seg;
> > u32 page_size, temp;
> > - int i;
> > + int i, j, num_ports;
> > +
> > + INIT_LIST_HEAD(&xhci->cancel_cmd_list);
> > + INIT_LIST_HEAD(&xhci->lpm_failed_devs);
> > +
> > + num_ports = HCS_MAX_PORTS(xhci_readl(xhci,
> > &xhci->cap_regs->hcs_params1));
> > +
> > + xhci->rh_bw = kzalloc(sizeof(*xhci->rh_bw)*num_ports, flags);
> > + if (!xhci->rh_bw)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < num_ports; i++) {
> > + struct xhci_interval_bw_table *bw_table;
> > +
> > + INIT_LIST_HEAD(&xhci->rh_bw[i].tts);
> > + bw_table = &xhci->rh_bw[i].bw_table;
> > +
Re: [PATCH v2 2/9] ehci-platform: add pre_setup() method to platform data
On Tue, Apr 09, 2013 at 02:04:56AM +0400, Sergei Shtylyov wrote: > On 04/09/2013 01:51 AM, Sergei Shtylyov wrote: > >Hello. > > > >On 04/09/2013 01:26 AM, 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 > >>>Signed-off-by: Sergei Shtylyov > >>> > >[...] > >>>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 > >>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. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pull Request] xHCI misc cleanup patches for 3.10
On Mon, Apr 08, 2013 at 03:09:04PM -0700, Sarah Sharp wrote: > The following changes since commit 505bdbc79d20f8f2a56c02498f079bb23b0ef756: > > USB: driver.c: processing failure, maching resume condition with suspend > condition (2013-04-01 12:32:43 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git > for-usb-next-2012-04-08 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi Mylene, On Mon, Apr 8, 2013 at 10:41 AM, Mylene Josserand wrote: > Hi everyone, > > > I need some help to understand how USB is configured. > > I am updating an old kernel (2.6.32 !) to the version 3.8.2. I am > self-taught on Linux kernel so, sometimes, I need the help of the > community to understand it :) > The SoC is a IMX27. For the USB side, we have a NXP ISP1504. > > 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 I can reproduce it here as well on a mx27pdk. I thought the issue could be due to the conversion to the common clock framework, but then I tested a 3.2 kernel and I got the same behavior. Adding Sascha /Eric/Javier, in case they have recently tried USB host on mx27 recently. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: xhci-dbg: Display endpoint number and direction in context dump
When CONFIG_XHCI_HCD_DEBUGGING is activated, the XHCI driver can dump
device and input contexts to the console. The endpoint contexts in that
dump are labeled "Endpoint N Context", where N is the XHCI endpoint
index (DCI - 1). This can be very confusing, especially for people who
are not that familiar with the XHCI specification. This patch introduces
an xhci_get_endpoint_address function (as a counterpart to the reverse
xhci_get_endpoint_index), and uses it to additionally display the
endpoint number and direction when dumping contexts, which are much more
commonly used concepts in USB.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-dbg.c | 5 -
drivers/usb/host/xhci.c | 10 ++
drivers/usb/host/xhci.h | 1 +
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 5f3a7c7..16a8272 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -503,11 +503,14 @@ static void xhci_dbg_ep_ctx(struct xhci_hcd *xhci,
if (last_ep < 31)
last_ep_ctx = last_ep + 1;
for (i = 0; i < last_ep_ctx; ++i) {
+ unsigned int epaddr = xhci_get_endpoint_address(i);
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci, ctx, i);
dma_addr_t dma = ctx->dma +
((unsigned long)ep_ctx - (unsigned long)ctx->bytes);
- xhci_dbg(xhci, "Endpoint %02d Context:\n", i);
+ xhci_dbg(xhci, "Endpoint %02d %s Context (index %02d):\n",
+ epaddr & USB_ENDPOINT_NUMBER_MASK,
+ usb_endpoint_out(epaddr) ? "OUT" : "IN", i);
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - ep_info\n",
&ep_ctx->ep_info,
(unsigned long long)dma, ep_ctx->ep_info);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 53b8f89..3a3ac92 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1107,6 +1107,16 @@ unsigned int xhci_get_endpoint_index(struct
usb_endpoint_descriptor *desc)
return index;
}
+/* The reverse operation to xhci_get_endpoint_index. Calculate the USB endpoint
+ * address from the XHCI endpoint index.
+ */
+unsigned int xhci_get_endpoint_address(unsigned int ep_index)
+{
+ unsigned int number = DIV_ROUND_UP(ep_index, 2);
+ unsigned int direction = ep_index % 2 ? USB_DIR_OUT : USB_DIR_IN;
+ return direction | number;
+}
+
/* Find the flag for this endpoint (for use in the control context). Use the
* endpoint index to create a bitmask. The slot context is bit 0, endpoint 0
is
* bit 1, etc.
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 6358271..555e911 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1641,6 +1641,7 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd
*xhci, struct usb_device *ud
void xhci_copy_ep0_dequeue_into_input_ctx(struct xhci_hcd *xhci,
struct usb_device *udev);
unsigned int xhci_get_endpoint_index(struct usb_endpoint_descriptor *desc);
+unsigned int xhci_get_endpoint_address(unsigned int ep_index);
unsigned int xhci_get_endpoint_flag(struct usb_endpoint_descriptor *desc);
unsigned int xhci_get_endpoint_flag_from_index(unsigned int ep_index);
unsigned int xhci_last_valid_endpoint(u32 added_ctxs);
--
1.7.12.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: 答复: Re: 【PATCH】USB：add new zte 3g-dongle's pid to option.c
On Tue, Apr 09, 2013 at 09:23:08AM +0800, li.ru...@zte.com.cn wrote: > > Dear Greg, > No need, this information only let your know what kernel and source path > name i have used. I do not need that, you should always send me a patch against the latest development kernel version, I can't do anything with patches made against older kernel releases. And please do not send HTML email, it gets deleted by the mailing lists. Are you going to fix up this patch and resend it? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 答复: Re: 答复: Re: 【PATCH】USB：add new zte 3g-dongle's pid to option.c
On Tue, Apr 09, 2013 at 10:22:17AM +0800, li.ru...@zte.com.cn wrote: > > Hi， > I give your the patch is base on the kernel： > > linux-next: next-20130405 > > > when 2013-04-07 > > Now it up to next-20130408 Again, I do not need to know that at all. Do you see others sending patches with that information in their patches? > You mean i need to resend ？ Please go re-read my response, I included a number of things that needed to be fixed in order for the patch to be accepted. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Crash in dwc3 driver on module unload
Hi Felipe,
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?
--
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
Re: USB3.0 Interrupt transfer in u-boot
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 mailto: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: USB to SPI driver for MCP2210
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. 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: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
Hi >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" > [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 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
