archive mirror
 help / color / mirror / Atom feed
From: Douglas Anderson <>
To: Andrzej Hajda <>,
	Neil Armstrong <>,
	Laurent Pinchart <>,
	Jonas Karlman <>,
	Jernej Skrabec <>,
	Sam Ravnborg <>, Wolfram Sang <>
Cc: Lyude Paul <>,
	Steev Klimaszewski <>,
	Stephen Boyd <>,
	Bjorn Andersson <>,,
	Stanislav Lisovskiy <>,
	Linus W <>,,
	Maarten Lankhorst <>,
	Thierry Reding <>,,,
	Douglas Anderson <>,
	Andy Gross <>, Daniel Vetter <>,
	David Airlie <>,
	Maxime Ripard <>,
	Rob Herring <>,
	Robert Foss <>,
	Thomas Zimmermann <>,,
Subject: [PATCH v6 0/5] drm: Fix EDID reading on ti-sn65dsi86; solve some chicken-and-egg problems
Date: Mon,  3 May 2021 14:58:39 -0700	[thread overview]
Message-ID: <> (raw)

The primary goal of this series is to try to properly fix EDID reading
for eDP panels using the ti-sn65dsi86 bridge.

Previously we had a patch that added EDID reading but it turned out
not to work at bootup. This caused some extra churn at bootup as we
tried (and failed) to read the EDID several times and also ended up
forcing us to use the hardcoded mode at boot. With this patch series I
believe EDID reading is reliable at boot now and we never use the
hardcoded mode.

This series is the logical successor to the 3-part series containing
the patch ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only
if refclk") [1].

At v6 now, this patch series is smaller as I have landed most of the
cleanup patches. I've previously sent out a summary [2]. Now it just
has the i2c fix and some of the more controversial parts.

This patch was developed agains linuxnext (next-20210416) with
drm-misc-next (as of 20210503) merged in on a sc7180-trogdor-lazor
device. To get things booting for me, I had to use Stephen's patch [3]
to keep from crashing but otherwise all the patches I needed were

Primary change between v2 and v3 is to stop doing the EDID caching in
the core. I also added Andrzej's review tags.

Between v3 and v4 this series grew a whole lot. I changed it so that
the EDID reading is actually driven by the panel driver now as was
suggested by Andrzej. While I still believe that the old approach
wasn't too bad I'm still switching. Why?

The main reason is that I think it's useful in general for the panel
code to have access to the DDC bus and to be able to read the
EDID. This may allow us to more easily have the panel code support
multiple sources of panels--it can read the EDID and possibly adjust
timings based on the model ID. It also allows the panel code (or
perhaps backlight code?) to send DDC commands if they are need for a
particular panel.

At the moment, once the panel is provided the DDC bus then existing
code will assume that it should be in charge of reading the
EDID. While it doesn't have to work that way, it seems sane to build
on what's already there.

In order to expose the DDC bus to the panel, I had to solve a bunch of
chicken-and-egg problems in terms of probe ordering between the bridge
and the panel. I've broken the bridge driver into several sub drivers
to make this happen. At the moment the sub-drivers are just there to
solve the probe problem, but conceivably someone could use them to
break the driver up in the future if need be.

Between v4 and v5, high-level view of changes.
- Some of the early patches landed, so dropped from series.
- New pm_runtime_disable() fix (fixed a patch that already landed).
- Added Bjorn's tags to most patches
- Fixed problems when building as a module.
- Reordered debugfs patch and fixed error handling there.
- Dropped last patch. I'm not convinced it's safe w/out more work.

Between v5 and v6 this patch added the patch ("drm/dp: Allow an early
call to register DDC i2c bus") and only includes the patches that
haven't already landed.


Changes in v6:
- ("drm/dp: Allow an early call to register DDC i2c bus") new for v6.
- Use new drm_dp_aux_register_ddc() calls.

Douglas Anderson (5):
  i2c: i2c-core-of: Fix corner case of finding adapter by node
  drm/dp: Allow an early call to register DDC i2c bus
  drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev
  drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC
  arm64: dts: qcom: Link the panel to the bridge's DDC bus

 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi |  1 +
 drivers/gpu/drm/bridge/ti-sn65dsi86.c        | 99 +++++++++++++-------
 drivers/gpu/drm/drm_dp_helper.c              | 67 ++++++++++---
 drivers/i2c/i2c-core-of.c                    | 17 ++--
 include/drm/drm_dp_helper.h                  |  2 +
 5 files changed, 134 insertions(+), 52 deletions(-)


             reply	other threads:[~2021-05-03 21:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 21:58 Douglas Anderson [this message]
2021-05-03 21:58 ` [PATCH v6 1/5] i2c: i2c-core-of: Fix corner case of finding adapter by node Douglas Anderson
2021-05-17 20:16   ` Doug Anderson
2021-05-03 21:58 ` [PATCH v6 2/5] drm/dp: Allow an early call to register DDC i2c bus Douglas Anderson
2021-05-07 21:18   ` Lyude Paul
2021-05-07 22:00     ` Bjorn Andersson
2021-05-07 22:09       ` Lyude Paul
2021-05-14 11:16         ` Jani Nikula
2021-05-17 20:17           ` Doug Anderson
2021-05-03 21:58 ` [PATCH v6 3/5] drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev Douglas Anderson
2021-05-03 21:58 ` [PATCH v6 4/5] drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC Douglas Anderson
2021-05-03 21:58 ` [PATCH v6 5/5] arm64: dts: qcom: Link the panel to the bridge's DDC bus 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).