Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752956AbbBWPiI (ORCPT ); Mon, 23 Feb 2015 10:38:08 -0500 Received: from mail-we0-f176.google.com ([74.125.82.176]:38098 "EHLO mail-we0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752714AbbBWPiE (ORCPT ); Mon, 23 Feb 2015 10:38:04 -0500 Date: Mon, 23 Feb 2015 16:39:40 +0100 From: Daniel Vetter To: Rob Clark Cc: Archit Taneja , "dri-devel@lists.freedesktop.org" , linux-arm-msm , Linux Kernel Mailing List , Daniel Vetter Subject: Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set Message-ID: <20150223153940.GZ24485@phenom.ffwll.local> Mail-Followup-To: Rob Clark , Archit Taneja , "dri-devel@lists.freedesktop.org" , linux-arm-msm , Linux Kernel Mailing List References: <1424687361-17787-1-git-send-email-architt@codeaurora.org> <20150223140903.GY24485@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 3.16-2-amd64 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3296 Lines: 68 On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: > On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter wrote: > > On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote: > >> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja wrote: > >> > The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is > >> > selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev > >> > support is disabled in msm. Wrap around these functions with #ifdef checks to > >> > prevent build break. > >> > >> hmm, perhaps rather than solving this in each driver, we should do > >> some stub versions of those fb-helper fxns? > >> > >> There are at least one or two other drivers that can build without > >> fbdev, and I guess more going forward.. > > > > It's not quite that easy since you also have to start/stop the vt > > subsystem at the right point in time in your own driver. See > > intel_fbdev_set_suspend. If you don't do that there's no synchronization > > between fbcon shutting down/resuming and your driver, which in the best > > case means fbcon does some writes to nowhere and worst case means your > > chip dies (mmio to offline chip blocks) or writes go to somewhere random > > in system memory (iommu contains some stale ptes since not yet fully > > restored, more an issue with hibernate). > > I guess I don't fully follow the vt/fbcon interaction if there is no > fbdev driver... but then again I don't have vesafb/efifb to contend > with, so I'm assuming something to do with that.. It's the other way round: There's interaction when we have fbdev enabled beyond just calling a few fbdev helper functions. And we should compile that out too since the console_lock is way too evil ;-) Only with these additional #ifdefs is i915 completely console_lock free if you disable i915 fbdev support. Just stubbing out the fbdev helper functions is not enough. > > And because the console_lock is massively contended we do that in a async > > worker in i915. > > > > But anyway I agree it would still simply drivers quite a bit if we'd have > > support for dummy fb helpers in the core, maybe with an explicit Kconfig. > > Then drivers could switch to using that for the additional #ifdef (like > > the vt stuff i915 does) and otherwise rely upon dummy static inline. That > > would give us fbdev-less support for most drivers for free, which is kinda > > neat. > > I guess at least for all the arm drivers, life without fbdev doesn't > have these extra complications, so at least they could use stubs.. Does the problem sound more tricky with the above clarification? If you don't do the fb_set_suspend call then I expect you'll have some interesting problems. > Plus, I kind of expect phone/tablet/chromebook type stuff would lead > the charge into an fbdev-less world.. Yeah, that's another reason to support fbdev-less in the helpers instead of each driver. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/