[PATCH v10 0/3] Fix address translations on MPFS PCIe controller

[Conor Dooley]

Hey folks,

On Fri, Oct 11, 2024 at 03:00:40PM +0100, daire.mcnamara at microchip.com wrote:
> From: Daire McNamara <daire.mcnamara at microchip.com>
> 
> Hi all,
> 
> On Microchip PolarFire SoC (MPFS), the PCIe controller is connected to the
> CPU via one of three Fabric Interface Connectors (FICs).  Each FIC present
> to the CPU complex as 64-bit AXI-M and 64-bit AXI-S.  To preserve
> compatibility with other PolarFire family members, the PCIe controller is
> connected to its encapsulating FIC via a 32-bit AXI-M and 32-bit AXI-S
> interface.
> 
> Each FIC is implemented in FPGA logic and can incorporate logic along its 64-bit
> AXI-M to 32-bit AXI-M chain (including address translation) and, likewise, along
> its 32-bit AXI-S to 64-bit AXI-S chain (again including address translation).
> 
> In order to reduce the potential support space for the PCIe controller in
> this environment, MPFS supports certain reference designs for these address
> translations: reference designs for cache-coherent memory accesses
> and reference designs for non-cache-coherent memory accesses. The precise
> details of these reference designs and associated customer guidelines
> recommending that customers adhere to the addressing schemes used in those
> reference designs are available from Microchip, but the implication for the
> PCIe controller address translation between CPU-space and PCIe-space are:
> 
> For outbound address translation, the PCIe controller address translation tables
> are treated as if they are 32-bit only.  Any further address translation must
> be done in FPGA fabric.
> 
> For inbound address translation, the PCIe controller is configurable for two
> cases:
> * In the case of cache-coherent designs, the base of the AXI-S side of the
>   address translation must be set to 0 and the size should be 4 GiB wide. The
>   FPGA fabric must complete any address translations based on that 0-based
>   address translation.
> * In the case of non-cache coherent designs, the base of AXI-S side of the
>   address translation must be set to 0x8000'0000 and the size shall be 2 GiB
>   wide.  The FPGA fabric must complete any address translation based on that
>   0x80000000 base.
> 
> So, for example, in the non-cache-coherent case, with a device tree property
> that maps an inbound range from 0x10'0000'0000 in PCIe space to 0x10'0000'0000
> in CPU space, the PCIe rootport will translate a PCIe address of 0x10'0000'0000
> to an intermediate 32-bit AXI-S address of 0x8000'0000 and the FIC is
> responsible for translating that intermediate 32-bit AXI-S address of
> 0x8000'0000 to a 64-bit AXI-S address of 0x10'0000'0000.
> 
> And similarly, for example, in the cache-coherent case, with a device tree
> property that maps an inbound range from 0x10'0000'0000 in PCIe space to
> 0x10'0000'0000 in CPU space, the PCIe rootport will translate a PCIe address
> of 0x10'0000'0000 to an intermediate 32-bit AXI-S address of 0x0000'0000 and
> the FIC is responsible for translating that intermediate 32-bit AXI-S address
> of 0x0000'0000 to a 64-bit AXI-S address of 0x10'0000'0000.
> 
> See https://lore.kernel.org/all/20220902142202.2437658-1-daire.mcnamara@microchip.com/T/
> for backstory.
> 
> Changes since v9:
> - Dropped plda_setup_inbound_address_translation() from StarFive driver

Since I had some success bumping the other series for this driver, any
chance of some attention here?
AFAIK, Daire's addressed what's been pointed out by reviewers and
exempted the StarFive driver from overwriting the firmware-set values
with once calculated from DT as they requested.

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20241113/fda9ca62/attachment.sig>