On Thu, May 23, 2013 at 03:06:01PM -0300, Rodrigo Vivi wrote:
> Thanks Damien, I'll incorporate the nuke name.
>
> Ville, I though this SRM was just when adding the one for PSR, but now
> you pointed out I' ve seen it on PM enabling guide. This LRI without
> the SRM by itself already solved render
At Thu, 23 May 2013 19:41:58 +0200,
David Henningsson wrote:
>
> On 05/23/2013 12:29 PM, Wang, Xingchao wrote:
> >
> >
> >> -Original Message-
> >> From: Takashi Iwai [mailto:ti...@suse.de]
> >> Sent: Thursday, May 23, 2013 6:27 PM
> >> To: Wang, Xingchao
> >> Cc: Wang Xingchao; alsa-de...
On Wed, May 1, 2013 at 6:23 PM, Daniel Vetter wrote:
> On Wed, May 1, 2013 at 3:01 PM, Chris Wilson wrote:
>> On Wed, May 01, 2013 at 02:40:43PM +0200, Daniel Vetter wrote:
>>> On Wed, May 1, 2013 at 1:06 PM, Chris Wilson
>>> wrote:
>>> > On Wed, May 01, 2013 at 12:38:27PM +0200, Daniel Vetter
On Wed, May 08, 2013 at 12:55:17PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Check if the CRTC framebuffer matches the fbdev helper's framebuffer,
> and if it does, doen't enable cursors/sprites.
>
> Signed-off-by: Ville Syrjälä
This one here had conflicts. But it a
On Wed, May 08, 2013 at 12:55:18PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> plane->enabled is never set, so this code didn't do anything.
>
> If we end up doing a full modeset, sprites already get disabled. However
> if we end up doing a simple set_base, we still nee
On Wed, May 08, 2013 at 12:55:18PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> plane->enabled is never set, so this code didn't do anything.
>
> If we end up doing a full modeset, sprites already get disabled. However
> if we end up doing a simple set_base, we still nee
On Fri, May 24, 2013 at 11:03:06AM +0200, Daniel Vetter wrote:
> On Wed, May 1, 2013 at 6:23 PM, Daniel Vetter wrote:
> > The atomic_set(WEDGED) is imo very dangerous, since it'll wreak havoc
> > with our accounting. But in general I really prefer an angry user with
> > a stuck-process backtrace t
On Fri, May 24, 2013 at 11:20:21AM +0200, Daniel Vetter wrote:
> On Wed, May 08, 2013 at 12:55:17PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Check if the CRTC framebuffer matches the fbdev helper's framebuffer,
> > and if it does, doen't enable cursors/sprites.
On Fri, May 24, 2013 at 11:35:07AM +0200, Daniel Vetter wrote:
> On Wed, May 08, 2013 at 12:55:18PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > plane->enabled is never set, so this code didn't do anything.
> >
> > If we end up doing a full modeset, sprites already
If reset fails, the GPU is declared wedged. This ideally should never
happen, but very rarely it does. After the GPU is declared wedged, we
must allow userspace to continue to use its mapping of bo in order to
recover its data (and in some cases in order for memory management to
continue unabated).
On Fri, May 24, 2013 at 01:41:22AM +0200, Daniel Vetter wrote:
> On Thu, May 23, 2013 at 11:30 PM, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > But only the first 2048 lines will be compressed. No problem.
> >
> > With this I can finally see FBC on my 2560x1440 DP monitor, which
> > gives m
Instead of relying in acthd, track ring seqno progression
to detect if ring has hung.
v2: put hangcheck stuff inside struct (Chris Wilson)
v3: initialize hangcheck.seqno (Ben Widawsky)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h |2 --
drivers/gpu/drm/i915/i915
From: Paulo Zanoni
Hi
This series is a new version of "drm/i915: replace snb_update_wm with
haswell_update_wm on HSW". Ville asked to split the series into smaller patches,
so here they are. I also implemented the other suggestions made by Ville.
After this series, the only thing missing for co
From: Paulo Zanoni
Because we want to call it from the "sprite disable" paths, since on
Haswell we need to update the sprite watermarks when we disable
sprites.
For now, all this patch does is to add the "enable" argument and call
intel_update_sprite_watermarks from inside ivb_disable_plane. Thi
From: Paulo Zanoni
On Haswell, whenever we change the sprites we need to completely
recalculate all the watermarks, because the sprites are one of the
parameters to the LP watermarks, so a change on the sprites may
trigger a change on which LP levels are enabled.
So on this commit we store all t
From: Paulo Zanoni
We were previously calling sandybridge_update_wm on HSW, but the SNB
function didn't really match the HSW specification, so we were just
writing the wrong values.
With this patch, the haswell_update_wm function will set the correct
values for the WM_PIPE registers, but it will
From: Paulo Zanoni
We were previously only setting the WM_PIPE registers, now we are
setting the LP watermark registers. This should allow deeper PC
states, resulting in power savings.
We're only using 1/2 data buffer partitioning for now.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/
From: Paulo Zanoni
Now we compute the results for both 1/2 and 5/6 partitioning and then
use hsw_find_best_result to choose which one to use.
With this patch, Haswell watermarks support should be in good shape.
The only improvement we're missing is the case where the primary plane
is disabled: w
2013/5/22 Ville Syrjälä :
> On Tue, May 21, 2013 at 06:24:38PM -0300, Paulo Zanoni wrote:
>> Hi
>>
>> 2013/5/20 Ville Syrjälä :
>> > On Thu, May 09, 2013 at 05:13:41PM -0300, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> We were previously calling sandybridge_update_wm on HSW, but the S
On Fri, May 24, 2013 at 11:59 AM, Ville Syrjälä
wrote:
>
>> Why exactly do we need special driver callbacks for all this? Strictly
>> speaking fbcon is just another kms client, if it needs to dig around in
>> driver details that just means our interfaces are not good enough. I know
>> that there's
On Fri, May 24, 2013 at 11:59:19AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We were previously calling sandybridge_update_wm on HSW, but the SNB
> function didn't really match the HSW specification, so we were just
> writing the wrong values.
>
> With this patch, the haswell_update_wm
On Fri, May 24, 2013 at 12:05:15PM -0300, Paulo Zanoni wrote:
> 2013/5/22 Ville Syrjälä :
> > On Tue, May 21, 2013 at 06:24:38PM -0300, Paulo Zanoni wrote:
> >> Hi
> >>
> >> 2013/5/20 Ville Syrjälä :
> >> > On Thu, May 09, 2013 at 05:13:41PM -0300, Paulo Zanoni wrote:
> >> >> From: Paulo Zanoni
>
On Fri, May 24, 2013 at 11:59:20AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We were previously only setting the WM_PIPE registers, now we are
> setting the LP watermark registers. This should allow deeper PC
> states, resulting in power savings.
>
> We're only using 1/2 data buffer pa
On Fri, May 24, 2013 at 6:07 PM, Daniel Vetter wrote:
> pfit_size stores the request mode, which matches crtc->config.requested
> mode. Instead of jumping through hoops I think I'd be better to directly
> use those values ...
Scrap that, I can't read code ;-)
-Daniel
--
Daniel Vetter
Software Eng
On Fri, May 24, 2013 at 06:13:15PM +0200, Daniel Vetter wrote:
> On Fri, May 24, 2013 at 6:07 PM, Daniel Vetter wrote:
> > pfit_size stores the request mode, which matches crtc->config.requested
> > mode. Instead of jumping through hoops I think I'd be better to directly
> > use those values ...
>
On Fri, May 24, 2013 at 11:59:17AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because we want to call it from the "sprite disable" paths, since on
> Haswell we need to update the sprite watermarks when we disable
> sprites.
>
> For now, all this patch does is to add the "enable" argumen
On Fri, May 24, 2013 at 11:59:18AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> On Haswell, whenever we change the sprites we need to completely
> recalculate all the watermarks, because the sprites are one of the
> parameters to the LP watermarks, so a change on the sprites may
> trigger
On Fri, May 24, 2013 at 05:14:40PM +0200, Daniel Vetter wrote:
> On Fri, May 24, 2013 at 11:59 AM, Ville Syrjälä
> wrote:
> >
> >> Why exactly do we need special driver callbacks for all this? Strictly
> >> speaking fbcon is just another kms client, if it needs to dig around in
> >> driver details
On Tue, 21 May 2013 21:54:57 +0200
Daniel Vetter wrote:
> - if (clock < 20) {
> + if (crtc->config.port_clock == 162000) {
> /* For a long time we've carried around a ILK-DevA w/a for the
>* 160MHz clock. If we're really unlucky, it's still required.
>
On Mon, May 13, 2013 at 04:32:11PM +0300, Mika Kuoppala wrote:
> In preparation to track per ring progress in hangcheck,
> add i915_hangcheck_ring_hung.
>
> v2: omit dev parameter (Ben Widawsky)
>
> Signed-off-by: Mika Kuoppala
With the updated patch 2, patches 1-3 are:
Reviewed-by: Ben Widawsk
Chris Wilson noticed that since
commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9]
Author: Daniel Vetter
Date: Thu Nov 15 17:17:22 2012 +0100
drm/i915: clear up wedged transitions
X can again get -EIO when it does not expect it. And even worse score
a SIGBUS when accessing gtt mmaps.
On Fri, May 24, 2013 at 08:00:26PM +0300, Ville Syrjälä wrote:
> On Fri, May 24, 2013 at 11:59:18AM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > On Haswell, whenever we change the sprites we need to completely
> > recalculate all the watermarks, because the sprites are one of the
> >
On Fri, May 24, 2013 at 7:06 PM, Ville Syrjälä
wrote:
> On Fri, May 24, 2013 at 05:14:40PM +0200, Daniel Vetter wrote:
>> On Fri, May 24, 2013 at 11:59 AM, Ville Syrjälä
>> wrote:
>> >
>> >> Why exactly do we need special driver callbacks for all this? Strictly
>> >> speaking fbcon is just anothe
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
>
> drm/i915: clear up wedged transitions
>
> X can again get -EIO whe
2013/5/24 Ville Syrjälä :
> On Fri, May 24, 2013 at 11:59:19AM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> We were previously calling sandybridge_update_wm on HSW, but the SNB
>> function didn't really match the HSW specification, so we were just
>> writing the wrong values.
>>
>> With
From: Paulo Zanoni
We were previously calling sandybridge_update_wm on HSW, but the SNB
function didn't really match the HSW specification, so we were just
writing the wrong values.
With this patch, the haswell_update_wm function will set the correct
values for the WM_PIPE registers, but it will
From: Paulo Zanoni
We were previously only setting the WM_PIPE registers, now we are
setting the LP watermark registers. This should allow deeper PC
states, resulting in power savings.
We're only using 1/2 data buffer partitioning for now.
v2: Merge both hsw_compute_pri_wm_* functions (Ville)
37 matches
Mail list logo
