Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933109AbbDISCc (ORCPT ); Thu, 9 Apr 2015 14:02:32 -0400 Received: from mail-qk0-f169.google.com ([209.85.220.169]:33387 "EHLO mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933051AbbDISC3 (ORCPT ); Thu, 9 Apr 2015 14:02:29 -0400 MIME-Version: 1.0 In-Reply-To: <20150409170707.GA7742@kroah.com> References: <20150409112240.GA4748@station.rsr.lip6.fr> <20150409142024.GA3040@kroah.com> <20150409170707.GA7742@kroah.com> Date: Thu, 9 Apr 2015 14:02:28 -0400 Message-ID: Subject: Re: drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING From: Rob Clark To: Greg KH Cc: Valentin Rothberg , Hai Li , "dri-devel@lists.freedesktop.org" , Linux Kernel Mailing List , David Airlie , Paul Bolle , rupran@einserver.de, stefan.hengelein@fau.de 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: 3537 Lines: 74 On Thu, Apr 9, 2015 at 1:07 PM, Greg KH wrote: > On Thu, Apr 09, 2015 at 10:50:58AM -0400, Rob Clark wrote: >> On Thu, Apr 9, 2015 at 10:20 AM, Greg KH wrote: >> > On Thu, Apr 09, 2015 at 09:49:58AM -0400, Rob Clark wrote: >> >> On Thu, Apr 9, 2015 at 7:22 AM, Valentin Rothberg >> >> wrote: >> >> > Hi Hai, >> >> > >> >> > your commit d5af49c92a8a ("drm/msm/mdp5: Enable DSI connector in msm drm >> >> > driver") in today's Linux next tree adds an #ifdef with CONFIG_MSM_BUS_SCALING >> >> > as condition. MSM_BUS_SCALING is not defined in Kconfig, so the code in this >> >> > #ifdef block won't be compiled at its current state. >> >> > >> >> > I saw some references on this Kconfig option in other files; is there a >> >> > reason for the absence of MSM_BUS_SCALING? >> >> >> >> right now, it is something that only exists in downstream kernels (for >> >> example, android device kernels).. but in those kernels it is >> >> mandatory to use, as by default the memory/bus is downclocked and the >> >> display would underflow if we did not request sufficient bandwidth. >> >> >> >> It only exists right now in the upstream kernel to simplify >> >> backporting to various device kernels >> > >> > That's crazy. You are asking upstream to maintain code in order to just >> > make out of tree crap easier to maintain, which you don't have any plan >> > to ever upstream? That causes havoc on static analysis tools and >> > prevents anyone from ever being able to even change the code for new api >> > changes and test build it. >> >> Hey, don't blame me for the downstream kernels. But at various points >> in time I've had to backport drm/msm to various device kernels in >> order to work on the userspace/mesa end of things. (And, well, there >> are other crazy folks out there who want to get open source graphics >> drivers working on various phones/tablets.) It was a choice to make >> my life easier. You know, because reverse engineering a gpu is a walk >> in the park.. > > I really don't understand. Why is this code in the kernel tree if it > can't be built? How does anyone use this? By taking it and copying it > where? If it can't be built, and no one can update it, and of course > not run it, why is it here? What good is this code doing sitting here? > For devices where I cannot run an upstream kernel yet, I backport latest upstream drm (mostly 'cp -r' with as little changes as possible, cherrypicking other dependencies outside of drm) to the device kernel. Basically that lets me develop against upstream drm in parallel with the kernel-msm folks (hopefully) getting their pieces upstream. If I had to wait for all the clocks/regulators/gpio/etc drivers that I depend on to land upstream, I'd pretty much only be able to start when a given SoC was already a bit old (and add to that 6-12mos or so to get mesa into mesa into good shape on a new gpu generation, by the time the end user gets something usable the device would already be obsolete) Ideally we get to the point where I don't need to do this.. downstream vendor kernels are generally a PITA.. but for the time being, it seems like the most practical way for me to do things. BR, -R > confused, > > greg k-h -- 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/