All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Larsson <andreas@gaisler.com>
To: Christoph Hellwig <hch@lst.de>
Cc: David Miller <davem@davemloft.net>,
	sparclinux@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
	linux-kernel@vger.kernel.org, software@gaisler.com
Subject: Re: [PATCH] sparc32: Page align size in arch_dma_alloc
Date: Mon, 13 Sep 2021 15:18:38 +0200	[thread overview]
Message-ID: <3a653ab5-14d2-f61f-cb0a-cbeba93b4ac8@gaisler.com> (raw)
In-Reply-To: <20210909060712.GA25485@lst.de>

On 2021-09-09 08:07, Christoph Hellwig wrote:
> Andreas - while I've got your attention:  I've been looking into fully
> converting sparc32 to the generic DMA code.  Do you have any
> documentation for the Leon cache handling in dma_make_coherent,
> and more importantly how that applies to the dma coherent handling?
> I could see how a flush might be required for the streaming DMA mappings,
> that is mapping normal cached memory for I/O.  But for the coherent
> allocations which can be accessed from the device and the cpu without
> another DMA mapping call this seems really strange.

As long as the area passed to arch_dma_free is mapped by
arch_dma_allocate, I don't see why the call to dma_make_coherent in
arch_dma_free should be needed. I am not sure if there are any current
(or historical paths) where we nevertheless have a cacheable mapping
when we reach arch_dma_free (or the historical pci32_free_coherent).

The usual case for LEON systems is that cache snooping on the CPU side
invalidates cache lines matching DMA that the CPU sees on the bus. Under
the assumption that DMA accesses are seen on the processor bus, this is
the reason for only flushing if snooping is not enabled in
dma_make_coherent.

-- 
Andreas Larsson


  reply	other threads:[~2021-09-13 13:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08  7:48 [PATCH] sparc32: Page align size in arch_dma_alloc Andreas Larsson
2021-09-09  6:07 ` Christoph Hellwig
2021-09-13 13:18   ` Andreas Larsson [this message]
2021-09-14  6:17     ` Christoph Hellwig
2021-09-14  8:51       ` Andreas Larsson
2021-09-14 10:42         ` Christoph Hellwig
2021-09-14 11:16           ` Andreas Larsson
2021-09-14 11:26             ` Christoph Hellwig
     [not found] ` <YTjfJl6YmBCdZ8XB@ravnborg.org>
2021-09-14  6:12   ` Christoph Hellwig
2021-09-14 11:39     ` David Miller

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=3a653ab5-14d2-f61f-cb0a-cbeba93b4ac8@gaisler.com \
    --to=andreas@gaisler.com \
    --cc=davem@davemloft.net \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=software@gaisler.com \
    --cc=sparclinux@vger.kernel.org \
    /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.