public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>,
	peng.fan@oss.nxp.com
Cc: festevam@gmail.com, linux-clk@vger.kernel.org, linux-imx@nxp.com,
	linux-kernel@vger.kernel.org, marex@denx.de,
	mturquette@baylibre.com, peng.fan@nxp.com, sboyd@kernel.org,
	shawnguo@kernel.org, tharvey@gateworks.com
Subject: Re: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure
Date: Tue, 13 Sep 2022 20:01:59 +0300	[thread overview]
Message-ID: <b7eada4f-9625-d2a0-d58b-73bb08d17cc9@gmail.com> (raw)
In-Reply-To: <20220913152140.iikckob5h3ecagfi@mercury.elektranox.org>

Thanks for the input Sebastian!

On 9/13/22 18:21, Sebastian Reichel wrote:
> Hi,
> 
> I had the same trouble before for QMX6 system on module, which feeds
> the i.MX6 32k clock via I2C RTC's 32k output. Here is how it has
> been solved upstream:
> 
> https://lore.kernel.org/all/20210428222953.235280-1-sebastian.reichel@collabora.com/
> 

So, if my poor brains (that have been conferencing the whole day) can 
still read this correctly - upstream solution is that drivers 
controllong clock gate need to have this "fixed-clock" propery check && 
not register the gate if fixed-clock is present, right?

I think the fixed clock is better than the vendor specific property as 
it still describes the real HW. I am not really thrilled by the fact 
that each clk (provider) driver may potentially need to implement this 
as no one knows when the clocks are used in such an environment. This is 
why I feel the support would better fit the core. (Yep - I didn't yet 
read the linked discussion - I know people who are smarter than me have 
probably thought this through already).

So, basically this would require adding fixed-clock node in PMIC node 
when the 32K clock must not be touched. I hope this suits the people 
looking after the board dts files. In the clk driver it requires the 
check for "fixed-clock" node + return w/o registering the clk if node is 
there.

I guess we could at least have a registration API (something like 
clk_register_if_not_fixed(), but "naming is hard" said Rob once to me) - 
it would not only slightly simplify the drivers but it would also help 
avoiding this same discussion with the next board where similar problem 
is surfacing. This of course needs buy-in from Stephen (as does any 
change to bd718x7-clk which goes through his tree).

Finally this probably requires the binding docs changes to all PMICs 
which use the bd718x7-clk driver - and I guess that is Rob's territory.

I am happy if someone patches the bd718x7-clk + all the binding docs. 
Especially the binding docs - I never get the right at first shot. I can 
also try giving a hand with the clk-bd718x7 if no one else will, but 
that will take some time (I'm currently travelling) :( Tim, others, 
please let me know if you wish me to try looking at this.

Yours
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

  reply	other threads:[~2022-09-13 18:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 22:23 BD71847 clk driver disables clk-32k-out causing RTC/WDT failure Tim Harvey
2022-09-02  4:14 ` Matti Vaittinen
2022-09-08 16:00   ` Tim Harvey
2022-09-08 16:55     ` Marek Vasut
2022-09-08 19:25       ` Tim Harvey
2022-09-08 20:39         ` Marek Vasut
2022-09-09  2:06           ` Peng Fan
2022-09-09  2:35             ` Marek Vasut
2022-09-09  5:06               ` Matti Vaittinen
2022-09-12  7:40                 ` Peng Fan
2022-09-12 17:15                   ` Tim Harvey
2022-09-12 20:40                     ` Matti Vaittinen
2022-09-13  2:27                       ` Peng Fan
2022-09-13 15:21                         ` Sebastian Reichel
2022-09-13 17:01                           ` Matti Vaittinen [this message]
2022-09-13  2:30                     ` Peng Fan
2022-09-09  6:56               ` Peng Fan
2022-09-09  7:01                 ` Peng Fan

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=b7eada4f-9625-d2a0-d58b-73bb08d17cc9@gmail.com \
    --to=mazziesaccount@gmail.com \
    --cc=festevam@gmail.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=mturquette@baylibre.com \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=sboyd@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=shawnguo@kernel.org \
    --cc=tharvey@gateworks.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