All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	linux-fbdev@vger.kernel.org,
	Tomi Valkeinen <tomi.valkeinen@nokia.com>
Subject: Re: Mainline OMAP3 breakage (and other OMAP?)
Date: Thu, 2 Dec 2010 14:32:08 -0800	[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
--
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: Mainline OMAP3 breakage (and other OMAP?)
Date: Thu, 2 Dec 2010 14:32:08 -0800	[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

  reply	other threads:[~2010-12-02 22:32 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 [this message]
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
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=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 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.