From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83DCFC4332F for ; Fri, 16 Dec 2022 14:36:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229665AbiLPOgW (ORCPT ); Fri, 16 Dec 2022 09:36:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229620AbiLPOgV (ORCPT ); Fri, 16 Dec 2022 09:36:21 -0500 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84B2F26571; Fri, 16 Dec 2022 06:36:20 -0800 (PST) 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 2547F85098; Fri, 16 Dec 2022 15:36:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1671201378; bh=2+1IGwNUrGJM6aop5OG6c33myDUKHVjv1Glh0tsxN1w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=sGPbFPmbf/V1gocq+4kpJP0PKoiTg3mOTDIO4Rbm8wUK/RIuRtstCeVOEAKcW9Gf7 UdQkLTyk8HOsIb+N3dI4YxHLMxcsphPBu+AMGQnEojmOvkhJ+XdhYyXVdanSIo6iVz mRTz6JPsKOu+PY3J+6BblhuTu31pfvf7kHXDpBBBZ20s1jfAkKHpD10skz5GOm10sg CCyBh3D1ytwVtsgu9U2hrrUwuJN5L6I7Tem/k1DQDXD2ZcxI3YArEfd+BxupWv195U gTsixIgZfHaUK9NkgLZk3VJhmQFt5iIfgvGoC9tQGwuWeZ/2CP3AE/6BOFRyGUuN8G sFmGj8Tp6e5QQ== Message-ID: Date: Fri, 16 Dec 2022 15:36:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH v3 2/2] dt-bindings: rtc: m41t80: Mark the clock: subnode as deprecated Content-Language: en-US To: Sebastian Reichel Cc: devicetree@vger.kernel.org, Krzysztof Kozlowski , Alessandro Zummo , Alexandre Belloni , Rob Herring , Krzysztof Kozlowski , linux-rtc@vger.kernel.org References: <20221211205124.23823-1-marex@denx.de> <20221211205124.23823-2-marex@denx.de> <20221215180659.sa54lkinwxoiz7bb@mercury.elektranox.org> <20221216142408.6x3e5dhtdvgiewtb@mercury.elektranox.org> From: Marek Vasut In-Reply-To: <20221216142408.6x3e5dhtdvgiewtb@mercury.elektranox.org> 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 Precedence: bulk List-ID: X-Mailing-List: linux-rtc@vger.kernel.org On 12/16/22 15:24, Sebastian Reichel wrote: > Hi, Hi, > On Thu, Dec 15, 2022 at 08:39:47PM +0100, Marek Vasut wrote: >> On 12/15/22 19:06, Sebastian Reichel wrote: >>> On Sun, Dec 11, 2022 at 09:51:24PM +0100, Marek Vasut wrote: >>>> The clock {} subnode seems like it is describing an always-on clock >>>> generated by the PMIC. This should rather be modeled by consumer of >>>> the clock taking phandle to the RTC node itself, since it already >>>> does have clock-cells and all. Since there are no users of the clock >>>> subnode in tree anyway, mark it as deprecated to avoid proliferation >>>> of this approach. >>>> >>>> Acked-by: Krzysztof Kozlowski >>>> Signed-off-by: Marek Vasut >>>> --- >>>> Cc: Alessandro Zummo >>>> Cc: Alexandre Belloni >>>> Cc: Rob Herring >>>> Cc: Krzysztof Kozlowski >>>> Cc: linux-rtc@vger.kernel.org >>>> To: devicetree@vger.kernel.org >>>> --- >>>> V2: - Add AB from Krzysztof >>>> V3: - No change >>>> --- >>> >>> I just noticed this by accident. Basically everything in the patch >>> description is wrong: >>> >>> 1. There is a in-tree user: arch/arm/boot/dts/imx6dl-qmx6.dtsi >> >> Sorry, I missed this one. >> >>> 2. The PMIC has nothing to do with this >> >> In [3] the commit message claims the PMIC supplies 32kHz clock to i.MX6 CKIL, >> which per IMX6DQRM rev.6 Table 18-3 row SNVS indirectly supplies SNVS RTC. >> This reminded me of commit: > > The word PMIC is not mentioned once in [3]. s@PMIC@m41t62 RTC@, sorry. > PMIC is not involved. > The QMX6 32khz chain is like this: > > 32kHz crystal -> m41t62 crystal input > m41t62 clock output -> i.MX6 CKIL > >> 9509593f327ac ("arm64: dts: imx8mm: Model PMIC to SNVS RTC clock path on >> Data Modul i.MX8M Mini eDM SBC") >> >> which solves exactly the same problem, system hangs when 32 kHz clock are >> stopped, except this time on i.MX8MM, clock are generated by PMIC on I2C >> (notice how the PMIC is referenced directly) and the clock are supplied to >> the SVNS RTC XTal terminals. >> >> I wonder if this could be reused on the QMX6 board too? > > IIRC On i.MX6 referencing the I2C connected RTC results in boot > hanging forever when trying to get the ckil clock in > imx6q_clocks_init. At least it used to be the case when I was > working on this - I no longer have access to the boards. Of course > properly referencing the RTC clock was the first route I tried. Hmmmmm, what shall we do, un-deprecate the clock sub-node ?