> On Nov 4, 2020, at 9:17 PM, Anshuman Gupta <anshuman.gu...@intel.com> wrote:
>
> On 2020-11-03 at 17:06:42 -0500, Rodrigo Vivi wrote:
>> On Fri, Oct 30, 2020 at 11:46:58AM +0530, Anshuman Gupta wrote:
>>> From: Bob Paauwe <bob.j.paa...@intel.com>
>>>
>>> The WA specifies that we need to toggle a SDE chicken bit on and then
>>> off as the final step in preparation for s0ix entry.
>>>
>>> Bspec: 33450
>>> Bspec: 8402
>>>
>>> However, something is happening after we toggle the bit that causes
>>> the WA to be invalidated. This makes dispcnlunit1_cp_xosc_clkreq
>>> active being already in s0ix state i.e SLP_S0 counter incremented.
>>> Tweaking the Wa_14010685332 by setting the bit on suspend and clearing
>>> it on resume turns down the dispcnlunit1_cp_xosc_clkreq.
>>> B.Spec has Documented this tweaked sequence of WA as an alternative.
>>> Let keep this tweaked WA for Gen11 platforms and keep untweaked WA for
>>> other platforms which never observed this issue.
>>>
>>> v2 (MattR):
>>> - Change the comment on the workaround to give PCH names rather than
>>> platform names. Although the bspec is setup to list workarounds by
>>> platform, the hardware team has confirmed that the actual issue being
>>> worked around here is something that was introduced back in the
>>> Cannon Lake PCH and carried forward to subsequent PCH's.
>>> - Extend the untweaked version of the workaround to include PCH_CNP as
>>> well. Note that since PCH_CNP is used to represent CMP, this will
>>> apply on CML and some variants of RKL too.
>>> - Cap the untweaked version of the workaround so that it won't apply to
>>> "fake" PCH's (i.e., DG1). The issue we're working around really is
>>> an issue in the PCH itself, not the South Display, so it shouldn't
>>> apply when there isn't a real PCH.
>>>
>>> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
>>> Signed-off-by: Bob Paauwe <bob.j.paa...@intel.com>
>>> Signed-off-by: Anshuman Gupta <anshuman.gu...@intel.com>
>>> Signed-off-by: Matt Roper <matthew.d.ro...@intel.com>
>>> ---
>>> .../drm/i915/display/intel_display_power.c | 21 +++++++++++++++++--
>>> drivers/gpu/drm/i915/i915_irq.c | 6 ++++--
>>> 2 files changed, 23 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
>>> b/drivers/gpu/drm/i915/display/intel_display_power.c
>>> index 689922480661..d2a6518329d7 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>>> @@ -5858,17 +5858,34 @@ static void intel_power_domains_verify_state(struct
>>> drm_i915_private *i915)
>>>
>>> void intel_display_power_suspend_late(struct drm_i915_private *i915)
>>> {
>>> - if (INTEL_GEN(i915) >= 11 || IS_GEN9_LP(i915))
>>> + u32 val;
>>> +
>>> + if (INTEL_GEN(i915) >= 11 || IS_GEN9_LP(i915)) {
>>> bxt_enable_dc9(i915);
>>> - else if (IS_HASWELL(i915) || IS_BROADWELL(i915))
>>> + /* Tweaked Wa_14010685332:icp,jsp,mcc */
>>> + if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
>>> PCH_MCC) {
>>> + val = intel_de_read(i915, SOUTH_CHICKEN1);
>>> + val |= SBCLK_RUN_REFCLK_DIS;
>>> + intel_de_write(i915, SOUTH_CHICKEN1, val);
>>
>> could we use intel_de_rmw here?
> May be i had misunderstod it earlier, i thought it was your recommendation
> to use manual read, modify write without using intel_uncore_rmw(),
ouch, I'm really sorry for causing this confusion here.
My recommendation was for debug purposes only on the original w/a
I haven't noticed it had expanded to the alternate/tweaked one.
This shouldn't be needed here.
> Was the actual idea to use intel_de_rmw flavour of API instead of
> intel_uncore_rmw?
I'm assuming that both south or north registers would still be considered
display engine. Jani can correct me if I'm wrong here.
But I believe _de_ is more appropriated here.
> Also would it require to use at original Wa in gen11_display_irq_reset as
> well?
any modification there could be done in separated patches as needed.
>
> Thanks,
> Anshuman Gupta.
>>
>>> + }
>>> + } else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
>>> hsw_enable_pc8(i915);
>>> + }
>>> }
>>>
>>> void intel_display_power_resume_early(struct drm_i915_private *i915)
>>> {
>>> + u32 val;
>>> +
>>> if (INTEL_GEN(i915) >= 11 || IS_GEN9_LP(i915)) {
>>> gen9_sanitize_dc_state(i915);
>>> bxt_disable_dc9(i915);
>>> + /* Tweaked Wa_14010685332:icp,jsp,mcc */
>>> + if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
>>> PCH_MCC) {
>>> + val = intel_de_read(i915, SOUTH_CHICKEN1);
>>> + val &= ~SBCLK_RUN_REFCLK_DIS;
>>> + intel_de_write(i915, SOUTH_CHICKEN1, val);
>>
>> and here?
>>
>> sorry for not having spotted that sooner.
>>
>>> + }
>>> } else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
>>> hsw_disable_pc8(i915);
>>> }
>>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>>> b/drivers/gpu/drm/i915/i915_irq.c
>>> index dc33c96d741d..410c03624c6a 100644
>>> --- a/drivers/gpu/drm/i915/i915_irq.c
>>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>>> @@ -3055,8 +3055,10 @@ static void gen11_display_irq_reset(struct
>>> drm_i915_private *dev_priv)
>>> if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
>>> GEN3_IRQ_RESET(uncore, SDE);
>>>
>>> - /* Wa_14010685332:icl,jsl,ehl,tgl,rkl */
>>> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
>>> + /* Wa_14010685332:cnp/cmp,tgp,adp */
>>> + if (INTEL_PCH_TYPE(dev_priv) == PCH_CNP ||
>>> + (INTEL_PCH_TYPE(dev_priv) >= PCH_TGP &&
>>> + INTEL_PCH_TYPE(dev_priv) < PCH_DG1)) {
>>> intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
>>> SBCLK_RUN_REFCLK_DIS, SBCLK_RUN_REFCLK_DIS);
>>> intel_uncore_rmw(uncore, SOUTH_CHICKEN1,
>>> --
>>> 2.26.2
>>>
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
