Re: [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality

From: Robin Murphy
Date: Mon Mar 21 2022 - 16:06:51 EST


On 2022-03-21 19:21, Marc Zyngier wrote:
On Mon, 21 Mar 2022 18:03:27 +0000,
Rob Herring <robh@xxxxxxxxxx> wrote:

On Mon, Mar 21, 2022 at 11:36 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:

On Mon, 21 Mar 2022 15:17:34 +0000,
Rob Herring <robh@xxxxxxxxxx> wrote:

On Mon, Mar 21, 2022 at 5:49 AM Marc Zyngier <maz@xxxxxxxxxx> 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.