linuxppc-dev.lists.ozlabs.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).