Re: fw_devlink=on and sunxi HDMI

[Maxime Ripard]

On Mon, May 17, 2021 at 10:29:57AM +0200, Ondřej 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řej Jirman <megi@xxxxxx> wrote:
> > >
> > > Hello,
> > >
> > > Linux 5.13-rc1 again has fw_devlink=on enabled by default. I've found that this
> > > breaks probing display pipeline and HDMI output on sunxi boards, because 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 not 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_devlink
> > > expectations by my reading of the the e-mails about trying the fw_devlink=on
> > > 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 nodes?
> > > Seems like second solution would be quicker now that rc1 is out.
> > 
> > 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.
> 
> 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 passing
> platform data around
> (https://elixir.bootlin.com/linux/latest/source/include/drm/bridge/dw_hdmi.h#L115)
> to get a specific set of phy glue callbacks hooked into platform data of dw-hdmi
> prior to calling dw_hdmi_probe.
> 
> 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 device.
> 
> 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.
> 
> 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

Attachment: signature.asc
Description: PGP signature