[Intel-gfx] [PATCH] drm/i915: Read the EDP DPCD and PSR Capability
From: Shobhit Kumar
v2: reuse of just created is_edp_psr and put it at right place.
v3: move is_edp_psr above intel_edp_disable
Reviewed-by: Paulo Zanoni
Reviewed-by: Jani Nikula
Signed-off-by: Shobhit Kumar
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 13 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 759a1c5..5332186 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1342,6 +1342,12 @@ static void intel_dp_get_config(struct intel_encoder
*encoder,
pipe_config->adjusted_mode.flags |= flags;
}
+static bool is_edp_psr(struct intel_dp *intel_dp)
+{
+ return (is_edp(intel_dp) &&
+ (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED));
+}
+
static void intel_disable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
@@ -2255,6 +2261,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
+ /* Check if the panel supports PSR */
+ memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
+ intel_dp_aux_native_read_retry(intel_dp, DP_PSR_SUPPORT,
+ intel_dp->psr_dpcd,
+ sizeof(intel_dp->psr_dpcd));
+ if (is_edp_psr(intel_dp))
+ DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
DP_DWN_STRM_PORT_PRESENT))
return true; /* native DP sink */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0445d8c..18d9dea 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -470,6 +470,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+ uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Added SDP and VSC structures for handling PSR for eDP
From: Shobhit Kumar
SDP header and SDP VSC header as per eDP 1.3 spec, section 3.5,
chapter "PSR Secondary Data Package Support".
v2: Modified and corrected the structures to be more in line for
kernel coding guidelines and rebased the code on Paulo's DP patchset
v3: removing unecessary identation at DP_RECEIVER_CAP_SIZE
v4: moving them to include/drm/drm_dp_helper.h and also already
icluding EDP_PSR_RECEIVER_CAP_SIZE to add everything needed
for PSR at once at drm_dp_helper.h
v5: Fix SDP VSC header and identation by (Paulo Zanoni) and
remove i915 from title (Daniel Vetter)
v6: Fix spec version and move comments from code to commit message
since numbers might change in the future (by Paulo Zanoni).
CC: Paulo Zanoni
Reviewed-by: Paulo Zanoni
Signed-off-by: Sateesh Kavuri
Signed-off-by: Shobhit Kumar
Signed-off-by: Rodrigo Vivi
---
include/drm/drm_dp_helper.h | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e8e1417..ae8dbfb 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -342,13 +342,42 @@ u8 drm_dp_get_adjust_request_voltage(u8
link_status[DP_LINK_STATUS_SIZE],
u8 drm_dp_get_adjust_request_pre_emphasis(u8 link_status[DP_LINK_STATUS_SIZE],
int lane);
-#define DP_RECEIVER_CAP_SIZE 0xf
+#define DP_RECEIVER_CAP_SIZE 0xf
+#define EDP_PSR_RECEIVER_CAP_SIZE 2
+
void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
u8 drm_dp_link_rate_to_bw_code(int link_rate);
int drm_dp_bw_code_to_link_rate(u8 link_bw);
+struct edp_sdp_header {
+ u8 HB0; /* Secondary Data Packet ID */
+ u8 HB1; /* Secondary Data Packet Type */
+ u8 HB2; /* 7:5 reserved, 4:0 revision number */
+ u8 HB3; /* 7:5 reserved, 4:0 number of valid data bytes */
+} __packed;
+
+#define EDP_SDP_HEADER_REVISION_MASK 0x1F
+#define EDP_SDP_HEADER_VALID_PAYLOAD_BYTES 0x1F
+
+struct edp_vsc_psr {
+ struct edp_sdp_header sdp_header;
+ u8 DB0; /* Stereo Interface */
+ u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid */
+ u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
+ u8 DB3; /* CRC value bits 15:8 of the R or Cr component */
+ u8 DB4; /* CRC value bits 7:0 of the G or Y component */
+ u8 DB5; /* CRC value bits 15:8 of the G or Y component */
+ u8 DB6; /* CRC value bits 7:0 of the B or Cb component */
+ u8 DB7; /* CRC value bits 15:8 of the B or Cb component */
+ u8 DB8_31[24]; /* Reserved */
+} __packed;
+
+#define EDP_VSC_PSR_STATE_ACTIVE (1<<0)
+#define EDP_VSC_PSR_UPDATE_RFB (1<<1)
+#define EDP_VSC_PSR_CRC_VALUES_VALID (1<<2)
+
static inline int
drm_dp_max_link_rate(u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] [v2] drm/i915: Fix context sizes on HSW
With updates to the spec, we can actually see the context layout, and how many dwords are allocated. That table suggests we need 70720 bytes per HW context. Rounded up, this is 18 pages. Looking at what lives after the current 4 pages we use, I can't see too much important (mostly it's d3d related), but there are a couple of things which look scary. I am hopeful this can explain some of our odd HSW failures. v2: Make the context only 17 pages. The power context space isn't used ever, and execlists aren't used in our driver, making the actual total 66944 bytes. Reported-by: "Azad, Vinit" Cc: sta...@vger.kernel.org Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 9 + 2 files changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index ff47145..51b7a21 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -113,7 +113,7 @@ static int get_context_size(struct drm_device *dev) case 7: reg = I915_READ(GEN7_CXT_SIZE); if (IS_HASWELL(dev)) - ret = HSW_CXT_TOTAL_SIZE(reg) * 64; + ret = HSW_CXT_TOTAL_SIZE; else ret = GEN7_CXT_TOTAL_SIZE(reg) * 64; break; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 2102ff3..f061c67 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1718,14 +1718,7 @@ GEN7_CXT_EXTENDED_SIZE(ctx_reg) + \ GEN7_CXT_GT1_SIZE(ctx_reg) + \ GEN7_CXT_VFSTATE_SIZE(ctx_reg)) -#define HSW_CXT_POWER_SIZE(ctx_reg)((ctx_reg >> 26) & 0x3f) -#define HSW_CXT_RING_SIZE(ctx_reg) ((ctx_reg >> 23) & 0x7) -#define HSW_CXT_RENDER_SIZE(ctx_reg) ((ctx_reg >> 15) & 0xff) -#define HSW_CXT_TOTAL_SIZE(ctx_reg)(HSW_CXT_POWER_SIZE(ctx_reg) + \ -HSW_CXT_RING_SIZE(ctx_reg) + \ -HSW_CXT_RENDER_SIZE(ctx_reg) + \ -GEN7_CXT_VFSTATE_SIZE(ctx_reg)) - +#define HSW_CXT_TOTAL_SIZE (17 * PAGE_SIZE) /* * Overlay regs -- 1.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Fix a couple of "should it be static?" sparse warnings
A genuine 'static' omission and 2 other warnings triggered by not
including the header where those functions where defined.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cc9440b..154d0a4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -30,6 +30,7 @@
#include "intel_drv.h"
#include "../../../platform/x86/intel_ips.h"
#include
+#include
#define FORCEWAKE_ACK_TIMEOUT_MS 2
@@ -2465,8 +2466,8 @@ static void hsw_compute_wm_results(struct drm_device *dev,
/* Find the result with the highest level enabled. Check for enable_fbc_wm in
* case both are at the same level. Prefer r1 in case they're the same. */
-struct hsw_wm_values *hsw_find_best_result(struct hsw_wm_values *r1,
- struct hsw_wm_values *r2)
+static struct hsw_wm_values *hsw_find_best_result(struct hsw_wm_values *r1,
+ struct hsw_wm_values *r2)
{
int i, val_r1 = 0, val_r2 = 0;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Use seq_puts/seq_putc when possible
Caught with checkpatch.pl.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 110 ++--
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4dcaee3..858688d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -157,11 +157,11 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
switch (list) {
case ACTIVE_LIST:
- seq_printf(m, "Active:\n");
+ seq_puts(m, "Active:\n");
head = &dev_priv->mm.active_list;
break;
case INACTIVE_LIST:
- seq_printf(m, "Inactive:\n");
+ seq_puts(m, "Inactive:\n");
head = &dev_priv->mm.inactive_list;
break;
default:
@@ -171,9 +171,9 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
total_obj_size = total_gtt_size = count = 0;
list_for_each_entry(obj, head, mm_list) {
- seq_printf(m, " ");
+ seq_puts(m, " ");
describe_obj(m, obj);
- seq_printf(m, "\n");
+ seq_putc(m, '\n');
total_obj_size += obj->base.size;
total_gtt_size += obj->gtt_space->size;
count++;
@@ -290,7 +290,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
dev_priv->gtt.total,
dev_priv->gtt.mappable_end - dev_priv->gtt.start);
- seq_printf(m, "\n");
+ seq_putc(m, '\n');
list_for_each_entry_reverse(file, &dev->filelist, lhead) {
struct file_stats stats;
@@ -329,9 +329,9 @@ static int i915_gem_gtt_info(struct seq_file *m, void* data)
if (list == PINNED_LIST && obj->pin_count == 0)
continue;
- seq_printf(m, " ");
+ seq_puts(m, " ");
describe_obj(m, obj);
- seq_printf(m, "\n");
+ seq_putc(m, '\n');
total_obj_size += obj->base.size;
total_gtt_size += obj->gtt_space->size;
count++;
@@ -371,9 +371,9 @@ static int i915_gem_pageflip_info(struct seq_file *m, void
*data)
pipe, plane);
}
if (work->enable_stall_check)
- seq_printf(m, "Stall check enabled, ");
+ seq_puts(m, "Stall check enabled, ");
else
- seq_printf(m, "Stall check waiting for page
flip ioctl, ");
+ seq_puts(m, "Stall check waiting for page flip
ioctl, ");
seq_printf(m, "%d prepares\n",
atomic_read(&work->pending));
if (work->old_fb_obj) {
@@ -424,7 +424,7 @@ static int i915_gem_request_info(struct seq_file *m, void
*data)
mutex_unlock(&dev->struct_mutex);
if (count == 0)
- seq_printf(m, "No requests\n");
+ seq_puts(m, "No requests\n");
return 0;
}
@@ -574,10 +574,10 @@ static int i915_gem_fence_regs_info(struct seq_file *m,
void *data)
seq_printf(m, "Fence %d, pin count = %d, object = ",
i, dev_priv->fence_regs[i].pin_count);
if (obj == NULL)
- seq_printf(m, "unused");
+ seq_puts(m, "unused");
else
describe_obj(m, obj);
- seq_printf(m, "\n");
+ seq_putc(m, '\n');
}
mutex_unlock(&dev->struct_mutex);
@@ -1197,7 +1197,7 @@ static int i915_cur_delayinfo(struct seq_file *m, void
*unused)
(freq_sts >> 8) & 0xff));
mutex_unlock(&dev_priv->rps.hw_lock);
} else {
- seq_printf(m, "no P-state info available\n");
+ seq_puts(m, "no P-state info available\n");
}
return 0;
@@ -1292,28 +1292,28 @@ static int ironlake_drpc_info(struct seq_file *m)
seq_printf(m, "RS2 VID: %d\n", ((crstandvid >> 8) & 0x3f));
seq_printf(m, "Render standby enabled: %s\n",
(rstdbyctl & RCX_SW_EXIT) ? "no" : "yes");
- seq_printf(m, "Current RS state: ");
+ seq_puts(m, "Current RS state: ");
switch (rstdbyctl & RSX_STATUS_MASK) {
case RSX_STATUS_ON:
- seq_printf(m, "on\n");
+ seq_puts(m, "on\n");
break;
case RSX_STATUS_RC1:
- seq_printf(m, "RC1\n");
+ seq_puts(m, "RC1\n");
break;
case RSX_STATUS_RC1E:
- seq_printf(m, "RC1E\n");
+ seq_puts(m, "RC1E\n");
break
[Intel-gfx] [PATCH 2/3] drm/i915: Fix a few style issues found by checkpatch.pl
Missing spaces and misplaced '*'.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 858688d..7afc967 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -222,7 +222,7 @@ static int per_file_stats(int id, void *ptr, void *data)
return 0;
}
-static int i915_gem_object_info(struct seq_file *m, void* data)
+static int i915_gem_object_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
@@ -310,7 +310,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
-static int i915_gem_gtt_info(struct seq_file *m, void* data)
+static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
@@ -1328,8 +1328,7 @@ static int gen6_drpc_info(struct seq_file *m)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 rpmodectl1, gt_core_status, rcctl1, rc6vids = 0;
unsigned forcewake_count;
- int count=0, ret;
-
+ int count = 0, ret;
ret = mutex_lock_interruptible(&dev->struct_mutex);
if (ret)
@@ -1732,7 +1731,7 @@ static int i915_gen6_forcewake_count_info(struct seq_file
*m, void *data)
static const char *swizzle_string(unsigned swizzle)
{
- switch(swizzle) {
+ switch (swizzle) {
case I915_BIT_6_SWIZZLE_NONE:
return "none";
case I915_BIT_6_SWIZZLE_9:
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl
On Mon, 8 Apr 2013 21:24:58 +0200 Daniel Vetter wrote: > On Mon, Apr 8, 2013 at 7:40 PM, Chris Wilson wrote: > > On Mon, Apr 08, 2013 at 07:18:11PM +0200, Daniel Vetter wrote: > >> On Tue, Feb 12, 2013 at 02:17:22PM +, Chris Wilson wrote: > >> > By exporting the ability to map user address and inserting PTEs > >> > representing their backing pages into the GTT, we can exploit UMA in > >> > order > >> > to utilize normal application data as a texture source or even as a > >> > render target (depending upon the capabilities of the chipset). This has > >> > a number of uses, with zero-copy downloads to the GPU and efficient > >> > readback making the intermixed streaming of CPU and GPU operations > >> > fairly efficient. This ability has many widespread implications from > >> > faster rendering of client-side software rasterisers (chromium), > >> > mitigation of stalls due to read back (firefox) and to faster pipelining > >> > of texture data (such as pixel buffer objects in GL or data blobs in CL). > >> > > >> > v2: Compile with CONFIG_MMU_NOTIFIER > >> > v3: We can sleep while performing invalidate-range, which we can utilise > >> > to drop our page references prior to the kernel manipulating the vma > >> > (for either discard or cloning) and so protect normal users. > >> > v4: Only run the invalidate notifier if the range intercepts the bo. > >> > v5: Prevent userspace from attempting to GTT mmap non-page aligned > >> > buffers > >> > > >> > Signed-off-by: Chris Wilson > >> > >> Quick bikeshed: > >> - Still not really in favour of the in-page gtt offset handling ... I > >> still think that this is just a fancy mmap api, and it better reject > >> attempts to not map anything aligned to a full page outright. > > > > Strongly disagree. > > Ok, let's dig out the beaten arguments here ;-) > - Imo the gtt_offset frobbery is a bit fragile, and getting this right > in the face of ppgtt won't make it better. And yes the only reason we > still have that field is that you've shot down any patch to remove it > citing userptr here. So "it's here already" doesn't count ;-) > - Userptr for i915 is an mmap interface, and that works on pages, > lying to userspace isn't great. > - I don't see why userspace can't do this themselves. I've seen that > it makes things easier in SNA/X, but for a general purpose interface > that argument doesn't cut too much. > - I'm also a bit afraid that our code implicitly assumes that > size/offset are always page-aligned and I kinda want to avoid that we > have to audit for such issues from here on. We've blown up in the past > assuming that size > 0 already, I think we're set to blow up on this > one here. > > In any case, if you really want to stick to this I want this to be > explictly track in an obj->reloc_gtt_offset_adjustment or something > which is very loudly yelling at people to make sure no one trips over > it. Tracking the adjustment in a separate field, which would only ever > be used in the reloc code would address all my concerns (safe for the > api ugliness one). Resurrecting this again. I'm of two minds on the API here: on the one hand, it can be nicer for the kernel to handle this stuff if it can be done easily, and save userspace the trouble. But OTOH, consistent with existing page based interfaces makes things a little less jarring... > > >> - I915_USERPTR_UNSYNCHRONIZED ... eeek. That means that despite everyone > >> having mmu notifiers enabled in their distro config, you make sure sna > >> doesn't hit it. Imo not enough testing coverage ;-) Or this there > >> another reason behind this than "mmu notifiers are too slow"? > >> > >> Generally I'm a bit sloppy with going root-only for legacy X stuff (like > >> scanline waits), but this here looks very much generally useful. So not > >> exemption-material imo. > > > > Strongly disagree. Most of my machines do not have mmu-notifiers and > > would still like to benefit from userptr and I see no reason why we need > > to force mmu-notifiers. > > Note that I didn't shout against the mmu_notifier-less support > (although I'm honestly not too happy about it), what I don't like is > the override bit disabling the mmu_notifiers even if we have them. > Since that will mean that the code won't be tested through SNA, and so > has a good chance of being buggy. Once mesa comes around and uses it, > it'll nicely blow up. And one of the reason Jesse is breathing down my > neck to merge this is "other guys are interested in this at intel". I think we'll need good test cases to cover things regardless. And yes, an mmu notifier version that doesn't require root would be more generally useful than a root only interface (or are those items unrelated at this point?). Having a flag for root only operation for clients that know what they're doing is fine though, IMO. I think one of the nice use cases the Mesa guys have is to save an extra copy in glReadPixels for certain types of objects, which means non-root
[Intel-gfx] [PATCH] drm/i915: Fix up sdvo hpd pins for i965g/gm
Bspec seems to be full of lies, at least it disagress with reality:
Two systems corrobated that SDVO hpd bits are the same as on gen3.
v2: Update comment a bit.
Cc: Arthur Ranyan
Cc: Chris Wilson
Tested-by: Chris Wilson
Reported-and-tested-by: Alex Fiestas
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 13 ++---
drivers/gpu/drm/i915/i915_reg.h | 13 ++---
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7857430..611da3a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -70,15 +70,6 @@ static const u32 hpd_status_gen4[] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-static const u32 hpd_status_i965[] = {
-[HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
-[HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_I965,
-[HPD_SDVO_C] = SDVOC_HOTPLUG_INT_STATUS_I965,
-[HPD_PORT_B] = PORTB_HOTPLUG_INT_STATUS,
-[HPD_PORT_C] = PORTC_HOTPLUG_INT_STATUS,
-[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
-};
-
static const u32 hpd_status_i915[] = { /* i915 and valleyview are the same */
[HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
[HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_I915,
@@ -3449,13 +3440,13 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
u32 hotplug_trigger = hotplug_status & (IS_G4X(dev) ?
HOTPLUG_INT_STATUS_G4X :
-
HOTPLUG_INT_STATUS_I965);
+
HOTPLUG_INT_STATUS_I915);
DRM_DEBUG_DRIVER("hotplug event received, stat
0x%08x\n",
hotplug_status);
if (hotplug_trigger) {
if (hotplug_irq_storm_detect(dev,
hotplug_trigger,
- IS_G4X(dev) ?
hpd_status_gen4 : hpd_status_i965))
+ IS_G4X(dev) ?
hpd_status_gen4 : hpd_status_i915))
i915_hpd_irq_setup(dev);
queue_work(dev_priv->wq,
&dev_priv->hotplug_work);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2102ff3..137be4c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1874,6 +1874,12 @@
/* SDVO is different across gen3/4 */
#define SDVOC_HOTPLUG_INT_STATUS_G4X (1 << 3)
#define SDVOB_HOTPLUG_INT_STATUS_G4X (1 << 2)
+/*
+ * Bspec seems to be seriously misleaded about the SDVO hpd bits on i965g/gm,
+ * since reality corrobates that they're the same as on gen3. But keep these
+ * bits here (and the comment!) to help any other lost wanderers back onto the
+ * right tracks.
+ */
#define SDVOC_HOTPLUG_INT_STATUS_I965(3 << 4)
#define SDVOB_HOTPLUG_INT_STATUS_I965(3 << 2)
#define SDVOC_HOTPLUG_INT_STATUS_I915(1 << 7)
@@ -1885,13 +1891,6 @@
PORTC_HOTPLUG_INT_STATUS | \
PORTD_HOTPLUG_INT_STATUS)
-#define HOTPLUG_INT_STATUS_I965(CRT_HOTPLUG_INT_STATUS
| \
-SDVOB_HOTPLUG_INT_STATUS_I965
| \
-SDVOC_HOTPLUG_INT_STATUS_I965
| \
-PORTB_HOTPLUG_INT_STATUS | \
-PORTC_HOTPLUG_INT_STATUS | \
-PORTD_HOTPLUG_INT_STATUS)
-
#define HOTPLUG_INT_STATUS_I915(CRT_HOTPLUG_INT_STATUS
| \
SDVOB_HOTPLUG_INT_STATUS_I915
| \
SDVOC_HOTPLUG_INT_STATUS_I915
| \
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broadcast RGB questions
On Mon, Jun 24, 2013 at 6:19 PM, Tom Horsley wrote: > I don't suppose there is a way to set the default value for > this property with a kernel boot option is there? I keep > thinking my monitor is broken or my eyes have gone bad > while watching the boot messages scroll past :-). > (Anyone feel like adding such a kernel option?) We're toying around with ideas to load a full config (including any options) through a device-tree firmware blob. Adding tons more module options seems to have stopped scaling a while back. This would also allow us to quirk anything with can be quirked with xrandr. > If I can't get it set that early, does anyone have a > working example of the sort of xorg.conf fragment > I can stick in /etc/X11/xorg.conf.d/ to set it > as soon as X comes up on my system? (The docs > for xorg.conf seem to have been designed to > cause brains to explode when trying to understand > them). > > I am able to set it with xrandr but it makes my > monitor flicker when it changes (I thought avoiding > that sort of thing was why kernel mode setting > was invented :-). We need to do a full modeset when updating that attribute, so the flickering is expected. Fundamentally kms is about not blowing up since userspace really has no business touching the hw (especially in corporation with the kernel for dri1), less flickering is just the icing on the cake of a much more mature kms driver than userspace modesetting ever was. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix up sdvo hpd pins for i965g/gm
Bspec seems to be full of lies, at least it disagress with reality:
Two systems corrobated that SDVO hpd bits are the same as on gen3.
Cc: Arthur Ranyan
Cc: Chris Wilson
Tested-by: Chris Wilson
Reported-and-tested-by: Alex Fiestas
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 13 ++---
drivers/gpu/drm/i915/i915_reg.h | 13 ++---
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7857430..611da3a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -70,15 +70,6 @@ static const u32 hpd_status_gen4[] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-static const u32 hpd_status_i965[] = {
-[HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
-[HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_I965,
-[HPD_SDVO_C] = SDVOC_HOTPLUG_INT_STATUS_I965,
-[HPD_PORT_B] = PORTB_HOTPLUG_INT_STATUS,
-[HPD_PORT_C] = PORTC_HOTPLUG_INT_STATUS,
-[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
-};
-
static const u32 hpd_status_i915[] = { /* i915 and valleyview are the same */
[HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
[HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_I915,
@@ -3449,13 +3440,13 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
u32 hotplug_trigger = hotplug_status & (IS_G4X(dev) ?
HOTPLUG_INT_STATUS_G4X :
-
HOTPLUG_INT_STATUS_I965);
+
HOTPLUG_INT_STATUS_I915);
DRM_DEBUG_DRIVER("hotplug event received, stat
0x%08x\n",
hotplug_status);
if (hotplug_trigger) {
if (hotplug_irq_storm_detect(dev,
hotplug_trigger,
- IS_G4X(dev) ?
hpd_status_gen4 : hpd_status_i965))
+ IS_G4X(dev) ?
hpd_status_gen4 : hpd_status_i915))
i915_hpd_irq_setup(dev);
queue_work(dev_priv->wq,
&dev_priv->hotplug_work);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2102ff3..5a89e7d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1874,6 +1874,12 @@
/* SDVO is different across gen3/4 */
#define SDVOC_HOTPLUG_INT_STATUS_G4X (1 << 3)
#define SDVOB_HOTPLUG_INT_STATUS_G4X (1 << 2)
+/*
+ * Bspec seems to be seriously misleaded about the SDVO hpd bits on i965g/gm,
+ * since reality corrobates that they're the same as on gen3. But keep these
+ * bits here (and the comment!) to help any travellers back onto the right
+ * tracks.
+ */
#define SDVOC_HOTPLUG_INT_STATUS_I965(3 << 4)
#define SDVOB_HOTPLUG_INT_STATUS_I965(3 << 2)
#define SDVOC_HOTPLUG_INT_STATUS_I915(1 << 7)
@@ -1885,13 +1891,6 @@
PORTC_HOTPLUG_INT_STATUS | \
PORTD_HOTPLUG_INT_STATUS)
-#define HOTPLUG_INT_STATUS_I965(CRT_HOTPLUG_INT_STATUS
| \
-SDVOB_HOTPLUG_INT_STATUS_I965
| \
-SDVOC_HOTPLUG_INT_STATUS_I965
| \
-PORTB_HOTPLUG_INT_STATUS | \
-PORTC_HOTPLUG_INT_STATUS | \
-PORTD_HOTPLUG_INT_STATUS)
-
#define HOTPLUG_INT_STATUS_I915(CRT_HOTPLUG_INT_STATUS
| \
SDVOB_HOTPLUG_INT_STATUS_I915
| \
SDVOC_HOTPLUG_INT_STATUS_I915
| \
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Introduce an HAS_IPS() macro
On Mon, Jun 24, 2013 at 06:29:34PM +0100, Damien Lespiau wrote:
> Follow the trend and don't code conditions with platforms but with
> features.
>
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 4dcaee3..913f02e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1486,7 +1486,7 @@ static int i915_ips_status(struct seq_file *m, void
> *unused)
> struct drm_device *dev = node->minor->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> - if (!IS_ULT(dev)) {
> + if (!HAS_IPS(dev)) {
> seq_puts(m, "not supported\n");
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2b8b7ac..92c3bcf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1481,6 +1481,8 @@ struct drm_i915_file_private {
> #define HAS_PIPE_CXSR(dev) (INTEL_INFO(dev)->has_pipe_cxsr)
> #define I915_HAS_FBC(dev) (INTEL_INFO(dev)->has_fbc)
>
> +#define HAS_IPS(dev) (IS_ULT(dev))
> +
> #define HAS_PIPE_CONTROL(dev) (INTEL_INFO(dev)->gen >= 5)
>
> #define HAS_DDI(dev) (INTEL_INFO(dev)->has_ddi)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 218bc93..af2b5ab 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3250,7 +3250,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
> /* IPS only exists on ULT machines and is tied to pipe A. */
> static bool hsw_crtc_supports_ips(struct intel_crtc *crtc)
> {
> - return IS_ULT(crtc->base.dev) && crtc->pipe == PIPE_A;
> + return HAS_IPS(crtc->base.dev) && crtc->pipe == PIPE_A;
> }
>
> static void hsw_enable_ips(struct intel_crtc *crtc)
> @@ -4069,7 +4069,7 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
> pipe_config->pipe_bpp = 8*3;
> }
>
> - if (IS_HASWELL(dev))
> + if (HAS_IPS(dev))
> hsw_compute_ips_config(crtc, pipe_config);
>
> /* XXX: PCH clock sharing is done in ->mode_set, so make sure the old
> --
> 1.8.1.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] drm/i915: fix build warning on format specifier mismatch
On Tue, Jun 11, 2013 at 09:57:26AM +0300, Ville Syrjälä wrote:
> On Fri, Jun 07, 2013 at 04:03:50PM +0300, Jani Nikula wrote:
> > drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’:
> > drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects
> > argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat]
> >
> > v2: Use %zu instead of %d. Two char patch, and 100% wrong. (Ville)
> >
> > Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Queued for -next, thanks for the patch.
-Daniel
>
> > ---
> > drivers/gpu/drm/i915/i915_gem.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 58048d4..c2b60a4 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2999,7 +2999,7 @@ i915_gem_object_bind_to_gtt(struct
> > drm_i915_gem_object *obj,
> > * before evicting everything in a vain attempt to find space.
> > */
> > if (obj->base.size > gtt_max) {
> > - DRM_ERROR("Attempting to bind an object larger than the
> > aperture: object=%zd > %s aperture=%ld\n",
> > + DRM_ERROR("Attempting to bind an object larger than the
> > aperture: object=%zd > %s aperture=%zu\n",
> > obj->base.size,
> > map_and_fenceable ? "mappable" : "total",
> > gtt_max);
> > --
> > 1.7.9.5
> >
> > ___
> > 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
--
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 2/2] drm/i915: Fix reason for per-chip disabling of FBC
On Mon, Jun 24, 2013 at 04:22:02PM +0100, Damien Lespiau wrote:
> When running on my snb machine, recent kernels display successively:
>
> [drm:intel_update_fbc], fbc set to per-chip default
> [drm:intel_update_fbc], fbc disabled per module param
>
> But no module param is set. This happens because the check for the
> module parameter uses a variable that has been overridden inside the
> "per-chip default" code.
>
> Fix up the logic and add another reason for the FBC to the be disabled.
>
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch. Aside: checkpatch suggests an
s/seq_printf/seq_puts/ here ...
-Daniel
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 14 ++
> 3 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d4e78b6..4dcaee3 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1469,6 +1469,9 @@ static int i915_fbc_status(struct seq_file *m, void
> *unused)
> case FBC_MODULE_PARAM:
> seq_printf(m, "disabled per module param (default
> off)");
> break;
> + case FBC_CHIP_DEFAULT:
> + seq_printf(m, "disabled per chip default");
> + break;
> default:
> seq_printf(m, "unknown reason");
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 10a56c9..2b8b7ac 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -543,6 +543,7 @@ enum no_fbc_reason {
> FBC_NOT_TILED, /* buffer not tiled */
> FBC_MULTIPLE_PIPES, /* more than one pipe active */
> FBC_MODULE_PARAM,
> + FBC_CHIP_DEFAULT, /* disabled by default on this chip */
> };
>
> enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a8483f5..fd70a82 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -448,7 +448,6 @@ void intel_update_fbc(struct drm_device *dev)
> struct drm_framebuffer *fb;
> struct intel_framebuffer *intel_fb;
> struct drm_i915_gem_object *obj;
> - int enable_fbc;
> unsigned int max_hdisplay, max_vdisplay;
>
> if (!i915_powersave)
> @@ -489,14 +488,13 @@ void intel_update_fbc(struct drm_device *dev)
> intel_fb = to_intel_framebuffer(fb);
> obj = intel_fb->obj;
>
> - enable_fbc = i915_enable_fbc;
> - if (enable_fbc < 0) {
> - DRM_DEBUG_KMS("fbc set to per-chip default\n");
> - enable_fbc = 1;
> - if (INTEL_INFO(dev)->gen <= 7 && !IS_HASWELL(dev))
> - enable_fbc = 0;
> + if (i915_enable_fbc < 0 &&
> + INTEL_INFO(dev)->gen <= 7 && !IS_HASWELL(dev)) {
> + DRM_DEBUG_KMS("disabled per chip default\n");
> + dev_priv->no_fbc_reason = FBC_CHIP_DEFAULT;
> + goto out_disable;
> }
> - if (!enable_fbc) {
> + if (!i915_enable_fbc) {
> DRM_DEBUG_KMS("fbc disabled per module param\n");
> dev_priv->no_fbc_reason = FBC_MODULE_PARAM;
> goto out_disable;
> --
> 1.8.1.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 1/2] drm/i915: Make intel_enable_fbc() static
On Mon, Jun 24, 2013 at 04:22:01PM +0100, Damien Lespiau wrote:
> This function has no user outside of intel_pm.c.
>
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch. On the topic of stuff that sparse
can catch, we've accumulated a few other ones. On a quick look I think the
other non-static functions without declaration and the few enum transcoder
vs. enum pipe mismatche seem to be worth fixing. Volunteered?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index ffe9d35..a165be6 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -779,7 +779,6 @@ extern int intel_sprite_get_colorkey(struct drm_device
> *dev, void *data,
> extern void intel_init_pm(struct drm_device *dev);
> /* FBC */
> extern bool intel_fbc_enabled(struct drm_device *dev);
> -extern void intel_enable_fbc(struct drm_crtc *crtc, unsigned long interval);
> extern void intel_update_fbc(struct drm_device *dev);
> /* IPS */
> extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b27bda0..a8483f5 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -368,7 +368,7 @@ static void intel_cancel_fbc_work(struct drm_i915_private
> *dev_priv)
> dev_priv->fbc_work = NULL;
> }
>
> -void intel_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
> +static void intel_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
> {
> struct intel_fbc_work *work;
> struct drm_device *dev = crtc->dev;
> --
> 1.8.1.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] drm/i915: tune down DIDL warning about too many outputs
On Mon, Jun 24, 2013 at 06:06:35PM +0100, Damien Lespiau wrote:
> On Mon, Jun 24, 2013 at 06:32:36PM +0200, Daniel Vetter wrote:
> > Nothing the user (nor we) really can do about this, but upsets a nice
> > quiet boot.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Damien Lespiau
Queued for -next (with slightly amended commit message to clarify the
question from Paulo), thanks for the review.
-Daniel
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/i915/intel_opregion.c |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > b/drivers/gpu/drm/i915/intel_opregion.c
> > index 79be7cf..cfb8fb6 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -311,8 +311,8 @@ static void intel_didl_outputs(struct drm_device *dev)
> >
> > list_for_each_entry(acpi_cdev, &acpi_video_bus->children, node) {
> > if (i >= 8) {
> > - dev_printk(KERN_ERR, &dev->pdev->dev,
> > - "More than 8 outputs detected via ACPI\n");
> > + dev_dbg(&dev->pdev->dev,
> > + "More than 8 outputs detected via ACPI\n");
> > return;
> > }
> > status =
> > @@ -338,8 +338,8 @@ blind_set:
> > list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> > int output_type = ACPI_OTHER_OUTPUT;
> > if (i >= 8) {
> > - dev_printk(KERN_ERR, &dev->pdev->dev,
> > - "More than 8 outputs in connector list\n");
> > + dev_dbg(&dev->pdev->dev,
> > + "More than 8 outputs in connector list\n");
> > return;
> > }
> > switch (connector->connector_type) {
> > --
> > 1.7.10.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] drm/i915: tune down DIDL warning about too many outputs
On Mon, Jun 24, 2013 at 7:30 PM, Paulo Zanoni wrote: > 2013/6/24 Daniel Vetter : >> Nothing the user (nor we) really can do about this, but upsets a nice >> quiet boot. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988 >> Signed-off-by: Daniel Vetter > > What exactly is the impact of this problem? What happens when we > detect this? If we don't know which problems could happen when we > reach this condition, then I really don't think we should tune down > the message. If we know what is the impact of that message, then I > think we should add a nice comment explaining that, and only then > maybe tune down the message. > > By the way, this message is seen on all Haswell machines I checked. It means that the BIOS set up more outputs than what OpRegion supports. Tends to happen a lot with SDVs. Afaik there's nothing we can do when this happens. -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: tune down DIDL warning about too many outputs
2013/6/24 Daniel Vetter :
> Nothing the user (nor we) really can do about this, but upsets a nice
> quiet boot.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988
> Signed-off-by: Daniel Vetter
What exactly is the impact of this problem? What happens when we
detect this? If we don't know which problems could happen when we
reach this condition, then I really don't think we should tune down
the message. If we know what is the impact of that message, then I
think we should add a nice comment explaining that, and only then
maybe tune down the message.
By the way, this message is seen on all Haswell machines I checked.
> ---
> drivers/gpu/drm/i915/intel_opregion.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 79be7cf..cfb8fb6 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -311,8 +311,8 @@ static void intel_didl_outputs(struct drm_device *dev)
>
> list_for_each_entry(acpi_cdev, &acpi_video_bus->children, node) {
> if (i >= 8) {
> - dev_printk(KERN_ERR, &dev->pdev->dev,
> - "More than 8 outputs detected via ACPI\n");
> + dev_dbg(&dev->pdev->dev,
> + "More than 8 outputs detected via ACPI\n");
> return;
> }
> status =
> @@ -338,8 +338,8 @@ blind_set:
> list_for_each_entry(connector, &dev->mode_config.connector_list,
> head) {
> int output_type = ACPI_OTHER_OUTPUT;
> if (i >= 8) {
> - dev_printk(KERN_ERR, &dev->pdev->dev,
> - "More than 8 outputs in connector list\n");
> + dev_dbg(&dev->pdev->dev,
> + "More than 8 outputs in connector list\n");
> return;
> }
> switch (connector->connector_type) {
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Introduce an HAS_IPS() macro
Follow the trend and don't code conditions with platforms but with
features.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 4 ++--
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4dcaee3..913f02e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1486,7 +1486,7 @@ static int i915_ips_status(struct seq_file *m, void
*unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- if (!IS_ULT(dev)) {
+ if (!HAS_IPS(dev)) {
seq_puts(m, "not supported\n");
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b8b7ac..92c3bcf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1481,6 +1481,8 @@ struct drm_i915_file_private {
#define HAS_PIPE_CXSR(dev) (INTEL_INFO(dev)->has_pipe_cxsr)
#define I915_HAS_FBC(dev) (INTEL_INFO(dev)->has_fbc)
+#define HAS_IPS(dev) (IS_ULT(dev))
+
#define HAS_PIPE_CONTROL(dev) (INTEL_INFO(dev)->gen >= 5)
#define HAS_DDI(dev) (INTEL_INFO(dev)->has_ddi)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 218bc93..af2b5ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3250,7 +3250,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
/* IPS only exists on ULT machines and is tied to pipe A. */
static bool hsw_crtc_supports_ips(struct intel_crtc *crtc)
{
- return IS_ULT(crtc->base.dev) && crtc->pipe == PIPE_A;
+ return HAS_IPS(crtc->base.dev) && crtc->pipe == PIPE_A;
}
static void hsw_enable_ips(struct intel_crtc *crtc)
@@ -4069,7 +4069,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
pipe_config->pipe_bpp = 8*3;
}
- if (IS_HASWELL(dev))
+ if (HAS_IPS(dev))
hsw_compute_ips_config(crtc, pipe_config);
/* XXX: PCH clock sharing is done in ->mode_set, so make sure the old
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: tune down DIDL warning about too many outputs
On Mon, Jun 24, 2013 at 06:32:36PM +0200, Daniel Vetter wrote:
> Nothing the user (nor we) really can do about this, but upsets a nice
> quiet boot.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_opregion.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 79be7cf..cfb8fb6 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -311,8 +311,8 @@ static void intel_didl_outputs(struct drm_device *dev)
>
> list_for_each_entry(acpi_cdev, &acpi_video_bus->children, node) {
> if (i >= 8) {
> - dev_printk(KERN_ERR, &dev->pdev->dev,
> -"More than 8 outputs detected via ACPI\n");
> + dev_dbg(&dev->pdev->dev,
> + "More than 8 outputs detected via ACPI\n");
> return;
> }
> status =
> @@ -338,8 +338,8 @@ blind_set:
> list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> int output_type = ACPI_OTHER_OUTPUT;
> if (i >= 8) {
> - dev_printk(KERN_ERR, &dev->pdev->dev,
> -"More than 8 outputs in connector list\n");
> + dev_dbg(&dev->pdev->dev,
> + "More than 8 outputs in connector list\n");
> return;
> }
> switch (connector->connector_type) {
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix context sizes on HSW
With updates to the spec, we can actually see the context layout, and how many dwords are allocated. That table suggests we need 70720 bytes per HW context. Rounded up, this is 18 pages. Looking at what lives after the current 4 pages we use, I can't see too much important (mostly it's d3d related), but there are a couple of things which look scary. I am hopeful this can explain some of our odd HSW failures. NOTE: There is some discrepancy in our internal docs about whether or not this should be 17, or 18 pages. Since for stable, and currently we don't use many contexts, just use 18 to be safe. We can trim it later. Reported-by: "Azad, Vinit" Cc: sta...@vger.kernel.org Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 9 + 2 files changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index ff47145..51b7a21 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -113,7 +113,7 @@ static int get_context_size(struct drm_device *dev) case 7: reg = I915_READ(GEN7_CXT_SIZE); if (IS_HASWELL(dev)) - ret = HSW_CXT_TOTAL_SIZE(reg) * 64; + ret = HSW_CXT_TOTAL_SIZE; else ret = GEN7_CXT_TOTAL_SIZE(reg) * 64; break; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 2102ff3..4344b77 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1718,14 +1718,7 @@ GEN7_CXT_EXTENDED_SIZE(ctx_reg) + \ GEN7_CXT_GT1_SIZE(ctx_reg) + \ GEN7_CXT_VFSTATE_SIZE(ctx_reg)) -#define HSW_CXT_POWER_SIZE(ctx_reg)((ctx_reg >> 26) & 0x3f) -#define HSW_CXT_RING_SIZE(ctx_reg) ((ctx_reg >> 23) & 0x7) -#define HSW_CXT_RENDER_SIZE(ctx_reg) ((ctx_reg >> 15) & 0xff) -#define HSW_CXT_TOTAL_SIZE(ctx_reg)(HSW_CXT_POWER_SIZE(ctx_reg) + \ -HSW_CXT_RING_SIZE(ctx_reg) + \ -HSW_CXT_RENDER_SIZE(ctx_reg) + \ -GEN7_CXT_VFSTATE_SIZE(ctx_reg)) - +#define HSW_CXT_TOTAL_SIZE (18 * PAGE_SIZE) /* * Overlay regs -- 1.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: PPGTT dump for debug
On Mon, Jun 24, 2013 at 10:01:33AM -0700, Ben Widawsky wrote: > No users yet > > Signed-off-by: Ben Widawsky I didn't mean to send this yet. Please ignore. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: PPGTT dump for debug
No users yet
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 893007a..005358f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -99,6 +99,37 @@ static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
return pte;
}
+void gen6_dump_ppgtt(struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = ppgtt->base.dev->dev_private;
+ gen6_gtt_pte_t __iomem *pd_addr;
+ uint32_t pd_entry;
+ int i, j;
+
+ pd_addr = (gen6_gtt_pte_t __iomem*)dev_priv->gtt.gsm +
+ ppgtt->pd_offset / sizeof(gen6_gtt_pte_t);
+
+ for (i = 0; i < ppgtt->num_pd_entries; i++) {
+ gen6_gtt_pte_t *pt_vaddr;
+ dma_addr_t pt_addr = ppgtt->pt_dma_addr[i];
+ pd_entry = readl(pd_addr + i);
+
+ if (pd_entry != (u32)(GEN6_PDE_ADDR_ENCODE(pt_addr) |
GEN6_PDE_VALID))
+ DRM_ERROR("Actual PDE: %x Expected PDE: %x",
+ pd_entry,
+ (u32)(GEN6_PDE_ADDR_ENCODE(pt_addr) |
GEN6_PDE_VALID));
+
+ pt_vaddr = kmap_atomic(ppgtt->pt_pages[i]);
+ for (j = 0; j < I915_PPGTT_PT_ENTRIES; j++) {
+ gen6_gtt_pte_t scratch_pte =
+ ppgtt->base.pte_encode(ppgtt->base.scratch.addr,
+ I915_CACHE_LLC);
+ if (pt_vaddr[j] != scratch_pte)
+ DRM_ERROR("\tPTE = %x (%d %d)", pt_vaddr[j],
i,j);
+ }
+ kunmap_atomic(pt_vaddr);
+ }
+}
static void gen6_write_pdes(struct i915_hw_ppgtt *ppgtt)
{
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: tune down DIDL warning about too many outputs
Nothing the user (nor we) really can do about this, but upsets a nice
quiet boot.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_opregion.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 79be7cf..cfb8fb6 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -311,8 +311,8 @@ static void intel_didl_outputs(struct drm_device *dev)
list_for_each_entry(acpi_cdev, &acpi_video_bus->children, node) {
if (i >= 8) {
- dev_printk(KERN_ERR, &dev->pdev->dev,
- "More than 8 outputs detected via ACPI\n");
+ dev_dbg(&dev->pdev->dev,
+ "More than 8 outputs detected via ACPI\n");
return;
}
status =
@@ -338,8 +338,8 @@ blind_set:
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
int output_type = ACPI_OTHER_OUTPUT;
if (i >= 8) {
- dev_printk(KERN_ERR, &dev->pdev->dev,
- "More than 8 outputs in connector list\n");
+ dev_dbg(&dev->pdev->dev,
+ "More than 8 outputs in connector list\n");
return;
}
switch (connector->connector_type) {
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Broadcast RGB questions
I don't suppose there is a way to set the default value for this property with a kernel boot option is there? I keep thinking my monitor is broken or my eyes have gone bad while watching the boot messages scroll past :-). (Anyone feel like adding such a kernel option?) If I can't get it set that early, does anyone have a working example of the sort of xorg.conf fragment I can stick in /etc/X11/xorg.conf.d/ to set it as soon as X comes up on my system? (The docs for xorg.conf seem to have been designed to cause brains to explode when trying to understand them). I am able to set it with xrandr but it makes my monitor flicker when it changes (I thought avoiding that sort of thing was why kernel mode setting was invented :-). ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Make intel_enable_fbc() static
This function has no user outside of intel_pm.c.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ffe9d35..a165be6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -779,7 +779,6 @@ extern int intel_sprite_get_colorkey(struct drm_device
*dev, void *data,
extern void intel_init_pm(struct drm_device *dev);
/* FBC */
extern bool intel_fbc_enabled(struct drm_device *dev);
-extern void intel_enable_fbc(struct drm_crtc *crtc, unsigned long interval);
extern void intel_update_fbc(struct drm_device *dev);
/* IPS */
extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b27bda0..a8483f5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -368,7 +368,7 @@ static void intel_cancel_fbc_work(struct drm_i915_private
*dev_priv)
dev_priv->fbc_work = NULL;
}
-void intel_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+static void intel_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
{
struct intel_fbc_work *work;
struct drm_device *dev = crtc->dev;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Fix reason for per-chip disabling of FBC
When running on my snb machine, recent kernels display successively:
[drm:intel_update_fbc], fbc set to per-chip default
[drm:intel_update_fbc], fbc disabled per module param
But no module param is set. This happens because the check for the
module parameter uses a variable that has been overridden inside the
"per-chip default" code.
Fix up the logic and add another reason for the FBC to the be disabled.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 14 ++
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d4e78b6..4dcaee3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1469,6 +1469,9 @@ static int i915_fbc_status(struct seq_file *m, void
*unused)
case FBC_MODULE_PARAM:
seq_printf(m, "disabled per module param (default
off)");
break;
+ case FBC_CHIP_DEFAULT:
+ seq_printf(m, "disabled per chip default");
+ break;
default:
seq_printf(m, "unknown reason");
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10a56c9..2b8b7ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -543,6 +543,7 @@ enum no_fbc_reason {
FBC_NOT_TILED, /* buffer not tiled */
FBC_MULTIPLE_PIPES, /* more than one pipe active */
FBC_MODULE_PARAM,
+ FBC_CHIP_DEFAULT, /* disabled by default on this chip */
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a8483f5..fd70a82 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -448,7 +448,6 @@ void intel_update_fbc(struct drm_device *dev)
struct drm_framebuffer *fb;
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
- int enable_fbc;
unsigned int max_hdisplay, max_vdisplay;
if (!i915_powersave)
@@ -489,14 +488,13 @@ void intel_update_fbc(struct drm_device *dev)
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;
- enable_fbc = i915_enable_fbc;
- if (enable_fbc < 0) {
- DRM_DEBUG_KMS("fbc set to per-chip default\n");
- enable_fbc = 1;
- if (INTEL_INFO(dev)->gen <= 7 && !IS_HASWELL(dev))
- enable_fbc = 0;
+ if (i915_enable_fbc < 0 &&
+ INTEL_INFO(dev)->gen <= 7 && !IS_HASWELL(dev)) {
+ DRM_DEBUG_KMS("disabled per chip default\n");
+ dev_priv->no_fbc_reason = FBC_CHIP_DEFAULT;
+ goto out_disable;
}
- if (!enable_fbc) {
+ if (!i915_enable_fbc) {
DRM_DEBUG_KMS("fbc disabled per module param\n");
dev_priv->no_fbc_reason = FBC_MODULE_PARAM;
goto out_disable;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Small FBC fix
I noticed on pre-HSW machines we get a spurious debug message: [drm:intel_update_fbc], fbc set to per-chip default [drm:intel_update_fbc], fbc disabled per module param but the fbc module parameter is not set. This series fixes it up. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Detect invalid scanout pitches
On Thu, Jun 20, 2013 at 05:14:20PM +0100, Chris Wilson wrote:
> Report back the user error of attempting to setup a CRTC with an invalid
> framebuffer pitch. This is trickier than it should be as on gen4, there
> is a restriction that tiled surfaces must have a stride less than 16k -
> which is less than the largest supported CRTC size.
>
> v2: Fix the limits for gen3
> v3: Move check into intel_framebuffer_init() and fix VLV limits. (vsyrjala)
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=65099
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 03a5ed0..ed84c57 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9223,6 +9223,7 @@ int intel_framebuffer_init(struct drm_device *dev,
> struct drm_mode_fb_cmd2 *mode_cmd,
> struct drm_i915_gem_object *obj)
> {
> + int pitch_limit;
> int ret;
>
> if (obj->tiling_mode == I915_TILING_Y) {
> @@ -9236,10 +9237,26 @@ int intel_framebuffer_init(struct drm_device *dev,
> return -EINVAL;
> }
>
> - /* FIXME <= Gen4 stride limits are bit unclear */
> - if (mode_cmd->pitches[0] > 32768) {
> - DRM_DEBUG("pitch (%d) must be at less than 32768\n",
> - mode_cmd->pitches[0]);
> + if (INTEL_INFO(dev)->gen > 4 && !IS_VALLEYVIEW(dev)) {
I believe Daniel wants to use >= for such gen checks, and I tend to
agree that it would make things a bit easier to parse.
> + pitch_limit = 32*1024;
> + } else if (INTEL_INFO(dev)->gen > 3) {
> + if (obj->tiling_mode)
> + pitch_limit = 16*1024;
> + else
> + pitch_limit = 32*1024;
> + } else if (INTEL_INFO(dev)->gen > 2) {
> + if (obj->tiling_mode)
> + pitch_limit = 8*1024;
> + else
> + pitch_limit = 16*1024;
> + } else
> + /* XXX DSPC is limited to 4k tiled */
> + pitch_limit = 8*1024;
> +
> + if (mode_cmd->pitches[0] > pitch_limit) {
> + DRM_DEBUG("%s pitch (%d) must be at less than %d\n",
> + obj->tiling_mode ? "tiled" : "linear",
> + mode_cmd->pitches[0], pitch_limit);
> return -EINVAL;
> }
>
> --
> 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 21/31] drm/i915: consolidate pch pll enable sequence
On Wed, Jun 05, 2013 at 01:34:23PM +0200, Daniel Vetter wrote:
> It's been splattered over 3 different places all doing random things.
> Now we have (mostly) the same sequence as i8xx/i9xx, but all called
> from the crtc_enable hook (through the pll->enable function):
> - write new dividers
> - enable vco and wait for stable clocks
> - write again for the pixel mutliplier
>
> I've left the seemingly random 200 usec delay in there, just in case.
>
> Also move the encoder->pre_pll_enable hook into the crtc_enable
> function, at the same spot we currently have a hack to enable the lvds
> port. Since that hack is now redundant, kill it.
>
> While doing this patch I've learned the hard way that we can only fire
> up the LVDS port if both the pch dpll _and_ the fdi rc pll are not yet
> enabled. Otherwise things go haywire, at least on cpt.
>
> v2: It is paramount to write the FPx divisors before we enable the
> the vco by writing to the DPLL registers, for otherwise the divisors
> won't get updated. This is in line with the i8xx/i9xx dpll.
>
> v3: To keep the nice abstraction add a ->mode_set callback to set the
> divisors. Also streamline the enabling/disabling code a bit by
> removing some cargo-cult duplication and clearing registers where
> possible in the ->disable hook.
>
> v4: Remove now unused local variable.
>
> Signed-off-by: Daniel Vetter
For some reason my brain refuses to work on this patch. I say, let's
test it in the wild instead.
Acked-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_display.c | 75
> +---
> 2 files changed, 29 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4dc94ed..9fc1ea4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -157,6 +157,8 @@ struct intel_shared_dpll {
> /* should match the index in the dev_priv->shared_dplls array */
> enum intel_dpll_id id;
> struct intel_dpll_hw_state hw_state;
> + void (*mode_set)(struct drm_i915_private *dev_priv,
> + struct intel_shared_dpll *pll);
> void (*enable)(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll);
> void (*disable)(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fc1b5f7..334f86a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3064,13 +3064,7 @@ found:
> WARN_ON(pll->on);
> assert_shared_dpll_disabled(dev_priv, pll);
>
> - /* Wait for the clocks to stabilize before rewriting the regs */
> - I915_WRITE(PCH_DPLL(pll->id), dpll & ~DPLL_VCO_ENABLE);
> - POSTING_READ(PCH_DPLL(pll->id));
> - udelay(150);
> -
> - I915_WRITE(PCH_FP0(pll->id), fp);
> - I915_WRITE(PCH_DPLL(pll->id), dpll & ~DPLL_VCO_ENABLE);
> + pll->mode_set(dev_priv, pll);
> }
> pll->refcount++;
>
> @@ -3120,7 +3114,6 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
> struct intel_encoder *encoder;
> int pipe = intel_crtc->pipe;
> int plane = intel_crtc->plane;
> - u32 temp;
>
> WARN_ON(!crtc->enabled);
>
> @@ -3134,12 +3127,9 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
>
> intel_update_watermarks(dev);
>
> - if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
> - temp = I915_READ(PCH_LVDS);
> - if ((temp & LVDS_PORT_EN) == 0)
> - I915_WRITE(PCH_LVDS, temp | LVDS_PORT_EN);
> - }
> -
> + for_each_encoder_on_crtc(dev, crtc, encoder)
> + if (encoder->pre_pll_enable)
> + encoder->pre_pll_enable(encoder);
>
> if (intel_crtc->config.has_pch_encoder) {
> /* Note: FDI PLL enabling _must_ be done before we enable the
> @@ -5682,10 +5672,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc
> *crtc,
> if (intel_crtc->config.has_dp_encoder)
> intel_dp_set_m_n(intel_crtc);
>
> - for_each_encoder_on_crtc(dev, crtc, encoder)
> - if (encoder->pre_pll_enable)
> - encoder->pre_pll_enable(encoder);
> -
> if (is_lvds && has_reduced_clock && i915_powersave)
> intel_crtc->lowfreq_avail = true;
> else
> @@ -5694,23 +5680,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc
> *crtc,
> if (intel_crtc->config.has_pch_encoder) {
> pll = intel_crtc_to_shared_dpll(intel_crtc);
>
> - I915_WRITE(PCH_DPLL(pll->id), dpll);
> -
> - /* Wait for the clocks to stabilize. */
> - POSTING_READ(PCH_DPLL(pll->id));
> - udelay(150);
> -
> - /* The pixel multiplier can only be updated o
[Intel-gfx] [PATCH] drm/i915: Bail out once we've found the context object
Once we've found the the context object programmed in CCID, there's no
need to look the other objects in the list.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7857430..e0f42c8 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1801,6 +1801,7 @@ static void i915_gem_record_active_context(struct
intel_ring_buffer *ring,
if ((error->ccid & PAGE_MASK) == obj->gtt_offset) {
ering->ctx = i915_error_object_create_sized(dev_priv,
obj, 1);
+ break;
}
}
}
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, One remaining regression fix for i915. I've left it in -fixes for more than a week since it's in tricky code, and it took us a few kernel releases to notice the regression at all. The fence leak is especially annoying on gen2/3 and will kill userspace there quickly. For extra paranoia we've added a WARN in -next to catch this, things seem to be solid now. Cheers, Daniel The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-06-24 for you to fetch changes up to 19b2dbde5732170a03bd82cc8bd442cf88d856f7: drm/i915: Restore fences after resume and GPU resets (2013-06-16 01:10:45 +0200) Chris Wilson (1): drm/i915: Restore fences after resume and GPU resets drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/drm/i915/i915_gem.c | 22 +- drivers/gpu/drm/i915/i915_suspend.c |1 + 3 files changed, 8 insertions(+), 17 deletions(-) -- 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: Trim the i915_error_printf by the trailing '\0'
On Mon, Jun 24, 2013 at 03:26:54PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > It seems the request to vsnprintf will try to write to the byte past the
> > end of the maximum buffer, so trim the length by one byte.
> >
> > [76973.700434] BUG: unable to handle kernel paging request at
> > 1000
> > [76973.700468] IP: [] strnlen+0xd/0x40
> > [76973.700494] PGD 10387b067 PUD 15411a067 PMD 0
> > [76973.700515] Oops: [#1] SMP
> > [76973.700529] Modules linked in: cpufreq_userspace cpufreq_powersave
> > cpufreq_stats cpufreq_conservative binfmt_misc nfs lockd fscache sunrpc
> > coretemp crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64
> > ablk_helper cryptd lrw gf128mul glue_helper iTCO_wdt iTCO_vendor_support
> > microcode i2c_i801 lpc_ich mfd_core acpi_cpufreq mperf evdev processor ext4
> > crc16 jbd2 mbcache sd_mod crc_t10dif ahci libahci libata scsi_mod thermal
> > fan
> > [76973.700718] CPU: 2 PID: 13279 Comm: intel_error_dec Not tainted
> > 3.10.0-rc6+ #99
> > [76973.700746] Hardware name: Intel Corporation Shark Bay Client
> > platform/Flathead Creek Crb, BIOS HSWLPTU1.86C.0109.R03.1301282055
> > 01/28/2013
> > [76973.700793] task: 880153fa2100 ti: 88015231 task.ti:
> > 88015231
> > [76973.700820] RIP: 0010:[] []
> > strnlen+0xd/0x40
> > [76973.700849] RSP: 0018:880152311cb0 EFLAGS: 00010286
> > [76973.700869] RAX: 81774000 RBX: 88015472 RCX:
> > fffe
> > [76973.700895] RDX: 1000 RSI: RDI:
> > 1000
> > [76973.700920] RBP: 880152311cb0 R08: R09:
> >
> > [76973.700948] R10: R11: 000f R12:
> > 1000
> > [76973.700974] R13: 880154001000 R14: R15:
> >
> > [76973.701000] FS: 7f00fc942880() GS:88015e30()
> > knlGS:
> > [76973.701029] CS: 0010 DS: ES: CR0: 80050033
> > [76973.701050] CR2: 1000 CR3: 00015939a000 CR4:
> > 001407e0
> > [76973.701075] DR0: DR1: DR2:
> >
> > [76973.701103] DR3: DR6: fffe0ff0 DR7:
> > 0400
> > [76973.701128] Stack:
> > [76973.701136] 880152311ce8 811fdafb 88015472
> > 880154001000
> > [76973.701167] 880152311d58 817a703e 817a703e
> > 880152311d48
> > [76973.701198] 811fe8a9 000a 0001
> > 88015400
> > [76973.701229] Call Trace:
> > [76973.701242] [] string.isra.5+0x3b/0xf0
> > [76973.701264] [] vsnprintf+0x1d9/0x670
> > [76973.701286] [] i915_error_printf+0xb9/0x160
> > [76973.701311] [] print_error_buffers+0x18c/0x1e0
> > [76973.701335] [] i915_error_state_read+0x40e/0x8e0
> > [76973.701361] [] vfs_read+0x97/0x160
> > [76973.701381] [] SyS_read+0x44/0x90
> > [76973.701403] [] system_call_fastpath+0x16/0x1b
> > [76973.701424] Code: c0 01 80 38 00 75 f7 48 29 f8 5d c3 31 c0 5d c3 66 66
> > 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8d 4e ff 48 85 f6 48 89 e5 74 2a
> > <80> 3f 00 74 25 48 89 f8 31 d2 eb 10 0f 1f 80 00 00 00 00 48 83
> > [76973.701535] RIP [] strnlen+0xd/0x40
> > [76973.701550] RSP
> > [76973.701559] CR2: 1000
> >
> > Regression from commit edc3d8848dc9fe2a470316363dab8ef211d77e01
> > Author: Mika Kuoppala
> > Date: Thu May 23 13:55:35 2013 +0300
> >
> > drm/i915: avoid big kmallocs on reading error state
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index ec64f95..c436af9 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -653,7 +653,7 @@ static const char *purgeable_flag(int purgeable)
> > static void i915_error_vprintf(struct drm_i915_error_state_buf *e,
> >const char *f, va_list args)
> > {
> > - unsigned len;
> > + int len, rem;
> >
> > if (!e->err && WARN(e->bytes > (e->size - 1), "overflow")) {
> > e->err = -ENOSPC;
> > @@ -666,6 +666,11 @@ static void i915_error_vprintf(struct
> > drm_i915_error_state_buf *e,
> > /* Seek the first printf which is hits start position */
> > if (e->pos < e->start) {
> > len = vsnprintf(NULL, 0, f, args);
> > + if (len == -1) {
> > + e->err = -EIO;
> > + return;
> > + }
> > +
>
> -1 from vsnprintf would be broken vsnprintf. <0 would be better
> for paranoia.
Yeah, C99 says < 0 is failure, but the kernel's vsnprintf seems to never
return that.
>
> > if (e->pos + len <= e->start) {
> > e->pos += len;
> > retu
Re: [Intel-gfx] [PATCH] drm/i915: Trim the i915_error_printf by the trailing '\0'
Chris Wilson writes:
> It seems the request to vsnprintf will try to write to the byte past the
> end of the maximum buffer, so trim the length by one byte.
>
> [76973.700434] BUG: unable to handle kernel paging request at 1000
> [76973.700468] IP: [] strnlen+0xd/0x40
> [76973.700494] PGD 10387b067 PUD 15411a067 PMD 0
> [76973.700515] Oops: [#1] SMP
> [76973.700529] Modules linked in: cpufreq_userspace cpufreq_powersave
> cpufreq_stats cpufreq_conservative binfmt_misc nfs lockd fscache sunrpc
> coretemp crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper
> cryptd lrw gf128mul glue_helper iTCO_wdt iTCO_vendor_support microcode
> i2c_i801 lpc_ich mfd_core acpi_cpufreq mperf evdev processor ext4 crc16 jbd2
> mbcache sd_mod crc_t10dif ahci libahci libata scsi_mod thermal fan
> [76973.700718] CPU: 2 PID: 13279 Comm: intel_error_dec Not tainted
> 3.10.0-rc6+ #99
> [76973.700746] Hardware name: Intel Corporation Shark Bay Client
> platform/Flathead Creek Crb, BIOS HSWLPTU1.86C.0109.R03.1301282055 01/28/2013
> [76973.700793] task: 880153fa2100 ti: 88015231 task.ti:
> 88015231
> [76973.700820] RIP: 0010:[] []
> strnlen+0xd/0x40
> [76973.700849] RSP: 0018:880152311cb0 EFLAGS: 00010286
> [76973.700869] RAX: 81774000 RBX: 88015472 RCX:
> fffe
> [76973.700895] RDX: 1000 RSI: RDI:
> 1000
> [76973.700920] RBP: 880152311cb0 R08: R09:
>
> [76973.700948] R10: R11: 000f R12:
> 1000
> [76973.700974] R13: 880154001000 R14: R15:
>
> [76973.701000] FS: 7f00fc942880() GS:88015e30()
> knlGS:
> [76973.701029] CS: 0010 DS: ES: CR0: 80050033
> [76973.701050] CR2: 1000 CR3: 00015939a000 CR4:
> 001407e0
> [76973.701075] DR0: DR1: DR2:
>
> [76973.701103] DR3: DR6: fffe0ff0 DR7:
> 0400
> [76973.701128] Stack:
> [76973.701136] 880152311ce8 811fdafb 88015472
> 880154001000
> [76973.701167] 880152311d58 817a703e 817a703e
> 880152311d48
> [76973.701198] 811fe8a9 000a 0001
> 88015400
> [76973.701229] Call Trace:
> [76973.701242] [] string.isra.5+0x3b/0xf0
> [76973.701264] [] vsnprintf+0x1d9/0x670
> [76973.701286] [] i915_error_printf+0xb9/0x160
> [76973.701311] [] print_error_buffers+0x18c/0x1e0
> [76973.701335] [] i915_error_state_read+0x40e/0x8e0
> [76973.701361] [] vfs_read+0x97/0x160
> [76973.701381] [] SyS_read+0x44/0x90
> [76973.701403] [] system_call_fastpath+0x16/0x1b
> [76973.701424] Code: c0 01 80 38 00 75 f7 48 29 f8 5d c3 31 c0 5d c3 66 66 66
> 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8d 4e ff 48 85 f6 48 89 e5 74 2a <80>
> 3f 00 74 25 48 89 f8 31 d2 eb 10 0f 1f 80 00 00 00 00 48 83
> [76973.701535] RIP [] strnlen+0xd/0x40
> [76973.701550] RSP
> [76973.701559] CR2: 1000
>
> Regression from commit edc3d8848dc9fe2a470316363dab8ef211d77e01
> Author: Mika Kuoppala
> Date: Thu May 23 13:55:35 2013 +0300
>
> drm/i915: avoid big kmallocs on reading error state
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index ec64f95..c436af9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -653,7 +653,7 @@ static const char *purgeable_flag(int purgeable)
> static void i915_error_vprintf(struct drm_i915_error_state_buf *e,
> const char *f, va_list args)
> {
> - unsigned len;
> + int len, rem;
>
> if (!e->err && WARN(e->bytes > (e->size - 1), "overflow")) {
> e->err = -ENOSPC;
> @@ -666,6 +666,11 @@ static void i915_error_vprintf(struct
> drm_i915_error_state_buf *e,
> /* Seek the first printf which is hits start position */
> if (e->pos < e->start) {
> len = vsnprintf(NULL, 0, f, args);
> + if (len == -1) {
> + e->err = -EIO;
> + return;
> + }
> +
-1 from vsnprintf would be broken vsnprintf. <0 would be better
for paranoia.
> if (e->pos + len <= e->start) {
> e->pos += len;
> return;
> @@ -678,9 +683,14 @@ static void i915_error_vprintf(struct
> drm_i915_error_state_buf *e,
> }
> }
>
> - len = vsnprintf(e->buf + e->bytes, e->size - e->bytes, f, args);
> - if (len >= e->size - e->bytes)
> - len = e->size - e->bytes - 1;
The returned len excludes the trailing null. Len is adjusted to om
Re: [Intel-gfx] 'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system
On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote: > On Fri, 21 Jun 2013 23:58:08 -0700 > Guenter Roeck wrote: > > > Hi all, > > > > after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I > > started to > > see lots of "Timed out waiting for forcewake old ack to clear" error > > messages, > > including hang-ups especially if the system was highly loaded. With 3.5.24 > > everything was fine. > > > > After backing out commit 36ec8f877 (drm/i915: unconditionally use mt > > forcewake > > on hsw/ivb), everything is back to normal. The log message is still there, > > but > > only once during boot, and the system runs stable. > > > > CPU is "Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz", mainboard is Supermicro > > C7H61, BIOS version 2.00 dated 11/02/2012. Configuration file is whatever > > comes with Ubuntu; I'll be happy to provide a copy if anyone thinks it might > > help. > > > > Any idea what else I can do besides using a special kernel with the backed > > out > > commit ? Is it possible that others have the same problem ? > > Ouch, so a BIOS that uses the other forcewake mechanism seems to have > escaped. Is there a newer one available for your system? I'm hoping > it'll fix the issue, otherwise we may have to introduce both methods > for IVB again... > I installed the latest BIOS version (2.00b), but it did not fix the problem. Is there some info (such as an Intel document describing what needs to be done) which I could pass on to Supermicro ? I think it would be helpful if the condition was detected and reported, if that is possible. I spent two days so far tracking this down. It would be nice if others would not have to go through the same experience. Thanks, Guenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] PROBLEM: WARNING, plane B assertion failure
BIOS Information Vendor: Hewlett-Packard Version: 361A0 Ver. F.11 System Information Manufacturer: Hewlett-Packard Product Name: HP Mini Version: F.11 Wake-up Type: Power Switch SKU Number: FW376UA#ABA Family: 103C_5335KV 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03) (prog-if 0 0 [VGA controller]) Subsystem: Hewlett-Packard Company Device 361a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: i915 Kernel modules: i915 [3.243456] [ cut here ] [3.243541] WARNING: at drivers/gpu/drm/i915/intel_display.c:1274 intel_disable_pipe+0x146/0x150 [i915]() [3.243548] Hardware name: HP Mini [3.243554] plane B assertion failure, should be off on pipe B but is still active [3.243559] Modules linked in: cfg80211 hp_wmi(+) sparse_keymap iTCO_wdt iTCO_vendor_support rfkill uvcvideo coretemp videobuf2_vmalloc videobuf2_memops videobuf2_core microcode videodev usb_storage media snd_hda_intel(+) i915(+) evdev psmouse serio_raw pcspkr snd_hda_codec lpc_ich i2c_i801 of_i2c snd_hwdep drm_kms_helper wmi snd_pcm ssb snd_page_alloc mmc_core snd_timer drm snd pcmcia soundcore battery pcmcia_core acpi_cpufreq mperf sky2 video thermal ac intel_agp intel_gtt agpgart i2c_algo_bit i2c_core button processor ext4 crc16 mbcache jbd2 sd_mod ata_generic pata_acpi ata_piix libata ehci_pci uhci_hcd ehci_hcd scsi_mod usbcore usb_common [3.243695] Pid: 117, comm: systemd-udevd Not tainted 3.9.7-1-ARCH #1 [3.243701] Call Trace: [3.243721] [] warn_slowpath_common+0x6c/0xa0 [3.243788] [] ? intel_disable_pipe+0x146/0x150 [i915] [3.243854] [] ? intel_disable_pipe+0x146/0x150 [i915] [3.243867] [] warn_slowpath_fmt+0x33/0x40 [3.243933] [] intel_disable_pipe+0x146/0x150 [i915] [3.244000] [] i9xx_crtc_disable+0xec/0x1c0 [i915] [3.244233] [] intel_crtc_disable+0x2e/0x110 [i915] [3.244299] [] __intel_set_mode+0x242/0x880 [i915] [3.244316] [] ? mutex_unlock+0xd/0x10 [3.244347] [] ? drm_framebuffer_init+0x80/0x90 [drm] [3.244417] [] intel_set_mode+0x23/0x40 [i915] [3.244647] [] intel_get_load_detect_pipe+0x230/0x3a0 [i915] [3.244724] [] intel_modeset_setup_hw_state+0x714/0x8b0 [i915] [3.244796] [] intel_modeset_gem_init+0x20/0x30 [i915] [3.244852] [] i915_driver_load+0xa86/0xcb0 [i915] [3.245039] [] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] [3.245091] [] drm_get_pci_dev+0x13b/0x260 [drm] [3.245152] [] i915_pci_probe+0x3a/0x90 [i915] [3.245168] [] pci_device_probe+0x6f/0xb0 [3.245184] [] driver_probe_device+0x79/0x360 [3.245199] [] __driver_attach+0x71/0x80 [3.245211] [] ? __device_attach+0x40/0x40 [3.245223] [] bus_for_each_dev+0x47/0x80 [3.245236] [] driver_attach+0x1e/0x20 [3.245247] [] ? __device_attach+0x40/0x40 [3.245258] [] bus_add_driver+0x1df/0x2a0 [3.245402] [] ? pci_device_probe+0xb0/0xb0 [3.245417] [] ? pci_device_probe+0xb0/0xb0 [3.245429] [] driver_register+0x6a/0x130 [3.245444] [] __pci_register_driver+0x32/0x40 [3.245473] [] drm_pci_init+0xf5/0x100 [drm] [3.245504] [] ? 0xf8809fff [3.245568] [] i915_init+0x5e/0x60 [i915] [3.245581] [] do_one_initcall+0x10a/0x150 [3.245594] [] ? __blocking_notifier_call_chain+0x44/0x60 [3.245609] [] load_module+0x19a6/0x2340 [3.245627] [] sys_init_module+0x85/0xe0 [3.245641] [] sysenter_do_call+0x12/0x28 [3.245785] ---[ end trace 62583c49c20e738c ]--- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system
Hi all, after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started to see lots of "Timed out waiting for forcewake old ack to clear" error messages, including hang-ups especially if the system was highly loaded. With 3.5.24 everything was fine. After backing out commit 36ec8f877 (drm/i915: unconditionally use mt forcewake on hsw/ivb), everything is back to normal. The log message is still there, but only once during boot, and the system runs stable. CPU is "Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz", mainboard is Supermicro C7H61, BIOS version 2.00 dated 11/02/2012. Configuration file is whatever comes with Ubuntu; I'll be happy to provide a copy if anyone thinks it might help. Any idea what else I can do besides using a special kernel with the backed out commit ? Is it possible that others have the same problem ? Thanks, Guenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On dim., 2013-06-09 at 19:01 -0400, Matthew Garrett wrote:
> The first two patches in this series are picked from other patchesets aimed at
> solving similar problems. The last simply unregisters ACPI backlight control
> on Windows 8 systems when using an Intel GPU. Similar code could be added to
> other drivers, but I'm reluctant to do so without further investigation as
> to the behaviour of the vendor drivers under Windows.
Hi,
I've read this thread coming from
https://bugzilla.kernel.org/show_bug.cgi?id=51231 and tried the patches
on a Lenovo ThinkPad X230 with intel graphics.
The problem with thoses fixes is that they still introduce a regression
in how the brightness is handled, at least for me.
Before Linux support for acpi_osi("Windows 2012") (and when booting with
acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
just fine, whether in console, in the display manager or in my desktop
environment (Xfce). xfce4-power-manager just needs to be told that the
brightness keys are already handled and it doesn't need to do anything.
After Linux started responding to Win8 ACPI checks, it somehow broke,
but not completely. Brightness keys are not handled by the kernel
anymore (so no brightness adjustment in console or without a hotkey
daemon running). If I run xfce4-power-manager and tell it to handle the
brightness keys, it does work (although the number of brightness levels
is not completely right). That means both acpi_video0 and
intel_backlight backlight interfaces work, they just don't have the same
precision and max_brightness (more details on the bug).
When adding those three patches, well, acpi_video0 is removed (as
intended), but I still don't have brightness handling in the kernel and
need to have something handling it in userspace.
I really think this is a bad idea. In some cases it might be the only
solution, but having a place where this is set consistently would be
really best, imho. Every userspace daemon might do things differently,
and not everyone even has it. And I'm really not sure brightness keys
should be handled by a desktop environment anyway.
So can the previous behavior be actually restored? Maybe it was easier
to pass the brightness keys information from thinkpad_acpi.ko to
video.ko than it is to i915.ko but since it goes to the input layer
anyway I guess it could be fed to module handling that in a way or
another?
Please keep me on CC: on replies, I'm not subscribed to the various
lists.
Regards,
--
Yves-Alexis
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: Read the hardware state for the transcoder link upon error
On Fri, Jun 21, 2013 at 03:40:04PM +0100, Chris Wilson wrote:
> Do not trust our bookkeeping when reporting errors, and instead dump the
> register contents. In particular, this solves one particular issue when
> an error is reported before we finish setting up the outputs and have a
> complete mapping (i.e. during initialisation we set garbage state). If
> an error occurs at that early stage, it is vital that we get an accurate
> report of the hardware state and not conflated with our own inaccurate
> opinions.
>
> This fixes a panic for a large number of pre-Haswell machines that
> currently trigger an error during KMS takeover.
>
> Reported-by: Dustin King
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60021
> Signed-off-by: Chris Wilson
> Cc: sta...@vger.kernel.org
Shouldn't we just dump all transcoder registers on Haswell instead of
potentially fragile dances trying to reconstruct state?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 37
> ++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5988bda..7ce4588 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10273,12 +10273,43 @@ struct intel_display_error_state {
> } plane[I915_MAX_PIPES];
> };
>
> +static enum transcoder
> +read_cpu_transcoder(struct drm_i915_private *dev_priv, int pipe)
> +{
> + if (HAS_DDI(dev_priv->dev)) {
> + int edp_pipe;
> +
> + switch (I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP)) &
> (TRANS_DDI_FUNC_ENABLE | TRANS_DDI_EDP_INPUT_MASK)) {
> + default:
> + edp_pipe = -1;
> + break;
> +
> + case TRANS_DDI_EDP_INPUT_A_ONOFF | TRANS_DDI_FUNC_ENABLE:
> + case TRANS_DDI_EDP_INPUT_A_ON | TRANS_DDI_FUNC_ENABLE:
> + edp_pipe = PIPE_A;
> + break;
> +
> + case TRANS_DDI_EDP_INPUT_B_ONOFF | TRANS_DDI_FUNC_ENABLE:
> + edp_pipe = PIPE_B;
> + break;
> +
> + case TRANS_DDI_EDP_INPUT_C_ONOFF | TRANS_DDI_FUNC_ENABLE:
> + edp_pipe = PIPE_C;
> + break;
> + }
> +
> + if (edp_pipe == pipe)
> + pipe = TRANSCODER_EDP;
> + }
> +
> + return pipe;
> +}
> +
> struct intel_display_error_state *
> intel_display_capture_error_state(struct drm_device *dev)
> {
> drm_i915_private_t *dev_priv = dev->dev_private;
> struct intel_display_error_state *error;
> - enum transcoder cpu_transcoder;
> int i;
>
> error = kmalloc(sizeof(*error), GFP_ATOMIC);
> @@ -10289,7 +10320,9 @@ intel_display_capture_error_state(struct drm_device
> *dev)
> error->power_well_driver = I915_READ(HSW_PWR_WELL_DRIVER);
>
> for_each_pipe(i) {
> - cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, i);
> + enum transcoder cpu_transcoder;
> +
> + cpu_transcoder = read_cpu_transcoder(dev_priv, i);
> error->pipe[i].cpu_transcoder = cpu_transcoder;
>
> if (INTEL_INFO(dev)->gen <= 6 || IS_VALLEYVIEW(dev)) {
> --
> 1.8.3.1
>
> ___
> 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] drm/i915: move i915_trace_irq_get() out of the tracing macro
On Fri, Jun 21, 2013 at 02:51:07PM +0200, Sebastian Andrzej Siewior wrote: > On 06/21/2013 01:08 PM, Chris Wilson wrote: > > On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote: > >> There is a report on RT about "BUG: scheduling while atomic" because the > >> sleeping lock is taken in tracing context. This patch simply moves > >> locking operation out of the tracing macro. > > > > No. This enables the IRQ, as well as making a number of > > very expensively serialised read, unconditionally. > > Ach in case CONFIG_TRACING is enabled but the tracepoint itself is > disabled. In that case it is probably best to drop this tracepoint from > -RT. Iirc when we've last discussed this with Thomas Gleixner he mentioned that there's a setup/teardown hook when enabling/disabling a tracepoint. We could use that to enable/disable interrupts. Needs a notch of logic rework though since the auto-irq disable code needs adjusting ... And on a 2nd look that trace_irq_seqno logic looks a bit broken anyway. It's somewhere on my todo list, but patches very much welcome. -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] PROBLEM: WARNING, plane B assertion failure
Can you please boot with drm.debug=0xe added to your kernel bootline, reproduce the issue and the attach the complete dmesg? Thanks, Daniel On Mon, Jun 24, 2013 at 4:35 AM, brian porter wrote: > BIOS Information > Vendor: Hewlett-Packard > Version: 361A0 Ver. F.11 > System Information > Manufacturer: Hewlett-Packard > Product Name: HP Mini > Version: F.11 > Wake-up Type: Power Switch > SKU Number: FW376UA#ABA > Family: 103C_5335KV > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE > Express Integrated Graphics Controller (rev 03) (prog-if 0 > 0 [VGA controller]) > Subsystem: Hewlett-Packard Company Device 361a > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at fe98 (32-bit, non-prefetchable) [size=512K] > Region 1: I/O ports at dc80 [size=8] > Region 2: Memory at d000 (32-bit, prefetchable) [size=256M] > Region 3: Memory at fe94 (32-bit, non-prefetchable) [size=256K] > Expansion ROM at [disabled] > Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- > Address: Data: > Capabilities: [d0] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Kernel driver in use: i915 > Kernel modules: i915 > > > [3.243456] [ cut here ] > [3.243541] WARNING: at drivers/gpu/drm/i915/intel_display.c:1274 > intel_disable_pipe+0x146/0x150 [i915]() > [3.243548] Hardware name: HP Mini > [3.243554] plane B assertion failure, should be off on pipe B but > is still active > [3.243559] Modules linked in: cfg80211 hp_wmi(+) sparse_keymap > iTCO_wdt iTCO_vendor_support rfkill uvcvideo coretemp > videobuf2_vmalloc videobuf2_memops videobuf2_core microcode videodev > usb_storage media snd_hda_intel(+) i915(+) evdev psmouse serio_raw > pcspkr snd_hda_codec lpc_ich i2c_i801 of_i2c snd_hwdep drm_kms_helper > wmi snd_pcm ssb snd_page_alloc mmc_core snd_timer drm snd pcmcia > soundcore battery pcmcia_core acpi_cpufreq mperf sky2 video thermal ac > intel_agp intel_gtt agpgart i2c_algo_bit i2c_core button processor > ext4 crc16 mbcache jbd2 sd_mod ata_generic pata_acpi ata_piix libata > ehci_pci uhci_hcd ehci_hcd scsi_mod usbcore usb_common > [3.243695] Pid: 117, comm: systemd-udevd Not tainted 3.9.7-1-ARCH #1 > [3.243701] Call Trace: > [3.243721] [] warn_slowpath_common+0x6c/0xa0 > [3.243788] [] ? intel_disable_pipe+0x146/0x150 [i915] > [3.243854] [] ? intel_disable_pipe+0x146/0x150 [i915] > [3.243867] [] warn_slowpath_fmt+0x33/0x40 > [3.243933] [] intel_disable_pipe+0x146/0x150 [i915] > [3.244000] [] i9xx_crtc_disable+0xec/0x1c0 [i915] > [3.244233] [] intel_crtc_disable+0x2e/0x110 [i915] > [3.244299] [] __intel_set_mode+0x242/0x880 [i915] > [3.244316] [] ? mutex_unlock+0xd/0x10 > [3.244347] [] ? drm_framebuffer_init+0x80/0x90 [drm] > [3.244417] [] intel_set_mode+0x23/0x40 [i915] > [3.244647] [] intel_get_load_detect_pipe+0x230/0x3a0 [i915] > [3.244724] [] intel_modeset_setup_hw_state+0x714/0x8b0 [i915] > [3.244796] [] intel_modeset_gem_init+0x20/0x30 [i915] > [3.244852] [] i915_driver_load+0xa86/0xcb0 [i915] > [3.245039] [] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] > [3.245091] [] drm_get_pci_dev+0x13b/0x260 [drm] > [3.245152] [] i915_pci_probe+0x3a/0x90 [i915] > [3.245168] [] pci_device_probe+0x6f/0xb0 > [3.245184] [] driver_probe_device+0x79/0x360 > [3.245199] [] __driver_attach+0x71/0x80 > [3.245211] [] ? __device_attach+0x40/0x40 > [3.245223] [] bus_for_each_dev+0x47/0x80 > [3.245236] [] driver_attach+0x1e/0x20 > [3.245247] [] ? __device_attach+0x40/0x40 > [3.245258] [] bus_add_driver+0x1df/0x2a0 > [3.245402] [] ? pci_device_probe+0xb0/0xb0 > [3.245417] [] ? pci_device_probe+0xb0/0xb0 > [3.245429] [] driver_register+0x6a/0x130 > [3.245444] [] __pci_register_driver+0x32/0x40 > [3.245473] [] drm_pci_init+0xf5/0x100 [drm] > [3.245504] [] ? 0xf8809fff > [3.245568] [] i915_init+0x5e/0x60 [i915] > [3.245581] [] do_one_initcall+0x10a/0x150 > [3.245594] [] ? __blocking_notifier_call_chain+0x44/0x60 > [3.245609] [] load_module+0x19a6/0x2340 > [3.245627] [] sys_init_module+0x85/0xe0 > [3.245641] [] sysenter_do_call+0x12/0x28 > [3.245785] ---[ end trace 62583c49c20e738c ]--- -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Inte
