All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Porter <porter@cox.net>
To: Dan Malek <dan@embeddededge.com>
Cc: Matt Porter <porter@cox.net>, linuxppc-embedded@lists.linuxppc.org
Subject: Re: [PATCH] Fix *dma_sync_single() and flush_dcache_all
Date: Tue, 4 Mar 2003 16:45:35 -0700	[thread overview]
Message-ID: <20030304164535.G2120@home.com> (raw)
In-Reply-To: <3E6532B4.2090506@embeddededge.com>; from dan@embeddededge.com on Tue, Mar 04, 2003 at 06:11:48PM -0500


On Tue, Mar 04, 2003 at 06:11:48PM -0500, Dan Malek wrote:
> Matt Porter wrote:
>
> > That means the ARM and MIPS implementations that use a
> > bus_to_virt() on the dma_handle in *dma_sync_single are
> > correct and our (performance killing) call to flush_dcache_all
> > is unnecessary.
>
> Well, to be fair it seems this code has gone through a couple
> of revisions since it was originally written.  I suspect a "better
> safe than sorry" approach was taken when changes were made. :-)

I figured that. :)

> > If there are no objections, then I will commit to following
> > patch to 2_4_devel and 2.5.  The 2.5 pci_map_single/sync_single
> > are horked up anyway for 4xx so that will get fixed too.
>
> OK, go for it.  A couple of comments though.........
>
>
> >  #define CACHE_NWAYS	64
> >  #define CACHE_NLINES	16
>
> I made these #defines in the original code and I believe they were
> set to values based upon the processor selection.  When did they
> change to 'worst case' and the most popular and most performance
> challenged processors are paying the price for unnecessary cache
> operations?

I don't know the answer that.  It happened before I first touched
it.  I simply upped the worst case to cover the larger 440 core
dcache.

> > -#ifdef CONFIG_NOT_COHERENT_CACHE
> > -	/* The bus_to_virt() can't be used here, in case dma_handle
> > -	 * points to something that doesn't have the same cache attributes
> > -	 * as the 1:1 mapped kernel memory.
>
> Ummm....this is a very important comment (not because I wrote it) :-)
> On the 4xx and 8xx processors you can't use bus_to_virt() (unless we
> are still calling iopa() and properly tracking all of the pages that
> may be part of the DMA).  Are we _sure_ we aren't using consistent_alloc()'ed
> memory with these APIs?

Yes, I completely understand the comment. :)

As I said, the DMA API explicitly lists what memory can be passed to
this family of API's.  Memory allocated from pci_alloc_consistent
cannot be passed in.  Nor can ioremapped addresses.  DaveM suggests
another API be created to handle device to device transfers for 2.5+
for that specific case.

I listed the types of allocated addresses that the API documentation
explicitly mentions in the previous mail.  Memory allocated via
those methods will always be able to be converted back to a
virtual address via bus_to_virt() because the allocations come
from 1:1 kernel lowmem and are guaranteed to be contiguous.  highmem
is not a consideration since the *_single() family of calls is only
usable on lowmem...*_page() would be used for highmem.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

      reply	other threads:[~2003-03-04 23:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-04 22:36 [PATCH] Fix *dma_sync_single() and flush_dcache_all Matt Porter
2003-03-04 23:11 ` Dan Malek
2003-03-04 23:45   ` Matt Porter [this message]

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=20030304164535.G2120@home.com \
    --to=porter@cox.net \
    --cc=dan@embeddededge.com \
    --cc=linuxppc-embedded@lists.linuxppc.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.