Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Store max dotclock
On Thu, Jul 30, 2015 at 09:49:28AM +0300, Mika Kahola wrote:
> Store max dotclock into dev_priv structure so we are able
> to filter out the modes that are not supported by our
> platforms.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 20
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 04aa34a..1f69211b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1777,6 +1777,7 @@ struct drm_i915_private {
> unsigned int fsb_freq, mem_freq, is_ddr3;
> unsigned int skl_boot_cdclk;
> unsigned int cdclk_freq, max_cdclk_freq;
> + unsigned int max_dotclk;
> unsigned int hpll_freq;
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 43b0f17..9031261 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5259,6 +5259,24 @@ static void modeset_update_crtc_power_domains(struct
> drm_atomic_state *state)
> modeset_put_power_domains(dev_priv, put_domains[i]);
> }
>
> +static int intel_update_max_dotclk(struct drm_device *dev)
You don't update max dotclck, you are computing it. The caller is the
one storing it dev_priv->max_dotclk (and so is the one actually doing
the update).
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
So why did you pass in dev if we never use it?
> + int max_cdclk_freq = dev_priv->max_cdclk_freq;
> + int max_dotclk_freq;
> +
> + if (IS_BROADWELL(dev) || IS_CHERRYVIEW(dev))
We already have dev_priv, so please stop doing dev->dev_priv over and
over again.
> + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 100, 95);
> + else if (IS_VALLEYVIEW(dev))
> + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 100, 90);
> + else if (IS_GEN2(dev) || IS_GEN3(dev))
If you reverse this pair and do
else if (INTEL_INFO(dev)->gen > 3)
max_dotclk_freq = max_cdclk_freq;
else
max_dotclk_freq = DIV_ROUND_UP(2 * max_cdclk_freq * 100, 90);
Then the chain is mostly ordered in most-recent to oldest, always
helpful for the next person.
Is this correct for gen9+?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tools: Add LD_PRELOAD-base AUB dumper tool
From: Kristian Høgsberg Kristensen
This does everything the aub dump functionality in libdrm does, but
without being part of libdrm. This moves the very developer oriented
functionality out of core libdrm and adds some flexibility in how we
activate it (we can specify filename, for example). Most importantly,
this lets us dump aub files for tools and/or drivers that don't use
libdrm, without having to add that code to each of those projects.
The tool is used much like strace or valgrind. For example:
$ intel_aubdump -v --output=stuff.aub -- glxgears -geometry 500x500
will launch glxgears with its options and enable aub dumping and pass
the -v and --output=stuff.aub options to the aub dumper.
Signed-off-by: Kristian Høgsberg Kristensen
---
configure.ac | 5 +-
tools/.gitignore | 1 +
tools/Makefile.am | 12 ++
tools/aubdump.c| 505 +
tools/intel_aub.h | 153 +++
tools/intel_aubdump.in | 68 +++
6 files changed, 743 insertions(+), 1 deletion(-)
create mode 100644 tools/aubdump.c
create mode 100644 tools/intel_aub.h
create mode 100644 tools/intel_aubdump.in
diff --git a/configure.ac b/configure.ac
index 3770b2f..6fc63e4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -255,6 +255,7 @@ AC_CONFIG_FILES([
scripts/Makefile
tests/Makefile
tools/Makefile
+tools/intel_aubdump
tools/quick_dump/Makefile
tools/null_state_gen/Makefile
debugger/Makefile
@@ -264,7 +265,9 @@ AC_CONFIG_FILES([
assembler/test/Makefile
assembler/intel-gen4asm.pc
overlay/Makefile
-])
+],
+[chmod +x tools/intel_aubdump])
+
AC_OUTPUT
# Print a summary of the compilation
diff --git a/tools/.gitignore b/tools/.gitignore
index a09d9e8..49bd24f 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -1,6 +1,7 @@
# Please keep sorted alphabetically
hsw_compute_wrpll
igt_stats
+intel_aubdump
intel_audio_dump
intel_backlight
intel_bios_dumper
diff --git a/tools/Makefile.am b/tools/Makefile.am
index da971c3..95f13f9 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -10,3 +10,15 @@ AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/lib
AM_CFLAGS = $(DEBUG_CFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) $(CWARNFLAGS)
$(CAIRO_CFLAGS) $(LIBUNWIND_CFLAGS)
LDADD = $(top_builddir)/lib/libintel_tools.la $(DRM_LIBS) $(PCIACCESS_LIBS)
$(CAIRO_LIBS) $(LIBUDEV_LIBS) $(LIBUNWIND_LIBS) -lm
+
+# aubdumper
+
+module_LTLIBRARIES = intel_aubdump.la
+moduledir = $(libdir)
+intel_aubdump_la_LDFLAGS = -module -avoid-version -no-undefined
+intel_aubdump_la_SOURCES = aubdump.c intel_aub.h
+intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la
+
+bin_SCRIPTS = intel_aubdump
+CLEANFILES = $(bin_SCRIPTS)
+
diff --git a/tools/aubdump.c b/tools/aubdump.c
new file mode 100644
index 000..cfbd58f
--- /dev/null
+++ b/tools/aubdump.c
@@ -0,0 +1,505 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#define _GNU_SOURCE /* for RTLD_NEXT */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "intel_aub.h"
+#include "intel_chipset.h"
+
+static int (*libc_open)(const char *pathname, int flags, mode_t mode);
+static int (*libc_ioctl)(int fd, unsigned long request, void *argp);
+
+static int drm_fd = -1;
+static char *filename;
+static FILE *file;
+static int gen = 0;
+static int verbose = 0;
+static const uint32_t gtt_size = 0x1;
+
+#define MAX_BO_COUNT 64 * 1024
+
+struct bo {
+ uint32_t size;
+ uint32_t offset;
+ void *map;
+};
+
+static struct bo *bos;
+
+#define DRM_MAJOR 22
[Intel-gfx] drm/atomic: Reject events for inactive crtc's.
This will cause drm_atomic_helper_page_flip and drm_mode_atomic_ioctl to
fail with -EINVAL if a event is requested on a inactive crtc.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d719ce0b10a0..679577e8e02d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -476,6 +476,12 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return -EINVAL;
}
+ if (!state->active && state->event) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event and not active\n",
+crtc->base.id);
+ return -EINVAL;
+ }
+
/* The state->enable vs. state->mode_blob checks can be WARN_ON,
* as this is a kernel-internal detail that userspace should never
* be able to trigger. */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/18] drm/i915/gen9: Removed byte swapping for csr firmware.
On Tuesday 28 July 2015 04:39 PM, Sunil Kamath wrote:
On Tuesday 28 July 2015 01:38 PM, Nagaraju, Vathsala wrote:
Signed-off-by: Vatsala Nagaraju
It's Vathsala Nagaraju
Commit message: Removed byte swapping for csr firmware.
Commit message does not convey as to why the change was made. "This
change is needed as DMC firmware loading failed on skylake due byte
swap done in the driver"
yes. agree.
Same review comments as other patches. Bug fixing patches should go
first in sequence and also commit message should contain relevant info
on fix/patch.
This byte swapping is not needed at all.
Minimal things to take care.
- Sunil
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
Behalf Of Animesh Manna
Sent: Sunday, July 26, 2015 12:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vatsala Nagaraju
Subject: [Intel-gfx] [PATCH 18/18] drm/i915/gen9: Removed byte
swapping for csr firmware.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vatsala Nagaraju
---
drivers/gpu/drm/i915/intel_csr.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c
b/drivers/gpu/drm/i915/intel_csr.c
index 1858f02..50779e0 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -328,16 +328,7 @@ static uint32_t *parse_csr_fw(struct
drm_i915_private *dev_priv,
return NULL;
}
-for (i = 0; i < dmc_header->fw_size; i++) {
-uint32_t *tmp = (u32 *)&fw->data[readcount + i * 4];
-/*
- * The firmware payload is an array of 32 bit words stored in
- * little-endian format in the firmware image and programmed
- * as 32 bit big-endian format to memory.
- */
-dmc_payload[i] = (uint32_t __force) cpu_to_be32(*tmp);
-}
-
+memcpy(dmc_payload, &fw->data[readcount], dmc_header->fw_size);
*4 missing for byte conversion here.
memcpy(dmc_payload, &fw->data[readcount], (dmc_header->fw_size)*4); ?
Still issue to be addressed here to confirm that fw is loaded fine.
- Sunil
return dmc_payload;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/18] drm/i915/skl: Removed csr firmware load in resume path.
On Wednesday 29 July 2015 04:40 PM, Sunil Kamath wrote: On Tuesday 28 July 2015 04:53 PM, Sunil Kamath wrote: On Sunday 26 July 2015 12:30 AM, Animesh Manna wrote: As csr firmware is taking care of loading the firmware, so no need for driver to load again. Cc: Damien Lespiau Cc: Imre Deak Cc: Sunil Kamath Signed-off-by: Animesh Manna Signed-off-by: Vathsala Nagaraju --- drivers/gpu/drm/i915/i915_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 77b35fd..f5e720b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1048,7 +1048,6 @@ static int skl_resume_prepare(struct drm_i915_private *dev_priv) skl_disable_dc6(dev_priv); skl_init_cdclk(dev_priv); -intel_csr_load_program(dev_priv); The context save and restore program is reset on cold boot, warm reset, PCI function level reset, and hibernate/suspend. Will it not impact? - Sunil If the intention is just to check the DC5/DC6 counters, why cant we just add debug prints before f/w reload? Than to just avoiding reloading fw itself. - Sunil Dont hurry on this patch. Need to close on the above opens. - Sunil return 0; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915/skl: Do not disable cdclk PLL if csr firmware is present.
On Sunday 26 July 2015 12:30 AM, Animesh Manna wrote:
While display engine entering into low power state no need to disable
cdclk pll as CSR firmware of dmc will take care. If pll is already
enabled firmware execution sequence will be blocked. This is one
of the criteria for dmc to work properly.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-bt: Vathsala Nagaraju
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af0bcfe..ef2ef4d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5675,10 +5675,13 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
DRM_ERROR("DBuf power disable timeout\n");
- /* disable DPLL0 */
- I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) & ~LCPLL_PLL_ENABLE);
- if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
- DRM_ERROR("Couldn't disable DPLL0\n");
+ if (dev_priv->csr.dmc_payload) {
+ /* disable DPLL0 */
+ I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) &
+ ~LCPLL_PLL_ENABLE);
+ if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
+ DRM_ERROR("Couldn't disable DPLL0\n");
+ }
intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
}
This is a right bug fix.
Reviewed-by: A.Sunil Kamath
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Declare the swizzling unknown for L-shaped configurations
On Sun, Jun 28, 2015 at 09:19:26AM +0100, Chris Wilson wrote: > The old style of memory interleaving swizzled upto the end of the > first even bank of memory, and then used the remainder as unswizzled on > the unpaired bank - i.e. swizzling is not constant for all memory. This > causes problems when we try to migrate memory and so the kernel prevents > migration at all when we detect L-shaped inconsistent swizzling. > However, this issue also extends to userspace who try to manually detile > into memory as the swizzling for an individual page is unknown (it > depends on its physical address only known to the kernel), userspace > cannot correctly swizzle. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105 > Signed-off-by: Chris Wilson > Cc: Daniel Vetter > Cc: sta...@vger.kernel.org Daniel since you dropped v2 and had already reviewed this version, it would have been useful had you done the swap... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/18] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
On Sunday 26 July 2015 12:30 AM, Animesh Manna wrote:
Mmio register access after dc6/dc5 entry is causing the
system hang, so enabling dc6 as the last call in suspend flow.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 19 +++
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ddf8a25..77b35fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -995,6 +995,9 @@ static int i915_pm_resume(struct device *dev)
static int skl_suspend_complete(struct drm_i915_private *dev_priv)
{
+ if (dev_priv->csr.dmc_payload)
+ skl_enable_dc6(dev_priv);
+
skl_uninit_cdclk(dev_priv);
This is really right change.
With this we will go back to our original design.
Deepest possible display state will be triggered by respective suspend
complete.
for example in BXT we trigger DC9 from bxt_suspend_complete and works
fine with rpm integrated.
Same case here for SKL for DC6 which uses DMC.
Right bug fix.
Reviewed-by: A.Sunil Kamath
return 0;
@@ -1041,6 +1044,9 @@ static int bxt_resume_prepare(struct drm_i915_private
*dev_priv)
static int skl_resume_prepare(struct drm_i915_private *dev_priv)
{
+ if (dev_priv->csr.dmc_payload)
+ skl_disable_dc6(dev_priv);
+
skl_init_cdclk(dev_priv);
intel_csr_load_program(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 644286f..0d13f50 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv);
void skl_init_cdclk(struct drm_i915_private *dev_priv);
void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
+void skl_enable_dc6(struct drm_i915_private *dev_priv);
+void skl_disable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index a5059e8..ddae00e 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -540,7 +540,7 @@ static void assert_can_disable_dc6(struct drm_i915_private
*dev_priv)
"DC6 already programmed to be disabled.\n");
}
-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
+void skl_enable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -557,7 +557,7 @@ static void skl_enable_dc6(struct drm_i915_private *dev_priv)
POSTING_READ(DC_STATE_EN);
}
-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
+void skl_disable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -618,10 +618,10 @@ static void skl_set_power_well(struct drm_i915_private *dev_priv,
!I915_READ(HSW_PWR_WELL_BIOS),
"Invalid for power well status to be enabled,
unless done by the BIOS, \
when request is to disable!\n");
- if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
- power_well->data == SKL_DISP_PW_2) {
+ if (power_well->data == SKL_DISP_PW_2) {
+ if (GEN9_ENABLE_DC5(dev))
+ gen9_disable_dc5(dev_priv);
if (SKL_ENABLE_DC6(dev)) {
- skl_disable_dc6(dev_priv);
/*
* DDI buffer programming unnecessary
during driver-load/resume
* as it's already done during modeset
initialization then.
@@ -629,8 +629,6 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
*/
if
(!dev_priv->power_domains.initializing)
intel_prepare_ddi(dev);
- } else {
- gen9_disable_dc5(dev_priv);
}
}
I915_WRITE(HSW_PWR_WELL_DRIVER, tmp | req_mask);
@@ -650,12 +648,9 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
POSTING_READ(HSW_PWR_WELL_DRIVER);
DRM_DEBUG_KMS("Dis
Re: [Intel-gfx] [PATCH v2 08/12] drm/i915: Remove connectors_active from sanitization.
Op 29-07-15 om 15:09 schreef Ander Conselvan De Oliveira:
> On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
>> connectors_active will be removed, so just calculate this right here.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 17 ++---
>> 1 file changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index ed9eba2666e2..341fadb40c81 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14935,8 +14935,10 @@ static void intel_sanitize_crtc(struct intel_crtc
>> *crtc)
>> /* Adjust the state of the output pipe according to whether we
>> * have active connectors/encoders. */
>> enable = false;
>> -for_each_encoder_on_crtc(dev, &crtc->base, encoder)
>> -enable |= encoder->connectors_active;
>> +for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
>> +enable = true;
>> +break;
>> +}
>>
>> if (!enable)
>> intel_crtc_disable_noatomic(&crtc->base);
>> @@ -14992,6 +14994,7 @@ static void intel_sanitize_encoder(struct
>> intel_encoder *encoder)
>> {
>> struct intel_connector *connector;
>> struct drm_device *dev = encoder->base.dev;
>> +bool active = false;
>>
>> /* We need to check both for a crtc link (meaning that the
>> * encoder is active and trying to read from a pipe) and the
>> @@ -14999,7 +15002,15 @@ static void intel_sanitize_encoder(struct
>> intel_encoder *encoder)
>> bool has_active_crtc = encoder->base.crtc &&
>> to_intel_crtc(encoder->base.crtc)->active;
>>
>> -if (encoder->connectors_active && !has_active_crtc) {
>> +for_each_intel_connector(dev, connector) {
>> +if (connector->encoder != encoder)
> Shouldn't this be connector->base.encoder?
>
> Ander
Well ideally connector->state->best_encoder, but yeah looks like we haven't set
that up here yet, so connector->base.encoder is probably the right member to
check..
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fixup locking WARNINGs in drm_mode_config_reset
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6887 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 297/297 296/297 SNB 315/315 315/315 IVB 342/342 342/342 BYT 282/282 282/282 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@flip-vs-dpms-interruptible PASS(1) DMESG_WARN(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: read bpp from vbt only for older panels
From: "Thulasimani,Sivakumar"
BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and hence should be preferred over any value
programmed in VBT.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..898dc74 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -132,6 +132,7 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp,
bool sync);
static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
static void vlv_steal_power_sequencer(struct drm_device *dev,
enum pipe pipe);
+static struct edid * intel_dp_get_edid(struct intel_dp *intel_dp);
static int
intel_dp_max_link_bw(struct intel_dp *intel_dp)
@@ -1353,6 +1354,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct edid *edid = NULL;
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1409,12 +1411,19 @@ intel_dp_compute_config(struct intel_encoder *encoder,
* bpc in between. */
bpp = pipe_config->pipe_bpp;
if (is_edp(intel_dp)) {
- if (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp) {
+ edid = intel_dp_get_edid(intel_dp);
+
+ /* Get bpp from vbt only for panels with edid 1.3 or older */
+ if (edid && edid->version == 1 && edid->revision <= 3 &&
+ (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp))
{
DRM_DEBUG_KMS("clamping bpp for eDP panel to
BIOS-provided %i\n",
dev_priv->vbt.edp_bpp);
bpp = dev_priv->vbt.edp_bpp;
}
+ if (edid)
+ kfree(edid);
+
/*
* Use the maximum clock and number of lanes the eDP panel
* advertizes being capable of. The panels are generally
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries for CHV
From: "Thulasimani,Sivakumar"
CHV does not support intermediate link rates nor does it support
HBR2. This patch removes those entries and returns HBR as the max
link rate supported on CHV platform.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 898dc74..5c68b17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
27,
324000, 432000, 54 };
static const int skl_rates[] = { 162000, 216000, 27,
324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
static const int default_rates[] = { 162000, 27, 54 };
/**
@@ -1186,15 +1183,13 @@ intel_dp_source_rates(struct drm_device *dev, const int
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
- } else if (IS_CHERRYVIEW(dev)) {
- *source_rates = chv_rates;
- return ARRAY_SIZE(chv_rates);
}
*source_rates = default_rates;
- if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0)
- /* WaDisableHBR2:skl */
+ /* WaDisableHBR2:skl */
+ if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) ||
+ IS_CHERRYVIEW(dev))
return (DP_LINK_BW_2_7 >> 3) + 1;
else if (INTEL_INFO(dev)->gen >= 8 ||
(IS_HASWELL(dev) && !IS_HSW_ULX(dev)))
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/12] drm/i915: Remove connectors_active from intel_dp.c.
On Thu, 2015-07-30 at 08:54 +0200, Maarten Lankhorst wrote: > Op 29-07-15 om 15:26 schreef Ander Conselvan De Oliveira: > > On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote: > > > Now that everything's atomic, checking encoder->base.crtc is enough. > > Don't you need to check encoder->base.crtc->state->active too? > Not sure, I think stealing a encoder being bound to any crtc is probably good > enough reason to > warn. > We probably don't hold the right lock to dereference crtc->state. Fair enough. Add that to the commit message and you can add Reviewed-by: Ander Conselvan de Oliveira ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 04/19] drm/i915/gen8: Generalize PTE writing for GEN8 PPGTT
On 7/30/2015 5:46 AM, Goel, Akash wrote:
On 7/29/2015 9:53 PM, Michel Thierry wrote:
The insert_entries function was the function used to write PTEs. For the
PPGTT it was "hardcoded" to only understand two level page tables, which
was the case for GEN7. We can reuse this for 4 level page tables, and
remove the concept of insert_entries, which was never viable past 2
level page tables anyway, but it requires a bit of rework to make the
function a bit more generic.
This patch begins the generalization work, and it will be heavily used
upon when the 48b code is complete. The patch series attempts to make
each function which touches a part of code specific to the page table
level and here is no exception.
v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v3: Rebase after final merged version of Mika's ppgtt/scratch patches.
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 52
+++--
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bd56979..f338a13 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -600,24 +600,21 @@ static int gen8_mm_switch(struct i915_hw_ppgtt
*ppgtt,
return 0;
}
-static void gen8_ppgtt_clear_range(struct i915_address_space *vm,
- uint64_t start,
- uint64_t length,
- bool use_scratch)
+static void gen8_ppgtt_clear_pte_range(struct i915_address_space *vm,
+ struct i915_page_directory_pointer *pdp,
+ uint64_t start,
+ uint64_t length,
+ gen8_pte_t scratch_pte)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
-struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME:
48b */
-gen8_pte_t *pt_vaddr, scratch_pte;
+gen8_pte_t *pt_vaddr;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
unsigned pte = start >> GEN8_PTE_SHIFT & GEN8_PTE_MASK;
unsigned num_entries = length >> PAGE_SHIFT;
unsigned last_pte, i;
-scratch_pte = gen8_pte_encode(px_dma(ppgtt->base.scratch_page),
- I915_CACHE_LLC, use_scratch);
-
Sorry for the late comment.
Would it be better to have a WARN_ON check here on NULL value of pdp
pointer, considering the pdp will no longer be static in case of 48 bit.
Actually there are already such checks used in this function for pd, pt
and page pointers.
Best regards
Akash
Ok, I'll add the extra WARN_ON(!pdp).
-Michel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 06/19] drm/i915/gen8: Add PML4 structure
On 7/30/2015 5:01 AM, Goel, Akash wrote:
On 7/29/2015 9:53 PM, Michel Thierry wrote:
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
Cc: Akash Goel
Signed-off-by: Michel Thierry
@@ -557,6 +563,8 @@ static void free_pdp(struct drm_device *dev,
struct i915_page_directory_pointer *pdp)
{
__pdp_fini(pdp);
+if (USES_FULL_48BIT_PPGTT(dev))
+kfree(pdp);
Sorry for the late comment.
This change is a bit of distraction here, should be moved to the
following 'alloc/free for 4lvl' patch.
Best regards
Akash
kfree(pdp) moved to patch 7/19.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 08/19] drm/i915/gen8: Add 4 level switching infrastructure and lrc support
On 7/30/2015 5:14 AM, Goel, Akash wrote:
On 7/29/2015 9:53 PM, Michel Thierry wrote:
@@ -1512,12 +1522,15 @@ static int gen8_emit_bb_start(struct
drm_i915_gem_request *req,
* Ideally, we should set Force PD Restore in ctx descriptor,
* but we can't. Force Restore would be a second option, but
* it is unsafe in case of lite-restore (because the ctx is
- * not idle). */
+ * not idle). PML4 is allocated during ppgtt init so this is
+ * not needed in 48-bit.*/
if (req->ctx->ppgtt &&
(intel_ring_flag(req->ring) &
req->ctx->ppgtt->pd_dirty_rings)) {
-ret = intel_logical_ring_emit_pdps(req);
-if (ret)
-return ret;
+if (GEN8_CTX_ADDRESSING_MODE(req->i915) == LEGACY_32B_CONTEXT) {
Sorry for the late comment.
For consistency, better to use 'USES_FULL_48BIT_PPGTT' macro only here,
as that will also imply the same thing i.e. which type of Context
addressing mode is being used.
Best regards
Akash
Ack. I'm changing it to if (!USES_FULL_48BIT_PPGTT(req->i915)).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: read bpp from vbt only for older panels
On Thu, 30 Jul 2015, Sivakumar Thulasimani
wrote:
> From: "Thulasimani,Sivakumar"
>
> BPP bits defined in VBT should be used only on panels whose
> edid version is 1.3 or older. EDID version 1.4 introduced offsets
> where bpp is defined and hence should be preferred over any value
> programmed in VBT.
Should we actually look at the EDID bpp somewhere?
> Signed-off-by: Sivakumar Thulasimani
> ---
> drivers/gpu/drm/i915/intel_dp.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 44f8a32..898dc74 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -132,6 +132,7 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp,
> bool sync);
> static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
> static void vlv_steal_power_sequencer(struct drm_device *dev,
> enum pipe pipe);
> +static struct edid * intel_dp_get_edid(struct intel_dp *intel_dp);
>
> static int
> intel_dp_max_link_bw(struct intel_dp *intel_dp)
> @@ -1353,6 +1354,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> enum port port = dp_to_dig_port(intel_dp)->port;
> struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
> struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct edid *edid = NULL;
> int lane_count, clock;
> int min_lane_count = 1;
> int max_lane_count = intel_dp_max_lane_count(intel_dp);
> @@ -1409,12 +1411,19 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>* bpc in between. */
> bpp = pipe_config->pipe_bpp;
> if (is_edp(intel_dp)) {
> - if (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp) {
> + edid = intel_dp_get_edid(intel_dp);
> +
> + /* Get bpp from vbt only for panels with edid 1.3 or older */
> + if (edid && edid->version == 1 && edid->revision <= 3 &&
> + (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp))
> {
Now you require the panel to have an EDID in order to use the bpp in
VBT.
BR,
Jani.
> DRM_DEBUG_KMS("clamping bpp for eDP panel to
> BIOS-provided %i\n",
> dev_priv->vbt.edp_bpp);
> bpp = dev_priv->vbt.edp_bpp;
> }
>
> + if (edid)
> + kfree(edid);
> +
> /*
>* Use the maximum clock and number of lanes the eDP panel
>* advertizes being capable of. The panels are generally
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries for CHV
On Thu, 30 Jul 2015, Sivakumar Thulasimani
wrote:
> From: "Thulasimani,Sivakumar"
>
> CHV does not support intermediate link rates nor does it support
> HBR2. This patch removes those entries and returns HBR as the max
> link rate supported on CHV platform.
These are two separate changes, and should be two separate
patches. Moreover, the intermediate link rate change should be a revert
of
commit fe51bfb95c996733150c44d21e1c9f4b6322a326
Author: Ville Syrjälä
Date: Thu Mar 12 17:10:38 2015 +0200
drm/i915: Add eDP intermediate frequencies for CHV
with Cc: Ville and Sonika to record this back and forth here.
BR,
Jani.
>
> Signed-off-by: Sivakumar Thulasimani
> ---
> drivers/gpu/drm/i915/intel_dp.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 898dc74..5c68b17 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
> 27,
> 324000, 432000, 54 };
> static const int skl_rates[] = { 162000, 216000, 27,
> 324000, 432000, 54 };
> -static const int chv_rates[] = { 162000, 202500, 21, 216000,
> - 243000, 27, 324000, 405000,
> - 42, 432000, 54 };
> static const int default_rates[] = { 162000, 27, 54 };
>
> /**
> @@ -1186,15 +1183,13 @@ intel_dp_source_rates(struct drm_device *dev, const
> int **source_rates)
> } else if (IS_SKYLAKE(dev)) {
> *source_rates = skl_rates;
> return ARRAY_SIZE(skl_rates);
> - } else if (IS_CHERRYVIEW(dev)) {
> - *source_rates = chv_rates;
> - return ARRAY_SIZE(chv_rates);
> }
>
> *source_rates = default_rates;
>
> - if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0)
> - /* WaDisableHBR2:skl */
> + /* WaDisableHBR2:skl */
> + if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) ||
> + IS_CHERRYVIEW(dev))
> return (DP_LINK_BW_2_7 >> 3) + 1;
> else if (INTEL_INFO(dev)->gen >= 8 ||
> (IS_HASWELL(dev) && !IS_HSW_ULX(dev)))
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 03/19] drm/i915/gen8: Abstract PDP usage
Up until now, ppgtt->pdp has always been the root of our page tables.
Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
In preparation for 4 level page tables, we need to stop using ppgtt->pdp
directly unless we know it's what we want. The future structure will use
ppgtt->pml4 for the top level, and the pdp is just one of the entries
being pointed to by a pml4e. The temporal pdp local variable will be
removed once the rest of the 4-level code lands.
Also, start passing the vm pointer to the alloc functions, instead of
ppgtt.
v2: Updated after dynamic page allocation changes.
v3: Rebase after s/page_tables/page_table/.
v4: Rebase after changes in "Dynamic page table allocations" patch.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rebase after final merged version of Mika's ppgtt/scratch patches.
v7: Keep pagetable map in-line (and avoid unnecessary for_each_pde
loops), remove redundant ppgtt pointer in _alloc_pagetabs (Akash)
v8: Fix text indentation in _alloc_pagetabs/page_directories (Chris)
v9: Defer gen8_alloc_va_range_4lvl definition until 4lvl is implemented,
clean-up gen8_ppgtt_cleanup [pun intended] (Akash).
v10: Clean-up commit message (Akash).
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 84 +++--
1 file changed, 44 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 28f3227..bd56979 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -607,6 +607,7 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
gen8_pte_t *pt_vaddr, scratch_pte;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
@@ -621,10 +622,10 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
struct i915_page_directory *pd;
struct i915_page_table *pt;
- if (WARN_ON(!ppgtt->pdp.page_directory[pdpe]))
+ if (WARN_ON(!pdp->page_directory[pdpe]))
break;
- pd = ppgtt->pdp.page_directory[pdpe];
+ pd = pdp->page_directory[pdpe];
if (WARN_ON(!pd->page_table[pde]))
break;
@@ -662,6 +663,7 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
gen8_pte_t *pt_vaddr;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
@@ -675,7 +677,7 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
break;
if (pt_vaddr == NULL) {
- struct i915_page_directory *pd =
ppgtt->pdp.page_directory[pdpe];
+ struct i915_page_directory *pd =
pdp->page_directory[pdpe];
struct i915_page_table *pt = pd->page_table[pde];
pt_vaddr = kmap_px(pt);
}
@@ -755,28 +757,29 @@ static void gen8_ppgtt_cleanup(struct i915_address_space
*vm)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
+ struct drm_device *dev = ppgtt->base.dev;
int i;
- for_each_set_bit(i, ppgtt->pdp.used_pdpes,
-I915_PDPES_PER_PDP(ppgtt->base.dev)) {
- if (WARN_ON(!ppgtt->pdp.page_directory[i]))
+ for_each_set_bit(i, pdp->used_pdpes, I915_PDPES_PER_PDP(dev)) {
+ if (WARN_ON(!pdp->page_directory[i]))
continue;
- gen8_free_page_tables(ppgtt->base.dev,
- ppgtt->pdp.page_directory[i]);
- free_pd(ppgtt->base.dev, ppgtt->pdp.page_directory[i]);
+ gen8_free_page_tables(dev, pdp->page_directory[i]);
+ free_pd(dev, pdp->page_directory[i]);
}
- free_pdp(ppgtt->base.dev, &ppgtt->pdp);
+ free_pdp(dev, pdp);
+
gen8_free_scratch(vm);
}
/**
* gen8_ppgtt_alloc_pagetabs() - Allocate page tables for VA range.
- * @ppgtt: Master ppgtt structure.
- * @pd:Page directory for this address range.
+ * @vm:Master vm structure.
+ * @pd:Page directory for this address range.
* @start: Starting virtual address to begin allocations.
- * @length Size of the allocations.
[Intel-gfx] [PATCH v7 04/19] drm/i915/gen8: Generalize PTE writing for GEN8 PPGTT
The insert_entries function was the function used to write PTEs. For the
PPGTT it was "hardcoded" to only understand two level page tables, which
was the case for GEN7. We can reuse this for 4 level page tables, and
remove the concept of insert_entries, which was never viable past 2
level page tables anyway, but it requires a bit of rework to make the
function a bit more generic.
v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v3: Rebase after final merged version of Mika's ppgtt/scratch patches.
v4: Check and warn for NULL value of pdp pointer (Akash).
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 53 -
1 file changed, 41 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bd56979..740ad5b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -600,23 +600,23 @@ static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
return 0;
}
-static void gen8_ppgtt_clear_range(struct i915_address_space *vm,
- uint64_t start,
- uint64_t length,
- bool use_scratch)
+static void gen8_ppgtt_clear_pte_range(struct i915_address_space *vm,
+ struct i915_page_directory_pointer *pdp,
+ uint64_t start,
+ uint64_t length,
+ gen8_pte_t scratch_pte)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
- struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
- gen8_pte_t *pt_vaddr, scratch_pte;
+ gen8_pte_t *pt_vaddr;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
unsigned pte = start >> GEN8_PTE_SHIFT & GEN8_PTE_MASK;
unsigned num_entries = length >> PAGE_SHIFT;
unsigned last_pte, i;
- scratch_pte = gen8_pte_encode(px_dma(ppgtt->base.scratch_page),
- I915_CACHE_LLC, use_scratch);
+ if (WARN_ON(!pdp))
+ return;
while (num_entries) {
struct i915_page_directory *pd;
@@ -656,14 +656,30 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
}
}
-static void gen8_ppgtt_insert_entries(struct i915_address_space *vm,
- struct sg_table *pages,
- uint64_t start,
- enum i915_cache_level cache_level, u32
unused)
+static void gen8_ppgtt_clear_range(struct i915_address_space *vm,
+ uint64_t start,
+ uint64_t length,
+ bool use_scratch)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
+
+ gen8_pte_t scratch_pte = gen8_pte_encode(px_dma(vm->scratch_page),
+I915_CACHE_LLC, use_scratch);
+
+ gen8_ppgtt_clear_pte_range(vm, pdp, start, length, scratch_pte);
+}
+
+static void
+gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
+ struct i915_page_directory_pointer *pdp,
+ struct sg_table *pages,
+ uint64_t start,
+ enum i915_cache_level cache_level)
+{
+ struct i915_hw_ppgtt *ppgtt =
+ container_of(vm, struct i915_hw_ppgtt, base);
gen8_pte_t *pt_vaddr;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
@@ -700,6 +716,19 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
kunmap_px(ppgtt, pt_vaddr);
}
+static void gen8_ppgtt_insert_entries(struct i915_address_space *vm,
+ struct sg_table *pages,
+ uint64_t start,
+ enum i915_cache_level cache_level,
+ u32 unused)
+{
+ struct i915_hw_ppgtt *ppgtt =
+ container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
+
+ gen8_ppgtt_insert_pte_entries(vm, pdp, pages, start, cache_level);
+}
+
static void gen8_free_page_tables(struct drm_device *dev,
struct i915_page_directory *pd)
{
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskto
[Intel-gfx] [PATCH v7 06/19] drm/i915/gen8: Add PML4 structure
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
v4: kfree the pdp until the 4lvl alloc/free patch (Akash).
Cc: Akash Goel
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 36 +++-
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
3 files changed, 46 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..4729eaf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2498,7 +2498,8 @@ struct drm_i915_cmd_table {
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 6)
#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 8)
#define USES_PPGTT(dev)(i915.enable_ppgtt)
-#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt == 2)
+#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt >= 2)
+#define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
#define HAS_OVERLAY(dev) (INTEL_INFO(dev)->has_overlay)
#define OVERLAY_NEEDS_PHYSICAL(dev)
(INTEL_INFO(dev)->overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f71746..3288154 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -104,9 +104,12 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
{
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
+ bool has_full_64bit_ppgtt;
has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
+ has_full_64bit_ppgtt = (IS_BROADWELL(dev) ||
+ INTEL_INFO(dev)->gen >= 9) && false; /* FIXME:
64b */
if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
@@ -125,6 +128,9 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
if (enable_ppgtt == 2 && has_full_ppgtt)
return 2;
+ if (enable_ppgtt == 3 && has_full_64bit_ppgtt)
+ return 3;
+
#ifdef CONFIG_INTEL_IOMMU
/* Disable ppgtt on SNB if VT-d is on. */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) {
@@ -689,9 +695,6 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
pt_vaddr = NULL;
for_each_sg_page(pages->sgl, &sg_iter, pages->nents, 0) {
- if (WARN_ON(pdpe >= GEN8_LEGACY_PDPES))
- break;
-
if (pt_vaddr == NULL) {
struct i915_page_directory *pd =
pdp->page_directory[pdpe];
struct i915_page_table *pt = pd->page_table[pde];
@@ -1105,14 +1108,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
ppgtt->base.start = 0;
- ppgtt->base.total = 1ULL << 32;
- if (IS_ENABLED(CONFIG_X86_32))
- /* While we have a proliferation of size_t variables
-* we cannot represent the full ppgtt size on 32bit,
-* so limit it to the same size as the GGTT (currently
-* 2GiB).
-*/
- ppgtt->base.total = to_i915(ppgtt->base.dev)->gtt.base.total;
ppgtt->base.cleanup = gen8_ppgtt_cleanup;
ppgtt->base.allocate_va_range = gen8_alloc_va_range;
ppgtt->base.insert_entries = gen8_ppgtt_insert_entries;
@@ -1122,10 +1117,25 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt->switch_mm = gen8_mm_switch;
- ret = __pdp_init(false, &ppgtt->pdp);
+ if (!USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
+ ret = __pdp_init(false, &ppgtt->pdp);
- if (ret)
+ if (ret)
+ goto free_scratch;
+
+ ppgtt->base.total = 1ULL << 32;
+ if (IS_ENABLED(CONFIG_X86_32))
+ /* While we have a proliferation of size_t variables
+* we cannot represent the full ppgtt size on 32bit,
+* so limit it to the same size as the GGTT (currently
+* 2GiB).
+*/
+ ppgtt->base.total =
to_i915(ppgtt->base.dev)->gtt.base.total;
+ } else {
+ ppgtt->base.total = 1ULL << 48;
+ ret = -EPERM; /* Not yet implemented */
goto free_scratch;
+ }
return 0;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 87e389c..04bc66f 100644
--- a/drivers/gpu/drm/i915/i915_g
[Intel-gfx] [PATCH v7 07/19] drm/i915/gen8: implement alloc/free for 4lvl
PML4 has no special attributes, and there will always be a PML4.
So simply initialize it at creation, and destroy it at the end.
The code for 4lvl is able to call into the existing 3lvl page table code
to handle all of the lower levels.
v2: Return something at the end of gen8_alloc_va_range_4lvl to keep the
compiler happy. And define ret only in one place.
Updated gen8_ppgtt_unmap_pages and gen8_ppgtt_free to handle 4lvl.
v3: Use i915_dma_unmap_single instead of pci API. Fix a
couple of incorrect checks when unmapping pdp and pd pages (Akash).
v4: Call __pdp_fini also for 32b PPGTT. Clean up alloc_pdp param list.
v5: Prevent (harmless) out of range access in gen8_for_each_pml4e.
v6: Simplify alloc_vma_range_4lvl and gen8_ppgtt_init_common error
paths. (Akash)
v7: Rebase, s/gen8_ppgtt_free_*/gen8_ppgtt_cleanup_*/.
v8: Change location of pml4_init/fini. It will make next patches
cleaner.
v9: Rebase after Mika's ppgtt cleanup / scratch merge patch series, while
trying to reuse as much as possible for pdp alloc. pml4_init/fini
replaced by setup/cleanup_px macros.
v10: Rebase after Mika's merged ppgtt cleanup patch series.
v11: Rebase after final merged version of Mika's ppgtt/scratch
patches.
v12: Fix pdpe start value in trace (Akash)
v13: Define all 4lvl functions in this patch directly, instead of
previous patches, add i915_page_directory_pointer_entry_alloc here,
use test_bit to detect when pdp is already allocated (Akash).
v14: Move pdp allocation into a new gen8_ppgtt_alloc_page_dirpointers
funtion, as we do for pds and pts; move pd and pdp setup functions to
this patch (Akash).
v15: Added kfree(pdp) from previous patch to this (Akash).
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 239 +---
drivers/gpu/drm/i915/i915_gem_gtt.h | 15 ++-
drivers/gpu/drm/i915/i915_trace.h | 8 ++
3 files changed, 246 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3288154..c498eaa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -210,6 +210,9 @@ static gen8_pde_t gen8_pde_encode(const dma_addr_t addr,
return pde;
}
+#define gen8_pdpe_encode gen8_pde_encode
+#define gen8_pml4e_encode gen8_pde_encode
+
static gen6_pte_t snb_pte_encode(dma_addr_t addr,
enum i915_cache_level level,
bool valid, u32 unused)
@@ -559,10 +562,73 @@ static void __pdp_fini(struct i915_page_directory_pointer
*pdp)
pdp->page_directory = NULL;
}
+static struct
+i915_page_directory_pointer *alloc_pdp(struct drm_device *dev)
+{
+ struct i915_page_directory_pointer *pdp;
+ int ret = -ENOMEM;
+
+ WARN_ON(!USES_FULL_48BIT_PPGTT(dev));
+
+ pdp = kzalloc(sizeof(*pdp), GFP_KERNEL);
+ if (!pdp)
+ return ERR_PTR(-ENOMEM);
+
+ ret = __pdp_init(dev, pdp);
+ if (ret)
+ goto fail_bitmap;
+
+ ret = setup_px(dev, pdp);
+ if (ret)
+ goto fail_page_m;
+
+ return pdp;
+
+fail_page_m:
+ __pdp_fini(pdp);
+fail_bitmap:
+ kfree(pdp);
+
+ return ERR_PTR(ret);
+}
+
static void free_pdp(struct drm_device *dev,
struct i915_page_directory_pointer *pdp)
{
__pdp_fini(pdp);
+ if (USES_FULL_48BIT_PPGTT(dev)) {
+ cleanup_px(dev, pdp);
+ kfree(pdp);
+ }
+}
+
+static void
+gen8_setup_page_directory(struct i915_hw_ppgtt *ppgtt,
+ struct i915_page_directory_pointer *pdp,
+ struct i915_page_directory *pd,
+ int index)
+{
+ gen8_ppgtt_pdpe_t *page_directorypo;
+
+ if (!USES_FULL_48BIT_PPGTT(ppgtt->base.dev))
+ return;
+
+ page_directorypo = kmap_px(pdp);
+ page_directorypo[index] = gen8_pdpe_encode(px_dma(pd), I915_CACHE_LLC);
+ kunmap_px(ppgtt, page_directorypo);
+}
+
+static void
+gen8_setup_page_directory_pointer(struct i915_hw_ppgtt *ppgtt,
+ struct i915_pml4 *pml4,
+ struct i915_page_directory_pointer *pdp,
+ int index)
+{
+ gen8_ppgtt_pml4e_t *pagemap = kmap_px(pml4);
+
+ WARN_ON(!USES_FULL_48BIT_PPGTT(ppgtt->base.dev));
+ pagemap[index] = gen8_pml4e_encode(px_dma(pdp), I915_CACHE_LLC);
+ kunmap_px(ppgtt, pagemap);
}
/* Broadwell Page Directory Pointer Descriptors */
@@ -785,12 +851,9 @@ static void gen8_free_scratch(struct i915_address_space
*vm)
free_scratch_page(dev, vm->scratch_page);
}
-static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
+static void gen8_ppgtt_cleanup_3lvl(struct drm_device *dev,
+ struct i915_page_directory_pointer *pdp)
{
- struct i915_hw_ppgtt *ppgtt
[Intel-gfx] [PATCH v7 08/19] drm/i915/gen8: Add 4 level switching infrastructure and lrc support
In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains
the base address to PML4, while the other PDP registers are ignored.
In LRC, the addressing mode must be specified in every context
descriptor, and the base address to PML4 is stored in the reg state.
v2: PML4 update in legacy context switch is left for historic reasons,
the preferred mode of operation is with lrc context based submission.
v3: s/gen8_map_page_directory/gen8_setup_page_directory and
s/gen8_map_page_directory_pointer/gen8_setup_page_directory_pointer.
Also, clflush will be needed for bxt. (Akash)
v4: Squashed lrc-specific code and use a macro to set PML4 register.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
PDP update in bb_start is only for legacy 32b mode.
v6: Rebase after final merged version of Mika's ppgtt/scratch
patches.
v7: There is no need to update the pml4 register value in
execlists_update_context. (Akash)
v8: Move pd and pdp setup functions to a previous patch, they do not
belong here. (Akash)
v9: Check USES_FULL_48BIT_PPGTT instead of GEN8_CTX_ADDRESSING_MODE in
gen8_emit_bb_start to check if emit pdps is needed. (Akash)
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 60 ++---
3 files changed, 55 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c498eaa..ae2e082 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -656,8 +656,8 @@ static int gen8_write_pdp(struct drm_i915_gem_request *req,
return 0;
}
-static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct drm_i915_gem_request *req)
+static int gen8_legacy_mm_switch(struct i915_hw_ppgtt *ppgtt,
+struct drm_i915_gem_request *req)
{
int i, ret;
@@ -672,6 +672,12 @@ static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
return 0;
}
+static int gen8_48b_mm_switch(struct i915_hw_ppgtt *ppgtt,
+ struct drm_i915_gem_request *req)
+{
+ return gen8_write_pdp(req, 0, px_dma(&ppgtt->pml4));
+}
+
static void gen8_ppgtt_clear_pte_range(struct i915_address_space *vm,
struct i915_page_directory_pointer *pdp,
uint64_t start,
@@ -1321,14 +1327,13 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt->base.unbind_vma = ppgtt_unbind_vma;
ppgtt->base.bind_vma = ppgtt_bind_vma;
- ppgtt->switch_mm = gen8_mm_switch;
-
if (USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
ret = setup_px(ppgtt->base.dev, &ppgtt->pml4);
if (ret)
goto free_scratch;
ppgtt->base.total = 1ULL << 48;
+ ppgtt->switch_mm = gen8_48b_mm_switch;
} else {
ret = __pdp_init(false, &ppgtt->pdp);
if (ret)
@@ -1343,6 +1348,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
*/
ppgtt->base.total =
to_i915(ppgtt->base.dev)->gtt.base.total;
+ ppgtt->switch_mm = gen8_legacy_mm_switch;
trace_i915_page_directory_pointer_entry_alloc(&ppgtt->base,
0, 0,
GEN8_PML4E_SHIFT);
@@ -1540,8 +1546,9 @@ static void gen8_ppgtt_enable(struct drm_device *dev)
int j;
for_each_ring(ring, dev_priv, j) {
+ u32 four_level = USES_FULL_48BIT_PPGTT(dev) ?
GEN8_GFX_PPGTT_48B : 0;
I915_WRITE(RING_MODE_GEN7(ring),
- _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE));
+ _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE | four_level));
}
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3a77678..5bd1b6a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1670,6 +1670,7 @@ enum skl_disp_power_wells {
#define GFX_REPLAY_MODE (1<<11)
#define GFX_PSMI_GRANULARITY (1<<10)
#define GFX_PPGTT_ENABLE (1<<9)
+#define GEN8_GFX_PPGTT_48B (1<<7)
#define VLV_DISPLAY_BASE 0x18
#define VLV_MIPI_BASE VLV_DISPLAY_BASE
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 99bba8e..4c40614 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -196,13 +196,21 @@
reg_state[CTX_PDP ## n ## _LDW+1] = lower_32_bits(_addr); \
}
+#define ASSIGN_CTX_PML4(ppgtt, reg_state) { \
+ reg_state[CTX_PDP0_UDW + 1] = upper_32_bits(px_dma(&ppgtt->pml4)); \
+ reg_st
[Intel-gfx] [PATCH v7 18/19] drm/i915/gen8: Flip the 48b switch
Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Note, aliasing PPGTT remains 32b only.
v2: s/full_64b/full_48b/. (Akash)
Cc: Akash Goel
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 9 -
drivers/gpu/drm/i915/i915_params.c | 2 +-
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c792591..31d20c6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -104,12 +104,11 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
{
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
- bool has_full_64bit_ppgtt;
+ bool has_full_48bit_ppgtt;
has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
- has_full_64bit_ppgtt = (IS_BROADWELL(dev) ||
- INTEL_INFO(dev)->gen >= 9) && false; /* FIXME:
64b */
+ has_full_48bit_ppgtt = IS_BROADWELL(dev) || INTEL_INFO(dev)->gen >= 9;
if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
@@ -128,7 +127,7 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
if (enable_ppgtt == 2 && has_full_ppgtt)
return 2;
- if (enable_ppgtt == 3 && has_full_64bit_ppgtt)
+ if (enable_ppgtt == 3 && has_full_48bit_ppgtt)
return 3;
#ifdef CONFIG_INTEL_IOMMU
@@ -147,7 +146,7 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
}
if (INTEL_INFO(dev)->gen >= 8 && i915.enable_execlists)
- return 2;
+ return has_full_48bit_ppgtt ? 3 : 2;
else
return has_aliasing_ppgtt ? 1 : 0;
}
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 5ae4b0a..900e48a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -111,7 +111,7 @@ MODULE_PARM_DESC(enable_hangcheck,
module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
MODULE_PARM_DESC(enable_ppgtt,
"Override PPGTT usage. "
- "(-1=auto [default], 0=disabled, 1=aliasing, 2=full)");
+ "(-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full_48b)");
module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
MODULE_PARM_DESC(enable_execlists,
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: read bpp from vbt only for older panels
On 7/30/2015 3:27 PM, Jani Nikula wrote:
On Thu, 30 Jul 2015, Sivakumar Thulasimani
wrote:
From: "Thulasimani,Sivakumar"
BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and hence should be preferred over any value
programmed in VBT.
Should we actually look at the EDID bpp somewhere?
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..898dc74 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -132,6 +132,7 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp,
bool sync);
static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
static void vlv_steal_power_sequencer(struct drm_device *dev,
enum pipe pipe);
+static struct edid * intel_dp_get_edid(struct intel_dp *intel_dp);
static int
intel_dp_max_link_bw(struct intel_dp *intel_dp)
@@ -1353,6 +1354,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct edid *edid = NULL;
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1409,12 +1411,19 @@ intel_dp_compute_config(struct intel_encoder *encoder,
* bpc in between. */
bpp = pipe_config->pipe_bpp;
if (is_edp(intel_dp)) {
- if (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp) {
+ edid = intel_dp_get_edid(intel_dp);
+
+ /* Get bpp from vbt only for panels with edid 1.3 or older */
+ if (edid && edid->version == 1 && edid->revision <= 3 &&
+ (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp))
{
Now you require the panel to have an EDID in order to use the bpp in
VBT.
BR,
Jani.
will update with a new patch that will remove this expectation.
DRM_DEBUG_KMS("clamping bpp for eDP panel to BIOS-provided
%i\n",
dev_priv->vbt.edp_bpp);
bpp = dev_priv->vbt.edp_bpp;
}
+ if (edid)
+ kfree(edid);
+
/*
* Use the maximum clock and number of lanes the eDP panel
* advertizes being capable of. The panels are generally
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Store max dotclock
On Thu, 2015-07-30 at 08:00 +0100, Chris Wilson wrote:
> On Thu, Jul 30, 2015 at 09:49:28AM +0300, Mika Kahola wrote:
> > Store max dotclock into dev_priv structure so we are able
> > to filter out the modes that are not supported by our
> > platforms.
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_display.c | 20
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 04aa34a..1f69211b 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1777,6 +1777,7 @@ struct drm_i915_private {
> > unsigned int fsb_freq, mem_freq, is_ddr3;
> > unsigned int skl_boot_cdclk;
> > unsigned int cdclk_freq, max_cdclk_freq;
> > + unsigned int max_dotclk;
> > unsigned int hpll_freq;
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 43b0f17..9031261 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5259,6 +5259,24 @@ static void modeset_update_crtc_power_domains(struct
> > drm_atomic_state *state)
> > modeset_put_power_domains(dev_priv, put_domains[i]);
> > }
> >
> > +static int intel_update_max_dotclk(struct drm_device *dev)
>
> You don't update max dotclck, you are computing it. The caller is the
> one storing it dev_priv->max_dotclk (and so is the one actually doing
> the update).
>
True. I'll fix the poor naming of that routine.
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
>
> So why did you pass in dev if we never use it?
>
> > + int max_cdclk_freq = dev_priv->max_cdclk_freq;
> > + int max_dotclk_freq;
> > +
> > + if (IS_BROADWELL(dev) || IS_CHERRYVIEW(dev))
>
> We already have dev_priv, so please stop doing dev->dev_priv over and
> over again.
>
Yeah, that's pretty much unnecessary, so removing this one for the next
series of patches.
> > + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 100, 95);
> > + else if (IS_VALLEYVIEW(dev))
> > + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 100, 90);
> > + else if (IS_GEN2(dev) || IS_GEN3(dev))
>
> If you reverse this pair and do
>
> else if (INTEL_INFO(dev)->gen > 3)
> max_dotclk_freq = max_cdclk_freq;
> else
> max_dotclk_freq = DIV_ROUND_UP(2 * max_cdclk_freq * 100, 90);
>
> Then the chain is mostly ordered in most-recent to oldest, always
> helpful for the next person.
>
I'll apply this change as well on the next patch series.
> Is this correct for gen9+?
This is something I need to double check. My current understanding is
that we should be able to support dot clock up to cd clock frequency
from HSW+ onwards. Actually, I did missed the Ville's comment to limit
dot clock to 90% for older platforms so I need to add this to the next
series as well.
Thanks again for valuable comments.
Cheers,
Mika
> -Chris
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: HDMI pixel clock check
On Thu, 2015-07-30 at 07:54 +0100, Chris Wilson wrote:
> On Thu, Jul 30, 2015 at 09:49:30AM +0300, Mika Kahola wrote:
> > It is possible the we request to have a mode that has
> > higher pixel clock than our HW can support. This patch
> > checks if requested pixel clock is lower than the one
> > supported by the HW. The requested mode is discarded
> > if we cannot support the requested pixel clock.
> >
> > This patch applies to HDMI.
> >
> > V2:
> > - removed computation for max dot clock
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/intel_hdmi.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 70bad5b..b85efaa 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1191,15 +1191,22 @@ intel_hdmi_mode_valid(struct drm_connector
> > *connector,
> > {
> > struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
> > struct drm_device *dev = intel_hdmi_to_dev(hdmi);
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > enum drm_mode_status status;
> > int clock;
> > + int max_pixclk = dev_priv->max_dotclk;
> >
> > if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > return MODE_NO_DBLESCAN;
> >
> > clock = mode->clock;
> > - if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > + if (mode->flags & DRM_MODE_FLAG_DBLCLK) {
> > clock *= 2;
> > + max_pixclk *= 2;
> > + }
> > +
> > + if (clock > max_pixclk)
> > + return MODE_CLOCK_HIGH;
>
> Or do the test before the DBLCLK?
Yes, I could move the test before DBLCLK.
-Mika-
> -Chris
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries for CHV
On 7/30/2015 3:31 PM, Jani Nikula wrote:
On Thu, 30 Jul 2015, Sivakumar Thulasimani
wrote:
From: "Thulasimani,Sivakumar"
CHV does not support intermediate link rates nor does it support
HBR2. This patch removes those entries and returns HBR as the max
link rate supported on CHV platform.
These are two separate changes, and should be two separate
patches. Moreover, the intermediate link rate change should be a revert
of
commit fe51bfb95c996733150c44d21e1c9f4b6322a326
Author: Ville Syrjälä
Date: Thu Mar 12 17:10:38 2015 +0200
drm/i915: Add eDP intermediate frequencies for CHV
with Cc: Ville and Sonika to record this back and forth here.
BR,
Jani.
Sure, will share new patch that will revert the above one and create a
new patch
for restricting CHV to HBR.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 898dc74..5c68b17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
27,
324000, 432000, 54 };
static const int skl_rates[] = { 162000, 216000, 27,
324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
static const int default_rates[] = { 162000, 27, 54 };
/**
@@ -1186,15 +1183,13 @@ intel_dp_source_rates(struct drm_device *dev, const int
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
- } else if (IS_CHERRYVIEW(dev)) {
- *source_rates = chv_rates;
- return ARRAY_SIZE(chv_rates);
}
*source_rates = default_rates;
- if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0)
- /* WaDisableHBR2:skl */
+ /* WaDisableHBR2:skl */
+ if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) ||
+ IS_CHERRYVIEW(dev))
return (DP_LINK_BW_2_7 >> 3) + 1;
else if (INTEL_INFO(dev)->gen >= 8 ||
(IS_HASWELL(dev) && !IS_HSW_ULX(dev)))
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: DSI pixel clock check
On Thu, 2015-07-30 at 07:52 +0100, Chris Wilson wrote:
> On Thu, Jul 30, 2015 at 09:49:33AM +0300, Mika Kahola wrote:
> > It is possible the we request to have a mode that has
> > higher pixel clock than our HW can support. This patch
> > checks if requested pixel clock is lower than the one
> > supported by the HW. The requested mode is discarded
> > if we cannot support the requested pixel clock.
> >
> > This patch applies to DSI.
> >
> > V2:
> > - removed computation for max pixel clock
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/intel_dsi.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 18dd7d7..2882978 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -654,6 +654,11 @@ intel_dsi_mode_valid(struct drm_connector *connector,
> > {
> > struct intel_connector *intel_connector = to_intel_connector(connector);
> > struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
> > + struct intel_encoder *intel_encoder = intel_connector->encoder;
> > + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&intel_encoder->base);
> > + struct drm_device *dev = intel_dsi->base.base.dev;
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > + int max_pixclk = dev_priv->max_dotclk;
>
> You only wanted i915, why all the extra steps?
> int max_pixclk = to_i915(connector->dev)->max_dotclk;
There's really no need for all these steps. All I need to extract is the
max_dotclk and I could do that shorter. This is also applicable for
other patches in the series.
-Mika-
> -Chris
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/atomic: refuse changing CRTC for planes while active
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6889 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 297/297 297/297 SNB 315/315 315/315 IVB 342/342 342/342 BYT 282/282 282/282 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC CABC PATCH v2 3/3] drm/i915: CABC support for backlight control
On 7/24/2015 5:54 PM, Deepak M wrote:
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion here assumes that the
panels use standard SW register for control.
In this design there will be no PWM signal from the SoC and DCS
commands are sent to enable and control the backlight brightness.
v2:
- Created a new backlight driver for cabc, which will be registered
only when it cabc is supported by panel.
(Addressed comment from Daniel Vetter)
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/intel_drv.h |3 +-
drivers/gpu/drm/i915/intel_dsi.c | 13 ++
drivers/gpu/drm/i915/intel_dsi_cabc.c | 349 +
drivers/gpu/drm/i915/intel_dsi_cabc.h | 45 +
drivers/gpu/drm/i915/intel_panel.c| 22 ++-
include/video/mipi_display.h |8 +
7 files changed, 436 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.c
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index de21965..a73953c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -75,6 +75,7 @@ i915-y += dvo_ch7017.o \
intel_dp_mst.o \
intel_dsi.o \
intel_dsi_pll.o \
+ intel_dsi_cabc.o \
intel_dsi_panel_vbt.o \
intel_dvo.o \
intel_hdmi.o \
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3f0a890..9f806dd5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1319,7 +1319,8 @@ extern struct drm_display_mode
*intel_find_panel_downclock(
struct drm_connector *connector);
void intel_backlight_register(struct drm_device *dev);
void intel_backlight_unregister(struct drm_device *dev);
-
+extern int cabc_backlight_device_register(struct intel_connector *connector);
+extern void cabc_backlight_device_unregister(struct intel_connector
*connector);
/* intel_psr.c */
void intel_psr_enable(struct intel_dp *intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 98998e9..8f006f2 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -34,6 +34,7 @@
#include "i915_drv.h"
#include "intel_drv.h"
#include "intel_dsi.h"
+#include "intel_dsi_cabc.h"
static const struct {
u16 panel_id;
@@ -376,6 +377,7 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ struct intel_connector *connector = intel_dsi->attached_connector;
enum port port;
DRM_DEBUG_KMS("\n");
@@ -396,6 +398,9 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
intel_dsi_port_enable(encoder);
}
+
+ if (dev_priv->vbt.dsi.config->cabc_supported)
+ cabc_enable_backlight(connector);
}
static void intel_dsi_pre_enable(struct intel_encoder *encoder)
@@ -469,11 +474,15 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ struct intel_connector *connector = intel_dsi->attached_connector;
enum port port;
u32 temp;
DRM_DEBUG_KMS("\n");
+ if (dev_priv->vbt.dsi.config->cabc_supported)
+ cabc_disable_backlight(connector);
+
if (is_vid_mode(intel_dsi)) {
for_each_dsi_port(port, intel_dsi->ports)
wait_for_dsi_fifo_empty(intel_dsi, port);
@@ -1099,6 +1108,10 @@ void intel_dsi_init(struct drm_device *dev)
intel_panel_init(&intel_connector->panel, fixed_mode, NULL);
+ if (dev_priv->vbt.dsi.config->cabc_supported)
+ cabc_setup_backlight(connector,
+ intel_encoder->crtc_mask ==
+ (1 << PIPE_A) ? PIPE_A : PIPE_B);
return;
err:
diff --git a/drivers/gpu/drm/i915/intel_dsi_cabc.c
b/drivers/gpu/drm/i915/intel_dsi_cabc.c
new file mode 100644
index 000..2a78326
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_cabc.c
@@ -0,0 +1,349 @@
+/*
+ * Copyright © 2006-2010 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without li
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On 30 July 2015 at 15:18, Linus Torvalds wrote:
> On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote:
>>
>> It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9
>
> You didn't catch enough of the code line to decode the code, but it's
> early enough in drm_crtc_index() (just five bytes in) that it's almost
> certainly the very first dereference, so it's almost guaranteed to be
> that
>
>crtc->dev
>
> access as part of list_for_each_entry(), with crtc being NULL. And
> yes, "->dev" is the very first field, so the offset is zero too (while
> the "->mode_config" list access would not be at offset zero).
>
> And it looks like it is called from drm_atomic_helper_check_modeset():
> the reason it has a question mark in the backtrace is because the
> fault happens before the stack frame has even been set up.
>
> There are multiple calls to "drm_crtc_index()" from that function, I
> can't tell which one it is. Looking at the code generation I get, I
> think it's because update_connector_routing() gets inlined, and that
> one does several calls. Most of them look like this:
>
> if (connector->state->crtc) {
> idx = drm_crtc_index(connector->state->crtc);
>
> ie they check that the crtc is non-NULL, but that last one does not:
>
> connector_state->best_encoder = new_encoder;
> idx = drm_crtc_index(connector_state->crtc);
>
> crtc_state = state->crtc_states[idx];
> crtc_state->mode_changed = true;
>
> and I suspect the fix might be something like the attached. Totally
> untested. Ted?
>
> This whole "atomic modeset" series has been one royal fuck-up, guys.
> We've had too many of these kinds of crap issues.
It hasn't been that bad, on a scale of 1 to MD eats my raid array, I'd
say we are barely at a 5.
There have been a lot of small and seemingly easily fixed teething
problems, essentially rewriting the DRM API to provide a new userspace
API and internal interface, porting some drivers partly to the new
interface, while trying to maintain the old ABI/API on top seamlessly
was always going to be an impossible task. It was never going to
magically all just work in -next and land in your tree fully formed
smelling of lavender and elderberries. This is a massive undertaking,
and doing it over a few kernels was the only possible way it could
ever land.
I think the biggest problem we've had is the QA team at Intel got
reorganised or something right when they really needed to be doing
testing on this stuff, so what was sitting in -next never got as much
testing as it had previously, and you can see that in the types of
cases that are getting through. I think the other thing we can learn
is that when Android forks the kernel we should just say this shit is
too hard, let Google go and create a new API and a complete set of
graphics drivers and deal with it in 10 years, because that was
seriously the only other option.
So yes it's a pity other kernel developers are seeing our fallout, but
I've experienced lots of other kernel developers fall out over the
years, and generally the idea is to get this stuff fixed to a
reasonable state before you release a final kernel.
Note I'm not personally involved in the development for atomic
modesetting at all, I'm running the kernels with it where and when I
can, and I trust the developers who work on it are doing as much as
they can to make it work.
That said hopefully Daniel can find a bag of fucks to debug and write
a proper patch, instead of rage quitting the universe, and just git
reset --hard v4.0 drivers/gpu/drm/i915..
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Paper over locking WARN in default_state_clear
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6888 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 297/297 296/297 SNB 315/315 315/315 IVB 342/342 342/342 BYT 282/282 282/282 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@rcs-wf_vblank-vs-dpms-interruptible PASS(1) DMESG_WARN(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/19] 48-bit PPGTT
On Wed, Jul 29, 2015 at 05:23:44PM +0100, Michel Thierry wrote: > This clean-up version delays the 48-bit work to later patches and includes > more review comments from Akash and Chris. The first 5 patches prepare the > dynamic page allocation code to handle independent pdps, but no specific > code for 48-bit mode is added before the 5th patch. > > In order expand the GPU address space, a 4th level translation is added, > the Page Map Level 4 (PML4). This PML4 has 512 PML4 Entries (PML4E), > PML4[0-511], each pointing to a PDP. All the existing "dynamic alloc > ppgtt" functions are used, only adding the 4th level changes. I also > updated some remaining variables that were 32b only. > > There are 2 hardware workarounds needed to allow correct operation with > 48b addresses (Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset). > A flag (EXEC_OBJECT_SUPPORTS_48B_ADDRESS) will indicate if a given object can > be allocated outside the first 4 PDPs; if not, the end range is forced to 4GB. > Also, more objects now use the DRM_MM_CREATE_TOP flag. To maintain > compatibility, in libdrm I added a new drm_intel_bo_emit_reloc_48bit function > that will flag these objects, while the existing drm_intel_bo_emit_reloc > clears it. > > Finally, this feature is only available in BDW and Gen9, requires LRC > submission mode (execlists) and it can be detected by i915.enable_ppgtt=3. > > Also note that this expanded address space is only available for full > PPGTT, aliasing PPGTT and Global GTT remain 32-bit. > > I'll resend the userland patches (libdrm/mesa) in a different patchset, there > haven't been changes on them, but they require a rebase. I will also expand > the > ppgtt igt test per Chris suggestions. Just a head's up, I haven't root caused this yet, but with i915.enable_ppgtt=2 I started getting GPU hangs that didn't happen before this series... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Add sync framework support to execbuff IOCTL
On 29/07/2015 22:19, Jesse Barnes wrote: On 07/07/2015 02:15 AM, Tvrtko Ursulin wrote: On 07/06/2015 01:58 PM, John Harrison wrote: On 06/07/2015 10:29, Daniel Vetter wrote: On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote: On 07/02/2015 04:55 PM, Chris Wilson wrote: It would be nice if we could reuse one seqno both for internal/external fences. If you need to expose a fence ordering within a timeline that is based on the creation stamp rather than execution stamp, it seems like we could just add such a stamp when creating the sync_pt and not worry about its relationship to the execution seqno. Doing so does expose that requests are reordered to userspace since the signalling timeline is not the same as userspace's ordered timeline. Not sure if that is a problem or not. Afaict the sync uapi is based on waiting for all of a set of fences to retire. It doesn't seem to rely on fence ordering (that is knowing that fence A will signal before fence B so it need only wait on fence B). Here's hoping that we can have both simplicity and efficiency... Jumping in with not even perfect understanding of everything here - but timeline business has always been confusing me. There is nothing in the uapi which needs it afaics and iirc there was some discussion at the time Jesse floated his patches that it can be removed. Based on that when I squashed his patches and ported them on top of John's request to fence conversion it ended up something like the below (manually edited a bit to be less noisy and some prep patches omitted): This implements the ioctl based uapi and indeed seqnos are not actually used in waits. So is this insufficient for some reason? (Other that it does not implement the input fence side of things.) Yeah android syncpt on top of struct fence embedded int i915 request is what I'd have expected. The thing I'm not happy with in that plan is that it leaves the kernel driver at the mercy of user land applications. If we return a fence object to user land via a file descriptor (or indeed any other mechanism) then that fence object must be locked until user land closes the file. If the fence object is the one embedded within our request structure then that means user land is effectively locking our request structure. Given that more and more stuff is being attached to the request, that could be a fair bit of memory tied up that we can do nothing about. E.g. if a rogue/buggy application requests a fence be returned for every batch buffer submitted but never closes them. Whereas, if we go the route of a separate fence object specifically for user land then they can leak them like a sieve and we won't really care so much. I am starting to agree gradually with this view. Given all the complications, referencing requests for exporting via fds feels quite heavy-weight, with potentially unbound dependencies and more trickiness in the future, even if we agreed on referencing and locking details. Seqnos per context sounds like a significantly more light-weight and decoupled implementation. I think this is the right long term direction as well; conceptually the per-context seqnos make the most sense in light of scheduling, and they let us keep things simple for sync pts as well. Only question is, who is signed up to make it all work? Jesse That's the version I had originally. A separate fence object using a per context per ring timeline that is safe to export to user land. However, Daniel Vetter was very strongly convinced that using a single shared fence object both internally and externally was the better solution. My current implementation has a per context per ring timeline which is used to give the fence a definitely in order and sensible seqno. It is just not the same seqno that goes through the hardware. At least, not yet! Although that change could be quite significant. John. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/19] 48-bit PPGTT
On 7/30/2015 12:26 PM, Chris Wilson wrote: On Wed, Jul 29, 2015 at 05:23:44PM +0100, Michel Thierry wrote: This clean-up version delays the 48-bit work to later patches and includes more review comments from Akash and Chris. The first 5 patches prepare the dynamic page allocation code to handle independent pdps, but no specific code for 48-bit mode is added before the 5th patch. In order expand the GPU address space, a 4th level translation is added, the Page Map Level 4 (PML4). This PML4 has 512 PML4 Entries (PML4E), PML4[0-511], each pointing to a PDP. All the existing "dynamic alloc ppgtt" functions are used, only adding the 4th level changes. I also updated some remaining variables that were 32b only. There are 2 hardware workarounds needed to allow correct operation with 48b addresses (Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset). A flag (EXEC_OBJECT_SUPPORTS_48B_ADDRESS) will indicate if a given object can be allocated outside the first 4 PDPs; if not, the end range is forced to 4GB. Also, more objects now use the DRM_MM_CREATE_TOP flag. To maintain compatibility, in libdrm I added a new drm_intel_bo_emit_reloc_48bit function that will flag these objects, while the existing drm_intel_bo_emit_reloc clears it. Finally, this feature is only available in BDW and Gen9, requires LRC submission mode (execlists) and it can be detected by i915.enable_ppgtt=3. Also note that this expanded address space is only available for full PPGTT, aliasing PPGTT and Global GTT remain 32-bit. I'll resend the userland patches (libdrm/mesa) in a different patchset, there haven't been changes on them, but they require a rebase. I will also expand the ppgtt igt test per Chris suggestions. Just a head's up, I haven't root caused this yet, but with i915.enable_ppgtt=2 I started getting GPU hangs that didn't happen before this series... -Chris Sounds like I screwed up something in the first 4 patches or in the Wa32bit one. The rest of the changes are contained to 48-bit code. Have you find a way to reproduce it? Thanks, -Michel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/19] 48-bit PPGTT
On Thu, Jul 30, 2015 at 12:52:19PM +0100, Michel Thierry wrote: > On 7/30/2015 12:26 PM, Chris Wilson wrote: > >Just a head's up, I haven't root caused this yet, but with > >i915.enable_ppgtt=2 I started getting GPU hangs that didn't happen > >before this series... > > Sounds like I screwed up something in the first 4 patches or in the > Wa32bit one. The rest of the changes are contained to 48-bit code. It's also likely to be bdw specific since I've been running the same kernel on snb/ivb/hsw without issue. I just thought I would do a quick compare of pggtt=3 against pggtt=2 when the problems started. > Have you find a way to reproduce it? It was in the middle of the ue4 Reflections demo, though it had run through a sample of other tests seemingly without issue. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/12] drm/i915: Only update mode related state if a modeset happened.
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> The rest will be a noop anyway, since without modeset there will be
> no updated dplls and no modeset state to update.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 30 +++---
> 1 file changed, 7 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 23175ce6583d..280629911d41 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12181,33 +12181,15 @@ fail:
> return ret;
> }
>
> -static bool intel_crtc_in_use(struct drm_crtc *crtc)
> -{
> - struct drm_encoder *encoder;
> - struct drm_device *dev = crtc->dev;
> -
> - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head)
> - if (encoder->crtc == crtc)
> - return true;
> -
> - return false;
> -}
> -
> static void
> -intel_modeset_update_state(struct drm_atomic_state *state)
> +intel_modeset_update_crtc_state(struct drm_atomic_state *state)
> {
> struct drm_crtc *crtc;
> struct drm_crtc_state *crtc_state;
> int i;
>
> - intel_shared_dpll_commit(state);
> -
> - drm_atomic_helper_update_legacy_modeset_state(state->dev, state);
> -
> /* Double check state. */
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - WARN_ON(crtc->state->enable != intel_crtc_in_use(crtc));
> -
> to_intel_crtc(crtc)->config = to_intel_crtc_state(crtc->state);
>
> /* Update hwmode for vblank functions */
> @@ -13109,12 +13091,14 @@ static int intel_atomic_commit(struct drm_device
> *dev,
>
> /* Only after disabling all output pipelines that will be changed can we
>* update the the output configuration. */
> - intel_modeset_update_state(state);
> + intel_modeset_update_crtc_state(state);
>
> - /* The state has been swaped above, so state actually contains the
> - * old state now. */
> - if (any_ms)
> + if (any_ms) {
> + intel_shared_dpll_commit(state);
> +
> + drm_atomic_helper_update_legacy_modeset_state(state->dev,
> state);
> modeset_update_crtc_power_domains(state);
> + }
>
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2.1 2.5/12] drm/i915: Validate the state after an atomic modeset, only, and pass the state.
First step in removing dpms and validating atomic state.
There can still be a mismatch in the connector state because the dpms
callbacks are still used, but this can not happen immediately after a modeset.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_crt.c | 2 --
drivers/gpu/drm/i915/intel_display.c | 12 ++--
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_dvo.c | 2 --
drivers/gpu/drm/i915/intel_sdvo.c| 2 --
5 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 5d78c1feec81..9eba3dd5b434 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -280,8 +280,6 @@ static int intel_crt_dpms(struct drm_connector *connector,
int mode)
intel_crtc_update_dpms(crtc);
}
- intel_modeset_check_state(connector->dev);
-
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dfe4407b0390..77b4da7e698c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6440,8 +6440,6 @@ int intel_connector_dpms(struct drm_connector *connector,
int mode)
if (connector->encoder)
intel_encoder_dpms(to_intel_encoder(connector->encoder), mode);
- intel_modeset_check_state(connector->dev);
-
return 0;
}
@@ -12900,8 +12898,9 @@ check_shared_dpll_state(struct drm_device *dev)
}
}
-void
-intel_modeset_check_state(struct drm_device *dev)
+static void
+intel_modeset_check_state(struct drm_device *dev,
+ struct drm_atomic_state *old_state)
{
check_wm_state(dev);
check_connector_state(dev);
@@ -13290,10 +13289,11 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_helper_wait_for_vblanks(dev, state);
drm_atomic_helper_cleanup_planes(dev, state);
- drm_atomic_state_free(state);
if (any_ms)
- intel_modeset_check_state(dev);
+ intel_modeset_check_state(dev, state);
+
+ drm_atomic_state_free(state);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6bd848..0da4236dc85a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -999,7 +999,6 @@ int intel_connector_init(struct intel_connector *);
struct intel_connector *intel_connector_alloc(void);
int intel_connector_dpms(struct drm_connector *, int mode);
bool intel_connector_get_hw_state(struct intel_connector *connector);
-void intel_modeset_check_state(struct drm_device *dev);
bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
struct intel_digital_port *port);
void intel_connector_attach_encoder(struct intel_connector *connector,
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index fd5e522abebb..600f7fb855d8 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -237,8 +237,6 @@ static int intel_dvo_dpms(struct drm_connector *connector,
int mode)
intel_crtc_update_dpms(crtc);
}
- intel_modeset_check_state(connector->dev);
-
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 2c435a79d4da..8911e0e417ee 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1550,8 +1550,6 @@ static int intel_sdvo_dpms(struct drm_connector
*connector, int mode)
intel_sdvo_set_active_outputs(intel_sdvo,
intel_sdvo->attached_output);
}
- intel_modeset_check_state(connector->dev);
-
return 0;
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2.1 03/12] drm/i915: Convert connector checking to atomic, v2.
Right now dpms callbacks can still fiddle with the connector state,
but it can only turn connectors off.
This is remediated by only checking crtc->state->active when the
connector is active, and ignore crtc->state->active when the
connector is off.
connectors_active is no longer checked, and will be removed later
in this series together with dpms.
Another check for !encoder->crtc is performed by check_encoder_state
too, so it can be removed.
Changes since v1:
- Add commit message.
- rename state to old_state.
- Move deletion of mst_port check to mst patch.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 66 +---
1 file changed, 32 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 77b4da7e698c..876071ad4681 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6360,38 +6360,33 @@ static void intel_encoder_dpms(struct intel_encoder
*encoder, int mode)
* internal consistency). */
static void intel_connector_check_state(struct intel_connector *connector)
{
- if (connector->get_hw_state(connector)) {
- struct intel_encoder *encoder = connector->encoder;
- struct drm_crtc *crtc;
- bool encoder_enabled;
- enum pipe pipe;
+ struct drm_crtc *crtc = connector->base.state->crtc;
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
- connector->base.base.id,
- connector->base.name);
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
+ connector->base.base.id,
+ connector->base.name);
- I915_STATE_WARN(connector->base.dpms == DRM_MODE_DPMS_OFF,
-"wrong connector dpms state\n");
- I915_STATE_WARN(connector->base.encoder != &encoder->base,
-"active connector not linked to encoder\n");
+ if (connector->get_hw_state(connector)) {
+ struct drm_encoder *encoder = &connector->encoder->base;
+ struct drm_connector_state *conn_state = connector->base.state;
- if (encoder) {
- I915_STATE_WARN(!encoder->connectors_active,
-"encoder->connectors_active not set\n");
+ I915_STATE_WARN(!crtc,
+"connector enabled without attached crtc\n");
- encoder_enabled = encoder->get_hw_state(encoder, &pipe);
- I915_STATE_WARN(!encoder_enabled, "encoder not
enabled\n");
- if (I915_STATE_WARN_ON(!encoder->base.crtc))
- return;
+ if (!crtc)
+ return;
- crtc = encoder->base.crtc;
+ I915_STATE_WARN(!crtc->state->active,
+ "connector is active, but attached crtc isn't\n");
- I915_STATE_WARN(!crtc->state->enable,
- "crtc not enabled\n");
- I915_STATE_WARN(!to_intel_crtc(crtc)->active, "crtc not
active\n");
- I915_STATE_WARN(pipe != to_intel_crtc(crtc)->pipe,
-"encoder active on the wrong pipe\n");
- }
+ I915_STATE_WARN(conn_state->best_encoder != encoder,
+ "atomic encoder doesn't match attached encoder\n");
+
+ I915_STATE_WARN(conn_state->crtc != encoder->crtc,
+ "attached encoder crtc differs from connector crtc\n");
+ } else {
+ I915_STATE_WARN(!crtc && connector->base.state->best_encoder,
+ "best encoder set without crtc!\n");
}
}
@@ -12699,20 +12694,23 @@ static void check_wm_state(struct drm_device *dev)
}
static void
-check_connector_state(struct drm_device *dev)
+check_connector_state(struct drm_device *dev,
+ struct drm_atomic_state *old_state)
{
- struct intel_connector *connector;
+ struct drm_connector_state *old_conn_state;
+ struct drm_connector *connector;
+ int i;
- for_each_intel_connector(dev, connector) {
- struct drm_encoder *encoder = connector->base.encoder;
- struct drm_connector_state *state = connector->base.state;
+ for_each_connector_in_state(old_state, connector, old_conn_state, i) {
+ struct drm_encoder *encoder = connector->encoder;
+ struct drm_connector_state *state = connector->state;
/* This also checks the encoder/connector hw state with the
* ->get_hw_state callbacks. */
- intel_connector_check_state(connector);
+ intel_connector_check_state(to_intel_connector(connector));
I915_STATE_WARN(state->best_encoder != en
[Intel-gfx] [PATCH v2.1 06/12] drm/i915: Make crtc checking use the atomic state, v2.
Instead of allocating pipe_config on the stack use the old
crtc_state, it's only going to freed from this point on.
All crtc' are now only checked once during modeset,
because false positives can happen with encoders after
dpms changes and to limit the amount of errors for 1 failure.
Changes since v1:
- crtc_state -> old_crtc_state
- state -> old_state
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 118 +--
1 file changed, 56 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 129931f3013e..4babecd1c99f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11829,7 +11829,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
struct drm_atomic_state *state = crtc_state->state;
- int ret, idx = crtc->base.id;
+ int ret;
bool mode_changed = needs_modeset(crtc_state);
if (mode_changed && !check_encoder_cloning(state, intel_crtc)) {
@@ -11837,10 +11837,6 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
return -EINVAL;
}
- I915_STATE_WARN(crtc->state->active != intel_crtc->active,
- "[CRTC:%i] mismatch between state->active(%i) and
crtc->active(%i)\n",
- idx, crtc->state->active, intel_crtc->active);
-
if (mode_changed && !crtc_state->active)
intel_crtc->atomic.update_wm_post = true;
@@ -12722,19 +12718,16 @@ check_encoder_state(struct drm_device *dev)
for_each_intel_encoder(dev, encoder) {
bool enabled = false;
- bool active = false;
- enum pipe pipe, tracked_pipe;
+ enum pipe pipe;
DRM_DEBUG_KMS("[ENCODER:%d:%s]\n",
encoder->base.base.id,
encoder->base.name);
for_each_intel_connector(dev, connector) {
- if (connector->base.encoder != &encoder->base)
+ if (connector->base.state->best_encoder !=
&encoder->base)
continue;
enabled = true;
- if (connector->base.dpms != DRM_MODE_DPMS_OFF)
- active = true;
I915_STATE_WARN(connector->base.state->crtc !=
encoder->base.crtc,
@@ -12745,85 +12738,86 @@ check_encoder_state(struct drm_device *dev)
"encoder's enabled state mismatch "
"(expected %i, found %i)\n",
!!encoder->base.crtc, enabled);
- I915_STATE_WARN(active && !encoder->base.crtc,
-"active encoder with no crtc\n");
-
- active = encoder->get_hw_state(encoder, &pipe);
if (!encoder->base.crtc) {
- I915_STATE_WARN(active,
-"encoder detached but not turned off.\n");
+ bool active;
- continue;
+ active = encoder->get_hw_state(encoder, &pipe);
+ I915_STATE_WARN(active,
+"encoder detached but still enabled on pipe %c.\n",
+pipe_name(pipe));
}
-
- I915_STATE_WARN(active != encoder->base.crtc->state->active,
-"encoder's hw state doesn't match sw tracking "
-"(expected %i, found %i)\n",
-encoder->base.crtc->state->active, active);
-
-
- tracked_pipe = to_intel_crtc(encoder->base.crtc)->pipe;
- I915_STATE_WARN(active && pipe != tracked_pipe,
-"active encoder's pipe doesn't match"
-"(expected %i, found %i)\n",
-tracked_pipe, pipe);
-
}
}
static void
-check_crtc_state(struct drm_device *dev)
+check_crtc_state(struct drm_device *dev, struct drm_atomic_state *old_state)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *crtc;
struct intel_encoder *encoder;
- struct intel_crtc_state pipe_config;
+ struct drm_crtc_state *old_crtc_state;
+ struct drm_crtc *crtc;
+ int i;
- for_each_intel_crtc(dev, crtc) {
+ for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *pipe_config, *sw_config;
bool active;
- memset(&pipe_config, 0, sizeof(pipe_config));
+ if (!needs_modeset(crtc->state))
+ continue;
- DRM_DEBUG_KMS("[
[Intel-gfx] [PATCH v2.1 08/12] drm/i915: Remove connectors_active from sanitization, v2.
connectors_active will be removed, so just calculate this instead.
Changes since v1:
- Look for the right pointer in intel_sanitize_encoder.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_display.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4837d14a5f8e..ff0a22f223e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14936,8 +14936,10 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
enable = false;
- for_each_encoder_on_crtc(dev, &crtc->base, encoder)
- enable |= encoder->connectors_active;
+ for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
+ enable = true;
+ break;
+ }
if (!enable)
intel_crtc_disable_noatomic(&crtc->base);
@@ -14993,6 +14995,7 @@ static void intel_sanitize_encoder(struct intel_encoder
*encoder)
{
struct intel_connector *connector;
struct drm_device *dev = encoder->base.dev;
+ bool active = false;
/* We need to check both for a crtc link (meaning that the
* encoder is active and trying to read from a pipe) and the
@@ -15000,7 +15003,15 @@ static void intel_sanitize_encoder(struct
intel_encoder *encoder)
bool has_active_crtc = encoder->base.crtc &&
to_intel_crtc(encoder->base.crtc)->active;
- if (encoder->connectors_active && !has_active_crtc) {
+ for_each_intel_connector(dev, connector) {
+ if (connector->base.encoder != &encoder->base)
+ continue;
+
+ active = true;
+ break;
+ }
+
+ if (active && !has_active_crtc) {
DRM_DEBUG_KMS("[ENCODER:%d:%s] has active connectors but no
active pipe!\n",
encoder->base.base.id,
encoder->base.name);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2.1 09/12] drm/i915: Remove connectors_active from intel_dp.c, v2.
Now that everything's atomic, checking encoder->base.crtc is enough.
This function doesn't have the locks to dereference crtc->state, but
stealing an encoder bound to any crtc is probably enough reason to warn.
Changes since v1:
- Commit message.
Cc: Ville Syrjälä
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3c243dee72c2..da347a8996a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2624,7 +2624,7 @@ static void vlv_steal_power_sequencer(struct drm_device
*dev,
DRM_DEBUG_KMS("stealing pipe %c power sequencer from port %c\n",
pipe_name(pipe), port_name(port));
- WARN(encoder->connectors_active,
+ WARN(encoder->base.crtc,
"stealing pipe %c power sequencer from active eDP port
%c\n",
pipe_name(pipe), port_name(port));
@@ -4241,10 +4241,7 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
- if (!intel_encoder->connectors_active)
- return;
-
- if (WARN_ON(!intel_encoder->base.crtc))
+ if (!intel_encoder->base.crtc)
return;
if (!to_intel_crtc(intel_encoder->base.crtc)->active)
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm: Add config for detecting libdrm
On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote: > On 01 Jul 2015 14:52, Patrik Jakobsson wrote: > > Use pkg-config to try to find libdrm. If that fails use the standard > > include directory for kernel drm headers in /usr/include/drm. > > > > * configure.ac: Use pkg-config to find libdrm > > > > Signed-off-by: Patrik Jakobsson > > --- > > configure.ac | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/configure.ac b/configure.ac > > index bb8bf46..aa63af7 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -844,6 +844,10 @@ fi > > AM_CONDITIONAL([USE_LIBUNWIND], [test "x$use_libunwind" = xyes]) > > AC_MSG_RESULT([$use_libunwind]) > > > > +PKG_CHECK_MODULES([libdrm], [libdrm], > > + [CPPFLAGS="$CPPFLAGS $libdrm_CFLAGS"], > > + [CPPFLAGS="$CPPFLAGS -I/usr/include/drm"]) > > yikes, no, this is a really really bad idea. it should read: > PKG_CHECK_MODULES([LIBDRM], [libdrm], > [CPPFLAGS="$CPPFLAGS $LIBDRM_CFLAGS"], [:]) > -mike Hi Mike Please include me in CC. I take it you don't want me to fallback on kernel headers and skip compiling with drm support if libdrm is not available? Cheers Patrik ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm: Add config for detecting libdrm
On 30 Jul 2015 15:30, Patrik Jakobsson wrote: > On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote: > > On 01 Jul 2015 14:52, Patrik Jakobsson wrote: > > > Use pkg-config to try to find libdrm. If that fails use the standard > > > include directory for kernel drm headers in /usr/include/drm. > > > > > > * configure.ac: Use pkg-config to find libdrm > > > > > > Signed-off-by: Patrik Jakobsson > > > --- > > > configure.ac | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/configure.ac b/configure.ac > > > index bb8bf46..aa63af7 100644 > > > --- a/configure.ac > > > +++ b/configure.ac > > > @@ -844,6 +844,10 @@ fi > > > AM_CONDITIONAL([USE_LIBUNWIND], [test "x$use_libunwind" = xyes]) > > > AC_MSG_RESULT([$use_libunwind]) > > > > > > +PKG_CHECK_MODULES([libdrm], [libdrm], > > > + [CPPFLAGS="$CPPFLAGS $libdrm_CFLAGS"], > > > + [CPPFLAGS="$CPPFLAGS -I/usr/include/drm"]) > > > > yikes, no, this is a really really bad idea. it should read: > > PKG_CHECK_MODULES([LIBDRM], [libdrm], > > [CPPFLAGS="$CPPFLAGS $LIBDRM_CFLAGS"], [:]) > > I take it you don't want me to fallback on kernel headers and skip > compiling with drm support if libdrm is not available? you cannot hardcode any path at all. if the kernel headers provide all of the defines/structs that you need, then just include them directly via #include . -mike signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5b59d5ad7d1c..aac212297b49 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state
> *state, int conn_idx)
> }
>
> connector_state->best_encoder = new_encoder;
> - idx = drm_crtc_index(connector_state->crtc);
> + if (connector_state->crtc) {
> + idx = drm_crtc_index(connector_state->crtc);
>
> - crtc_state = state->crtc_states[idx];
> - crtc_state->mode_changed = true;
> + crtc_state = state->crtc_states[idx];
> + crtc_state->mode_changed = true;
> + }
This shouldn't happen since if it does we ended up stealing the encoder
from the connector itself (we do check for connector_state->crtc earlier)
and that would be a bug. I haven't figured out a precise theory but my
guess is on the best_encoder selection, and indeed dp mst encoder
selection seems to have gone belly up in 4.2 with the bisected commit.
I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
but I couldn't test them yet since no dp mst here and I didn't find
anything that would ship faster than 1-2 weeks yet. I'll try to get some
other people here to test it meanwhile too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP
On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
>
>
> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
> >>identify both lane count and reversal state without touching anything in the
> >>link training code. i am yet to upstream my changes for CHT that i can share
> >>if required that does the same in intel_dp_detect without touching any line
> >>in link training path.
> >With my current limited knowledge of the dp hotplug (and i915 driver) I
> >am not sure we could detect the reversed state without trying to train 1
> >lane only. I'd be glad to look at your changes and test them on my
> >system if you think that could help having a cleaner solution.
> >
> >Cheers,
> >Benjamin
> No, what i recommended was to do link training but in intel_dp_detect. Since
> USB Type C cable
> also has its own lane count restriction (it can have different lane count
> than the one supported
> by panel) you might have to figure that out as well. so both reversal and
> lane count detection
> can be done outside the modeset path and keep the code free of type C
> changes outside
> detection path.
Thanks for the detailed explanations. Now I see what you mean and
definitively understand why this is better.
>
> Please find below the code to do the same. Do not waste time trying to apply
> this directly on
> nightly since this is based on a local tree and because this is pre- atomic
> changes code, so you
> might have to modify chv_upfront_link_train to work on top of the latest
> nightly code. we
> are supposed to upstream this and is in my todo list.
Thanks for this patch. I'll try to adapt it to test on the Broadwell
laptop I have and get the reversed state detected here.
Cheers,
Benjamin
>
> ---
>
> Author: Durgadoss R
> Date: Fri May 22 14:30:07 2015 +0530
>
>drm/i915: Enable Upfront link training for type-C DP support
>
> To support USB type C alternate DP mode, the display driver needs to
> know the
> number of lanes required by DP panel as well as number of lanes that can
> be
> supported by the type-C cable. Sometimes, the type-C cable may limit the
> bandwidth even if Panel can support more lanes. To address these
> scenarios,
> the display driver will start link training with max lanes, and if the
> link
> training fails, the driver then falls back to x2 lanes.
>
> * Since link training is done before modeset, planes are not enabled.
> Only
> encoder and the its associated PLLs are enabled.
> * Once link training is done, the encoder and its PLLs are disabled; so
> that
> the subsequent modeset is not aware of these changes.
> * As of now, this is tested only on CHV.
>
> Signed-off-by: Durgadoss R
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0c8ae2a..c72dcaa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14793,3 +14793,121 @@ intel_display_print_error_state(struct
> drm_i915_error_state_buf *m,
> err_printf(m, " VSYNC: %08x\n", error->transcoder[i].vsync);
> }
> }
> +
> +bool chv_upfront_link_train(struct drm_device *dev,
> +struct intel_dp *intel_dp, struct intel_crtc *crtc)
> +{
> +struct drm_i915_private *dev_priv = dev->dev_private;
> +struct intel_connector *connector = intel_dp->attached_connector;
> +struct intel_encoder *encoder = connector->encoder;
> +bool found = false;
> +bool valid_crtc = false;
> +
> +if (!connector || !encoder) {
> +DRM_DEBUG_KMS("dp connector/encoder is NULL\n");
> +return false;
> +}
> +
> +/* If we already have a crtc, start link training directly */
> +if (crtc) {
> +valid_crtc = true;
> +goto start_link_train;
> +}
> +
> +/* Find an unused crtc and use it for link training */
> +for_each_intel_crtc(dev, crtc) {
> +if (intel_crtc_active(&crtc->base))
> +continue;
> +
> +connector->new_encoder = encoder;
> +encoder->new_crtc = crtc;
> +encoder->base.crtc = &crtc->base;
> +
> +/* Make sure the new crtc will work with the encoder */
> +if (drm_encoder_crtc_ok(&encoder->base,
> + &crtc->base)) {
> +found = true;
> +break;
> +}
> +}
> +
> +if (!found) {
> +DRM_ERROR("Could not find crtc for upfront link training\n");
> +return false;
> +}
> +
> +start_link_train:
> +
> +DRM_DEBUG_KMS("upfront link training on pipe:%c\n",
> +pipe_name(crtc->pipe));
> +found = false;
> +
> +/* Initialize with Max Link rate & lane count supported by panel */
> +intel_dp->link_bw =
Re: [Intel-gfx] [PATCH] drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt
On Wed, Jul 29, 2015 at 08:02:48PM +0100, Chris Wilson wrote:
> If the device does not support the aliasing ppgtt, we must translate
> user bind requests (PIN_USER) from LOCAL_BIND to a GLOBAL_BIND. However,
> since this is device specific we cannot do this conveniently in the
> upper layers and so must manage the vma->bound flags in the backend.
>
> Partial revert of commit 75d04a3773ecee617847de963ae4195d6aa74c28 [4.2-rc1]
> Author: Mika Kuoppala
> Date: Tue Apr 28 17:56:17 2015 +0300
>
> drm/i915/gtt: Allocate va range only if vma is not bound
>
> Note this was spotted by Daniel originally, but we dropped the ball in
> getting the fix in before the bug going wild. Sorry all.
>
> Reported-by: Vincent Legoll vincent.leg...@gmail.com
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91133
> References: https://bugs.freedesktop.org/show_bug.cgi?id=90224
> Signed-off-by: Chris Wilson
> Cc: Michel Thierry
> Cc: Daniel Vetter
> Cc: Mika Kuoppala
> Cc: Jani Nikula
Picked up for -fixes, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 9d3852c521c7..c0d8e1f5b5c2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1928,6 +1928,17 @@ static int ggtt_bind_vma(struct i915_vma *vma,
> vma->vm->insert_entries(vma->vm, pages,
> vma->node.start,
> cache_level, pte_flags);
> +
> + /* Note the inconsistency here is due to absence of the
> + * aliasing ppgtt on gen4 and earlier. Though we always
> + * request PIN_USER for execbuffer (translated to LOCAL_BIND),
> + * without the appgtt, we cannot honour that request and so
> + * must substitute it with a global binding. Since we do this
> + * behind the upper layers back, we need to explicitly set
> + * the bound flag ourselves.
> + */
> + vma->bound |= GLOBAL_BIND;
> +
> }
>
> if (dev_priv->mm.aliasing_ppgtt && flags & LOCAL_BIND) {
> --
> 2.4.6
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Declare the swizzling unknown for L-shaped configurations
On Thu, Jul 30, 2015 at 08:05:07AM +0100, Chris Wilson wrote: > On Sun, Jun 28, 2015 at 09:19:26AM +0100, Chris Wilson wrote: > > The old style of memory interleaving swizzled upto the end of the > > first even bank of memory, and then used the remainder as unswizzled on > > the unpaired bank - i.e. swizzling is not constant for all memory. This > > causes problems when we try to migrate memory and so the kernel prevents > > migration at all when we detect L-shaped inconsistent swizzling. > > However, this issue also extends to userspace who try to manually detile > > into memory as the swizzling for an individual page is unknown (it > > depends on its physical address only known to the kernel), userspace > > cannot correctly swizzle. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105 > > Signed-off-by: Chris Wilson > > Cc: Daniel Vetter > > Cc: sta...@vger.kernel.org > > Daniel since you dropped v2 and had already reviewed this version, it > would have been useful had you done the swap... Simply forgot, sorry. I added a note about the earlier attempt and also one to explain that cc: stable is for fixing up wc mmaps. Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/18] drm/i915/gen9: Removed byte swapping for csr firmware.
memcpy(dmc_payload, &fw->data[readcount], dmc_header->fw_size);
dmc_header->fw_size is wrong.
This will result in 0's after 0x80734 location, results in system hang.
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Animesh Manna
Sent: Sunday, July 26, 2015 12:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vatsala Nagaraju
Subject: [Intel-gfx] [PATCH 18/18] drm/i915/gen9: Removed byte swapping for csr
firmware.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vatsala Nagaraju
---
drivers/gpu/drm/i915/intel_csr.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 1858f02..50779e0 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -328,16 +328,7 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
return NULL;
}
- for (i = 0; i < dmc_header->fw_size; i++) {
- uint32_t *tmp = (u32 *)&fw->data[readcount + i * 4];
- /*
-* The firmware payload is an array of 32 bit words stored in
-* little-endian format in the firmware image and programmed
-* as 32 bit big-endian format to memory.
-*/
- dmc_payload[i] = (uint32_t __force) cpu_to_be32(*tmp);
- }
-
+ memcpy(dmc_payload, &fw->data[readcount], dmc_header->fw_size);
return dmc_payload;
}
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/18] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
Hang is due to patch 18 not mmio access.
-Original Message-
From: Manna, Animesh
Sent: Sunday, July 26, 2015 12:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Manna, Animesh; Lespiau, Damien; Deak, Imre; Kamath, Sunil; Nagaraju,
Vathsala; Bhardwaj, Rajneesh
Subject: [PATCH 15/18] drm/i915/skl: Making DC6 entry is the last call in
suspend flow.
Mmio register access after dc6/dc5 entry is causing the system hang, so
enabling dc6 as the last call in suspend flow.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 19 +++
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ddf8a25..77b35fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -995,6 +995,9 @@ static int i915_pm_resume(struct device *dev)
static int skl_suspend_complete(struct drm_i915_private *dev_priv) {
+ if (dev_priv->csr.dmc_payload)
+ skl_enable_dc6(dev_priv);
+
skl_uninit_cdclk(dev_priv);
return 0;
@@ -1041,6 +1044,9 @@ static int bxt_resume_prepare(struct drm_i915_private
*dev_priv)
static int skl_resume_prepare(struct drm_i915_private *dev_priv) {
+ if (dev_priv->csr.dmc_payload)
+ skl_disable_dc6(dev_priv);
+
skl_init_cdclk(dev_priv);
intel_csr_load_program(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 644286f..0d13f50 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv); void
skl_init_cdclk(struct drm_i915_private *dev_priv); void
skl_uninit_cdclk(struct drm_i915_private *dev_priv);
+void skl_enable_dc6(struct drm_i915_private *dev_priv); void
+skl_disable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config); void
intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n); diff --git
a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index a5059e8..ddae00e 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -540,7 +540,7 @@ static void assert_can_disable_dc6(struct drm_i915_private
*dev_priv)
"DC6 already programmed to be disabled.\n"); }
-static void skl_enable_dc6(struct drm_i915_private *dev_priv)
+void skl_enable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -557,7 +557,7 @@ static void skl_enable_dc6(struct drm_i915_private
*dev_priv)
POSTING_READ(DC_STATE_EN);
}
-static void skl_disable_dc6(struct drm_i915_private *dev_priv)
+void skl_disable_dc6(struct drm_i915_private *dev_priv)
{
uint32_t val;
@@ -618,10 +618,10 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
!I915_READ(HSW_PWR_WELL_BIOS),
"Invalid for power well status to be enabled,
unless done by the BIOS, \
when request is to disable!\n");
- if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
- power_well->data == SKL_DISP_PW_2) {
+ if (power_well->data == SKL_DISP_PW_2) {
+ if (GEN9_ENABLE_DC5(dev))
+ gen9_disable_dc5(dev_priv);
if (SKL_ENABLE_DC6(dev)) {
- skl_disable_dc6(dev_priv);
/*
* DDI buffer programming unnecessary
during driver-load/resume
* as it's already done during modeset
initialization then.
@@ -629,8 +629,6 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
*/
if
(!dev_priv->power_domains.initializing)
intel_prepare_ddi(dev);
- } else {
- gen9_disable_dc5(dev_priv);
}
}
I915_WRITE(HSW_PWR_WELL_DRIVER, tmp | req_mask); @@
-650,12 +648,9 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
POSTING_READ(HSW_PWR_WELL_DRIVER);
DRM_DEBUG_KMS("Disabling %s\n", power_well->name);
- if ((GEN9_E
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 5b59d5ad7d1c..aac212297b49 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state
> > *state, int conn_idx)
> > }
> >
> > connector_state->best_encoder = new_encoder;
> > - idx = drm_crtc_index(connector_state->crtc);
> > + if (connector_state->crtc) {
> > + idx = drm_crtc_index(connector_state->crtc);
> >
> > - crtc_state = state->crtc_states[idx];
> > - crtc_state->mode_changed = true;
> > + crtc_state = state->crtc_states[idx];
> > + crtc_state->mode_changed = true;
> > + }
>
> This shouldn't happen since if it does we ended up stealing the encoder
> from the connector itself (we do check for connector_state->crtc earlier)
> and that would be a bug. I haven't figured out a precise theory but my
> guess is on the best_encoder selection, and indeed dp mst encoder
> selection seems to have gone belly up in 4.2 with the bisected commit.
Well, I just tested Linus's patch and it works.
BTW, is there any chance that I can suspend my laptop, and then move
it from my docking station at home (where I have a Dell 30" display)
to my docking station at work (where I have a Dell 24" display), and
actually have the new monitor be detected? For at least the past
year, I have to reboot in order to be able to use the external
monitor? This used to work, but it's been a very long-standing
regression. I undrstand that Multi-stream DP is a evil horrible hack,
and supporting it is painful, but this used to work, and it hasn't in
a long time. :-(
- Ted
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> but I couldn't test them yet since no dp mst here and I didn't find
> anything that would ship faster than 1-2 weeks yet. I'll try to get some
> other people here to test it meanwhile too.
I've tried pulling in your patches from fixes-stuff, onto Linus's tree
(without Linus's fix), and the good news is that I'm no longer
crashing on boot.
The *bad* news is that (a) it breaks the external monitor attached to
the docking station completely (this was working with Linus's patch),
and (b) it's triggering a LOCKDEP failure.
So even though Linus's patch wasn't supposed to work, I think I'm
going to back to it
- Ted
Jul 30 11:46:49 closure kernel: [4.221951]
Jul 30 11:46:49 closure kernel: [4.221954]
==
Jul 30 11:46:49 closure kernel: [4.221957] [ INFO: possible circular
locking dependency detected ]
Jul 30 11:46:49 closure kernel: [4.221960] 4.2.0-rc4-13906-g5f1b75cd #16
Not tainted
Jul 30 11:46:49 closure kernel: [4.221963]
---
Jul 30 11:46:49 closure kernel: [4.221966] modprobe/503 is trying to
acquire lock:
Jul 30 11:46:49 closure kernel: [4.221968] (init_mutex){+.+.+.}, at:
[] acpi_video_get_backlight_type+0x17/0x164
Jul 30 11:46:49 closure kernel: [4.221977]
Jul 30 11:46:49 closure kernel: [4.221977] but task is already holding lock:
Jul 30 11:46:49 closure kernel: [4.221979]
(&(&backlight_notifier)->rwsem){..}, at: []
__blocking_notifier_call_chain+0x37/0x69
Jul 30 11:46:49 closure kernel: [4.221987]
Jul 30 11:46:49 closure kernel: [4.221987] which lock already depends on
the new lock.
Jul 30 11:46:49 closure kernel: [4.221987]
Jul 30 11:46:49 closure kernel: [4.221990]
Jul 30 11:46:49 closure kernel: [4.221990] the existing dependency chain
(in reverse order) is:
Jul 30 11:46:49 closure kernel: [4.221995]
Jul 30 11:46:49 closure kernel: [4.221995] -> #1
(&(&backlight_notifier)->rwsem){..}:
Jul 30 11:46:49 closure kernel: [4.222001][]
lock_acquire+0x104/0x18b
Jul 30 11:46:49 closure kernel: [4.222007][]
down_write+0x46/0x8a
Jul 30 11:46:49 closure kernel: [4.222012][]
blocking_notifier_chain_register+0x36/0x57
Jul 30 11:46:49 closure kernel: [4.222017][]
backlight_register_notifier+0x18/0x1a
Jul 30 11:46:49 closure kernel: [4.222022][]
acpi_video_get_backlight_type+0xfa/0x164
Jul 30 11:46:49 closure kernel: [4.222028][]
0xc03a1e45
Jul 30 11:46:49 closure audispd: No plugins found, exiting
Jul 30 11:46:49 closure kernel: [4.222032][]
0xc03a28a8
Jul 30 11:46:49 closure kernel: [4.222036][]
do_one_initcall+0x19a/0x1af
Jul 30 11:46:49 closure kernel: [4.222042][]
do_init_module+0x60/0x1e3
Jul 30 11:46:49 closure kernel: [4.222047][]
load_module+0x1c42/0x2059
Jul 30 11:46:49 closure kernel: [4.222052][]
SyS_finit_module+0x85/0x92
Jul 30 11:46:49 closure kernel: [4.222056][]
entry_SYSCALL_64_fastpath+0x16/0x73
Jul 30 11:46:49 closure kernel: [4.222060]
Jul 30 11:46:49 closure kernel: [4.222060] -> #0 (init_mutex){+.+.+.}:
Jul 30 11:46:49 closure kernel: [4.222065][]
__lock_acquire+0xc55/0xf54
Jul 30 11:46:49 closure kernel: [4.222070][]
lock_acquire+0x104/0x18b
Jul 30 11:46:49 closure kernel: [4.222074][]
mutex_lock_nested+0x70/0x391
Jul 30 11:46:49 closure kernel: [4.222078][]
acpi_video_get_backlight_type+0x17/0x164
Jul 30 11:46:49 closure kernel: [4.222083][]
acpi_video_backlight_notify+0x19/0x2f
Jul 30 11:46:49 closure kernel: [4.222088][]
notifier_call_chain+0x4c/0x71
Jul 30 11:46:49 closure kernel: [4.222092][]
__blocking_notifier_call_chain+0x50/0x69
Jul 30 11:46:49 closure kernel: [4.222098][]
blocking_notifier_call_chain+0x14/0x16
Jul 30 11:46:49 closure kernel: [4.222103][]
backlight_device_register+0x1df/0x1f1
Jul 30 11:46:49 closure kernel: [4.222108][]
intel_backlight_register+0xf0/0x157 [i915]
Jul 30 11:46:49 closure kernel: [4.222146][]
intel_modeset_gem_init+0x158/0x164 [i915]
Jul 30 11:46:49 closure kernel: [4.222176][]
i915_driver_load+0xf1c/0x1139 [i915]
Jul 30 11:46:49 closure kernel: [4.05][]
drm_dev_register+0x84/0xfd [drm]
Jul 30 11:46:49 closure kernel: [4.17][]
drm_get_pci_dev+0x102/0x1bc [drm]
Jul 30 11:46:49 closure kernel: [4.28][]
i915_pci_probe+0x4f/0x51 [i915]
Jul 30 11:46:49 closure kernel: [4.47][]
pci_device_probe+0x74/0xd6
Jul 30 11:46:49 closure kernel: [4.53][]
driver_probe_device+
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Thu, Jul 30, 2015 at 5:32 PM, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
>> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
>> > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
>> > 1 file changed, 5 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> > b/drivers/gpu/drm/drm_atomic_helper.c
>> > index 5b59d5ad7d1c..aac212297b49 100644
>> > --- a/drivers/gpu/drm/drm_atomic_helper.c
>> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> > @@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state
>> > *state, int conn_idx)
>> > }
>> >
>> > connector_state->best_encoder = new_encoder;
>> > - idx = drm_crtc_index(connector_state->crtc);
>> > + if (connector_state->crtc) {
>> > + idx = drm_crtc_index(connector_state->crtc);
>> >
>> > - crtc_state = state->crtc_states[idx];
>> > - crtc_state->mode_changed = true;
>> > + crtc_state = state->crtc_states[idx];
>> > + crtc_state->mode_changed = true;
>> > + }
>>
>> This shouldn't happen since if it does we ended up stealing the encoder
>> from the connector itself (we do check for connector_state->crtc earlier)
>> and that would be a bug. I haven't figured out a precise theory but my
>> guess is on the best_encoder selection, and indeed dp mst encoder
>> selection seems to have gone belly up in 4.2 with the bisected commit.
>
> Well, I just tested Linus's patch and it works.
That's sersiously surprising if you mean display and everything actually
works. Is dpms on/off and suspend and all that also still working? Can you
please changed the check into a
if (!connector_state->crtc)
return 0;
so that we don't blow up on the debug line below and then grab dmesg with
drm.debug=0x1e when this happens? Note there will be lots of noise you
might need to dig out full dmesg from logs.
> BTW, is there any chance that I can suspend my laptop, and then move
> it from my docking station at home (where I have a Dell 30" display)
> to my docking station at work (where I have a Dell 24" display), and
> actually have the new monitor be detected? For at least the past
> year, I have to reboot in order to be able to use the external
> monitor? This used to work, but it's been a very long-standing
> regression. I undrstand that Multi-stream DP is a evil horrible hack,
> and supporting it is painful, but this used to work, and it hasn't in
> a long time. :-(
Hm we seem to not reprobe mst state on resume. The quick hack below should
help (but totally untested since still no dp mst hub here).
-Daniel
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 884b4f9b81c4..c0677c83a0e9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -775,6 +775,9 @@ static int i915_drm_resume(struct drm_device *dev)
/* Config may have changed between suspend and resume */
drm_helper_hpd_irq_event(dev);
+ dev_priv->short_hpd_port_mask = ~0;
+ queue_work(dev_priv->dp_wq, &dev_priv->dig_port_work);
+
intel_opregion_init(dev);
intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Thu, 30 Jul 2015 17:32:28 +0200,
Theodore Ts'o wrote:
>
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> > > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 5b59d5ad7d1c..aac212297b49 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state
> > > *state, int conn_idx)
> > > }
> > >
> > > connector_state->best_encoder = new_encoder;
> > > - idx = drm_crtc_index(connector_state->crtc);
> > > + if (connector_state->crtc) {
> > > + idx = drm_crtc_index(connector_state->crtc);
> > >
> > > - crtc_state = state->crtc_states[idx];
> > > - crtc_state->mode_changed = true;
> > > + crtc_state = state->crtc_states[idx];
> > > + crtc_state->mode_changed = true;
> > > + }
> >
> > This shouldn't happen since if it does we ended up stealing the encoder
> > from the connector itself (we do check for connector_state->crtc earlier)
> > and that would be a bug. I haven't figured out a precise theory but my
> > guess is on the best_encoder selection, and indeed dp mst encoder
> > selection seems to have gone belly up in 4.2 with the bisected commit.
>
> Well, I just tested Linus's patch and it works.
>
> BTW, is there any chance that I can suspend my laptop, and then move
> it from my docking station at home (where I have a Dell 30" display)
> to my docking station at work (where I have a Dell 24" display), and
> actually have the new monitor be detected? For at least the past
> year, I have to reboot in order to be able to use the external
> monitor? This used to work, but it's been a very long-standing
> regression. I undrstand that Multi-stream DP is a evil horrible hack,
> and supporting it is painful, but this used to work, and it hasn't in
> a long time. :-(
Relevant with this?
https://bugs.freedesktop.org/show_bug.cgi?id=89589
I wanted to check this by myself, too, as the same bug was reported to
openSUSE bugzilla, but I had no hardware showing it.
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote: > I've tried pulling in your patches from fixes-stuff, onto Linus's tree > (without Linus's fix), and the good news is that I'm no longer > crashing on boot. > > The *bad* news is that (a) it breaks the external monitor attached to > the docking station completely (this was working with Linus's patch), > and (b) it's triggering a LOCKDEP failure. Well, that's not fair. Even with Linus's fix, there is still a LOCKDEP failure. And a few more i915 WARNINGS. But at least the external monitor works, so this is what I'm using. Enclosed please find a dmesg with the lockdep and i915 warnings and my .config. The kernel that I used can be found at: https://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/log/?h=i915-test-4.2.0-rc4 - Ted dmesg.gz Description: application/gzip config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> > but I couldn't test them yet since no dp mst here and I didn't find
> > anything that would ship faster than 1-2 weeks yet. I'll try to get some
> > other people here to test it meanwhile too.
>
> I've tried pulling in your patches from fixes-stuff, onto Linus's tree
> (without Linus's fix), and the good news is that I'm no longer
> crashing on boot.
Ok so I'm not completely clueless yet, the encoder confusion indeed
resulted in the follow-up crash. But obviously I don't understand yet
exactly what's going on if this breaks the display.
> The *bad* news is that (a) it breaks the external monitor attached to
> the docking station completely (this was working with Linus's patch),
> and (b) it's triggering a LOCKDEP failure.
The lockdep splat is all in the driver load before we do any modeset at
all, so shouldn't have changed between these patches. Are you sure it's a
regression due to mine and wasn't there before?
> So even though Linus's patch wasn't supposed to work, I think I'm
> going to back to it
Well I found some dp mst hubs meanwhile so hopefully tomorrow I can test
myself what's going wrong here.
-Daniel
>
> - Ted
>
>
> Jul 30 11:46:49 closure kernel: [4.221951]
> Jul 30 11:46:49 closure kernel: [4.221954]
> ==
> Jul 30 11:46:49 closure kernel: [4.221957] [ INFO: possible circular
> locking dependency detected ]
> Jul 30 11:46:49 closure kernel: [4.221960] 4.2.0-rc4-13906-g5f1b75cd #16
> Not tainted
> Jul 30 11:46:49 closure kernel: [4.221963]
> ---
> Jul 30 11:46:49 closure kernel: [4.221966] modprobe/503 is trying to
> acquire lock:
> Jul 30 11:46:49 closure kernel: [4.221968] (init_mutex){+.+.+.}, at:
> [] acpi_video_get_backlight_type+0x17/0x164
> Jul 30 11:46:49 closure kernel: [4.221977]
> Jul 30 11:46:49 closure kernel: [4.221977] but task is already holding
> lock:
> Jul 30 11:46:49 closure kernel: [4.221979]
> (&(&backlight_notifier)->rwsem){..}, at: []
> __blocking_notifier_call_chain+0x37/0x69
> Jul 30 11:46:49 closure kernel: [4.221987]
> Jul 30 11:46:49 closure kernel: [4.221987] which lock already depends on
> the new lock.
> Jul 30 11:46:49 closure kernel: [4.221987]
> Jul 30 11:46:49 closure kernel: [4.221990]
> Jul 30 11:46:49 closure kernel: [4.221990] the existing dependency chain
> (in reverse order) is:
> Jul 30 11:46:49 closure kernel: [4.221995]
> Jul 30 11:46:49 closure kernel: [4.221995] -> #1
> (&(&backlight_notifier)->rwsem){..}:
> Jul 30 11:46:49 closure kernel: [4.222001][]
> lock_acquire+0x104/0x18b
> Jul 30 11:46:49 closure kernel: [4.222007][]
> down_write+0x46/0x8a
> Jul 30 11:46:49 closure kernel: [4.222012][]
> blocking_notifier_chain_register+0x36/0x57
> Jul 30 11:46:49 closure kernel: [4.222017][]
> backlight_register_notifier+0x18/0x1a
> Jul 30 11:46:49 closure kernel: [4.222022][]
> acpi_video_get_backlight_type+0xfa/0x164
> Jul 30 11:46:49 closure kernel: [4.222028][]
> 0xc03a1e45
> Jul 30 11:46:49 closure audispd: No plugins found, exiting
> Jul 30 11:46:49 closure kernel: [4.222032][]
> 0xc03a28a8
> Jul 30 11:46:49 closure kernel: [4.222036][]
> do_one_initcall+0x19a/0x1af
> Jul 30 11:46:49 closure kernel: [4.222042][]
> do_init_module+0x60/0x1e3
> Jul 30 11:46:49 closure kernel: [4.222047][]
> load_module+0x1c42/0x2059
> Jul 30 11:46:49 closure kernel: [4.222052][]
> SyS_finit_module+0x85/0x92
> Jul 30 11:46:49 closure kernel: [4.222056][]
> entry_SYSCALL_64_fastpath+0x16/0x73
> Jul 30 11:46:49 closure kernel: [4.222060]
> Jul 30 11:46:49 closure kernel: [4.222060] -> #0 (init_mutex){+.+.+.}:
> Jul 30 11:46:49 closure kernel: [4.222065][]
> __lock_acquire+0xc55/0xf54
> Jul 30 11:46:49 closure kernel: [4.222070][]
> lock_acquire+0x104/0x18b
> Jul 30 11:46:49 closure kernel: [4.222074][]
> mutex_lock_nested+0x70/0x391
> Jul 30 11:46:49 closure kernel: [4.222078][]
> acpi_video_get_backlight_type+0x17/0x164
> Jul 30 11:46:49 closure kernel: [4.222083][]
> acpi_video_backlight_notify+0x19/0x2f
> Jul 30 11:46:49 closure kernel: [4.222088][]
> notifier_call_chain+0x4c/0x71
> Jul 30 11:46:49 closure kernel: [4.222092][]
> __blocking_notifier_call_chain+0x50/0x69
> Jul 30 11:46:49 closure kernel: [4.222098][]
> blocking_notifier_call_chain+0x14/0x16
> Jul 30 11:46:49 closure kernel: [4.222103][]
> backlight_device_regist
Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helper: Add option to update planes only on active crtc
Op 29-07-15 om 14:01 schreef Daniel Vetter:
> With drivers supporting runtime pm it's generally not a good idea to
> touch the hardware when it's off. Add an option to the commit_planes
> helper to support this case.
>
> Note that the helpers already add all planes on a crtc when a modeset
> happens, hence plane updates will not be lost if drivers set this to
> true.
>
> v2: Check for NULL state->crtc before chasing the pointer. Also check
> both old and new crtc if there's a switch. Finally just outright
> disallow switching crtcs for a plane if the plane is in active use, on
> most hardware that doesn't make sense.
>
> v3: Since commit_planes(active_only = true) is for enabling things
> only after all the crtc are on we should only look at the new crtc to
> decide whether to call the plane hooks - if the current CRTC isn't on
> then skip. If the old crtc (when moving a plane) went down then the
> plane should have been disabled as part of the pipe shutdown work
> already. For which there's currently no helper really unfortunately.
> Also move the check for wether a plane gets a new CRTC assigned while
> still in active use out of this patch.
>
> Cc: Maarten Lankhorst
> Cc: Thierry Reding
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c| 20 ++--
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +-
> drivers/gpu/drm/msm/msm_atomic.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
> drivers/gpu/drm/sti/sti_drm_drv.c | 2 +-
> drivers/gpu/drm/tegra/drm.c| 2 +-
> include/drm/drm_atomic_helper.h| 3 ++-
> 8 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0b475fae067d..6be0adb5a0e9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1029,7 +1029,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>
> drm_atomic_helper_commit_modeset_disables(dev, state);
>
> - drm_atomic_helper_commit_planes(dev, state);
> + drm_atomic_helper_commit_planes(dev, state, false);
>
> drm_atomic_helper_commit_modeset_enables(dev, state);
>
> @@ -1144,10 +1144,16 @@ fail:
> }
> EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);
>
> +bool plane_crtc_active(struct drm_plane_state *state)
> +{
> + return state->crtc && state->crtc->state->active;
> +}
> +
> /**
> * drm_atomic_helper_commit_planes - commit plane state
> * @dev: DRM device
> * @old_state: atomic state object with old state structures
> + * @active_only: Only commit on active CRTC if set
> *
> * This function commits the new plane state using the plane and atomic
> helper
> * functions for planes and crtcs. It assumes that the atomic state has
> already
> @@ -1162,7 +1168,8 @@ EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);
> * drm_atomic_helper_commit_planes_on_crtc() instead.
> */
> void drm_atomic_helper_commit_planes(struct drm_device *dev,
> - struct drm_atomic_state *old_state)
> + struct drm_atomic_state *old_state,
> + bool active_only)
> {
> struct drm_crtc *crtc;
> struct drm_crtc_state *old_crtc_state;
> @@ -1178,6 +1185,9 @@ void drm_atomic_helper_commit_planes(struct drm_device
> *dev,
> if (!funcs || !funcs->atomic_begin)
> continue;
>
> + if (active_only && !crtc->state->active)
> + continue;
> +
> funcs->atomic_begin(crtc, old_crtc_state);
> }
>
> @@ -1189,6 +1199,9 @@ void drm_atomic_helper_commit_planes(struct drm_device
> *dev,
> if (!funcs)
> continue;
>
> + if (active_only && !plane_crtc_active(plane->state))
> + continue;
> +
> /*
>* Special-case disabling the plane if drivers support it.
>*/
>
This would leave a plane active if it was moved from a active crtc to a
inactive crtc, you would still need to call the atomic_disable(plane) callback
for that one. ;-)
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 00/24] replace ioremap_{cache|wt} with memremap
Changes since v2 [1]:
1/ Move arch_memremap() and arch_memunmap() out of line (Christoph)
2/ Convert region_is_ram() to region_intersects() and define an enum for
its 3 return values. (Luis)
3/ Fix gma500 and i915 to explicitly use cached mappings and clean up
the __iomem usage. (Daniel)
4/ Kill unused ioremap aliases (ioremap_cached() and
ioremap_fullcache()) (Christoph)
5/ Clarify some change logs and documentation (Luis, Christoph, and
Ross)
6/ Add a unified CONFIG_MMU=n implementation with __weak symbols. (Luis)
---
While developing the pmem driver we noticed that the __iomem annotation
on the return value from ioremap_cache() was being mishandled by several
callers. We also observed that all of the call sites expected to be
able to treat the return value from ioremap_cache() as normal
(non-__iomem) pointer to memory.
This patchset takes the opportunity to clean up the above confusion as
well as a few issues with the ioremap_{cache|wt} interface, including:
1/ Eliminating the possibility of function prototypes differing between
architectures by defining a central memremap() prototype that takes
flags to determine the mapping type.
2/ Returning NULL rather than falling back silently to a different
mapping-type. This allows drivers to be stricter about the
mapping-type fallbacks that are permissible.
[1]: http://marc.info/?l=linux-arch&m=14377917405&w=2
---
Dan Williams (24):
mm: enhance region_is_ram() to region_intersects()
arch, drivers: don't include directly, use instead
cleanup IORESOURCE_CACHEABLE vs ioremap()
intel_iommu: fix leaked ioremap mapping
arch: introduce memremap()
arm: switch from ioremap_cache to memremap
x86: switch from ioremap_cache to memremap
gma500: switch from acpi_os_ioremap to memremap
i915: switch from acpi_os_ioremap to memremap
acpi: switch from ioremap_cache to memremap
toshiba laptop: replace ioremap_cache with ioremap
memconsole: fix __iomem mishandling, switch to memremap
visorbus: switch from ioremap_cache to memremap
intel-iommu: switch from ioremap_cache to memremap
libnvdimm, pmem: push call to ioremap_cache out of line
pxa2xx-flash: switch from ioremap_cache to memremap
sfi: switch from ioremap_cache to memremap
fbdev: switch from ioremap_wt to memremap
pmem: switch from ioremap_wt to memremap
arch: kill ioremap_cached()
arch: kill ioremap_fullcache()
arch: remove ioremap_cache, replace with arch_memremap
arch: remove ioremap_wt, optionally replace with arch_memremap
pmem: convert to generic memremap
Documentation/x86/pat.txt |6 +
arch/arc/include/asm/io.h |1
arch/arm/Kconfig |1
arch/arm/include/asm/io.h |7 --
arch/arm/include/asm/xen/page.h|4 -
arch/arm/mach-clps711x/board-cdb89712.c|2
arch/arm/mach-shmobile/pm-rcar.c |2
arch/arm/mm/ioremap.c | 18 +++-
arch/arm/mm/mmu.c |2
arch/arm/mm/nommu.c| 11 ++
arch/arm64/Kconfig |1
arch/arm64/include/asm/acpi.h | 11 --
arch/arm64/include/asm/dmi.h |8 +-
arch/arm64/include/asm/io.h|2
arch/arm64/kernel/efi.c|9 +-
arch/arm64/kernel/smp_spin_table.c | 19 ++--
arch/arm64/mm/ioremap.c| 20 ++--
arch/avr32/include/asm/io.h|1
arch/frv/include/asm/io.h | 12 ---
arch/ia64/Kconfig |1
arch/ia64/include/asm/io.h |5 -
arch/ia64/kernel/cyclone.c |2
arch/ia64/mm/ioremap.c | 16 +++
arch/m32r/include/asm/io.h |1
arch/m68k/Kconfig |1
arch/m68k/include/asm/io_mm.h | 12 ---
arch/m68k/include/asm/io_no.h | 11 --
arch/m68k/include/asm/raw_io.h |1
arch/m68k/mm/kmap.c| 17 +++-
arch/m68k/mm/sun3kmap.c|6 +
arch/metag/include/asm/io.h|6 -
arch/microblaze/include/asm/io.h |2
arch/mn10300/include/asm/io.h |1
arch/nios2/include/asm/io.h|1
arch/powerpc/kernel/pci_of_scan.c |2
arch/s390/include/asm/io.h |1
arch/sh/Kconfig|1
arch/sh/include/asm/io.h |6 -
arch/sh/mm/ioremap.c | 15 +++
arch/sparc/include/asm/io_32.h |1
arch/sparc/include/asm/io_64.h
[Intel-gfx] [PATCH v3 09/24] i915: switch from acpi_os_ioremap to memremap
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/i915/i915_debugfs.c |2 -
drivers/gpu/drm/i915/i915_drv.h | 12 ++---
drivers/gpu/drm/i915/intel_bios.c |7 +--
drivers/gpu/drm/i915/intel_opregion.c | 87 -
drivers/gpu/drm/i915/intel_panel.c|2 -
5 files changed, 52 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 82bbe3f2a7e1..9228d6048bde 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1831,7 +1831,7 @@ static int i915_opregion(struct seq_file *m, void *unused)
goto out;
if (opregion->header) {
- memcpy_fromio(data, opregion->header, OPREGION_SIZE);
+ memcpy(data, opregion->header, OPREGION_SIZE);
seq_write(m, data, OPREGION_SIZE);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5f27290201e0..2efbfd53be51 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -403,14 +403,14 @@ struct opregion_swsci;
struct opregion_asle;
struct intel_opregion {
- struct opregion_header __iomem *header;
- struct opregion_acpi __iomem *acpi;
- struct opregion_swsci __iomem *swsci;
+ struct opregion_header *header;
+ struct opregion_acpi *acpi;
+ struct opregion_swsci *swsci;
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
- struct opregion_asle __iomem *asle;
- void __iomem *vbt;
- u32 __iomem *lid_state;
+ struct opregion_asle *asle;
+ void *vbt;
+ u32 *lid_state;
struct work_struct asle_work;
};
#define OPREGION_SIZE(8*1024)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 198fc3c3291b..3e2dca4f5e6e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1206,11 +1206,10 @@ static const struct bdb_header *validate_vbt(const void
__iomem *_base,
{
/*
* This is the one place where we explicitly discard the address space
-* (__iomem) of the BIOS/VBT. (And this will cause a sparse complaint.)
-* From now on everything is based on 'base', and treated as regular
-* memory.
+* (__iomem) of the BIOS/VBT. From now on everything is based on
+* 'base', and treated as regular memory.
*/
- const void *base = (const void *) _base;
+ const void *base = (const void __force *) _base;
size_t offset = _vbt - _base;
const struct vbt_header *vbt = base + offset;
const struct bdb_header *bdb;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 481337436f72..7deed1062871 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -232,7 +232,7 @@ struct opregion_asle {
static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci;
+ struct opregion_swsci *swsci = dev_priv->opregion.swsci;
u32 main_function, sub_function, scic;
u16 pci_swsci;
u32 dslp;
@@ -257,7 +257,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
}
/* Driver sleep timeout in ms. */
- dslp = ioread32(&swsci->dslp);
+ dslp = swsci->dslp;
if (!dslp) {
/* The spec says 2ms should be the default, but it's too small
* for some machines. */
@@ -270,7 +270,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
}
/* The spec tells us to do this, but we are the only user... */
- scic = ioread32(&swsci->scic);
+ scic = swsci->scic;
if (scic & SWSCI_SCIC_INDICATOR) {
DRM_DEBUG_DRIVER("SWSCI request already in progress\n");
return -EBUSY;
@@ -278,8 +278,8 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
scic = function | SWSCI_SCIC_INDICATOR;
- iowrite32(parm, &swsci->parm);
- iowrite32(scic, &swsci->scic);
+ swsci->parm = parm;
+ swsci->scic = scic;
/* Ensure SCI event is selected and event trigger is cleared. */
pci_read_config_word(dev->pdev, PCI_SWSCI, &pci_swsci);
@@ -294,7 +294,7 @@ static int swsci(struct drm_device *dev, u32 function, u32
parm, u32 *parm_out)
pci_write_config_word(dev->pdev, PCI_SWSCI, pci
Re: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries for CHV
This applies to all CHV derivatives, including BSW?
Gavin Hindman
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Sivakumar Thulasimani
Sent: Thursday, July 30, 2015 1:45 AM
To: ville.syrj...@linux.intel.com; intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries
for CHV
From: "Thulasimani,Sivakumar"
CHV does not support intermediate link rates nor does it support HBR2. This
patch removes those entries and returns HBR as the max link rate supported on
CHV platform.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 898dc74..5c68b17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
27,
324000, 432000, 54 };
static const int skl_rates[] = { 162000, 216000, 27,
324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
static const int default_rates[] = { 162000, 27, 54 };
/**
@@ -1186,15 +1183,13 @@ intel_dp_source_rates(struct drm_device *dev, const int
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
- } else if (IS_CHERRYVIEW(dev)) {
- *source_rates = chv_rates;
- return ARRAY_SIZE(chv_rates);
}
*source_rates = default_rates;
- if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0)
- /* WaDisableHBR2:skl */
+ /* WaDisableHBR2:skl */
+ if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) ||
+ IS_CHERRYVIEW(dev))
return (DP_LINK_BW_2_7 >> 3) + 1;
else if (INTEL_INFO(dev)->gen >= 8 ||
(IS_HASWELL(dev) && !IS_HSW_ULX(dev)))
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Thu, Jul 30, 2015 at 8:57 AM, Takashi Iwai wrote: > On Thu, 30 Jul 2015 17:32:28 +0200, > Theodore Ts'o wrote: >> >> BTW, is there any chance that I can suspend my laptop, and then move >> it from my docking station at home (where I have a Dell 30" display) >> to my docking station at work (where I have a Dell 24" display), and >> actually have the new monitor be detected? For at least the past >> year, I have to reboot in order to be able to use the external >> monitor? This used to work, but it's been a very long-standing >> regression. I undrstand that Multi-stream DP is a evil horrible hack, >> and supporting it is painful, but this used to work, and it hasn't in >> a long time. :-( > > Relevant with this? >https://bugs.freedesktop.org/show_bug.cgi?id=89589 > > I wanted to check this by myself, too, as the same bug was reported to > openSUSE bugzilla, but I had no hardware showing it. Hmm. That commit e7d6f7d70829 looks like it should still revert fairly cleanly (just move the call to intel_dp_mst_resume() to before the intel_modeset_setup_hw_state() call and locking). Ted, worth checking out, even if that presumably ends up re-introducing some WARN_ON's.. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 00/19] 48-bit PPGTT
On Thu, Jul 30, 2015 at 12:52:19PM +0100, Michel Thierry wrote: > Sounds like I screwed up something in the first 4 patches or in the > Wa32bit one. The rest of the changes are contained to 48-bit code. > > Have you find a way to reproduce it? Seems like no. Whatever happened this morning, it hasn't happened since preping the tree for a bisect (recompiling an retesting last known bad/good). Panic over for the time being. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Mark PIN_USER binding as GLOBAL_BIND without the aliasing ppgtt
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6894 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 297/297 297/297 SNB 315/315 315/315 IVB 342/342 342/342 BYT 282/282 282/282 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Extract a intel_power_well_enable() function
From: Damien Lespiau
We need a bit book keeping around power wells' ops->enable(), namely a
nice debug message and updating hw_enabled. Let's introduce a
intel_power_well_enable() function to make sure all the callers do the
same things.
v2 (from Paulo):
- s/i915_power_well_enable/intel_power_well_enable/ since everything
else on this file uses intel_ instead of i915_.
- Fix typo in commit message.
Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6393b76..a52574d 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -68,6 +68,14 @@
bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
int power_well_id);
+static void intel_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ DRM_DEBUG_KMS("enabling %s\n", power_well->name);
+ power_well->ops->enable(dev_priv, power_well);
+ power_well->hw_enabled = true;
+}
+
/*
* We should only use the power well if we explicitly asked the hardware to
* enable it, so check if it's enabled and also check if we've requested it to
@@ -1104,11 +1112,8 @@ void intel_display_power_get(struct drm_i915_private
*dev_priv,
mutex_lock(&power_domains->lock);
for_each_power_well(i, power_well, BIT(domain), power_domains) {
- if (!power_well->count++) {
- DRM_DEBUG_KMS("enabling %s\n", power_well->name);
- power_well->ops->enable(dev_priv, power_well);
- power_well->hw_enabled = true;
- }
+ if (!power_well->count++)
+ intel_power_well_enable(dev_priv, power_well);
}
power_domains->domain_use_count[domain]++;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Extract a intel_power_well_disable() function
From: Damien Lespiau
Similar to the ->enable vfunc in commit:
commit 865720564389b2b19cf58e41ed31701e5f464b9d
Author: Damien Lespiau
Date: Wed Jun 3 14:27:05 2015 +0100
drm/i915: Extract a intel_power_well_enable() function
v2 (from Paulo):
- Same s/i915_/intel_/ bikeshed as the previous patch.
- Update the commit hash.
Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index a52574d..821644d 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -76,6 +76,14 @@ static void intel_power_well_enable(struct drm_i915_private
*dev_priv,
power_well->hw_enabled = true;
}
+static void intel_power_well_disable(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+ DRM_DEBUG_KMS("disabling %s\n", power_well->name);
+ power_well->hw_enabled = false;
+ power_well->ops->disable(dev_priv, power_well);
+}
+
/*
* We should only use the power well if we explicitly asked the hardware to
* enable it, so check if it's enabled and also check if we've requested it to
@@ -1147,11 +1155,8 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
WARN_ON(!power_well->count);
- if (!--power_well->count && i915.disable_power_well) {
- DRM_DEBUG_KMS("disabling %s\n", power_well->name);
- power_well->hw_enabled = false;
- power_well->ops->disable(dev_priv, power_well);
- }
+ if (!--power_well->count && i915.disable_power_well)
+ intel_power_well_disable(dev_priv, power_well);
}
mutex_unlock(&power_domains->lock);
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Fix SKL runtime PM
Hello So I discovered that SKL runtime PM doesn't work on drm-intel-nightly and decided to investigate why. I found this patch in one of Damien's trees and it fixed the problem I was seeing. I really don't know why the patches were not sent to the list yet and I can't ask him since he's on vacation. So I decided to review them, implement my own bikesheds, add R-B tags and submit to the list, since it's an important feature that's broken and preliminary_hw_support was removed for SKL. I hope the reason he didn't submit this is not because there's some bug I failed to spot. Anyway, he'll tell us in a few days :). Also notice that we're not passing every pm_rpm subtest now: we're just not failing 100% of the tests. Thanks, Paulo Damien Lespiau (3): drm/i915: Extract a intel_power_well_enable() function drm/i915: Extract a intel_power_well_disable() function drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences Paulo Zanoni (1): drm/i915/skl: send opregion_nofify_adapter(PCI_D1) instead of PCI_D3 drivers/gpu/drm/i915/i915_drv.c | 20 +-- drivers/gpu/drm/i915/intel_ddi.c| 2 -- drivers/gpu/drm/i915/intel_display.c| 5 +-- drivers/gpu/drm/i915/intel_drv.h| 2 ++ drivers/gpu/drm/i915/intel_runtime_pm.c | 59 +++-- 5 files changed, 63 insertions(+), 25 deletions(-) -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequences
From: Damien Lespiau
Before this patch, we used the intel_display_power_{get,put} functions
to make sure the PW1 and Misc I/O power wells were enabled all the
time while LCPLL was enabled. We called a get() at
intel_ddi_pll_init() when we discovered that LCPLL was enabled, then
we would call put/get at skl_{un,}init_cdclk().
The problem is that skl_uninit_cdclk() is indirectly called by
intel_runtime_suspend(). So it will only release its power well
_after_ we already decided to runtime suspend. But since we only
decide to runtime suspend after all power wells and refcounts are
released, that basically means we will never decide to runtime
suspend.
So what this patch does to fix that problem is move the PW1 + Misc I/O
power well handling out of the runtime PM mechanism: instead of
calling intel_display_power_{get_put} - functions that touch the
refcount -, we'll call the low level intel_power_well_{en,dis}able,
which don't change the refcount. This way, it is now possible for the
refcount to actually reach zero, and we'll now start runtime
suspending/resuming.
v2 (from Paulo):
- Write a commit message since the original patch left it empty.
- Rebase after the intel_power_well_{en,dis}able rename.
- Use lookup_power_well() instead of hardcoded indexes.
Testcase: igt/pm_rpm/rte (and every other rpm test)
Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c| 2 --
drivers/gpu/drm/i915/intel_display.c| 5 +++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 29 +
4 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a40bfb..e629ad3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2931,8 +2931,6 @@ void intel_ddi_pll_init(struct drm_device *dev)
dev_priv->skl_boot_cdclk = cdclk_freq;
if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
DRM_ERROR("LCPLL1 is disabled\n");
- else
- intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
} else if (IS_BROXTON(dev)) {
broxton_init_cdclk(dev);
broxton_ddi_phy_init(dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 43b0f17..34cbe4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5680,7 +5680,8 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
DRM_ERROR("Couldn't disable DPLL0\n");
- intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
+ /* disable PG1 and Misc I/O */
+ skl_pw1_misc_io_fini(dev_priv);
}
void skl_init_cdclk(struct drm_i915_private *dev_priv)
@@ -5693,7 +5694,7 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
I915_WRITE(HSW_NDE_RSTWRN_OPT, val | RESET_PCH_HANDSHAKE_ENABLE);
/* enable PG1 and Misc I/O */
- intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
+ skl_pw1_misc_io_init(dev_priv);
/* DPLL0 already enabed !? */
if (I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..10e8a2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1325,6 +1325,8 @@ void intel_psr_single_frame_update(struct drm_device *dev,
int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_fini(struct drm_i915_private *);
void intel_power_domains_init_hw(struct drm_i915_private *dev_priv);
+void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv);
+void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv);
void intel_runtime_pm_enable(struct drm_i915_private *dev_priv);
bool intel_display_power_is_enabled(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 821644d..d62b030 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1505,6 +1505,35 @@ static struct i915_power_well skl_power_wells[] = {
},
};
+void skl_pw1_misc_io_init(struct drm_i915_private *dev_priv)
+{
+ struct i915_power_well *well;
+
+ if (!IS_SKYLAKE(dev_priv))
+ return;
+
+ well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
+ intel_power_well_enable(dev_priv, well);
+
+ well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO);
+ intel_power_well_enable(dev_priv, well);
+}
+
+void skl_pw1_misc_io_fini(struct drm_i915_private *dev_priv)
+{
+ struct i915_power_well *well;
+
+ if (!IS_SKYLAKE(dev_priv))
+ return;
+
+ well = lookup_power_well(dev_pri
[Intel-gfx] [PATCH 4/4] drm/i915/skl: send opregion_nofify_adapter(PCI_D1) instead of PCI_D3
I was told that the "repurposed D1 definition" is still valid for SKL.
It is BDW that is special due to its hotplug bug, so let's
special-case BDW instead of HSW.
Cc: Kristen Carlson Accardi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 151263b..1d88745 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1489,7 +1489,15 @@ static int intel_runtime_suspend(struct device *device)
* FIXME: We really should find a document that references the arguments
* used below!
*/
- if (IS_HASWELL(dev)) {
+ if (IS_BROADWELL(dev)) {
+ /*
+* On Broadwell, if we use PCI_D1 the PCH DDI ports will stop
+* being detected, and the call we do at intel_runtime_resume()
+* won't be able to restore them. Since PCI_D3hot matches the
+* actual specification and appears to be working, use it.
+*/
+ intel_opregion_notify_adapter(dev, PCI_D3hot);
+ } else {
/*
* current versions of firmware which depend on this opregion
* notification have repurposed the D1 definition to mean
@@ -1498,16 +1506,6 @@ static int intel_runtime_suspend(struct device *device)
* the suspend path.
*/
intel_opregion_notify_adapter(dev, PCI_D1);
- } else {
- /*
-* On Broadwell, if we use PCI_D1 the PCH DDI ports will stop
-* being detected, and the call we do at intel_runtime_resume()
-* won't be able to restore them. Since PCI_D3hot matches the
-* actual specification and appears to be working, use it. Let's
-* assume the other non-Haswell platforms will stay the same as
-* Broadwell.
-*/
- intel_opregion_notify_adapter(dev, PCI_D3hot);
}
assert_forcewakes_inactive(dev_priv);
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: revert duplicated WaBarrierPerformanceFixDisable:skl
good catch.
Reviewed-by: Rodrigo Vivi
On Wed, Jul 29, 2015 at 12:21 PM, Marc Herbert wrote:
> With this simple git diff command one can see that skl_init_workarounds()
> got two copies of WaBarrierPerformanceFixDisable:skl:
>
> git diff -U21 ca6e4405779e^1 ca6e4405779e
> drivers/gpu/drm/i915/intel_ringbuffer.c
>
> This happened when the backmerge of drm-intel-fixes-2015-07-15
> Merged the same fix on both sides. Same fix but not identical enough for
> git: with a different surrounding context; hence the code duplication.
>
> This commit merely reverts the output of the git command above
> = the duplication introduced in the backmerge.
>
> (This duplication was found while running git sanity checks on a
> _linearized_ i915 forklift for ChromeOS.)
>
> Signed-off-by: Marc Herbert
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 177f7ed16cf0..1c14233d179f 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1041,13 +1041,6 @@ static int skl_init_workarounds(struct intel_engine_cs
> *ring)
> WA_SET_BIT_MASKED(HIZ_CHICKEN,
>
> BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
>
> - if (INTEL_REVID(dev) == SKL_REVID_C0 ||
> - INTEL_REVID(dev) == SKL_REVID_D0)
> - /* WaBarrierPerformanceFixDisable:skl */
> - WA_SET_BIT_MASKED(HDC_CHICKEN0,
> - HDC_FENCE_DEST_SLM_DISABLE |
> - HDC_BARRIER_PERFORMANCE_DISABLE);
> -
> if (INTEL_REVID(dev) <= SKL_REVID_D0) {
> /*
> *Use Force Non-Coherent whenever executing a 3D context. This
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Split sink_crc function in start, stop and read.
This is just a preparation patch to make clear what operation we
are performing. There is no functional change on the sink crc
logic.
hsw_disable_ips has been moved a bit further in the start function
to avoid disabling ips when sink crc is not going to be started.
and to avoid goto on this function.
v2: explain why hsw_disable_ips() call place has changed.
Cc: Daniel Vetter
Reviewed-by: Rafael Antognolli
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 89 +++--
1 file changed, 50 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..10cbc98 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3958,40 +3958,64 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
return intel_dp->is_mst;
}
-int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
+static void intel_dp_sink_crc_stop(struct intel_dp *intel_dp)
{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_device *dev = intel_dig_port->base.base.dev;
- struct intel_crtc *intel_crtc =
- to_intel_crtc(intel_dig_port->base.base.crtc);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
u8 buf;
- int test_crc_count;
- int attempts = 6;
- int ret = 0;
-
- hsw_disable_ips(intel_crtc);
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0) {
- ret = -EIO;
- goto out;
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
+ DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
+ return;
}
- if (!(buf & DP_TEST_CRC_SUPPORTED)) {
- ret = -ENOTTY;
- goto out;
- }
+ if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
+ buf & ~DP_TEST_SINK_START) < 0)
+ DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
- ret = -EIO;
- goto out;
- }
+ hsw_enable_ips(intel_crtc);
+}
+
+static int intel_dp_sink_crc_start(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
+ u8 buf;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0)
+ return -EIO;
+
+ if (!(buf & DP_TEST_CRC_SUPPORTED))
+ return -ENOTTY;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
+ return -EIO;
+
+ hsw_disable_ips(intel_crtc);
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
- buf | DP_TEST_SINK_START) < 0) {
- ret = -EIO;
- goto out;
+ buf | DP_TEST_SINK_START) < 0) {
+ hsw_enable_ips(intel_crtc);
+ return -EIO;
}
+ return 0;
+}
+
+int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct intel_crtc *intel_crtc = to_intel_crtc(dig_port->base.base.crtc);
+ u8 buf;
+ int test_crc_count;
+ int attempts = 6;
+ int ret;
+
+ ret = intel_dp_sink_crc_start(intel_dp);
+ if (ret)
+ return ret;
+
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf) < 0) {
ret = -EIO;
goto stop;
@@ -4014,23 +4038,10 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
*crc)
goto stop;
}
- if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0)
ret = -EIO;
- goto stop;
- }
-
stop:
- if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
- DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
- goto out;
- }
- if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
- buf & ~DP_TEST_SINK_START) < 0) {
- DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
- goto out;
- }
-out:
- hsw_enable_ips(intel_crtc);
+ intel_dp_sink_crc_stop(intel_dp);
return ret;
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: revert duplicated WaBarrierPerformanceFixDisable:skl
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6895 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 297/297 296/297 SNB 315/315 315/315 IVB 342/342 342/342 BYT -1 282/282 281/282 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@flip-vs-dpms-interruptible PASS(1) DMESG_WARN(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix FBC frontbuffer tracking flushing code
On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Due to the way busy_bits was handled, we were not doing any flushes if
> we didn't previously get an invalidate. Since it's possible to get
> flushes without an invalidate first, remove the busy_bits early
> return.
>
> So now that we don't have the busy_bits guard anymore we'll need the
> origin check for the GTT tracking (we were not doing anything on GTT
> flushes due to the GTT check at invalidate()).
>
> As a last detail, since we can get multiple consecutive flushes,
> disable FBC before updating it, otherwise intel_fbc_update() will just
> keep FBC enabled instead of restarting it.
>
> Notice that this does not fix any of the current IGT tests due to the
> fact that we still have a few intel_fbc() calls at points where we
> also have the frontbuffer tracking calls: we didn't fully convert to
> frontbuffer tracking yet. Once we remove those calls and start relying
> only on the frontbuffer tracking infrastructure we'll need this patch.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_fbc.c | 13 +++--
> drivers/gpu/drm/i915/intel_frontbuffer.c | 2 +-
> 3 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index f4abce1..2437666 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1240,7 +1240,7 @@ void intel_fbc_invalidate(struct drm_i915_private
> *dev_priv,
> unsigned int frontbuffer_bits,
> enum fb_op_origin origin);
> void intel_fbc_flush(struct drm_i915_private *dev_priv,
> -unsigned int frontbuffer_bits);
> +unsigned int frontbuffer_bits, enum fb_op_origin
> origin);
> const char *intel_no_fbc_reason_str(enum no_fbc_reason reason);
> void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index c271af7..1f97fb5 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -884,22 +884,23 @@ void intel_fbc_invalidate(struct drm_i915_private
> *dev_priv,
> }
>
> void intel_fbc_flush(struct drm_i915_private *dev_priv,
> -unsigned int frontbuffer_bits)
> +unsigned int frontbuffer_bits, enum fb_op_origin
> origin)
> {
> if (!dev_priv->fbc.enable_fbc)
> return;
>
> - mutex_lock(&dev_priv->fbc.lock);
> + if (origin == ORIGIN_GTT)
> + return;
>
> - if (!dev_priv->fbc.busy_bits)
> - goto out;
> + mutex_lock(&dev_priv->fbc.lock);
>
> dev_priv->fbc.busy_bits &= ~frontbuffer_bits;
>
> - if (!dev_priv->fbc.busy_bits)
> + if (!dev_priv->fbc.busy_bits) {
> + __intel_fbc_disable(dev_priv);
> __intel_fbc_update(dev_priv);
>
are we going to kill fbc_update for good? ;)
But yes, we need to force the disable on flush so this is good.
I'd just add in a separated patch, but anyway feel free to use
Reviewed-by: Rodrigo Vivi
> + }
>
> -out:
> mutex_unlock(&dev_priv->fbc.lock);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c
> b/drivers/gpu/drm/i915/intel_frontbuffer.c
> index 777b1d3..ac85357 100644
> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
> @@ -129,7 +129,7 @@ static void intel_frontbuffer_flush(struct drm_device
> *dev,
>
> intel_edp_drrs_flush(dev, frontbuffer_bits);
> intel_psr_flush(dev, frontbuffer_bits, origin);
> - intel_fbc_flush(dev_priv, frontbuffer_bits);
> + intel_fbc_flush(dev_priv, frontbuffer_bits, origin);
> }
>
> /**
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: don't call intel_fbc_update() at intel_unpin_work_fn()
On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni wrote: > From: Paulo Zanoni > > Because intel_unpin_work_fn() already calls > intel_frontbuffer_flip_complete() which will call intel_fbc_flush() > which will call intel_fbc_update() when needed. > > We couldn't fix this previously due to the fact that FBC was not > properly behaving as intended on frontbuffer flushes, but now that > this is fixed, we can remove the additional call. > > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_display.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index ad0fc6a..37b2528 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -10765,15 +10765,12 @@ static void intel_unpin_work_fn(struct > work_struct *__work) > container_of(__work, struct intel_unpin_work, work); > struct intel_crtc *crtc = to_intel_crtc(work->crtc); > struct drm_device *dev = crtc->base.dev; > - struct drm_i915_private *dev_priv = dev->dev_private; > struct drm_plane *primary = crtc->base.primary; > > mutex_lock(&dev->struct_mutex); > intel_unpin_fb_obj(work->old_fb, primary->state); > drm_gem_object_unreference(&work->pending_flip_obj->base); > > - intel_fbc_update(dev_priv); > \o/ let's kill it! Reviewed-by: Rodrigo Vivi > - > if (work->flip_queued_req) > i915_gem_request_assign(&work->flip_queued_req, NULL); > mutex_unlock(&dev->struct_mutex); > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: don't disable FBC for pipe A when flipping pipe B
On Wed, Jul 15, 2015 at 5:31 AM Daniel Vetter wrote: > On Tue, Jul 14, 2015 at 04:29:13PM -0300, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > Use the appropriate call. > Good! Reviewed-by: Rodrigo Vivi > > > > I know there's a discussion about whether we need this call here at > > all, but removing the call means we'll only update FBC after we get > > the page flip IRQ. So the user may only see the new frame a little > > after it should. Let's wait just a little bit more before removing > > this call since we can rely in the HW tracking for accurate flips. > I'm in favor of remove or at least move to frontbuffer prepare for flip.. > > Afaik fbc2 on g4x+ does correctly invalidate the fbc cache when flipping > the frontbuffer. This was needed for fbc1 which just didn't handle flips - > there we had to essentially disable and then re-enable fbc to make sure > the update was tracked correctly. > > The other problem is correctly synchronizing the fence update (for hw gtt > tracking) against the flip. I'm not sure whether we still have races left > there, but simply updating the fence window before we flip should be all > that's required. But anyway I'm also in favor of removing the old fbc... > -Daniel > > > > > Signed-off-by: Paulo Zanoni > > --- > > drivers/gpu/drm/i915/intel_display.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > > index 37b2528..6e3ba5f 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -11544,7 +11544,7 @@ static int intel_crtc_page_flip(struct drm_crtc > *crtc, > > to_intel_plane(primary)->frontbuffer_bit); > > mutex_unlock(&dev->struct_mutex); > > > > - intel_fbc_disable(dev_priv); > > + intel_fbc_disable_crtc(intel_crtc); > > intel_frontbuffer_flip_prepare(dev, > > > to_intel_plane(primary)->frontbuffer_bit); > > > > -- > > 2.1.4 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: special-case dirtyfb for frontbuffer tracking
Very good. I should've added this when adding the dirtyfb flush...
Thanks,
Reviewed-by: Rodrigo Vivi
On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> First, an introduction. We currently have two types of GTT mmaps: the
> "normal" old mmap, and the WC mmap. For frontbuffer-related features
> that have automatic hardware tracking, only the non-WC mmap writes are
> detected by the hardware. Since inside the Kernel both are treated as
> ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
> tracking are destined to fail.
>
> One of the special rules defined for the WC mmaps is that the user
> should call the dirtyfb IOCTL after he is done using the pointers, so
> that results in an intel_fb_obj_flush() call. The problem is that the
> dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
> though the hardware tracking is not detecing the WC mmap operations.
> So in order to fix that without having to give up the automatic
> hardware tracking for GTT mmaps we transform the flush operation from
> dirtyfb into a special operation: ORIGIN_DIRTYFB.
>
> This commit fixes all the kms_frontbuffer_tracking subtests that
> contain "fbc" and "mmap-wc" in their names and are currently failing
> (for a total of 16 subtests).
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index cf6761c..78d21c1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -894,6 +894,7 @@ enum fb_op_origin {
> ORIGIN_CPU,
> ORIGIN_CS,
> ORIGIN_FLIP,
> + ORIGIN_DIRTYFB,
> };
>
> struct i915_fbc {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6e3ba5f..cffaaf4a3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14479,7 +14479,7 @@ static int intel_user_framebuffer_dirty(struct
> drm_framebuffer *fb,
> struct drm_i915_gem_object *obj = intel_fb->obj;
>
> mutex_lock(&dev->struct_mutex);
> - intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> + intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
> mutex_unlock(&dev->struct_mutex);
>
> return 0;
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.
Since active function on VLV immediately activate PSR let's give more
time for idleness. Different from core platforms where we have idle_frames
count.
Also kms_psr_sink_crc now is automated and always get this:
[drm:intel_enable_pipe] enabling pipe A
[drm:intel_edp_backlight_on]
[drm:intel_panel_enable_backlight] pipe
[drm:intel_panel_enable_backlight] pipe A
[drm:intel_panel_actually_set_backlight] set backlight PWM = 7812
PSR gets enabled somewhere here after backlight.
[drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 0x0
[drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
[drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
PSR gets flushed around here by intel_atomic_commit
[drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511
[drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp
[drm:intel_set_memory_cxsr] memory self-refresh is enabled
[drm:intel_connector_check_state] [CONNECTOR:39:eDP-1]
[drm:check_encoder_state] [ENCODER:30:DAC-30]
[drm:check_encoder_state] [ENCODER:31:TMDS-31]
[drm:check_encoder_state] [ENCODER:36:TMDS-36]
[drm:check_encoder_state] [ENCODER:38:TMDS-38]
[drm:check_crtc_state] [CRTC:21]
[drm:check_crtc_state] [CRTC:26]
[drm:intel_psr_activate [i915]] *ERROR* PSR Active
[drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 0x
[drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO
Underrun.
It is true that in a product we won't keep disabling and enabling planes so
frequently, but for safeness let's stay conservative.
It is also true that 500ms is an etternity. But PSR is anyway a power saving
feature for idle scenario. So if it is idle feature stays on and 500ms to get
it reanabled is not that insane.
v2: Rebase over intel_psr.c and fix typo.
v3: Revival: Manual tests indicated that this is needed. With a short delay
there is a huge risk of getting blank screens when planes are being enabled.
v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but
actually time for link training what we aren't doing, but with only 100 sec
in some cases kms_psr_sink_crc manual was showing blank screen,
so let's use this for now. Also changed comment by a FIXME.
v5: Rebase after a long time, remove FIXME and update comment above.
v6: msecs_to_jiffies is already on delay. remove duplication.
v7: use msecs_to_jiffies on schedule_delayed_work call.
Reviewed-by: Durgadoss R (v4)
Signed-off-by: Rodrigo Vivi
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index acd8ec8..a04b4dc 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -698,6 +698,7 @@ void intel_psr_flush(struct drm_device *dev,
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc;
enum pipe pipe;
+ int delay_ms = HAS_DDI(dev) ? 100 : 500;
mutex_lock(&dev_priv->psr.lock);
if (!dev_priv->psr.enabled) {
@@ -733,7 +734,7 @@ void intel_psr_flush(struct drm_device *dev,
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
schedule_delayed_work(&dev_priv->psr.work,
- msecs_to_jiffies(100));
+ msecs_to_jiffies(delay_ms));
mutex_unlock(&dev_priv->psr.lock);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries for CHV
On 7/30/2015 10:48 PM, Hindman, Gavin wrote:
This applies to all CHV derivatives, including BSW?
Gavin Hindman
yes, this will apply to all CHV derivatives.
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Sivakumar Thulasimani
Sent: Thursday, July 30, 2015 1:45 AM
To: ville.syrj...@linux.intel.com; intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries
for CHV
From: "Thulasimani,Sivakumar"
CHV does not support intermediate link rates nor does it support HBR2. This
patch removes those entries and returns HBR as the max link rate supported on
CHV platform.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 898dc74..5c68b17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
27,
324000, 432000, 54 };
static const int skl_rates[] = { 162000, 216000, 27,
324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
static const int default_rates[] = { 162000, 27, 54 };
/**
@@ -1186,15 +1183,13 @@ intel_dp_source_rates(struct drm_device *dev, const int
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
- } else if (IS_CHERRYVIEW(dev)) {
- *source_rates = chv_rates;
- return ARRAY_SIZE(chv_rates);
}
*source_rates = default_rates;
- if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0)
- /* WaDisableHBR2:skl */
+ /* WaDisableHBR2:skl */
+ if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) ||
+ IS_CHERRYVIEW(dev))
return (DP_LINK_BW_2_7 >> 3) + 1;
else if (INTEL_INFO(dev)->gen >= 8 ||
(IS_HASWELL(dev) && !IS_HSW_ULX(dev)))
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 04/19] drm/i915/gen8: Generalize PTE writing for GEN8 PPGTT
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/30/2015 3:32 PM, Michel Thierry wrote:
The insert_entries function was the function used to write PTEs. For the
PPGTT it was "hardcoded" to only understand two level page tables, which
was the case for GEN7. We can reuse this for 4 level page tables, and
remove the concept of insert_entries, which was never viable past 2
level page tables anyway, but it requires a bit of rework to make the
function a bit more generic.
v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v3: Rebase after final merged version of Mika's ppgtt/scratch patches.
v4: Check and warn for NULL value of pdp pointer (Akash).
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 53 -
1 file changed, 41 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bd56979..740ad5b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -600,23 +600,23 @@ static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
return 0;
}
-static void gen8_ppgtt_clear_range(struct i915_address_space *vm,
- uint64_t start,
- uint64_t length,
- bool use_scratch)
+static void gen8_ppgtt_clear_pte_range(struct i915_address_space *vm,
+ struct i915_page_directory_pointer *pdp,
+ uint64_t start,
+ uint64_t length,
+ gen8_pte_t scratch_pte)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
- struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
- gen8_pte_t *pt_vaddr, scratch_pte;
+ gen8_pte_t *pt_vaddr;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
unsigned pte = start >> GEN8_PTE_SHIFT & GEN8_PTE_MASK;
unsigned num_entries = length >> PAGE_SHIFT;
unsigned last_pte, i;
- scratch_pte = gen8_pte_encode(px_dma(ppgtt->base.scratch_page),
- I915_CACHE_LLC, use_scratch);
+ if (WARN_ON(!pdp))
+ return;
while (num_entries) {
struct i915_page_directory *pd;
@@ -656,14 +656,30 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
}
}
-static void gen8_ppgtt_insert_entries(struct i915_address_space *vm,
- struct sg_table *pages,
- uint64_t start,
- enum i915_cache_level cache_level, u32
unused)
+static void gen8_ppgtt_clear_range(struct i915_address_space *vm,
+ uint64_t start,
+ uint64_t length,
+ bool use_scratch)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
+
+ gen8_pte_t scratch_pte = gen8_pte_encode(px_dma(vm->scratch_page),
+I915_CACHE_LLC, use_scratch);
+
+ gen8_ppgtt_clear_pte_range(vm, pdp, start, length, scratch_pte);
+}
+
+static void
+gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
+ struct i915_page_directory_pointer *pdp,
+ struct sg_table *pages,
+ uint64_t start,
+ enum i915_cache_level cache_level)
+{
+ struct i915_hw_ppgtt *ppgtt =
+ container_of(vm, struct i915_hw_ppgtt, base);
gen8_pte_t *pt_vaddr;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
@@ -700,6 +716,19 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
kunmap_px(ppgtt, pt_vaddr);
}
+static void gen8_ppgtt_insert_entries(struct i915_address_space *vm,
+ struct sg_table *pages,
+ uint64_t start,
+ enum i915_cache_level cache_level,
+ u32 unused)
+{
+ struct i915_hw_ppgtt *ppgtt =
+ container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
+
+ gen8_ppgtt_insert_pte_entries(vm, pdp, pages, start, cache_level);
+}
+
static void gen8_free_page_tables(struct drm_device *dev,
struct i915_page_directory *p
Re: [Intel-gfx] [PATCH v7 03/19] drm/i915/gen8: Abstract PDP usage
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/30/2015 3:32 PM, Michel Thierry wrote:
Up until now, ppgtt->pdp has always been the root of our page tables.
Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
In preparation for 4 level page tables, we need to stop using ppgtt->pdp
directly unless we know it's what we want. The future structure will use
ppgtt->pml4 for the top level, and the pdp is just one of the entries
being pointed to by a pml4e. The temporal pdp local variable will be
removed once the rest of the 4-level code lands.
Also, start passing the vm pointer to the alloc functions, instead of
ppgtt.
v2: Updated after dynamic page allocation changes.
v3: Rebase after s/page_tables/page_table/.
v4: Rebase after changes in "Dynamic page table allocations" patch.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rebase after final merged version of Mika's ppgtt/scratch patches.
v7: Keep pagetable map in-line (and avoid unnecessary for_each_pde
loops), remove redundant ppgtt pointer in _alloc_pagetabs (Akash)
v8: Fix text indentation in _alloc_pagetabs/page_directories (Chris)
v9: Defer gen8_alloc_va_range_4lvl definition until 4lvl is implemented,
clean-up gen8_ppgtt_cleanup [pun intended] (Akash).
v10: Clean-up commit message (Akash).
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 84 +++--
1 file changed, 44 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 28f3227..bd56979 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -607,6 +607,7 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
gen8_pte_t *pt_vaddr, scratch_pte;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
@@ -621,10 +622,10 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
struct i915_page_directory *pd;
struct i915_page_table *pt;
- if (WARN_ON(!ppgtt->pdp.page_directory[pdpe]))
+ if (WARN_ON(!pdp->page_directory[pdpe]))
break;
- pd = ppgtt->pdp.page_directory[pdpe];
+ pd = pdp->page_directory[pdpe];
if (WARN_ON(!pd->page_table[pde]))
break;
@@ -662,6 +663,7 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
gen8_pte_t *pt_vaddr;
unsigned pdpe = start >> GEN8_PDPE_SHIFT & GEN8_PDPE_MASK;
unsigned pde = start >> GEN8_PDE_SHIFT & GEN8_PDE_MASK;
@@ -675,7 +677,7 @@ static void gen8_ppgtt_insert_entries(struct
i915_address_space *vm,
break;
if (pt_vaddr == NULL) {
- struct i915_page_directory *pd =
ppgtt->pdp.page_directory[pdpe];
+ struct i915_page_directory *pd =
pdp->page_directory[pdpe];
struct i915_page_table *pt = pd->page_table[pde];
pt_vaddr = kmap_px(pt);
}
@@ -755,28 +757,29 @@ static void gen8_ppgtt_cleanup(struct i915_address_space
*vm)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
+ struct i915_page_directory_pointer *pdp = &ppgtt->pdp; /* FIXME: 48b */
+ struct drm_device *dev = ppgtt->base.dev;
int i;
- for_each_set_bit(i, ppgtt->pdp.used_pdpes,
-I915_PDPES_PER_PDP(ppgtt->base.dev)) {
- if (WARN_ON(!ppgtt->pdp.page_directory[i]))
+ for_each_set_bit(i, pdp->used_pdpes, I915_PDPES_PER_PDP(dev)) {
+ if (WARN_ON(!pdp->page_directory[i]))
continue;
- gen8_free_page_tables(ppgtt->base.dev,
- ppgtt->pdp.page_directory[i]);
- free_pd(ppgtt->base.dev, ppgtt->pdp.page_directory[i]);
+ gen8_free_page_tables(dev, pdp->page_directory[i]);
+ free_pd(dev, pdp->page_directory[i]);
}
- free_pdp(ppgtt->base.dev, &ppgtt->pdp);
+ free_pdp(dev, pdp);
+
gen8_free_scratch(vm);
}
/**
* gen8_ppgtt_alloc_pagetabs() - Allocate page tables for VA range.
- * @ppgtt: Master ppgtt structure.
- * @pd:Page directory for this address range.
+ * @vm:Master vm structure.
+ * @pd:Page directory for this address
Re: [Intel-gfx] [PATCH v7 07/19] drm/i915/gen8: implement alloc/free for 4lvl
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/30/2015 3:35 PM, Michel Thierry wrote:
PML4 has no special attributes, and there will always be a PML4.
So simply initialize it at creation, and destroy it at the end.
The code for 4lvl is able to call into the existing 3lvl page table code
to handle all of the lower levels.
v2: Return something at the end of gen8_alloc_va_range_4lvl to keep the
compiler happy. And define ret only in one place.
Updated gen8_ppgtt_unmap_pages and gen8_ppgtt_free to handle 4lvl.
v3: Use i915_dma_unmap_single instead of pci API. Fix a
couple of incorrect checks when unmapping pdp and pd pages (Akash).
v4: Call __pdp_fini also for 32b PPGTT. Clean up alloc_pdp param list.
v5: Prevent (harmless) out of range access in gen8_for_each_pml4e.
v6: Simplify alloc_vma_range_4lvl and gen8_ppgtt_init_common error
paths. (Akash)
v7: Rebase, s/gen8_ppgtt_free_*/gen8_ppgtt_cleanup_*/.
v8: Change location of pml4_init/fini. It will make next patches
cleaner.
v9: Rebase after Mika's ppgtt cleanup / scratch merge patch series, while
trying to reuse as much as possible for pdp alloc. pml4_init/fini
replaced by setup/cleanup_px macros.
v10: Rebase after Mika's merged ppgtt cleanup patch series.
v11: Rebase after final merged version of Mika's ppgtt/scratch
patches.
v12: Fix pdpe start value in trace (Akash)
v13: Define all 4lvl functions in this patch directly, instead of
previous patches, add i915_page_directory_pointer_entry_alloc here,
use test_bit to detect when pdp is already allocated (Akash).
v14: Move pdp allocation into a new gen8_ppgtt_alloc_page_dirpointers
funtion, as we do for pds and pts; move pd and pdp setup functions to
this patch (Akash).
v15: Added kfree(pdp) from previous patch to this (Akash).
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 239 +---
drivers/gpu/drm/i915/i915_gem_gtt.h | 15 ++-
drivers/gpu/drm/i915/i915_trace.h | 8 ++
3 files changed, 246 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3288154..c498eaa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -210,6 +210,9 @@ static gen8_pde_t gen8_pde_encode(const dma_addr_t addr,
return pde;
}
+#define gen8_pdpe_encode gen8_pde_encode
+#define gen8_pml4e_encode gen8_pde_encode
+
static gen6_pte_t snb_pte_encode(dma_addr_t addr,
enum i915_cache_level level,
bool valid, u32 unused)
@@ -559,10 +562,73 @@ static void __pdp_fini(struct i915_page_directory_pointer
*pdp)
pdp->page_directory = NULL;
}
+static struct
+i915_page_directory_pointer *alloc_pdp(struct drm_device *dev)
+{
+ struct i915_page_directory_pointer *pdp;
+ int ret = -ENOMEM;
+
+ WARN_ON(!USES_FULL_48BIT_PPGTT(dev));
+
+ pdp = kzalloc(sizeof(*pdp), GFP_KERNEL);
+ if (!pdp)
+ return ERR_PTR(-ENOMEM);
+
+ ret = __pdp_init(dev, pdp);
+ if (ret)
+ goto fail_bitmap;
+
+ ret = setup_px(dev, pdp);
+ if (ret)
+ goto fail_page_m;
+
+ return pdp;
+
+fail_page_m:
+ __pdp_fini(pdp);
+fail_bitmap:
+ kfree(pdp);
+
+ return ERR_PTR(ret);
+}
+
static void free_pdp(struct drm_device *dev,
struct i915_page_directory_pointer *pdp)
{
__pdp_fini(pdp);
+ if (USES_FULL_48BIT_PPGTT(dev)) {
+ cleanup_px(dev, pdp);
+ kfree(pdp);
+ }
+}
+
+static void
+gen8_setup_page_directory(struct i915_hw_ppgtt *ppgtt,
+ struct i915_page_directory_pointer *pdp,
+ struct i915_page_directory *pd,
+ int index)
+{
+ gen8_ppgtt_pdpe_t *page_directorypo;
+
+ if (!USES_FULL_48BIT_PPGTT(ppgtt->base.dev))
+ return;
+
+ page_directorypo = kmap_px(pdp);
+ page_directorypo[index] = gen8_pdpe_encode(px_dma(pd), I915_CACHE_LLC);
+ kunmap_px(ppgtt, page_directorypo);
+}
+
+static void
+gen8_setup_page_directory_pointer(struct i915_hw_ppgtt *ppgtt,
+ struct i915_pml4 *pml4,
+ struct i915_page_directory_pointer *pdp,
+ int index)
+{
+ gen8_ppgtt_pml4e_t *pagemap = kmap_px(pml4);
+
+ WARN_ON(!USES_FULL_48BIT_PPGTT(ppgtt->base.dev));
+ pagemap[index] = gen8_pml4e_encode(px_dma(pdp), I915_CACHE_LLC);
+ kunmap_px(ppgtt, pagemap);
}
/* Broadwell Page Directory Pointer Descriptors */
@@ -785,12 +851,9 @@ static void gen8_free_scratch(struct i915_address_space
*vm)
free_scratch_page(dev, vm->scratch_page);
}
-static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
+static void gen8_ppgtt_cleanup_3lvl(struct drm_device *de
Re: [Intel-gfx] [PATCH v7 08/19] drm/i915/gen8: Add 4 level switching infrastructure and lrc support
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/30/2015 3:36 PM, Michel Thierry wrote:
In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains
the base address to PML4, while the other PDP registers are ignored.
In LRC, the addressing mode must be specified in every context
descriptor, and the base address to PML4 is stored in the reg state.
v2: PML4 update in legacy context switch is left for historic reasons,
the preferred mode of operation is with lrc context based submission.
v3: s/gen8_map_page_directory/gen8_setup_page_directory and
s/gen8_map_page_directory_pointer/gen8_setup_page_directory_pointer.
Also, clflush will be needed for bxt. (Akash)
v4: Squashed lrc-specific code and use a macro to set PML4 register.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
PDP update in bb_start is only for legacy 32b mode.
v6: Rebase after final merged version of Mika's ppgtt/scratch
patches.
v7: There is no need to update the pml4 register value in
execlists_update_context. (Akash)
v8: Move pd and pdp setup functions to a previous patch, they do not
belong here. (Akash)
v9: Check USES_FULL_48BIT_PPGTT instead of GEN8_CTX_ADDRESSING_MODE in
gen8_emit_bb_start to check if emit pdps is needed. (Akash)
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 60 ++---
3 files changed, 55 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c498eaa..ae2e082 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -656,8 +656,8 @@ static int gen8_write_pdp(struct drm_i915_gem_request *req,
return 0;
}
-static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
- struct drm_i915_gem_request *req)
+static int gen8_legacy_mm_switch(struct i915_hw_ppgtt *ppgtt,
+struct drm_i915_gem_request *req)
{
int i, ret;
@@ -672,6 +672,12 @@ static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
return 0;
}
+static int gen8_48b_mm_switch(struct i915_hw_ppgtt *ppgtt,
+ struct drm_i915_gem_request *req)
+{
+ return gen8_write_pdp(req, 0, px_dma(&ppgtt->pml4));
+}
+
static void gen8_ppgtt_clear_pte_range(struct i915_address_space *vm,
struct i915_page_directory_pointer *pdp,
uint64_t start,
@@ -1321,14 +1327,13 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt->base.unbind_vma = ppgtt_unbind_vma;
ppgtt->base.bind_vma = ppgtt_bind_vma;
- ppgtt->switch_mm = gen8_mm_switch;
-
if (USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
ret = setup_px(ppgtt->base.dev, &ppgtt->pml4);
if (ret)
goto free_scratch;
ppgtt->base.total = 1ULL << 48;
+ ppgtt->switch_mm = gen8_48b_mm_switch;
} else {
ret = __pdp_init(false, &ppgtt->pdp);
if (ret)
@@ -1343,6 +1348,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
*/
ppgtt->base.total =
to_i915(ppgtt->base.dev)->gtt.base.total;
+ ppgtt->switch_mm = gen8_legacy_mm_switch;
trace_i915_page_directory_pointer_entry_alloc(&ppgtt->base,
0, 0,
GEN8_PML4E_SHIFT);
@@ -1540,8 +1546,9 @@ static void gen8_ppgtt_enable(struct drm_device *dev)
int j;
for_each_ring(ring, dev_priv, j) {
+ u32 four_level = USES_FULL_48BIT_PPGTT(dev) ?
GEN8_GFX_PPGTT_48B : 0;
I915_WRITE(RING_MODE_GEN7(ring),
- _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE));
+ _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE | four_level));
}
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3a77678..5bd1b6a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1670,6 +1670,7 @@ enum skl_disp_power_wells {
#define GFX_REPLAY_MODE (1<<11)
#define GFX_PSMI_GRANULARITY(1<<10)
#define GFX_PPGTT_ENABLE(1<<9)
+#define GEN8_GFX_PPGTT_48B (1<<7)
#define VLV_DISPLAY_BASE 0x18
#define VLV_MIPI_BASE VLV_DISPLAY_BASE
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 99bba8e..4c40614 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -196,13 +196,21 @@
reg_state[CTX_PDP ## n ## _LDW+1] = lower_32_bits(_addr); \
}
+#define ASSIGN_C
Re: [Intel-gfx] [PATCH v7 06/19] drm/i915/gen8: Add PML4 structure
On 7/30/2015 3:34 PM, Michel Thierry wrote:
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
v4: kfree the pdp until the 4lvl alloc/free patch (Akash).
Cc: Akash Goel
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 36 +++-
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
3 files changed, 46 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 04aa34a..4729eaf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2498,7 +2498,8 @@ struct drm_i915_cmd_table {
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 6)
#define HAS_LOGICAL_RING_CONTEXTS(dev)(INTEL_INFO(dev)->gen >= 8)
#define USES_PPGTT(dev) (i915.enable_ppgtt)
-#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt == 2)
+#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt >= 2)
+#define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
#define HAS_OVERLAY(dev) (INTEL_INFO(dev)->has_overlay)
#define OVERLAY_NEEDS_PHYSICAL(dev)
(INTEL_INFO(dev)->overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f71746..3288154 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -104,9 +104,12 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
{
bool has_aliasing_ppgtt;
bool has_full_ppgtt;
+ bool has_full_64bit_ppgtt;
has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
+ has_full_64bit_ppgtt = (IS_BROADWELL(dev) ||
+ INTEL_INFO(dev)->gen >= 9) && false; /* FIXME:
64b */
Sorry for the late comment.
Would it be better to move the changes done in this sanitize function to
the later patch only 'Flip the 48b switch' ?
As even with the removal of these changes, setting of enable_ppgtt to 3
would still be equivalent to the default mode (-1).
What is really needed now is the definition of 'USES_FULL_48BIT_PPGTT'
macro.
Best regards
Akash
if (intel_vgpu_active(dev))
has_full_ppgtt = false; /* emulation is too hard */
@@ -125,6 +128,9 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
if (enable_ppgtt == 2 && has_full_ppgtt)
return 2;
+ if (enable_ppgtt == 3 && has_full_64bit_ppgtt)
+ return 3;
+
#ifdef CONFIG_INTEL_IOMMU
/* Disable ppgtt on SNB if VT-d is on. */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) {
@@ -689,9 +695,6 @@ gen8_ppgtt_insert_pte_entries(struct i915_address_space *vm,
pt_vaddr = NULL;
for_each_sg_page(pages->sgl, &sg_iter, pages->nents, 0) {
- if (WARN_ON(pdpe >= GEN8_LEGACY_PDPES))
- break;
-
if (pt_vaddr == NULL) {
struct i915_page_directory *pd =
pdp->page_directory[pdpe];
struct i915_page_table *pt = pd->page_table[pde];
@@ -1105,14 +1108,6 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
return ret;
ppgtt->base.start = 0;
- ppgtt->base.total = 1ULL << 32;
- if (IS_ENABLED(CONFIG_X86_32))
- /* While we have a proliferation of size_t variables
-* we cannot represent the full ppgtt size on 32bit,
-* so limit it to the same size as the GGTT (currently
-* 2GiB).
-*/
- ppgtt->base.total = to_i915(ppgtt->base.dev)->gtt.base.total;
ppgtt->base.cleanup = gen8_ppgtt_cleanup;
ppgtt->base.allocate_va_range = gen8_alloc_va_range;
ppgtt->base.insert_entries = gen8_ppgtt_insert_entries;
@@ -1122,10 +1117,25 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt->switch_mm = gen8_mm_switch;
- ret = __pdp_init(false, &ppgtt->pdp);
+ if (!USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
+ ret = __pdp_init(false, &ppgtt->pdp);
- if (ret)
+ if (ret)
+ goto free_scratch;
+
+ ppgtt->base.total = 1ULL << 32;
+ if (IS_ENABLED(CONFIG_X86_32))
+ /* While we have a proliferation of size_t variables
+* we cannot represent the full ppgtt size on 32bit,
+* so limit it to the same size as the GGTT (currently
+* 2GiB).
+
[Intel-gfx] [PATCH] drm/i915: read bpp from vbt only for older panels
From: "Thulasimani,Sivakumar"
BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and read into display_info, hence bpp from
VBT will be used only when bpc in display_info is zero.
v2: use display_info.bpc for deciding when to use vbt_bpp (Jani)
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..ae00e86 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1409,7 +1409,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
* bpc in between. */
bpp = pipe_config->pipe_bpp;
if (is_edp(intel_dp)) {
- if (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp) {
+
+ /* Get bpp from vbt only for panels that dont have bpp in edid
*/
+ if (intel_connector->base.display_info.bpc == 0 &&
+ (dev_priv->vbt.edp_bpp && dev_priv->vbt.edp_bpp < bpp))
{
DRM_DEBUG_KMS("clamping bpp for eDP panel to
BIOS-provided %i\n",
dev_priv->vbt.edp_bpp);
bpp = dev_priv->vbt.edp_bpp;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] Revert "drm/i915: Add eDP intermediate frequencies for CHV"
From: "Thulasimani,Sivakumar"
This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä
Date: Thu Mar 12 17:10:38 2015 +0200
CHV does not support intermediate frequencies so reverting the
patch that added it in the first place
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..d9fb7a8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
27,
324000, 432000, 54 };
static const int skl_rates[] = { 162000, 216000, 27,
324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
static const int default_rates[] = { 162000, 27, 54 };
/**
@@ -1185,9 +1182,6 @@ intel_dp_source_rates(struct drm_device *dev, const int
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
- } else if (IS_CHERRYVIEW(dev)) {
- *source_rates = chv_rates;
- return ARRAY_SIZE(chv_rates);
}
*source_rates = default_rates;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: remove HBR2 from chv supported list
From: "Thulasimani,Sivakumar" This patch removes 5.4Gbps from supported link rate for CHV since it is not supported in it. Signed-off-by: Sivakumar Thulasimani --- drivers/gpu/drm/i915/intel_dp.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index d9fb7a8..4e53433 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1186,8 +1186,9 @@ intel_dp_source_rates(struct drm_device *dev, const int **source_rates) *source_rates = default_rates; - if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) - /* WaDisableHBR2:skl */ + /* WaDisableHBR2:skl */ + if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) || + IS_CHERRYVIEW(dev)) return (DP_LINK_BW_2_7 >> 3) + 1; else if (INTEL_INFO(dev)->gen >= 8 || (IS_HASWELL(dev) && !IS_HSW_ULX(dev))) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
