On Wed, 2019-02-27 at 11:46 +0200, Andy Shevchenko wrote: > [External] > > > +Cc Vinod > > On Wed, Feb 27, 2019 at 11:45 AM Andy Shevchenko > <andy.shevche...@gmail.com> wrote: > > > > On Wed, Feb 27, 2019 at 10:51 AM Alexandru Ardelean > > <alexandru.ardel...@analog.com> wrote: > > > > > > From: Andy Shevchenko <andy.shevche...@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.shevche...@gmail.com> > > > Signed-off-by: Alexandru Ardelean <alexandru.ardel...@analog.com> > > > > Hmm... Usually we don't accept generic API without users. > > Do you have any use case in mind?
Yep: this one: https://patchwork.kernel.org/patch/10814527/ But, I can rework this patch to work without the helper. > > > > > 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. > > I don't think I managed to follow [or find] the full length of that discussion. Or, the conclusion wasn't that obvious to me, from what I found. I assumed this may have been dropped/forgotten. In any case, I am fine with just reworking. > > 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
