On Mon, 3 Jun 2019 15:19:13 +
"Ser, Simon" wrote:
> On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote:
> > It's definitely a very suboptimal situation. Not sure there's a good way
> > out. The trouble here is that i915 ended up configuring crtc/connectors
> > differently than -modesetti
On Mon, Jun 03, 2019 at 09:43:59PM +0300, Jani Nikula wrote:
> On Sat, 01 Jun 2019, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2019-05-31 23:24:07)
> >> Separate the display PM from the PCI-level runtime PM.
> >> I'll follow this up with v2 of the rpm encapsulation series [1], but
> >
Quoting Imre Deak (2019-06-04 08:12:22)
> On Mon, Jun 03, 2019 at 09:43:59PM +0300, Jani Nikula wrote:
> > On Sat, 01 Jun 2019, Chris Wilson wrote:
> > > Quoting Daniele Ceraolo Spurio (2019-05-31 23:24:07)
> > >> Separate the display PM from the PCI-level runtime PM.
> > >> I'll follow this up wi
== Series Details ==
Series: series starting with [01/15] drm/i915: Make the semaphore saturation
mask global
URL : https://patchwork.freedesktop.org/series/61524/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6182_full -> Patchwork_13161_full
Measure the baseline latency between contexts in order to directly
compare that with the additional cost of preemption.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 230 ++
1 file changed, 230 insertions(+)
diff --git a/tests/i915/gem_exec_late
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 81 +++
1 file changed, 81 insertions(+)
diff --git a/tests/i915/gem_exec_latency.c b/tests/i915/gem_exec_latency.c
index e88fbbc6a..fd4ceb4d6 100644
--- a/tests/i915/gem_exec_latency.c
+++ b/tests/i9
== Series Details ==
Series: drm/i915/gtt: Replace struct_mutex serialisation for allocation
URL : https://patchwork.freedesktop.org/series/61533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6182_full -> Patchwork_13162_full
==
On 29/05/2019 14:24, Chris Wilson wrote:
Appease static analysers by making sure subslice always have a value.
drivers/gpu/drm/i915//gt/intel_engine_cs.c:971 intel_sseu_fls_subslice() error:
uninitialized symbol 'subslice'.
There's also the nagging question of whether that fls() is off-by-one.
Quoting Xiaolin Zhang (2019-06-03 07:02:44)
> +static void gen8_ppgtt_clear_4lvl_pv(struct i915_address_space *vm,
> + u64 start, u64 length)
> +{
> + struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
> + struct i915_pml4 *pml4 = &ppgtt->pml4;
> +
Den 31.05.2019 16.01, skrev Noralf Trønnes:
> struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
> use that directly instead and attach it as a modeset array onto
> drm_client_dev. drm_fb_helper will use this array to store its modesets
> which means it will always initialize
== Series Details ==
Series: drm/i915/dp: Correctly advertise HBR3 for GEN11+
URL : https://patchwork.freedesktop.org/series/61546/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6182_full -> Patchwork_13164_full
Summary
---
Allow reuse of the fault-handling code in preparation for having
multiple fault handlers depending on the mmaping type and backing
storage.
Cc: Matthew Auld
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 208 ++--
Fixes the following warnings:
./include/drm/drm_mode_config.h:841: warning: Incorrect use of
kernel-doc format: * hdr_output_metadata_property: Connector
property containing hdr
./include/drm/drm_mode_config.h:918: warning: Function parameter or member
'hdr_output_metadata_property' not d
Quoting Abdiel Janulgue (2019-06-04 11:37:23)
> Allow reuse of the fault-handling code in preparation for having
> multiple fault handlers depending on the mmaping type and backing
> storage.
>
> Cc: Matthew Auld
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
>
> Signed-off-by: Abdiel Janulgue
> --
On 06/04/2019 02:00 PM, Chris Wilson wrote:
>> +
>> + /* Access to snoopable pages through the GTT is incoherent. */
>> + if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(dev_priv)) {
>
> And that is very, very specific to one path.
>
Oops, yep that should be gtt-fault specific
== Series Details ==
Series: drm/i915: Split out GTT fault handler to make it generic
URL : https://patchwork.freedesktop.org/series/61573/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6184 -> Patchwork_13165
Summary
-
Quoting Chris Wilson (2019-06-03 20:11:30)
> Instead of relying on the caller holding struct_mutex across the
> allocation, push the allocation under a tree of spinlocks stored inside
> the page tables. Not only should this allow us to avoid struct_mutex
> here, but it will allow multiple users to
Quoting Joonas Lahtinen (2019-06-04 12:37:03)
> Quoting Chris Wilson (2019-06-03 20:11:30)
> > Instead of relying on the caller holding struct_mutex across the
> > allocation, push the allocation under a tree of spinlocks stored inside
> > the page tables. Not only should this allow us to avoid str
Quoting Chris Wilson (2019-05-31 19:11:28)
> We only need to flush the object once prior to starting the partial
> tiling test as inside the test we explicitly maintain coherency.
>
> Signed-off-by: Chris Wilson
Checks out.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
Quoting Chris Wilson (2019-05-31 19:11:29)
> As the fence registers are not part of the engine powerwells, we do not
> need to fiddle with forcewake in order to update a fence. Avoid using
> the heavyweight debug checking normal mmio writes as the checking
> dominates the selftest runtime and is su
Quoting Chris Wilson (2019-05-31 19:11:30)
> As the GTT is outside of the powerwell, we can simplify flushing the
> GGTT writes by using an unchecked mmio write and post.
>
> Signed-off-by: Chris Wilson
Ditto for s/unc/uncore/
Reviewed-by: Joonas Lahtinen
Regards, Joonas
_
We only need to flush the object once prior to starting the partial
tiling test as inside the test we explicitly maintain coherency.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 21 ---
1 file changed, 9 insertions(
As the fence registers are not part of the engine powerwells, we do not
need to fiddle with forcewake in order to update a fence. Avoid using
the heavyweight debug checking normal mmio writes as the checking
dominates the selftest runtime and is superfluous!
In the process, retire the I915_WRITE()
As the GTT is outside of the powerwell, we can simplify flushing the
GGTT writes by using an unchecked mmio write and post.
v2: s/unc/uncore/
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 20
1 file changed, 12 insertion
If we have to drop the seqcount & rcu lock to perform a krealloc, we
have to restart the loop. In doing so, be careful not to lose track of
the already acquired exclusive fence.
Fixes: fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu()
after writes") #v4.10
Signed-off-by: Chris W
On Mon, Jun 03, 2019 at 02:58:57PM +0100, Chris Wilson wrote:
> We need to mark the output polling as disabled to prevent concurrent
> irqs from queuing new work as shutdown the probe -- causing that work to
> execute after we have freed the structs:
>
> <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_
Am 04.06.19 um 14:39 schrieb Chris Wilson:
> If we have to drop the seqcount & rcu lock to perform a krealloc, we
> have to restart the loop. In doing so, be careful not to lose track of
> the already acquired exclusive fence.
>
> Fixes: fedf54132d24 ("dma-buf: Restart reservation_object_get_fences
If we have to drop the seqcount & rcu lock to perform a krealloc, we
have to restart the loop. In doing so, be careful not to lose track of
the already acquired exclusive fence.
Fixes: fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu()
after writes") #v4.10
Signed-off-by: Chris W
On Mon, Jun 03, 2019 at 02:49:40PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
> use before encoder_type is set. This caused GEN11+ to incorrectly strip
> HBR3 from source rates. Move intel_dp_set_source_
If we have to drop the seqcount & rcu lock to perform a krealloc, we
have to restart the loop. In doing so, be careful not to lose track of
the already acquired exclusive fence.
Fixes: fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu()
after writes") #v4.10
Signed-off-by: Chris W
On Tue, Jun 04, 2019 at 03:51:58PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 03, 2019 at 02:49:40PM -0700, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood
> >
> > intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
> > use before encoder_type is set. This caused GEN11+
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
Signed-off-by: Lionel Landwerlin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 49 ++-
include/uapi/drm/i915_drm.h | 44 +++--
2 f
Reporting this version will help application figure out what level of
the support the running kernel provides.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
include/uapi/drm/i915_drm.h | 21 +
2 files changed, 24 insertions(+)
diff --git
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
Signed-off-by: Lionel Landwerlin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 270 ++
drivers/gpu/drm/i915/i915_drv.c | 4 +-
include/uapi/drm/i915_drm
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
Hi all,
This is a pretty big update following v2.
The first big change is to drop the HW arbitration usage in favor of a
software mechanism using a special priority in the scheduler.
The second is a rework of the uAPI. Since we have a couple of execbuf
uAPI changes for this series (VK_INTEL_perf
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v
Quoting Lionel Landwerlin (2019-06-04 14:11:35)
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 2e33a9b4eae7..e0071e44de3d 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -366,9 +366,16 @@ struct perf_open_p
Quoting Lionel Landwerlin (2019-06-04 14:11:36)
> We're planning to use this for a couple of new feature where we need
> to provide additional parameters to execbuf.
See struct i915_user_extension. Might as well try and share common code.
-Chris
___
Inte
Quoting Lionel Landwerlin (2019-06-04 14:11:38)
> list_add_tail(&rq->client_link, &rq->file_priv->mm.request_list);
> }
>
> +static int eb_oa_config(struct i915_execbuffer *eb)
> +{
> + struct i915_vma *oa_vma;
> + int err;
> +
> + if (!eb->oa_config)
> +
On Mon, Jun 03, 2019 at 04:33:19PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 03, 2019 at 10:09:30AM +, Vasilev, Oleg wrote:
> > Hi,
> >
> > Can this be reviewed, please?
>
> It looks good to me. But the test results are horrible, due to the ext4
> fail I think. I've hit retest to get new resu
Quoting Lionel Landwerlin (2019-06-04 14:11:39)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index ed19f4e53d31..4046f045408b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -683,6 +683,12 @@ static
On Fri, May 17, 2019 at 10:31:19PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pass around intel_atomic_state rather than drm_atomic_state.
> This avoids some extra casts and annoing aliasing variables.
>
> Signed-off-by: Ville Syrjälä
> ---
Series pushed with Maarten's irc rb. Thank
On 04/06/2019 16:40, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-06-04 14:11:38)
list_add_tail(&rq->client_link, &rq->file_priv->mm.request_list);
}
+static int eb_oa_config(struct i915_execbuffer *eb)
+{
+ struct i915_vma *oa_vma;
+ int err;
+
+ if (!eb-
From: Ville Syrjälä
It's a bit silly to go through intel_dp.c to assign the
prepare_link_train vfunc for ddi platforms when we can just
assign it directly from intel_ddi.c.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 5 -
drivers/gpu/drm/i915/intel_ddi.h | 1 -
driv
From: Ville Syrjälä
intel_dp_link_down() is static and it's only called from the pre-ddi
DP functions, so having a WARN_ON(HAS_DDI) in there is quite pointless.
Remove it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/dri
The HW completion flag for the TBT AUX power well enabling/disabling
gets stuck if the firmware tears down the TBT DP tunnel before the
completion.
We shouldn't complain about the timeout, since it's expected to happen
and doesn't cause further issues. We suppress the disabling timeout
already, do
According to the spec we should not enable the DDI-IO power domain if
the TypeC port is in the TBT-alt mode, so do that only in the other
TypeC modes or for non-TypeC ports.
Cc: Manasi Navare
Cc: Anusha Srivatsa
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c | 11 ---
1
Move the TypeC port handling functions to a new file for clarity.
While at it:
- s/icl_tc_port_connected()/intel_tc_port_connected()/
icl_tc_phy_disconnect(), will be unexported later.
- s/intel_dp_get_fia_supported_lane_count()/intel_tc_port_fia_max_lane_count()/
It's used for HDMI legacy mo
Fix the mapping from a TBT AUX power well index to the DP_AUX_CH_CTL
register.
Fixes: c7375d9542f1 ("drm/i915: Configure AUX_CH_CTL when enabling the AUX
power domain")
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display_power.c | 11
Unify the TypeC port notation in log messages, so that it matches the
spec. For instance the first ICL TypeC port will read as 'Port C/TC#1'.
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_tc.c | 41 +
In the TypeC TBT-alt port mode we must use the TBT AUX power domain,
fix that.
Cc: Manasi Navare
Cc: Anusha Srivatsa
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Add support to read out the TBT PLL HW state.
Cc: Vandita Kulkarni
Cc: Paulo Zanoni
Cc: Lucas De Marchi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/dri
Atm we switch the TypeC port mode upon receiving an HPD interrupt.
That's unsafe since the port could be active (after a modeset) or there
could be other users that depend on the port mode to stay fixed. To make
the mode switching robust add a TypeC port mode refcounting reflecting
the active state
The TypeC port mode can switch dynamically, to reflect that better call
the port's mode as 'mode' rather than 'type'.
While at it:
- s/TC_PORT_TBT/TC_PORT_TBT_ALT/ and s/TC_PORT_TYPEC/TC_PORT_DP_ALT/.
'TYPEC' is ambiguous, TBT_ALT and DP_ALT better match the reality.
- Remove the 'unknown' Type
Make the order during detection more consistent: first reset the TypeC
port mode if needed (adding new helpers for this), then detect any
connected sink.
To check if a port mode reset is needed determine first the target port
mode based on the live status if a sink is already connected or the
PHY
For using the correct AUX power domains we have to sanitize the TypeC
port mode early, so move that before encoder sanitization. To do this
properly read out the actual port mode instead of just relying on the
VBT legacy port flag (which can be incorrect).
We also verify that the PHY is connected
Based on a recent BSpec update (Index/21750) we must handle the TCCOLD
event associated with the DP-alt mode. We can detect this event by
reading an invalid all-1s value from FIA registers.
After detecting TCCOLD we will:
- fall back to TBT-alt mode when attempting to switch to DP-alt mode
- concl
The PHY satus complete flag normally clears when disconnecting the PHY
in DP-alt mode (achieved by switching to safe mode), so wait for the
flag to clear.
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_tc.c | 4
1 file changed, 4 inserti
We must keep the TypeC port mode fixed for the duration of the connector
detection and each AUX transfers. Add a new TypeC lock holding it around
these two sequences. For consistency also hold the lock during the port
mode sanitization.
Whenever resetting the port mode (only during the detection f
Factor out helpers reading/parsing the TypeC specific registers, making
current users of them clearer and letting us use them later.
While at it also:
- Simplify icl_tc_phy_connect() with an early return in legacy mode.
- Simplify the live status check using one bitmask for all HPD bits.
- Remove
For consistency s/intel_get_shared_dpll()/intel_reserve_shared_dplls()/
to better match intel_release_shared_dplls(). Also, pass to the
reserve/release and get_dplls/put_dplls hooks the intel_atomic_state and
CRTC object, that way these functions can look up the old or new state
as needed.
Also re
Use hex numbers, since that makes more sense when decoding a bit pattern.
No functional change.
Suggested-by: Ville Syrjälä
Cc: Animesh Manna
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_tc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
The TypeC port mode needs to stay fixed whenever the port is active. Do
that by introducing a tc_link_refcount to account for active ports,
avoiding changing the port mode if a reference is held.
During the modeset commit phase we also have to reset the port mode and
update the active PLL reflecti
When enabling a TypeC port we need to reserve all the required PLLs for
it, the TBT PLL for TBT-alt and the MG PHY PLL for DP-alt/legacy sinks.
We can select the proper PLL for the current port mode from the reserved
PLLs only once we selected and locked down the port mode for the whole
duration of
For clarity factor out the combo PHY and TypeC PHY specific code from
icl_get_dplls() into their own functions.
No functional changes.
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 100 +-
Pass the PLL HW state to the PLL find/reference functions making it
clearer what is their input. Also pass to these the atomic state and the
CRTC object instead of the CRTC state, since they don't require the
latter.
Move setting the PLL in the crtc_state to the get_dpll() hook, which
is the more
Add state verification for the TypeC port mode wrt. the port's AUX power
well enabling/disabling. Also check the correctness of changing the port
mode:
- When enabling/disabling the AUX power well for a TypeC port we must hold
already the TypeC port lock.
- When changing the TypeC port mode the p
Lane reversal happens only in the FIA module for TBT-alt/DP-alt mode, so
WARN if lane reversal is attempted at a different level. See the
BSpec DDI_BUF_CTL register description.
Cc: Manasi Navare
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/inte
Disconnecting the TypeC PHY when the port is in legacy mode is not
necessary:
- BSpec doesn't specify a disconnect sequence for legacy mode.
- The use of the PHY is dedicated for the display in legacy mode.
- We keep the PHY always connected during runtime as well in legacy
mode.
We disconnect t
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/selftests: Flush partial-tiling
object once
URL : https://patchwork.freedesktop.org/series/61578/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/selftests: Flush partial-tili
The intent was to skip unused HW contexts by checking ce->state.
However, this only works for execlists where the ppGTT pointers is
stored inside the HW context. For gen7, the ppGTT is alongside the
logical state and must be updated on all active engines but, crucially,
only on active engines. As w
Instead of relying on the caller holding struct_mutex across the
allocation, push the allocation under a tree of spinlocks stored inside
the page tables. Not only should this allow us to avoid struct_mutex
here, but it will allow multiple users to lock independent ranges for
concurrent allocations,
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/selftests: Flush partial-tiling
object once
URL : https://patchwork.freedesktop.org/series/61578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6186 -> Patchwork_13166
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev3)
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
87e2a194bf9d drm/i915/perf: introduce a versioning of the i915-perf uapi
d05986d1855c drm/i915/perf
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev3)
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: introduce a versioning of the i915-perf uapi
Okay!
Commi
== Series Details ==
Series: dma-buf: Discard old fence_excl on retrying get_fences_rcu for realloc
(rev3)
URL : https://patchwork.freedesktop.org/series/61581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6186 -> Patchwork_13167
=
I told vecs0 to use vecs1 registers...
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_shared.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
index 67ecd0953..069964546 100644
--- a/tests/i915/gem_ctx_shared.c
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev3)
URL : https://patchwork.freedesktop.org/series/60916/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6186 -> Patchwork_13168
Summary
---
*
== Series Details ==
Series: series starting with [1/2] drm/i915: Move intel_dp->prepare_link_train
assignment into ddi code
URL : https://patchwork.freedesktop.org/series/61586/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6187 -> Patchwork_13169
===
On Fri, May 24, 2019 at 07:40:28PM +0200, Hans de Goede wrote:
> Prior to this commit we fail to init the DSI panel on the GPD MicroPC:
> https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/
>
> The problem is intel_dsi_vbt_init() failing with the following error:
> *ER
== Series Details ==
Series: drm/i915: Fix TypeC port mode switching
URL : https://patchwork.freedesktop.org/series/61590/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
14db34664cf1 drm/i915/icl: Add support to read out the TBT PLL HW state
90cdad322f0f drm/i915: Tune down WARN
On Fri, May 24, 2019 at 06:30:19PM +0200, Hans de Goede wrote:
> The vlv/icl_dphy_param_init calls do various calculations to set dphy
> parameters based on the pclk.
>
> Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
> vlv_dsi_init a chance to tweak the pclk before these calc
On Fri, May 24, 2019 at 06:30:18PM +0200, Hans de Goede wrote:
> This is a preparation patch for moving the calling of *_dphy_param_init()
> out of intel_dsi_vbt_init.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi_vbt.c | 77 +++
== Series Details ==
Series: drm/i915: Fix TypeC port mode switching
URL : https://patchwork.freedesktop.org/series/61590/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/icl: Add support to read out the TBT PLL HW state
Okay!
Commit: drm/i915
On Fri, May 24, 2019 at 06:30:20PM +0200, Hans de Goede wrote:
> The GOP sometimes initializes the pclk at a (slightly) different frequency
> then the pclk which we've calculated.
>
> This commit makes the DSI code read-back the pclk set by the GOP and
> if that is within a reasonable margin of th
== Series Details ==
Series: drm/i915: Skip context_barrier emission for unused contexts
URL : https://patchwork.freedesktop.org/series/61595/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6187 -> Patchwork_13171
Summary
--
== Series Details ==
Series: drm/i915/gtt: Replace struct_mutex serialisation for allocation (rev2)
URL : https://patchwork.freedesktop.org/series/61533/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
15da932f11d7 drm/i915/gtt: Replace struct_mutex serialisation for allocation
-
== Series Details ==
Series: drm/i915/gtt: Replace struct_mutex serialisation for allocation (rev2)
URL : https://patchwork.freedesktop.org/series/61533/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/gtt: Replace struct_mutex serialisation fo
On 04/06/19 09:29, Chris Wilson wrote:
I told vecs0 to use vecs1 registers...
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_shared.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
index 67ecd0953..069964
== Series Details ==
Series: drm/i915/gtt: Replace struct_mutex serialisation for allocation (rev2)
URL : https://patchwork.freedesktop.org/series/61533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6187 -> Patchwork_13172
== Series Details ==
Series: drm/i915: Don't check uv_wm in skl_plane_wm_equals() (rev2)
URL : https://patchwork.freedesktop.org/series/58281/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6187 -> Patchwork_13173
Summary
--
On Tue, Jun 04, 2019 at 05:02:13PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> It's a bit silly to go through intel_dp.c to assign the
> prepare_link_train vfunc for ddi platforms when we can just
> assign it directly from intel_ddi.c.
>
> Signed-off-by: Ville Syrjälä
Yes looks like
On Tue, Jun 04, 2019 at 05:02:14PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_dp_link_down() is static and it's only called from the pre-ddi
> DP functions, so having a WARN_ON(HAS_DDI) in there is quite pointless.
> Remove it.
>
> Signed-off-by: Ville Syrjälä
Looks good to me
On Tue, Jun 04, 2019 at 03:51:58PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 03, 2019 at 02:49:40PM -0700, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood
> >
> > intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
> > use before encoder_type is set. This caused GEN11+
Quoting Antonio Argenziano (2019-06-04 19:43:35)
>
>
> On 04/06/19 09:29, Chris Wilson wrote:
> > I told vecs0 to use vecs1 registers...
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/i915/gem_ctx_shared.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --gi
From: Ville Syrjälä
Our PCH refclk init code currently assumes that the PCH SSC reference
can only be used for FDI. That is not true and it can be used by
SPLL/WRPLL for eDP SSC or clock bending as well. Before we go
reconfiguring it let's make sure no PLL is currently using the PCH
SSC reference
From: Ville Syrjälä
Give the PLL control register bits better names on HSW/BDW.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 37 ++-
drivers/gpu/drm/i915/intel_ddi.c | 16 ++--
drivers/gpu/drm/i915/intel_display.c | 8 +++---
d
1 - 100 of 117 matches
Mail list logo
