[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BY5PR02MB652001BCA69400852A361252C7349@BY5PR02MB6520.namprd02.prod.outlook.com>
Date: Fri, 11 Jun 2021 19:33:49 +0000
From: Radhey Shyam Pandey <radheys@...inx.com>
To: Lars-Peter Clausen <lars@...afoo.de>,
"vkoul@...nel.org" <vkoul@...nel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
Michal Simek <michals@...inx.com>
CC: "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
git <git@...inx.com>
Subject: RE: [RFC v2 PATCH 7/7] dmaengine: xilinx_dma: Program interrupt delay
timeout
-----Original Message-----
> From: Lars-Peter Clausen <lars@...afoo.de>
> Sent: Thursday, April 15, 2021 1:03 PM
> To: Radhey Shyam Pandey <radheys@...inx.com>; vkoul@...nel.org;
> robh+dt@...nel.org; Michal Simek <michals@...inx.com>
> Cc: dmaengine@...r.kernel.org; devicetree@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; git
> <git@...inx.com>
> Subject: Re: [RFC v2 PATCH 7/7] dmaengine: xilinx_dma: Program interrupt
> delay timeout
>
> On 4/9/21 7:56 PM, Radhey Shyam Pandey wrote:
> > Program IRQDelay for AXI DMA. The interrupt timeout mechanism causes
> > the DMA engine to generate an interrupt after the delay time period
> > has expired. It enables dmaengine to respond in real-time even though
> > interrupt coalescing is configured. It also remove the placeholder
> > for delay interrupt and merge it with frame completion interrupt.
> > Since by default interrupt delay timeout is disabled this feature
> > addition has no functional impact on VDMA and CDMA IP's.
>
> In my opinion this should not come from the devicetree. This setting is
> application specific and should be configured through a runtime API.
The inclination for reading irq delay from DT was to minimize creating custom
interface for clients. For example - If we use xilinx_vdma_channel_set_config
API in ethernet driver it won't be then generic enough to be hooked to any
other dmaengine client. Any thoughts on it? With DT only limitation is it's
not runtime programmable.
Thanks,
Radhey
>
> For the VDMA there is already xilinx_vdma_channel_set_config() which
> allows to configure the maximum number of IRQs that can be coalesced and
> the IRQ delay. Something similar is probably needed for the AXIDMA.
>
> >
> > Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@...inx.com>
> > ---
> > Changes for v2:
> > - Read irq delay timeout value from DT.
> > - Merge interrupt processing for frame done and delay interrupt.
> > ---
> > drivers/dma/xilinx/xilinx_dma.c | 20 +++++++++++---------
> > 1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_dma.c
> b/drivers/dma/xilinx/xilinx_dma.c
> > index a2ea2d649332..0c0dc9882a01 100644
> > --- a/drivers/dma/xilinx/xilinx_dma.c
> > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > @@ -173,8 +173,10 @@
> > #define XILINX_DMA_MAX_TRANS_LEN_MAX 23
> > #define XILINX_DMA_V2_MAX_TRANS_LEN_MAX 26
> > #define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
> > +#define XILINX_DMA_CR_DELAY_MAX GENMASK(31, 24)
> > #define XILINX_DMA_CR_CYCLIC_BD_EN_MASK BIT(4)
> > #define XILINX_DMA_CR_COALESCE_SHIFT 16
> > +#define XILINX_DMA_CR_DELAY_SHIFT 24
> > #define XILINX_DMA_BD_SOP BIT(27)
> > #define XILINX_DMA_BD_EOP BIT(26)
> > #define XILINX_DMA_BD_COMP_MASK BIT(31)
> > @@ -410,6 +412,7 @@ struct xilinx_dma_tx_descriptor {
> > * @stop_transfer: Differentiate b/w DMA IP's quiesce
> > * @tdest: TDEST value for mcdma
> > * @has_vflip: S2MM vertical flip
> > + * @irq_delay: Interrupt delay timeout
> > */
> > struct xilinx_dma_chan {
> > struct xilinx_dma_device *xdev;
> > @@ -447,6 +450,7 @@ struct xilinx_dma_chan {
> > int (*stop_transfer)(struct xilinx_dma_chan *chan);
> > u16 tdest;
> > bool has_vflip;
> > + u8 irq_delay;
> > };
> >
> > /**
> > @@ -1555,6 +1559,9 @@ static void xilinx_dma_start_transfer(struct
> xilinx_dma_chan *chan)
> > if (chan->has_sg)
> > xilinx_write(chan, XILINX_DMA_REG_CURDESC,
> > head_desc->async_tx.phys);
> > + reg &= ~XILINX_DMA_CR_DELAY_MAX;
> > + reg |= chan->irq_delay << XILINX_DMA_CR_DELAY_SHIFT;
> > + dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
> >
> > xilinx_dma_start(chan);
> >
> > @@ -1877,15 +1884,8 @@ static irqreturn_t xilinx_dma_irq_handler(int
> irq, void *data)
> > }
> > }
> >
> > - if (status & XILINX_DMA_DMASR_DLY_CNT_IRQ) {
> > - /*
> > - * Device takes too long to do the transfer when user
> requires
> > - * responsiveness.
> > - */
> > - dev_dbg(chan->dev, "Inter-packet latency too long\n");
> > - }
> > -
> > - if (status & XILINX_DMA_DMASR_FRM_CNT_IRQ) {
> > + if (status & (XILINX_DMA_DMASR_FRM_CNT_IRQ |
> > + XILINX_DMA_DMASR_DLY_CNT_IRQ)) {
> > spin_lock(&chan->lock);
> > xilinx_dma_complete_descriptor(chan);
> > chan->idle = true;
> > @@ -2802,6 +2802,8 @@ static int xilinx_dma_chan_probe(struct
> xilinx_dma_device *xdev,
> > /* Retrieve the channel properties from the device tree */
> > has_dre = of_property_read_bool(node, "xlnx,include-dre");
> >
> > + of_property_read_u8(node, "xlnx,irq-delay", &chan->irq_delay);
> > +
> > chan->genlock = of_property_read_bool(node, "xlnx,genlock-
> mode");
> >
> > err = of_property_read_u32(node, "xlnx,datawidth", &value);
>
Powered by blists - more mailing lists