Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752504AbbBWOHa (ORCPT ); Mon, 23 Feb 2015 09:07:30 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:39506 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752341AbbBWOH1 (ORCPT ); Mon, 23 Feb 2015 09:07:27 -0500 Date: Mon, 23 Feb 2015 15:09:03 +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: <20150223140903.GY24485@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> 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: 1987 Lines: 41 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). 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. -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/