From: Alan Stern on
This is addressed to James Bottomley as he is the author of
Documentation/DMA-API.txt, but anyone else who can contribute is
invited to do so.

Suppose a scatter-gather transfer with multiple scatterlist elements
has been mapped via dma_map_sg(). Is it then valid to call
dma_sync_sg_for_cpu() with the "sg" argument pointing to one of the
mapped scatterlist elements (not necessarily the first one) and the
"nelems" argument set to 1?

Thanks,

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on
On Mon, 2010-03-15 at 17:30 -0400, Alan Stern wrote:
> This is addressed to James Bottomley as he is the author of
> Documentation/DMA-API.txt, but anyone else who can contribute is
> invited to do so.
>
> Suppose a scatter-gather transfer with multiple scatterlist elements
> has been mapped via dma_map_sg(). Is it then valid to call
> dma_sync_sg_for_cpu() with the "sg" argument pointing to one of the
> mapped scatterlist elements (not necessarily the first one) and the
> "nelems" argument set to 1?

It's not the design of the API, but I'm guessing, given the way the API
works on most arch's that it will work. However, if you just want a
single element sync'd, won't dma_sync_single_for_cpu do that
transparently (as in just feed in the address and length from the sg
list), without mucking with the sg API?

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on
On Mon, 15 Mar 2010 17:30:19 -0400 (EDT)
Alan Stern <stern(a)rowland.harvard.edu> wrote:

> This is addressed to James Bottomley as he is the author of
> Documentation/DMA-API.txt, but anyone else who can contribute is
> invited to do so.
>
> Suppose a scatter-gather transfer with multiple scatterlist elements
> has been mapped via dma_map_sg(). Is it then valid to call
> dma_sync_sg_for_cpu() with the "sg" argument pointing to one of the
> mapped scatterlist elements (not necessarily the first one) and the
> "nelems" argument set to 1?

As James said, probably it works. As long as passed scatterlist
elements points to mapped regions, it works.

However, I think that the latest DMA-API.txt makes it clear that only
dma_sync_single_for_{cpu|device} supports a partial sync. So it's not
recommended, I guess.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Mon, 15 Mar 2010, James Bottomley wrote:

> On Mon, 2010-03-15 at 17:30 -0400, Alan Stern wrote:
> > This is addressed to James Bottomley as he is the author of
> > Documentation/DMA-API.txt, but anyone else who can contribute is
> > invited to do so.
> >
> > Suppose a scatter-gather transfer with multiple scatterlist elements
> > has been mapped via dma_map_sg(). Is it then valid to call
> > dma_sync_sg_for_cpu() with the "sg" argument pointing to one of the
> > mapped scatterlist elements (not necessarily the first one) and the
> > "nelems" argument set to 1?
>
> It's not the design of the API, but I'm guessing, given the way the API
> works on most arch's that it will work. However, if you just want a
> single element sync'd, won't dma_sync_single_for_cpu do that
> transparently (as in just feed in the address and length from the sg
> list), without mucking with the sg API?

On Tue, 16 Mar 2010, FUJITA Tomonori wrote:

> As James said, probably it works. As long as passed scatterlist
> elements points to mapped regions, it works.
>
> However, I think that the latest DMA-API.txt makes it clear that only
> dma_sync_single_for_{cpu|device} supports a partial sync. So it's not
> recommended, I guess.

What the documentation actually says about the dma_sync_* functions is:

All the parameters must be the same as those passed into the
single mapping API.

So it isn't clear that dma_sync_sg_for_cpu(dev, sg, 1, dir) can be used
on a mapping created by dma_map_sg(dev, sg, n, dir), and it isn't
clear that dma_sync_single_for_cpu() can be used on a mapping created
by dma_map_sg().

But if you guys say it will work, I'll go ahead and use
dma_sync_single_for_cpu().

Thanks,

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on
On Tue, 16 Mar 2010 10:30:47 -0400 (EDT)
Alan Stern <stern(a)rowland.harvard.edu> wrote:

> On Mon, 15 Mar 2010, James Bottomley wrote:
>
> > On Mon, 2010-03-15 at 17:30 -0400, Alan Stern wrote:
> > > This is addressed to James Bottomley as he is the author of
> > > Documentation/DMA-API.txt, but anyone else who can contribute is
> > > invited to do so.
> > >
> > > Suppose a scatter-gather transfer with multiple scatterlist elements
> > > has been mapped via dma_map_sg(). Is it then valid to call
> > > dma_sync_sg_for_cpu() with the "sg" argument pointing to one of the
> > > mapped scatterlist elements (not necessarily the first one) and the
> > > "nelems" argument set to 1?
> >
> > It's not the design of the API, but I'm guessing, given the way the API
> > works on most arch's that it will work. However, if you just want a
> > single element sync'd, won't dma_sync_single_for_cpu do that
> > transparently (as in just feed in the address and length from the sg
> > list), without mucking with the sg API?
>
> On Tue, 16 Mar 2010, FUJITA Tomonori wrote:
>
> > As James said, probably it works. As long as passed scatterlist
> > elements points to mapped regions, it works.
> >
> > However, I think that the latest DMA-API.txt makes it clear that only
> > dma_sync_single_for_{cpu|device} supports a partial sync. So it's not
> > recommended, I guess.
>
> What the documentation actually says about the dma_sync_* functions is:
>
> All the parameters must be the same as those passed into the
> single mapping API.

It's true to dma_sync_sg_for_*. You can see there:

With the sync_single API, you can use dma_handle and size parameters
that aren't identical to those passed into the single mapping API to
do a partial sync.

dma_sync_single_for_* can do a partial sync but dma_sync_sg_for_*
doesn't support a partial sync.


> So it isn't clear that dma_sync_sg_for_cpu(dev, sg, 1, dir) can be used
> on a mapping created by dma_map_sg(dev, sg, n, dir),

You should not do (though it might work).

> and it isn't
> clear that dma_sync_single_for_cpu() can be used on a mapping created
> by dma_map_sg().

You should not do (though it might work).


> But if you guys say it will work, I'll go ahead and use
> dma_sync_single_for_cpu().
>

Well, it's undocumented. It might work but might not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/