In
Author: Daniel Vetter
Date: Wed Jun 5 13:34:23 2013 +0200
drm/i915: consolidate pch pll enable sequence
I've removed all the code from this if block, but somehow forgotten to
kill the block itself.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 fi
On Wed, 16 Oct 2013, Jani Nikula wrote:
> This isn't a real fix to the problem, but rather a stopgap measure while
> trying to find a proper solution.
>
> There are several laptops out there that fail to light up the eDP panel
> in UEFI boot mode. They seem to be mostly IVB machines, including but
On 10/16/13 9:21 AM, Ben Widawsky wrote:
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot currently explain why the l
v2: Fixed the botched locking on init_hw failure in i915_reset (Ville)
Call cleanup_ringbuffer on failed context create in init_hw (Ville)
v3: Add dev argument ti clean_ringbuffer
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
dri
On Thu, Oct 17, 2013 at 02:49:54PM -0700, Ben Widawsky wrote:
> v2: Fixed the botched locking on init_hw failure in i915_reset (Ville)
> Call cleanup_ringbuffer on failed context create in init_hw (Ville)
>
> Reviewed-by: Kenneth Graunke
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i91
v2: Fixed the botched locking on init_hw failure in i915_reset (Ville)
Call cleanup_ringbuffer on failed context create in init_hw (Ville)
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
drivers/gpu/drm/i915/i915_drv.h | 3
On Thu, Oct 17, 2013 at 02:04:34PM -0700, Ben Widawsky wrote:
> On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote:
> > On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> > > On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > > > If we force the hw to idle as o
On Thu, Oct 17, 2013 at 08:37:44PM +0100, Chris Wilson wrote:
> On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> > On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > > If we force the hw to idle as our first step during unload, we can abort
> > > the unload upon failur
On Thu, Oct 17, 2013 at 10:53:14PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> For some reason we're enabling sprite scaling on ILK always. That
> doesn't work well with the new watermark code that expects to use
> LP1 watermarks with unscaled sprites.
>
> Only enable s
From: Ville Syrjälä
Group the sprite register writes a bit tighter. We want to write
the registers atomically, and so doing the base address/offset
artihmetic within the critical section is pointless when it can
all be done beforehand.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/inte
From: Ville Syrjälä
Add trace points for observing the atomic pipe update mechanism.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_trace.h | 77 +
drivers/gpu/drm/i915/intel_sprite.c | 6 +++
2 files changed, 83 insertions(+)
diff --git a/dr
From: Ville Syrjälä
Move the primary plane enable/disable to occur atomically with the
sprite update that caused the primary plane visibility to change.
FBC and IPS enable/disable is left to happen well before or after
the primary plane change.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm
From: Ville Syrjälä
Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.
We do the vblank evade by che
From: Ville Syrjälä
Refactor the i915_get_crtc_scanoutpos() code a bit to make the
"negative values during vblank" adjustment optional. For most uses
the raw scanline number without such adjustments is easier to use.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 46 ++
From: Ville Syrjälä
For some reason we're enabling sprite scaling on ILK always. That
doesn't work well with the new watermark code that expects to use
LP1 watermarks with unscaled sprites.
Only enable sprite scaling on ILK when actually needed, just like
we do on SNB.
Signed-off-by: Ville Syrj
From: Ville Syrjälä
When color keying is used, the primary may not be invisible even though
the sprite fully covers it. So check for color keying before deciding to
disable the primary plane.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 11 ++-
1 file changed,
Today I heard some grumblings about atomic updates again, so I decided
to move the thing forward a bit. This series only makes sprite
updates + the accompanying primary enable/disable happen atomically.
But it's a decent baby step towards full atomic updates. At least we
would get the vblank evade
On Thu, Oct 17, 2013 at 12:07:26PM -0700, Ben Widawsky wrote:
> On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> > If we force the hw to idle as our first step during unload, we can abort
> > the unload upon failure. Later we can probe whether the hardware remain
> > active even afte
On Thu, Oct 17, 2013 at 01:02:53PM +0100, Chris Wilson wrote:
> If we force the hw to idle as our first step during unload, we can abort
> the unload upon failure. Later we can probe whether the hardware remain
> active even after we try to shut it down.
>
> Signed-off-by: Chris Wilson
Isn't it
On Thu, Oct 17, 2013 at 08:52:17PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 17, 2013 at 09:59:43AM -0700, Ben Widawsky wrote:
> > From: Ben Widawsky
> >
> > Only compile tested
> >
> > CC: Kenneth Graunke
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/i915_drv.c |
On Thu, Oct 17, 2013 at 09:59:43AM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> Only compile tested
>
> CC: Kenneth Graunke
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_drv.c | 5 +---
> drivers/gpu/drm/i915/i915_drv.h | 3 +--
> drivers/gpu/drm/i91
On 10/17/2013 09:59 AM, Ben Widawsky wrote:
> From: Ben Widawsky
>
> Only compile tested
>
> CC: Kenneth Graunke
> Signed-off-by: Ben Widawsky
The code looks good to me (but I didn't test it either). I'm in favor
of this happening.
Reviewed-by: Kenneth Graunke
_
From: Ben Widawsky
Only compile tested
CC: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 5 +---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/i915_gem.c | 7 +-
drivers/gpu/drm/i915/i915_gem_context.c | 43 +++
On Wed, May 22, 2013 at 04:48:15PM +0800, Xiong Zhang wrote:
> HDMI Compliance Testing fail on i915 driver, the error log show:
> M1-M0=0b00(NO Data) of AVI InfoFrame Packet should correspond to the
> aspect ratio of the viewed image.Skip because AVI R3-R0 is no 1000
> (Same as picture aspect ratio
Daniel pointed out that it was hard to get anything lockless to work
correctly, so don't even try for this non critical piece of code and
just use a spin lock.
v2: Make intel_pipe_crc->opened a bool
v3: Use assert_spin_locked() instead of a comment (Daniel)
Suggested-by: Daniel Vetter
Signed-off
Daniel pointed out that it was hard to get anything lockless to work
correctly, so don't even try for this non critical piece of code and
just use a spin lock.
v2: Make intel_pipe_crc->opened a bool
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs
Daniel pointed out that it was hard to get anything lockless to work
correctly, so don't even try for this non critical piece of code and
just use a spin lock.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 53 ++--
On Wed, 2013-10-16 at 19:46 +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
> > From: Artem Bityutskiy
> >
> > This patch changes HDMI port registration order for the BayTrail platform.
> >
> > The story is that in kernel version 3.11 i915 supporte
On Thu, Oct 17, 2013 at 11:53:49AM +0100, Damien Lespiau wrote:
> On Wed, Oct 16, 2013 at 10:55:52PM +0200, Daniel Vetter wrote:
> > hw designers decided to change the CRC registers and coalesce them all
> > into one. Otherwise nothing changed. I've opted for a new hsw_ version
> > to grab the crc
On Wed, 2013-10-16 at 08:08 -0700, Jesse Barnes wrote:
> On Wed, 16 Oct 2013 14:10:13 +0300
> Imre Deak wrote:
>
> > On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote:
> > > On Tue, 15 Oct 2013 16:54:00 -0300
> > > Paulo Zanoni wrote:
> > > [...]
> > > No that's taken into account here. In
On Thu, Oct 17, 2013 at 02:37:07PM +0200, Daniel Vetter wrote:
> Failed to properly test this.
>
> Reported-by: Chris Wilson
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
Tested-by: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
On Thu, Oct 17, 2013 at 09:01:52AM -0300, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Wed, Oct 16, 2013 at 6:34 AM, Jani Nikula wrote:
> > The HDMI audio expects HDMI pixel clock to be set in the audio
> > configuration. We've currently just set 0, using 25.2 / 1.001 kHz
> > frequency
Failed to properly test this.
Reported-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5fc
For me this patch makes sense and swith to fbcon is faster, so:
Reviewed-by: Rodrigo Vivi
with this -collector is "empty"... at least until next -testing update.
On Mon, Oct 7, 2013 at 5:15 PM, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> A simple modeset, where we only wish to switch over to
If we force the hw to idle as our first step during unload, we can abort
the unload upon failure. Later we can probe whether the hardware remain
active even after we try to shut it down.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c | 10 ++
1 file changed, 6 insertions
Reviewed-by: Rodrigo Vivi
On Wed, Oct 16, 2013 at 6:34 AM, Jani Nikula wrote:
> This will be needed for setting the HDMI pixel clock for audio
> config. No functional changes.
>
> v2: Now with a commit message.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h |3
Reviewed-by: Rodrigo Vivi
On Wed, Oct 16, 2013 at 6:34 AM, Jani Nikula wrote:
> The HDMI audio expects HDMI pixel clock to be set in the audio
> configuration. We've currently just set 0, using 25.2 / 1.001 kHz
> frequency, which fails with some modes.
>
> v2: Now with a commit message.
>
> Refe
On Tue, Oct 8, 2013 at 3:18 PM, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> tools/Makefile.am |1 +
> tools/intel_opregion_decode.c | 438
> +
> 2 files changed, 439 insertions(+)
> create mode 100644 tools/intel_opregion_dec
Thank you Danmien for helping with this.
It's moving so fast. I'm looking forward we could create some automation test
for media also
Thanks
--Shuang
> -Original Message-
> From: Lespiau, Damien
> Sent: Wednesday, October 16, 2013 1:55 AM
> To: intel-gfx@lists.freedesktop.org
> C
On Wed, Oct 16, 2013 at 10:55:52PM +0200, Daniel Vetter wrote:
> hw designers decided to change the CRC registers and coalesce them all
> into one. Otherwise nothing changed. I've opted for a new hsw_ version
> to grab the crc sample since hsw+1 will have the same crc registers,
> but different int
At Thu, 17 Oct 2013 10:24:07 +0100,
Chris Wilson wrote:
>
> On Thu, Oct 17, 2013 at 09:41:09AM +0200, Takashi Iwai wrote:
> > At Wed, 16 Oct 2013 18:27:33 +0100,
> > Chris Wilson wrote:
> > >
> > > On Wed, Oct 16, 2013 at 10:06:27AM -0700, Ben Widawsky wrote:
> > > > On Wed, Oct 16, 2013 at 05:58
From: Ville Syrjälä
Use the same wait_for_vblank code for CTG that we use for ILK+.
Also fix the name of the frame counter register while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dr
From: Ville Syrjälä
When the hardware frame counter reads 0xff and we're already past
vblank start, we'd return 0x100 as the vblank counter value. Once
we'd cross into the next frame's active portion, the vblank counter
would wrap to 0. So we're reporting two different vblank counter valu
On Thu, Oct 17, 2013 at 09:41:09AM +0200, Takashi Iwai wrote:
> At Wed, 16 Oct 2013 18:27:33 +0100,
> Chris Wilson wrote:
> >
> > On Wed, Oct 16, 2013 at 10:06:27AM -0700, Ben Widawsky wrote:
> > > On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
> > > > So clearing the valid bit shou
Hello,
I've been directed here from the Fedora developers list, looking for some
answers regarding computers with bi-directional DisplayPorts/Thunderbolt ports.
The iMac and HP Z1 have one, which lets them be used as a Display for another
computer, while that computer is still running. Apple c
At Wed, 16 Oct 2013 18:27:33 +0100,
Chris Wilson wrote:
>
> On Wed, Oct 16, 2013 at 10:06:27AM -0700, Ben Widawsky wrote:
> > On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
> > > So clearing the valid bit should result in the GPU reporting errors for
> > > delayed accesses, but none
On Thu, Oct 17, 2013 at 01:00:42AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, October 08, 2013 10:56:11 AM Daniel Vetter wrote:
> > The drm/i915 driver wants to adjust it's own power policies using the
> > cpu policies as a guideline (we can implicitly boost the cpus through
> > the gpus on some
47 matches
Mail list logo
