Hi Hans,
sunxi musb (otg) support should land in 4.3, this has made me take a look at the Fedora ARM kernel config, esp. since the sunxi musb code only works with CONFIG_MUSB_PIO_ONLY=y
One thing stands out here, config-armv7 has:
CONFIG_USB_TI_CPPI41_DMA=y
Where as config-armv7-generic has:
CONFIG_MUSB_PIO_ONLY=y
And these 2 are mutually exclusive ...
Well we had issues with a number of devices some time ago and after engaging with the upstream maintainer this is the working config we ended up with. Without digging through my email I seem to remember that was around 4.0. I'm not against changing it but it currently works and it would need testing across all possibly affected devices before I'll accept a change.
What problem is it causing you?
I started investigating this after seening a /boot/config-.... which had "# CONFIG_MUSB_PIO_ONLY is not set", but I cannot find the kernel with that anymore, so this may be my memory playing tricks with me.
Either way I believe that it would be good to remove the
CONFIG_USB_TI_CPPI41_DMA=y
From config-armv7, because we do not want that.
Not going to happen until I get to test across affected devices, it has caused us issues in the past.
While on the subject of ARM kernel config, can we please have:
CONFIG_TOUCHSCREEN_CHIPONE_ICN8318=m CONFIG_INPUT_AXP20X_PEK=m
Added to one of the armv7 config files (not sure which one is appropriate), this enables support for a touchscreen found on some tablets we support, resp. for getting input events for power button presses on pretty much all Allwinner devices.
Added, I can't know what modules are in all the possible devices, if you're aware of something new going upstream in a cycle that is useful please just ping an email off so I'm aware of it.
And last I wonder what the policy is for having things as module vs builtin, e.g. on x86 usb controllers and the most common storage controllers are builtin to speed boot-up, sunxi certainly could benefit from building in CONFIG_MMC_SUNXI and CONFIG_MMC_BLOCK, but as said I've no idea what the policy is here.
The policy is we keep it modular where possible to keep the kernel size small. Unlike x86 we generally have a lot less RAM and a lot more options. In the case of USB most x86 devices use a single generic ?HCI driver, so that's 4 drivers (u/o/e/x) total built in, similarly the only storage driver that's built in is generally that of the intel chipset. We have dozens usb/MMC/ata drivers we could potentially build in.
What sort of "speed difference" are we looking at here? I presume it's purely an initial boot up speed issue as opposed to a run time speed issue. Why don't we just build the world in?
Peter