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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
