Re: [Intel-gfx] [PATCH 1/6] drm/i915: unconditionally copy mode into crtc at boot time
On Mon, Dec 16, 2013 at 04:35:40PM -0800, Jesse Barnes wrote:
On Thu, 12 Dec 2013 14:44:33 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 12 Dec 2013 23:39:39 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Dec 12, 2013 at 01:29:39PM -0800, Jesse Barnes wrote:
On Thu, 12 Dec 2013 22:21:29 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Dec 12, 2013 at 12:41:52PM -0800, Jesse Barnes wrote:
The BIOS code will need this to properly inherit the mode.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af3717a..1ae3d44 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11175,7 +11175,7 @@ void intel_modeset_setup_hw_state(struct
drm_device *dev,
*/
list_for_each_entry(crtc, dev-mode_config.crtc_list,
base.head) {
- if (crtc-active i915_fastboot) {
+ if (crtc-active) {
That's just enabling half of the fastboot hack, so nacked.
This part isn't the hack, but is required for fastboot. Without this,
we'll end up with a bogus mode when we try to inherit from the BIOS.
So if you want to nack this I'll have to put the other BIOS bits under
fastboot as well.
crtc-config.pipe_src_w/h not good enough? I've thought that's what you've
used in the last iteration, hence my suprise why we suddenly need to
resurrect this hack here. All the information this hack exposes to
crtc-mode is available in the pipe config, so I really don't think you
neeed it.
Count me confused for now, please explain.
Yes, we read out all the data into the pipe config. But if we don't
put that data into the CRTC proper, any subsequent code that uses the
CRTC mode will fail and think there's nothing there (resulting in fail
at fbcon DPMS time for example).
The actual warning w/o this change is:
[ 17.088591] [drm:intel_pipe_config_compare] *ERROR* mismatch in pipe_src_w
(expected 0, found 4096)
[ 17.088592] [ cut here ]
[ 17.088619] WARNING: CPU: 1 PID: 534 at
drivers/gpu/drm/i915/intel_display.c:9588 check_crtc_state+0x6bf/0xc90
[i915]()
[ 17.088619] pipe state doesn't match!
...
[ 17.088710] [a02f2caf] check_crtc_state+0x6bf/0xc90 [i915]
[ 17.088729] [a03007ab] intel_modeset_check_state+0x2bb/0x7b0
[i915]
[ 17.088745] [a0300d35] intel_set_mode+0x25/0x30 [i915]
[ 17.088762] [a03015db] intel_crtc_set_config+0x7ab/0x9a0 [i915]
[ 17.088777] [a0133a4d] drm_mode_set_config_internal+0x5d/0xe0
[drm]
[ 17.088783] [a0184ea1] drm_fb_helper_set_par+0x71/0xf0
[drm_kms_helper]
[ 17.088787] [8135b301] fb_set_var+0x191/0x430
So the first mode set from the fb layer is half baked, because the core
DRM structures didn't have the right mode to pass down, and so we fall
over.
I can fix this either by always copying the mode info into the core
structs, or by putting the call to fbdev_init_bios under i915_fastboot
as well.
Hm, I think I need to take a closer look here again since I really thought
it'd would Just Work. Hiding more behind the fastboot hack isn't really
what I want either, especially since we want to move from checking the
input mode to checking the pipe config for fastbooting. So having a single
piece which relies on that reconstructed mode would be rather ugly.
Can you please attach the full debug log for this?
Also, could this just be a side effect of the more fancy -initial_config
logic, i.e. what happens if we disable that one?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: retrieve current fb config into new plane_config structure at init
On Mon, Dec 16, 2013 at 04:01:41PM -0800, Jesse Barnes wrote: On Sat, 14 Dec 2013 12:01:47 +0100 Daniel Vetter dan...@ffwll.ch wrote: But I still think the fb lifetime management is a bit broken here and we need a few small changes: 1. Right here in this loop we need to assign the fb from the plane_config ot the crtc-fb pointer and grab an fb reference for that. If we don't do that we'll fall over for CONFIG_FB=n A side-effect of that is that plane_config is now fairly redundant and we have the problem of cleaning up the fb referenced in there somehow (especially for CONFIG_FB=n). That's kinda the reason why I don't like it very much ... The below points are for the next patch, just noting them here for the full picture. I haven't read carefully through that patch yet, so might all be correct already. 2. We need to clean up fb reference in the plane config. Iirc your current patch 3 fails that for CONFIG_FB=n Hm yeah the ownership is less clear in the CONFIG_FB=n case. I think the driver will own the buffer, and it'll get dropped on the first mode set with a new buffer. But even then there will be no process to deref the object finally, so it'll stick around. Hm... maybe just disable it if CONFIG_FB=n is the right answer for now. If you switch the fbdev code to look at crtc-fb instead of crtc-plane_config.fb and just drop the plane_config.fb pointer (and it's reference) it should pan out. Then the only reference+pointers we have are the ones in crtc-fb, and the drm core will take care of those. fbdev then needs to grab an additional reference for ifbdev-fb, but it needs to do that anyway. Your current code seems to just steal the initial reference from creating the framebuffer in -get_plane_config. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915: read out hw state earlier
On Mon, Dec 16, 2013 at 04:34:25PM -0800, Jesse Barnes wrote: We want to do this early on before we try to fetch the plane config, which depends on some of the pipe config state. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org I've merged patches 23 from this series. This one here needs a backmerge which atm is blocked on Dave moving drm-fixes ahead ... -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 07/15] drm/i915: gen specific ring init
On Mon, Dec 16, 2013 at 08:50:43PM -0800, Ben Widawsky wrote:
Gen8 has already had some differentiation with how it handles rings.
Semaphores bring yet more differences, and now is as good a time as any
to do the split.
Also, since gen8 doesn't actually use semaphores up until this point,
put the proper NULL values in for the mbox info.
v2: v1 had a stale commit message
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Subject should probably say gen_8_ specific ring init since for the
render ring we already have gen specific stuff. I can do this
color-adjustment when applying if nothing else pops up ;-)
-Daniel
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 134
++--
1 file changed, 92 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 7a8c5d8..db63a5c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1857,19 +1857,33 @@ int intel_init_render_ring_buffer(struct drm_device
*dev)
ring-id = RCS;
ring-mmio_base = RENDER_RING_BASE;
- if (INTEL_INFO(dev)-gen = 6) {
+ if (INTEL_INFO(dev)-gen = 8) {
+ ring-add_request = gen6_add_request;
+ ring-flush = gen8_render_ring_flush;
+ ring-irq_get = gen8_ring_get_irq;
+ ring-irq_put = gen8_ring_put_irq;
+ ring-irq_enable_mask = GT_RENDER_USER_INTERRUPT;
+ ring-get_seqno = gen6_ring_get_seqno;
+ ring-set_seqno = ring_set_seqno;
+ ring-semaphore.sync_to = gen6_ring_sync;
+ if (i915_semaphore_is_enabled(dev))
+ ring-semaphore.signal = gen6_signal;
+ ring-semaphore.signal = gen6_signal;
+ ring-semaphore.mbox[RCS] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore.mbox[VCS] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore.mbox[BCS] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore.mbox[VECS] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore.signal_mbox[RCS] = GEN6_NOSYNC;
+ ring-semaphore.signal_mbox[VCS] = GEN6_NOSYNC;
+ ring-semaphore.signal_mbox[BCS] = GEN6_NOSYNC;
+ ring-semaphore.signal_mbox[VECS] = GEN6_NOSYNC;
+ } else if (INTEL_INFO(dev)-gen = 6) {
ring-add_request = gen6_add_request;
ring-flush = gen7_render_ring_flush;
if (INTEL_INFO(dev)-gen == 6)
ring-flush = gen6_render_ring_flush;
- if (INTEL_INFO(dev)-gen = 8) {
- ring-flush = gen8_render_ring_flush;
- ring-irq_get = gen8_ring_get_irq;
- ring-irq_put = gen8_ring_put_irq;
- } else {
- ring-irq_get = gen6_ring_get_irq;
- ring-irq_put = gen6_ring_put_irq;
- }
+ ring-irq_get = gen6_ring_get_irq;
+ ring-irq_put = gen6_ring_put_irq;
ring-irq_enable_mask = GT_RENDER_USER_INTERRUPT;
ring-get_seqno = gen6_ring_get_seqno;
ring-set_seqno = ring_set_seqno;
@@ -1911,6 +1925,7 @@ int intel_init_render_ring_buffer(struct drm_device
*dev)
ring-irq_enable_mask = I915_USER_INTERRUPT;
}
ring-write_tail = ring_write_tail;
+
if (IS_HASWELL(dev))
ring-dispatch_execbuffer = hsw_ring_dispatch_execbuffer;
else if (IS_GEN8(dev))
@@ -2044,24 +2059,35 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
ring-irq_put = gen8_ring_put_irq;
ring-dispatch_execbuffer =
gen8_ring_dispatch_execbuffer;
+ ring-semaphore.sync_to = gen6_ring_sync;
+ if (i915_semaphore_is_enabled(dev))
+ ring-semaphore.signal = gen6_signal;
+ ring-semaphore.mbox[RCS] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore.mbox[VCS] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore.mbox[BCS] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore.mbox[VECS] = MI_SEMAPHORE_SYNC_INVALID;
+ ring-semaphore.signal_mbox[RCS] = GEN6_NOSYNC;
+ ring-semaphore.signal_mbox[VCS] = GEN6_NOSYNC;
+ ring-semaphore.signal_mbox[BCS] = GEN6_NOSYNC;
+ ring-semaphore.signal_mbox[VECS] = GEN6_NOSYNC;
} else {
ring-irq_enable_mask = GT_BSD_USER_INTERRUPT;
ring-irq_get = gen6_ring_get_irq;
ring-irq_put = gen6_ring_put_irq;
ring-dispatch_execbuffer =
gen6_ring_dispatch_execbuffer;
+ ring-semaphore.sync_to = gen6_ring_sync;
+ if
[Intel-gfx] [PATCH] drm/i915: Use symbolic names for booleans in i915_semaphore_is_enabled
Noticed while reviewing a patch and couldn't resist the OCD.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aea909b2f22e..31ffe39d2b79 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -480,12 +480,12 @@ check_next:
bool i915_semaphore_is_enabled(struct drm_device *dev)
{
if (INTEL_INFO(dev)-gen 6)
- return 0;
+ return false;
/* Until we get further testing... */
if (IS_GEN8(dev)) {
WARN_ON(!i915_preliminary_hw_support);
- return 0;
+ return false;
}
if (i915_semaphores = 0)
@@ -497,7 +497,7 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
return false;
#endif
- return 1;
+ return true;
}
static int i915_drm_freeze(struct drm_device *dev)
--
1.8.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: kick firmware fbs even when i915 fbdev is disabled
Otherwise we don't kick out firmware framebuffers like vesafb and
efifb when CONFIG_DRM_I915_FBDEV=n but CONFIG_FB=y.
There's still the pesky issue with vgacon which we should somehow
replace with the dummy console at least. We have a similar issue at
module un/reload, since vgacon state is terminally botched after
i915.ko has loaded in modeset mode. But this gets us a step further at
least.
v2: Use IS_ENABLED - I always get this wrong for tristates. Spotted by
Jani.
Reported-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jani Nikula jani.nik...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index c9101bde96be..6b5f63043cde 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1413,7 +1413,7 @@ void i915_master_destroy(struct drm_device *dev, struct
drm_master *master)
master-driver_priv = NULL;
}
-#ifdef CONFIG_DRM_I915_FBDEV
+#if IS_ENABLED(CONFIG_FB)
static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
{
struct apertures_struct *ap;
--
1.8.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Propagate PCI read/write errors during vga_set_state()
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
This has very little effect other than log the errors in case of failure,
and we then hope for the best.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d0082a025c83..7db292c469af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11336,12 +11336,21 @@ int intel_modeset_vga_set_state(struct drm_device
*dev, bool state)
struct drm_i915_private *dev_priv = dev-dev_private;
u16 gmch_ctrl;
- pci_read_config_word(dev_priv-bridge_dev, INTEL_GMCH_CTRL, gmch_ctrl);
+ if (pci_read_config_word(dev_priv-bridge_dev, INTEL_GMCH_CTRL,
gmch_ctrl)) {
+ DRM_ERROR(failed to read control word\n);
+ return -EIO;
+ }
+
if (state)
gmch_ctrl = ~INTEL_GMCH_VGA_DISABLE;
else
gmch_ctrl |= INTEL_GMCH_VGA_DISABLE;
- pci_write_config_word(dev_priv-bridge_dev, INTEL_GMCH_CTRL, gmch_ctrl);
+
+ if (pci_write_config_word(dev_priv-bridge_dev, INTEL_GMCH_CTRL,
gmch_ctrl)) {
+ DRM_ERROR(failed to write control word\n);
+ return -EIO;
+ }
+
return 0;
}
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/15] [v2] Broadwell HW semaphore
On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote: Reposting this as a new series since two of the patches dropped off since last time. Functionally it's the same as before. Like before, the patch drm/i915: unleash semaphores on gen8 should probably not be merged as it's not 100% clear where the hang is currently coming from. Everything else should be pretty benign for other platforms. I've pulled in the first two patches already. For review Damien is signed up (althought he goes on vacation soon) and for greater learning experience he's also agreed to throw in a testcase on top. We already have a nice stresstest for semaphores (gem_ring_sync_loop), but no real functional test which checks that the batches are indeed correctly ordered. For gpu vs. cpu races we already have a fairly complete set in gem_concurrent_blt, but that has many additional complications we don't really care about for ring2ring syncing. For each pair of rings R1, R2 where we have copy support (i.e. blt, rendercpy and mediafill) do: - Throw a busy load onto R1. gem_concurrent_blt just uses lots of buffers for this effect. - Fill three buffers A, B, C with unique data. - Copy A to B on ring R1 Then come the three different variants. - Copy B to C on ring R2, check that C now contains what A originally contained. This is the write-read hazard. gem_concurrent_blt calls this early read. - Copy C to A on ring R2, check that B now contains what A originally contained. This is the read-write hazard, gem_concurrent_blt calls it overwrite_source. - Copy C to B on ring R2 and check that B contains what C originally contained. This is the write/write hazard. gem_concurrent_blt doesn't have that since for the cpu case it's too boring. - As long as we don't allow concurrent reads on different rings testing that one isn't worth it. And even then we could only check whether the ring without the busy load indeed completes much earlier than the other (i.e. both rings would copy a shared buffer to a private buffer). Not worth it at all. We also have some other tests for cpu access which check for specific bugs where we've in the past lost the last gpu read/last gpu write access breadcrumb. But those only make sense once we have bugs (or more complicated code like e.g. whith the scheduler). Cheers, Daniel Ben Widawsky (15): drm/i915: Reorder/respace MI instruction definition drm/i915: Don't emit mbox updates without semaphores drm/i915: Move semaphore specific ring members to struct drm/i915: Virtualize the ringbuffer signal func drm/i915: Move ring_begin to signal() drm/i915: Make semaphore updates more precise drm/i915: gen specific ring init drm/i915/bdw: implement semaphore signal drm/i915/bdw: implement semaphore wait drm/i915: FORCE_RESTORE for gen8 semaphores drm/i915/bdw: poll semaphores drm/i915: Extract semaphore error collection drm/i915/bdw: collect semaphore error state drm/i915: unleash semaphores on gen8 drm/i915: semaphore debugfs drivers/gpu/drm/i915/i915_debugfs.c | 69 +++ drivers/gpu/drm/i915/i915_drv.c | 6 - drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_gem.c | 10 +- drivers/gpu/drm/i915/i915_gem_context.c | 9 + drivers/gpu/drm/i915/i915_gpu_error.c | 75 ++-- drivers/gpu/drm/i915/i915_reg.h | 58 +++--- drivers/gpu/drm/i915/intel_ringbuffer.c | 329 drivers/gpu/drm/i915/intel_ringbuffer.h | 87 - 9 files changed, 508 insertions(+), 137 deletions(-) -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Short-circuit no-op vga_set_state()
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote: Touching the VGA registers risks a hard machine hang, at least on this ivb machine after removing a conflicting efifb. This is more than likely related to the discovery that VGA IO decode on the more recent PCH platforms is terminally broken. Please double check the config space address. At a glance, it looks like we should be using SNB_GMCH_CTRL since SNB. Might explain the issues? Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7db292c469af..d9b91a585dbf 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11341,6 +11341,9 @@ int intel_modeset_vga_set_state(struct drm_device *dev, bool state) return -EIO; } + if (!!(gmch_ctrl INTEL_GMCH_VGA_DISABLE) == !state) + return 0; + I think I'd use a temp gmch_ctrl, make the change below on that, and then compare the new and old values. Just to avoid the use of negatives so much. Either way, the patch is Reviewed-by: Jani Nikula jani.nik...@intel.com *iff* it's still needed with the verified config space address. BR, Jani. if (state) gmch_ctrl = ~INTEL_GMCH_VGA_DISABLE; else -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kick firmware fbs even when i915 fbdev is disabled
On Tue, 17 Dec 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Otherwise we don't kick out firmware framebuffers like vesafb and
efifb when CONFIG_DRM_I915_FBDEV=n but CONFIG_FB=y.
There's still the pesky issue with vgacon which we should somehow
replace with the dummy console at least. We have a similar issue at
module un/reload, since vgacon state is terminally botched after
i915.ko has loaded in modeset mode. But this gets us a step further at
least.
v2: Use IS_ENABLED - I always get this wrong for tristates. Spotted by
Jani.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Reported-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jani Nikula jani.nik...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index c9101bde96be..6b5f63043cde 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1413,7 +1413,7 @@ void i915_master_destroy(struct drm_device *dev, struct
drm_master *master)
master-driver_priv = NULL;
}
-#ifdef CONFIG_DRM_I915_FBDEV
+#if IS_ENABLED(CONFIG_FB)
static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
{
struct apertures_struct *ap;
--
1.8.4.3
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Patchwork for intel-gfx
Hi all, Thanks to Carl Worth we now have a nice pachwork instance for intel-gfx: http://patchwork.freedesktop.org/project/intel-gfx/list/ We also have a git hook for i-g-t, xf86-video-intel and my drm-intel repo which will automatically set patches to Accepted when they're merged. I'll manually update the patch state when the automagic mode doesn't work (e.g. when I apply a small fixup to the patch while merging). Right now I think patchwork is a nice way for developers to keep track of all their own patches. So if you want to use it please create an account and then occasionally clean up all your old patches and put them into Rejected or the Superseeded state. I'm not sure whether patchwork is the right tool for assigning reviewers (it has some features), so for now we'll keep the current system. I'll also be more lazy with sending out merge confirmations since patchwork keeps track of that now. I'll still send replies when I frob patches though. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Use IS_VALLEYVIEW() to test the is_valleyview flag
On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Merged this one here, not really sure what to do with the rest.
-Daniel
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c01d08d..351065d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3584,9 +3584,11 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
void gen6_rps_idle(struct drm_i915_private *dev_priv)
{
+ struct drm_device *dev = dev_priv-dev;
+
mutex_lock(dev_priv-rps.hw_lock);
if (dev_priv-rps.enabled) {
- if (dev_priv-info-is_valleyview)
+ if (IS_VALLEYVIEW(dev))
valleyview_set_rps(dev_priv-dev,
dev_priv-rps.min_delay);
else
gen6_set_rps(dev_priv-dev, dev_priv-rps.min_delay);
@@ -3597,9 +3599,11 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
void gen6_rps_boost(struct drm_i915_private *dev_priv)
{
+ struct drm_device *dev = dev_priv-dev;
+
mutex_lock(dev_priv-rps.hw_lock);
if (dev_priv-rps.enabled) {
- if (dev_priv-info-is_valleyview)
+ if (IS_VALLEYVIEW(dev))
valleyview_set_rps(dev_priv-dev,
dev_priv-rps.max_delay);
else
gen6_set_rps(dev_priv-dev, dev_priv-rps.max_delay);
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/15] drm/i915: Make semaphore updates more precise
On Mon, Dec 16, 2013 at 08:50:42PM -0800, Ben Widawsky wrote: @@ -2054,7 +2052,8 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev) gen6_ring_dispatch_execbuffer; } ring-semaphore.sync_to = gen6_ring_sync; - ring-semaphore.signal = gen6_signal; + if (i915_semaphore_is_enabled(dev)) + ring-semaphore.signal = gen6_signal; This is made more complicated as we allow changing i915.semaphores at runtime. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] S3 resume and commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King colin.k...@canonical.com wrote: Hi there, There is a S3 resume issue that affects HP Mini Atom N270 with Intel Mobile 945GSE on Linux 3.9.0 upwards. Device: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:361a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe98 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at dc80 [size=8] Region 2: Memory at d000 (32-bit, prefetchable) [size=256M] Region 3: Memory at fe94 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 Issue: On S3 resume screen is blank. I've tracked this down to 2 patches: 1. 24576d23976746cb52e7700c4cadbf4bc1bc3472 drm/i915: enable VT switchless resume v3 This commit stops the screen from turning back on. Without the patch the screen resumes back to on, however it is filled with random vertical lines. 2. fa55583797d12b10928a1813f3dcf066637caf5e drm/i915: fixup the plane-pipe fixup code I have to manually revert this. If I don't I get the random vertical lines on resume. Any ideas on how to address these two issues that cause S3 resume to leave the HP mini in a broken state? Please file a bug report on bugs.freedesktop.org against DRI - DRM(Intel). Also please always cc relevant mailing lists when reporting kernel issues. -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 5/8] drm/i915: retrieve current fb config into new plane_config structure at init v7
On Mon, Dec 16, 2013 at 04:34:26PM -0800, Jesse Barnes wrote:
+ if (INTEL_INFO(dev)-gen = 4) {
+ if (plane_config-tiled)
+ offset = I915_READ(DSPTILEOFF(plane));
+ else
+ offset = I915_READ(DSPLINOFF(plane));
+ base = I915_READ(DSPSURF(plane)) 0xf000;
+ } else {
+ base = I915_READ(DSPADDR(plane));
+ }
+
+ val = I915_READ(PIPESRC(pipe));
+ plane_config-fb-base.width = ((val 16) 0xfff) + 1;
+ plane_config-fb-base.height = ((val 0) 0xfff) + 1;
+
+ val = I915_READ(DSPSTRIDE(pipe));
+ plane_config-fb-base.pitches[0] = val 0xff80;
+
+ plane_config-size = ALIGN(plane_config-fb-base.pitches[0] *
+plane_config-fb-base.height, PAGE_SIZE);
This underestimates the size of a tiled framebuffer. Height should be
aligned to 1,16,64 depending on tiling.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/14] drm/i915: Make ILK/SNB/IVB use HSW watermark code
On Mon, Dec 16, 2013 at 11:38:38PM +0200, Imre Deak wrote: On Thu, 2013-12-05 at 15:51 +0200, ville.syrj...@linux.intel.com wrote: Back on the watermark horse. This series moves ILK/SNB/IVB over to the HSW watermark code. This series still has some underrun issues since the safe watermark update mechanism is yet to be introduced. However it shouldn't really be any worse than what we have ATM, and I'd like to have all the platforms converted so that we have more systems that will excercise the new update mechanism when it arrives. Looks ok to me. I have a couple of bikesheds inlined, regardless of those on the series: Yeah, that looks like good cleanups on top, but since Ville is already on vacation I've decided to pull the patches in already. -Daniel Reviewed-by: Imre Deak imre.d...@intel.com Ville Syrjälä (14): drm/i915: Add IVB DDB partitioning control drm/i915: Add ILK/SNB/IVB WM latency field support drm/i915: Avoid computing invalid WM levels when sprites/scaling is enabled Revert drm/i915/sprite: Always enable the scaler on IronLake drm/i915: Fix LP1 sprite watermarks for ILK/SNB drm/i915: Fix LP1+ watermark disabling ILK drm/i915: Don't merge LP1+ watermarks on ILK/SNB/IVB when multiple pipes are enabled drm/i915: Disable FBC WM on ILK, and disable LP2+ when FBC is enabled drm/i915: Linetime watermarks are a HSW feature drm/i915: Disable LP1+ watermarks safely in init drm/i915: Move ILK/SNB/IVB over to the HSW WM code drm/i915: Try to fix the messy IVB sprite scaling workaround drm/i915: Don't disable primary when color keying is used drm/i915: Avoid underruns when disabling sprites drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 857 +++ drivers/gpu/drm/i915/intel_sprite.c | 50 +- 5 files changed, 195 insertions(+), 717 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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 6/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
+ if (dev_priv-fbdev)
+ drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
}
Also intel_fbdev_restore_mode() needs the NULL fbdev safeguard.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use symbolic names for booleans in i915_semaphore_is_enabled
On Tue, 17 Dec 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Noticed while reviewing a patch and couldn't resist the OCD.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aea909b2f22e..31ffe39d2b79 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -480,12 +480,12 @@ check_next:
bool i915_semaphore_is_enabled(struct drm_device *dev)
{
if (INTEL_INFO(dev)-gen 6)
- return 0;
+ return false;
/* Until we get further testing... */
if (IS_GEN8(dev)) {
WARN_ON(!i915_preliminary_hw_support);
- return 0;
+ return false;
}
if (i915_semaphores = 0)
@@ -497,7 +497,7 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
return false;
#endif
- return 1;
+ return true;
}
static int i915_drm_freeze(struct drm_device *dev)
--
1.8.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Use IS_VALLEYVIEW() to test the is_valleyview flag
On Tue, Dec 17, 2013 at 10:38:48AM +0100, Daniel Vetter wrote: On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote: Signed-off-by: Damien Lespiau damien.lesp...@intel.com Merged this one here, not really sure what to do with the rest. So, apparently, there's some unhappiness with INTEL_INFO, which is somewhat understandable, it doesn't provide much more convenience than dev_priv-info. I can resend the series getting rid of INTEL_INFO() if the sentiment is shared. To provide the const safety, we can then declare the info struct as const in the private structure and cast it as non const at initialization time (as Ville suggests). -- Damien ___ 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: Short-circuit no-op vga_set_state()
On Tue, Dec 17, 2013 at 11:21:27AM +0200, Jani Nikula wrote: On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote: Touching the VGA registers risks a hard machine hang, at least on this ivb machine after removing a conflicting efifb. This is more than likely related to the discovery that VGA IO decode on the more recent PCH platforms is terminally broken. Please double check the config space address. At a glance, it looks like we should be using SNB_GMCH_CTRL since SNB. Might explain the issues? Hmm, indeed. This bit is at a different location on SNB, but it is locked. Which is where all the vgaarb madness began last time. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Short-circuit no-op vga_set_state()
On Tue, Dec 17, 2013 at 11:45:45AM +, Chris Wilson wrote: On Tue, Dec 17, 2013 at 11:21:27AM +0200, Jani Nikula wrote: On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote: Touching the VGA registers risks a hard machine hang, at least on this ivb machine after removing a conflicting efifb. This is more than likely related to the discovery that VGA IO decode on the more recent PCH platforms is terminally broken. Please double check the config space address. At a glance, it looks like we should be using SNB_GMCH_CTRL since SNB. Might explain the issues? Hmm, indeed. This bit is at a different location on SNB, but it is locked. Which is where all the vgaarb madness began last time. Ok, that feels at least as stable as not writing to the invalid address. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] video/fb: Propagate error code from failing to unregister conflicting fb
On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
---
drivers/video/fbmem.c | 31 +--
include/linux/fb.h| 4 ++--
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 010d19105ebc..e296967a3abb 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1577,10 +1577,10 @@ static bool fb_do_apertures_overlap(struct
apertures_struct *gena,
static int do_unregister_framebuffer(struct fb_info *fb_info);
#define VGA_FB_PHYS 0xA
-static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
-const char *name, bool primary)
+static int do_remove_conflicting_framebuffers(struct apertures_struct *a,
+ const char *name, bool primary)
{
- int i;
+ int i, ret;
/* check all firmware fbs and kick off if the base addr overlaps */
for (i = 0 ; i FB_MAX; i++) {
@@ -1599,22 +1599,29 @@ static void
do_remove_conflicting_framebuffers(struct apertures_struct *a,
printk(KERN_INFO fb: conflicting fb hw usage
%s vs %s - removing generic driver\n,
name, registered_fb[i]-fix.id);
- do_unregister_framebuffer(registered_fb[i]);
+ ret = do_unregister_framebuffer(registered_fb[i]);
+ if (ret)
+ return ret;
An observation, this bails out early instead of trying to unregister all
the conflicting framebuffers regardless of errors like before. We're
probably doomed either way?
Indeed. Early exit hopefully leaves the machine usable for bug reporting.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Use IS_VALLEYVIEW() to test the is_valleyview flag
On Tue, Dec 17, 2013 at 12:17 PM, Damien Lespiau damien.lesp...@intel.com wrote: On Tue, Dec 17, 2013 at 10:38:48AM +0100, Daniel Vetter wrote: On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote: Signed-off-by: Damien Lespiau damien.lesp...@intel.com Merged this one here, not really sure what to do with the rest. So, apparently, there's some unhappiness with INTEL_INFO, which is somewhat understandable, it doesn't provide much more convenience than dev_priv-info. I can resend the series getting rid of INTEL_INFO() if the sentiment is shared. To provide the const safety, we can then declare the info struct as const in the private structure and cast it as non const at initialization time (as Ville suggests). I'd be ok with that plan. Like I've said on irc, no opinions really on this matter, as long as we can keep the const safety around - imo that helps a lot with reviewing code. E.g. Chris just spotted that some of Ben's semaphore changes aren't too safe since we can frob semaphores at runtime. -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 1/5] drm/i915: Adding VBT fields to support eDP DRRS feature
On Tue, Dec 17, 2013 at 10:58:23AM +0530, Vandana Kannan wrote: From: Pradeep Bhat pradeep.b...@intel.com This patch reads the DRRS support and Mode type from VBT fields. The read information will be stored in VBT struct during BIOS parsing. The above functionality is needed for decision making whether DRRS feature is supported in i915 driver for eDP panels. This information helps us decide if seamless DRRS can be done at runtime to support certain power saving features. This patch was tested by setting necessary bit in VBT struct and merging the new VBT with system BIOS so that we can read the value. What's the reason for the inconsistent intel_ tautology? @@ -488,6 +508,9 @@ parse_driver_features(struct drm_i915_private *dev_priv, if (driver-dual_frequency) dev_priv-render_reclock_avail = true; + + dev_priv-vbt.intel_drrs_enabled = driver-intel_drrs_state; + DRM_DEBUG_KMS(DRRS State Enabled : %d\n, driver-intel_drrs_state); Now this oddity needs a big explanation. Writing that will hopefully reveal a better strategy. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Parse EDID probed modes for DRRS support
On Tue, Dec 17, 2013 at 10:58:24AM +0530, Vandana Kannan wrote:
From: Pradeep Bhat pradeep.b...@intel.com
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode, based on the implementaion find_panel_downclock.
It also checks the VBT fields to see if panel supports seamless DRRS or not.
Based on above data it marks whether eDP panel supports seamless DRRS or not.
This information is needed for supporting seamless DRRS switch for
certain power saving usecases. This patch is tested by enabling the DRM logs
and user should see whether Seamless DRRS is supported or not.
Signed-off-by: Pradeep Bhat pradeep.b...@intel.com
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_dp.c | 47
++
drivers/gpu/drm/i915/intel_drv.h | 29 +++
3 files changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 02e11dc..c9bca16 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1462,8 +1462,10 @@ typedef struct drm_i915_private {
/* Reclocking support */
bool render_reclock_avail;
bool lvds_downclock_avail;
+ bool edp_downclock_avail;
/* indicates the reduced downclock for LVDS*/
int lvds_downclock;
+ int edp_downclock;
u16 orig_clock;
Do any machines have both edp and lvds? Shouldn't this be a part of the
panel state?
+/**
+ * This enum is used to indicate the DRRS support type.
+ * The values of the enum map 1-to-1 with the values from VBT.
+ */
+enum edp_panel_type {
+ DRRS_NOT_SUPPORTED = -1,
+ STATIC_DRRS_SUPPORT = 0,
+ SEAMLESS_DRRS_SUPPORT = 2
+};
+/**
+ * HIGH_RR is the highest eDP panel refresh rate read from EDID
+ * LOW_RR is the lowest eDP panel refresh rate found from EDID
+ * parsing for same resolution.
+ */
+enum edp_drrs_refresh_rate_type {
+ DRRS_HIGH_RR,
+ DRRS_LOW_RR,
+ DRRS_MAX_RR, /* RR count */
+};
+/**
+ * The drrs_info struct will represent the DRRS feature for eDP
+ * panel.
+ */
+struct drrs_info {
+ int is_drrs_supported;
+ int drrs_refresh_rate_type;
So what was the point of the enums again? Are you purposely trying to
disable gcc and sparse's type-safety?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Idleness detection for DRRS
On Tue, Dec 17, 2013 at 10:58:26AM +0530, Vandana Kannan wrote: Adding support to detect display idleness by tracking page flip from user space. Switch to low refresh rate is triggered after 2 seconds of idleness. The delay is configurable. If there is a page flip or call to update the plane, then high refresh rate is applied. The feature is not used in dual-display mode. Looks very inconsistent next to intel_fbc_disable/intel_fbc_update. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915/bdw: Add support for DRRS to switch RR
On Tue, Dec 17, 2013 at 10:58:27AM +0530, Vandana Kannan wrote:
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M N registers and the new M/N values will be used in the next frame
that is output.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Signed-off-by: Pradeep Bhat pradeep.b...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 209be3c..183cfd7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,9 +798,15 @@ intel_dp_set_m2_n2(struct intel_crtc *crtc, struct
intel_link_m_n *m_n)
struct drm_i915_private *dev_priv = dev-dev_private;
enum transcoder transcoder = crtc-config.cpu_transcoder;
- if (INTEL_INFO(dev)-gen = 5 INTEL_INFO(dev)-gen 8) {
+ if (INTEL_INFO(dev)-gen = 8) {
+ I915_WRITE(PIPE_DATA_M1(transcoder),
+ TU_SIZE(m_n-tu) | m_n-gmch_m);
+ I915_WRITE(PIPE_DATA_N1(transcoder), m_n-gmch_n);
+ I915_WRITE(PIPE_LINK_M1(transcoder), m_n-link_m);
+ I915_WRITE(PIPE_LINK_N1(transcoder), m_n-link_n);
+ } else if (INTEL_INFO(dev)-gen = 5 INTEL_INFO(dev)-gen 8) {
Ouch. Double ouch later.
-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 1/3] drm/i915: simplify platform specific code in hsw_write_wm_values
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c12767c..f402c16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2516,12 +2516,11 @@ static void hsw_write_wm_values(struct drm_i915_private
*dev_priv,
I915_WRITE(DISP_ARB_CTL, val);
}
- if (INTEL_INFO(dev)-gen = 6) {
- if (dirty WM_DIRTY_LP(1) previous-wm_lp_spr[0] !=
results-wm_lp_spr[0])
- I915_WRITE(WM1S_LP_ILK, results-wm_lp_spr[0]);
- } else {
- if (dirty WM_DIRTY_LP(1) previous-wm_lp_spr[0] !=
results-wm_lp_spr[0])
- I915_WRITE(WM1S_LP_ILK, results-wm_lp_spr[0]);
+ if (dirty WM_DIRTY_LP(1)
+ previous-wm_lp_spr[0] != results-wm_lp_spr[0])
+ I915_WRITE(WM1S_LP_ILK, results-wm_lp_spr[0]);
+
+ if (INTEL_INFO(dev)-gen = 7) {
if (dirty WM_DIRTY_LP(2) previous-wm_lp_spr[1] !=
results-wm_lp_spr[1])
I915_WRITE(WM2S_LP_IVB, results-wm_lp_spr[1]);
if (dirty WM_DIRTY_LP(3) previous-wm_lp_spr[2] !=
results-wm_lp_spr[2])
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: remove unused WM defines
Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 36 1 file changed, 36 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e9548b1..a699efd 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3430,42 +3430,6 @@ /* the unit of memory self-refresh latency time is 0.5us */ #define ILK_SRLT_MASK 0x3f -/* define the fifo size on Ironlake */ -#define ILK_DISPLAY_FIFO 128 -#define ILK_DISPLAY_MAXWM 64 -#define ILK_DISPLAY_DFTWM 8 -#define ILK_CURSOR_FIFO32 -#define ILK_CURSOR_MAXWM 16 -#define ILK_CURSOR_DFTWM 8 - -#define ILK_DISPLAY_SR_FIFO512 -#define ILK_DISPLAY_MAX_SRWM 0x1ff -#define ILK_DISPLAY_DFT_SRWM 0x3f -#define ILK_CURSOR_SR_FIFO 64 -#define ILK_CURSOR_MAX_SRWM0x3f -#define ILK_CURSOR_DFT_SRWM8 - -#define ILK_FIFO_LINE_SIZE 64 - -/* define the WM info on Sandybridge */ -#define SNB_DISPLAY_FIFO 128 -#define SNB_DISPLAY_MAXWM 0x7f/* bit 16:22 */ -#define SNB_DISPLAY_DFTWM 8 -#define SNB_CURSOR_FIFO32 -#define SNB_CURSOR_MAXWM 0x1f/* bit 4:0 */ -#define SNB_CURSOR_DFTWM 8 - -#define SNB_DISPLAY_SR_FIFO512 -#define SNB_DISPLAY_MAX_SRWM 0x1ff /* bit 16:8 */ -#define SNB_DISPLAY_DFT_SRWM 0x3f -#define SNB_CURSOR_SR_FIFO 64 -#define SNB_CURSOR_MAX_SRWM0x3f/* bit 5:0 */ -#define SNB_CURSOR_DFT_SRWM8 - -#define SNB_FBC_MAX_SRWM 0xf /* bit 23:20 */ - -#define SNB_FIFO_LINE_SIZE 64 - /* the address where we get all kinds of latency value */ #define SSKPD 0x5d10 -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: s/haswell_update_wm/ilk_update_wm/
We use this hook starting from ILK onwards, so change the prefix
accordingly. Also rename functions/struct names used from
haswell_update_wm that are relevant to ILK already.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_pm.c | 86 -
2 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53288f6..bce647f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1215,7 +1215,7 @@ struct intel_wm_level {
uint32_t fbc_val;
};
-struct hsw_wm_values {
+struct ilk_wm_values {
uint32_t wm_pipe[3];
uint32_t wm_lp[3];
uint32_t wm_lp_spr[3];
@@ -1521,7 +1521,7 @@ typedef struct drm_i915_private {
uint16_t cur_latency[5];
/* current hardware state */
- struct hsw_wm_values hw;
+ struct ilk_wm_values hw;
} wm;
struct i915_package_c8 pc8;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f402c16..fccd7a8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1716,7 +1716,7 @@ static uint32_t ilk_wm_fbc(uint32_t pri_val, uint32_t
horiz_pixels,
return DIV_ROUND_UP(pri_val * 64, horiz_pixels * bytes_per_pixel) + 2;
}
-struct hsw_pipe_wm_parameters {
+struct ilk_pipe_wm_parameters {
bool active;
uint32_t pipe_htotal;
uint32_t pixel_rate;
@@ -1725,7 +1725,7 @@ struct hsw_pipe_wm_parameters {
struct intel_plane_wm_parameters cur;
};
-struct hsw_wm_maximums {
+struct ilk_wm_maximums {
uint16_t pri;
uint16_t spr;
uint16_t cur;
@@ -1743,7 +1743,7 @@ struct intel_wm_config {
* For both WM_PIPE and WM_LP.
* mem_value must be in 0.1us units.
*/
-static uint32_t ilk_compute_pri_wm(const struct hsw_pipe_wm_parameters *params,
+static uint32_t ilk_compute_pri_wm(const struct ilk_pipe_wm_parameters *params,
uint32_t mem_value,
bool is_lp)
{
@@ -1772,7 +1772,7 @@ static uint32_t ilk_compute_pri_wm(const struct
hsw_pipe_wm_parameters *params,
* For both WM_PIPE and WM_LP.
* mem_value must be in 0.1us units.
*/
-static uint32_t ilk_compute_spr_wm(const struct hsw_pipe_wm_parameters *params,
+static uint32_t ilk_compute_spr_wm(const struct ilk_pipe_wm_parameters *params,
uint32_t mem_value)
{
uint32_t method1, method2;
@@ -1795,7 +1795,7 @@ static uint32_t ilk_compute_spr_wm(const struct
hsw_pipe_wm_parameters *params,
* For both WM_PIPE and WM_LP.
* mem_value must be in 0.1us units.
*/
-static uint32_t ilk_compute_cur_wm(const struct hsw_pipe_wm_parameters *params,
+static uint32_t ilk_compute_cur_wm(const struct ilk_pipe_wm_parameters *params,
uint32_t mem_value)
{
if (!params-active || !params-cur.enabled)
@@ -1809,7 +1809,7 @@ static uint32_t ilk_compute_cur_wm(const struct
hsw_pipe_wm_parameters *params,
}
/* Only for WM_LP. */
-static uint32_t ilk_compute_fbc_wm(const struct hsw_pipe_wm_parameters *params,
+static uint32_t ilk_compute_fbc_wm(const struct ilk_pipe_wm_parameters *params,
uint32_t pri_val)
{
if (!params-active || !params-pri.enabled)
@@ -1914,7 +1914,7 @@ static void ilk_compute_wm_maximums(struct drm_device
*dev,
int level,
const struct intel_wm_config *config,
enum intel_ddb_partitioning
ddb_partitioning,
- struct hsw_wm_maximums *max)
+ struct ilk_wm_maximums *max)
{
max-pri = ilk_plane_wm_max(dev, level, config, ddb_partitioning,
false);
max-spr = ilk_plane_wm_max(dev, level, config, ddb_partitioning, true);
@@ -1923,7 +1923,7 @@ static void ilk_compute_wm_maximums(struct drm_device
*dev,
}
static bool ilk_validate_wm_level(int level,
- const struct hsw_wm_maximums *max,
+ const struct ilk_wm_maximums *max,
struct intel_wm_level *result)
{
bool ret;
@@ -1965,7 +1965,7 @@ static bool ilk_validate_wm_level(int level,
static void ilk_compute_wm_level(struct drm_i915_private *dev_priv,
int level,
-const struct hsw_pipe_wm_parameters *p,
+const struct ilk_pipe_wm_parameters *p,
struct intel_wm_level *result)
{
uint16_t pri_latency = dev_priv-wm.pri_latency[level];
@@ -2113,8 +2113,8 @@ static void intel_setup_wm_latency(struct drm_device *dev)
Re: [Intel-gfx] [PATCH 3/3] drm/i915: s/haswell_update_wm/ilk_update_wm/
2013/12/17 Imre Deak imre.d...@intel.com:
We use this hook starting from ILK onwards, so change the prefix
accordingly. Also rename functions/struct names used from
haswell_update_wm that are relevant to ILK already.
No functional change.
As I mentioned on IRC, my only worry is how many conflicts we're going
to cause with Ville's local WM patches (I don't know how many he still
has). But the 3 patches look correct, so, for all of them:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_pm.c | 86
-
2 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53288f6..bce647f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1215,7 +1215,7 @@ struct intel_wm_level {
uint32_t fbc_val;
};
-struct hsw_wm_values {
+struct ilk_wm_values {
uint32_t wm_pipe[3];
uint32_t wm_lp[3];
uint32_t wm_lp_spr[3];
@@ -1521,7 +1521,7 @@ typedef struct drm_i915_private {
uint16_t cur_latency[5];
/* current hardware state */
- struct hsw_wm_values hw;
+ struct ilk_wm_values hw;
} wm;
struct i915_package_c8 pc8;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f402c16..fccd7a8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1716,7 +1716,7 @@ static uint32_t ilk_wm_fbc(uint32_t pri_val, uint32_t
horiz_pixels,
return DIV_ROUND_UP(pri_val * 64, horiz_pixels * bytes_per_pixel) + 2;
}
-struct hsw_pipe_wm_parameters {
+struct ilk_pipe_wm_parameters {
bool active;
uint32_t pipe_htotal;
uint32_t pixel_rate;
@@ -1725,7 +1725,7 @@ struct hsw_pipe_wm_parameters {
struct intel_plane_wm_parameters cur;
};
-struct hsw_wm_maximums {
+struct ilk_wm_maximums {
uint16_t pri;
uint16_t spr;
uint16_t cur;
@@ -1743,7 +1743,7 @@ struct intel_wm_config {
* For both WM_PIPE and WM_LP.
* mem_value must be in 0.1us units.
*/
-static uint32_t ilk_compute_pri_wm(const struct hsw_pipe_wm_parameters
*params,
+static uint32_t ilk_compute_pri_wm(const struct ilk_pipe_wm_parameters
*params,
uint32_t mem_value,
bool is_lp)
{
@@ -1772,7 +1772,7 @@ static uint32_t ilk_compute_pri_wm(const struct
hsw_pipe_wm_parameters *params,
* For both WM_PIPE and WM_LP.
* mem_value must be in 0.1us units.
*/
-static uint32_t ilk_compute_spr_wm(const struct hsw_pipe_wm_parameters
*params,
+static uint32_t ilk_compute_spr_wm(const struct ilk_pipe_wm_parameters
*params,
uint32_t mem_value)
{
uint32_t method1, method2;
@@ -1795,7 +1795,7 @@ static uint32_t ilk_compute_spr_wm(const struct
hsw_pipe_wm_parameters *params,
* For both WM_PIPE and WM_LP.
* mem_value must be in 0.1us units.
*/
-static uint32_t ilk_compute_cur_wm(const struct hsw_pipe_wm_parameters
*params,
+static uint32_t ilk_compute_cur_wm(const struct ilk_pipe_wm_parameters
*params,
uint32_t mem_value)
{
if (!params-active || !params-cur.enabled)
@@ -1809,7 +1809,7 @@ static uint32_t ilk_compute_cur_wm(const struct
hsw_pipe_wm_parameters *params,
}
/* Only for WM_LP. */
-static uint32_t ilk_compute_fbc_wm(const struct hsw_pipe_wm_parameters
*params,
+static uint32_t ilk_compute_fbc_wm(const struct ilk_pipe_wm_parameters
*params,
uint32_t pri_val)
{
if (!params-active || !params-pri.enabled)
@@ -1914,7 +1914,7 @@ static void ilk_compute_wm_maximums(struct drm_device
*dev,
int level,
const struct intel_wm_config *config,
enum intel_ddb_partitioning
ddb_partitioning,
- struct hsw_wm_maximums *max)
+ struct ilk_wm_maximums *max)
{
max-pri = ilk_plane_wm_max(dev, level, config, ddb_partitioning,
false);
max-spr = ilk_plane_wm_max(dev, level, config, ddb_partitioning,
true);
@@ -1923,7 +1923,7 @@ static void ilk_compute_wm_maximums(struct drm_device
*dev,
}
static bool ilk_validate_wm_level(int level,
- const struct hsw_wm_maximums *max,
+ const struct ilk_wm_maximums *max,
struct intel_wm_level *result)
{
bool ret;
@@ -1965,7 +1965,7 @@ static bool ilk_validate_wm_level(int level,
static void ilk_compute_wm_level(struct drm_i915_private *dev_priv,
[Intel-gfx] [PATCH] fbcon: Avoid corrupting active workqueue entries
We attempt to reschedule an active work which can itself corrupt the
workqueue lists, and we may then free the work item whilst the task is
still pending. Both of these may lead to a system deadlock and an
unresponsive machine without any outputs for a panic to even be shown.
[7.372961] WARNING: at kernel/workqueue.c:1365 __queue_work+0x216/0x292()
[7.372964] Modules linked in: coretemp arc4 kvm_intel kvm iwldvm
crc32c_intel mac80211 ghash_clmulni_intel cryptd joydev hid_lenovo_tpkbd
lib80211 iTCO_wdt iwlwifi iTCO_vendor_support i915(+) btusb snd_hda_codec_hdmi
bluetooth evdev snd_hda_intel usbhid snd_hda_codec pcspkr hid cfg80211
microcode snd_hwdep i2c_i801 snd_pcm drm_kms_helper lpc_ich drm mfd_core
snd_page_alloc rfkill snd_timer snd soundcore mei_me i2c_algo_bit video mei
acpi_cpufreq mperf i2c_core button processor ext4 crc16 jbd2 mbcache sg sd_mod
crc_t10dif ahci libahci libata scsi_mod thermal fan ehci_pci ehci_hcd
thermal_sys usbcore usb_common
[7.373068] CPU: 0 PID: 660 Comm: ps Not tainted 3.10.9+ #55
[7.373071] Hardware name: /D33217CK, BIOS
GKPPT10H.86A.0025.2012.1011.1534 10/11/2012
[7.373075] 81596a1e 88045f203d38 813eaef6
88045f203d78
[7.373083] 81041027 88045f203d78
88045f217f00
[7.373091] 88044a89c800 88042b473aa0
88045f203d88
[7.373098] Call Trace:
[7.373101] IRQ [813eaef6] dump_stack+0x19/0x1b
[7.373115] [81041027] warn_slowpath_common+0x62/0x7b
[7.373121] [81041055] warn_slowpath_null+0x15/0x17
[7.373127] [8105aa82] __queue_work+0x216/0x292
[7.373133] [8105ab65] queue_work_on+0x4c/0x7c
[7.373140] [8123cebb] ? fbcon_add_cursor_timer+0xfb/0xfb
[7.373146] [8123cee1] cursor_timer_handler+0x26/0x42
[7.373153] [8104ee1f] call_timer_fn+0xcc/0x1ea
[7.373160] [8104ed53] ? detach_if_pending+0x7a/0x7a
[7.373166] [8123cebb] ? fbcon_add_cursor_timer+0xfb/0xfb
[7.373172] [8104f27b] run_timer_softirq+0x19c/0x1e4
[7.373178] [8104874e] ? __do_softirq+0x9e/0x2a7
[7.373183] [810487e9] __do_softirq+0x139/0x2a7
[7.373189] [81048a7a] irq_exit+0x56/0x9b
[7.373196] [8102af31] smp_apic_timer_interrupt+0x77/0x85
[7.373203] [813f5ff2] apic_timer_interrupt+0x72/0x80
[7.373206] EOI [8113ea70] ? spin_lock+0x9/0xb
[7.373217] [8120d8c1] ? do_raw_spin_trylock+0x42/0x42
[7.373223] [813ef2e0] ? _raw_spin_unlock+0x23/0x36
[7.373229] [8113ea7b] spin_unlock+0x9/0xb
[7.373235] [8113fd25] dput+0xd9/0xf8
[7.373241] [8113685e] path_put+0x13/0x20
[7.373247] [8113a6f3] do_last+0x925/0xa0d
[7.373253] [81137fa4] ? inode_permission+0x40/0x42
[7.373259] [8113a89c] path_openat+0xc1/0x325
[7.373265] [8113ae0c] do_filp_open+0x33/0x81
[7.373271] [811455bd] ? __alloc_fd+0x169/0x17b
[7.373279] [8112d78f] do_sys_open+0x67/0xf4
[7.373285] [8112d839] SyS_open+0x1d/0x1f
[7.373290] [813f5369] system_call_fastpath+0x16/0x1b
[7.373294] ---[ end trace 78bba0b9776072a9 ]---
[7.538936] fbcon: inteldrmfb (fb0) is primary device
[7.539446] Console: switching consoles 2-6 to frame buffer device
[7.539463] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[7.539468] i915 :00:02.0: registered panic notifier
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72765
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: sta...@vger.kernel.org
---
drivers/video/console/fbcon.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index cd8a8027f8ae..f474976f6b34 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -397,6 +397,8 @@ static void fb_flashcursor(struct work_struct *work)
ops-cursor(vc, info, mode, softback_lines, get_color(vc, info, c, 1),
get_color(vc, info, c, 0));
console_unlock();
+
+ mod_timer(ops-cursor_timer, jiffies + HZ/5);
}
static void cursor_timer_handler(unsigned long dev_addr)
@@ -405,7 +407,6 @@ static void cursor_timer_handler(unsigned long dev_addr)
struct fbcon_ops *ops = info-fbcon_par;
queue_work(system_power_efficient_wq, info-queue);
- mod_timer(ops-cursor_timer, jiffies + HZ/5);
}
static void fbcon_add_cursor_timer(struct fb_info *info)
@@ -417,6 +418,8 @@ static void fbcon_add_cursor_timer(struct fb_info *info)
!fbcon_cursor_noblink) {
if (!info-queue.func)
[Intel-gfx] [PATCH] drm/i915: Use the correct GMCH_CTRL register for Sandybridge+
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.
Note that the register is still marked as locked RO on Sandybridge, so
vgaarb is still dysfunctional.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jani Nikula jani.nik...@linux.intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7db292c469af..9caf6a879f31 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11334,9 +11334,10 @@ void intel_connector_attach_encoder(struct
intel_connector *connector,
int intel_modeset_vga_set_state(struct drm_device *dev, bool state)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned reg = INTEL_INFO(dev)-gen = 6 ? SNB_GMCH_CTRL :
INTEL_GMCH_CTRL;
u16 gmch_ctrl;
- if (pci_read_config_word(dev_priv-bridge_dev, INTEL_GMCH_CTRL,
gmch_ctrl)) {
+ if (pci_read_config_word(dev_priv-bridge_dev, reg, gmch_ctrl)) {
DRM_ERROR(failed to read control word\n);
return -EIO;
}
@@ -11346,7 +11347,7 @@ int intel_modeset_vga_set_state(struct drm_device *dev,
bool state)
else
gmch_ctrl |= INTEL_GMCH_VGA_DISABLE;
- if (pci_write_config_word(dev_priv-bridge_dev, INTEL_GMCH_CTRL,
gmch_ctrl)) {
+ if (pci_write_config_word(dev_priv-bridge_dev, reg, gmch_ctrl)) {
DRM_ERROR(failed to write control word\n);
return -EIO;
}
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/1] drm/i915: Verify address field of PCBR register.
From: Deepak S deepa...@intel.com
RC6 should be enabled only if the PCBR register is programmed properly by
either BIOS or Gfx. This patches address the case where PCBR allocation
fails due buggy BIOS or due to stolen memory allocation fails.
v2: Add #define for magic numbers (Daniel)
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 9 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f1eece4..1e4c693a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4982,6 +4982,7 @@
#define GEN6_GT_GFX_RC60x138108
#define GEN6_GT_GFX_RC6p 0x13810C
#define GEN6_GT_GFX_RC6pp 0x138110
+#define VLV_PCBR_ADDR_MASK 12
#define GEN6_PCODE_MAILBOX 0x138124
#define GEN6_PCODE_READY (131)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bcb8470..abf73f3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4073,7 +4073,7 @@ static void valleyview_enable_rps(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_ring_buffer *ring;
- u32 gtfifodbg, val, rc6_mode = 0;
+ u32 gtfifodbg, val, rc6_mode = 0, pcbr;
int i;
WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
@@ -4118,7 +4118,12 @@ static void valleyview_enable_rps(struct drm_device *dev)
_MASKED_BIT_ENABLE(VLV_COUNT_RANGE_HIGH |
VLV_MEDIA_RC6_COUNT_EN |
VLV_RENDER_RC6_COUNT_EN));
- if (intel_enable_rc6(dev) INTEL_RC6_ENABLE)
+
+ /* Enable RC6 Only if the PCBR address is configured either by
+* BIOS or Gfx Driver */
+ pcbr = I915_READ(VLV_PCBR);
+ if (intel_enable_rc6(dev) INTEL_RC6_ENABLE
+ (pcbr VLV_PCBR_ADDR_MASK))
rc6_mode = GEN7_RC_CTL_TO_MODE | VLV_RC_CTL_CTX_RST_PARALLEL;
intel_print_rc6_info(dev, rc6_mode);
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/1] drm/i915: Bring UP Power Wells before disabling RC6.
From: Deepak S deepa...@intel.com
we're doing forcewake before Disabling RC6, This what the BIOS expects
when going into suspend.
v2: updated commit message (Daniel)
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index abf73f3..ca7b537 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3662,8 +3662,14 @@ static void valleyview_disable_rps(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ /* we're doing forcewake before Disabling RC6,
+* This what the BIOS expects when going into suspend */
+ gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
+
I915_WRITE(GEN6_RC_CONTROL, 0);
+ gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
+
gen6_disable_rps_interrupts(dev);
if (dev_priv-vlv_pctx) {
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915: set min delay to rpe delay (Efficient frequency).
From: Deepak S deepa...@intel.com We use RPe here since it should match the Vmin we were shooting for. That should give us better perf than if we used the min freq available. System thermal can take the system to lowest possible freq (RPn). We are making sure, we calmp the freq to min_delay (RPe). Signed-off-by: Deepak S deepa...@intel.com --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ca7b537..7c98694 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4157,7 +4157,7 @@ static void valleyview_enable_rps(struct drm_device *dev) vlv_gpu_freq(dev_priv, dev_priv-rps.rpe_delay), dev_priv-rps.rpe_delay); - dev_priv-rps.min_delay = valleyview_rps_min_freq(dev_priv); + dev_priv-rps.min_delay = dev_priv-rps.rpe_delay; DRM_DEBUG_DRIVER(min GPU freq: %d MHz (%u)\n, vlv_gpu_freq(dev_priv, dev_priv-rps.min_delay), dev_priv-rps.min_delay); -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915: WA to fix Voltage not getting dropped to Vmin when Gfx is power gated.
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPe, it might fail since the
Gfx clocks are down.
So to fix this in Gfx idel,Bring the GFX clock up and set the freq to
RPe then move GFx down.
v2: remove vlv_update_rps_cur_delay function. Update commit message (Daniel)
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/intel_pm.c | 61 -
3 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1a6cc69..8c9b3a1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -923,6 +923,8 @@ struct intel_gen6_power_mgmt {
bool enabled;
struct delayed_work delayed_resume_work;
+ bool gfx_clk_down;
+
/*
* Protects RPS/RC6 register access and PCU communication.
* Must be taken after struct_mutex if nested.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1e4c693a..0a19219 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4974,6 +4974,10 @@
GEN6_PM_RP_DOWN_THRESHOLD | \
GEN6_PM_RP_DOWN_TIMEOUT)
+#define VLV_GTLC_SURVIVABILITY_REG 0x130098
+#define VLV_GFX_CLK_STATUS_BIT (13)
+#define VLV_GFX_CLK_FORCE_ON_BIT (12)
+
#define GEN6_GT_GFX_RC6_LOCKED 0x138104
#define VLV_COUNTER_CONTROL0x138104
#define VLV_COUNT_RANGE_HIGH (115)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e6e933b..adda054 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3581,12 +3581,70 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
trace_intel_gpu_freq_change(val * 50);
}
+/* vlv_set_rps_idle: Set the frequency to Rpe if Gfx clocks are down
+ *
+ * If Gfx clock is UP, then reset the timer as there is a possibility
+ * that normal Turbo logic can bring down the freq to Rpe.
+ * If Gfx clock is Down, then
+ * 1. Mask Turbo interrupts
+ * 2. Bring up Gfx clock
+ * 3. Change the freq to Rpe and wait till P-Unit updates freq
+ * 4. Clear the Force GFX CLK ON bit so that Gfx can down
+ * 5. Unmask Turbo interrupts
+*/
+static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
+{
+
+ /*
+* When we are idle. Drop to min voltage state.
+* Note: we use RPe here since it should match the
+* Vmin we were shooting for. That should give us better
+* perf when we come back out of RC6 than if we used the
+* min freq available.
+*/
+
+ if (dev_priv-rps.cur_delay = dev_priv-rps.rpe_delay)
+ return;
+
+ if (!(I915_READ(VLV_GTLC_SURVIVABILITY_REG) VLV_GFX_CLK_STATUS_BIT))
+ dev_priv-rps.gfx_clk_down = true;
+
+ /* Mask turbo interrupt so that they will not come in between */
+ if (dev_priv-rps.gfx_clk_down)
+ I915_WRITE(GEN6_PMINTRMSK, 0x);
+
+ /* Bring up the Gfx clock */
+ I915_WRITE(VLV_GTLC_SURVIVABILITY_REG,
+ I915_READ(VLV_GTLC_SURVIVABILITY_REG) |
+ VLV_GFX_CLK_FORCE_ON_BIT);
+
+ if (wait_for_atomic(((VLV_GFX_CLK_STATUS_BIT
+ I915_READ(VLV_GTLC_SURVIVABILITY_REG)) != 0), 500)) {
+ DRM_ERROR(GFX_CLK_ON request timed out\n);
+ return;
+ }
+
+ valleyview_set_rps(dev_priv-dev, dev_priv-rps.rpe_delay);
+
+ /* Release the Gfx clock */
+ I915_WRITE(VLV_GTLC_SURVIVABILITY_REG,
+ I915_READ(VLV_GTLC_SURVIVABILITY_REG)
+ ~VLV_GFX_CLK_FORCE_ON_BIT);
+
+ /* Unmask Turbo interrupts */
+ if (dev_priv-rps.gfx_clk_down)
+ I915_WRITE(GEN6_PMINTRMSK, ~GEN6_PM_RPS_EVENTS);
+
+ dev_priv-rps.gfx_clk_down = false;
+}
+
+
void gen6_rps_idle(struct drm_i915_private *dev_priv)
{
mutex_lock(dev_priv-rps.hw_lock);
if (dev_priv-rps.enabled) {
if (dev_priv-info-is_valleyview)
- valleyview_set_rps(dev_priv-dev,
dev_priv-rps.min_delay);
+ vlv_set_rps_idle(dev_priv);
else
gen6_set_rps(dev_priv-dev, dev_priv-rps.min_delay);
dev_priv-rps.last_adj = 0;
@@ -4826,6 +4884,7 @@ void intel_gpu_ips_teardown(void)
i915_mch_dev = NULL;
spin_unlock_irq(mchdev_lock);
}
+
static void intel_init_emon(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.8.4.2
[Intel-gfx] [PATCH v2 0/3] Fixes for vlv turbo.
From: Deepak S deepa...@intel.com This patch includes 1. set min delay to rpe delay (Efficient frequency) for better performace. 2. Disable/Enable PM Intrrupts based on the current freq. 3. WA to fix Voltage is not getting dropped to Vmin when Gfx is power gated Deepak S (5): drm/i915: set min delay to rpe delay (Efficient frequency). drm/i915: Disable/Enable PM Intrrupts based on the current freq. drm/i915: WA to fix Voltage not getting dropped to Vmin when Gfx is power gated. drivers/gpu/drm/i915/i915_drv.h | 5 +++ drivers/gpu/drm/i915/i915_irq.c | 31 +++- drivers/gpu/drm/i915/i915_reg.h | 5 +++ drivers/gpu/drm/i915/intel_pm.c | 81 +++-- 4 files changed, 116 insertions(+), 6 deletions(-) -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: Disable/Enable PM Intrrupts based on the current freq.
From: Deepak S deepa...@intel.com
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for PM DOWN THRESHOLD INTRRUPTS.
v2: Use bool variables (Daniel)
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_irq.c | 31 +--
drivers/gpu/drm/i915/intel_pm.c | 3 +++
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c638547..1a6cc69 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -914,6 +914,9 @@ struct intel_gen6_power_mgmt {
u8 rp0_delay;
u8 hw_max;
+ bool rp_up_masked;
+ bool rp_down_masked;
+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1d44c79..9dd65a8 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -988,7 +988,20 @@ static void gen6_pm_rps_work(struct work_struct *work)
adj *= 2;
else
adj = 1;
- new_delay = dev_priv-rps.cur_delay + adj;
+
+ if (dev_priv-rps.cur_delay = dev_priv-rps.max_delay) {
+ I915_WRITE(GEN6_PMINTRMSK,
+ I915_READ(GEN6_PMINTRMSK) | 1 5);
+ dev_priv-rps.rp_up_masked = true;
+ new_delay = dev_priv-rps.cur_delay;
+ } else
+ new_delay = dev_priv-rps.cur_delay + adj;
+
+ if (dev_priv-rps.rp_down_masked) {
+ I915_WRITE(GEN6_PMINTRMSK,
+ I915_READ(GEN6_PMINTRMSK) | ~(1 4));
+ dev_priv-rps.rp_down_masked = false;
+ }
/*
* For better performance, jump directly
@@ -1007,7 +1020,21 @@ static void gen6_pm_rps_work(struct work_struct *work)
adj *= 2;
else
adj = -1;
- new_delay = dev_priv-rps.cur_delay + adj;
+
+ if (dev_priv-rps.cur_delay = dev_priv-rps.max_delay) {
+ I915_WRITE(GEN6_PMINTRMSK,
+ I915_READ(GEN6_PMINTRMSK) | 1 4);
+ dev_priv-rps.rp_down_masked = true;
+ new_delay = dev_priv-rps.cur_delay;
+ } else
+ new_delay = dev_priv-rps.cur_delay + adj;
+
+ if (dev_priv-rps.rp_up_masked) {
+ I915_WRITE(GEN6_PMINTRMSK,
+ I915_READ(GEN6_PMINTRMSK) | ~(1 5));
+ dev_priv-rps.rp_up_masked = false;
+ }
+
} else { /* unknown event */
new_delay = dev_priv-rps.cur_delay;
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7c98694..e6e933b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4166,6 +4166,9 @@ static void valleyview_enable_rps(struct drm_device *dev)
vlv_gpu_freq(dev_priv, dev_priv-rps.rpe_delay),
dev_priv-rps.rpe_delay);
+ dev_priv-rps.rp_up_masked = 0;
+ dev_priv-rps.rp_down_masked = 0;
+
valleyview_set_rps(dev_priv-dev, dev_priv-rps.rpe_delay);
gen6_enable_rps_interrupts(dev);
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: set min delay to rpe delay (Efficient frequency).
On Tue, Dec 17, 2013 at 08:35:39PM +0530, deepa...@intel.com wrote: From: Deepak S deepa...@intel.com We use RPe here since it should match the Vmin we were shooting for. That should give us better perf than if we used the min freq available. System thermal can take the system to lowest possible freq (RPn). We are making sure, we calmp the freq to min_delay (RPe). Signed-off-by: Deepak S deepa...@intel.com Nak. Read the code, explain how it currently fails. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Disable/Enable PM Intrrupts based on the current freq.
On Tue, Dec 17, 2013 at 08:35:40PM +0530, deepa...@intel.com wrote: From: Deepak S deepa...@intel.com When current delay is already at max delay, Let's disable the PM UP THRESHOLD INTRRUPTS, so that we will not get further interrupts until current delay is less than max delay, Also request for the PM DOWN THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and viceversa for PM DOWN THRESHOLD INTRRUPTS. v2: Use bool variables (Daniel) Signed-off-by: Deepak S deepa...@intel.com Nak. Why not do this with the rest of the threshold interrupt adjusting code? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use the correct GMCH_CTRL register for Sandybridge+
On Tue, 17 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.
Note that the register is still marked as locked RO on Sandybridge, so
vgaarb is still dysfunctional.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jani Nikula jani.nik...@linux.intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7db292c469af..9caf6a879f31 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11334,9 +11334,10 @@ void intel_connector_attach_encoder(struct
intel_connector *connector,
int intel_modeset_vga_set_state(struct drm_device *dev, bool state)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned reg = INTEL_INFO(dev)-gen = 6 ? SNB_GMCH_CTRL :
INTEL_GMCH_CTRL;
u16 gmch_ctrl;
- if (pci_read_config_word(dev_priv-bridge_dev, INTEL_GMCH_CTRL,
gmch_ctrl)) {
+ if (pci_read_config_word(dev_priv-bridge_dev, reg, gmch_ctrl)) {
DRM_ERROR(failed to read control word\n);
return -EIO;
}
@@ -11346,7 +11347,7 @@ int intel_modeset_vga_set_state(struct drm_device
*dev, bool state)
else
gmch_ctrl |= INTEL_GMCH_VGA_DISABLE;
- if (pci_write_config_word(dev_priv-bridge_dev, INTEL_GMCH_CTRL,
gmch_ctrl)) {
+ if (pci_write_config_word(dev_priv-bridge_dev, reg, gmch_ctrl)) {
DRM_ERROR(failed to write control word\n);
return -EIO;
}
--
1.8.5.1
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] S3 resume and commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
On Tue, 17 Dec 2013 10:52:06 +0100 Daniel Vetter daniel.vet...@ffwll.ch wrote: On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King colin.k...@canonical.com wrote: Hi there, There is a S3 resume issue that affects HP Mini Atom N270 with Intel Mobile 945GSE on Linux 3.9.0 upwards. Device: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:361a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe98 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at dc80 [size=8] Region 2: Memory at d000 (32-bit, prefetchable) [size=256M] Region 3: Memory at fe94 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 Issue: On S3 resume screen is blank. I've tracked this down to 2 patches: 1. 24576d23976746cb52e7700c4cadbf4bc1bc3472 drm/i915: enable VT switchless resume v3 This commit stops the screen from turning back on. Without the patch the screen resumes back to on, however it is filled with random vertical lines. 2. fa55583797d12b10928a1813f3dcf066637caf5e drm/i915: fixup the plane-pipe fixup code I have to manually revert this. If I don't I get the random vertical lines on resume. Any ideas on how to address these two issues that cause S3 resume to leave the HP mini in a broken state? Please file a bug report on bugs.freedesktop.org against DRI - DRM(Intel). Also please always cc relevant mailing lists when reporting kernel issues. Are you using X with a recent (well not ancient) X driver? Do you have any other console drivers built in, like vesafb? If you open a bug, please add the above info to that instead, we can track it there. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/15] [v2] Broadwell HW semaphore
On Tue, Dec 17, 2013 at 10:17:38AM +0100, Daniel Vetter wrote: On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote: Reposting this as a new series since two of the patches dropped off since last time. Functionally it's the same as before. Like before, the patch drm/i915: unleash semaphores on gen8 should probably not be merged as it's not 100% clear where the hang is currently coming from. Everything else should be pretty benign for other platforms. I've pulled in the first two patches already. For review Damien is signed up (althought he goes on vacation soon) and for greater learning experience he's also agreed to throw in a testcase on top. We already have a nice stresstest for semaphores (gem_ring_sync_loop), but no real functional test which checks that the batches are indeed correctly ordered. For gpu vs. cpu races we already have a fairly complete set in gem_concurrent_blt, but that has many additional complications we don't really care about for ring2ring syncing. For each pair of rings R1, R2 where we have copy support (i.e. blt, rendercpy and mediafill) do: mediafill and rendercopy both use the render ring, so only one of them is useful here, right? Might need to investigate similar blit batches for other rings, if possible at all. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] S3 resume and commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
On 17/12/13 16:30, Jesse Barnes wrote: On Tue, 17 Dec 2013 10:52:06 +0100 Daniel Vetter daniel.vet...@ffwll.ch wrote: On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King colin.k...@canonical.com wrote: Hi there, There is a S3 resume issue that affects HP Mini Atom N270 with Intel Mobile 945GSE on Linux 3.9.0 upwards. Device: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:361a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe98 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at dc80 [size=8] Region 2: Memory at d000 (32-bit, prefetchable) [size=256M] Region 3: Memory at fe94 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 Issue: On S3 resume screen is blank. I've tracked this down to 2 patches: 1. 24576d23976746cb52e7700c4cadbf4bc1bc3472 drm/i915: enable VT switchless resume v3 This commit stops the screen from turning back on. Without the patch the screen resumes back to on, however it is filled with random vertical lines. 2. fa55583797d12b10928a1813f3dcf066637caf5e drm/i915: fixup the plane-pipe fixup code I have to manually revert this. If I don't I get the random vertical lines on resume. Any ideas on how to address these two issues that cause S3 resume to leave the HP mini in a broken state? Please file a bug report on bugs.freedesktop.org against DRI - DRM(Intel). Also please always cc relevant mailing lists when reporting kernel issues. Are you using X with a recent (well not ancient) X driver? xserver-org-video-intel, 2:2.99.904-0ubuntu2 Do you have any other console drivers built in, like vesafb? None that I can observe. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device
We want to disable the (unused) VGA plane on the intel hardware, which
should be a simple matter of writing the vga control register. However,
in 2009 (commit 24f119c769bacac5729297b682fec7811a983cc6), that simple
code was changed to also smash the SR01 VGA register to fix random
crash and lockups.
When running efifb on an nVidia card, executing this store to SR01
ends up causing the screen to go black.
I'm not sure if this store is still required; this patch limits it to
when the intel card is primary.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c714d4d..545b271 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9038,12 +9038,14 @@ static void i915_disable_vga(struct drm_device *dev)
u8 sr1;
u32 vga_reg = i915_vgacntrl_reg(dev);
- vga_get_uninterruptible(dev-pdev, VGA_RSRC_LEGACY_IO);
- outb(SR01, VGA_SR_INDEX);
- sr1 = inb(VGA_SR_DATA);
- outb(sr1 | 15, VGA_SR_DATA);
- vga_put(dev-pdev, VGA_RSRC_LEGACY_IO);
- udelay(300);
+ if (dev-pdev == vga_default_device()) {
+ vga_get_uninterruptible(dev-pdev, VGA_RSRC_LEGACY_IO);
+ outb(SR01, VGA_SR_INDEX);
+ sr1 = inb(VGA_SR_DATA);
+ outb(sr1 | 15, VGA_SR_DATA);
+ vga_put(dev-pdev, VGA_RSRC_LEGACY_IO);
+ udelay(300);
+ }
I915_WRITE(vga_reg, VGA_DISP_DISABLE);
POSTING_READ(vga_reg);
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device
On Tue, Dec 17, 2013 at 09:12:10AM -0800, Keith Packard wrote: We want to disable the (unused) VGA plane on the intel hardware, which should be a simple matter of writing the vga control register. However, in 2009 (commit 24f119c769bacac5729297b682fec7811a983cc6), that simple code was changed to also smash the SR01 VGA register to fix random crash and lockups. When running efifb on an nVidia card, executing this store to SR01 ends up causing the screen to go black. I'm not sure if this store is still required; this patch limits it to when the intel card is primary. The bspec still says we must assert SR01 bit5 prior to disabling the VGA plane. Perhaps the test should be whether (vga_reg VGA_DISP_DISABLE) == 0 and do nothing if the plane is already off. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC hax: drm/i915: Kick out vga console
On Mon, Dec 16, 2013 at 06:07:14PM -0200, Paulo Zanoni wrote: 2013/12/16 Daniel Vetter dan...@ffwll.ch: On Mon, Dec 16, 2013 at 05:19:25PM +, Chris Wilson wrote: Touching the VGA resources on an IVB EFI machine causes hard hangs when we then kick out the efifb. Ouch. Please take a look at arch/x86/kernel/setup.c, at the end of function setup_arch: #ifdef CONFIG_VT #if defined(CONFIG_VGA_CONSOLE) if (!efi_enabled(EFI_BOOT) || (efi_mem_type(0xa) != EFI_CONVENTIONAL_MEMORY)) conswitchp = vga_con; #elif defined(CONFIG_DUMMY_CONSOLE) conswitchp = dummy_con; #endif #endif Shouldn't this code already be doing what you want on IVB? Perhaps we could improve it to do what you want? Yes. I jumped to the wrong conclusion, and double checking after uninstalling efifb we default to the dummy console. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Like I've said on irc I think we want a select DUMMY_CONSOLE here, at least if none of the core developers objects. And we also need this (or something similar) to make Paulo happy, this should fix unclaimed register disasters due to vgacon accessing the dead vga ranges when unloading our driver on hsw while pc8/D3 is in effect. Paulo, can you please give this a spin - you need to make sure that CONFIG_DUMMY_CONSOLE is set though, so that needs some magic. I teste the patch, it does the required magic to solve the remaining problem :) Care to write a real changelog describing the problem this actually solves then? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device
Chris Wilson ch...@chris-wilson.co.uk writes: The bspec still says we must assert SR01 bit5 prior to disabling the VGA plane. Perhaps the test should be whether (vga_reg VGA_DISP_DISABLE) == 0 and do nothing if the plane is already off. The problem is that for some reason we're smashing *some other video card* when it's being used via efifb. I'm wondering if vgaarb just doesn't work because efifb isn't telling vgaarb that it's using those registers (I mean, how would it even know?) The other simple option is to just not disable VGA if the card isn't primary; presumably it wasn't ever enabled. And, yes, I know that the card probably won't work at all if it isn't primary because so much currently depends on the BIOS setting up bits of the card that we can't autodetect. So, another simple option would be to just refuse to load the driver if the card is secondary... -- keith.pack...@intel.com pgpLLmW0aJ7ID.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/15] [v2] Broadwell HW semaphore
On Tue, Dec 17, 2013 at 04:29:56PM +, Damien Lespiau wrote: On Tue, Dec 17, 2013 at 10:17:38AM +0100, Daniel Vetter wrote: On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote: Reposting this as a new series since two of the patches dropped off since last time. Functionally it's the same as before. Like before, the patch drm/i915: unleash semaphores on gen8 should probably not be merged as it's not 100% clear where the hang is currently coming from. Everything else should be pretty benign for other platforms. I've pulled in the first two patches already. For review Damien is signed up (althought he goes on vacation soon) and for greater learning experience he's also agreed to throw in a testcase on top. We already have a nice stresstest for semaphores (gem_ring_sync_loop), but no real functional test which checks that the batches are indeed correctly ordered. For gpu vs. cpu races we already have a fairly complete set in gem_concurrent_blt, but that has many additional complications we don't really care about for ring2ring syncing. For each pair of rings R1, R2 where we have copy support (i.e. blt, rendercpy and mediafill) do: mediafill and rendercopy both use the render ring, so only one of them is useful here, right? Oh dear, somehow I've thought that was launched on the vcs like a compute job. So yeah, we can only test between blt and render then. I guess I should read the patches more carefully ;-) Might need to investigate similar blit batches for other rings, if possible at all. Yeah, otoh we should be able to test the general logic with this. And if there's a type somewhere in the vcs/vecs tables, well mea culpa. -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 1/2] drm/i915: move psr_setup_done to psr struct
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53288f6..cae3225 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -715,6 +715,7 @@ struct i915_fbc {
struct i915_psr {
bool sink_support;
bool source_ok;
+ bool setup_done;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9b40113..f062a59 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1567,7 +1567,7 @@ static void intel_edp_psr_setup(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct edp_vsc_psr psr_vsc;
- if (intel_dp-psr_setup_done)
+ if (dev_priv-psr.setup_done)
return;
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
@@ -1582,7 +1582,7 @@ static void intel_edp_psr_setup(struct intel_dp *intel_dp)
I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
- intel_dp-psr_setup_done = true;
+ dev_priv-psr.setup_done = true;
}
static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
@@ -3702,7 +3702,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
WARN(error, intel_dp_i2c_init failed with error %d for port %c\n,
error, port_name(port));
- intel_dp-psr_setup_done = false;
+ dev_priv-psr.setup_done = false;
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
i2c_del_adapter(intel_dp-adapter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 46aea6c..f7b5b2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -485,7 +485,6 @@ struct intel_dp {
int backlight_off_delay;
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
- bool psr_setup_done;
struct intel_connector *attached_connector;
};
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915/bdw: poll semaphores
On Mon, Dec 16, 2013 at 08:50:47PM -0800, Ben Widawsky wrote: Signed-off-by: Ben Widawsky b...@bwidawsk.net Can you source this recommendation, even if just personal communication? Is this likely to be temporary? Will a difference (power, latency) ever be measurable? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: move psr_setup_done to psr struct
2013/12/17 Rodrigo Vivi rodrigo.v...@gmail.com:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53288f6..cae3225 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -715,6 +715,7 @@ struct i915_fbc {
struct i915_psr {
bool sink_support;
bool source_ok;
+ bool setup_done;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9b40113..f062a59 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1567,7 +1567,7 @@ static void intel_edp_psr_setup(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct edp_vsc_psr psr_vsc;
- if (intel_dp-psr_setup_done)
+ if (dev_priv-psr.setup_done)
return;
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
@@ -1582,7 +1582,7 @@ static void intel_edp_psr_setup(struct intel_dp
*intel_dp)
I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
- intel_dp-psr_setup_done = true;
+ dev_priv-psr.setup_done = true;
}
static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
@@ -3702,7 +3702,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
WARN(error, intel_dp_i2c_init failed with error %d for port %c\n,
error, port_name(port));
- intel_dp-psr_setup_done = false;
+ dev_priv-psr.setup_done = false;
This line is now weird because most systems will call
intel_dp_init_connector more than once, so we'll zero setup_done many
times. I don't see any bugs related to this, but we should probably
move this line to somewhere else. Or just remove this line and rely on
the fact that the struct is initialized as zero when allocated. It
seems sink_support and source_ok are not explicitly initialized, so we
should probably follow this model.
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
i2c_del_adapter(intel_dp-adapter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 46aea6c..f7b5b2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -485,7 +485,6 @@ struct intel_dp {
int backlight_off_delay;
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
- bool psr_setup_done;
struct intel_connector *attached_connector;
};
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Clarify automated test constant and add constant for FAUX test pattern
On Mon, 07 Oct 2013 11:05:57 +0300 Jani Nikula jani.nik...@linux.intel.com wrote: On Fri, 04 Oct 2013, Todd Previte tprev...@gmail.com wrote: - DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN to clarify - Added DP_TEST_LINK_FAUX_PATTERN to support automated testing of Fast AUX Signed-off-by: Todd Previte tprev...@gmail.com Reviewed-by: Jani Nikula jani.nik...@intel.com Did this ever go in? -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Add Baytrail PSR Support.
This patch adds PSR Support to Baytrail.
Baytrail cannot easily detect screen updates and force PSR exit.
So we inactivate it on busy_ioctl and update to get it back
on next display mark_idle.
The current issue with this implementation is the cursor updates.
(Yet to be fixed).
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 +++-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/i915_reg.h | 34
drivers/gpu/drm/i915/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/intel_display.c | 3 +
drivers/gpu/drm/i915/intel_dp.c | 156 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
8 files changed, 191 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6294ffd..b29543d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1816,6 +1816,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
u32 psrperf = 0;
+ u32 psrstatus;
bool enabled = false;
intel_runtime_pm_get(dev_priv);
@@ -1823,14 +1824,23 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, Sink_Support: %s\n, yesno(dev_priv-psr.sink_support));
seq_printf(m, Source_OK: %s\n, yesno(dev_priv-psr.source_ok));
- enabled = HAS_PSR(dev)
- I915_READ(EDP_PSR_CTL(dev)) EDP_PSR_ENABLE;
+ if (HAS_PSR(dev)) {
+ if (IS_VALLEYVIEW(dev)) {
+psrstatus = I915_READ(VLV_EDP_PSR_STATUS_CTL)
+ VLV_EDP_PSR_CURR_STATE_MASK;
+ enabled = ((psrstatus == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+ (psrstatus == VLV_EDP_PSR_ACTIVE_SF_UPDATE));
+ } else
+ enabled = I915_READ(EDP_PSR_CTL(dev)) EDP_PSR_ENABLE;
+ }
seq_printf(m, Enabled: %s\n, yesno(enabled));
- if (HAS_PSR(dev))
+ /* VLV PSR has no kind of performance counter */
+ if (HAS_PSR(dev) !IS_VALLEYVIEW(dev)) {
psrperf = I915_READ(EDP_PSR_PERF_CNT(dev))
EDP_PSR_PERF_CNT_MASK;
- seq_printf(m, Performance_Counter: %u\n, psrperf);
+ seq_printf(m, Performance_Counter: %u\n, psrperf);
+ }
intel_runtime_pm_put(dev_priv);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cae3225..916d243 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -716,6 +716,7 @@ struct i915_psr {
bool sink_support;
bool source_ok;
bool setup_done;
+ bool inactive;
};
enum intel_pch {
@@ -1851,7 +1852,8 @@ struct drm_i915_file_private {
#define HAS_DDI(dev) (INTEL_INFO(dev)-has_ddi)
#define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)-has_fpga_dbg)
-#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev))
+#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
+IS_VALLEYVIEW(dev))
#define HAS_PC8(dev) (IS_HASWELL(dev)) /* XXX HSW:ULX */
#define HAS_RUNTIME_PM(dev)(IS_HASWELL(dev))
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 32636a4..d0a5c27 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4048,6 +4048,9 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
if (ret)
return ret;
+ if (IS_VALLEYVIEW(dev))
+ intel_edp_psr_inactivate(dev);
+
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args-handle));
if (obj-base == NULL) {
ret = -ENOENT;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9548b1..c996e261 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1969,6 +1969,40 @@
#define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
#define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
+/* VLV eDP PSR registers */
+#define VLV_EDP_PSR_CTL(VLV_DISPLAY_BASE +
0x60090)
+#define VLV_EDP_PSR_ENABLE(10)
+#define VLV_EDP_PSR_RESET (11)
+#define VLV_EDP_PSR_MODE_MASK (72)
+#define VLV_EDP_PSR_MODE_HW_TIMER (13)
+#define VLV_EDP_PSR_MODE_SW_TIMER (12)
+#define VLV_EDP_PSR_SINGLE_FRAME_UPDATE (17)
+#define VLV_EDP_PSR_ACTIVE_ENTRY (18)
+#define VLV_EDP_PSR_SRC_TRANSMITTER_STATE (19)
+#define VLV_EDP_PSR_DBL_FRAME (110)
+#define VLV_EDP_PSR_FRAME_COUNT_MASK (0xff16)
[Intel-gfx] [PATCH 1/2] drm/i915: move psr_setup_done to psr struct
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53288f6..cae3225 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -715,6 +715,7 @@ struct i915_fbc {
struct i915_psr {
bool sink_support;
bool source_ok;
+ bool setup_done;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9b40113..f062a59 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1567,7 +1567,7 @@ static void intel_edp_psr_setup(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct edp_vsc_psr psr_vsc;
- if (intel_dp-psr_setup_done)
+ if (dev_priv-psr.setup_done)
return;
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
@@ -1582,7 +1582,7 @@ static void intel_edp_psr_setup(struct intel_dp *intel_dp)
I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
- intel_dp-psr_setup_done = true;
+ dev_priv-psr.setup_done = true;
}
static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
@@ -3702,7 +3702,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
WARN(error, intel_dp_i2c_init failed with error %d for port %c\n,
error, port_name(port));
- intel_dp-psr_setup_done = false;
+ dev_priv-psr.setup_done = false;
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
i2c_del_adapter(intel_dp-adapter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 46aea6c..f7b5b2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -485,7 +485,6 @@ struct intel_dp {
int backlight_off_delay;
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
- bool psr_setup_done;
struct intel_connector *attached_connector;
};
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add Baytrail PSR Support.
This patch adds PSR Support to Baytrail.
Baytrail cannot easily detect screen updates and force PSR exit.
So we inactivate it on busy_ioctl and update to get it back
on next display mark_idle.
v2: Also inactivate PSR on cursor update.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 +++-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/i915_reg.h | 34
drivers/gpu/drm/i915/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/intel_display.c | 6 ++
drivers/gpu/drm/i915/intel_dp.c | 156 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
8 files changed, 194 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6294ffd..b29543d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1816,6 +1816,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
u32 psrperf = 0;
+ u32 psrstatus;
bool enabled = false;
intel_runtime_pm_get(dev_priv);
@@ -1823,14 +1824,23 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, Sink_Support: %s\n, yesno(dev_priv-psr.sink_support));
seq_printf(m, Source_OK: %s\n, yesno(dev_priv-psr.source_ok));
- enabled = HAS_PSR(dev)
- I915_READ(EDP_PSR_CTL(dev)) EDP_PSR_ENABLE;
+ if (HAS_PSR(dev)) {
+ if (IS_VALLEYVIEW(dev)) {
+psrstatus = I915_READ(VLV_EDP_PSR_STATUS_CTL)
+ VLV_EDP_PSR_CURR_STATE_MASK;
+ enabled = ((psrstatus == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+ (psrstatus == VLV_EDP_PSR_ACTIVE_SF_UPDATE));
+ } else
+ enabled = I915_READ(EDP_PSR_CTL(dev)) EDP_PSR_ENABLE;
+ }
seq_printf(m, Enabled: %s\n, yesno(enabled));
- if (HAS_PSR(dev))
+ /* VLV PSR has no kind of performance counter */
+ if (HAS_PSR(dev) !IS_VALLEYVIEW(dev)) {
psrperf = I915_READ(EDP_PSR_PERF_CNT(dev))
EDP_PSR_PERF_CNT_MASK;
- seq_printf(m, Performance_Counter: %u\n, psrperf);
+ seq_printf(m, Performance_Counter: %u\n, psrperf);
+ }
intel_runtime_pm_put(dev_priv);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cae3225..916d243 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -716,6 +716,7 @@ struct i915_psr {
bool sink_support;
bool source_ok;
bool setup_done;
+ bool inactive;
};
enum intel_pch {
@@ -1851,7 +1852,8 @@ struct drm_i915_file_private {
#define HAS_DDI(dev) (INTEL_INFO(dev)-has_ddi)
#define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)-has_fpga_dbg)
-#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev))
+#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
+IS_VALLEYVIEW(dev))
#define HAS_PC8(dev) (IS_HASWELL(dev)) /* XXX HSW:ULX */
#define HAS_RUNTIME_PM(dev)(IS_HASWELL(dev))
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 32636a4..d0a5c27 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4048,6 +4048,9 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
if (ret)
return ret;
+ if (IS_VALLEYVIEW(dev))
+ intel_edp_psr_inactivate(dev);
+
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args-handle));
if (obj-base == NULL) {
ret = -ENOENT;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9548b1..c996e261 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1969,6 +1969,40 @@
#define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
#define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
+/* VLV eDP PSR registers */
+#define VLV_EDP_PSR_CTL(VLV_DISPLAY_BASE +
0x60090)
+#define VLV_EDP_PSR_ENABLE(10)
+#define VLV_EDP_PSR_RESET (11)
+#define VLV_EDP_PSR_MODE_MASK (72)
+#define VLV_EDP_PSR_MODE_HW_TIMER (13)
+#define VLV_EDP_PSR_MODE_SW_TIMER (12)
+#define VLV_EDP_PSR_SINGLE_FRAME_UPDATE (17)
+#define VLV_EDP_PSR_ACTIVE_ENTRY (18)
+#define VLV_EDP_PSR_SRC_TRANSMITTER_STATE (19)
+#define VLV_EDP_PSR_DBL_FRAME (110)
+#define VLV_EDP_PSR_FRAME_COUNT_MASK (0xff16)
+#define VLV_EDP_PSR_IDLE_FRAME_SHIFT
Re: [Intel-gfx] [PATCH 08/15] drm/i915/bdw: implement semaphore signal
On Mon, Dec 16, 2013 at 08:50:44PM -0800, Ben Widawsky wrote:
+static int gen8_rcs_signal(struct intel_ring_buffer *signaller,
+unsigned int num_dwords)
+{
+#define MBOX_UPDATE_DWORDS 8
+ struct drm_device *dev = signaller-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_ring_buffer *waiter;
+ int i, ret, num_rings;
+
+ num_rings = hweight_long(INTEL_INFO(dev)-ring_mask);
+ num_dwords = (num_rings-1) * MBOX_UPDATE_DWORDS;
+#undef MBOX_UPDATE_DWORDS
+
+ /* XXX: + 4 for the caller */
+ ret = intel_ring_begin(signaller, num_dwords + 4);
+ if (ret)
+ return ret;
You now pass down how many dwords the caller requires so it should just
be num_dwords += (num_rings - 1) * DWORDS_PER_MBOX; above.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
int intel_fbdev_init(struct drm_device *dev)
@@ -268,17 +461,25 @@ int intel_fbdev_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int ret;
- ifbdev = kzalloc(sizeof(*ifbdev), GFP_KERNEL);
- if (!ifbdev)
- return -ENOMEM;
+ /* This may fail, if so, dev_priv-fbdev won't be set below */
+ intel_fbdev_init_bios(dev);
- dev_priv-fbdev = ifbdev;
- ifbdev-helper.funcs = intel_fb_helper_funcs;
+ if ((ifbdev = dev_priv-fbdev) == NULL) {
+ ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
+ if (ifbdev == NULL)
+ return -ENOMEM;
+
+ ifbdev-helper.funcs = intel_fb_helper_funcs;
+ ifbdev-preferred_bpp = 32;
+
+ dev_priv-fbdev = ifbdev;
+ }
Since Daniel also mentioned the same bikeshed, I think this would look
neater with the allocation here and ifbdev being passed to
intel_fbdev_init_bios to fill in:
ifbdev = kzalloc(sizeof(*ifbdev), GFP_KERNEL);
if (ifbdev == NULL)
return -ENODEV;
if (!intel_fbdev_init_bios(dev, ifbdev)) {
ifbdev-helper.funcs = intel_fb_helper_funcs;
ifbdev-preferred_bpp = 32;
}
dev_priv-fbdev = ifbdev;
return 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
Re: [Intel-gfx] [PATCH 4/5] drm/i915: vlv: W/a for hotplug/manual VGA detection
On Sat, 2013-12-14 at 20:38 -0200, Rodrigo Vivi wrote: From: Imre Deak imre.d...@intel.com At least on my VLV stepping VGA detection doesn't work in certain cases. One such case is when all pipes are off and VGA is plugged in. Another case reported by Joonas Lahtinen (also on the same stepping) is booting with VGA disconnected where we incorrectly report that VGA is connected. At least in the first case writing the FORCE bit in the ADPA reg will get stuck, i.e. the detection never completes. Both cases seem to be solved by disabling DPIO clock gating based on the PSR state. As I haven't found any trace that this would be a known issue, I can only speculate that both the DPIO HW block and the HW block responsible for VGA detection uses the same clock source which gets gated even though PSR is inactive. I haven't measured if and how this change affects our power savings. Reported-by: Joonas Lahtinen joonas.lahti...@linux.intel.com Signed-off-by: Imre Deak imre.d...@intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com Please ignore this, I'll send a v2. --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_pm.c | 5 + 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index f1eece4..726c3ce 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1451,6 +1451,9 @@ # define I965_FT_CLOCK_GATE_DISABLE (1 1) # define I965_DM_CLOCK_GATE_DISABLE (1 0) +#define DPPSR_CGDIS_VLV(dev_priv-info-display_mmio_offset + 0x6204) +# define DPIOUNIT_PSR_CLOCK_GATING_DISABLE (1 6) + #define RENCLK_GATE_D2 0x6208 #define VF_UNIT_CLOCK_GATE_DISABLE (1 9) #define GS_UNIT_CLOCK_GATE_DISABLE (1 7) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 465304a..4208065 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5438,6 +5438,11 @@ static void valleyview_init_clock_gating(struct drm_device *dev) I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE); + /* Wa to make VGA hotplug and manual detection work. */ + val = I915_READ(DPPSR_CGDIS_VLV); + val |= DPIOUNIT_PSR_CLOCK_GATING_DISABLE; + I915_WRITE(DPIOUNIT_PSR_CLOCK_GATING_DISABLE, val); + /* WaDisableEarlyCull:vlv */ I915_WRITE(_3D_CHICKEN3, _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL)); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device
On Tue, Dec 17, 2013 at 10:17:24AM -0800, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: The bspec still says we must assert SR01 bit5 prior to disabling the VGA plane. Perhaps the test should be whether (vga_reg VGA_DISP_DISABLE) == 0 and do nothing if the plane is already off. The problem is that for some reason we're smashing *some other video card* when it's being used via efifb. Ok, so as no vgaarb_clients have yet been registered and so the call to grab the IO resource does not actually disable VGA IO routing to the nvidia card. I'm wondering if vgaarb just doesn't work because efifb isn't telling vgaarb that it's using those registers (I mean, how would it even know?) Agreed, that does seem to be the nub of the problem. The other simple option is to just not disable VGA if the card isn't primary; presumably it wasn't ever enabled. And, yes, I know that the card probably won't work at all if it isn't primary because so much currently depends on the BIOS setting up bits of the card that we can't autodetect. So, another simple option would be to just refuse to load the driver if the card is secondary... If you care to update the changelog to explain the problem is that vgaarb is ineffective before all clients are registered, then I think this is a good temporary hack. It should be possible for vgaarb to mark resources as locked if the device is interpretting IO access and has no method for disabling the IO grab (and then a vga_tryget() check here). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/15] drm/i915/bdw: implement semaphore wait
On Mon, Dec 16, 2013 at 08:50:45PM -0800, Ben Widawsky wrote: Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to wait on is all well defined by the table in the previous patch. There is nothing else different from previous GEN's semaphore synchronization code. v2: Update macros to not require the other ring's ring-id (Chris) Signed-off-by: Ben Widawsky b...@bwidawsk.net --- +/* seqno size is actually only a uint32, but since we plan to use MI_FLUSH_DW to + * do the writes, and that must have qw aligned offsets, simply pretend it's 8b. + */ +#define i915_semaphore_seqno_size sizeof(uint64_t) +#define GEN8_SIGNAL_OFFSET(to) \ + (i915_gem_obj_ggtt_offset(dev_priv-semaphore_obj) + \ + (ring-id * I915_NUM_RINGS * i915_semaphore_seqno_size) + \ + (i915_semaphore_seqno_size * (to))) + +#define GEN8_WAIT_OFFSET(__ring, from) \ + (i915_gem_obj_ggtt_offset(dev_priv-semaphore_obj) + \ + ((from) * I915_NUM_RINGS * i915_semaphore_seqno_size) + \ + (i915_semaphore_seqno_size * (__ring)-id)) Please sir, may I have #define GEN8_SEMAPHORE_OFFSET(from, to) \ (i915_gem_obj_ggtt_offset(dev_priv-semaphore_obj) + \ ((from) * I915_NUM_RINGS + (to)) * i915_semaphore_seqno_size) #define GEN8_SIGNAL_OFFSET(to) GEN8_SEMAPHORE_OFFSET(ring-id, to) #define GEN8_WAIT_OFFSET(from) GEN8_SEMAPHORE_OFFSET(from, ring-id) ? -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: move psr_setup_done to psr struct
On Tue, Dec 17, 2013 at 6:06 PM, Paulo Zanoni przan...@gmail.com wrote:
2013/12/17 Rodrigo Vivi rodrigo.v...@gmail.com:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 53288f6..cae3225 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -715,6 +715,7 @@ struct i915_fbc {
struct i915_psr {
bool sink_support;
bool source_ok;
+ bool setup_done;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 9b40113..f062a59 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1567,7 +1567,7 @@ static void intel_edp_psr_setup(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct edp_vsc_psr psr_vsc;
- if (intel_dp-psr_setup_done)
+ if (dev_priv-psr.setup_done)
return;
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
@@ -1582,7 +1582,7 @@ static void intel_edp_psr_setup(struct intel_dp
*intel_dp)
I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
- intel_dp-psr_setup_done = true;
+ dev_priv-psr.setup_done = true;
}
static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
@@ -3702,7 +3702,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
WARN(error, intel_dp_i2c_init failed with error %d for port %c\n,
error, port_name(port));
- intel_dp-psr_setup_done = false;
+ dev_priv-psr.setup_done = false;
This line is now weird because most systems will call
intel_dp_init_connector more than once, so we'll zero setup_done many
times. I don't see any bugs related to this, but we should probably
move this line to somewhere else.
yeah, it isn't a problem... some of my tests here I was making it
false on all disable call.
But it is better if it was only once for sure...
and I was using on dp_init what I guess doesn't help either, right?
so, do you suggest any place?
Or just remove this line and rely on
the fact that the struct is initialized as zero when allocated. It
seems sink_support and source_ok are not explicitly initialized, so we
should probably follow this model.
Can we trust that? If this is a sure thing I think this is might be
the best approach.
Thanks!
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
i2c_del_adapter(intel_dp-adapter);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 46aea6c..f7b5b2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -485,7 +485,6 @@ struct intel_dp {
int backlight_off_delay;
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
- bool psr_setup_done;
struct intel_connector *attached_connector;
};
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915: Extract semaphore error collection
On Mon, Dec 16, 2013 at 08:50:48PM -0800, Ben Widawsky wrote: Refactoring semaphore error state capture in preparation for future hardware support. Signed-off-by: Ben Widawsky b...@bwidawsk.net A trivial explanation for a trivial patch is better than none. :) -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 v2] drm/i915: vlv: W/a for hotplug/manual VGA detection
VGA detection requires the reference clock to be on, so make sure this is the case. This fixes VGA hotplug/manual detection where all pipes are off and so we would normally disable all clocks. v2: - Instead of disabling PSR clock gating, force the reference clock on through the DPLL_A register. (Kin Chan S kin.s.c...@intel.com) Reported-by: Joonas Lahtinen joonas.lahti...@linux.intel.com Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 14 -- drivers/gpu/drm/i915/intel_pm.c | 5 + 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 674fd43..f3a0a7e 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1507,9 +1507,15 @@ static void vlv_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe) /* Make sure the pipe isn't still relying on us */ assert_pipe_disabled(dev_priv, pipe); - /* Leave integrated clock source enabled */ + /* +* Leave integrated clock source enabled for pipe B and the reference +* clock for pipe A. The latter is needed for VGA hotplug / manual +* detection. +*/ if (pipe == PIPE_B) val = DPLL_INTEGRATED_CRI_CLK_VLV; + else + val = DPLL_REFA_CLK_ENABLE_VLV; I915_WRITE(DPLL(pipe), val); POSTING_READ(DPLL(pipe)); } @@ -4984,7 +4990,11 @@ static void vlv_update_pll(struct intel_crtc *crtc) vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW11(pipe), 0x87871000); - /* Enable DPIO clock input */ + /* +* Enable DPIO clock input. We should never disable the reference +* clock for pipe A, since VGA hotplug / manual detection depends +* on it. Set it here for state tracking. +*/ dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REFA_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV; /* We should never disable this, set it here for state tracking */ diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index fccd7a8..1c1de83 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4933,6 +4933,11 @@ static void valleyview_init_clock_gating(struct drm_device *dev) I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE); + /* Force the reference clock on for VGA hotplug / manual detection */ + val = I915_READ(DPLL(PIPE_A)); + val |= DPLL_REFA_CLK_ENABLE_VLV; + I915_WRITE(DPLL(PIPE_A), val); + /* WaDisableEarlyCull:vlv */ I915_WRITE(_3D_CHICKEN3, _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL)); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: retrieve current fb config into new plane_config structure at init
On Tue, 17 Dec 2013 09:38:36 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Mon, Dec 16, 2013 at 04:01:41PM -0800, Jesse Barnes wrote: On Sat, 14 Dec 2013 12:01:47 +0100 Daniel Vetter dan...@ffwll.ch wrote: But I still think the fb lifetime management is a bit broken here and we need a few small changes: 1. Right here in this loop we need to assign the fb from the plane_config ot the crtc-fb pointer and grab an fb reference for that. If we don't do that we'll fall over for CONFIG_FB=n A side-effect of that is that plane_config is now fairly redundant and we have the problem of cleaning up the fb referenced in there somehow (especially for CONFIG_FB=n). That's kinda the reason why I don't like it very much ... The below points are for the next patch, just noting them here for the full picture. I haven't read carefully through that patch yet, so might all be correct already. 2. We need to clean up fb reference in the plane config. Iirc your current patch 3 fails that for CONFIG_FB=n Hm yeah the ownership is less clear in the CONFIG_FB=n case. I think the driver will own the buffer, and it'll get dropped on the first mode set with a new buffer. But even then there will be no process to deref the object finally, so it'll stick around. Hm... maybe just disable it if CONFIG_FB=n is the right answer for now. If you switch the fbdev code to look at crtc-fb instead of crtc-plane_config.fb and just drop the plane_config.fb pointer (and it's reference) it should pan out. Then the only reference+pointers we have are the ones in crtc-fb, and the drm core will take care of those. How can I switch to looking at crtc-fb? Or do you mean get_plane_config should stuff a full fb into crtc-fb instead of the plane_config struct? fbdev then needs to grab an additional reference for ifbdev-fb, but it needs to do that anyway. Your current code seems to just steal the initial reference from creating the framebuffer in -get_plane_config. Right. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: retrieve current fb config into new plane_config structure at init v7
On Tue, 17 Dec 2013 10:03:12 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Dec 16, 2013 at 04:34:26PM -0800, Jesse Barnes wrote:
+ if (INTEL_INFO(dev)-gen = 4) {
+ if (plane_config-tiled)
+ offset = I915_READ(DSPTILEOFF(plane));
+ else
+ offset = I915_READ(DSPLINOFF(plane));
+ base = I915_READ(DSPSURF(plane)) 0xf000;
+ } else {
+ base = I915_READ(DSPADDR(plane));
+ }
+
+ val = I915_READ(PIPESRC(pipe));
+ plane_config-fb-base.width = ((val 16) 0xfff) + 1;
+ plane_config-fb-base.height = ((val 0) 0xfff) + 1;
+
+ val = I915_READ(DSPSTRIDE(pipe));
+ plane_config-fb-base.pitches[0] = val 0xff80;
+
+ plane_config-size = ALIGN(plane_config-fb-base.pitches[0] *
+ plane_config-fb-base.height, PAGE_SIZE);
This underestimates the size of a tiled framebuffer. Height should be
aligned to 1,16,64 depending on tiling.
Fixed, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
On Tue, 17 Dec 2013 10:34:39 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
+ if (dev_priv-fbdev)
+ drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
}
Also intel_fbdev_restore_mode() needs the NULL fbdev safeguard.
Fixed.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
+ if (dev_priv-fbdev)
+ drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
}
Also intel_fbdev_restore_mode() needs the NULL fbdev safeguard.
Fixed.
I still don't get why we need this check - for CONFIG_FB=n we have a
special dummy function and we are really careful in the setup code to
only enable the interrupt handling code once fbdev is fully set up. Or
do I miss some change here which makes this required? If so the right
fix imo would be to shuffle the init sequence again (and update all
the tons of comments about it, ofc).
-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 6/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
On Tue, 17 Dec 2013 22:17:22 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
+ if (dev_priv-fbdev)
+ drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
}
Also intel_fbdev_restore_mode() needs the NULL fbdev safeguard.
Fixed.
I still don't get why we need this check - for CONFIG_FB=n we have a
special dummy function and we are really careful in the setup code to
only enable the interrupt handling code once fbdev is fully set up. Or
do I miss some change here which makes this required? If so the right
fix imo would be to shuffle the init sequence again (and update all
the tons of comments about it, ofc).
In the init code I'm more careful now to avoid leaving a bogus
pointer around:
ret = drm_fb_helper_init(dev, ifbdev-helper,
INTEL_INFO(dev)-num_pipes,
4);
if (ret) {
+ dev_priv-fbdev = NULL;
kfree(ifbdev);
return ret;
}
So in the unlikely event that the fb helper code fails I don't want to
fall over.
But that shouldn't happen in practice. I only have the checks in place
to catch when I failed to set the fbdev field in one path (which is now
fixed).
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: retrieve current fb config into new plane_config structure at init
On Tue, Dec 17, 2013 at 10:04 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Hm yeah the ownership is less clear in the CONFIG_FB=n case. I think the driver will own the buffer, and it'll get dropped on the first mode set with a new buffer. But even then there will be no process to deref the object finally, so it'll stick around. Hm... maybe just disable it if CONFIG_FB=n is the right answer for now. If you switch the fbdev code to look at crtc-fb instead of crtc-plane_config.fb and just drop the plane_config.fb pointer (and it's reference) it should pan out. Then the only reference+pointers we have are the ones in crtc-fb, and the drm core will take care of those. How can I switch to looking at crtc-fb? Or do you mean get_plane_config should stuff a full fb into crtc-fb instead of the plane_config struct? Yeah, that would be my idea. Since crtc-fb is managed by the drm core we could also enable the recovery for CONFIG_FB=n and so enable smooth transitions without fbdev being present. Well, super-smooth only with fastboot ofc ;-) -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 02/15] drm/i915: Don't emit mbox updates without semaphores
On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote: Aside from the fact that it leaves confusing dumps on error capture, it is entirely unnecessary, and potentially harmful in cases like BDW, where the instruction has changed. In reality (seemingly), this will have no behavioral impact. Signed-off-by: Ben Widawsky b...@bwidawsk.net The reason why we currently do is because i915.semaphores can change at runtime. So we emit the instructions whilst i915.semaphores=0 just in case, it is enabled later. This restriction can be lifted with a little more work in handling the missed semaphores, I think, or it may just require a proof that everything is safe as is. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
On Tue, Dec 17, 2013 at 10:30 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
+ if (dev_priv-fbdev)
+ drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
}
Also intel_fbdev_restore_mode() needs the NULL fbdev safeguard.
Fixed.
I still don't get why we need this check - for CONFIG_FB=n we have a
special dummy function and we are really careful in the setup code to
only enable the interrupt handling code once fbdev is fully set up. Or
do I miss some change here which makes this required? If so the right
fix imo would be to shuffle the init sequence again (and update all
the tons of comments about it, ofc).
In the init code I'm more careful now to avoid leaving a bogus
pointer around:
ret = drm_fb_helper_init(dev, ifbdev-helper,
INTEL_INFO(dev)-num_pipes,
4);
if (ret) {
+ dev_priv-fbdev = NULL;
kfree(ifbdev);
return ret;
}
So in the unlikely event that the fb helper code fails I don't want to
fall over.
But that shouldn't happen in practice. I only have the checks in place
to catch when I failed to set the fbdev field in one path (which is now
fixed)
Imo if a core piece of the driver fails to initialize we should just
fail driver loading. We've had tons of crazy lore around contexts
failing, ppgtt failing and other similar stuff, and I think it just
makes the normal code more fragile with no real gain.
If you think something slips through the cracks maybe just throw a
BUG_ON in there instead.
-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 6/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
On Tue, 17 Dec 2013 19:29:00 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
int intel_fbdev_init(struct drm_device *dev)
@@ -268,17 +461,25 @@ int intel_fbdev_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int ret;
- ifbdev = kzalloc(sizeof(*ifbdev), GFP_KERNEL);
- if (!ifbdev)
- return -ENOMEM;
+ /* This may fail, if so, dev_priv-fbdev won't be set below */
+ intel_fbdev_init_bios(dev);
- dev_priv-fbdev = ifbdev;
- ifbdev-helper.funcs = intel_fb_helper_funcs;
+ if ((ifbdev = dev_priv-fbdev) == NULL) {
+ ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
+ if (ifbdev == NULL)
+ return -ENOMEM;
+
+ ifbdev-helper.funcs = intel_fb_helper_funcs;
+ ifbdev-preferred_bpp = 32;
+
+ dev_priv-fbdev = ifbdev;
+ }
Since Daniel also mentioned the same bikeshed, I think this would look
neater with the allocation here and ifbdev being passed to
intel_fbdev_init_bios to fill in:
ifbdev = kzalloc(sizeof(*ifbdev), GFP_KERNEL);
if (ifbdev == NULL)
return -ENODEV;
if (!intel_fbdev_init_bios(dev, ifbdev)) {
ifbdev-helper.funcs = intel_fb_helper_funcs;
ifbdev-preferred_bpp = 32;
}
dev_priv-fbdev = ifbdev;
return 0;
Yeah, looks better that way. Fixed.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/15] drm/i915: Don't emit mbox updates without semaphores
On Tue, Dec 17, 2013 at 07:24:41PM +, Chris Wilson wrote: On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote: Aside from the fact that it leaves confusing dumps on error capture, it is entirely unnecessary, and potentially harmful in cases like BDW, where the instruction has changed. In reality (seemingly), this will have no behavioral impact. Signed-off-by: Ben Widawsky b...@bwidawsk.net The reason why we currently do is because i915.semaphores can change at runtime. So we emit the instructions whilst i915.semaphores=0 just in case, it is enabled later. This restriction can be lifted with a little more work in handling the missed semaphores, I think, or it may just require a proof that everything is safe as is. -Chris It should still check the module parameter - I guess it would be nice to guard changing the module parameter with struct_mutex (generally, not just here), as that also breaks the emit path. So in short, I think it's broken for two reasons. My (and Daniel's) vote is to just make the module param static. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: grab a pages pin count for preallocate stolen
But only when we indeed set up a gtt mapping. We need this since the vma also holds a pages_pin_count, on top of the unconditional pages_pin_count we grab for all stolen objects (to avoid swap-out). This should avoid a pages_pin_count underrun when cleaning up framebuffers objects taken over from the BIOS. Reported-by: Jesse Barnes jbar...@virtuousgeek.org Cc: Jesse Barnes jbar...@virtuousgeek.org Cc: Ben Widawsky benjamin.widaw...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_gem_stolen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index d284d892ed94..fed87ec17211 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -420,6 +420,7 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev, list_add_tail(obj-global_list, dev_priv-mm.bound_list); list_add_tail(vma-mm_list, ggtt-inactive_list); + i915_gem_object_pin_pages(obj); return obj; -- 1.8.4.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915/vlv: add early DPIO init v3
Just add an early init since we may need to access DPIO regs early on. The init call in modeset_init_hw is also needed for the resume case, when we need to reset DPIO to keep things happy. v2: split reset and reg init v3: split patches (Daniel) Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index af3717a..24506be 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -10861,6 +10861,8 @@ void intel_modeset_init(struct drm_device *dev) } } + intel_init_dpio(dev); + intel_cpu_pll_init(dev); intel_shared_dpll_init(dev); -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] convert to using crtc-fb for BIOS fb management
Along with refcounting changes and breakage.
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 39 ++
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_fbdev.c | 19 -
4 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index d284d89..c1625e6 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -420,6 +420,8 @@ i915_gem_object_create_stolen_for_preallocated(struct
drm_device *dev,
list_add_tail(obj-global_list, dev_priv-mm.bound_list);
list_add_tail(vma-mm_list, ggtt-inactive_list);
+ /* the vma also holds a pages reference */
+ i915_gem_object_pin_pages(obj);
return obj;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 97acb01..e5821a0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5508,13 +5508,14 @@ static void i9xx_get_plane_config(struct intel_crtc
*crtc,
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj = NULL;
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
+ struct intel_framebuffer *fb;
u32 val, base, offset;
int pipe = crtc-pipe, plane = crtc-plane;
int fourcc, pixel_format;
int aligned_height;
- plane_config-fb = kzalloc(sizeof(*plane_config-fb), GFP_KERNEL);
- if (!plane_config-fb) {
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+ if (!fb) {
DRM_DEBUG_KMS(failed to alloc fb\n);
return;
}
@@ -5527,8 +5528,8 @@ static void i9xx_get_plane_config(struct intel_crtc *crtc,
pixel_format = val DISPPLANE_PIXFORMAT_MASK;
fourcc = intel_format_to_fourcc(pixel_format);
- plane_config-fb-base.pixel_format = fourcc;
- plane_config-fb-base.bits_per_pixel =
+ fb-base.pixel_format = fourcc;
+ fb-base.bits_per_pixel =
drm_format_plane_cpp(fourcc, 0) * 8;
if (INTEL_INFO(dev)-gen = 4) {
@@ -5542,23 +5543,23 @@ static void i9xx_get_plane_config(struct intel_crtc
*crtc,
}
val = I915_READ(PIPESRC(pipe));
- plane_config-fb-base.width = ((val 16) 0xfff) + 1;
- plane_config-fb-base.height = ((val 0) 0xfff) + 1;
+ fb-base.width = ((val 16) 0xfff) + 1;
+ fb-base.height = ((val 0) 0xfff) + 1;
val = I915_READ(DSPSTRIDE(pipe));
- plane_config-fb-base.pitches[0] = val 0xff80;
+ fb-base.pitches[0] = val 0xff80;
- aligned_height = intel_align_height(dev, plane_config-fb-base.height,
+ aligned_height = intel_align_height(dev, fb-base.height,
plane_config-tiled);
- plane_config-size = ALIGN(plane_config-fb-base.pitches[0] *
+ plane_config-size = ALIGN(fb-base.pitches[0] *
aligned_height, PAGE_SIZE);
DRM_DEBUG_KMS(pipe/plane %d/%d with fb: size=%dx%d@%d, offset=%x,
pitch %d, size 0x%x\n,
- pipe, plane, plane_config-fb-base.width,
- plane_config-fb-base.height,
- plane_config-fb-base.bits_per_pixel, base,
- plane_config-fb-base.pitches[0],
+ pipe, plane, fb-base.width,
+ fb-base.height,
+ fb-base.bits_per_pixel, base,
+ fb-base.pitches[0],
plane_config-size);
/*
@@ -5571,19 +5572,21 @@ static void i9xx_get_plane_config(struct intel_crtc
*crtc,
return;
mode_cmd.pixel_format = fourcc;
- mode_cmd.width = plane_config-fb-base.width;
- mode_cmd.height = plane_config-fb-base.height;
- mode_cmd.pitches[0] = plane_config-fb-base.pitches[0];
+ mode_cmd.width = fb-base.width;
+ mode_cmd.height = fb-base.height;
+ mode_cmd.pitches[0] = fb-base.pitches[0];
mutex_lock(dev-struct_mutex);
- if (intel_framebuffer_init(dev, plane_config-fb, mode_cmd, obj)) {
+ if (intel_framebuffer_init(dev, fb, mode_cmd, obj)) {
DRM_DEBUG_KMS(intel fb init failed\n);
goto out_unref_obj;
}
+ crtc-base.fb = fb-base;
+
mutex_unlock(dev-struct_mutex);
- DRM_DEBUG_KMS(plane fb obj %p\n, plane_config-fb-obj);
+ DRM_DEBUG_KMS(plane fb obj %p\n, fb-obj);
return;
out_unref_obj:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d849a5c..a40109e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -211,7 +211,6 @@ typedef struct dpll {
} intel_clock_t;
struct intel_plane_config {
- struct intel_framebuffer *fb; /* ends up managed by
[Intel-gfx] [PATCH 09/10] port hotplug status live fix for VLV
--- drivers/gpu/drm/i915/i915_reg.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 2d20390..f91cb12 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2119,9 +2119,9 @@ * Please check the detailed lore in the commit message for for experimental * evidence. */ -#define PORTD_HOTPLUG_LIVE_STATUS (1 29) +#define PORTB_HOTPLUG_LIVE_STATUS (1 29) #define PORTC_HOTPLUG_LIVE_STATUS (1 28) -#define PORTB_HOTPLUG_LIVE_STATUS (1 27) +#define PORTD_HOTPLUG_LIVE_STATUS (1 27) #define PORTD_HOTPLUG_INT_STATUS (3 21) #define PORTC_HOTPLUG_INT_STATUS (3 19) #define PORTB_HOTPLUG_INT_STATUS (3 17) -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915: retrieve current fb config into new plane_config structure at init v8
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
v2: update for new pitch_for_width function (Jesse)
comment how get_plane_config works with shared fbs (Jesse)
v3: s/ARGB/XRGB (Ville)
use pipesrc width/height (Ville)
fix fourcc comment (Bob)
use drm_format_plane_cpp (Ville)
v4: use fb for tracking fb data object (Ville)
v5: fix up gen2 pitch limits (Ville)
v6: read out stride as well (Daniel)
v7: split out init ordering changes (Daniel)
don't fetch config if !CONFIG_FB
v8: use proper height in get_plane_config (Chris)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 130 +++
drivers/gpu/drm/i915/intel_drv.h | 8 +++
3 files changed, 141 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index efc57fe..2ea151d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -366,6 +366,7 @@ struct drm_i915_error_state {
struct intel_connector;
struct intel_crtc_config;
+struct intel_plane_config;
struct intel_crtc;
struct intel_limit;
struct dpll;
@@ -404,6 +405,8 @@ struct drm_i915_display_funcs {
* fills out the pipe-config with the hw state. */
bool (*get_pipe_config)(struct intel_crtc *,
struct intel_crtc_config *);
+ void (*get_plane_config)(struct intel_crtc *,
+struct intel_plane_config *);
int (*crtc_mode_set)(struct drm_crtc *crtc,
int x, int y,
struct drm_framebuffer *old_fb);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 367d64d..6c38d03 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2025,6 +2025,27 @@ unsigned long intel_gen4_compute_page_offset(int *x, int
*y,
}
}
+int intel_format_to_fourcc(int format)
+{
+ switch (format) {
+ case DISPPLANE_8BPP:
+ return DRM_FORMAT_C8;
+ case DISPPLANE_BGRX555:
+ return DRM_FORMAT_XRGB1555;
+ case DISPPLANE_BGRX565:
+ return DRM_FORMAT_RGB565;
+ default:
+ case DISPPLANE_BGRX888:
+ return DRM_FORMAT_XRGB;
+ case DISPPLANE_RGBX888:
+ return DRM_FORMAT_XBGR;
+ case DISPPLANE_BGRX101010:
+ return DRM_FORMAT_XRGB2101010;
+ case DISPPLANE_RGBX101010:
+ return DRM_FORMAT_XBGR2101010;
+ }
+}
+
static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer *fb,
int x, int y)
{
@@ -5480,6 +5501,96 @@ static void vlv_crtc_clock_get(struct intel_crtc *crtc,
pipe_config-port_clock = clock.dot / 5;
}
+static void i9xx_get_plane_config(struct intel_crtc *crtc,
+ struct intel_plane_config *plane_config)
+{
+ struct drm_device *dev = crtc-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_gem_object *obj = NULL;
+ struct drm_mode_fb_cmd2 mode_cmd = { 0 };
+ u32 val, base, offset;
+ int pipe = crtc-pipe, plane = crtc-plane;
+ int fourcc, pixel_format;
+ int aligned_height;
+
+ plane_config-fb = kzalloc(sizeof(*plane_config-fb), GFP_KERNEL);
+ if (!plane_config-fb) {
+ DRM_DEBUG_KMS(failed to alloc fb\n);
+ return;
+ }
+
+ val = I915_READ(DSPCNTR(plane));
+
+ if (INTEL_INFO(dev)-gen = 4)
+ if (val DISPPLANE_TILED)
+ plane_config-tiled = true;
+
+ pixel_format = val DISPPLANE_PIXFORMAT_MASK;
+ fourcc = intel_format_to_fourcc(pixel_format);
+ plane_config-fb-base.pixel_format = fourcc;
+ plane_config-fb-base.bits_per_pixel =
+ drm_format_plane_cpp(fourcc, 0) * 8;
+
+ if (INTEL_INFO(dev)-gen = 4) {
+ if (plane_config-tiled)
+ offset = I915_READ(DSPTILEOFF(plane));
+ else
+ offset = I915_READ(DSPLINOFF(plane));
+ base = I915_READ(DSPSURF(plane)) 0xf000;
+ } else {
+ base = I915_READ(DSPADDR(plane));
+ }
+
+ val = I915_READ(PIPESRC(pipe));
+ plane_config-fb-base.width = ((val 16) 0xfff) + 1;
+ plane_config-fb-base.height = ((val 0) 0xfff) + 1;
+
+ val = I915_READ(DSPSTRIDE(pipe));
+ plane_config-fb-base.pitches[0] = val 0xff80;
+
+ aligned_height = intel_align_height(dev, plane_config-fb-base.height,
+ plane_config-tiled);
+
+ plane_config-size =
[Intel-gfx] [PATCH 04/10] drm/i915: split aligned height calculation out
For use by get_plane_config.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b8a058a..367d64d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1921,6 +1921,14 @@ static bool need_vtd_wa(struct drm_device *dev)
return false;
}
+static int intel_align_height(struct drm_device *dev, int height, bool tiled)
+{
+ int tile_height;
+
+ tile_height = IS_GEN2(dev) ? 16 : 8;
+ return ALIGN(height, tiled ? tile_height : 1);
+}
+
int
intel_pin_and_fence_fb_obj(struct drm_device *dev,
struct drm_i915_gem_object *obj,
@@ -10392,7 +10400,7 @@ int intel_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_i915_gem_object *obj)
{
- int aligned_height, tile_height;
+ int aligned_height;
int pitch_limit;
int ret;
@@ -10486,9 +10494,8 @@ int intel_framebuffer_init(struct drm_device *dev,
if (mode_cmd-offsets[0] != 0)
return -EINVAL;
- tile_height = IS_GEN2(dev) ? 16 : 8;
- aligned_height = ALIGN(mode_cmd-height,
- obj-tiling_mode ? tile_height : 1);
+ aligned_height = intel_align_height(dev, mode_cmd-height,
+ obj-tiling_mode);
/* FIXME drm helper for size checks (especially planar formats)? */
if (obj-base.size aligned_height * mode_cmd-pitches[0])
return -EINVAL;
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915/vlv: split DPIO init and reset
We only need to init the reg offset for DPIO once, but we need to reset
DPIO at resume time and at init time.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 24506be..aa935ae 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1368,6 +1368,15 @@ static void intel_init_dpio(struct drm_device *dev)
return;
DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO;
+}
+
+static void intel_reset_dpio(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!IS_VALLEYVIEW(dev))
+ return;
+
/*
* From VLV2A0_DP_eDP_DPIO_driver_vbios_notes_10.docx -
* 6. De-assert cmn_reset/side_reset. Same as VLV X0.
@@ -10799,7 +10808,7 @@ void intel_modeset_init_hw(struct drm_device *dev)
I915_WRITE(DPLL(PIPE_B), I915_READ(DPLL(PIPE_B)) |
DPLL_INTEGRATED_CRI_CLK_VLV);
- intel_init_dpio(dev);
+ intel_reset_dpio(dev);
mutex_lock(dev-struct_mutex);
intel_enable_gt_powersave(dev);
@@ -10862,6 +10871,7 @@ void intel_modeset_init(struct drm_device *dev)
}
intel_init_dpio(dev);
+ intel_reset_dpio(dev);
intel_cpu_pll_init(dev);
intel_shared_dpll_init(dev);
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: read out hw state earlier
We want to do this early on before we try to fetch the plane config, which depends on some of the pipe config state. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index aa935ae..0b8a058a 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -10882,6 +10882,11 @@ void intel_modeset_init(struct drm_device *dev) /* Just in case the BIOS is doing something questionable. */ intel_disable_fbc(dev); + + drm_modeset_lock_all(dev); + drm_mode_config_reset(dev); + intel_modeset_setup_hw_state(dev, false); + drm_modeset_unlock_all(dev); } static void @@ -11249,11 +11254,6 @@ void intel_modeset_gem_init(struct drm_device *dev) intel_modeset_init_hw(dev); intel_setup_overlay(dev); - - drm_modeset_lock_all(dev); - drm_mode_config_reset(dev); - intel_modeset_setup_hw_state(dev, false); - drm_modeset_unlock_all(dev); } void intel_modeset_cleanup(struct drm_device *dev) -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/15] drm/i915: Don't emit mbox updates without semaphores
On Tue, Dec 17, 2013 at 02:02:23PM -0800, Ben Widawsky wrote: On Tue, Dec 17, 2013 at 07:24:41PM +, Chris Wilson wrote: On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote: Aside from the fact that it leaves confusing dumps on error capture, it is entirely unnecessary, and potentially harmful in cases like BDW, where the instruction has changed. In reality (seemingly), this will have no behavioral impact. Signed-off-by: Ben Widawsky b...@bwidawsk.net The reason why we currently do is because i915.semaphores can change at runtime. So we emit the instructions whilst i915.semaphores=0 just in case, it is enabled later. This restriction can be lifted with a little more work in handling the missed semaphores, I think, or it may just require a proof that everything is safe as is. -Chris It should still check the module parameter - I guess it would be nice to guard changing the module parameter with struct_mutex (generally, not just here), as that also breaks the emit path. So in short, I think it's broken for two reasons. My (and Daniel's) vote is to just make the module param static. Dynamic i915.semaphores is something I can live happily without. If we ever do need such a thing, it needs to be internal to the kernel. -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 06/10] drm/i915: alloc intel_fb in the intel_fbdev struct
Allocate this struct instead, so we can re-use another allocated
elsewhere if needed.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 27 +++
3 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6c38d03..97acb01 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7838,11 +7838,11 @@ mode_fits_in_fbdev(struct drm_device *dev,
if (dev_priv-fbdev == NULL)
return NULL;
- obj = dev_priv-fbdev-ifb.obj;
+ obj = dev_priv-fbdev-fb-obj;
if (obj == NULL)
return NULL;
- fb = dev_priv-fbdev-ifb.base;
+ fb = dev_priv-fbdev-fb-base;
if (fb-pitches[0] intel_framebuffer_pitch_for_width(mode-hdisplay,
fb-bits_per_pixel))
return NULL;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4787773..182ba0a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -110,7 +110,7 @@ struct intel_framebuffer {
struct intel_fbdev {
struct drm_fb_helper helper;
- struct intel_framebuffer ifb;
+ struct intel_framebuffer *fb;
struct list_head fbdev_list;
struct drm_display_mode *our_mode;
};
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 284c3eb..ee4b3c1 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -62,11 +62,20 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
{
struct intel_fbdev *ifbdev =
container_of(helper, struct intel_fbdev, helper);
+ struct intel_framebuffer *fb;
struct drm_device *dev = helper-dev;
struct drm_mode_fb_cmd2 mode_cmd = {};
struct drm_i915_gem_object *obj;
int size, ret;
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+ if (!fb) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ifbdev-fb = fb;
+
/* we don't do packed 24bpp */
if (sizes-surface_bpp == 24)
sizes-surface_bpp = 32;
@@ -97,7 +106,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
goto out_unref;
}
- ret = intel_framebuffer_init(dev, ifbdev-ifb, mode_cmd, obj);
+ ret = intel_framebuffer_init(dev, ifbdev-fb, mode_cmd, obj);
if (ret)
goto out_unpin;
@@ -116,7 +125,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
{
struct intel_fbdev *ifbdev =
container_of(helper, struct intel_fbdev, helper);
- struct intel_framebuffer *intel_fb = ifbdev-ifb;
+ struct intel_framebuffer *intel_fb = ifbdev-fb;
struct drm_device *dev = helper-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct fb_info *info;
@@ -126,11 +135,12 @@ static int intelfb_create(struct drm_fb_helper *helper,
mutex_lock(dev-struct_mutex);
- if (!intel_fb-obj) {
+ if (!intel_fb || !intel_fb-obj) {
DRM_DEBUG_KMS(no BIOS fb, allocating a new one\n);
ret = intelfb_alloc(helper, sizes);
if (ret)
goto out_unlock;
+ intel_fb = ifbdev-fb;
} else {
DRM_DEBUG_KMS(re-using BIOS fb\n);
sizes-fb_width = intel_fb-base.width;
@@ -148,7 +158,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
info-par = helper;
- fb = ifbdev-ifb.base;
+ fb = ifbdev-fb-base;
ifbdev-helper.fb = fb;
ifbdev-helper.fbdev = info;
@@ -194,7 +204,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
* If the object is stolen however, it will be full of whatever
* garbage was left in there.
*/
- if (ifbdev-ifb.obj-stolen)
+ if (ifbdev-fb-obj-stolen)
memset_io(info-screen_base, 0, info-screen_size);
/* Use default scratch pixmap (info-pixmap.flags = FB_PIXMAP_SYSTEM) */
@@ -258,8 +268,9 @@ static void intel_fbdev_destroy(struct drm_device *dev,
drm_fb_helper_fini(ifbdev-helper);
- drm_framebuffer_unregister_private(ifbdev-ifb.base);
- intel_framebuffer_fini(ifbdev-ifb);
+ drm_framebuffer_unregister_private(ifbdev-fb-base);
+ intel_framebuffer_fini(ifbdev-fb);
+ kfree(ifbdev-fb);
}
int intel_fbdev_init(struct drm_device *dev)
@@ -322,7 +333,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state)
* been restored from swap. If the object is stolen however, it will be
* full of whatever garbage was left in there.
*/
- if (state ==
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v7
On Tue, Dec 17, 2013 at 10:58:51PM +0100, Daniel Vetter wrote: On Tue, Dec 17, 2013 at 10:30 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: So in the unlikely event that the fb helper code fails I don't want to fall over. But that shouldn't happen in practice. I only have the checks in place to catch when I failed to set the fbdev field in one path (which is now fixed) Imo if a core piece of the driver fails to initialize we should just fail driver loading. We've had tons of crazy lore around contexts failing, ppgtt failing and other similar stuff, and I think it just makes the normal code more fragile with no real gain. If you think something slips through the cracks maybe just throw a BUG_ON in there instead. I tripped over it earlier when I was disabling parts of the driver. I think allowing dev_priv-fbdev to be NULL fits nicely with your crusade against fbcon. (In fact it was quite fun to load the driver without modesetting as a headless accelerator...) -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 08/10] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v8
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fixup aperture and cmap frees (Imre)
use unlocked unref if init_bios fails (Jesse)
fix curly brace around DSPADDR check (Imre)
comment failure path for pin_and_fence (Imre)
v3: fixup fixup of aperture frees (Chris)
v4: update to current bits (locking pin_and_fence hack) (Jesse)
v5: move fb config fetch to display code (Jesse)
re-order hw state readout on initial load to suit fb inherit (Jesse)
re-add pin_and_fence in fbdev code to make sure we refcount properly (Je
v6: rename to plane_config (Daniel)
check for valid object when initializing BIOS fb (Jesse)
split from plane_config readout and other display changes (Jesse)
drop use_bios_fb option (Chris)
update comments (Jesse)
rework fbdev_init_bios for clarity (Jesse)
drop fb obj ref under lock (Chris)
v7: use fb object from plane_config instead (Ville)
take ref on fb object (Jesse)
v8: put under i915_fastboot option (Jesse)
fix fb ptr checking (Jesse)
inform drm_fb_helper if we fail to enable a connector (Jesse)
drop unnecessary enabled[] modifications in failure cases (Chris)
split from BIOS connector config readout (Daniel)
don't memset the fb buffer if preallocated (Chris)
alloc ifbdev up front and pass to init_bios (Chris)
check for bad ifbdev in restore_mode too (Chris)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbdev.c | 111 ++---
2 files changed, 103 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 182ba0a..d849a5c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -113,6 +113,7 @@ struct intel_fbdev {
struct intel_framebuffer *fb;
struct list_head fbdev_list;
struct drm_display_mode *our_mode;
+ int preferred_bpp;
};
struct intel_encoder {
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 9e7f6d1..a3e8156 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -132,6 +132,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
int size, ret;
+ bool prealloc = false;
mutex_lock(dev-struct_mutex);
@@ -143,6 +144,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
intel_fb = ifbdev-fb;
} else {
DRM_DEBUG_KMS(re-using BIOS fb\n);
+ prealloc = true;
sizes-fb_width = intel_fb-base.width;
sizes-fb_height = intel_fb-base.height;
}
@@ -204,7 +206,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
* If the object is stolen however, it will be full of whatever
* garbage was left in there.
*/
- if (ifbdev-fb-obj-stolen)
+ if (ifbdev-fb-obj-stolen !prealloc)
memset_io(info-screen_base, 0, info-screen_size);
/* Use default scratch pixmap (info-pixmap.flags = FB_PIXMAP_SYSTEM) */
@@ -364,23 +366,112 @@ static void intel_fbdev_destroy(struct drm_device *dev,
kfree(ifbdev-fb);
}
+/*
+ * Build an intel_fbdev struct using a BIOS allocated framebuffer, if possible.
+ * The core display code will have read out the current plane configuration,
+ * so we use that to figure out if there's an object for us to use as the
+ * fb, and if so, we re-use it for the fbdev configuration.
+ *
+ * Note we only support a single fb shared across pipes for boot (mostly for
+ * fbcon), so we just find the biggest and use that.
+ */
+static bool intel_fbdev_init_bios(struct drm_device *dev,
+struct intel_fbdev *ifbdev)
+{
+ struct intel_framebuffer *fb = NULL;
+ struct drm_crtc *crtc;
+ struct intel_crtc *intel_crtc;
+ struct intel_plane_config *plane_config = NULL;
+ unsigned int last_size = 0;
+
+ /* Find the largest framebuffer to use, then free the others */
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
+ intel_crtc = to_intel_crtc(crtc);
+
+ if (!intel_crtc-active || !intel_crtc-plane_config.fb) {
+ DRM_DEBUG_KMS(pipe %c not active or no fb, skipping\n,
+ pipe_name(intel_crtc-pipe));
+ continue;
+ }
+
+ if (intel_crtc-plane_config.size last_size) {
+ plane_config = intel_crtc-plane_config;
+ last_size = plane_config-size;
+
[Intel-gfx] [PATCH 07/10] drm/i915: allow re-use BIOS connector config for initial fbdev config
The BIOS or boot loader will generally create an initial display
configuration for us that includes some set of active pipes and
displays. This routine tries to figure out which pipes and connectors
are active and stuffs them into the crtcs and modes array given to us by
the drm_fb_helper code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_fbdev.c | 91 ++
1 file changed, 91 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index ee4b3c1..9e7f6d1 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -246,6 +246,97 @@ static void intel_crtc_fb_gamma_get(struct drm_crtc *crtc,
u16 *red, u16 *green,
*blue = intel_crtc-lut_b[regno] 8;
}
+static struct drm_fb_helper_crtc *
+intel_fb_helper_crtc(struct drm_fb_helper *fb_helper, struct drm_crtc *crtc)
+{
+ int i;
+
+ for (i = 0; i fb_helper-crtc_count; i++)
+ if (fb_helper-crtc_info[i].mode_set.crtc == crtc)
+ return fb_helper-crtc_info[i];
+
+ return NULL;
+}
+
+/*
+ * Try to read the BIOS display configuration and use it for the initial
+ * fb configuration.
+ *
+ * The BIOS or boot loader will generally create an initial display
+ * configuration for us that includes some set of active pipes and displays.
+ * This routine tries to figure out which pipes and connectors are active
+ * and stuffs them into the crtcs and modes array given to us by the
+ * drm_fb_helper code.
+ *
+ * The overall sequence is:
+ * intel_fbdev_init - from driver load
+ * intel_fbdev_init_bios - initialize the intel_fbdev using BIOS data
+ * drm_fb_helper_init - build fb helper structs
+ * drm_fb_helper_single_add_all_connectors - more fb helper structs
+ * intel_fbdev_initial_config - apply the config
+ * drm_fb_helper_initial_config - call -probe then register_framebuffer()
+ * drm_setup_crtcs - build crtc config for fbdev
+ * intel_fb_initial_config - find active connectors etc
+ * drm_fb_helper_single_fb_probe - set up fbdev
+ * intelfb_create - re-use or alloc fb, build out fbdev structs
+ *
+ * If the BIOS or boot loader leaves the display in VGA mode, there's not
+ * much we can do; switching out of that mode involves allocating a new,
+ * high res buffer, and also recalculating bandwidth requirements for the
+ * new bpp configuration.
+ */
+static bool intel_fb_initial_config(struct drm_fb_helper *fb_helper,
+ struct drm_fb_helper_crtc **crtcs,
+ struct drm_display_mode **modes,
+ bool *enabled, int width, int height)
+{
+ int i;
+
+ for (i = 0; i fb_helper-connector_count; i++) {
+ struct drm_connector *connector;
+ struct drm_encoder *encoder;
+
+ connector = fb_helper-connector_info[i]-connector;
+ if (!enabled[i]) {
+ DRM_DEBUG_KMS(connector %d not enabled, skipping\n,
+ connector-base.id);
+ continue;
+ }
+
+ encoder = connector-encoder;
+ if (!encoder || !encoder-crtc) {
+ DRM_DEBUG_KMS(connector %d has no encoder or crtc,
skipping\n,
+ connector-base.id);
+ enabled[i] = false;
+ continue;
+ }
+
+ if (WARN_ON(!encoder-crtc-enabled)) {
+ DRM_DEBUG_KMS(connector %s on crtc %d has inconsistent
state, aborting\n,
+ drm_get_connector_name(connector),
+ encoder-crtc-base.id);
+ return false;
+ }
+
+ if (!to_intel_crtc(encoder-crtc)-active) {
+ DRM_DEBUG_KMS(connector %s on inactive crtc %d,
borting\n,
+ drm_get_connector_name(connector),
+ encoder-crtc-base.id);
+ return false;
+ }
+
+ modes[i] = encoder-crtc-mode;
+ crtcs[i] = intel_fb_helper_crtc(fb_helper, encoder-crtc);
+
+ DRM_DEBUG_KMS(connector %s on crtc %d: %s\n,
+ drm_get_connector_name(connector),
+ encoder-crtc-base.id,
+ modes[i]-name);
+ }
+
+ return true;
+}
+
static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
.gamma_set = intel_crtc_fb_gamma_set,
.gamma_get = intel_crtc_fb_gamma_get,
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] [v3] drm/i915/bdw: implement semaphore signal
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space, somewhere in the GTT.
The comments in the code define the layout I've opted for, which should
be fairly future proof. Ie. I tried to define offsets in abstract terms
(NUM_RINGS, seqno size, etc).
NOTE: If one wanted to move this to the HWSP they could. I've decided
one 4k object would be easier to deal with, and provide potential wins
with cache locality, but that's all speculative.
v2: Update the macro to not need the other ring's ring-id (Chris)
v3: After the num_dwords update in the last patch, size was not properly
adjusted on rebase. (Chris)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 5 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 198 +---
drivers/gpu/drm/i915/intel_ringbuffer.h | 38 +-
4 files changed, 196 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c638547..4ccb436 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1355,6 +1355,7 @@ typedef struct drm_i915_private {
struct pci_dev *bridge_dev;
struct intel_ring_buffer ring[I915_NUM_RINGS];
+ struct drm_i915_gem_object *semaphore_obj;
uint32_t last_seqno, next_seqno;
drm_dma_handle_t *status_page_dmah;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ac87ab8..5c3bf66 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -215,7 +215,7 @@
#define MI_DISPLAY_FLIP_IVB_SPRITE_B (3 19)
#define MI_DISPLAY_FLIP_IVB_PLANE_C (4 19)
#define MI_DISPLAY_FLIP_IVB_SPRITE_C (5 19)
-#define MI_SEMAPHORE_MBOX MI_INSTR(0x16, 1) /* gen6+ */
+#define MI_SEMAPHORE_MBOX MI_INSTR(0x16, 1) /* gen6, gen7 */
#define MI_SEMAPHORE_GLOBAL_GTT(122)
#define MI_SEMAPHORE_UPDATE (121)
#define MI_SEMAPHORE_COMPARE (120)
@@ -240,6 +240,8 @@
#define MI_RESTORE_EXT_STATE_EN (12)
#define MI_FORCE_RESTORE (11)
#define MI_RESTORE_INHIBIT (10)
+#define MI_SEMAPHORE_SIGNALMI_INSTR(0x1b, 0) /* GEN8+ */
+#define MI_SEMAPHORE_TARGET(engine) ((engine)15)
#define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1)
#define MI_MEM_VIRTUAL (1 22) /* 965+ only */
#define MI_STORE_DWORD_INDEX MI_INSTR(0x21, 1)
@@ -328,6 +330,7 @@
#define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE(110) /*
GM45+ only */
#define PIPE_CONTROL_INDIRECT_STATE_DISABLE (19)
#define PIPE_CONTROL_NOTIFY (18)
+#define PIPE_CONTROL_FLUSH_ENABLE(17) /* gen7+ */
#define PIPE_CONTROL_VF_CACHE_INVALIDATE (14)
#define PIPE_CONTROL_CONST_CACHE_INVALIDATE (13)
#define PIPE_CONTROL_STATE_CACHE_INVALIDATE (12)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index db63a5c..d6e664d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -619,6 +619,13 @@ static int init_render_ring(struct intel_ring_buffer *ring)
static void render_ring_cleanup(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-semaphore_obj) {
+ i915_gem_object_unpin(dev_priv-semaphore_obj);
+ drm_gem_object_unreference(dev_priv-semaphore_obj-base);
+ dev_priv-semaphore_obj = NULL;
+ }
if (ring-scratch.obj == NULL)
return;
@@ -632,6 +639,85 @@ static void render_ring_cleanup(struct intel_ring_buffer
*ring)
ring-scratch.obj = NULL;
}
+static int gen8_rcs_signal(struct intel_ring_buffer *signaller,
+ unsigned int num_dwords)
+{
+#define MBOX_UPDATE_DWORDS 8
+ struct drm_device *dev = signaller-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_ring_buffer *waiter;
+ int i, ret, num_rings;
+
+ num_rings = hweight_long(INTEL_INFO(dev)-ring_mask);
+ num_dwords += (num_rings-1) * MBOX_UPDATE_DWORDS;
+#undef MBOX_UPDATE_DWORDS
+
+ ret = intel_ring_begin(signaller, num_dwords);
+ if (ret)
+ return ret;
+
+ for_each_ring(waiter, dev_priv, i) {
+ u64 gtt_offset = signaller-semaphore.signal_ggtt[i];
+ if (gtt_offset == MI_SEMAPHORE_SYNC_INVALID)
+ continue;
+
+ intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6));
+ intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB |
+ PIPE_CONTROL_QW_WRITE |
+
[Intel-gfx] [PATCH 01.5/15] drm/i915: Make semaphore modparam RO
A couple patches in the upcoming rework of semaphores will break if semaphores are toggled by the user at various times. Since the code cleanups there seem to be an overall win, and toggling semaphores at runtime is not a terribly useful thing to do, simply make the module parameter read-only. Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 23f8217..2527d4a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -59,7 +59,7 @@ MODULE_PARM_DESC(powersave, Enable powersavings, fbc, downclocking, etc. (default: true)); int i915_semaphores __read_mostly = -1; -module_param_named(semaphores, i915_semaphores, int, 0600); +module_param_named(semaphores, i915_semaphores, int, 0400); MODULE_PARM_DESC(semaphores, Use semaphores for inter-ring sync (default: -1 (use per-chip defaults))); -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/15] [v3] drm/i915/bdw: implement semaphore wait
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update macros to not require the other ring's ring-id (Chris)
v3: Use a condensed GEN8_SEMAPHORE_OFFSET to define the WAIT/SIGNAL
offsets (Chris). To be honest, I prefer the original implementation
because I feel it is more explicit about exactly what is going on. I am
willing to declare I am just unsmart, and leave it there.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 66 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 30 +++
3 files changed, 62 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5c3bf66..a47463f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -242,6 +242,9 @@
#define MI_RESTORE_INHIBIT (10)
#define MI_SEMAPHORE_SIGNALMI_INSTR(0x1b, 0) /* GEN8+ */
#define MI_SEMAPHORE_TARGET(engine) ((engine)15)
+#define MI_SEMAPHORE_WAIT MI_INSTR(0x1c, 2) /* GEN8+ */
+#define MI_SEMAPHORE_POLL(115)
+#define MI_SEMAPHORE_SAD_GTE_SDD (112)
#define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1)
#define MI_MEM_VIRTUAL (1 22) /* 965+ only */
#define MI_STORE_DWORD_INDEX MI_INSTR(0x21, 1)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index d6e664d..f87b704 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -796,6 +796,31 @@ static inline bool i915_gem_has_seqno_wrapped(struct
drm_device *dev,
* @signaller - ring which has, or will signal
* @seqno - seqno which the waiter will block on
*/
+
+static int
+gen8_ring_sync(struct intel_ring_buffer *waiter,
+ struct intel_ring_buffer *signaller,
+ u32 seqno)
+{
+ struct drm_i915_private *dev_priv = waiter-dev-dev_private;
+ int ret;
+
+ ret = intel_ring_begin(waiter, 4);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(waiter, MI_SEMAPHORE_WAIT |
+ MI_SEMAPHORE_GLOBAL_GTT |
+ MI_SEMAPHORE_SAD_GTE_SDD);
+ intel_ring_emit(waiter, seqno);
+ intel_ring_emit(waiter,
+ lower_32_bits(GEN8_WAIT_OFFSET(waiter, signaller-id)));
+ intel_ring_emit(waiter,
+ upper_32_bits(GEN8_WAIT_OFFSET(waiter, signaller-id)));
+ intel_ring_advance(waiter);
+ return 0;
+}
+
static int
gen6_ring_sync(struct intel_ring_buffer *waiter,
struct intel_ring_buffer *signaller,
@@ -1934,39 +1959,6 @@ static int gen6_ring_flush(struct intel_ring_buffer
*ring,
return 0;
}
-/* seqno size is actually only a uint32, but since we plan to use MI_FLUSH_DW
to
- * do the writes, and that must have qw aligned offsets, simply pretend it's
8b.
- */
-#define SEQNO_SIZE sizeof(uint64_t)
-#define GEN8_SIGNAL_OFFSET(to) \
- (i915_gem_obj_ggtt_offset(dev_priv-semaphore_obj) + \
- (ring-id * I915_NUM_RINGS * SEQNO_SIZE) + \
- (SEQNO_SIZE * (to)))
-
-#define GEN8_WAIT_OFFSET(from) \
- (i915_gem_obj_ggtt_offset(dev_priv-semaphore_obj) + \
- ((from) * I915_NUM_RINGS * SEQNO_SIZE) + \
- (SEQNO_SIZE * ring-id))
-
-#define GEN8_RING_SEMAPHORE_INIT do { \
- if (!dev_priv-semaphore_obj) { \
- break; \
- } \
- ring-semaphore.signal_ggtt[RCS] = GEN8_SIGNAL_OFFSET(RCS); \
- ring-semaphore.signal_ggtt[VCS] = GEN8_SIGNAL_OFFSET(VCS); \
- ring-semaphore.signal_ggtt[BCS] = GEN8_SIGNAL_OFFSET(BCS); \
- ring-semaphore.signal_ggtt[VECS] = GEN8_SIGNAL_OFFSET(VECS); \
- ring-semaphore.mbox[RCS] = GEN8_WAIT_OFFSET(RCS); \
- ring-semaphore.mbox[VCS] = GEN8_WAIT_OFFSET(VCS); \
- ring-semaphore.mbox[BCS] = GEN8_WAIT_OFFSET(BCS); \
- ring-semaphore.mbox[VECS] = GEN8_WAIT_OFFSET(VECS); \
- ring-semaphore.signal_ggtt[ring-id] = MI_SEMAPHORE_SYNC_INVALID; \
- ring-semaphore.mbox[ring-id] = GEN6_NOSYNC; \
- } while(0)
-#undef seqno_size
-
-
-
int intel_init_render_ring_buffer(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
@@ -2002,7 +1994,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring-irq_enable_mask = GT_RENDER_USER_INTERRUPT;
ring-get_seqno = gen6_ring_get_seqno;
ring-set_seqno = ring_set_seqno;
- ring-semaphore.sync_to = gen6_ring_sync;
+ ring-semaphore.sync_to = gen8_ring_sync;
if (i915_semaphore_is_enabled(dev)) {
BUG_ON(!dev_priv-semaphore_obj);
ring-semaphore.signal =
Re: [Intel-gfx] [PATCH 12/15] drm/i915: Extract semaphore error collection
On Tue, Dec 17, 2013 at 07:14:27PM +, Chris Wilson wrote: On Mon, Dec 16, 2013 at 08:50:48PM -0800, Ben Widawsky wrote: Refactoring semaphore error state capture in preparation for future hardware support. Signed-off-by: Ben Widawsky b...@bwidawsk.net A trivial explanation for a trivial patch is better than none. :) -Chris Daniel if you don't mind, please add this if/when merge. If you do mind, I will repost. Thanks. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: grab a pages pin count for preallocate stolen
On Tue, Dec 17, 2013 at 11:42:11PM +0100, Daniel Vetter wrote: But only when we indeed set up a gtt mapping. We need this since the vma also holds a pages_pin_count, on top of the unconditional pages_pin_count we grab for all stolen objects (to avoid swap-out). This should avoid a pages_pin_count underrun when cleaning up framebuffers objects taken over from the BIOS. Reported-by: Jesse Barnes jbar...@virtuousgeek.org Cc: Jesse Barnes jbar...@virtuousgeek.org Cc: Ben Widawsky benjamin.widaw...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_gem_stolen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index d284d892ed94..fed87ec17211 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -420,6 +420,7 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev, list_add_tail(obj-global_list, dev_priv-mm.bound_list); list_add_tail(vma-mm_list, ggtt-inactive_list); + i915_gem_object_pin_pages(obj); return obj; -- 1.8.4.3 I'm missing why _i915_gem_object_create_stolen() isn't good enough for pinning the pages. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device
Chris Wilson ch...@chris-wilson.co.uk writes: Ok, so as no vgaarb_clients have yet been registered and so the call to grab the IO resource does not actually disable VGA IO routing to the nvidia card. Yikes! This explains a lot. If you care to update the changelog to explain the problem is that vgaarb is ineffective before all clients are registered, then I think this is a good temporary hack. It should be possible for vgaarb to mark resources as locked if the device is interpretting IO access and has no method for disabling the IO grab (and then a vga_tryget() check here). Sounds like vgaarb should not assume that all devices using VGA are registered drivers. That also sounds like a significantly harder fix. If SR01 is required before disabling VGA, then perhaps we should not disable VGA at all in this case though. That sounds safer, although if VGA was enabled, it will suck a bit more power? -- keith.pack...@intel.com pgpvHdV8z2b5h.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] video/fb: Propagate error code from failing to unregister conflicting fb
On Tue, Dec 17, 2013 at 10:14 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote: On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote: If we fail to remove a conflicting fb driver, we need to abort the loading of the second driver to avoid likely kernel panics. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org I'll merge this via the drm tree, Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/intel_pm.c between commit fec8cba306f9 (drm/i915: use crtc_htotal in watermark calculations to match fastboot v2) from Linus' tree and commit 96f90c5421aa (drm/i915: Move ILK/SNB/IVB over to the HSW WM code) from the drm-intel tree. I fixed it up (I just removed the code removed by the drm-intel tree patch) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell s...@canb.auug.org.au pgpS_sf3mGy0a.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix disabled semaphores
The ring will emit too many if semaphores are disabled since we do not
add the correct number to num_dwords anymore.
This was introduced:
commit 52ed23253b68e1cf154b03d91bed619504cf955b
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Mon Dec 16 20:50:38 2013 -0800
drm/i915: Don't emit mbox updates without semaphores
FWIW, the bug was fixed later in the series.
/me hangs head in shame.
Daniel: Also note that we should have merged the read-only semaphore
modparam before this patch.
Reported-by: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b106984..b242dbb 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -673,10 +673,12 @@ gen6_add_request(struct intel_ring_buffer *ring)
if (ret)
return ret;
- for_each_ring(useless, dev_priv, i) {
- u32 mbox_reg = ring-signal_mbox[i];
- if (mbox_reg != GEN6_NOSYNC)
- update_mboxes(ring, mbox_reg);
+ if (i915_semaphore_is_enabled(dev)) {
+ for_each_ring(useless, dev_priv, i) {
+ u32 mbox_reg = ring-signal_mbox[i];
+ if (mbox_reg != GEN6_NOSYNC)
+ update_mboxes(ring, mbox_reg);
+ }
}
intel_ring_emit(ring, MI_STORE_DWORD_INDEX);
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC Patch v1 11/13] ACPI, i915: replace open-coded _DSM specific code with helper functions
Use helper functions to simplify _DSM related code in i915 driver.
Function intel_dsm() is used to check functions supported by ACPI _DSM
method, but it has strange check for special value 0x8002. After
digging into nouveau driver, I think the check is copied from nouveau
driver and is useless for i915 driver, so remove it.
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/gpu/drm/i915/intel_acpi.c | 144 -
1 file changed, 30 insertions(+), 114 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_acpi.c
b/drivers/gpu/drm/i915/intel_acpi.c
index dfff090..1bfac94 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -12,8 +12,6 @@
#include i915_drv.h
#define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
-
-#define INTEL_DSM_FN_SUPPORTED_FUNCTIONS 0 /* No args */
#define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
static struct intel_dsm_priv {
@@ -28,61 +26,6 @@ static const u8 intel_dsm_guid[] = {
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
};
-static int intel_dsm(acpi_handle handle, int func)
-{
- struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
- struct acpi_object_list input;
- union acpi_object params[4];
- union acpi_object *obj;
- u32 result;
- int ret = 0;
-
- input.count = 4;
- input.pointer = params;
- params[0].type = ACPI_TYPE_BUFFER;
- params[0].buffer.length = sizeof(intel_dsm_guid);
- params[0].buffer.pointer = (char *)intel_dsm_guid;
- params[1].type = ACPI_TYPE_INTEGER;
- params[1].integer.value = INTEL_DSM_REVISION_ID;
- params[2].type = ACPI_TYPE_INTEGER;
- params[2].integer.value = func;
- params[3].type = ACPI_TYPE_PACKAGE;
- params[3].package.count = 0;
- params[3].package.elements = NULL;
-
- ret = acpi_evaluate_object(handle, _DSM, input, output);
- if (ret) {
- DRM_DEBUG_DRIVER(failed to evaluate _DSM: %d\n, ret);
- return ret;
- }
-
- obj = (union acpi_object *)output.pointer;
-
- result = 0;
- switch (obj-type) {
- case ACPI_TYPE_INTEGER:
- result = obj-integer.value;
- break;
-
- case ACPI_TYPE_BUFFER:
- if (obj-buffer.length == 4) {
- result = (obj-buffer.pointer[0] |
- (obj-buffer.pointer[1] 8) |
- (obj-buffer.pointer[2] 16) |
- (obj-buffer.pointer[3] 24));
- break;
- }
- default:
- ret = -EINVAL;
- break;
- }
- if (result == 0x8002)
- ret = -ENODEV;
-
- kfree(output.pointer);
- return ret;
-}
-
static char *intel_dsm_port_name(u8 id)
{
switch (id) {
@@ -137,83 +80,56 @@ static char *intel_dsm_mux_type(u8 type)
static void intel_dsm_platform_mux_info(void)
{
- struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
- struct acpi_object_list input;
- union acpi_object params[4];
- union acpi_object *pkg;
- int i, ret;
-
- input.count = 4;
- input.pointer = params;
- params[0].type = ACPI_TYPE_BUFFER;
- params[0].buffer.length = sizeof(intel_dsm_guid);
- params[0].buffer.pointer = (char *)intel_dsm_guid;
- params[1].type = ACPI_TYPE_INTEGER;
- params[1].integer.value = INTEL_DSM_REVISION_ID;
- params[2].type = ACPI_TYPE_INTEGER;
- params[2].integer.value = INTEL_DSM_FN_PLATFORM_MUX_INFO;
- params[3].type = ACPI_TYPE_PACKAGE;
- params[3].package.count = 0;
- params[3].package.elements = NULL;
-
- ret = acpi_evaluate_object(intel_dsm_priv.dhandle, _DSM, input,
- output);
- if (ret) {
- DRM_DEBUG_DRIVER(failed to evaluate _DSM: %d\n, ret);
- goto out;
+ int i;
+ union acpi_object *pkg, *connector_count;
+
+ pkg = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, intel_dsm_guid,
+ INTEL_DSM_REVISION_ID, INTEL_DSM_FN_PLATFORM_MUX_INFO,
+ NULL, ACPI_TYPE_PACKAGE);
+ if (!pkg) {
+ DRM_DEBUG_DRIVER(failed to evaluate _DSM\n);
+ return;
}
- pkg = (union acpi_object *)output.pointer;
-
- if (pkg-type == ACPI_TYPE_PACKAGE) {
- union acpi_object *connector_count = pkg-package.elements[0];
- DRM_DEBUG_DRIVER(MUX info connectors: %lld\n,
- (unsigned long long)connector_count-integer.value);
- for (i = 1; i pkg-package.count; i++) {
- union acpi_object *obj = pkg-package.elements[i];
- union acpi_object *connector_id =
- obj-package.elements[0];
- union
