On Mon, May 27, 2013 at 06:30:17PM -0300, Paulo Zanoni wrote:
> 2013/5/21 Daniel Vetter :
> Besides this, I also booted a kernel with this patch, and on the first
> time we print these things, almost everything is zero, even stuff like
> pipe_bpp, even for enabled pipes. Is this expected?
Lack of
On Thu, May 23, 2013 at 02:03:09PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> A few fixes, nothing shocking:
> - More Haswell pci ids. Includes a pile of marketing spare ids (which
> despite the spare moniker show up all over the place).
> - Fix a regression in handling modeset failures, resulti
On Fri, May 24, 2013 at 10:03:14PM +0100, Chris Wilson wrote:
> On Fri, May 24, 2013 at 09:29:32PM +0200, Daniel Vetter wrote:
> > Chris Wilson noticed that since
> >
> > commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9]
> > Author: Daniel Vetter
> > Date: Thu Nov 15 17:17:22 2012 +0100
>
On Mon, May 27, 2013 at 06:42:42PM +0300, Imre Deak wrote:
> Leaving the GPU running after we exit can mess up timing dependent tests
> we run afterwards.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270
>
> Signed-off-by: Imre Deak
I've flailed around in this area since forever
In the cloned case, changing just one output but keeping the other, the
pipe state won't change and intel_crtc_update_dpms will be a nop, but we
still need to update the dpms state of the output being changed.
Only dvo, sdvo and crt are cloneable, so only those three have special
dpms functions.
On Mon, May 27, 2013 at 02:54:33PM -0300, Rodrigo Vivi wrote:
> Yeap, makes sense let them explicit then...
> Thanks for explanation and fell free to go ahead ;)
Thanks for your review, all patches merged to dinq.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48
It appears that a beneficial side-effect of Mika's more accurate hangman
work is to speed up hang detection and execution. This exposes a bug in
the reset code that then treats repeated simulated hangs as an
indication that the machine is wedged. Jiggle the code around so that we
only do the simula
On Mon, May 27, 2013 at 05:45:53PM -0300, Paulo Zanoni wrote:
> 2013/5/21 Daniel Vetter :
> > + pipe_config->cpu_transcoder = crtc->pipe;
> > + tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
> > + if (tmp & TRANS_DDI_FUNC_ENABLE) {
> > + enum pipe trans_edp_pip
... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.
Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
ove
On Tue, May 28, 2013 at 12:35:02PM +0300, Jani Nikula wrote:
> In the cloned case, changing just one output but keeping the other, the
> pipe state won't change and intel_crtc_update_dpms will be a nop, but we
> still need to update the dpms state of the output being changed.
>
> Only dvo, sdvo an
On Tue, May 28, 2013 at 05:51:44PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENOMEM in the kmap() error handling case
> instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Softw
On Tue, May 28, 2013 at 05:51:44PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENOMEM in the kmap() error handling case
> instead of 0, as done elsewhere in this function.
kmap() can fail?
It is either translated to page_address() or kmap_high() (on x86),
neither of which m
All this pipe config abstraction adds another layer of complexity, so
it's good to have better visibility into what's going on exactly.
Doesn't dump out everything yet, and some bits are a bit duplicated
but this should be a good start.
Note that at boot-up a lot of the fields are 0 even for enabl
On Sat, Apr 27, 2013 at 05:59:19PM -0700, Ben Widawsky wrote:
> HSW has some special requirements for the VEBOX. Splitting out the
> interrupt handler will make the code a bit nicer and less error prone
> when we begin to handle those.
>
> The slight functional change in this patch (queueing work
On Sat, Apr 27, 2013 at 05:59:20PM -0700, Ben Widawsky wrote:
> @@ -2720,12 +2720,12 @@ static void gen6_enable_rps(struct drm_device *dev)
> gen6_set_rps(dev_priv->dev, (gt_perf_status & 0xff00) >> 8);
>
> /* requires MSI enabled */
> - I915_WRITE(GEN6_PMIER, GEN6_PM_DEFERRED_EVE
On Sat, Apr 27, 2013 at 05:59:21PM -0700, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_irq.c | 27 ++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq
On Sat, Apr 27, 2013 at 05:59:22PM -0700, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_irq.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 21b09cd..4a1b7f5 100644
> --
On Sat, Apr 27, 2013 at 05:59:23PM -0700, Ben Widawsky wrote:
> It's overkill on older gens, but it's useful for newer gens.
>
> Signed-off-by: Ben Widawsky
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop
Only lvds/tv did actually check for cloning or not, but many more
places should.
Notices because my ivb tried to enable both cpu edp and vga on the
first crtc - the resulting confusion between has_pch_encoder,
has_dp_encoder but not actually being a pch dp encoder resulting in
hilarity (hitting a
- Correct cpu->pch display matching is already check when we detect
the PCH type at driver load.
- Plane/pipe state is already checked both when a) enabling, b)
disabling and in c) the modeset state checker. No need to go
overboard and also check it in in between a) and b).
Cc: Paulo Zanoni
On Sat, Apr 27, 2013 at 05:59:24PM -0700, Ben Widawsky wrote:
> The motivation here is we're going to add some new interrupt definitions
> and handling outside of the GT interrupts which is all we've managed so
> far (with some RPS exceptions). By consolidating the names in the future
> we can make
2013/5/28 Daniel Vetter :
> All this pipe config abstraction adds another layer of complexity, so
> it's good to have better visibility into what's going on exactly.
> Doesn't dump out everything yet, and some bits are a bit duplicated
> but this should be a good start.
>
> Note that at boot-up a l
Signed-off-by: Imre Deak
---
lib/drmtest.c | 16
1 file changed, 16 insertions(+)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 16f5be1..2d37fb6 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -109,6 +109,7 @@ int gem_available_fences(int fd)
}
+#define LOCAL_I915_EXEC
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270
v2:
- Make sure also that the GPU is idle at start and error exit of any
test using drm_open_any(). (Daniel)
Signed-off-by: Imre Deak
---
lib/drmtest.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
- Correct cpu->pch display matching is already check when we detect
the PCH type at driver load.
- Plane/pipe state is already checked both when a) enabling, b)
disabling and in c) the modeset state checker. No need to go
overboard and also check it in in between a) and b).
Cc: Paulo Zanoni
On Tue, May 28, 2013 at 11:17:34AM -0300, Paulo Zanoni wrote:
> 2013/5/28 Daniel Vetter :
> > All this pipe config abstraction adds another layer of complexity, so
> > it's good to have better visibility into what's going on exactly.
> > Doesn't dump out everything yet, and some bits are a bit dupl
2013/5/28 Daniel Vetter :
> - Correct cpu->pch display matching is already check when we detect
> the PCH type at driver load.
> - Plane/pipe state is already checked both when a) enabling, b)
> disabling and in c) the modeset state checker. No need to go
> overboard and also check it in in b
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270
v2:
- Make sure also that the GPU is idle at start and error exit of any
test using drm_open_any(). (Daniel)
v3:
- actually call gem_quiescent_gpu() at exit
Signed-off-by: Imre Deak
---
lib/drmtest.c | 27 ++-
On Sat, Apr 27, 2013 at 05:59:25PM -0700, Ben Widawsky wrote:
> v2: Use the correct lock to protect PM interrupt regs, this was
> accidentally lost from earlier (Haihao)
> Fix return types (Ben)
>
> CC: Xiang, Haihao
> Signed-off-by: Ben Widawsky
> ---
Reviewed-by: Damien Lespiau
--
Damien
On Sat, Apr 27, 2013 at 05:59:26PM -0700, Ben Widawsky wrote:
> Similar to a patch originally written by:
>
> v2: Reversed the meanings of masked and enabled (Haihao)
> Made non-destructive writes in case enable/disabler rps runs first
> (Haihao)
>
> CC: Xiang, Haihao
> Signed-off-by: Ben Widaws
On Sat, Apr 27, 2013 at 05:59:27PM -0700, Ben Widawsky wrote:
> From: "Xiang, Haihao"
>
> v2 (Ben): s/hsw/hws
>
> Signed-off-by: Xiang, Haihao
> [Order changed, and modified by]
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 13 +
> 1 file changed, 13
On Sat, Apr 27, 2013 at 05:59:28PM -0700, Ben Widawsky wrote:
> From: "Xiang, Haihao"
>
> A user can run batchbuffer via VEBOX ring.
>
> Signed-off-by: Xiang, Haihao
> [Order changed by]
> Signed-off-by: Ben Widawsky
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915
On Sat, Apr 27, 2013 at 05:59:29PM -0700, Ben Widawsky wrote:
> From: "Xiang, Haihao"
>
> This will let userland only try to use the new ring
> when the appropriate kernel is present
>
> Signed-off-by: Xiang, Haihao
> [Order changed, and merge conflict resolved by]
> Signed-off-by: Ben Widawsky
From: Wei Yongjun
Fix to return -ENOMEM in the kmap() error handling case
instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
On Tue, May 28, 2013 at 05:35:32PM +0300, Imre Deak wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270
>
> v2:
> - Make sure also that the GPU is idle at start and error exit of any
> test using drm_open_any(). (Daniel)
> v3:
> - actually call gem_quiescent_gpu() at exit
>
>
On Tue, May 28, 2013 at 02:30:56PM +0100, Damien Lespiau wrote:
> On Sat, Apr 27, 2013 at 05:59:20PM -0700, Ben Widawsky wrote:
> > @@ -2720,12 +2720,12 @@ static void gen6_enable_rps(struct drm_device *dev)
> > gen6_set_rps(dev_priv->dev, (gt_perf_status & 0xff00) >> 8);
> >
> > /* requi
On Tue, May 28, 2013 at 04:06:07PM +0100, Damien Lespiau wrote:
> On Sat, Apr 27, 2013 at 05:59:27PM -0700, Ben Widawsky wrote:
> > From: "Xiang, Haihao"
> >
> > v2 (Ben): s/hsw/hws
> >
> > Signed-off-by: Xiang, Haihao
> > [Order changed, and modified by]
> > Signed-off-by: Ben Widawsky
> > --
On Tue, May 28, 2013 at 03:01:54PM +0100, Damien Lespiau wrote:
> On Sat, Apr 27, 2013 at 05:59:24PM -0700, Ben Widawsky wrote:
> > The motivation here is we're going to add some new interrupt definitions
> > and handling outside of the GT interrupts which is all we've managed so
> > far (with some
On Tue, May 21, 2013 at 1:28 PM, Ben Guthro wrote:
> On Tue, May 21, 2013 at 10:02 AM, Daniel Vetter wrote:
>> On Tue, May 21, 2013 at 3:44 PM, Ben Guthro wrote:
This will break kms since now you have the vbios and the linux kms driver
fighting over the same piece of hw. Does
Hi Dave,
So I've figured it's time to upon up drm-next with a nice pile of intel
patches. And there seems to be some other stuff pending on dri-devel
already, too ;-)
Highlights (copy-pasted from my testing cycle mails):
- fbc support for Haswell (Rodrigo)
- streamlined workaround comments, inclu
WaFbcNukeOn3DBlt for IVB, HSW and VLV.
According BSPec: "Workaround: Do not enable Render Command Streamer tracking
for FBC.
Instead insert a LRI to address 0x50380 with data 0x0004 after the
PIPE_CONTROL that
follows each render submission."
v2: Chris noticed that flush_domains check was m
Ops, sorry about miss "in-reply-to".. I was here fighting with my git
send-email for a long time doing many attempts...
Anyways, going to the point.
Ville, I decide to let it without SRM described in PM guide because it
doesn't not work properly. I' ve made many attempts here but it doesn'
t work
The primary change in this series is I introduce the
ivybridge_preinstall and "Add PM regs to pre/post install"
before make "PM interrupt writes non-destructive". This helps address
the issue Damien caught where the PMIMR is never cleared midway through
the series. On that note, I fixed a bug intro
Semaphores are tied very closely to the rings in the GPU. Trivial patch
adds comments to the existing code so that when we add new rings we can
include comments there as well. It also helps distinguish the ring to
semaphore mailbox interactions by using the ringname in the semaphore
data structures
This replaces the existing MBOX update code with a more generalized
calculation for emitting mbox updates. We also create a sentinel for
doing the updates so we can more abstractly deal with the rings.
When doing MBOX updates the code must be aware of the /other/ rings.
Until now the platforms whi
The video enhancement command streamer is a new ring on HSW which does
what it sounds like it does. This patch provides the most minimal
inception of the ring.
In order to support a new ring, we need to bump the number. The patch
may look trivial to the untrained eye, but bumping the number of rin
Like the other rings, the VECS supports semaphores. The semaphore stuff
is a bit wonky so this patch on it's own should be nice for review.
This patch should have no functional impact.
v2: Fix the English parts of clarification (again, register names were
right, text was reversed) (Damien)
Restor
v2: Use the correct lock to protect PM interrupt regs, this was
accidentally lost from earlier (Haihao)
Fix return types (Ben)
Reviewed-by: Damien Lespiau
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 46 +++--
drivers/gpu/drm/i915/intel_r
HSW has some special requirements for the VEBOX. Splitting out the
interrupt handler will make the code a bit nicer and less error prone
when we begin to handle those.
The slight functional change in this patch (queueing work while holding
the spinlock) is intentional as it makes a subsequent patc
v2: Add new PCH_NOP check (Damien)
Add SDEIMR comment (Damien)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_irq.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
i
From: "Xiang, Haihao"
The flag will be useful to help share code between IVB, and HSW as the
programming is similar in many places with this as one of the major
differences.
Signed-off-by: Xiang, Haihao
[Commit message + small fix by]
Reviewed-by: Damien Lespiau
Signed-off-by: Ben Widawsky
--
At the moment, these values are wiped out anyway by the rps
enable/disable. That will be changed in the next patch though.
v2: Add post install setup to address issue found by Damien in the next
patch.
replaced
WARN_ON(dev_priv->rps.pm_iir != 0);
with rps.pm_iir = 0;
With the v2 of this patch and
Historically we considered the render ring to have special flush
semantics and everything else to fall under a more general umbrella.
Probably by coincidence more than anything we decided to make the bsd
ring have the default *other* flush. As the new vebox ring exposes, the
bsd ring is actually th
PM interrupts have an expanded role on HSW. It helps route the EBOX
interrupts. This patch is necessary to make the existing code which
touches the mask, and enable registers more friendly to other code paths
that also will need these registers.
To be more explicit:
At preinstall all interrupts ar
It's overkill on older gens, but it's useful for newer gens.
Reviewed-by: Damien Lespiau
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 16
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +++-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --gi
v2: Add set_seqno which didn't exist before rebase (Haihao)
Signed-off-by: Ben Widawsky
Reviewed-by: Damien Lespiau
Signed-off-by: Xiang, Haihao
---
drivers/gpu/drm/i915/i915_gem.c | 11 ++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c
The motivation here is we're going to add some new interrupt definitions
and handling outside of the GT interrupts which is all we've managed so
far (with some RPS exceptions). By consolidating the names in the future
we can make thing a bit cleaner as we don't need to define register
names twice,
From: "Xiang, Haihao"
A user can run batchbuffer via VEBOX ring.
Signed-off-by: Xiang, Haihao
Reviewed-by: Damien Lespiau
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +
include/uapi/drm/i915_drm.h| 1 +
2 files changed, 10 insertions
From: "Xiang, Haihao"
v2: Removed rebase relic VECS ring from i915_gem_request_info (Damien)
Signed-off-by: Xiang, Haihao
[Order changed, and modified by]
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/
From: "Xiang, Haihao"
This will let userland only try to use the new ring
when the appropriate kernel is present
Signed-off-by: Xiang, Haihao
Reviewed-by: Damien Lespiau
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
include/uapi/drm/i915_drm.h | 2 +-
2 files c
Similar to a patch originally written by:
v2: Reversed the meanings of masked and enabled (Haihao)
Made non-destructive writes in case enable/disabler rps runs first
(Haihao)
v3: Reword error message (Damien)
Modify postinstall to do the right thing based on previous fixup. (Ben)
CC: Xiang, Haih
This will allow us to use the same code paths whether or not we have
PPGTT actually turned on. It will do all but actually enable the bits
that tell the HW to use PPGTT.
This patch also will help tie together contexts and PPGTT in the next
patch. That patch wants to disable contexts if there is no
62 matches
Mail list logo
