From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
The IP Accelerator hardware/firmware owns a sizeable region within the
IMEM, named 'modem-tables', containing various packet processing
configuration data.
It's not actually accessed by the OS, although we have to IOMMU-map it
with the IPA device, so that presumably the firmware can act upon it.
Allow it as a subnode of IMEM.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Documentation/devicetree/bindings/sram/qcom,imem.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index 6a627c57ae2f..c63026904061 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -67,6 +67,20 @@ properties:
$ref: /schemas/power/reset/syscon-reboot-mode.yaml#
patternProperties:
+ "^modem-tables@[0-9a-f]+$":
+ type: object
+ description:
+ Region containing packet processing configuration for the IP Accelerator.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ additionalProperties: false
+
"^pil-reloc@[0-9a-f]+$":
$ref: /schemas/remoteproc/qcom,pil-info.yaml#
description: Peripheral image loader relocation region
--
2.53.0On 17/02/2026 14:30, Konrad Dybcio wrote: > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > The IP Accelerator hardware/firmware owns a sizeable region within the > IMEM, named 'modem-tables', containing various packet processing > configuration data. > > It's not actually accessed by the OS, although we have to IOMMU-map it > with the IPA device, so that presumably the firmware can act upon it. > > Allow it as a subnode of IMEM. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > --- > Documentation/devicetree/bindings/sram/qcom,imem.yaml | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Best regards, Krzysztof
On 2/17/26 7:30 AM, Konrad Dybcio wrote: > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > The IP Accelerator hardware/firmware owns a sizeable region within the > IMEM, named 'modem-tables', containing various packet processing > configuration data. > > It's not actually accessed by the OS, although we have to IOMMU-map it > with the IPA device, so that presumably the firmware can act upon it. > > Allow it as a subnode of IMEM. OK so you'll define a "modem-tables@" property in the SRAM node, whose phandle will then be referred to by the "sram" property in the IPA node. That sounds good to me. Thanks Konrad. Reviewed-by: Alex Elder <elder@riscstar.com> > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > --- > Documentation/devicetree/bindings/sram/qcom,imem.yaml | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml > index 6a627c57ae2f..c63026904061 100644 > --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml > +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml > @@ -67,6 +67,20 @@ properties: > $ref: /schemas/power/reset/syscon-reboot-mode.yaml# > > patternProperties: > + "^modem-tables@[0-9a-f]+$": > + type: object > + description: > + Region containing packet processing configuration for the IP Accelerator. > + > + properties: > + reg: > + maxItems: 1 > + > + required: > + - reg > + > + additionalProperties: false > + > "^pil-reloc@[0-9a-f]+$": > $ref: /schemas/remoteproc/qcom,pil-info.yaml# > description: Peripheral image loader relocation region >
On Tue, Feb 17, 2026 at 02:30:31PM +0100, Konrad Dybcio wrote: > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > The IP Accelerator hardware/firmware owns a sizeable region within the > IMEM, named 'modem-tables', containing various packet processing > configuration data. > > It's not actually accessed by the OS, although we have to IOMMU-map it > with the IPA device, so that presumably the firmware can act upon it. > > Allow it as a subnode of IMEM. You do not have compatible, so rely on the node name as ABI, which is fine in general but... I do not see usage of it in the driver. Why do you need to define modem-tables child then? > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > --- > Documentation/devicetree/bindings/sram/qcom,imem.yaml | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) Best regards, Krzysztof
On 2/17/26 9:25 PM, Krzysztof Kozlowski wrote: > On Tue, Feb 17, 2026 at 02:30:31PM +0100, Konrad Dybcio wrote: >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >> >> The IP Accelerator hardware/firmware owns a sizeable region within the >> IMEM, named 'modem-tables', containing various packet processing >> configuration data. >> >> It's not actually accessed by the OS, although we have to IOMMU-map it >> with the IPA device, so that presumably the firmware can act upon it. >> >> Allow it as a subnode of IMEM. > > You do not have compatible, so rely on the node name as ABI, which is > fine in general but... I do not see usage of it in the driver. Why do > you need to define modem-tables child then? I don't really *need* the node name to be an ABI. However, the current binding for IMEM only allows a named "pil-reloc@.." subnode (which is consumed via of_find_compatible_node() in the remoteproc subsystem) so I figured the intention was to keep the list of allowed subnodes strictly moderated If you'd prefer a blanket pattern declaration with say '^[a-z]@[0-9a-z]+$' with just a reg requirement inside, I'm fine with that too Konrad
On 18/02/2026 12:05, Konrad Dybcio wrote: > On 2/17/26 9:25 PM, Krzysztof Kozlowski wrote: >> On Tue, Feb 17, 2026 at 02:30:31PM +0100, Konrad Dybcio wrote: >>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >>> >>> The IP Accelerator hardware/firmware owns a sizeable region within the >>> IMEM, named 'modem-tables', containing various packet processing >>> configuration data. >>> >>> It's not actually accessed by the OS, although we have to IOMMU-map it >>> with the IPA device, so that presumably the firmware can act upon it. >>> >>> Allow it as a subnode of IMEM. >> >> You do not have compatible, so rely on the node name as ABI, which is >> fine in general but... I do not see usage of it in the driver. Why do >> you need to define modem-tables child then? > > I don't really *need* the node name to be an ABI. However, the current > binding for IMEM only allows a named "pil-reloc@.." subnode (which is > consumed via of_find_compatible_node() in the remoteproc subsystem) so I > figured the intention was to keep the list of allowed subnodes strictly > moderated > > If you'd prefer a blanket pattern declaration with say '^[a-z]@[0-9a-z]+$' > with just a reg requirement inside, I'm fine with that too No, the problem is that you do not use the ABI here at all. Neither would you use the blanket pattern, so my question stays: why adding ABI which is not used? The pil-reloc is being used, as you pointed out. Best regards, Krzysztof
On 18-Feb-26 12:56, Krzysztof Kozlowski wrote:
> On 18/02/2026 12:05, Konrad Dybcio wrote:
>> On 2/17/26 9:25 PM, Krzysztof Kozlowski wrote:
>>> On Tue, Feb 17, 2026 at 02:30:31PM +0100, Konrad Dybcio wrote:
>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>
>>>> The IP Accelerator hardware/firmware owns a sizeable region within the
>>>> IMEM, named 'modem-tables', containing various packet processing
>>>> configuration data.
>>>>
>>>> It's not actually accessed by the OS, although we have to IOMMU-map it
>>>> with the IPA device, so that presumably the firmware can act upon it.
>>>>
>>>> Allow it as a subnode of IMEM.
>>>
>>> You do not have compatible, so rely on the node name as ABI, which is
>>> fine in general but... I do not see usage of it in the driver. Why do
>>> you need to define modem-tables child then?
>>
>> I don't really *need* the node name to be an ABI. However, the current
>> binding for IMEM only allows a named "pil-reloc@.." subnode (which is
>> consumed via of_find_compatible_node() in the remoteproc subsystem) so I
>> figured the intention was to keep the list of allowed subnodes strictly
>> moderated
>>
>> If you'd prefer a blanket pattern declaration with say '^[a-z]@[0-9a-z]+$'
>> with just a reg requirement inside, I'm fine with that too
>
> No, the problem is that you do not use the ABI here at all. Neither
> would you use the blanket pattern, so my question stays: why adding ABI
> which is not used?
The subnode I'm trying to introduce is going to be consumed (via a
phandle reference) from the IPA node, as done by the remaining 2
patches in this series.
I would much prefer not to touch this binding file, but there's an
additionalProperties: false and just adding it as-is results in a:
arch/arm64/boot/dts/qcom/sc7280-idp.dtb: sram@146a5000: 'modem-tables@1234' does not match any of the regexes: '^pil-reloc@[0-9a-f]+$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/sram/qcom,imem.yaml#
Konrad
>
> The pil-reloc is being used, as you pointed out.
>
> Best regards,
> Krzysztof
On 18/02/2026 13:26, Konrad Dybcio wrote: > > > On 18-Feb-26 12:56, Krzysztof Kozlowski wrote: >> On 18/02/2026 12:05, Konrad Dybcio wrote: >>> On 2/17/26 9:25 PM, Krzysztof Kozlowski wrote: >>>> On Tue, Feb 17, 2026 at 02:30:31PM +0100, Konrad Dybcio wrote: >>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >>>>> >>>>> The IP Accelerator hardware/firmware owns a sizeable region within the >>>>> IMEM, named 'modem-tables', containing various packet processing >>>>> configuration data. >>>>> >>>>> It's not actually accessed by the OS, although we have to IOMMU-map it >>>>> with the IPA device, so that presumably the firmware can act upon it. >>>>> >>>>> Allow it as a subnode of IMEM. >>>> >>>> You do not have compatible, so rely on the node name as ABI, which is >>>> fine in general but... I do not see usage of it in the driver. Why do >>>> you need to define modem-tables child then? >>> >>> I don't really *need* the node name to be an ABI. However, the current >>> binding for IMEM only allows a named "pil-reloc@.." subnode (which is >>> consumed via of_find_compatible_node() in the remoteproc subsystem) so I >>> figured the intention was to keep the list of allowed subnodes strictly >>> moderated >>> >>> If you'd prefer a blanket pattern declaration with say '^[a-z]@[0-9a-z]+$' >>> with just a reg requirement inside, I'm fine with that too >> >> No, the problem is that you do not use the ABI here at all. Neither >> would you use the blanket pattern, so my question stays: why adding ABI >> which is not used? > > The subnode I'm trying to introduce is going to be consumed (via a > phandle reference) from the IPA node, as done by the remaining 2 > patches in this series. And that's the problem - I do not see consuming child. I see of_parse_phandle to sram node, not the child. > > I would much prefer not to touch this binding file, but there's an > additionalProperties: false and just adding it as-is results in a: > > arch/arm64/boot/dts/qcom/sc7280-idp.dtb: sram@146a5000: 'modem-tables@1234' does not match any of the regexes: '^pil-reloc@[0-9a-f]+$', 'pinctrl-[0-9]+' > from schema $id: http://devicetree.org/schemas/sram/qcom,imem.yaml# > > Konrad Best regards, Krzysztof
On 18-Feb-26 14:21, Krzysztof Kozlowski wrote:
> On 18/02/2026 13:26, Konrad Dybcio wrote:
>>
>>
>> On 18-Feb-26 12:56, Krzysztof Kozlowski wrote:
>>> On 18/02/2026 12:05, Konrad Dybcio wrote:
>>>> On 2/17/26 9:25 PM, Krzysztof Kozlowski wrote:
>>>>> On Tue, Feb 17, 2026 at 02:30:31PM +0100, Konrad Dybcio wrote:
>>>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>>
>>>>>> The IP Accelerator hardware/firmware owns a sizeable region within the
>>>>>> IMEM, named 'modem-tables', containing various packet processing
>>>>>> configuration data.
>>>>>>
>>>>>> It's not actually accessed by the OS, although we have to IOMMU-map it
>>>>>> with the IPA device, so that presumably the firmware can act upon it.
>>>>>>
>>>>>> Allow it as a subnode of IMEM.
>>>>>
>>>>> You do not have compatible, so rely on the node name as ABI, which is
>>>>> fine in general but... I do not see usage of it in the driver. Why do
>>>>> you need to define modem-tables child then?
>>>>
>>>> I don't really *need* the node name to be an ABI. However, the current
>>>> binding for IMEM only allows a named "pil-reloc@.." subnode (which is
>>>> consumed via of_find_compatible_node() in the remoteproc subsystem) so I
>>>> figured the intention was to keep the list of allowed subnodes strictly
>>>> moderated
>>>>
>>>> If you'd prefer a blanket pattern declaration with say '^[a-z]@[0-9a-z]+$'
>>>> with just a reg requirement inside, I'm fine with that too
>>>
>>> No, the problem is that you do not use the ABI here at all. Neither
>>> would you use the blanket pattern, so my question stays: why adding ABI
>>> which is not used?
>>
>> The subnode I'm trying to introduce is going to be consumed (via a
>> phandle reference) from the IPA node, as done by the remaining 2
>> patches in this series.
>
> And that's the problem - I do not see consuming child. I see
> of_parse_phandle to sram node, not the child.
Ah, I just realized this series has no DT examples..
The property I proposed to add into the IPA node&code is indeed
named 'sram', but my intention is to pass a phandle to the *child*
(similarly like we pass a phandle to the child of a nvmem provider
rather than to the provider device itself)
i.e. the design I envisioned is:
imem@foo {
...
ipa_modem_tables: modem-tables@1234 {
reg = <0x1234 0x1234>;
};
};
...
ipa@foobar {
...
sram = <&ipa_modem_tables>;
}
Konrad
On 18/02/2026 14:32, Konrad Dybcio wrote:
>>>>>
>>>>> If you'd prefer a blanket pattern declaration with say '^[a-z]@[0-9a-z]+$'
>>>>> with just a reg requirement inside, I'm fine with that too
>>>>
>>>> No, the problem is that you do not use the ABI here at all. Neither
>>>> would you use the blanket pattern, so my question stays: why adding ABI
>>>> which is not used?
>>>
>>> The subnode I'm trying to introduce is going to be consumed (via a
>>> phandle reference) from the IPA node, as done by the remaining 2
>>> patches in this series.
>>
>> And that's the problem - I do not see consuming child. I see
>> of_parse_phandle to sram node, not the child.
>
> Ah, I just realized this series has no DT examples..
>
> The property I proposed to add into the IPA node&code is indeed
> named 'sram', but my intention is to pass a phandle to the *child*
> (similarly like we pass a phandle to the child of a nvmem provider
> rather than to the provider device itself)
>
> i.e. the design I envisioned is:
>
> imem@foo {
> ...
>
> ipa_modem_tables: modem-tables@1234 {
> reg = <0x1234 0x1234>;
> };
> };
>
> ...
>
> ipa@foobar {
> ...
>
> sram = <&ipa_modem_tables>;
> }
OK, this explains my questions.
Best regards,
Krzysztof
© 2016 - 2026 Red Hat, Inc.