On Mon, Dec 10, 2018 at 05:12:24PM +0800, Wesley Sheng wrote: > MRPC normal mode requires the host to read the MRPC command status and > output data from BAR. This results in high latency responses from the > Memory Read TLP and potential Completion Timeout (CTO). > > MRPC DMA mode implementation includes: > Macro definitions for registers and data structures corresponding to > MRPC DMA mode. > > Add module parameter use_dma_mrpc to select between MRPC DMA mode and > MRPC normal mode. > > Add MRPC mode functionality to: > * Retrieve MRPC DMA mode version > * Allocate DMA buffer, ISR registration, and enable DMA function during > initialization > * Check MRPC execution status and collect execution results from DMA buffer > * Release DMA buffer and disable DMA function when unloading module > > MRPC DMA mode is a new feature of firmware and the driver will fall back > to MRPC normal mode if there is no support in the legacy firmware. > > Include <linux/io-64-nonatomic-lo-hi.h> so that readq/writeq is replaced > by two readl/writel on systems that do not support it. > > Signed-off-by: Wesley Sheng <wesley.sheng@xxxxxxxxxxxxx> > Reviewed-by: Logan Gunthorpe <logang@xxxxxxxxxxxx> > static void init_pff(struct switchtec_dev *stdev) > @@ -1294,6 +1367,19 @@ static int switchtec_init_pci(struct switchtec_dev *stdev, > > pci_set_drvdata(pdev, stdev); > > + if (!use_dma_mrpc) > + return 0; > + > + if (!(ioread32(&stdev->mmio_mrpc->dma_ver) ? true : false)) > + return 0; This is ... harder to decode than necessary. It's obvious that the intent is to return if the adapter firmware doesn't support DMA, but I lost interest before I could verify that it works as intended. Bjorn
