On pe, 2015-12-18 at 16:18 +, Dave Gordon wrote:
> On 18/12/15 12:27, Joonas Lahtinen wrote:
> > Take advantage of WARN return value to simplify the flow.
> >
> > Cc: Rob Clark
> > Reviewed-by: Chris Wilson
> > Reported-by: Chris Wilson
> > Signed-off-by: Joonas Lahtinen
> > ---
> > driv
Sorry, I missed the emails.
On 12/11/2015 09:58 PM, Takashi Iwai wrote:
On Fri, 11 Dec 2015 11:43:51 +0100,
Takashi Iwai wrote:
On Fri, 11 Dec 2015 07:07:53 +0100,
Libin Yang wrote:
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 9aa83e7..5ad2e66
On Fri, Dec 18, 2015 at 05:27:01PM -0800, Matt Roper wrote:
> pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the
> legacy FB fields (plane->fb and plane->old_fb). However it was building
> the plane mask to pass to this function incorrectly (the bitwise OR was
> using plane indic
On Thu, 10 Dec 2015 14:16:03 +0100,
Takashi Iwai wrote:
>
> Hi Daniel,
>
> please pull the get_eld op addition from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> tags/drm-i915-get-eld
>
> The topmost commit is 0bdf5a05647a66dcc6394986e061daeac9b1cf96
>
> -
On Mon, Dec 21, 2015 at 10:25:14AM +0100, Takashi Iwai wrote:
> On Thu, 10 Dec 2015 14:16:03 +0100,
> Takashi Iwai wrote:
> >
> > Hi Daniel,
> >
> > please pull the get_eld op addition from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> > tags/drm-i915-get-eld
> >
>
On Thu, Dec 17, 2015 at 09:35:03AM -0800, Jesse Barnes wrote:
> On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > The sync framework is now used by the i915 driver. Therefore it can be
> > moved out of staging and into the regular tree. Also, the public
> >
On Thu, Dec 17, 2015 at 09:49:27AM -0800, Jesse Barnes wrote:
> Yeah we definitely want this, but it'll have to be reconciled with the
> different request->fence patches. I'm not sure if it would be easier to move
> to per-context seqnos first or go this route and deal with the mismatch
> betwe
On Wed, Dec 16, 2015 at 10:02:29PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 18, 2015 at 03:19:39PM +, Chris Wilson wrote:
> > There was a silent conflict between
> >
> > commit 0a878716265e9af9f697264dc2e858fcc060d833
> > Author: Daniel Vetter
> > Date: Thu Oct 15 14:23:01 2015 +0200
> >
On Mon, 21 Dec 2015 10:59:41 +0100,
Daniel Vetter wrote:
>
> On Mon, Dec 21, 2015 at 10:25:14AM +0100, Takashi Iwai wrote:
> > On Thu, 10 Dec 2015 14:16:03 +0100,
> > Takashi Iwai wrote:
> > >
> > > Hi Daniel,
> > >
> > > please pull the get_eld op addition from:
> > >
> > > git://git.kernel.
On Tue, Dec 15, 2015 at 12:40:30PM +0800, Gary Wang wrote:
> The total delay of HDMI hotplug detecting with 30ms have already
> been split into a resolution of 3 retries of 10ms each, for the worst
> cases. But it still suffered from only waiting 10ms at most in
> intel_hdmi_detect(). This patch co
== Summary ==
Built on 7cdc548e77f503593b83a1c5d58f4dcc862c17e2 drm-intel-nightly:
2015y-12m-18d-19h-26m-21s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2)
pass -> DMESG-WARN (skl-i7k-2)
Te
On Mon, Dec 21, 2015 at 11:29:16AM +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 12:40:30PM +0800, Gary Wang wrote:
> > The total delay of HDMI hotplug detecting with 30ms have already
> > been split into a resolution of 3 retries of 10ms each, for the worst
> > cases. But it still suffered
On 18 December 2015 at 17:25, wrote:
> From: Ville Syrjälä
>
> The test tries to anger CHV pipe C cursor by walking the edges of the
> screen while moving the cursor across the screen edge.
>
> The actual hw issue only occurs on pipe C, and only on the left screen
> edge. The testcase can walk a
On 18 December 2015 at 17:25, wrote:
> From: Ville Syrjälä
>
> Several tests do one or more of the followin:
> * igt_create_fb() + igt_paint_test_pattern()
> * igt_create_color_fb() + igt_paint_test_pattern()
> * igt_create_fb() + igt_paint_image()
>
> Extract them into new helpes: igt_create_pa
On Wed, Dec 16, 2015 at 06:36:48PM +, Dave Gordon wrote:
> We set up engines in forwards order, so some things (notably the
> default context) are "owned" by engine 0 (the render engine, aka "RCS").
> For symmetry and to make sure such shared objects don't disappear too
> early, we should gener
On Mon, Dec 21, 2015 at 11:48:35AM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 06:36:48PM +, Dave Gordon wrote:
> > We set up engines in forwards order, so some things (notably the
> > default context) are "owned" by engine 0 (the render engine, aka "RCS").
> > For symmetry and to mak
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results, but every client is woken up after
every batch
On 21/12/15 11:01, Chris Wilson wrote:
On Mon, Dec 21, 2015 at 11:48:35AM +0100, Daniel Vetter wrote:
On Wed, Dec 16, 2015 at 06:36:48PM +, Dave Gordon wrote:
We set up engines in forwards order, so some things (notably the
default context) are "owned" by engine 0 (the render engine, aka "R
Disable DP link training optimization if DP link configuration
changes. If one of the DP link parameters i.e. link rate or
lane count changes the link training does no longer apply the
previously computed drive current and pre-emphasis level.
Instead, the link training is started with zero values.
These two patches are fixes for DP link trainging failures and flickering issues
reported by
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Mika Kahola (2):
drm/i915: Disable fast link training if DP config changes
drm/i915: Check DP no aux transaction bit on link training
dr
Check if no AUX transactions are required on DP link training.
If this bit is set, we can reuse the known good drive current
and pre-emphasis level from the last "full" link training.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915
On some HSW boards all pipeC tests fail with various dmesg errors.
This seems to be caused by Pipe C beeing disabled in FUSE_STRAP and
thus reading back the PIPECONF register is always zero.
Fixed by adjusting pipe_count to 2 and thus the pipeC igt tests will
be skipped.
Signed-off-by: Gabriel Fe
On Mon, Dec 21, 2015 at 10:37:25AM +, Chris Wilson wrote:
> On Mon, Dec 21, 2015 at 11:29:16AM +0100, Daniel Vetter wrote:
> > On Tue, Dec 15, 2015 at 12:40:30PM +0800, Gary Wang wrote:
> > > The total delay of HDMI hotplug detecting with 30ms have already
> > > been split into a resolution of
On 21/12/15 08:11, Joonas Lahtinen wrote:
On pe, 2015-12-18 at 16:18 +, Dave Gordon wrote:
On 18/12/15 12:27, Joonas Lahtinen wrote:
Take advantage of WARN return value to simplify the flow.
Cc: Rob Clark
Reviewed-by: Chris Wilson
Reported-by: Chris Wilson
Signed-off-by: Joonas Lahtinen
On Wed, Dec 16, 2015 at 07:22:25PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 04:28:36PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 16, 2015 at 02:51:20PM +0200, Ville Syrjälä wrote:
> > > On Wed, Dec 16, 2015 at 11:30:19AM +0100, Daniel Vetter wrote:
> > > > On Mon, Dec 14, 2015 at 06:
On Fri, Dec 18, 2015 at 12:38:59PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> The device struct_mutex needs to be held before releasing any GEM
> objects allocated by GuC.
>
> WARNING: CPU: 0 PID: 1575 at include/drm/drm_gem.h:217
> gem_release_guc_obj+0x5f/0x70 [i915]()
> Call
On Fri, Dec 18, 2015 at 12:34:16PM +0200, Imre Deak wrote:
> On pe, 2015-12-18 at 11:59 +0200, Jani Nikula wrote:
> > On Thu, 17 Dec 2015, Imre Deak wrote:
> > > On Thu, 2015-12-17 at 09:49 -0800, Ben Widawsky wrote:
> > > > +> if (IS_GEN9(ring->dev))
> > >
> > > Nitpick: INTEL_INFO(
On Thu, Dec 17, 2015 at 10:49:24PM +0200, Imre Deak wrote:
> On Thu, 2015-12-17 at 09:49 -0800, Ben Widawsky wrote:
> > It is unclear if this is even required on BXT.
>
> I'm not sure either, I only added it on the premise that it was marked
> as SKL+ originally in BSpec. The revision log entry in
On Fri, Dec 18, 2015 at 07:24:19AM -0800, Matt Roper wrote:
> On Fri, Dec 18, 2015 at 07:14:17AM -0800, Matt Roper wrote:
> > On Fri, Dec 18, 2015 at 05:10:12PM +0200, Ville Syrjälä wrote:
> > > On Fri, Dec 18, 2015 at 06:58:58AM -0800, Matt Roper wrote:
> > > > On Fri, Dec 18, 2015 at 12:35:47PM +
== Summary ==
Built on c7ae36da9cc3dd7480cec86a8b19fc76d075927d drm-intel-nightly:
2015y-12m-21d-10h-37m-34s UTC integration manifest
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS (bsw-nuc-2)
pass -> DMESG-WARN (hsw-gt2)
== Summary ==
Built on c7ae36da9cc3dd7480cec86a8b19fc76d075927d drm-intel-nightly:
2015y-12m-21d-10h-37m-34s UTC integration manifest
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS (bsw-nuc-2)
pass -> DMESG-WARN (hsw-gt2)
== Summary ==
Built on c7ae36da9cc3dd7480cec86a8b19fc76d075927d drm-intel-nightly:
2015y-12m-21d-10h-37m-34s UTC integration manifest
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS (bsw-nuc-2)
pass -> DMESG-WARN (hsw-gt2)
On Thu, Dec 17, 2015 at 06:18:05PM +, Chris Wilson wrote:
> As we add the VMA to the request early, it may be cancelled during
> execbuf reservation. This will leave the context object pointing to a
> dangling request; i915_wait_request() simply skips the wait and so we
> may unbind the object
On Fri, Dec 18, 2015 at 04:53:28PM +, Daniel Stone wrote:
> [Paging danvet to the bottom paragraphs re client-cap ...]
>
> Hi Lionel,
> I've still got quite a few concerns about the implementation as it
> stands. Some are minor quibbles (e.g. can't unset blob IDs), some are
> larger design iss
On Thu, Dec 17, 2015 at 06:57:53PM +, Lionel Landwerlin wrote:
> From: Shashank Sharma
>
> Color Management is an extension to DRM framework to allow hardware color
> correction and enhancement capabilities.
>
> DRM color manager supports these color properties:
> 1. "ctm": Color transformat
On Thu, Dec 17, 2015 at 06:57:56PM +, Lionel Landwerlin wrote:
> From: Shashank Sharma
>
> Implement degamma, csc and gamma steps on CHV.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/
On Mon, Dec 21, 2015 at 01:28:17PM +0100, Daniel Vetter wrote:
> On Thu, Dec 17, 2015 at 06:18:05PM +, Chris Wilson wrote:
> > As we add the VMA to the request early, it may be cancelled during
> > execbuf reservation. This will leave the context object pointing to a
> > dangling request; i915_
There's two blocks to parse, have one function per block. The existing
one cuts neatly into two.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/
The sequence block has sizes of elements after the operation byte since
sequence block v3. Use it to skip elements we don't support yet.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 +-
1 file changed, 24 insertions(+), 19 deletions(-
Untie the VBT based generic panel driver from the VBT parsing, so that
the two don't have to be updated in lockstep.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/d
Hi all, this is follow-up to my earlier opregion/vbt series [1]. This
covers patches 1 and 7 of Deepak's series [2], but does quite a bunch of
rework to make everything as neat as it can be given the spec. There's
also some generic VBT documentation.
Unfortunately I haven't been able to test this
Add parsing of the i2c element, defined in MIPI sequence block v2. Drop
the status operation byte while at it, that does not exist.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 5 +
drivers/gpu/drm/i915/intel_bios.h | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-
Properly parse the new sequences added in MIPI sequence block v2.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 411b33794536..6146f1b0cf48 100644
Add an overview and documentation for the VBT/BDB header structures.
Signed-off-by: Jani Nikula
---
Documentation/DocBook/gpu.tmpl| 6 ++
drivers/gpu/drm/i915/intel_bios.c | 24 +++-
drivers/gpu/drm/i915/intel_bios.h | 38 --
3 fil
Make everything a bit more readable and clear.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 158 +-
drivers/gpu/drm/i915/intel_bios.h | 4 +-
3 files changed, 57 insertions(+), 107 deletions(-
Make the whole thing easier to read.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 76 +--
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 7393596
Have get_blocksize() support the special case of MIPI sequence block v3+
which has a separate field for size. Provide and use abstractions for
getting the blocksize given a pointer to the block "envelope",
i.e. pointer to the block id, and given a pointer to the block payload
data.
Signed-off-by:
The changes since the sequence block v2 are:
* The whole MIPI bios data block has a separate 32-bit size field since
v3, stored after the version. This facilitates big sequences.
* The size of the panel specific sequence blocks has grown to 32
bits. This facilitates big sequences.
* The elem
Untie the VBT based generic panel driver from the VBT parsing, so that
the two don't have to be updated in lockstep.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/d
Just for OCD.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 2dc46a98c332..21c162e01189 100644
--- a/drivers/gpu/drm/i915/intel
New sequences, new operations within sequences.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 6146f1b0cf48..350d4e0f75a4 100644
--- a/drivers/g
Make it a bit tidier.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 62 +++---
1 file changed, 22 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 1f9c
From: vkorjani
New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.
v2: Add i2c_put_adapter call(Jani), rebase
v3: corrected the retry loop(Jani), rebase
v4 by Jani:
- don't put the adapter if get fails
- print an
== Summary ==
Built on ac2305b6c91b9a84cc12566016ece257c3ebcba3 drm-intel-nightly:
2015y-12m-17d-16h-19m-23s UTC integration manifest
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS (bsw-nuc-2)
pass -> DMESG-WARN (hsw-brixbox)
== Summary ==
Built on e858593f63757a993fa56f282cb1493c57810a20 drm-intel-nightly:
2015y-12m-21d-12h-06m-20s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (skl-i5k-2)
pass -> DMESG-WARN (skl-i7k-2)
Te
== Summary ==
Built on e858593f63757a993fa56f282cb1493c57810a20 drm-intel-nightly:
2015y-12m-21d-12h-06m-20s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (skl-i5k-2)
pass -> DMESG-WARN (skl-i7k-2)
Te
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> On skylake when calculating plane visibility with the crtc in
> dpms off mode the real cdclk may be different from what it would be
> if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock)
> from skl_max_scale. The fix
On Fri, Dec 18, 2015 at 02:11:24PM +0200, Joonas Lahtinen wrote:
> On pe, 2015-12-18 at 12:03 +, Dave Gordon wrote:
> > On 18/12/15 10:39, Joonas Lahtinen wrote:
> > > Using __stringify(x) instead of #x adds support for macros as
> > > a parameter and reduces runtime overhead.
> > >
> > > Slig
Ander had a comment s/During//
Other than this is
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> When the crtc is configured but not active we currently clip to (0,0)x(0,0).
> This results in differences in calculations depending on dpms setting.
> When the crtc is enabled but not
== Summary ==
Built on e858593f63757a993fa56f282cb1493c57810a20 drm-intel-nightly:
2015y-12m-21d-12h-06m-20s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (skl-i5k-2)
pass -> DMESG-WARN (skl-i7k-2)
Te
On Fri, Dec 18, 2015 at 01:08:16PM +0200, Joonas Lahtinen wrote:
> Move all the bool variables to the end as per the comment.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Joonas Lahtinen
Merged the first 2 patches from this series, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_params.h
On Mon, Dec 21, 2015 at 11:53:52AM +, Dave Gordon wrote:
> On 21/12/15 08:11, Joonas Lahtinen wrote:
> >On pe, 2015-12-18 at 16:18 +, Dave Gordon wrote:
> >>On 18/12/15 12:27, Joonas Lahtinen wrote:
> >>>Take advantage of WARN return value to simplify the flow.
> >>>
> >>>Cc: Rob Clark
> >
On Fri, Dec 18, 2015 at 03:01:16PM -, Patchwork wrote:
> == Summary ==
>
> HEAD is now at da33ddb drm-intel-nightly: 2015y-12m-18d-13h-53m-06s UTC
> integration manifest
> Applying: drm/i915: Extend LRC pinning to cover GPU context writeback
> Repository lacks necessary blobs to fall back on
On Fri, Dec 18, 2015 at 07:24:39PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Turns out CHV pipe C was glued on somewhat poorly, and there's something
> wrong with the cursor. If the cursor straddles the left screen edge,
> and is then moved away from the edge or disabl
On Mon, Dec 21, 2015 at 02:49:18PM +0100, Daniel Vetter wrote:
> On Fri, Dec 18, 2015 at 07:24:39PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Turns out CHV pipe C was glued on somewhat poorly, and there's something
> > wrong with the cursor. If the cursor straddl
On 21/12/2015 10:03, Daniel Vetter wrote:
On Thu, Dec 17, 2015 at 09:35:03AM -0800, Jesse Barnes wrote:
On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The sync framework is now used by the i915 driver. Therefore it can be
moved out of staging and into the regular
Signed-off-by: Jani Nikula
---
tools/intel_opregion_decode.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/intel_opregion_decode.c b/tools/intel_opregion_decode.c
index b19566108ed7..c65828ae2900 100644
--- a/tools/intel_opregion_decode.c
+++ b/tools/intel_opregio
Due to the clever way the whole sequence block is specified without
forward compatibility, it's not possible to dump most blocks without
this.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/intel_bios_re
Bail out on v3+, we don't support that just yet.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index e308eaa081d6..09ca50d44a77 100644
--- a/tools/intel_bios_reader.c
+++ b/t
Simplify things a lot, make it correct, don't pass random pointers to
free() on errors, etc.
Signed-off-by: Jani Nikula
---
tools/intel_bios.h| 19 ++--
tools/intel_bios_reader.c | 224 +-
2 files changed, 78 insertions(+), 165 deletions(-)
d
Try to print something useful and helpful for the user.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 1b1cb6bc8
In commit
commit 024c9045221fe45482863c47c4b4c47d37f97cbf
Author: Matt Roper
Date: Thu Sep 24 15:53:11 2015 -0700
drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style
WM (v4)
I fumbled while converting the dimensions stored in the plane_param
On Mon, Dec 21, 2015 at 11:15:04AM +0530, Kumar, Shobhit wrote:
> On 12/19/2015 08:14 AM, Matt Roper wrote:
> >On Fri, Dec 18, 2015 at 03:58:52PM -0800, Radhakrishna Sripada wrote:
> >>Original value of 32 blocks is not sufficient when using cursor size of
> >>256x256 causing FIFO underruns when th
From: Tvrtko Ursulin
Currently a single request submission in execlist mode results
in two emitted interrupts. First the user interrupt arrives and
is then followed by the context complete interrupt. (This time
delay is caused by the time taken by the GPU to write out the
context and update the C
On Mon, Dec 21, 2015 at 02:20:59PM +, John Harrison wrote:
> On 21/12/2015 10:03, Daniel Vetter wrote:
> >On Thu, Dec 17, 2015 at 09:35:03AM -0800, Jesse Barnes wrote:
> >>On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> >>>From: John Harrison
> >>>
> >>>The sync framework is now use
On Fri, Dec 18, 2015 at 07:25:48PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add support for reading the CRC in non-blocking mode. Useful for tests
> that want to start the CRC capture, then do a bunch of operations, then
> collect however many CRCs that got generated.
On Fri, Dec 18, 2015 at 07:25:47PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> It's nice to see just how many components the crc claims to have
> when the count don't match what we expect.
>
> Signed-off-by: Ville Syrjälä
Assuming that you're on vacation already merge
On Mon, Dec 21, 2015 at 05:33:41AM +, Kumar, Abhay wrote:
> Changed the implementation using boottime and removed jiffies. Please review
> and let us know if this is close.
Comments like these should be part of the patch submission itself,
including a note about which reviewer made the sugges
On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote:
> Once all the preparations are complete, we are ready to write the
> modesetting to the hardware. During this phase, we will be making lots
> of HW register access, so take a top level wakeref to prevent an
> unwarranted rpm suspend cyc
On Sat, Dec 19, 2015 at 03:02:49PM +, Chris Wilson wrote:
> On Sat, Dec 19, 2015 at 03:40:39PM +0100, Lukas Wunner wrote:
> > Clean up after 0c82312f3f15 ("drm/i915: Pin the ifbdev for the
> > info->system_base GGTT mmapping"):
> >
> > At each of the remaining "goto out" in intelfb_alloc(), fb
1. add call to i915_gem_context_fini() to deallocate the default
context(s) if the call to init_rings() fails, so that we don't
leak the context in that situation.
2. remove useless code in intel_logical_ring_cleanup(), presumably
copypasted from legacy ringbuffer version at creation.
Si
Some of the LRC-specific context-destruction code has to special-case
the global default context, bacause the HWSP is part of that context. At
present it deduces it indirectly by checking for the backpointer from
the engine to the context, but that's an unsafe assumption if the setup
and teardown c
All the engines share the same default (intel_)context, so we can just
keep a single reference to it in the dev_priv structure rather than in
each of the engine[] elements. This make refcounting more sensible too,
as we now have a refcount of one for the one pointer, rather than a
refcount of one b
There are quite a number of places where the driver tests whether a
given context is or is not the global default context, usually by
checking whether an engine's default_pointer points to the context. Now
that we have a 'is_global_default' flag in the context itself, these can
be rewritten to use
A collection of patches to simplify the creation, use, and destruction
of the driver's global default context.
The first two simplify the many places where the code treats the
global default context differently from any other context:
[1/6] drm/i915: mark the global default (intel
1. Fix intel_cleanup_ring_buffer() to handle the error cleanup
case where the ringbuffer has been allocated but map-and-pin
failed. Unpin it iff it's previously been mapped-and-pinned.
2. Fix the error path in intel_init_ring_buffer(), which already
called intel_destroy_ringbuffer_obj(),
There are a number of places where the driver needs a request, but isn't
working on behalf of any specific user or in a specific context. For
such requests, we associate them with the default context for the engine
that the request will be submitted to.
This patch provides a shorthand for doing su
On Mon, Dec 21, 2015 at 01:07:23PM +0200, Marius Vlad wrote:
> Signed-off-by: Marius Vlad
Hm, why that? Given that this is against the usual style in igt this needs
some justification, not an empty commit message.
Thanks, Daniel
> ---
> lib/igt_kms.c | 321 +
On Mon, Dec 21, 2015 at 05:02:08PM +0100, Daniel Vetter wrote:
> On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote:
> > Once all the preparations are complete, we are ready to write the
> > modesetting to the hardware. During this phase, we will be making lots
> > of HW register access,
On Mon, Dec 21, 2015 at 04:14:53PM +, Chris Wilson wrote:
> On Mon, Dec 21, 2015 at 05:02:08PM +0100, Daniel Vetter wrote:
> > On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote:
> > > Once all the preparations are complete, we are ready to write the
> > > modesetting to the hardware.
On Mon, Dec 21, 2015 at 05:28:16PM +0100, Daniel Vetter wrote:
> On Mon, Dec 21, 2015 at 04:14:53PM +, Chris Wilson wrote:
> > On Mon, Dec 21, 2015 at 05:02:08PM +0100, Daniel Vetter wrote:
> > > On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote:
> > > > Once all the preparations are
Thanks Daniel. Will push today with proper comment.
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, December 21, 2015 7:58 AM
To: Kumar, Abhay
Cc: Intel-gfx@lists.freedesktop.org; Syrjala, Ville; Paulo Zanoni
Subject: Re: [Int
== Summary ==
Built on 78deeec98b10627fe2050ce8ebfa2ea2d5b9e6c7 drm-intel-nightly:
2015y-12m-21d-16h-03m-57s UTC integration manifest
Test gem_mmap_gtt:
Subgroup basic-small-bo:
dmesg-warn -> PASS (bdw-nuci7)
Test gem_storedw_loop:
Subgroup basic-render:
== Summary ==
HEAD is now at 78deeec drm-intel-nightly: 2015y-12m-21d-16h-03m-57s UTC
integration manifest
Applying: drm/i915/bdw+: Do not emit user interrupts when not needed
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/i915_drv.h
M drivers/gpu/drm/i915/intel
On Mon, Dec 21, 2015 at 04:37:41PM +, Chris Wilson wrote:
> On Mon, Dec 21, 2015 at 05:28:16PM +0100, Daniel Vetter wrote:
> > On Mon, Dec 21, 2015 at 04:14:53PM +, Chris Wilson wrote:
> > > On Mon, Dec 21, 2015 at 05:02:08PM +0100, Daniel Vetter wrote:
> > > > On Sat, Dec 19, 2015 at 09:58
From: Borislav Petkov
gcc complains on 32-bit like this:
drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’:
drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer from \
integer of different size [-Wint-to-pointer-cast]
offset = (unsigne
On Mon, Dec 21, 2015 at 07:53:59PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> gcc complains on 32-bit like this:
>
> drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’:
> drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer from
> \
>
Storing the max_level in dev_priv as VLV/CHV already do is a bit simpler
than calling this standalone function, especially since some of the
callsites need to special-case the call to check whether they're running
on VLV/CHV.
This function was further confusing since it wasn't actually specific to
Hi all.
Every couple of months, I try out the latest Enlightenment ( from git
), using Wayland and EGL. Using Intel graphics ( I've tried quite a
few, including the latest i5 and i7 integrated chips ), there are some
serious issues that look driver-related. I can now actually *start* a
Wayland / E
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_pm.c
between commit:
344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
from Linus' tree and commit:
06e668ac91c9 ("drm/i915: Apply broader WaRsDisableCoarsePowerGati
1 - 100 of 117 matches
Mail list logo
