[PATCH v2 0/4] dt-bindings: soc: qcom: Add soc related bindings for Kaanapali and Glymur

[PATCH v2 0/4] dt-bindings: soc: qcom: Add soc related bindings for Kaanapali and Glymur

[Jingyi Wang]

Add soc related bindings for Kaanapali Platform including aoss_qmp,
imem and scm. And add aoss_qmp for Glymur.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
Changes in v2:
- Fix capital letter in subject and simplify commit message - Eugen Hristev
- pick aoss_qmp change from https://lore.kernel.org/linux-arm-msm/20250924183726.509202-1-sibi.sankar@oss.qualcomm.com/T/#m4bbee2db112a471cdca7aa63477b7147691e6852 and rebase
- Link to v1: https://lore.kernel.org/r/20250924-knp-soc-binding-v1-0-93a072e174f9@oss.qualcomm.com

---
Jingyi Wang (3):
      dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible
      dt-bindings: soc: qcom,aoss-qmp: Document the Kaanapali AOSS channel
      dt-bindings: firmware: qcom,scm: Document SCM on Kaanapali SOC

Sibi Sankar (1):
      dt-bindings: soc: qcom,aoss-qmp: Document the Glymur AOSS side channel

 Documentation/devicetree/bindings/firmware/qcom,scm.yaml      | 2 ++
 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml | 2 ++
 Documentation/devicetree/bindings/sram/qcom,imem.yaml         | 1 +
 3 files changed, 5 insertions(+)
---
base-commit: aaa9c3550b60d6259d6ea8b1175ade8d1242444e
change-id: 20251022-knp-soc-binding-bb9110682752

Best regards,
-- 
Jingyi Wang <jingyi.wang@oss.qualcomm.com>

[PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Jingyi Wang]

Document qcom,kaanapali-imem compatible.

Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index 6a627c57ae2f..1e29a8ff287f 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -19,6 +19,7 @@ properties:
       - enum:
           - qcom,apq8064-imem
           - qcom,ipq5424-imem
+          - qcom,kaanapali-imem
           - qcom,msm8226-imem
           - qcom,msm8974-imem
           - qcom,msm8976-imem

-- 
2.25.1

[PATCH v2 2/4] dt-bindings: soc: qcom,aoss-qmp: Document the Kaanapali AOSS channel

[Jingyi Wang]

Document the Always-On Subsystem side channel on the Qualcomm Kaanapali
platform for communication with client found on the SoC such as
remoteprocs.

Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
index 851a1260f8dc..57aa819939f0 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
@@ -25,6 +25,7 @@ properties:
   compatible:
     items:
       - enum:
+          - qcom,kaanapali-aoss-qmp
           - qcom,milos-aoss-qmp
           - qcom,qcs615-aoss-qmp
           - qcom,qcs8300-aoss-qmp

-- 
2.25.1

[PATCH v2 3/4] dt-bindings: firmware: qcom,scm: Document SCM on Kaanapali SOC

[Jingyi Wang]

Document scm compatible for the Qualcomm Kaanapali SoC.

Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index ef97faac7e47..340b754e6322 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -31,6 +31,7 @@ properties:
           - qcom,scm-ipq806x
           - qcom,scm-ipq8074
           - qcom,scm-ipq9574
+          - qcom,scm-kaanapali
           - qcom,scm-mdm9607
           - qcom,scm-milos
           - qcom,scm-msm8226
@@ -202,6 +203,7 @@ allOf:
           compatible:
             contains:
               enum:
+                - qcom,scm-kaanapali
                 - qcom,scm-milos
                 - qcom,scm-sm8450
                 - qcom,scm-sm8550

-- 
2.25.1

[PATCH v2 4/4] dt-bindings: soc: qcom,aoss-qmp: Document the Glymur AOSS side channel

[Jingyi Wang]

From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>

Document the Always-on Subsystem side channel on the Glymur SoC.

Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
index 57aa819939f0..c5c1bac2db01 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml
@@ -25,6 +25,7 @@ properties:
   compatible:
     items:
       - enum:
+          - qcom,glymur-aoss-qmp
           - qcom,kaanapali-aoss-qmp
           - qcom,milos-aoss-qmp
           - qcom,qcs615-aoss-qmp

-- 
2.25.1

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Dmitry Baryshkov]

On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
> Document qcom,kaanapali-imem compatible.
> 
> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> index 6a627c57ae2f..1e29a8ff287f 100644
> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> @@ -19,6 +19,7 @@ properties:
>        - enum:
>            - qcom,apq8064-imem
>            - qcom,ipq5424-imem
> +          - qcom,kaanapali-imem

Can you use mmio-sram instead?

>            - qcom,msm8226-imem
>            - qcom,msm8974-imem
>            - qcom,msm8976-imem
> 
> -- 
> 2.25.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2 3/4] dt-bindings: firmware: qcom,scm: Document SCM on Kaanapali SOC

