[Intel-gfx] [PATCH v4] drm/i915/skl: New ddb allocation algorithm

[Mahesh Kumar]

Hi Maarten,

thanks for pointing out the issue,

not only start value, end value is also incorrect. I got the root-cause 
for both.
but this end value issue seems to be always there. end value should be 
-1 (because start block should also be counted)
Will fix both & upload the reworked patches.

-Mahesh


On Monday 19 September 2016 03:25 PM, Maarten Lankhorst wrote:
> Op 14-09-16 om 14:36 schreef Mahesh Kumar:
>> Hi,
>> There was an issue with transition WM, it was getting enabled & causing fifo underrun.
>> I fixed the condition, After that tested kms_plane & not getting any underrun.
>> Please let me know if you see any other issue.
>>
>> Regards,
>> -Mahesh
>>
>> On Tuesday 13 September 2016 06:10 PM, Maarten Lankhorst wrote:
>>> Op 13-09-16 om 14:15 schreef Kumar, Mahesh:
>>>> From: Mahesh Kumar <mahesh1.kumar at intel.com>
>>>>
>>>> This patch implements new DDB allocation algorithm as per HW team
>>>> suggestion. This algo takecare of scenario where we allocate less DDB
>>>> for the planes with lower relative pixel rate, but they require more DDB
>>>> to work.
>>>> It also takes care of enabling same watermark level for each
>>>> plane, for efficient power saving.
>>>>
>>>> Changes since v1:
>>>>    - Rebase on top of Paulo's patch series
>>>>
>>>> Changes since v2:
>>>>    - Fix the for loop condition to enable WM
>>>>
>>>> Signed-off-by: Mahesh Kumar <mahesh1.kumar at intel.com>
>>> I'm still getting underrun issues when running the entire patch series against kms_atomic_transition and kms_plane.
>>> Can you confirm?
>>>
>>> ~Maarten
> Found it..
>
> During the test run:
> # cat /sys/kernel/debug/dri/0/i915_ddb_info
>                    Start     End    Size
> Pipe A
>    Plane1              0       0       0
>    Plane2             30     890     860
>    Cursor            860     892      32
>
> Pretty sure the start value here is bogus, and plane2 wm's end up overlapping with cursor.
>
> ~Maarten
>