[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=ULWobi5rDbZajiyPvd1TtLQg-x6EqTNgs2pWiGBUjPRg@mail.gmail.com>
Date: Tue, 15 Feb 2022 15:31:01 -0800
From: Doug Anderson <dianders@...omium.org>
To: dri-devel <dri-devel@...ts.freedesktop.org>
Cc: Daniel Vetter <daniel@...ll.ch>,
Javier Martinez Canillas <javierm@...hat.com>,
Robert Foss <robert.foss@...aro.org>, lschyi@...omium.org,
Sam Ravnborg <sam@...nborg.org>, jjsu@...omium.org,
Andrzej Hajda <andrzej.hajda@...el.com>,
David Airlie <airlied@...ux.ie>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Jonas Karlman <jonas@...boo.se>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Neil Armstrong <narmstrong@...libre.com>,
Thierry Reding <thierry.reding@...il.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] drm/panel-edp: Debugfs for panel-edp
Hi,
On Fri, Feb 4, 2022 at 4:14 PM Douglas Anderson <dianders@...omium.org> wrote:
>
> The main goal of this series is the final patch in the series: to
> allow test code to reliably find out if we ended up hitting the
> "fallback" case of the generic edp-panel driver where we don't
> recognize a panel and choose to use super conservative timing.
>
> Version 1 of the patch actually landed but was quickly reverted since
> it was pointed out that it should have been done in debugfs, not
> sysfs.
>
> As discussed on IRC [1], we want this support to be under the
> "connector" directory of debugfs but there was no existing way to do
> that. Thus patch #2 in the series was born to try to plumb this
> through. It was asserted that it would be OK to rely on a fairly
> modern display pipeline for this plumbing and perhaps fail to populate
> the debugfs file if we're using older/deprecated pipelines.
>
> Patch #1 in the series was born because the bridge chip I was using
> was still using an older/deprecated pipeline. While this doesn't get
> us fully to a modern pipeline for ti-sn65dsi86 (it still doesn't move
> to "NO_CONNECTOR") it hopefully moves us in the right direction.
>
> This was tested on sc7180-trogdor devices with _both_ the ti-sn65dsi86
> and the parade-ps8640 bridge chips (since some devices have one, some
> the other). The parade-ps8640 already uses supports "NO_CONNECTOR",
> luckily.
>
> [1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2022-02-02
>
> Changes in v2:
> - ("ti-sn65dsi86: Use drm_bridge_connector") new for v2.
> - ("drm: Plumb debugfs_init through to panels") new for v2.
> - Now using debugfs, not sysfs
>
> Douglas Anderson (3):
> drm/bridge: ti-sn65dsi86: Use drm_bridge_connector
> drm: Plumb debugfs_init through to panels
> drm/panel-edp: Allow querying the detected panel via debugfs
>
> drivers/gpu/drm/bridge/panel.c | 12 +++++
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 72 +++++---------------------
> drivers/gpu/drm/drm_bridge_connector.c | 15 ++++++
> drivers/gpu/drm/drm_debugfs.c | 3 ++
> drivers/gpu/drm/panel/panel-edp.c | 37 +++++++++++--
> include/drm/drm_bridge.h | 7 +++
> include/drm/drm_connector.h | 7 +++
> include/drm/drm_panel.h | 8 +++
> 8 files changed, 98 insertions(+), 63 deletions(-)
Landed these three patches to drm-misc-next w/ accumulated tags:
$ git log --oneline -3
6ed19359d6bd drm/panel-edp: Allow querying the detected panel via debugfs
2509969a9862 drm: Plumb debugfs_init through to panels
e283820cbf80 drm/bridge: ti-sn65dsi86: Use drm_bridge_connector
If it turns out that we want to add more reporting when debugfs calls
return errors then I'm happy to submit follow-on patches. Discussion
about that can be found in:
https://lore.kernel.org/r/CAD=FV=Ut3N9syXbN7i939mNsx3h7-u9cU9j6=XFkz9vrh0Vseg@mail.gmail.com
Unless something changes, though, my current plan is not to do
follow-up patches and leave this as-is without any extra error
reporting.
-Doug
Powered by blists - more mailing lists