[LEDE-DEV] [PATCH] [BUG] XRX200 VPE support is broken since conflicting SMP support was introduced

Stefan Koch stefan.koch10 at gmail.com
Wed Feb 22 07:33:00 PST 2017


The VPE support needed by the VMMC driver to realize FXS support for 
lantiq xrx200 devices is broken since 2017-02-01.

The following commit introduced *conflicting* SMP support for lantiq 
xrx200 devices and breaks FXS support:

The VPE kernel configuration have been enabled by this commit since 

To use VPE at least CONFIG_MIPS_MT_SMP needs to be disabled within 
xrx200/config-default and nosmp added to the kernel command line
Without nosmp within command line the full SMP part must be disabled

If SMP and VPE are enabled together you will get strange kernel panics. 
Because both, SMP and VPE want to use the second CPU core.
The first commit above that introduces SMP added nosmp to kernel command 
line. So no funny kernel panics appear. But the VMMC firmware could not 
be loaded.

So there a different options to recover FXS support:
1) remove SMP support for xrx200
2) Disables CONFIG_MIPS_MT_SMP within kernel default configuration that 
conflicts with the VPE kernel configuration options. I have added a 
patch as attachment but not tested it without nosmp option and don't 
know what happens on a device that uses no VPE/VMMC/FXS. But it recovers 
FXS support successfully.
3) Write a new patch

The CONFIG_MIPS_MT_SMP option enables many ifdef's within the kernel 
code. It cannot be disabled at runtime, yet.

1) So one possibility is to disable CONFIG_MIPS_MT_SMP when the vmmc 
driver package is selected. But this conflicts with Default Target 
approach which builds images for all xrx200 based devices.
2) Create a menu entry within menuconfig to enable SMP support which 
disables VPE support then. But every image that wants to use SMP needs 
to be self builded.
2) Provide images with and without SMP support for each device that uses 
VPE (one kernel with enabed SMP and one with enabled VPE)
3) Replace all ifdef's with if's that will recognized at run time to 
archive a generic kernel

What do you think about it?
How to solve this issue?

Best regards


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smperr.patch
Type: text/x-patch
Size: 485 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170222/5d0f4952/attachment.bin>

More information about the Lede-dev mailing list