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