On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote:
> From: Dhinakaran Pandiyan
>
> Wrap the max. vswing check in a separate function.
> This makes the clock recovery phase of DP link training cleaner
>
> v2:
> Fixed the Compiler warning (Mika Kahola)
>
> Signed-off-by: Dhinakaran Pandiyan
Am 07.09.2016 um 01:04 schrieb Masahiro Yamada:
Remove unneeded variables and assignments.
Signed-off-by: Masahiro Yamada
Tom StDenis was working on a similar patch for amdgpu as well, please
make sure that your work doesn't conflict with his.
Apart from that looks good to me. But I would
On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote:
> From: Dhinakaran Pandiyan
>
> This function cleans up clock recovery loop in link training
> compliant
> tp Dp Spec 1.2. It tries the clock recovery 5 times for the same
> voltage
> or until max voltage swing is reached and removes the add
Reviewed-by: Mika Kahola
On Fri, 2016-09-02 at 22:05 +0300, Pandiyan, Dhinakaran wrote:
> On Fri, 2016-09-02 at 14:20 +0300, Mika Kahola wrote:
> >
> > On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote:
> > >
> > > Fix the number of tries in channel euqalization link training
> > > sequenc
On 9/6/2016 9:22 PM, Tvrtko Ursulin wrote:
On 06/09/16 16:33, Goel, Akash wrote:
On 9/6/2016 6:47 PM, Tvrtko Ursulin wrote:
Hi,
On 06/09/16 11:43, akash.g...@intel.com wrote:
From: Akash Goel
This patch provides a test utility which helps capture GuC firmware
logs and
then dump them to f
SLPC (Single Loop Power Controller) is a replacement for
some host-based power management features. The SLPC
implementation runs in firmware on GuC.
This series has been tested with SKL GuC firmware
version 9.18 which is yet to be released. Performance and
power testing with these patches and 9.1
For Gen9, RPM suspend is dependent on rps.enabled. This is needed for
other platforms as RC6 and RPS enabling is indicated by rps.enabled. RPM
Suspend depends only on RC6, so we need to remove the check of rps.enabled.
For Gen9 RC6 and RPS enabling is separated hence do rps.enabled check only
for n
From: Tom O'Rourke
If slpc enabled, then add enable SLPC flag to guc
control parameter during guc load.
v1: Use intel_slpc_enabled() (Paulo)
Reviewed-by: David Weinehall
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_guc_loader.c | 3 +++
1 file
From: Tom O'Rourke
Add has_slpc capablity flag to indicate GuC firmware
supports single loop power control (SLPC). SLPC is
a replacement for some host-based power management
features.
v1: fix whitespace (Sagar)
Reviewed-by: David Weinehall
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Aru
From: Tom O'Rourke
When frequency requests are made by SLPC, host driver
should not attempt to make frequency requests due to
potential conflicts.
Host-based turbo operations are already avoided when
SLPC is used. This change covers other frequency
requests such as from sysfs or debugfs interfa
From: Tom O'Rourke
On platforms with SLPC support: call intel_slpc_*()
functions from corresponding intel_*_gt_powersave()
functions; and do not use rps functions.
v1: Return void instead of ignored error code (Paulo)
enable/disable RC6 in SLPC flows (Sagar)
replace HAS_SLPC() use with i
From: Tom O'Rourke
Expose host2guc_action for use by SLPC in intel_slpc.c.
Expose functions to allocate and release objects used
by GuC to be used for SLPC shared memory object.
v1: Updated function names as they need to be made extern. (ChrisW)
Reviewed-by: David Weinehall
Signed-off-by: Tom
From: Tom O'Rourke
This patch adds has_slpc to skylake info.
The SLPC interface has changed and could continue to
change. Only GuC versions known to be compatible are
supported here.
On Skylake, GuC firmware v6 is supported. Other
platforms and versions can be added here later.
v1: Move slpc_
From: Tom O'Rourke
i915.enable_slpc is used to override the default for slpc usage.
The expected values are -1=auto, 0=disabled [default], 1=enabled.
slpc_enable_sanitize() converts i915.enable_slpc to either 0 or 1.
Interpretation of default value is based on HAS_SLPC(), after
slpc_version_chec
From: Tom O'Rourke
Add host2guc SLPC reset event and send reset event
during enable.
v1: Extract host2guc_slpc to handle slpc status code
coding style changes (Paulo)
Removed WARN_ON for checking msb of gtt address of
shared gem obj. (ChrisW)
host2guc_action to i915_guc_action ch
From: Tom O'Rourke
Send SLPC shutdown event during disable, suspend, and reset
operations. Sending shutdown event while already shutdown
is OK.
v1: Return void instead of ignored error code (Paulo)
Removed WARN_ON for checking msb of gtt address of
shared gem obj. (ChrisW)
Added SLPC
From: Tom O'Rourke
SLPC shared data is used to pass information
to/from SLPC in GuC firmware.
For Skylake, platform sku type and slice count
are identified from device id and fuse values.
Support for other platforms needs to be added.
v1: Update for SLPC interface version 2015.2.4
intel_sl
From: Tom O'Rourke
The SLPC interface has changed and could continue to
change. Only GuC versions known to be compatible are
supported here.
On Skylake, GuC firmware v9 is supported. Other
platforms and versions can be added here later.
v1: Updated with modified sanitize_slpc_option in earlie
From: Tom O'Rourke
When SLPC is controlling requested frequency, the rps.cur_freq
value is not used to make the frequency request.
Requested frequency from register RPNSWREQ has the value
most recently requested by SLPC firmware. Adding new sysfs
interface gt_req_freq_mhz to know this value.
SLP
From: Tom O'Rourke
v1: fix whitespace (Sagar)
v2-v3: Rebase.
v4: Updated with GuC firmware v9.
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_slpc.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i
From: Tom O'Rourke
i915_slpc_info shows the contents of SLPC shared data
parsed into text format.
v1: Reformat slpc info (Radek)
squashed query task state info
in slpc info, kunmap before seq_print (Paulo)
return void instead of ignored return value (Paulo)
Avoid magic numbers an
With SLPC, only RP SW Mode control should be left enabled by i915.
Else, SLPC requests through through RPNSWREQ will not be granted.
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_pm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i91
From: Tom O'Rourke
Add slpc_param_id enum values.
Add events for setting/unsetting parameters.
v1: Use host2guc_slpc
update slcp_param_id enum values for SLPC 2015.2.4
return void instead of ignored error code (Paulo)
v2: Checkpatch update.
v3: Rebase.
v4: Updated with GuC firmware v9
From: Tom O'Rourke
Adds debugfs hooks for each slpc task.
The enable/disable debugfs files are
i915_slpc_gtperf, i915_slpc_balancer, and i915_slpc_dcc.
Each of these can take the values:
"default", "enabled", or "disabled"
v1: update for SLPC v2015.2.4
dfps and turbo merged and renamed "gt
From: Tom O'Rourke
Adds has_slpc to broxton info and adds broxton firmware version check
to sanitize_slpc_option.
v1: Adjusted slpc version check for major version 8.
Added message if version mismatch happens for easier debug. (Sagar)
v2-v3: Rebase.
v4: Commit message update.
Signed-off-b
From: Tom O'Rourke
Update sysfs and debugfs functions to set SLPC
parameters when setting max/min frequency.
v1: Update for SLPC 2015.2.4 (params for both slice and unslice)
Replace HAS_SLPC with intel_slpc_active() (Paulo)
Signed-off-by: Tom O'Rourke
Signed-off-by: Sagar Arun Kamble
---
v2: Removing checks for vma obj and kmap_atomic validity. (Chris)
v3: Rebase.
v4: Updated to make sure SLPC enable keeps min/max freq softlimits
unchanged after initializing once. (Chris)
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_slpc.c | 47 ++
This will help avoid Host to GuC actions being called till GuC gets
loaded during i915_drm_resume.
v2-v3: Rebase.
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i91
SLPC status has to be linked with GuC load status to make sure
SLPC actions get invoked when GuC is loaded.
v2: Space and function return convention issues. (Deepak)
v3: Rebase.
v4: Limiting the check for SLPC actions.
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_drv.h | 4
v1: Updated tasks and frequency post reset.
Added DFPS param update for MAX_FPS and FPS Stall.
v2-v3: Rebase.
v4: Updated with GuC firmware v9.
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_slpc.c | 41 +++
With SLPC, user can read this value to know SLPC requested frequency.
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_sysfs.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
in
On Wed, 07 Sep 2016, Masahiro Yamada wrote:
> Remove unneeded variables and assignments.
>
> Signed-off-by: Masahiro Yamada
...
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 95ddd56..59d029d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/driver
On Wed, Sep 07, 2016 at 01:40:27PM +0530, Goel, Akash wrote:
>
>
> On 9/6/2016 9:22 PM, Tvrtko Ursulin wrote:
> >
> >On 06/09/16 16:33, Goel, Akash wrote:
> >>On 9/6/2016 6:47 PM, Tvrtko Ursulin wrote:
> >>>Hi,
> >>>
> >>>On 06/09/16 11:43, akash.g...@intel.com wrote:
> From: Akash Goel
> >>
Remove unneeded variables and assignments.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c| 6 +-
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c| 6 +-
drivers/gpu/drm/bridge/analo
Property lifetimes are equal to the device lifetime, so the separate
drm_property_find is not needed. The pointer can be retrieved from
the properties member, which saves us some locking and a extra lookup.
The lifetime for properties is until the device is destroyed, which
happens late in the dev
drm_select_eld requires mode_config.mutex and connection_mutex
because it looks at the connector list and at the legacy encoders.
This is not required, because when we call audio_codec_enable we know
which connector it was called for, so pass the state.
This also removes having to look at crtc->c
This gets rid of a warning that the connectors are used without locking
when doing a nonblocking modeset.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
This fixes a few places where we emit warnings on nonblocking modesets,
then flips the switch and enables it. Tested on my BDW and SKL,
but SKL still fails on the detection whether nonblocking modesets
are supported with some WM related issue.
Fixing this and support for atomic connector propertie
The only user was i915, which is now gone.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_edid.c | 26 --
include/drm/drm_edid.h | 1 -
2 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 50541324a4ab
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a66a4252ee0..9fe8873d82cb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
All of this state should be updated as soon as possible. It shouldn't be
done later because then future updates may not depend on it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/driv
This is the last connector still looking at crtc->config. Fix this.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_hdmi.c | 48 +--
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gp
Op 07-09-16 om 10:58 schreef Maarten Lankhorst:
> Property lifetimes are equal to the device lifetime, so the separate
> drm_property_find is not needed. The pointer can be retrieved from
> the properties member, which saves us some locking and a extra lookup.
>
> The lifetime for properties is unt
== Series Details ==
Series: drm: squash lines for simple wrapper functions
URL : https://patchwork.freedesktop.org/series/12096/
State : warning
== Summary ==
Series 12096v1 drm: squash lines for simple wrapper functions
http://patchwork.freedesktop.org/api/1.0/series/12096/revisions/1/mbox/
On 07/09/16 09:44, Chris Wilson wrote:
On Wed, Sep 07, 2016 at 01:40:27PM +0530, Goel, Akash wrote:
On 9/6/2016 9:22 PM, Tvrtko Ursulin wrote:
[snip]
+while (!stop_logging)
+{
+if (test_duration && (igt_seconds_elapsed(&start) >
test_duration)) {
If you agree to allow no p
On Wed, Sep 07, 2016 at 10:37:07AM +0100, Tvrtko Ursulin wrote:
>
> On 07/09/16 09:44, Chris Wilson wrote:
> >And fixing the blocking read() is about 10 lines in the kernel...
>
> Haven't checked but if that is the case, since we are already fixing
> relayfs issues, it would be good to do that on
On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote:
> According to the DisplayPort Spec, in case of Clock Recovery failure
> the link training sequence should fall back to the lower link rate
> followed by lower lane count until CR succeeds.
> On CR success, the sequence proceeds with Channel E
Introduced with commit cd86866dec.
Signed-off-by: Marius Vlad
CC: Robert Foss
---
demos/Makefile.sources | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/demos/Makefile.sources b/demos/Makefile.sources
index 31f7f83..aea363f 100644
--- a/demos/Makefile.sources
+++ b/demos/Mak
Thanks for catching this Marius.
Reviewed-by Robert Foss
Rob.
On 2016-09-07 05:59 AM, Marius Vlad wrote:
Introduced with commit cd86866dec.
Signed-off-by: Marius Vlad
CC: Robert Foss
---
demos/Makefile.sources | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/demos/Mak
== Series Details ==
Series: drm/i915: Enable support for nonblocking modesets.
URL : https://patchwork.freedesktop.org/series/12098/
State : success
== Summary ==
Series 12098v1 drm/i915: Enable support for nonblocking modesets.
http://patchwork.freedesktop.org/api/1.0/series/12098/revisions/
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
v6: Rebased.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
v2:
- Leave the legacy implementation in place as the ABI implementation
in the core is incompatib
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --g
Hi,
this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.
The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.
Other drivers fo
Signed-off-by: Marius Vlad
---
assembler/gen8_disasm.c | 5 -
lib/intel_device_info.c | 6 --
overlay/igfx.c| 7 ---
tests/testdisplay.c | 1 -
tools/intel_bios_reader.c | 22 --
5 files changed, 41 deletions(-)
diff --git a/assembler/gen
On 9/7/2016 3:07 PM, Tvrtko Ursulin wrote:
On 07/09/16 09:44, Chris Wilson wrote:
On Wed, Sep 07, 2016 at 01:40:27PM +0530, Goel, Akash wrote:
On 9/6/2016 9:22 PM, Tvrtko Ursulin wrote:
[snip]
+while (!stop_logging)
+{
+if (test_duration && (igt_seconds_elapsed(&start) >
On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote:
> From: Jim Bride
>
> Add upfront link training to intel_dp_mst_mode_valid() so that we
> know
> topology constraints before we validate the legality of modes to be
> checked.
> Call the function that loops through the link rates and lane co
Applied. Thanks!
On Tue, Sep 06, 2016 at 03:55:41PM +0100, Derek Morton wrote:
> The benchmark was failing with:
> gem_busy.c:158:8: error: implicit declaration of function 'intel_gen'
> is invalid in C99 [-Werror,-Wimplicit-function-declaration]
> gen = intel_gen(intel_get_drm_devid(fd));
>
> The
On Fri, 19 Aug 2016, David Weinehall wrote:
> On Thu, Aug 18, 2016 at 10:29:43AM +0300, David Weinehall wrote:
>> On Wed, Aug 17, 2016 at 04:43:36PM +0300, Jani Nikula wrote:
>> > On Wed, 17 Aug 2016, Chris Wilson wrote:
>> > > On Wed, Aug 17, 2016 at 03:47:48PM +0300, David Weinehall wrote:
>> >
On Tue, 06 Sep 2016, t s wrote:
> I know that this is not the latest general kernel, but I wonder if this is
> a known problem and what can be done about it.
Try drm-intel-nightly branch of [1], and if the problem persists, file a
bug at [2].
BR,
Jani.
[1] http://cgit.freedesktop.org/drm-intel
On Sun, 04 Sep 2016, Dominik Brodowski wrote:
> Hi!
>
> Since commit 1c80c25fb6 (determined by git bisect, and confirmed by
> reverting this patch on top of 9ca581b50d), the sceen on my DELL XPS 13
> is flickering every once in a while (sometimes multiple times per
> second, sometimes only every f
Hi Tom,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160907]
[cannot apply to v4.8-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto
In preparation for introducing a per-engine reset, we can first separate
the mixing of the reset state from the global reset counter.
The loss of atomicity in updating the reset state poses a small problem
for handling the waiters. For requests, this is solved by advancing the
seqno so that a wait
This is really a core kernel struct in disguise until we can finally
place it in kernel/. There is an immediate need for a fence collection
mechanism that is more flexible than fence-array, in particular being
able to easily drive request submission via events (and not just
interrupt driven). The s
Rather than blindly assuming we need to advance the tail for
resubmitting the request via the ELSP, record the position.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_request.h | 15 +--
drivers/gpu/drm/i915/intel_lrc.c| 4 ++--
2
Access to intel_init_emon() is strictly ordered by gt_powersave, using
struct_mutex around it is overkill (and will conflict with the caller
holding struct_mutex themselves).
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 2 --
1 file changed, 2 del
If we find a ring waiting on a semaphore for another assigned but not yet
emitted request, treat it as valid and waiting.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b
Similar to the issue with reading from the context status buffer,
see commit 26720ab97fea ("drm/i915: Move CSB MMIO reads out of the
execlists lock"), we frequently write to the ELSP register (4 writes per
interrupt) and know we hold the required spinlock and forcewake throughout.
We can further re
Emulate HW to track and manage ELSP queue. A set of SW ports are defined
and requests are assigned to these ports before submitting them to HW. This
helps in cleaning up incomplete requests during reset recovery easier
especially after engine reset by decoupling elsp queue management. This
will bec
In the next patch we want to handle reset directly by a locked waiter in
order to avoid issues with returning before the reset is handled. To
handle the reset, we must first know whether we hold the struct_mutex.
If we do not hold the struct_mtuex we can not perform the reset, but we do
not block t
Leave the more complicated request dequeueing to the tasklet and instead
just kick start the tasklet if we detect we are adding the first
request.
v2: Play around with list operators until we agree upon something
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
dri
Let's avoid mixing sealing the hardware commands for the request and
adding the request to the software tracking.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_request.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties
We need finer control over wakeup behaviour during i915_wait_request(),
so expand the current bool interruptible to a bitmask.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers
Currently the presumption is that the request construction and its
submission to the GuC are all under the same holding of struct_mutex. We
wish to relax this to separate the request construction and the later
submission to the GuC. This requires us to reserve some space in the
GuC command queue fo
Now that we have fences in place to drive request submission, we can
employ those to queue requests after their dependencies as opposed to
stalling in the middle of an execbuf ioctl. (However, we still choose to
spin before enabling the IRQ as that is faster - though contentious.)
v2: Do the fence
Since we have a cooperative mode now with a direct reset, we can avoid
the contention on struct_mutex and instead try then sleep on the
I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is
cleared, all is fine. Otherwise, we sleep for a bit and try again. In
the worst case we sleep for
Drive final request submission from a callback from the fence. This way
the request is queued until all dependencies are resolved, at which
point it is handed to the backend for queueing to hardware. At this
point, no dependencies are set on the request, so the callback is
immediate.
A side-effect
Just rearrange the code to reduce churn in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 76
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
Update reset path in preparation for engine reset which requires
identification of incomplete requests and associated context and fixing
their state so that engine can resume correctly after reset.
The request that caused the hang will be skipped and head is reset to the
start of breadcrumb. This
Now that we can wait upon fences before emitting the request, it becomes
trivial to wait upon any implicit fence provided by the dma-buf
reservation object.
Testcase: igt/prime_vgem/fence-wait
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/d
We are about to specialize object synchronisation to enable nonblocking
execbuf submission. First we make a copy of the current object
synchronisation for execbuffer. The general i915_gem_object_sync() will
be removed following the removal of CS flips in the near future.
Signed-off-by: Chris Wilso
If a waiter is holding the struct_mutex, then the reset worker cannot
reset the GPU until the waiter returns. We do not want to return -EAGAIN
form i915_wait_request as that breaks delicate operations like
i915_vma_unbind() which often cannot be restarted easily, and returning
-EIO is just as usele
On Mon, 29 Aug 2016, Meelis Roos wrote:
> Tried 4.8-rc4 on my i5-2400 PC, got this warning:
Fixed in drm-intel-fixes by
commit fc2780b66b15092ac68272644a522c1624c48547
Author: Chris Wilson
Date: Fri Aug 26 11:59:26 2016 +0100
drm/i915: Add GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase
On Wed, Aug 31, 2016 at 01:46:03PM +0530, Nautiyal Ankit wrote:
> From: aknautiy
>
> Idleness DRRS:
> By default the DRRS state will be at DRRS_HIGH_RR. When a Display
> content is Idle for more than 1Sec Idleness will be declared and
> DRRS_LOW_RR will be invoked, changing the
On 07/09/16 14:52, kbuild test robot wrote:
Hi Tom,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160907]
[cannot apply to v4.8-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git
On Tue, 06 Sep 2016, li...@eikelenboom.it wrote:
> On 2016-09-06 11:25, Jani Nikula wrote:
>> On Tue, 06 Sep 2016, li...@eikelenboom.it wrote:
>>> L.S.,
>>>
>>> Since one of the last 4.8 RC's i'm getting the warning below when
>>> booting on my sandybridge based thinkpad.
>>> From what it seems t
Hi Jani,
2016-09-07 17:34 GMT+09:00 Jani Nikula :
> On Wed, 07 Sep 2016, Masahiro Yamada wrote:
>> Remove unneeded variables and assignments.
>>
>> Signed-off-by: Masahiro Yamada
>
> ...
>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 95ddd56..59
From: Akash Goel
This patch provides a test utility which helps capture GuC firmware logs and
then dump them to file.
The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and
stored into a file '/tmp/guc_log_dump.dat', the name of the output file can
be changed through a comman
> -Original Message-
> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> Sent: Tuesday, September 06, 2016 7:04 PM
> To: David Airlie; dri-de...@lists.freedesktop.org
> Cc: Masahiro Yamada; Gustavo Padovan; Yakir Yang; Huang, Ray; Deucher,
> Alexander; Liu, Monk; Zhou, David(Ch
On 07/09/16 16:27, akash.g...@intel.com wrote:
From: Akash Goel
This patch provides a test utility which helps capture GuC firmware logs and
then dump them to file.
The logs are pulled from a debugfs file '/sys/kernel/debug/dri/guc_log' and
stored into a file '/tmp/guc_log_dump.dat', the name
== Series Details ==
Series: series starting with [01/21] drm/i915: Add a sw fence for collecting up
dma fences (rev22)
URL : https://patchwork.freedesktop.org/series/12007/
State : warning
== Summary ==
Series 12007v22 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/seri
On 06/09/16 21:36, Nicolas Iooss wrote:
On 06/09/16 12:21, Dave Gordon wrote:
On 04/09/16 19:58, Nicolas Iooss wrote:
When building the kernel with clang and some warning flags, the compiler
reports that the return value of dcs_get_backlight() may be
uninitialized:
drivers/gpu/drm/i915/int
My only thought is that it seems like we prefix functions skl_, kbl_,
etc. just to indicate which generation introduced the feature. Skl uses
quite a few sandybridge and haswell functions. If this is a little
closer to what most intel devs would expect the naming to be though
then:
Reviewed-by: Ly
On Tue, Sep 06, 2016 at 09:52:14PM -0300, Paulo Zanoni wrote:
> According to BSpec, it's the "core CPUs" that need the code, which
> means SKL and KBL, but not BXT.
>
> I don't have a KBL to test this patch on it.
IIRC bspec doesn't specify the sagv latency for anything but
SKL, and the relevant
On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> And use it to move knowledge about the SAGV-supporting platforms from
> the callers to the SAGV code.
>
> We'll add more platforms to intel_has_sagv(), so IMHO it makes more
> sense to move all this to a single function instead of patching a
I'm not sure that kbl has this either. The kbl machine I've been
working with thus-far has passed a few modesetting stress tests with
the chameleon, and I don't have anything trying to control sagv stuff
on it.
This being said though the sagv for skylake did happen to get added
right before releas
On Wed, Sep 07, 2016 at 01:53:31PM +0300, Mika Kahola wrote:
> On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote:
> > From: Jim Bride
> >
> > Add upfront link training to intel_dp_mst_mode_valid() so that we
> > know
> > topology constraints before we validate the legality of modes to be
> >
On Wed, Sep 07, 2016 at 12:47:49PM +0300, Mika Kahola wrote:
> On Tue, 2016-09-06 at 17:13 -0700, Manasi Navare wrote:
> > According to the DisplayPort Spec, in case of Clock Recovery failure
> > the link training sequence should fall back to the lower link rate
> > followed by lower lane count unt
1 - 100 of 141 matches
Mail list logo
