On Sunday 02 October 2011 21:56:09 Felipe Balbi wrote:

quoted

Unfortunately, even with the dma parts out of the way there is
a lot that needs to be done to make musb, ehci or ohci
really cross-platform. Right now, you can only have one
platform driver glue for each of those drivers, and they

that's not true for musb. I can already compile am35x and omap2430
together. TUSB is a different story though. With a small effort, we
could also allow DaVinci and the like to compile cleanly and work.

Ok, good.

quoted

should eventually be converted to a large library module for
the core, with independent platform driver front-end, similar

that's how MUSB works now and that's what I have been discussing with
Alan Stern for the past month or so, wrt to *HCI. There are even patches
floating on linux-usb right now trying to hash out the problems.

Ah, glad to see that is happening. I can probably get rid of a bunch
of randconfig patches I have for those then.

Maybe you should have consulted the maintainers of those drivers before
making such statements.

MUSB is not the best example because of its history. I understand the
DMA part is still really messy, but we have been working very hard to
hash the problems and still allow new glue layers to be merged.

Sorry if I have made my statement sound like an accusation, it wasn't
meant as one, merely as a sigh at having identified yet another area
that needs to be changed in order to have cross-platform ARM kernels
working in every case.
 

How about taking a sneak pick at what the code does right now ? As of
today, I can even even have all UDC controller drivers into one kernel
and I generally compile x86 with all controllers available. There's some
very small work that has to be done on each of the UDC drivers to remove
any references to <arch/..> <asm/..> and <plat/..> headers but that work
in in progress.

I didn't really see any problems with UDC at all. What I saw were a lot
of build problems with the musb host side, and I rewrote this patch half
a dozen times before I ended up with a version that consistently built
without making the code look worse.

I also agree that the musb implementation is less of a problem than
ohci/ehci in its current form, as it already is layered in the right
way. I did not attempt to turn the Kconfig 'choice' statement there
into a flat list though, so I wouldn't know what problems to expect.

	Arnd