ABC --led-row-addr-type=3 seems to require unreasonable values for gpio_slowdown (SM5368 and DP32020A row chips) => Fixed by --led-row-addr-type=5

[marcmerlin]

I now have 2 different kinds of ABC panels, which require unreasonable gpio_slowdown values, and the higher the resolution/more pixels being driven, the worse things get.
(splitting this off from #1773 which was originally about allowing higher values than 5 for gpio slowdown)
Will also point #823 to this bug

[marcmerlin]

Copying things I found out in #1773 , I've confirmed that on the same chip and same version of linux (I tried raspbian 32bit which was better for ABC than dietpi 64bit), when selecting ABCDE addressing (default), the output is stable with a certain slowdown factor on ABC panels, but the lines are in the wrong place.
The moment I switch to --led-row-addr-type=3, the lines go in the right place but the output becomes unstable/garbled. So clearly the type 3 addressing line output waveform is worse than type 0 and causes the garbling.
To be clear with type0, the output is stable with a slowdown of 2 (but the lines are in the wrong place, understandably)
with type3, I need a slowdown of 7 before things work. That's a huge difference :-/
that test was on rpi3a running 6.1.21-v8+ dietpi 64bit, and with active-3 board.

And I can also confirm that somehow the 32bit 4.14.98-v7+ raspbian works "better" (only a slowdown of 4 is needed) than 6.1.21-v8+ dietpi 64bit on the same exact rpi3a (I just swapped the sdcard, left everything else the same and the slowdown had to go from 4 to 7 to run the same demo -D0 code.
Details in #1773 (comment)

[marcmerlin]

And I took the rpi3a back to raspbian 4.x kernel (32bit) isolcpus=3, running the exact same
Date: Fri Feb 28 11:46:57 2025 -0800 d10f518 git
and I can confirm that
--led-row-addr-type=0 is stable at --led-slowdown-gpio=1
while
--led-row-addr-type=3 needs --led-slowdown-gpio=4

[marcmerlin]

I'm really lost as to why dietpi is worse than raspbian (for ABC only, for ABCDE, it's fine).
I checked that the things from README have been done and isolcpus=3 is on for both (as well as bcm sound turned off and other GPIO and BT stuff gone too)

root@rpi02w3:~# apt-get remove bluez bluez-firmware pi-bluetooth triggerhappy pigpio
Reading package lists... 0%
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'bluez' is not installed, so not removed
Package 'bluez-firmware' is not installed, so not removed
Package 'pi-bluetooth' is not installed, so not removed
Package 'triggerhappy' is not installed, so not removed
Package 'pigpio' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 39 not upgraded.
root@rpi02w3:~# 
root@rpi02w3:~# lsmod | grep bcm
root@rpi02w3:~# cat /proc/cmdline 
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0 snd_bcm2835.enable_headphones=0 snd_bcm2835.enable_hdmi=0 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000  root=PARTUUID=58622d2d-02 rootfstype=ext4 rootwait net.ifnames=0 logo.nologo console=tty1 isolcpus=3

So for now, I'll go back to a bigger rpi3a (bigger than rpi0 2w which won't boot with that older raspbian 32bit) to limit the --led-slowdown-gpio slowdown damage, but this is just a crutch, I'm pretty convinced there is something "off" with the ABC driver that can hopefully be fixed/improved.

[marcmerlin]

If I'm not mistaken, the relevant chip is SM5368PF?

[marcmerlin]

I checked in a workaround until a proper fix can be found and will be closing the other bug I had initial data in.
I think it's good to reference to #1773 (comment)
showing how rpi3a with an old raspbian works better than the same board with a new dietpi (exact same code)

[marcmerlin]

Not sure if that adds anything, but the vendor who sold me the panels uses this to drive them: 5958 decoding