Messages in this thread | | | Date | Mon, 21 Mar 2022 20:06:40 +0000 | Subject | Re: [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality | From | Robin Murphy <> |
| |
On 2022-03-21 19:21, Marc Zyngier wrote: > On Mon, 21 Mar 2022 18:03:27 +0000, > Rob Herring <robh@kernel.org> wrote: >> >> On Mon, Mar 21, 2022 at 11:36 AM Marc Zyngier <maz@kernel.org> wrote: >>> >>> On Mon, 21 Mar 2022 15:17:34 +0000, >>> Rob Herring <robh@kernel.org> wrote: >>>> >>>> On Mon, Mar 21, 2022 at 5:49 AM Marc Zyngier <maz@kernel.org> wrote: >>>>> >>>> For XGene-1, I'd still like to understand what the issue is. Reverting >>>> the first fix and fixing 'dma-ranges' should have fixed it. I need a >>>> dump of how the IB registers are initialized in both cases. I'm not >>>> saying changing 'dma-ranges' in the firmware is going to be required >>>> here. There's a couple of other ways we could fix that without a >>>> firmware change, but first I need to understand why it broke. >>> >>> Reverting 6dce5aa59e0b was enough for me, without changing anything >>> else. >> >> Meaning c7a75d07827a didn't matter for you. I'm not sure that it would. >> >> Can you tell me what 'dma-ranges' contains on your system? > > Each pcie node (all 5 of them) has: > > dma-ranges = <0x42000000 0x80 0x00 0x80 0x00 0x00 0x80000000 > 0x42000000 0x00 0x00 0x00 0x00 0x80 0x00>;
Hmm, is there anyone other than iommu-dma who actually depends on the resource list being sorted in ascending order of bus address? I recall at the time I pushed for creating the list in sorted order as it was the simplest and most efficient option, but there's no technical reason we couldn't create it in as-found order and defer the sorting until iova_reserve_pci_windows() (at worst that could even operate on a temporary copy if need be). It's just more code, which didn't need to exist without a good reason, but if this is one then exist it certainly may.
Cheers, Robin.
| |