From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932310AbcEXQ2s (ORCPT ); Tue, 24 May 2016 12:28:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:51764 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751148AbcEXQ2r (ORCPT ); Tue, 24 May 2016 12:28:47 -0400 Subject: Re: [PATCH 2/3] Define fb_open_adj_file() To: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, eich@suse.de, thellstrom@vmware.com, tomi.valkeinen@ti.com References: <1464000533-13140-1-git-send-email-mstaudt@suse.de> <1464000533-13140-3-git-send-email-mstaudt@suse.de> <20160523134457.GZ27098@phenom.ffwll.local> From: Max Staudt Message-ID: <5744813C.5080909@suse.de> Date: Tue, 24 May 2016 18:28:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160523134457.GZ27098@phenom.ffwll.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, Thanks for the feedback! Comments below: On 05/23/2016 03:44 PM, Daniel Vetter wrote: > Do we _really_ care about fbdev mmap support so much that we want to add > more hacks all over the place (in each driver) to make it work? Given that > fbdev is officially in the "no more drivers" territory, I'm not sure we > want this either. > > The trouble is that fbdev mmap and kms dumb buffer mmap have different > semantics and so every driver needs to implement both if they're special > in any kind of way. DRM drivers already have fbdev hacks in place in order to implement both semantics. With this change, only bochsdrm(fb) will need to be touched, and if no further DRM driver implements fbdev support the way bochsdrmfb does, then no further driver will need this code. This patch set is really just about setting file->f_mapping in bochsdrmfb's fb_open(), so we finally get rid of the WARNING. We could also pass file as a third paramenter in fb_open(), changing the function definition in all fbdev drivers. I'm happy to change the patch in that way if this is preferred. > If we can't say no to fbdev mmap then I think we should implement > something that works for all drivers. I'm thinking of allocating just a > pile of pages in the fbdev emulation, and then copying them over using the > defio stuff we just merged for 4.7 into a dumb bo, plus calling dirtyfb. > Or at least something along those lines. Of couse just opt-in, in case the > driver can do a more traditional mmio fbdev mmapping. Well, the mmap code is standard fbdev and it's already there, so why not keep it? All this patch series does is allowing bochsdrmfb to work properly until fbdev support is finally removed from the kernel. Max