On Fri, Jun 30, 2017 at 05:40:58PM +0530, Mahesh Kumar wrote:
> Gen9+ Interlace fetch mode doesn't support few plane configurations & pipe
> scaling.
> - Y-tile
> - 90/270 rotation
> - pipe/plane scaling
> - 420 planar formats
Do we have igt testcases that try to exercise all this? When fixin
Hi all,
2nd round of 4.14 features:
- prep for deferred fbdev setup
- refactor fixed 16.16 computations and skl+ wm code (Mahesh Kumar)
- more cnl paches (Rodrigo, Imre et al)
- tighten context cleanup and handling (Chris Wilson)
- fix interlaced handling on skl+ (Mahesh Kumar)
- small bits as us
On Mon, Jul 17, 2017 at 12:28:00PM +0800, Hailin Gu wrote:
> Hi~ all,
>
> Does the test program have any hardware or version limitations?
>
>
> I found that most testcase could run on a machine with intel(R) Core(TM)
> i7-2600K CPU @ 3.40GHz.
>
> But can't run on Intel(R) Xeon(R) CPU E5-2699 v3
On Mon, Jul 17, 2017 at 11:14:03AM +0300, Arkadiusz Hiler wrote:
> On Mon, Jul 17, 2017 at 12:28:00PM +0800, Hailin Gu wrote:
> > Hi~ all,
> >
> > Does the test program have any hardware or version limitations?
> >
> >
> > I found that most testcase could run on a machine with intel(R) Core(TM)
On Thu, Jul 06, 2017 at 10:29:41AM -0700, Michel Thierry wrote:
> On 06/07/17 04:12, Arkadiusz Hiler wrote:
> > On Tue, Jun 20, 2017 at 11:25:02AM -0700, Michel Thierry wrote:
> > > Platforms with per-engine reset enabled (i915.reset=2) are unlikely to
> > > perform a full chip reset, keeping the r
In the next patch we will want to reinsert a request not at the end of
the priority queue, but at the front. Here we split insert_request()
into two, the first function retrieves the priority list (for reuse for
unsubmit later) and a wrapper function to insert at the end of that list
and to schedul
Move insert_request() earlier to avoid a forward declaration in a later
patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 128 +++
1 file changed, 64 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/driver
When we write to ELSP, it triggers a context preemption at the earliest
arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
operations and the explicit MI_ARB_CHECK). If this is to the same
context, it triggers a LITE_RESTORE where the RING_TAIL is merely
updated (used currently to chain
With preemption, we will want to "unsubmit" a request, taking it back
from the hw and returning it to the priority sorted execution list. In
order to know where to insert it into that list, we need to remember
its adjust priority (which may change even as it was being executed).
Signed-off-by: Chr
== Series Details ==
Series: series starting with [RFC,1/4] drm/i915/execlists: Move insert_request()
URL : https://patchwork.freedesktop.org/series/27382/
State : success
== Summary ==
Series 27382v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27382/revisions/
On Fri, Jul 14, 2017 at 06:04:03PM -0700, Matthias Kaehlcke wrote:
> The current code uses two different enum types for PCH transcoders and
> performs implicit conversions between the two types. This is error prone
> and causes clang to raise warnings like this:
>
> drivers/gpu/drm/i915/intel_dp.c
On 14/07/17 19:21, Matthew Auld wrote:
On 14 July 2017 at 18:57, Lionel Landwerlin
wrote:
On 14/07/17 18:09, Matthew Auld wrote:
On 13 July 2017 at 12:16, Lionel Landwerlin
wrote:
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without per
Triggering a GPU reset for one engine affects another, notably
corrupting the context status buffer (CSB) effectively losing track of
inflight requests.
Adding a few printks:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ad41836fa5e5..a969456bc0fa 100644
---
Including a check against the execlist queue before calling the engine
idle and passing hangcheck.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_e
We should only ever do nop_submit_request when the machine is wedged, so
assert it is so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ca7a56ff3904..5517
After setting the WEDGED bit, make sure that we do wake up waiters as
they may not be waiting for a request completion yet, just for its
execution.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/d
When we wedge the device, we clear out the in-flight requests and
advance the breadcrumb to indicate they are complete. However, the
breadcrumb advance includes an assert that the engine is idle, so that
advancement needs to be the last step to ensure we pass our own sanity
checks.
Signed-off-by:
Before we declare an engine as idle, check if there are any pending
execlist context-switches and if the ring itself reports as idle.
Otherwise, we may be left in a situation where we miss a crucial
execlist event (or something more sinister) yet the requests complete.
Since the seqno write happens
When the GPU is reset, we want to discard all pending notifications as
either we have manually completed them, or they are no longer
applicable. Make sure we do reset the engine->irq_posted prior to
re-enabling the engine (e.g. the interrupt tasklets) in
i915_gem_reset_finish_engine().
Signed-off-
As part of the knowing whether there is outstanding data in the CSB,
also check whether there is an outstanding IRQ notification.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 --
1 file changed, 4 i
intel_engine_init_globa_seqno() may be called from an uncontrolled
set-wedged path where we have given up waiting for broken hw and declare
it defunct. Along that path, any sanity checks that the hw is idle
before we adjust its state will expectedly fail, so we simply cannot.
Instead of asserting i
We rely on disabling the execlists (by stopping the tasklet) to prevent
new requests from submitting to the engine ELSP before we are ready.
However, we re-enable the engine before we call init_hw which gives
userspace the opportunity to subit a new request which is then
overwritten by init_hw -- b
Although a banned context will be told to -EIO off if they try to submit
more requests, we have a discrepancy between whole device resets and
per-engine resets where we report the GPU reset but not the engine
resets. This leaves a bit of mystery as to why the context was banned,
and also reduces aw
When doing a GPU reset, the CSB register will be trashed and we will
lose any context-switch notifications that happened since the tasklet
was disabled. If we find that all requests on this engine were
completed, we want to make sure that the ELSP tracker is similarly empty
so that we do not feed b
Since we make call i915_gem_context_mark_guilty() concurrently when
resetting different engines in parallel, we need to make sure that our
updates are safe for the unlocked access.
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2
We try to fixup the context image after the reset to ensure that there
are no more pending writes from the hw that may conflict and to fixup
any that were in flight.
Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Tvr
If all goes well, resetting one engine should not affect the operation of
any others. So to test this, we setup a continuous stream of requests
onto to each of the "innocent" engines whilst constantly resetting our
target engine.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Op 15-07-17 om 11:31 schreef Daniel Vetter:
> The legacy plane->fb pointer is refcounted by calling
> drm_atomic_clean_old_fb().
>
> In practice this isn't a real problem because:
> - The caller in the i915 gpu reset code restores the original state
> again, which means the plane->fb pointer won'
Quoting Chris Wilson (2017-07-17 09:42:35)
> @@ -503,6 +500,49 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
> struct drm_i915_gem_request *rq, *rn;
>
> + if (once) {
>
On Mon, 17 Jul 2017, David Binderman wrote:
> Hello there,
Hello. No need to include LKML for stuff like this. But Cc'd the folks
from the broken commit.
> drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean
> expression with an integer other than 0 or 1.
>
> Source code is
Op 15-07-17 om 15:45 schreef Daniel Vetter:
> On Sat, Jul 15, 2017 at 3:23 PM, Daniel Vetter wrote:
>> On Sat, Jul 15, 2017 at 2:00 PM, Patchwork
>> wrote:
>>> == Series Details ==
>>>
>>> Series: RFC: duct-tape for the gpu reset vs. modeset deadlock
>>> URL : https://patchwork.freedesktop.org/
Hi,
On Monday 17 July 2017 03:22 PM, Jani Nikula wrote:
On Mon, 17 Jul 2017, David Binderman wrote:
Hello there,
Hello. No need to include LKML for stuff like this. But Cc'd the folks
from the broken commit.
drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean
expressi
Hi~ Hiler
Thank for your reply.
I'm sorry for didn't notice the integradted graphics.
But there is still some cases could not pass and shown requirement not met,
running on i7-4770.
I wonder if these skiped cases only about the cpu? So different processor must
have different test result.
Or can
Op 17-07-17 om 12:32 schreef Mahesh Kumar:
> Hi,
>
>
> On Monday 17 July 2017 03:22 PM, Jani Nikula wrote:
>> On Mon, 17 Jul 2017, David Binderman wrote:
>>> Hello there,
>> Hello. No need to include LKML for stuff like this. But Cc'd the folks
>> from the broken commit.
>>
>>> drivers/gpu/drm/i91
Hi,
On Monday 17 July 2017 04:01 PM, Maarten Lankhorst wrote:
Op 17-07-17 om 12:32 schreef Mahesh Kumar:
Hi,
On Monday 17 July 2017 03:22 PM, Jani Nikula wrote:
On Mon, 17 Jul 2017, David Binderman wrote:
Hello there,
Hello. No need to include LKML for stuff like this. But Cc'd the folks
On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote:
> A more complete solution would be to do the mutex_init in the drm core
> only for legacy drivers, plus add it to each modern driver that still
> needs it, which would also give each its own lockdep key. Trying to do
> that dynamically
Hi,
> No need of flag here. If vGPU driver is not loaded in the guest,
> there
> is no surface being managed by vGPU, in that case this size will be
> zero.
Ok, we certainly have the same situation with intel. When the guest
driver is not loaded (yet) there is no valid surface.
We should clea
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same
as ddb_allocation >= blocks_per_line, so use the latter to simplify
this.
This fixes the following compiler warning:
drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a
boolean expression with an integer other than 0
On Fri, Jul 14, 2017 at 03:28:47PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Fix error checking/locking in
> perf/lookup_context()
> URL : https://patchwork.freedesktop.org/series/27309/
> State : success
I pushed both patches to -dinq, tha
On Wed, Jun 01, 2016 at 06:04:40PM +0100, Chris Wilson wrote:
> On Wed, Jun 01, 2016 at 05:01:13PM +0100, Damien Lespiau wrote:
> > We exit early if has_aliasing_ppgtt is 0, so towards the end of the
> > function has_aliasing_ppgtt can only be 1.
> >
> > Also:
> >
> > if (foo)
> >
Reviewed-by: Mahesh Kumar
On Monday 17 July 2017 04:43 PM, Maarten Lankhorst wrote:
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same
as ddb_allocation >= blocks_per_line, so use the latter to simplify
this.
This fixes the following compiler warning:
drivers/gpu/drm/i915/in
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same
as ddb_allocation >= blocks_per_line, so use the latter to simplify
this.
This fixes the following compiler warning:
drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a
boolean expression with an integer other than 0
Daniel Vetter writes:
> i915 needs this.
>
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 38
> +
> include/drm/drm_atomic_helper.h | 1 +
> 2 files changed, 39 insertions(+)
>
== Series Details ==
Series: drm/i915: Fix bad comparison in skl_compute_plane_wm. (rev2)
URL : https://patchwork.freedesktop.org/series/27395/
State : success
== Summary ==
Series 27395v2 drm/i915: Fix bad comparison in skl_compute_plane_wm.
https://patchwork.freedesktop.org/api/1.0/series/27
Quoting Chris Wilson (2017-07-17 10:46:23)
> Quoting Chris Wilson (2017-07-17 09:42:35)
> > @@ -503,6 +500,49 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> > struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
> > struct drm_i915_gem_r
On Mon, Jul 17, 2017 at 12:30:30PM +0200, Gu, HailinX wrote:
> Hi~ Hiler
> Thank for your reply.
> I'm sorry for didn't notice the integradted graphics.
> But there is still some cases could not pass and shown requirement not met,
> running on i7-4770.
> I wonder if these skiped cases only about
On Friday 14 July 2017 07:55 PM, Paulo Zanoni wrote:
Em Sex, 2017-07-14 às 19:25 +0530, Praveen Paneri escreveu:
Hi Paulo,
On Thursday 13 July 2017 02:31 AM, Paulo Zanoni wrote:
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
Now that we have support for Y-tiled buffers, add ano
From: Emil Velikov
Cc: Chris Wilson
Signed-off-by: Emil Velikov
---
src/legacy/i810/i810.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/legacy/i810/i810.h b/src/legacy/i810/i810.h
index de250ab8..347188c9 100644
--- a/src/legacy/i810/i810.h
+++ b/src/legacy/i810/i810.h
@@ -218,7 +218
Hi all,
Here is a v4 of this series. It is mostly prompted by one of Imre's
series [1] that attracted my attention at how we do locking in the
perf part of the driver.
I believe up to now it was fine due to the fact that we had all
configs always present in kernel space. With this series, configs
We were reserving fewer dwords in the ring than necessary. Indeed
we're always writing all registers once, so discard the actual number
of registers given by the user and just program the whitelisted ones
once.
Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+")
Reported-by: Matt
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
v3: Add some flex registers (Matthew)
Signed-off-by: Lionel Landwerlin
---
tests/perf.c | 207 +++
1 file
On Thu, Jul 06, 2017 at 05:14:18PM +0100, Liviu Dudau wrote:
> From: Brian Starkey
>
> Separate out the CRC code for better compartmentalisation. Should ease
> the addition of more/different CRC sources in the future.
>
> Signed-off-by: Brian Starkey
> Signed-off-by: Liviu Dudau
>
> ---
> li
The documentation was lying. The igt_crc_to_string() is threadsafe and
does not return a pointer to an internal buffer.
Actually the caller is responsible for the memory that is allocated (and
they are for all the current cases), so let's put that in the doc too.
While I was at it I got rid of st
== Series Details ==
Series: Add support for loadable OA configs
URL : https://patchwork.freedesktop.org/series/27403/
State : warning
== Summary ==
Series 27403v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27403/revisions/1/mbox/
Test gem_exec_flush:
This adds the connector name when printing a debug message about the DP
link training result. It is useful to figure out what connector is
failing when multiple DP connectors are used.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/i915/intel_dp_link_training.c | 10 ++
1 file chan
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.
It checks if the mode is YCBCR420 and source can support this
output then it marks the ycbc
This patch series is a subset of series "YCBCR 4:2:0 handling in DRM layer"
Published and reviewed here: https://patchwork.freedesktop.org/series/26973/
The original series had 14 patches, out of which first 8 (which were in DRM
layer) are reviewed merged. These 6 patches are the I915 layer handli
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
sc
When output colorspace is YCBCR420, we have to load the
corresponding colorspace in AVI infoframe. This patch fills
the colorspace of AVI infoframe as per the output mode.
V2: Rebase
V3: Rebase
V4: Rebase
V5: Added r-b from Ander
V6: Checking RGB/YCBCR420 output only (Ville)
V7: Add colorspace inf
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, which uses recommended bspec
values to perf
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
V4: Rebase
V5: Added r-b from A
== Series Details ==
Series: drm/i915: Explicit the connector name for DP link training result
URL : https://patchwork.freedesktop.org/series/27410/
State : success
== Summary ==
Series 27410v1 drm/i915: Explicit the connector name for DP link training result
https://patchwork.freedesktop.org/
On Mon, Jul 17, 2017 at 04:59:48PM +0300, Arkadiusz Hiler wrote:
> The documentation was lying. The igt_crc_to_string() is threadsafe and
> does not return a pointer to an internal buffer.
>
> Actually the caller is responsible for the memory that is allocated (and
> they are for all the current c
On Mon, Jul 17, 2017 at 04:50:27PM +0300, Arkadiusz Hiler wrote:
> On Thu, Jul 06, 2017 at 05:14:18PM +0100, Liviu Dudau wrote:
> > From: Brian Starkey
> >
> > Separate out the CRC code for better compartmentalisation. Should ease
> > the addition of more/different CRC sources in the future.
> >
On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra wrote:
> On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote:
>> A more complete solution would be to do the mutex_init in the drm core
>> only for legacy drivers, plus add it to each modern driver that still
>> needs it, which would also
== Series Details ==
Series: YCBCR 4:2:0 handling in i915 layer
URL : https://patchwork.freedesktop.org/series/27412/
State : success
== Summary ==
Series 27412v1 YCBCR 4:2:0 handling in i915 layer
https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/1/mbox/
Test gem_exec_suspend:
clenup -> cleanup
On 17/07/17 18:05, Liviu Dudau wrote:
On Mon, Jul 17, 2017 at 04:59:48PM +0300, Arkadiusz Hiler wrote:
The documentation was lying. The igt_crc_to_string() is threadsafe and
does not return a pointer to an internal buffer.
Actually the caller is responsible for the memory tha
On Mon, Jul 17, 2017 at 11:39:56AM +0200, Maarten Lankhorst wrote:
> Op 15-07-17 om 11:31 schreef Daniel Vetter:
> > The legacy plane->fb pointer is refcounted by calling
> > drm_atomic_clean_old_fb().
> >
> > In practice this isn't a real problem because:
> > - The caller in the i915 gpu reset cod
Highlights:
- Bugs open during the week: 17
- Bugs closed during the week: 8
- Bugs labeled ReadyForDev during the week: 9
- Total bugs remain open: 327
- Total bugs labeled ReadyForDev: 130
Details:
- Bugs open during the week(priority): 17
+-
Link to FDO regression list:
https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=DRM%2FIntel&f0=OP&f1=OP&f2=short_desc&f3=keywords&f4=CP&f5=CP&j1=OR&known_name=i915%20regressions&list_id=600614&o2=anywordssubstr&o3=anywordss
On Mon, Jul 17, 2017 at 05:06:42PM +0200, Daniel Vetter wrote:
> On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra wrote:
> > On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote:
> >> A more complete solution would be to do the mutex_init in the drm core
> >> only for legacy drivers, plus
On Wed, 2017-07-12 at 17:50 +0300, Paul Kocialkowski wrote:
> This introduces CRC calculation for reference frames, instead of
> using
> hardcoded values for them. The rendering of reference frames may
> differ
> from machine to machine, especially due to font rendering, and the
> frame itself may
The only thing that needs changing is the thing I mentioned on patch
#2. After you make sure exiting prematurely doesn't cause the rest of
IGT to segfault or something like that, that should hopefully be the
last change that will need to be done. Afterwards I will push the whole
series at once.
Th
Op 15-07-17 om 13:40 schreef Daniel Vetter:
> Taking the modeset locks unconditionally isn't the greatest idea,
> because atm that part is still broken and times out (and then atomic
> keels over). And there's really no reason to do so, the old code
> didn't do that either.
>
> To make the patch a
El Mon, Jul 17, 2017 at 11:07:01AM +0200 Daniel Vetter ha dit:
> On Fri, Jul 14, 2017 at 06:04:03PM -0700, Matthias Kaehlcke wrote:
> > The current code uses two different enum types for PCH transcoders and
> > performs implicit conversions between the two types. This is error prone
> > and causes
Just one change for this patch below
On Wed, 2017-07-12 at 17:57 +0300, Paul Kocialkowski wrote:
> This adds support for VGA frame comparison testing with the reference
> generated from cairo. The retrieved frame from the chamelium is first
> cropped, as it contains the blanking intervals, through
Hey! The only changes I need on this is the small fix I mentioned for
patch #2, and a nitpick regarding the spellings being used for the
functions. I wasn't sure whether or not we should be using analog or
analogue (us spelling vs. everyone else) but apparently the answer is
to use the US spellings
The current code uses in some instances enum transcoder for PCH
transcoders and enum pipe in others. This is error prone and clang
raises warnings like this:
drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
from enumeration type 'enum pipe' to different enumeration type
'e
For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
Use the correct table.
The error was pointed out by this clang warning:
drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
[-Wunneeded-interna
Looks like a typo in
cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.")
but Cc'ing Rodrigo, Clint to make sure this wasn't a workaround.
-DK
On Mon, 2017-07-17 at 11:21 -0700, Matthias Kaehlcke wrote:
> For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
> Use th
This makes sense, it should have returned the edp ddi buf translation
table as per the Bspec.
Please add this to the commit message:
Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
After that,
Reviewed-by: Manasi Navare
Manasi
On Mon, Jul 17, 2017 at 11:21:27AM -0700, M
Ok, there must be a problem, sent 5 messages to the list with clear details
on how the intel driver is failing for me, got one answer from Chris which
sadly was a bit too short to give me a good hint of what I should try next
or what further debugging I should give to help fix/improve the driver, a
== Series Details ==
Series: drm/i915: Return correct EDP voltage swing table for 0.85V
URL : https://patchwork.freedesktop.org/series/27426/
State : success
== Summary ==
Series 27426v1 drm/i915: Return correct EDP voltage swing table for 0.85V
https://patchwork.freedesktop.org/api/1.0/series
For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
Use the correct table.
The error was pointed out by this clang warning:
drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
[-Wunneeded-interna
== Series Details ==
Series: drm/i915: Return correct EDP voltage swing table for 0.85V (rev2)
URL : https://patchwork.freedesktop.org/series/27426/
State : success
== Summary ==
Series 27426v2 drm/i915: Return correct EDP voltage swing table for 0.85V
https://patchwork.freedesktop.org/api/1.0
Marc, please file a bug on freedesktop.org.
We expect the modesetting driver to work well and if it's not, it should have a
bug associated with it.
Sorry for your frustration.
On 17-07-17 12:22:00, Marc MERLIN wrote:
Ok, there must be a problem, sent 5 messages to the list with clear details
o
On Mon, 2017-07-17 at 18:55 +, Pandiyan, Dhinakaran wrote:
> Looks like a typo in
>
> cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.")
>
> but Cc'ing Rodrigo, Clint to make sure this wasn't a workaround.
>
> -DK
Checked with Clint, this wasn't a workaround, a typo indeed.
On Mon, Jul 17, 2017 at 08:59:18PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Mon, 2017-07-17 at 18:55 +, Pandiyan, Dhinakaran wrote:
> > Looks like a typo in
> >
> > cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.")
> >
> > but Cc'ing Rodrigo, Clint to make sure this wasn't
On Mon, Jul 17, 2017 at 01:55:36PM -0700, Ben Widawsky wrote:
> Marc, please file a bug on freedesktop.org.
>
> We expect the modesetting driver to work well and if it's not, it should
> have a bug associated with it.
Thanks, done:
https://bugs.freedesktop.org/show_bug.cgi?id=101825
Hopefully I
On 17/07/17 02:11, Chris Wilson wrote:
We rely on disabling the execlists (by stopping the tasklet) to prevent
new requests from submitting to the engine ELSP before we are ready.
However, we re-enable the engine before we call init_hw which gives
userspace the opportunity to subit a new request
The condition for setting the Loadgen Select bit of
PORT_TX_DW4 register during DDI Vswing Sequence should be
Bit rate <=6 GHz whereas the existing code checks only
Bit Rate < 6GHz. This patch fixes this condition.
While at it also remove the redundant paranthesis.
Fixes: cf54ca8bc567 ("drm/i915/c
On 17/07/17 02:11, Chris Wilson wrote:
When the GPU is reset, we want to discard all pending notifications as
either we have manually completed them, or they are no longer
applicable. Make sure we do reset the engine->irq_posted prior to
re-enabling the engine (e.g. the interrupt tasklets) in
i91
== Series Details ==
Series: drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence
URL : https://patchwork.freedesktop.org/series/27446/
State : success
== Summary ==
Series 27446v1 drm/i915/cnl: Fix loadgen select programming on ddi vswing
sequence
https://patchwork.freedesktop
On 17/07/17 02:11, Chris Wilson wrote:
Before we declare an engine as idle, check if there are any pending
execlist context-switches and if the ring itself reports as idle.
Otherwise, we may be left in a situation where we miss a crucial
execlist event (or something more sinister) yet the request
On 17/07/17 02:11, Chris Wilson wrote:
Triggering a GPU reset for one engine affects another, notably
corrupting the context status buffer (CSB) effectively losing track of
inflight requests.
Adding a few printks:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
ind
On 17/07/17 02:11, Chris Wilson wrote:
We should only ever do nop_submit_request when the machine is wedged, so
assert it is so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/d
On 17/07/17 02:11, Chris Wilson wrote:
Although a banned context will be told to -EIO off if they try to submit
more requests, we have a discrepancy between whole device resets and
per-engine resets where we report the GPU reset but not the engine
resets. This leaves a bit of mystery as to why th
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
b6dcaaac4474 ("drm/vblank: _ioctl posfix for ioctl handler")
interacting with commit
d5288c88c67c ("switch compat_drm_wait_vblank() to drm_ioctl_kernel()")
from Linu
1 - 100 of 103 matches
Mail list logo
