[Intel-gfx] [PATCH 7/7] drm/i915: add i915_get_reset_stats_ioctl

[Dave Airlie]

On Sat, Nov 9, 2013 at 3:21 AM, Ian Romanick <idr at freedesktop.org> wrote:
> On 11/07/2013 10:32 PM, Daniel Vetter wrote:
>> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie <airlied at gmail.com> wrote:
>>> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>>>> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>>>> On 10/27/2013 05:30 AM, Daniel Vetter wrote:
>>>>>> On Fri, Oct 25, 2013 at 06:42:35PM -0700, Ian Romanick wrote:
>>>>>>> Since the Mesa merge window is closing soon, I'm finally getting back on
>>>>>>> this.  I've pushed a rebase of my old Mesa branch to my fd.o repo
>>>>>>>
>>>>>>> http://cgit.freedesktop.org/~idr/mesa/log/?h=robustness3
>>>>>>>
>>>>>>> I have a couple questions...
>>>>>>>
>>>>>>> 1. Has any of this landed an a kernel tree anywhere?
>>>>>>
>>>>>> Afaik everything but the actual ioctl and i-g-t testcase has landed.
>>>>>
>>>>> And that stuff will land once my patches hit the Mesa list or ... ?
>>>>
>>>> Yup.
>>>
>>> Hey kernel first, then upstream projects, at the moment libdrm has
>>> ioctls in it that I have no upstream solid kernel commit for,
>>>
>>> Either in the next 24 hrs I have this in my tree or the libdrm commits
>>> need to be reverted,
>>>
>>> and if someone releases libdrm in that time span then I'm going to be
>>> quite pissed.
>>
>> It's kinda too late imo for 3.13 (and there's an open question whether
>> we need one more flag or not), so I wanted to pull it in into 3.14.
>> Which also gives us plenty of time to add or not add that optional
>> flag. So I guess time to revert. Can you do that pls?
>
> Reverting has completely broken Mesa builds, and was the wrong choice.
> Thanks for giving me opportunity to reply before breaking my stuff.
>

Hey Ian,

stop merging incomplete shit 5 mins before the branch point,

you should know better, Mesa is meant to be moving to 3 mth release
cycle to avoid this kinda merge everything crap,

there was an open thread on the api for this feature, there was
questions of whether a drm cap was needed, you failed to address any
of these and you merged the feature, the rules aren't different than
before, stuff goes in the kernel first and userspace second, we went
down this road before and it always gets screwed up.

Dave.