All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Steev Klimaszewski <steev@kali.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, Daniel Vetter <daniel@ffwll.ch>,
	Maxime Ripard <mripard@kernel.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Linus W <linus.walleij@linaro.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels
Date: Thu, 29 Jul 2021 14:19:23 -0700	[thread overview]
Message-ID: <CAD=FV=XYfQkuPseBq32rf2qiiv4fn2uf2wWv7FT3pjkRF9ugdA@mail.gmail.com> (raw)
In-Reply-To: <YQMPOxfQw7zx6evp@robh.at.kernel.org>

Hi,

On Thu, Jul 29, 2021 at 1:27 PM Rob Herring <robh@kernel.org> wrote:
>
> IMO, you should move any applicable compatibles to the edp-panel schema.
> Also, I don't think you should add 'edp-panel' to them. If they can work
> better with the generic eDP driver, then that should be an internal
> kernel change without a DT change. Also, if 2 different drivers match on
> compatible, it's a roll of the dice which driver binds.

So overall what I was going for is this:

1. I want to be able to specify _just_ "edp-panel" for new boards.
We'll make sure this is how it looks on devices that go through the
factory and thus we can make sure that the driver can recognize all
panels that get shipped.

2. For existing boards, I'd like to be able to move them to use
"edp-panel" but I'm less confident that I can really say exactly what
panels are out there in the field. Even though our device tree has
always listed only one panel, in truth boards have shipped with more
than one and they've just been "compatible enough" with each other
(this "white lie" is what I'm trying to fix). If somehow the generic
"edp-panel" doesn't recognize a panel then I wanted to be able to use
the old timings we'd always had before as a "fallback". That means
that logically I wanted "edp-panel" to be first and only fallback to
the old compatible string if we didn't recognize the panel ID that
came from the EDID. In truth, both compatible strings are handled by
the same driver the driver patch I submitted tried to be smart.

Perhaps that above is over ambitious and it'd be better to just drop
the whole "fallback" concept. If a board manufacturer wants to start
using the "edp-panel" concept then maybe the right idea is to force
them to bump the "board id" and then we can pick a new device tree
revision. Then we can make sure all boards that come out of the
factory with that new "board id" can be identified properly in the
EDID. This will also get rid of some of the complexity in the driver
patch, which is nice. I'll plan on doing this and address your other
feedback for a v2.


-Doug

WARNING: multiple messages have this Message-ID
From: Doug Anderson <dianders@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Steev Klimaszewski <steev@kali.org>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels
Date: Thu, 29 Jul 2021 14:19:23 -0700	[thread overview]
Message-ID: <CAD=FV=XYfQkuPseBq32rf2qiiv4fn2uf2wWv7FT3pjkRF9ugdA@mail.gmail.com> (raw)
In-Reply-To: <YQMPOxfQw7zx6evp@robh.at.kernel.org>

Hi,

On Thu, Jul 29, 2021 at 1:27 PM Rob Herring <robh@kernel.org> wrote:
>
> IMO, you should move any applicable compatibles to the edp-panel schema.
> Also, I don't think you should add 'edp-panel' to them. If they can work
> better with the generic eDP driver, then that should be an internal
> kernel change without a DT change. Also, if 2 different drivers match on
> compatible, it's a roll of the dice which driver binds.

So overall what I was going for is this:

1. I want to be able to specify _just_ "edp-panel" for new boards.
We'll make sure this is how it looks on devices that go through the
factory and thus we can make sure that the driver can recognize all
panels that get shipped.

2. For existing boards, I'd like to be able to move them to use
"edp-panel" but I'm less confident that I can really say exactly what
panels are out there in the field. Even though our device tree has
always listed only one panel, in truth boards have shipped with more
than one and they've just been "compatible enough" with each other
(this "white lie" is what I'm trying to fix). If somehow the generic
"edp-panel" doesn't recognize a panel then I wanted to be able to use
the old timings we'd always had before as a "fallback". That means
that logically I wanted "edp-panel" to be first and only fallback to
the old compatible string if we didn't recognize the panel ID that
came from the EDID. In truth, both compatible strings are handled by
the same driver the driver patch I submitted tried to be smart.

Perhaps that above is over ambitious and it'd be better to just drop
the whole "fallback" concept. If a board manufacturer wants to start
using the "edp-panel" concept then maybe the right idea is to force
them to bump the "board id" and then we can pick a new device tree
revision. Then we can make sure all boards that come out of the
factory with that new "board id" can be identified properly in the
EDID. This will also get rid of some of the complexity in the driver
patch, which is nice. I'll plan on doing this and address your other
feedback for a v2.


-Doug

  reply	other threads:[~2021-07-29 21:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23  0:21 [RFC PATCH 0/8] eDP: Support probing eDP panels dynamically instead of hardcoding Douglas Anderson
2021-07-23  0:21 ` Douglas Anderson
2021-07-23  0:21 ` [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels Douglas Anderson
2021-07-23  0:21   ` Douglas Anderson
2021-07-29 20:27   ` Rob Herring
2021-07-29 20:27     ` Rob Herring
2021-07-29 21:19     ` Doug Anderson [this message]
2021-07-29 21:19       ` Doug Anderson
2021-07-23  0:21 ` [RFC PATCH 2/8] drm/edid: Break out reading block 0 of the EDID Douglas Anderson
2021-07-23  0:21   ` Douglas Anderson
2021-07-23  0:21 ` [RFC PATCH 3/8] drm/edid: Allow the querying/working with the panel ID from " Douglas Anderson
2021-07-23  0:21   ` Douglas Anderson
2021-07-23  0:21 ` [RFC PATCH 4/8] drm/panel-simple: Don't re-read the EDID every time we power off the panel Douglas Anderson
2021-07-23  0:21   ` Douglas Anderson
2021-07-23  0:21 ` [RFC PATCH 5/8] drm/panel-simple: Copy "desc" into driver data; don't store a pointer Douglas Anderson
2021-07-23  0:21   ` Douglas Anderson
2021-07-23  0:21 ` [RFC PATCH 6/8] drm/panel-simple: Split the delay structure out of the panel description Douglas Anderson
2021-07-23  0:21   ` Douglas Anderson
2021-07-23  0:21 ` [RFC PATCH 7/8] drm/panel-simple: Implement generic "edp-panel"s probed by EDID Douglas Anderson
2021-07-23  0:21   ` Douglas Anderson
2021-07-23  0:21 ` [RFC PATCH 8/8] arm64: dts: qcom: sc7180: trogdor devices can use probable eDP panels Douglas Anderson
2021-07-23  0:21   ` Douglas Anderson

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='CAD=FV=XYfQkuPseBq32rf2qiiv4fn2uf2wWv7FT3pjkRF9ugdA@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robh@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=steev@kali.org \
    --cc=thierry.reding@gmail.com \
    --cc=tzimmermann@suse.de \
    --subject='Re: [RFC PATCH 1/8] dt-bindings: drm/panel-simple: Introduce generic eDP panels' \
    /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

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.