MIPI DSI, DBI, and tinydrm drivers

[Noralf Trønnes]

Den 24.05.2020 20.35, skrev Daniel Vetter:
> 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
>>
>> 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 :-)
> 

Unfortunately I don't have the two RFC series in my inbox anymore.
I can see from this coverletter that drm_panel was removed after RFC v2:

drm: Add support for tiny LCD displays
https://patchwork.freedesktop.org/series/4520/

The problem is that there's no discussion in the relevant patch:
https://patchwork.freedesktop.org/patch/80117/?series=4520&rev=2

What I remember is that someone said I couldn't use it, then I replied
that someone suggested drm_panel to me in an earlier discussion, but I
couldn't remember who. Then Emil chimed in and said he was the one that
suggested it.

Anyways let's see what Paul comes up with, if he finds a way to move SPI
DBI over to drm_panel than I'm all for it. If not we'll just have to
live with a hybrid solution I guess, one for MIPI DBI parallel bus for
his hardware type and one for MIPI DBI SPI.

The Pi also has a hw block for parallel DBI, downstream there's a driver
that treats it as a generic parallel bus, since it's an 8080 compatible
bus. If I'm not mistaken the BeagleBone Black also has a bus like this.

When I started on tinydrm I had the idea to try and add a parallel bus
type to Linux (even had a prototype for bit banging gpio) that I could
use with DBI. This would make the bus available for things like FPGA's
also, not just displays. I gave up on the idea since parallel DBI uses a
lot of pins to upload a frame to display GRAM, much better to drive the
panel directly through MIPI DPI (better fps), which all these SoC's also
support.

Noralf.

> Cheers, Daniel
> 
>>
>> Noralf.
>>
>>>
>>> Cheers,
>>> -Paul
>>>
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
>