Re: [PATCH 7/7] drm/i915: add i915_get_reset_stats_ioctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/08/2013 11:00 AM, Dave Airlie wrote:
> On Sat, Nov 9, 2013 at 3:21 AM, Ian Romanick <idr@xxxxxxxxxxxxxxx> wrote:
>> On 11/07/2013 10:32 PM, Daniel Vetter wrote:
>>> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie <airlied@xxxxxxxxx> wrote:
>>>> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
>>>>> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick <idr@xxxxxxxxxxxxxxx> 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,

Stop calling other people's hard work shit.  It just makes you look like
an asshole.  Seriously.

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

That's not the reason for the 3 month cycle.  The reason for the 3 month
cycle is because all of the distros, including Fedora, were pulling
random points from master because waiting 6 months for features and
performance improvements was too long.

> 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

I don't know where you're getting "drm cap" nonsense.  That was closed
two weeks ago:

http://lists.freedesktop.org/archives/intel-gfx/2013-October/035016.html

> 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.

I thought Daniel and I had closed that, and I Acked-by the kernel patch.
 He and I talked about this on IRC.  ***IF*** we need an extra flag for
global resets, there's already a place for it in the (currently) pad
field returned by the ioctl.

This isn't some last minute, half-baked interface.  We've been working
on this for nearly a year.  After going through several revisions,
Mika's kernel patch has been on the intel-gfx list since July.  That
people are exploding about this now just boggles my mind.

> Dave.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux