Hi,
I checked the GSoC/Ideas page, and this really looks like what I want
to do as a GSoC.
The subject I'll probably choose is "MUSB enhancements", and I may
work on Power managment if get the time to do so.
I'm currently studying at Epitech, in 5th year and a s the maintainer
of the ACPI4Asus project (http://acpi4asus.sf.net) I got some
background in kernel development. I also worked on MTD and UBIFS last
year, and wrote some nand drivers (for WinCE).
I never worked on USB (and MUSB/OTG), but I see that as a good
occasion to learn something new in kernel area.
Still, I've got some questions. Why is this issue still here ? Just
because nobody took the time to fix it ? Or is the PHY hard to work
with ? How would you rate the difficulty of this project ?
My timezone is GMT+1 (Lyon, France), who would be the best mentor for
this subject ?
About the "USB device audio support", it seems
drivers/usb/gadget/audio.c already exists, maybe the idea needs to
be updated to explain what need to be done for beagle board.
Thanks !
Hi,
I checked the GSoC/Ideas page, and this really looks like what I want
to do as a GSoC.
The subject I'll probably choose is "MUSB enhancements", and I may
work on Power managment if get the time to do so.
I'm currently studying at Epitech, in 5th year and a s the maintainer
of the ACPI4Asus project (http://acpi4asus.sf.net) I got some
background in kernel development. I also worked on MTD and UBIFS last
year, and wrote some nand drivers (for WinCE).
I never worked on USB (and MUSB/OTG), but I see that as a good
occasion to learn something new in kernel area.
Still, I've got some questions. Why is this issue still here ? Just
because nobody took the time to fix it ? Or is the PHY hard to work
with ? How would you rate the difficulty of this project ?
Part of the reason is there are many flavors of the MUSB hardware in
existance. Briefly, the history of this driver is (from the view of the OMAP
processors):
- An early unsupported driver went into the kernel
- The driver was cleaned up over many iterations and refactored
- Code was merged in supporting different platforms with different options and
erratas.
The code merge is still in progress. There are also different PHYs being used
with the same MUSB IP. The publically available variants that I know -
OMAP2 with the TWL4030 PHY
OMAP2 with a different PHY used by the N800
OMAP3 with the TWL4030 PHY
OMAP3 with a different PHY used by the N900
Davinci processors with the integrated PHY
IIRC, the OMAP-L13x's also use it with the integrated PHY
Blackfin
Getting the driver working with all those different flavors and others is a
bit tricky. Each one can have different options and different erratas
depending on the version. Examples of the differences are -
DMA vs PIO modes - there are 2 code paths that can vary depending on the sizes
of the transfer.
Number of end points available in the hardware and the size of transfers
supported. This changes the scheduling code in the MUSB driver. In addition,
on some configurations, only certain hardware endpoints can be used for ISOC
transfers.
PHY behavior - each PHY is configured through its own mechanism. There are
also erratas relating to how OTG is suppose to work. IIRC, some versions
(all?) have a very sensitive VBUS ERROR detecct which has been a cause of
some problems.
Hope this doesn't scare anyone off. Just pointing out what some of the battles
can be.
