Hi, On 24/05/2020 21:50, Paul Cercueil wrote: > Hi Daniel, > > Le dim. 24 mai 2020 à 20:35, Daniel Vetter <dan...@ffwll.ch> a écrit : >> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes <nor...@tronnes.org> wrote: >>> >>> >>> >>> 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. >> >> Do we have drivers with dbi support that actually want to reuse the >> tinydrm drivers? Good clean is all good, but we need a solid reason >> for changing stuff. Plus we need to make sure we're not just >> rediscovering all the old reasons for why we ended up where we are >> right now in the first place. > > I'm trying to interface a ILI9331 based panel that has a DBI/8080 interface. > The ILI9331 is very similar to the ILI9341 which already has a tinydrm > driver. My SoC has a dedicated DBI/DSI controller, and I have currently no > way to make it work with the ingenic-drm driver. > > The idea of a generic drm_panel tinydrm driver was to avoid duplicating code > between regular panel and tinydrm drivers, but the focus of my email was more > to point that right now there is no way to interface a DBI panel with a > regular DRM driver. Unlike DSI, there are currently no drivers with DBI > support as there is no API to register a host DBI driver or a DBI panel > driver. This is what's really missing here. >
Did you have a look at "Enable ili9341 and l3gd20 on stm32f429-disco" (http://lkml.kernel.org/r/1590378062-7965-1-git-send-email-dillon.min...@gmail.com) from dillon.min...@gmail.com, it uses the STM32 DPI engine to feed a ili9341. Seems it would match your issue. Neil > Cheers, > -Paul > >>> > 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. >>> >>> My initial tinydrm work used drm_panel, but I was not allowed to use it >>> (at least not the way I had done it). >> >> Hm, do we have a summary of all the discussions/reasons from back >> then? All I remember is that it's all that simple, you've done a lot >> of work exploring all the options, I'm fairly sure I suggested >> drm_panel even back then but somehow it didn't really work. Would be >> good if we make sure we don't at least repeat history too much :-) >> >> Cheers, Daniel >> >>> >>> Noralf. >>> >>> > >>> > Cheers, >>> > -Paul >>> > >>> > >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
