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