All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Fix rawclk readout for g4x
@ 2017-05-04 18:15 ` ville.syrjala
  0 siblings, 0 replies; 7+ messages in thread
From: ville.syrjala @ 2017-05-04 18:15 UTC (permalink / raw)
  To: intel-gfx; +Cc: stable, Tomi Sarvela

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Turns out our skills in decoding the CLKCFG register weren't good
enough. On this particular elk the answer we got was 400 MHz when
in reality the clock was running at 266 MHz, which then caused us
to program a bogus AUX clock divider that caused all AUX communication
to fail.

Sadly the docs are now in bit heaven, so the fix will have to be based
on empirical evidence. Using another elk machine I was able to frob
the FSB frequency from the BIOS and see how it affects the CLKCFG
register. The machine seesm to use a frequency of 266 MHz by default,
and fortunately it still boot even with the 50% CPU overclock that
we get when we bump the FSB up to 400 MHz.

It turns out the actual FSB frequency and the register have no real
link whatsoever. The register value is based on some straps or something,
but fortunately those too can be configured from the BIOS on this board,
although it doesn't seem to respect the settings 100%. In the end I was
able to derive the following relationship:

BIOS FSB / strap | CLKCFG
-------------------------
200              | 0x2
266              | 0x0
333              | 0x4
400              | 0x4

So only the 200 and 400 MHz cases actually match how we're currently
decoding that register. But as the comment next to some of the defines
says, we have been just guessing anyway.

So let's fix things up so that at least the 266 MHz case will work
correctly as that is actually the setting used by both the buggy
machine and my test machine.

The fact that 333 and 400 MHz BIOS settings result in the same register
value is a little disappointing, as that means we can't tell them apart.
However, according to the gmch datasheet for both elk and ctg 400 Mhz is
not even a supported FSB frequency, so I'm going to make the assumption
that we should decode it as 333 MHz instead.

Cc: stable@vger.kernel.org
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h    | 10 +++++++---
 drivers/gpu/drm/i915/intel_cdclk.c |  6 ++----
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee8170cda93e..524fdfda9d45 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3059,10 +3059,14 @@ enum skl_disp_power_wells {
 #define CLKCFG_FSB_667					(3 << 0)	/* hrawclk 166 */
 #define CLKCFG_FSB_800					(2 << 0)	/* hrawclk 200 */
 #define CLKCFG_FSB_1067					(6 << 0)	/* hrawclk 266 */
+#define CLKCFG_FSB_1067_ALT				(0 << 0)	/* hrawclk 266 */
 #define CLKCFG_FSB_1333					(7 << 0)	/* hrawclk 333 */
-/* Note, below two are guess */
-#define CLKCFG_FSB_1600					(4 << 0)	/* hrawclk 400 */
-#define CLKCFG_FSB_1600_ALT				(0 << 0)	/* hrawclk 400 */
+/*
+ * Note that on at least on ELK the below value is reported for both
+ * 333 and 400 MHz BIOS FSB setting, but given that the gmch datasheet
+ * lists only 200/266/333 MHz FSB as supported let's decode it as 333 MHz.
+ */
+#define CLKCFG_FSB_1333_ALT				(4 << 0)	/* hrawclk 333 */
 #define CLKCFG_FSB_MASK					(7 << 0)
 #define CLKCFG_MEM_533					(1 << 4)
 #define CLKCFG_MEM_667					(2 << 4)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
index 763010f8ad89..29792972d55d 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1808,13 +1808,11 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
 	case CLKCFG_FSB_800:
 		return 200000;
 	case CLKCFG_FSB_1067:
+	case CLKCFG_FSB_1067_ALT:
 		return 266667;
 	case CLKCFG_FSB_1333:
+	case CLKCFG_FSB_1333_ALT:
 		return 333333;
-	/* these two are just a guess; one of them might be right */
-	case CLKCFG_FSB_1600:
-	case CLKCFG_FSB_1600_ALT:
-		return 400000;
 	default:
 		return 133333;
 	}
-- 
2.10.2

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH] drm/i915: Fix rawclk readout for g4x
@ 2017-05-04 18:15 ` ville.syrjala
  0 siblings, 0 replies; 7+ messages in thread
From: ville.syrjala @ 2017-05-04 18:15 UTC (permalink / raw)
  To: intel-gfx; +Cc: Tomi Sarvela, stable

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Turns out our skills in decoding the CLKCFG register weren't good
enough. On this particular elk the answer we got was 400 MHz when
in reality the clock was running at 266 MHz, which then caused us
to program a bogus AUX clock divider that caused all AUX communication
to fail.

Sadly the docs are now in bit heaven, so the fix will have to be based
on empirical evidence. Using another elk machine I was able to frob
the FSB frequency from the BIOS and see how it affects the CLKCFG
register. The machine seesm to use a frequency of 266 MHz by default,
and fortunately it still boot even with the 50% CPU overclock that
we get when we bump the FSB up to 400 MHz.

It turns out the actual FSB frequency and the register have no real
link whatsoever. The register value is based on some straps or something,
but fortunately those too can be configured from the BIOS on this board,
although it doesn't seem to respect the settings 100%. In the end I was
able to derive the following relationship:

BIOS FSB / strap | CLKCFG
-------------------------
200              | 0x2
266              | 0x0
333              | 0x4
400              | 0x4

So only the 200 and 400 MHz cases actually match how we're currently
decoding that register. But as the comment next to some of the defines
says, we have been just guessing anyway.

So let's fix things up so that at least the 266 MHz case will work
correctly as that is actually the setting used by both the buggy
machine and my test machine.

The fact that 333 and 400 MHz BIOS settings result in the same register
value is a little disappointing, as that means we can't tell them apart.
However, according to the gmch datasheet for both elk and ctg 400 Mhz is
not even a supported FSB frequency, so I'm going to make the assumption
that we should decode it as 333 MHz instead.

Cc: stable@vger.kernel.org
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h    | 10 +++++++---
 drivers/gpu/drm/i915/intel_cdclk.c |  6 ++----
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee8170cda93e..524fdfda9d45 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3059,10 +3059,14 @@ enum skl_disp_power_wells {
 #define CLKCFG_FSB_667					(3 << 0)	/* hrawclk 166 */
 #define CLKCFG_FSB_800					(2 << 0)	/* hrawclk 200 */
 #define CLKCFG_FSB_1067					(6 << 0)	/* hrawclk 266 */
+#define CLKCFG_FSB_1067_ALT				(0 << 0)	/* hrawclk 266 */
 #define CLKCFG_FSB_1333					(7 << 0)	/* hrawclk 333 */
-/* Note, below two are guess */
-#define CLKCFG_FSB_1600					(4 << 0)	/* hrawclk 400 */
-#define CLKCFG_FSB_1600_ALT				(0 << 0)	/* hrawclk 400 */
+/*
+ * Note that on at least on ELK the below value is reported for both
+ * 333 and 400 MHz BIOS FSB setting, but given that the gmch datasheet
+ * lists only 200/266/333 MHz FSB as supported let's decode it as 333 MHz.
+ */
+#define CLKCFG_FSB_1333_ALT				(4 << 0)	/* hrawclk 333 */
 #define CLKCFG_FSB_MASK					(7 << 0)
 #define CLKCFG_MEM_533					(1 << 4)
 #define CLKCFG_MEM_667					(2 << 4)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
index 763010f8ad89..29792972d55d 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1808,13 +1808,11 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
 	case CLKCFG_FSB_800:
 		return 200000;
 	case CLKCFG_FSB_1067:
+	case CLKCFG_FSB_1067_ALT:
 		return 266667;
 	case CLKCFG_FSB_1333:
+	case CLKCFG_FSB_1333_ALT:
 		return 333333;
-	/* these two are just a guess; one of them might be right */
-	case CLKCFG_FSB_1600:
-	case CLKCFG_FSB_1600_ALT:
-		return 400000;
 	default:
 		return 133333;
 	}
-- 
2.10.2

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

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* ✓ Fi.CI.BAT: success for drm/i915: Fix rawclk readout for g4x
  2017-05-04 18:15 ` ville.syrjala
  (?)
@ 2017-05-04 18:34 ` Patchwork
  -1 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2017-05-04 18:34 UTC (permalink / raw)
  To: ville.syrjala; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Fix rawclk readout for g4x
URL   : https://patchwork.freedesktop.org/series/23978/
State : success

== Summary ==

