All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Mirosław" <mirqus@gmail.com>
To: Mark Salter <msalter@redhat.com>
Cc: linux-kernel@vger.kernel.org, ming.lei@canonical.com,
	stern@rowland.harvard.edu, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] add dma_coherent_write_sync to DMA API
Date: Thu, 1 Sep 2011 11:57:36 +0200	[thread overview]
Message-ID: <CAHXqBFJ6tEkn+iW3ZBAiWu5Sx9y9MQdnJt5Gfnv5Xc3UB78uLw@mail.gmail.com> (raw)
In-Reply-To: <1314826214-22428-2-git-send-email-msalter@redhat.com>

2011/8/31 Mark Salter <msalter@redhat.com>:
> On ARMv6/7 DMA-coherent memory is bufferable which means that CPU writes to
> coherent memory may still be held in a write buffer for a significant amount
> of time. This is largely mitigated by having the MMIO write functions force
> a write buffer flush before doing the actual write to the MMIO register. This
> forces out previous CPU writes to coherent memory for drivers which write to
> a register to inform the device that something was written to memory. However,
> this does not mitigate the problem for devices which poll the DMA memory for
> changes written by the CPU. One such case was found by ming.lei@canonical.com
> in the USB EHCI driver. The EHCI host controller relies at least partly on
> polling DMA coherent memory for information from the driver.
>
> This patch adds a dma_coherent_write_sync() function to the DMA API which
> drivers can use to explicitly force out data which may otherwise be held up
> in a write buffer. It is a no-op unless and architecture provides its own
> version or the function and sets ARCH_HAS_DMA_COHERENT_WRITE_SYNC.
[...]
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -418,6 +418,18 @@ void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr,
>        ....
>
>
> +Part Ie - Write buffering to dma-coherent memory
> +------------------------------------------------
> +
> +Some architectures supporting DMA coherent memory may have write
> +buffering between the CPU and DMA memory. This buffering may delay
> +CPU writes from reaching coherent memory in a timely manner.
> +
> +    void
> +    dma_coherent_write_sync()
> +
> +Force any outstanding coherent writes to memory.

This should be merged or referenced in part Ia.

BTW, if there's no time limit on write buffers flushing, or if write
buffers can cause reordering of the writes, then the memory accesses
need to be managed just like non-DMA-coherent memory. So what differs
then in DMA-coherent vs non-DMA-coherent mappings then?

Best Regards,
Michał Mirosław

WARNING: multiple messages have this Message-ID (diff)
From: mirqus@gmail.com (Michał Mirosław)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] add dma_coherent_write_sync to DMA API
Date: Thu, 1 Sep 2011 11:57:36 +0200	[thread overview]
Message-ID: <CAHXqBFJ6tEkn+iW3ZBAiWu5Sx9y9MQdnJt5Gfnv5Xc3UB78uLw@mail.gmail.com> (raw)
In-Reply-To: <1314826214-22428-2-git-send-email-msalter@redhat.com>

2011/8/31 Mark Salter <msalter@redhat.com>:
> On ARMv6/7 DMA-coherent memory is bufferable which means that CPU writes to
> coherent memory may still be held in a write buffer for a significant amount
> of time. This is largely mitigated by having the MMIO write functions force
> a write buffer flush before doing the actual write to the MMIO register. This
> forces out previous CPU writes to coherent memory for drivers which write to
> a register to inform the device that something was written to memory. However,
> this does not mitigate the problem for devices which poll the DMA memory for
> changes written by the CPU. One such case was found by ming.lei at canonical.com
> in the USB EHCI driver. The EHCI host controller relies at least partly on
> polling DMA coherent memory for information from the driver.
>
> This patch adds a dma_coherent_write_sync() function to the DMA API which
> drivers can use to explicitly force out data which may otherwise be held up
> in a write buffer. It is a no-op unless and architecture provides its own
> version or the function and sets ARCH_HAS_DMA_COHERENT_WRITE_SYNC.
[...]
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -418,6 +418,18 @@ void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr,
> ? ? ? ?....
>
>
> +Part Ie - Write buffering to dma-coherent memory
> +------------------------------------------------
> +
> +Some architectures supporting DMA coherent memory may have write
> +buffering between the CPU and DMA memory. This buffering may delay
> +CPU writes from reaching coherent memory in a timely manner.
> +
> + ? ?void
> + ? ?dma_coherent_write_sync()
> +
> +Force any outstanding coherent writes to memory.

