Messages in this thread | | | From | Andy Shevchenko <> | Date | Wed, 27 Feb 2019 11:46:11 +0200 | Subject | Re: [PATCH] lib/scatterlist: introduce sg_nents_for_dma() helper |
| |
+Cc Vinod
On Wed, Feb 27, 2019 at 11:45 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Feb 27, 2019 at 10:51 AM Alexandru Ardelean > <alexandru.ardelean@analog.com> wrote: > > > > From: Andy Shevchenko <andy.shevchenko@gmail.com> > > > > Sometimes the user needs to split each entry on the mapped scatter list > > due to DMA length constrains. This helper returns a number of entities > > assuming that each of them is not bigger than supplied maximum length. > > > > Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> > > Hmm... Usually we don't accept generic API without users. > Do you have any use case in mind? > > > Patch was sent in 2016 initially to the DMA engine sub-system. > > Link: > > https://patchwork.kernel.org/patch/9389821/ > > This was part of a larger series: > > https://patchwork.kernel.org/project/linux-dmaengine/list/?q=sg_nents_for_dma&archive=both&series=&submitter=&delegate=&state=* > > > > I'm not sure if this is supposed to go into DMAEngine or lib/scatterlist. > > It doesn't look like lib/scatterlist is managed by DMAEngine, so (by using > > the `get_maintainers.pl` script) I'm sending this patch to this group of > > parties. > > The problem the patch tried to solve is much deeper and correct > solution should be more generic, i.e. > each channel should provide a set of parameters, such as DMA segment > size, to the users (via DMA engine API) and users should prepare the > SG list according to the limits of the channel. > In that case we don't need to re-split/re-allocate given SG list at > all, which would simplify DMA slave drivers and their users. > > We discussed this topic back in 2016 with Vinod on LPC, but seems it's > not critical to solve. My case is to improve DMA performance for 8250 > UART. > > -- > With Best Regards, > Andy Shevchenko
-- With Best Regards, Andy Shevchenko
| |