[Intel-gfx] [RFC PATCH v4 0/7] Add support for Legacy HDMI audio drivers
Legacy (CherryTrail/ Baytrail) HDMI audio drivers added Legacy hdmi audio-Gfx interaction/ interfacing is updated to use irq chip framework Jerome Anand (7): drm/i915: setup bridge for HDMI LPE audio driver drm/i915: Add support for audio driver notifications ALSA: add shell for Intel HDMI LPE audio driver ALSA: x86: hdmi: Add audio support for BYT and CHT ALSA: x86: hdmi: Improve position reporting ALSA: x86: hdmi: Fixup some monitor ALSA: x86: hdmi: continue playback even when display resolution changes Documentation/gpu/i915.rst |9 + drivers/gpu/drm/i915/Makefile |3 + drivers/gpu/drm/i915/i915_drv.c|8 +- drivers/gpu/drm/i915/i915_drv.h| 18 + drivers/gpu/drm/i915/i915_irq.c| 27 + drivers/gpu/drm/i915/i915_reg.h|3 + drivers/gpu/drm/i915/intel_audio.c |8 + drivers/gpu/drm/i915/intel_hdmi.c |1 + drivers/gpu/drm/i915/intel_lpe_audio.c | 409 +++ include/drm/intel_lpe_audio.h | 46 + sound/Kconfig |2 + sound/Makefile |2 +- sound/x86/Kconfig | 16 + sound/x86/Makefile | 10 + sound/x86/intel_hdmi_audio.c | 1932 sound/x86/intel_hdmi_audio.h | 201 sound/x86/intel_hdmi_audio_if.c| 551 + sound/x86/intel_hdmi_lpe_audio.c | 626 +++ sound/x86/intel_hdmi_lpe_audio.h | 692 19 files changed, 4561 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_lpe_audio.c create mode 100644 include/drm/intel_lpe_audio.h create mode 100644 sound/x86/Kconfig create mode 100644 sound/x86/Makefile create mode 100644 sound/x86/intel_hdmi_audio.c create mode 100644 sound/x86/intel_hdmi_audio.h create mode 100644 sound/x86/intel_hdmi_audio_if.c create mode 100644 sound/x86/intel_hdmi_lpe_audio.c create mode 100644 sound/x86/intel_hdmi_lpe_audio.h -- 2.9.3 base-commit: b34f27e00c9a21d2078062da760e24fd4a620391 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
On Thu, Dec 01, 2016 at 05:18:00PM +, Robert Bragg wrote:
> I'm currently considering the use of DRM_ERROR in i915 perf for steam
> config validation errors (i.e. userspace misconfigurations) that should
> be changed so that i-g-t tests aren't treated as failures when
> triggering these.
>
> I initially proposed changing these to DRM_INFO messages and
> intentionally wanted to avoid DRM_DEBUG since in my limited experience
> DRM_DEBUG messages aren't practical to work with.
>
> I thought I'd see if DRM_DEBUG could be updated to have a bit more fine
> grained control in case that might help sway my view.
>
> Tbh, although I think something like this could be nice to have, I'm
> still not really convinced that debug messages are a great fit for
> helping userspace developers hitting EINVAL errors. Such developers
> don't need to be drm/i915 developers and imho shouldn't be expected to
> know of the existence of optional debug messages, and if you don't know
> of there existence then the control interface isn't important and they
> won't help anyone.
Sounds like we'd need a bit more documentation in drm-uapi.rst ;-) We
really can't spam dmesg by default for userspace fail, e.g. if you open a
file that isn't there dmesg also doesn't tell you what exactly went wrong
(e.g. which directory in your path it couldn't find).
But I wanted to trick someone into looking into dynamic debugging since
forever, since the current drm.debug firehose is indeed unmanageable by
default. So I very much like the idea you're pushing for here.
But needs to be discussed on dri-devel, pls resubmit with that on cc.
> --- >8 --- (git am --scissors)
;-)
Cheers, Daniel
>
> Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt)
> allow fine grained control over which debug messages are enabled with
> runtime control through /sysfs/kernel/debug/dynamic_debug/control
>
> This provides more control than the current drm.drm_debug parameter
> which for some use cases is impractical to use given how chatty
> some drm debug categories are.
>
> For example all debug messages in i915_drm.c can be enabled with:
> echo "file i915_perf.c +p" > dynamic_debug/control
>
> This aims to maintain compatibility with controlling debug messages
> using the drm_debug parameter. The new dynamic debug macros are called
> by default but conditionally calling [dev_]printk if the category flag
> is set (side stepping the dynamic debug condition in that case)
>
> This removes the drm_[dev_]printk wrappers considering that the dynamic
> debug macros are only useful if they can track the __FILE__, __func__
> and __LINE__ where they are called. The wrapper didn't seem necessary in
> the DRM_UT_NONE case with no category flag.
>
> The output format should be compatible, unless the _DEV macros are
> passed a NULL dev pointer considering how the core.c dev_printk
> implementation adds "(NULL device *)" to the message in that case while
> the drm wrapper would fallback to a plain printk in this case.
> Previously some of non-dev drm debug macros were defined in terms of
> passing NULL to a dev version but that's avoided now due to this
> difference.
>
> I haven't so far looked to see what affect these have on linked object
> sizes.
>
> Signed-off-by: Robert Bragg
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/drm_drv.c | 47 -
> include/drm/drmP.h| 168
> +-
> 2 files changed, 108 insertions(+), 107 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index cc6c253..5b2dbcd 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -65,53 +65,6 @@ static struct idr drm_minors_idr;
>
> static struct dentry *drm_debugfs_root;
>
> -#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
> -
> -void drm_dev_printk(const struct device *dev, const char *level,
> - unsigned int category, const char *function_name,
> - const char *prefix, const char *format, ...)
> -{
> - struct va_format vaf;
> - va_list args;
> -
> - if (category != DRM_UT_NONE && !(drm_debug & category))
> - return;
> -
> - va_start(args, format);
> - vaf.fmt = format;
> - vaf.va = &args;
> -
> - if (dev)
> - dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
> -&vaf);
> - else
> - printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
> -
> - va_end(args);
> -}
> -EXPORT_SYMBOL(drm_dev_printk);
> -
> -void drm_printk(const char *level, unsigned int category,
> - const char *format, ...)
> -{
> - struct va_format vaf;
> - va_list args;
> -
> - if (category != DRM_UT_NONE && !(drm_debug & category))
> - return;
> -
> - va_start(args, format);
> - vaf.fmt = format;
> - vaf.va = &args;
> -
> - printk("%s" "[" DRM_NAME ":%ps]%s %pV",
> -level, __builtin_ret
[Intel-gfx] [RFC PATCH v4 1/7] drm/i915: setup bridge for HDMI LPE audio driver
Enable support for HDMI LPE audio mode on Baytrail and
Cherrytrail when HDaudio controller is not detected
Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward HDMI LPE audio irqs.
HDMI LPE audio driver (a standalone sound driver) probes the
LPE audio device and creates a new sound card.
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Jerome Anand
---
Documentation/gpu/i915.rst | 9 +
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_drv.c| 8 +-
drivers/gpu/drm/i915/i915_drv.h| 15 ++
drivers/gpu/drm/i915/i915_irq.c| 27 +++
drivers/gpu/drm/i915/i915_reg.h| 3 +
drivers/gpu/drm/i915/intel_lpe_audio.c | 363 +
include/drm/intel_lpe_audio.h | 45
8 files changed, 471 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_lpe_audio.c
create mode 100644 include/drm/intel_lpe_audio.h
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 117d2ab..a671eee 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -213,6 +213,15 @@ Video BIOS Table (VBT)
.. kernel-doc:: drivers/gpu/drm/i915/intel_vbt_defs.h
:internal:
+intel hdmi lpe audio support
+
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_lpe_audio.c
+ :doc: LPE Audio integration for HDMI or DP playback
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_lpe_audio.c
+ :internal:
+
Memory Management and Command Submission
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 580602d..3a2369c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -126,6 +126,9 @@ i915-y += intel_gvt.o
include $(src)/gvt/Makefile
endif
+# LPE Audio for VLV and CHT
+i915-y += intel_lpe_audio.o
+
obj-$(CONFIG_DRM_I915) += i915.o
CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b893e67..93811ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1144,7 +1144,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
if (IS_GEN5(dev_priv))
intel_gpu_ips_init(dev_priv);
- i915_audio_component_init(dev_priv);
+ if (intel_lpe_audio_init(dev_priv) < 0)
+ i915_audio_component_init(dev_priv);
/*
* Some ports require correctly set-up hpd registers for detection to
@@ -1162,7 +1163,10 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
- i915_audio_component_cleanup(dev_priv);
+ if (HAS_LPE_AUDIO(dev_priv))
+ intel_lpe_audio_teardown(dev_priv);
+ else
+ i915_audio_component_cleanup(dev_priv);
intel_gpu_ips_teardown();
acpi_video_unregister();
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 970e50b..2a79048 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2284,6 +2284,12 @@ struct drm_i915_private {
/* Used to save the pipe-to-encoder mapping for audio */
struct intel_encoder *av_enc_map[I915_MAX_PIPES];
+ /* necessary resource sharing with HDMI LPE audio driver. */
+ struct {
+ struct platform_device *platdev;
+ int irq;
+ } lpe_audio;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
@@ -2773,6 +2779,8 @@ intel_info(const struct drm_i915_private *dev_priv)
#define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
+#define HAS_LPE_AUDIO(dev_priv) ((dev_priv)->lpe_audio.platdev != NULL)
+
#define INTEL_PCH_DEVICE_ID_MASK 0xff00
#define INTEL_PCH_IBX_DEVICE_ID_TYPE 0x3b00
#define INTEL_PCH_CPT_DEVICE_ID_TYPE 0x1c00
@@ -3547,6 +3555,13 @@ extern int i915_restore_state(struct drm_device *dev);
void i915_setup_sysfs(struct drm_i915_private *dev_priv);
void i915_teardown_sysfs(struct drm_i915_private *dev_priv);
+/* i915_lpe_audio.c */
+int intel_lpe_audio_init(struct drm_i915_private *dev_priv);
+int intel_lpe_audio_setup(struct drm_i915_private *dev_priv);
+void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv);
+void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv);
+bool intel_lpe_audio_detect(struct drm_i915_private *dev_priv);
+
/* intel_i2c.c */
extern int intel_setup_gmbus(struct drm_device *dev);
extern void intel_teardown_gmbus(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i
[Intel-gfx] [RFC PATCH v4 2/7] drm/i915: Add support for audio driver notifications
Notifiations like mode change, hot plug and edid to
the audio driver are added. This is inturn used by the
audio driver for its functionality.
A new interface file capturing the notifications needed by the
audio driver is added
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Jerome Anand
---
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm/i915/intel_audio.c | 8 ++
drivers/gpu/drm/i915/intel_hdmi.c | 1 +
drivers/gpu/drm/i915/intel_lpe_audio.c | 46 ++
include/drm/intel_lpe_audio.h | 1 +
5 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2a79048..33bc44c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3561,6 +3561,9 @@ int intel_lpe_audio_setup(struct drm_i915_private
*dev_priv);
void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv);
void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv);
bool intel_lpe_audio_detect(struct drm_i915_private *dev_priv);
+void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
+ void *eld, int port, int tmds_clk_speed,
+ bool connected);
/* intel_i2c.c */
extern int intel_setup_gmbus(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 1c509f7..55a6831 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include
@@ -627,6 +628,10 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder,
if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
+
+ if (HAS_LPE_AUDIO(dev_priv))
+ intel_lpe_audio_notify(dev_priv, connector->eld, port,
+ crtc_state->port_clock, true);
}
/**
@@ -660,6 +665,9 @@ void intel_audio_codec_disable(struct intel_encoder
*intel_encoder)
if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
+
+ if (HAS_LPE_AUDIO(dev_priv))
+ intel_lpe_audio_notify(dev_priv, NULL, port, 0, true);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index fb88e32..02d50e3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -36,6 +36,7 @@
#include
#include "intel_drv.h"
#include
+#include
#include "i915_drv.h"
static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi *intel_hdmi)
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index e12e5f7..a141a9c 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -361,3 +361,49 @@ void intel_lpe_audio_teardown(struct drm_i915_private
*dev_priv)
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
}
+
+
+/**
+ * intel_lpe_audio_notify() - notify lpe audio event
+ * audio driver and i915
+ * @dev_priv: the i915 drm device private data
+ * @eld : ELD data
+ * @port: port id
+ * @tmds_clk_speed: tmds clock frequency in Hz
+ * @connected: hdmi connected/disconnected
+ *
+ * Notify lpe audio driver of eld change.
+ */
+void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
+ void *eld, int port, int tmds_clk_speed,
+ bool connected)
+{
+ unsigned long irq_flags;
+
+ if (HAS_LPE_AUDIO(dev_priv)) {
+ struct intel_hdmi_lpe_audio_pdata *pdata = dev_get_platdata(
+ &(dev_priv->lpe_audio.platdev->dev));
+
+ spin_lock_irqsave(&pdata->lpe_audio_slock,
+ irq_flags);
+
+ if (eld != NULL) {
+ memcpy(pdata->eld.eld_data, eld,
+ HDMI_MAX_ELD_BYTES);
+ pdata->eld.port_id = port;
+
+ if (tmds_clk_speed)
+ pdata->tmds_clock_speed =
+ tmds_clk_speed;
+ }
+ pdata->hdmi_connected = connected;
+ if (pdata->notify_audio_lpe)
+ pdata->notify_audio_lpe(
+ (eld != NULL) ? &pdata->eld : NULL);
+ else
+ pdata->notify_pending = true;
+
+ spin_unlock_irqrestore(&pdata->lpe_audio_slock,
+ irq_flags);
+ }
+}
diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h
index a64c449..952de05 100644
--- a/include/drm/i
[Intel-gfx] [RFC PATCH v4 4/7] ALSA: x86: hdmi: Add audio support for BYT and CHT
Hdmi audio driver based on the child platform device
created by gfx driver is implemented.
This audio driver is derived from legacy intel
hdmi audio driver.
The interfaces for interaction between gfx and audio
are updated and the driver implementation updated to
derive interrupts in its own address space based on
irq chip framework
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Jerome Anand
---
sound/x86/Makefile |2 +
sound/x86/intel_hdmi_audio.c | 1907 ++
sound/x86/intel_hdmi_audio.h | 201
sound/x86/intel_hdmi_audio_if.c | 551 +++
sound/x86/intel_hdmi_lpe_audio.c | 16 +-
5 files changed, 2671 insertions(+), 6 deletions(-)
create mode 100644 sound/x86/intel_hdmi_audio.c
create mode 100644 sound/x86/intel_hdmi_audio.h
create mode 100644 sound/x86/intel_hdmi_audio_if.c
diff --git a/sound/x86/Makefile b/sound/x86/Makefile
index 78b2ae1..bc074d0 100644
--- a/sound/x86/Makefile
+++ b/sound/x86/Makefile
@@ -3,6 +3,8 @@ DRIVER_NAME := hdmi_lpe_audio
ccflags-y += -Idrivers/gpu/drm/i915
$(DRIVER_NAME)-objs += \
+ intel_hdmi_audio.o \
+ intel_hdmi_audio_if.o \
intel_hdmi_lpe_audio.o
obj-$(CONFIG_HDMI_LPE_AUDIO) += $(DRIVER_NAME).o
diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c
new file mode 100644
index 000..461b7d7
--- /dev/null
+++ b/sound/x86/intel_hdmi_audio.c
@@ -0,0 +1,1907 @@
+/*
+ * intel_hdmi_audio.c - Intel HDMI audio driver
+ *
+ * Copyright (C) 2016 Intel Corp
+ * Authors: Sailaja Bandarupalli
+ * Ramesh Babu K V
+ * Vaibhav Agarwal
+ * Jerome Anand
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * ~~
+ * ALSA driver for Intel HDMI audio
+ */
+
+#define pr_fmt(fmt)"had: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_hdmi_audio.h"
+
+static DEFINE_MUTEX(had_mutex);
+
+/*standard module options for ALSA. This module supports only one card*/
+static int hdmi_card_index = SNDRV_DEFAULT_IDX1;
+static char *hdmi_card_id = SNDRV_DEFAULT_STR1;
+static struct snd_intelhad *had_data;
+
+module_param(hdmi_card_index, int, 0444);
+MODULE_PARM_DESC(hdmi_card_index,
+ "Index value for INTEL Intel HDMI Audio controller.");
+module_param(hdmi_card_id, charp, 0444);
+MODULE_PARM_DESC(hdmi_card_id,
+ "ID string for INTEL Intel HDMI Audio controller.");
+
+/*
+ * ELD SA bits in the CEA Speaker Allocation data block
+*/
+static int eld_speaker_allocation_bits[] = {
+ [0] = FL | FR,
+ [1] = LFE,
+ [2] = FC,
+ [3] = RL | RR,
+ [4] = RC,
+ [5] = FLC | FRC,
+ [6] = RLC | RRC,
+ /* the following are not defined in ELD yet */
+ [7] = 0,
+};
+
+/*
+ * This is an ordered list!
+ *
+ * The preceding ones have better chances to be selected by
+ * hdmi_channel_allocation().
+ */
+static struct cea_channel_speaker_allocation channel_allocations[] = {
+/*channel: 7 6543 210 */
+{ .ca_index = 0x00, .speakers = { 0,0, 0, 0, 0,0, FR, FL }
},
+ /* 2.1 */
+{ .ca_index = 0x01, .speakers = { 0,0, 0, 0, 0, LFE, FR, FL }
},
+ /* Dolby Surround */
+{ .ca_index = 0x02, .speakers = { 0,0, 0, 0, FC,0, FR, FL }
},
+ /* surround40 */
+{ .ca_index = 0x08, .speakers = { 0,0, RR, RL, 0,0, FR, FL }
},
+ /* surround41 */
+{ .ca_index = 0x09, .speakers = { 0,0, RR, RL, 0, LFE, FR, FL }
},
+ /* surround50 */
+{ .ca_index = 0x0a, .speakers = { 0,0, RR, RL, FC,0, FR, FL }
},
+ /* surround51 */
+{ .ca_index = 0x0b, .speakers = { 0,0, RR, RL, FC, LFE, FR, FL }
},
+ /* 6.1 */
+{ .ca_index = 0x0f, .speakers = { 0, RC, RR, RL, FC, LFE, FR, FL }
},
+ /* surround71 */
+{ .ca_index = 0x13, .speakers = { RRC, RLC, RR, RL, FC, LFE, FR, FL }
},
+
+{ .ca_index = 0x03, .speakers = { 0,0, 0, 0, FC, LFE, FR, FL }
},
+{ .ca_index = 0x04, .speakers = { 0,0, 0, RC,
[Intel-gfx] [RFC PATCH v4 3/7] ALSA: add shell for Intel HDMI LPE audio driver
On Baytrail and Cherrytrail, HDaudio may be fused out or disabled
by the BIOS. This driver enables an alternate path to the i915
display registers and DMA.
Although there is no hardware path between i915 display and LPE/SST
audio clusters, this HDMI capability is referred to in the documentation
as "HDMI LPE Audio" so we keep the name for consistency. There is no
hardware path or control dependencies with the LPE/SST DSP functionality.
The hdmi-lpe-audio driver will be probed when the i915 driver creates
a child platform device.
Since this driver is neither SoC nor PCI, a new x86 folder is added
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Jerome Anand
---
sound/Kconfig| 2 +
sound/Makefile | 2 +-
sound/x86/Kconfig| 16 +
sound/x86/Makefile | 8 +
sound/x86/intel_hdmi_lpe_audio.c | 622 +++
sound/x86/intel_hdmi_lpe_audio.h | 692 +++
6 files changed, 1341 insertions(+), 1 deletion(-)
create mode 100644 sound/x86/Kconfig
create mode 100644 sound/x86/Makefile
create mode 100644 sound/x86/intel_hdmi_lpe_audio.c
create mode 100644 sound/x86/intel_hdmi_lpe_audio.h
diff --git a/sound/Kconfig b/sound/Kconfig
index 5a240e0..ee2e69a 100644
--- a/sound/Kconfig
+++ b/sound/Kconfig
@@ -108,6 +108,8 @@ source "sound/parisc/Kconfig"
source "sound/soc/Kconfig"
+source "sound/x86/Kconfig"
+
endif # SND
menuconfig SOUND_PRIME
diff --git a/sound/Makefile b/sound/Makefile
index c41bdf5..6de45d2 100644
--- a/sound/Makefile
+++ b/sound/Makefile
@@ -5,7 +5,7 @@ obj-$(CONFIG_SOUND) += soundcore.o
obj-$(CONFIG_SOUND_PRIME) += oss/
obj-$(CONFIG_DMASOUND) += oss/
obj-$(CONFIG_SND) += core/ i2c/ drivers/ isa/ pci/ ppc/ arm/ sh/ synth/ usb/ \
- firewire/ sparc/ spi/ parisc/ pcmcia/ mips/ soc/ atmel/ hda/
+ firewire/ sparc/ spi/ parisc/ pcmcia/ mips/ soc/ atmel/ hda/ x86/
obj-$(CONFIG_SND_AOA) += aoa/
# This one must be compilable even if sound is configured out
diff --git a/sound/x86/Kconfig b/sound/x86/Kconfig
new file mode 100644
index 000..182adf3
--- /dev/null
+++ b/sound/x86/Kconfig
@@ -0,0 +1,16 @@
+menuconfig SND_X86
+ tristate "X86 sound devices"
+ ---help---
+
+ X86 sound devices that don't fall under SoC or PCI categories
+
+if SND_X86
+
+config HDMI_LPE_AUDIO
+ tristate "HDMI audio without HDaudio on Intel Atom platforms"
+ depends on DRM_I915
+default n
+help
+ Choose this option to support HDMI LPE Audio mode
+
+endif # SND_X86
diff --git a/sound/x86/Makefile b/sound/x86/Makefile
new file mode 100644
index 000..78b2ae1
--- /dev/null
+++ b/sound/x86/Makefile
@@ -0,0 +1,8 @@
+DRIVER_NAME := hdmi_lpe_audio
+
+ccflags-y += -Idrivers/gpu/drm/i915
+
+$(DRIVER_NAME)-objs += \
+ intel_hdmi_lpe_audio.o
+
+obj-$(CONFIG_HDMI_LPE_AUDIO) += $(DRIVER_NAME).o
diff --git a/sound/x86/intel_hdmi_lpe_audio.c b/sound/x86/intel_hdmi_lpe_audio.c
new file mode 100644
index 000..f31ab72
--- /dev/null
+++ b/sound/x86/intel_hdmi_lpe_audio.c
@@ -0,0 +1,622 @@
+/*
+ * intel_hdmi_lpe_audio.c - Intel HDMI LPE audio driver for Atom platforms
+ *
+ * Copyright (C) 2016 Intel Corp
+ * Authors:
+ * Jerome Anand
+ * Aravind Siddappaji
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * ~~
+ */
+
+#define pr_fmt(fmt)"hdmi_lpe_audio: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "intel_hdmi_lpe_audio.h"
+
+/* globals*/
+struct platform_device *gpdev;
+int _hdmi_state;
+union otm_hdmi_eld_t hdmi_eld;
+
+struct hdmi_lpe_audio_ctx {
+ int irq;
+ void __iomem *mmio_start;
+ had_event_call_back had_event_callbacks;
+ struct snd_intel_had_interface *had_interface;
+ void *had_pvt_data;
+ int tmds_clock_speed;
+ unsigned int had_config_offset;
+ int hdmi_audio_interrupt_mask;
+ struct work_struct hdmi_audio_wq;
+};
+
+static inline void hdmi_set_eld(void *eld)
+{
+ int size = (sizeof(hdmi_eld)) > HDMI_MAX_ELD_BYTES ?
+ HDMI_MAX_ELD_BYTES :
+ (sizeof(hdmi_eld));
+
+ memcpy((void *)&hdmi_eld, eld, size);
+}
+
+static inline int hdmi_get_eld(void *eld)
+{
+
[Intel-gfx] [RFC PATCH v4 5/7] ALSA: x86: hdmi: Improve position reporting
Use a hw register to calculate sub-period position reports.
This makes PulseAudio happier.
Signed-off-by: David Henningsson
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Jerome Anand
---
sound/x86/intel_hdmi_audio.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c
index 461b7d7..d9ce750 100644
--- a/sound/x86/intel_hdmi_audio.c
+++ b/sound/x86/intel_hdmi_audio.c
@@ -1492,6 +1492,8 @@ static snd_pcm_uframes_t snd_intelhad_pcm_pointer(
{
struct snd_intelhad *intelhaddata;
u32 bytes_rendered = 0;
+ u32 t;
+ int buf_id;
/* pr_debug("snd_intelhad_pcm_pointer called\n"); */
@@ -1502,6 +1504,14 @@ static snd_pcm_uframes_t snd_intelhad_pcm_pointer(
return SNDRV_PCM_POS_XRUN;
}
+ buf_id = intelhaddata->curr_buf % 4;
+ had_read_register(AUD_BUF_A_LENGTH + (buf_id * HAD_REG_WIDTH), &t);
+ if (t == 0) {
+ pr_debug("discovered buffer done for buf %d\n", buf_id);
+ /* had_process_buffer_done(intelhaddata); */
+ }
+ t = intelhaddata->buf_info[buf_id].buf_size - t;
+
if (intelhaddata->stream_info.buffer_rendered)
div_u64_rem(intelhaddata->stream_info.buffer_rendered,
intelhaddata->stream_info.ring_buf_size,
@@ -1509,7 +1519,7 @@ static snd_pcm_uframes_t snd_intelhad_pcm_pointer(
intelhaddata->stream_info.buffer_ptr = bytes_to_frames(
substream->runtime,
- bytes_rendered);
+ bytes_rendered + t);
return intelhaddata->stream_info.buffer_ptr;
}
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH v4 6/7] ALSA: x86: hdmi: Fixup some monitor
This change was given to Canonical apparently to fix an issue with
on some monitor brand. It's not clear what this patch does but it doesn't
seem to have side effects.
Signed-off-by: David Henningsson
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Jerome Anand
---
sound/x86/intel_hdmi_audio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c
index d9ce750..9249521 100644
--- a/sound/x86/intel_hdmi_audio.c
+++ b/sound/x86/intel_hdmi_audio.c
@@ -337,6 +337,7 @@ static void snd_intelhad_reset_audio_v2(u8 reset)
static int had_prog_status_reg(struct snd_pcm_substream *substream,
struct snd_intelhad *intelhaddata)
{
+ union aud_cfg cfg_val = {.cfg_regval = 0};
union aud_ch_status_0 ch_stat0 = {.status_0_regval = 0};
union aud_ch_status_1 ch_stat1 = {.status_1_regval = 0};
int format;
@@ -347,6 +348,7 @@ static int had_prog_status_reg(struct snd_pcm_substream
*substream,
IEC958_AES0_NONAUDIO)>>1;
ch_stat0.status_0_regx.clk_acc = (intelhaddata->aes_bits &
IEC958_AES3_CON_CLOCK)>>4;
+ cfg_val.cfg_regx.val_bit = ch_stat0.status_0_regx.lpcm_id;
switch (substream->runtime->rate) {
case AUD_SAMPLE_RATE_32:
@@ -426,7 +428,6 @@ int snd_intelhad_prog_audio_ctrl_v2(struct
snd_pcm_substream *substream,
else
cfg_val.cfg_regx_v2.layout = LAYOUT1;
- cfg_val.cfg_regx_v2.val_bit = 1;
had_write_register(AUD_CONFIG, cfg_val.cfg_regval);
return 0;
}
@@ -482,7 +483,6 @@ int snd_intelhad_prog_audio_ctrl_v1(struct
snd_pcm_substream *substream,
}
- cfg_val.cfg_regx.val_bit = 1;
had_write_register(AUD_CONFIG, cfg_val.cfg_regval);
return 0;
}
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH v4 7/7] ALSA: x86: hdmi: continue playback even when display resolution changes
When the display resolution changes, the drm disables the
display pipes due to which audio rendering stops. At this
time, we need to ensure the existing audio pointers and
buffers are cleared out so that the playback can restarted
once the display pipe is enabled with a different N/CTS values
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Jerome Anand
---
sound/x86/intel_hdmi_audio.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c
index 9249521..d6fd638 100644
--- a/sound/x86/intel_hdmi_audio.c
+++ b/sound/x86/intel_hdmi_audio.c
@@ -43,6 +43,7 @@ static DEFINE_MUTEX(had_mutex);
static int hdmi_card_index = SNDRV_DEFAULT_IDX1;
static char *hdmi_card_id = SNDRV_DEFAULT_STR1;
static struct snd_intelhad *had_data;
+static int underrun_count;
module_param(hdmi_card_index, int, 0444);
MODULE_PARM_DESC(hdmi_card_index,
@@ -1114,6 +1115,7 @@ static int snd_intelhad_open(struct snd_pcm_substream
*substream)
intelhaddata = snd_pcm_substream_chip(substream);
had_stream = intelhaddata->private_data;
runtime = substream->runtime;
+ underrun_count = 0;
pm_runtime_get(intelhaddata->dev);
@@ -1506,10 +1508,23 @@ static snd_pcm_uframes_t snd_intelhad_pcm_pointer(
buf_id = intelhaddata->curr_buf % 4;
had_read_register(AUD_BUF_A_LENGTH + (buf_id * HAD_REG_WIDTH), &t);
- if (t == 0) {
- pr_debug("discovered buffer done for buf %d\n", buf_id);
- /* had_process_buffer_done(intelhaddata); */
+
+ if ((t == 0) || (t == ((u32)-1L))) {
+ underrun_count++;
+ pr_debug("discovered buffer done for buf %d, count = %d\n",
+ buf_id, underrun_count);
+
+ if (underrun_count > (HAD_MIN_PERIODS/2)) {
+ pr_debug("assume audio_codec_reset, underrun = %d - do
xrun\n",
+ underrun_count);
+ underrun_count = 0;
+ return SNDRV_PCM_POS_XRUN;
+ }
+ } else {
+ /* Reset Counter */
+ underrun_count = 0;
}
+
t = intelhaddata->buf_info[buf_id].buf_size - t;
if (intelhaddata->stream_info.buffer_rendered)
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/15] drm/i915/glk: Force DDI initialization.
On Thu, 2016-12-01 at 16:52 -0800, Rodrigo Vivi wrote:
> This could also be squashed or reviewed-by you...
> either works for me, I just cannot review the patch that I'm listed as author
> ;)
I had a vague recollection of editing this patch, hence why I didn't add my own
R-b. But it was just a rebase, so
Reviewed-by: Ander Conselvan de Oliveira
But I'll squash this into the patch 5.
Ander
> On Thu, Nov 10, 2016 at 05:23:11PM +0200, Ander Conselvan de Oliveira wrote:
> >
> > From: Rodrigo Vivi
> >
> > As for BXT, GLK doesn't support port detection through SFUSE_STRAP, so
> > let's force DDI initialization in order to get HDMI and DP.
> >
> > v2: Use dev_priv instead of dev. (Tvrtko)
> > Signed-off-by: Rodrigo Vivi
> > Signed-off-by: Ander Conselvan de Oliveira > l.com>
> > ---
> > 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 c6ffe0a..4069a6e 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15491,7 +15491,7 @@ static void intel_setup_outputs(struct drm_device
> > *dev)
> > if (intel_crt_present(dev))
> > intel_crt_init(dev);
> >
> > - if (IS_BROXTON(dev_priv)) {
> > + if (IS_GEN9_LP(dev_priv)) {
> > /*
> > * FIXME: Broxton doesn't support port detection via the
> > * DDI_BUF_CTL_A or SFUSE_STRAP registers, find another way
> > to
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/9] Geminilake enabling
Remaining glk enabling patches, with some of the patches squashed. All have R-bs already. Ander Conselvan de Oliveira (8): drm/i915/glk: Reuse broxton code for geminilake drm/i915/glk: Add power wells for Geminilake drm/i915/glk: Implement Geminilake DDI init sequence drm/i915/glk: Set DCC delay range 2 in PLL enable sequence drm/i915/glk: Reuse broxton's cdclk code for GLK drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilake drm/i915/glk: Implement core display init/uninit sequence for geminilake drm/i915/glk: Configure number of sprite planes properly Madhav Chauhan (1): drm/i915/glk: Update Port PLL enable sequence for Geminilkae drivers/gpu/drm/i915/i915_debugfs.c | 10 +- drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +- drivers/gpu/drm/i915/i915_irq.c | 10 +- drivers/gpu/drm/i915/i915_reg.h | 44 +++-- drivers/gpu/drm/i915/intel_bios.c| 2 +- drivers/gpu/drm/i915/intel_ddi.c | 26 ++--- drivers/gpu/drm/i915/intel_device_info.c | 5 +- drivers/gpu/drm/i915/intel_display.c | 93 ++ drivers/gpu/drm/i915/intel_dp.c | 24 ++--- drivers/gpu/drm/i915/intel_dpio_phy.c| 115 +++--- drivers/gpu/drm/i915/intel_dpll_mgr.c| 32 +- drivers/gpu/drm/i915/intel_dsi.c | 30 +++--- drivers/gpu/drm/i915/intel_dsi_pll.c | 12 +-- drivers/gpu/drm/i915/intel_hdmi.c| 6 +- drivers/gpu/drm/i915/intel_i2c.c | 4 +- drivers/gpu/drm/i915/intel_mocs.c| 2 +- drivers/gpu/drm/i915/intel_panel.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 6 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 163 +-- 20 files changed, 474 insertions(+), 125 deletions(-) -- 2.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915/glk: Implement core display init/uninit sequence for geminilake
The sequence is pretty much the same as broxton, except that bspec
requires the AUX domains to be enabled. But since those can't be enabled
before the phys are initialized, we just use the same sequence as
broxton.
v2: Don't manually enable AUX domains. (Ander)
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 4987a66..fb10ee6 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2721,7 +2721,7 @@ void intel_power_domains_init_hw(struct drm_i915_private
*dev_priv, bool resume)
if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
skl_display_core_init(dev_priv, resume);
- } else if (IS_BROXTON(dev_priv)) {
+ } else if (IS_GEN9_LP(dev_priv)) {
bxt_display_core_init(dev_priv, resume);
} else if (IS_CHERRYVIEW(dev_priv)) {
mutex_lock(&power_domains->lock);
@@ -2760,7 +2760,7 @@ void intel_power_domains_suspend(struct drm_i915_private
*dev_priv)
if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
skl_display_core_uninit(dev_priv);
- else if (IS_BROXTON(dev_priv))
+ else if (IS_GEN9_LP(dev_priv))
bxt_display_core_uninit(dev_priv);
}
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilake
Geminilake has double wide pipes so it can output two pixels per CD
clock.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d4a63f..1fafcce 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5805,8 +5805,10 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
{
int max_cdclk_freq = dev_priv->max_cdclk_freq;
- if (INTEL_INFO(dev_priv)->gen >= 9 ||
- IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+ if (IS_GEMINILAKE(dev_priv))
+ return 2 * max_cdclk_freq;
+ else if (INTEL_INFO(dev_priv)->gen >= 9 ||
+IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
return max_cdclk_freq;
else if (IS_CHERRYVIEW(dev_priv))
return max_cdclk_freq*95/100;
@@ -6563,9 +6565,9 @@ static int valleyview_calc_cdclk(struct drm_i915_private
*dev_priv,
static int glk_calc_cdclk(int max_pixclk)
{
- if (max_pixclk > 158400)
+ if (max_pixclk > 2 * 158400)
return 316800;
- else if (max_pixclk > 79200)
+ else if (max_pixclk > 2 * 79200)
return 158400;
else
return 79200;
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915/glk: Update Port PLL enable sequence for Geminilkae
From: Madhav Chauhan
Add steps for enabling and disabling Port PLL as per bspec.
Signed-off-by: Madhav Chauhan
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_dpll_mgr.c | 20
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6cff01d..90685d2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1574,6 +1574,8 @@ enum skl_disp_power_wells {
#define PORT_PLL_ENABLE (1 << 31)
#define PORT_PLL_LOCK(1 << 30)
#define PORT_PLL_REF_SEL (1 << 27)
+#define PORT_PLL_POWER_ENABLE(1 << 26)
+#define PORT_PLL_POWER_STATE (1 << 25)
#define BXT_PORT_PLL_ENABLE(port) _MMIO_PORT(port, _PORT_PLL_A,
_PORT_PLL_B)
#define _PORT_PLL_EBB_0_A 0x162034
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 63104b7..97f7cc9 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1380,6 +1380,16 @@ static void bxt_ddi_pll_enable(struct drm_i915_private
*dev_priv,
temp |= PORT_PLL_REF_SEL;
I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp);
+ if (IS_GEMINILAKE(dev_priv)) {
+ temp = I915_READ(BXT_PORT_PLL_ENABLE(port));
+ temp |= PORT_PLL_POWER_ENABLE;
+ I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp);
+
+ if (wait_for_us((I915_READ(BXT_PORT_PLL_ENABLE(port)) &
+PORT_PLL_POWER_STATE), 200))
+ DRM_ERROR("Power state not set for PLL:%d\n", port);
+ }
+
/* Disable 10 bit clock */
temp = I915_READ(BXT_PORT_PLL_EBB_4(phy, ch));
temp &= ~PORT_PLL_10BIT_CLK_ENABLE;
@@ -1485,6 +1495,16 @@ static void bxt_ddi_pll_disable(struct drm_i915_private
*dev_priv,
temp &= ~PORT_PLL_ENABLE;
I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp);
POSTING_READ(BXT_PORT_PLL_ENABLE(port));
+
+ if (IS_GEMINILAKE(dev_priv)) {
+ temp = I915_READ(BXT_PORT_PLL_ENABLE(port));
+ temp &= ~PORT_PLL_POWER_ENABLE;
+ I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp);
+
+ if (wait_for_us(!(I915_READ(BXT_PORT_PLL_ENABLE(port)) &
+ PORT_PLL_POWER_STATE), 200))
+ DRM_ERROR("Power state not reset for PLL:%d\n", port);
+ }
}
static bool bxt_ddi_pll_get_hw_state(struct drm_i915_private *dev_priv,
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] drm/i915/glk: Implement Geminilake DDI init sequence
Implement the DDI initsequence and add information about the different
phys in GLK.
v2: Rebase on the move of phys to be power wells.
v3: Rebase on addition of struct bxt_ddi_phy_info.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_reg.h | 17 +++--
drivers/gpu/drm/i915/intel_dpio_phy.c | 114 +++-
drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 39 +++
5 files changed, 155 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90ef5a0..035ac75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -234,7 +234,8 @@ enum dpio_channel {
enum dpio_phy {
DPIO_PHY0,
- DPIO_PHY1
+ DPIO_PHY1,
+ DPIO_PHY2,
};
enum intel_display_power_domain {
@@ -3619,7 +3620,7 @@ u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv,
u32 reg);
void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
/* intel_dpio_phy.c */
-void bxt_port_to_phy_channel(enum port port,
+void bxt_port_to_phy_channel(struct drm_i915_private *dev_priv, enum port port,
enum dpio_phy *phy, enum dpio_channel *ch);
void bxt_ddi_phy_set_signal_level(struct drm_i915_private *dev_priv,
enum port port, u32 margin, u32 scale,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 35f7820..d1f0720 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -62,6 +62,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define _PORT3(port, a, b, c) ((port) == PORT_A ? (a) : \
(port) == PORT_B ? (b) : (c))
#define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PORT3(pipe, a, b, c))
+#define _PHY3(phy, a, b, c) ((phy) == DPIO_PHY0 ? (a) : \
+(phy) == DPIO_PHY1 ? (b) : (c))
+#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
#define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask))\
@@ -1062,6 +1065,7 @@ enum skl_disp_power_wells {
BXT_DPIO_CMN_A,
BXT_DPIO_CMN_BC,
+ GLK_DPIO_CMN_C,
};
#define SKL_POWER_WELL_STATE(pw) (1 << ((pw) * 2))
@@ -1530,8 +1534,10 @@ enum skl_disp_power_wells {
/* BXT PHY registers */
#define _BXT_PHY0_BASE 0x6C000
#define _BXT_PHY1_BASE 0x162000
-#define BXT_PHY_BASE(phy) _PIPE((phy), _BXT_PHY0_BASE, \
-_BXT_PHY1_BASE)
+#define _BXT_PHY2_BASE 0x163000
+#define BXT_PHY_BASE(phy) _PHY3((phy), _BXT_PHY0_BASE, \
+_BXT_PHY1_BASE, \
+_BXT_PHY2_BASE)
#define _BXT_PHY(phy, reg) \
_MMIO(BXT_PHY_BASE(phy) - _BXT_PHY0_BASE + (reg))
@@ -1543,7 +1549,6 @@ enum skl_disp_power_wells {
_MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1))
#define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
-#define GT_DISPLAY_POWER_ON(phy) (1 << (phy))
#define _BXT_PHY_CTL_DDI_A 0x64C00
#define _BXT_PHY_CTL_DDI_B 0x64C10
@@ -1556,9 +1561,11 @@ enum skl_disp_power_wells {
#define _PHY_CTL_FAMILY_EDP0x64C80
#define _PHY_CTL_FAMILY_DDI0x64C90
+#define _PHY_CTL_FAMILY_DDI_C 0x64CA0
#define COMMON_RESET_DIS (1 << 31)
-#define BXT_PHY_CTL_FAMILY(phy)_MMIO_PIPE((phy),
_PHY_CTL_FAMILY_DDI, \
- _PHY_CTL_FAMILY_EDP)
+#define BXT_PHY_CTL_FAMILY(phy)_MMIO_PHY3((phy),
_PHY_CTL_FAMILY_DDI, \
+ _PHY_CTL_FAMILY_EDP, \
+ _PHY_CTL_FAMILY_DDI_C)
/* BXT PHY PLL registers */
#define _PORT_PLL_A0x46074
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 8c62dea..46e38a0 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -131,6 +131,18 @@ struct bxt_ddi_phy_info {
enum dpio_phy rcomp_phy;
/**
+* @reset_delay: delay in us to wait before setting the common reset
+* bit in BXT_PHY_CTL_FAMILY, which effectively enables the phy.
+*/
+ int reset_delay;
+
+ /**
+* @pwron_mask: Mask with the appropriate bit set that would cause the
+* punit to power this phy if written to BXT_P_CR_GT_DISP_PWRON.
+*/
+ u32 pwron_mask;
+
+ /**
* @channel: struct containing per channel infor
[Intel-gfx] [PATCH 9/9] drm/i915/glk: Configure number of sprite planes properly
Geminilake has 4 planes (3 sprites) per pipe.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_device_info.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 185e3bb..602d761 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -278,7 +278,10 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
* we don't expose the topmost plane at all to prevent ABI breakage
* down the line.
*/
- if (IS_BROXTON(dev_priv)) {
+ if (IS_GEMINILAKE(dev_priv))
+ for_each_pipe(dev_priv, pipe)
+ info->num_sprites[pipe] = 3;
+ else if (IS_BROXTON(dev_priv)) {
info->num_sprites[PIPE_A] = 2;
info->num_sprites[PIPE_B] = 2;
info->num_sprites[PIPE_C] = 1;
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] drm/i915/glk: Set DCC delay range 2 in PLL enable sequence
Follow the PLL enable sequence updated in bspec, which requires the DCC
delay range 2 bit to be set.
v2: Moved from DDI init sequence to PLL enable.
v3: Don't read value from GRP register. (Rodrido)
Cc: Rodrigo Vivi
Signed-off-by: Ander Conselvan De Oliveira
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 15 +++
drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d1f0720..6cff01d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1784,6 +1784,21 @@ enum skl_disp_power_wells {
#define DEEMPH_SHIFT 24
#define DE_EMPHASIS (0xFF << DEEMPH_SHIFT)
+#define _PORT_TX_DW5_LN0_A 0x162514
+#define _PORT_TX_DW5_LN0_B 0x6C514
+#define _PORT_TX_DW5_LN0_C 0x6C914
+#define _PORT_TX_DW5_GRP_A 0x162D14
+#define _PORT_TX_DW5_GRP_B 0x6CD14
+#define _PORT_TX_DW5_GRP_C 0x6CF14
+#define BXT_PORT_TX_DW5_LN0(phy, ch) _MMIO_BXT_PHY_CH(phy, ch, \
+_PORT_TX_DW5_LN0_B, \
+_PORT_TX_DW5_LN0_C)
+#define BXT_PORT_TX_DW5_GRP(phy, ch) _MMIO_BXT_PHY_CH(phy, ch, \
+_PORT_TX_DW5_GRP_B, \
+_PORT_TX_DW5_GRP_C)
+#define DCC_DELAY_RANGE_1(1 << 9)
+#define DCC_DELAY_RANGE_2(1 << 8)
+
#define _PORT_TX_DW14_LN0_A0x162538
#define _PORT_TX_DW14_LN0_B0x6C538
#define _PORT_TX_DW14_LN0_C0x6C938
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 8a82507..63104b7 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1458,6 +1458,12 @@ static void bxt_ddi_pll_enable(struct drm_i915_private
*dev_priv,
200))
DRM_ERROR("PLL %d not locked\n", port);
+ if (IS_GEMINILAKE(dev_priv)) {
+ temp = I915_READ(BXT_PORT_TX_DW5_LN0(phy, ch));
+ temp |= DCC_DELAY_RANGE_2;
+ I915_WRITE(BXT_PORT_TX_DW5_GRP(phy, ch), temp);
+ }
+
/*
* While we write to the group register to program all lanes at once we
* can read only lane registers and we pick lanes 0/1 for that.
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915/glk: Add power wells for Geminilake
Geminilake has power wells are similar to SKL, but with the misc IO well
being split into separate AUX IO wells.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 114 +++-
2 files changed, 117 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1dec207..35f7820 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1044,9 +1044,15 @@ enum skl_disp_power_wells {
/* These numbers are fixed and must match the position of the pw bits */
SKL_DISP_PW_MISC_IO,
SKL_DISP_PW_DDI_A_E,
+ GLK_DISP_PW_DDI_A = SKL_DISP_PW_DDI_A_E,
SKL_DISP_PW_DDI_B,
SKL_DISP_PW_DDI_C,
SKL_DISP_PW_DDI_D,
+
+ GLK_DISP_PW_AUX_A = 8,
+ GLK_DISP_PW_AUX_B,
+ GLK_DISP_PW_AUX_C,
+
SKL_DISP_PW_1 = 14,
SKL_DISP_PW_2,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 66ab1c8..49043fc 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -453,6 +453,45 @@ static void hsw_set_power_well(struct drm_i915_private
*dev_priv,
BIT(POWER_DOMAIN_AUX_C) | \
BIT(POWER_DOMAIN_INIT))
+#define GLK_DISPLAY_POWERWELL_2_POWER_DOMAINS (\
+ BIT(POWER_DOMAIN_TRANSCODER_A) |\
+ BIT(POWER_DOMAIN_PIPE_B) | \
+ BIT(POWER_DOMAIN_TRANSCODER_B) |\
+ BIT(POWER_DOMAIN_PIPE_C) | \
+ BIT(POWER_DOMAIN_TRANSCODER_C) |\
+ BIT(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
+ BIT(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
+ BIT(POWER_DOMAIN_PORT_DDI_B_LANES) |\
+ BIT(POWER_DOMAIN_PORT_DDI_C_LANES) |\
+ BIT(POWER_DOMAIN_AUX_B) | \
+ BIT(POWER_DOMAIN_AUX_C) | \
+ BIT(POWER_DOMAIN_AUDIO) | \
+ BIT(POWER_DOMAIN_VGA) | \
+ BIT(POWER_DOMAIN_INIT))
+#define GLK_DISPLAY_DDI_A_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_PORT_DDI_A_LANES) |\
+ BIT(POWER_DOMAIN_INIT))
+#define GLK_DISPLAY_DDI_B_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_PORT_DDI_B_LANES) |\
+ BIT(POWER_DOMAIN_INIT))
+#define GLK_DISPLAY_DDI_C_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_PORT_DDI_C_LANES) |\
+ BIT(POWER_DOMAIN_INIT))
+#define GLK_DISPLAY_AUX_A_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_AUX_A) | \
+ BIT(POWER_DOMAIN_INIT))
+#define GLK_DISPLAY_AUX_B_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_AUX_B) | \
+ BIT(POWER_DOMAIN_INIT))
+#define GLK_DISPLAY_AUX_C_POWER_DOMAINS ( \
+ BIT(POWER_DOMAIN_AUX_C) | \
+ BIT(POWER_DOMAIN_INIT))
+#define GLK_DISPLAY_DC_OFF_POWER_DOMAINS ( \
+ GLK_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
+ BIT(POWER_DOMAIN_MODESET) | \
+ BIT(POWER_DOMAIN_AUX_A) | \
+ BIT(POWER_DOMAIN_INIT))
+
static void assert_can_enable_dc9(struct drm_i915_private *dev_priv)
{
WARN_ONCE((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC9),
@@ -694,7 +733,7 @@ gen9_sanitize_power_well_requests(struct drm_i915_private
*dev_priv,
}
static void skl_set_power_well(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well, bool enable)
+ struct i915_power_well *power_well, bool enable)
{
uint32_t tmp, fuse_status;
uint32_t req_mask, state_mask;
@@ -720,11 +759,14 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
return;
}
break;
- case SKL_DISP_PW_DDI_A_E:
+ case SKL_DISP_PW_MISC_IO:
+ case SKL_DISP_PW_DDI_A_E: /* GLK_DISP_PW_DDI_A */
case SKL_DISP_PW_DDI_B:
case SKL_DISP_PW_DDI_C:
case SKL_DISP_PW_DDI_D:
- case SKL_DISP_PW_MISC_IO:
+ case GLK_DISP_PW_AUX_A:
+ case GLK_DISP_PW_AUX_B:
+ case GLK_DISP_PW_AUX_C:
break;
default:
WARN(1, "Unknown power well %lu\n", power_well->id);
@@ -2150,6 +2192,70 @@ static struct i915_power_well bxt_power_wells[] = {
},
};
+static struct i915_power_well glk_power_wells[] = {
+ {
+ .name = "always-on",
+ .always_on = 1,
+ .domains = POWER_DOMAIN_MASK,
+ .ops = &i9xx_always_on_power_well_ops,
+ },
+ {
+ .name = "power well 1",
+ /* Handled by the DMC firmware */
+
[Intel-gfx] [PATCH 6/9] drm/i915/glk: Reuse broxton's cdclk code for GLK
Geminilake has the same register layout, reference clock and programming
sequence as broxton. The difference is that it doesn't support the 1.5
divider and has different ratios, but a lot of code can be shared
between the two platforms.
v2: Rebase (s/broxton/bxt).
v3: Fix vco calculation in glk_de_pll_vco().
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_display.c | 73
1 file changed, 65 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3a03112..8d4a63f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -124,6 +124,7 @@ static void ironlake_pfit_enable(struct intel_crtc *crtc);
static void intel_modeset_setup_hw_state(struct drm_device *dev);
static void intel_pre_disable_primary_noatomic(struct drm_crtc *crtc);
static int ilk_max_pixel_rate(struct drm_atomic_state *state);
+static int glk_calc_cdclk(int max_pixclk);
static int bxt_calc_cdclk(int max_pixclk);
struct intel_limit {
@@ -5841,6 +5842,8 @@ static void intel_update_max_cdclk(struct
drm_i915_private *dev_priv)
max_cdclk = 308571;
dev_priv->max_cdclk_freq = skl_calc_cdclk(max_cdclk, vco);
+ } else if (IS_GEMINILAKE(dev_priv)) {
+ dev_priv->max_cdclk_freq = 316800;
} else if (IS_BROXTON(dev_priv)) {
dev_priv->max_cdclk_freq = 624000;
} else if (IS_BROADWELL(dev_priv)) {
@@ -5928,6 +5931,26 @@ static int bxt_de_pll_vco(struct drm_i915_private
*dev_priv, int cdclk)
return dev_priv->cdclk_pll.ref * ratio;
}
+static int glk_de_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
+{
+ int ratio;
+
+ if (cdclk == dev_priv->cdclk_pll.ref)
+ return 0;
+
+ switch (cdclk) {
+ default:
+ MISSING_CASE(cdclk);
+ case 79200:
+ case 158400:
+ case 316800:
+ ratio = 33;
+ break;
+ }
+
+ return dev_priv->cdclk_pll.ref * ratio;
+}
+
static void bxt_de_pll_disable(struct drm_i915_private *dev_priv)
{
I915_WRITE(BXT_DE_PLL_ENABLE, 0);
@@ -5969,7 +5992,10 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv, int cdclk)
u32 val, divider;
int vco, ret;
- vco = bxt_de_pll_vco(dev_priv, cdclk);
+ if (IS_GEMINILAKE(dev_priv))
+ vco = glk_de_pll_vco(dev_priv, cdclk);
+ else
+ vco = bxt_de_pll_vco(dev_priv, cdclk);
DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
@@ -5982,6 +6008,7 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv, int cdclk)
divider = BXT_CDCLK_CD2X_DIV_SEL_2;
break;
case 3:
+ WARN(IS_GEMINILAKE(dev_priv), "Unsupported divider\n");
divider = BXT_CDCLK_CD2X_DIV_SEL_1_5;
break;
case 2:
@@ -6091,6 +6118,8 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
*dev_priv)
void bxt_init_cdclk(struct drm_i915_private *dev_priv)
{
+ int cdclk;
+
bxt_sanitize_cdclk(dev_priv);
if (dev_priv->cdclk_freq != 0 && dev_priv->cdclk_pll.vco != 0)
@@ -6101,7 +6130,12 @@ void bxt_init_cdclk(struct drm_i915_private *dev_priv)
* - The initial CDCLK needs to be read from VBT.
* Need to make this change after VBT has changes for BXT.
*/
- bxt_set_cdclk(dev_priv, bxt_calc_cdclk(0));
+ if (IS_GEMINILAKE(dev_priv))
+ cdclk = glk_calc_cdclk(0);
+ else
+ cdclk = bxt_calc_cdclk(0);
+
+ bxt_set_cdclk(dev_priv, cdclk);
}
void bxt_uninit_cdclk(struct drm_i915_private *dev_priv)
@@ -6527,6 +6561,16 @@ static int valleyview_calc_cdclk(struct drm_i915_private
*dev_priv,
return 20;
}
+static int glk_calc_cdclk(int max_pixclk)
+{
+ if (max_pixclk > 158400)
+ return 316800;
+ else if (max_pixclk > 79200)
+ return 158400;
+ else
+ return 79200;
+}
+
static int bxt_calc_cdclk(int max_pixclk)
{
if (max_pixclk > 576000)
@@ -6589,15 +6633,27 @@ static int valleyview_modeset_calc_cdclk(struct
drm_atomic_state *state)
static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
{
+ struct drm_i915_private *dev_priv = to_i915(state->dev);
int max_pixclk = ilk_max_pixel_rate(state);
struct intel_atomic_state *intel_state =
to_intel_atomic_state(state);
+ int cdclk;
- intel_state->cdclk = intel_state->dev_cdclk =
- bxt_calc_cdclk(max_pixclk);
+ if (IS_GEMINILAKE(dev_priv))
+ cdclk = glk_calc_cdclk(max_pixclk);
+ else
+ cdclk = bxt_calc_cdclk(max_pixclk);
- if (!intel_state->active_crtcs)
- intel_state
[Intel-gfx] [PATCH 1/9] drm/i915/glk: Reuse broxton code for geminilake
Geminilake is mostly backwards compatible with broxton, so change most
of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the
platforms will be implemented in follow-up patches.
v2: Don't reuse broxton's path in intel_update_max_cdclk().
Don't set plane count as in broxton.
v3: Rebase
v4: Include the check intel_bios_is_port_hpd_inverted().
Commit message.
v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo)
v6: Rebase.
v7: Convert a few mode IS_BROXTON() occurances in pps, ddi, dsi and pll
code. (Rodrigo)
v8: Squash a couple of DDI patches with more conversions. (Rodrigo)
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 8
drivers/gpu/drm/i915/i915_irq.c | 10 +-
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
drivers/gpu/drm/i915/intel_bios.c | 2 +-
drivers/gpu/drm/i915/intel_ddi.c| 26 +-
drivers/gpu/drm/i915/intel_display.c| 14 +++---
drivers/gpu/drm/i915/intel_dp.c | 24
drivers/gpu/drm/i915/intel_dpio_phy.c | 1 -
drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
drivers/gpu/drm/i915/intel_dsi.c| 30 +++---
drivers/gpu/drm/i915/intel_dsi_pll.c| 12 ++--
drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
drivers/gpu/drm/i915/intel_i2c.c| 4 ++--
drivers/gpu/drm/i915/intel_mocs.c | 2 +-
drivers/gpu/drm/i915/intel_panel.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 6 +++---
drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +++---
18 files changed, 84 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d006ed1..1b59d12 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1108,7 +1108,7 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
int max_freq;
rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
- if (IS_BROXTON(dev_priv)) {
+ if (IS_GEN9_LP(dev_priv)) {
rp_state_cap = I915_READ(BXT_RP_STATE_CAP);
gt_perf_status = I915_READ(BXT_GT_PERF_STATUS);
} else {
@@ -1204,7 +1204,7 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
seq_printf(m, "Down threshold: %d%%\n",
dev_priv->rps.down_threshold);
- max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 0 :
+ max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
rp_state_cap >> 16) & 0xff;
max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ?
GEN9_FREQ_SCALER : 1);
@@ -1217,7 +1217,7 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
intel_gpu_freq(dev_priv, max_freq));
- max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 16 :
+ max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
rp_state_cap >> 0) & 0xff;
max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ?
GEN9_FREQ_SCALER : 1);
@@ -5180,7 +5180,7 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
/* BXT has a single slice and at most 3 subslices. */
- if (IS_BROXTON(dev_priv)) {
+ if (IS_GEN9_LP(dev_priv)) {
s_max = 1;
ss_max = 3;
}
@@ -5214,7 +5214,7 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
- if (IS_BROXTON(dev_priv)) {
+ if (IS_GEN9_LP(dev_priv)) {
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
/* skip disabled subslice */
continue;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 02fb063..c004247 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -372,7 +372,7 @@ static void kunmap_page_dma(struct drm_i915_private
*dev_priv, void *vaddr)
/* There are only few exceptions for gen >=6. chv and bxt.
* And we are not sure about the latter so play safe for now.
*/
- if (IS_CHERRYVIEW(dev_priv) || IS_BROXTON(dev_priv))
+ if (IS_CHERRYVIEW(dev_priv) || IS_GEN9_LP(dev_priv))
drm_clflush_virt_range(vaddr, PAGE_SIZE);
kunmap_at
Re: [Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces
On Thu, 2016-12-01 at 23:53 -0800, Daniel Vetter wrote: > On Thu, Dec 01, 2016 at 01:44:15PM +0530, swati.dhin...@intel.com wrote: > > From: Swati Dhingra > > > > The patch introduces a new pseudo filesystem type, named 'drmfs' which is > > intended to house the files for the data generated by drm subsystem that > > cannot be accommodated by any of the existing filesystems. > > The filesystem is modelled on the lines of existing pseudo-filesystems such > > as debugfs/tracefs, and borrows ideas from their implementation. > > This filesystem will be appearing at sys/kernel/drm. > > > > A new config 'CONFIG_DRMFS' is introduced to enable/disable the filesystem, > > which is dependent on CONFIG_DRM. > > The filesystem will not be registered standalone during kernel init time, > > instead it is intended to be initialized/registered during drm > > initialization. > > > > The intent for introduction of the filesystem is to act as a location to > > hold > > various kinds of data output from Linux DRM subsystems, which can't really > > fit > > anywhere else into the existing filesystems such as debugfs/sysfs etc. All > > these > > filesystems have their own constraints and are intended to output a > > particular > > type of data such as attributes and small debug parameter data. Due to these > > constraints, there is a need for a new pseudo filesytem, customizable to DRM > > specific requirements and catering to the needs to DRM subsystem components > > > > Signed-off-by: Sourab Gupta > > Signed-off-by: Swati Dhingra > > I thought review feedback was to put that into drm, not under fs/? Also, > needs proper ccing. > -Daniel > Hi Daniel, We'll remove it from fs and add under drm/ in the next version of series. Sorry, forgot to add dri-devel, will add it when we send next version. > > --- > > drivers/gpu/drm/drm_drv.c | 1 + > > fs/Kconfig | 9 + > > fs/Makefile| 1 + > > fs/drmfs/Makefile | 3 + > > fs/drmfs/inode.c | 561 > > + > > include/linux/drmfs.h | 56 + > > include/uapi/linux/magic.h | 3 + > > 7 files changed, 634 insertions(+) > > create mode 100644 fs/drmfs/Makefile > > create mode 100644 fs/drmfs/inode.c > > create mode 100644 include/linux/drmfs.h > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > index 6dbb986..84fcfcb 100644 > > --- a/drivers/gpu/drm/drm_drv.c > > +++ b/drivers/gpu/drm/drm_drv.c > > @@ -27,6 +27,7 @@ > > */ > > > > #include > > +#include > > #include > > #include > > #include > > diff --git a/fs/Kconfig b/fs/Kconfig > > index 4bd03a2..7d0ac20 100644 > > --- a/fs/Kconfig > > +++ b/fs/Kconfig > > @@ -200,6 +200,15 @@ config HUGETLBFS > > config HUGETLB_PAGE > > def_bool HUGETLBFS > > > > +config DRMFS > > + bool "Drmfs file system support" > > + depends on DRM > > + help > > + Drmfs is a pseudo file system for drm subsystem output data. > > + > > + drmfs is a filesystem to hold miscellaneous output data from drm > > + subsystems. > > + > > config ARCH_HAS_GIGANTIC_PAGE > > bool > > > > diff --git a/fs/Makefile b/fs/Makefile > > index ed2b632..b34a96e 100644 > > --- a/fs/Makefile > > +++ b/fs/Makefile > > @@ -120,6 +120,7 @@ obj-$(CONFIG_BEFS_FS) += befs/ > > obj-$(CONFIG_HOSTFS) += hostfs/ > > obj-$(CONFIG_CACHEFILES) += cachefiles/ > > obj-$(CONFIG_DEBUG_FS) += debugfs/ > > +obj-$(CONFIG_DRMFS)+= drmfs/ > > obj-$(CONFIG_TRACING) += tracefs/ > > obj-$(CONFIG_OCFS2_FS) += ocfs2/ > > obj-$(CONFIG_BTRFS_FS) += btrfs/ > > diff --git a/fs/drmfs/Makefile b/fs/drmfs/Makefile > > new file mode 100644 > > index 000..ac87e497 > > --- /dev/null > > +++ b/fs/drmfs/Makefile > > @@ -0,0 +1,3 @@ > > +drmfs-objs := inode.o > > + > > +obj-$(CONFIG_DRMFS)+= drmfs.o > > diff --git a/fs/drmfs/inode.c b/fs/drmfs/inode.c > > new file mode 100644 > > index 000..9220705 > > --- /dev/null > > +++ b/fs/drmfs/inode.c > > @@ -0,0 +1,561 @@ > > +/* > > + * Copyright © 2014 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
Re: [Intel-gfx] [PATCH v3] drm/i915/glk: Reuse broxton code for geminilake
On Thu, 2016-12-01 at 17:06 -0800, Rodrigo Vivi wrote:
> A reviewed backwards because I was willing to check if all ifs were in place.
>
> I missed the ones from i915_drv.c
>
> *** i915_drv.c:
> i915_drm_suspend_late[1500]fw_csr = !IS_GEN9_LP(dev_priv) &&
> i915_drm_suspend_late[1513]if (IS_GEN9_LP(dev_priv))
> i915_drm_resume_early[1721]if (IS_GEN9_LP(dev_priv)) {
> i915_drm_resume_early[1731]if (IS_GEN9_LP(dev_priv) ||
> intel_runtime_suspend[2354]if (IS_GEN9_LP(dev_priv)) {
> intel_runtime_resume[2439] if (IS_GEN9_LP(dev_priv)) {
>
> The ones that I had added with the patch
> "drm/i915/glk: Add missing bits to allow runtime pm suspend on GLK."
>
> Feel free to squash all those into this patch if you like. However I believe
> that before that one we need Anusha's dmc load patch that is one that I'm also
> missing on this series here, right?
>
> So any option works for me and if you decide to move with this feel free to
> use
> Reviewed-by: Rodrigo Vivi
>
> And please let me know what are your plans with this runtime_pm related
> patches and if you need anything from me.
I was planning to do those as a follow up once this series is merged. I didn't
want to make it any bigger to make review easier.
Ander
>
> Thanks,
> Rodrigo.
>
> On Tue, Nov 29, 2016 at 05:47:12PM +0200, Ander Conselvan de Oliveira wrote:
> >
> > Geminilake is mostly backwards compatible with broxton, so change most
> > of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the
> > platforms will be implemented in follow-up patches.
> >
> > v2: Don't reuse broxton's path in intel_update_max_cdclk().
> > Don't set plane count as in broxton.
> >
> > v3: Rebase
> >
> > v4: Include the check intel_bios_is_port_hpd_inverted().
> > Commit message.
> >
> > v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo)
> >
> > v6: Rebase.
> >
> > v7: Convert a few mode IS_BROXTON() occurances in pps, ddi, dsi and pll
> > code. (Rodrigo)
> >
> > Cc: Rodrigo Vivi
> > Signed-off-by: Ander Conselvan de Oliveira > l.com>
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 8
> > drivers/gpu/drm/i915/i915_irq.c | 10 +-
> > drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> > drivers/gpu/drm/i915/intel_bios.c | 2 +-
> > drivers/gpu/drm/i915/intel_ddi.c| 18 +-
> > drivers/gpu/drm/i915/intel_display.c| 12 ++--
> > drivers/gpu/drm/i915/intel_dp.c | 24
> > drivers/gpu/drm/i915/intel_dpio_phy.c | 1 -
> > drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
> > drivers/gpu/drm/i915/intel_dsi.c| 30 +++---
> > drivers/gpu/drm/i915/intel_dsi_pll.c| 12 ++--
> > drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
> > drivers/gpu/drm/i915/intel_i2c.c| 4 ++--
> > drivers/gpu/drm/i915/intel_mocs.c | 2 +-
> > drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > drivers/gpu/drm/i915/intel_pm.c | 6 +++---
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +++---
> > 18 files changed, 79 insertions(+), 80 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 8eb8c29..6c17d39 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1108,7 +1108,7 @@ static int i915_frequency_info(struct seq_file *m,
> > void *unused)
> > int max_freq;
> >
> > rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
> > - if (IS_BROXTON(dev_priv)) {
> > + if (IS_GEN9_LP(dev_priv)) {
> > rp_state_cap = I915_READ(BXT_RP_STATE_CAP);
> > gt_perf_status = I915_READ(BXT_GT_PERF_STATUS);
> > } else {
> > @@ -1204,7 +1204,7 @@ static int i915_frequency_info(struct seq_file *m,
> > void *unused)
> > seq_printf(m, "Down threshold: %d%%\n",
> > dev_priv->rps.down_threshold);
> >
> > - max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 0 :
> > + max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
> > rp_state_cap >> 16) & 0xff;
> > max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)
> > ?
> > GEN9_FREQ_SCALER : 1);
> > @@ -1217,7 +1217,7 @@ static int i915_frequency_info(struct seq_file *m,
> > void *unused)
> > seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
> > intel_gpu_freq(dev_priv, max_freq));
> >
> > - max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 16 :
> > + max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
> > rp_state_cap >> 0) & 0xff;
> > max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)
> > ?
> > GEN9_FREQ_SCA
Re: [Intel-gfx] [RFC 2/3] drm: Register drmfs filesystem from drm init
On Thu, 2016-12-01 at 23:57 -0800, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 01:44:16PM +0530, swati.dhin...@intel.com wrote:
> > From: Swati Dhingra
> >
> > During drm module initialization, drm_core_init initializes the drmfs
> > filesystem and register this with kernel. A driver specific directory is
> > created
> > inside drmfs root, and dentry of this directory is saved for subsequent use
> > by the driver (e.g. i915). The driver can then create files/directories
> > inside
> > this root directory directly.
> > In case of i915 driver, the top directory is created at
> > '/sys/kernel/drm/i915'.
> >
> > Signed-off-by: Sourab Gupta
> > Signed-off-by: Swati Dhingra
> > ---
> > drivers/gpu/drm/drm_drv.c | 22 ++
> > include/drm/drm_drv.h | 3 +++
> > 2 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 84fcfcb..ead360bd 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -688,6 +688,14 @@ int drm_dev_register(struct drm_device *dev, unsigned
> > long flags)
> > {
> > int ret;
> >
> > +#ifdef CONFIG_DRMFS
> > + dev->driver->drmfs_root = drmfs_create_dir(dev->driver->name, NULL);
> > + if (IS_ERR(dev->driver->drmfs_root)) {
> > + DRM_ERROR("Failed to get drmfs root dentry\n");
> > + return PTR_ERR(dev->driver->drmfs_root);
> > + }
> > +#endif
>
> Don't do #ifdef in the code, instead provide dummy static inline functions
> that do nothing in headers when a feature is disabled. For an example see
> CONFIG_DRM_FBDEV_EMULATION in drm_fb_helper.[hc].
>
Sorry, Will take take of this going forward.
> Also, drmfs here is seriously lacking documentation. E.g. where are we
> supposed to put different things related to rendering, modesetting, and
> all these issues? You need to add a section in drm-uabi.rst, write
> kernel-doc + overview sections for all of this and pull it in.
> -Daniel
>
Ok. Will work on adding requisite documentation for drmfs.
Thanks,
Sourab
> > +
> > mutex_lock(&drm_global_mutex);
> >
> > ret = drm_minor_register(dev, DRM_MINOR_CONTROL);
> > @@ -758,6 +766,9 @@ void drm_dev_unregister(struct drm_device *dev)
> > drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
> > drm_minor_unregister(dev, DRM_MINOR_RENDER);
> > drm_minor_unregister(dev, DRM_MINOR_CONTROL);
> > +#ifdef CONFIG_DRMFS
> > + drmfs_remove(dev->driver->drmfs_root);
> > +#endif
> > }
> > EXPORT_SYMBOL(drm_dev_unregister);
> >
> > @@ -825,6 +836,9 @@ static void drm_core_exit(void)
> > {
> > unregister_chrdev(DRM_MAJOR, "drm");
> > debugfs_remove(drm_debugfs_root);
> > +#ifdef CONFIG_DRMFS
> > + drmfs_fini();
> > +#endif
> > drm_sysfs_destroy();
> > idr_destroy(&drm_minors_idr);
> > drm_connector_ida_destroy();
> > @@ -845,6 +859,14 @@ static int __init drm_core_init(void)
> > goto error;
> > }
> >
> > +#ifdef CONFIG_DRMFS
> > + ret = drmfs_init();
> > + if (ret < 0) {
> > + DRM_ERROR("Cannot create DRM FS: %d\n", ret);
> > + goto error;
> > + }
> > +#endif
> > +
> > drm_debugfs_root = debugfs_create_dir("dri", NULL);
> > if (!drm_debugfs_root) {
> > ret = -ENOMEM;
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index aad8bba..34804de 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -403,6 +403,9 @@ struct drm_driver {
> >
> > /* List of devices hanging off this driver with stealth attach. */
> > struct list_head legacy_dev_list;
> > +
> > + /* drmfs parent directory dentry for this driver */
> > + struct dentry *drmfs_root;
> > };
> >
> > extern __printf(6, 7)
> > --
> > 2.7.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: use DRM_DEBUG for userspace issues
On Thu, Dec 01, 2016 at 05:21:52PM +, Robert Bragg wrote:
> Avoid using DRM_ERROR for conditions userspace can trigger with a bad
> config when opening a stream or from not reading data in a timely
> fashion (whereby the OA buffer fills up). These conditions are tested
> by i-g-t which treats error messages as failures if using the test
> runner. This wasn't an issue while the i915-perf igt tests were being
> run in isolation.
>
> One message relating to seeing a spurious zeroed report was changed to
> use DRM_NOTE instead of DRM_ERROR. Ideally this warning shouldn't be
> seen, but it's not a serious problem if it is. Considering that the
> tail margin mechanism is only a heuristic it's possible we might see
> this from time to time.
>
> Signed-off-by: Robert Bragg Cc: Daniel Vetter
>
> fix i915_perf dbg messages
> ---
> drivers/gpu/drm/i915/i915_perf.c | 42
>
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 9551282..5705005 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -474,7 +474,7 @@ static int gen7_append_oa_reports(struct i915_perf_stream
> *stream,
>* copying it to userspace...
>*/
> if (report32[0] == 0) {
> - DRM_ERROR("Skipping spurious, invalid OA report\n");
> + DRM_NOTE("Skipping spurious, invalid OA report\n");
> continue;
The above looks like a genuine hw/kernel fail, which we shouldn't put
under the carpet. I'd leave it at DRM_ERROR - I can bikeshed that while
applying if you're ok. Otherwise lgtm, will apply as soon as we've
clarified that.
-Daniel
> }
>
> @@ -551,7 +551,7 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
> if (ret)
> return ret;
>
> - DRM_ERROR("OA buffer overflow: force restart\n");
> + DRM_DEBUG("OA buffer overflow: force restart\n");
>
> dev_priv->perf.oa.ops.oa_disable(dev_priv);
> dev_priv->perf.oa.ops.oa_enable(dev_priv);
> @@ -1000,17 +1000,17 @@ static int i915_oa_stream_init(struct
> i915_perf_stream *stream,
>* IDs
>*/
> if (!dev_priv->perf.metrics_kobj) {
> - DRM_ERROR("OA metrics weren't advertised via sysfs\n");
> + DRM_DEBUG("OA metrics weren't advertised via sysfs\n");
> return -EINVAL;
> }
>
> if (!(props->sample_flags & SAMPLE_OA_REPORT)) {
> - DRM_ERROR("Only OA report sampling supported\n");
> + DRM_DEBUG("Only OA report sampling supported\n");
> return -EINVAL;
> }
>
> if (!dev_priv->perf.oa.ops.init_oa_buffer) {
> - DRM_ERROR("OA unit not supported\n");
> + DRM_DEBUG("OA unit not supported\n");
> return -ENODEV;
> }
>
> @@ -1019,17 +1019,17 @@ static int i915_oa_stream_init(struct
> i915_perf_stream *stream,
>* we currently only allow exclusive access
>*/
> if (dev_priv->perf.oa.exclusive_stream) {
> - DRM_ERROR("OA unit already in use\n");
> + DRM_DEBUG("OA unit already in use\n");
> return -EBUSY;
> }
>
> if (!props->metrics_set) {
> - DRM_ERROR("OA metric set not specified\n");
> + DRM_DEBUG("OA metric set not specified\n");
> return -EINVAL;
> }
>
> if (!props->oa_format) {
> - DRM_ERROR("OA report format not specified\n");
> + DRM_DEBUG("OA report format not specified\n");
> return -EINVAL;
> }
>
> @@ -1384,7 +1384,7 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
> *dev_priv,
> if (IS_ERR(specific_ctx)) {
> ret = PTR_ERR(specific_ctx);
> if (ret != -EINTR)
> - DRM_ERROR("Failed to look up context with ID %u
> for opening perf stream\n",
> + DRM_DEBUG("Failed to look up context with ID %u
> for opening perf stream\n",
> ctx_handle);
> goto err;
> }
> @@ -1397,7 +1397,7 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
> *dev_priv,
>*/
> if (!specific_ctx &&
> i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
> - DRM_ERROR("Insufficient privileges to open system-wide i915
> perf stream\n");
> + DRM_DEBUG("Insufficient privileges to open system-wide i915
> perf stream\n");
> ret = -EACCES;
> goto err_ctx;
> }
> @@ -1476,7 +1476,7 @@ static int read_properties_unlocked(struct
> drm_i915_private *dev_priv,
> memset(props, 0, sizeof(struct perf_open_properties));
>
> if (!n_props) {
> -
[Intel-gfx] [PATCH] drm/i915: Fix kerneldoc for intel_guc_fini
From: Tvrtko Ursulin
Recent refactoring forgot to update this one.
Signed-off-by: Tvrtko Ursulin
Fixes: bf9e8429ab97 ("drm/i915: Make various init functions take dev_priv")
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 260ffe5e693b..21db69705458 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -773,7 +773,7 @@ void intel_guc_init(struct drm_i915_private *dev_priv)
/**
* intel_guc_fini() - clean up all allocated resources
- * @dev: drm device
+ * @dev_priv: i915 device private
*/
void intel_guc_fini(struct drm_i915_private *dev_priv)
{
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Geminilake enabling (rev9)
== Series Details == Series: Geminilake enabling (rev9) URL : https://patchwork.freedesktop.org/series/15118/ State : warning == Summary == Series 15118v9 Geminilake enabling https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/9/mbox/ Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: pass -> DMESG-WARN (fi-ivb-3770) fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:222 dwarn:1 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 58e999de1132de619056ee8fafccbbe7dfba3f4d drm-tip: 2016y-12m-02d-07h-55m-48s UTC integration manifest 1f087d4 drm/i915/glk: Configure number of sprite planes properly 0615d8a drm/i915/glk: Implement core display init/uninit sequence for geminilake 6ada4b4 drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilake 819a098 drm/i915/glk: Reuse broxton's cdclk code for GLK aa98396 drm/i915/glk: Update Port PLL enable sequence for Geminilkae da9e47e drm/i915/glk: Set DCC delay range 2 in PLL enable sequence a59b507 drm/i915/glk: Implement Geminilake DDI init sequence 39714d8 drm/i915/glk: Add power wells for Geminilake 9b3c48c drm/i915/glk: Reuse broxton code for geminilake == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3168/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc for intel_guc_fini
On Fri, Dec 02, 2016 at 08:43:53AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Recent refactoring forgot to update this one.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: bf9e8429ab97 ("drm/i915: Make various init functions take dev_priv")
> Cc: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-gfx@lists.freedesktop.org
> ---
> drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 260ffe5e693b..21db69705458 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -773,7 +773,7 @@ void intel_guc_init(struct drm_i915_private *dev_priv)
>
> /**
> * intel_guc_fini() - clean up all allocated resources
> - * @dev: drm device
> + * @dev_priv:i915 device private
Can't even think of a nitpick, aside from not enough coffee yet for
Friday morning.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add some unit tests for the breadcrumb rbtree
First retroactive test, make sure that the waiters are in global seqno
order after random inserts and removals.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_selftests.h| 1 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 161 +++
2 files changed, 162 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_selftests.h
b/drivers/gpu/drm/i915/i915_selftests.h
index 3f8015c8a520..9562ec81c781 100644
--- a/drivers/gpu/drm/i915/i915_selftests.h
+++ b/drivers/gpu/drm/i915/i915_selftests.h
@@ -8,4 +8,5 @@
*
* Tests are executed in reverse order by igt/drv_selftest
*/
+selftest(breadcrumbs, intel_breadcrumbs_selftest)
selftest(sanitycheck, i915_selftest_sanitycheck) /* keep last */
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 53ae7884babd..604ccd618ac8 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -25,6 +25,7 @@
#include
#include "i915_drv.h"
+#include "i915_selftest.h"
static void intel_breadcrumbs_hangcheck(unsigned long data)
{
@@ -661,3 +662,163 @@ unsigned int intel_breadcrumbs_busy(struct
drm_i915_private *i915)
return mask;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include
+
+static struct intel_engine_cs *mock_engine(const char *name)
+{
+ struct intel_engine_cs *engine;
+ static int id;
+
+ engine = kzalloc(sizeof(*engine) + 4096, GFP_KERNEL);
+ if (!engine)
+ return NULL;
+
+ /* minimal engine setup for seqno */
+ engine->name = name;
+ engine->id = id++;
+ engine->status_page.page_addr = (void *)(engine + 1);
+
+ /* minimal breadcrumbs init */
+ spin_lock_init(&engine->breadcrumbs.lock);
+
+ return engine;
+}
+
+static int *get_random_order(int count)
+{
+ int *order;
+ int n, r, tmp;
+
+ order = kmalloc_array(count, sizeof(*order), GFP_TEMPORARY);
+ if (!order)
+ return order;
+
+ for (n = 0; n < count; n++)
+ order[n] = n;
+
+ for (n = count - 1; n > 1; n--) {
+ r = get_random_int() % (n + 1);
+ if (r != n) {
+ tmp = order[n];
+ order[n] = order[r];
+ order[r] = tmp;
+ }
+ }
+
+ return order;
+}
+
+static int check_rbtree(struct intel_engine_cs *engine,
+ const unsigned long *bitmap,
+ struct intel_wait *waiters,
+ const int count)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ struct rb_node *rb;
+ int first;
+
+ if (&b->first_wait->node != rb_first(&b->waiters)) {
+ pr_err("First waiter does not match first element of
wait-tree\n");
+ return -EINVAL;
+ }
+
+ first = find_first_bit(bitmap, count);
+ for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
+ struct intel_wait *w = container_of(rb, typeof(*w), node);
+ int idx = w - waiters;
+
+ if (!test_bit(idx, bitmap)) {
+ pr_err("waiter[%d, seqno=%d] removed but still in
wait-tree\n",
+ idx, w->seqno);
+ return -EINVAL;
+ }
+
+ if (first != idx) {
+ pr_err("waiter[%d, seqno=%d] does not match expected
next element in tree [%d]\n",
+ idx, w->seqno, first);
+ return -EINVAL;
+ }
+
+ first = find_next_bit(bitmap, count, first + 1);
+ }
+
+ return 0;
+}
+
+static int igt_random_insert_remove(void)
+{
+ struct intel_engine_cs *engine;
+ struct intel_wait *waiters;
+ const int count = 4096;
+ int *in_order, *out_order;
+ unsigned long *bitmap;
+ int err = -ENOMEM;
+ int n;
+
+ engine = mock_engine("mock");
+ if (!engine)
+ goto out;
+
+ waiters = kmalloc_array(count, sizeof(*waiters), GFP_KERNEL);
+ if (!waiters)
+ goto out_engines;
+
+ bitmap = kzalloc(count / BITS_PER_LONG * sizeof(*bitmap), GFP_KERNEL);
+ if (!bitmap)
+ goto out_waiters;
+
+ in_order = get_random_order(count);
+ if (!in_order)
+ goto out_bitmap;
+
+ out_order = get_random_order(count);
+ if (!out_order)
+ goto out_order;
+
+ for (n = 0; n < count; n++)
+ intel_wait_init(&waiters[n], 0x1000 + n);
+
+ err = check_rbtree(engine, bitmap, waiters, count);
+ for (n = 0; n < count; n++) {
+ int i = in_order[n];
+
+ intel_engine_add_wait(engine, &waiters[i]);
+ __set_bit(i, bitmap);
+
+ err |= check_rbtree(engine, bitmap, waiters, count);
+ }
+ for (n = 0; n < count; n++) {
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix kerneldoc for intel_guc_fini
== Series Details == Series: drm/i915: Fix kerneldoc for intel_guc_fini URL : https://patchwork.freedesktop.org/series/16264/ State : success == Summary == Series 16264v1 drm/i915: Fix kerneldoc for intel_guc_fini https://patchwork.freedesktop.org/api/1.0/series/16264/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 58e999de1132de619056ee8fafccbbe7dfba3f4d drm-tip: 2016y-12m-02d-07h-55m-48s UTC integration manifest 214194a drm/i915: Fix kerneldoc for intel_guc_fini == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3169/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915: Zero out HOWM registers before writing new WM/HOWM register values
On Thu, Dec 01, 2016 at 03:43:07PM +0100, Maarten Lankhorst wrote: > Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä > > > > On VLV/CHV some of the watermark values are split across two registers: > > low order bits in one, and high order bits in another. So we may not be > > able to update a single watermark value atomically, and thus we must be > > careful that we don't temporarily introduce out of bounds values during > > the reprogramming. To prevent this we can simply zero out all the high > > order bits initially, then we update the low order bits, and finally > > we update the high order bits with the final value. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_pm.c | 17 +++-- > > 1 file changed, 11 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > b/drivers/gpu/drm/i915/intel_pm.c > > index 9f25f2195a6a..8a3441bbff30 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -877,6 +877,17 @@ static void vlv_write_wm_values(struct intel_crtc > > *crtc, > >(wm->ddl[pipe].plane[PLANE_SPRITE0] << DDL_SPRITE_SHIFT(0)) | > >(wm->ddl[pipe].plane[PLANE_PRIMARY] << DDL_PLANE_SHIFT)); > > > > + /* > > +* Zero the (unused) WM1 watermarks, and also clear all the > > +* high order bits so that there are no out of bounds values > > +* present in the registers during the reprogramming. > > +*/ > > + I915_WRITE(DSPHOWM, 0); > > + I915_WRITE(DSPHOWM1, 0); > > + I915_WRITE(DSPFW4, 0); > > + I915_WRITE(DSPFW5, 0); > > + I915_WRITE(DSPFW6, 0); > Watermarks for DSPHOWM are inverted right? And lower values just mean more > wakeups? Yes, it's all inverted. > Should be harmless then. > > Reviewed-by: Maarten Lankhorst > > I915_WRITE(DSPFW1, > >FW_WM(wm->sr.plane, SR) | > >FW_WM(wm->pipe[PIPE_B].plane[PLANE_CURSOR], CURSORB) | > > @@ -924,12 +935,6 @@ static void vlv_write_wm_values(struct intel_crtc > > *crtc, > >FW_WM(wm->pipe[PIPE_A].plane[PLANE_PRIMARY] >> 8, > > PLANEA_HI)); > > } > > > > - /* zero (unused) WM1 watermarks */ > > - I915_WRITE(DSPFW4, 0); > > - I915_WRITE(DSPFW5, 0); > > - I915_WRITE(DSPFW6, 0); > > - I915_WRITE(DSPHOWM1, 0); > > - > > POSTING_READ(DSPFW1); > > } > > > -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix kerneldoc for intel_guc_fini
On 02/12/2016 09:45, Patchwork wrote: == Series Details == Series: drm/i915: Fix kerneldoc for intel_guc_fini URL : https://patchwork.freedesktop.org/series/16264/ State : success == Summary == Series 16264v1 drm/i915: Fix kerneldoc for intel_guc_fini https://patchwork.freedesktop.org/api/1.0/series/16264/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 58e999de1132de619056ee8fafccbbe7dfba3f4d drm-tip: 2016y-12m-02d-07h-55m-48s UTC integration manifest 214194a drm/i915: Fix kerneldoc for intel_guc_fini Merged, thanks for the review. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Protect DSPARB registers with a spinlock
On Thu, Dec 01, 2016 at 03:45:35PM +0100, Maarten Lankhorst wrote:
> Op 01-12-16 om 14:13 schreef Ville Syrjälä:
> > On Thu, Dec 01, 2016 at 12:56:16PM +0100, Maarten Lankhorst wrote:
> >> Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> >>> From: Ville Syrjälä
> >>>
> >>> Each DSPARB register can house bits for two separate pipes, hence
> >>> we must protect the registers during reprogramming so that parallel
> >>> FIFO reconfigurations happening simultaneosly on multiple pipes won't
> >>> corrupt each others values.
> >>>
> >>> Signed-off-by: Ville Syrjälä
> >>> ---
> >>> drivers/gpu/drm/i915/i915_drv.c | 1 +
> >>> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> >>> drivers/gpu/drm/i915/intel_pm.c | 6 ++
> >>> 3 files changed, 10 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >>> b/drivers/gpu/drm/i915/i915_drv.c
> >>> index 0fba4bb5655e..c98032e9112b 100644
> >>> --- a/drivers/gpu/drm/i915/i915_drv.c
> >>> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >>> @@ -811,6 +811,7 @@ static int i915_driver_init_early(struct
> >>> drm_i915_private *dev_priv,
> >>> spin_lock_init(&dev_priv->uncore.lock);
> >>> spin_lock_init(&dev_priv->mm.object_stat_lock);
> >>> spin_lock_init(&dev_priv->mmio_flip_lock);
> >>> + spin_lock_init(&dev_priv->wm.dsparb_lock);
> >> Can we make sure all wm updates are done with dev_priv->wm.wm_mutex held
> >> instead?
> > We can't grab a mutex from the vblank evade critical section. We'd have
> > to hold the mutex across the whole thing then. Not sure if that would be
> > a good or a bad thing.
> Ah right, I missed that part since it didn't happen in the patches yet, might
> be worth pointing out in the commit message.
Right. A bit of tunnel vision on my part here. I'll plop in a note about it.
>
> Will vlv_wm_values also be updated with that lock in the future? Looks like
> it could be a fun race otherwise.
Yes, wm_mutex will be protecting all the global wm state.
> >> gen9 wm's and ilk wm's use that mutex, for similar reasons.
> >>> mutex_init(&dev_priv->sb_lock);
> >>> mutex_init(&dev_priv->modeset_restore_lock);
> >>> mutex_init(&dev_priv->av_mutex);
> >>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>> b/drivers/gpu/drm/i915/i915_drv.h
> >>> index 9d808b706824..75439e9a67f7 100644
> >>> --- a/drivers/gpu/drm/i915/i915_drv.h
> >>> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >>> @@ -2169,6 +2169,9 @@ struct drm_i915_private {
> >>> } sagv_status;
> >>>
> >>> struct {
> >>> + /* protects DSPARB registers on pre-g4x/vlv/chv */
> >>> + spinlock_t dsparb_lock;
> >>> +
> >>> /*
> >>>* Raw watermark latency values:
> >>>* in 0.1us units for WM0,
> >>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >>> b/drivers/gpu/drm/i915/intel_pm.c
> >>> index 24d85a4e4ed3..9f25f2195a6a 100644
> >>> --- a/drivers/gpu/drm/i915/intel_pm.c
> >>> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >>> @@ -1215,6 +1215,8 @@ static void vlv_pipe_set_fifo_size(struct
> >>> intel_crtc *crtc)
> >>> pipe_name(crtc->pipe), sprite0_start,
> >>> sprite1_start, fifo_size);
> >>>
> >>> + spin_lock(&dev_priv->wm.dsparb_lock);
> >>> +
> >>> switch (crtc->pipe) {
> >>> uint32_t dsparb, dsparb2, dsparb3;
> >>> case PIPE_A:
> >>> @@ -1271,6 +1273,10 @@ static void vlv_pipe_set_fifo_size(struct
> >>> intel_crtc *crtc)
> >>> default:
> >>> break;
> >>> }
> >>> +
> >>> + POSTING_READ(DSPARB);
> >>> +
> >>> + spin_unlock(&dev_priv->wm.dsparb_lock);
> >>> }
> >>>
> >>> #undef VLV_FIFO
>
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm/i915: Pass crtc state to vlv_compute_wm_level()
On Thu, Dec 01, 2016 at 03:47:55PM +0100, Maarten Lankhorst wrote:
> Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > Rather than accessing crtc->config in vlv_compute_wm_level() let's
> > pass in the crtc state explicitly. One step closer to atomic.
> >
> > Signed-off-by: Ville Syrjälä
> Yay. All users of intel_crtc->config have to die in the future, but this is
> temporarily a legit use for it.
>
> For patch 13, 14 and 15
>
> Reviewed-by: Maarten Lankhorst
> > drivers/gpu/drm/i915/intel_pm.c | 20 +++-
> > 1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 291843c2b61b..2a2aa8968b93 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -978,24 +978,26 @@ static void vlv_setup_wm_latency(struct
> > drm_i915_private *dev_priv)
> > }
> > }
> >
> > -static uint16_t vlv_compute_wm_level(struct intel_plane *plane,
> > -struct intel_crtc *crtc,
> > -const struct intel_plane_state *state,
> > +static uint16_t vlv_compute_wm_level(const struct intel_crtc_state
> > *crtc_state,
> > +const struct intel_plane_state
> > *plane_state,
> > int level)
> > {
> > + struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > + const struct drm_display_mode *adjusted_mode =
> > + &crtc_state->base.adjusted_mode;
> > int clock, htotal, cpp, width, wm;
> >
> > if (dev_priv->wm.pri_latency[level] == 0)
> > return USHRT_MAX;
> >
> > - if (!state->base.visible)
> > + if (!plane_state->base.visible)
> > return 0;
> >
> > - cpp = drm_format_plane_cpp(state->base.fb->pixel_format, 0);
> > - clock = crtc->config->base.adjusted_mode.crtc_clock;
> > - htotal = crtc->config->base.adjusted_mode.crtc_htotal;
> > - width = crtc->config->pipe_src_w;
> > + cpp = drm_format_plane_cpp(plane_state->base.fb->pixel_format, 0);
> > + clock = adjusted_mode->crtc_clock;
> > + htotal = adjusted_mode->crtc_htotal;
> > + width = crtc_state->pipe_src_w;
> > if (WARN_ON(htotal == 0))
> > htotal = 1;
> >
> > @@ -1145,7 +1147,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
> >
> > /* normal watermarks */
> > for (level = 0; level < wm_state->num_levels; level++) {
> > - int wm = vlv_compute_wm_level(plane, crtc, state,
> > level);
> > + int wm = vlv_compute_wm_level(crtc->config, state,
> > level);
> > int max_wm = plane->wm.fifo_size;
> >
> > /* hack */
>
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight
The primary consumer of the lpss pwm is the i915 kms driver, but
currently that driver cannot get the pwm because i915 platforms are
not using devicetree and pwm-lpss does not call pwm_add_table.
Another problem is that i915 does not support get_pwm returning
-EPROBE_DEFER and i915's init is very complex and this is almost
impossible to fix.
This commit changes the PWM_LPSS Kconfig from a tristate to a bool, so
that when the i915 driver loads the lpss pwm will be available avoiding
the -EPROBE_DEFER issue. Note that this is identical to how the same
problem was solved for the pwm-crc driver.
Being builtin also allows calling pwm_add_table directly from the
pwm-lpss code, otherwise the pwm_add_table call would need to be put
somewhere else to ensure it happens before i915 calls pwm_get,
even if i915 would support -EPROBE_DEFER.
Signed-off-by: Hans de Goede
---
drivers/pwm/Kconfig| 12 +++-
drivers/pwm/pwm-lpss.c | 11 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index bf01288..cda31ea 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -240,28 +240,22 @@ config PWM_LPC32XX
will be called pwm-lpc32xx.
config PWM_LPSS
- tristate
+ bool
config PWM_LPSS_PCI
- tristate "Intel LPSS PWM PCI driver"
+ bool "Intel LPSS PWM PCI driver"
depends on X86 && PCI
select PWM_LPSS
help
The PCI driver for Intel Low Power Subsystem PWM controller.
- To compile this driver as a module, choose M here: the module
- will be called pwm-lpss-pci.
-
config PWM_LPSS_PLATFORM
- tristate "Intel LPSS PWM platform driver"
+ bool "Intel LPSS PWM platform driver"
depends on X86 && ACPI
select PWM_LPSS
help
The platform driver for Intel Low Power Subsystem PWM controller.
- To compile this driver as a module, choose M here: the module
- will be called pwm-lpss-platform.
-
config PWM_MESON
tristate "Amlogic Meson PWM driver"
depends on ARCH_MESON
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 72c0bce..b4d8835 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -161,6 +161,12 @@ static const struct pwm_ops pwm_lpss_ops = {
.owner = THIS_MODULE,
};
+/* PWM consumed by the Intel GFX */
+static struct pwm_lookup pwm_lpss_lookup[] = {
+ PWM_LOOKUP("pwm-lpss", 0, ":00:02.0", "pwm_backlight", 0,
+ PWM_POLARITY_NORMAL),
+};
+
struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
const struct pwm_lpss_boardinfo *info)
{
@@ -193,12 +199,17 @@ struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
struct resource *r,
return ERR_PTR(ret);
}
+ /* Add lookup table for pwm_backlight */
+ pwm_lpss_lookup[0].provider = dev_name(dev);
+ pwm_add_table(pwm_lpss_lookup, ARRAY_SIZE(pwm_lpss_lookup));
+
return lpwm;
}
EXPORT_SYMBOL_GPL(pwm_lpss_probe);
int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
{
+ pwm_remove_table(pwm_lpss_lookup, ARRAY_SIZE(pwm_lpss_lookup));
return pwmchip_remove(&lpwm->chip);
}
EXPORT_SYMBOL_GPL(pwm_lpss_remove);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] pwm: lpss: Add get_state callback
Add a get_state callback so that the initial state correctly reflects
the actual hardware state.
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-lpss.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index b4d8835..f5603c0 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -135,6 +135,33 @@ static int pwm_lpss_config(struct pwm_chip *chip, struct
pwm_device *pwm,
return 0;
}
+static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct pwm_lpss_chip *lpwm = to_lpwm(chip);
+ unsigned long base_unit_range, freq;
+ unsigned long long base_unit, on_time_div;
+ u32 ctrl;
+
+ base_unit_range = BIT(lpwm->info->base_unit_bits);
+
+ ctrl = pwm_lpss_read(pwm);
+ on_time_div = ctrl & PWM_ON_TIME_DIV_MASK;
+ base_unit = (ctrl >> PWM_BASE_UNIT_SHIFT) & (base_unit_range - 1);
+
+ freq = base_unit * lpwm->info->clk_rate / base_unit_range;
+ if (freq == 0)
+ freq = 1;
+
+ state->period = NSEC_PER_SEC / freq;
+ state->duty_cycle = state->period * on_time_div / 255ULL;
+ state->polarity = PWM_POLARITY_NORMAL;
+ state->enabled = (ctrl & PWM_ENABLE) ? true : false;
+
+ if (state->enabled)
+ pm_runtime_get_sync(chip->dev);
+}
+
static int pwm_lpss_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
pm_runtime_get_sync(chip->dev);
@@ -156,6 +183,7 @@ static void pwm_lpss_disable(struct pwm_chip *chip, struct
pwm_device *pwm)
static const struct pwm_ops pwm_lpss_ops = {
.config = pwm_lpss_config,
+ .get_state = pwm_lpss_get_state,
.enable = pwm_lpss_enable,
.disable = pwm_lpss_disable,
.owner = THIS_MODULE,
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make i915_suspend_switcheroo static
Looks like this was missed when unexporting, so let's keep sparse happy.
Cc: Tvrtko Ursulin
Fixes: 7f26cb88014a ("drm/i915: Unexport VGA switcheroo functions")
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ace9be8f6ff9..ae583c79c19f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1522,7 +1522,7 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
return ret;
}
-int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state)
+static int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state)
{
int error;
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make i915_suspend_switcheroo static
On 02/12/2016 10:24, Matthew Auld wrote:
Looks like this was missed when unexporting, so let's keep sparse happy.
Cc: Tvrtko Ursulin
Fixes: 7f26cb88014a ("drm/i915: Unexport VGA switcheroo functions")
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ace9be8f6ff9..ae583c79c19f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1522,7 +1522,7 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
return ret;
}
-int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state)
+static int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state)
{
int error;
Gah.. sorry, another half distracted. Thanks for fixing it.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: give gen8_setup_page_directory or more accurate name
The function name gen8_setup_page_directory is misleading, and only
serves to confuse the reader, it's not setting up a pd, but rather
encoding a specific pdpe with a given pd.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 02fb063302bf..967537798b1f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -627,10 +627,10 @@ static void gen8_initialize_pml4(struct
i915_address_space *vm,
}
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_setup_pdpe(struct i915_hw_ppgtt *ppgtt,
+ struct i915_page_directory_pointer *pdp,
+ struct i915_page_directory *pd,
+ int index)
{
gen8_ppgtt_pdpe_t *page_directorypo;
@@ -1376,7 +1376,7 @@ static int gen8_alloc_va_range_3lvl(struct
i915_address_space *vm,
kunmap_px(ppgtt, page_directory);
__set_bit(pdpe, pdp->used_pdpes);
- gen8_setup_page_directory(ppgtt, pdp, pd, pdpe);
+ gen8_setup_pdpe(ppgtt, pdp, pd, pdpe);
}
free_gen8_temp_bitmaps(new_page_dirs, new_page_tables);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: give gen8_setup_page_directory_pointer or more accurate name
The function name gen8_setup_page_directory_pointer is misleading, and only
serves to confuse the reader, it's not setting up a pdp, but
rather encoding a specific pml4e with a given pdp.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 967537798b1f..1ec44f95479e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -643,10 +643,10 @@ gen8_setup_pdpe(struct i915_hw_ppgtt *ppgtt,
}
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_setup_pml4e(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);
@@ -1435,7 +1435,7 @@ static int gen8_alloc_va_range_4lvl(struct
i915_address_space *vm,
if (ret)
goto err_out;
- gen8_setup_page_directory_pointer(ppgtt, pml4, pdp, pml4e);
+ gen8_setup_pml4e(ppgtt, pml4, pdp, pml4e);
}
bitmap_or(pml4->used_pml4es, new_pdps, pml4->used_pml4es,
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences
On Thu, 01 Dec 2016, Hans de Goede wrote: > The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are > not fine grained enough to abstract all the different steps we need to > take (and VBT sequences we need to exec) properly. So simply remove the > panel _enable/disable and prepare/unprepare callbacks and instead > export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c > and call that from intel_dsi_enable/disable(). > > No functional changes. No functional changes, but this is quite a big design change between intel_dsi.c and intel_dsi_panel_vbt.c. Originally the idea was to separate the dsi core code and the panel specific code, letting one write a panel driver that was not based on values in VBT. This patch changes that. Now I'm not sure if there'll ever be a panel driver not based on VBT, and perhaps the current drm_panel based interface between two is not enough in the end, nor prettiest. But after this patch, we might just as well throw out the drm_panel interface, and refactor the division between the two files completely. Indeed, if we accept the direction set in this patch, that refactoring would be the logical next step. I have not made up my mind about this yet. An alternative would be to amend the drm_panel interface to achieve the kind of granularity you're after in the follow-up patches. Indeed, such patches have been sent in the past. BR, Jani. > > Signed-off-by: Hans de Goede > --- > drivers/gpu/drm/i915/intel_dsi.c | 14 +++--- > drivers/gpu/drm/i915/intel_dsi.h | 3 +++ > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 > ++ > 3 files changed, 15 insertions(+), 45 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > b/drivers/gpu/drm/i915/intel_dsi.c > index 85b748d..cf761e8 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.c > +++ b/drivers/gpu/drm/i915/intel_dsi.c > @@ -656,7 +656,10 @@ static void intel_dsi_pre_enable(struct intel_encoder > *encoder, > /* put device in ready state */ > intel_dsi_device_ready(encoder); > > - drm_panel_prepare(intel_dsi->panel); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); > > /* Enable port in pre-enable phase itself because as per hw team >* recommendation, port should be enabled befor plane & pipe */ > @@ -669,7 +672,8 @@ static void intel_dsi_pre_enable(struct intel_encoder > *encoder, > dpi_send_cmd(intel_dsi, TURN_ON, false, port); > msleep(100); > > - drm_panel_enable(intel_dsi->panel); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON); > > intel_dsi_port_enable(encoder); > } > @@ -732,7 +736,8 @@ static void intel_dsi_post_disable(struct intel_encoder > *encoder, >* if disable packets are sent before sending shutdown packet then in >* some next enable sequence send turn on packet error is observed >*/ > - drm_panel_disable(intel_dsi->panel); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF); > > intel_dsi_clear_device_ready(encoder); > > @@ -746,7 +751,8 @@ static void intel_dsi_post_disable(struct intel_encoder > *encoder, > I915_WRITE(DSPCLK_GATE_D, val); > } > > - drm_panel_unprepare(intel_dsi->panel); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); > + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF); > > msleep(intel_dsi->panel_off_delay); > > diff --git a/drivers/gpu/drm/i915/intel_dsi.h > b/drivers/gpu/drm/i915/intel_dsi.h > index d567823..5486491 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.h > +++ b/drivers/gpu/drm/i915/intel_dsi.h > @@ -132,6 +132,9 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct > drm_encoder *encoder) > > void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port port); > > +void intel_dsi_exec_vbt_sequence(struct intel_dsi *intel_dsi, > + enum mipi_seq seq_id); > + > bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv); > int intel_compute_dsi_pll(struct intel_encoder *encoder, > struct intel_crtc_state *config); > diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > index b5a02c6..f71f913 100644 > --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c > @@ -400,10 +400,9 @@ static const char *sequence_name(enum mipi_seq seq_id) > return "(unknown)"; > } > > -static void generic_e
Re: [Intel-gfx] [PATCH 08/18] drm/i915/dsi: Document the panel enable / disable sequences from the spec
On Thu, 01 Dec 2016, Hans de Goede wrote: > Document the DSI panel enable / disable sequences from the spec, > for easy comparison between the code and the spec. > > Signed-off-by: Hans de Goede I haven't done a proper review, but patches 1-8 are Acked-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dsi.c | 64 > > 1 file changed, 64 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > b/drivers/gpu/drm/i915/intel_dsi.c > index 229..85b748d 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.c > +++ b/drivers/gpu/drm/i915/intel_dsi.c > @@ -555,6 +555,70 @@ static void intel_dsi_prepare(struct intel_encoder > *intel_encoder, > struct intel_crtc_state *pipe_config); > static void intel_dsi_unprepare(struct intel_encoder *encoder); > > +/* > + * Panel enable/disable sequences from the spec: > + * > + * v2 sequence for video mode: > + * - power on > + * - wait t1+t2 > + * - MIPIDeassertResetPin > + * - clk/data lines to lp-11 > + * - MIPISendInitialDcsCmds > + * - turn on DPI > + * - MIPIDisplayOn > + * - wait t5 > + * - backlight on > + * ... > + * - backlight off > + * - wait t6 > + * - MIPIDisplayOff > + * - turn off DPI > + * - clk/data lines to lp-00 > + * - MIPIAssertResetPin > + * - wait t3 > + * - power off > + * - wait t4 > + * > + * v3 sequence for video mode: > + * - MIPIPanelPowerOn > + * - MIPIDeassertResetPin > + * - set clk/data lines to lp-11 > + * - MIPISendInitialDcsCmds (LP) > + * - turn on DPI > + * - MIPITearOn (command mode only) + MIPIDisplayOn (LP and HS) > + * - MIPIBacklightOn > + * ... > + * - MIPIBacklightOff > + * - turn off DPI > + * - MIPITearOff + MIPIDisplayOff (LP) > + * - clk/data lines to lp-00 > + * - MIPIAssertResetPin > + * - MIPIPanelPowerOff > + * > + * sequence for command mode: > + * - power on > + * - wait t1+t2 > + * - MIPIDeassertResetPin > + * - clk/data lines to lp-11 > + * - MIPISendInitialDcsCmds > + * - MIPITearOn > + * - MIPIDisplayOn > + * - set pipe to dsr mode > + * - wait t5 > + * - backlight on > + * ... issue write_mem_start/write_mem_continue commands ... > + * - backlight off > + * - wait t6 > + * - disable pipe dsr mode > + * - MIPITearOff > + * - MIPIDisplayOff > + * - clk/data lines to lp-00 > + * - MIPIAssertResetPin > + * - wait t3 > + * - power off > + * - wait t4 > + */ > + > static void intel_dsi_pre_enable(struct intel_encoder *encoder, >struct intel_crtc_state *pipe_config, >struct drm_connector_state *conn_state) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: give gen8_setup_page_directory_pointer or more accurate name
On Fri, Dec 02, 2016 at 10:30:21AM +, Matthew Auld wrote: > The function name gen8_setup_page_directory_pointer is misleading, and only > serves to confuse the reader, it's not setting up a pdp, but > rather encoding a specific pml4e with a given pdp. > > Signed-off-by: Matthew Auld Both need s/or/a/ in subject Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight
On Fri, 02 Dec 2016, Hans de Goede wrote:
> The primary consumer of the lpss pwm is the i915 kms driver, but
> currently that driver cannot get the pwm because i915 platforms are
> not using devicetree and pwm-lpss does not call pwm_add_table.
>
> Another problem is that i915 does not support get_pwm returning
> -EPROBE_DEFER and i915's init is very complex and this is almost
> impossible to fix.
>
> This commit changes the PWM_LPSS Kconfig from a tristate to a bool, so
> that when the i915 driver loads the lpss pwm will be available avoiding
> the -EPROBE_DEFER issue. Note that this is identical to how the same
> problem was solved for the pwm-crc driver.
Arguably this solution was worse for pwm-crc than pwm-lpss here, because
bool CONFIG_PWM_CRC depends on INTEL_SOC_PMIC which depends on I2C being
built-in. This one doesn't have all that bad dependencies.
FWIW, both patches are
Acked-by: Jani Nikula
>
> Being builtin also allows calling pwm_add_table directly from the
> pwm-lpss code, otherwise the pwm_add_table call would need to be put
> somewhere else to ensure it happens before i915 calls pwm_get,
> even if i915 would support -EPROBE_DEFER.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/pwm/Kconfig| 12 +++-
> drivers/pwm/pwm-lpss.c | 11 +++
> 2 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index bf01288..cda31ea 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -240,28 +240,22 @@ config PWM_LPC32XX
> will be called pwm-lpc32xx.
>
> config PWM_LPSS
> - tristate
> + bool
>
> config PWM_LPSS_PCI
> - tristate "Intel LPSS PWM PCI driver"
> + bool "Intel LPSS PWM PCI driver"
> depends on X86 && PCI
> select PWM_LPSS
> help
> The PCI driver for Intel Low Power Subsystem PWM controller.
>
> - To compile this driver as a module, choose M here: the module
> - will be called pwm-lpss-pci.
> -
> config PWM_LPSS_PLATFORM
> - tristate "Intel LPSS PWM platform driver"
> + bool "Intel LPSS PWM platform driver"
> depends on X86 && ACPI
> select PWM_LPSS
> help
> The platform driver for Intel Low Power Subsystem PWM controller.
>
> - To compile this driver as a module, choose M here: the module
> - will be called pwm-lpss-platform.
> -
> config PWM_MESON
> tristate "Amlogic Meson PWM driver"
> depends on ARCH_MESON
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 72c0bce..b4d8835 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -161,6 +161,12 @@ static const struct pwm_ops pwm_lpss_ops = {
> .owner = THIS_MODULE,
> };
>
> +/* PWM consumed by the Intel GFX */
> +static struct pwm_lookup pwm_lpss_lookup[] = {
> + PWM_LOOKUP("pwm-lpss", 0, ":00:02.0", "pwm_backlight", 0,
> +PWM_POLARITY_NORMAL),
> +};
> +
> struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
>const struct pwm_lpss_boardinfo *info)
> {
> @@ -193,12 +199,17 @@ struct pwm_lpss_chip *pwm_lpss_probe(struct device
> *dev, struct resource *r,
> return ERR_PTR(ret);
> }
>
> + /* Add lookup table for pwm_backlight */
> + pwm_lpss_lookup[0].provider = dev_name(dev);
> + pwm_add_table(pwm_lpss_lookup, ARRAY_SIZE(pwm_lpss_lookup));
> +
> return lpwm;
> }
> EXPORT_SYMBOL_GPL(pwm_lpss_probe);
>
> int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
> {
> + pwm_remove_table(pwm_lpss_lookup, ARRAY_SIZE(pwm_lpss_lookup));
> return pwmchip_remove(&lpwm->chip);
> }
> EXPORT_SYMBOL_GPL(pwm_lpss_remove);
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: remove redundant warnings
If we've gotten this far then we must have already checked if the vma can fit into the vm when we inserted the mm node, and in turn must have also checked for the overflow. Cc: Chris Wilson Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 02fb063302bf..a3c17a04b883 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -1304,15 +1304,6 @@ static int gen8_alloc_va_range_3lvl(struct i915_address_space *vm, uint32_t pdpes = I915_PDPES_PER_PDP(dev_priv); int ret; - /* Wrap is never okay since we can only represent 48b, and we don't -* actually use the other side of the canonical address space. -*/ - if (WARN_ON(start + length < start)) - return -ENODEV; - - if (WARN_ON(start + length > vm->total)) - return -ENODEV; - ret = alloc_gen8_temp_bitmaps(&new_page_dirs, &new_page_tables, pdpes); if (ret) return ret; -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make i915_suspend_switcheroo static
== Series Details == Series: drm/i915: make i915_suspend_switcheroo static URL : https://patchwork.freedesktop.org/series/16269/ State : success == Summary == Series 16269v1 drm/i915: make i915_suspend_switcheroo static https://patchwork.freedesktop.org/api/1.0/series/16269/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 f13868539d56703427fdce7f532907c22252f12f drm-tip: 2016y-12m-02d-09h-56m-05s UTC integration manifest d824940 drm/i915: make i915_suspend_switcheroo static == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3170/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: s/gen8_setup_page_directory/gen8_setup_pdpe/
The function name gen8_setup_page_directory is misleading, and only
serves to confuse the reader, it's not setting up a pd, but rather
encoding a specific pdpe with a given pd.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 02fb063302bf..967537798b1f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -627,10 +627,10 @@ static void gen8_initialize_pml4(struct
i915_address_space *vm,
}
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_setup_pdpe(struct i915_hw_ppgtt *ppgtt,
+ struct i915_page_directory_pointer *pdp,
+ struct i915_page_directory *pd,
+ int index)
{
gen8_ppgtt_pdpe_t *page_directorypo;
@@ -1376,7 +1376,7 @@ static int gen8_alloc_va_range_3lvl(struct
i915_address_space *vm,
kunmap_px(ppgtt, page_directory);
__set_bit(pdpe, pdp->used_pdpes);
- gen8_setup_page_directory(ppgtt, pdp, pd, pdpe);
+ gen8_setup_pdpe(ppgtt, pdp, pd, pdpe);
}
free_gen8_temp_bitmaps(new_page_dirs, new_page_tables);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: s/gen8_setup_page_directory_pointer/gen8_setup_pml4e/
The function name gen8_setup_page_directory_pointer is misleading, and
only serves to confuse the reader, it's not setting up a pdp, but
rather encoding a specific pml4e with a given pdp.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 967537798b1f..1ec44f95479e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -643,10 +643,10 @@ gen8_setup_pdpe(struct i915_hw_ppgtt *ppgtt,
}
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_setup_pml4e(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);
@@ -1435,7 +1435,7 @@ static int gen8_alloc_va_range_4lvl(struct
i915_address_space *vm,
if (ret)
goto err_out;
- gen8_setup_page_directory_pointer(ppgtt, pml4, pdp, pml4e);
+ gen8_setup_pml4e(ppgtt, pml4, pdp, pml4e);
}
bitmap_or(pml4->used_pml4es, new_pdps, pml4->used_pml4es,
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove redundant warnings
On Fri, Dec 02, 2016 at 10:58:38AM +, Matthew Auld wrote: > If we've gotten this far then we must have already checked if the > vma can fit into the vm when we inserted the mm node, and in turn > must have also checked for the overflow. > > Cc: Chris Wilson > Signed-off-by: Matthew Auld The sanitychecks are a reasonable idea, since the result can be catastrophic - but they are rather piecemeal and not desired in production (just CI, and we want some really abusive test cases, of which we already have a small selection). I'd rather see these become GEM_BUG_ON (or GEM_WARN_ON) and more complete coverage of the callbacks. i915_vma_bind() would give complete coverage with minimal testing. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make i915_suspend_switcheroo static
On 02/12/2016 11:15, Patchwork wrote: == Series Details == Series: drm/i915: make i915_suspend_switcheroo static URL : https://patchwork.freedesktop.org/series/16269/ State : success == Summary == Series 16269v1 drm/i915: make i915_suspend_switcheroo static https://patchwork.freedesktop.org/api/1.0/series/16269/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 f13868539d56703427fdce7f532907c22252f12f drm-tip: 2016y-12m-02d-09h-56m-05s UTC integration manifest d824940 drm/i915: make i915_suspend_switcheroo static Pushed. Thanks again for cleaning up after me. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Calculate common rates and max lane count in Long pulse handler
> == Series Details == > > Series: drm/i915: Calculate common rates and max lane count in Long pulse > handler > URL : https://patchwork.freedesktop.org/series/16250/ > State : warning > > == Summary == > > Series 16250v1 drm/i915: Calculate common rates and max lane count in > Long pulse handler > https://patchwork.freedesktop.org/api/1.0/series/16250/revisions/1/mbox/ > > Test kms_flip: > Subgroup basic-flip-vs-wf_vblank: > pass -> DMESG-WARN (fi-ivb-3770) *ERROR* EDID checksum is invalid, remainder https://bugs.freedesktop.org/show_bug.cgi?id=98228 > Test kms_force_connector_basic: > Subgroup prune-stale-modes: > skip -> PASS (fi-snb-2600) > Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/8] drm/i915/bxt: Enable IPC support
Hi,
On Tuesday 22 November 2016 08:15 PM, Paulo Zanoni wrote:
Em Ter, 2016-11-22 às 19:05 +0530, Mahesh Kumar escreveu:
Hi,
On Tuesday 22 November 2016 12:16 AM, Paulo Zanoni wrote:
Em Sex, 2016-11-18 às 20:39 +0530, Mahesh Kumar escreveu:
This patch adds IPC support for platforms. This patch enables IPC
only for BXT/KBL platform as for SKL recommendation is to keep is
disabled.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controles the memory read priority of Display.
When IPC is enabled, plane read requests are sent at high
priority
until
filling above the transition watermark, then the requests are
sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have
better
memory access. When IPC is disabled, all plane read requests are
sent
at
high priority.
Changes since V1:
- Remove commandline parameter to disable ipc
- Address Paulo's comments
Changes since V2:
- Address review comments
- Set ipc_enabled flag
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 15 +++
4 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 1b0a589..4074601 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1244,6 +1244,7 @@ int i915_driver_load(struct pci_dev *pdev,
const struct pci_device_id *ent)
intel_runtime_pm_enable(dev_priv);
dev_priv->ipc_enabled = false;
+ intel_enable_ipc(dev_priv);
So now we have to places that touch dev_priv->ipc_enabled. This one
and
intel_enable_ipc(). Please move that "dev_priv->ipc_enabled =
false"
line to inside intel_enable_ipc(). It's much easier to read the
code
when there's a single function responsible for setting the
appropriate
value to a variable.
Besides, my understanding of your discussion with Maarten in the
last
revision of this patch was that we needed to change where
intel_enable_ipc() is called in order to make sure the bit stays
enabled after suspend/resume. If that's not needed, why is it not
needed?
We don't overwrite DISP_ARB_CTL2 register during suspend/resume
So there will not be any impact of it & handling during
suspend/resume
is not needed.
Just to make sure I understood: any value that our driver sets to this
register will persist after a suspend/resume cycle? That's not what I
was expecting. Usually after a suspend/resume cycle a lot of registers
are reset to their default value, so our driver needs to write them all
again.
Can you also confirm whether this is true during runtime PM?
Thanks,
Paulo
After discussing with HW team, My understanding was not fully correct.
HW/(DMC fw) does the restoring of registers only in case of DC5/6,
In case of DC9 sw need to take-care of restoring. Will add restore part
in intel_display_resume & intel_runtime_resume.
above two places are correct places for restoring?
Regards,
-Mahesh
thanks for review
Regards,
-Mahesh
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor
%d\n",
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index c70c07a..300418a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6076,6 +6076,7 @@ enum {
#define DISP_FBC_WM_DIS (1<<15)
#define DISP_ARB_CTL2_MMIO(0x45004)
#define DISP_DATA_PARTITION_5_6 (1<<6)
+#define DISP_IPC_ENABLE (1<<3)
#define DBUF_CTL _MMIO(0x45008)
#define DBUF_POWER_REQUEST (1<<31)
#define DBUF_POWER_STATE(1<<30)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index cd132c2..ad542a2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1745,6 +1745,7 @@ bool skl_ddb_allocation_overlaps(const
struct
skl_ddb_entry **entries,
uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state
*pipe_config);
bool ilk_disable_lp_wm(struct drm_device *dev);
int sanitize_rc6_option(struct drm_i915_private *dev_priv, int
enable_rc6);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
static inline int intel_enable_rc6(void)
{
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index df39b50..d8090aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4682,6 +4682,21 @@ void intel_update_watermarks(struct
intel_crtc
*crtc)
dev_priv->display.update_wm(crtc);
}
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
+ return;
+
+ val = I915_READ(DISP_ARB_CTL2);
+
+
[Intel-gfx] [RFCv2 1/3] drm/i915: Provide a hook for selftests
Some pieces of code are independent of hardware but are very tricky to
exercise through the normal userspace ABI or via debugfs hooks. Being
able to create mock unit tests and execute them through CI is vital.
Start by adding a central point where we can execute unit tests from and
a parameter to enable them. This is disabled by default as the
expectation is that these tests will occasionally explode.
To facilitate integration with igt, any parameter beginning with
i915.subtest__ is interpreted as a selftest subtest executable
independently via igt/drv_selftest.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug| 15 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_params.c| 5 ++
drivers/gpu/drm/i915/i915_params.h| 3 +
drivers/gpu/drm/i915/i915_pci.c | 6 ++
drivers/gpu/drm/i915/i915_selftest.c | 115 ++
drivers/gpu/drm/i915/i915_selftest.h | 54
drivers/gpu/drm/i915/i915_selftests.h | 11
8 files changed, 210 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_selftest.c
create mode 100644 drivers/gpu/drm/i915/i915_selftest.h
create mode 100644 drivers/gpu/drm/i915/i915_selftests.h
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index a6c69b8cb1d2..b48822288e22 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -23,6 +23,7 @@ config DRM_I915_DEBUG
select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
select DRM_DEBUG_MM if DRM=y
select DRM_I915_SW_FENCE_DEBUG_OBJECTS if DRM_I915=y
+ select DRM_I915_SELFTEST
default n
help
Choose this option to turn on extra driver debugging that may affect
@@ -56,3 +57,17 @@ config DRM_I915_SW_FENCE_DEBUG_OBJECTS
Recommended for driver developers only.
If in doubt, say "N".
+
+config DRM_I915_SELFTEST
+ bool "Enable selftests upon driver load"
+ depends on DRM_I915
+ default n
+ help
+ Choose this option to allow the driver to perform selftests upon
+ loading; also requires the i915.selftest=1 module parameter. To
+ exit the module after running the selftests (i.e. to prevent normal
+ module initialisation afterwards) use i915.selftest=-1.
+
+ Recommended for driver developers only.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3c30916727fb..7c3b4f0c836c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -114,6 +114,7 @@ i915-y += dvo_ch7017.o \
# Post-mortem debug and GPU hang state capture
i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
+i915-$(CONFIG_DRM_I915_SELFTEST) += i915_selftest.o
# virtual gpu code
i915-y += i915_vgpu.o
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 0e280fbd52f1..b66e38e66833 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -243,3 +243,8 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host
support(default:false)");
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+module_param_named_unsafe(selftest, i915.selftest, int, 0400);
+MODULE_PARM_DESC(selftest, "Run selftests when loading (0:disabled [default],
1 run tests then load module, -1 run tests then exit module)");
+#endif
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 8e433de04679..49ca8a6f9407 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -28,6 +28,9 @@
#include /* for __read_mostly */
struct i915_params {
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+ int selftest;
+#endif
int modeset;
int panel_ignore_lid;
int semaphores;
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 389a33090707..1683adb845ee 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -27,6 +27,7 @@
#include
#include "i915_drv.h"
+#include "i915_selftest.h"
#define GEN_DEFAULT_PIPEOFFSETS \
.pipe_offsets = { PIPE_A_OFFSET, PIPE_B_OFFSET, \
@@ -496,6 +497,11 @@ static struct pci_driver i915_pci_driver = {
static int __init i915_init(void)
{
bool use_kms = true;
+ int ret;
+
+ ret = i915_selftest();
+ if (ret)
+ return ret;
/*
* Enable KMS by default, unless explicitly overriden by
diff --git a/drivers/gpu/drm/i915/i915_selftest.c
b/drivers/gpu/drm/i915/i915_selftest.c
new file mode 100644
index ..684a1bcb54d1
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_selftest.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright © 2016 Intel Corporation
[Intel-gfx] [RFCv2 3/3] drm/i915: Add unit tests for the breadcrumb rbtree, completion
Second retroactive test, make sure that the waiters are removed from the
global wait-tree when their seqno completes.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 79
1 file changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 3eda013903d3..fff1eddc5020 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -849,10 +849,89 @@ static int igt_random_insert_remove(void *ignore)
return err;
}
+static void mock_seqno_advance(struct intel_engine_cs *engine, u32 seqno)
+{
+ intel_write_status_page(engine, I915_GEM_HWS_INDEX, seqno);
+}
+
+static int igt_insert_complete(void *ignore)
+{
+ struct intel_engine_cs *engine;
+ struct intel_wait *waiters;
+ const int count = 4096;
+ unsigned long *bitmap;
+ int err = -ENOMEM;
+ int n, m;
+
+ engine = mock_engine("mock");
+ if (!engine)
+ goto out;
+
+ waiters = kmalloc_array(count, sizeof(*waiters), GFP_KERNEL);
+ if (!waiters)
+ goto out_engines;
+
+ bitmap = kzalloc(DIV_ROUND_UP(count, BITS_PER_LONG) * sizeof(*bitmap),
+GFP_KERNEL);
+ if (!bitmap)
+ goto out_waiters;
+
+ for (n = 0; n < count; n++) {
+ intel_wait_init(&waiters[n], n + 0x1000);
+ intel_engine_add_wait(engine, &waiters[n]);
+ __set_bit(n, bitmap);
+ }
+ err = check_rbtree(engine, bitmap, waiters, count);
+ if (err)
+ goto err;
+
+ for (n = 0; n < count; n = m) {
+ int seqno = 2*n;
+
+ GEM_BUG_ON(find_first_bit(bitmap, count) != n);
+
+ if (intel_wait_complete(&waiters[n])) {
+ pr_err("waiter[%d, seqno=%d] completed too early\n",
+ n, waiters[n].seqno);
+ err = -EINVAL;
+ goto err;
+ }
+
+ /* complete the following waiters */
+ mock_seqno_advance(engine, seqno + 0x1000);
+ for (m = n; m <= seqno; m++) {
+ if (m == count)
+ break;
+
+ GEM_BUG_ON(!test_bit(m, bitmap));
+ __clear_bit(m, bitmap);
+ }
+
+ intel_engine_remove_wait(engine, &waiters[n]);
+ err = check_rbtree(engine, bitmap, waiters, count);
+ if (err) {
+ pr_err("completion after seqno advance to %d failed\n",
+ seqno);
+ goto err;
+ }
+ }
+
+ err = check_rbtree_empty(engine);
+err:
+ kfree(bitmap);
+out_waiters:
+ kfree(waiters);
+out_engines:
+ kfree(engine);
+out:
+ return err;
+}
+
int intel_breadcrumbs_selftest(void)
{
static const struct i915_subtest tests[] = {
SUBTEST(igt_random_insert_remove),
+ SUBTEST(igt_insert_complete),
};
return i915_subtests(tests, NULL);
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFCv2 2/3] drm/i915: Add unit tests for the breadcrumb rbtree, insert/remove
First retroactive test, make sure that the waiters are in global seqno
order after random inserts and removals.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_selftests.h| 1 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 197 +++
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
3 files changed, 199 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_selftests.h
b/drivers/gpu/drm/i915/i915_selftests.h
index 3f8015c8a520..9562ec81c781 100644
--- a/drivers/gpu/drm/i915/i915_selftests.h
+++ b/drivers/gpu/drm/i915/i915_selftests.h
@@ -8,4 +8,5 @@
*
* Tests are executed in reverse order by igt/drv_selftest
*/
+selftest(breadcrumbs, intel_breadcrumbs_selftest)
selftest(sanitycheck, i915_selftest_sanitycheck) /* keep last */
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 53ae7884babd..3eda013903d3 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -25,6 +25,7 @@
#include
#include "i915_drv.h"
+#include "i915_selftest.h"
static void intel_breadcrumbs_hangcheck(unsigned long data)
{
@@ -109,6 +110,11 @@ static void __intel_breadcrumbs_enable_irq(struct
intel_breadcrumbs *b)
if (b->rpm_wakelock)
return;
+ if (unlikely(b->mock)) {
+ b->rpm_wakelock = true;
+ return;
+ }
+
/* Since we are waiting on a request, the GPU should be busy
* and should have its own rpm reference. For completeness,
* record an rpm reference for ourselves to cover the
@@ -143,6 +149,11 @@ static void __intel_breadcrumbs_disable_irq(struct
intel_breadcrumbs *b)
if (!b->rpm_wakelock)
return;
+ if (unlikely(b->mock)) {
+ b->rpm_wakelock = false;
+ return;
+ }
+
if (b->irq_enabled) {
irq_disable(engine);
b->irq_enabled = false;
@@ -661,3 +672,189 @@ unsigned int intel_breadcrumbs_busy(struct
drm_i915_private *i915)
return mask;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include
+
+static struct intel_engine_cs *mock_engine(const char *name)
+{
+ struct intel_engine_cs *engine;
+ static int id;
+
+ engine = kzalloc(sizeof(*engine) + 4096, GFP_KERNEL);
+ if (!engine)
+ return NULL;
+
+ /* minimal engine setup for seqno */
+ engine->name = name;
+ engine->id = id++;
+ engine->status_page.page_addr = (void *)(engine + 1);
+
+ /* minimal breadcrumbs init */
+ spin_lock_init(&engine->breadcrumbs.lock);
+ engine->breadcrumbs.mock = true;
+
+ return engine;
+}
+
+static int *get_random_order(int count)
+{
+ int *order;
+ int n, r, tmp;
+
+ order = kmalloc_array(count, sizeof(*order), GFP_TEMPORARY);
+ if (!order)
+ return order;
+
+ for (n = 0; n < count; n++)
+ order[n] = n;
+
+ for (n = count - 1; n > 1; n--) {
+ r = get_random_int() % (n + 1);
+ if (r != n) {
+ tmp = order[n];
+ order[n] = order[r];
+ order[r] = tmp;
+ }
+ }
+
+ return order;
+}
+
+static int check_rbtree(struct intel_engine_cs *engine,
+ const unsigned long *bitmap,
+ const struct intel_wait *waiters,
+ const int count)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ struct rb_node *rb;
+ int first;
+
+ if (&b->first_wait->node != rb_first(&b->waiters)) {
+ pr_err("First waiter does not match first element of
wait-tree\n");
+ return -EINVAL;
+ }
+
+ first = find_first_bit(bitmap, count);
+ for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
+ struct intel_wait *w = container_of(rb, typeof(*w), node);
+ int idx = w - waiters;
+
+ if (!test_bit(idx, bitmap)) {
+ pr_err("waiter[%d, seqno=%d] removed but still in
wait-tree\n",
+ idx, w->seqno);
+ return -EINVAL;
+ }
+
+ if (first != idx) {
+ pr_err("waiter[%d, seqno=%d] does not match expected
next element in tree [%d]\n",
+ idx, w->seqno, first);
+ return -EINVAL;
+ }
+
+ first = find_next_bit(bitmap, count, first + 1);
+ }
+
+ return 0;
+}
+
+static int check_rbtree_empty(struct intel_engine_cs *engine)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+
+ if (b->first_wait != NULL) {
+ pr_err("Empty breadcrumbs still has a waiter\n");
+ return -EINVAL;
+ }
+
+ if (!RB_EMPTY_ROOT(&b->waiters)) {
+ pr_err("Empty
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: give gen8_setup_page_directory or more accurate name
== Series Details == Series: series starting with [1/2] drm/i915: give gen8_setup_page_directory or more accurate name URL : https://patchwork.freedesktop.org/series/16270/ State : success == Summary == Series 16270v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16270/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 273202788eba907049316b3ccc2f4d1fd30aff1d drm-tip: 2016y-12m-02d-11h-27m-42s UTC integration manifest ba18152 drm/i915: give gen8_setup_page_directory_pointer or more accurate name 2b777f4 drm/i915: give gen8_setup_page_directory or more accurate name == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3171/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: use DRM_DEBUG for userspace issues
On Fri, Dec 2, 2016 at 8:35 AM, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 05:21:52PM +, Robert Bragg wrote:
> > Avoid using DRM_ERROR for conditions userspace can trigger with a bad
> > config when opening a stream or from not reading data in a timely
> > fashion (whereby the OA buffer fills up). These conditions are tested
> > by i-g-t which treats error messages as failures if using the test
> > runner. This wasn't an issue while the i915-perf igt tests were being
> > run in isolation.
> >
> > One message relating to seeing a spurious zeroed report was changed to
> > use DRM_NOTE instead of DRM_ERROR. Ideally this warning shouldn't be
> > seen, but it's not a serious problem if it is. Considering that the
> > tail margin mechanism is only a heuristic it's possible we might see
> > this from time to time.
> >
> > Signed-off-by: Robert Bragg > Cc: Daniel Vetter
> >
> > fix i915_perf dbg messages
> > ---
> > drivers/gpu/drm/i915/i915_perf.c | 42 --
> --
> > 1 file changed, 21 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> > index 9551282..5705005 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -474,7 +474,7 @@ static int gen7_append_oa_reports(struct
> i915_perf_stream *stream,
> >* copying it to userspace...
> >*/
> > if (report32[0] == 0) {
> > - DRM_ERROR("Skipping spurious, invalid OA
> report\n");
> > + DRM_NOTE("Skipping spurious, invalid OA report\n");
> > continue;
>
> The above looks like a genuine hw/kernel fail, which we shouldn't put
> under the carpet. I'd leave it at DRM_ERROR - I can bikeshed that while
> applying if you're ok. Otherwise lgtm, will apply as soon as we've
> clarified that.
>
It's something that is unfortunately expected to be possible from time to
time due to a hardware race condition between the OA unit updating the tail
pointer for a new report and that report actually becoming visible to the
cpu in memory.
If/when it happens it's not really a significant problem for userspace
(assuming it's rare/intermittent given what the driver does as a
best-effort workaround here). Userspace sees a briefly lower sampling
resolution but the metrics can still be normalized.
We wouldn't want i-g-t failing in this case, so that's why I was changing
it.
It's not really something you want to see ideally (it implies our
heuristic-based software workaround isn't perfect). If it's seen a lot then
that certainly should be considered a warning that we need to try and
improve how we workaround the race condition. If you see it rarely then is
somewhere between a note, and a warning I suppose.
Regards,
- Robert
> -Daniel
>
> > }
> >
> > @@ -551,7 +551,7 @@ static int gen7_oa_read(struct i915_perf_stream
> *stream,
> > if (ret)
> > return ret;
> >
> > - DRM_ERROR("OA buffer overflow: force restart\n");
> > + DRM_DEBUG("OA buffer overflow: force restart\n");
> >
> > dev_priv->perf.oa.ops.oa_disable(dev_priv);
> > dev_priv->perf.oa.ops.oa_enable(dev_priv);
> > @@ -1000,17 +1000,17 @@ static int i915_oa_stream_init(struct
> i915_perf_stream *stream,
> >* IDs
> >*/
> > if (!dev_priv->perf.metrics_kobj) {
> > - DRM_ERROR("OA metrics weren't advertised via sysfs\n");
> > + DRM_DEBUG("OA metrics weren't advertised via sysfs\n");
> > return -EINVAL;
> > }
> >
> > if (!(props->sample_flags & SAMPLE_OA_REPORT)) {
> > - DRM_ERROR("Only OA report sampling supported\n");
> > + DRM_DEBUG("Only OA report sampling supported\n");
> > return -EINVAL;
> > }
> >
> > if (!dev_priv->perf.oa.ops.init_oa_buffer) {
> > - DRM_ERROR("OA unit not supported\n");
> > + DRM_DEBUG("OA unit not supported\n");
> > return -ENODEV;
> > }
> >
> > @@ -1019,17 +1019,17 @@ static int i915_oa_stream_init(struct
> i915_perf_stream *stream,
> >* we currently only allow exclusive access
> >*/
> > if (dev_priv->perf.oa.exclusive_stream) {
> > - DRM_ERROR("OA unit already in use\n");
> > + DRM_DEBUG("OA unit already in use\n");
> > return -EBUSY;
> > }
> >
> > if (!props->metrics_set) {
> > - DRM_ERROR("OA metric set not specified\n");
> > + DRM_DEBUG("OA metric set not specified\n");
> > return -EINVAL;
> > }
> >
> > if (!props->oa_format) {
> > - DRM_ERROR("OA report format not specified\n");
> > + DRM_DEBUG("OA report format not specified\n");
> > return -EINVAL;
> > }
> >
> > @@ -1384,7 +1384,7 @@ i915_perf_open_ioctl_locked(st
Re: [Intel-gfx] [PATCH 01/18] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
On Thu, Dec 01, 2016 at 09:29:08PM +0100, Hans de Goede wrote:
> Looking at the ADF code from the Android kernel sources for a
> cherrytrail tablet I noticed that it is calling the
> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
>
> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
> in panel prepare/unprepare hooks") the mainline i915 code was doing the
> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
> MIPI_SEQ_DEASSERT_RESET.
>
> Looking at the naming of the sequences that is the right thing to do,
> but the problem is, that the old mainline code and the ADF code was
> actually calling the right sequence (tested on a cube iwork8 air tablet),
> and the swapping of the calling breaks things.
>
> This breakage was likely not noticed in testing because on cherrytrail,
> currently chv_exec_gpio ends up disabling the gpio pins rather then
> setting them (this is fixed in the next patch in this patch-set).
>
> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
> places in the enum defining them, so that their (new) names match their
> actual use.
>
> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_bios.h | 4 ++--
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 8405b5a..642a5eb 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -49,11 +49,11 @@ struct edp_power_seq {
> /* MIPI Sequence Block definitions */
> enum mipi_seq {
> MIPI_SEQ_END = 0,
> - MIPI_SEQ_ASSERT_RESET,
> + MIPI_SEQ_DEASSERT_RESET,
> MIPI_SEQ_INIT_OTP,
> MIPI_SEQ_DISPLAY_ON,
> MIPI_SEQ_DISPLAY_OFF,
> - MIPI_SEQ_DEASSERT_RESET,
> + MIPI_SEQ_ASSERT_RESET,
I think we'll still want to keep to the names as they are in the
spec, and instead we'll just call them in the order that looks
wrong + add a comment explaining why we do that.
> MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
> MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
> MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 0d8ff00..579d2f5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
> */
>
> static const char * const seq_name[] = {
> - [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> + [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> [MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
> [MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
> [MIPI_SEQ_DISPLAY_OFF] = "MIPI_SEQ_DISPLAY_OFF",
> - [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> + [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> [MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
> [MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
> [MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
> --
> 2.9.3
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating
On Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
> Once the i915 driver has successfully loaded, the panel can be disabled /
> enabled without hitting this issue.
>
> The getting stuck is caused by vlv_init_display_clock_gating() clearing
> the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
> chv_pipe_power_well_ops.enable() on driver load, while PIPE-A is enabled
> driving the DSI LCD by the BIOS.
>
> Clearing this bit while DSI is in use is a known issue and
> intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
> as appropriate.
>
> This commit modifies vlv_init_display_clock_gating() to leave the
> DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing PIPE-A getting stuck.
>
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
> Cc: sta...@vger.kernel.org
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 356c662..b5ce7cb 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct
> drm_i915_private *dev_priv,
>
> static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
> {
> - I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
> + u32 val;
> +
> + /*
> + * When on driver load, PIPE A may be active and driving a DSI display.
> + * Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid PIPE A getting stuck
> + * (and never recovering) in this case. intel_dsi_post_disable() will
> + * clear it when we turn off the display.
Why are you talking only about pipe A here?
> + */
> + val = I915_READ(DSPCLK_GATE_D);
> + val &= DPOUNIT_CLOCK_GATE_DISABLE;
> + val |= VRHUNIT_CLOCK_GATE_DISABLE;
> + I915_WRITE(DSPCLK_GATE_D, val);
>
> /*
>* Disable trickle feed and enable pnd deadline calculation
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove redundant warnings
== Series Details == Series: drm/i915: remove redundant warnings URL : https://patchwork.freedesktop.org/series/16273/ State : success == Summary == Series 16273v1 drm/i915: remove redundant warnings https://patchwork.freedesktop.org/api/1.0/series/16273/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 273202788eba907049316b3ccc2f4d1fd30aff1d drm-tip: 2016y-12m-02d-11h-27m-42s UTC integration manifest 2ad35df drm/i915: remove redundant warnings == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3172/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH alternative #1] drm/i915/bxt: add bxt dsi gpio element support
On Thu, 01 Dec 2016, Mika Kahola wrote:
> On Tue, 2016-11-15 at 14:08 +0200, Jani Nikula wrote:
>> Request the GPIO by index through the consumer API. For now, use a
>> quick
>> hack to store the already requested ones, simply because I have no
>> idea
>> whether this actually works or not, and I have no way to test it.
>>
>> Cc: Mika Kahola
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 38
>> +-
>> 1 file changed, 32 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index 9f279a3d0f74..41e0eeac97f4 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -304,19 +305,44 @@ static void chv_exec_gpio(struct
>> drm_i915_private *dev_priv,
>> mutex_unlock(&dev_priv->sb_lock);
>> }
>>
>> +static void bxt_exec_gpio(struct drm_i915_private *dev_priv,
>> + u8 gpio_source, u8 gpio_index, bool value)
>> +{
>> +/* XXX: this table is a quick ugly hack. */
>> +static struct gpio_desc *bxt_gpio_table[U8_MAX + 1];
>> +struct gpio_desc *gpio_desc = bxt_gpio_table[gpio_index];
>> +
>> +if (!gpio_desc) {
>> +gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
>> + NULL, gpio_index,
> This patch works better with *NULL* replaced by *"panel"*. With this
> change we can access GPIO's without GPIO index request failures.
Oh, nice find. Can you resend the patch with that fixed, please?
BR,
Jani.
>
>> + value ?
>> GPIOD_OUT_LOW :
>> + GPIOD_OUT_HIGH);
>> +
>> +if (IS_ERR_OR_NULL(gpio_desc)) {
>> +DRM_ERROR("GPIO index %u request failed
>> (%ld)\n",
>> + gpio_index, PTR_ERR(gpio_desc));
>> +return;
>> +}
>> +
>> +bxt_gpio_table[gpio_index] = gpio_desc;
>> +}
>> +
>> +gpiod_set_value(gpio_desc, value);
>> +}
>> +
>> static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const
>> u8 *data)
>> {
>> struct drm_device *dev = intel_dsi->base.base.dev;
>> struct drm_i915_private *dev_priv = to_i915(dev);
>> -u8 gpio_source, gpio_index;
>> +u8 gpio_source, gpio_index = 0, gpio_number;
>> bool value;
>>
>> DRM_DEBUG_KMS("\n");
>>
>> if (dev_priv->vbt.dsi.seq_version >= 3)
>> -data++;
>> +gpio_index = *data++;
>>
>> -gpio_index = *data++;
>> +gpio_number = *data++;
>>
>> /* gpio source in sequence v2 only */
>> if (dev_priv->vbt.dsi.seq_version == 2)
>> @@ -328,11 +354,11 @@ static const u8 *mipi_exec_gpio(struct
>> intel_dsi *intel_dsi, const u8 *data)
>> value = *data++ & 1;
>>
>> if (IS_VALLEYVIEW(dev_priv))
>> -vlv_exec_gpio(dev_priv, gpio_source, gpio_index,
>> value);
>> +vlv_exec_gpio(dev_priv, gpio_source, gpio_number,
>> value);
>> else if (IS_CHERRYVIEW(dev_priv))
>> -chv_exec_gpio(dev_priv, gpio_source, gpio_index,
>> value);
>> +chv_exec_gpio(dev_priv, gpio_source, gpio_number,
>> value);
>> else
>> -DRM_DEBUG_KMS("GPIO element not supported on this
>> platform\n");
>> +bxt_exec_gpio(dev_priv, gpio_source, gpio_index,
>> value);
>>
>> return data;
>> }
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm/i915: Pass crtc state to vlv_compute_wm_level()
On Thu, Dec 01, 2016 at 03:47:55PM +0100, Maarten Lankhorst wrote:
> Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > Rather than accessing crtc->config in vlv_compute_wm_level() let's
> > pass in the crtc state explicitly. One step closer to atomic.
> >
> > Signed-off-by: Ville Syrjälä
> Yay. All users of intel_crtc->config have to die in the future, but this is
> temporarily a legit use for it.
Pardon the stray reply earlier. What I wanted to say was that I was
playing around with coccinelle a bit the other night, and managed to
trick it into a little bit of crtc->config killing. I think I'll try
to expand my efforts there a bit more before posting the stuff though.
>
> For patch 13, 14 and 15
>
> Reviewed-by: Maarten Lankhorst
> > drivers/gpu/drm/i915/intel_pm.c | 20 +++-
> > 1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 291843c2b61b..2a2aa8968b93 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -978,24 +978,26 @@ static void vlv_setup_wm_latency(struct
> > drm_i915_private *dev_priv)
> > }
> > }
> >
> > -static uint16_t vlv_compute_wm_level(struct intel_plane *plane,
> > -struct intel_crtc *crtc,
> > -const struct intel_plane_state *state,
> > +static uint16_t vlv_compute_wm_level(const struct intel_crtc_state
> > *crtc_state,
> > +const struct intel_plane_state
> > *plane_state,
> > int level)
> > {
> > + struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > + const struct drm_display_mode *adjusted_mode =
> > + &crtc_state->base.adjusted_mode;
> > int clock, htotal, cpp, width, wm;
> >
> > if (dev_priv->wm.pri_latency[level] == 0)
> > return USHRT_MAX;
> >
> > - if (!state->base.visible)
> > + if (!plane_state->base.visible)
> > return 0;
> >
> > - cpp = drm_format_plane_cpp(state->base.fb->pixel_format, 0);
> > - clock = crtc->config->base.adjusted_mode.crtc_clock;
> > - htotal = crtc->config->base.adjusted_mode.crtc_htotal;
> > - width = crtc->config->pipe_src_w;
> > + cpp = drm_format_plane_cpp(plane_state->base.fb->pixel_format, 0);
> > + clock = adjusted_mode->crtc_clock;
> > + htotal = adjusted_mode->crtc_htotal;
> > + width = crtc_state->pipe_src_w;
> > if (WARN_ON(htotal == 0))
> > htotal = 1;
> >
> > @@ -1145,7 +1147,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
> >
> > /* normal watermarks */
> > for (level = 0; level < wm_state->num_levels; level++) {
> > - int wm = vlv_compute_wm_level(plane, crtc, state,
> > level);
> > + int wm = vlv_compute_wm_level(crtc->config, state,
> > level);
> > int max_wm = plane->wm.fifo_size;
> >
> > /* hack */
>
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: s/gen8_setup_page_directory/gen8_setup_pdpe/
== Series Details == Series: series starting with [1/2] drm/i915: s/gen8_setup_page_directory/gen8_setup_pdpe/ URL : https://patchwork.freedesktop.org/series/16274/ State : success == Summary == Series 16274v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16274/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 273202788eba907049316b3ccc2f4d1fd30aff1d drm-tip: 2016y-12m-02d-11h-27m-42s UTC integration manifest 7a56d9f drm/i915: s/gen8_setup_page_directory_pointer/gen8_setup_pml4e/ 002c35c drm/i915: s/gen8_setup_page_directory/gen8_setup_pdpe/ == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3173/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: introduce GEM_WARN_ON
In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, this
will enable us to freely add warnings which our CI will hopefully catch
but without fear of impacting production machines.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 51ec793f2e20..04c777e6d0bf 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -27,8 +27,10 @@
#ifdef CONFIG_DRM_I915_DEBUG_GEM
#define GEM_BUG_ON(expr) BUG_ON(expr)
+#define GEM_WARN_ON(expr) WARN_ON(expr)
#else
#define GEM_BUG_ON(expr) do { } while (0)
+#define GEM_WARN_ON(expr) do { } while (0)
#endif
#define I915_NUM_ENGINES 5
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: move vma sanity checking into i915_vma_bind
If we move the sanity checking from gen8_alloc_va_range_3lvl and
gen6_alloc_va_range into i915_vma_bind, we will increase our coverage to
now both callbacks. We also convert each WARN_ON over to a GEM_WARN_ON.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 12
drivers/gpu/drm/i915/i915_vma.c | 6 ++
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 02fb063302bf..e0746eb5dc54 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1304,15 +1304,6 @@ static int gen8_alloc_va_range_3lvl(struct
i915_address_space *vm,
uint32_t pdpes = I915_PDPES_PER_PDP(dev_priv);
int ret;
- /* Wrap is never okay since we can only represent 48b, and we don't
-* actually use the other side of the canonical address space.
-*/
- if (WARN_ON(start + length < start))
- return -ENODEV;
-
- if (WARN_ON(start + length > vm->total))
- return -ENODEV;
-
ret = alloc_gen8_temp_bitmaps(&new_page_dirs, &new_page_tables, pdpes);
if (ret)
return ret;
@@ -1930,9 +1921,6 @@ static int gen6_alloc_va_range(struct i915_address_space
*vm,
uint32_t pde;
int ret;
- if (WARN_ON(start_in + length_in > ppgtt->base.total))
- return -ENODEV;
-
start = start_save = start_in;
length = length_save = length_in;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4c91a68ecb6d..2c494191d7b3 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -176,6 +176,12 @@ int i915_vma_bind(struct i915_vma *vma, enum
i915_cache_level cache_level,
if (bind_flags == 0)
return 0;
+ if (GEM_WARN_ON(vma->node.start + vma->node.size < vma->node.start))
+ return -ENODEV;
+
+ if (GEM_WARN_ON(vma->node.start + vma->node.size > vma->vm->total))
+ return -ENODEV;
+
if (vma_flags == 0 && vma->vm->allocate_va_range) {
trace_i915_va_alloc(vma);
ret = vma->vm->allocate_va_range(vma->vm,
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating
Hi,
On 02-12-16 13:40, Ville Syrjälä wrote:
On Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.
The getting stuck is caused by vlv_init_display_clock_gating() clearing
the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
chv_pipe_power_well_ops.enable() on driver load, while PIPE-A is enabled
driving the DSI LCD by the BIOS.
Clearing this bit while DSI is in use is a known issue and
intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
as appropriate.
This commit modifies vlv_init_display_clock_gating() to leave the
DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing PIPE-A getting stuck.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 356c662..b5ce7cb 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct
drm_i915_private *dev_priv,
static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
{
- I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
+ u32 val;
+
+ /*
+* When on driver load, PIPE A may be active and driving a DSI display.
+* Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid PIPE A getting stuck
+* (and never recovering) in this case. intel_dsi_post_disable() will
+* clear it when we turn off the display.
Why are you talking only about pipe A here?
Because that is the pipe which was getting stuck on my tablet. I see that
the comment for the same workaround in intel_dsi.c just says:
" Disable DPOunit clock gating, can stall pipe" so I guess I should
update the comment s/PIPE A/pipe(s)/. Any other remarks before I send a v2 ?
Regards,
Hans
+*/
+ val = I915_READ(DSPCLK_GATE_D);
+ val &= DPOUNIT_CLOCK_GATE_DISABLE;
+ val |= VRHUNIT_CLOCK_GATE_DISABLE;
+ I915_WRITE(DSPCLK_GATE_D, val);
/*
* Disable trickle feed and enable pnd deadline calculation
--
2.9.3
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce GEM_WARN_ON
On Fri, Dec 02, 2016 at 01:23:13PM +, Matthew Auld wrote:
> In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, this
> will enable us to freely add warnings which our CI will hopefully catch
> but without fear of impacting production machines.
Impacting performance?
>
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index 51ec793f2e20..04c777e6d0bf 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -27,8 +27,10 @@
>
> #ifdef CONFIG_DRM_I915_DEBUG_GEM
> #define GEM_BUG_ON(expr) BUG_ON(expr)
> +#define GEM_WARN_ON(expr) WARN_ON(expr)
> #else
> #define GEM_BUG_ON(expr) do { } while (0)
> +#define GEM_WARN_ON(expr) do { } while (0)
> #endif
>
> #define I915_NUM_ENGINES 5
> --
> 2.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/18] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
Hi,
On 02-12-16 13:37, Ville Syrjälä wrote:
On Thu, Dec 01, 2016 at 09:29:08PM +0100, Hans de Goede wrote:
Looking at the ADF code from the Android kernel sources for a
cherrytrail tablet I noticed that it is calling the
MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
in panel prepare/unprepare hooks") the mainline i915 code was doing the
same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
MIPI_SEQ_DEASSERT_RESET.
Looking at the naming of the sequences that is the right thing to do,
but the problem is, that the old mainline code and the ADF code was
actually calling the right sequence (tested on a cube iwork8 air tablet),
and the swapping of the calling breaks things.
This breakage was likely not noticed in testing because on cherrytrail,
currently chv_exec_gpio ends up disabling the gpio pins rather then
setting them (this is fixed in the next patch in this patch-set).
This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
places in the enum defining them, so that their (new) names match their
actual use.
Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_bios.h | 4 ++--
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 8405b5a..642a5eb 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -49,11 +49,11 @@ struct edp_power_seq {
/* MIPI Sequence Block definitions */
enum mipi_seq {
MIPI_SEQ_END = 0,
- MIPI_SEQ_ASSERT_RESET,
+ MIPI_SEQ_DEASSERT_RESET,
MIPI_SEQ_INIT_OTP,
MIPI_SEQ_DISPLAY_ON,
MIPI_SEQ_DISPLAY_OFF,
- MIPI_SEQ_DEASSERT_RESET,
+ MIPI_SEQ_ASSERT_RESET,
I think we'll still want to keep to the names as they are in the
spec, and instead we'll just call them in the order that looks
wrong + add a comment explaining why we do that.
I really want the i915 driver to use the correct names, anything
else will lead to no amount of confusion for people who have
experience with embedded stuff.
How about adding a comment here in the enum, as well as in
patch 8: "drm/i915/dsi: Document the panel enable / disable sequences from the
spec"
That the spec has assert / deassert the wrong way around and that
the i915 code is using the correct names ?
Most people will not even have access to the spec, so it seems to
me that having this right in the code, with a comment to warn
people who do have access to the spec is better then the other
way around.
Regards,
Hans
MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 0d8ff00..579d2f5 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
*/
static const char * const seq_name[] = {
- [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
+ [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
[MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
[MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
[MIPI_SEQ_DISPLAY_OFF] = "MIPI_SEQ_DISPLAY_OFF",
- [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
+ [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
[MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
[MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
[MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating
On Fri, Dec 02, 2016 at 02:27:43PM +0100, Hans de Goede wrote:
> Hi,
>
> On 02-12-16 13:40, Ville Syrjälä wrote:
> > On Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
> >> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
> >> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
> >> Once the i915 driver has successfully loaded, the panel can be disabled /
> >> enabled without hitting this issue.
> >>
> >> The getting stuck is caused by vlv_init_display_clock_gating() clearing
> >> the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
> >> chv_pipe_power_well_ops.enable() on driver load, while PIPE-A is enabled
> >> driving the DSI LCD by the BIOS.
> >>
> >> Clearing this bit while DSI is in use is a known issue and
> >> intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
> >> as appropriate.
> >>
> >> This commit modifies vlv_init_display_clock_gating() to leave the
> >> DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing PIPE-A getting stuck.
> >>
> >> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
> >> Cc: sta...@vger.kernel.org
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
> >> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> index 356c662..b5ce7cb 100644
> >> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> @@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct
> >> drm_i915_private *dev_priv,
> >>
> >> static void vlv_init_display_clock_gating(struct drm_i915_private
> >> *dev_priv)
> >> {
> >> - I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
> >> + u32 val;
> >> +
> >> + /*
> >> + * When on driver load, PIPE A may be active and driving a DSI display.
> >> + * Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid PIPE A getting stuck
> >> + * (and never recovering) in this case. intel_dsi_post_disable() will
> >> + * clear it when we turn off the display.
> >
> > Why are you talking only about pipe A here?
>
> Because that is the pipe which was getting stuck on my tablet. I see that
> the comment for the same workaround in intel_dsi.c just says:
> " Disable DPOunit clock gating, can stall pipe" so I guess I should
> update the comment s/PIPE A/pipe(s)/. Any other remarks before I send a v2 ?
Nope. With that this is
Reviewed-by: Ville Syrjälä
>
> Regards,
>
> Hans
>
>
>
> >
> >> + */
> >> + val = I915_READ(DSPCLK_GATE_D);
> >> + val &= DPOUNIT_CLOCK_GATE_DISABLE;
> >> + val |= VRHUNIT_CLOCK_GATE_DISABLE;
> >> + I915_WRITE(DSPCLK_GATE_D, val);
> >>
> >>/*
> >> * Disable trickle feed and enable pnd deadline calculation
> >> --
> >> 2.9.3
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-de...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences
Hi, On 02-12-16 11:31, Jani Nikula wrote: On Thu, 01 Dec 2016, Hans de Goede wrote: The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are not fine grained enough to abstract all the different steps we need to take (and VBT sequences we need to exec) properly. So simply remove the panel _enable/disable and prepare/unprepare callbacks and instead export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c and call that from intel_dsi_enable/disable(). No functional changes. No functional changes, but this is quite a big design change between intel_dsi.c and intel_dsi_panel_vbt.c. True, I did this because adding a callback per init step to the drm_panel interface felt like it will result in a game of whack a mole (adding more and more callbacks). See the end of this mail for a proposal with leaves the drm_panel interface in place, while also avoiding this problem. Originally the idea was to separate the dsi core code and the panel specific code, letting one write a panel driver that was not based on values in VBT. This patch changes that. I see, I was not aware of this history. Now I'm not sure if there'll ever be a panel driver not based on VBT, and perhaps the current drm_panel based interface between two is not enough in the end, nor prettiest. But after this patch, we might just as well throw out the drm_panel interface, and refactor the division between the two files completely. Indeed, if we accept the direction set in this patch, that refactoring would be the logical next step. Is intel_dsi.c the only user of the drm_panel interface ? The name suggests it is not intel specific. I have not made up my mind about this yet. An alternative would be to amend the drm_panel interface to achieve the kind of granularity you're after in the follow-up patches. Indeed, such patches have been sent in the past. How about we add a "drm_panel_exec_sequence" callback to the drm_panel interface, which takes an enum argument which (de)init step to do ? Then we can easily add extra init steps later by extending the enum, and panel implementations which do not care about certain steps can simply treat these as nops. This avoids the need to add a ton of callbacks to the drm_panel struct. If there are no other users, we could then also remove the enable/disable and prepare/unprepare pairs from drm_panel now, I left those in place assuming that intel_dsi.c was not the only user of drm_panel. Regards, Hans BR, Jani. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 14 +++--- drivers/gpu/drm/i915/intel_dsi.h | 3 +++ drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 ++ 3 files changed, 15 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 85b748d..cf761e8 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -656,7 +656,10 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, /* put device in ready state */ intel_dsi_device_ready(encoder); - drm_panel_prepare(intel_dsi->panel); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); /* Enable port in pre-enable phase itself because as per hw team * recommendation, port should be enabled befor plane & pipe */ @@ -669,7 +672,8 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, dpi_send_cmd(intel_dsi, TURN_ON, false, port); msleep(100); - drm_panel_enable(intel_dsi->panel); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON); intel_dsi_port_enable(encoder); } @@ -732,7 +736,8 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, * if disable packets are sent before sending shutdown packet then in * some next enable sequence send turn on packet error is observed */ - drm_panel_disable(intel_dsi->panel); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF); intel_dsi_clear_device_ready(encoder); @@ -746,7 +751,8 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, I915_WRITE(DSPCLK_GATE_D, val); } - drm_panel_unprepare(intel_dsi->panel); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF); msleep(intel_dsi->panel_off_delay); diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
Re: [Intel-gfx] [PATCH 01/18] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
On Fri, Dec 02, 2016 at 02:34:01PM +0100, Hans de Goede wrote:
> Hi,
>
> On 02-12-16 13:37, Ville Syrjälä wrote:
> > On Thu, Dec 01, 2016 at 09:29:08PM +0100, Hans de Goede wrote:
> >> Looking at the ADF code from the Android kernel sources for a
> >> cherrytrail tablet I noticed that it is calling the
> >> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
> >>
> >> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
> >> in panel prepare/unprepare hooks") the mainline i915 code was doing the
> >> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
> >> MIPI_SEQ_DEASSERT_RESET.
> >>
> >> Looking at the naming of the sequences that is the right thing to do,
> >> but the problem is, that the old mainline code and the ADF code was
> >> actually calling the right sequence (tested on a cube iwork8 air tablet),
> >> and the swapping of the calling breaks things.
> >>
> >> This breakage was likely not noticed in testing because on cherrytrail,
> >> currently chv_exec_gpio ends up disabling the gpio pins rather then
> >> setting them (this is fixed in the next patch in this patch-set).
> >>
> >> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
> >> places in the enum defining them, so that their (new) names match their
> >> actual use.
> >>
> >> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
> >> Cc: Jani Nikula
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/i915/intel_bios.h | 4 ++--
> >> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
> >> 2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> >> b/drivers/gpu/drm/i915/intel_bios.h
> >> index 8405b5a..642a5eb 100644
> >> --- a/drivers/gpu/drm/i915/intel_bios.h
> >> +++ b/drivers/gpu/drm/i915/intel_bios.h
> >> @@ -49,11 +49,11 @@ struct edp_power_seq {
> >> /* MIPI Sequence Block definitions */
> >> enum mipi_seq {
> >>MIPI_SEQ_END = 0,
> >> - MIPI_SEQ_ASSERT_RESET,
> >> + MIPI_SEQ_DEASSERT_RESET,
> >>MIPI_SEQ_INIT_OTP,
> >>MIPI_SEQ_DISPLAY_ON,
> >>MIPI_SEQ_DISPLAY_OFF,
> >> - MIPI_SEQ_DEASSERT_RESET,
> >> + MIPI_SEQ_ASSERT_RESET,
> >
> > I think we'll still want to keep to the names as they are in the
> > spec, and instead we'll just call them in the order that looks
> > wrong + add a comment explaining why we do that.
>
> I really want the i915 driver to use the correct names, anything
> else will lead to no amount of confusion for people who have
> experience with embedded stuff.
>
> How about adding a comment here in the enum, as well as in
> patch 8: "drm/i915/dsi: Document the panel enable / disable sequences from
> the spec"
> That the spec has assert / deassert the wrong way around and that
> the i915 code is using the correct names ?
Sure, I could live with that. We definitely need to have that
comment somewhere.
>
> Most people will not even have access to the spec, so it seems to
> me that having this right in the code, with a comment to warn
> people who do have access to the spec is better then the other
> way around.
>
> Regards,
>
> Hans
>
>
>
> >
> >>MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
> >>MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
> >>MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> index 0d8ff00..579d2f5 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> @@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
> >> */
> >>
> >> static const char * const seq_name[] = {
> >> - [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> >> + [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> >>[MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
> >>[MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
> >>[MIPI_SEQ_DISPLAY_OFF] = "MIPI_SEQ_DISPLAY_OFF",
> >> - [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> >> + [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> >>[MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
> >>[MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
> >>[MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
> >> --
> >> 2.9.3
> >
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFCv2,1/3] drm/i915: Provide a hook for selftests
== Series Details == Series: series starting with [RFCv2,1/3] drm/i915: Provide a hook for selftests URL : https://patchwork.freedesktop.org/series/16276/ State : success == Summary == Series 16276v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16276/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 273202788eba907049316b3ccc2f4d1fd30aff1d drm-tip: 2016y-12m-02d-11h-27m-42s UTC integration manifest e80f0ef drm/i915: Add unit tests for the breadcrumb rbtree, completion d081f15 drm/i915: Add unit tests for the breadcrumb rbtree, insert/remove d6a6f1a drm/i915: Provide a hook for selftests == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3174/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce GEM_WARN_ON
On Fri, Dec 02, 2016 at 01:23:13PM +, Matthew Auld wrote:
> In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, this
> will enable us to freely add warnings which our CI will hopefully catch
> but without fear of impacting production machines.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index 51ec793f2e20..04c777e6d0bf 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -27,8 +27,10 @@
>
> #ifdef CONFIG_DRM_I915_DEBUG_GEM
> #define GEM_BUG_ON(expr) BUG_ON(expr)
> +#define GEM_WARN_ON(expr) WARN_ON(expr)
> #else
> #define GEM_BUG_ON(expr) do { } while (0)
> +#define GEM_WARN_ON(expr) do { } while (0)
#define GEM_WARN_ON 0
i.e. so that if (GEM_WARN_ON(insane_condition()) compiles out correctly
without DEBUG_GEM enabled.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences
On Fri, 02 Dec 2016, Hans de Goede wrote: > Hi, > > On 02-12-16 11:31, Jani Nikula wrote: >> On Thu, 01 Dec 2016, Hans de Goede wrote: >>> The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are >>> not fine grained enough to abstract all the different steps we need to >>> take (and VBT sequences we need to exec) properly. So simply remove the >>> panel _enable/disable and prepare/unprepare callbacks and instead >>> export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c >>> and call that from intel_dsi_enable/disable(). >>> >>> No functional changes. >> >> No functional changes, but this is quite a big design change between >> intel_dsi.c and intel_dsi_panel_vbt.c. > > True, I did this because adding a callback per init step to the > drm_panel interface felt like it will result in a game of > whack a mole (adding more and more callbacks). See the end of > this mail for a proposal with leaves the drm_panel interface > in place, while also avoiding this problem. > >> Originally the idea was to >> separate the dsi core code and the panel specific code, letting one >> write a panel driver that was not based on values in VBT. This patch >> changes that. > > I see, I was not aware of this history. > >> Now I'm not sure if there'll ever be a panel driver not based on VBT, >> and perhaps the current drm_panel based interface between two is not >> enough in the end, nor prettiest. But after this patch, we might just as >> well throw out the drm_panel interface, and refactor the division >> between the two files completely. Indeed, if we accept the direction set >> in this patch, that refactoring would be the logical next step. > > Is intel_dsi.c the only user of the drm_panel interface ? The name > suggests it is not intel specific. Just a quick note here, it's not i915 specific, it's used in other drivers. BR, Jani. > >> I have not made up my mind about this yet. An alternative would be to >> amend the drm_panel interface to achieve the kind of granularity you're >> after in the follow-up patches. Indeed, such patches have been sent in >> the past. > > How about we add a "drm_panel_exec_sequence" callback to the > drm_panel interface, which takes an enum argument which (de)init > step to do ? > > Then we can easily add extra init steps later by extending the > enum, and panel implementations which do not care about certain > steps can simply treat these as nops. This avoids the need > to add a ton of callbacks to the drm_panel struct. > > If there are no other users, we could then also remove the > enable/disable and prepare/unprepare pairs from drm_panel > now, I left those in place assuming that intel_dsi.c was > not the only user of drm_panel. > > Regards, > > Hans > > > > >> >> BR, >> Jani. >> >>> >>> Signed-off-by: Hans de Goede >>> --- >>> drivers/gpu/drm/i915/intel_dsi.c | 14 +++--- >>> drivers/gpu/drm/i915/intel_dsi.h | 3 +++ >>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 >>> ++ >>> 3 files changed, 15 insertions(+), 45 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c >>> b/drivers/gpu/drm/i915/intel_dsi.c >>> index 85b748d..cf761e8 100644 >>> --- a/drivers/gpu/drm/i915/intel_dsi.c >>> +++ b/drivers/gpu/drm/i915/intel_dsi.c >>> @@ -656,7 +656,10 @@ static void intel_dsi_pre_enable(struct intel_encoder >>> *encoder, >>> /* put device in ready state */ >>> intel_dsi_device_ready(encoder); >>> >>> - drm_panel_prepare(intel_dsi->panel); >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); >>> >>> /* Enable port in pre-enable phase itself because as per hw team >>> * recommendation, port should be enabled befor plane & pipe */ >>> @@ -669,7 +672,8 @@ static void intel_dsi_pre_enable(struct intel_encoder >>> *encoder, >>> dpi_send_cmd(intel_dsi, TURN_ON, false, port); >>> msleep(100); >>> >>> - drm_panel_enable(intel_dsi->panel); >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON); >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON); >>> >>> intel_dsi_port_enable(encoder); >>> } >>> @@ -732,7 +736,8 @@ static void intel_dsi_post_disable(struct intel_encoder >>> *encoder, >>> * if disable packets are sent before sending shutdown packet then in >>> * some next enable sequence send turn on packet error is observed >>> */ >>> - drm_panel_disable(intel_dsi->panel); >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF); >>> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF); >>> >>> intel_dsi_clear_device_ready(encoder); >>> >>> @@ -746,7 +751,8 @@ static void intel_dsi_post_disable(struct intel_encoder >>>
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: introduce GEM_WARN_ON
== Series Details == Series: series starting with [1/2] drm/i915: introduce GEM_WARN_ON URL : https://patchwork.freedesktop.org/series/16278/ State : warning == Summary == Series 16278v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16278/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-skl-6770hq) fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:230 dwarn:1 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 273202788eba907049316b3ccc2f4d1fd30aff1d drm-tip: 2016y-12m-02d-11h-27m-42s UTC integration manifest 05e8d2b drm/i915: move vma sanity checking into i915_vma_bind 91fae78 drm/i915: introduce GEM_WARN_ON == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3175/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/audio: extend audio sync rate support for DP MST
On Fri, 02 Dec 2016, "Yang, Libin" wrote:
> Any comments? Thanks.
Both pushed to dinq, thanks for the patches.
Libin and/or Dhinakaran, please improve the documentation of struct
i915_audio_component_ops to describe the parameters of sync_audio_rate
and get_eld hooks. For example, there's nothing about pipe being -1 for
non-MST.
BR,
Jani.
>
> Regards,
> Libin
>
>
>>-Original Message-
>>From: Yang, Libin
>>Sent: Thursday, December 1, 2016 1:17 PM
>>To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com;
>>ville.syrj...@linux.intel.com; Vetter, Daniel ;
>>Pandiyan, Dhinakaran ; ti...@suse.de
>>Cc: Yang, Libin
>>Subject: [PATCH 2/2] drm/i915/audio: extend audio sync rate support for DP
>>MST
>>
>>From: Libin Yang
>>
>>Remove the type judgement in i915_audio_component_sync_audio_rate().
>>Audio rate sync is necessary for all i915 digital audio now.
>>
>>Signed-off-by: Libin Yang
>>---
>> drivers/gpu/drm/i915/intel_audio.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/intel_audio.c
>>b/drivers/gpu/drm/i915/intel_audio.c
>>index c8a1345..3bbc96c 100644
>>--- a/drivers/gpu/drm/i915/intel_audio.c
>>+++ b/drivers/gpu/drm/i915/intel_audio.c
>>@@ -805,9 +805,7 @@ static int
>>i915_audio_component_sync_audio_rate(struct device *kdev, int port,
>>
>> /* 1. get the pipe */
>> intel_encoder = get_saved_enc(dev_priv, port, pipe);
>>- if (!intel_encoder || !intel_encoder->base.crtc ||
>>- (intel_encoder->type != INTEL_OUTPUT_HDMI &&
>>- intel_encoder->type != INTEL_OUTPUT_DP)) {
>>+ if (!intel_encoder || !intel_encoder->base.crtc) {
>> DRM_DEBUG_KMS("Not valid for port %c\n",
>>port_name(port));
>> err = -ENODEV;
>> goto unlock;
>>--
>>2.7.4
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.
The getting stuck is caused by vlv_init_display_clock_gating() clearing
the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled
driving the DSI LCD by the BIOS.
Clearing this bit while DSI is in use is a known issue and
intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
as appropriate.
This commit modifies vlv_init_display_clock_gating() to leave the
DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
---
Changes in v2:
-Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 356c662..87b4af0 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct
drm_i915_private *dev_priv,
static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
{
- I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
+ u32 val;
+
+ /*
+* On driver load, a pipe may be active and driving a DSI display.
+* Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid the pipe getting stuck
+* (and never recovering) in this case. intel_dsi_post_disable() will
+* clear it when we turn off the display.
+*/
+ val = I915_READ(DSPCLK_GATE_D);
+ val &= DPOUNIT_CLOCK_GATE_DISABLE;
+ val |= VRHUNIT_CLOCK_GATE_DISABLE;
+ I915_WRITE(DSPCLK_GATE_D, val);
/*
* Disable trickle feed and enable pnd deadline calculation
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] GVT-g device model fix
On Wed, 30 Nov 2016, Daniel Vetter wrote: > On Wed, Nov 30, 2016 at 04:23:02PM +0800, Zhenyu Wang wrote: >> >> Hi, >> >> Here's current left GVT-g device model bug fixes for pull. > > Since 4.10 feature freeze is already done, this needs to go into > drm-intel-next-fixes. Jani, can you pls pull? Pulled, Jani. > > Thanks, Daniel > >> >> Thanks. >> >> --- >> >> The following changes since commit 53e86ada8e53fcdbe1593f70b7df85549ba70b9a: >> >> drm/i915/gvt: remove unresolved vfio pin/unpin pages interface dependency >> (2016-11-17 15:51:16 +0800) >> >> are available in the git repository at: >> >> https://github.com/01org/gvt-linux tags/gvt-next-2016-11-30 >> >> for you to fetch changes up to 53d6f812c0dbf1c9cad89b1c2118e61c13ca9677: >> >> drm/i915/gvt: fix lock not released bug for dispatch_workload() err path >> (2016-11-25 09:18:11 +0800) >> >> >> gvt-next-2016-11-30 >> >> - initialize vgpu as primary for correct cfg space setting >> - fix 64 bit bar emulation >> - fix un-released lock issue on dispatch workload err path >> >> >> Du, Changbin (1): >> drm/i915/gvt: fix missing init param.primary >> >> Xiaoguang Chen (1): >> drm/i915/gvt: fix getting 64bit bar size error >> >> Zhenyu Wang (1): >> drm/i915/gvt: fix lock not released bug for dispatch_workload() err >> path >> >> drivers/gpu/drm/i915/gvt/gvt.h | 2 ++ >> drivers/gpu/drm/i915/gvt/scheduler.c | 10 ++ >> drivers/gpu/drm/i915/gvt/vgpu.c | 1 + >> 3 files changed, 9 insertions(+), 4 deletions(-) >> >> -- >> Open Source Technology Center, Intel ltd. >> >> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 0/4 v7] Convert sh scripts to C variants.
On Thu, Dec 01, 2016 at 11:43:11PM +, Chris Wilson wrote: > The actual conversion from sh to C for drv_module_reload_basic needs an > ack from Petri after some soak testing. Please rebase (if required). > -Chris Pushed the last two patches. drv_module_reload changes looked fine on farm2. -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/3] drm/i915/gen6+: Clear upper data byte during PCODE write (rev2)
On ma, 2016-11-28 at 17:15 +, Patchwork wrote: > == Series Details == > > Series: series starting with [v4,1/3] drm/i915/gen6+: Clear upper data byte > during PCODE write (rev2) > URL : https://patchwork.freedesktop.org/series/16046/ > State : success > > == Summary == > > Series 16046v2 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/16046/revisions/2/mbox/ I pushed 1/3 to -dinq, thanks for the review. I'll send an updated version of the other 2, doing the polling first w/o disabling preemption. According to Art and my tests that should succeed most of the time, so we'd need the preempt-disabled poll only as a fallback. > fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 > fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 > fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 > fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 > fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 > fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 > fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 > fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 > fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 > fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 > fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 > > 477cc06f6ef4842fd63e28ff30d721462af199a6 drm-tip: 2016y-11m-28d-16h-17m-39s > UTC integration manifest > b82f611 drm/i915/gen9: Fix PCODE polling during SAGV disabling > 97b0290 drm/i915/gen9: Fix PCODE polling during CDCLK change notification > 50aec7a4c drm/i915/gen6+: Clear upper data byte during PCODE write > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3128/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Geminilake enabling (rev9)
On Fri, 2016-12-02 at 09:17 +, Patchwork wrote: > == Series Details == > > Series: Geminilake enabling (rev9) > URL : https://patchwork.freedesktop.org/series/15118/ > State : warning > > == Summary == > > Series 15118v9 Geminilake enabling > https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/9/mbox/ > > Test kms_pipe_crc_basic: > Subgroup read-crc-pipe-b: > pass -> DMESG-WARN (fi-ivb-3770) *ERROR* EDID checksum is invalid, remainder is 157 https://bugs.freedesktop.org/show_bug.cgi?id=98228 Series pushed. Thanks for the reviews. Ander > > fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 > fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 > fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 > fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 > fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 > fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 > fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-ivb-3770 total:245 pass:222 dwarn:1 dfail:0 fail:0 skip:22 > fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 > fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 > fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 > fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 > fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 > > 58e999de1132de619056ee8fafccbbe7dfba3f4d drm-tip: 2016y-12m-02d-07h-55m-48s > UTC integration manifest > 1f087d4 drm/i915/glk: Configure number of sprite planes properly > 0615d8a drm/i915/glk: Implement core display init/uninit sequence for > geminilake > 6ada4b4 drm/i915/glk: Allow dotclock up to 2 * cdclk on geminilake > 819a098 drm/i915/glk: Reuse broxton's cdclk code for GLK > aa98396 drm/i915/glk: Update Port PLL enable sequence for Geminilkae > da9e47e drm/i915/glk: Set DCC delay range 2 in PLL enable sequence > a59b507 drm/i915/glk: Implement Geminilake DDI init sequence > 39714d8 drm/i915/glk: Add power wells for Geminilake > 9b3c48c drm/i915/glk: Reuse broxton code for geminilake > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3168/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
Looking at the ADF code from the Android kernel sources for a
cherrytrail tablet I noticed that it is calling the
MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
in panel prepare/unprepare hooks") the mainline i915 code was doing the
same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
MIPI_SEQ_DEASSERT_RESET.
Looking at the naming of the sequences that is the right thing to do,
but the problem is, that the old mainline code and the ADF code was
actually calling the right sequence (tested on a cube iwork8 air tablet),
and the swapping of the calling breaks things.
This breakage was likely not noticed in testing because on cherrytrail,
currently chv_exec_gpio ends up disabling the gpio pins rather then
setting them (this is fixed in the next patch in this patch-set).
This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
places in the enum defining them, so that their (new) names match their
actual use.
Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Hans de Goede
Acked-by: Jani Nikula
---
Changes in v2:
-Add a comment to the enum explaining that the assert/reassert names
are swapped in the spec
---
drivers/gpu/drm/i915/intel_bios.h | 12 +---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 8405b5a..7e3545f 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -46,14 +46,20 @@ struct edp_power_seq {
u16 t11_t12;
} __packed;
-/* MIPI Sequence Block definitions */
+/*
+ * MIPI Sequence Block definitions
+ *
+ * Note the VBT spec has AssertReset / DeassertReset swapped from their
+ * usual naming, we use the proper names here to avoid confusion when
+ * reading the code.
+ */
enum mipi_seq {
MIPI_SEQ_END = 0,
- MIPI_SEQ_ASSERT_RESET,
+ MIPI_SEQ_DEASSERT_RESET,/* Spec says MipiAssertResetPin */
MIPI_SEQ_INIT_OTP,
MIPI_SEQ_DISPLAY_ON,
MIPI_SEQ_DISPLAY_OFF,
- MIPI_SEQ_DEASSERT_RESET,
+ MIPI_SEQ_ASSERT_RESET, /* Spec says MipiDeassertResetPin */
MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 0d8ff00..579d2f5 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
*/
static const char * const seq_name[] = {
- [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
+ [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
[MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
[MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
[MIPI_SEQ_DISPLAY_OFF] = "MIPI_SEQ_DISPLAY_OFF",
- [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
+ [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
[MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
[MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
[MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst
On Nov 30, 2016 19:41, "Daniel Vetter" wrote: > > On Tue, Nov 29, 2016 at 05:00:55PM +, Robert Bragg wrote: > > This adds a 'Perf' section to i915.rst with the following sub sections: > > - Overview > > - Comparison with Core Perf > > - i915 Driver Entry Points > > - i915 Perf Stream > > - i915 Perf Observation Architecture Stream > > - All i915 Perf Internals > > > > Signed-off-by: Robert Bragg > > Cc: Daniel Vetter > > Two style bikesheds below, feel free to ignore. > > > --- > > Documentation/gpu/i915.rst | 92 + > > drivers/gpu/drm/i915/i915_drv.h | 151 > > drivers/gpu/drm/i915/i915_perf.c | 289 ++ + > > 3 files changed, 478 insertions(+), 54 deletions(-) > > > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > > index 117d2ab..714bd4b 100644 > > --- a/Documentation/gpu/i915.rst > > +++ b/Documentation/gpu/i915.rst > > @@ -356,4 +356,96 @@ switch_mm > > .. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h > > :doc: switch_mm tracepoint > > > > +Perf > > + > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :doc: i915 Perf Overview > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :doc: i915 Perf History and Comparison with Core Perf > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :doc: i915 Perf File Operations > > You have the headings in the DOC comments itself, which works until > someone reorganizes stuff. Then it tends to fall apart badly. Yeah, could be better. > > > + > > +i915 Driver Entry Points > > + > > + > > +This section covers the entrypoints exported outside of i915_perf.c to > > +integrate with drm/i915 and to handle the `DRM_I915_PERF_OPEN` ioctl. > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_init > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_fini > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_register > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_unregister > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_open_ioctl > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_release > > One potential issue with listing everything explicitly is that if someone > ever (and this is bound to happen) adds a new function, they'll forget to > add it. Hence we just pull them all in, and if you want to refernce some > specifically, do that in the overview sections. And also sprinkle lots of > cross-references all over to make groups of functions easier to discover. Without any structure it just didn't seem like documentation; just a dump of internals info which didn't look that helpful to me. There are some fairly noteworthy separations of responsibilities between functions providing the i915 perf stream infrastructure and then the code for OA unit streams, and then code specifically for Haswell. Splitting them into sections seems worthwhile to me. I don't think it's that big a deal listing symbols individually and maintaining this when adding new symbols. Having maintained Cogl using gtk-doc where symbols had to be explicitly listed in a -sections.txt file to added them to the documentation, that wasn't too bad. It's true that slip ups happen, but having control over the order symbols are presented seems good to me. It could be nice if an ordered list could be passed to :functions: to reduce how many times the corresponding perl script runs. It could maybe be good if there was some way to tag/label symbols in kerneldoc for selection in restructured text. It would also be nice if the tooling understood what symbols were in the document so far, so it could somehow be possible to have a dumping ground section for 'everything else' at the end. Regards, - Robert > > But in the end your docs, your turf ;-) > -Daniel > > > + > > +i915 Perf Stream > > + > > + > > +This section covers the stream-semantics-agnostic structures and functions > > +for representing an i915 perf stream FD and associated file operations. > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h > > + :functions: i915_perf_stream > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h > > + :functions: i915_perf_stream_ops > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: read_properties_unlocked > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_open_ioctl_unlocked > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_destroy_unlocked > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_read > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_ioctl > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > > + :functions: i915_perf_enable_unlocked
Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce GEM_WARN_ON
On 2 December 2016 at 13:54, Chris Wilson wrote:
> On Fri, Dec 02, 2016 at 01:23:13PM +, Matthew Auld wrote:
>> In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, this
>> will enable us to freely add warnings which our CI will hopefully catch
>> but without fear of impacting production machines.
>>
>> Suggested-by: Chris Wilson
>> Signed-off-by: Matthew Auld
>> ---
>> drivers/gpu/drm/i915/i915_gem.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.h
>> b/drivers/gpu/drm/i915/i915_gem.h
>> index 51ec793f2e20..04c777e6d0bf 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.h
>> +++ b/drivers/gpu/drm/i915/i915_gem.h
>> @@ -27,8 +27,10 @@
>>
>> #ifdef CONFIG_DRM_I915_DEBUG_GEM
>> #define GEM_BUG_ON(expr) BUG_ON(expr)
>> +#define GEM_WARN_ON(expr) WARN_ON(expr)
>> #else
>> #define GEM_BUG_ON(expr) do { } while (0)
>> +#define GEM_WARN_ON(expr) do { } while (0)
>
> #define GEM_WARN_ON 0
Oops. As an alternative, would you be offended with something like:
#define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
Then the compiler will still check the validity of the expression, but
will still compile everything out, and then we don't accidentally
break the build when compiling without DEBUG_GEM ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst
On Thu, Dec 1, 2016 at 12:12 PM, Jani Nikula wrote: > On Wed, 30 Nov 2016, Daniel Vetter wrote: > > On Tue, Nov 29, 2016 at 05:00:55PM +, Robert Bragg wrote: > >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > >> + :functions: i915_perf_init > >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > >> + :functions: i915_perf_fini > >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > >> + :functions: i915_perf_register > >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > >> + :functions: i915_perf_unregister > >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > >> + :functions: i915_perf_open_ioctl > >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c > >> + :functions: i915_perf_release > > > > One potential issue with listing everything explicitly is that if someone > > ever (and this is bound to happen) adds a new function, they'll forget to > > add it. Hence we just pull them all in, and if you want to refernce some > > specifically, do that in the overview sections. > > One real issue with listing everything separately is that kernel-doc > parses the source file once per every kernel-doc directive. > Yeah, this is unfortunate and I'd originally hoped I could pass an ordered list which could reduce how often kernel-doc is run. In practice I haven't seen a performance problem with doing this though. > > Also, doesn't Sphinx complain about not having a blank line to end the > indented block after the directive? It might not, but I thought it > might. > Apparently it's ok, I've been generating and previewing the documentation and haven't seen a warning about this. >From the restructure text spec, regarding white space: "Blank lines may be omitted when the markup makes element separation unambiguous, in conjunction with indentation." Regards, - Robert > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Technology Center > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce GEM_WARN_ON
On Fri, Dec 02, 2016 at 03:11:05PM +, Matthew Auld wrote:
> On 2 December 2016 at 13:54, Chris Wilson wrote:
> > On Fri, Dec 02, 2016 at 01:23:13PM +, Matthew Auld wrote:
> >> In a similar spirit to GEM_BUG_ON we now also have GEM_WARN_ON, this
> >> will enable us to freely add warnings which our CI will hopefully catch
> >> but without fear of impacting production machines.
> >>
> >> Suggested-by: Chris Wilson
> >> Signed-off-by: Matthew Auld
> >> ---
> >> drivers/gpu/drm/i915/i915_gem.h | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_gem.h
> >> b/drivers/gpu/drm/i915/i915_gem.h
> >> index 51ec793f2e20..04c777e6d0bf 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem.h
> >> +++ b/drivers/gpu/drm/i915/i915_gem.h
> >> @@ -27,8 +27,10 @@
> >>
> >> #ifdef CONFIG_DRM_I915_DEBUG_GEM
> >> #define GEM_BUG_ON(expr) BUG_ON(expr)
> >> +#define GEM_WARN_ON(expr) WARN_ON(expr)
> >> #else
> >> #define GEM_BUG_ON(expr) do { } while (0)
> >> +#define GEM_WARN_ON(expr) do { } while (0)
> >
> > #define GEM_WARN_ON 0
> Oops. As an alternative, would you be offended with something like:
>
> #define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
>
> Then the compiler will still check the validity of the expression, but
> will still compile everything out, and then we don't accidentally
> break the build when compiling without DEBUG_GEM ?
Ooh, new shiny. Uses sizeof()! Can you prepare a patch to fixup
GEM_BUG_ON as well?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.17
A new intel-gpu-tools quarterly release is available with the following changes: Library changes: - Added an iterator that generate primes for creating input data that should not fall into any patterns that may be optimised by the drivers. (Chris Wilson) - Crashes in fixture blocks now print a stacktrace. (Marius Vlad) - Added support for various system suspend/resume options. (Imre Deak) - Added linked list helpers from the Wayland project. (Lyude) - Added a generic dummy workload helper for submitting GPU workloads that consume exactly a specified amount of time. (Abdiel Janulgue) - Added C functions for driver loading/unloading, pkill and lsof, for converting shell script tests to C code. (Marius Vlad) Tools changes: - intel_reg: Add Kabylake support. (Jani Nikula) - intel_bios_reader: Also dump PSR info. (Ville Syrjälä) - intel_guc_logger: New tool for capturing logs from the GuC firmware. (Akash Goel) - intel_aubdump: Added commandline option to stream the dump to another process. (Lionel Landwerlin) - intel_aubdump: Annotate the dump with the application name and the used PCI ID. (Jason Ekstrand) Benchmark changes: - gem_latency: Added support for measuring fence wakeup latencies. (Chris Wilson) - prime_lookup: New microbenchmark for stressing prime_fd_to_handle and prime_handle_to_fd. (Chris Wilson) Test changes: - Multiple new tests. - Added an explicit list of tests used for Intel CI. (Petri Latvala) - Converted multiple shell script tests to C. (Marius Vlad) And many other bug fixes and improvements. And the full changelog follows: Abdiel Janulgue (8): lib: Make signal helper definitions reusable lib: add igt_dummyload igt/gem_wait: Use new igt_spin_batch igt/kms_flip: Use new igt_spin_batch igt/kms_busy.c: Use new igt_spin_batch igt_dummyload: clear signal handler on the desructor as well igt/kms_flip: Fix set_dpms called with an idle bo igt_dummyload: Don't clear handler for invalid signal Akash Goel (1): This patch provides a test utility which helps capture GuC firmware logs and Chris Wilson (99): benchmarks/gem_latency: Measure fence wakeup latencies benchmarks/gem_busy: Merge all the sync_file fences together igt/gem_exec_nop: Relax assertion for parallel execution igt/gem_exec_nop: Check submitting nops to each engine in parallel igt/gem_exec_nop: Refine the target calculation igt/gem_ctx_switch: Increase execution weight igt/gem_exec_latency: Initial sketch for measuring execbuf cost in GPU cycles igt/gem_exec_nop: Show more timing details igt/gem_exec_whisper: Add competing child processes igt/gem_busy: Replace extended busy-ioctl testing in bat with simpler tests igt/gem_busy: Actually flag the hang tests to cause a GPU hang igt/gem_busy: Prevent banning when running multiple hang tests igt/kms_cursor_legacy: Reduce flip/cursor ordering to basics lib/kms: Probe connectors from igt_enable_connectors() lib: Add an iterator to generate primes lib: Export igt_debugfs_mount() lib: Add support for DROP_FREED in igt_drop_caches_set() lib: Add igt_primes.h to SOURCES igt/prime_vgem: Initialise pfd for both parent/child igt/gem_concurrent_all: Leave bufmgr destroyed before forking igt/gem_concurrent_blit: Limit number of reads for dmabufs benchmarks: Add some missing .gitignore binaries igt/gem_concurrent_blit: Only set the pixels to be compared (GTT paths) benchmarks: Add prime_lookup microbenchmark benchmarks/gem_blt: Remove () causing integer overflow igt/vgem: Add a basic test for handling of module unload overlay: Silence compiler warning for unused i81x_info igt/gem_userptr_blits: Tidy up the debug spam igt/gem_exec_whisper: Hang injection igt/kms_cursor_legacy: Check that a busy flip doesn't block the cursor igt/vgem_basic: Allow mmap() to persist without the vgem module loaded igt/kms_cursor_legacy: Deduplicate make_busy() igt/gem_exec_whisper: Tweaking the global seqno is not multiuser safe igt/gem_ctx_threads: Repeat threads until timeout igt/gem_ctx_thrash: Update context size estimates igt/gem_ctx_thrash: Include with-execlists indicator Remove igt/vgem_reload_basic And remove vgem_reload_basic form Makefile.sources igt/gem_wait: Use explicit timers igt/gem_exec_big: Secure dispatch is run through the GGTT, limit it such lib/igt_gt: Use /sys/.../error instead of /debug/.../i915_error_state igt/gem_wait: munmap the batch along all paths igt/gem_ctx_param: Tidy error messages igt/gem_ctx_param: Update invalid parma number lib/sysfs: Use a fallback for builtin modules benchmarks/gem_blt: Directly compare the cmdparser tools/l3_parity: Skip on ivb with only a single slice igt: Trim timeouts for basic GEM t
Re: [Intel-gfx] [PATCH 1/3] drm: Add a new connector atomic property for link status
On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the link should be reduced, but we can't reduce
> the link below the requirements of the mode. Black screen follows.
>
> One idea would be to have setcrtc return a failure. However, it
> already should not fail as the atomic checks have passed. It would
> also conflict with the idea of making setcrtc asynchronous in the
> future, returning before the actual mode setting and link training.
>
> Another idea is to train the link "upfront" at hotplug time, before
> pruning the mode list, so that we can do the pruning based on
> practical not theoretical capabilities. However, the changes for link
> training are pretty drastic, all for the sake of error handling and
> DP compliance, when the most common happy day scenario is the current
> approach of link training at mode setting time, using the optimal
> parameters for the mode. It is also not certain all hardware could do
> this without the pipe on; not even all our hardware can do this. Some
> of this can be solved, but not trivially.
>
> Both of the above ideas also fail to address link degradation *during*
> operation.
>
> The solution is to add a new "link-status" connector property in order
> to address link training failure in a way that:
> a) changes the current happy day scenario as little as possible, to
> avoid regressions, b) can be implemented the same way by all drm
> drivers, c) is still opt-in for the drivers and userspace, and opting
> out doesn't regress the user experience, d) doesn't prevent drivers
> from implementing better or alternate approaches, possibly without
> userspace involvement. And, of course, handles all the issues presented.
> In the usual happy day scenario, this is always "good". If something
> fails during or after a mode set, the kernel driver can set the link
> status to "bad" and issue a hotplug uevent for userspace to have it
> re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> again. If the theoretical capabilities of the link can't be reached,
> the mode list is trimmed based on that.
>
> v4:
> * Add comments in kernel-doc format (Daniel Vetter)
> * Update the kernel-doc for link-status (Sean Paul)
> v3:
> * Fixed a build error (Jani Saarinen)
> v2:
> * Removed connector->link_status (Daniel Vetter)
> * Set connector->state->link_status in
> drm_mode_connector_set_link_status_property
> (Daniel Vetter)
> * Set the connector_changed flag to true if connector->state->link_status
> changed.
> * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
>
> Acked-by: Tony Cheng
> Acked-by: Harry Wentland
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Cc: Sean Paul
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_atomic.c| 10 +++
> drivers/gpu/drm/drm_atomic_helper.c | 8 ++
> drivers/gpu/drm/drm_connector.c | 54
> -
> include/drm/drm_connector.h | 19 +
> include/drm/drm_mode_config.h | 5
> include/uapi/drm/drm_mode.h | 4 +++
> 6 files changed, 99 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 89737e4..990f013 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>* now?) atomic writes to DPMS property:
>*/
> return -EINVAL;
> + } else if (property == config->link_status_property) {
> + /* Never downgrade from GOOD to BAD on userspace's request here,
> + * only hw issues can do that.
> + */
> + if (state->link_status == DRM_LINK_STATUS_GOOD)
> + return 0;
> + state->link_status = val;
> + return 0;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
> *val = (state->crtc) ? state->crtc->base.id : 0;
> } else if (property == config->dpms_property) {
> *val = connector->dpms;
> + } else if (property == config->link_status_property) {
> + *val = state->link_status;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/dri
[Intel-gfx] [PATCH] drm/i915: Add I2C and DP-AUX char devices to debug kconfig
These char devices exposing the driver's I2C and DP-AUX adapters for user space tools are useful to debug display output related issues. Enable them with the rest of additional driver debug options. Suggested-by: Chris Wilson Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/Kconfig.debug | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index a6c69b8..cc4ad57 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -19,6 +19,8 @@ config DRM_I915_DEBUG bool "Enable additional driver debugging" depends on DRM_I915 select PREEMPT_COUNT +select I2C_CHARDEV +select DRM_DP_AUX_CHARDEV select X86_MSR # used by igt/pm_rpm select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) select DRM_DEBUG_MM if DRM=y -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.17
Awesome. Looks good to me and Thanks! On Fri, Dec 02, 2016 at 06:19:40PM +0200, Petri Latvala wrote: > A new intel-gpu-tools quarterly release is available with the > following changes: > > Library changes: > > - Added an iterator that generate primes for creating input data that > should not fall into any patterns that may be optimised by the > drivers. (Chris Wilson) > > - Crashes in fixture blocks now print a stacktrace. (Marius Vlad) > > - Added support for various system suspend/resume options. (Imre Deak) > > - Added linked list helpers from the Wayland project. (Lyude) > > - Added a generic dummy workload helper for submitting GPU workloads > that consume exactly a specified amount of time. (Abdiel Janulgue) > > - Added C functions for driver loading/unloading, pkill and lsof, for > converting shell script tests to C code. (Marius Vlad) > > Tools changes: > > - intel_reg: Add Kabylake support. (Jani Nikula) > > - intel_bios_reader: Also dump PSR info. (Ville Syrjälä) > > - intel_guc_logger: New tool for capturing logs from the GuC > firmware. (Akash Goel) > > - intel_aubdump: Added commandline option to stream the dump to > another process. (Lionel Landwerlin) > > - intel_aubdump: Annotate the dump with the application name and the > used PCI ID. (Jason Ekstrand) > > Benchmark changes: > > - gem_latency: Added support for measuring fence wakeup latencies. (Chris > Wilson) > > - prime_lookup: New microbenchmark for stressing prime_fd_to_handle > and prime_handle_to_fd. (Chris Wilson) > > Test changes: > > - Multiple new tests. > > - Added an explicit list of tests used for Intel CI. (Petri Latvala) > > - Converted multiple shell script tests to C. (Marius Vlad) > > > And many other bug fixes and improvements. > > > And the full changelog follows: > > Abdiel Janulgue (8): > lib: Make signal helper definitions reusable > lib: add igt_dummyload > igt/gem_wait: Use new igt_spin_batch > igt/kms_flip: Use new igt_spin_batch > igt/kms_busy.c: Use new igt_spin_batch > igt_dummyload: clear signal handler on the desructor as well > igt/kms_flip: Fix set_dpms called with an idle bo > igt_dummyload: Don't clear handler for invalid signal > > Akash Goel (1): > This patch provides a test utility which helps capture GuC firmware > logs and > > Chris Wilson (99): > benchmarks/gem_latency: Measure fence wakeup latencies > benchmarks/gem_busy: Merge all the sync_file fences together > igt/gem_exec_nop: Relax assertion for parallel execution > igt/gem_exec_nop: Check submitting nops to each engine in parallel > igt/gem_exec_nop: Refine the target calculation > igt/gem_ctx_switch: Increase execution weight > igt/gem_exec_latency: Initial sketch for measuring execbuf cost in GPU > cycles > igt/gem_exec_nop: Show more timing details > igt/gem_exec_whisper: Add competing child processes > igt/gem_busy: Replace extended busy-ioctl testing in bat with simpler > tests > igt/gem_busy: Actually flag the hang tests to cause a GPU hang > igt/gem_busy: Prevent banning when running multiple hang tests > igt/kms_cursor_legacy: Reduce flip/cursor ordering to basics > lib/kms: Probe connectors from igt_enable_connectors() > lib: Add an iterator to generate primes > lib: Export igt_debugfs_mount() > lib: Add support for DROP_FREED in igt_drop_caches_set() > lib: Add igt_primes.h to SOURCES > igt/prime_vgem: Initialise pfd for both parent/child > igt/gem_concurrent_all: Leave bufmgr destroyed before forking > igt/gem_concurrent_blit: Limit number of reads for dmabufs > benchmarks: Add some missing .gitignore binaries > igt/gem_concurrent_blit: Only set the pixels to be compared (GTT paths) > benchmarks: Add prime_lookup microbenchmark > benchmarks/gem_blt: Remove () causing integer overflow > igt/vgem: Add a basic test for handling of module unload > overlay: Silence compiler warning for unused i81x_info > igt/gem_userptr_blits: Tidy up the debug spam > igt/gem_exec_whisper: Hang injection > igt/kms_cursor_legacy: Check that a busy flip doesn't block the cursor > igt/vgem_basic: Allow mmap() to persist without the vgem module loaded > igt/kms_cursor_legacy: Deduplicate make_busy() > igt/gem_exec_whisper: Tweaking the global seqno is not multiuser safe > igt/gem_ctx_threads: Repeat threads until timeout > igt/gem_ctx_thrash: Update context size estimates > igt/gem_ctx_thrash: Include with-execlists indicator > Remove igt/vgem_reload_basic > And remove vgem_reload_basic form Makefile.sources > igt/gem_wait: Use explicit timers > igt/gem_exec_big: Secure dispatch is run through the GGTT, limit it such > lib/igt_gt: Use /sys/.../error instead of /debug/.../i915_error_state > igt/gem_wait: munm
Re: [Intel-gfx] [PATCH] drm/i915: Calculate common rates and max lane count in Long pulse handler
Jani,
This patch is in response to your feedback previously on the fallback link rate
patch.
You had mentioned that we should in the long run move the common rates array and
max lane count to intel_dp so that it gets computed only once on hotplug and
then
gets used whenever it is requested.
This also greatly simplies the way we handle link training fallback, since
in that case we can directly modify the common len to the lower the max
supported link
rate and modify the max lane count to use lower lane count after reaching RBR.
This allows us to get rid of fallback_link_rate and fallback_lane_count
variables and makes this more generic without any link training retry specifics.
Could you please take a look at this patch?
I will likely submit the link training retraining series again basing it on top
of this patch to hav ethe simplified fallback link train logic.
Regards
Manasi
On Thu, Dec 01, 2016 at 08:02:09PM -0800, Manasi Navare wrote:
> Supported link rate common to source and sink as well as the
> maximum supported lane count based on source and sink capabilities should
> be set only once on hotplug and then used anytime they are requested.
> This patch creates and array of common rates and max lane count as the
> intel_dp member. It gets calculated only once in the long pulse handler
> and then gets used when requested in compute_config and other functions.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_dp.c | 38 --
> drivers/gpu/drm/i915/intel_drv.h | 5 +
> 2 files changed, 21 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9dfbde4..de37807 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -274,8 +274,7 @@ static int intersect_rates(const int *source_rates, int
> source_len,
> return k;
> }
>
> -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> - int *common_rates)
> +static int intel_dp_common_rates(struct intel_dp *intel_dp)
> {
> const int *source_rates, *sink_rates;
> int source_len, sink_len;
> @@ -285,7 +284,7 @@ static int intel_dp_common_rates(struct intel_dp
> *intel_dp,
>
> return intersect_rates(source_rates, source_len,
> sink_rates, sink_len,
> -common_rates);
> +intel_dp->common_rates);
> }
>
> static enum drm_mode_status
> @@ -312,7 +311,7 @@ static int intel_dp_common_rates(struct intel_dp
> *intel_dp,
> }
>
> max_link_clock = intel_dp_max_link_rate(intel_dp);
> - max_lanes = intel_dp_max_lane_count(intel_dp);
> + max_lanes = intel_dp->max_lane_count;
>
> max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> mode_rate = intel_dp_link_required(target_clock, 18);
> @@ -1430,8 +1429,7 @@ static void snprintf_int_array(char *str, size_t len,
> static void intel_dp_print_rates(struct intel_dp *intel_dp)
> {
> const int *source_rates, *sink_rates;
> - int source_len, sink_len, common_len;
> - int common_rates[DP_MAX_SUPPORTED_RATES];
> + int source_len, sink_len;
> char str[128]; /* FIXME: too big for stack? */
>
> if ((drm_debug & DRM_UT_KMS) == 0)
> @@ -1445,8 +1443,8 @@ static void intel_dp_print_rates(struct intel_dp
> *intel_dp)
> snprintf_int_array(str, sizeof(str), sink_rates, sink_len);
> DRM_DEBUG_KMS("sink rates: %s\n", str);
>
> - common_len = intel_dp_common_rates(intel_dp, common_rates);
> - snprintf_int_array(str, sizeof(str), common_rates, common_len);
> + snprintf_int_array(str, sizeof(str), intel_dp->common_rates,
> +intel_dp->common_len);
> DRM_DEBUG_KMS("common rates: %s\n", str);
> }
>
> @@ -1495,14 +1493,12 @@ static int rate_to_index(int find, const int *rates)
> int
> intel_dp_max_link_rate(struct intel_dp *intel_dp)
> {
> - int rates[DP_MAX_SUPPORTED_RATES] = {};
> - int len;
> + int len = intel_dp->common_len;
>
> - len = intel_dp_common_rates(intel_dp, rates);
> if (WARN_ON(len <= 0))
> return 162000;
>
> - return rates[len - 1];
> + return intel_dp->common_rates[len - 1];
> }
>
> int intel_dp_rate_select(struct intel_dp *intel_dp, int rate)
> @@ -1550,22 +1546,18 @@ static int intel_dp_compute_bpp(struct intel_dp
> *intel_dp,
> struct intel_connector *intel_connector = intel_dp->attached_connector;
> int lane_count, clock;
> int min_lane_count = 1;
> - int max_lane_count = intel_dp_max_lane_count(intel_dp);
> + int max_lane_count = intel_dp->max_lane_count;
> /* Conveniently, the link BW constants become indices with a shift...*/
> int min_clock = 0;
> int max_clock;
> int bpp, mode_rate;
> int link_avail,
Re: [Intel-gfx] [PATCH 1/3] drm: Add a new connector atomic property for link status
On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
> > At the time userspace does setcrtc, we've already promised the mode
> > would work. The promise is based on the theoretical capabilities of
> > the link, but it's possible we can't reach this in practice. The DP
> > spec describes how the link should be reduced, but we can't reduce
> > the link below the requirements of the mode. Black screen follows.
> >
> > One idea would be to have setcrtc return a failure. However, it
> > already should not fail as the atomic checks have passed. It would
> > also conflict with the idea of making setcrtc asynchronous in the
> > future, returning before the actual mode setting and link training.
> >
> > Another idea is to train the link "upfront" at hotplug time, before
> > pruning the mode list, so that we can do the pruning based on
> > practical not theoretical capabilities. However, the changes for link
> > training are pretty drastic, all for the sake of error handling and
> > DP compliance, when the most common happy day scenario is the current
> > approach of link training at mode setting time, using the optimal
> > parameters for the mode. It is also not certain all hardware could do
> > this without the pipe on; not even all our hardware can do this. Some
> > of this can be solved, but not trivially.
> >
> > Both of the above ideas also fail to address link degradation *during*
> > operation.
> >
> > The solution is to add a new "link-status" connector property in order
> > to address link training failure in a way that:
> > a) changes the current happy day scenario as little as possible, to
> > avoid regressions, b) can be implemented the same way by all drm
> > drivers, c) is still opt-in for the drivers and userspace, and opting
> > out doesn't regress the user experience, d) doesn't prevent drivers
> > from implementing better or alternate approaches, possibly without
> > userspace involvement. And, of course, handles all the issues presented.
> > In the usual happy day scenario, this is always "good". If something
> > fails during or after a mode set, the kernel driver can set the link
> > status to "bad" and issue a hotplug uevent for userspace to have it
> > re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> > again. If the theoretical capabilities of the link can't be reached,
> > the mode list is trimmed based on that.
> >
> > v4:
> > * Add comments in kernel-doc format (Daniel Vetter)
> > * Update the kernel-doc for link-status (Sean Paul)
> > v3:
> > * Fixed a build error (Jani Saarinen)
> > v2:
> > * Removed connector->link_status (Daniel Vetter)
> > * Set connector->state->link_status in
> > drm_mode_connector_set_link_status_property
> > (Daniel Vetter)
> > * Set the connector_changed flag to true if connector->state->link_status
> > changed.
> > * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> > * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
> >
> > Acked-by: Tony Cheng
> > Acked-by: Harry Wentland
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Ville Syrjala
> > Cc: Chris Wilson
> > Cc: Sean Paul
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/drm_atomic.c| 10 +++
> > drivers/gpu/drm/drm_atomic_helper.c | 8 ++
> > drivers/gpu/drm/drm_connector.c | 54
> > -
> > include/drm/drm_connector.h | 19 +
> > include/drm/drm_mode_config.h | 5
> > include/uapi/drm/drm_mode.h | 4 +++
> > 6 files changed, 99 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 89737e4..990f013 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > * now?) atomic writes to DPMS property:
> > */
> > return -EINVAL;
> > + } else if (property == config->link_status_property) {
> > + /* Never downgrade from GOOD to BAD on userspace's request here,
> > +* only hw issues can do that.
> > +*/
> > + if (state->link_status == DRM_LINK_STATUS_GOOD)
> > + return 0;
> > + state->link_status = val;
> > + return 0;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct
> > drm_printer *p,
> > *val = (state->crtc) ? state->crtc->base.id : 0;
> > } else if (property == config->dpms_property) {
> > *val = connector->dpms;
> > + } else if (property == config->link_status_property) {
> > + *val =
Re: [Intel-gfx] [PATCH] drm/i915: Always load guc by default.
>-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Thursday, November 24, 2016 12:41 AM >To: Tvrtko Ursulin >Cc: Srivatsa, Anusha ; intel- >g...@lists.freedesktop.org; Mcgee, Jeff >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Always load guc by default. > >On Thu, Nov 24, 2016 at 08:31:22AM +, Tvrtko Ursulin wrote: >> >> On 24/11/2016 08:21, Chris Wilson wrote: >> >On Thu, Nov 24, 2016 at 08:15:31AM +, Tvrtko Ursulin wrote: >> >> >> >>On 24/11/2016 07:13, Chris Wilson wrote: >> >>>On Wed, Nov 23, 2016 at 04:52:38PM -0800, Anusha Srivatsa wrote: >> Remove the enable_guc_loading parameter. Load the GuC on plaforms >> that have GuC. All issues we found so far are related to GuC >> features like the command submission, but no bug is related to the >> guc loading itself. >> >> This addresses the case when we need GuC loaded even with no GuC >> feature in use, like - GuC authenticating HuC loading. >> >>> >> >>>Why not just load the firmware if it may be used? >> >> >> >>It was discussed briefly in the other thread, but I suppose as soon >> >>as the HuC patches go in that would be always so it may not be that >> >>useful. >> >> >> >>Unless there is a reason to add a HuC enable/disable parameter in >> >>general. I have no idea on that one. >> > >> >In hindsight, we should have had i915.enable_dmc to easily protect >> >users against failures. History says we will regret enabling a new >> >piece of hw/fw without a feature option. >> >> So.. >> >> 1. Add i915.enable_huc, default to enabled 2. Unexport >> i915.enable_guc_loading 3. Gate enable_guc_loading by i915.enable_huc >> and i915.enable_guc_submission > >Aye, that would be my preference. >-Chris So, basically control the guc loads depending on huc_enable or guc_submission parameter. If either or both are enabled then load guc. No need to load guc if a platform has one? Any thought on having 0,-1,1 and 2 values for submission? 1 is load if guc is available (but do not error out if not present) and 2 is load and fail if not present. I am thinking what if we need that differentiation. -Anusha >-- >Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add I2C and DP-AUX char devices to debug kconfig
== Series Details == Series: drm/i915: Add I2C and DP-AUX char devices to debug kconfig URL : https://patchwork.freedesktop.org/series/16295/ State : success == Summary == Series 16295v1 drm/i915: Add I2C and DP-AUX char devices to debug kconfig https://patchwork.freedesktop.org/api/1.0/series/16295/revisions/1/mbox/ fi-bdw-5557u total:247 pass:232 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:247 pass:207 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:247 pass:219 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:247 pass:219 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:247 pass:194 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:247 pass:223 dwarn:3 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 16c2727017476099091b70f53da7eb365f2a001e drm-tip: 2016y-12m-02d-16h-19m-57s UTC integration manifest c17d464 drm/i915: Add I2C and DP-AUX char devices to debug kconfig == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3176/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/glk: Reuse broxton code for geminilake
On Fri, 2016-12-02 at 10:27 +0200, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-12-01 at 17:06 -0800, Rodrigo Vivi wrote:
> > A reviewed backwards because I was willing to check if all ifs were in
> > place.
> >
> > I missed the ones from i915_drv.c
> >
> > *** i915_drv.c:
> > i915_drm_suspend_late[1500]fw_csr = !IS_GEN9_LP(dev_priv) &&
> > i915_drm_suspend_late[1513]if (IS_GEN9_LP(dev_priv))
> > i915_drm_resume_early[1721]if (IS_GEN9_LP(dev_priv)) {
> > i915_drm_resume_early[1731]if (IS_GEN9_LP(dev_priv) ||
> > intel_runtime_suspend[2354]if (IS_GEN9_LP(dev_priv)) {
> > intel_runtime_resume[2439] if (IS_GEN9_LP(dev_priv)) {
> >
> > The ones that I had added with the patch
> > "drm/i915/glk: Add missing bits to allow runtime pm suspend on GLK."
> >
> > Feel free to squash all those into this patch if you like. However I believe
> > that before that one we need Anusha's dmc load patch that is one that I'm
> > also
> > missing on this series here, right?
> >
> > So any option works for me and if you decide to move with this feel free to
> > use
> > Reviewed-by: Rodrigo Vivi
> >
> > And please let me know what are your plans with this runtime_pm related
> > patches and if you need anything from me.
>
> I was planning to do those as a follow up once this series is merged. I didn't
> want to make it any bigger to make review easier.
yep. Makes sense. Good idea.
>
> Ander
>
> >
> > Thanks,
> > Rodrigo.
> >
> > On Tue, Nov 29, 2016 at 05:47:12PM +0200, Ander Conselvan de Oliveira wrote:
> > >
> > > Geminilake is mostly backwards compatible with broxton, so change most
> > > of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the
> > > platforms will be implemented in follow-up patches.
> > >
> > > v2: Don't reuse broxton's path in intel_update_max_cdclk().
> > > Don't set plane count as in broxton.
> > >
> > > v3: Rebase
> > >
> > > v4: Include the check intel_bios_is_port_hpd_inverted().
> > > Commit message.
> > >
> > > v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo)
> > >
> > > v6: Rebase.
> > >
> > > v7: Convert a few mode IS_BROXTON() occurances in pps, ddi, dsi and pll
> > > code. (Rodrigo)
> > >
> > > Cc: Rodrigo Vivi
> > > Signed-off-by: Ander Conselvan de Oliveira
> > > > > l.com>
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
> > > drivers/gpu/drm/i915/i915_gem_gtt.c | 8
> > > drivers/gpu/drm/i915/i915_irq.c | 10 +-
> > > drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> > > drivers/gpu/drm/i915/intel_bios.c | 2 +-
> > > drivers/gpu/drm/i915/intel_ddi.c| 18 +-
> > > drivers/gpu/drm/i915/intel_display.c| 12 ++--
> > > drivers/gpu/drm/i915/intel_dp.c | 24
> > > drivers/gpu/drm/i915/intel_dpio_phy.c | 1 -
> > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
> > > drivers/gpu/drm/i915/intel_dsi.c| 30
> > > +++---
> > > drivers/gpu/drm/i915/intel_dsi_pll.c| 12 ++--
> > > drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
> > > drivers/gpu/drm/i915/intel_i2c.c| 4 ++--
> > > drivers/gpu/drm/i915/intel_mocs.c | 2 +-
> > > drivers/gpu/drm/i915/intel_panel.c | 2 +-
> > > drivers/gpu/drm/i915/intel_pm.c | 6 +++---
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +++---
> > > 18 files changed, 79 insertions(+), 80 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 8eb8c29..6c17d39 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -1108,7 +1108,7 @@ static int i915_frequency_info(struct seq_file *m,
> > > void *unused)
> > > int max_freq;
> > >
> > > rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
> > > - if (IS_BROXTON(dev_priv)) {
> > > + if (IS_GEN9_LP(dev_priv)) {
> > > rp_state_cap = I915_READ(BXT_RP_STATE_CAP);
> > > gt_perf_status = I915_READ(BXT_GT_PERF_STATUS);
> > > } else {
> > > @@ -1204,7 +1204,7 @@ static int i915_frequency_info(struct seq_file *m,
> > > void *unused)
> > > seq_printf(m, "Down threshold: %d%%\n",
> > > dev_priv->rps.down_threshold);
> > >
> > > - max_freq = (IS_BROXTON(dev_priv) ? rp_state_cap >> 0 :
> > > + max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
> > > rp_state_cap >> 16) & 0xff;
> > > max_freq *= (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)
> > > ?
> > >GEN9_FREQ_SCALER : 1);
> > > @@ -1217,7 +1217,7 @@ static int i915_frequency_info(struct seq_file *m,
> > > void *unused)
> > > seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
> > > intel_gpu_freq(dev_priv, max_freq));
> > >
> > >
[Intel-gfx] [PATCH] drm/i915: allow GEM_BUG_ON expr checking with !DEBUG_GEM
Use BUILD_BUG_ON_INVALID(expr) in GEM_BUG_ON when building without
DEBUG_GEM. This means the compiler can now check the validity of expr
without generating any code, in turn preventing us from inadvertently
breaking the build when DEBUG_GEM is not enabled.
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 51ec793f2e20..8801a14a78a2 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -28,7 +28,7 @@
#ifdef CONFIG_DRM_I915_DEBUG_GEM
#define GEM_BUG_ON(expr) BUG_ON(expr)
#else
-#define GEM_BUG_ON(expr) do { } while (0)
+#define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
#endif
#define I915_NUM_ENGINES 5
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: allow GEM_BUG_ON expr checking with !DEBUG_GEM
== Series Details == Series: drm/i915: allow GEM_BUG_ON expr checking with !DEBUG_GEM URL : https://patchwork.freedesktop.org/series/16298/ State : warning == Summary == Series 16298v1 drm/i915: allow GEM_BUG_ON expr checking with !DEBUG_GEM https://patchwork.freedesktop.org/api/1.0/series/16298/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-connector-state: pass -> DMESG-WARN (fi-snb-2520m) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b: pass -> DMESG-WARN (fi-ivb-3770) fi-bdw-5557u total:247 pass:232 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:247 pass:207 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:247 pass:219 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:247 pass:219 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:247 pass:194 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:247 pass:224 dwarn:1 dfail:0 fail:0 skip:22 fi-kbl-7500u total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:247 pass:223 dwarn:3 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:247 pass:214 dwarn:1 dfail:0 fail:0 skip:32 fi-snb-2600 total:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 16c2727017476099091b70f53da7eb365f2a001e drm-tip: 2016y-12m-02d-16h-19m-57s UTC integration manifest a909a17 drm/i915: allow GEM_BUG_ON expr checking with !DEBUG_GEM == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3177/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation
On Wed, Nov 23, 2016 at 03:59:52PM +0200, Jani Nikula wrote:
> On Tue, 22 Nov 2016, Manasi Navare wrote:
> > +
> > +static void get_test_videopattern_data(void)
> > +{
> > + int count = 0;
> > + uint16_t video_pattern_value[3];
> > + char video_pattern_attribute[15];
> > +
> > + if (!test_data_fp)
> > + fprintf(stderr, "Invalid Test data File pointer\r\n");
> > +
> > + rewind(test_data_fp);
> > + while (!feof(test_data_fp) && count < 3)
> > + fscanf(test_data_fp, "%s %u\n", video_pattern_attribute,
> > + (unsigned int *)&video_pattern_value[count++]);
> > +
> > + hdisplay = video_pattern_value[0];
> > + vdisplay = video_pattern_value[1];
> > + bitdepth = video_pattern_value[2];
> > + igt_info("Hdisplay = %d\r\n", hdisplay);
> > + igt_info("Vdisplay = %d\r\n", vdisplay);
> > + igt_info("BitDepth = %u\r\n", bitdepth);
> > +
> > +}
>
> If you have this working now, I guess we can go with what's in [1] since
> that's fairly isolated for now. It's debugfs, so we can remove it
> later. In the long run, I do want this using DPCD directly though.
>
> BR,
> Jani.
>
>
>
> [1]
> http://patchwork.freedesktop.org/patch/msgid/1479850766-32748-6-git-send-email-manasi.d.nav...@intel.com
>
>
>
>
Thanks for your feedback Jani.
Yes, I have the debugfs interface fully functional and validated with DPR-120
compliance unit. So I agree that we can stick with this for now and since its
debugfs we can replace it later with reading the dpcd directly in IGT tool
if and when the number of DPCD registers increases for more testing. For now its
literally only 3 values (for video) and 1 for EDID that we are reading from
DPCD
through the debugfs interface.
Manasi
> > +
> > +static int process_test_request(int test_type)
> > +{
> > + int mode;
> > + unsigned long test_data_edid;
> > + int status = 0;
> > +
> > + switch (test_type) {
> > + case DP_TEST_LINK_VIDEO_PATTERN:
> > + video_pattern_flag = true;
> > + get_test_videopattern_data();
> > + mode = INTEL_MODE_VIDEO_PATTERN_TEST;
> > + break;
> > + case DP_TEST_LINK_EDID_READ:
> > + test_data_edid = get_test_edid_data();
> > + mode = (test_data_edid & DP_COMPLIANCE_VIDEO_MODE_MASK) >>
> > + INTEL_DP_RESOLUTION_SHIFT_MASK;
> > + break;
> > + default:
> > + /* Unknown test type */
> > + fprintf(stderr, "Invalid test request. Ignored.\r\n");
> > + break;
> > + }
> > + status = update_display(mode, true);
> > +
> > + /* Return 0 on success and -1 on failure */
> > + return status;
> > +}
> > +
> > +static void dump_connectors_fd(int drmfd)
> > +{
> > + int i, j;
> > +
> > + drmModeRes *mode_resources = drmModeGetResources(drmfd);
> > +
> > + if (!mode_resources) {
> > + igt_warn("drmModeGetResources failed: %s\n", strerror(errno));
> > + return;
> > + }
> > +
> > + igt_info("Connectors:\n");
> > + igt_info("id\tencoder\tstatus\t\ttype\tsize (mm)\tmodes\n");
> > + for (i = 0; i < mode_resources->count_connectors; i++) {
> > + drmModeConnector *connector;
> > +
> > + connector = drmModeGetConnectorCurrent(drmfd,
> > +
> > mode_resources->connectors[i]);
> > + if (!connector) {
> > + igt_warn("could not get connector %i: %s\n",
> > mode_resources->connectors[i], strerror(errno));
> > + continue;
> > + }
> > +
> > + igt_info("%d\t%d\t%s\t%s\t%dx%d\t\t%d\n",
> > connector->connector_id, connector->encoder_id,
> > kmstest_connector_status_str(connector->connection),
> > kmstest_connector_type_str(connector->connector_type), connector->mmWidth,
> > connector->mmHeight, connector->count_modes);
> > +
> > + if (!connector->count_modes)
> > + continue;
> > +
> > + igt_info(" modes:\n");
> > + igt_info(" name refresh (Hz) hdisp hss hse htot vdisp ""vss
> > vse vtot flags type clock\n");
> > + for (j = 0; j < connector->count_modes; j++) {
> > + igt_info("[%d]", j);
> > + kmstest_dump_mode(&connector->modes[j]);
> > + }
> > +
> > + drmModeFreeConnector(connector);
> > + }
> > + igt_info("\n");
> > +
> > + drmModeFreeResources(mode_resources);
> > +}
> > +
> > +static void dump_crtcs_fd(int drmfd)
> > +{
> > + int i;
> > + drmModeRes *mode_resources = drmModeGetResources(drmfd);
> > +
> > + igt_info("CRTCs:\n");
> > + igt_info("id\tfb\tpos\tsize\n");
> > + for (i = 0; i < mode_resources->count_crtcs; i++) {
> > + drmModeCrtc *crtc;
> > +
> > + crtc = drmModeGetCrtc(drmfd, mode_resources->crtcs[i]);
> > + if (!crtc) {
> > + igt_warn("could not get crtc %i: %s\n",
> > mode_resources->crtcs[i], strerror(errno));
> > + contin
Re: [Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation
Petri and Marius, could you please review this patch when you have time? This tool has been evolved through the DPR-120 compliance testing. It has been fully verified using DPR-120 and it addresses the comments and concerns that Marius had few months ago on the older version of this tool. Regards Manasi On Mon, Nov 21, 2016 at 07:40:27PM -0800, Manasi Navare wrote: > This is the userspace component of the Displayport Compliance > testing software required for compliance testing of the I915 > Display Port driver. This must be running in order to successfully > complete Display Port compliance testing. This app and the kernel > code that accompanies it has been written to satify the requirements > of the Displayport Link CTS 1.2 rev1.1 specification from VESA. > Note that this application does not support eDP compliance testing. > This utility has an automation support for the Link training tests > (4.3.1.1. - 4.3.2.3), EDID tests (4.2.2.3 > - 4.2.2.6) and Video Pattern generation tests (4.3.3.1) from CTS > specification 1.2 Rev 1.1. > > This tool has the support for responding to the hotplug uevents > sent by compliance testting unit after each test. > > The Linux DUT running this utility must be in text (console) mode > and cannot have any other display manager running. Since this uses > sysfs nodes for kernel interaction, this utility should be run as > Root. Once this user application is up and running, waiting for > test requests, the test appliance software on the windows host > can now be used to execute the compliance tests. > > This app is based on some prior work done in April 2015 (by > Todd Previte ) > > Signed-off-by: Manasi Navare > --- > tools/Makefile.am |3 +- > tools/Makefile.sources |7 + > tools/intel_dp_compliance.c | 1045 > +++ > tools/intel_dp_compliance.h | 35 ++ > tools/intel_dp_compliance_hotplug.c | 123 + > 5 files changed, 1212 insertions(+), 1 deletion(-) > create mode 100644 tools/intel_dp_compliance.c > create mode 100644 tools/intel_dp_compliance.h > create mode 100644 tools/intel_dp_compliance_hotplug.c > > diff --git a/tools/Makefile.am b/tools/Makefile.am > index 18f86f6..eac6d64 100644 > --- a/tools/Makefile.am > +++ b/tools/Makefile.am > @@ -13,7 +13,7 @@ AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/lib > AM_CFLAGS = $(DEBUG_CFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) $(CWARNFLAGS) \ > $(CAIRO_CFLAGS) $(LIBUNWIND_CFLAGS) -DPKGDATADIR=\"$(pkgdatadir)\" \ > $(WERROR_CFLAGS) > -LDADD = $(top_builddir)/lib/libintel_tools.la > +LDADD = $(top_builddir)/lib/libintel_tools.la $(GLIB_LIBS) > AM_LDFLAGS = -Wl,--as-needed > > > @@ -24,6 +24,7 @@ moduledir = $(libdir) > intel_aubdump_la_LDFLAGS = -module -avoid-version -no-undefined > intel_aubdump_la_SOURCES = aubdump.c > intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la -ldl > +intel_dp_compliance_la_LIBADD = $(LDADD) > > bin_SCRIPTS = intel_aubdump > CLEANFILES = $(bin_SCRIPTS) > diff --git a/tools/Makefile.sources b/tools/Makefile.sources > index be58871..09c0667 100644 > --- a/tools/Makefile.sources > +++ b/tools/Makefile.sources > @@ -13,6 +13,7 @@ tools_prog_lists = \ > intel_bios_reader \ > intel_display_crc \ > intel_display_poller\ > + intel_dp_compliance \ > intel_forcewaked\ > intel_gpu_frequency \ > intel_firmware_decode \ > @@ -55,3 +56,9 @@ intel_l3_parity_SOURCES = \ > intel_l3_parity.h \ > intel_l3_udev_listener.c > > +intel_dp_compliance_SOURCES = \ > +intel_dp_compliance.c \ > +intel_dp_compliance.h \ > +intel_dp_compliance_hotplug.c \ > +$(NULL) > + > diff --git a/tools/intel_dp_compliance.c b/tools/intel_dp_compliance.c > new file mode 100644 > index 000..967d2f8 > --- /dev/null > +++ b/tools/intel_dp_compliance.c > @@ -0,0 +1,1045 @@ > +/* > + * Copyright ? 2014-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
Re: [Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation
Adding both Petri and Marius in CC. Regards Manasi On Mon, Nov 21, 2016 at 07:40:27PM -0800, Manasi Navare wrote: > This is the userspace component of the Displayport Compliance > testing software required for compliance testing of the I915 > Display Port driver. This must be running in order to successfully > complete Display Port compliance testing. This app and the kernel > code that accompanies it has been written to satify the requirements > of the Displayport Link CTS 1.2 rev1.1 specification from VESA. > Note that this application does not support eDP compliance testing. > This utility has an automation support for the Link training tests > (4.3.1.1. - 4.3.2.3), EDID tests (4.2.2.3 > - 4.2.2.6) and Video Pattern generation tests (4.3.3.1) from CTS > specification 1.2 Rev 1.1. > > This tool has the support for responding to the hotplug uevents > sent by compliance testting unit after each test. > > The Linux DUT running this utility must be in text (console) mode > and cannot have any other display manager running. Since this uses > sysfs nodes for kernel interaction, this utility should be run as > Root. Once this user application is up and running, waiting for > test requests, the test appliance software on the windows host > can now be used to execute the compliance tests. > > This app is based on some prior work done in April 2015 (by > Todd Previte ) > > Signed-off-by: Manasi Navare > --- > tools/Makefile.am |3 +- > tools/Makefile.sources |7 + > tools/intel_dp_compliance.c | 1045 > +++ > tools/intel_dp_compliance.h | 35 ++ > tools/intel_dp_compliance_hotplug.c | 123 + > 5 files changed, 1212 insertions(+), 1 deletion(-) > create mode 100644 tools/intel_dp_compliance.c > create mode 100644 tools/intel_dp_compliance.h > create mode 100644 tools/intel_dp_compliance_hotplug.c > > diff --git a/tools/Makefile.am b/tools/Makefile.am > index 18f86f6..eac6d64 100644 > --- a/tools/Makefile.am > +++ b/tools/Makefile.am > @@ -13,7 +13,7 @@ AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/lib > AM_CFLAGS = $(DEBUG_CFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) $(CWARNFLAGS) \ > $(CAIRO_CFLAGS) $(LIBUNWIND_CFLAGS) -DPKGDATADIR=\"$(pkgdatadir)\" \ > $(WERROR_CFLAGS) > -LDADD = $(top_builddir)/lib/libintel_tools.la > +LDADD = $(top_builddir)/lib/libintel_tools.la $(GLIB_LIBS) > AM_LDFLAGS = -Wl,--as-needed > > > @@ -24,6 +24,7 @@ moduledir = $(libdir) > intel_aubdump_la_LDFLAGS = -module -avoid-version -no-undefined > intel_aubdump_la_SOURCES = aubdump.c > intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la -ldl > +intel_dp_compliance_la_LIBADD = $(LDADD) > > bin_SCRIPTS = intel_aubdump > CLEANFILES = $(bin_SCRIPTS) > diff --git a/tools/Makefile.sources b/tools/Makefile.sources > index be58871..09c0667 100644 > --- a/tools/Makefile.sources > +++ b/tools/Makefile.sources > @@ -13,6 +13,7 @@ tools_prog_lists = \ > intel_bios_reader \ > intel_display_crc \ > intel_display_poller\ > + intel_dp_compliance \ > intel_forcewaked\ > intel_gpu_frequency \ > intel_firmware_decode \ > @@ -55,3 +56,9 @@ intel_l3_parity_SOURCES = \ > intel_l3_parity.h \ > intel_l3_udev_listener.c > > +intel_dp_compliance_SOURCES = \ > +intel_dp_compliance.c \ > +intel_dp_compliance.h \ > +intel_dp_compliance_hotplug.c \ > +$(NULL) > + > diff --git a/tools/intel_dp_compliance.c b/tools/intel_dp_compliance.c > new file mode 100644 > index 000..967d2f8 > --- /dev/null > +++ b/tools/intel_dp_compliance.c > @@ -0,0 +1,1045 @@ > +/* > + * Copyright ? 2014-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. > + * > + * Displayport Compliance Tes
Re: [Intel-gfx] [PATCH] drm/i915: allow GEM_BUG_ON expr checking with !DEBUG_GEM
On Fri, Dec 02, 2016 at 06:47:50PM +, Matthew Auld wrote:
> Use BUILD_BUG_ON_INVALID(expr) in GEM_BUG_ON when building without
> DEBUG_GEM. This means the compiler can now check the validity of expr
> without generating any code, in turn preventing us from inadvertently
> breaking the build when DEBUG_GEM is not enabled.
>
> Cc: Chris Wilson
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index 51ec793f2e20..8801a14a78a2 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -28,7 +28,7 @@
> #ifdef CONFIG_DRM_I915_DEBUG_GEM
> #define GEM_BUG_ON(expr) BUG_ON(expr)
> #else
> -#define GEM_BUG_ON(expr) do { } while (0)
> +#define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
> #endif
Lgtm, compiles both ways and picks up an error when DEBUG_GEM is disabled.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
