== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL (rev3)
URL : https://patchwork.freedesktop.org/series/44043/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4274_full -> Patchwork_9175_full =
== Summary - WARNING ==
Minor unknown changes
== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL (rev3)
URL : https://patchwork.freedesktop.org/series/44043/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4274 -> Patchwork_9175 =
== Summary - SUCCESS ==
No regressions found.
External
== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL (rev3)
URL : https://patchwork.freedesktop.org/series/44043/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: drop one bit on the hw_id when using guc
== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL (rev3)
URL : https://patchwork.freedesktop.org/series/44043/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4bb0abe855ff drm/i915: drop one bit on the hw_id when using guc
9d90eabec73c
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen the issue because we need to allocate
1048576+ contexts to hit this issue. Still, we should
Hi,
Addressing some comments from Chris & Michel.
Thanks for your time,
Lionel Landwerlin (2):
drm/i915: drop one bit on the hw_id when using guc
drm/i915/perf: fix ctx_id read with GuC & ICL
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem_context.c | 15
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches
On Thu, May 31, 2018 at 10:20:54PM +0100, Chris Wilson wrote:
> Quoting Singh, Satyeshwar (2018-05-31 22:17:25)
> > Hi Chris,
> > Isn't this dependent upon the workload submitted to the GuC? Meaning we
> > have one workload that refused to be preempted (really long shader for
> > example) but it
On 01/06/18 20:24, Michel Thierry wrote:
On 6/1/2018 8:10 AM, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-06-01 10:52:14)
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by
Em Sex, 2018-05-25 às 11:32 -0700, James Ausmus escreveu:
> On Thu, May 24, 2018 at 04:42:37PM -0700, Paulo Zanoni wrote:
> > From: Manasi Navare
> >
> > For ICL, on Combo PHY the allowed max rates are:
> > - HBR3 8.1 eDP (DDIA)
> > - HBR2 5.4 DisplayPort (DDIB)
> > and for MG PHY/TC DDI Ports
Em Sex, 2018-05-25 às 08:52 -0700, Lucas De Marchi escreveu:
> From: Mahesh Kumar
>
> All connectors may not have best_encoder attached, so don't
> dereference
> encoder pointer for each connector.
>
> Fixes: c27e917e2bda (drm/i915/icl: add basic support for the ICL
> clocks)
> Signed-off-by:
Em Seg, 2018-05-21 às 17:25 -0700, Paulo Zanoni escreveu:
> Hi
>
> This series contains some more ICL patches that haven't seen the
> mailing list yet. While I'll definitely help re-review the patches
> not
> authored by me, please help me with the ones I can't review.
I just applied 7 patches
Em Sex, 2018-05-25 às 09:26 -0700, Lucas De Marchi escreveu:
> On Mon, May 21, 2018 at 05:25:41PM -0700, Paulo Zanoni wrote:
> > From: Manasi Navare
> >
> > This patch adds a proper HDMI DDI entry level for vswing
> > programming sequences on ICL.
> >
> > Spec doesn't specify any default for
Em Seg, 2018-05-07 às 11:46 +0300, Joonas Lahtinen escreveu:
> Ingo, do you prefer to merge through our tree with your ack?
Ping?
>
> Quoting Paulo Zanoni (2018-05-04 23:32:51)
> > ICL changes the registers and addresses to 64 bits.
> >
> > I also briefly looked at implementing an u64 version
Quoting Ville Syrjala (2018-06-01 18:00:30)
> From: Ville Syrjälä
>
> Pull the common plane+plane_state allocation into a small helper.
> Reduces the amount of boilerplate in the plane initialization
> functions.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
Quoting Ville Syrjala (2018-06-01 18:00:29)
> From: Ville Syrjälä
>
> No point in having each caller of intel_create_plane_state() initialize
> the scaler_id to -1. Instead just do it in intel_create_plane_state().
No tricks spotted.
> Previously we left scaler_id at 0 for pre-SKL platforms,
Quoting Ville Syrjala (2018-06-01 18:00:24)
> From: Ville Syrjälä
>
> We're currently not providing the possible_crtcs mask to
> drm_universal_plane_init() for primary/cursor planes. While that does
> work on account of drm_crtc_init_with_planes() filling those up
> for us, it's inconsisten with
Quoting Ville Syrjala (2018-06-01 18:00:24)
> From: Ville Syrjälä
>
> We're currently not providing the possible_crtcs mask to
> drm_universal_plane_init() for primary/cursor planes. While that does
> work on account of drm_crtc_init_with_planes() filling those up
> for us, it's inconsisten with
== Series Details ==
Series: drm/i915: Some plane init cleanups (rev3)
URL : https://patchwork.freedesktop.org/series/44104/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4272_full -> Patchwork_9174_full =
== Summary - WARNING ==
Minor unknown changes coming with
== Series Details ==
Series: drm/i915: Some plane init cleanups
URL : https://patchwork.freedesktop.org/series/44104/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4272_full -> Patchwork_9173_full =
== Summary - WARNING ==
Minor unknown changes coming with
On 6/1/2018 8:10 AM, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-06-01 10:52:14)
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen
On 6/1/2018 10:08 AM, Lionel Landwerlin wrote:
On 01/06/18 16:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-06-01 10:52:15)
+ /*
+* The LRCA is aligned to a page. As a result the
+* lower 12bits are always at 0 and
== Series Details ==
Series: drm/i915: Some plane init cleanups (rev3)
URL : https://patchwork.freedesktop.org/series/44104/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4272 -> Patchwork_9174 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: drm/i915: Some plane init cleanups (rev3)
URL : https://patchwork.freedesktop.org/series/44104/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
af017bc71198 drm/i915: Constify all plane_funcs structs
06b012de49a5 drm/i915: Populate possible_crtcs for
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Flush all writes before suspend
URL : https://patchwork.freedesktop.org/series/44096/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4272_full -> Patchwork_9172_full =
== Summary - WARNING ==
Minor
From: Ville Syrjälä
Let's try to stick a common naming pattern in all the plane init funcs.
v2: Rebase due to color_encoding/range props
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 84 ++--
1 file changed, 41 insertions(+), 43
From: Ville Syrjälä
There's not much point in following the primary vs. sprite split
for the SKL+ universal plane init code. The only difference is
of our own doing in the form of the .check_plane(). Let's make
a small exception for that little detail and otherwise share
the same code to
== Series Details ==
Series: drm/i915: Some plane init cleanups
URL : https://patchwork.freedesktop.org/series/44104/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4272 -> Patchwork_9173 =
== Summary - SUCCESS ==
No regressions found.
External URL:
From: Ville Syrjälä
Looks like we need a libdrm dep on intel_drv. Build fails for me on
Arch.
In file included from ../src/intel_device.c:51:
/usr/include/xf86drm.h:40:10: fatal error: drm.h: No such file or directory
#include
Signed-off-by: Ville Syrjälä
---
src/meson.build | 1 +
1 file
On 01/06/18 16:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-06-01 10:52:15)
+ /*
+* The LRCA is aligned to a page. As a result the
+* lower 12bits are always at 0 and reused in the
+*
== Series Details ==
Series: drm/i915: Some plane init cleanups
URL : https://patchwork.freedesktop.org/series/44104/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bb943e33dcbe drm/i915: Constify all plane_funcs structs
4f6d16bcf869 drm/i915: Populate possible_crtcs for
From: Ville Syrjälä
Use a more familiar naming pattern for our variables in the sprite plane
init function.
v2: Drop the redundant 'plane' from plane_formats and num_planes_formats
too
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 103
From: Ville Syrjälä
Let's try to stick a common naming pattern in all the plane init funcs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 86 ++--
1 file changed, 42 insertions(+), 44 deletions(-)
diff --git
From: Ville Syrjälä
No point in having each caller of intel_create_plane_state() initialize
the scaler_id to -1. Instead just do it in intel_create_plane_state().
Previously we left scaler_id at 0 for pre-SKL platforms, but I can't
see how initializing it to -1 always would cause any harm.
From: Ville Syrjälä
Untangle skl_plane_has_planar() into a more legible form.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
From: Ville Syrjälä
Pull the common plane+plane_state allocation into a small helper.
Reduces the amount of boilerplate in the plane initialization
functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 44 ---
From: Ville Syrjälä
There's not much point in following the primary vs. sprite split
for the SKL+ universal plane init code. The only difference is
of our own doing in the form of the .check_plane(). Let's make
a small exception for that little detail and otherwise share
the same code to
From: Ville Syrjälä
All SKL+ universal planes support the same set of formats (with the
exception of NV12 which we don't expose yet). Make the format lists
for primary and sprites the same.
And make the format list const while at it.
v2: Deal with the "planar" format lit as well
From: Ville Syrjälä
All CNL universal planes support horizontal mirroring. Currently
we expose the capability only for the primary plane. Expose it
for the overlay planes as well.
Cc: Joonas Lahtinen
Signed-off-by: Ville Syrjälä
Reviewed-by: Joonas Lahtinen
---
From: Ville Syrjälä
Plane scaling is not supported with specific pixel formats. Disallow
plane scaling when such a format is used. Currently the only such
pixel format we expose is C8, but in case we add more in the future
let's make it easy to deal with them.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
plane_funcs can be cosnt. Make them so.
v2: Rebase due to per-platforms plane_funcs
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
From: Ville Syrjälä
Another version of these cleansup. Last time there was some kind of smtp
fail when sending and patchwork got confused at the wonky threading. So
best to repost fully I thought. Additionally I had to resolve a lot of
rebase confilicts and I spotted a few NV12 related things I
From: Ville Syrjälä
We're currently not providing the possible_crtcs mask to
drm_universal_plane_init() for primary/cursor planes. While that does
work on account of drm_crtc_init_with_planes() filling those up
for us, it's inconsisten with what we're doing for sprite planes.
Let's just always
From: Ville Syrjälä
enum i9xx_plane_id namespace is not valid for any sprite plane,
so let's not even populate plane->i9xx_plane.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Flush all writes before suspend
URL : https://patchwork.freedesktop.org/series/44096/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4272 -> Patchwork_9172 =
== Summary - WARNING ==
Minor unknown
On Thu, May 31, 2018 at 09:13:12AM +0300, Jani Nikula wrote:
> On Wed, 30 May 2018, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The sprite code has a bunch of spaces where tabs should be used. Fix it
> > up.
>
> I guess the subject could be a little more specific; you aren't fixing
>
On Thu, May 31, 2018 at 04:20:24AM +, Srinivas, Vidya wrote:
> Thank you.
> Reviewed-By: Vidya Srinivas
Thanks. Series pushed to dinq.
>
> > -Original Message-
> > From: Ville Syrjala [mailto:ville.syrj...@linux.intel.com]
> > Sent: Tuesday, May 22, 2018 12:26 AM
> > To:
On Fri, Jun 01, 2018 at 01:29:12PM +0300, Mika Kahola wrote:
> On Tue, 2018-01-30 at 22:38 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Call the enum i9xx_plane_id variable i9xx_plane like we do elsewhere.
> >
> > Cc: Hans de Goede
>
> Reviewed-by: Mika Kahola
Thanks.
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Flush all writes before suspend
URL : https://patchwork.freedesktop.org/series/44096/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4271 -> Patchwork_9171 =
== Summary - FAILURE ==
Serious unknown
Quoting Lionel Landwerlin (2018-06-01 10:52:14)
> We currently using GuC as a proxy to the hardware. When Guc is used in
> such mode, it consumes the bit 20 of the hw_id to indicate that the
> workload was submitted by proxy.
>
> So far we probably haven't seen the issue because we need to
As we have already suspended the device, this should be a no-op except
for marking that all writes are indeed complete. The downside is that
we then have to walk all the lists of objects for what should be a no-op
(in some cases they will be mmio read to ensure the GGTT writes are
indeed flushed,
Let's not take any chances by using a shortcut to mark the objects as in
the CPU domain upon freezing (all pages will be written to disk and so
on restore all objects will start from the CPU domain). Currently, we
simply mark the objects as being in the CPU domain, bypassing the
flushes. Let's
Quoting Tvrtko Ursulin (2018-06-01 15:02:38)
>
> On 31/05/2018 19:51, Chris Wilson wrote:
> > In the next patch, we will begin processing the CSB from inside the
> > interrupt handler. This means that updating the execlists->port[] will
>
> The message that we will be processing CSB from irq
On 31/05/2018 19:51, Chris Wilson wrote:
In the next patch, we will begin processing the CSB from inside the
interrupt handler. This means that updating the execlists->port[] will
The message that we will be processing CSB from irq handler, here and in
following patch 5/11, doesn't seem to
== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL (rev2)
URL : https://patchwork.freedesktop.org/series/44043/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4269_full -> Patchwork_9169_full =
== Summary - WARNING ==
Minor unknown changes
Quoting Joonas Lahtinen (2018-06-01 13:56:56)
> On Fri, 2018-06-01 at 10:35 +0100, Chris Wilson wrote:
> > On resume, we have to rewrite all the PDE entries for gen7 ppgtts. If we
> > switch on full-ppgtt, there is then one address space with no PDE, the
> > GGTT. Currently under aliasing-ppgtt,
On 31/05/2018 19:51, Chris Wilson wrote:
We can avoid the mmio read of the CSB pointers after reset based on the
knowledge that the HW always start writing at entry 0 in the CSB buffer.
We need to reset our CSB head tracking after GPU reset (and on
sanitization after resume) so that we are
On 31/05/2018 19:51, Chris Wilson wrote:
As we want to be able to call i915_reset_engine and co from a softirq or
timer context, we need to be irqsafe at all timers. So we have to forgo
s/timers/times/
the simple spin_lock_irq for the full spin_lock_irqsave.
Signed-off-by: Chris Wilson
== Series Details ==
Series: drm/i915: Check intel_contexts to avoid one extra pointer chase
URL : https://patchwork.freedesktop.org/series/44077/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4269_full -> Patchwork_9168_full =
== Summary - FAILURE ==
Serious unknown
On Fri, 2018-06-01 at 10:35 +0100, Chris Wilson wrote:
> Let's not take any chances by using a shortcut to mark the objects as in
> the CPU domain upon freezing (all pages will be written to disk and so
> on restore all objects will start from the CPU domain). Currently, we
> simply mark the
On Fri, 2018-06-01 at 10:35 +0100, Chris Wilson wrote:
> As we have already suspended the device, this should be a no-op except
> for marking that all writes are indeed complete. The downside is that
> we then have to walk all the lists of objects for what should be a no-op
> (in some cases they
On Fri, 2018-06-01 at 10:35 +0100, Chris Wilson wrote:
> On resume, we have to rewrite all the PDE entries for gen7 ppgtts. If we
> switch on full-ppgtt, there is then one address space with no PDE, the
> GGTT. Currently under aliasing-ppgtt, the GGTT address space does have
> an associated ppgtt
Quoting Chris Wilson (2018-06-01 10:40:02)
> As we store the intel_context on the request (rq->hw_context), we can
> simply compare that against the local intel_context for the
> i915->kernel_context rather than using the rq->gem_context.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
== Series Details ==
Series: drm/i915: Check intel_contexts to avoid one extra pointer chase
URL : https://patchwork.freedesktop.org/series/44077/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4269 -> Patchwork_9170 =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: series starting with [1/6] drm/i915/gtt: Avoid calling non-existent
allocate_va_range
URL : https://patchwork.freedesktop.org/series/44076/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4269_full -> Patchwork_9167_full =
== Summary - FAILURE
On Tuesday 29 May 2018 11:35 PM, Ville Syrjälä wrote:
On Fri, May 18, 2018 at 02:54:53PM +0530, Ramalingam C wrote:
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL (rev2)
URL : https://patchwork.freedesktop.org/series/44043/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4269 -> Patchwork_9169 =
== Summary - FAILURE ==
Serious unknown changes coming
== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL (rev2)
URL : https://patchwork.freedesktop.org/series/44043/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: drop one bit on the hw_id when using guc
== Series Details ==
Series: drm/i915/perf: fix context filtering with GuC & ICL (rev2)
URL : https://patchwork.freedesktop.org/series/44043/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
46fbdfad6eee drm/i915: drop one bit on the hw_id when using guc
-:28: CHECK:SPACING:
== Series Details ==
Series: drm/i915: Check intel_contexts to avoid one extra pointer chase
URL : https://patchwork.freedesktop.org/series/44077/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4269 -> Patchwork_9168 =
== Summary - FAILURE ==
Serious unknown changes
Quoting Joonas Lahtinen (2018-06-01 11:19:07)
> On Thu, 2018-05-31 at 12:35 +0100, Chris Wilson wrote:
> > 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
On Tue, 2018-01-30 at 22:38 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Call the enum i9xx_plane_id variable i9xx_plane like we do elsewhere.
>
> Cc: Hans de Goede
Reviewed-by: Mika Kahola
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 8
> 1
Quoting Joonas Lahtinen (2018-06-01 11:21:43)
> On Thu, 2018-05-31 at 12:35 +0100, Chris Wilson wrote:
> > 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
On Tue, 2018-01-30 at 22:38 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We disable trickle feed whenever possible, except for the cursors
> on SNB/IVB. Let's try disabling it there too if for no other reason
> than consistency.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Ville
On Thu, 2018-05-31 at 12:35 +0100, Chris Wilson wrote:
> 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
On Thu, 2018-05-31 at 12:35 +0100, Chris Wilson wrote:
> 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
This asks for
On Thu, 2018-05-31 at 12:35 +0100, Chris Wilson wrote:
> 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
Quoting Mika Kuoppala (2018-06-01 11:05:18)
> Chris Wilson writes:
>
> > As we store the intel_context on the request (rq->hw_context), we can
> > simply compare that against the local intel_context for the
> > i915->kernel_context rather than using the rq->gem_context.
> >
> > Signed-off-by:
Chris Wilson writes:
> As we store the intel_context on the request (rq->hw_context), we can
> simply compare that against the local intel_context for the
> i915->kernel_context rather than using the rq->gem_context.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
>
== Series Details ==
Series: series starting with [1/6] drm/i915/gtt: Avoid calling non-existent
allocate_va_range
URL : https://patchwork.freedesktop.org/series/44076/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4269 -> Patchwork_9167 =
== Summary - FAILURE ==
We currently using GuC as a proxy to the hardware. When Guc is used in
such mode, it consumes the bit 20 of the hw_id to indicate that the
workload was submitted by proxy.
So far we probably haven't seen the issue because we need to allocate
1048576+ contexts to hit this issue. Still, we should
One thing we didn't really understand about the OA report is that the
ContextID field (dword 2) is copy of the context descriptor (dword 1).
On Gen8->10 and without using GuC we didn't notice the issue because
we only checked the 21bits of the ContextID field in the OA reports
which matches
Hi all,
A small v2 to make Michel/Oscar's life easier with the rebasing of ICL
patches.
Cheers,
Lionel Landwerlin (2):
drm/i915: drop one bit on the hw_id when using guc
drm/i915/perf: fix ctx_id read with GuC & ICL
drivers/gpu/drm/i915/i915_drv.h | 2 +
As we store the intel_context on the request (rq->hw_context), we can
simply compare that against the local intel_context for the
i915->kernel_context rather than using the rq->gem_context.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1 file
Let's not take any chances by using a shortcut to mark the objects as in
the CPU domain upon freezing (all pages will be written to disk and so
on restore all objects will start from the CPU domain). Currently, we
simply mark the objects as being in the CPU domain, bypassing the
flushes. Let's
On resume, we have to rewrite all the PDE entries for gen7 ppgtts. If we
switch on full-ppgtt, there is then one address space with no PDE, the
GGTT. Currently under aliasing-ppgtt, the GGTT address space does have
an associated ppgtt and so the restore works just fine. We would have a
similar
As we have already suspended the device, this should be a no-op except
for marking that all writes are indeed complete. The downside is that
we then have to walk all the lists of objects for what should be a no-op
(in some cases they will be mmio read to ensure the GGTT writes are
indeed flushed,
Let's see if we have all the kinks worked out and full-ppgtt now works
reliably on Haswell. If we can let userspace have full control over
their own ppgtt, it makes softpinning far more effective, in turn making
GPU dispatch far more efficient and more secure (due to better mm
segregation).
On hsw and older, we do not need to allocate the ppgtt on the fly and so
ppgtt->allocate_va_range() is NULL. Fixup ppgtt_bind_vma not to call it,
in that case!
v2: PIN_UPDATE still exists.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 34 ++---
1
Let's see if we have all the kinks worked out and full-ppgtt now works
reliably on gen7. If we can let userspace have full control over
their own ppgtt, it makes softpinning far more effective, in turn making
GPU dispatch far more efficient and more secure (due to better mm
segregation).
Chris Wilson writes:
> glk is failing gem_tiled_blits which is very odd as it doesn't use
> fencing and so the tiling is all internal to the GPU. From the small
> number of examples seen so far, it looks like just a single bit is being
> flipped. Let's dump some values to see if it there is a
Chris Wilson writes:
> Now that we always switch to the kernel context upon idling, we can
> make that assertion.
>
> References: 4dfacb0bcbee ("drm/i915: Switch to kernel context before idling
> at runtime")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
>
On Wed, 2018-01-31 at 16:37 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use MCURSOR_ instead of CURSOR_ as the prefix for the non-845/865
> cursor defines consistently, and move the pipe CSC enable bit next
> to the other non-845/865 cursor defines.
>
> v2: Take care of gvt uses as
On Tue, 2018-01-30 at 22:38 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Like we do for encoder let's make the plane->get_hw_state() return
> the pipe to which the plane is currently attached. We don't currently
> allow planes to move between the pipes, but perhaps one day we will.
>
>
On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson
> Signed-off-by: Neil
== Series Details ==
Series: Add ChromeOS EC CEC Support (rev8)
URL : https://patchwork.freedesktop.org/series/43162/
State : failure
== Summary ==
Applying: media: cec-notifier: Get notifier by device and connector name
Applying: drm/i915: hdmi: add CEC notifier to intel_hdmi
Applying: mfd:
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
Acked-by: Hans Verkuil
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
---
include/linux/mfd/cros_ec_commands.h | 81
1 file
Hi All,
The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
through it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device
1 - 100 of 105 matches
Mail list logo
