Thread (7 messages) 7 messages, 4 authors, 2021-05-19

Re: fw_devlink=on and sunxi HDMI

From: Maxime Ripard <hidden>
Date: 2021-05-18 14:04:49
Also in: linux-sunxi, lkml

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:
quoted
On Sun, May 16, 2021 at 10:05 AM Ondřej Jirman [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help