From: "Noralf Trønnes" <noralf@tronnes.org>
To: Paul Cercueil <paul@crapouillou.net>
Cc: Sam Ravnborg <sam@ravnborg.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: MIPI DSI, DBI, and tinydrm drivers
Date: Mon, 25 May 2020 02:46:31 +0200 [thread overview]
Message-ID: <224444bc-e573-920e-f9a8-c23c6962b322@tronnes.org> (raw)
In-Reply-To: <GKUUAQ.UZ3OW5SM7R453@crapouillou.net>
Den 24.05.2020 23.33, skrev Paul Cercueil:
>
>
> Le dim. 24 mai 2020 à 23:24, Noralf Trønnes <noralf@tronnes.org> a écrit :
>>
>>
>> Den 24.05.2020 22.42, skrev Paul Cercueil:
>>>
>>>
>>> Le dim. 24 mai 2020 à 22:14, Noralf Trønnes <noralf@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@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@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?
(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.
Noralf.
>
>
>> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-05-25 0:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-24 16:13 MIPI DSI, DBI, and tinydrm drivers Paul Cercueil
2020-05-24 17:46 ` Noralf Trønnes
2020-05-24 18:35 ` Daniel Vetter
2020-05-24 19:50 ` Paul Cercueil
2020-05-25 14:58 ` Neil Armstrong
2020-05-27 12:10 ` Paul Cercueil
2020-05-25 10:08 ` Noralf Trønnes
2020-05-28 15:27 ` Emil Velikov
2020-06-03 12:15 ` Noralf Trønnes
2020-06-03 20:25 ` Emil Velikov
2020-06-05 12:58 ` Noralf Trønnes
2020-05-24 19:54 ` Paul Cercueil
2020-05-24 20:14 ` Noralf Trønnes
2020-05-24 20:42 ` Paul Cercueil
2020-05-24 21:24 ` Noralf Trønnes
2020-05-24 21:33 ` Paul Cercueil
2020-05-25 0:46 ` Noralf Trønnes [this message]
2020-05-25 2:05 ` Paul Cercueil
2020-05-25 13:23 ` Noralf Trønnes
2020-05-24 20:06 ` Sam Ravnborg
2020-05-25 1:46 ` Paul Cercueil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=224444bc-e573-920e-f9a8-c23c6962b322@tronnes.org \
--to=noralf@tronnes.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=paul@crapouillou.net \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).