Hey folks, Has this patchset fallen through the cracks? Cheers, Conor. On Wed, Nov 13, 2024 at 11:50:44AM +0000, Conor Dooley wrote: > On Fri, Oct 11, 2024 at 03:00:40PM +0100, daire.mcnamara@xxxxxxxxxxxxx wrote: > > From: Daire McNamara <daire.mcnamara@xxxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxxx/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.
Attachment:
signature.asc
Description: PGP signature
