Re: [Intel-gfx] [PATCH 5/5] drm/i915/vlv: support save/restore of display state around power well toggle
On Tue, Oct 15, 2013 at 01:42:53PM -0700, Jesse Barnes wrote:
On Tue, 15 Oct 2013 17:09:19 -0300
Paulo Zanoni przan...@gmail.com wrote:
2013/10/14 Jesse Barnes jbar...@virtuousgeek.org:
If we disable the power well at runtime, we need to save enough display
state so we can restore it when the power well comes back again. Add
support for that on VLV by reusing some of the _freeze and _thaw code.
Note we need to drop the power well lock in this path around the restore,
since we'll end up in mode set functions that take more refs on the
power well.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_uncore.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index b126f5a..070ff00 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -406,7 +406,26 @@ static void __vlv_set_power_well(struct
drm_i915_private *dev_priv,
static void vlv_set_display_power(struct drm_i915_private *dev_priv,
bool enable)
{
- __vlv_set_power_well(dev_priv, DISP2D_PWRGT, enable);
+ struct drm_device *dev = dev_priv-dev;
+ struct i915_power_well *power_well = dev_priv-power_well;
+
+ if (enable) {
+ /* Lost all the display state, restore it */
+ if (vlv_display_power_enabled(dev_priv))
+ return; /* already on, skip the fireworks */
+ __vlv_set_power_well(dev_priv, DISP2D_PWRGT, true);
+ spin_unlock_irq(power_well-lock);
+ i915_restore_state(dev);
At least on Haswell, i915_restore_state restores a lot more than just
what was lost on the power well. Do you really need all this? Besides,
I kinda fear you can break things by restoring stuff that is already
running. While we're doing this restoring, interrputs are happening,
everything is running, yet we call stuff like intel_i2c_reset,
i915_gem_restore_fences and others. Another example: we have code to
restore the backlight registers, but backlight is usually on the
output that works even with the power well disabled. So if we disable
the power well, then change backlight on the only output that is
working, then reenable the power well we'll restore a bogus
backlight state on a case where we shouldn't be touching backlight at
all.
Yeah this is definitely a WIP. We'll probably need power well specific
save/restore functions. Depending on which well was toggled, the state
that needs to be saved restored will be different. It may be best to
try to push all this into modeset_setup_hw_state, since it should know
which power wells are needed for different ops and thus restore the
right state. But that means ripping apart save/restore_state and
putting bits in the right places, potentially with specific hooks like
the uncore save/restore I added for other stuff.
setup_hw_state only deals with things which should be active (and restores
them when they're not active). But what we want here is to re-run the
-mode_set callback code when enabling a pipe again through dpms. So for
me it feels much saner to just add that callback there instead of
magically restoring register state in the get/put functions.
The reason for that is that at least long-term I expect the -mode_set
callbacks to die and that we'll move everything which is in there either
into -enable callbacks or into the compute config stage. With that we'll
have the guarantee that the hw touching code sequence is always the same,
no matter which exact upper level function caused a given state change
(modeset, dpms, resume, ...).
I don't really have an opinion about how we should handle this stuff on
the gem side of things. For that magically restoring the gem hw state in
the get/put functions sounds like the right approach. For gem we probably
also need some delayed actual put to have a bit of hysteresis. That's
kinda why I think we should have separate interfaces for display power
well management and gem/irq/aux power well management.
-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: Move some hdmi enable function name to vlv specific.
There is no functional change on this patch. Only rename several
hdmi encoder function name which suppose to use only by valleyview from
intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 4f4d346..51a8336 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1074,7 +1074,7 @@ done:
return 0;
}
-static void intel_hdmi_pre_enable(struct intel_encoder *encoder)
+static void vlv_hdmi_pre_enable(struct intel_encoder *encoder)
{
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_device *dev = encoder-base.dev;
@@ -1127,7 +1127,7 @@ static void intel_hdmi_pre_enable(struct intel_encoder
*encoder)
vlv_wait_port_ready(dev_priv, port);
}
-static void intel_hdmi_pre_pll_enable(struct intel_encoder *encoder)
+static void vlv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
{
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_device *dev = encoder-base.dev;
@@ -1163,7 +1163,7 @@ static void intel_hdmi_pre_pll_enable(struct
intel_encoder *encoder)
mutex_unlock(dev_priv-dpio_lock);
}
-static void intel_hdmi_post_disable(struct intel_encoder *encoder)
+static void vlv_hdmi_post_disable(struct intel_encoder *encoder)
{
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
@@ -1313,10 +1313,10 @@ void intel_hdmi_init(struct drm_device *dev, int
hdmi_reg, enum port port)
intel_encoder-get_hw_state = intel_hdmi_get_hw_state;
intel_encoder-get_config = intel_hdmi_get_config;
if (IS_VALLEYVIEW(dev)) {
- intel_encoder-pre_pll_enable = intel_hdmi_pre_pll_enable;
- intel_encoder-pre_enable = intel_hdmi_pre_enable;
+ intel_encoder-pre_pll_enable = vlv_hdmi_pre_pll_enable;
+ intel_encoder-pre_enable = vlv_hdmi_pre_enable;
intel_encoder-enable = vlv_enable_hdmi;
- intel_encoder-post_disable = intel_hdmi_post_disable;
+ intel_encoder-post_disable = vlv_hdmi_post_disable;
} else {
intel_encoder-enable = intel_enable_hdmi;
}
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replace has_bsd/blt/vebox with a mask
On Tue, Oct 15, 2013 at 10:02:57AM -0700, Ben Widawsky wrote: From: Ben Widawsky b...@bwidawsk.net I've sent this patch several times for various reasons. It essentially cleans up a lot of code where we need to do something per ring, and want to query whether or not the ring exists on that hardware. It has various uses coming up, but for now it shouldn't be too offensive. v2: Big conflict resolution on Damien's DEV_INFO_FOR_EACH stuff v3: Resolved vebox addition v4: Rebased after months of disuse. Also made failed ringbuffer init cleaner. v5: Remove the init cleaner from v4. There is a better way to do it. (Chris) Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net Series merged, thanks for patchesreview. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: HSW GT3 Slices: exec flag to warn kernel that userspace is using predication
On Tue, Oct 15, 2013 at 05:50:49PM -0300, Rodrigo Vivi wrote:
If Userspace isn't using MI_PREDICATE all slices must be enabled for
backward compatibility.
If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will
force
all slices on.
v2: fix the inverted logic for backwards compatibility
USE_PREDICATE unset force gt_full when defaul is half
instead of GT_FULL flag.
CC: Eric Anholt e...@anholt.net
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h| 8
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 67
++
drivers/gpu/drm/i915/i915_reg.h| 11 +
drivers/gpu/drm/i915/i915_sysfs.c | 11 -
drivers/gpu/drm/i915/intel_display.c | 6 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c| 39 -
include/uapi/drm/i915_drm.h| 8 +++-
8 files changed, 146 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 685fb1d..bd4774e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1219,6 +1219,12 @@ struct i915_package_c8 {
} regsave;
};
+struct i915_gt_slices {
+ int state_default;
Either use it as an integer (a count of slices enabled by default) or
make it an enum.
+ int forcing_full;
bool legacy_userspace_busy; ?
+ struct mutex m_lock;
Ugh. Just struct mutex lock; /* locks all access to this struct and
slice registers */ will suffice
+};
+
typedef struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1418,6 +1424,8 @@ typedef struct drm_i915_private {
struct i915_package_c8 pc8;
+ struct i915_gt_slices gt_slices;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ce0d47..eb09a51 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -923,6 +923,66 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
}
static int
+i915_gt_full_immediate(struct drm_device *dev, struct intel_ring_buffer
*ring)
That's a misnomer.
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ int ret;
+
+ if (!HAS_SLICE_SHUTDOWN(dev) || ring == dev_priv-ring[BCS])
+ return 0;
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, HSW_GT_SLICE_INFO);
+ intel_ring_emit(ring, SLICE_SEL_BOTH);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, MI_PREDICATE_RESULT_2);
+ intel_ring_emit(ring, LOWER_SLICE_ENABLED);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, HSW_SLICESHUTDOWN);
+ intel_ring_emit(ring, ~SLICE_SHUTDOWN);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
+ intel_ring_emit(ring, CS_IDLE_COUNT_1US);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, WAIT_FOR_RC6_EXIT);
+ intel_ring_emit(ring, WAIT_RC6_EXIT | MASK_WAIT_RC6_EXIT);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
+ intel_ring_emit(ring, CS_IDLE_COUNT_5US);
+ intel_ring_advance(ring);
+
+ return 0;
+}
+
+static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
struct drm_i915_gem_execbuffer2 *args,
@@ -999,6 +1059,13 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
return -EINVAL;
}
+ if ((args-flags I915_EXEC_USE_PREDICATE) == 0
+ dev_priv-gt_slices.state_default == 0
+ !dev_priv-gt_slices.forcing_full) {
Always set legacy_userspace_busy here so that a change in state_default
cannot possibly break currently active users i.e. they are independent
bookkeeping.
+ dev_priv-gt_slices.forcing_full =
[Intel-gfx] [PATCH v2 2/2] drm/i915: set HDMI pixel clock in audio configuration
The HDMI audio expects HDMI pixel clock to be set in the audio
configuration. We've currently just set 0, using 25.2 / 1.001 kHz
frequency, which fails with some modes.
v2: Now with a commit message.
Reference:
http://mid.gmane.org/cagpeb3ep1lrzetpxhgrfbdqr5ts2tac8gcukwwuguf1u5ny...@mail.gmail.com
Reference: http://mid.gmane.org/20130206213533.ga16...@hardeman.nu
Reported-by: David Härdeman da...@hardeman.nu
Reported-by: Jasper Smet josb...@gmail.com
Tested-by: Jasper Smet josb...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 12 -
drivers/gpu/drm/i915/intel_display.c | 48 +++---
2 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 13153c3..3266819 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4875,7 +4875,17 @@
#define AUD_CONFIG_LOWER_N_SHIFT 4
#define AUD_CONFIG_LOWER_N_VALUE (0xfff 4)
#define AUD_CONFIG_PIXEL_CLOCK_HDMI_SHIFT16
-#define AUD_CONFIG_PIXEL_CLOCK_HDMI (0xf 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK (0xf 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_25175(0 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_25200(1 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_27000(2 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_27027(3 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_54000(4 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_54054(5 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_74176(6 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_74250(7 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 (8 16)
+#define AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 (9 16)
#define AUD_CONFIG_DISABLE_NCTS (1 3)
/* HSW Audio */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 55740f2..a097f84 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6722,6 +6722,44 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
return 0;
}
+static struct {
+ int clock;
+ u32 config;
+} hdmi_audio_clock[] = {
+ { DIV_ROUND_UP(25200 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_25175 },
+ { 25200, AUD_CONFIG_PIXEL_CLOCK_HDMI_25200 }, /* default per bspec */
+ { 27000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27000 },
+ { 27000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27027 },
+ { 54000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54000 },
+ { 54000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54054 },
+ { DIV_ROUND_UP(74250 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_74176 },
+ { 74250, AUD_CONFIG_PIXEL_CLOCK_HDMI_74250 },
+ { DIV_ROUND_UP(148500 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_148352
},
+ { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
+};
+
+/* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
+static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(hdmi_audio_clock); i++) {
+ if (mode-clock == hdmi_audio_clock[i].clock)
+ break;
+ }
+
+ if (i == ARRAY_SIZE(hdmi_audio_clock)) {
+ DRM_DEBUG_KMS(HDMI audio pixel clock setting for %d not found,
falling back to defaults\n, mode-clock);
+ i = 1;
+ }
+
+ DRM_DEBUG_KMS(Configuring HDMI audio for pixel clock %d (0x%08x)\n,
+ hdmi_audio_clock[i].clock,
+ hdmi_audio_clock[i].config);
+
+ return hdmi_audio_clock[i].config;
+}
+
static bool intel_eld_uptodate(struct drm_connector *connector,
int reg_eldv, uint32_t bits_eldv,
int reg_elda, uint32_t bits_elda,
@@ -6847,8 +6885,9 @@ static void haswell_write_eld(struct drm_connector
*connector,
DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
eld[5] |= (1 2); /* Conn_Type, 0x1 = DisplayPort */
I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
- } else
- I915_WRITE(aud_config, 0);
+ } else {
+ I915_WRITE(aud_config, audio_config_hdmi_pixel_clock(mode));
+ }
if (intel_eld_uptodate(connector,
aud_cntrl_st2, eldv,
@@ -6926,8 +6965,9 @@ static void ironlake_write_eld(struct drm_connector
*connector,
DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
eld[5] |= (1 2); /* Conn_Type, 0x1 = DisplayPort */
I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
- } else
- I915_WRITE(aud_config, 0);
+ } else {
+ I915_WRITE(aud_config, audio_config_hdmi_pixel_clock(mode));
+ }
if (intel_eld_uptodate(connector,
aud_cntrl_st2, eldv,
--
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: pass mode to ELD write vfuncs
Mengdong, I meant to CC you on these two patches. Please have a look.
I also screwed up in-reply-to, was meant to be
http://mid.gmane.org/cover.1381765995.git.jani.nik...@intel.com
BR,
Jani.
On Wed, 16 Oct 2013, Jani Nikula jani.nik...@intel.com wrote:
This will be needed for setting the HDMI pixel clock for audio
config. No functional changes.
v2: Now with a commit message.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |3 ++-
drivers/gpu/drm/i915/intel_display.c | 11 +++
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6106d3d..caee590 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -379,7 +379,8 @@ struct drm_i915_display_funcs {
void (*crtc_disable)(struct drm_crtc *crtc);
void (*off)(struct drm_crtc *crtc);
void (*write_eld)(struct drm_connector *connector,
- struct drm_crtc *crtc);
+ struct drm_crtc *crtc,
+ struct drm_display_mode *mode);
void (*fdi_link_train)(struct drm_crtc *crtc);
void (*init_clock_gating)(struct drm_device *dev);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f1b636..55740f2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6752,7 +6752,8 @@ static bool intel_eld_uptodate(struct drm_connector
*connector,
}
static void g4x_write_eld(struct drm_connector *connector,
- struct drm_crtc *crtc)
+ struct drm_crtc *crtc,
+ struct drm_display_mode *mode)
{
struct drm_i915_private *dev_priv = connector-dev-dev_private;
uint8_t *eld = connector-eld;
@@ -6792,7 +6793,8 @@ static void g4x_write_eld(struct drm_connector
*connector,
}
static void haswell_write_eld(struct drm_connector *connector,
- struct drm_crtc *crtc)
+ struct drm_crtc *crtc,
+ struct drm_display_mode *mode)
{
struct drm_i915_private *dev_priv = connector-dev-dev_private;
uint8_t *eld = connector-eld;
@@ -6879,7 +6881,8 @@ static void haswell_write_eld(struct drm_connector
*connector,
}
static void ironlake_write_eld(struct drm_connector *connector,
- struct drm_crtc *crtc)
+struct drm_crtc *crtc,
+struct drm_display_mode *mode)
{
struct drm_i915_private *dev_priv = connector-dev-dev_private;
uint8_t *eld = connector-eld;
@@ -6974,7 +6977,7 @@ void intel_write_eld(struct drm_encoder *encoder,
connector-eld[6] = drm_av_sync_delay(connector, mode) / 2;
if (dev_priv-display.write_eld)
- dev_priv-display.write_eld(connector, crtc);
+ dev_priv-display.write_eld(connector, crtc, mode);
}
static void i845_update_cursor(struct drm_crtc *crtc, u32 base)
--
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
Re: [Intel-gfx] [PATCH] drm/i915: Move some hdmi enable function name to vlv specific.
On Wed, Oct 16, 2013 at 05:07:41PM +0800, Chon Ming Lee wrote:
There is no functional change on this patch. Only rename several
hdmi encoder function name which suppose to use only by valleyview from
intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
As a followup you could also remove the pointless IS_VALLEYVIEW() checks
from pre_enable and pre_pll_enable.
---
drivers/gpu/drm/i915/intel_hdmi.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 4f4d346..51a8336 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1074,7 +1074,7 @@ done:
return 0;
}
-static void intel_hdmi_pre_enable(struct intel_encoder *encoder)
+static void vlv_hdmi_pre_enable(struct intel_encoder *encoder)
{
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_device *dev = encoder-base.dev;
@@ -1127,7 +1127,7 @@ static void intel_hdmi_pre_enable(struct intel_encoder
*encoder)
vlv_wait_port_ready(dev_priv, port);
}
-static void intel_hdmi_pre_pll_enable(struct intel_encoder *encoder)
+static void vlv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
{
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_device *dev = encoder-base.dev;
@@ -1163,7 +1163,7 @@ static void intel_hdmi_pre_pll_enable(struct
intel_encoder *encoder)
mutex_unlock(dev_priv-dpio_lock);
}
-static void intel_hdmi_post_disable(struct intel_encoder *encoder)
+static void vlv_hdmi_post_disable(struct intel_encoder *encoder)
{
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
@@ -1313,10 +1313,10 @@ void intel_hdmi_init(struct drm_device *dev, int
hdmi_reg, enum port port)
intel_encoder-get_hw_state = intel_hdmi_get_hw_state;
intel_encoder-get_config = intel_hdmi_get_config;
if (IS_VALLEYVIEW(dev)) {
- intel_encoder-pre_pll_enable = intel_hdmi_pre_pll_enable;
- intel_encoder-pre_enable = intel_hdmi_pre_enable;
+ intel_encoder-pre_pll_enable = vlv_hdmi_pre_pll_enable;
+ intel_encoder-pre_enable = vlv_hdmi_pre_enable;
intel_encoder-enable = vlv_enable_hdmi;
- intel_encoder-post_disable = intel_hdmi_post_disable;
+ intel_encoder-post_disable = vlv_hdmi_post_disable;
} else {
intel_encoder-enable = intel_enable_hdmi;
}
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 1/2] drm/i915: static inline for dummy crc functions
Also use #ifdef to keep consistent with all other such cases.
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_irq.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9aeddc0..b39a548 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2235,10 +2235,10 @@ int i915_verify_lists(struct drm_device *dev);
/* i915_debugfs.c */
int i915_debugfs_init(struct drm_minor *minor);
void i915_debugfs_cleanup(struct drm_minor *minor);
-#if defined(CONFIG_DEBUG_FS)
+#ifdef CONFIG_DEBUG_FS
void intel_display_crc_init(struct drm_device *dev);
#else
-void intel_display_crc_init(struct drm_device *dev) {}
+static inline void intel_display_crc_init(struct drm_device *dev) {}
#endif
/* i915_gpu_error.c */
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b2be057..8c9148c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1225,7 +1225,7 @@ static void ivb_pipe_crc_update(struct drm_device *dev,
enum pipe pipe)
wake_up_interruptible(pipe_crc-wq);
}
#else
-static void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
+static inline void ivb_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
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: constify harder
We not only want const strings, but a const array of them. Reported by
checkpatch.pl
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d1674b6..5fce5d8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1909,7 +1909,7 @@ static int i915_pipe_crc_create(struct dentry *root,
struct drm_minor *minor,
return drm_add_fake_info_node(minor, ent, info);
}
-static const char *pipe_crc_sources[] = {
+static const char * const pipe_crc_sources[] = {
none,
plane1,
plane2,
@@ -2054,7 +2054,7 @@ enum intel_pipe_crc_object {
PIPE_CRC_OBJECT_PIPE,
};
-static const char *pipe_crc_objects[] = {
+static const char * const pipe_crc_objects[] = {
pipe,
};
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Pipe CRCs v1
On Tue, Oct 15, 2013 at 06:55:26PM +0100, Damien Lespiau wrote: This series exposes the pipe CRCs on ivybridge through debugfs. It's based on the initial work from Shuang He, with some improvements to have a nice user space API. There are several points in the display pipeline where CRCs can be computed on the bits flowing there. For instance, it's usually possible to compute the CRCs of the primary plane, the sprite plane or the CRCs of the bits after the panel fitter (collectively called pipe CRCs). An intel-gpu-tools series will follow with helpers to use the feature from tests and basic testing. Further work items: * make it work on other platforms * expose other CRCs than just the pipe CRCs (transcoders, ddi, ...) * implement poll() for the result files I like this and so went ahead and merged it right away. A bit of CRC support is much better than none and the tests should make sure that things actually work somewhat. Polishing that imo still needs to happen: - Roll out on other platforms. Especially vlv since there we actually want to have good sprite support. - Add an all alias or something similar which just picks a crc source take takes the pixels after all sprite/cursor/plane blending, csc and gamma ramps have been applied. For ivb that seems to be the pf source. To make sure it works we'd need a small testcase that moves cursors/sprites/planes and changes gamma to make sure we cover all these things. Then we could finally have automated testcases for checking all the restore code in our resume paths (or dpms on and all that stuff). - atomic_t is weakly ordered, even on x86 (since it doesn't even have). Also, writing a correct lockless ringbuffer is Damn Hard (tm). I don't see any need to massive performance issues with this, so we need to switch to normal mutex locking (with a spinlock for the ringbuffer itself to allow the irq handler to fill it). - Use it all over the place in igt tests ... Thanks a lot for doing this. 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
Re: [Intel-gfx] [PATCH] drm/i915: Move some hdmi enable function name to vlv specific.
On Wed, Oct 16, 2013 at 05:07:41PM +0800, Chon Ming Lee wrote: There is no functional change on this patch. Only rename several hdmi encoder function name which suppose to use only by valleyview from intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc. Signed-off-by: Chon Ming Lee chon.ming@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/16] drm/i915: Expose latest 200 CRC value for pipe through debugfs
On Tue, Oct 15, 2013 at 06:55:27PM +0100, Damien Lespiau wrote:
From: Shuang He shuang...@intel.com
There are several points in the display pipeline where CRCs can be
computed on the bits flowing there. For instance, it's usually possible
to compute the CRCs of the primary plane, the sprite plane or the CRCs
of the bits after the panel fitter (collectively called pipe CRCs).
v2: Quite a bit of rework here and there (Damien)
Signed-off-by: Shuang He shuang...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 +
drivers/gpu/drm/i915/i915_drv.h | 16
drivers/gpu/drm/i915/i915_irq.c | 35 +++
drivers/gpu/drm/i915/i915_reg.h | 36 +++-
4 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 72d0458..e1d45aa 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1732,6 +1732,36 @@ static int i915_pc8_status(struct seq_file *m, void
*unused)
return 0;
}
+static int i915_pipe_crc(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ enum pipe pipe = (enum pipe)node-info_ent-data;
+ const struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
+ int i;
+ int start;
+
+ if (!IS_IVYBRIDGE(dev)) {
+ seq_puts(m, unsupported\n);
+ return 0;
+ }
+
+ start = atomic_read(pipe_crc-slot) + 1;
+ seq_puts(m, timestamp CRC1 CRC2 CRC3 CRC4
CRC5\n);
+ for (i = 0; i INTEL_PIPE_CRC_ENTRIES_NR; i++) {
+ const struct intel_pipe_crc_entry *entry =
+ pipe_crc-entries[(start + i) %
+INTEL_PIPE_CRC_ENTRIES_NR];
+
+ seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
+entry-crc[0], entry-crc[1], entry-crc[2],
+entry-crc[3], entry-crc[4]);
+ }
+
+ return 0;
+}
+
static int
i915_wedged_get(void *data, u64 *val)
{
@@ -2247,6 +2277,9 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_edp_psr_status, i915_edp_psr_status, 0},
{i915_energy_uJ, i915_energy_uJ, 0},
{i915_pc8_status, i915_pc8_status, 0},
+ {i915_pipe_A_crc, i915_pipe_crc, 0, (void *)PIPE_A},
+ {i915_pipe_B_crc, i915_pipe_crc, 0, (void *)PIPE_B},
+ {i915_pipe_C_crc, i915_pipe_crc, 0, (void *)PIPE_C},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6106d3d..6855d91 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1219,6 +1219,18 @@ struct i915_package_c8 {
} regsave;
};
+struct intel_pipe_crc_entry {
+ uint32_t timestamp;
+ uint32_t crc[5];
+};
+
+#define INTEL_PIPE_CRC_ENTRIES_NR200
+struct intel_pipe_crc {
+ struct intel_pipe_crc_entry entries[INTEL_PIPE_CRC_ENTRIES_NR];
+ enum intel_pipe_crc_source source;
+ atomic_t slot;
+};
+
typedef struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1423,6 +1435,10 @@ typedef struct drm_i915_private {
struct i915_dri1_state dri1;
/* Old ums support infrastructure, same warning applies. */
struct i915_ums_state ums;
+
+#ifdef CONFIG_DEBUG_FS
+ struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
+#endif
Should we keep this in intel_crtc perhaps?
} drm_i915_private_t;
static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 26753b6..d2074f1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1188,6 +1188,32 @@ static void dp_aux_irq_handler(struct drm_device *dev)
wake_up_all(dev_priv-gmbus_wait_queue);
}
+#if defined(CONFIG_DEBUG_FS)
+static void ivb_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
+ struct intel_pipe_crc_entry *entry;
+ ktime_t now;
+ int ts, slot;
+
+ now = ktime_get();
+ ts = ktime_to_us(now);
+
+ slot = (atomic_read(pipe_crc-slot) + 1) % INTEL_PIPE_CRC_ENTRIES_NR;
Looks like using atomic_t for 'slot' doesn't really help us in any way.
+ entry = pipe_crc-entries[slot];
+ entry-timestamp = ts;
+ entry-crc[0] = I915_READ(PIPE_CRC_RES_1_IVB(pipe));
+ entry-crc[1] =
[Intel-gfx] [PATCH] drm/i915: Disable all GEM timers and work on unload
We have two once very similar functions, i915_gpu_idle() and
i915_gem_idle(). The former is used as the lower level operation to
flush work on the GPU, whereas the latter is the high level interface to
flush the GEM bookkeeping in addition to flushing the GPU. As such
i915_gem_idle() also clears out the request and activity lists and
cancels the delayed work. This is what we need for unloading the driver,
unfortunately we called i915_gpu_idle() instead.
In the process, make sure that when cancelling the delayed work and
timer, which is synchronous, that we do not hold any locks to prevent a
deadlock if the work item is already waiting upon the mutex. This
requires us to push the mutex down from the caller to i915_gem_idle().
v2: s/i915_gem_idle/i915_gem_suspend/
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Tested-by: xunx.f...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c |8 +--
drivers/gpu/drm/i915/i915_drv.c |4 +---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c | 44 +--
4 files changed, 22 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e35f29..fd6c46b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1699,15 +1699,9 @@ int i915_driver_unload(struct drm_device *dev)
if (dev_priv-mm.inactive_shrinker.scan_objects)
unregister_shrinker(dev_priv-mm.inactive_shrinker);
- mutex_lock(dev-struct_mutex);
- ret = i915_gpu_idle(dev);
+ ret = i915_gem_suspend(dev);
if (ret)
DRM_ERROR(failed to idle hardware: %d\n, ret);
- i915_gem_retire_requests(dev);
- mutex_unlock(dev-struct_mutex);
-
- /* Cancel the retire work handler, which should be idle now. */
- cancel_delayed_work_sync(dev_priv-mm.retire_work);
io_mapping_free(dev_priv-gtt.mappable);
arch_phys_wc_del(dev_priv-gtt.mtrr);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59649c0..cd05cc7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -479,9 +479,7 @@ static int i915_drm_freeze(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
int error;
- mutex_lock(dev-struct_mutex);
- error = i915_gem_idle(dev);
- mutex_unlock(dev-struct_mutex);
+ error = i915_gem_suspend(dev);
if (error) {
dev_err(dev-pdev-dev,
GEM idle failed, resume might fail\n);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e0152e7..daefba4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2039,7 +2039,7 @@ int i915_gem_l3_remap(struct intel_ring_buffer *ring, int
slice);
void i915_gem_init_swizzling(struct drm_device *dev);
void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int __must_check i915_gpu_idle(struct drm_device *dev);
-int __must_check i915_gem_idle(struct drm_device *dev);
+int __must_check i915_gem_suspend(struct drm_device *dev);
int __i915_add_request(struct intel_ring_buffer *ring,
struct drm_file *file,
struct drm_i915_gem_object *batch_obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 63dbd3c..2ff35b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4401,17 +4401,18 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
}
int
-i915_gem_idle(struct drm_device *dev)
+i915_gem_suspend(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
- int ret;
+ int ret = 0;
+ mutex_lock(dev-struct_mutex);
if (dev_priv-ums.mm_suspended)
- return 0;
+ goto err;
ret = i915_gpu_idle(dev);
if (ret)
- return ret;
+ goto err;
i915_gem_retire_requests(dev);
@@ -4419,16 +4420,25 @@ i915_gem_idle(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_gem_evict_everything(dev);
- del_timer_sync(dev_priv-gpu_error.hangcheck_timer);
-
i915_kernel_lost_context(dev);
i915_gem_cleanup_ringbuffer(dev);
- /* Cancel the retire work handler, which should be idle now. */
+ /* Hack! Don't let anybody do execbuf while we don't control the chip.
+* We need to replace this with a semaphore, or something.
+* And not confound ums.mm_suspended!
+*/
+ dev_priv-ums.mm_suspended = true;
+ mutex_unlock(dev-struct_mutex);
+
+ del_timer_sync(dev_priv-gpu_error.hangcheck_timer);
cancel_delayed_work_sync(dev_priv-mm.retire_work);
Re: [Intel-gfx] [PATCH 4/5] drm/i915: take power well refs when needed
On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote: On Tue, 15 Oct 2013 16:54:00 -0300 Paulo Zanoni przan...@gmail.com wrote: [...] No that's taken into account here. In __intel_set_mode we take a private ref on the appropriate power well so that we'll preserve state until we do the first crtc_enable. From then on, the ref is tracked there and we drop the private one in __intel_set_mode + if (crtc-active) + intel_display_power_get(dev, + POWER_DOMAIN_PIPE(crtc-pipe)); + What about the panel fitter power domains? Sometimes the panel fitter is the thing that makes you require a power well, even though you're on a pipe that doesn't need it. And on Haswell you also have to take into account TRANSCODER_EDP+PIPE_A versus TRANSCODER_A+PIPE_A, where the first doesn't need the power well but the second needs it. Yeah I'm still not sure how to handle this in generic code. Maybe the power well mapping function Imre added will be enough, but it definitely gets tricky when we look at all the different platforms we have to (and will have to) handle. Isn't the power domain abstraction a neat idea exactly for the above case? Generic code just asks for the domain it needs and doesn't care how it maps to power wells on the given platform. So for transcoder_edp +pipe_a it'd end up asking for POWER_DOMAIN_PIPE_A and POWER_DOMAIN_TRANSCODER_EDP, both of which is a nop on HSW, and for the other case POWER_DOMAIN_PIPE_A and POWER_DOMAIN_TRANSCODER_A which would enable the power well. You also have the POWER_DOMAIN_PIPE, POWER_DOMAIN_TRANSCODER, POWER_DOMAIN_PIPE_PANEL_FITTER helpers already. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use pipe_name() instead of the pipe number
Yet other direct usages of the pipe number instead of pipe_name(). We've been tracking them lately but managed to miss these last ones. v2: Catch them all! (Ville) Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com (v1) Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- drivers/gpu/drm/i915/intel_dsi.c | 2 +- drivers/gpu/drm/i915/intel_panel.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4f1b636..5a40b29 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -10730,11 +10730,11 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev) } encoder-connectors_active = false; - DRM_DEBUG_KMS([ENCODER:%d:%s] hw state readout: %s, pipe=%i\n, + DRM_DEBUG_KMS([ENCODER:%d:%s] hw state readout: %s, pipe %c\n, encoder-base.base.id, drm_get_encoder_name(encoder-base), encoder-base.crtc ? enabled : disabled, - pipe); + pipe_name(pipe)); } list_for_each_entry(connector, dev-mode_config.connector_list, diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 9a2fdd2..d257b09 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -350,7 +350,7 @@ static void intel_dsi_mode_set(struct intel_encoder *intel_encoder) unsigned int bpp = intel_crtc-config.pipe_bpp; u32 val, tmp; - DRM_DEBUG_KMS(pipe %d\n, pipe); + DRM_DEBUG_KMS(pipe %c\n, pipe_name(pipe)); /* Update the DSI PLL */ vlv_enable_dsi_pll(intel_encoder); diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 1f29960..de15186 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -574,7 +574,7 @@ void intel_panel_enable_backlight(struct drm_device *dev, intel_pipe_to_cpu_transcoder(dev_priv, pipe); unsigned long flags; - DRM_DEBUG_KMS(pipe=%d\n, pipe); + DRM_DEBUG_KMS(pipe %c\n, pipe_name(pipe)); spin_lock_irqsave(dev_priv-backlight.lock, flags); -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable all GEM timers and work on unload
On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote: We have two once very similar functions, i915_gpu_idle() and i915_gem_idle(). The former is used as the lower level operation to flush work on the GPU, whereas the latter is the high level interface to flush the GEM bookkeeping in addition to flushing the GPU. As such i915_gem_idle() also clears out the request and activity lists and cancels the delayed work. This is what we need for unloading the driver, unfortunately we called i915_gpu_idle() instead. In the process, make sure that when cancelling the delayed work and timer, which is synchronous, that we do not hold any locks to prevent a deadlock if the work item is already waiting upon the mutex. This requires us to push the mutex down from the caller to i915_gem_idle(). v2: s/i915_gem_idle/i915_gem_suspend/ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Tested-by: xunx.f...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: HSW GT3 Slices: exec flag to warn kernel that userspace is using predication
Hi Chris,
Thank you very much for all suggestions. Will do the changes. But for
that question below I don't have the clear answer:
On Wed, Oct 16, 2013 at 6:15 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Oct 15, 2013 at 05:50:49PM -0300, Rodrigo Vivi wrote:
If Userspace isn't using MI_PREDICATE all slices must be enabled for
backward compatibility.
If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will
force
all slices on.
v2: fix the inverted logic for backwards compatibility
USE_PREDICATE unset force gt_full when defaul is half
instead of GT_FULL flag.
CC: Eric Anholt e...@anholt.net
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h| 8
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 67
++
drivers/gpu/drm/i915/i915_reg.h| 11 +
drivers/gpu/drm/i915/i915_sysfs.c | 11 -
drivers/gpu/drm/i915/intel_display.c | 6 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c| 39 -
include/uapi/drm/i915_drm.h| 8 +++-
8 files changed, 146 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 685fb1d..bd4774e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1219,6 +1219,12 @@ struct i915_package_c8 {
} regsave;
};
+struct i915_gt_slices {
+ int state_default;
Either use it as an integer (a count of slices enabled by default) or
make it an enum.
+ int forcing_full;
bool legacy_userspace_busy; ?
+ struct mutex m_lock;
Ugh. Just struct mutex lock; /* locks all access to this struct and
slice registers */ will suffice
+};
+
typedef struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1418,6 +1424,8 @@ typedef struct drm_i915_private {
struct i915_package_c8 pc8;
+ struct i915_gt_slices gt_slices;
+
/* Old dri1 support infrastructure, beware the dragons ya fools
entering
* here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ce0d47..eb09a51 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -923,6 +923,66 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
}
static int
+i915_gt_full_immediate(struct drm_device *dev, struct intel_ring_buffer
*ring)
That's a misnomer.
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ int ret;
+
+ if (!HAS_SLICE_SHUTDOWN(dev) || ring == dev_priv-ring[BCS])
+ return 0;
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, HSW_GT_SLICE_INFO);
+ intel_ring_emit(ring, SLICE_SEL_BOTH);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, MI_PREDICATE_RESULT_2);
+ intel_ring_emit(ring, LOWER_SLICE_ENABLED);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, HSW_SLICESHUTDOWN);
+ intel_ring_emit(ring, ~SLICE_SHUTDOWN);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
+ intel_ring_emit(ring, CS_IDLE_COUNT_1US);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, WAIT_FOR_RC6_EXIT);
+ intel_ring_emit(ring, WAIT_RC6_EXIT | MASK_WAIT_RC6_EXIT);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
+ intel_ring_emit(ring, CS_IDLE_COUNT_5US);
+ intel_ring_advance(ring);
+
+ return 0;
+}
+
+static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
struct drm_i915_gem_execbuffer2 *args,
@@ -999,6 +1059,13 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
return -EINVAL;
}
+ if ((args-flags I915_EXEC_USE_PREDICATE) == 0
+ dev_priv-gt_slices.state_default == 0
+ !dev_priv-gt_slices.forcing_full) {
Re: [Intel-gfx] [PATCH 3/4] drm/i915: HSW GT3 Slices: exec flag to warn kernel that userspace is using predication
On Wed, Oct 16, 2013 at 09:12:46AM -0300, Rodrigo Vivi wrote: + dev_priv-gt_slices.forcing_full = true; + i915_gt_full_immediate(dev, ring); What happens when this fails? If it only partially emits the commands, etc. This is a very good question. If it fails, my only concern would be the sync between HSW_GT_SLICE_INFO and MI_PREDICATE_RESULT_2. But I don't know how to do this during the exec buf without delaying the execution. Do you have any suggestion? Reduce the series of if() to just one, act upon the return value, only set legacy_userspace_busy to true after making the change. It will eventually get cleaned up if the dispatch later fails, but we must make sure that we accurately track hardware state. -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 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 991abff..58c6fd4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1748,14 +1748,14 @@ static int i915_pipe_crc(struct seq_file *m, void
*data)
return 0;
}
- seq_puts(m, timestamp CRC1 CRC2 CRC3 CRC4
CRC5\n);
+ seq_puts(m, frameCRC1 CRC2 CRC3 CRC4 CRC5\n);
head = atomic_read(pipe_crc-head);
tail = atomic_read(pipe_crc-tail);
while (CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) = 1) {
struct intel_pipe_crc_entry *entry = pipe_crc-entries[tail];
- seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
+ seq_printf(m, %8u %8x %8x %8x %8x %8x\n, entry-frame,
entry-crc[0], entry-crc[1], entry-crc[2],
entry-crc[3], entry-crc[4]);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a1ed3a..cd87919 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1228,7 +1228,7 @@ enum intel_pipe_crc_source {
};
struct intel_pipe_crc_entry {
- uint32_t timestamp;
+ uint32_t frame;
uint32_t crc[5];
};
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73d76af..0b21828 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1195,8 +1195,7 @@ static void ivb_pipe_crc_update(struct drm_device *dev,
enum pipe pipe)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
- ktime_t now;
- int ts, head, tail;
+ int head, tail;
head = atomic_read(pipe_crc-head);
tail = atomic_read(pipe_crc-tail);
@@ -1208,10 +1207,7 @@ static void ivb_pipe_crc_update(struct drm_device
*dev, enum pipe pipe)
entry = pipe_crc-entries[head];
- now = ktime_get();
- ts = ktime_to_us(now);
-
- entry-timestamp = ts;
+ entry-frame = I915_READ(PIPEFRAME(pipe));
BTW that's the wrong register for ctg+. It should be PIPE_FRMCOUNT_GM45.
But it would be better if you just call
dev-driver-get_vblank_counter(). Then you get the correct answer for
everything except gen2, and for gen2 we could implement a software
frame counter if need be.
entry-crc[0] = I915_READ(PIPE_CRC_RES_1_IVB(pipe));
entry-crc[1] = I915_READ(PIPE_CRC_RES_2_IVB(pipe));
entry-crc[2] = I915_READ(PIPE_CRC_RES_3_IVB(pipe));
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs
On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 991abff..58c6fd4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1748,14 +1748,14 @@ static int i915_pipe_crc(struct seq_file *m, void
*data)
return 0;
}
- seq_puts(m, timestamp CRC1 CRC2 CRC3 CRC4
CRC5\n);
+ seq_puts(m, frameCRC1 CRC2 CRC3 CRC4 CRC5\n);
head = atomic_read(pipe_crc-head);
tail = atomic_read(pipe_crc-tail);
while (CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) = 1) {
struct intel_pipe_crc_entry *entry = pipe_crc-entries[tail];
- seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
+ seq_printf(m, %8u %8x %8x %8x %8x %8x\n, entry-frame,
entry-crc[0], entry-crc[1], entry-crc[2],
entry-crc[3], entry-crc[4]);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 7a1ed3a..cd87919 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1228,7 +1228,7 @@ enum intel_pipe_crc_source {
};
struct intel_pipe_crc_entry {
- uint32_t timestamp;
+ uint32_t frame;
uint32_t crc[5];
};
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 73d76af..0b21828 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1195,8 +1195,7 @@ static void ivb_pipe_crc_update(struct drm_device
*dev, enum pipe pipe)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
- ktime_t now;
- int ts, head, tail;
+ int head, tail;
head = atomic_read(pipe_crc-head);
tail = atomic_read(pipe_crc-tail);
@@ -1208,10 +1207,7 @@ static void ivb_pipe_crc_update(struct drm_device
*dev, enum pipe pipe)
entry = pipe_crc-entries[head];
- now = ktime_get();
- ts = ktime_to_us(now);
-
- entry-timestamp = ts;
+ entry-frame = I915_READ(PIPEFRAME(pipe));
BTW that's the wrong register for ctg+. It should be PIPE_FRMCOUNT_GM45.
But it would be better if you just call
dev-driver-get_vblank_counter(). Then you get the correct answer for
everything except gen2, and for gen2 we could implement a software
frame counter if need be.
Hm, maybe we should even cobble it out of the drm vblank support code, to
make sure that the vblank frame numbers from the crc debugfs align with
timestamps for pageflips. But this is definitely a good idea. And afaik
gen2 doesn't have crc support (not even gen3 iirc). I'll do this in my
bikeshed series.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs
On Wed, Oct 16, 2013 at 03:51:40PM +0200, Daniel Vetter wrote:
On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 991abff..58c6fd4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1748,14 +1748,14 @@ static int i915_pipe_crc(struct seq_file *m, void
*data)
return 0;
}
- seq_puts(m, timestamp CRC1 CRC2 CRC3 CRC4
CRC5\n);
+ seq_puts(m, frameCRC1 CRC2 CRC3 CRC4 CRC5\n);
head = atomic_read(pipe_crc-head);
tail = atomic_read(pipe_crc-tail);
while (CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) = 1) {
struct intel_pipe_crc_entry *entry = pipe_crc-entries[tail];
- seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
+ seq_printf(m, %8u %8x %8x %8x %8x %8x\n, entry-frame,
entry-crc[0], entry-crc[1], entry-crc[2],
entry-crc[3], entry-crc[4]);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 7a1ed3a..cd87919 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1228,7 +1228,7 @@ enum intel_pipe_crc_source {
};
struct intel_pipe_crc_entry {
- uint32_t timestamp;
+ uint32_t frame;
uint32_t crc[5];
};
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 73d76af..0b21828 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1195,8 +1195,7 @@ static void ivb_pipe_crc_update(struct drm_device
*dev, enum pipe pipe)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
- ktime_t now;
- int ts, head, tail;
+ int head, tail;
head = atomic_read(pipe_crc-head);
tail = atomic_read(pipe_crc-tail);
@@ -1208,10 +1207,7 @@ static void ivb_pipe_crc_update(struct drm_device
*dev, enum pipe pipe)
entry = pipe_crc-entries[head];
- now = ktime_get();
- ts = ktime_to_us(now);
-
- entry-timestamp = ts;
+ entry-frame = I915_READ(PIPEFRAME(pipe));
BTW that's the wrong register for ctg+. It should be PIPE_FRMCOUNT_GM45.
But it would be better if you just call
dev-driver-get_vblank_counter(). Then you get the correct answer for
everything except gen2, and for gen2 we could implement a software
frame counter if need be.
Hm, maybe we should even cobble it out of the drm vblank support code, to
make sure that the vblank frame numbers from the crc debugfs align with
timestamps for pageflips. But this is definitely a good idea. And afaik
gen2 doesn't have crc support (not even gen3 iirc). I'll do this in my
bikeshed series.
I see crc registers in both gen2 and 3 bspec.
--
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 1/2] drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
This is useful with the follow-up patch that frobs
dev_priv-vbt.edp_bpp, and the value no longer comes directly from VBT.
---
drivers/gpu/drm/i915/intel_dp.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e4fdedc..f63aa8c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -822,10 +822,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
/* Walk through all bpp values. Luckily they're all nicely spaced with 2
* bpc in between. */
bpp = pipe_config-pipe_bpp;
- if (is_edp(intel_dp) dev_priv-vbt.edp_bpp) {
+ if (is_edp(intel_dp) dev_priv-vbt.edp_bpp
+ dev_priv-vbt.edp_bpp bpp) {
DRM_DEBUG_KMS(clamping bpp for eDP panel to BIOS-provided
%i\n,
dev_priv-vbt.edp_bpp);
- bpp = min_t(int, bpp, dev_priv-vbt.edp_bpp);
+ bpp = dev_priv-vbt.edp_bpp;
}
for (; bpp = 6*3; bpp -= 2*3) {
--
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 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs
On Wed, Oct 16, 2013 at 03:51:40PM +0200, Daniel Vetter wrote:
On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 991abff..58c6fd4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1748,14 +1748,14 @@ static int i915_pipe_crc(struct seq_file *m, void
*data)
return 0;
}
- seq_puts(m, timestamp CRC1 CRC2 CRC3 CRC4
CRC5\n);
+ seq_puts(m, frameCRC1 CRC2 CRC3 CRC4 CRC5\n);
head = atomic_read(pipe_crc-head);
tail = atomic_read(pipe_crc-tail);
while (CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) = 1) {
struct intel_pipe_crc_entry *entry = pipe_crc-entries[tail];
- seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
+ seq_printf(m, %8u %8x %8x %8x %8x %8x\n, entry-frame,
entry-crc[0], entry-crc[1], entry-crc[2],
entry-crc[3], entry-crc[4]);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 7a1ed3a..cd87919 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1228,7 +1228,7 @@ enum intel_pipe_crc_source {
};
struct intel_pipe_crc_entry {
- uint32_t timestamp;
+ uint32_t frame;
uint32_t crc[5];
};
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 73d76af..0b21828 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1195,8 +1195,7 @@ static void ivb_pipe_crc_update(struct drm_device
*dev, enum pipe pipe)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
- ktime_t now;
- int ts, head, tail;
+ int head, tail;
head = atomic_read(pipe_crc-head);
tail = atomic_read(pipe_crc-tail);
@@ -1208,10 +1207,7 @@ static void ivb_pipe_crc_update(struct drm_device
*dev, enum pipe pipe)
entry = pipe_crc-entries[head];
- now = ktime_get();
- ts = ktime_to_us(now);
-
- entry-timestamp = ts;
+ entry-frame = I915_READ(PIPEFRAME(pipe));
BTW that's the wrong register for ctg+. It should be PIPE_FRMCOUNT_GM45.
But it would be better if you just call
dev-driver-get_vblank_counter(). Then you get the correct answer for
everything except gen2, and for gen2 we could implement a software
frame counter if need be.
Hm, maybe we should even cobble it out of the drm vblank support code, to
make sure that the vblank frame numbers from the crc debugfs align with
timestamps for pageflips.
Well the frame numbers reported to userspace by vblank/page flip code
are based on a software counter maintained by the drm vblank code.
.get_vblank_counter() is the real hardware counter. I guess you mean
that we should try to report the software counter for userspace here
as well. Sounds reasonable.
--
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 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue
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
---
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/6] preparation for multiple power-wells
This is a prepration for adding support for multiple power-wells needed by future HW platforms. I pushed the rest of the enabling patches to [1]. I'd like to post the generic parts of those once we agreed how to do the power-well abstraction. Except a spinlock-mutex change these patches shouldn't cause any functional change. I tested it on VLV/HSW VGA by doing a manual DPMS on/off and checking that the power-well indeed toggles. Also on HSW I checked that the audio power well release/request still works by doing a rmmod/insmod snd_hda_intel. [1] https://github.com/ideak/linux/commits/powerwells Imre Deak (6): drm/i915: make the intel_display_power_domain enum compact drm/i915: factor out is_always_on_domain drm/i915: change power_well-lock to be mutex drm/i915: factor out modeset_update_power_wells drm/i915: enable only the needed power domains during modeset drm/i915: use power get/put instead of set for power on after init drivers/gpu/drm/i915/i915_dma.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 23 -- drivers/gpu/drm/i915/intel_display.c | 69 -- drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_pm.c | 133 ++- 6 files changed, 124 insertions(+), 107 deletions(-) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915: make the intel_display_power_domain enum compact
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,
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: factor out modeset_update_power_wells
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);
}
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: enable only the needed power domains during modeset
So far the modeset code enabled all power domains if it needed any. It
wasn't a problem since HW generations so far only had one always-on
power well and one dynamic power well that can be enabled/disabled. For
domains powered by always-on power wells (panel fitter on pipe A and the
eDP transcoder) we didn't do anything, for all other domains we just
enabled the single dynamic power well.
Future HW generations will change this, as they add multiple dynamic
power wells. Support for these will be added later, this patch prepares
for those by making sure we only enable the required domains.
Note that after this change on HSW we'll enable all power domains even
if it was the domain for the panel fitter on pipe A or the eDP
transcoder. This isn't a problem since the power domain framework
already checks if the domain is on an always-on power well and doesn't
do anything in this case.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 46
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8e734f2..e2a4f3b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6561,21 +6561,57 @@ static void hsw_package_c8_gpu_busy(struct
drm_i915_private *dev_priv)
}
}
+#define for_each_power_domain(domain, mask)\
+ for ((domain) = 0; (domain) POWER_DOMAIN_NUM; (domain)++) \
+ if ((1 (domain)) (mask))
+
+static unsigned long get_pipe_power_domains(struct drm_device *dev,
+ enum pipe pipe, bool pfit_enabled)
+{
+ unsigned long mask;
+ enum transcoder transcoder;
+
+ transcoder = intel_pipe_to_cpu_transcoder(dev-dev_private, pipe);
+
+ mask = BIT(POWER_DOMAIN_PIPE(pipe));
+ mask |= BIT(POWER_DOMAIN_TRANSCODER(transcoder));
+ if (pfit_enabled)
+ mask |= BIT(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe));
+
+ return mask;
+}
+
static void modeset_update_power_wells(struct drm_device *dev)
{
- bool enable = false;
+ unsigned long pipe_domains[I915_MAX_PIPES] = { 0, };
struct intel_crtc *crtc;
+ /*
+* First get all needed power domains, then put all unneeded, to avoid
+* any unnecessary toggling of the power wells.
+*/
list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) {
+ enum intel_display_power_domain domain;
+
if (!crtc-base.enabled)
continue;
- if (crtc-pipe != PIPE_A || crtc-config.pch_pfit.enabled ||
- crtc-config.cpu_transcoder != TRANSCODER_EDP)
- enable = true;
+ pipe_domains[crtc-pipe] = get_pipe_power_domains(dev,
+ crtc-pipe,
+ crtc-config.pch_pfit.enabled);
+
+ for_each_power_domain(domain, pipe_domains[crtc-pipe])
+ intel_display_power_get(dev, domain);
}
- intel_set_power_well(dev, enable);
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) {
+ enum intel_display_power_domain domain;
+
+ for_each_power_domain(domain, crtc-enabled_power_domains)
+ intel_display_power_put(dev, domain);
+
+ crtc-enabled_power_domains = pipe_domains[crtc-pipe];
+ }
}
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 189257d..63a5bfd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -320,6 +320,7 @@ struct intel_crtc {
* some outputs connected to this crtc.
*/
bool active;
+ unsigned long enabled_power_domains;
bool eld_vld;
bool primary_enabled; /* is the primary plane (partially) visible? */
bool lowfreq_avail;
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: factor out is_always_on_domain
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 POWER_DOMAIN_PIPE_C_PANEL_FITTER:
- case
[Intel-gfx] [PATCH 6/6] drm/i915: use power get/put instead of set for power on after init
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 i915_disable_vga_mem(struct drm_device *dev);
void hsw_enable_ips(struct intel_crtc *crtc);
void hsw_disable_ips(struct intel_crtc
Re: [Intel-gfx] Patch for crashing intel server
On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote: This does indeed stop the server from crashing, but actually makes the problem worse: it used to play video for a few minutes and then crash when trying. With my patch it would play video for a few minutes and then present black screens when trying. With your patch, it presents black screens from the start. Start of video, or beginning of X? Beginning of X. After starting and logging in, I can play them for a few minutes; afterwards it will crash. I must say I'm not entirely sure if the backtrace I sent you is a typical case; I managed to crash it sooner than usual, so perhaps it wasn't the bug that I triggered before. It did stop the crashing however. However, that still leaveas the question as to how you ended up being unable to allocate bo... I didn't check the backtrace myself, but when I wrote my shotgun-patch, the problem was that pixmap_private was NULL; bo is in there, right? So at least in that case, it could never have allocated it, or at least it couldn't store the pointer. While looking for it I did find and try intel-gpu-time, and noticed that it always reports the gpu 100% busy, even when running intel-gpu-time sleep 5 from a linux virtual terminal (so not even X is displayed). Is that normal? Hmm, looks like it should report correctly on i915. Due to unrelated problems (unbearable slowness) I switched from gnome to xfce. It does report 0% now. It seems gnome keeps the gpu busy even if it's not displaying anything... Thanks, Bas signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Runtime display PM for VLV/BYT
On Wed, 2013-10-16 at 00:09 +0200, Daniel Vetter wrote: On Tue, Oct 15, 2013 at 8:15 PM, Imre Deak imre.d...@intel.com wrote: Related to this: I made intel_encoder_get_hw_state() only check if the power well is on and return false if it's not to indicate that the encoder is off. I also thought of doing the same as you and take a ref instead, not sure what's the right way. Maybe doing the readout only if the power is on, but also making sure we have a reference in this case? So with a new helper we'd have in intel_encoder_get_hw_state(): I think the approach we've quickly discussed in today's call is probably simplest: We grab a temporary reference to all the display power wells around all the dpms/modeset functions and ignore any power well checks on top of that. The hw will (well, should) be in the power on default state, so nothing should magically turn on if we don't want that. Ok, I'm fine with this too for now, later it can be improved if needed. I added a new POWER_DOMAIN_INIT for keeping all power wells on through driver init-first modeset and suspend-first modeset, that could be used for this purpose too. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm: add support for additional stereo 3D modes
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
v2: Use (1 0) for consistency. (Ville Syrjälä)
Skip adding any modes if 3D_MASK is indicated as being present but
the length only includes 3D_Structure_ALL. (Ville Syrjälä)
Check that the value of HDMI_3D_LEN is large enough to include
3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä)
v3: Increment offset before the length checks. (Ville Syrjälä)
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
drivers/gpu/drm/drm_edid.c | 103 +
1 file changed, 94 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9e81609..f1764ec 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2652,6 +2652,50 @@ static int add_hdmi_mode(struct drm_connector
*connector, u8 vic)
return 1;
}
+static int add_3d_struct_modes(struct drm_connector *connector, u16 structure,
+ const u8 *video_db, u8 video_len, u8 video_index)
+{
+ struct drm_device *dev = connector-dev;
+ struct drm_display_mode *newmode;
+ int modes = 0;
+ u8 cea_mode;
+
+ if (video_db == NULL || video_index video_len)
+ return 0;
+
+ /* CEA modes are numbered 1..127 */
+ cea_mode = (video_db[video_index] 127) - 1;
+ if (cea_mode = ARRAY_SIZE(edid_cea_modes))
+ return 0;
+
+ if (structure (1 0)) {
+ newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+ if (newmode) {
+ newmode-flags |= DRM_MODE_FLAG_3D_FRAME_PACKING;
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ if (structure (1 6)) {
+ newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+ if (newmode) {
+ newmode-flags |= DRM_MODE_FLAG_3D_TOP_AND_BOTTOM;
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ if (structure (1 8)) {
+ newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+ if (newmode) {
+ newmode-flags = DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF;
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+
+ return modes;
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
@@ -2662,10 +2706,13 @@ static int add_hdmi_mode(struct drm_connector
*connector, u8 vic)
* also adds the stereo 3d modes when applicable.
*/
static int
-do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
+do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
+ const u8 *video_db, u8 video_len)
{
- int modes = 0, offset = 0, i;
- u8 vic_len;
+ int modes = 0, offset = 0, i, multi_present = 0;
+ u8 vic_len, hdmi_3d_len = 0;
+ u16 mask;
+ u16 structure_all;
if (len 8)
goto out;
@@ -2689,11 +2736,16 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
/* 3D_Present */
offset++;
- if (db[8 + offset] (1 7))
+ if (db[8 + offset] (1 7)) {
modes += add_hdmi_mandatory_stereo_modes(connector);
+ /* 3D_Multi_present */
+ multi_present = (db[8 + offset] 0x60) 5;
+ }
+
offset++;
vic_len = db[8 + offset] 5;
+ hdmi_3d_len = db[8 + offset] 0x1f;
for (i = 0; i vic_len len = (9 + offset + i); i++) {
u8 vic;
@@ -2701,6 +2753,35 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
vic = db[9 + offset + i];
modes += add_hdmi_mode(connector, vic);
}
+ offset += 1 + vic_len;
+
+ if (!(multi_present == 1 || multi_present == 2))
+ goto out;
+
+ if ((multi_present == 1 len (9 + offset)) ||
+ (multi_present == 2 len (11 + offset)))
+ goto out;
+
+ if ((multi_present == 1 hdmi_3d_len 2) ||
+ (multi_present == 2 hdmi_3d_len 4))
+ goto out;
+
+ /* 3D_Structure_ALL */
+ structure_all = (db[8 + offset] 8) | db[9 + offset];
+
+ /* check if 3D_MASK is present */
+ if (multi_present == 2)
+ mask = (db[10 + offset] 8) | db[11 + offset];
+ else
+ mask = 0x;
+
+ for (i = 0; i 16; i++) {
+ if (mask (1 i))
+ modes += add_3d_struct_modes(connector,
+structure_all,
+
Re: [Intel-gfx] [PATCH v3] drm: add support for additional stereo 3D modes
On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
v2: Use (1 0) for consistency. (Ville Syrjälä)
Skip adding any modes if 3D_MASK is indicated as being present but
the length only includes 3D_Structure_ALL. (Ville Syrjälä)
Check that the value of HDMI_3D_LEN is large enough to include
3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä)
v3: Increment offset before the length checks. (Ville Syrjälä)
Signed-off-by: Thomas Wood thomas.w...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_edid.c | 103
+
1 file changed, 94 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9e81609..f1764ec 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2652,6 +2652,50 @@ static int add_hdmi_mode(struct drm_connector
*connector, u8 vic)
return 1;
}
+static int add_3d_struct_modes(struct drm_connector *connector, u16
structure,
+const u8 *video_db, u8 video_len, u8 video_index)
+{
+ struct drm_device *dev = connector-dev;
+ struct drm_display_mode *newmode;
+ int modes = 0;
+ u8 cea_mode;
+
+ if (video_db == NULL || video_index video_len)
+ return 0;
+
+ /* CEA modes are numbered 1..127 */
+ cea_mode = (video_db[video_index] 127) - 1;
+ if (cea_mode = ARRAY_SIZE(edid_cea_modes))
+ return 0;
+
+ if (structure (1 0)) {
+ newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+ if (newmode) {
+ newmode-flags |= DRM_MODE_FLAG_3D_FRAME_PACKING;
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ if (structure (1 6)) {
+ newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+ if (newmode) {
+ newmode-flags |= DRM_MODE_FLAG_3D_TOP_AND_BOTTOM;
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ if (structure (1 8)) {
+ newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+ if (newmode) {
+ newmode-flags = DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF;
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+
+ return modes;
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
@@ -2662,10 +2706,13 @@ static int add_hdmi_mode(struct drm_connector
*connector, u8 vic)
* also adds the stereo 3d modes when applicable.
*/
static int
-do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
+do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
+const u8 *video_db, u8 video_len)
{
- int modes = 0, offset = 0, i;
- u8 vic_len;
+ int modes = 0, offset = 0, i, multi_present = 0;
+ u8 vic_len, hdmi_3d_len = 0;
+ u16 mask;
+ u16 structure_all;
if (len 8)
goto out;
@@ -2689,11 +2736,16 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
/* 3D_Present */
offset++;
- if (db[8 + offset] (1 7))
+ if (db[8 + offset] (1 7)) {
modes += add_hdmi_mandatory_stereo_modes(connector);
+ /* 3D_Multi_present */
+ multi_present = (db[8 + offset] 0x60) 5;
+ }
+
offset++;
vic_len = db[8 + offset] 5;
+ hdmi_3d_len = db[8 + offset] 0x1f;
for (i = 0; i vic_len len = (9 + offset + i); i++) {
u8 vic;
@@ -2701,6 +2753,35 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
vic = db[9 + offset + i];
modes += add_hdmi_mode(connector, vic);
}
+ offset += 1 + vic_len;
+
+ if (!(multi_present == 1 || multi_present == 2))
+ goto out;
+
+ if ((multi_present == 1 len (9 + offset)) ||
+ (multi_present == 2 len (11 + offset)))
+ goto out;
+
+ if ((multi_present == 1 hdmi_3d_len 2) ||
+ (multi_present == 2 hdmi_3d_len 4))
+ goto out;
+
+ /* 3D_Structure_ALL */
+ structure_all = (db[8 + offset] 8) | db[9 + offset];
+
+ /* check if 3D_MASK is present */
+ if (multi_present == 2)
+ mask = (db[10 + offset] 8) | db[11 + offset];
+ else
+ mask = 0x;
+
+ for (i = 0; i 16; i++) {
+ if (mask (1 i))
+ modes +=
Re: [Intel-gfx] [PATCH 4/5] drm/i915: take power well refs when needed
On Wed, 16 Oct 2013 14:10:13 +0300 Imre Deak imre.d...@intel.com wrote: On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote: On Tue, 15 Oct 2013 16:54:00 -0300 Paulo Zanoni przan...@gmail.com wrote: [...] No that's taken into account here. In __intel_set_mode we take a private ref on the appropriate power well so that we'll preserve state until we do the first crtc_enable. From then on, the ref is tracked there and we drop the private one in __intel_set_mode + if (crtc-active) + intel_display_power_get(dev, + POWER_DOMAIN_PIPE(crtc-pipe)); + What about the panel fitter power domains? Sometimes the panel fitter is the thing that makes you require a power well, even though you're on a pipe that doesn't need it. And on Haswell you also have to take into account TRANSCODER_EDP+PIPE_A versus TRANSCODER_A+PIPE_A, where the first doesn't need the power well but the second needs it. Yeah I'm still not sure how to handle this in generic code. Maybe the power well mapping function Imre added will be enough, but it definitely gets tricky when we look at all the different platforms we have to (and will have to) handle. Isn't the power domain abstraction a neat idea exactly for the above case? Generic code just asks for the domain it needs and doesn't care how it maps to power wells on the given platform. So for transcoder_edp +pipe_a it'd end up asking for POWER_DOMAIN_PIPE_A and POWER_DOMAIN_TRANSCODER_EDP, both of which is a nop on HSW, and for the other case POWER_DOMAIN_PIPE_A and POWER_DOMAIN_TRANSCODER_A which would enable the power well. You also have the POWER_DOMAIN_PIPE, POWER_DOMAIN_TRANSCODER, POWER_DOMAIN_PIPE_PANEL_FITTER helpers already. Yeah I think it can work. I missed your function that takes a crtc though as well, so we don't end up polluting the generic functions with TRANSCODER references that don't exist on the Atom platforms for example. That's the main thing I'm worried about, since as we get more and more wells I think it'll get easier to get it wrong in the generic code, if we have to use all the required domains for all platforms there. -- 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 for crashing intel server
On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote: On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote: This does indeed stop the server from crashing, but actually makes the problem worse: it used to play video for a few minutes and then crash when trying. With my patch it would play video for a few minutes and then present black screens when trying. With your patch, it presents black screens from the start. Start of video, or beginning of X? Beginning of X. After starting and logging in, I can play them for a few minutes; afterwards it will crash. Still weird. Can you attach the Xorg.log from the black screen and/or crash. I must say I'm not entirely sure if the backtrace I sent you is a typical case; I managed to crash it sooner than usual, so perhaps it wasn't the bug that I triggered before. It did stop the crashing however. However, that still leaveas the question as to how you ended up being unable to allocate bo... I didn't check the backtrace myself, but when I wrote my shotgun-patch, the problem was that pixmap_private was NULL; bo is in there, right? So at least in that case, it could never have allocated it, or at least it couldn't store the pointer. I doubt we failed to malloc the intel_pixmap, so the reason why the intel_pixmap would be NULL is more likely due to failure to allocate the GPU buffer object i.e. they are semantically interchangeable, an attached intel_pixmap to a Pixmap implies we have a GPU bo. Similarly checking for the intel_pixmap should be enough to assert that the GPU bo exists. -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 1/8] lib: Add a small helper to open debugfs files
On Tue, Oct 15, 2013 at 07:44:27PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/Makefile.am | 2 ++
lib/igt_debugfs.c | 75
+++
lib/igt_debugfs.h | 36 ++
3 files changed, 113 insertions(+)
create mode 100644 lib/igt_debugfs.c
create mode 100644 lib/igt_debugfs.h
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 387141b..5710802 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -11,6 +11,8 @@ libintel_tools_la_SOURCES = \
i830_reg.h \
i915_3d.h \
i915_reg.h \
+ igt_debugfs.c \
+ igt_debugfs.h \
instdone.c \
instdone.h \
intel_batchbuffer.c \
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
new file mode 100644
index 000..33c4fc1
--- /dev/null
+++ b/lib/igt_debugfs.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include sys/stat.h
+#include sys/mount.h
+#include errno.h
+#include stdio.h
+#include string.h
+#include fcntl.h
+
+#include igt_debugfs.h
+
+int igt_debugfs_init(igt_debugfs_t *debugfs)
+{
+ const char *path = /sys/kernel/debug;
+ struct stat st;
+ int n;
+
+ if (stat(/debug/dri, st) == 0) {
+ path = /debug/dri;
+ goto find_minor;
+ }
+
+ if (stat(/sys/kernel/debug/dri, st) == 0)
+ goto find_minor;
+
+ if (stat(/sys/kernel/debug, st))
+ return errno;
+
+ if (mount(debug, /sys/kernel/debug, debugfs, 0, 0))
+ return errno;
+
+find_minor:
+ strcpy(debugfs-root, path);
+ for (n = 0; n 16; n++) {
+ int len = sprintf(debugfs-dri_path, %s/dri/%d, path, n);
+ sprintf(debugfs-dri_path + len, /i915_error_state);
+ if (stat(debugfs-dri_path, st) == 0) {
+ debugfs-dri_path[len] = '\0';
+ return 0;
+ }
+ }
+
+ debugfs-dri_path[0] = '\0';
+ return ENOENT;
+}
+
+int igt_debugfs_open(igt_debugfs_t *debugfs, const char *filename)
+{
+ char buf[1024];
+
+ sprintf(buf, %s/%s, debugfs-dri_path, filename);
+ return open(buf, O_RDONLY);
+}
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
new file mode 100644
index 000..aa9449a
--- /dev/null
+++ b/lib/igt_debugfs.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __IGT_DEBUGFS_H__
+#define __IGT_DEBUGFS_H__
+
+typedef struct {
+ char root[128];
+ char
[Intel-gfx] [PATCH 2/2] drm/i915: Disable GGTT PTEs on GEN6+ suspend
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot currently explain why the latent GPU writes
occur.
In the technical sense, this patch is a workaround in that we have an
issue we can't explain, and the patch indirectly solves the issue.
However, it's really better than a workaround because we understand why
it works, and it really should be a safe thing to do in all cases.
The noticeable effect other than the debug messages would be an increase
in the suspend time. I have not measure how expensive it actually is.
I think it would be good to spend further time to root cause why we're
seeing these latent writes, but it shouldn't preclude preventing the
fallout.
NOTE: It should be safe (and makes some sense IMO) to also keep the
VALID bit unset on resume when we clear_range(). I've opted not to do
this as properly clearing those bits at some later point would be extra
work.
Bugzilla:
http://bugs.freedesktop.org/6549://bugs.freedesktop.org/show_bug.cgi?id=65496
Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=110401
Tested-by: Takashi Iwai ti...@suse.de
Tested-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.c | 5 ++-
drivers/gpu/drm/i915/i915_drv.h | 5 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 76 -
drivers/gpu/drm/i915/i915_reg.h | 4 ++
4 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59649c0..ea90c5f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -502,6 +502,8 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_modeset_suspend_hw(dev);
}
+ i915_gem_suspend_gtt_mappings(dev);
+
i915_save_state(dev);
intel_opregion_fini(dev);
@@ -587,7 +589,8 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
mutex_lock(dev-struct_mutex);
i915_gem_restore_gtt_mappings(dev);
mutex_unlock(dev-struct_mutex);
- }
+ } else if (drm_core_check_feature(dev, DRIVER_MODESET))
+ i915_check_and_clear_faults(dev);
intel_init_power_well(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0cbeb0e..7ca99350 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -521,7 +521,8 @@ struct i915_address_space {
bool valid); /* Create a valid PTE */
void (*clear_range)(struct i915_address_space *vm,
unsigned int first_entry,
- unsigned int num_entries);
+ unsigned int num_entries,
+ bool use_scratch);
void (*insert_entries)(struct i915_address_space *vm,
struct sg_table *st,
unsigned int first_entry,
@@ -2143,6 +2144,8 @@ void i915_ppgtt_bind_object(struct i915_hw_ppgtt *ppgtt,
void i915_ppgtt_unbind_object(struct i915_hw_ppgtt *ppgtt,
struct drm_i915_gem_object *obj);
+void i915_check_and_clear_faults(struct drm_device *dev);
+void i915_gem_suspend_gtt_mappings(struct drm_device *dev);
void i915_gem_restore_gtt_mappings(struct drm_device *dev);
int __must_check i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj);
void i915_gem_gtt_bind_object(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 81dce29..c4c42e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -241,7 +241,8 @@ static int gen6_ppgtt_enable(struct drm_device *dev)
/* PPGTT support for Sandybdrige/Gen6 and later */
static void gen6_ppgtt_clear_range(struct i915_address_space *vm,
unsigned first_entry,
- unsigned num_entries)
+ unsigned num_entries,
+ bool use_scratch)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
@@ -372,7 +373,7 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
}
ppgtt-base.clear_range(ppgtt-base, 0,
- ppgtt-num_pd_entries * I915_PPGTT_PT_ENTRIES);
+ ppgtt-num_pd_entries * I915_PPGTT_PT_ENTRIES,
true);
ppgtt-pd_offset = first_pd_entry_in_global_pt * sizeof(gen6_gtt_pte_t);
@@ -449,7 +450,8 @@ void i915_ppgtt_unbind_object(struct i915_hw_ppgtt *ppgtt,
{
ppgtt-base.clear_range(ppgtt-base,
Re: [Intel-gfx] [PATCH 3/6] drm/i915: change power_well-lock to be mutex
On Wed, 2013-10-16 at 13:19 -0300, Paulo Zanoni wrote:
2013/10/16 Imre Deak imre.d...@intel.com:
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.
Not even from snd_hda_intel? Did we check this?
Yea, at least I tried to check this at all call sites and haven't found
any place where they request the power well in atomic context. In any
case I think it's a design problem if they do ..
--Imre
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);
}
/*
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable all GEM timers and work on unload
On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote: On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote: We have two once very similar functions, i915_gpu_idle() and i915_gem_idle(). The former is used as the lower level operation to flush work on the GPU, whereas the latter is the high level interface to flush the GEM bookkeeping in addition to flushing the GPU. As such i915_gem_idle() also clears out the request and activity lists and cancels the delayed work. This is what we need for unloading the driver, unfortunately we called i915_gpu_idle() instead. In the process, make sure that when cancelling the delayed work and timer, which is synchronous, that we do not hold any locks to prevent a deadlock if the work item is already waiting upon the mutex. This requires us to push the mutex down from the caller to i915_gem_idle(). v2: s/i915_gem_idle/i915_gem_suspend/ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Tested-by: xunx.f...@intel.com Queued for -next, thanks for the patch. Oops, spotted a bug in my v2. ums.mm_suspend should only be set for !kms. Sorry that slipped my mind when doing the s/_idle/_suspend. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] [v2] drm/i915: Disable GGTT PTEs on GEN6+ suspend
On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote: Once the machine gets to a certain point in the suspend process, we expect the GPU to be idle. If it is not, we might corrupt memory. Empirically (with an early version of this patch) we have seen this is not the case. We cannot currently explain why the latent GPU writes occur. In the technical sense, this patch is a workaround in that we have an issue we can't explain, and the patch indirectly solves the issue. However, it's really better than a workaround because we understand why it works, and it really should be a safe thing to do in all cases. The noticeable effect other than the debug messages would be an increase in the suspend time. I have not measure how expensive it actually is. I think it would be good to spend further time to root cause why we're seeing these latent writes, but it shouldn't preclude preventing the fallout. NOTE: It should be safe (and makes some sense IMO) to also keep the VALID bit unset on resume when we clear_range(). I've opted not to do this as properly clearing those bits at some later point would be extra work. v2: Fix bugzilla link And the other one? Bugzilla: http://bugs.freedesktop.org/6549://bugs.freedesktop.org/show_bug.cgi?id=65496 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321 Tested-by: Takashi Iwai ti...@suse.de Tested-by: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net So clearing the valid bit should result in the GPU reporting errors for delayed accesses, but none were reported? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] [v2] drm/i915: Disable GGTT PTEs on GEN6+ suspend
On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote: On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote: Once the machine gets to a certain point in the suspend process, we expect the GPU to be idle. If it is not, we might corrupt memory. Empirically (with an early version of this patch) we have seen this is not the case. We cannot currently explain why the latent GPU writes occur. In the technical sense, this patch is a workaround in that we have an issue we can't explain, and the patch indirectly solves the issue. However, it's really better than a workaround because we understand why it works, and it really should be a safe thing to do in all cases. The noticeable effect other than the debug messages would be an increase in the suspend time. I have not measure how expensive it actually is. I think it would be good to spend further time to root cause why we're seeing these latent writes, but it shouldn't preclude preventing the fallout. NOTE: It should be safe (and makes some sense IMO) to also keep the VALID bit unset on resume when we clear_range(). I've opted not to do this as properly clearing those bits at some later point would be extra work. v2: Fix bugzilla link And the other one? I'm really amazing. If we move ahead with this patch, Daniel, can you just erase the extra bugs.freedesktop.org/6549:// Bugzilla: http://bugs.freedesktop.org/6549://bugs.freedesktop.org/show_bug.cgi?id=65496 Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321 Tested-by: Takashi Iwai ti...@suse.de Tested-by: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net So clearing the valid bit should result in the GPU reporting errors for delayed accesses, but none were reported? -Chris So I can't actually reproduce the problem for some reason. Paulo will need to answer. One theory is the fault information is lost on suspend. The original patch put faults both in suspend, and resume. After this, I asked Paulo to wedge the GPU, and there I saw faults. -- 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 2/2] [v2] drm/i915: Disable GGTT PTEs on GEN6+ suspend
On Wed, Oct 16, 2013 at 10:06:27AM -0700, Ben Widawsky wrote: On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote: So clearing the valid bit should result in the GPU reporting errors for delayed accesses, but none were reported? So I can't actually reproduce the problem for some reason. Paulo will need to answer. One theory is the fault information is lost on suspend. The original patch put faults both in suspend, and resume. After this, I asked Paulo to wedge the GPU, and there I saw faults. If we can capture the error, and it should be very possible to do so, we should be able to pinpoint the cause quite quickly. If it is just deferred writes, it should also be a problem across module unload - which should be easier for getting debug information out. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable all GEM timers and work on unload
On Wed, Oct 16, 2013 at 05:47:26PM +0100, Chris Wilson wrote: On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote: On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote: We have two once very similar functions, i915_gpu_idle() and i915_gem_idle(). The former is used as the lower level operation to flush work on the GPU, whereas the latter is the high level interface to flush the GEM bookkeeping in addition to flushing the GPU. As such i915_gem_idle() also clears out the request and activity lists and cancels the delayed work. This is what we need for unloading the driver, unfortunately we called i915_gpu_idle() instead. In the process, make sure that when cancelling the delayed work and timer, which is synchronous, that we do not hold any locks to prevent a deadlock if the work item is already waiting upon the mutex. This requires us to push the mutex down from the caller to i915_gem_idle(). v2: s/i915_gem_idle/i915_gem_suspend/ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Tested-by: xunx.f...@intel.com Queued for -next, thanks for the patch. Oops, spotted a bug in my v2. ums.mm_suspend should only be set for !kms. Sorry that slipped my mind when doing the s/_idle/_suspend. Actually I've noticed since it was missing from the changelog, but figured you've decided against that. I'll rectify it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: preserve dispaly init order on ByT
On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote: 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 This makes imo sense irrespective of any userspace issues. Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm: add support for additional stereo 3D modes
On Wed, Oct 16, 2013 at 06:07:30PM +0300, Ville Syrjälä wrote: On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote: Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor Specific Data Block to expose more stereo 3D modes. v2: Use (1 0) for consistency. (Ville Syrjälä) Skip adding any modes if 3D_MASK is indicated as being present but the length only includes 3D_Structure_ALL. (Ville Syrjälä) Check that the value of HDMI_3D_LEN is large enough to include 3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä) v3: Increment offset before the length checks. (Ville Syrjälä) Signed-off-by: Thomas Wood thomas.w...@intel.com Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: vlv: fix VGA hotplug after modeset
On Wed, Oct 16, 2013 at 08:39:24PM +0300, Imre Deak wrote: Since commit 912d812e84cea8689a2bf3dd13b11dfe191f0f1e Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Thu Oct 11 20:08:23 2012 +0200 drm/i915/crt: don't set HOTPLUG bits on !PCH on VLV we don't detect any VGA unplug event after a modeset, since there we reset the ADPA hotplug bits. Fix it by preserving the hotplug bits on VLV as well. Signed-off-by: Imre Deak imre.d...@intel.com Queued for -next (with a bikeshed to make it consistent with Chris' equivalent fix in intel_crt_reset), thanks for the patch. -Daniel --- drivers/gpu/drm/i915/intel_crt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index becb311..bd37685 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -274,7 +274,7 @@ static void intel_crt_mode_set(struct intel_encoder *encoder) struct drm_display_mode *adjusted_mode = crtc-config.adjusted_mode; u32 adpa; - if (HAS_PCH_SPLIT(dev)) + if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev)) adpa = ADPA_HOTPLUG_BITS; else adpa = 0; -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] framebuffer_init checks
On Thu, Oct 10, 2013 at 02:42:40PM +0300, Ville Syrjälä wrote: On Wed, Oct 09, 2013 at 09:23:50PM +0200, Daniel Vetter wrote: Hi all, That little patch turned into a bit more, and on top of it there's now also a new testcase in igt: kms_addfb. It checks for most of the evil stuff you can feed to addfb. For the series: Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com All merged, thanks for your review. For patch 2 I've added a note about how exactly it'll affect shipped userspace and smashed Chris' grumpy irc r-b on top. -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] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert Revert drm/i915: revert eDP bpp clamping code changes
BugLink: http://bugs.launchpad.net/bugs/1195483
This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Paulo Zanoni przan...@gmail.com
Cc: David Airlie airl...@linux.ie
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 26e162b..ce933ad 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -709,10 +709,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
/* Walk through all bpp values. Luckily they're all nicely spaced with 2
* bpc in between. */
- bpp = pipe_config-pipe_bpp;
- if (is_edp(intel_dp) dev_priv-vbt.edp_bpp)
- bpp = min_t(int, bpp, dev_priv-vbt.edp_bpp);
-
+ bpp = min_t(int, 8*3, pipe_config-pipe_bpp);
for (; bpp = 6*3; bpp -= 2*3) {
mode_rate = intel_dp_link_required(adjusted_mode-clock, bpp);
@@ -763,6 +760,19 @@ found:
pipe_config-dp_m_n);
intel_dp_set_clock(encoder, pipe_config, intel_dp-link_bw);
+ /*
+* XXX: We have a strange regression where using the vbt edp bpp value
+* for the link bw computation results in black screens, the panel only
+* works when we do the computation at the usual 24bpp (but still
+* requires us to use 18bpp). Until that's fully debugged, stay
+* bug-for-bug compatible with the old code.
+*/
+ if (is_edp(intel_dp) dev_priv-vbt.edp_bpp) {
+ DRM_DEBUG_KMS(clamping display bpc (was %d) to eDP (%d)\n,
+ bpp, dev_priv-vbt.edp_bpp);
+ bpp = min_t(int, bpp, dev_priv-vbt.edp_bpp);
+ }
+ pipe_config-pipe_bpp = bpp;
return true;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 0/1] Revert Revert drm/i915: revert eDP bpp clamping code changes
Hi Daniel, A bug was opened against the Ubuntu kernel[0]. It was found that reverting the following commit resolved this bug: 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 The regression was introduced as of v3.10-rc2 and affects a large number of end users. I see this code has gone back and forth a few times, so I was wondering if we could get some feedback. The revert of commit 657445f was tested aginst 3.11 stable and could not be done cleanly, so I had to make some modifications. The modifications I made for 3.11 are in [PATCH 1/1]. The revert can't be done cleanly against 3.12 neither. The modifications I made for 3.11 will not work cleanly on 3.12 due to recent changes in 3.12, such as commit 7984211. However, I can create a patch specific for 3.12 if you think this is the best way to go. Thanks, Joe http://pad.lv/1195483 Joseph Salisbury (1): Revert Revert drm/i915: revert eDP bpp clamping code changes drivers/gpu/drm/i915/intel_dp.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) -- 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] drm/i915: preserve dispaly init order on ByT
On Wed, Oct 16, 2013 at 07:46:27PM +0200, Daniel Vetter wrote: On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote: 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. I'm sure I heard a rumour that there was an extension block in EDID to assiocate touch devices with monitors. Does anyone know any firm details about that? -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 01/16] drm/i915: extract display_pipe_crc_update
The ringbuffer update logic should always be the same, but different
platforms have different amounts of CRC registers. Hence extract it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8c9148c..df031bb 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1190,7 +1190,10 @@ static void dp_aux_irq_handler(struct drm_device *dev)
}
#if defined(CONFIG_DEBUG_FS)
-static void ivb_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+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, uint32_t frame)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
@@ -1212,18 +1215,31 @@ static void ivb_pipe_crc_update(struct drm_device *dev,
enum pipe pipe)
entry = pipe_crc-entries[head];
- entry-frame = I915_READ(PIPEFRAME(pipe));
- entry-crc[0] = I915_READ(PIPE_CRC_RES_1_IVB(pipe));
- entry-crc[1] = I915_READ(PIPE_CRC_RES_2_IVB(pipe));
- entry-crc[2] = I915_READ(PIPE_CRC_RES_3_IVB(pipe));
- entry-crc[3] = I915_READ(PIPE_CRC_RES_4_IVB(pipe));
- entry-crc[4] = I915_READ(PIPE_CRC_RES_5_IVB(pipe));
+ entry-frame = frame;
+ entry-crc[0] = crc0;
+ entry-crc[1] = crc1;
+ entry-crc[2] = crc2;
+ entry-crc[3] = crc3;
+ entry-crc[4] = crc4;
head = (head + 1) (INTEL_PIPE_CRC_ENTRIES_NR - 1);
atomic_set(pipe_crc-head, head);
wake_up_interruptible(pipe_crc-wq);
}
+
+static void ivb_pipe_crc_update(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)),
+ I915_READ(PIPEFRAME(pipe)));
+}
#else
static inline void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
#endif
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/16] CRC support for non-ivb
Hi all, I've stitched together basic CRC support for non-ivb platforms. Still need to do a bit more testing on this, but ignoring bugs this should be it. We also need to pimp the igt testcase a bit so that it falls back to the new PIPE source if the PLANE1 source isn't available. Review and comments highly welcome. Cheers, Daniel Daniel Vetter (16): drm/i915: extract display_pipe_crc_update drm/i915: add CRC #defines for ilk/snb drm/i915: wire up CRC interrupt for ilk/snb drm/i915: use -get_vblank_counter for the crc frame counter drm/i915: wait one vblank when disabling CRCs drm/i915: fix CRC debugfs setup drm/i915: crc support for hsw drm/i915: Adjust CRC capture for pre-gen5/vlv drm/i915: CRC source selection #defines for gmch/vlv chips drm/i915: Wire up CRC interrupts for pre-gen5/vlv drm/i915: Enable CRC interrupts on pre-gen5/vlv drm/i915: Fix PIPE_CRC_CTL for vlv drm/i915: Add new CRC sources drm/i915: Wire up CRC support for gen3/4 drm/i915: Wire up gen2 CRC support drm/i915: Wire up CRC for vlv drivers/gpu/drm/i915/i915_debugfs.c | 164 +++- drivers/gpu/drm/i915/i915_drv.h | 6 ++ drivers/gpu/drm/i915/i915_irq.c | 151 + drivers/gpu/drm/i915/i915_reg.h | 74 +--- 4 files changed, 328 insertions(+), 67 deletions(-) -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/16] drm/i915: wire up CRC interrupt for ilk/snb
We enable the interrupt unconditionally and only control it
through the enable bit in the CRC control register.
v2: Extract per-platform helpers to compute the register values.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 74 -
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 26 -
drivers/gpu/drm/i915/i915_reg.h | 2 +
4 files changed, 84 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5fce5d8..323f58e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1914,6 +1914,7 @@ static const char * const pipe_crc_sources[] = {
plane1,
plane2,
pf,
+ pipe,
};
static const char *pipe_crc_source_name(enum intel_pipe_crc_source source)
@@ -1942,14 +1943,61 @@ static int display_crc_ctl_open(struct inode *inode,
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
}
+static int ilk_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+ uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PLANE1:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PRIMARY_ILK;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_PLANE2:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_ILK;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_PF:
+ return -EINVAL;
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PIPE_ILK;
+ break;
+ default:
+ *val = 0;
+ break;
+ }
+
+ return 0;
+}
+
+static int ivb_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+ uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PLANE1:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PRIMARY_IVB;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_PLANE2:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_IVB;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_PF:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ return -EINVAL;
+ default:
+ *val = 0;
+ break;
+ }
+
+ return 0;
+}
+
static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe,
enum intel_pipe_crc_source source)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
u32 val;
+ int ret;
- if (!IS_IVYBRIDGE(dev))
+ if (!(IS_IVYBRIDGE(dev) || IS_GEN5(dev) || IS_GEN6(dev)))
return -ENODEV;
if (pipe_crc-source == source)
@@ -1959,6 +2007,14 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
if (pipe_crc-source source)
return -EINVAL;
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ ret = ilk_pipe_crc_ctl_reg(source, val);
+ else
+ ret = ivb_pipe_crc_ctl_reg(source, val);
+
+ if (ret != 0)
+ return ret;
+
/* none - real source transition */
if (source) {
DRM_DEBUG_DRIVER(collecting CRCs for pipe %c, %s\n,
@@ -1976,22 +2032,6 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
pipe_crc-source = source;
- switch (source) {
- case INTEL_PIPE_CRC_SOURCE_PLANE1:
- val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PRIMARY_IVB;
- break;
- case INTEL_PIPE_CRC_SOURCE_PLANE2:
- val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_IVB;
- break;
- case INTEL_PIPE_CRC_SOURCE_PF:
- val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
- break;
- case INTEL_PIPE_CRC_SOURCE_NONE:
- default:
- val = 0;
- break;
- }
-
I915_WRITE(PIPE_CRC_CTL(pipe), val);
POSTING_READ(PIPE_CRC_CTL(pipe));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e2bf930..09857f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1222,6 +1222,7 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_PLANE1,
INTEL_PIPE_CRC_SOURCE_PLANE2,
INTEL_PIPE_CRC_SOURCE_PF,
+ INTEL_PIPE_CRC_SOURCE_PIPE,
INTEL_PIPE_CRC_SOURCE_MAX,
};
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index df031bb..36465ef 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1240,8 +1240,22 @@ static void ivb_pipe_crc_update(struct drm_device *dev,
enum pipe pipe)
[Intel-gfx] [PATCH 02/16] drm/i915: add CRC #defines for ilk/snb
Also add a new _PIPE_INC macro which takes an base plus increment. Much less likely to botch the job by missing an s/A/B/ somewhere. v2: They've moved the bitfield. Argh! Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_reg.h | 46 +++-- 1 file changed, 35 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 4d01eaf..984bf9e1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -26,6 +26,7 @@ #define _I915_REG_H_ #define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a))) +#define _PIPE_INC(pipe, base, inc) ((base) + (pipe)*(inc)) #define _TRANSCODER(tran, a, b) ((a) + (tran)*((b)-(a))) #define _PORT(port, a, b) ((a) + (port)*((b)-(a))) @@ -1844,19 +1845,31 @@ #define PIPE_CRC_SOURCE_PRIMARY_IVB (0 29) #define PIPE_CRC_SOURCE_SPRITE_IVB (1 29) #define PIPE_CRC_SOURCE_PF_IVB (2 29) -#define _PIPE_CRC_RES_1_A_IVB (dev_priv-info-display_mmio_offset + 0x60064) -#define _PIPE_CRC_RES_2_A_IVB (dev_priv-info-display_mmio_offset + 0x60068) -#define _PIPE_CRC_RES_3_A_IVB (dev_priv-info-display_mmio_offset + 0x6006c) -#define _PIPE_CRC_RES_4_A_IVB (dev_priv-info-display_mmio_offset + 0x60070) -#define _PIPE_CRC_RES_5_A_IVB (dev_priv-info-display_mmio_offset + 0x60074) +#define PIPE_CRC_SOURCE_PRIMARY_ILK (0 28) +#define PIPE_CRC_SOURCE_SPRITE_ILK (1 28) +#define PIPE_CRC_SOURCE_PIPE_ILK (2 28) +/* embedded DP port on the north display block, reserved on ivb */ +#define PIPE_CRC_SOURCE_PORT_A_ILK (4 28) +#define PIPE_CRC_SOURCE_FDI_ILK (5 28) /* reserved on ivb */ +#define _PIPE_CRC_RES_1_A_IVB 0x60064 +#define _PIPE_CRC_RES_2_A_IVB 0x60068 +#define _PIPE_CRC_RES_3_A_IVB 0x6006c +#define _PIPE_CRC_RES_4_A_IVB 0x60070 +#define _PIPE_CRC_RES_5_A_IVB 0x60074 + +#define _PIPE_CRC_RES_RED_A_ILK0x60060 +#define _PIPE_CRC_RES_GREEN_A_ILK 0x60064 +#define _PIPE_CRC_RES_BLUE_A_ILK 0x60068 +#define _PIPE_CRC_RES_RES1_A_ILK 0x6006c +#define _PIPE_CRC_RES_RES2_A_ILK 0x60080 /* Pipe B CRC regs */ -#define _PIPE_CRC_CTL_B(dev_priv-info-display_mmio_offset + 0x61050) -#define _PIPE_CRC_RES_1_B_IVB (dev_priv-info-display_mmio_offset + 0x61064) -#define _PIPE_CRC_RES_2_B_IVB (dev_priv-info-display_mmio_offset + 0x61068) -#define _PIPE_CRC_RES_3_B_IVB (dev_priv-info-display_mmio_offset + 0x6106c) -#define _PIPE_CRC_RES_4_B_IVB (dev_priv-info-display_mmio_offset + 0x61070) -#define _PIPE_CRC_RES_5_B_IVB (dev_priv-info-display_mmio_offset + 0x61074) +#define _PIPE_CRC_CTL_B0x61050 +#define _PIPE_CRC_RES_1_B_IVB 0x61064 +#define _PIPE_CRC_RES_2_B_IVB 0x61068 +#define _PIPE_CRC_RES_3_B_IVB 0x6106c +#define _PIPE_CRC_RES_4_B_IVB 0x61070 +#define _PIPE_CRC_RES_5_B_IVB 0x61074 #define PIPE_CRC_CTL(pipe) _PIPE(pipe, _PIPE_CRC_CTL_A, _PIPE_CRC_CTL_B) #define PIPE_CRC_RES_1_IVB(pipe) \ @@ -1870,6 +1883,17 @@ #define PIPE_CRC_RES_5_IVB(pipe) \ _PIPE(pipe, _PIPE_CRC_RES_5_A_IVB, _PIPE_CRC_RES_5_B_IVB) +#define PIPE_CRC_RES_RED_ILK(pipe) \ + _PIPE_INC(pipe, _PIPE_CRC_RES_RED_A_ILK, 0x01000) +#define PIPE_CRC_RES_GREEN_ILK(pipe) \ + _PIPE_INC(pipe, _PIPE_CRC_RES_GREEN_A_ILK, 0x01000) +#define PIPE_CRC_RES_BLUE_ILK(pipe) \ + _PIPE_INC(pipe, _PIPE_CRC_RES_BLUE_A_ILK, 0x01000) +#define PIPE_CRC_RES_RES1_ILK(pipe) \ + _PIPE_INC(pipe, _PIPE_CRC_RES_RES1_A_ILK, 0x01000) +#define PIPE_CRC_RES_RES2_ILK(pipe) \ + _PIPE_INC(pipe, _PIPE_CRC_RES_RES2_A_ILK, 0x01000) + /* Pipe A timing regs */ #define _HTOTAL_A (dev_priv-info-display_mmio_offset + 0x6) #define _HBLANK_A (dev_priv-info-display_mmio_offset + 0x60004) -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/16] drm/i915: wait one vblank when disabling CRCs
This avoids a spurious spurious interrupt warning. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 323f58e..349f149 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2040,6 +2040,8 @@ static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe, DRM_DEBUG_DRIVER(stopping CRCs for pipe %c\n, pipe_name(pipe)); + intel_wait_for_vblank(dev, pipe); + kfree(pipe_crc-entries); pipe_crc-entries = NULL; } -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/16] drm/i915: use -get_vblank_counter for the crc frame counter
Suggested by Ville.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 36465ef..eaf1268 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1193,7 +1193,7 @@ static void dp_aux_irq_handler(struct drm_device *dev)
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, uint32_t frame)
+ uint32_t crc4)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
@@ -1215,7 +1215,7 @@ static void display_pipe_crc_update(struct drm_device
*dev, enum pipe pipe,
entry = pipe_crc-entries[head];
- entry-frame = frame;
+ entry-frame = dev-driver-get_vblank_counter(dev, pipe);
entry-crc[0] = crc0;
entry-crc[1] = crc1;
entry-crc[2] = crc2;
@@ -1237,8 +1237,7 @@ static void ivb_pipe_crc_update(struct drm_device *dev,
enum pipe 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)),
- I915_READ(PIPEFRAME(pipe)));
+ I915_READ(PIPE_CRC_RES_5_IVB(pipe)));
}
static void ilk_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
@@ -1250,8 +1249,7 @@ static void ilk_pipe_crc_update(struct drm_device *dev,
enum pipe pipe)
I915_READ(PIPE_CRC_RES_GREEN_ILK(pipe)),
I915_READ(PIPE_CRC_RES_BLUE_ILK(pipe)),
I915_READ(PIPE_CRC_RES_RES1_ILK(pipe)),
- I915_READ(PIPE_CRC_RES_RES2_ILK(pipe)),
- I915_READ(PIPEFRAME(pipe)));
+ I915_READ(PIPE_CRC_RES_RES2_ILK(pipe)));
}
#else
static inline void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/16] drm/i915: fix CRC debugfs setup
We've set up all files, but removed only those for which we have a
pipe. Which leaves the one for pipe C on machines with less than 2
pipes, breaking module reload.
v2: We can't get at the drm device this early (wtf), so just register
all the files and also remove them all again.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 349f149..bb55046 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2772,7 +2772,6 @@ int i915_debugfs_init(struct drm_minor *minor)
void i915_debugfs_cleanup(struct drm_minor *minor)
{
- struct drm_device *dev = minor-dev;
int i;
drm_debugfs_remove_files(i915_debugfs_list,
@@ -2781,7 +2780,7 @@ void i915_debugfs_cleanup(struct drm_minor *minor)
drm_debugfs_remove_files((struct drm_info_list *) i915_forcewake_fops,
1, minor);
- for (i = 0; i INTEL_INFO(dev)-num_pipes; i++) {
+ for (i = 0; i ARRAY_SIZE(i915_pipe_crc_data); i++) {
struct drm_info_list *info_list =
(struct drm_info_list *)i915_pipe_crc_data[i];
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/16] drm/i915: Adjust CRC capture for pre-gen5/vlv
Should work down to gen2. The #defines for the interrupt sources are
already there in PIPESTAT and are the same on all gmch platforms for
gen2 up to vlv.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 28 +++-
drivers/gpu/drm/i915/i915_reg.h | 30 +++---
2 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 156a1a4..98f5ac3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1249,21 +1249,31 @@ static void ivb_pipe_crc_update(struct drm_device *dev,
enum pipe pipe)
I915_READ(PIPE_CRC_RES_5_IVB(pipe)));
}
-static void ilk_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+static void i9xx_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t res1, res2;
+
+ if (INTEL_INFO(dev)-gen = 3)
+ res1 = I915_READ(PIPE_CRC_RES_RES1_I915(pipe));
+ else
+ res1 = 0;
+
+ if (INTEL_INFO(dev)-gen = 5 || IS_G4X(dev))
+ res2 = I915_READ(PIPE_CRC_RES_RES2_G4X(pipe));
+ else
+ res2 = 0;
display_pipe_crc_update(dev, pipe,
- I915_READ(PIPE_CRC_RES_RED_ILK(pipe)),
- I915_READ(PIPE_CRC_RES_GREEN_ILK(pipe)),
- I915_READ(PIPE_CRC_RES_BLUE_ILK(pipe)),
- I915_READ(PIPE_CRC_RES_RES1_ILK(pipe)),
- I915_READ(PIPE_CRC_RES_RES2_ILK(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 ilk_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
@@ -1543,10 +1553,10 @@ static void ilk_display_irq_handler(struct drm_device
*dev, u32 de_iir)
DRM_DEBUG_DRIVER(Pipe B FIFO underrun\n);
if (de_iir DE_PIPEA_CRC_DONE)
- ilk_pipe_crc_update(dev, PIPE_A);
+ i9xx_pipe_crc_update(dev, PIPE_A);
if (de_iir DE_PIPEB_CRC_DONE)
- ilk_pipe_crc_update(dev, PIPE_B);
+ i9xx_pipe_crc_update(dev, PIPE_B);
if (de_iir DE_PLANEA_FLIP_DONE) {
intel_prepare_page_flip(dev, 0);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cf277ac..7379bbd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1858,11 +1858,11 @@
#define _PIPE_CRC_RES_4_A_IVB 0x60070
#define _PIPE_CRC_RES_5_A_IVB 0x60074
-#define _PIPE_CRC_RES_RED_A_ILK0x60060
-#define _PIPE_CRC_RES_GREEN_A_ILK 0x60064
-#define _PIPE_CRC_RES_BLUE_A_ILK 0x60068
-#define _PIPE_CRC_RES_RES1_A_ILK 0x6006c
-#define _PIPE_CRC_RES_RES2_A_ILK 0x60080
+#define _PIPE_CRC_RES_RED_A(dev_priv-info-display_mmio_offset +
0x60060)
+#define _PIPE_CRC_RES_GREEN_A (dev_priv-info-display_mmio_offset +
0x60064)
+#define _PIPE_CRC_RES_BLUE_A (dev_priv-info-display_mmio_offset +
0x60068)
+#define _PIPE_CRC_RES_RES1_A_I915 (dev_priv-info-display_mmio_offset +
0x6006c)
+#define _PIPE_CRC_RES_RES2_A_G4X (dev_priv-info-display_mmio_offset +
0x60080)
/* Pipe B CRC regs */
#define _PIPE_CRC_CTL_B0x61050
@@ -1884,16 +1884,16 @@
#define PIPE_CRC_RES_5_IVB(pipe) \
_PIPE(pipe, _PIPE_CRC_RES_5_A_IVB, _PIPE_CRC_RES_5_B_IVB)
-#define PIPE_CRC_RES_RED_ILK(pipe) \
- _PIPE_INC(pipe, _PIPE_CRC_RES_RED_A_ILK, 0x01000)
-#define PIPE_CRC_RES_GREEN_ILK(pipe) \
- _PIPE_INC(pipe, _PIPE_CRC_RES_GREEN_A_ILK, 0x01000)
-#define PIPE_CRC_RES_BLUE_ILK(pipe) \
- _PIPE_INC(pipe, _PIPE_CRC_RES_BLUE_A_ILK, 0x01000)
-#define PIPE_CRC_RES_RES1_ILK(pipe) \
- _PIPE_INC(pipe, _PIPE_CRC_RES_RES1_A_ILK, 0x01000)
-#define PIPE_CRC_RES_RES2_ILK(pipe) \
- _PIPE_INC(pipe, _PIPE_CRC_RES_RES2_A_ILK, 0x01000)
+#define PIPE_CRC_RES_RED(pipe) \
+ _PIPE_INC(pipe, _PIPE_CRC_RES_RED_A, 0x01000)
+#define PIPE_CRC_RES_GREEN(pipe) \
+ _PIPE_INC(pipe, _PIPE_CRC_RES_GREEN_A, 0x01000)
+#define PIPE_CRC_RES_BLUE(pipe) \
+ _PIPE_INC(pipe, _PIPE_CRC_RES_BLUE_A, 0x01000)
+#define PIPE_CRC_RES_RES1_I915(pipe) \
+ _PIPE_INC(pipe, _PIPE_CRC_RES_RES1_A_I915, 0x01000)
+#define
[Intel-gfx] [PATCH 09/16] drm/i915: CRC source selection #defines for gmch/vlv chips
A bit a mess, since with DP/TV outputs we can't use the pipe CRC. Also, no plane CRCs, so we need to update the basic testcases. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_reg.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 7379bbd..ad8fe21 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1843,15 +1843,37 @@ /* Pipe A CRC regs */ #define _PIPE_CRC_CTL_A(dev_priv-info-display_mmio_offset + 0x60050) #define PIPE_CRC_ENABLE (1 31) +/* ivb+ source selection */ #define PIPE_CRC_SOURCE_PRIMARY_IVB (0 29) #define PIPE_CRC_SOURCE_SPRITE_IVB (1 29) #define PIPE_CRC_SOURCE_PF_IVB (2 29) +/* ilk+ source selection */ #define PIPE_CRC_SOURCE_PRIMARY_ILK (0 28) #define PIPE_CRC_SOURCE_SPRITE_ILK (1 28) #define PIPE_CRC_SOURCE_PIPE_ILK (2 28) /* embedded DP port on the north display block, reserved on ivb */ #define PIPE_CRC_SOURCE_PORT_A_ILK (4 28) #define PIPE_CRC_SOURCE_FDI_ILK (5 28) /* reserved on ivb */ +/* vlv source selection */ +#define PIPE_CRC_SOURCE_PIPE_VLV (0 27) +#define PIPE_CRC_SOURCE_HDMIB_VLV(1 27) +#define PIPE_CRC_SOURCE_HDMIC_VLV(2 27) +/* with DP port the pipe source is invalid */ +#define PIPE_CRC_SOURCE_DP_D_VLV (3 27) +#define PIPE_CRC_SOURCE_DP_B_VLV (6 27) +#define PIPE_CRC_SOURCE_DP_C_VLV (7 27) +/* gen3+ source selection */ +#define PIPE_CRC_SOURCE_PIPE_I9XX(0 28) +#define PIPE_CRC_SOURCE_SDVOB_I9XX (1 28) +#define PIPE_CRC_SOURCE_SDVOC_I9XX (2 28) +/* with DP/TV port the pipe source is invalid */ +#define PIPE_CRC_SOURCE_DP_D_G4X (3 28) +#define PIPE_CRC_SOURCE_TV_PRE (4 28) +#define PIPE_CRC_SOURCE_TV_POST (5 28) +#define PIPE_CRC_SOURCE_DP_B_G4X (6 28) +#define PIPE_CRC_SOURCE_DP_C_G4X (7 28) +/* gen2 doesn't have source selection bits */ + #define _PIPE_CRC_RES_1_A_IVB 0x60064 #define _PIPE_CRC_RES_2_A_IVB 0x60068 #define _PIPE_CRC_RES_3_A_IVB 0x6006c -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/16] drm/i915: Wire up CRC interrupts for pre-gen5/vlv
And throw in a tiny for_each_pipe refactoring for gen2.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 98f5ac3..b31e7ca 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1350,6 +1350,9 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
intel_prepare_page_flip(dev, pipe);
intel_finish_page_flip(dev, pipe);
}
+
+ if (pipe_stats[pipe] PIPE_CRC_DONE_INTERRUPT_STATUS)
+ i9xx_pipe_crc_update(dev, pipe);
}
/* Consume port. Then clear IIR or we'll miss events */
@@ -2800,13 +2803,14 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
if (iir I915_USER_INTERRUPT)
notify_ring(dev, dev_priv-ring[RCS]);
- if (pipe_stats[0] PIPE_VBLANK_INTERRUPT_STATUS
- i8xx_handle_vblank(dev, 0, iir))
- flip_mask = ~DISPLAY_PLANE_FLIP_PENDING(0);
+ for_each_pipe(pipe) {
+ if (pipe_stats[pipe] PIPE_VBLANK_INTERRUPT_STATUS
+ i8xx_handle_vblank(dev, pipe, iir))
+ flip_mask = ~DISPLAY_PLANE_FLIP_PENDING(pipe);
- if (pipe_stats[1] PIPE_VBLANK_INTERRUPT_STATUS
- i8xx_handle_vblank(dev, 1, iir))
- flip_mask = ~DISPLAY_PLANE_FLIP_PENDING(1);
+ if (pipe_stats[pipe] PIPE_CRC_DONE_INTERRUPT_STATUS)
+ i9xx_pipe_crc_update(dev, pipe);
+ }
iir = new_iir;
}
@@ -2999,6 +3003,9 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
if (pipe_stats[pipe] PIPE_LEGACY_BLC_EVENT_STATUS)
blc_event = true;
+
+ if (pipe_stats[pipe] PIPE_CRC_DONE_INTERRUPT_STATUS)
+ i9xx_pipe_crc_update(dev, pipe);
}
if (blc_event || (iir I915_ASLE_INTERRUPT))
@@ -3243,6 +3250,9 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
if (pipe_stats[pipe] PIPE_LEGACY_BLC_EVENT_STATUS)
blc_event = true;
+
+ if (pipe_stats[pipe] PIPE_CRC_DONE_INTERRUPT_STATUS)
+ i9xx_pipe_crc_update(dev, pipe);
}
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/16] drm/i915: Fix PIPE_CRC_CTL for vlv
The PIPE_B #define was missing the display mmio offset. Use the _PIPE_INC macro instead, it's simpler. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_reg.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ad8fe21..4e0f0b7 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1887,14 +1887,13 @@ #define _PIPE_CRC_RES_RES2_A_G4X (dev_priv-info-display_mmio_offset + 0x60080) /* Pipe B CRC regs */ -#define _PIPE_CRC_CTL_B0x61050 #define _PIPE_CRC_RES_1_B_IVB 0x61064 #define _PIPE_CRC_RES_2_B_IVB 0x61068 #define _PIPE_CRC_RES_3_B_IVB 0x6106c #define _PIPE_CRC_RES_4_B_IVB 0x61070 #define _PIPE_CRC_RES_5_B_IVB 0x61074 -#define PIPE_CRC_CTL(pipe) _PIPE(pipe, _PIPE_CRC_CTL_A, _PIPE_CRC_CTL_B) +#define PIPE_CRC_CTL(pipe) _PIPE_INC(pipe, _PIPE_CRC_CTL_A, 0x01000) #define PIPE_CRC_RES_1_IVB(pipe) \ _PIPE(pipe, _PIPE_CRC_RES_1_A_IVB, _PIPE_CRC_RES_1_B_IVB) #define PIPE_CRC_RES_2_IVB(pipe) \ -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/16] drm/i915: Add new CRC sources
On pre-gen5 and vlv we can't use the pipe source when TV-out or a DP
port is connected to the pipe. Hence we need to expose new CRC
sources.
Also simplify the existing pipe source platform code a bit by
rejecting all unhandled sources by default.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 ++--
drivers/gpu/drm/i915/i915_drv.h | 5 +
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 59c7653..c504c27 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1915,6 +1915,10 @@ static const char * const pipe_crc_sources[] = {
plane2,
pf,
pipe,
+ TV,
+ DP-B,
+ DP-C,
+ DP-D,
};
static const char *pipe_crc_source_name(enum intel_pipe_crc_source source)
@@ -1953,14 +1957,14 @@ static int ilk_pipe_crc_ctl_reg(enum
intel_pipe_crc_source source,
case INTEL_PIPE_CRC_SOURCE_PLANE2:
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_ILK;
break;
- case INTEL_PIPE_CRC_SOURCE_PF:
- return -EINVAL;
case INTEL_PIPE_CRC_SOURCE_PIPE:
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PIPE_ILK;
break;
- default:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
*val = 0;
break;
+ default:
+ return -EINVAL;
}
return 0;
@@ -1979,11 +1983,11 @@ static int ivb_pipe_crc_ctl_reg(enum
intel_pipe_crc_source source,
case INTEL_PIPE_CRC_SOURCE_PF:
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
break;
- case INTEL_PIPE_CRC_SOURCE_PIPE:
- return -EINVAL;
- default:
+ case INTEL_PIPE_CRC_SOURCE_NONE:
*val = 0;
break;
+ default:
+ return -EINVAL;
}
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 09857f8..4ba0a79 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1223,6 +1223,11 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_PLANE2,
INTEL_PIPE_CRC_SOURCE_PF,
INTEL_PIPE_CRC_SOURCE_PIPE,
+ /* TV/DP on pre-gen5/vlv can't use the pipe source. */
+ INTEL_PIPE_CRC_SOURCE_TV,
+ INTEL_PIPE_CRC_SOURCE_DP_B,
+ INTEL_PIPE_CRC_SOURCE_DP_C,
+ INTEL_PIPE_CRC_SOURCE_DP_D,
INTEL_PIPE_CRC_SOURCE_MAX,
};
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/16] drm/i915: Wire up CRC support for gen3/4
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 44 +++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c504c27..6de9e7e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1947,6 +1947,44 @@ static int display_crc_ctl_open(struct inode *inode,
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
}
+static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
+enum intel_pipe_crc_source source,
+uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PIPE_I9XX;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_TV:
+ if (!SUPPORTS_TV(dev))
+ return -EINVAL;
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_TV_PRE;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_DP_B:
+ if (!IS_G4X(dev))
+ return -EINVAL;
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_B_G4X;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_DP_C:
+ if (!IS_G4X(dev))
+ return -EINVAL;
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_G4X;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_DP_D:
+ if (!IS_G4X(dev))
+ return -EINVAL;
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_D_G4X;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ *val = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int ilk_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
uint32_t *val)
{
@@ -2001,7 +2039,7 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
u32 val;
int ret;
- if (!(INTEL_INFO(dev)-gen = 5 !IS_VALLEYVIEW(dev)))
+ if (!(INTEL_INFO(dev)-gen = 3 !IS_VALLEYVIEW(dev)))
return -ENODEV;
if (pipe_crc-source == source)
@@ -2011,7 +2049,9 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
if (pipe_crc-source source)
return -EINVAL;
- if (IS_GEN5(dev) || IS_GEN6(dev))
+ if (INTEL_INFO(dev)-gen 5)
+ ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
+ else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
else
ret = ivb_pipe_crc_ctl_reg(source, val);
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/debugfs_pipe_crc: fall back to PIPE source
With PLANE1 and PIPE CRC sources the test will work on all currently
shipping (and planed fwiw) platforms.
Also add all the other new sources for non-ivb/hsw chips.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/igt_debugfs.c| 12 +++-
lib/igt_debugfs.h| 7 ++-
tests/debugfs_pipe_crc.c | 8 +++-
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 371f583..f903454 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -207,6 +207,11 @@ static const char *pipe_crc_sources[] = {
plane1,
plane2,
pf,
+ pipe,
+ TV,
+ DP-B,
+ DP-C,
+ DP-D
};
static const char *pipe_crc_source_name(enum intel_pipe_crc_source source)
@@ -214,7 +219,7 @@ static const char *pipe_crc_source_name(enum
intel_pipe_crc_source source)
return pipe_crc_sources[source];
}
-void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
+bool igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
{
char buf[64];
igt_crc_t *crcs = NULL;
@@ -223,7 +228,10 @@ void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
sprintf(buf, pipe %c %s, pipe_name(pipe_crc-pipe),
pipe_crc_source_name(pipe_crc-source));
+ errno = 0;
write(pipe_crc-ctl_fd, buf, strlen(buf));
+ if (errno != 0)
+ return false;
/*
* For some no yet identified reason, the first CRC is bonkers. So
@@ -231,6 +239,8 @@ void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
*/
igt_pipe_crc_get_crcs(pipe_crc, 1, crcs);
free(crcs);
+
+ return true;
}
void igt_pipe_crc_stop(igt_pipe_crc_t *pipe_crc)
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index 7c280e7..f2873e0 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -50,6 +50,11 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_PLANE1,
INTEL_PIPE_CRC_SOURCE_PLANE2,
INTEL_PIPE_CRC_SOURCE_PF,
+INTEL_PIPE_CRC_SOURCE_PIPE,
+INTEL_PIPE_CRC_SOURCE_TV,
+INTEL_PIPE_CRC_SOURCE_DP_B,
+INTEL_PIPE_CRC_SOURCE_DP_C,
+INTEL_PIPE_CRC_SOURCE_DP_D,
INTEL_PIPE_CRC_SOURCE_MAX,
};
@@ -69,7 +74,7 @@ igt_pipe_crc_new(igt_debugfs_t *debugfs, int drm_fd, enum
pipe pipe,
enum intel_pipe_crc_source source);
void igt_pipe_crc_reset(void);
void igt_pipe_crc_free(igt_pipe_crc_t *pipe_crc);
-void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc);
+bool igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc);
void igt_pipe_crc_stop(igt_pipe_crc_t *pipe_crc);
void igt_pipe_crc_get_crcs(igt_pipe_crc_t *pipe_crc, int n_crcs,
igt_crc_t **out_crcs);
diff --git a/tests/debugfs_pipe_crc.c b/tests/debugfs_pipe_crc.c
index 9884fd7..f9ebac9 100644
--- a/tests/debugfs_pipe_crc.c
+++ b/tests/debugfs_pipe_crc.c
@@ -172,7 +172,13 @@ static void test_read_crc(data_t *data)
connector_set_mode(data, connector, connector-config.default_mode);
- igt_pipe_crc_start(pipe_crc);
+ if (!igt_pipe_crc_start(pipe_crc)) {
+ igt_pipe_crc_free(pipe_crc);
+ pipe_crc = igt_pipe_crc_new(data-debugfs, data-drm_fd,
+ connector-config.pipe,
+ INTEL_PIPE_CRC_SOURCE_PIPE);
+ igt_assert(igt_pipe_crc_start(pipe_crc));
+ }
/* wait for 3 vblanks and the corresponding 3 CRCs */
igt_pipe_crc_get_crcs(pipe_crc, 3, crcs);
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/16] drm/i915: Wire up CRC for vlv
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ff6970b..5841b6f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1961,6 +1961,29 @@ static int i8xx_pipe_crc_ctl_reg(enum
intel_pipe_crc_source source,
return 0;
}
+static int vlv_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+ uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PIPE_VLV;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_DP_B:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_B_VLV;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_DP_C:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_VLV;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ *val = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
enum intel_pipe_crc_source source,
uint32_t *val)
@@ -2067,6 +2090,8 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
ret = i8xx_pipe_crc_ctl_reg(source, val);
else if (INTEL_INFO(dev)-gen 5)
ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
+ else if (IS_VALLEYVIEW(dev))
+ ret = vlv_pipe_crc_ctl_reg(source, val);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
else
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/16] drm/i915: Wire up gen2 CRC support
Really simple, and we don't even have working frame numbers.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6de9e7e..ff6970b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1947,6 +1947,20 @@ static int display_crc_ctl_open(struct inode *inode,
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
}
+static int i8xx_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ *val = PIPE_CRC_ENABLE;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
enum intel_pipe_crc_source source,
uint32_t *val)
@@ -2049,7 +2063,9 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
if (pipe_crc-source source)
return -EINVAL;
- if (INTEL_INFO(dev)-gen 5)
+ if (IS_GEN2(dev))
+ ret = i8xx_pipe_crc_ctl_reg(source, val);
+ else if (INTEL_INFO(dev)-gen 5)
ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert Revert drm/i915: revert eDP bpp clamping code changes
On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote: BugLink: http://bugs.launchpad.net/bugs/1195483 This reverts commit 657445fe8660100ad174600ebfa61536392b7624. Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Paulo Zanoni przan...@gmail.com Cc: David Airlie airl...@linux.ie Cc: sta...@vger.kernel.org It's by far not that simple. Jani is working on both the underlying bug and a better w/a. See https://bugzilla.kernel.org/show_bug.cgi?id=59841 for the full story in its entire glory. 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
Re: [Intel-gfx] [PATCH] cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n
On Tuesday, October 08, 2013 10:56:11 AM Daniel Vetter wrote:
The drm/i915 driver wants to adjust it's own power policies using the
cpu policies as a guideline (we can implicitly boost the cpus through
the gpus on some platforms). To avoid a dreaded select (since a
depends will leave users wondering where where their driver has gone
too) add dummy functions.
Reported-by: kbuild test robot fengguang...@intel.com
Cc: kbuild test robot fengguang...@intel.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
A quick ack for merging this this through the drm-intel tree is
probably the simplest way forward.
Well, ACK, or please let me know if you want me to take this.
Thanks!
---
include/linux/cpufreq.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index fcabc42..5ad9a4e 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -93,8 +93,16 @@ struct cpufreq_policy {
#define CPUFREQ_SHARED_TYPE_ALL (2) /* All dependent CPUs should set
freq */
#define CPUFREQ_SHARED_TYPE_ANY (3) /* Freq can be set from any
dependent CPU*/
+#ifdef CONFIG_CPU_FREQ
struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu);
void cpufreq_cpu_put(struct cpufreq_policy *policy);
+#else
+static inline struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
+{
+ return NULL;
+}
+static inline void cpufreq_cpu_put(struct cpufreq_policy *policy) { }
+#endif
static inline bool policy_is_shared(struct cpufreq_policy *policy)
{
--
I speak only for myself.
Rafael J. Wysocki, 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] [IGT PATCH] README: list some of the dependencies
On Tue, Oct 08, 2013 at 09:19:06PM +0300, Jani Nikula wrote: Signed-off-by: Jani Nikula jani.nik...@intel.com --- README | 12 1 file changed, 12 insertions(+) diff --git a/README b/README index 653bfcd..a04c987 100644 --- a/README +++ b/README @@ -96,3 +96,15 @@ debugger/ initiating connections with debug clients.. The debugger must be run as root: sudo debugger/eudb + +DEPENDENCIES + This is a non-exchaustive list of package dependencies required for + building everything: + + libpciaccess-dev + libdrm-dev + xutils-dev + libcairo2-dev + swig2.0 + libpython3.3-dev + x11proto-dri2-dev I've pushed this. Some documentation is better than no documentation. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
