public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <iod00d@hp.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-kernel@vger.kernel.org, discuss@x86-64.org,
	linux-ia64@vger.kernel.org, ak@suse.de, tony.luck@intel.com,
	Asit.K.Mallick@intel.com
Subject: Re: [patch 2.6.13 4/6] swiotlb: support syncing DMA_BIDIRECTIONAL mappings
Date: Mon, 12 Sep 2005 11:51:20 -0700	[thread overview]
Message-ID: <20050912185120.GD21820@esmail.cup.hp.com> (raw)
In-Reply-To: <09122005104851.31120@bilbo.tuxdriver.com>

On Mon, Sep 12, 2005 at 10:48:51AM -0400, John W. Linville wrote:
...
> +	switch (target) {
> +	case SYNC_FOR_CPU:
> +		if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
> +			memcpy(buffer, dma_addr, size);
> +		else if (dir != DMA_TO_DEVICE && dir != DMA_NONE)
> +			BUG();
> +		break;
> +	case SYNC_FOR_DEVICE:
> +		if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
> +			memcpy(dma_addr, buffer, size);
> +		else if (dir != DMA_FROM_DEVICE && dir != DMA_NONE)
> +			BUG();
> +		break;
> +	default:
>  		BUG();
> +	}

Isn't "DMA_NONE" expected to generate a warning or panic?

Documentation/DMA-mapping.txt says:
	The value PCI_DMA_NONE is to be used for debugging.  One can
	hold this in a data structure before you come to know the
	precise direction, and this will help catch cases where your
	direction tracking logic has failed to set things up properly.


And it just seems wrong to sync a buffer if no DMA has taking place.

...
> @@ -525,14 +540,15 @@ swiotlb_sync_single_for_device(struct de
>   */
>  static inline void
>  swiotlb_sync_single_range(struct device *hwdev, dma_addr_t dev_addr,
> -			  unsigned long offset, size_t size, int dir)
> +			  unsigned long offset, size_t size,
> +			  int dir, int target)
>  {
>  	char *dma_addr = phys_to_virt(dev_addr) + offset;
>  
>  	if (dir == DMA_NONE)
>  		BUG();

This existing code seems to support the idea that DMA sync interfaces
require the direction be set to something other than DMA_NONE.

thanks,
grant

  parent reply	other threads:[~2005-09-12 18:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-30 18:03 [patch 2.6.13] swiotlb: add swiotlb_sync_single_range_for_{cpu,device} Luck, Tony
2005-08-30 18:09 ` John W. Linville
2005-08-30 18:33   ` [rfc patch] swiotlb: consolidate swiotlb_sync_single_* implementations John W. Linville
2005-08-30 18:40     ` [rfc patch] swiotlb: consolidate swiotlb_sync_sg_* implementations John W. Linville
2005-09-12 14:48   ` [patch 2.6.13 0/6] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device} John W. Linville
2005-09-12 14:48     ` [patch 2.6.13 1/6] swiotlb: move from arch/ia64/lib to lib John W. Linville
2005-09-12 14:48       ` [patch 2.6.13 2/6] swiotlb: cleanup some code duplication cruft John W. Linville
2005-09-12 14:48         ` [patch 2.6.13 3/6] swiotlb: support syncing sub-ranges of mappings John W. Linville
2005-09-12 14:48           ` [patch 2.6.13 4/6] swiotlb: support syncing DMA_BIDIRECTIONAL mappings John W. Linville
2005-09-12 14:48             ` [patch 2.6.13 5/6] swiotlb: file header comments John W. Linville
2005-09-12 14:48               ` [patch 2.6.13 6/6] x86_64: implement dma_sync_single_range_for_{cpu,device} John W. Linville
2005-09-12 15:22                 ` Andi Kleen
2005-09-12 18:51             ` Grant Grundler [this message]
2005-09-12 19:51               ` [patch 2.6.13 4/6] swiotlb: support syncing DMA_BIDIRECTIONAL mappings John W. Linville
2005-09-12 19:53                 ` [patch 2.6.13] swiotlb: BUG() for DMA_NONE in sync_single John W. Linville
2005-09-12 20:23                   ` Grant Grundler
2005-09-12 23:45                     ` [patch 2.6.13 (take #2)] " John W. Linville
2005-09-12 23:59                       ` Grant Grundler
2005-09-13  4:05                       ` [discuss] " Andi Kleen

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=20050912185120.GD21820@esmail.cup.hp.com \
    --to=iod00d@hp.com \
    --cc=Asit.K.Mallick@intel.com \
    --cc=ak@suse.de \
    --cc=discuss@x86-64.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=tony.luck@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox