Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b7eada4f-9625-d2a0-d58b-73bb08d17cc9@gmail.com>
Date:   Tue, 13 Sep 2022 20:01:59 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
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
References: <20220913152140.iikckob5h3ecagfi@mercury.elektranox.org>
From:   Matti Vaittinen <mazziesaccount@gmail.com>
Subject: Re: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure
In-Reply-To: <20220913152140.iikckob5h3ecagfi@mercury.elektranox.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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! ~~