On 24/03/16 12:03, Patchwork wrote:
== Series Details ==
Series: drm/i915: fix potential dangling else problems in for_each_ macros
(rev4)
URL : https://patchwork.freedesktop.org/series/1142/
State : success
== Summary ==
Series 1142v4 drm/i915: fix potential dangling else problems in for_
Rename and document the GGTT init functions to give a better
idea of the context where they are called from.
i915_gem_gtt_init => i915_ggtt_init_hw
i915_gem_init_global_gtt => i915_gem_init_ggtt
i915_global_gtt_cleanup => i915_ggtt_cleanup_hw
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Ville Syrjä
On Thu, Mar 24, 2016 at 02:33:32PM +, Dave Gordon wrote:
> On 24/03/16 13:42, Chris Wilson wrote:
> >On Thu, Mar 24, 2016 at 01:32:53PM +, Chris Wilson wrote:
> >>If we arm the release timer on acquiring the forcewake, we will release
> >>the forcewake on the jiffie afterwards. If we only a
On Thu, Mar 24, 2016 at 03:42:28PM +0100, Maarten Lankhorst wrote:
> Op 24-03-16 om 15:26 schreef Ville Syrjälä:
> > On Thu, Mar 24, 2016 at 09:35:04AM +0100, Maarten Lankhorst wrote:
> >> Op 23-03-16 om 16:07 schreef Ville Syrjälä:
> >>> On Wed, Mar 23, 2016 at 02:24:30PM +0100, Maarten Lankhorst
On to, 2016-03-24 at 14:38 +, Chris Wilson wrote:
> A fault in a user provided buffer may lead anywhere, and lockdep warns
> that we have a potential deadlock between the mm->mmap_sem and the
> kernfs file mutex:
>
> [ 82.811702] ==
> [ 8
On Thu, Mar 24, 2016 at 01:54:36PM +, Tvrtko Ursulin wrote:
>
> On 24/03/16 13:42, Chris Wilson wrote:
> >On Thu, Mar 24, 2016 at 01:32:53PM +, Chris Wilson wrote:
> >>If we arm the release timer on acquiring the forcewake, we will release
> >>the forcewake on the jiffie afterwards. If we
On Thu, 24 Mar 2016, Deepak M wrote:
> In CABC (Content Adaptive Brightness Control) content grey level
> scale can be increased while simultaneously decreasing
> brightness of the backlight to achieve same perceived brightness.
>
> The CABC is not standardized and panel vendors are free to follow
On 24/03/16 14:31, Chris Wilson wrote:
__force_wake_get() only acquire a temporary wakeref on forcewake that is
automatically releases when a timer expires. When reading the code
again, I confused __intel_uncore_forcewake_get for __force_wake_get and
to my shame thought I found a bug in an unbala
Quoting Vivi, Rodrigo (2016-03-23 18:52:38)
>
> Thanks Dylan But how will you handle the piglig installed in
> /usr/local/bin? Maybe we can have one version in our piglit dir inside
> igt but another version in the system what could be different and
> misslead this check.
>
I have this: http
On 24/03/16 14:03, Patchwork wrote:
== Series Details ==
Series: drm/i915: Move execlists irq handler to a bottom half (rev3)
URL : https://patchwork.freedesktop.org/series/4764/
State : warning
== Summary ==
Series 4764v3 drm/i915: Move execlists irq handler to a bottom half
http://patchw
On 24/03/16 14:31, Chris Wilson wrote:
__force_wake_get() only acquire a temporary wakeref on forcewake that is
automatically releases when a timer expires. When reading the code
again, I confused __intel_uncore_forcewake_get for __force_wake_get and
to my shame thought I found a bug in an unbal
Op 24-03-16 om 15:48 schreef Ville Syrjälä:
> On Thu, Mar 24, 2016 at 03:42:28PM +0100, Maarten Lankhorst wrote:
>> Op 24-03-16 om 15:26 schreef Ville Syrjälä:
>>> On Thu, Mar 24, 2016 at 09:35:04AM +0100, Maarten Lankhorst wrote:
Op 23-03-16 om 16:07 schreef Ville Syrjälä:
> On Wed, Mar 2
== Series Details ==
Series: drm/i915: Only arm the forcewake release timer on the final put (rev2)
URL : https://patchwork.freedesktop.org/series/4859/
State : failure
== Summary ==
Series 4859v2 drm/i915: Only arm the forcewake release timer on the final put
http://patchwork.freedesktop.org/
On Thu, Mar 24, 2016 at 03:12:02PM +, Dave Gordon wrote:
> On 24/03/16 14:31, Chris Wilson wrote:
> >__force_wake_get() only acquire a temporary wakeref on forcewake that is
> >automatically releases when a timer expires. When reading the code
> >again, I confused __intel_uncore_forcewake_get f
After this series, afaict, intel_bios.c only updates fields under
dev_priv->vbt with the data from VBT.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/intel_bios.c | 4 ++--
drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
drivers/gpu/drm/i915/intel_dp.c | 2 +-
4 files chang
Set from VBT, but never used. Good riddance.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 3 ---
drivers/gpu/drm/i915/intel_bios.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bf867e28731d..09
Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_sdvo.c | 16
3 files changed, 10 insertions(+), 11 dele
On Thu, Mar 24, 2016 at 03:03:24PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Only arm the forcewake release timer on the final put (rev2)
> URL : https://patchwork.freedesktop.org/series/4859/
> State : failure
>
> == Summary ==
>
> Series 4859v2 drm/i915: Only arm t
== Series Details ==
Series: drm/i915: Use atomic state in debugfs.
URL : https://patchwork.freedesktop.org/series/4862/
State : warning
== Summary ==
Series 4862v1 drm/i915: Use atomic state in debugfs.
http://patchwork.freedesktop.org/api/1.0/series/4862/revisions/1/mbox/
Test pm_rpm:
Lets BUG_ON and don't bother with a WARN and returning an error, so we can
remove the need to pollute the code with error handling, after all it is
a programmer error to provide NULL view. Also while we're here remove
redundant NULL ggtt_view check.
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Signed-
On Thu, Mar 24, 2016 at 04:19:13PM +0100, Maarten Lankhorst wrote:
> Op 24-03-16 om 15:48 schreef Ville Syrjälä:
> > On Thu, Mar 24, 2016 at 03:42:28PM +0100, Maarten Lankhorst wrote:
> >> Op 24-03-16 om 15:26 schreef Ville Syrjälä:
> >>> On Thu, Mar 24, 2016 at 09:35:04AM +0100, Maarten Lankhorst
Housekeeping, similar to psr, backlight, and dsi. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 19 ++-
drivers/gpu/drm/i915/intel_bios.c | 38 +++---
drivers/gpu/drm/i915/intel_ddi.c | 8
driv
On ke, 2016-03-23 at 14:57 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Doing a lot of work in the interrupt handler introduces huge
> latencies to the system as a whole.
>
> Most dramatic effect can be seen by running an all engine
> stress test like igt/gem_exec_nop/all where, when
On Thu, Mar 24, 2016 at 05:56:40PM +0200, Imre Deak wrote:
> On ke, 2016-03-23 at 14:57 +, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Doing a lot of work in the interrupt handler introduces huge
> > latencies to the system as a whole.
> >
> > Most dramatic effect can be seen by r
On 24/03/16 07:40, Joonas Lahtinen wrote:
On ke, 2016-03-23 at 18:02 +0200, Ville Syrjälä wrote:
On Wed, Mar 23, 2016 at 05:54:09PM +0200, Mika Kuoppala wrote:
Ville Syrjälä writes:
[ text/plain ]
On Wed, Mar 23, 2016 at 03:00:22PM +0200, Joonas Lahtinen wrote:
Rename and document the GG
On Thu, Mar 24, 2016 at 04:01:53PM +, Dave Gordon wrote:
> On 24/03/16 07:40, Joonas Lahtinen wrote:
> >On ke, 2016-03-23 at 18:02 +0200, Ville Syrjälä wrote:
> >>On Wed, Mar 23, 2016 at 05:54:09PM +0200, Mika Kuoppala wrote:
> >>>
> >>>Ville Syrjälä writes:
> >>>
>
> [ text/plain ]
>
== Series Details ==
Series: drm/i915: Rename __force_wake_get to __force_wake_auto
URL : https://patchwork.freedesktop.org/series/4864/
State : warning
== Summary ==
Series 4864v1 drm/i915: Rename __force_wake_get to __force_wake_auto
http://patchwork.freedesktop.org/api/1.0/series/4864/revis
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of akash.g...@intel.com
> Sent: Tuesday, March 22, 2016 8:43 AM
> To: intel-gfx@lists.freedesktop.org
On 3/24/2016 9:59 PM, Gore, Tim wrote:
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of akash.g...@intel.com
Sent: Tuesday, March 22, 2016 8:43 AM
To
Thanks Shashank.
When they get merged and propagated to nightly I merge the last one in
internal.
On Thu, 2016-03-24 at 12:57 +, Sharma, Shashank wrote:
> Ok, will do it for other patches too.
>
> Regards
> Shashank
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.i
On to, 2016-03-24 at 16:05 +, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 05:56:40PM +0200, Imre Deak wrote:
> > On ke, 2016-03-23 at 14:57 +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Doing a lot of work in the interrupt handler introduces huge
> > > latencies to the
== Series Details ==
Series: kernfs: Move faulting copy_user operations outside of the mutex (rev2)
URL : https://patchwork.freedesktop.org/series/3722/
State : warning
== Summary ==
Series 3722v2 kernfs: Move faulting copy_user operations outside of the mutex
http://patchwork.freedesktop.org/
On Thu, Mar 24, 2016 at 04:34:01PM -, Patchwork wrote:
> == Series Details ==
>
> Series: kernfs: Move faulting copy_user operations outside of the mutex (rev2)
> URL : https://patchwork.freedesktop.org/series/3722/
> State : warning
>
> == Summary ==
>
> Series 3722v2 kernfs: Move faultin
== Series Details ==
Series: series starting with [v2] drm/i915: Rename GGTT init functions (rev3)
URL : https://patchwork.freedesktop.org/series/4790/
State : warning
== Summary ==
Series 4790v3 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4790/revisions/3/mbox/
== Series Details ==
Series: series starting with [1/4] drm/i915: use a substruct in vbt data for edp
URL : https://patchwork.freedesktop.org/series/4868/
State : failure
== Summary ==
Series 4868v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4868/revisions/1/mb
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get fragmented
severely, which considerably slows down the system. In such a scenario,
Shrinker is also unable to help as lack of memory is not the actual problem,
since it has been observed that there are enough fre
This series of patches takes all of the workarounds we used in
intel_dp_dpcd_read_wake() for working around misbehaving sinks into drm's DP
aux transaction helpers, so that they can be applied to all aux transactions
across each driver. While this patch series was intended to fix issues with the
Th
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
Signed-off-by: Lyude
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
Some sinks need some time during the process of resuming the system from
sleep before they're ready to handle transactions. While it would be
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
kn
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
DP helper.
Some sinks will just return garbage for the first aux tranaction they
receive when coming out of sleep mode, so we need to perform an addition
Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
timeout, there's no use for having this function anymore. Good riddens.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_dp.c | 79 -
1 file changed, 22 insertions(+), 57 deletions
From: Arun Siluvery
Due to timing issues in the HW some of the status bits required for GuC
authentication doesn't get set occassionally, when that happens, GuC cannot
be initialized and we will be left with a wedged GPU. The WA suggested is
to perform a soft reset of GuC and attempt to reload th
After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already loaded the GuC with
firmware, which will then cause this kernel's attempt to (re)load the
firmware to fail
On Thu, Mar 24, 2016 at 11:52:59PM +0530, akash.g...@intel.com wrote:
> +static int
> +unsafe_drop_pages(struct drm_i915_gem_object *obj)
> +{
> + struct i915_vma *vma, *next;
> + int ret;
> +
> + drm_gem_object_reference(&obj->base);
> + list_for_each_entry_safe(vma, next, &obj->vm
BTW, this two-item patchset was just a repost to get CI to pick it up,
without getting confused by it previously being embedded in a longer set
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/list
... by issuing dirtyfb calls upon framebuffer creation. Since the
non-working SNA versions just never ever issued dirtyfb or sw_finish
calls, the Kernel workaround disables itself in case it sees one of
those calls. The problem is that we've fixed the bug by forcing
TearFree, so we're still not sen
The DDX driver changes its behavior depending on the value it reads
from i915.enable_fbc, so sanitize the value in order to allow it to
know what's going on. It uses this in order to choose the defaults for
the TearFree option. Before this patch, it will read -1 and always
assume that FBC is disabl
Hi
The Kernel patches are mostly the same, but with the review
suggestions implemented. The DDX patch is new and should really help
things now.
Thanks,
Paulo
Paulo Zanoni (4):
drm/i915/fbc: update busy_bits even for GTT and flip flushes
drm/i915/fbc: sanitize i915.enable_fbc during FBC init
We ignore ORIGIN_GTT because the hardware tracking can recognize GTT
writes and take care of them. We also ignore ORIGIN_FLIP because we
deal with flips without relying on the frontbuffer tracking
infrastructure. On the other hand, a flush is a flush and means we're
good to go, so we need to update
FBC and the frontbuffer tracking infrastructure were designed assuming
that user space applications would follow a specific set of rules
regarding frontbuffer management and mmapping. I recently discovered
that current user space is not exactly following these rules: my
investigation led me to the
Now that we're more protected against user space doing frontbuffer
mmap rendering, the last - how many times did I say this before? -
SKL problem seems to be solved. So let's give it a try.
And since the other newer platforms are still under preliminary
support, let's enable FBC on them too to mak
On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> FBC and the frontbuffer tracking infrastructure were designed assuming
> that user space applications would follow a specific set of rules
> regarding frontbuffer management and mmapping. I recently discovered
> that current user space
On Thu, Mar 24, 2016 at 06:40:55PM +0200, Imre Deak wrote:
> Hm yea, I missed that it's only an execlist tasklet and so there
> shouldn't be any pending tasklet after mark_idle(). Perhaps it would
> still make sense to assert for this in gen8_logical_ring_put_irq() or
> somewhere? Similarly there i
Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> >
> > FBC and the frontbuffer tracking infrastructure were designed
> > assuming
> > that user space applications would follow a specific set of rules
> > regarding frontbuff
On Thu, Mar 24, 2016 at 08:53:21PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > >
> > > FBC and the frontbuffer tracking infrastructure were designed
> > > assuming
> > > that user sp
On Thu, Mar 24, 2016 at 09:03:59PM +, ch...@chris-wilson.co.uk wrote:
> On Thu, Mar 24, 2016 at 08:53:21PM +, Zanoni, Paulo R wrote:
> > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > > >
> > > > FBC and the
Em Qui, 2016-03-24 às 21:03 +, ch...@chris-wilson.co.uk escreveu:
> On Thu, Mar 24, 2016 at 08:53:21PM +, Zanoni, Paulo R wrote:
> >
> > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > >
> > > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > > >
> > > >
>
On Thu, Mar 24, 2016 at 09:21:49PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-03-24 às 21:03 +, ch...@chris-wilson.co.uk escreveu:
> > On Thu, Mar 24, 2016 at 08:53:21PM +, Zanoni, Paulo R wrote:
> > >
> > > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > > >
> > > > On Th
On Thu, 2016-03-24 at 19:56 +, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 06:40:55PM +0200, Imre Deak wrote:
> > Hm yea, I missed that it's only an execlist tasklet and so there
> > shouldn't be any pending tasklet after mark_idle(). Perhaps it
> > would
> > still make sense to assert for th
On Thu, Mar 24, 2016 at 12:18:49PM +, Tvrtko Ursulin wrote:
> /**
> * intel_lrc_irq_handler() - handle Context Switch interrupts
> - * @ring: Engine Command Streamer to handle.
> + * @engine: Engine Command Streamer to handle.
> *
> * Check the unread Context Status Buffers and manage th
101 - 162 of 162 matches
Mail list logo
