From: Eric Anholt e...@anholt.net
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
We want to support this tool on more platforms. This lays the
groundwork for making that possible.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
tools/intel_perf_counters.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git
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
Add write-verify test to gem_fence_thrash. Test will create
multiple threads per fence then verify the write into fenced region.
v2: non-threaded, non-tiled tests added. suggested by Chris Wilson.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tests/gem_fence_thrash.c | 145
On Wed, Mar 27, 2013 at 12:48:07PM +0200, Mika Kuoppala wrote:
Add write-verify test to gem_fence_thrash. Test will create
multiple threads per fence then verify the write into fenced region.
v2: non-threaded, non-tiled tests added. suggested by Chris Wilson.
Signed-off-by: Mika Kuoppala
On Tue, Mar 26, 2013 at 10:06:39PM -0700, Kenneth Graunke wrote:
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
On Tue, 2013-03-26 at 16:07 -0700, Jesse Barnes wrote:
On Wed, 20 Mar 2013 14:23:48 +0200
Imre Deak imre.d...@intel.com wrote:
+ if (!info-screen_base)
kfree(info-apertures) is missing. The same goes for
intel_fbdev_destroy().
Fixed in both places.
+ goto err_cmap;
Hi,
Well, the ACPI spec says this (section B.5.2):
The OEM may define the number 0 as Zero brightness that can mean
to turn off the lighting (e.g. LCD panel backlight) in the device.
This may be useful in the case of an output device that can still be
viewed using only ambient light, for
On Wed, Mar 27, 2013 at 3:09 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
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
Hi,
Well, the ACPI spec says this (section B.5.2):
The OEM may define the number 0 as Zero brightness that can mean
to turn off the lighting (e.g. LCD panel backlight) in the device.
This may be useful in the case of an output device that can still be
viewed using only ambient light, for
On Wed, Mar 27, 2013 at 8:56 AM, Danny Baumann dannybaum...@web.de wrote:
Hi,
Well, the ACPI spec says this (section B.5.2):
The OEM may define the number 0 as Zero brightness that can mean
to turn off the lighting (e.g. LCD panel backlight) in the device.
This may be useful in the case
On 03/26/2013 10:15 PM, Alexander van Heukelum wrote:
Hi Hans,
Could you check if the attached patch solves your problem?
Yep, the grass is green again.
--
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Wed, Mar 27, 2013 at 01:49:47PM +0100, Daniel Vetter wrote:
On Wed, Mar 27, 2013 at 3:09 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
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
On Wed, Mar 27, 2013 at 01:49:06PM +0200, Imre Deak wrote:
On Tue, 2013-03-26 at 16:07 -0700, Jesse Barnes wrote:
On Wed, 20 Mar 2013 14:23:48 +0200
Imre Deak imre.d...@intel.com wrote:
+ if (!info-screen_base)
kfree(info-apertures) is missing. The same goes for
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 readable instead of turning the backlight off.
This
Hi Hans,
Could you check if the attached patch solves your problem?
Greetings,
Alexander van Heukelum
On Sun, Mar 24, 2013, at 22:19, Hans de Bruin wrote:
commit 49cb25e9290 x86: 'get rid of pt_regs argument in vm86/vm86old'
somehow breaks the colors when I play 'civilization I' under
ERROR: __build_bug_on_failed [drivers/gpu/drm/i915/i915.ko] undefined!
Originally reported at
http://www.gossamer-threads.com/lists/linux/kernel/1631803
FDO bug #62775
This needs to be backported to both 3.7 and 3.8 stable trees. Doesn't apply
straight,
but it's a quick change.
Signed-off-by:
On Wed, Mar 27, 2013 at 12:44:30AM +0100, Daniel Vetter wrote:
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
On Tue, 2013-03-26 at 23:53 +, Chris Wilson wrote:
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?
Ah,
Noticed while reviewing the hotplug irq setup code. Just looks better.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index
This fixes a regression introduced in
commit e5868a318d1ae28f760f77bb91ce5deb751733fd
Author: Egbert Eich e...@suse.de
Date: Thu Feb 28 04:17:12 2013 -0500
DRM/i915: Convert HPD interrupts to make use of HPD pin assignment in encode
Due to the irq setup rework in 3.9, see
commit
On Wed, Mar 27, 2013 at 03:47:11PM +0100, Daniel Vetter wrote:
Noticed while reviewing the hotplug irq setup code. Just looks better.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
What about the activation period? Do we want to
On Wed, Mar 27, 2013 at 03:55:01PM +0100, Daniel Vetter wrote:
This fixes a regression introduced in
commit e5868a318d1ae28f760f77bb91ce5deb751733fd
Author: Egbert Eich e...@suse.de
Date: Thu Feb 28 04:17:12 2013 -0500
DRM/i915: Convert HPD interrupts to make use of HPD pin
Daniel Vetter writes:
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 e...@suse.de
I've applied your patch up to this
On Mon, Feb 25, 2013 at 12:06:57PM -0500, Egbert Eich wrote:
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it
On Wed, Mar 27, 2013 at 12:56:37PM +0100, Danny Baumann wrote:
OK, I see. And there is user space depending on that behaviour? And
again - how is user space supposed to know about the behavioral
differences? Is it something like 'if type is raw, don't expect
anything'?
Do not rely upon 0
On Wed, Mar 27, 2013 at 05:02:43PM +0200, Ville Syrjälä wrote:
On Wed, Mar 27, 2013 at 03:47:11PM +0100, Daniel Vetter wrote:
Noticed while reviewing the hotplug irq setup code. Just looks better.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä
On Wed, Mar 27, 2013 at 05:05:54PM +0200, Ville Syrjälä wrote:
On Wed, Mar 27, 2013 at 03:55:01PM +0100, Daniel Vetter wrote:
This fixes a regression introduced in
commit e5868a318d1ae28f760f77bb91ce5deb751733fd
Author: Egbert Eich e...@suse.de
Date: Thu Feb 28 04:17:12 2013 -0500
From: Ville Syrjälä ville.syrj...@linux.intel.com
struct drm_rect represents a simple rectangle. The utility
functions are there to help driver writers.
v2: Moved the region stuff into its own file, made the smaller funcs
static inline, used 64bit maths in the scaled clipping function to
From: Ville Syrjälä ville.syrj...@linux.intel.com
These functions calculcate the scaling factor based on the source and
destination rectangles.
There are two version of the functions, the strict ones that will
return an error if the min/max scaling factor is exceeded, and the
relaxed versions
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a debug function to print the rectangle in a human readable format.
v2: Renamed drm_region to drm_rect, the function from drm_region_debug
to drm_rect_debug_print(), and use %+d instead of +%d in the format.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä ville.syrj...@linux.intel.com
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel
From: Ville Syrjälä ville.syrj...@linux.intel.com
When disabling a sprite, wait for the sprite to stop fetching data
from memory before unpinning the fb.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_sprite.c | 2 ++
1 file changed, 2 insertions(+)
On Wed, 27 Mar 2013 13:49:47 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 27, 2013 at 3:09 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
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
On Wed, 27 Mar 2013 01:13:48 +0100
Daniel Vetter dan...@ffwll.ch wrote:
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
On Wed, 27 Mar 2013 17:49:13 +0200
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When disabling a sprite, wait for the sprite to stop fetching data
from memory before unpinning the fb.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
On Wed, 27 Mar 2013 00:44:50 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
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).
On Wed, 27 Mar 2013 00:44:51 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
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
On Wed, Mar 27, 2013 at 09:29:03AM -0700, Jesse Barnes wrote:
On Wed, 27 Mar 2013 17:49:13 +0200
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When disabling a sprite, wait for the sprite to stop fetching data
from memory before unpinning the
On Wed, 27 Mar 2013 00:44:52 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
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
On Wed, 27 Mar 2013 00:44:53 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
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
On Wed, 27 Mar 2013 00:44:54 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
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
On Wed, Mar 27, 2013 at 09:49:52AM -0700, Jesse Barnes wrote:
Changelog and summary could be better and mention the new
compute_config function and how it replaces the mode_fixup one.
Also, TIMINGS_SET probably wasn't a very good name in the first place,
since it really deals with
On Wed, 27 Mar 2013 00:44:52 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
+ bool (*compute_config)(struct intel_encoder *,
+struct intel_crtc_config *);
void (*pre_pll_enable)(struct intel_encoder *);
void (*pre_enable)(struct intel_encoder *);
On Wed, Mar 27, 2013 at 5:49 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
Changelog and summary could be better and mention the new
compute_config function and how it replaces the mode_fixup one.
Also, TIMINGS_SET probably wasn't a very good name in the first place,
since it really deals
On Wed, Mar 27, 2013 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3e22305..3672b8d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@
On Wed, 27 Mar 2013 00:44:55 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
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
On Wed, Mar 27, 2013 at 5:59 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
@@ -203,6 +201,10 @@ struct intel_connector {
struct intel_crtc_config {
struct drm_display_mode requested_mode;
struct drm_display_mode adjusted_mode;
+ /* This flag must be set by the encoder's
On Wed, 27 Mar 2013 00:44:56 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
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:
On Wed, 27 Mar 2013 00:44:57 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We want to compute this earlier. To avoid a big complicated patch,
this patch here just does the big searchreplace and still calls the
old functions at the same places.
Signed-off-by: Daniel Vetter
On Wed, Mar 27, 2013 at 6:06 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
+ if (HAS_PCH_SPLIT(dev) !HAS_DDI(dev) !is_cpu_edp(intel_dp))
+ pipe_config-has_pch_encoder = true;
+
This could just do
if (intel_dp-is_pch_edp)
pipe_config-has_pch_encoder = true;
On Wed, 27 Mar 2013 18:06:44 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Mar 27, 2013 at 5:59 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
@@ -203,6 +201,10 @@ struct intel_connector {
struct intel_crtc_config {
struct drm_display_mode requested_mode;
On Wed, 27 Mar 2013 00:44:58 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
For a moment I confused CPT with LPT at bspec where 18 was reserved... but
now I found the correct one.
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Tue, Mar 26, 2013 at 6:38 PM, Daniel Vetter daniel.vet...@ffwll.chwrote:
Now with Egbert Eich's hpd infrastructure rework merged this
On Wed, Mar 27, 2013 at 6:24 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
This looks good and seems to cover the bugs we've had here before. My
only concern is the one I mentioned before: on older chipsets we could
dither between plane, pipe, *and* port. Nowadays the pipe always does
it.
On Wed, Mar 27, 2013 at 03:46:15PM -0300, Rodrigo Vivi wrote:
For a moment I confused CPT with LPT at bspec where 18 was reserved... but
now I found the correct one.
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Queued for -next, thanks for the review.
-Daniel
--
Daniel Vetter
Software
Hi Al,
Hans de Bruin found a regression due to one of your changes. I asked him to
test a fix and he reported back that it worked. (Thanks!) Can you see if you
agree with the fix? Patch is attached due to webmail...
Greetings,
Alexander
From 961a1b130aa79acb54f556a0accfcc643d1d3ed1 Mon Sep
On Mon, Mar 25, 2013 at 02:56:39PM +0200, Jani Nikula wrote:
Any comments on these two patches?
Both queued for -next, thanks for the patches. That means though that
you're volunteered for more cleanup ;-)
-Daniel
BR,
Jani.
On Tue, 12 Mar 2013, Jani Nikula jani.nik...@intel.com
On Wed, 27 Mar 2013 00:44:59 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
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
On Wed, 27 Mar 2013 00:45:00 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
On Wed, Mar 27, 2013, at 20:46, Al Viro wrote:
On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
Hi Al,
Hans de Bruin found a regression due to one of your changes. I asked him to
test a fix and he reported back that it worked. (Thanks!) Can you see if
you agree
On Wed, 27 Mar 2013 00:45:01 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
On Wed, Mar 27, 2013 at 10:28 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
I had to double check this against 9/13... I guess the order will be
clearer with the actual code as opposed to patches.
But won't these override the pipe_config bpp we set in
pipe_config_set_bpp()? Why bother
Since
commit bcf9dcc1e6269fac674e41f25d007ff75f76e840
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Sun Jul 15 09:42:38 2012 +0100
drm/i915: Workaround hang with BSD and forcewake on SandyBridge
and
commit 0cc2764cc4a4bd73df55f8893c871778cf7ddd0f
Author: Ben Widawsky
As Thomas Gleixner spotted, it's rather horrible racy:
- We can miss almost a full tick, so need to compensate by 1 jiffy.
- We need to re-check the condition when having timed-out, since a
the last check could have been before the timeout expired. E.g. when
we've been preempted or a long irq
On Wed, 27 Mar 2013 23:41:55 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Mar 27, 2013 at 10:28 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I had to double check this against 9/13... I guess the order will be
clearer with the actual code as opposed to patches.
But
On Wed, Mar 27, 2013 at 04:13:13PM -0700, Jesse Barnes wrote:
On Wed, 27 Mar 2013 23:41:55 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Mar 27, 2013 at 10:28 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I had to double check this against 9/13... I guess the order will
---
.mutt/mail_aliases | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mutt/mail_aliases b/.mutt/mail_aliases
index 009b7ac..c5f54bf 100644
--- a/.mutt/mail_aliases
+++ b/.mutt/mail_aliases
@@ -49,3 +49,4 @@ alias agd5f Alex Deucher alexdeuc...@gmail.com
alias glisse Jerome Glisse
68 matches
Mail list logo
