Re: [PATCH 2/2] drm/i915: Only recalculate wm's for planes part of the state, v2.

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

 



Op 02-03-16 om 22:08 schreef Zanoni, Paulo R:
> Em Ter, 2016-03-01 às 14:28 -0800, Matt Roper escreveu:
>> On Tue, Mar 01, 2016 at 11:07:22AM +0100, Maarten Lankhorst wrote:
>>> Only planes that are part of the state should be used for
>>> recalculating
>>> watermarks. For planes not part of the state the previous patch
>>> allows
>>> us to re-use the old values since they're calculated even for
>>> levels
>>> that are not actively used.
>>>
>>> Changes since v1:
>>> - Remove big if from intel_crtc_atomic_check.
>>> - Remove extra newline.
>>> - Remove memset in ilk_compute_pipe_wm.
>>>
>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx
>>> Cc: Matt Roper <matthew.d.roper@xxxxxxxxx>
>> I haven't thought through this too carefully yet, but off the top of
>> my
>> head I'm not sure if this will work for SKL once we transition it to
>> also use a more atomic style.  Changes to other state might result in
>> changes to DDB allocation, making our previously-calculated values
>> invalid.
>>
>> I think this is okay for the current code (where only ILK is atomic),
>> so
>>
>>     Acknowledged-by: Matt Roper <matthew.d.roper@xxxxxxxxx>
>>
>> for the time being.  I'll be back to looking at SKL-style watermarks
>> in
>> the next day or two and I might have to backtrack somewhat in cases
>> where a DDB partitioning changes results in a full recompute, but I
>> need
>> to think through the details a bit more about how best to handle
>> that.
> I spent some time looking at that early return from invalid pipe
> watermarks, but I suppose that return means we'll completely discard
> anything just computed by the function, right?
>
> The patch seems to do what it says on the box, so if we assume we
> actually want the patch:
> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx>
>
> I'll let you and Matt decide whether we actually want the patch or not.
>
This was a bug. I sent a fix for that one. When wm calculation fails -EINVAL is returned now,
and the invalid wm's discarded.

~Maarten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://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