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

[Manivannan Sadhasivam]

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 at 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 at 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 at 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
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 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.

@krzk: Can you share your opinion?

- Mani

-- 
மணிவண்ணன் சதாசிவம்