Re: MIPI DSI, DBI, and tinydrm drivers

["Noralf Trønnes" <noralf@tronnes.org>]

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

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel