On Thu, Mar 09, 2023 at 03:22:08PM +0100, Jerome Brunet wrote:
>
> On Mon 06 Mar 2023 at 22:05, Dmitry Rokosov <ddrokosov@xxxxxxxxxxxxxx> wrote:
>
> > Hello Jerome,
> >
> > Thanks a lot for such detailed review. Please find my comments and
> > thoughts below.
> >
> > On Mon, Mar 06, 2023 at 12:38:22PM +0100, Jerome Brunet wrote:
> >>
> >> On Wed 01 Mar 2023 at 21:37, Dmitry Rokosov <ddrokosov@xxxxxxxxxxxxxx> wrote:
> >>
> >> > Introduce Peripherals clock controller for Amlogic A1 SoC family.
> >> >
> >> > Signed-off-by: Jian Hu <jian.hu@xxxxxxxxxxx>
> >> > Signed-off-by: Dmitry Rokosov <ddrokosov@xxxxxxxxxxxxxx>
> >
> > [...]
> >
> >> > +static struct clk_regmap dspa_a_sel = {
> >> > + .data = &(struct clk_regmap_mux_data){
> >> > + .offset = DSPA_CLK_CTRL0,
> >> > + .mask = 0x7,
> >> > + .shift = 10,
> >> > + .table = mux_table_dsp_ab,
> >> > + },
> >> > + .hw.init = &(struct clk_init_data){
> >> > + .name = "dspa_a_sel",
> >> > + .ops = &clk_regmap_mux_ops,
> >> > + .parent_data = dsp_ab_parent_data,
> >> > + .num_parents = ARRAY_SIZE(dsp_ab_parent_data),
> >> > + /* DSPA_A clk parent should be set statically from dt */
> >> > + .flags = CLK_SET_RATE_NO_REPARENT,
> >> > + },
> >> > +};
> >> > +
> >> > +static struct clk_regmap dspa_a_div = {
> >> > + .data = &(struct clk_regmap_div_data){
> >> > + .offset = DSPA_CLK_CTRL0,
> >> > + .shift = 0,
> >> > + .width = 10,
> >> > + },
> >> > + .hw.init = &(struct clk_init_data){
> >> > + .name = "dspa_a_div",
> >> > + .ops = &clk_regmap_divider_ops,
> >> > + .parent_hws = (const struct clk_hw *[]) {
> >> > + &dspa_a_sel.hw
> >> > + },
> >> > + .num_parents = 1,
> >> > + .flags = CLK_SET_RATE_PARENT,
> >> > + },
> >> > +};
> >> > +
> >> > +static struct clk_regmap dspa_a = {
> >> > + .data = &(struct clk_regmap_gate_data){
> >> > + .offset = DSPA_CLK_CTRL0,
> >> > + .bit_idx = 13,
> >> > + },
> >> > + .hw.init = &(struct clk_init_data) {
> >> > + .name = "dspa_a",
> >> > + .ops = &clk_regmap_gate_ops,
> >> > + .parent_hws = (const struct clk_hw *[]) {
> >> > + &dspa_a_div.hw
> >> > + },
> >> > + .num_parents = 1,
> >> > + /*
> >> > + * DSPA_A accelerator clk, cannot be disabled by CCF if it
> >> > + * has been set by bootloader
> >>
> >> Then IGNORE_UNUSED is wrong. use RO ops with you must retain the
> >> bootloader config.
> >
> > I thought UNUSED logic will disable 'unused' clock during
> > initialization. Or do you mean it's not relevant for ro ops clock,
> > because disable() callback is not defined?
>
> It does. It does no prevent a disable if the clock is enabled then
> disabled. So what is here works as long as no driver touches this
> clock. In such case you are better off with RO ops.
>
Okay. But for dspX clocks I'm going to listen to your suggestion and
leave this out with default parameters.
> >
> >>
> >> Note that it is usually a bad idea to depend on the bootloader config.
> >> Things tends to go bad when other bootloader version join the fun, like
> >> upstream u-boot
> >
> > To be honest, I don't have the ability to test such behavior on our side,
> > because in my hands I have SoC SKUs w/o DSP only.
>
> Then maybe you should leave these clocks out for now.
>
Sure, agree.
> > But theoretically DSP FW can be started already from the bootloader, and
> > then we shouldn't touch this clock.
>
> In theory the bootloader can do it all, why bother booting linux ... :P
>
Exactly! It depends on your goals and motivation :-)
> > May be CCF has device tree tricks to solve such situations, don't know
> > actually. On the other hand, appropriate driver logic would be a nice
> > exit here.
>
> If you have a DSP, it is likely to have something to communicate with
> the OS at some point, or at least monitor. Such driver would need to
> handle to clocks properly.
>
> Since you can test this, I strongly suggest to leave this out for now.
>
Okay, it's the best decision in such situation.
> >
> > [...]
> >
> >> > +static struct clk_regmap dspa_en_nic = {
> >> > + .data = &(struct clk_regmap_gate_data){
> >> > + .offset = DSPA_CLK_EN,
> >> > + .bit_idx = 0,
> >> > + },
> >> > + .hw.init = &(struct clk_init_data) {
> >> > + .name = "dspa_en_nic",
> >> > + .ops = &clk_regmap_gate_ops,
> >> > + .parent_hws = (const struct clk_hw *[]) {
> >> > + &dspa_sel.hw
> >> > + },
> >> > + .num_parents = 1,
> >> > + /*
> >> > + * DSPA_EN_NIC accelerator clk, cannot be disabled by CCF if it
> >> > + * has been set by bootloader
> >> > + */
> >> > + .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
> >>
> >> All this just highlight the lack of proper drivers to handle the clock,
> >> like remote proc one.
> >>
> >
> > Okay, let's imagine we have such a driver. If DSP is already running,
> > we can skip the clock setup on this driver side. Hmmm. It looks like
> > a proper solution...
> >
> > I would prefer to tag it with TODO and mark DSP clocks with ro_ops till
> > we don't have such a driver.
> >
> > [...]
> >
> >> > +
> >> > +static struct clk_regmap fclk_div2_divn = {
> >> > + .data = &(struct clk_regmap_gate_data){
> >> > + .offset = CLK12_24_CTRL,
> >> > + .bit_idx = 12,
> >> > + },
> >> > + .hw.init = &(struct clk_init_data){
> >> > + .name = "fclk_div2_divn",
> >> > + .ops = &clk_regmap_gate_ops,
> >> > + .parent_hws = (const struct clk_hw *[]) {
> >> > + &fclk_div2_divn_pre.hw
> >> > + },
> >> > + .num_parents = 1,
> >> > + .flags = CLK_SET_RATE_PARENT,
> >> > + },
> >> > +};
> >> > +
> >> > +/*
> >> > + * the index 2 is sys_pll_div16, it will be completed in the CPU clock ctrl,
> >>
> >> I don't get this, what do you mean ?
> >>
> >
> > I mean, it will be implemented in the CPU clock controller driver in the
> > next patch series. Agree, I have to make a rephrase.
> >
> >> > + * the index 4 is the clock measurement source, it relies on
> >> > + * the clock measurement register configuration.
> >>
> >> Obviously ... What mean here is that clock measurement is a debug
> >> feature and should be considered
> >>
>
> Arff sorry, "should *NOT* be considered"
>
Yep, in the current patch (and at all I suppose) it should not be
considered. But IMHO I need to comment out why index 4 is missing.
> >
> > Should I mark it with TODO tag? I prefer to implement 'must have' logic
> > first. Clock measurement are optional from my point of view.
> >
> > [...]
> >
> >> > +static struct clk_regmap pwm_a = {
> >> > + .data = &(struct clk_regmap_gate_data){
> >> > + .offset = PWM_CLK_AB_CTRL,
> >> > + .bit_idx = 8,
> >> > + },
> >> > + .hw.init = &(struct clk_init_data) {
> >> > + .name = "pwm_a",
> >> > + .ops = &clk_regmap_gate_ops,
> >> > + .parent_hws = (const struct clk_hw *[]) {
> >> > + &pwm_a_div.hw
> >> > + },
> >> > + .num_parents = 1,
> >> > + /*
> >> > + * The CPU working voltage is controlled by pwm_a
> >> > + * in BL2 firmware. The clock is required by the platform
> >> > + * to operate correctly. Add the CLK_IS_CRITICAL flag to
> >> > + * avoid changing at runtime.
> >> > + * About critical, refer to sys
> >> > + */
> >>
> >> PWM_A required by the BL2 ... really ? Looks really fishy to me.
> >>
> >> Is it possible it is used by regulator instead ?
> >>
> >
> > Honestly, this comment's information was grabbed from Amlogic custom
> > driver. It has such words:
> >
> > /*
> > * add CLK_IGNORE_UNUSED flag for pwm controller GATE
> > * clk core will disable unused clock, it may disable
> > * vddcore voltage which contrlled by one pwm in bl21.
> > * add the flag to avoid changing cpu voltage.
> > */
> >
> > We don't have bl21 source code in the hands, so I can't check
> > unfortunately. But I have no reasons to don't trust Amlogic custom
> > clk driver decisions about low level bootloaders roles.
>
> So it is a regulator. Not the BL2(1)
>
> There are several reasons why this is wrong:
> * CLK_IGNORE_UNUSED would be wrong for reasons I already mentionned
> * CLK_SET_RATE_PARENT | CLK_IS_CRITICAL is not great either because
> nothing prevents the rate to be changed to an absurdly low value, which
> would not go well with a DVFS PWM.
> * This bakes power contraints specific to your board in the SoC clock
> controller. Another board, another BL21 could have different
> contraints. We can't lock all PWM clock sources. This is not
> appropriate.
>
> You need to properly describe your regualtors in DT.
>
I've got deeper and checked other board configurations. Now I see what
you mean. Voltage regulations should happen using vddcpu driver and pwm
clk is used to control core voltage. Thank you for pointing me to this
architecture problem.
In the next patch I will change pwm_a flags to the default value with
CLK_SET_RATE_PARENT.
[...]
--
Thank you,
Dmitry
