Hi Ville,
Thank you for the patch.
On Tuesday 04 June 2013 10:58:35 ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers
On Tue, Jun 04, 2013 at 11:49:08PM +0100, Chris Wilson wrote:
> By stashing a pointer of who opened the device and keeping a list of
> open fd, we can then walk each client and inspect how many objects they
> have open. For example,
>
> i915_gem_objects:
> 1102 objects, 613646336 bytes
> 663 [662]
On Tue, Jun 04, 2013 at 11:18:03PM +0100, Chris Wilson wrote:
> By stashing a pointer of who opened the device and keeping a list of
> open fd, we can then walk each client and inspect how many objects they
> have open. For example,
>
> i915_gem_objects:
> 1102 objects, 613646336 bytes
> 663 [662]
By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,
i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
37 [37] active objects, 46874
By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,
i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
37 [37] active objects, 46874
On Tue, Jun 04, 2013 at 02:26:19PM +0100, Chris Wilson wrote:
> By stashing a pointer of who opened the device and keeping a list of
> open fd, we can then walk each client and inspect how many objects they
> have open. For example,
>
> i915_gem_objects:
> 1102 objects, 613646336 bytes
> 663 [662]
On Sat, May 25, 2013 at 12:26:34PM -0700, Ben Widawsky wrote:
> Hello.
>
> I'm continuing to develop full PPGTT support for the i915 driver. This
> series is a follow-up to the previously posted RFC [1]. This series
> contains reworked versions of the unmerged patches (fingers crossed that
> I did
From: Paulo Zanoni
CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
without proper front buffer invalidation on the last 2k lines, so
don't enable FBC on these cases for now.
v2: Use gen >= 5, not gen > 4 (Daniel).
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c
On Tue, Jun 04, 2013 at 02:46:14PM -0300, Paulo Zanoni wrote:
> 2013/6/4 Daniel Vetter :
> > On Mon, Jun 3, 2013 at 11:15 PM, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
> >> without proper front buffer invalidation on the
2013/6/4 Daniel Vetter :
> On Mon, Jun 3, 2013 at 11:15 PM, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
>> without proper front buffer invalidation on the last 2k lines, so
>> don't enable FBC on these cases for now.
>>
>> Signed
On Mon, Jun 3, 2013 at 11:15 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
> without proper front buffer invalidation on the last 2k lines, so
> don't enable FBC on these cases for now.
>
> Signed-off-by: Paulo Zanoni
> ---
> dr
Signed-off-by: Damien Lespiau
---
lib/instdone.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/instdone.c b/lib/instdone.c
index 4679a9c..ad5c62f 100644
--- a/lib/instdone.c
+++ b/lib/instdone.c
@@ -37,6 +37,7 @@ int num_instdone_bits = 0;
static void
add_instdone_bit(uint32_t reg, ui
This tool only supports ILK. I take the fact that nobody has felt the
need to update it for later platforms as a sign it's not very useful.
Signed-off-by: Damien Lespiau
---
Android.mk | 33 --
tools/.gitignore | 1 -
tools/Makefile.am
Also intel_iosf_read() does not exist, and would need a bit more
arguments.
Signed-off-by: Damien Lespiau
---
tools/intel_iosf_read.c | 70 -
1 file changed, 70 deletions(-)
delete mode 100644 tools/intel_iosf_read.c
diff --git a/tools/intel_iosf
Hi Dave,
Three regression fixes and one no-lvds quirk update. The regression Egbert
Eich tracked down goes back to 2.6.37 ... ugh. The other two are pretty
minor: One bogus modeset state checker WARN and a patch to prevent X
dying in a SIGBUS after a gpu hang with failed (or not implement as on
ge
On Tue, Jun 04, 2013 at 03:19:12PM +0100, Chris Wilson wrote:
> On Tue, May 21, 2013 at 03:28:34PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The specs are a bit unclear whether the per-plane trickle feed disable
> > control exists on VLV. There is another trickle
On Tue, Jun 04, 2013 at 04:35:32PM +0100, Chris Wilson wrote:
> On Tue, Jun 04, 2013 at 05:13:21PM +0200, Egbert Eich wrote:
> > In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
> > for DDC. Thus the code will always have to rely on a LVDS panel
> > mode supplied by VBT.
> > In m
On Tue, Jun 04, 2013 at 05:13:21PM +0200, Egbert Eich wrote:
> In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
> for DDC. Thus the code will always have to rely on a LVDS panel
> mode supplied by VBT.
> In most cases this succeeds, so this didn't get detected for quite
> a while
In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
for DDC. Thus the code will always have to rely on a LVDS panel
mode supplied by VBT.
In most cases this succeeds, so this didn't get detected for quite
a while.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/i915/intel_sdvo.c |
On Tue, May 21, 2013 at 03:28:34PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The specs are a bit unclear whether the per-plane trickle feed disable
> control exists on VLV. There is another trickle feed disable control
> in the MI_ARB register.
>
> Based on some quick
On Tue, May 21, 2013 at 03:28:33PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> According to BSpec, trickle feed should be disabled for BW and
> mobile CL. Those constraints seem to match all of our gen4 chipsets.
>
> Trickle feed is disabled via the MI_ARB_STATE registe
On Tue, May 21, 2013 at 03:28:32PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The docs say that the trickle feed disable bit is present (for primary
> planes only, not video sprites) on CTG, and that it must be set
> for ELK. Just set it for all g4x chipsets.
>
> v2: D
The programming notes for Broadwater and Crestline mandate that the
trickle feed disable bit is asserted.
See section 1.16.2 MI_ARB_STATE.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_pm.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,
i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
37 [37] active objects, 46874
On Mon, Jun 03, 2013 at 02:08:33PM -0300, Paulo Zanoni wrote:
> 2013/6/1 Daniel Vetter :
> > Panel fitters on ivb/hsw are not created equal since not all of them
> > support the new high-quality upscaling mode. To offset this the hw
> > allows us to freely assign the pfits to pipes.
> >
> > Since o
On Mon, Jun 03, 2013 at 01:54:40PM -0300, Paulo Zanoni wrote:
> 2013/6/1 Daniel Vetter :
> > ... not the port clock. This allows us to kill the funny semantics
> > around pixel_target_clock.
> >
> > Since the dpll code still needs the real port clock, add a new
> > port_clock field to the pipe conf
On Mon, Jun 03, 2013 at 08:50:29AM +0100, Chris Wilson wrote:
> On Sun, Jun 02, 2013 at 01:26:24PM +0200, Daniel Vetter wrote:
> > Since this is run in the compute config stage we need to check
> > the new_ pointers, i.e the stage output routing, not the current
> > modeset layout. Also there was a
On Tue, Jun 04, 2013 at 01:49:39PM +0300, Jani Nikula wrote:
>
> Failed to mention that this should address Daniel's complaints about the
> ->pre_enable and ->enable calls being in the same spot [1]. And while I
> needed this for something else, it should be easy to do the eDP
> backlight fix Dani
From: Ville Syrjälä
Make assert_sprites_disabled() operational on all platforms where
we currently have sprite support enabled.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 90d02c7..3be69bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
From: Ville Syrjälä
Ever since gen4 primary planes were fixed to pipes.
And for gen2-3, don't check plane B if it doesn't exist.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i91
From: Ville Syrjälä
Disable/restore sprite planes around mode-set just like we do for the
primary and cursor planes. Now that we have working sprite clipping,
this actually works quite decently.
Previosuly we didn't even bother to disable sprites when changing mode,
which could lead to a corrupt
From: Ville Syrjälä
First disable FBC, then IPS, then disable all planes, and finally
disable the pipe.
v2: Mention IPS in the commit message
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a
From: Ville Syrjälä
VLV doesn't have the old video overlay.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dac2db7..61bee12 100644
---
From: Ville Syrjälä
Again follow the same sequence for all generations, because doing
otherwise just doesn't make sense.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_
From: Ville Syrjälä
Follow the same sequence when enabling the cursor plane during
modeset. No point in doing this stuff in different order on different
generations.
This should also avoid a needless wait for vblank for the g4x cursor
workaround when the cursor gets enabled anyway.
Acked-by: Eg
From: Ville Syrjälä
Loading the palette after the planes are enabled can risk showing
incorrect colors. ILK+ already load the palette before even the pipe
is enabled. Just follow the same order for gen2-4 and VLV.
According to BSpec the requirements for palette access are
display core clock and
Failed to mention that this should address Daniel's complaints about the
->pre_enable and ->enable calls being in the same spot [1]. And while I
needed this for something else, it should be easy to do the eDP
backlight fix Daniel mentions on top.
Cheers,
Jani.
[1]
http://mid.gmane.org/cakmk7uf
Reposting the whole set for clarity.
Changes from v1:
- Rebasing due to other changes
- Fixed sprite disable in ironlake_crtc_disable()
- Improved some commit messages
- More asserts
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists
Encoder ->pre_enable and ->enable callbacks were moved back to back in
VLV crtc enable sequence, which is not very useful. Move ->enable call
at the end of the sequence.
With the previously rearranged VLV DP and HDMI ->pre_enable and ->enable
callbacks in place, this should not cause any functiona
Currently ->pre_enable and ->enable are called back to back. Rearrange
the DP callbacks to make it possible to move ->enable call later.
Basically do everything in ->pre_enable on VLV, and make ->enable a NOP.
There should be no functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/dr
Currently ->pre_enable and ->enable are called back to back. Rearrange
the HDMI callbacks to make it possible to move ->enable call later.
Basically do everything in ->pre_enable on VLV, and make ->enable a NOP.
There should be no functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/
On Mon, Jun 03, 2013 at 04:11:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There's a bunch of unused members inside drm_plane, bloating the size of
> the structure needlessly. Eliminate them.
>
> v2: Remove all of it from kernel-doc too
>
> Reviewed-by: Laurent Pin
On Mon, Jun 03, 2013 at 04:10:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Cursors and plane can obscure whatever fbdev wants to show the user.
> Disable them all in drm_fb_helper_restore_fbdev_mode.
>
> After the cursors and planes have been disabled, user space ne
On Tue, Jun 04, 2013 at 10:06:08AM +0300, Ville Syrjälä wrote:
> On Mon, Jun 03, 2013 at 03:41:49PM -0300, Rodrigo Vivi wrote:
> > + if (IS_GEN7(dev))
> > + return gen7_ring_fbc_flush(ring, false);
>
> Still no flush_domains check?
And if we are being picky, not using the fbc_dirty fl
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..f1f11e1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drive
On Mon, Jun 03, 2013 at 03:41:49PM -0300, Rodrigo Vivi wrote:
> WaFbcNukeOn3DBlt for IVB, HSW.
>
> According BSPec: "Workaround: Do not enable Render Command Streamer tracking
> for FBC.
> Instead insert a LRI to address 0x50380 with data 0x0004 after the
> PIPE_CONTROL that
> follows each r
47 matches
Mail list logo
