* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [111006 01:04]:
> On Wed, 2011-10-05 at 15:41 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [111004 23:11]:
> > > On Tue, 2011-10-04 at 17:45 -0700, Tony Lindgren wrote:
> > > > This assumes fixed mappings which will not work once we move
> > > > to use ioremap_exec(). It seems that these are currently
> > > > not in use, or in use for some out of tree corner cases.
> > > >
> > > > If SRAM support for framebuffer is wanted, it should be done
> > > > with ioremap in the driver.
> > > >
> > > > Note that further removal of the code can now be done,
> > > > but that can be done seprately by the driver maintainers.
> > > >
> > > > Cc: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
> > > > Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> > >
> > > Looks good to me. I have similar changes in my working branch for omapfb
> > > cleanup.
> > >
> > > Acked-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
> >
> > Thanks. FYI, looks like there's a warning in display.c:
> >
> > arch/arm/mach-omap2/display.c: In function 'omap_display_init':
> > arch/arm/mach-omap2/display.c:93: warning: assignment from incompatible pointer type
> >
> > Do you have a patch for that already?
>
> Paul should have a patch for that in queue ("OMAP: change
> get_context_loss_count ret value to int"). DSS is already using the new
> style function pointer, which uses int for return value (versus the
> current function which returns u32).
OK thanks.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
