[Intel-gfx] [PATCH] drm/i915/skl: While sanitizing cdclock check the SWF18 as well

[Kumar, Shobhit]

On 11/02/2015 11:48 PM, Thulasimani, Sivakumar wrote:
>
>
> On 11/2/2015 11:17 PM, Kumar, Shobhit wrote:
>> On 11/02/2015 10:07 PM, Thulasimani, Sivakumar wrote:
>>>
>>>
>>> On 11/2/2015 6:49 PM, Kumar, Shobhit wrote:
>>>> On 11/02/2015 06:40 PM, Jani Nikula wrote:
>>>>> On Mon, 02 Nov 2015, Shobhit Kumar <shobhit.kumar at intel.com> wrote:
>>>>>> SWF18 is set if the display has been intialized by the pre-os. It
>>>>>> also gives what configuration is enabled on which pipe. The DPLL and
>>>>>> CDCLK verification checks can fail as the pre-os does initialize the
>>>>>> DPLL for Audio codec initialization. So fisrt check if SWF18 is
>>>>>> set and
>>>>>> then follow through with other DPLL and CDCLK verification.
>>>>>
>>>>> Can we universally trust all bios/gop/bootloader/whatnot to have
>>>>> initialized this? What if it's not set?
>>>>>
>>>>
>>>> As per my discussion with gop team, this has been enabled in main
>>>> stream for quite sometime including VLV, CHT, BDW, SKL+ and is common
>>>> for GOP/VBIOS across chrome/windows/android. So yes I think we can
>>>> universally trust as of now.
>>> This has been added since IVB timeframe and should be part of VBT spec.
>>> but i just encountered
>>> an issue in Android Charging OS where there is no modeset and is using
>>> the displays
>>> enabled by GOP/VBIOS. This patch might break such expectations.
>>
>> Why would this break anything in Android charging UI. Basically this
>> patch only says do cdclock sanitization if display is not enabled by
>> pre-os. In this use case it is already enabled by GOP/VBIOS and the
>> driver any way expects it to be programmed by pre-os in general. So in
>> this scenario, the sanitization logic will not do anything at all
>> because SWF18 will be set and CDCLOCK and DPLL will be properly
>> enabled already and just return false. Fast-modeset should not be
>> broken by this at all.
>>
> my bad :( should review carefully when sitting late night.
>>>>
>>>> Regards
>>>> Shobhit
>>>>
>>>>> BR,
>>>>> Jani.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
>>>>>> Signed-off-by: Shobhit Kumar <shobhit.kumar at intel.com>
>>>>>> ---
>>>>>>   drivers/gpu/drm/i915/i915_reg.h      | 3 +++
>>>>>>   drivers/gpu/drm/i915/intel_display.c | 8 ++++++++
>>>>>>   2 files changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>>>>> b/drivers/gpu/drm/i915/i915_reg.h
>>>>>> index 9ee9481..bd476ff 100644
>>>>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>>>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>>>>> @@ -5006,6 +5006,9 @@ enum skl_disp_power_wells {
>>>>>>   #define SWF1(i) (dev_priv->info.display_mmio_offset + 0x71410 +
>>>>>> (i) * 4)
>>>>>>   #define SWF3(i) (dev_priv->info.display_mmio_offset + 0x72414 +
>>>>>> (i) * 4)
>>>>>>
>>>>>> +/* VBIOS flag for display initialized status */
>>>>>> +#define GEN6_SWF18 (dev_priv->info.display_mmio_offset + 0x4F060)
>>>>>> +
>>>>>>   /* Pipe B */
>>>>>>   #define _PIPEBDSL (dev_priv->info.display_mmio_offset + 0x71000)
>>>>>>   #define _PIPEBCONF (dev_priv->info.display_mmio_offset + 0x71008)
>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>>>> index 103cacb..0ecb35c 100644
>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>>>> @@ -5761,6 +5761,14 @@ int skl_sanitize_cdclk(struct
>>>>>> drm_i915_private *dev_priv)
>>>>>>       uint32_t cdctl = I915_READ(CDCLK_CTL);
>>>>>>       int freq = dev_priv->skl_boot_cdclk;
>>>>>>
>>>>>> +    /*
>>>>>> +     * check if the pre-os intialized the display
>>>>>> +     * There is SWF18 scratchpad register defined which is set by
>>>>>> the
>>>>>> +     * pre-os which can be used by the OS drivers to check the
>>>>>> status
>>>>>> +     */
>>>>>> +    if ((I915_READ(GEN6_SWF18) & 0x00FFFF) == 0)
>>>>>> +        goto sanitize;
>>>>>> +
>>>>>>       /* Is PLL enabled and locked ? */
>>>>>>       if (!((lcpll1 & LCPLL_PLL_ENABLE) && (lcpll1 &
>>>>>> LCPLL_PLL_LOCK)))
>>>>>>           goto sanitize;
>>>>>
> can you share bit more details on when GOP/VBIOS sets DPLL but does not
> enable
> display ? (atleast that is what i understood from the commit message)
>

This patch has to be looked in continuation with the patch for sanitize 
cdclk which I gave in cover letter to get the full context. Basic point 
here is that GOP/VBIOS does not enable DPLL as that is not even loaded 
in certain use cases. It is the FSP/BIOS that loads the GOP and executes 
it to enable display. In this case, FSP does not load GOP/VBIOS but 
still programs DPLL itself for some audio codec initialization. The 
sanitize cdclock function has to decide when to do the sanitization. 
That was based on DPLL check and CDCLK verification, but both are done 
by BIOS and hence will assume everything is fine when it is not. That is 
why additional check of SWF18 is added.

I can clarify a bit more in the commit message.

Regards
Shobhit

> regards,
> Sivakumar
>>>> _______________________________________________
>>>> Intel-gfx mailing list
>>>> Intel-gfx at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>