Re: [PATCH v3 1/9] ASoC: dt-bindings: qcom,qaif-cpu: Add binding

[Prasad Kumpatla]

On 8/28/2026 6:12 PM, Srinivas Kandagatla wrote:
> On 8/28/26 1:37 PM, Srinivas Kandagatla wrote:
> > On 8/28/26 9:58 AM, Harendra Gautam wrote:
> > > > > > > > > +#define QAIF_CDC_DMA_VA_TX8  254
> > > > > > > > > +#define QAIF_CDC_DMA_VA_TX9  255
> > > > > > > > > +
> > > > > > > > These DAI IDs exceed the LPASS_MAX_PORT limit, which will cause sound
> > > > > > > > card registration to fail.
> > > > > > > >
> > > > > > > > Check sound/soc/qcom/common.c, as the current indices (246-255) are
> > > > > > > > beyond the supported LPASS port range.
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Rafi.
> > > > > > > Thanks for pointing this out. We can either add the range check for
> > > > > > > min/max QAIF DAI IDs in qcom/common.c or introduce a common helper in
> > > > > > > qcom/common.h to validate the supported DAI IDs across Qualcomm
> > > > > > > platforms.
> > > > > > You should add these ids to
> > > > > > include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h instead to avoid
> > > > > > conflicts with common code.
> > > > > >
> > > > > > --srini
> > > > > Thanks for the suggestion. qcom,q6dsp-lpass-ports.h is specific to Q6
> > > > > DSP/AFE virtual port IDs. Since QAIF is a direct MMIO driver with no
> > > > > Q6 DSP involvement, would adding QAIF IDs there not be misleading?
> > > > These are IDs that will be reused across both dsp and non-dsp solution.
> > > > So it makes more sense to keep it in one single place to allow the
> > > > hardware description (DT) unchanged across different software solutions.
> > > >
> > > >
> > > > > would it be better to update the range check in common.c/common.h to
> > > > > accommodate both LPASS and QAIF DAI ID ranges instead?
> > > > No, that does not make sense because these numbering might conflicting
> > > > with other ports in future.
> > > >
> > > > --srini
> > > Srini, could you please confirm if adding QAIF DAIs to
> > > qcom,q6dsp-lpass-ports.h is acceptable given that it increases
> > > LPASS_MAX_PORT by 56 (from 149 to 205), which indirectly grows
> > > multiple arrays sized by AFE_PORT_MAX and APM_PORT_MAX in other
> > BTW, the dai ids are already added by Prasad
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h?h=next-20260827#n240
> >
> >
> > You should use them.
> Correction, he only added QAIF clk ids, not the dai ids, Not sure why
> dai ids are missing.
>
> That also raises question on how did Prasad test it without the QAIF dai
> ids.

Hi Srini,

Validation on Hawi/Shikra(DSP solutions) was done using the existing LPASS DAI IDs from qcom,q6dsp-lpass-ports.h,
since no dependency of introduce new QAIF-specific DAI IDs for testing.

@Harendra
As I understand it, the hardware interface mapping is almost similar between the DSP and CPU solutions,
May be the no.of interface count be different. Would reusing the existing DAI IDs therefore be sufficient for CPU solution as well?


Thanks,
Prasad

> --srini
> > to your question about increase in size, yes, this is know issue, i have
> > some changes to send which will remove the need of this static array
> > which should fix the concerns.
> >
> > But for now all the hardware dai ids for qualcomm SoCs should be in a
> > single place irrespective of dsp or non dsp solution.
> >
> >
> > --srini
> > > drivers eg below
> > > https://elixir.bootlin.com/linux/v7.2/source/sound/soc/qcom/qdsp6/q6afe-dai.c#L30
> > > https://elixir.bootlin.com/linux/v7.2/source/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c#L21
> > > -Harendra