Re: [Intel-gfx] [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote: I've just tracked down and fixed an bug which can lead to a hard-hang in the crtc restore code (which is used both in the lid handler when opening and on resume). If you could please test this patch (on top of drm-intel-nightly): https://patchwork.kernel.org/patch/2428971/ Now I can confirm this works fine, with no warnings, errors, or freezes. Thanks, Richard ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [3.4.y, 3.5.y] drm/i915: Use the correct size of the GTT for placing the per-process entries
Hi Greg, Please consider 9a0f938bde74 drm/i915: Use the correct size of the GTT for placing the per-process entries, 2012-08-24 for application to the 3.4.y tree. Without this patch, Geoff Crompton's iMac hits a BUG during bootup. The problem is reproducible on * Debian's 3.2.y-based kernel with drm backported from 3.4.37 * a Debian kernel close to 3.4.4 * a Debian kernel close to 3.5.5 * vanilla 3.4.4 He is not able to reproduce the problem on * Debian's older 3.2.y-based kernels without the 3.4.y drm backport * a Debian kernel close to 3.6.4; various newer kernels * vanilla 3.4.4 + this patch The patch was applied upstream during the 3.6-rc4 cycle, so newer kernels don't need it. http://bugs.debian.org/703468 has details, including a screenshot of the boot failure (unable to handling kernel paging request at c9000b7ff000 in i915_gem_init_ppgtt). Thoughts welcome, as always. Regards, Jonathan ___ 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: Fixup Oops in the pipe config computation
On Thu, Apr 11, 2013 at 11:09:00PM +0200, Daniel Vetter wrote: On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote: Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. This time things blew up when restoring modes in the switchless resume code - intel_modeset_affected_pipes figured out that pipe 2 should be restored, but since pipe 1 was disabled there was no mode nor fb when trying to restore the first crtc. Hilarity ensued and broke resume on my i945gme machine since the pipe_config_set_bpp added in commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw fell over the lack of an fb. Fix this mess by now by justing shunting all the cool new global modeset logic in intel_modeset_affected_pipes. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Potentially the same bug reported against 3.8.1: Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 Cc: sta...@vger.kernel.org References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html Tested-by: Richard Cochran richardcoch...@gmail.com --- drivers/gpu/drm/i915/intel_display.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f60493b..58c6bb6 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7629,6 +7629,10 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes, /* ... and mask these out. */ *modeset_pipes = ~(*disable_pipes); *prepare_pipes = ~(*disable_pipes); + + /* HACK: We don't (yet) fully support global modesets. */ + *modeset_pipes = 1 intel_crtc-pipe; + *prepare_pipes = 1 intel_crtc-pipe; } static bool intel_crtc_in_use(struct drm_crtc *crtc) -- 1.7.10.4 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: shorten debugfs output simple attributes
commit 647416f9eefe7699754b01b9fc82758fde83248c
Author: Kees Cook keesc...@chromium.org
Date: Sun Mar 10 14:10:06 2013 -0700
drm/i915: use simple attribute in debugfs routines
made i915_next_seqno debugfs entry to crop it's output
if returned value was large enough. Using simple_attr
will limit the output to 24 bytes.
Fix is to strip out preamples on all simple attributes
that have one.
v2: Fix all simple attributes (Daniel Vetter)
Cc: Kees Cook keesc...@chromium.org
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index be88532..7e60bb5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -901,7 +901,7 @@ i915_next_seqno_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
i915_next_seqno_get, i915_next_seqno_set,
- next_seqno : 0x%llx\n);
+ 0x%llx\n);
static int i915_rstdby_delays(struct seq_file *m, void *unused)
{
@@ -1687,7 +1687,7 @@ i915_wedged_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(i915_wedged_fops,
i915_wedged_get, i915_wedged_set,
- wedged : %llu\n);
+ %llu\n);
static int
i915_ring_stop_get(void *data, u64 *val)
@@ -1841,7 +1841,7 @@ i915_max_freq_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(i915_max_freq_fops,
i915_max_freq_get, i915_max_freq_set,
- max freq: %llu\n);
+ %llu\n);
static int
i915_min_freq_get(void *data, u64 *val)
@@ -1892,7 +1892,7 @@ i915_min_freq_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
i915_min_freq_get, i915_min_freq_set,
- min freq: %llu\n);
+ %llu\n);
static int
i915_cache_sharing_get(void *data, u64 *val)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: shorten i915_next_seqno debugfs output
Kees Cook keesc...@chromium.org writes: On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala mika.kuopp...@linux.intel.com wrote: Kees Cook keesc...@chromium.org writes: On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala mika.kuopp...@linux.intel.com wrote: commit 647416f9eefe7699754b01b9fc82758fde83248c Author: Kees Cook keesc...@chromium.org Date: Sun Mar 10 14:10:06 2013 -0700 drm/i915: use simple attribute in debugfs routines made i915_next_seqno debugfs entry to crop it's output if returned value was large enough. Using simple_attr will limit the output to 24 bytes. Fix this by returning only the value and nothing else. Cc: Kees Cook keesc...@chromium.org Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com Oh! Thanks for catching that. What a weird limitation. What about max freq, min freq, and wedged? Do those run the risk of truncation too? max and min freq should be safe, and wedged too on 32bit platforms. But if gpu is declared wedged on host with 64bit atomic_t, it will crop the output. Should we consider proposing an increase in the size of the simple attr buffer? It seems silly to provide an arbitrary format string but leave the buffer so small. That or dynamic allocation to attr-get_buf. But that would need extra pass with snprintf and I don't know if that qualifies as 'simple' anymore. I have posted a patch which fixes all i915 debugfs simple attributes to fit into the simple_attr by removing everything except the fmt to value. I didn't find any testcases which would rely on preample being there. --Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use drm_mm for PPGTT PDEs
On Thu, Apr 11, 2013 at 08:36:26AM -0700, Ben Widawsky wrote: On Thu, Apr 11, 2013 at 07:10:50AM +0100, Chris Wilson wrote: On Wed, Apr 10, 2013 at 07:43:39PM -0700, Ben Widawsky wrote: I think this is a nice generalization on it's own, but it's primarily prep work for my PPGTT support. Does this bother anyone? The only down side I can see is we waste 2k of cpu unmappable space (unless we have something else that is = 2k and doesn't need to be page aligned). It's RFC because I have only hacked this up and haven't thoroughly tested a bunch of error and suspend/resume paths. Ugh. Fragmentation, you need a top down allocator. -Chris For the current case we can easily address this by setting the range to be the old range and keep the existing allocator but limit it to the same portion it used before. This isn't very interesting though and the previous code is probably better suited for this case anyway since it's inherently much more robust against accidentally overwriting the PDEs. As discussed, my concern here is that we are limiting the maximum object size by placing very long lived and unmovable objects right in the middle of the GTT. Would you agree that on GEN7 + multiple PPGTTs; the fragmentation is a don't care? Yes. Given true ppggt, then we mostly only care about fragmentation in the mappable region. -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/7] drm/i915: Fixup Oops in the pipe config computation
On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote: Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. This time things blew up when restoring modes in the switchless resume code - intel_modeset_affected_pipes figured out that pipe 2 should be restored, but since pipe 1 was disabled there was no mode nor fb when trying to restore the first crtc. Hilarity ensued and broke resume on my i945gme machine since the pipe_config_set_bpp added in I can see how the hack works, but I'm not clear on how we got into the situation of trying to enable multiple pipes in the first place. Do you mind expanding upon the failure conditions a bit more? -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 3/4] drm/i915: ensure single initialization and cleanup of backlight device
Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.
A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |3 +++
drivers/gpu/drm/i915/intel_dp.c |5 +
drivers/gpu/drm/i915/intel_lvds.c|1 -
drivers/gpu/drm/i915/intel_panel.c |7 ++-
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 457a0a0..712b0af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9419,6 +9419,9 @@ void intel_modeset_cleanup(struct drm_device *dev)
/* flush any delayed tasks or pending work */
flush_scheduled_work();
+ /* destroy backlight, if any, before the connectors */
+ intel_panel_destroy_backlight(dev);
+
drm_mode_config_cleanup(dev);
intel_cleanup_overlay(dev);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 173add1..8845e82 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2474,17 +2474,14 @@ done:
static void
intel_dp_destroy(struct drm_connector *connector)
{
- struct drm_device *dev = connector-dev;
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_connector *intel_connector = to_intel_connector(connector);
if (!IS_ERR_OR_NULL(intel_connector-edid))
kfree(intel_connector-edid);
- if (is_edp(intel_dp)) {
- intel_panel_destroy_backlight(dev);
+ if (is_edp(intel_dp))
intel_panel_fini(intel_connector-panel);
- }
drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index ca2d903..f36f1ba 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -631,7 +631,6 @@ static void intel_lvds_destroy(struct drm_connector
*connector)
if (!IS_ERR_OR_NULL(lvds_connector-base.edid))
kfree(lvds_connector-base.edid);
- intel_panel_destroy_backlight(connector-dev);
intel_panel_fini(lvds_connector-base.panel);
drm_sysfs_connector_remove(connector);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 464c3d7..5d3e9d7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -459,6 +459,9 @@ int intel_panel_setup_backlight(struct drm_connector
*connector)
intel_panel_init_backlight(dev);
+ if (WARN_ON(dev_priv-backlight.device))
+ return -ENODEV;
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.brightness = dev_priv-backlight.level;
@@ -488,8 +491,10 @@ int intel_panel_setup_backlight(struct drm_connector
*connector)
void intel_panel_destroy_backlight(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (dev_priv-backlight.device)
+ if (dev_priv-backlight.device) {
backlight_device_unregister(dev_priv-backlight.device);
+ dev_priv-backlight.device = NULL;
+ }
}
#else
int intel_panel_setup_backlight(struct drm_connector *connector)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: hsw backlight registers need transcoder instead of pipe
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_panel.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 5d3e9d7..0362f5c 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -344,6 +344,8 @@ void intel_panel_enable_backlight(struct drm_device *dev,
enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ enum transcoder cpu_transcoder =
+ intel_pipe_to_cpu_transcoder(dev_priv, pipe);
unsigned long flags;
spin_lock_irqsave(dev_priv-backlight.lock, flags);
@@ -374,7 +376,7 @@ void intel_panel_enable_backlight(struct drm_device *dev,
else
tmp = ~BLM_PIPE_SELECT;
- tmp |= BLM_PIPE(pipe);
+ tmp |= BLM_PIPE(cpu_transcoder);
tmp = ~BLM_PWM_ENABLE;
I915_WRITE(reg, tmp);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm/i915: backlight locking, cleanup
Patches 1-2 are for locking, 3-4 are related only by being backlight fixes. I haven't tested these much... BR, Jani. Jani Nikula (4): drm/i915: keep max backlight internal to intel_panel.c drm/i915: protect backlight registers and data with a spinlock drm/i915: ensure single initialization and cleanup of backlight device drm/i915: hsw backlight registers need transcoder instead of pipe drivers/gpu/drm/i915/i915_dma.c |1 + drivers/gpu/drm/i915/i915_drv.h |1 + drivers/gpu/drm/i915/i915_suspend.c | 10 drivers/gpu/drm/i915/intel_display.c |3 ++ drivers/gpu/drm/i915/intel_dp.c |5 +- drivers/gpu/drm/i915/intel_drv.h |4 +- drivers/gpu/drm/i915/intel_lvds.c |1 - drivers/gpu/drm/i915/intel_opregion.c |4 +- drivers/gpu/drm/i915/intel_panel.c| 90 - 9 files changed, 85 insertions(+), 34 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: keep max backlight internal to intel_panel.c
In preparation of adding locking to backlight, make max backlight value
(the modulation frequency the PWM duty cycle value must not exceed)
internal to intel_panel.c.
Have intel_panel_set_backlight() accept a caller defined range for level,
and scale input to max backlight value internally.
Clean up intel_panel_get_max_backlight() and usage internally.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_drv.h |4 +--
drivers/gpu/drm/i915/intel_opregion.c |4 +--
drivers/gpu/drm/i915/intel_panel.c| 51 +++--
3 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..d2238d1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -520,8 +520,8 @@ extern void intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
-extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
-extern void intel_panel_set_backlight(struct drm_device *dev, u32 level);
+extern void intel_panel_set_backlight(struct drm_device *dev,
+ u32 level, u32 max);
extern int intel_panel_setup_backlight(struct drm_connector *connector);
extern void intel_panel_enable_backlight(struct drm_device *dev,
enum pipe pipe);
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 4d33874..42faa58 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -152,7 +152,6 @@ static u32 asle_set_backlight(struct drm_device *dev, u32
bclp)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct opregion_asle __iomem *asle = dev_priv-opregion.asle;
- u32 max;
DRM_DEBUG_DRIVER(bclp = 0x%08x\n, bclp);
@@ -163,8 +162,7 @@ static u32 asle_set_backlight(struct drm_device *dev, u32
bclp)
if (bclp 255)
return ASLE_BACKLIGHT_FAILED;
- max = intel_panel_get_max_backlight(dev);
- intel_panel_set_backlight(dev, bclp * max / 255);
+ intel_panel_set_backlight(dev, bclp, 255);
iowrite32((bclp*0x64)/0xff | ASLE_CBLV_VALID, asle-cblv);
return 0;
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 7874cec..acab67c 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -130,6 +130,9 @@ static int is_backlight_combination_mode(struct drm_device
*dev)
return 0;
}
+/* XXX: query mode clock or hardware clock and program max PWM appropriately
+ * when it's 0.
+ */
static u32 i915_read_blc_pwm_ctl(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -164,7 +167,7 @@ static u32 i915_read_blc_pwm_ctl(struct drm_device *dev)
return val;
}
-static u32 _intel_panel_get_max_backlight(struct drm_device *dev)
+static u32 intel_panel_get_max_backlight(struct drm_device *dev)
{
u32 max;
@@ -182,23 +185,8 @@ static u32 _intel_panel_get_max_backlight(struct
drm_device *dev)
max *= 0xff;
}
- return max;
-}
-
-u32 intel_panel_get_max_backlight(struct drm_device *dev)
-{
- u32 max;
-
- max = _intel_panel_get_max_backlight(dev);
- if (max == 0) {
- /* XXX add code here to query mode clock or hardware clock
-* and program max PWM appropriately.
-*/
- pr_warn_once(fixme: max PWM is zero\n);
- return 1;
- }
-
DRM_DEBUG_DRIVER(max backlight PWM = %d\n, max);
+
return max;
}
@@ -217,8 +205,11 @@ static u32 intel_panel_compute_brightness(struct
drm_device *dev, u32 val)
return val;
if (i915_panel_invert_brightness 0 ||
- dev_priv-quirks QUIRK_INVERT_BRIGHTNESS)
- return intel_panel_get_max_backlight(dev) - val;
+ dev_priv-quirks QUIRK_INVERT_BRIGHTNESS) {
+ u32 max = intel_panel_get_max_backlight(dev);
+ if (max)
+ return max - val;
+ }
return val;
}
@@ -270,6 +261,10 @@ static void intel_panel_actually_set_backlight(struct
drm_device *dev, u32 level
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;
+ /* we're screwed, but keep behaviour backwards compatible */
+ if (!max)
+ max = 1;
+
lbpc = level * 0xfe / max + 1;
level /= lbpc;
pci_write_config_byte(dev-pdev, PCI_LBPC, lbpc);
@@ -282,9 +277,20 @@ static void intel_panel_actually_set_backlight(struct
drm_device *dev, u32 level
[Intel-gfx] [PATCH 2/4] drm/i915: protect backlight registers and data with a spinlock
Backlight data and registers are fiddled through LVDS/eDP modeset
enable/disable hooks, backlight sysfs files, asle interrupts, and register
save/restore. Protect the backlight related registers and driver private
fields using a spinlock.
The locking in register save/restore covers a little more than is strictly
necessary, including non-modeset case, for simplicity.
v2: Cover register access, save/restore, i915_read_blc_pwm_ctl() and code
paths leading there.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c |1 +
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_suspend.c | 10 ++
drivers/gpu/drm/i915/intel_panel.c | 30 +-
4 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3b315ba..7751660 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1629,6 +1629,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
spin_lock_init(dev_priv-irq_lock);
spin_lock_init(dev_priv-gpu_error.lock);
spin_lock_init(dev_priv-rps.lock);
+ spin_lock_init(dev_priv-backlight.lock);
mutex_init(dev_priv-dpio_lock);
mutex_init(dev_priv-rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b5a495a..9aa9d60 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -952,6 +952,7 @@ typedef struct drm_i915_private {
struct {
int level;
bool enabled;
+ spinlock_t lock; /* bl registers and the above bl fields */
struct backlight_device *device;
} backlight;
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 41f0fde..88b9a66 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -192,6 +192,7 @@ static void i915_restore_vga(struct drm_device *dev)
static void i915_save_display(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long flags;
/* Display arbitration control */
if (INTEL_INFO(dev)-gen = 4)
@@ -202,6 +203,8 @@ static void i915_save_display(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_save_display_reg(dev);
+ spin_lock_irqsave(dev_priv-backlight.lock, flags);
+
/* LVDS state */
if (HAS_PCH_SPLIT(dev)) {
dev_priv-regfile.savePP_CONTROL = I915_READ(PCH_PP_CONTROL);
@@ -222,6 +225,8 @@ static void i915_save_display(struct drm_device *dev)
dev_priv-regfile.saveLVDS = I915_READ(LVDS);
}
+ spin_unlock_irqrestore(dev_priv-backlight.lock, flags);
+
if (!IS_I830(dev) !IS_845G(dev) !HAS_PCH_SPLIT(dev))
dev_priv-regfile.savePFIT_CONTROL = I915_READ(PFIT_CONTROL);
@@ -257,6 +262,7 @@ static void i915_restore_display(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
u32 mask = 0x;
+ unsigned long flags;
/* Display arbitration */
if (INTEL_INFO(dev)-gen = 4)
@@ -265,6 +271,8 @@ static void i915_restore_display(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_restore_display_reg(dev);
+ spin_lock_irqsave(dev_priv-backlight.lock, flags);
+
/* LVDS state */
if (INTEL_INFO(dev)-gen = 4 !HAS_PCH_SPLIT(dev))
I915_WRITE(BLC_PWM_CTL2, dev_priv-regfile.saveBLC_PWM_CTL2);
@@ -304,6 +312,8 @@ static void i915_restore_display(struct drm_device *dev)
I915_WRITE(PP_CONTROL, dev_priv-regfile.savePP_CONTROL);
}
+ spin_unlock_irqrestore(dev_priv-backlight.lock, flags);
+
/* only restore FBC info on the platform that supports FBC*/
intel_disable_fbc(dev);
if (I915_HAS_FBC(dev)) {
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index acab67c..464c3d7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -138,6 +138,8 @@ static u32 i915_read_blc_pwm_ctl(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 val;
+ WARN_ON(!spin_is_locked(dev_priv-backlight.lock));
+
/* Restore the CTL value if it lost, e.g. GPU reset */
if (HAS_PCH_SPLIT(dev_priv-dev)) {
@@ -218,6 +220,9 @@ static u32 intel_panel_get_backlight(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
u32 val;
+ unsigned long flags;
+
+ spin_lock_irqsave(dev_priv-backlight.lock, flags);
if (HAS_PCH_SPLIT(dev)) {
val = I915_READ(BLC_PWM_CPU_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
@@ -235,6 +240,9 @@ static
[Intel-gfx] [PATCH 3/3] drm/i915: drop code duplication in favor of asle interrupt handler
With the previous work asle and gse interrupt handlers should now be
functionally the same. Drop the duplicated code.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_irq.c |4 ++--
drivers/gpu/drm/i915/intel_opregion.c | 37 -
3 files changed, 2 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b5a495a..aec9377 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1810,7 +1810,6 @@ extern int intel_opregion_setup(struct drm_device *dev);
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 void intel_opregion_gse_intr(struct drm_device *dev);
extern void intel_opregion_enable_asle(struct drm_device *dev);
#else
static inline void intel_opregion_init(struct drm_device *dev) { return; }
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e97bbb2..269f1a1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -792,7 +792,7 @@ static irqreturn_t ivybridge_irq_handler(int irq, void *arg)
dp_aux_irq_handler(dev);
if (de_iir DE_GSE_IVB)
- intel_opregion_gse_intr(dev);
+ intel_opregion_asle_intr(dev);
for (i = 0; i 3; i++) {
if (de_iir (DE_PIPEA_VBLANK_IVB (5 * i)))
@@ -886,7 +886,7 @@ static irqreturn_t ironlake_irq_handler(int irq, void *arg)
dp_aux_irq_handler(dev);
if (de_iir DE_GSE)
- intel_opregion_gse_intr(dev);
+ intel_opregion_asle_intr(dev);
if (de_iir DE_PIPEA_VBLANK)
drm_handle_vblank(dev, 0);
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index c3a288e..3e22cea 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -224,43 +224,6 @@ void intel_opregion_asle_intr(struct drm_device *dev)
iowrite32(asle_stat, asle-aslc);
}
-void intel_opregion_gse_intr(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct opregion_asle __iomem *asle = dev_priv-opregion.asle;
- u32 asle_stat = 0;
- u32 asle_req;
-
- if (!asle)
- return;
-
- asle_req = ioread32(asle-aslc) ASLE_REQ_MSK;
-
- if (!asle_req) {
- DRM_DEBUG_DRIVER(non asle set request??\n);
- return;
- }
-
- if (asle_req ASLE_SET_ALS_ILLUM) {
- DRM_DEBUG_DRIVER(Illum is not supported\n);
- asle_stat |= ASLE_ALS_ILLUM_FAILED;
- }
-
- if (asle_req ASLE_SET_BACKLIGHT)
- asle_stat |= asle_set_backlight(dev, ioread32(asle-bclp));
-
- if (asle_req ASLE_SET_PFIT) {
- DRM_DEBUG_DRIVER(Pfit is not supported\n);
- asle_stat |= ASLE_PFIT_FAILED;
- }
-
- if (asle_req ASLE_SET_PWM_FREQ) {
- DRM_DEBUG_DRIVER(PWM freq is not supported\n);
- asle_stat |= ASLE_PWM_FREQ_FAILED;
- }
-
- iowrite32(asle_stat, asle-aslc);
-}
#define ASLE_ALS_EN(10)
#define ASLE_BLC_EN(11)
#define ASLE_PFIT_EN (12)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915: opregion cleanup
There's still stuff to do on opregion cleanup, but here are some potentially risky and/or controversial ones... Jani Nikula (3): drm/i915: don't pretend we support ASLE ALS, PFIT, or PFMB drm/i915/opregion: don't pretend we did something when we didn't drm/i915: drop code duplication in favor of asle interrupt handler drivers/gpu/drm/i915/i915_drv.h |1 - drivers/gpu/drm/i915/i915_irq.c |4 +-- drivers/gpu/drm/i915/intel_opregion.c | 60 - 3 files changed, 9 insertions(+), 56 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/opregion: don't pretend we did something when we didn't
In theory, the BIOS should not even request these from us now that we
aren't claiming we support these, but when it does anyway, don't pretend it
succeeded. It should be the right thing to do, but might confuse the BIOS.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_opregion.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index a622fd0..c3a288e 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -174,29 +174,22 @@ static u32 asle_set_als_illum(struct drm_device *dev, u32
alsi)
{
/* alsi is the current ALS reading in lux. 0 indicates below sensor
range, 0x indicates above sensor range. 1-0xfffe are valid */
- return 0;
+ DRM_DEBUG_DRIVER(Illum is not supported\n);
+ return ASLE_ALS_ILLUM_FAILED;
}
static u32 asle_set_pwm_freq(struct drm_device *dev, u32 pfmb)
{
- struct drm_i915_private *dev_priv = dev-dev_private;
- if (pfmb ASLE_PFMB_PWM_VALID) {
- u32 blc_pwm_ctl = I915_READ(BLC_PWM_CTL);
- u32 pwm = pfmb ASLE_PFMB_PWM_MASK;
- blc_pwm_ctl = BACKLIGHT_DUTY_CYCLE_MASK;
- pwm = pwm 9;
- /* FIXME - what do we do with the PWM? */
- }
- return 0;
+ DRM_DEBUG_DRIVER(PWM freq is not supported\n);
+ return ASLE_PWM_FREQ_FAILED;
}
static u32 asle_set_pfit(struct drm_device *dev, u32 pfit)
{
/* Panel fitting is currently controlled by the X code, so this is a
noop until modesetting support works fully */
- if (!(pfit ASLE_PFIT_VALID))
- return ASLE_PFIT_FAILED;
- return 0;
+ DRM_DEBUG_DRIVER(Pfit is not supported\n);
+ return ASLE_PFIT_FAILED;
}
void intel_opregion_asle_intr(struct drm_device *dev)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: don't pretend we support ASLE ALS, PFIT, or PFMB
In theory, this should prevent the BIOS from requesting them from us, and this should be the right thing. In practice, this is not always the case, and might surprise the BIOS. Signed-off-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/i915/intel_opregion.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index 4d33874..a622fd0 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -282,9 +282,7 @@ void intel_opregion_enable_asle(struct drm_device *dev) if (IS_MOBILE(dev)) intel_enable_asle(dev); - iowrite32(ASLE_ALS_EN | ASLE_BLC_EN | ASLE_PFIT_EN | - ASLE_PFMB_EN, - asle-tche); + iowrite32(ASLE_BLC_EN, asle-tche); iowrite32(1, asle-ardy); } } -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: keep max backlight internal to intel_panel.c
On Fri, Apr 12, 2013 at 03:18:36PM +0300, Jani Nikula wrote: In preparation of adding locking to backlight, make max backlight value (the modulation frequency the PWM duty cycle value must not exceed) internal to intel_panel.c. Have intel_panel_set_backlight() accept a caller defined range for level, and scale input to max backlight value internally. Clean up intel_panel_get_max_backlight() and usage internally. Signed-off-by: Jani Nikula jani.nik...@intel.com Nice idea, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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 3/7] drm/i915: Fixup pfit disabling for gen2/3
On Thu, Apr 11, 2013 at 04:29:06PM +0200, Daniel Vetter wrote: The recent rework of the pfit handling didn't take into account that the panel fitter is fixed to pipe B: commit 24a1f16de97c4cf0029d9acd04be06db32208726 Author: Mika Kuoppala mika.kuopp...@linux.intel.com Date: Fri Feb 8 16:35:37 2013 +0200 drm/i915: disable shared panel fitter for pipe Fix this up by properly computing the pipe the pfit is on. Also extract the logic into its own function, add a debug assert to check that the pipe is off (mostly just documentation) and add some debug output. If pipe A was disabled after pipe B was set up, the panel fitter will be disabled. Now most userspace doesn't do modesets in this order, which is why I couldn't ever reproduce this and why it took me so long to figure out. We really need hw state readout and check support for the pannel fitter ... Reported-by: Hans de Bruin jmdebr...@xmsnet.nl Cc: Mika Kuoppala mika.kuopp...@intel.com Cc: Hans de Bruin jmdebr...@xmsnet.nl References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19049 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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 7/7] drm/i915: add i9xx pfit pipe asserts
On Thu, Apr 11, 2013 at 04:29:10PM +0200, Daniel Vetter wrote: We can only enable the pfit if the pipe. Ensure that this is obied with a neat assert. Also check whether the pfit is off before enabling it - if not we've lost track of things somewhere since the pfit is only ever used by the lvds output. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Ignoring the pedants picking over the changelog, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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 6/7] drm/i915: add pipe asserts for the crtc enable sequence
On Thu, Apr 11, 2013 at 04:29:09PM +0200, Daniel Vetter wrote: The i9xx modeset sequence is currently pretty fishy, so tight it all up with some good assert-sprinkling. We already have good coverage on the disable side, but the enable side is spotty (since until recently it was wrong). Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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 5/7] drm/i915: drop redundant vblank waits
On Thu, Apr 11, 2013 at 04:29:08PM +0200, Daniel Vetter wrote: Just blows through 50ms for naught, since the pipe is off. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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 4/7] drm/i915: don't enable the plane too early in i9xx_crtc_mode_set
On Thu, Apr 11, 2013 at 04:29:07PM +0200, Daniel Vetter wrote: This is horrible lore and we should be able to get rid of it now that the lvds/pfit handling code actually does the right thing. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch I'd prefer 4 5 squashed, specially as 5 will then introduce a WARN, but Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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] slow x11 after upgrade
Thanks for concrete answer. I rebuilt my xf86-video-intel driver with glamor, SNA and UXA support enabled but unfortunately it did not help. My 815 E chipset still works slow. I think it is because glamor, SNA and UXA does not support my chipset, right ? If so, is it going to be supported in the future or this chipset is just to old. thanks for an answer On Fri, Apr 5, 2013 at 5:20 PM, Chris Wilson ch...@chris-wilson.co.ukwrote: On Fri, Apr 05, 2013 at 05:07:07PM +0200, j j wrote: I performed an update very carefully. I did all the steps suggested by gentoo packages and quot;eselect newsquot;. I rebuild xf86-video-intel and most probably turned on what is required in the kernel. My video hardware is intel (815 E) on board chipset. I use fluxbox as window manager. And now more details about the system before upgrade and after upgrade. I upgrade my system twice a year. Previously I upgraded it in summer 2012 and now I upgraded it at the beginning of 2013. The details of the system after summer 2012 upgrade are as follows: kernel: 3.2.21-gentoo (genkernel) xorg-server: 1.12.2 xorg-x11: 7.4-r2 xf86-video-intel: 2.19.0 (use flags: dri -glamor -sna) fluxbox: 1.0.0-r2 The details of the system after 2013 upgrade are as follows: kernel: 3.5.7-gentoo xorg-server: 1.13.1 xorg-x11: 7.4-r2 xf86-video-intel: 2.20.13 (use flags: dri sna udev -glamor -uxa -xvmc) fluxbox: 1.3.2 The update to xorg-server 1.13 dropped XAA support so your i815 is no longer accelerated (except for DRI and Xv iirc). -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] slow x11 after upgrade
On Fri, Apr 12, 2013 at 04:13:47PM +0200, j j wrote: Thanks for concrete answer. I rebuilt my xf86-video-intel driver with glamor, SNA and UXA support enabled but unfortunately it did not help. My quot;815 Equot; chipset still works slow. I think it is because glamor, SNA and UXA does not support my chipset, right ? Right, the modern drivers are dependent upon having KMS and GEM in the kernel. In comparison, supporting a gen1 backend in the DDX is trivial. If so, is it going to be supported in the future or this chipset is just to old. There's no incentive in Intel for supporting 81x, but both Daniel and myself have muttered that we should jfdi. As I have no 81x hw, you are welcome to do the KMS port... To reiterate, you need to downgrade Xorg (xorg-xserver) to restore XAA support for your chipset. -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/7] drm/i915: Fixup Oops in the pipe config computation
On Fri, Apr 12, 2013 at 11:46 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Thu, Apr 11, 2013 at 04:29:05PM +0200, Daniel Vetter wrote: Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. This time things blew up when restoring modes in the switchless resume code - intel_modeset_affected_pipes figured out that pipe 2 should be restored, but since pipe 1 was disabled there was no mode nor fb when trying to restore the first crtc. Hilarity ensued and broke resume on my i945gme machine since the pipe_config_set_bpp added in I can see how the hack works, but I'm not clear on how we got into the situation of trying to enable multiple pipes in the first place. Do you mind expanding upon the failure conditions a bit more? Yeah, that's worth spilling a few words ;-) So the issue is that intel_set_mode essentially already does a global modeset: intel_modeset_affected_pipes compares the current state with where we want to go to (which is carefully set up by intel_crtc_set_config) and then goes through the modeset sequence for any crtc which needs updating. Now the issue is that the actual interface with the remaining code still only works on one crtc, and so we only pass in one fb and one mode. In intel_set_mode we also only compute one intel_crtc_config (which should be the one for the crtc we're doing a modeset on). The reason for that mismatch is twofold: - We want to eventually do all modeset as global state changes, so it's just infrastructure prep. - But even the old semantics can change more than one crtc when you e.g. move a connector from crtc A to crtc B, then both crtc A and B need to be updated. Usually that means one pipe is disabled and the other enabled. This is also the reason why the hack doesn't touch the disable_pipes mask. Now hilarity ensued in our kms config restore paths when we actually try to do a modeset on all crtcs: If the first crtc should be off and the second should be on, then the call on the first crtc will notice that the 2nd one should be switched on and so tries to compute the pipe_config. But due to a lack of passed-in fb (crtc 1 should be off after all) it only results in tears. This case is ridiculously easy to hit on gen2/3 where the lvds output is restricted to pipe B ;-) Also, before the pipe_config bpp rework gen2/3 didn't care really about the fb-depth and so just stumbled a bit, but never fell over completely. But apparently Ajax also managed to blow up pch platforms, probably with some randomized configs, and pch platforms trip up over the lack of an fb even in the old code. 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] [QA] Testing report for `drm-intel-testing` (was: Updated -next) on ww15
Summary We finished a new round of kernel testing. Generally, in this circle, 2 new bugs are filed, 23 bugs are still opened,1 Resolved fixed bugs(we are busy in doing our testing, sorry that we are slow to response this bug, we will retest this bug ASAP), 6 bugs are closed. Test Environment Kernel: (drm-intel-testing)7522bcfce44527bf46a34d062c5140758022310b Some additional commit info: Merge: bae3699 8abbbaf Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Sat Apr 6 18:16:11 2013 +0200 Hardware We covered the platform: Haswell, HSW ULT, IvyBridge, SandyBridge, IronLake Finding New Bugs: Bug 63453https://bugs.freedesktop.org/show_bug.cgi?id=63453 - [ILK] testdisplay cause Call Trace with DP pipe Bug 63454https://bugs.freedesktop.org/show_bug.cgi?id=63454 - Call Trace when resume from S3 Opened Bugs: Bug 62791https://bugs.freedesktop.org/show_bug.cgi?id=62791 - [ILK regression] Change from X-window to text terminal causes Call Trace Bug 62275https://bugs.freedesktop.org/show_bug.cgi?id=62275 - [HSW 3.8.2 regression] After running testdisplay with only eDP, screen turn to black and can't light up again Bug 55121https://bugzilla.kernel.org/show_bug.cgi?id=55121 - Limited color range on screen that is connected via HDMI [SandyBridge] (https://bugzilla.kernel.org/show_bug.cgi?id=55121) Bug 61041https://bugs.freedesktop.org/show_bug.cgi?id=61041 - [Pineview]I-G-T/testdisplay VGA 1600x1200 65Hz messing the screen Bug 61158https://bugs.freedesktop.org/show_bug.cgi?id=61158 - [ILK] System hang while running testdisplay to mode 1280x800 Bug 60002https://bugs.freedesktop.org/show_bug.cgi?id=60002 - [PNV]I-G-T/kms_flip subtest：'blocking-absolute-wf_vblank' fail Bug 6https://bugs.freedesktop.org/show_bug.cgi?id=6 - [IVB]kms_flip error: inter-vblank ts jitter Bug 5https://bugs.freedesktop.org/show_bug.cgi?id=5 - [ILK,IVB]kms_flip error: inter-flip ts jitter Bug 59834https://bugs.freedesktop.org/show_bug.cgi?id=59834 - [ILK]I-G-T/kms_flip subtest: 'wf_vblank-vs-modeset' fail Bug 59836https://bugs.freedesktop.org/show_bug.cgi?id=59836 - [PNV]igt/kms_flip/absolute-wf_vblank fail Bug 59229https://bugs.freedesktop.org/show_bug.cgi?id=59229 - I-G-T/ prime_self_import fail Bug 59339https://bugs.freedesktop.org/show_bug.cgi?id=59339 - [ILK] I-G-T/kms_flip subtest: 'flip-vs-panning' fail Bug 36997https://bugs.freedesktop.org/show_bug.cgi?id=36997 - [G45 SDVO] TV can't display Bug 42194https://bugs.freedesktop.org/show_bug.cgi?id=42194 - [IVB/SNB] coldplug new monitors for fbcon on lastclose() Bug 51975https://bugs.freedesktop.org/show_bug.cgi?id=51975 - [IVB]can't find the HDMI audio device Bug 54111https://bugs.freedesktop.org/show_bug.cgi?id=54111 - [IVB]I-G-T prime test/module_reload fail with *ERROR* “Memory manager not clean. Delaying takedown” Bug 57441https://bugs.freedesktop.org/show_bug.cgi?id=57441 - [HSW]I-G-T/sysfs_l3_parity fail Bug 58497https://bugs.freedesktop.org/show_bug.cgi?id=58497 - [IVB HSW] I-G-T/testdisplay, there's error in dmesg Bug 58695https://bugs.freedesktop.org/show_bug.cgi?id=58695 - I-G-T/prime_udl fail Bug 58701https://bugs.freedesktop.org/show_bug.cgi?id=58701 - [SNB DP]I-G-T/testdisplay 1920x1080i showing not full Bug 54687https://bugs.freedesktop.org/show_bug.cgi?id=54687 - [ilk] pipe off timeout Bug 52424https://bugs.freedesktop.org/show_bug.cgi?id=52424 - [Bisected SNB Regression] glxgears causes GPU hung Bug 45729https://bugs.freedesktop.org/show_bug.cgi?id=45729 - [bisected regression] Incorrect Mode Timing on DP Display, with 3.3-rc (due to interlaced CEA modes) (blocked by bug #61158) Resolved fixed bugs: Bug 58897https://bugs.freedesktop.org/show_bug.cgi?id=58897 - [HSW CRW]*ERROR* Unknown unclaimed register Closed Bugs: Bug 61929https://bugs.freedesktop.org/show_bug.cgi?id=61929 - [HSW eDP regression 3.8] eDP blank until xrandr is re-run Bug 61542https://bugs.freedesktop.org/show_bug.cgi?id=61542 - [HSW bisected] Desktop-EDP can not work Bug 63415https://bugs.freedesktop.org/show_bug.cgi?id=63415 - [IVB Bisected]I-G-T sysfs_rps Aborted Bug 63246https://bugs.freedesktop.org/show_bug.cgi?id=63246 - [IVB]I-G-T kms_flip/flip-vs-bad-tiling cause [drm:intel_pin_and_fence_fb_obj] *ERROR* Y tiled not allowed for scan out buffers Bug 62798https://bugs.freedesktop.org/show_bug.cgi?id=62798 - [ilk Bisected]System boot fail with -queued kernel Bug 62584https://bugs.freedesktop.org/show_bug.cgi?id=62584 - [SNB Bisected]System hang while booting up with -queued kernel Thanks Yangwei ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fixup Oops in the pipe config computation
Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. So that intel_set_mode essentially already does a global modeset: intel_modeset_affected_pipes compares the current state with where we want to go to (which is carefully set up by intel_crtc_set_config) and then goes through the modeset sequence for any crtc which needs updating. Now the issue is that the actual interface with the remaining code still only works on one crtc, and so we only pass in one fb and one mode. In intel_set_mode we also only compute one intel_crtc_config (which should be the one for the crtc we're doing a modeset on). The reason for that mismatch is twofold: - We want to eventually do all modeset as global state changes, so it's just infrastructure prep. - But even the old semantics can change more than one crtc when you e.g. move a connector from crtc A to crtc B, then both crtc A and B need to be updated. Usually that means one pipe is disabled and the other enabled. This is also the reason why the hack doesn't touch the disable_pipes mask. Now hilarity ensued in our kms config restore paths when we actually try to do a modeset on all crtcs: If the first crtc should be off and the second should be on, then the call on the first crtc will notice that the 2nd one should be switched on and so tries to compute the pipe_config. But due to a lack of passed-in fb (crtc 1 should be off after all) it only results in tears. This case is ridiculously easy to hit on gen2/3 where the lvds output is restricted to pipe B. Note that before the pipe_config bpp rework gen2/3 didn't care really about the fb-depth, so this is a regression brought to light with commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw But apparently Ajax also managed to blow up pch platforms, probably with some randomized configs, and pch platforms trip up over the lack of an fb even in the old code. So this actually goes back to the first introduction of the new modeset restore code in commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open Fix this mess by now by justing shunting all the cool new global modeset logic in intel_modeset_affected_pipes. v2: Improve commit message and clean up all the comments in intel_modeset_affected_pipes - since the introduction of the modeset restore code they've been a bit outdated. Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 Cc: sta...@vger.kernel.org References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html Tested-by: Richard Cochran richardcoch...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 1b2c744..010115c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7613,22 +7613,25 @@ intel_modeset_affected_pipes(struct drm_crtc *crtc, unsigned *modeset_pipes, if (crtc-enabled) *prepare_pipes |= 1 intel_crtc-pipe; - /* We only support modeset on one single crtc, hence we need to do that -* only for the passed in crtc iff we change anything else than just -* disable crtcs. -* -* This is actually not true, to be fully compatible with the old crtc -* helper we automatically disable _any_ output (i.e. doesn't need to be -* connected to the crtc we're modesetting on) if it's disconnected. -* Which is a rather nutty api (since changed the output configuration -* without userspace's explicit request can lead to confusion), but -* alas. Hence we currently need to modeset on all pipes we prepare. */ + /* +* For simplicity do a full modeset on any pipe where the output routing +* changed. We could be more clever, but that would require us to be +* more careful with calling the relevant encoder-mode_set functions. +*/ if (*prepare_pipes) *modeset_pipes = *prepare_pipes; /* ... and mask these out. */ *modeset_pipes = ~(*disable_pipes); *prepare_pipes = ~(*disable_pipes); + + /* +* HACK: We don't (yet) fully support global modesets. intel_set_config +* obies this rule, but the modeset restore mode of +* intel_modeset_setup_hw_state does not. +*/ + *modeset_pipes = 1 intel_crtc-pipe; + *prepare_pipes = 1 intel_crtc-pipe; } static bool intel_crtc_in_use(struct drm_crtc *crtc) -- 1.7.10.4 ___ Intel-gfx mailing list
Re: [Intel-gfx] [PATCH] drm/i915: Fixup Oops in the pipe config computation
On Fri, Apr 12, 2013 at 06:48:43PM +0200, Daniel Vetter wrote: Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. So that intel_set_mode essentially already does a global modeset: intel_modeset_affected_pipes compares the current state with where we want to go to (which is carefully set up by intel_crtc_set_config) and then goes through the modeset sequence for any crtc which needs updating. Now the issue is that the actual interface with the remaining code still only works on one crtc, and so we only pass in one fb and one mode. In intel_set_mode we also only compute one intel_crtc_config (which should be the one for the crtc we're doing a modeset on). The reason for that mismatch is twofold: - We want to eventually do all modeset as global state changes, so it's just infrastructure prep. - But even the old semantics can change more than one crtc when you e.g. move a connector from crtc A to crtc B, then both crtc A and B need to be updated. Usually that means one pipe is disabled and the other enabled. This is also the reason why the hack doesn't touch the disable_pipes mask. Now hilarity ensued in our kms config restore paths when we actually try to do a modeset on all crtcs: If the first crtc should be off and the second should be on, then the call on the first crtc will notice that the 2nd one should be switched on and so tries to compute the pipe_config. But due to a lack of passed-in fb (crtc 1 should be off after all) it only results in tears. This case is ridiculously easy to hit on gen2/3 where the lvds output is restricted to pipe B. Note that before the pipe_config bpp rework gen2/3 didn't care really about the fb-depth, so this is a regression brought to light with commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw But apparently Ajax also managed to blow up pch platforms, probably with some randomized configs, and pch platforms trip up over the lack of an fb even in the old code. So this actually goes back to the first introduction of the new modeset restore code in commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open Fix this mess by now by justing shunting all the cool new global modeset logic in intel_modeset_affected_pipes. v2: Improve commit message and clean up all the comments in intel_modeset_affected_pipes - since the introduction of the modeset restore code they've been a bit outdated. Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 ^ Bugzilla Cc: sta...@vger.kernel.org References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html Tested-by: Richard Cochran richardcoch...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch I'm happier with that and with reducing the amount of confusion from the comments, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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: turbo RC6 support for VLV v6
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
clean up mem freq calculation (Ben)
clean up debug prints (Ben)
v4: move defines from punit patch (Ville)
v5: remove writes to nonexistent regs (Jesse)
put RP and RC regs together (Jesse)
fix RC6 enable (Jesse)
v6: use correct fuse reads from NC (Jesse)
split out min/max funcs for use in sysfs (Jesse)
add debugfs sysfs freq controls (Jesse)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 58 --
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/i915_irq.c |5 +-
drivers/gpu/drm/i915/i915_reg.h | 21
drivers/gpu/drm/i915/i915_sysfs.c | 68
drivers/gpu/drm/i915/intel_pm.c | 198 +--
6 files changed, 317 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index be88532..ee2791f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -941,7 +941,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void
*unused)
MEMSTAT_VID_SHIFT);
seq_printf(m, Current P-state: %d\n,
(rgvstat MEMSTAT_PSTATE_MASK)
MEMSTAT_PSTATE_SHIFT);
- } else if (IS_GEN6(dev) || IS_GEN7(dev)) {
+ } else if ((IS_GEN6(dev) || IS_GEN7(dev)) !IS_VALLEYVIEW(dev)) {
u32 gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS);
u32 rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
@@ -1006,6 +1006,25 @@ static int i915_cur_delayinfo(struct seq_file *m, void
*unused)
max_freq = rp_state_cap 0xff;
seq_printf(m, Max non-overclocked (RP0) frequency: %dMHz\n,
max_freq * GT_FREQUENCY_MULTIPLIER);
+ } else if (IS_VALLEYVIEW(dev)) {
+ u32 freq_sts, val;
+
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS,
+ freq_sts);
+ seq_printf(m, PUNIT_REG_GPU_FREQ_STS: 0x%08x\n, freq_sts);
+ seq_printf(m, DDR freq: %d MHz\n, dev_priv-mem_freq);
+
+ valleyview_punit_read(dev_priv, PUNIT_FUSE_BUS1, val);
+ seq_printf(m, max GPU freq: %d MHz\n,
+ vlv_gpu_freq(dev_priv-mem_freq, val));
+
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_LFM, val);
+ seq_printf(m, min GPU freq: %d MHz\n,
+ vlv_gpu_freq(dev_priv-mem_freq, val));
+
+ seq_printf(m, current GPU freq: %d MHz\n,
+ vlv_gpu_freq(dev_priv-mem_freq,
+ (freq_sts 8) 0xff));
} else {
seq_printf(m, no P-state info available\n);
}
@@ -1806,7 +1825,11 @@ i915_max_freq_get(void *data, u64 *val)
if (ret)
return ret;
- *val = dev_priv-rps.max_delay * GT_FREQUENCY_MULTIPLIER;
+ if (IS_VALLEYVIEW(dev))
+ *val = vlv_gpu_freq(dev_priv-mem_freq,
+ dev_priv-rps.max_delay);
+ else
+ *val = dev_priv-rps.max_delay * GT_FREQUENCY_MULTIPLIER;
mutex_unlock(dev_priv-rps.hw_lock);
return 0;
@@ -1831,9 +1854,16 @@ i915_max_freq_set(void *data, u64 val)
/*
* Turbo will still be enabled, but won't go above the set value.
*/
- do_div(val, GT_FREQUENCY_MULTIPLIER);
- dev_priv-rps.max_delay = val;
- gen6_set_rps(dev, val);
+ if (IS_VALLEYVIEW(dev)) {
+ val = vlv_freq_opcode(dev_priv-mem_freq, val);
+ dev_priv-rps.max_delay = val;
+ gen6_set_rps(dev, val);
+ } else {
+ do_div(val, GT_FREQUENCY_MULTIPLIER);
+ dev_priv-rps.max_delay = val;
+ gen6_set_rps(dev, val);
+ }
+
mutex_unlock(dev_priv-rps.hw_lock);
return 0;
@@ -1857,7 +1887,11 @@ i915_min_freq_get(void *data, u64 *val)
if (ret)
return ret;
- *val = dev_priv-rps.min_delay * GT_FREQUENCY_MULTIPLIER;
+ if (IS_VALLEYVIEW(dev))
+ *val = vlv_gpu_freq(dev_priv-mem_freq,
+ dev_priv-rps.min_delay);
+ else
+ *val = dev_priv-rps.min_delay * GT_FREQUENCY_MULTIPLIER;
mutex_unlock(dev_priv-rps.hw_lock);
return 0;
@@ -1882,9 +1916,15 @@ i915_min_freq_set(void *data, u64 val)
/*
* Turbo will still be enabled, but won't go below the set value.
*/
- do_div(val,
[Intel-gfx] [PATCH 2/2] drm/i915: turbo RC6 support for VLV v6
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
clean up mem freq calculation (Ben)
clean up debug prints (Ben)
v4: move defines from punit patch (Ville)
v5: remove writes to nonexistent regs (Jesse)
put RP and RC regs together (Jesse)
fix RC6 enable (Jesse)
v6: use correct fuse reads from NC (Jesse)
split out min/max funcs for use in sysfs (Jesse)
add debugfs sysfs freq controls (Jesse)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 58 --
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/i915_irq.c |5 +-
drivers/gpu/drm/i915/i915_reg.h | 21
drivers/gpu/drm/i915/i915_sysfs.c | 68
drivers/gpu/drm/i915/intel_pm.c | 198 +--
6 files changed, 317 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index be88532..ee2791f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -941,7 +941,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void
*unused)
MEMSTAT_VID_SHIFT);
seq_printf(m, Current P-state: %d\n,
(rgvstat MEMSTAT_PSTATE_MASK)
MEMSTAT_PSTATE_SHIFT);
- } else if (IS_GEN6(dev) || IS_GEN7(dev)) {
+ } else if ((IS_GEN6(dev) || IS_GEN7(dev)) !IS_VALLEYVIEW(dev)) {
u32 gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS);
u32 rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
@@ -1006,6 +1006,25 @@ static int i915_cur_delayinfo(struct seq_file *m, void
*unused)
max_freq = rp_state_cap 0xff;
seq_printf(m, Max non-overclocked (RP0) frequency: %dMHz\n,
max_freq * GT_FREQUENCY_MULTIPLIER);
+ } else if (IS_VALLEYVIEW(dev)) {
+ u32 freq_sts, val;
+
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS,
+ freq_sts);
+ seq_printf(m, PUNIT_REG_GPU_FREQ_STS: 0x%08x\n, freq_sts);
+ seq_printf(m, DDR freq: %d MHz\n, dev_priv-mem_freq);
+
+ valleyview_punit_read(dev_priv, PUNIT_FUSE_BUS1, val);
+ seq_printf(m, max GPU freq: %d MHz\n,
+ vlv_gpu_freq(dev_priv-mem_freq, val));
+
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_LFM, val);
+ seq_printf(m, min GPU freq: %d MHz\n,
+ vlv_gpu_freq(dev_priv-mem_freq, val));
+
+ seq_printf(m, current GPU freq: %d MHz\n,
+ vlv_gpu_freq(dev_priv-mem_freq,
+ (freq_sts 8) 0xff));
} else {
seq_printf(m, no P-state info available\n);
}
@@ -1806,7 +1825,11 @@ i915_max_freq_get(void *data, u64 *val)
if (ret)
return ret;
- *val = dev_priv-rps.max_delay * GT_FREQUENCY_MULTIPLIER;
+ if (IS_VALLEYVIEW(dev))
+ *val = vlv_gpu_freq(dev_priv-mem_freq,
+ dev_priv-rps.max_delay);
+ else
+ *val = dev_priv-rps.max_delay * GT_FREQUENCY_MULTIPLIER;
mutex_unlock(dev_priv-rps.hw_lock);
return 0;
@@ -1831,9 +1854,16 @@ i915_max_freq_set(void *data, u64 val)
/*
* Turbo will still be enabled, but won't go above the set value.
*/
- do_div(val, GT_FREQUENCY_MULTIPLIER);
- dev_priv-rps.max_delay = val;
- gen6_set_rps(dev, val);
+ if (IS_VALLEYVIEW(dev)) {
+ val = vlv_freq_opcode(dev_priv-mem_freq, val);
+ dev_priv-rps.max_delay = val;
+ gen6_set_rps(dev, val);
+ } else {
+ do_div(val, GT_FREQUENCY_MULTIPLIER);
+ dev_priv-rps.max_delay = val;
+ gen6_set_rps(dev, val);
+ }
+
mutex_unlock(dev_priv-rps.hw_lock);
return 0;
@@ -1857,7 +1887,11 @@ i915_min_freq_get(void *data, u64 *val)
if (ret)
return ret;
- *val = dev_priv-rps.min_delay * GT_FREQUENCY_MULTIPLIER;
+ if (IS_VALLEYVIEW(dev))
+ *val = vlv_gpu_freq(dev_priv-mem_freq,
+ dev_priv-rps.min_delay);
+ else
+ *val = dev_priv-rps.min_delay * GT_FREQUENCY_MULTIPLIER;
mutex_unlock(dev_priv-rps.hw_lock);
return 0;
@@ -1882,9 +1916,15 @@ i915_min_freq_set(void *data, u64 val)
/*
* Turbo will still be enabled, but won't go below the set value.
*/
- do_div(val,
[Intel-gfx] [PATCH 1/2] drm/i915: VLV GPU frequency to opcode functions
When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 56 +++
2 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4fa36d..db7d0be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1873,6 +1873,8 @@ int sandybridge_pcode_read(struct drm_i915_private
*dev_priv, u8 mbox, u32 *val)
int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u8 mbox, u32
val);
int valleyview_punit_read(struct drm_i915_private *dev_priv, u8 addr, u32
*val);
int valleyview_punit_write(struct drm_i915_private *dev_priv, u8 addr, u32
val);
+int vlv_gpu_freq(int ddr_freq, int val);
+int vlv_freq_opcode(int ddr_freq, int val);
#define __i915_read(x, y) \
u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 13a0666..7f313c0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4579,3 +4579,59 @@ int valleyview_punit_write(struct drm_i915_private
*dev_priv, u8 addr, u32 val)
{
return vlv_punit_rw(dev_priv, PUNIT_OPCODE_REG_WRITE, addr, val);
}
+
+int vlv_gpu_freq(int ddr_freq, int val)
+{
+ int mult, base;
+
+ switch (ddr_freq) {
+ case 800:
+ mult = 20;
+ base = 120;
+ break;
+ case 1066:
+ mult = 22;
+ base = 133;
+ break;
+ case 1333:
+ mult = 21;
+ base = 125;
+ break;
+ default:
+ return -1;
+ }
+
+ return ((val - 0xbd) * mult) + base;
+}
+
+int vlv_freq_opcode(int ddr_freq, int val)
+{
+ int mult, base;
+
+ switch (ddr_freq) {
+ case 800:
+ mult = 20;
+ base = 120;
+ break;
+ case 1066:
+ mult = 22;
+ base = 133;
+ break;
+ case 1333:
+ mult = 21;
+ base = 125;
+ break;
+ default:
+ return -1;
+ }
+
+ val /= mult;
+ val -= base / mult;
+ val += 0xbd;
+
+ if (val 0xea)
+ val = 0xea;
+
+ return val;
+}
+
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: shorten i915_next_seqno debugfs output
On Fri, Apr 12, 2013 at 2:15 AM, Mika Kuoppala mika.kuopp...@linux.intel.com wrote: Kees Cook keesc...@chromium.org writes: On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala mika.kuopp...@linux.intel.com wrote: Kees Cook keesc...@chromium.org writes: On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala mika.kuopp...@linux.intel.com wrote: commit 647416f9eefe7699754b01b9fc82758fde83248c Author: Kees Cook keesc...@chromium.org Date: Sun Mar 10 14:10:06 2013 -0700 drm/i915: use simple attribute in debugfs routines made i915_next_seqno debugfs entry to crop it's output if returned value was large enough. Using simple_attr will limit the output to 24 bytes. Fix this by returning only the value and nothing else. Cc: Kees Cook keesc...@chromium.org Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com Oh! Thanks for catching that. What a weird limitation. What about max freq, min freq, and wedged? Do those run the risk of truncation too? max and min freq should be safe, and wedged too on 32bit platforms. But if gpu is declared wedged on host with 64bit atomic_t, it will crop the output. Should we consider proposing an increase in the size of the simple attr buffer? It seems silly to provide an arbitrary format string but leave the buffer so small. That or dynamic allocation to attr-get_buf. But that would need extra pass with snprintf and I don't know if that qualifies as 'simple' anymore. I have posted a patch which fixes all i915 debugfs simple attributes to fit into the simple_attr by removing everything except the fmt to value. I didn't find any testcases which would rely on preample being there. That works too. :) If you want, consider them: Acked-by: Kees Cook keesc...@chromium.org :) Thanks! -Kees -- Kees Cook Chrome OS Security ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: shorten debugfs output simple attributes
On Fri, Apr 12, 2013 at 2:10 AM, Mika Kuoppala mika.kuopp...@linux.intel.com wrote: commit 647416f9eefe7699754b01b9fc82758fde83248c Author: Kees Cook keesc...@chromium.org Date: Sun Mar 10 14:10:06 2013 -0700 drm/i915: use simple attribute in debugfs routines made i915_next_seqno debugfs entry to crop it's output if returned value was large enough. Using simple_attr will limit the output to 24 bytes. Fix is to strip out preamples on all simple attributes that have one. v2: Fix all simple attributes (Daniel Vetter) Cc: Kees Cook keesc...@chromium.org Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com Acked-by: Kees Cook keesc...@chromium.org -- Kees Cook Chrome OS Security ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Scale ring, rather than ia, frequency on Haswell
Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we increase the frequency of the ring to increase the available
memory bandwidth.
v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
v3: s/max_ring_freq/min_ring_freq/ as that is what it is
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_debugfs.c |7 --
drivers/gpu/drm/i915/i915_reg.h |4
drivers/gpu/drm/i915/intel_pm.c | 43 +++
3 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7da45aa..6220d97 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1357,7 +1357,7 @@ static int i915_ring_freq_table(struct seq_file *m, void
*unused)
if (ret)
return ret;
- seq_printf(m, GPU freq (MHz)\tEffective CPU freq (MHz)\n);
+ seq_printf(m, GPU freq (MHz)\tEffective CPU freq (MHz)\tEffective Ring
freq (MHz)\n);
for (gpu_freq = dev_priv-rps.min_delay;
gpu_freq = dev_priv-rps.max_delay;
@@ -1366,7 +1366,10 @@ static int i915_ring_freq_table(struct seq_file *m, void
*unused)
sandybridge_pcode_read(dev_priv,
GEN6_PCODE_READ_MIN_FREQ_TABLE,
ia_freq);
- seq_printf(m, %d\t\t%d\n, gpu_freq * GT_FREQUENCY_MULTIPLIER,
ia_freq * 100);
+ seq_printf(m, %d\t\t%d\t\t\t\t%d\n,
+ gpu_freq * GT_FREQUENCY_MULTIPLIER,
+ ((ia_freq 0) 0xff) * 100,
+ ((ia_freq 8) 0xff) * 100);
}
mutex_unlock(dev_priv-rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e0fc070..077d40f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1210,6 +1210,9 @@
#define MCHBAR_MIRROR_BASE_SNB 0x14
+/* Memory controller frequency in MCHBAR for Haswell (possible SNB+) */
+#define DCLK 0x5e04
+
/** 915-945 and GM965 MCH register controlling DRAM channel access */
#define DCC0x10200
#define DCC_ADDRESSING_MODE_SINGLE_CHANNEL (0 0)
@@ -4390,6 +4393,7 @@
#define GEN6_DECODE_RC6_VID(vids)(((vids) * 5) + 245)
#define GEN6_PCODE_DATA0x138128
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
+#define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
#define VLV_IOSF_DOORBELL_REQ 0x182100
#define IOSF_DEVFN_SHIFT 24
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index baea4fc..7ef5b3f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2684,8 +2684,8 @@ static void gen6_update_ring_freq(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
int min_freq = 15;
- int gpu_freq;
- unsigned int ia_freq, max_ia_freq;
+ unsigned int gpu_freq;
+ unsigned int max_ia_freq, min_ring_freq;
int scaling_factor = 180;
WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
@@ -2701,6 +2701,10 @@ static void gen6_update_ring_freq(struct drm_device *dev)
/* Convert from kHz to MHz */
max_ia_freq /= 1000;
+ min_ring_freq = I915_READ(MCHBAR_MIRROR_BASE_SNB + DCLK);
+ /* convert DDR frequency from units of 133.3MHz to bandwidth */
+ min_ring_freq = (2 * 4 * min_ring_freq + 2)/ 3;
+
/*
* For each potential GPU frequency, load a ring frequency we'd like
* to use for memory access. We do this by specifying the IA frequency
@@ -2709,21 +2713,32 @@ static void gen6_update_ring_freq(struct drm_device
*dev)
for (gpu_freq = dev_priv-rps.max_delay; gpu_freq =
dev_priv-rps.min_delay;
gpu_freq--) {
int diff = dev_priv-rps.max_delay - gpu_freq;
-
- /*
-* For GPU frequencies less than 750MHz, just use the lowest
-* ring freq.
-*/
- if (gpu_freq min_freq)
- ia_freq = 800;
- else
- ia_freq = max_ia_freq - ((diff * scaling_factor) / 2);
- ia_freq = DIV_ROUND_CLOSEST(ia_freq, 100);
- ia_freq = GEN6_PCODE_FREQ_IA_RATIO_SHIFT;
+ unsigned int ia_freq = 0, ring_freq = 0;
+
+ if (IS_HASWELL(dev)) {
+ ring_freq = (gpu_freq * 5 + 3) / 4;
+
Re: [Intel-gfx] [PATCH 1/2] drm/i915: VLV GPU frequency to opcode functions
On Fri, Apr 12, 2013 at 10:50:44AM -0700, Jesse Barnes wrote:
When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 56
+++
2 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4fa36d..db7d0be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1873,6 +1873,8 @@ int sandybridge_pcode_read(struct drm_i915_private
*dev_priv, u8 mbox, u32 *val)
int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u8 mbox, u32
val);
int valleyview_punit_read(struct drm_i915_private *dev_priv, u8 addr, u32
*val);
int valleyview_punit_write(struct drm_i915_private *dev_priv, u8 addr, u32
val);
+int vlv_gpu_freq(int ddr_freq, int val);
+int vlv_freq_opcode(int ddr_freq, int val);
#define __i915_read(x, y) \
u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 13a0666..7f313c0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4579,3 +4579,59 @@ int valleyview_punit_write(struct drm_i915_private
*dev_priv, u8 addr, u32 val)
{
return vlv_punit_rw(dev_priv, PUNIT_OPCODE_REG_WRITE, addr, val);
}
+
+int vlv_gpu_freq(int ddr_freq, int val)
+{
+ int mult, base;
+
+ switch (ddr_freq) {
+ case 800:
+ mult = 20;
+ base = 120;
+ break;
+ case 1066:
+ mult = 22;
+ base = 133;
+ break;
+ case 1333:
+ mult = 21;
+ base = 125;
+ break;
+ default:
+ return -1;
+ }
+
+ return ((val - 0xbd) * mult) + base;
+}
+
+int vlv_freq_opcode(int ddr_freq, int val)
+{
+ int mult, base;
+
+ switch (ddr_freq) {
+ case 800:
+ mult = 20;
+ base = 120;
+ break;
+ case 1066:
+ mult = 22;
+ base = 133;
+ break;
+ case 1333:
+ mult = 21;
+ base = 125;
+ break;
+ default:
+ return -1;
+ }
+
+ val /= mult;
+ val -= base / mult;
+ val += 0xbd;
+
+ if (val 0xea)
+ val = 0xea;
+
+ return val;
+}
+
I can't find this stupid doc, again. But with or without comments below:
Acked-by: Ben Widawsky b...@bwidawsk.net
As we just discussed on IRC, I remember a much simpler formula. I assume
you have a reason for not using it.
Without seeing the callers it's hard to tell, but using unsigned values,
and asserting that val 0xbd would seem to make more sense.
Also, I'd think it's reasonable to WARN_ON_ONCE() or something in the
default case since it means we probably need to support something new.
Finally, I think doing the math in the reverse order of freq() is easier
to read, ie.
val -= base;
val /= mult;
val += 0xbd;
--
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] [3.4.y, 3.5.y] drm/i915: Use the correct size of the GTT for placing the per-process entries
On Fri, Apr 12, 2013 at 12:31:53AM -0700, Jonathan Nieder wrote: Hi Greg, Please consider 9a0f938bde74 drm/i915: Use the correct size of the GTT for placing the per-process entries, 2012-08-24 for application to the 3.4.y tree. Without this patch, Geoff Crompton's iMac hits a BUG during bootup. The problem is reproducible on * Debian's 3.2.y-based kernel with drm backported from 3.4.37 * a Debian kernel close to 3.4.4 * a Debian kernel close to 3.5.5 * vanilla 3.4.4 He is not able to reproduce the problem on * Debian's older 3.2.y-based kernels without the 3.4.y drm backport * a Debian kernel close to 3.6.4; various newer kernels * vanilla 3.4.4 + this patch The patch was applied upstream during the 3.6-rc4 cycle, so newer kernels don't need it. http://bugs.debian.org/703468 has details, including a screenshot of the boot failure (unable to handling kernel paging request at c9000b7ff000 in i915_gem_init_ppgtt). Now applied, thanks. greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: report Gen5+ CPU and PCH FIFO underruns
Hi
2013/3/28 Daniel Vetter dan...@ffwll.ch:
On Fri, Feb 22, 2013 at 05:05:29PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
In this commit we enable both CPU and PCH FIFO underrun reporting and
start reporting them. We follow a few rules:
- after we receive one of these errors, we mask the interrupt, so
we won't get an interrupt storm and we also won't flood dmesg;
- at each mode set we enable the interrupts again, so we'll see each
message at most once per mode set;
- in the specific places where we need to ignore the errors, we
completely mask the interrupts.
The downside of this patch is that since we're completely disabling
(masking) the interrupts instead of just not printing error messages,
we will mask more than just what we want on IVB/HSW CPU interrupts
(due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So
when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll
also be masking PCH FIFO underruns for pipe B, because both are
reported by SERR_INT which has to be either completely enabled or
completely disabled (in othe words, there's no way to disable/enable
specific bits of GEN7_ERR_INT and SERR_INT).
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Ok, sorry for the long delay in reviewing this (I've somehow hoped that
someone else would do it, but meh ...).
I'm happy with the logic in your patch here, but it took me a while to
piece together the control flow and what exactly is done where. I think
that can be improved by renaming a few functions to make it clearer what
exactly they're doing. Suggestions below.
Yeah, looks like the names were not really good. See below.
The only functional comment is about the hsw err irq blocking, at least to
me it looks not required.
Yours, Daniel
---
drivers/gpu/drm/i915/i915_irq.c | 307
+-
drivers/gpu/drm/i915/i915_reg.h | 13 +-
drivers/gpu/drm/i915/intel_display.c | 17 +-
drivers/gpu/drm/i915/intel_drv.h | 10 ++
4 files changed, 334 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 7531095..d0f9c47 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -57,6 +57,208 @@ ironlake_disable_display_irq(drm_i915_private_t
*dev_priv, u32 mask)
}
}
+static bool disable_gen7_err_int(struct drm_i915_private *dev_priv)
It took me a while to figure out that this just checks whether underrun
reporting is disabled on any crtc and whether we hence need to disable it
completely. Usually I presume that a function call verb_something actually
does what the verb say, e.g. disable_foo I expect that the function
actually disables foo.
Since I can't come up with a concise name for these two functions here
(have_pipe_with_disabled_underrun_reporting is the best I could do ...)
maybe just inline it into their respective (only) callsite and add a
comment before the loop saying what it does? Maybe like
bool can_enable_underrun_reporting = true;
/* No per-crtc underrun irq disable bit, only a global one. */
for_each_pipe {
if (crtc-underrun_reporting_disabled)
can_enable_underrun_reporting = false;
}
if (enable can_enable_underrun_reporting)
/* enable */
else
/* disable */
I renamed disable_gen7_err_int() to ivb_can_enable_err_int() (and
inverted its behavior, of course). Same thing with
cpt_can_enable_serr_int(). I hope it's understandable now :)
+{
+ struct intel_crtc *crtc;
+ enum pipe pipe;
+
+ for_each_pipe(pipe) {
+ crtc = to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
+
+ if (crtc-disable_cpu_fifo_underrun)
Same here, I'd go with cpu_fifo_underrun_disabled to make it clear that
it's a state tracking, not a request/action variable.
Done.
+ return true;
+ }
+
+ return false;
+}
+
+static bool disable_serr_int(struct drm_i915_private *dev_priv)
+{
+ enum pipe pipe;
+ struct intel_crtc *crtc;
+
+ for_each_pipe(pipe) {
+ crtc = to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
+
+ if (crtc-disable_pch_fifo_underrun)
+ return true;
+ }
+
+ return false;
+}
+
+static void ironlake_report_fifo_underrun(struct drm_device *dev,
+ enum pipe pipe, bool enable)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t bit = (pipe == PIPE_A) ? DE_PIPEA_FIFO_UNDERRUN :
+ DE_PIPEB_FIFO_UNDERRUN;
+
+ if (enable)
+ ironlake_enable_display_irq(dev_priv, bit);
+ else
+ ironlake_disable_display_irq(dev_priv, bit);
+}
+
+static void
Re: [Intel-gfx] [PATCH 2/2] drm/i915: turbo RC6 support for VLV v6
On Fri, Apr 12, 2013 at 10:50:45AM -0700, Jesse Barnes wrote: Uses slightly different interfaces than other platforms. v2: track actual set freq, not requested (Rohit) fix debug prints in init code (Jesse) v3: don't write sleep reg (Jesse) re-add RC6 wake limit write (Ben) fixup thresholds to match other platforms (Ben) clean up mem freq calculation (Ben) clean up debug prints (Ben) v4: move defines from punit patch (Ville) v5: remove writes to nonexistent regs (Jesse) put RP and RC regs together (Jesse) fix RC6 enable (Jesse) v6: use correct fuse reads from NC (Jesse) split out min/max funcs for use in sysfs (Jesse) add debugfs sysfs freq controls (Jesse) Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org I didn't stare too intently since I had reviewed v4, nothing stood out immediately though, so: Reviewed-by: Ben Widawsky b...@bwidawsk.net [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 4/7] drm/i915: don't touch the PF regs if the power well is down
On Fri, Mar 22, 2013 at 02:16:38PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com This solves some unclaimed register messages when booting the machine with eDP attached. V2: Rebase and add the comment requested by Daniel. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Merged this one and the previous prep patch to dinq, 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
[Intel-gfx] [PATCH 2/2] drm/i915: print Gen5+ CPU/PCH poison interrupts
From: Paulo Zanoni paulo.r.zan...@intel.com
This is bad news and shouldn't be happening.
V2: Rebase.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 13 +++--
drivers/gpu/drm/i915/i915_reg.h |2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9aff6ed..8b2461b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -939,6 +939,9 @@ static void ivb_err_int_handler(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 err_int = I915_READ(GEN7_ERR_INT);
+ if (err_int ERR_INT_POISON)
+ DRM_ERROR(Poison interrupt\n);
+
if (err_int ERR_INT_FIFO_UNDERRUN_A)
if (intel_set_cpu_fifo_underrun_reporting(dev, PIPE_A, false))
DRM_DEBUG_DRIVER(Pipe A FIFO underrun\n);
@@ -959,6 +962,9 @@ static void cpt_serr_int_handler(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
u32 serr_int = I915_READ(SERR_INT);
+ if (serr_int SERR_INT_POISON)
+ DRM_ERROR(PCH poison interrupt\n);
+
if (serr_int SERR_INT_TRANS_A_FIFO_UNDERRUN)
if (intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A,
false))
@@ -1172,6 +1178,9 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
if (de_iir DE_PIPEB_VBLANK)
drm_handle_vblank(dev, 1);
+ if (de_iir DE_POISON)
+ DRM_ERROR(Poison interrupt\n);
+
if (de_iir DE_PIPEA_FIFO_UNDERRUN)
if (intel_set_cpu_fifo_underrun_reporting(dev, PIPE_A, false))
DRM_DEBUG_DRIVER(Pipe A FIFO underrun\n);
@@ -2403,7 +2412,7 @@ static void ibx_irq_postinstall(struct drm_device *dev)
if (HAS_PCH_IBX(dev)) {
mask = SDE_GMBUS | SDE_AUX_MASK | SDE_TRANSB_FIFO_UNDER |
- SDE_TRANSA_FIFO_UNDER;
+ SDE_TRANSA_FIFO_UNDER | SDE_POISON;
} else {
mask = SDE_GMBUS_CPT | SDE_AUX_MASK_CPT | SDE_ERROR_CPT;
@@ -2424,7 +2433,7 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
u32 display_mask = DE_MASTER_IRQ_CONTROL | DE_GSE | DE_PCH_EVENT |
DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE |
DE_AUX_CHANNEL_A | DE_PIPEB_FIFO_UNDERRUN |
- DE_PIPEA_FIFO_UNDERRUN;
+ DE_PIPEA_FIFO_UNDERRUN | DE_POISON;
u32 render_irqs;
dev_priv-irq_mask = ~display_mask;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 932b4a0..68a27e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -529,6 +529,7 @@
#define ERROR_GEN6 0x040a0
#define GEN7_ERR_INT 0x44040
+#define ERR_INT_POISON (131)
#define ERR_INT_MMIO_UNCLAIMED (113)
#define ERR_INT_FIFO_UNDERRUN_C (16)
#define ERR_INT_FIFO_UNDERRUN_B (13)
@@ -3693,6 +3694,7 @@
#define SDEIER 0xc400c
#define SERR_INT 0xc4040
+#define SERR_INT_POISON (131)
#define SERR_INT_TRANS_C_FIFO_UNDERRUN(16)
#define SERR_INT_TRANS_B_FIFO_UNDERRUN(13)
#define SERR_INT_TRANS_A_FIFO_UNDERRUN(10)
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: remove comment about IVB link training from intel_pm.c
From: Paulo Zanoni paulo.r.zan...@intel.com
We have the exact same comment inside intel_init_display. This is
a leftover from when we moved a lot of code from intel_display.c to
intel_pm.c.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index baea4fc..a175984 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4191,7 +4191,6 @@ void intel_init_pm(struct drm_device *dev)
}
dev_priv-display.init_clock_gating =
gen6_init_clock_gating;
} else if (IS_IVYBRIDGE(dev)) {
- /* FIXME: detect B0+ stepping and use auto training */
if (SNB_READ_WM0_LATENCY()) {
dev_priv-display.update_wm =
ivybridge_update_wm;
dev_priv-display.update_sprite_wm =
sandybridge_update_sprite_wm;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines
From: Paulo Zanoni paulo.r.zan...@intel.com
We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
have CRT, so just check for !IS_ULT. This problem happened on a real
machine and resulted in a very ugly dmesg.
Cc: sta...@vger.kernel.org
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 574d68d..64b4407 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8488,7 +8488,7 @@ static void intel_setup_outputs(struct drm_device *dev)
I915_WRITE(PFIT_CONTROL, 0);
}
- if (!(HAS_DDI(dev) (I915_READ(DDI_BUF_CTL(PORT_A)) DDI_A_4_LANES)))
+ if (!IS_ULT(dev))
intel_crt_init(dev);
if (HAS_DDI(dev)) {
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: WARN when LPT-LP is not paired with ULT CPU
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..3d3803a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -457,11 +457,13 @@ void intel_detect_pch(struct drm_device *dev)
dev_priv-num_pch_pll = 0;
DRM_DEBUG_KMS(Found LynxPoint PCH\n);
WARN_ON(!IS_HASWELL(dev));
+ WARN_ON(IS_ULT(dev));
} else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
dev_priv-pch_type = PCH_LPT;
dev_priv-num_pch_pll = 0;
DRM_DEBUG_KMS(Found LynxPoint LP PCH\n);
WARN_ON(!IS_HASWELL(dev));
+ WARN_ON(!IS_ULT(dev));
}
BUG_ON(dev_priv-num_pch_pll I915_NUM_PLLS);
}
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
