Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753172AbbBWPDY (ORCPT ); Mon, 23 Feb 2015 10:03:24 -0500 Received: from mail-ie0-f177.google.com ([209.85.223.177]:34878 "EHLO mail-ie0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752317AbbBWPDW (ORCPT ); Mon, 23 Feb 2015 10:03:22 -0500 MIME-Version: 1.0 In-Reply-To: <20150223140903.GY24485@phenom.ffwll.local> References: <1424687361-17787-1-git-send-email-architt@codeaurora.org> <20150223140903.GY24485@phenom.ffwll.local> Date: Mon, 23 Feb 2015 10:03:21 -0500 Message-ID: Subject: Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set From: Rob Clark To: Rob Clark , Archit Taneja , "dri-devel@lists.freedesktop.org" , linux-arm-msm , Linux Kernel Mailing List Cc: Daniel Vetter Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2557 Lines: 57 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.. > 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.. Plus, I kind of expect phone/tablet/chromebook type stuff would lead the charge into an fbdev-less world.. BR, -R > -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/