Series 23978v1 drm/i915: Fix rawclk readout for g4x
https://patchwork.freedesktop.org/api/1.0/series/23978/revisions/1/mbox/

fi-bdw-5557u     total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  time:432s
fi-bdw-gvtdvm    total:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  time:425s
fi-bsw-n3050     total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  time:579s
fi-bxt-j4205     total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  time:515s
fi-bxt-t5700     total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  time:564s
fi-byt-j1900     total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  time:494s
fi-byt-n2820     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  time:483s
fi-hsw-4770      total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  time:411s
fi-hsw-4770r     total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  time:409s
fi-ilk-650       total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  time:420s
fi-ivb-3520m     total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:480s
fi-ivb-3770      total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:487s
fi-kbl-7500u     total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:458s
fi-kbl-7560u     total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  time:571s
fi-skl-6260u     total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:454s
fi-skl-6700hq    total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  time:573s
fi-skl-6700k     total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  time:455s
fi-skl-6770hq    total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:492s
fi-skl-gvtdvm    total:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  time:430s
fi-snb-2520m     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  time:529s
fi-snb-2600      total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  time:413s

369880c1680bf9bde467a40d2a03d3ad32341281 drm-tip: 2017y-05m-04d-15h-00m-33s UTC integration manifest
be10d0a drm/i915: Fix rawclk readout for g4x

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4624/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix rawclk readout for g4x
  2017-05-04 18:15 ` ville.syrjala
@ 2017-05-05  6:48   ` Jani Nikula
  -1 siblings, 0 replies; 7+ messages in thread
From: Jani Nikula @ 2017-05-05  6:48 UTC (permalink / raw)
  To: ville.syrjala, intel-gfx; +Cc: Tomi Sarvela, stable

On Thu, 04 May 2017, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Turns out our skills in decoding the CLKCFG register weren't good
> enough. On this particular elk the answer we got was 400 MHz when
> in reality the clock was running at 266 MHz, which then caused us
> to program a bogus AUX clock divider that caused all AUX communication
> to fail.
>
> Sadly the docs are now in bit heaven, so the fix will have to be based
> on empirical evidence. Using another elk machine I was able to frob
> the FSB frequency from the BIOS and see how it affects the CLKCFG
> register. The machine seesm to use a frequency of 266 MHz by default,
> and fortunately it still boot even with the 50% CPU overclock that
> we get when we bump the FSB up to 400 MHz.
>
> It turns out the actual FSB frequency and the register have no real
> link whatsoever. The register value is based on some straps or something,
> but fortunately those too can be configured from the BIOS on this board,
> although it doesn't seem to respect the settings 100%. In the end I was
> able to derive the following relationship:
>
> BIOS FSB / strap | CLKCFG
> -------------------------
> 200              | 0x2
> 266              | 0x0
> 333              | 0x4
> 400              | 0x4
>
> So only the 200 and 400 MHz cases actually match how we're currently
> decoding that register. But as the comment next to some of the defines
> says, we have been just guessing anyway.
>
> So let's fix things up so that at least the 266 MHz case will work
> correctly as that is actually the setting used by both the buggy
> machine and my test machine.
>
> The fact that 333 and 400 MHz BIOS settings result in the same register
> value is a little disappointing, as that means we can't tell them apart.
> However, according to the gmch datasheet for both elk and ctg 400 Mhz is
> not even a supported FSB frequency, so I'm going to make the assumption
> that we should decode it as 333 MHz instead.

If you look at b11248df4c0d ("drm/i915: Add CLKCFG register definition")
and 7662c8bd6545 ("drm/i915: add FIFO watermark support"), the original
values seem to be on the guesswork side as well...

As such can't review, but

Acked-by: Jani Nikula <jani.nikula@intel.com>

