| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from George G. Davis
This Freescale Semiconductor, Inc. contributed patch adds mem_types[]
support for ARMv6 non-shared device memory region attributes. This
implementation provides support for only first level section mapped
non-shared devices. Second level non-shared device mappings are not
yet supported.
Signed-off-by: George G. Davis <gdavis@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from Deepak Saxena
In working on adding 36-bit addressed supersection support to ioremap(),
I came to the conclusion that it would be far simpler to do so by just
splitting __ioremap() into a main external interface and adding an
__ioremap_pfn() function that takes a pfn + offset into the page that
__ioremap() can call. This way existing callers of __ioremap() won't have
to change their code and 36-bit systems will just call __ioremap_pfn()
and we will not have to deal with unsigned long long variables.
Note that __ioremap_pfn() should _NOT_ be called directly by drivers
but is reserved for use by arch_ioremap() implementations that map
32-bit resource regions into the real 36-bit address and then call
this new function.
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| |
|
|
|
|
|
| |
Macro arguments should _always_ be surrounded by parentheses
when used to prevent unexpected problems with operator precedence.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
| |
|
|
|
|
|
|
|
|
|
| |
Patch from Deepak Saxena
Convert map_desc.physical to map_desc.pfn. This allows us to add
support for 36-bit addressed physical devices in the static maps
without having to resort to u64 variables.
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
