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;
From:   Peng Fan <peng.fan@nxp.com>
To:     Marek Vasut <marex@denx.de>,
        "tharvey@gateworks.com" <tharvey@gateworks.com>,
        Stephen Boyd <sboyd@kernel.org>
CC:     Matti Vaittinen <mazziesaccount@gmail.com>,
        linux-clk <linux-clk@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        Fabio Estevam <festevam@gmail.com>,
        Shawn Guo <shawnguo@kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>,
        Michael Turquette <mturquette@baylibre.com>
Subject: RE: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure
Thread-Topic: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure
Thread-Index: AQHYvlGBdqdb0Wka20ODtoakwJg21K3LiDmAgAozSACAAA+IgIAAKeoAgAAUeoCAAFoVIIAACWUAgABIzlA=
Date:   Fri, 9 Sep 2022 06:56:45 +0000
Message-ID: <DU0PR04MB9417919287BF69B2535348CC88439@DU0PR04MB9417.eurprd04.prod.outlook.com>
References: <CAJ+vNU1Za2CPGVX3q4HKufsxbL5zRrk1B5CWFpKritetrTs4dA@mail.gmail.com>
 <59b6dd0a-7cbb-5dbd-8da0-57baeba3327e@gmail.com>
 <CAJ+vNU2FVQRwCa3DnOwkFjaZg-ntFLZmetwDbSggDXDdwOOGTg@mail.gmail.com>
 <2ab24cc4-4aa2-d364-9b29-55f5d6b23626@denx.de>
 <CAJ+vNU0voeMW06Je6nyrV1Ud3sT8Us+RACcQtsKUwKVaXF+dQw@mail.gmail.com>
 <ce0ffc43-bae7-a55b-ebea-985abc765c33@denx.de>
 <DU0PR04MB9417D8123D40FBC980E9C05388439@DU0PR04MB9417.eurprd04.prod.outlook.com>
 <a03ce7a3-dfa5-6016-afbf-33193a5e2376@denx.de>
In-Reply-To: <a03ce7a3-dfa5-6016-afbf-33193a5e2376@denx.de>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9pdxnhx/1zQGCy4lt1azZu/0oHBB6YsKNXogxRt6uSZJ65KS91hjpyxnDAB6?=
 =?us-ascii?Q?U23PXPIj9UBNGsbAIFNFrS1J48FD3mEO/d9WSSMnquBFLEDaHke9klEiwdYV?=
 =?us-ascii?Q?hNPc4fnomeNP7asf/uiA4TPl38vSa3U7JvUT4s0uTKIeyr/fnsfKIMTP1jLh?=
 =?us-ascii?Q?2w86RiU4cEUCptH7w4INp/t7p9kPQADDwCXC097ybfHq0OXYie4cA5YUIzh6?=
 =?us-ascii?Q?TVRcIBZ/nUrrqTvBfMSkNruEZwC3k1vdSbcp5LNGzduuerj9c/K6W2V+PbTo?=
 =?us-ascii?Q?bfsRm9FBfpIBc8NMPBq21pkUOehTPy4luTjl3b9tn8lwWzYUVwmYJpOT8Drd?=
 =?us-ascii?Q?G7sjUiMipxD/Amq4G7dGNeQOz9z9hgn+G7sRmrCPVAfvTyzDfrX3b+3uzT1w?=
 =?us-ascii?Q?qV9J3GN3yQkQ44OmmIKXPX91lHaeSGYlk5MDtQ8k0/NCoCoHwQVyG6SzcUOj?=
 =?us-ascii?Q?9HUOICkmK0cbZoh9b9vGpa8ieMMaQslB5D5O/txMgrfXEcCoYcVtTtMQoLZt?=
 =?us-ascii?Q?HrVB+sSOIK4uopw4S/hJpHAqNumAjVztHUsSomKiin7jxDkjwizCIw0aSu4F?=
 =?us-ascii?Q?ZSr0bnywdVDve9eBJfxWTCdHZGAQWRKlZsZu6Y8ZahxtW24R/ksvH6z+8A2a?=
 =?us-ascii?Q?qahcCC5T8EssI4hr3ljTbkYmAz6egtF4kWAHVmhLzEKdP5RC4bfck03yKvf6?=
 =?us-ascii?Q?PlH0VLPHsMcREMnwXJGpOqPrPHRVrxCFpOhNaOw+4ECeyu6aGxUaYT2ZdOvE?=
 =?us-ascii?Q?gwoCIBCLyTNgrEcbUxVusGS2qbQOeqWARHkI0pTGhuE5HUvhctv1KBKUOma0?=
 =?us-ascii?Q?H0wjw2BrFaA/StVyzaXoGHey084/1/q9ZgOe7C8KgS4zWU/1y+Dei3MWj4ps?=
 =?us-ascii?Q?4gkgNjYFQTg9/yij2bTr5Ze6Zg2oZqPOd0FdMHQIEtwyVxxEqq9EYU0rcr93?=
 =?us-ascii?Q?t0vFiIClpuMc9kO1OqJ8GYJPq2QLWipC6+NX7z0vZsjypWbE4t8lKLkZAH5P?=
 =?us-ascii?Q?+5DzSiQgrW86sETvdlUzNw4EN8ciPfvZqDiietv3Q8BGl5Ed+T7+UqE/M9w4?=
 =?us-ascii?Q?OT7iHMNLhYm9UeGpjCGvWx4W7Mu64rpC+MVRJUf/IPRv6fYwxDDhUz/Kqqdx?=
 =?us-ascii?Q?k5vzHXRZzwIQtBNa/2JuqpTnXnqnMngo1SVwQk/4z4A3LNmpSxfWSPA8Nhkz?=
 =?us-ascii?Q?mJrzE6ynVAZG0JCNb/gp9W9491gOkB8ZEExmGFrIf7Gj26mDet6sPoE6YKkA?=
 =?us-ascii?Q?EyGZf/79EeJfM2qlxjcviUux4eBB2zdlAu9RtMzjaeFhPrf8GzJFuuqC2//c?=
 =?us-ascii?Q?UXNC0JYXb6u19DHy+ur9Ow9nMRqSYLzVDfIKmAd14RJ5NC3C8dACBfovi2eS?=
 =?us-ascii?Q?XdXcC2zcFMikdnxW47EwVLbF7G/74R8vgTM42L4Wm+L/1wcqQdtuSC6EtIxj?=
 =?us-ascii?Q?GeBnrSuRlNupmUQKj+QARMiFv5U/Z9nk8SQ7JVl8dH6gfwKIwPToEAHDg4Xk?=
 =?us-ascii?Q?vsA3ZXMe83puwkD3zEqK3TA+2SSd1zfZt7a8jkmmotqZ+DC1Mkd+AzMaqDWs?=
 =?us-ascii?Q?FCjAbBBcreU5DdxH9iY=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9417.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 83ae52c2-4b8b-464b-09f8-08da92307598
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2022 06:56:45.5174
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iZA3m4Ke2KGRjvB+ythEusggdUGOK0zq3mnBxvils+Bo/KajcBoDXk8t61J7s6vROdjZZpqeHL06sk8VtGm6Ow==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB6802
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Subject: Re: BD71847 clk driver disables clk-32k-out causing RTC/WDT fail=
ure
>=20
> On 9/9/22 04:06, Peng Fan wrote:
> >> Subject: Re: BD71847 clk driver disables clk-32k-out causing RTC/WDT
> >> failure
> >>
> >> On 9/8/22 21:25, Tim Harvey wrote:
> >>> On Thu, Sep 8, 2022 at 9:55 AM Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 9/8/22 18:00, Tim Harvey wrote:
> >>>>> On Thu, Sep 1, 2022 at 9:14 PM Matti Vaittinen
> >> <mazziesaccount@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi Tim,
> >>>>>>
> >>>>>> On 9/2/22 01:23, Tim Harvey wrote:
> >>>>>>> Greetings,
> >>>>>>>
> >>>>>>> I've found that the bd71847 clk driver
> >> (CONFIG_COMMON_CLK_BD718XX
> >>>>>>> drivers/clk/clk-bd718x7.c) disables clk-32k-out (the BD71847
> >>>>>>> C32K_OUT
> >>>>>>> pin) which is connected IMX8MM RTC_XTALI which ends up
> disabling
> >>>>>>> the IMX RTC as well as the IMX WDOG functionality.
> >>>>>>
> >>>>>> //snip
> >>>>>>
> >>>>>>> This happens via clk_unprepare_unused() as nothing is flagging
> >>>>>>> the clk-32k-out as being used. What should be added to the
> >>>>>>> device-tree to signify that this clk is indeed necessary and shou=
ld
> not be disabled?
> >>>>>>
> >>>>>> I have seen following proposal from Marek Vasut:
> >>>>>>
> >>>>>>
> >> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fl
> >>>>>> ore.kernel.org%2Fall%2F20220517235919.200375-1-
> >> marex%40denx.de%2FT%
> >>>>>>
> >>
> 2F%23m52d6d0831bf43d5f293e35cb27f3021f278d0564&amp;data=3D05%7C0
> >> 1%7Cp
> >>>>>>
> >>
> eng.fan%40nxp.com%7C07d48edcc47c4694e08208da91da2bf4%7C686ea1d
> >> 3bc2b
> >>>>>>
> >>
> 4c6fa92cd99c5c301635%7C0%7C0%7C637982664162868785%7CUnknown%
> >> 7CTWFpb
> >>>>>>
> >>
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> >> 6
> >>>>>>
> >>
> Mn0%3D%7C3000%7C%7C%7C&amp;sdata=3DuF26u9g4onuqCWzPRAvD%2F%
> >> 2FLByaEhh5
> >>>>>> Dtah9K8CcAOAM%3D&amp;reserved=3D0
> >>>>>>
> >>>>>> I am not sure if the discussion is completed though. I guess it
> >>>>>> was agreed this was needed/usefull and maybe the remaining thing
> >>>>>> to decide was just the property naming.
> >>>>>>
> >>>>>> Best Regards
> >>>>>>            -- Matti
> >>>>>>
> >>>>>
> >>>>> Thanks Matti,
> >>>>>
> >>>>> Marek - has there been any progress on determining how best to
> >>>>> keep certain clocks from being disabled?
> >>>>
> >>>> No. You can read the discussion above.
> >>>
> >>> Marek,
> >>>
> >>> I wasn't on the linux-clk list at that time so can't respond to the
> >>> thread but the discussion seems to have died out a couple of months
> >>> ago with no agreement between you or Stephen on how to deal with it.
> >>>
> >>> So where do we take this from here? It looks like there are about 18
> >>> boards with dt's using "rohm,bd718*" which would all have non
> >>> working RTC/WDOG with CONFIG_COMMON_CLK_BD718XX enabled
> (which it is
> >>> in
> >>> arch/arm64/configs/defconfig) right?
> >
> > Is there any requirement that the bd718xx clk needs to be runtime on/of=
f?
>=20
> Yes, the 32kHz clock on BD71xxx should behave like any other clock, unles=
s
> specified otherwise, see below.
>=20
> > I suppose the clk should always be never be off, if yes, why not have
> something:
>=20
> What is needed in this specific case of BD718xx is I think clock consumer=
 on
> the MX8M clock driver side which would claim the 32kHz input from the
> PMIC and up the clock enable count to keep the 32 kHz clock always on. Th=
e
> PMIC is most likely supplying 32 kHz clock to the MX8M, which if the 32 k=
Hz
> clock are turned off would hang (I observed that before too).

i.MX8M has internal 32 KHz XTAL module, why need external pmic 32KHz feed
in?

Thanks,
Peng.
>=20
> What I tried to address in this thread is a generic problem which commonl=
y
> appears on various embedded systems, except every time anyone tried to
> solve it in a generic manner, it was rejected or they gave up.
>=20
> The problem is this -- you have an arbitrary clock, and you need to keep =
it
> running always otherwise the system fails, and you do not have a clock
> consumer in the DT for whatever reason e.g. because the SoC is only used
> as a clock source for some unrelated clock net. There must be a way to ma=
rk
> the clock as "never disable these", i.e. critical-clock.
> (I feel like I keep repeating this over and over in this thread, so pleas=
e read
> the whole thread backlog)