From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753785AbbCIIyS (ORCPT ); Mon, 9 Mar 2015 04:54:18 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:42605 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752873AbbCIIyP (ORCPT ); Mon, 9 Mar 2015 04:54:15 -0400 Message-ID: <54FD5FB1.5030705@codeaurora.org> Date: Mon, 09 Mar 2015 14:24:09 +0530 From: Archit Taneja User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Rob Clark , linux-arm-msm , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , daniel@ffwll.ch Subject: Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set References: <1424687361-17787-1-git-send-email-architt@codeaurora.org> <20150223140903.GY24485@phenom.ffwll.local> <20150223153940.GZ24485@phenom.ffwll.local> <54F82AA3.4040902@codeaurora.org> <20150305154453.GL18775@phenom.ffwll.local> <54FD3632.8080904@codeaurora.org> <20150309074438.GK18775@phenom.ffwll.local> In-Reply-To: <20150309074438.GK18775@phenom.ffwll.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/09/2015 01:14 PM, Daniel Vetter wrote: > On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote: >> On 03/05/2015 09:14 PM, Daniel Vetter wrote: >>> On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote: >>>> On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja wrote: >>>>> >>>>> On 02/23/2015 09:09 PM, Daniel Vetter wrote: >>>>>> >>>>>> On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: >>>>> Rather than creating fb helper stub functions, maybe we could help each drm >>>>> driver create two variants of functions needed by drm core(like >>>>> output_poll_changed and dev_lastclose), one variant supporting legacy fbdev, >>>>> and the other not? >>>> >>>> So one quick thought.. building without fbdev would ideally/eventually >>>> be a distro level decision, not a driver level decision.. so I think >>>> it is *eventually* not a problem for it being a global drm level >>>> decision. The only problem is right now some drivers support no-fbdev >>>> config, and some do not. Maybe it is worth fixing that? >>> >>> Yeah, if we get fbdev emulation Kconfig option then I think i915 and msm >>> should remove their own options and just use that. There's really no need >>> to have this per-driver, this is a question of what userspace expects and >>> so per-distro, independant of the driver. >>> -Daniel >>> >> >> Okay. If I understand right. We need to do something like this: >> >> - Create a new Kconfig option that lets us emulate fbdev >> >> - For drivers that already have a config for fbdev emulation, replace it >> with our new emulation config. >> >> - For drivers that assume fbdev emulation by default, select our new >> emulation config in their respective Kconfigs. >> >> Does this sound okay? >> >> I suppose this could be the first step. Later we'd need to work on each >> driver to work with and without the fbdev emulation Kconfig option. > > See Rob's idea quoted above: Imo you should just do the conditional code > in the fbdev emulation helper in drm_fb_helper.c, not in drivers. There's > some additional code in i915 (and maybe also msm) to compile out (mostly > around taking/dropping console_lock) and we want to keep that. But that > should also just be using the same new config option. So: > > - Add new config option DRM_FBDEV_EMULATION (default y for backwards > compat). Use that to stub out helpers in drm_fb_helper.c. > > - Replace the msm/i915 specific options with the new, i.e. remove it from > Kconfig and use DRM_FBDEV_EMULATION in the code instead of the msm/i915 > specific one. > > fbdev-less support for all other drivers will just magically happen > without the need for driver-specific code (except for the special locking > in i915 and similar things maybe). That sounds good. I wasn't totally sure about fbdev-less support working out of the box on devices that use the fb CMA helpers. The drm_fbdev_cma_* funcs internally use the fb helper functions. Stubbing the fb helpers out might result in some corner cases. However, after a quick look at that the cma helpers, it looks like it take all the necessary precautions to prevent uninitialized accesses. Although, it would be ideal to stub out the drm_fbdev_cma_* helper functions too since they don't serve any purpose when fbdev emulation is disabled. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project