drm/i915: Add documentation to gen9_set_dc_state()

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

drivers/gpu/drm/i915/intel_runtime_pm.c +23 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 
+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering
+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *
+ * Based on the above enabling a deeper DC power state is asynchronous wrt.
+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write
+ * to DC_STATE_EN blocking until the state is restored.
+ */
 static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
 {
 	uint32_t val;

Signature · 1 line

2.13.2

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

drivers/gpu/drm/i915/intel_runtime_pm.c +23 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 
+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering
+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *
+ * Based on the above enabling a deeper DC power state is asynchronous wrt.
+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write
+ * to DC_STATE_EN blocking until the state is restored.
+ */
 static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
 {
 	uint32_t val;

Cc Rodrigo, DK, Ville

Quoted 10 lines · Imre Deak

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

Quoted 5 lines

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

I think I'm still missing a definitive answer to the question, who disables PSR before DP AUX transactions?

Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in pps_lock() cause PSR exit, through the DC state change? If yes, this needs to be properly documented in code. Maybe with a WARN_ON(psr active) on top.

Quoting bspec 7530, "DDI A AUX channel transactions must not be sent while SRD is enabled. SRD must be completely disabled before a DDI A AUX channel transaction can be sent."

I'm also confused how sink CRC would ever work with PSR enabled.

BR,
Jani.

Quoted 35 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +23 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 
+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering
+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *
+ * Based on the above enabling a deeper DC power state is asynchronous wrt.
+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write
+ * to DC_STATE_EN blocking until the state is restored.
+ */
 static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
 {
 	uint32_t val;

Argh, now with Ville's correct address.

Quoted 26 lines · Jani Nikula

Cc Rodrigo, DK, Ville

Quoted 10 lines · Imre Deak

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

Quoted 5 lines

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

I think I'm still missing a definitive answer to the question, who disables PSR before DP AUX transactions?

Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in pps_lock() cause PSR exit, through the DC state change? If yes, this needs to be properly documented in code. Maybe with a WARN_ON(psr active) on top.

Quoted 38 lines

Quoting bspec 7530, "DDI A AUX channel transactions must not be sent while SRD is enabled. SRD must be completely disabled before a DDI A AUX channel transaction can be sent."

I'm also confused how sink CRC would ever work with PSR enabled.

BR,
Jani.

Quoted 27 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +18 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 
+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering
+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *
+ * Based on the above enabling a deeper DC power state is asynchronous wrt.

Quoted 8 lines

Quoted 8 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +5 -0

+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write
+ * to DC_STATE_EN blocking until the state is restored.
+ */
 static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
 {
 	uint32_t val;

Signature · 1 line

Jani Nikula, Intel Open Source Technology Center

Quoted 17 lines · Jani Nikula

Argh, now with Ville's correct address.

Quoted 13 lines · Jani Nikula

Cc Rodrigo, DK, Ville

Quoted 10 lines · Imre Deak

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

I think I'm still missing a definitive answer to the question, who disables PSR before DP AUX transactions?

Quoted 5 lines

Quoted 5 lines

Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in pps_lock() cause PSR exit, through the DC state change? If yes, this needs to be properly documented in code. Maybe with a WARN_ON(psr active) on top.

No, that was only my misunderstanding earlier on IRC. Disabling DC states doesn't prevent PSR entry. So the PSR active state is independent of DC states; if PSR is enabled with DC5/6 disabled it just means there will be less power saving during PSR active periods than it would be possible with DC5/6 enabled.

Disabling PSR then has to happen by some other means while the driver performs AUX transfers, either disabling it manually from the driver, or by using the AUX HW mutex.

Quoted 7 lines

Quoted 7 lines

Quoting bspec 7530, "DDI A AUX channel transactions must not be sent while SRD is enabled. SRD must be completely disabled before a DDI A AUX channel transaction can be sent."

I'm also confused how sink CRC would ever work with PSR enabled.

Quoted 35 lines

Quoted 35 lines

BR,
Jani.

Quoted 30 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +21 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 
+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering
+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *
+ * Based on the above enabling a deeper DC power state is asynchronous wrt.
+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write

Quoted 8 lines

Quoted 5 lines

Quoted 5 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +2 -0

+ * to DC_STATE_EN blocking until the state is restored.
+ */
 static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
 {
 	uint32_t val;

Signature · 1 line

Jani Nikula, Intel Open Source Technology Center

Quoted 18 lines · Imre Deak

Quoted 17 lines · Jani Nikula

Argh, now with Ville's correct address.

Quoted 13 lines · Jani Nikula

Cc Rodrigo, DK, Ville

Quoted 10 lines · Imre Deak

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

I think I'm still missing a definitive answer to the question, who disables PSR before DP AUX transactions?

no one. :(

This is a gap that we are aware. I believe Jose is working to address that.

cc Jose.

Quoted 11 lines

Quoted 5 lines

Quoted 5 lines

Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in pps_lock() cause PSR exit, through the DC state change? If yes, this needs to be properly documented in code. Maybe with a WARN_ON(psr active) on top.

No, that was only my misunderstanding earlier on IRC. Disabling DC states doesn't prevent PSR entry. So the PSR active state is independent of DC states; if PSR is enabled with DC5/6 disabled it just means there will be less power saving during PSR active periods than it would be possible with DC5/6 enabled.

Yeap, they are independent.

Quoted 1 line

Quoted 3 lines

Disabling PSR then has to happen by some other means while the driver performs AUX transfers, either disabling it manually from the driver, or by using the AUX HW mutex.

AUX HW mutex is not an option. It got discarded again. Guidance from HW eng is to avoid it and disable PSR manually before aux transactions.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoting bspec 7530, "DDI A AUX channel transactions must not be sent while SRD is enabled. SRD must be completely disabled before a DDI A AUX channel transaction can be sent."

I'm also confused how sink CRC would ever work with PSR enabled.

Our driver does aux transactions on modesets and hw does them on psr sync.

Sink CRC is used on the tests after modeset and hopefully when psr is stable. But this actually could explain most of sink CRC issues we had so far, indeed. Too much assumption and so less checks and protections :(

my bad...

Quoted 43 lines

Quoted 43 lines

Quoted 40 lines

BR,
Jani.

Quoted 35 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +23 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 
+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering
+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *
+ * Based on the above enabling a deeper DC power state is asynchronous wrt.
+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write
+ * to DC_STATE_EN blocking until the state is restored.
+ */
 static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
 {
 	uint32_t val;

Signature · 1 line

Jani Nikula, Intel Open Source Technology Center

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

drivers/gpu/drm/i915/intel_runtime_pm.c +1 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 
+/**

Quoted 24 lines · Imre Deak

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

drivers/gpu/drm/i915/intel_runtime_pm.c +0 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 

drivers/gpu/drm/i915/intel_runtime_pm.c void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv) · line 555

Quoted 11 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +11 -0

+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering

Any chance you could eliminate the firmware/HW ambiguity? Not knowing whether it is the firmware or the HW leads to potentially incorrect assumptions.

drivers/gpu/drm/i915/intel_runtime_pm.c void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv) · line 561

Quoted 6 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +6 -0

+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *

One of things that is completely misleading is the enable_dc6 debug message we print. It is all over dmesg, but like you already wrote, HW needs PSR to be enabled and only in a single-pipe active case, the display controller can go to DC6. So, with PSR disabled upstream, there is really no chance that the HW can go to DC6 without all displays disabled.

drivers/gpu/drm/i915/intel_runtime_pm.c void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv) · line 570

Quoted 9 lines

drivers/gpu/drm/i915/intel_runtime_pm.c +6 -0

+ * Based on the above enabling a deeper DC power state is asynchronous wrt.
+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write
+ * to DC_STATE_EN blocking until the state is restored.
+ */
 static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
 {
 	uint32_t val;

Add documentation to gen9_set_dc_state() on what enabling a given DC state means and at what point HW/DMC actually enters/exits these states.

Cc Jani Nikula <[email protected]>

Cc Daniel Vetter <[email protected]>

Signed-off-by Imre Deak <[email protected]>

---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

[ On IRC I stated that PSR entry would be prevented in a given DC state,
but looking more at it I haven't found any proof for this. So as I understand the only connection between PSR and DC states is that if DC5/6 is disabled power saving will be blocked, which would otherwise be possible when PSR is active and the display pipe is off. ]

drivers/gpu/drm/i915/intel_runtime_pm.c +23 -0

index 53ea564f971e..40a7955886d4 100644
@@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
 	dev_priv->csr.dc_state = val;
 }
 
+/**
+ * gen9_set_dc_state - set target display C power state
+ * @dev_priv: i915 device instance
+ * @state: target DC power state
+ * - DC_STATE_DISABLE
+ * - DC_STATE_EN_UPTO_DC5
+ * - DC_STATE_EN_UPTO_DC6
+ * - DC_STATE_EN_DC9
+ *
+ * Signal to DMC firmware/HW the target DC power state passed in @state.
+ * DMC/HW can turn off individual display clocks and power rails when entering
+ * a deeper DC power state (higher in number) and turns these back when exiting
+ * that state to a shallower power state (lower in number). The HW will decide
+ * when to actually enter a given state on an on-demand basis, for instance
+ * depending on the active state of display pipes. The state of display
+ * registers backed by affected power rails are saved/restored as needed.
+ *
+ * Based on the above enabling a deeper DC power state is asynchronous wrt.
+ * enabling it. Disabling a deeper power state is synchronous: for instance
+ * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
+ * back on and register state is restored. This is guaranteed by the MMIO write
+ * to DC_STATE_EN blocking until the state is restored.
+ */
 static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
 {
 	uint32_t val;

Signature · 6 lines

2.13.2

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx