While the Sandybridge PRM doesn't have any documentation on the GPU's
performance counters, a lot of information can be gleaned from the older
Ironlake PRM. Oddly, none of the information documented there actually
appears to apply to Ironlake. However, it apparently works just great
on Sandybridg
We want to support this tool on more platforms. This lays the
groundwork for making that possible.
Signed-off-by: Kenneth Graunke
---
tools/intel_perf_counters.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/tools/intel_perf_counters.
From: Eric Anholt
This reads the GPU's performance counters via MI_REPORT_PERF_COUNT and
prints them in a top-style interface. While it can be useful in and of
itself, it also documents the performance counters and lets us verify
that they're working.
Currently, it only supports Ironlake.
v2 [
Hi Daniel,
Thank you for your notification. This would make it easy to run sub suite on
simulation during this stage. I know the goal is to run the whole i-g-t test
case.
So we can run tests/igt.test just like any other real machines. Ok, I'll add it
to our nightly ASAP.
Thanks
--Sun, Yi
If for example the BIOS fb is too small for the dual pipe config we detect, we
may have valid timings and such, but no fb. The pfit case also hits this path
(though currently only fastboots if you hack your mode clock to match).
--
Jesse Barnes, Intel Open Source Technology Center
Ori
On Tue, Mar 26, 2013 at 10:00:23AM -0700, Ben Widawsky wrote:
> On Tue, Mar 26, 2013 at 04:38:58PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 26, 2013 at 03:24:37PM +, Damien Lespiau wrote:
> > > There are two ways to run tests, directly with make check/test
> > > or through piglit.
> > >
> >
On Tue, Mar 26, 2013 at 12:57:42PM -0700, Andrew Morton wrote:
> On Tue, 26 Mar 2013 15:50:20 +0100 Daniel Vetter wrote:
>
> > On Tue, Mar 26, 2013 at 03:14:17PM +0200, Imre Deak wrote:
> > > When adding sg_page_iter I haven't thought properly through the use case
> > > for sg lists w/o backing p
On Tue, Mar 26, 2013 at 10:50:57PM +, Damien Lespiau wrote:
> On Tue, Mar 26, 2013 at 03:14:17PM +0200, Imre Deak wrote:
> > When adding sg_page_iter I haven't thought properly through the use case
> > for sg lists w/o backing pages - which is specific to the i915 driver -
> > so this patchset
On Wed, Mar 27, 2013 at 12:45:02AM +0100, Daniel Vetter wrote:
> There's a rather decent confusion going on around transcoder m_n
> values. So let's clarify:
> - All dp encoders need this, either on the pch transcoder if it's a
> pch port, or on the cpu transcoder/pipe if it's a cpu port.
> - fdi
On Tue, Mar 26, 2013 at 04:33:07PM -0700, Jesse Barnes wrote:
> Read the current hardware state to retrieve the active mode and populate
> our CRTC config if that mode matches our presumptions.
>
> v2: check that get_hw_state gave us a valid pipe (Imre)
> add clock_get for ILK+ (Jesse)
>
> Si
On Tue, Mar 26, 2013 at 11:15:38PM +, Damien Lespiau wrote:
> On Tue, Mar 05, 2013 at 02:52:39PM +, Chris Wilson wrote:
> > From the w/a database:
> >
> > 'To prevent false VT-d type 6 error:
> >
> > The primary display plane must be 256KiB aligned, and require an extra
> > 128 PTEs o
On Tue, Mar 26, 2013 at 04:33:11PM -0700, Jesse Barnes wrote:
> In case we don't get an fb from the BIOS, we may still be able to re-use
> existing state and flip a new buffer.
>
> Signed-off-by: Jesse Barnes
This hack here smells extremely fishy. Where do we come up with no fb, but
a real mode
On Wed, 27 Mar 2013 00:52:47 +0100
Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 04:24:48PM -0700, Jesse Barnes wrote:
> > On Wed, 20 Mar 2013 14:36:25 +0200
> > Imre Deak wrote:
> >
> > > > + pipe = -1;
> > > >
> > > > if (encoder->get_hw_state(encoder, &pipe))
On Tue, Mar 26, 2013 at 04:33:06PM -0700, Jesse Barnes wrote:
> v2: check for non-native modes and adjust (Jesse)
> fixup aperture and cmap frees (Imre)
The aperture is already freed via framebuffer_release(). And wrong
patch?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
On Tue, Mar 26, 2013 at 04:24:48PM -0700, Jesse Barnes wrote:
> On Wed, 20 Mar 2013 14:36:25 +0200
> Imre Deak wrote:
>
> > > + pipe = -1;
> > >
> > > if (encoder->get_hw_state(encoder, &pipe)) {
> > > - encoder->base.crtc =
> > > - dev_
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the cp
- gen4 and earlier (save for g4x) only really have a 8bpc pipe, with
the possibility to dither to 6bpc using the panel fitter
- g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly.
- TV/SDVO out are the only connectors available on platforms with
a pipe bpp != 8, add code to force th
- There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc
float layout, but we don't really support it.
- 10bpc is a gen4+ feature, fix up the support for it.
- Update_plane should never see a wrong fb bpp value, BUG in the
corresponding cases.
v2: Rebase on top of Ville's plane pi
The old code only handled either 6bpc or 8bpc. Since it's easy to do,
reorganize the code to be a bit more generic so that it can also handle
10bpc and 12bpc. Note that we still start with 8bpc, so there's no
functional change.
Also, since we no don't need to compute the 6BPC flag in the mode_vali
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the enco
We want to compute this earlier. To avoid a big complicated patch,
this patch here just does the big search&replace and still calls the
old functions at the same places.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 8
drivers/gpu/drm/i915/intel_display.c | 25
Now that we have a useful struct for this, let's use it. Some neat
pointer-chasing required, but it's all there already.
v2: Rebased on top of the added Haswell limited color range support.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 ++---
drivers/gpu/drm
This is used way too often in the enable/disable paths. And will
be even more useful in the future.
Note that correct semantics of this change highly depend upon
correct updating of intel_crtc->config: Like with all other
modeset state, we need to call ->disable with the old config,
but ->mode_set
Completely unused by now. Separate patch in case I've missed a
place somewhere which dereferences the helper vtable but actually
shouldn't do so.
v2: Resolve rebase conflict with Egbert Eich's hpd infrastructure
rework.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 5
Used by SDVO (and hopefully, eventually HDMI, if we ever get around
to fixing up the low dotclock CEA modes ...).
This required adding a new encoder->mode_set callback to be able to
pass around the intel_crtc_config.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 80 +++
Only used by the lvds encoder. Note that we shouldn't do the same
simple conversion with the FORCE_6BPC flag, since that's much better
handled by moving all the pipe_bpc computation around.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
drivers/gpu/drm/i
To make decent modeset state checking possible (e.g. for the check
mode with atomic modesetting) we want to have the full pipe
configuration and state checks done before we touch the hw.
To ensure that all the little bits&pieces that are now moved to the
pipe_config handle this correctly, move its
Currently only containing the requested and the adjusted mode. And
only crtc callbacks are converted somewhat to it, encoders will be
done on a as-needed basis (simply too much churn in one patch
otherwise).
Future patches will add tons more useful stuff to this struct,
starting with the very simp
Hi all,
Changes since last time around (i.e. not including the fixups I've sent
already):
- Apply bikeshed from Paulo.
- Split up patches for Jesse.
- Rebase onto latest dinq.
Happy review!
Cheers, Daniel
Daniel Vetter (13):
drm/i915: introduce struct intel_crtc_config
drm/i915: compute pip
Due to the irq setup rework in 3.9 Egbert's hpd rework blows up on
pch-split platforms. The new init sequence is:
- irq enabling
- modeset init
- hpd setup
We need to move around the ibx setup a bit to fix this.
This needs to be squashed into a commit on dinq.
Cc: Egbert Eich
Cc: Jesse Barnes
On Tue, 26 Mar 2013 16:33:07 -0700
Jesse Barnes wrote:
> Read the current hardware state to retrieve the active mode and populate
> our CRTC config if that mode matches our presumptions.
>
> v2: check that get_hw_state gave us a valid pipe (Imre)
> add clock_get for ILK+ (Jesse)
>
> Signed-
In case we don't get an fb from the BIOS, we may still be able to re-use
existing state and flip a new buffer.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/dr
Lets us see what's going on if we slowboot instead of fastboot.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
inde
We may need to disable the panel when flipping to a new buffer, so check
the state here and zero it out if needed, otherwise leave it alone.
v2: fixup pipe_set_base check (Imre)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 12 insertio
From: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |9 +
drivers/gpu/drm/i915/intel_dp.c |1 +
drivers/gpu/drm/i915/intel_drv.h |8
drivers/gpu/drm/i915/intel_fb.c |9 +
drivers/gpu/drm/i915/intel_lvds.c
From: Chris Wilson
As we retrieve the mode from the BIOS it may be constructed using
different assumptions for its configuration, such as utilizing the panel
fitter in a conflicting manner. As such the associated framebuffer may be
insufficient for our setup, and so we need to reject the current
Read the current hardware state to retrieve the active mode and populate
our CRTC config if that mode matches our presumptions.
v2: check that get_hw_state gave us a valid pipe (Imre)
add clock_get for ILK+ (Jesse)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |2
v2: check for non-native modes and adjust (Jesse)
fixup aperture and cmap frees (Imre)
use unlocked unref if init_bios fails (Jesse)
fix curly brace around DSPADDR check (Imre)
comment failure path for pin_and_fence (Imre)
Signed-off-by: Chris Wilson
Signed-off-by: Jesse Barnes
-
From: Chris Wilson
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the clocks stabilise between each
stage. If we are not actually changing the clock sources, then we can
return early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm
This will be shared with wrapping the BIOS framebuffer into the fbdev
later. In the meantime, we can tidy the code slightly and improve the
error path handling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |7 --
drivers/gpu/drm/i915/intel_drv.h |7 ++
drivers
They're slowly getting slurped in. These ones are rebased on top of the
bits Daniel pushed today, and include the comments from Imre.
There's one missing piece for getting fastboot to not slowboot on
laptops that don't use the native mode: overriding the pixel clock of a
panel fitted mode with th
On Wed, 20 Mar 2013 14:51:12 +0200
Imre Deak wrote:
> On Tue, 2013-02-19 at 13:31 -0800, Jesse Barnes wrote:
> > If the mode is non-native using the panel fitter, don't try to re-use
> > the fb the BIOS allocated for it.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/inte
On Wed, 20 Mar 2013 14:48:22 +0200
Imre Deak wrote:
> On Tue, 2013-02-19 at 13:31 -0800, Jesse Barnes wrote:
> > Turns out it's easy to get the clock, though it may correspond to a
> > potential pfit mode. In that case, we may still be able to flip if
> > we can get the native mode params someho
On Wed, 20 Mar 2013 14:41:32 +0200
Imre Deak wrote:
> On Tue, 2013-02-19 at 13:31 -0800, Jesse Barnes wrote:
> > Missing a curly brace.
>
> Should be merged into 6/13.
Fixed. Thanks.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gf
On Wed, 20 Mar 2013 14:36:25 +0200
Imre Deak wrote:
> > + pipe = -1;
> >
> > if (encoder->get_hw_state(encoder, &pipe)) {
> > - encoder->base.crtc =
> > - dev_priv->pipe_to_crtc_mapping[pipe];
> > - } else {
> > +
On Wed, 20 Mar 2013 14:31:38 +0200
Imre Deak wrote:
> > + offset = I915_READ(DSPSURF(plane));
> > + } else
> > + offset = I915_READ(DSPADDR(plane));
>
> Nitpick: the second branch should be inside { } too.
Fixed.
>
> > + if (!obj_offset)
On Tue, Mar 05, 2013 at 02:52:39PM +, Chris Wilson wrote:
> From the w/a database:
>
> 'To prevent false VT-d type 6 error:
>
> The primary display plane must be 256KiB aligned, and require an extra
> 128 PTEs of padding afterward;
>
> The sprites planes must be 128KiB aligned, and req
On Wed, 20 Mar 2013 14:23:48 +0200
Imre Deak wrote:
> > + if (!info->screen_base)
>
> kfree(info->apertures) is missing. The same goes for
> intel_fbdev_destroy().
Fixed in both places.
>
> > + goto err_cmap;
> > +
> > + /* If the object is shmemfs backed, it will have given us
On Wed, 20 Mar 2013 14:17:00 +0200
Imre Deak wrote:
> On Tue, 2013-02-19 at 13:31 -0800, Jesse Barnes wrote:
> > From: Chris Wilson
> >
> > Modifying the clock sources (via the DREF control on the PCH) is a slow
> > multi-stage process as we need to let the clocks stabilise between each
> > sta
On Tue, Mar 26, 2013 at 03:14:17PM +0200, Imre Deak wrote:
> When adding sg_page_iter I haven't thought properly through the use case
> for sg lists w/o backing pages - which is specific to the i915 driver -
> so this patchset adds support for this.
>
> It applies on the i915 tree [1], where the i
Now with Egbert Eich's hpd infrastructure rework merged this is dead
simple. And we need this to make output detection work on SDVO - with
the cleaned-up drm polling helpers outputs which claim to have hpd
support are no longer polled.
Now SDVO claims to do that, but it's not actually wired up. So
On Tue, Mar 26, 2013 at 02:12:39PM -0700, Jesse Barnes wrote:
> On Fri, 22 Feb 2013 00:56:52 +0100
> Daniel Vetter wrote:
>
> > The procedure has now 3 steps:
> >
> > 1. Compute the bpp that the plane will output, this is done in
> >pipe_config_set_bpp and stored into pipe_config->pipe_bpp.
On Fri, 22 Feb 2013 00:56:52 +0100
Daniel Vetter wrote:
> The procedure has now 3 steps:
>
> 1. Compute the bpp that the plane will output, this is done in
>pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
>this function clamps the pipe_bpp to whatever limit the EDID of a
On Fri, 22 Feb 2013 00:56:54 +0100
Daniel Vetter wrote:
> - gen4 and earlier (save for g4x) only really have a 8bpc pipe, with
> the possibility to dither to 6bpc using the panel fitter
> - g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly.
> - TV/SDVO out are the only connectors a
On Fri, 22 Feb 2013 00:56:53 +0100
Daniel Vetter wrote:
> - There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc
> float layout, but we don't really support it.
> - 10bpc is a gen4+ feature, fix up the support for it.
> - Update_plane should never see a wrong fb bpp value, BUG in
On Mon, Feb 25, 2013 at 12:06:52PM -0500, Egbert Eich wrote:
> Now since we have replaced the bits to show interest in hotplug IRQs
> we can go and nuke the 'hotplug_supported_mask'.
>
> Signed-off-by: Egbert Eich
I've applied your patch up to this one. Patch four needed some manual
convincing t
On Tue, 26 Mar 2013 20:46:24 +0100
Daniel Vetter wrote:
> On Tue, Feb 19, 2013 at 01:31:37PM -0800, Jesse Barnes wrote:
> > From: Chris Wilson
> >
> > Wrap a preallocated region of stolen memory within an ordinary GEM
> > object, for example the BIOS framebuffer.
> >
> > Signed-off-by: Chris W
On Tue, 26 Mar 2013 20:52:53 +
Chris Wilson wrote:
> On Tue, Mar 26, 2013 at 09:34:29PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 19, 2013 at 01:31:39PM -0800, Jesse Barnes wrote:
> > > Rather than building a config which may or may not work, let the driver
> > > build an initial fb config.
On Tue, 26 Mar 2013 21:46:03 +0100
Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 01:25:27PM -0700, Jesse Barnes wrote:
> > commit 79dd6a5bd6603b9d76b992d59819c3aec50e6c33
> > Author: Jesse Barnes
> > Date: Fri Feb 15 12:37:40 2013 -0800
> >
> > drm/i915: restore sprite state when forcing
On Tue, Mar 26, 2013 at 09:34:29PM +0100, Daniel Vetter wrote:
> On Tue, Feb 19, 2013 at 01:31:39PM -0800, Jesse Barnes wrote:
> > Rather than building a config which may or may not work, let the driver
> > build an initial fb config. This allows the driver to use the BIOS boot
> > configuration f
On Tue, Mar 26, 2013 at 01:25:27PM -0700, Jesse Barnes wrote:
> commit 79dd6a5bd6603b9d76b992d59819c3aec50e6c33
> Author: Jesse Barnes
> Date: Fri Feb 15 12:37:40 2013 -0800
>
> drm/i915: restore sprite state when forcing a config restore v2
>
> Needed for VT switchless resume.
>
On Tue, Feb 19, 2013 at 01:31:39PM -0800, Jesse Barnes wrote:
> Rather than building a config which may or may not work, let the driver
> build an initial fb config. This allows the driver to use the BIOS boot
> configuration for example, displaying kernel messages and the initial fb
> console on
commit 79dd6a5bd6603b9d76b992d59819c3aec50e6c33
Author: Jesse Barnes
Date: Fri Feb 15 12:37:40 2013 -0800
drm/i915: restore sprite state when forcing a config restore v2
Needed for VT switchless resume.
v2: cursor state is now handled correctly in crtc_enable (Daniel)
On Tue, Mar 26, 2013 at 08:50:53PM +0100, Mark Kettenis wrote:
> From: Mark Kettenis
>
> The sysinfo function is Linux-specific. sysconf(_SC_PHYS_PAGES), while
> not truly portable, is available on many more systems, including Linux,
> Solaris, NetBSD, FreeBSD and OpenBSD. So use that instead.
On Mon, 25 Feb 2013 12:06:50 -0500
Egbert Eich wrote:
> This allows to enable HPD interrupts for individual pins to only receive
> hotplug events from lines which are connected and working.
>
> Signed-off-by: Egbert Eich
> ---
In reviewing the old one, I thought tables might be nice, but on
se
On Mon, 25 Feb 2013 12:06:49 -0500
Egbert Eich wrote:
> To clean up hotplug support we add a new enum to intel_encoder:
> enum hpd_pin. It allows the encoder to request a hpd line but leave
> the details which IRQ is responsible on which chipset generation
> to i915_irq.c.
> This way requesting h
On Mon, 25 Feb 2013 12:06:48 -0500
Egbert Eich wrote:
> It's basically identical to i915_hpd_irq_setup().
>
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/i915/i915_irq.c | 26 +-
> 1 files changed, 1 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/
On Tue, 26 Mar 2013 15:50:20 +0100 Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 03:14:17PM +0200, Imre Deak wrote:
> > When adding sg_page_iter I haven't thought properly through the use case
> > for sg lists w/o backing pages - which is specific to the i915 driver -
> > so this patchset adds s
On Thu, 10 Jan 2013 10:02:43 -0500
Egbert Eich wrote:
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/i915/i915_irq.c | 178 ++
> 1 files changed, 103 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i91
On Thu, 10 Jan 2013 10:02:42 -0500
Egbert Eich wrote:
> + if (hotplug_trigger & intel_connector->hpd_status_bit) {
> + if (jiffies > (intel_connector->last_hpd_jiffies +
> msecs_to_jiffies(1000)) ||
> + jiffies < intel_connector->last_hpd_j
> Date: Tue, 26 Mar 2013 09:06:54 +
> From: Chris Wilson
>
> On Mon, Mar 25, 2013 at 10:40:35PM +0100, Mark Kettenis wrote:
> > From: Mark Kettenis
> >
> > Fix cut'n'paste error such that this actually compiles.
>
> Mea culpa. Thanks a lot,
No problem Chris. The SNA code isn't compiled y
On Thu, 10 Jan 2013 10:02:41 -0500
Egbert Eich wrote:
> To be able to map an HPD interrupt to a connector add the
> hpd status bit to the intel_connector structure.
>
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/i915/intel_crt.c |3 ++-
> drivers/gpu/drm/i915/intel_dp.c |3 +
From: Mark Kettenis
The sysinfo function is Linux-specific. sysconf(_SC_PHYS_PAGES), while
not truly portable, is available on many more systems, including Linux,
Solaris, NetBSD, FreeBSD and OpenBSD. So use that instead. Verified
that this results in the same value as the sysinfo call on a ha
On Thu, 10 Jan 2013 10:02:40 -0500
Egbert Eich wrote:
> So far the hotplug_supported_mask in the struct drm_i915_private
> is only used for pre-Ironlake chipsets.
> This patch sets up the correct value for all generations.
>
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/i915/i915_drv.h
On Tue, Mar 26, 2013 at 8:37 PM, Rodrigo Vivi wrote:
> I forgot to say that I tested patch by patch today on my HSW ULT and just
> noticed real improvement with the patch you already queued.
>
> Where improvements are: at least 0.2W and also less oscillation and more %
> on RC and package C states
On Tue, Feb 19, 2013 at 01:31:37PM -0800, Jesse Barnes wrote:
> From: Chris Wilson
>
> Wrap a preallocated region of stolen memory within an ordinary GEM
> object, for example the BIOS framebuffer.
>
> Signed-off-by: Chris Wilson
Queued for -next, thanks for the patch. My merge plan here still
I forgot to say that I tested patch by patch today on my HSW ULT and just
noticed real improvement with the patch you already queued.
Where improvements are: at least 0.2W and also less oscillation and more %
on RC and package C states.
Although I'd like to see the rest of the series applied to h
I'm in favor of this revert. Although I don't have any argument in values,
I always guessed that many of rc6 bugs we have on snb came from the gap
between the threashold values used and documented for snb.
On Tue, Mar 26, 2013 at 4:00 PM, Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 01:32:51P
On Tue, Mar 26, 2013 at 04:25:58PM +0200, Imre Deak wrote:
> On Tue, 2013-03-26 at 11:29 +, Chris Wilson wrote:
> > There is a minute window for a race between put-fence removing the fence
> > and for a new transaction by an external party on the GTT mmap. That is
> > we must zap the mmap prior
On Tue, Mar 26, 2013 at 01:32:51PM -0300, Rodrigo Vivi wrote:
> ah... got your point...
> I just split later because Ben wanted the frequency patch as the first one
> so I decided to let split at last patch to be really optional...
> so, you suggestion is to revert the order of this two latest patc
Hi,
Thus far our assumption always was that the acpi backlight works better
than the intel native backlight. So everything only uses the intel
backlight if there's no other backlight driver by default.
So if I should merge this as a general solution for Windows 8 machines not
working properly,
Hi,
Am 26.03.2013 18:02, schrieb Matthew Garrett:
On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:
This patch makes the behaviour of the intel_backlight backlight device
consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
makes the panel content barely rea
This will poke userspace into probing for configuration changes that may
have occurred across suspend/resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/
With the other bits in place, we can do this safely.
v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 14 +++---
drivers/gpu/drm/i915/intel_
Hi,
Thus far our assumption always was that the acpi backlight works better
than the intel native backlight. So everything only uses the intel
backlight if there's no other backlight driver by default.
There are machines, such as the pnv netbook on my desk, on which
intel_backlight does nothin
On Tue, Mar 26, 2013 at 04:38:58PM +0100, Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 03:24:37PM +, Damien Lespiau wrote:
> > There are two ways to run tests, directly with make check/test
> > or through piglit.
> >
> > When IGT_SIMULATION is set to '1', we substitute the list of tests in
>
On Tue, Mar 26, 2013 at 09:25:44AM -0700, Jesse Barnes wrote:
> Needed for VT switchless resume.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dis
Reviewed-by: Rodrigo Vivi
On Tue, Mar 26, 2013 at 1:25 PM, Jesse Barnes wrote:
> This will poke userspace into probing for configuration changes that may
> have occurred across suspend/resume.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.c | 20
Reviewed-by: Rodrigo Vivi
On Tue, Mar 26, 2013 at 1:25 PM, Jesse Barnes wrote:
> With the other bits in place, we can do this safely.
>
> v2: disable backlight on suspend to prevent premature enablement on resume
> v3: disable CRTCs on suspend to allow RTD3 (Kristen)
>
> Signed-off-by: Jesse Ba
Reviewed-by: Rodrigo Vivi
On Tue, Mar 26, 2013 at 1:25 PM, Jesse Barnes wrote:
> Needed for VT switchless resume.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu
Reviewed-by: Rodrigo Vivi
On Tue, Mar 26, 2013 at 1:25 PM, Jesse Barnes wrote:
> To be used to restore sprite state on resume.
>
> v2: move sprite tracking bits up so we don't track modified sprite state
> v3: use src_x/y in sprite suspend/resume code (Ville)
>
> Signed-off-by: Jesse Barnes
>
ah... got your point...
I just split later because Ben wanted the frequency patch as the first one
so I decided to let split at last patch to be really optional...
so, you suggestion is to revert the order of this two latest patches or the
3?
I guess frequency one was already queued right?
On Tue
Yeah, this kind of overlaps ben's patch, but also remove unecessary
sandybridge_pcode_write.
On Tue, Mar 26, 2013 at 5:02 AM, Daniel Vetter wrote:
> On Mon, Mar 25, 2013 at 05:55:51PM -0300, Rodrigo Vivi wrote:
> > Yet according to pm spec pcode read/write operations aren't necessary
> for HSW.
On Tue, Mar 26, 2013 at 5:25 PM, Rodrigo Vivi wrote:
> I just checked the code and this patch looks right for me.
> it doesn't add any if block... just remove them.
> What am I missing?
You've added it right in the previous patch ;-)
Which means if someone tries to understand the history of a gi
This will poke userspace into probing for configuration changes that may
have occurred across suspend/resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/
Needed for VT switchless resume.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7307974..093006b 100644
-
To be used to restore sprite state on resume.
v2: move sprite tracking bits up so we don't track modified sprite state
v3: use src_x/y in sprite suspend/resume code (Ville)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h|5 +
drivers/gpu/drm/i915/intel_sprite.c |
With the other bits in place, we can do this safely.
v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 14 +++---
drivers/gpu/drm/i915/intel_
Hi Daniel,
I just checked the code and this patch looks right for me.
it doesn't add any if block... just remove them.
What am I missing?
Thanks,
Rodrigo.
On Tue, Mar 26, 2013 at 10:54 AM, Rodrigo Vivi wrote:
> ops, when reworking to let the split as last patch I missed this one...
> I'll rese
On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb wrote:
> Since 2514bc510d0c3aadcc5204056bb440fa36845147, the intel_dp_mode_fixup
> function prefers lane count over frequency. That causes problems on
> hardware that has less working lanes than it reports. This option allows
> to workaround such hardwar
1 - 100 of 131 matches
Mail list logo
