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.
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.
I think I can help with that, I just need some guidance - I am fishing
in exotic seas here.
Thoughts, comments, are very welcome.
Cheers,
-Paul
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
