linux-kernel - Re: drm/msm/mdp5: undefined CONFIG_MSM_BUS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF6AEGu-ed3Jee4mMEo-ozqiPMAuEHUg_STvktdAFdihtJhvOQ@mail.gmail.com>
Date:	Thu, 9 Apr 2015 14:02:28 -0400
From:	Rob Clark <robdclark@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Valentin Rothberg <valentinrothberg@...il.com>,
	Hai Li <hali@...eaurora.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Airlie <airlied@...ux.ie>,
	Paul Bolle <pebolle@...cali.nl>, rupran@...server.de,
	stefan.hengelein@....de
Subject: Re: drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

On Thu, Apr 9, 2015 at 1:07 PM, Greg KH <gregkh@...uxfoundation.org> 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 <gregkh@...uxfoundation.org> 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
>> >> <valentinrothberg@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/