[Dmitry Baryshkov]

On Wed, Oct 22, 2025 at 12:28:43AM -0700, Jingyi Wang wrote:
> Document scm compatible for the Qualcomm Kaanapali SoC.

SCM, not scm

> 
> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Jingyi Wang]

On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
> On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
>> Document qcom,kaanapali-imem compatible.
>>
>> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> ---
>>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> index 6a627c57ae2f..1e29a8ff287f 100644
>> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> @@ -19,6 +19,7 @@ properties:
>>        - enum:
>>            - qcom,apq8064-imem
>>            - qcom,ipq5424-imem
>> +          - qcom,kaanapali-imem
> 
> Can you use mmio-sram instead?
> 

Here is the node: 

		sram@14680000 {
			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
			reg = <0x0 0x14680000 0x0 0x1000>;
			ranges = <0 0 0x14680000 0x1000>;

			#address-cells = <1>;
			#size-cells = <1>;

			pil-reloc@94c {
				compatible = "qcom,pil-reloc-info";
				reg = <0x94c 0xc8>;
			};
		};

other qualcomm are also using imem, could you please give more details on why
we should use mmio-sram here?

Thanks,
Jingyi

>>            - qcom,msm8226-imem
>>            - qcom,msm8974-imem
>>            - qcom,msm8976-imem
>>
>> -- 
>> 2.25.1
>>
> 

Re: [PATCH v2 3/4] dt-bindings: firmware: qcom,scm: Document SCM on Kaanapali SOC

[Jingyi Wang]

On 10/22/2025 4:50 PM, Dmitry Baryshkov wrote:
> On Wed, Oct 22, 2025 at 12:28:43AM -0700, Jingyi Wang wrote:
>> Document scm compatible for the Qualcomm Kaanapali SoC.
> 
> SCM, not scm
> 
Will fix

Thanks,
Jingyi

>>
>> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> ---
>>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>>  1 file changed, 2 insertions(+)
>>
> 

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Dmitry Baryshkov]

On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
> 
> 
> On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
> > On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
> >> Document qcom,kaanapali-imem compatible.
> >>
> >> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> >> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> >> ---
> >>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> >> index 6a627c57ae2f..1e29a8ff287f 100644
> >> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> >> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> >> @@ -19,6 +19,7 @@ properties:
> >>        - enum:
> >>            - qcom,apq8064-imem
> >>            - qcom,ipq5424-imem
> >> +          - qcom,kaanapali-imem
> > 
> > Can you use mmio-sram instead?
> > 
> 
> Here is the node: 
> 
> 		sram@14680000 {
> 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
> 			reg = <0x0 0x14680000 0x0 0x1000>;
> 			ranges = <0 0 0x14680000 0x1000>;
> 
> 			#address-cells = <1>;
> 			#size-cells = <1>;
> 
> 			pil-reloc@94c {
> 				compatible = "qcom,pil-reloc-info";
> 				reg = <0x94c 0xc8>;
> 			};
> 		};
> 
> other qualcomm are also using imem, could you please give more details on why
> we should use mmio-sram here?

https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/

> 
> Thanks,
> Jingyi
> 
> >>            - qcom,msm8226-imem
> >>            - qcom,msm8974-imem
> >>            - qcom,msm8976-imem
> >>
> >> -- 
> >> 2.25.1
> >>
> > 
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Bjorn Andersson]

On Wed, Oct 22, 2025 at 12:34:58PM +0300, Dmitry Baryshkov wrote:
> On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
> > 
> > 
> > On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
> > > On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
> > >> Document qcom,kaanapali-imem compatible.
> > >>
> > >> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> > >> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> > >> ---
> > >>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
> > >>  1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > >> index 6a627c57ae2f..1e29a8ff287f 100644
> > >> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > >> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > >> @@ -19,6 +19,7 @@ properties:
> > >>        - enum:
> > >>            - qcom,apq8064-imem
> > >>            - qcom,ipq5424-imem
> > >> +          - qcom,kaanapali-imem
> > > 
> > > Can you use mmio-sram instead?
> > > 
> > 
> > Here is the node: 
> > 
> > 		sram@14680000 {
> > 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
> > 			reg = <0x0 0x14680000 0x0 0x1000>;
> > 			ranges = <0 0 0x14680000 0x1000>;
> > 
> > 			#address-cells = <1>;
> > 			#size-cells = <1>;
> > 
> > 			pil-reloc@94c {
> > 				compatible = "qcom,pil-reloc-info";
> > 				reg = <0x94c 0xc8>;
> > 			};
> > 		};
> > 
> > other qualcomm are also using imem, could you please give more details on why
> > we should use mmio-sram here?
> 
> https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/
> 

I considered exactly this when I wrote the binding back then...

But the binding defines mmio-sram as "Simple IO memory regions to be
managed by the genalloc API." and the Linux sram driver follows that and
registers a gen_pool across the sram memory region.

