linux-kernel - Re: [PATCH v13 4/6] clk: meson: a1: add Amlogic A1 PLL clock controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFBinCCmNLQF_qV3k4kgDEAsemEsjL-GQtPex7Pmxrc2sHx30A@mail.gmail.com>
Date:   Sun, 14 May 2023 22:53:53 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Dmitry Rokosov <ddrokosov@...rdevices.ru>
Cc:     neil.armstrong@...aro.org, jbrunet@...libre.com,
        mturquette@...libre.com, sboyd@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, khilman@...libre.com,
        jian.hu@...ogic.com, kernel@...rdevices.ru, rockosov@...il.com,
        linux-amlogic@...ts.infradead.org, linux-clk@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v13 4/6] clk: meson: a1: add Amlogic A1 PLL clock
 controller driver

Hi Dmitry.

On Thu, May 11, 2023 at 3:26 PM Dmitry Rokosov <ddrokosov@...rdevices.ru> wrote:
[...]
> > If you agree with my statement from above I'll be able to make my
> > original question more specific:
> > Since we know that we have all the required inputs for fixed_pll,
> > sys_pll and hifi_pll - do you know what AUDDDS is and whether it
> > requires any specific clock inputs (other than "fixpll_in" and
> > "hifipll_in")?
> >
>
> To be honest, I have prepared A1 peripherals and A1 PLL drivers based on very
> poor Amlogic datasheets and custom 4.19-based vendor drivers.
> The vendor driver has an AUDDDS clock in the PLL clock part, but it is not
> used anywhere. Unfortunately, as usual, the datasheet doesn't provide any
> information or explanation about what it is. However, the driver has a few
> lines of comments that indicate:
>
>     /*
>      * aud dds clock is not pll clock, not divider clock,
>      * No clock model can describe it.
>      * So we regard it as a gate, and the gate ops
>      * should realize lonely.
>      */
>
> Additionally, the vendor driver states that AUDDDS has a 49Mhz clock,
> but I do not see any relationship with other clocks (including the exported
> GENCLK).
> Jian did not include it in the first version of the PLL driver, and I have
> decided not to change it either.
>
> I also noticed a few lines of AUDDDS initialization sequences in the vendor
> driver, which may affect CPU clock objects (from my point of view).
> However, they are currently under development, and I will try to figure it
> out with Amlogic support.
>
> > > However, I do not believe this to be a significant issue. The clock DT
> > > bindings are organized to simplify the process of introducing new bindings,
> > > whether public or private. For instance, we may add new bindings to
> > > include/dt-bindings at the end of the list and increase the overall number,
> > > without disrupting the DT bindings ABI (the old numbers will remain
> > > unchanged).
> > Yep, this part is clear to me. I should have been more specific that I
> > was asking about the inputs that are described in the .yaml file, not
> > the clock IDs.
>
> Actually, AUDDDS has an xtal2dds parent clock, and if we need to have
> the AUDDDS clock in the PLL driver, we should add one more link between
> peripherals and PLL drivers.
>
> Let me know if you have any questions.
I have no questions - all I can say is that:
- I like your approach of clarifying details of the AUDDDS clock with Amlogic
- and I fully agree with your conclusion that (depending on what
Amlogic says) we need one more link from the PLL driver to the AUDDDS
clock

Thank you for your persistence with this series, I'm sure it will pay
off in the long run!


Best regards,
Martin