>
> Cc: stable@vger.kernel.org
> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
> Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_reg.h    | 10 +++++++---
>  drivers/gpu/drm/i915/intel_cdclk.c |  6 ++----
>  2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ee8170cda93e..524fdfda9d45 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3059,10 +3059,14 @@ enum skl_disp_power_wells {
>  #define CLKCFG_FSB_667					(3 << 0)	/* hrawclk 166 */
>  #define CLKCFG_FSB_800					(2 << 0)	/* hrawclk 200 */
>  #define CLKCFG_FSB_1067					(6 << 0)	/* hrawclk 266 */
> +#define CLKCFG_FSB_1067_ALT				(0 << 0)	/* hrawclk 266 */
>  #define CLKCFG_FSB_1333					(7 << 0)	/* hrawclk 333 */
> -/* Note, below two are guess */
> -#define CLKCFG_FSB_1600					(4 << 0)	/* hrawclk 400 */
> -#define CLKCFG_FSB_1600_ALT				(0 << 0)	/* hrawclk 400 */
> +/*
> + * Note that on at least on ELK the below value is reported for both
> + * 333 and 400 MHz BIOS FSB setting, but given that the gmch datasheet
> + * lists only 200/266/333 MHz FSB as supported let's decode it as 333 MHz.
> + */
> +#define CLKCFG_FSB_1333_ALT				(4 << 0)	/* hrawclk 333 */
>  #define CLKCFG_FSB_MASK					(7 << 0)
>  #define CLKCFG_MEM_533					(1 << 4)
>  #define CLKCFG_MEM_667					(2 << 4)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
> index 763010f8ad89..29792972d55d 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1808,13 +1808,11 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
>  	case CLKCFG_FSB_800:
>  		return 200000;
>  	case CLKCFG_FSB_1067:
> +	case CLKCFG_FSB_1067_ALT:
>  		return 266667;
>  	case CLKCFG_FSB_1333:
> +	case CLKCFG_FSB_1333_ALT:
>  		return 333333;
> -	/* these two are just a guess; one of them might be right */
> -	case CLKCFG_FSB_1600:
> -	case CLKCFG_FSB_1600_ALT:
> -		return 400000;
>  	default:
>  		return 133333;
>  	}

-- 
Jani Nikula, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/i915: Fix rawclk readout for g4x
@ 2017-05-05  6:48   ` Jani Nikula
  0 siblings, 0 replies; 7+ messages in thread
From: Jani Nikula @ 2017-05-05  6:48 UTC (permalink / raw)
  To: ville.syrjala, intel-gfx; +Cc: Tomi Sarvela, stable

On Thu, 04 May 2017, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Turns out our skills in decoding the CLKCFG register weren't good
> enough. On this particular elk the answer we got was 400 MHz when
> in reality the clock was running at 266 MHz, which then caused us
> to program a bogus AUX clock divider that caused all AUX communication
> to fail.
>
> Sadly the docs are now in bit heaven, so the fix will have to be based
> on empirical evidence. Using another elk machine I was able to frob
> the FSB frequency from the BIOS and see how it affects the CLKCFG
> register. The machine seesm to use a frequency of 266 MHz by default,
> and fortunately it still boot even with the 50% CPU overclock that
> we get when we bump the FSB up to 400 MHz.
>
> It turns out the actual FSB frequency and the register have no real
> link whatsoever. The register value is based on some straps or something,
> but fortunately those too can be configured from the BIOS on this board,
> although it doesn't seem to respect the settings 100%. In the end I was
> able to derive the following relationship:
>
> BIOS FSB / strap | CLKCFG
> -------------------------
> 200              | 0x2
> 266              | 0x0
> 333              | 0x4
> 400              | 0x4
>
> So only the 200 and 400 MHz cases actually match how we're currently
> decoding that register. But as the comment next to some of the defines
> says, we have been just guessing anyway.
>
> So let's fix things up so that at least the 266 MHz case will work
> correctly as that is actually the setting used by both the buggy
> machine and my test machine.
>
> The fact that 333 and 400 MHz BIOS settings result in the same register
> value is a little disappointing, as that means we can't tell them apart.
> However, according to the gmch datasheet for both elk and ctg 400 Mhz is
> not even a supported FSB frequency, so I'm going to make the assumption
> that we should decode it as 333 MHz instead.

If you look at b11248df4c0d ("drm/i915: Add CLKCFG register definition")
and 7662c8bd6545 ("drm/i915: add FIFO watermark support"), the original
values seem to be on the guesswork side as well...

As such can't review, but

Acked-by: Jani Nikula <jani.nikula@intel.com>

>
> Cc: stable@vger.kernel.org
> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
> Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_reg.h    | 10 +++++++---
>  drivers/gpu/drm/i915/intel_cdclk.c |  6 ++----
>  2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ee8170cda93e..524fdfda9d45 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3059,10 +3059,14 @@ enum skl_disp_power_wells {
>  #define CLKCFG_FSB_667					(3 << 0)	/* hrawclk 166 */
>  #define CLKCFG_FSB_800					(2 << 0)	/* hrawclk 200 */
>  #define CLKCFG_FSB_1067					(6 << 0)	/* hrawclk 266 */
> +#define CLKCFG_FSB_1067_ALT				(0 << 0)	/* hrawclk 266 */
>  #define CLKCFG_FSB_1333					(7 << 0)	/* hrawclk 333 */
> -/* Note, below two are guess */
> -#define CLKCFG_FSB_1600					(4 << 0)	/* hrawclk 400 */
> -#define CLKCFG_FSB_1600_ALT				(0 << 0)	/* hrawclk 400 */
> +/*
> + * Note that on at least on ELK the below value is reported for both
> + * 333 and 400 MHz BIOS FSB setting, but given that the gmch datasheet
> + * lists only 200/266/333 MHz FSB as supported let's decode it as 333 MHz.
> + */
> +#define CLKCFG_FSB_1333_ALT				(4 << 0)	/* hrawclk 333 */
>  #define CLKCFG_FSB_MASK					(7 << 0)
>  #define CLKCFG_MEM_533					(1 << 4)
>  #define CLKCFG_MEM_667					(2 << 4)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
> index 763010f8ad89..29792972d55d 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1808,13 +1808,11 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
>  	case CLKCFG_FSB_800:
>  		return 200000;
>  	case CLKCFG_FSB_1067:
> +	case CLKCFG_FSB_1067_ALT:
>  		return 266667;
>  	case CLKCFG_FSB_1333:
> +	case CLKCFG_FSB_1333_ALT:
>  		return 333333;
> -	/* these two are just a guess; one of them might be right */
> -	case CLKCFG_FSB_1600:
> -	case CLKCFG_FSB_1600_ALT:
> -		return 400000;
>  	default:
>  		return 133333;
>  	}

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix rawclk readout for g4x
  2017-05-05  6:48   ` Jani Nikula
@ 2017-05-05 10:33     ` Ville Syrjälä
  -1 siblings, 0 replies; 7+ messages in thread
From: Ville Syrjälä @ 2017-05-05 10:33 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx, Tomi Sarvela, stable

On Fri, May 05, 2017 at 09:48:08AM +0300, Jani Nikula wrote:
> On Thu, 04 May 2017, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> >
> > Turns out our skills in decoding the CLKCFG register weren't good
> > enough. On this particular elk the answer we got was 400 MHz when
> > in reality the clock was running at 266 MHz, which then caused us
> > to program a bogus AUX clock divider that caused all AUX communication
> > to fail.
> >
> > Sadly the docs are now in bit heaven, so the fix will have to be based
> > on empirical evidence. Using another elk machine I was able to frob
> > the FSB frequency from the BIOS and see how it affects the CLKCFG
> > register. The machine seesm to use a frequency of 266 MHz by default,
> > and fortunately it still boot even with the 50% CPU overclock that
> > we get when we bump the FSB up to 400 MHz.
> >
> > It turns out the actual FSB frequency and the register have no real
> > link whatsoever. The register value is based on some straps or something,
> > but fortunately those too can be configured from the BIOS on this board,
> > although it doesn't seem to respect the settings 100%. In the end I was
> > able to derive the following relationship:
> >
> > BIOS FSB / strap | CLKCFG
> > -------------------------
> > 200              | 0x2
> > 266              | 0x0
> > 333              | 0x4
> > 400              | 0x4
> >
> > So only the 200 and 400 MHz cases actually match how we're currently
> > decoding that register. But as the comment next to some of the defines
> > says, we have been just guessing anyway.
> >
> > So let's fix things up so that at least the 266 MHz case will work
> > correctly as that is actually the setting used by both the buggy
> > machine and my test machine.
> >
> > The fact that 333 and 400 MHz BIOS settings result in the same register
> > value is a little disappointing, as that means we can't tell them apart.
> > However, according to the gmch datasheet for both elk and ctg 400 Mhz is
> > not even a supported FSB frequency, so I'm going to make the assumption
> > that we should decode it as 333 MHz instead.
> 
> If you look at b11248df4c0d ("drm/i915: Add CLKCFG register definition")
> and 7662c8bd6545 ("drm/i915: add FIFO watermark support"), the original
> values seem to be on the guesswork side as well...

Some of them do match what's in the gmch datasheets for some platforms.
But sadly all the gmch datasheet are very incomplete, and some lack this
register entirely.

I would prefer to find a way to read this out from some actual PLL or
something, because these strap values might not have anything to do with
reality if the user has adjusted the FSB manually via the BIOS. But
yeah, -ENODOCS so there's not much we can do.

> 
> As such can't review, but
> 
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> >
> > Cc: stable@vger.kernel.org
> > Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
> > Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
> > Signed-off-by: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h    | 10 +++++++---
> >  drivers/gpu/drm/i915/intel_cdclk.c |  6 ++----
> >  2 files changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index ee8170cda93e..524fdfda9d45 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3059,10 +3059,14 @@ enum skl_disp_power_wells {
> >  #define CLKCFG_FSB_667					(3 << 0)	/* hrawclk 166 */
> >  #define CLKCFG_FSB_800					(2 << 0)	/* hrawclk 200 */
> >  #define CLKCFG_FSB_1067					(6 << 0)	/* hrawclk 266 */
> > +#define CLKCFG_FSB_1067_ALT				(0 << 0)	/* hrawclk 266 */
> >  #define CLKCFG_FSB_1333					(7 << 0)	/* hrawclk 333 */
> > -/* Note, below two are guess */
> > -#define CLKCFG_FSB_1600					(4 << 0)	/* hrawclk 400 */
> > -#define CLKCFG_FSB_1600_ALT				(0 << 0)	/* hrawclk 400 */
> > +/*
> > + * Note that on at least on ELK the below value is reported for both
> > + * 333 and 400 MHz BIOS FSB setting, but given that the gmch datasheet
> > + * lists only 200/266/333 MHz FSB as supported let's decode it as 333 MHz.
> > + */
> > +#define CLKCFG_FSB_1333_ALT				(4 << 0)	/* hrawclk 333 */
> >  #define CLKCFG_FSB_MASK					(7 << 0)
> >  #define CLKCFG_MEM_533					(1 << 4)
> >  #define CLKCFG_MEM_667					(2 << 4)
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
> > index 763010f8ad89..29792972d55d 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -1808,13 +1808,11 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
> >  	case CLKCFG_FSB_800:
> >  		return 200000;
> >  	case CLKCFG_FSB_1067:
> > +	case CLKCFG_FSB_1067_ALT:
> >  		return 266667;
> >  	case CLKCFG_FSB_1333:
> > +	case CLKCFG_FSB_1333_ALT:
> >  		return 333333;
> > -	/* these two are just a guess; one of them might be right */
> > -	case CLKCFG_FSB_1600:
> > -	case CLKCFG_FSB_1600_ALT:
> > -		return 400000;
> >  	default:
> >  		return 133333;
> >  	}
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Ville Syrj�l�
Intel OTC

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915: Fix rawclk readout for g4x
@ 2017-05-05 10:33     ` Ville Syrjälä
  0 siblings, 0 replies; 7+ messages in thread
From: Ville Syrjälä @ 2017-05-05 10:33 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx, Tomi Sarvela, stable

On Fri, May 05, 2017 at 09:48:08AM +0300, Jani Nikula wrote:
> On Thu, 04 May 2017, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Turns out our skills in decoding the CLKCFG register weren't good
> > enough. On this particular elk the answer we got was 400 MHz when
> > in reality the clock was running at 266 MHz, which then caused us
> > to program a bogus AUX clock divider that caused all AUX communication
> > to fail.
> >
> > Sadly the docs are now in bit heaven, so the fix will have to be based
> > on empirical evidence. Using another elk machine I was able to frob
> > the FSB frequency from the BIOS and see how it affects the CLKCFG
> > register. The machine seesm to use a frequency of 266 MHz by default,
> > and fortunately it still boot even with the 50% CPU overclock that
> > we get when we bump the FSB up to 400 MHz.
> >
> > It turns out the actual FSB frequency and the register have no real
> > link whatsoever. The register value is based on some straps or something,
> > but fortunately those too can be configured from the BIOS on this board,
> > although it doesn't seem to respect the settings 100%. In the end I was
> > able to derive the following relationship:
> >
> > BIOS FSB / strap | CLKCFG
> > -------------------------
> > 200              | 0x2
> > 266              | 0x0
> > 333              | 0x4
> > 400              | 0x4
> >
> > So only the 200 and 400 MHz cases actually match how we're currently
> > decoding that register. But as the comment next to some of the defines
> > says, we have been just guessing anyway.
> >
> > So let's fix things up so that at least the 266 MHz case will work
> > correctly as that is actually the setting used by both the buggy
> > machine and my test machine.
> >
> > The fact that 333 and 400 MHz BIOS settings result in the same register
> > value is a little disappointing, as that means we can't tell them apart.
> > However, according to the gmch datasheet for both elk and ctg 400 Mhz is
> > not even a supported FSB frequency, so I'm going to make the assumption
> > that we should decode it as 333 MHz instead.
> 
> If you look at b11248df4c0d ("drm/i915: Add CLKCFG register definition")
> and 7662c8bd6545 ("drm/i915: add FIFO watermark support"), the original
> values seem to be on the guesswork side as well...

