On ke, 2016-09-07 at 15:45 +0100, Chris Wilson wrote:
> 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
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Techn
On 08/09/16 02:23 AM, Imre Deak wrote:
> This fixes the error path for platforms that don't define the new
> page_flip_target() hook.
>
> Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2")
> Testcase: igt/kms_flip/basic-flip-vs-dpms
> CC: Michel Dänzer
> Signed-off-by: Imre Deak
> ---
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:
9909113cc48a ("drm/i915/gen9: Only copy WM results for changed pipes to
skl_hw")
from Linus' tree and commits:
2722efb90b34 ("drm/i915/gen9: Only copy WM results fo
== Series Details ==
Series: Revert "drm/i915/psr: Make idle_frames sensible again"
URL : https://patchwork.freedesktop.org/series/12148/
State : warning
== Summary ==
Series 12148v1 Revert "drm/i915/psr: Make idle_frames sensible again"
http://patchwork.freedesktop.org/api/1.0/series/12148/re
This reverts commit 1c80c25fb622973dd135878e98d172be20859049.
There are panels that needs 4 idle frames before entering PSR,
but VBT is unproperly set.
Also lately it was identified that idle frame count calculated at HW
can be off by 1, what makes the minimum of 2, at least.
Without the current
On Wed, 2016-09-07 at 15:37 +0300, Jani Nikula wrote:
> 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 wh
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 EQ.
In case of Channel EQ failures, it should fallback to
lower l
On Wed, 2016-08-31 at 18:09 +0200, Daniel Vetter wrote:
> Now that there's less stuff in there I noticed that I overlooked
> them.
> Sprinkle some docs over them while at it.
>
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_connector.h | 24 ++--
> include/drm/drm_c
For patches 6-8:
Reviewed-by: Lyude
On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> Hi
>
> This series is the result of me comparing the code against BSpec. It
> doesn't solve any particular problem I was seeing, but there's enough
> changes that this code could potentially change the
On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> During watermarks calculations, this value is used in 3 different
> places. Only one of them was not using a hardcoded 4. Move the code
> up
> so everybody can benefit from the actual value.
>
> This should only help on situations with Y til
On 07/09/16 18:03, Dave Gordon wrote:
> 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_backl
Reviewed-by: Rodrigo Vivi
On Wed, Aug 17, 2016 at 12:30:39PM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>
Reviewed-by: Rodrigo Vivi
On Wed, Aug 17, 2016 at 12:30:40PM -0700, Carlos Santa wrote:
> Remove runtime PM support for SNB as it breaks hotplug support.
> Feedback from V. Syrjala.
>
> Signed-off-by: Carlos Santa
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Rodrigo Vivi
On Wed, Aug 17, 2016 at 12:30:45PM -0700, Carlos Santa wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>
Reviewed-by: Rodrigo Vivi
On Wed, Aug 17, 2016 at 12:30:41PM -0700, Carlos Santa wrote:
> No need for HAS_CORE_RING_FREQ as that flag is actually the same as
> .has_llc. Feedback from V. Syrjala.
>
> Signed-off-by: Carlos Santa
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gp
From: Jim Bride
Add the PLL selection code for HSW/BDW/BXT/SKL into a stand-alone function
in order to allow for the implementation of a platform neutral upfront
link training function.
v4:
* Removed dereferencing NULL pointer in case of failure (Dhinakaran Pandiyan)
v3:
* Add Hooks for all DDI
On Fri, Sep 02, 2016 at 01:06:32PM -0700, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote:
> > From: Jim Bride
> >
> > Add the PLL selection code for HSW/BDW/BXT/SKL into a stand-alone function
> > in order to allow for the implementation of a platform neutral
On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote:
> Respect max TMDS clock frequency from DPCD for active
> DP to HDMI adapters.
>
> Signed-off-by: Mika Kahola
Reviewed-by: Jim Bride
> ---
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_hdmi.c | 27 ++
On Wed, Aug 17, 2016 at 01:49:48PM +0300, Mika Kahola wrote:
> Read DisplayPort branch device info from through debugfs
> interface.
>
> v2: use drm_dp_helper routines to collect data
> v3: cleanup to match the drm_dp_helper.c patches introduced
> earlier in this series
> v4: move DP branch de
On Wed, Aug 17, 2016 at 01:49:47PM +0300, Mika Kahola wrote:
> DisplayPort branch device may define max supported bits per
> component. Update display info based on this value if bpc
> is defined.
>
> v2: cleanup to match the drm_dp_helper.c patches introduced
> earlier in this series
> v3: Fi
On Wed, Aug 17, 2016 at 01:49:45PM +0300, Mika Kahola wrote:
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
>
> The regist
On Wed, Aug 17, 2016 at 01:49:44PM +0300, Mika Kahola wrote:
> SW revision is mandatory field for DisplayPort branch
> devices. This is defined in DPCD register field 0x50A.
To be precise, the revision info is in 0x50A and 0x50B. Since
both the major and minor versions are called out separately
in
On 2016-09-07 16:49, Jani Nikula wrote:
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.
On Wed, Aug 17, 2016 at 01:49:43PM +0300, Mika Kahola wrote:
> HW revision is mandatory field for DisplayPort branch
> devices. This is defined in DPCD register field 0x509.
>
> v2: move drm_dp_ds_revision structure to be part of
> drm_dp_link structure (Daniel)
> v3: remove dependency to drm_
On Wed, Aug 17, 2016 at 01:49:42PM +0300, Mika Kahola wrote:
> Let's remove reference to "struct intel_connector *connector"
> in intel_dp_aux_init() function as it is no longer required.
>
> Signed-off-by: Mika Kahola
Reviewed-by: Jim Bride
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4 ++--
>
From: Dhinakaran Pandiyan
Wrap the max. vswing check in a separate function.
This makes the clock recovery phase of DP link training cleaner
v3:
Fixed the paranthesis warning (Mika Kahola)
v2:
Fixed the Compiler warning (Mika Kahola)
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Manasi Nav
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 additional non
compliant retries. This function now returns a boolean val
From: Durgadoss R
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes, the
type-C cable may limit the bandwidth even if Panel can support
more lanes.
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 EQ.
In case of Channel EQ failures, it should fallback to
lower l
== Series Details ==
Series: drm: two more (drm_)printk() wrapper macros (fixup)
URL : https://patchwork.freedesktop.org/series/12130/
State : failure
== Summary ==
Series 12130v1 drm: two more (drm_)printk() wrapper macros (fixup)
http://patchwork.freedesktop.org/api/1.0/series/12130/revision
Of course, this also re-enables GuC loading and submission
by default on suitable platforms, since it's Intel's Plan
of Record that GuC submission shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 10 +-
1 file changed, 5 insertions(+), 5
Previously the code allowed *any* values for the enable_guc_loading and
enable_guc_submission parameters, and forced them into range by clipping
at each extremum. This version instead ignores unknown values, treating
them as DEFAULT (which then gets converted to DISABLED or PREFERRED).
Of course w
The existing code that accesses the "enable_guc_loading"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean
0/1 mapping to specific values (which could be confusing
for maintainers).
So this patch just provides and uses names for the v
There are various literal constants used in the GuC module-parameter
processing code; this sequence of patches replaces them with symbolic
names for greater clarity.
And then it re-enables GuC submission by default
v3:
Original patch broken into two (1/4 + 2/4)
Name for GuC log level NONE ad
The existing code that accesses the "guc_log_level" parameter
uses an explicit numerical value for the "no logging" case,
whereas there are symbolic names for the other levels.
So this patch just provides and uses a name for the default log
level (NONE), with the same numeric value that is already
The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean 0/1
mapping to specific values (which could be confusing for
maintainers).
So this patch just provides and uses names for the
== Series Details ==
Series: drm: Fix error path in drm_mode_page_flip_ioctl()
URL : https://patchwork.freedesktop.org/series/12129/
State : failure
== Summary ==
Series 12129v1 drm: Fix error path in drm_mode_page_flip_ioctl()
http://patchwork.freedesktop.org/api/1.0/series/12129/revisions/1/
On 26/08/16 20:55, Chris Wilson wrote:
On Fri, Aug 26, 2016 at 08:46:25PM +0100, Dave Gordon wrote:
@@ -1520,6 +1528,14 @@ static void eb_export_fence(struct drm_i915_gem_object
*obj,
if (ret)
return ret;
+ if (instp_mode != I915_EXEC_CONSTANTS_REL_GENERAL) {
+
Between v2 and v3 of this patch,
c4e68a583202 ("drm: Introduce DRM_DEV_* log messages")
was introduced upstream, and this was the reason for the rewrite as v3.
Unfortunately a maintainer pushed the earlier version to drm-intel-next
30b0da8d556e ("drm: extra printk() wrapper macros")
creating a
This fixes the error path for platforms that don't define the new
page_flip_target() hook.
Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2")
Testcase: igt/kms_flip/basic-flip-vs-dpms
CC: Michel Dänzer
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1
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
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
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
> >
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 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
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
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 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
== 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 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
> -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
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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:
>> >
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 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
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) >
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
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
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
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
== 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/
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
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
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
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 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
== 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/
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
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
+++
1 - 100 of 141 matches
Mail list logo
