sh1106-spi invalid buffer alignment on 6.12 kernel #6733

gtrainavicius · 2025-03-20T15:10:57Z

Describe the bug

Trying to load the DT overlay and module for sh1106 display (possibly other SPI displays are affected too), fails with invalid buffer alignment.

It is not necessary to have the actual display to be hooked up to reproduce the problem.

Doesn't happen on 6.6 kernel versions.

Steps to reproduce the behaviour

Execute:

sudo dtoverlay sh1106-spi,reset_pin=17,dc_pin=27

Device (s)

Raspberry Pi 5

System

patch@patchbox:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2024-04-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 64e3efc023558a4d4634a702c467f513d5b2bca1, stage-patchbox
patch@patchbox:~ $ vcgencmd version
2025/03/19 13:41:26
Copyright (c) 2012 Broadcom
version cec1d3ae (release) (embedded)
patch@patchbox:~ $ uname -a
Linux patchbox 6.12.19-v8-16k+ #1865 SMP PREEMPT Wed Mar 19 13:48:20 GMT 2025 aarch64 GNU/Linux

Logs

6.12_error.log

6.6 success log for comparison:

6.6_success.log

Additional context

No response

The text was updated successfully, but these errors were encountered:

6by9 · 2025-03-20T15:37:44Z

Upstream have managed to configure two different kernel modules to have the same compatible string
https://elixir.bootlin.com/linux/v6.13.7/source/drivers/gpu/drm/solomon/ssd130x-spi.c#L113
https://elixir.bootlin.com/linux/v6.13.7/source/drivers/staging/fbtft/fb_sh1106.c#L173

Both are getting loaded, and it's the gpu/drm/solomon driver that is crashing.

If you want the deprecated fbtf version (which is what you appeared to have in 6.6), then create a file /etc/modprobe.d/blacklist-ssd130x-spi.conf with the contents blacklist ssd130x-spi.

P33M · 2025-03-20T15:42:52Z

The splat after that is from the AXI DMAC driver - presumably this error path hasn't been called before...

Also, I'm not entirely sure that the DMAC requires a word-aligned start address. It should only need naturally-aligned buffers with a length of integer multiples of SRC_WIDTH.

6by9 · 2025-03-20T15:43:41Z

The solomon driver hasn't set a dma_mask, hence the

[   71.879798] ------------[ cut here ]------------
[   71.879804] WARNING: CPU: 1 PID: 1136 at kernel/dma/mapping.c:209 __dma_map_sg_attrs+0x164/0x178

pelwell · 2025-03-20T16:02:03Z

The solomon driver is passing in an odd address for the transfer, which is not very friendly. The problem with the error path is that axi_desc_put assumes that the LLIs have been allocated and calls dma_pool_free on them. I'll fix the latter.

axi_desc_put often gets called in error paths, and so can't assume that the descriptor passed in has been completely initialised. Guard against unallocated LLIs. See: raspberrypi#6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Remove a bogus memory alignment check - transfers will be run bytewise if needed - and add a check that the overall length is multiple of the register size, otherwise there is residue. See: raspberrypi#6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

pelwell · 2025-03-20T16:49:22Z

See #6734.

axi_desc_put often gets called in error paths, and so can't assume that the descriptor passed in has been completely initialised. Guard against unallocated LLIs. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Remove a bogus memory alignment check - transfers will be run bytewise if needed - and add a check that the overall length is multiple of the register size, otherwise there is residue. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

axi_desc_put often gets called in error paths, and so can't assume that the descriptor passed in has been completely initialised. Guard against unallocated LLIs. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Remove a bogus memory alignment check - transfers will be run bytewise if needed - and add a check that the overall length is multiple of the register size, otherwise there is residue. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

axi_desc_put often gets called in error paths, and so can't assume that the descriptor passed in has been completely initialised. Guard against unallocated LLIs. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Remove a bogus memory alignment check - transfers will be run bytewise if needed - and add a check that the overall length is multiple of the register size, otherwise there is residue. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

pelwell · 2025-03-24T11:17:27Z

Please close the issue if it has been resolved.

axi_desc_put often gets called in error paths, and so can't assume that the descriptor passed in has been completely initialised. Guard against unallocated LLIs. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Remove a bogus memory alignment check - transfers will be run bytewise if needed - and add a check that the overall length is multiple of the register size, otherwise there is residue. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

gtrainavicius · 2025-03-25T09:31:11Z

Blacklisting the ssd130x-spi driver worked as a workaround for now, I will get around to testing a newer kernel version again hopefully by the end of the week.

axi_desc_put often gets called in error paths, and so can't assume that the descriptor passed in has been completely initialised. Guard against unallocated LLIs. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Remove a bogus memory alignment check - transfers will be run bytewise if needed - and add a check that the overall length is multiple of the register size, otherwise there is residue. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

axi_desc_put often gets called in error paths, and so can't assume that the descriptor passed in has been completely initialised. Guard against unallocated LLIs. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Remove a bogus memory alignment check - transfers will be run bytewise if needed - and add a check that the overall length is multiple of the register size, otherwise there is residue. See: #6733 Signed-off-by: Phil Elwell <phil@raspberrypi.com>

gtrainavicius · 2025-03-27T14:38:12Z

The overlay and module loads now without problems, however, the ssd130x-spi module does not work well with sh1106 OLED, I will stick to the older module for now.

6by9 · 2025-03-27T14:47:09Z

Have you tried blacklisting fb_sh1106 instead of ssd130x-spi?

With the recent fixes that have been applied (use sudo rpi-update to grab the latest kernel), loading the overlay doesn't cause an issue for me (I don't have the hardware to confirm the output).

However you don't want two modules trying to implement the same functionality. If ssd130x-spi works, then dropping fb_sh1106 from the defconfigs would be a good move. All the FBTFT drivers are orphaned and stuck in staging.

gtrainavicius · 2025-03-28T13:43:45Z

This is a one off use case where I'll pretty much lock the software versions, so I'm just happy fb_sh1106 works fine. :) If I have to come across this again in the future, I'll look for better solutions.

Thank you for your help!