I believe IMEM is SRAM (it's at least not registers), but its memory
layout is fixed, so it's not a pool in any form.


What Krzysztof says makes sense, but rather than just throwing a yak at
Jingyi, it would be nice if you provided some guidance on how you would
like to see this turn out.

Regards,
Bjorn

> > 
> > Thanks,
> > Jingyi
> > 
> > >>            - qcom,msm8226-imem
> > >>            - qcom,msm8974-imem
> > >>            - qcom,msm8976-imem
> > >>
> > >> -- 
> > >> 2.25.1
> > >>
> > > 
> > 
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Dmitry Baryshkov]

On Wed, Oct 22, 2025 at 05:42:58PM -0500, Bjorn Andersson wrote:
> On Wed, Oct 22, 2025 at 12:34:58PM +0300, Dmitry Baryshkov wrote:
> > On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
> > > 
> > > 
> > > On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
> > > > On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
> > > >> Document qcom,kaanapali-imem compatible.
> > > >>
> > > >> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> > > >> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> > > >> ---
> > > >>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
> > > >>  1 file changed, 1 insertion(+)
> > > >>
> > > >> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > > >> index 6a627c57ae2f..1e29a8ff287f 100644
> > > >> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > > >> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > > >> @@ -19,6 +19,7 @@ properties:
> > > >>        - enum:
> > > >>            - qcom,apq8064-imem
> > > >>            - qcom,ipq5424-imem
> > > >> +          - qcom,kaanapali-imem
> > > > 
> > > > Can you use mmio-sram instead?
> > > > 
> > > 
> > > Here is the node: 
> > > 
> > > 		sram@14680000 {
> > > 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
> > > 			reg = <0x0 0x14680000 0x0 0x1000>;
> > > 			ranges = <0 0 0x14680000 0x1000>;
> > > 
> > > 			#address-cells = <1>;
> > > 			#size-cells = <1>;
> > > 
> > > 			pil-reloc@94c {
> > > 				compatible = "qcom,pil-reloc-info";
> > > 				reg = <0x94c 0xc8>;
> > > 			};
> > > 		};
> > > 
> > > other qualcomm are also using imem, could you please give more details on why
> > > we should use mmio-sram here?
> > 
> > https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/
> > 
> 
> I considered exactly this when I wrote the binding back then...
> 
> But the binding defines mmio-sram as "Simple IO memory regions to be
> managed by the genalloc API." and the Linux sram driver follows that and
> registers a gen_pool across the sram memory region.
> 
> I believe IMEM is SRAM (it's at least not registers), but its memory
> layout is fixed, so it's not a pool in any form.
> 
> 
> What Krzysztof says makes sense, but rather than just throwing a yak at
> Jingyi, it would be nice if you provided some guidance on how you would
> like to see this turn out.

I tested, pretty same approach seems to work:

	sram@14680000 {
		compatible = "mmio-sram";
		reg = <0x0 0x14680000 0x0 0x1000>;
		ranges = <0 0 0x14680000 0x1000>;

		#address-cells = <1>;
		#size-cells = <1>;

		pil-reloc-sram@94c {
			compatible = "qcom,pil-reloc-info";
			reg = <0x94c 0xc8>;
		};
	};


-- 
With best wishes
Dmitry

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Jingyi Wang]

On 10/23/2025 8:06 AM, Dmitry Baryshkov wrote:
> On Wed, Oct 22, 2025 at 05:42:58PM -0500, Bjorn Andersson wrote:
>> On Wed, Oct 22, 2025 at 12:34:58PM +0300, Dmitry Baryshkov wrote:
>>> On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
>>>>
>>>>
>>>> On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
>>>>>> Document qcom,kaanapali-imem compatible.
>>>>>>
>>>>>> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
>>>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>> index 6a627c57ae2f..1e29a8ff287f 100644
>>>>>> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>> @@ -19,6 +19,7 @@ properties:
>>>>>>        - enum:
>>>>>>            - qcom,apq8064-imem
>>>>>>            - qcom,ipq5424-imem
>>>>>> +          - qcom,kaanapali-imem
>>>>>
>>>>> Can you use mmio-sram instead?
>>>>>
>>>>
>>>> Here is the node: 
>>>>
>>>> 		sram@14680000 {
>>>> 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
>>>> 			reg = <0x0 0x14680000 0x0 0x1000>;
>>>> 			ranges = <0 0 0x14680000 0x1000>;
>>>>
>>>> 			#address-cells = <1>;
>>>> 			#size-cells = <1>;
>>>>
>>>> 			pil-reloc@94c {
>>>> 				compatible = "qcom,pil-reloc-info";
>>>> 				reg = <0x94c 0xc8>;
>>>> 			};
>>>> 		};
>>>>
>>>> other qualcomm are also using imem, could you please give more details on why
>>>> we should use mmio-sram here?
>>>
>>> https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/
>>>
>>
>> I considered exactly this when I wrote the binding back then...
>>
>> But the binding defines mmio-sram as "Simple IO memory regions to be
>> managed by the genalloc API." and the Linux sram driver follows that and
>> registers a gen_pool across the sram memory region.
>>
>> I believe IMEM is SRAM (it's at least not registers), but its memory
>> layout is fixed, so it's not a pool in any form.
>>
>>
>> What Krzysztof says makes sense, but rather than just throwing a yak at
>> Jingyi, it would be nice if you provided some guidance on how you would
>> like to see this turn out.
> 
> I tested, pretty same approach seems to work:
> 
> 	sram@14680000 {
> 		compatible = "mmio-sram";
> 		reg = <0x0 0x14680000 0x0 0x1000>;
> 		ranges = <0 0 0x14680000 0x1000>;
> 
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 
> 		pil-reloc-sram@94c {
> 			compatible = "qcom,pil-reloc-info";
> 			reg = <0x94c 0xc8>;
> 		};
> 	};
> 
> 

Thanks for clarify, I will drop this patch and make the change in dt.
Meanwhile change in sram.yaml should also be required.

Thanks,
Jingyi

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Konrad Dybcio]

On 10/23/25 12:42 AM, Bjorn Andersson wrote:
> On Wed, Oct 22, 2025 at 12:34:58PM +0300, Dmitry Baryshkov wrote:
>> On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
>>>
>>>
>>> On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
>>>> On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
>>>>> Document qcom,kaanapali-imem compatible.
>>>>>
>>>>> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
>>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
>>>>>  1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>> index 6a627c57ae2f..1e29a8ff287f 100644
>>>>> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>> @@ -19,6 +19,7 @@ properties:
>>>>>        - enum:
>>>>>            - qcom,apq8064-imem
>>>>>            - qcom,ipq5424-imem
>>>>> +          - qcom,kaanapali-imem
>>>>
>>>> Can you use mmio-sram instead?
>>>>
>>>
>>> Here is the node: 
>>>
>>> 		sram@14680000 {
>>> 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
>>> 			reg = <0x0 0x14680000 0x0 0x1000>;
>>> 			ranges = <0 0 0x14680000 0x1000>;
>>>
>>> 			#address-cells = <1>;
>>> 			#size-cells = <1>;
>>>
>>> 			pil-reloc@94c {
>>> 				compatible = "qcom,pil-reloc-info";
>>> 				reg = <0x94c 0xc8>;
>>> 			};
>>> 		};
>>>
>>> other qualcomm are also using imem, could you please give more details on why
>>> we should use mmio-sram here?
>>
>> https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/
>>
> 
> I considered exactly this when I wrote the binding back then...
> 
> But the binding defines mmio-sram as "Simple IO memory regions to be
> managed by the genalloc API." and the Linux sram driver follows that and
> registers a gen_pool across the sram memory region.
> 
> I believe IMEM is SRAM (it's at least not registers), but its memory
> layout is fixed, so it's not a pool in any form.

I tried to get answers for this internally, but no dice.. It's fair
to assume that's what it is though, I think..

We can probably change the compatible and restart my old IPA-IMEM
series which touched upon that while at it:

code+bindings:
https://lore.kernel.org/lkml/20250527-topic-ipa_imem-v2-0-6d1aad91b841@oss.qualcomm.com/

(incl. discussion with Krzysztof about mmio-sram)

dt:
https://lore.kernel.org/linux-arm-msm/20250523-topic-ipa_mem_dts-v1-0-f7aa94fac1ab@oss.qualcomm.com/

I seem to even have the relevant bindings patches on my computer:

https://github.com/quic-kdybcio/linux/commits/topic/imem_sram/

Konrad

Re: [PATCH v2 2/4] dt-bindings: soc: qcom,aoss-qmp: Document the Kaanapali AOSS channel

[Rob Herring (Arm)]

On Wed, 22 Oct 2025 00:28:42 -0700, Jingyi Wang wrote:
> Document the Always-On Subsystem side channel on the Qualcomm Kaanapali
> platform for communication with client found on the SoC such as
> remoteprocs.
> 
> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v2 3/4] dt-bindings: firmware: qcom,scm: Document SCM on Kaanapali SOC

[Rob Herring (Arm)]

On Wed, 22 Oct 2025 00:28:43 -0700, Jingyi Wang wrote:
> Document scm compatible for the Qualcomm Kaanapali SoC.
> 
> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v2 4/4] dt-bindings: soc: qcom,aoss-qmp: Document the Glymur AOSS side channel

[Rob Herring (Arm)]

On Wed, 22 Oct 2025 00:28:44 -0700, Jingyi Wang wrote:
> From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> 
> Document the Always-on Subsystem side channel on the Glymur SoC.
> 
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Bjorn Andersson]

