MIPI DSI, DBI, and tinydrm drivers

[Noralf Trønnes]

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 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 ;-)
> 

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.