Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933306AbcLINfI (ORCPT ); Fri, 9 Dec 2016 08:35:08 -0500 Received: from mail-wj0-f196.google.com ([209.85.210.196]:36280 "EHLO mail-wj0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753632AbcLINfF (ORCPT ); Fri, 9 Dec 2016 08:35:05 -0500 Date: Fri, 9 Dec 2016 14:35:12 +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: <20161209133512.nuohi42ho3rgghau@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> <20161209084154.rp4wqzv46tuvf3jv@phenom.ffwll.local> <1481284087.27965.13.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1481284087.27965.13.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 Content-Length: 1903 Lines: 40 On Fri, Dec 09, 2016 at 10:48:07PM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote: > > > > And since I failed to make this clear: There's not really a > > fundamental > > reason ast and cirrus use the dirty tracking for fbdev. It's just that > > doing it that way was the fastest way to get those servers booting, and > > ever since no one cared. It's a bit tricky to do right because fbdev > > assumes it always own the framebuffer and that it never moves, > > That can be worked around from my memories of hacking fbdev many years > ago. Basically fbdev only owns it if it's the current VT and you can > make it release it if the user switches to KD_GRAPHICS which userspace > should always do before taking over. > > As for multi userspace client, well, swapping an mmap between HW and > memory backing store is a somewhat solved problem already. Hm, I didn't know that, but then all existing drm drivers have fairly simplistic fbdev mmap implementations. > > whereas drm has a multi-master model and proper isolation. IIrc we've hacked up > > something once, and if there's indeed more interest into vram dumb buffer > > drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma > > fb helpers we have) to make it all pretty and nice and fast and > > essentially plug-in-and-forget from a driver authors pov. > > That would be nice. I don't have the bandwidth to swap-in enough > understanding of TTM guts right now but I might look into it some time next? > year if nobody beats me to it. Probably best would be to first extract some helpers for ttm based vram dumb buffer management, and then start to implement some of the improvements so that all drivers can benefit. Like you've said it's not rocket science, it just needs to be done ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch