| Message ID | ad294414-0fce-26f0-c729-2a051aecf896@gmail.com |
|---|---|
| State | RFC |
| Headers | show |
On Wed, 2017-02-22 at 16:33 +0100, Stefan Koch wrote: > > *IMPORTANT* > 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 > > *WARNING* > 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 Surely you can still have have SMP support in the kernel; all you need to do is take the other CPU offline properly before you repurpose it for VPE?
On Wed, Feb 22, 2017 at 04:33:00PM +0100, Stefan Koch wrote: > 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? 4) Write a proper, platform agnostic driver to connect the SLIC via SPI, PCM, I2C or whatever and add a simple DAHDI driver for it. Then have asterisk do the transcoding (maybe some ASM optimization to make it even take advantage of MIPS DSP instructions) and rely in the kernel scheduler to share the load nicely between the two CPUs. That'd be much cleaner and will even be reusable on other targets like ramips or ar71xx (where we also got devices with SLICs) plus we can support non-Infenion SLIC and escape the (intentional?) vendor-lock of that shady Lantiq implementation. Cheers Daniel
2017-02-22 17:11 GMT+01:00 Daniel Golle <daniel@makrotopia.org>: > 4) Write a proper, platform agnostic driver to connect the SLIC via > SPI, PCM, I2C or whatever and add a simple DAHDI driver for it. Then > have asterisk do the transcoding (maybe some ASM optimization to make > it even take advantage of MIPS DSP instructions) and rely in the kernel > scheduler to share the load nicely between the two CPUs. > > That'd be much cleaner and will even be reusable on other targets like > ramips or ar71xx (where we also got devices with SLICs) plus we can > support non-Infenion SLIC and escape the (intentional?) vendor-lock of > that shady Lantiq implementation. > I think It would be a nice thing to have a native Linux SLIC driver. For FXS it may be easier than to implement DECT and other things that the firmware does support. Does the SLIC support the DECT functionality or is it somewhere else? I have never detected the VPE specific command line at AVM Fritz!Boxes. Do you know how they do it? The Easybox 904 uses the same VPE approach by loading the firmware, reduce system memory and so on. But this one is a bit more simplified.
2017-02-22 17:05 GMT+01:00 David Woodhouse <dwmw2@infradead.org>: > On Wed, 2017-02-22 at 16:33 +0100, Stefan Koch wrote: > > Surely you can still have have SMP support in the kernel; all you need > to do is take the other CPU offline properly before you repurpose it > for VPE? I have created a LEDE pull request with a patch that solves the issue. If CONFIG_MIPS_MT_SMP/CONFIG_SMP is enabled and nosmp is set FXS will work now. See: https://github.com/lede-project/source/pull/899
Hi Stefan, On Tue, Feb 28, 2017 at 07:37:08PM +0100, Stefan Koch wrote: > 2017-02-22 17:11 GMT+01:00 Daniel Golle <daniel@makrotopia.org>: > > 4) Write a proper, platform agnostic driver to connect the SLIC via > > SPI, PCM, I2C or whatever and add a simple DAHDI driver for it. Then > > have asterisk do the transcoding (maybe some ASM optimization to make > > it even take advantage of MIPS DSP instructions) and rely in the kernel > > scheduler to share the load nicely between the two CPUs. > > > > That'd be much cleaner and will even be reusable on other targets like > > ramips or ar71xx (where we also got devices with SLICs) plus we can > > support non-Infenion SLIC and escape the (intentional?) vendor-lock of > > that shady Lantiq implementation. > > > I think It would be a nice thing to have a native Linux SLIC driver. > For FXS it may be easier than to implement DECT and other things that > the firmware does support. > Does the SLIC support the DECT functionality or is it somewhere else? Nah, SLICs a rather simple AD/DA things with on-hook/off-hook detection plus some high-voltage AC stuff going on to ring the bell. Not crazily complicated, but also not exactly trivial. Caller-ID, ADSI, DTMF and all that is taken care of purely in software by DAHDI. Support for SLICs mostly depends on platform support for high-speed SPI and PCM from what I understand, the rest should not be that hard... Datasheets are also not hard to find. DECT is a completely different story: Most devices I've seen so far use Dialog's SC14452 connected via SPI and PCM. Sometimes a small FPGA is used, supposedly serving as a PCM de-multiplexer, so SLICs and DECT can be used simultanously on the same PCM bus. Supporting that might give us a serious headache unless someone finds a good way to hack that into the kernel (obviously, we'll have to reverse-engineer this first by sniffing the PCM bus before and after it hits the FPGA) For the more simple cases and/or more up-to-date boards, I put some effort into porting Osmocom's DECT stack to OpenWrt long time ago: https://lists.openwrt.org/pipermail/openwrt-devel/2014-June/026274.html But at the time there was no support for hardware-supported SPI on Lantiq nor any support for PCM/I2S stuff, thus I was stuck with that really old PCMCIA gear It'd be great if someone could actually forward-port and test-run this on some x86-32 gear with a PCMCIA slot and the COM-ON-AIR card flying around in at Raumfahrtagentur in Berlin. Some weird devices actually use a Cologne Chip HFC-4S connected via SPI and then drive the analog ports and DECT indirectly via BRI. Those boxes are more like a low-end ISDN PBX with built-in DECT and analog ports. Supporting them should not be too difficult as datasheets as well as drivers (as part of DAHDI) for Cologne Chip HFC are publicly available. > > I have never detected the VPE specific command line at AVM > Fritz!Boxes. Do you know how they do it? > The Easybox 904 uses the same VPE approach by loading the firmware, > reduce system memory and so on. But this one is a bit more simplified. No idea what AVM is doing. I mostly looked at Arcadyan and AudioCodes boards... Cheers Daniel
diff --git a/target/linux/lantiq/xrx200/config-default b/target/linux/lantiq/xrx200/config-default index c307dc8029..5dca18acae 100644 --- a/target/linux/lantiq/xrx200/config-default +++ b/target/linux/lantiq/xrx200/config-default @@ -22,7 +22,7 @@ CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_MIPS_MT=y # CONFIG_MIPS_MT_FPAFF is not set -CONFIG_MIPS_MT_SMP=y +# CONFIG_MIPS_MT_SMP is not set CONFIG_MIPS_PERF_SHARED_TC_COUNTERS=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_ECC=y