On 27/06/2018 11:58, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 11:40:32)
On 25/06/2018 10:48, Chris Wilson wrote:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission
On 27/06/2018 14:09, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 14:03:07)
On 27/06/2018 11:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 10:52:45)
On 25/06/2018 10:48, Chris Wilson wrote:
@@ -1109,16 +1089,11 @@ static void process_csb(struct intel_engine_cs
Am Dienstag, 26. Juni 2018, 21:47:13 CEST schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> Use drm_crtc_mask() where appropriate.
>
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Signed-off-by: Ville Syrjälä
thanks for that small cleanup, applied to drm-misc-next
Thanks
Heiko
Hi,
thanks for review.
On 6/26/2018 1:59 PM, Daniel Vetter wrote:
On Tue, Jun 26, 2018 at 11:52:57AM +0530, Mahesh Kumar wrote:
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
On Wed, Jun 27, 2018 at 04:52:27PM +0300, Jani Nikula wrote:
> On Wed, 27 Jun 2018, Imre Deak wrote:
> > Pushed it to -dinq with the s/_PICK(_MMIO())/_MMIO_PORT()/ change and the
> > checkpatch warnings fixed. Thanks for the reviews.
>
> I'd prefer it if actual functional changes were resent to
On Tue, Jun 26, 2018 at 05:05:48PM -0700, Vito Caputo wrote:
> Hello,
>
> Beginning with 4.18, when I lock my X server using the `xlock` command,
> and close the lid, upon reopening the lid I am not presented with the
> xlock UI.
>
> The system is not hung. If I blindly enter the password, I
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
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
Cc: dri-de...@lists.freedesktop.org
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
Cc: dri-de...@lists.freedesktop.org
---
This patch implements verify_crc_source callback function introduced
earlier in this series.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/gpu/drm/i915/intel_pipe_crc.c |
This patch implements get_crc_sources callback, which returns list of
all the valid crc sources supported by driver in current platform.
Changes since V1:
- Return array of crc sources
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c |
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4
Op 27-06-18 om 16:44 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.
>
>
Hi,
On 6/27/2018 8:48 PM, Maarten Lankhorst wrote:
Op 27-06-18 om 16:44 schreef Mahesh Kumar:
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.
== Series Details ==
Series: series starting with [1/6] drm/i915/execlists: Pull submit after
dequeue under timeline lock
URL : https://patchwork.freedesktop.org/series/45482/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2f29c7874491 drm/i915/execlists: Pull submit after
== Series Details ==
Series: series starting with [01/31] drm/i915: Defer modeset cleanup to a
secondary task (rev4)
URL : https://patchwork.freedesktop.org/series/45325/
State : failure
== Summary ==
Applying: drm/i915: Defer modeset cleanup to a secondary task
Using index info to
On 27/06/2018 11:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 10:52:45)
On 25/06/2018 10:48, Chris Wilson wrote:
@@ -1109,16 +1089,11 @@ static void process_csb(struct intel_engine_cs *engine)
} else {
port_set(port, port_pack(rq, count));
Quoting Mika Kuoppala (2018-06-27 14:08:34)
> Chris Wilson writes:
>
> > By taking advantage of the RCU protection of the task struct, we can find
> > the appropriate signaler under the spinlock and then release the spinlock
> > before waking the task and signaling the fence.
> >
> >
On Wed, 27 Jun 2018, Chris Wilson wrote:
> I really must remember to proof read git send-email.
I did like the subsequent "warning for horror" and "failure for horror"
messages from CI though.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Add client callbacks and hook them up.
Add a list of clients per drm_device.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 92 -
drivers/gpu/drm/drm_drv.c | 7 +++
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has
moved to drm_fbdev_generic_setup().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 21 -
include/drm/drm_fb_cma_helper.h | 3 ---
2 files changed, 24
Make full use of the generic fbdev client.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +--
drivers/gpu/drm/tinydrm/ili9225.c | 1 -
drivers/gpu/drm/tinydrm/mi0283qt.c | 1 -
drivers/gpu/drm/tinydrm/st7586.c
Print the names of the internal clients currently attached.
Reviewed-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 28
drivers/gpu/drm/drm_debugfs.c | 7 +++
include/drm/drm_client.h | 3 +++
3 files changed, 38
Quoting Tvrtko Ursulin (2018-06-27 14:03:07)
>
> On 27/06/2018 11:35, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-27 10:52:45)
> >>
> >> On 25/06/2018 10:48, Chris Wilson wrote:
> >>> @@ -1109,16 +1089,11 @@ static void process_csb(struct intel_engine_cs
> >>> *engine)
> >>>
Quoting Tvrtko Ursulin (2018-06-27 14:28:08)
>
> On 27/06/2018 12:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-27 11:57:39)
> >> Cost benefit? Is it really so interesting to keep tweaking this? I feel
> >> like I can stamp an r-b with the "yeah whatever" approach.. but the
> >>
On Wed, 27 Jun 2018, Imre Deak wrote:
> Pushed it to -dinq with the s/_PICK(_MMIO())/_MMIO_PORT()/ change and the
> checkpatch warnings fixed. Thanks for the reviews.
I'd prefer it if actual functional changes were resent to the list for
CI instead of fixed in place.
BR,
Jani.
--
Jani Nikula,
Op 27-06-18 om 16:44 schreef Mahesh Kumar:
> 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
> Cc:
On 27/06/2018 14:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 14:15:22)
On 27/06/2018 11:58, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-06-27 11:40:32)
On 25/06/2018 10:48, Chris Wilson wrote:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-06-27 14:08:34)
>> Chris Wilson writes:
>>
>> > By taking advantage of the RCU protection of the task struct, we can find
>> > the appropriate signaler under the spinlock and then release the spinlock
>> > before waking the task and signaling
On Wed, Jun 27, 2018 at 01:45:04PM +0200, Maarten Lankhorst wrote:
> Op 26-06-18 om 19:59 schreef Ville Syrjälä:
> > On Mon, Jun 25, 2018 at 06:37:58PM +0200, Maarten Lankhorst wrote:
> >> The only time we should start FBC is when we have waited a vblank
> >> after the atomic update.
> > What
== Series Details ==
Series: drm/i915: Wait for engines to idle before retiring
URL : https://patchwork.freedesktop.org/series/45484/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4386 -> Patchwork_9443 =
== Summary - FAILURE ==
Serious unknown changes coming with
Chris Wilson writes:
> Avoid calling dma_fence_signal() from inside the interrupt if we haven't
> enabled signaling on the request.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_irq.c | 8 ++--
> drivers/gpu/drm/i915/i915_request.c | 2 +-
>
On Tue, 26 Jun 2018, Vito Caputo wrote:
> Beginning with 4.18, when I lock my X server using the `xlock` command,
> and close the lid, upon reopening the lid I am not presented with the
> xlock UI.
Please file a bug report at [1]. Please include Xorg.0.log and dmesg
with drm.debug=14 reproducing
On 27/06/2018 12:38, Chris Wilson wrote:
In the next patch, we will process the CSB events directly from the
submission path, rather than only after a CS interrupt. Hence, we will
no longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small
On Tue, Jun 26, 2018 at 04:12:24PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/icl: Add power well support
> URL : https://patchwork.freedesktop.org/series/45409/
> State : success
Pushed it to -dinq with the s/_PICK(_MMIO())/_MMIO_PORT()/ change and the
checkpatch
v2: Test each shared context is its own timeline and allows request
reordering between shared contexts.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Michal Wajdeczko
---
lib/i915/gem_context.c | 66 +++
lib/i915/gem_context.h | 13 +
Add a new mode for some more stress, submit the all-engines tests
simultaneously, a stream per engine.
Signed-off-by: Chris Wilson
---
tests/gem_exec_whisper.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/tests/gem_exec_whisper.c
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20180627]
[cannot apply to v4.18-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
Fixes: 0654edaa3690 ("misc/mei/hdcp: Component framework for I915 Interface")
Signed-off-by: kbuild test robot
---
mei_hdcp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index ba75502..146a4be
Hi Noralf,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20180627]
[cannot apply to drm/drm-next linus/master drm-exynos/exynos-drm/for-next
v4.18-rc2 v4.18-rc1 v4.17 v4.18-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
Queues are a form of contexts that share vm and enfore a single timeline
across all engines. Test switching between them, just like ordinary
contexts.
Signed-off-by: Chris Wilson
---
tests/gem_ctx_switch.c | 75 +++---
1 file changed, 55 insertions(+), 20
As a rule of thumb, don't change patches while committing.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drm-intel.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drm-intel.rst b/drm-intel.rst
index baf48f459dd9..ad8ff9739336 100644
--- a/drm-intel.rst
+++ b/drm-intel.rst
@@
Lots has happened in the CI front since the first version was added.
Signed-off-by: Jani Nikula
---
drm-intel.rst | 45 -
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drm-intel.rst b/drm-intel.rst
index c68949a41c95..baf48f459dd9
Quoting Tvrtko Ursulin (2018-06-27 14:24:53)
>
> On 27/06/2018 14:09, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-27 14:03:07)
> >>
> >> On 27/06/2018 11:35, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-06-27 10:52:45)
>
> On 25/06/2018 10:48, Chris Wilson wrote:
>
There's already some BIT() usage here and there, embrace it.
Cc: Paulo Zanoni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index
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
Cc:
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.
Changes
This patch implements "verify_crc_source" callback function for
rcar drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 40 ++
1 file changed, 40 insertions(+)
diff --git
This patch implements "verify_crc_source" callback function for
rockchip drm driver.
Changes since V1:
- simplify the verification (Jani N)
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20
1 file
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 inputs, values_cnt we
already gets as part of verify_crc_source.
On Wed, Jun 27, 2018 at 11:11:57AM +0200, Daniel Vetter wrote:
> On Wed, Jun 27, 2018 at 11:08:48AM +0200, Daniel Vetter wrote:
> > On Tue, Jun 26, 2018 at 08:47:09PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a convenience macro for iterating connector->encoder_ids[].
== Series Details ==
Series: series starting with [1/6] drm/i915/execlists: Pull submit after
dequeue under timeline lock
URL : https://patchwork.freedesktop.org/series/45482/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4388 -> Patchwork_9444 =
== Summary - SUCCESS ==
Quoting Tvrtko Ursulin (2018-06-27 16:21:24)
>
> On 27/06/2018 14:29, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-27 14:15:22)
> >>
> >> On 27/06/2018 11:58, Chris Wilson wrote:
> >>> That tasklets get kicked randomly, I think was the culprit.
> >>
> >> What do you mean? I hope we
On Tue, Jun 26, 2018 at 05:55:59PM -0700, Azhar Shaikh wrote:
> On KBL, WHL RVPs, booting up with an external display connected, triggers
> below warning, when the BiOS brings up the external display too.
> This warning is not seen during hotplug.
>
> [3.615226] [ cut here
Quoting Michal Wajdeczko (2018-06-27 16:51:42)
> On Wed, 27 Jun 2018 16:41:13 +0200, Jani Nikula
> wrote:
>
> > There's already some BIT() usage here and there, embrace it.
> >
> > Cc: Paulo Zanoni
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 9 +
> >
== Series Details ==
Series: drm: Add generic fbdev emulation
URL : https://patchwork.freedesktop.org/series/45488/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: Begin an API for in-kernel clients
Okay!
Commit: drm/fb-helper: Add generic fbdev emulation .fb_probe
On Wed, Jun 27, 2018 at 5:13 PM, Jani Nikula wrote:
> Lots has happened in the CI front since the first version was added.
>
> Signed-off-by: Jani Nikula
> ---
> drm-intel.rst | 45 -
> 1 file changed, 28 insertions(+), 17 deletions(-)
>
> diff --git
== Series Details ==
Series: drm/i915: encourage BIT() macro usage in register definitions
URL : https://patchwork.freedesktop.org/series/45498/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4388 -> Patchwork_9446 =
== Summary - SUCCESS ==
No regressions found.
On Wed, 27 Jun 2018 16:41:13 +0200, Jani Nikula
wrote:
There's already some BIT() usage here and there, embrace it.
Cc: Paulo Zanoni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
== Series Details ==
Series: drm: Add generic fbdev emulation
URL : https://patchwork.freedesktop.org/series/45488/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b94e8e78c556 drm: Begin an API for in-kernel clients
-:26: WARNING:FILE_PATH_CHANGES: added, moved or deleted
== Series Details ==
Series: drm: Add generic fbdev emulation
URL : https://patchwork.freedesktop.org/series/45488/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4388 -> Patchwork_9445 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On Wed, Jun 27, 2018 at 5:13 PM, Jani Nikula wrote:
> As a rule of thumb, don't change patches while committing.
>
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
> ---
> drm-intel.rst | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drm-intel.rst b/drm-intel.rst
> index
On Wed, Jun 27, 2018 at 05:18:39PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 26, 2018 at 05:05:48PM -0700, Vito Caputo wrote:
> > Hello,
> >
> > Beginning with 4.18, when I lock my X server using the `xlock` command,
> > and close the lid, upon reopening the lid I am not presented with the
> >
== Series Details ==
Series: series starting with [1/6] drm/i915/execlists: Pull submit after
dequeue under timeline lock
URL : https://patchwork.freedesktop.org/series/45482/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4388_full -> Patchwork_9444_full =
== Summary -
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
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.
The follow up patch will use this
== Series Details ==
Series: series starting with [CI,1/5] drm/i915/gtt: Add read only pages to
gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/45519/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Add read only pages to gen8_pte_encode
Okay!
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.
The follow up patch will use this
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev7)
URL : https://patchwork.freedesktop.org/series/38254/
State : failure
== Summary ==
Applying: drm: hdcp2.2 authentication msg definitions
Applying: drm: HDMI and DP specific HDCP2.2 defines
Applying: mei: bus: whitelist hdcp
== Series Details ==
Series: Improve crc-core driver interface (rev3)
URL : https://patchwork.freedesktop.org/series/45246/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4388 -> Patchwork_9447 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9447
== Series Details ==
Series: drm/i915: Wait for engines to idle before retiring
URL : https://patchwork.freedesktop.org/series/45484/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4389 -> Patchwork_9450 =
== Summary - SUCCESS ==
No regressions found.
External URL:
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least
On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
read-only, that is cause any GPU write onto that page to be discarded
(not triggering a fault). This is all that we need to finally support
the read-only flag for userptr!
Testcase: igt/gem_userptr_blits/readonly*
From: Jon Bloomfield
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield
If the user created a read-only object, they should not be allowed to
circumvent the write protection using the pwrite ioctl.
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: Joonas Lahtinen
Cc: Matthew Auld
Reviewed-by: Jon Bloomfield
Reviewed-by: Joonas Lahtinen
Reviewed-by: Matthew
From: Jon Bloomfield
Hook up the flags to allow read-only ppGTT mappings for gen8+
v2: Include a selftest to check that writes to a readonly PTE are
dropped
v3: Don't duplicate cpu_check() as we can just reuse it, and even worse
don't wholesale copy the theory-of-operation comment from
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
On Wed, Jun 27, 2018 at 10:39:56AM -0700, Radhakrishna Sripada wrote:
> On Tue, Jun 26, 2018 at 05:55:59PM -0700, Azhar Shaikh wrote:
> > On KBL, WHL RVPs, booting up with an external display connected, triggers
> > below warning, when the BiOS brings up the external display too.
> > This warning
== Series Details ==
Series: drm: Add generic fbdev emulation
URL : https://patchwork.freedesktop.org/series/45488/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4388_full -> Patchwork_9445_full =
== Summary - WARNING ==
Minor unknown changes coming with
== Series Details ==
Series: drm/i915: Wait for engines to idle before retiring
URL : https://patchwork.freedesktop.org/series/45484/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4388 -> Patchwork_9449 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: series starting with [CI,1/5] drm/i915/gtt: Add read only pages to
gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/45519/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
edc140b84d5c drm/i915/gtt: Add read only pages to
Setup a userptr object that only has a read-only mapping back to a file
store (memfd). Then attempt to write into that mapping using the GPU and
assert that those writes do not land (while also writing via a writable
userptr mapping into the same memfd to verify that the GPU is working!)
== Series Details ==
Series: series starting with [v7,1/2] drm/i915/psr: Lockless version of
psr_wait_for_idle
URL : https://patchwork.freedesktop.org/series/45521/
State : failure
== Summary ==
Applying: drm/i915/psr: Lockless version of psr_wait_for_idle
Using index info to reconstruct a
== Series Details ==
Series: series starting with [CI,1/5] drm/i915/gtt: Add read only pages to
gen8_pte_encode
URL : https://patchwork.freedesktop.org/series/45519/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4390 -> Patchwork_9451 =
== Summary - SUCCESS ==
No
== Series Details ==
Series: drm/i915: encourage BIT() macro usage in register definitions
URL : https://patchwork.freedesktop.org/series/45498/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4388_full -> Patchwork_9446_full =
== Summary - WARNING ==
Minor unknown
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on
In the next patch, we will process the CSB events directly from the
submission path, rather than only after a CS interrupt. Hence, we will
no longer have the need for a loop until the has-interrupt bit is clear,
and in the meantime can remove that small optimisation.
v2: Tvrtko pointed out it was
In the next patch, we will begin processing the CSB from inside the
submission path (underneath an irqsoff section, and even from inside
interrupt handlers). This means that updating the execlists->port[] will
no longer be serialised by the tasklet but needs to be locked by the
Following the removal of the last workarounds, the only CSB mmio access
is for the old vGPU interface. The mmio registers presented by vGPU do
not require forcewake and can be treated as ordinary volatile memory,
i.e. they behave just like the HWSP access just at a different location.
We can
On HW reset, the HW clears the write pointer (to 0). But since it also
writes its first CSB entry to slot 0, we need to reset the write pointer
back to the element before (so the first entry we read is 0).
This is required for the next patch, where we trust the CSB completely!
Signed-off-by:
In the following patch, we will process the CSB events under the
timeline.lock and not serialised by the tasklet. This also means that we
will need to protect access to common variables such as
execlists->csb_head with the timeline.lock during reset.
v2: Move sync_irq to avoid deadlocks between
As we now never read back our current head position from the CSB
pointers register, and the HW itself doesn't use it to prevent
overwriting unread CSB entries, we do not need to keep updating the
register. As it turns out this register is not listed as being shadowed,
and so requires forcewake --
We do not need to do a posting read of our uncached mmio write to
re-enable the master interrupt lines after handling an interrupt, so
don't. This saves us a slow UC read before we can process the interrupt,
most noticeable in execlists where any stalls imposes extra latency on
GPU command
Now that we use the CSB stored in the CPU friendly HWSP, we do not need
to track interrupts for when the mmio CSB registers are valid and can
just check where we read up to last from the cached HWSP. This means we
can forgo the atomic bit tracking from interrupt, and in the next patch
it means we
The current method of checking for a failed module load is flawed, as we
only report the error on probing it is not being reported back by
modprobe. So we have to dig inside the module_parameters while the
module is still loaded to discover the error.
v2: Expect i915.inject_load_failure to be
By taking advantage of the RCU protection of the task struct, we can find
the appropriate signaler under the spinlock and then release the spinlock
before waking the task and signaling the fence.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 32
Rather than have multiple locked instructions inside the notify_ring()
irq handler, move them inside the spinlock and reduce their intrinsic
locking.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
If we have more interrupts pending (because we know there are more
breadcrumb signals before the completion), then we do not need to
trigger an irq_seqno_barrier or even wakeup the task on this interrupt
as there will be another. To allow some margin of error (we are trying
to work around
Avoid calling dma_fence_signal() from inside the interrupt if we haven't
enabled signaling on the request.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
drivers/gpu/drm/i915/i915_request.c | 2 +-
== Series Details ==
Series: drm/i915: Wait for engines to idle before retiring
URL : https://patchwork.freedesktop.org/series/45484/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4388_full -> Patchwork_9449_full =
== Summary - WARNING ==
Minor unknown changes coming
1 - 100 of 231 matches
Mail list logo
