From: Vinod Koul <vinod.koul@intel.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: dmaengine@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Modifying sg_dma_len(sg)?
Date: Thu, 21 May 2015 21:23:46 +0530 [thread overview]
Message-ID: <20150521155346.GQ3140@localhost> (raw)
In-Reply-To: <CAMuHMdUjNGnYUPALgMCmy0EhpwYt8f3Ggv7PV+zYMvsmTSiq5w@mail.gmail.com>
On Tue, May 19, 2015 at 08:51:54AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 19, 2015 at 6:01 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> > On Fri, May 15, 2015 at 03:46:27PM +0200, Geert Uytterhoeven wrote:
> >
> > am ccing LKML, perhaps this needs wider discussion..
> >
> >> Several drivers reuse mapped scatterlists, and modify sg_dma_len(sg) to
> >> match the actual number of bytes they want to transfer.
> >>
> >> Hence during driver shutdown, dma_unmap_sg() is called with a scatterlist
> >> that has modified lengths, compared to the original passed to dma_map_sg().
> >> If CONFIG_DMA_API_DEBUG=y, this causes warnings like:
> >>
> >> WARNING: CPU: 0 PID: 20 at lib/dma-debug.c:1103 check_unmap+0x24c/0x85c()
> >> rcar-dmac e6700000.dma-controller: DMA-API: device driver frees
> >> DMA memory with different size [device address=0x000000006e15f000]
> >> [map size=4096 bytes] [unmap size=3 bytes]
> >>
> >> The warning can be silenced by restoring the original sg_dma_len() just before
> >> calling dma_unmap_sg(), but it looks like no driver actually does that.
> > Right, but should the drivers map with one length and then modify the
> > length later on, why not map only the size that is required...
>
> This is mostly done in serial drivers, which set up an initial mapping, and
> reuse it with different lengths, depending on the amount of data to transfer
> at that time.
>
> > So driver should always unmap and remap with the right length whenever it is
> > required to change the length. Perhaps a dma_remap_sg() API to do so
> > properly.
> >
> > I do not think modifying length directly should be encouraged...
>
> In cases where there's only a single segment, I think it's better to use
> dma_map_single() instead of dma_map_sg().
> Then the actual length to transfer can easily be passed to
> dmaengine_prep_slave_single(), right?
Sounds right to me
--
~Vinod
prev parent reply other threads:[~2015-05-21 15:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAMuHMdXbxavw3Gw9BbuwVPEFgsY1AOPmRVNq51Xu9_aMrPNZbw@mail.gmail.com>
2015-05-19 4:01 ` Modifying sg_dma_len(sg)? Vinod Koul
2015-05-19 6:51 ` Geert Uytterhoeven
2015-05-21 15:53 ` Vinod Koul [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150521155346.GQ3140@localhost \
--to=vinod.koul@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.