This should be merged or referenced in part Ia.

BTW, if there's no time limit on write buffers flushing, or if write
buffers can cause reordering of the writes, then the memory accesses
need to be managed just like non-DMA-coherent memory. So what differs
then in DMA-coherent vs non-DMA-coherent mappings then?

Best Regards,
Micha? Miros?aw

  parent reply	other threads:[~2011-09-01  9:57 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-31 21:30 [PATCH 0/3] RFC: addition to DMA API Mark Salter
2011-08-31 21:30 ` Mark Salter
2011-08-31 21:30 ` [PATCH 1/3] add dma_coherent_write_sync " Mark Salter
2011-08-31 21:30   ` Mark Salter
2011-09-01  2:59   ` Josh Cartwright
2011-09-01  2:59     ` Josh Cartwright
2011-09-01  9:57   ` Michał Mirosław [this message]
2011-09-01  9:57     ` Michał Mirosław
2011-09-01 12:36     ` Mark Salter
2011-09-01 12:36       ` Mark Salter
2011-09-06 14:30       ` Catalin Marinas
2011-09-06 14:30         ` Catalin Marinas
2011-08-31 21:30 ` [PATCH 2/3] define ARM-specific dma_coherent_write_sync Mark Salter
2011-08-31 21:30   ` Mark Salter
2011-09-06 14:32   ` Catalin Marinas
2011-09-06 14:32     ` Catalin Marinas
2011-09-06 14:37     ` Mark Salter
2011-09-06 14:37       ` Mark Salter
2011-09-06 14:48       ` Catalin Marinas
2011-09-06 14:48         ` Catalin Marinas
2011-09-06 15:02         ` Mark Salter
2011-09-06 15:02           ` Mark Salter
2011-10-03  1:40           ` Jon Masters
2011-10-03  1:40             ` Jon Masters
2011-10-03  8:44             ` Catalin Marinas
2011-10-03  8:44               ` Catalin Marinas
2011-10-03  9:24               ` Jon Masters
2011-10-03  9:24                 ` Jon Masters
2011-08-31 21:30 ` [PATCH 3/3] add dma_coherent_write_sync calls to USB EHCI driver Mark Salter
2011-08-31 21:30   ` Mark Salter
2011-09-01  2:33   ` Ming Lei
2011-09-01  2:33     ` Ming Lei
2011-09-01  2:09 ` [PATCH 0/3] RFC: addition to DMA API Ming Lei
2011-09-01  2:09   ` Ming Lei
2011-09-01  3:09   ` Alan Stern
2011-09-01  3:09     ` Alan Stern
2011-09-01  3:41     ` Ming Lei
2011-09-01  3:41       ` Ming Lei
2011-09-01  8:45       ` Will Deacon
2011-09-01  8:45         ` Will Deacon
2011-09-01  9:14         ` Ming Lei
2011-09-01  9:14           ` Ming Lei
2011-09-01 15:42           ` Alan Stern
2011-09-01 15:42             ` Alan Stern
2011-09-01 16:04             ` Russell King - ARM Linux
2011-09-01 16:04               ` Russell King - ARM Linux
2011-09-01 17:31               ` Will Deacon
2011-09-01 17:31                 ` Will Deacon
2011-09-01 18:07                 ` Russell King - ARM Linux
2011-09-01 18:07                   ` Russell King - ARM Linux
2011-09-01 19:14                 ` Mark Salter
2011-09-01 19:14                   ` Mark Salter
2011-09-01 15:22       ` Alan Stern
2011-09-01 15:22         ` Alan Stern
2011-09-01 15:56         ` Ming Lei
2011-09-01 15:56           ` Ming Lei
2011-09-01 16:48           ` Alan Stern
2011-09-01 16:48             ` Alan Stern
2011-09-02  0:59             ` Ming Lei
2011-09-02  0:59               ` Ming Lei
2011-09-02 13:53               ` Alan Stern
2011-09-02 13:53                 ` Alan Stern
2011-09-01  9:11 ` Will Deacon
2011-09-01  9:11   ` Will Deacon

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=CAHXqBFJ6tEkn+iW3ZBAiWu5Sx9y9MQdnJt5Gfnv5Xc3UB78uLw@mail.gmail.com \
    --to=mirqus@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=msalter@redhat.com \
    --cc=stern@rowland.harvard.edu \
    /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.