[PATCH 1/4] dt-bindings: mtd: qcom,nandc: Add MDM9607 QPIC NAND controller
Konrad Dybcio
konrad.dybcio at oss.qualcomm.com
Tue Jun 9 02:01:18 PDT 2026
On 6/9/26 10:55 AM, Konrad Dybcio wrote:
> On 6/9/26 10:10 AM, Stephan Gerhold wrote:
>> On Tue, Jun 09, 2026 at 09:52:51AM +0200, Miquel Raynal wrote:
>>>>> On MDM9607, there is only a single controllable clock for the NAND
>>>>> controller (RPM_SMD_QPIC_CLK). The same situation also applies e.g. for
>>>>> qcom,sdx55-nand, but the corresponding device tree (qcom-sdx55.dtsi) works
>>>>> around that by assigning a dummy clock (&nand_clk_dummy) to the second
>>>>> clock ("aon") that is required by the dt-bindings. This is not really
>>>>> useful, so avoid doing that for new platforms by excluding the second "aon"
>>>>> clock entry in the dt-bindings.
>>>>
>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>
>>>
>>> What is the problem in giving twice the same clock? If this is what is
>>> done in the hardware routing, I do not see the reason for more
>>> complexity in the binding?
>>>
>>
>> I had that in my first draft for this series, but this would be wrong
>> IMO. I suspect there is no QPIC/NAND related "aon" (always-on) clock on
>> this platform at all. I'm not sure about MDM9607 in particular (maybe
>> someone from Qualcomm can confirm), but a similar platform I was looking
>> into at some point actually had *3* separate clocks for QPIC in the
>> hardware and none of them were called "aon" ...
>
> gcc_qpic_ahb_clk (50/100/133.(3) MHz sourced from PCNoC_bfdcd_clk_src)
> gcc_qpic_clk (likewise, sourced from qpic_clk_src which is sourced
> from GPLLs)
> gcc_qpic_system_clk (32 KHz)
>
> No clock containing the substring 'aon' in its name on this platform
Looking at SDX65, perhaps the 32 Khz clock is the "aon" one after all..
The NAND documentation says
CC_QPIC_SYSTEM_CLK - Always-on timeout clock (32 KHz)
Konrad
More information about the linux-mtd
mailing list