Hi Emil, Den 03.06.2020 22.25, skrev Emil Velikov: > 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 ;-) > I guess it turns out that you were right :-) > 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. > +1 When Paul has found a solution for his hw we'll find a way to integrate support for these MIPI DBI SPI drivers. Noralf. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
