Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755843AbbDIOvE (ORCPT ); Thu, 9 Apr 2015 10:51:04 -0400 Received: from mail-vn0-f53.google.com ([209.85.216.53]:36674 "EHLO mail-vn0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753611AbbDIOu7 (ORCPT ); Thu, 9 Apr 2015 10:50:59 -0400 MIME-Version: 1.0 In-Reply-To: <20150409142024.GA3040@kroah.com> References: <20150409112240.GA4748@station.rsr.lip6.fr> <20150409142024.GA3040@kroah.com> Date: Thu, 9 Apr 2015 10:50:58 -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: 2271 Lines: 52 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.. BR, -R > If this was in a subsystem that I maintain, I'd delete it tomorrow. But > in the end, it's up to David to decide if he wants to waste the cycles > or not. > > Ick ick ick. > > 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/