From: Pantelis Antoniou <panto@intracom.gr>
To: Matt Porter <mporter@kernel.crashing.org>
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 16:36:18 +0300 [thread overview]
Message-ID: <4280B8D2.4080702@intracom.gr> (raw)
In-Reply-To: <20050510064702.B21835@cox.net>
Matt Porter wrote:
> 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?
>
No that will do just fine.
I just want to know the recommended way to do it.
> -Matt
>
>
Regards
Pantelis
next prev parent reply other threads:[~2005-05-10 13:52 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
2005-05-10 13:36 ` Pantelis Antoniou [this message]
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=4280B8D2.4080702@intracom.gr \
--to=panto@intracom.gr \
--cc=linuxppc-embedded@ozlabs.org \
--cc=mporter@kernel.crashing.org \
--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.