linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@iki.fi>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V2] video: implement a simple framebuffer driver
Date: Tue, 30 Apr 2013 07:27:01 +0000	[thread overview]
Message-ID: <517F7245.2050606@iki.fi> (raw)
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>

Hi,

On 04/04/2013 05:39 AM, Stephen Warren wrote:
> A simple frame-buffer describes a raw memory region that may be rendered
> to, with the assumption that the display hardware has already been set
> up to scan out from that buffer.
> 
> This is useful in cases where a bootloader exists and has set up the
> display hardware, but a Linux driver doesn't yet exist for the display
> hardware.

I had an idea related to this driver. There are two requirements that I
believe are (or will be) quite common:

On embedded devices quite often the bootloader initializes the display,
with the purpose of having a valid image on the screen for the whole
boot up process (company logo, or whatever).

With multi-arch kernels, we'll have display drivers for all platforms
and panels compiled with the kernel. If all these are built-in, they
will possibly increase the kernel size quite a bit, so it would be good
to have the display drivers as modules.

Now, if we have the display drivers as modules, the point when the
kernel/userspace can update the screen will be pretty late. Also,
there's no chance to get any early kernel boot messages on the screen.

So how about if we had this kind of simple fb, built-in to the kernel,
used only for the boot time until the proper driver is loaded. A "bootfb".

The bootloader would init the display hardware, the bootfb would give an
early /dev/fb0 for the kernel and userspace, and when the real display
driver is loaded, the bootfb would be unbound and the real driver would
take over.

 Tomi


  parent reply	other threads:[~2013-04-30  7:27 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-04  2:39 [PATCH V2] video: implement a simple framebuffer driver Stephen Warren
2013-04-09  0:16 ` Andrew Morton
2013-04-09  3:16   ` Stephen Warren
2013-04-09  8:08   ` Geert Uytterhoeven
2013-04-11  9:56   ` Laurent Pinchart
2013-04-11 16:06     ` Stephen Warren
2013-04-11 20:06       ` Laurent Pinchart
2013-04-11 20:38         ` Stephen Warren
2013-04-29 20:56           ` Laurent Pinchart
2013-04-29 21:15     ` Tomasz Figa
2013-04-29 21:20       ` Laurent Pinchart
2013-04-29 21:31         ` Tomasz Figa
2013-04-29 21:40           ` Laurent Pinchart
2013-04-29 22:04             ` Arnd Bergmann
2013-04-29 22:23               ` Laurent Pinchart
2013-04-29 22:40                 ` Olof Johansson
2013-04-30  9:50                   ` Laurent Pinchart
2013-05-02 18:25               ` Stephen Warren
2013-05-02 18:35                 ` Geert Uytterhoeven
2013-05-03 10:06                 ` Laurent Pinchart
2013-05-07 21:33                   ` Andrew Morton
2013-05-08  2:36                     ` Stephen Warren
2013-05-08 19:28                       ` Olof Johansson
2013-05-08 20:58                       ` Rob Landley
2013-04-30  7:28       ` Tomi Valkeinen
2013-04-11 10:42 ` Geert Uytterhoeven
2013-04-11 16:10   ` Stephen Warren
2013-04-30  7:27 ` Tomi Valkeinen [this message]
2013-04-30 10:28   ` Arnd Bergmann
2013-04-30 11:42     ` Laurent Pinchart
2013-04-30 11:48       ` Tomi Valkeinen
2013-04-30 11:49         ` Laurent Pinchart
2013-04-30 11:46     ` Tomi Valkeinen
2013-05-03  5:40       ` Dave Airlie
2013-04-30  7:39 ` Tomi Valkeinen
2013-04-30 10:34   ` Arnd Bergmann
2013-04-30 14:38   ` Re[2]: [PATCH V2] video: implement a simple f =?UTF-8?B?cmFtZWJ1ZmZlciBkc Alexander Shiyan
2013-04-30 15:07     ` Re[2]: [PATCH V2] video: implement a simple framebuffer driver Arnd Bergmann
2013-05-18 10:29 ` Alexandre Courbot
2013-05-20 15:25   ` Stephen Warren

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=517F7245.2050606@iki.fi \
    --to=tomi.valkeinen@iki.fi \
    --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).