drm/i915: BIOS display/adapter power state notifications
Subsystems (2)
cover drm/i915: BIOS display/adapter power state notifications
Hi all, here are some patches for letting the BIOS do some further power savings on HSW, now based on intel-drm-nightly with Paulo's PC8+ work.
Patches 1-4 are the glue code to wrap the BIOS SWSCI calls into a few sensible function calls.
Patches 5-6 are for reference only, and I presume they will have to be tweaked based on testing. Where exactly to do the calls? What parameters are to be used in the end? Possibly calls need to be added on the suspend/resume paths too.
I don't have the setup to do the testing and measurements, but I hope these will enable others.
BR,
Jani.
Jani Nikula (6):
drm/i915: expose intel_ddi_get_encoder_port()
drm/i915: add plumbing for SWSCI
drm/i915: add opregion function to notify bios of encoder
enable/disable
drm/i915: add opregion function to notify bios of adapter power state
DRAFT: drm/i915: do display power state notification on crtc
enable/disable
DRAFT: drm/i915: do adapter power state notification on PC8+
enable/disable
drivers/gpu/drm/i915/i915_drv.h | 12 ++ drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 12 +- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_opregion.c | 200 ++++++++++++++++++++++++++++++++- 5 files changed, 223 insertions(+), 4 deletions(-)
Signature · 1 line
1.7.9.5
PATCH 1/6 drm/i915: expose intel_ddi_get_encoder_port()
In preparation for followup work.
--- drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/intel_ddi.c +1 -1
@@ -58,7 +58,7 @@ static const u32 hsw_ddi_translations_fdi[] = { 0x00FFFFFF, 0x00040006 /* HDMI parameters */ }; -static enum port intel_ddi_get_encoder_port (struct intel_encoder *intel_encoder) +enum port intel_ddi_get_encoder_port (struct intel_encoder *intel_encoder) {struct drm_encoder *encoder = &intel_encoder->base;int type = intel_encoder->type;
drivers/gpu/drm/i915/intel_drv.h +1 -0
@@ -707,6 +707,7 @@ extern void intel_write_eld(struct drm_encoder *encoder,extern void intel_prepare_ddi (struct drm_device *dev);extern void hsw_fdi_link_train (struct drm_crtc *crtc);extern void intel_ddi_init (struct drm_device *dev,enum port port); +extern enum port intel_ddi_get_encoder_port (struct intel_encoder *intel_encoder);/* For use by IVB LP watermark workaround in intel_sprite.c */ extern void intel_update_watermarks (struct drm_device *dev);
Signature · 1 line
1.7.9.5
Re: [PATCH 1/6] drm/i915: expose intel_ddi_get_encoder_port()
2013/8/23 Jani Nikula <[email protected]>:
Quoted 3 lines
In preparation for followup work.
Signed-off-by Jani Nikula <[email protected]>
Quoted 33 lines
--- drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)drivers/gpu/drm/i915/intel_ddi.c +1
-1@@ -58,7 +58,7 @@ static const u32 hsw_ddi_translations_fdi[] = { 0x00FFFFFF, 0x00040006 /* HDMI parameters */ }; -static enum port intel_ddi_get_encoder_port (struct intel_encoder *intel_encoder) +enum port intel_ddi_get_encoder_port (struct intel_encoder *intel_encoder) {struct drm_encoder *encoder = &intel_encoder->base;int type = intel_encoder->type;drivers/gpu/drm/i915/intel_drv.h +1
-1@@ -707,6 +707,7 @@ extern void intel_write_eld(struct drm_encoder *encoder,extern void intel_prepare_ddi (struct drm_device *dev);extern void hsw_fdi_link_train (struct drm_crtc *crtc);extern void intel_ddi_init (struct drm_device *dev,enum port port); +extern enum port intel_ddi_get_encoder_port (struct intel_encoder *intel_encoder);/* For use by IVB LP watermark workaround in intel_sprite.c */ extern void intel_update_watermarks (struct drm_device *dev); --1.7.9.5
Signature · 1 line
Paulo Zanoni
PATCH 2/6 drm/i915: add plumbing for SWSCI
In reply to Jani NikulaSWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and filters out any calls that shouldn't happen. This way the callers don't need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set PCI_SWSCI bit 0 to trigger interrupt (Mengdong Lin)
v4: remove an extra #define (Jesse)
--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_opregion.c | 121 ++++++++++++++++++++++++++++++++- 2 files changed, 121 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_drv.h +1 -0
@@ -225,6 +225,7 @@ struct intel_opregion {struct opregion_header __iomem *header;struct opregion_acpi __iomem *acpi;struct opregion_swsci __iomem *swsci; +u32 swsci_requested_callbacks;struct opregion_asle __iomem *asle;void __iomem *vbt;u32 __iomem *lid_state;
drivers/gpu/drm/i915/intel_opregion.c +120 -1
140 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH 1/1 drm/i915: add plumbing for SWSCI
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and filters out any calls that shouldn't happen. This way the callers don't need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set PCI_SWSCI bit 0 to trigger interrupt (Mengdong Lin)
v4: remove an extra #define (Jesse)
v5: spec says s/w is responsible for clearing PCI_SWSCI bit 0 too
--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_opregion.c | 133 ++++++++++++++++++++++++++++++++- 2 files changed, 131 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/i915_drv.h +1 -0
@@ -225,6 +225,7 @@ struct intel_opregion {struct opregion_header __iomem *header;struct opregion_acpi __iomem *acpi;struct opregion_swsci __iomem *swsci; +u32 swsci_requested_callbacks;struct opregion_asle __iomem *asle;void __iomem *vbt;u32 __iomem *lid_state;
drivers/gpu/drm/i915/intel_opregion.c +130 -3
158 lines not on this page · raw message
Signature · 1 line
1.7.10.4
Re: [PATCH] drm/i915: add plumbing for SWSCI
Hi
2013/8/28 Jani Nikula <[email protected]>:
Quoted 51 lines
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and filters out any calls that shouldn't happen. This way the callers don't need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set
PCI_SWSCIbit 0 to trigger interrupt (Mengdong Lin)v4: remove an extra #define (Jesse)
v5: spec says s/w is responsible for clearing
PCI_SWSCIbit 0 tooSigned-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_opregion.c | 133 ++++++++++++++++++++++++++++++++- 2 files changed, 131 insertions(+), 3 deletions(-)drivers/gpu/drm/i915/i915_drv.h +1
-0@@ -225,6 +225,7 @@ struct intel_opregion {struct opregion_header __iomem *header;struct opregion_acpi __iomem *acpi;struct opregion_swsci __iomem *swsci; +u32 swsci_requested_callbacks;struct opregion_asle __iomem *asle;void __iomem *vbt;u32 __iomem *lid_state;drivers/gpu/drm/i915/intel_opregion.c +5
-2@@ -36,8 +36,11 @@#include "i915_drv.h" #include "intel_drv.h" -#define PCI_ASLE 0xe4 -#define PCI_ASLS 0xfc +#define PCI_ASLE 0xe4 +#define PCI_ASLS 0xfc +#define PCI_SWSCI 0xe8 +#define PCI_SWSCI_SCISEL (1 << 15) +#define PCI_SWSCI_GSSCIE (1 << 0)#define OPREGION_HEADER_OFFSET 0#define OPREGION_ACPI_OFFSET 0x100
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 162
Quoted 9 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0@@ -151,6 +154,48 @@ struct opregion_asle {#define ASLE_CBLV_VALID (1<<31) +/* Software System Control Interrupt (SWSCI) */ +#define SWSCI_SCIC_INDICATOR (1 << 0) +#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1 +#define SWSCI_SCIC_MAIN_FUNCTION_MASK (0xf << 1) +#define SWSCI_SCIC_SUB_FUNCTION_SHIFT 8 +#define SWSCI_SCIC_SUB_FUNCTION_MASK (0x7f << 8)
Shouldn't this be (0xff << 8) since it's bits 15:8 ?
Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+#define SWSCI_SCIC_EXIT_STATUS_SHIFT 5 +#define SWSCI_SCIC_EXIT_STATUS_MASK (7 << 5) +#define SWSCI_SCIC_EXIT_STATUS_SUCCESS 1 + +#define SWSCI_FUNCTION_CODE (main, sub) \
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 177
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+ ((main) <<SWSCI_SCIC_MAIN_FUNCTION_SHIFT | \ + (sub) <<SWSCI_SCIC_SUB_FUNCTION_SHIFT ) + +/* SWSCI: Get BIOS Data (GBDA) */ +#define SWSCI_GBDA 4 +#define SWSCI_GBDA_SUPPORTED_CALLS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 0) +#define SWSCI_GBDA_REQUESTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 1) +#define SWSCI_GBDA_BOOT_DISPLAY_PREF SWSCI_FUNCTION_CODE(SWSCI_GBDA, 4) +#define SWSCI_GBDA_PANEL_DETAILS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 5) +#define SWSCI_GBDA_TV_STANDARD SWSCI_FUNCTION_CODE(SWSCI_GBDA, 6)
The newer spec says "reserved" here. But let's leave your definition until they assign it again to something else :) (same thing for the other TV bit below)
Quoted 27 lines
drivers/gpu/drm/i915/intel_opregion.c +21
-0+#define SWSCI_GBDA_INTERNAL_GRAPHICS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 7) +#define SWSCI_GBDA_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_GBDA, 10) + +/* SWSCI: System BIOS Callbacks (SBCB) */ +#define SWSCI_SBCB 6 +#define SWSCI_SBCB_SUPPORTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 0) +#define SWSCI_SBCB_INIT_COMPLETION SWSCI_FUNCTION_CODE(SWSCI_SBCB, 1) +#define SWSCI_SBCB_PRE_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 3) +#define SWSCI_SBCB_POST_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 4) +#define SWSCI_SBCB_DISPLAY_SWITCH SWSCI_FUNCTION_CODE(SWSCI_SBCB, 5) +#define SWSCI_SBCB_SET_TV_FORMAT SWSCI_FUNCTION_CODE(SWSCI_SBCB, 6) +#define SWSCI_SBCB_ADAPTER_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 7) +#define SWSCI_SBCB_DISPLAY_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 8) +#define SWSCI_SBCB_SET_BOOT_DISPLAY SWSCI_FUNCTION_CODE(SWSCI_SBCB, 9) +#define SWSCI_SBCB_SET_INTERNAL_GFX SWSCI_FUNCTION_CODE(SWSCI_SBCB, 11) +#define SWSCI_SBCB_POST_HIRES_TO_DOS_FS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 16) +#define SWSCI_SBCB_SUSPEND_RESUME SWSCI_FUNCTION_CODE(SWSCI_SBCB, 17) +#define SWSCI_SBCB_SET_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 18) +#define SWSCI_SBCB_POST_VBE_PM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 19) +#define SWSCI_SBCB_ENABLE_DISABLE_AUDIO SWSCI_FUNCTION_CODE(SWSCI_SBCB, 21) +#define ACPI_OTHER_OUTPUT (0<<8)#define ACPI_VGA_OUTPUT (1<<8)#define ACPI_TV_OUTPUT (2<<8)@@ -158,6 +203,84 @@ struct opregion_asle {#define ACPI_LVDS_OUTPUT (4<<8)
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 214
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +9
-0#ifdef CONFIG_ACPI +static int swsci (struct drm_device *dev,u32 function,u32 parm,u32 *parm_out) +{ +struct drm_i915_private *dev_priv = dev->dev_private; +struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci; +u32 main_function, sub_function, scic; +u16 pci_swsci; + +if (!swsci) +return 0 ;
You also use "return 0" for success below. I'd return -ESOMETHING here. Perhaps also print an error message.
Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+ + main_function = (function &SWSCI_SCIC_MAIN_FUNCTION_MASK ) >> +SWSCI_SCIC_MAIN_FUNCTION_SHIFT ; + sub_function = (function &SWSCI_SCIC_SUB_FUNCTION_MASK ) >> +SWSCI_SCIC_SUB_FUNCTION_SHIFT ;
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 229
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+ +if (main_function ==SWSCI_SBCB && sub_function !=0 ) { +/* +* SBCB sub-function codes correspond to the bits in requested +* callbacks, except for bit 0 which is reserved. The driver +* must not call interfaces that are not specifically requested +* by the bios. +*/ +if ((dev_priv->opregion.swsci_requested_callbacks & + (1 << sub_function)) ==0 )
I think you have to do (1 << sub_funcition -1) to make it correct.
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 230
Quoted 1 line
drivers/gpu/drm/i915/intel_opregion.c +1
-0+return 0 ;
I'd return -ESOMETHINGELSE here too, possibly printing an error message.
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 233
Quoted 3 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-0+ } + +/* XXX: The spec tells us to do this, but we are the only user... */
I'd remove the "XXX: " substring from the comment. The spec suggests only graphics uses this specific interface, but it doesn't say that other events happening on the system won't cause this bit to be flipped. I don't know... the code seems correct, so the "XXX" code may be misleading.
The sad thing is that there's also no guarantees that someone won't start using the interface just after you read this bit and before writing it to 1... We may need dev_priv->swsci_lock depending on how we use this function (I haven't checked the next patches yet).
Quoted 16 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+ scic =ioread32 (&swsci->scic); +if (scic &SWSCI_SCIC_INDICATOR ) { +DRM_DEBUG_DRIVER ("SWSCI request already in progress\n" ); +return -EBUSY ; + } + + scic = function |SWSCI_SCIC_INDICATOR ; + +iowrite32 (parm, &swsci->parm); +iowrite32 (scic, &swsci->scic); +From what I understood of the spec, from the line below...
drivers/gpu/drm/i915/intel_opregion.c +1
-0+/* Ensure SCI event is selected and event trigger is cleared. */
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 255
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+pci_read_config_word (dev->pdev,PCI_SWSCI , &pci_swsci); +if (!(pci_swsci &PCI_SWSCI_SCISEL ) || (pci_swsci &PCI_SWSCI_GSSCIE )) { + pci_swsci |=PCI_SWSCI_SCISEL ; + pci_swsci &= ~PCI_SWSCI_GSSCIE ; +pci_write_config_word (dev->pdev,PCI_SWSCI , pci_swsci); + } + +/* Use event trigger to tell bios to check the mail. */ + pci_swsci |=PCI_SWSCI_GSSCIE ; +pci_write_config_word (dev->pdev,PCI_SWSCI , pci_swsci);
... to the line above, we don't need this code. My understanding is that the BIOS will do all these things automagically for us, so if we write these regs we may even be racing with it, especially since we already wrote swsci->scic. Do we really need this code?
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 260
Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+ +/* +* Poll for the result. The spec says nothing about timing out; add an +* arbitrary timeout to not hang if the bios fails. +*/
The spec does mention a timeout, check the description of DSLP: Driver Sleep Timeout.
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 273
Quoted 13 lines
drivers/gpu/drm/i915/intel_opregion.c +13
-0+#define C (((scic = ioread32(&swsci->scic)) & SWSCI_SCIC_INDICATOR) == 0) +if (wait_for (C ,500 )) { +DRM_DEBUG_DRIVER ("SWSCI request timed out\n" ); +return -ETIMEDOUT ; + } + + scic = (scic &SWSCI_SCIC_EXIT_STATUS_MASK ) >> +SWSCI_SCIC_EXIT_STATUS_SHIFT ; + +/* Note: scic == 0 is an error! */ +if (scic !=SWSCI_SCIC_EXIT_STATUS_SUCCESS ) { +DRM_DEBUG_DRIVER ("SWSCI request error %u\n" , scic); +return -EINVAL ;/* XXX */
Why XXX above? To me, a XXX means there's something on the code that must be fixed.
Quoted 14 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+ } + +if (parm_out) + *parm_out =ioread32 (&swsci->parm); + +return 0 ; + +#undef C +} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private;
drivers/gpu/drm/i915/intel_opregion.c int intel_opregion_setup(struct drm_device *dev) · line 617
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-1@@ -488,8 +611,12 @@ int intel_opregion_setup(struct drm_device *dev) }if (mboxes &MBOX_SWSCI ) { -DRM_DEBUG_DRIVER ("SWSCI supported\n" ); opregion->swsci = base +OPREGION_SWSCI_OFFSET ; + +swsci (dev,SWSCI_GBDA_REQUESTED_CALLBACKS ,0 , + &opregion->swsci_requested_callbacks);
No error checking?
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c +2
-1+DRM_DEBUG_DRIVER ("SWSCI supported, requested callbacks %08x\n" , + opregion->swsci_requested_callbacks); }if (mboxes &MBOX_ASLE ) {DRM_DEBUG_DRIVER ("ASLE supported\n" ); --1.7.10.4
Signature · 1 line
Paulo Zanoni
Re: [PATCH] drm/i915: add plumbing for SWSCI
2013/8/29 Paulo Zanoni <[email protected]>:
Quoted 247 lines
Hi
2013/8/28 Jani Nikula <[email protected]>:
Quoted 51 lines
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and filters out any calls that shouldn't happen. This way the callers don't need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set
PCI_SWSCIbit 0 to trigger interrupt (Mengdong Lin)v4: remove an extra #define (Jesse)
v5: spec says s/w is responsible for clearing
PCI_SWSCIbit 0 tooSigned-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_opregion.c | 133 ++++++++++++++++++++++++++++++++- 2 files changed, 131 insertions(+), 3 deletions(-)drivers/gpu/drm/i915/i915_drv.h +1
-0@@ -225,6 +225,7 @@ struct intel_opregion {struct opregion_header __iomem *header;struct opregion_acpi __iomem *acpi;struct opregion_swsci __iomem *swsci; +u32 swsci_requested_callbacks;struct opregion_asle __iomem *asle;void __iomem *vbt;u32 __iomem *lid_state;drivers/gpu/drm/i915/intel_opregion.c +5
-2@@ -36,8 +36,11 @@#include "i915_drv.h" #include "intel_drv.h" -#define PCI_ASLE 0xe4 -#define PCI_ASLS 0xfc +#define PCI_ASLE 0xe4 +#define PCI_ASLS 0xfc +#define PCI_SWSCI 0xe8 +#define PCI_SWSCI_SCISEL (1 << 15) +#define PCI_SWSCI_GSSCIE (1 << 0)#define OPREGION_HEADER_OFFSET 0#define OPREGION_ACPI_OFFSET 0x100drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 162
Quoted 9 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0@@ -151,6 +154,48 @@ struct opregion_asle {#define ASLE_CBLV_VALID (1<<31) +/* Software System Control Interrupt (SWSCI) */ +#define SWSCI_SCIC_INDICATOR (1 << 0) +#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1 +#define SWSCI_SCIC_MAIN_FUNCTION_MASK (0xf << 1) +#define SWSCI_SCIC_SUB_FUNCTION_SHIFT 8 +#define SWSCI_SCIC_SUB_FUNCTION_MASK (0x7f << 8)Shouldn't this be (
0xff<< 8) since it's bits 15:8 ?Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+#define SWSCI_SCIC_EXIT_STATUS_SHIFT 5 +#define SWSCI_SCIC_EXIT_STATUS_MASK (7 << 5) +#define SWSCI_SCIC_EXIT_STATUS_SUCCESS 1 + +#define SWSCI_FUNCTION_CODE (main, sub) \drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 177
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+ ((main) <<SWSCI_SCIC_MAIN_FUNCTION_SHIFT | \ + (sub) <<SWSCI_SCIC_SUB_FUNCTION_SHIFT ) + +/* SWSCI: Get BIOS Data (GBDA) */ +#define SWSCI_GBDA 4 +#define SWSCI_GBDA_SUPPORTED_CALLS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 0) +#define SWSCI_GBDA_REQUESTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 1) +#define SWSCI_GBDA_BOOT_DISPLAY_PREF SWSCI_FUNCTION_CODE(SWSCI_GBDA, 4) +#define SWSCI_GBDA_PANEL_DETAILS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 5) +#define SWSCI_GBDA_TV_STANDARD SWSCI_FUNCTION_CODE(SWSCI_GBDA, 6)The newer spec says "reserved" here. But let's leave your definition until they assign it again to something else :) (same thing for the other TV bit below)
Quoted 27 lines
drivers/gpu/drm/i915/intel_opregion.c +21
-0+#define SWSCI_GBDA_INTERNAL_GRAPHICS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 7) +#define SWSCI_GBDA_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_GBDA, 10) + +/* SWSCI: System BIOS Callbacks (SBCB) */ +#define SWSCI_SBCB 6 +#define SWSCI_SBCB_SUPPORTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 0) +#define SWSCI_SBCB_INIT_COMPLETION SWSCI_FUNCTION_CODE(SWSCI_SBCB, 1) +#define SWSCI_SBCB_PRE_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 3) +#define SWSCI_SBCB_POST_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 4) +#define SWSCI_SBCB_DISPLAY_SWITCH SWSCI_FUNCTION_CODE(SWSCI_SBCB, 5) +#define SWSCI_SBCB_SET_TV_FORMAT SWSCI_FUNCTION_CODE(SWSCI_SBCB, 6) +#define SWSCI_SBCB_ADAPTER_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 7) +#define SWSCI_SBCB_DISPLAY_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 8) +#define SWSCI_SBCB_SET_BOOT_DISPLAY SWSCI_FUNCTION_CODE(SWSCI_SBCB, 9) +#define SWSCI_SBCB_SET_INTERNAL_GFX SWSCI_FUNCTION_CODE(SWSCI_SBCB, 11) +#define SWSCI_SBCB_POST_HIRES_TO_DOS_FS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 16) +#define SWSCI_SBCB_SUSPEND_RESUME SWSCI_FUNCTION_CODE(SWSCI_SBCB, 17) +#define SWSCI_SBCB_SET_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 18) +#define SWSCI_SBCB_POST_VBE_PM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 19) +#define SWSCI_SBCB_ENABLE_DISABLE_AUDIO SWSCI_FUNCTION_CODE(SWSCI_SBCB, 21) +#define ACPI_OTHER_OUTPUT (0<<8)#define ACPI_VGA_OUTPUT (1<<8)#define ACPI_TV_OUTPUT (2<<8)@@ -158,6 +203,84 @@ struct opregion_asle {#define ACPI_LVDS_OUTPUT (4<<8)drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 214
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +9
-0#ifdef CONFIG_ACPI +static int swsci (struct drm_device *dev,u32 function,u32 parm,u32 *parm_out) +{ +struct drm_i915_private *dev_priv = dev->dev_private; +struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci; +u32 main_function, sub_function, scic; +u16 pci_swsci; + +if (!swsci) +return 0 ;You also use "return 0" for success below. I'd return
-ESOMETHINGhere. Perhaps also print an error message.Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+ + main_function = (function &SWSCI_SCIC_MAIN_FUNCTION_MASK ) >> +SWSCI_SCIC_MAIN_FUNCTION_SHIFT ; + sub_function = (function &SWSCI_SCIC_SUB_FUNCTION_MASK ) >> +SWSCI_SCIC_SUB_FUNCTION_SHIFT ;drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 229
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+ +if (main_function ==SWSCI_SBCB && sub_function !=0 ) { +/* +* SBCB sub-function codes correspond to the bits in requested +* callbacks, except for bit 0 which is reserved. The driver +* must not call interfaces that are not specifically requested +* by the bios. +*/ +if ((dev_priv->opregion.swsci_requested_callbacks & + (1 << sub_function)) ==0 )I think you have to do (1 <<
sub_funcition-1) to make it correct.drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 230
Quoted 1 line
drivers/gpu/drm/i915/intel_opregion.c +1
-0+return 0 ;I'd return
-ESOMETHINGELSEhere too, possibly printing an error message.drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 233
Quoted 3 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-0+ } + +/* XXX: The spec tells us to do this, but we are the only user... */ I'd remove the "XXX: " substring from the comment. The spec suggests only graphics uses this specific interface, but it doesn't say that other events happening on the system won't cause this bit to be flipped. I don't know... the code seems correct, so the "XXX" code may be misleading.
The sad thing is that there's also no guarantees that someone won't start using the interface just after you read this bit and before writing it to 1... We may need
dev_priv->swsci_lockdepending on how we use this function (I haven't checked the next patches yet).drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 244
Quoted 11 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+ scic =ioread32 (&swsci->scic); +if (scic &SWSCI_SCIC_INDICATOR ) { +DRM_DEBUG_DRIVER ("SWSCI request already in progress\n" ); +return -EBUSY ; + } + + scic = function |SWSCI_SCIC_INDICATOR ; + +iowrite32 (parm, &swsci->parm); +iowrite32 (scic, &swsci->scic); +From what I understood of the spec, from the line below...
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 255
Quoted 11 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+/* Ensure SCI event is selected and event trigger is cleared. */ +pci_read_config_word (dev->pdev,PCI_SWSCI , &pci_swsci); +if (!(pci_swsci &PCI_SWSCI_SCISEL ) || (pci_swsci &PCI_SWSCI_GSSCIE )) { + pci_swsci |=PCI_SWSCI_SCISEL ; + pci_swsci &= ~PCI_SWSCI_GSSCIE ; +pci_write_config_word (dev->pdev,PCI_SWSCI , pci_swsci); + } + +/* Use event trigger to tell bios to check the mail. */ + pci_swsci |=PCI_SWSCI_GSSCIE ; +pci_write_config_word (dev->pdev,PCI_SWSCI , pci_swsci);... to the line above, we don't need this code. My understanding is that the BIOS will do all these things automagically for us, so if we write these regs we may even be racing with it, especially since we already wrote
swsci->scic. Do we really need this code?drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 260
Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+ +/* +* Poll for the result. The spec says nothing about timing out; add an +* arbitrary timeout to not hang if the bios fails. +*/ The spec does mention a timeout, check the description of DSLP: Driver Sleep Timeout.
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 273
Quoted 13 lines
drivers/gpu/drm/i915/intel_opregion.c +13
-0+#define C (((scic = ioread32(&swsci->scic)) & SWSCI_SCIC_INDICATOR) == 0) +if (wait_for (C ,500 )) { +DRM_DEBUG_DRIVER ("SWSCI request timed out\n" ); +return -ETIMEDOUT ; + } + + scic = (scic &SWSCI_SCIC_EXIT_STATUS_MASK ) >> +SWSCI_SCIC_EXIT_STATUS_SHIFT ; + +/* Note: scic == 0 is an error! */ +if (scic !=SWSCI_SCIC_EXIT_STATUS_SUCCESS ) { +DRM_DEBUG_DRIVER ("SWSCI request error %u\n" , scic); +return -EINVAL ;/* XXX */ Why XXX above? To me, a XXX means there's something on the code that must be fixed.
Quoted 16 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+ } + +if (parm_out) + *parm_out =ioread32 (&swsci->parm); + +return 0 ; + +#undef C +} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private;@@ -488,8 +611,12 @@ int intel_opregion_setup(struct drm_device *dev) }
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c int intel_opregion_setup(struct drm_device *dev) · line 617
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-1if (mboxes &MBOX_SWSCI ) { -DRM_DEBUG_DRIVER ("SWSCI supported\n" ); opregion->swsci = base +OPREGION_SWSCI_OFFSET ; + +swsci (dev,SWSCI_GBDA_REQUESTED_CALLBACKS ,0 , + &opregion->swsci_requested_callbacks);No error checking?
Also, the "swsci" declaration is under "#ifdef CONFIG_ACPI", but not this call.
Quoted 15 lines
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +2
-1+DRM_DEBUG_DRIVER ("SWSCI supported, requested callbacks %08x\n" , + opregion->swsci_requested_callbacks); }if (mboxes &MBOX_ASLE ) {DRM_DEBUG_DRIVER ("ASLE supported\n" ); --1.7.10.4
--
Paulo Zanoni
Signature · 1 line
Paulo Zanoni
Re: [PATCH] drm/i915: add plumbing for SWSCI
In reply to Paulo ZanoniQuoted 57 lines · Paulo Zanoni
Hi
2013/8/28 Jani Nikula <[email protected]>:
Quoted 54 lines
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and filters out any calls that shouldn't happen. This way the callers don't need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set
PCI_SWSCIbit 0 to trigger interrupt (Mengdong Lin)v4: remove an extra #define (Jesse)
v5: spec says s/w is responsible for clearing
PCI_SWSCIbit 0 tooSigned-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_opregion.c | 133 ++++++++++++++++++++++++++++++++- 2 files changed, 131 insertions(+), 3 deletions(-)drivers/gpu/drm/i915/i915_drv.h +1
-0@@ -225,6 +225,7 @@ struct intel_opregion {struct opregion_header __iomem *header;struct opregion_acpi __iomem *acpi;struct opregion_swsci __iomem *swsci; +u32 swsci_requested_callbacks;struct opregion_asle __iomem *asle;void __iomem *vbt;u32 __iomem *lid_state;drivers/gpu/drm/i915/intel_opregion.c +5
-2@@ -36,8 +36,11 @@#include "i915_drv.h" #include "intel_drv.h" -#define PCI_ASLE 0xe4 -#define PCI_ASLS 0xfc +#define PCI_ASLE 0xe4 +#define PCI_ASLS 0xfc +#define PCI_SWSCI 0xe8 +#define PCI_SWSCI_SCISEL (1 << 15) +#define PCI_SWSCI_GSSCIE (1 << 0)#define OPREGION_HEADER_OFFSET 0#define OPREGION_ACPI_OFFSET 0x100@@ -151,6 +154,48 @@ struct opregion_asle {#define ASLE_CBLV_VALID (1<<31)
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 162
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+/* Software System Control Interrupt (SWSCI) */ +#define SWSCI_SCIC_INDICATOR (1 << 0) +#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1 +#define SWSCI_SCIC_MAIN_FUNCTION_MASK (0xf << 1) +#define SWSCI_SCIC_SUB_FUNCTION_SHIFT 8 +#define SWSCI_SCIC_SUB_FUNCTION_MASK (0x7f << 8)Shouldn't this be (
0xff<< 8) since it's bits 15:8 ?
In my spec, section 4.1.1: "Function codes are broken down into two parts the main function code (SCIC bits [4:1]) and the sub-function code (SCIC bits [14:8])."
Quoted 11 lines
Quoted 11 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+#define SWSCI_SCIC_EXIT_STATUS_SHIFT 5 +#define SWSCI_SCIC_EXIT_STATUS_MASK (7 << 5) +#define SWSCI_SCIC_EXIT_STATUS_SUCCESS 1 + +#define SWSCI_FUNCTION_CODE (main, sub) \ + ((main) << SWSCI_SCIC_MAIN_FUNCTION_SHIFT | \ + (sub) << SWSCI_SCIC_SUB_FUNCTION_SHIFT) + +/* SWSCI: Get BIOS Data (GBDA) */ +#define SWSCI_GBDA 4 +#define SWSCI_GBDA_SUPPORTED_CALLS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 0)
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 177
Quoted 4 lines
drivers/gpu/drm/i915/intel_opregion.c +4
-0+#define SWSCI_GBDA_REQUESTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 1) +#define SWSCI_GBDA_BOOT_DISPLAY_PREF SWSCI_FUNCTION_CODE(SWSCI_GBDA, 4) +#define SWSCI_GBDA_PANEL_DETAILS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 5) +#define SWSCI_GBDA_TV_STANDARD SWSCI_FUNCTION_CODE(SWSCI_GBDA, 6)The newer spec says "reserved" here. But let's leave your definition until they assign it again to something else :) (same thing for the other TV bit below)
Okay. :)
Quoted 27 lines
Quoted 27 lines
drivers/gpu/drm/i915/intel_opregion.c +21
-0+#define SWSCI_GBDA_INTERNAL_GRAPHICS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 7) +#define SWSCI_GBDA_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_GBDA, 10) + +/* SWSCI: System BIOS Callbacks (SBCB) */ +#define SWSCI_SBCB 6 +#define SWSCI_SBCB_SUPPORTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 0) +#define SWSCI_SBCB_INIT_COMPLETION SWSCI_FUNCTION_CODE(SWSCI_SBCB, 1) +#define SWSCI_SBCB_PRE_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 3) +#define SWSCI_SBCB_POST_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 4) +#define SWSCI_SBCB_DISPLAY_SWITCH SWSCI_FUNCTION_CODE(SWSCI_SBCB, 5) +#define SWSCI_SBCB_SET_TV_FORMAT SWSCI_FUNCTION_CODE(SWSCI_SBCB, 6) +#define SWSCI_SBCB_ADAPTER_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 7) +#define SWSCI_SBCB_DISPLAY_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 8) +#define SWSCI_SBCB_SET_BOOT_DISPLAY SWSCI_FUNCTION_CODE(SWSCI_SBCB, 9) +#define SWSCI_SBCB_SET_INTERNAL_GFX SWSCI_FUNCTION_CODE(SWSCI_SBCB, 11) +#define SWSCI_SBCB_POST_HIRES_TO_DOS_FS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 16) +#define SWSCI_SBCB_SUSPEND_RESUME SWSCI_FUNCTION_CODE(SWSCI_SBCB, 17) +#define SWSCI_SBCB_SET_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 18) +#define SWSCI_SBCB_POST_VBE_PM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 19) +#define SWSCI_SBCB_ENABLE_DISABLE_AUDIO SWSCI_FUNCTION_CODE(SWSCI_SBCB, 21) +#define ACPI_OTHER_OUTPUT (0<<8)#define ACPI_VGA_OUTPUT (1<<8)#define ACPI_TV_OUTPUT (2<<8)@@ -158,6 +203,84 @@ struct opregion_asle {#define ACPI_LVDS_OUTPUT (4<<8)
Quoted 13 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 214
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +9
-0#ifdef CONFIG_ACPI +static int swsci (struct drm_device *dev,u32 function,u32 parm,u32 *parm_out) +{ +struct drm_i915_private *dev_priv = dev->dev_private; +struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci; +u32 main_function, sub_function, scic; +u16 pci_swsci; + +if (!swsci) +return 0 ;You also use "return 0" for success below. I'd return
-ESOMETHINGhere. Perhaps also print an error message.
My reasoning was, if the platform doesn't support SWSCI (this one here), or does not request a specific sub-function (the one below), we just carry on. I can add a -ESOMETHING if you like, but I think an error message would pollute dmesg too much. Or else we'd have to burden the call sites with checks if we can call the functions.
Quoted 9 lines
Quoted 9 lines
drivers/gpu/drm/i915/intel_opregion.c +9
-0+ + main_function = (function &SWSCI_SCIC_MAIN_FUNCTION_MASK ) >> +SWSCI_SCIC_MAIN_FUNCTION_SHIFT ; + sub_function = (function &SWSCI_SCIC_SUB_FUNCTION_MASK ) >> +SWSCI_SCIC_SUB_FUNCTION_SHIFT ; + +if (main_function ==SWSCI_SBCB && sub_function !=0 ) { +/* +* SBCB sub-function codes correspond to the bits in requested
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 229
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+* callbacks, except for bit 0 which is reserved. The driver +* must not call interfaces that are not specifically requested +* by the bios. +*/ +if ((dev_priv->opregion.swsci_requested_callbacks & + (1 << sub_function)) ==0 )I think you have to do (1 <<
sub_funcition-1) to make it correct.
I think you're off by one, please double check.
Quoted 4 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 230
Quoted 1 line
drivers/gpu/drm/i915/intel_opregion.c +1
-0+return 0 ;I'd return
-ESOMETHINGELSEhere too, possibly printing an error message.
See above.
Quoted 9 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 233
Quoted 3 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-0+ } + +/* XXX: The spec tells us to do this, but we are the only user... */ I'd remove the "XXX: " substring from the comment. The spec suggests only graphics uses this specific interface, but it doesn't say that other events happening on the system won't cause this bit to be flipped. I don't know... the code seems correct, so the "XXX" code may be misleading.
I'll drop it.
Quoted 4 lines
The sad thing is that there's also no guarantees that someone won't start using the interface just after you read this bit and before writing it to 1... We may need
dev_priv->swsci_lockdepending on how we use this function (I haven't checked the next patches yet).
I think I thought we'd be covered by struct_mutex here, but perhaps that was before the adapter notification... how's the pc8 call paths?
Quoted 27 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 244
Quoted 11 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+ scic =ioread32 (&swsci->scic); +if (scic &SWSCI_SCIC_INDICATOR ) { +DRM_DEBUG_DRIVER ("SWSCI request already in progress\n" ); +return -EBUSY ; + } + + scic = function |SWSCI_SCIC_INDICATOR ; + +iowrite32 (parm, &swsci->parm); +iowrite32 (scic, &swsci->scic); +From what I understood of the spec, from the line below...
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 255
Quoted 11 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+/* Ensure SCI event is selected and event trigger is cleared. */ +pci_read_config_word (dev->pdev,PCI_SWSCI , &pci_swsci); +if (!(pci_swsci &PCI_SWSCI_SCISEL ) || (pci_swsci &PCI_SWSCI_GSSCIE )) { + pci_swsci |=PCI_SWSCI_SCISEL ; + pci_swsci &= ~PCI_SWSCI_GSSCIE ; +pci_write_config_word (dev->pdev,PCI_SWSCI , pci_swsci); + } + +/* Use event trigger to tell bios to check the mail. */ + pci_swsci |=PCI_SWSCI_GSSCIE ; +pci_write_config_word (dev->pdev,PCI_SWSCI , pci_swsci);
Quoted 4 lines
... to the line above, we don't need this code. My understanding is that the BIOS will do all these things automagically for us, so if we write these regs we may even be racing with it, especially since we already wrote
swsci->scic. Do we really need this code?
We need it. It gives me some consolation that I made the same interpretation as you did, before Mengdong Lin corrected me... The opregion spec is really unclear about this, and it's easy to confuse between the SCIC register and the PCI SWSCI register. Have a look at SWSCI in the bspec PCI section. Only that triggers the event.
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 260
Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+ +/* +* Poll for the result. The spec says nothing about timing out; add an +* arbitrary timeout to not hang if the bios fails. +*/ The spec does mention a timeout, check the description of DSLP: Driver Sleep Timeout.
Ah yes, thanks. Any idea what the unit for DSLP might be? Not in my spec...
Quoted 8 lines
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c +8
-0+#define C (((scic = ioread32(&swsci->scic)) & SWSCI_SCIC_INDICATOR) == 0) +if (wait_for (C ,500 )) { +DRM_DEBUG_DRIVER ("SWSCI request timed out\n" ); +return -ETIMEDOUT ; + } + + scic = (scic &SWSCI_SCIC_EXIT_STATUS_MASK ) >> +SWSCI_SCIC_EXIT_STATUS_SHIFT ;
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 273
Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+ +/* Note: scic == 0 is an error! */ +if (scic !=SWSCI_SCIC_EXIT_STATUS_SUCCESS ) { +DRM_DEBUG_DRIVER ("SWSCI request error %u\n" , scic); +return -EINVAL ;/* XXX */ Why XXX above? To me, a XXX means there's something on the code that must be fixed.
s/XXX/check if there's an appropriate error code we could use/ :)
Quoted 16 lines
Quoted 16 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+ } + +if (parm_out) + *parm_out =ioread32 (&swsci->parm); + +return 0 ; + +#undef C +} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private;@@ -488,8 +611,12 @@ int intel_opregion_setup(struct drm_device *dev) }
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c int intel_opregion_setup(struct drm_device *dev) · line 617
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-1if (mboxes &MBOX_SWSCI ) { -DRM_DEBUG_DRIVER ("SWSCI supported\n" ); opregion->swsci = base +OPREGION_SWSCI_OFFSET ; + +swsci (dev,SWSCI_GBDA_REQUESTED_CALLBACKS ,0 , + &opregion->swsci_requested_callbacks);No error checking?
Will fix.
Thanks for the review,
Jani.
Quoted 19 lines
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +2
-1+DRM_DEBUG_DRIVER ("SWSCI supported, requested callbacks %08x\n" , + opregion->swsci_requested_callbacks); }if (mboxes &MBOX_ASLE ) {DRM_DEBUG_DRIVER ("ASLE supported\n" ); --1.7.10.4
Signature · 5 lines
Paulo Zanoni _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH] drm/i915: add plumbing for SWSCI
2013/8/29 Jani Nikula <[email protected]>:
Quoted 67 lines · Paulo Zanoni
Quoted 57 lines
Hi
2013/8/28 Jani Nikula <[email protected]>:
Quoted 54 lines
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and filters out any calls that shouldn't happen. This way the callers don't need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set
PCI_SWSCIbit 0 to trigger interrupt (Mengdong Lin)v4: remove an extra #define (Jesse)
v5: spec says s/w is responsible for clearing
PCI_SWSCIbit 0 tooSigned-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_opregion.c | 133 ++++++++++++++++++++++++++++++++- 2 files changed, 131 insertions(+), 3 deletions(-)drivers/gpu/drm/i915/i915_drv.h +1
-0@@ -225,6 +225,7 @@ struct intel_opregion {struct opregion_header __iomem *header;struct opregion_acpi __iomem *acpi;struct opregion_swsci __iomem *swsci; +u32 swsci_requested_callbacks;struct opregion_asle __iomem *asle;void __iomem *vbt;u32 __iomem *lid_state;drivers/gpu/drm/i915/intel_opregion.c +5
-2@@ -36,8 +36,11 @@#include "i915_drv.h" #include "intel_drv.h" -#define PCI_ASLE 0xe4 -#define PCI_ASLS 0xfc +#define PCI_ASLE 0xe4 +#define PCI_ASLS 0xfc +#define PCI_SWSCI 0xe8 +#define PCI_SWSCI_SCISEL (1 << 15) +#define PCI_SWSCI_GSSCIE (1 << 0)#define OPREGION_HEADER_OFFSET 0#define OPREGION_ACPI_OFFSET 0x100@@ -151,6 +154,48 @@ struct opregion_asle {#define ASLE_CBLV_VALID (1<<31)Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 162
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+/* Software System Control Interrupt (SWSCI) */ +#define SWSCI_SCIC_INDICATOR (1 << 0) +#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1 +#define SWSCI_SCIC_MAIN_FUNCTION_MASK (0xf << 1) +#define SWSCI_SCIC_SUB_FUNCTION_SHIFT 8 +#define SWSCI_SCIC_SUB_FUNCTION_MASK (0x7f << 8)Shouldn't this be (
0xff<< 8) since it's bits 15:8 ?
Quoted 3 lines
In my spec, section 4.1.1: "Function codes are broken down into two parts the main function code (SCIC bits [4:1]) and the sub-function code (SCIC bits [14:8])."
In the same spec, section 3.3.1, table 3-35 says it's 15:8 :( We're both right and wrong...
Quoted 64 lines
Quoted 12 lines
Quoted 12 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+#define SWSCI_SCIC_EXIT_STATUS_SHIFT 5 +#define SWSCI_SCIC_EXIT_STATUS_MASK (7 << 5) +#define SWSCI_SCIC_EXIT_STATUS_SUCCESS 1 + +#define SWSCI_FUNCTION_CODE (main, sub) \ + ((main) << SWSCI_SCIC_MAIN_FUNCTION_SHIFT | \ + (sub) << SWSCI_SCIC_SUB_FUNCTION_SHIFT) + +/* SWSCI: Get BIOS Data (GBDA) */ +#define SWSCI_GBDA 4 +#define SWSCI_GBDA_SUPPORTED_CALLS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 0)Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 177
Quoted 4 lines
drivers/gpu/drm/i915/intel_opregion.c +4
-0+#define SWSCI_GBDA_REQUESTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 1) +#define SWSCI_GBDA_BOOT_DISPLAY_PREF SWSCI_FUNCTION_CODE(SWSCI_GBDA, 4) +#define SWSCI_GBDA_PANEL_DETAILS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 5) +#define SWSCI_GBDA_TV_STANDARD SWSCI_FUNCTION_CODE(SWSCI_GBDA, 6)The newer spec says "reserved" here. But let's leave your definition until they assign it again to something else :) (same thing for the other TV bit below)
Okay. :)
Quoted 27 lines
Quoted 27 lines
drivers/gpu/drm/i915/intel_opregion.c +21
-0+#define SWSCI_GBDA_INTERNAL_GRAPHICS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 7) +#define SWSCI_GBDA_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_GBDA, 10) + +/* SWSCI: System BIOS Callbacks (SBCB) */ +#define SWSCI_SBCB 6 +#define SWSCI_SBCB_SUPPORTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 0) +#define SWSCI_SBCB_INIT_COMPLETION SWSCI_FUNCTION_CODE(SWSCI_SBCB, 1) +#define SWSCI_SBCB_PRE_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 3) +#define SWSCI_SBCB_POST_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 4) +#define SWSCI_SBCB_DISPLAY_SWITCH SWSCI_FUNCTION_CODE(SWSCI_SBCB, 5) +#define SWSCI_SBCB_SET_TV_FORMAT SWSCI_FUNCTION_CODE(SWSCI_SBCB, 6) +#define SWSCI_SBCB_ADAPTER_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 7) +#define SWSCI_SBCB_DISPLAY_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 8) +#define SWSCI_SBCB_SET_BOOT_DISPLAY SWSCI_FUNCTION_CODE(SWSCI_SBCB, 9) +#define SWSCI_SBCB_SET_INTERNAL_GFX SWSCI_FUNCTION_CODE(SWSCI_SBCB, 11) +#define SWSCI_SBCB_POST_HIRES_TO_DOS_FS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 16) +#define SWSCI_SBCB_SUSPEND_RESUME SWSCI_FUNCTION_CODE(SWSCI_SBCB, 17) +#define SWSCI_SBCB_SET_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 18) +#define SWSCI_SBCB_POST_VBE_PM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 19) +#define SWSCI_SBCB_ENABLE_DISABLE_AUDIO SWSCI_FUNCTION_CODE(SWSCI_SBCB, 21) +#define ACPI_OTHER_OUTPUT (0<<8)#define ACPI_VGA_OUTPUT (1<<8)#define ACPI_TV_OUTPUT (2<<8)@@ -158,6 +203,84 @@ struct opregion_asle {#define ACPI_LVDS_OUTPUT (4<<8)Quoted 13 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 214
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +9
-0#ifdef CONFIG_ACPI +static int swsci (struct drm_device *dev,u32 function,u32 parm,u32 *parm_out) +{ +struct drm_i915_private *dev_priv = dev->dev_private; +struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci; +u32 main_function, sub_function, scic; +u16 pci_swsci; + +if (!swsci) +return 0 ;You also use "return 0" for success below. I'd return
-ESOMETHINGhere. Perhaps also print an error message.
Quoted 5 lines
My reasoning was, if the platform doesn't support SWSCI (this one here), or does not request a specific sub-function (the one below), we just carry on. I can add a
-ESOMETHINGif you like, but I think an error message would pollute dmesg too much. Or else we'd have to burden the call sites with checks if we can call the functions.
Makes sense.
Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +9
-0+ + main_function = (function &SWSCI_SCIC_MAIN_FUNCTION_MASK ) >> +SWSCI_SCIC_MAIN_FUNCTION_SHIFT ; + sub_function = (function &SWSCI_SCIC_SUB_FUNCTION_MASK ) >> +SWSCI_SCIC_SUB_FUNCTION_SHIFT ; + +if (main_function ==SWSCI_SBCB && sub_function !=0 ) { +/* +* SBCB sub-function codes correspond to the bits in requested Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 229
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+* callbacks, except for bit 0 which is reserved. The driver +* must not call interfaces that are not specifically requested +* by the bios. +*/ +if ((dev_priv->opregion.swsci_requested_callbacks & + (1 << sub_function)) ==0 )I think you have to do (1 <<
sub_funcition-1) to make it correct.
Quoted 1 line
I think you're off by one, please double check.
Ok, it seems you were using spec version 0.8 from December 2012, right? Mine is version 1.0 from June 2013. The sub-function codes are still the same, but the callbacks reply changed. Now I see some bits moved even 5 positions (e.g, enable/disable audio) while the ones I checked only moved 1 position. Trolls!!! Where's my sword?
Quoted 20 lines
Quoted 5 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 230
Quoted 2 lines
drivers/gpu/drm/i915/intel_opregion.c +1
-0+return 0 ;I'd return
-ESOMETHINGELSEhere too, possibly printing an error message.See above.
Quoted 9 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 233
Quoted 3 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-0+ } + +/* XXX: The spec tells us to do this, but we are the only user... */ I'd remove the "XXX: " substring from the comment. The spec suggests only graphics uses this specific interface, but it doesn't say that other events happening on the system won't cause this bit to be flipped. I don't know... the code seems correct, so the "XXX" code may be misleading.
I'll drop it.
Quoted 7 lines
Quoted 4 lines
The sad thing is that there's also no guarantees that someone won't start using the interface just after you read this bit and before writing it to 1... We may need
dev_priv->swsci_lockdepending on how we use this function (I haven't checked the next patches yet).I think I thought we'd be covered by
struct_mutexhere, but perhaps that was before the adapter notification... how's the pc8 call paths?
If we only call this while modesetting and entering/leaving PC8, we should be fine. But we never know what's going to be needed in the future. For now, we can leave as it is.
Quoted 33 lines
Quoted 28 lines
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 244
Quoted 12 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+ scic =ioread32 (&swsci->scic); +if (scic &SWSCI_SCIC_INDICATOR ) { +DRM_DEBUG_DRIVER ("SWSCI request already in progress\n" ); +return -EBUSY ; + } + + scic = function |SWSCI_SCIC_INDICATOR ; + +iowrite32 (parm, &swsci->parm); +iowrite32 (scic, &swsci->scic); +From what I understood of the spec, from the line below...
drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 255
Quoted 11 lines
drivers/gpu/drm/i915/intel_opregion.c +11
-0+/* Ensure SCI event is selected and event trigger is cleared. */ +pci_read_config_word (dev->pdev,PCI_SWSCI , &pci_swsci); +if (!(pci_swsci &PCI_SWSCI_SCISEL ) || (pci_swsci &PCI_SWSCI_GSSCIE )) { + pci_swsci |=PCI_SWSCI_SCISEL ; + pci_swsci &= ~PCI_SWSCI_GSSCIE ; +pci_write_config_word (dev->pdev,PCI_SWSCI , pci_swsci); + } + +/* Use event trigger to tell bios to check the mail. */ + pci_swsci |=PCI_SWSCI_GSSCIE ; +pci_write_config_word (dev->pdev,PCI_SWSCI , pci_swsci);Quoted 4 lines
... to the line above, we don't need this code. My understanding is that the BIOS will do all these things automagically for us, so if we write these regs we may even be racing with it, especially since we already wrote
swsci->scic. Do we really need this code?
Quoted 5 lines
We need it. It gives me some consolation that I made the same interpretation as you did, before Mengdong Lin corrected me... The opregion spec is really unclear about this, and it's easy to confuse between the SCIC register and the PCI SWSCI register. Have a look at SWSCI in the bspec PCI section. Only that triggers the event.
I'll take a look and do some experiments.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +5
-0+ +/* +* Poll for the result. The spec says nothing about timing out; add an +* arbitrary timeout to not hang if the bios fails. +*/
Quoted 5 lines
Quoted 2 lines
The spec does mention a timeout, check the description of DSLP: Driver Sleep Timeout.
Ah yes, thanks. Any idea what the unit for DSLP might be? Not in my spec...
On the 1.0 spec, the second paragraph of section 3.3.3 is just "Timeout Unit will be in milliseconds". I couldn't find anything in the 0.8 spec... Section 3.3.3 also says that if the timeout value is 0, we should consider 2ms.
Quoted 18 lines
Quoted 17 lines
Quoted 4 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-0+#define C (((scic = ioread32(&swsci->scic)) & SWSCI_SCIC_INDICATOR) == 0) +if (wait_for (C ,500 )) { +DRM_DEBUG_DRIVER ("SWSCI request timed out\n" );drivers/gpu/drm/i915/intel_opregion.c struct opregion_asle { · line 273
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+return -ETIMEDOUT ; + } + + scic = (scic &SWSCI_SCIC_EXIT_STATUS_MASK ) >> +SWSCI_SCIC_EXIT_STATUS_SHIFT ; + +/* Note: scic == 0 is an error! */ +if (scic !=SWSCI_SCIC_EXIT_STATUS_SUCCESS ) { +DRM_DEBUG_DRIVER ("SWSCI request error %u\n" , scic); +return -EINVAL ;/* XXX */ Why XXX above? To me, a XXX means there's something on the code that must be fixed.
Quoted 1 line
s/XXX/check if there's an appropriate error code we could use/ :)
Ok. I'll leave the decision to you :)
Quoted 50 lines
Quoted 17 lines
Quoted 17 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+ } + +if (parm_out) + *parm_out =ioread32 (&swsci->parm); + +return 0 ; + +#undef C +} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private;@@ -488,8 +611,12 @@ int intel_opregion_setup(struct drm_device *dev) }Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c int intel_opregion_setup(struct drm_device *dev) · line 617
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +3
-1if (mboxes &MBOX_SWSCI ) { -DRM_DEBUG_DRIVER ("SWSCI supported\n" ); opregion->swsci = base +OPREGION_SWSCI_OFFSET ; + +swsci (dev,SWSCI_GBDA_REQUESTED_CALLBACKS ,0 , + &opregion->swsci_requested_callbacks);No error checking?
Will fix.
Thanks for the review,
Jani.Quoted 19 lines
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +2
-1+DRM_DEBUG_DRIVER ("SWSCI supported, requested callbacks %08x\n" , + opregion->swsci_requested_callbacks); }if (mboxes &MBOX_ASLE ) {DRM_DEBUG_DRIVER ("ASLE supported\n" ); --1.7.10.4
--
Paulo Zanoni
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signature · 1 line
Paulo Zanoni
PATCH 3/6 drm/i915: add opregion function to notify bios of encoder enable/disable
In reply to Jani NikulaThe bios interface seems messy, and it's hard to tell what the bios really wants. At first, only add support for DDI based machines (hsw+), and see how it turns out.
The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference.
v2:
- squash notification function and callers patches together (Daniel)
- move callers to haswell_crtc_{enable,disable} (Daniel)
- rename notification function (Chris)
v3:
- separate notification function and callers again, as it's not clear whether the display power state notification is the right thing to do after all
--- drivers/gpu/drm/i915/i915_drv.h | 8 +++++ drivers/gpu/drm/i915/intel_opregion.c | 52 +++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+)
drivers/gpu/drm/i915/i915_drv.h +8 -0
@@ -2171,15 +2171,23 @@ static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)extern void intel_i2c_reset (struct drm_device *dev);/* intel_opregion.c */ +struct intel_encoder ;extern int intel_opregion_setup (struct drm_device *dev);#ifdef CONFIG_ACPI extern void intel_opregion_init (struct drm_device *dev);extern void intel_opregion_fini (struct drm_device *dev);extern void intel_opregion_asle_intr (struct drm_device *dev); +extern int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable);#else static inline void intel_opregion_init (struct drm_device *dev) {return ; }static inline void intel_opregion_fini (struct drm_device *dev) {return ; }static inline void intel_opregion_asle_intr (struct drm_device *dev) {return ; } +static inline int +intel_opregion_notify_encoder (struct intel_encoder *intel_encoder,bool enable) +{ +return 0 ; +}#endif /* intel_acpi.c */
drivers/gpu/drm/i915/intel_opregion.c +52 -0
58 lines not on this page · raw message
Signature · 1 line
1.7.9.5
Re: [PATCH 3/6] drm/i915: add opregion function to notify bios of encoder enable/disable
Hi
2013/8/23 Jani Nikula <[email protected]>:
Quoted 87 lines
The bios interface seems messy, and it's hard to tell what the bios really wants. At first, only add support for DDI based machines (hsw+), and see how it turns out.
The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference.
v2:
- squash notification function and callers patches together (Daniel)
- move callers to haswell_crtc_{enable,disable} (Daniel)
- rename notification function (Chris)v3:
- separate notification function and callers again, as it's not clear whether the display power state notification is the right thing to do after allSigned-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 8 +++++ drivers/gpu/drm/i915/intel_opregion.c | 52 +++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+)drivers/gpu/drm/i915/i915_drv.h +8
-0@@ -2171,15 +2171,23 @@ static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)extern void intel_i2c_reset (struct drm_device *dev);/* intel_opregion.c */ +struct intel_encoder ;extern int intel_opregion_setup (struct drm_device *dev);#ifdef CONFIG_ACPI extern void intel_opregion_init (struct drm_device *dev);extern void intel_opregion_fini (struct drm_device *dev);extern void intel_opregion_asle_intr (struct drm_device *dev); +extern int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable);#else static inline void intel_opregion_init (struct drm_device *dev) {return ; }static inline void intel_opregion_fini (struct drm_device *dev) {return ; }static inline void intel_opregion_asle_intr (struct drm_device *dev) {return ; } +static inline int +intel_opregion_notify_encoder (struct intel_encoder *intel_encoder,bool enable) +{ +return 0 ; +}#endif /* intel_acpi.c */ drivers/gpu/drm/i915/intel_opregion.c +28
-0@@ -273,6 +273,58 @@ static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)#undef C } +#define DISPLAY_TYPE_CRT 0 +#define DISPLAY_TYPE_TV 1 +#define DISPLAY_TYPE_EXTERNAL_FLAT_PANEL 2 +#define DISPLAY_TYPE_INTERNAL_FLAT_PANEL 3 + +int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable) +{ +struct drm_device *dev = intel_encoder->base.dev; +u32 parm =0 ; +u32 type =0 ; +u32 port; + +/* don't care about old stuff for now */ +if (!HAS_DDI (dev)) +return 0 ; + + port =intel_ddi_get_encoder_port (intel_encoder); +if (port ==PORT_E ) { + port =0 ; + }else { + parm |=1 << port; + port++; + } + +if (!enable) + parm |=4 <<8 ; +
drivers/gpu/drm/i915/intel_opregion.c static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out) · line 313
Quoted 10 lines
drivers/gpu/drm/i915/intel_opregion.c +10
-0+switch (intel_encoder->type) { +case INTEL_OUTPUT_ANALOG : + type =DISPLAY_TYPE_CRT ; +break ; +case INTEL_OUTPUT_UNKNOWN : +case INTEL_OUTPUT_DISPLAYPORT : +case INTEL_OUTPUT_HDMI : + type =DISPLAY_TYPE_EXTERNAL_FLAT_PANEL ; +break ; +case INTEL_OUTPUT_LVDS :
We don't have LVDS on DDI platforms.
drivers/gpu/drm/i915/intel_opregion.c static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out) · line 325
Quoted 12 lines
drivers/gpu/drm/i915/intel_opregion.c +12
-0+case INTEL_OUTPUT_EDP : + type =DISPLAY_TYPE_INTERNAL_FLAT_PANEL ; +break ; +default : +DRM_DEBUG_DRIVER ("unsupported intel_encoder type %d\n" , + intel_encoder->type); +return -EINVAL ; + } + + parm |= type << (16 + port *3 ); + +return swsci (dev,SWSCI_SBCB_DISPLAY_POWER_STATE , parm,NULL );
In patch 2, on the initialization code you call the GBDA request callbacks function to see which ones will work. Shouldn't you also add code to call the SBCB request callbacks function and see if DISPLAY_POWER_STATE is really supported? I know that DISPLAY_POWER_STATE is supposed to be mandatory, but just checking won't hurt us. We could maybe even add a code to WARN in case one of the mandatory callbacks is not available :) This suggestion could be in a separate patch.
With or without any changes: Reviewed-by: Paulo Zanoni <[email protected]>
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c +2
-1+} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private; --1.7.9.5
Signature · 1 line
Paulo Zanoni
Re: [PATCH 3/6] drm/i915: add opregion function to notify bios of encoder enable/disable
2013/8/29 Paulo Zanoni <[email protected]>:
Quoted 94 lines
Hi
2013/8/23 Jani Nikula <[email protected]>:
Quoted 91 lines
The bios interface seems messy, and it's hard to tell what the bios really wants. At first, only add support for DDI based machines (hsw+), and see how it turns out.
The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference.
v2:
- squash notification function and callers patches together (Daniel)
- move callers to haswell_crtc_{enable,disable} (Daniel)
- rename notification function (Chris)v3:
- separate notification function and callers again, as it's not clear whether the display power state notification is the right thing to do after allSigned-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 8 +++++ drivers/gpu/drm/i915/intel_opregion.c | 52 +++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+)drivers/gpu/drm/i915/i915_drv.h +8
-0@@ -2171,15 +2171,23 @@ static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)extern void intel_i2c_reset (struct drm_device *dev);/* intel_opregion.c */ +struct intel_encoder ;extern int intel_opregion_setup (struct drm_device *dev);#ifdef CONFIG_ACPI extern void intel_opregion_init (struct drm_device *dev);extern void intel_opregion_fini (struct drm_device *dev);extern void intel_opregion_asle_intr (struct drm_device *dev); +extern int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable);#else static inline void intel_opregion_init (struct drm_device *dev) {return ; }static inline void intel_opregion_fini (struct drm_device *dev) {return ; }static inline void intel_opregion_asle_intr (struct drm_device *dev) {return ; } +static inline int +intel_opregion_notify_encoder (struct intel_encoder *intel_encoder,bool enable) +{ +return 0 ; +}#endif /* intel_acpi.c */ drivers/gpu/drm/i915/intel_opregion.c +32
-0@@ -273,6 +273,58 @@ static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)#undef C } +#define DISPLAY_TYPE_CRT 0 +#define DISPLAY_TYPE_TV 1 +#define DISPLAY_TYPE_EXTERNAL_FLAT_PANEL 2 +#define DISPLAY_TYPE_INTERNAL_FLAT_PANEL 3 + +int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable) +{ +struct drm_device *dev = intel_encoder->base.dev; +u32 parm =0 ; +u32 type =0 ; +u32 port; + +/* don't care about old stuff for now */ +if (!HAS_DDI (dev)) +return 0 ; + + port =intel_ddi_get_encoder_port (intel_encoder); +if (port ==PORT_E ) { + port =0 ; + }else { + parm |=1 << port; + port++; + } + +if (!enable) + parm |=4 <<8 ; + +switch (intel_encoder->type) { +case INTEL_OUTPUT_ANALOG : + type =DISPLAY_TYPE_CRT ; +break ;
Quoted 16 lines
drivers/gpu/drm/i915/intel_opregion.c static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out) · line 313
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+case INTEL_OUTPUT_UNKNOWN : +case INTEL_OUTPUT_DISPLAYPORT : +case INTEL_OUTPUT_HDMI : + type =DISPLAY_TYPE_EXTERNAL_FLAT_PANEL ; +break ; +case INTEL_OUTPUT_LVDS :We don't have LVDS on DDI platforms.
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+case INTEL_OUTPUT_EDP : + type =DISPLAY_TYPE_INTERNAL_FLAT_PANEL ; +break ; +default : +DRM_DEBUG_DRIVER ("unsupported intel_encoder type %d\n" , + intel_encoder->type);
This should be a WARN.
Quoted 33 lines
drivers/gpu/drm/i915/intel_opregion.c static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out) · line 325
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+return -EINVAL ; + } + + parm |= type << (16 + port *3 ); + +return swsci (dev,SWSCI_SBCB_DISPLAY_POWER_STATE , parm,NULL );In patch 2, on the initialization code you call the GBDA request callbacks function to see which ones will work. Shouldn't you also add code to call the SBCB request callbacks function and see if
DISPLAY_POWER_STATEis really supported? I know thatDISPLAY_POWER_STATEis supposed to be mandatory, but just checking won't hurt us. We could maybe even add a code to WARN in case one of the mandatory callbacks is not available :) This suggestion could be in a separate patch.With or without any changes: Reviewed-by: Paulo Zanoni <[email protected]>
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c +2
-1+} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private; --1.7.9.5
--
Paulo Zanoni
Signature · 1 line
Paulo Zanoni
Re: [PATCH 3/6] drm/i915: add opregion function to notify bios of encoder enable/disable
In reply to Paulo ZanoniQuoted 94 lines · Paulo Zanoni
Hi
2013/8/23 Jani Nikula <[email protected]>:
Quoted 91 lines
The bios interface seems messy, and it's hard to tell what the bios really wants. At first, only add support for DDI based machines (hsw+), and see how it turns out.
The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference.
v2:
- squash notification function and callers patches together (Daniel)
- move callers to haswell_crtc_{enable,disable} (Daniel)
- rename notification function (Chris)v3:
- separate notification function and callers again, as it's not clear whether the display power state notification is the right thing to do after allSigned-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 8 +++++ drivers/gpu/drm/i915/intel_opregion.c | 52 +++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+)drivers/gpu/drm/i915/i915_drv.h +8
-0@@ -2171,15 +2171,23 @@ static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)extern void intel_i2c_reset (struct drm_device *dev);/* intel_opregion.c */ +struct intel_encoder ;extern int intel_opregion_setup (struct drm_device *dev);#ifdef CONFIG_ACPI extern void intel_opregion_init (struct drm_device *dev);extern void intel_opregion_fini (struct drm_device *dev);extern void intel_opregion_asle_intr (struct drm_device *dev); +extern int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable);#else static inline void intel_opregion_init (struct drm_device *dev) {return ; }static inline void intel_opregion_fini (struct drm_device *dev) {return ; }static inline void intel_opregion_asle_intr (struct drm_device *dev) {return ; } +static inline int +intel_opregion_notify_encoder (struct intel_encoder *intel_encoder,bool enable) +{ +return 0 ; +}#endif /* intel_acpi.c */ drivers/gpu/drm/i915/intel_opregion.c +32
-0@@ -273,6 +273,58 @@ static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)#undef C } +#define DISPLAY_TYPE_CRT 0 +#define DISPLAY_TYPE_TV 1 +#define DISPLAY_TYPE_EXTERNAL_FLAT_PANEL 2 +#define DISPLAY_TYPE_INTERNAL_FLAT_PANEL 3 + +int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable) +{ +struct drm_device *dev = intel_encoder->base.dev; +u32 parm =0 ; +u32 type =0 ; +u32 port; + +/* don't care about old stuff for now */ +if (!HAS_DDI (dev)) +return 0 ; + + port =intel_ddi_get_encoder_port (intel_encoder); +if (port ==PORT_E ) { + port =0 ; + }else { + parm |=1 << port; + port++; + } + +if (!enable) + parm |=4 <<8 ; + +switch (intel_encoder->type) { +case INTEL_OUTPUT_ANALOG : + type =DISPLAY_TYPE_CRT ; +break ;
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out) · line 313
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+case INTEL_OUTPUT_UNKNOWN : +case INTEL_OUTPUT_DISPLAYPORT : +case INTEL_OUTPUT_HDMI : + type =DISPLAY_TYPE_EXTERNAL_FLAT_PANEL ; +break ; +case INTEL_OUTPUT_LVDS :We don't have LVDS on DDI platforms.
Right.
Quoted 13 lines
drivers/gpu/drm/i915/intel_opregion.c static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out) · line 325
Quoted 12 lines
drivers/gpu/drm/i915/intel_opregion.c +12
-0+case INTEL_OUTPUT_EDP : + type =DISPLAY_TYPE_INTERNAL_FLAT_PANEL ; +break ; +default : +DRM_DEBUG_DRIVER ("unsupported intel_encoder type %d\n" , + intel_encoder->type); +return -EINVAL ; + } + + parm |= type << (16 + port *3 ); + +return swsci (dev,SWSCI_SBCB_DISPLAY_POWER_STATE , parm,NULL );
Quoted 8 lines
In patch 2, on the initialization code you call the GBDA request callbacks function to see which ones will work. Shouldn't you also add code to call the SBCB request callbacks function and see if
DISPLAY_POWER_STATEis really supported? I know thatDISPLAY_POWER_STATEis supposed to be mandatory, but just checking won't hurt us. We could maybe even add a code to WARN in case one of the mandatory callbacks is not available :) This suggestion could be in a separate patch.
As I explained in my reply to your review on patch 2, my idea was to filter out unsupported calls in swsci(), so we don't have to add checks to all call sites. I also log the swsci_requested_callbacks value after GBDA. We could add a bigger warn (as a separate patch) after the GBDA call if some needed callback is not requested.
BR,
Jani.
Quoted 22 lines
With or without any changes: Reviewed-by: Paulo Zanoni <[email protected]>
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c +2
-1+} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private; --1.7.9.5
Signature · 5 lines
Paulo Zanoni _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 3/6] drm/i915: add opregion function to notify bios of encoder enable/disable
2013/8/29 Jani Nikula <[email protected]>:
Quoted 128 lines · Paulo Zanoni
Quoted 94 lines
Hi
2013/8/23 Jani Nikula <[email protected]>:
Quoted 91 lines
The bios interface seems messy, and it's hard to tell what the bios really wants. At first, only add support for DDI based machines (hsw+), and see how it turns out.
The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference.
v2:
- squash notification function and callers patches together (Daniel)
- move callers to haswell_crtc_{enable,disable} (Daniel)
- rename notification function (Chris)v3:
- separate notification function and callers again, as it's not clear whether the display power state notification is the right thing to do after allSigned-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 8 +++++ drivers/gpu/drm/i915/intel_opregion.c | 52 +++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+)drivers/gpu/drm/i915/i915_drv.h +8
-0@@ -2171,15 +2171,23 @@ static inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)extern void intel_i2c_reset (struct drm_device *dev);/* intel_opregion.c */ +struct intel_encoder ;extern int intel_opregion_setup (struct drm_device *dev);#ifdef CONFIG_ACPI extern void intel_opregion_init (struct drm_device *dev);extern void intel_opregion_fini (struct drm_device *dev);extern void intel_opregion_asle_intr (struct drm_device *dev); +extern int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable);#else static inline void intel_opregion_init (struct drm_device *dev) {return ; }static inline void intel_opregion_fini (struct drm_device *dev) {return ; }static inline void intel_opregion_asle_intr (struct drm_device *dev) {return ; } +static inline int +intel_opregion_notify_encoder (struct intel_encoder *intel_encoder,bool enable) +{ +return 0 ; +}#endif /* intel_acpi.c */ drivers/gpu/drm/i915/intel_opregion.c +32
-0@@ -273,6 +273,58 @@ static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)#undef C } +#define DISPLAY_TYPE_CRT 0 +#define DISPLAY_TYPE_TV 1 +#define DISPLAY_TYPE_EXTERNAL_FLAT_PANEL 2 +#define DISPLAY_TYPE_INTERNAL_FLAT_PANEL 3 + +int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder, +bool enable) +{ +struct drm_device *dev = intel_encoder->base.dev; +u32 parm =0 ; +u32 type =0 ; +u32 port; + +/* don't care about old stuff for now */ +if (!HAS_DDI (dev)) +return 0 ; + + port =intel_ddi_get_encoder_port (intel_encoder); +if (port ==PORT_E ) { + port =0 ; + }else { + parm |=1 << port; + port++; + } + +if (!enable) + parm |=4 <<8 ; + +switch (intel_encoder->type) { +case INTEL_OUTPUT_ANALOG : + type =DISPLAY_TYPE_CRT ; +break ;Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out) · line 313
Quoted 6 lines
drivers/gpu/drm/i915/intel_opregion.c +6
-0+case INTEL_OUTPUT_UNKNOWN : +case INTEL_OUTPUT_DISPLAYPORT : +case INTEL_OUTPUT_HDMI : + type =DISPLAY_TYPE_EXTERNAL_FLAT_PANEL ; +break ; +case INTEL_OUTPUT_LVDS :We don't have LVDS on DDI platforms.
Right.
Quoted 13 lines
drivers/gpu/drm/i915/intel_opregion.c static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out) · line 325
Quoted 12 lines
drivers/gpu/drm/i915/intel_opregion.c +12
-0+case INTEL_OUTPUT_EDP : + type =DISPLAY_TYPE_INTERNAL_FLAT_PANEL ; +break ; +default : +DRM_DEBUG_DRIVER ("unsupported intel_encoder type %d\n" , + intel_encoder->type); +return -EINVAL ; + } + + parm |= type << (16 + port *3 ); + +return swsci (dev,SWSCI_SBCB_DISPLAY_POWER_STATE , parm,NULL );Quoted 8 lines
In patch 2, on the initialization code you call the GBDA request callbacks function to see which ones will work. Shouldn't you also add code to call the SBCB request callbacks function and see if
DISPLAY_POWER_STATEis really supported? I know thatDISPLAY_POWER_STATEis supposed to be mandatory, but just checking won't hurt us. We could maybe even add a code to WARN in case one of the mandatory callbacks is not available :) This suggestion could be in a separate patch.
Quoted 5 lines
As I explained in my reply to your review on patch 2, my idea was to filter out unsupported calls in
swsci(), so we don't have to add checks to all call sites. I also log theswsci_requested_callbacksvalue after GBDA. We could add a bigger warn (as a separate patch) after the GBDA call if some needed callback is not requested.
I re-checked the code and now I see why we're both confused :). We have 2 request_callbacks functions: the GBDA one and the SBCB one. If you look at patch 2, you'll notice that at intel_opregion_setup we request the GBDA callbacks. But if you look at the swsci function you'll see that our requested_callbacks check is for the SBCB main function. For some reason I was thinking we only did the "check and store requested callbacks" for GBDA, so I suggested you to implement the same thing (inside the swsci funcion), but for SBCB: with this, we wouldn't need check at the call sites. But I see that in the current code we call the "give me the GBDA callbacks" but never check them, and we don't call the "give me the SBCB callbacks" but always check them.
Also, on patch 2 when I was saying that we need the "-1" on the shift and that some bits moved around, I was reviewing the SBCB code, not the GBDA, we need to check both...
Quoted 27 lines
BR,
Jani.Quoted 22 lines
With or without any changes: Reviewed-by: Paulo Zanoni <[email protected]>
Quoted 8 lines
drivers/gpu/drm/i915/intel_opregion.c +2
-1+} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private; --1.7.9.5
--
Paulo Zanoni
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signature · 1 line
Paulo Zanoni
PATCH 4/6 drm/i915: add opregion function to notify bios of adapter power state
In reply to Jani NikulaNotifying the bios lets it enter power saving states.
--- drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/intel_opregion.c | 27 +++++++++++++++++++++++++++ 2 files changed, 30 insertions(+)
drivers/gpu/drm/i915/i915_drv.h +3 -0
@@ -2179,12 +2179,15 @@ extern void intel_opregion_fini(struct drm_device *dev);extern void intel_opregion_asle_intr (struct drm_device *dev);extern int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder,bool enable); +extern int intel_opregion_notify_adapter (struct drm_device *dev, +pci_power_t state);#else static inline void intel_opregion_init (struct drm_device *dev) {return ; }static inline void intel_opregion_fini (struct drm_device *dev) {return ; }static inline void intel_opregion_asle_intr (struct drm_device *dev) {return ; }static inline int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder,bool enable) +intel_opregion_notify_adapter(struct drm_device *dev, pci_power_t state) {return 0 ; }
drivers/gpu/drm/i915/intel_opregion.c +27 -0
@@ -325,6 +325,33 @@ int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,return swsci (dev,SWSCI_SBCB_DISPLAY_POWER_STATE , parm,NULL ); } +static const struct { +pci_power_t pci_power_state; +u32 parm; +} power_state_map[] = { + {PCI_D0 ,0x00 }, + {PCI_D1 ,0x01 }, + {PCI_D2 ,0x02 }, + { PCI_D3hot,0x04 }, + { PCI_D3cold,0x04 }, +}; + +int intel_opregion_notify_adapter (struct drm_device *dev,pci_power_t state) +{ +int i; + +if (!HAS_DDI (dev)) +return 0 ; + +for (i =0 ; i <ARRAY_SIZE (power_state_map); i++) { +if (state == power_state_map[i].pci_power_state) +return swsci (dev,SWSCI_SBCB_ADAPTER_POWER_STATE , + power_state_map[i].parm,NULL ); + } + +return -EINVAL ; +} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private;
Signature · 1 line
1.7.9.5
Re: [PATCH 4/6] drm/i915: add opregion function to notify bios of adapter power state
2013/8/23 Jani Nikula <[email protected]>:
Quoted 15 lines
Notifying the bios lets it enter power saving states.
Signed-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/intel_opregion.c | 27 +++++++++++++++++++++++++++ 2 files changed, 30 insertions(+)drivers/gpu/drm/i915/i915_drv.h +0
-0@@ -2179,12 +2179,15 @@ extern void intel_opregion_fini(struct drm_device *dev);extern void intel_opregion_asle_intr (struct drm_device *dev); extern int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,
drivers/gpu/drm/i915/i915_drv.h extern void intel_opregion_fini(struct drm_device *dev); · line 2190
Quoted 10 lines
drivers/gpu/drm/i915/i915_drv.h +3
-0bool enable); +extern int intel_opregion_notify_adapter (struct drm_device *dev, +pci_power_t state);#else static inline void intel_opregion_init (struct drm_device *dev) {return ; }static inline void intel_opregion_fini (struct drm_device *dev) {return ; }static inline void intel_opregion_asle_intr (struct drm_device *dev) {return ; } static inline int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder, bool enable) +intel_opregion_notify_adapter(struct drm_device *dev, pci_power_t state)
I don't think this will compile when you don't have CONFIG_ACPI. The "static inline int" part is missing, and the new function stole the implementation of intel_opregion_notify_encoder.
Besides this, the patch looks correct. We could try to merge patches 1-4 before the others.
Quoted 44 lines
drivers/gpu/drm/i915/i915_drv.h +0
-0{return 0 ; }drivers/gpu/drm/i915/intel_opregion.c +27
-1@@ -325,6 +325,33 @@ int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,return swsci (dev,SWSCI_SBCB_DISPLAY_POWER_STATE , parm,NULL ); } +static const struct { +pci_power_t pci_power_state; +u32 parm; +} power_state_map[] = { + {PCI_D0 ,0x00 }, + {PCI_D1 ,0x01 }, + {PCI_D2 ,0x02 }, + { PCI_D3hot,0x04 }, + { PCI_D3cold,0x04 }, +}; + +int intel_opregion_notify_adapter (struct drm_device *dev,pci_power_t state) +{ +int i; + +if (!HAS_DDI (dev)) +return 0 ; + +for (i =0 ; i <ARRAY_SIZE (power_state_map); i++) { +if (state == power_state_map[i].pci_power_state) +return swsci (dev,SWSCI_SBCB_ADAPTER_POWER_STATE , + power_state_map[i].parm,NULL ); + } + +return -EINVAL ; +} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private; --1.7.9.5
Signature · 1 line
Paulo Zanoni
Re: [PATCH 4/6] drm/i915: add opregion function to notify bios of adapter power state
Quoted 22 lines · Paulo Zanoni
2013/8/23 Jani Nikula <[email protected]>:
Quoted 21 lines
Notifying the bios lets it enter power saving states.
Signed-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/intel_opregion.c | 27 +++++++++++++++++++++++++++ 2 files changed, 30 insertions(+)drivers/gpu/drm/i915/i915_drv.h +2
-0@@ -2179,12 +2179,15 @@ extern void intel_opregion_fini(struct drm_device *dev);extern void intel_opregion_asle_intr (struct drm_device *dev);extern int intel_opregion_notify_encoder (struct intel_encoder *intel_encoder,bool enable); +extern int intel_opregion_notify_adapter (struct drm_device *dev, +pci_power_t state);#else static inline void intel_opregion_init (struct drm_device *dev) {return ; }static inline void intel_opregion_fini (struct drm_device *dev) {return ; }
Quoted 8 lines
drivers/gpu/drm/i915/i915_drv.h extern void intel_opregion_fini(struct drm_device *dev); · line 2190
Quoted 4 lines
drivers/gpu/drm/i915/i915_drv.h +1
-0static inline void intel_opregion_asle_intr (struct drm_device *dev) {return ; } static inline int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder, bool enable) +intel_opregion_notify_adapter(struct drm_device *dev, pci_power_t state)I don't think this will compile when you don't have
CONFIG_ACPI. The "static inline int" part is missing, and the new function stole the implementation ofintel_opregion_notify_encoder.
*facepalm* that's ugly.
Thanks for the review,
Jani.
Quoted 57 lines
Besides this, the patch looks correct. We could try to merge patches 1-4 before the others.
Quoted 44 lines
drivers/gpu/drm/i915/i915_drv.h +0
-0{return 0 ; }drivers/gpu/drm/i915/intel_opregion.c +27
-1@@ -325,6 +325,33 @@ int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,return swsci (dev,SWSCI_SBCB_DISPLAY_POWER_STATE , parm,NULL ); } +static const struct { +pci_power_t pci_power_state; +u32 parm; +} power_state_map[] = { + {PCI_D0 ,0x00 }, + {PCI_D1 ,0x01 }, + {PCI_D2 ,0x02 }, + { PCI_D3hot,0x04 }, + { PCI_D3cold,0x04 }, +}; + +int intel_opregion_notify_adapter (struct drm_device *dev,pci_power_t state) +{ +int i; + +if (!HAS_DDI (dev)) +return 0 ; + +for (i =0 ; i <ARRAY_SIZE (power_state_map); i++) { +if (state == power_state_map[i].pci_power_state) +return swsci (dev,SWSCI_SBCB_ADAPTER_POWER_STATE , + power_state_map[i].parm,NULL ); + } + +return -EINVAL ; +} +static u32 asle_set_backlight (struct drm_device *dev,u32 bclp) {struct drm_i915_private *dev_priv = dev->dev_private; --1.7.9.5
Signature · 5 lines
Paulo Zanoni _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
PATCH 5/6 DRAFT: drm/i915: do display power state notification on crtc enable/disable
In reply to Jani NikulaThe spec says to notify prior to power down and after power up. It is unclear whether it makes a difference.
--- drivers/gpu/drm/i915/intel_display.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/i915/intel_display.c +6 -2
@@ -3404,8 +3404,10 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)intel_update_fbc (dev);mutex_unlock (&dev->struct_mutex); -for_each_encoder_on_crtc (dev, crtc, encoder) +for_each_encoder_on_crtc (dev, crtc, encoder) { encoder->enable (encoder); +intel_opregion_notify_encoder (encoder, true); + }/* * There seems to be a race in PCH platform hw (at least on some
@@ -3519,8 +3521,10 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)if (!intel_crtc->active)return ; -for_each_encoder_on_crtc (dev, crtc, encoder) +for_each_encoder_on_crtc (dev, crtc, encoder) { +intel_opregion_notify_encoder (encoder, false); encoder->disable (encoder); + }intel_crtc_wait_for_pending_flips (crtc);drm_vblank_off (dev, pipe);
Signature · 1 line
1.7.9.5
Re: [PATCH 5/6] DRAFT: drm/i915: do display power state notification on crtc enable/disable
2013/8/23 Jani Nikula <[email protected]>:
Quoted 13 lines
The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference.
Signed-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/intel_display.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)drivers/gpu/drm/i915/intel_display.c +0
-0
drivers/gpu/drm/i915/intel_display.c static void haswell_crtc_enable(struct drm_crtc *crtc) · line 3409
Quoted 7 lines
drivers/gpu/drm/i915/intel_display.c +2
-1@@ -3404,8 +3404,10 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)intel_update_fbc (dev);mutex_unlock (&dev->struct_mutex); -for_each_encoder_on_crtc (dev, crtc, encoder) +for_each_encoder_on_crtc (dev, crtc, encoder) { encoder->enable (encoder); +intel_opregion_notify_encoder (encoder, true);
No error checking. But if you followed my bikesheds on the previous patches, I believe all the error cases have already been singaled by error messages, so this could be fine.
remove the DRAFT word form the patch title)
Quoted 19 lines
drivers/gpu/drm/i915/intel_display.c +4
-2+ }/* * There seems to be a race in PCH platform hw (at least on some @@ -3519,8 +3521,10 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)if (!intel_crtc->active)return ; -for_each_encoder_on_crtc (dev, crtc, encoder) +for_each_encoder_on_crtc (dev, crtc, encoder) { +intel_opregion_notify_encoder (encoder, false); encoder->disable (encoder); + }intel_crtc_wait_for_pending_flips (crtc);drm_vblank_off (dev, pipe); --1.7.9.5
Signature · 1 line
Paulo Zanoni
PATCH 6/6 DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable
In reply to Jani Nikula--- drivers/gpu/drm/i915/intel_display.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/i915/intel_display.c +4 -0
@@ -6093,6 +6093,8 @@ void hsw_enable_pc8_work(struct work_struct *__work)lpt_disable_clkout_dp (dev);hsw_pc8_disable_interrupts (dev);hsw_disable_lcpll (dev_priv, true, true); + +intel_opregion_notify_adapter (dev,PCI_D1 ); }static void __hsw_enable_package_c8 (struct drm_i915_private *dev_priv)
@@ -6126,6 +6128,8 @@ static void __hsw_disable_package_c8(struct drm_i915_private *dev_priv)if (!dev_priv->pc8.enabled)return ; +intel_opregion_notify_adapter (dev,PCI_D0 ); +DRM_DEBUG_KMS ("Disabling package C8+\n" );hsw_restore_lcpll (dev_priv);
Signature · 1 line
1.7.9.5
Re: [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable
2013/8/23 Jani Nikula <[email protected]>:
/* Please insert explanation on why we need this and what changes if we do this. */
I applied your patches and booted them. I got into PC8, did the PC8 test suite and nothing changed. I really don't know what to expect from this series and/or how to check what's improving. Also, see below:
Quoted 10 lines
Signed-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/intel_display.c | 4 ++++ 1 file changed, 4 insertions(+)drivers/gpu/drm/i915/intel_display.c +0
-0
drivers/gpu/drm/i915/intel_display.c void hsw_enable_pc8_work(struct work_struct *__work) · line 6097
Quoted 5 lines
drivers/gpu/drm/i915/intel_display.c +2
-0@@ -6093,6 +6093,8 @@ void hsw_enable_pc8_work(struct work_struct *__work)lpt_disable_clkout_dp (dev);hsw_pc8_disable_interrupts (dev);hsw_disable_lcpll (dev_priv, true, true); + +intel_opregion_notify_adapter (dev,PCI_D1 );
Why D1? Shouldn't this be D3? I think that's what people having been asking us to implement.
On the doc that explains "adapter power state notification", my understanding is that it suggests that we should call this _before_ we go into the lower states and the other chunk should be called _after_ we're at the higher power states. So perhaps we should call intel_opregion_notify_adapter before hsw_disable_lcpll, and, on the chunk below, after hsw_restore_lcpll? But this is not 100% clear, I may be wrong.
By the way, I modified your patch to implement the suggestions above, and got the same results: no noticeable difference, everything still works. No news is good news?
Quoted 15 lines
drivers/gpu/drm/i915/intel_display.c +2
-1}static void __hsw_enable_package_c8 (struct drm_i915_private *dev_priv)@@ -6126,6 +6128,8 @@ static void __hsw_disable_package_c8(struct drm_i915_private *dev_priv)if (!dev_priv->pc8.enabled)return ; +intel_opregion_notify_adapter (dev,PCI_D0 ); +DRM_DEBUG_KMS ("Disabling package C8+\n" );hsw_restore_lcpll (dev_priv); --1.7.9.5
Signature · 1 line
Paulo Zanoni
Re: [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable
Quoted 10 lines · On Fri, 23 Aug 2013 13:44:17 -0300 Paulo Zanoni <[email protected]> wrote:
2013/8/23 Jani Nikula <[email protected]>:
/* Please insert explanation on why we need this and what changes if we do this. */
I applied your patches and booted them. I got into PC8, did the PC8 test suite and nothing changed. I really don't know what to expect from this series and/or how to check what's improving. Also, see below:
So this is one of these things that will have no visible impact on i915, but will impact other parts of the system. So I think the only way to test it is by throwing it on the SIP board and checking the power level of the components this impacts (Audio, thermal, KBC/EC, LPT). And without the code which does the actual PCI D3 request from i915, nothing will happen. Is it possible to get a patch which finds some very obvious place to put the controller into D3 so we can check to see if the opregion notifies are doing what they are supposed to?
Quoted 51 lines
Quoted 11 lines
Signed-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/intel_display.c | 4 ++++ 1 file changed, 4 insertions(+)drivers/gpu/drm/i915/intel_display.c +0
-0drivers/gpu/drm/i915/intel_display.c void hsw_enable_pc8_work(struct work_struct *__work) · line 6097
Quoted 5 lines
drivers/gpu/drm/i915/intel_display.c +2
-0@@ -6093,6 +6093,8 @@ void hsw_enable_pc8_work(struct work_struct *__work)lpt_disable_clkout_dp (dev);hsw_pc8_disable_interrupts (dev);hsw_disable_lcpll (dev_priv, true, true); + +intel_opregion_notify_adapter (dev,PCI_D1 );Why D1? Shouldn't this be D3? I think that's what people having been asking us to implement.
On the doc that explains "adapter power state notification", my understanding is that it suggests that we should call this _before_ we go into the lower states and the other chunk should be called _after_ we're at the higher power states. So perhaps we should call
intel_opregion_notify_adapterbeforehsw_disable_lcpll, and, on the chunk below, afterhsw_restore_lcpll? But this is not 100% clear, I may be wrong.By the way, I modified your patch to implement the suggestions above, and got the same results: no noticeable difference, everything still works. No news is good news?
Quoted 15 lines
drivers/gpu/drm/i915/intel_display.c +2
-1}static void __hsw_enable_package_c8 (struct drm_i915_private *dev_priv)@@ -6126,6 +6128,8 @@ static void __hsw_disable_package_c8(struct drm_i915_private *dev_priv)if (!dev_priv->pc8.enabled)return ; +intel_opregion_notify_adapter (dev,PCI_D0 ); +DRM_DEBUG_KMS ("Disabling package C8+\n" );hsw_restore_lcpll (dev_priv); --1.7.9.5
Re: [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable
2013/8/23 Kristen Carlson Accardi <[email protected]>:
Quoted 14 lines
Quoted 10 lines · On Fri, 23 Aug 2013 13:44:17 -0300 Paulo Zanoni <[email protected]> wrote:
2013/8/23 Jani Nikula <[email protected]>:
/* Please insert explanation on why we need this and what changes if we do this. */
I applied your patches and booted them. I got into PC8, did the PC8 test suite and nothing changed. I really don't know what to expect from this series and/or how to check what's improving. Also, see below:
Quoted 6 lines
So this is one of these things that will have no visible impact on i915, but will impact other parts of the system. So I think the only way to test it is by throwing it on the SIP board and checking the power level of the components this impacts (Audio, thermal, KBC/EC, LPT). And without the code which does the actual PCI D3 request from i915, nothing will happen.
I was told we could try to verify this by reading PCI config register 0xd4, but for me it's always 0x0, which means we're probably not really getting into D3.
Quoted 3 lines
Is it possible to get a patch which finds
some very obvious place to put the controller into D3 so we can check to see if the opregion notifies are doing what they are supposed to?
http://cgit.freedesktop.org/~pzanoni/linux/?h=d3-wip
My check using the PCI config register 0xd4 suggests we're probably not really enabling D3 :(
Quoted 53 lines
Quoted 52 lines
Quoted 12 lines
Signed-off-by Jani Nikula <[email protected]>--- drivers/gpu/drm/i915/intel_display.c | 4 ++++ 1 file changed, 4 insertions(+)drivers/gpu/drm/i915/intel_display.c +0
-0drivers/gpu/drm/i915/intel_display.c void hsw_enable_pc8_work(struct work_struct *__work) · line 6097
Quoted 5 lines
drivers/gpu/drm/i915/intel_display.c +2
-0@@ -6093,6 +6093,8 @@ void hsw_enable_pc8_work(struct work_struct *__work)lpt_disable_clkout_dp (dev);hsw_pc8_disable_interrupts (dev);hsw_disable_lcpll (dev_priv, true, true); + +intel_opregion_notify_adapter (dev,PCI_D1 );Why D1? Shouldn't this be D3? I think that's what people having been asking us to implement.
On the doc that explains "adapter power state notification", my understanding is that it suggests that we should call this _before_ we go into the lower states and the other chunk should be called _after_ we're at the higher power states. So perhaps we should call
intel_opregion_notify_adapterbeforehsw_disable_lcpll, and, on the chunk below, afterhsw_restore_lcpll? But this is not 100% clear, I may be wrong.By the way, I modified your patch to implement the suggestions above, and got the same results: no noticeable difference, everything still works. No news is good news?
Quoted 15 lines
drivers/gpu/drm/i915/intel_display.c +2
-1}static void __hsw_enable_package_c8 (struct drm_i915_private *dev_priv)@@ -6126,6 +6128,8 @@ static void __hsw_disable_package_c8(struct drm_i915_private *dev_priv)if (!dev_priv->pc8.enabled)return ; +intel_opregion_notify_adapter (dev,PCI_D0 ); +DRM_DEBUG_KMS ("Disabling package C8+\n" );hsw_restore_lcpll (dev_priv); --1.7.9.5
Signature · 1 line
Paulo Zanoni
Re: [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable
Quoted 22 lines · Paulo Zanoni
2013/8/23 Kristen Carlson Accardi <[email protected]>:
Quoted 14 lines
Quoted 10 lines · On Fri, 23 Aug 2013 13:44:17 -0300 Paulo Zanoni <[email protected]> wrote:
2013/8/23 Jani Nikula <[email protected]>:
/* Please insert explanation on why we need this and what changes if we do this. */
I applied your patches and booted them. I got into PC8, did the PC8 test suite and nothing changed. I really don't know what to expect from this series and/or how to check what's improving. Also, see below:
Quoted 6 lines
So this is one of these things that will have no visible impact on i915, but will impact other parts of the system. So I think the only way to test it is by throwing it on the SIP board and checking the power level of the components this impacts (Audio, thermal, KBC/EC, LPT). And without the code which does the actual PCI D3 request from i915, nothing will happen.
Quoted 3 lines
I was told we could try to verify this by reading PCI config register
0xd4, but for me it's always0x0, which means we're probably not really getting into D3.
You have to write 0x3 into the PCI PM register to make it enter D3. Exactly like you do when you suspend the whole machine.
Not sure 0xd4 is the correct offset in this case, but you can look it up from lspci output (remember +4), or in kernel code just use pci_dev.pm_cap+4. Hmm, it's 0xd4 in my SNB at least. Maybe it's always the same for the GPU.
Signature · 2 lines
Ville Syrjälä Intel OTC
Re: [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable
2013/8/23 Ville Syrjälä <[email protected]>:
Quoted 27 lines · Paulo Zanoni
Quoted 22 lines
2013/8/23 Kristen Carlson Accardi <[email protected]>:
Quoted 14 lines
Quoted 10 lines · On Fri, 23 Aug 2013 13:44:17 -0300 Paulo Zanoni <[email protected]> wrote:
2013/8/23 Jani Nikula <[email protected]>:
/* Please insert explanation on why we need this and what changes if we do this. */
I applied your patches and booted them. I got into PC8, did the PC8 test suite and nothing changed. I really don't know what to expect from this series and/or how to check what's improving. Also, see below:
Quoted 6 lines
So this is one of these things that will have no visible impact on i915, but will impact other parts of the system. So I think the only way to test it is by throwing it on the SIP board and checking the power level of the components this impacts (Audio, thermal, KBC/EC, LPT). And without the code which does the actual PCI D3 request from i915, nothing will happen.
Quoted 3 lines
I was told we could try to verify this by reading PCI config register
0xd4, but for me it's always0x0, which means we're probably not really getting into D3.
Quoted 7 lines
You have to write
0x3into the PCI PM register to make it enter D3. Exactly like you do when you suspend the whole machine.Not sure
0xd4is the correct offset in this case, but you can look it up from lspci output (remember +4), or in kernel code just use pci_dev.pm_cap+4. Hmm, it's0xd4in my SNB at least. Maybe it's always the same for the GPU.
Check the description of 0xd4 on BSpec.
I actually wrote the "get into D3" value to it (using setpci), and then when I got out of PC8 I saw tons and tons of error messages on dmesg due to the fact that we were failing to write registers. Which means it probably works, but we may have more work to do.
Quoted 4 lines
--
Ville Syrjälä
Intel OTC
Signature · 1 line
Paulo Zanoni
Re: [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable
Quoted 36 lines · Paulo Zanoni
2013/8/23 Ville Syrjälä <[email protected]>:
Quoted 27 lines · Paulo Zanoni
Quoted 22 lines
2013/8/23 Kristen Carlson Accardi <[email protected]>:
Quoted 14 lines
Quoted 10 lines · On Fri, 23 Aug 2013 13:44:17 -0300 Paulo Zanoni <[email protected]> wrote:
2013/8/23 Jani Nikula <[email protected]>:
/* Please insert explanation on why we need this and what changes if we do this. */
I applied your patches and booted them. I got into PC8, did the PC8 test suite and nothing changed. I really don't know what to expect from this series and/or how to check what's improving. Also, see below:
Quoted 6 lines
So this is one of these things that will have no visible impact on i915, but will impact other parts of the system. So I think the only way to test it is by throwing it on the SIP board and checking the power level of the components this impacts (Audio, thermal, KBC/EC, LPT). And without the code which does the actual PCI D3 request from i915, nothing will happen.
Quoted 3 lines
I was told we could try to verify this by reading PCI config register
0xd4, but for me it's always0x0, which means we're probably not really getting into D3.Quoted 7 lines
You have to write
0x3into the PCI PM register to make it enter D3. Exactly like you do when you suspend the whole machine.Not sure
0xd4is the correct offset in this case, but you can look it up from lspci output (remember +4), or in kernel code just use pci_dev.pm_cap+4. Hmm, it's0xd4in my SNB at least. Maybe it's always the same for the GPU.
Quoted 6 lines
Check the description of
0xd4on BSpec.I actually wrote the "get into D3" value to it (using setpci), and then when I got out of PC8 I saw tons and tons of error messages on dmesg due to the fact that we were failing to write registers. Which means it probably works, but we may have more work to do.
My quick and dirty idea for runtime PM would be something like this:
- for ioctls just slap rpm_get_sync/put() around drm_ioctl, not optimal but it's very easy for getting started
- all sysfs/debugfs stuff would need to be handled individually
- to deal w/ gtt mmaps just call put_fence or something during suspend, grab one ref in fault and probably release it from a delayed work, or mabe record a timestamp at last fault time and check it in the idle callback
- grab one ref per request (or per active ring maybe?)
- grab one ref per active pipe
- maybe some odd delayed work would need another reference
With that, I think everything of importance would hold a reference, so the runtime pm idle callback shouldn't really need to do much.
Signature · 2 lines
Ville Syrjälä Intel OTC
Re: [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable
Quoted 12 lines · Ville Syrjälä
My quick and dirty idea for runtime PM would be something like this:
- for ioctls just slap rpm_get_sync/put() arounddrm_ioctl, not optimal but it's very easy for getting started
- all sysfs/debugfs stuff would need to be handled individually
- to deal w/ gtt mmaps just callput_fenceor something during suspend, grab one ref in fault and probably release it from a delayed work, or mabe record a timestamp at last fault time and check it in the idle callback
- grab one ref per request (or per active ring maybe?)
- grab one ref per active pipe
- maybe some odd delayed work would need another reference
Quoted 2 lines
With that, I think everything of importance would hold a reference, so the runtime pm idle callback shouldn't really need to do much.
I think we can do this cheaper:
- Grab a ref everywhere we want to disallow pc8+ currently (by hooking into the same get/put calls Paulo's patches sprinkled all over). That should cover 100% of all the runtime stuff - Paulo's pc8+ test is rather extensive.
That leaves us with the debugfs/sysfs crap doing register access. Cheap and dirty (and likely to make Chris rage) is to add get/put calls with a suitable timeout to the register i/o functions. Less cheap (but I'm unsure whether that's better) would be to sprinkle get/put calls around all relevant sysfs/debugfs files. Pure s/w stuff like the error state wouldn't need it though (and we should try hard not to require it in case runtime pm hangs).
-Daniel
Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch