Hi,
On Tue, Oct 06, 2020 at 10:15:08AM +0200, Marc Gonzalez wrote:
> On 01/10/2020 12:57, Stanimir Varbanov wrote:
>
> > On 10/1/20 8:57 AM, Manivannan Sadhasivam wrote:
> >
> >> On Thu, Oct 01, 2020 at 12:46:46AM +0300, Stanimir Varbanov wrote:
> >>
[...]
> >>> iommu-map is a standard DT property why we have to parse it manually?
> >>>
> >>
> >> So right now we don't have a way to pass this information from DT. And there
> >> is no IOMMU API to parse the fields also. We need to extract this information
> >> to program the hash tables (BDF, SID) as the mapping between BDF and SID is not
> >> 1:1 in SM8250.
> >
> > We used iommu-map for msm8998 see this commit:
> >
> > b84dfd175c09888751f501e471fdca346f582e06
> > ("arm64: dts: qcom: msm8998: Add PCIe PHY and RC nodes")
> >
> > I also Cc-ed Marc if he knows something more.
>
> My memory is hazy.
>
> I remember an odd quirk in the downstream kernel:
>
> [v1,1/3] PCI: qcom: Setup PCIE20_PARF_BDF_TRANSLATE_N
> http://patchwork.ozlabs.org/project/linux-pci/patch/958ae127-3aa2-6824-c875-e3012644ed3d@xxxxxxx/
>
> Manivannan, are you trying to deal with PCIE20_PARF_BDF_TRANSLATE_N
> or some equivalent register?
>
I'm dealing with PCIE20_PARF_BDF_TO_SID_TABLE_N but I'm not sure how it
relates to PCIE20_PARF_BDF_TRANSLATE_N.
> +Robin, he's the one who helped me figure this stuff out (iommu-map).
> It was in reply to patch 2:
> http://patchwork.ozlabs.org/project/linux-pci/patch/82ab78ee-4a38-4eee-f064-272b6f964f17@xxxxxxx/
>
> In the end, I dropped patch 1 because... everything seemed to work
> without it (?!) (Makes one wonder what it actually does. But qcom
> refused to provide any register documentation, which is idiotic
> because this is DW IP, and they are open-source friendly, IIUC.)
>
Without this patch, PCIe will work on SM8250 but during successive reboots
I started seeing issues which gets fixed by this patch.
Thanks,
Mani
> Regards.
