<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/arm/include/asm/memory.h, branch v2.6.32</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge branch 'master' into devel</title>
<updated>2009-09-12T11:04:37+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk@dyn-67.arm.linux.org.uk</email>
</author>
<published>2009-09-12T11:04:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=87d721ad7a37b7650dd710c88dd5c6a5bf9fe996'/>
<id>87d721ad7a37b7650dd710c88dd5c6a5bf9fe996</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: Fix pfn_valid() for sparse memory</title>
<updated>2009-09-12T10:48:09+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk@dyn-67.arm.linux.org.uk</email>
</author>
<published>2009-09-07T14:06:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b7cfda9fc3d7aa60cffab5367f2a72a4a70060cd'/>
<id>b7cfda9fc3d7aa60cffab5367f2a72a4a70060cd</id>
<content type='text'>
On OMAP platforms, some people want to declare to segment up the memory
between the kernel and a separate application such that there is a hole
in the middle of the memory as far as Linux is concerned.  However,
they want to be able to mmap() the hole.

This currently causes problems, because update_mmu_cache() thinks that
there are valid struct pages for the "hole".  Fix this by making
pfn_valid() slightly more expensive, by checking whether the PFN is
contained within the meminfo array.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Tested-by: Khasim Syed Mohammed &lt;khasim@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On OMAP platforms, some people want to declare to segment up the memory
between the kernel and a separate application such that there is a hole
in the middle of the memory as far as Linux is concerned.  However,
they want to be able to mmap() the hole.

This currently causes problems, because update_mmu_cache() thinks that
there are valid struct pages for the "hole".  Fix this by making
pfn_valid() slightly more expensive, by checking whether the PFN is
contained within the meminfo array.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Tested-by: Khasim Syed Mohammed &lt;khasim@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Thumb-2: Add support for loadable modules</title>
<updated>2009-07-24T11:32:59+00:00</updated>
<author>
<name>Catalin Marinas</name>
<email>catalin.marinas@arm.com</email>
</author>
<published>2009-07-24T11:32:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=adca6dc23bc620ea95392659625200a252b97be3'/>
<id>adca6dc23bc620ea95392659625200a252b97be3</id>
<content type='text'>
Modules compiled to Thumb-2 have two additional relocations needing to
be resolved at load time, R_ARM_THM_CALL and R_ARM_THM_JUMP24, for BL
and B.W instructions. The maximum Thumb-2 addressing range is +/-2^24
(+/-16MB) therefore the MODULES_VADDR macro in asm/memory.h is set to
(MODULES_END - 8MB) for the Thumb-2 compiled kernel.

Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Modules compiled to Thumb-2 have two additional relocations needing to
be resolved at load time, R_ARM_THM_CALL and R_ARM_THM_JUMP24, for BL
and B.W instructions. The maximum Thumb-2 addressing range is +/-2^24
(+/-16MB) therefore the MODULES_VADDR macro in asm/memory.h is set to
(MODULES_END - 8MB) for the Thumb-2 compiled kernel.

Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] make page_to_dma() highmem aware</title>
<updated>2009-03-16T01:01:21+00:00</updated>
<author>
<name>Nicolas Pitre</name>
<email>nico@cam.org</email>
</author>
<published>2008-09-09T19:54:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=58edb515724f9e63e569536d01ac8d8f8ddb367a'/>
<id>58edb515724f9e63e569536d01ac8d8f8ddb367a</id>
<content type='text'>
If a machine class has a custom __virt_to_bus() implementation then it
must provide a __arch_page_to_dma() implementation as well which is
_not_ based on page_address() to support highmem.

This patch fixes existing __arch_page_to_dma() and provide a default
implementation otherwise.  The default implementation for highmem is
based on __pfn_to_bus() which is defined only when no custom
__virt_to_bus() is provided by the machine class.

That leaves only ebsa110 and footbridge which cannot support highmem
until they provide their own __arch_page_to_dma() implementation.
But highmem support on those legacy platforms with limited memory is
certainly not a priority.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a machine class has a custom __virt_to_bus() implementation then it
must provide a __arch_page_to_dma() implementation as well which is
_not_ based on page_address() to support highmem.

This patch fixes existing __arch_page_to_dma() and provide a default
implementation otherwise.  The default implementation for highmem is
based on __pfn_to_bus() which is defined only when no custom
__virt_to_bus() is provided by the machine class.

That leaves only ebsa110 and footbridge which cannot support highmem
until they provide their own __arch_page_to_dma() implementation.
But highmem support on those legacy platforms with limited memory is
certainly not a priority.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] kmap support</title>
<updated>2009-03-16T01:01:20+00:00</updated>
<author>
<name>Nicolas Pitre</name>
<email>nico@cam.org</email>
</author>
<published>2008-09-15T20:44:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d73cd42893f4cdc06e6829fea2347bb92cb789d1'/>
<id>d73cd42893f4cdc06e6829fea2347bb92cb789d1</id>
<content type='text'>
The kmap virtual area borrows a 2MB range at the top of the 16MB area
below PAGE_OFFSET currently reserved for kernel modules and/or the
XIP kernel.  This 2MB corresponds to the range covered by 2 consecutive
second-level page tables, or a single pmd entry as seen by the Linux
page table abstraction.  Because XIP kernels are unlikely to be seen
on systems needing highmem support, there shouldn't be any shortage of
VM space for modules (14 MB for modules is still way more than twice the
typical usage).

Because the virtual mapping of highmem pages can go away at any moment
after kunmap() is called on them, we need to bypass the delayed cache
flushing provided by flush_dcache_page() in that case.

The atomic kmap versions are based on fixmaps, and
__cpuc_flush_dcache_page() is used directly in that case.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The kmap virtual area borrows a 2MB range at the top of the 16MB area
below PAGE_OFFSET currently reserved for kernel modules and/or the
XIP kernel.  This 2MB corresponds to the range covered by 2 consecutive
second-level page tables, or a single pmd entry as seen by the Linux
page table abstraction.  Because XIP kernels are unlikely to be seen
on systems needing highmem support, there shouldn't be any shortage of
VM space for modules (14 MB for modules is still way more than twice the
typical usage).

Because the virtual mapping of highmem pages can go away at any moment
after kunmap() is called on them, we need to bypass the delayed cache
flushing provided by flush_dcache_page() in that case.

The atomic kmap versions are based on fixmaps, and
__cpuc_flush_dcache_page() is used directly in that case.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] remove a common set of __virt_to_bus definitions</title>
<updated>2008-11-28T15:36:49+00:00</updated>
<author>
<name>Nicolas Pitre</name>
<email>nico@cam.org</email>
</author>
<published>2008-09-06T01:53:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b5ee9002583fc14e6d45a04c18f208987a8fbced'/>
<id>b5ee9002583fc14e6d45a04c18f208987a8fbced</id>
<content type='text'>
Let's provide an overridable default instead of having every machine
class define __virt_to_bus and __bus_to_virt to the same thing.  What
most platforms are using is bus_addr == phys_addr so such is the default.

One exception is ebsa110 which has no DMA what so ever, so the actual
definition is not important except only for proper compilation.  Also
added a comment about the special footbridge bus translation.

Let's also remove comments alluding to set_dma_addr which is not
(and should not) be commonly used.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Let's provide an overridable default instead of having every machine
class define __virt_to_bus and __bus_to_virt to the same thing.  What
most platforms are using is bus_addr == phys_addr so such is the default.

One exception is ebsa110 which has no DMA what so ever, so the actual
definition is not important except only for proper compilation.  Also
added a comment about the special footbridge bus translation.

