All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: Mainline OMAP3 breakage (and other OMAP?)
Date: Tue, 14 Dec 2010 12:23:51 +0000	[thread overview]
Message-ID: <1292329431.6893.113.camel@tubuntu> (raw)
In-Reply-To: <20101203130724.GB30957@n2100.arm.linux.org.uk>

Hi,

On Fri, 2010-12-03 at 13:07 +0000, ext Russell King - ARM Linux wrote:

> So please, 2MB, or if you object, at the _very_ _least_ 1MB.  But
> definitely not PAGE_SIZE.

Here's a patch for this. Works for me on OMAP3430SDP. If the patch is
ok, I'll send a pull request to Paul.



From 6c54704730626e2683e05574b3cbba966980c956 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Date: Tue, 14 Dec 2010 14:16:59 +0200
Subject: [PATCH] OMAP: DSS: VRAM: Align start & size of vram to 2M

Align the start address and size of VRAM area to 2M as per comments from
Russell King:

> > So, why SZ_2M?
>
> Firstly, that's the granularity which we allocate page tables - one
> Linux page table covers 2MB of memory.  We want to avoid creating page
> tables for the main memory mapping as that increases TLB pressure through
> the use of additional TLB entries, and more page table walks.
>
> Plus, we never used to allow the kernel's direct memory mapping to be
> mapped at anything less than section size - this restriction has since
> been lifted due to OMAP SRAM problems, but I'd rather we stuck with it
> to ensure that we have proper behaviour from all parts of the system.
>
> Secondly, we don't want to end up with lots of fragmentation at the end
> of the memory mapping as that'll reduce performance, not only by making
> the pfn_valid() search more expensive.
>
> Emsuring a minimum allocation size and alignment makes sure that the
> regions can be coalesced together into one block, and minimises run-time
> expenses.
>
> So please, 2MB, or if you object, at the _very_ _least_ 1MB.  But
> definitely not PAGE_SIZE.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
---
 drivers/video/omap2/vram.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index 2fd7e52..9441e2e 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -551,7 +551,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
 	if (!size)
 		return;
 
-	size = PAGE_ALIGN(size);
+	size = ALIGN(size, SZ_2M);
 
 	if (paddr) {
 		if (paddr & ~PAGE_MASK) {
@@ -576,7 +576,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
 			return;
 		}
 	} else {
-		paddr = memblock_alloc(size, PAGE_SIZE);
+		paddr = memblock_alloc(size, SZ_2M);
 	}
 
 	memblock_free(paddr, size);
-- 
1.7.1




WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
To: ext Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
	Paul Mundt <lethal@linux-sh.org>,
	Tony Lindgren <tony@atomide.com>,
	linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Mainline OMAP3 breakage (and other OMAP?)
Date: Tue, 14 Dec 2010 14:23:51 +0200	[thread overview]
Message-ID: <1292329431.6893.113.camel@tubuntu> (raw)
In-Reply-To: <20101203130724.GB30957@n2100.arm.linux.org.uk>

Hi,

On Fri, 2010-12-03 at 13:07 +0000, ext Russell King - ARM Linux wrote:

> So please, 2MB, or if you object, at the _very_ _least_ 1MB.  But
> definitely not PAGE_SIZE.

Here's a patch for this. Works for me on OMAP3430SDP. If the patch is
ok, I'll send a pull request to Paul.



>From 6c54704730626e2683e05574b3cbba966980c956 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Date: Tue, 14 Dec 2010 14:16:59 +0200
Subject: [PATCH] OMAP: DSS: VRAM: Align start & size of vram to 2M

Align the start address and size of VRAM area to 2M as per comments from
Russell King:

