- 26 1月, 2006 1 次提交
-
-
由 George G. Davis 提交于
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: NGeorge G. Davis <gdavis@mvista.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 10 1月, 2006 1 次提交
-
-
由 Deepak Saxena 提交于
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: NDeepak Saxena <dsaxena@plexity.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 29 10月, 2005 1 次提交
-
-
由 Russell King 提交于
Macro arguments should _always_ be surrounded by parentheses when used to prevent unexpected problems with operator precedence. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 28 10月, 2005 1 次提交
-
-
由 Deepak Saxena 提交于
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: NDeepak Saxena <dsaxena@plexity.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-