All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <iod00d@hp.com>
To: David Brownell <david-b@pacbell.net>
Cc: davidm@hpl.hp.com, Greg KH <greg@kroah.com>,
	vojtech@suse.cz, linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
	pochini@shiny.it
Subject: Re: [linux-usb-devel] Re: serious 2.6 bug in USB subsystem?
Date: Mon, 08 Mar 2004 06:18:02 +0000	[thread overview]
Message-ID: <20040308061802.GA25960@cup.hp.com> (raw)
In-Reply-To: <4049FE57.2060809@pacbell.net>

On Sat, Mar 06, 2004 at 08:37:43AM -0800, David Brownell wrote:
> DMA-coherent memory is defined as "memory for which a write by either
> the device or the processor can immediately be read by the processor
> or device without having to worry about caching effects."

The use of "immediate" here means no other sync function needs to
be called to access the data - ie don't need to call pci_sync_single().

In general, the accesses are ordered following PCI ordering rules.
But every architecture (including x86) has issues with "inflight" DMA.
Line based Interrupts are delivered on a different path than DMA 
and thus ordering can't be enforced.
For example, the code around the following comment in drivers/net/tg3.c:
	/*
	 * Flush PCI write.  This also guarantees that our
	 * status block has been flushed to host memory.
	 */


> `Such a
> write-buffering mechanism is clearly a type of (write-)caching effect,

No - the data is still in flight and in some deterministic time frame
will become visible to the CPU.
Calling it a "caching effect" confuses the issues even worse.

> and readl() would be a kind of dma_rmb(), if you will.

Yes, that's correct - but it's orthogonal to "cache coherent".

> I suspect the docs are wrong about what dma-coherent means.

Not "wrong", just misunderstood. ;^)

hth,
grant

WARNING: multiple messages have this Message-ID (diff)
From: Grant Grundler <iod00d@hp.com>
To: David Brownell <david-b@pacbell.net>
Cc: davidm@hpl.hp.com, Greg KH <greg@kroah.com>,
	vojtech@suse.cz, linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
	pochini@shiny.it
Subject: Re: [linux-usb-devel] Re: serious 2.6 bug in USB subsystem?
Date: Sun, 7 Mar 2004 22:18:02 -0800	[thread overview]
Message-ID: <20040308061802.GA25960@cup.hp.com> (raw)
In-Reply-To: <4049FE57.2060809@pacbell.net>

On Sat, Mar 06, 2004 at 08:37:43AM -0800, David Brownell wrote:
> DMA-coherent memory is defined as "memory for which a write by either
> the device or the processor can immediately be read by the processor
> or device without having to worry about caching effects."

The use of "immediate" here means no other sync function needs to
be called to access the data - ie don't need to call pci_sync_single().

In general, the accesses are ordered following PCI ordering rules.
But every architecture (including x86) has issues with "inflight" DMA.
Line based Interrupts are delivered on a different path than DMA 
and thus ordering can't be enforced.
For example, the code around the following comment in drivers/net/tg3.c:
	/*
	 * Flush PCI write.  This also guarantees that our
	 * status block has been flushed to host memory.
	 */


> `Such a
> write-buffering mechanism is clearly a type of (write-)caching effect,

No - the data is still in flight and in some deterministic time frame
will become visible to the CPU.
Calling it a "caching effect" confuses the issues even worse.

> and readl() would be a kind of dma_rmb(), if you will.

Yes, that's correct - but it's orthogonal to "cache coherent".

> I suspect the docs are wrong about what dma-coherent means.

Not "wrong", just misunderstood. ;^)