On Thu, Oct 23, 2025 at 03:06:00AM +0300, Dmitry Baryshkov wrote:
> On Wed, Oct 22, 2025 at 05:42:58PM -0500, Bjorn Andersson wrote:
> > On Wed, Oct 22, 2025 at 12:34:58PM +0300, Dmitry Baryshkov wrote:
> > > On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
> > > > 
> > > > 
> > > > On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
> > > > > On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
> > > > >> Document qcom,kaanapali-imem compatible.
> > > > >>
> > > > >> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> > > > >> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> > > > >> ---
> > > > >>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
> > > > >>  1 file changed, 1 insertion(+)
> > > > >>
> > > > >> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > > > >> index 6a627c57ae2f..1e29a8ff287f 100644
> > > > >> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > > > >> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> > > > >> @@ -19,6 +19,7 @@ properties:
> > > > >>        - enum:
> > > > >>            - qcom,apq8064-imem
> > > > >>            - qcom,ipq5424-imem
> > > > >> +          - qcom,kaanapali-imem
> > > > > 
> > > > > Can you use mmio-sram instead?
> > > > > 
> > > > 
> > > > Here is the node: 
> > > > 
> > > > 		sram@14680000 {
> > > > 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
> > > > 			reg = <0x0 0x14680000 0x0 0x1000>;
> > > > 			ranges = <0 0 0x14680000 0x1000>;
> > > > 
> > > > 			#address-cells = <1>;
> > > > 			#size-cells = <1>;
> > > > 
> > > > 			pil-reloc@94c {
> > > > 				compatible = "qcom,pil-reloc-info";
> > > > 				reg = <0x94c 0xc8>;
> > > > 			};
> > > > 		};
> > > > 
> > > > other qualcomm are also using imem, could you please give more details on why
> > > > we should use mmio-sram here?
> > > 
> > > https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/
> > > 
> > 
> > I considered exactly this when I wrote the binding back then...
> > 
> > But the binding defines mmio-sram as "Simple IO memory regions to be
> > managed by the genalloc API." and the Linux sram driver follows that and
> > registers a gen_pool across the sram memory region.
> > 
> > I believe IMEM is SRAM (it's at least not registers), but its memory
> > layout is fixed, so it's not a pool in any form.
> > 
> > 
> > What Krzysztof says makes sense, but rather than just throwing a yak at
> > Jingyi, it would be nice if you provided some guidance on how you would
> > like to see this turn out.
> 
> I tested, pretty same approach seems to work:
> 

Now you're shaving at random ;)

> 	sram@14680000 {
> 		compatible = "mmio-sram";

You can put "pil-reloc-sram" wherever, because it will perform a
of_find_compatible_node() to dig up some node with the compatible
"qcom,pil-reloc-info" .

In other words, this line created a genpool for something that really
isn't a genpool, but luckily that didn't have any side effects.


There are however other users of IMEM, such as the "reboot-mode", which
relies on the "sram" device probing child devices, and is implemented by
"syscon-reboot-mode".

Perhaps the solution is to not support any new users of that?


But no matter what, the definition "Simple IO memory regions to be
managed by the genalloc API" will never be true for IMEM.

And as this isn't a syscon, simple-mfd, or mmio-sram...how about making
the fallback "qcom,imem" (in this same binding) and omitting any
implementation until we need one)?

Regards,
Bjorn

> 		reg = <0x0 0x14680000 0x0 0x1000>;
> 		ranges = <0 0 0x14680000 0x1000>;
> 
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 
> 		pil-reloc-sram@94c {
> 			compatible = "qcom,pil-reloc-info";
> 			reg = <0x94c 0xc8>;
> 		};
> 	};
> 
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Aiqun(Maria) Yu]

