Qualcomm IPQ SoCs also have the IMEM(On-chip SRAM) region and used for
the various debugging purposes like storing system restart reason and
so on. As a preparatory work, first describe the IMEM region and
susbsequently add the required features.
Across all SoCs, only initial 4KB can be accessed by all the masters in
the SoC, remaining regions are access protected.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Documentation/devicetree/bindings/sram/sram.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index c451140962c86f4e8f98437a2830cb2c6a697e63..83e8c1e7070de782557fa7a36573cc48cbe28c62 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -34,6 +34,11 @@ properties:
- nvidia,tegra186-sysram
- nvidia,tegra194-sysram
- nvidia,tegra234-sysram
+ - qcom,ipq5018-imem
+ - qcom,ipq5332-imem
+ - qcom,ipq6018-imem
+ - qcom,ipq8074-imem
+ - qcom,ipq9574-imem
- qcom,kaanapali-imem
- qcom,rpm-msg-ram
- rockchip,rk3288-pmu-sram
--
2.34.1On Sat, Feb 28, 2026 at 06:38:00PM +0530, Kathiravan Thirumoorthy wrote: > Qualcomm IPQ SoCs also have the IMEM(On-chip SRAM) region and used for > the various debugging purposes like storing system restart reason and This binding does not allow restart reason. pil-reloc-info was kind of allowed, but now I think this might have been a mistake because that bindings were posted incomplete. > so on. As a preparatory work, first describe the IMEM region and Nope, sorry. Bindings must be posted complete, see writing-bindings. It makes no sense to squeeze here something knowingly incomplete and then in two weeks remove it, because it is not correct. That's exactly what happened with incomplete Kaanapali. Post complete bindings. Best regards, Krzysztof
On 3/1/26 12:27 PM, Krzysztof Kozlowski wrote: > On Sat, Feb 28, 2026 at 06:38:00PM +0530, Kathiravan Thirumoorthy wrote: >> Qualcomm IPQ SoCs also have the IMEM(On-chip SRAM) region and used for >> the various debugging purposes like storing system restart reason and > > This binding does not allow restart reason. pil-reloc-info was kind of > allowed, but now I think this might have been a mistake because that > bindings were posted incomplete. The sram.yaml binding allows any arbitrrary subnode (sort of like nvmem), so long as the name includes 'smem' Konrad
On 02/03/2026 14:52, Konrad Dybcio wrote: > On 3/1/26 12:27 PM, Krzysztof Kozlowski wrote: >> On Sat, Feb 28, 2026 at 06:38:00PM +0530, Kathiravan Thirumoorthy wrote: >>> Qualcomm IPQ SoCs also have the IMEM(On-chip SRAM) region and used for >>> the various debugging purposes like storing system restart reason and >> >> This binding does not allow restart reason. pil-reloc-info was kind of >> allowed, but now I think this might have been a mistake because that >> bindings were posted incomplete. > > The sram.yaml binding allows any arbitrrary subnode (sort of like nvmem), Not, true, look at the compatible. It requires a specific type of nodes. > so long as the name includes 'smem' Also not accurate - "sram" is not the reboot reason, which has node name called "reboot-mode". Best regards, Krzysztof
On 3/2/26 2:56 PM, Krzysztof Kozlowski wrote: > On 02/03/2026 14:52, Konrad Dybcio wrote: >> On 3/1/26 12:27 PM, Krzysztof Kozlowski wrote: >>> On Sat, Feb 28, 2026 at 06:38:00PM +0530, Kathiravan Thirumoorthy wrote: >>>> Qualcomm IPQ SoCs also have the IMEM(On-chip SRAM) region and used for >>>> the various debugging purposes like storing system restart reason and >>> >>> This binding does not allow restart reason. pil-reloc-info was kind of >>> allowed, but now I think this might have been a mistake because that >>> bindings were posted incomplete. >> >> The sram.yaml binding allows any arbitrrary subnode (sort of like nvmem), > > Not, true, look at the compatible. It requires a specific type of nodes. Right, I didn't scroll far enough! >> so long as the name includes 'smem' > > Also not accurate - "sram" is not the reboot reason, which has node name > called "reboot-mode". What I was referring to is: patternProperties: "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$": where the 'sram' (not 'smem' as I typo'd above) is obligatory Konrad
On 02/03/2026 15:10, Konrad Dybcio wrote: >> >> Also not accurate - "sram" is not the reboot reason, which has node name >> called "reboot-mode". > > What I was referring to is: > > patternProperties: > "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$": > > where the 'sram' (not 'smem' as I typo'd above) is obligatory I know and sram is not part of "reboot-mode" name. It is "reboot-mode" in existing binding and DTS, not "reboot-mode-sram". Best regards, Krzysztof
On 3/2/26 3:54 PM, Krzysztof Kozlowski wrote: > On 02/03/2026 15:10, Konrad Dybcio wrote: >>> >>> Also not accurate - "sram" is not the reboot reason, which has node name >>> called "reboot-mode". >> >> What I was referring to is: >> >> patternProperties: >> "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$": >> >> where the 'sram' (not 'smem' as I typo'd above) is obligatory > > I know and sram is not part of "reboot-mode" name. It is "reboot-mode" > in existing binding and DTS, not "reboot-mode-sram". In any case, I believe it'd be good to drop that requirement Konrad
On 02/03/2026 15:56, Konrad Dybcio wrote: > On 3/2/26 3:54 PM, Krzysztof Kozlowski wrote: >> On 02/03/2026 15:10, Konrad Dybcio wrote: >>>> >>>> Also not accurate - "sram" is not the reboot reason, which has node name >>>> called "reboot-mode". >>> >>> What I was referring to is: >>> >>> patternProperties: >>> "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$": >>> >>> where the 'sram' (not 'smem' as I typo'd above) is obligatory >> >> I know and sram is not part of "reboot-mode" name. It is "reboot-mode" >> in existing binding and DTS, not "reboot-mode-sram". > > In any case, I believe it'd be good to drop that requirement Ah, and one more thing, the syscon-reboot-mode is Linux driver with its own Linux requirements - syscon - so probably not working with sram bindings. That's another reason full binding should be posted and tested - I speculate it simply does not work. > Konrad Best regards, Krzysztof
On 3/2/26 5:33 PM, Krzysztof Kozlowski wrote: > On 02/03/2026 15:56, Konrad Dybcio wrote: >> On 3/2/26 3:54 PM, Krzysztof Kozlowski wrote: >>> On 02/03/2026 15:10, Konrad Dybcio wrote: >>>>> >>>>> Also not accurate - "sram" is not the reboot reason, which has node name >>>>> called "reboot-mode". >>>> >>>> What I was referring to is: >>>> >>>> patternProperties: >>>> "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$": >>>> >>>> where the 'sram' (not 'smem' as I typo'd above) is obligatory >>> >>> I know and sram is not part of "reboot-mode" name. It is "reboot-mode" >>> in existing binding and DTS, not "reboot-mode-sram". >> >> In any case, I believe it'd be good to drop that requirement > > Ah, and one more thing, the syscon-reboot-mode is Linux driver with its > own Linux requirements - syscon - so probably not working with sram > bindings. That's another reason full binding should be posted and tested > - I speculate it simply does not work. It won't even probe, we talked about that a long time ago on a similar occasion https://lore.kernel.org/linux-arm-msm/f6b16d1d-3730-46d1-81aa-bfaf09c20754@oss.qualcomm.com/ Konrad
On 3/3/2026 4:18 PM, Konrad Dybcio wrote:
> On 3/2/26 5:33 PM, Krzysztof Kozlowski wrote:
>> On 02/03/2026 15:56, Konrad Dybcio wrote:
>>> On 3/2/26 3:54 PM, Krzysztof Kozlowski wrote:
>>>> On 02/03/2026 15:10, Konrad Dybcio wrote:
>>>>>> Also not accurate - "sram" is not the reboot reason, which has node name
>>>>>> called "reboot-mode".
>>>>> What I was referring to is:
>>>>>
>>>>> patternProperties:
>>>>> "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$":
>>>>>
>>>>> where the 'sram' (not 'smem' as I typo'd above) is obligatory
>>>> I know and sram is not part of "reboot-mode" name. It is "reboot-mode"
>>>> in existing binding and DTS, not "reboot-mode-sram".
>>> In any case, I believe it'd be good to drop that requirement
>> Ah, and one more thing, the syscon-reboot-mode is Linux driver with its
>> own Linux requirements - syscon - so probably not working with sram
>> bindings. That's another reason full binding should be posted and tested
>> - I speculate it simply does not work.
> It won't even probe, we talked about that a long time ago on a similar
> occasion
>
> https://lore.kernel.org/linux-arm-msm/f6b16d1d-3730-46d1-81aa-bfaf09c20754@oss.qualcomm.com/
Sorry, TBH, I'm confused here...
I agree that, DT node should be as simple as below for now until the
child node is added.
sram@8600000 {
compatible = "qcom,ipq5332-imem", "mmio-sram";
reg = <0x08600000 0x14000>;
no-memory-wc;
};
When I add the child node, it will eventually become like
sram@8600000 {
compatible = "qcom,ipq5332-imem", "mmio-sram";
reg = <0 0x08600000 0 0x1c000>;
ranges = <0 0 0x08600000 0x1c000>;
no-memory-wc;
#address-cells = <1>;
#size-cells = <1>;
restart_reason: restartreason-sram@7b0 {
reg = <0x7b0 0x4>;
};
};
which seems to be matching with the binding requirements.
and the consumer can reference to this node like
sram = <&restart_reason>;
I'm not following what's being suggested here. Can you please help me to
understand further on this.
>
> Konrad
On 04/03/2026 12:16, Kathiravan Thirumoorthy wrote:
>
> On 3/3/2026 4:18 PM, Konrad Dybcio wrote:
>> On 3/2/26 5:33 PM, Krzysztof Kozlowski wrote:
>>> On 02/03/2026 15:56, Konrad Dybcio wrote:
>>>> On 3/2/26 3:54 PM, Krzysztof Kozlowski wrote:
>>>>> On 02/03/2026 15:10, Konrad Dybcio wrote:
>>>>>>> Also not accurate - "sram" is not the reboot reason, which has node name
>>>>>>> called "reboot-mode".
>>>>>> What I was referring to is:
>>>>>>
>>>>>> patternProperties:
>>>>>> "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$":
>>>>>>
>>>>>> where the 'sram' (not 'smem' as I typo'd above) is obligatory
>>>>> I know and sram is not part of "reboot-mode" name. It is "reboot-mode"
>>>>> in existing binding and DTS, not "reboot-mode-sram".
>>>> In any case, I believe it'd be good to drop that requirement
>>> Ah, and one more thing, the syscon-reboot-mode is Linux driver with its
>>> own Linux requirements - syscon - so probably not working with sram
>>> bindings. That's another reason full binding should be posted and tested
>>> - I speculate it simply does not work.
>> It won't even probe, we talked about that a long time ago on a similar
>> occasion
>>
>> https://lore.kernel.org/linux-arm-msm/f6b16d1d-3730-46d1-81aa-bfaf09c20754@oss.qualcomm.com/
>
>
> Sorry, TBH, I'm confused here...
>
> I agree that, DT node should be as simple as below for now until the
> child node is added.
>
> sram@8600000 {
> compatible = "qcom,ipq5332-imem", "mmio-sram";
> reg = <0x08600000 0x14000>;
> no-memory-wc;
> };
>
> When I add the child node, it will eventually become like
>
> sram@8600000 {
> compatible = "qcom,ipq5332-imem", "mmio-sram";
> reg = <0 0x08600000 0 0x1c000>;
> ranges = <0 0 0x08600000 0x1c000>;
>
> no-memory-wc;
>
> #address-cells = <1>;
> #size-cells = <1>;
>
> restart_reason: restartreason-sram@7b0 {
> reg = <0x7b0 0x4>;
> };
> };
>
> which seems to be matching with the binding requirements.
>
> and the consumer can reference to this node like
>
> sram = <&restart_reason>;
>
> I'm not following what's being suggested here. Can you please help me to
> understand further on this.
I already asked you what to do.
"Nope, sorry. Bindings must be posted complete, see writing-bindings."
So post it after testing. We suggest that it simply does not work, but
you can always prove us wrong.
Best regards,
Krzysztof
On 3/4/26 12:29 PM, Krzysztof Kozlowski wrote:
> On 04/03/2026 12:16, Kathiravan Thirumoorthy wrote:
>>
>> On 3/3/2026 4:18 PM, Konrad Dybcio wrote:
>>> On 3/2/26 5:33 PM, Krzysztof Kozlowski wrote:
>>>> On 02/03/2026 15:56, Konrad Dybcio wrote:
>>>>> On 3/2/26 3:54 PM, Krzysztof Kozlowski wrote:
>>>>>> On 02/03/2026 15:10, Konrad Dybcio wrote:
>>>>>>>> Also not accurate - "sram" is not the reboot reason, which has node name
>>>>>>>> called "reboot-mode".
>>>>>>> What I was referring to is:
>>>>>>>
>>>>>>> patternProperties:
>>>>>>> "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$":
>>>>>>>
>>>>>>> where the 'sram' (not 'smem' as I typo'd above) is obligatory
>>>>>> I know and sram is not part of "reboot-mode" name. It is "reboot-mode"
>>>>>> in existing binding and DTS, not "reboot-mode-sram".
>>>>> In any case, I believe it'd be good to drop that requirement
>>>> Ah, and one more thing, the syscon-reboot-mode is Linux driver with its
>>>> own Linux requirements - syscon - so probably not working with sram
>>>> bindings. That's another reason full binding should be posted and tested
>>>> - I speculate it simply does not work.
>>> It won't even probe, we talked about that a long time ago on a similar
>>> occasion
>>>
>>> https://lore.kernel.org/linux-arm-msm/f6b16d1d-3730-46d1-81aa-bfaf09c20754@oss.qualcomm.com/
>>
>>
>> Sorry, TBH, I'm confused here...
>>
>> I agree that, DT node should be as simple as below for now until the
>> child node is added.
>>
>> sram@8600000 {
>> compatible = "qcom,ipq5332-imem", "mmio-sram";
>> reg = <0x08600000 0x14000>;
>> no-memory-wc;
>> };
>>
>> When I add the child node, it will eventually become like
>>
>> sram@8600000 {
>> compatible = "qcom,ipq5332-imem", "mmio-sram";
>> reg = <0 0x08600000 0 0x1c000>;
>> ranges = <0 0 0x08600000 0x1c000>;
>>
>> no-memory-wc;
>>
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> restart_reason: restartreason-sram@7b0 {
>> reg = <0x7b0 0x4>;
>> };
>> };
>>
>> which seems to be matching with the binding requirements.
>>
>> and the consumer can reference to this node like
>>
>> sram = <&restart_reason>;
>>
>> I'm not following what's being suggested here. Can you please help me to
>> understand further on this.
>
> I already asked you what to do.
>
> "Nope, sorry. Bindings must be posted complete, see writing-bindings."
>
> So post it after testing. We suggest that it simply does not work, but
> you can always prove us wrong.
Are you by chance confusing 'syscon-reboot-mode' (write TO imem to set the
restart reason) with this node (read FROM imem to present a restart reason
via wdog)?
Konrad
On 04/03/2026 12:38, Konrad Dybcio wrote:
> On 3/4/26 12:29 PM, Krzysztof Kozlowski wrote:
>> On 04/03/2026 12:16, Kathiravan Thirumoorthy wrote:
>>>
>>> On 3/3/2026 4:18 PM, Konrad Dybcio wrote:
>>>> On 3/2/26 5:33 PM, Krzysztof Kozlowski wrote:
>>>>> On 02/03/2026 15:56, Konrad Dybcio wrote:
>>>>>> On 3/2/26 3:54 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 02/03/2026 15:10, Konrad Dybcio wrote:
>>>>>>>>> Also not accurate - "sram" is not the reboot reason, which has node name
>>>>>>>>> called "reboot-mode".
>>>>>>>> What I was referring to is:
>>>>>>>>
>>>>>>>> patternProperties:
>>>>>>>> "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$":
>>>>>>>>
>>>>>>>> where the 'sram' (not 'smem' as I typo'd above) is obligatory
>>>>>>> I know and sram is not part of "reboot-mode" name. It is "reboot-mode"
>>>>>>> in existing binding and DTS, not "reboot-mode-sram".
>>>>>> In any case, I believe it'd be good to drop that requirement
>>>>> Ah, and one more thing, the syscon-reboot-mode is Linux driver with its
>>>>> own Linux requirements - syscon - so probably not working with sram
>>>>> bindings. That's another reason full binding should be posted and tested
>>>>> - I speculate it simply does not work.
>>>> It won't even probe, we talked about that a long time ago on a similar
>>>> occasion
>>>>
>>>> https://lore.kernel.org/linux-arm-msm/f6b16d1d-3730-46d1-81aa-bfaf09c20754@oss.qualcomm.com/
>>>
>>>
>>> Sorry, TBH, I'm confused here...
>>>
>>> I agree that, DT node should be as simple as below for now until the
>>> child node is added.
>>>
>>> sram@8600000 {
>>> compatible = "qcom,ipq5332-imem", "mmio-sram";
>>> reg = <0x08600000 0x14000>;
>>> no-memory-wc;
>>> };
>>>
>>> When I add the child node, it will eventually become like
>>>
>>> sram@8600000 {
>>> compatible = "qcom,ipq5332-imem", "mmio-sram";
>>> reg = <0 0x08600000 0 0x1c000>;
>>> ranges = <0 0 0x08600000 0x1c000>;
>>>
>>> no-memory-wc;
>>>
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>>
>>> restart_reason: restartreason-sram@7b0 {
>>> reg = <0x7b0 0x4>;
>>> };
>>> };
>>>
>>> which seems to be matching with the binding requirements.
>>>
>>> and the consumer can reference to this node like
>>>
>>> sram = <&restart_reason>;
>>>
>>> I'm not following what's being suggested here. Can you please help me to
>>> understand further on this.
>>
>> I already asked you what to do.
>>
>> "Nope, sorry. Bindings must be posted complete, see writing-bindings."
>>
>> So post it after testing. We suggest that it simply does not work, but
>> you can always prove us wrong.
>
> Are you by chance confusing 'syscon-reboot-mode' (write TO imem to set the
> restart reason) with this node (read FROM imem to present a restart reason
> via wdog)?
Previously IMEM was in with reboot-mode, so that is why I am asking.
Commit msg mentions only "restart reason" but also states it is not
adding complete picture, so I am done guessing here.
Best regards,
Krzysztof
© 2016 - 2026 Red Hat, Inc.