Hi Paul.

On Sun, May 24, 2020 at 06:13:16PM +0200, Paul Cercueil wrote:
> Hi list,
> 
> I'd like to open a discussion about the current support of MIPI DSI and DBI
> panels.
> 
> Both are standards from the MIPI alliance, both are communication protocols
> between a LCD controller and a LCD panel, they generally both use the same
> commands (DCS), the main difference is that DSI is serial and DBI is
> generally parallel.
> 
> In the kernel right now, DSI is pretty well implemented. All the
> infrastucture to register a DSI host, DSI device etc. is there. DSI panels
> are implemented as regular drm_panel instances, and their drivers go through
> the DSI API to communicate with the panel, which makes them independent of
> the DSI host driver.
> 
> DBI, on the other hand, does not have any of this. All (?) DBI panels are
> implemented as tinydrm drivers, which make them impossible to use with
> regular DRM drivers. Writing a standard drm_panel driver is impossible, as
> there is no concept of host and device. All these tinydrm drivers register
> their own DBI host as they all do DBI over SPI.
> 
> I think this needs a good cleanup. Given that DSI and DBI are so similar, it
> would probably make sense to fuse DBI support into the current DSI code, as
> trying to update DBI would result in a lot of code being duplicated. With
> the proper host/device registration mechanism from DSI code, it would be
> possible to turn most of the tinydrm drivers into regular drm_panel drivers.

We could add proper support for a DBI bus, like we have today for DSI.
This seems like the simple approach as we then have a DSI and a DBI bus.

But many panels implement support for both DSI and DBI and then what to
do then? We could register a driver based on the configuration like we
do in some drivers already. But this would push logic to the dirvers
which we would like to keep simple.
We could also try to extend the current DSI bus support to cover
DBI too - but thats seems also to be not so elegant.

I atually started on the framework bits for implementing a DBI bus
but got sidetracked so did not get far.
And back then I also was concerned if we should go for a dedicated
DBI bus or we should do something else.

I have attached two WIP patches from when I looked at it.
The binding needs extra work and the code may not even build...

> The problem then is that these should still be available as tinydrm drivers.
> If the DSI/DBI panels can somehow register a .update_fb() callback, it would
> make it possible to have a panel-agnostic tinydrm driver, which would then
> probably open a lot of doors, and help a lot to clean the mess.
We should find a clean solution for new drivers and then we can see what
to do for the existing drivers.
We only have a few existing tiny drivers for now - and knowing the
amount of panel candidates that exist we have to make it simple to
add support for new panels, both DBI, DSI and DPI variants.

And if we could then find a way to allow the user to specify the init
sequence without modifying the kernel then we could make it much
simpler again. Noralf have a solution for this in staging but I think
we need something else in DRM.
I have had in mind if we could ut something in initrd or some sort but
that is down on the TODO list to look at.

	Sam