On Tue, 11 Apr 2017 23:27:07 +0200,
Chris Wilson wrote:
>
> On Tue, Apr 11, 2017 at 10:20:56PM +0100, Chris Wilson wrote:
> > On Tue, Apr 11, 2017 at 11:01:57PM +0200, Takashi Iwai wrote:
> > > On Tue, 11 Apr 2017 22:41:12 +0200,
> > > Chris Wilson wrote:
> > > Oh, this fell into a crack as it was
== Series Details ==
Series: series starting with [1/3] drm/i915: Add stub mmio read/write routines
to mock device
URL : https://patchwork.freedesktop.org/series/22891/
State : success
== Summary ==
Series 22891v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22
Provide dummy function pointers for the mock device in case we do hit
mmio during testing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 1 +
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +
drivers/gpu/drm/i915/selftests/mock_uncore.c | 52 +
If we have a mock engine and it has no more requests in flight, report
it as idle as there is no hardware to contradict us! Otherwise we
attempt to query the hw that doesn't exist and find that the hw hasn't
set its idle bit and we get upset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
igt_mmap_offset_exhaustion() selftest was using live requests to make an
object busy, but we did not hold a runtime pm wakeref for submitting the
requests. Acquire it to avoid triggering "RPM wakelock ref not held
during HW access" warnings.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/s
On Tue, Apr 11, 2017 at 10:20:56PM +0100, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 11:01:57PM +0200, Takashi Iwai wrote:
> > On Tue, 11 Apr 2017 22:41:12 +0200,
> > Chris Wilson wrote:
> > Oh, this fell into a crack as it was sent just before my vacation.
> >
> > About the change:
> >
> > >
On Tue, Apr 11, 2017 at 11:01:57PM +0200, Takashi Iwai wrote:
> On Tue, 11 Apr 2017 22:41:12 +0200,
> Chris Wilson wrote:
> >
> > On Wed, Mar 01, 2017 at 06:59:18PM +, Chris Wilson wrote:
> > > [31908.547136] BUG: KASAN: use-after-free in
> > > intel_lpe_audio_teardown+0x78/0xb0 [i915] at add
On Tue, 11 Apr 2017 22:41:12 +0200,
Chris Wilson wrote:
>
> On Wed, Mar 01, 2017 at 06:59:18PM +, Chris Wilson wrote:
> > [31908.547136] BUG: KASAN: use-after-free in
> > intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358
> > [31908.547297] Read of size 8 by task drv_selftest/
== Series Details ==
Series: series starting with [01/13] drm/i915: Reinstate reservation_object
zapping for batch_pool objects (rev2)
URL : https://patchwork.freedesktop.org/series/22099/
State : failure
== Summary ==
LD drivers/acpi/built-in.o
LD drivers/scsi/scsi_mod.o
LD
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active loca
On Wed, Mar 01, 2017 at 06:59:18PM +, Chris Wilson wrote:
> [31908.547136] BUG: KASAN: use-after-free in
> intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358
> [31908.547297] Read of size 8 by task drv_selftest/3781
> [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted:
Hi Dave,
I have a lonely pull request for you. Just the patch you asked me to pick up
this morning.
drm-misc-fixes-2017-04-11:
Core changes:
- None
Driver changes
- udl: Fix unaligned memory access on SPARC (Jonathan)
Cheers, Sean
The following changes since commit a71c9a1c779f2499fb2afc0
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
== 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
== 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
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
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
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
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 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
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 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
== 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
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
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
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 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
== 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
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
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
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
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 +++
== 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 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
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 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:
>> >>
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 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
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 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:
>> >>
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
== 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
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: 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 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
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
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 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:
>> >
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, 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
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 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
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
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 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
== 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 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/
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 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
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 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
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 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 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 ==
== 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 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-
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 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 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 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 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:
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:
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
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 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 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
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 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
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
/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
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
== 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: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 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
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
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
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
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
> -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:
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
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 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
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
== 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
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
1 - 100 of 112 matches
Mail list logo
