headers
Felipe Balbi | 1 Sep 2011 01:55
Picon
Favicon

Re: [PATCH 06/20] usb: hcd-pci: introduce pm-ops for platform-pci devs

Hi,

On Wed, Aug 31, 2011 at 04:46:58PM -0400, Alan Stern wrote:
> > > > While it might possible to merge them. I think we should take smaller
> > > > steps at a time. Those files are already there anyway. So at first we
> > > > find a way to clean up the ifdeferry and allow all of those to be built
> > > > on all archs (it's definitely possible)
> > > 
> > > Just how did you want all these different drivers to be built?  You
> > > said you don't want a separate module containing an entire copy of the
> > > ehci core for each arch; you want the core to be shared.  That means
> > > one of two things:
> > > 
> > > 	Build a single monolithic module containing all the drivers.
> > > 	This is quite likely to require a large bunch of #ifdefs.
> > > 
> > > 	Build a minimal driver module for each arch, and have the ehci
> > > 	core in a single separate module that gets loaded for
> > > 	dependency resolution.  This is likely to require a bunch of
> > > 	exported symbols.
> > > 
> > > Which approach are you advocating?
> > 
> > let udev do its thing:
> > 
> > - arch code will add a platform_device to the driver model, e.g.:
> >   platform_device_register(&omap_ehci_device);
> > 
> > - based on the device add uevent, udev will load the correct module (in
> >   this case ehci-omap.ko)
(Continue reading)

Permalink | Reply | 18 comments |
headers
Josh Boyer | 1 Sep 2011 02:18
Picon

Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data

On Wed, Aug 31, 2011 at 6:36 PM, Greg KH <greg@...> wrote:
> On Tue, Aug 30, 2011 at 08:29:21AM -0700, Tirumala Marri wrote:
>> <-----Original Message-----
>> <From: Pratyush Anand [mailto:pratyush.anand@...]
>> <Sent: Tuesday, August 30, 2011 4:58 AM
>> <To: linux-usb@...
>> <Cc: tmarri@...;
linuxppc-dev@...; fchen@...;
>> <mmiesfeld@...; shiraz.hashim@...; deepak.sikri@...;
>> <vipulkumar.samar@...;
rajeev-dlh.kumar@...; vipin.kumar@...m;
>> <bhupesh.sharma@...; viresh.kumar@...;
Amit.VIRDI@...; Pratyush
>> <Anand
>> <Subject: [PATCH 02/14] dwc/otg: Structure declaration for shared data
>> <
>> <There are some DWC OTG parameters which might be passed by a platform.
>> <Declaration for structure of those parameters have been provided in this
>> <include file.
>> <
>> <Signed-off-by: Pratyush Anand <pratyush.anand@...>
>> <---
>> < include/linux/usb/dwc_otg.h |  274
>>
>> [Tirumala Marri] I am not sure how to separate your changes. But we need
>> More time as our initial patches are still pending.
>
> pending where?  Have you submitted them for inclusion?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg KH | 1 Sep 2011 03:37
Gravatar

Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data

On Wed, Aug 31, 2011 at 08:18:12PM -0400, Josh Boyer wrote:
> On Wed, Aug 31, 2011 at 6:36 PM, Greg KH <greg@...> wrote:
> > On Tue, Aug 30, 2011 at 08:29:21AM -0700, Tirumala Marri wrote:
> >> <-----Original Message-----
> >> <From: Pratyush Anand [mailto:pratyush.anand@...]
> >> <Sent: Tuesday, August 30, 2011 4:58 AM
> >> <To: linux-usb@...
> >> <Cc: tmarri@...;
linuxppc-dev@...; fchen@...;
> >> <mmiesfeld@...; shiraz.hashim@...; deepak.sikri@...;
> >> <vipulkumar.samar@...;
rajeev-dlh.kumar@...; vipin.kumar <at> st.com;
> >> <bhupesh.sharma@...; viresh.kumar@...;
Amit.VIRDI@...; Pratyush
> >> <Anand
> >> <Subject: [PATCH 02/14] dwc/otg: Structure declaration for shared data
> >> <
> >> <There are some DWC OTG parameters which might be passed by a platform.
> >> <Declaration for structure of those parameters have been provided in this
> >> <include file.
> >> <
> >> <Signed-off-by: Pratyush Anand <pratyush.anand@...>
> >> <---
> >> < include/linux/usb/dwc_otg.h |  274
> >>
> >> [Tirumala Marri] I am not sure how to separate your changes. But we need
> >> More time as our initial patches are still pending.
> >
> > pending where?  Have you submitted them for inclusion?
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ming Lei | 1 Sep 2011 04:37
Picon

Re: [PATCH 3/3] usb: ehci: fix comment for EHCI_SHRINK_JIFFIES

Hi,

On Wed, Aug 31, 2011 at 11:07 PM, Alan Stern
<stern@...> wrote:
>>  #define EHCI_SHRINK_JIFFIES  (DIV_ROUND_UP(HZ, 200) + 1)
>> -                                             /* 200-ms async qh unlink delay */
>> +                                             /* async qh unlink delay */
>
> Nice catch!  That "200" was obviously a typo, copying the 200 value
> from the line above.  Instead of erasing it, how about changing it to
> say "5" (which is what it should have been)?

Considered the 5ms is obvious in code, maybe it is not worthy to comment it.

thanks,
--

-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Alan Stern | 1 Sep 2011 04:53
Picon
Favicon

Re: [PATCH 06/20] usb: hcd-pci: introduce pm-ops for platform-pci devs

On Thu, 1 Sep 2011, Felipe Balbi wrote:

> > I'm willing to go along with the idea of adding an extra device layer
> > between the controller and the root hub.  But I'm not so keen about
> > making it a platform_device.  What we need here is a general usb_host
> > device that can be a new device_type on the USB bus, like we discussed 
> > earlier.
> 
> I don't think this will be a good approach. You see, this will affect
> the non-standard hosts too.

To some extent, yes.  I don't see anything wrong with that.  You're
proposing a significant change to part of the USB stack; it ought to
affect the existing drivers.

> Hosts like MUSB are completely non-standard, so they must provide their
> own hc_driver. But they talk directly to usbcore.
> 
> In the case of the standard hosts what we have is, for example:
> 
> usbcore <--> EHCI Stack <--> Architecture
> 
> What I'm proposing is to split the EHCI stack to its own
> platform_driver/device. If you add a struct usb_host kinda thing, that
> will affect MUSB too:
> 
> - usbcore <--> MUSB <--> Architcture
> + usbcore <--> usb_host <--> MUSB <--> architecture

Your diagram is not a good description of the existing stack.  We
(Continue reading)

Permalink | Reply | 17 comments |
headers
Oliver Neukum | 1 Sep 2011 08:01

Re: 3.0.3 + Bluetooth USB Dongle: no success without noapic

Am Donnerstag, 1. September 2011, 07:36:10 schrieb Harald Dunkel:
> On 08/28/11 12:07, Oliver Neukum wrote:
> > Am Sonntag, 28. August 2011, 11:49:57 schrieb Harald Dunkel:

Hi,

> >> [   91.589073] usb 2-5: new full speed USB device number 8 using ohci_hcd [   91.709067] usb 2-5: device
descriptor read/64, error -62 [   91.930059] usb 2-5: device descriptor read/64, error -62 [   92.144054]
usb 2-5: new full speed USB device number 9 using ohci_hcd [   92.264073] usb 2-5:
> >> device descriptor read/64, error -62 [   92.485064] usb 2-5: device descriptor read/64, error -62 [  
92.699091] usb 2-5: new full speed USB device number 10 using ohci_hcd [   93.103040] usb 2-5: device not
accepting address 10, error -62 [   93.216102] usb 2-5: new full speed USB device
> >> number 11 using ohci_hcd [   93.620038] usb 2-5: device not accepting address 11, error -62 [   93.620072]
hub 2-0:1.0: unable to enumerate USB device on port 5
> >>
> >> Booting with noapic fixes this problem.
> >
> > Do any other USB devices work on that OHCI?
> >
> 
> Sorry for the delay.
> 
> It seems that this problem comes up by chance (with or without
> noapic). If I move the dongle to another USB slot then the problem
> is gone. By now the Bluetooth dongle is the only device showing this
> problem.
> 
> Here is the output of lsusb with all devices plugged in and
> working:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Felipe Balbi | 1 Sep 2011 10:32
Picon
Favicon

Re: [PATCH 06/20] usb: hcd-pci: introduce pm-ops for platform-pci devs

Hi,

On Wed, Aug 31, 2011 at 10:53:01PM -0400, Alan Stern wrote:
> On Thu, 1 Sep 2011, Felipe Balbi wrote:
> 
> > > I'm willing to go along with the idea of adding an extra device layer
> > > between the controller and the root hub.  But I'm not so keen about
> > > making it a platform_device.  What we need here is a general usb_host
> > > device that can be a new device_type on the USB bus, like we discussed 
> > > earlier.
> > 
> > I don't think this will be a good approach. You see, this will affect
> > the non-standard hosts too.
> 
> To some extent, yes.  I don't see anything wrong with that.  You're
> proposing a significant change to part of the USB stack; it ought to
> affect the existing drivers.
> 
> > Hosts like MUSB are completely non-standard, so they must provide their
> > own hc_driver. But they talk directly to usbcore.
> > 
> > In the case of the standard hosts what we have is, for example:
> > 
> > usbcore <--> EHCI Stack <--> Architecture
> > 
> > What I'm proposing is to split the EHCI stack to its own
> > platform_driver/device. If you add a struct usb_host kinda thing, that
> > will affect MUSB too:
> > 
> > - usbcore <--> MUSB <--> Architcture
(Continue reading)

Permalink | Reply | 16 comments |
headers
Sebastian Andrzej Siewior | 1 Sep 2011 12:34

Re: [RFC 11/17] usb/ehci: make au1xxx use generic add code

On Wed, Aug 31, 2011 at 11:26:13PM +0300, Felipe Balbi wrote:
> Hi,
Hi,

> > What I see right now is
> > - tt, big endian register and such
> > - clocks
> 
> clock should be handled by ehci-<arch>.c. IOW, ehci-hcd should believe
> clocks are on when it's starting. 
Yes, so this piece has to remain in ehci-arch.c file. Some architectures have
one clock, others have two. So I think that there there is no point in merging
them.

>Also, if ehci-hcd.c should handle PM,
> it should do so with pm_runtime APIs.

I think it does this already.

> > - register offset (sometimes at 0x0 sometimes + 0x100). This however could be
> 
> struct resource ?

I though about this. It is not obvious to my why this has not been done in the
first place. However it does look like there is something within the first
0x100 bytes thas is beeing used.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sebastian Andrzej Siewior | 1 Sep 2011 12:36

Re: [RFC 09/17] usb/ehci: add generic hcd add function

On Wed, Aug 31, 2011 at 10:02:30PM +0530, ABRAHAM, KISHON VIJAY wrote:
> > +       hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);
> some platforms use ioremap_nocache to map memory. Wont those platforms
> be affected if they use this generic hcd add function??

