LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Daniel Vetter <daniel@ffwll.ch>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, David Airlie <airlied@linux.ie>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Maxime Ripard <mripard@kernel.org>,
	Steev Klimaszewski <steev@kali.org>,
	Linus W <linus.walleij@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/6] eDP: Support probing eDP panels dynamically instead of hardcoding
Date: Mon, 9 Aug 2021 15:18:03 -0700	[thread overview]
Message-ID: <CAD=FV=XxOXJEgq7SiOVwSo2eWEbekQqutucFP=MmrrtmStXxog@mail.gmail.com> (raw)
In-Reply-To: <YQmp3mGpLW+ELxAC@ravnborg.org>

Hi,

On Tue, Aug 3, 2021 at 1:41 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Douglas,
>
> On Fri, Jul 30, 2021 at 02:26:19PM -0700, Douglas Anderson wrote:
> > The goal of this patch series is to move away from hardcoding exact
> > eDP panels in device tree files. As discussed in the various patches
> > in this series (I'm not repeating everything here), most eDP panels
> > are 99% probable and we can get that last 1% by allowing two "power
> > up" delays to be specified in the device tree file and then using the
> > panel ID (found in the EDID) to look up additional power sequencing
> > delays for the panel.
>
> Have you considered a new driver for edp panels?
> panel-edp.c?
>
> There will be some duplicate code from pnale-simple - but the same can
> be said by the other panel drivers too.
> In the end I think it is better to separate them so we end up with two
> less complex panel drivers rather than one do-it-all panel driver.
>
> I have not looked in detail how this would look like, but my first
> impression is that we should split it out.

I certainly could, but my argument against it is that really it's the
exact same set of eDP panels that would be supported by both drivers.
By definition the "simple" eDP panels are the ones that just have a
regulator/enable GPIO and some timings to turn them off. Those are the
exact same set of panels that can be probed if we just provide the
panel ID that's hardcoded in the EDID. As you can see from the
implementation patch I'm actually sharing the private data structures
(the ones containing the timing) for panels that are supported both as
"probable" and as hardcoded. If we split into two drivers we'd either
need to duplicate the timings for all panels supported by both drivers
or we'd have to somehow export them (maybe hard if things are in
modules). Also, since it's the same set of eDP panels we'd need to
exactly duplicate all the code handling delays / HPD. It just doesn't
feel right to me.


-Doug

  parent reply	other threads:[~2021-08-09 22:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-30 21:26 Douglas Anderson
2021-07-30 21:26 ` [PATCH v2 1/6] dt-bindings: drm/panel-simple: Introduce generic eDP panels Douglas Anderson
2021-08-02 13:39   ` Rob Herring
2021-08-09 22:20     ` Doug Anderson
2021-08-09 22:56       ` Rob Herring
2021-07-30 21:26 ` [PATCH v2 2/6] drm/edid: Break out reading block 0 of the EDID Douglas Anderson
2021-07-30 21:26 ` [PATCH v2 3/6] drm/edid: Allow the querying/working with the panel ID from " Douglas Anderson
2021-07-30 21:26 ` [PATCH v2 4/6] drm/panel-simple: Don't re-read the EDID every time we power off the panel Douglas Anderson
2021-07-30 21:26 ` [PATCH v2 5/6] drm/panel-simple: Split the delay structure out of the panel description Douglas Anderson
2021-07-30 21:26 ` [PATCH v2 6/6] drm/panel-simple: Implement generic "edp-panel"s probed by EDID Douglas Anderson
     [not found] ` <YQmp3mGpLW+ELxAC@ravnborg.org>
2021-08-09 22:18   ` Doug Anderson [this message]
     [not found]     ` <YRTsFNTn/T8fLxyB@ravnborg.org>
2021-08-12 16:00       ` [PATCH v2 0/6] eDP: Support probing eDP panels dynamically instead of hardcoding Doug 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=XxOXJEgq7SiOVwSo2eWEbekQqutucFP=MmrrtmStXxog@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+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=steev@kali.org \
    --cc=thierry.reding@gmail.com \
    --cc=tzimmermann@suse.de \
    --subject='Re: [PATCH v2 0/6] eDP: Support probing eDP panels dynamically instead of hardcoding' \
    /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 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).