[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1481289555.8389.1.camel@pengutronix.de>
Date: Fri, 09 Dec 2016 14:19:15 +0100
From: Lucas Stach <l.stach@...gutronix.de>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Daniel Vetter <daniel@...ll.ch>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
Teddy Wang <teddy.wang@...iconmotion.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
DRI Development <dri-devel@...ts.freedesktop.org>,
Tomi Valkeinen <tomi.valkeinen@...com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Arnaud Patard <arnaud.patard@...-net.org>
Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers
Am Freitag, den 09.12.2016, 22:44 +1100 schrieb Benjamin Herrenschmidt:
> On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:
> > Yeah if you have discrete vram then your dumb display driver isn't all
> > that pretty. We essentially just have the few drivers Dave hacked up to be
> > able to boot some servers. And there's definitely lots of room for more
> > shared code for those, and also some better infrastructure and helpers to
> > share more cod and make them better.
> >
> > The massive pile of dumb framebuffers we all merged over the past 2 years
> > all use system/dma memory for scanout, and for those we have the very nice
> > cma helpers that take care of everything for you.
>
> Do they work if the system/DMA memory has to be physically contiguous
> and at a fixed address ? The AST "ARM side" GPU is like that.
Yes, CMA is exactly the solution for that. It provides contiguous memory
that doesn't need to be removed from the normal Linux memory handling
and allows for the CMA region to be at specific places if needed. It's
just a matter of describing the constraints properly.
Regards,
Lucas
Powered by blists - more mailing lists