SPECIAL CARE DSI(9)

📦 version 7.3.1, in nixpkgs unstable

🎀 special care dsi 🎀

okay bestie so this is from the Kernel API Manual and it's literally about keeping your DRM bridges and MIPI-DSI hosts from having a whole messy situationship during probe. it's giving "will they won't they" but in kernel space, and honestly we need to talk about it 💅

✨ DESCRIPTION ✨

the drama between the bridges and the other frameworks involved in probing the upstream driver and the bridge driver? highkey challenging. fr fr, there are multiple cases you gotta consider:

  • the upstream driver doesn't use the component framework and isn't a MIPI-DSI host. in this case, the bridge driver will probe at some point, and the upstream driver should try to probe again by returning EPROBE_DEFER as long as the bridge driver hasn't probed. like, just keep trying babe 🫶
  • the upstream driver doesn't use the component framework, but is a MIPI-DSI host. here the bridge device uses the MIPI-DCS commands to be controlled. in this case, the bridge device is a child of the display device, and when it probes it's assured that the display device (and MIPI-DSI host) is present. the upstream driver will be assured that the bridge driver is connected between the mipi_dsi_host_ops.attach and mipi_dsi_host_ops.detach operations. therefore it must run mipi_dsi_host_register in its probe function, and then run drm_bridge_attach in its mipi_dsi_host_ops.attach hook. no skipping steps, that's the rule ✨
  • the upstream driver uses the component framework and is a MIPI-DSI host. bridge device still uses the MIPI-DCS commands to be controlled. this is the same situation as above, and it can run mipi_dsi_host_register in either its probe or bind hooks. flexible queen 💅
  • the upstream driver uses the component framework and is a MIPI-DSI host, but the bridge device uses a separate bus (such as I2C) to be controlled. okay so in this case there's like, no correlation between the probe of the bridge and the upstream drivers 😭 so care must be taken to avoid an endless EPROBE_DEFER loop, with each driver waiting for the other to probe. it's giving two people texting "you go first" forever. don't do that.
⚠️ that last one is the actual trap bestie — endless EPROBE_DEFER loops are real and they will absolutely eat your boot time alive. be careful!

🌸 the ideal pattern 🌸

the ideal pattern to cover the last item (and all the others in the MIPI-DSI host driver case) is to split the operations like this:

  • the MIPI-DSI host driver must run mipi_dsi_host_register in its probe hook. this makes sure the MIPI-DSI host sticks around, and that the driver's bind can be called. iconic, no notes 👑
  • in its probe hook, the bridge driver must try to find its MIPI-DSI host, register as a MIPI-DSI device, and attach the MIPI-DSI device to its host. the bridge driver is now functional. slay 💖
  • in its struct mipi_dsi_host_ops.attach hook, the MIPI-DSI host can now add its component. its bind hook will now be called, and since the bridge driver is attached and registered, we can now look for it and attach it. the way that this just works 🦋

at this point, we're now certain that both the upstream driver and the bridge driver are functional, and we can't have a deadlock-like situation when probing. periodt. no cap. that's the whole vibe check and it passed 🌈

⭐ SEE ALSO ⭐

that's the whole page bestie, go probe something safely 💜

mwah 💋 — from ./drivers/gpu/drm, October 2026, and yes it's still special care dsi(9) 🎀

📦 where this page comes from