All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Porter <mporter@kernel.crashing.org>
To: Pantelis Antoniou <panto@intracom.gr>
Cc: Tom Rini <trini@kernel.crashing.org>,
	linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH  03/04] Freescale Ethernet combined driver
Date: Tue, 10 May 2005 06:47:04 -0700	[thread overview]
Message-ID: <20050510064702.B21835@cox.net> (raw)
In-Reply-To: <4280B3CB.8030007@intracom.gr>; from panto@intracom.gr on Tue, May 10, 2005 at 04:14:51PM +0300

On Tue, May 10, 2005 at 04:14:51PM +0300, Pantelis Antoniou wrote:
> Matt Porter wrote:
> > On Tue, May 10, 2005 at 08:13:48AM -0400, Dan Malek wrote:
> > 
> >>On May 10, 2005, at 7:17 AM, Pantelis Antoniou wrote:
> >>
> >>
> >>>This patch replace iopa use with virt_to_phys.
> >>
> >>Not gonna work .....
> >>
> >>When you map uncached on 8xx you get a new vmalloc()
> >>space.  The virt_to_xxx macros don't work on those addresses.
> >>You need to use the dma_consistent() function, stash the
> >>real physical address it returns and then use it where
> >>appropriate.
> > 
> > 
> > That and the use of virt_to_* and friends is deprecated by
> > the DMA API. You'll never get that upstream even if it were
> > a case where it did work.  That's a good thing to know for
> > anybody doing other drivers...
> > 
> > -Matt
> > 
> > 
> 
> OK then.
> 
> What's the recommended function to call to go from a
> virtual -> physical address, but without doing a cache
> flush/invalidate?

There is no generic function to do that in a driver since
no mainstream drivers in the kernel need to do it. Generally
you can rework the driver such that you cache the DMA address
as Dan suggested already.  I don't know your exact usage, however,
you can allocate memory with dma_alloc_noncoherent() that is
cached on ppc32 NOT_CACHE_COHERENT prcoessors and stash the
dma_addr_t/void * for later use. The other way is to kmalloc and
dma_map_single() (stashing the same way) which is basically the
same thing.

Do you have a case where this doesn't work?

-Matt

  reply	other threads:[~2005-05-10 13:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-09 11:45 [PATCH 03/04] Freescale Ethernet combined driver Pantelis Antoniou
2005-05-09 20:38 ` Matt Porter
2005-05-10 11:17   ` Pantelis Antoniou
2005-05-10 12:13     ` Dan Malek
2005-05-10 12:15       ` Pantelis Antoniou
2005-05-10 13:27       ` Matt Porter
2005-05-10 13:14         ` Pantelis Antoniou
2005-05-10 13:47           ` Matt Porter [this message]
2005-05-10 13:36             ` Pantelis Antoniou
2005-05-12  9:37             ` Pantelis Antoniou
2005-05-13  8:51               ` Pantelis Antoniou
2005-05-10 18:14           ` Dan Malek
  -- strict thread matches above, loose matches on Subject: below --
2005-05-10 14:53 Rune Torgersen
2005-05-10 18:24 ` Dan Malek

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=20050510064702.B21835@cox.net \
    --to=mporter@kernel.crashing.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=panto@intracom.gr \
    --cc=trini@kernel.crashing.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.