Re: [PATCH] arm64: dts: qcom: shikra: Add qcom,vmid to BAM-DMA node

On 05-08-2026 09:08 am, Bjorn Andersson wrote:
> On Tue, Aug 04, 2026 at 09:49:18PM +0530, Vishnu Santhosh wrote:
>> On 31-07-2026 02:49 am, Bjorn Andersson wrote:
>>> On Tue, Jul 14, 2026 at 02:01:53PM +0530, Vishnu Santhosh wrote:
>>>> On the Qualcomm Shikra SoC the mDSP (VMID 43 / QCOM_SCM_VMID_NAV) is
>>>> the AXI master for BAM descriptor FIFO accesses. The XPU enforces
>>>> per-region access control; without an SCM assignment granting NAV
>>>> access, the first DMA transfer triggers an XPU violation.
>>>>
>>> I'm a bit puzzled about your plan here.
>>>
>>> You posted this on July 14th, that's 3 days after I asked you to rebase
>>> patch [1]. This patch literally says that [1] is broken and untested.
>> The XPU violation itself wasn't visible against the base bam-dmux
>> enablement alone. It only showed up once the access-control policy was
>> enabled, which happened to land close to when [1] was posted upstream.
>> That's why this series followed so soon after.
>>
> Are you saying that none of the shikra patches were tested with
> access-control enabled?!
>
> Regards,
> Bjorn

Correct for [1] because access-control wasn't enabled in the Shikra build
used at that point. It was enabled afterward, which is when this XPU
violation was found.

Some context on why this issue is Shikra-specific: A2 BAM (used by
BAM-DMUX) sits in the secure domain on this SoC and doesn't support IOMMU
Stage-2 translation, so there's no IOMMU domain that can be attached
to it. The XPU is the only protection mechanism available. On past
targets like msm8916, the same A2 BAM configuration never surfaced
this class of issue, so it wasn't something we'd seen before.

We are currently discussing with Stephen on the SCM calls on bam driver side
to fix the violation. Once concluded, will verify and fold the dt changes
together with [1].


Thanks,
Vishnu