Let's also remove comments alluding to set_dma_addr which is not
(and should not) be commonly used.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] unconditionally define __virt_to_phys and __phys_to_virt</title>
<updated>2008-11-28T15:36:48+00:00</updated>
<author>
<name>Nicolas Pitre</name>
<email>nico@cam.org</email>
</author>
<published>2008-09-05T20:05:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=75f4aa15cf05ce6d99c8261cf57dcd749877fd1c'/>
<id>75f4aa15cf05ce6d99c8261cf57dcd749877fd1c</id>
<content type='text'>
There is no machine class overriding this.  If non linear translations
are implemented again for some machines then this could be restored at
that time.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is no machine class overriding this.  If non linear translations
are implemented again for some machines then this could be restored at
that time.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] fix naming of MODULE_START / MODULE_END</title>
<updated>2008-11-06T17:13:47+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk@dyn-67.arm.linux.org.uk</email>
</author>
<published>2008-11-06T17:11:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ab4f2ee130d5ffcf35616e1f5c6ab75af5b463b6'/>
<id>ab4f2ee130d5ffcf35616e1f5c6ab75af5b463b6</id>
<content type='text'>
As of 73bdf0a60e607f4b8ecc5aec597105976565a84f, the kernel needs
to know where modules are located in the virtual address space.
On ARM, we located this region between MODULE_START and MODULE_END.
Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END.
Update ARM to use the same naming, so is_vmalloc_or_module_addr()
can work properly.  Also update the comment on mm/vmalloc.c to
reflect that ARM also places modules in a separate region from the
vmalloc space.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As of 73bdf0a60e607f4b8ecc5aec597105976565a84f, the kernel needs
to know where modules are located in the virtual address space.
On ARM, we located this region between MODULE_START and MODULE_END.
Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END.
Update ARM to use the same naming, so is_vmalloc_or_module_addr()
can work properly.  Also update the comment on mm/vmalloc.c to
reflect that ARM also places modules in a separate region from the
vmalloc space.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] 5295/1: make ZONE_DMA optional</title>
<updated>2008-10-09T20:29:46+00:00</updated>
<author>
<name>Nicolas Pitre</name>
<email>nico@cam.org</email>
</author>
<published>2008-10-07T19:14:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3bca103a1e658d23737d20e1989139d9ca8973bf'/>
<id>3bca103a1e658d23737d20e1989139d9ca8973bf</id>
<content type='text'>
Most ARM machines don't need a special "DMA" memory zone, and
when configured out, the kernel becomes a bit smaller:

|   text    data     bss     dec     hex filename
|3826182  102384  111700 4040266  3da64a vmlinux
|3823593  101616  111700 4036909  3d992d vmlinux.nodmazone

This is because the system now has only one zone total which effect is
to optimize away many conditionals in page allocation paths.

So let's configure this zone only on machines that need split zones.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most ARM machines don't need a special "DMA" memory zone, and
when configured out, the kernel becomes a bit smaller:

|   text    data     bss     dec     hex filename
|3826182  102384  111700 4040266  3da64a vmlinux
|3823593  101616  111700 4036909  3d992d vmlinux.nodmazone

This is because the system now has only one zone total which effect is
to optimize away many conditionals in page allocation paths.

So let's configure this zone only on machines that need split zones.

Signed-off-by: Nicolas Pitre &lt;nico@marvell.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ARM] mm: move vmalloc= parsing to arch/arm/mm/mmu.c</title>
<updated>2008-09-30T20:34:16+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk@dyn-67.arm.linux.org.uk</email>
</author>
<published>2008-09-30T18:31:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6c5da7aced798c7781f054a76c769b85f0173561'/>
<id>6c5da7aced798c7781f054a76c769b85f0173561</id>
<content type='text'>
There's no point scattering this around the tree, the parsing
of the parameter might as well live beside the code which uses
it.  That also means we can make vmalloc_reserve a static
variable.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There's no point scattering this around the tree, the parsing
of the parameter might as well live beside the code which uses
it.  That also means we can make vmalloc_reserve a static
variable.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
