[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190926171801.GM3824@vkoul-mobl>
Date: Thu, 26 Sep 2019 10:18:01 -0700
From: Vinod Koul <vkoul@...nel.org>
To: Radhey Shyam Pandey <radheys@...inx.com>
Cc: "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
Michal Simek <michals@...inx.com>,
"nick.graumann@...il.com" <nick.graumann@...il.com>,
"andrea.merello@...il.com" <andrea.merello@...il.com>,
Appana Durga Kedareswara Rao <appanad@...inx.com>,
"mcgrof@...nel.org" <mcgrof@...nel.org>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next 3/8] dmaengine: xilinx_dma: Introduce
xilinx_dma_get_residue
On 26-09-19, 05:52, Radhey Shyam Pandey wrote:
> > > + * VDMA and simple mode do not support residue reporting, so the
> > > + * residue field will always be 0.
> > > + */
> > > + if (chan->xdev->dma_config->dmatype == XDMA_TYPE_VDMA ||
> > !chan->has_sg)
> > > + return residue;
> >
> > why not check this in status callback?
> Assuming we mean to move vdma and non-sg check to xilinx_dma_tx_status.
> Just a thought- Keeping this check in xilinx_dma_get_residue provides
> an abstraction and caller can simply call this func with knowing about
> IP config specific residue calculation. Considering this point does it
> looks ok ?
well you are checking either way, so calling the lower level function
only when you need it makes more sense!
--
~Vinod
Powered by blists - more mailing lists