Re: [PATCH v3 6/6] bus: mhi: host: pci_generic: Support independent DMA mask for VFs

[Vivek Pernamitta]

On 9/5/2025 8:33 PM, Manivannan Sadhasivam wrote:
> On Thu, Aug 21, 2025 at 06:25:38PM GMT, Vivek.Pernamitta@xxxxxxxxxxx wrote:
> > From: Vivek Pernamitta <quic_vpernami@xxxxxxxxxxx>
> >
> > Certain devices like QDU100 bootloader support only up to a 32-bit DMA
> > address range. However, Virtual Functions (VFs) are enabled only after
> > the device enters Mission Mode and can support higher DMA address ranges
> > (up to 40 bits).
> >
> > A 32-bit DMA mask limits addressable space to 4GiB, which is insufficient
> > for data transfer requirements over VFs on platforms like QDU100. These
> > devices require larger memory regions to be mapped for efficient VF
> > operation.
> >
> > To address this, configure `dma_mask` independently for Physical Functions
> > (PFs) and Virtual Functions (VFs), allowing VFs to use higher DMA mask
> > values where supported.
> >
> > As per PCIe SR-IOV specification (rev 0.9, Section 1), VFs are capable of
> > handling resources associated with the main data movement of the Function.
> > > > This change ensures compatibility with bootloaders that have limited DMA
> > capabilities while enabling full VF functionality once the device reaches
> > Mission Mode.
>
> Compatibility is with the existing non-SR-IOV devices, isn't it? How does
> bootloader comes into picture for them?
Set "vf_dma_data_width" explicitly for SR-IOV devices where VFs support
64-bit DMA but PFs do not. For non-SRIOV devices, this flag should 
remain dma_data_width unset and defaults to zero.  If both bootloader
and HLOS support the  same DMA width and for non-SRIOV device, set the
flag "dma_data_width" alone to the maximum supported bits to ensure
compatibility and performance.> - Mani
>