MIPI DSI, DBI, and tinydrm drivers

[Noralf Trønnes]

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.

Noralf.

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