Re: MIPI DSI, DBI, and tinydrm drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Den 25.05.2020 04.05, skrev Paul Cercueil:
> 
> 
> Le lun. 25 mai 2020 à 2:46, Noralf Trønnes <noralf@xxxxxxxxxxx> a écrit :
>>
>>
>> Den 24.05.2020 23.33, skrev Paul Cercueil:
>>>
>>>
>>>  Le dim. 24 mai 2020 à 23:24, Noralf Trønnes <noralf@xxxxxxxxxxx> a
>>> écrit :
>>>>
>>>>
>>>>  Den 24.05.2020 22.42, skrev Paul Cercueil:
>>>>>
>>>>>
>>>>>   Le dim. 24 mai 2020 à 22:14, Noralf Trønnes <noralf@xxxxxxxxxxx> a
>>>>>  écrit :
>>>>>>
>>>>>>
>>>>>>   Den 24.05.2020 21.54, skrev Paul Cercueil:
>>>>>>>    Hi Noralf,
>>>>>>>
>>>>>>>    Le dim. 24 mai 2020 à 19:46, Noralf Trønnes
>>>>>>> <noralf@xxxxxxxxxxx> 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@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?
> 
> What I had in mind was a generic tinydrm driver that fetched the
> drm_panel from devicetree. Which is what you were working on, right?
> 

Ok, I guess was confused by the DBI SPI bridge term and figured this was
a DBI device that panel devices was attached to. My proposal was turning
a DRM panel driver into a full blown DRM driver which AFAIR was what I
was not allowed to do when working on tinydrm. The reason I didn't take
my work any further is because Thierry didn't take interest in it, he
would need to be ok with turning drm_panel drivers into regular DRM drivers.

Noralf.

>> (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.
> 
> I'm not sure the number of pins changes that much between the two, does
> it? Here I have 16 pins for command/data, one pin for command/data
> signal, and the pixel clock.
> 
> DBI has advantages over DPI, e.g. you don't need a separate SPI/I2C to
> configure the panel, and data is only transferred when a new frame is
> available, which means power savings when displaying still images, or a
> variable refresh rate when displaying video.
> 
> -Paul
> 
>>>
>>>
>>>>  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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
> 
> 
> 
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux