dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: MIPI DSI, DBI, and tinydrm drivers
Date: Sun, 24 May 2020 21:54:03 +0200	[thread overview]
Message-ID: <3YPUAQ.ALFWN74JD6DR1@crapouillou.net> (raw)
In-Reply-To: <05f4908a-2df4-2694-e5e6-0faee31cc2a9@tronnes.org>

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.

Cheers,
-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

  parent reply	other threads:[~2020-05-25  7:23 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 [this message]
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

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=3YPUAQ.ALFWN74JD6DR1@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=noralf@tronnes.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).