Re: MIPI DSI, DBI, and tinydrm drivers

[Paul Cercueil <paul@crapouillou.net>]

Hi Neil,

Le lun. 25 mai 2020 à 16:58, Neil Armstrong <narmstrong@baylibre.com> 
a écrit :
> Hi,
> 
> On 24/05/2020 21:50, Paul Cercueil wrote:
>>  Hi Daniel,
>> 
>>  Le dim. 24 mai 2020 à 20:35, Daniel Vetter <daniel@ffwll.ch> a 
>> écrit :
>>>  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.
>> 
>>  I'm trying to interface a ILI9331 based panel that has a DBI/8080 
>> interface. The ILI9331 is very similar to the ILI9341 which already 
>> has a tinydrm driver. My SoC has a dedicated DBI/DSI controller, and 
>> I have currently no way to make it work with the ingenic-drm driver.
>> 
>>  The idea of a generic drm_panel tinydrm driver was to avoid 
>> duplicating code between regular panel and tinydrm drivers, but the 
>> focus of my email was more to point that right now there is no way 
>> to interface a DBI panel with a regular DRM driver. Unlike DSI, 
>> there are currently no drivers with DBI support as there is no API 
>> to register a host DBI driver or a DBI panel driver. This is what's 
>> really missing here.
>> 
> 
> Did you have a look at "Enable ili9341 and l3gd20 on stm32f429-disco" 
> (http://lkml.kernel.org/r/1590378062-7965-1-git-send-email-dillon.minfei@gmail.com) 
> from dillon.minfei@gmail.com,
> it uses the STM32 DPI engine to feed a ili9341. Seems it would match 
> your issue.

Note that DBI and DPI are different things. Here the ILI9341 uses SPI 
directly instead of a DBI API for sending its commands, which means the 
driver won't work on e.g. a 8080 bus.

-Paul
>> 
>> 
>>>>   > 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 :-)
>>> 
>>>  Cheers, Daniel
>>> 
>>>> 
>>>>   Noralf.
>>>> 
>>>>   >
>>>>   > Cheers,
>>>>   > -Paul
>>>>   >
>>>>   >
>>>>   _______________________________________________
>>>>   dri-devel mailing list
>>>>   dri-devel@lists.freedesktop.org
>>>>   https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>> 
>>> 
>>> 
>>>  --
>>>  Daniel Vetter
>>>  Software Engineer, Intel Corporation
>>>  +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>> 
>> 
>>  _______________________________________________
>>  dri-devel mailing list
>>  dri-devel@lists.freedesktop.org
>>  https://lists.freedesktop.org/mailman/listinfo/dri-devel


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel