All of lore.kernel.org
 help / color / mirror / Atom feed
From: sonika <sonika.jindal@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915/skl: Enabling PSR on Skylake
Date: Wed, 21 Jan 2015 10:23:26 +0530	[thread overview]
Message-ID: <54BF30C6.9020807@intel.com> (raw)
In-Reply-To: <CABVU7+tGe5er9f0Xdcj8aFE8RT46Ngsga0-mcQzwTVg3OF+3=A@mail.gmail.com>


On Wednesday 21 January 2015 03:31 AM, Rodrigo Vivi wrote:
> Hi Sonika, for the login screen my guess is that blinking cursor
> waiting for password blocks psr entry.
But I thought it is the psr exit which is taking time which is why it 
takes time
to actually show up the characters
> For test cases I started the test case enhancement but my psr work is
> paused this month for bug maintainance. Any help is welcome.
> I was planing also to take a look on new Paulo's fbc tests cases to
> see if we could use some pieces on PSR validation. might be worth to
> take a look.
Can we test scenarios like delayed psr exits (like the one I mentioned) 
with test case?
If yes, I can work with you offline to enhance the igt.
> But anyway, for HW tracking I would only consider when I use a KDE for
> a while without missing any screen updates and seeing perf counter
> increasing. But if you tell this is what happening I trust you and we
> can add support for that since it is disabled by default and validate
> that carefully also on SKL when trying to enable it by default
> everywhere.
Hmm, I have not tested with KDE yet. I have been testing with ubuntu 
with gnome.
And it works very smooth there. I will do more experiments with KDE too.
>
> I'm going to review the code more carefully later...
>
> On Tue, Jan 20, 2015 at 3:49 AM, Jindal, Sonika <sonika.jindal@intel.com> wrote:
>> Is somebody working on enhancing the psr testcase?
>> -Sonika
>>
>> -----Original Message-----
>> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
>> Sent: Tuesday, January 20, 2015 3:20 PM
>> To: Jindal, Sonika
>> Cc: Daniel Vetter; intel-gfx; Vivi, Rodrigo
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR on Skylake
>>
>> On Mon, Jan 19, 2015 at 05:10:58PM +0530, sonika wrote:
>>> On Saturday 17 January 2015 09:54 AM, Daniel Vetter wrote:
>>>> On Fri, Jan 16, 2015 at 02:07:26PM +0530, Sonika Jindal wrote:
>>>>> Mainly taking care of some register offsets, otherwise things are
>>>>> similar to hsw. Also, programming ddi aux to use hardcoded values for psr data select.
>>>>>
>>>>> v2: introduce  EDP_PSR_AUX_BASE macro (Chris)
>>>>> v3: Moving to HW tracking for SKL+ platforms, so activating source
>>>>> psr during psr_enabling and then avoiding psr entries and exits for
>>>>> each frontbuffer updates.
>>>>>
>>>>> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
>>>>> ---
>>>>>   drivers/gpu/drm/i915/i915_drv.h          |    3 ++-
>>>>>   drivers/gpu/drm/i915/i915_reg.h          |   19 +++++++++++++------
>>>>>   drivers/gpu/drm/i915/intel_frontbuffer.c |    7 +++++--
>>>>>   drivers/gpu/drm/i915/intel_psr.c         |   18 +++++++++++++++++-
>>>>>   4 files changed, 37 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>>>> b/drivers/gpu/drm/i915/i915_drv.h index 42c69ca..ee5cd3b 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>>>> @@ -2355,7 +2355,8 @@ struct drm_i915_cmd_table {
>>>>>   #define HAS_DDI(dev) (INTEL_INFO(dev)->has_ddi)
>>>>>   #define HAS_FPGA_DBG_UNCLAIMED(dev)
>>>>> (INTEL_INFO(dev)->has_fpga_dbg)
>>>>>   #define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
>>>>> - IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
>>>>> + IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
>>>>> + IS_SKYLAKE(dev))
>>>>>   #define HAS_RUNTIME_PM(dev) (IS_GEN6(dev) || IS_HASWELL(dev) || \
>>>>>    IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
>>>>>   #define HAS_RC6(dev) (INTEL_INFO(dev)->gen >= 6) diff --git
>>>>> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>>>>> index a828cf5..068c8da 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>>>> @@ -2619,12 +2619,14 @@ enum skl_disp_power_wells {
>>>>>   #define   EDP_PSR_TP1_TIME_0us (3<<4)
>>>>>   #define   EDP_PSR_IDLE_FRAME_SHIFT 0
>>>>>
>>>>> -#define EDP_PSR_AUX_CTL(dev) (EDP_PSR_BASE(dev) + 0x10) -#define
>>>>> EDP_PSR_AUX_DATA1(dev) (EDP_PSR_BASE(dev) + 0x14) -#define
>>>>> EDP_PSR_AUX_DATA2(dev) (EDP_PSR_BASE(dev) + 0x18) -#define
>>>>> EDP_PSR_AUX_DATA3(dev) (EDP_PSR_BASE(dev) + 0x1c) -#define
>>>>> EDP_PSR_AUX_DATA4(dev) (EDP_PSR_BASE(dev) + 0x20) -#define
>>>>> EDP_PSR_AUX_DATA5(dev) (EDP_PSR_BASE(dev) + 0x24)
>>>>> +#define EDP_PSR_AUX_BASE(dev) (INTEL_INFO(dev)->gen >= 9 ? \
>>>>> + 0x64000 : EDP_PSR_BASE(dev))
>>>>> +#define EDP_PSR_AUX_CTL(dev) (EDP_PSR_AUX_BASE(dev) + 0x10) #define
>>>>> +EDP_PSR_AUX_DATA1(dev) (EDP_PSR_AUX_BASE(dev) + 0x14) #define
>>>>> +EDP_PSR_AUX_DATA2(dev) (EDP_PSR_AUX_BASE(dev) + 0x18) #define
>>>>> +EDP_PSR_AUX_DATA3(dev) (EDP_PSR_AUX_BASE(dev) + 0x1c) #define
>>>>> +EDP_PSR_AUX_DATA4(dev) (EDP_PSR_AUX_BASE(dev) + 0x20) #define
>>>>> +EDP_PSR_AUX_DATA5(dev) (EDP_PSR_AUX_BASE(dev) + 0x24)
>>>>>
>>>>>   #define EDP_PSR_STATUS_CTL(dev) (EDP_PSR_BASE(dev) + 0x40)
>>>>>   #define   EDP_PSR_STATUS_STATE_MASK (7<<29)
>>>>> @@ -3771,6 +3773,11 @@ enum skl_disp_power_wells {
>>>>>   #define   DP_AUX_CH_CTL_PRECHARGE_TEST    (1 << 11)
>>>>>   #define   DP_AUX_CH_CTL_BIT_CLOCK_2X_MASK    (0x7ff)
>>>>>   #define   DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT   0
>>>>> +#define   DP_AUX_CH_CTL_PSR_DATA_AUX_REG_SKL (1 << 14)
>>>>> +#define   DP_AUX_CH_CTL_FS_DATA_AUX_REG_SKL (1 << 13)
>>>>> +#define   DP_AUX_CH_CTL_GTC_DATA_AUX_REG_SKL (1 << 12)
>>>>> +#define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL_MASK (1f << 5)
>>>>> +#define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
>>>>>   #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
>>>>>
>>>>>   /*
>>>>> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c
>>>>> b/drivers/gpu/drm/i915/intel_frontbuffer.c
>>>>> index 79f6d72..010d550 100644
>>>>> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
>>>>> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
>>>>> @@ -156,7 +156,9 @@ void intel_fb_obj_invalidate(struct
>>>>> drm_i915_gem_object *obj,
>>>>>
>>>>>    intel_mark_fb_busy(dev, obj->frontbuffer_bits, ring);
>>>>>
>>>>> - intel_psr_invalidate(dev, obj->frontbuffer_bits);
>>>>> +
>>>>> + if (INTEL_INFO(dev)->gen < 9)
>>>>> + intel_psr_invalidate(dev, obj->frontbuffer_bits);
>>>>>   }
>>>>>
>>>>>   /**
>>>>> @@ -182,7 +184,8 @@ void intel_frontbuffer_flush(struct drm_device
>>>>> *dev,
>>>>>
>>>>>    intel_mark_fb_busy(dev, frontbuffer_bits, NULL);
>>>>>
>>>>> - intel_psr_flush(dev, frontbuffer_bits);
>>>>> + if (INTEL_INFO(dev)->gen < 9)
>>>>> + intel_psr_flush(dev, frontbuffer_bits);
>>>> I'm pretty sure the hw isn't good enough yet to detect everything,
>>>> unfortunately the testcase is also not quite ready yet. In any case
>>>> these changes should be moved into the inel_psr_* functions and in a
>>>> separate patch.
>>> When ubuntu boots up and stops at the login screen, the text I enter
>>> comes slowly, looks like psr exit and entry is not very prompt at that time.
>>> But when I try with SW tracking, I see that PSR doesn't get enabled at
>>> all at that point!
>>> Also, I don't see calls to frontbuffer invalidate and flush at that point.
>>> So, with SW tracking too we will have cases where we don't enter psr.
>>> Any inputs on why frontbuffer calls are not received during login screen?
>>>
>>> Please note that after login, it works fine if I type something on the
>>> terminal or do some other things.
>> I have no idea why or what exactly the ubuntu screen does in it's login function. Just please note that there are _lots_ more desktop environments on linux than just ubunut's flavour of gnome, so we really need to have that psr testcase working (which covers them all) instead of manual testing.
>> -Daniel
>>
>>>> Also someone needs to re-review the psr igt testcase to make sure it
>>>> covers everything. Ville could do that too since he's done the fbc
>>>> testcase.
>>>> -Daniel
>>>>
>>>>>    /*
>>>>>    * FIXME: Unconditional fbc flushing here is a rather gross hack
>>>>> and diff --git a/drivers/gpu/drm/i915/intel_psr.c
>>>>> b/drivers/gpu/drm/i915/intel_psr.c
>>>>> index dd0e6e0..6d2cdb8 100644
>>>>> --- a/drivers/gpu/drm/i915/intel_psr.c
>>>>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>>>>> @@ -173,11 +173,24 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
>>>>>    I915_WRITE(EDP_PSR_AUX_DATA1(dev) + i,
>>>>>      intel_dp_pack_aux(&aux_msg[i], sizeof(aux_msg) - i));
>>>>>
>>>>> - I915_WRITE(EDP_PSR_AUX_CTL(dev),
>>>>> + if (INTEL_INFO(dev)->gen >= 9) {
>>>>> + uint32_t val;
>>>>> +
>>>>> + val = I915_READ(EDP_PSR_AUX_CTL(dev)); val &=
>>>>> + ~DP_AUX_CH_CTL_TIME_OUT_MASK; val |=
>>>>> + DP_AUX_CH_CTL_TIME_OUT_1600us; val &=
>>>>> + ~DP_AUX_CH_CTL_MESSAGE_SIZE_MASK; val |= (sizeof(aux_msg) <<
>>>>> + DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT);
>>>>> + /* Use hardcoded data values for PSR */ val &=
>>>>> + ~DP_AUX_CH_CTL_PSR_DATA_AUX_REG_SKL;
>>>>> + I915_WRITE(EDP_PSR_AUX_CTL(dev), val); } else {
>>>>> + I915_WRITE(EDP_PSR_AUX_CTL(dev),
>>>>>      DP_AUX_CH_CTL_TIME_OUT_400us |
>>>>>      (sizeof(aux_msg) << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) |
>>>>>      (precharge << DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT) |
>>>>>      (aux_clock_divider << DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
>>>>> + }
>>>>>   }
>>>>>
>>>>>   static void vlv_psr_enable_source(struct intel_dp *intel_dp) @@
>>>>> -355,6 +368,9 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>>>>>
>>>>>    /* Enable PSR on the panel */
>>>>>    hsw_psr_enable_sink(intel_dp);
>>>>> +
>>>>> + if (INTEL_INFO(dev)->gen >= 9)
>>>>> + intel_psr_activate(intel_dp);
>>>>>    } else {
>>>>>    vlv_psr_setup_vsc(intel_dp);
>>>>>
>>>>> --
>>>>> 1.7.10.4
>>>>>
>>>>> _______________________________________________
>>>>> Intel-gfx mailing list
>>>>> Intel-gfx@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>

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

  reply	other threads:[~2015-01-21  5:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16  8:37 [PATCH] drm/i915/skl: Enabling PSR on Skylake Sonika Jindal
2015-01-16 15:06 ` shuang.he
2015-01-17  4:24 ` Daniel Vetter
2015-01-19 11:40   ` sonika
2015-01-20  9:50     ` Daniel Vetter
2015-01-20 11:49       ` Jindal, Sonika
2015-01-20 22:01         ` Rodrigo Vivi
2015-01-21  4:53           ` sonika [this message]
2015-01-21  8:37           ` Daniel Vetter
2015-01-21  8:55             ` sonika
2015-01-21  9:42               ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2015-01-22  9:00 Sonika Jindal
2015-01-22 17:48 ` shuang.he
2015-01-28 16:02 ` Daniel Vetter
2015-01-29  3:57   ` sonika
2015-01-29 16:11     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54BF30C6.9020807@intel.com \
    --to=sonika.jindal@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@gmail.com \
    --cc=rodrigo.vivi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.