On 10/28/2025 2:44 AM, Bjorn Andersson wrote:
> On Thu, Oct 23, 2025 at 03:06:00AM +0300, Dmitry Baryshkov wrote:
>> On Wed, Oct 22, 2025 at 05:42:58PM -0500, Bjorn Andersson wrote:
>>> On Wed, Oct 22, 2025 at 12:34:58PM +0300, Dmitry Baryshkov wrote:
>>>> On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
>>>>>
>>>>>
>>>>> On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
>>>>>> On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
>>>>>>> Document qcom,kaanapali-imem compatible.
>>>>>>>
>>>>>>> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
>>>>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>>>>>> ---
>>>>>>>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
>>>>>>>  1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>>> index 6a627c57ae2f..1e29a8ff287f 100644
>>>>>>> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>>> @@ -19,6 +19,7 @@ properties:
>>>>>>>        - enum:
>>>>>>>            - qcom,apq8064-imem
>>>>>>>            - qcom,ipq5424-imem
>>>>>>> +          - qcom,kaanapali-imem
>>>>>>
>>>>>> Can you use mmio-sram instead?
>>>>>>
>>>>>
>>>>> Here is the node: 
>>>>>
>>>>> 		sram@14680000 {
>>>>> 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
>>>>> 			reg = <0x0 0x14680000 0x0 0x1000>;
>>>>> 			ranges = <0 0 0x14680000 0x1000>;
>>>>>
>>>>> 			#address-cells = <1>;
>>>>> 			#size-cells = <1>;
>>>>>
>>>>> 			pil-reloc@94c {
>>>>> 				compatible = "qcom,pil-reloc-info";
>>>>> 				reg = <0x94c 0xc8>;
>>>>> 			};
>>>>> 		};
>>>>>
>>>>> other qualcomm are also using imem, could you please give more details on why
>>>>> we should use mmio-sram here?
>>>>
>>>> https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/
>>>>
>>>
>>> I considered exactly this when I wrote the binding back then...
>>>
>>> But the binding defines mmio-sram as "Simple IO memory regions to be
>>> managed by the genalloc API." and the Linux sram driver follows that and
>>> registers a gen_pool across the sram memory region.
>>>
>>> I believe IMEM is SRAM (it's at least not registers), but its memory
>>> layout is fixed, so it's not a pool in any form.
>>>
>>>
>>> What Krzysztof says makes sense, but rather than just throwing a yak at
>>> Jingyi, it would be nice if you provided some guidance on how you would
>>> like to see this turn out.
>>
>> I tested, pretty same approach seems to work:
>>
> 
> Now you're shaving at random ;)
> 
>> 	sram@14680000 {
>> 		compatible = "mmio-sram";
> 
> You can put "pil-reloc-sram" wherever, because it will perform a
> of_find_compatible_node() to dig up some node with the compatible
> "qcom,pil-reloc-info" .
> 
> In other words, this line created a genpool for something that really
> isn't a genpool, but luckily that didn't have any side effects.
> 
> 
> There are however other users of IMEM, such as the "reboot-mode", which
> relies on the "sram" device probing child devices, and is implemented by
> "syscon-reboot-mode".
> 
> Perhaps the solution is to not support any new users of that?
> 
> 
> But no matter what, the definition "Simple IO memory regions to be
> managed by the genalloc API" will never be true for IMEM.
> 
> And as this isn't a syscon, simple-mfd, or mmio-sram...how about making
> the fallback "qcom,imem" (in this same binding) and omitting any
> implementation until we need one)?


Totally agree. We can remove the "syscon" and "simple-mfd" compatibles
for Kaanapali.
For Kaanapali, the reboot reason does not rely on imem at all—it uses
nvmem cells instead.
Previously, the syscon-reboot-mode required "syscon" and "simple-mfd"
compatibles for older targets like APQ8064, which used imem as the
reboot mode solution.


> 
> Regards,
> Bjorn
> 
>> 		reg = <0x0 0x14680000 0x0 0x1000>;
>> 		ranges = <0 0 0x14680000 0x1000>;
>>
>> 		#address-cells = <1>;
>> 		#size-cells = <1>;
>>
>> 		pil-reloc-sram@94c {
>> 			compatible = "qcom,pil-reloc-info";
>> 			reg = <0x94c 0xc8>;
>> 		};
>> 	};
>>
>>
>> -- 
>> With best wishes
>> Dmitry


-- 
Thx and BRs,
Aiqun(Maria) Yu

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Bjorn Andersson]

