From: Helge Deller <deller@gmx.de>
To: John David Anglin <dave.anglin@bell.net>, linux-parisc@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Subject: Re: [PATCH] parisc: improve cach flushing in arch_sync_dma_for_cpu()
Date: Tue, 16 May 2023 20:00:34 +0200 [thread overview]
Message-ID: <ZGPEwk3JEc/skrBx@p100> (raw)
In-Reply-To: <0c0a6071-d518-4d6c-17be-934e5f1a1199@bell.net>
* John David Anglin <dave.anglin@bell.net>:
> On 2023-05-16 3:09 a.m., Helge Deller wrote:
> > On 5/16/23 00:28, John David Anglin wrote:
> > > On 2023-05-15 2:39 p.m., Helge Deller wrote:
> > > > + case DMA_BIDIRECTIONAL:
> > > > + flush_kernel_dcache_range(addr, size);
> > > > + purge_kernel_dcache_range_asm(addr, addr + size);
> > > I don't think flush and purge are both needed.
> >
> > I'm not sure...
> >
> > Just to fully understand it. Is this short summary correct: ?
> > - flush_kernel_dcache_range: flush cache back to memory, but keep data in cache.
> No. If present, fdc writes addressed cache line to memory if and only if line is dirty. It
> then invalidates line. It does not keep data in cache.
>
> Next read loads from memory.
> > Next read fetches the data which is still in the cache, thus the next
> > read doesn't checks if data in memory has been modified in the meantime (e.g. via DMA).
> > - purge_kernel_dcache_range_asm: ignore currently cached data & drop any cached data in that range.
> > Even if cache has dirty memory which hasn't been written back yet, drop it and don't write back.
> if present, pdc invalidates line. At privilege level zero, an implementation may optionally write
> back a dirty line to memory. At non-zero privilege levels, fdc and pdc are effectively the same.
>
> I don't know how to determine whether pdc does write back or not. It would be specified in processor
> ERS.
Thanks for the explanation!
With that, I've attached an updated (untested) patch below.
Helge
[PATCH v2] parisc: improve cach flushing in arch_sync_dma_for_cpu()
Add comment in arch_sync_dma_for_device() and handle the direction flag in
arch_sync_dma_for_cpu().
When receiving data from the device (DMA_FROM_DEVICE) unconditionally
purge the data cache in arch_sync_dma_for_cpu().
Signed-off-by: Helge Deller <deller@gmx.de>
diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index ba87f791323b..71ed5391f29d 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -446,11 +446,27 @@ void arch_dma_free(struct device *dev, size_t size, void *vaddr,
void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
{
+ /*
+ * fdc: The data cache line is written back to memory, if and only if
+ * it is dirty, and then invalidated from the data cache.
+ */
flush_kernel_dcache_range((unsigned long)phys_to_virt(paddr), size);
}
void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
{
- flush_kernel_dcache_range((unsigned long)phys_to_virt(paddr), size);
+ unsigned long addr = (unsigned long) phys_to_virt(paddr);
+
+ switch (dir) {
+ case DMA_TO_DEVICE:
+ case DMA_BIDIRECTIONAL:
+ flush_kernel_dcache_range(addr, size);
+ return;
+ case DMA_FROM_DEVICE:
+ purge_kernel_dcache_range_asm(addr, addr + size);
+ return;
+ default:
+ BUG();
+ }
}
next prev parent reply other threads:[~2023-05-16 18:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 18:39 [PATCH] parisc: improve cach flushing in arch_sync_dma_for_cpu() Helge Deller
2023-05-15 22:28 ` John David Anglin
2023-05-16 7:09 ` Helge Deller
2023-05-16 14:20 ` John David Anglin
2023-05-16 18:00 ` Helge Deller [this message]
2023-05-19 16:07 ` John David Anglin
2023-05-20 5:10 ` Helge Deller
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=ZGPEwk3JEc/skrBx@p100 \
--to=deller@gmx.de \
--cc=dave.anglin@bell.net \
--cc=linux-parisc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox