From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Thomas Graichen <thomas.graichen@gmail.com>,
Douglas Anderson <dianders@chromium.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Jon Hunter <jonathanh@nvidia.com>,
dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan
Date: Tue, 21 Dec 2021 11:58:03 +0100 [thread overview]
Message-ID: <YcGzO0A/iWzhFjvE@orome> (raw)
In-Reply-To: <e27bd5e0-51d2-875b-aa41-f198230880ac@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4916 bytes --]
On Mon, Dec 20, 2021 at 07:12:03PM +0300, Dmitry Osipenko wrote:
> 20.12.2021 18:27, Thierry Reding пишет:
> > On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
> >> 20.12.2021 13:48, Thierry Reding пишет:
> >>> From: Thierry Reding <treding@nvidia.com>
> >>>
> >>> Hi,
> >>>
> >>> this is an alternative proposal to fix panel support on Venice 2 and
> >>> Nyan. Dmitry had proposed a different solution that involved reverting
> >>> the I2C/DDC registration order and would complicate things by breaking
> >>> the encapsulation of the driver by introducing a global (though locally
> >>> scoped) variable[0].
> >>>
> >>> This set of patches avoids that by using the recently introduced DP AUX
> >>> bus infrastructure. The result is that the changes are actually less
> >>> intrusive and not a step back. Instead they nicely remove the circular
> >>> dependency that previously existed and caused these issues in the first
> >>> place.
> >>>
> >>> To be fair, this is not perfect either because it requires a device tree
> >>> change and hence isn't technically backwards-compatible. However, given
> >>> that the original device tree was badly broken in the first place, I
> >>> think we can make an exception, especially since it is not generally a
> >>> problem to update device trees on the affected devices.
> >>>
> >>> Secondly, this relies on infrastructure that was introduced in v5.15 and
> >>> therefore will be difficult to backport beyond that. However, since this
> >>> functionality has been broken since v5.13 and all of the kernel versions
> >>> between that and v5.15 are EOL anyway, there isn't much that we can do
> >>> to fix the interim versions anyway.
> >>>
> >>> Adding Doug and Laurent since they originally designed the AUX bus
> >>> patches in case they see anything in here that would be objectionable.
> >>>
> >>> Thierry
> >>>
> >>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> >>>
> >>> Thierry Reding (2):
> >>> drm/tegra: dpaux: Populate AUX bus
> >>> ARM: tegra: Move panels to AUX bus
> >>>
> >>> arch/arm/boot/dts/tegra124-nyan-big.dts | 15 +++++++++------
> >>> arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
> >>> arch/arm/boot/dts/tegra124-venice2.dts | 14 +++++++-------
> >>> drivers/gpu/drm/tegra/Kconfig | 1 +
> >>> drivers/gpu/drm/tegra/dpaux.c | 7 +++++++
> >>> 5 files changed, 33 insertions(+), 19 deletions(-)
> >>>
> >>
> >> It should "work" since you removed the ddc-i2c-bus phandle from the
> >> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
> >> probe. But this looks like a hack rather than a fix.
> >
> > The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
> > not specified. And that makes perfect sense because we'd basically just
> > be pointing back to the AUX node anyway.
> >
> >> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
> >> should be relevant here. The drm_dp_aux_register() still should to
> >> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
> >> panel->ddc adapter won't be registered.
> >
> > drm_dp_aux_register() is only needed to expose the device to userspace
> > and make the I2C adapter available to the rest of the system. But since
> > we already know the AUX and I2C adapter, we can use it directly without
> > doing a separate lookup. drm_dp_aux_init() should be enough to set the
> > adapter up to work for what we need.
> >
> > See also the kerneldoc for drm_dp_aux_register() where this is described
> > in a bit more detail.
>
> Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
> DDC will work properly anyways with that on v5.16.
>
> But the aux-bus usage still is irrelevant for the fix. Let's not use it
> then.
Yes, it's completely relevant because it essentially replaces the I2C
DDC. With the AUX bus, the AUX and hence the I2C DDC can be implied from
the bus' parent.
> >> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >> instantiated, AFAICS.
> >
> > I've tested this and it works fine on Venice 2. Since that was the
> > reference design for Nyan, I suspect that Nyan's will also work.
> >
> > It'd be great if Thomas or anyone else with access to a Nyan could
> > test this to verify that.
>
> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> 2023, hence we need to either use:
All the (at least relevant) functionality that is in panel-edp was in
panel-simple before it was moved to panel-edp. I've backported this set
of patches to v5.15 and it works just fine there.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-12-21 10:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-20 10:48 [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan Thierry Reding
2021-12-20 10:48 ` [PATCH 1/2] drm/tegra: dpaux: Populate AUX bus Thierry Reding
2021-12-22 19:48 ` Dmitry Osipenko
2022-01-06 1:02 ` Doug Anderson
2021-12-20 10:48 ` [PATCH 2/2] ARM: tegra: Move panels to " Thierry Reding
2021-12-22 19:30 ` Dmitry Osipenko
2022-03-06 17:59 ` Dmitry Osipenko
2022-03-07 7:45 ` Thierry Reding
2022-01-06 1:02 ` Doug Anderson
2021-12-20 14:45 ` [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan Dmitry Osipenko
2021-12-20 15:27 ` Thierry Reding
2021-12-20 16:12 ` Dmitry Osipenko
2021-12-20 16:55 ` Dmitry Osipenko
2021-12-21 5:35 ` Dmitry Osipenko
2021-12-21 10:58 ` Thierry Reding [this message]
2021-12-21 15:47 ` Dmitry Osipenko
2021-12-21 16:17 ` Thierry Reding
2021-12-21 16:45 ` Dmitry Osipenko
2021-12-21 18:01 ` Thierry Reding
2021-12-22 3:01 ` Dmitry Osipenko
2021-12-22 11:53 ` Thierry Reding
2021-12-22 19:26 ` Dmitry Osipenko
2022-01-06 1:11 ` Doug Anderson
2022-01-14 11:35 ` Dmitry Osipenko
2022-02-22 10:39 ` Dmitry Osipenko
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=YcGzO0A/iWzhFjvE@orome \
--to=thierry.reding@gmail.com \
--cc=dianders@chromium.org \
--cc=digetx@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jonathanh@nvidia.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-tegra@vger.kernel.org \
--cc=thomas.graichen@gmail.com \
/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