devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	devicetree@vger.kernel.org, Maxime Ripard <mripard@kernel.org>,
	Chen-Yu Tsai <wens@csie.org>,
	Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH] dt-bindings: display: Convert a bunch of panels to DT schema
Date: Mon, 9 Dec 2019 11:39:55 -0600	[thread overview]
Message-ID: <CAL_JsqLNSF3j9q49SVTpg=742dgt-60BRhXUxEVUXyYtroAqOQ@mail.gmail.com> (raw)
In-Reply-To: <20191204201452.GA30193@ravnborg.org>

On Wed, Dec 4, 2019 at 2:15 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Rob.
>
> On Mon, Dec 02, 2019 at 08:38:39AM -0600, Rob Herring wrote:
> > On Sat, Nov 30, 2019 at 1:43 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > Hi Rob.
> > >
> > > Thanks for doing this boring, trivial and tiresome task.
> >
> > It was somewhat scripted at least...
> >
> > > On Tue, Nov 19, 2019 at 05:13:09PM -0600, Rob Herring wrote:
> > > > Convert all the 'simple' panels which either use the single
> > > > 'power-supply' property or don't say and just reference
> > > > simple-panel.txt. In the later case, bindings are clear as to which
> > > > properties are required or unused.
> > > >
> > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > Cc: Chen-Yu Tsai <wens@csie.org>
> > > > Cc: Thierry Reding <thierry.reding@gmail.com>
> > > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > >
> > > So Thierry and I ended up as Maintianes for them all.
> > > I gues thats OK as we look after the panel stuff anyway.
> > >
> > > > ---
> > > > We could perhaps consolidate a bunch of these, but I have no idea how
> > > > accurate some of these are WRT what's required or not. Seems strange
> > > > that 'backlight' is optional unless the backlight is tied full on for
> > > > example. If that's the case, then should backlight ever be required?
> > > I do not really follow you here.
> > > Looking through the patch set things looks normal to me.
> > >
> > > What do I miss here?
> >
> > I'm saying a bunch of these could just be a single schema doc with a
> > long list of compatibles. The variation is in what properties are
> > required or not.
>
> It would be just wonderful if we could have only a few
> dt-bindings for the simple panels.
> Like you I cannot see why enable-gpios should be required.
>
> We could end up with something like three classes of bindings:
>
> +required:
> +  - compatible
> +  - power-supply
>
> +required:
> +  - compatible
> +  - port
> +  - power-supply
>
> +required:
> +  - backlight
> +  - compatible
> +  - port
> +  - power-supply
>
> The port part is to my best understanding a way to
> connect the panel to the display driver.
> So it should be more how the connect in the binding
> that decides if port is used or not.

Yes, though it's also initially panels were just the child of the
controller before 'port' came along. We still allow both ways though
'port' is preferred.

> And the panel should not require it.
>
> I may use it with display drivers that do not support it
> in their binding.
>
> And then we have backlight - which can hardly be mandatory.
> The panel could hard-wire it to provide backligt if it wanted
> and the binding should continue to work.
> I think you had the same argument.
>
> So we are down to two required properties:
> +required:
> +  - compatible
> +  - power-supply
>
> Could we put all simple panels in one binding file
> with only this - that would be great.
> Hopefully scripted somehow...
>
> Then adding new simple panels would be a matter of
> adding a new compatible.

Yes. The issue would be enforcing the big disclaimer of "Do not add
your panel here unless it has a single power rail." (And anything else
we think of). Between a single line add vs. a whole new doc, you know
what people will pick. I guess panels could still be moved out of the
common doc later on. We'd also have to be fighting off the "let me add
just one new property for my panel".

> And if they are sorted this should not cause many merge issues either.
>
> I hope I understood you correct.

You did. I'd like to hear Thierry's thoughts on this before going down
this path.

Rob

  reply	other threads:[~2019-12-09 17:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19 23:13 [PATCH] dt-bindings: display: Convert a bunch of panels to DT schema Rob Herring
2019-11-30 19:43 ` Sam Ravnborg
2019-12-02 14:38   ` Rob Herring
2019-12-04 20:14     ` Sam Ravnborg
2019-12-09 17:39       ` Rob Herring [this message]
2019-12-09 18:00         ` Sam Ravnborg

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='CAL_JsqLNSF3j9q49SVTpg=742dgt-60BRhXUxEVUXyYtroAqOQ@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mripard@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=thierry.reding@gmail.com \
    --cc=wens@csie.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).