Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 18 May 2021 16:04:42 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     =?utf-8?Q?Ond=C5=99ej?= Jirman <megous@megous.com>,
        Saravana Kannan <saravanak@google.com>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        linux-sunxi@lists.linux.dev, wens@csie.org,
        jernej.skrabec@gmail.com,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, andre.przywara@arm.com
Subject: Re: fw_devlink=on and sunxi HDMI
Message-ID: <20210518140442.4hb6og6qh5htublo@gilmour>
References: <20210516170539.2yxe43qwezonuo3r@core>
 <CAGETcx93RxfsXG51zeaUK+UyKdEDgivqkmS85mcMPp0H42X5ZQ@mail.gmail.com>
 <20210517082957.sddwy2dv5esbzmo4@core>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="fdh4hwf2hzbvoi6g"
Content-Disposition: inline
In-Reply-To: <20210517082957.sddwy2dv5esbzmo4@core>
Precedence: bulk


--fdh4hwf2hzbvoi6g
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 17, 2021 at 10:29:57AM +0200, Ond=C5=99ej Jirman wrote:
> On Sun, May 16, 2021 at 11:32:47PM -0700, Saravana Kannan wrote:
> > On Sun, May 16, 2021 at 10:05 AM Ond=C5=99ej Jirman <megi@xff.cz> wrote:
> > >
> > > Hello,
> > >
> > > Linux 5.13-rc1 again has fw_devlink=3Don enabled by default. I've fou=
nd that this
> > > breaks probing display pipeline and HDMI output on sunxi boards, beca=
use of
> > > fwnode_link between hdmi and hdmi-phy nodes.
> > >
> > > HDMI device probe keeps being avoided with these repeated messages in=
 dmesg:
> > >
> > >   platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy n=
ot ready
> > >
> > > Both nodes have their own compatible, but are implemented by a single
> > > struct device.
> > >
> > > This looks like a kind of situation that's expected to break fw_devli=
nk
> > > expectations by my reading of the the e-mails about trying the fw_dev=
link=3Don
> > > during 5.12 cycle.
> > >
> > > Is this supposed to be solved by implementing the PHY node as it's own
> > > device or by breaking the fwnode_link between the hdmi phy and hdmi n=
odes?
> > > Seems like second solution would be quicker now that rc1 is out.
> >=20
> > Seems like sun8i_hdmi_phy_probe() already does 95% of the work to make
> > the PHY a separate driver. Why not just finish it up by really making
> > it a separate driver? I'd really prefer doing that because this seems
> > unnecessarily messed up. The phy will have a struct device created for
> > it already. You are just not probing it.
>=20
> Currently it's all just a glue code for dw-hdmi, which is not using a phy
> framework and handles both the controller and phy parts. dw-hdmi needs pa=
ssing
> platform data around
> (https://elixir.bootlin.com/linux/latest/source/include/drm/bridge/dw_hdm=
i.h#L115)
> to get a specific set of phy glue callbacks hooked into platform data of =
dw-hdmi
> prior to calling dw_hdmi_probe.
>=20
> Looking at other users of dw_hdmi_probe this is the only one that has this
> unfortunate issue due to using phys binding internally as a part of one d=
evice.
>=20
> Just making it a platform driver will also change the probe order of phy =
and the
> controller, which I've heard from Jernej needs to have the current order =
of
> (controller and then phy) perserved, for some reason, and will make things
> still a bit more convoluted.
>=20
> So this looks like needs quite a bit of thought.

Yep, and even if it was simple (which it really isn't), it wouldn't be
-rc* material.

Maxime

--fdh4hwf2hzbvoi6g
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYKPJegAKCRDj7w1vZxhR
xY/sAQCoFYzBDvdB1iFrTeEgkP1/bJEtjBgkBnXBYqumOyP2ugD/TL6HP6UhWXEA
1BAzfJ+mg2XNxf66mlBJSN2Pz/8nBQo=
=64N2
-----END PGP SIGNATURE-----

--fdh4hwf2hzbvoi6g--