From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] Linux support for ARM LPAE
Date: Wed, 7 Dec 2011 12:25:44 +0000 [thread overview]
Message-ID: <20111207122544.GD23720@arm.com> (raw)
In-Reply-To: <20111207112320.GB23720@arm.com>
On Wed, Dec 07, 2011 at 11:23:20AM +0000, Catalin Marinas wrote:
> On Tue, Dec 06, 2011 at 11:30:58PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Dec 06, 2011 at 02:07:29PM +0000, Catalin Marinas wrote:
> > > This patch wasn't
> > > originally part of my LPAE series as I hoped you would have merged it
> > > during the last cycle. Now it had to be part of the pull request as LPAE
> > > patches depend on it.
> >
> > I've stated many times why it's not merged, and for the N'th time: it
> > generates warnings. I'm _not_ merging something that is known to add
> > warnings such as those which this patch produces without there being a
> > fix for it. You know that _very well_ because I've said it several
> > times, not only by email but also on our various phone calls.
> >
> > I've dealt with this patch in exactly the same way at every merge window
> > we've had for the last _year_ - I've queued it up with the expectation
> > that hopefully someone would fix the warnings, the warnings didn't get
> > fixed, so it got dropped from the pull request. Immediately after the
> > merge window (which includes this) it gets reinstated back into
> > linux-next.
>
> Yes, I'm fully aware, and I sent you a fix-up in the past. I can
> re-write that fix-up in a few other ways if you don't like the current
> one, just let me know.
OK, I took the time to implement another RFC fix-up for this. It's only
compile-tested at the moment and may need a few more tweaks but it gives
you an idea on what it tries to achieve. With the classic MMU, all the
pud_alloc/pmd_alloc just translate to pud_offset/pmd_offset so the
current behaviour should not be affected. In theory, it could work with
LPAE as well as it allocates the pmd at run-time (we don't really need
freeing them during unmap). Any thoughts?
ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud
From: Catalin Marinas <catalin.marinas@arm.com>
With the arch/arm code conversion to pgtable-nopud.h, the section and
supersection (un|re)map code triggers compiler warnings on UP systems.
This is caused by pmd_offset() being given a pgd_t argument rather than
a pud_t one. This patch makes the necessary conversion via pud_alloc()
and pmd_alloc().
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/mm/ioremap.c | 50 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index bdb248c..4827851 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -78,13 +78,20 @@ void __check_kvm_seq(struct mm_struct *mm)
static void unmap_area_sections(unsigned long virt, unsigned long size)
{
unsigned long addr = virt, end = virt + (size & ~(SZ_1M - 1));
- pgd_t *pgd;
flush_cache_vunmap(addr, end);
- pgd = pgd_offset_k(addr);
do {
- pmd_t pmd, *pmdp = pmd_offset(pgd, addr);
+ pgd_t *pgd = pgd_offset_k(addr);
+ pud_t *pud;
+ pmd_t pmd, *pmdp;
+ if (pgd_none(*pgd))
+ continue;
+ pud = pud_offset(pgd, addr);
+ if (pud_none(*pud))
+ continue;
+
+ pmdp = pmd_offset(pud, addr);
pmd = *pmdp;
if (!pmd_none(pmd)) {
/*
@@ -103,10 +110,7 @@ static void unmap_area_sections(unsigned long virt, unsigned long size)
if ((pmd_val(pmd) & PMD_TYPE_MASK) == PMD_TYPE_TABLE)
pte_free_kernel(&init_mm, pmd_page_vaddr(pmd));
}
-
- addr += PGDIR_SIZE;
- pgd++;
- } while (addr < end);
+ } while (addr += PMD_SIZE, addr < end);
/*
* Ensure that the active_mm is up to date - we want to
@@ -123,7 +127,6 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
size_t size, const struct mem_type *type)
{
unsigned long addr = virt, end = virt + size;
- pgd_t *pgd;
/*
* Remove and free any PTE-based mapping, and
@@ -131,9 +134,17 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
*/
unmap_area_sections(virt, size);
- pgd = pgd_offset_k(addr);
do {
- pmd_t *pmd = pmd_offset(pgd, addr);
+ pgd_t *pgd = pgd_offset_k(addr);
+ pud_t *pud;
+ pmd_t *pmd;
+
+ pud = pud_alloc(&init_mm, pgd, addr);
+ if (!pud)
+ return -ENOMEM;
+ pmd = pmd_alloc(&init_mm, pud, addr);
+ if (!pmd)
+ return -ENOMEM;
pmd[0] = __pmd(__pfn_to_phys(pfn) | type->prot_sect);
pfn += SZ_1M >> PAGE_SHIFT;
@@ -141,8 +152,7 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
pfn += SZ_1M >> PAGE_SHIFT;
flush_pmd_entry(pmd);
- addr += PGDIR_SIZE;
- pgd++;
+ addr += PMD_SIZE;
} while (addr < end);
return 0;
@@ -153,7 +163,6 @@ remap_area_supersections(unsigned long virt, unsigned long pfn,
size_t size, const struct mem_type *type)
{
unsigned long addr = virt, end = virt + size;
- pgd_t *pgd;
/*
* Remove and free any PTE-based mapping, and
@@ -161,23 +170,30 @@ remap_area_supersections(unsigned long virt, unsigned long pfn,
*/
unmap_area_sections(virt, size);
- pgd = pgd_offset_k(virt);
do {
+ pgd_t *pgd = pgd_offset_k(addr);
+ pud_t *pud;
unsigned long super_pmd_val, i;
+ pud = pud_alloc(&init_mm, pgd, addr);
+ if (!pud)
+ return -ENOMEM;
super_pmd_val = __pfn_to_phys(pfn) | type->prot_sect |
PMD_SECT_SUPER;
super_pmd_val |= ((pfn >> (32 - PAGE_SHIFT)) & 0xf) << 20;
for (i = 0; i < 8; i++) {
- pmd_t *pmd = pmd_offset(pgd, addr);
+ pmd_t *pmd;
+
+ pmd = pmd_alloc(&init_mm, pud, addr);
+ if (!pmd)
+ return -ENOMEM;
pmd[0] = __pmd(super_pmd_val);
pmd[1] = __pmd(super_pmd_val);
flush_pmd_entry(pmd);
- addr += PGDIR_SIZE;
- pgd++;
+ addr += PMD_SIZE;
}
pfn += SUPERSECTION_SIZE >> PAGE_SHIFT;
--
Catalin
next prev parent reply other threads:[~2011-12-07 12:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-02 18:20 [GIT PULL] Linux support for ARM LPAE Catalin Marinas
2011-12-06 12:41 ` Russell King - ARM Linux
2011-12-06 14:07 ` Catalin Marinas
2011-12-06 23:30 ` Russell King - ARM Linux
2011-12-07 11:23 ` Catalin Marinas
2011-12-07 12:25 ` Catalin Marinas [this message]
2011-12-07 20:29 ` Russell King - ARM Linux
2011-12-07 22:15 ` Catalin Marinas
2011-12-07 22:22 ` Russell King - ARM Linux
2011-12-08 0:16 ` Russell King - ARM Linux
2011-12-07 20:10 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111207122544.GD23720@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.