Some of them do match what's in the gmch datasheets for some platforms.
But sadly all the gmch datasheet are very incomplete, and some lack this
register entirely.

I would prefer to find a way to read this out from some actual PLL or
something, because these strap values might not have anything to do with
reality if the user has adjusted the FSB manually via the BIOS. But
yeah, -ENODOCS so there's not much we can do.

> 
> As such can't review, but
> 
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> >
> > Cc: stable@vger.kernel.org
> > Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
> > Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h    | 10 +++++++---
> >  drivers/gpu/drm/i915/intel_cdclk.c |  6 ++----
> >  2 files changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index ee8170cda93e..524fdfda9d45 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3059,10 +3059,14 @@ enum skl_disp_power_wells {
> >  #define CLKCFG_FSB_667					(3 << 0)	/* hrawclk 166 */
> >  #define CLKCFG_FSB_800					(2 << 0)	/* hrawclk 200 */
> >  #define CLKCFG_FSB_1067					(6 << 0)	/* hrawclk 266 */
> > +#define CLKCFG_FSB_1067_ALT				(0 << 0)	/* hrawclk 266 */
> >  #define CLKCFG_FSB_1333					(7 << 0)	/* hrawclk 333 */
> > -/* Note, below two are guess */
> > -#define CLKCFG_FSB_1600					(4 << 0)	/* hrawclk 400 */
> > -#define CLKCFG_FSB_1600_ALT				(0 << 0)	/* hrawclk 400 */
> > +/*
> > + * Note that on at least on ELK the below value is reported for both
> > + * 333 and 400 MHz BIOS FSB setting, but given that the gmch datasheet
> > + * lists only 200/266/333 MHz FSB as supported let's decode it as 333 MHz.
> > + */
> > +#define CLKCFG_FSB_1333_ALT				(4 << 0)	/* hrawclk 333 */
> >  #define CLKCFG_FSB_MASK					(7 << 0)
> >  #define CLKCFG_MEM_533					(1 << 4)
> >  #define CLKCFG_MEM_667					(2 << 4)
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c
> > index 763010f8ad89..29792972d55d 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -1808,13 +1808,11 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
> >  	case CLKCFG_FSB_800:
> >  		return 200000;
> >  	case CLKCFG_FSB_1067:
> > +	case CLKCFG_FSB_1067_ALT:
> >  		return 266667;
> >  	case CLKCFG_FSB_1333:
> > +	case CLKCFG_FSB_1333_ALT:
> >  		return 333333;
> > -	/* these two are just a guess; one of them might be right */
> > -	case CLKCFG_FSB_1600:
> > -	case CLKCFG_FSB_1600_ALT:
> > -		return 400000;
> >  	default:
> >  		return 133333;
> >  	}
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2017-05-05 10:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-04 18:15 [PATCH] drm/i915: Fix rawclk readout for g4x ville.syrjala
2017-05-04 18:15 ` ville.syrjala
2017-05-04 18:34 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-05-05  6:48 ` [Intel-gfx] [PATCH] " Jani Nikula
2017-05-05  6:48   ` Jani Nikula
2017-05-05 10:33   ` [Intel-gfx] " Ville Syrjälä
2017-05-05 10:33     ` Ville Syrjälä

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.