On Mon, 2019-09-09 at 13:25 +0300, Ville Syrjälä wrote:
> On Sat, Sep 07, 2019 at 11:19:55PM +, Mun, Gwan-gyeong wrote:
> > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > > wrote:
> > > > On Fri, Sep 06, 2019 at 11:31:55AM +, Sh
On 9/10/2019 8:44 AM, Sharma, Shashank wrote:
-Original Message-
From: Manna, Animesh
Sent: Monday, September 9, 2019 10:27 PM
To: Sharma, Shashank ; intel-
g...@lists.freedesktop.org
Cc: Thierry, Michel ; Nikula, Jani
;
Vivi, Rodrigo
Subject: Re: [PATCH v5 05/11] drm/i915/dsb: Chec
On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> wrote:
> > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > > wrote:
> > > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma
On Mon, Sep 09, 2019 at 11:55:35PM +0100, Chris Wilson wrote:
> If the display is inactive, we need not worry about the gpu reset
> clobbering the display!
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
> 1 file changed, 17 insertions(+), 1
Hi Chris,
On Tuesday, September 10, 2019 12:55:36 AM CEST Chris Wilson wrote:
> Unwedging the GPU requires a successful GPU reset before we restore the
> default submission, or else we may see residual context switch events
> that we were not expecting.
>
> Reported-by: Janusz Krzysztofik
> Sign
On Tue, Sep 10, 2019 at 07:34:31AM +, Mun, Gwan-gyeong wrote:
> On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > wrote:
> > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
During reset, we try to ensure no forward progress of the CS prior to
the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this
register is context saved and do we end up in the odd situation where we
save the STOP_RING bit and so try to stop the engine again immediately
upon resume.
During reset, we try to ensure no forward progress of the CS prior to
the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this
register is context saved and do we end up in the odd situation where we
save the STOP_RING bit and so try to stop the engine again immediately
upon resume.
On 10/09/2019 05:53, Summers, Stuart wrote:
On Fri, 2019-09-06 at 19:13 +0100, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-02 14:42:44)
On 24/07/2019 14:05, Tvrtko Ursulin wrote:
On 23/07/2019 16:49, Stuart Summers wrote:
+u32 intel_sseu_get_subslices(const struct sseu_dev_info *ss
Quoting Ville Syrjälä (2019-09-10 08:39:31)
> On Mon, Sep 09, 2019 at 11:55:35PM +0100, Chris Wilson wrote:
> > If the display is inactive, we need not worry about the gpu reset
> > clobbering the display!
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_reset.c | 18
== Series Details ==
Series: drm/i915/execlists: Clear STOP_RING bit on reset (rev2)
URL : https://patchwork.freedesktop.org/series/66473/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6857 -> Patchwork_14336
Summary
--
== Series Details ==
Series: drm/i915/tgl: Implement Wa_1409142259 (rev2)
URL : https://patchwork.freedesktop.org/series/66364/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6855_full -> Patchwork_14335_full
Summary
---
On Tue, Sep 10, 2019 at 09:32:45AM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2019-09-10 08:39:31)
> > On Mon, Sep 09, 2019 at 11:55:35PM +0100, Chris Wilson wrote:
> > > If the display is inactive, we need not worry about the gpu reset
> > > clobbering the display!
> > >
> > > Signed-off
On Mon, 09 Sep 2019, Manasi Navare wrote:
> On Thu, Sep 05, 2019 at 11:03:12AM +0530, Nautiyal, Ankit K wrote:
>> Hi,
>>
>> I was able to get 5K HPz27q 317b monitor for some time. Below are the
>> observation on HPz27q Monitor with two DP cables connected to a KBL machine.
>>
>> *General Obs
On Sun, 08 Sep 2019, Manasi Navare wrote:
> This patch series addresses all review comments and now the enable and
> disable paths follow the method of obtaining slave states from master
> and updating master-slaves in correct order during master modeset.
Main high level question: what does it ta
Chris Wilson writes:
> During reset, we try to ensure no forward progress of the CS prior to
> the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this
> register is context saved and do we end up in the odd situation where we
> save the STOP_RING bit and so try to stop the engine
Quoting Mika Kuoppala (2019-09-10 10:31:05)
> Chris Wilson writes:
>
> > During reset, we try to ensure no forward progress of the CS prior to
> > the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this
> > register is context saved and do we end up in the odd situation where we
Hi Ville,
On Mon, 2 Sep 2019 16:15:45 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> CEA ext block revisions 1 and 2 do not contain the data block
> collection. Instead that section of the extension block is
> marked as reserved for 8 byte timing descriptors. Revision 3
> changed it to c
On Wed, Aug 21, 2019 at 03:32:19PM +0200, Maarten Lankhorst wrote:
> We cannot switch between HQ and normal mode on GLK+, so only
> add planes on platforms where it makes sense.
>
> We could probably restrict it even more to only add when scaler
> users toggles between 1 and 2, but lets just leave
Hi Ville,
On Mon, 2 Sep 2019 16:15:46 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's make cea_db_offsets() a bit more convenient to use by
> setting the start/end offsets to zero whenever the data block
> collection isn't present. This makes it safe for the caller
> to blindly iter
On Tue, Sep 10, 2019 at 11:46:20AM +0200, Jean Delvare wrote:
> Hi Ville,
>
> On Mon, 2 Sep 2019 16:15:46 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's make cea_db_offsets() a bit more convenient to use by
> > setting the start/end offsets to zero whenever the data block
> >
On Mon, 09 Sep 2019 21:28:00 +0200, Anusha Srivatsa
wrote:
Update MAKE_HUC_FW_PATH macro to follow the same convention
as the MAKE_GUC_FW_PATH with the separator changing from "_" to "."
and removing "ver".
above commit message (and patch title) is little misleading as updating
a macro is s
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-09-10 10:31:05)
>> Chris Wilson writes:
>>
>> > During reset, we try to ensure no forward progress of the CS prior to
>> > the reset by setting the STOP_RING bit in RING_MI_MODE. Since gen9, this
>> > register is context saved and do we end up
On 2019-09-08 at 20:55:17 +0300, Imre Deak wrote:
Hi Imre ,
Thanks for review, could you please provide your response on below
comments.
> On Sat, Sep 07, 2019 at 10:44:42PM +0530, Anshuman Gupta wrote:
> > DC3CO is useful power state, when DMC detects PSR2 idle frame
> > while an active video play
Quoting Mika Kuoppala (2019-09-10 10:54:43)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-09-10 10:31:05)
> >> Chris Wilson writes:
> >>
> >> > During reset, we try to ensure no forward progress of the CS prior to
> >> > the reset by setting the STOP_RING bit in RING_MI_MODE. Since g
Currently the property docs don't specify whether it's okay for two planes to
have the same zpos value and what user-space should expect in this case.
The rule mentionned in the past was to disambiguate with object IDs. However
some drivers break this rule (that's why the ordering is documented as
On Tue, 10 Sep 2019 12:48:42 +0300, Ville Syrjälä wrote:
> On Tue, Sep 10, 2019 at 11:46:20AM +0200, Jean Delvare wrote:
> > Hi Ville,
> >
> > On Mon, 2 Sep 2019 16:15:46 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Let's make cea_db_offsets() a bit more convenient to use
Chris Wilson writes:
> Icelake hit an issue where it missed reporting a completion event and
> instead jumped straight to a idle->active event (skipping over the
> active->idle and not even hitting the lite-restore preemption).
>
> 661497511us : process_csb: rcs0 cs-irq head=11, tail=0
> 66149751
On Mon, 09 Sep 2019, Swati Sharma wrote:
> In this patch series, added state checker to validate gamma lut values
> for cherryview and i965 platforms. It's extension of the
> patch series https://patchwork.freedesktop.org/patch/328246/?series=58039
> which enabled the basic infrastructure and stat
Chris Wilson writes:
> Be paranoid and make sure we flush any and all writes out of the WCB
> before performing the UC mmio to update the RING_TAIL. (An UC write
> should itself be enough to do the flush, hence the paranoia here.) Quite
> infrequently, we see problems where the GPU seems to overs
Chris Wilson writes:
> As soon as we re-enable the various functions within the HW, they may go
> off and read data via a GGTT offset. Hence, if we have not yet restored
> the GGTT PTE before then, they may read and even *write* random locations
> in memory.
>
> Detected by DMAR faults during res
Chris Wilson writes:
> Despite the widespread and complete failure of Broadwell integrated
> graphics when DMAR is enabled, known over the years, we have never been
> able to root cause the issue. Instead, we let the failure undermine our
> confidence in the iommu system itself when we should be
On 10-Sep-19 3:57 PM, Jani Nikula wrote:
On Mon, 09 Sep 2019, Swati Sharma wrote:
In this patch series, added state checker to validate gamma lut values
for cherryview and i965 platforms. It's extension of the
patch series https://patchwork.freedesktop.org/patch/328246/?series=58039
which enabl
On Mon, 9 Sep 2019 at 12:00, Chris Wilson wrote:
>
> Being a "low-level" test, we opt to bypass the normal bind/unbind hooks
> for the lower level insert_entries/clear_range. For ggtt, the
> bind/unbind hooks provide the runtime wakeref and so we must also handle
> this in exercising the low level
Forcewake handling is a prime suspect now. Keep ref
always on tgl to test the theory and reveal the coverage.
Testcase: igt/gem_sync
Cc: Chris Wilson
Suggested-by: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
1 file changed, 4 insertions(+), 1 deleti
== Series Details ==
Series: drm: two planes with the same zpos have undefined ordering
URL : https://patchwork.freedesktop.org/series/66480/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7b8f1c2a9415 drm: two planes with the same zpos have undefined ordering
-:6: WARNING:COMMI
Currently, if there is time remaining before the start of the loop, we
do one full iteration over many possible different chunks within the
object. A full loop may take 50+s (depending on speed of indirect GTT
mmapings) and we try separately with LINEAR, X and Y -- at which point
igt times out. If
From: Ville Syrjälä
system_unbound_wq can't keep up sometimes and we get dropped frames.
Switch to a high priority variant.
Reported-by: Heinrich Fink
Tested-by: Heinrich Fink
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +-
drivers/gpu/drm/i915/i915_
== Series Details ==
Series: drm: two planes with the same zpos have undefined ordering
URL : https://patchwork.freedesktop.org/series/66480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14337
Summary
---
On Fri, Sep 06, 2019 at 05:21:36PM -0700, Matt Roper wrote:
> Aside from a few minor register changes and some different clock values,
> cdclk design hasn't changed much since gen9lp. Let's consolidate the
> handlers for bxt, cnl, and icl to keep the codeflow consistent.
>
> Also, while we're at
On Tue, 10 Sep 2019 at 13:10, Chris Wilson wrote:
>
> Currently, if there is time remaining before the start of the loop, we
> do one full iteration over many possible different chunks within the
> object. A full loop may take 50+s (depending on speed of indirect GTT
> mmapings) and we try separat
Quoting Ville Syrjala (2019-09-10 13:13:47)
> From: Ville Syrjälä
>
> system_unbound_wq can't keep up sometimes and we get dropped frames.
> Switch to a high priority variant.
>
> Reported-by: Heinrich Fink
> Tested-by: Heinrich Fink
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
On Fri, Sep 06, 2019 at 05:21:38PM -0700, Matt Roper wrote:
> We'd previously combined ICL/TGL logic into the cnl_set_cdclk function,
> but BXT is pretty similar as well. Roll the cnl/icl/tgl logic back into
> the bxt function; the only things we really need to handle separately
> are punit notifi
On Fri, Sep 06, 2019 at 05:21:39PM -0700, Matt Roper wrote:
> The CNL variant of this function is identical to the BXT variant aside
> from not needing to handle SSA precharge.
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/i
On Fri, Sep 06, 2019 at 05:21:40PM -0700, Matt Roper wrote:
> The uninitialize flow is the same on all of these platforms, aside from
> calculating a different frequency level.
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 48 +++-
On Fri, Sep 06, 2019 at 05:21:41PM -0700, Matt Roper wrote:
> With all of the cdclk function consolidation, we can cut down on a lot
> of platform if/else logic by creating a vfunc that's initialized at
> startup.
Reviewed-by: Ville Syrjälä
>
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
>
On Fri, Sep 06, 2019 at 05:21:42PM -0700, Matt Roper wrote:
> When reading out the BIOS-programmed cdclk state, let's make sure that
> the cdclk value is on the valid list for the platform, ensure that the
> VCO matches the cdclk, and ensure that the CD2X divider was set
> properly.
Reviewed-by: V
== Series Details ==
Series: drm/i915/tgl: Keep forcewake always for now
URL : https://patchwork.freedesktop.org/series/66483/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14338
Summary
---
**SUCCE
On Fri, Sep 06, 2019 at 05:21:43PM -0700, Matt Roper wrote:
> The BXT and CNL functions were already basically identical, whereas
> ICL's function tried to do its own sanitization rather than calling
> bxt_sanitize_cdclk.
>
> This should actually fix a bug in our ICL initialization where it would
On Sat, Sep 07, 2019 at 09:05:00PM -0700, Matt Roper wrote:
> The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X
> dividers in an easy-to-read table for most recent platforms. We've been
> translating the data from that table into platform-specific code logic,
> but it's easy to over
== Series Details ==
Series: drm/i915/selftests: Tighten the timeout testing for partial mmaps
URL : https://patchwork.freedesktop.org/series/66484/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8b28c802b06b drm/i915/selftests: Tighten the timeout testing for partial mmaps
-:27
On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong
wrote:
>
> On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > wrote:
> > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > > >
== Series Details ==
Series: drm/i915/selftests: Tighten the timeout testing for partial mmaps
URL : https://patchwork.freedesktop.org/series/66484/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14339
Summ
Quoting Mika Kuoppala (2019-09-10 12:35:47)
> Forcewake handling is a prime suspect now. Keep ref
> always on tgl to test the theory and reveal the coverage.
>
> Testcase: igt/gem_sync
> Cc: Chris Wilson
> Suggested-by: Chris Wilson
> Signed-off-by: Mika Kuoppala
Gets us as far as reload, befo
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 00786a142ff0..06709dd6a2e0 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/
---
drivers/iommu/intel-iommu.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 34f6a3d93ae2..c98cdfd91691 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -439,8 +439,6 @@ static int __init intel_iom
Despite the widespread and complete failure of Broadwell integrated
graphics when DMAR is enabled, known over the years, we have never been
able to root cause the issue. Instead, we let the failure undermine our
confidence in the iommu system itself when we should be pushing for it to
be always ena
== Series Details ==
Series: drm/i915/execlists: Clear STOP_RING bit on reset (rev2)
URL : https://patchwork.freedesktop.org/series/66473/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6857_full -> Patchwork_14336_full
Summ
== Series Details ==
Series: drm/i915: Use a high priority wq for nonblocking plane updates
URL : https://patchwork.freedesktop.org/series/66485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6860 -> Patchwork_14340
Summary
On Fri, Aug 09, 2019 at 01:53:43PM +0100, Chris Wilson wrote:
> Quoting Martin Wilck (2019-08-09 13:41:42)
> > This happened to me today, running kernel 5.3.0-rc3-1.g571863b-default
> > (5.3-rc3 with just a few patches on top), after starting a KVM virtual
> > machine. The X screen was frozen. Remo
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 00786a142ff0..c5c00cad6ba1 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu
== Series Details ==
Series: series starting with drm/i915: Force compilation with intel-iommu for
CI validation (rev2)
URL : https://patchwork.freedesktop.org/series/66487/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f0df04b62a3b drm/i915: Force compilation with intel-iommu
From: Tvrtko Ursulin
Code in i915_gem_init_hw is all about GT init so move it to intel_gt.c
renaming to intel_gt_init_hw.
Existing intel_gt_init_hw is renamed to intel_gt_init_hw_early since it
is currently called from driver probe.
Signed-off-by: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilso
From: Tvrtko Ursulin
Timelines live in struct intel_gt so make wait_for_timelines take
exactly what it needs.
Signed-off-by: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/driv
From: Tvrtko Ursulin
Both in the container_of and getting to gt->awake there is no need to go
via i915 since both the wakeref and awake are members of gt.
Signed-off-by: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +++---
1 file changed, 3 ins
From: Tvrtko Ursulin
A few patches left hanging since late July. First one old in spirit but adjusted
and renamed and the rest update for latest drm-tip.
Happy to receive thoughts on whether this cleanup makes sense.
Cc: Andi Shyti
Cc: Chris Wilson
Tvrtko Ursulin (4):
drm/i915: Move GT ini
From: Tvrtko Ursulin
These notifications operate on intel_gt so make the code take what it
needs.
Signed-off-by: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/dr
== Series Details ==
Series: Few loose end intel_gt cleanups
URL : https://patchwork.freedesktop.org/series/66490/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4144570a45a2 drm/i915: Move GT init to intel_gt.c
-:89: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN
Quoting Tvrtko Ursulin (2019-09-10 15:38:20)
> From: Tvrtko Ursulin
>
> Code in i915_gem_init_hw is all about GT init so move it to intel_gt.c
> renaming to intel_gt_init_hw.
>
> Existing intel_gt_init_hw is renamed to intel_gt_init_hw_early since it
> is currently called from driver probe.
>
>
Quoting Tvrtko Ursulin (2019-09-10 15:38:21)
> From: Tvrtko Ursulin
>
> Timelines live in struct intel_gt so make wait_for_timelines take
> exactly what it needs.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andi Shyti
> Cc: Chris Wilson
I've deleted this code, fwiw, merged it with request manage
Quoting Tvrtko Ursulin (2019-09-10 15:38:22)
> From: Tvrtko Ursulin
>
> Both in the container_of and getting to gt->awake there is no need to go
> via i915 since both the wakeref and awake are members of gt.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andi Shyti
> Cc: Chris Wilson
Have same chun
== Series Details ==
Series: series starting with drm/i915: Force compilation with intel-iommu for
CI validation (rev2)
URL : https://patchwork.freedesktop.org/series/66487/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14341
Quoting Tvrtko Ursulin (2019-09-10 15:38:23)
> From: Tvrtko Ursulin
>
> These notifications operate on intel_gt so make the code take what it
> needs.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andi Shyti
> Cc: Chris Wilson
Soon the blocking_notifier will be relieved of duty...
I think it migh
== Series Details ==
Series: Few loose end intel_gt cleanups
URL : https://patchwork.freedesktop.org/series/66490/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14342
Summary
---
**SUCCESS**
No r
References: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fbe98a2db88e..b3cc8560696b
Previous version of the series was here:
https://lists.freedesktop.org/archives/intel-gfx/2019-September/211853.html
This version incorporates Ville's comments, most of which are on the
second patch where we introduce the cdclk tables. The structure and
parsing of the tables is now done in a
The uninitialize flow is the same on all of these platforms, aside from
calculating a different frequency level.
v2: Reverse platform conditional order for consistency. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk
With all of the cdclk function consolidation, we can cut down on a lot
of platform if/else logic by creating a vfunc that's initialized at
startup.
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 75 --
We'd previously combined ICL/TGL logic into the cnl_set_cdclk function,
but BXT is pretty similar as well. Roll the cnl/icl/tgl logic back into
the bxt function; the only things we really need to handle separately
are punit notification and calling different functions to enable/disable
the cdclk P
The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X
dividers in an easy-to-read table for most recent platforms. We've been
translating the data from that table into platform-specific code logic,
but it's easy to overlook an area we need to update when adding new
cdclk values or enabl
Aside from a few minor register changes and some different clock values,
cdclk design hasn't changed much since gen9lp. Let's consolidate the
handlers for bxt, cnl, and icl to keep the codeflow consistent.
Also, while we're at it, s/bxt_de_pll_update/bxt_de_pll_readout/ since
"update" makes me th
The CNL variant of this function is identical to the BXT variant aside
from not needing to handle SSA precharge.
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 46 +-
1 file changed, 2 insertions(+), 4
The BXT and CNL functions were already basically identical, whereas
ICL's function tried to do its own sanitization rather than calling
bxt_sanitize_cdclk.
This should actually fix a bug in our ICL initialization where it would
consider the /2 CD2X divider invalid and force an unnecessary
sanitiza
When reading out the BIOS-programmed cdclk state, let's make sure that
the cdclk value is on the valid list for the platform, ensure that the
VCO matches the cdclk, and ensure that the CD2X divider was set
properly.
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
dri
On Tue, Sep 10, 2019 at 08:42:45AM -0700, Matt Roper wrote:
> Aside from a few minor register changes and some different clock values,
> cdclk design hasn't changed much since gen9lp. Let's consolidate the
> handlers for bxt, cnl, and icl to keep the codeflow consistent.
>
> Also, while we're at
On Tue, Sep 10, 2019 at 08:42:46AM -0700, Matt Roper wrote:
> The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X
> dividers in an easy-to-read table for most recent platforms. We've been
> translating the data from that table into platform-specific code logic,
> but it's easy to over
Aside from a few minor register changes and some different clock values,
cdclk design hasn't changed much since gen9lp. Let's consolidate the
handlers for bxt, cnl, and icl to keep the codeflow consistent.
Also, while we're at it, s/bxt_de_pll_update/bxt_de_pll_readout/ since
"update" makes me th
== Series Details ==
Series: drm/i915/tgl: Disable rc6 for debugging
URL : https://patchwork.freedesktop.org/series/66492/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14343
Summary
---
**SUCCESS**
On Tue, Sep 10, 2019 at 08:42:46AM -0700, Matt Roper wrote:
...
> +struct intel_cdclk_vals {
> + u32 refclk;
Oh, I think (at least currently) refclk would fit into u16,
so we could pack this a bit tighter still.
> + u32 cdclk;
> + u8 divider; /* CD2X divider * 2 */
> + u8 rat
== Series Details ==
Series: cdclk consolidation and rework for BXT-TGL (rev5)
URL : https://patchwork.freedesktop.org/series/66365/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c7ffbe99a9da drm/i915: Consolidate bxt/cnl/icl cdclk readout
-:81: CHECK:CAMELCASE: Avoid CamelCase
Quoting Patchwork (2019-09-10 17:06:36)
> External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14343/
>
> Known issues
>
>
> Here are the changes found in Patchwork_14343 that come from known issues:
tgl died in gem_exec_gttfill, so not rc6, or even runtime-pm, by it
On Tue, Sep 10, 2019 at 9:21 AM Ilia Mirkin wrote:
>
> On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong
> wrote:
> >
> > On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > > wrote:
> > > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin
The bspec lays out legal cdclk frequencies, PLL ratios, and CD2X
dividers in an easy-to-read table for most recent platforms. We've been
translating the data from that table into platform-specific code logic,
but it's easy to overlook an area we need to update when adding new
cdclk values or enabl
References: https://bugs.freedesktop.org/show_bug.cgi?id=111593
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/intel_pm.c | 3 +--
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drive
== Series Details ==
Series: cdclk consolidation and rework for BXT-TGL (rev6)
URL : https://patchwork.freedesktop.org/series/66365/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c43a4d52b847 drm/i915: Consolidate bxt/cnl/icl cdclk readout
-:81: CHECK:CAMELCASE: Avoid CamelCase
== Series Details ==
Series: cdclk consolidation and rework for BXT-TGL (rev5)
URL : https://patchwork.freedesktop.org/series/66365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14344
Summary
---
*
== Series Details ==
Series: cdclk consolidation and rework for BXT-TGL (rev6)
URL : https://patchwork.freedesktop.org/series/66365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14345
Summary
---
*
Minor comment below. With or without it,
Reviewed-by: Umesh Nerlige Ramappa
Regards,
Umesh
On Mon, Sep 09, 2019 at 12:31:06PM +0300, Lionel Landwerlin wrote:
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and
== Series Details ==
Series: drm: two planes with the same zpos have undefined ordering
URL : https://patchwork.freedesktop.org/series/66480/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6860_full -> Patchwork_14337_full
S
== Series Details ==
Series: drm/i915/tgl: Disable rc6 for debugging (rev2)
URL : https://patchwork.freedesktop.org/series/66492/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6861 -> Patchwork_14346
Summary
---
**SU
1 - 100 of 149 matches
Mail list logo
