Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
simple-mfd, also "reboot reason" is not required on Kaanapali like some
other platforms. So define a common "qcom,imem" binding and fallback to it.
Currently there is no requirement for any specific implementation for the
"qcom,imem". Its child node "qcom,pil-reloc-info" has no implementation
dependency on IMEM.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
.../devicetree/bindings/sram/qcom,imem.yaml | 77 ++++++++++++----------
1 file changed, 41 insertions(+), 36 deletions(-)
diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index 6a627c57ae2f..09278b21acf4 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -15,42 +15,47 @@ description:
properties:
compatible:
- items:
- - enum:
- - qcom,apq8064-imem
- - qcom,ipq5424-imem
- - qcom,msm8226-imem
- - qcom,msm8974-imem
- - qcom,msm8976-imem
- - qcom,qcs404-imem
- - qcom,qcs615-imem
- - qcom,qcs8300-imem
- - qcom,qdu1000-imem
- - qcom,sa8775p-imem
- - qcom,sar2130p-imem
- - qcom,sc7180-imem
- - qcom,sc7280-imem
- - qcom,sc8280xp-imem
- - qcom,sdm630-imem
- - qcom,sdm845-imem
- - qcom,sdx55-imem
- - qcom,sdx65-imem
- - qcom,sdx75-imem
- - qcom,sm6115-imem
- - qcom,sm6125-imem
- - qcom,sm6350-imem
- - qcom,sm6375-imem
- - qcom,sm7150-imem
- - qcom,sm8150-imem
- - qcom,sm8250-imem
- - qcom,sm8350-imem
- - qcom,sm8450-imem
- - qcom,sm8550-imem
- - qcom,sm8650-imem
- - qcom,sm8750-imem
- - qcom,x1e80100-imem
- - const: syscon
- - const: simple-mfd
+ oneOf:
+ - items:
+ - enum:
+ - qcom,apq8064-imem
+ - qcom,ipq5424-imem
+ - qcom,msm8226-imem
+ - qcom,msm8974-imem
+ - qcom,msm8976-imem
+ - qcom,qcs404-imem
+ - qcom,qcs615-imem
+ - qcom,qcs8300-imem
+ - qcom,qdu1000-imem
+ - qcom,sa8775p-imem
+ - qcom,sar2130p-imem
+ - qcom,sc7180-imem
+ - qcom,sc7280-imem
+ - qcom,sc8280xp-imem
+ - qcom,sdm630-imem
+ - qcom,sdm845-imem
+ - qcom,sdx55-imem
+ - qcom,sdx65-imem
+ - qcom,sdx75-imem
+ - qcom,sm6115-imem
+ - qcom,sm6125-imem
+ - qcom,sm6350-imem
+ - qcom,sm6375-imem
+ - qcom,sm7150-imem
+ - qcom,sm8150-imem
+ - qcom,sm8250-imem
+ - qcom,sm8350-imem
+ - qcom,sm8450-imem
+ - qcom,sm8550-imem
+ - qcom,sm8650-imem
+ - qcom,sm8750-imem
+ - qcom,x1e80100-imem
+ - const: syscon
+ - const: simple-mfd
+ - items:
+ - enum:
+ - qcom,kaanapali-imem
+ - const: qcom,imem
reg:
maxItems: 1
--
2.25.1On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote: > Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or > simple-mfd, also "reboot reason" is not required on Kaanapali like some I do not see correlation. Something is not a syscon, so you add a new generic compatible? No. > other platforms. So define a common "qcom,imem" binding and fallback to it. You did not define fallback to it! ... > + - items: > + - enum: > + - qcom,kaanapali-imem > + - const: qcom,imem I do not understand what this generic compatible is supposed to express, not explained in commit msg. Considering this wasn't before, it is a major and really undesired change. It also makes no sesne. There was no generic compatible before but "if not syscon" now this must have generic compatible, what? NAK Best regards, Krzysztof
On 11/4/25 9:16 AM, Krzysztof Kozlowski wrote:
> On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
>> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
>> simple-mfd, also "reboot reason" is not required on Kaanapali like some
>
> I do not see correlation. Something is not a syscon, so you add a new
> generic compatible? No.
>
>> other platforms. So define a common "qcom,imem" binding and fallback to it.
>
> You did not define fallback to it!
>
> ...
>
>> + - items:
>> + - enum:
>> + - qcom,kaanapali-imem
>> + - const: qcom,imem
>
> I do not understand what this generic compatible is supposed to express,
> not explained in commit msg. Considering this wasn't before, it is a
> major and really undesired change. It also makes no sesne. There was no
> generic compatible before but "if not syscon" now this must have generic
> compatible, what?
So IMEM (or SYSTEM_IMEM more specifically as opposed to BOOT_IMEM which
you can take your guesses what it's used for) is to the best of our
understanding just a piece of SRAM that's accessible by multiple
processors/subsystems on the SoC.
A smaller region within it ("shared IMEM") is a little bit of a dumping
ground for various (incl. runtime) configuration and debug magic data
and that's usually what Linux is concerned with.
IMEM is currently described as a simple-mfd+syscon, which it is clearly
not. The former, as we've established in the past, was used as a hack to
have something call of_platform_populate().
I think that in turn is only necessary for the old arm32 DTs which have
a syscon-reboot-mode node under IMEM (and I think that's where the syscon
compatible comes from).
Should we make the switch to mmio-sram and settle this discussion?
It would probably require convincing the sram maintainer to add that
of_platform_populate() call in its probe func and making syscon-reboot
not depend on a syscon (not like it's very hard)
Konrad
On 04/11/2025 13:32, Konrad Dybcio wrote:
> On 11/4/25 9:16 AM, Krzysztof Kozlowski wrote:
>> On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
>>> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
>>> simple-mfd, also "reboot reason" is not required on Kaanapali like some
>>
>> I do not see correlation. Something is not a syscon, so you add a new
>> generic compatible? No.
>>
>>> other platforms. So define a common "qcom,imem" binding and fallback to it.
>>
>> You did not define fallback to it!
>>
>> ...
>>
>>> + - items:
>>> + - enum:
>>> + - qcom,kaanapali-imem
>>> + - const: qcom,imem
>>
>> I do not understand what this generic compatible is supposed to express,
>> not explained in commit msg. Considering this wasn't before, it is a
>> major and really undesired change. It also makes no sesne. There was no
>> generic compatible before but "if not syscon" now this must have generic
>> compatible, what?
>
> So IMEM (or SYSTEM_IMEM more specifically as opposed to BOOT_IMEM which
> you can take your guesses what it's used for) is to the best of our
> understanding just a piece of SRAM that's accessible by multiple
> processors/subsystems on the SoC.
>
> A smaller region within it ("shared IMEM") is a little bit of a dumping
> ground for various (incl. runtime) configuration and debug magic data
> and that's usually what Linux is concerned with.
>
> IMEM is currently described as a simple-mfd+syscon, which it is clearly
> not. The former, as we've established in the past, was used as a hack to
> have something call of_platform_populate().
>
> I think that in turn is only necessary for the old arm32 DTs which have
> a syscon-reboot-mode node under IMEM (and I think that's where the syscon
> compatible comes from).
>
> Should we make the switch to mmio-sram and settle this discussion?
> It would probably require convincing the sram maintainer to add that
> of_platform_populate() call in its probe func and making syscon-reboot
> not depend on a syscon (not like it's very hard)
This I got, but nothing here explains why you need generic compatible.
To re-iterate: there was no generic compatible before, now there is.
Writing bindings and numerous reviews from DT maintainers ask not to use
generic compatibles.
Best regards,
Krzysztof
On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
> On 04/11/2025 13:32, Konrad Dybcio wrote:
>> On 11/4/25 9:16 AM, Krzysztof Kozlowski wrote:
>>> On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
>>>> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
>>>> simple-mfd, also "reboot reason" is not required on Kaanapali like some
>>>
>>> I do not see correlation. Something is not a syscon, so you add a new
>>> generic compatible? No.
>>>
>>>> other platforms. So define a common "qcom,imem" binding and fallback to it.
>>>
>>> You did not define fallback to it!
>>>
>>> ...
>>>
>>>> + - items:
>>>> + - enum:
>>>> + - qcom,kaanapali-imem
>>>> + - const: qcom,imem
>>>
>>> I do not understand what this generic compatible is supposed to express,
>>> not explained in commit msg. Considering this wasn't before, it is a
>>> major and really undesired change. It also makes no sesne. There was no
>>> generic compatible before but "if not syscon" now this must have generic
>>> compatible, what?
>>
>> So IMEM (or SYSTEM_IMEM more specifically as opposed to BOOT_IMEM which
>> you can take your guesses what it's used for) is to the best of our
>> understanding just a piece of SRAM that's accessible by multiple
>> processors/subsystems on the SoC.
>>
>> A smaller region within it ("shared IMEM") is a little bit of a dumping
>> ground for various (incl. runtime) configuration and debug magic data
>> and that's usually what Linux is concerned with.
>>
>> IMEM is currently described as a simple-mfd+syscon, which it is clearly
>> not. The former, as we've established in the past, was used as a hack to
>> have something call of_platform_populate().
>>
>> I think that in turn is only necessary for the old arm32 DTs which have
>> a syscon-reboot-mode node under IMEM (and I think that's where the syscon
>> compatible comes from).
>>
>> Should we make the switch to mmio-sram and settle this discussion?
>> It would probably require convincing the sram maintainer to add that
>> of_platform_populate() call in its probe func and making syscon-reboot
>> not depend on a syscon (not like it's very hard)
>
> This I got, but nothing here explains why you need generic compatible.
> To re-iterate: there was no generic compatible before, now there is.
> Writing bindings and numerous reviews from DT maintainers ask not to use
> generic compatibles.
OK so let's not worry about a generic compatible. IMEM exists since
MSM8974 and it only had major hw updates with SM8550. They don't
impact the software interface though, so qcom,msm8974-imem is OK.
There's a separate control/status register address space for each
instance of this IP (usually far apart from the actual SRAM pool),
which Linux doesn't have to care about.
Konrad
On 04/11/2025 15:35, Konrad Dybcio wrote: > On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: >> This I got, but nothing here explains why you need generic compatible. >> To re-iterate: there was no generic compatible before, now there is. >> Writing bindings and numerous reviews from DT maintainers ask not to use >> generic compatibles. > > OK so let's not worry about a generic compatible. IMEM exists since > MSM8974 and it only had major hw updates with SM8550. They don't > impact the software interface though, so qcom,msm8974-imem is OK. > > There's a separate control/status register address space for each > instance of this IP (usually far apart from the actual SRAM pool), > which Linux doesn't have to care about. Just use qcom,kaanapali-imem - that's the first device here without syscons. Best regards, Krzysztof
On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote: > On 04/11/2025 15:35, Konrad Dybcio wrote: >> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: >>> This I got, but nothing here explains why you need generic compatible. >>> To re-iterate: there was no generic compatible before, now there is. >>> Writing bindings and numerous reviews from DT maintainers ask not to use >>> generic compatibles. >> >> OK so let's not worry about a generic compatible. IMEM exists since >> MSM8974 and it only had major hw updates with SM8550. They don't >> impact the software interface though, so qcom,msm8974-imem is OK. >> >> There's a separate control/status register address space for each >> instance of this IP (usually far apart from the actual SRAM pool), >> which Linux doesn't have to care about. > > Just use qcom,kaanapali-imem - that's the first device here without syscons. So we don't want to move the existing ones over? Konrad
On 04/11/2025 15:38, Konrad Dybcio wrote: > On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote: >> On 04/11/2025 15:35, Konrad Dybcio wrote: >>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: >>>> This I got, but nothing here explains why you need generic compatible. >>>> To re-iterate: there was no generic compatible before, now there is. >>>> Writing bindings and numerous reviews from DT maintainers ask not to use >>>> generic compatibles. >>> >>> OK so let's not worry about a generic compatible. IMEM exists since >>> MSM8974 and it only had major hw updates with SM8550. They don't >>> impact the software interface though, so qcom,msm8974-imem is OK. >>> >>> There's a separate control/status register address space for each >>> instance of this IP (usually far apart from the actual SRAM pool), >>> which Linux doesn't have to care about. >> >> Just use qcom,kaanapali-imem - that's the first device here without syscons. > > So we don't want to move the existing ones over? This was never discussed and this patch did not do it. You cannot move them, that's ABI. Best regards, Krzysztof
On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote:
> On 04/11/2025 15:38, Konrad Dybcio wrote:
>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
>>> On 04/11/2025 15:35, Konrad Dybcio wrote:
>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>>>> This I got, but nothing here explains why you need generic compatible.
>>>>> To re-iterate: there was no generic compatible before, now there is.
>>>>> Writing bindings and numerous reviews from DT maintainers ask not to use
>>>>> generic compatibles.
>>>>
>>>> OK so let's not worry about a generic compatible. IMEM exists since
>>>> MSM8974 and it only had major hw updates with SM8550. They don't
>>>> impact the software interface though, so qcom,msm8974-imem is OK.
>>>>
>>>> There's a separate control/status register address space for each
>>>> instance of this IP (usually far apart from the actual SRAM pool),
>>>> which Linux doesn't have to care about.
>>>
>>> Just use qcom,kaanapali-imem - that's the first device here without syscons.
>>
>> So we don't want to move the existing ones over?
>
> This was never discussed and this patch did not do it. You cannot move
> them, that's ABI.
I see, I implicitly assumed this would be a sweeping change.
So should the Kaanapali submitters simply send a version of this
patch with:
- oneOf:
- const: qcom,kaanapali-imem
- items:
# existing big list
?
I'm not a huge fan of using kaanapali as the fallback-going-forward
since it's literally the newest platform on the shelves (or perhaps
not even on the shelves yet..) so it's going to look funny when
someone comes up with support for another 2013 soc.. but perhaps
that's just how things are supposed to be
Konrad
On Tue, Nov 04, 2025 at 03:58:27PM +0100, Konrad Dybcio wrote: > On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote: > > On 04/11/2025 15:38, Konrad Dybcio wrote: > >> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote: > >>> On 04/11/2025 15:35, Konrad Dybcio wrote: > >>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: > >>>>> This I got, but nothing here explains why you need generic compatible. > >>>>> To re-iterate: there was no generic compatible before, now there is. > >>>>> Writing bindings and numerous reviews from DT maintainers ask not to use > >>>>> generic compatibles. > >>>> > >>>> OK so let's not worry about a generic compatible. IMEM exists since > >>>> MSM8974 and it only had major hw updates with SM8550. They don't > >>>> impact the software interface though, so qcom,msm8974-imem is OK. > >>>> > >>>> There's a separate control/status register address space for each > >>>> instance of this IP (usually far apart from the actual SRAM pool), > >>>> which Linux doesn't have to care about. > >>> > >>> Just use qcom,kaanapali-imem - that's the first device here without syscons. > >> > >> So we don't want to move the existing ones over? > > > > This was never discussed and this patch did not do it. You cannot move > > them, that's ABI. > > I see, I implicitly assumed this would be a sweeping change. > > So should the Kaanapali submitters simply send a version of this > patch with: > > - oneOf: > - const: qcom,kaanapali-imem > - items: > # existing big list > > ? We have 33 cases of "this is just a generic Qualcomm IMEM block", could we just make it "qcom,imem" until there's actually a sign that it's not a platform-independent block? Regards, Bjorn > > I'm not a huge fan of using kaanapali as the fallback-going-forward > since it's literally the newest platform on the shelves (or perhaps > not even on the shelves yet..) so it's going to look funny when > someone comes up with support for another 2013 soc.. but perhaps > that's just how things are supposed to be > > Konrad
On 11/7/2025 1:54 AM, Bjorn Andersson wrote: > On Tue, Nov 04, 2025 at 03:58:27PM +0100, Konrad Dybcio wrote: >> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote: >>> On 04/11/2025 15:38, Konrad Dybcio wrote: >>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote: >>>>> On 04/11/2025 15:35, Konrad Dybcio wrote: >>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: >>>>>>> This I got, but nothing here explains why you need generic compatible. >>>>>>> To re-iterate: there was no generic compatible before, now there is. >>>>>>> Writing bindings and numerous reviews from DT maintainers ask not to use >>>>>>> generic compatibles. >>>>>> OK so let's not worry about a generic compatible. IMEM exists since >>>>>> MSM8974 and it only had major hw updates with SM8550. They don't >>>>>> impact the software interface though, so qcom,msm8974-imem is OK. >>>>>> >>>>>> There's a separate control/status register address space for each >>>>>> instance of this IP (usually far apart from the actual SRAM pool), >>>>>> which Linux doesn't have to care about. >>>>> Just use qcom,kaanapali-imem - that's the first device here without syscons. >>>> So we don't want to move the existing ones over? >>> This was never discussed and this patch did not do it. You cannot move >>> them, that's ABI. >> I see, I implicitly assumed this would be a sweeping change. >> >> So should the Kaanapali submitters simply send a version of this >> patch with: >> >> - oneOf: >> - const: qcom,kaanapali-imem >> - items: >> # existing big list >> >> ? > We have 33 cases of "this is just a generic Qualcomm IMEM block", could > we just make it "qcom,imem" until there's actually a sign that it's not > a platform-independent block? Any conclusion / further feedback on this would be helpful to move things forward. Thanks in advance. > > Regards, > Bjorn > >> I'm not a huge fan of using kaanapali as the fallback-going-forward >> since it's literally the newest platform on the shelves (or perhaps >> not even on the shelves yet..) so it's going to look funny when >> someone comes up with support for another 2013 soc.. but perhaps >> that's just how things are supposed to be >> >> Konrad
On 11/11/2025 4:29 PM, Kathiravan Thirumoorthy wrote: > > On 11/7/2025 1:54 AM, Bjorn Andersson wrote: >> On Tue, Nov 04, 2025 at 03:58:27PM +0100, Konrad Dybcio wrote: >>> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote: >>>> On 04/11/2025 15:38, Konrad Dybcio wrote: >>>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote: >>>>>> On 04/11/2025 15:35, Konrad Dybcio wrote: >>>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: >>>>>>>> This I got, but nothing here explains why you need generic >>>>>>>> compatible. >>>>>>>> To re-iterate: there was no generic compatible before, now there >>>>>>>> is. >>>>>>>> Writing bindings and numerous reviews from DT maintainers ask >>>>>>>> not to use >>>>>>>> generic compatibles. >>>>>>> OK so let's not worry about a generic compatible. IMEM exists since >>>>>>> MSM8974 and it only had major hw updates with SM8550. They don't >>>>>>> impact the software interface though, so qcom,msm8974-imem is OK. >>>>>>> >>>>>>> There's a separate control/status register address space for each >>>>>>> instance of this IP (usually far apart from the actual SRAM pool), >>>>>>> which Linux doesn't have to care about. >>>>>> Just use qcom,kaanapali-imem - that's the first device here >>>>>> without syscons. >>>>> So we don't want to move the existing ones over? >>>> This was never discussed and this patch did not do it. You cannot move >>>> them, that's ABI. >>> I see, I implicitly assumed this would be a sweeping change. >>> >>> So should the Kaanapali submitters simply send a version of this >>> patch with: >>> >>> - oneOf: >>> - const: qcom,kaanapali-imem >>> - items: >>> # existing big list >>> >>> ? >> We have 33 cases of "this is just a generic Qualcomm IMEM block", could >> we just make it "qcom,imem" until there's actually a sign that it's not >> a platform-independent block? If it’s not platform-specific, why not use a common compatible here? I mean let's have a common "qcom,imem" start from kaanapali. What benefits would a platform-specific approach bring in this case? For newer platforms, we could simply adopt the common compatible and avoid adding a dedicated platform compatible name. Also, the old bootloader reboot-mode solution that uses the IMEM area as a magic syscon is deprecated for newer targets. > > > Any conclusion / further feedback on this would be helpful to move > things forward. Thanks in advance. Which platform are you waiting for as a reference? Or are you only focused on the current Kaanapali? By the way, great to see we share the same goal here. > > >> >> Regards, >> Bjorn >> >>> I'm not a huge fan of using kaanapali as the fallback-going-forward >>> since it's literally the newest platform on the shelves (or perhaps >>> not even on the shelves yet..) so it's going to look funny when >>> someone comes up with support for another 2013 soc.. but perhaps >>> that's just how things are supposed to be >>> >>> Konrad -- Thx and BRs, Aiqun(Maria) Yu
On 11/11/2025 5:38 PM, Aiqun(Maria) Yu wrote: > On 11/11/2025 4:29 PM, Kathiravan Thirumoorthy wrote: >> On 11/7/2025 1:54 AM, Bjorn Andersson wrote: >>> On Tue, Nov 04, 2025 at 03:58:27PM +0100, Konrad Dybcio wrote: >>>> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote: >>>>> On 04/11/2025 15:38, Konrad Dybcio wrote: >>>>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote: >>>>>>> On 04/11/2025 15:35, Konrad Dybcio wrote: >>>>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: >>>>>>>>> This I got, but nothing here explains why you need generic >>>>>>>>> compatible. >>>>>>>>> To re-iterate: there was no generic compatible before, now there >>>>>>>>> is. >>>>>>>>> Writing bindings and numerous reviews from DT maintainers ask >>>>>>>>> not to use >>>>>>>>> generic compatibles. >>>>>>>> OK so let's not worry about a generic compatible. IMEM exists since >>>>>>>> MSM8974 and it only had major hw updates with SM8550. They don't >>>>>>>> impact the software interface though, so qcom,msm8974-imem is OK. >>>>>>>> >>>>>>>> There's a separate control/status register address space for each >>>>>>>> instance of this IP (usually far apart from the actual SRAM pool), >>>>>>>> which Linux doesn't have to care about. >>>>>>> Just use qcom,kaanapali-imem - that's the first device here >>>>>>> without syscons. >>>>>> So we don't want to move the existing ones over? >>>>> This was never discussed and this patch did not do it. You cannot move >>>>> them, that's ABI. >>>> I see, I implicitly assumed this would be a sweeping change. >>>> >>>> So should the Kaanapali submitters simply send a version of this >>>> patch with: >>>> >>>> - oneOf: >>>> - const: qcom,kaanapali-imem >>>> - items: >>>> # existing big list >>>> >>>> ? >>> We have 33 cases of "this is just a generic Qualcomm IMEM block", could >>> we just make it "qcom,imem" until there's actually a sign that it's not >>> a platform-independent block? > If it’s not platform-specific, why not use a common compatible here? I > mean let's have a common "qcom,imem" start from kaanapali. > > What benefits would a platform-specific approach bring in this case? For > newer platforms, we could simply adopt the common compatible and avoid > adding a dedicated platform compatible name. > > Also, the old bootloader reboot-mode solution that uses the IMEM area as > a magic syscon is deprecated for newer targets. > >> >> Any conclusion / further feedback on this would be helpful to move >> things forward. Thanks in advance. > > Which platform are you waiting for as a reference? Or are you only > focused on the current Kaanapali? > By the way, great to see we share the same goal here. I'm working on the IPQ SoCs. All of these discussions started from the IPQ series[1], followed by Konrad's IPA stuff[2] and now we are in Kaanapali. [1] https://lore.kernel.org/linux-arm-msm/20250610-wdt_reset_reason-v5-0-2d2835160ab5@oss.qualcomm.com/ [2] https://lore.kernel.org/linux-arm-msm/20250527-topic-ipa_imem-v2-0-6d1aad91b841@oss.qualcomm.com/ Reaching a conclusion on this topic together will help us move forward with the above mentioned series. > >> >>> Regards, >>> Bjorn >>> >>>> I'm not a huge fan of using kaanapali as the fallback-going-forward >>>> since it's literally the newest platform on the shelves (or perhaps >>>> not even on the shelves yet..) so it's going to look funny when >>>> someone comes up with support for another 2013 soc.. but perhaps >>>> that's just how things are supposed to be >>>> >>>> Konrad >
On 04/11/2025 15:58, Konrad Dybcio wrote: > On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote: >> On 04/11/2025 15:38, Konrad Dybcio wrote: >>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote: >>>> On 04/11/2025 15:35, Konrad Dybcio wrote: >>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: >>>>>> This I got, but nothing here explains why you need generic compatible. >>>>>> To re-iterate: there was no generic compatible before, now there is. >>>>>> Writing bindings and numerous reviews from DT maintainers ask not to use >>>>>> generic compatibles. >>>>> >>>>> OK so let's not worry about a generic compatible. IMEM exists since >>>>> MSM8974 and it only had major hw updates with SM8550. They don't >>>>> impact the software interface though, so qcom,msm8974-imem is OK. >>>>> >>>>> There's a separate control/status register address space for each >>>>> instance of this IP (usually far apart from the actual SRAM pool), >>>>> which Linux doesn't have to care about. >>>> >>>> Just use qcom,kaanapali-imem - that's the first device here without syscons. >>> >>> So we don't want to move the existing ones over? >> >> This was never discussed and this patch did not do it. You cannot move >> them, that's ABI. > > I see, I implicitly assumed this would be a sweeping change. > > So should the Kaanapali submitters simply send a version of this > patch with: > > - oneOf: > - const: qcom,kaanapali-imem > - items: > # existing big list > > ? > > I'm not a huge fan of using kaanapali as the fallback-going-forward > since it's literally the newest platform on the shelves (or perhaps > not even on the shelves yet..) so it's going to look funny when > someone comes up with support for another 2013 soc.. but perhaps > that's just how things are supposed to be Yes. Feel free to choose other fully compatible device as the fallback, like you mentioned in previous email, I proposed Kaanapali as the easiest. Best regards, Krzysztof
On 11/4/25 4:02 PM, Krzysztof Kozlowski wrote: > On 04/11/2025 15:58, Konrad Dybcio wrote: >> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote: >>> On 04/11/2025 15:38, Konrad Dybcio wrote: >>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote: >>>>> On 04/11/2025 15:35, Konrad Dybcio wrote: >>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote: >>>>>>> This I got, but nothing here explains why you need generic compatible. >>>>>>> To re-iterate: there was no generic compatible before, now there is. >>>>>>> Writing bindings and numerous reviews from DT maintainers ask not to use >>>>>>> generic compatibles. >>>>>> >>>>>> OK so let's not worry about a generic compatible. IMEM exists since >>>>>> MSM8974 and it only had major hw updates with SM8550. They don't >>>>>> impact the software interface though, so qcom,msm8974-imem is OK. >>>>>> >>>>>> There's a separate control/status register address space for each >>>>>> instance of this IP (usually far apart from the actual SRAM pool), >>>>>> which Linux doesn't have to care about. >>>>> >>>>> Just use qcom,kaanapali-imem - that's the first device here without syscons. >>>> >>>> So we don't want to move the existing ones over? >>> >>> This was never discussed and this patch did not do it. You cannot move >>> them, that's ABI. >> >> I see, I implicitly assumed this would be a sweeping change. >> >> So should the Kaanapali submitters simply send a version of this >> patch with: >> >> - oneOf: >> - const: qcom,kaanapali-imem >> - items: >> # existing big list >> >> ? >> >> I'm not a huge fan of using kaanapali as the fallback-going-forward >> since it's literally the newest platform on the shelves (or perhaps >> not even on the shelves yet..) so it's going to look funny when >> someone comes up with support for another 2013 soc.. but perhaps >> that's just how things are supposed to be > > > Yes. Feel free to choose other fully compatible device as the fallback, > like you mentioned in previous email, I proposed Kaanapali as the easiest. Ehhh it's not super convenient given the available list I see that msm8994 isn't described yet. If we don't need to care about the pre-/post 8550 split (which we would only for the aforementioned control register space which is NOT what this binding describes), let's go with that as the fallback. Konrad
On 11/4/2025 4:16 PM, Krzysztof Kozlowski wrote: > On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote: >> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or >> simple-mfd, also "reboot reason" is not required on Kaanapali like some > > I do not see correlation. Something is not a syscon, so you add a new > generic compatible? No. > >> other platforms. So define a common "qcom,imem" binding and fallback to it. > > You did not define fallback to it! > > ... > >> + - items: >> + - enum: >> + - qcom,kaanapali-imem >> + - const: qcom,imem > > I do not understand what this generic compatible is supposed to express, > not explained in commit msg. Considering this wasn't before, it is a > major and really undesired change. It also makes no sesne. There was no > generic compatible before but "if not syscon" now this must have generic > compatible, what? Are you suggesting to remove the generic compatible of "qcom,imem"? Could you pls help to confirm the suggested way from your point of view? > > NAK > > Best regards, > Krzysztof > -- Thx and BRs, Aiqun(Maria) Yu
On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote: > Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or > simple-mfd, also "reboot reason" is not required on Kaanapali like some > other platforms. So define a common "qcom,imem" binding and fallback to it. > Currently there is no requirement for any specific implementation for the > "qcom,imem". Its child node "qcom,pil-reloc-info" has no implementation > dependency on IMEM. I think this could have captured the discussion leading up to this result a bit better, and the fact that this isn't unique to Kaanapali. But I won't insist on a rewrite. > > Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Regards, Bjorn > --- > .../devicetree/bindings/sram/qcom,imem.yaml | 77 ++++++++++++---------- > 1 file changed, 41 insertions(+), 36 deletions(-) > > diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml > index 6a627c57ae2f..09278b21acf4 100644 > --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml > +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml > @@ -15,42 +15,47 @@ description: > > properties: > compatible: > - items: > - - enum: > - - qcom,apq8064-imem > - - qcom,ipq5424-imem > - - qcom,msm8226-imem > - - qcom,msm8974-imem > - - qcom,msm8976-imem > - - qcom,qcs404-imem > - - qcom,qcs615-imem > - - qcom,qcs8300-imem > - - qcom,qdu1000-imem > - - qcom,sa8775p-imem > - - qcom,sar2130p-imem > - - qcom,sc7180-imem > - - qcom,sc7280-imem > - - qcom,sc8280xp-imem > - - qcom,sdm630-imem > - - qcom,sdm845-imem > - - qcom,sdx55-imem > - - qcom,sdx65-imem > - - qcom,sdx75-imem > - - qcom,sm6115-imem > - - qcom,sm6125-imem > - - qcom,sm6350-imem > - - qcom,sm6375-imem > - - qcom,sm7150-imem > - - qcom,sm8150-imem > - - qcom,sm8250-imem > - - qcom,sm8350-imem > - - qcom,sm8450-imem > - - qcom,sm8550-imem > - - qcom,sm8650-imem > - - qcom,sm8750-imem > - - qcom,x1e80100-imem > - - const: syscon > - - const: simple-mfd > + oneOf: > + - items: > + - enum: > + - qcom,apq8064-imem > + - qcom,ipq5424-imem > + - qcom,msm8226-imem > + - qcom,msm8974-imem > + - qcom,msm8976-imem > + - qcom,qcs404-imem > + - qcom,qcs615-imem > + - qcom,qcs8300-imem > + - qcom,qdu1000-imem > + - qcom,sa8775p-imem > + - qcom,sar2130p-imem > + - qcom,sc7180-imem > + - qcom,sc7280-imem > + - qcom,sc8280xp-imem > + - qcom,sdm630-imem > + - qcom,sdm845-imem > + - qcom,sdx55-imem > + - qcom,sdx65-imem > + - qcom,sdx75-imem > + - qcom,sm6115-imem > + - qcom,sm6125-imem > + - qcom,sm6350-imem > + - qcom,sm6375-imem > + - qcom,sm7150-imem > + - qcom,sm8150-imem > + - qcom,sm8250-imem > + - qcom,sm8350-imem > + - qcom,sm8450-imem > + - qcom,sm8550-imem > + - qcom,sm8650-imem > + - qcom,sm8750-imem > + - qcom,x1e80100-imem > + - const: syscon > + - const: simple-mfd > + - items: > + - enum: > + - qcom,kaanapali-imem > + - const: qcom,imem > > reg: > maxItems: 1 > > -- > 2.25.1 >
© 2016 - 2026 Red Hat, Inc.