Re: [PATCH v3 1/2] PCI: xilinx-nwl: Enable coherent PCIe DMA traffic using CCI

From: Rob Herring <robh@kernel.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>,
	Robin Murphy <robin.murphy@arm.com>,
	PCI <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v3 1/2] PCI: xilinx-nwl: Enable coherent PCIe DMA traffic using CCI
Date: Tue, 6 Apr 2021 15:34:56 -0500	[thread overview]
Message-ID: <CAL_Jsq+TKsZpHsjm0dBVTGdCMeDYLeOxqFBmNhuM_-xLizX6Fg@mail.gmail.com> (raw)
In-Reply-To: <20210406142004.GA25082@lpieralisi>

On Tue, Apr 6, 2021 at 9:20 AM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> [+ Rob, Robin]
>
> On Mon, Feb 22, 2021 at 02:17:31PM +0530, Bharat Kumar Gogada wrote:
> > Add support for routing PCIe DMA traffic coherently when
> > Cache Coherent Interconnect (CCI) is enabled in the system.
> > The "dma-coherent" property is used to determine if CCI is enabled
> > or not.
> > Refer to https://developer.arm.com/documentation/ddi0470/k/preface
> > for the CCI specification.
> >
> > Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
> > ---
> >  drivers/pci/controller/pcie-xilinx-nwl.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
> > index 07e36661bbc2..8689311c5ef6 100644
> > --- a/drivers/pci/controller/pcie-xilinx-nwl.c
> > +++ b/drivers/pci/controller/pcie-xilinx-nwl.c
> > @@ -26,6 +26,7 @@
> >
> >  /* Bridge core config registers */
> >  #define BRCFG_PCIE_RX0                       0x00000000
> > +#define BRCFG_PCIE_RX1                       0x00000004
> >  #define BRCFG_INTERRUPT                      0x00000010
> >  #define BRCFG_PCIE_RX_MSG_FILTER     0x00000020
> >
> > @@ -128,6 +129,7 @@
> >  #define NWL_ECAM_VALUE_DEFAULT               12
> >
> >  #define CFG_DMA_REG_BAR                      GENMASK(2, 0)
> > +#define CFG_PCIE_CACHE                       GENMASK(7, 0)
> >
> >  #define INT_PCI_MSI_NR                       (2 * 32)
> >
> > @@ -675,6 +677,11 @@ static int nwl_pcie_bridge_init(struct nwl_pcie *pcie)
> >       nwl_bridge_writel(pcie, CFG_ENABLE_MSG_FILTER_MASK,
> >                         BRCFG_PCIE_RX_MSG_FILTER);
> >
> > +     /* This routes the PCIe DMA traffic to go through CCI path */
> > +     if (of_dma_is_coherent(dev->of_node))
> > +             nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, BRCFG_PCIE_RX1) |
> > +                               CFG_PCIE_CACHE, BRCFG_PCIE_RX1);
> > +
>
> This is weird. FW is telling us that the RC is DMA coherent hence
> we have to program the RC so that it is indeed DMA coherent.
>
> It does not make much sense. I think this is a set-up that should be
> programmed by firmware and reported to the kernel via the standard
> "dma-coherent" property. The kernel can read that register to check the
> HW configuration complies with the DT property.
>
> I'd like to get RobH/Robin thoughts on this before proceeding - they
> have more insights about the DT dma-coherent usage/bindings and
> expected behaviour.

Without the above change or firmware setup, a DT with 'dma-coherent'
and a kernel without it will be broken because the above register
won't be configured, yet we'll be using coherent DMA ops.

Originally when I added 'dma-coherent' (for Calxeda h/w), I had to do
all the coherent path setup in the kernel to ensure the h/w setup was
in-sync with the DMA ops. Nowadays, it's probably safe to assume the
OS has coherent support, but can we say that for sure for all OSs?

It also is going to depend if this register survives resets of the
module. If not, then it needs to be done in the kernel.

Rob