From: Tony Lindgren <tony@atomide.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/4] ARM: OMAP: Remove calls to SRAM allocations for framebuffer
Date: Thu, 6 Oct 2011 09:22:40 -0700 [thread overview]
Message-ID: <20111006162239.GI6324@atomide.com> (raw)
In-Reply-To: <1317890284.1945.38.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [111006 01:04]:
> On Wed, 2011-10-05 at 15:41 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [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@ti.com>
> > > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > >
> > > Looks good to me. I have similar changes in my working branch for omapfb
> > > cleanup.
> > >
> > > Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >
> > 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
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] ARM: OMAP: Remove calls to SRAM allocations for framebuffer
Date: Thu, 6 Oct 2011 09:22:40 -0700 [thread overview]
Message-ID: <20111006162239.GI6324@atomide.com> (raw)
In-Reply-To: <1317890284.1945.38.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [111006 01:04]:
> On Wed, 2011-10-05 at 15:41 -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [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@ti.com>
> > > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > >
> > > Looks good to me. I have similar changes in my working branch for omapfb
> > > cleanup.
> > >
> > > Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >
> > 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
next prev parent reply other threads:[~2011-10-06 16:22 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 0:45 [PATCH 0/4] initialize omap SRAM later on with __arm_ioremap_exec() Tony Lindgren
2011-10-05 0:45 ` Tony Lindgren
2011-10-05 0:45 ` [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY Tony Lindgren
2011-10-05 0:45 ` Tony Lindgren
2011-10-05 1:00 ` Nicolas Pitre
2011-10-05 1:00 ` Nicolas Pitre
2011-10-05 22:06 ` Tony Lindgren
2011-10-05 22:06 ` Tony Lindgren
2011-10-05 22:08 ` [PATCH 1.5/4] ARM: OMAP1: Use generic map_io, init_early and init_irq Tony Lindgren
2011-10-05 22:08 ` Tony Lindgren
2011-10-07 6:40 ` [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY Santosh Shilimkar
2011-10-07 6:40 ` Santosh Shilimkar
2011-10-07 14:43 ` Tony Lindgren
2011-10-07 14:43 ` Tony Lindgren
2011-10-07 15:03 ` Santosh Shilimkar
2011-10-07 15:03 ` Santosh Shilimkar
2011-10-07 15:11 ` Tony Lindgren
2011-10-07 15:11 ` Tony Lindgren
2011-10-07 17:39 ` Santosh Shilimkar
2011-10-07 17:39 ` Santosh Shilimkar
2011-10-07 18:16 ` Tony Lindgren
2011-10-07 18:16 ` Tony Lindgren
2011-10-07 18:20 ` Santosh Shilimkar
2011-10-07 18:20 ` Santosh Shilimkar
2011-10-07 18:27 ` Tony Lindgren
2011-10-07 18:27 ` Tony Lindgren
2011-10-05 0:45 ` [PATCH 2/4] ARM: OMAP: Avoid cpu_is_omapxxxx usage until map_io is done Tony Lindgren
2011-10-05 0:45 ` Tony Lindgren
2011-10-07 6:47 ` Santosh Shilimkar
2011-10-07 6:47 ` Santosh Shilimkar
2011-10-05 0:45 ` [PATCH 3/4] ARM: OMAP: Remove calls to SRAM allocations for framebuffer Tony Lindgren
2011-10-05 0:45 ` Tony Lindgren
2011-10-05 6:45 ` Tomi Valkeinen
2011-10-05 6:45 ` Tomi Valkeinen
2011-10-05 22:41 ` Tony Lindgren
2011-10-05 22:41 ` Tony Lindgren
2011-10-06 8:38 ` Tomi Valkeinen
2011-10-06 8:38 ` Tomi Valkeinen
2011-10-06 16:22 ` Tony Lindgren [this message]
2011-10-06 16:22 ` Tony Lindgren
2011-10-05 0:45 ` [PATCH 4/4] ARM: OMAP: Map SRAM later on with ioremap_exec() Tony Lindgren
2011-10-05 0:45 ` Tony Lindgren
2011-10-05 1:07 ` Nicolas Pitre
2011-10-05 1:07 ` Nicolas Pitre
2011-10-05 22:13 ` Tony Lindgren
2011-10-05 22:13 ` Tony Lindgren
2011-10-05 23:01 ` Nicolas Pitre
2011-10-05 23:01 ` Nicolas Pitre
2011-10-07 6:52 ` Santosh Shilimkar
2011-10-07 6:52 ` Santosh Shilimkar
2011-10-07 14:55 ` Tony Lindgren
2011-10-07 14:55 ` Tony Lindgren
2011-10-05 1:40 ` [PATCH 5/4] ARM: OMAP: Move set_globals initialization to happen in init_early Tony Lindgren
2011-10-05 1:40 ` Tony Lindgren
2011-10-05 1:51 ` Nicolas Pitre
2011-10-05 1:51 ` Nicolas Pitre
2011-10-06 1:36 ` Tony Lindgren
2011-10-06 1:36 ` Tony Lindgren
2011-10-07 6:56 ` Santosh Shilimkar
2011-10-07 6:56 ` Santosh Shilimkar
2011-10-07 14:54 ` Tony Lindgren
2011-10-07 14:54 ` Tony Lindgren
2011-10-07 23:26 ` Nicolas Pitre
2011-10-07 23:26 ` Nicolas Pitre
2011-10-05 7:03 ` [PATCH 0/4] initialize omap SRAM later on with __arm_ioremap_exec() Santosh Shilimkar
2011-10-05 7:03 ` Santosh Shilimkar
2011-10-06 1:42 ` Tony Lindgren
2011-10-06 1:42 ` Tony Lindgren
2011-10-07 6:59 ` Santosh Shilimkar
2011-10-07 6:59 ` Santosh Shilimkar
2011-10-07 14:45 ` Tony Lindgren
2011-10-07 14:45 ` Tony Lindgren
2011-10-07 20:23 ` Nicolas Pitre
2011-10-07 20:23 ` Nicolas Pitre
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=20111006162239.GI6324@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=tomi.valkeinen@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.