Den 24.05.2020 21.54, skrev Paul Cercueil: > Hi Noralf, > > Le dim. 24 mai 2020 à 19:46, Noralf Trønnes <noralf@xxxxxxxxxxx> a écrit : >> >> >> Den 24.05.2020 18.13, skrev Paul Cercueil: >>> 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. >> >> I did look at this a few months back: >> >> drm/mipi-dbi: Support panel drivers >> https://lists.freedesktop.org/archives/dri-devel/2019-August/228966.html >> >> The problem with DBI is that it has reused other busses which means we >> don't have DBI drivers, we have SPI drivers instead (6800/8080 is not >> avail. as busses in Linux yet). DSI and DPI on the other hand has >> dedicated hw controller drivers not shared with other subsystems. > > I don't think that should be much of a problem. You could have a DBI/SPI > bridge, that wraps a SPI device into a DBI host, for instance. The panel > drivers would just use the DBI API without having to know what's done > behind the scene. This will be a bridge implemented in software, are we allowed to have software devices in the Device Tree? I though it was just allowed to describe hardware. Noralf. > > Cheers, > -Paul > >> My initial tinydrm work used drm_panel, but I was not allowed to use it >> (at least not the way I had done it). >> >> Noralf. >> >>> >>> Cheers, >>> -Paul >>> >>> > > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
