== Series Details ==
Series: drm: Document code of conduct
URL : https://patchwork.freedesktop.org/series/22830/
State : warning
== Summary ==
Series 22830v1 drm: Document code of conduct
https://patchwork.freedesktop.org/api/1.0/series/22830/revisions/1/mbox/
Test gem_exec_basic:
Sub
Hi,
On 11 April 2017 at 07:48, Daniel Vetter wrote:
> Note: As Daniel Stone mentioned in the announcement fd.o admins
> started chatting with the communities their hosting, which includs the
> X.org foundation board, to figure out how to fan out enforcement and
> allow projects to run things on t
On 11 April 2017 at 12:38, Daniel Stone wrote:
> Hi,
>
> On 11 April 2017 at 07:48, Daniel Vetter wrote:
>> Note: As Daniel Stone mentioned in the announcement fd.o admins
>> started chatting with the communities their hosting, which includs the
>> X.org foundation board, to figure out how to fan
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 10, 2017 3:39 PM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH i-g-t v2] tests/kms_concurrent: Concurrent and
> interruptible
> subtests for atomic
On 04/11/2017 01:03 PM, Sumit Semwal wrote:
On 11 April 2017 at 12:38, Daniel Stone wrote:
Hi,
On 11 April 2017 at 07:48, Daniel Vetter wrote:
Note: As Daniel Stone mentioned in the announcement fd.o admins
started chatting with the communities their hosting, which includs the
X.org founda
Op 11-04-17 om 09:42 schreef Kahola, Mika:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Monday, April 10, 2017 3:39 PM
>> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH i-g-t v2] tests/kms_concurrent: Concu
On ma, 2017-04-10 at 17:24 +0100, Chris Wilson wrote:
> Similar to commit 8490ae207f1d ("drm/i915: Suppress busy status for
> engines if wedged") we also want to report intel_engine_is_idle() as
> true as well as the main intel_engines_are_idle(), as we now check that
> the engines are idle when ov
On 11/04/17 10:51, Archit Taneja wrote:
On 04/11/2017 01:03 PM, Sumit Semwal wrote:
On 11 April 2017 at 12:38, Daniel Stone wrote:
Hi,
On 11 April 2017 at 07:48, Daniel Vetter wrote:
Note: As Daniel Stone mentioned in the announcement fd.o admins
started chatting with the communities thei
On Fri, 07 Apr 2017, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 12:15:00PM -0700, Rodrigo Vivi wrote:
>> Backlight support on Cannonpoint is a lot
>> likely Broxton, but with only one controller (0).
>
> This being the PCH backlight obviously. I guess we still don't have any
> use for the CPU
On Mon, Apr 10, 2017 at 04:23:15PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915: Stop second guessing the caller
> for intel_uncore_wait_for_register() (rev2)
> URL : https://patchwork.freedesktop.org/series/22786/
> State : warning
>
> == Summ
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think th
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think th
If we *know* that the engine is idle, i.e. we have not more contexts in
lift, we can skip any spurious CSB idle interrupts. These spurious
interrupts seem to arrive long after we assert that the engines are
completely idle, triggering later assertions:
[ 178.896646] intel_engine_is_idle(bcs): int
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think th
== Series Details ==
Series: drm/i915: Don't mark an execlists context-switch when idle
URL : https://patchwork.freedesktop.org/series/22841/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/gvt/firmware.o
CC [M] drivers/gpu/drm/i915/gvt/interrupt.o
CC [M] drivers/gpu/drm/i91
This test case introduces concurrently running test cases for atomic
modesetting.
The first test or thread draws blue backround with black holes on it.
These holes are covered by rectangular, blue planes that are placed
randomly like in test case 'kms_plane_multiple'.
The second thread changes re
On Tue, 11 Apr 2017, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything
On 04/11/2017 08:48 AM, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anyth
On 04/11/2017 11:03 AM, Daniel Vetter wrote:
> On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
>> freedesktop.org has adopted a formal&enforced code of conduct:
>>
>> https://www.fooishbar.org/blog/fdo-contributor-covenant/
>> https://www.freedesktop.org/wiki/CodeOfConduct/
>>
>> Bes
> -Original Message-
> From: Dong, Chuanxiao
> Sent: Monday, April 10, 2017 10:40 AM
> To: Dong, Chuanxiao ; Chris Wilson
>
> Cc: Tian, Kevin ; intel-gvt-...@lists.freedesktop.org;
> intel-gfx@lists.freedesktop.org; joonas.lahti...@linux.intel.com; Zheng,
> Xiao ; Wang, Zhi A
> Subject:
Op 11-04-17 om 08:48 schreef Daniel Vetter:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
freedesktop.org has adopted a formal&enforced code of conduct:
https://www.fooishbar.org/blog/fdo-contributor-covenant/
https://www.freedesktop.org/wiki/CodeOfConduct/
Besides formalizing things a bit more I don't think this changes
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to acquire uncore.lock around
each register, s
Since the sandybridge_pcode_read() may be called from
skl_pcode_request() inside an atomic context (with preempt disabled), we
should avoid hitting any sleeping paths.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 inserti
While we do hold the forcewake for legacy ringbuffer initialisation, we
don't guard our access with the uncore.lock spinlock. In theory, we only
initialise when no others should be accessing the same mmio cachelines,
but in practice be safe as this is an infrequently used path and not
worth risky m
Allow the caller to use the fast_timeout_us to specify how long to wait
within the atomic section, rather than transparently switching to a
sleeping loop for larger values. This is required as some callsites may
need a long wait and are in an atomic section.
Signed-off-by: Chris Wilson
Cc: Michal
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
__in
On Mon, Apr 10, 2017 at 07:34:33AM -0700, Oscar Mateo wrote:
> From: Daniele Ceraolo Spurio
>
> Technically speaking, the context size is per engine class, not per
> instance.
>
> v2: Add MISSING_CASE (Tvrtko)
>
> v3: Rebased
>
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Sign
On Tue, Apr 11, 2017 at 11:13:36AM +0100, Chris Wilson wrote:
> Allow the caller to use the fast_timeout_us to specify how long to wait
> within the atomic section, rather than transparently switching to a
> sleeping loop for larger values. This is required as some callsites may
> need a long wait
== Series Details ==
Series: series starting with [1/5] drm/i915: Stop second guessing the caller
for intel_uncore_wait_for_register()
URL : https://patchwork.freedesktop.org/series/22845/
State : success
== Summary ==
Series 22845v1 Series without cover letter
https://patchwork.freedesktop.o
On Tue, Apr 11, 2017 at 11:13:37AM +0100, Chris Wilson wrote:
> submit_request() is called from an atomic context, it's not allowed to
> sleep. We have to be careful in our parameters to
> intel_uncore_wait_for_register() to limit ourselves to the atomic wait
> loop and not incur the wrath of our w
/drm-i915-Don-t-mark-an-execlists-context-switch-when-idle/20170411-183510
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x070-201715 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux
Hi Chris,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20170411]
[cannot apply to v4.11-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris
On 11/04/2017 11:13, Chris Wilson wrote:
Allow the caller to use the fast_timeout_us to specify how long to wait
within the atomic section, rather than transparently switching to a
sleeping loop for larger values. This is required as some callsites may
need a long wait and are in an atomic secti
In at least SKL and GLK (possibly other devices too), using a cursor
plane to scan out an fb might result in a different pipe crc than when
using a regular plane at the same position with the same fb while using
the CSC logic to limit the color range. The differences could be caused
by the cursor p
On Tue, Apr 11, 2017 at 11:13:36AM +0100, Chris Wilson wrote:
> Allow the caller to use the fast_timeout_us to specify how long to wait
> within the atomic section, rather than transparently switching to a
> sleeping loop for larger values. This is required as some callsites may
> need a long wait
On 11/04/2017 12:21, Chris Wilson wrote:
On Tue, Apr 11, 2017 at 11:13:36AM +0100, Chris Wilson wrote:
Allow the caller to use the fast_timeout_us to specify how long to wait
within the atomic section, rather than transparently switching to a
sleeping loop for larger values. This is required as
On 11/04/2017 11:13, Chris Wilson wrote:
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 6976e74b5
On 11/04/2017 11:13, Chris Wilson wrote:
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to
Allow the caller to use the fast_timeout_us to specify how long to wait
within the atomic section, rather than transparently switching to a
sleeping loop for larger values. This is required as some callsites may
need a long wait and are in an atomic section.
v2: Reinforce kerneldoc fast_timeout_us
On 11/04/2017 11:13, Chris Wilson wrote:
Since the sandybridge_pcode_read() may be called from
skl_pcode_request() inside an atomic context (with preempt disabled), we
should avoid hitting any sleeping paths.
Please update the commit to mention the timeout decrease and with that:
Reviewed-by:
On 11/04/2017 11:13, Chris Wilson wrote:
While we do hold the forcewake for legacy ringbuffer initialisation, we
don't guard our access with the uncore.lock spinlock. In theory, we only
initialise when no others should be accessing the same mmio cachelines,
but in practice be safe as this is an
On Tue, Apr 11, 2017 at 10:18:56AM +0100, Chris Wilson wrote:
> If we *know* that the engine is idle, i.e. we have not more contexts in
> lift, we can skip any spurious CSB idle interrupts. These spurious
> interrupts seem to arrive long after we assert that the engines are
> completely idle, trigg
On 11/04/2017 12:27, Chris Wilson wrote:
Allow the caller to use the fast_timeout_us to specify how long to wait
within the atomic section, rather than transparently switching to a
sleeping loop for larger values. This is required as some callsites may
need a long wait and are in an atomic secti
On 11/04/2017 11:25, Chris Wilson wrote:
On Mon, Apr 10, 2017 at 07:34:33AM -0700, Oscar Mateo wrote:
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc:
On 10/04/2017 15:34, Oscar Mateo wrote:
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-
== Series Details ==
Series: series starting with [v2] drm/i915: Stop second guessing the caller for
intel_uncore_wait_for_register() (rev2)
URL : https://patchwork.freedesktop.org/series/22845/
State : failure
== Summary ==
Series 22845v2 Series without cover letter
https://patchwork.freedes
On Tue, Apr 11, 2017 at 10:30:00AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/5] drm/i915: Stop second guessing the caller
> for intel_uncore_wait_for_register()
> URL : https://patchwork.freedesktop.org/series/22845/
> State : success
>
> == Summary ==
On Wed, 29 Mar 2017, Jani Nikula wrote:
> On Tue, 21 Mar 2017, Jani Nikula wrote:
>> On Mon, 13 Mar 2017, Jani Nikula wrote:
>>> I'm already scripting my fixes backports quite a bit, and frankly don't
>>> really manually backport anything that doesn't apply cleanly. I'm
>>> thinking of automatin
On Tue, Apr 11, 2017 at 12:32:14PM +0100, Tvrtko Ursulin wrote:
>
> On 11/04/2017 11:25, Chris Wilson wrote:
> >On Mon, Apr 10, 2017 at 07:34:33AM -0700, Oscar Mateo wrote:
> >>From: Daniele Ceraolo Spurio
> >>
> >>Technically speaking, the context size is per engine class, not per
> >>instance.
On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
We want to refer to the index of the engine consistently throughout the
userspace ABI. We already have such an index through the execbuffer
engine specifier, that needs to be able to refer to each engine
specifically, so rename it the index to uabi_id to reflect its
generality beyond execbuf.
Sign
On Fri, 07 Apr 2017, Zhenyu Wang wrote:
> Hi,
>
> Still need this one from Min for correct execlist csb initial
> read ptr fix, which could possibly cause guest hang.
Pulled to drm-intel-fixes, thanks.
BR,
Jani.
>
> Thanks.
> ---
>
> The following changes since commit aa4ce4493c88dc324911152d1c
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think th
On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote:
> On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
>> freedesktop.org has adopted a formal&enforced code of conduct:
>>
>> https://www.fooishbar.org/blog/fdo-contributor-covenant/
>> https://www.freedesktop.org/wiki/CodeOfConduct/
== Series Details ==
Series: drm/i915: Rename intel_engine_cs.exec_id to uabi_id
URL : https://patchwork.freedesktop.org/series/22849/
State : warning
== Summary ==
Series 22849v1 drm/i915: Rename intel_engine_cs.exec_id to uabi_id
https://patchwork.freedesktop.org/api/1.0/series/22849/revisio
On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote:
> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote:
> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
> >> freedesktop.org has adopted a formal&enforced code of conduct:
> >>
> >> https://www.fooishbar.org/blog/fdo
Hey
On Tue, Apr 11, 2017 at 8:48 AM, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this ch
On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote:
> On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote:
>> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote:
>> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
>> >> freedesktop.org has adopted a formal&enforced c
On Tue, Apr 11, 2017 at 01:26:51PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Rename intel_engine_cs.exec_id to uabi_id
> URL : https://patchwork.freedesktop.org/series/22849/
> State : warning
>
> == Summary ==
>
> Series 22849v1 drm/i915: Rename intel_engine_cs.exec
In the next patch, we will introduce a new cache domain for
differentiating between GTT access and direct WC access. This will
require us to include WC in our write_domain flushes. Rather than
duplicate a third function, combine the existing two into one and
flushing WC writes will then be automati
When discussing a new WC mmap, we based the interface upon the
assumption that GTT was fully coherent. How naive! Commits 3b5724d702ef
("drm/i915: Wait for writes through the GTT to land before reading
back") and ed4596ea992d ("drm/i915/guc: WA to address the Ringbuffer
coherency issue") demonstrat
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think th
On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote:
> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote:
> > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote:
> >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote:
> >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Dan
On Tue, 11 Apr 2017, Luc Verhaegen wrote:
> On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote:
>> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote:
>> > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote:
>> >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote:
>> >
This is slightly weaker version of MAYBE_BUILD_BUG_ON that allows
us to avoid adding implicit BUG but still detect as much as possible
during the build. With this new macro we can fix the problem with
GCC 4.4.7 that wrongly triggers build break in wait_for_atomic()
when invoked with non-const param
On Mon, 10 Apr 2017, "Stangle, Steven P." wrote:
> Hi all, I am looking for the best driver to use on an old computer
> running RHEL 7.2. The computer is a Gateway m465-g which has an Intel
> 945gm Chipset with integrated graphics - intel graphics media
> accelerator (GMA) 950.
>
> What driver am
On Thu, 06 Apr 2017, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 04:44:17PM +0300, Jani Nikula wrote:
>> Don't clobber intel_dp->sink_count with the raw value.
>>
>> Suggested-by: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Thanks for the reviews, pushed patc
== Series Details ==
Series: series starting with [1/2] drm/i915: Combine write_domain flushes to a
single function
URL : https://patchwork.freedesktop.org/series/22855/
State : success
== Summary ==
Series 22855v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/2
On Tue, Apr 11, 2017 at 04:58:51PM +0300, Jani Nikula wrote:
> On Tue, 11 Apr 2017, Luc Verhaegen wrote:
> > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote:
> >> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote:
> >> > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wro
== Series Details ==
Series: drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON
URL : https://patchwork.freedesktop.org/series/22857/
State : success
== Summary ==
Series 22857v1 drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON
https://patchwork.freedesktop.org/api/1.0/series/22857/revisions/1/mbox/
Test g
In places, we assume that RCS exists. This has been true forever, but
let us catch this failure during bringup by adding an explicit check
that we do have an RCS engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 8 +++-
1 file changed, 7 insertions(+), 1 deleti
On Tue, Apr 11, 2017 at 5:14 PM, Luc Verhaegen wrote:
> On Tue, Apr 11, 2017 at 04:58:51PM +0300, Jani Nikula wrote:
>> On Tue, 11 Apr 2017, Luc Verhaegen wrote:
>> > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote:
>> >> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote:
>> >>
On 2017-04-11 02:48 AM, Daniel Vetter wrote:
freedesktop.org has adopted a formal&enforced code of conduct:
https://www.fooishbar.org/blog/fdo-contributor-covenant/
https://www.freedesktop.org/wiki/CodeOfConduct/
Besides formalizing things a bit more I don't think this changes
anything for us
On Tue, Apr 11, 2017 at 04:30:22PM +0100, Chris Wilson wrote:
> In places, we assume that RCS exists. This has been true forever, but
> let us catch this failure during bringup by adding an explicit check
> that we do have an RCS engine.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i9
Thanks Jani for pushing patches 1-9.
Now we just need review on Patch 10 (Validate cached link rate and lane count),
may
Be Ville can review that. I have submitted new revision based on his comments
already.
And Patch 11 already has your R-b.
Regards
Manasi
On Thu, 06 Apr 2017, Ville Syrjälä
On Tue, Apr 11, 2017 at 11:14 AM, Luc Verhaegen wrote:
> On Tue, Apr 11, 2017 at 04:58:51PM +0300, Jani Nikula wrote:
>> On Tue, 11 Apr 2017, Luc Verhaegen wrote:
>> > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote:
>> >> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote:
>> >>
On Tue, Apr 11, 2017 at 04:30:22PM +0100, Chris Wilson wrote:
> In places, we assume that RCS exists. This has been true forever, but
> let us catch this failure during bringup by adding an explicit check
> that we do have an RCS engine.
Note that some might argue that I'm using the RCS engine as
On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
== Series Details ==
Series: drm/i915: Bail if we do not setup the RCS engine
URL : https://patchwork.freedesktop.org/series/22860/
State : success
== Summary ==
Series 22860v1 drm/i915: Bail if we do not setup the RCS engine
https://patchwork.freedesktop.org/api/1.0/series/22860/revisions/1/m
On 11/04/2017 16:30, Chris Wilson wrote:
In places, we assume that RCS exists. This has been true forever, but
let us catch this failure during bringup by adding an explicit check
that we do have an RCS engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 8 +++
On Tue, Apr 11, 2017 at 5:50 PM, Alex Deucher wrote:
> On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote:
>> freedesktop.org has adopted a formal&enforced code of conduct:
>>
>> https://www.fooishbar.org/blog/fdo-contributor-covenant/
>> https://www.freedesktop.org/wiki/CodeOfConduct/
>>
>> Be
Since
commit bac2a909a096c9110525c18cbb8ce73c660d5f71
Author: Rafael J. Wysocki
Date: Wed Jan 21 02:17:42 2015 +0100
PCI / PM: Avoid resuming PCI devices during system suspend
PCI devices will default to allowing the system suspend complete
optimization where devices are not woken up duri
Daniel Vetter writes:
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything for us, we've alrea
== Series Details ==
Series: drm/i915: Prevent the system suspend complete optimization
URL : https://patchwork.freedesktop.org/series/22863/
State : failure
== Summary ==
Series 22863v1 drm/i915: Prevent the system suspend complete optimization
https://patchwork.freedesktop.org/api/1.0/series
On Tue, Apr 11, 2017 at 07:12:35PM +0300, Imre Deak wrote:
> +static int i915_pm_prepare(struct device *kdev)
> +{
> + /*
> + * Get a reference to disable the direct complete optimization. This
> + * is needed, since we have a suspend sequence specific to system
> + * suspend (th
In places, we assume that RCS exists. This has been true forever, but
let us catch this failure during bringup by adding an explicit check
that we do have an RCS engine.
v2: Make use of HAS_ENGINE (Tvrtko)
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_e
On Tue, Apr 11, 2017 at 05:54:07PM +0100, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 07:12:35PM +0300, Imre Deak wrote:
> > +static int i915_pm_prepare(struct device *kdev)
> > +{
> > + /*
> > +* Get a reference to disable the direct complete optimization. This
> > +* is needed, since
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
v4: Restore the interface back to hiding the class lookup (Chris)
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele C
== Series Details ==
Series: drm/i915: Bail if we do not setup the RCS engine (rev2)
URL : https://patchwork.freedesktop.org/series/22860/
State : success
== Summary ==
Series 22860v2 drm/i915: Bail if we do not setup the RCS engine
https://patchwork.freedesktop.org/api/1.0/series/22860/revisi
On Tue, Apr 11, 2017 at 12:09 PM, Daniel Vetter wrote:
> On Tue, Apr 11, 2017 at 5:50 PM, Alex Deucher wrote:
>> On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter
>> wrote:
>>> freedesktop.org has adopted a formal&enforced code of conduct:
>>>
>>> https://www.fooishbar.org/blog/fdo-contributor-cov
2017-04-11 Daniel Vetter :
> freedesktop.org has adopted a formal&enforced code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything for us, we've
On Tue, Apr 11, 2017 at 04:32:59PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Prevent the system suspend complete optimization
> URL : https://patchwork.freedesktop.org/series/22863/
> State : failure
>
> == Summary ==
>
> Series 22863v1 drm/i915: Prevent the system s
We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by
virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are
busy. As this is not obvious from the code, add a comment.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 9
On Tue, Apr 11, 2017 at 05:15:51PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Bail if we do not setup the RCS engine (rev2)
> URL : https://patchwork.freedesktop.org/series/22860/
> State : success
>
> == Summary ==
>
> Series 22860v2 drm/i915: Bail if we do not setup
On Tue, Apr 11, 2017 at 03:11:12AM -0700, Oscar Mateo wrote:
> From: Daniele Ceraolo Spurio
>
> Technically speaking, the context size is per engine class, not per
> instance.
>
> v2: Add MISSING_CASE (Tvrtko)
>
> v3: Rebased
>
> v4: Restore the interface back to hiding the class lookup (Chris
Similar to commit 8490ae207f1d ("drm/i915: Suppress busy status for
engines if wedged") we also want to report intel_engine_is_idle() as
true as well as the main intel_engines_are_idle(), as we now check that
the engines are idle when overwriting the HWS page. This is not true
whilst we are setting
== Series Details ==
Series: drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()
(rev2)
URL : https://patchwork.freedesktop.org/series/22790/
State : success
== Summary ==
Series 22790v2 drm/i915/execlists: Document runtime pm for
intel_lrc_irq_handler()
https://patchwork.fre
== Series Details ==
Series: drm/i915: Lie and treat all engines as idle if wedged (rev2)
URL : https://patchwork.freedesktop.org/series/22793/
State : success
== Summary ==
Series 22793v2 drm/i915: Lie and treat all engines as idle if wedged
https://patchwork.freedesktop.org/api/1.0/series/22
On Tue, Apr 11, 2017 at 07:40:58PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Lie and treat all engines as idle if wedged (rev2)
> URL : https://patchwork.freedesktop.org/series/22793/
> State : success
>
> == Summary ==
>
> Series 22793v2 drm/i915: Lie and treat all
1 - 100 of 112 matches
Mail list logo
