MIPI DSI, DBI, and tinydrm drivers

[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.

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