linux-kernel - Re: [RFC PATCH 0/3] staging: remove fbdev drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161209133339.3cpvuxerimoc5huf@phenom.ffwll.local>
Date:   Fri, 9 Dec 2016 14:33:39 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Noralf Trønnes <noralf@...nnes.org>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Teddy Wang <teddy.wang@...iconmotion.com>,
        Arnaud Patard <arnaud.patard@...-net.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, Dec 09, 2016 at 10:44:16PM +1100, Benjamin Herrenschmidt wrote:
> 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.

Yeah, if you wire up the dma_alloc_coherent to cma you'll get a contiguous
buffer pinned into place.

> > So it is possible, only reason vram dumb buffers look worse is that there's
> > only 3 and no one cares about them, vs about 20 and a very active community
> > of contributors (also for core drm improvements) for the other case.
> 
> Well, we could move offb to drm while at it I suppose that would be another
> one (offb is the "dumb driver based on pre-programmed output by firmware).

One of the still in-flight drm drivers is the simpledrm thing meant for
all kinds of firmware drivers like efifb and similar things on arm for
pre-programmed output set up by firmware. I.e. no modeset support and
otherwise a lot of fake to make it work as drm driver, but the idea that
it's good enough until your real drm driver takes over.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch