Hi, thanks for the quick reply.
On 09.12.21 10:38, Sander Vanheule wrote: > Hi Birger, > >> >> I would suggest to use sub-targets for these platforms with optimized >> compiler settings and SMP/single processor selected correctly for each, >> see https://github.com/BrainSlayer/pie/commits/pie-5.10-rtl9313 >> >> You already set up SMP build support in the config, but don't activate it. > > Currently there are no supported devices in OpenWrt that have one of the SMP- > capable SoCs, which is the main reason it is not yet included here. I've had > a > very quick look on enabling SMP for RTL839x with a mainline build, but haven't > gotten it to work yet. I don't think you can pull the argument about that there are currently no supported devices in master as this concerns an architectural decision for all SoC generations. Also people are already using these devices, plus there are several developers trying to get support for the 839x up to the 931x into master bit-by-bit so it can see at least a bit of peer-review. We need to find a long-term solution, here and this change is very disruptive for development. As you can imagine, a lot of the code I use is never in a git, but instrumentation of core mips code to be able to debug deadlocks and RCU stalls. > Hiroshi and I are still learning as we go along here. I don't know if we can > reasonably expect to have one kernel that supports all SoCs, or if there are > really conflicting build requirements. > > >> However with 2 small patches to the IRQ controller >> https://github.com/BrainSlayer/pie/commit/61860e04b89fa4c76a0e41af3e5d3480dabdf63c#diff-8b9c10bdba2282c6926cb9f7207ac869b011e248a6171f8132e79e1807c9f12a >> > > The patch you link here doesn't seem to apply to the current IRQ controller, > but > to an already modified version of it. It also appears to implement interrupt > balancing, but is that a hard requirement for SMP on RTL839x? The IRQ controller needs a lot of update and the patch is not on the backported patch for the controller but the actual file with the controller code. I really don't like to debug or do development on top of patches, it is much harder. I would suggest to just copy the new version into the tree, there was nothing there before. The IRQ balancing is not necessary strictly speaking for 8390, but if you want to use it with the RTL9300 timer, which needs to send IRQs to both CPUs, it is needed. So you would need it for your proposal below to test this on the 8390 with the timer. > >> and the Ethernet driver >> https://github.com/BrainSlayer/pie/commit/cdbc6598a1e69f74aa5fbaac9c896595a06d21f4#diff-2adae55db41693c452fcc10fb3925ff8c5a38760243f0b77bbd54acc75170d0a >> SMP can be enabled on the RTL8390 and the 9310 platform. >> >> I am a bit worried of using the generic MIPS platform for the RTL9300. >> The SoC has a broken R4K Clock Event Interrupt and requires the RTL9300 >> timer to work plus SMP support for the IRQ controller. There are only >> 2 examples in Linux which have such a combination of dedicated Timer >> for SMP support and IRQ controller, the Sibyte SB1250 and the BCM1480 >> platforms. > > A cursory search (and limited understanding of clocksources etc.) also turned > up > the Ingenic SoCs for me. These appear to have custom timers too, but are still > based on MIPS_GENERIC. I had not noticed that one, it looks promising. There is now also a stand-alone CEVT-reimplementation of the RTL9300 timer here: https://github.com/BrainSlayer/pie/blob/pie-5.10-rtl9313/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c > > Since this Realtek timer is also available on RTL838x/RTL839x, we could use > these platforms for testing as well. The kernel also supports the clocksource= > parameter, which appears to allow for alternative clock selection. So if a > (generic) kernel with R4K-CEVT support is running on RTL930x, shouldn't we be > able to convince it to really use the Realtek timer? This should work. The RTL9300 event source actually pretends to be more accurate than the R4K-CEVT (it isn't but has more features such as one-shot), so that it is being picked up instead. > If Realtek did really funny stuff that makes MIPS_GENERIC incompatible with > some > of these SoCs, I still feel we should try going through upstream. But at least > then we would be quite sure new code is the only way to support these chips. Good idea. Could you try using the RTL9300-CEVT timer and the new IRQ controller with MIPS_GENERIC and SMP? Maybe it works. Sebastian and I are quite sure the timer does what it is supposed to do and the IRQ controller works like a charm on the 8390 under SMP, so either MIPS_GENERIC works, or there are more issues with the SoC, including ones that make it so broken that it does not actually work with SMP. Realtek does not provide any support for SMP to device makers, so maybe the silicon is kaputt. In any case, could you look into the suggestion with the sub-targets? The different compile options should make quite a difference in performance. Cheers, Birger _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
