[PATCH v6 4/4] RFT: drm/rockchip: Create custom commit tail

[Maxime Ripard]

On Fri, Dec 05, 2025 at 03:11:06PM +0100, Linus Walleij wrote:
> On Fri, Dec 5, 2025 at 2:53 PM Maxime Ripard <mripard at kernel.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20251208/cd850b47/attachment.sig>