== Series Details ==
Series: series starting with [v3,1/2] drm/i915/perf: Allow non-privileged
access when OA buffer is not sampled
URL : https://patchwork.freedesktop.org/series/69645/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7367_full -> Patchwork_15321_full
==
== Series Details ==
Series: drm/i915/dsi: Do not read the transcoder register.
URL : https://patchwork.freedesktop.org/series/69654/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7368 -> Patchwork_15324
Summary
---
== Series Details ==
Series: series starting with [01/19] drm/i915/selftests: Force bonded
submission to overlap
URL : https://patchwork.freedesktop.org/series/69647/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7367_full -> Patchwork_15322_full
=
Before checking the current i915_active state for the asynchronous work
we submitted, flush any ongoing callback. This ensures that our sampling
is robust and does not sporadically fail due to bad timing as the work
is running on another cpu.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
When waiting for idle, serialise with any ongoing callback so that it
will have completed before completing the wait.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_wakeref.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wa
Only serialise with the chipset using an mmio if the chipset is
currently active. We expect that any writes into the chipset range will
simply be forgotten until it wakes up.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Since igt now defaults to not enabling ftrace-on-oops, we need to
manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
GEM_BUG_ON panicking.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i91
Chris Wilson writes:
> Only serialise with the chipset using an mmio if the chipset is
> currently active. We expect that any writes into the chipset range will
> simply be forgotten until it wakes up.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid, as we always manipulated the timeline only
We only need the one loop to find the dirty vma flush them, and their
chipset.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.
As we may park the gt during request retirement, we may then cancel the
retirement worker only to then program the delayed worker once more.
If we schedule the next delayed retirement worker first, if we then park
the gt, the work remain cancelled [until we unpark].
Signed-off-by: Chris Wilson
-
Take the obj->vma.lock to prevent modifications to the list as we
iterate, to avoid the dreaded the NULL pointer.
<1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
0150
<1>[ 347.820856] #PF: supervisor read access in kernel mode
<1>[ 347.820874] #PF: error_code(0x
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a working if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normally are in process context,
we can typically u
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner.
References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in
intel_gt_retire_requests()")
Signed-of
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin() needed to be atomic and
ordered in a nice oni
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap w
Retire all requests if we resort to wedged the driver on suspend. They
will now be idle, so we might as we free them before shutting down.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm
Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
possible rc6 context corruption. Poke at the bear!
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 13 ++
When setting up a full GGTT, we expect the next insert to fail with
-ENOSPC. Simplify the use of ERR_PTR to not confuse either the reader or
smatch.
Reported-by: Dan Carpenter
References: f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction")
Signed-off-by: Chris Wilson
---
driver
Now that we never allow the intel_wakeref callbacks to be invoked from
interrupt context, we do not need the irqsafe spinlock for the timeline.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 -
drivers/gpu/drm/i915/gt/intel_reset.c | 9 -
Bonded request submission is designed to allow requests to execute in
parallel as laid out by the user. If the master request is already
finished before its bonded pair is submitted, the pair were not destined
to run in parallel and we lose the information about the master engine
to dictate selecti
On Fri, Nov 15, 2019 at 09:42:00PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Yank out the code for the plane->fb/old_fb/crtc handling from
> the page flip path into page_flip_internal(), and provide a
> simpler variant for atomic drivers.
>
> We'll also move the fb vs. src viewport c
On Fri, Nov 15, 2019 at 09:42:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The early return in drm_atomic_set_mode_for_crtc() isn't quite
> right. It would mistakenly return and fail to update
> crtc_state->enable if someone actually tried to set a zeroed
> mode on a currently disab
Chris Wilson writes:
> Only serialise with the chipset using an mmio if the chipset is
> currently active. We expect that any writes into the chipset range will
> simply be forgotten until it wakes up.
>
> Signed-off-by: Chris Wilson
From other threads,
Reviewed-by: Mika Kuoppala
> ---
> dr
Chris Wilson writes:
> Take the obj->vma.lock to prevent modifications to the list as we
> iterate, to avoid the dreaded the NULL pointer.
>
> <1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
> 0150
> <1>[ 347.820856] #PF: supervisor read access in kernel mode
> <1>[
On Fri, Nov 15, 2019 at 09:42:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Test the basics of drm_atomic_set_mode_for_crtc(), and in particular
> verify that the function doesn't take the shortcut incorrectly.
>
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/
On Fri, Nov 15, 2019 at 09:42:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently setplane grabs all modeset locks, which seems a bit
> excessive. Let's reduce that to just the locks we really need
> on atomic drivers. For non-atomic drivers let's stick to the
> current scheme fo
Chris Wilson writes:
> We only need the one loop to find the dirty vma flush them, and their
> chipset.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/
== Series Details ==
Series: series starting with [01/17] drm/i915/gem: Manually dump the debug
trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69669/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e14d64857e27 drm/i915/gem: Manually dump the debug trace on G
Quoting Mika Kuoppala (2019-11-19 10:48:22)
> Chris Wilson writes:
>
> > We only need the one loop to find the dirty vma flush them, and their
> > chipset.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
> > 1
When userspace writes into the GTT itself, it is supposed to call
set-domain to let the kernel keep track and so manage the CPU/GPU
caches. As we track writes on the individual i915_vma, we should also be
sure to mark them as dirty.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/
== Series Details ==
Series: series starting with [01/17] drm/i915/gem: Manually dump the debug
trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15325
Fault handler to handle missing pages for shmem-backed objects.
v2: bail out of inserting PTEs when failing to insert the
fault address
v3: has struct page check
v4: Add self-test for validating CPU fault handler to ensure PTEs
are revoked when an object is unbound.
v5: Add comment where P
Prefer CPU WC mmaps via our new mmap offset plumbing otherwise fall-
back to GTT mmaps when hw doesn't support PAT
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
Acked-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 ++
drivers/gpu/drm/i915/gem/i915_gem_mman
This is really just an alias of mmap_gtt. The 'mmap offset' nomenclature
comes from the value returned by this ioctl which is the offset into the
device fd which userpace uses with mmap(2).
mmap_gtt was our initial mmap_offset implementation, this extends
our CPU mmap support to allow additional f
Have i915 replace the core drm_gem_mmap implementation to overcome its
limitation in having only a single mmap offset node per gem object.
This change allows us to have multiple mmap offsets per object and
enables a mmapping instance to use unique fault-handlers per user vma.
This allows i915 to s
On 19/11/2019 13.37, Abdiel Janulgue wrote:
> +struct drm_i915_gem_mmap_offset {
> + /** Handle for the object being mapped. */
> + __u32 handle;
> + __u32 pad;
> + /**
> + * Fake offset to use for subsequent mmap call
> + *
> + * This is a fixed-size type for 32/64
== Series Details ==
Series: drm/i915/dsi: Do not read the transcoder register.
URL : https://patchwork.freedesktop.org/series/69654/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7368_full -> Patchwork_15324_full
Summary
-
On 08/11/2019 11:04, Arkadiusz Hiler wrote:
On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote:
Quoting Arkadiusz Hiler (2019-11-07 17:38:20)
We don't want you to translate C into English, we want you to provide a bit of
that extra information that you would have put in the comments a
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
>
> On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
> > On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
> > > > On Mon, Nov 18, 2019 at 06:59:21PM +08
== Series Details ==
Series: drm/i915/gem: Track ggtt writes from userspace on the bound vma
URL : https://patchwork.freedesktop.org/series/69672/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15326
Summar
On Tue, Nov 19, 2019 at 11:03:39AM +0800, Jason Wang wrote:
> > Also, see the other conversations we are having about a "virtual" bus
> > and devices. I do not want to have two different ways of doing the same
> > thing in the kernel at the same time please. Please work together with
> > the Inte
== Series Details ==
Series: series starting with [1/4] drm/i915: Allow i915 to manage the vma
offset nodes instead of drm core
URL : https://patchwork.freedesktop.org/series/69674/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
badcc07981f3 drm/i915: Allow i915 to manage the v
On Tue, Nov 19, 2019 at 02:37:17PM +0200, Lionel Landwerlin wrote:
> On 08/11/2019 11:04, Arkadiusz Hiler wrote:
> > On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote:
> > > Quoting Arkadiusz Hiler (2019-11-07 17:38:20)
> > > > We don't want you to translate C into English, we want you t
On Tue, Nov 19, 2019 at 02:37:17PM +0200, Lionel Landwerlin wrote:
> On 08/11/2019 11:04, Arkadiusz Hiler wrote:
> > On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote:
> > > Quoting Arkadiusz Hiler (2019-11-07 17:38:20)
> > > > We don't want you to translate C into English, we want you t
Addressed comments on RFC-v2 from Jani, thanks.
Vandita Kulkarni (8):
drm/i915/dsi: Configure transcoder operation for command mode.
drm/i915/dsi: Add vblank calculation for command mode
drm/i915/dsi: Add cmd mode flags in display mode private flags
drm/i915/dsi: Add check for periodic com
In TE Gate mode, on every flip we need to set the
frame update request bit. After this bit is set
transcoder hardware will automatically send the
frame data to the panel when it receives the TE event.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 22
If the GOP has programmed periodic command mode,
we need to disable that which would need a
deconfigure and configure sequence.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i
Transcoder timing calculation differ for command mode.
v2: Use is_vid_mode, and use same I915_WRITE (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 39 +-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/
On dsi cmd mode we do not receive vblanks instead
we would get TE and these flags indicate TE is expected on
which port.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/ic
Adding TE flags and periodic command mode flags
as part of private flags to indicate what TE interrupts
we would be getting instead of vblanks in case of mipi dsi
command mode.
v2: Add TE flag description (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
v2: Pass only relevant masked bits to the handler (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 64 +
1 file changed, 64 insertions(+)
diff --git a/dri
Configure the transcoder to operate in TE GATE command mode
and take TE events from GPIO.
Also disable the periodic command mode, that GOP would have
programmed.
v2: Disable util pin (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 52
We need to configure TE interrupt in two places.
Port interrupt and DSI interrupt mask registers.
v2: Hide the private flags check inside configure_te (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 55 +++--
1 file changed, 53 insertions
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fdc21d81bb9e drm/i915/dsi: Configure transcoder operation for command mode.
-:60: CHECK:BRACES: braces {} sh
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/dsi: Configure transcoder operation for command mode.
Okay!
Commit: drm
On 19/11/2019 15:02, Arkadiusz Hiler wrote:
The goal is to have those descriptions in the first place and make them
more accessible to people. You have to keep in mind that we have
decently sized organization, people are coming and going. Not everyone
becomes a seasoned kernel developer day one a
On Mon, 2019-11-18 at 20:25 +, Lisovskiy, Stanislav wrote:
P.S: (In addition to my last yesterday letter):
>
> That is actually a violation of BSpec, we are not using two slices
> for same
> pipe while we could. We had already enough of bw issues, why should
> we make our life even harder?
>
== Series Details ==
Series: series starting with [1/4] drm/i915: Allow i915 to manage the vma
offset nodes instead of drm core
URL : https://patchwork.freedesktop.org/series/69674/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15327
Dear Tomáš,
On 2019-11-04 18:31, Tomas Janousek wrote:
> On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote:
>> On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7
>> resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews
>> the errors below.
>>
>> ```
>> [0
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15328
Summary
---
**SUCCESS*
On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
On Mon, N
On 2019/11/19 下午8:40, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 11:03:39AM +0800, Jason Wang wrote:
Also, see the other conversations we are having about a "virtual" bus
and devices. I do not want to have two different ways of doing the same
thing in the kernel at the same time please. P
On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
>
> On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
> > On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
> > > On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
> > > > On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote
On 18/11/2019 23:02, Chris Wilson wrote:
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid,
Fork and remap the same object into a new process space under a new file
descriptor. Principally to check list management and find scaling issues
in using such lists.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
tests/i915/gem_mmap_gtt.c | 72 ++-
1 fi
On Mon, Nov 18, 2019 at 08:00:07PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Cleanups around .crtc_enable/disable() (rev3)
> URL : https://patchwork.freedesktop.org/series/69352/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7365 -> Patchwo
On 18/11/2019 23:02, Chris Wilson wrote:
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued thi
Quoting Tvrtko Ursulin (2019-11-19 14:15:49)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > The general concept was that intel_timeline.active_count was locked by
> > the intel_timeline.mutex. The exception was for power management, where
> > the engine->kernel_context->timeline could be manipul
== Series Details ==
Series: i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
URL : https://patchwork.freedesktop.org/series/69678/
State : warning
== Summary ==
Did not get list of undocumented tests for this run, something is wrong!
Other than that, pipeline status: FAILE
== Series Details ==
Series: series starting with [01/17] drm/i915/gem: Manually dump the debug
trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370_full -> Patchwork_15325_full
==
Quoting Tvrtko Ursulin (2019-11-19 14:35:04)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
> > the backend"), I erroneously concluded that we last modify the engine
> > inside __i915_request_commit() meaning that we could en
On 18/11/2019 23:02, Chris Wilson wrote:
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin() n
Chris Wilson writes:
> When userspace writes into the GTT itself, it is supposed to call
> set-domain to let the kernel keep track and so manage the CPU/GPU
> caches. As we track writes on the individual i915_vma, we should also be
> sure to mark them as dirty.
>
> Signed-off-by: Chris Wilson
>
== Series Details ==
Series: i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
URL : https://patchwork.freedesktop.org/series/69678/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371 -> IGTPW_3727
Summary
For our current users we don't expect pool objects to be writable from
the gpu.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_pool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.c
b/drivers/gpu/drm/i915/
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap w
On 18/11/2019 23:02, Chris Wilson wrote:
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine swit
Quoting Matthew Auld (2019-11-19 15:01:54)
> For our current users we don't expect pool objects to be writable from
> the gpu.
>
Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow
buffers")
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped
Hi All,
This series needs to be merged through a single tree, to keep things
bisectable. I have even considered just squashing all 3 patches into 1,
but having separate commits seems better, but that does lead to an
intermediate state where the backlight sysfs interface will be broken
(and fixed 2
== Series Details ==
Series: drm/i915: Cleanups around .crtc_enable/disable() (rev4)
URL : https://patchwork.freedesktop.org/series/69352/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371 -> Patchwork_15329
Summary
--
Hi Chris,
On Tue, Nov 19, 2019 at 10:09:29AM +, Chris Wilson wrote:
> Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
> possible rc6 context corruption. Poke at the bear!
>
> Signed-off-by: Chris Wilson
> Cc: Imre Deak
> Cc: Mika Kuoppala
it looks good,
Reviewed-by:
Quoting Andi Shyti (2019-11-19 15:24:59)
> Hi Chris,
>
> On Tue, Nov 19, 2019 at 10:09:29AM +, Chris Wilson wrote:
> > Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
> > possible rc6 context corruption. Poke at the bear!
> >
> > Signed-off-by: Chris Wilson
> > Cc: Imre
also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-gt-Schedule-request-retirement-when-submission-idles/20191119-023819
b
On 11/19/19 12:46 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20191118:
on x86_64:
ERROR: "pm_suspend_target_state" [drivers/gpu/drm/i915/i915.ko] undefined!
# CONFIG_SUSPEND is not set
--
~Randy
Reported-by: Randy Dunlap
___
Intel-gfx
On Tue, 19 Nov 2019, Hans de Goede wrote:
> Hi All,
>
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
> intermediate state where the
On Tue, Nov 19, 2019 at 04:18:18PM +0100, Hans de Goede wrote:
> At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
> different PWM controllers for controlling the LCD's backlight brightness.
> Either the one integrated into the PMIC or the one integrated into the
> SoC (the 1st
Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
possible rc6 context corruption. Poke at the bear!
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Mika Kuoppala
Reviewed-by: Andi Shyti
Tested-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +
drivers
On Tue, 19 Nov 2019, Vandita Kulkarni wrote:
> As per the Bspec, port mapping is fixed for mipi dsi.
>
> v2: Reuse the existing function (Jani)
>
> Signed-off-by: Vandita Kulkarni
Pushed, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 17 +++
On 18/11/2019 23:02, Chris Wilson wrote:
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a working if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normall
On 18/11/2019 23:02, Chris Wilson wrote:
Now that we never allow the intel_wakeref callbacks to be invoked from
interrupt context, we do not need the irqsafe spinlock for the timeline.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 -
drivers/gpu/dr
On 18/11/2019 23:02, Chris Wilson wrote:
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner.
References: 7936a22dd466 ("drm/i915/gt: Wait for new request
== Series Details ==
Series: drm/i915: make pool objects read-only
URL : https://patchwork.freedesktop.org/series/69684/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371 -> Patchwork_15330
Summary
---
**SUCCESS**
On 18/11/2019 23:02, Chris Wilson wrote:
As we may park the gt during request retirement, we may then cancel the
retirement worker only to then program the delayed worker once more.
If we schedule the next delayed retirement worker first, if we then park
the gt, the work remain cancelled [until
Quoting Tvrtko Ursulin (2019-11-19 15:57:24)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index f7c8fec436a9..fec46afb9264 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/
On 18/11/2019 23:02, Chris Wilson wrote:
Retire all requests if we resort to wedged the driver on suspend. They
will now be idle, so we might as we free them before shutting down.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 +
1 file changed, 1 insertion(+)
di
Chris Wilson writes:
> When waiting for idle, serialise with any ongoing callback so that it
> will have completed before completing the wait.
Might be come apparent and evident when reading the patch
that introduce the intel_wakeref_unlock_wait(),
but reader is yearning for a why part.
The 'wa
1 - 100 of 161 matches
Mail list logo
