Hi,
On 09/15/2015 05:32 AM, Peter Robinson wrote:
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.
As said the 2 are mutually exclusive, CONFIG_USB_TI_CPPI41_DMA and
CONFIG_MUSB_PIO_ONLY used to be part of a single "choice" in
drivers/usb/musb/Kconfig
I see that this has changed now (4.3) to:
config MUSB_PIO_ONLY
...
if !MUSB_PIO_ONLY
config USB_UX500_DMA
...
config USB_TI_CPPI41_DMA
...
...
endif
Which explains why I'm no longer actually seeing
CONFIG_USB_TI_CPPI41_DMA=y
Ending up in /boot/config-... for the latest Fedora ARM kernels
What problem is it causing you?
Selecting USB_TI_CPPI41_DMA rather then MUSB_PIO_ONLY will
break musb on ALL SoCs not using TI_CPPI41_DMA:
drivers/usb/musb/musb_core.c:
#ifndef CONFIG_MUSB_PIO_ONLY
if (!musb->ops->dma_init || !musb->ops->dma_exit) {
dev_err(dev, "DMA controller not set\n");
goto fail2;
}
musb_dma_controller_create = musb->ops->dma_init;
musb_dma_controller_destroy = musb->ops->dma_exit;
#endif
And when selecting USB_TI_CPPI41_DMA (and only that one)
none of the other musb platform glue drivers will have
ops->dma_init set, causing them to fail.
This affects the just merged sunxi musb support, but also
any other musb users.
Note that the new kernel Kconfig suggests that now a days
it is possible to build in more dma drivers, looking at
the code this seems correct, but I'm not 100% sure.
Note I can easily fix this problem for sunxi by adding
dummy dma support, but this is going to be a problem for
the other musb users.
> 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.
See above, this is a real problem, also the changed Kconfig
in 4.3, causes CONFIG_MUSB_PIO_ONLY=y to take preference now,
so current 4.3 builds already have effectively removed
CONFIG_USB_TI_CPPI41_DMA=y
> 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
Thanks.
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.
Will do.
> 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.
Ok, fair enough.
Regards,
Hans