MIPI DSI, DBI, and tinydrm drivers

[Noralf Trønnes]

Den 24.05.2020 23.33, skrev Paul Cercueil:
> 
> 
> Le dim. 24 mai 2020 à 23:24, Noralf Trønnes <noralf at tronnes.org> a écrit :
>>
>>
>> Den 24.05.2020 22.42, skrev Paul Cercueil:
>>>
>>>
>>>  Le dim. 24 mai 2020 à 22:14, Noralf Trønnes <noralf at tronnes.org> a
>>> écrit :
>>>>
>>>>
>>>>  Den 24.05.2020 21.54, skrev Paul Cercueil:
>>>>>   Hi Noralf,
>>>>>
>>>>>   Le dim. 24 mai 2020 à 19:46, Noralf Trønnes <noralf at tronnes.org> a
>>>>>  écrit :
>>>>>>
>>>>>>
>>>>>>   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.
>>>>>>>
>>>>>>>    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.
>>>>>
>>>>>   I don't think that should be much of a problem. You could have a
>>>>>  DBI/SPI
>>>>>   bridge, that wraps a SPI device into a DBI host, for instance. The
>>>>>  panel
>>>>>   drivers would just use the DBI API without having to know what's
>>>>> done
>>>>>   behind the scene.
>>>>
>>>>  This will be a bridge implemented in software, are we allowed to have
>>>>  software devices in the Device Tree? I though it was just allowed to
>>>>  describe hardware.
>>>
>>>  It wouldn't appear in devicetree. If the panel is connected over SPI,
>>>  then DBI is just the protocol it uses.
>>
>> How do you attach a panel to the DBI device if it doesn't appear in DT?
> 
> When probed from a DBI host controller, the panel's devicetree binding
> would look like this:
> 
> &dbi_host {
> 
>    panel {
>        compatible = "my,dbi-device";
>    };
> };
> 
> When probed from SPI it would appear in DT like this:
> 
> &spi {
> 
>    panel at 0 {
>        reg = <0>;
>        compatible = "my,dbi-device-spi";
>    };
> };
> 
> In that case, the driver would create a SPI-DBI bridge, but that is an
> implementation detail that doesn't belong in devicetree.

You said that you want to turn the tinydrm drivers into regular
drm_panel drivers. If this is a drm_panel driver, who calls
drm_of_find_panel_or_bridge() to make use of it? Or is this drm_panel
driver a full blown DRM driver?

(btw. tinydrm.ko is gone now, all drivers in tiny/ are regular DRM drivers)

I'm curious, what kind of device is going to use this? It's a bit
strange to spend so many pins on the display interface and choose DBI
instead of DPI.

Noralf.

> 
> 
>> Another problem is that the DBI panel uses SPI both for framebuffer
>> upload and controller initialization. How shall this be handled when the
>> panel driver needs SPI for init and the DBI bridge needs SPI for frame
>> upload?
> 
> Does the panel driver need SPI for init? I don't think so. It needs to
> send DBI commands over SPI, yes. Only the DBI-SPI bridge would control
> the SPI device.
> 
> -Paul
> 
>>>
>>>  If probed as a SPI device driver, the panel's spi_driver would register
>>>  an instance of the DBI/SPI host driver, then register itself as a
>>>  dbi_driver. If probed from a DBI host it would just register itself
>>> as a
>>>  dbi_driver.
>>>
>>>  -Paul
>>>
>>>>>
>>>>>>   My initial tinydrm work used drm_panel, but I was not allowed to
>>>>>>  use it
>>>>>>   (at least not the way I had done it).
>>>>>>
>>>>>>   Noralf.
>>>>>>
>>>>>>>
>>>>>>>    Cheers,
>>>>>>>    -Paul
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
> 
> 
>