RE: [PATCH 0/2] net: wwan: qcom_bam_dmux: Alloc RX buffers as a single coherent block

Posted by Jagielski, Jedrzej 1 week, 4 days ago

From: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com> 
Sent: Tuesday, July 14, 2026 7:33 AM

>On platforms where the modem DMAs into the BAM-DMUX RX data buffers and
>the XPU (eXternal Protection Unit) enforces per-region access control,
>each individually DMA-mapped RX buffer consumes an XPU resource group.
>With only ~16 groups available on Shikra (mDSP, VMID 43 / NAV), the
>per-buffer mappings exhaust the table and inbound transfers fault.
>
>This series adds a qcom,shikra-bam-dmux compatible and have the driver
>select QCOM_SCM_VMID_NAV internally via that compatible's match data.
>When matched, the driver allocates all RX buffers as a single
>contiguous coherent block and SCM-assigns it to HLOS plus the VMID
>once at probe, consuming one XPU resource group instead of many.
>
>Platforms that do not use the qcom,shikra-bam-dmux compatible are
>unaffected: the existing per-buffer dma_map_single() path is
>unchanged.
>
>Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>---
>Vishnu Santhosh (2):
>      dt-bindings: net: qcom,bam-dmux: Add qcom,shikra-bam-dmux compatible
>      net: wwan: qcom_bam_dmux: Alloc RX buffers as a single coherent block
>
> .../devicetree/bindings/net/qcom,bam-dmux.yaml     |   8 +-
> drivers/net/wwan/Kconfig                           |   1 +
> drivers/net/wwan/qcom_bam_dmux.c                   | 134 +++++++++++++++++++--
> 3 files changed, 132 insertions(+), 11 deletions(-)
>---
>base-commit: 3b029c035b34bbc693405ddf759f0e9b920c27f1
>change-id: 20260714-qcom-bam-dmux-vmid-ext-d9289db310c1
>
>Best regards,
>-- 
>Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

Hi Vishnu
you need to specify target tree, net-next for this series i believe
please refer to[1]

[1]
https://docs.kernel.org/process/maintainer-netdev.html#indicating-target-tree

Re: [PATCH 0/2] net: wwan: qcom_bam_dmux: Alloc RX buffers as a single coherent block

Posted by Vishnu Santhosh 1 week, 4 days ago

On 14-07-2026 01:23 pm, Jagielski, Jedrzej wrote:
> From: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> Sent: Tuesday, July 14, 2026 7:33 AM
>
>> On platforms where the modem DMAs into the BAM-DMUX RX data buffers and
>> the XPU (eXternal Protection Unit) enforces per-region access control,
>> each individually DMA-mapped RX buffer consumes an XPU resource group.
>> With only ~16 groups available on Shikra (mDSP, VMID 43 / NAV), the
>> per-buffer mappings exhaust the table and inbound transfers fault.
>>
>> This series adds a qcom,shikra-bam-dmux compatible and have the driver
>> select QCOM_SCM_VMID_NAV internally via that compatible's match data.
>> When matched, the driver allocates all RX buffers as a single
>> contiguous coherent block and SCM-assigns it to HLOS plus the VMID
>> once at probe, consuming one XPU resource group instead of many.
>>
>> Platforms that do not use the qcom,shikra-bam-dmux compatible are
>> unaffected: the existing per-buffer dma_map_single() path is
>> unchanged.
>>
>> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>> ---
>> Vishnu Santhosh (2):
>>       dt-bindings: net: qcom,bam-dmux: Add qcom,shikra-bam-dmux compatible
>>       net: wwan: qcom_bam_dmux: Alloc RX buffers as a single coherent block
>>
>> .../devicetree/bindings/net/qcom,bam-dmux.yaml     |   8 +-
>> drivers/net/wwan/Kconfig                           |   1 +
>> drivers/net/wwan/qcom_bam_dmux.c                   | 134 +++++++++++++++++++--
>> 3 files changed, 132 insertions(+), 11 deletions(-)
>> ---
>> base-commit: 3b029c035b34bbc693405ddf759f0e9b920c27f1
>> change-id: 20260714-qcom-bam-dmux-vmid-ext-d9289db310c1
>>
>> Best regards,
>> -- 
>> Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> Hi Vishnu
> you need to specify target tree, net-next for this series i believe
> please refer to[1]
>
> [1]
> https://docs.kernel.org/process/maintainer-netdev.html#indicating-target-tree
>
Thanks Jedrzej. I will address the comments and will send out the next revision
specifying the target tree as net-next.

Thanks,
Vishnu