[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130417.131156.13653463501819067.davem@davemloft.net>
Date: Wed, 17 Apr 2013 13:11:56 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: torvalds@...ux-foundation.org
Cc: tomi.valkeinen@...com, linux-kernel@...r.kernel.org,
clemens@...isch.de, arnd@...db.de, tiwai@...e.de,
mchehab@...hat.com, ralf@...ux-mips.org
Subject: Re: Device driver memory 'mmap()' function helper cleanup
From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Wed, 17 Apr 2013 07:44:33 -0700
> (*) io_remap_pfn_page() is the "extended" version that takes care of
> some special magical details on a couple of odd architectures, notably
> sparc (but also one special case of MIPS PAE that have some magic bit
> tricks). But even for MIPS and Sparc, it ends up devolving to be the
> same as the "regular" remap_pfn_page() for normal memory. I'm adding
> David and Ralf to the cc just to verify that I read it right, but
> everybody else just defines "io_remap_pfn_range" to be
> "remap_pfn_range".
Yeah, the only thing special we do on sparc is interpret the PFN
specially. We munge it into the real physical address and then
pass it all down to remap_pfn_range() to do the real work.
We used to have a crazy special version of this entire routine
on sparc64 that tried to create huge TLB mappings, but that got
killed quite some time ago:
commit 3e37fd3153ac95088a74f5e7c569f7567e9f993a
Author: David S. Miller <davem@...emloft.net>
Date: Thu Nov 17 18:17:59 2011 -0800
sparc: Kill custom io_remap_pfn_range().
To handle the large physical addresses, just make a simple wrapper
around remap_pfn_range() like MIPS does.
Signed-off-by: David S. Miller <davem@...emloft.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists