From: Tony Lindgren <tony@atomide.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: lo-ml <linux-omap@vger.kernel.org>
Subject: Re: The old omapfb support
Date: Tue, 19 Apr 2011 15:30:36 +0300 [thread overview]
Message-ID: <20110419123036.GF15620@atomide.com> (raw)
In-Reply-To: <1303215626.32281.70.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [110419 15:17]:
> Hi Tony, All,
>
> Due to the recent SRAM discussion I started removing SRAM support from
> the new omapdss and omapfb driver, which was quite a simple task. Then I
> realized that the old omapfb driver also contains SRAM code, removing of
> which which wasn't such a simple task. I think I got that solved, but it
> needs still cleaning up.
OK
> But this again reminded me of the mess of having two display drivers,
> the old omapfb and the new DSS2. Many of the OMAP2 boards using the old
> driver should be quite easy to port to DSS2, with the exception of N800.
> DSS2 doesn't support OMAP1, so there's not much that can be done with
> those boards currently.
>
> What is the status of OMAP1 support in general? Is having a working
> framebuffer for OMAP1 boards something we need?
There are people actively using omap1 boards with the framebuffer, so
let's not mess with that except to remove the SRAM support.
> Will there be a single kernel config containing OMAP1 and OMAP2+ support
> in the future? This will cause problems, as the old and new display
> drivers cannot coexist currently.
This will not happen any time soon (if ever) because of issues supporting
anything below ARMv6 together with ARMv6 and 7 in the same kernel binary.
> I have never worked with an OMAP1 board, and I don't own one, and thus I
> don't have any experience on OMAP1 display HW. This will make any work I
> do on OMAP1 omapfb slightly difficult, but if there's clear need for
> OMAP1 fb, then I think the only way to go is to convert the old omapfb
> driver to an OMAP1 framebuffer driver.
Yeh we can just make old omapfb depends on ARCH_OMAP1.
> But whatever is decided on OMAP1 fb, I'll start converting the OMAP2
> drivers to the new DSS2.
OK great.
Tony
next prev parent reply other threads:[~2011-04-19 12:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 12:20 The old omapfb support Tomi Valkeinen
2011-04-19 12:30 ` Tony Lindgren [this message]
2011-04-19 12:34 ` Michael Büsch
2011-04-19 12:41 ` Tomi Valkeinen
2011-04-19 12:45 ` Michael Büsch
2011-04-20 8:06 ` Tomi Valkeinen
2011-04-20 11:18 ` Michael Büsch
2011-04-20 11:31 ` Tomi Valkeinen
2011-04-20 11:35 ` Michael Büsch
2011-04-29 13:33 ` N8x0 display support (was: Re: The old omapfb support) Tomi Valkeinen
2011-04-29 14:08 ` Jarkko Nikula
2011-04-29 21:04 ` Michael Büsch
2011-04-29 21:05 ` Michael Büsch
2011-04-30 6:01 ` Tomi Valkeinen
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=20110419123036.GF15620@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap@vger.kernel.org \
--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.