Re: [Intel-gfx] [PATCH] drm/i915: Protect debugfs per_file_stats with RCU lock
On Tue, Sep 03, 2019 at 07:21:33AM +0100, Chris Wilson wrote:
> If we make sure we grab a strong reference to each object as we dump it,
> we can reduce the locks outside of our iterators to an rcu_read_lock.
>
> This should prevent errors like:
> [ 2138.371911] BUG: KASAN: use-after-free in per_file_stats+0x43/0x380 [i915]
> [ 2138.371924] Read of size 8 at addr 888223651000 by task cat/8293
>
> [ 2138.371947] CPU: 0 PID: 8293 Comm: cat Not tainted
> 5.3.0-rc6-CI-Custom_4352+ #1
> [ 2138.371953] Hardware name: To Be Filled By O.E.M. To Be Filled By
> O.E.M./J4205-ITX, BIOS P1.40 07/14/2017
> [ 2138.371959] Call Trace:
> [ 2138.371974] dump_stack+0x7c/0xbb
> [ 2138.372099] ? per_file_stats+0x43/0x380 [i915]
> [ 2138.372108] print_address_description+0x73/0x3a0
> [ 2138.372231] ? per_file_stats+0x43/0x380 [i915]
> [ 2138.372352] ? per_file_stats+0x43/0x380 [i915]
> [ 2138.372362] __kasan_report+0x14e/0x192
> [ 2138.372489] ? per_file_stats+0x43/0x380 [i915]
> [ 2138.372502] kasan_report+0xe/0x20
> [ 2138.372625] per_file_stats+0x43/0x380 [i915]
> [ 2138.372751] ? i915_panel_show+0x110/0x110 [i915]
> [ 2138.372761] idr_for_each+0xa7/0x160
> [ 2138.372773] ? idr_get_next_ul+0x110/0x110
> [ 2138.372782] ? do_raw_spin_lock+0x10a/0x1d0
> [ 2138.372923] print_context_stats+0x264/0x510 [i915]
>
> Signed-off-by: Chris Wilson
Tested-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 9798f27a697a..708855e051b5 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -237,6 +237,9 @@ static int per_file_stats(int id, void *ptr, void *data)
> struct file_stats *stats = data;
> struct i915_vma *vma;
>
> + if (!kref_get_unless_zero(&obj->base.refcount))
> + return 0;
> +
> stats->count++;
> stats->total += obj->base.size;
> if (!atomic_read(&obj->bind_count))
> @@ -284,6 +287,7 @@ static int per_file_stats(int id, void *ptr, void *data)
> }
> spin_unlock(&obj->vma.lock);
>
> + i915_gem_object_put(obj);
> return 0;
> }
>
> @@ -313,10 +317,12 @@ static void print_context_stats(struct seq_file *m,
> i915_gem_context_lock_engines(ctx), it) {
> intel_context_lock_pinned(ce);
> if (intel_context_is_pinned(ce)) {
> + rcu_read_lock();
> if (ce->state)
> per_file_stats(0,
> ce->state->obj, &kstats);
> per_file_stats(0, ce->ring->vma->obj, &kstats);
> + rcu_read_unlock();
> }
> intel_context_unlock_pinned(ce);
> }
> @@ -328,9 +334,9 @@ static void print_context_stats(struct seq_file *m,
> struct task_struct *task;
> char name[80];
>
> - spin_lock(&file->table_lock);
> + rcu_read_lock();
> idr_for_each(&file->object_idr, per_file_stats, &stats);
> - spin_unlock(&file->table_lock);
> + rcu_read_unlock();
>
> rcu_read_lock();
> task = pid_task(ctx->pid ?: file->pid, PIDTYPE_PID);
> --
> 2.23.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 RESEND] drm/i915: add support for specifying DMC firmware override by module param
On Mon, Apr 30, 2018 at 01:47:15PM +0300, Jani Nikula wrote:
> On Tue, 24 Apr 2018, Jani Nikula wrote:
> > Use i915.dmc_firmware_path to override default firmware for the platform
> > and bypassing version checks.
> >
> > v2: add missing param struct member declaration (David)
> >
> > Tested-by: David Weinehall
> > Reviewed-by: David Weinehall
> > Cc: Anusha Srivatsa
> > Cc: David Weinehall
> > Signed-off-by: Jani Nikula
>
> So *I* don't need this patch. Please someone tell me this is useful to
> you, and I'll merge.
It's useful for us (PnP team), and I believe Anusha has expressed
interest too, correct?
Kind regards, David
>
> Thanks,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/i915_params.c | 3 +++
> > drivers/gpu/drm/i915/i915_params.h | 1 +
> > drivers/gpu/drm/i915/intel_csr.c | 9 +++--
> > 3 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 08108ce5be21..66ea3552c63e 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -164,6 +164,9 @@ i915_param_named_unsafe(guc_firmware_path, charp, 0400,
> > i915_param_named_unsafe(huc_firmware_path, charp, 0400,
> > "HuC firmware path to use instead of the default one");
> >
> > +i915_param_named_unsafe(dmc_firmware_path, charp, 0400,
> > + "DMC firmware path to use instead of the default one");
> > +
> > i915_param_named_unsafe(enable_dp_mst, bool, 0600,
> > "Enable multi-stream transport (MST) for new DisplayPort sinks.
> > (default: true)");
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> > b/drivers/gpu/drm/i915/i915_params.h
> > index c96360398072..6684025b7af8 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -51,6 +51,7 @@ struct drm_printer;
> > param(int, guc_log_level, -1) \
> > param(char *, guc_firmware_path, NULL) \
> > param(char *, huc_firmware_path, NULL) \
> > + param(char *, dmc_firmware_path, NULL) \
> > param(int, mmio_debug, 0) \
> > param(int, edp_vswing, 0) \
> > param(int, reset, 2) \
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index 41e6c75a7f3c..d81673250d3b 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -297,7 +297,10 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
> > *dev_priv,
> >
> > csr->version = css_header->version;
> >
> > - if (IS_CANNONLAKE(dev_priv)) {
> > + if (csr->fw_path == i915_modparams.dmc_firmware_path) {
> > + /* Bypass version check for firmware override. */
> > + required_version = csr->version;
> > + } else if (IS_CANNONLAKE(dev_priv)) {
> > required_version = CNL_CSR_VERSION_REQUIRED;
> > } else if (IS_GEMINILAKE(dev_priv)) {
> > required_version = GLK_CSR_VERSION_REQUIRED;
> > @@ -452,7 +455,9 @@ void intel_csr_ucode_init(struct drm_i915_private
> > *dev_priv)
> > if (!HAS_CSR(dev_priv))
> > return;
> >
> > - if (IS_CANNONLAKE(dev_priv))
> > + if (i915_modparams.dmc_firmware_path)
> > + csr->fw_path = i915_modparams.dmc_firmware_path;
> > + else if (IS_CANNONLAKE(dev_priv))
> > csr->fw_path = I915_CSR_CNL;
> > else if (IS_GEMINILAKE(dev_priv))
> > csr->fw_path = I915_CSR_GLK;
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 RESEND] drm/i915: add support for specifying DMC firmware override by module param
On Tue, Apr 24, 2018 at 03:20:16PM +0300, Jani Nikula wrote:
> Use i915.dmc_firmware_path to override default firmware for the platform
> and bypassing version checks.
>
> v2: add missing param struct member declaration (David)
>
> Tested-by: David Weinehall
> Reviewed-by: David Weinehall
Re-tested against latest drm-tip; still works fine.
> Cc: Anusha Srivatsa
> Cc: David Weinehall
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_params.c | 3 +++
> drivers/gpu/drm/i915/i915_params.h | 1 +
> drivers/gpu/drm/i915/intel_csr.c | 9 +++--
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 08108ce5be21..66ea3552c63e 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -164,6 +164,9 @@ i915_param_named_unsafe(guc_firmware_path, charp, 0400,
> i915_param_named_unsafe(huc_firmware_path, charp, 0400,
> "HuC firmware path to use instead of the default one");
>
> +i915_param_named_unsafe(dmc_firmware_path, charp, 0400,
> + "DMC firmware path to use instead of the default one");
> +
> i915_param_named_unsafe(enable_dp_mst, bool, 0600,
> "Enable multi-stream transport (MST) for new DisplayPort sinks.
> (default: true)");
>
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index c96360398072..6684025b7af8 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -51,6 +51,7 @@ struct drm_printer;
> param(int, guc_log_level, -1) \
> param(char *, guc_firmware_path, NULL) \
> param(char *, huc_firmware_path, NULL) \
> + param(char *, dmc_firmware_path, NULL) \
> param(int, mmio_debug, 0) \
> param(int, edp_vswing, 0) \
> param(int, reset, 2) \
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index 41e6c75a7f3c..d81673250d3b 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -297,7 +297,10 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
> *dev_priv,
>
> csr->version = css_header->version;
>
> - if (IS_CANNONLAKE(dev_priv)) {
> + if (csr->fw_path == i915_modparams.dmc_firmware_path) {
> + /* Bypass version check for firmware override. */
> + required_version = csr->version;
> + } else if (IS_CANNONLAKE(dev_priv)) {
> required_version = CNL_CSR_VERSION_REQUIRED;
> } else if (IS_GEMINILAKE(dev_priv)) {
> required_version = GLK_CSR_VERSION_REQUIRED;
> @@ -452,7 +455,9 @@ void intel_csr_ucode_init(struct drm_i915_private
> *dev_priv)
> if (!HAS_CSR(dev_priv))
> return;
>
> - if (IS_CANNONLAKE(dev_priv))
> + if (i915_modparams.dmc_firmware_path)
> + csr->fw_path = i915_modparams.dmc_firmware_path;
> + else if (IS_CANNONLAKE(dev_priv))
> csr->fw_path = I915_CSR_CNL;
> else if (IS_GEMINILAKE(dev_priv))
> csr->fw_path = I915_CSR_GLK;
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Request driver probe from an async task
On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> As we are careful not to register external interfaces before the
> internals are brought up, we are not dependent upon a synchronous
> probing and can allow ourselves to be probed from a secondary thread
> during system bootup. We already do relegate some configuration to
> asynchronous tasks (such as setting up the fbdev), now do the entire
> probe.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=105622
> Signed-off-by: Chris Wilson
LGTM, and still seems to apply cleanly.
Reviewed-by: David Weinehall
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: David Weinehall
> ---
> 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 4364922e935d..be7b03d48229 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -726,6 +726,7 @@ static struct pci_driver i915_pci_driver = {
> .probe = i915_pci_probe,
> .remove = i915_pci_remove,
> .driver.pm = &i915_pm_ops,
> + .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> };
>
> static int __init i915_init(void)
> --
> 2.16.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on CFL and GLK
On Thu, Mar 15, 2018 at 05:42:00PM -0700, Rodrigo Vivi wrote:
> On Thu, Mar 15, 2018 at 03:35:02PM +0200, David Weinehall wrote:
> > Since Coffee Lake uses the Kaby Lake DMC it's a safe
> > bet that the debug registers are the same. I haven't
> > double-checked that the GLK DMC uses the same registers
> > as BXT, but it seems as good of a guess as any.
>
> It would be good to check. Last time that I checked we were getting
> deep PC residencies but these registers were zeroed on CFL.
>
> Also this bit confuses many people since it is not a
> proper residency counter :/
I'll run some tests on all platforms that are supposed to be supported
by this, and compare the behaviour.
>
> >
> > Signed-off-by: David Weinehall
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index c4cc8fef11a0..dad0776d58b4 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2813,13 +2813,14 @@ static int i915_dmc_info(struct seq_file *m, void
> > *unused)
> > seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
> >CSR_VERSION_MINOR(csr->version));
> >
> > - if (IS_KABYLAKE(dev_priv) ||
> > + if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> > (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))) {
> > seq_printf(m, "DC3 -> DC5 count: %d\n",
> >I915_READ(SKL_CSR_DC3_DC5_COUNT));
> > seq_printf(m, "DC5 -> DC6 count: %d\n",
> >I915_READ(SKL_CSR_DC5_DC6_COUNT));
> > - } else if (IS_BROXTON(dev_priv) && csr->version >= CSR_VERSION(1, 4)) {
> > + } else if (IS_GEMINILAKE(dev_priv) ||
> > + IS_BROXTON(dev_priv) && csr->version >= CSR_VERSION(1, 4)) {
> > seq_printf(m, "DC3 -> DC5 count: %d\n",
> >I915_READ(BXT_CSR_DC3_DC5_COUNT));
> > }
> > --
> > 2.16.2
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on CFL and GLK
Since Coffee Lake uses the Kaby Lake DMC it's a safe
bet that the debug registers are the same. I haven't
double-checked that the GLK DMC uses the same registers
as BXT, but it seems as good of a guess as any.
v2: Add parentheses to silence warning
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c4cc8fef11a0..87be104347cd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2813,13 +2813,14 @@ static int i915_dmc_info(struct seq_file *m, void
*unused)
seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
CSR_VERSION_MINOR(csr->version));
- if (IS_KABYLAKE(dev_priv) ||
+ if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
(IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))) {
seq_printf(m, "DC3 -> DC5 count: %d\n",
I915_READ(SKL_CSR_DC3_DC5_COUNT));
seq_printf(m, "DC5 -> DC6 count: %d\n",
I915_READ(SKL_CSR_DC5_DC6_COUNT));
- } else if (IS_BROXTON(dev_priv) && csr->version >= CSR_VERSION(1, 4)) {
+ } else if (IS_GEMINILAKE(dev_priv) ||
+ (IS_BROXTON(dev_priv) && csr->version >= CSR_VERSION(1, 4)))
{
seq_printf(m, "DC3 -> DC5 count: %d\n",
I915_READ(BXT_CSR_DC3_DC5_COUNT));
}
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on CFL and GLK
Since Coffee Lake uses the Kaby Lake DMC it's a safe
bet that the debug registers are the same. I haven't
double-checked that the GLK DMC uses the same registers
as BXT, but it seems as good of a guess as any.
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c4cc8fef11a0..dad0776d58b4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2813,13 +2813,14 @@ static int i915_dmc_info(struct seq_file *m, void
*unused)
seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
CSR_VERSION_MINOR(csr->version));
- if (IS_KABYLAKE(dev_priv) ||
+ if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
(IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))) {
seq_printf(m, "DC3 -> DC5 count: %d\n",
I915_READ(SKL_CSR_DC3_DC5_COUNT));
seq_printf(m, "DC5 -> DC6 count: %d\n",
I915_READ(SKL_CSR_DC5_DC6_COUNT));
- } else if (IS_BROXTON(dev_priv) && csr->version >= CSR_VERSION(1, 4)) {
+ } else if (IS_GEMINILAKE(dev_priv) ||
+ IS_BROXTON(dev_priv) && csr->version >= CSR_VERSION(1, 4)) {
seq_printf(m, "DC3 -> DC5 count: %d\n",
I915_READ(BXT_CSR_DC3_DC5_COUNT));
}
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix incorrect comment
While the comment singles out Port A or B, the code says Port A or *D*. Looking at the history it seems that the comment was added after the code, so it seems likely that the code is correct, not the comment. CC: Jani Nikula CC: Rodrigo Vivi Signed-off-by: David Weinehall --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index f10a14330e7c..21d526bd4df6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -258,7 +258,7 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp) if (IS_CNL_WITH_PORT_F(dev_priv)) return 81; - /* For other SKUs, max rate on ports A and B is 5.4G */ + /* For other SKUs, max rate on ports A and D is 5.4G */ if (port == PORT_A || port == PORT_D) return 54; -- 2.16.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Display WA #0827 for NV12 to RGB switch
On Tue, Feb 06, 2018 at 04:36:42PM +0530, Vidya Srinivas wrote:
> From: Chandra Konduru
>
> Display WA #0827:
> Switching the plane format from NV12 to RGB and leaving system idle results
> in display underrun and corruption. WA: Set the bit 15 & bit 19 to 1b
> in the CLKGATE_DIS_PSL register for the pipe in which NV12 plane is enabled.
>
> Signed-off-by: Chandra Konduru
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_display.c | 16
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8f36023..c4af05e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3822,6 +3822,9 @@ enum {
> #define _CLKGATE_DIS_PSL_A 0x46520
> #define _CLKGATE_DIS_PSL_B 0x46524
> #define _CLKGATE_DIS_PSL_C 0x46528
> +#define DUPS1_GATING_DIS (1 << 15)
> +#define DUPS2_GATING_DIS (1 << 19)
> +#define DUPS3_GATING_DIS (1 << 23)
> #define DPF_GATING_DIS (1 << 10)
> #define DPF_RAM_GATING_DIS (1 << 9)
> #define DPFR_GATING_DIS(1 << 8)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 551c970..94faf3e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5495,6 +5495,20 @@ static void glk_pipe_scaler_clock_gating_wa(struct
> drm_i915_private *dev_priv,
> I915_WRITE(CLKGATE_DIS_PSL(pipe), val);
> }
>
> +static void skl_wa_clkgate(struct drm_i915_private *dev_priv,
> + int pipe, int enable)
> +{
> + if (pipe == PIPE_A || pipe == PIPE_B) {
> + if (enable)
> + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> + DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> + else
> + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> + I915_READ(CLKGATE_DIS_PSL(pipe)) &
> + ~(DUPS1_GATING_DIS|DUPS2_GATING_DIS));
> + }
> +}
> +
> static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
> struct drm_atomic_state *old_state)
> {
> @@ -5599,6 +5613,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> intel_wait_for_vblank(dev_priv, hsw_workaround_pipe);
> intel_wait_for_vblank(dev_priv, hsw_workaround_pipe);
> }
> + skl_wa_clkgate(dev_priv, pipe, 1);
> }
>
> static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force)
> @@ -5709,6 +5724,7 @@ static void haswell_crtc_disable(struct
> intel_crtc_state *old_crtc_state,
> intel_ddi_disable_pipe_clock(intel_crtc->config);
>
> intel_encoders_post_disable(crtc, old_crtc_state, old_state);
> + skl_wa_clkgate(dev_priv, intel_crtc->pipe, 0);
> }
Unless I'm misreading the context of this patch you're applying a workaround,
that by name seems to be for Skylake only, to: Haswell, Broadwell, and gen9+.
Either the name is incorrect, or the application of it.
As per BSpec the workaround seems to be for all of gen9 and only A-stepping of
gen10.
I don't see it listed for Haswell or Broadwell.
Cross-referencing the WA-database with Bspec, based on the HSD
link, it seems that this issue *might* be
WaDups1GatingDisableClockGatingForMPO; if this is the case it might
make sense to include that WA name too. At the very least
there should always be a comment mentioning the workaround name/number
and the platform(s) it applies to.
Also, according to the WA database, if the above mentioned issue really
is the same, the WA is *NOT* necessary on GLK (seeing as GLK uses gen10
display this might make sense, though the WA database sometimes contains
mistakes).
Regards, David
> static void i9xx_pfit_enable(struct intel_crtc *crtc)
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915/dp: Remove redundant sleep after AUX transaction length check.
On Fri, Jan 26, 2018 at 06:49:20PM -0800, Dhinakaran Pandiyan wrote:
> The core already takes care of the delay before retrying. The delay now
> changes to (500, 600)us instead of (500 + 1000, 600 + 1500)us.
Reviewed-by: David Weinehall
> Cc: Rodrigo Vivi
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_dp.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2454326690fb..97a4557053db 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1189,14 +1189,6 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
> if (recv_bytes == 0 || recv_bytes > 20) {
> DRM_DEBUG_KMS("Forbidden recv_bytes = %d on aux transaction\n",
> recv_bytes);
> - /*
> - * FIXME: This patch was created on top of a series that
> - * organize the retries at drm level. There EBUSY should
> - * also take care for 1ms wait before retrying.
> - * That aux retries re-org is still needed and after that is
> - * merged we remove this sleep from here.
> - */
> - usleep_range(1000, 1500);
> ret = -EBUSY;
> goto out;
> }
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] drm/i915/dp: Move comment about hw timeout to the right place.
On Fri, Jan 26, 2018 at 06:49:21PM -0800, Dhinakaran Pandiyan wrote:
> No functional change.
>
> Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_dp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 97a4557053db..06619998b5a3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1136,14 +1136,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
> DP_AUX_CH_CTL_TIME_OUT_ERROR |
> DP_AUX_CH_CTL_RECEIVE_ERROR);
>
> - if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> - continue;
> -
> /* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2
>* 400us delay required for errors and timeouts
>* Timeout errors from the HW already meet this
>* requirement so skip to next iteration
>*/
> + if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR)
> + continue;
> +
> if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) {
> usleep_range(400, 500);
> continue;
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915/psr: Extract PSR DPCD initialization and move it to intel_psr.c
On Fri, Jan 26, 2018 at 06:49:17PM -0800, Dhinakaran Pandiyan wrote:
> intel_edp_init_dpcd() is cluttered with PSR specific DPCD checks and
> intel_dp.c is huge.
Yes please! Good idea.
> No functional change intended.
Reviewed-by: David Weinehall
> Cc: Rodrigo Vivi
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_dp.c | 64 +
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 68
>
> 3 files changed, 70 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a2e88715..2454326690fb 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3135,35 +3135,6 @@ intel_dp_get_link_status(struct intel_dp *intel_dp,
> uint8_t link_status[DP_LINK_
> DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> }
>
> -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> -{
> - uint8_t psr_caps = 0;
> -
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_CAPS, &psr_caps) != 1)
> - return false;
> - return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
> -}
> -
> -static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
> -{
> - uint8_t dprx = 0;
> -
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
> - &dprx) != 1)
> - return false;
> - return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
> -}
> -
> -static bool intel_dp_get_alpm_status(struct intel_dp *intel_dp)
> -{
> - uint8_t alpm_caps = 0;
> -
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_RECEIVER_ALPM_CAP,
> - &alpm_caps) != 1)
> - return false;
> - return alpm_caps & DP_ALPM_CAP;
> -}
> -
> /* These are source-specific values. */
> uint8_t
> intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3714,40 +3685,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
> DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
>
> - /* Check if the panel supports PSR */
> - drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT,
> - intel_dp->psr_dpcd,
> - sizeof(intel_dp->psr_dpcd));
> - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> - dev_priv->psr.sink_support = true;
> - DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> - }
> -
> - if (INTEL_GEN(dev_priv) >= 9 &&
> - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> - uint8_t frame_sync_cap;
> -
> - dev_priv->psr.sink_support = true;
> - if (drm_dp_dpcd_readb(&intel_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> - &frame_sync_cap) != 1)
> - frame_sync_cap = 0;
> - dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
> - /* PSR2 needs frame sync as well */
> - dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> - DRM_DEBUG_KMS("PSR2 %s on sink",
> - dev_priv->psr.psr2_support ? "supported" : "not
> supported");
> -
> - if (dev_priv->psr.psr2_support) {
> - dev_priv->psr.y_cord_support =
> - intel_dp_get_y_cord_status(intel_dp);
> - dev_priv->psr.colorimetry_support =
> - intel_dp_get_colorimetry_status(intel_dp);
> - dev_priv->psr.alpm =
> - intel_dp_get_alpm_status(intel_dp);
> - }
> -
> - }
> + intel_psr_init_dpcd(intel_dp);
>
> /*
>* Read the eDP display control registers.
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3cee54bc0352..a340bc04dad8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1851,6 +1851,7 @@ bool is_hdcp_supported(struct drm_i915_private
> *dev_priv, enum port port);
>
> /* intel_psr.c */
> #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
> +void intel_psr_init_dpcd(struct intel_dp *intel_dp);
> void intel_psr_enable(struct intel_dp *intel_dp,
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915: only assign dev_priv->pch_id on successful pch detection
On Fri, Jan 26, 2018 at 04:48:05PM +0200, Jani Nikula wrote:
> Currently pch_id gets assigned also when there's no pch. It doesn't look
> like it makes a difference, but do the right thing anyway.
Makes sense.
Reviewed-by: David Weinehall
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3e8664de025d..0332e315650c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -183,8 +183,6 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
>
> id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>
> - dev_priv->pch_id = id;
> -
> if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> dev_priv->pch_type = PCH_IBX;
> DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> @@ -272,6 +270,8 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> continue;
> }
>
> + dev_priv->pch_id = id;
> +
> break;
> }
> if (!pch)
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: reduce indent in pch detection
On Fri, Jan 26, 2018 at 04:48:04PM +0200, Jani Nikula wrote:
> Save some horizontal space.
Yes, please!
Reviewed-by: David Weinehall
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 189
>
> 1 file changed, 96 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1ec12add34b2..3e8664de025d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -176,100 +176,103 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
>* of only checking the first one.
>*/
> while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> - if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> - unsigned short id = pch->device &
> INTEL_PCH_DEVICE_ID_MASK;
> -
> - dev_priv->pch_id = id;
> -
> - if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_IBX;
> - DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> - WARN_ON(!IS_GEN5(dev_priv));
> - } else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_CPT;
> - DRM_DEBUG_KMS("Found CougarPoint PCH\n");
> - WARN_ON(!IS_GEN6(dev_priv) &&
> - !IS_IVYBRIDGE(dev_priv));
> - } else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
> - /* PantherPoint is CPT compatible */
> - dev_priv->pch_type = PCH_CPT;
> - DRM_DEBUG_KMS("Found PantherPoint PCH\n");
> - WARN_ON(!IS_GEN6(dev_priv) &&
> - !IS_IVYBRIDGE(dev_priv));
> - } else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_LPT;
> - DRM_DEBUG_KMS("Found LynxPoint PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> - !IS_BROADWELL(dev_priv));
> - WARN_ON(IS_HSW_ULT(dev_priv) ||
> - IS_BDW_ULT(dev_priv));
> - } else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_LPT;
> - DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> - !IS_BROADWELL(dev_priv));
> - WARN_ON(!IS_HSW_ULT(dev_priv) &&
> - !IS_BDW_ULT(dev_priv));
> - } else if (id == INTEL_PCH_WPT_DEVICE_ID_TYPE) {
> - /* WildcatPoint is LPT compatible */
> - dev_priv->pch_type = PCH_LPT;
> - DRM_DEBUG_KMS("Found WildcatPoint PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> - !IS_BROADWELL(dev_priv));
> - WARN_ON(IS_HSW_ULT(dev_priv) ||
> - IS_BDW_ULT(dev_priv));
> - } else if (id == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE) {
> - /* WildcatPoint is LPT compatible */
> - dev_priv->pch_type = PCH_LPT;
> - DRM_DEBUG_KMS("Found WildcatPoint LP PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> - !IS_BROADWELL(dev_priv));
> - WARN_ON(!IS_HSW_ULT(dev_priv) &&
> - !IS_BDW_ULT(dev_priv));
> - } else if (id == INTEL_PCH_SPT_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_SPT;
> - DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) &&
> - !IS_KABYLAKE(dev_priv));
> - } else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
> - dev_priv->pch_type = PCH_SPT;
> - DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
> - W
Re: [Intel-gfx] [PATCH 09/10] drm/i915/cnl: Enable DDI-F on Cannonlake.
On Thu, Jan 25, 2018 at 02:03:29PM -0800, Rodrigo Vivi wrote:
> Now let's finish the Port-F support by adding the
> proper port F detection, irq and power well support.
lgtm,
Reviewed-by: David Weinehall
> v2: Rebase
> v3: Use BIT_ULL
> v4: Cover missed case on ddi init.
> v5: Update commit message.
> v6: Rebase on top of display headers rework.
> v7: Squash power-well handling related to DDI F to this
> patch to avoid warns as pointed out by DK.
>
> Cc: Dhinakaran Pandiyan
> Cc: Manasi Navare
> Cc: Ville Syrjälä
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_ddi.c| 4
> drivers/gpu/drm/i915/intel_display.c| 6 +-
> drivers/gpu/drm/i915/intel_display.h| 2 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 19 ---
> 5 files changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 076a49107e02..8261fe4c4316 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1304,6 +1304,7 @@ enum i915_power_well_id {
> SKL_DISP_PW_DDI_B,
> SKL_DISP_PW_DDI_C,
> SKL_DISP_PW_DDI_D,
> + CNL_DISP_PW_DDI_F = 6,
>
> GLK_DISP_PW_AUX_A = 8,
> GLK_DISP_PW_AUX_B,
> @@ -8945,6 +8946,7 @@ enum skl_power_gate {
> #define SFUSE_STRAP_RAW_FREQUENCY (1<<8)
> #define SFUSE_STRAP_DISPLAY_DISABLED(1<<7)
> #define SFUSE_STRAP_CRT_DISABLED(1<<6)
> +#define SFUSE_STRAP_DDIF_DETECTED (1<<3)
> #define SFUSE_STRAP_DDIB_DETECTED (1<<2)
> #define SFUSE_STRAP_DDIC_DETECTED (1<<1)
> #define SFUSE_STRAP_DDID_DETECTED (1<<0)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index e51559be2e3b..cfcd9cb37d5d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2946,6 +2946,10 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> intel_dig_port->ddi_io_power_domain =
> POWER_DOMAIN_PORT_DDI_E_IO;
> break;
> + case PORT_F:
> + intel_dig_port->ddi_io_power_domain =
> + POWER_DOMAIN_PORT_DDI_F_IO;
> + break;
> default:
> MISSING_CASE(port);
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 83de43ce1f3b..fe3c09184c2e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5647,6 +5647,8 @@ enum intel_display_power_domain
> intel_port_to_power_domain(enum port port)
> return POWER_DOMAIN_PORT_DDI_D_LANES;
> case PORT_E:
> return POWER_DOMAIN_PORT_DDI_E_LANES;
> + case PORT_F:
> + return POWER_DOMAIN_PORT_DDI_F_LANES;
> default:
> MISSING_CASE(port);
> return POWER_DOMAIN_PORT_OTHER;
> @@ -13619,7 +13621,7 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> if (found || IS_GEN9_BC(dev_priv))
> intel_ddi_init(dev_priv, PORT_A);
>
> - /* DDI B, C and D detection is indicated by the SFUSE_STRAP
> + /* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
>* register */
> found = I915_READ(SFUSE_STRAP);
>
> @@ -13629,6 +13631,8 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> intel_ddi_init(dev_priv, PORT_C);
> if (found & SFUSE_STRAP_DDID_DETECTED)
> intel_ddi_init(dev_priv, PORT_D);
> + if (found & SFUSE_STRAP_DDIF_DETECTED)
> + intel_ddi_init(dev_priv, PORT_F);
> /*
>* On SKL we don't have a way to detect DDI-E so we rely on VBT.
>*/
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 30fa2041a45f..c4042e342f50 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -157,11 +157,13 @@ enum intel_display_power_domain {
> POWER_DOMAIN_PORT_DDI_C_LANES,
> POWER_DOMAIN_PORT_DDI_D_LANES,
> POWER_DOMAIN_PORT_DDI_E_LANES,
> + POWER_DOMAIN_PORT_DDI_F_LANES,
> POWER_DOMAIN_PORT_DDI_A_IO,
> POWER_DOMAIN_PORT_DDI_B_IO,
> POWER_DOMAIN_PORT_DDI_C_IO,
> POWER_DOMAIN_PORT_DDI_D_IO,
> POWER_DOMAIN_PORT_DDI_E_IO,
> + POWER_DOMAIN_PORT_DD
Re: [Intel-gfx] [PATCH 02/10] drm/i915/cnl: Add AUX-F support
On Thu, Jan 25, 2018 at 02:03:22PM -0800, Rodrigo Vivi wrote:
> On some Cannonlake SKUs we have a dedicated Aux for port F,
> that is only the full split between port A and port E.
>
> There is still no Aux E for Port E, as in previous platforms,
> because port_E still means shared lanes with port A.
>
Looks good to me, except the dual sets of review comments and
signed-offs by, which seems kind of odd--did you squash two
patches into one?
Anyway, the code looks clean & documented, and the registers
seem to match documentation, so:
Reviewed-by: David Weinehall
> v2: Rebase.
> v3: Add couple missed PORT_F cases on intel_dp.
> v4: Rebase and fix commit message.
> v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
> v6: Rebase on top of display headers rework.
> v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
> v8: Fix Aux bits for Port F (DK)
> v9: Fix VBT definition of Port F (DK).
> v10: Squash power well addition to this patch to avoid
> warns as pointed by DK.
>
> Cc: Dhinakaran Pandiyan
> Cc: Lucas De Marchi
> Cc: Imre Deak
> Cc: Manasi Navare
> Cc: Ville Syrjälä
> Signed-off-by: Rodrigo Vivi
>
> drm/i915/cnl: Don't try to manage Port F power wells on all CNL.
>
> SKUs that lacks on the full port F split will just time out
> when touching this power well bits, causing a noisy warn.
>
> v2: Suggested-by: Imre. Temporarily remove the aux pw id after setting
> it instead of duplicating and redefining everything.
> v3: Simplify even more the logic, using one that don't mix the
> array size with the pw bits. Also add a comment.
>
> Cc: Dhinakaran Pandiyan
> Cc: Lucas De Marchi
> Cc: Imre Deak
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_irq.c | 6 ++
> drivers/gpu/drm/i915/i915_reg.h | 9 +
> drivers/gpu/drm/i915/intel_display.h| 1 +
> drivers/gpu/drm/i915/intel_dp.c | 8
> drivers/gpu/drm/i915/intel_runtime_pm.c | 21 +
> 6 files changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5702ebf17974..f89a1a0a25c8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1255,6 +1255,7 @@ enum modeset_restore {
> #define DP_AUX_B 0x10
> #define DP_AUX_C 0x20
> #define DP_AUX_D 0x30
> +#define DP_AUX_F 0x60
>
> #define DDC_PIN_B 0x05
> #define DDC_PIN_C 0x04
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f643d5ad7ff7..4d84b1c41a94 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2585,6 +2585,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> GEN9_AUX_CHANNEL_C |
> GEN9_AUX_CHANNEL_D;
>
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + tmp_mask |= CNL_AUX_CHANNEL_F;
> +
> if (iir & tmp_mask) {
> dp_aux_irq_handler(dev_priv);
> found = true;
> @@ -3623,6 +3626,9 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
> }
>
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + de_port_masked |= CNL_AUX_CHANNEL_F;
> +
> de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
> GEN8_PIPE_FIFO_UNDERRUN;
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 64933fd74cb6..44f46593172f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1312,6 +1312,7 @@ enum i915_power_well_id {
> CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
> CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
> CNL_DISP_PW_AUX_D,
> + CNL_DISP_PW_AUX_F,
>
> SKL_DISP_PW_1 = 14,
> SKL_DISP_PW_2,
> @@ -5284,6 +5285,13 @@ enum {
> #define _DPD_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64320)
> #define _DPD_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64324)
>
> +#define _DPF_AUX_CH_CTL (dev_priv->info.display_mmio_offset +
> 0x64510)
> +#define _DPF_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64514)
> +#define _DPF_AUX_CH_DATA2(dev_priv->info.display_mmio_offset + 0x64518)
> +#define _DPF_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6451c)
> +#define _DPF_AUX_CH_DATA4(dev
Re: [Intel-gfx] [PATCH] drm/i915: vbt defs typo fixes
On Thu, Jan 18, 2018 at 05:06:13PM +0200, Jani Nikula wrote:
> No more sing-a-ling.
LOL, well spotted.
> Reported-by: Adam Jackson
> Signed-off-by: Jani Nikula
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_vbt_defs.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index bbb173e116b3..fa4f67d3f261 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -227,7 +227,7 @@ struct bdb_general_features {
> #define DEVICE_TYPE_COMPOSITE_OUTPUT (1 << 9)
> #define DEVICE_TYPE_DUAL_CHANNEL (1 << 8)
> #define DEVICE_TYPE_HIGH_SPEED_LINK (1 << 6)
> -#define DEVICE_TYPE_LVDS_SINGALING (1 << 5)
> +#define DEVICE_TYPE_LVDS_SIGNALING (1 << 5)
> #define DEVICE_TYPE_TMDS_DVI_SIGNALING (1 << 4)
> #define DEVICE_TYPE_VIDEO_SIGNALING (1 << 3)
> #define DEVICE_TYPE_DISPLAYPORT_OUTPUT (1 << 2)
> @@ -243,7 +243,7 @@ struct bdb_general_features {
>DEVICE_TYPE_MIPI_OUTPUT | \
>DEVICE_TYPE_COMPOSITE_OUTPUT | \
>DEVICE_TYPE_DUAL_CHANNEL | \
> - DEVICE_TYPE_LVDS_SINGALING | \
> + DEVICE_TYPE_LVDS_SIGNALING | \
>DEVICE_TYPE_TMDS_DVI_SIGNALING | \
>DEVICE_TYPE_VIDEO_SIGNALING | \
>DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
> @@ -253,7 +253,7 @@ struct bdb_general_features {
> (DEVICE_TYPE_INTERNAL_CONNECTOR | \
>DEVICE_TYPE_MIPI_OUTPUT | \
>DEVICE_TYPE_COMPOSITE_OUTPUT | \
> - DEVICE_TYPE_LVDS_SINGALING | \
> + DEVICE_TYPE_LVDS_SIGNALING | \
>DEVICE_TYPE_TMDS_DVI_SIGNALING | \
>DEVICE_TYPE_VIDEO_SIGNALING | \
>DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bios: add DP max link rate to VBT child device struct
On Thu, Jan 18, 2018 at 05:04:59PM +0200, Jani Nikula wrote:
> Update VBT defs to reflect revision 216. While at it, default the
> expected child device struct size to sizeof the size rather than a
> hardcoded value.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_bios.c | 8 +---
> drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 51108ffc28d1..b820d595ebc8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1323,11 +1323,13 @@ parse_general_definitions(struct drm_i915_private
> *dev_priv,
> expected_size = LEGACY_CHILD_DEVICE_CONFIG_SIZE;
> } else if (bdb->version == 195) {
> expected_size = 37;
> - } else if (bdb->version <= 197) {
> + } else if (bdb->version <= 215) {
> expected_size = 38;
> + } else if (bdb->version <= 216) {
> + expected_size = 39;
> } else {
> - expected_size = 38;
> - BUILD_BUG_ON(sizeof(*child) < 38);
> + expected_size = sizeof(*child);
> + BUILD_BUG_ON(sizeof(*child) < 39);
> DRM_DEBUG_DRIVER("Expected child device config size for VBT
> version %u not known; assuming %u\n",
>bdb->version, expected_size);
> }
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index e3d7745a9151..bbb173e116b3 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -412,6 +412,8 @@ struct child_device_config {
> u16 dp_gpio_pin_num;/* 195 */
> u8 dp_iboost_level:4; /* 196 */
> u8 hdmi_iboost_level:4; /* 196 */
> + u8 dp_max_link_rate_reserved:6; /* 216 */
> + u8 dp_max_link_rate:2; /* 216 CNL+ */
Isn't the bitorder wrong here?
> } __packed;
>
> struct bdb_general_definitions {
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Write AVI infoframes for Parade LSPCON
On Wed, Dec 20, 2017 at 10:08:53AM +0530, Sharma, Shashank wrote:
> Thanks for the review, David.
>
> My comments, inline.
>
>
> Regards
>
> Shashank
>
>
> On 12/19/2017 3:43 PM, David Weinehall wrote:
> > On Mon, Dec 18, 2017 at 08:15:30PM +0100, Maarten Lankhorst wrote:
> > > Op 14-11-17 om 16:17 schreef Shashank Sharma:
> > > > Different LSPCON vendors specify their custom methods to pass
> > > > AVI infoframes to the LSPCON chip, so does Parade tech.
> > > >
> > > > This patch adds functions to arrange and write AVI infoframes
> > > > into Parade LSPCON chips.
> > > >
> > > > Signed-off-by: Shashank Sharma
> > > > ---
> > > > drivers/gpu/drm/i915/intel_lspcon.c | 119
> > > > +++-
> > > > 1 file changed, 118 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> > > > b/drivers/gpu/drm/i915/intel_lspcon.c
> > > > index 1ac4c47..77f0687 100644
> > > > --- a/drivers/gpu/drm/i915/intel_lspcon.c
> > > > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> > > > @@ -37,6 +37,12 @@
> > > > #define LSPCON_MCA_AVI_IF_KICKOFF (1 << 0)
> > > > #define LSPCON_MCA_AVI_IF_HANDLED (1 << 1)
> > > > +/* AUX addresses to write Parade AVI IF */
> > > > +#define LSPCON_PARADE_AVI_IF_WRITE_OFFSET 0x516
> > > > +#define LSPCON_PARADE_AVI_IF_CTRL 0x51E
> > > > +#define LSPCON_PARADE_AVI_IF_KICKOFF (1 << 7)
> > > > +#define LSPCON_PARADE_AVI_IF_DATA_SIZE 32
> > > > +
> > > > static struct intel_dp *lspcon_to_intel_dp(struct intel_lspcon
> > > > *lspcon)
> > > > {
> > > > struct intel_digital_port *dig_port =
> > > > @@ -241,6 +247,113 @@ static void lspcon_resume_in_pcon_wa(struct
> > > > intel_lspcon *lspcon)
> > > > DRM_DEBUG_KMS("LSPCON DP descriptor mismatch after resume\n");
> > > > }
> > > > +static bool lspcon_parade_fw_ready(struct drm_dp_aux *aux)
> > > > +{
> > > > + u8 avi_if_ctrl;
> > > > + u8 retry;
> > > > + ssize_t ret;
> > > > +
> > > > + /* Check if LSPCON FW is ready for data */
> > > > + for (retry = 0; retry < 5; retry++) {
> > > > +
> > Remove this newline.
> Why ? this is not accidental.
Because accidental or not you're not allowed to impose personal coding
style on the driver. Follow the example of the rest of the driver;
we don't insert leading blanklines inside for-blocks (or other blocks,
for that matter).
> > > > + if (retry)
> > > > + usleep_range(200, 300);
> > > > +
> > > > + ret = drm_dp_dpcd_read(aux, LSPCON_PARADE_AVI_IF_CTRL,
> > > > + &avi_if_ctrl, 1);
> > > > + if (ret < 0) {
> > > > + DRM_ERROR("Failed to read AVI IF control\n");
> > > > + return false;
> > > > + }
> > > > +
> > > > + if ((avi_if_ctrl & LSPCON_PARADE_AVI_IF_KICKOFF) == 0)
> > > > + return true;
> > > > + }
> > > > +
> > > > + DRM_ERROR("Parade FW not ready to accept AVI IF\n");
> > > > + return false;
> > > > +}
> > > > +
> > > > +static bool _lspcon_parade_write_infoframe_blocks(struct drm_dp_aux
> > > > *aux,
> > > > + uint8_t *avi_buf)
> > > > +{
> > > > + u8 avi_if_ctrl;
> > > > + u8 block_count = 0;
> > > > + u8 *data;
> > > > + uint16_t reg;
> > > > + ssize_t ret;
> > > > +
> > > > + while (block_count < 4) {
> > > > +
> > And this one.
> Same as above.
> - Shashank
> >
> > > > + if (!lspcon_parade_fw_ready(aux)) {
> > > > + DRM_DEBUG_KMS("LSPCON FW not ready, block %d\n",
> > > > + block_count);
> > > > + return false;
> > > > + }
> > > > +
> > > > + reg = LS
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Write AVI infoframes for Parade LSPCON
On Mon, Dec 18, 2017 at 08:15:30PM +0100, Maarten Lankhorst wrote:
> Op 14-11-17 om 16:17 schreef Shashank Sharma:
> > Different LSPCON vendors specify their custom methods to pass
> > AVI infoframes to the LSPCON chip, so does Parade tech.
> >
> > This patch adds functions to arrange and write AVI infoframes
> > into Parade LSPCON chips.
> >
> > Signed-off-by: Shashank Sharma
> > ---
> > drivers/gpu/drm/i915/intel_lspcon.c | 119
> > +++-
> > 1 file changed, 118 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> > b/drivers/gpu/drm/i915/intel_lspcon.c
> > index 1ac4c47..77f0687 100644
> > --- a/drivers/gpu/drm/i915/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> > @@ -37,6 +37,12 @@
> > #define LSPCON_MCA_AVI_IF_KICKOFF (1 << 0)
> > #define LSPCON_MCA_AVI_IF_HANDLED (1 << 1)
> >
> > +/* AUX addresses to write Parade AVI IF */
> > +#define LSPCON_PARADE_AVI_IF_WRITE_OFFSET 0x516
> > +#define LSPCON_PARADE_AVI_IF_CTRL 0x51E
> > +#define LSPCON_PARADE_AVI_IF_KICKOFF (1 << 7)
> > +#define LSPCON_PARADE_AVI_IF_DATA_SIZE 32
> > +
> > static struct intel_dp *lspcon_to_intel_dp(struct intel_lspcon *lspcon)
> > {
> > struct intel_digital_port *dig_port =
> > @@ -241,6 +247,113 @@ static void lspcon_resume_in_pcon_wa(struct
> > intel_lspcon *lspcon)
> > DRM_DEBUG_KMS("LSPCON DP descriptor mismatch after resume\n");
> > }
> >
> > +static bool lspcon_parade_fw_ready(struct drm_dp_aux *aux)
> > +{
> > + u8 avi_if_ctrl;
> > + u8 retry;
> > + ssize_t ret;
> > +
> > + /* Check if LSPCON FW is ready for data */
> > + for (retry = 0; retry < 5; retry++) {
> > +
Remove this newline.
> > + if (retry)
> > + usleep_range(200, 300);
> > +
> > + ret = drm_dp_dpcd_read(aux, LSPCON_PARADE_AVI_IF_CTRL,
> > + &avi_if_ctrl, 1);
> > + if (ret < 0) {
> > + DRM_ERROR("Failed to read AVI IF control\n");
> > + return false;
> > + }
> > +
> > + if ((avi_if_ctrl & LSPCON_PARADE_AVI_IF_KICKOFF) == 0)
> > + return true;
> > + }
> > +
> > + DRM_ERROR("Parade FW not ready to accept AVI IF\n");
> > + return false;
> > +}
> > +
> > +static bool _lspcon_parade_write_infoframe_blocks(struct drm_dp_aux *aux,
> > + uint8_t *avi_buf)
> > +{
> > + u8 avi_if_ctrl;
> > + u8 block_count = 0;
> > + u8 *data;
> > + uint16_t reg;
> > + ssize_t ret;
> > +
> > + while (block_count < 4) {
> > +
And this one.
> > + if (!lspcon_parade_fw_ready(aux)) {
> > + DRM_DEBUG_KMS("LSPCON FW not ready, block %d\n",
> > + block_count);
> > + return false;
> > + }
> > +
> > + reg = LSPCON_PARADE_AVI_IF_WRITE_OFFSET;
> > + data = avi_buf + block_count * 8;
> > + ret = drm_dp_dpcd_write(aux, reg, data, 8);
> > + if (ret < 0) {
> > + DRM_ERROR("Failed to write AVI IF block %d\n",
> > + block_count);
> > + return false;
> > + }
> > +
> > + /*
> > +* Once a block of data is written, we have to inform the FW
> > +* about this by writing into avi infoframe control register:
> > +* - set the kickoff bit[7] to 1
> > +* - write the block no. to bits[1:0]
> > +*/
> > + reg = LSPCON_PARADE_AVI_IF_CTRL;
> > + avi_if_ctrl = LSPCON_PARADE_AVI_IF_KICKOFF | block_count;
> > + ret = drm_dp_dpcd_write(aux, reg, &avi_if_ctrl, 1);
> > + if (ret < 0) {
> > + DRM_ERROR("Failed to update (0x%x), block %d\n",
> > + reg, block_count);
> > + return false;
> > + }
> > +
> > + block_count++;
> > + }
> > +
> > + DRM_DEBUG_KMS("Wrote AVI IF blocks successfully\n");
> > + return true;
> > +}
> > +
> > +static bool _lspcon_write_avi_infoframe_parade(struct drm_dp_aux *aux,
> > + const uint8_t *frame,
> > + ssize_t len)
> > +{
> > + uint8_t avi_if[LSPCON_PARADE_AVI_IF_DATA_SIZE] = {1, };
> > +
> > + /*
> > +* Parade's frames contains 32 bytes of data, divided
> > +* into 4 frames:
> > +* Token byte (first byte of first frame, must be non-zero)
> > +* HB0 to HB2 from AVI IF (3 bytes header)
> > +* PB0 to PB27 from AVI IF (28 bytes data)
> > +* So it should look like this
> > +* first block: ||
> > +* next 3 blocks:
> > +*/
> > +
> > + if (len > LSPCON_PARADE_AVI_IF_DATA_SIZE - 1) {
> > + DRM_ERROR("Invalid length of infoframes\n");
> > + return false;
> > + }
> > +
> > + memcpy(&avi_if[1], fr
Re: [Intel-gfx] [PATCH] drm/i915: add support for specifying DMC firmware override by module param
On Tue, Nov 21, 2017 at 11:54:16PM +0200, Jani Nikula wrote:
> On Tue, 21 Nov 2017, David Weinehall wrote:
> > On Tue, Nov 21, 2017 at 01:51:29PM +0200, Jani Nikula wrote:
> >> Use i915.dmc_firmware_path to override default firmware for the platform
> >> and bypassing version checks.
> >>
> >> Signed-off-by: Jani Nikula
> >>
> >> ---
> >>
> >> Untested.
> >
> > Yeah, it kind of shows. It fails to compile :D
>
> Oops. I was anxious to get the patch on the list in the heat of IRC
> discussion, and just added the disclaimer instead of doing this
> properly... *blush*
>
> >
> > But if you chuck in:
> >
> > param(char *, dmc_firmware_path, NULL) \
> >
> > in i915_params.h
> >
> > Things work correctly and you can use:
> >
> > Tested-by: David Weinehall
> > Reviewed-by: David Weinehall
>
> Thanks. But let's wait for more input on whether this is really what
> people want. Perhaps this is useful *regardless* of the outcome of the
> other discussions.
Fine by me. FWIW *we* (as in the PnP testing team) would definitely
benefit if this patch got merged, since we'd be able to simplify
automated testing of different versions of DMC.
> BR,
> Jani.
>
>
> >
> >> ---
> >> drivers/gpu/drm/i915/i915_params.c | 3 +++
> >> drivers/gpu/drm/i915/intel_csr.c | 9 +++--
> >> 2 files changed, 10 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_params.c
> >> b/drivers/gpu/drm/i915/i915_params.c
> >> index 3328147b4863..c11ad6d67fa9 100644
> >> --- a/drivers/gpu/drm/i915/i915_params.c
> >> +++ b/drivers/gpu/drm/i915/i915_params.c
> >> @@ -171,6 +171,9 @@ i915_param_named_unsafe(guc_firmware_path, charp, 0400,
> >> i915_param_named_unsafe(huc_firmware_path, charp, 0400,
> >>"HuC firmware path to use instead of the default one");
> >>
> >> +i915_param_named_unsafe(dmc_firmware_path, charp, 0400,
> >> + "DMC firmware path to use instead of the default one");
> >> +
> >> i915_param_named_unsafe(enable_dp_mst, bool, 0600,
> >>"Enable multi-stream transport (MST) for new DisplayPort sinks.
> >> (default: true)");
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> >> b/drivers/gpu/drm/i915/intel_csr.c
> >> index 77d8b3d483ca..82db376ec7e1 100644
> >> --- a/drivers/gpu/drm/i915/intel_csr.c
> >> +++ b/drivers/gpu/drm/i915/intel_csr.c
> >> @@ -296,7 +296,10 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
> >> *dev_priv,
> >>
> >>csr->version = css_header->version;
> >>
> >> - if (IS_CANNONLAKE(dev_priv)) {
> >> + if (csr->fw_path == i915_modparams.dmc_firmware_path) {
> >> + /* Bypass version check for firmware override. */
> >> + required_version = csr->version;
> >> + } else if (IS_CANNONLAKE(dev_priv)) {
> >>required_version = CNL_CSR_VERSION_REQUIRED;
> >>} else if (IS_GEMINILAKE(dev_priv)) {
> >>required_version = GLK_CSR_VERSION_REQUIRED;
> >> @@ -451,7 +454,9 @@ void intel_csr_ucode_init(struct drm_i915_private
> >> *dev_priv)
> >>if (!HAS_CSR(dev_priv))
> >>return;
> >>
> >> - if (IS_CANNONLAKE(dev_priv))
> >> + if (i915_modparams.dmc_firmware_path)
> >> + csr->fw_path = i915_modparams.dmc_firmware_path;
> >> + else if (IS_CANNONLAKE(dev_priv))
> >>csr->fw_path = I915_CSR_CNL;
> >>else if (IS_GEMINILAKE(dev_priv))
> >>csr->fw_path = I915_CSR_GLK;
> >> --
> >> 2.11.0
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add support for specifying DMC firmware override by module param
On Tue, Nov 21, 2017 at 01:51:29PM +0200, Jani Nikula wrote:
> Use i915.dmc_firmware_path to override default firmware for the platform
> and bypassing version checks.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> Untested.
Yeah, it kind of shows. It fails to compile :D
But if you chuck in:
param(char *, dmc_firmware_path, NULL) \
in i915_params.h
Things work correctly and you can use:
Tested-by: David Weinehall
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_params.c | 3 +++
> drivers/gpu/drm/i915/intel_csr.c | 9 +++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 3328147b4863..c11ad6d67fa9 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -171,6 +171,9 @@ i915_param_named_unsafe(guc_firmware_path, charp, 0400,
> i915_param_named_unsafe(huc_firmware_path, charp, 0400,
> "HuC firmware path to use instead of the default one");
>
> +i915_param_named_unsafe(dmc_firmware_path, charp, 0400,
> + "DMC firmware path to use instead of the default one");
> +
> i915_param_named_unsafe(enable_dp_mst, bool, 0600,
> "Enable multi-stream transport (MST) for new DisplayPort sinks.
> (default: true)");
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index 77d8b3d483ca..82db376ec7e1 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -296,7 +296,10 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
> *dev_priv,
>
> csr->version = css_header->version;
>
> - if (IS_CANNONLAKE(dev_priv)) {
> + if (csr->fw_path == i915_modparams.dmc_firmware_path) {
> + /* Bypass version check for firmware override. */
> + required_version = csr->version;
> + } else if (IS_CANNONLAKE(dev_priv)) {
> required_version = CNL_CSR_VERSION_REQUIRED;
> } else if (IS_GEMINILAKE(dev_priv)) {
> required_version = GLK_CSR_VERSION_REQUIRED;
> @@ -451,7 +454,9 @@ void intel_csr_ucode_init(struct drm_i915_private
> *dev_priv)
> if (!HAS_CSR(dev_priv))
> return;
>
> - if (IS_CANNONLAKE(dev_priv))
> + if (i915_modparams.dmc_firmware_path)
> + csr->fw_path = i915_modparams.dmc_firmware_path;
> + else if (IS_CANNONLAKE(dev_priv))
> csr->fw_path = I915_CSR_CNL;
> else if (IS_GEMINILAKE(dev_priv))
> csr->fw_path = I915_CSR_GLK;
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm
On Thu, Nov 16, 2017 at 08:24:02PM +0200, David Weinehall wrote: > On Wed, Nov 08, 2017 at 04:25:42PM +0200, David Weinehall wrote: > > On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote: > > > Now that we have CI, and that pm_rpm fully passes (I guess the audio > > > folks have implemented proper runtime pm for snd-hda, hooray, pls > > > confirm) it's time to enable this again by default. > > > > > > Real goal here is to have 1 configuration only that we fully support, > > > instead of tons of different codes with every user/customer tuning it > > > differently. And really, power stuff should work by default, and > > > should be enabled by everywhere where it is save to do so. > > > > > > v2: Completely new commit message, a few years passed since v1 ... > > > > > > Cc: Takashi Iwai > > > Cc: Liam Girdwood > > > Cc: "Yang, Libin" > > > Cc: "Lin, Mengdong" > > > Cc: "Li, Jocelyn" > > > Cc: "Kaskinen, Tanu" > > > Cc: "Zanoni, Paulo R" > > > Signed-off-by: Daniel Vetter > > > > lgtm, > > > > Reviewed-by: David Weinehall > > Been testing a bit; test results are a bit discouraging when it comes to > idle power consumption. > > Our nightly test suite logs idle power consumption before running any > tests, after running all tests, and then finally after running > powertop --auto-tune. > > The before and after cases are similar with and without patch, > but not so for the auto-tune case. > > Without this patch, powertop --auto-tune yields a massive improvement > (on NUC6i5 the power consumption drops with more than a factor of 3), > while with this patch the power consumption just drops with 10% or so. With the 10s => 0.1s bit of the patch reverted there's no longer any --auto-tune regression. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+
GEN6_RC_VIDEO_FREQ is deprecated for >= gen10;
don't try to program it.
v2: Use IS_GEN9() instead of INTEL_GEN() and remove comment (Rodrigo)
Signed-off-by: David Weinehall
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_pm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8c69ec9eb6ee..8f6c02477226 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6583,9 +6583,10 @@ static void gen9_enable_rps(struct drm_i915_private
*dev_priv)
{
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
- /* Program defaults and thresholds for RPS*/
- I915_WRITE(GEN6_RC_VIDEO_FREQ,
- GEN9_FREQUENCY(dev_priv->gt_pm.rps.rp1_freq));
+ /* Program defaults and thresholds for RPS */
+ if (IS_GEN9(dev_priv))
+ I915_WRITE(GEN6_RC_VIDEO_FREQ,
+ GEN9_FREQUENCY(dev_priv->gt_pm.rps.rp1_freq));
/* 1 second timeout*/
I915_WRITE(GEN6_RP_DOWN_TIMEOUT,
--
2.15.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm
On Wed, Nov 08, 2017 at 04:25:42PM +0200, David Weinehall wrote: > On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote: > > Now that we have CI, and that pm_rpm fully passes (I guess the audio > > folks have implemented proper runtime pm for snd-hda, hooray, pls > > confirm) it's time to enable this again by default. > > > > Real goal here is to have 1 configuration only that we fully support, > > instead of tons of different codes with every user/customer tuning it > > differently. And really, power stuff should work by default, and > > should be enabled by everywhere where it is save to do so. > > > > v2: Completely new commit message, a few years passed since v1 ... > > > > Cc: Takashi Iwai > > Cc: Liam Girdwood > > Cc: "Yang, Libin" > > Cc: "Lin, Mengdong" > > Cc: "Li, Jocelyn" > > Cc: "Kaskinen, Tanu" > > Cc: "Zanoni, Paulo R" > > Signed-off-by: Daniel Vetter > > lgtm, > > Reviewed-by: David Weinehall Been testing a bit; test results are a bit discouraging when it comes to idle power consumption. Our nightly test suite logs idle power consumption before running any tests, after running all tests, and then finally after running powertop --auto-tune. The before and after cases are similar with and without patch, but not so for the auto-tune case. Without this patch, powertop --auto-tune yields a massive improvement (on NUC6i5 the power consumption drops with more than a factor of 3), while with this patch the power consumption just drops with 10% or so. Judging by the powertop output it seems as though we're getting a lot of interrupts from i915. * * * Top 10 Power Consumers * * * With patch: Usage;Events/s;Category;Description 0,5%; 75,1;Interrupt;[124] i915 0,3%; 48,4;Process;/usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch 0,1%; 42,8;Timer;hrtimer_wakeup 0,0%; 34,9;Timer;tick_sched_timer 4,2%; 1,1;kWork;i915_hpd_poll_init_work 0,1%; 14,0;Process;python2 /opt/scripts/dut/dutlaunch/launch2.py --workspace=/opt/jenkins/workspace/Custom_test --iterations=1 idlepower_before un 0,0%; 13,3;Process;[rcu_preempt] 0,8%; 1,7;Process;python /opt/scripts/dut/perf-meter.py --avgskip 1 --name perf-meter --infofile /tmp/testname GLBenchmark testfw_app synmark2 he 0,0%; 3,0;Process;compiz 0,7%; 0,11;kWork;output_poll_execute Without the patch: Usage;Events/s;Category;Description 0,0%; 29,1;Timer;tick_sched_timer 0,1%; 19,9;Process;python2 /opt/scripts/dut/dutlaunch/launch.py --workspace=/opt/jenkins/workspace/Nightly_kernel_test/kernel/1510773665/SKL_6260U 0,0%; 13,2;Process;[rcu_preempt] 0,8%; 1,6;Process;python /opt/scripts/dut/perf-meter.py --avgskip 1 --name perf-meter --infofile /tmp/testname GLBenchmark testfw_app synmark2 he 0,0%; 2,5;Process;compiz 0,0%; 1,5;Process;java -jar slave.jar 0,0%; 1,2;Interrupt;[3] net_rx(softirq) 0,0%; 1,0;kWork;pci_pme_list_scan 0,0%; 0,9;Interrupt;[121] xhci_hcd 0,1%; 0,5;Process;perf-meter As can be seen the i915 driver doesn't even show up without the patch, while it's the main culprit with the patch. Just to eliminate DMC issues I'm going to do another run, but with DMC v1.27 instead of v1.26. Kind regards, David > > > --- > > drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > > b/drivers/gpu/drm/i915/intel_runtime_pm.c > > index 8315499452dc..dc24d008d8d4 100644 > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > > @@ -3232,7 +3232,7 @@ void intel_runtime_pm_enable(struct drm_i915_private > > *dev_priv) > > struct pci_dev *pdev = dev_priv->drm.pdev; > > struct device *kdev = &pdev->dev; > > > > - pm_runtime_set_autosuspend_delay(kdev, 1); /* 10s */ > > + pm_runtime_set_autosuspend_delay(kdev, 100); > > pm_runtime_mark_last_busy(kdev); > > > > /* > > @@ -3251,6 +3251,8 @@ void intel_runtime_pm_enable(struct drm_i915_private > > *dev_priv) > > pm_runtime_use_autosuspend(kdev); > > } > > > > + pm_runtime_allow(kdev); > > + > > /* > > * The core calls the driver load handler with an RPM reference held. > > * We drop that here and will reacquire it during unloading in > > -- > > 2.15.0.rc2 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915/cnl: Extend HDMI 2.0 support to CNL.
On Mon, Nov 13, 2017 at 10:47:44AM -0800, Rodrigo Vivi wrote:
> On Sat, Nov 11, 2017 at 09:43:44AM +, Sharma, Shashank wrote:
> > Regards
> >
> > Shashank
> >
> >
> > On 11/11/2017 3:56 AM, Rodrigo Vivi wrote:
> > > Starting on GLK we support HDMI 2.0. So this patch only
> > > extend the work Shashank has made to GLK to CNL.
> > >
> > > Cc: Paulo Zanoni
> > > Cc: Shashank Sharma
> > > Cc: Manasi Navare
> > > Signed-off-by: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 2d95db64cdf2..1b22b587e98c 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1235,7 +1235,7 @@ static int intel_hdmi_source_max_tmds_clock(struct
> > > intel_encoder *encoder)
> > > &dev_priv->vbt.ddi_port_info[encoder->port];
> > > int max_tmds_clock;
> > > - if (IS_GEMINILAKE(dev_priv))
> > > + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> > Would it be a good idea to create a new macro called IS_HDMI2_SUPPORTED() or
> > a function is_hdmi2_supported() where we keep all the GEN check ?
>
> I asked myself the same question.
> I believe a IS_HDMI2_SUPPORTED or HAS_HDMI2_SUPPORT is a good idea...
Typically we use HAS_* to check whether a feature is available,
and IS_* to identify a platform, or whether the parameter passed is of a certain
type.
So I believe HAS_HDMI2_SUPPORT would be correct if it's to check whether
the platform supports HDMI2.
> > > max_tmds_clock = 594000;
> > > else if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
> > > max_tmds_clock = 30;
> > > @@ -1511,7 +1511,8 @@ bool intel_hdmi_compute_config(struct intel_encoder
> > > *encoder,
> > > pipe_config->lane_count = 4;
> > > - if (scdc->scrambling.supported && IS_GEMINILAKE(dev_priv)) {
> > > + if (scdc->scrambling.supported && (IS_GEMINILAKE(dev_priv) ||
> > > +INTEL_GEN(dev_priv) >= 10) {
> > > if (scdc->scrambling.low_rates)
> > > pipe_config->hdmi_scrambling = true;
> > > @@ -2033,7 +2034,7 @@ void intel_hdmi_init_connector(struct
> > > intel_digital_port *intel_dig_port,
> > > connector->doublescan_allowed = 0;
> > > connector->stereo_allowed = 1;
> > > - if (IS_GEMINILAKE(dev_priv))
> > > + if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> > > connector->ycbcr_420_allowed = true;
> > Looks good otherwise.
> > - Shashank
> > > intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove pre-production pooled-EU w/a for Broxton
On Wed, Nov 15, 2017 at 06:06:53PM +, Chris Wilson wrote:
> Quoting David Weinehall (2017-11-15 18:01:41)
> > On Tue, Nov 14, 2017 at 01:51:16PM +, Chris Wilson wrote:
> > > WaEnablePooledEuFor2x6 only applies to preproduction models, unsupported
> > > since commit 0102ba1fd8af ("drm/i915: Add early BXT sdv to the list of
> > > preproduction machines").
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Jani Nikula
> >
> > Reviewed-by: David Weinehall
>
> Ta, hope your sdp is ok in the bin ;)
>
> Any volunteers for IS_GLK_REVID, IS_KBL_REVID ?
I don't think we should workarounds for pre-production GLK hardware
until there's actually production GLK hardware available :)
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove pre-production pooled-EU w/a for Broxton
On Tue, Nov 14, 2017 at 01:51:16PM +, Chris Wilson wrote:
> WaEnablePooledEuFor2x6 only applies to preproduction models, unsupported
> since commit 0102ba1fd8af ("drm/i915: Add early BXT sdv to the list of
> preproduction machines").
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 78bf7374fbdd..f609cfb7f1b2 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -235,16 +235,6 @@ static void gen9_sseu_info_init(struct drm_i915_private
> *dev_priv)
> #define IS_SS_DISABLED(ss) (!(sseu->subslice_mask & BIT(ss)))
> info->has_pooled_eu = hweight8(sseu->subslice_mask) == 3;
>
> - /*
> - * There is a HW issue in 2x6 fused down parts that requires
> - * Pooled EU to be enabled as a WA. The pool configuration
> - * changes depending upon which subslice is fused down. This
> - * doesn't affect if the device has all 3 subslices enabled.
> - */
> - /* WaEnablePooledEuFor2x6:bxt */
> - info->has_pooled_eu |= (hweight8(sseu->subslice_mask) == 2 &&
> - IS_BXT_REVID(dev_priv, 0,
> BXT_REVID_B_LAST));
> -
> sseu->min_eu_in_pool = 0;
> if (info->has_pooled_eu) {
> if (IS_SS_DISABLED(2) || IS_SS_DISABLED(0))
> --
> 2.15.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Remove pre-production Broxton register workarounds
On Tue, Nov 14, 2017 at 03:32:17PM +, Chris Wilson wrote: > Quoting Patchwork (2017-11-14 15:28:51) > > == Series Details == > > > > Series: series starting with [CI,1/2] drm/i915: Remove pre-production > > Broxton register workarounds > > URL : https://patchwork.freedesktop.org/series/33780/ > > State : success > > > > == Summary == > > > > Warning: bzip CI_DRM_3343/shard-glkb6/results34.json.bz2 wasn't in correct > > JSON format > > Test kms_busy: > > Subgroup extended-modeset-hang-newfb-with-reset-render-b: > > pass -> DMESG-WARN (shard-hsw) fdo#103038 > > > > fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038 > > > > shard-hswtotal:2584 pass:1471 dwarn:3 dfail:1 fail:10 > > skip:1099 time:9498s > > Blacklisted hosts: > > shard-apltotal:2584 pass:1623 dwarn:2 dfail:1 fail:22 skip:936 > > time:12986s > > shard-kbltotal:2450 pass:1630 dwarn:5 dfail:2 fail:23 skip:788 > > time:10001s > > shard-snbtotal:2584 pass:1200 dwarn:3 dfail:1 fail:12 > > skip:1368 time:7765s > > > > == Logs == > > > > For more details see: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7115/shards.html > > After a few months waiting for David Weinehall to wean himself off his > bxt sdp, I've given in and pushed. Thanks for the review, and yes we can > probably start reducing the unused macros for checking for preproduction > machines. I actually removed the BXT RVP from our farm a while ago, so that's fine :) Kind regards ,David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too
On Tue, Nov 14, 2017 at 03:05:03PM +0200, Valtteri Rantala wrote:
> Testing the texture read performance shows that the same tuning for the
> SQ credits is needed on GLK as on BXT/APL. This has been also confirmed
> by Altug from the HW team.
>
> Cc: Altug Koker
> Signed-off-by: Valtteri Rantala
With comments below, and unless Altug has objections:
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 70bbe8e..11fc0bd 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1093,6 +1093,15 @@ static int gen9_init_workarounds(struct
> intel_engine_cs *engine)
> /* WaDisableSTUnitPowerOptimization:skl,bxt,kbl,glk,cfl */
> WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN2, GEN8_ST_PO_DISABLE);
>
> + /* WaProgramL3SqcReg1DefaultForPerf:bxt,glk */
> + if (IS_BXT_REVID(dev_priv, BXT_REVID_B0, REVID_FOREVER) ||
> + IS_GEMINILAKE(dev_priv)) {
Since we've dropped workarounds for pre-production Broxtons,
I think this could/should be simplified to:
if (IS_BROXTON(dev_priv) || IS_GEMINILAKE(dev_priv)) {
or even
if (IS_GEN9_LP(dev_priv)) {
But that's just nitpicking. The fix is sound from a performance
perspective.
> + u32 val = I915_READ(GEN8_L3SQCREG1);
> + val &= ~L3_PRIO_CREDITS_MASK;
> + val |= L3_GENERAL_PRIO_CREDITS(62) | L3_HIGH_PRIO_CREDITS(2);
> + I915_WRITE(GEN8_L3SQCREG1, val);
> + }
> +
> /* WaOCLCoherentLineFlush:skl,bxt,kbl,cfl */
> I915_WRITE(GEN8_L3SQCREG4, (I915_READ(GEN8_L3SQCREG4) |
> GEN8_LQSC_FLUSH_COHERENT_LINES));
> @@ -1258,14 +1267,6 @@ static int bxt_init_workarounds(struct intel_engine_cs
> *engine)
> return ret;
> }
>
> - /* WaProgramL3SqcReg1DefaultForPerf:bxt */
> - if (IS_BXT_REVID(dev_priv, BXT_REVID_B0, REVID_FOREVER)) {
> - u32 val = I915_READ(GEN8_L3SQCREG1);
> - val &= ~L3_PRIO_CREDITS_MASK;
> - val |= L3_GENERAL_PRIO_CREDITS(62) | L3_HIGH_PRIO_CREDITS(2);
> - I915_WRITE(GEN8_L3SQCREG1, val);
> - }
> -
> /* WaToEnableHwFixForPushConstHWBug:bxt */
> if (IS_BXT_REVID(dev_priv, BXT_REVID_C0, REVID_FOREVER))
> WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
> --
> 2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+
On Fri, Nov 10, 2017 at 11:53:58AM -0800, Rodrigo Vivi wrote:
> On Fri, Nov 10, 2017 at 02:29:29PM +0000, David Weinehall wrote:
> > GEN6_RC_VIDEO_FREQ is deprecated for >= gen10;
> > don't try to program it.
> >
> > Signed-off-by: David Weinehall
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 07118c0b69d3..9f0ca3ae28f8 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6568,11 +6568,14 @@ static void gen9_enable_rps(struct drm_i915_private
> > *dev_priv)
> > {
> > intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> >
> > - /* Program defaults and thresholds for RPS*/
> > - I915_WRITE(GEN6_RC_VIDEO_FREQ,
> > - GEN9_FREQUENCY(dev_priv->gt_pm.rps.rp1_freq));
> > + /* Program defaults and thresholds for RPS */
> > +
> > + /* GEN6_RC_VIDEO_FREQ is deprecated for >= gen10 */
> > + if (INTEL_GEN(dev_priv) == 9)
>
> I believe if we use INTEL_GEN < 10 we can avoid the comment.
>
> I noticed now that we have nowadays other cases with INTEL_GEN ==
> so I wonder if this is our new trend or if we should stop doing this
> and use our old IS_GEN everywhere as possible... in this case IS_GEN9.
Right, IS_GEN9() would probably make more sense.
> I won't niptick on those... since the content itself of this patch
> is right according to the PM specs. So, one way or another fell free
> to use:
>
> Reviewed-by: Rodrigo Vivi
>
> > + I915_WRITE(GEN6_RC_VIDEO_FREQ,
> > + GEN9_FREQUENCY(dev_priv->gt_pm.rps.rp1_freq));
> >
> > - /* 1 second timeout*/
> > + /* 1 second timeout */
> > I915_WRITE(GEN6_RP_DOWN_TIMEOUT,
> > GT_INTERVAL_FROM_US(dev_priv, 100));
> >
> > --
> > 2.15.0
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+
GEN6_RC_VIDEO_FREQ is deprecated for >= gen10;
don't try to program it.
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/intel_pm.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 07118c0b69d3..9f0ca3ae28f8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6568,11 +6568,14 @@ static void gen9_enable_rps(struct drm_i915_private
*dev_priv)
{
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
- /* Program defaults and thresholds for RPS*/
- I915_WRITE(GEN6_RC_VIDEO_FREQ,
- GEN9_FREQUENCY(dev_priv->gt_pm.rps.rp1_freq));
+ /* Program defaults and thresholds for RPS */
+
+ /* GEN6_RC_VIDEO_FREQ is deprecated for >= gen10 */
+ if (INTEL_GEN(dev_priv) == 9)
+ I915_WRITE(GEN6_RC_VIDEO_FREQ,
+ GEN9_FREQUENCY(dev_priv->gt_pm.rps.rp1_freq));
- /* 1 second timeout*/
+ /* 1 second timeout */
I915_WRITE(GEN6_RP_DOWN_TIMEOUT,
GT_INTERVAL_FROM_US(dev_priv, 100));
--
2.15.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable runtime pm
On Tue, Nov 07, 2017 at 05:18:21PM +0100, Daniel Vetter wrote: > Now that we have CI, and that pm_rpm fully passes (I guess the audio > folks have implemented proper runtime pm for snd-hda, hooray, pls > confirm) it's time to enable this again by default. > > Real goal here is to have 1 configuration only that we fully support, > instead of tons of different codes with every user/customer tuning it > differently. And really, power stuff should work by default, and > should be enabled by everywhere where it is save to do so. > > v2: Completely new commit message, a few years passed since v1 ... > > Cc: Takashi Iwai > Cc: Liam Girdwood > Cc: "Yang, Libin" > Cc: "Lin, Mengdong" > Cc: "Li, Jocelyn" > Cc: "Kaskinen, Tanu" > Cc: "Zanoni, Paulo R" > Signed-off-by: Daniel Vetter lgtm, Reviewed-by: David Weinehall > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 8315499452dc..dc24d008d8d4 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -3232,7 +3232,7 @@ void intel_runtime_pm_enable(struct drm_i915_private > *dev_priv) > struct pci_dev *pdev = dev_priv->drm.pdev; > struct device *kdev = &pdev->dev; > > - pm_runtime_set_autosuspend_delay(kdev, 1); /* 10s */ > + pm_runtime_set_autosuspend_delay(kdev, 100); > pm_runtime_mark_last_busy(kdev); > > /* > @@ -3251,6 +3251,8 @@ void intel_runtime_pm_enable(struct drm_i915_private > *dev_priv) > pm_runtime_use_autosuspend(kdev); > } > > + pm_runtime_allow(kdev); > + > /* >* The core calls the driver load handler with an RPM reference held. >* We drop that here and will reacquire it during unloading in > -- > 2.15.0.rc2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.
On Tue, Oct 31, 2017 at 05:11:20PM -0700, Anusha Srivatsa wrote: > Calculate the time that GuC takes to load using > jiffies. This information could be very useful in > determining if GuC is taking unreasonably long time > to load in a certain platforms. > > v2: Calculate time before logs are collected. > Move the guc_load_time variable as a part of > intel_uc_fw struct. Store only final result > which is to be exported to debugfs. (Michal) > Add the load time in the print message as well. > > v3: Remove debugfs entry. Remove local variable > guc_finish_load. (Daniel, Tvrtko) > > v4: Use ktime_get() instead of jiffies. Use DRM_NOTE > if time taken to load is more than the threshold. On > load times within acceptable range, use DRM_DEBUG_DRIVER > (Tvrtko) > > v5: Rebased. Do not expose the load time variable in a global > struct (Tvrtko, Joonas) From my point of view (measuring suspend/resume times) knowing how much time is spent loading GuC & HuC is really useful, so it's definitely useful information. Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/20] drm/i915: Save all GT WAs and apply them at a later time
On Tue, Oct 31, 2017 at 09:30:27AM -0700, Oscar Mateo wrote: > > > On 10/31/2017 07:14 AM, Joonas Lahtinen wrote: > > On Mon, 2017-10-30 at 13:17 -0700, Oscar Mateo wrote: > > > By doing this, we can dump these workarounds in debugfs for validation > > > (which, > > > at the moment, we are only able to do for the contexts WAs). > > > > > > v2: > > >- Wrong macro used for MMIO set bit masked > > >- Improved naming > > >- Rebased > > > > > > v3: > > >- GT instead of MMIO (Chris, Mika) > > >- Leave L3_PRIO_CREDITS_MASK for a separate patch > > >- Rebased > > > > > > v4: Carry the init_early nomenclature over (Chris) > > > > > > Signed-off-by: Oscar Mateo > > > Cc: Mika Kuoppala > > > Cc: Ville Syrjälä > > > Reviewed-by: Chris Wilson > > This and the following patch are still a no-go and won't be merged. The > > required changes for the series to be accepted (to make it more > > declarative) were clearly described previously. If there are further > > questions, we should discuss those instead wasting time looking at > > respins that do not address the input given. > > > > Respins that ignore review are a waste of everyone's time. So, please > > react to the review instead of trying to brute force a series in as you > > see fit. > > > > Regards, Joonas > > My apologies, I wasn't trying to "brute force" anything. I haven't been able > to work on this for the last two weeks and I didn't want the issue to go > cold, so I sent a version to attend to Ville's and Chris' review comments > (this is useful anyway, because the same comments apply whether you go with > functions or with a static table). I am working on a version that implements > your suggestions and I will send it as soon as it's ready. Typically when submitting a changeset that isn't ready to be merged, you'd tag it RFC or similar. Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix SSEU Device Status.
On Fri, Oct 27, 2017 at 03:05:58PM -0700, Oscar Mateo wrote:
>
>
> On 10/25/2017 05:15 PM, Rodrigo Vivi wrote:
> > CNL adds an extra register for slice/subslice information.
> > Although no SKU is planed with an extra slice let's already
> > handle this extra piece of information so we don't have the
> > risk in future of getting a part that might have chosen this
> > part of the die instead of other slices or anything like that.
> >
> > Also if subslice is disabled the information of eu ack for that
> > is garbage, so let's skip checks for eu if subslice is disabled
> > as we skip the subslice if slice is disabled.
> >
> > The rest is pretty much like gen9.
> >
> > v2: Remove IS_CANNONLAKE from gen9 status function.
> >
> > v3: Consider s_max = 6 and ss_max=4 to run over all possible
> > slices and subslices possible by spec. Although no real
> > hardware will have that many slices/subslices.
> > To match with sseu info init.
> > v4: Fix offset calculation for slices 4 and 5.
> > Removed Oscar's rv-b since this change also needs review.
> > v5: Let's consider only valid bits for SLICE*_PGCTL_ACK.
> > This looks like wrong in Spec, but seems to be enough
> > for now. Whenever Spec gets updated and fixed we come
> > back and properly update the masks. Also add a FIXME,
> > so we can revisit this later when we find some strange
> > info on debugfs or when we noitce spec got updated.
> >
> > Cc: Oscar Mateo
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 61
> > +++--
> > drivers/gpu/drm/i915/i915_reg.h | 7 +
> > 2 files changed, 66 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index c65e381b85f3..61c466ff87e0 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4448,6 +4448,61 @@ static void cherryview_sseu_device_status(struct
> > drm_i915_private *dev_priv,
> > }
> > }
> > +static void gen10_sseu_device_status(struct drm_i915_private *dev_priv,
> > +struct sseu_dev_info *sseu)
> > +{
> > + const struct intel_device_info *info = INTEL_INFO(dev_priv);
> > + int s_max = 6, ss_max = 4;
> > + int s, ss;
> > + u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
> > +
> > + for (s = 0; s < s_max; s++) {
> > + /*
> > +* FIXME: Valid SS Mask respects the spec and read
> > +* only valid bits for those registers, excluding reserverd
> > +* although this seems wrong becuase it would leave many
>
> s/becuase/because
s/reserverd/reserved,/
> Seems like a look compromise (a corrected BSpec would be better, but
> ¯\_(ツ)_/¯)
>
> Reviewed-by: Oscar Mateo
>
> > +* subslices without ACK.
> > +*/
> > + s_reg[s] = I915_READ(GEN10_SLICE_PGCTL_ACK(s)) &
> > + GEN10_PGCTL_VALID_SS_MASK(s);
> > + eu_reg[2 * s] = I915_READ(GEN10_SS01_EU_PGCTL_ACK(s));
> > + eu_reg[2 * s + 1] = I915_READ(GEN10_SS23_EU_PGCTL_ACK(s));
> > + }
> > +
> > + eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
> > +GEN9_PGCTL_SSA_EU19_ACK |
> > +GEN9_PGCTL_SSA_EU210_ACK |
> > +GEN9_PGCTL_SSA_EU311_ACK;
> > + eu_mask[1] = GEN9_PGCTL_SSB_EU08_ACK |
> > +GEN9_PGCTL_SSB_EU19_ACK |
> > +GEN9_PGCTL_SSB_EU210_ACK |
> > +GEN9_PGCTL_SSB_EU311_ACK;
> > +
> > + for (s = 0; s < s_max; s++) {
> > + if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
> > + /* skip disabled slice */
> > + continue;
> > +
> > + sseu->slice_mask |= BIT(s);
> > + sseu->subslice_mask = info->sseu.subslice_mask;
> > +
> > + for (ss = 0; ss < ss_max; ss++) {
> > + unsigned int eu_cnt;
> > +
> > + if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
> > + /* skip disabled subslice */
> > + continue;
> > +
> > + eu_cnt = 2 * hweight32(eu_reg[2 * s + ss / 2] &
> > + eu_mask[ss % 2]);
> > + sseu->eu_total += eu_cnt;
> > + sseu->eu_per_subslice = max_t(unsigned int,
> > + sseu->eu_per_subslice,
> > + eu_cnt);
> > + }
> > + }
> > +}
> > +
> > static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
> > struct sseu_dev_info *sseu)
> > {
> > @@ -4483,7 +4538,7 @@ static void gen9_sseu_device_status(struct
> > drm_i915_private *dev_priv,
> > sseu->slice_mask |= BIT(s);
> > - if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv))
> > + if (IS_GEN9_BC(dev
Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6
On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo Spurio wrote: > > > On 26/10/17 03:32, Chris Wilson wrote: > > It has been many years since the last confirmed sighting (and fix) of an > > RC6 related bug (usually a system hang). Remove the parameter to stop > > users from setting dangerous values, as they often set it during triage > > and end up disabling the entire runtime pm instead (the option is not a > > fine scalpel!). > > > > Furthermore, it allows users to set known dangerous values which were > > intended for testing and not for production use. For testing, we can > > always patch in the required setting without having to expose ourselves > > to random abuse. > > > > v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document the > > lack of ilk support better. > > v3: Clear intel_info->rc6p if we don't support rc6 itself. > > > > Signed-off-by: Chris Wilson > > Cc: Rodrigo Vivi > > Cc: Joonas Lahtinen > > Cc: Jani Nikula > > Cc: Imre Deak > > Cc: Daniel Vetter > > Acked-by: Daniel Vetter > > --- > > I think that for execution/debug on early silicon we might still want the > ability to turn features like RC6 off. Maybe we can add a debug kconfig to > force info->has_rc6 = 0? Not a blocker to this patch but worth considering > IMO. Most of the BIOSes I've seen on our RVPs have had an option to disable RC6. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Get RC6 working.
On Mon, Oct 23, 2017 at 03:46:12PM -0700, Rodrigo Vivi wrote:
> On CNL, individual wake rate limit was added to each engine.
>
> GT can only go to RC6 if both Render and Media engines are
> individually qualified. So we need to set their individual
> wake rate limit.
>
> +-+---+--+--+
> | |GT RC6 | Render C6 | Media C6 |
> +-+---+--+--+
> | Wake rate limit | 0xA09C[31:16] | 0xA09C[15:0] | 0xA0A0[15:0] |
> +-+---+--+--+
>
> v2: - Tune Render and Media wake rate values according to some extra
> info I got from HW engineers. Value can be tuned, but for now
> these are the recommended values.
> - Fix typos pointed by James.
>
> Cc: Nathan Ciobanu
> Cc: Wayne Boyer
> Cc: Joe Konno
> Cc: David Weinehall
> Signed-off-by: Rodrigo Vivi
> Reviewed-by: James Ausmus
I've verified that RC6 works with your patch applied.
Minor comments below, but nothing major. Great work!
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 15 +++
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 68a58cce6ab1..f138eae82bf0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7905,6 +7905,7 @@ enum {
> #define GEN6_RC1_WAKE_RATE_LIMIT _MMIO(0xA098)
> #define GEN6_RC6_WAKE_RATE_LIMIT _MMIO(0xA09C)
> #define GEN6_RC6pp_WAKE_RATE_LIMIT _MMIO(0xA0A0)
> +#define GEN10_MEDIA_WAKE_RATE_LIMIT _MMIO(0xA0A0)
> #define GEN6_RC_EVALUATION_INTERVAL _MMIO(0xA0A8)
> #define GEN6_RC_IDLE_HYSTERSIS _MMIO(0xA0AC)
> #define GEN6_RC_SLEEP_MMIO(0xA0B0)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5fdae39b1969..742d5455b201 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6605,12 +6605,19 @@ static void gen9_enable_rc6(struct drm_i915_private
> *dev_priv)
> I915_WRITE(GEN6_RC_CONTROL, 0);
>
> /* 2b: Program RC6 thresholds.*/
> -
> - /* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is
> enabled */
> - if (IS_SKYLAKE(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 10) {
> + I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16 | 85);
> + I915_WRITE(GEN10_MEDIA_WAKE_RATE_LIMIT, 150);
> + } else if (IS_SKYLAKE(dev_priv)) {
How about:
} else if (NEEDS_WaRsDisableCoarsePowerGating(dev_priv)) {
I realise that this isn't code you're introducing, but fixing it at the
same time might make sense. We have a few other cases elsewhere with
where we apply Coarse PG even though (at least according to that
WA-test) we only need it on some Skylakes.
> + /*
> + * WaRsDoubleRc6WrlWithCoarsePowerGating:skl Doubling WRL only
> + * when CPG is enabled
> + */
> I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16);
> - else
> + } else {
> I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
> + }
> +
> I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
> I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
> for_each_engine(engine, dev_priv, id)
> --
> 2.13.5
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use bdw_ddi_translations_fdi for Broadwell
On Fri, Oct 13, 2017 at 04:47:35PM +0100, Chris Wilson wrote:
> The compiler warns:
>
> drivers/gpu/drm/i915/intel_ddi.c:118:35: warning:
> ‘bdw_ddi_translations_fdi’ defined but not used
>
> Lo and behold, if we look at intel_ddi_get_buf_trans_fdi(), it uses
> hsw_ddi_translations_fdi[] for both Haswell and *Broadwell*
Good catch, and thanks for fixing.
I noticed that the patch has already been reviewed and merged, so I
won't bother with an R-B.
Kind regards, David
> Fixes: 7d1c42e679f9 ("drm/i915: Refactor code to select the DDI buf
> translation table")
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: David Weinehall
> Cc: Jani Nikula
> Cc: # v4.12+
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b307b6fe1ce3..115162549914 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -734,8 +734,8 @@ intel_ddi_get_buf_trans_fdi(struct drm_i915_private
> *dev_priv,
> int *n_entries)
> {
> if (IS_BROADWELL(dev_priv)) {
> - *n_entries = ARRAY_SIZE(hsw_ddi_translations_fdi);
> - return hsw_ddi_translations_fdi;
> + *n_entries = ARRAY_SIZE(bdw_ddi_translations_fdi);
> + return bdw_ddi_translations_fdi;
> } else if (IS_HASWELL(dev_priv)) {
> *n_entries = ARRAY_SIZE(hsw_ddi_translations_fdi);
> return hsw_ddi_translations_fdi;
> --
> 2.15.0.rc0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaRsUseTimeoutMode
On Tue, Aug 22, 2017 at 04:58:28PM -0700, Rodrigo Vivi wrote:
> Apparently RC6 residency is lower than expected
> with EI mode for most of the cases on CNL A0, B0 and C0.
>
> This Wa doesn't solve our lower residency, but I
> believe it is better to have it since EI is not
> expected to work by HW engineers anyways.
>
> Cc: David Weinehall
> Cc: Mika Kuoppala
> Signed-off-by: Rodrigo Vivi
Sorry, I totally missed out on this one earlier. Looks correct,
and I've tested the patch on our CNL-Y without noticing any
regressions.
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 11 +--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7587ef53026b..cb017b7d8ccb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2967,6 +2967,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>
> #define CNL_REVID_A0 0x0
> #define CNL_REVID_B0 0x1
> +#define CNL_REVID_C0 0x2
>
> #define IS_CNL_REVID(p, since, until) \
> (IS_CANNONLAKE(p) && IS_REVID(p, since, until))
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d5ff0b9f999f..8c6d74d94799 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6456,7 +6456,7 @@ static void gen9_enable_rc6(struct drm_i915_private
> *dev_priv)
> {
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
> - uint32_t rc6_mask = 0;
> + u32 rc6_mode, rc6_mask = 0;
>
> /* 1a: Software RC state - RC0 */
> I915_WRITE(GEN6_RC_STATE, 0);
> @@ -6494,8 +6494,15 @@ static void gen9_enable_rc6(struct drm_i915_private
> *dev_priv)
> rc6_mask = GEN6_RC_CTL_RC6_ENABLE;
> DRM_INFO("RC6 %s\n", onoff(rc6_mask & GEN6_RC_CTL_RC6_ENABLE));
> I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
> +
> + /* WaRsUseTimeoutMode:cnl (pre-prod) */
> + if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_C0))
> + rc6_mode = GEN7_RC_CTL_TO_MODE;
> + else
> + rc6_mode = GEN6_RC_CTL_EI_MODE(1);
> +
> I915_WRITE(GEN6_RC_CONTROL,
> -GEN6_RC_CTL_HW_ENABLE | GEN6_RC_CTL_EI_MODE(1) | rc6_mask);
> +GEN6_RC_CTL_HW_ENABLE | rc6_mode | rc6_mask);
>
> /*
>* 3b: Enable Coarse Power Gating only when RC6 is enabled.
> --
> 2.13.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add has_psr-flag to gen9lp
On Thu, Sep 28, 2017 at 08:19:29PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add has_psr-flag to gen9lp > URL : https://patchwork.freedesktop.org/series/28488/ > State : success > > == Summary == > > Series 28488v1 drm/i915: Add has_psr-flag to gen9lp > https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/ > > Test kms_psr_sink_crc: > Subgroup psr_basic: > skip -> PASS (fi-glk-1) This seems relevant, and promising. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/13] drm/i915: Inherit Kabylake platform features from Skylake
On Thu, Sep 28, 2017 at 08:38:58PM +0100, Chris Wilson wrote:
> I recently tried to update the gen9 feature matrix and to my unpleasant
> surprise found that Kabylake still acted like Broadwell and didn't
> enable the feature. This is because kbl/cfl are inheriting their
> defaults from Broadwell and not Skylake.
>
> Signed-off-by: Chris Wilson
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_pci.c | 21 +
> 1 file changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index da60866b6628..01d4b569b2cc 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -495,13 +495,9 @@ static const struct intel_device_info
> intel_geminilake_info __initconst = {
> };
>
> #define KBL_PLATFORM \
> - BDW_FEATURES, \
> - .gen = 9, \
> + SKL_PLATFORM, \
> .platform = INTEL_KABYLAKE, \
> - .has_csr = 1, \
> - .has_guc = 1, \
> - .has_ipc = 1, \
> - .ddb_size = 896
> + .has_ipc = 1
This seems correct.
> static const struct intel_device_info intel_kabylake_gt1_info __initconst = {
> KBL_PLATFORM,
> @@ -520,13 +516,8 @@ static const struct intel_device_info
> intel_kabylake_gt3_info __initconst = {
> };
>
> #define CFL_PLATFORM \
> - BDW_FEATURES, \
> - .gen = 9, \
> - .platform = INTEL_COFFEELAKE, \
> - .has_csr = 1, \
> - .has_guc = 1, \
> - .has_ipc = 1, \
> - .ddb_size = 896
> + KBL_PLATFORM, \
> + .platform = INTEL_COFFEELAKE
As does this.
> static const struct intel_device_info intel_coffeelake_gt1_info __initconst
> = {
> CFL_PLATFORM,
> @@ -545,14 +536,12 @@ static const struct intel_device_info
> intel_coffeelake_gt3_info __initconst = {
> };
>
> static const struct intel_device_info intel_cannonlake_gt2_info __initconst
> = {
> - BDW_FEATURES,
> + SKL_PLATFORM,
> .is_alpha_support = 1,
> .platform = INTEL_CANNONLAKE,
> .gen = 10,
> .gt = 2,
> .ddb_size = 1024,
> - .has_csr = 1,
> - .has_ipc = 1,
> .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> };
But not this. Since you're inheriting SKL_PLATFORM rather than
KBL_PLATFORM you're missing out on .has_ipc = 1.
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp
On Thu, Sep 28, 2017 at 04:20:29AM +, Rodrigo Vivi wrote: > On Wed, Sep 27, 2017 at 5:14 AM David Weinehall < > david.weineh...@linux.intel.com> wrote: > > > On Tue, Aug 08, 2017 at 12:50:51PM -0700, Rodrigo Vivi wrote: > > > a long time ago I had agreed with Daniel that we would only add new > > > platforms after it was enabled by default on previous platforms. > > > a big reason for that is that we was willing to reduce the platforms > > > to validate and do better validation one by one before enabling. > > > > > > However now I believe it would be beneficial to have that supported > > > added so we can get more brave people using in different platforms so > > > we could capture more corner cases before we enable it by default. > > > Also we can still enable by default one platform at time if needed. > > > > > > So: > > > > > > Acked-by: Rodrigo Vivi > > > > > > I also checked the spec to see if there was anything else new or > > > different for these platforms and didn't find anything so: > > > > > > Reviewed-by: Rodrigo Vivi > > > > > > But let's wait a bit to merge to give Daniel or others a time to nack ;) > > > > An update: while testing revealed that our BXT-P RVP doesn't work with > > PSR, the GLK definitely does. CI would like to do PSR testing on GLK, > > which obviously isn't possible if PSR is reported as unsupported on GLK. > > > > Based on BSpec alone the PSR failure on BXT-P shouldn't be a > > Broxton/Apollo Lake issue, but rather an issue with the RVP board > > (or the panel), so I'd say that this patch still makes sense. > > > It would be very important if we could narrow down the issue on BXT. > Panel?! Bios?! Missing Workaround? Different user space? Agreed. I haven't been able to find any newer BIOS for that device, the user space should be the same. Missing workaround might well be the case, and the panel is definitely not the same as the one the GLK has. We have several other panels that could be tested with though. > One of the biggest problem with PSR is that when it works well in all > machines we have and we enable it we end up finding someone in the > community with a machine that does not work well. "Luckily" I own one of those machines :P > We have an opportunity to investigate and understand very well what > are the issues on this BXT. We shouldn't loose track of it. That opportunity is now rapidly fleeing, since the HW in question is a BXT B0, for which the "drop workarounds" patch series has already been submitted and gotten a R-B. > And maybe adding that to CI we will be forced to record the bug! ;) > > > > > After all it only changes gen9lp to report that they *can* support PSR > > (thus allowing for testing of PSR on such platforms), it doesn't enable > > it by default. > > > > So I'd like to nudge once more that this patch be merged. > > I agree. Let's add it. Also good to enable on CNL as well. If the panel > that you have there on CNL that is on CI doesn't support it you are about > to recurve some panels that does support PSR2. Yeah, enabling on CNL too makes sense and getting systematic PSR2 testing would be awesome. "recurve" => "receive"? Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp
On Tue, Aug 08, 2017 at 12:50:51PM -0700, Rodrigo Vivi wrote: > a long time ago I had agreed with Daniel that we would only add new > platforms after it was enabled by default on previous platforms. > a big reason for that is that we was willing to reduce the platforms > to validate and do better validation one by one before enabling. > > However now I believe it would be beneficial to have that supported > added so we can get more brave people using in different platforms so > we could capture more corner cases before we enable it by default. > Also we can still enable by default one platform at time if needed. > > So: > > Acked-by: Rodrigo Vivi > > I also checked the spec to see if there was anything else new or > different for these platforms and didn't find anything so: > > Reviewed-by: Rodrigo Vivi > > But let's wait a bit to merge to give Daniel or others a time to nack ;) An update: while testing revealed that our BXT-P RVP doesn't work with PSR, the GLK definitely does. CI would like to do PSR testing on GLK, which obviously isn't possible if PSR is reported as unsupported on GLK. Based on BSpec alone the PSR failure on BXT-P shouldn't be a Broxton/Apollo Lake issue, but rather an issue with the RVP board (or the panel), so I'd say that this patch still makes sense. After all it only changes gen9lp to report that they *can* support PSR (thus allowing for testing of PSR on such platforms), it doesn't enable it by default. So I'd like to nudge once more that this patch be merged. Daniel, any objections? Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Speed up DMC firmware loading
On Tue, Sep 05, 2017 at 02:25:36PM +0100, Chris Wilson wrote:
> Quoting David Weinehall (2017-09-05 14:10:50)
> > Currently we're doing:
> >
> > 1. acquire lock
> > 2. write word to hardware
> > 3. release lock
> > 4. repeat from 1
> >
> > to load the DMC firmware. Due to the cost of acquiring/releasing a lock,
> > and the size of the DMC firmware, this slows down DMC loading a lot.
> >
> > This patch simply acquires the lock, writes the entire firmware,
> > then releases the lock. Testing shows resume speedups
> > in the order of 10ms on platforms with DMC firmware (GEN9+).
> >
> > v2: Per feedback from Chris & Ville there's no need to do the whole
> > forcewake dance, so lose that bit (Chris, Ville)
> >
> > v3: Actually send the new version of the patch...
> >
> > v4: Don't acquire the uncore lock. Disable preempt. (Chris)
> >
> > Signed-off-by: David Weinehall
> > ---
> > drivers/gpu/drm/i915/intel_csr.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index 965988f79a55..cdfb624eb82d 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -252,8 +252,14 @@ void intel_csr_load_program(struct drm_i915_private
> > *dev_priv)
> > }
> >
> > fw_size = dev_priv->csr.dmc_fw_size;
> > + assert_rpm_wakelock_held(dev_priv);
> > +
> > + preempt_disable();
> > +
> > for (i = 0; i < fw_size; i++)
> > - I915_WRITE(CSR_PROGRAM(i), payload[i]);
> > + I915_WRITE_FW(CSR_PROGRAM(i), payload[i]);
> > +
> > + preempt_enable();
> >
> > for (i = 0; i < dev_priv->csr.mmio_count; i++) {
> > I915_WRITE(dev_priv->csr.mmioaddr[i],
>
> Looked into extending the coverage to the second loop?
The second loop didn't really show up in my benchmarks,
so I decided to minimise the changes.
The only other I915_WRITE() loops that show up when measuring
are the LUT loading; I'll fix those in a future patch.
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Speed up DMC firmware loading
Currently we're doing:
1. acquire lock
2. write word to hardware
3. release lock
4. repeat from 1
to load the DMC firmware. Due to the cost of acquiring/releasing a lock,
and the size of the DMC firmware, this slows down DMC loading a lot.
This patch simply acquires the lock, writes the entire firmware,
then releases the lock. Testing shows resume speedups
in the order of 10ms on platforms with DMC firmware (GEN9+).
v2: Per feedback from Chris & Ville there's no need to do the whole
forcewake dance, so lose that bit (Chris, Ville)
v3: Actually send the new version of the patch...
v4: Don't acquire the uncore lock. Disable preempt. (Chris)
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/intel_csr.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 965988f79a55..cdfb624eb82d 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -252,8 +252,14 @@ void intel_csr_load_program(struct drm_i915_private
*dev_priv)
}
fw_size = dev_priv->csr.dmc_fw_size;
+ assert_rpm_wakelock_held(dev_priv);
+
+ preempt_disable();
+
for (i = 0; i < fw_size; i++)
- I915_WRITE(CSR_PROGRAM(i), payload[i]);
+ I915_WRITE_FW(CSR_PROGRAM(i), payload[i]);
+
+ preempt_enable();
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
I915_WRITE(dev_priv->csr.mmioaddr[i],
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Speed up DMC firmware loading
On Mon, Sep 04, 2017 at 08:15:57PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-09-04 20:14:32)
> > Quoting David Weinehall (2017-09-04 20:08:06)
> > > Currently we're doing:
> > >
> > > 1. acquire lock
> > > 2. write word to hardware
> > > 3. release lock
> > > 4. repeat from 1
> > >
> > > to load the DMC firmware. Due to the cost of acquiring/releasing a lock,
> > > and the size of the DMC firmware, this slows down DMC loading a lot.
> > >
> > > This patch simply acquires the lock, writes the entire firmware,
> > > then releases the lock. Testing shows resume speedups
> > > in the order of 10ms on platforms with DMC firmware (GEN9+).
> > >
> > > v2: Per feedback from Chris & Ville there's no need to do the whole
> > > forcewake dance, so lose that bit (Chris, Ville)
> > >
> > > v3: Actually send the new version of the patch...
> > >
> > > Signed-off-by: David Weinehall
> > > ---
> > > drivers/gpu/drm/i915/intel_csr.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > > b/drivers/gpu/drm/i915/intel_csr.c
> > > index 965988f79a55..28ea24932ef1 100644
> > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > @@ -240,6 +240,7 @@ void intel_csr_load_program(struct drm_i915_private
> > > *dev_priv)
> > > {
> > > u32 *payload = dev_priv->csr.dmc_payload;
> > > uint32_t i, fw_size;
> > > + unsigned long flags;
> > >
> > > if (!HAS_CSR(dev_priv)) {
> > > DRM_ERROR("No CSR support available for this platform\n");
> > > @@ -252,8 +253,13 @@ void intel_csr_load_program(struct drm_i915_private
> > > *dev_priv)
> > > }
> > >
> > > fw_size = dev_priv->csr.dmc_fw_size;
> > > + assert_rpm_wakelock_held(dev_priv);
> > > + spin_lock_irqsave(&dev_priv->uncore.lock, flags);
> > > +
> > > for (i = 0; i < fw_size; i++)
> > > - I915_WRITE(CSR_PROGRAM(i), payload[i]);
> > > + I915_WRITE_FW(CSR_PROGRAM(i), payload[i]);
> > > +
> > > + spin_unlock_irqrestore(&dev_priv->uncore.lock, flags);
> >
> > Still would like to see the version without the uncore.lock. Afaict,
> > there isn't a requirement here -- unless you are serialising between
> > multiple users (concurrent intel_csr_load_program?) of CSR_PROGRAM.
>
> You may also want to consider a preempt_disable around this block as
> well, the argument being that we want the writes tightly grouped.
> -Chris
OK, I'll spin a non-spinning v4 tomorrow :)
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Speed up DMC firmware loading
On Mon, Sep 04, 2017 at 07:55:56PM +0100, Chris Wilson wrote: > Quoting David Weinehall (2017-09-04 19:38:04) > > v2: Per feedback from Chris & Ville there's no need to do the whole > > forcewake dance, so lose that bit (Chris, Ville) > > > @@ -251,9 +253,20 @@ void intel_csr_load_program(struct drm_i915_private > > *dev_priv) > > return; > > } > > > > + fw_domains = intel_uncore_forcewake_for_reg(dev_priv, > > + CSR_PROGRAM(0), > > + FW_REG_WRITE); > > + > > fw_size = dev_priv->csr.dmc_fw_size; > > + assert_rpm_wakelock_held(dev_priv); > > + spin_lock_irqsave(&dev_priv->uncore.lock, flags); > > + intel_uncore_forcewake_get__locked(dev_priv, fw_domains); > > Still there! Yeah, I missed the git add... Whooopsie; check v3. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Speed up DMC firmware loading
Currently we're doing:
1. acquire lock
2. write word to hardware
3. release lock
4. repeat from 1
to load the DMC firmware. Due to the cost of acquiring/releasing a lock,
and the size of the DMC firmware, this slows down DMC loading a lot.
This patch simply acquires the lock, writes the entire firmware,
then releases the lock. Testing shows resume speedups
in the order of 10ms on platforms with DMC firmware (GEN9+).
v2: Per feedback from Chris & Ville there's no need to do the whole
forcewake dance, so lose that bit (Chris, Ville)
v3: Actually send the new version of the patch...
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/intel_csr.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 965988f79a55..28ea24932ef1 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -240,6 +240,7 @@ void intel_csr_load_program(struct drm_i915_private
*dev_priv)
{
u32 *payload = dev_priv->csr.dmc_payload;
uint32_t i, fw_size;
+ unsigned long flags;
if (!HAS_CSR(dev_priv)) {
DRM_ERROR("No CSR support available for this platform\n");
@@ -252,8 +253,13 @@ void intel_csr_load_program(struct drm_i915_private
*dev_priv)
}
fw_size = dev_priv->csr.dmc_fw_size;
+ assert_rpm_wakelock_held(dev_priv);
+ spin_lock_irqsave(&dev_priv->uncore.lock, flags);
+
for (i = 0; i < fw_size; i++)
- I915_WRITE(CSR_PROGRAM(i), payload[i]);
+ I915_WRITE_FW(CSR_PROGRAM(i), payload[i]);
+
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, flags);
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
I915_WRITE(dev_priv->csr.mmioaddr[i],
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Speed up DMC firmware loading
Currently we're doing:
1. acquire lock
2. write word to hardware
3. release lock
4. repeat from 1
to load the DMC firmware. Due to the cost of acquiring/releasing a lock,
and the size of the DMC firmware, this slows down DMC loading a lot.
This patch simply acquires the lock, writes the entire firmware,
then releases the lock. Testing shows resume speedups
in the order of 10ms on platforms with DMC firmware (GEN9+).
v2: Per feedback from Chris & Ville there's no need to do the whole
forcewake dance, so lose that bit (Chris, Ville)
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/intel_csr.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 965988f79a55..b7a6ef7e0d53 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -239,7 +239,9 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
void intel_csr_load_program(struct drm_i915_private *dev_priv)
{
u32 *payload = dev_priv->csr.dmc_payload;
+ enum forcewake_domains fw_domains;
uint32_t i, fw_size;
+ unsigned long flags;
if (!HAS_CSR(dev_priv)) {
DRM_ERROR("No CSR support available for this platform\n");
@@ -251,9 +253,20 @@ void intel_csr_load_program(struct drm_i915_private
*dev_priv)
return;
}
+ fw_domains = intel_uncore_forcewake_for_reg(dev_priv,
+ CSR_PROGRAM(0),
+ FW_REG_WRITE);
+
fw_size = dev_priv->csr.dmc_fw_size;
+ assert_rpm_wakelock_held(dev_priv);
+ spin_lock_irqsave(&dev_priv->uncore.lock, flags);
+ intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
+
for (i = 0; i < fw_size; i++)
- I915_WRITE(CSR_PROGRAM(i), payload[i]);
+ I915_WRITE_FW(CSR_PROGRAM(i), payload[i]);
+
+ intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, flags);
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
I915_WRITE(dev_priv->csr.mmioaddr[i],
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Speed up DMC firmware loading
Currently we're doing:
1. acquire lock
2. write word to hardware
3. release lock
4. repeat from 1
to load the DMC firmware. Due to the cost of acquiring/releasing a lock,
and the size of the DMC firmware, this slows down DMC loading a lot.
This patch simply acquires the lock, writes the entire firmware,
then releases the lock. Testing shows resume speedups
in the order of 10ms on platforms with DMC firmware (GEN9+).
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/intel_csr.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 965988f79a55..b7a6ef7e0d53 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -239,7 +239,9 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
void intel_csr_load_program(struct drm_i915_private *dev_priv)
{
u32 *payload = dev_priv->csr.dmc_payload;
+ enum forcewake_domains fw_domains;
uint32_t i, fw_size;
+ unsigned long flags;
if (!HAS_CSR(dev_priv)) {
DRM_ERROR("No CSR support available for this platform\n");
@@ -251,9 +253,20 @@ void intel_csr_load_program(struct drm_i915_private
*dev_priv)
return;
}
+ fw_domains = intel_uncore_forcewake_for_reg(dev_priv,
+ CSR_PROGRAM(0),
+ FW_REG_WRITE);
+
fw_size = dev_priv->csr.dmc_fw_size;
+ assert_rpm_wakelock_held(dev_priv);
+ spin_lock_irqsave(&dev_priv->uncore.lock, flags);
+ intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
+
for (i = 0; i < fw_size; i++)
- I915_WRITE(CSR_PROGRAM(i), payload[i]);
+ I915_WRITE_FW(CSR_PROGRAM(i), payload[i]);
+
+ intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, flags);
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
I915_WRITE(dev_priv->csr.mmioaddr[i],
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: "Race-to-idle" on switching to the kernel context
On Wed, Aug 23, 2017 at 04:03:44PM +0100, Chris Wilson wrote: > Quoting David Weinehall (2017-08-23 15:54:13) > > On Fri, Aug 18, 2017 at 03:08:15PM +0100, Chris Wilson wrote: > > > During suspend we want to flush out all active contexts and their > > > rendering. To do so we queue a request from the kernel's context, once > > > we know that request is done, we know the GPU is completely idle. To > > > speed up that switch bump the GPU clocks. > > > > > > Switching to the kernel context prior to idling is also used to enforce > > > a barrier before changing OA properties, and when evicting active > > > rendering from the global GTT. All cases where we do want to > > > race-to-idle. > > > > > > Signed-off-by: Chris Wilson > > > Cc: David Weinehall > > > > No statistically significant speedup on suspend in our typical > > benchmark, but that one doesn't take into account systems in load--it > > suspends from idle, and from the description it seems that this patch > > would mostly affect systems with load. > > In terms of everything else, I doubt we ever are significantly waiting > for the GPU upon suspend, the user interface would finish showing its > "going to suspend" screen before starting the suspend, so its only going > to be background tasks still rendering to the gpu oblivious of the > incoming suspend. Rare -- I'm going to squirrel this patch away until we > have a need for it. I suspect that the most common use-case for suspend is laptops, triggered by the user closing the lid; ""going to suspend" screens are gonna go unseen by most users. > Thanks for the review and testing, and if you do come across a workload > which could benefit do let me know. It may well be that userspace isn't > as smart as I expect... I think the main reason that I didn't see much improvement in our benchmarks is the way we measure suspend times; to be able to get numbers that are comparable night after night we "normalise" the load by running a non-measured suspend/resume right before the one we actually measure. This means that by the time we benchmark we have already performed the flushing that your patch achieves, so the benefits of your patch wouldn't be visible. With your patch we get more stable results already on the first run, so there definitely is a benefit. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: "Race-to-idle" on switching to the kernel context
On Fri, Aug 18, 2017 at 03:08:15PM +0100, Chris Wilson wrote:
> During suspend we want to flush out all active contexts and their
> rendering. To do so we queue a request from the kernel's context, once
> we know that request is done, we know the GPU is completely idle. To
> speed up that switch bump the GPU clocks.
>
> Switching to the kernel context prior to idling is also used to enforce
> a barrier before changing OA properties, and when evicting active
> rendering from the global GTT. All cases where we do want to
> race-to-idle.
>
> Signed-off-by: Chris Wilson
> Cc: David Weinehall
No statistically significant speedup on suspend in our typical
benchmark, but that one doesn't take into account systems in load--it
suspends from idle, and from the description it seems that this patch
would mostly affect systems with load.
But no regression either, so I'm fine with the patch.
Tested-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 58a2a44f88bd..ca1423ad2708 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -895,6 +895,7 @@ int i915_gem_switch_to_kernel_context(struct
> drm_i915_private *dev_priv)
>
> for_each_engine(engine, dev_priv, id) {
> struct drm_i915_gem_request *req;
> + bool active = false;
> int ret;
>
> if (engine_has_kernel_context(engine))
> @@ -913,13 +914,17 @@ int i915_gem_switch_to_kernel_context(struct
> drm_i915_private *dev_priv)
> prev = i915_gem_active_raw(&tl->last_request,
> &dev_priv->drm.struct_mutex);
> if (prev)
> - i915_sw_fence_await_sw_fence_gfp(&req->submit,
> - &prev->submit,
> - GFP_KERNEL);
> + active |=
> i915_sw_fence_await_sw_fence_gfp(&req->submit,
> +
> &prev->submit,
> +
> GFP_KERNEL) > 0;
> }
>
> ret = i915_switch_context(req);
> +
> + if (active)
> + gen6_rps_boost(req, NULL);
> i915_add_request(req);
> +
> if (ret)
> return ret;
> }
> --
> 2.14.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: "Race-to-idle" on switching to the kernel context
On Mon, Aug 21, 2017 at 12:48:03PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Quoting Chris Wilson (2017-08-21 10:28:16)
> >> Quoting Mika Kuoppala (2017-08-21 10:17:52)
> >> > Chris Wilson writes:
> >> >
> >> > > During suspend we want to flush out all active contexts and their
> >> > > rendering. To do so we queue a request from the kernel's context, once
> >> > > we know that request is done, we know the GPU is completely idle. To
> >> > > speed up that switch bump the GPU clocks.
> >> > >
> >> > > Switching to the kernel context prior to idling is also used to enforce
> >> > > a barrier before changing OA properties, and when evicting active
> >> > > rendering from the global GTT. All cases where we do want to
> >> > > race-to-idle.
> >> > >
> >> > > Signed-off-by: Chris Wilson
> >> > > Cc: David Weinehall
> >> > > ---
> >> > > drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
> >> > > 1 file changed, 8 insertions(+), 3 deletions(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> >> > > b/drivers/gpu/drm/i915/i915_gem_context.c
> >> > > index 58a2a44f88bd..ca1423ad2708 100644
> >> > > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> >> > > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> >> > > @@ -895,6 +895,7 @@ int i915_gem_switch_to_kernel_context(struct
> >> > > drm_i915_private *dev_priv)
> >> > >
> >> > > for_each_engine(engine, dev_priv, id) {
> >> > > struct drm_i915_gem_request *req;
> >> > > + bool active = false;
> >> > > int ret;
> >> > >
> >> > > if (engine_has_kernel_context(engine))
> >> > > @@ -913,13 +914,17 @@ int i915_gem_switch_to_kernel_context(struct
> >> > > drm_i915_private *dev_priv)
> >> > > prev = i915_gem_active_raw(&tl->last_request,
> >> > >
> >> > > &dev_priv->drm.struct_mutex);
> >> > > if (prev)
> >> > > -
> >> > > i915_sw_fence_await_sw_fence_gfp(&req->submit,
> >> > > -
> >> > > &prev->submit,
> >> > > -
> >> > > GFP_KERNEL);
> >> > > + active |=
> >> > > i915_sw_fence_await_sw_fence_gfp(&req->submit,
> >> > > +
> >> > > &prev->submit,
> >> > > +
> >> > > GFP_KERNEL) > 0;
> >> >
> >> > There is no point of kicking the clocks if we are the only request left?
> >> >
> >> > Well logical as the request is empty, just pondering if the actual ctx
> >> > save/restore would finish quicker.
> >>
> >> I was thinking if it was just the context save itself, it not would be
> >> enough of a difference to justify itself. Just gut feeling and not
> >> measured, I worry about the irony of boosting from idle just to idle.
> >
> > Hmm, or we could be more precise and just set the clocks high rather
> > than queue a task. The complication isn't worth it for just a single
> > callsite, but I am contemplating supplying boost/clocks information
> > along with the request.
>
> For the purposes of suspend, I think the approach is simple and
> good enough.
>
> Can David give a Tested-by?
Didn't notice this until now, but I'll give it a whirl.
> Reviewed-by: Mika Kuoppala
>
> > -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp
On Tue, Aug 08, 2017 at 12:50:51PM -0700, Rodrigo Vivi wrote:
> a long time ago I had agreed with Daniel that we would only add new
> platforms after it was enabled by default on previous platforms.
> a big reason for that is that we was willing to reduce the platforms
> to validate and do better validation one by one before enabling.
>
> However now I believe it would be beneficial to have that supported
> added so we can get more brave people using in different platforms so
> we could capture more corner cases before we enable it by default.
> Also we can still enable by default one platform at time if needed.
>
> So:
>
> Acked-by: Rodrigo Vivi
>
> I also checked the spec to see if there was anything else new or
> different for these platforms and didn't find anything so:
>
> Reviewed-by: Rodrigo Vivi
>
> But let's wait a bit to merge to give Daniel or others a time to nack ;)
A bit more testing shows that while our GLK systems work perfectly fine
with PSR (and gets the expected power savings), the BXT system we tested
on didn't cope quite so well. I'll have to dig into this a bit to see
if there's something Broxton-related info on PSR in Bspec I missed,
or if it's just our BXT-P RVP that's buggy.
Kind regards, David
> Cheers,
> Rodrigo.
>
>
> On Tue, Aug 8, 2017 at 3:09 AM, David Weinehall
> wrote:
> > While testing Jim Bride's latest batch of PSR patches I noticed
> > that gen9lp doesn't include the has_psr flag, and that our GLK
> > system thus reported PSR as unsupported.
> >
> > This patch simply adds has_psr.
> >
> > Signed-off-by: David Weinehall
> > ---
> > 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 09d97e0990b7..11f0e8aa1fe4 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -377,6 +377,7 @@ static const struct intel_device_info
> > intel_skylake_gt3_info = {
> > .has_ddi = 1, \
> > .has_fpga_dbg = 1, \
> > .has_fbc = 1, \
> > + .has_psr = 1, \
> > .has_runtime_pm = 1, \
> > .has_pooled_eu = 0, \
> > .has_csr = 1, \
> > --
> > 2.14.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add has_psr-flag to gen9lp
On Tue, Aug 08, 2017 at 10:34:46AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Add has_psr-flag to gen9lp > URL : https://patchwork.freedesktop.org/series/28488/ > State : failure > > == Summary == > > Series 28488v1 drm/i915: Add has_psr-flag to gen9lp > https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/ > > Test gem_exec_suspend: > Subgroup basic-s3: > pass -> INCOMPLETE (fi-skl-6260u) SKL isn't GEN9LP, so this is unrelated. > Test kms_pipe_crc_basic: > Subgroup hang-read-crc-pipe-b: > dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 PineView isn't GEN9LP, so this is also unrelated. > fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 > > fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > time:442s > fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 > time:416s > fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 > time:358s > fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 > time:487s > fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:485s > fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 > time:523s > fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 > time:511s > fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:583s > fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:433s > fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:408s > fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 > time:417s > fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:497s > fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:473s > fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:460s > fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:564s > fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:579s > fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 > time:584s > fi-skl-6260u total:109 pass:105 dwarn:0 dfail:0 fail:0 skip:3 > fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:639s > fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:468s > fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 > time:423s > fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:487s > fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 > time:545s > fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 > time:405s > > 3d87f89058607b2a2adecf99ddb637a676b4df64 drm-tip: 2017y-08m-08d-09h-05m-05s > UTC integration manifest > 719c12b943ba drm/i915: Add has_psr-flag to gen9lp > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5338/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp
While testing Jim Bride's latest batch of PSR patches I noticed
that gen9lp doesn't include the has_psr flag, and that our GLK
system thus reported PSR as unsupported.
This patch simply adds has_psr.
Signed-off-by: David Weinehall
---
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 09d97e0990b7..11f0e8aa1fe4 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -377,6 +377,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.has_ddi = 1, \
.has_fpga_dbg = 1, \
.has_fbc = 1, \
+ .has_psr = 1, \
.has_runtime_pm = 1, \
.has_pooled_eu = 0, \
.has_csr = 1, \
--
2.14.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rpm: Use the quick mode by default
On Thu, Aug 03, 2017 at 01:43:39PM +0200, Daniel Vetter wrote:
> pm_rpm is one of the main offenders for long runtime in our full igt
> run. And hey, there's a quick option already, so make it the default.
>
> This means there's yet another way to enable stress tests, we really
> need to standardize this somehow. Or shred the stress-tests we really
> don't want/need anymore.
>
> Cc: Paulo Zanoni
> Cc: Arkadiusz Hiler
> Signed-off-by: Daniel Vetter
> ---
> tests/pm_rpm.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index 1873c9017b6e..8962bc3e56d8 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -1852,14 +1852,14 @@ static void fences_subtest(bool dpms)
> igt_assert(munmap(buf_ptr, params.fb.size) == 0);
> }
>
> -int rounds = 40;
> +int rounds = 10;
> bool stay = false;
>
> static int opt_handler(int opt, int opt_index, void *data)
> {
> switch (opt) {
> case 'q':
> - rounds = 10;
> + rounds = 50;
> break;
> case 's':
> stay = true;
> @@ -1874,10 +1874,10 @@ static int opt_handler(int opt, int opt_index, void
> *data)
> int main(int argc, char *argv[])
> {
> const char *help_str =
> -" --quick\t\tMake the stress-tests not stressful, for quick
> regression testing.\n"
> +" --stress\t\tMake the stress-tests more stressful, for quick
> regression testing.\n"
wouldn't adding more rounds make it *less* quick?
> " --stay\t\tDisable all screen and try to go into runtime pm.
> Useful for debugging.";
> static struct option long_options[] = {
> - {"quick", 0, 0, 'q'},
> + {"stress", 0, 0, 'q'},
> {"stay", 0, 0, 's'},
> { 0, 0, 0, 0 }
> };
> --
> 2.13.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: enable WaDisableDopClkGating for gen9
On Wed, Aug 02, 2017 at 12:24:33PM -0700, Rodrigo Vivi wrote:
> On Wed, Aug 2, 2017 at 10:34 AM, Praveen Paneri
> wrote:
> > This WA is required when decoupled frequencies for slice and unslice
> > are enabled. This disables DOP clock gating for gen9.
> >
> > v2: enable the WA for all gen9 platforms (not just for SKL GT4 where
> > the hang issue is originally reported) to avoid rare hangs (David)
> >
> > Cc: David Weinehall
> > Reviewed-by: David Weinehall
> > Signed-off-by: Praveen Paneri
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 3fc42aa..e369d77 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -88,6 +88,12 @@ static void gen9_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> > /* WaFbcHighMemBwCorruptionAvoidance:skl,bxt,kbl,cfl */
> > I915_WRITE(ILK_DPFC_CHICKEN, I915_READ(ILK_DPFC_CHICKEN) |
> >ILK_DPFC_DISABLE_DUMMY0);
> > +
> > + if (IS_GEN9(dev_priv)) {
>
> I believe we should go with IS_SKYLAKE(dev_priv)
Based on the info below that sounds sensible, yes. Good find.
> Bspec only list this Wa for:
> BDW: ALL
> CHV: UNTIL A7
>
> WaDatabase only list this to:
> SKL: SIWA_FOREVER
> BDW: SIWA_FOREVER
> CHV: SIWA_CHV_UNTIL_A7
> SNB: SIWA_UNTIL_GT_MOBILE_D0
Do we currently apply the fix on SNB?
I must say that the list of platforms seem a bit arbitrary though; it
seems weird that an issue on Sandybridge would disappear on Ivybridge
and Haswell, then resurface again on Broadwell...
Then again, it happens far too often in software land, so it might very
well be that it happens in hardware land too.
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/edp: Allow alternate fixed mode for eDP if available.
On Fri, Jul 28, 2017 at 12:22:29PM -0700, Jim Bride wrote:
> Some fixed resolution panels actually support more than one mode,
> with the only thing different being the refresh rate. Having this
> alternate mode available to us is desirable, because it allows us to
> test PSR on panels whose setup time at the preferred mode is too long.
> With this patch we allow the use of the alternate mode if it's
> available and it was specifically requested.
>
> v2 and v3: Rebase
> v4: * Fix up some leaky mode stuff (Chris)
> * Rebase
> v5: * Fix a NULL pointer derefreence (David Weinehall)
dereference
I've tested your patch series, and with the v5 version of this patch
plus the v4 versions of the other patches my Skylake laptop no longer
oopses on boot. I've also tested this on a Haswell laptop that had
working PSR even without this patch, to make sure that this doesn't
introduce any regressions.
Reviewed-by: David Weinehall
with minor nitpicks.
>
> Cc: David Weinehall
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Cc: Jani Nikula
> Cc: Chris Wilson
> Signed-off-by: Jim Bride
> ---
> drivers/gpu/drm/i915/intel_dp.c| 38
> +-
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_dsi.c | 2 +-
> drivers/gpu/drm/i915/intel_dvo.c | 2 +-
> drivers/gpu/drm/i915/intel_lvds.c | 3 ++-
> drivers/gpu/drm/i915/intel_panel.c | 6 ++
> 6 files changed, 45 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 7c0e530..60c4642 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1606,6 +1606,23 @@ static int intel_dp_compute_bpp(struct intel_dp
> *intel_dp,
> return bpp;
> }
>
> +static bool intel_edp_compare_alt_mode(struct drm_display_mode *m1,
> +struct drm_display_mode *m2)
> +{
> + bool bres = false;
> +
Whitespace error (git apply warns)
> + if (m1 && m2)
> + bres = (m1->hdisplay == m2->hdisplay &&
Dunno if it warns about this too, but methinks that double space is
erroneous.
> + m1->hsync_start == m2->hsync_start &&
> + m1->hsync_end == m2->hsync_end &&
> + m1->htotal == m2->htotal &&
> + m1->vdisplay == m2->vdisplay &&
> + m1->vsync_start == m2->vsync_start &&
> + m1->vsync_end == m2->vsync_end &&
> + m1->vtotal == m2->vtotal);
> + return bres;
> +}
> +
> bool
> intel_dp_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> @@ -1652,8 +1669,16 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> pipe_config->has_audio = intel_conn_state->force_audio ==
> HDMI_AUDIO_ON;
>
> if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
> - intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
> -adjusted_mode);
> + struct drm_display_mode *panel_mode =
> + intel_connector->panel.alt_fixed_mode;
> + struct drm_display_mode *req_mode = &pipe_config->base.mode;
> +
> + if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
> + panel_mode = intel_connector->panel.fixed_mode;
> +
> + drm_mode_debug_printmodeline(panel_mode);
> +
> + intel_fixed_panel_mode(panel_mode, adjusted_mode);
>
> if (INTEL_GEN(dev_priv) >= 9) {
> int ret;
> @@ -5810,6 +5835,7 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> struct drm_device *dev = intel_encoder->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_display_mode *fixed_mode = NULL;
> + struct drm_display_mode *alt_fixed_mode = NULL;
> struct drm_display_mode *downclock_mode = NULL;
> bool has_dpcd;
> struct drm_display_mode *scan;
> @@ -5865,13 +5891,14 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> }
> intel_connector->edid = edid;
>
> - /* prefer fixed mode from EDID if available */
> + /* prefer fixed mode from EDID if available, save an alt mode also */
> list_for_each_entry(scan, &connector->probed_modes, head) {
> if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
>
Re: [Intel-gfx] [PATCH] drm/i915: enable WaDisableDopClkGating for SKL GT4
On Sat, Jul 29, 2017 at 10:29:00AM +0530, Praveen Paneri wrote:
> This WA is required when decopled frequencies for slice
> and unslice are enabled. This disables DOP clock gating
> for SKL GT4.
>
> Cc: David Weinehall
> Signed-off-by: Praveen Paneri
Tested to fix hangs on GT4; I would suggest applying this fix
for all GEN 9 platforms though, not just SKL GT4e, even if that
platform is the only one where we've been able to trigger the
issue so far.
Anyway, the fix works and is correct, so:
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 48785ef..6dee3b6 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -78,6 +78,12 @@ static void gen9_init_clock_gating(struct drm_i915_private
> *dev_priv)
> /* WaFbcHighMemBwCorruptionAvoidance:skl,bxt,kbl,cfl */
> I915_WRITE(ILK_DPFC_CHICKEN, I915_READ(ILK_DPFC_CHICKEN) |
> ILK_DPFC_DISABLE_DUMMY0);
> +
> + if (IS_SKL_GT4(dev_priv)) {
> + /* WaDisableDopClockGating */
> + I915_WRITE(GEN7_MISCCPCTL, I915_READ(GEN7_MISCCPCTL)
> +& ~GEN7_DOP_CLOCK_GATE_ENABLE);
> + }
> }
>
> static void bxt_init_clock_gating(struct drm_i915_private *dev_priv)
> --
> 1.9.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later
On 2017-08-02 02:15, Pandiyan, Dhinakaran wrote: On Mon, 2017-07-31 at 15:41 -0700, Puthikorn Voravootivat wrote: But now you're suggesting another arbitrary narrow selection of panels based on limited evidence. I understand your point that the panel I observe is not the representative of the real world. My point is that we don't know that the panel will work or not unless we test all panel in the world. And blacklist would be too much work to maintain and whitelist would make this code too limited. As standard adoption should be better over time, I suggest that the newer panel should have better implement of the standard than older panel. And I suggest that eDP 1.4 should be a good heuristic for the "newer panel" based on these 2 reasons 1. Even though it is a limited evident, David and I independently saw unrelated eDP 1.3 panel that implement this feature incorrectly. 2. eDP 1.4 is the first version that support AUX backlight enablement. TCON vendor probably also make sure the AUX backlight brightness ajustment works when testing that feature. Is this make sense? Thanks. I tried to investigate this a little bit and found a device that reproduces the issue. The backlight does not come back up after a suspend-resume cycle because the PWM controller does not get enabled at resume. However, things just work at boot because the BIOS happens to enable PCH PWM at boot and the panel lights up via the BL_PWM_PIN. Like you said, this could be because some eDP 1.3 panels have a broken implementation and eDP 1.4 panels are better. Or, with the BL_PWM_PIN wired to the board, it simply overrides the DPCD settings. I decided to not disconnect the PWM pin and test this theory since this was a development laptop. In summary, I am not really sure blacklisting all eDP 1.3 panels is the best idea. Also, I don't know how many eDP 1.4 panels this has been tested to correctly work on. Anyway, since we have four panels that do not work, we could check if these are the same model/make etc. and blacklist them if there's a common thread. The panel in my system is made by LG, model LP140QH1-SPF1. Kind regards, David - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 RESEND 0/4] Kernel PSR Fix-ups
On Tue, Jul 25, 2017 at 09:48:07AM -0700, Jim Bride wrote: > These patches, along with an upcoming series for IGT, enable our > PSR IGT tests to run reliably once again on HSW, BDW, and SKL. > The first change enables us to run the PSR tests on some RVP platforms > whose panels have too slow of a setup time when running in their > preferred mode. The second fixes a minor problem with the way that > we were initializing SRD_CTL that caused us to clobber a bit that we > are not supposed to change in that register on SKL and KBL. The third > change re-introduces some changes to our link training code to be less > aggressive about changing link state for eDP, because PSR depends on > the link state being the same at PSR exit as it was at PSR entry. > The fourth change greatly increases the reliability of reading the > sink CRC generated by the eDP panel. > > v2 Highlights: >* Rebased to current drm-tip >* Greatly reduced looping around trying to read sink CRC (Jani) >* Reduce amount of changes in the sink CRC patch (Jani) >* Field-wise init of EDP_PSR_MAX_SLEEP_TIME (Rodrigo) >* Minor commit message / cover letter tweaks > > v3: >* Re-ordered patches to put reviewed patches first. >* Rebased to current drm-tip > > v4: >* Addressed review feedback (see patches for details) >* Rebase Is this a pure resend, or does it include any fixes on top of earlier versions? As mentioned elsewhere I experienced issues with both your previous patch series and the two before that one. I'll run a new testrun with this series just in case (it might be that the issues I noticed were caused by bad interaction with some other component). Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix kbuild error
On Tue, Jul 25, 2017 at 01:53:36PM +0100, Chris Wilson wrote:
> After rebasing af2788925ae0 ("drm/i915: Squelch reset messages during
> selftests"), I missed fixing up a call to i915_reset().
>
> Reported-by: kbuild test robot
> Fixes: af2788925ae0 ("drm/i915: Squelch reset messages during selftests")
> Signed-off-by: Chris Wilson
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> index 6896751ee919..7c55a4c7f4c9 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> @@ -842,7 +842,7 @@ static int igt_render_engine_reset_fallback(void *arg)
>
> mutex_lock(&i915->drm.struct_mutex);
> set_bit(I915_RESET_HANDOFF, &i915->gpu_error.flags);
> - i915_reset(i915);
> + i915_reset(i915, I915_RESET_QUIET);
> GEM_BUG_ON(test_bit(I915_RESET_HANDOFF,
> &i915->gpu_error.flags));
> mutex_unlock(&i915->drm.struct_mutex);
> --
> 2.13.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later
On Tue, Jul 25, 2017 at 03:41:46PM +0300, David Weinehall wrote: > On 2017-07-25 02:15, Puthikorn Voravootivat wrote: > > I saw a DP 1.3 panel that advertise AUX backlight brightness control > > but not working properly. So it should work but not in real world. > > I think that is good reason enough to add this as a heuristic. > > > > > Either key it on eDP 1.4 and hope that it's a reasonable expectation, > or employ a whitelist (potentially lots of effort adding all displays that > supports AUX backlight, but safe from regressions) or a blacklist > (potentially fewer displays need to be added, but risks introducing > regressions for end users). Sorry for the blurb in the previous mail, I replied from my official Intel address by mistake :S Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later
On 2017-07-25 02:15, Puthikorn Voravootivat wrote: I saw a DP 1.3 panel that advertise AUX backlight brightness control but not working properly. So it should work but not in real world. I think that is good reason enough to add this as a heuristic. Either key it on eDP 1.4 and hope that it's a reasonable expectation, or employ a whitelist (potentially lots of effort adding all displays that supports AUX backlight, but safe from regressions) or a blacklist (potentially fewer displays need to be added, but risks introducing regressions for end users). Kind regards, David - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later
On 2017-07-20 12:33, Jani Nikula wrote:
On Wed, 19 Jul 2017, "Pandiyan, Dhinakaran"
wrote:
On Wed, 2017-07-19 at 15:59 +0530, Jenny TC wrote:
With older panels, AUX pin for backlight doesn't work.
What evidence do you have to back up that claim?
Chapter 10.1 does, at least according to my reading, state that AUX CH
backlight control
requires eDP v1.4.
On some panels, this causes backlight issues on S3 resume.
What is it that we are missing in the resume path?
I suspect this isn't so much a resume issue, as a matter of some devices
by sheer luck (read by using the backlight set already on bootup)
keeping the right backlight level until after a suspend/resume cycle.
Enable the
feature only for eDP1.4 or later.
I can't find the eDP 1.4 requirement in the spec. Regional brightness
control was added in eDP 1.4, but we don't enable that. My concern is we
might be missing a real fix by ignoring < eDP 1.4 panels.
Agreed.
This has been going on too long now, with no real effort to get at the
roots of the problem. The right approach is to revert the regressing
commits now, and start over. Reverts posted [1].
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/27623/
Fix-suggested-by: Puthikorn Voravootivat
1. Please use the "Fixes" tag to refer to the commit that introduced the
code you are fixing.
2. The "Suggested-by" tag is more common to give credits to the person
who suggested the fix.
3. Please use the "Bugzilla" tag to point to the bug that David
reported.
Signed-off-by: Jenny TC
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index b25cd88..421f31f 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -292,7 +292,7 @@ static int intel_dp_aux_setup_backlight(struct
intel_connector *connector,
* via PWM pin or using AUX is better than using PWM pin.
*
* The heuristic to determine that using AUX pin is better than using PWM pin
is
- * that the panel support any of the feature list here.
+ * that the panel is eDP 1.4 or later and support any of the feature list here
* - Regional backlight brightness adjustment
* - Backlight PWM frequency set
* - More than 8 bits resolution of brightness level
@@ -310,6 +310,10 @@ static int intel_dp_aux_setup_backlight(struct
intel_connector *connector,
if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
return true;
+ /* Enable this for eDP 1.4 panel or later. */
+ if (intel_dp->edp_dpcd[0] < DP_EDP_14)
+ return false;
+
/* Panel supports regional backlight brightness adjustment */
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_GENERAL_CAP_3,
®_val) != 1) {
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"
On Tue, Jul 18, 2017 at 11:56:23AM -0700, Puthikorn Voravootivat wrote:
> May be the older panel might not work well with this feature.
> David/Jani, what do you think about adding check that the panel is eDP
> 1.4 or later in the heuristic?
While this patch might seem correct on the surface (with the patch
it now correctly prevents non-eDP 1.4 registers from being read on
sinks that aren't eDP 1.4 compliant), it still isn't correct
as per my understanding of the eDP 1.4 spec.
Chapter 10.1 of the eDP 1.4 spec clearly states that backlight through
AUX is an eDP v1.4 (and higher) feature.
The first conditional in this function will return true
if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
If so, the backlight will attempt to use AUX backlight control
even on eDP sinks with a lower revision than v1.4.
So, per my reading of the eDP v1.4 spec, the conditional should be
the very first thing in this function (my eDP v1.3 device works
fine if the eDP version checks is at the beginning of the function,
but fails if it's after the PWM pin cap check).
Kind regards, David
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index b25cd88fc1c5..e63f2296fd34 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -292,7 +292,7 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
> * via PWM pin or using AUX is better than using PWM pin.
> *
> * The heuristic to determine that using AUX pin is better than using
> PWM pin is
> - * that the panel support any of the feature list here.
> + * that the panel is eDP 1.4 or later and support any of the feature list
> here.
> * - Regional backlight brightness adjustment
> * - Backlight PWM frequency set
> * - More than 8 bits resolution of brightness level
> @@ -310,6 +310,10 @@ intel_dp_aux_display_control_heuristic(struct
> intel_connector *connector)
> if (!(intel_dp->edp_dpcd[2] &
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
> return true;
>
> + /* Enable this for eDP 1.4 panel or later. */
> + if (intel_dp->edp_dpcd[0] < DP_EDP_14)
> + return false;
> +
> /* Panel supports regional backlight brightness adjustment */
> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_GENERAL_CAP_3,
> ®_val) != 1) {
>
> On Mon, Jul 10, 2017 at 7:23 AM, David Weinehall
> wrote:
> > This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
> >
> > This patch has been identified to introduce a backlight regression
> > on at least two different platforms; either the heuristic is broken
> > (if so the patch needs to be reworked) or the in-kernel DPCD backlight
> > support is broken (if so it's premature to enable DPCD backlight
> > even if the platforms support it).
> >
> > Signed-off-by: David Weinehall
> > ---
> > drivers/gpu/drm/i915/i915_params.c| 7 ++-
> > drivers/gpu/drm/i915/i915_params.h| 1 -
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 61
> > ++-
> > 3 files changed, 6 insertions(+), 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 88b9d3e6713a..bec5ade371b0 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
> > .huc_firmware_path = NULL,
> > .enable_dp_mst = true,
> > .inject_load_failure = 0,
> > - .enable_dpcd_backlight = -1,
> > + .enable_dpcd_backlight = false,
> > .enable_gvt = false,
> > .enable_dbc = true,
> > };
> > @@ -247,10 +247,9 @@ MODULE_PARM_DESC(enable_dp_mst,
> > module_param_named_unsafe(inject_load_failure, i915.inject_load_failure,
> > uint, 0400);
> > MODULE_PARM_DESC(inject_load_failure,
> > "Force an error after a number of failure check points (0:disabled
> > (default), N:force failure at the Nth failure check point)");
> > -module_param_named_unsafe(enable_dpcd_backlight,
> > i915.enable_dpcd_backlight, int, 0600);
> > +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight,
> > bool, 0600);
> > MODULE_PARM_DESC(enable_dpcd_backlight,
> > - "Enable support for DPCD backlight control "
> > - "(-1:auto (default), 0:force disable, 1:force enabled if
> > supported");
> > + "Enable s
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "drm/i915: Add heuristic to determine better way to adjust brightness"
On Mon, Jul 10, 2017 at 02:25:39PM -, Patchwork wrote:
> == Series Details ==
>
> Series: Revert "drm/i915: Add heuristic to determine better way to adjust
> brightness"
> URL : https://patchwork.freedesktop.org/series/27065/
> State : failure
OK, seems I botched that one :S
Will geerate a new one tomorrow.
>
> == Summary ==
>
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> CHK include/generated/bounds.h
> CHK include/generated/timeconst.h
> CHK include/generated/asm-offsets.h
> CALLscripts/checksyscalls.sh
> CHK scripts/mod/devicetable-offsets.h
> CHK include/generated/compile.h
> CHK kernel/config_data.h
> CC [M] drivers/gpu/drm/i915/i915_params.o
> drivers/gpu/drm/i915/i915_params.c:66:2: error: unknown field
> ‘enable_dpcd_backlight’ specified in initializer
> .enable_dpcd_backlight = false,
> ^
> In file included from ./include/linux/module.h:18:0,
> from ./include/drm/drmP.h:59,
> from drivers/gpu/drm/i915/i915_drv.h:47,
> from drivers/gpu/drm/i915/i915_params.c:26:
> drivers/gpu/drm/i915/i915_params.c: In function
> ‘__check_enable_dpcd_backlight’:
> drivers/gpu/drm/i915/i915_params.c:250:47: error: ‘struct i915_params’ has no
> member named ‘enable_dpcd_backlight’
> module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
> 0600);
>^
> ./include/linux/moduleparam.h:346:68: note: in definition of macro
> ‘__param_check’
> static inline type __always_unused *__check_##name(void) { return(p); }
> ^
> ./include/linux/moduleparam.h:148:2: note: in expansion of macro
> ‘param_check_bool’
> param_check_##type(name, &(value)); \
> ^
> drivers/gpu/drm/i915/i915_params.c:250:1: note: in expansion of macro
> ‘module_param_named’
> module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
> 0600);
> ^
> drivers/gpu/drm/i915/i915_params.c: At top level:
> drivers/gpu/drm/i915/i915_params.c:250:47: error: ‘struct i915_params’ has no
> member named ‘enable_dpcd_backlight’
> module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
> 0600);
>^
> ./include/linux/moduleparam.h:227:54: note: in definition of macro
> ‘__module_param_call’
> VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } }
> ^
> ./include/linux/moduleparam.h:149:2: note: in expansion of macro
> ‘module_param_cb’
> module_param_cb(name, ¶m_ops_##type, &value, perm); \
> ^
> drivers/gpu/drm/i915/i915_params.c:250:1: note: in expansion of macro
> ‘module_param_named’
> module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
> 0600);
> ^
> scripts/Makefile.build:302: recipe for target
> 'drivers/gpu/drm/i915/i915_params.o' failed
> make[4]: *** [drivers/gpu/drm/i915/i915_params.o] Error 1
> scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed
> make[3]: *** [drivers/gpu/drm/i915] Error 2
> scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:1016: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"
This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
This patch has been identified to introduce a backlight regression
on at least two different platforms; either the heuristic is broken
(if so the patch needs to be reworked) or the in-kernel DPCD backlight
support is broken (if so it's premature to enable DPCD backlight
even if the platforms support it).
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_params.c| 7 ++-
drivers/gpu/drm/i915/i915_params.h| 1 -
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 61 ++-
3 files changed, 6 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 88b9d3e6713a..bec5ade371b0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
- .enable_dpcd_backlight = -1,
+ .enable_dpcd_backlight = false,
.enable_gvt = false,
.enable_dbc = true,
};
@@ -247,10 +247,9 @@ MODULE_PARM_DESC(enable_dp_mst,
module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint,
0400);
MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
-module_param_named_unsafe(enable_dpcd_backlight, i915.enable_dpcd_backlight,
int, 0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
0600);
MODULE_PARM_DESC(enable_dpcd_backlight,
- "Enable support for DPCD backlight control "
- "(-1:auto (default), 0:force disable, 1:force enabled if supported");
+ "Enable support for DPCD backlight control (default:false)");
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 057e203e6bda..6a88c76664db 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -53,7 +53,6 @@
func(int, edp_vswing); \
func(int, reset); \
func(unsigned int, inject_load_failure); \
- func(int, enable_dpcd_backlight); \
/* leave bools at the end to not create holes */ \
func(bool, alpha_support); \
func(bool, enable_cmd_parser); \
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index b25cd88fc1c5..f32dec02e540 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -277,66 +277,15 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
/* Check the eDP Display control capabilities registers to determine if
* the panel can support backlight control over the aux channel
*/
- if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
- (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
+ if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
+ (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
+ !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
{
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
}
-/*
- * Heuristic function whether we should use AUX for backlight adjustment or
not.
- *
- * We should use AUX for backlight brightness adjustment if panel doesn't this
- * via PWM pin or using AUX is better than using PWM pin.
- *
- * The heuristic to determine that using AUX pin is better than using PWM pin
is
- * that the panel support any of the feature list here.
- * - Regional backlight brightness adjustment
- * - Backlight PWM frequency set
- * - More than 8 bits resolution of brightness level
- * - Backlight enablement via AUX and not by BL_ENABLE pin
- *
- * If all above are not true, assume that using PWM pin is better.
- */
-static bool
-intel_dp_aux_display_control_heuristic(struct intel_connector *connector)
-{
- struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
- uint8_t reg_val;
-
- /* Panel doesn't support adjusting backlight brightness via PWN pin */
- if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
- return true;
-
- /* Panel supports regional backlight brightness adjustment */
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_GENERAL_CAP_3,
- ®_val) != 1) {
- DRM_DEBUG_KMS("Failed to read DPCD register 0x
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Inherit RPS stuff from previous platforms.
On Thu, Jul 06, 2017 at 01:41:13PM -0700, Rodrigo Vivi wrote:
> Apparently no change on RPS stuff from previous platforms.
>
> v2: Merging to rps related patches in one and also adding
> missed cases.
>
> Cc: David Weinehall
> Signed-off-by: Rodrigo Vivi
Double-checking BSpec didn't yield anything obvious, so:
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 20
> drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 18 +-
> 4 files changed, 24 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 643f56b..ca2e34b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1159,7 +1159,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
>
> reqf = I915_READ(GEN6_RPNSWREQ);
> - if (IS_GEN9(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 9)
> reqf >>= 23;
> else {
> reqf &= ~GEN6_TURBO_DISABLE;
> @@ -1181,7 +1181,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> rpdownei = I915_READ(GEN6_RP_CUR_DOWN_EI) & GEN6_CURIAVG_MASK;
> rpcurdown = I915_READ(GEN6_RP_CUR_DOWN) & GEN6_CURBSYTAVG_MASK;
> rpprevdown = I915_READ(GEN6_RP_PREV_DOWN) &
> GEN6_CURBSYTAVG_MASK;
> - if (IS_GEN9(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 9)
> cagf = (rpstat & GEN9_CAGF_MASK) >> GEN9_CAGF_SHIFT;
> else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> cagf = (rpstat & HSW_CAGF_MASK) >> HSW_CAGF_SHIFT;
> @@ -1210,7 +1210,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> dev_priv->rps.pm_intrmsk_mbz);
> seq_printf(m, "GT_PERF_STATUS: 0x%08x\n", gt_perf_status);
> seq_printf(m, "Render p-state ratio: %d\n",
> -(gt_perf_status & (IS_GEN9(dev_priv) ? 0x1ff00 :
> 0xff00)) >> 8);
> +(gt_perf_status & (INTEL_GEN(dev_priv) >= 9 ?
> 0x1ff00 : 0xff00)) >> 8);
> seq_printf(m, "Render p-state VID: %d\n",
> gt_perf_status & 0xff);
> seq_printf(m, "Render p-state limit: %d\n",
> @@ -1241,18 +1241,21 @@ static int i915_frequency_info(struct seq_file *m,
> void *unused)
>
> max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
> rp_state_cap >> 16) & 0xff;
> - max_freq *= (IS_GEN9_BC(dev_priv) ? GEN9_FREQ_SCALER : 1);
> + max_freq *= (IS_GEN9_BC(dev_priv) ||
> + IS_CANNONLAKE(dev_priv) ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Lowest (RPN) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
>
> max_freq = (rp_state_cap & 0xff00) >> 8;
> - max_freq *= (IS_GEN9_BC(dev_priv) ? GEN9_FREQ_SCALER : 1);
> + max_freq *= (IS_GEN9_BC(dev_priv) ||
> + IS_CANNONLAKE(dev_priv) ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
>
> max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
> rp_state_cap >> 0) & 0xff;
> - max_freq *= (IS_GEN9_BC(dev_priv) ? GEN9_FREQ_SCALER : 1);
> + max_freq *= (IS_GEN9_BC(dev_priv) ||
> + IS_CANNONLAKE(dev_priv) ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Max non-overclocked (RP0) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
> seq_printf(m, "Max overclocked frequency: %dMHz\n",
> @@ -1855,7 +1858,7 @@ static int i915_ring_freq_table(struct seq_file *m,
> void *unused)
> if (ret)
> goto out;
>
> - if (IS_GEN9_BC(dev_priv)) {
> + if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> /* Convert GT frequency to 50 HZ units */
> min_gpu_freq =
> dev_priv->rps.min_freq_softlimit / GEN9_FREQ_SCALER;
> @@ -1875,7 +187
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add option to support dynamic backlight via DPCD"
On Wed, Jul 05, 2017 at 05:40:19PM +0300, David Weinehall wrote: > On Wed, Jul 05, 2017 at 01:03:46PM +0300, Jani Nikula wrote: > > On Tue, 04 Jul 2017, David Weinehall > > wrote: > > > This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3. > > > > > > The introduction of dynamic backlight control causes > > > Lenovo ThinkPad X1 Carbon 4th Gen to boot to a black screen; > > > presumably the backlight is off. > > > > Oh, I thought reverting just this commit was not enough for you, based > > on the previous discussion in the patch thread. If this is enough, and > > the DPCD backlight by default works for you, I might be inclined to go > > with just defaulting to false here. > > Yeah, that was indeed my experience, but I cannot reproduce that > behaviour now; disabling DBC seems to be enough to make things work. > It might be that I made some mistake in my earlier testing. > > I retested now, with the following results: > > Both DPCD & DBC enabled: black screen > DBC enabled, DPCD disabled: works > DBC disabled, DPCD enabled: works > DBC disabled, DPCD disabled: works > > Based on my understanding of the code, DPCD backlight is required for > DBC to work, so it makes sense that disabling either of the two > makes things work (hence I don't understand how I got my earlier > result where just disabling DBC wasn't enough). > > Anyhow, I'm fine with just changing the default to false. I need to NAK my own revert. It turns out that while booting with only i915.enable_dbc=0 gives backlight, the backlight will only work until a suspend/resume cycle has taken place; after that the display will come up blank, unless i915.enable_dpcd_backlight=0 is also passed. So I'll submit a new revert. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add option to support dynamic backlight via DPCD"
On Wed, Jul 05, 2017 at 01:03:46PM +0300, Jani Nikula wrote:
> On Tue, 04 Jul 2017, David Weinehall wrote:
> > This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3.
> >
> > The introduction of dynamic backlight control causes
> > Lenovo ThinkPad X1 Carbon 4th Gen to boot to a black screen;
> > presumably the backlight is off.
>
> Oh, I thought reverting just this commit was not enough for you, based
> on the previous discussion in the patch thread. If this is enough, and
> the DPCD backlight by default works for you, I might be inclined to go
> with just defaulting to false here.
Yeah, that was indeed my experience, but I cannot reproduce that
behaviour now; disabling DBC seems to be enough to make things work.
It might be that I made some mistake in my earlier testing.
I retested now, with the following results:
Both DPCD & DBC enabled: black screen
DBC enabled, DPCD disabled: works
DBC disabled, DPCD enabled: works
DBC disabled, DPCD disabled: works
Based on my understanding of the code, DPCD backlight is required for
DBC to work, so it makes sense that disabling either of the two
makes things work (hence I don't understand how I got my earlier
result where just disabling DBC wasn't enough).
Anyhow, I'm fine with just changing the default to false.
Kind regards, David
> BR,
> Jani.
>
>
> >
> > Signed-off-by: David Weinehall
> > ---
> > drivers/gpu/drm/i915/i915_params.c| 5 -
> > drivers/gpu/drm/i915/i915_params.h| 3 +--
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26
> > --
> > 3 files changed, 1 insertion(+), 33 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 88b9d3e6713a..5b5ab15d191f 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -65,7 +65,6 @@ struct i915_params i915 __read_mostly = {
> > .inject_load_failure = 0,
> > .enable_dpcd_backlight = -1,
> > .enable_gvt = false,
> > - .enable_dbc = true,
> > };
> >
> > module_param_named(modeset, i915.modeset, int, 0400);
> > @@ -255,7 +254,3 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> > module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> > MODULE_PARM_DESC(enable_gvt,
> > "Enable support for Intel GVT-g graphics virtualization host
> > support(default:false)");
> > -
> > -module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
> > -MODULE_PARM_DESC(enable_dbc,
> > - "Enable support for dynamic backlight control (default:true)");
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> > b/drivers/gpu/drm/i915/i915_params.h
> > index 057e203e6bda..0d6cf9138dc4 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -67,8 +67,7 @@
> > func(bool, verbose_state_checks); \
> > func(bool, nuclear_pageflip); \
> > func(bool, enable_dp_mst); \
> > - func(bool, enable_gvt); \
> > - func(bool, enable_dbc)
> > + func(bool, enable_gvt)
> >
> > #define MEMBER(T, member) T member
> > struct i915_params {
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index b25cd88fc1c5..fea161727c6e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -173,24 +173,6 @@ static bool intel_dp_aux_set_pwm_freq(struct
> > intel_connector *connector)
> > return true;
> > }
> >
> > -/*
> > -* Set minimum / maximum dynamic brightness percentage. This value is
> > expressed
> > -* as the percentage of normal brightness in 5% increments.
> > -*/
> > -static bool
> > -intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> > - u32 min, u32 max)
> > -{
> > - u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> > -
> > - if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> > - dbc, sizeof(dbc)) < 0) {
> > - DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> > - return false;
> > - }
> > - return true;
> > -}
> > -
> > static void intel_dp_aux_enable_backlight(const struct intel_crtc_state
> > *crtc_state,
> > const struct drm_connector_state
>
[Intel-gfx] [PATCH] Revert "drm/i915: Add option to support dynamic backlight via DPCD"
This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3.
The introduction of dynamic backlight control causes
Lenovo ThinkPad X1 Carbon 4th Gen to boot to a black screen;
presumably the backlight is off.
Signed-off-by: David Weinehall
---
drivers/gpu/drm/i915/i915_params.c| 5 -
drivers/gpu/drm/i915/i915_params.h| 3 +--
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26 --
3 files changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 88b9d3e6713a..5b5ab15d191f 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -65,7 +65,6 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
.enable_dpcd_backlight = -1,
.enable_gvt = false,
- .enable_dbc = true,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -255,7 +254,3 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host
support(default:false)");
-
-module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
-MODULE_PARM_DESC(enable_dbc,
- "Enable support for dynamic backlight control (default:true)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 057e203e6bda..0d6cf9138dc4 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -67,8 +67,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
- func(bool, enable_gvt); \
- func(bool, enable_dbc)
+ func(bool, enable_gvt)
#define MEMBER(T, member) T member
struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index b25cd88fc1c5..fea161727c6e 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -173,24 +173,6 @@ static bool intel_dp_aux_set_pwm_freq(struct
intel_connector *connector)
return true;
}
-/*
-* Set minimum / maximum dynamic brightness percentage. This value is expressed
-* as the percentage of normal brightness in 5% increments.
-*/
-static bool
-intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
- u32 min, u32 max)
-{
- u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
-
- if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
- dbc, sizeof(dbc)) < 0) {
- DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
- return false;
- }
- return true;
-}
-
static void intel_dp_aux_enable_backlight(const struct intel_crtc_state
*crtc_state,
const struct drm_connector_state
*conn_state)
{
@@ -226,14 +208,6 @@ static void intel_dp_aux_enable_backlight(const struct
intel_crtc_state *crtc_st
if (intel_dp_aux_set_pwm_freq(connector))
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
- if (i915.enable_dbc &&
- (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
- if(intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0,
100)) {
- new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
- DRM_DEBUG_KMS("Enable dynamic brightness.\n");
- }
- }
-
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/edid: rename macro for CEA extended-tag
On Mon, Jul 03, 2017 at 08:41:53PM +0530, Shashank Sharma wrote:
> CEA-861-F introduces extended tag codes for EDID extension blocks,
> which indicates the actual type of the data block. The code for
> using exteded tag is 0x7, whereas in the existing code, the
> corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"
>
> This patch renames the macro and usages from "VIDEO_CAPABILITY_BLOCK"
> to "CEA_EXTENDED_TAG"
Hmmm, no it doesn't. It renames it to "USE_EXTENDED_TAG".
> V2: Add extended tag code check for video capabilitiy block (ville)
> V3: Ville:
> - Use suggested names for macros
> - Check the block length first, before checking the extended tag
>
> Cc: Ville Syrjala
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2e55599..8ae0c92 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2566,7 +2566,8 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> -#define VIDEO_CAPABILITY_BLOCK 0x07
> +#define USE_EXTENDED_TAG 0x07
> +#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> #define EDID_BASIC_AUDIO (1 << 6)
> #define EDID_CEA_YCRCB444(1 << 5)
> #define EDID_CEA_YCRCB422(1 << 4)
> @@ -3218,6 +3219,12 @@ cea_db_payload_len(const u8 *db)
> }
>
> static int
> +cea_db_extended_tag(const u8 *db)
> +{
> + return db[1];
> +}
> +
> +static int
> cea_db_tag(const u8 *db)
> {
> return db[0] >> 5;
> @@ -3793,8 +3800,10 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
> return false;
>
> for_each_cea_db(edid_ext, i, start, end) {
> - if (cea_db_tag(&edid_ext[i]) == VIDEO_CAPABILITY_BLOCK &&
> - cea_db_payload_len(&edid_ext[i]) == 2) {
> + if (cea_db_tag(&edid_ext[i]) == USE_EXTENDED_TAG &&
> + cea_db_payload_len(&edid_ext[i]) == 2 &&
> + cea_db_extended_tag(&edid_ext[i]) ==
> + EXT_VIDEO_CAPABILITY_BLOCK) {
> DRM_DEBUG_KMS("CEA VCDB 0x%02x\n", edid_ext[i + 2]);
> return edid_ext[i + 2] & EDID_CEA_VCDB_QS;
> }
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder
On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote: > There's quite a number of machines on the market, mainly Lenovo > ThinkPads, that make the horrible mistake in their firmware of reusing > the PCIBAR space reserved for the SMBus for things that are completely > unrelated to the SMBus controller, such as the OpRegion used for i915. > This is very bad and entirely evil, but with Lenovo's historically poor > track record of fixing their firmware, it is extremely unlikely this is > ever going to be properly fixed. > > So, while it would be nice if we could just cut off the SMBus controller > and call it a day this unfortunately breaks RMI4 mode completely for > most of the ThinkPads. Even though this behavior is extremely wrong, for > whatever reason sharing the PCIBAR between the OpRegion and SMBus seems > to be just fine. Regardless however, I think it's safe to assume that > when the BIOS accesses the PCIBAR space of the SMBus controller like > this that it's trying to get to something else that we mapped the SMBus > controller over. > > On my X1 Carbon, this assumption appears to be correct. I've traced down > the firmware accesses to being caused by the firmware mistakenly placing > the SWSCI mailbox for i915 on top of the SMBus host controller region. > And indeed, blacklisting i915 causes the firmware to never attempt to > touch this region. > > So, in order to try to workaround this and not break either SMBus or > i915, we temporarily unmap the PCI device for the SMBus controller, > do the thing that the firmware wanted to do, then remap the device and > report a firmware bug. > > Signed-off-by: Lyude > Cc: Rafael J. Wysocki > Cc: Benjamin Tissoires > Cc: Mika Westerberg > Cc: Jean Delvare > Cc: Wolfram Sang > Cc: intel-gfx@lists.freedesktop.org > --- > So: unfortunately > > a7ae81952cda (i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI > BAR) > > Seems to prevent the ThinkPad X1 Carbon 4th gen and the T460s from actually > using their SMBus controllers at all. As mentioned above, I've traced the > issue > down to the firmware responding to the SWSCI by sticking data in places it > shouldn't, e.g. the SMBus registers. > > I'm entirely unsure if this patch is the correct fix for this, and wouldn't be > at all surprised if it's just as bad of a patch as I think it is ;P. So I > figured I'd send it to intel-gfx and the authors of the original version of > this > patch to get their take on it and see if there might be something less hacky > we > can do to fix this. How does "that other" operating system handle this? FWIW I own a ThinkPad X1 Carbon 4th Gen, so I'm happy for your work on it :) Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD
On Tue, Jun 27, 2017 at 10:29:33PM +, Pandiyan, Dhinakaran wrote: > > > > On Tue, 2017-06-27 at 16:23 +0300, David Weinehall wrote: > > On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote: > > > On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote: > > > > This patch adds option to enable dynamic backlight for eDP > > > > panel that supports this feature via DPCD register and > > > > set minimum / maximum brightness to 0% and 100% of the > > > > normal brightness. > > > > > > This patch causes a regression on my ThinkPad X1 Carbon Gen 4; > > > with enable_dbc = true the backlight stays off; setting i915.enable_dbc=0 > > > on boot makes things work properly again. > > > > Some more testing indicates that while i915.enable_dbc=0 solves the > > initial issue of backlight not coming on, it's not enough--after > > suspend/resume the backlight stays off. > > > > Passing i915.enable_dpcd_backlight=0 seems to work both for the initial > > case of backlight not coming on at boot, and the issue with backlight > > not coming on after suspend/resume. > > > > So: > > > > DBC:1, DPCD: -1: blank screen on boot > > DBC:0, DPCD: -1: screen OK on boot, blank after suspend/resume > > DBC:1, DPCD: 0: screen OK on boot, screen OK after suspend/resume > > DBC:0, DPCD: 0: screen OK on boot, screen OK after suspend/resume > > > > So it seems that at least for the ThinkPad X1 Carbon Gen 4 (possibly > > limited to the 2560x1440 model) DPCD backlight isn't supported. > > > > Hi David, > > Thanks for the bug report. It's come a bit sooner than I expected > though. > > We shouldn't be enabling DPCD backlight control if the panel does not > support it. I'd like to look at the dmesg with drm.debug=0xE. We debug > log the panel capabilities early during boot and that will be useful. > Can you also provide the output of i915_dpcd in debugfs for the eDP > connector? > > I guess it makes sense to file an FDO and attach the logs there. https://bugs.freedesktop.org/show_bug.cgi?id=101619 Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop flushing of the object free list/worker from i915_gem_suspend
On Tue, Jun 27, 2017 at 06:37:31PM +0100, Chris Wilson wrote: > i915_gem_suspend() is called from all of our finalization paths > (suspend, hibernate, unload). i915_gem_drain_freed_objects() adds an > arbitrary delay as it uses an rcu_barrier() to ensure that there are no > more freed objects in flight, and this delay causes a large amount of > variability in suspend timings. For S3 suspend, we do not need to free > pages as doing so does not impact at all upon the system in its > suspended state, unlike S4 hibernation where we do want the hibernation > image to be as small as possible. Therefore we can forgo waiting inside > i915_gem_suspend(), so long as we ensure that we do cleanup before > unload (see i915_gem_load_cleanup()) and prefer to reap our objects > prior to hibernation (see i915_gem_freeze()). > > Removing the rcu_barrier() from i915_gem_suspend() improves S3 latency > by about 30ms on Skylake (ymmv). > > Reported-by: David Weinehall > Signed-off-by: Chris Wilson > Cc: David Weinehall Tested-by: David Weinehall Reviewed-by: David Weinehall > --- > drivers/gpu/drm/i915/i915_gem.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 36d838677982..f38c84e485ab 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -4597,8 +4597,6 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv) > while (flush_delayed_work(&dev_priv->gt.idle_work)) > ; > > - i915_gem_drain_freed_objects(dev_priv); > - > /* Assert that we sucessfully flushed all the work and >* reset the GPU back to its idle, low power state. >*/ > -- > 2.13.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD
On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote:
> On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> > This patch adds option to enable dynamic backlight for eDP
> > panel that supports this feature via DPCD register and
> > set minimum / maximum brightness to 0% and 100% of the
> > normal brightness.
>
> This patch causes a regression on my ThinkPad X1 Carbon Gen 4;
> with enable_dbc = true the backlight stays off; setting i915.enable_dbc=0
> on boot makes things work properly again.
Some more testing indicates that while i915.enable_dbc=0 solves the
initial issue of backlight not coming on, it's not enough--after
suspend/resume the backlight stays off.
Passing i915.enable_dpcd_backlight=0 seems to work both for the initial
case of backlight not coming on at boot, and the issue with backlight
not coming on after suspend/resume.
So:
DBC:1, DPCD: -1: blank screen on boot
DBC:0, DPCD: -1: screen OK on boot, blank after suspend/resume
DBC:1, DPCD: 0: screen OK on boot, screen OK after suspend/resume
DBC:0, DPCD: 0: screen OK on boot, screen OK after suspend/resume
So it seems that at least for the ThinkPad X1 Carbon Gen 4 (possibly
limited to the 2560x1440 model) DPCD backlight isn't supported.
Or possibly something is wrong with the DPCD backlight patch.
> > Signed-off-by: Puthikorn Voravootivat
> > Reviewed-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/i915_params.c| 5 +
> > drivers/gpu/drm/i915/i915_params.h| 3 ++-
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26
> > ++
> > 3 files changed, 33 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 5b5ab15d191f..88b9d3e6713a 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
> > .inject_load_failure = 0,
> > .enable_dpcd_backlight = -1,
> > .enable_gvt = false,
> > + .enable_dbc = true,
> > };
> >
> > module_param_named(modeset, i915.modeset, int, 0400);
> > @@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> > module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> > MODULE_PARM_DESC(enable_gvt,
> > "Enable support for Intel GVT-g graphics virtualization host
> > support(default:false)");
> > +
> > +module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
> > +MODULE_PARM_DESC(enable_dbc,
> > + "Enable support for dynamic backlight control (default:true)");
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> > b/drivers/gpu/drm/i915/i915_params.h
> > index 0d6cf9138dc4..057e203e6bda 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -67,7 +67,8 @@
> > func(bool, verbose_state_checks); \
> > func(bool, nuclear_pageflip); \
> > func(bool, enable_dp_mst); \
> > - func(bool, enable_gvt)
> > + func(bool, enable_gvt); \
> > + func(bool, enable_dbc)
> >
> > #define MEMBER(T, member) T member
> > struct i915_params {
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index fea161727c6e..b25cd88fc1c5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -173,6 +173,24 @@ static bool intel_dp_aux_set_pwm_freq(struct
> > intel_connector *connector)
> > return true;
> > }
> >
> > +/*
> > +* Set minimum / maximum dynamic brightness percentage. This value is
> > expressed
> > +* as the percentage of normal brightness in 5% increments.
> > +*/
> > +static bool
> > +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> > + u32 min, u32 max)
> > +{
> > + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> > +
> > + if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> > + dbc, sizeof(dbc)) < 0) {
> > + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> > + return false;
> > + }
> > + return true;
> > +}
> > +
> > static void intel_dp_aux_enable_backlight(const struct intel_crtc_state
> > *crtc_state,
> > const struct d
Re: [Intel-gfx] [PATCH v4 0/5] HPD support during suspend for BXT/APL.
On Mon, Jun 12, 2017 at 08:54:02PM +0530, Animesh Manna wrote: > Along with below patches sharing some background details/design. > - On BXT, Display cannot generate an interrupt when in D3. > - Without display in D3, S0ix can be achieved, Power impact will be zero if > d3 is blocked. PMCSR for Graphics/Display is irrelevant, as the power > management for them is taken care by the PUNIT using RC6/DC9 hints and *not* > through PMCSR write trigger. Does this apply to GLK as well? > > So solution is based on below principles: > - Display should not be put into D3 for HPD to work. > - With D0+DC9 we can achieve S0ix and at the same time helps to get the > interrupt. > - Using pci_save_state() during suspend to take control from OSPM and > blocking D3, while resuming, giving back to OSPM by pci_restore_state(). > - _DSM method is used to program pmc hpd control register to enable hpd > during suspend. > > Please have a look and send your comments/suggestions. > > v1: Initial version sent as RFC. > > v2: Updated version after addressing review comments from Imre,David. > > v3: Updated version after addressing review commnets from Imre, Ville, > Chris. > > v4: New version updated after bios changes on APL platform. > > Animesh Manna (5): > drm/i915/bxt: Corrected the guid for bxt. > drm/i915/bxt: VBT changes for hpd as wakeup feature > drm/i915/bxt: Added _DSM call to set HPD_CTL. > drm/i915/bxt: Block D3 during suspend. > drm/i915: Enable HPD interrupts with master ctl interrupt > > drivers/gpu/drm/i915/i915_drv.c | 5 +++ > drivers/gpu/drm/i915/i915_drv.h | 3 ++ > drivers/gpu/drm/i915/i915_irq.c | 69 > +++-- > drivers/gpu/drm/i915/i915_reg.h | 8 > drivers/gpu/drm/i915/intel_acpi.c | 59 > drivers/gpu/drm/i915/intel_bios.c | 4 ++ > drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +- > drivers/gpu/drm/i915/intel_vbt_defs.h | 3 +- > 8 files changed, 141 insertions(+), 13 deletions(-) > > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD
On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> This patch adds option to enable dynamic backlight for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.
This patch causes a regression on my ThinkPad X1 Carbon Gen 4;
with enable_dbc = true the backlight stays off; setting i915.enable_dbc=0
on boot makes things work properly again.
> Signed-off-by: Puthikorn Voravootivat
> Reviewed-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/i915_params.c| 5 +
> drivers/gpu/drm/i915/i915_params.h| 3 ++-
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26 ++
> 3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 5b5ab15d191f..88b9d3e6713a 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
> .inject_load_failure = 0,
> .enable_dpcd_backlight = -1,
> .enable_gvt = false,
> + .enable_dbc = true,
> };
>
> module_param_named(modeset, i915.modeset, int, 0400);
> @@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> MODULE_PARM_DESC(enable_gvt,
> "Enable support for Intel GVT-g graphics virtualization host
> support(default:false)");
> +
> +module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
> +MODULE_PARM_DESC(enable_dbc,
> + "Enable support for dynamic backlight control (default:true)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 0d6cf9138dc4..057e203e6bda 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -67,7 +67,8 @@
> func(bool, verbose_state_checks); \
> func(bool, nuclear_pageflip); \
> func(bool, enable_dp_mst); \
> - func(bool, enable_gvt)
> + func(bool, enable_gvt); \
> + func(bool, enable_dbc)
>
> #define MEMBER(T, member) T member
> struct i915_params {
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index fea161727c6e..b25cd88fc1c5 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -173,6 +173,24 @@ static bool intel_dp_aux_set_pwm_freq(struct
> intel_connector *connector)
> return true;
> }
>
> +/*
> +* Set minimum / maximum dynamic brightness percentage. This value is
> expressed
> +* as the percentage of normal brightness in 5% increments.
> +*/
> +static bool
> +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> +u32 min, u32 max)
> +{
> + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> +
> + if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> + dbc, sizeof(dbc)) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> + return false;
> + }
> + return true;
> +}
> +
> static void intel_dp_aux_enable_backlight(const struct intel_crtc_state
> *crtc_state,
> const struct drm_connector_state
> *conn_state)
> {
> @@ -208,6 +226,14 @@ static void intel_dp_aux_enable_backlight(const struct
> intel_crtc_state *crtc_st
> if (intel_dp_aux_set_pwm_freq(connector))
> new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
>
> + if (i915.enable_dbc &&
> + (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
> + if(intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0,
> 100)) {
> + new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
> + DRM_DEBUG_KMS("Enable dynamic brightness.\n");
> + }
> + }
> +
> if (new_dpcd_buf != dpcd_buf) {
> if (drm_dp_dpcd_writeb(&intel_dp->aux,
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
> --
> 2.13.1.611.g7e3b11ae1-goog
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set all undefined MOCS entries to follow PTE
On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote:
> A good default for garbage entries from the user is to follow the
> default setting of the object (i.e. the PTE). Currently they use the
> uncached entry, and now the only way to accidentally hit uncached
> performance is via explicit use of the uncached MOCS or setting the
> object to uncached. Note that these entries are currently undefined in
> the ABI and we reserve the right to change them. We originally chose
> uncached to eliminate any problem with reducing the caching level in
> future, but the object is a much better definition of the minimum
> caching level.
>
> Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS")
> Signed-off-by: Chris Wilson
> Cc: David Weinehall
> Cc: Arkadiusz Hiler
> Cc: Tvrtko Ursulin
> Cc: sta...@vger.kernel.org
LGTM, and passes our nightly msdk test case.
Tested-by: David Weinehall
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_mocs.c | 39
> +++
> 1 file changed, 15 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> index 92e461c68385..e7a7781ca457 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -85,10 +85,7 @@ struct drm_i915_mocs_table {
> *
> * Entries not part of the following tables are undefined as far as
> * userspace is concerned and shouldn't be relied upon. For the time
> - * being they will be implicitly initialized to the strictest caching
> - * configuration (uncached) to guarantee forwards compatibility with
> - * userspace programs written against more recent kernels providing
> - * additional MOCS entries.
> + * being they will be implicitly initialized to follow the PTE.
> *
> * NOTE: These tables MUST start with being uncached and the length
> * MUST be less than 63 as the last two registers are reserved
> @@ -249,16 +246,13 @@ int intel_mocs_init_engine(struct intel_engine_cs
> *engine)
> table.table[index].control_value);
>
> /*
> - * Ok, now set the unused entries to uncached. These entries
> + * Ok, now set the unused entries to follow the PTE. These entries
>* are officially undefined and no contract for the contents
>* and settings is given for these entries.
> - *
> - * Entry 0 in the table is uncached - so we are just writing
> - * that value to all the used entries.
>*/
> for (; index < GEN9_NUM_MOCS_ENTRIES; index++)
> I915_WRITE(mocs_register(engine->id, index),
> -table.table[0].control_value);
> +table.table[I915_MOCS_PTE].control_value);
>
> return 0;
> }
> @@ -295,16 +289,13 @@ static int emit_mocs_control_table(struct
> drm_i915_gem_request *req,
> }
>
> /*
> - * Ok, now set the unused entries to uncached. These entries
> + * Ok, now set the unused entries to follow the PTE. These entries
>* are officially undefined and no contract for the contents
>* and settings is given for these entries.
> - *
> - * Entry 0 in the table is uncached - so we are just writing
> - * that value to all the used entries.
>*/
> for (; index < GEN9_NUM_MOCS_ENTRIES; index++) {
> *cs++ = i915_mmio_reg_offset(mocs_register(engine, index));
> - *cs++ = table->table[0].control_value;
> + *cs++ = table->table[I915_MOCS_PTE].control_value;
> }
>
> *cs++ = MI_NOOP;
> @@ -355,18 +346,17 @@ static int emit_mocs_l3cc_table(struct
> drm_i915_gem_request *req,
> if (table->size & 0x01) {
> /* Odd table size - 1 left over */
> *cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(i));
> - *cs++ = l3cc_combine(table, 2 * i, 0);
> + *cs++ = l3cc_combine(table, 2 * i, I915_MOCS_PTE);
> i++;
> }
>
> /*
> - * Now set the rest of the table to uncached - use entry 0 as
> - * this will be uncached. Leave the last pair uninitialised as
> - * they are reserved by the hardware.
> + * Now set the rest of the table to follow the PTE.
> + * Leave the last pair as they are reserved by the hardware.
>*/
> for (; i < GEN9_NUM_MOCS_ENTRIES / 2; i++) {
> *cs++ = i915_mmio_reg_offset(GEN9_LNCFCMOCS(i));
> - *cs++ = l3cc_combine(table, 0, 0);
> + *cs++ = l3cc_combine(table, I915_MOCS_PTE, I915_MOCS_PTE);
> }
>
> *cs++ = MI_NOOP;
&g
Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9
On Thu, May 04, 2017 at 10:35:33AM +0200, Arkadiusz Hiler wrote: > On Thu, Apr 27, 2017 at 05:23:16PM +0100, Chris Wilson wrote: > > On Thu, Apr 27, 2017 at 06:30:42PM +0300, David Weinehall wrote: > > > On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote: > > > > On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote: > > > > > Add a bunch of MOCS entries for gen 9 that were missing from > > > > > intel_mocs. > > > > > Some of these are used by media-sdk; if these entries are missing > > > > > the default will instead be to do everything uncached. > > > > > > > > > > This patch improves media-sdk performance with up to 60% > > > > > with the (admittedly synthetic) benchmarks we use in our nightly > > > > > testing, without regressing any other benchmarks. > > > > > > > > Hey David, > > > > > > > > I am testing some of the extended MOCS with Mesa and the differences I > > > > see fit in the margins of statistical error. > > > > > > > > Odd, I thought, so to make sure I haven't messed up anything in the > > > > process of compiling, setting LD_LIBRARY_PATH and benchmarking I turned > > > > everything to UNCACHED - and I saw severe performance drop. > > > > > > > > So here is the question it induced: > > > > > > > > Have you used the "closest neighbour" from entries available or did you > > > > defaulted to the UNCACHED ones? That could be the culprit. > > > > > > > > Note: I have tested MOCS for VB and Render Target only, and only in a > > > > few synthetic cases - it will require much more fine-tuning and > > > > benchmarking before any final conclusions. > > > > > > As I mentioned in the commit message, the improvements only manifest > > > themselves for media-sdk workloads (and presumably other workloads > > > that uses the same hardware); if you see any performance regressions > > > with these additional entries I'd be interested to know. > > > > But what is being counter suggested is that their is no reason for these > > mocs entries. If the sdk is just using mocs registers without first > > programming them outside of the kernel abi, then it will be hitting > > uncached memory - and then the only benefit is from simply enabling > > cached access. The kernel ABI is minimalist for a reason, and we want to > > know why we should be adding tables that we need to maintain forever > > (bonus points for making that a consistent interface for hardware for > > years to come). > > -Chris > > Thanks for rephrasing - that's exactly what I am concerned with. > > Did you just use the MediaSDK as it is - meaning that MOCS entries > beyond the set of the 3 we have defined had been naively utilized? > > If that's the case it is probably the cause of the performance > difference - everything beyond "the 3" means UNCACHED. > > Can you try changing MediaSDK to only use entries that are already in? > How the performance differs in that case? We're benchmarking using upstream MediaSDK without changes, since that's the only thing that's relevant. Customising benchmarks to get better results isn't really an acceptable solution :) Obviously fixing MediaSDK upstream is a different story, in case one of the three pre-defined entries we have turns out to be the best possible MOCS-settings for that workload. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9
On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote: > On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote: > > Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs. > > Some of these are used by media-sdk; if these entries are missing > > the default will instead be to do everything uncached. > > > > This patch improves media-sdk performance with up to 60% > > with the (admittedly synthetic) benchmarks we use in our nightly > > testing, without regressing any other benchmarks. > > Hey David, > > I am testing some of the extended MOCS with Mesa and the differences I > see fit in the margins of statistical error. > > Odd, I thought, so to make sure I haven't messed up anything in the > process of compiling, setting LD_LIBRARY_PATH and benchmarking I turned > everything to UNCACHED - and I saw severe performance drop. > > So here is the question it induced: > > Have you used the "closest neighbour" from entries available or did you > defaulted to the UNCACHED ones? That could be the culprit. > > Note: I have tested MOCS for VB and Render Target only, and only in a > few synthetic cases - it will require much more fine-tuning and > benchmarking before any final conclusions. As I mentioned in the commit message, the improvements only manifest themselves for media-sdk workloads (and presumably other workloads that uses the same hardware); if you see any performance regressions with these additional entries I'd be interested to know. Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9
Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
Some of these are used by media-sdk; if these entries are missing
the default will instead be to do everything uncached.
This patch improves media-sdk performance with up to 60%
with the (admittedly synthetic) benchmarks we use in our nightly
testing, without regressing any other benchmarks.
Signed-off-by: David Weinehall
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 92e461c68385..5236a442a14f 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -103,7 +103,6 @@ static const struct drm_i915_mocs_entry
skylake_mocs_table[] = {
LE_TGT_CACHE(LE_TC_LLC_ELLC) |
LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
LE_PFM(0) | LE_SCF(0),
-
/* 0x0010 */
.l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
},
@@ -123,7 +122,133 @@ static const struct drm_i915_mocs_entry
skylake_mocs_table[] = {
LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
LE_PFM(0) | LE_SCF(0),
/* 0x0030 */
- .l3cc_value = L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ },
+ {
+ /* 0x0037 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+ LE_TGT_CACHE(LE_TC_LLC) |
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0030 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ },
+ {
+ /* 0x0039 */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+ LE_TGT_CACHE(LE_TC_LLC_ELLC) |
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0030 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ },
+ {
+ /* 0x0033 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+ LE_TGT_CACHE(LE_TC_PAGETABLE) |
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0030 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ },
+ {
+ /* 0x0017 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+ LE_TGT_CACHE(LE_TC_LLC) |
+ LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0030 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ },
+ {
+ /* 0x0037 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+ LE_TGT_CACHE(LE_TC_LLC) |
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+ },
+ {
+ /* 0x0039 */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+ LE_TGT_CACHE(LE_TC_LLC_ELLC) |
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+ },
+ {
+ /* 0x0017 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+ LE_TGT_CACHE(LE_TC_LLC) |
+ LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+ },
+ {
+ /* 0x003b */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+ LE_TGT_CACHE(LE_TC_LLC_ELLC) |
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+ },
+ {
+ /* 0x0033 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+ LE_TGT_CACHE(LE_TC_PAGETABLE) |
+ LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+ LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+ },
+ {
+ /* 0x0019 */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+ LE_TGT_CACHE(LE_TC_LLC_ELLC) |
+ LE_LRUM(1) | LE_AOM(0
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend
On 2017-04-05 18:46, Kamble, Sagar A wrote: On 4/5/2017 6:32 PM, David Weinehall wrote: On 2017-04-05 15:54, Joonas Lahtinen wrote: On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote: i915 is currently doing Full GPU reset at the end of suspend followed by GuC suspend. This reset bypasses the GuC. We need to tell the GuC to suspend before we do a direct intel_gpu_reset, Otherwise the gpu state will no longer match the GuC's expectations and its suspend will not be successful. With this change, i915 suspends GuC after suspending GEM and before doing Full GPU reset. + David, Oscar and Michel My understanding is that reloading GuC firmware after each resume is a major bottleneck in resume time, and we instead should be telling GuC to suspend and not reset the GPU, at most only reset the engines. Regards, Joonas If this is possible, then yes, it'd definitely be preferable. If not, then doing the GuC + HuC loading asynchronously on resume would be preferable. Anusha mentioned working on asynchronous loading, hence added to CC. Kind regards, David Data points about GuC load times for reference that I collected today on SKL and APL. At Rpn(lowest frequency) it loads/becomes ready in 3-4 jiffies. Running at >=RPe it becomes ready in a jiffy. Are these times in tolerable limits? Another concern Daniele highlighted was rare chance of WOPCM persisting post suspend/resume and hence needing reload. I believe the fetch from disk must be time consuming during boot time load and for that asynchronous load can be pursued. I've seen times on the order of 30-35ms. It should be noted though that this included HuC (and HuC verifying the integrity of HuC or whatever it does). I can re-run the tests once I'm done with various other tests I'm doing right now though; my GuC-related tests are quite old, since it's not loaded by default (which is probably a good thing, considering the stability issues we're seeing with GuC). Kind regards, David - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend
On 2017-04-05 15:54, Joonas Lahtinen wrote: On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote: i915 is currently doing Full GPU reset at the end of suspend followed by GuC suspend. This reset bypasses the GuC. We need to tell the GuC to suspend before we do a direct intel_gpu_reset, Otherwise the gpu state will no longer match the GuC's expectations and its suspend will not be successful. With this change, i915 suspends GuC after suspending GEM and before doing Full GPU reset. + David, Oscar and Michel My understanding is that reloading GuC firmware after each resume is a major bottleneck in resume time, and we instead should be telling GuC to suspend and not reset the GPU, at most only reset the engines. Regards, Joonas If this is possible, then yes, it'd definitely be preferable. If not, then doing the GuC + HuC loading asynchronously on resume would be preferable. Anusha mentioned working on asynchronous loading, hence added to CC. Kind regards, David - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] dim: avoid errors with rm $foo/ expanding to /
On Wed, Mar 22, 2017 at 12:53:24PM +0200, Jani Nikula wrote: > On Wed, 22 Mar 2017, David Weinehall wrote: > > rm -rf / woes can be remedied by always passing "--preserve-root" to rm > > (I believe that this is the default already though). > > That doesn't help with 'rm -rf /*' though. Hmmm, but how would you end up with that if it does /$foo and $foo="" or unset? Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] dim: avoid errors with rm $foo/ expanding to /
On Tue, Mar 21, 2017 at 01:50:48PM +0100, Daniel Vetter wrote:
> On Tue, Mar 21, 2017 at 01:15:59PM +0200, Jani Nikula wrote:
> > On Tue, 21 Mar 2017, Daniel Vetter wrote:
> > > On Tue, Mar 21, 2017 at 12:14:31PM +0200, Jani Nikula wrote:
> > >> Fix shellcheck SC2115: Use "${var:?}" to ensure this never expands to /.
> > >>
> > >> Signed-off-by: Jani Nikula
> > >
> > > I'm not sold on these because if those are ever unset, dim will fail all
> > > over the place.
> >
> > Yup, like at the top where we specifically ensure $DIM_PREFIX is not
> > empty!
> >
> > > I'm leaning towards shutting this one up.
> >
> > I know, I was divided about this one as well, but erred on the safe side
> > because 'rm -Rf /*' is such a huge failure mode.
> >
> > I could lean either way.
>
> Even for this failure mode it feels like noise ... I guess bash scripting
> just is noise, and we'll live with it?
>
> Saying, Ḯ'm also ok with you pushing this. We might eventually have a
> command where the input is user-supplied and if absent could result in
> tears. I just fixed that broken default handling for dim retip :-)
rm -rf / woes can be remedied by always passing "--preserve-root" to rm
(I believe that this is the default already though).
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.
On Sun, Mar 12, 2017 at 01:21:12PM +, Chris Wilson wrote: > On Fri, Mar 10, 2017 at 05:14:32PM -0800, Kenneth Graunke wrote: > > On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has > > had the surprising behavior of doing a synchronized GTT mapping. > > This is obviously not what the user of the API wanted. > > > > Eric left a comment indicating a valid concern: if the CPU and GPU > > caches are incoherent, we don't keep track of where the user last > > mapped the buffer, and what caches might contain relevant data. > > Note this is an issue in libdrm_intel not tracking the cache domain > transitions. Even just a switch between cpu and coherent would solve the > majority of that - the caveat being shared bo where the tracking is > incomplete. > > > Modern Atom systems still don't have LLC, but they do offer snooping, > > which effectively makes the caches coherent. The kernel appears to > > set up the PTE/PPAT to enable snooping for everything where the cache > > level is not I915_CACHE_NONE. As far as I know, only scanout buffers > > are marked as uncached. > > Byt, bsw beg to differ. I don't have a bxt to know the results of the > igt/kernel tests. Just give me a list of the tests to run (and, if any, what patches to apply and the debugging level you want enabled) and I'll provide the necessary results. > > Any buffers used by scanout should be flagged as non-reusable with > > drm_intel_bo_disable_reuse(), prime export, or flink. So, we can > > assume that any reusable buffer should be snooped. > > Not really, there is no reason why scanout buffers can't be reused. > > > This patch enables unsynchronized mappings for reusable buffers > > on all Gen6+ hardware (which have either LLC or snooping). > > > > On Broxton, this improves the performance of Unigine Valley 1.0 > > on Low settings at 1280x720 by about 45%, and Unigine Heaven 4.0 > > (same settings) by about 53%. > > Does anyone have figures for gtt performance on bxt - does it cover over > the same performance penalty from earler atoms? Basically why bother to > enable this over wc mapping (no stalls for a contended, limited > resource) + detiling. (Just note that for detiling Y to WC you need to > use a temporary cacheable page, or rearrange the code to make sure the > reads/writes are in 64 byte chunks.) Again, I can run any tests you'd like to get numbers from, just give me a list. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Refactor code to select the DDI buf translation table
On Thu, Feb 23, 2017 at 07:35:05PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Split the code to select the correct trasnslation table into DP,
translations, superfluous space before DP
> eDP and FDI specific helpers. This reduces the clutter in
> intel_prepare_dp_ddi_buffers(), and we'll have other uses for some
> of these new helper functions later on.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 126
> +++
> 1 file changed, 73 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index cd6fedd229a0..5e4b0172810d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -468,6 +468,59 @@ static int intel_ddi_hdmi_level(struct drm_i915_private
> *dev_priv, enum port por
> return hdmi_level;
> }
>
> +static const struct ddi_buf_trans *
> +intel_ddi_get_buf_trans_dp(struct drm_i915_private *dev_priv,
> +int *n_entries)
> +{
> + if (IS_KABYLAKE(dev_priv)) {
> + return kbl_get_buf_trans_dp(dev_priv, n_entries);
> + } else if (IS_SKYLAKE(dev_priv)) {
> + return skl_get_buf_trans_dp(dev_priv, n_entries);
> + } else if (IS_BROADWELL(dev_priv)) {
> + *n_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> + return bdw_ddi_translations_dp;
> + } else if (IS_HASWELL(dev_priv)) {
> + *n_entries = ARRAY_SIZE(hsw_ddi_translations_dp);
> + return hsw_ddi_translations_dp;
> + }
> +
> + *n_entries = 0;
> + return NULL;
> +}
> +
> +static const struct ddi_buf_trans *
> +intel_ddi_get_buf_trans_edp(struct drm_i915_private *dev_priv,
> + int *n_entries)
> +{
> + if (IS_KABYLAKE(dev_priv) || IS_SKYLAKE(dev_priv)) {
> + return skl_get_buf_trans_edp(dev_priv, n_entries);
> + } else if (IS_BROADWELL(dev_priv)) {
> + return bdw_get_buf_trans_edp(dev_priv, n_entries);
> + } else if (IS_HASWELL(dev_priv)) {
> + *n_entries = ARRAY_SIZE(hsw_ddi_translations_dp);
> + return hsw_ddi_translations_dp;
> + }
> +
> + *n_entries = 0;
> + return NULL;
> +}
> +
> +static const struct ddi_buf_trans *
> +intel_ddi_get_buf_trans_fdi(struct drm_i915_private *dev_priv,
> + int *n_entries)
> +{
> + if (IS_BROADWELL(dev_priv)) {
> + *n_entries = ARRAY_SIZE(hsw_ddi_translations_fdi);
> + return hsw_ddi_translations_fdi;
> + } else if (IS_HASWELL(dev_priv)) {
> + *n_entries = ARRAY_SIZE(hsw_ddi_translations_fdi);
> + return hsw_ddi_translations_fdi;
> + }
> +
> + *n_entries = 0;
> + return NULL;
> +}
> +
> /*
> * Starting with Haswell, DDI port buffers must be programmed with correct
> * values in advance. This function programs the correct values for
> @@ -477,45 +530,29 @@ void intel_prepare_dp_ddi_buffers(struct intel_encoder
> *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> u32 iboost_bit = 0;
> - int i, n_dp_entries, n_edp_entries, size;
> + int i, n_entries;
> enum port port = intel_ddi_get_encoder_port(encoder);
> - const struct ddi_buf_trans *ddi_translations_fdi;
> - const struct ddi_buf_trans *ddi_translations_dp;
> - const struct ddi_buf_trans *ddi_translations_edp;
> const struct ddi_buf_trans *ddi_translations;
>
> if (IS_GEN9_LP(dev_priv))
> return;
>
> - if (IS_KABYLAKE(dev_priv)) {
> - ddi_translations_fdi = NULL;
> - ddi_translations_dp =
> - kbl_get_buf_trans_dp(dev_priv, &n_dp_entries);
> - ddi_translations_edp =
> - skl_get_buf_trans_edp(dev_priv, &n_edp_entries);
> - } else if (IS_SKYLAKE(dev_priv)) {
> - ddi_translations_fdi = NULL;
> - ddi_translations_dp =
> - skl_get_buf_trans_dp(dev_priv, &n_dp_entries);
> - ddi_translations_edp =
> - skl_get_buf_trans_edp(dev_priv, &n_edp_entries);
> - } else if (IS_BROADWELL(dev_priv)) {
> - ddi_translations_fdi = bdw_ddi_translations_fdi;
> - ddi_translations_dp = bdw_ddi_translations_dp;
> - ddi_translations_edp = bdw_get_buf_trans_edp(dev_priv,
> &n_edp_entries);
> - n_dp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> - }
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Introduce intel_ddi_dp_voltage_max()
On Thu, Feb 23, 2017 at 07:35:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rather than sprinkling ideas of how big the DDI buf translation tables
> are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c
> where the actual tables are defined. To that end we introduce
> intel_ddi_dp_voltage_max() which will actually look at the proper
> translation table to determine what is the maximum voltage swing level
> supported.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 18 ++
> drivers/gpu/drm/i915/intel_dp.c | 5 ++---
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 3 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6f8e57f127e5..0c3665f9e4f4 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1615,6 +1615,24 @@ static void bxt_ddi_vswing_sequence(struct
> drm_i915_private *dev_priv,
>ddi_translations[level].deemphasis);
> }
>
> +u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + int n_entries;
> +
> + if (encoder->type == INTEL_OUTPUT_EDP)
> + intel_ddi_get_buf_trans_edp(dev_priv, &n_entries);
> + else
> + intel_ddi_get_buf_trans_dp(dev_priv, &n_entries);
> +
> + if (WARN_ON(n_entries < 1))
> + n_entries = 1;
> + if (WARN_ON(n_entries > ARRAY_SIZE(index_to_dp_signal_levels)))
> + n_entries = ARRAY_SIZE(index_to_dp_signal_levels);
> +
> + return index_to_dp_signal_levels[n_entries - 1];
> +}
> +
> static uint32_t translate_signal_level(int signal_levels)
> {
> int i;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 024798a9c016..e72c92a08c81 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3098,9 +3098,8 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
> if (IS_GEN9_LP(dev_priv))
> return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> else if (INTEL_GEN(dev_priv) >= 9) {
> - if (dev_priv->vbt.edp.low_vswing && port == PORT_A)
> - return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> - return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + return intel_ddi_dp_voltage_max(encoder);
> } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> else if (IS_GEN7(dev_priv) && port == PORT_A)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3c8aaca947d3..e9a90dcd15df 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1233,6 +1233,8 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config);
> void intel_ddi_set_vc_payload_alloc(struct drm_crtc *crtc, bool state);
> uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
> +u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
> +
> unsigned int intel_fb_align_height(struct drm_i915_private *dev_priv,
> unsigned int height,
> uint32_t pixel_format,
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Refactor translate_signal_level()
On Thu, Feb 23, 2017 at 07:35:06PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Convert the big switch statement in translate_signal_level() into a neat
> table. The table also serves as documentation for the translation
> tables. We'll also have other uses for this table later on.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 60
> ++--
> 1 file changed, 21 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 5e4b0172810d..6f8e57f127e5 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -34,6 +34,19 @@ struct ddi_buf_trans {
> u8 i_boost; /* SKL: I_boost; valid: 0x0, 0x1, 0x3, 0x7 */
> };
>
> +static const u8 index_to_dp_signal_levels[] = {
> + [0] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_0,
> + [1] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_1,
> + [2] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_2,
> + [3] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_3,
> + [4] = DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_0,
> + [5] = DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_1,
> + [6] = DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_2,
> + [7] = DP_TRAIN_VOLTAGE_SWING_LEVEL_2 | DP_TRAIN_PRE_EMPH_LEVEL_0,
> + [8] = DP_TRAIN_VOLTAGE_SWING_LEVEL_2 | DP_TRAIN_PRE_EMPH_LEVEL_1,
> + [9] = DP_TRAIN_VOLTAGE_SWING_LEVEL_3 | DP_TRAIN_PRE_EMPH_LEVEL_0,
> +};
> +
> /* HDMI/DVI modes ignore everything but the last 2 items. So we share
> * them for both DP and FDI transports, allowing those ports to
> * automatically adapt to HDMI connections as well
> @@ -1604,48 +1617,17 @@ static void bxt_ddi_vswing_sequence(struct
> drm_i915_private *dev_priv,
>
> static uint32_t translate_signal_level(int signal_levels)
> {
> - uint32_t level;
> -
> - switch (signal_levels) {
> - default:
> - DRM_DEBUG_KMS("Unsupported voltage swing/pre-emphasis level:
> 0x%x\n",
> - signal_levels);
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_0:
> - level = 0;
> - break;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_1:
> - level = 1;
> - break;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_2:
> - level = 2;
> - break;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_3:
> - level = 3;
> - break;
> -
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_0:
> - level = 4;
> - break;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_1:
> - level = 5;
> - break;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_2:
> - level = 6;
> - break;
> -
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_2 | DP_TRAIN_PRE_EMPH_LEVEL_0:
> - level = 7;
> - break;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_2 | DP_TRAIN_PRE_EMPH_LEVEL_1:
> - level = 8;
> - break;
> + int i;
>
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_3 | DP_TRAIN_PRE_EMPH_LEVEL_0:
> - level = 9;
> - break;
> + for (i = 0; i < ARRAY_SIZE(index_to_dp_signal_levels); i++) {
Superfluous space between < and ARRAY_SIZE.
> + if (index_to_dp_signal_levels[i] == signal_levels)
> + return i;
> }
>
> - return level;
> + WARN(1, "Unsupported voltage swing/pre-emphasis level: 0x%x\n",
> + signal_levels);
> +
> + return 0;
> }
>
> uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: kill {bdw, bxt}_modeset_calc_cdclk
On Fri, Feb 17, 2017 at 11:22:04AM -0200, Paulo Zanoni wrote:
> The functions are pretty much the same, except for the CDCLK and VCO
> calculations. Add BDW support to vlv_modeset_calc_cdclk() and add
> BXT/GLK support to skl_modeset_calc_cdclk(). The two reamining
s/reamining/remaining/
> functions are still very similar, except for the fact that the vlv
> version doesn't touch the VCO. Further patches could unify them even
> more if that's desired.
>
> While at it, merge some lines that can fit 80 columns in those
> functions.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 120
> ++---
> 1 file changed, 30 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index d643c0c..d505ff1 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1499,45 +1499,18 @@ static int intel_max_pixel_rate(struct
> drm_atomic_state *state)
> static int vlv_modeset_calc_cdclk(struct drm_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->dev);
> - int max_pixclk = intel_max_pixel_rate(state);
> - struct intel_atomic_state *intel_state =
> - to_intel_atomic_state(state);
> - int cdclk;
> -
> - cdclk = vlv_calc_cdclk(dev_priv, max_pixclk);
> -
> - if (cdclk > dev_priv->max_cdclk_freq) {
> - DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> - cdclk, dev_priv->max_cdclk_freq);
> - return -EINVAL;
> - }
> -
> - intel_state->cdclk.logical.cdclk = cdclk;
> -
> - if (!intel_state->active_crtcs) {
> - cdclk = vlv_calc_cdclk(dev_priv, 0);
> -
> - intel_state->cdclk.actual.cdclk = cdclk;
> - } else {
> - intel_state->cdclk.actual =
> - intel_state->cdclk.logical;
> - }
> -
> - return 0;
> -}
> -
> -static int bdw_modeset_calc_cdclk(struct drm_atomic_state *state)
> -{
> - struct drm_i915_private *dev_priv = to_i915(state->dev);
> struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> int max_pixclk = intel_max_pixel_rate(state);
> int cdclk;
>
> /*
> - * FIXME should also account for plane ratio
> - * once 64bpp pixel formats are supported.
> + * FIXME: Broadwell should also account for plane ratio once 64bpp pixel
> + * formats are supported.
>*/
> - cdclk = bdw_calc_cdclk(max_pixclk);
> + if (IS_BROADWELL(dev_priv))
> + cdclk = bdw_calc_cdclk(max_pixclk);
> + else
> + cdclk = vlv_calc_cdclk(dev_priv, max_pixclk);
>
> if (cdclk > dev_priv->max_cdclk_freq) {
> DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> @@ -1548,12 +1521,14 @@ static int bdw_modeset_calc_cdclk(struct
> drm_atomic_state *state)
> intel_state->cdclk.logical.cdclk = cdclk;
>
> if (!intel_state->active_crtcs) {
> - cdclk = bdw_calc_cdclk(0);
> + if (IS_BROADWELL(dev_priv))
> + cdclk = bdw_calc_cdclk(0);
> + else
> + cdclk = vlv_calc_cdclk(dev_priv, 0);
>
> intel_state->cdclk.actual.cdclk = cdclk;
> } else {
> - intel_state->cdclk.actual =
> - intel_state->cdclk.logical;
> + intel_state->cdclk.actual = intel_state->cdclk.logical;
> }
>
> return 0;
> @@ -1561,57 +1536,26 @@ static int bdw_modeset_calc_cdclk(struct
> drm_atomic_state *state)
>
> static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
> {
> - struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> struct drm_i915_private *dev_priv = to_i915(state->dev);
> - const int max_pixclk = intel_max_pixel_rate(state);
> + struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> + int max_pixclk = intel_max_pixel_rate(state);
> int cdclk, vco;
>
> - vco = intel_state->cdclk.logical.vco;
> - if (!vco)
> - vco = dev_priv->skl_preferred_vco_freq;
> -
> /*
> - * FIXME should also account for plane ratio
> - * once 64bpp pixel formats are supported.
> + * FIXME: Skylake/Kabylake should also account for plane ratio once
> + * 64bpp pixel formats are supported.
>*/
> - cdclk = skl_calc_cdclk(max_pixclk, vco);
> -
> - if (cdclk > dev_priv->max_cdclk_freq) {
> - DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> - cdclk, dev_priv->max_cdclk_freq);
> - return -EINVAL;
> - }
> -
> - intel_state->cdclk.logical.vco = vco;
> - intel_state->cdclk.logical.cdclk = cdclk;
> -
> - if (!intel_state->active_crtcs) {
> - cdclk = skl_calc_cdclk(0, vco);
> -
> - intel_state->cdclk.actual.vc
Re: [Intel-gfx] [PATCH] drm/i915: DMC 1.03 for Geminilake
On Wed, Feb 15, 2017 at 09:34:23AM -0800, Rodrigo Vivi wrote: > There is a new version of DMC available for Kabylake. s/Kabylake/Gemini Lake/ > > It's release notes only mention: > - Enhancement in the FW to restore the PG2 state > > v2: cook on top of drm-tip without depending on kbl one so CI can check. > > Cc: Ander Conselvan de Oliveira > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_csr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_csr.c > b/drivers/gpu/drm/i915/intel_csr.c > index 9dcc434..14659c7 100644 > --- a/drivers/gpu/drm/i915/intel_csr.c > +++ b/drivers/gpu/drm/i915/intel_csr.c > @@ -34,9 +34,9 @@ > * low-power state and comes back to normal. > */ > > -#define I915_CSR_GLK "i915/glk_dmc_ver1_01.bin" > +#define I915_CSR_GLK "i915/glk_dmc_ver1_03.bin" > MODULE_FIRMWARE(I915_CSR_GLK); > -#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 1) > +#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 3) > > #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin" > MODULE_FIRMWARE(I915_CSR_KBL); > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Only enable DDI IO power domains after enabling DPLL
On Fri, Feb 10, 2017 at 03:29:59PM +0200, Ander Conselvan de Oliveira wrote:
> According to bspec, the DDI IO power domains should be enabled after
> enabling the DPLL and mapping it to the DDI. The current order doesn't
> seem to create problems with Skylake and Kabylake, but causes enable
> timeouts in Geminilake.
>
> Cc: David Weinehall
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +++
> drivers/gpu/drm/i915/intel_ddi.c| 49
> drivers/gpu/drm/i915/intel_display.c| 12 ++
> drivers/gpu/drm/i915/intel_drv.h| 3 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 68
> +++--
> 5 files changed, 108 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bfccf9d..27847d4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -343,6 +343,11 @@ enum intel_display_power_domain {
> POWER_DOMAIN_PORT_DDI_C_LANES,
> POWER_DOMAIN_PORT_DDI_D_LANES,
> POWER_DOMAIN_PORT_DDI_E_LANES,
> + POWER_DOMAIN_PORT_DDI_A_IO,
> + POWER_DOMAIN_PORT_DDI_B_IO,
> + POWER_DOMAIN_PORT_DDI_C_IO,
> + POWER_DOMAIN_PORT_DDI_D_IO,
> + POWER_DOMAIN_PORT_DDI_E_IO,
> POWER_DOMAIN_PORT_DSI,
> POWER_DOMAIN_PORT_CRT,
> POWER_DOMAIN_PORT_OTHER,
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b0c4d23..72754b9 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1440,6 +1440,18 @@ bool intel_ddi_get_hw_state(struct intel_encoder
> *encoder,
> return ret;
> }
>
> +static unsigned long long
> +intel_ddi_get_power_domains(struct intel_encoder *encoder)
> +{
> + struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
> + enum pipe pipe;
> +
> + if (intel_ddi_get_hw_state(encoder, &pipe))
> + return BIT_ULL(dig_port->ddi_io_power_domain);
> +
> + return 0;
> +}
> +
> void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc)
> {
> struct drm_crtc *crtc = &intel_crtc->base;
> @@ -1682,6 +1694,7 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum port port = intel_ddi_get_encoder_port(encoder);
> + struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
>
> intel_dp_set_link_params(intel_dp, link_rate, lane_count,
>link_mst);
> @@ -1689,6 +1702,9 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> intel_edp_panel_on(intel_dp);
>
> intel_ddi_clk_select(encoder, pll);
> +
> + intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
> +
> intel_prepare_dp_ddi_buffers(encoder);
> intel_ddi_init_dp_buf_reg(encoder);
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> @@ -1708,9 +1724,13 @@ static void intel_ddi_pre_enable_hdmi(struct
> intel_encoder *encoder,
> struct drm_encoder *drm_encoder = &encoder->base;
> enum port port = intel_ddi_get_encoder_port(encoder);
> int level = intel_ddi_hdmi_level(dev_priv, port);
> + struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
>
> intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> intel_ddi_clk_select(encoder, pll);
> +
> + intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
> +
> intel_prepare_hdmi_ddi_buffers(encoder);
> if (IS_GEN9_BC(dev_priv))
> skl_ddi_set_iboost(encoder, level);
> @@ -1754,6 +1774,7 @@ static void intel_ddi_post_disable(struct intel_encoder
> *intel_encoder,
> struct drm_encoder *encoder = &intel_encoder->base;
> struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> enum port port = intel_ddi_get_encoder_port(intel_encoder);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> int type = intel_encoder->type;
> uint32_t val;
> bool wait = false;
> @@ -1793,6 +1814,8 @@ static void intel_ddi_post_disable(struct intel_encoder
> *intel_encoder,
>
> intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
> }
> +
> + intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
> }
>
> void intel_ddi_fdi_post_disable
Re: [Intel-gfx] [PATCH 4/6] drm/i915/glk: Don't enable DDI IO power domains during init
On Fri, Feb 10, 2017 at 03:29:57PM +0200, Ander Conselvan de Oliveira wrote: > In Geminilake, the DDI IO power domains can't be enabled before a DPLL > is running and mapped to the appropriate DDI. At least on Geminilake, > attempting to enable those during init will lead to a timeout. > > The failure to enable the power domain also causes issues with the state > verifier during resume from suspend. After all the init power domains > are enabled, the call to intel_power_domains_sync_hw() from the resume > path will cause the hw_enabled field on the respective power wells to be > false while the usage count remains above zero. Further attempts to > enable the power domain caused by a modeset will simply update the usage > count without doing anything else. When the state verifier attempts to > read the state of a DDI encoder, intel_display_power_get_if_enabled() > returns false, leading to the following WARN: > > WARNING: CPU: 3 PID: 1743 at drivers/gpu/drm/i915/intel_display.c:7001 > verify_connector_state.isra.80+0x26c/0x2b0 [i915] > attached crtc is active, but connector isn't > Modules linked in: i915(E) tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 > xt_conntrack ebtable_broute bridge stp llc ebtable_nat ip6table_mangle > ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 > ip6table_raw iptable_mangle iptable_security iptable_nat nf_conntrack_ipv4 > nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw ebtable_filter > ebtables ip6table_filter ip6_tables x86_pkg_temp_thermal coretemp kvm_intel > kvm i2c_algo_bit drm_kms_helper irqbypass crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel drm shpchp tpm_tis tpm_tis_core tpm nfsd auth_rpcgss > nfs_acl lockd grace sunrpc crc32c_intel serio_raw [last unloaded: i915] > CPU: 3 PID: 1743 Comm: kworker/u8:22 Tainted: GW E > 4.10.0-rc3ander+ #300 > Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS > GELKRVPA.X64.0023.B40.1611302145 11/30/2016 > Workqueue: events_unbound async_run_entry_fn > Call Trace: > dump_stack+0x86/0xc3 > __warn+0xcb/0xf0 > warn_slowpath_fmt+0x5f/0x80 > verify_connector_state.isra.80+0x26c/0x2b0 [i915] > intel_atomic_commit_tail+0x520/0x1000 [i915] > ? remove_wait_queue+0x70/0x70 > intel_atomic_commit+0x3f8/0x520 [i915] > ? intel_runtime_pm_put+0x6e/0xa0 [i915] > drm_atomic_commit+0x4b/0x50 [drm] > __intel_display_resume+0x72/0xc0 [i915] > intel_display_resume+0x107/0x150 [i915] > i915_drm_resume+0xe0/0x180 [i915] > i915_pm_restore+0x1e/0x30 [i915] > i915_pm_resume+0xe/0x10 [i915] > pci_pm_resume+0x64/0xa0 > dpm_run_callback+0xa1/0x2a0 > ? pci_pm_thaw+0x90/0x90 > device_resume+0xe3/0x200 > async_resume+0x1d/0x50 > async_run_entry_fn+0x39/0x170 > process_one_work+0x212/0x670 > ? process_one_work+0x197/0x670 > worker_thread+0x4e/0x490 > kthread+0x101/0x140 > ? process_one_work+0x670/0x670 > ? kthread_create_on_node+0x60/0x60 > ret_from_fork+0x2a/0x40 > > Cc: David Weinehall > Signed-off-by: Ander Conselvan de Oliveira > LGTM, Reviewed-by: David Weinehall > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 8795679..b729a39 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -469,14 +469,11 @@ static void hsw_set_power_well(struct drm_i915_private > *dev_priv, > BIT_ULL(POWER_DOMAIN_VGA) | \ > BIT_ULL(POWER_DOMAIN_INIT)) > #define GLK_DISPLAY_DDI_A_POWER_DOMAINS (\ > - BIT_ULL(POWER_DOMAIN_PORT_DDI_A_LANES) |\ > - BIT_ULL(POWER_DOMAIN_INIT)) > + BIT_ULL(POWER_DOMAIN_PORT_DDI_A_LANES)) > #define GLK_DISPLAY_DDI_B_POWER_DOMAINS (\ > - BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES) |\ > - BIT_ULL(POWER_DOMAIN_INIT)) > + BIT_ULL(POWER_DOMAIN_PORT_DDI_B_LANES)) > #define GLK_DISPLAY_DDI_C_POWER_DOMAINS (\ > - BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\ > - BIT_ULL(POWER_DOMAIN_INIT)) > + BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES)) > #define GLK_DPIO_CMN_A_POWER_DOMAINS ( \ > BIT_ULL(POWER_DOMAIN_PORT_DDI_A_LANES) |\ > BIT_ULL(POWER_DOMAIN_AUX_A) | \ > -- > 2.9.3 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Black screen after switching desktop session (was: Re: Linux 4.10-rc5)
time consuming; the full combinatorial testcase, for instance, can take weeks or months--I haven't done a full run recently--to complete. I hope this helps you understand why bugs can slip under the radar, and why a bisect is so important. Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/glk: Turn on workarounds that apply to Geminilake too
On Thu, Jan 26, 2017 at 11:16:58AM +0200, Ander Conselvan de Oliveira wrote:
> Apply workarounds to Geminilake, and annotate those that are applied
> unconditionally when they apply to GLK based on the workaround database.
>
> v2: Fix commit message typos. (David)
> v3: Rebase.
> Cc: David Weinehall
> Cc: Rodrigo Vivi
> Signed-off-by: Ander Conselvan de Oliveira
>
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
> drivers/gpu/drm/i915/intel_lrc.c| 6 +++---
> drivers/gpu/drm/i915/intel_mocs.c | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 23
> drivers/gpu/drm/i915/intel_ringbuffer.c | 37
> +
> 5 files changed, 53 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 40685c6..048040e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2184,14 +2184,14 @@ static void gtt_write_workarounds(struct
> drm_i915_private *dev_priv)
>* called on driver load and after a GPU reset, so you can place
>* workarounds here even if they get overwritten by GPU reset.
>*/
> - /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl */
> + /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl,glk */
> if (IS_BROADWELL(dev_priv))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW);
> else if (IS_CHERRYVIEW(dev_priv))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_CHV);
> else if (IS_GEN9_BC(dev_priv))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
> - else if (IS_BROXTON(dev_priv))
> + else if (IS_GEN9_LP(dev_priv))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index bee9d56..0e7b950 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1101,13 +1101,13 @@ static int gen9_init_indirectctx_bb(struct
> intel_engine_cs *engine,
> struct drm_i915_private *dev_priv = engine->i915;
> uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
>
> - /* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt */
> + /* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt,glk */
> ret = gen8_emit_flush_coherentl3_wa(engine, batch, index);
> if (ret < 0)
> return ret;
> index = ret;
>
> - /* WaDisableGatherAtSetShaderCommonSlice:skl,bxt,kbl */
> + /* WaDisableGatherAtSetShaderCommonSlice:skl,bxt,kbl,glk */
> wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
> wa_ctx_emit_reg(batch, index, COMMON_SLICE_CHICKEN2);
> wa_ctx_emit(batch, index, _MASKED_BIT_DISABLE(
> @@ -1131,7 +1131,7 @@ static int gen9_init_indirectctx_bb(struct
> intel_engine_cs *engine,
> wa_ctx_emit(batch, index, 0);
> }
>
> - /* WaMediaPoolStateCmdInWABB:bxt */
> + /* WaMediaPoolStateCmdInWABB:bxt,glk */
> if (HAS_POOLED_EU(engine->i915)) {
> /*
>* EU pool configuration is setup along with golden context
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> index 8f98fc7..773e362 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -191,7 +191,7 @@ static bool get_mocs_settings(struct drm_i915_private
> *dev_priv,
> "Platform that should have a MOCS table does not.\n");
> }
>
> - /* WaDisableSkipCaching:skl,bxt,kbl */
> + /* WaDisableSkipCaching:skl,bxt,kbl,glk */
> if (IS_GEN9(dev_priv)) {
> int i;
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 08548a4..8fc1e89f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -65,12 +65,12 @@ static void gen9_init_clock_gating(struct
> drm_i915_private *dev_priv)
> I915_WRITE(GEN8_CONFIG0,
> I915_READ(GEN8_CONFIG0) | GEN9_DEFAULT_FIXES);
>
> - /* WaEnableChickenDCPR:skl,bxt,kbl */
> + /* WaEnableChickenDCPR:skl,bxt,kbl,glk */
> I915_WRITE(GEN8_CHICKEN_DCPR_1,
> I915_READ(GEN8_CHICKEN_DCPR_1) | MASK_WAKEMEM);
>
> /* WaFbcTurnOffFbcWatermark:skl,bxt,kbl */
> - /* WaFbcWakeMemOn:skl,bxt,kbl */
> + /* WaFbcWakeMemOn:skl,bxt,kbl,glk */
> I915_WRI
Re: [Intel-gfx] [PATCH 3/3] drm/i915/glk: Turn on workarounds that apply to Geminilake too
On Thu, Jan 12, 2017 at 01:47:37PM +0200, Ander Conselvan de Oliveira wrote:
> Apply workarounds to Geminilake, and annoatate those that are applied
annotate
> uncondionally when they apply to GLK based on the workaround database.
unconditionally
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
> drivers/gpu/drm/i915/intel_lrc.c| 6 +++---
> drivers/gpu/drm/i915/intel_mocs.c | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 23
> drivers/gpu/drm/i915/intel_ringbuffer.c | 37
> +
> 5 files changed, 53 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 0ed99adf..7024144 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2167,14 +2167,14 @@ static void gtt_write_workarounds(struct
> drm_i915_private *dev_priv)
>* called on driver load and after a GPU reset, so you can place
>* workarounds here even if they get overwritten by GPU reset.
>*/
> - /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt */
> + /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,glk */
> if (IS_BROADWELL(dev_priv))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW);
> else if (IS_CHERRYVIEW(dev_priv))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_CHV);
> else if (IS_SKYLAKE(dev_priv))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
> - else if (IS_BROXTON(dev_priv))
> + else if (IS_GEN9_LP(dev_priv))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index db714dc..7bb3d0a 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1126,13 +1126,13 @@ static int gen9_init_indirectctx_bb(struct
> intel_engine_cs *engine,
> if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
> wa_ctx_emit(batch, index, MI_ARB_ON_OFF | MI_ARB_DISABLE);
>
> - /* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt */
> + /* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt,glk */
> ret = gen8_emit_flush_coherentl3_wa(engine, batch, index);
> if (ret < 0)
> return ret;
> index = ret;
>
> - /* WaDisableGatherAtSetShaderCommonSlice:skl,bxt,kbl */
> + /* WaDisableGatherAtSetShaderCommonSlice:skl,bxt,kbl,glk */
> wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
> wa_ctx_emit_reg(batch, index, COMMON_SLICE_CHICKEN2);
> wa_ctx_emit(batch, index, _MASKED_BIT_DISABLE(
> @@ -1156,7 +1156,7 @@ static int gen9_init_indirectctx_bb(struct
> intel_engine_cs *engine,
> wa_ctx_emit(batch, index, 0);
> }
>
> - /* WaMediaPoolStateCmdInWABB:bxt */
> + /* WaMediaPoolStateCmdInWABB:bxt,glk */
> if (HAS_POOLED_EU(engine->i915)) {
> /*
>* EU pool configuration is setup along with golden context
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> index c787fc4..9c67534 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -191,7 +191,7 @@ static bool get_mocs_settings(struct drm_i915_private
> *dev_priv,
> "Platform that should have a MOCS table does not.\n");
> }
>
> - /* WaDisableSkipCaching:skl,bxt,kbl */
> + /* WaDisableSkipCaching:skl,bxt,kbl,glk */
> if (IS_GEN9(dev_priv)) {
> int i;
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b257343..c8ebf1d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -65,12 +65,12 @@ static void gen9_init_clock_gating(struct
> drm_i915_private *dev_priv)
> I915_WRITE(GEN8_CONFIG0,
> I915_READ(GEN8_CONFIG0) | GEN9_DEFAULT_FIXES);
>
> - /* WaEnableChickenDCPR:skl,bxt,kbl */
> + /* WaEnableChickenDCPR:skl,bxt,kbl,glk */
> I915_WRITE(GEN8_CHICKEN_DCPR_1,
> I915_READ(GEN8_CHICKEN_DCPR_1) | MASK_WAKEMEM);
>
> /* WaFbcTurnOffFbcWatermark:skl,bxt,kbl */
> - /* WaFbcWakeMemOn:skl,bxt,kbl */
> + /* WaFbcWakeMemOn:skl,bxt,kbl,glk */
> I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
> DISP_FBC_WM_DIS |
> DISP_FBC_MEMORY_WAKE);
> @@ -107,6 +107,19 @@ static void bxt_init_clock_gating(struct
> drm_i915_private *dev_priv)
> PWM1_GATING_DIS | PWM2_GATING_DIS);
> }
>
> +static void glk_init_clock_gating(struct drm_i915_private *dev_priv)
> +{
> + gen9_init_clock_gating(dev_priv);
> +
> + /*
> + * WaDisablePWMClockGating:glk
> +
