[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/drm_crtc.c between commit b21e3afe2357 (drm: use ida to
allocate connector ids) from the drm tree and commit 88cd8b8b1503 (drm:
add MIPI DSI encoder and connector types) from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/drm_crtc.c
index 54b4169,190827d..000
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@@ -186,22 -193,23 +186,23 @@@ struct drm_conn_prop_enum_list
* Connector and encoder types.
*/
static struct drm_conn_prop_enum_list drm_connector_enum_list[] =
-{ { DRM_MODE_CONNECTOR_Unknown, Unknown, 0 },
- { DRM_MODE_CONNECTOR_VGA, VGA, 0 },
- { DRM_MODE_CONNECTOR_DVII, DVI-I, 0 },
- { DRM_MODE_CONNECTOR_DVID, DVI-D, 0 },
- { DRM_MODE_CONNECTOR_DVIA, DVI-A, 0 },
- { DRM_MODE_CONNECTOR_Composite, Composite, 0 },
- { DRM_MODE_CONNECTOR_SVIDEO, SVIDEO, 0 },
- { DRM_MODE_CONNECTOR_LVDS, LVDS, 0 },
- { DRM_MODE_CONNECTOR_Component, Component, 0 },
- { DRM_MODE_CONNECTOR_9PinDIN, DIN, 0 },
- { DRM_MODE_CONNECTOR_DisplayPort, DP, 0 },
- { DRM_MODE_CONNECTOR_HDMIA, HDMI-A, 0 },
- { DRM_MODE_CONNECTOR_HDMIB, HDMI-B, 0 },
- { DRM_MODE_CONNECTOR_TV, TV, 0 },
- { DRM_MODE_CONNECTOR_eDP, eDP, 0 },
- { DRM_MODE_CONNECTOR_VIRTUAL, Virtual, 0},
+{ { DRM_MODE_CONNECTOR_Unknown, Unknown },
+ { DRM_MODE_CONNECTOR_VGA, VGA },
+ { DRM_MODE_CONNECTOR_DVII, DVI-I },
+ { DRM_MODE_CONNECTOR_DVID, DVI-D },
+ { DRM_MODE_CONNECTOR_DVIA, DVI-A },
+ { DRM_MODE_CONNECTOR_Composite, Composite },
+ { DRM_MODE_CONNECTOR_SVIDEO, SVIDEO },
+ { DRM_MODE_CONNECTOR_LVDS, LVDS },
+ { DRM_MODE_CONNECTOR_Component, Component },
+ { DRM_MODE_CONNECTOR_9PinDIN, DIN },
+ { DRM_MODE_CONNECTOR_DisplayPort, DP },
+ { DRM_MODE_CONNECTOR_HDMIA, HDMI-A },
+ { DRM_MODE_CONNECTOR_HDMIB, HDMI-B },
+ { DRM_MODE_CONNECTOR_TV, TV },
+ { DRM_MODE_CONNECTOR_eDP, eDP },
+ { DRM_MODE_CONNECTOR_VIRTUAL, Virtual },
+ { DRM_MODE_CONNECTOR_DSI, DSI },
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@@ -211,24 -219,9 +212,25 @@@
{ DRM_MODE_ENCODER_LVDS, LVDS },
{ DRM_MODE_ENCODER_TVDAC, TV },
{ DRM_MODE_ENCODER_VIRTUAL, Virtual },
+ { DRM_MODE_ENCODER_DSI, DSI },
};
+void drm_connector_ida_init(void)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(drm_connector_enum_list); i++)
+ ida_init(drm_connector_enum_list[i].ida);
+}
+
+void drm_connector_ida_destroy(void)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(drm_connector_enum_list); i++)
+ ida_destroy(drm_connector_enum_list[i].ida);
+}
+
const char *drm_get_encoder_name(const struct drm_encoder *encoder)
{
static char buf[32];
pgpmLI8uJVWEq.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Track the proc which created the context
On Thu, Aug 29, 2013 at 3:31 AM, Ben Widawsky benjamin.widaw...@intel.com wrote: We've tried more than once in the past to print the guilty process. Prior to Mika's recent work however, we never had a good way to actually assign guilt. With that, this trivial patch should get print the guilty process and pid in dmesg. Until we merge the full PPGTT support (which have per fd contexts), we don't have a good way to name the default context used by X, and other clients not opting in to contexts. As such, they will get swapper as their guilty process. Once the full PPGTT support is merged, we should be able to properly track the names. NOTE: The string is limited to 16 characters as defined by the ASCII string kept in the task struct. One could theoretically pull out the full from the command args as done for cmdline in proc, but this is terribly ugly, and a homework assignment for another day. Example courtesy of Eric: [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x1b5a000 ctx 1 [ext_framebuffer pid=5762]) at 0x1b5a034 Cc: Mika Kuoppala mika.kuopp...@linux.intel.com Tested-by: Eric Anholt e...@anholt.net Signed-off-by: Ben Widawsky b...@bwidawsk.net This is neat. But while at it I think we should add the same information to the error state, too. Care to quickly update your patch? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Report enabled slices on Haswell GT3
On Wed, Aug 28, 2013 at 10:09:40PM +0100, Chris Wilson wrote: On Wed, Aug 28, 2013 at 04:45:46PM -0300, Rodrigo Vivi wrote: Batchbuffers constructed by userspace can conditionalise their URB allocations through the use of the MI_SET_PREDICATE command. This command can read the MI_PREDICATE_RESULT_2 register to see how many slices are enabled on GT3, and by virtue of the result, scale their memory allocations to fit enabled memory. Of course, this only works if the kernel sets the appropriate bit in the register first. v2: Better commit subject and message by Chris Wilson. Cc: Chris Wilson ch...@chris-wilson.co.uk Credits-by: Yejun Guo yejun@intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com I would have written the I915_WRITE() differently but, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] How to work around zero-initialized BLC_PWM_PCH_CTL2?
Hi, a new laptop model we've been struggling has some strange hardware configuration. BIOS turns off backlight and skips its initialization when the machine is booted with the lid closed. This leaves BLC_PWM_PCH_CTL2 and other registers uninitialized. Because a proper max brightness value can't be obtained from this register, i915 driver doesn't create the own backlight control any more. It results in the permanent blank screen even after the lid is opened. Actually, the only missing piece is the initial BLC_PWM_PCH_CTL2 value. If I overwrite it via intel_reg_write before loading i915 module, everything works fine. Now I wonder whether we can get this max brightness value from somewhere else. Is it defined in VBT or anywhere else persistent? thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Boost RPS frequency for CPU stalls
On Thu, Aug 29, 2013 at 03:04:13AM +, Meng, Mengmeng wrote: Hi, It's Power results on IVB mobile. With the patches, workloads would cost more power. mobile IVB git-53749d3 git-53749d3 with four Patches VS no workloads patchesPatch Average Watt-hour Time Average Watt-hour Time Average Watt-hour watt watt watt idle 25.6 3.7 9′25.7 3.8 9′ 100.39% 102.70% video30.7 2.75'30 30.9 2.75'30 100.65% 100.00% game 33.5 6.411'43 33.9 6.511'41 101.19% 101.56% That too is inline with expectations. Boosting the frequency everytime we need a result from the GPU from idle is going to burn through power more quickly. I think this a reasonable result though - I think the extra power use is justified by the snappier response. It must be time for someone to step forward and review the patches, or to check the results on their favourite workload. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Track the proc which created the context
On Thu, Aug 29, 2013 at 08:36:59AM +0200, Daniel Vetter wrote: On Thu, Aug 29, 2013 at 3:31 AM, Ben Widawsky benjamin.widaw...@intel.com wrote: We've tried more than once in the past to print the guilty process. Prior to Mika's recent work however, we never had a good way to actually assign guilt. With that, this trivial patch should get print the guilty process and pid in dmesg. Until we merge the full PPGTT support (which have per fd contexts), we don't have a good way to name the default context used by X, and other clients not opting in to contexts. As such, they will get swapper as their guilty process. Once the full PPGTT support is merged, we should be able to properly track the names. NOTE: The string is limited to 16 characters as defined by the ASCII string kept in the task struct. One could theoretically pull out the full from the command args as done for cmdline in proc, but this is terribly ugly, and a homework assignment for another day. Example courtesy of Eric: [drm:i915_set_reset_status] *ERROR* render ring hung inside bo (0x1b5a000 ctx 1 [ext_framebuffer pid=5762]) at 0x1b5a034 Cc: Mika Kuoppala mika.kuopp...@linux.intel.com Tested-by: Eric Anholt e...@anholt.net Signed-off-by: Ben Widawsky b...@bwidawsk.net This is neat. But while at it I think we should add the same information to the error state, too. Care to quickly update your patch? We also have request-file, admittedly only valid for live clients, but could be used for accurate naming. If we want to keep the info around, I think we want a refcounted struct i915_comm that could be used independently of contexts (because we have machines too old for contexts)... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 12/15] drm/i915: Band Gap WA
On Tue, Aug 27, 2013 at 03:12:24PM +0300, Jani Nikula wrote:
+static void band_gap_wa(struct drm_i915_private *dev_priv)
+{
+ mutex_lock(dev_priv-dpio_lock);
+
+ /* Enable bandgap fix in GOP driver */
+ vlv_cck_modify(dev_priv, 0x6D, 0x0001, 0x0003);
I hear that the new way of doing the band gap reset is through the
flisdsi sideband interface (instead of CCK) to shave off non necessary
delays.
Yogesh, should we upstream the flisdsi version of this patch instead?
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: add opregion function to notify bios of encoder enable/disable
Hi
2013/8/23 Jani Nikula jani.nik...@intel.com:
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 all
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |8 +
drivers/gpu/drm/i915/intel_opregion.c | 52
+
2 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index adc2f46..1703029 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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 */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index a3558ae..72a4af6 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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_TV1
+#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;
+ 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.
+ 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
paulo.r.zan...@intel.com
+}
+
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
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add plumbing for SWSCI
2013/8/29 Paulo Zanoni przan...@gmail.com:
Hi
2013/8/28 Jani Nikula jani.nik...@intel.com:
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
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_opregion.c | 133
-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 84b95b1..adc2f46 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index cfb8fb6..233cc7f 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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 (131)
+/* 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 ?
+#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)
+#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)
+#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_DISPLAYSWSCI_FUNCTION_CODE(SWSCI_SBCB, 9)
+#define SWSCI_SBCB_SET_INTERNAL_GFXSWSCI_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 (08)
#define ACPI_VGA_OUTPUT (18)
#define ACPI_TV_OUTPUT (28)
@@ -158,6 +203,84 @@ struct opregion_asle {
#define ACPI_LVDS_OUTPUT (48)
#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
Re: [Intel-gfx] [PATCH] drm/i915: add plumbing for SWSCI
On Thu, 29 Aug 2013, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/8/28 Jani Nikula jani.nik...@intel.com:
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
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_opregion.c | 133
-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 84b95b1..adc2f46 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index cfb8fb6..233cc7f 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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 (131)
+/* 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]).
+#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)
+#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. :)
+#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_DISPLAYSWSCI_FUNCTION_CODE(SWSCI_SBCB, 9)
+#define SWSCI_SBCB_SET_INTERNAL_GFXSWSCI_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 (08)
#define ACPI_VGA_OUTPUT (18)
#define ACPI_TV_OUTPUT (28)
@@ -158,6 +203,84 @@ struct opregion_asle {
#define ACPI_LVDS_OUTPUT (48)
Re: [Intel-gfx] [PATCH 4/6] drm/i915: add opregion function to notify bios of adapter power state
2013/8/23 Jani Nikula jani.nik...@intel.com:
Notifying the bios lets it enter power saving states.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/intel_opregion.c | 27 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1703029..e17a9a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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)
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.
{
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 72a4af6..e47aefc 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] DRAFT: drm/i915: do display power state notification on crtc enable/disable
2013/8/23 Jani Nikula jani.nik...@intel.com:
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 jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bcb62fe..a6df68e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -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.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com (and you can
remove the DRAFT word form the patch title)
+ }
/*
* 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
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: add opregion function to notify bios of encoder enable/disable
2013/8/29 Paulo Zanoni przan...@gmail.com:
Hi
2013/8/23 Jani Nikula jani.nik...@intel.com:
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 all
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |8 +
drivers/gpu/drm/i915/intel_opregion.c | 52
+
2 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index adc2f46..1703029 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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 */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index a3558ae..72a4af6 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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_TV1
+#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;
+ 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.
+ 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.
+ 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
paulo.r.zan...@intel.com
+}
+
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
--
Paulo Zanoni
___
Intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: add opregion function to notify bios of encoder enable/disable
On Thu, 29 Aug 2013, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/8/23 Jani Nikula jani.nik...@intel.com:
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 all
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |8 +
drivers/gpu/drm/i915/intel_opregion.c | 52
+
2 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index adc2f46..1703029 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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 */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index a3558ae..72a4af6 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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_TV1
+#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;
+ 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.
+ 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.
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,
Re: [Intel-gfx] [PATCH 4/6] drm/i915: add opregion function to notify bios of adapter power state
On Thu, 29 Aug 2013, Paulo Zanoni przan...@gmail.com wrote:
2013/8/23 Jani Nikula jani.nik...@intel.com:
Notifying the bios lets it enter power saving states.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/intel_opregion.c | 27 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 1703029..e17a9a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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)
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.
*facepalm* that's ugly.
Thanks for the review,
Jani.
Besides this, the patch looks correct. We could try to merge patches
1-4 before the others.
{
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 72a4af6..e47aefc 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Trace context switches
On Thu, Aug 29, 2013 at 01:34:30PM +0100, Chris Wilson wrote: Add a tracepoint for monitoring context switching. Sounds familiar http://lists.freedesktop.org/archives/intel-gfx/2012-June/018003.html Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk [snip] -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore the preliminary HW check.
On Fri, Aug 23, 2013 at 04:33:58PM -0700, Jesse Barnes wrote: On Fri, 23 Aug 2013 16:00:07 -0700 Ben Widawsky benjamin.widaw...@intel.com wrote: We still maintain code internally that cares about preliminary support. Leaving the check here doesn't hurt anyone, and should keep things more in line. This time around, stick the info in the intel_info structure, and also change the error from DRM_ERROR-DRM_INFO. I hate this param. But this looks like a better way to do it than the ID list we had in pci_probe before. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org Daniel, ping. One of my goals is to allow people to easily look at source and determine which HW is preliminary, and which isn't. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Trace context switches
On Thu, Aug 29, 2013 at 09:29:18AM -0700, Ben Widawsky wrote: On Thu, Aug 29, 2013 at 01:34:30PM +0100, Chris Wilson wrote: Add a tracepoint for monitoring context switching. Sounds familiar http://lists.freedesktop.org/archives/intel-gfx/2012-June/018003.html Not quite what I want though. I guess what I really want is inter-process context switches in addition to hw-context switches. But still that patch lack information that I think will be useful. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Trace context switches
On Thu, Aug 29, 2013 at 05:45:14PM +0100, Chris Wilson wrote: On Thu, Aug 29, 2013 at 09:29:18AM -0700, Ben Widawsky wrote: On Thu, Aug 29, 2013 at 01:34:30PM +0100, Chris Wilson wrote: Add a tracepoint for monitoring context switching. Sounds familiar http://lists.freedesktop.org/archives/intel-gfx/2012-June/018003.html Not quite what I want though. I guess what I really want is inter-process context switches in addition to hw-context switches. But still that patch lack information that I think will be useful. -Chris -- Chris Wilson, Intel Open Source Technology Centre Maybe I don't know what info you're trying to obtain. Fix the commit message? -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Trace context switches
On Thu, Aug 29, 2013 at 09:54:58AM -0700, Ben Widawsky wrote: On Thu, Aug 29, 2013 at 05:45:14PM +0100, Chris Wilson wrote: On Thu, Aug 29, 2013 at 09:29:18AM -0700, Ben Widawsky wrote: On Thu, Aug 29, 2013 at 01:34:30PM +0100, Chris Wilson wrote: Add a tracepoint for monitoring context switching. Sounds familiar http://lists.freedesktop.org/archives/intel-gfx/2012-June/018003.html Not quite what I want though. I guess what I really want is inter-process context switches in addition to hw-context switches. But still that patch lack information that I think will be useful. -Chris -- Chris Wilson, Intel Open Source Technology Centre Maybe I don't know what info you're trying to obtain. Fix the commit message? Add a tracepoint for correctly monitoring context switching. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use RCS flips on Ivybridge+
On Mon, Aug 26, 2013 at 1:43 PM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
On Mon, Aug 26, 2013 at 1:42 PM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:
On Mon, Aug 26, 2013 at 12:58 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
RCS flips do work on Iybridge+ so long as we can unmask the messages
through DERRMR. However, there are quite a few workarounds mentioned
regarding unmasking more than one event or triggering more than one
message through DERRMR. Those workarounds in principle prevent us from
performing pipelined flips (and asynchronous flips across multiple
planes) and equally apply to the known good BCS ring. Given that it
already appears to work, and also appears to work with unmasking all 3
planes at once (and queuing flips across multiple planes), be brave.
Bugzlla: https://bugs.freedesktop.org/show_bug.cgi?id=67600
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Lightly-tested-by: Stephane Marchesin marche...@icps.u-strasbg.fr
You can go ahead and say Tested-by, I ran my usual tests for 3 hours and
it didn't crash/show an issue. It would crash in ~10-30 minutes with the
other patches.
Oh actually this one is a bit different... Give me 3 hours :)
Tested-by: Stéphane Marchesin marc...@chromium.org
Stéphane
Stéphane
Cc: Stephane Marchesin marche...@icps.u-strasbg.fr
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_reg.h | 18
drivers/gpu/drm/i915/intel_display.c | 40
2 files changed, 49 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index c6f5009..df168f4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -230,6 +230,7 @@
* address/value pairs. Don't overdue it, though, x = 2^4 must hold!
*/
#define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*x-1)
+#define MI_STORE_REGISTER_MEM(x) MI_INSTR(0x24, 2*x-1)
#define MI_FLUSH_DWMI_INSTR(0x26, 1) /* for GEN6 */
#define MI_FLUSH_DW_STORE_INDEX (121)
#define MI_INVALIDATE_TLB(118)
@@ -678,6 +679,23 @@
#define FPGA_DBG_RM_NOCLAIM (131)
#define DERRMR 0x44050
+#define DERRMR_PIPEA_SCANLINE(10)
+#define DERRMR_PIPEA_PRI_FLIP_DONE (11)
+#define DERRMR_PIPEA_SPR_FLIP_DONE (12)
+#define DERRMR_PIPEA_VBLANK (13)
+#define DERRMR_PIPEA_HBLANK (15)
+#define DERRMR_PIPEB_SCANLINE(18)
+#define DERRMR_PIPEB_PRI_FLIP_DONE (19)
+#define DERRMR_PIPEB_SPR_FLIP_DONE (110)
+#define DERRMR_PIPEB_VBLANK (111)
+#define DERRMR_PIPEB_HBLANK (113)
+/* Note that PIPEC is not a simple translation of PIPEA/PIPEB */
+#define DERRMR_PIPEC_SCANLINE(114)
+#define DERRMR_PIPEC_PRI_FLIP_DONE (115)
+#define DERRMR_PIPEC_SPR_FLIP_DONE (120)
+#define DERRMR_PIPEC_VBLANK (121)
+#define DERRMR_PIPEC_HBLANK (122)
+
/* GM45+ chicken bits -- debug workaround bits that may be required
* for various sorts of correct behavior. The top 16 bits of each are
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9748dce..ffbcbd1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7826,12 +7826,6 @@ err:
return ret;
}
-/*
- * On gen7 we currently use the blit ring because (in early silicon at
least)
- * the render ring doesn't give us interrpts for page flip completion,
which
- * means clients will hang after the first flip is queued. Fortunately
the
- * blit ring generates interrupts properly, so use it instead.
- */
static int intel_gen7_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
@@ -7839,9 +7833,13 @@ static int intel_gen7_queue_flip(struct drm_device
*dev,
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_ring_buffer *ring = dev_priv-ring[BCS];
+ struct intel_ring_buffer *ring;
uint32_t plane_bit = 0;
- int ret;
+ int len, ret;
+
+ ring = obj-ring;
+ if (ring == NULL || ring-id != RCS)
+ ring = dev_priv-ring[BCS];
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
if (ret)
@@ -7863,10 +7861,34 @@ static int intel_gen7_queue_flip(struct
drm_device *dev,
goto err_unpin;
}
- ret = intel_ring_begin(ring, 4);
+ len = 4;
+ if (ring-id == RCS)
+ len += 6;
+
+ ret = intel_ring_begin(ring, len);
if (ret)
goto err_unpin;
+ /* Unmask the flip-done completion message. Note that the bspec
says that
+* we should do
Re: [Intel-gfx] [PATCH] drm/i915: add plumbing for SWSCI
2013/8/29 Jani Nikula jani.nik...@intel.com:
On Thu, 29 Aug 2013, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/8/28 Jani Nikula jani.nik...@intel.com:
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
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_opregion.c | 133
-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 84b95b1..adc2f46 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index cfb8fb6..233cc7f 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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 (131)
+/* 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]).
In the same spec, section 3.3.1, table 3-35 says it's 15:8 :(
We're both right and wrong...
+#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)
+#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. :)
+#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_DISPLAYSWSCI_FUNCTION_CODE(SWSCI_SBCB, 9)
+#define SWSCI_SBCB_SET_INTERNAL_GFXSWSCI_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
Re: [Intel-gfx] [PATCH 3/6] drm/i915: add opregion function to notify bios of encoder enable/disable
2013/8/29 Jani Nikula jani.nik...@intel.com:
On Thu, 29 Aug 2013, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/8/23 Jani Nikula jani.nik...@intel.com:
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 all
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |8 +
drivers/gpu/drm/i915/intel_opregion.c | 52
+
2 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index adc2f46..1703029 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -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 */
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index a3558ae..72a4af6 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -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_TV1
+#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;
+ 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.
+ 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.
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
[Intel-gfx] [PATCH] drm/i915: Fix list corruption in vma_unbind
The saga around the breadcrumb vmas used by execbuf continues ...
This time around we've managed to unconditionally move the object to
the unbound list on the last vma unbind even though it might never
have been on either the bound or unbound list. Hilarity ensued.
Chris Wilson tracked this one down but compared to his patches I've
simply opted to completely separate the unbound case for not-yet bound
vmas. Otherwise we imo end up with semantically hard to parse checks
around the list_move_tail(global_list, ...).
This is exercised by the new swapping variants of
igt/tests/gem_evict_everything.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
Bugzilla: https://bugs.freedesktop.org/attachment.cgi?id=84818
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d9eee14..d12dfc3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2624,8 +2624,11 @@ int i915_vma_unbind(struct i915_vma *vma)
if (list_empty(vma-vma_link))
return 0;
- if (!drm_mm_node_allocated(vma-node))
- goto destroy;
+ if (!drm_mm_node_allocated(vma-node)) {
+ i915_gem_vma_destroy(vma);
+
+ return 0;
+ }
if (obj-pin_count)
return -EBUSY;
@@ -2665,7 +2668,6 @@ int i915_vma_unbind(struct i915_vma *vma)
drm_mm_remove_node(vma-node);
-destroy:
i915_gem_vma_destroy(vma);
/* Since the unbound list is global, only move to that list if
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix list corruption in vma_unbind
On Thu, Aug 29, 2013 at 07:50:31PM +0200, Daniel Vetter wrote:
The saga around the breadcrumb vmas used by execbuf continues ...
This time around we've managed to unconditionally move the object to
the unbound list on the last vma unbind even though it might never
have been on either the bound or unbound list. Hilarity ensued.
Chris Wilson tracked this one down but compared to his patches I've
simply opted to completely separate the unbound case for not-yet bound
vmas. Otherwise we imo end up with semantically hard to parse checks
around the list_move_tail(global_list, ...).
This is exercised by the new swapping variants of
igt/tests/gem_evict_everything.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
Bugzilla: https://bugs.freedesktop.org/attachment.cgi?id=84818
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d9eee14..d12dfc3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2624,8 +2624,11 @@ int i915_vma_unbind(struct i915_vma *vma)
if (list_empty(vma-vma_link))
return 0;
- if (!drm_mm_node_allocated(vma-node))
- goto destroy;
+ if (!drm_mm_node_allocated(vma-node)) {
+ i915_gem_vma_destroy(vma);
+
I'm equivocal on this particular whitespace. For such short branches, it
looks neater with a tight return.
+ return 0;
+ }
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use RCS flips on Ivybridge+
On Mon, Aug 26, 2013 at 08:58:12PM +0100, Chris Wilson wrote:
RCS flips do work on Iybridge+ so long as we can unmask the messages
through DERRMR. However, there are quite a few workarounds mentioned
regarding unmasking more than one event or triggering more than one
message through DERRMR. Those workarounds in principle prevent us from
performing pipelined flips (and asynchronous flips across multiple
planes) and equally apply to the known good BCS ring. Given that it
already appears to work, and also appears to work with unmasking all 3
planes at once (and queuing flips across multiple planes), be brave.
Bugzlla: https://bugs.freedesktop.org/show_bug.cgi?id=67600
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Lightly-tested-by: Stephane Marchesin marche...@icps.u-strasbg.fr
Cc: Stephane Marchesin marche...@icps.u-strasbg.fr
Cc: Ben Widawsky b...@bwidawsk.net
Both patches merged to dinq.
-Daniel
---
drivers/gpu/drm/i915/i915_reg.h | 18
drivers/gpu/drm/i915/intel_display.c | 40
2 files changed, 49 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c6f5009..df168f4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -230,6 +230,7 @@
* address/value pairs. Don't overdue it, though, x = 2^4 must hold!
*/
#define MI_LOAD_REGISTER_IMM(x) MI_INSTR(0x22, 2*x-1)
+#define MI_STORE_REGISTER_MEM(x) MI_INSTR(0x24, 2*x-1)
#define MI_FLUSH_DW MI_INSTR(0x26, 1) /* for GEN6 */
#define MI_FLUSH_DW_STORE_INDEX(121)
#define MI_INVALIDATE_TLB (118)
@@ -678,6 +679,23 @@
#define FPGA_DBG_RM_NOCLAIM(131)
#define DERRMR 0x44050
+#define DERRMR_PIPEA_SCANLINE (10)
+#define DERRMR_PIPEA_PRI_FLIP_DONE (11)
+#define DERRMR_PIPEA_SPR_FLIP_DONE (12)
+#define DERRMR_PIPEA_VBLANK(13)
+#define DERRMR_PIPEA_HBLANK(15)
+#define DERRMR_PIPEB_SCANLINE (18)
+#define DERRMR_PIPEB_PRI_FLIP_DONE (19)
+#define DERRMR_PIPEB_SPR_FLIP_DONE (110)
+#define DERRMR_PIPEB_VBLANK(111)
+#define DERRMR_PIPEB_HBLANK(113)
+/* Note that PIPEC is not a simple translation of PIPEA/PIPEB */
+#define DERRMR_PIPEC_SCANLINE (114)
+#define DERRMR_PIPEC_PRI_FLIP_DONE (115)
+#define DERRMR_PIPEC_SPR_FLIP_DONE (120)
+#define DERRMR_PIPEC_VBLANK(121)
+#define DERRMR_PIPEC_HBLANK(122)
+
/* GM45+ chicken bits -- debug workaround bits that may be required
* for various sorts of correct behavior. The top 16 bits of each are
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9748dce..ffbcbd1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7826,12 +7826,6 @@ err:
return ret;
}
-/*
- * On gen7 we currently use the blit ring because (in early silicon at least)
- * the render ring doesn't give us interrpts for page flip completion, which
- * means clients will hang after the first flip is queued. Fortunately the
- * blit ring generates interrupts properly, so use it instead.
- */
static int intel_gen7_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
@@ -7839,9 +7833,13 @@ static int intel_gen7_queue_flip(struct drm_device
*dev,
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_ring_buffer *ring = dev_priv-ring[BCS];
+ struct intel_ring_buffer *ring;
uint32_t plane_bit = 0;
- int ret;
+ int len, ret;
+
+ ring = obj-ring;
+ if (ring == NULL || ring-id != RCS)
+ ring = dev_priv-ring[BCS];
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
if (ret)
@@ -7863,10 +7861,34 @@ static int intel_gen7_queue_flip(struct drm_device
*dev,
goto err_unpin;
}
- ret = intel_ring_begin(ring, 4);
+ len = 4;
+ if (ring-id == RCS)
+ len += 6;
+
+ ret = intel_ring_begin(ring, len);
if (ret)
goto err_unpin;
+ /* Unmask the flip-done completion message. Note that the bspec says
that
+ * we should do this for both the BCS and RCS, and that we must not
unmask
+ * more than one flip event at any time (or ensure that one flip message
+ * can be sent by waiting for flip-done prior to queueing new flips).
+ * Experimentation says that BCS works despite DERRMR masking all
+ * flip-done completion events and that unmasking all planes at once
+ * for the RCS also doesn't appear to drop events. Setting the DERRMR
+ * to zero does lead to lockups within
Re: [Intel-gfx] [PATCH 08/17] drm/i915: Always prefer CPU relocations with LLC
On Thu, Aug 29, 2013 at 09:11:16PM +0200, Daniel Vetter wrote:
On Thu, Aug 29, 2013 at 10:20:06AM -0700, Ben Widawsky wrote:
On Mon, Aug 26, 2013 at 07:51:00PM -0300, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
A follow-on to the update of the LLC coherency logic is that we can rely
on the LLC being coherent with the CS for rewriting batchbuffers
irrespective of their cache domain. (This should have no effect
currently as all the batch buffers are expected to be I915_CACHE_LLC and
so using the cpu relocation path anyway.)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 792c52a..3b64b9f 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -166,7 +166,8 @@ eb_destroy(struct eb_objects *eb)
static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
{
- return (obj-base.write_domain == I915_GEM_DOMAIN_CPU ||
+ return (HAS_LLC(obj-base.dev) ||
+ obj-base.write_domain == I915_GEM_DOMAIN_CPU ||
!obj-map_and_fenceable ||
obj-cache_level != I915_CACHE_NONE);
Assuming the commit message is factually correct... the obj-cache_level
shouldn't factor into the equation at all.
We stil need to take the cache level into account on non-llc machines ...
-Daniel
I always forget I915_CACHE_LLC is overloaded to mean snoopable.
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix list corruption in vma_unbind
On Thu, Aug 29, 2013 at 07:57:38PM +0100, Chris Wilson wrote:
On Thu, Aug 29, 2013 at 07:50:31PM +0200, Daniel Vetter wrote:
The saga around the breadcrumb vmas used by execbuf continues ...
This time around we've managed to unconditionally move the object to
the unbound list on the last vma unbind even though it might never
have been on either the bound or unbound list. Hilarity ensued.
Chris Wilson tracked this one down but compared to his patches I've
simply opted to completely separate the unbound case for not-yet bound
vmas. Otherwise we imo end up with semantically hard to parse checks
around the list_move_tail(global_list, ...).
This is exercised by the new swapping variants of
igt/tests/gem_evict_everything.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky b...@bwidawsk.net
Bugzilla: https://bugs.freedesktop.org/attachment.cgi?id=84818
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Merged, but I've dropped the paragraph about the igt tests again - I just
can't hit the bug any more :( Also I've fixed the bugzilla link, it
pointed at an attachment instead of the bug.
-Daniel
---
drivers/gpu/drm/i915/i915_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index d9eee14..d12dfc3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2624,8 +2624,11 @@ int i915_vma_unbind(struct i915_vma *vma)
if (list_empty(vma-vma_link))
return 0;
- if (!drm_mm_node_allocated(vma-node))
- goto destroy;
+ if (!drm_mm_node_allocated(vma-node)) {
+ i915_gem_vma_destroy(vma);
+
I'm equivocal on this particular whitespace. For such short branches, it
looks neater with a tight return.
+ return 0;
+ }
--
Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/6] treewide: kmem_cache_alloc GFP_ZERO cleanups
Just a few cleanups to use zalloc style calls and reduce the uses of __GFP_ZERO for kmem_cache_alloc[_node] uses. Use the more kernel normal zalloc style. Joe Perches (6): slab/block: Add and use kmem_cache_zalloc_node block: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc i915_gem: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc aio: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc ceph: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc f2fs: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc block/blk-core.c| 3 +-- block/blk-integrity.c | 3 +-- block/blk-ioc.c | 6 ++ block/cfq-iosched.c | 10 -- drivers/gpu/drm/i915/i915_gem.c | 2 +- fs/aio.c| 2 +- fs/ceph/dir.c | 2 +- fs/ceph/file.c | 2 +- fs/f2fs/super.c | 2 +- include/linux/slab.h| 5 + 10 files changed, 18 insertions(+), 19 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] i915_gem: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc
The helper exists, might as well use it instead of __GFP_ZERO.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8a0eb96..c4acd96 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -214,7 +214,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
void *i915_gem_object_alloc(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- return kmem_cache_alloc(dev_priv-slab, GFP_KERNEL | __GFP_ZERO);
+ return kmem_cache_zalloc(dev_priv-slab, GFP_KERNEL);
}
void i915_gem_object_free(struct drm_i915_gem_object *obj)
--
1.8.1.2.459.gbcd45b4.dirty
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix list corruption in vma_unbind
On Thu, Aug 29, 2013 at 11:06:24PM +0200, Daniel Vetter wrote: On Thu, Aug 29, 2013 at 07:57:38PM +0100, Chris Wilson wrote: On Thu, Aug 29, 2013 at 07:50:31PM +0200, Daniel Vetter wrote: The saga around the breadcrumb vmas used by execbuf continues ... This time around we've managed to unconditionally move the object to the unbound list on the last vma unbind even though it might never have been on either the bound or unbound list. Hilarity ensued. Chris Wilson tracked this one down but compared to his patches I've simply opted to completely separate the unbound case for not-yet bound vmas. Otherwise we imo end up with semantically hard to parse checks around the list_move_tail(global_list, ...). This is exercised by the new swapping variants of igt/tests/gem_evict_everything. Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Ben Widawsky b...@bwidawsk.net Bugzilla: https://bugs.freedesktop.org/attachment.cgi?id=84818 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Merged, but I've dropped the paragraph about the igt tests again - I just can't hit the bug any more :( Also I've fixed the bugzilla link, it pointed at an attachment instead of the bug. It fixed the tests for me, just got a whole new trace when using GL. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Updated stolen mem patches
On Tue, Aug 27, 2013 at 01:49:08PM -0500, H. Peter Anvin wrote: If noone hers to them first poke me tomorrow. On an aircraft right now. As discussed on irc I've pulled these in through drm-intel-next trees. Should show up in the next linux-next. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Just a one-line patch to fix a black screen issue on rare ivb machines,:w cc: stable. Normally I'd just shovel this into the -next pull request this late in the -rc cycle, but Linus was making noises about not getting real fixes which are cc: stable. So here we go ;-) Cheers, Daniel The following changes since commit d8dfad3876e438b759da3c833d62fb8b2267: Linux 3.11-rc7 (2013-08-25 17:43:22 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-08-30 for you to fetch changes up to 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d: drm/i915: ivb: fix edp voltage swing reg val (2013-08-30 00:07:27 +0200) Imre Deak (1): drm/i915: ivb: fix edp voltage swing reg val drivers/gpu/drm/i915/i915_reg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next
Hi Dave,
Need to get my stuff out the door ;-) Highlights:
- pc8+ support from Paulo
- more vma patches from Ben.
- Kconfig option to enable preliminary support by default (Josh
Triplett)
- Optimized cpu cache flush handling and support for write-through caching
of display planes on Iris (Chris)
- rc6 tuning from Stéphane Marchesin for more stability
- VECS seqno wrap/semaphores fix (Ben)
- a pile of smaller cleanups and improvements all over
Note that I've ditched Ben's execbuf vma conversion for 3.12 since not yet
ready. But there's still other vma conversion stuff in here.
Cheers, Daniel
The following changes since commit 5c536613d8ebda3da0448550d0a997651a6048e2:
drm/i915: Fix FB WM for HSW (2013-08-09 20:27:43 +0200)
are available in the git repository at:
git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-08-23
for you to fetch changes up to fb1ae911f4e58c2cf28fcd48b59f54d17283da07:
drm/i915: Print seqnos as unsigned in debugfs (2013-08-23 14:52:37 +0200)
Ben Widawsky (10):
drm/i915: WARN_ON failed map_and_fenceable
drm/i915: Initialize seqno for VECS too
drm/i915: Get VECS semaphore info on error
drm/i915: Remove node only when allocated
drm/i915: cleanup mapfence in bind
drm: WARN when removing unallocated node
drm/i915: s/obj-exec_list/obj-obj_exec_link in debugfs
drm/i915: Switch eviction code to use vmas
drm/i915: prepare bind_to_vm for preallocated vma
drm/i915/vma: Correct use after free in eviction
Chris Wilson (9):
drm/i915: Update rules for reading cache lines through the LLC
drm/i915: Track when an object is pinned for use by the display engine
drm/i915: Update rules for writing through the LLC with the cpu
drm/i915: Allow the GPU to cache stolen memory
drm/i915: Only do a chipset flush after a clflush
drm/i915: Use Write-Through cacheing for the display plane on Iris
drm/i915: Allow the user to set bo into the DISPLAY cache domain
drm/i915: Print the changes required for modeset
drm/i915: Drop the overzealous warning from i915_gem_set_cache_level
Damien Lespiau (4):
drm/i915: Remove DSPARB_HWCONTROL()
drm/i915: Remove HAS_PIPE_CONTROL()
drm: Remove IS_IRONLAKE_D()
drm/i915: Remove I915_READ_{NOPID, SYNC_0, SYNC_1})()
Daniel Vetter (6):
drm/i915: reserve I915_CACHING_DISPLAY and document cache modes
drm/i915: clarify error paths in create_stolen_for_preallocated
drm/i915: use vma-node directly and rewrap mapfence in bind
drm/i915: unpin backing storage in dmabuf_unmap
drm/i915: explicit store base gem object in dma_buf-priv
drm/i915: Use POSTING_READ in lcpll code
Guillaume Clement (1):
i915: Fix SDVO potentially turning off randomly
Jani Nikula (3):
drm/i915: remove unused leftover variable irq_received
drm/i915: give more distinctive names to ring hangcheck action enums
drm/i915: drop unnecessary local variable to suppress build warning
Jesse Barnes (3):
drm/i915: make IVB FDI training match spec v3
drm/i915: Expose energy counter on SNB+ through debugfs
drm/i915: drop WaMbcDriverBootEnable workaround
Josh Triplett (1):
i915: Add a Kconfig option to turn on i915.preliminary_hw_support by
default
Paulo Zanoni (20):
drm/i915: remove set but unused variables
drm/i915: print a message when we detect an early Haswell SDV
drm/i915: check the power well when redisabling VGA
drm/i915: clarify Haswell power well bit names
drm/i915: enable the power well before module unload
drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq
drm/i915: wrap GTIMR changes
drm/i915: wrap GEN6_PMIMR changes
drm/i915: don't update GEN6_PMIMR when it's not needed
drm/i915: add dev_priv-pm_irq_mask
drm/i915: don't disable/reenable IVB error interrupts when not needed
drm/i915: don't queue PM events we won't process
drm/i915: fix how we mask PMIMR when adding work to the queue
drm/i915: merge HSW and SNB PM irq handlers
drm/i915: grab force_wake when restoring LCPLL
drm/i915: fix SDEIMR assertion when disabling LCPLL
drm/i915: allow package C8+ states on Haswell (disabled)
drm/i915: add i915_pc8_status debugfs file
drm/i915: add i915.pc8_timeout function
drm/i915: enable Package C8+ by default
Rafael Barbalho (1):
drm/i915: Cleaning up the relocate entry function
Stéphane Marchesin (1):
drm/i915: tune the RC6 threshold for stability
Ville Syrjälä (2):
drm/i915: Fix context size calculation on SNB/IVB/VLV
drm/i915: Print seqnos as unsigned in debugfs
Vinit Azad (1):
drm/i915: Only unmask required PM interrupts
drivers/gpu/drm/Kconfig| 11 +
drivers/gpu/drm/drm_mm.c | 3 +
Re: [Intel-gfx] [PATCH] drm/i915: Fix list corruption in vma_unbind
On Thu, Aug 29, 2013 at 10:19:24PM +0100, Chris Wilson wrote: On Thu, Aug 29, 2013 at 11:06:24PM +0200, Daniel Vetter wrote: On Thu, Aug 29, 2013 at 07:57:38PM +0100, Chris Wilson wrote: On Thu, Aug 29, 2013 at 07:50:31PM +0200, Daniel Vetter wrote: The saga around the breadcrumb vmas used by execbuf continues ... This time around we've managed to unconditionally move the object to the unbound list on the last vma unbind even though it might never have been on either the bound or unbound list. Hilarity ensued. Chris Wilson tracked this one down but compared to his patches I've simply opted to completely separate the unbound case for not-yet bound vmas. Otherwise we imo end up with semantically hard to parse checks around the list_move_tail(global_list, ...). This is exercised by the new swapping variants of igt/tests/gem_evict_everything. Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Ben Widawsky b...@bwidawsk.net Bugzilla: https://bugs.freedesktop.org/attachment.cgi?id=84818 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Merged, but I've dropped the paragraph about the igt tests again - I just can't hit the bug any more :( Also I've fixed the bugzilla link, it pointed at an attachment instead of the bug. It fixed the tests for me, just got a whole new trace when using GL. -Chris -- Chris Wilson, Intel Open Source Technology Centre I'm not really sure why the assertion I added blew up :/ Tested-by: Ben Widawsky b...@bwidawsk.net -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Modify DP set clock to accomodate more eDP timings.
eDP 1.4 supports 4-5 extra link rates in additional to current 2 link
rate. Create a structure to store the DPLL divisor data to improve
readability.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 48 +++---
1 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2151d13..ab8a5ff 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -38,6 +38,19 @@
#define DP_LINK_CHECK_TIMEOUT (10 * 1000)
+struct dp_link_dpll{
+ int link_bw;
+ struct dpll dpll;
+};
+
+static const struct dp_link_dpll gen4_dpll[] =
+ {{ DP_LINK_BW_1_62, {2,23,8,2,10,0,0,0,0}},
+ { DP_LINK_BW_2_7, {1,14,2,1,10,0,0,0,0}}};
+
+static const struct dp_link_dpll pch_dpll[] =
+ {{ DP_LINK_BW_1_62, {1,12,9,2,10,0,0,0,0}},
+ { DP_LINK_BW_2_7, {2,14,8,1,10,0,0,0,0}}};
+
/**
* is_edp - is the given port attached to an eDP panel (either CPU or PCH)
* @intel_dp: DP struct
@@ -649,37 +662,24 @@ intel_dp_set_clock(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config, int link_bw)
{
struct drm_device *dev = encoder-base.dev;
+ int i;
if (IS_G4X(dev)) {
- if (link_bw == DP_LINK_BW_1_62) {
- pipe_config-dpll.p1 = 2;
- pipe_config-dpll.p2 = 10;
- pipe_config-dpll.n = 2;
- pipe_config-dpll.m1 = 23;
- pipe_config-dpll.m2 = 8;
- } else {
- pipe_config-dpll.p1 = 1;
- pipe_config-dpll.p2 = 10;
- pipe_config-dpll.n = 1;
- pipe_config-dpll.m1 = 14;
- pipe_config-dpll.m2 = 2;
+ for(i = 0; i sizeof(gen4_dpll) / sizeof(struct dp_link_dpll);
i++) {
+ if (link_bw == gen4_dpll[i].link_bw){
+ pipe_config-dpll = gen4_dpll[i].dpll;
+ break;
+ }
}
pipe_config-clock_set = true;
} else if (IS_HASWELL(dev)) {
/* Haswell has special-purpose DP DDI clocks. */
} else if (HAS_PCH_SPLIT(dev)) {
- if (link_bw == DP_LINK_BW_1_62) {
- pipe_config-dpll.n = 1;
- pipe_config-dpll.p1 = 2;
- pipe_config-dpll.p2 = 10;
- pipe_config-dpll.m1 = 12;
- pipe_config-dpll.m2 = 9;
- } else {
- pipe_config-dpll.n = 2;
- pipe_config-dpll.p1 = 1;
- pipe_config-dpll.p2 = 10;
- pipe_config-dpll.m1 = 14;
- pipe_config-dpll.m2 = 8;
+ for(i = 0; i sizeof(pch_dpll) / sizeof(struct dp_link_dpll);
i++) {
+ if (link_bw == pch_dpll[i].link_bw){
+ pipe_config-dpll = pch_dpll[i].dpll;
+ break;
+ }
}
pipe_config-clock_set = true;
} else if (IS_VALLEYVIEW(dev)) {
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock
For DP pll settings, there is only two golden configs. Instead of running
through the algorithm to determine it, hardcode the value and get it
determine in intel_dp_set_clock.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_dp.c | 12 +++-
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f526ea9..453fa16 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -339,19 +339,6 @@ static const intel_limit_t intel_limits_vlv_hdmi = {
.p2_slow = 2, .p2_fast = 20 },
};
-static const intel_limit_t intel_limits_vlv_dp = {
- .dot = { .min = 25000, .max = 27 },
- .vco = { .min = 400, .max = 600 },
- .n = { .min = 1, .max = 7 },
- .m = { .min = 22, .max = 450 },
- .m1 = { .min = 2, .max = 3 },
- .m2 = { .min = 11, .max = 156 },
- .p = { .min = 10, .max = 30 },
- .p1 = { .min = 1, .max = 3 },
- .p2 = { .dot_limit = 27,
- .p2_slow = 2, .p2_fast = 20 },
-};
-
static const intel_limit_t *intel_ironlake_limit(struct drm_crtc *crtc,
int refclk)
{
@@ -414,10 +401,8 @@ static const intel_limit_t *intel_limit(struct drm_crtc
*crtc, int refclk)
} else if (IS_VALLEYVIEW(dev)) {
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_ANALOG))
limit = intel_limits_vlv_dac;
- else if (intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))
+ else
limit = intel_limits_vlv_hdmi;
- else
- limit = intel_limits_vlv_dp;
} else if (!IS_GEN2(dev)) {
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS))
limit = intel_limits_i9xx_lvds;
@@ -4889,15 +4874,16 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
}
refclk = i9xx_get_refclk(crtc, num_connectors);
+
+ limit = intel_limit(crtc, refclk);
- if (!is_dsi) {
+ if (!is_dsi !intel_crtc-config.clock_set) {
/*
* Returns a set of divisors for the desired target clock with
* the given refclk, or FALSE. The returned values represent
* the clock equation: reflck * (5 * (m1 + 2) + (m2 + 2)) / (n +
* 2) / p1 / p2.
*/
- limit = intel_limit(crtc, refclk);
ok = dev_priv-display.find_dpll(limit, crtc,
intel_crtc-config.port_clock,
refclk, NULL, clock);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ab8a5ff..89a2606 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -51,6 +51,10 @@ static const struct dp_link_dpll pch_dpll[] =
{{ DP_LINK_BW_1_62, {1,12,9,2,10,0,0,0,0}},
{ DP_LINK_BW_2_7, {2,14,8,1,10,0,0,0,0}}};
+static const struct dp_link_dpll vlv_dpll[] =
+ {{ DP_LINK_BW_1_62, {5,3,81,3,2,0,0,0,0}},
+ { DP_LINK_BW_2_7, {1,2,27,2,2,0,0,0,0}}};
+
/**
* is_edp - is the given port attached to an eDP panel (either CPU or PCH)
* @intel_dp: DP struct
@@ -683,7 +687,13 @@ intel_dp_set_clock(struct intel_encoder *encoder,
}
pipe_config-clock_set = true;
} else if (IS_VALLEYVIEW(dev)) {
- /* FIXME: Need to figure out optimized DP clocks for vlv. */
+ for(i = 0; i sizeof(vlv_dpll) / sizeof(struct dp_link_dpll);
i++) {
+ if (link_bw == vlv_dpll[i].link_bw){
+ pipe_config-dpll = vlv_dpll[i].dpll;
+ break;
+ }
+ }
+ pipe_config-clock_set = true;
}
}
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
