This is a lockless version of the exisiting psr_wait_for_idle().
We want to wait for PSR to idle out inside intel_pipe_update_start.
At the time of a pipe update, we should never race with any psr
enable or disable code, which is a part of crtc enable/disable. So,
we can live w/o taking any psr loc
Quoting Tarun Vyas (2018-06-22 08:05:21)
> This is a lockless version of the exisiting psr_wait_for_idle().
> We want to wait for PSR to idle out inside intel_pipe_update_start.
> At the time of a pipe update, we should never race with any psr
> enable or disable code, which is a part of crtc enabl
On Fri, Jun 22, 2018 at 08:12:00AM +0100, Chris Wilson wrote:
> Quoting Tarun Vyas (2018-06-22 08:05:21)
> > This is a lockless version of the exisiting psr_wait_for_idle().
> > We want to wait for PSR to idle out inside intel_pipe_update_start.
> > At the time of a pipe update, we should never rac
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Friday, June 22, 2018 2:36 PM
>To: Zhao, Yakui ; intel-gfx@lists.freedesktop.org
>Cc: Zhao, Yakui
>Subject: Re: [PATCH V2] drm/i915: Use I915_MAP_WC for execlists context
>buffer on the platforms without LLC
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Friday, June 22, 2018 2:26 PM
>To: Zhao, Yakui ; intel-gfx@lists.freedesktop.org
>Cc: Zhao, Yakui
>Subject: Re: [PATCH V2] drm/i915: Use I915_MAP_WC for execlists context
>buffer on the platforms without LLC
Quoting Zhao, Yakui (2018-06-22 08:29:15)
>
>
> >-Original Message-
> >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> >Sent: Friday, June 22, 2018 2:36 PM
> >To: Zhao, Yakui ; intel-gfx@lists.freedesktop.org
> >Cc: Zhao, Yakui
> >Subject: Re: [PATCH V2] drm/i915: Use I915_MAP_WC
From: Hang Yuan
This helps kvmgt included in initramfs and got loaded after i915.
Signed-off-by: Hang Yuan
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 062e91b..a0fb51f 100644
-
> -Original Message-
> From: Sripada, Radhakrishna
> Sent: Friday, June 22, 2018 2:39 AM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>
> Subject: Re: [Intel-gfx] [v2] drm/i915: Enable hw workaround to bypass
> alpha
>
> On Thu, Jun 21, 2018 at 08:4
== Series Details ==
Series: drm/i915/psr: Lockless version of psr_wait_for_idle (rev3)
URL : https://patchwork.freedesktop.org/series/45209/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9394 =
== Summary - SUCCESS ==
No regressions found.
External
Quoting hang.y...@linux.intel.com (2018-06-22 08:32:57)
> From: Hang Yuan
>
> This helps kvmgt included in initramfs and got loaded after i915.
>
> Signed-off-by: Hang Yuan
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/
== Series Details ==
Series: drm/i915: add kvmgt as i915's soft dependency
URL : https://patchwork.freedesktop.org/series/45227/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9395 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https:/
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Friday, June 22, 2018 3:37 PM
>To: Zhao, Yakui ; intel-gfx@lists.freedesktop.org
>Subject: RE: [PATCH V2] drm/i915: Use I915_MAP_WC for execlists context
>buffer on the platforms without LLC
>
>Quoting Zhao,
Quoting Zhao, Yakui (2018-06-22 09:06:27)
>
>
> >-Original Message-
> >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> >Sent: Friday, June 22, 2018 3:37 PM
> >To: Zhao, Yakui ; intel-gfx@lists.freedesktop.org
> >Subject: RE: [PATCH V2] drm/i915: Use I915_MAP_WC for execlists contex
On Fri, Jun 22, 2018 at 08:44:50AM +0100, Chris Wilson wrote:
> Quoting hang.y...@linux.intel.com (2018-06-22 08:32:57)
> > From: Hang Yuan
> >
> > This helps kvmgt included in initramfs and got loaded after i915.
> >
> > Signed-off-by: Hang Yuan
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 2
== Series Details ==
Series: series starting with [v6,1/5] drm/i915/psr: Remove intel_crtc_state
parameter from disable()
URL : https://patchwork.freedesktop.org/series/45200/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4365_full -> Patchwork_9389_full =
== Summary - WAR
tor 2018-06-21 klockan 14:09 -0700 skrev Radhakrishna Sripada:
> On Thu, Jun 21, 2018 at 08:43:56PM +0530, Vandita Kulkarni wrote:
> > Alpha blending with alpha 0 and 0xff passes through
> > alpha math and rounding logic causing differences
> > compared to fully transparent or opaque plane,resultin
On Fri, Jun 22, 2018 at 04:33:21PM +0800,
intel-gvt-dev-boun...@lists.freedesktop.org wrote:
> On Fri, Jun 22, 2018 at 08:44:50AM +0100, Chris Wilson wrote:
> > Quoting hang.y...@linux.intel.com (2018-06-22 08:32:57)
> > > From: Hang Yuan
> > >
> > > This helps kvmgt included in initramfs and go
Before checking for vblank evasion in pipe_update_start, we
need to wait for PSR idle. intel_psr.c already has psr_wait_for_idle
but we don't need any psr locks in pipe_update_start anyway b/c
psr_enable/disable won't race there. There is some code duplication
here but can't help it (borrowed from
On Fri, Jun 22, 2018 at 01:51:08AM -0700, Tarun Vyas wrote:
> Before checking for vblank evasion in pipe_update_start, we
> need to wait for PSR idle. intel_psr.c already has psr_wait_for_idle
> but we don't need any psr locks in pipe_update_start anyway b/c
> psr_enable/disable won't race there. T
This is a lockless version of the exisiting psr_wait_for_idle().
We want to wait for PSR to idle out inside intel_pipe_update_start.
At the time of a pipe update, we should never race with any psr
enable or disable code, which is a part of crtc enable/disable. So,
we can live w/o taking any psr loc
On Fri, Jun 22, 2018 at 09:41:26AM +0100, Chris Wilson wrote:
> Quoting Hang Yuan (2018-06-22 09:18:02)
> > On Fri, Jun 22, 2018 at 08:44:50AM +0100, Chris Wilson wrote:
> > > Quoting hang.y...@linux.intel.com (2018-06-22 08:32:57)
> > > > From: Hang Yuan
> > > >
> > > > This helps kvmgt included
The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then
the pipe_update_start call schedules itself out to check back later.
On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but
lags w.r.t core kernel code, hot plugging an external display triggers
tons of "potential
== Series Details ==
Series: drm/i915/psr: Lockless version of psr_wait_for_idle (rev4)
URL : https://patchwork.freedesktop.org/series/45209/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9396 =
== Summary - SUCCESS ==
No regressions found.
External
== Series Details ==
Series: drm/i915: Wait for PSR exit before checking for vblank evasion
URL : https://patchwork.freedesktop.org/series/45235/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i9
Hi Tarun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.18-rc1 next-20180622]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Tarun,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.18-rc1 next-20180622]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
This series improves crc-core <-> driver interface.
This series adds following functionality in the crc-core
- Now control node will print all the available sources if
implemented by driver along with current source.
- Setting of sorce will fail if provided source is not supported
- cleanup o
This patch implements a callback function "pre_crc_read" which will
be called before crc read. In this function driver can implement and
preparation work required for successfully reading CRC data.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/drm_debugfs_crc.c | 8
include/drm/drm_c
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable input, values_cnt we
already gets as part of verify_crc_source.
Sig
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 +++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 16
This patch implements "verify_crc_source" callback function for
rockchip drm driver.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm
This patch adds a new callback function "verify_crc_source" which will
be used during setting the crc source in control node and while opening
data node for crc reading. This will help in avoiding setting of wrong
string for source.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/drm_debugfs_crc
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
poll/read blocking read() call.
Suggested-by: Ville Syrjälä
Signed-off-by: Mahesh Kumar
---
This patch implements a callback function "get_crc_sources" which
will be called during read of control node. It is an optional
callback function and if driver implements this callback, driver
should print list of available CRC sources in seq_file privided
as an input to the callback.
Signed-off-b
This patch implements verify_crc_source callback function introduced
earlier in this series.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/gpu/drm/i915/intel_pipe_crc.c | 109 +
This patch implements get_crc_sources callback, which returns list of
all the valid crc sources supported by driver in current platform.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pipe_cr
This patch implements "verify_crc_source" callback function for
rcar drm driver.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/dr
== Series Details ==
Series: Improve crc-core driver interface
URL : https://patchwork.freedesktop.org/series/45246/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
029f1bb122df drm: crc: Introduce verify_crc_source callback
5ec7aa87b40a drm: crc: Introduce pre_crc_read function
As we may cancel the ce->state allocation during context pinning (but
crucially after we mark ce as operational), that means we may be asked
to destroy a nonexistent ce->state. Given the choice in handing a
complex error path on pinning, and just ignoring the lack of state in
destroy, choice the la
== Series Details ==
Series: Improve crc-core driver interface
URL : https://patchwork.freedesktop.org/series/45246/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9398 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9398 absolute
== Series Details ==
Series: drm/i915/execlists: Check for ce->state before destroy
URL : https://patchwork.freedesktop.org/series/45249/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9399 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Op 22-06-18 om 12:41 schreef Mahesh Kumar:
> This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
>
> Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
> during open. If application want to wait after read call, it can use
> poll/read blocking read() call.
>
> Suggest
== Series Details ==
Series: drm/i915/psr: Add psr1 live status (rev2)
URL : https://patchwork.freedesktop.org/series/45143/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368_full -> Patchwork_9392_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwo
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
v2: reordered
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 9
The caching of SGT's done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugg
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 57 +++
include/linux/dma-buf.h | 5 +
2 files ch
[As requested by Daniel cross posting to intel-gfx as well].
This set is the first step towards allowing to use a DMA-buf without actually
pinning the underlying resources. This in turn the the ground work for PCIe P2P
operations as well as quite a bunch of other use cases.
The idea is that we
== Series Details ==
Series: series starting with [1/4] dma-buf: add
dma_buf_(un)map_attachment_locked variants v2
URL : https://patchwork.freedesktop.org/series/45258/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bc0996cea437 dma-buf: add dma_buf_(un)map_attachment_locked va
== Series Details ==
Series: drm/i915/psr: Lockless version of psr_wait_for_idle (rev3)
URL : https://patchwork.freedesktop.org/series/45209/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368_full -> Patchwork_9394_full =
== Summary - WARNING ==
Minor unknown changes co
== Series Details ==
Series: series starting with [1/4] dma-buf: add
dma_buf_(un)map_attachment_locked variants v2
URL : https://patchwork.freedesktop.org/series/45258/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9400 =
== Summary - FAILURE ==
Seriou
From: Michal Hocko
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks. Currently we simply back off and mark an
oom
On 06/22/2018 02:30 PM, Maarten Lankhorst wrote:
Op 22-06-18 om 12:41 schreef Mahesh Kumar:
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
== Series Details ==
Series: mm, oom: distinguish blockable mode for mmu notifiers
URL : https://patchwork.freedesktop.org/series/45263/
State : failure
== Summary ==
Applying: mm, oom: distinguish blockable mode for mmu notifiers
Using index info to reconstruct a base tree...
M arch/x86
== Series Details ==
Series: drm/i915: add kvmgt as i915's soft dependency
URL : https://patchwork.freedesktop.org/series/45227/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368_full -> Patchwork_9395_full =
== Summary - WARNING ==
Minor unknown changes coming with Pat
Hi Michal,
[Adding Felix as well]
Well first of all you have a misconception why at least the AMD graphics
driver need to be able to sleep in an MMU notifier: We need to sleep
because we need to wait for hardware operations to finish and *NOT*
because we need to wait for locks.
I'm not sure
On Fri 22-06-18 17:13:02, Christian König wrote:
> Hi Michal,
>
> [Adding Felix as well]
>
> Well first of all you have a misconception why at least the AMD graphics
> driver need to be able to sleep in an MMU notifier: We need to sleep because
> we need to wait for hardware operations to finish
Quoting Michal Hocko (2018-06-22 16:02:42)
> Hi,
> this is an RFC and not tested at all. I am not very familiar with the
> mmu notifiers semantics very much so this is a crude attempt to achieve
> what I need basically. It might be completely wrong but I would like
> to discuss what would be a bett
== Series Details ==
Series: drm/i915/psr: Lockless version of psr_wait_for_idle (rev4)
URL : https://patchwork.freedesktop.org/series/45209/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368_full -> Patchwork_9396_full =
== Summary - WARNING ==
Minor unknown changes co
On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:02:42)
> > Hi,
> > this is an RFC and not tested at all. I am not very familiar with the
> > mmu notifiers semantics very much so this is a crude attempt to achieve
> > what I need basically. It might be completely
== Series Details ==
Series: mm, oom: distinguish blockable mode for mmu notifiers (rev2)
URL : https://patchwork.freedesktop.org/series/45263/
State : failure
== Summary ==
Applying: mm, oom: distinguish blockable mode for mmu notifiers
Using index info to reconstruct a base tree...
M d
[Hmm, the cc list got mangled somehow - you have just made many people
to work for suse ;) and to kvack.org in the preious one - fixed up
hopefully]
On Fri 22-06-18 17:07:21, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:57:16)
> > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > Qu
On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > Hi,
> > > this is an RFC and not tested at all. I am not very familiar with the
> > > mmu notifiers semantics very much so this is a cru
Additionally, we are already on Arch:
https://aur.archlinux.org/packages/compute-runtime
Can I assume that adoption plan is not a blocker anymore?
Bartosz
> Yes, once you follow through with the plan, there should be no issues about
> merging patches to support the driver.
>
> You may want to
[Resnding with the CC list fixed]
On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > > Quoting Michal Hocko (2018-06-22 16:02:42)
In the guc_ctl_debug_flags, the ads struct is programmed only
when USES_GUC_SUBMISSION is satisfied. But, this has to be
programmed for all suspend/resume cases.
Remove the condition and program the ads struct for
both huc loading and guc submission.
This issue was noticed when CI threw errors for
Commit title is slightly misleading, as the USES_GUC_SUBMISSION is not
removed from a suspend/resume path. the firmware tag is also confusing
since this fixes an i915 bug. Maybe something like "drm/i915/guc: Remove
USES_GUC_SUBMISSION for ads programming" would be clearer
On 22/06/18 10:05, An
On Fri, Jun 22, 2018 at 06:42:43PM +0200, Michal Hocko wrote:
> [Resnding with the CC list fixed]
>
> On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> > On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > > On Fri 22-06-18 16:36:4
On Fri, 2018-06-22 at 10:25 -0700, Daniele Ceraolo Spurio wrote:
> Commit title is slightly misleading, as the USES_GUC_SUBMISSION is
> not
> removed from a suspend/resume path. the firmware tag is also
> confusing
> since this fixes an i915 bug. Maybe something like "drm/i915/guc:
> Remove
> US
>-Original Message-
>From: Ceraolo Spurio, Daniele
>Sent: Friday, June 22, 2018 10:26 AM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Cc: Spotswood, John A ; Mateo Lozano, Oscar
>
>Subject: Re: [PATCH] firmware/guc: Remove USES_GUC_SUBMISSION for
>suspend/resume
>
>Commit t
== Series Details ==
Series: firmware/guc: Remove USES_GUC_SUBMISSION for suspend/resume
URL : https://patchwork.freedesktop.org/series/45270/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4369 -> Patchwork_9403 =
== Summary - WARNING ==
Minor unknown changes coming with
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Tarun Vyas
>Sent: Friday, June 22, 2018 1:59 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Pandiyan, Dhinakaran ; Vivi, Rodrigo
>
>Subject: [Intel-gfx] [PATCH v3] drm/i915/psr: Lockless vers
On 22/06/18 10:38, Srivatsa, Anusha wrote:
-Original Message-
From: Ceraolo Spurio, Daniele
Sent: Friday, June 22, 2018 10:26 AM
To: Srivatsa, Anusha ; intel-
g...@lists.freedesktop.org
Cc: Spotswood, John A ; Mateo Lozano, Oscar
Subject: Re: [PATCH] firmware/guc: Remove USES_GUC_SU
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Shaikh, Azhar
>Sent: Friday, June 22, 2018 10:43 AM
>To: Vyas, Tarun ; intel-gfx@lists.freedesktop.org
>Cc: Pandiyan, Dhinakaran ; Vivi, Rodrigo
>
>Subject: Re: [Intel-gfx] [PATCH v3] drm/i
== Series Details ==
Series: drm/i915/execlists: Check for ce->state before destroy
URL : https://patchwork.freedesktop.org/series/45249/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4368_full -> Patchwork_9399_full =
== Summary - WARNING ==
Minor unknown changes coming
In the guc_ctl_debug_flags, the ads struct is programmed only
when USES_GUC_SUBMISSION is satisfied. But, this has to be
programmed for all suspend/resume cases.
Remove the condition and program the ads struct for
both huc loading and guc submission.
This issue was noticed when CI threw errors for
On Fri, 2018-06-22 at 09:29 +0530, vathsala nagaraju wrote:
> From: Vathsala Nagaraju
>
> Prints live state of psr1.Extending the existing
> PSR2 live state function to cover psr1.
>
> Tested on KBL with psr2 and psr1 panel.
>
> v2: rebase
> v3: DK
> Rename psr2_live_status to psr_source_st
== Series Details ==
Series: drm/i915/guc: Remove USES_GUC_SUBMISSION for ads programming
URL : https://patchwork.freedesktop.org/series/45275/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
feae764d1f39 drm/i915/guc: Remove USES_GUC_SUBMISSION for ads programming
-:25: WARNING:
== Series Details ==
Series: drm/i915/guc: Remove USES_GUC_SUBMISSION for ads programming
URL : https://patchwork.freedesktop.org/series/45275/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4369 -> Patchwork_9404 =
== Summary - SUCCESS ==
No regressions found.
Externa
== Series Details ==
Series: firmware/guc: Remove USES_GUC_SUBMISSION for suspend/resume
URL : https://patchwork.freedesktop.org/series/45270/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4369_full -> Patchwork_9403_full =
== Summary - WARNING ==
Minor unknown changes c
On 2018-06-22 11:24 AM, Michal Hocko wrote:
> On Fri 22-06-18 17:13:02, Christian König wrote:
>> Hi Michal,
>>
>> [Adding Felix as well]
>>
>> Well first of all you have a misconception why at least the AMD graphics
>> driver need to be able to sleep in an MMU notifier: We need to sleep because
>>
Quoting Anusha Srivatsa (2018-06-22 19:19:03)
> In the guc_ctl_debug_flags, the ads struct is programmed only
> when USES_GUC_SUBMISSION is satisfied. But, this has to be
> programmed for all suspend/resume cases.
> Remove the condition and program the ads struct for
> both huc loading and guc subm
== Series Details ==
Series: drm/i915/guc: Remove USES_GUC_SUBMISSION for ads programming
URL : https://patchwork.freedesktop.org/series/45275/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4369_full -> Patchwork_9404_full =
== Summary - WARNING ==
Minor unknown changes
commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr
back.") switched from delayed work to the plain variant and while doing so
remove the check for work_busy() before scheduling a PSR activation.
This appears to cause consecutive executions of psr_activate() in this
scenario - after
== Series Details ==
Series: drm/i915/psr: Fix race in intel_psr_work()
URL : https://patchwork.freedesktop.org/series/45291/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4370 -> Patchwork_9405 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://pa
== Series Details ==
Series: drm/i915/psr: Fix race in intel_psr_work()
URL : https://patchwork.freedesktop.org/series/45291/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4370_full -> Patchwork_9405_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchw
86 matches
Mail list logo
