On Friday 29 June 2007, Dmitry Krivoschekov wrote:
> David Brownell wrote:
> > On Thursday 28 June 2007, Rodolfo Giometti wrote:
> >
> >> As suggest by Leo let me propose to you my new patch for PXA27x UDC
> >> support.
> >>
> >> Please, let me know what I have to do for kernel inclusion. :)
> >
> > Let's start with *JUST* a driver, not trying to update everything
> > else in the USB Gadget stack so that it looks like it's designed
> > specifically to handle all of Intel's design botches related to
> > endpoint config ... and work worse for essentially everything else.
> >
> > (Unlike pretty much every other vendor, Intel wanted hardware config
> > management. It was unusably buggy in pxa21x/25x/26x, and not much
> > better in pxa27x.)
> >
> >
> > So in technical terms, and to repeat what I've said before: just
> > configure it to act more like a PXA 25x chip (no altsettings) and
> > get it so it passes all the tests [1], modulo errata which have no
> > workarounds
>
> Other options are:
>
> 1. pre-program endpoints so the setting covers all gadget
> configurations, it seems it's feasible. The only appreciable
> change is, CDC Ethernet config number should be 3 instead of 1.
> It should not break anything.
ISTR looking at this in some detail a few years back, and
concluding that it wouldn't quite work. That was before
started to hear back from people that the pxa27x hardware
didn't really match its documentation, too ...
> 2. Implement a FAKE call of GET_CONFIGURATION command so upon
> gadget binding you can issue the command and program endpoints
> according to the received gadget configuration.
That would involve *multiple* such fake calls. Not the most
elegant of solutions, but ISTR using it in some other context.
But again, that presumes sane hardware, or at least hardware
that matches the docs. And people who've looked at this in
more pain than I have are consistent in telling me that pxa27x
endpoint configuration has problems that the docs and errata
do not describe. (If it were just one person, rather than four
different developers, I'd be somewhat skeptical.) Hence my
eventual conclusion (and advice) to just stop trying to use
that misfeature.
> Also, considering that PXA3XX processors include PXA27x-compatible
> USB device controller it makes sense to develop a driver that
> will support both processor families. Hopefully PXA3XX arch
> support will be merged some day (the arch support has been already
> submitted here, but I don't know about its current status).
Has someone actually signed up to develop and maintain such a
controller driver? If so, that would be a Fine Thing, but not
one I've heard rumored before. I've assumed that the best we'd
have is someone (Rodolfo?!) finally cleaning up a pxa27x version
so it could be merged.
- Dave
>
>
> Regards,
> Dmitry
>
> > ... then submit that. No epautoconfig updates, no
> > patches to every gadget driver to cope with updated autoconfig.
> >
> > Once there's a basic working no-frills version merged, then we can
> > talk about whether things in the rest of the stack should change
> > to accomodate the bizarre concepts of this controller.
> >
> > - Dave
> >
> >
> > [1] http://www.linux-usb.org/usbtest/
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
