Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2767020pxb; Fri, 12 Feb 2021 00:12:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJz12nozVoHEuNJpR8raw8+4XM1Ae+f3w9S8Qn2jHlVkMoQzirP0qg6T+tuVpCmxR+obwR6R X-Received: by 2002:a17:906:8292:: with SMTP id h18mr1861445ejx.342.1613117537369; Fri, 12 Feb 2021 00:12:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613117537; cv=none; d=google.com; s=arc-20160816; b=a+m9D0RNv0T7mVi4c8qdhSgm/ThXFAEIVEy1VQtGdpY6WLjQSf+WoPOOPXAGRy2eyZ JxX36a+6hWFS9bZG1oaou+9uLn7lsJAXZEjShQCMR8cby2vXSAMNae8HslidDsjU1zsZ +wxs9C8v5gzino+HBIbAuSfAEv0oGQJjJwKNhcoxHeZnY4TtjS0tjn0Zhxa9aosfg8TW Ama5mqZOhhn/K4vmeElpruLbkHYJAWk50l23ysJv2knKtp83/4NF/rk9XvdlPWBQ4a2o lEKYrOFsTDLv2pP5SG5qVeG7Pto4oLGl+QPV2cLWgzqOd9WUUSS62hxmNXMowc5ImolL L09Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=DHLRE2UmB8C4wlDYI8k7uWIN7I9RjaZ2KYe3yihptMU=; b=H12KYkd42NWepZUcZDhkCJUOgcme0dnMX065qGOozHYiqCLQP35ueWm2Ae0GQp7fyu mq8Wv1A2vR2U2qxKZbf9fShnEezWf75MT00492wsQwTcc9HKYITUmlZDD+E1mDDn0UWx xDtULbo/B9uB/J+kARP4sIT85f0EmY4genhaiT0jpPKfXUs2uXh9Bzd3i4qwXaiFLY/u polnpGN27JPGCyzTGl8sIMX0bAxct9slOAhuXK0ARuwEKtVAw3HPtmgqn+mzIstHkPgy Y9TxRix+VY/HTSMSHyxL5MnB1GiQAV+YQhVFQEIKftsHIMBoZg6/SCkN9+UzL0fQHmOt PEvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=SgPTIN9l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gt36si5431415ejc.57.2021.02.12.00.11.53; Fri, 12 Feb 2021 00:12:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=SgPTIN9l; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229907AbhBLIJv (ORCPT + 99 others); Fri, 12 Feb 2021 03:09:51 -0500 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:60942 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229598AbhBLIJt (ORCPT ); Fri, 12 Feb 2021 03:09:49 -0500 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11C86l2M029175; Fri, 12 Feb 2021 09:08:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=DHLRE2UmB8C4wlDYI8k7uWIN7I9RjaZ2KYe3yihptMU=; b=SgPTIN9lqgwaVVpkZ+RZC5gItARGIhGqsdMWlXL1ng4qFgK0ZH84btADnmv2q3JCF1Kz Dmm8a8gSrwSDMO0D/E6d5q5JaEgv4K3d87myhQStAeUWyuC7qJOksxTAQBeSwdOWURPx ADunrwMYfVxgYkq92XrWDWIargGuzOOt21Smh5SMBGs+RR4AUNP8Ppm3HJlgp8Wl1L3L qpyzqABA08S0MaSiIztNlXwubfAVtZjlMe/h6QK33DVRHc1uo3jFzQ+SGyQzc+mgnteI Qp8BlbUt3PgDCwhlMPga9upVHJ81MNFkgF1QFs9PlyRuIRW2bpgZ5t0JkMJYhHd8OGUg jg== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 36hravbcje-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Feb 2021 09:08:42 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DCD72100034; Fri, 12 Feb 2021 09:08:41 +0100 (CET) Received: from Webmail-eu.st.com (gpxdag2node6.st.com [10.75.127.70]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id B967B219D40; Fri, 12 Feb 2021 09:08:41 +0100 (CET) Received: from lmecxl0572.lme.st.com (10.75.127.121) by GPXDAG2NODE6.st.com (10.75.127.70) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Feb 2021 09:08:40 +0100 Subject: Re: [PATCH v2 02/14] clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into one clock To: Stephen Boyd , Alexandre Torgue , Etienne Carriere , "Maxime Coquelin" , Michael Turquette , Philipp Zabel , "Rob Herring" , CC: , , , , References: <20210126090120.19900-1-gabriel.fernandez@foss.st.com> <20210126090120.19900-3-gabriel.fernandez@foss.st.com> <161285764074.418021.15522379930579131077@swboyd.mtv.corp.google.com> From: "gabriel.fernandez@foss.st.com" Message-ID: <5cc12945-0347-820c-1125-30ab4a947a00@foss.st.com> Date: Fri, 12 Feb 2021 09:08:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <161285764074.418021.15522379930579131077@swboyd.mtv.corp.google.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.75.127.121] X-ClientProxiedBy: GPXDAG1NODE5.st.com (10.75.127.66) To GPXDAG2NODE6.st.com (10.75.127.70) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369,18.0.737 definitions=2021-02-12_02:2021-02-12,2021-02-12 signatures=0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/9/21 9:00 AM, Stephen Boyd wrote: > Quoting gabriel.fernandez@foss.st.com (2021-01-26 01:01:08) >> From: Gabriel Fernandez >> >> 'ck_rtc' has multiple clocks as input (ck_hsi, ck_lsi, and ck_hse). >> A divider is available only on the specific rtc input for ck_hse. >> This Merge will facilitate to have a more coherent clock tree >> in no trusted / trusted world. >> >> Signed-off-by: Gabriel Fernandez >> --- >> drivers/clk/clk-stm32mp1.c | 49 +++++++++++++++++++++++++++++++++----- >> 1 file changed, 43 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c >> index 35d5aee8f9b0..0e1d4427a8df 100644 >> --- a/drivers/clk/clk-stm32mp1.c >> +++ b/drivers/clk/clk-stm32mp1.c >> @@ -245,7 +245,7 @@ static const char * const dsi_src[] = { >> }; >> >> static const char * const rtc_src[] = { >> - "off", "ck_lse", "ck_lsi", "ck_hse_rtc" >> + "off", "ck_lse", "ck_lsi", "ck_hse" >> }; >> >> static const char * const mco1_src[] = { >> @@ -1031,6 +1031,42 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name, >> return hw; >> } >> >> +/* The divider of RTC clock concerns only ck_hse clock */ >> +#define HSE_RTC 3 >> + >> +static unsigned long clk_divider_rtc_recalc_rate(struct clk_hw *hw, >> + unsigned long parent_rate) >> +{ >> + if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC)) >> + return clk_divider_ops.recalc_rate(hw, parent_rate); >> + >> + return parent_rate; >> +} >> + >> +static long clk_divider_rtc_round_rate(struct clk_hw *hw, unsigned long rate, >> + unsigned long *prate) >> +{ >> + if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC)) > This clk op can be called at basically any time. Maybe this should use > the determine rate op and then look to see what the parent is that comes > in via the rate request structure? Or is the intention to keep this > pinned to one particular parent? Looking at this right now it doesn't > really make much sense why the current parent state should play into > what rate the clk can round to, unless there is some more clk flags > going on that constrain the ability to change this clk's parent. Yes the intention is to keep this pinned for one particular parent. This divider is only applied on the 4th input of the MUX of the RTC and doesn't affect the HSE frequency for all the system. Oscillators  ----- | lse |----------------+----------------> ck_lse  -----                 |  -----                 | | lsi |------------+--------------------> ck_lsi  -----             |   |                    |   |  -----             |   | | hse |----+-------|---|----------------> ck_hse  -----     |       |   |            |       |   |         |\ mux            |       |   |  OFF -->| \            |       |   |         |  \     gate            |       |   --------->|  |     ---            |       |             |  |--->|   |--> ck_rtc            |       ------------->|  |     ---            |    -----------      |  |             ----| % 1 to 64 |--->| /                  -----------     |/                    divider I manage the RTC with a clock composite with a gate a mux and a specific rate ops for hse input. That why i need to the parent state. Best Regards Gabriel >> + return clk_divider_ops.round_rate(hw, rate, prate); >> + >> + return *prate; >> +} >> + >> +static int clk_divider_rtc_set_rate(struct clk_hw *hw, unsigned long rate, >> + unsigned long parent_rate) >> +{ >> + if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC)) >> + return clk_divider_ops.set_rate(hw, rate, parent_rate); >> + >> + return parent_rate; >> +} >> +