Re: [Intel-gfx] [PATCH] drm/i915: Handle sync_seqno correctly when seqno has wrapped.
On Mon, 19 Nov 2012 09:21:48 -0800, Ben Widawsky b...@bwidawsk.net wrote: On Mon, 19 Nov 2012 12:55:22 +0200 Mika Kuoppala mika.kuopp...@linux.intel.com wrote: On Tue, 13 Nov 2012 08:39:26 -0800, Ben Widawsky b...@bwidawsk.net wrote: Can you add another patch on top of this to have the starting seqno be a near pre-wrap value so we can catch bugs even without igt. I tried that but failed. I suspect that there is something in hw/sw that doesn't like if first seqno is 0x8000. Something in hw needs to initialized explicitly if seqno is not starting from 1? Nothing that I am aware of. If you have the first be 0, and then add a huge jump right after that, does it work? We can't jump more than 0x8000-1 as i915_seqno_passed() breaks. But with the patches for preallocate seqnos now in, I was able to get things working when first seqno was 0x. -Mika ___ 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: Include the last semaphore sync point in the error-state
On Tue, 27 Nov 2012 17:06:54 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Should be useful to know what the driver thought the other ring's seqno
was when it last used a semaphore.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |2 ++
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c52758c..5359f376 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -657,10 +657,12 @@ static void i915_ring_error_state(struct seq_file *m,
if (INTEL_INFO(dev)-gen = 6) {
seq_printf(m, RC PSMI: 0x%08x\n, error-rc_psmi[ring]);
seq_printf(m, FAULT_REG: 0x%08x\n, error-fault_reg[ring]);
- seq_printf(m, SYNC_0: 0x%08x\n,
-error-semaphore_mboxes[ring][0]);
- seq_printf(m, SYNC_1: 0x%08x\n,
-error-semaphore_mboxes[ring][1]);
+ seq_printf(m, SYNC_0: 0x%08x [last synced 0x%08x]\n,
+error-semaphore_mboxes[ring][0],
+error-semaphore_seqno[ring][0]);
+ seq_printf(m, SYNC_1: 0x%08x [last synced 0x%08x]\n,
+error-semaphore_mboxes[ring][1],
+error-semaphore_seqno[ring][1]);
}
seq_printf(m, seqno: 0x%08x\n, error-seqno[ring]);
seq_printf(m, waiting: %s\n, yesno(error-waiting[ring]));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 23afc21..476aa94 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -199,6 +199,7 @@ struct drm_i915_error_state {
u32 instdone[I915_NUM_RINGS];
u32 acthd[I915_NUM_RINGS];
u32 semaphore_mboxes[I915_NUM_RINGS][I915_NUM_RINGS - 1];
+ u32 semaphore_seqno[I915_NUM_RINGS][I915_NUM_RINGS - 1];
u32 rc_psmi[I915_NUM_RINGS]; /* sleep state */
/* our own tracking of ring head and tail */
u32 cpu_ring_head[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bfb6c51..1f40090 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1156,6 +1156,8 @@ static void i915_record_ring_state(struct drm_device
*dev,
= I915_READ(RING_SYNC_0(ring-mmio_base));
error-semaphore_mboxes[ring-id][1]
= I915_READ(RING_SYNC_1(ring-mmio_base));
+ error-semaphore_seqno[ring-id][0] = ring-sync_seqno[0];
+ error-semaphore_seqno[ring-id][1] = ring-sync_seqno[1];
}
if (INTEL_INFO(dev)-gen = 4) {
--
1.7.10.4
This patch was important for catching a seqno wrap problem in
i915_gem_object_sync().
Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
___
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: Include the last semaphore sync point in the error-state
On Thu, Nov 29, 2012 at 11:16:20AM +0200, Mika Kuoppala wrote:
On Tue, 27 Nov 2012 17:06:54 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Should be useful to know what the driver thought the other ring's seqno
was when it last used a semaphore.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |2 ++
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c52758c..5359f376 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -657,10 +657,12 @@ static void i915_ring_error_state(struct seq_file *m,
if (INTEL_INFO(dev)-gen = 6) {
seq_printf(m, RC PSMI: 0x%08x\n, error-rc_psmi[ring]);
seq_printf(m, FAULT_REG: 0x%08x\n, error-fault_reg[ring]);
- seq_printf(m, SYNC_0: 0x%08x\n,
- error-semaphore_mboxes[ring][0]);
- seq_printf(m, SYNC_1: 0x%08x\n,
- error-semaphore_mboxes[ring][1]);
+ seq_printf(m, SYNC_0: 0x%08x [last synced 0x%08x]\n,
+ error-semaphore_mboxes[ring][0],
+ error-semaphore_seqno[ring][0]);
+ seq_printf(m, SYNC_1: 0x%08x [last synced 0x%08x]\n,
+ error-semaphore_mboxes[ring][1],
+ error-semaphore_seqno[ring][1]);
}
seq_printf(m, seqno: 0x%08x\n, error-seqno[ring]);
seq_printf(m, waiting: %s\n, yesno(error-waiting[ring]));
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 23afc21..476aa94 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -199,6 +199,7 @@ struct drm_i915_error_state {
u32 instdone[I915_NUM_RINGS];
u32 acthd[I915_NUM_RINGS];
u32 semaphore_mboxes[I915_NUM_RINGS][I915_NUM_RINGS - 1];
+ u32 semaphore_seqno[I915_NUM_RINGS][I915_NUM_RINGS - 1];
u32 rc_psmi[I915_NUM_RINGS]; /* sleep state */
/* our own tracking of ring head and tail */
u32 cpu_ring_head[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index bfb6c51..1f40090 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1156,6 +1156,8 @@ static void i915_record_ring_state(struct drm_device
*dev,
= I915_READ(RING_SYNC_0(ring-mmio_base));
error-semaphore_mboxes[ring-id][1]
= I915_READ(RING_SYNC_1(ring-mmio_base));
+ error-semaphore_seqno[ring-id][0] = ring-sync_seqno[0];
+ error-semaphore_seqno[ring-id][1] = ring-sync_seqno[1];
}
if (INTEL_INFO(dev)-gen = 4) {
--
1.7.10.4
This patch was important for catching a seqno wrap problem in
i915_gem_object_sync().
Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
Applied both patches to dinq.
-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: Set sync_seqno properly after seqno wrap
On Wed, Nov 28, 2012 at 05:18:45PM +0200, Mika Kuoppala wrote: i915_gem_handle_seqno_wrap() will zero all sync_seqnos but as the wrap can happen inside ring-sync_to(), pre wrap seqno was carried over and overwrote the zeroed sync_seqno. When wrap is handled, all outstanding requests will be retired and objects moved to inactive queue, causing their last_read_seqno to be zero. Use this to update the sync_seqno correctly. RING_SYNC registers after wrap will contain pre wrap values which are = seqno. So injecting the semaphore wait into ring completes immediately. Original idea for using last_read_seqno from Chris Wilson. Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/17] drm/i915: add encoder-pre_pll_enable callback
On Tue, Nov 27, 2012 at 06:38:18PM -0200, Paulo Zanoni wrote: Hi 2012/11/26 Daniel Vetter daniel.vet...@ffwll.ch: Currently we have two encoder specific bits in the common mode_set functions: - lvds pin pair enabling - dp m/n setting and computation Now the lvds stuff needs to happen before the pll is enabled. Since that is done in the crtc_mode_set functions, we need to add a new callback to be able to move them to the encoder code (where they belong). The dp m/n stuff is a giant mess anyway (since it also confuses itself with the fdi link m/n handling), so that needs to be handled separately. I think that we can move the pll enabling down quite a bit, which might allow us to eventually merge encoder-pre_enable with this new pre_pll_enable callback. But for now this will allow us to clean things up a bit. Note that vlv doesn't support lvds, hence we don't need to change anything in there. My only worry is that in the future we might use the pre_pll_enable callback for some non-LVDS encoder, and then we'll forget about calling this on VLV. I really hope that we've cleaned things up by then and this pre_pll_enable hook is gone again. So merged as-is. -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 v2 1/4] drm/i915: Don't allow ring tail to reach the same cacheline as head
On Wed, Nov 28, 2012 at 09:45:46PM +0100, Daniel Vetter wrote: On Tue, Nov 27, 2012 at 08:34:55PM +0200, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com From BSpec: If the Ring Buffer Head Pointer and the Tail Pointer are on the same cacheline, the Head Pointer must not be greater than the Tail Pointer. The easiest way to enforce this is to reduce the reported ring space. References: Gen2 BSpec 1. Programming Environment / 1.4.4.6 Ring Buffer Use Gen3 BSpec vol1c Memory Interface Functions / 2.3.4.5 Ring Buffer Use Gen4+ BSpec vol1c Memory Interface and Command Stream / 5.3.4.5 Ring Buffer Use v2: Include the exact BSpec references in the description Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Another small bikeshed for this one: Less magic numbers with #define RING_FREE_SPACE 64 Can do. And since the number will only appear in one place, I think I'll stick the BSpec references into a comment above it. -- 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 5/5] tests/flip_test: use subtest infrastructure
On Tue, 27 Nov 2012, Daniel Vetter daniel.vet...@ffwll.ch wrote:
To make the testnames easier to handle in scripts, replace all
spaces with dashes.
The important part is to not print anything to stdout when enumerating
subtests, so protect the timestamp test with the right check.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/Makefile.am | 2 +-
tests/flip_test.c | 51 ---
2 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index ff6e829..f4a3abb 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -13,6 +13,7 @@ NOUVEAU_TESTS = \
endif
TESTS_progs_M = \
+ flip_test \
$(NULL)
TESTS_progs = \
@@ -81,7 +82,6 @@ TESTS_progs = \
drm_vma_limiter_cached \
sysfs_rc6_residency \
sysfs_rps \
- flip_test \
gem_wait_render_timeout \
gem_ctx_create \
gem_ctx_bad_destroy \
diff --git a/tests/flip_test.c b/tests/flip_test.c
index 5214da9..5ad62d1 100644
--- a/tests/flip_test.c
+++ b/tests/flip_test.c
@@ -969,50 +969,55 @@ int main(int argc, char **argv)
int flags;
const char *name;
} tests[] = {
- { 15, TEST_VBLANK | TEST_CHECK_TS, wf-vblank },
+ { 15, TEST_VBLANK | TEST_CHECK_TS, wf_vblank },
{ 15, TEST_VBLANK | TEST_VBLANK_BLOCK | TEST_CHECK_TS,
- blocking wf-vblank },
+ blocking-wf_vblank },
The commit message says nothing about replacing dashes with
underscores. Seems to me it would be better to leave dashes as they are,
and replace spaces with underscores. Or replace all [^a-zA-Z0-9] with -.
BR,
Jani.
{ 5, TEST_VBLANK | TEST_VBLANK_ABSOLUTE,
- absolute wf-vblank },
+ absolute-wf_vblank },
{ 5, TEST_VBLANK | TEST_VBLANK_BLOCK | TEST_VBLANK_ABSOLUTE,
- blocking absolute wf-vblank },
- { 30, TEST_VBLANK | TEST_DPMS | TEST_EINVAL, wf-vblank vs
dpms },
+ blocking-absolute-wf_vblank },
+ { 30, TEST_VBLANK | TEST_DPMS | TEST_EINVAL,
wf_vblank-vs-dpms },
{ 30, TEST_VBLANK | TEST_DPMS | TEST_WITH_DUMMY_LOAD,
- delayed wf-vblank vs dpms },
- { 30, TEST_VBLANK | TEST_MODESET | TEST_EINVAL, wf-vblank vs
modeset },
+ delayed-wf_vblank-vs-dpms },
+ { 30, TEST_VBLANK | TEST_MODESET | TEST_EINVAL,
wf_vblank-vs-modeset },
{ 30, TEST_VBLANK | TEST_MODESET | TEST_WITH_DUMMY_LOAD,
- delayed wf-vblank vs modeset },
-
- { 15, TEST_FLIP | TEST_CHECK_TS | TEST_EBUSY , plain flip },
- { 30, TEST_FLIP | TEST_DPMS | TEST_EINVAL, flip vs dpms },
- { 30, TEST_FLIP | TEST_DPMS | TEST_WITH_DUMMY_LOAD, delayed
flip vs dpms },
- { 5, TEST_FLIP | TEST_PAN, flip vs panning },
- { 30, TEST_FLIP | TEST_PAN | TEST_WITH_DUMMY_LOAD, delayed
flip vs panning },
- { 30, TEST_FLIP | TEST_MODESET | TEST_EINVAL, flip vs modeset
},
- { 30, TEST_FLIP | TEST_MODESET | TEST_WITH_DUMMY_LOAD, delayed
flip vs modeset },
+ delayed-wf_vblank-vs-modeset },
+
+ { 15, TEST_FLIP | TEST_CHECK_TS | TEST_EBUSY , plain-flip },
+ { 30, TEST_FLIP | TEST_DPMS | TEST_EINVAL, flip-vs-dpms },
+ { 30, TEST_FLIP | TEST_DPMS | TEST_WITH_DUMMY_LOAD,
delayed-flip-vs-dpms },
+ { 5, TEST_FLIP | TEST_PAN, flip-vs-panning },
+ { 30, TEST_FLIP | TEST_PAN | TEST_WITH_DUMMY_LOAD,
delayed-flip-vs-panning },
+ { 30, TEST_FLIP | TEST_MODESET | TEST_EINVAL, flip-vs-modeset
},
+ { 30, TEST_FLIP | TEST_MODESET | TEST_WITH_DUMMY_LOAD,
delayed-flip-vs-modeset },
{ 5, TEST_FLIP | TEST_VBLANK_EXPIRED_SEQ,
- flip vs. expired vblank },
+ flip-vs-expired-vblank },
{ 15, TEST_FLIP | TEST_VBLANK | TEST_VBLANK_ABSOLUTE |
- TEST_CHECK_TS, flip vs absolute wf-vblank },
+ TEST_CHECK_TS, flip-vs-absolute-wf_vblank },
{ 15, TEST_FLIP | TEST_VBLANK | TEST_CHECK_TS,
- flip vs wf-vblank },
+ flip-vs-wf_vblank },
{ 15, TEST_FLIP | TEST_VBLANK | TEST_VBLANK_BLOCK |
- TEST_CHECK_TS, flip vs blocking wf-vblank },
+ TEST_CHECK_TS, flip-vs-blocking-wf-vblank },
};
int i;
+ drmtest_subtest_init(argc, argv);
+
drm_fd =
Re: [Intel-gfx] [PATCH 04/17] drm/i915: track is_dual_link in intel_lvds
On Tue, Nov 27, 2012 at 06:58:51PM -0200, Paulo Zanoni wrote: bikeshedding Here we could try to add some debug message telling whether we found dual-link LVDS or not. I don't know how useful it would be, but I added it to test your patches on my machine (I was not really sure whether it supported dual-link LVDS or not). Something like: + if (lvds_encoder-is_dual_link) +DRM_DEBUG_KMS(Dual link LVDS found\n); /bikeshedding Still, the patch looks correct, so with or without the debug message: Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com Excellent idea, I've slightly generalized the output so that it tells whether single or dual link has been detected. -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: Ensure that the wait ioctl return timeout is valid
On Wed, Nov 14, 2012 at 07:11:24PM +, Chris Wilson wrote: Due to a discrepancy between the sleep time and the amount of time we spend waiting inside the wait_event_timeout, it is possible that we end up computing that negative time remains in the wait_ioctl. This is obviously a bogus result to return to userspace, and triggers a WARN, so we need to fix up the value before propagating it back. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Ben Widawsky b...@bwidawsk.net Ben, can you pls take a look at this and smash an r-b on it if you're ok? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: reject modes the LPT FDI receiver can't handle
From: Paulo Zanoni paulo.r.zan...@intel.com
More specifically, the LPT FDI RX only supports 8bpc and a maximum of
2 lanes, so anything above that won't work and should be rejected.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_crt.c | 5 +
drivers/gpu/drm/i915/intel_display.c | 23 ++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 20 insertions(+), 9 deletions(-)
This one could go to 3.8 too.
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 5c77743..3084d01 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -198,6 +198,11 @@ static int intel_crt_mode_valid(struct drm_connector
*connector,
if (mode-clock max_clock)
return MODE_CLOCK_HIGH;
+ /* The FDI receiver on LPT only supports 8bpc and only has 2 lanes. */
+ if (HAS_PCH_LPT(dev)
+ (ironlake_get_lanes_required(mode-clock, 27, 24) 2))
+ return MODE_CLOCK_HIGH;
+
return MODE_OK;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 78d12c4..8d86a39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5228,6 +5228,17 @@ static bool ironlake_check_fdi_lanes(struct intel_crtc
*intel_crtc)
}
}
+int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp)
+{
+ /*
+* Account for spread spectrum to avoid
+* oversubscribing the link. Max center spread
+* is 2.5%; use 5% for safety's sake.
+*/
+ u32 bps = target_clock * bpp * 21 / 20;
+ return bps / (link_bw * 8) + 1;
+}
+
static void ironlake_set_m_n(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -5281,15 +5292,9 @@ static void ironlake_set_m_n(struct drm_crtc *crtc,
else
target_clock = adjusted_mode-clock;
- if (!lane) {
- /*
-* Account for spread spectrum to avoid
-* oversubscribing the link. Max center spread
-* is 2.5%; use 5% for safety's sake.
-*/
- u32 bps = target_clock * intel_crtc-bpp * 21 / 20;
- lane = bps / (link_bw * 8) + 1;
- }
+ if (!lane)
+ lane = ironlake_get_lanes_required(target_clock, link_bw,
+ intel_crtc-bpp);
intel_crtc-fdi_lanes = lane;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 522061c..a468a07 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -556,6 +556,7 @@ intel_pipe_to_cpu_transcoder(struct drm_i915_private
*dev_priv,
enum pipe pipe);
extern void intel_wait_for_vblank(struct drm_device *dev, int pipe);
extern void intel_wait_for_pipe_off(struct drm_device *dev, int pipe);
+extern int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp);
struct intel_load_detect_pipe {
struct drm_framebuffer *release_fb;
--
1.7.11.7
___
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 FDI lane calculation
From: Paulo Zanoni paulo.r.zan...@intel.com
The previous code was making the bps value 5% higher than what the
spec says, which was enough to make certain VGA modes require 3 lanes
instead of 2, which makes us reject these modes on Haswell since it
only has 2 FDI lanes. For previous gens this was not much of a
problem, since they had 4 lanes, and requiring more lanes than the
needed is ok, as long as you have all the lanes.
Notice that this might improve the case where we use pipes B and C on
Ivy Bridge since both pipes only have 4 lanes to share (see
ironlake_check_fdi_lanes).
Cc: Adam Jackson a...@redhat.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
As it is, this one will make the list of supported modes on Haswell VGA bigger,
so we could skip 3.8 and send this through 3.9, so we have plently of time to
get confident this won't break older platforms.
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d86a39..1825ae7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5231,12 +5231,10 @@ static bool ironlake_check_fdi_lanes(struct intel_crtc
*intel_crtc)
int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp)
{
/*
-* Account for spread spectrum to avoid
-* oversubscribing the link. Max center spread
-* is 2.5%; use 5% for safety's sake.
+* The spec says:
+* Number of lanes = INT(dot clock * bytes per pixel / ls_clk)
*/
- u32 bps = target_clock * bpp * 21 / 20;
- return bps / (link_bw * 8) + 1;
+ return DIV_ROUND_UP(target_clock * bpp, link_bw * 8);
}
static void ironlake_set_m_n(struct drm_crtc *crtc,
@@ -5296,6 +5294,8 @@ static void ironlake_set_m_n(struct drm_crtc *crtc,
lane = ironlake_get_lanes_required(target_clock, link_bw,
intel_crtc-bpp);
+ DRM_DEBUG_KMS(Using %d FDI lanes on pipe %c\n, lane,
+ pipe_name(intel_crtc-pipe));
intel_crtc-fdi_lanes = lane;
if (pixel_multiplier 1)
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: kill intel_dp_link_clock()
From: Paulo Zanoni paulo.r.zan...@intel.com
Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but
supports DP_LINK_BW_5_4 and is also used by the other drivers.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d76258d..841eaee 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -148,15 +148,6 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp)
return max_link_bw;
}
-static int
-intel_dp_link_clock(uint8_t link_bw)
-{
- if (link_bw == DP_LINK_BW_2_7)
- return 27;
- else
- return 162000;
-}
-
/*
* The units on the numbers in the next two are... bizarre. Examples will
* make it clearer; this one parallels an example in the eDP spec.
@@ -191,7 +182,8 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp,
struct drm_display_mode *mode,
bool adjust_mode)
{
- int max_link_clock =
intel_dp_link_clock(intel_dp_max_link_bw(intel_dp));
+ int max_link_clock =
+ drm_dp_bw_code_to_link_rate(intel_dp_max_link_bw(intel_dp));
int max_lanes = drm_dp_max_lane_count(intel_dp-dpcd);
int max_rate, mode_rate;
@@ -722,12 +714,15 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
for (clock = 0; clock = max_clock; clock++) {
for (lane_count = 1; lane_count = max_lane_count; lane_count
= 1) {
- int link_avail =
intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
+ int link_bw_clock =
+ drm_dp_bw_code_to_link_rate(bws[clock]);
+ int link_avail = intel_dp_max_data_rate(link_bw_clock,
+ lane_count);
if (mode_rate = link_avail) {
intel_dp-link_bw = bws[clock];
intel_dp-lane_count = lane_count;
- adjusted_mode-clock =
intel_dp_link_clock(intel_dp-link_bw);
+ adjusted_mode-clock = link_bw_clock;
DRM_DEBUG_KMS(DP link bw %02x lane
count %d clock %d bpp %d\n,
intel_dp-link_bw, intel_dp-lane_count,
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: intel_prepare_ddi_buffers should be static
On Thu, Nov 29, 2012 at 03:39:09PM +0200, Imre Deak wrote: On Fri, 2012-11-23 at 15:30 -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com It's not even declared on header files. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com On the series: Reviewed-by: Imre Deak imre.d...@intel.com Series queued for -next, thanks for the patchesreview. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kill intel_dp_link_clock()
On Thu, Nov 29, 2012 at 11:31:29AM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but supports DP_LINK_BW_5_4 and is also used by the other drivers. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Thanks for picking up the pieces after my refactoring ;-) Patch merged to dinq. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: fix FDI lane calculation
On Thu, 29 Nov 2012 11:29:33 -0200, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The previous code was making the bps value 5% higher than what the
spec says, which was enough to make certain VGA modes require 3 lanes
instead of 2, which makes us reject these modes on Haswell since it
only has 2 FDI lanes. For previous gens this was not much of a
problem, since they had 4 lanes, and requiring more lanes than the
needed is ok, as long as you have all the lanes.
Notice that this might improve the case where we use pipes B and C on
Ivy Bridge since both pipes only have 4 lanes to share (see
ironlake_check_fdi_lanes).
Cc: Adam Jackson a...@redhat.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
As it is, this one will make the list of supported modes on Haswell VGA
bigger,
so we could skip 3.8 and send this through 3.9, so we have plently of time to
get confident this won't break older platforms.
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d86a39..1825ae7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5231,12 +5231,10 @@ static bool ironlake_check_fdi_lanes(struct
intel_crtc *intel_crtc)
int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp)
{
/*
- * Account for spread spectrum to avoid
- * oversubscribing the link. Max center spread
- * is 2.5%; use 5% for safety's sake.
+ * The spec says:
+ * Number of lanes = INT(dot clock * bytes per pixel / ls_clk)
*/
- u32 bps = target_clock * bpp * 21 / 20;
- return bps / (link_bw * 8) + 1;
+ return DIV_ROUND_UP(target_clock * bpp, link_bw * 8);
Can you split this into two patches, one for using DIV_ROUND_UP and for
removingthe oversubscription, as the DIV_ROUND_UP looks to be a separate
issue worth testing. (Handling the case where bps % (link_bw * 8) == 0.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_set
Especially getting rid of all things lvds is ... great!
v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni.
v3:
- handle DP ports correctly (spoted by Paulo)
- don't leave {} behind for a single-line block (again spotted by
Paulo)
- kill another if (IBX || CPT) block
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 131 +--
1 file changed, 2 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3b6e4b0..fecaabc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5343,9 +5343,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
num_connectors++;
}
- WARN(!(HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)),
-Unexpected PCH type %d\n, INTEL_PCH_TYPE(dev));
-
ok = ironlake_compute_clocks(crtc, adjusted_mode, clock,
has_reduced_clock, reduced_clock);
if (!ok) {
@@ -5464,20 +5461,13 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
int pipe = intel_crtc-pipe;
int plane = intel_crtc-plane;
int num_connectors = 0;
- intel_clock_t clock, reduced_clock;
- u32 dpll = 0, fp = 0, fp2 = 0;
- bool ok, has_reduced_clock = false;
- bool is_lvds = false, is_dp = false, is_cpu_edp = false;
+ bool is_dp = false, is_cpu_edp = false;
struct intel_encoder *encoder;
- u32 temp;
int ret;
bool dither;
for_each_encoder_on_crtc(dev, crtc, encoder) {
switch (encoder-type) {
- case INTEL_OUTPUT_LVDS:
- is_lvds = true;
- break;
case INTEL_OUTPUT_DISPLAYPORT:
is_dp = true;
break;
@@ -5511,143 +5501,26 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
if (!intel_ddi_pll_mode_set(crtc, adjusted_mode-clock))
return -EINVAL;
- if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
- ok = ironlake_compute_clocks(crtc, adjusted_mode, clock,
-has_reduced_clock,
-reduced_clock);
- if (!ok) {
- DRM_ERROR(Couldn't find PLL settings for mode!\n);
- return -EINVAL;
- }
- }
-
/* Ensure that the cursor is valid for the new mode before changing...
*/
intel_crtc_update_cursor(crtc, true);
/* determine panel color depth */
dither = intel_choose_pipe_bpp_dither(crtc, fb, intel_crtc-bpp,
adjusted_mode);
- if (is_lvds dev_priv-lvds_dither)
- dither = true;
DRM_DEBUG_KMS(Mode for pipe %d:\n, pipe);
drm_mode_debug_printmodeline(mode);
- if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
- fp = clock.n 16 | clock.m1 8 | clock.m2;
- if (has_reduced_clock)
- fp2 = reduced_clock.n 16 | reduced_clock.m1 8 |
- reduced_clock.m2;
-
- dpll = ironlake_compute_dpll(intel_crtc, adjusted_mode, clock,
-fp);
-
- /* CPU eDP is the only output that doesn't need a PCH PLL of its
-* own on pre-Haswell/LPT generation */
- if (!is_cpu_edp) {
- struct intel_pch_pll *pll;
-
- pll = intel_get_pch_pll(intel_crtc, dpll, fp);
- if (pll == NULL) {
- DRM_DEBUG_DRIVER(failed to find PLL for pipe
%d\n,
-pipe);
- return -EINVAL;
- }
- } else
- intel_put_pch_pll(intel_crtc);
-
- /* The LVDS pin pair needs to be on before the DPLLs are
-* enabled. This is an exception to the general rule that
-* mode_set doesn't turn things on.
-*/
- if (is_lvds) {
- temp = I915_READ(PCH_LVDS);
- temp |= LVDS_PORT_EN | LVDS_A0A2_CLKA_POWER_UP;
- if (HAS_PCH_CPT(dev)) {
- temp = ~PORT_TRANS_SEL_MASK;
- temp |= PORT_TRANS_SEL_CPT(pipe);
- } else {
- if (pipe == 1)
- temp |= LVDS_PIPEB_SELECT;
- else
- temp = ~LVDS_PIPEB_SELECT;
- }
-
- /* set the corresponsding LVDS_BORDER bit */
- temp |=
[Intel-gfx] [PATCH 02/10] drm/i915: move set_pll_edp to intel_dp.c
Now that we enable the cpu edp pll in intel_dp-pre_enable and no
longer in crtc_mode_set, we can also move the modeset part to the
intel_dp-mode_set callback. Previously this was not possible because
the encoder -mode_set callbacks are called after the crtc mode set
callback.
v2: Rebase on top of copypasted hsw crtc_mode_set.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 40
drivers/gpu/drm/i915/intel_dp.c | 40
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fecaabc..0c44421 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2293,43 +2293,6 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return 0;
}
-static void ironlake_set_pll_edp(struct drm_crtc *crtc, int clock)
-{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- u32 dpa_ctl;
-
- DRM_DEBUG_KMS(eDP PLL enable for clock %d\n, clock);
- dpa_ctl = I915_READ(DP_A);
- dpa_ctl = ~DP_PLL_FREQ_MASK;
-
- if (clock 20) {
- u32 temp;
- dpa_ctl |= DP_PLL_FREQ_160MHZ;
- /* workaround for 160Mhz:
- 1) program 0x4600c bits 15:0 = 0x8124
- 2) program 0x46010 bit 0 = 1
- 3) program 0x46034 bit 24 = 1
- 4) program 0x64000 bit 14 = 1
- */
- temp = I915_READ(0x4600c);
- temp = 0x;
- I915_WRITE(0x4600c, temp | 0x8124);
-
- temp = I915_READ(0x46010);
- I915_WRITE(0x46010, temp | 1);
-
- temp = I915_READ(0x46034);
- I915_WRITE(0x46034, temp | (1 24));
- } else {
- dpa_ctl |= DP_PLL_FREQ_270MHZ;
- }
- I915_WRITE(DP_A, dpa_ctl);
-
- POSTING_READ(DP_A);
- udelay(500);
-}
-
static void intel_fdi_normal_train(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
@@ -5429,9 +5392,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
fdi_config_ok = ironlake_check_fdi_lanes(intel_crtc);
- if (is_cpu_edp)
- ironlake_set_pll_edp(crtc, adjusted_mode-clock);
-
ironlake_set_pipeconf(crtc, adjusted_mode, dither);
intel_wait_for_vblank(dev, pipe);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d76258d..dc019af 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -851,6 +851,43 @@ void intel_dp_init_link_config(struct intel_dp *intel_dp)
}
}
+static void ironlake_set_pll_edp(struct drm_crtc *crtc, int clock)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 dpa_ctl;
+
+ DRM_DEBUG_KMS(eDP PLL enable for clock %d\n, clock);
+ dpa_ctl = I915_READ(DP_A);
+ dpa_ctl = ~DP_PLL_FREQ_MASK;
+
+ if (clock 20) {
+ u32 temp;
+ dpa_ctl |= DP_PLL_FREQ_160MHZ;
+ /* workaround for 160Mhz:
+ 1) program 0x4600c bits 15:0 = 0x8124
+ 2) program 0x46010 bit 0 = 1
+ 3) program 0x46034 bit 24 = 1
+ 4) program 0x64000 bit 14 = 1
+ */
+ temp = I915_READ(0x4600c);
+ temp = 0x;
+ I915_WRITE(0x4600c, temp | 0x8124);
+
+ temp = I915_READ(0x46010);
+ I915_WRITE(0x46010, temp | 1);
+
+ temp = I915_READ(0x46034);
+ I915_WRITE(0x46034, temp | (1 24));
+ } else {
+ dpa_ctl |= DP_PLL_FREQ_270MHZ;
+ }
+ I915_WRITE(DP_A, dpa_ctl);
+
+ POSTING_READ(DP_A);
+ udelay(500);
+}
+
static void
intel_dp_mode_set(struct drm_encoder *encoder, struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -950,6 +987,9 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
drm_display_mode *mode,
} else {
intel_dp-DP |= DP_LINK_TRAIN_OFF_CPT;
}
+
+ if (is_cpu_edp(intel_dp))
+ ironlake_set_pll_edp(crtc, adjusted_mode-clock);
}
#define IDLE_ON_MASK (PP_ON | 0| PP_SEQUENCE_MASK | 0
| PP_SEQUENCE_STATE_MASK)
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: rip out pre-production ilk cpu edp w/a
While reading docs I've noticed that this special workaround to select
the 1.6 GHz DP clock only applies to pre-production ilk machines.
Since the registers we're touching here are rather undocumented and
might be harmful on later chips, rip it out.
For the Bspec reference of this w/a look in vol4g CPU Display
Registers [DevILK], Section 4.1.7.1 DP_A—DisplayPort A
Control Register, DP_PLL_Frequency_Select.
v2: Keep a debug message as a hint in case something regresses.
Requested by Chris Wilson.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_dp.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dc019af..ee03a45 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -862,26 +862,15 @@ static void ironlake_set_pll_edp(struct drm_crtc *crtc,
int clock)
dpa_ctl = ~DP_PLL_FREQ_MASK;
if (clock 20) {
- u32 temp;
+ /* For a long time we've carried around a ILK-DevA w/a for the
+* 160MHz clock. If we're really unlucky, it's still required.
+*/
+ DRM_DEBUG_KMS(160MHz cpu eDP clock, might need ilk devA
w/a\n);
dpa_ctl |= DP_PLL_FREQ_160MHZ;
- /* workaround for 160Mhz:
- 1) program 0x4600c bits 15:0 = 0x8124
- 2) program 0x46010 bit 0 = 1
- 3) program 0x46034 bit 24 = 1
- 4) program 0x64000 bit 14 = 1
- */
- temp = I915_READ(0x4600c);
- temp = 0x;
- I915_WRITE(0x4600c, temp | 0x8124);
-
- temp = I915_READ(0x46010);
- I915_WRITE(0x46010, temp | 1);
-
- temp = I915_READ(0x46034);
- I915_WRITE(0x46034, temp | (1 24));
} else {
dpa_ctl |= DP_PLL_FREQ_270MHZ;
}
+
I915_WRITE(DP_A, dpa_ctl);
POSTING_READ(DP_A);
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: use wait_for_vblank instead of msleep(17)
17 ms is eerily close to 60 Hz ^-1
Unfortunately this goes back to the original DP enabling for ilk, and
unfortunately does not come with a reason for it's existance attached.
Some closer inspection of the code and DP specs shows that we set the
idle link pattern before we disable the port. And it seems like that
the DP spec (or at least our hw) only switch to the idle pattern on
the next vblank. Hence a vblank wait at this spot makes _much_ more
sense than a really long wait.
v2: Rebase fixup.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ee03a45..b3754b0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1993,6 +1993,8 @@ intel_dp_link_down(struct intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc =
+ to_intel_crtc(intel_dig_port-base.base.crtc);
uint32_t DP = intel_dp-DP;
/*
@@ -2027,7 +2029,7 @@ intel_dp_link_down(struct intel_dp *intel_dp)
}
POSTING_READ(intel_dp-output_reg);
- msleep(17);
+ intel_wait_for_vblank(dev, intel_crtc-pipe);
if (HAS_PCH_IBX(dev)
I915_READ(intel_dp-output_reg) DP_PIPEB_SELECT) {
@@ -2059,7 +2061,7 @@ intel_dp_link_down(struct intel_dp *intel_dp)
POSTING_READ(intel_dp-output_reg);
msleep(50);
} else
- intel_wait_for_vblank(dev, to_intel_crtc(crtc)-pipe);
+ intel_wait_for_vblank(dev, intel_crtc-pipe);
}
DP = ~DP_AUDIO_OUTPUT_ENABLE;
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915: WARN on !crtc in intel_dp_link_down
This could have happened with the old crtc helper based modeset code,
but can't happen any longer with the new code.
Hence put in a WARN and adjust the comment. If no one hits this, we
can eventually remove it (like a few other such cases across our
code).
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_dp.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b3754b0..c308550 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2049,15 +2049,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
/* Changes to enable or select take place the vblank
* after being written.
*/
- if (crtc == NULL) {
- /* We can arrive here never having been attached
-* to a CRTC, for instance, due to inheriting
-* random state from the BIOS.
-*
-* If the pipe is not running, play safe and
-* wait for the clocks to stabilise before
-* continuing.
-*/
+ if (WARN_ON(crtc == NULL)) {
+ /* We should never try to disable a port without a crtc
+* attached. For paranoia keep the code around for a
+* bit. */
POSTING_READ(intel_dp-output_reg);
msleep(50);
} else
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915: drop unnecessary clearing of pch dp transcoder timings
This has originally been added in
commit 8db9d77b1b14fd730561f64beea8c00e4478d7c5
Author: Zhenyu Wang zhen...@linux.intel.com
Date: Wed Apr 7 16:15:54 2010 +0800
drm/i915: Support for Cougarpoint PCH display pipeline
probably to combat issues with hw state left behind by the BIOS. And
indeed, I've checked out that specific revision, and there is no DP
support yet. So the pch dp transcoder won't be correctly disabled, and
that's important since it requires a rether special disable dance:
Just writing 0 to TRANS_DP_CTL won't cut it, since we need to select
the NONE port when disabling, too.
And indeed, things seem to still work, so let's just remove this.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0c44421..456acd6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5345,15 +5345,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
} else
intel_put_pch_pll(intel_crtc);
- if (is_dp !is_cpu_edp) {
+ if (is_dp !is_cpu_edp)
intel_dp_set_m_n(crtc, mode, adjusted_mode);
- } else {
- /* For non-DP output, clear any trans DP clock recovery
setting.*/
- I915_WRITE(TRANSDATA_M1(pipe), 0);
- I915_WRITE(TRANSDATA_N1(pipe), 0);
- I915_WRITE(TRANSDPLINK_M1(pipe), 0);
- I915_WRITE(TRANSDPLINK_N1(pipe), 0);
- }
for_each_encoder_on_crtc(dev, crtc, encoder)
if (encoder-pre_pll_enable)
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: extract common link_m_n helpers
Both the dp and fdi code use the exact same computations (ignore minor
differences in conversion between bits and bytes).
This makes it even more apparent that we have a _massive_ mess between
cpu transcoder/fdi link/pch transcoder and pch link settings. And also
that we have hilarious amounts of confusion between edp and dp
(despite that they're identical at a link level).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 13
drivers/gpu/drm/i915/intel_display.c | 31 +---
drivers/gpu/drm/i915/intel_dp.c | 39 +++-
3 files changed, 26 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9be7efd..a98cff0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -101,6 +101,19 @@ struct intel_pch_pll {
};
#define I915_NUM_PLLS 2
+/* Used by dp and fdi links */
+struct intel_link_m_n {
+ uint32_ttu;
+ uint32_tgmch_m;
+ uint32_tgmch_n;
+ uint32_tlink_m;
+ uint32_tlink_n;
+};
+
+void intel_link_compute_m_n(int bpp, int nlanes,
+ int pixel_clock, int link_clock,
+ struct intel_link_m_n *m_n);
+
struct intel_ddi_plls {
int spll_refcount;
int wrpll1_refcount;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 456acd6..9e13636 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3954,16 +3954,8 @@ static int i830_get_display_clock_speed(struct
drm_device *dev)
return 133000;
}
-struct fdi_m_n {
- u32tu;
- u32gmch_m;
- u32gmch_n;
- u32link_m;
- u32link_n;
-};
-
static void
-fdi_reduce_ratio(u32 *num, u32 *den)
+intel_reduce_ratio(uint32_t *num, uint32_t *den)
{
while (*num 0xff || *den 0xff) {
*num = 1;
@@ -3971,20 +3963,18 @@ fdi_reduce_ratio(u32 *num, u32 *den)
}
}
-static void
-ironlake_compute_m_n(int bits_per_pixel, int nlanes, int pixel_clock,
-int link_clock, struct fdi_m_n *m_n)
+void
+intel_link_compute_m_n(int bits_per_pixel, int nlanes,
+ int pixel_clock, int link_clock,
+ struct intel_link_m_n *m_n)
{
- m_n-tu = 64; /* default size */
-
- /* BUG_ON(pixel_clock INT_MAX / 36); */
+ m_n-tu = 64;
m_n-gmch_m = bits_per_pixel * pixel_clock;
m_n-gmch_n = link_clock * nlanes * 8;
- fdi_reduce_ratio(m_n-gmch_m, m_n-gmch_n);
-
+ intel_reduce_ratio(m_n-gmch_m, m_n-gmch_n);
m_n-link_m = pixel_clock;
m_n-link_n = link_clock;
- fdi_reduce_ratio(m_n-link_m, m_n-link_n);
+ intel_reduce_ratio(m_n-link_m, m_n-link_n);
}
static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
@@ -5098,7 +5088,7 @@ static void ironlake_set_m_n(struct drm_crtc *crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum transcoder cpu_transcoder = intel_crtc-cpu_transcoder;
struct intel_encoder *intel_encoder, *edp_encoder = NULL;
- struct fdi_m_n m_n = {0};
+ struct intel_link_m_n m_n = {0};
int target_clock, pixel_multiplier, lane, link_bw;
bool is_dp = false, is_cpu_edp = false;
@@ -5156,8 +5146,7 @@ static void ironlake_set_m_n(struct drm_crtc *crtc,
if (pixel_multiplier 1)
link_bw *= pixel_multiplier;
- ironlake_compute_m_n(intel_crtc-bpp, lane, target_clock, link_bw,
-m_n);
+ intel_link_compute_m_n(intel_crtc-bpp, lane, target_clock, link_bw,
m_n);
I915_WRITE(PIPE_DATA_M1(cpu_transcoder), TU_SIZE(m_n.tu) | m_n.gmch_m);
I915_WRITE(PIPE_DATA_N1(cpu_transcoder), m_n.gmch_n);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c308550..c5bd555 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -742,39 +742,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
return false;
}
-struct intel_dp_m_n {
- uint32_ttu;
- uint32_tgmch_m;
- uint32_tgmch_n;
- uint32_tlink_m;
- uint32_tlink_n;
-};
-
-static void
-intel_reduce_ratio(uint32_t *num, uint32_t *den)
-{
- while (*num 0xff || *den 0xff) {
- *num = 1;
- *den = 1;
- }
-}
-
-static void
-intel_dp_compute_m_n(int bpp,
-int nlanes,
-int pixel_clock,
-int link_clock,
-struct intel_dp_m_n *m_n)
-{
- m_n-tu = 64;
- m_n-gmch_m = (pixel_clock * bpp) 3;
- m_n-gmch_n = link_clock * nlanes;
- intel_reduce_ratio(m_n-gmch_m, m_n-gmch_n);
-
[Intel-gfx] [PATCH 08/10] drm/i915: don't call update_watermark in crtc_mode_set
We already update watermarks at all the right places in the crtc_enable/disable callbacks. And since -mode_set doesn't change the active state, nothing will have changed ... v2: Rebase on top of latest haswell copypasta. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9e13636..bb42102 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4713,8 +4713,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, ret = intel_pipe_set_base(crtc, x, y, fb); - intel_update_watermarks(dev); - return ret; } @@ -5384,8 +5382,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc, ret = intel_pipe_set_base(crtc, x, y, fb); - intel_update_watermarks(dev); - intel_update_linetime_watermarks(dev, pipe, adjusted_mode); return fdi_config_ok ? ret : -EINVAL; @@ -5471,8 +5467,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc, ret = intel_pipe_set_base(crtc, x, y, fb); - intel_update_watermarks(dev); - intel_update_linetime_watermarks(dev, pipe, adjusted_mode); return ret; -- 1.7.11.7 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] drm/i915: don't call update_watermarks from haswell enable/disable code
We don't use these on haswell, since haswell as per-pipe watermarks and nothing global any more. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index bb42102..0a45d07 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3357,7 +3357,6 @@ static void haswell_crtc_enable(struct drm_crtc *crtc) return; intel_crtc-active = true; - intel_update_watermarks(dev); is_pch_port = haswell_crtc_driving_pch(crtc); @@ -3546,7 +3545,6 @@ static void haswell_crtc_disable(struct drm_crtc *crtc) } intel_crtc-active = false; - intel_update_watermarks(dev); mutex_lock(dev-struct_mutex); intel_update_fbc(dev); -- 1.7.11.7 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: rip out update_linetime_wm abstraction
I like abstraction and vfuncs, but only if they actually abstract anything.
In this case here they just obfuscate, so let's rip this stuff out.
Aside: We really should move all the haswell stuff into it's own file ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel_display.c | 31 +++---
drivers/gpu/drm/i915/intel_drv.h | 2 --
drivers/gpu/drm/i915/intel_pm.c | 37
4 files changed, 28 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a98cff0..ac52c75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -269,8 +269,6 @@ struct drm_i915_display_funcs {
void (*update_wm)(struct drm_device *dev);
void (*update_sprite_wm)(struct drm_device *dev, int pipe,
uint32_t sprite_width, int pixel_size);
- void (*update_linetime_wm)(struct drm_device *dev, int pipe,
-struct drm_display_mode *mode);
void (*modeset_global_resources)(struct drm_device *dev);
int (*crtc_mode_set)(struct drm_crtc *crtc,
struct drm_display_mode *mode,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0a45d07..0c7e88d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5380,11 +5380,36 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
ret = intel_pipe_set_base(crtc, x, y, fb);
- intel_update_linetime_watermarks(dev, pipe, adjusted_mode);
-
return fdi_config_ok ? ret : -EINVAL;
}
+static void
+haswell_update_linetime_wm(struct drm_device *dev, int pipe,
+struct drm_display_mode *mode)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 temp;
+
+ temp = I915_READ(PIPE_WM_LINETIME(pipe));
+ temp = ~PIPE_WM_LINETIME_MASK;
+
+ /* The WM are computed with base on how long it takes to fill a single
+* row at the given clock rate, multiplied by 8.
+* */
+ temp |= PIPE_WM_LINETIME_TIME(
+ ((mode-crtc_hdisplay * 1000) / mode-clock) * 8);
+
+ /* IPS watermarks are only used by pipe A, and are ignored by
+* pipes B and C. They are calculated similarly to the common
+* linetime values, except that we are using CD clock frequency
+* in MHz instead of pixel rate for the division.
+*
+* This is a placeholder for the IPS watermark calculation code.
+*/
+
+ I915_WRITE(PIPE_WM_LINETIME(pipe), temp);
+}
+
static int haswell_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
@@ -5465,7 +5490,7 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
ret = intel_pipe_set_base(crtc, x, y, fb);
- intel_update_linetime_watermarks(dev, pipe, adjusted_mode);
+ haswell_update_linetime_wm(dev, pipe, adjusted_mode);
return ret;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7ca7772..824efde 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -622,8 +622,6 @@ extern void intel_update_watermarks(struct drm_device *dev);
extern void intel_update_sprite_watermarks(struct drm_device *dev, int pipe,
uint32_t sprite_width,
int pixel_size);
-extern void intel_update_linetime_watermarks(struct drm_device *dev, int pipe,
-struct drm_display_mode *mode);
extern unsigned long intel_gen4_compute_offset_xtiled(int *x, int *y,
unsigned int bpp,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f595b8d..a487d15 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1890,33 +1890,6 @@ static void sandybridge_update_wm(struct drm_device *dev)
cursor_wm);
}
-static void
-haswell_update_linetime_wm(struct drm_device *dev, int pipe,
-struct drm_display_mode *mode)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- u32 temp;
-
- temp = I915_READ(PIPE_WM_LINETIME(pipe));
- temp = ~PIPE_WM_LINETIME_MASK;
-
- /* The WM are computed with base on how long it takes to fill a single
-* row at the given clock rate, multiplied by 8.
-* */
- temp |= PIPE_WM_LINETIME_TIME(
- ((mode-crtc_hdisplay * 1000) / mode-clock) * 8);
-
- /* IPS watermarks are only used by pipe A, and are ignored by
-* pipes B and C. They are calculated
[Intel-gfx] [PATCH] drm/i915: dynamic haswell display power well support
We can disable (almost) all the display hw if we only use pipe A, with
the integrated edp transcoder on port A. Because we don't set the cpu
transcoder that earyl (yet), we need to help us with a trick to simply
check for any edp encoders.
And wrt the old code: Can anyone explain what that struct mutex
grabbing was supposed to protect?
v2: Paulo Zanoni pointed out that we also need to configure the eDP
cpu transcoder correctly.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_ddi.c | 8 -
drivers/gpu/drm/i915/intel_display.c | 66 +---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 31 -
4 files changed, 68 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ad936c6..1a73a70 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -960,7 +960,13 @@ void intel_ddi_enable_pipe_func(struct drm_crtc *crtc)
if (cpu_transcoder == TRANSCODER_EDP) {
switch (pipe) {
case PIPE_A:
- temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
+ /* Can only use the always-on power well for eDP when
+* not using the panel fitter, and when not using motion
+* blur mitigation (which we don't support). */
+ if (dev_priv-pch_pf_size)
+ temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
+ else
+ temp |= TRANS_DDI_EDP_INPUT_A_ON;
break;
case PIPE_B:
temp |= TRANS_DDI_EDP_INPUT_B_ONOFF;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 52b6b0e..ea8e57c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5448,6 +5448,65 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
return fdi_config_ok ? ret : -EINVAL;
}
+/* Starting with Haswell, we have different power wells for
+ * different parts of the GPU. This attempts to enable them all.
+ */
+static void haswell_set_power_well(struct drm_device *dev,
+ bool enable)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long power_wells[] = {
+ HSW_PWR_WELL_CTL1,
+ HSW_PWR_WELL_CTL2,
+ HSW_PWR_WELL_CTL4
+ };
+ int i;
+
+ if (!IS_HASWELL(dev))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(power_wells); i++) {
+ int well = I915_READ(power_wells[i]);
+
+ if (enable) {
+ I915_WRITE(power_wells[i], well HSW_PWR_WELL_ENABLE);
+ if (wait_for(I915_READ(power_wells[i])
HSW_PWR_WELL_STATE, 20))
+ DRM_ERROR(Error enabling power well %lx\n,
power_wells[i]);
+ } else {
+ I915_WRITE(power_wells[i], well ~HSW_PWR_WELL_ENABLE);
+ if (wait_for((I915_READ(power_wells[i])
HSW_PWR_WELL_STATE) == 0, 20))
+ DRM_ERROR(Error disabling power well %lx\n,
power_wells[i]);
+ }
+ }
+}
+
+static void haswell_modeset_global_resources(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ bool enable = false;
+ struct intel_crtc *crtc;
+ struct intel_encoder *encoder;
+
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) {
+ if (crtc-pipe != PIPE_A crtc-base.enabled)
+ enable = true;
+ /* XXX: Should check for edp transcoder here, but thanks to init
+* sequence that's not yet availble. Just in case desktop eDP on
+* PORT D is possible on haswell, too. */
+ }
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list, base.head)
{
+ if (encoder-type != INTEL_OUTPUT_EDP)
+ enable = true;
+ }
+
+ /* Even the eDP panel fitter is outside the always-on well. */
+ if (dev_priv-pch_pf_size)
+ enable = true;
+
+ haswell_set_power_well(dev, enable);
+}
+
static int haswell_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
@@ -8421,6 +8480,8 @@ static void intel_init_display(struct drm_device *dev)
} else if (IS_HASWELL(dev)) {
dev_priv-display.fdi_link_train = hsw_fdi_link_train;
dev_priv-display.write_eld = haswell_write_eld;
+ dev_priv-display.modeset_global_resources =
+ haswell_modeset_global_resources;
Re: [Intel-gfx] [PATCH 3/3] drm/i915: fix FDI lane calculation
On 11/29/12 8:29 AM, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com The previous code was making the bps value 5% higher than what the spec says, which was enough to make certain VGA modes require 3 lanes instead of 2, which makes us reject these modes on Haswell since it only has 2 FDI lanes. For previous gens this was not much of a problem, since they had 4 lanes, and requiring more lanes than the needed is ok, as long as you have all the lanes. Notice that this might improve the case where we use pipes B and C on Ivy Bridge since both pipes only have 4 lanes to share (see ironlake_check_fdi_lanes). Fine with me. I'm not entirely sure the SS check I had there was necessary; I do remember the docs saying to account for it, but I'm not sure the check we had there was correct. Reviewed-by: Adam Jackson a...@redhat.com - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Ensure that the wait ioctl return timeout is valid
On Thu, 29 Nov 2012 13:42:17 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Nov 14, 2012 at 07:11:24PM +, Chris Wilson wrote: Due to a discrepancy between the sleep time and the amount of time we spend waiting inside the wait_event_timeout, it is possible that we end up computing that negative time remains in the wait_ioctl. This is obviously a bogus result to return to userspace, and triggers a WARN, so we need to fix up the value before propagating it back. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Ben Widawsky b...@bwidawsk.net Ben, can you pls take a look at this and smash an r-b on it if you're ok? Thanks, Daniel I want the real bug fixed! I do suspect it's a test bug, but I'd prefer not to slap an r-b on until I can pass the original problematic test. This just fixes an annoying WARN, which isn't super important to me because it's not a regression (since it existed since day 1), and no userspace really cares yet other than IGT. I did review the patch previously, and it looks fine. So, the r-b is pending. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: dynamic haswell display power well support
On Thu, 29 Nov 2012 16:19:54 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We can disable (almost) all the display hw if we only use pipe A, with
the integrated edp transcoder on port A. Because we don't set the cpu
transcoder that earyl (yet), we need to help us with a trick to simply
check for any edp encoders.
And wrt the old code: Can anyone explain what that struct mutex
grabbing was supposed to protect?
v2: Paulo Zanoni pointed out that we also need to configure the eDP
cpu transcoder correctly.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
/me waits for tested-by on this one... you may want to ping Joe, since
he's one of the few I know with a working edp panel + HSW atm. (Also,
maybe run this by Art)
Power numbers and how it was tested would also be cool.
---
drivers/gpu/drm/i915/intel_ddi.c | 8 -
drivers/gpu/drm/i915/intel_display.c | 66
+---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 31 - 4 files
changed, 68 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c index ad936c6..1a73a70 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -960,7 +960,13 @@ void intel_ddi_enable_pipe_func(struct drm_crtc
*crtc) if (cpu_transcoder == TRANSCODER_EDP) {
switch (pipe) {
case PIPE_A:
- temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
+ /* Can only use the always-on power well for
eDP when
+ * not using the panel fitter, and when not
using motion
+ * blur mitigation (which we don't support).
*/
+ if (dev_priv-pch_pf_size)
+ temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
+ else
+ temp |= TRANS_DDI_EDP_INPUT_A_ON;
break;
case PIPE_B:
temp |= TRANS_DDI_EDP_INPUT_B_ONOFF;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c index 52b6b0e..ea8e57c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5448,6 +5448,65 @@ static int ironlake_crtc_mode_set(struct
drm_crtc *crtc, return fdi_config_ok ? ret : -EINVAL;
}
+/* Starting with Haswell, we have different power wells for
+ * different parts of the GPU. This attempts to enable them all.
+ */
+static void haswell_set_power_well(struct drm_device *dev,
+bool enable)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long power_wells[] = {
+ HSW_PWR_WELL_CTL1,
+ HSW_PWR_WELL_CTL2,
+ HSW_PWR_WELL_CTL4
+ };
+ int i;
+
+ if (!IS_HASWELL(dev))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(power_wells); i++) {
+ int well = I915_READ(power_wells[i]);
+
+ if (enable) {
+ I915_WRITE(power_wells[i], well
HSW_PWR_WELL_ENABLE);
+ if (wait_for(I915_READ(power_wells[i])
HSW_PWR_WELL_STATE, 20))
+ DRM_ERROR(Error enabling power well
%lx\n, power_wells[i]);
+ } else {
+ I915_WRITE(power_wells[i], well
~HSW_PWR_WELL_ENABLE);
+ if (wait_for((I915_READ(power_wells[i])
HSW_PWR_WELL_STATE) == 0, 20))
+ DRM_ERROR(Error disabling power
well %lx\n, power_wells[i]);
+ }
+ }
+}
+
+static void haswell_modeset_global_resources(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ bool enable = false;
+ struct intel_crtc *crtc;
+ struct intel_encoder *encoder;
+
+ list_for_each_entry(crtc, dev-mode_config.crtc_list,
base.head) {
+ if (crtc-pipe != PIPE_A crtc-base.enabled)
+ enable = true;
+ /* XXX: Should check for edp transcoder here, but
thanks to init
+ * sequence that's not yet availble. Just in case
desktop eDP on
+ * PORT D is possible on haswell, too. */
+ }
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list,
base.head) {
+ if (encoder-type != INTEL_OUTPUT_EDP)
+ enable = true;
+ }
+
+ /* Even the eDP panel fitter is outside the always-on well.
*/
+ if (dev_priv-pch_pf_size)
+ enable = true;
+
+ haswell_set_power_well(dev, enable);
+}
+
static int haswell_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode
*adjusted_mode, @@ -8421,6 +8480,8 @@ static void
intel_init_display(struct drm_device *dev) } else if
(IS_HASWELL(dev)) {
[Intel-gfx] [PATCH 0/6] drivers: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com Turns out a few drivers have strayed away from using the spinlock_t typedef and decided to use struct spinlock directly. This series converts these drivers to use spinlock_t. Each change has been compile tested with allmodconfig and sparse checked. Driver developers may want to look at the compile error output / sparse error report supplied in each commit log, in particular brcmfmac and i915, there are quite a few things that are not related to this change that the developers can clean up / fix. Luis R. Rodriguez (6): ux500: convert struct spinlock to spinlock_t i915: convert struct spinlock to spinlock_t s5p-fimc: convert struct spinlock to spinlock_t s5p-jpeg: convert struct spinlock to spinlock_t brcmfmac: convert struct spinlock to spinlock_t ie6xx_wdt: convert struct spinlock to spinlock_t drivers/crypto/ux500/cryp/cryp.h |4 ++-- drivers/crypto/ux500/hash/hash_alg.h |4 ++-- drivers/gpu/drm/i915/i915_drv.h|4 ++-- drivers/media/platform/s5p-fimc/mipi-csis.c|2 +- drivers/media/platform/s5p-jpeg/jpeg-core.h|2 +- drivers/net/wireless/brcm80211/brcmfmac/fweh.h |2 +- drivers/watchdog/ie6xx_wdt.c |2 +- 7 files changed, 10 insertions(+), 10 deletions(-) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] ux500: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
I was unable to build test with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 M=drivers/crypto/ux500/
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
is missing; modules will have no dependencies and modversions.
LD drivers/crypto/ux500/built-in.o
Building modules, stage 2.
MODPOST 0 modules
Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
drivers/crypto/ux500/cryp/cryp.h |4 ++--
drivers/crypto/ux500/hash/hash_alg.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp.h b/drivers/crypto/ux500/cryp/cryp.h
index 14cfd05..ba324b2 100644
--- a/drivers/crypto/ux500/cryp/cryp.h
+++ b/drivers/crypto/ux500/cryp/cryp.h
@@ -236,12 +236,12 @@ struct cryp_device_data {
struct clk *clk;
struct regulator *pwr_regulator;
int power_status;
- struct spinlock ctx_lock;
+ spinlock_t ctx_lock;
struct cryp_ctx *current_ctx;
struct klist_node list_node;
struct cryp_dma dma;
bool power_state;
- struct spinlock power_state_spinlock;
+ spinlock_t power_state_spinlock;
bool restore_dev_ctx;
};
diff --git a/drivers/crypto/ux500/hash/hash_alg.h
b/drivers/crypto/ux500/hash/hash_alg.h
index cd9351c..0183f5e 100644
--- a/drivers/crypto/ux500/hash/hash_alg.h
+++ b/drivers/crypto/ux500/hash/hash_alg.h
@@ -363,10 +363,10 @@ struct hash_device_data {
struct hash_register __iomem*base;
struct klist_node list_node;
struct device *dev;
- struct spinlock ctx_lock;
+ spinlock_t ctx_lock;
struct hash_ctx *current_ctx;
boolpower_state;
- struct spinlock power_state_lock;
+ spinlock_t power_state_lock;
struct regulator*regulator;
struct clk *clk;
boolrestore_dev_state;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] i915: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com spinlock_t should always be used. LD drivers/gpu/drm/i915/built-in.o CHECK drivers/gpu/drm/i915/i915_drv.c CC [M] drivers/gpu/drm/i915/i915_drv.o CHECK drivers/gpu/drm/i915/i915_dma.c CC [M] drivers/gpu/drm/i915/i915_dma.o CHECK drivers/gpu/drm/i915/i915_irq.c CC [M] drivers/gpu/drm/i915/i915_irq.o CHECK drivers/gpu/drm/i915/i915_debugfs.c drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression CC [M] drivers/gpu/drm/i915/i915_debugfs.o CHECK drivers/gpu/drm/i915/i915_suspend.c CC [M] drivers/gpu/drm/i915/i915_suspend.o CHECK drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/i915_gem.c:3703:14:expected unsigned int [unsigned] [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3703:14:got restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: = drivers/gpu/drm/i915/i915_gem.c:3706:22:left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3706:22:right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |= drivers/gpu/drm/i915/i915_gem.c:3707:22:left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3707:22:right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types) drivers/gpu/drm/i915/i915_gem.c:3711:39:expected restricted gfp_t [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3711:39:got unsigned int [unsigned] [usertype] mask CC [M] drivers/gpu/drm/i915/i915_gem.o CHECK drivers/gpu/drm/i915/i915_gem_context.c CC [M] drivers/gpu/drm/i915/i915_gem_context.o CHECK drivers/gpu/drm/i915/i915_gem_debug.c CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CHECK drivers/gpu/drm/i915/i915_gem_evict.c CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CHECK drivers/gpu/drm/i915/i915_gem_execbuffer.c CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CHECK drivers/gpu/drm/i915/i915_gem_gtt.c CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CHECK drivers/gpu/drm/i915/i915_gem_stolen.c CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CHECK drivers/gpu/drm/i915/i915_gem_tiling.c CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CHECK drivers/gpu/drm/i915/i915_sysfs.c CC [M] drivers/gpu/drm/i915/i915_sysfs.o CHECK drivers/gpu/drm/i915/i915_trace_points.c CC [M] drivers/gpu/drm/i915/i915_trace_points.o CHECK drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:1736:9: int enum transcoder versus drivers/gpu/drm/i915/intel_display.c:1736:9: int enum pipe drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:3659:48: int enum pipe versus drivers/gpu/drm/i915/intel_display.c:3659:48: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_display.o CHECK drivers/gpu/drm/i915/intel_crt.c CC [M] drivers/gpu/drm/i915/intel_crt.o CHECK drivers/gpu/drm/i915/intel_lvds.c CC [M] drivers/gpu/drm/i915/intel_lvds.o CHECK drivers/gpu/drm/i915/intel_bios.c drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces) drivers/gpu/drm/i915/intel_bios.c:706:60:expected struct vbt_header *vbt drivers/gpu/drm/i915/intel_bios.c:706:60:got void [noderef] asn:2*vbt drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_bios.c:726:42:expected void const *noident drivers/gpu/drm/i915/intel_bios.c:726:42:got unsigned char [noderef] [usertype] asn:2* drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression CC [M] drivers/gpu/drm/i915/intel_bios.o CHECK drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static? drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum pipe versus drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_ddi.o drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’: drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used uninitialized in this
[Intel-gfx] [PATCH 3/6] s5p-fimc: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
Could not get this to build with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
M=drivers/media/platform/s5p-fimc/
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
is missing; modules will have no dependencies and modversions.
LD drivers/media/platform/s5p-fimc/built-in.o
Building modules, stage 2.
MODPOST 0 modules
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-me...@vger.kernel.org
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
drivers/media/platform/s5p-fimc/mipi-csis.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index 4c961b1..86c8775 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -187,7 +187,7 @@ struct csis_state {
const struct csis_pix_format *csis_fmt;
struct v4l2_mbus_framefmt format;
- struct spinlock slock;
+ spinlock_t slock;
struct csis_pktbuf pkt_buf;
struct s5pcsis_event events[S5PCSIS_NUM_EVENTS];
};
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] s5p-jpeg: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
Could not get this to build with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
M=drivers/media/platform/s5p-jpeg
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
is missing; modules will have no dependencies and modversions.
Building modules, stage 2.
MODPOST 0 modules
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-me...@vger.kernel.org
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h
b/drivers/media/platform/s5p-jpeg/jpeg-core.h
index 022b9b9..8a4013e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -62,7 +62,7 @@
*/
struct s5p_jpeg {
struct mutexlock;
- struct spinlock slock;
+ spinlock_t slock;
struct v4l2_device v4l2_dev;
struct video_device *vfd_encoder;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] brcmfmac: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com spinlock_t should always be used. LD drivers/net/wireless/brcm80211/built-in.o CHECK drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.o CHECK drivers/net/wireless/brcm80211/brcmfmac/fwil.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/fwil.o CHECK drivers/net/wireless/brcm80211/brcmfmac/fweh.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/fweh.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_common.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.o CHECK drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.o CHECK drivers/net/wireless/brcm80211/brcmfmac/usb.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/usb.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.o LD [M] drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.o LD drivers/net/wireless/brcm80211/brcmsmac/built-in.o CHECK drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1311:6: warning: context imbalance in 'brcms_down' - unexpected unlock drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1598:6: warning: context imbalance in 'brcms_rfkill_set_hw_state' - unexpected unlock CC [M] drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.o CHECK drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.o CHECK drivers/net/wireless/brcm80211/brcmsmac/ampdu.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/ampdu.o CHECK drivers/net/wireless/brcm80211/brcmsmac/antsel.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/antsel.o CHECK drivers/net/wireless/brcm80211/brcmsmac/channel.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/channel.o CHECK drivers/net/wireless/brcm80211/brcmsmac/main.c drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:36: warning: Initializer entry defined twice drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:43: also defined here CC [M] drivers/net/wireless/brcm80211/brcmsmac/main.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy_shim.o CHECK drivers/net/wireless/brcm80211/brcmsmac/pmu.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/pmu.o CHECK drivers/net/wireless/brcm80211/brcmsmac/rate.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/rate.o CHECK drivers/net/wireless/brcm80211/brcmsmac/stf.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/stf.o CHECK drivers/net/wireless/brcm80211/brcmsmac/aiutils.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/aiutils.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c:3313:46: warning: cast truncates bits from constant value (7fff becomes 7fff) CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:17688:47: warning: cast truncates bits from constant value (7fff becomes 7fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:18187:53: warning: cast truncates bits from constant value (3fff becomes 3fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:21160:36: warning: cast truncates bits from constant value (3fff becomes 3fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:23321:35: warning: cast truncates bits from constant value (7fff becomes 7fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:28343:44: warning: cast truncates bits from constant value (1fff becomes 1fff) CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.c CC [M]
[Intel-gfx] [PATCH 6/6] ie6xx_wdt: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
CHECK drivers/watchdog/ie6xx_wdt.c
CC [M] drivers/watchdog/ie6xx_wdt.o
Building modules, stage 2.
MODPOST 43 modules
LD [M] drivers/watchdog/ie6xx_wdt.ko
Cc: Alexander Stein alexander.st...@systec-electronic.com
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
drivers/watchdog/ie6xx_wdt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/ie6xx_wdt.c b/drivers/watchdog/ie6xx_wdt.c
index e24ef6a..f2d6573 100644
--- a/drivers/watchdog/ie6xx_wdt.c
+++ b/drivers/watchdog/ie6xx_wdt.c
@@ -82,7 +82,7 @@ MODULE_PARM_DESC(resetmode,
static struct {
unsigned short sch_wdtba;
- struct spinlock unlock_sequence;
+ spinlock_t unlock_sequence;
#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
#endif
--
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 2/6] i915: convert struct spinlock to spinlock_t
On Thu, Nov 29, 2012 at 12:45:06PM -0800, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@do-not-panic.com spinlock_t should always be used. LD drivers/gpu/drm/i915/built-in.o CHECK drivers/gpu/drm/i915/i915_drv.c CC [M] drivers/gpu/drm/i915/i915_drv.o CHECK drivers/gpu/drm/i915/i915_dma.c CC [M] drivers/gpu/drm/i915/i915_dma.o CHECK drivers/gpu/drm/i915/i915_irq.c CC [M] drivers/gpu/drm/i915/i915_irq.o CHECK drivers/gpu/drm/i915/i915_debugfs.c drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression CC [M] drivers/gpu/drm/i915/i915_debugfs.o CHECK drivers/gpu/drm/i915/i915_suspend.c CC [M] drivers/gpu/drm/i915/i915_suspend.o CHECK drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/i915_gem.c:3703:14:expected unsigned int [unsigned] [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3703:14:got restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: = drivers/gpu/drm/i915/i915_gem.c:3706:22:left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3706:22:right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |= drivers/gpu/drm/i915/i915_gem.c:3707:22:left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3707:22:right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types) drivers/gpu/drm/i915/i915_gem.c:3711:39:expected restricted gfp_t [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3711:39:got unsigned int [unsigned] [usertype] mask CC [M] drivers/gpu/drm/i915/i915_gem.o CHECK drivers/gpu/drm/i915/i915_gem_context.c CC [M] drivers/gpu/drm/i915/i915_gem_context.o CHECK drivers/gpu/drm/i915/i915_gem_debug.c CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CHECK drivers/gpu/drm/i915/i915_gem_evict.c CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CHECK drivers/gpu/drm/i915/i915_gem_execbuffer.c CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CHECK drivers/gpu/drm/i915/i915_gem_gtt.c CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CHECK drivers/gpu/drm/i915/i915_gem_stolen.c CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CHECK drivers/gpu/drm/i915/i915_gem_tiling.c CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CHECK drivers/gpu/drm/i915/i915_sysfs.c CC [M] drivers/gpu/drm/i915/i915_sysfs.o CHECK drivers/gpu/drm/i915/i915_trace_points.c CC [M] drivers/gpu/drm/i915/i915_trace_points.o CHECK drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:1736:9: int enum transcoder versus drivers/gpu/drm/i915/intel_display.c:1736:9: int enum pipe drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:3659:48: int enum pipe versus drivers/gpu/drm/i915/intel_display.c:3659:48: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_display.o CHECK drivers/gpu/drm/i915/intel_crt.c CC [M] drivers/gpu/drm/i915/intel_crt.o CHECK drivers/gpu/drm/i915/intel_lvds.c CC [M] drivers/gpu/drm/i915/intel_lvds.o CHECK drivers/gpu/drm/i915/intel_bios.c drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces) drivers/gpu/drm/i915/intel_bios.c:706:60:expected struct vbt_header *vbt drivers/gpu/drm/i915/intel_bios.c:706:60:got void [noderef] asn:2*vbt drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_bios.c:726:42:expected void const *noident drivers/gpu/drm/i915/intel_bios.c:726:42:got unsigned char [noderef] [usertype] asn:2* drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression CC [M] drivers/gpu/drm/i915/intel_bios.o CHECK drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static? drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum pipe versus drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_ddi.o
[Intel-gfx] [PATCH] drm/i915: fixup sparse warnings
- __iomem where there is none (I love how we mix these things up).
- Use gfp_t instead of an other plain type.
- Unconfuse one place about enum pipe vs enum transcoder - for the pch
transcoder we actually use the pipe enum. Fixup the other cases
where we assign the pipe to the cpu transcoder with explicit casts.
- Declare the mch_lock properly in a header.
There is still a decent mess in intel_bios.c about __iomem, but heck,
this is x86 and we're allowed to do that.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c |4 ++--
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/i915_gem.c |2 +-
drivers/gpu/drm/i915/i915_irq.c |3 ---
drivers/gpu/drm/i915/intel_ddi.c |2 +-
drivers/gpu/drm/i915/intel_display.c |9 +
6 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 62619e3..3f588ff 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -544,11 +544,11 @@ static int i915_hws_info(struct seq_file *m, void *data)
struct drm_device *dev = node-minor-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring;
- const volatile u32 __iomem *hws;
+ const u32 *hws;
int i;
ring = dev_priv-ring[(uintptr_t)node-info_ent-data];
- hws = (volatile u32 __iomem *)ring-status_page.page_addr;
+ hws = ring-status_page.page_addr;
if (hws == NULL)
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 31ab43b..3950d75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -572,6 +572,9 @@ struct intel_gen6_power_mgmt {
struct mutex hw_lock;
};
+/* defined intel_pm.c */
+extern spinlock_t mchdev_lock;
+
struct intel_ilk_power_mgmt {
u8 cur_delay;
u8 min_delay;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5c8df57..d1091f4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3693,7 +3693,7 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct
drm_device *dev,
{
struct drm_i915_gem_object *obj;
struct address_space *mapping;
- u32 mask;
+ gfp_t mask;
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
if (obj == NULL)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6cd3dc9..1a1862c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -300,9 +300,6 @@ static void i915_hotplug_work_func(struct work_struct *work)
drm_helper_hpd_irq_event(dev);
}
-/* defined intel_pm.c */
-extern spinlock_t mchdev_lock;
-
static void ironlake_handle_rps_change(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ad936c6..f02b3fe 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1044,7 +1044,7 @@ bool intel_ddi_connector_get_hw_state(struct
intel_connector *intel_connector)
if (port == PORT_A)
cpu_transcoder = TRANSCODER_EDP;
else
- cpu_transcoder = pipe;
+ cpu_transcoder = (enum transcoder) pipe;
tmp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 52b6b0e..f32877c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1671,7 +1671,7 @@ static void lpt_enable_pch_transcoder(struct
drm_i915_private *dev_priv,
BUG_ON(dev_priv-info-gen 5);
/* FDI must be feeding us bits for PCH ports */
- assert_fdi_tx_enabled(dev_priv, cpu_transcoder);
+ assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
/* Workaround: set timing override bit. */
@@ -1759,7 +1759,7 @@ static void intel_enable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe,
{
enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
pipe);
- enum transcoder pch_transcoder;
+ enum pipe pch_transcoder;
int reg;
u32 val;
@@ -1779,7 +1779,8 @@ static void intel_enable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe,
if (pch_port) {
/* if driving the PCH, we need FDI enabled */
assert_fdi_rx_pll_enabled(dev_priv, pch_transcoder);
- assert_fdi_tx_pll_enabled(dev_priv, cpu_transcoder);
+ assert_fdi_tx_pll_enabled(dev_priv,
+
Re: [Intel-gfx] [PATCH 1/3] drm/i915: fix hsw_fdi_link_train retry code
On Thu, Nov 29, 2012 at 11:29:31AM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We were previously doing exactly what the mode set sequence for CRT
document mandates, but whenever we failed to train the link in the
first tentative, all the other subsequent retries always failed. In
one of my monitors that has 47 modes, I was usually getting around 3
failures when running testdisplay -a.
After this patch, even if we fail in the first tentative, we can
succeed in the next ones. So now when running testdisplay -a I see
around 3 times the message FDI link training done on step 1 and no
failures.
Notice that now the retry code looks a lot like the DP retry code.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 43
+---
1 file changed, 27 insertions(+), 16 deletions(-)
I'd like this to go to 3.8 somehow.
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 852012b..3264cb4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -138,6 +138,19 @@ static const long hsw_ddi_buf_ctl_values[] = {
DDI_BUF_EMP_800MV_3_5DB_HSW
};
+static void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
+ enum port port)
+{
+ uint32_t reg = DDI_BUF_CTL(port);
+ int i;
+
+ for (i = 0; i 8; i++) {
+ udelay(1);
+ if (I915_READ(reg) DDI_BUF_IS_IDLE)
+ return;
+ }
+ DRM_ERROR(Timeout waiting for DDI BUF %c idle bit\n, port_name(port));
+}
/* Starting with Haswell, different DDI ports can work in FDI mode for
* connection to the PCH-located connectors. For this, it is necessary to
train
@@ -231,18 +244,30 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
return;
}
+ temp = I915_READ(DDI_BUF_CTL(PORT_E));
+ temp = ~DDI_BUF_CTL_ENABLE;
+ I915_WRITE(DDI_BUF_CTL(PORT_E), temp);
+ POSTING_READ(DDI_BUF_CTL(PORT_E));
+
/* Disable DP_TP_CTL and FDI_RX_CTL and retry */
- I915_WRITE(DP_TP_CTL(PORT_E),
-I915_READ(DP_TP_CTL(PORT_E)) ~DP_TP_CTL_ENABLE);
+ temp = I915_READ(DP_TP_CTL(PORT_E));
+ temp = ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
+ temp |= DP_TP_CTL_LINK_TRAIN_PAT1;
+ I915_WRITE(DP_TP_CTL(PORT_E), temp);
+ POSTING_READ(DP_TP_CTL(PORT_E));
+
+ intel_wait_ddi_buf_idle(dev_priv, PORT_E);
rx_ctl_val = ~FDI_RX_ENABLE;
I915_WRITE(_FDI_RXA_CTL, rx_ctl_val);
+ POSTING_READ(_FDI_RXA_CTL);
/* Reset FDI_RX_MISC pwrdn lanes */
temp = I915_READ(_FDI_RXA_MISC);
temp = ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
temp |= FDI_RX_PWRDN_LANE1_VAL(2) | FDI_RX_PWRDN_LANE0_VAL(2);
I915_WRITE(_FDI_RXA_MISC, temp);
+ POSTING_READ(_FDI_RXA_MISC);
What now slightly irks me here is that this sequence and the one in
intel_ddi_fdi_disable don't match exactly. Imo it would make sense to have
both the same (after all, we disable the same piece of hw) - have you
tried that out (there's obviously some slight unification required first)?
-Daniel
}
DRM_ERROR(FDI link training failed!\n);
@@ -1222,20 +1247,6 @@ static void intel_ddi_pre_enable(struct intel_encoder
*intel_encoder)
}
}
-static void intel_wait_ddi_buf_idle(struct drm_i915_private *dev_priv,
- enum port port)
-{
- uint32_t reg = DDI_BUF_CTL(port);
- int i;
-
- for (i = 0; i 8; i++) {
- udelay(1);
- if (I915_READ(reg) DDI_BUF_IS_IDLE)
- return;
- }
- DRM_ERROR(Timeout waiting for DDI BUF %c idle bit\n, port_name(port));
-}
-
static void intel_ddi_post_disable(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
--
1.7.11.7
___
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
