No atomic I2C transfer handler when using ssd1306

[fyc09]

Describe the bug

I use ssd1306 driver provided by kernel using "dtoverlay=ssd1306". After shutting down and message "Reaching target Power-Off", it repeatedly warns "No atomic I2C transfer handler for i2c-0" and power does not really shutdown.

Steps to reproduce the behaviour

• Connect a SSD1306 OLED with i2c interface
• Add "dtoverlay=ssd1306" at the end of /boots/firmware/config.txt
• Add fbcon=map:1 into cmdline.txt to enable fbcon on the oled
• Reboot to apply changes, here the screen works well
• Shutdown

Device (s)

Raspberry Pi Zero

System

OS:
Raspberry Pi reference 2025-05-13
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f548f25325e28bea61904f5038a9b9fd0c92b07b, stage2

Firmware:
Apr 30 2025 13:35:18
Copyright (c) 2012 Broadcom
version 5560078dcc8591a00f57b9068d13e5544aeef3aa (clean) (release) (start)

Kernel:
Linux raspberrypi 6.12.25+rpt-rpi-v6 #1 Raspbian 1:6.12.25-1+rpt1 (2025-04-30) armv6l GNU/Linux

Logs

I don't know how to copy the shutdown log, but i found a similar problem on banana pi

Additional context

Using SPI interface does not have such problem. The reason is Bcm2835 does not support atomic transfers yet. Can anyone implement that, or its just impossible

Forum

[6by9]

From the docs
https://elixir.bootlin.com/linux/v6.16.3/source/include/linux/i2c.h#L516-L519

 * @xfer: Transfer a given number of messages defined by the msgs array via
 *   the specified adapter.
 * @xfer_atomic: Same as @xfer. Yet, only using atomic context so e.g. PMICs
 *   can be accessed very late before shutdown. Optional.

The I2C bus driver is currently written to use interrupts and sleeping, hence not suitable for an atomic context.

It is possible to add a busy waiting option (eg 470a662 for stm32f7), but it hasn't been a need until now.

[6by9]

Actually checking https://elixir.bootlin.com/linux/v6.16.3/source/drivers/i2c/i2c-core.h#L42, it logs a WARN, but of itself it does not fail the I2C transaction (it does a i2c_trylock_bus instead of just i2c_lock_bus).
The likelihood of that lock failing at that point is minimal, so I'm surprised that it stalls shutdown.

[pelwell]

Also, there are two drivers that implement the "solomon,ssd1306fb-i2c" compatible string:

drivers/video/fbdev/ssd1307fb.c

and

drivers/gpu/drm/solomon/ssd130x-i2c.c

(and the old FBTFT driver drivers/staging/fbtft/fb_ssd1306.c also supports the device).

Both (all three!) drivers are enabled in our defconfigs, so it's undefined which gets loaded:

alias of:N*T*Csolomon,ssd1306fb-i2cC* ssd1307fb
alias of:N*T*Csolomon,ssd1306fb-i2c ssd1307fb
alias of:N*T*Csolomon,ssd1306fb-i2cC* ssd130x_i2c
alias of:N*T*Csolomon,ssd1306fb-i2c ssd130x_i2c

[6by9]

As long as the device tree bindings are equivalent, then drivers/video/fbdev/ssd1307fb.c ought to get disabled.
At least staging/fbtft is using solomon,ssd1306 as the compatible to make it different.

[pelwell]

As long as the device tree bindings are equivalent, then drivers/video/fbdev/ssd1307fb.c ought to get disabled.

Are you sure? drivers/gpu/drm/solomon/ssd130x-i2c.c says:

		/* Deprecated but kept for backward compatibility */
		.compatible = "solomon,ssd1306fb-i2c",

[6by9]

fb19747

    drm/solomon: Add ssd130x new compatible strings and deprecate old ones.
    
    The current compatible strings for SSD130x I2C controllers contain an "fb"
    and "-i2c" suffixes. These have been deprecated and more correct ones were
    added, that don't encode a subsystem or bus used to interface the devices.

So it's the compatible string that is deprecated, not the driver. Change the compatible string in the overlay then.

drivers/gpu/drm/solomon/ssd130x-i2c.c is listed as maintained by Javier at Redhat.
drivers/video/fbdev/ssd1307fb.c has no maintainer listed, it just falls under the generic FRAMEBUFFER LAYER header. fbdev is considered legacy by mainline.

[6by9]

Actually swapping to the DRM driver solves the problem straight off.

ssd1307fb_remove in the fbdev driver tries to send a DISPLAY_OFF command to the display, and presumably that is what is failing.

Neither the remove nor shutdown hooks for the DRM driver appear at first glance to send any I2C messages, so avoid the problem.

I will be sorting out the overlay, but for a quick test you could create /etc/modprobe.d/blacklist-ssd1307fb.conf containing the text blacklist ssd1307fb which should stop that module being loaded.

I have got a patch to the I2C driver to implement xfer_atomic, but either my display ignores the DISPLAY_OFF or I've got an issue in it. (Probably the latter as I can use dynamic device tree to unload the module, and the display does clear).

[fyc09]

dmesg shows the actual driver is indeed ssd1307fb.

iridet@raspberrypi:~ $ sudo dmesg | grep ssd
[   30.541689] ssd1307fb 1-003c: fb1: Solomon SSD1307 framebuffer device registered, using 1024 bytes of video memory

After adding the blacklist, problem solved and everything works fine.

iridet@raspberrypi:~ $ sudo dmesg | grep ssd
[   31.465027] ssd130x-i2c 1-003c: supply vcc not found, using dummy regulator
[   31.523200] [drm] Initialized ssd130x 1.0.0 for 1-003c on minor 0
[   32.027871] ssd130x-i2c 1-003c: [drm] fb1: ssd130xdrmfb frame buffer device

[6by9]

The one niggle with using the DRM driver is that there is no fixed binding between the card and /dev/fbN node. In my testing I did get about a 50:50 split as to which display driver loaded first and claimed /dev/fb0.

There is dtparam=drm_fb0_vc4 which should force vc4 (HDMI outputs etc) to be /dev/fb0, and then ssd1306 would always get /dev/fb1.

[fyc09]

On my Raspberry Pi Zero, the ssd1306 ALWAYS get /dev/fb1 while /dev/fb0 is not found, when I'm not connecting HDMI outputs.

[6by9]

#7034 swaps the overlay to always using the DRM driver.