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.
