public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	linux-riscv@lists.infradead.org,
	Paul Walmsley <paul.walmsley@sifive.com>,
	daire.mcnamara@microchip.com, robh@kernel.org,
	krzk+dt@kernel.org, samuel.holland@sifive.com,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v1 0/5] PolarFire SoC Icicle Reference Design PCIe ?support?/fixes
Date: Wed, 3 Jul 2024 21:15:53 +0100	[thread overview]
Message-ID: <20240703-girdle-grandly-c6495236fa72@spud> (raw)
In-Reply-To: <mhng-011d3bea-b607-4df2-a65c-7b08547cb85e@palmer-ri-x1c9>

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

On Wed, Jul 03, 2024 at 01:09:43PM -0700, Palmer Dabbelt wrote:
> On Mon, 10 Jun 2024 04:09:12 PDT (-0700), Conor Dooley wrote:
> > Hey all,
> > 
> > Here's some patches that add an Erratum to enable non-coherent DMA
> > support for PolarFire SoC. By nature of being an FPGA, and due to the
> > PCIe root ports being only 32-bit capable, many bitstreams configure the
> > FPGA fabric such that peripherals in the fabric become non-coherent. The
> > PCIe root ports on PolarFire SoC are connected to the core-complex via
> > the fabric, and therefore can be (and regularly are) made DMA
> > non-coherent. The Icicle Kit Reference Design has been configuring the
> > PCIe root port in this manner since late 2022 and in a way unsupported
> > by mainline since earlier that year. Adding this non-coherent DMA
> > support makes PCIe functional on those FPGA designs. Daire did almost all
> > the work to figure out how to support these kinds of designs, and this
> > series depends on his patches to introduce the required dma-ranges
> > handling for the root port driver:
> > https://lore.kernel.org/linux-pci/20240531085333.2501399-1-daire.mcnamara@microchip.com/
> > 
> > The final patch depends on:
> > https://lore.kernel.org/linux-pci/20240527-slather-backfire-db4605ae7cd7@wendy/
> > 
> > I'm not sure if an Erratum is really the right way to go about doing
> > this, but I didn't want to make ARCH_MICROCHIP depend on NONPORTABLE.
> > An alternative would be to add a menu under drivers/soc like Renesas
> > does and allow it to be toggled as an option there instead.
> 
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> 
> if you want to take this via some other tree.

Yeah, I was expecting to take it myself but hadn't gone fishing for an
ack because the PCI parts haven't landed yet & the copy in my k.org tree
had a KISMET issue reported against it.

> I don't see any issue calling it an erratum, if it lets us keep building
> generic kernels for these systems that seems like a good enough agrument to
> me.

Cool :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2024-07-03 20:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10 11:09 [PATCH v1 0/5] PolarFire SoC Icicle Reference Design PCIe ?support?/fixes Conor Dooley
2024-06-10 11:09 ` [PATCH v1 1/5] cache: ccache: allow building for PolarFire Conor Dooley
2024-06-12  9:23   ` Emil Renner Berthing
2024-06-10 11:09 ` [PATCH v1 2/5] cache: ccache: add mpfs to nonstandard cache ops list Conor Dooley
2024-06-12  9:23   ` Emil Renner Berthing
2024-06-10 11:09 ` [PATCH v1 3/5] RISC-V: Add an MPFS erratum for PCIe Conor Dooley
2024-06-12  9:29   ` Emil Renner Berthing
2024-06-10 11:09 ` [PATCH v1 4/5] riscv: dts: microchip: modify memory map & add dma-ranges for pcie on icicle Conor Dooley
2024-06-10 11:09 ` [PATCH v1 5/5] riscv: dts: microchip: update pcie reg properties Conor Dooley
2024-06-10 11:16 ` [PATCH v1 0/5] PolarFire SoC Icicle Reference Design PCIe ?support?/fixes Conor Dooley
2024-06-10 19:55 ` Rob Herring (Arm)
2024-06-10 21:28   ` Conor Dooley
2024-07-03 20:09 ` Palmer Dabbelt
2024-07-03 20:15   ` Conor Dooley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240703-girdle-grandly-c6495236fa72@spud \
    --to=conor@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=daire.mcnamara@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh@kernel.org \
    --cc=samuel.holland@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox