MIPI DSI, DBI, and tinydrm drivers

[Emil Velikov]

Hi Noralf,

On Wed, 3 Jun 2020 at 13:15, Noralf Trønnes <noralf at tronnes.org> wrote:
>
> Den 28.05.2020 17.27, skrev Emil Velikov:
> > On Sun, 24 May 2020 at 19:35, Daniel Vetter <daniel at ffwll.ch> wrote:
> >>
> >> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes <noralf at 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.
> >>
> >>>> 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