Hi Sam,
Le dim. 24 mai 2020 à 22:06, Sam Ravnborg <sam@xxxxxxxxxxxx> a écrit :
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.
My controller supports 8/16/18-bit commands, 8/16/18-bit data, serial
or parallel. There is nothing DBI-specific in that, but there is
nothing DSI-specific either; it is more of a bus controller, on which
the DSI and DBI protocols can be used. I think the way to go would be
to separate the buses from the protocols. Ideally, I would have a bus
driver, with "mipi-dsi" and "mipi-dbi-8080" flags in devicetree, and
the core's DSI/DBI code would work on top of the bus API.
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 code looks pretty much like what I was experimenting with before
sending the email. But I think we can do better.
The binding specifies the 'mipi-dbi-type' while in practice the same
hardware may be able to support several types, and specifies a bunch of
GPIOs which wouldn't apply in my case (since they are handled by the
controller).
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.
Agreed.
Cheers,
-Paul
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
