Message-ID: <20230530160334.z6sclbmqccs6ju4y@CAB-WSD-L081021>
Date:   Tue, 30 May 2023 19:03:34 +0300
From:   Dmitry Rokosov <ddrokosov@...rdevices.ru>
To:     Conor Dooley <conor.dooley@...rochip.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        <jbrunet@...libre.com>
CC:     <krzysztof.kozlowski+dt@...aro.org>, <neil.armstrong@...aro.org>,
        <mturquette@...libre.com>, <sboyd@...nel.org>,
        <robh+dt@...nel.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 v15 5/6] dt-bindings: clock: meson: add A1 Peripherals
 clock controller bindings

Hello Conor, Martin and Jerome,

Thank you so much for the detailed information and thoughts you shared
about the important process of changing DT bindings. Please find my
comments below.

On Tue, May 30, 2023 at 10:34:07AM +0100, Conor Dooley wrote:
> Yo,
> 
> On Mon, May 29, 2023 at 10:38:33PM +0200, Martin Blumenstingl wrote:
> > On Mon, May 22, 2023 at 3:00 PM Dmitry Rokosov <ddrokosov@...rdevices.ru> wrote:
> > [...]
> > > > This IP block has at least one additional input called "sys_pll_div16".
> > > > My understanding is that the "sys_pll_div16" clock is generated by the
> > > > CPU clock controller. Support for the CPU clock controller
> > > > (dt-bindings and a driver) will be added at a later time by Dmitry.
> > > > How can we manage incrementally implementing the clock controllers?
> > > > From a hardware perspective the "sys_pll_div16" input is mandatory.
> > > > How to manage this in the .dts patches then (for example: does this
> > > > mean that Dmitry can only add the clock controller to the .dts when
> > > > all clock controller bindings have been implemented - or is there
> > > > another way)?
> > >
> > > You're absolutely right: currently, not all inputs are supported because
> > > the CPU clock controller isn't ready yet – I'm working on it at the
> > > moment.
> > >
> > > I understand your concerns about bindings and schema description, but
> > > there is an issue to be considered. I'm developing the entire clock
> > > controller A1 subsystem incrementally in three stages: peripherals and
> > > PLL, CPU, and Audio. This is because the CPU can operate at a static
> > > frequency and voltage, and the board boots normally without the CPU
> > > clock controller, thermal sensor, and OPP table. Audio is also
> > > important, but it's optional. On the other hand, without setting up the
> > > peripherals and PLL controllers, the board won't function because
> > > they're fundamental.
> > I understand your approach and I like it (without that incremental
> > approach you would probably be looking at a series with 15-20
> > patches).
> > 
> > Maybe the dt-binding maintainers have a suggestion for us here?
> > Let me try to summarize the issue in a few bullet points:
> > - There's (at least) four clock controllers on the Amlogic A1 SoC
> > - Some of these clock controllers take the outputs of another clock
> > controller as inputs
> > - In this series patch the peripheral clock controller has an input
> > called "sys_pll_div16"
> > - The clock controller which provides the "sys_pll_div16" clock is not
> > implemented yet (my understanding is that implementing it and adding
> > it to this series is not easy: it would add even more patches that
> > need to be reviewed and in general it's a tricky clock controller to
> > implement as it manages the CPU clocks)
> 
> If I am understanding correctly, this series implements the child
> controller and a parent, which is unimplemented, provides the child with
> sys_pll_div16.
> The thing I am missing is whether the child controller has some outputs
> that depend on this sys_pll_div16 input & whether those are documented
> in this series. Regardless, you should be able to add more output clocks
> without compatibility issues.
> 
> > > Right now, we're in the first stage of the plan. Unfortunately, I can't
> > > disclose the exact names and number of clock bindings for the CPU and
> > > Audio, as they're still in development and only exist in my head or
> > > draft versions.
> > >
> > > If possible, I'd prefer to provide the new bindings and connections once
> > > all the appropriate drivers are finalized.
> > Question to Conor and Krzysztof (assuming you read my summary above):
> > Is it fine that Dmitry adds additional inputs to the peripheral clock
> > controller binding in later patches?
> 
> Perhaps Krzysztof will disagree with me, but my take on it would be that
> the binding should describe the individual clock controller in its
> totality, but the driver can choose to only implement a subset of it.
> 
> If you define the binding as only needing N inputs, but then later
> expand it to having N+M inputs, the driver will have to support N & N+M
> input clocks to preserve compatibility.
> If you define it as needing N+M inputs from the beginning, but only use
> N, there is no issue with backwards compatibility when you later use
> them all.
> 