On Wed, Oct 29, 2025 at 07:47:11PM +0800, Aiqun(Maria) Yu wrote:
> On 10/28/2025 2:44 AM, Bjorn Andersson wrote:
> > On Thu, Oct 23, 2025 at 03:06:00AM +0300, Dmitry Baryshkov wrote:
> >> On Wed, Oct 22, 2025 at 05:42:58PM -0500, Bjorn Andersson wrote:
> >>> On Wed, Oct 22, 2025 at 12:34:58PM +0300, Dmitry Baryshkov wrote:
> >>>> On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
> >>>>>
> >>>>>
> >>>>> On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
> >>>>>> On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
> >>>>>>> Document qcom,kaanapali-imem compatible.
> >>>>>>>
> >>>>>>> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
> >>>>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> >>>>>>> ---
> >>>>>>>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
> >>>>>>>  1 file changed, 1 insertion(+)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> >>>>>>> index 6a627c57ae2f..1e29a8ff287f 100644
> >>>>>>> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> >>>>>>> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> >>>>>>> @@ -19,6 +19,7 @@ properties:
> >>>>>>>        - enum:
> >>>>>>>            - qcom,apq8064-imem
> >>>>>>>            - qcom,ipq5424-imem
> >>>>>>> +          - qcom,kaanapali-imem
> >>>>>>
> >>>>>> Can you use mmio-sram instead?
> >>>>>>
> >>>>>
> >>>>> Here is the node: 
> >>>>>
> >>>>> 		sram@14680000 {
> >>>>> 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
> >>>>> 			reg = <0x0 0x14680000 0x0 0x1000>;
> >>>>> 			ranges = <0 0 0x14680000 0x1000>;
> >>>>>
> >>>>> 			#address-cells = <1>;
> >>>>> 			#size-cells = <1>;
> >>>>>
> >>>>> 			pil-reloc@94c {
> >>>>> 				compatible = "qcom,pil-reloc-info";
> >>>>> 				reg = <0x94c 0xc8>;
> >>>>> 			};
> >>>>> 		};
> >>>>>
> >>>>> other qualcomm are also using imem, could you please give more details on why
> >>>>> we should use mmio-sram here?
> >>>>
> >>>> https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/
> >>>>
> >>>
> >>> I considered exactly this when I wrote the binding back then...
> >>>
> >>> But the binding defines mmio-sram as "Simple IO memory regions to be
> >>> managed by the genalloc API." and the Linux sram driver follows that and
> >>> registers a gen_pool across the sram memory region.
> >>>
> >>> I believe IMEM is SRAM (it's at least not registers), but its memory
> >>> layout is fixed, so it's not a pool in any form.
> >>>
> >>>
> >>> What Krzysztof says makes sense, but rather than just throwing a yak at
> >>> Jingyi, it would be nice if you provided some guidance on how you would
> >>> like to see this turn out.
> >>
> >> I tested, pretty same approach seems to work:
> >>
> > 
> > Now you're shaving at random ;)
> > 
> >> 	sram@14680000 {
> >> 		compatible = "mmio-sram";
> > 
> > You can put "pil-reloc-sram" wherever, because it will perform a
> > of_find_compatible_node() to dig up some node with the compatible
> > "qcom,pil-reloc-info" .
> > 
> > In other words, this line created a genpool for something that really
> > isn't a genpool, but luckily that didn't have any side effects.
> > 
> > 
> > There are however other users of IMEM, such as the "reboot-mode", which
> > relies on the "sram" device probing child devices, and is implemented by
> > "syscon-reboot-mode".
> > 
> > Perhaps the solution is to not support any new users of that?
> > 
> > 
> > But no matter what, the definition "Simple IO memory regions to be
> > managed by the genalloc API" will never be true for IMEM.
> > 
> > And as this isn't a syscon, simple-mfd, or mmio-sram...how about making
> > the fallback "qcom,imem" (in this same binding) and omitting any
> > implementation until we need one)?
> 
> 
> Totally agree. We can remove the "syscon" and "simple-mfd" compatibles
> for Kaanapali.
> For Kaanapali, the reboot reason does not rely on imem at all—it uses
> nvmem cells instead.
> Previously, the syscon-reboot-mode required "syscon" and "simple-mfd"
> compatibles for older targets like APQ8064, which used imem as the
> reboot mode solution.
> 

And there's
https://lore.kernel.org/lkml/20250527-topic-ipa_imem-v2-0-6d1aad91b841@oss.qualcomm.com/
which Konrad pointed out, which would also work with this model
(qcom,imem fallback but no implementation).


This also does leave the door open for a future qcom,imem
implementation, if we need to associate some logic to the imem device
itself.

Regards,
Bjorn

> 
> > 
> > Regards,
> > Bjorn
> > 
> >> 		reg = <0x0 0x14680000 0x0 0x1000>;
> >> 		ranges = <0 0 0x14680000 0x1000>;
> >>
> >> 		#address-cells = <1>;
> >> 		#size-cells = <1>;
> >>
> >> 		pil-reloc-sram@94c {
> >> 			compatible = "qcom,pil-reloc-info";
> >> 			reg = <0x94c 0xc8>;
> >> 		};
> >> 	};
> >>
> >>
> >> -- 
> >> With best wishes
> >> Dmitry
> 
> 
> -- 
> Thx and BRs,
> Aiqun(Maria) Yu

Re: (subset) [PATCH v2 0/4] dt-bindings: soc: qcom: Add soc related bindings for Kaanapali and Glymur

[Bjorn Andersson]

On Wed, 22 Oct 2025 00:28:40 -0700, Jingyi Wang wrote:
> Add soc related bindings for Kaanapali Platform including aoss_qmp,
> imem and scm. And add aoss_qmp for Glymur.
> 
> 

Applied, thanks!

[4/4] dt-bindings: soc: qcom,aoss-qmp: Document the Glymur AOSS side channel
      commit: df8764c2cbfeae63c4fa42c9d4ce926e412fa53c

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>

Re: [PATCH v2 1/4] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Konrad Dybcio]

