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: <f85808f9-979d-1dc5-ac9a-9519c62e2737@denx.de>
Date:   Thu, 6 Oct 2022 13:05:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.1
Subject: Re: [RFC PATCH 0/2] Propose critical clocks
Content-Language: en-US
To:     Stephen Boyd <sboyd@kernel.org>,
        Marco Felsch <m.felsch@pengutronix.de>, abel.vesa@linaro.org,
        abelvesa@kernel.org, festevam@gmail.com, kernel@pengutronix.de,
        krzysztof.kozlowski+dt@linaro.org, mturquette@baylibre.com,
        robh+dt@kernel.org, s.hauer@pengutronix.de, shawnguo@kernel.org
Cc:     Peng Fan <peng.fan@nxp.com>, linux-clk@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-imx@nxp.com
References: <20220913102141.971148-1-m.felsch@pengutronix.de>
 <20221005082348.v43xbjrhbdlbaohv@pengutronix.de>
 <20221005230609.5BA04C433D6@smtp.kernel.org>
From:   Marek Vasut <marex@denx.de>
In-Reply-To: <20221005230609.5BA04C433D6@smtp.kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/6/22 01:06, Stephen Boyd wrote:
> Quoting Marco Felsch (2022-10-05 01:23:48)
>> Hi Stephen, Michael,
>>
>> I know it is a busy time right now, but maybe you have a few minutes for
>> this RFC. I know it is incomplete, but the interessting part is there
>> and it would fix a real issue we encountered on the imx8mm-evk's.

The i.MX8M hang when using 32kHz supplied by PMIC is solved by modeling 
the clock in DT correctly, see:

https://lore.kernel.org/all/20220924174603.458956-1-marex@denx.de/

> There's another approach by Marek[1]. Can you work together on a
> solution? I think we should step away from trying to make the critical
> flag work during clk registration, and turn on the clk during provider
> registration instead.

So that would work like the qualcomm-specific 'protected-clock' property?

I really want to avoid such clock-driver specific hacks which are poorly 
or inconsistently supported. This critical-clock should be a generic 
solution and that should be in clock core.

> That hopefully makes it simpler. We can keep the
> clk flag of course, so that the clk can't be turned off, but otherwise
> we shouldn't need to make registration path check for the property.
> 
> [1] https://lore.kernel.org/all/20220924174517.458657-1-marex@denx.de/