In short, I agree with Jerome's position, which he shared in the
parallel email:
https://lore.kernel.org/all/1jmt1m42m1.fsf@starbuckisacylon.baylibre.com/

Below I will try to explain my position.

Please correct me if I am mistaken, but it appears we are currently
discussing a scenario where a new kernel X+1 image version is flashed
onto a device with a device tree from kernel X-1 image version, and
whether a new driver with clock object connections can function on the
previous Device Tree version.

If I'm grasping the issue correctly, it seems that we have four
potential scenarios at play here:
1) we may have altered the relationships between internal clock objects;
2) we may have introduced new output clock connections;
3) we may have introduced new input clock connections;
4) we may have removed existing connections from the driver.

It seems that options 1 and 4 are straightforward and easy to
understand.
The 4 case is fully prohibited. We cannot remove
any object or connection from the clock driver if another consumer uses
it in the previous Device Tree versions. It is also important to note
that any internal changes within the driver do not affect the device
tree connections, as this is already clear.

The second and third cases are more complex.

For instance, let's say we are preparing a new patchset for an existing
clock driver, such as Peripherals, where we are adding an Audio clock
that is handled by an MMIO register inside Peripherals clock driver. X-1
dts does not recognize this new clock and doesn't have any connection to
any node or to any other clock driver, thereby eliminating any backwards
compatibility issues.

As for new input clock connections, such as the cpu_clock
(sys_pll_div16), these are handled by clock muxing abstraction, allowing
CCF to find the clock object by fw.name and returning -ENOENT if the
connection is missing without breaking any CCF flow. It happens in the
kernel function clk_core_fill_parent_index()
https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk.c#L424
Despite not having the connection for the new input in the old Device
Tree version, this will not break kernel boot flow and workflow, and the
new clock object just would not be utilized.

Based on the presented arguments, I fully agree with Jerome's position.
We can add new connections and objects in new driver versions, but their
removal is prohibited.

If it's alright with you, I would prefer to keep the Peripherals and PLL
clock driver and their bindings as they are, and continue with the CPU
and Audio clock controllers in a separate patch series. Would that be
feasible for you?

> > If not: how can we proceed in case we need to add them now (the
> > dt-binding example is the easy part for me as we can just make up a
> > phandle like &sys_pll_div16_clk and use that - but this can't work
> > when Dmitry tries to add the clock controller to meson-a1.dtsi)
> 
> I would be inclined to do the same thing in the dts as the example,
> and make up a fixed-frequency clock and use it to plug the hole.
> When you have bindings etc written for the clock controller providing
> that clock, the fixed-frequency clock could be swapped out for the real
> one.
> 
> > PS: Dmitry is trying to get this series into Linux 6.5. As far as I
> > remember the common clock maintainers don't take pull requests with
> > new features after -rc6 (which is in less than two weeks).
> > So time is getting a bit short and for me this is the very last
> > outstanding question. If you say that it's fine to add clocks later on
> > this will immediately get my Reviewed-by.
> 
> I *think* that what I've just said should not get in the way of such a
> timeline, as it would only involve a "small" change to the dt-binding,
> but not require additional bindings or driver.
> 
> Cheers,
> Conor.
> 

-- 
Thank you,
Dmitry

УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: Это электронное сообщение и любые документы, приложенные к нему, содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что если это сообщение не предназначено Вам, использование, копирование, распространение информации, содержащейся в настоящем сообщении, а также осуществление любых действий на основе этой информации, строго запрещено. Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и удалите это сообщение.
CONFIDENTIALITY NOTICE: This email and any files attached to it are confidential. If you are not the intended recipient you are notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

Powered by blists - more mailing lists