Hi Noralf, On Wed, 3 Jun 2020 at 13:15, Noralf Trønnes <noralf@xxxxxxxxxxx> wrote: > > 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 > Guilty as charged ;-) Guess I should ask some silly questions first: Was tinydrm modelled as a drm driver itself, because the idea of drm_panel::update() callback seemed dirty? That's the only concern raised that I can find on the list... It's effectively in the link you provided. As far as I can tell, first RFC was already using the tiny drm driver model. https://patchwork.freedesktop.org/patch/77161/ Yet again, do we actually need the callback? The mipi-dbi(?) spi panels in panel/ get away w/o one, while pushing far more pixels onto the screen (tiny has resolutions up-to 320x480, panel up-to 480x800). That said, I'm a fan of lifting the tiny (panel) drivers into drm-panel and exposing them via dbi-bus sounds reasonable IMHO. Seems like Paul has the DT dbi/spi bus questions covered as well. Patches illustrating his ideas would be more than welcome. -Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
