On Tue, Mar 28, 2017 at 08:23:53AM +0200, Daniel Vetter wrote:
> On Mon, Mar 27, 2017 at 04:12:05PM -0400, Harry Wentland wrote:
> > On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
> > > This is just prep work to get an acquire ctx into every place where we
> > > call ->update_pla
On Mon, Mar 27, 2017 at 08:13:17PM -0400, Harry Wentland wrote:
> On Wednesday, March 22, 2017 10:50:52 PM EDT Daniel Vetter wrote:
> > No need to grab both plane and crtc locks at the same time, we can do
> > them one after the other. If userspace races it'll get what it
> > deserves either way.
>
On Mon, Mar 27, 2017 at 04:12:05PM -0400, Harry Wentland wrote:
> On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
> > This is just prep work to get an acquire ctx into every place where we
> > call ->update_plane or ->disable_plane.
> >
> > v2: Keep the hidden acquire_ctx pointer
Matthew Auld writes:
> If we were to ever encounter a sample_flags mismatch we need to ensure
> we destroy the stream when we bail.
>
> Fixes: d79651522e89 ("drm/i915: Enable i915 perf stream for Haswell OA unit")
> Signed-off-by: Matthew Auld
> Cc: Robert Bragg
Reviewed-by: Mika Kuoppala
>
== Series Details ==
Series: drm/i915/scheduler: add gvt force-single-submission and notification
for guc
URL : https://patchwork.freedesktop.org/series/21972/
State : warning
== Summary ==
Series 21972v1 drm/i915/scheduler: add gvt force-single-submission and
notification for guc
https://pa
GVT needs single submission and cannot allow merge. So when GuC submitting
a GVT request, the next one should be submitted to guc later until the
previous one is completed. This is following the usage when using execlist
mode submission.
Cc: ch...@chris-wilson.co.uk
Signed-off-by: Chuanxiao Dong
GVT requires force-single-submission and notification when i915
using execlist submit, and these should be extended to GuC when
i915 using GuC submit. Below two patches are used to implement this
Chuanxiao Dong (2):
drm/i915/scheduler: add gvt force-single-submission for guc
drm/i915/scheduler
GVT request needs a manual mmio load/restore. Before GuC submit
a request, send notification to gvt for mmio loading. And after
the GuC finished this GVT request, notify gvt again for mmio
restore. This follows the usage when using execlists submission.
Cc: xiao.zh...@intel.com
Cc: kevin.t...@inte
On Wednesday, March 22, 2017 10:50:52 PM EDT Daniel Vetter wrote:
> No need to grab both plane and crtc locks at the same time, we can do
> them one after the other. If userspace races it'll get what it
> deserves either way.
>
> This removes another user of drm_modeset_lock_crtc. There's only one
> > Reviewed-by: Zhenyu Wang
>
> Entirely disabling stolen is rather massive, this stuff is supposed to
> work ... There should be special RMRR mappings in the iommu to help the
> guest access the stolen range correctly from the gpu.
>
> Which machine where does this blow up on?
> -Daniel
[Zhang
On 25/03/17 02:38, Chris Wilson wrote:
On Fri, Mar 24, 2017 at 06:30:09PM -0700, Michel Thierry wrote:
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do
Patches 2-5, 9-12, 14-19: Reviewed-by: Harry Wentland
Patches 1,13: Questions in response to those patches
Patches 6-8: Acked-by: Harry Wentland
Looks like a nice cleanup.
Harry
On Wednesday, March 22, 2017 10:50:39 PM EDT Daniel Vetter wrote:
> Hi all,
>
> This is something I kinda had on
On 03/24/2017 01:59 AM, Chris Wilson wrote:
On Thu, Mar 23, 2017 at 09:36:10AM -0700, Oscar Mateo wrote:
On 03/23/2017 03:57 PM, Chris Wilson wrote:
I'm not happy with moving subfeature detection logic into the core GEM
code. if (i915.enable_guc_loading) firstly should never be a module
param
== Series Details ==
Series: drm/i915/dp: Validate cached link rate and lane count before retraining
(rev2)
URL : https://patchwork.freedesktop.org/series/21797/
State : success
== Summary ==
Series 21797v2 drm/i915/dp: Validate cached link rate and lane count before
retraining
https://patch
Hi! Just an FYI I am planning on taking a look at this very soon
On Mon, 2017-03-27 at 18:02 +0200, Takashi Iwai wrote:
> Hi,
>
> the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> drm/i915: Call intel_dp_mst_resume() before resuming displays
>
> seems to trigger a kernel panic when
== Series Details ==
Series: drm/i915/perf: destroy stream on sample_flags mismatch
URL : https://patchwork.freedesktop.org/series/21954/
State : success
== Summary ==
Series 21954v1 drm/i915/perf: destroy stream on sample_flags mismatch
https://patchwork.freedesktop.org/api/1.0/series/21954/r
On 25/03/17 02:26, Chris Wilson wrote:
On Fri, Mar 24, 2017 at 06:30:07PM -0700, Michel Thierry wrote:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 87e76ef589b1..d484cbc561eb 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_ir
== Series Details ==
Series: drm/i915/perf: remove user triggerable warn
URL : https://patchwork.freedesktop.org/series/21953/
State : success
== Summary ==
Series 21953v1 drm/i915/perf: remove user triggerable warn
https://patchwork.freedesktop.org/api/1.0/series/21953/revisions/1/mbox/
fi-b
Currently intel_dp_check_link_status() tries to retrain the link if
Clock recovery or Channel EQ for any of the lanes indicated by
intel_dp->lane_count is not set. However these values cached in intel_dp
structure can be stale if link training has failed for these values
during previous modeset. Or
On 03/23, Robert Bragg wrote:
> This change is pre-emptively aiming to avoid a potential cause of kernel
> logging noise in case some condition were to result in us seeing invalid
> OA reports.
>
> The workaround for the OA unit's tail pointer race condition is what
> avoids the primary know cause
On Mon, Mar 27, 2017 at 10:06:45PM +0100, Chris Wilson wrote:
> On Mon, Mar 27, 2017 at 11:11:47AM +0100, Tvrtko Ursulin wrote:
> >
> > On 26/03/2017 09:46, Chris Wilson wrote:
> > >Unlocking is dangerous. In this case we combine an early update to the
> > >out-of-queue request, because we know th
On Mon, Mar 27, 2017 at 11:11:47AM +0100, Tvrtko Ursulin wrote:
>
> On 26/03/2017 09:46, Chris Wilson wrote:
> >Unlocking is dangerous. In this case we combine an early update to the
> >out-of-queue request, because we know that it will be inserted into the
> >correct FIFO priority-ordered slot wh
== Series Details ==
Series: drm/i915: Keep all engine locks across scheduling (rev3)
URL : https://patchwork.freedesktop.org/series/21890/
State : success
== Summary ==
Series 21890v3 drm/i915: Keep all engine locks across scheduling
https://patchwork.freedesktop.org/api/1.0/series/21890/revi
On 25/03/17 02:01, Chris Wilson wrote:
On Fri, Mar 24, 2017 at 06:29:54PM -0700, Michel Thierry wrote:
As all other functions related to resetting engines are using reset_engine.
However, we should aim to clear any confusion between this and our
requests. Maybe gen8_reset_engine_start and gen
If we were to ever encounter a sample_flags mismatch we need to ensure
we destroy the stream when we bail.
Fixes: d79651522e89 ("drm/i915: Enable i915 perf stream for Haswell OA unit")
Signed-off-by: Matthew Auld
Cc: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 3 ++-
1 file changed, 2 i
Don't throw a warning if we are given an invalid property id. While
here let's also bring back Robert' original idea of catching unhandled
enumeration values at compile time.
Fixes: eec688e1420d ("drm/i915: Add i915 perf infrastructure")
Signed-off-by: Matthew Auld
Cc: Robert Bragg
---
drivers/
On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
> This is just prep work to get an acquire ctx into every place where we
> call ->update_plane or ->disable_plane.
>
> v2: Keep the hidden acquire_ctx pointers valid while transitioning.
>
> Signed-off-by: Daniel Vetter
> ---
> d
On Mon, 2017-03-27 at 22:31 +0300, Jani Nikula wrote:
> On Mon, 27 Mar 2017, "Pandiyan, Dhinakaran"
> wrote:
> > On Mon, 2017-03-27 at 14:33 +0300, Jani Nikula wrote:
> >> Several major vendor USB-C->HDMI converters, in particular the DA200,
> >> fail to recover a 5.4 GHz 1 lane signal if the lin
Unlocking is dangerous. In this case we combine an early update to the
out-of-queue request, because we know that it will be inserted into the
correct FIFO priority-ordered slot when it becomes ready in the future.
However, given sufficient enthusiasm, it may become ready as we are
continuing to re
On Mon, 27 Mar 2017, "Pandiyan, Dhinakaran"
wrote:
> On Mon, 2017-03-27 at 14:33 +0300, Jani Nikula wrote:
>> Several major vendor USB-C->HDMI converters, in particular the DA200,
>> fail to recover a 5.4 GHz 1 lane signal if the link N is greater than
>> 0x8.
>>
>> The link M and N depend o
== Series Details ==
Series: drm/i915: Cursor code cleanup and cursor "FBC" support for IVB+ (rev2)
URL : https://patchwork.freedesktop.org/series/20835/
State : success
== Summary ==
Series 20835v2 drm/i915: Cursor code cleanup and cursor "FBC" support for IVB+
https://patchwork.freedesktop.o
On Sat, 25 Mar 2017, Chris Wilson wrote:
> One POSTING_READ of ACTHD may not be enough to ensure that the seqno
> write has been posted from the GPU and is now visible. So do three!
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97557
> References: https://bugs.freedesktop.org/show_b
From: Ville Syrjälä
It looks like simply writing all the cursor register every single
time might be slightly faster than checking to see of each of
them need to be written. So if any other register apart from
CURPOS needs to be written let's just write all the registers.
CURPOS is left as a spec
From: Ville Syrjälä
Supposedly 845/865 require only 32 byte alignment for CURBASE. Let's
relax the checks to allow that instead of demanding 4KiB alignment.
This will allow cursor panning in 8 pixel units.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file cha
From: Ville Syrjälä
The cursor plane doesn't have any kind of source offset register, so
the only form of panning possible is via a the base address register.
The alignment required by CURBASE ranges from 32B to 16KiB depending
on the platform. Let's make sure the user didn't ask for something
we
From: Ville Syrjälä
Bspec tells us that gen3 platforms need 4KiB alignment for CURBASE
rather than the 256 byte alignment required by i85x. Let's fix that
and pull the code to determine the correct alignment to a helper
function.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_disp
From: Ville Syrjälä
IVB introduced the CUR_FBC_CTL register which allows reducing the cursor
height down to 8 lines from the otherwise square cursor dimensions.
Implement support for it. CUR_FBC_CTL can't be used when the cursor
is rotated.
Commandeer the otherwise unused cursor->cursor.size to
From: Ville Syrjälä
The remaining cursor base address calculations are spread
around into several different locations. Just pull it all
into one place.
v2: Don't pass intel_plane as we don't really need it
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_
From: Ville Syrjälä
Move cursor_base, cursor_cntl, and cursor_size from intel_crtc
into intel_plane so that we don't need the crtc for cursor stuff
so much.
Also entirely nuke cursor_addr which IMO doesn't provide any benefit
since it's not actually used by the cursor code itself. I'm not 100%
s
From: Ville Syrjälä
There should be no need to do posting reads between all the cursor
register accessess. Let's just drop them.
v2: Rebase due to I915_WRITE_FW() and uncore.lock
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson #v1
---
drivers/gpu/drm/i915/intel_display.c | 32
From: Ville Syrjälä
The cursor code currently ignores fb->pitches[0] (except when creating
the fb itself), and just uses the cursor_width*4 as the stride. Let's
make sure fb->pitches[0] actually matches what we expect it to be.
We can also relax the stride vs. cursor width relationship on 845/86
From: Ville Syrjälä
Supposedly on some platforms we can get extra atomicity guarantees for
CURPOS if we write it between the CURCNTR and CURBASE. Let's move the
CURPOS handling into the platform specific hooks to make the possible
without having to pass the calculated CURPOS around. And while at
From: Ville Syrjälä
The 845/865 and 830/855/9xx+ style cursor don't have that
much in common with each other, so let's just split the
.check_plane() hook into two variants as well.
v2: Keep the common stuff in one place (Chris)
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reg.h | 7 ++-
drivers/gpu/drm/i915/intel_display.c | 9 +++--
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm
From: Ville Syrjälä
Another iteration of my cursor stuff. I ended up expanding it quite a bit
because I decided that I need to handle the fb/src offsets correctly.
I also tried to address some of Chris's review feedback, mainly about
sharing some of the code between the i9xx and i845/i865 codepa
From: Ville Syrjälä
We have the maximum cursor dimensions stored in the mode_config, so
let's just consult that information instead of hardcoding the same
information in multiple places.
We still need to keep some per-platform checks as the limitations are
quite diverse.
Signed-off-by: Ville Sy
From: Ville Syrjälä
Streamline things by passing intel_plane and intel_crtc instead of
the drm types to our plane hooks.
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 6 +-
drivers/gpu/drm/i915/intel_display.c | 109 +
From: Ville Syrjälä
Move the CURPOS calculations to seprate function. This will allow
sharing the code between the 845/865 vs. others codepaths when we
otherwise split them apart.
v2: Don't pass intel_plane as it's not needed
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers
On Mon, 2017-03-27 at 14:33 +0300, Jani Nikula wrote:
> Several major vendor USB-C->HDMI converters, in particular the DA200,
> fail to recover a 5.4 GHz 1 lane signal if the link N is greater than
> 0x8.
>
> The link M and N depend on the pixel clock and link clock ratio. With
> current code
On Mon, Mar 27, 2017 at 08:21:21PM +0300, Ville Syrjälä wrote:
> On Mon, Mar 27, 2017 at 09:53:36AM -0700, Manasi Navare wrote:
> > On Mon, Mar 27, 2017 at 06:26:06PM +0300, Jani Nikula wrote:
> > > On Mon, 27 Mar 2017, Ville Syrjälä wrote:
> > > > On Thu, Mar 23, 2017 at 04:11:32PM -0700, Manasi
On Mon, 27 Mar 2017, René Rebe wrote:
> How to move forward? Is the xorg intel driver despite missing releases
> under active development, or should I just use the lower performance
> mode setting driver?
Please file a bug over at [1], attach Xorg.0.log and dmesg with
drm.debug=14 module paramete
On Mon, 2017-03-27 at 10:35 +0200, Maarten Lankhorst wrote:
> Op 27-03-17 om 10:31 schreef Daniel Vetter:
> > On Mon, Mar 27, 2017 at 10:28:42AM +0200, Maarten Lankhorst wrote:
> >> Op 27-03-17 om 08:38 schreef Daniel Vetter:
> >>> On Wed, Mar 22, 2017 at 03:30:49PM -0700, Dhinakaran Pandiyan wrote
On 03/23, Robert Bragg wrote:
> These are auto generated from an XML description of metric sets,
> currently maintained in gputop, ref:
>
> https://github.com/rib/gputop
> > gputop-data/oa-*.xml
> > scripts/i915-perf-kernelgen.py
>
> $ make -C gputop-data -f Makefile.xml
>
> Signed-off-by: R
On 03/23, Robert Bragg wrote:
> Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
> share (more-or-less) the same OA unit design.
>
> Of particular note in comparison to Haswell: some OA unit HW config
> state has become per-context state and as a consequence it is somewhat
> m
There is no reason to separately check for valid fw path before
we try to fetch it. Let the fetch function take care of this.
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletion
On Mon, Mar 27, 2017 at 09:53:36AM -0700, Manasi Navare wrote:
> On Mon, Mar 27, 2017 at 06:26:06PM +0300, Jani Nikula wrote:
> > On Mon, 27 Mar 2017, Ville Syrjälä wrote:
> > > On Thu, Mar 23, 2017 at 04:11:32PM -0700, Manasi Navare wrote:
> > >> Currently intel_dp_check_link_status() tries to re
This function is no longer used. Its functionality is covered
by intel_uc_fini_fw().
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_huc.c | 18 --
drivers/gpu/drm/i915/intel_uc.h | 1 -
2 files changed, 19 deletions(-)
Cleanups of uc firmware structs from GuC and Huc are the same for both.
Move common code to the helper function to avoid duplication.
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uc.c | 30 +++---
1 file changed,
Some of the DRM_NOTE messages are just using "uC" without specifying
which uc they are related to. We can be more user friendly.
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uc.c | 19 +--
drivers/gpu/drm/i915/intel_uc.h
The file fits better. Also use "" for invalid case.
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_guc_loader.c | 16
drivers/gpu/drm/i915/intel_uc.c | 18 ++
drivers/gpu/drm/i915/intel_uc.h
On Mon, Mar 27, 2017 at 06:26:06PM +0300, Jani Nikula wrote:
> On Mon, 27 Mar 2017, Ville Syrjälä wrote:
> > On Thu, Mar 23, 2017 at 04:11:32PM -0700, Manasi Navare wrote:
> >> Currently intel_dp_check_link_status() tries to retrain the link if
> >> Clock recovery or Channel EQ for any of the lane
Hi,
the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
drm/i915: Call intel_dp_mst_resume() before resuming displays
seems to trigger a kernel panic when some modeset change happens after
S3 resume. The details are found in openSUSE bugzilla,
https://bugzilla.suse.com/show_bug.cgi?i
On 03/27/2017 08:22 AM, Jani Nikula wrote:
On Mon, 27 Mar 2017, Daniel Vetter wrote:
On Mon, Mar 27, 2017 at 02:33:25PM +0300, Jani Nikula wrote:
Several major vendor USB-C->HDMI converters, in particular the DA200,
fail to recover a 5.4 GHz 1 lane signal if the link N is greater than
0x8.
On Wed, Mar 22, 2017 at 10:50:46PM +0100, Daniel Vetter wrote:
> Yes the help text is unhelpful, but atomic drivers should never use
> this. Just grab the lock without context or anything.
>
> Also an aside: Checking ->active like this doesn't protect against
> nonblocking commits, this is rather
*Arbitrated system bandwidth workarounds for watermark.*
All GEN-9 based platforms require watermark related WA to be enabled if
Display memory bandwidth requirement is exceeding XX% of total available
system memory bandwidth.
This XX% depend on multiple factors.
*e.g.* if all the enabled plan
Hi,
On Mar 27, 2017, at 17:26, Chris Wilson wrote:
> On Mon, Mar 27, 2017 at 04:47:44PM +0200, René Rebe wrote:
>> Hi all,
>>
>> connecting a Dell 4k MST display using the xorg intel driver on two
>> different machines (Surface Pro 3, Dell XPS 13 9360) results in one of the
>> two halts mirro
On Mon, Mar 27, 2017 at 04:47:44PM +0200, René Rebe wrote:
> Hi all,
>
> connecting a Dell 4k MST display using the xorg intel driver on two different
> machines (Surface Pro 3, Dell XPS 13 9360) results in one of the two halts
> mirrored on the two MST halfs of the display. Using xrandr --left-
On Mon, 27 Mar 2017, Ville Syrjälä wrote:
> On Thu, Mar 23, 2017 at 04:11:32PM -0700, Manasi Navare wrote:
>> Currently intel_dp_check_link_status() tries to retrain the link if
>> Clock recovery or Channel EQ for any of the lanes indicated by
>> intel_dp->lane_count is not set. However these valu
On Mon, 27 Mar 2017, Daniel Vetter wrote:
> On Mon, Mar 27, 2017 at 02:33:25PM +0300, Jani Nikula wrote:
>> Several major vendor USB-C->HDMI converters, in particular the DA200,
>> fail to recover a 5.4 GHz 1 lane signal if the link N is greater than
>> 0x8.
>>
>> The link M and N depend on t
Hi all,
connecting a Dell 4k MST display using the xorg intel driver on two different
machines (Surface Pro 3, Dell XPS 13 9360) results in one of the two halts
mirrored on the two MST halfs of the display. Using xrandr --left-of /
--right-of I could not yet find a combination that would correc
On Mon, Mar 27, 2017 at 02:30:08PM +0100, Chris Wilson wrote:
> On Mon, Mar 27, 2017 at 04:19:58PM +0300, Mika Kuoppala wrote:
> > Chris Wilson writes:
> >
> > > On Mon, Mar 27, 2017 at 01:12:30PM +0300, Mika Kuoppala wrote:
> > >> Chris Wilson writes:
> > >>
> > >> > One POSTING_READ of ACTHD
On Sat, Mar 25, 2017 at 02:19:13PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Mark manually wedged engines as guilty
> URL : https://patchwork.freedesktop.org/series/21882/
> State : success
>
> == Summary ==
>
> Series 21882v1 drm/i915: Mark manually wedged engines a
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Chris Wilson
> Sent: Monday, March 27, 2017 10:33 PM
> To: Dong, Chuanxiao
> Cc: Zheng, Xiao; intel-gfx@lists.freedesktop.org;
> joonas.lahti...@linux.intel.com; intel-gvt-...@li
On Mon, Mar 27, 2017 at 05:20:25PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Use the incoming value from debugfs/i915_wedged to select which engines
> > to marked as guilty in order to force us to reset those requests
> > (required to quickly bypass simulated hangs).
> >
> > Signed
On Mon, Mar 27, 2017 at 02:22:10PM +, Dong, Chuanxiao wrote:
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Monday, March 27, 2017 9:50 PM
> > To: Dong, Chuanxiao
> > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> >
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Monday, March 27, 2017 9:50 PM
> To: Dong, Chuanxiao
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com
> Subject: Re: [
On Mon, Mar 27, 2017 at 05:00:49PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Mon, Mar 27, 2017 at 04:19:58PM +0300, Mika Kuoppala wrote:
> >> Chris Wilson writes:
> >>
> >> > On Mon, Mar 27, 2017 at 01:12:30PM +0300, Mika Kuoppala wrote:
> >> >> Chris Wilson writes:
> >> >>
Chris Wilson writes:
> Use the incoming value from debugfs/i915_wedged to select which engines
> to marked as guilty in order to force us to reset those requests
> (required to quickly bypass simulated hangs).
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i91
On Mon, Mar 27, 2017 at 02:11:27PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/3] drm/i915/execlists: Wrap tail pointer
> after reset tweaking (rev2)
> URL : https://patchwork.freedesktop.org/series/21930/
> State : success
>
> == Summary ==
>
> Serie
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/execlists: Wrap tail pointer
after reset tweaking (rev2)
URL : https://patchwork.freedesktop.org/series/21930/
State : success
== Summary ==
Series 21930v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
Chris Wilson writes:
> On Mon, Mar 27, 2017 at 04:19:58PM +0300, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > On Mon, Mar 27, 2017 at 01:12:30PM +0300, Mika Kuoppala wrote:
>> >> Chris Wilson writes:
>> >>
>> >> > One POSTING_READ of ACTHD may not be enough to ensure that the seqno
>>
Chris Wilson writes:
> Whilst I like having the assertions clearly visible in the code, they
> are quite repetitious! As we find new limits we want to incorporate into
> the set of assertions, it make sense to refactor them to a common
> routine.
>
> v2: Add a guc holdout.
>
> Signed-off-by: Chri
Chris Wilson writes:
> In addition to being qword-aligned, the RING_TAIL offset must be within
> the ring!
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 4
> drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> 2 files changed
On Mon, Mar 27, 2017 at 09:32:20PM +0800, Chuanxiao Dong wrote:
> GVT request needs a manual mmio load/restore. Before GuC submit
> a request, send notification to gvt for mmio loading. And after
> the GuC finished this GVT request, notify gvt again for mmio
> restore. This follows the usage when u
On Thu, Mar 23, 2017 at 04:11:32PM -0700, Manasi Navare wrote:
> Currently intel_dp_check_link_status() tries to retrain the link if
> Clock recovery or Channel EQ for any of the lanes indicated by
> intel_dp->lane_count is not set. However these values cached in intel_dp
> structure can be stale i
On Mon, Mar 27, 2017 at 04:19:58PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Mon, Mar 27, 2017 at 01:12:30PM +0300, Mika Kuoppala wrote:
> >> Chris Wilson writes:
> >>
> >> > One POSTING_READ of ACTHD may not be enough to ensure that the seqno
> >> > write has been posted from
GVT request needs a manual mmio load/restore. Before GuC submit
a request, send notification to gvt for mmio loading. And after
the GuC finished this GVT request, notify gvt again for mmio
restore. This follows the usage when using execlists submission.
v2: use context_status_change instead of exe
On pe, 2017-03-24 at 10:36 +, Chris Wilson wrote:
> Merge the two vfuncs into one and so eliminate one more case of
> execlists/ringbuffer specialisation outside of the intel_engine_cs.c
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open S
Chris Wilson writes:
> On Mon, Mar 27, 2017 at 01:12:30PM +0300, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > One POSTING_READ of ACTHD may not be enough to ensure that the seqno
>> > write has been posted from the GPU and is now visible. So do three!
>> >
>>
>> Is this about posting r
Whilst I like having the assertions clearly visible in the code, they
are quite repetitious! As we find new limits we want to incorporate into
the set of assertions, it make sense to refactor them to a common
routine.
v2: Add a guc holdout.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
On Fri, Mar 24, 2017 at 10:35:56AM +, Chris Wilson wrote:
> On Thu, Mar 23, 2017 at 09:27:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > All the pre-SKL sprite planes compute the x/y/tile offsets in a
> > similar way. There are a couple of minor differences b
On pe, 2017-03-24 at 08:59 +, Chris Wilson wrote:
> On Thu, Mar 23, 2017 at 09:36:10AM -0700, Oscar Mateo wrote:
> >
> > On 03/23/2017 03:57 PM, Chris Wilson wrote:
> > >
> > > I'm not happy with moving subfeature detection logic into the core GEM
> > > code. if (i915.enable_guc_loading) firs
Chris Wilson writes:
> If the request->wa_tail is 0 (because it landed exactly on the end of
> the ringbuffer), when we reconstruct request->tail following a reset we
> fill in an illegal value (-8 or 0x0018). As a result, RING_HEAD is
> never able to catch up with RING_TAIL and the GPU spins
On Mon, Mar 27, 2017 at 02:33:25PM +0300, Jani Nikula wrote:
> Several major vendor USB-C->HDMI converters, in particular the DA200,
> fail to recover a 5.4 GHz 1 lane signal if the link N is greater than
> 0x8.
>
> The link M and N depend on the pixel clock and link clock ratio. With
> curren
In addition to being qword-aligned, the RING_TAIL offset must be within
the ring!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c| 4
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/d
Whilst I like having the assertions clearly visible in the code, they
are quite repetitious! As we find new limits we want to incorporate into
the set of assertions, it make sense to refactor them to a common
routine.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i
If the request->wa_tail is 0 (because it landed exactly on the end of
the ringbuffer), when we reconstruct request->tail following a reset we
fill in an illegal value (-8 or 0x0018). As a result, RING_HEAD is
never able to catch up with RING_TAIL and the GPU spins endlessly. If
the ring contain
On pe, 2017-03-24 at 09:42 +, Chris Wilson wrote:
> Since removing the module parameter to force selection of ringbuffer
> emission for gen8, the code is defunct. Remove it.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas L
On pe, 2017-03-24 at 09:42 +, Chris Wilson wrote:
> Execlists and legacy ringbuffer submission are no longer feature
> comparable (execlists now offer greater functionality that should
> overcome their performance hit) and obsoletes the unsafe module
> parameter, i.e. comparing the two modes of
On Mon, Mar 27, 2017 at 10:10:54AM +0100, Tvrtko Ursulin wrote:
>
> On 25/03/2017 20:10, Chris Wilson wrote:
> >I noticed that gcc was spilling the CSB to the stack, so rearrange the
> >code to be more compact. Spilling in this function is slightly more
> >interesting due to the mmio reads acting
1 - 100 of 158 matches
Mail list logo
