[PATCH V2] video: implement a simple framebuffer driver

[Olof Johansson]

On Tue, May 7, 2013 at 7:36 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 05/07/2013 03:33 PM, Andrew Morton wrote:
>>
>> We don't seem to have a well-defined path to travel here, and I don't
>> get the feeling that anyone has signed up to walk it?
>>
>> So I'm inclined to merge Stephen's patch as-is into 3.10.  It's pretty
>> simple and standalone.  Any strenuous objections?
>>
>> BTW, Olof told me off-list that this patch is a "critical piece" for
>> running mainline Linux on ARM Chromebooks.  That was important
>> information - more important than anything else we were told about this
>> patch!
>>
>> So Stephen, could I please have a new changelog for this patch which
>> explains this application, and any other interesting/important things
>> which were left out?  Quickly, please.
>
> OK, how about the version below:
>
> ----------
> Subject: drivers/video: implement a simple framebuffer driver
>
> 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.
>
> Examples use-cases include:
>
> * The built-in LCD panels on the Samsung ARM chromebook, and Tegra
> devices, and likely many other ARM or embedded systems. These cannot yet
> be supported using a full graphics driver, since the panel control
> should be provided by the CDF (Common Display Framework), which has been
> stuck in design/review for quite some time. One could support these
> panels using custom SoC-specific code, but there is a desire to use
> common infra-structure rather than having each SoC vendor invent their
> own code, hence the desire to wait for CDF.
>
> * Hardware for which a full graphics driver is not yet available, and
> the path to obtain one upstream isn't yet clear. For example, the
> Raspberry Pi.
>
> * Any hardware in early stages of upstreaming, before a full graphics
> driver has been tackled. This driver can provide a graphical boot
> console (even full X support) much earlier in the upstreaming process,
> thus making new SoC or board support more generally useful earlier.
> ----------
>
> I assume you can just edit the patch you have and don't need me to
> resend with the adjusted description.

Oh, looks like it never got a:

Acked-by: Olof Johansson <olof at lixom.net>

Either. Feel free to add, Andrew.


-Olof