Fedora ARM kernel config remarks / questions

[Hans de Goede]

Hi,

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 ...

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.

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.

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.

Thanks & Regards,

Hans

[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

[Clive Messer]

On Tue, 2015-09-15 at 10:32 +0100, Peter Robinson wrote:
> > 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.

Not sure it would be a good idea removing that one.... It certainly needs
testing on BeagleBone.

It's been a long time since I booted a BeagleBone, but I have a vague 
recollection that it will force BB USB to use PIO for transfers, and 
that was a complete disaster last time I was testing USB DAC's on 
the BeagleBone. YMMV.

Regards

Clive

[Hans de Goede]

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