Thanks for the input Rodrigo, Arthur. I will update commit message and repost the patch. Thanks, Radhakrishna Sripada -----Original Message----- From: Runyan, Arthur J Sent: Thursday, June 23, 2016 1:04 PM To: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> Cc: Sripada, Radhakrishna <radhakrishna.sripada@xxxxxxxxx>; intel-gfx <intel-gfx@xxxxxxxxxxxxxxxxxxxxx>; drm-intel-fixes@xxxxxxxxxxxxxxxxxxxxx Subject: RE: [PATCH] drm/i915/skl: Increase cursor ddb blocks in multi-pipe config That part is trying to just allocate 8 to each cursor. The buffer used up will be 8*numpipes, but that's because its assuming you can end up enabling a cursor on each pipe. I think its good to go up to 16. The kind of latencies we get on skl mean that a 64x64 32bpp cursor with 8 blocks will be restricting package C states even at 1920x1080 60hz. The 8 number was based on what hardware did for allocation on past projects. -----Original Message----- From: Rodrigo Vivi [mailto:rodrigo.vivi@xxxxxxxxx] Sent: Thursday, June 23, 2016 12:50 PM To: Runyan, Arthur J Cc: Sripada, Radhakrishna; intel-gfx; drm-intel-fixes@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [PATCH] drm/i915/skl: Increase cursor ddb blocks in multi-pipe config Thanks Art. I believe the commit message should be updated to reflect this is flexible. Probably coping and pasting this part of spec: "More allocation might be required to support deeper low power states." So I went now to the spec to review the code and besides the line above I also notice for this specific case BSpec actually recommend 8 * num_active. "For each enabled cursor CursorBufAlloc = 8" "BlocksAvailable = TotalBlocksAvailable - (8 * NumPipes)." What I believe in this code it should be return 8 * num_active instead of a fixed number of 8 or 16. Right? Thanks, Rodrigo. On Thu, Jun 23, 2016 at 12:20 PM, Runyan, Arthur J <arthur.j.runyan@xxxxxxxxx> wrote: > The bspec says "These are basic methods that can be used for single and multi-pipe modes. For optimal power usage, the display driver can choose to use more advanced allocation techniques as desired." > So we leave it up to the driver to optimize as it sees fit. > > -----Original Message----- > From: Rodrigo Vivi [mailto:rodrigo.vivi@xxxxxxxxx] > Sent: Thursday, June 16, 2016 4:20 PM > To: Sripada, Radhakrishna > Cc: intel-gfx; drm-intel-fixes@xxxxxxxxxxxxxxxxxxxxx; Runyan, Arthur J > Subject: Re: [PATCH] drm/i915/skl: Increase cursor ddb > blocks in multi-pipe config > > I believe we should use whatever BSpec recommends. > > If that is not the best behavior and block things out than the spec needs to be updated or a workaround documented there. > > Art? thoughts? > > On Mon, Jun 13, 2016 at 3:03 PM, Radhakrishna Sripada <radhakrishna.sripada@xxxxxxxxx> wrote: >> The bspec suggests giving cursor planes a fixed allocation of 8 >> blocks when running in a multi-CRTC configuration. However we have >> found that this small allocation can only accommodate level >> 0 watermarks on many platforms, which in turn prevents the system >> from entering deeper sleep states. Let's use a slightly higher >> allocation of 16 blocks for the cursor to increase our chances of >> enabling lower power states. >> >> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@xxxxxxxxx> >> Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> >> --- >> drivers/gpu/drm/i915/intel_pm.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c index 658a756..a949dac 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -2933,7 +2933,8 @@ static unsigned int skl_cursor_allocation(int num_active) >> if (num_active == 1) >> return 32; >> >> - return 8; >> + /* higher than bspec recommendation (8) */ >> + return 16; >> } >> >> static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, >> u32 reg) >> -- >> 1.9.1 >> >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Rodrigo Vivi > Blog: http://blog.vivi.eng.br -- Rodrigo Vivi Blog: http://blog.vivi.eng.br _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
