From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
To: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
kernel@collabora.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] driver core: Don't log intentional skip of device link creation as error
Date: Fri, 9 Aug 2024 12:13:25 -0400 [thread overview]
Message-ID: <c622df86-0372-450e-b3dd-ab93cd051d6f@notapiano> (raw)
In-Reply-To: <CAGETcx9e4mpcMY+pqMYXsVWGcjgkctCqgO665KgqUH4JvYbUAQ@mail.gmail.com>
On Mon, Jul 29, 2024 at 05:08:48PM -0700, Saravana Kannan wrote:
> On Mon, Jul 29, 2024 at 2:25 PM Nícolas F. R. A. Prado
> <nfraprado@collabora.com> wrote:
> >
> > On Tue, Jun 25, 2024 at 09:56:07AM -0400, Nícolas F. R. A. Prado wrote:
> > > On Mon, Jun 24, 2024 at 04:53:30PM -0700, Saravana Kannan wrote:
> > > > On Mon, Jun 24, 2024 at 8:21 AM Nícolas F. R. A. Prado
> > > > <nfraprado@collabora.com> wrote:
> > > > >
> > > > > Commit ac66c5bbb437 ("driver core: Allow only unprobed consumers for
> > > > > SYNC_STATE_ONLY device links") introduced an early return in
> > > > > device_link_add() to prevent useless links from being created. However
> > > > > the calling function fw_devlink_create_devlink() unconditionally prints
> > > > > an error if device_link_add() didn't create a link, even in this case
> > > > > where it is intentionally skipping the link creation.
> > > > >
> > > > > Add a check to detect if the link wasn't created intentionally and in
> > > > > that case don't log an error.
> > > >
> > > > Your point is somewhat valid, and I might Ack this. But this really
> > > > shouldn't be happening a lot. Can you give more context on how you are
> > > > hitting this?
> > >
> > > Of course. I'm seeing this on the mt8195-cherry-tomato-r2 platform.
> > >
> > > The following error is printed during boot:
> > >
> > > mediatek-drm-dp 1c500000.edp-tx: Failed to create device link (0x180) with backlight-lcd0
> > >
> > > It doesn't happen with the upstream defconfig, but with the following config
> > > change it does:
> > >
> > > -CONFIG_PWM_MTK_DISP=m
> > > +CONFIG_PWM_MTK_DISP=y
> > >
> > > That probably changes the order in which the MTK DP and the backlight drivers
> > > probe, resulting in the error.
> > >
> > > One peculiarity that comes to mind is that the DP driver calls
> > > devm_of_dp_aux_populate_bus() to run a callback once the panel has finished
> > > probing. I'm not sure if this could have something to do with the error.
> > >
> > > Full log at https://lava.collabora.dev/scheduler/job/14573149
> >
> > Hi Saravana,
> >
> > With the given context for where this issue is happening, what do you think
> > about this patch?
>
> Ah sorry, missed your earlier email.
>
> Couple of points:
> 1. It looks like the link in question is "SYNC_STATE_ONLY" because
> it's part of a cycle. Correct me if I'm wrong. You might want to use
> the new "post-init-providers" property to help fw_devlink break the
> cycle and enforce the right dependency between the edp-tx and your
> backlight. And then this error should go away and your device ordering
> is enforced a bit better.
I don't see any cycle there. edp-tx points to backlight, but backlight doesn't
point back (from mt8195-cherry.dtsi):
&edp_tx {
...
aux-bus {
panel {
compatible = "edp-panel";
power-supply = <&pp3300_disp_x>;
backlight = <&backlight_lcd0>;
backlight_lcd0: backlight-lcd0 {
compatible = "pwm-backlight";
brightness-levels = <0 1023>;
default-brightness-level = <576>;
enable-gpios = <&pio 82 GPIO_ACTIVE_HIGH>;
num-interpolated-steps = <1023>;
pwms = <&disp_pwm0 0 500000>;
power-supply = <&ppvar_sys>;
};
And DL_FLAG_CYCLE is not set in the flags in the error log: 0x180. (Let me know
if there's something else that I should be looking at to detect a cycle)
Thanks,
Nícolas
>
> 2. If we take this patch, it might be better to make a "useless device
> links" helper function and use the same on in device_link_add() and in
> the "if" condition that's used to decide if a device link should be
> created. The con == sup is another "useless device link" check. But
> I'm not really sure if we should mask this error as it help with stuff
> like (1). con == sup is a bit more clear cut example of a "useless
> device link" in the context of fw_devlink.
>
> -Saravana
next prev parent reply other threads:[~2024-08-09 16:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 15:20 Nícolas F. R. A. Prado
2024-06-24 23:53 ` Saravana Kannan
2024-06-25 13:55 ` Nícolas F. R. A. Prado
2024-07-29 21:25 ` Nícolas F. R. A. Prado
2024-07-30 0:08 ` Saravana Kannan
2024-08-09 16:13 ` Nícolas F. R. A. Prado [this message]
2024-10-02 20:57 ` Nícolas F. R. A. Prado
2024-10-14 12:49 ` Jon Hunter
2024-10-15 21:32 ` Nícolas F. R. A. Prado
2024-10-23 0:57 ` Saravana Kannan
2024-10-23 13:34 ` Nícolas F. R. A. Prado
2024-12-17 13:44 ` Matthias Schiffer
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=c622df86-0372-450e-b3dd-ab93cd051d6f@notapiano \
--to=nfraprado@collabora.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=saravanak@google.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
all inboxes | Powered by JetHome®