The patch looks ok to me.
On Wed, 2019-03-06 at 18:14 -0800, Aditya Swarup wrote:
> Setting the pixel rounding bit to 1 in PIPE_CHICKEN register allows
> to passthrough FB pixels unmodified across pipe. This fixes the
> failures
> for DP link layer compliance tests 4.4.1.1, 4.4.1.2 & 4.4.1.3.
> (L
On 06/03/2019 23:08, Carlos Santa wrote:
On Mon, 2019-02-25 at 13:34 +, Tvrtko Ursulin wrote:
On 21/02/2019 02:58, Carlos Santa wrote:
From: Michel Thierry
Users/tests relying on the total reset count will start seeing a
smaller
number since most of the hangs can be handled by engine res
Hi,
Here's gvt-fixes for 5.1-rc1. This contains fixes for newer
version of Windows driver, e.g fix parser for MI_FLUSH_DW and
font render error. And with other stable fix in error path,
fix unexpected workload submission when vGPU idle, etc. Details
are below.
Thanks
--
The following changes sin
== Series Details ==
Series: drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev2)
URL : https://patchwork.freedesktop.org/series/57619/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5713_full -> Patchwork_12400_full
=
== Series Details ==
Series: drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev2)
URL : https://patchwork.freedesktop.org/series/57619/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12400
===
== Series Details ==
Series: drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev2)
URL : https://patchwork.freedesktop.org/series/57619/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ca509862fd1a drm/i915/icl: Fix CRC mismatch error for DP link layer complian
On Wed, 2019-03-06 at 10:07 -0800, Rodrigo Vivi wrote:
> On Tue, Mar 05, 2019 at 01:46:56PM -0800, Anusha wrote:
> > From: Anusha Srivatsa
> >
> > Comet Lake PCH is based off of Cannon Point(CNP).
> > Add PCI ID for Comet Lake PCH.
> >
> > v2: Code cleanup (DK)
> >
> > Cc: Dhinakaran Pandiyan
Setting the pixel rounding bit to 1 in PIPE_CHICKEN register allows
to passthrough FB pixels unmodified across pipe. This fixes the failures
for DP link layer compliance tests 4.4.1.1, 4.4.1.2 & 4.4.1.3.
(Lineage #1605353570)
v2: This is also needed to fix failing IGT test case kms_cursor_crc on
I
== Series Details ==
Series: Polish DRAM information readout code (rev6)
URL : https://patchwork.freedesktop.org/series/57213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5713_full -> Patchwork_12398_full
Summary
---
On Mon, 2019-02-25 at 13:34 +, Tvrtko Ursulin wrote:
> On 21/02/2019 02:58, Carlos Santa wrote:
> > From: Michel Thierry
> >
> > Users/tests relying on the total reset count will start seeing a
> > smaller
> > number since most of the hangs can be handled by engine reset.
> > Note that if res
Hi, I was working on adding the writeback support to VKMS; as a result,
I was using the Liviu’s patchset to validate my implementation [1].
However, I consistently failed to pass the requirements in
igt_display_require(); more specifically, I couldn't pass this test:
igt_skip("No KMS driver or no
On 03/01, Maarten Lankhorst wrote:
> Convert vkms to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding destroy_state(),
> call it directly for freeing the old state.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohamm
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs (rev4)
URL : https://patchwork.freedesktop.org/series/56059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5712_full -> Patchwork_12397_full
== Series Details ==
Series: drm/i915/ddi: Fix default eDP detection on port A
URL : https://patchwork.freedesktop.org/series/57663/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12399
Summary
---
*
On 03/06, Maarten Lankhorst wrote:
> Op 04-03-2019 om 16:32 schreef Rodrigo Siqueira:
> > The function fb_is_bound() mix integer value with booleans for handling
> > the return value. This commit standardizes the return value of
> > fb_is_bound() for using only booleans.
> >
> > Signed-off-by: Rodr
Hi Liviu,
I’m using your patchset to guide my implementation of writeback in the
VKMS, so, first of all, thanks :)
During my work, I noticed that you’re setting the drmSetClientCap()
before drmModeGetResources() which make the writeback capability
‘invisible’ for drmModeGetResources(). I made the
== Series Details ==
Series: Polish DRAM information readout code (rev6)
URL : https://patchwork.freedesktop.org/series/57213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12398
Summary
---
**SUCCE
On Wed, Mar 06, 2019 at 09:31:01PM +0200, Gwan-gyeong Mun wrote:
> All of the link bandwidth and Data M/N calculations were assumed a bpp as
> RGB format. But When we are using YCbCr 4:2:0 output format on DP,
> we should change bpp calculations as YCbCr 4:2:0 format.
> The pipe_bpp value was assum
== Series Details ==
Series: Polish DRAM information readout code (rev6)
URL : https://patchwork.freedesktop.org/series/57213/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Store DIMM rank information as a number
-O:drivers/gpu/drm/i915/i915
== Series Details ==
Series: Polish DRAM information readout code (rev6)
URL : https://patchwork.freedesktop.org/series/57213/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
79f39cc66d09 drm/i915: Store DIMM rank information as a number
574621760038 drm/i915: Extract functions t
On Wed, Mar 06, 2019 at 09:30:57PM +0200, Gwan-gyeong Mun wrote:
> This patch checks a support of YCBCR420 outputs on an encoder level.
> If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
> output, else it continues with RGB output mode.
> It set output_format to INTEL_OUTP
We rely on VBT DDI port info for eDP detection on GEN9 platforms and
above. This breaks GEN9 platforms which don't have VBT because port A
eDP now defaults to false. Fix this by defaulting to true when VBT is
missing.
Fixes: commit a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP
de
From: Ville Syrjälä
We'll need information about the memory configuration on cnl+ too.
Extend the code to parse the slightly changed register layout.
v2: Document what cnl_get_dimm_size() returns (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c
From: Ville Syrjälä
We'll need to know the memory type in the system for some
bandwidth limitations and whatnot. Let's read that out on
gen9+.
v2: Rebase
v3: Fix the copy paste fail in the BXT bit definitions (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i9
From: Ville Syrjälä
Rename the dimm info structs for clarity.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 18 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gp
From: Ville Syrjälä
Remove the pointless zero initialization of bunch of things
(the thing is kzalloc()ed).
Also throw out the mostly useless on-stack string. I think
it'll be clear enough from the logs that 0 means unknown.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/g
From: Ville Syrjälä
The BXT DUNIT register tells us the size of each DRAM device
in Gb. We want to report the size of the whole DIMM in GB, so
that it matches how we report it for non-LP platforms.
v2: Deobfuscate the math (Chris)
s/GB/GBIT/ in the register bit definitions (Jani)
Reviewed-b
From: Ville Syrjälä
Life will be easier later if we have the ranks stored
as a bare number.
v2: s/%d/%u/ all over (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 92 +++--
drivers/gpu/drm/i915/i915_drv.h | 11 ++--
From: Ville Syrjälä
Make the code less repetitive by extracting a few small helpers.
v2: Squash in the switch removal for skl_get_dimm_ranks()
(it got misplaced in a rebase accident)
Document what skl_get_dimm_size() returns (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Decouple intel_is_dram_symmetric() from the raw register values
by comparing just the dram_channel_info structs.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 28
1 file changed, 12 insertions(+), 1
From: Ville Syrjälä
Pass the dimm struct to skl_is_16gb_dimm() rather than passing each
value separately. And let's replace the hardcoded set of values with
some simple arithmetic.
Also fix the byte vs. bit inconsistency in the debug message,
and polish the wording otherwise as well.
v2: Deobfu
From: Ville Syrjälä
The BXT code for parsing DIMM info works for GLK too. Let's
dig it out even if we might not need it immediately.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Ville Syrjälä
Polish the bxt DIMM parsing by extracting a few small helpers.
v2: Use struct dram_dimm_info
v3: Document what bxt_get_dimm_size() returns (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 94 ++-
From: Ville Syrjälä
Reduce the code duplication a bit by sharing the same
code for parsing both DIMMs on a channel.
v2: s/%d/%u/ all over (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 44 ++---
1 file changed, 2
From: Ville Syrjälä
Addressed Jani's review comments (thanks!). Should be good to land once
CI gives the green light.
Ville Syrjälä (12):
drm/i915: Store DIMM rank information as a number
drm/i915: Extract functions to derive SKL+ DIMM info
drm/i915: Polish skl_is_16gb_dimm()
drm/i915: E
On Wed, Mar 06, 2019 at 09:00:01PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2019 at 10:55:01AM -0800, Lucas De Marchi wrote:
> > On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote:
> > >On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote:
> > >> On Wed, Mar 06, 2019 at 0
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs (rev4)
URL : https://patchwork.freedesktop.org/series/56059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5712 -> Patchwork_12397
Summ
On Wed, 06 Mar 2019, Ville Syrjälä wrote:
> On Tue, Mar 05, 2019 at 06:16:57PM +0200, Jani Nikula wrote:
>> On Mon, 25 Feb 2019, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > We'll need information about the memory configuration on cnl+ too.
>> > Extend the code to parse the slightly c
== Series Details ==
Series: drm/i915/selftests: Canonicalise gen8 addresses (rev2)
URL : https://patchwork.freedesktop.org/series/57645/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5712_full -> Patchwork_12396_full
Summa
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 fi
SDP VSC Header and Data Block follow DP 1.4a spec, section 2.2.5.7.5,
chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
include/drm/drm_dp_helper.h | 17 +
1 file changed, 17 insertions(+)
diff --g
All of the link bandwidth and Data M/N calculations were assumed a bpp as
RGB format. But When we are using YCbCr 4:2:0 output format on DP,
we should change bpp calculations as YCbCr 4:2:0 format.
The pipe_bpp value was assumed RGB format, therefore, it was multiplied
with 3. But YCbCr 4:2:0 requi
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
This patches are RFC patches that add a VSC structure for handling
Pixel Encodi
On Tue, Mar 05, 2019 at 06:16:57PM +0200, Jani Nikula wrote:
> On Mon, 25 Feb 2019, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We'll need information about the memory configuration on cnl+ too.
> > Extend the code to parse the slightly changed register layout.
> >
> > Signed-off-by: Vil
-Original Message-
From: Chris Wilson
Sent: Wednesday, March 6, 2019 1:08 AM
To: Wajdeczko, Michal ; Sundaresan, Sujaritha
; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Fixing error code for WOPCM
initialization
Quoting Michal Wajdeczko (2019-03-
On 3/6/19 1:08 AM, Chris Wilson wrote:
Quoting Michal Wajdeczko (2019-03-06 09:01:09)
On Wed, 06 Mar 2019 09:45:17 +0100, Chris Wilson
Now doing an if (i915_error_injected() && !err) err = -EINVAL; makes
sense to catch places where we've eaten that error and so breaking the
test.
This will no
On Wed, Mar 06, 2019 at 10:55:01AM -0800, Lucas De Marchi wrote:
> On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote:
> >On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote:
> >> On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote:
> >> >On Wed, Mar 06, 2019 at 02:
On Wed, Mar 06, 2019 at 08:01:05PM +0200, Ville Syrjälä wrote:
On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote:
On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote:
> On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote:
> >On Wed, Mar 06, 2019 at 02:55:58PM +0
On Wed, Mar 06, 2019 at 05:34:14PM +0200, Jani Nikula wrote:
> Iterate over child devices instead of ports in parse_ddi_ports() to
> initialize dri_port_info. We'll eventually need to decide some stuff
> based on the child device order, which may be different from the port
> order.
>
> As a bonus,
On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote:
On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote:
On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote:
>On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote:
>> Quoting Ville Syrjälä (2019-03-06 14:52
On Tue, Mar 05, 2019 at 01:46:56PM -0800, Anusha wrote:
> From: Anusha Srivatsa
>
> Comet Lake PCH is based off of Cannon Point(CNP).
> Add PCI ID for Comet Lake PCH.
>
> v2: Code cleanup (DK)
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gp
On Tue, Mar 05, 2019 at 01:46:55PM -0800, Anusha wrote:
> From: Anusha Srivatsa
>
> Comet Lake is a Intel Processor containing Gen9
> Intel HD Graphics. This patch adds the initial set of
> PCI IDs. Comet Lake comes off of Coffee Lake - adding
> the IDs to Coffee Lake ID list.
>
> More support a
On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote:
> > On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote:
> > >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote:
> > >> Quoting Ville Syrjälä (2019-
On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote:
> > On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote:
> > >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote:
> > >> Quoting Ville Syrjälä (2019-
On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote:
> On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote:
> >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote:
> >> Quoting Ville Syrjälä (2019-03-06 14:52:11)
> >> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris
On Wed, Mar 06, 2019 at 05:34:16PM +0200, Jani Nikula wrote:
> The main benefit is improved debug logging of the ports also on VLV.
The fact that this causes VLV to start using the AUX/DDC pins from VBT
needs to be called out in the commit msg.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gp
Quoting Patchwork (2019-03-06 17:38:42)
> * igt@i915_selftest@live_contexts:
> - fi-icl-u3: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569]
Still no luck with that fix, then?
It's just the one fix actually.
-Chris
___
Intel-gfx mailing
On Wed, Mar 06, 2019 at 05:34:15PM +0200, Jani Nikula wrote:
> For the time being this is only for completeness and better debug
> logging of DSI ports.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 14 --
> 2 f
On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote:
On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote:
Quoting Ville Syrjälä (2019-03-06 14:52:11)
> On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2019-03-05 19:29:05)
> > > From: Vil
== Series Details ==
Series: drm/i915/selftests: Canonicalise gen8 addresses (rev2)
URL : https://patchwork.freedesktop.org/series/57645/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5712 -> Patchwork_12396
Summary
---
Quoting Matthew Auld (2019-03-06 17:05:47)
> On 06/03/2019 14:25, Chris Wilson wrote:
> > Split the plain old shmem object into its own file to start decluttering
> > i915_gem.c
> >
> > Signed-off-by: Chris Wilson
>
> [snip]
>
> > +
> > +const struct drm_i915_gem_object_ops i915_gem_shmem_ops =
On 06/03/2019 14:25, Chris Wilson wrote:
Split the plain old shmem object into its own file to start decluttering
i915_gem.c
Signed-off-by: Chris Wilson
[snip]
+
+const struct drm_i915_gem_object_ops i915_gem_shmem_ops = {
+ .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
+
== Series Details ==
Series: drm/i915/bios: ddi port parsing changes
URL : https://patchwork.freedesktop.org/series/57651/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5712 -> Patchwork_12395
Summary
---
**FAILURE**
Quoting Matthew Auld (2019-03-06 16:23:19)
> On 06/03/2019 14:25, Chris Wilson wrote:
> > Currently the code for manipulating the pages on an object is still
> > residing in i915_gem.c, move it to i915_gem_object.c
> >
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > ---
> > drivers
On 06/03/2019 14:25, Chris Wilson wrote:
Currently the code for manipulating the pages on an object is still
residing in i915_gem.c, move it to i915_gem_object.c
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Makefile | 3 +-
.../gpu/drm/i915/{ =>
== Series Details ==
Series: series starting with [01/43] drm/i915/selftests: Canonicalise gen8
addresses
URL : https://patchwork.freedesktop.org/series/57646/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5711 -> Patchwork_12394
==
== Series Details ==
Series: drm/i915/bios: ddi port parsing changes
URL : https://patchwork.freedesktop.org/series/57651/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/bios: iterate over child devices to initialize ddi_port_info
-drivers/gpu
On 06/03/2019 14:25, Chris Wilson wrote:
Declutter i915_gem.h by moving the ioctl API into its own header.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org
For igt_vm_isolation, we write into the whole 48b address space, and not
just our usual low 4G of global GTT. For these MI operations, play safe
and ensure we use the canonical address form.
v2: Leave original offset unmolested as we use that for our CPU pointer
offset
Signed-off-by: Chris Wilson
On 06/03/2019 14:51, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-06 14:43:13)
On 06/03/2019 14:24, Chris Wilson wrote:
Introduce a mutex to start locking the HW contexts independently of
struct_mutex, with a view to reducing the coarse struct_mutex. The
intel_context.pin_mutex is used
On 06/03/2019 14:25, Chris Wilson wrote:
For convenience in avoiding inline spaghetti, keep the type definition
as a separate header.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
h
Quoting Patchwork (2019-03-06 15:42:32)
> == Series Details ==
>
> Series: drm/i915/selftests: Canonicalise gen8 addresses
> URL : https://patchwork.freedesktop.org/series/57645/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5711 -> Patchwork_12393
>
== Series Details ==
Series: drm/i915/selftests: Canonicalise gen8 addresses
URL : https://patchwork.freedesktop.org/series/57645/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5711 -> Patchwork_12393
Summary
---
**F
For the time being this is only for completeness and better debug
logging of DSI ports.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 14 --
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i
The main benefit is improved debug logging of the ports also on VLV.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 9beff569b010..0
Some prep work for future changes which will be easier with ddi port info being
initialized in child device order instead of port order.
BR,
Jani.
Jani Nikula (3):
drm/i915/bios: iterate over child devices to initialize ddi_port_info
drm/i915/bios: parse dsi devices in parse_ddi_ports()
dr
Iterate over child devices instead of ports in parse_ddi_ports() to
initialize dri_port_info. We'll eventually need to decide some stuff
based on the child device order, which may be different from the port
order.
As a bonus, this allows better abstractions for e.g. dvo port mapping.
There's a su
On Tue, Mar 05, 2019 at 09:13:39PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/i915: Do not temporarily disable
> the DPLL on i830
> URL : https://patchwork.freedesktop.org/series/57598/
> State : failure
>
> == Summary ==
>
> CI Bug Log - chan
== Series Details ==
Series: series starting with [01/43] drm/i915/selftests: Canonicalise gen8
addresses
URL : https://patchwork.freedesktop.org/series/57646/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/selftests: Canonicalise gen8 addres
On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2019-03-06 14:52:11)
> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2019-03-05 19:29:05)
> > > > From: Ville Syrjälä
> > > >
> > > > At some point people have sta
== Series Details ==
Series: series starting with [01/43] drm/i915/selftests: Canonicalise gen8
addresses
URL : https://patchwork.freedesktop.org/series/57646/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
38853354b213 drm/i915/selftests: Canonicalise gen8 addresses
9afdcdabf8
== Series Details ==
Series: series starting with [1/2] drm/i915/dp: deconflate PPS unlock from
divisor register (rev3)
URL : https://patchwork.freedesktop.org/series/57579/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5708_full -> Patchwork_12392_full
==
== Series Details ==
Series: drm/i915: Pass around the intel_context
URL : https://patchwork.freedesktop.org/series/57635/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5708_full -> Patchwork_12391_full
Summary
---
*
Quoting Ville Syrjälä (2019-03-06 14:52:11)
> On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2019-03-05 19:29:05)
> > > From: Ville Syrjälä
> > >
> > > At some point people have started to assume that
> > > pipe_offsets[] & co. are only populated for pipe
On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-03-05 19:29:05)
> > From: Ville Syrjälä
> >
> > At some point people have started to assume that
> > pipe_offsets[] & co. are only populated for pipes and whatnot
> > that actually exist. That is in fact n
Quoting Tvrtko Ursulin (2019-03-06 14:43:13)
>
> On 06/03/2019 14:24, Chris Wilson wrote:
> > Introduce a mutex to start locking the HW contexts independently of
> > struct_mutex, with a view to reducing the coarse struct_mutex. The
> > intel_context.pin_mutex is used to guard the transition to an
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that w
On 06/03/2019 14:24, Chris Wilson wrote:
Introduce a mutex to start locking the HW contexts independently of
struct_mutex, with a view to reducing the coarse struct_mutex. The
intel_context.pin_mutex is used to guard the transition to and from being
pinned on the gpu, and so is required before s
Chris Wilson writes:
> For igt_vm_isolation, we write into the whole 48b address space, and not
> just our usual low 4G of global GTT. For these MI operations, play safe
> and ensure we use the canonical address form.
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Mika Kuoppala
> ---
On 06/03/2019 14:24, Chris Wilson wrote:
In preparation for an ever growing number of engines and so ever
increasing static array of HW contexts within the GEM context, move the
array over to an rbtree, allocated upon first use.
Unfortunately, this imposes an rbtree lookup at a few frequent cal
On 06/03/2019 14:24, Chris Wilson wrote:
If we place a pointer to the engine specific intel_context_ops in the
engine itself, we can assign the ops pointer on initialising the
context, and then rely on it being set. This simplifies the code in
later patches.
Signed-off-by: Chris Wilson
---
d
Chris Wilson writes:
> Quoting Tvrtko Ursulin (2019-03-05 18:13:34)
>>
>> intel_engine.h in 3...2...1.. ;)
>
> As soon as we have a good name for the legacy submission method. At the
> moment, my favorites are:
> gen2_submission.c / legacy_submission.c (actually that's winning again)
> gen8_subm
We can no longer assume execution ordering, and in particular we cannot
assume which context will execute last. One side-effect of this is that
we cannot determine if the kernel-context is resident on the GPU, so
remove the routines that claimed to do so.
Signed-off-by: Chris Wilson
---
drivers/
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the user level the context often
represents a singl
For use in the next patch, if we track which engines have been used by
the HW, we can reduce the work required to flush our state off the HW to
those engines.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 +--
drivers/
To facilitate the next patch to allow preemptible kernels not to incur
the wrath of hangcheck, we need to ensure that we can still suspend and
shutdown. That is we will not be able to rely on hangcheck to terminate
a blocking kernel and instead must manually do so ourselves. The
advantage is that w
If we place a pointer to the engine specific intel_context_ops in the
engine itself, we can assign the ops pointer on initialising the
context, and then rely on it being set. This simplifies the code in
later patches.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c |
1 - 100 of 174 matches
Mail list logo
