On Tue, Apr 6, 2021 at 9:20 AM Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> 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@xxxxxxxxxx> > > --- > > 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
