All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emil Velikov <emil.l.velikov@gmail.com>
To: Paul Cercueil <paul@crapouillou.net>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	od@zcrc.me
Subject: Re: [RFC PATCH 0/4] DSI/DBI and TinyDRM driver
Date: Tue, 16 Jun 2020 18:47:11 +0100	[thread overview]
Message-ID: <CACvgo50abpfh6Q+zPZCCG7RnAzX=CZJmtv2SyTyBfLC7qWtU1w@mail.gmail.com> (raw)
In-Reply-To: <1RIXBQ.4P44ILM1QELP2@crapouillou.net>

Hi all,

Allow me to compare this approach with some work Linus W [1] did a
while back, which I've just noticed.

Pauls' approach:

 - Perhaps the shortest one possible
Porting an existing DSI panel to DBI is 3 lines of code - compat line
in the SPI/DSI bridge, a bus_type and
mipi_dsi_maybe_register_tiny_driver() call
The clever use of the DSI type (equal to zero) means that things will
work w/o updating existing dsi hosts and devices in panel/. Yet in the
very unlikely case that the panel does not support DSI, we will still
allow it.

Although thinking about the type I wonder if it can accommodate all use-cases:
Since we can have a device (panel) capable of DSI+SPI it makes sense
for it to expose the type bitmask, not the host. Although, what if the
host itself supports DSI+SPI.?
Now we can extrapolate that with a host (say fimd/exynos I think)
which supports a SPI panel (s6e63m0) while having
of_graph_get_port_by_id(0)?

- Strange (ab)use of the DSI bus for DBI (SPI, 6800, 8080 etc)
We care about existing users (DT) and it sounds unlikely (based on
previous discussion) that DBI + SPI/6800... will make it into DT. So
the current approach seems quite reasonable IMHO.


Linus' approach:
- Clear separation of DSI/SPI
Compat strings are still duplicated, although in separate files

- Minor code motion and slightly more invasive porting overall
Much of the boilerplate can be reduced via helper lib and macros. Even
then it's unlikely we'll reach the 3 line delta as with Paul's
approach.

- Does not handle tiny-dsi (dummy) drm driver
It seems doable, with minor changes


Personally I'm on the fence and a deciding factor for me is if Paul's
approach can handle all the combinations of host/device type support.
That said, the input from people likely to do the work would be highly
appreciated.

Once a decision is made, an illustrative series + todo entry would be
great to have.
-Emil

[1] https://lists.freedesktop.org/archives/dri-devel/2020-May/266079.html
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-06-16 17:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-07 13:38 [RFC PATCH 0/4] DSI/DBI and TinyDRM driver Paul Cercueil
2020-06-07 13:38 ` [RFC PATCH 1/4] gpu/drm: dsi: Let host and device specify supported bus Paul Cercueil
2020-06-07 13:38 ` [RFC PATCH 2/4] gpu/drm: Add SPI DBI host driver Paul Cercueil
2020-06-07 13:38 ` [RFC PATCH 3/4] gpu/drm: Add TinyDRM for DSI/DBI panels Paul Cercueil
2020-07-08  2:26   ` Sandy Huang
2020-07-08 12:26     ` Paul Cercueil
2020-06-07 13:38 ` [RFC PATCH 4/4] gpu/drm: Add Ilitek ILI9341 DBI panel driver Paul Cercueil
2020-06-14 16:36 ` [RFC PATCH 0/4] DSI/DBI and TinyDRM driver Noralf Trønnes
2020-06-14 18:45   ` Paul Cercueil
2020-06-16 17:47     ` Emil Velikov [this message]
2020-06-16 20:54       ` Paul Cercueil
2020-06-18 22:42       ` Paul Cercueil
2020-07-03 17:26   ` Sam Ravnborg
2020-07-07 14:32     ` Noralf Trønnes
2020-07-08  7:23       ` Daniel Vetter
2020-07-08 12:49         ` Paul Cercueil
2020-07-08 13:58           ` Noralf Trønnes

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='CACvgo50abpfh6Q+zPZCCG7RnAzX=CZJmtv2SyTyBfLC7qWtU1w@mail.gmail.com' \
    --to=emil.l.velikov@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=od@zcrc.me \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.