Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752813AbcLIVOd (ORCPT ); Fri, 9 Dec 2016 16:14:33 -0500 Received: from gate.crashing.org ([63.228.1.57]:40184 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756AbcLIVOb (ORCPT ); Fri, 9 Dec 2016 16:14:31 -0500 Message-ID: <1481315223.17253.15.camel@kernel.crashing.org> Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers From: Benjamin Herrenschmidt To: Daniel Vetter Cc: 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" Date: Sat, 10 Dec 2016 07:27:03 +1100 In-Reply-To: <20161209133512.nuohi42ho3rgghau@phenom.ffwll.local> 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> <20161209133512.nuohi42ho3rgghau@phenom.ffwll.local> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.2 (3.22.2-1.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2075 Lines: 48 On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote: > > 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. Hrm, I though the TTM did it ... I remember talking with Thomas Hellstrom about that back in the day... you use unmap_mapping_range to unmap the existing mappings basically so you can take new faults and route them to a different page, but I can't see a call in there so maybe he ended up not doing it. We used to do that on Cell to "context switch" the local memory of the SPU engines between the real SPU and the backing store. It's not very hard to do. The main issue is that the mapping attributes change between cached and non-cached under the hood, so users have to be careful not to do things like use instructions that only work on one type of mapping (or do things like misaligned accesses). > > > 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 ;-) Right :-) Though getting ones head around the infrastructure in the DRM does take time :-) There's a lot of stuff in there, between TTM, GEM etc... and not all of it completely "obvious" ... Cheers, Ben. > -Daniel > --