[fedora-arm] Fedora ARM kernel config remarks / questions

[Peter Robinson]

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