On 10/29/25 4:37 PM, Bjorn Andersson wrote:
> On Wed, Oct 29, 2025 at 07:47:11PM +0800, Aiqun(Maria) Yu wrote:
>> On 10/28/2025 2:44 AM, Bjorn Andersson wrote:
>>> On Thu, Oct 23, 2025 at 03:06:00AM +0300, Dmitry Baryshkov wrote:
>>>> On Wed, Oct 22, 2025 at 05:42:58PM -0500, Bjorn Andersson wrote:
>>>>> On Wed, Oct 22, 2025 at 12:34:58PM +0300, Dmitry Baryshkov wrote:
>>>>>> On Wed, Oct 22, 2025 at 05:05:30PM +0800, Jingyi Wang wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 10/22/2025 4:49 PM, Dmitry Baryshkov wrote:
>>>>>>>> On Wed, Oct 22, 2025 at 12:28:41AM -0700, Jingyi Wang wrote:
>>>>>>>>> Document qcom,kaanapali-imem compatible.
>>>>>>>>>
>>>>>>>>> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
>>>>>>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>>>>>>>> ---
>>>>>>>>>  Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
>>>>>>>>>  1 file changed, 1 insertion(+)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>>>>> index 6a627c57ae2f..1e29a8ff287f 100644
>>>>>>>>> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>>>>> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>>>>>>>>> @@ -19,6 +19,7 @@ properties:
>>>>>>>>>        - enum:
>>>>>>>>>            - qcom,apq8064-imem
>>>>>>>>>            - qcom,ipq5424-imem
>>>>>>>>> +          - qcom,kaanapali-imem
>>>>>>>>
>>>>>>>> Can you use mmio-sram instead?
>>>>>>>>
>>>>>>>
>>>>>>> Here is the node: 
>>>>>>>
>>>>>>> 		sram@14680000 {
>>>>>>> 			compatible = "qcom,kaanapali-imem", "syscon", "simple-mfd";
>>>>>>> 			reg = <0x0 0x14680000 0x0 0x1000>;
>>>>>>> 			ranges = <0 0 0x14680000 0x1000>;
>>>>>>>
>>>>>>> 			#address-cells = <1>;
>>>>>>> 			#size-cells = <1>;
>>>>>>>
>>>>>>> 			pil-reloc@94c {
>>>>>>> 				compatible = "qcom,pil-reloc-info";
>>>>>>> 				reg = <0x94c 0xc8>;
>>>>>>> 			};
>>>>>>> 		};
>>>>>>>
>>>>>>> other qualcomm are also using imem, could you please give more details on why
>>>>>>> we should use mmio-sram here?
>>>>>>
>>>>>> https://lore.kernel.org/linux-arm-msm/e4c5ecc3-fd97-4b13-a057-bb1a3b7f9207@kernel.org/
>>>>>>
>>>>>
>>>>> I considered exactly this when I wrote the binding back then...
>>>>>
>>>>> But the binding defines mmio-sram as "Simple IO memory regions to be
>>>>> managed by the genalloc API." and the Linux sram driver follows that and
>>>>> registers a gen_pool across the sram memory region.
>>>>>
>>>>> I believe IMEM is SRAM (it's at least not registers), but its memory
>>>>> layout is fixed, so it's not a pool in any form.
>>>>>
>>>>>
>>>>> What Krzysztof says makes sense, but rather than just throwing a yak at
>>>>> Jingyi, it would be nice if you provided some guidance on how you would
>>>>> like to see this turn out.
>>>>
>>>> I tested, pretty same approach seems to work:
>>>>
>>>
>>> Now you're shaving at random ;)
>>>
>>>> 	sram@14680000 {
>>>> 		compatible = "mmio-sram";
>>>
>>> You can put "pil-reloc-sram" wherever, because it will perform a
>>> of_find_compatible_node() to dig up some node with the compatible
>>> "qcom,pil-reloc-info" .
>>>
>>> In other words, this line created a genpool for something that really
>>> isn't a genpool, but luckily that didn't have any side effects.
>>>
>>>
>>> There are however other users of IMEM, such as the "reboot-mode", which
>>> relies on the "sram" device probing child devices, and is implemented by
>>> "syscon-reboot-mode".
>>>
>>> Perhaps the solution is to not support any new users of that?
>>>
>>>
>>> But no matter what, the definition "Simple IO memory regions to be
>>> managed by the genalloc API" will never be true for IMEM.
>>>
>>> And as this isn't a syscon, simple-mfd, or mmio-sram...how about making
>>> the fallback "qcom,imem" (in this same binding) and omitting any
>>> implementation until we need one)?
>>
>>
>> Totally agree. We can remove the "syscon" and "simple-mfd" compatibles
>> for Kaanapali.
>> For Kaanapali, the reboot reason does not rely on imem at all—it uses
>> nvmem cells instead.
>> Previously, the syscon-reboot-mode required "syscon" and "simple-mfd"
>> compatibles for older targets like APQ8064, which used imem as the
>> reboot mode solution.
>>
> 
> And there's
> https://lore.kernel.org/lkml/20250527-topic-ipa_imem-v2-0-6d1aad91b841@oss.qualcomm.com/
> which Konrad pointed out, which would also work with this model
> (qcom,imem fallback but no implementation).

Hm sorry I skipped this thread and started repeating similar points
in v3.

Ultimately I don't really care either way (mmio-sram vs generic node
acted upon by different drivers), but I do care about closing this
discussion..

Konrad