
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/21/12 17:55, Marek Vasut wrote:
Dear Ilya Yanok,
Current MUSB driver in U-Boot uses old UDC API while new gagdet client drivers need new gadget API. Also current MUSB driver has some significant limitations (like inability to handle tx for endpoints other than ep0). So I think port of new Linux driver is desirable.
This is initial port, performed mostly by putting DM and OTG code under #ifndef __UBOOT__ clauses. My intention was to be as close as possible to the original to ease of possible resyncs. Some warnings are suppressed via CFLAGS. There are some style problems but I'm not touching them for now for the above mentioned reason. There is obviously some room for optimisation, some structure fields are unused as well as (probably) some code.
This is not a replacement for existing MUSB driver (at least for now), cause there are still consumers of the old interface and the only ported backend is for TI AM335X (while the old code has a bunch of other backends).
OTG and DMA are not supported. The only ported driver is for TI AM33xx, but others should be easy to port too.
Virtual root hub is not implemented but this shouldn't be a big problem as the old code has virtual root hub support enabled only for Blackfin platform.
Tested it on AM335x EVM and BeagleBone with CDC Ethernet gadget and a bunch of storage devices.
Pathes are rather big because of the original code size (and I didn't delete unused code, just disabled it). So it's probably better to look at changes as compared to Linux code. I prepared such version also, you can find it at [1]. Hopefully it will be also useful if resync with the kernel will be needed in future.
[1] https://github.com/yanok/u-boot/tree/musb-changes-from-linux
[...]
I'm glad about this. But how can we make this work if we already have a driver for this in u-boot, now we will have another. Tom ?
Part of our pain point here is that, if I'm following everything right, we're switching from our home-grown MUSB framework to the kernel one. The good thing is that there's not many users of the existing framework. Being able to switch to a codebase we can re-sync with the kernel for is a good thing. It comes down to how much of an effort it is to convert and leave untested the other platforms. The good news I believe is that aside from am335x everything else already has a kernel portion to work from.
- -- Tom