From: Paul Cercueil <paul@crapouillou.net>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: MIPI DSI, DBI, and tinydrm drivers
Date: Mon, 25 May 2020 03:46:47 +0200 [thread overview]
Message-ID: <Z96VAQ.OJZYLOUQ5XU4@crapouillou.net> (raw)
In-Reply-To: <20200524200655.GA44152@ravnborg.org>
Hi Sam,
Le dim. 24 mai 2020 à 22:06, Sam Ravnborg <sam@ravnborg.org> a écrit :
> Hi Paul.
>
> On Sun, May 24, 2020 at 06:13:16PM +0200, Paul Cercueil wrote:
>> 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.
>
> We could add proper support for a DBI bus, like we have today for DSI.
> This seems like the simple approach as we then have a DSI and a DBI
> bus.
>
> But many panels implement support for both DSI and DBI and then what
> to
> do then? We could register a driver based on the configuration like we
> do in some drivers already. But this would push logic to the dirvers
> which we would like to keep simple.
> We could also try to extend the current DSI bus support to cover
> DBI too - but thats seems also to be not so elegant.
My controller supports 8/16/18-bit commands, 8/16/18-bit data, serial
or parallel. There is nothing DBI-specific in that, but there is
nothing DSI-specific either; it is more of a bus controller, on which
the DSI and DBI protocols can be used. I think the way to go would be
to separate the buses from the protocols. Ideally, I would have a bus
driver, with "mipi-dsi" and "mipi-dbi-8080" flags in devicetree, and
the core's DSI/DBI code would work on top of the bus API.
> I atually started on the framework bits for implementing a DBI bus
> but got sidetracked so did not get far.
> And back then I also was concerned if we should go for a dedicated
> DBI bus or we should do something else.
>
> I have attached two WIP patches from when I looked at it.
> The binding needs extra work and the code may not even build...
The code looks pretty much like what I was experimenting with before
sending the email. But I think we can do better.
The binding specifies the 'mipi-dbi-type' while in practice the same
hardware may be able to support several types, and specifies a bunch of
GPIOs which wouldn't apply in my case (since they are handled by the
controller).
>> 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.
> We should find a clean solution for new drivers and then we can see
> what
> to do for the existing drivers.
Agreed.
Cheers,
-Paul
> We only have a few existing tiny drivers for now - and knowing the
> amount of panel candidates that exist we have to make it simple to
> add support for new panels, both DBI, DSI and DPI variants.
>
> And if we could then find a way to allow the user to specify the init
> sequence without modifying the kernel then we could make it much
> simpler again. Noralf have a solution for this in staging but I think
> we need something else in DRM.
> I have had in mind if we could ut something in initrd or some sort but
> that is down on the TODO list to look at.
>
> Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2020-05-25 7:22 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
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 [this message]
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=Z96VAQ.OJZYLOUQ5XU4@crapouillou.net \
--to=paul@crapouillou.net \
--cc=dri-devel@lists.freedesktop.org \
--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).