ioremap() has to do the same thing that is done by ioremap_nocached() as it
makes no sense to access hardware cached. Fell free to correct me.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Sebastian Andrzej Siewior | 1 Sep 2011 12:43

Re: [RFC 06/17] usb/ehci: use platform helper in xilinx of

On Wed, Aug 31, 2011 at 06:11:42PM +0200, Jan Andersson wrote:
> platform_get_irq() / platform_get_resource(.., IORESOURCE_IRQ, ..) is
> broken on SPARC32 (at least for LEON) so a change like:
> 
> >>> -       irq = irq_of_parse_and_map(dn, 0);
> >>> +       irq = platform_get_irq(op, 0);
> 
> will break ehci-grlib.c.

Thanks for reminding me of this :) I know that sparc is using the DT
infrastructure in a special way.

> A colleague of mine has adding support for
> platform_get_irq() on his todo list, but it will probably be a while
> before it gets sorted out.

So there are plans for sparc to get this sorted out, that is good to hear.

> My guess is that most people that use ehci-grlib use a kernel
> distributed by my employer. If the use of irq_of_parse_and_map() stands
> in the way of the ehci registration rework then please go ahead and
> remove it - we can temporarily carry a workaround in our linux dist.

I don't intend to break anything or cause more work for you. So it can stand
as it is now and could be converted once sparc is ready for it and this
approach is accepted in general :)

> Best regards,
>  Jan
(Continue reading)

Permalink | Reply | 0 comments |

Gmane