MIPI DSI, DBI, and tinydrm drivers
Paul Cercueil
paul at crapouillou.net
Mon May 25 02:05:47 UTC 2020
Le lun. 25 mai 2020 à 2:46, Noralf Trønnes <noralf at tronnes.org> a
écrit :
>
>
> 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?
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?
> (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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
More information about the dri-devel
mailing list