From: Tony Lindgren <tony@atomide.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: Mainline OMAP3 breakage (and other OMAP?)
Date: Thu, 02 Dec 2010 22:32:08 +0000 [thread overview]
Message-ID: <20101202223208.GA17222@atomide.com> (raw)
In-Reply-To: <20101202221612.GJ10461@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [101202 14:06]:
> On Thu, Dec 02, 2010 at 01:58:38PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [101202 13:04]:
> > > This has been around since October:
> > >
> > > drivers/video/omap2/vram.c: In function ■omap_vram_reserve_sdram_memblock■:
> > > drivers/video/omap2/vram.c:573: error: ■MEMBLOCK_REAL_LIMIT■ undeclared (first use in this function)
> > > drivers/video/omap2/vram.c:573: error: (Each undeclared identifier is reported only once
> > > drivers/video/omap2/vram.c:573: error: for each function it appears in.)
> > >
> > > This requires a trivial one-liner compile fix:
> > >
> > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> > > index fed2a72..a8973f0 100644
> > > --- a/drivers/video/omap2/vram.c
> > > +++ b/drivers/video/omap2/vram.c
> > > @@ -570,7 +570,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
> > > return;
> > > }
> > > } else {
> > > - paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> > > + paddr = memblock_alloc(size, PAGE_SIZE);
> > > }
> > >
> > > omap_vram_add_region(paddr, size);
> > >
> > > which restores the old behaviour before the X86 memblock changes went
> > > in. Yes, there may be other changes due to the ioremap stuff, but
> > > that's really no excuse for not fixing the compile error itself.
> >
> > Great. Adding fbdev and Tomi to Cc.
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> http://marc.info/?l=linux-omap&w=2&r=1&s=MEMBLOCK_REAL_LIMIT%20vram&q=b
>
> There have been patches posted throughout November to fix this, but
> the problem is they're not making it to mainline. It needs chasing
> until someone does the right thing and sends one variant of the above
> patch, rather than just leaving it until the ioremap fixes hit
> mainline during the next merge window.
Yes this should go in during the -rc for sure.
I suggest you merge this but let's wait a bit and check if Tomi
already has a similar fix queued for the -rc series.
Regards,
Tony
next prev parent reply other threads:[~2010-12-02 22:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101202211421.GG10461@n2100.arm.linux.org.uk>
2010-12-02 21:58 ` Mainline OMAP3 breakage (and other OMAP?) Tony Lindgren
2010-12-02 22:16 ` Russell King - ARM Linux
2010-12-02 22:32 ` Tony Lindgren [this message]
2010-12-03 3:09 ` Paul Mundt
2010-12-03 8:41 ` Russell King - ARM Linux
2010-12-03 12:10 ` Felipe Contreras
2010-12-03 13:07 ` Russell King - ARM Linux
2010-12-03 13:15 ` Felipe Contreras
2010-12-14 12:23 ` Tomi Valkeinen
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=20101202223208.GA17222@atomide.com \
--to=tony@atomide.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).