From: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [net-next,v2] net: ethernet: rtsn: Add support for Renesas Ethernet-TSN
Date: Wed, 8 May 2024 17:10:43 +0200 [thread overview]
Message-ID: <20240508151043.GH1385281@ragnatech.se> (raw)
In-Reply-To: <51b6a4f8-ef48-400f-acb6-fd20e661802d@lunn.ch>
Hello Andrew,
Thanks for your feedback, I really appreciate your effort reviewing this
work.
On 2024-05-08 16:00:21 +0200, Andrew Lunn wrote:
> > I agree it's odd and I will try to find out.
> >
> > If I remove all pm_ calls and the include of pm_runtime.h register reads
> > from the device do no longer works, so operating the device fails. Even
> > if I dig out the root cause for this, is there any harm in keeping the
> > pm_ operations in the initial entablement?
>
> It suggests something is broken. Do we want to merge broken code?
Of course I do not want broken code merged. I was curious if you knew of
any harmful side effect of of using pm_ functions I was unaware of.
>
> Once we understand the root cause maybe then we can decide it is O.K.
The root cause is that the module clock is not enabled without some
action. If I remove all pm_ calls as well as the inclusion of
linux/pm_runtime.h. The tsn module clock is left disabled after probe
completes.
# grep . /sys/kernel/debug/clk/tsn/*
/sys/kernel/debug/clk/tsn/clk_accuracy:0
/sys/kernel/debug/clk/tsn/clk_duty_cycle:1/2
/sys/kernel/debug/clk/tsn/clk_enable_count:0
/sys/kernel/debug/clk/tsn/clk_flags:CLK_SET_RATE_PARENT
/sys/kernel/debug/clk/tsn/clk_max_rate:18446744073709551615
/sys/kernel/debug/clk/tsn/clk_min_rate:0
/sys/kernel/debug/clk/tsn/clk_notifier_count:0
/sys/kernel/debug/clk/tsn/clk_parent:s0d4_hsc
/sys/kernel/debug/clk/tsn/clk_phase:0
/sys/kernel/debug/clk/tsn/clk_prepare_count:1
/sys/kernel/debug/clk/tsn/clk_protect_count:0
/sys/kernel/debug/clk/tsn/clk_rate:199999992
As the clock is disabled trying to operate the device is not possible.
The clock can either be enabled by the pm_ calls as show or be replaced
by an explicit clk_enable(), like this (the other pm_ related
calls/includes are of course also removed).
- pm_runtime_enable(&pdev->dev);
- pm_runtime_get_sync(&pdev->dev);
+ clk_enable(priv->clk);
Either of the two methods leaves the module clock running and the driver
can operate the device.
# grep . /sys/kernel/debug/clk/tsn/*
/sys/kernel/debug/clk/tsn/clk_accuracy:0
/sys/kernel/debug/clk/tsn/clk_duty_cycle:1/2
/sys/kernel/debug/clk/tsn/clk_enable_count:1
/sys/kernel/debug/clk/tsn/clk_flags:CLK_SET_RATE_PARENT
/sys/kernel/debug/clk/tsn/clk_max_rate:18446744073709551615
/sys/kernel/debug/clk/tsn/clk_min_rate:0
/sys/kernel/debug/clk/tsn/clk_notifier_count:0
/sys/kernel/debug/clk/tsn/clk_parent:s0d4_hsc
/sys/kernel/debug/clk/tsn/clk_phase:0
/sys/kernel/debug/clk/tsn/clk_prepare_count:1
/sys/kernel/debug/clk/tsn/clk_protect_count:0
/sys/kernel/debug/clk/tsn/clk_rate:199999992
I would prefer to keep the pm_ operations, but if you prefer I can
switch to using clk_enable().
--
Kind Regards,
Niklas Söderlund
next prev parent reply other threads:[~2024-05-08 15:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 20:18 [net-next,v2] net: ethernet: rtsn: Add support for Renesas Ethernet-TSN Niklas Söderlund
2024-05-07 20:57 ` Andrew Lunn
2024-05-07 21:50 ` Niklas Söderlund
2024-05-08 0:35 ` Andrew Lunn
2024-05-08 11:07 ` Niklas Söderlund
2024-05-08 0:52 ` Andrew Lunn
2024-05-08 11:03 ` Niklas Söderlund
2024-05-08 0:55 ` Andrew Lunn
2024-05-08 10:58 ` Niklas Söderlund
2024-05-08 12:33 ` Andrew Lunn
2024-05-08 12:55 ` Niklas Söderlund
2024-05-08 14:00 ` Andrew Lunn
2024-05-08 15:10 ` Niklas Söderlund [this message]
2024-05-08 15:29 ` Geert Uytterhoeven
2024-05-08 17:36 ` Andrew Lunn
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=20240508151043.GH1385281@ragnatech.se \
--to=niklas.soderlund+renesas@ragnatech.se \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yoshihiro.shimoda.uh@renesas.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;
as well as URLs for NNTP newsgroup(s).