Den 28.05.2020 17.27, skrev Emil Velikov: > On Sun, 24 May 2020 at 19:35, Daniel Vetter <daniel@xxxxxxxx> wrote: >> >> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes <noralf@xxxxxxxxxxx> 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. >> >>>> 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 >>> > Coming late to the party - the series looks like a great step forward. > >>> 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 :-) >> > This pretty much ^^. Does anyone have a link/summary of the concerns? > I found the thread where you Emil suggested I look at drm_panel: https://lists.freedesktop.org/archives/dri-devel/2015-September/091215.html I used drm_panel in the tinydrm RFC's, but dropped it in version 1 according to the changelog. I think it was Thierry that didn't like how it was used, but I'm not entirely sure. Unfortunately I can't find the emails. There's nothing on the preceding RFC v2, so looks like it's gone somehow: https://patchwork.freedesktop.org/patch/80117/?series=4520&rev=2 Noralf. > From userspace POV - having these as panel makes sense. > Currently as new tiny drm _driver_ gets added, userspace has to be > updated to deal with it ... every so often. > > Additionally having both DPI and DBI code for the given panel > alongside one another makes the overall picture clearer. > > -Emil > Aside: mipi_dbi API should grow a drm_ prefix. > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
