Op 13-06-16 om 16:45 schreef Daniel Vetter:
> On Thu, Jun 09, 2016 at 01:36:50PM +0200, Maarten Lankhorst wrote:
>> This will make it more likely that intermediary watermarks cause fifo
>> underruns, which is useful when writing watermark specific tests,
>> to make it more likely to trigger FIFO un
== Series Details ==
Series: drm/i915: Fix missing unlock on error in i915_ppgtt_info()
URL : https://patchwork.freedesktop.org/series/8657/
State : warning
== Summary ==
Series 8657v1 drm/i915: Fix missing unlock on error in i915_ppgtt_info()
http://patchwork.freedesktop.org/api/1.0/series/86
On Mon, Jun 13, 2016 at 11:42:00PM +, weiyj...@163.com wrote:
> From: Wei Yongjun
>
> Add the missing unlock before return from function i915_ppgtt_info()
> in the error handling case.
>
> Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex)
> Signed-off-by: Wei Yongjun
Appli
== Series Details ==
Series: drm/i915/skl: Increase cursor ddb blocks in multi-pipe config
URL : https://patchwork.freedesktop.org/series/8656/
State : failure
== Summary ==
Series 8656v1 drm/i915/skl: Increase cursor ddb blocks in multi-pipe config
http://patchwork.freedesktop.org/api/1.0/ser
== Series Details ==
Series: drm/i915/guc: updates to GuC doorbell handling (rev2)
URL : https://patchwork.freedesktop.org/series/8553/
State : failure
== Summary ==
Series 8553v2 drm/i915/guc: updates to GuC doorbell handling
http://patchwork.freedesktop.org/api/1.0/series/8553/revisions/2/mb
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commit:
a5aac5ab876a ("drm/i915: Check VBT for port presence in addition to the strap
on VLV/CHV")
from the drm-intel-fixes tree and commit:
457c52d87e5d ("drm/i915: Only i
On Wed, 2016-06-08 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> PSR in CHV, unlike HSW, can get activated even if vblanks interrupts
> are
> enabled. But, the pipe is not expected to generate timings signals
> when PSR is active. Specifically, we do not get vblank interrupts in
> CHV
> if PSR becom
From: Wei Yongjun
Add the missing unlock before return from function i915_ppgtt_info()
in the error handling case.
Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex)
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2
The bspec suggests giving cursor planes a fixed allocation of 8
blocks when running in a multi-CRTC configuration. However we
have found that this small allocation can only accommodate level
0 watermarks on many platforms, which in turn prevents the
system from entering deeper sleep states. Let's
On Fri, Jun 03, 2016 at 06:34:33AM +0100, Arun Siluvery wrote:
> This mode allows to assign EUs to pools which can process work collectively.
> The command to enable this mode should be issued as part of context
> initialization.
>
> The pooled mode is global, once enabled it has to stay the same
This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.
There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
is snooped by doorbell hardware for writes from
These registers are not actually writable by the CPU; only the GuC can
actually program them. So let's not do writes that have no effect.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 5 -
1 file changed, 5 deletions(-)
diff --git a
During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at
this point. But then, the booted kernel is replaced by the hibernated
image, and this r
This version doesn't update the doorbell bitmap, as that will
be done when the selected doorbell is associated with a client.
The call is now slightly earlier, just on the general principle
that potentially-failing operations should be done as early as
possible, to eliminate late failures and simp
Various GuC (doorbell) related patches, some trivial. The bulk of the
changes are in [patch 5/7], but it's mostly just reorganisation of
existing code; and [patch 6/7] is just a followup to that, kept as a
separate change for reasons of clarity. The new functionality is
implemented in a single new
Just code movement, no actual change to the function. This is in
preparation for the next patch, which will reorganise all the other
doorbell code, but doesn't change this function. So let's shuffle it
down near its caller rather than leaving it mixed in with the setup
code. Unlike the doorbell man
Bitmap operators are overkill when touching only one bit.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i
To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.
v2: use kernel bitmap-printing format (%pb) rather than %x.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtk
On Mon, Jun 13, 2016 at 04:25:55PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Rather than looping through encoders to see which encoder types
> > are being driven by the pipe, add an output_types bit
On ma, 2016-06-13 at 14:23 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,RESEND,1/6] drm/i915/bxt: Wait for
> PHY1 GRC calibration synchronously
> URL : https://patchwork.freedesktop.org/series/8627/
> State : failure
>
> == Summary ==
>
> Series 8627v1 Se
This version doesn't update the doorbell bitmap, as that will
be done when the selected doorbell is associated with a client.
Also it's called a little earlier, just on the general principle
that potentially-failing operations should be done before those
that can't fail, to simplify error handling
On 13/06/16 16:59, Dave Gordon wrote:
On 13/06/16 11:53, Tvrtko Ursulin wrote:
On 13/06/16 11:25, Dave Gordon wrote:
On 13/06/16 10:48, Tvrtko Ursulin wrote:
On 10/06/16 17:51, Dave Gordon wrote:
This patch refactors the driver's handling and tracking of
doorbells, in
preparation for a lat
On 13/06/16 11:53, Tvrtko Ursulin wrote:
On 13/06/16 11:25, Dave Gordon wrote:
On 13/06/16 10:48, Tvrtko Ursulin wrote:
On 10/06/16 17:51, Dave Gordon wrote:
This patch refactors the driver's handling and tracking of
doorbells, in
preparation for a later one which will resolve a suspend-resu
On 13/06/16 16:42, Dave Gordon wrote:
On 11/06/16 06:50, Patchwork wrote:
== Series Details ==
Series: series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to
'dev' for static functions
URL : https://patchwork.freedesktop.org/series/8556/
State : warning
== Summary ==
Series 8556v1 S
On 07/06/2016 13:02, Maarten Lankhorst wrote:
Op 02-06-16 om 15:25 schreef Tvrtko Ursulin:
On 01/06/16 18:07, john.c.harri...@intel.com wrote:
From: John Harrison
The intended usage model for struct fence is that the signalled status
should be set on demand rather than polled. That is, there
On 11/06/16 06:50, Patchwork wrote:
== Series Details ==
Series: series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for
static functions
URL : https://patchwork.freedesktop.org/series/8556/
State : warning
== Summary ==
Series 8556v1 Series without cover letter
http://patch
On 13/06/16 10:28, Tvrtko Ursulin wrote:
On 10/06/16 18:35, Dave Gordon wrote:
More Coccinellery ...
Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)".
At this time, we've found 189 instances, and each replacement
saves one
On Mon, Jun 13, 2016 at 04:13:48PM +0200, Daniel Vetter wrote:
> Currently it's part of prepare_fb, still in the first phase of
> atomic_commit which might fail. Which means that we need to have some
> heuristics in cleanup_fb to figure out whether things failed, or
> whether we just clean up the o
Instead of looping until the first disconnected port is found,
now go through all possible connectors, drawing the sprite on
any connected display.
Signed-off-by: Jim Bride
---
demos/intel_sprite_on.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/demos/intel_sprite_on
On Thu, Jun 09, 2016 at 03:14:54PM -0700, Matt Roper wrote:
> When we sanitize our DDB and watermark info during the first atomic
> commit, we need to calculate the total data rate. Since we haven't
> explicitly added the planes for each CRTC to our atomic state, the total
> data rate calculation
On Thu, Jun 09, 2016 at 03:14:53PM -0700, Matt Roper wrote:
> intel_state->active_crtcs is usually only initialized when doing a
> modeset. During our first atomic commit after boot, we're effectively
> faking a modeset to sanitize the DDB/wm setup, so ensure that this field
> gets initialized bef
On Thu, Jun 09, 2016 at 01:36:50PM +0200, Maarten Lankhorst wrote:
> This will make it more likely that intermediary watermarks cause fifo
> underruns, which is useful when writing watermark specific tests,
> to make it more likely to trigger FIFO underruns in intermediary watermarks.
That's surpr
On Mon, 13 Jun 2016, Jani Nikula wrote:
> On Mon, 13 Jun 2016, Gerd Hoffmann wrote:
>> Signed-off-by: Gerd Hoffmann
>
> Reviewed-by: Jani Nikula
And pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
>
>
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 6 --
>> 1 file changed,
== Series Details ==
Series: series starting with [1/5] drm/i915: Signal drm events for atomic
URL : https://patchwork.freedesktop.org/series/8632/
State : failure
== Summary ==
Series 8632v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/8632/revisions/1/mbox
Tes
Dan Carpenter writes:
> It seems pretty clear that bitwise OR was intended here and not logical
> OR.
>
> Fixes: 6fc29133eafb ('drm/i915/gen9: Add WaDisableSkipCaching')
> Signed-off-by: Dan Carpenter
Pushed to drm-intel-next-queued. Thanks for patch.
-Mika
>
> diff --git a/drivers/gpu/drm/i9
Em Seg, 2016-06-13 às 13:47 +0200, Stefan Richter escreveu:
> On Jun 10 Paulo Zanoni wrote:
> >
> > Since my test machines don't produce FIFO underrun errors, I tested
> > this by
> > creating a debugfs file that just calls
> > intel_fbc_handle_fifo_underrun(). I'd
> > appreciate some Tested-by ta
On Wed, Jun 08, 2016 at 07:03:02PM +0200, Lukas Wunner wrote:
> On Wed, Jun 08, 2016 at 02:09:40PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> > > Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> > > superfluous because t
On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rather than looping through encoders to see which encoder types
> are being driven by the pipe, add an output_types bitmask into
> the crtc state and populate it prior to compute_config and du
== Series Details ==
Series: series starting with [v2,RESEND,1/6] drm/i915/bxt: Wait for PHY1 GRC
calibration synchronously
URL : https://patchwork.freedesktop.org/series/8627/
State : failure
== Summary ==
Series 8627v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/ser
On Fri, Jun 10, 2016 at 03:14:36PM +0530, Agrawal, Akshu wrote:
> On 6/8/2016 2:10 PM, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote:
> > > CHV pipe C hits underrun when we get -ve X values of cursor. To avoid
> > > this we crop the cursor image for by -ve X
On Wed, Jun 08, 2016 at 11:11:07AM +0100, Chris Wilson wrote:
> On Wed, Jun 08, 2016 at 12:02:01PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 03, 2016 at 05:55:44PM +0100, Chris Wilson wrote:
> > > Since we are not concerned with userspace racing itself with set-tiling
> > > (the order is indeterm
Simply split intel_atomic_commit in half and place the new
nonblocking commit helpers at the right spots.
NOTE: There's still trouble with obj->frontbuffer bits getting mangled
when pipelining atomic commits.
v2:
- Remove the check for nonblocking which returned -EINVAL.
- Do wait for requests in
Currently it's part of prepare_fb, still in the first phase of
atomic_commit which might fail. Which means that we need to have some
heuristics in cleanup_fb to figure out whether things failed, or
whether we just clean up the old fbs.
That's fragile, and worse, once we start pipelining commits ge
Note that I didn't start garbage collecting all the legacy flip code
yet, to make it easier to revert this. But there will be _lots_ of
code that can be removed once this is tested on all platforms.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2
Right now still all blocking, no worker anywhere to be seen.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a4eb
This is part of what atomic must implement. And it's also required
to be able to use the helper nonblocking support.
v2: Always send out the drm event, remove the planes_changed check.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 ++---
drivers/gpu/drm/i915
On 13/06/16 14:35, Gore, Tim wrote:
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
Sent: Monday, June 13, 2016 12:40 PM
To: Gore, Tim
Cc: intel-gfx@lists.freedesktop.o
Signed-off-by: Maarten Lankhorst
---
tests/kms_rmfb.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/tests/kms_rmfb.c b/tests/kms_rmfb.c
index a3fde9f43788..89aa323210dd 100644
--- a/tests/kms_rmfb.c
+++ b/tests/kms_rmfb.c
@@ -144,12 +144,9 @@ run_rmfb_test(struct rm
There are a lot of places where we do either
for_each_pipe {
igt_subtest_f(... "-pipe-C", pipe_name())
for_each_connected_output()
/* Run subtest */
}
or:
igt_subtest_f(...) {
for_each_pipe()
for_each_connected_output()
Op 08-06-16 om 16:52 schreef Ville Syrjälä:
> On Wed, Jun 08, 2016 at 04:47:48PM +0200, Maarten Lankhorst wrote:
>> Op 08-06-16 om 15:35 schreef Ville Syrjälä:
>>> On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote:
Op 08-06-16 om 15:12 schreef Ville Syrjälä:
> On Wed, Jun 0
These helpers will be needed by the next patch, so factor them out.
No functional change.
v2:
- Move the refcount==0 WARN to the new put helper. (Ville)
CC: Ville Syrjälä
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 33
So far we depended on the HW to dynamically power down unused PHYs and
so we enabled them manually once during driver loading/resuming. There
are indications however that we can achieve better power savings by
manual powering toggling. So make the PHY enabling/disabling to happen
on-demand whenever
Rename these remaining function prefixes to better align with the
corresponding SKL functions.
No functional change.
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c| 13 ++---
drivers/gpu/drm/i915/intel_display.c| 28 ++--
So far we configured a static lane latency optimization during driver
loading/resuming. The specification changed at one point and now this
configuration depends on the lane count, so move the configuration
to modeset time accordingly.
It's not clear when this lane configuration takes effect. The
We can check the power state of the PHY data and common lanes as
reported by the PHY. Do this in case we need to debug problems where the
PHY gets stuck in an unexpected state.
Note that I only check these when the lanes are expected to be powered
on purpose, since it's not clear at what point the
A follow-up patch moves the PHY enabling to the power well code where
enabling/disabling the PHYs will happen independently. Because of this
waiting for the GRC calibration in PHY1 asynchronously would need some
additional logic. Instead of adding that let's keep things simple for now
and wait sync
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Monday, June 13, 2016 12:40 PM
> To: Gore, Tim
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Ro.CI.BAT: wa
Regards
Shashank
On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The video DIP can be used with DP ports as well. So let's at least read
out the state, and disable all infoframes when disabling the port.
Otherwise we might get left with whatever the previous guy w
On Mon, Jun 13, 2016 at 02:12:46PM +0100, Tvrtko Ursulin wrote:
>
> On 13/06/16 13:52, Chris Wilson wrote:
> >On Mon, Jun 13, 2016 at 01:45:56PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 13/06/16 13:40, Chris Wilson wrote:
> >>>The idea behind relaxing the restriction for pread/pwrite was to handle
Don't add SOURCE_DIR to the path for gem_blt as if this
script is invocated on some other directory, the path to
gem_blt will be concatenated two times.
References: https://bugs.freedesktop.org/show_bug.cgi?id=88437
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
tests/drv_missed_irq_hang | 4
Also CC Daniel. I have got "Reviewed-by" and passed the ABAT tests. Is there
anything I should do before patches get picked?
Thanks,
Zhi.
> -Original Message-
> From: Wang, Zhi A
> Sent: Monday, June 13, 2016 4:17 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: ch...@chris-wilson.co.uk; L
On Mon, 13 Jun 2016, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f
Hi Chris:
As Joonas is on vacation, can you pick my patches? or if you have some
comments I can continue improving them.
Thanks,
Zhi.
> -Original Message-
> From: Wang, Zhi A
> Sent: Thursday, June 09, 2016 9:44 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: ch...@chris-wilson.co.uk;
Regards
Shashank
On 6/13/2016 5:57 PM, Ville Syrjälä wrote:
On Mon, Jun 13, 2016 at 05:39:47PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Now that the infoframe hooks are part of the intel_dig_port, we can us
On 13/06/16 13:52, Chris Wilson wrote:
On Mon, Jun 13, 2016 at 01:45:56PM +0100, Tvrtko Ursulin wrote:
On 13/06/16 13:40, Chris Wilson wrote:
The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the
== Series Details ==
Series: series starting with drm/i915: pwrite/pread do not require
obj->base.filp, just pages (rev3)
URL : https://patchwork.freedesktop.org/series/8528/
State : failure
== Summary ==
Applying: drm/i915: pwrite/pread do not require obj->base.filp, just pages
Applying: drm
== Series Details ==
Series: drm/i915: use #defines for qemu subsystem ids (rev2)
URL : https://patchwork.freedesktop.org/series/2918/
State : warning
== Summary ==
Series 2918v2 drm/i915: use #defines for qemu subsystem ids
http://patchwork.freedesktop.org/api/1.0/series/2918/revisions/2/mbox
Reviewed-by: Shashank Sharma
Regards
Shashank
On 6/13/2016 5:55 PM, Ville Syrjälä wrote:
On Mon, Jun 13, 2016 at 03:47:13PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
DP ports will also want to utilize the vi
On Mon, Jun 13, 2016 at 01:45:56PM +0100, Tvrtko Ursulin wrote:
>
> On 13/06/16 13:40, Chris Wilson wrote:
> >The idea behind relaxing the restriction for pread/pwrite was to handle
> >!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
> >that the object provide struct pages.
>
Ok, apart from this, looks good to me.
Reviewed-by: Shashank Sharma
Regards
Shashank
On 6/13/2016 5:54 PM, Ville Syrjälä wrote:
On Mon, Jun 13, 2016 at 03:36:19PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
D
Regards
Shashank
On 6/13/2016 5:54 PM, Ville Syrjälä wrote:
On Mon, Jun 13, 2016 at 01:40:50PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
has_infoframe is what tells us whether infoframes should be enabled, s
On 13/06/16 13:40, Chris Wilson wrote:
The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the object provide struct pages.
v2: Remove excess (). Note enough editing after copy'n'paste.
Signed-off-by
The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the object provide struct pages.
v2: Remove excess (). Note enough editing after copy'n'paste.
Signed-off-by: Chris Wilson
Cc: Ankitprasad Sharma
Cc
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f313b4d..3099390 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i9
== Series Details ==
Series: series starting with drm/i915: pwrite/pread do not require
obj->base.filp, just pages (rev2)
URL : https://patchwork.freedesktop.org/series/8528/
State : failure
== Summary ==
Applying: drm/i915: pwrite/pread do not require obj->base.filp, just pages
Applying: drm
The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the object provide struct pages.
Signed-off-by: Chris Wilson
Cc: Ankitprasad Sharma
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 7
On 16-06-13 13:29:46, Petko Manolov wrote:
> Hello guys,
>
> Running xorg on my Lenovo Yoga 2 Pro (MY2013) on recent kernels turn into a
> major PITA. After a couple of minutes the screen starts to flicker and only
> killing xorg or reboot fixes the problem. This is what i typically see
On Mon, Jun 13, 2016 at 05:39:47PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Now that the infoframe hooks are part of the intel_dig_port, we can use
> > the normal .write_infoframe() hook to up
On Mon, Jun 13, 2016 at 03:47:13PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > DP ports will also want to utilize the video DIP for SDP transmission.
> > So let's move the vfuncs into the dig_por
On Mon, Jun 13, 2016 at 03:36:19PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Disabling the video DIP when shutting the port down seems like a good
> > idea.
> >
> > Bspec says:
> > "When disabl
On Mon, Jun 13, 2016 at 01:40:50PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > has_infoframe is what tells us whether infoframes should be enabled, so
> > let's pass that instead of has_hdmi_sink
Regards
Shashank
On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Now that the infoframe hooks are part of the intel_dig_port, we can use
the normal .write_infoframe() hook to update the VSC SDP. We do need to
deal with the size difference between the VSC DIP and t
On 13/06/2016 16:45, tim.g...@intel.com wrote:
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
v2: move to gen9_init_workarounds (Arun)
v3: move to start of gen9_
On Jun 10 Paulo Zanoni wrote:
> Since my test machines don't produce FIFO underrun errors, I tested this by
> creating a debugfs file that just calls intel_fbc_handle_fifo_underrun(). I'd
> appreciate some Tested-by tags, if possible.
Since May 8 I have been using 4.6.0-rc6 patched with
drm-intel-
Reviewed-by: Shashank Sharma
Regards
Shashank
On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
DP ports may want to use the video DIP for SDP transmission, so let's
initiialize the vfuncs for DP encoders as well. The only exception is
port A eDP prior to HSW as th
== Series Details ==
Series: drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
(rev3)
URL : https://patchwork.freedesktop.org/series/8487/
State : warning
== Summary ==
Series 8487v3 drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
http://patchwork.freedeskt
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
v2: move to gen9_init_workarounds (Arun)
v3: move to start of gen9_init_workarounds (Arun)
Signed-off-by: Tim Gore
Hello guys,
Running xorg on my Lenovo Yoga 2 Pro (MY2013) on recent kernels turn into a
major PITA. After a couple of minutes the screen starts to flicker and only
killing xorg or reboot fixes the problem. This is what i typically see in
dmesg:
[0.00] microcode: microcode up
On 13/06/16 11:25, Dave Gordon wrote:
On 13/06/16 10:48, Tvrtko Ursulin wrote:
On 10/06/16 17:51, Dave Gordon wrote:
This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.
There are three resources to be
== Series Details ==
Series: series starting with [RESEND,1/7] drm/i915/dsi: don't debug log
"missing" sequences
URL : https://patchwork.freedesktop.org/series/8611/
State : success
== Summary ==
Series 8611v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/8611/re
Dan Carpenter writes:
> It seems pretty clear that bitwise OR was intended here and not logical
> OR.
>
> Fixes: 6fc29133eafb ('drm/i915/gen9: Add WaDisableSkipCaching')
> Signed-off-by: Dan Carpenter
Reviewed-by: Mika Kuoppala
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/g
== Series Details ==
Series: drm/i915/opregion: proper handling of DIDL and CADL (rev3)
URL : https://patchwork.freedesktop.org/series/4783/
State : failure
== Summary ==
Series 4783v3 drm/i915/opregion: proper handling of DIDL and CADL
http://patchwork.freedesktop.org/api/1.0/series/4783/revi
-i915-opregion-proper-handling-of-DIDL-and-CADL/20160613-173347
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
On 13/06/16 10:48, Tvrtko Ursulin wrote:
On 10/06/16 17:51, Dave Gordon wrote:
This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.
There are three resources to be managed:
1. Cachelines: a single line w
In sequence block v3 these are gracefully skipped anyway, but add the
functions so we can have some debug breadcrumbs.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pa
Leave behind some debugging clues in case some panels don't work
properly.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index da5ed4a850b9..e2f47ff15
Be a little paranoid in case the specs change or something.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index d078c57
Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add them where it feels logical. The
drm panel hooks don't currently offer us more granularity anyway.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
1 file
Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add them where it feels logical. The
drm panel hooks don't currently offer us more granularity anyway.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
1 file
On 10/06/16 17:51, Dave Gordon wrote:
During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at
this point. But then, the booted kernel is rep
1 - 100 of 132 matches
Mail list logo
