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;
Date:   Tue, 30 May 2023 15:06:40 +0300
From:   Dmitry Rokosov <ddrokosov@sberdevices.ru>
To:     Jerome Brunet <jbrunet@baylibre.com>
CC:     Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
        <neil.armstrong@linaro.org>, <mturquette@baylibre.com>,
        <sboyd@kernel.org>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <khilman@baylibre.com>,
        <jian.hu@amlogic.com>, <kernel@sberdevices.ru>,
        <rockosov@gmail.com>, <linux-amlogic@lists.infradead.org>,
        <linux-clk@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v15 6/6] clk: meson: a1: add Amlogic A1 Peripherals clock
 controller driver
Message-ID: <20230530120640.irugyrio3qa7czjy@CAB-WSD-L081021>
References: <20230517133309.9874-1-ddrokosov@sberdevices.ru>
 <20230517133309.9874-7-ddrokosov@sberdevices.ru>
 <CAFBinCBs7-9CvfQLxLoG5=FjmSK+S5eGsLXOAyQN9kNOg2q-2g@mail.gmail.com>
 <20230522133212.fcxgsml4hmvj65bb@CAB-WSD-L081021>
 <1jr0qy42tn.fsf@starbuckisacylon.baylibre.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1jr0qy42tn.fsf@starbuckisacylon.baylibre.com>
User-Agent: NeoMutt/20220415
Precedence: bulk

Hello Jerome,

Thank you for the review!

On Tue, May 30, 2023 at 10:32:57AM +0200, Jerome Brunet wrote:
> 
> On Mon 22 May 2023 at 16:32, Dmitry Rokosov <ddrokosov@sberdevices.ru> wrote:
> 
> > Hello Martin,
> >
> > Thank you so much for the review, I really appreciate it!
> > Please find my comments below.
> >
> > On Fri, May 19, 2023 at 11:03:54PM +0200, Martin Blumenstingl wrote:
> >> Hi Dmitry,
> >> 
> >> On Wed, May 17, 2023 at 3:33 PM Dmitry Rokosov <ddrokosov@sberdevices.ru> wrote:
> >> [...]
> >> > +static struct clk_regmap sys_b_sel = {
> >> > +       .data = &(struct clk_regmap_mux_data){
> >> > +               .offset = SYS_CLK_CTRL0,
> >> > +               .mask = 0x7,
> >> > +               .shift = 26,
> >> > +               .table = mux_table_sys,
> >> > +       },
> >> > +       .hw.init = &(struct clk_init_data){
> >> > +               .name = "sys_b_sel",
> >> > +               .ops = &clk_regmap_mux_ro_ops,
> >> the sys_*_sel muxes and sys_*_gate are _ro...
> >> 
> >> > +               .parent_data = sys_parents,
> >> > +               .num_parents = ARRAY_SIZE(sys_parents),
> >> > +       },
> >> > +};
> >> > +
> >> > +static struct clk_regmap sys_b_div = {
> >> > +       .data = &(struct clk_regmap_div_data){
> >> > +               .offset = SYS_CLK_CTRL0,
> >> > +               .shift = 16,
> >> > +               .width = 10,
> >> > +       },
> >> > +       .hw.init = &(struct clk_init_data){
> >> > +               .name = "sys_b_div",
> >> > +               .ops = &clk_regmap_divider_ops,
> >> ...but the sys_*_div aren't
> >> Is this on purpose? If it is: why can the divider be changed at
> >> runtime but the mux can't?
> >> 
> >
> > Ah, that's a good catch. Since the system clock is set up by the BootROM
> > code, all sys_* dividers and gates should be read-only. I'll make sure
> > to change that in the next version.
> >
> >> [...]
> >> > +/*
> >> > + * the index 2 is sys_pll_div16, it will be implemented in the CPU clock driver,
> >> We need to add the "sys_pll_div16" input to the dt-bindings since they
> >> should always describe the hardware (regardless of what the driver
> >> implements currently).
> >> I'm not sure how to manage this while we don't have the CPU clock
> >> driver ready yet but I'm sure Rob or Krzysztof will be able to help us
> >> here.
> >> 
> >
> > I've shared my thoughts about it in the bindings thread. Please take a
> > look.
> >
> >> > + * the index 4 is the clock measurement source, it's not supported yet
> >> I suspect that this comes from the clock measurer IP block and if so
> >> the dt-bindings should probably describe this input. But again, we'd
> >> need to keep it optional for now since our clock measurer driver
> >> doesn't even implement a clock controller.
> >> 
> >
> > Indeed, this is a similar situation to what we have with the inputs and
> > clocks of the CPU and Audio clock controllers. It seems like there is
> > only one option here: we should mark it with a TODO tag...
> >
> >> [...]
> >> > +static struct clk_regmap pwm_a_sel = {
> >> > +       .data = &(struct clk_regmap_mux_data){
> >> > +               .offset = PWM_CLK_AB_CTRL,
> >> > +               .mask = 0x1,
> >> > +               .shift = 9,
> >> > +       },
> >> > +       .hw.init = &(struct clk_init_data){
> >> > +               .name = "pwm_a_sel",
> >> > +               .ops = &clk_regmap_mux_ops,
> >> > +               .parent_data = pwm_abcd_parents,
> >> > +               .num_parents = ARRAY_SIZE(pwm_abcd_parents),
> >> > +               /* For more information, please refer to rtc clock */
> >> > +               .flags = CLK_SET_RATE_NO_REPARENT,
> >> As mentioned in [0] we'll work with Heiner to see if we can improve
> >> the decision making process of the PWM controller driver so that we
> >> can just have .flags = 0 here.
> >> This applies to all other occurrences of the same comment about the rtc clock.
> >
> > Sure, I'll make the change in v16. In my opinion, we should remove the
> > CLK_SET_RATE_NO_REPARENT flag from all RTC related clock objects,
> > including PWM, regardless of the outcome of the Heiner discussion. Based
> > on our IRC talk, the decision has more pros than cons -
> > https://libera.irclog.whitequark.org/linux-amlogic/2023-05-18
> 
> The clock scheme of PWM could indeed be handled like audio is but it
> not strictly required.
> 
> In audio we have a limited number of PLLs (root sources). There is a lot
> more consummers than there is root sources. If the root sources rate is
> not carefully chosen to statisfy all needs, we could end in a situation
> where we can't satisfy all consummers or we must glitch the source to do
> so.
> 
> For the PWM, I think (but I'm not 100% sure) that the main clock controller
> provides a source for each PWM. No risk of race there. That is why AML
> decided to completly ignore the clock element in the PWM IP, because
> they can do almost everything with what is in the main controller ... Still
> ignoring those part is wrong
> 
> For the RTC, If you want/need to handle external RTCs, I don't think you
> have much of a choice. If both the internal and external *report* the
> same rate, CCF can't really know if one is best. It will just pick one,
> no necessarily the one you want. I don't really see a way around manual
> selection for this.
> 

Per my understading, the rtc32k Amlogic clock is an internal clock and
cannot be an external one. Amlogic has provided it as an internal 32k
stable clock with low jitter.

You're absolutely right that there is no data available to confirm the
choice of an external RTC clock in the CCF. However, as per the approach
we discussed with Martin and Heiner, we can still use the RTC clock as a
parent for PWM in the current implementation. If the parent clock
already has 32k, we do not change the rate from the PWM driver. The
benefit of this approach is that reparenting is still available, but the
PWM child cannot change the RTC frequency; it simply uses the
appropriate parent clock. Additionally, if the parent is already set to
rtc32k, we shouldn't change it.

-- 
Thank you,
Dmitry