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;
References: <20220728054202.6981-1-yu.tu@amlogic.com>
 <1j8rodhfn9.fsf@starbuckisacylon.baylibre.com>
 <032b3c3f-f899-bf53-ecbb-35191d39392b@amlogic.com>
User-agent: mu4e 1.8.6; emacs 27.1
From:   Jerome Brunet <jbrunet@baylibre.com>
To:     Yu Tu <yu.tu@amlogic.com>, linux-clk@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
        Neil Armstrong <narmstrong@baylibre.com>,
        Kevin Hilman <khilman@baylibre.com>,
        Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Subject: Re: [PATCH V2 0/3] Add S4 SoC clock controller driver
Date:   Thu, 28 Jul 2022 10:27:00 +0200
In-reply-to: <032b3c3f-f899-bf53-ecbb-35191d39392b@amlogic.com>
Message-ID: <1j4jz1hbr5.fsf@starbuckisacylon.baylibre.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On Thu 28 Jul 2022 at 16:06, Yu Tu <yu.tu@amlogic.com> wrote:

> Hi JB=EF=BC=8C
>
> On 2022/7/28 15:08, Jerome Brunet wrote:
>> [ EXTERNAL EMAIL ]
>>=20
>> On Thu 28 Jul 2022 at 13:41, Yu Tu <yu.tu@amlogic.com> wrote:
>>=20
>>> 1. Add clock controller driver for S4 SOC.
>>>
>>> Yu Tu (3):
>>>    dt-bindings: clk: meson: add S4 SoC clock controller bindings
>>>    arm64: dts: meson: add S4 Soc clock controller in DT
>>>    clk: meson: s4: add s4 SoC clock controller driver
>>>
>>> V1 -> V2: Change format as discussed in the email.
>>>
>>> Link:https://lore.kernel.org/linux-amlogic/20220708062757.3662-1-yu.tu@=
amlogic.com/
>>>
>>>   .../bindings/clock/amlogic,gxbb-clkc.txt      |    1 +
>>>   MAINTAINERS                                   |    1 +
>>>   arch/arm64/boot/dts/amlogic/meson-s4.dtsi     |   11 +
>>>   drivers/clk/meson/Kconfig                     |   15 +
>>>   drivers/clk/meson/Makefile                    |    1 +
>>>   drivers/clk/meson/s4.c                        | 4732 +++++++++++++++++
>>>   drivers/clk/meson/s4.h                        |  296 ++
>>>   include/dt-bindings/clock/s4-clkc.h           |  146 +
>>>   8 files changed, 5203 insertions(+)
>>>   create mode 100644 drivers/clk/meson/s4.c
>>>   create mode 100644 drivers/clk/meson/s4.h
>>>   create mode 100644 include/dt-bindings/clock/s4-clkc.h
>>>
>>>
>>> base-commit: b293bc9286ee21824e93f0fcfed3b78fdfee01e6
>> Please don't post until you have addressed *ALL* the comments from the
>> previous version.
> The last email asked you to adopt A1 method, but you did not reply?
>
>> At first glance, I can see that this is still a single driver for
>> what is obviously 2 controllers with 2 register spaces. Simple comments
>> like the "<< 2" in the register declaration have not been addressed eith=
er.
> I understand that this should be a controller, just two address
> descriptions. One is the various PLL registers and one is the clock for=20
> the peripherals. And PLL is to provide a clock source for various
> peripheral clocks. So a clock controller is reasonable. I think you got=20
> it wrong.

I don't think I do. This looks exactly like the A1.
The post of that controller are still in the  archive and I am sure your
colleagues can give you the history.

You clearly have register regions providing clock, separated by
0x8000. Claiming that as one big region is bad design.

There has been several remarks about using a big syscon on V1,
unaddressed too.

CCF has everything necessary in place to handle each register region
separately, properly and pass clock around.

You can handle it as a single controller, claiming the two regions
individually but:
# 1 - handling 2 different regmaps in the controller is going to be
      bigger mess than you think
# 2 - I am far from convinced there is any reason to do so


>
> Ok, if you insist on using two clock controllers,, please provide your the
> reason and example code?
>
>> Seeing that, I have not reviewed this version further.
>> I won't until all the comments from v1 are either addressed or answer
>> Regards
>> Jerome
>> .