> > So, why SZ_2M?
>
> Firstly, that's the granularity which we allocate page tables - one
> Linux page table covers 2MB of memory.  We want to avoid creating page
> tables for the main memory mapping as that increases TLB pressure through
> the use of additional TLB entries, and more page table walks.
>
> Plus, we never used to allow the kernel's direct memory mapping to be
> mapped at anything less than section size - this restriction has since
> been lifted due to OMAP SRAM problems, but I'd rather we stuck with it
> to ensure that we have proper behaviour from all parts of the system.
>
> Secondly, we don't want to end up with lots of fragmentation at the end
> of the memory mapping as that'll reduce performance, not only by making
> the pfn_valid() search more expensive.
>
> Emsuring a minimum allocation size and alignment makes sure that the
> regions can be coalesced together into one block, and minimises run-time
> expenses.
>
> So please, 2MB, or if you object, at the _very_ _least_ 1MB.  But
> definitely not PAGE_SIZE.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
---
 drivers/video/omap2/vram.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index 2fd7e52..9441e2e 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -551,7 +551,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
 	if (!size)
 		return;
 
-	size = PAGE_ALIGN(size);
+	size = ALIGN(size, SZ_2M);
 
 	if (paddr) {
 		if (paddr & ~PAGE_MASK) {
@@ -576,7 +576,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
 			return;
 		}
 	} else {
-		paddr = memblock_alloc(size, PAGE_SIZE);
+		paddr = memblock_alloc(size, SZ_2M);
 	}
 
 	memblock_free(paddr, size);
-- 
1.7.1




WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@nokia.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: Mainline OMAP3 breakage (and other OMAP?)
Date: Tue, 14 Dec 2010 14:23:51 +0200	[thread overview]
Message-ID: <1292329431.6893.113.camel@tubuntu> (raw)
In-Reply-To: <20101203130724.GB30957@n2100.arm.linux.org.uk>

Hi,

On Fri, 2010-12-03 at 13:07 +0000, ext Russell King - ARM Linux wrote:

> So please, 2MB, or if you object, at the _very_ _least_ 1MB.  But
> definitely not PAGE_SIZE.

Here's a patch for this. Works for me on OMAP3430SDP. If the patch is
ok, I'll send a pull request to Paul.

  parent reply	other threads:[~2010-12-14 12:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-02 21:14 Mainline OMAP3 breakage (and other OMAP?) Russell King - ARM Linux
2010-12-02 21:14 ` Russell King - ARM Linux
2010-12-02 21:58 ` Tony Lindgren
2010-12-02 21:58   ` Tony Lindgren
2010-12-02 21:58   ` Tony Lindgren
2010-12-02 22:16   ` Russell King - ARM Linux
2010-12-02 22:16     ` Russell King - ARM Linux
2010-12-02 22:16     ` Russell King - ARM Linux
2010-12-02 22:32     ` Tony Lindgren
2010-12-02 22:32       ` Tony Lindgren
2010-12-02 22:32       ` Tony Lindgren
2010-12-03  3:09       ` Paul Mundt
2010-12-03  3:09         ` Paul Mundt
2010-12-03  3:09         ` Paul Mundt
2010-12-03  8:41         ` Russell King - ARM Linux
2010-12-03  8:41           ` Russell King - ARM Linux
2010-12-03  8:41           ` Russell King - ARM Linux
2010-12-03 12:10           ` Felipe Contreras
2010-12-03 12:10             ` Felipe Contreras
2010-12-03 12:10             ` Felipe Contreras
2010-12-03 13:07             ` Russell King - ARM Linux
2010-12-03 13:07               ` Russell King - ARM Linux
2010-12-03 13:07               ` Russell King - ARM Linux
2010-12-03 13:15               ` Felipe Contreras
2010-12-03 13:15                 ` Felipe Contreras
2010-12-03 13:15                 ` Felipe Contreras
2010-12-14 12:23               ` Tomi Valkeinen [this message]
2010-12-14 12:23                 ` Tomi Valkeinen
2010-12-14 12:23                 ` Tomi Valkeinen
2010-12-14 18:55                 ` Tony Lindgren
2010-12-14 18:55                   ` Tony Lindgren
2010-12-14 18:55                   ` Tony Lindgren

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=1292329431.6893.113.camel@tubuntu \
    --to=tomi.valkeinen@nokia.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.