From: Tony Lindgren <tony@atomide.com>
To: "Aguirre Rodriguez, Sergio Alberto" <saaguirre@ti.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 3b/6] omap: Split vmalloc.h for mach-omap1 and mach-omap2
Date: Tue, 20 Oct 2009 10:42:23 -0700 [thread overview]
Message-ID: <20091020174223.GH12576@atomide.com> (raw)
In-Reply-To: <A24693684029E5489D1D202277BE89444CFD9E9C@dlee02.ent.ti.com>
* Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com> [091020 10:15]:
> Tony,
>
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org
> > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Tuesday, October 20, 2009 11:57 AM
> > To: linux-arm-kernel@lists.infradead.org
> > Cc: linux-omap@vger.kernel.org
> > Subject: [PATCH 3b/6] omap: Split vmalloc.h for mach-omap1
> > and mach-omap2
> >
> > I've added a patch to split vmalloc.h into this series to allow
> > different VMALLOC_END on omap1 and omap2.
> >
> > Regards,
> >
> > Tony
> >
> > From 72464dbae2749dd57bc2b3cd57d4fc6ba7abca37 Mon Sep 17 00:00:00 2001
> > From: Tony Lindgren <tony@atomide.com>
> > Date: Mon, 19 Oct 2009 17:26:29 -0700
> > Subject: [PATCH] omap: Split vmalloc.h for mach-omap1 and mach-omap2
> >
> > Earlier patch "omap: Remap L3, L4 to get more kernel io address space"
> > changed the VMALLOC_END.
> >
> > However, this change causes problems on mach-omap1:
> >
> > BUG: mapping for 0xe0000000 at 0xe0000000 overlaps vmalloc space
> > BUG: mapping for 0xe1000000 at 0xe1000000 overlaps vmalloc space
> >
> > Fix this by creating separate vmalloc.h files for mach-omap1
> > and mach-omap2.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h
> > b/arch/arm/mach-omap1/include/mach/vmalloc.h
> > similarity index 86%
> > copy from arch/arm/plat-omap/include/mach/vmalloc.h
> > copy to arch/arm/mach-omap1/include/mach/vmalloc.h
> > index fc338a5..1b2af14 100644
> > --- a/arch/arm/plat-omap/include/mach/vmalloc.h
> > +++ b/arch/arm/mach-omap1/include/mach/vmalloc.h
> > @@ -1,5 +1,5 @@
> > /*
> > - * arch/arm/plat-omap/include/mach/vmalloc.h
> > + * arch/arm/mach-omap1/include/mach/vmalloc.h
>
> I thought that keeping file paths was discouraged...
>
> Why not getting rid of it to avoid changing it every time?
Well mostly to keep things consistent with existing files.
If we want to, we can do a separate series to remove the
paths for all the files later on.
Regards,
Tony
> Regards,
> Sergio
> > *
> > * Copyright (C) 2000 Russell King.
> > *
> > @@ -17,8 +17,4 @@
> > * along with this program; if not, write to the Free Software
> > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> > 02111-1307 USA
> > */
> > -#ifdef CONFIG_ARCH_OMAP1
> > #define VMALLOC_END (PAGE_OFFSET + 0x18000000)
> > -#else
> > -#define VMALLOC_END (PAGE_OFFSET + 0x38000000)
> > -#endif
> > diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h
> > b/arch/arm/mach-omap2/include/mach/vmalloc.h
> > similarity index 85%
> > rename from arch/arm/plat-omap/include/mach/vmalloc.h
> > rename to arch/arm/mach-omap2/include/mach/vmalloc.h
> > index fc338a5..9ce9b6e 100644
> > --- a/arch/arm/plat-omap/include/mach/vmalloc.h
> > +++ b/arch/arm/mach-omap2/include/mach/vmalloc.h
> > @@ -17,8 +17,4 @@
> > * along with this program; if not, write to the Free Software
> > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> > 02111-1307 USA
> > */
> > -#ifdef CONFIG_ARCH_OMAP1
> > -#define VMALLOC_END (PAGE_OFFSET + 0x18000000)
> > -#else
> > -#define VMALLOC_END (PAGE_OFFSET + 0x38000000)
> > -#endif
> > +#define VMALLOC_END (PAGE_OFFSET + 0x38000000)
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3b/6] omap: Split vmalloc.h for mach-omap1 and mach-omap2
Date: Tue, 20 Oct 2009 10:42:23 -0700 [thread overview]
Message-ID: <20091020174223.GH12576@atomide.com> (raw)
In-Reply-To: <A24693684029E5489D1D202277BE89444CFD9E9C@dlee02.ent.ti.com>
* Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com> [091020 10:15]:
> Tony,
>
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org
> > [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Tuesday, October 20, 2009 11:57 AM
> > To: linux-arm-kernel at lists.infradead.org
> > Cc: linux-omap at vger.kernel.org
> > Subject: [PATCH 3b/6] omap: Split vmalloc.h for mach-omap1
> > and mach-omap2
> >
> > I've added a patch to split vmalloc.h into this series to allow
> > different VMALLOC_END on omap1 and omap2.
> >
> > Regards,
> >
> > Tony
> >
> > From 72464dbae2749dd57bc2b3cd57d4fc6ba7abca37 Mon Sep 17 00:00:00 2001
> > From: Tony Lindgren <tony@atomide.com>
> > Date: Mon, 19 Oct 2009 17:26:29 -0700
> > Subject: [PATCH] omap: Split vmalloc.h for mach-omap1 and mach-omap2
> >
> > Earlier patch "omap: Remap L3, L4 to get more kernel io address space"
> > changed the VMALLOC_END.
> >
> > However, this change causes problems on mach-omap1:
> >
> > BUG: mapping for 0xe0000000 at 0xe0000000 overlaps vmalloc space
> > BUG: mapping for 0xe1000000 at 0xe1000000 overlaps vmalloc space
> >
> > Fix this by creating separate vmalloc.h files for mach-omap1
> > and mach-omap2.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h
> > b/arch/arm/mach-omap1/include/mach/vmalloc.h
> > similarity index 86%
> > copy from arch/arm/plat-omap/include/mach/vmalloc.h
> > copy to arch/arm/mach-omap1/include/mach/vmalloc.h
> > index fc338a5..1b2af14 100644
> > --- a/arch/arm/plat-omap/include/mach/vmalloc.h
> > +++ b/arch/arm/mach-omap1/include/mach/vmalloc.h
> > @@ -1,5 +1,5 @@
> > /*
> > - * arch/arm/plat-omap/include/mach/vmalloc.h
> > + * arch/arm/mach-omap1/include/mach/vmalloc.h
>
> I thought that keeping file paths was discouraged...
>
> Why not getting rid of it to avoid changing it every time?
Well mostly to keep things consistent with existing files.
If we want to, we can do a separate series to remove the
paths for all the files later on.
Regards,
Tony
> Regards,
> Sergio
> > *
> > * Copyright (C) 2000 Russell King.
> > *
> > @@ -17,8 +17,4 @@
> > * along with this program; if not, write to the Free Software
> > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> > 02111-1307 USA
> > */
> > -#ifdef CONFIG_ARCH_OMAP1
> > #define VMALLOC_END (PAGE_OFFSET + 0x18000000)
> > -#else
> > -#define VMALLOC_END (PAGE_OFFSET + 0x38000000)
> > -#endif
> > diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h
> > b/arch/arm/mach-omap2/include/mach/vmalloc.h
> > similarity index 85%
> > rename from arch/arm/plat-omap/include/mach/vmalloc.h
> > rename to arch/arm/mach-omap2/include/mach/vmalloc.h
> > index fc338a5..9ce9b6e 100644
> > --- a/arch/arm/plat-omap/include/mach/vmalloc.h
> > +++ b/arch/arm/mach-omap2/include/mach/vmalloc.h
> > @@ -17,8 +17,4 @@
> > * along with this program; if not, write to the Free Software
> > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
> > 02111-1307 USA
> > */
> > -#ifdef CONFIG_ARCH_OMAP1
> > -#define VMALLOC_END (PAGE_OFFSET + 0x18000000)
> > -#else
> > -#define VMALLOC_END (PAGE_OFFSET + 0x38000000)
> > -#endif
> > +#define VMALLOC_END (PAGE_OFFSET + 0x38000000)
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-omap" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
next prev parent reply other threads:[~2009-10-20 17:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-14 21:48 [PATCH 0/6] Reorganize omap headers to have include/plat Tony Lindgren
2009-10-14 21:48 ` Tony Lindgren
2009-10-14 21:48 ` [PATCH 1/6] omap: headers: Add mach patch to include files Tony Lindgren
2009-10-14 21:48 ` Tony Lindgren
2009-10-14 22:54 ` Tony Lindgren
2009-10-14 22:54 ` Tony Lindgren
2009-10-14 21:49 ` [PATCH 2/6] omap: headers: Split debug-macro.S for mach-omap1 and mach-omap2 Tony Lindgren
2009-10-14 21:49 ` Tony Lindgren
2009-10-14 21:49 ` [PATCH 3/6] omap: headers: Split entry-macro.S " Tony Lindgren
2009-10-14 21:49 ` Tony Lindgren
2009-10-20 16:57 ` [PATCH 3b/6] omap: Split vmalloc.h " Tony Lindgren
2009-10-20 16:57 ` Tony Lindgren
2009-10-20 17:15 ` Aguirre Rodriguez, Sergio Alberto
2009-10-20 17:15 ` Aguirre Rodriguez, Sergio Alberto
2009-10-20 17:42 ` Tony Lindgren [this message]
2009-10-20 17:42 ` Tony Lindgren
2009-10-14 21:49 ` [PATCH 4/6] omap: headers: Move mtd-xip.h to be mach-omap1 specific Tony Lindgren
2009-10-14 21:49 ` Tony Lindgren
2009-10-14 21:49 ` [PATCH 5/6] omap: headers: Create headers necessary for compile under mach-omap1 and mach-omap2 Tony Lindgren
2009-10-14 21:49 ` Tony Lindgren
2009-10-20 16:58 ` Tony Lindgren
2009-10-20 16:58 ` Tony Lindgren
[not found] ` <20091014215009.30227.1464.stgit@kaulin.muru.com>
2009-10-14 23:16 ` [PATCH 6/6] omap: headers: Move remaining headers from include/mach to include/plat Tony Lindgren
2009-10-14 23:16 ` 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=20091020174223.GH12576@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=saaguirre@ti.com \
/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.