Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue
On Wed, 16 Oct 2013, Jani Nikula jani.nik...@intel.com wrote:
This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.
There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.
The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.
Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.
The bug raised its head since
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sat May 4 10:09:18 2013 +0200
Revert drm/i915: revert eDP bpp clamping code changes
which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.
Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.
We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
CC: sta...@vger.kernel.org
Signed-off-by: Jani Nikula jani.nik...@intel.com
Tested-by: Ulf Winkelvos u...@winkelvos.de
Tested-by: jkp j...@iki.fi
and I also have another machine on loan this fixes.
Jani.
---
For backporting to v3.12, you also need
commit 84a44adc16ab118cf7e0518861216cbc91cee6e4
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Fri Sep 6 23:29:00 2013 +0300
drm/i915: Add support for pipe_bpp readout
---
drivers/gpu/drm/i915/intel_dp.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f63aa8c..cb895d8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1476,6 +1476,27 @@ static void intel_dp_get_config(struct intel_encoder
*encoder,
ironlake_check_encoder_dotclock(pipe_config, dotclock);
pipe_config-adjusted_mode.crtc_clock = dotclock;
+
+ if (is_edp(intel_dp) dev_priv-vbt.edp_bpp
+ pipe_config-pipe_bpp dev_priv-vbt.edp_bpp) {
+ /*
+ * This is a big fat ugly hack.
+ *
+ * Some machines in UEFI boot mode provide us a VBT that has 18
+ * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+ * unknown we fail to light up. Yet the same BIOS boots up with
+ * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+ * max, not what it tells us to use.
+ *
+ * Note: This will still be broken if the eDP panel is not lit
+ * up by the BIOS, and thus we can't get the mode at module
+ * load.
+ */
+ DRM_DEBUG_KMS(pipe has %d bpp for eDP panel, overriding
BIOS-provided max %d bpp\n,
+ pipe_config-pipe_bpp, dev_priv-vbt.edp_bpp);
+ dev_priv-vbt.edp_bpp = pipe_config-pipe_bpp;
+ }
+
}
static bool is_edp_psr(struct drm_device *dev)
--
1.7.9.5
--
Jani Nikula, 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] drm/i915: remove dead code in ironlake_crtc_mode_set
In
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Wed Jun 5 13:34:23 2013 +0200
drm/i915: consolidate pch pll enable sequence
I've removed all the code from this if block, but somehow forgotten to
kill the block itself.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 04c3e1b..38892db 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6072,11 +6072,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
else
intel_crtc-lowfreq_avail = false;
- if (intel_crtc-config.has_pch_encoder) {
- pll = intel_crtc_to_shared_dpll(intel_crtc);
-
- }
-
intel_set_pipe_timings(intel_crtc);
if (intel_crtc-config.has_pch_encoder) {
--
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 2/7] drm/i915: Fix non-scaled sprites for ILK
On Thu, Oct 17, 2013 at 09:56:03PM +0100, Chris Wilson wrote: On Thu, Oct 17, 2013 at 10:53:14PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com For some reason we're enabling sprite scaling on ILK always. That doesn't work well with the new watermark code that expects to use LP1 watermarks with unscaled sprites. Only enable sprite scaling on ILK when actually needed, just like we do on SNB. The sprite plane simply didn't work on my ilk machine unless I enabled the scaler. If you want to revert it, at least mention which patch you are reverting with justification/demonstration that it works now. Hmm. Oh I see it actually does work when the scaler is enabled. I'm going to assume the hardware automagically disables LP1+ watermarks in that case or something, and then it just happens to work even though we don't set up the watermarks correctly. Earlier I was trying with a 1k wide 32bpp source w/o scaling, so it exceeded the scaler limits (width_bytes 4096) but since the code that does the check didn't realize scaling was actually enabled it let it through and the hardware didn't like that very much. So since it kind of works currently with smaller source widths, I'm going to leave it alone until I send out the watermark changes. And I'll pimp up the commit message at that point. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do hw quiescing first during unload
On Thu, Oct 17, 2013 at 02:04:34PM -0700, Ben Widawsky wrote: On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote: On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote: On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote: If we force the hw to idle as our first step during unload, we can abort the unload upon failure. Later we can probe whether the hardware remain active even after we try to shut it down. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield what we want? It may be mean, but it seems to me to be the right thing to do if we cannot turn off the hardware to unload the driver... -Chris -- Chris Wilson, Intel Open Source Technology Centre And what about my suggestion of simply using pci_clear_master? Might that hang some boxes? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: bikeshed the pipe CRC irq functions a bit
- Give them an _irq_handler postfix, like all the other irq stuff.
- Shuffle the DEBUG_FS=n dummy functions around a bit. This is prep
work to extract all the crc debug stuff into intel_display_testing.c
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 71 +
1 file changed, 37 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5c3baa0..8f7baad 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1190,10 +1190,10 @@ static void dp_aux_irq_handler(struct drm_device *dev)
}
#if defined(CONFIG_DEBUG_FS)
-static void display_pipe_crc_update(struct drm_device *dev, enum pipe pipe,
- uint32_t crc0, uint32_t crc1,
- uint32_t crc2, uint32_t crc3,
- uint32_t crc4)
+static void display_pipe_crc_irq_handler(struct drm_device *dev, enum pipe
pipe,
+uint32_t crc0, uint32_t crc1,
+uint32_t crc2, uint32_t crc3,
+uint32_t crc4)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
@@ -1227,29 +1227,37 @@ static void display_pipe_crc_update(struct drm_device
*dev, enum pipe pipe,
wake_up_interruptible(pipe_crc-wq);
}
+#else
+static inline void
+display_pipe_crc_irq_handler(struct drm_device *dev, enum pipe pipe,
+uint32_t crc0, uint32_t crc1,
+uint32_t crc2, uint32_t crc3,
+uint32_t crc4) {}
+#endif
+
-static void hsw_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+static void hsw_pipe_crc_irq_handler(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- display_pipe_crc_update(dev, pipe,
- I915_READ(PIPE_CRC_RES_1_IVB(pipe)),
- 0, 0, 0, 0);
+ display_pipe_crc_irq_handler(dev, pipe,
+I915_READ(PIPE_CRC_RES_1_IVB(pipe)),
+0, 0, 0, 0);
}
-static void ivb_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+static void ivb_pipe_crc_irq_handler(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- display_pipe_crc_update(dev, pipe,
- I915_READ(PIPE_CRC_RES_1_IVB(pipe)),
- I915_READ(PIPE_CRC_RES_2_IVB(pipe)),
- I915_READ(PIPE_CRC_RES_3_IVB(pipe)),
- I915_READ(PIPE_CRC_RES_4_IVB(pipe)),
- I915_READ(PIPE_CRC_RES_5_IVB(pipe)));
+ display_pipe_crc_irq_handler(dev, pipe,
+I915_READ(PIPE_CRC_RES_1_IVB(pipe)),
+I915_READ(PIPE_CRC_RES_2_IVB(pipe)),
+I915_READ(PIPE_CRC_RES_3_IVB(pipe)),
+I915_READ(PIPE_CRC_RES_4_IVB(pipe)),
+I915_READ(PIPE_CRC_RES_5_IVB(pipe)));
}
-static void i9xx_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+static void i9xx_pipe_crc_irq_handler(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t res1, res2;
@@ -1264,17 +1272,12 @@ static void i9xx_pipe_crc_update(struct drm_device
*dev, enum pipe pipe)
else
res2 = 0;
- display_pipe_crc_update(dev, pipe,
- I915_READ(PIPE_CRC_RES_RED(pipe)),
- I915_READ(PIPE_CRC_RES_GREEN(pipe)),
- I915_READ(PIPE_CRC_RES_BLUE(pipe)),
- res1, res2);
+ display_pipe_crc_irq_handler(dev, pipe,
+I915_READ(PIPE_CRC_RES_RED(pipe)),
+I915_READ(PIPE_CRC_RES_GREEN(pipe)),
+I915_READ(PIPE_CRC_RES_BLUE(pipe)),
+res1, res2);
}
-#else
-static inline void hsw_pipe_crc_update(struct drm_device *dev, int pipe) {}
-static inline void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
-static inline void i9xx_pipe_crc_update(struct drm_device *dev, int pipe) {}
-#endif
/* The RPS events need forcewake, so we add them to a work queue and mask their
* IMR bits until the work is done. Other interrupts can be processed without
@@ -1352,7 +1355,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
}
if (pipe_stats[pipe] PIPE_CRC_DONE_INTERRUPT_STATUS)
-
[Intel-gfx] Updated drm-intel-testing
Hi all, New -testing cycle with cool stuff: - CRC support from Damien and He Shuang. Long term this should allow us to test an awful lot modesetting corner cases automatically. So for me as the maintainer this is really big. - HDMI audio fix from Jani. - VLV dpll computation code refactoring from Ville. - Fixups for the gpu booster from last time around (Chris). - Some cleanups in the context code from Ben. - More watermark work from Ville (we'll be getting there ...). - vblank timestamp improvements from Ville. - CONFIG_FB=n support, including drm core changes to make the fbdev helpers optional. - DP link training improvements (Jani). - mmio vtable from Ben, prep work for future hw. Happy testing! Cheers, 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] [PATCH] drm/i915: print object bindings in debugfs
This is useful when we only have aliasing ppgtt and want to figure out
what exactly is accesssible and what not. Paulo can somehow overwrite
the fbcon framebuffer with the blitter on his hsw machine ...
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 061182a..e0a3b56 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -124,7 +124,9 @@ static inline const char *get_global_flag(struct
drm_i915_gem_object *obj)
static void
describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *dev_priv = obj-base.dev-dev_private;
struct i915_vma *vma;
+
seq_printf(m, %pK: %s%s%s %8zdKiB %02x %02x %u %u %u%s%s%s,
obj-base,
get_pin_flag(obj),
@@ -155,6 +157,10 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
seq_printf(m, gtt offset: %08lx, size: %08lx),
vma-node.start, vma-node.size);
}
+ if (dev_priv-mm.aliasing_ppgtt)
+ seq_pritnf( (bindings: %s%s),
+ obj-has_global_gtt_mapping ? g : ,
+ obj-has_aliasing_ppgtt_mapping ? pp : );
if (obj-stolen)
seq_printf(m, (stolen: %08lx), obj-stolen-start);
if (obj-pin_mappable || obj-fault_mappable) {
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: print object bindings in debugfs
This is useful when we only have aliasing ppgtt and want to figure out
what exactly is accesssible and what not. Paulo can somehow overwrite
the fbcon framebuffer with the blitter on his hsw machine ...
v2: Actually make it compile.
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 061182a..2272898 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -124,7 +124,9 @@ static inline const char *get_global_flag(struct
drm_i915_gem_object *obj)
static void
describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *dev_priv = obj-base.dev-dev_private;
struct i915_vma *vma;
+
seq_printf(m, %pK: %s%s%s %8zdKiB %02x %02x %u %u %u%s%s%s,
obj-base,
get_pin_flag(obj),
@@ -155,6 +157,10 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
seq_printf(m, gtt offset: %08lx, size: %08lx),
vma-node.start, vma-node.size);
}
+ if (dev_priv-mm.aliasing_ppgtt)
+ seq_printf(m, (bindings: %s%s),
+ obj-has_global_gtt_mapping ? g : ,
+ obj-has_aliasing_ppgtt_mapping ? pp : );
if (obj-stolen)
seq_printf(m, (stolen: %08lx), obj-stolen-start);
if (obj-pin_mappable || obj-fault_mappable) {
--
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: print object bindings in debugfs
On Fri, Oct 18, 2013 at 05:18:27PM +0200, Daniel Vetter wrote:
This is useful when we only have aliasing ppgtt and want to figure out
what exactly is accesssible and what not. Paulo can somehow overwrite
the fbcon framebuffer with the blitter on his hsw machine ...
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 061182a..e0a3b56 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -124,7 +124,9 @@ static inline const char *get_global_flag(struct
drm_i915_gem_object *obj)
static void
describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *dev_priv = obj-base.dev-dev_private;
struct i915_vma *vma;
+
seq_printf(m, %pK: %s%s%s %8zdKiB %02x %02x %u %u %u%s%s%s,
obj-base,
get_pin_flag(obj),
@@ -155,6 +157,10 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
seq_printf(m, gtt offset: %08lx, size: %08lx),
vma-node.start, vma-node.size);
}
+ if (dev_priv-mm.aliasing_ppgtt)
+ seq_pritnf( (bindings: %s%s),
+obj-has_global_gtt_mapping ? g : ,
+obj-has_aliasing_ppgtt_mapping ? pp : );
So we have:
...(bindings: )...
...(bindings: g)...
...(bindings: pp)...
...(bindings: gpp)...
That looks more confusing than informative atm.
-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
[Intel-gfx] [PATCH] drm/i915: preserve dispaly init order on ByT
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
This patch changes HDMI port registration order for the BayTrail platform.
The story is that in kernel version 3.11 i915 supported only one HDMI port -
the HDMIB port. So this port ended up being HDMI-1 in user-space.
But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT'
introduced HDMIC port support. And added HDMIC registration prior to HDMIB,
so HDMIB became HDMI-2 and HDMIC became HDMI-1.
Well, this is fine as far as the kernel is concerned. i915 does not give any
guarantees to the numbering, and has never given them.
However, this breaks wayland setup in Tizen IVI. We have only one single HDMI
port on our hardware, and it is connected to HDMIB. Our configuration relies on
the fact that it is HDMI-1.
Well, certainly this is user-space problem which was exposed with Jesse's
patch. However, there is a reason why we have to do this assumption - we use
touchscreen monitors and we have to associate event devices with the monitors,
and this is not easy to do dynamically, so we just have a static setup.
Anyway, while the user-space setup will have to be fixed regardless, let's
chane the HDMI port registration order so that HDMIB stays HDMI-1, just like it
was in 3.11. Simply because there is no strong reason for changing the order in
the kernel, and it'll help setups like ours in sense that we'll have more time
for fixing the issue properly.
Also amend the commentary which looks a bit out-of-date.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f1b636..3fc8ae6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9880,7 +9880,14 @@ static void intel_setup_outputs(struct drm_device *dev)
if (I915_READ(PCH_DP_D) DP_DETECTED)
intel_dp_init(dev, PCH_DP_D, PORT_D);
} else if (IS_VALLEYVIEW(dev)) {
- /* Check for built-in panel first. Shares lanes with HDMI on
SDVOC */
+ /* DP and HDMI share lanes on the SDVOC */
+ if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIB) SDVO_DETECTED) {
+ intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIB,
+ PORT_B);
+ if (I915_READ(VLV_DISPLAY_BASE + DP_B) DP_DETECTED)
+ intel_dp_init(dev, VLV_DISPLAY_BASE + DP_B,
PORT_B);
+ }
+
if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIC) SDVO_DETECTED) {
intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIC,
PORT_C);
@@ -9889,13 +9896,6 @@ static void intel_setup_outputs(struct drm_device *dev)
PORT_C);
}
- if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIB) SDVO_DETECTED) {
- intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIB,
- PORT_B);
- if (I915_READ(VLV_DISPLAY_BASE + DP_B) DP_DETECTED)
- intel_dp_init(dev, VLV_DISPLAY_BASE + DP_B,
PORT_B);
- }
-
intel_dsi_init(dev);
} else if (SUPPORTS_DIGITAL_OUTPUTS(dev)) {
bool found = false;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do hw quiescing first during unload
On Fri, Oct 18, 2013 at 10:36:30AM +0300, Ville Syrjälä wrote: On Thu, Oct 17, 2013 at 02:04:34PM -0700, Ben Widawsky wrote: On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote: On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote: On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote: If we force the hw to idle as our first step during unload, we can abort the unload upon failure. Later we can probe whether the hardware remain active even after we try to shut it down. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield what we want? It may be mean, but it seems to me to be the right thing to do if we cannot turn off the hardware to unload the driver... -Chris -- Chris Wilson, Intel Open Source Technology Centre And what about my suggestion of simply using pci_clear_master? Might that hang some boxes? Hmm, why are you thinking? -- 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: Do hw quiescing first during unload
On Fri, Oct 18, 2013 at 11:09:15AM -0700, Ben Widawsky wrote: On Fri, Oct 18, 2013 at 10:36:30AM +0300, Ville Syrjälä wrote: On Thu, Oct 17, 2013 at 02:04:34PM -0700, Ben Widawsky wrote: On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote: On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote: On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote: If we force the hw to idle as our first step during unload, we can abort the unload upon failure. Later we can probe whether the hardware remain active even after we try to shut it down. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Isn't it pretty mean to fail to unload? Wouldn't pci_clear_master yield what we want? It may be mean, but it seems to me to be the right thing to do if we cannot turn off the hardware to unload the driver... -Chris -- Chris Wilson, Intel Open Source Technology Centre And what about my suggestion of simply using pci_clear_master? Might that hang some boxes? Hmm, why are you thinking? No particular reason. Just my well honed hardware is often borked reflex. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: make the intel_display_power_domain enum compact
On Wed, 16 Oct 2013 17:25:48 +0300
Imre Deak imre.d...@intel.com wrote:
Upcoming patches will add tracking for a set of power domains via a
bitmask; to make things simple there remove the current gap in the
enum values.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2ea66f2..9b04d05 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -98,14 +98,16 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_A,
POWER_DOMAIN_TRANSCODER_B,
POWER_DOMAIN_TRANSCODER_C,
- POWER_DOMAIN_TRANSCODER_EDP = POWER_DOMAIN_TRANSCODER_A + 0xF,
+ POWER_DOMAIN_TRANSCODER_EDP,
POWER_DOMAIN_VGA,
};
#define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
#define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
-#define POWER_DOMAIN_TRANSCODER(tran) ((tran) + POWER_DOMAIN_TRANSCODER_A)
+#define POWER_DOMAIN_TRANSCODER(tran) \
+ ((tran) == TRANSCODER_EDP ? POWER_DOMAIN_TRANSCODER_EDP : \
+ (tran) + POWER_DOMAIN_TRANSCODER_A)
enum hpd_pin {
HPD_NONE = 0,
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, 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 2/6] drm/i915: factor out is_always_on_domain
On Wed, 16 Oct 2013 17:25:49 +0300
Imre Deak imre.d...@intel.com wrote:
It is just cleaner this way and makes it easier to add support for
other HW generations with always-on power wells powering a different
set of domains.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/intel_pm.c | 84
+++--
2 files changed, 38 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9b04d05..ca05f3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -100,8 +100,12 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_C,
POWER_DOMAIN_TRANSCODER_EDP,
POWER_DOMAIN_VGA,
+
+ POWER_DOMAIN_NUM,
};
+#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
+
#define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
#define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
@@ -109,6 +113,10 @@ enum intel_display_power_domain {
((tran) == TRANSCODER_EDP ? POWER_DOMAIN_TRANSCODER_EDP : \
(tran) + POWER_DOMAIN_TRANSCODER_A)
+#define HSW_ALWAYS_ON_POWER_DOMAINS (\
+ BIT(POWER_DOMAIN_PIPE_A) | \
+ BIT(POWER_DOMAIN_TRANSCODER_EDP))
+
enum hpd_pin {
HPD_NONE = 0,
HPD_PORT_A = HPD_NONE, /* PORT_A is internal */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3d3658c..57d08a2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5367,6 +5367,23 @@ void intel_suspend_hw(struct drm_device *dev)
lpt_suspend_hw(dev);
}
+static bool is_always_on_power_domain(struct drm_device *dev,
+ enum intel_display_power_domain domain)
+{
+ unsigned long always_on_domains;
+
+ BUG_ON(BIT(domain) ~POWER_DOMAIN_MASK);
+
+ if (IS_HASWELL(dev)) {
+ always_on_domains = HSW_ALWAYS_ON_POWER_DOMAINS;
+ } else {
+ WARN_ON(1);
+ return true;
+ }
+
+ return BIT(domain) always_on_domains;
+}
+
/**
* We should only use the power well if we explicitly asked the hardware to
* enable it, so check if it's enabled and also check if we've requested it
to
@@ -5380,24 +5397,11 @@ bool intel_display_power_enabled(struct drm_device
*dev,
if (!HAS_POWER_WELL(dev))
return true;
- switch (domain) {
- case POWER_DOMAIN_PIPE_A:
- case POWER_DOMAIN_TRANSCODER_EDP:
+ if (is_always_on_power_domain(dev, domain))
return true;
- case POWER_DOMAIN_VGA:
- case POWER_DOMAIN_PIPE_B:
- case POWER_DOMAIN_PIPE_C:
- case POWER_DOMAIN_PIPE_A_PANEL_FITTER:
- case POWER_DOMAIN_PIPE_B_PANEL_FITTER:
- case POWER_DOMAIN_PIPE_C_PANEL_FITTER:
- case POWER_DOMAIN_TRANSCODER_A:
- case POWER_DOMAIN_TRANSCODER_B:
- case POWER_DOMAIN_TRANSCODER_C:
- return I915_READ(HSW_PWR_WELL_DRIVER) ==
+
+ return I915_READ(HSW_PWR_WELL_DRIVER) ==
(HSW_PWR_WELL_ENABLE_REQUEST | HSW_PWR_WELL_STATE_ENABLED);
- default:
- BUG();
- }
}
static void __intel_set_power_well(struct drm_device *dev, bool enable)
@@ -5469,26 +5473,12 @@ void intel_display_power_get(struct drm_device *dev,
if (!HAS_POWER_WELL(dev))
return;
- switch (domain) {
- case POWER_DOMAIN_PIPE_A:
- case POWER_DOMAIN_TRANSCODER_EDP:
+ if (is_always_on_power_domain(dev, domain))
return;
- case POWER_DOMAIN_VGA:
- case POWER_DOMAIN_PIPE_B:
- case POWER_DOMAIN_PIPE_C:
- case POWER_DOMAIN_PIPE_A_PANEL_FITTER:
- case POWER_DOMAIN_PIPE_B_PANEL_FITTER:
- case POWER_DOMAIN_PIPE_C_PANEL_FITTER:
- case POWER_DOMAIN_TRANSCODER_A:
- case POWER_DOMAIN_TRANSCODER_B:
- case POWER_DOMAIN_TRANSCODER_C:
- spin_lock_irq(power_well-lock);
- __intel_power_well_get(power_well);
- spin_unlock_irq(power_well-lock);
- return;
- default:
- BUG();
- }
+
+ spin_lock_irq(power_well-lock);
+ __intel_power_well_get(power_well);
+ spin_unlock_irq(power_well-lock);
}
void intel_display_power_put(struct drm_device *dev,
@@ -5500,26 +5490,12 @@ void intel_display_power_put(struct drm_device *dev,
if (!HAS_POWER_WELL(dev))
return;
- switch (domain) {
- case POWER_DOMAIN_PIPE_A:
- case POWER_DOMAIN_TRANSCODER_EDP:
+ if (is_always_on_power_domain(dev, domain))
return;
- case POWER_DOMAIN_VGA:
- case POWER_DOMAIN_PIPE_B:
- case POWER_DOMAIN_PIPE_C:
- case POWER_DOMAIN_PIPE_A_PANEL_FITTER:
- case POWER_DOMAIN_PIPE_B_PANEL_FITTER:
- case
Re: [Intel-gfx] [PATCH 3/6] drm/i915: change power_well-lock to be mutex
On Wed, 16 Oct 2013 17:25:50 +0300
Imre Deak imre.d...@intel.com wrote:
There is no hard need for this to be a spin lock, as we don't take these
locks in irq context from anywhere. An upcoming patch will add calls to
punit read/write functions from within regions protected by this lock
and those functions need a mutex in turn. As a solution for that convert
the spin lock to be a mutex.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 26 +-
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ca05f3a..e4354dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -910,7 +910,7 @@ struct intel_ilk_power_mgmt {
/* Power well structure for haswell */
struct i915_power_well {
struct drm_device *device;
- spinlock_t lock;
+ struct mutex lock;
/* power well enable/disable usage count */
int count;
int i915_request;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 57d08a2..f7363a8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5476,9 +5476,9 @@ void intel_display_power_get(struct drm_device *dev,
if (is_always_on_power_domain(dev, domain))
return;
- spin_lock_irq(power_well-lock);
+ mutex_lock(power_well-lock);
__intel_power_well_get(power_well);
- spin_unlock_irq(power_well-lock);
+ mutex_unlock(power_well-lock);
}
void intel_display_power_put(struct drm_device *dev,
@@ -5493,9 +5493,9 @@ void intel_display_power_put(struct drm_device *dev,
if (is_always_on_power_domain(dev, domain))
return;
- spin_lock_irq(power_well-lock);
+ mutex_lock(power_well-lock);
__intel_power_well_put(power_well);
- spin_unlock_irq(power_well-lock);
+ mutex_unlock(power_well-lock);
}
static struct i915_power_well *hsw_pwr;
@@ -5506,9 +5506,9 @@ void i915_request_power_well(void)
if (WARN_ON(!hsw_pwr))
return;
- spin_lock_irq(hsw_pwr-lock);
+ mutex_lock(hsw_pwr-lock);
__intel_power_well_get(hsw_pwr);
- spin_unlock_irq(hsw_pwr-lock);
+ mutex_unlock(hsw_pwr-lock);
}
EXPORT_SYMBOL_GPL(i915_request_power_well);
@@ -5518,9 +5518,9 @@ void i915_release_power_well(void)
if (WARN_ON(!hsw_pwr))
return;
- spin_lock_irq(hsw_pwr-lock);
+ mutex_lock(hsw_pwr-lock);
__intel_power_well_put(hsw_pwr);
- spin_unlock_irq(hsw_pwr-lock);
+ mutex_unlock(hsw_pwr-lock);
}
EXPORT_SYMBOL_GPL(i915_release_power_well);
@@ -5531,7 +5531,7 @@ int i915_init_power_well(struct drm_device *dev)
hsw_pwr = dev_priv-power_well;
hsw_pwr-device = dev;
- spin_lock_init(hsw_pwr-lock);
+ mutex_init(hsw_pwr-lock);
hsw_pwr-count = 0;
return 0;
@@ -5553,7 +5553,7 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
if (!i915_disable_power_well !enable)
return;
- spin_lock_irq(power_well-lock);
+ mutex_lock(power_well-lock);
/*
* This function will only ever contribute one
@@ -5572,7 +5572,7 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
__intel_power_well_put(power_well);
out:
- spin_unlock_irq(power_well-lock);
+ mutex_unlock(power_well-lock);
}
static void intel_resume_power_well(struct drm_device *dev)
@@ -5583,9 +5583,9 @@ static void intel_resume_power_well(struct drm_device
*dev)
if (!HAS_POWER_WELL(dev))
return;
- spin_lock_irq(power_well-lock);
+ mutex_lock(power_well-lock);
__intel_set_power_well(dev, power_well-count 0);
- spin_unlock_irq(power_well-lock);
+ mutex_unlock(power_well-lock);
}
/*
Are there ordering requirements we should document? E.g. always take
this after the mode config lock or something?
Otherwise:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, 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 4/6] drm/i915: factor out modeset_update_power_wells
On Wed, 16 Oct 2013 17:25:51 +0300
Imre Deak imre.d...@intel.com wrote:
We'll need the same functionality for other HW generations. The support
for these will be added by upcoming patches.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b334c50..8e734f2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6561,7 +6561,7 @@ static void hsw_package_c8_gpu_busy(struct
drm_i915_private *dev_priv)
}
}
-static void haswell_modeset_global_resources(struct drm_device *dev)
+static void modeset_update_power_wells(struct drm_device *dev)
{
bool enable = false;
struct intel_crtc *crtc;
@@ -6576,7 +6576,11 @@ static void haswell_modeset_global_resources(struct
drm_device *dev)
}
intel_set_power_well(dev, enable);
+}
+static void haswell_modeset_global_resources(struct drm_device *dev)
+{
+ modeset_update_power_wells(dev);
hsw_update_package_c8(dev);
}
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, 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 6/6] drm/i915: use power get/put instead of set for power on after init
On Wed, 16 Oct 2013 17:25:53 +0300
Imre Deak imre.d...@intel.com wrote:
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.
This logic is supported by intel_set_power_well() in the power domain
framework. It would be nice to simplify the API, so that we only have
get/put functions and make it more explicit on the higher level how this
power well on during init logic works. This will make it also easier
if in the future we want to shorten the time the power wells are on.
For this add a new device private flag tracking whether we have the
power wells on because of init/suspend and use only
intel_display_power_get()/put(). As nothing else uses
intel_set_power_well() we can remove it.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 7 ++-
drivers/gpu/drm/i915/intel_display.c | 17 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 35 +--
6 files changed, 27 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b8bc887..dd7f1f6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1708,7 +1708,7 @@ int i915_driver_unload(struct drm_device *dev)
/* The i915.ko module is still not prepared to be loaded when
* the power well is not enabled, so just enable it in case
* we're going to unload/reload. */
- intel_set_power_well(dev, true);
+ intel_display_set_init_power(dev, true);
i915_remove_power_well(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59649c0..7299a96 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -469,7 +469,7 @@ static int i915_drm_freeze(struct drm_device *dev)
/* We do a lot of poking in a lot of registers, make sure they work
* properly. */
hsw_disable_package_c8(dev_priv);
- intel_set_power_well(dev, true);
+ intel_display_set_init_power(dev, true);
drm_kms_helper_poll_disable(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4354dd..0557c6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -100,6 +100,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_C,
POWER_DOMAIN_TRANSCODER_EDP,
POWER_DOMAIN_VGA,
+ POWER_DOMAIN_INIT,
POWER_DOMAIN_NUM,
};
@@ -913,7 +914,6 @@ struct i915_power_well {
struct mutex lock;
/* power well enable/disable usage count */
int count;
- int i915_request;
};
struct i915_dri1_state {
@@ -1369,6 +1369,11 @@ typedef struct drm_i915_private {
* mchdev_lock in intel_pm.c */
struct intel_ilk_power_mgmt ips;
+ /*
+ * Power wells needed for initialization at driver init and suspend
+ * time are on. They are kept on until after the first modeset.
+ */
+ bool init_power_on;
/* Haswell power well */
struct i915_power_well power_well;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e2a4f3b..e30db91 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6581,6 +6581,21 @@ static unsigned long get_pipe_power_domains(struct
drm_device *dev,
return mask;
}
+void intel_display_set_init_power(struct drm_device *dev, bool enable)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-init_power_on == enable)
+ return;
+
+ if (enable)
+ intel_display_power_get(dev, POWER_DOMAIN_INIT);
+ else
+ intel_display_power_put(dev, POWER_DOMAIN_INIT);
+
+ dev_priv-init_power_on = enable;
+}
+
static void modeset_update_power_wells(struct drm_device *dev)
{
unsigned long pipe_domains[I915_MAX_PIPES] = { 0, };
@@ -6612,6 +6627,8 @@ static void modeset_update_power_wells(struct
drm_device *dev)
crtc-enabled_power_domains = pipe_domains[crtc-pipe];
}
+
+ intel_display_set_init_power(dev, false);
}
static void haswell_modeset_global_resources(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 63a5bfd..e6306f5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -680,6 +680,7 @@ bool intel_crtc_active(struct drm_crtc *crtc);
void
[Intel-gfx] [PATCH] drm/i915: Print RC6 info less often
Since we use intel_enable_rc6() now for more than just when we're
enabling RC6, we'll see this message many times, and it is just
confusing.
As an example, calc_residency calls this function whenever poked via
sysfs. This leaves the impression in dmesg that we're constantly
re-enabling RC6.
While at it, move the defines and description from drv.h to intel_pm.c,
since these are only ever used in that code.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 21
drivers/gpu/drm/i915/intel_pm.c | 54 -
2 files changed, 43 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 701098c..76e5435 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1786,27 +1786,6 @@ struct drm_i915_file_private {
#include i915_trace.h
-/**
- * RC6 is a special power stage which allows the GPU to enter an very
- * low-voltage mode when idle, using down to 0V while at this stage. This
- * stage is entered automatically when the GPU is idle when RC6 support is
- * enabled, and as soon as new workload arises GPU wakes up automatically as
well.
- *
- * There are different RC6 modes available in Intel GPU, which differentiate
- * among each other with the latency required to enter and leave RC6 and
- * voltage consumed by the GPU in different states.
- *
- * The combination of the following flags define which states GPU is allowed
- * to enter, while RC6 is the normal RC6 state, RC6p is the deep RC6, and
- * RC6pp is deepest RC6. Their support by hardware varies according to the
- * GPU, BIOS, chipset and platform. RC6 is usually the safest one and the one
- * which brings the most power savings; deeper states save more power, but
- * require higher latency to switch to and wake up.
- */
-#define INTEL_RC6_ENABLE (10)
-#define INTEL_RC6p_ENABLE (11)
-#define INTEL_RC6pp_ENABLE (12)
-
extern const struct drm_ioctl_desc i915_ioctls[];
extern int i915_max_ioctl;
extern unsigned int i915_fbpercrtc __always_unused;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bf5261f..ca9a778 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -32,6 +32,27 @@
#include linux/module.h
#include drm/i915_powerwell.h
+/**
+ * RC6 is a special power stage which allows the GPU to enter an very
+ * low-voltage mode when idle, using down to 0V while at this stage. This
+ * stage is entered automatically when the GPU is idle when RC6 support is
+ * enabled, and as soon as new workload arises GPU wakes up automatically as
well.
+ *
+ * There are different RC6 modes available in Intel GPU, which differentiate
+ * among each other with the latency required to enter and leave RC6 and
+ * voltage consumed by the GPU in different states.
+ *
+ * The combination of the following flags define which states GPU is allowed
+ * to enter, while RC6 is the normal RC6 state, RC6p is the deep RC6, and
+ * RC6pp is deepest RC6. Their support by hardware varies according to the
+ * GPU, BIOS, chipset and platform. RC6 is usually the safest one and the one
+ * which brings the most power savings; deeper states save more power, but
+ * require higher latency to switch to and wake up.
+ */
+#define INTEL_RC6_ENABLE (10)
+#define INTEL_RC6p_ENABLE (11)
+#define INTEL_RC6pp_ENABLE (12)
+
/* FBC, or Frame Buffer Compression, is a technique employed to compress the
* framebuffer contents in-memory, aiming at reducing the required bandwidth
* during in-memory transfers and, therefore, reduce the power packet.
@@ -3685,6 +3706,20 @@ static void valleyview_disable_rps(struct drm_device
*dev)
}
}
+static void intel_print_rc6_info(struct drm_device *dev, u32 mode)
+{
+ if (IS_GEN6(dev))
+ DRM_DEBUG_DRIVER(Sandybridge: deep RC6 disabled\n);
+
+ if (IS_HASWELL(dev))
+ DRM_DEBUG_DRIVER(Haswell: only RC6 available\n);
+
+ DRM_INFO(Enabling RC6 states: RC6 %s, RC6p %s, RC6pp %s\n,
+ (mode GEN6_RC_CTL_RC6_ENABLE) ? on : off,
+ (mode GEN6_RC_CTL_RC6p_ENABLE) ? on : off,
+ (mode GEN6_RC_CTL_RC6pp_ENABLE) ? on : off);
+}
+
int intel_enable_rc6(const struct drm_device *dev)
{
/* No RC6 before Ironlake */
@@ -3699,18 +3734,13 @@ int intel_enable_rc6(const struct drm_device *dev)
if (INTEL_INFO(dev)-gen == 5)
return 0;
- if (IS_HASWELL(dev)) {
- DRM_DEBUG_DRIVER(Haswell: only RC6 available\n);
+ if (IS_HASWELL(dev))
return INTEL_RC6_ENABLE;
- }
/* snb/ivb have more than one rc6 state. */
- if (INTEL_INFO(dev)-gen == 6) {
- DRM_DEBUG_DRIVER(Sandybridge: deep RC6
Re: [Intel-gfx] [PATCH] drm/i915: print object bindings in debugfs
On Fri, Oct 18, 2013 at 05:33:52PM +0100, Chris Wilson wrote:
On Fri, Oct 18, 2013 at 05:18:27PM +0200, Daniel Vetter wrote:
This is useful when we only have aliasing ppgtt and want to figure out
what exactly is accesssible and what not. Paulo can somehow overwrite
the fbcon framebuffer with the blitter on his hsw machine ...
Cc: Paulo Zanoni przan...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 061182a..e0a3b56 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -124,7 +124,9 @@ static inline const char *get_global_flag(struct
drm_i915_gem_object *obj)
static void
describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *dev_priv = obj-base.dev-dev_private;
struct i915_vma *vma;
+
seq_printf(m, %pK: %s%s%s %8zdKiB %02x %02x %u %u %u%s%s%s,
obj-base,
get_pin_flag(obj),
@@ -155,6 +157,10 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
seq_printf(m, gtt offset: %08lx, size: %08lx),
vma-node.start, vma-node.size);
}
+ if (dev_priv-mm.aliasing_ppgtt)
+ seq_pritnf( (bindings: %s%s),
+ obj-has_global_gtt_mapping ? g : ,
+ obj-has_aliasing_ppgtt_mapping ? pp : );
So we have:
...(bindings: )...
...(bindings: g)...
...(bindings: pp)...
...(bindings: gpp)...
That looks more confusing than informative atm.
-Chris
This is why I opted to leave just 'g' in get_global_flag. A lack of a g
inplies ppgtt. Also fwiw, this info is already there unless I didn't
follow what you did:
list_for_each_entry(vma, obj-vma_list, vma_link) {
if (!i915_is_ggtt(vma-vm))
seq_puts(m, (pp);
else
seq_puts(m, (g);
seq_printf(m, gtt offset: %08lx, size: %08lx),
vma-node.start, vma-node.size);
}
--
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] drm/i915: fix open-coded DIV_ROUND_UP
From: Paulo Zanoni paulo.r.zan...@intel.com
Use the nice Kernel macro, it makes the code much more readable.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 34df59b..e7b39d7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -261,7 +261,7 @@ i915_gem_dumb_create(struct drm_file *file,
struct drm_mode_create_dumb *args)
{
/* have to work out size/pitch and return them */
- args-pitch = ALIGN(args-width * ((args-bpp + 7) / 8), 64);
+ args-pitch = ALIGN(args-width * DIV_ROUND_UP(args-bpp, 8), 64);
args-size = args-pitch * args-height;
return i915_gem_create(file, dev,
args-size, args-handle);
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index acc8395..895fcb4 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -78,8 +78,8 @@ static int intelfb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes-surface_width;
mode_cmd.height = sizes-surface_height;
- mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((sizes-surface_bpp + 7) /
- 8), 64);
+ mode_cmd.pitches[0] = ALIGN(mode_cmd.width *
+ DIV_ROUND_UP(sizes-surface_bpp, 8), 64);
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes-surface_bpp,
sizes-surface_depth);
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
