Re: [PATCH 0/4] mtd: rawnand: qcom: Add MDM9607

[Miquel Raynal <miquel.raynal@bootlin.com>]

On 06/07/2026 at 16:19:04 +02, Manivannan Sadhasivam <mani@kernel.org> wrote:

> On Mon, Jul 06, 2026 at 03:26:18PM +0200, Stephan Gerhold wrote:
>> On Mon, Jul 06, 2026 at 03:18:18PM +0200, Miquel Raynal wrote:
>> > On 06/07/2026 at 14:55:26 +02, Stephan Gerhold <stephan.gerhold@linaro.org> wrote:
>> > > On Mon, Jun 29, 2026 at 05:46:57PM +0200, Manivannan Sadhasivam wrote:
>> > >> On Mon, Jun 08, 2026 at 03:20:21PM +0200, Stephan Gerhold wrote:
>> > >> > MDM9607 has QPIC v1.5 that supports the OP_PAGE_READ_ONFI_READ command, but
>> > >> > is missing the rest of the hardware changes in QPIC v2. There is also only
>> > >> > a single clock that can be controlled using the RPM firmware. Document and
>> > >> > add the new qcom,mdm9607-nand compatible for this setup.
>> > >> > 
>> > >> > Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
>> > >> 
>> > >> You could ammend patch 1's commit message with the information I shared in the
>> > >> reply. But nevertheless:
>> > >> 
>> > >> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
>> > >> 
>> > >
>> > > Do you want me to resend the series with patch 1 commit message
>> > > adjusted? There were no other changes requested as far as I can tell.
>> > 
>> > I was mostly waiting for answers on my questions from the DT binding
>> > maintainers, but I understand they must be too loaded at the moment.
>> > 
>> > > I think the current commit message there is fine, especially if you add
>> > > the Link: tag during applying. The extra context will be there.
>> > >
>> > > If you want me to resend, I would just replace the second paragraph in
>> > > patch 1 with the following:
>> > >
>> > > ---
>> > > On MDM9607 and other recent SoCs, the QPIC hardware requires 3 clocks
>> > > (ahb, core, aon). However, the access to these clocks is restricted to
>> > > the RPM firmware that controls the shared power resources for the whole
>> > > SoC. The clocks cannot be controlled separately, there is only a single
>> > > RPM_SMD_QPIC_CLK clock that implicitly enables all of the 3 clocks.
>> > > The only exception to this are some IPQ* SoC that are not using RPM,
>> > > there the clocks are directly controlled by the kernel via the clock
>> > > controller (GCC). Require only one clock in the dt-bindings for MDM9607
>> > > to avoid having to define dummy clock entries.
>> > 
>> > I am sorry but this is still incorrect. You don't have to define 2 dummy
>> > clocks. You would have to define 3 times the same clock (and that's not
>> > a problem). I have been working on the concept of clock nexus which
>> > may solve this kind of issue in a rather elegant way but that's not
>> > ready yet.
>> > 
>> > In my opinion the binding that you want to push (a single clock) is
>> > wrong, but since I've been explaining this for several weeks already,
>> > please at least fix the commit message and I will take it as you want.
>> > 
>> 
>> Thanks for your feedback!
>> 
>> Either way works for me personally, but now we have a conflict between
>> your requested changes and the feedback from Mani, who maintains this
>> driver. :-)
>> 
>> @Mani: Would you also be fine with defining all 3 clocks in the DT
>> ("ahb", "core", "aon") and then assigning the RPM_SMD_QPIC_CLK to all of
>> them?
>> 
>
> AFAIU, devicetree binding should describe the "OS view of the
> hardware", not the

Like Geert pointed out in the below thread, I am equally surprised by
this shift but I guess SoC complexity requires adaptations.

> hardware itself. We have many predecents to this rule. One of them is the SCMI
> based resource control in Qcom Automotive SoCs, where clocks/regulators to
> individual IPs are controlled by the SCMI server and OS just sees a single SCMI
> power-domain for the IP. So we only describe the SCMI power-domain in the
> binding and not the physical clocks/regulators received by the IP in hardware.
>
> We had a recent discussion around the same topic and you can see the reply from
> Krzk here: https://lore.kernel.org/all/c83ca485-1e2e-46ba-bd15-1168aa8955d3@kernel.org
>
> So here also, the hardware receives 3 clocks physically, but OS cannot control
> all 3 of them, but just a single clock from RPMh which controls the 3 real
> clocks. Moreover, assigning the same clock to 3 different clock sources doesn't
> accurately describe the hardware either, because those 3 clocks operate on
> different frequencies

Ah, this is a point that was missing to my understanding. You actually
have three *different* clocks, and you control all of them through some
kind of firmware proxy called RPMh with a single handle. So basically
the kernel just enables one clock and the firmware enables/configures
two other clocks differently automatically. Is that it? Feels like you
almost need a power domain here.

> and if the driver queries the frequency of
> RPM_SMD_QPIC_CLK, it would just return the same frequency. This is where the
> dummy clock comes handy as it atleast provides a valid clock frequency to the
> driver. But I'm not advocating for its usage here anymore.
>
> Hence IMO, assigning the same RPM_SMD_QPIC_CLK to all 3 clocks is not the right
> approach and we should be assigning a single RPM_SMD_QPIC_CLK to
> 'core' clk.

You said using three times the same clock would be wrong because we
would get three times the same rate whereas in practice it's wrong. This
means the OS has access to these clocks somehow, so if we need to
describe what the OS sees of the hardware, as you say, defining a single
clock is incomplete.

Again, I am not totally opposed to the single clock idea if you all feel
like this is the way forward. Yet, it sounds a bit hackish.

> @krzk: Can you share your opinion?

Thanks,
Miquèl