On Wed, Apr 10, 2013 at 07:43:39PM -0700, Ben Widawsky wrote:
> I think this is a nice generalization on it's own, but it's primarily
> prep work for my PPGTT support. Does this bother anyone?
>
> The only down side I can see is we waste 2k of cpu unmappable space
> (unless we have something else
Oops forget the RFC tag in the subject.
[snip]
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
I think this is a nice generalization on it's own, but it's primarily
prep work for my PPGTT support. Does this bother anyone?
The only down side I can see is we waste 2k of cpu unmappable space
(unless we have something else that is <= 2k and doesn't need to be page
aligned).
It's RFC because I
On Wed, Apr 10, 2013 at 02:41:39PM -0700, Jesse Barnes wrote:
> On Wed, 10 Apr 2013 20:45:11 +0100
> Chris Wilson wrote:
>
> > + ring_freq = (gpu_freq * 5 + 3) / 4;
> > + ring_freq = max(max_ring_freq, ring_freq);
>
> Should this be min(max_ring_freq, ring_fre
On Wed, 10 Apr 2013 20:45:11 +0100
Chris Wilson wrote:
> + ring_freq = (gpu_freq * 5 + 3) / 4;
> + ring_freq = max(max_ring_freq, ring_freq);
Should this be min(max_ring_freq, ring_freq)? Otherwise it seems like
every ia_freq will correspond to the highes
dp_init_connector adjusts the encoder type if it is a eDP panel. Use
that to decide whether we should set up a hdmi connector or not.
To do so reorder the hdmi connector setup sequence in ddi_init a bit.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 25 +++---
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the en
On Wed, Apr 10, 2013 at 08:45:11PM +0100, Chris Wilson wrote:
> Haswell introduces a separate frequency domain for the ring (uncore). So
> where we used to increase the CPU (IA) clock with GPU busyness, we now
> need to scale the ring frequency directly instead. As the ring limits
> our memory band
On Wed, Apr 10, 2013 at 7:27 PM, Richard Cochran
wrote:
> On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
>>
>> It's written against drm-intel-next-queued at
>>
>> http://cgit.freedesktop.org/~danvet/drm-intel
>>
>> I've thought that it should apply pretty cleanly against older kern
Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we incre
Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we incre
On Wed, Apr 10, 2013 at 03:27:05PM +0100, Chris Wilson wrote:
> On Fri, Sep 07, 2012 at 10:51:44AM -0700, Ben Widawsky wrote:
> > On Fri, 7 Sep 2012 12:03:37 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, Sep 06, 2012 at 01:54:10PM -0700, Ben Widawsky wrote:
> > > > From: Jesse Barnes
> > > >
On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
>
> It's written against drm-intel-next-queued at
>
> http://cgit.freedesktop.org/~danvet/drm-intel
>
> I've thought that it should apply pretty cleanly against older kernels,
> too. Apparently it conflicts a bit in intel_modeset_set
On Mon, 2013-04-08 at 15:48 -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
> are being zeroed, but I couldn't find a reason for this, so leave them
> as they are for now to avoid regressions.
>
> Signed-off-by: Paulo Zanon
On Tue, Apr 09, 2013 at 05:25:50PM -0700, Ben Widawsky wrote:
> Looks like a some remnant from a rebase.
>
> Signed-off-by: Ben Widawsky
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers
On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> It will be only consistent once we've restored all the crtcs. Since a
> bunch of other callers also want to just restore a single crtc, add a
> boolean to disable checking only where it doesn't make sense.
>
> Note that intel_modeset
On Fri, Sep 07, 2012 at 10:51:44AM -0700, Ben Widawsky wrote:
> On Fri, 7 Sep 2012 12:03:37 +0200
> Daniel Vetter wrote:
>
> > On Thu, Sep 06, 2012 at 01:54:10PM -0700, Ben Widawsky wrote:
> > > From: Jesse Barnes
> > >
> > > On SNB and IVB, there's an MSR (also exposed through MCHBAR) we can u
On Wed, Apr 10, 2013 at 01:59:02PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> > It will be only consistent once we've restored all the crtcs. Since a
> > bunch of other callers also want to just restore a single crtc, add a
> > boolean to disabl
On Wed, Apr 10, 2013 at 10:52:20AM +0200, Daniel Vetter wrote:
> So the idea is now to enable fbc/psr when pageflipping and disable it
> as soon as we detect a frontbuffer rendering event. Thanks to the
> current gem api we can do this pretty cheaply:
> - CPU writes to the frontbuffer call sw_finis
On Tue, Apr 09, 2013 at 06:32:45PM -0300, Rodrigo Vivi wrote:
> According to SNB GT PM Programming Guide page 9,
> Write Min Frequency Table is 09h
I think this is the winner of what workarounds the hang...
(Since patch 3 is a no-op, patch 1 still reverts a change to the media
turbo mode requested
On Wed, Apr 10, 2013 at 10:18 AM, Ville Syrjälä
wrote:
>> > > + dpfc_ctl |= (HSW_DPFC_CTL_FENCE_EN | obj->fence_reg);
>> >
>> > The CPU fence field must be written with 0. SNB/IVB could do with the
>> > same fix.
>> >
>>
>> Where did you get this restriction for HSW?
>
> BSpec.
>
>> Should we
On Tue, Apr 09, 2013 at 03:13:10PM -0300, Rodrigo Vivi wrote:
> On Tue, Apr 9, 2013 at 5:35 AM, Ville Syrjälä > wrote:
>
> > On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote:
> > > This patch introduce Frame Buffer Compression (FBC) support for HSW.
> > > It adds a new function haswel
On Tue, Apr 09, 2013 at 03:05:10PM -0300, Rodrigo Vivi wrote:
> On Tue, Apr 9, 2013 at 5:37 AM, Ville Syrjälä > wrote:
>
> > On Mon, Apr 08, 2013 at 06:49:44PM -0300, Rodrigo Vivi wrote:
> > > Display register 46500h bit 23 must be set to 1b for the entire time that
> > > Frame Buffer Compression
23 matches
Mail list logo
