On Fri, Dec 05, 2025 at 03:11:06PM +0100, Linus Walleij wrote: > On Fri, Dec 5, 2025 at 2:53 PM Maxime Ripard <[email protected]> wrote: > > > - We need to figure out the bridge ordering mess in the first place > > I was thinking about what we can do here, adding various flags was > discussed and deemed too kludgy. > > What exists in the kernel are things such as the MMC power sequencer > which can be found in > > drivers/mmc/core/pwrseq_simple.c > drivers/mmc/core/pwrseq_emmc.c > drivers/mmc/core/pwrseq_sd8787.c > > with some DT bindings in > > Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml > Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml > Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml > > So here the approach is that the specific sequencing requirements > are added to the hardware description (the device tree) but there the > resources are really flat, then the driver for each type of sequence > takes care of the semantics, i.e. the actual sequencing and ordering. > > Maybe we want to look into something like this?
It's much more complicated than that, and it has nothing to do in the device tree. The DSI bus has different power states, and DSI devices have various requirements depending on the power state (in particular, when you can send commands to the device). Thus, there needs to be some synchronization between the DSI controller driver and the DSI device driver to allow the device driver to perform something in an expected power state. It's been shoehorned into the bridge API (with pre_enable vs enable) and hacked a bit with pre_enable_prev_first, but it really should be fixed once and for all. Maxime
signature.asc
Description: PGP signature
