linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* ioremap questions
@ 2004-10-28 20:53 Yoav Steinberg
  2004-10-28 22:29 ` Matt Porter
  0 siblings, 1 reply; 2+ messages in thread
From: Yoav Steinberg @ 2004-10-28 20:53 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

Hello,
i'm trying to map a physical address on the 440GP's external bus to a virtual address so I can access it from kernel space. While looking at the ebony.c file under the drivers/mtd/maps I saw that a function called ioremap64 was used.
My questions:
1) Why use the ioremap64 function which receives a 64bit physical address when the CPU is a 32 bit CPU? It seems like this is a special function for th 44x series, is this true?
2) There seem to be multiple ioremap functions: ioremap/64/_nocache etc. which is the most appropriate one? What are the differences?
3) Do I need to call iounmap before remapping somethig previouslly mapped with ioremap?
 
Thank's

[-- Attachment #2: Type: text/html, Size: 1225 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: ioremap questions
  2004-10-28 20:53 ioremap questions Yoav Steinberg
@ 2004-10-28 22:29 ` Matt Porter
  0 siblings, 0 replies; 2+ messages in thread
From: Matt Porter @ 2004-10-28 22:29 UTC (permalink / raw)
  To: Yoav Steinberg; +Cc: linuxppc-embedded

[Please fix your mailer, line length is way too big]

On Thu, Oct 28, 2004 at 10:53:38PM +0200, Yoav Steinberg wrote:
> Hello,
> i'm trying to map a physical address on the 440GP's external bus to a virtual address so I can access it from kernel space. While looking at the ebony.c file under the drivers/mtd/maps I saw that a function called ioremap64 was used.
> My questions:
> 1) Why use the ioremap64 function which receives a 64bit physical
> address when the CPU is a 32 bit CPU? It seems like this is a
> special function for th 44x series, is this true?

The CPU is 32-bit virtual (well, technically 41-bit but who's counting)
and 36-bit physical. This is a special function for any ppc32 platform
with >32-bit physical address space. It is needed because the kernel
does not yet support resources with >32-bit start/end fields. We
can and do perform fix-ups so ioremap() works for generic PCI drivers
and some other areas, but sometimes the fixup method can fail due
to overlapping address space and the resolution of the resource
fields. In that case, it is necessary to use ioremap64(). In
44x-specific drivers, it's generally a good idea to use ioremap64()
since you aren't hiding the real address behind the fixup code...
increasing readability.

> 2) There seem to be multiple ioremap functions: ioremap/64/_nocache
> etc. which is the most appropriate one? What are the differences?

For what you want to do, a custom driver, use ioremap64(). On ppc32,
ioremap_nocache() and ioremap() do the same thing. I've explained the
difference with ioremap64() above.

> 3) Do I need to call iounmap before remapping somethig previouslly
> mapped with ioremap? 

No. It will create a new mapping. It is, however, good practice to
use iounmap() when you are done using a resource. This frees up
vmalloc space in the kernel.  In many applications, this is
becoming a very limited address space.

-Matt

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-10-28 22:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-28 20:53 ioremap questions Yoav Steinberg
2004-10-28 22:29 ` Matt Porter

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).