Hello.
David Brownell wrote:
If you want to have MUSB support in kernel you can forget your dream
of "single kernel image". :-)
That's quite a pursuasive argument.
Yet I haven't seen any proof to it. There's no fundamental
reason it should be so. Details are missing. :)
You have the access to OMAP-L137 and DaVicni MUSB specs -- compare
them. Though you're right -- I can probably prepare and post the draft
patch despite it needs CPPI 4.1 support code to function, contrasted to
hte autonomous CPPI 3.0 driver. That code will reside somewhere in
arch/arm/ -- probably the generic part should go to arch/arm/common/...
I haven't completely separated the generic code and platfrom specific
configuration. I'm just still being busy with different USB issues, so
it may take time...
In the case of MUSB, the driver already has a way to use different DMA
engines. From there, it's not too difficult to teach have it select
the DMA engine at runtime instead of compile time (maybe it already
does this.)
Doesn't currently do that, but it could learn how. Or, there
could be other stratgies too.
I have one question: why do it? To be able to include into the kernel
a lump of unusable code? I certainly have not interest in doing that...
besides, working wiht the MUSB maintainer hasn't been exactly
pleasurable experince (and I have many pending MUSB patches already).
- Dave
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