hth,
grant

  reply	other threads:[~2004-03-08  6:18 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-27 22:35 serious 2.6 bug in USB subsystem? David Mosberger
2003-10-28  1:30 ` Greg KH
2003-10-28  3:00   ` David Mosberger
2003-10-30 15:11     ` [linux-usb-devel] " David Brownell
2003-10-30 20:15       ` David Mosberger
     [not found]         ` <16289.55171.278494.17172@napali.hpl.hp.com>
2003-10-31 16:23           ` David Brownell
2003-10-31 18:34             ` David Mosberger
2003-10-31 18:50               ` Valdis.Kletnieks
2003-10-31 19:28               ` David Brownell
2003-10-31 19:50                 ` David Mosberger
2003-10-31 20:06                   ` David S. Miller
2004-03-06  2:08             ` David Mosberger
2004-03-06  2:08               ` David Mosberger
2004-03-06  2:13               ` David Mosberger
2004-03-06  2:13                 ` David Mosberger
2004-03-06  4:55               ` David Brownell
2004-03-06  4:55                 ` David Brownell
2004-03-06  5:49                 ` David Mosberger
2004-03-06  5:49                   ` David Mosberger
2004-03-06  7:21                   ` David Mosberger
2004-03-06  7:21                     ` David Mosberger
2004-03-06  8:39                     ` David Mosberger
2004-03-06  8:39                       ` David Mosberger
2004-03-06 16:37                   ` David Brownell
2004-03-06 16:37                     ` David Brownell
2004-03-08  6:18                     ` Grant Grundler [this message]
2004-03-08  6:18                       ` Grant Grundler
2004-03-08 18:58                       ` David Mosberger
2004-03-08 18:58                         ` David Mosberger
2004-03-08 21:48                         ` David Brownell
2004-03-08 21:48                           ` David Brownell
2004-03-09  9:15                           ` David Mosberger
2004-03-09  9:15                             ` David Mosberger
2004-03-09 17:36                             ` David Brownell
2004-03-09 17:36                               ` David Brownell
2004-03-09 17:58                               ` David Mosberger
2004-03-09 17:58                                 ` David Mosberger
2004-03-09 20:39                                 ` David Brownell
2004-03-09 20:39                                   ` David Brownell
2004-03-09 23:32                                   ` David Mosberger
2004-03-09 23:32                                     ` David Mosberger
2004-03-10  2:53                                     ` David Brownell
2004-03-10  2:53                                       ` David Brownell
2004-03-10  6:11                                       ` David Mosberger
2004-03-10  6:11                                         ` David Mosberger
2004-03-10  6:59                                   ` David Mosberger
2004-03-10  6:59                                     ` David Mosberger
2004-03-10  7:52                                     ` Wouter Lueks
2004-03-10 16:49                                       ` David Mosberger
2004-03-10 19:49                                         ` Wouter Lueks
2004-03-10 16:22                                     ` David Brownell
2004-03-10 16:22                                       ` David Brownell
2004-03-10 18:04                                       ` David Mosberger
2004-03-10 18:04                                         ` David Mosberger
2004-03-11  2:43                                         ` David Brownell
2004-03-11  2:43                                           ` David Brownell
2004-03-11  5:35                                           ` David Mosberger
2004-03-11  5:35                                             ` David Mosberger
2004-03-10 19:29                                     ` Colin Leroy
2004-03-06  9:17                 ` [linux-usb-devel] " David Mosberger
2004-03-06  9:17                   ` David Mosberger
2004-03-06 17:30                   ` David Brownell
2004-03-06 17:30                     ` David Brownell
2004-03-07 13:48                     ` Matthias Andree
2004-03-08 18:49                     ` David Mosberger
2004-03-08 18:49                       ` David Mosberger
2003-11-03  3:46         ` David Brownell
2003-11-03 21:25           ` David Mosberger
2004-03-03 12:33 ` Wouter Lueks
2004-03-03 15:30   ` Wouter Lueks

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=20040308061802.GA25960@cup.hp.com \
    --to=iod00d@hp.com \
    --cc=david-b@pacbell.net \
    --cc=davidm@hpl.hp.com \
    --cc=greg@kroah.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=pochini@shiny.it \
    --cc=vojtech@suse.cz \
    /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.