Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp1432954rwn; Thu, 8 Sep 2022 20:33:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR5L2zl/h4pKO2XpCV5Rnmo9MDSwJAw3DgDygGPNy90wvrKOCuGjMqVym0wDIUnL9RkrEgtu X-Received: by 2002:aa7:838a:0:b0:536:101a:9ccf with SMTP id u10-20020aa7838a000000b00536101a9ccfmr11992847pfm.18.1662694388449; Thu, 08 Sep 2022 20:33:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662694388; cv=none; d=google.com; s=arc-20160816; b=rTCLsBsYR9/CTZIvUN3cmzcLFyJij7otzj2Rvii42b3DbKCWZK0qh8C/0UiRA38oJn F31dml4c9YwYS1qb+Myr5kLv8ae8swAZ6XRXmo93k9u49LG2i5ICG6duboDVvLtRKJlk q2ioeseZ/FZmtHy+L+dKLb8bwXBLGJNDjTlUdAj+19QVVTrD+yvGE/SVC9Or72HpcfCS F31CybPPReY95o2leoRXjvySeSh2jtzxrdJgM6j7j9IHC4N9GELJvo/pmjpGLn6Vy9LF HqfrEbQbwAnFOkNrSSj+CqwSuhDvTvnFufQMQoRl/RIX8ExHmsnEboOteEWYKZQybeBI 8gAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=KZUxrLB9w3Y4O3+rbswXA7Hu2cCIB7pHxP9oYGvuKoI=; b=x1oZKLwal4eOz3foVVVh90WbVNysO6W1BsJ64VV2+tbBeK5XCFfbxfI9aIQO650KHI zQtxywyBfuiN4fB5IxVOwB/ei/PBppDJhZN+gUpFuHlvpIzJPXcIIVtvsgMKYOfUJAhc NRe6tFbcuVJZ9jAOD8Q0qLickwxdqU416xyCRkFea1GLxGh+y9b4Ke/e0aV+mxw8siY4 D1ovX2R5G0Q6NtwcGIhTZgi1fVJdvJGEH3AuIrgpvti/9g3vYOPZxIVSRrguSGJQDzXP 57+d1Bxp8i++asaZkMzd67nsfqGJ2ACzpAS3RQJwRBB8TjO4K3lKdw5aS/O53B6AsC8T C6lA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@denx.de header.s=phobos-20191101 header.b=tjTYyVa6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 6-20020a630006000000b00434bbab9db9si86819pga.696.2022.09.08.20.32.55; Thu, 08 Sep 2022 20:33:08 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@denx.de header.s=phobos-20191101 header.b=tjTYyVa6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229831AbiIICfR (ORCPT + 99 others); Thu, 8 Sep 2022 22:35:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbiIICfO (ORCPT ); Thu, 8 Sep 2022 22:35:14 -0400 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BFF86BD45; Thu, 8 Sep 2022 19:35:10 -0700 (PDT) Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 77E8984A5B; Fri, 9 Sep 2022 04:35:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1662690908; bh=KZUxrLB9w3Y4O3+rbswXA7Hu2cCIB7pHxP9oYGvuKoI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=tjTYyVa6jqfR3iUW9w+Lo3UY6twwuQte/MOC9MvZ421VURsZ9rFJXJqM8xsg9Oj/G oqc3LE9YH5/iFkXUaNgS4UJcbmtl6HviqogiIOzzlFIneyfS4eyU0JKL8Ovd+HDrHN VP77qkEaPCITRI6S168OlwiqTennd5ibc2biPFsrFVBkm3zjwYXdYBA8/i/O9quw9v y0L5gBLMxQU7oc+mmZXClR0QPTiSF8ydtADBdRCxH9hSP3+KCdKqGniZ7nK8v3iLWo iU4kNmd3OkEhM5TH35ipZ6NETo3fKsmbttE0Tm73sYxPB3TV0QJn0JZFaT//Y2o+RR jdam9fKwk1trg== Message-ID: Date: Fri, 9 Sep 2022 04:35:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure Content-Language: en-US To: Peng Fan , "tharvey@gateworks.com" , Stephen Boyd Cc: Matti Vaittinen , linux-clk , open list , Fabio Estevam , Shawn Guo , dl-linux-imx , Michael Turquette References: <59b6dd0a-7cbb-5dbd-8da0-57baeba3327e@gmail.com> <2ab24cc4-4aa2-d364-9b29-55f5d6b23626@denx.de> From: Marek Vasut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,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: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: >>>> >>>> On 9/8/22 18:00, Tim Harvey wrote: >>>>> On Thu, Sep 1, 2022 at 9:14 PM Matti Vaittinen >> 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 should not be disabled? >>>>>> >>>>>> I have seen following proposal from Marek Vasut: >>>>>> >>>>>> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl >>>>>> ore.kernel.org%2Fall%2F20220517235919.200375-1- >> marex%40denx.de%2FT% >>>>>> >> 2F%23m52d6d0831bf43d5f293e35cb27f3021f278d0564&data=05%7C0 >> 1%7Cp >>>>>> >> eng.fan%40nxp.com%7C07d48edcc47c4694e08208da91da2bf4%7C686ea1d >> 3bc2b >>>>>> >> 4c6fa92cd99c5c301635%7C0%7C0%7C637982664162868785%7CUnknown% >> 7CTWFpb >>>>>> >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >> 6 >>>>>> >> Mn0%3D%7C3000%7C%7C%7C&sdata=uF26u9g4onuqCWzPRAvD%2F% >> 2FLByaEhh5 >>>>>> Dtah9K8CcAOAM%3D&reserved=0 >>>>>> >>>>>> 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/off? Yes, the 32kHz clock on BD71xxx should behave like any other clock, unless specified otherwise, see below. > I suppose the clk should always be never be off, if yes, why not have something: 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. The PMIC is most likely supplying 32 kHz clock to the MX8M, which if the 32 kHz clock are turned off would hang (I observed that before too). What I tried to address in this thread is a generic problem which commonly appears on various embedded systems, except every time anyone tried to solve it in a generic manner, it was rejected or they gave up. 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 mark the clock as "never disable these", i.e. critical-clock. (I feel like I keep repeating this over and over in this thread, so please read the whole thread backlog)