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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxxx>

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@xxxxxxxxx>
---
    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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux