[Intel-gfx] [PATCH v2] drm/i915/skl: Increase ddb blocks to support large cursor sizes

[Kumar, Shobhit]

On 12/21/2015 09:02 PM, Matt Roper wrote:
> On Mon, Dec 21, 2015 at 11:15:04AM +0530, Kumar, Shobhit wrote:
>> On 12/19/2015 08:14 AM, Matt Roper wrote:
>>> On Fri, Dec 18, 2015 at 03:58:52PM -0800, Radhakrishna Sripada wrote:
>>>> Original value of 32 blocks is not sufficient when using cursor size of
>>>> 256x256 causing FIFO underruns when the reworked wm
>>>> caluclations in
>>>>
>>>> commit 024c9045221fe45482863c47c4b4c47d37f97cbf
>>>> Author: Matt Roper <matthew.d.roper at intel.com>
>>>> Date:   Thu Sep 24 15:53:11 2015 -0700
>>>>
>>>>      drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v4)
>>>>
>>>> are used. Increasing the number of blocks to 52 to make cursor plane tolerate
>>>> SAGV block time for the maximum possible cursor size.
>>>>
>>>> v2: Included Matt's suggestion, bumping up the no of blocks in multi-pipe case
>>>> to 16.
>>>>
>>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada at intel.com>
>>>> Signed-off-by: Kalyan Kondapally <kalyan.kondapally at intel.com>
>>>
>>> Can you try my patch "drm/i915/skl: Use proper plane dimensions for DDB
>>> and WM calculations" first and see if it solves your problems?  It's
>>
>> Where can I find this patch ? Couldn't find in drm-intel branches or
>> the mailing list.
>
> Yeah, looks like I mistyped the mailing list address for git-send-email;
> just resent with the proper address...you can find it here:
>
>          http://patchwork.freedesktop.org/patch/68786/
>

Thanks Matt. I tried this patch against this issue reverting the cursor 
DDB bump up from Sripada and I could still reproduce the 
blanking/unblanking on external display on cursor move to the external 
display. Tested with a 4k DP monitor.

Didn't have a high res eDP panel handy right away to test single display 
with hardware cursor.

Regards
Shobhit

>
> Matt
>
>>
>> Regards
>> Shobhit
>>
>>> possible that your problems were caused by my fumble that I'm fixing
>>> with that patch; if that patch fixes the problem, then we may not need
>>> to alter the cursor's fixed allocation after all.
>>>
>>> Of course as we noted, there are a handful of new workarounds in the
>>> bspec (SAGV disabling, system memory bandwidth checking, etc.) that we
>>> still don't have in our driver yet, so if any of those are the true root
>>> cause, then your patch here is probably a reasonable short-term fix
>>> until we can take action on the new workarounds.  In that case, you can
>>> consider this patch
>>>
>>> Acknowledged-by: Matt Roper <matthew.d.roper at intel.com>
>>>
>>> Unfortunately I only have a BXT which doesn't exhibit the problems
>>> you're seeing, so I can't actually test this out myself.
>>>
>>>
>>> Matt
>>>
>>>> ---
>>>>   drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>>>> index d385d99..c5ba4e5 100644
>>>> --- a/drivers/gpu/drm/i915/intel_pm.c
>>>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>>>> @@ -2802,9 +2802,9 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
>>>>   static unsigned int skl_cursor_allocation(const struct intel_wm_config *config)
>>>>   {
>>>>   	if (config->num_pipes_active == 1)
>>>> -		return 32;
>>>> +		return 52;
>>>>
>>>> -	return 8;
>>>> +	return 16;
>>>>   }
>>>>
>>>>   static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32 reg)
>>>> --
>>>> 1.9.1
>>>>
>>>
>