linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ondřej Jirman" <megous@megous.com>
To: Saravana Kannan <saravanak@google.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-sunxi@lists.linux.dev, mripard@kernel.org, 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
Date: Mon, 17 May 2021 10:29:57 +0200	[thread overview]
Message-ID: <20210517082957.sddwy2dv5esbzmo4@core> (raw)
In-Reply-To: <CAGETcx93RxfsXG51zeaUK+UyKdEDgivqkmS85mcMPp0H42X5ZQ@mail.gmail.com>

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@xff.cz> 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.

regards,
	o.

> Thanks,
> Saravana
> 
> >
> > Where would be a good place to break that fwnode_link in code?
> >
> > Or can the fw_devlink code be made aware of this situation, where two fwnodes
> > are implemented by the same Linux device, somehow?
> >
> > Relevant references:
> >
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c#L600
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c#L212
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#L1176
> >
> > kind regards,
> >         o.

  reply	other threads:[~2021-05-17  8:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 17:05 fw_devlink=on and sunxi HDMI Ondřej Jirman
2021-05-17  6:32 ` Saravana Kannan
2021-05-17  8:29   ` Ondřej Jirman [this message]
2021-05-18 14:04     ` Maxime Ripard
2021-05-19 21:29     ` Saravana Kannan
2021-05-19 22:00       ` Ondřej Jirman
2021-05-19 22:15         ` Saravana Kannan

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=20210517082957.sddwy2dv5esbzmo4@core \
    --to=megous@megous.com \
    --cc=andre.przywara@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mripard@kernel.org \
    --cc=rafael@kernel.org \
    --cc=saravanak@google.com \
    --cc=wens@csie.org \
    /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;
as well as URLs for NNTP newsgroup(s).