query about dma_sync_*_for_cpu and direction=TO_DEVICE

[Vineet Gupta]

Hi,

I've read dma mapping and dma-api kernel documentation as well as the
DMA API change at http://lwn.net/Articles/75780/ which describes fork
of dma_sync_* to dma_sync_*_for_cpu and dma_sync_*_for_device.

It seems the names of API are self explanatory and direction parameter
is not needed (except for handling BIDIRECTIONAL case).
So for e.g. If software wants to access the dma buffer, post DMA, it
will invoke dma_sync_single_for_cpu so that non-coherent arch can
invalidate the corresponding cache lines. This implies FROM_DEVICE
semantics. Does that mean dma_sync_single_for_cpu invoked with
direction = TO_DEVICE should return error.
Corollary case is when dma_sync_single_for_device is invoked with
direction = FROM_DEVICE, is tha error too (buggy driver).

The architecture for which I'm implementing DMA coherency APIs has
non-coherent DMA memory and logical-to-bus mapping / DMA bounce is not
a issue.

Thanks,
Vineet

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ***@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

[Peter Teoh]

Post by Vineet Gupta
Hi,
I've read dma mapping and dma-api kernel documentation as well as the
DMA API change at http://lwn.net/Articles/75780/ which describes fork
of dma_sync_* to dma_sync_*_for_cpu and dma_sync_*_for_device.
It seems the names of API are self explanatory and direction parameter
is not needed (except for handling BIDIRECTIONAL case).
So for e.g. If software wants to access the dma buffer, post DMA, it
will invoke dma_sync_single_for_cpu so that non-coherent arch can
invalidate the corresponding cache lines. This implies FROM_DEVICE
semantics. Does that mean dma_sync_single_for_cpu invoked with
direction = TO_DEVICE should return error.

drivers/ieee1394/sbp2.c:

static int sbp2_create_command_orb(struct sbp2_lu *lu,
struct sbp2_command_info *cmd,
struct scsi_cmnd *SCpnt)
{
dma_sync_single_for_cpu(dmadev, cmd->command_orb_dma,
sizeof(struct sbp2_command_orb), DMA_TO_DEVICE);

???

Post by Vineet Gupta
Corollary case is when dma_sync_single_for_device is invoked with
direction = FROM_DEVICE, is tha error too (buggy driver).
The architecture for which I'm implementing DMA coherency APIs has
non-coherent DMA memory and logical-to-bus mapping / DMA bounce is not
a issue.
Thanks,
Vineet

[Vineet Gupta]

Post by Peter Teoh

Post by Vineet Gupta
Hi,
I've read dma mapping and dma-api kernel documentation as well as the
DMA API change at http://lwn.net/Articles/75780/ which describes fork
of dma_sync_* to dma_sync_*_for_cpu and dma_sync_*_for_device.
It seems the names of API are self explanatory and direction parameter
is not needed (except for handling BIDIRECTIONAL case).
So for e.g. If software wants to access the dma buffer, post DMA, it
will invoke dma_sync_single_for_cpu so that non-coherent arch can
invalidate the corresponding cache lines. This implies FROM_DEVICE
semantics. Does that mean dma_sync_single_for_cpu invoked with
direction = TO_DEVICE should return error.

static int sbp2_create_command_orb(struct sbp2_lu *lu,
struct sbp2_command_info *cmd,
struct scsi_cmnd *SCpnt)
{
dma_sync_single_for_cpu(dmadev, cmd->command_orb_dma,
sizeof(struct sbp2_command_orb), DMA_TO_DEVICE);
???

Yes I've seen this, but fail to understand the semantics. sync_for_cpu
implies transfer of ownership to CPU, after a DMA, which means
FROM_DEVICE semantics. To prepare the buffer to be CPU ready, non
coherent arch needs to invalidate any stray cache lines.

However passing a TO_DEVICE direction to dma_sync_single_for_cpu will
do just reverse (look at ARM implementation of this function), it
wbacks the cache lines.

So my point is dma_sync_single_for_cpu with direction = DMA_TO_DEVICE
sounds ambiguous and calling driver is not sure what kind of cache
sync operation he implies.

Post by Peter Teoh

Post by Vineet Gupta
Corollary case is when dma_sync_single_for_device is invoked with
direction = FROM_DEVICE, is tha error too (buggy driver).
The architecture for which I'm implementing DMA coherency APIs has
non-coherent DMA memory and logical-to-bus mapping / DMA bounce is not
a issue.
Thanks,
Vineet

--
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ***@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