Re: [PATCH 1/2] drm/i915/bxt: Set oscaledcompmethod to enable scale value

["Jindal, Sonika" <sonika.jindal@intel.com>]

On 9/23/2015 1:02 AM, Imre Deak wrote:
> On Wed, 2015-09-23 at 00:01 +0530, Sivakumar Thulasimani wrote:
>>
>> On 9/22/2015 6:32 PM, Imre Deak wrote:
>>> On ma, 2015-09-21 at 23:00 +0530, Sivakumar Thulasimani wrote:
>>>> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
>>>>
>>>> On 9/18/2015 2:11 PM, Sonika Jindal wrote:
>>>>> Bspec update tells that we have to enable oscaledcompmethod instead of
>>>>> ouniqetrangenmethod for enabling scale value during swing programming.
>>>>> Also, scale value is 'don't care' for other levels except the last entry
>>>>> translation table. So, make it 0 instead of 0x9A.
>>>>>
>>>>> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
>>>>> ---
>>>>>     drivers/gpu/drm/i915/i915_reg.h  |    2 +-
>>>>>     drivers/gpu/drm/i915/intel_ddi.c |   22 +++++++++++-----------
>>>>>     2 files changed, 12 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>>>>> index 812b7b2..cec6546 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>>>> @@ -1395,7 +1395,7 @@ enum skl_disp_power_wells {
>>>>>     #define BXT_PORT_TX_DW3_LN0(port)	_PORT3(port, _PORT_TX_DW3_LN0_A,  \
>>>>>     						     _PORT_TX_DW3_LN0_B,  \
>>>>>     						     _PORT_TX_DW3_LN0_C)
>>>>> -#define   UNIQE_TRANGE_EN_METHOD	(1 << 27)
>>>>> +#define   SCALE_DCOMP_METHOD		(1 << 26)
>>>>>
>>>>>     #define _PORT_TX_DW4_LN0_A		0x162510
>>>>>     #define _PORT_TX_DW4_LN0_B		0x6C510
>>>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
>>>>> index fec51df..0d9b304 100644
>>>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>>>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>>>>> @@ -261,15 +261,15 @@ struct bxt_ddi_buf_trans {
>>>>>      */
>>>>>     static const struct bxt_ddi_buf_trans bxt_ddi_translations_dp[] = {
>>>>>     					/* Idx	NT mV diff	db  */
>>>>> -	{ 52,  0x9A, 0, 128, true  },	/* 0:	400		0   */
>>>>> -	{ 78,  0x9A, 0, 85,  false },	/* 1:	400		3.5 */
>>>>> -	{ 104, 0x9A, 0, 64,  false },	/* 2:	400		6   */
>>>>> -	{ 154, 0x9A, 0, 43,  false },	/* 3:	400		9.5 */
>>>>> -	{ 77,  0x9A, 0, 128, false },	/* 4:	600		0   */
>>>>> -	{ 116, 0x9A, 0, 85,  false },	/* 5:	600		3.5 */
>>>>> -	{ 154, 0x9A, 0, 64,  false },	/* 6:	600		6   */
>>>>> -	{ 102, 0x9A, 0, 128, false },	/* 7:	800		0   */
>>>>> -	{ 154, 0x9A, 0, 85,  false },	/* 8:	800		3.5 */
>>>>> +	{ 52,  0, 0, 128, true  },	/* 0:	400		0   */
>>>>> +	{ 78,  0, 0, 85,  false },	/* 1:	400		3.5 */
>>>>> +	{ 104, 0, 0, 64,  false },	/* 2:	400		6   */
>>>>> +	{ 154, 0, 0, 43,  false },	/* 3:	400		9.5 */
>>>>> +	{ 77,  0, 0, 128, false },	/* 4:	600		0   */
>>>>> +	{ 116, 0, 0, 85,  false },	/* 5:	600		3.5 */
>>>>> +	{ 154, 0, 0, 64,  false },	/* 6:	600		6   */
>>>>> +	{ 102, 0, 0, 128, false },	/* 7:	800		0   */
>>>>> +	{ 154, 0, 0, 85,  false },	/* 8:	800		3.5 */
>>> There is no point in changing the above values as they are don't-care in
>>> any case. In fact the reset value is 0x98 so I'd program that for these
>>> cases if we ever wanted to change them. For now I'd leave this as-is to
>>> keep in sync with the bxt_ddi_translations_hdmi table and also what CHV
>>> does.
>>>
Now it doesn't make a difference after we have set the oscalecompmethod 
correctly. But when we were not doing that, this 'don't care' value was 
making a difference. It was being considered.
I am sure of this because with low vswing table, only when I added 0x9A, 
it worked for me because we were not unsetting the oscaledcompmenthod.

So, I think its better to reset it to some value other than 0x9A.
Regarding 0x98 being the reset value, is it mentioned in bspec? I 
couldn't find that in the table. If that is the case, we can make it 
0x98 instead of 0x9A.

>>>>>     	{ 154, 0x9A, 1, 128, false },	/* 9:	1200		0   */
>>>>>     };
>>>
>>>>>
>>>>> @@ -2151,9 +2151,9 @@ static void bxt_ddi_vswing_sequence(struct drm_device *dev, u32 level,
>>>>>     	I915_WRITE(BXT_PORT_TX_DW2_GRP(port), val);
>>>>>
>>>>>     	val = I915_READ(BXT_PORT_TX_DW3_LN0(port));
>>>>> -	val &= ~UNIQE_TRANGE_EN_METHOD;
>>>>> +	val &= ~SCALE_DCOMP_METHOD;
>>>>>     	if (ddi_translations[level].enable)
>>>>> -		val |= UNIQE_TRANGE_EN_METHOD;
>>>>> +		val |= SCALE_DCOMP_METHOD;
>>> Please still leave behind a DRM_ERROR in case UNIQE_TRANGE_EN_METHOD was
>>> set in the register and we are disabling scaling. The scaling value does
>>> seem to depend on this bit too, so seeing if it was set can help
>>> tracking down problems.
>>>
Again, I couldn't find it mentioned anywhere that scaling value depends 
on "ouniqetrangenmethod" ? Is it in bspec?
Although it does seem to make a difference in case of low vswing table.
With default table, it edp continues to work if set or not set this bit.
I will add back the unsetting of this bit and then setting of this bit 
when 'enable' is set.

Regards,
Sonik
>> This was the only place UNIQE_TRANGE_EN_METHOD was set before, with that
>> removed
>> only possibility for it to be set is by GOP/VBIOS. (who are also
>> expected to make this change
>> if not done already.) in such a scenario wont an error message be
>> useless here ?
>
> Yes, this is exactly a check for BIOS settings. It wouldn't be the first
> case that BIOS didn't program something according to our expectations,
> especially given the multiple versions out there.
>
>>>>>     	I915_WRITE(BXT_PORT_TX_DW3_GRP(port), val);
>>>>>
>>>>>     	val = I915_READ(BXT_PORT_TX_DW4_LN0(port));
>>>
>>>
>>>
>>
>>
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx