From: Maxime Ripard <maxime@cerno.tech>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: David Lechner <david@lechnology.com>,
robh+dt@kernel.org, devicetree@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-staging@lists.linux.dev, dave.stevenson@raspberrypi.com
Subject: Re: [PATCH 0/6] drm/tiny/st7735r: Match up with staging/fbtft driver
Date: Wed, 1 Dec 2021 15:52:37 +0100 [thread overview]
Message-ID: <20211201145237.6ezs4pwkmku3pesv@houat> (raw)
In-Reply-To: <ca9e432a-6b04-9935-2469-135a9b47514e@tronnes.org>
[-- Attachment #1: Type: text/plain, Size: 3685 bytes --]
Hi Noralf,
On Tue, Nov 30, 2021 at 03:30:11PM +0100, Noralf Trønnes wrote:
> Den 29.11.2021 10.39, skrev Maxime Ripard:
> > On Wed, Nov 24, 2021 at 04:03:07PM -0600, David Lechner wrote:
> >> On 11/24/21 9:07 AM, Noralf Trønnes wrote:
> > I agree that it doesn't really fit in the DT either though. Noralf, what
> > kind of data do we need to setup a display in fbtft? The init sequence,
> > and maybe some enable/reset GPIO, plus some timing duration maybe?
> >
> > There's one similar situation I can think of: wifi chips. Those also
> > need a few infos from the DT (like what bus it's connected to, enable
> > GPIO, etc) and a different sequence (firmware), sometimes different from
> > one board to the other.
> >
> > Could we have a binding that would be something like:
> >
> > panel@42 {
> > compatible = "panel-spi";
> > model = "panel-from-random-place-42";
> > enable-gpios = <&...>;
> > }
> >
> > And then, the driver would request the init sequence through the
> > firmware mechanism using a name generated from the model property.
> >
> > It allows to support multiple devices in a given system, since the
> > firmware name wouldn't conflict, it makes a decent binding, and users
> > can adjust the init sequence easily (maybe with a bit of tooling)
> >
> > Would that work?
>
> I really like this idea. An added benefit is that one driver can handle
> all MIPI DBI compatible controllers avoiding the need to do a patchset
> like this for all the various MIPI DBI controllers. The firmware will
> just contain numeric commands with parameters, so no need for different
> controller drivers to handle the controller specific command names.
>
> The following is a list of the MIPI DBI compatible controllers currently
> in staging/fbtft: ili9341, hx8357d, st7735r, ili9163, ili9163, ili9163,
> ili9163, ili9486, ili9481, tinylcd, s6d02a1, s6d02a1, hx8340bn, ili9340.
>
> The compatible needs to be a bit more specific though since there are 2
> major SPI protocols for these display: MIPI DBI and the one used by
> ILI9325 and others.
>
> The full binding would be something like this:
>
> panel@42 {
> compatible = "panel-mipi-dbi-spi";
> model = "panel-from-random-place-42";
>
> /* The MIPI DBI spec lists these powers supply pins */
> vdd-supply = <&...>;
> vddi-supply = <&...>;
>
> /* Optional gpio to drive the RESX line */
> reset-gpios = <&...>;
>
> /*
> * D/CX: Data/Command, Command is active low
> * Abcense: Interface option 1 (D/C embedded in 9-bit word)
> * Precense: Interface option 3
> */
> dc-gpios = <&...>;
>
> /*
> * If set the driver won't try to read from the controller to see
> * if it's already configured by the bootloader or previously by
> * the driver. A readable controller avoids flicker and/or delay
> * enabling the pipeline.
> *
> * This property might not be necessary if we are guaranteed to
> * always read back all 1's or 0's when MISO is not connected.
> * I don't know if all setups can guarantee that.
> */
> write-only;
>
> /* Optional ref to backlight node */
> backlight = <&...>;
> }
It looks decent to me. We'll want Rob to give his opinion though, but it
looks in a much better shape compared to what we usually have :)
> Many of these controllers also have a RGB interface option for the
> pixels and only do configuration over SPI.
> Maybe the compatible should reflect these 2 options somehow?
I think we'll want a "real" panel for RGB, with its own compatible
though. We have a few of these drivers in tree already, so it's better
to remain consistent.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2021-12-01 14:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 15:07 [PATCH 0/6] drm/tiny/st7735r: Match up with staging/fbtft driver Noralf Trønnes
2021-11-24 15:07 ` [PATCH 1/6] dt-bindings: display: sitronix,st7735r: Fix backlight in example Noralf Trønnes
2021-12-01 21:57 ` Rob Herring
2021-12-06 8:53 ` Geert Uytterhoeven
2021-12-06 15:18 ` David Lechner
2021-11-24 15:07 ` [PATCH 2/6] dt-bindings: display: sitronix,st7735r: Make reset-gpios optional Noralf Trønnes
2021-12-01 21:57 ` Rob Herring
2021-12-06 15:18 ` David Lechner
2021-11-24 15:07 ` [PATCH 3/6] dt-bindings: display: sitronix,st7735r: Remove spi-max-frequency limit Noralf Trønnes
2021-12-01 21:57 ` Rob Herring
2021-12-06 15:19 ` David Lechner
2021-12-06 16:02 ` Noralf Trønnes
2021-11-24 15:07 ` [PATCH 4/6] dt-bindings: display: sitronix,st7735r: Add initialization properties Noralf Trønnes
2021-12-01 22:08 ` Rob Herring
2021-11-24 15:07 ` [PATCH 5/6] drm/mipi-dbi: Add device property functions Noralf Trønnes
2021-11-24 15:07 ` [PATCH 6/6] drm: tiny: st7735r: Support DT initialization of controller Noralf Trønnes
2021-11-24 22:03 ` [PATCH 0/6] drm/tiny/st7735r: Match up with staging/fbtft driver David Lechner
2021-11-25 17:21 ` Noralf Trønnes
2021-11-29 9:39 ` Maxime Ripard
2021-11-30 8:13 ` Geert Uytterhoeven
2021-11-30 9:03 ` Maxime Ripard
2021-11-30 14:30 ` Noralf Trønnes
2021-12-01 14:52 ` Maxime Ripard [this message]
2021-12-06 15:26 ` David Lechner
2021-12-06 16:04 ` Noralf Trønnes
2022-03-09 10:37 ` 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=20211201145237.6ezs4pwkmku3pesv@houat \
--to=maxime@cerno.tech \
--cc=dave.stevenson@raspberrypi.com \
--cc=david@lechnology.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=noralf@tronnes.org \
--cc=robh+dt@kernel.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).