From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754164AbcLINdg (ORCPT ); Fri, 9 Dec 2016 08:33:36 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:33968 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753633AbcLINdd (ORCPT ); Fri, 9 Dec 2016 08:33:33 -0500 Date: Fri, 9 Dec 2016 14:33:39 +0100 From: Daniel Vetter To: Benjamin Herrenschmidt Cc: Daniel Vetter , Geert Uytterhoeven , Thomas Petazzoni , Tomi Valkeinen , Greg Kroah-Hartman , Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Sudip Mukherjee , Teddy Wang , Arnaud Patard , DRI Development , Linux Fbdev development list , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Message-ID: <20161209133339.3cpvuxerimoc5huf@phenom.ffwll.local> Mail-Followup-To: Benjamin Herrenschmidt , Geert Uytterhoeven , Thomas Petazzoni , Tomi Valkeinen , Greg Kroah-Hartman , Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Sudip Mukherjee , Teddy Wang , Arnaud Patard , DRI Development , Linux Fbdev development list , "linux-kernel@vger.kernel.org" References: <20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local> <20161208153735.74d7d350@free-electrons.com> <20161208152134.wnv4j4i6m5xpoycp@phenom.ffwll.local> <1481232877.26959.52.camel@kernel.crashing.org> <1481234249.26959.55.camel@kernel.crashing.org> <20161209083442.peoriqsto2llvl2t@phenom.ffwll.local> <1481283856.27965.11.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1481283856.27965.11.camel@kernel.crashing.org> X-Operating-System: Linux phenom 4.8.0-1-amd64 User-Agent: NeoMutt/20161104 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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