On Tue, Feb 12, 2013 at 03:36:03PM +0100, Daniel Vetter wrote:
> This has been lost in the locking rework for intel_alloc_context_page:
>
> commit 2c34b850ee1e9f86b41706149d0954eee58757a3
> Author: Ben Widawsky
> Date: Sat Mar 19 18:14:26 2011 -0700
>
> drm/i915: fix ilk rc6 teardown locki
On Tue, Feb 12, 2013 at 10:01:39PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The bit controlling whether PIPE_CONTROL DW/QW write targets
> the global GTT or PPGTT moved moved from DW 2 bit 2 to
> DW 1 bit 24 on IVB.
>
> TODO: need to test on IVB actually and make sur
On Tue, Feb 12, 2013 at 10:01:38PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We already print the HWS addresses during init, so do the same for the
> pipe control page. Reduces guesswork when looking at hex addresses
> later.
>
> Signed-off-by: Ville Syrjälä
Queued
From: Ville Syrjälä
The bit controlling whether PIPE_CONTROL DW/QW write targets
the global GTT or PPGTT moved moved from DW 2 bit 2 to
DW 1 bit 24 on IVB.
TODO: need to test on IVB actually and make sure things don't
explode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h
From: Ville Syrjälä
We already print the HWS addresses during init, so do the same for the
pipe control page. Reduces guesswork when looking at hex addresses
later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/d
On Fri, Feb 8, 2013 at 8:36 PM, Kamal Mostafa wrote:
> > Daniel's backlight fixes which landed in 3.6 did enable working
> > backlight controls on the XPS13, but it appears that this commit from
> > Paolo broke it again:
> > a4f32fc drm/i915: don't forget the PCH backlight registers
On Fr
On Tue, Feb 12, 2013 at 07:37:08PM +0200, Jani Nikula wrote:
> On Tue, 12 Feb 2013, Chris Wilson wrote:
> > On Tue, Feb 12, 2013 at 07:06:59PM +0200, Jani Nikula wrote:
> >> Keep all the platform output selection in intel_output_setup(), and don't
> >> scatter it around.
> >
> > I see this as doin
On Tue, 12 Feb 2013, Chris Wilson wrote:
> On Tue, Feb 12, 2013 at 07:06:59PM +0200, Jani Nikula wrote:
>> Keep all the platform output selection in intel_output_setup(), and don't
>> scatter it around.
>
> I see this as doing the opposite. You are littering an already over
> complicated routine w
On Tue, Feb 12, 2013 at 07:06:59PM +0200, Jani Nikula wrote:
> Keep all the platform output selection in intel_output_setup(), and don't
> scatter it around.
I see this as doing the opposite. You are littering an already over
complicated routine with LVDS specific information.
> As a useful side
Keep all the platform output selection in intel_output_setup(), and don't
scatter it around. As a useful side effect, do not try to enable LVDS on
HSW or VLV.
Some checks are done in a slightly different order than before, and on some
platforms VGA is now initialized before LVDS.
Signed-off-by: J
Originally dev->struct_mutex protected all kinds of things for rps/ips
(debugfs access, driver state, ...). Nowadays we have
dev_priv->rps.lock for this, so only the ilk ips code needs it really.
Push the locking down. I haven't yet changed the cleanup side since
there we lock large parts of the c
Could lead to tears if the work indeed runs after we've destroyed the
fbdev ... Totally unlikely to happen though in reality.
Signed-off-by: Daniel Vetter
---
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/
This has been lost in the locking rework for intel_alloc_context_page:
commit 2c34b850ee1e9f86b41706149d0954eee58757a3
Author: Ben Widawsky
Date: Sat Mar 19 18:14:26 2011 -0700
drm/i915: fix ilk rc6 teardown locking
Cc: Ben Widawsky
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915
Hi all,
Three patches for little things I've recently noticed. The long-term aim behind
the last one is to slowly reduce the scope of struct_mutex and clarify what's
actually protected by it.
Comments highly welcome.
Cheers, Daniel
Daniel Vetter (3):
drm/i915: remove bogus mutex_unlock from e
From: Damien Lespiau
Invoking say,
sudo ./tests/gem_render_linear_blits 1
does not make a lot of sense as we're creating a single bo. The test
does not yell at you and passes, even if the rendercopy function does
not do anything. This makes it quite harmful when trying to debug
rendercopy wit
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, w
On Fri, Feb 08, 2013 at 04:35:38PM +0200, Mika Kuoppala wrote:
> commit c1d1f5aeda2033d96e872f416388653f05d4c16d
> Author: Mika Kuoppala
> Date: Tue Feb 5 17:26:52 2013 +0200
>
> drm/i915: disable shared panel fitter for pipe
>
> moved panel fit disabling to be crtc property. Thus
> the ne
On Thu, Feb 07, 2013 at 11:15:26AM -0200, Paulo Zanoni wrote:
> 2013/2/7 Daniel Vetter :
> > They're physically the same pins and also the same bits, duplicating
> > only confuses the reader. This also makes it a bit obvious that we
> > have quite some code duplication going on here. Squashing that
On Sat, Feb 09, 2013 at 12:24:02PM -0800, Ben Widawsky wrote:
> On Sat, Feb 09, 2013 at 09:03:42PM +0100, Daniel Vetter wrote:
> > Some early bios versions seem to ship with the wrong tuning values for
> > the MCH, possible resulting in pipe underruns under load. Especially
> > on DP outputs this c
On Mon, Feb 11, 2013 at 01:31:27PM -0800, Ben Widawsky wrote:
> It's not that the assertion is incorrect, but rather that we can call
> do_destroy early in loading, and we will falsely BUG().
>
> Since contexts have been in for a while now, and in the internal APIs
> are pretty stable, it should b
20 matches
Mail list logo
