Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
On 14/06/13 08:47, Tony Lindgren wrote: > * Kishon Vijay Abraham I [130613 22:41]: >> Hi, >> >> On Thursday 13 June 2013 06:35 PM, Tomi Valkeinen wrote: >>> Hi, >>> >>> On 28/05/13 08:18, Kishon Vijay Abraham I wrote: Hi Tony, On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote: > In order for controllers to get PHY in case of non dt boot, the phy > binding information (phy label) should be added in the platform > data of the controller. This series would be needed to get MUSB working in OMAP3 boards for non-dt boot case. Do you think this is good enough to go in this rc cycle? >>> >>> Did this or some other solution go forward? I'm still unable to boot >>> with usb-gadget-ethernet with v3.10-rc5. >> >> No. I think Tony is ok to take this only during next merge window. > > Yes I'll apply them to omap-for-v3.11/fixes-non-critical. We really > should have basic functionaly tested and working always before the > merge window so we only need to do minimal fixes during the -rc cycle. I'm mostly interested in the USB gadget ethernet for the boards I have, but if I'm not mistaken, all USB gadget support for many OMAP boards is broken in v3.10. Shouldn't that be fixed, no matter if it's a minimal fix or not? Or is there some other, more minimal, way to fix this? Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Fri, Jun 14, 2013 at 09:53:52AM +0800, Ming Lei wrote: > On Fri, Jun 14, 2013 at 8:35 AM, Greg Kroah-Hartman > wrote: > > On Thu, Jun 13, 2013 at 03:41:17PM -0400, Alan Stern wrote: > >> On Thu, 13 Jun 2013, Greg Kroah-Hartman wrote: > >> > >> > On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote: > >> > > On Thu, 13 Jun 2013, Ming Lei wrote: > >> > > > >> > > > - using interrupt threaded handler(default) > >> > > > 33.440 MB/sec > >> > > > > >> > > > - using tasklet(#undef USB_HCD_THREADED_IRQ) > >> > > > 34.29 MB/sec > >> > > > > >> > > > - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c ) > >> > > > 34.260 MB/s > >> > > > > >> > > > > >> > > > So looks usb mass storage performance loss can be observed with > >> > > > interrupt threaded handler because one mass storage read/write > >> > > > sectors > >> > > > requires at least 3 interrupts which wake up usb-storage thread 3 > >> > > > times > >> > > > (each interrupt wakeup the usb-storage each time), introducing irq > >> > > > threaded > >> > > > handler will make 2 threads to be waken up about 6 times for one > >> > > > read/write. > >> > > > > >> > > > I think usb mass storage transfer handler need to be rewritten, > >> > > > otherwise > >> > > > it may become worsen after using irq threaded handler in USB 3.0.(the > >> > > > above device can reach >120MB/sec with hardware handler or tasklet > >> > > > handler, > >> > > > which means about ~3K interrupts/sec, so ~6K contexts switch in case > >> > > > of > >> > > > using irq threaded handler) > >> > > > > >> > > > So how about supporting tasklet first, then convert to interrupt > >> > > > threaded handler > >> > > > after usb mass storage transfer is rewritten without performance > >> > > > loss? > >> > > > (rewriting > >> > > > usb mass storage transfer handler may need some time and work since > >> > > > storage > >> > > > stability/correctness is extremely important, :-) > >> > > > >> > > Maybe we should simply copy what the networking people do. They are > >> > > very concerned about performance and latency; whatever technique they > >> > > use should be good for USB too. > >> > > >> > Yes, but for "old-style" usb-storage, is this really a big deal? We are > >> > still easily hitting the "line-speed" of USB for usb-storage with simple > >> > machines, the bottlenecks that I'm seeing are in the devices themselves, > >> > and then in the USB wire speed. > >> > >> What about with USB-3 storage devices? Many of them still use the > >> bulk-only transport instead of UAS. They may push the limits up. > > > > Are they really? Have we seen that happen yet? With the number's I've > > Yes, the device I am testing is bulk-only, no uas support , and it is very > popular in market. > > > seen published, we are easily serving up enough data to keep the pipe > > full, but that all depends on your CPU / host controller. > > > >> > Once hardware comes out that uses USB streams, and we get device support > >> > for the UAS protocol, then we might have a need to change things, but at > >> > this point in time, for the "old" driver, I think we are fine. > >> > > >> > Unless someone has a workload / benchmark that shows otherwise? > >> > >> The test results above show a 2.4% degradation for threaded interrupts > >> as compared to tasklets. That's in addition to the bottlenecks caused > >> by the device; no doubt it would be worse for a faster device. This > >> result calls into question the benefits of threaded interrupts. > >> > >> The main reason for moving away from the current scheme is to reduce > >> latency for other interrupt handlers. Ming gave two examples of slow > >> USB code that runs in hardirq context now; with his change they would > >> run in softirq context and therefore wouldn't delay other interrupts so > >> much. (Interrupt latency is hard to measure, however.) > > > > Yes, I know that people keep wanting to worry about latency issues, and > > the best answer for them has always been, "don't use USB." :) > > I think we can do it better, why don't do it? :-) Because of other issues, that have been brought up here already. But if you can do it without affecting others, that's fine. > > You suffer throughput issues with predicitable latency dependancies, so > > This patchset don't cause throughout degradation but decrease latency much, > also has other advantages. Like what? > > we need to be careful we don't slow down the 99% of the systems out > > there that do not care about this at all. > > Considered great amount of ARM devices in market, I think we need to > consider the problem on these devices, :-) Is it a problem on those devices? I think they have host controller issues that are way bigger problems than this device driver, right? 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/majo
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
* Kishon Vijay Abraham I [130613 22:41]: > Hi, > > On Thursday 13 June 2013 06:35 PM, Tomi Valkeinen wrote: > >Hi, > > > >On 28/05/13 08:18, Kishon Vijay Abraham I wrote: > >>Hi Tony, > >> > >>On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote: > >>>In order for controllers to get PHY in case of non dt boot, the phy > >>>binding information (phy label) should be added in the platform > >>>data of the controller. > >> > >>This series would be needed to get MUSB working in OMAP3 boards for > >>non-dt boot case. Do you think this is good enough to go in this rc cycle? > > > >Did this or some other solution go forward? I'm still unable to boot > >with usb-gadget-ethernet with v3.10-rc5. > > No. I think Tony is ok to take this only during next merge window. Yes I'll apply them to omap-for-v3.11/fixes-non-critical. We really should have basic functionaly tested and working always before the merge window so we only need to do minimal fixes during the -rc cycle. 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: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
Hi, On Thursday 13 June 2013 06:35 PM, Tomi Valkeinen wrote: Hi, On 28/05/13 08:18, Kishon Vijay Abraham I wrote: Hi Tony, On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy label) should be added in the platform data of the controller. This series would be needed to get MUSB working in OMAP3 boards for non-dt boot case. Do you think this is good enough to go in this rc cycle? Did this or some other solution go forward? I'm still unable to boot with usb-gadget-ethernet with v3.10-rc5. No. I think Tony is ok to take this only during next merge window. 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] extcon: Add an API to get extcon device from dt node
On 06/12/2013 03:55 PM, Kishon Vijay Abraham I wrote:
> Hi Chanwoo Choi,
>
> On Wednesday 12 June 2013 07:09 AM, Chanwoo Choi wrote:
>> From: Kishon Vijay Abraham I
>>
>> Added an API of_extcon_get_extcon_dev() to be used by drivers to get
>> extcon device in the case of dt boot (this can be used instead of
>> extcon_get_extcon_dev()).
>>
>> Signed-off-by: Kishon Vijay Abraham I
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Myungjoo Ham
>> ---
>> drivers/extcon/Makefile | 3 +++
>> drivers/extcon/of-extcon.c | 56
>>
>> include/linux/extcon/of-extcon.h | 30 +
>> 3 files changed, 89 insertions(+)
>> create mode 100644 drivers/extcon/of-extcon.c
>> create mode 100644 include/linux/extcon/of-extcon.h
>>
>> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
>> index 540e2c3..39cdf95 100644
>> --- a/drivers/extcon/Makefile
>> +++ b/drivers/extcon/Makefile
>> @@ -2,9 +2,12 @@
>> # Makefile for external connector class (extcon) devices
>> #
>>
>> +obj-$(CONFIG_OF)+= of-extcon.o
>> +
>> obj-$(CONFIG_EXTCON)+= extcon-class.o
>> obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
>> obj-$(CONFIG_EXTCON_ADC_JACK)+= extcon-adc-jack.o
>> +
>> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
>> obj-$(CONFIG_EXTCON_MAX8997)+= extcon-max8997.o
>> obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-arizona.o
>> diff --git a/drivers/extcon/of-extcon.c b/drivers/extcon/of-extcon.c
>> new file mode 100644
>> index 000..29f82b4
>> --- /dev/null
>> +++ b/drivers/extcon/of-extcon.c
>> @@ -0,0 +1,56 @@
>> +/*
>> + * OF helpers for External connector (extcon) framework
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + * Kishon Vijay Abraham I
>> + *
>> + * Copyright (C) 2013 Samsung Electronics
>> + * Chanwoo Choi
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
>> +{
>> +struct device_node *node;
>> +struct extcon_dev *edev;
>> +struct platform_device *extcon_parent_dev;
>> +
>> +if (!dev->of_node) {
>> +dev_dbg(dev, "device does not have a device node entry\n");
>> +return ERR_PTR(-EINVAL);
>> +}
>> +
>> +node = of_parse_phandle(dev->of_node, "extcon", index);
>> +if (!node) {
>> +dev_dbg(dev, "failed to get phandle in %s node\n",
>> +dev->of_node->full_name);
>> +return ERR_PTR(-ENODEV);
>> +}
>> +
>> +extcon_parent_dev = of_find_device_by_node(node);
>> +if (!extcon_parent_dev) {
>> +dev_dbg(dev, "unable to find device by node\n");
>> +return ERR_PTR(-EPROBE_DEFER);
>> +}
>> +
>> +edev = extcon_get_extcon_dev(dev_name(&extcon_parent_dev->dev));
>
> In order to get this working, I needed a small fix in extcon_dev_register
>
> - dev_set_name(edev->dev, edev->name ? edev->name : dev_name(dev));
> + edev->name = edev->name ? edev->name : dev_name(dev);
> + dev_set_name(edev->dev, edev->name);
>
OK, I added it on this patch.
> Also using extcon_get_extcon_dev here requires the extcon driver not to set
> edev.name since we use *dev_name* here. Hence I recommend using my initial
> class iterative approach. Anyway its your call. Let me know if have to float
> a new version of the patch (either the iterative approach or having the fix I
> mentioned in extcon_dev_register).
I prefer to imprement "of_extcon_get_extcon_dev()" separately from extcon core.
I will resend modified patch with your comment of extcon_dev_register() at once.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Fri, Jun 14, 2013 at 3:41 AM, Alan Stern wrote: > > The main reason for moving away from the current scheme is to reduce > latency for other interrupt handlers. Ming gave two examples of slow > USB code that runs in hardirq context now; with his change they would > run in softirq context and therefore wouldn't delay other interrupts so > much. (Interrupt latency is hard to measure, however.) With the two trace points of irq_handler_entry and irq_handler_exit, the interrupt latency(or the time taken by hard irq handler) isn't hard to measure. One simple script can figure out the average/maximum latency for one irq handler, like I did in 4/4. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe 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: DWC3: Event Interrupt Mask issue
On Thu, Jun 13, 2013 at 10:20:53PM +0800, Felipe Balbi wrote: > Hi, > > On Thu, Jun 13, 2013 at 08:26:12PM +0800, Huang Rui wrote: > > > > I was reading dwc3 codes and found that during the process of > > > > configuring event buffer (dwc3_event_buffers_setup), it only write the > > > > size of the buffer and doesn't write interrupt mask bit into GEVNTSIZ > > > > register like below, > > > > > > > > dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n), > > > > evt->length & 0x); > > > > > > > > But in spec, it suggests that write this bit to prevent the interrupt > > > > from being generated in an event buffer configuration. So need we set > > > > > > where does it say that ? I just re-read details about that bit and all > > > it says is that it can be used to mask the interrupt, but events will > > > still be queued. Maybe I'm missing some part. Which revision of the > > > databook are you reading ? > > > > Thanks a lot to look back into this issue. I read version 2.50a, in > > section 8.2.2, the step 3 to configure an Event Buffer describes: > > > > "Writes the size of the buffer and interrupt mask into GEVNTSIZn. > > Depending on your system interrupt latency, enough Event Buffer space > > must be allocated to avoid lost interrupts or reduced performance." > > > > If I misunderstood, please correct me. > > but we are writing Interrupt mask bit, just always writing 0 :-) > You're right. :) > > > Anyway, we don't really need that bit right now because linux will only > > > enable the IRQ line after request_*irq() has been called and we're > > > setting up our event buffers before calling that. > > > > > > > Yeah, when the event buffers are set up, it must not encounter any > > interrupts. > > right. > > > > OTOH, we could use that bit as means to get rid of IRQF_ONESHOT from > > > DWC3 driver. > > > > > > > Thanks to teach me. The IRQF_ONESHOT interrupt should also prevent the > > other interrupts until the current thread has been run, just like the > > function of interrupt mask bit, am I right? > > that's correct. IRQ subsystem makes sure to keep IRQs masked until > thread has finished running. > > > > Can you test a patch for me ? I don't have access to HW right now. I > > > assume the patch below works fine, does it ? > > > > > > > Sorry, I haven't got the board yet. Your patch looks good, and I will > > test it as soon as I get HW. > > alright, so it's likely that I'll get access to my stuff back before. > Anyway, if you happen to have time, I'd be glad to see a Tested-by, > always good to test on more than a single platform. With my pleasure if I get board at that time. Best Regards, Rui -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, Jun 13, 2013 at 10:54 PM, Alan Stern wrote: > > Maybe we should simply copy what the networking people do. They are > very concerned about performance and latency; whatever technique they > use should be good for USB too. Most of net devices don't use interrupt threaded handler, looks we need to copy that first, :-) $git grep -n request_threaded_irq drivers/net/ | wc -l 9 $git grep -n request_threaded_irq drivers/net/wireless | wc -l 5 Also 5 of 9 using interrupt threaded handler are wireless network devices, which are a bit slow, and only one ethernet driver uses it. So I plan to use tasklet first, then we can switch to interrupt threaded handler in the future if mass storage devices are OK with it. If no one objects to use tasklet, I will post out the v1 patch for review later. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe 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 V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
On Fri, Jun 14, 2013 at 9:31 AM, Chao Xie wrote: > On Thu, Jun 13, 2013 at 11:08 PM, Alan Stern > wrote: >> On Thu, 13 Jun 2013, Chao Xie wrote: >> >>> >> These operations sound generic enough to be done at HCD layer, no? So no >>> >> need to >>> >> replicate the same stuff in ohci, ehci, xhci, etc. >>> > >>> > The HCD layer handles suspend and resume only for PCI host controllers. >>> > Not for other types. >>> > >>> > I don't know if the acquire/start and stop/release parts can be moved >>> > into the USB core. Maybe they can. >>> > >>> > Alan Stern >>> > >>> hi >>> The following is my understanding. >>> I think for PHY initialization and shutdown part, it is generic for >>> other parts. >>> PHY initialization need to be called before hc_driver->reset is called. >>> I think it can be added at usb_add_hcd. >>> For PHY shutdown, it can be added at usb_remove_hcd. >> >> Yes, that should work. >> > Fine, i can add a patch for that. My usb phy patches are pending on it. > >>> For suspend/resume, i do not know how to add it. For our EHCI driver, >>> when system goes to deep idle states, we just directly shutdown the >>> hcd and initialize it again when the system goes back. >> >> You shut down the host controller? Then how does it detect wakeup >> events? And how does it know if a device was disconnected while the >> power was off? >> > Hi > I think maybe my suspend/resume is not same as what you think. > The suspend/resume i mean is the peripharal sub system suspend/resume > states. When SOC enter this low power mode, > the clock to usb, power to usb are all shut down. > When the controller is shut down, i think that usb_remove_hcd will > help to remove all the attached devices. > We do not rely on usb host controller to wake up the whole sub system. > If a device is disconnected while the power was off, when the host > controller is powered again, it will do initialization again, and all > the attached devices are susposed be removed already. > > hi I am sorry that i unerstand it wrong. I checked with the code in our 3.4 git. we really did a lot of things when suspend/resume, and at that point the patch for ehci_resume and ehci_suspend are not added. i think the driver can make use of ehci_resume/ehci_suspend. For PHY, we have to initialize it and shutdown it when do suspend/resume. Our PHY do not have any suspend states. I suppose these phy operation have to be handled by each ehci driver owner only, or you think it can be handled at ehci-hce level?. >> Alan Stern >> -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Fri, Jun 14, 2013 at 8:35 AM, Greg Kroah-Hartman wrote: > On Thu, Jun 13, 2013 at 03:41:17PM -0400, Alan Stern wrote: >> On Thu, 13 Jun 2013, Greg Kroah-Hartman wrote: >> >> > On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote: >> > > On Thu, 13 Jun 2013, Ming Lei wrote: >> > > >> > > > - using interrupt threaded handler(default) >> > > > 33.440 MB/sec >> > > > >> > > > - using tasklet(#undef USB_HCD_THREADED_IRQ) >> > > > 34.29 MB/sec >> > > > >> > > > - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c ) >> > > > 34.260 MB/s >> > > > >> > > > >> > > > So looks usb mass storage performance loss can be observed with >> > > > interrupt threaded handler because one mass storage read/write sectors >> > > > requires at least 3 interrupts which wake up usb-storage thread 3 times >> > > > (each interrupt wakeup the usb-storage each time), introducing irq >> > > > threaded >> > > > handler will make 2 threads to be waken up about 6 times for one >> > > > read/write. >> > > > >> > > > I think usb mass storage transfer handler need to be rewritten, >> > > > otherwise >> > > > it may become worsen after using irq threaded handler in USB 3.0.(the >> > > > above device can reach >120MB/sec with hardware handler or tasklet >> > > > handler, >> > > > which means about ~3K interrupts/sec, so ~6K contexts switch in case of >> > > > using irq threaded handler) >> > > > >> > > > So how about supporting tasklet first, then convert to interrupt >> > > > threaded handler >> > > > after usb mass storage transfer is rewritten without performance loss? >> > > > (rewriting >> > > > usb mass storage transfer handler may need some time and work since >> > > > storage >> > > > stability/correctness is extremely important, :-) >> > > >> > > Maybe we should simply copy what the networking people do. They are >> > > very concerned about performance and latency; whatever technique they >> > > use should be good for USB too. >> > >> > Yes, but for "old-style" usb-storage, is this really a big deal? We are >> > still easily hitting the "line-speed" of USB for usb-storage with simple >> > machines, the bottlenecks that I'm seeing are in the devices themselves, >> > and then in the USB wire speed. >> >> What about with USB-3 storage devices? Many of them still use the >> bulk-only transport instead of UAS. They may push the limits up. > > Are they really? Have we seen that happen yet? With the number's I've Yes, the device I am testing is bulk-only, no uas support , and it is very popular in market. > seen published, we are easily serving up enough data to keep the pipe > full, but that all depends on your CPU / host controller. > >> > Once hardware comes out that uses USB streams, and we get device support >> > for the UAS protocol, then we might have a need to change things, but at >> > this point in time, for the "old" driver, I think we are fine. >> > >> > Unless someone has a workload / benchmark that shows otherwise? >> >> The test results above show a 2.4% degradation for threaded interrupts >> as compared to tasklets. That's in addition to the bottlenecks caused >> by the device; no doubt it would be worse for a faster device. This >> result calls into question the benefits of threaded interrupts. >> >> The main reason for moving away from the current scheme is to reduce >> latency for other interrupt handlers. Ming gave two examples of slow >> USB code that runs in hardirq context now; with his change they would >> run in softirq context and therefore wouldn't delay other interrupts so >> much. (Interrupt latency is hard to measure, however.) > > Yes, I know that people keep wanting to worry about latency issues, and > the best answer for them has always been, "don't use USB." :) I think we can do it better, why don't do it? :-) > You suffer throughput issues with predicitable latency dependancies, so This patchset don't cause throughout degradation but decrease latency much, also has other advantages. > we need to be careful we don't slow down the 99% of the systems out > there that do not care about this at all. Considered great amount of ARM devices in market, I think we need to consider the problem on these devices, :-) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Fri, Jun 14, 2013 at 3:41 AM, Alan Stern wrote: > On Thu, 13 Jun 2013, Greg Kroah-Hartman wrote: > >> On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote: >> > On Thu, 13 Jun 2013, Ming Lei wrote: >> > >> > > - using interrupt threaded handler(default) >> > > 33.440 MB/sec >> > > >> > > - using tasklet(#undef USB_HCD_THREADED_IRQ) >> > > 34.29 MB/sec >> > > >> > > - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c ) >> > > 34.260 MB/s >> > > >> > > >> > > So looks usb mass storage performance loss can be observed with >> > > interrupt threaded handler because one mass storage read/write sectors >> > > requires at least 3 interrupts which wake up usb-storage thread 3 times >> > > (each interrupt wakeup the usb-storage each time), introducing irq >> > > threaded >> > > handler will make 2 threads to be waken up about 6 times for one >> > > read/write. >> > > >> > > I think usb mass storage transfer handler need to be rewritten, otherwise >> > > it may become worsen after using irq threaded handler in USB 3.0.(the >> > > above device can reach >120MB/sec with hardware handler or tasklet >> > > handler, >> > > which means about ~3K interrupts/sec, so ~6K contexts switch in case of >> > > using irq threaded handler) >> > > >> > > So how about supporting tasklet first, then convert to interrupt >> > > threaded handler >> > > after usb mass storage transfer is rewritten without performance loss? >> > > (rewriting >> > > usb mass storage transfer handler may need some time and work since >> > > storage >> > > stability/correctness is extremely important, :-) >> > >> > Maybe we should simply copy what the networking people do. They are >> > very concerned about performance and latency; whatever technique they >> > use should be good for USB too. >> >> Yes, but for "old-style" usb-storage, is this really a big deal? We are >> still easily hitting the "line-speed" of USB for usb-storage with simple >> machines, the bottlenecks that I'm seeing are in the devices themselves, >> and then in the USB wire speed. > > What about with USB-3 storage devices? Many of them still use the > bulk-only transport instead of UAS. They may push the limits up. Exactly, my test device(sandisk extreme USB 3.0 16G, 0781:5580) is very popular, which is faster than most USB 3.0 pendrive in market, but the device is bulk-only, and no UAS support, so I guess most of the USB 3.0 pendrive in market still may not support UAS. > >> Once hardware comes out that uses USB streams, and we get device support >> for the UAS protocol, then we might have a need to change things, but at >> this point in time, for the "old" driver, I think we are fine. >> >> Unless someone has a workload / benchmark that shows otherwise? > > The test results above show a 2.4% degradation for threaded interrupts > as compared to tasklets. That's in addition to the bottlenecks caused > by the device; no doubt it would be worse for a faster device. This > result calls into question the benefits of threaded interrupts. If I enable HCD_BH in xhci driver and enable requst_threaded_irq in xhci driver, the degradation becomes >10%, see below test on the same device connected to xhci-hcd: [tom@board]$ps -ax | grep xhci Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html 4896 pts/1S+ 0:00 grep --color=auto xhci [tom@board]$sudo ./ds-msg /dev/sdb 400M 1 4 No. 0, time 121 MB No. 1, time 122 MB No. 2, time 124 MB No. 3, time 122 MB count=4, total=489 ms, average=122.250 MB [tom@board]$ [tom@board]$ps -ax | grep xhci Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html 6037 ?S 0:00 [irq/42-xhci_hcd] 6038 ?S 0:00 [irq/43-xhci_hcd] 6039 ?S 0:00 [irq/44-xhci_hcd] 6040 ?S 0:00 [irq/45-xhci_hcd] 6041 ?S 0:00 [irq/46-xhci_hcd] 6304 pts/1S+ 0:00 grep --color=auto xhci [tom@board]$ [tom@board]$ [tom@board]$sudo ./ds-msg /dev/sdb 400M 1 4 No. 0, time 107 MB No. 1, time 108 MB No. 2, time 108 MB No. 3, time 109 MB count=4, total=432 ms, average=108.000 MB Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe 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 V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
On Thu, Jun 13, 2013 at 11:08 PM, Alan Stern wrote: > On Thu, 13 Jun 2013, Chao Xie wrote: > >> >> These operations sound generic enough to be done at HCD layer, no? So no >> >> need to >> >> replicate the same stuff in ohci, ehci, xhci, etc. >> > >> > The HCD layer handles suspend and resume only for PCI host controllers. >> > Not for other types. >> > >> > I don't know if the acquire/start and stop/release parts can be moved >> > into the USB core. Maybe they can. >> > >> > Alan Stern >> > >> hi >> The following is my understanding. >> I think for PHY initialization and shutdown part, it is generic for >> other parts. >> PHY initialization need to be called before hc_driver->reset is called. >> I think it can be added at usb_add_hcd. >> For PHY shutdown, it can be added at usb_remove_hcd. > > Yes, that should work. > Fine, i can add a patch for that. My usb phy patches are pending on it. >> For suspend/resume, i do not know how to add it. For our EHCI driver, >> when system goes to deep idle states, we just directly shutdown the >> hcd and initialize it again when the system goes back. > > You shut down the host controller? Then how does it detect wakeup > events? And how does it know if a device was disconnected while the > power was off? > Hi I think maybe my suspend/resume is not same as what you think. The suspend/resume i mean is the peripharal sub system suspend/resume states. When SOC enter this low power mode, the clock to usb, power to usb are all shut down. When the controller is shut down, i think that usb_remove_hcd will help to remove all the attached devices. We do not rely on usb host controller to wake up the whole sub system. If a device is disconnected while the power was off, when the host controller is powered again, it will do initialization again, and all the attached devices are susposed be removed already. > 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/3] USB: OMAP: add omap-otg
Hi,
On Fri, Jun 14, 2013 at 01:37:11AM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Jun 12, 2013 at 06:13:26PM +0300, Felipe Balbi wrote:
> > On Mon, Jun 10, 2013 at 01:40:05AM +0300, Aaro Koskinen wrote:
> > > +void omap_otg_set_mode(enum omap_otg_mode mode)
> > > +{
> > > + if (!otg_dev) {
> > > + WARN(1, "%s: controller not present\n", __func__);
> > > + return;
> > > + }
> > > + mutex_lock(&otg_dev->serialize);
> > > + switch (mode) {
> > > + case OMAP_OTG_MODE_DEVICE:
> > > + /*
> > > + * Set B-session valid.
> > > + */
> > > + omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSVLD);
> > > + break;
> > > + case OMAP_OTG_MODE_HOST:
> > > + /*
> > > + * Set A-session valid.
> > > + */
> > > + omap_otg_ctrl(OMAP_OTG_ASESSVLD);
> > > + break;
> > > + case OMAP_OTG_MODE_DISCONNECT:
> > > + /*
> > > + * Set B-session end to indicate no VBUS.
> > > + */
> > > + omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSEND);
> > > + break;
> > > + default:
> > > + WARN(1, "%s: unknown mode: %d\n", __func__, mode);
> > > + }
> > > + mutex_unlock(&otg_dev->serialize);
> > > +}
> > > +EXPORT_SYMBOL_GPL(omap_otg_set_mode);
> >
> > looks like this should provide a extcon interface for its users.
>
> Is there any examples available? Anyway, I'll look into this.
In extcon tree there are some patches from Kishon adding that to
dwc3-omap.c :-)
--
balbi
signature.asc
Description: Digital signature
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Fri, Jun 14, 2013 at 5:09 AM, Alan Stern wrote:
> On Thu, 13 Jun 2013, Steven Rostedt wrote:
>
>> On Thu, 2013-06-13 at 15:41 -0400, Alan Stern wrote:
>>
>> > The test results above show a 2.4% degradation for threaded interrupts
>> > as compared to tasklets. That's in addition to the bottlenecks caused
>> > by the device; no doubt it would be worse for a faster device. This
>> > result calls into question the benefits of threaded interrupts.
>>
>> That's because it was written like a top half and not a full blown
>> interrupt. I just looked at the patch, and saw this:
>>
>> +#ifndef USB_HCD_THREADED_IRQ
>> if (sched) {
>> if (async)
>> tasklet_schedule(&bh->bh);
>> else
>> tasklet_hi_schedule(&bh->bh);
>> }
>> +#else
>> + if (sched)
>> + schedule_work(&hcd->periodic_bh->work);
>> +#endif
>>
>> What is this? The work isn't done by an interrupt thread, but by work queues!
>
> You don't understand the patch. Most of the time, sched will be 0
> here and hence the work queue won't be involved.
>
> Yes, part of the work is done by a work queue rather than the interrupt
> thread. But it is an unimportant part, the part that involves
> transfers to root hubs or transfers that were cancelled. These things
> can complete without any interrupt occurring, so they can't be handled
> by the interrupt thread. However, they are the abnormal case; the
> transfers we care about are not to root hubs and they do complete
> normally.
>
>> The point of the interrupt thread is that you do *all* the work that
>> needs to be done when an interrupt comes in. You don't need to delay the
>> work.
>
> You've got it backward. The patch doesn't leave part of the work
> undone when an interrupt occurs. Rather it's the other way around --
> sometimes work needs to be done when there isn't any interrupt. This
> could happen in a timer callback, or it could happen as a direct result
> of a function call.
>
> Since there doesn't seem to be any way to invoke the interrupt thread
> in the absence of an interrupt, Ming pushed the job off to a work
> queue.
>
>> If you just treat a threaded interrupt like a real interrupt and push
>> off work to something else, then yes, it will degrade performance.
>>
>> If you go the threaded interrupt route, you need to rethink the
>> paradigm. There's no reason that the interrupt handler needs to be fast
>> like it needs to be in true interrupt context. The handler can now use
>> mutexes, and other full features that currently only threads benefit
>> from. It should improve locking issues, and can serialize things if
>> needed.
>>
>> All this patch did was to switch the main irq to a thread and make a
>> bottom half into a work queue.
>
> In case it's not clear, the code you quoted above is part of the
> interrupt handler, not part of the thread.
>
>> Why couldn't you just do:
>>
>> if (sched)
>> usb_giveback_urb_bh(bh);
>>
>> ?
>
> Because usb_giveback_urb_bh() is supposed to run in the context of the
> tasklet or interrupt thread or work queue, not in the context of the
> interrupt handler.
Exactly, the code should have been the below shape:
#ifndef USB_HCD_THREADED_IRQ
..
#else
if (!in_irq()) {
bh = hcd->periodic_bh;
sched = 1;
}
#endif
Then it will be quite clear.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, Jun 13, 2013 at 03:41:17PM -0400, Alan Stern wrote: > On Thu, 13 Jun 2013, Greg Kroah-Hartman wrote: > > > On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote: > > > On Thu, 13 Jun 2013, Ming Lei wrote: > > > > > > > - using interrupt threaded handler(default) > > > > 33.440 MB/sec > > > > > > > > - using tasklet(#undef USB_HCD_THREADED_IRQ) > > > > 34.29 MB/sec > > > > > > > > - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c ) > > > > 34.260 MB/s > > > > > > > > > > > > So looks usb mass storage performance loss can be observed with > > > > interrupt threaded handler because one mass storage read/write sectors > > > > requires at least 3 interrupts which wake up usb-storage thread 3 times > > > > (each interrupt wakeup the usb-storage each time), introducing irq > > > > threaded > > > > handler will make 2 threads to be waken up about 6 times for one > > > > read/write. > > > > > > > > I think usb mass storage transfer handler need to be rewritten, > > > > otherwise > > > > it may become worsen after using irq threaded handler in USB 3.0.(the > > > > above device can reach >120MB/sec with hardware handler or tasklet > > > > handler, > > > > which means about ~3K interrupts/sec, so ~6K contexts switch in case of > > > > using irq threaded handler) > > > > > > > > So how about supporting tasklet first, then convert to interrupt > > > > threaded handler > > > > after usb mass storage transfer is rewritten without performance loss? > > > > (rewriting > > > > usb mass storage transfer handler may need some time and work since > > > > storage > > > > stability/correctness is extremely important, :-) > > > > > > Maybe we should simply copy what the networking people do. They are > > > very concerned about performance and latency; whatever technique they > > > use should be good for USB too. > > > > Yes, but for "old-style" usb-storage, is this really a big deal? We are > > still easily hitting the "line-speed" of USB for usb-storage with simple > > machines, the bottlenecks that I'm seeing are in the devices themselves, > > and then in the USB wire speed. > > What about with USB-3 storage devices? Many of them still use the > bulk-only transport instead of UAS. They may push the limits up. Are they really? Have we seen that happen yet? With the number's I've seen published, we are easily serving up enough data to keep the pipe full, but that all depends on your CPU / host controller. > > Once hardware comes out that uses USB streams, and we get device support > > for the UAS protocol, then we might have a need to change things, but at > > this point in time, for the "old" driver, I think we are fine. > > > > Unless someone has a workload / benchmark that shows otherwise? > > The test results above show a 2.4% degradation for threaded interrupts > as compared to tasklets. That's in addition to the bottlenecks caused > by the device; no doubt it would be worse for a faster device. This > result calls into question the benefits of threaded interrupts. > > The main reason for moving away from the current scheme is to reduce > latency for other interrupt handlers. Ming gave two examples of slow > USB code that runs in hardirq context now; with his change they would > run in softirq context and therefore wouldn't delay other interrupts so > much. (Interrupt latency is hard to measure, however.) Yes, I know that people keep wanting to worry about latency issues, and the best answer for them has always been, "don't use USB." :) You suffer throughput issues with predicitable latency dependancies, so we need to be careful we don't slow down the 99% of the systems out there that do not care about this at all. 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 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, 13 Jun 2013, Steven Rostedt wrote: > I only took a quick look at the second patch. I'm now looking at both > patches applied to the code. I didn't realize this was called from the > top half. > > Usually the top half for threaded interrupts is used just to quite the > interrupt line. Either by acknowledging the interrupt or by disabling > the device from sending more interrupts till the bottom half (thread) > can run. This looks to be doing a bit more than that. Yes, it does. Ming left all the host controller processing in the top half. The bottom half merely handles the completion callbacks. One of the things we discussed during this email thread was the possibility of moving _all_ the work into the threaded handler. That's not as easy to do, though; it requires significant modification of the host controller driver. And each controller driver would need its own modifications, whereas with Ming's approach only the core needs to be changed. > I'll look a bit deeper at the patch, but this still doesn't look like a > typical threaded interrupt usage. I'll agree with that; it isn't typical. Ming claims that the work remaining in the top half often takes less than 20 us on average in his tests. Depending on the particular device, the work in the bottom half can be very quick (little more than waking up a thread in the case of usb-storage) or quite slow (perhaps on the order of a ms or more for the UVC video driver on some ARM platforms). 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/3] USB: OMAP: add omap-otg
Hi,
On Wed, Jun 12, 2013 at 06:13:26PM +0300, Felipe Balbi wrote:
> On Mon, Jun 10, 2013 at 01:40:05AM +0300, Aaro Koskinen wrote:
> > +void omap_otg_set_mode(enum omap_otg_mode mode)
> > +{
> > + if (!otg_dev) {
> > + WARN(1, "%s: controller not present\n", __func__);
> > + return;
> > + }
> > + mutex_lock(&otg_dev->serialize);
> > + switch (mode) {
> > + case OMAP_OTG_MODE_DEVICE:
> > + /*
> > +* Set B-session valid.
> > +*/
> > + omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSVLD);
> > + break;
> > + case OMAP_OTG_MODE_HOST:
> > + /*
> > +* Set A-session valid.
> > +*/
> > + omap_otg_ctrl(OMAP_OTG_ASESSVLD);
> > + break;
> > + case OMAP_OTG_MODE_DISCONNECT:
> > + /*
> > +* Set B-session end to indicate no VBUS.
> > +*/
> > + omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSEND);
> > + break;
> > + default:
> > + WARN(1, "%s: unknown mode: %d\n", __func__, mode);
> > + }
> > + mutex_unlock(&otg_dev->serialize);
> > +}
> > +EXPORT_SYMBOL_GPL(omap_otg_set_mode);
>
> looks like this should provide a extcon interface for its users.
Is there any examples available? Anyway, I'll look into this.
Thanks,
A.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, 2013-06-13 at 17:09 -0400, Alan Stern wrote:
> On Thu, 13 Jun 2013, Steven Rostedt wrote:
>
> > On Thu, 2013-06-13 at 15:41 -0400, Alan Stern wrote:
> >
> > > The test results above show a 2.4% degradation for threaded interrupts
> > > as compared to tasklets. That's in addition to the bottlenecks caused
> > > by the device; no doubt it would be worse for a faster device. This
> > > result calls into question the benefits of threaded interrupts.
> >
> > That's because it was written like a top half and not a full blown
> > interrupt. I just looked at the patch, and saw this:
> >
> > +#ifndef USB_HCD_THREADED_IRQ
> > if (sched) {
> > if (async)
> > tasklet_schedule(&bh->bh);
> > else
> > tasklet_hi_schedule(&bh->bh);
> > }
> > +#else
> > + if (sched)
> > + schedule_work(&hcd->periodic_bh->work);
> > +#endif
> >
> > What is this? The work isn't done by an interrupt thread, but by work
> > queues!
>
> You don't understand the patch.
Hey, I'll admit that I don't understand how USB works ;-)
I also only looked at the second patch without applying it. Thus, a lot
of the changes were out of context for me.
> Most of the time, sched will be 0
> here and hence the work queue won't be involved.
OK, I only compared that current tasklets were being commented out, and
that's pretty much all I had to go on.
>
> Yes, part of the work is done by a work queue rather than the interrupt
> thread. But it is an unimportant part, the part that involves
> transfers to root hubs or transfers that were cancelled. These things
> can complete without any interrupt occurring, so they can't be handled
> by the interrupt thread. However, they are the abnormal case; the
> transfers we care about are not to root hubs and they do complete
> normally.
>
> > The point of the interrupt thread is that you do *all* the work that
> > needs to be done when an interrupt comes in. You don't need to delay the
> > work.
>
> You've got it backward. The patch doesn't leave part of the work
> undone when an interrupt occurs. Rather it's the other way around --
> sometimes work needs to be done when there isn't any interrupt. This
> could happen in a timer callback, or it could happen as a direct result
> of a function call.
>
> Since there doesn't seem to be any way to invoke the interrupt thread
> in the absence of an interrupt, Ming pushed the job off to a work
> queue.
>
> > If you just treat a threaded interrupt like a real interrupt and push
> > off work to something else, then yes, it will degrade performance.
> >
> > If you go the threaded interrupt route, you need to rethink the
> > paradigm. There's no reason that the interrupt handler needs to be fast
> > like it needs to be in true interrupt context. The handler can now use
> > mutexes, and other full features that currently only threads benefit
> > from. It should improve locking issues, and can serialize things if
> > needed.
> >
> > All this patch did was to switch the main irq to a thread and make a
> > bottom half into a work queue.
>
> In case it's not clear, the code you quoted above is part of the
> interrupt handler, not part of the thread.
Got it.
>
> > Why couldn't you just do:
> >
> > if (sched)
> > usb_giveback_urb_bh(bh);
> >
> > ?
>
> Because usb_giveback_urb_bh() is supposed to run in the context of the
> tasklet or interrupt thread or work queue, not in the context of the
> interrupt handler.
I only took a quick look at the second patch. I'm now looking at both
patches applied to the code. I didn't realize this was called from the
top half.
Usually the top half for threaded interrupts is used just to quite the
interrupt line. Either by acknowledging the interrupt or by disabling
the device from sending more interrupts till the bottom half (thread)
can run. This looks to be doing a bit more than that.
I'll look a bit deeper at the patch, but this still doesn't look like a
typical threaded interrupt usage.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, 13 Jun 2013, Steven Rostedt wrote:
> On Thu, 2013-06-13 at 15:41 -0400, Alan Stern wrote:
>
> > The test results above show a 2.4% degradation for threaded interrupts
> > as compared to tasklets. That's in addition to the bottlenecks caused
> > by the device; no doubt it would be worse for a faster device. This
> > result calls into question the benefits of threaded interrupts.
>
> That's because it was written like a top half and not a full blown
> interrupt. I just looked at the patch, and saw this:
>
> +#ifndef USB_HCD_THREADED_IRQ
> if (sched) {
> if (async)
> tasklet_schedule(&bh->bh);
> else
> tasklet_hi_schedule(&bh->bh);
> }
> +#else
> + if (sched)
> + schedule_work(&hcd->periodic_bh->work);
> +#endif
>
> What is this? The work isn't done by an interrupt thread, but by work queues!
You don't understand the patch. Most of the time, sched will be 0
here and hence the work queue won't be involved.
Yes, part of the work is done by a work queue rather than the interrupt
thread. But it is an unimportant part, the part that involves
transfers to root hubs or transfers that were cancelled. These things
can complete without any interrupt occurring, so they can't be handled
by the interrupt thread. However, they are the abnormal case; the
transfers we care about are not to root hubs and they do complete
normally.
> The point of the interrupt thread is that you do *all* the work that
> needs to be done when an interrupt comes in. You don't need to delay the
> work.
You've got it backward. The patch doesn't leave part of the work
undone when an interrupt occurs. Rather it's the other way around --
sometimes work needs to be done when there isn't any interrupt. This
could happen in a timer callback, or it could happen as a direct result
of a function call.
Since there doesn't seem to be any way to invoke the interrupt thread
in the absence of an interrupt, Ming pushed the job off to a work
queue.
> If you just treat a threaded interrupt like a real interrupt and push
> off work to something else, then yes, it will degrade performance.
>
> If you go the threaded interrupt route, you need to rethink the
> paradigm. There's no reason that the interrupt handler needs to be fast
> like it needs to be in true interrupt context. The handler can now use
> mutexes, and other full features that currently only threads benefit
> from. It should improve locking issues, and can serialize things if
> needed.
>
> All this patch did was to switch the main irq to a thread and make a
> bottom half into a work queue.
In case it's not clear, the code you quoted above is part of the
interrupt handler, not part of the thread.
> Why couldn't you just do:
>
> if (sched)
> usb_giveback_urb_bh(bh);
>
> ?
Because usb_giveback_urb_bh() is supposed to run in the context of the
tasklet or interrupt thread or work queue, not in the context of the
interrupt handler.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, 2013-06-13 at 15:41 -0400, Alan Stern wrote:
> The test results above show a 2.4% degradation for threaded interrupts
> as compared to tasklets. That's in addition to the bottlenecks caused
> by the device; no doubt it would be worse for a faster device. This
> result calls into question the benefits of threaded interrupts.
That's because it was written like a top half and not a full blown
interrupt. I just looked at the patch, and saw this:
+#ifndef USB_HCD_THREADED_IRQ
if (sched) {
if (async)
tasklet_schedule(&bh->bh);
else
tasklet_hi_schedule(&bh->bh);
}
+#else
+ if (sched)
+ schedule_work(&hcd->periodic_bh->work);
+#endif
What is this? The work isn't done by an interrupt thread, but by work queues!
The point of the interrupt thread is that you do *all* the work that
needs to be done when an interrupt comes in. You don't need to delay the
work.
If you just treat a threaded interrupt like a real interrupt and push
off work to something else, then yes, it will degrade performance.
If you go the threaded interrupt route, you need to rethink the
paradigm. There's no reason that the interrupt handler needs to be fast
like it needs to be in true interrupt context. The handler can now use
mutexes, and other full features that currently only threads benefit
from. It should improve locking issues, and can serialize things if
needed.
All this patch did was to switch the main irq to a thread and make a
bottom half into a work queue.
Why couldn't you just do:
if (sched)
usb_giveback_urb_bh(bh);
?
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe 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 05/10] USB: OHCI: Properly handle ohci-exynos suspend
On Thu, 13 Jun 2013, Tomasz Figa wrote:
> > + rc = ohci_suspend(hcd, do_wakeup);
> > + if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
> > + ohci_resume(hcd, false);
> > + rc = -EBUSY;
> > + }
>
> I'm not into USB host subsystem, so I might just ask a stupid question.
>
> Can't we make ohci_suspend check this for us, so the drivers would just
> check for error code? It seems like in all your patches this part of code
> is duplicated, looking as a good candidate to be generic.
Argh! You're right, of course.
I didn't see it, because the only existing place where this check is
made is in the PCI glue layer. Pushing it into the HCDs themselves is
obviously the right thing to do.
Manjanuth, let's do this. You can write a preliminary patch that puts
this check at the end of the ohci_suspend() routine, and then resubmit
your series.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, 13 Jun 2013, Greg Kroah-Hartman wrote: > On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote: > > On Thu, 13 Jun 2013, Ming Lei wrote: > > > > > - using interrupt threaded handler(default) > > > 33.440 MB/sec > > > > > > - using tasklet(#undef USB_HCD_THREADED_IRQ) > > > 34.29 MB/sec > > > > > > - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c ) > > > 34.260 MB/s > > > > > > > > > So looks usb mass storage performance loss can be observed with > > > interrupt threaded handler because one mass storage read/write sectors > > > requires at least 3 interrupts which wake up usb-storage thread 3 times > > > (each interrupt wakeup the usb-storage each time), introducing irq > > > threaded > > > handler will make 2 threads to be waken up about 6 times for one > > > read/write. > > > > > > I think usb mass storage transfer handler need to be rewritten, otherwise > > > it may become worsen after using irq threaded handler in USB 3.0.(the > > > above device can reach >120MB/sec with hardware handler or tasklet > > > handler, > > > which means about ~3K interrupts/sec, so ~6K contexts switch in case of > > > using irq threaded handler) > > > > > > So how about supporting tasklet first, then convert to interrupt > > > threaded handler > > > after usb mass storage transfer is rewritten without performance loss? > > > (rewriting > > > usb mass storage transfer handler may need some time and work since > > > storage > > > stability/correctness is extremely important, :-) > > > > Maybe we should simply copy what the networking people do. They are > > very concerned about performance and latency; whatever technique they > > use should be good for USB too. > > Yes, but for "old-style" usb-storage, is this really a big deal? We are > still easily hitting the "line-speed" of USB for usb-storage with simple > machines, the bottlenecks that I'm seeing are in the devices themselves, > and then in the USB wire speed. What about with USB-3 storage devices? Many of them still use the bulk-only transport instead of UAS. They may push the limits up. > Once hardware comes out that uses USB streams, and we get device support > for the UAS protocol, then we might have a need to change things, but at > this point in time, for the "old" driver, I think we are fine. > > Unless someone has a workload / benchmark that shows otherwise? The test results above show a 2.4% degradation for threaded interrupts as compared to tasklets. That's in addition to the bottlenecks caused by the device; no doubt it would be worse for a faster device. This result calls into question the benefits of threaded interrupts. The main reason for moving away from the current scheme is to reduce latency for other interrupt handlers. Ming gave two examples of slow USB code that runs in hardirq context now; with his change they would run in softirq context and therefore wouldn't delay other interrupts so much. (Interrupt latency is hard to measure, however.) 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 V2 05/10] USB: OHCI: Properly handle ohci-exynos suspend
Hi Manjunath,
On Thursday 13 of June 2013 14:46:24 Manjunath Goudar wrote:
> Suspend scenario in case of ohci-exynos glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
> routine in exynos_ohci_suspend() will ensure proper
> handling of suspend scenario.
>
> V2:
> -Incase ohci_suspend() fails, return right away without
> executing further.
>
> Signed-off-by: Manjunath Goudar
> Cc: Arnd Bergmann
> Cc: Alan Stern
> Cc: Greg KH
> Cc: linux-usb@vger.kernel.org
> ---
> drivers/usb/host/ohci-exynos.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-exynos.c
> b/drivers/usb/host/ohci-exynos.c index 6ff830c..8fecb6a 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -203,9 +203,17 @@ static int exynos_ohci_suspend(struct device *dev)
> struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
> struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> struct platform_device *pdev = to_platform_device(dev);
> + bool do_wakeup = device_may_wakeup(dev);
> unsigned long flags;
> int rc = 0;
>
> + rc = ohci_suspend(hcd, do_wakeup);
> + if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
> + ohci_resume(hcd, false);
> + rc = -EBUSY;
> + }
I'm not into USB host subsystem, so I might just ask a stupid question.
Can't we make ohci_suspend check this for us, so the drivers would just
check for error code? It seems like in all your patches this part of code
is duplicated, looking as a good candidate to be generic.
Best regards,
Tomasz
> + if (rc)
> + return rc;
> /*
>* Root hub was already suspended. Disable irq emission and
>* mark HW unaccessible, bail out if RH has been resumed. Use
--
To unsubscribe from this list: send the line "unsubscribe 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 03/10] USB: OHCI: Properly handle ohci-da8xx suspend
On Thu, 13 Jun 2013, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-da8xx glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
> routine in ohci_da8xx_suspend() will ensure proper
> handling of suspend scenario.
>
> V2:
> -Incase ohci_suspend() fails, return right away without
> executing further.
> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
> index 6aaa9c9..8d4914d 100644
> --- a/drivers/usb/host/ohci-da8xx.c
> +++ b/drivers/usb/host/ohci-da8xx.c
> @@ -406,10 +406,21 @@ static int ohci_hcd_da8xx_drv_remove(struct
> platform_device *dev)
> }
>
> #ifdef CONFIG_PM
> -static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
> message)
> +static int ohci_da8xx_suspend(struct platform_device *pdev,
> + pm_message_t message)
> {
> - struct usb_hcd *hcd= platform_get_drvdata(dev);
> + struct usb_hcd *hcd= platform_get_drvdata(pdev);
> struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> + bool do_wakeup = device_may_wakeup(&pdev->dev);
> + int ret;
Again, the new variables should line up with the old ones.
> +
> + ret = ohci_suspend(hcd, do_wakeup);
> + if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
> + ohci_resume(hcd, false);
> + ret = -EBUSY;
> + }
> + if (ret)
> + return ret;
>
> if (time_before(jiffies, ohci->next_statechange))
> msleep(5);
This time_before and next_statechange stuff can be removed. Or if you
want to keep it, the code you added should come after it.
> @@ -417,8 +428,8 @@ static int ohci_da8xx_suspend(struct platform_device
> *dev, pm_message_t message)
>
> ohci_da8xx_clock(0);
> hcd->state = HC_STATE_SUSPENDED;
> - dev->dev.power.power_state = PMSG_SUSPEND;
> - return 0;
> + pdev->dev.power.power_state = PMSG_SUSPEND;
> + return ret;
> }
This pdev->dev.power.power_state stuff isn't being used any more. It
can be removed.
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 V2 02/10] USB: OHCI: Properly handle ohci-s3c2410 suspend
On Thu, 13 Jun 2013, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-s3c2410 glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
> routine in ohci_hcd_s3c2410_drv_suspend() will ensure
> proper handling of suspend scenario.
>
> V2:
> -Incase ohci_suspend() fails, return right away
> without executing further.
> diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
> index 8018bb1..01430f2 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -430,7 +430,15 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device
> *dev)
> struct platform_device *pdev = to_platform_device(dev);
> unsigned long flags;
> int rc = 0;
> + bool do_wakeup = device_may_wakeup(dev);
>
> + rc = ohci_suspend(hcd, do_wakeup);
> + if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
> + ohci_resume(hcd, false);
> + rc = -EBUSY;
> + }
> + if (rc)
> + return rc;
> /*
>* Root hub was already suspended. Disable irq emission and
>* mark HW unaccessible, bail out if RH has been resumed. Use
The part that follows this patch doesn't make sense any more. I think
we can afford to get rid of the test for ohci->rh_state !=
OHCI_RH_SUSPENDED; the PM core has been quite stable for years and it
won't try to suspend the controller if the root hub is active.
Also, the
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
line isn't needed, because ohci_suspend() does it.
Putting this all together, all that's left is the spin_lock/unlock and
the call to s3c2410_stop_hc(). The comment isn't needed, nor is the
statement label. (In fact, I'm not even sure if the spin_lock/unlock
lines are needed. It depends on the hardware details.)
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 V2 01/10] USB: OHCI: Properly handle ohci-at91 suspend
On Thu, 13 Jun 2013, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-at91 glue was not properly
> handled as it was not suspending generic part of ohci controller.
> Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
> will ensure proper handling of suspend scenario.
>
> V2:
> -Incase ohci_suspend() fails, return right away without executing further.
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index fb2f127..6620e3a 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -619,8 +619,18 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
> pm_message_t mesg)
> {
> struct usb_hcd *hcd = platform_get_drvdata(pdev);
> struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> + bool do_wakeup = device_may_wakeup(&pdev->dev);
> + int ret;
Please use tab characters so that "do_wakeup" and "ret" are lined up
directly beneath "*hcd" and "*ohci". The rest of this patch is okay.
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote: > On Thu, 13 Jun 2013, Ming Lei wrote: > > > - using interrupt threaded handler(default) > > 33.440 MB/sec > > > > - using tasklet(#undef USB_HCD_THREADED_IRQ) > > 34.29 MB/sec > > > > - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c ) > > 34.260 MB/s > > > > > > So looks usb mass storage performance loss can be observed with > > interrupt threaded handler because one mass storage read/write sectors > > requires at least 3 interrupts which wake up usb-storage thread 3 times > > (each interrupt wakeup the usb-storage each time), introducing irq threaded > > handler will make 2 threads to be waken up about 6 times for one read/write. > > > > I think usb mass storage transfer handler need to be rewritten, otherwise > > it may become worsen after using irq threaded handler in USB 3.0.(the > > above device can reach >120MB/sec with hardware handler or tasklet handler, > > which means about ~3K interrupts/sec, so ~6K contexts switch in case of > > using irq threaded handler) > > > > So how about supporting tasklet first, then convert to interrupt > > threaded handler > > after usb mass storage transfer is rewritten without performance loss? > > (rewriting > > usb mass storage transfer handler may need some time and work since storage > > stability/correctness is extremely important, :-) > > Maybe we should simply copy what the networking people do. They are > very concerned about performance and latency; whatever technique they > use should be good for USB too. Yes, but for "old-style" usb-storage, is this really a big deal? We are still easily hitting the "line-speed" of USB for usb-storage with simple machines, the bottlenecks that I'm seeing are in the devices themselves, and then in the USB wire speed. Once hardware comes out that uses USB streams, and we get device support for the UAS protocol, then we might have a need to change things, but at this point in time, for the "old" driver, I think we are fine. Unless someone has a workload / benchmark that shows otherwise? 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 V3 REPOST 4/7] USB: EHCI: tegra: remove all power management
From: Stephen Warren
The PM routines in ehci-tegra.c use APIs such as ehci_reset(),
ehci_halt(), and ehci_tdi_reset() that would need to be exported to
convert ehci-tegra.c into a separate module from ehci-hcd.c. However,
we'd prefer not to export them.
Instead, simply remove all power management functionality. Runtime PM
was disabled since it didn't work correctly, and system suspend isn't
yet supported in a meaningful way. So, this change doesn't lose any
functionality.
Hopefully the power management logic can be reimplemented in a cleaner
way in the future.
Signed-off-by: Stephen Warren
Acked-by: Arnd Bergmann
Acked-by: Alan Stern
---
v3:
* Also remove tegra_ehci_power_up(), tegra_ehci_shutdown(), struct
tegra_ehci_hcd.host_resumed.
* Add back .bus_{suspend,resume} entries in tegra_ehci_hc_driver.
v2: New patch.
---
drivers/usb/host/ehci-tegra.c | 246 +-
1 file changed, 1 insertion(+), 245 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 289b9b8..dde5189 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -46,30 +46,11 @@ struct tegra_ehci_hcd {
struct tegra_usb_phy *phy;
struct clk *clk;
struct usb_phy *transceiver;
- int host_resumed;
int port_resuming;
bool needs_double_reset;
enum tegra_usb_phy_port_speed port_speed;
};
-static void tegra_ehci_power_up(struct usb_hcd *hcd)
-{
- struct tegra_ehci_hcd *tegra = dev_get_drvdata(hcd->self.controller);
-
- clk_prepare_enable(tegra->clk);
- usb_phy_set_suspend(hcd->phy, 0);
- tegra->host_resumed = 1;
-}
-
-static void tegra_ehci_power_down(struct usb_hcd *hcd)
-{
- struct tegra_ehci_hcd *tegra = dev_get_drvdata(hcd->self.controller);
-
- tegra->host_resumed = 0;
- usb_phy_set_suspend(hcd->phy, 1);
- clk_disable_unprepare(tegra->clk);
-}
-
static int tegra_ehci_internal_port_reset(
struct ehci_hcd *ehci,
u32 __iomem *portsc_reg
@@ -248,39 +229,6 @@ done:
return retval;
}
-static void tegra_ehci_restart(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- ehci_reset(ehci);
-
- /* setup the frame list and Async q heads */
- ehci_writel(ehci, ehci->periodic_dma, &ehci->regs->frame_list);
- ehci_writel(ehci, (u32)ehci->async->qh_dma, &ehci->regs->async_next);
- /* setup the command register and set the controller in RUN mode */
- ehci->command &= ~(CMD_LRESET|CMD_IAAD|CMD_PSE|CMD_ASE|CMD_RESET);
- ehci->command |= CMD_RUN;
- ehci_writel(ehci, ehci->command, &ehci->regs->command);
-
- down_write(&ehci_cf_port_reset_rwsem);
- ehci_writel(ehci, FLAG_CF, &ehci->regs->configured_flag);
- /* flush posted writes */
- ehci_readl(ehci, &ehci->regs->command);
- up_write(&ehci_cf_port_reset_rwsem);
-}
-
-static void tegra_ehci_shutdown(struct usb_hcd *hcd)
-{
- struct tegra_ehci_hcd *tegra = dev_get_drvdata(hcd->self.controller);
-
- /* ehci_shutdown touches the USB controller registers, make sure
-* controller has clocks to it */
- if (!tegra->host_resumed)
- tegra_ehci_power_up(hcd);
-
- ehci_shutdown(hcd);
-}
-
static int tegra_ehci_setup(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -395,7 +343,7 @@ static const struct hc_driver tegra_ehci_hc_driver = {
/* modified ehci functions for tegra */
.reset = tegra_ehci_setup,
- .shutdown = tegra_ehci_shutdown,
+ .shutdown = ehci_shutdown,
.map_urb_for_dma= tegra_ehci_map_urb_for_dma,
.unmap_urb_for_dma = tegra_ehci_unmap_urb_for_dma,
.hub_control= tegra_ehci_hub_control,
@@ -432,182 +380,6 @@ static int setup_vbus_gpio(struct platform_device *pdev,
return err;
}
-#ifdef CONFIG_PM
-
-static int controller_suspend(struct device *dev)
-{
- struct tegra_ehci_hcd *tegra =
- platform_get_drvdata(to_platform_device(dev));
- struct ehci_hcd *ehci = tegra->ehci;
- struct usb_hcd *hcd = ehci_to_hcd(ehci);
- struct ehci_regs __iomem *hw = ehci->regs;
- unsigned long flags;
-
- if (time_before(jiffies, ehci->next_statechange))
- msleep(10);
-
- ehci_halt(ehci);
-
- spin_lock_irqsave(&ehci->lock, flags);
- tegra->port_speed = (readl(&hw->port_status[0]) >> 26) & 0x3;
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
- spin_unlock_irqrestore(&ehci->lock, flags);
-
- tegra_ehci_power_down(hcd);
- return 0;
-}
-
-static int controller_resume(struct device *dev)
-{
- struct tegra_ehci_hcd *tegra =
- platform_get_drvdata(to_platform_device(dev));
- struct ehci_hcd *ehci = tegra->ehci;
- struct usb_hcd *hcd = ehci_to_hcd(e
[PATCH V3 REPOST 3/7] USB: EHCI: export ehci_handshake for ehci-hcd sub-drivers
From: Manjunath Goudar
In order to split ehci-hcd.c into separate modules, handshake() must be
exported. Rename the symbol to add an ehci_ prefix, to avoid any naming
clashes.
Signed-off-by: Manjunath Goudar
[swarren, split Manjunath's patches more logically, limit this change
to export just handshake()]
Signed-off-by: Stephen Warren
Acked-by: Alan Stern
Acked-by: Arnd Bergmann
---
v3: No change.
v2: Only export handshake(), not reset/tdi_reset/halt.
---
drivers/usb/host/ehci-hcd.c | 17 ++---
drivers/usb/host/ehci-hub.c | 4 ++--
drivers/usb/host/ehci-tegra.c | 12 ++--
drivers/usb/host/ehci.h | 2 ++
4 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 246e124..e8a6f3d 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -139,7 +139,7 @@ static inline unsigned ehci_read_frame_index(struct
ehci_hcd *ehci)
/*-*/
/*
- * handshake - spin reading hc until handshake completes or fails
+ * ehci_handshake - spin reading hc until handshake completes or fails
* @ptr: address of hc register to be read
* @mask: bits to look at in result of read
* @done: value of those bits when handshake succeeds
@@ -155,8 +155,8 @@ static inline unsigned ehci_read_frame_index(struct
ehci_hcd *ehci)
* before driver shutdown. But it also seems to be caused by bugs in cardbus
* bridge shutdown: shutting down the bridge before the devices using it.
*/
-static int handshake (struct ehci_hcd *ehci, void __iomem *ptr,
- u32 mask, u32 done, int usec)
+int ehci_handshake(struct ehci_hcd *ehci, void __iomem *ptr,
+ u32 mask, u32 done, int usec)
{
u32 result;
@@ -172,6 +172,7 @@ static int handshake (struct ehci_hcd *ehci, void __iomem
*ptr,
} while (usec > 0);
return -ETIMEDOUT;
}
+EXPORT_SYMBOL_GPL(ehci_handshake);
/* check TDI/ARC silicon is in host mode */
static int tdi_in_host_mode (struct ehci_hcd *ehci)
@@ -212,7 +213,7 @@ static int ehci_halt (struct ehci_hcd *ehci)
spin_unlock_irq(&ehci->lock);
synchronize_irq(ehci_to_hcd(ehci)->irq);
- return handshake(ehci, &ehci->regs->status,
+ return ehci_handshake(ehci, &ehci->regs->status,
STS_HALT, STS_HALT, 16 * 125);
}
@@ -251,7 +252,7 @@ static int ehci_reset (struct ehci_hcd *ehci)
ehci_writel(ehci, command, &ehci->regs->command);
ehci->rh_state = EHCI_RH_HALTED;
ehci->next_statechange = jiffies;
- retval = handshake (ehci, &ehci->regs->command,
+ retval = ehci_handshake(ehci, &ehci->regs->command,
CMD_RESET, 0, 250 * 1000);
if (ehci->has_hostpc) {
@@ -286,7 +287,8 @@ static void ehci_quiesce (struct ehci_hcd *ehci)
/* wait for any schedule enables/disables to take effect */
temp = (ehci->command << 10) & (STS_ASS | STS_PSS);
- handshake(ehci, &ehci->regs->status, STS_ASS | STS_PSS, temp, 16 * 125);
+ ehci_handshake(ehci, &ehci->regs->status, STS_ASS | STS_PSS, temp,
+ 16 * 125);
/* then disable anything that's still active */
spin_lock_irq(&ehci->lock);
@@ -295,7 +297,8 @@ static void ehci_quiesce (struct ehci_hcd *ehci)
spin_unlock_irq(&ehci->lock);
/* hardware can take 16 microframes to turn off ... */
- handshake(ehci, &ehci->regs->status, STS_ASS | STS_PSS, 0, 16 * 125);
+ ehci_handshake(ehci, &ehci->regs->status, STS_ASS | STS_PSS, 0,
+ 16 * 125);
}
/*-*/
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index b2f6450..2b70277 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -892,7 +892,7 @@ static int ehci_hub_control (
PORT_SUSPEND | PORT_RESUME);
ehci_writel(ehci, temp, status_reg);
clear_bit(wIndex, &ehci->resuming_ports);
- retval = handshake(ehci, status_reg,
+ retval = ehci_handshake(ehci, status_reg,
PORT_RESUME, 0, 2000 /* 2msec */);
if (retval != 0) {
ehci_err(ehci,
@@ -918,7 +918,7 @@ static int ehci_hub_control (
/* REVISIT: some hardware needs 550+ usec to clear
* this bit; seems too long to spin routinely...
*/
- retval = handshake(ehci, status_reg,
+ retval = ehci_handshake(ehci, status_reg,
PORT_RESET, 0, 1000);
if (retval != 0) {
[PATCH V3 REPOST 2/7] usb: phy: add MODULE_LICENSE to phy-tegra-usb.c
From: Stephen Warren
When this file is built as a module, it needs a MODULE_LICENSE in order
to access many exported symbols.
Signed-off-by: Stephen Warren
Acked-by: Arnd Bergmann
Acked-by: Felipe Balbi
---
v3: No change.
v2: No change.
---
drivers/usb/phy/phy-tegra-usb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 5d9af11..f0727f2 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -869,3 +870,6 @@ struct usb_phy *tegra_usb_get_phy(struct device_node *dn)
return &tegra_phy->u_phy;
}
EXPORT_SYMBOL_GPL(tegra_usb_get_phy);
+
+MODULE_DESCRIPTION("Tegra USB PHY driver");
+MODULE_LICENSE("GPL v2");
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 REPOST 6/7] USB: EHCI: make ehci-tegra a separate driver
From: Manjunath Goudar
Separate the Tegra on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Signed-off-by: Manjunath Goudar
[swarren, reworked Manjunath's patches to split them more logically,
minor re-order of added lines to better match layout of other split-up
HCD drivers and existing code, add MODULE_DEVICE_TABLE, fix
MODULE_LICENSE, adapted to change in earlier patches which removed the
ehci_driver_overrides addition, removed all PM code and solved circular
dependencies.]
Signed-off-by: Stephen Warren
Acked-by: Arnd Bergmann
Acked-by: Alan Stern
---
v3:
* Removed use of tegra_ehci_power_up() from egra_ehci_hcd_shutdown().
* Made tegra_overrides const/initconst not initdata.
* Added comment re: need for overrides in ehci_tegra_init().
v2:
* Set non-standard fields in tegra_ehci_hc_driver manually, rather than
relying on an expanded struct ehci_driver_overrides.
* Save orig_hub_control rather than relying on ehci_hub_control being
exported.
* Rebased on new versions of earlier patches.
---
drivers/usb/host/Kconfig | 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 5 --
drivers/usb/host/ehci-tegra.c | 128 --
4 files changed, 76 insertions(+), 60 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 881609e..7d0aa5f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -198,7 +198,7 @@ config USB_EHCI_MSM
has an external PHY.
config USB_EHCI_TEGRA
- boolean "NVIDIA Tegra HCD support"
+ tristate "NVIDIA Tegra HCD support"
depends on ARCH_TEGRA
select USB_EHCI_ROOT_HUB_TT
select USB_PHY
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index b41fa5f..bea7112 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o
obj-$(CONFIG_USB_EHCI_S5P) += ehci-s5p.o
obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
+obj-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index e8a6f3d..7abf1ce 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1269,11 +1269,6 @@ MODULE_LICENSE ("GPL");
#definePLATFORM_DRIVER ehci_hcd_msp_driver
#endif
-#ifdef CONFIG_USB_EHCI_TEGRA
-#include "ehci-tegra.c"
-#define PLATFORM_DRIVERtegra_ehci_driver
-#endif
-
#ifdef CONFIG_SPARC_LEON
#include "ehci-grlib.c"
#define PLATFORM_DRIVERehci_grlib_driver
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 8063429..338c8a5 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -17,25 +17,44 @@
*/
#include
+#include
+#include
#include
-#include
-#include
-#include
-#include
#include
+#include
+#include
+#include
#include
#include
+#include
+#include
#include
+#include
#include
#include
-#include
+#include
+#include
+#include
+
+#include "ehci.h"
#define TEGRA_USB_BASE 0xC500
#define TEGRA_USB2_BASE0xC5004000
#define TEGRA_USB3_BASE0xC5008000
+#define PORT_WAKE_BITS (PORT_WKOC_E|PORT_WKDISC_E|PORT_WKCONN_E)
+
#define TEGRA_USB_DMA_ALIGN 32
+#define DRIVER_DESC "Tegra EHCI driver"
+#define DRV_NAME "tegra-ehci"
+
+static struct hc_driver __read_mostly tegra_ehci_hc_driver;
+
+static int (*orig_hub_control)(struct usb_hcd *hcd,
+ u16 typeReq, u16 wValue, u16 wIndex,
+ char *buf, u16 wLength);
+
struct tegra_ehci_hcd {
struct ehci_hcd *ehci;
struct tegra_usb_phy *phy;
@@ -218,25 +237,13 @@ static int tegra_ehci_hub_control(
spin_unlock_irqrestore(&ehci->lock, flags);
/* Handle the hub control events here */
- return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+ return orig_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+
done:
spin_unlock_irqrestore(&ehci->lock, flags);
return retval;
}
-static int tegra_ehci_setup(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- /* EHCI registers start at offset 0x100 */
- ehci->caps = hcd->regs + 0x100;
-
- /* switch to host mode */
- hcd->has_tt = 1;
-
- return ehci_setup(hcd);
-}
-
struct dma_aligned_buffer {
void *kmalloc_ptr;
void *old_xfer_buffer;
@@ -316,38 +323,6 @@ static void tegra_ehci_unmap_urb_for_dma(struct usb_hcd
*hcd, struct urb *urb)
free_dma_aligned_buffer(urb);
}
-static const struct hc_driver tegra
[PATCH 1/1] USB: wusbcore: add sysfs attribute for retry count
This patch adds a sysfs attribute for the wireless host controller
transaction retry count. It also changes the default value from 15
retries to infinite retries because the driver currently does not handle
retry errors gracefully.
Signed-off-by: Thomas Pugliese
diff --git a/drivers/usb/wusbcore/wa-rpipe.c b/drivers/usb/wusbcore/wa-rpipe.c
index 9429c12..9a595c1 100644
--- a/drivers/usb/wusbcore/wa-rpipe.c
+++ b/drivers/usb/wusbcore/wa-rpipe.c
@@ -367,8 +367,7 @@ static int rpipe_aim(struct wa_rpipe *rpipe, struct wahc
*wa,
rpipe->descr.bmAttribute = (ep->desc.bmAttributes &
USB_ENDPOINT_XFERTYPE_MASK);
/* rpipe->descr.bmCharacteristics RO */
- /* FIXME: bmRetryOptions */
- rpipe->descr.bmRetryOptions = 15;
+ rpipe->descr.bmRetryOptions = (wa->wusb->retry_count & 0xF);
/* FIXME: use for assessing link quality? */
rpipe->descr.wNumTransactionErrors = 0;
result = __rpipe_set_descr(wa, &rpipe->descr,
diff --git a/drivers/usb/wusbcore/wusbhc.c b/drivers/usb/wusbcore/wusbhc.c
index 8759aa6..e712af3 100644
--- a/drivers/usb/wusbcore/wusbhc.c
+++ b/drivers/usb/wusbcore/wusbhc.c
@@ -205,12 +205,42 @@ static ssize_t wusb_dnts_store(struct device *dev,
}
static DEVICE_ATTR(wusb_dnts, 0644, wusb_dnts_show, wusb_dnts_store);
+static ssize_t wusb_retry_count_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct wusbhc *wusbhc = usbhc_dev_to_wusbhc(dev);
+
+ return sprintf(buf, "%d\n", wusbhc->retry_count);
+}
+
+static ssize_t wusb_retry_count_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct wusbhc *wusbhc = usbhc_dev_to_wusbhc(dev);
+ uint8_t retry_count;
+ ssize_t result;
+
+ result = sscanf(buf, "%hhu", &retry_count);
+
+ if (result != 1)
+ return -EINVAL;
+
+ wusbhc->retry_count = max_t(uint8_t, retry_count, WUSB_RETRY_COUNT_MAX);
+
+ return size;
+}
+static DEVICE_ATTR(wusb_retry_count, 0644, wusb_retry_count_show,
+ wusb_retry_count_store);
+
/* Group all the WUSBHC attributes */
static struct attribute *wusbhc_attrs[] = {
&dev_attr_wusb_trust_timeout.attr,
&dev_attr_wusb_chid.attr,
&dev_attr_wusb_phy_rate.attr,
&dev_attr_wusb_dnts.attr,
+ &dev_attr_wusb_retry_count.attr,
NULL,
};
@@ -241,6 +271,7 @@ int wusbhc_create(struct wusbhc *wusbhc)
wusbhc->phy_rate = UWB_PHY_RATE_INVALID - 1;
wusbhc->dnts_num_slots = 4;
wusbhc->dnts_interval = 2;
+ wusbhc->retry_count = WUSB_RETRY_COUNT_INFINITE;
mutex_init(&wusbhc->mutex);
result = wusbhc_mmcie_create(wusbhc);
diff --git a/drivers/usb/wusbcore/wusbhc.h b/drivers/usb/wusbcore/wusbhc.h
index a7069f4..711b195 100644
--- a/drivers/usb/wusbcore/wusbhc.h
+++ b/drivers/usb/wusbcore/wusbhc.h
@@ -69,6 +69,8 @@
* zone 0.
*/
#define WUSB_CHANNEL_STOP_DELAY_MS 8
+#define WUSB_RETRY_COUNT_MAX 15
+#define WUSB_RETRY_COUNT_INFINITE 0
/**
* Wireless USB device
@@ -254,6 +256,7 @@ struct wusbhc {
uint8_t phy_rate;
uint8_t dnts_num_slots;
uint8_t dnts_interval;
+ uint8_t retry_count;
struct wuie_host_info *wuie_host_info;
struct mutex mutex; /* locks everything else */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 REPOST 0/7] USB: tegra: support building as a module
From: Stephen Warren I'm reposting this because I originally thought Felipe would apply it to his PHY tree, since it's based on other work there. Now that tree has been merged into Greg's main USB tree, I believe this series can be applied there instead. Hence, resending so it shows up in Greg's inbox. ehci-tegra is currently built into the main ehci-hcd driver, rather than being a separate module. This causes issues with multi-platform ARM kernels. This series separates ehci-tegra into its own module to avoid those problems. Manjunath Goudar originally wrote most of this series. I've since cleaned it up, rebased it on Venu's recent changes to the Tegra USB driver, and tested it. Manjunath Goudar (3): usb: phy: export ulpi_viewport_access_ops USB: EHCI: export ehci_handshake for ehci-hcd sub-drivers USB: EHCI: make ehci-tegra a separate driver Stephen Warren (4): usb: phy: add MODULE_LICENSE to phy-tegra-usb.c USB: EHCI: tegra: remove all power management USB: EHCI: tegra: fix circular module dependencies USB: EHCI: tegra: make use of ehci->priv drivers/usb/host/Kconfig| 2 +- drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-hcd.c | 22 +- drivers/usb/host/ehci-hub.c | 4 +- drivers/usb/host/ehci-tegra.c | 474 drivers/usb/host/ehci.h | 2 + drivers/usb/phy/phy-tegra-usb.c | 43 +++- drivers/usb/phy/phy-ulpi-viewport.c | 2 + include/linux/usb/tegra_usb_phy.h | 4 - 9 files changed, 165 insertions(+), 389 deletions(-) -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 REPOST 5/7] USB: EHCI: tegra: fix circular module dependencies
From: Stephen Warren
The Tegra EHCI driver directly calls various functions in the Tegra USB
PHY driver. The reverse is also true; the PHY driver calls into the EHCI
driver. This is problematic when the two are built as modules.
The calls from the PHY to EHCI driver were originally added in commit
bbdabdb "usb: add APIs to access host registers from Tegra PHY", for the
following reasons:
1) The register being touched is an EHCI register, so logically only the
EHCI driver should touch it.
2) (1) implies that some locking may be needed to correctly implement the
r/m/w access to this shared register.
3) We were expecting to pass only the PHY register space to the Tegra PHY
driver, and hence it would not have access to touch the shared
registers.
To solve this, that commit added functions in the EHCI driver to touch the
shared register on behalf of the PHY driver.
In practice, we ended up not having any locking in the implementaiton of
those functions, and I've been led to believe this is safe. Equally, (3)
did not happen either. Hence, it is possible for the PHY driver to touch
the shared register directly.
Given that, this patch moves the code to touch the shared register back
into the PHY driver, to eliminate the module problems. If we actually
need locking or co-ordination in the future, I propose we put the lock
support into some pre-existing core module, or into a third separate
module, in order to avoid the circular dependencies.
I apologize for my contribution to code churn here.
Signed-off-by: Stephen Warren
Acked-by: Alan Stern
Acked-by: Arnd Bergmann
---
v3: No change.
v2: No change; just rebased on new versions of earlier patches.
---
drivers/usb/host/ehci-tegra.c | 36
drivers/usb/phy/phy-tegra-usb.c | 39 ---
include/linux/usb/tegra_usb_phy.h | 4
3 files changed, 36 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index dde5189..8063429 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -34,11 +34,6 @@
#define TEGRA_USB2_BASE0xC5004000
#define TEGRA_USB3_BASE0xC5008000
-/* PORTSC registers */
-#define TEGRA_USB_PORTSC1 0x184
-#define TEGRA_USB_PORTSC1_PTS(x) (((x) & 0x3) << 30)
-#define TEGRA_USB_PORTSC1_PHCD (1 << 23)
-
#define TEGRA_USB_DMA_ALIGN 32
struct tegra_ehci_hcd {
@@ -380,37 +375,6 @@ static int setup_vbus_gpio(struct platform_device *pdev,
return err;
}
-/* Bits of PORTSC1, which will get cleared by writing 1 into them */
-#define TEGRA_PORTSC1_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC)
-
-void tegra_ehci_set_pts(struct usb_phy *x, u8 pts_val)
-{
- unsigned long val;
- struct usb_hcd *hcd = bus_to_hcd(x->otg->host);
- void __iomem *base = hcd->regs;
-
- val = readl(base + TEGRA_USB_PORTSC1) & ~TEGRA_PORTSC1_RWC_BITS;
- val &= ~TEGRA_USB_PORTSC1_PTS(3);
- val |= TEGRA_USB_PORTSC1_PTS(pts_val & 3);
- writel(val, base + TEGRA_USB_PORTSC1);
-}
-EXPORT_SYMBOL_GPL(tegra_ehci_set_pts);
-
-void tegra_ehci_set_phcd(struct usb_phy *x, bool enable)
-{
- unsigned long val;
- struct usb_hcd *hcd = bus_to_hcd(x->otg->host);
- void __iomem *base = hcd->regs;
-
- val = readl(base + TEGRA_USB_PORTSC1) & ~TEGRA_PORTSC1_RWC_BITS;
- if (enable)
- val |= TEGRA_USB_PORTSC1_PHCD;
- else
- val &= ~TEGRA_USB_PORTSC1_PHCD;
- writel(val, base + TEGRA_USB_PORTSC1);
-}
-EXPORT_SYMBOL_GPL(tegra_ehci_set_phcd);
-
static int tegra_ehci_probe(struct platform_device *pdev)
{
struct resource *res;
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index f0727f2..3446245 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -32,11 +32,20 @@
#include
#include
#include
+#include
#include
#include
#define ULPI_VIEWPORT 0x170
+/* PORTSC registers */
+#define TEGRA_USB_PORTSC1 0x184
+#define TEGRA_USB_PORTSC1_PTS(x) (((x) & 0x3) << 30)
+#define TEGRA_USB_PORTSC1_PHCD (1 << 23)
+
+/* Bits of PORTSC1, which will get cleared by writing 1 into them */
+#define TEGRA_PORTSC1_RWC_BITS (PORT_CSC | PORT_PEC | PORT_OCC)
+
#define USB_SUSP_CTRL 0x400
#define USB_WAKE_ON_CNNT_EN_DEV (1 << 3)
#define USB_WAKE_ON_DISCON_EN_DEV(1 << 4)
@@ -197,6 +206,30 @@ static struct tegra_utmip_config utmip_default[] = {
},
};
+static void set_pts(struct tegra_usb_phy *phy, u8 pts_val)
+{
+ void __iomem *base = phy->regs;
+ unsigned long val;
+
+ val = readl(base + TEGRA_USB_PORTSC1) & ~TEGRA_PORTSC1_RWC_BITS;
+ val &= ~TEGRA_USB_PORTSC1_PTS(3);
+ val |= TEGRA_USB_PORTSC1_PTS(pts_val & 3);
+ writel(val, base + TEGRA_
[PATCH V3 REPOST 1/7] usb: phy: export ulpi_viewport_access_ops
From: Manjunath Goudar
In order to build a ULPI PHY driver as a module, this symbol needs to
be exported.
Signed-off-by: Manjunath Goudar
[swarren, reworked Manjunath's patches to split them more logically]
Signed-off-by: Stephen Warren
Acked-by: Arnd Bergmann
Acked-by: Felipe Balbi
---
v3: No change.
v2: Include export.h not module.h
---
drivers/usb/phy/phy-ulpi-viewport.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/phy/phy-ulpi-viewport.c
b/drivers/usb/phy/phy-ulpi-viewport.c
index c5ba7e5..7c22a539 100644
--- a/drivers/usb/phy/phy-ulpi-viewport.c
+++ b/drivers/usb/phy/phy-ulpi-viewport.c
@@ -12,6 +12,7 @@
*
*/
+#include
#include
#include
#include
@@ -78,3 +79,4 @@ struct usb_phy_io_ops ulpi_viewport_access_ops = {
.read = ulpi_viewport_read,
.write = ulpi_viewport_write,
};
+EXPORT_SYMBOL_GPL(ulpi_viewport_access_ops);
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 REPOST 7/7] USB: EHCI: tegra: make use of ehci->priv
From: Stephen Warren
Rather than allocating struct tegra_ehci_hcd separately, use struct
ehci_hcd's priv field instead.
Signed-off-by: Stephen Warren
Acked-by: Alan Stern
---
v3: New patch.
---
drivers/usb/host/ehci-tegra.c | 70 +--
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 338c8a5..8dac5e4 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -56,7 +56,6 @@ static int (*orig_hub_control)(struct usb_hcd *hcd,
char *buf, u16 wLength);
struct tegra_ehci_hcd {
- struct ehci_hcd *ehci;
struct tegra_usb_phy *phy;
struct clk *clk;
struct usb_phy *transceiver;
@@ -139,8 +138,8 @@ static int tegra_ehci_hub_control(
u16 wLength
)
{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- struct tegra_ehci_hcd *tegra = dev_get_drvdata(hcd->self.controller);
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ struct tegra_ehci_hcd *tegra = (struct tegra_ehci_hcd *)ehci->priv;
u32 __iomem *status_reg;
u32 temp;
unsigned long flags;
@@ -354,6 +353,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
{
struct resource *res;
struct usb_hcd *hcd;
+ struct ehci_hcd *ehci;
struct tegra_ehci_hcd *tegra;
struct tegra_ehci_platform_data *pdata;
int err = 0;
@@ -378,20 +378,29 @@ static int tegra_ehci_probe(struct platform_device *pdev)
setup_vbus_gpio(pdev, pdata);
- tegra = devm_kzalloc(&pdev->dev, sizeof(struct tegra_ehci_hcd),
-GFP_KERNEL);
- if (!tegra)
- return -ENOMEM;
+ hcd = usb_create_hcd(&tegra_ehci_hc_driver, &pdev->dev,
+ dev_name(&pdev->dev));
+ if (!hcd) {
+ dev_err(&pdev->dev, "Unable to create HCD\n");
+ err = -ENOMEM;
+ goto cleanup_vbus_gpio;
+ }
+ platform_set_drvdata(pdev, hcd);
+ ehci = hcd_to_ehci(hcd);
+ tegra = (struct tegra_ehci_hcd *)ehci->priv;
+
+ hcd->has_tt = 1;
tegra->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(tegra->clk)) {
dev_err(&pdev->dev, "Can't get ehci clock\n");
- return PTR_ERR(tegra->clk);
+ err = PTR_ERR(tegra->clk);
+ goto cleanup_hcd_create;
}
err = clk_prepare_enable(tegra->clk);
if (err)
- return err;
+ goto cleanup_clk_get;
tegra_periph_reset_assert(tegra->clk);
udelay(1);
@@ -400,35 +409,24 @@ static int tegra_ehci_probe(struct platform_device *pdev)
np_phy = of_parse_phandle(pdev->dev.of_node, "nvidia,phy", 0);
if (!np_phy) {
err = -ENODEV;
- goto cleanup_clk;
+ goto cleanup_clk_en;
}
u_phy = tegra_usb_get_phy(np_phy);
if (IS_ERR(u_phy)) {
err = PTR_ERR(u_phy);
- goto cleanup_clk;
+ goto cleanup_clk_en;
}
+ hcd->phy = u_phy;
tegra->needs_double_reset = of_property_read_bool(pdev->dev.of_node,
"nvidia,needs-double-reset");
- hcd = usb_create_hcd(&tegra_ehci_hc_driver, &pdev->dev,
- dev_name(&pdev->dev));
- if (!hcd) {
- dev_err(&pdev->dev, "Unable to create HCD\n");
- err = -ENOMEM;
- goto cleanup_clk;
- }
- tegra->ehci = hcd_to_ehci(hcd);
-
- hcd->has_tt = 1;
- hcd->phy = u_phy;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(&pdev->dev, "Failed to get I/O memory\n");
err = -ENXIO;
- goto cleanup_hcd_create;
+ goto cleanup_clk_en;
}
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
@@ -436,14 +434,14 @@ static int tegra_ehci_probe(struct platform_device *pdev)
if (!hcd->regs) {
dev_err(&pdev->dev, "Failed to remap I/O memory\n");
err = -ENOMEM;
- goto cleanup_hcd_create;
+ goto cleanup_clk_en;
}
- tegra->ehci->caps = hcd->regs + 0x100;
+ ehci->caps = hcd->regs + 0x100;
err = usb_phy_init(hcd->phy);
if (err) {
dev_err(&pdev->dev, "Failed to initialize phy\n");
- goto cleanup_hcd_create;
+ goto cleanup_clk_en;
}
u_phy->otg = devm_kzalloc(&pdev->dev, sizeof(struct usb_otg),
@@ -477,8 +475,6 @@ static int tegra_ehci_probe(struct platform_device *pdev)
tegra->transceiver = ERR_PTR(-ENODEV);
}
- platform_set_drvdata(pdev, tegra);
-
err = usb_add_hcd(hcd, irq, IRQF_SHARE
[PATCH 0/1] USB: wusbcore: add sysfs attribute for DNTS count and interval
This patch adds a sysfs attribute for the wireless USB host controller
device notification transmit slot(DNTS) count and interval. It also
changes the defaults from 16 slots in every MMC to a more reasonable 4
slots every 2ms.
Signed-off-by: Thomas Pugliese
diff --git a/drivers/usb/wusbcore/mmc.c b/drivers/usb/wusbcore/mmc.c
index b8c7258..27497ff 100644
--- a/drivers/usb/wusbcore/mmc.c
+++ b/drivers/usb/wusbcore/mmc.c
@@ -214,9 +214,9 @@ int wusbhc_start(struct wusbhc *wusbhc)
dev_err(dev, "error starting security in the HC: %d\n", result);
goto error_sec_start;
}
- /* FIXME: the choice of the DNTS parameters is somewhat
-* arbitrary */
- result = wusbhc->set_num_dnts(wusbhc, 0, 15);
+
+ result = wusbhc->set_num_dnts(wusbhc, wusbhc->dnts_interval,
+ wusbhc->dnts_num_slots);
if (result < 0) {
dev_err(dev, "Cannot set DNTS parameters: %d\n", result);
goto error_set_num_dnts;
diff --git a/drivers/usb/wusbcore/wusbhc.c b/drivers/usb/wusbcore/wusbhc.c
index c35ee43..8759aa6 100644
--- a/drivers/usb/wusbcore/wusbhc.c
+++ b/drivers/usb/wusbcore/wusbhc.c
@@ -175,11 +175,42 @@ static ssize_t wusb_phy_rate_store(struct device *dev,
}
static DEVICE_ATTR(wusb_phy_rate, 0644, wusb_phy_rate_show,
wusb_phy_rate_store);
+static ssize_t wusb_dnts_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct wusbhc *wusbhc = usbhc_dev_to_wusbhc(dev);
+
+ return sprintf(buf, "num slots: %d\ninterval: %dms\n",
+ wusbhc->dnts_num_slots, wusbhc->dnts_interval);
+}
+
+static ssize_t wusb_dnts_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct wusbhc *wusbhc = usbhc_dev_to_wusbhc(dev);
+ uint8_t num_slots, interval;
+ ssize_t result;
+
+ result = sscanf(buf, "%hhu %hhu", &num_slots, &interval);
+
+ if (result != 2)
+ return -EINVAL;
+
+ wusbhc->dnts_num_slots = num_slots;
+ wusbhc->dnts_interval = interval;
+
+ return size;
+}
+static DEVICE_ATTR(wusb_dnts, 0644, wusb_dnts_show, wusb_dnts_store);
+
/* Group all the WUSBHC attributes */
static struct attribute *wusbhc_attrs[] = {
&dev_attr_wusb_trust_timeout.attr,
&dev_attr_wusb_chid.attr,
&dev_attr_wusb_phy_rate.attr,
+ &dev_attr_wusb_dnts.attr,
NULL,
};
@@ -205,8 +236,11 @@ int wusbhc_create(struct wusbhc *wusbhc)
{
int result = 0;
+ /* set defaults. These can be overwritten using sysfs attributes. */
wusbhc->trust_timeout = WUSB_TRUST_TIMEOUT_MS;
wusbhc->phy_rate = UWB_PHY_RATE_INVALID - 1;
+ wusbhc->dnts_num_slots = 4;
+ wusbhc->dnts_interval = 2;
mutex_init(&wusbhc->mutex);
result = wusbhc_mmcie_create(wusbhc);
diff --git a/drivers/usb/wusbcore/wusbhc.h b/drivers/usb/wusbcore/wusbhc.h
index b4a4fa7..a7069f4 100644
--- a/drivers/usb/wusbcore/wusbhc.h
+++ b/drivers/usb/wusbcore/wusbhc.h
@@ -252,6 +252,8 @@ struct wusbhc {
unsigned trust_timeout; /* in jiffies */
struct wusb_ckhdid chid;
uint8_t phy_rate;
+ uint8_t dnts_num_slots;
+ uint8_t dnts_interval;
struct wuie_host_info *wuie_host_info;
struct mutex mutex; /* locks everything else */
--
To unsubscribe from this list: send the line "unsubscribe 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] MIPS: Kconfig: Select USB_EHCI_HCD if USB_SUPPORt is enabled
On 06/13/2013 08:42 AM, Markos Chandras wrote:
Commit 94d83649e1c2f25c87dc4ead9c2ab073305
"USB: remove USB_EHCI_BIG_ENDIAN_{DESC,MMIO} depends on architecture symbol"
caused the following regression in cavium_octeon_defconfig:
warning: (MIPS_SEAD3 && PMC_MSP && CPU_CAVIUM_OCTEON) selects
USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies
(USB_SUPPORT && USB && USB_EHCI_HCD)
We fix this problem by selecting the USB_EHCI_HCD missing dependency
if USB_SUPPORT is enabled.
Signed-off-by: Markos Chandras
Acked-by: Steven J. Hill
NAK. This is incorrect.
It is completely backwards and forces us to have EHCI unconditionally.
The proper fix is to move USB_EHCI_BIG_ENDIAN_MMIO (and similar other
Kconifg variables) out of the conditional section and make them
universally visible/usable.
David Daney
---
This patch is for the upstream-sfr/mips-for-linux-next
---
arch/mips/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 87ddac9..a058ba8 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1411,6 +1411,7 @@ config CPU_CAVIUM_OCTEON
select CPU_SUPPORTS_HUGEPAGES
select LIBFDT
select USE_OF
+ select USB_EHCI_HCD if USB_SUPPORT
select USB_EHCI_BIG_ENDIAN_MMIO
help
The Cavium Octeon processor is a highly integrated chip containing
--
To unsubscribe from this list: send the line "unsubscribe 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 14/20] usb: chipidea: ci13xxx-imx: move static pdata into probe function
Sergei Shtylyov writes:
> Hello.
>
> On 06/13/2013 06:59 PM, Alexander Shishkin wrote:
>
>> From: Michael Grzeschik
>
>> The pdata structure gets copied anyway inside ci13xxx_add_device
>> by platform_device_add. We don't need to have it static.
>
>> Signed-off-by: Michael Grzeschik
>> Signed-off-by: Marc Kleine-Budde
>> Signed-off-by: Sascha Hauer
>> Reviewed-by: Peter Chen
>> Signed-off-by: Alexander Shishkin
>> ---
>> drivers/usb/chipidea/ci13xxx_imx.c | 19 +--
>> 1 file changed, 9 insertions(+), 10 deletions(-)
>
>> diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
>> b/drivers/usb/chipidea/ci13xxx_imx.c
>> index 9cecfd5..18d83ab 100644
>> --- a/drivers/usb/chipidea/ci13xxx_imx.c
>> +++ b/drivers/usb/chipidea/ci13xxx_imx.c
>> @@ -87,17 +87,16 @@ EXPORT_SYMBOL_GPL(usbmisc_get_init_data);
>>
>> /* End of common functions shared by usbmisc drivers*/
>>
>> -static struct ci13xxx_platform_data ci13xxx_imx_platdata = {
>> -.name = "ci13xxx_imx",
>> -.flags = CI13XXX_REQUIRE_TRANSCEIVER |
>> - CI13XXX_PULLUP_ON_VBUS |
>> - CI13XXX_DISABLE_STREAMING,
>> -.capoffset = DEF_CAPOFFSET,
>> -};
>> -
>> static int ci13xxx_imx_probe(struct platform_device *pdev)
>> {
>> struct ci13xxx_imx_data *data;
>> +struct ci13xxx_platform_data pdata = {
>> +.name = "ci13xxx_imx",
>> +.capoffset = DEF_CAPOFFSET,
>> +.flags = CI13XXX_REQUIRE_TRANSCEIVER |
>> + CI13XXX_PULLUP_ON_VBUS |
>> + CI13XXX_DISABLE_STREAMING,
>> +};
>
>Don't think that's a good idea. This will cause some code bloat.
They can have more than one instance of chipidea, so they'll need it
sooner or later.
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 14/20] usb: chipidea: ci13xxx-imx: move static pdata into probe function
Hello.
On 06/13/2013 06:59 PM, Alexander Shishkin wrote:
From: Michael Grzeschik
The pdata structure gets copied anyway inside ci13xxx_add_device
by platform_device_add. We don't need to have it static.
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sascha Hauer
Reviewed-by: Peter Chen
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 9cecfd5..18d83ab 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -87,17 +87,16 @@ EXPORT_SYMBOL_GPL(usbmisc_get_init_data);
/* End of common functions shared by usbmisc drivers*/
-static struct ci13xxx_platform_data ci13xxx_imx_platdata = {
- .name = "ci13xxx_imx",
- .flags = CI13XXX_REQUIRE_TRANSCEIVER |
- CI13XXX_PULLUP_ON_VBUS |
- CI13XXX_DISABLE_STREAMING,
- .capoffset = DEF_CAPOFFSET,
-};
-
static int ci13xxx_imx_probe(struct platform_device *pdev)
{
struct ci13xxx_imx_data *data;
+ struct ci13xxx_platform_data pdata = {
+ .name = "ci13xxx_imx",
+ .capoffset = DEF_CAPOFFSET,
+ .flags = CI13XXX_REQUIRE_TRANSCEIVER |
+ CI13XXX_PULLUP_ON_VBUS |
+ CI13XXX_DISABLE_STREAMING,
+ };
Don't think that's a good idea. This will cause some code bloat.
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 fix 0/3] Configfs support
On Thu, Jun 13, 2013 at 05:25:48PM +0300, Felipe Balbi wrote: > Hi, > > On Thu, Jun 13, 2013 at 10:37:23AM +0200, Andrzej Pietrasiewicz wrote: > > Hello Felipe, Hello Greg, > > > > I've seen that you pulled a bunch of my patches. That's nice. > > > > However, Felipe was unable to apply one of them due to some whitespace > > issues, > > so he dropped it. > > > > While dropping the said patch does not break anything, it makes the usb > > functions configurable through configfs unavailable to be built > > stand-alone. They still can be built but only as a side effect of building > > some old gadgets which depend on the functions of interest, e.g. ecm, > > ecm subset, eem, rndis will be built as a side effect of building > > g_ether.ko. > > > > In Kconfig the problem described here manifests itself by some > > USB_CONFIGFS_* > > entries being dependent on nonexistent USB_CONFIGFS. In practice they do not > > appear in menuconfig, so they can't be selected. > > > > This isn't terribly bad, but the goal of configfs integration is to allow > > composing the gadgets of functions of choice at runtime, provided that > > the functions themselves are compiled. Which, in turn, stops the > > proliferation of new g_.ko gadgets and, ultimately, allows > > dropping the g_.ko modules at all. And this is in contradiction > > to not being able to build only f_.ko modules without building some > > g_.ko gadgets. > > > > The series I'm sending does the following: > > > > 1) fix separate building of configfs-enabled functions > > 2) add a piece of documentation about configfs-based usb gadgets > > 3) add some Documentation/ABI/* related to the newly added configfs entries > > > > I kindly ask you to consider the series; either as a whole, or individual > > patches. The patches in the series do not depend on each other. Verified by > > checkpatch. > > Greg, if you want to apply them directly I'm fine with it: > > Acked-by: Felipe Balbi Ok, I'll queue them up later today, 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 10/20] usb: chipidea: udc: add multiple td support to hardware_{en,de}queue
Kerry Calvert writes: [adding linux-usb back to the loop] > Dude, what is with the spamming of this list? Cease and desist please These things are called patches. This is how they are distributed in linux kernel development process. 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 V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
On Thu, 13 Jun 2013, Chao Xie wrote: > >> These operations sound generic enough to be done at HCD layer, no? So no > >> need to > >> replicate the same stuff in ohci, ehci, xhci, etc. > > > > The HCD layer handles suspend and resume only for PCI host controllers. > > Not for other types. > > > > I don't know if the acquire/start and stop/release parts can be moved > > into the USB core. Maybe they can. > > > > Alan Stern > > > hi > The following is my understanding. > I think for PHY initialization and shutdown part, it is generic for > other parts. > PHY initialization need to be called before hc_driver->reset is called. > I think it can be added at usb_add_hcd. > For PHY shutdown, it can be added at usb_remove_hcd. Yes, that should work. > For suspend/resume, i do not know how to add it. For our EHCI driver, > when system goes to deep idle states, we just directly shutdown the > hcd and initialize it again when the system goes back. You shut down the host controller? Then how does it detect wakeup events? And how does it know if a device was disconnected while the power was off? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/20] usb: chipidea: ci13xxx_imx: remove 'phy_np'
From: Fabio Estevam
There is no need to keep a local 'phy_np' as we can directly use the private
structure in data->phy_np.
Signed-off-by: Fabio Estevam
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 5fac2a1..9cecfd5 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -99,7 +99,6 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
{
struct ci13xxx_imx_data *data;
struct platform_device *phy_pdev;
- struct device_node *phy_np;
struct resource *res;
int ret;
@@ -133,10 +132,9 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
return ret;
}
- phy_np = of_parse_phandle(pdev->dev.of_node, "fsl,usbphy", 0);
- if (phy_np) {
- data->phy_np = phy_np;
- phy_pdev = of_find_device_by_node(phy_np);
+ data->phy_np = of_parse_phandle(pdev->dev.of_node, "fsl,usbphy", 0);
+ if (data->phy_np) {
+ phy_pdev = of_find_device_by_node(data->phy_np);
if (phy_pdev) {
struct usb_phy *phy;
phy = pdev_to_phy(phy_pdev);
@@ -211,8 +209,8 @@ err:
if (data->reg_vbus)
regulator_disable(data->reg_vbus);
put_np:
- if (phy_np)
- of_node_put(phy_np);
+ if (data->phy_np)
+ of_node_put(data->phy_np);
clk_disable_unprepare(data->clk);
return ret;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/20] usb: chipidea: get rid of camelcase names
Since someone has added camelcase detection to checkpatch.pl, chipidea
udc patches have been very noisy. To make everybody's life easier, this
patch changes camelcase names into something more appropriate to the
coding style. No functional changes.
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/debug.c | 10 +-
drivers/usb/chipidea/udc.c | 503 +-
2 files changed, 257 insertions(+), 256 deletions(-)
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 64b8c32..3356621 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -126,15 +126,15 @@ static int ci_qheads_show(struct seq_file *s, void *data)
spin_lock_irqsave(&ci->lock, flags);
for (i = 0; i < ci->hw_ep_max/2; i++) {
- struct ci13xxx_ep *mEpRx = &ci->ci13xxx_ep[i];
- struct ci13xxx_ep *mEpTx =
+ struct ci13xxx_ep *hweprx = &ci->ci13xxx_ep[i];
+ struct ci13xxx_ep *hweptx =
&ci->ci13xxx_ep[i + ci->hw_ep_max/2];
seq_printf(s, "EP=%02i: RX=%08X TX=%08X\n",
- i, (u32)mEpRx->qh.dma, (u32)mEpTx->qh.dma);
+ i, (u32)hweprx->qh.dma, (u32)hweptx->qh.dma);
for (j = 0; j < (sizeof(struct ci13xxx_qh)/sizeof(u32)); j++)
seq_printf(s, " %04X:%08X%08X\n", j,
- *((u32 *)mEpRx->qh.ptr + j),
- *((u32 *)mEpTx->qh.ptr + j));
+ *((u32 *)hweprx->qh.ptr + j),
+ *((u32 *)hweptx->qh.ptr + j));
}
spin_unlock_irqrestore(&ci->lock, flags);
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 825bfeb..02062a5 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -369,7 +369,7 @@ static int hw_usb_reset(struct ci13xxx *ci)
* UTIL block
*/
-static int add_td_to_list(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq,
+static int add_td_to_list(struct ci13xxx_ep *hwep, struct ci13xxx_req *hwreq,
unsigned length)
{
int i;
@@ -380,7 +380,7 @@ static int add_td_to_list(struct ci13xxx_ep *mEp, struct
ci13xxx_req *mReq,
if (node == NULL)
return -ENOMEM;
- node->ptr = dma_pool_alloc(mEp->td_pool, GFP_ATOMIC,
+ node->ptr = dma_pool_alloc(hwep->td_pool, GFP_ATOMIC,
&node->dma);
if (node->ptr == NULL) {
kfree(node);
@@ -392,7 +392,7 @@ static int add_td_to_list(struct ci13xxx_ep *mEp, struct
ci13xxx_req *mReq,
node->ptr->token &= cpu_to_le32(TD_TOTAL_BYTES);
node->ptr->token |= cpu_to_le32(TD_STATUS_ACTIVE);
- temp = (u32) (mReq->req.dma + mReq->req.actual);
+ temp = (u32) (hwreq->req.dma + hwreq->req.actual);
if (length) {
node->ptr->page[0] = cpu_to_le32(temp);
for (i = 1; i < TD_PAGE_COUNT; i++) {
@@ -402,17 +402,17 @@ static int add_td_to_list(struct ci13xxx_ep *mEp, struct
ci13xxx_req *mReq,
}
}
- mReq->req.actual += length;
+ hwreq->req.actual += length;
- if (!list_empty(&mReq->tds)) {
+ if (!list_empty(&hwreq->tds)) {
/* get the last entry */
- lastnode = list_entry(mReq->tds.prev,
+ lastnode = list_entry(hwreq->tds.prev,
struct td_node, td);
lastnode->ptr->next = cpu_to_le32(node->dma);
}
INIT_LIST_HEAD(&node->td);
- list_add_tail(&node->td, &mReq->tds);
+ list_add_tail(&node->td, &hwreq->tds);
return 0;
}
@@ -429,25 +429,25 @@ static inline u8 _usb_addr(struct ci13xxx_ep *ep)
/**
* _hardware_queue: configures a request at hardware level
* @gadget: gadget
- * @mEp:endpoint
+ * @hwep: endpoint
*
* This function returns an error code
*/
-static int _hardware_enqueue(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq)
+static int _hardware_enqueue(struct ci13xxx_ep *hwep, struct ci13xxx_req
*hwreq)
{
- struct ci13xxx *ci = mEp->ci;
+ struct ci13xxx *ci = hwep->ci;
int ret = 0;
- unsigned rest = mReq->req.length;
+ unsigned rest = hwreq->req.length;
int pages = TD_PAGE_COUNT;
struct td_node *firstnode, *lastnode;
/* don't queue twice */
- if (mReq->req.status == -EALREADY)
+ if (hwreq->req.status == -EALREADY)
return -EALREADY;
- mReq->req.status = -EALREADY;
+ hwreq->req.status = -EALREADY;
- ret = usb_gadget_map_request(&ci->gadget, &mReq->req, mEp->dir);
+ ret = usb_gadget_map_request(&ci->gadget, &hwreq->req, hwep->dir);
if (ret)
return ret;
@@ -455,44 +455,44
[PATCH 16/20] usb: chipidea: i.MX: use devm_usb_get_phy_by_phandle to get phy
From: Sascha Hauer
This patch converts the driver to use devm_usb_get_phy_by_phandle
which makes the code smaller and a bit simpler.
Signed-off-by: Sascha Hauer
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 18d83ab..7e6f067 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -28,7 +28,6 @@
((struct usb_phy *)platform_get_drvdata(pdev))
struct ci13xxx_imx_data {
- struct device_node *phy_np;
struct usb_phy *phy;
struct platform_device *ci_pdev;
struct clk *clk;
@@ -97,9 +96,9 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
CI13XXX_PULLUP_ON_VBUS |
CI13XXX_DISABLE_STREAMING,
};
- struct platform_device *phy_pdev;
struct resource *res;
int ret;
+ struct usb_phy *phy;
if (of_find_property(pdev->dev.of_node, "fsl,usbmisc", NULL)
&& !usbmisc_ops)
@@ -131,18 +130,16 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
return ret;
}
- data->phy_np = of_parse_phandle(pdev->dev.of_node, "fsl,usbphy", 0);
- if (data->phy_np) {
- phy_pdev = of_find_device_by_node(data->phy_np);
- if (phy_pdev) {
- struct usb_phy *phy;
- phy = pdev_to_phy(phy_pdev);
- if (phy &&
- try_module_get(phy_pdev->dev.driver->owner)) {
- usb_phy_init(phy);
- data->phy = phy;
- }
+ phy = devm_usb_get_phy_by_phandle(&pdev->dev, "fsl,usbphy", 0);
+ if (!IS_ERR(phy)) {
+ ret = usb_phy_init(phy);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to init phy: %d\n", ret);
+ goto err_clk;
}
+ } else if (PTR_ERR(phy) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto err_clk;
}
/* we only support host now, so enable vbus here */
@@ -153,7 +150,7 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
dev_err(&pdev->dev,
"Failed to enable vbus regulator, err=%d\n",
ret);
- goto put_np;
+ goto err_clk;
}
} else {
data->reg_vbus = NULL;
@@ -207,9 +204,7 @@ disable_device:
err:
if (data->reg_vbus)
regulator_disable(data->reg_vbus);
-put_np:
- if (data->phy_np)
- of_node_put(data->phy_np);
+err_clk:
clk_disable_unprepare(data->clk);
return ret;
}
@@ -229,9 +224,6 @@ static int ci13xxx_imx_remove(struct platform_device *pdev)
module_put(data->phy->dev->driver->owner);
}
- if (data->phy_np)
- of_node_put(data->phy_np);
-
clk_disable_unprepare(data->clk);
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, 13 Jun 2013, Ming Lei wrote: > > For reasonably sophisticated host controllers like EHCI, the delay in > > responding to an interrupt doesn't matter much. But for simpler host > > EHCI might still benefit from the change: suppose uvc video is playing on > one EHCI bus, and mass storage's performance over another EHCI may > decrease because of the IRQ latency introduced. If multiple CPUs are involved, then we could see an improvement in the case where the two EHCI controllers share the same IRQ line. With different IRQs, though, everything would run in parallel on different CPUs, so there is no advantage. > > At this point we are talking about multiple changes: > > > > Moving the givebacks to a tasklet or threaded handler. > > > > Changing the USB completion handlers so that they can be called > > with interrupts enabled. > > > > Allowing the tasklet/thread to run with interrupts enabled. > > > > Moving more of the HCD processing into the tasklet/thread. > > > > Maybe other things too. In principle, the first and second items can > > be done simultaneously. > > Very good summery, we can push the 1st change with disabling local IRQ > when calling complete(), so that at least DMA unmapping can be done > with IRQ enabled, and at the same time do the API change, which > should be a bit slow but the mechanical way proposed by Oliver may > be OK. > > The 3rd item is easy once the 1st two items are completed. > > For the 4th one, it might be a long term thing, since refactoring > HCD interrupt handler is a bit complicated. Also, when the 1st > three items are completed, hard interrupt handler takes less time, > often less than 20us at average about EHCI, so I am wondering > if the 4th is worthy. Yes, I don't know about that. If the time spent in the hardirq processing is reasonably short then moving it to the threaded handler won't help very much. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/20] usb: chipidea: add PTW, PTS and STS handling
From: Michael Grzeschik
This patch makes it possible to configure the PTW, PTS and STS bits
inside the portsc register for host and device mode before the driver
starts and the phy can be addressed as hardware implementation is
designed.
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sascha Hauer
Signed-off-by: Alexander Shishkin
---
.../devicetree/bindings/usb/ci13xxx-imx.txt|5 ++
drivers/usb/chipidea/bits.h| 16 ++-
drivers/usb/chipidea/core.c| 48
include/linux/usb/chipidea.h |1 +
4 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
index 1c04a4c..184a8e0 100644
--- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
@@ -5,6 +5,11 @@ Required properties:
- reg: Should contain registers location and length
- interrupts: Should contain controller interrupt
+Recommended properies:
+- phy_type: the type of the phy connected to the core. Should be one
+ of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
+ property the PORTSC register won't be touched
+
Optional properties:
- fsl,usbphy: phandler of usb phy that connects to the only one port
- fsl,usbmisc: phandler of non-core register device, with one argument
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 050de85..aefa026 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -48,10 +48,24 @@
#define PORTSC_SUSP BIT(7)
#define PORTSC_HSPBIT(9)
#define PORTSC_PTC(0x0FUL << 16)
+/* PTS and PTW for non lpm version only */
+#define PORTSC_PTS(d) \
+ d) & 0x3) << 30) | (((d) & 0x4) ? BIT(25) : 0))
+#define PORTSC_PTWBIT(28)
+#define PORTSC_STSBIT(29)
/* DEVLC */
#define DEVLC_PSPD(0x03UL << 25)
-#defineDEVLC_PSPD_HS (0x02UL << 25)
+#define DEVLC_PSPD_HS (0x02UL << 25)
+#define DEVLC_PTW BIT(27)
+#define DEVLC_STS BIT(28)
+#define DEVLC_PTS(d) (((d) & 0x7) << 29)
+
+/* Encoding for DEVLC_PTS and PORTSC_PTS */
+#define PTS_UTMI 0
+#define PTS_ULPI 2
+#define PTS_SERIAL3
+#define PTS_HSIC 4
/* OTGSC */
#define OTGSC_IDPU BIT(5)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index fe47419..5e8d1ed 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -63,6 +63,8 @@
#include
#include
#include
+#include
+#include
#include "ci.h"
#include "udc.h"
@@ -207,6 +209,45 @@ static int hw_device_init(struct ci13xxx *ci, void __iomem
*base)
return 0;
}
+static void hw_phymode_configure(struct ci13xxx *ci)
+{
+ u32 portsc, lpm, sts;
+
+ switch (ci->platdata->phy_mode) {
+ case USBPHY_INTERFACE_MODE_UTMI:
+ portsc = PORTSC_PTS(PTS_UTMI);
+ lpm = DEVLC_PTS(PTS_UTMI);
+ break;
+ case USBPHY_INTERFACE_MODE_UTMIW:
+ portsc = PORTSC_PTS(PTS_UTMI) | PORTSC_PTW;
+ lpm = DEVLC_PTS(PTS_UTMI) | DEVLC_PTW;
+ break;
+ case USBPHY_INTERFACE_MODE_ULPI:
+ portsc = PORTSC_PTS(PTS_ULPI);
+ lpm = DEVLC_PTS(PTS_ULPI);
+ break;
+ case USBPHY_INTERFACE_MODE_SERIAL:
+ portsc = PORTSC_PTS(PTS_SERIAL);
+ lpm = DEVLC_PTS(PTS_SERIAL);
+ sts = 1;
+ break;
+ case USBPHY_INTERFACE_MODE_HSIC:
+ portsc = PORTSC_PTS(PTS_HSIC);
+ lpm = DEVLC_PTS(PTS_HSIC);
+ break;
+ default:
+ return;
+ }
+
+ if (ci->hw_bank.lpm) {
+ hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
+ hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+ } else {
+ hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
+ hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+ }
+}
+
/**
* hw_device_reset: resets chip (execute without interruption)
* @ci: the controller
@@ -223,6 +264,7 @@ int hw_device_reset(struct ci13xxx *ci, u32 mode)
while (hw_read(ci, OP_USBCMD, USBCMD_RST))
udelay(10); /* not RTOS friendly */
+ hw_phymode_configure(ci);
if (ci->platdata->notify_event)
ci->platdata->notify_event(ci,
@@ -368,6 +410,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return -ENODEV;
}
+ if (!dev->of_node && dev->parent)
+ dev->of_node = dev->parent->of_node;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap
[PATCH 15/20] usb: chipidea: usbmisc: use module_platform_driver
From: Philipp Zabel
This patch converts the driver to use the module_platform_driver
macro which makes the code smaller and a bit simpler.
Signed-off-by: Philipp Zabel
Signed-off-by: Michael Grzeschik
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/usbmisc_imx.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 1c6610a..588bae8 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -243,17 +243,7 @@ static struct platform_driver usbmisc_imx_driver = {
},
};
-static int usbmisc_imx_drv_init(void)
-{
- return platform_driver_register(&usbmisc_imx_driver);
-}
-subsys_initcall(usbmisc_imx_drv_init);
-
-static void usbmisc_imx_drv_exit(void)
-{
- platform_driver_unregister(&usbmisc_imx_driver);
-}
-module_exit(usbmisc_imx_drv_exit);
+module_platform_driver(usbmisc_imx_driver);
MODULE_ALIAS("platform:usbmisc-imx");
MODULE_LICENSE("GPL v2");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/20] usb: chipidea: move to pcim_* functions
From: Andy Shevchenko
This patch makes error path cleaner and probe function tidier.
Signed-off-by: Andy Shevchenko
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_pci.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_pci.c
b/drivers/usb/chipidea/ci13xxx_pci.c
index 59fab90..7cf5495 100644
--- a/drivers/usb/chipidea/ci13xxx_pci.c
+++ b/drivers/usb/chipidea/ci13xxx_pci.c
@@ -61,14 +61,13 @@ static int ci13xxx_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
- retval = pci_enable_device(pdev);
+ retval = pcim_enable_device(pdev);
if (retval)
- goto done;
+ return retval;
if (!pdev->irq) {
dev_err(&pdev->dev, "No IRQ, check BIOS/PCI setup!");
- retval = -ENODEV;
- goto disable_device;
+ return -ENODEV;
}
pci_set_master(pdev);
@@ -84,18 +83,12 @@ static int ci13xxx_pci_probe(struct pci_dev *pdev,
plat_ci = ci13xxx_add_device(&pdev->dev, res, nres, platdata);
if (IS_ERR(plat_ci)) {
dev_err(&pdev->dev, "ci13xxx_add_device failed!\n");
- retval = PTR_ERR(plat_ci);
- goto disable_device;
+ return PTR_ERR(plat_ci);
}
pci_set_drvdata(pdev, plat_ci);
return 0;
-
- disable_device:
- pci_disable_device(pdev);
- done:
- return retval;
}
/**
@@ -111,7 +104,6 @@ static void ci13xxx_pci_remove(struct pci_dev *pdev)
struct platform_device *plat_ci = pci_get_drvdata(pdev);
ci13xxx_remove_device(plat_ci);
- pci_disable_device(pdev);
}
/**
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/20] usb: chipidea: improve kconfig
From: Peter Chen Randy Dunlap reported this problem on i386: > drivers/built-in.o: In function `ci_hdrc_host_init': > (.text+0x2ce75c): undefined reference to `ehci_init_driver' > > When USB_EHCI_HCD=m and USB_CHIPIDEA=y. In fact, this problem is existed on all platforms which are using chipidea driver. The root cause of this problem is the chipidea host uses symbol exported from ehci-hcd, but chipidea core does not depends on USB_EHCI_HCD. So, chipidea driver will not be compiled as module if USB_EHCI_HCD=m. It is very hard to give a perfect solution since chipidea core depends on USB || USB_GADGET, and chipdiea host depends on both USB_EHCI_HCD and USB_CHIPIDEA, the same problem exists for gadget. To fix this problem, we had to have below assumptions: - If USB_EHCI_HCD=y && USB_GADGET=y, USB_CHIPIDEA can be 'y'. - If USB_EHCI_HCD=m && USB_GADGET=y, USB_CHIPIDEA=m or USB_CHIPIDEA_HOST can't be seen if USB_CHIPIDEA=y. It will cause compile error due to no glue layer for ehci: > error: #error "missing bus glue for ehci-hcd" So, we had to compile USB_CHIPIDEA=m if USB_EHCI_HCD=m, current ehci hcd core guarantee it. - If USB_EHCI_HCD=y && USB_GADGET=m, USB_CHIPIDEA=m or USB_CHIPIDEA_UDC can't be seen if USB_CHIPIDEA=y. Of cos, the gadget will out of working at this situation, so the user had to compile USB_CHIPIDEA=m. - USB_EHCI_HCD=m && USB_GADGET=m, we can't see USB_CHIPIDEA_HOST and USB_CHIPIDEA_UDC unless USB_CHIPIDEA=m. The reason why it has above assumptions: - If both ehci core and gadget core build as module, the chipidea has to build as module. - If one of ehci core or gadget core is built in, another is built as module, we can only enable the function which is built in, or enable both roles as modules (USB_CHIPIDEA=m), since chipidea core driver takes care of both host and device roles. Signed-off-by: Peter Chen Signed-off-by: Alexander Shishkin --- drivers/usb/chipidea/Kconfig |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index b2df442..eb2aa2e 100644 --- a/drivers/usb/chipidea/Kconfig +++ b/drivers/usb/chipidea/Kconfig @@ -12,15 +12,15 @@ if USB_CHIPIDEA config USB_CHIPIDEA_UDC bool "ChipIdea device controller" - depends on USB_GADGET=y || USB_GADGET=USB_CHIPIDEA + depends on USB_GADGET=y || USB_CHIPIDEA=m help Say Y here to enable device controller functionality of the ChipIdea driver. config USB_CHIPIDEA_HOST bool "ChipIdea host controller" - depends on USB=y || USB=USB_CHIPIDEA - depends on USB_EHCI_HCD=y + depends on USB=y + depends on USB_EHCI_HCD=y || USB_CHIPIDEA=m select USB_EHCI_ROOT_HUB_TT help Say Y here to enable host controller functionality of the -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/20] usb: chipidea: ci13xxx-imx: move static pdata into probe function
From: Michael Grzeschik
The pdata structure gets copied anyway inside ci13xxx_add_device
by platform_device_add. We don't need to have it static.
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sascha Hauer
Reviewed-by: Peter Chen
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 9cecfd5..18d83ab 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -87,17 +87,16 @@ EXPORT_SYMBOL_GPL(usbmisc_get_init_data);
/* End of common functions shared by usbmisc drivers*/
-static struct ci13xxx_platform_data ci13xxx_imx_platdata = {
- .name = "ci13xxx_imx",
- .flags = CI13XXX_REQUIRE_TRANSCEIVER |
- CI13XXX_PULLUP_ON_VBUS |
- CI13XXX_DISABLE_STREAMING,
- .capoffset = DEF_CAPOFFSET,
-};
-
static int ci13xxx_imx_probe(struct platform_device *pdev)
{
struct ci13xxx_imx_data *data;
+ struct ci13xxx_platform_data pdata = {
+ .name = "ci13xxx_imx",
+ .capoffset = DEF_CAPOFFSET,
+ .flags = CI13XXX_REQUIRE_TRANSCEIVER |
+ CI13XXX_PULLUP_ON_VBUS |
+ CI13XXX_DISABLE_STREAMING,
+ };
struct platform_device *phy_pdev;
struct resource *res;
int ret;
@@ -160,7 +159,7 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
data->reg_vbus = NULL;
}
- ci13xxx_imx_platdata.phy = data->phy;
+ pdata.phy = data->phy;
if (!pdev->dev.dma_mask)
pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
@@ -178,7 +177,7 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
data->ci_pdev = ci13xxx_add_device(&pdev->dev,
pdev->resource, pdev->num_resources,
- &ci13xxx_imx_platdata);
+ &pdata);
if (IS_ERR(data->ci_pdev)) {
ret = PTR_ERR(data->ci_pdev);
dev_err(&pdev->dev,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/20] usb: chipidea: remove superfluous pci_set_drvdata(pci, NULL)
From: Andy Shevchenko As drvdata is cleared to NULL at probe failure or at removal by the driver core, we don't have to call pci_set_drvdata(pci, NULL) any longer in each driver. Signed-off-by: Andy Shevchenko Signed-off-by: Alexander Shishkin --- drivers/usb/chipidea/ci13xxx_pci.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/chipidea/ci13xxx_pci.c b/drivers/usb/chipidea/ci13xxx_pci.c index a2a6ac8..59fab90 100644 --- a/drivers/usb/chipidea/ci13xxx_pci.c +++ b/drivers/usb/chipidea/ci13xxx_pci.c @@ -111,7 +111,6 @@ static void ci13xxx_pci_remove(struct pci_dev *pdev) struct platform_device *plat_ci = pci_get_drvdata(pdev); ci13xxx_remove_device(plat_ci); - pci_set_drvdata(pdev, NULL); pci_disable_device(pdev); } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/20] usb: chipidea: udc: add multiple td support to hardware_{en,de}queue
From: Michael Grzeschik
This patch removes the restriction of having a limited amount of only
four active tds on one endpoint. We use the linked list implementation
to manage all tds which get added and removed by hardware_{en,de}queue.
The removal of this restriction adds the driver to run into a hardware
errata. It's possible that the hardware will still address an transfer
descriptor that already got cleaned up. To solve this the patch also
postpone the cleanup of processed tds by one.
Signed-off-by: Michael Grzeschik
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci.h |1 +
drivers/usb/chipidea/core.c |1 -
drivers/usb/chipidea/udc.c | 192 +--
3 files changed, 111 insertions(+), 83 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index b0a6bce..9ef6860 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -58,6 +58,7 @@ struct ci13xxx_ep {
struct ci13xxx *ci;
spinlock_t *lock;
struct dma_pool *td_pool;
+ struct td_node *pending_td;
};
enum ci_role {
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 2ef0ce3..fe47419 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -44,7 +44,6 @@
* TODO List
* - OTG
* - Interrupt Traffic
- * - Handle requests which spawns into several TDs
* - GET_STATUS(device) - always reports 0
* - Gadget API (majority of optional features)
* - Suspend & Remote Wakeup
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 12819e4a..825bfeb 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -369,17 +369,11 @@ static int hw_usb_reset(struct ci13xxx *ci)
* UTIL block
*/
-static void setup_td_bits(struct td_node *tdnode, unsigned length)
-{
- memset(tdnode->ptr, 0, sizeof(*tdnode->ptr));
- tdnode->ptr->token = cpu_to_le32(length << __ffs(TD_TOTAL_BYTES));
- tdnode->ptr->token &= cpu_to_le32(TD_TOTAL_BYTES);
- tdnode->ptr->token |= cpu_to_le32(TD_STATUS_ACTIVE);
-}
-
static int add_td_to_list(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq,
unsigned length)
{
+ int i;
+ u32 temp;
struct td_node *lastnode, *node = kzalloc(sizeof(struct td_node),
GFP_ATOMIC);
@@ -393,7 +387,22 @@ static int add_td_to_list(struct ci13xxx_ep *mEp, struct
ci13xxx_req *mReq,
return -ENOMEM;
}
- setup_td_bits(node, length);
+ memset(node->ptr, 0, sizeof(struct ci13xxx_td));
+ node->ptr->token = cpu_to_le32(length << __ffs(TD_TOTAL_BYTES));
+ node->ptr->token &= cpu_to_le32(TD_TOTAL_BYTES);
+ node->ptr->token |= cpu_to_le32(TD_STATUS_ACTIVE);
+
+ temp = (u32) (mReq->req.dma + mReq->req.actual);
+ if (length) {
+ node->ptr->page[0] = cpu_to_le32(temp);
+ for (i = 1; i < TD_PAGE_COUNT; i++) {
+ u32 page = temp + i * CI13XXX_PAGE_SIZE;
+ page &= ~TD_RESERVED_MASK;
+ node->ptr->page[i] = cpu_to_le32(page);
+ }
+ }
+
+ mReq->req.actual += length;
if (!list_empty(&mReq->tds)) {
/* get the last entry */
@@ -427,9 +436,9 @@ static inline u8 _usb_addr(struct ci13xxx_ep *ep)
static int _hardware_enqueue(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq)
{
struct ci13xxx *ci = mEp->ci;
- unsigned i;
int ret = 0;
- unsigned length = mReq->req.length;
+ unsigned rest = mReq->req.length;
+ int pages = TD_PAGE_COUNT;
struct td_node *firstnode, *lastnode;
/* don't queue twice */
@@ -442,21 +451,29 @@ static int _hardware_enqueue(struct ci13xxx_ep *mEp,
struct ci13xxx_req *mReq)
if (ret)
return ret;
- firstnode = list_first_entry(&mReq->tds,
- struct td_node, td);
+ /*
+* The first buffer could be not page aligned.
+* In that case we have to span into one extra td.
+*/
+ if (mReq->req.dma % PAGE_SIZE)
+ pages--;
- setup_td_bits(firstnode, length);
+ if (rest == 0)
+ add_td_to_list(mEp, mReq, 0);
- firstnode->ptr->page[0] = cpu_to_le32(mReq->req.dma);
- for (i = 1; i < TD_PAGE_COUNT; i++) {
- u32 page = mReq->req.dma + i * CI13XXX_PAGE_SIZE;
- page &= ~TD_RESERVED_MASK;
- firstnode->ptr->page[i] = cpu_to_le32(page);
+ while (rest > 0) {
+ unsigned count = min(mReq->req.length - mReq->req.actual,
+ (unsigned)(pages * CI13XXX_PAGE_SIZE));
+
[PATCH 00/20] usb: chipidea: updates for v3.11
Hi,
Here's a set of chipidea updates for v3.11. These are mostly fixes and
cleanups, but also include isoch endpoint support and multi-td
transfers by Michael.
On top there are two mass rename patches that I've been meaning to
push for a while, particularly the one that gets rid of "ci13xxx".
Everything is sparse, smatch, checkpatch and coccinelle clean.
Alexander Shishkin (2):
usb: chipidea: get rid of camelcase names
usb: chipidea: drop "13xxx" infix
Andy Shevchenko (2):
usb: chipidea: remove superfluous pci_set_drvdata(pci, NULL)
usb: chipidea: move to pcim_* functions
Fabio Estevam (6):
usb: chipidea: ci13xxx_imx: let device core handle pinctrl
usb: chipidea: usbmisc_imx: Staticize usbmisc_imx_drv_init/exit
usb: chipidea: ci13xxx_imx: fix error path
usb: chipidea: ci13xxx_imx: remove reg_vbus
usb: chipidea: ci13xxx_imx: check if 'data->phy_np' is not NULL
usb: chipidea: ci13xxx_imx: remove 'phy_np'
Michael Grzeschik (6):
usb: chipidea: udc: configure iso endpoints
usb: chipidea: udc: manage dynamic amount of tds with a linked list
usb: chipidea: udc: add multiple td support to hardware_{en,de}queue
usb: add devicetree helpers for determining dr_mode and phy_type
usb: chipidea: add PTW, PTS and STS handling
usb: chipidea: ci13xxx-imx: move static pdata into probe function
Peter Chen (1):
usb: chipidea: improve kconfig
Philipp Zabel (1):
usb: chipidea: usbmisc: use module_platform_driver
Sascha Hauer (2):
usb: chipidea: introduce dual role mode pdata flags
usb: chipidea: i.MX: use devm_usb_get_phy_by_phandle to get phy
.../devicetree/bindings/usb/ci13xxx-imx.txt|6 +
drivers/usb/chipidea/Kconfig |6 +-
drivers/usb/chipidea/Makefile |6 +-
drivers/usb/chipidea/bits.h| 16 +-
drivers/usb/chipidea/ci.h | 51 +-
.../usb/chipidea/{ci13xxx_imx.c => ci_hdrc_imx.c} | 116 ++-
.../usb/chipidea/{ci13xxx_imx.h => ci_hdrc_imx.h} |0
.../usb/chipidea/{ci13xxx_msm.c => ci_hdrc_msm.c} | 49 +-
.../usb/chipidea/{ci13xxx_pci.c => ci_hdrc_pci.c} | 60 +-
drivers/usb/chipidea/core.c| 109 ++-
drivers/usb/chipidea/debug.c | 61 +-
drivers/usb/chipidea/debug.h |8 +-
drivers/usb/chipidea/host.c| 10 +-
drivers/usb/chipidea/host.h|4 +-
drivers/usb/chipidea/udc.c | 785 +++-
drivers/usb/chipidea/udc.h | 26 +-
drivers/usb/chipidea/usbmisc_imx.c | 14 +-
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/of.c | 47 ++
drivers/usb/usb-common.c | 35 +
include/linux/usb/chipidea.h | 31 +-
include/linux/usb/of.h | 28 +
include/linux/usb/otg.h|7 +
include/linux/usb/phy.h|9 +
24 files changed, 886 insertions(+), 599 deletions(-)
rename drivers/usb/chipidea/{ci13xxx_imx.c => ci_hdrc_imx.c} (66%)
rename drivers/usb/chipidea/{ci13xxx_imx.h => ci_hdrc_imx.h} (100%)
rename drivers/usb/chipidea/{ci13xxx_msm.c => ci_hdrc_msm.c} (58%)
rename drivers/usb/chipidea/{ci13xxx_pci.c => ci_hdrc_pci.c} (68%)
create mode 100644 drivers/usb/phy/of.c
create mode 100644 include/linux/usb/of.h
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/20] usb: add devicetree helpers for determining dr_mode and phy_type
From: Michael Grzeschik
This adds two little devicetree helper functions for determining the
dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
the devicetree.
Signed-off-by: Michael Grzeschik
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Sascha Hauer
Acked-by: Felipe Balbi
Signed-off-by: Alexander Shishkin
---
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/of.c | 47 ++
drivers/usb/usb-common.c | 35 ++
include/linux/usb/of.h | 28 +++
include/linux/usb/otg.h |7 +++
include/linux/usb/phy.h |9 +
6 files changed, 127 insertions(+)
create mode 100644 drivers/usb/phy/of.c
create mode 100644 include/linux/usb/of.h
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index a9169cb..070eca3 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_USB_PHY) += phy.o
+obj-$(CONFIG_OF) += of.o
# transceiver drivers, keep the list sorted
diff --git a/drivers/usb/phy/of.c b/drivers/usb/phy/of.c
new file mode 100644
index 000..7ea0154
--- /dev/null
+++ b/drivers/usb/phy/of.c
@@ -0,0 +1,47 @@
+/*
+ * USB of helper code
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static const char *const usbphy_modes[] = {
+ [USBPHY_INTERFACE_MODE_UNKNOWN] = "",
+ [USBPHY_INTERFACE_MODE_UTMI]= "utmi",
+ [USBPHY_INTERFACE_MODE_UTMIW] = "utmi_wide",
+ [USBPHY_INTERFACE_MODE_ULPI]= "ulpi",
+ [USBPHY_INTERFACE_MODE_SERIAL] = "serial",
+ [USBPHY_INTERFACE_MODE_HSIC]= "hsic",
+};
+
+/**
+ * of_usb_get_phy_mode - Get phy mode for given device_node
+ * @np:Pointer to the given device_node
+ *
+ * The function gets phy interface string from property 'phy_type',
+ * and returns the correspondig enum usb_phy_interface
+ */
+enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np)
+{
+ const char *phy_type;
+ int err, i;
+
+ err = of_property_read_string(np, "phy_type", &phy_type);
+ if (err < 0)
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
+
+ for (i = 0; i < ARRAY_SIZE(usbphy_modes); i++)
+ if (!strcmp(phy_type, usbphy_modes[i]))
+ return i;
+
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
+}
+EXPORT_SYMBOL_GPL(of_usb_get_phy_mode);
diff --git a/drivers/usb/usb-common.c b/drivers/usb/usb-common.c
index 0db0a91..675384d 100644
--- a/drivers/usb/usb-common.c
+++ b/drivers/usb/usb-common.c
@@ -13,7 +13,9 @@
#include
#include
+#include
#include
+#include
#include
const char *usb_otg_state_string(enum usb_otg_state state)
@@ -79,4 +81,37 @@ const char *usb_state_string(enum usb_device_state state)
}
EXPORT_SYMBOL_GPL(usb_state_string);
+#ifdef CONFIG_OF
+static const char *const usb_dr_modes[] = {
+ [USB_DR_MODE_UNKNOWN] = "",
+ [USB_DR_MODE_HOST] = "host",
+ [USB_DR_MODE_PERIPHERAL]= "peripheral",
+ [USB_DR_MODE_OTG] = "otg",
+};
+
+/**
+ * of_usb_get_dr_mode - Get dual role mode for given device_node
+ * @np:Pointer to the given device_node
+ *
+ * The function gets phy interface string from property 'dr_mode',
+ * and returns the correspondig enum usb_dr_mode
+ */
+enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
+{
+ const char *dr_mode;
+ int err, i;
+
+ err = of_property_read_string(np, "dr_mode", &dr_mode);
+ if (err < 0)
+ return USB_DR_MODE_UNKNOWN;
+
+ for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
+ if (!strcmp(dr_mode, usb_dr_modes[i]))
+ return i;
+
+ return USB_DR_MODE_UNKNOWN;
+}
+EXPORT_SYMBOL_GPL(of_usb_get_dr_mode);
+#endif
+
MODULE_LICENSE("GPL");
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
new file mode 100644
index 000..e460a24
--- /dev/null
+++ b/include/linux/usb/of.h
@@ -0,0 +1,28 @@
+/*
+ * OF helpers for usb devices.
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_USB_OF_H
+#define __LINUX_USB_OF_H
+
+#include
+#include
+
+#ifdef CONFIG_OF
+enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
+enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np);
+#else
+static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node
*np)
+{
+ return USBPHY_INTERFACE_MODE_UNKNOWN;
+}
+
+static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
+{
+ return USB_DR_MODE_UNKNOWN;
+}
+#endif
+
+#endif /* __LINUX_USB_OF_H */
diff
[PATCH 04/20] usb: chipidea: ci13xxx_imx: fix error path
From: Fabio Estevam
If usbmisc_ops->post() fails it should point the error path to release all
previously acquired resources, so adjust it to call ci13xxx_remove_device().
While at it, remove the unnecessary 'plat_ci' indirection, as we can directly
use the private structure.
Signed-off-by: Fabio Estevam
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 45bb9b5..24f46e1 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -98,7 +98,7 @@ static struct ci13xxx_platform_data ci13xxx_imx_platdata = {
static int ci13xxx_imx_probe(struct platform_device *pdev)
{
struct ci13xxx_imx_data *data;
- struct platform_device *plat_ci, *phy_pdev;
+ struct platform_device *phy_pdev;
struct device_node *phy_np;
struct resource *res;
struct regulator *reg_vbus;
@@ -180,11 +180,11 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
}
}
- plat_ci = ci13xxx_add_device(&pdev->dev,
+ data->ci_pdev = ci13xxx_add_device(&pdev->dev,
pdev->resource, pdev->num_resources,
&ci13xxx_imx_platdata);
- if (IS_ERR(plat_ci)) {
- ret = PTR_ERR(plat_ci);
+ if (IS_ERR(data->ci_pdev)) {
+ ret = PTR_ERR(data->ci_pdev);
dev_err(&pdev->dev,
"Can't register ci_hdrc platform device, err=%d\n",
ret);
@@ -196,11 +196,10 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev,
"usbmisc post failed, ret=%d\n", ret);
- goto put_np;
+ goto disable_device;
}
}
- data->ci_pdev = plat_ci;
platform_set_drvdata(pdev, data);
pm_runtime_no_callbacks(&pdev->dev);
@@ -208,6 +207,8 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
return 0;
+disable_device:
+ ci13xxx_remove_device(data->ci_pdev);
err:
if (reg_vbus)
regulator_disable(reg_vbus);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/20] usb: chipidea: ci13xxx_imx: let device core handle pinctrl
From: Fabio Estevam
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for handling pinctrl.
So remove devm_pinctrl_get_select_default() from the driver.
Cc:
Signed-off-by: Fabio Estevam
Tested-by: Shawn Guo
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 585099a..45bb9b5 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include "ci.h"
#include "ci13xxx_imx.h"
@@ -103,7 +102,6 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
struct device_node *phy_np;
struct resource *res;
struct regulator *reg_vbus;
- struct pinctrl *pinctrl;
int ret;
if (of_find_property(pdev->dev.of_node, "fsl,usbmisc", NULL)
@@ -122,11 +120,6 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
return -ENOENT;
}
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev, "pinctrl get/select failed, err=%ld\n",
- PTR_ERR(pinctrl));
-
data->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(data->clk)) {
dev_err(&pdev->dev,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/20] usb: chipidea: udc: configure iso endpoints
From: Michael Grzeschik
This patch adds iso endpoint support to the device controller.
It makes use of the multiplication bits in the maxpacket field
of the endpoint and calculates the multiplier bits for each
transfer description on every request.
Signed-off-by: Michael Grzeschik
Reviewed-by: Peter Chen
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/core.c |2 +-
drivers/usb/chipidea/udc.c | 20 +++-
drivers/usb/chipidea/udc.h |1 +
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 49b098b..2ef0ce3 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -43,7 +43,7 @@
*
* TODO List
* - OTG
- * - Isochronous & Interrupt Traffic
+ * - Interrupt Traffic
* - Handle requests which spawns into several TDs
* - GET_STATUS(device) - always reports 0
* - Gadget API (majority of optional features)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 519ead2..e9a57bb0 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -466,6 +466,14 @@ static int _hardware_enqueue(struct ci13xxx_ep *mEp,
struct ci13xxx_req *mReq)
mEp->qh.ptr->td.token &=
cpu_to_le32(~(TD_STATUS_HALTED|TD_STATUS_ACTIVE));
+ if (mEp->type == USB_ENDPOINT_XFER_ISOC) {
+ u32 mul = mReq->req.length / mEp->ep.maxpacket;
+
+ if (mReq->req.length % mEp->ep.maxpacket)
+ mul++;
+ mEp->qh.ptr->cap |= mul << __ffs(QH_MULT);
+ }
+
wmb(); /* synchronize before ep prime */
ret = hw_ep_prime(ci, mEp->num, mEp->dir,
@@ -678,6 +686,12 @@ static int _ep_queue(struct usb_ep *ep, struct usb_request
*req,
}
}
+ if (usb_endpoint_xfer_isoc(mEp->ep.desc) &&
+ mReq->req.length > (1 + mEp->ep.mult) * mEp->ep.maxpacket) {
+ dev_err(mEp->ci->dev, "request length too big for
isochronous\n");
+ return -EMSGSIZE;
+ }
+
/* first nuke then test link, e.g. previous status has not sent */
if (!list_empty(&mReq->queue)) {
dev_err(mEp->ci->dev, "request already in queue\n");
@@ -1060,7 +1074,8 @@ static int ep_enable(struct usb_ep *ep,
mEp->num = usb_endpoint_num(desc);
mEp->type = usb_endpoint_type(desc);
- mEp->ep.maxpacket = usb_endpoint_maxp(desc);
+ mEp->ep.maxpacket = usb_endpoint_maxp(desc) & 0x07ff;
+ mEp->ep.mult = QH_ISO_MULT(usb_endpoint_maxp(desc));
if (mEp->type == USB_ENDPOINT_XFER_CONTROL)
cap |= QH_IOS;
@@ -1246,6 +1261,9 @@ static int ep_set_halt(struct usb_ep *ep, int value)
if (ep == NULL || mEp->ep.desc == NULL)
return -EINVAL;
+ if (usb_endpoint_xfer_isoc(mEp->ep.desc))
+ return -EOPNOTSUPP;
+
spin_lock_irqsave(mEp->lock, flags);
#ifndef STALL_IN
diff --git a/drivers/usb/chipidea/udc.h b/drivers/usb/chipidea/udc.h
index d12e8b5..a75724a 100644
--- a/drivers/usb/chipidea/udc.h
+++ b/drivers/usb/chipidea/udc.h
@@ -50,6 +50,7 @@ struct ci13xxx_qh {
#define QH_MAX_PKT(0x07FFUL << 16)
#define QH_ZLTBIT(29)
#define QH_MULT (0x0003UL << 30)
+#define QH_ISO_MULT(x) ((x >> 11) & 0x03)
/* 1 */
u32 curr;
/* 2 - 8 */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/20] usb: chipidea: introduce dual role mode pdata flags
From: Sascha Hauer
Even if a chipidea core is otg capable the board may not be. This allows
to explicitly set the core to host/peripheral mode. Without these flags
the driver falls back to the old behaviour.
Signed-off-by: Sascha Hauer
Signed-off-by: Alexander Shishkin
---
.../devicetree/bindings/usb/ci13xxx-imx.txt|1 +
drivers/usb/chipidea/core.c| 24 +++-
include/linux/usb/chipidea.h |2 +-
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
index 184a8e0..b4b5b79 100644
--- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
@@ -9,6 +9,7 @@ Recommended properies:
- phy_type: the type of the phy connected to the core. Should be one
of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
property the PORTSC register won't be touched
+- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
Optional properties:
- fsl,usbphy: phandler of usb phy that connects to the only one port
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5e8d1ed..915b486 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -404,6 +404,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
struct resource *res;
void __iomem*base;
int ret;
+ enum usb_dr_mode dr_mode;
if (!dev->platform_data) {
dev_err(dev, "platform data missing\n");
@@ -455,14 +456,25 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (!ci->platdata->phy_mode)
ci->platdata->phy_mode = of_usb_get_phy_mode(dev->of_node);
+ if (!ci->platdata->dr_mode)
+ ci->platdata->dr_mode = of_usb_get_dr_mode(dev->of_node);
+
+ if (ci->platdata->dr_mode == USB_DR_MODE_UNKNOWN)
+ ci->platdata->dr_mode = USB_DR_MODE_OTG;
+
+ dr_mode = ci->platdata->dr_mode;
/* initialize role(s) before the interrupt is requested */
- ret = ci_hdrc_host_init(ci);
- if (ret)
- dev_info(dev, "doesn't support host\n");
+ if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
+ ret = ci_hdrc_host_init(ci);
+ if (ret)
+ dev_info(dev, "doesn't support host\n");
+ }
- ret = ci_hdrc_gadget_init(ci);
- if (ret)
- dev_info(dev, "doesn't support gadget\n");
+ if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_PERIPHERAL) {
+ ret = ci_hdrc_gadget_init(ci);
+ if (ret)
+ dev_info(dev, "doesn't support gadget\n");
+ }
if (!ci->roles[CI_ROLE_HOST] && !ci->roles[CI_ROLE_GADGET]) {
dev_err(dev, "no supported roles\n");
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 1a2aa18..b314647 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -20,7 +20,7 @@ struct ci13xxx_platform_data {
#define CI13XXX_REQUIRE_TRANSCEIVERBIT(1)
#define CI13XXX_PULLUP_ON_VBUS BIT(2)
#define CI13XXX_DISABLE_STREAMING BIT(3)
-
+ enum usb_dr_modedr_mode;
#define CI13XXX_CONTROLLER_RESET_EVENT 0
#define CI13XXX_CONTROLLER_STOPPED_EVENT 1
void(*notify_event) (struct ci13xxx *ci, unsigned event);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/20] usb: chipidea: usbmisc_imx: Staticize usbmisc_imx_drv_init/exit
From: Fabio Estevam
Fix the following sparse warnings:
drivers/usb/chipidea/usbmisc_imx.c:246:5: warning: symbol
'usbmisc_imx_drv_init' was not declared. Should it be static?
drivers/usb/chipidea/usbmisc_imx.c:252:6: warning: symbol
'usbmisc_imx_drv_exit' was not declared. Should it be static?
Signed-off-by: Fabio Estevam
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/usbmisc_imx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 714a6bd..1c6610a 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -243,13 +243,13 @@ static struct platform_driver usbmisc_imx_driver = {
},
};
-int usbmisc_imx_drv_init(void)
+static int usbmisc_imx_drv_init(void)
{
return platform_driver_register(&usbmisc_imx_driver);
}
subsys_initcall(usbmisc_imx_drv_init);
-void usbmisc_imx_drv_exit(void)
+static void usbmisc_imx_drv_exit(void)
{
platform_driver_unregister(&usbmisc_imx_driver);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/20] usb: chipidea: ci13xxx_imx: check if 'data->phy_np' is not NULL
From: Fabio Estevam Similarly as it is done in ci13xxx_imx_remove(), only calls of_node_put if data->phy_np is not NULL. Signed-off-by: Fabio Estevam Signed-off-by: Alexander Shishkin --- drivers/usb/chipidea/ci13xxx_imx.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/ci13xxx_imx.c b/drivers/usb/chipidea/ci13xxx_imx.c index 1b100c8..5fac2a1 100644 --- a/drivers/usb/chipidea/ci13xxx_imx.c +++ b/drivers/usb/chipidea/ci13xxx_imx.c @@ -232,7 +232,8 @@ static int ci13xxx_imx_remove(struct platform_device *pdev) module_put(data->phy->dev->driver->owner); } - of_node_put(data->phy_np); + if (data->phy_np) + of_node_put(data->phy_np); clk_disable_unprepare(data->clk); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/20] usb: chipidea: ci13xxx_imx: remove reg_vbus
From: Fabio Estevam
There is no need to keep a 'reg_vbus' indirection, so get rid of it.
The motivation for doing this change is that in the case of error, the current
code only sets the local reg_vbus to NULL instead of updating the private
structure 'data->reg_vbus'.
Updating only the local reg_vbus is wrong, since we currently check for
data->reg_vbus in the ci13xxx_imx_remove() function.
In order to avoid such issue, just use 'data->reg_vbus' directly.
Signed-off-by: Fabio Estevam
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/ci13xxx_imx.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 24f46e1..1b100c8 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -101,7 +101,6 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
struct platform_device *phy_pdev;
struct device_node *phy_np;
struct resource *res;
- struct regulator *reg_vbus;
int ret;
if (of_find_property(pdev->dev.of_node, "fsl,usbmisc", NULL)
@@ -150,18 +149,17 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
}
/* we only support host now, so enable vbus here */
- reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
- if (!IS_ERR(reg_vbus)) {
- ret = regulator_enable(reg_vbus);
+ data->reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
+ if (!IS_ERR(data->reg_vbus)) {
+ ret = regulator_enable(data->reg_vbus);
if (ret) {
dev_err(&pdev->dev,
"Failed to enable vbus regulator, err=%d\n",
ret);
goto put_np;
}
- data->reg_vbus = reg_vbus;
} else {
- reg_vbus = NULL;
+ data->reg_vbus = NULL;
}
ci13xxx_imx_platdata.phy = data->phy;
@@ -210,8 +208,8 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
disable_device:
ci13xxx_remove_device(data->ci_pdev);
err:
- if (reg_vbus)
- regulator_disable(reg_vbus);
+ if (data->reg_vbus)
+ regulator_disable(data->reg_vbus);
put_np:
if (phy_np)
of_node_put(phy_np);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/20] usb: chipidea: udc: manage dynamic amount of tds with a linked list
From: Michael Grzeschik
Instead of having a limited number of usable tds in the udc we use a
linked list to support dynamic amount of needed tds for all special
gadget types. This improves throughput.
Signed-off-by: Michael Grzeschik
Reviewed-by: Felipe Balbi
Signed-off-by: Alexander Shishkin
---
drivers/usb/chipidea/debug.c | 19 +++--
drivers/usb/chipidea/udc.c | 161 +-
drivers/usb/chipidea/udc.h | 11 +--
3 files changed, 129 insertions(+), 62 deletions(-)
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 36a7063..64b8c32 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -162,6 +162,7 @@ static int ci_requests_show(struct seq_file *s, void *data)
unsigned long flags;
struct list_head *ptr = NULL;
struct ci13xxx_req *req = NULL;
+ struct td_node *node, *tmpnode;
unsigned i, j, qsize = sizeof(struct ci13xxx_td)/sizeof(u32);
if (ci->role != CI_ROLE_GADGET) {
@@ -174,13 +175,17 @@ static int ci_requests_show(struct seq_file *s, void
*data)
list_for_each(ptr, &ci->ci13xxx_ep[i].qh.queue) {
req = list_entry(ptr, struct ci13xxx_req, queue);
- seq_printf(s, "EP=%02i: TD=%08X %s\n",
- i % (ci->hw_ep_max / 2), (u32)req->dma,
- ((i < ci->hw_ep_max/2) ? "RX" : "TX"));
-
- for (j = 0; j < qsize; j++)
- seq_printf(s, " %04X:%08X\n", j,
- *((u32 *)req->ptr + j));
+ list_for_each_entry_safe(node, tmpnode, &req->tds, td) {
+ seq_printf(s, "EP=%02i: TD=%08X %s\n",
+ i % (ci->hw_ep_max / 2),
+ (u32)node->dma,
+ ((i < ci->hw_ep_max/2) ?
+ "RX" : "TX"));
+
+ for (j = 0; j < qsize; j++)
+ seq_printf(s, " %04X:%08X\n", j,
+ *((u32 *)node->ptr + j));
+ }
}
spin_unlock_irqrestore(&ci->lock, flags);
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index e9a57bb0..12819e4a 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -368,6 +368,46 @@ static int hw_usb_reset(struct ci13xxx *ci)
/**
* UTIL block
*/
+
+static void setup_td_bits(struct td_node *tdnode, unsigned length)
+{
+ memset(tdnode->ptr, 0, sizeof(*tdnode->ptr));
+ tdnode->ptr->token = cpu_to_le32(length << __ffs(TD_TOTAL_BYTES));
+ tdnode->ptr->token &= cpu_to_le32(TD_TOTAL_BYTES);
+ tdnode->ptr->token |= cpu_to_le32(TD_STATUS_ACTIVE);
+}
+
+static int add_td_to_list(struct ci13xxx_ep *mEp, struct ci13xxx_req *mReq,
+ unsigned length)
+{
+ struct td_node *lastnode, *node = kzalloc(sizeof(struct td_node),
+ GFP_ATOMIC);
+
+ if (node == NULL)
+ return -ENOMEM;
+
+ node->ptr = dma_pool_alloc(mEp->td_pool, GFP_ATOMIC,
+ &node->dma);
+ if (node->ptr == NULL) {
+ kfree(node);
+ return -ENOMEM;
+ }
+
+ setup_td_bits(node, length);
+
+ if (!list_empty(&mReq->tds)) {
+ /* get the last entry */
+ lastnode = list_entry(mReq->tds.prev,
+ struct td_node, td);
+ lastnode->ptr->next = cpu_to_le32(node->dma);
+ }
+
+ INIT_LIST_HEAD(&node->td);
+ list_add_tail(&node->td, &mReq->tds);
+
+ return 0;
+}
+
/**
* _usb_addr: calculates endpoint address from direction & number
* @ep: endpoint
@@ -390,6 +430,7 @@ static int _hardware_enqueue(struct ci13xxx_ep *mEp, struct
ci13xxx_req *mReq)
unsigned i;
int ret = 0;
unsigned length = mReq->req.length;
+ struct td_node *firstnode, *lastnode;
/* don't queue twice */
if (mReq->req.status == -EALREADY)
@@ -397,58 +438,46 @@ static int _hardware_enqueue(struct ci13xxx_ep *mEp,
struct ci13xxx_req *mReq)
mReq->req.status = -EALREADY;
- if (mReq->req.zero && length && (length % mEp->ep.maxpacket == 0)) {
- mReq->zptr = dma_pool_alloc(mEp->td_pool, GFP_ATOMIC,
- &mReq->zdma);
- if (mReq->zptr == NULL)
- return -ENOMEM;
-
- memset(mReq->zptr, 0, sizeof(*mReq->zptr));
- mReq->zptr->next= cpu_to_le
Re: [GIT PULL] USB patches for v3.11 merge window
HI, On Thu, Jun 13, 2013 at 05:53:50PM +0300, Roger Quadros wrote: > On 06/13/2013 05:17 PM, Felipe Balbi wrote: > > Hi, > > > > On Thu, Jun 13, 2013 at 12:05:36PM +0300, Roger Quadros wrote: > >> On 06/13/2013 01:37 AM, Greg KH wrote: > >>> On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote: > On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote: > > Hi, > > > > On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote: > >>> But, I get a build error with your tree pulled in, at the link point > >>> in > >>> time: > >>> > >>> ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined! > >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb3.ko] > >>> undefined! > >>> ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined! > >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb2.ko] > >>> undefined! > >>> ERROR: "usb_add_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined! > >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined! > >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-omap-usb3.ko] undefined! > >>> ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-omap-usb3.ko] undefined! > >>> ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-nop.ko] undefined! > >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-nop.ko] undefined! > >>> ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-isp1301.ko] undefined! > >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-isp1301.ko] undefined! > >>> ERROR: "usb_add_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! > >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] > >>> undefined! > >>> ERROR: "usb_get_phy" [drivers/usb/musb/ux500.ko] undefined! > >>> ERROR: "usb_put_phy" [drivers/usb/musb/ux500.ko] undefined! > >>> ERROR: "usb_put_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined! > >>> ERROR: "usb_get_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined! > >>> ERROR: "devm_usb_get_phy" [drivers/usb/gadget/mv_udc.ko] undefined! > >>> ERROR: "devm_usb_get_phy" [drivers/usb/dwc3/dwc3.ko] undefined! > >>> ERROR: "devm_usb_get_phy_by_phandle" [drivers/usb/dwc3/dwc3.ko] > >>> undefined! > >>> ERROR: "usb_get_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > >>> ERROR: "usb_put_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > >>> ERROR: "usb_get_phy" [drivers/power/isp1704_charger.ko] undefined! > >>> ERROR: "usb_put_phy" [drivers/power/isp1704_charger.ko] undefined! > >>> > >>> Any ideas? > >> > >> hmm... I think it was Roger's patches changing the way PHY layer is > >> enabled, do you mind if I drop that for now ? I would have to rebase, > >> but I guess it's a necessary evil at this point. > > > > I took the silence as a yes and pushed a new tag with Roger's patches > > removed. I have also removed one musb patch which wasn't necessary after > > all. > > Sorry for the silence, I went to lunch :) > > > Here's an updated pull request, which I have compiled on ARM and x86 > > and didn't see the linking problem mentioned above: > > Ok, thanks, I'll try it out now... > >>> > >>> That worked, now pulled and pushed out, thanks. > >> > >> Hi Greg, > >> > >> I tried to reproduce the above problem but couldn't. Could you please > >> share your .config that caused the issue and the command sequence you used > >> to arrive > >> at the problem? Thanks. > >> > >> By any chance is it possible that there were some stale modules lying > >> around > >> in your tree? > >> > >> The problem shouldn't happen because the symbols are defined in phy.c > >> (USB_PHY) which > >> is selected by the PHY drivers. Even if USB_PHY is not selected, the > >> functions (except > >> usb_add/remove_phy() are defined as inlines in /include/linux/usb/phy.h > > > > If CONFIG_USB is set to M you should see the problem since EHCI-OMAP > > would 'select' (meaning set Y) to the PHY driver. Kbuild won't > > statically link anything from a directory which was entered due to M. > > > > Not sure if that sounds as clear as I expected :-p > > > > OK thanks. Maybe setting USB_PHY as tristate should fix it. I'll try > it out tomorrow. in your patchset you removed USB_PHY right ? That's what caused the issue. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Thu, 13 Jun 2013, Ming Lei wrote: > - using interrupt threaded handler(default) > 33.440 MB/sec > > - using tasklet(#undef USB_HCD_THREADED_IRQ) > 34.29 MB/sec > > - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c ) > 34.260 MB/s > > > So looks usb mass storage performance loss can be observed with > interrupt threaded handler because one mass storage read/write sectors > requires at least 3 interrupts which wake up usb-storage thread 3 times > (each interrupt wakeup the usb-storage each time), introducing irq threaded > handler will make 2 threads to be waken up about 6 times for one read/write. > > I think usb mass storage transfer handler need to be rewritten, otherwise > it may become worsen after using irq threaded handler in USB 3.0.(the > above device can reach >120MB/sec with hardware handler or tasklet handler, > which means about ~3K interrupts/sec, so ~6K contexts switch in case of > using irq threaded handler) > > So how about supporting tasklet first, then convert to interrupt > threaded handler > after usb mass storage transfer is rewritten without performance loss? > (rewriting > usb mass storage transfer handler may need some time and work since storage > stability/correctness is extremely important, :-) Maybe we should simply copy what the networking people do. They are very concerned about performance and latency; whatever technique they use should be good for USB too. > Also another problem with irq threaded handler is that there is no sort of > tasklet_schedule() interface to wakeup the thread handler manually, so > I have to use work to schedule some URB giveback from drivers(root hub > transfer, unlink), even though that isn't a big deal but will cause code a > bit > much/complicated, :-) Yes, I was going to bring that up. Thomas, sometimes we need the IRQ handler thread to do some work even though an interrupt hasn't occurred. Is there an API for this, or can one be added? 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: [GIT PULL] USB patches for v3.11 merge window
On 06/13/2013 05:17 PM, Felipe Balbi wrote: > Hi, > > On Thu, Jun 13, 2013 at 12:05:36PM +0300, Roger Quadros wrote: >> On 06/13/2013 01:37 AM, Greg KH wrote: >>> On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote: On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote: > Hi, > > On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote: >>> But, I get a build error with your tree pulled in, at the link point in >>> time: >>> >>> ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined! >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined! >>> ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined! >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined! >>> ERROR: "usb_add_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined! >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined! >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-omap-usb3.ko] undefined! >>> ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-omap-usb3.ko] undefined! >>> ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-nop.ko] undefined! >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-nop.ko] undefined! >>> ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-isp1301.ko] undefined! >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-isp1301.ko] undefined! >>> ERROR: "usb_add_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! >>> ERROR: "usb_remove_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] >>> undefined! >>> ERROR: "usb_get_phy" [drivers/usb/musb/ux500.ko] undefined! >>> ERROR: "usb_put_phy" [drivers/usb/musb/ux500.ko] undefined! >>> ERROR: "usb_put_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined! >>> ERROR: "usb_get_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined! >>> ERROR: "devm_usb_get_phy" [drivers/usb/gadget/mv_udc.ko] undefined! >>> ERROR: "devm_usb_get_phy" [drivers/usb/dwc3/dwc3.ko] undefined! >>> ERROR: "devm_usb_get_phy_by_phandle" [drivers/usb/dwc3/dwc3.ko] >>> undefined! >>> ERROR: "usb_get_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined! >>> ERROR: "usb_put_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined! >>> ERROR: "usb_get_phy" [drivers/power/isp1704_charger.ko] undefined! >>> ERROR: "usb_put_phy" [drivers/power/isp1704_charger.ko] undefined! >>> >>> Any ideas? >> >> hmm... I think it was Roger's patches changing the way PHY layer is >> enabled, do you mind if I drop that for now ? I would have to rebase, >> but I guess it's a necessary evil at this point. > > I took the silence as a yes and pushed a new tag with Roger's patches > removed. I have also removed one musb patch which wasn't necessary after > all. Sorry for the silence, I went to lunch :) > Here's an updated pull request, which I have compiled on ARM and x86 > and didn't see the linking problem mentioned above: Ok, thanks, I'll try it out now... >>> >>> That worked, now pulled and pushed out, thanks. >> >> Hi Greg, >> >> I tried to reproduce the above problem but couldn't. Could you please >> share your .config that caused the issue and the command sequence you used >> to arrive >> at the problem? Thanks. >> >> By any chance is it possible that there were some stale modules lying around >> in your tree? >> >> The problem shouldn't happen because the symbols are defined in phy.c >> (USB_PHY) which >> is selected by the PHY drivers. Even if USB_PHY is not selected, the >> functions (except >> usb_add/remove_phy() are defined as inlines in /include/linux/usb/phy.h > > If CONFIG_USB is set to M you should see the problem since EHCI-OMAP > would 'select' (meaning set Y) to the PHY driver. Kbuild won't > statically link anything from a directory which was entered due to M. > > Not sure if that sounds as clear as I expected :-p > OK thanks. Maybe setting USB_PHY as tristate should fix it. I'll try it out tomorrow. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] USB: OHCI: Properly handle ohci-spear suspend
On Thu, 13 Jun 2013, Viresh Kumar wrote:
> > + bool do_wakeup = device_may_wakeup(&pdev->dev);
> > + int ret;
> > +
> > + ret = ohci_suspend(hcd, do_wakeup);
> > + if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
>
> maybe s/ret == 0/!ret
I tend to prefer using ! for boolean values and == 0 for numeric
values. Just a matter of personal taste.
> I thought ret == 0 is the success case and not error case.
>
> > + ohci_resume(hcd, false);
> > + ret = -EBUSY;
> > + }
Yes, 0 is the success case. You must not have seen the explanation for
this code; it is needed to handle a race. If the suspend succeeds but
a wakeup request has already arrived, we need to undo the suspend.
Obviously, if the suspend failed then there's no need to undo anything.
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 fix 0/3] Configfs support
Hi, On Thu, Jun 13, 2013 at 10:37:23AM +0200, Andrzej Pietrasiewicz wrote: > Hello Felipe, Hello Greg, > > I've seen that you pulled a bunch of my patches. That's nice. > > However, Felipe was unable to apply one of them due to some whitespace issues, > so he dropped it. > > While dropping the said patch does not break anything, it makes the usb > functions configurable through configfs unavailable to be built > stand-alone. They still can be built but only as a side effect of building > some old gadgets which depend on the functions of interest, e.g. ecm, > ecm subset, eem, rndis will be built as a side effect of building g_ether.ko. > > In Kconfig the problem described here manifests itself by some USB_CONFIGFS_* > entries being dependent on nonexistent USB_CONFIGFS. In practice they do not > appear in menuconfig, so they can't be selected. > > This isn't terribly bad, but the goal of configfs integration is to allow > composing the gadgets of functions of choice at runtime, provided that > the functions themselves are compiled. Which, in turn, stops the > proliferation of new g_.ko gadgets and, ultimately, allows > dropping the g_.ko modules at all. And this is in contradiction > to not being able to build only f_.ko modules without building some > g_.ko gadgets. > > The series I'm sending does the following: > > 1) fix separate building of configfs-enabled functions > 2) add a piece of documentation about configfs-based usb gadgets > 3) add some Documentation/ABI/* related to the newly added configfs entries > > I kindly ask you to consider the series; either as a whole, or individual > patches. The patches in the series do not depend on each other. Verified by > checkpatch. Greg, if you want to apply them directly I'm fine with it: Acked-by: Felipe Balbi Also ok to wait for v3.12 merge window as nothing is *really* broken. -- balbi signature.asc Description: Digital signature
Re: DWC3: Event Interrupt Mask issue
Hi, On Thu, Jun 13, 2013 at 08:26:12PM +0800, Huang Rui wrote: > > > I was reading dwc3 codes and found that during the process of > > > configuring event buffer (dwc3_event_buffers_setup), it only write the > > > size of the buffer and doesn't write interrupt mask bit into GEVNTSIZ > > > register like below, > > > > > > dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n), > > > evt->length & 0x); > > > > > > But in spec, it suggests that write this bit to prevent the interrupt > > > from being generated in an event buffer configuration. So need we set > > > > where does it say that ? I just re-read details about that bit and all > > it says is that it can be used to mask the interrupt, but events will > > still be queued. Maybe I'm missing some part. Which revision of the > > databook are you reading ? > > Thanks a lot to look back into this issue. I read version 2.50a, in > section 8.2.2, the step 3 to configure an Event Buffer describes: > > "Writes the size of the buffer and interrupt mask into GEVNTSIZn. > Depending on your system interrupt latency, enough Event Buffer space > must be allocated to avoid lost interrupts or reduced performance." > > If I misunderstood, please correct me. but we are writing Interrupt mask bit, just always writing 0 :-) > > Anyway, we don't really need that bit right now because linux will only > > enable the IRQ line after request_*irq() has been called and we're > > setting up our event buffers before calling that. > > > > Yeah, when the event buffers are set up, it must not encounter any > interrupts. right. > > OTOH, we could use that bit as means to get rid of IRQF_ONESHOT from > > DWC3 driver. > > > > Thanks to teach me. The IRQF_ONESHOT interrupt should also prevent the > other interrupts until the current thread has been run, just like the > function of interrupt mask bit, am I right? that's correct. IRQ subsystem makes sure to keep IRQs masked until thread has finished running. > > Can you test a patch for me ? I don't have access to HW right now. I > > assume the patch below works fine, does it ? > > > > Sorry, I haven't got the board yet. Your patch looks good, and I will > test it as soon as I get HW. alright, so it's likely that I'll get access to my stuff back before. Anyway, if you happen to have time, I'd be glad to see a Tested-by, always good to test on more than a single platform. -- balbi signature.asc Description: Digital signature
Re: [GIT PULL] USB patches for v3.11 merge window
Hi, On Thu, Jun 13, 2013 at 12:05:36PM +0300, Roger Quadros wrote: > On 06/13/2013 01:37 AM, Greg KH wrote: > > On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote: > >> On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote: > >>> Hi, > >>> > >>> On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote: > > But, I get a build error with your tree pulled in, at the link point in > > time: > > > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined! > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined! > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined! > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined! > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined! > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined! > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-omap-usb3.ko] undefined! > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-omap-usb3.ko] undefined! > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-nop.ko] undefined! > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-nop.ko] undefined! > > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-isp1301.ko] undefined! > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-isp1301.ko] undefined! > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! > > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] > > undefined! > > ERROR: "usb_get_phy" [drivers/usb/musb/ux500.ko] undefined! > > ERROR: "usb_put_phy" [drivers/usb/musb/ux500.ko] undefined! > > ERROR: "usb_put_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined! > > ERROR: "usb_get_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined! > > ERROR: "devm_usb_get_phy" [drivers/usb/gadget/mv_udc.ko] undefined! > > ERROR: "devm_usb_get_phy" [drivers/usb/dwc3/dwc3.ko] undefined! > > ERROR: "devm_usb_get_phy_by_phandle" [drivers/usb/dwc3/dwc3.ko] > > undefined! > > ERROR: "usb_get_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > > ERROR: "usb_put_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > > ERROR: "usb_get_phy" [drivers/power/isp1704_charger.ko] undefined! > > ERROR: "usb_put_phy" [drivers/power/isp1704_charger.ko] undefined! > > > > Any ideas? > > hmm... I think it was Roger's patches changing the way PHY layer is > enabled, do you mind if I drop that for now ? I would have to rebase, > but I guess it's a necessary evil at this point. > >>> > >>> I took the silence as a yes and pushed a new tag with Roger's patches > >>> removed. I have also removed one musb patch which wasn't necessary after > >>> all. > >> > >> Sorry for the silence, I went to lunch :) > >> > >>> Here's an updated pull request, which I have compiled on ARM and x86 > >>> and didn't see the linking problem mentioned above: > >> > >> Ok, thanks, I'll try it out now... > > > > That worked, now pulled and pushed out, thanks. > > Hi Greg, > > I tried to reproduce the above problem but couldn't. Could you please > share your .config that caused the issue and the command sequence you used to > arrive > at the problem? Thanks. > > By any chance is it possible that there were some stale modules lying around > in your tree? > > The problem shouldn't happen because the symbols are defined in phy.c > (USB_PHY) which > is selected by the PHY drivers. Even if USB_PHY is not selected, the > functions (except > usb_add/remove_phy() are defined as inlines in /include/linux/usb/phy.h If CONFIG_USB is set to M you should see the problem since EHCI-OMAP would 'select' (meaning set Y) to the PHY driver. Kbuild won't statically link anything from a directory which was entered due to M. Not sure if that sounds as clear as I expected :-p -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
Hi, On 28/05/13 08:18, Kishon Vijay Abraham I wrote: > Hi Tony, > > On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote: >> In order for controllers to get PHY in case of non dt boot, the phy >> binding information (phy label) should be added in the platform >> data of the controller. > > This series would be needed to get MUSB working in OMAP3 boards for > non-dt boot case. Do you think this is good enough to go in this rc cycle? Did this or some other solution go forward? I'm still unable to boot with usb-gadget-ethernet with v3.10-rc5. Tomi signature.asc Description: OpenPGP digital signature
Re: DWC3: Event Interrupt Mask issue
Hi Felipe,
On Thu, Jun 13, 2013 at 02:01:04AM +0800, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jun 07, 2013 at 03:50:17PM +0800, Huang Rui wrote:
> > Hi Felipe,
> >
> > I was reading dwc3 codes and found that during the process of
> > configuring event buffer (dwc3_event_buffers_setup), it only write the
> > size of the buffer and doesn't write interrupt mask bit into GEVNTSIZ
> > register like below,
> >
> > dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n),
> > evt->length & 0x);
> >
> > But in spec, it suggests that write this bit to prevent the interrupt
> > from being generated in an event buffer configuration. So need we set
>
> where does it say that ? I just re-read details about that bit and all
> it says is that it can be used to mask the interrupt, but events will
> still be queued. Maybe I'm missing some part. Which revision of the
> databook are you reading ?
Thanks a lot to look back into this issue. I read version 2.50a, in
section 8.2.2, the step 3 to configure an Event Buffer describes:
"Writes the size of the buffer and interrupt mask into GEVNTSIZn.
Depending on your system interrupt latency, enough Event Buffer space
must be allocated to avoid lost interrupts or reduced performance."
If I misunderstood, please correct me.
>
> Anyway, we don't really need that bit right now because linux will only
> enable the IRQ line after request_*irq() has been called and we're
> setting up our event buffers before calling that.
>
Yeah, when the event buffers are set up, it must not encounter any
interrupts.
> OTOH, we could use that bit as means to get rid of IRQF_ONESHOT from
> DWC3 driver.
>
Thanks to teach me. The IRQF_ONESHOT interrupt should also prevent the
other interrupts until the current thread has been run, just like the
function of interrupt mask bit, am I right?
> Can you test a patch for me ? I don't have access to HW right now. I
> assume the patch below works fine, does it ?
>
Sorry, I haven't got the board yet. Your patch looks good, and I will
test it as soon as I get HW.
> (it's not final yet, I will still break it down into proper patches)
>
> 8<--- cut here
>
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index c35d49d..be74df6 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -236,7 +236,7 @@ static int dwc3_event_buffers_setup(struct dwc3 *dwc)
> dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(n),
> upper_32_bits(evt->dma));
> dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n),
> - evt->length & 0x);
> + DWC3_GEVNTSIZ_SIZE(evt->length));
> dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(n), 0);
> }
>
> @@ -255,7 +255,8 @@ static void dwc3_event_buffers_cleanup(struct dwc3 *dwc)
>
> dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(n), 0);
> dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(n), 0);
> - dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n), 0);
> + dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n), DWC3_GEVNTSIZ_INTMASK
> + | DWC3_GEVNTSIZ_SIZE(0));
> dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(n), 0);
> }
> }
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index b69d322..d2ceb82 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -194,6 +194,10 @@
> #define DWC3_GTXFIFOSIZ_TXFDEF(n)((n) & 0x)
> #define DWC3_GTXFIFOSIZ_TXFSTADDR(n) ((n) & 0x)
>
> +/* Global Event Size Registers */
> +#define DWC3_GEVNTSIZ_INTMASK(1 << 31)
> +#define DWC3_GEVNTSIZ_SIZE(n)((n) & 0x)
> +
> /* Global HWPARAMS1 Register */
> #define DWC3_GHWPARAMS1_EN_PWROPT(n) (((n) & (3 << 24)) >> 24)
> #define DWC3_GHWPARAMS1_EN_PWROPT_NO 0
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 2b6e7e0..dc7ee3d 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1567,7 +1567,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>
> irq = platform_get_irq(to_platform_device(dwc->dev), 0);
> ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
> - IRQF_SHARED | IRQF_ONESHOT, "dwc3", dwc);
> + IRQF_SHARED, "dwc3", dwc);
> if (ret) {
> dev_err(dwc->dev, "failed to request irq #%d --> %d\n",
> irq, ret);
> @@ -2491,6 +2491,7 @@ static irqreturn_t dwc3_thread_interrupt(int irq, void
> *_dwc)
> struct dwc3 *dwc = _dwc;
> unsigned long flags;
> irqreturn_t ret = IRQ_NONE;
> + u32 reg;
> int i;
>
> spin_lock_irqsave(&dwc->lock, flags);
> @@ -2530,6 +2531,11 @@ static irqreturn_t dwc3_thread_interrupt(int irq, void
> *_dwc)
> evt->count = 0;
> evt->flags &= ~DWC3_EVEN
Re: [PATCH 10/10] USB: OHCI: Properly handle ohci-spear suspend
On 13 June 2013 14:41, Manjunath Goudar wrote:
> Suspend scenario in case of ohci-spear glue was not
> properly handled as it was not suspending generic part
> of ohci controller.Calling explicitly the ohci_suspend()
Add space after full stop.
> routine in spear_ohci_hcd_drv_suspend() will ensure proper
> handling of suspend scenario.
>
> V2:
> -Incase ohci_suspend() fails, return right away without
> executing further.
You added changelog at wrong place. This will get commited once
somebody applies this patch.
> Signed-off-by: Manjunath Goudar
> Cc: Arnd Bergmann
> Cc: Alan Stern
> Cc: Greg KH
> Cc: linux-usb@vger.kernel.org
> ---
Add it here.
> drivers/usb/host/ohci-spear.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
> index 31ff3fc..2ff867b 100644
> --- a/drivers/usb/host/ohci-spear.c
> +++ b/drivers/usb/host/ohci-spear.c
> @@ -130,12 +130,22 @@ static int spear_ohci_hcd_drv_remove(struct
> platform_device *pdev)
> }
>
> #if defined(CONFIG_PM)
> -static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
> +static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
> pm_message_t message)
> {
> - struct usb_hcd *hcd = platform_get_drvdata(dev);
> + struct usb_hcd *hcd = platform_get_drvdata(pdev);
> struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> struct spear_ohci *sohci_p = to_spear_ohci(hcd);
> + bool do_wakeup = device_may_wakeup(&pdev->dev);
> + int ret;
> +
> + ret = ohci_suspend(hcd, do_wakeup);
> + if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
maybe s/ret == 0/!ret
I thought ret == 0 is the success case and not error case.
> + ohci_resume(hcd, false);
> + ret = -EBUSY;
> + }
> + if (ret)
> + return ret;
>
> if (time_before(jiffies, ohci->next_statechange))
> msleep(5);
> @@ -143,7 +153,7 @@ static int spear_ohci_hcd_drv_suspend(struct
> platform_device *dev,
>
> clk_disable_unprepare(sohci_p->clk);
>
> - return 0;
> + return ret;
> }
>
> static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
> --
> 1.7.9.5
>
>
> ___
> linaro-dev mailing list
> linaro-...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 10/10] USB: OHCI: Properly handle ohci-spear suspend
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-spear.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..2ff867b 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,12 +130,22 @@ static int spear_ohci_hcd_drv_remove(struct
platform_device *pdev)
}
#if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
pm_message_t message)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
@@ -143,7 +153,7 @@ static int spear_ohci_hcd_drv_suspend(struct
platform_device *dev,
clk_disable_unprepare(sohci_p->clk);
- return 0;
+ return ret;
}
static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 06/10] USB: OHCI: Properly handle ohci-omap suspend
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-omap.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index b900dba..9144315 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -423,16 +423,27 @@ static int ohci_hcd_omap_drv_remove(struct
platform_device *dev)
#ifdef CONFIG_PM
-static int ohci_omap_suspend(struct platform_device *dev, pm_message_t message)
+static int ohci_omap_suspend(struct platform_device *pdev, pm_message_t
message)
{
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(dev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
omap_ohci_clock_power(0);
- return 0;
+ return ret;
}
static int ohci_omap_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 01/10] USB: OHCI: Properly handle ohci-at91 suspend
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-at91.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fb2f127..6620e3a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -619,8 +619,18 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
- if (device_may_wakeup(&pdev->dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
+
+ if (do_wakeup)
enable_irq_wake(hcd->irq);
/*
@@ -637,7 +647,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
at91_stop_clock();
}
- return 0;
+ return ret;
}
static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 05/10] USB: OHCI: Properly handle ohci-exynos suspend
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-exynos.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 6ff830c..8fecb6a 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -203,9 +203,17 @@ static int exynos_ohci_suspend(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
+ bool do_wakeup = device_may_wakeup(dev);
unsigned long flags;
int rc = 0;
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ rc = -EBUSY;
+ }
+ if (rc)
+ return rc;
/*
* Root hub was already suspended. Disable irq emission and
* mark HW unaccessible, bail out if RH has been resumed. Use
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 03/10] USB: OHCI: Properly handle ohci-da8xx suspend
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-da8xx.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..8d4914d 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,10 +406,21 @@ static int ohci_hcd_da8xx_drv_remove(struct
platform_device *dev)
}
#ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+ pm_message_t message)
{
- struct usb_hcd *hcd= platform_get_drvdata(dev);
+ struct usb_hcd *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
@@ -417,8 +428,8 @@ static int ohci_da8xx_suspend(struct platform_device *dev,
pm_message_t message)
ohci_da8xx_clock(0);
hcd->state = HC_STATE_SUSPENDED;
- dev->dev.power.power_state = PMSG_SUSPEND;
- return 0;
+ pdev->dev.power.power_state = PMSG_SUSPEND;
+ return ret;
}
static int ohci_da8xx_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 02/10] USB: OHCI: Properly handle ohci-s3c2410 suspend
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away
without executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-s3c2410.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 8018bb1..01430f2 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -430,7 +430,15 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
unsigned long flags;
int rc = 0;
+ bool do_wakeup = device_may_wakeup(dev);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ rc = -EBUSY;
+ }
+ if (rc)
+ return rc;
/*
* Root hub was already suspended. Disable irq emission and
* mark HW unaccessible, bail out if RH has been resumed. Use
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 09/10] USB: OHCI: Properly handle ohci-sm501 suspend
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-sm501.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index d479d5d..81ebbce 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -216,14 +216,25 @@ static int ohci_hcd_sm501_drv_remove(struct
platform_device *pdev)
static int ohci_sm501_suspend(struct platform_device *pdev, pm_message_t msg)
{
struct device *dev = &pdev->dev;
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(pdev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
sm501_unit_power(dev->parent, SM501_GATE_USB_HOST, 0);
- return 0;
+ return ret;
}
static int ohci_sm501_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 04/10] USB: OHCI: Properly handle ohci-ep93xx suspend
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-ep93xx.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..b36b74e 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -174,13 +174,23 @@ static int ohci_hcd_ep93xx_drv_suspend(struct
platform_device *pdev, pm_message_
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
ep93xx_stop_hc(&pdev->dev);
- return 0;
+ return ret;
}
static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 08/10] USB: OHCI: Properly handle ohci-pxa27x suspend
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-pxa27x.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 3a9c01d..d441a87 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -564,13 +564,23 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->ohci.next_statechange))
msleep(5);
ohci->ohci.next_statechange = jiffies;
pxa27x_stop_hc(ohci, dev);
- return 0;
+ return ret;
}
static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 07/10] USB: OHCI: Properly handle ohci-platform suspend
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index bc30475..f91201b 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -139,14 +139,25 @@ static int ohci_platform_remove(struct platform_device
*dev)
static int ohci_platform_suspend(struct device *dev)
{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev->platform_data;
struct platform_device *pdev =
container_of(dev, struct platform_device, dev);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (pdata->power_suspend)
pdata->power_suspend(pdev);
- return 0;
+ return ret;
}
static int ohci_platform_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 00/10] USB: OHCI:Properly handle ohci_suspend()routine in bus glue
Suspend scenario in case of ohci bus glue was not properly handled as it was not suspending generic part of ohci controller. Calling explicitly the ohci_suspend()routine will ensure proper handling of suspend scenario. V2: -Incase ohci_suspend() fails, return right away without executing further. Manjunath Goudar (10): USB: OHCI: Properly handle ohci-at91 suspend USB: OHCI: Properly handle ohci-s3c2410 suspend USB: OHCI: Properly handle ohci-da8xx suspend USB: OHCI: Properly handle ohci-ep93xx suspend USB: OHCI: Properly handle ohci-exynos suspend USB: OHCI: Properly handle ohci-omap suspend USB: OHCI: Properly handle ohci-platform suspend USB: OHCI: Properly handle ohci-pxa27x suspend USB: OHCI: Properly handle ohci-sm501 suspend USB: OHCI: Properly handle ohci-spear suspend drivers/usb/host/ohci-at91.c | 14 -- drivers/usb/host/ohci-da8xx.c| 19 +++ drivers/usb/host/ohci-ep93xx.c | 12 +++- drivers/usb/host/ohci-exynos.c |8 drivers/usb/host/ohci-omap.c | 17 ++--- drivers/usb/host/ohci-platform.c | 13 - drivers/usb/host/ohci-pxa27x.c | 12 +++- drivers/usb/host/ohci-s3c2410.c |8 drivers/usb/host/ohci-sm501.c| 15 +-- drivers/usb/host/ohci-spear.c| 16 +--- 10 files changed, 117 insertions(+), 17 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] USB: OHCI: Properly handle ohci-omap suspend
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-omap.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index b900dba..9144315 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -423,16 +423,27 @@ static int ohci_hcd_omap_drv_remove(struct
platform_device *dev)
#ifdef CONFIG_PM
-static int ohci_omap_suspend(struct platform_device *dev, pm_message_t message)
+static int ohci_omap_suspend(struct platform_device *pdev, pm_message_t
message)
{
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(dev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
omap_ohci_clock_power(0);
- return 0;
+ return ret;
}
static int ohci_omap_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] USB: OHCI: Properly handle ohci-ep93xx suspend
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-ep93xx.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..b36b74e 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -174,13 +174,23 @@ static int ohci_hcd_ep93xx_drv_suspend(struct
platform_device *pdev, pm_message_
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
ep93xx_stop_hc(&pdev->dev);
- return 0;
+ return ret;
}
static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] USB: OHCI: Properly handle ohci-sm501 suspend
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-sm501.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index d479d5d..81ebbce 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -216,14 +216,25 @@ static int ohci_hcd_sm501_drv_remove(struct
platform_device *pdev)
static int ohci_sm501_suspend(struct platform_device *pdev, pm_message_t msg)
{
struct device *dev = &pdev->dev;
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(pdev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
sm501_unit_power(dev->parent, SM501_GATE_USB_HOST, 0);
- return 0;
+ return ret;
}
static int ohci_sm501_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] USB: OHCI: Properly handle ohci-pxa27x suspend
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-pxa27x.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 3a9c01d..d441a87 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -564,13 +564,23 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->ohci.next_statechange))
msleep(5);
ohci->ohci.next_statechange = jiffies;
pxa27x_stop_hc(ohci, dev);
- return 0;
+ return ret;
}
static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] USB: OHCI: Properly handle ohci-spear suspend
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-spear.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..2ff867b 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,12 +130,22 @@ static int spear_ohci_hcd_drv_remove(struct
platform_device *pdev)
}
#if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
pm_message_t message)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
@@ -143,7 +153,7 @@ static int spear_ohci_hcd_drv_suspend(struct
platform_device *dev,
clk_disable_unprepare(sohci_p->clk);
- return 0;
+ return ret;
}
static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] USB: OHCI: Properly handle ohci-exynos suspend
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-exynos.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 6ff830c..8fecb6a 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -203,9 +203,17 @@ static int exynos_ohci_suspend(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
+ bool do_wakeup = device_may_wakeup(dev);
unsigned long flags;
int rc = 0;
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ rc = -EBUSY;
+ }
+ if (rc)
+ return rc;
/*
* Root hub was already suspended. Disable irq emission and
* mark HW unaccessible, bail out if RH has been resumed. Use
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] USB: OHCI: Properly handle ohci-platform suspend
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index bc30475..f91201b 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -139,14 +139,25 @@ static int ohci_platform_remove(struct platform_device
*dev)
static int ohci_platform_suspend(struct device *dev)
{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev->platform_data;
struct platform_device *pdev =
container_of(dev, struct platform_device, dev);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (pdata->power_suspend)
pdata->power_suspend(pdev);
- return 0;
+ return ret;
}
static int ohci_platform_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] USB: OHCI: Properly handle ohci-s3c2410 suspend
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away
without executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-s3c2410.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 8018bb1..01430f2 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -430,7 +430,15 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
unsigned long flags;
int rc = 0;
+ bool do_wakeup = device_may_wakeup(dev);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ rc = -EBUSY;
+ }
+ if (rc)
+ return rc;
/*
* Root hub was already suspended. Disable irq emission and
* mark HW unaccessible, bail out if RH has been resumed. Use
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] USB: OHCI: Properly handle ohci-da8xx suspend
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-da8xx.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..8d4914d 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,10 +406,21 @@ static int ohci_hcd_da8xx_drv_remove(struct
platform_device *dev)
}
#ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+ pm_message_t message)
{
- struct usb_hcd *hcd= platform_get_drvdata(dev);
+ struct usb_hcd *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
@@ -417,8 +428,8 @@ static int ohci_da8xx_suspend(struct platform_device *dev,
pm_message_t message)
ohci_da8xx_clock(0);
hcd->state = HC_STATE_SUSPENDED;
- dev->dev.power.power_state = PMSG_SUSPEND;
- return 0;
+ pdev->dev.power.power_state = PMSG_SUSPEND;
+ return ret;
}
static int ohci_da8xx_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] USB: OHCI: Properly handle ohci-at91 suspend
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without executing further.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-at91.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fb2f127..6620e3a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -619,8 +619,18 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
- if (device_may_wakeup(&pdev->dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
+
+ if (do_wakeup)
enable_irq_wake(hcd->irq);
/*
@@ -637,7 +647,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
at91_stop_clock();
}
- return 0;
+ return ret;
}
static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] USB: OHCI:Properly handle ohci_suspend()routine in bus glue
Suspend scenario in case of ohci bus glue was not properly handled as it was not suspending generic part of ohci controller. Calling explicitly the ohci_suspend()routine will ensure proper handling of suspend scenario. V2: -Incase ohci_suspend() fails, return right away without executing further. Manjunath Goudar (10): USB: OHCI: Properly handle ohci-at91 suspend USB: OHCI: Properly handle ohci-s3c2410 suspend USB: OHCI: Properly handle ohci-da8xx suspend USB: OHCI: Properly handle ohci-ep93xx suspend USB: OHCI: Properly handle ohci-exynos suspend USB: OHCI: Properly handle ohci-omap suspend USB: OHCI: Properly handle ohci-platform suspend USB: OHCI: Properly handle ohci-pxa27x suspend USB: OHCI: Properly handle ohci-sm501 suspend USB: OHCI: Properly handle ohci-spear suspend drivers/usb/host/ohci-at91.c | 14 -- drivers/usb/host/ohci-da8xx.c| 19 +++ drivers/usb/host/ohci-ep93xx.c | 12 +++- drivers/usb/host/ohci-exynos.c |8 drivers/usb/host/ohci-omap.c | 17 ++--- drivers/usb/host/ohci-platform.c | 13 - drivers/usb/host/ohci-pxa27x.c | 12 +++- drivers/usb/host/ohci-s3c2410.c |8 drivers/usb/host/ohci-sm501.c| 15 +-- drivers/usb/host/ohci-spear.c| 16 +--- 10 files changed, 117 insertions(+), 17 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB patches for v3.11 merge window
On 06/13/2013 01:37 AM, Greg KH wrote: > On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote: >> On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote: >>> Hi, >>> >>> On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote: > But, I get a build error with your tree pulled in, at the link point in > time: > > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined! > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb3.ko] undefined! > ERROR: "usb_add_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined! > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-samsung-usb2.ko] undefined! > ERROR: "usb_add_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined! > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-rcar-usb.ko] undefined! > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-omap-usb3.ko] undefined! > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-omap-usb3.ko] undefined! > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-nop.ko] undefined! > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-nop.ko] undefined! > ERROR: "usb_add_phy_dev" [drivers/usb/phy/phy-isp1301.ko] undefined! > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-isp1301.ko] undefined! > ERROR: "usb_add_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! > ERROR: "usb_remove_phy" [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! > ERROR: "usb_get_phy" [drivers/usb/musb/ux500.ko] undefined! > ERROR: "usb_put_phy" [drivers/usb/musb/ux500.ko] undefined! > ERROR: "usb_put_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined! > ERROR: "usb_get_phy" [drivers/usb/gadget/pxa27x_udc.ko] undefined! > ERROR: "devm_usb_get_phy" [drivers/usb/gadget/mv_udc.ko] undefined! > ERROR: "devm_usb_get_phy" [drivers/usb/dwc3/dwc3.ko] undefined! > ERROR: "devm_usb_get_phy_by_phandle" [drivers/usb/dwc3/dwc3.ko] undefined! > ERROR: "usb_get_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > ERROR: "usb_put_phy" [drivers/usb/chipidea/ci_hdrc.ko] undefined! > ERROR: "usb_get_phy" [drivers/power/isp1704_charger.ko] undefined! > ERROR: "usb_put_phy" [drivers/power/isp1704_charger.ko] undefined! > > Any ideas? hmm... I think it was Roger's patches changing the way PHY layer is enabled, do you mind if I drop that for now ? I would have to rebase, but I guess it's a necessary evil at this point. >>> >>> I took the silence as a yes and pushed a new tag with Roger's patches >>> removed. I have also removed one musb patch which wasn't necessary after >>> all. >> >> Sorry for the silence, I went to lunch :) >> >>> Here's an updated pull request, which I have compiled on ARM and x86 >>> and didn't see the linking problem mentioned above: >> >> Ok, thanks, I'll try it out now... > > That worked, now pulled and pushed out, thanks. Hi Greg, I tried to reproduce the above problem but couldn't. Could you please share your .config that caused the issue and the command sequence you used to arrive at the problem? Thanks. By any chance is it possible that there were some stale modules lying around in your tree? The problem shouldn't happen because the symbols are defined in phy.c (USB_PHY) which is selected by the PHY drivers. Even if USB_PHY is not selected, the functions (except usb_add/remove_phy() are defined as inlines in /include/linux/usb/phy.h cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 6/9] ARM: dts: omap: update usb_otg_hs data
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
Documentation/devicetree/bindings/usb/usb-phy.txt |6 ++
arch/arm/boot/dts/omap3-beagle-xm.dts |2 ++
arch/arm/boot/dts/omap3-evm.dts|2 ++
arch/arm/boot/dts/omap3-overo.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |3 +++
arch/arm/boot/dts/twl4030.dtsi |1 +
7 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..c0871a7 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be "50". This signifies the controller can supply upto
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num-eps = <16>;
ram-bits = <12>;
ctrl-module = <&omap_control_usb>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
};
Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
Required properties:
- compatible: Should be "ti,omap-usb2"
- reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+ phandle while referencing this phy.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
ctrl-module = <&omap_control_usb>;
+ #phy-cells = <0>;
};
OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+ phandle while referencing this phy.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
<0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
ctrl-module = <&omap_control_usb>;
+ #phy-cells = <0>;
};
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..023596e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -123,6 +123,8 @@
&usb_otg_hs {
interface-type = <0>;
usb-phy = <&usb2_phy>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
mode = <3>;
power = <50>;
};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 96d1c20..f2b8314 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -69,6 +69,8 @@
&usb_otg_hs {
interface-type = <0>;
usb-phy = <&usb2_phy>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
mode = <3>;
power = <50>;
};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index a626c50..b65916e 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -74,6 +74,8 @@
&usb_otg_hs {
interface-type = <0>;
usb-phy = <&usb2_phy>;
+ phys = <&usb2_phy>;
+ phy-names = "usb2-phy";
mode = <3>;
power = <50>;
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..dae620b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -517,6 +517,7 @@
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
ctrl-module = <&omap_control_usb>;
+ #phy-cells = <0>;
};
};
@@ -655,6 +656,8 @@
interrupt-names = "mc", "dma";
[PATCH v7 8/9] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/phy/phy-omap-usb2.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 3c275e7..bd2e4ca 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
}
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
- u32 ret;
- struct omap_usb *phy = phy_to_omapusb(x);
-
- if (suspend && !phy->is_suspended) {
- omap_control_usb_phy_power(phy->control_dev, 0);
- pm_runtime_put_sync(phy->dev);
- phy->is_suspended = 1;
- } else if (!suspend && phy->is_suspended) {
- ret = pm_runtime_get_sync(phy->dev);
- if (ret < 0) {
- dev_err(phy->dev, "get_sync failed with err %d\n",
- ret);
- return ret;
- }
- omap_control_usb_phy_power(phy->control_dev, 1);
- phy->is_suspended = 0;
- }
-
- return 0;
-}
-
static int omap_usb_power_off(struct phy *x)
{
struct omap_usb *phy = dev_get_drvdata(&x->dev);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.dev= phy->dev;
phy->phy.label = "omap-usb2";
- phy->phy.set_suspend= omap_usb2_suspend;
phy->phy.otg= otg;
phy->phy.type = USB_PHY_TYPE_USB2;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 4/9] usb: phy: twl4030: twl4030 shouldn't be subsys_initcall
Changed the inticall from subsys_initcall to module_init for
twl4030-usb.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/phy/phy-twl4030-usb.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c
index 65a5e43..fba9697 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -822,17 +822,7 @@ static struct platform_driver twl4030_usb_driver = {
},
};
-static int __init twl4030_usb_init(void)
-{
- return platform_driver_register(&twl4030_usb_driver);
-}
-subsys_initcall(twl4030_usb_init);
-
-static void __exit twl4030_usb_exit(void)
-{
- platform_driver_unregister(&twl4030_usb_driver);
-}
-module_exit(twl4030_usb_exit);
+module_platform_driver(twl4030_usb_driver);
MODULE_ALIAS("platform:twl4030_usb");
MODULE_AUTHOR("Texas Instruments, Inc, Nokia Corporation");
--
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
