Re: [Intel-gfx] [PATCH 1/3] drm/i915: drop encoder hot_plug calls at resume
On Tue, May 20, 2014 at 03:25:33PM -0700, Jesse Barnes wrote:
> We really just want to go detect displays again and fire off a hotplug
> event if things have changed, not go through full hotplug processing.
>
> Requested-by: Daniel Vetter
> Signed-off-by: Jesse Barnes
Yeah, still can't remember why we've done this, and the commit message is
silent.
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 20 +---
> 1 file changed, 1 insertion(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b948c71..302495f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -551,24 +551,6 @@ void intel_console_resume(struct work_struct *work)
> console_unlock();
> }
>
> -static void intel_resume_hotplug(struct drm_device *dev)
> -{
> - struct drm_mode_config *mode_config = &dev->mode_config;
> - struct intel_encoder *encoder;
> -
> - mutex_lock(&mode_config->mutex);
> - DRM_DEBUG_KMS("running encoder hotplug functions\n");
> -
> - list_for_each_entry(encoder, &mode_config->encoder_list, base.head)
> - if (encoder->hot_plug)
> - encoder->hot_plug(encoder);
> -
> - mutex_unlock(&mode_config->mutex);
> -
> - /* Just fire off a uevent and let userspace tell us what to do */
> - drm_helper_hpd_irq_event(dev);
> -}
> -
> static int i915_drm_thaw_early(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -624,7 +606,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
> restore_gtt_mappings)
> intel_hpd_init(dev);
> dev_priv->enable_hotplug_processing = true;
> /* Config may have changed between suspend and resume */
> - intel_resume_hotplug(dev);
> + drm_helper_hpd_irq_event(dev);
> }
>
> intel_opregion_init(dev);
> --
> 1.8.4.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: use async hpd_irq_event function on resume
On Tue, May 20, 2014 at 03:25:35PM -0700, Jesse Barnes wrote: > Gets the detect code (which may take awhile) out of the resume path, > speeding things up a bit. > > Signed-off-by: Jesse Barnes > --- > 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 302495f..571f688 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -606,7 +606,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool > restore_gtt_mappings) > intel_hpd_init(dev); > dev_priv->enable_hotplug_processing = true; > /* Config may have changed between suspend and resume */ > - drm_helper_hpd_irq_event(dev); > + async_schedule(drm_helper_hpd_irq_event_async, dev); Does that really help all that much? I've thought the driver core sychnronizes all the async workers again once resume is done. I'm better to schedule this as a fully async work with e.g. a 1s delay, like we do with the rps resume work. -Daniel > } > > intel_opregion_init(dev); > -- > 1.8.4.2 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] uxa: fix getmsc to not fail hard
On Wed, May 21, 2014 at 12:41:58PM +1000, Dave Airlie wrote: > From: Dave Airlie > > If some outputs go away we race with this call and apps > get X errors and fall over. Do what SNA does and don't > bother trying. Horrible clients is why I gave up trying to report BadMatch for the inactive pipe. Though it has been a long time since the kernel turned off CRTCs without intervention from userspace. This is a useful safeguard, though it angers the OML sync proponents. Pushed, thanks. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm: add async version of hpd_irq_event
On Tue, May 20, 2014 at 03:25:34PM -0700, Jesse Barnes wrote:
> In some cases, the callers of this function may not need the return
> value and delaying the uevent is ok. So add an async version of the
> function for use in those cases.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/drm_probe_helper.c | 8
> include/drm/drm_crtc_helper.h | 2 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 79f07f2..f3aee4a 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -446,3 +446,11 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
> return changed;
> }
> EXPORT_SYMBOL(drm_helper_hpd_irq_event);
> +
Kerneldoc is missing.
-Daniel
> +void drm_helper_hpd_irq_event_async(void *data, async_cookie_t cookie)
> +{
> + struct drm_device *dev = data;
> +
> + drm_helper_hpd_irq_event(dev);
> +}
> +EXPORT_SYMBOL(drm_helper_hpd_irq_event_async);
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index a3d75fe..4f4ed9c 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -33,6 +33,7 @@
> #ifndef __DRM_CRTC_HELPER_H__
> #define __DRM_CRTC_HELPER_H__
>
> +#include
> #include
> #include
> #include
> @@ -172,6 +173,7 @@ extern int
> drm_helper_probe_single_connector_modes_nomerge(struct drm_connector
> extern void drm_kms_helper_poll_init(struct drm_device *dev);
> extern void drm_kms_helper_poll_fini(struct drm_device *dev);
> extern bool drm_helper_hpd_irq_event(struct drm_device *dev);
> +extern void drm_helper_hpd_irq_event_async(void *data, async_cookie_t
> cookie);
> extern void drm_kms_helper_hotplug_event(struct drm_device *dev);
>
> extern void drm_kms_helper_poll_disable(struct drm_device *dev);
> --
> 1.8.4.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/11] i915: split some DP modesetting code into a separate function
From: Dave Airlie
this is just prep work for mst support.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0ad4e96..a5b8b76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -364,6 +364,18 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
DRM_ERROR("FDI link training failed!\n");
}
+void intel_ddi_mode_set_dp(struct intel_encoder *encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+ struct intel_digital_port *intel_dig_port =
+ enc_to_dig_port(&encoder->base);
+
+ intel_dp->DP = intel_dig_port->saved_port_bits |
+ DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
+ intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
+
+}
+
static void intel_ddi_mode_set(struct intel_encoder *encoder)
{
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
@@ -378,13 +390,7 @@ static void intel_ddi_mode_set(struct intel_encoder
*encoder)
crtc->eld_vld = false;
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
- struct intel_digital_port *intel_dig_port =
- enc_to_dig_port(&encoder->base);
-
- intel_dp->DP = intel_dig_port->saved_port_bits |
- DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
- intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
-
+ intel_ddi_mode_set_dp(encoder);
if (intel_dp->has_audio) {
DRM_DEBUG_DRIVER("DP audio on pipe %c on DDI\n",
pipe_name(crtc->pipe));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b885df1..8e41cdc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -683,6 +683,7 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc);
void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config);
+void intel_ddi_mode_set_dp(struct intel_encoder *encoder);
/* intel_display.c */
const char *intel_output_name(int output);
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/11] drm: add a path blob property
From: Dave Airlie
This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 26 ++
include/drm/drm_crtc.h | 5 +
2 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8bf87a6..06b9255 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1165,6 +1165,7 @@ static int
drm_mode_create_standard_connector_properties(struct drm_device *dev)
{
struct drm_property *edid;
struct drm_property *dpms;
+ struct drm_property *dev_path;
/*
* Standard properties (apply to all connectors)
@@ -1179,6 +1180,12 @@ static int
drm_mode_create_standard_connector_properties(struct drm_device *dev)
ARRAY_SIZE(drm_dpms_enum_list));
dev->mode_config.dpms_property = dpms;
+ dev_path = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB |
+ DRM_MODE_PROP_IMMUTABLE,
+ "PATH", 0);
+ dev->mode_config.path_property = dev_path;
+
return 0;
}
@@ -3637,6 +3644,25 @@ done:
return ret;
}
+int drm_mode_connector_set_path_property(struct drm_connector *connector,
+char *path)
+{
+ struct drm_device *dev = connector->dev;
+ int ret, size;
+ size = strlen(path) + 1;
+
+ connector->path_blob_ptr = drm_property_create_blob(connector->dev,
+ size, path);
+ if (!connector->path_blob_ptr)
+ return -EINVAL;
+
+ ret = drm_object_property_set_value(&connector->base,
+ dev->mode_config.path_property,
+ connector->path_blob_ptr->base.id);
+ return ret;
+}
+EXPORT_SYMBOL(drm_mode_connector_set_path_property);
+
/**
* drm_mode_connector_update_edid_property - update the edid property of a
connector
* @connector: drm connector
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 55bc523..e33959b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -500,6 +500,8 @@ struct drm_connector {
struct drm_property_blob *edid_blob_ptr;
struct drm_object_properties properties;
+ struct drm_property_blob *path_blob_ptr;
+
uint8_t polled; /* DRM_CONNECTOR_POLL_* */
/* requested DPMS state */
@@ -774,6 +776,7 @@ struct drm_mode_config {
struct list_head property_blob_list;
struct drm_property *edid_property;
struct drm_property *dpms_property;
+ struct drm_property *path_property;
struct drm_property *plane_type_property;
/* DVI-I properties */
@@ -926,6 +929,8 @@ extern void drm_mode_config_init(struct drm_device *dev);
extern void drm_mode_config_reset(struct drm_device *dev);
extern void drm_mode_config_cleanup(struct drm_device *dev);
+extern int drm_mode_connector_set_path_property(struct drm_connector
*connector,
+ char *path);
extern int drm_mode_connector_update_edid_property(struct drm_connector
*connector,
struct edid *edid);
extern int drm_object_property_set_value(struct drm_mode_object *obj,
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/11] drm/fb_helper: allow adding/removing connectors later
From: Dave Airlie
This is required to get fbcon probing to work on new connectors,
callers should acquire the mode config lock before calling these.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c | 53 +
include/drm/drm_fb_helper.h | 4
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 04d3fd3..a184204 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -105,6 +105,58 @@ fail:
}
EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector)
+{
+ struct drm_fb_helper_connector **temp;
+ struct drm_fb_helper_connector *fb_helper_connector;
+
+ WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
+ if (fb_helper->connector_count + 1 >
fb_helper->connector_info_alloc_count) {
+ temp = krealloc(fb_helper->connector_info, sizeof(struct
drm_fb_helper_connector) * (fb_helper->connector_count + 1), GFP_KERNEL);
+ if (!temp)
+ return -ENOMEM;
+
+ fb_helper->connector_info_alloc_count =
fb_helper->connector_count + 1;
+ fb_helper->connector_info = temp;
+ }
+
+
+ fb_helper_connector = kzalloc(sizeof(struct drm_fb_helper_connector),
GFP_KERNEL);
+ if (!fb_helper_connector)
+ return -ENOMEM;
+
+ fb_helper_connector->connector = connector;
+ fb_helper->connector_info[fb_helper->connector_count++] =
fb_helper_connector;
+ return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
+
+int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
+ struct drm_connector *connector)
+{
+ struct drm_fb_helper_connector *fb_helper_connector;
+ int i, j;
+
+ WARN_ON(!mutex_is_locked(&fb_helper->dev->mode_config.mutex));
+
+ for (i = 0; i < fb_helper->connector_count; i++) {
+ if (fb_helper->connector_info[i]->connector == connector)
+ break;
+ }
+
+ if (i == fb_helper->connector_count)
+ return -EINVAL;
+ fb_helper_connector = fb_helper->connector_info[i];
+
+ for (j = i + 1; j < fb_helper->connector_count; j++) {
+ fb_helper->connector_info[j - 1] = fb_helper->connector_info[j];
+ }
+ fb_helper->connector_count--;
+ kfree(fb_helper_connector);
+ return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
+
static int drm_fb_helper_parse_command_line(struct drm_fb_helper *fb_helper)
{
struct drm_fb_helper_connector *fb_helper_conn;
@@ -534,6 +586,7 @@ int drm_fb_helper_init(struct drm_device *dev,
kfree(fb_helper->crtc_info);
return -ENOMEM;
}
+ fb_helper->connector_info_alloc_count = dev->mode_config.num_connector;
fb_helper->connector_count = 0;
for (i = 0; i < crtc_count; i++) {
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 6e622f7..4abb415 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -86,6 +86,7 @@ struct drm_fb_helper {
int crtc_count;
struct drm_fb_helper_crtc *crtc_info;
int connector_count;
+ int connector_info_alloc_count;
struct drm_fb_helper_connector **connector_info;
struct drm_fb_helper_funcs *funcs;
struct fb_info *fbdev;
@@ -128,4 +129,7 @@ struct drm_display_mode *
drm_pick_cmdline_mode(struct drm_fb_helper_connector *fb_helper_conn,
int width, int height);
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector);
+int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
+ struct drm_connector *connector);
#endif
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] drm/crtc: add interface to reinitialise the legacy mode group
From: Dave Airlie
This can be called to update things after dynamic connectors/encoders
are created/deleted.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm_crtc.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f1753e6..8bf87a6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1421,6 +1421,15 @@ int drm_mode_group_init_legacy_group(struct drm_device
*dev,
}
EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
+void drm_reinit_primary_mode_group(struct drm_device *dev)
+{
+ drm_modeset_lock_all(dev);
+ drm_mode_group_destroy(&dev->primary->mode_group);
+ drm_mode_group_init_legacy_group(dev, &dev->primary->mode_group);
+ drm_modeset_unlock_all(dev);
+}
+EXPORT_SYMBOL(drm_reinit_primary_mode_group);
+
/**
* drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
* @out: drm_mode_modeinfo struct to return to the user
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c6b9e8a..55bc523 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -916,6 +916,7 @@ extern const char *drm_get_tv_select_name(int val);
extern void drm_fb_release(struct drm_file *file_priv);
extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct
drm_mode_group *group);
extern void drm_mode_group_destroy(struct drm_mode_group *group);
+extern void drm_reinit_primary_mode_group(struct drm_device *dev);
extern bool drm_probe_ddc(struct i2c_adapter *adapter);
extern struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] drm/i915: check connector->encoder before using it.
From: Dave Airlie
DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +---
drivers/gpu/drm/i915/i915_irq.c | 4
drivers/gpu/drm/i915/intel_display.c | 25 ++---
3 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae4..88e944f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2279,13 +2279,15 @@ static void intel_connector_info(struct seq_file *m,
seq_printf(m, "\tCEA rev: %d\n",
connector->display_info.cea_rev);
}
- if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
- intel_encoder->type == INTEL_OUTPUT_EDP)
- intel_dp_info(m, intel_connector);
- else if (intel_encoder->type == INTEL_OUTPUT_HDMI)
- intel_hdmi_info(m, intel_connector);
- else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
- intel_lvds_info(m, intel_connector);
+ if (intel_encoder) {
+ if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
+ intel_encoder->type == INTEL_OUTPUT_EDP)
+ intel_dp_info(m, intel_connector);
+ else if (intel_encoder->type == INTEL_OUTPUT_HDMI)
+ intel_hdmi_info(m, intel_connector);
+ else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
+ intel_lvds_info(m, intel_connector);
+ }
seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, &connector->modes, head)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index afa5519..5852dee 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1016,6 +1016,8 @@ static void i915_hotplug_work_func(struct work_struct
*work)
dev_priv->hpd_event_bits = 0;
list_for_each_entry(connector, &mode_config->connector_list, head) {
intel_connector = to_intel_connector(connector);
+ if (!intel_connector->encoder)
+ continue;
intel_encoder = intel_connector->encoder;
if (intel_encoder->hpd_pin > HPD_NONE &&
dev_priv->hpd_stats[intel_encoder->hpd_pin].hpd_mark ==
HPD_MARK_DISABLED &&
@@ -1046,6 +1048,8 @@ static void i915_hotplug_work_func(struct work_struct
*work)
list_for_each_entry(connector, &mode_config->connector_list, head) {
intel_connector = to_intel_connector(connector);
+ if (!intel_connector->encoder)
+ continue;
intel_encoder = intel_connector->encoder;
if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
if (intel_encoder->hot_plug)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b39d036..75b2aaf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4600,20 +4600,23 @@ static void intel_connector_check_state(struct
intel_connector *connector)
"wrong connector dpms state\n");
WARN(connector->base.encoder != &encoder->base,
"active connector not linked to encoder\n");
- WARN(!encoder->connectors_active,
-"encoder->connectors_active not set\n");
- encoder_enabled = encoder->get_hw_state(encoder, &pipe);
- WARN(!encoder_enabled, "encoder not enabled\n");
- if (WARN_ON(!encoder->base.crtc))
- return;
+ if (encoder) {
+ WARN(!encoder->connectors_active,
+"encoder->connectors_active not set\n");
+
+ encoder_enabled = encoder->get_hw_state(encoder, &pipe);
+ WARN(!encoder_enabled, "encoder not enabled\n");
+ if (WARN_ON(!encoder->base.crtc))
+ return;
- crtc = encoder->base.crtc;
+ crtc = encoder->base.crtc;
- WARN(!crtc->enabled, "crtc not enabled\n");
- WARN(!to_intel_crtc(crtc)->active, "crtc not active\n");
- WARN(pipe != to_intel_crtc(crtc)->pipe,
-"encoder active on the wrong pipe\n");
+ WARN(!crtc->enabled, "crtc not enabled\n");
+ WARN(!to_intel_crtc(crtc)->active, "crtc not active\n");
+ WARN(pipe != to_intel_crtc(crtc)->pipe,
+"encoder active on the wrong pipe\n");
+ }
}
}
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lis
[Intel-gfx] [PATCH 11/11] i915: mst topology dumper in debugfs (v0.2)
From: Dave Airlie
use the mst helper code to dump the topology in debugfs.
v0.2: drop is_mst check - as we want to dump other info
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 88e944f..2d455ed 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2378,6 +2378,28 @@ struct pipe_crc_info {
enum pipe pipe;
};
+static int i915_dp_mst_info(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_encoder *encoder;
+ struct intel_encoder *intel_encoder;
+ struct intel_digital_port *intel_dig_port;
+ drm_modeset_lock_all(dev);
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ intel_encoder = to_intel_encoder(encoder);
+ if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
+ continue;
+ intel_dig_port = enc_to_dig_port(encoder);
+ if (!intel_dig_port->dp.can_mst)
+ continue;
+
+ drm_dp_mst_dump_topology(m, &intel_dig_port->dp.mst_mgr);
+ }
+ drm_modeset_unlock_all(dev);
+ return 0;
+}
+
static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
{
struct pipe_crc_info *info = inode->i_private;
@@ -3813,6 +3835,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_pc8_status", i915_pc8_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
{"i915_display_info", i915_display_info, 0},
+ {"i915_dp_mst_info", i915_dp_mst_info, 0},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/11] drm/i915: add some registers need for displayport MST support.
From: Dave Airlie
These are just from the Haswell spec.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..557b37a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5386,6 +5386,7 @@ enum punit_power_well {
#define TRANS_DDI_EDP_INPUT_A_ONOFF (4<<12)
#define TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
#define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
+#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
#define TRANS_DDI_BFI_ENABLE (1<<4)
/* DisplayPort Transport Control */
@@ -5395,6 +5396,7 @@ enum punit_power_well {
#define DP_TP_CTL_ENABLE (1<<31)
#define DP_TP_CTL_MODE_SST(0<<27)
#define DP_TP_CTL_MODE_MST(1<<27)
+#define DP_TP_CTL_FORCE_ACT (1<<25)
#define DP_TP_CTL_ENHANCED_FRAME_ENABLE (1<<18)
#define DP_TP_CTL_FDI_AUTOTRAIN (1<<15)
#define DP_TP_CTL_LINK_TRAIN_MASK (7<<8)
@@ -5409,8 +5411,13 @@ enum punit_power_well {
#define DP_TP_STATUS_A 0x64044
#define DP_TP_STATUS_B 0x64144
#define DP_TP_STATUS(port) _PORT(port, DP_TP_STATUS_A, DP_TP_STATUS_B)
-#define DP_TP_STATUS_IDLE_DONE(1<<25)
-#define DP_TP_STATUS_AUTOTRAIN_DONE (1<<12)
+#define DP_TP_STATUS_IDLE_DONE(1<<25)
+#define DP_TP_STATUS_ACT_SENT (1<<24)
+#define DP_TP_STATUS_MODE_STATUS_MST (1<<23)
+#define DP_TP_STATUS_AUTOTRAIN_DONE (1<<12)
+#define DP_TP_STATUS_PAYLOAD_MAPPING_VC2 (3 << 8)
+#define DP_TP_STATUS_PAYLOAD_MAPPING_VC1 (3 << 4)
+#define DP_TP_STATUS_PAYLOAD_MAPPING_VC0 (3 << 0)
/* DDI Buffer Control */
#define DDI_BUF_CTL_A 0x64000
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/dp_helper: add defines for DP 1.2 and MST support.
From: Dave Airlie This just adds the defines from the DP 1.2 spec, which we will use later. Signed-off-by: Dave Airlie --- include/drm/drm_dp_helper.h | 78 + 1 file changed, 78 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index cfcacec..879836d 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -37,6 +37,7 @@ * eDP: Embedded DisplayPort version 1 * DPI: DisplayPort Interoperability Guideline v1.1a * 1.2: DisplayPort 1.2 + * MST: Multistream Transport - part of DP 1.2a * * 1.2 formally includes both eDP and DPI definitions. */ @@ -103,9 +104,14 @@ #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ /* Multiple stream transport */ +#define DP_FAUX_CAP0x020 /* 1.2 */ +# define DP_FAUX_CAP_1 (1 << 0) + #define DP_MSTM_CAP0x021 /* 1.2 */ # define DP_MST_CAP(1 << 0) +#define DP_GUID0x030 /* 1.2 */ + #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ # define DP_PSR_IS_SUPPORTED1 #define DP_PSR_CAPS 0x071 /* XXX 1.2? */ @@ -221,6 +227,16 @@ # define DP_PSR_CRC_VERIFICATION (1 << 2) # define DP_PSR_FRAME_CAPTURE (1 << 3) +#define DP_ADAPTER_CTRL0x1a0 +# define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) + +#define DP_BRANCH_DEVICE_CTRL 0x1a1 +# define DP_BRANCH_DEVICE_IRQ_HPD (1 << 0) + +#define DP_PAYLOAD_ALLOCATE_SET0x1c0 +#define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 +#define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2 + #define DP_SINK_COUNT 0x200 /* prior to 1.2 bit 7 was reserved mbz */ # define DP_GET_SINK_COUNT(x) x) & 0x80) >> 1) | ((x) & 0x3f)) @@ -230,6 +246,9 @@ # define DP_REMOTE_CONTROL_COMMAND_PENDING (1 << 0) # define DP_AUTOMATED_TEST_REQUEST (1 << 1) # define DP_CP_IRQ (1 << 2) +# define DP_MCCS_IRQ (1 << 3) +# define DP_DOWN_REP_MSG_RDY (1 << 4) /* DP MST */ +# define DP_UP_REQ_MSG_RDY (1 << 5) /* DP MST */ # define DP_SINK_SPECIFIC_IRQ (1 << 6) #define DP_LANE0_1_STATUS 0x202 @@ -294,6 +313,13 @@ #define DP_TEST_SINK 0x270 #define DP_TEST_SINK_START (1 << 0) +#define DP_PAYLOAD_TABLE_UPDATE_STATUS 0x2c0 /* 1.2 MST */ +# define DP_PAYLOAD_TABLE_UPDATED (1 << 0) +# define DP_PAYLOAD_ACT_HANDLED (1 << 1) + +#define DP_VC_PAYLOAD_ID_SLOT_1 0x2c1 /* 1.2 MST */ +/* up to ID_SLOT_63 at 0x2ff */ + #define DP_SOURCE_OUI 0x300 #define DP_SINK_OUI0x400 #define DP_BRANCH_OUI 0x500 @@ -303,6 +329,21 @@ # define DP_SET_POWER_D30x2 # define DP_SET_POWER_MASK 0x3 +#define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ +#define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ +#define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ +#define DP_SIDEBAND_MSG_UP_REQ_BASE0x1600 /* 1.2 MST */ + +#define DP_SINK_COUNT_ESI 0x2002 /* 1.2 */ +/* 0-5 sink count */ +# define DP_SINK_COUNT_CP_READY (1 << 6) + +#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */ + +#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */ + +#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */ + #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ # define DP_PSR_LINK_CRC_ERROR (1 << 0) # define DP_PSR_RFB_STORAGE_ERROR (1 << 1) @@ -319,6 +360,43 @@ # define DP_PSR_SINK_INTERNAL_ERROR 7 # define DP_PSR_SINK_STATE_MASK 0x07 +/* DP 1.2 Sideband message defines */ +/* peer device type - DP 1.2a Table 2-92 */ +#define DP_PEER_DEVICE_NONE0x0 +#define DP_PEER_DEVICE_SOURCE_OR_SST 0x1 +#define DP_PEER_DEVICE_MST_BRANCHING 0x2 +#define DP_PEER_DEVICE_SST_SINK0x3 +#define DP_PEER_DEVICE_DP_LEGACY_CONV 0x4 + +/* DP 1.2 MST sideband request names DP 1.2a Table 2-80 */ +#define DP_LINK_ADDRESS0x01 +#define DP_CONNECTION_STATUS_NOTIFY0x02 +#define DP_ENUM_PATH_RESOURCES 0x10 +#define DP_ALLOCATE_PAYLOAD0x11 +#define DP_QUERY_PAYLOAD 0x12 +#define DP_RESOURCE_STATUS_NOTIFY 0x13 +#define DP_CLEAR_PAYLOAD_ID_TABLE 0x14 +#define DP_REMOTE_DPCD_READ0x20 +#define DP_REMOTE_DPCD_WRITE 0x21 +#define DP_REMOTE_I2C_READ 0x22 +#define DP_REMOTE_I2C_WRITE0x23 +#define DP_POWER_UP_PHY0x24 +#define DP_POWER_DOWN_PHY 0x25 +#define DP_SINK_EVENT
[Intel-gfx] [RFC] DisplayPort MST support
Hey, So this set is pretty close to what I think we should be merging initially, Since the last set, it makes fbcon and suspend/resume work a lot better, I've also fixed a couple of bugs in -intel that make things work a lot better. I've bashed on this a bit using kms-flip from intel-gpu-tools, hacked to add 3 monitor support. It still generates a fair few i915 state checker backtraces, and some of them are fairly hard to work out, it might be we should just tone down the state checker for encoders/connectors with no actual hw backing them. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] drm: add DP MST encoder type
From: Dave Airlie
This adds an encoder type for DP MST encoders.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a3fe324..f1753e6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -227,6 +227,7 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
{ DRM_MODE_ENCODER_DSI, "DSI" },
+ { DRM_MODE_ENCODER_DPMST, "DP MST" },
};
static const struct drm_prop_enum_list drm_subpixel_enum_list[] =
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index f104c26..719add4 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -181,6 +181,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_TVDAC 4
#define DRM_MODE_ENCODER_VIRTUAL 5
#define DRM_MODE_ENCODER_DSI 6
+#define DRM_MODE_ENCODER_DPMST 7
struct drm_mode_get_encoder {
__u32 encoder_id;
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] uxa: fix getmsc to not fail hard
From: Dave Airlie
If some outputs go away we race with this call and apps
get X errors and fall over. Do what SNA does and don't
bother trying.
Signed-off-by: Dave Airlie
---
src/uxa/intel_dri.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/uxa/intel_dri.c b/src/uxa/intel_dri.c
index 0370034..5d1262a 100644
--- a/src/uxa/intel_dri.c
+++ b/src/uxa/intel_dri.c
@@ -1351,6 +1351,7 @@ I830DRI2GetMSC(DrawablePtr draw, CARD64 *ust, CARD64 *msc)
/* Drawable not displayed, make up a *monotonic* value */
if (pipe == -1) {
+fail:
*ust = gettime_us();
*msc = 0;
return TRUE;
@@ -1369,7 +1370,7 @@ I830DRI2GetMSC(DrawablePtr draw, CARD64 *ust, CARD64 *msc)
strerror(errno));
limit--;
}
- return FALSE;
+ goto fail;
}
*ust = ((CARD64)vbl.reply.tval_sec * 100) + vbl.reply.tval_usec;
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Wait for pending page flips before enabling/disabling the primary plane
It seems it needs a rebase...
I couldn't figure out where exactly you will put the wait_for_pending so
I'm going to wait a v2.
But this is my fault that took a century to review it... I'm sorry...
On Tue, Apr 15, 2014 at 11:41 AM, wrote:
> From: Ville Syrjälä
>
> We have to write to the primary plane base address registrer when we
> enable/disable the primary plane in response to sprite coverage. Those
> writes will cause the flip counter to increment which could interfere
> with the detection of CS flip completion. We could end up completing
> CS flips before the CS has even executed the commands from the ring.
>
> To avoid such issues, wait for CS flips to finish before we toggle the
> primary plane on/off.
>
> Testcase: igt/kms_mmio_vs_cs_flip/setplane_vs_cs_flip
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_sprite.c | 4
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9b181fc..c0fe5dd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3096,7 +3096,7 @@ bool intel_has_pending_fb_unpin(struct drm_device
> *dev)
> return false;
> }
>
> -static void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
> +void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index edef34e..f578e42 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -775,6 +775,7 @@ int valleyview_get_vco(struct drm_i915_private
> *dev_priv);
> void intel_mode_from_pipe_config(struct drm_display_mode *mode,
> struct intel_crtc_config *pipe_config);
> int intel_format_to_fourcc(int format);
> +void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc);
>
> /* intel_dp.c */
> void intel_dp_init(struct drm_device *dev, int output_reg, enum port
> port);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 4df7245..36a8f5e 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -529,6 +529,8 @@ intel_enable_primary(struct drm_crtc *crtc)
> if (intel_crtc->primary_enabled)
> return;
>
> + intel_crtc_wait_for_pending_flips(crtc);
> +
> intel_crtc->primary_enabled = true;
>
> I915_WRITE(reg, I915_READ(reg) | DISPLAY_PLANE_ENABLE);
> @@ -558,6 +560,8 @@ intel_disable_primary(struct drm_crtc *crtc)
> if (!intel_crtc->primary_enabled)
> return;
>
> + intel_crtc_wait_for_pending_flips(crtc);
> +
> intel_crtc->primary_enabled = false;
>
> mutex_lock(&dev->struct_mutex);
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Drop the excessive vblank waits from modeset codepaths
Reviewed-by: Rodrigo Vivi On Fri, Apr 25, 2014 at 3:30 AM, wrote: > From: Ville Syrjälä > > Now that we've plugged the mmio vs. ring flip race, we shouldn't need > these vblank waits in the modeset codepaths anymore. So get rid of > them. > > v2: gen2 needs to wait for planes to turn off before disabling pipe > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 19 +++ > 1 file changed, 7 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 33d21bf..17258fe5 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1901,7 +1901,6 @@ static void intel_enable_primary_hw_plane(struct > drm_i915_private *dev_priv, > > I915_WRITE(reg, val | DISPLAY_PLANE_ENABLE); > intel_flush_primary_plane(dev_priv, plane); > - intel_wait_for_vblank(dev_priv->dev, pipe); > } > > /** > @@ -1931,7 +1930,6 @@ static void intel_disable_primary_hw_plane(struct > drm_i915_private *dev_priv, > > I915_WRITE(reg, val & ~DISPLAY_PLANE_ENABLE); > intel_flush_primary_plane(dev_priv, plane); > - intel_wait_for_vblank(dev_priv->dev, pipe); > } > > static bool need_vtd_wa(struct drm_device *dev) > @@ -3706,16 +3704,6 @@ static void ironlake_crtc_enable(struct drm_crtc > *crtc) > if (HAS_PCH_CPT(dev)) > cpt_verify_modeset(dev, intel_crtc->pipe); > > - /* > -* There seems to be a race in PCH platform hw (at least on some > -* outputs) where an enabled pipe still completes any pageflip > right > -* away (as if the pipe is off) instead of waiting for vblank. As > soon > -* as the first vblank happend, everything works as expected. > Hence just > -* wait for one vblank before returning to avoid strange things > -* happening. > -*/ > - intel_wait_for_vblank(dev, intel_crtc->pipe); > - > drm_vblank_on(dev, pipe); > } > > @@ -4475,6 +4463,13 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) > intel_disable_planes(crtc); > intel_disable_primary_hw_plane(dev_priv, plane, pipe); > > + /* > +* On gen2 planes are double buffered but the pipe isn't, so we > must > +* wait for planes to fully turn off before disabling the pipe. > +*/ > + if (IS_GEN2(dev)) > + intel_wait_for_vblank(dev, pipe); > + > intel_set_cpu_fifo_underrun_reporting(dev, pipe, false); > intel_disable_pipe(dev_priv, pipe); > > -- > 1.8.3.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Wait for vblank in hsw_enable_ips()
Reviewed-by: Rodrigo Vivi
On Tue, Apr 15, 2014 at 11:41 AM, wrote:
> From: Ville Syrjälä
>
> Now that the vblank wait is gone from intel_enable_primary_plane(),
> hsw_enable_ips() needs to do the vblank wait itself.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 12 ++--
> drivers/gpu/drm/i915/intel_sprite.c | 5 +
> 2 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 32c6c16..33d21bf 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3543,17 +3543,17 @@ static void intel_disable_planes(struct drm_crtc
> *crtc)
>
> void hsw_enable_ips(struct intel_crtc *crtc)
> {
> - struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>
> if (!crtc->config.ips_enabled)
> return;
>
> - /* We can only enable IPS after we enable a plane and wait for a
> vblank.
> -* We guarantee that the plane is enabled by calling
> intel_enable_ips
> -* only after intel_enable_plane. And intel_enable_plane already
> waits
> -* for a vblank, so all we need to do here is to enable the IPS
> bit. */
> + /* We can only enable IPS after we enable a plane and wait for a
> vblank */
> + intel_wait_for_vblank(dev, crtc->pipe);
> +
> assert_plane_enabled(dev_priv, crtc->plane);
> - if (IS_BROADWELL(crtc->base.dev)) {
> + if (IS_BROADWELL(dev)) {
> mutex_lock(&dev_priv->rps.hw_lock);
> WARN_ON(sandybridge_pcode_write(dev_priv,
> DISPLAY_IPS_CONTROL, 0xc000));
> mutex_unlock(&dev_priv->rps.hw_lock);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 336ae6c..4df7245 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -540,10 +540,7 @@ intel_enable_primary(struct drm_crtc *crtc)
> * when going from primary only to sprite only and vice
> * versa.
> */
> - if (intel_crtc->config.ips_enabled) {
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> - hsw_enable_ips(intel_crtc);
> - }
> + hsw_enable_ips(intel_crtc);
>
> mutex_lock(&dev->struct_mutex);
> intel_update_fbc(dev);
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915: Fix mmio vs. CS flip race on ILK+
needs a small rebase but everything looks good for me so
Reviewed-by: Rodrigo Vivi
On Tue, Apr 15, 2014 at 11:41 AM, wrote:
> From: Ville Syrjälä
>
> Starting from ILK, mmio flips also cause a flip done interrupt to be
> signalled. This means if we first do a set_base and follow it
> immediately with the CS flip, we might mistake the flip done interrupt
> caused by the set_base as the flip done interrupt caused by the CS
> flip.
>
> The hardware has a flip counter which increments every time a mmio or
> CS flip is issued. It basically counts the number of DSPSURF register
> writes. This means we can sample the counter before we put the CS
> flip into the ring, and then when we get a flip done interrupt we can
> check whether the CS flip has actually performed the surface address
> update, or if the interrupt was caused by a previous but yet
> unfinished mmio flip.
>
> Even with the flip counter we still have a race condition of the CS flip
> base address update happens after the mmio flip done interrupt was
> raised but not yet processed by the driver. When the interrupt is
> eventually processed, the flip counter will already indicate that the
> CS flip has been executed, but it would not actually complete until the
> next start of vblank. We can use the DSPSURFLIVE register to check
> whether the hardware is actually scanning out of the buffer we expect,
> or if we managed hit this race window.
>
> This covers all the cases where the CS flip actually changes the base
> address. If the base address remains unchanged, we might still complete
> the CS flip before it has actually completed. But since the address
> didn't change anyway, the premature flip completion can't result in
> userspace overwriting data that's still being scanned out.
>
> CTG already has the flip counter and DSPSURFLIVE registers, and
> although the flip done interrupt is still limited to CS flips alone,
> the code now also checks the flip counter on CTG as well.
>
> v2: s/dspsurf/gtt_offset/ (Chris)
>
> Testcase: igt/kms_mmio_vs_cs_flip/setcrtc_vs_cs_flip
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73027
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 73
>
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> 3 files changed, 69 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 8f84555..c28169c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3638,6 +3638,7 @@ enum punit_power_well {
> #define _PIPEA_FRMCOUNT_GM45 0x70040
> #define _PIPEA_FLIPCOUNT_GM45 0x70044
> #define PIPE_FRMCOUNT_GM45(pipe) _PIPE2(pipe, _PIPEA_FRMCOUNT_GM45)
> +#define PIPE_FLIPCOUNT_GM45(pipe) _PIPE2(pipe, _PIPEA_FLIPCOUNT_GM45)
>
> /* Cursor A & B regs */
> #define _CURACNTR (dev_priv->info.display_mmio_offset +
> 0x70080)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 1390ab5..32c6c16 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8577,6 +8577,48 @@ void intel_finish_page_flip_plane(struct drm_device
> *dev, int plane)
> do_intel_finish_page_flip(dev, crtc);
> }
>
> +/* Is 'a' after or equal to 'b'? */
> +static bool flip_count_after_eq(u32 a, u32 b)
> +{
> + return !((a - b) & 0x8000);
> +}
> +
> +static bool page_flip_finished(struct intel_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + /*
> +* The relevant registers doen't exist on pre-ctg.
> +* As the flip done interrupt doesn't trigger for mmio
> +* flips on gmch platforms, a flip count check isn't
> +* really needed there. But since ctg has the registers,
> +* include it in the check anyway.
> +*/
> + if (INTEL_INFO(dev)->gen < 5 && !IS_G4X(dev))
> + return true;
> +
> + /*
> +* A DSPSURFLIVE check isn't enough in case the mmio and CS flips
> +* used the same base address. In that case the mmio flip might
> +* have completed, but the CS hasn't even executed the flip yet.
> +*
> +* A flip count check isn't enough as the CS might have updated
> +* the base address just after start of vblank, but before we
> +* managed to process the interrupt. This means we'd complete the
> +* CS flip too soon.
> +*
> +* Combining both checks should get us a good enough result. It may
> +* still happen that the CS flip has been executed, but has not
> +* yet actually completed. But in case the base address is the same
> +* anyway, we don't really care.
> +*/
> + return (I915_READ(DSPSURFLIVE(crtc->plane)) & ~0xfff) ==
> + crtc->unpin_
[Intel-gfx] [PATCH 2/3] drm: add async version of hpd_irq_event
In some cases, the callers of this function may not need the return
value and delaying the uevent is ok. So add an async version of the
function for use in those cases.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_probe_helper.c | 8
include/drm/drm_crtc_helper.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 79f07f2..f3aee4a 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -446,3 +446,11 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
return changed;
}
EXPORT_SYMBOL(drm_helper_hpd_irq_event);
+
+void drm_helper_hpd_irq_event_async(void *data, async_cookie_t cookie)
+{
+ struct drm_device *dev = data;
+
+ drm_helper_hpd_irq_event(dev);
+}
+EXPORT_SYMBOL(drm_helper_hpd_irq_event_async);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index a3d75fe..4f4ed9c 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -33,6 +33,7 @@
#ifndef __DRM_CRTC_HELPER_H__
#define __DRM_CRTC_HELPER_H__
+#include
#include
#include
#include
@@ -172,6 +173,7 @@ extern int
drm_helper_probe_single_connector_modes_nomerge(struct drm_connector
extern void drm_kms_helper_poll_init(struct drm_device *dev);
extern void drm_kms_helper_poll_fini(struct drm_device *dev);
extern bool drm_helper_hpd_irq_event(struct drm_device *dev);
+extern void drm_helper_hpd_irq_event_async(void *data, async_cookie_t cookie);
extern void drm_kms_helper_hotplug_event(struct drm_device *dev);
extern void drm_kms_helper_poll_disable(struct drm_device *dev);
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: use async hpd_irq_event function on resume
Gets the detect code (which may take awhile) out of the resume path, speeding things up a bit. Signed-off-by: Jesse Barnes --- 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 302495f..571f688 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -606,7 +606,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool restore_gtt_mappings) intel_hpd_init(dev); dev_priv->enable_hotplug_processing = true; /* Config may have changed between suspend and resume */ - drm_helper_hpd_irq_event(dev); + async_schedule(drm_helper_hpd_irq_event_async, dev); } intel_opregion_init(dev); -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: drop encoder hot_plug calls at resume
We really just want to go detect displays again and fire off a hotplug
event if things have changed, not go through full hotplug processing.
Requested-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b948c71..302495f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -551,24 +551,6 @@ void intel_console_resume(struct work_struct *work)
console_unlock();
}
-static void intel_resume_hotplug(struct drm_device *dev)
-{
- struct drm_mode_config *mode_config = &dev->mode_config;
- struct intel_encoder *encoder;
-
- mutex_lock(&mode_config->mutex);
- DRM_DEBUG_KMS("running encoder hotplug functions\n");
-
- list_for_each_entry(encoder, &mode_config->encoder_list, base.head)
- if (encoder->hot_plug)
- encoder->hot_plug(encoder);
-
- mutex_unlock(&mode_config->mutex);
-
- /* Just fire off a uevent and let userspace tell us what to do */
- drm_helper_hpd_irq_event(dev);
-}
-
static int i915_drm_thaw_early(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -624,7 +606,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
intel_hpd_init(dev);
dev_priv->enable_hotplug_processing = true;
/* Config may have changed between suspend and resume */
- intel_resume_hotplug(dev);
+ drm_helper_hpd_irq_event(dev);
}
intel_opregion_init(dev);
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Tue, 20 May 2014 14:18:07 -0700
Jesse Barnes wrote:
> On Tue, 20 May 2014 14:10:16 -0700
> Jesse Barnes wrote:
>
> > On Tue, 20 May 2014 22:15:45 +0200
> > Daniel Vetter wrote:
> >
> > > On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> > > wrote:
> > > > Ah, poll_enable is false until after _thaw finishes, so
> > > > our hotplug_resume call of hpd_irq_event does nothing. So aside from
> > > > the encoder hot_plug callbacks (which really just check dp link status,
> > > > which ought to be a no-op) our resume_hotplug function doesn't do
> > > > anything right now. May as well kill it and just send an unconditional
> > > > uevent?
> > >
> > > That's expensive since the reprobe will likely result in a few dropped
> > > frames (if the edid reading takes a long time). Better to do that in
> > > the kernel and avoid sending the uevent if nothing changed. Which iirc
> > > hpd_irq_event does for us.
> >
> > Well delaying the resume by a long time isn't much better, but I guess
> > we need to fix this somehow.
> >
> > Knut, does this patch also address your issue? It should reset the
> > connector status fields correctly so the X driver doesn't have to work
> > around things...
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index b948c71..e725235 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -623,8 +623,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
> > restore_gtt_mappings)
> > * */
> > intel_hpd_init(dev);
> > dev_priv->enable_hotplug_processing = true;
> > - /* Config may have changed between suspend and resume */
> > - intel_resume_hotplug(dev);
> > }
> >
> > intel_opregion_init(dev);
> > @@ -694,6 +692,11 @@ int i915_resume(struct drm_device *dev)
> > return ret;
> >
> > drm_kms_helper_poll_enable(dev);
> > + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > + /* Config may have changed between suspend and resume */
> > + intel_resume_hotplug(dev);
> > + }
> > +
> > return 0;
> > }
> >
>
> Bah nevermind, this won't do anything. I was thinking that poll_enable
> controlled the poll_enabled field, but it doesn't, it just schedules or
> cancels the work for it.
>
> So we're still left wondering why the connector status fields are
> incorrect on resume in this case...
And on top of that I can't reproduce your issue here on my BYT which
shares many of these code paths. It could be something i915 specific
where we're not doing teardown correctly...
Knut, can you run testdisplay -i from intel-gpu-tools after you kill
the X server following the resume? It shows connected for me both on
eDP and HDMI as expected.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Tue, 20 May 2014 14:10:16 -0700
Jesse Barnes wrote:
> On Tue, 20 May 2014 22:15:45 +0200
> Daniel Vetter wrote:
>
> > On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> > wrote:
> > > Ah, poll_enable is false until after _thaw finishes, so
> > > our hotplug_resume call of hpd_irq_event does nothing. So aside from
> > > the encoder hot_plug callbacks (which really just check dp link status,
> > > which ought to be a no-op) our resume_hotplug function doesn't do
> > > anything right now. May as well kill it and just send an unconditional
> > > uevent?
> >
> > That's expensive since the reprobe will likely result in a few dropped
> > frames (if the edid reading takes a long time). Better to do that in
> > the kernel and avoid sending the uevent if nothing changed. Which iirc
> > hpd_irq_event does for us.
>
> Well delaying the resume by a long time isn't much better, but I guess
> we need to fix this somehow.
>
> Knut, does this patch also address your issue? It should reset the
> connector status fields correctly so the X driver doesn't have to work
> around things...
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b948c71..e725235 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -623,8 +623,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
> restore_gtt_mappings)
>* */
> intel_hpd_init(dev);
> dev_priv->enable_hotplug_processing = true;
> - /* Config may have changed between suspend and resume */
> - intel_resume_hotplug(dev);
> }
>
> intel_opregion_init(dev);
> @@ -694,6 +692,11 @@ int i915_resume(struct drm_device *dev)
> return ret;
>
> drm_kms_helper_poll_enable(dev);
> + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> + /* Config may have changed between suspend and resume */
> + intel_resume_hotplug(dev);
> + }
> +
> return 0;
> }
>
Bah nevermind, this won't do anything. I was thinking that poll_enable
controlled the poll_enabled field, but it doesn't, it just schedules or
cancels the work for it.
So we're still left wondering why the connector status fields are
incorrect on resume in this case...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Tue, 20 May 2014 22:15:45 +0200
Daniel Vetter wrote:
> On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes
> wrote:
> > Ah, poll_enable is false until after _thaw finishes, so
> > our hotplug_resume call of hpd_irq_event does nothing. So aside from
> > the encoder hot_plug callbacks (which really just check dp link status,
> > which ought to be a no-op) our resume_hotplug function doesn't do
> > anything right now. May as well kill it and just send an unconditional
> > uevent?
>
> That's expensive since the reprobe will likely result in a few dropped
> frames (if the edid reading takes a long time). Better to do that in
> the kernel and avoid sending the uevent if nothing changed. Which iirc
> hpd_irq_event does for us.
Well delaying the resume by a long time isn't much better, but I guess
we need to fix this somehow.
Knut, does this patch also address your issue? It should reset the
connector status fields correctly so the X driver doesn't have to work
around things...
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b948c71..e725235 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -623,8 +623,6 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
* */
intel_hpd_init(dev);
dev_priv->enable_hotplug_processing = true;
- /* Config may have changed between suspend and resume */
- intel_resume_hotplug(dev);
}
intel_opregion_init(dev);
@@ -694,6 +692,11 @@ int i915_resume(struct drm_device *dev)
return ret;
drm_kms_helper_poll_enable(dev);
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ /* Config may have changed between suspend and resume */
+ intel_resume_hotplug(dev);
+ }
+
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Add support for Generic MIPI panel driver
On Tue, May 20, 2014 at 09:46:01PM +0530, Shobhit Kumar wrote: > >- UI is a period, so is homogeneous to time (s), but ui_num being in > > s^-1 and ui_den a constant, ui_num/ui_den looks like a frequency. Or > > could it be that UI = ui_den / ui_num? would be confusing, but the > > code below would make more sense. In which case could we have UI = > > ui_num / ui_den? > > I just kept ui_num and ui_den separately to take care of precision > loss, but I see how it is adding to confusion. Actually it is ui_den > / ui_num and we have all computations as 1/UI so it works. I think I > will compute UI directly as UI = (NS_KHZ_RATIO * 1000) /bitrate and > divide by 1000 wherever we use to maintain precision. Sounds ok ? I think just exchanging the two variable names (ui_num and ui_den) should be less work for you and should be enough. It's really just about having ui_num being the UI numerator so the reader is not too surprised > >>+ /* B044 */ > >>+ intel_dsi->hs_to_lp_count = > >>+ CEIL_DIV( > >>+ 4 * tlpx_ui + prepare_cnt * 2 + > >>+ exit_zero_cnt * 2 + 10, > >>+ 8); > > > >The previous was before I tried to look at the spec too closely. Mind > >explaining why we don't look at the HS to LP switch count? ie why HS to > >LP switch cound is always smaller than the LP to HS one? > > Because LP to HS uses exit_zero_count which is generally higher than > clk_zero_count. So just directly used LP to HS which amounts to > saying that switching from HS to LP takes lesser time than switching > from LP to HS. I can/should add code to compute max of the two. This could go to a separate task if you don't have time right now, Thanks for your answers! -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Drop now misleading DDI comment from dp_link_down
Since commit 2e82a7203182d0883d0f9450d40ad6e1c6578ad9 Author: Imre Deak Date: Fri Jan 17 15:46:43 2014 +0200 drm/i915: don't disable DP port after a failed link training and commit 5d6a1116c6475404e6505b708320f9579ae19acd Author: Imre Deak Date: Thu Jan 16 18:35:57 2014 +0200 drm/i915: don't disable the DP port if the link is lost we no longer call intel_dp_link_down from generic DP code, but only from the !HAS_DDI dp encoder functions. hsw/bdw have their own encoder disabling callback in intel_ddi.c. Hence the early return is no longer needed and the big comment just confusing, so let's rip it out. To ensure what we don't accidentally use this again on ddi encoders add a WARN_ON instead. Spotted while reading through intel_dp.c Cc: Imre Deak Cc: Paulo Zanoni Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_dp.c | 17 + 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 34ed143ab479..fbea236c8ade 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -2751,22 +2751,7 @@ intel_dp_link_down(struct intel_dp *intel_dp) to_intel_crtc(intel_dig_port->base.base.crtc); uint32_t DP = intel_dp->DP; - /* -* DDI code has a strict mode set sequence and we should try to respect -* it, otherwise we might hang the machine in many different ways. So we -* really should be disabling the port only on a complete crtc_disable -* sequence. This function is just called under two conditions on DDI -* code: -* - Link train failed while doing crtc_enable, and on this case we -* really should respect the mode set sequence and wait for a -* crtc_disable. -* - Someone turned the monitor off and intel_dp_check_link_status -* called us. We don't need to disable the whole port on this case, so -* when someone turns the monitor on again, -* intel_ddi_prepare_link_retrain will take care of redoing the link -* train. -*/ - if (HAS_DDI(dev)) + if (WARN_ON(HAS_DDI(dev))) return; if (WARN_ON((I915_READ(intel_dp->output_reg) & DP_PORT_EN) == 0)) -- 1.9.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Tue, May 20, 2014 at 9:58 PM, Jesse Barnes wrote: > Ah, poll_enable is false until after _thaw finishes, so > our hotplug_resume call of hpd_irq_event does nothing. So aside from > the encoder hot_plug callbacks (which really just check dp link status, > which ought to be a no-op) our resume_hotplug function doesn't do > anything right now. May as well kill it and just send an unconditional > uevent? That's expensive since the reprobe will likely result in a few dropped frames (if the edid reading takes a long time). Better to do that in the kernel and avoid sending the uevent if nothing changed. Which iirc hpd_irq_event does for us. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Tue, 20 May 2014 12:53:29 -0700 Jesse Barnes wrote: > On Fri, 16 May 2014 23:42:23 +0100 > Chris Wilson wrote: > > > On Fri, May 16, 2014 at 11:38:07PM +0100, Chris Wilson wrote: > > > On Fri, May 16, 2014 at 03:20:47PM -0700, Jesse Barnes wrote: > > > > On Mon, 21 Apr 2014 18:37:31 +0200 > > > > Knut Petersen wrote: > > > > > > + /* This driver doesn't need a VT switch to restore the mode on > > > > > > resume */ > > > > > > + info->skip_vt_switch = true; > > > > > > + > > > > > > drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth); > > > > > > drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, > > > > > > sizes->fb_height); > > > > > > > > Is it sufficient to just revert this part? Or are the other bits > > > > needed too? > > > > > > > > Sorry for the delay on this, I've been traveling a lot the past month > > > > and buried in other stuff so out of touch with much of my email. > > > > > > The key step here is that X is restarted after resume. The slow down was > > > due to X not finding any connected outputs and so disabling them all, > > > setting up a dummy 1024x768 fb which really confused KDE. (KDE queries > > > the config causing a forced reprobe of all outputs, setups the display > > > for the native 1280x1024, but screws up KDE's own bookkeeping.) > > > > > > The impact has been fixed by handling the connector->status more > > > robusting during initial output probing in X. What remains is the > > > question whether connector->status can be set appropriately upon resume? > > > It requires a detection cycle to be sure that the outputs are still > > > there, which is arguably better deferred to userspace. To be consistent > > > the BIOS take over code should mark connector->status as unknown for the > > > CRTCs it takes over without doing a detection cycle (where we just > > > presume that the CRTC/output being enabled means something is on the > > > other end of the pipe and is still valid). > > > > Hmm. Why didn't fbcon respond to the hotplug event on resume and perform > > a detection cycle before Knut was able to type startx on the console? > > That I think is the bug. > > Well, fbcon resume is delayed, but we do perform an fb re-probe via > intel_resume_hotplug() that should have done this. Not sure why that's > sufficient... but I agree userspace should probably re-probe on > resume. We're supposed to generate a uevent on resume, but the fb > layer may suppress that if it detects that no change has occurred. > > Maybe X is racing with our resume_hotplug somehow? It doesn't look > like that should happen... Ah, poll_enable is false until after _thaw finishes, so our hotplug_resume call of hpd_irq_event does nothing. So aside from the encoder hot_plug callbacks (which really just check dp link status, which ought to be a no-op) our resume_hotplug function doesn't do anything right now. May as well kill it and just send an unconditional uevent? -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: enable VT switchless resume v3
On Fri, 16 May 2014 23:42:23 +0100 Chris Wilson wrote: > On Fri, May 16, 2014 at 11:38:07PM +0100, Chris Wilson wrote: > > On Fri, May 16, 2014 at 03:20:47PM -0700, Jesse Barnes wrote: > > > On Mon, 21 Apr 2014 18:37:31 +0200 > > > Knut Petersen wrote: > > > > > + /* This driver doesn't need a VT switch to restore the mode on > > > > > resume */ > > > > > + info->skip_vt_switch = true; > > > > > + > > > > > drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth); > > > > > drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, > > > > > sizes->fb_height); > > > > > > Is it sufficient to just revert this part? Or are the other bits > > > needed too? > > > > > > Sorry for the delay on this, I've been traveling a lot the past month > > > and buried in other stuff so out of touch with much of my email. > > > > The key step here is that X is restarted after resume. The slow down was > > due to X not finding any connected outputs and so disabling them all, > > setting up a dummy 1024x768 fb which really confused KDE. (KDE queries > > the config causing a forced reprobe of all outputs, setups the display > > for the native 1280x1024, but screws up KDE's own bookkeeping.) > > > > The impact has been fixed by handling the connector->status more > > robusting during initial output probing in X. What remains is the > > question whether connector->status can be set appropriately upon resume? > > It requires a detection cycle to be sure that the outputs are still > > there, which is arguably better deferred to userspace. To be consistent > > the BIOS take over code should mark connector->status as unknown for the > > CRTCs it takes over without doing a detection cycle (where we just > > presume that the CRTC/output being enabled means something is on the > > other end of the pipe and is still valid). > > Hmm. Why didn't fbcon respond to the hotplug event on resume and perform > a detection cycle before Knut was able to type startx on the console? > That I think is the bug. Well, fbcon resume is delayed, but we do perform an fb re-probe via intel_resume_hotplug() that should have done this. Not sure why that's sufficient... but I agree userspace should probably re-probe on resume. We're supposed to generate a uevent on resume, but the fb layer may suppress that if it detects that no change has occurred. Maybe X is racing with our resume_hotplug somehow? It doesn't look like that should happen... -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness
On Tue, 29 Apr 2014 23:30:49 +0300
Jani Nikula wrote:
> Historically we've exposed the full backlight PWM duty cycle range to
> the userspace, in the name of "mechanism, not policy". However, it turns
> out there are both panels and board designs where there is a minimum
> duty cycle that is required for proper operation. The minimum duty cycle
> is available in the VBT.
>
> The backlight class sysfs interface does not make any promises to the
> userspace about the physical meaning of the range
> 0..max_brightness. Specifically there is no guarantee that 0 means off;
> indeed for acpi_backlight 0 usually is not off, but the minimum
> acceptable value.
>
> Respect the minimum backlight, and expose the range acceptable to the
> hardware as 0..max_brightness to the userspace via the backlight class
> device; 0 means the minimum acceptable enabled value. To switch off the
> backlight, the user must disable the encoder.
>
> As a side effect, make the backlight class device max brightness and
> physical PWM modulation frequency (i.e. max duty cycle) independent.
>
> Signed-off-by: Jani Nikula
I like the direction here... I wonder if we should always virtualize
the max too, and just always expose 0-2047 or something.
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 50dfc3a1a9d1..d9dad3498b87 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1164,6 +1164,7 @@ struct intel_vbt_data {
> u16 pwm_freq_hz;
> bool present;
> bool active_low_pwm;
> + u8 min_brightness; /* min_brightness/255 of max */
> } backlight;
>
> /* MIPI DSI */
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 2945f57c53ee..1a3e172029b3 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -339,11 +339,12 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
> struct bdb_header *bdb)
>
> dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
> + dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
> DRM_DEBUG_KMS("VBT backlight PWM modulation frequency %u Hz, "
> "active %s, min brightness %u, level %u\n",
> dev_priv->vbt.backlight.pwm_freq_hz,
> dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
> - entry->min_brightness,
> + dev_priv->vbt.backlight.min_brightness,
> backlight_data->level[panel_type]);
> }
This should probably just be a standalone patch. You can add my r-b
for that.
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d8b540b891d1..2af74dd03e31 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -165,6 +165,7 @@ struct intel_panel {
> struct {
> bool present;
> u32 level;
> + u32 min;
> u32 max;
> bool enabled;
> bool combination_mode; /* gen 2/4 only */
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 776249bab488..360ae203aacb 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -398,6 +398,30 @@ intel_panel_detect(struct drm_device *dev)
> }
> }
>
> +/* Scale user_level in range [0..user_max] to [hw_min..hw_max]. */
> +static u32 scale_user_to_hw(struct intel_connector *connector,
> + u32 user_level, u32 user_max)
> +{
> + struct intel_panel *panel = &connector->panel;
> +
> + user_level = clamp(user_level, 0U, user_max);
> +
> + return panel->backlight.min + user_level *
> + (panel->backlight.max - panel->backlight.min) / user_max;
> +}
> +
> +/* Scale hw_level in range [hw_min..hw_max] to [0..user_max]. */
> +static u32 scale_hw_to_user(struct intel_connector *connector,
> + u32 hw_level, u32 user_max)
> +{
> + struct intel_panel *panel = &connector->panel;
> +
> + hw_level = clamp(hw_level, panel->backlight.min, panel->backlight.max);
> +
> + return (hw_level - panel->backlight.min) * user_max /
> + (panel->backlight.max - panel->backlight.min);
> +}
> +
> static u32 intel_panel_compute_brightness(struct intel_connector *connector,
> u32 val)
> {
> @@ -558,14 +582,14 @@ intel_panel_actually_set_backlight(struct
> intel_connector *connector, u32 level)
> }
>
> /* set backlight brightness to level in range [0..max] */
> -void intel_panel_set_backlight(struct intel_connector *connector, u32 level,
> -u32 max)
> +void intel_panel_set_backlight(struct intel_connector *connector,
> +
Re: [Intel-gfx] [RFC PATCH 1/2] drm/i915: shuffle panel code
On Tue, May 20, 2014 at 12:00:27PM -0700, Jesse Barnes wrote:
> On Tue, 29 Apr 2014 23:30:48 +0300
> Jani Nikula wrote:
>
> > Somehow a few functions have been dropped in the middle of backlight
> > code. Move them around. No functional changes.
> >
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/intel_panel.c | 150
> > ++---
> > 1 file changed, 75 insertions(+), 75 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index 44ad415e3706..776249bab488 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -42,6 +42,59 @@ intel_fixed_panel_mode(const struct drm_display_mode
> > *fixed_mode,
> > drm_mode_set_crtcinfo(adjusted_mode, 0);
> > }
> >
> > +/**
> > + * intel_find_panel_downclock - find the reduced downclock for LVDS in EDID
> > + * @dev: drm device
> > + * @fixed_mode : panel native mode
> > + * @connector: LVDS/eDP connector
> > + *
> > + * Return downclock_avail
> > + * Find the reduced downclock for LVDS/eDP in EDID.
> > + */
> > +struct drm_display_mode *
> > +intel_find_panel_downclock(struct drm_device *dev,
> > + struct drm_display_mode *fixed_mode,
> > + struct drm_connector *connector)
> > +{
> > + struct drm_display_mode *scan, *tmp_mode;
> > + int temp_downclock;
> > +
> > + temp_downclock = fixed_mode->clock;
> > + tmp_mode = NULL;
> > +
> > + list_for_each_entry(scan, &connector->probed_modes, head) {
> > + /*
> > +* If one mode has the same resolution with the fixed_panel
> > +* mode while they have the different refresh rate, it means
> > +* that the reduced downclock is found. In such
> > +* case we can set the different FPx0/1 to dynamically select
> > +* between low and high frequency.
> > +*/
> > + if (scan->hdisplay == fixed_mode->hdisplay &&
> > + scan->hsync_start == fixed_mode->hsync_start &&
> > + scan->hsync_end == fixed_mode->hsync_end &&
> > + scan->htotal == fixed_mode->htotal &&
> > + scan->vdisplay == fixed_mode->vdisplay &&
> > + scan->vsync_start == fixed_mode->vsync_start &&
> > + scan->vsync_end == fixed_mode->vsync_end &&
> > + scan->vtotal == fixed_mode->vtotal) {
> > + if (scan->clock < temp_downclock) {
> > + /*
> > +* The downclock is already found. But we
> > +* expect to find the lower downclock.
> > +*/
> > + temp_downclock = scan->clock;
> > + tmp_mode = scan;
> > + }
> > + }
> > + }
> > +
> > + if (temp_downclock < fixed_mode->clock)
> > + return drm_mode_duplicate(dev, tmp_mode);
> > + else
> > + return NULL;
> > +}
> > +
> > /* adjusted_mode has been preset to be the panel's fixed mode */
> > void
> > intel_pch_panel_fitting(struct intel_crtc *intel_crtc,
> > @@ -323,6 +376,28 @@ out:
> > pipe_config->gmch_pfit.lvds_border_bits = border;
> > }
> >
> > +enum drm_connector_status
> > +intel_panel_detect(struct drm_device *dev)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > +
> > + /* Assume that the BIOS does not lie through the OpRegion... */
> > + if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> > + return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> > + connector_status_connected :
> > + connector_status_disconnected;
> > + }
> > +
> > + switch (i915.panel_ignore_lid) {
> > + case -2:
> > + return connector_status_connected;
> > + case -1:
> > + return connector_status_disconnected;
> > + default:
> > + return connector_status_unknown;
> > + }
> > +}
> > +
> > static u32 intel_panel_compute_brightness(struct intel_connector
> > *connector,
> > u32 val)
> > {
> > @@ -795,28 +870,6 @@ void intel_panel_enable_backlight(struct
> > intel_connector *connector)
> > spin_unlock_irqrestore(&dev_priv->backlight_lock, flags);
> > }
> >
> > -enum drm_connector_status
> > -intel_panel_detect(struct drm_device *dev)
> > -{
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > -
> > - /* Assume that the BIOS does not lie through the OpRegion... */
> > - if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> > - return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> > - connector_status_connected :
> > - connector_status_disconnected;
> > - }
> > -
> > - switch (i915.panel_ignore_lid) {
> > - case -2:
> > - return connector_status_connected;
> > - case -1:
Re: [Intel-gfx] [RFC PATCH 1/2] drm/i915: shuffle panel code
On Tue, 29 Apr 2014 23:30:48 +0300
Jani Nikula wrote:
> Somehow a few functions have been dropped in the middle of backlight
> code. Move them around. No functional changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_panel.c | 150
> ++---
> 1 file changed, 75 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 44ad415e3706..776249bab488 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -42,6 +42,59 @@ intel_fixed_panel_mode(const struct drm_display_mode
> *fixed_mode,
> drm_mode_set_crtcinfo(adjusted_mode, 0);
> }
>
> +/**
> + * intel_find_panel_downclock - find the reduced downclock for LVDS in EDID
> + * @dev: drm device
> + * @fixed_mode : panel native mode
> + * @connector: LVDS/eDP connector
> + *
> + * Return downclock_avail
> + * Find the reduced downclock for LVDS/eDP in EDID.
> + */
> +struct drm_display_mode *
> +intel_find_panel_downclock(struct drm_device *dev,
> + struct drm_display_mode *fixed_mode,
> + struct drm_connector *connector)
> +{
> + struct drm_display_mode *scan, *tmp_mode;
> + int temp_downclock;
> +
> + temp_downclock = fixed_mode->clock;
> + tmp_mode = NULL;
> +
> + list_for_each_entry(scan, &connector->probed_modes, head) {
> + /*
> + * If one mode has the same resolution with the fixed_panel
> + * mode while they have the different refresh rate, it means
> + * that the reduced downclock is found. In such
> + * case we can set the different FPx0/1 to dynamically select
> + * between low and high frequency.
> + */
> + if (scan->hdisplay == fixed_mode->hdisplay &&
> + scan->hsync_start == fixed_mode->hsync_start &&
> + scan->hsync_end == fixed_mode->hsync_end &&
> + scan->htotal == fixed_mode->htotal &&
> + scan->vdisplay == fixed_mode->vdisplay &&
> + scan->vsync_start == fixed_mode->vsync_start &&
> + scan->vsync_end == fixed_mode->vsync_end &&
> + scan->vtotal == fixed_mode->vtotal) {
> + if (scan->clock < temp_downclock) {
> + /*
> + * The downclock is already found. But we
> + * expect to find the lower downclock.
> + */
> + temp_downclock = scan->clock;
> + tmp_mode = scan;
> + }
> + }
> + }
> +
> + if (temp_downclock < fixed_mode->clock)
> + return drm_mode_duplicate(dev, tmp_mode);
> + else
> + return NULL;
> +}
> +
> /* adjusted_mode has been preset to be the panel's fixed mode */
> void
> intel_pch_panel_fitting(struct intel_crtc *intel_crtc,
> @@ -323,6 +376,28 @@ out:
> pipe_config->gmch_pfit.lvds_border_bits = border;
> }
>
> +enum drm_connector_status
> +intel_panel_detect(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + /* Assume that the BIOS does not lie through the OpRegion... */
> + if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> + return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> + connector_status_connected :
> + connector_status_disconnected;
> + }
> +
> + switch (i915.panel_ignore_lid) {
> + case -2:
> + return connector_status_connected;
> + case -1:
> + return connector_status_disconnected;
> + default:
> + return connector_status_unknown;
> + }
> +}
> +
> static u32 intel_panel_compute_brightness(struct intel_connector *connector,
> u32 val)
> {
> @@ -795,28 +870,6 @@ void intel_panel_enable_backlight(struct intel_connector
> *connector)
> spin_unlock_irqrestore(&dev_priv->backlight_lock, flags);
> }
>
> -enum drm_connector_status
> -intel_panel_detect(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> - /* Assume that the BIOS does not lie through the OpRegion... */
> - if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> - return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> - connector_status_connected :
> - connector_status_disconnected;
> - }
> -
> - switch (i915.panel_ignore_lid) {
> - case -2:
> - return connector_status_connected;
> - case -1:
> - return connector_status_disconnected;
> - default:
> - return connector_status_unknown;
> - }
> -}
> -
> #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
>
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Implement WaVcpClkGateDisableForMediaReset:ctg, elk
On Mon, 19 May 2014 19:23:27 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently we need to disable VCP unit clock gating around media reset
> on g4x.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_uncore.c | 36 +++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6522af4..543f23c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1724,6 +1724,10 @@ enum punit_power_well {
> #define VF_UNIT_CLOCK_GATE_DISABLE (1 << 9)
> #define GS_UNIT_CLOCK_GATE_DISABLE (1 << 7)
> #define CL_UNIT_CLOCK_GATE_DISABLE (1 << 6)
> +
> +#define VDECCLK_GATE_D 0x620C /* g4x only */
> +#define VCP_UNIT_CLOCK_GATE_DISABLE (1 << 4)
> +
> #define RAMCLK_GATE_D0x6210 /* CRL only */
> #define DEUC 0x6214 /* CRL only */
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index cd0d6e2..67385a9 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -990,6 +990,36 @@ static int i965_do_reset(struct drm_device *dev)
> return 0;
> }
>
> +static int g4x_do_reset(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + int ret;
> +
> + pci_write_config_byte(dev->pdev, I965_GDRST,
> + GRDOM_RENDER | GRDOM_RESET_ENABLE);
> + ret = wait_for(i965_reset_complete(dev), 500);
> + if (ret)
> + return ret;
> +
> + /* WaVcpClkGateDisableForMediaReset:ctg,elk */
> + I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) |
> VCP_UNIT_CLOCK_GATE_DISABLE);
> + POSTING_READ(VDECCLK_GATE_D);
> +
> + pci_write_config_byte(dev->pdev, I965_GDRST,
> + GRDOM_MEDIA | GRDOM_RESET_ENABLE);
> + ret = wait_for(i965_reset_complete(dev), 500);
> + if (ret)
> + return ret;
> +
> + /* WaVcpClkGateDisableForMediaReset:ctg,elk */
> + I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) &
> ~VCP_UNIT_CLOCK_GATE_DISABLE);
> + POSTING_READ(VDECCLK_GATE_D);
> +
> + pci_write_config_byte(dev->pdev, I965_GDRST, 0);
> +
> + return 0;
> +}
> +
> static int ironlake_do_reset(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -1042,7 +1072,11 @@ int intel_gpu_reset(struct drm_device *dev)
> case 7:
> case 6: return gen6_do_reset(dev);
> case 5: return ironlake_do_reset(dev);
> - case 4: return i965_do_reset(dev);
> + case 4:
> + if (IS_G4X(dev))
> + return g4x_do_reset(dev);
> + else
> + return i965_do_reset(dev);
> default: return -ENODEV;
> }
> }
Given how the reset flow stuff works this seems sensible, but I
couldn't find it in the docs I have. Shouldn't do any harm at the very
worst...
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Clear GDSR after reset on ILK
On Mon, 19 May 2014 19:23:26 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Clear the reset domain after a succesful GPU reset on ilk. We already > do that on gen4, so let's try to be a bit more consistent. And if > ether render or media reset fails, we might use the leftover value > in the register to pinpoint the culprit. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_uncore.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > index 5c29cfe..cd0d6e2 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -1004,8 +1004,14 @@ static int ironlake_do_reset(struct drm_device *dev) > > I915_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR, > ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE); > - return wait_for((I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR) & > - ILK_GRDOM_RESET_ENABLE) == 0, 500); > + ret = wait_for((I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR) & > + ILK_GRDOM_RESET_ENABLE) == 0, 500); > + if (ret) > + return ret; > + > + I915_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR, 0); > + > + return 0; > } > > static int gen6_do_reset(struct drm_device *dev) Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Kill RMW from ILK reset code
On Mon, 19 May 2014 19:23:25 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> All the other bits in the GDSR register are read-only, so we don't have
> to preserve them when we perform a GPU reset.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 008d30b..5c29cfe 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -993,22 +993,17 @@ static int i965_do_reset(struct drm_device *dev)
> static int ironlake_do_reset(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 gdrst;
> int ret;
>
> - gdrst = I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR);
> - gdrst &= ~ILK_GRDOM_MASK;
> I915_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR,
> -gdrst | ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
> +ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
> ret = wait_for((I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR) &
> ILK_GRDOM_RESET_ENABLE) == 0, 500);
> if (ret)
> return ret;
>
> - gdrst = I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR);
> - gdrst &= ~ILK_GRDOM_MASK;
> I915_WRITE(MCHBAR_MIRROR_BASE + ILK_GDSR,
> -gdrst | ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
> +ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
> return wait_for((I915_READ(MCHBAR_MIRROR_BASE + ILK_GDSR) &
>ILK_GRDOM_RESET_ENABLE) == 0, 500);
> }
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: assert and de-assert sideband reset at boot and resume v2
On Mon, 19 May 2014 16:16:37 -0700 Jesse Barnes wrote: > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except > that it resets the whole common lane section of the PHY. This is > required on machines where the BIOS doesn't do this for us on boot or > resume to properly re-calibrate and get the PHY ready to transmit data. > > Without this patch, such machines won't resume correctly much of the time, > with the symptom being a 'port ready' timeout and/or a link training > failure. > > v2: extract simpler set_power_well function for use in reset_dpio (Imre) > move to reset_dpio (Daniel & Ville) Summarizing the IRC discussion because we're terrible about doing that. Imre was concerned that this new unconditional reset would prevent fastboot from working, and I think he's right. I added a check for the DPIO reset de-assertion for that case, and it seems to do the right thing on my BYT here (skipping the reset on boot since the BIOS already did it, and doing it on resume since the BIOS hadn't). Patch is in the next mail. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
that it resets the whole common lane section of the PHY. This is
required on machines where the BIOS doesn't do this for us on boot or
resume to properly re-calibrate and get the PHY ready to transmit data.
Without this patch, such machines won't resume correctly much of the time,
with the symptom being a 'port ready' timeout and/or a link training
failure.
v2: extract simpler set_power_well function for use in reset_dpio (Imre)
move to reset_dpio (Daniel & Ville)
v3: don't reset if DPIO reset is already de-asserted (Imre)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 19 +++
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_pm.c | 13 ++---
3 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index df58afc..bdb4624 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1509,6 +1509,25 @@ static void intel_reset_dpio(struct drm_device *dev)
} else {
/*
+* If DPIO has already been reset, e.g. by BIOS, just skip all
+* this.
+*/
+ if (I915_READ(DPIO_CTL) & DPIO_CMNRST)
+ return;
+
+ /*
+* From VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_11.docx:
+* Need to assert and de-assert PHY SB reset by gating the
+* common lane power, then un-gating it.
+* Simply ungating isn't enough to reset the PHY enough to get
+* ports and lanes running.
+*/
+ __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC,
+false);
+ __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC,
+true);
+
+ /*
* From VLV2A0_DP_eDP_DPIO_driver_vbios_notes_10.docx -
* 6. De-assert cmn_reset/side_reset. Same as VLV X0.
* a. GUnit 0x2110 bit[0] set to 1 (def 0)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0ef2777..feb6165 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -966,7 +966,8 @@ void intel_runtime_pm_put(struct drm_i915_private
*dev_priv);
void intel_init_runtime_pm(struct drm_i915_private *dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *dev);
-
+void __vlv_set_power_well(struct drm_i915_private *dev_priv,
+ enum punit_power_well power_well_id, bool enable);
/* intel_sdvo.c */
bool intel_sdvo_init(struct drm_device *dev, uint32_t sdvo_reg, bool is_sdvob);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b59e8ab..8f7dbb9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5724,10 +5724,9 @@ static bool i9xx_always_on_power_well_enabled(struct
drm_i915_private *dev_priv,
return true;
}
-static void vlv_set_power_well(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well, bool enable)
+void __vlv_set_power_well(struct drm_i915_private *dev_priv,
+ enum punit_power_well power_well_id, bool enable)
{
- enum punit_power_well power_well_id = power_well->data;
u32 mask;
u32 state;
u32 ctrl;
@@ -5760,6 +5759,14 @@ out:
mutex_unlock(&dev_priv->rps.hw_lock);
}
+static void vlv_set_power_well(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well, bool enable)
+{
+ enum punit_power_well power_well_id = power_well->data;
+
+ __vlv_set_power_well(dev_priv, power_well_id, enable);
+}
+
static void vlv_power_well_sync_hw(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Replaced Blitter ring based flips with MMIO flips
On Tue, 2014-05-20 at 11:59 +, Chris Wilson wrote:
> On Tue, May 20, 2014 at 04:19:46PM +0530, sourab.gu...@intel.com wrote:
> > +int i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno);
>
> Be strict and add __must_check
>
We'll add this.
> > +static bool intel_use_mmio_flip(struct drm_device *dev)
> > +{
> > + /* If module parameter is disabled, use CS flips.
> > +* Otherwise, use MMIO flips starting from Gen5.
> > +* This is not being used for older platforms because of
> > +* non-availability of flip done interrupt.
> > +*/
>
> What? Where is the dependence on flip-done?
Hi Chris,
>From an earlier mail by Ville,
"It should work on gen5+ since all of those have a flip done interrupt.
For older platforms we use some clever tricks involving the flip_pending
status bits and vblank irqs. That code won't work for mmio flips. We'd
need to add another way to complete the flips based. That would involve
using the frame counter to make it accurate. To avoid races there we'd
definitely need to use the vblank evade mechanism to make sure we sample
the frame counter within the same frame as when we write the registers.
Also gen2 has the extra complication that it lacks a hardware frame
counter."
So, we had put the Gen5+ check here.
>
> > + if (i915.use_mmio_flip == 0)
> > + return false;
> > +
> > + if (INTEL_INFO(dev)->gen >= 5)
> > + return true;
> > + else
> > + return false;
>
> You have not justified the change in default settings for existing hw.
> Your argument is based on media power wells which does not support the
> general change. It would seem that we may want to mix mmio / CS flips
> depending on workload based on your vague statements.
>
> I quite fancy a tristate here for force-CS flips, force-MMIO flips, at
> driver discretion. Then enabling it on an architecture as a seperate
> patch with justification - it is then easier to do each architecture on
> a case-by-case basis and revert if need be.
>
We agree that the using mmio flips gives better residency in cases where
render and blitter engines reside in different power wells. This is
helpful in case of pure 3D workloads on valleyview. We have enabled it
in the second patch of series for valleyview.
This patch has put forth 2 states - 0 for force-CS flips and 1 for
force-MMIO flips. The second patch in this series enables it for
Valleyview architecture.
> > +static int intel_postpone_flip(struct drm_i915_gem_object *obj)
> > +{
> > + int ret;
>
> if (WARN_ON(crtc->mmio_flip_data.seqno)) return -EBUSY;
>
> You need a tiling check here as you do not update dspcntr. Or fix
> mmio_done.
>
We were not updating dspcntr here because atomicity concerns. We could
add tiling update also if its ok in that regard.
Ville, what's your opinion here.
> > + if (!obj->ring)
> > + return 0;
> > +
> > + if (i915_seqno_passed(obj->ring->get_seqno(obj->ring, true),
> > + obj->last_write_seqno))
> > + return 0;
> > +
> > + if (ret = i915_gem_check_olr(obj->ring, obj->last_write_seqno))
> > + return ret;
>
> Please don't anger gcc.
>
> > +
> > + if (WARN_ON(!obj->ring->irq_get(obj->ring)))
> > + return 0;
> > +
> > + return 1;
> > +}
>
> > @@ -11377,6 +11497,9 @@ static void intel_init_display(struct drm_device
> > *dev)
> > break;
> > }
> >
> > + if(intel_use_mmio_flip(dev))
>
> Please don't anger checkpatch.
>
> > + dev_priv->display.queue_flip = intel_queue_mmio_flip;
> > +
> > intel_panel_init_backlight_funcs(dev);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 32a74e1..08d65a4 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -351,6 +351,11 @@ struct intel_pipe_wm {
> > bool sprites_scaled;
> > };
> >
> > +struct intel_mmio_flip {
> > + u32 seqno;
> > + u32 ring_id;
> > +};
> > +
> > struct intel_crtc {
> > struct drm_crtc base;
> > enum pipe pipe;
> > @@ -403,6 +408,7 @@ struct intel_crtc {
> > } wm;
> >
> > wait_queue_head_t vbl_wait;
> > + struct intel_mmio_flip mmio_flip_data;
>
> Does _data add anything meaningful here to the description of mmio_flip?
> Just mmio_flip will suffice, as pending_mmio_flip is overkill but would
> make a useful comment.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add missing unregister_oom_notifier to the error/unload path
On Tue, May 20, 2014 at 07:47:20PM +0300, Imre Deak wrote: > I'm trying to reduce the WARNs during driver reload and this was one of > them. Also while at it remove the redundant condition from before > unregister_shrinker(). > > v2: > - fix the error path too and move the unregister to its logical place > (Chris) > - remove redundant condition from before unregister_shrinker() > > Signed-off-by: Imre Deak Queued for -next, thanks for the patch. -Daniel > --- > drivers/gpu/drm/i915/i915_dma.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > index bf81396..f14c47a 100644 > --- a/drivers/gpu/drm/i915/i915_dma.c > +++ b/drivers/gpu/drm/i915/i915_dma.c > @@ -44,6 +44,7 @@ > #include > #include > #include > +#include > > #define LP_RING(d) (&((struct drm_i915_private *)(d))->ring[RCS]) > > @@ -1741,8 +1742,8 @@ out_power_well: > intel_power_domains_remove(dev_priv); > drm_vblank_cleanup(dev); > out_gem_unload: > - if (dev_priv->mm.shrinker.scan_objects) > - unregister_shrinker(&dev_priv->mm.shrinker); > + WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier)); > + unregister_shrinker(&dev_priv->mm.shrinker); > > if (dev->pdev->msi_enabled) > pci_disable_msi(dev->pdev); > @@ -1793,8 +1794,8 @@ int i915_driver_unload(struct drm_device *dev) > > i915_teardown_sysfs(dev); > > - if (dev_priv->mm.shrinker.scan_objects) > - unregister_shrinker(&dev_priv->mm.shrinker); > + WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier)); > + unregister_shrinker(&dev_priv->mm.shrinker); > > io_mapping_free(dev_priv->gtt.mappable); > arch_phys_wc_del(dev_priv->gtt.mtrr); > -- > 1.8.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Re-enable vblank irqs for already active pipes
On Tue, May 20, 2014 at 05:20:05PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > If a pipe is already active when we init/resume there might not be a > full modeset afterwards so drm_vblank_on() may not get called. In such > a case if someone is holding a vblank reference across a suspend/resume > cycle drm_vblank_get() called after resuming won't re-enable the vblank > interrupts. > > So in order to make sure vblank interrupts get re-enabled post-resume, > call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already > active. > > v2: Also drm_vblank_off() if the pipe got disabled magically > > Signed-off-by: Ville Syrjälä This seems to duct-tape over the funny failure I'm seeing on my snb where kms_flip/vblank-vs-modeset|dpms-suspend work nicely, but kms_flip/vblank-vs-suspend has some totally hilarious random vblank frame counter after the modeset. Testecase: igt/kms_flip/vblank-vs-suspend Tested-by: Daniel Vetter Now the problem I have: We already call this in the crtc_enable hook. Why does calling this here again add the necessary magic? /me has no clue Cheers, Daniel > --- > drivers/gpu/drm/i915/intel_display.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 9420f4f..2e9f0b0 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -11708,6 +11708,12 @@ static void intel_sanitize_crtc(struct intel_crtc > *crtc) > reg = PIPECONF(crtc->config.cpu_transcoder); > I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK); > > + /* restore vblank interrupts to correct state */ > + if (crtc->active) > + drm_vblank_on(dev, crtc->pipe); > + else > + drm_vblank_off(dev, crtc->pipe); > + > /* We need to sanitize the plane -> pipe mapping first because this will >* disable the crtc (and hence change the state) if it is wrong. Note >* that gen4+ has a fixed plane -> pipe mapping. */ > -- > 1.8.5.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: add missing unregister_oom_notifier to the error/unload path
I'm trying to reduce the WARNs during driver reload and this was one of them. Also while at it remove the redundant condition from before unregister_shrinker(). v2: - fix the error path too and move the unregister to its logical place (Chris) - remove redundant condition from before unregister_shrinker() Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_dma.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index bf81396..f14c47a 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -44,6 +44,7 @@ #include #include #include +#include #define LP_RING(d) (&((struct drm_i915_private *)(d))->ring[RCS]) @@ -1741,8 +1742,8 @@ out_power_well: intel_power_domains_remove(dev_priv); drm_vblank_cleanup(dev); out_gem_unload: - if (dev_priv->mm.shrinker.scan_objects) - unregister_shrinker(&dev_priv->mm.shrinker); + WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier)); + unregister_shrinker(&dev_priv->mm.shrinker); if (dev->pdev->msi_enabled) pci_disable_msi(dev->pdev); @@ -1793,8 +1794,8 @@ int i915_driver_unload(struct drm_device *dev) i915_teardown_sysfs(dev); - if (dev_priv->mm.shrinker.scan_objects) - unregister_shrinker(&dev_priv->mm.shrinker); + WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier)); + unregister_shrinker(&dev_priv->mm.shrinker); io_mapping_free(dev_priv->gtt.mappable); arch_phys_wc_del(dev_priv->gtt.mtrr); -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Add support for Generic MIPI panel driver
On Monday 19 May 2014 07:53 PM, Damien Lespiau wrote:
On Mon, Apr 14, 2014 at 11:18:27AM +0530, Shobhit Kumar wrote:
+#define NS_MHZ_RATIO 100
[...]
+static bool generic_init(struct intel_dsi_device *dsi)
+{
[...]
+ /*
+* ui(s) = 1/f [f in hz]
+* ui(ns) = 10^9/f*10^6 [f in Mhz] -> 10^3/f(Mhz)
ui(ns) = 10^9/(f*10^6)
+*
+* LP byte clock = TLPX/8ui
Mind putting that comment just above the appropriate computation?
Also, LP byte clock = Tlpx / (8UI)
+*
+* Since txddrclkhs_i is 2xUI, the count values programmed in
+* DPHY param registers are divided by 2
That looks like a general comment that apply to a bunch of calculations
below, probably worth separating it from the UI comment.
Will update as suggested.
+*
+*/
+
+ /* in Kbps */
+ ui_num = bitrate;
+ ui_den = NS_MHZ_RATIO;
I'm a bit confused here, most likely missing something, care to clarify?
- IIUC, you want the computations to happen in ns. I'm a bit puzzled by
that NS_MHZ_RATIO constant name when we're dealing with Kbps.
That constant is 10^6 which seems to be OK for KHz. So maybe just a
naming problem?
Yeah, I now realize that it should be something like NS_KHZ_RATIO to
avoid confusion
- UI is a period, so is homogeneous to time (s), but ui_num being in
s^-1 and ui_den a constant, ui_num/ui_den looks like a frequency. Or
could it be that UI = ui_den / ui_num? would be confusing, but the
code below would make more sense. In which case could we have UI =
ui_num / ui_den?
I just kept ui_num and ui_den separately to take care of precision loss,
but I see how it is adding to confusion. Actually it is ui_den / ui_num
and we have all computations as 1/UI so it works. I think I will compute
UI directly as UI = (NS_KHZ_RATIO * 1000) /bitrate and divide by 1000
wherever we use to maintain precision. Sounds ok ?
+
+ tclk_prepare_clkzero = mipi_config->tclk_prepare_clkzero;
+ ths_prepare_hszero = mipi_config->ths_prepare_hszero;
+
+ /* B060 */
+ intel_dsi->lp_byte_clk = CEIL_DIV(tlpx_ns * ui_num, 8 * ui_den);
+
+ /* count values in UI = (ns value) * (bitrate / (2 * 10^6)) */
+ /* prepare count */
+ ths_prepare_ns =
+ (mipi_config->ths_prepare > mipi_config->tclk_prepare) ?
+ mipi_config->ths_prepare :
+ mipi_config->tclk_prepare;
That looks like max()
+
+ prepare_cnt = CEIL_DIV(ths_prepare_ns * ui_num, ui_den * 2);
The formula above has a 10^6, why is that OK not to have it there? (in
which unit is bitrate in the formula? MHz?) Is this something like:
Count in UI = count(ns) / UI(ns)
and then as UI = ui_den/ui_num (?!) we end up with:
Count in UI = count(ns) * ui_num / ui_den
And then the / 2 comment applies.
Yeah actually its like this. I will correct as suggested above.
+
+ /* exit zero count */
+ exit_zero_cnt = CEIL_DIV(
+ (ths_prepare_hszero - ths_prepare_ns) * ui_num,
+ ui_den * 2
+ );
+
+ /*
+* Exit zero is unified val ths_zero and ths_exit
+* minimum value for ths_exit = 110ns
+* min (exit_zero_cnt * 2) = 110/UI
+* exit_zero_cnt = 55/UI
+*/
+if (exit_zero_cnt < (55 * ui_num / ui_den))
+ if ((55 * ui_num) % ui_den)
+ exit_zero_cnt += 1;
I'm not sure what we're achieving with the +=1 here, mind explaining?
This is as per MIPI host controller spec to ceil the value
+
+ /* clk zero count */
+ clk_zero_cnt = CEIL_DIV(
+ (tclk_prepare_clkzero - ths_prepare_ns)
+ * ui_num, 2 * ui_den);
+
+ /* trail count */
+ tclk_trail_ns = (mipi_config->tclk_trail > mipi_config->ths_trail) ?
+ mipi_config->tclk_trail : mipi_config->ths_trail;
max()
+ trail_cnt = CEIL_DIV(tclk_trail_ns * ui_num, 2 * ui_den);
+
+ if (prepare_cnt > PREPARE_CNT_MAX ||
+ exit_zero_cnt > EXIT_ZERO_CNT_MAX ||
+ clk_zero_cnt > CLK_ZERO_CNT_MAX ||
+ trail_cnt > TRAIL_CNT_MAX)
+ DRM_DEBUG_DRIVER("Values crossing maximum limits\n");
Is that a situation that may happen in a normal case? or should we go
with a DRM_ERROR() here and potentially abort the modeset?
Generally it should not happen. We should not abort but clip to max
values though there is no guarantee it will work, but there is high
chance that it will work.
+
+ if (prepare_cnt > PREPARE_CNT_MAX)
+ prepare_cnt = PREPARE_CNT_MAX;
+
+ if (exit_zero_cnt > EXIT_ZERO_CNT_MAX)
+ exit_zero_cnt = EXIT_ZERO_CNT_MAX;
+
+ if (clk_zero_cnt > CLK_ZERO_CNT_MAX)
+ clk_zero_cnt = CLK_ZERO_CNT_MAX;
+
+ if (trail_cnt > TRAIL_C
Re: [Intel-gfx] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, May 20, 2014 at 5:15 PM, Thierry Reding wrote: > The component/master helpers don't allow you to do that. Essentially > what it does is provide a way to glue together multiple devices (the > components) to produce a meta-device (the master). What you get is a > pair of .bind()/.unbind() functions that are called on each of the > components when the master binds or unbinds the meta-device. I don't > see how that could be made to work for suspend/resume. We'll we could add a pm_ops pointer to the master and auto-register a pile of suspend/resume hooks to all the component devices. Then we'd suspend the master as soon as the first component gets suspended and resume it only when the last component is resumed. Should be doable with a bunch of refcounts. On top of that we should be able to use runtime pm to do fine-grained pm control for each component. So in my naive world here (never used the component stuff myself after all) this should all work out ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/kms_flip: various improvements
- Some debug logging for the ts continuity checks.
- Add a plain vblank-vs-suspend test where kms_flip doesn't switch off
the displays first.
- Ensure that we do at least 2 rounds, the suspend tests bailed out
after 1 round and so didn't test anything.
- Frob the testnames a bit.
Signed-off-by: Daniel Vetter
---
tests/kms_flip.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 634b6274afae..dd641821c8dc 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -574,6 +574,9 @@ static void check_state(struct test_output *o, struct
event_state *es)
igt_assert_f(es->current_seq - es->last_seq <= 100,
"unexpected %s seq %u, should be < %u\n",
es->name, es->current_seq, es->last_seq + 100);
+
+ igt_debug("testing ts continuity: Current frame %u, old frame
%u\n",
+ es->current_seq, es->last_seq);
}
if ((o->flags & TEST_CHECK_TS) && (!analog_tv_connector(o))) {
@@ -1176,6 +1179,7 @@ static unsigned event_loop(struct test_output *o,
unsigned duration_ms)
{
unsigned long start, end;
uint32_t hang = 0; /* Suppress GCC warning */
+ int count = 0;
if (o->flags & TEST_HANG_ONCE) {
hang = hang_gpu(drm_fd);
@@ -1193,8 +1197,10 @@ static unsigned event_loop(struct test_output *o,
unsigned duration_ms)
check_all_state(o, completed_events);
update_all_state(o, completed_events);
- if ((gettime_us() - start) / 1000 >= duration_ms)
+ if (count && (gettime_us() - start) / 1000 >= duration_ms)
break;
+
+ count++;
}
end = gettime_us();
@@ -1563,10 +1569,11 @@ int main(int argc, char **argv)
{ 0, TEST_ENOENT | TEST_NOEVENT, "nonexisting-fb" },
{ 10, TEST_DPMS_OFF | TEST_DPMS | TEST_VBLANK_RACE,
"dpms-vs-vblank-race" },
{ 10, TEST_MODESET | TEST_VBLANK_RACE, "modeset-vs-vblank-race"
},
- { 10, TEST_VBLANK | TEST_DPMS | TEST_RPM | TEST_TS_CONT,
"dpms-vs-rpm" },
- { 10, TEST_VBLANK | TEST_DPMS | TEST_SUSPEND | TEST_TS_CONT,
"dpms-vs-suspend" },
- { 0, TEST_VBLANK | TEST_MODESET | TEST_RPM | TEST_TS_CONT,
"modeset-vs-rpm" },
- { 0, TEST_VBLANK | TEST_MODESET | TEST_SUSPEND | TEST_TS_CONT,
"modeset-vs-suspend" },
+ { 10, TEST_VBLANK | TEST_DPMS | TEST_RPM | TEST_TS_CONT,
"vblank-vs-dpms-rpm" },
+ { 10, TEST_VBLANK | TEST_MODESET | TEST_RPM | TEST_TS_CONT,
"vblank-vs-modeset-rpm" },
+ { 0, TEST_VBLANK | TEST_DPMS | TEST_SUSPEND | TEST_TS_CONT,
"vblank-vs-dpms-suspend" },
+ { 0, TEST_VBLANK | TEST_MODESET | TEST_SUSPEND | TEST_TS_CONT,
"vblank-vs-modeset-suspend" },
+ { 0, TEST_VBLANK | TEST_SUSPEND | TEST_TS_CONT,
"vblank-vs-suspend" },
{ 0, TEST_BO_TOOBIG | TEST_NO_2X_OUTPUT, "bo-too-big" },
};
int i;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM
On Tue, May 20, 2014 at 4:20 PM, Daniel Vetter wrote: > On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrjälä wrote: >> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote: >> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote: >> > > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote: >> > > > Now that we unconditionally dtrt when disabling/enabling crtcs we >> > > > don't need any hacks any longer to keep the vblank logic sane when >> > > > all the registers go poof. So let's rip it all out. >> > > >> > > Hmm. drm_update_vblank_count() will now see some kind of diff between >> > > the last and current value when the registers got cloberred. So the >> > > vblank counter reported to userspace will jump. But I guess that's fine >> > > as long as userspace realizes that the counter is not at all reliable >> > > across modesets. >> > >> > I've added checks for this (the rpm varianst) and for the similiar >> > suspend/resume issues (the suspend variants) to kms_flip. It seems to work >> > and we don't actually jump to far. But maybe the tests are horribly >> > broken. >> >> Hmm. If we can force the power well off at the start of the test and then >> set a mode, I'd expect the vblank counter to jump by almost max_vblank_count >> since the hw counter would appear to wrap. > > Oh, I think the tests are busted ... Need to look at this again. I've added some debug output and fixed the suspend variants of the tests and it actually seems to work. I.e. the frame counter before and after a runtime pm or suspend/resume cycle is monotonic and only increases by a few frames. The limit the test uses is 100 frames, which should be tight enough to not confuse userspace. Of course userspace still needs to be able to cope with cancelled vblank events, but that's just how it is. At least the frame counters look sane now. So I think we're good. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, May 20, 2014 at 05:07:51PM +0200, Daniel Vetter wrote: > On 20/05/2014 16:57, Thierry Reding wrote: > >On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote: > >>>On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote: > >On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > > >>This RFC is based on previous discussion to set up a generic > > >>communication channel between display and audio driver and > > >>an internal design of Intel MCG/VPG HDMI audio driver. It's still an > > >>initial draft and your advice would be appreciated > > >>to improve the design. > > >> > > >>The basic idea is to create a new avsink module and let both drm and > > >>alsa depend on it. > > >>This new module provides a framework and APIs for synchronization > > >>between the display and audio driver. > > >> > > >>1. Display/Audio Client > > >> > > >>The avsink core provides APIs to create, register and lookup a > > >>display/audio client. > > >>A specific display driver (eg. i915) or audio driver (eg. HD-Audio > > >>driver) can create a client, add some resources > > >>objects (shared power wells, display outputs, and audio inputs, > > >>register ops) to the client, and then register this > > >>client to avisink core. The peer driver can look up a registered > > >>client by a name or type, or both. If a client gives > > >>a valid peer client name on registration, avsink core will bind the > > >>two clients as peer for each other. And we > > >>expect a display client and an audio client to be peers for each other > > >>in a system. > > > >One problem we have at the moment is the order of calling the system > >suspend/resume handlers of the display driver wrt. that of the audio > >driver. Since the power well control is part of the display HW block, we > >need to run the display driver's resume handler first, initialize the > >HW, and only then let the audio driver's resume handler run. For similar > >reasons we have to call the audio suspend handler first and only then > >the display driver resume handler. Currently we solve this using the > >display driver's late/early suspend/resume hooks, but we'd need a more > >robust solution. > > > >This seems to be a similar issue to the load time ordering problem that > >you describe later. Having a real device for avsync that would be a > >child of the display device would solve the ordering issue in both > >cases. I admit I haven't looked into it if this is feasible, but I would > >like to see some solution to this as part of the plan. > >>> > >>>Yeah, this is a big reason why I want real devices - we have piles of > >>>infrastructure to solve these ordering issues as soon as there's a > >>>struct device around. If we don't use that, we need to reinvent all > >>>those wheels ourselves. > >To make the driver core's magic work I think you'd need to find a way to > >reparent the audio device under the display device. Presumably they come > >from two different parts of the device tree (two different PCI devices I > >would guess for Intel, two different platform devices on SoCs). Changing > >the parent after a device has been registered doesn't work as far as I > >know. But even assuming that would work, I have trouble imagining what > >the implications would be on the rest of the driver model. > > > >I faced similar problems with the Tegra DRM driver, and the only way I > >can see to make this kind of interaction between devices work is by > >tacking on an extra layer outside the core driver model. > That's why we need a new avsink device which is a proper child of the gfx > device, and the audio driver needs to use the componentized device framework > so that the suspend/resume ordering works correctly. Or at least that's been > my idea, might be we have some small gaps here and there. The component/master helpers don't allow you to do that. Essentially what it does is provide a way to glue together multiple devices (the components) to produce a meta-device (the master). What you get is a pair of .bind()/.unbind() functions that are called on each of the components when the master binds or unbinds the meta-device. I don't see how that could be made to work for suspend/resume. Thierry pgp_kB904ANJg.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On 20/05/2014 16:57, Thierry Reding wrote: On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote: >On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote: > >On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > >>This RFC is based on previous discussion to set up a generic > >>communication channel between display and audio driver and > >>an internal design of Intel MCG/VPG HDMI audio driver. It's still an > >>initial draft and your advice would be appreciated > >>to improve the design. > >> > >>The basic idea is to create a new avsink module and let both drm and > >>alsa depend on it. > >>This new module provides a framework and APIs for synchronization > >>between the display and audio driver. > >> > >>1. Display/Audio Client > >> > >>The avsink core provides APIs to create, register and lookup a > >>display/audio client. > >>A specific display driver (eg. i915) or audio driver (eg. HD-Audio > >>driver) can create a client, add some resources > >>objects (shared power wells, display outputs, and audio inputs, > >>register ops) to the client, and then register this > >>client to avisink core. The peer driver can look up a registered > >>client by a name or type, or both. If a client gives > >>a valid peer client name on registration, avsink core will bind the > >>two clients as peer for each other. And we > >>expect a display client and an audio client to be peers for each other > >>in a system. > > > >One problem we have at the moment is the order of calling the system > >suspend/resume handlers of the display driver wrt. that of the audio > >driver. Since the power well control is part of the display HW block, we > >need to run the display driver's resume handler first, initialize the > >HW, and only then let the audio driver's resume handler run. For similar > >reasons we have to call the audio suspend handler first and only then > >the display driver resume handler. Currently we solve this using the > >display driver's late/early suspend/resume hooks, but we'd need a more > >robust solution. > > > >This seems to be a similar issue to the load time ordering problem that > >you describe later. Having a real device for avsync that would be a > >child of the display device would solve the ordering issue in both > >cases. I admit I haven't looked into it if this is feasible, but I would > >like to see some solution to this as part of the plan. > >Yeah, this is a big reason why I want real devices - we have piles of >infrastructure to solve these ordering issues as soon as there's a >struct device around. If we don't use that, we need to reinvent all >those wheels ourselves. To make the driver core's magic work I think you'd need to find a way to reparent the audio device under the display device. Presumably they come from two different parts of the device tree (two different PCI devices I would guess for Intel, two different platform devices on SoCs). Changing the parent after a device has been registered doesn't work as far as I know. But even assuming that would work, I have trouble imagining what the implications would be on the rest of the driver model. I faced similar problems with the Tegra DRM driver, and the only way I can see to make this kind of interaction between devices work is by tacking on an extra layer outside the core driver model. That's why we need a new avsink device which is a proper child of the gfx device, and the audio driver needs to use the componentized device framework so that the suspend/resume ordering works correctly. Or at least that's been my idea, might be we have some small gaps here and there. -Daniel Intel Semiconductor AG Registered No. 020.30.913.786-7 Registered Office: Badenerstrasse 549, 8048 Zurich, Switzerland ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, 2014-05-20 at 20:05 +0530, Vinod Koul wrote: > On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote: > > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > > > This RFC is based on previous discussion to set up a generic > > > communication channel between display and audio driver and > > > an internal design of Intel MCG/VPG HDMI audio driver. It's still an > > > initial draft and your advice would be appreciated > > > to improve the design. > > > > > > The basic idea is to create a new avsink module and let both drm and > > > alsa depend on it. > > > This new module provides a framework and APIs for synchronization > > > between the display and audio driver. > > > > > > 1. Display/Audio Client > > > > > > The avsink core provides APIs to create, register and lookup a > > > display/audio client. > > > A specific display driver (eg. i915) or audio driver (eg. HD-Audio > > > driver) can create a client, add some resources > > > objects (shared power wells, display outputs, and audio inputs, > > > register ops) to the client, and then register this > > > client to avisink core. The peer driver can look up a registered > > > client by a name or type, or both. If a client gives > > > a valid peer client name on registration, avsink core will bind the > > > two clients as peer for each other. And we > > > expect a display client and an audio client to be peers for each other > > > in a system. > > > > One problem we have at the moment is the order of calling the system > > suspend/resume handlers of the display driver wrt. that of the audio > > driver. Since the power well control is part of the display HW block, we > > need to run the display driver's resume handler first, initialize the > > HW, and only then let the audio driver's resume handler run. For similar > > reasons we have to call the audio suspend handler first and only then > > the display driver resume handler. Currently we solve this using the > > display driver's late/early suspend/resume hooks, but we'd need a more > > robust solution. > > > > This seems to be a similar issue to the load time ordering problem that > > you describe later. Having a real device for avsync that would be a > > child of the display device would solve the ordering issue in both > > cases. I admit I haven't looked into it if this is feasible, but I would > > like to see some solution to this as part of the plan. > > If we are able create and mandate that HDMI display controller is parent and > audio is child device, then this wouldn't be an issue and PM frameowrk will > ensure parent is suspended last. To my understanding we can't really do that since that's already fixed by the physical bus topology. That is in the Intel case the parent of both the audio and display device is the corresponding PCI bridge device. But avsync could be a new virtual device and you could let that be the child of the display device. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote: > On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote: > > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > >> This RFC is based on previous discussion to set up a generic > >> communication channel between display and audio driver and > >> an internal design of Intel MCG/VPG HDMI audio driver. It's still an > >> initial draft and your advice would be appreciated > >> to improve the design. > >> > >> The basic idea is to create a new avsink module and let both drm and > >> alsa depend on it. > >> This new module provides a framework and APIs for synchronization > >> between the display and audio driver. > >> > >> 1. Display/Audio Client > >> > >> The avsink core provides APIs to create, register and lookup a > >> display/audio client. > >> A specific display driver (eg. i915) or audio driver (eg. HD-Audio > >> driver) can create a client, add some resources > >> objects (shared power wells, display outputs, and audio inputs, > >> register ops) to the client, and then register this > >> client to avisink core. The peer driver can look up a registered > >> client by a name or type, or both. If a client gives > >> a valid peer client name on registration, avsink core will bind the > >> two clients as peer for each other. And we > >> expect a display client and an audio client to be peers for each other > >> in a system. > > > > One problem we have at the moment is the order of calling the system > > suspend/resume handlers of the display driver wrt. that of the audio > > driver. Since the power well control is part of the display HW block, we > > need to run the display driver's resume handler first, initialize the > > HW, and only then let the audio driver's resume handler run. For similar > > reasons we have to call the audio suspend handler first and only then > > the display driver resume handler. Currently we solve this using the > > display driver's late/early suspend/resume hooks, but we'd need a more > > robust solution. > > > > This seems to be a similar issue to the load time ordering problem that > > you describe later. Having a real device for avsync that would be a > > child of the display device would solve the ordering issue in both > > cases. I admit I haven't looked into it if this is feasible, but I would > > like to see some solution to this as part of the plan. > > Yeah, this is a big reason why I want real devices - we have piles of > infrastructure to solve these ordering issues as soon as there's a > struct device around. If we don't use that, we need to reinvent all > those wheels ourselves. To make the driver core's magic work I think you'd need to find a way to reparent the audio device under the display device. Presumably they come from two different parts of the device tree (two different PCI devices I would guess for Intel, two different platform devices on SoCs). Changing the parent after a device has been registered doesn't work as far as I know. But even assuming that would work, I have trouble imagining what the implications would be on the rest of the driver model. I faced similar problems with the Tegra DRM driver, and the only way I can see to make this kind of interaction between devices work is by tacking on an extra layer outside the core driver model. Thierry pgpPqxaZpacIy.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak wrote: > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > > This RFC is based on previous discussion to set up a generic > > communication channel between display and audio driver and > > an internal design of Intel MCG/VPG HDMI audio driver. It's still an > > initial draft and your advice would be appreciated > > to improve the design. > > > > The basic idea is to create a new avsink module and let both drm and > > alsa depend on it. > > This new module provides a framework and APIs for synchronization > > between the display and audio driver. > > > > 1. Display/Audio Client > > > > The avsink core provides APIs to create, register and lookup a > > display/audio client. > > A specific display driver (eg. i915) or audio driver (eg. HD-Audio > > driver) can create a client, add some resources > > objects (shared power wells, display outputs, and audio inputs, > > register ops) to the client, and then register this > > client to avisink core. The peer driver can look up a registered > > client by a name or type, or both. If a client gives > > a valid peer client name on registration, avsink core will bind the > > two clients as peer for each other. And we > > expect a display client and an audio client to be peers for each other > > in a system. > > One problem we have at the moment is the order of calling the system > suspend/resume handlers of the display driver wrt. that of the audio > driver. Since the power well control is part of the display HW block, we > need to run the display driver's resume handler first, initialize the > HW, and only then let the audio driver's resume handler run. For similar > reasons we have to call the audio suspend handler first and only then > the display driver resume handler. Currently we solve this using the > display driver's late/early suspend/resume hooks, but we'd need a more > robust solution. > > This seems to be a similar issue to the load time ordering problem that > you describe later. Having a real device for avsync that would be a > child of the display device would solve the ordering issue in both > cases. I admit I haven't looked into it if this is feasible, but I would > like to see some solution to this as part of the plan. If we are able create and mandate that HDMI display controller is parent and audio is child device, then this wouldn't be an issue and PM frameowrk will ensure parent is suspended last. -- ~Vinod signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote: > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: >> This RFC is based on previous discussion to set up a generic >> communication channel between display and audio driver and >> an internal design of Intel MCG/VPG HDMI audio driver. It's still an >> initial draft and your advice would be appreciated >> to improve the design. >> >> The basic idea is to create a new avsink module and let both drm and >> alsa depend on it. >> This new module provides a framework and APIs for synchronization >> between the display and audio driver. >> >> 1. Display/Audio Client >> >> The avsink core provides APIs to create, register and lookup a >> display/audio client. >> A specific display driver (eg. i915) or audio driver (eg. HD-Audio >> driver) can create a client, add some resources >> objects (shared power wells, display outputs, and audio inputs, >> register ops) to the client, and then register this >> client to avisink core. The peer driver can look up a registered >> client by a name or type, or both. If a client gives >> a valid peer client name on registration, avsink core will bind the >> two clients as peer for each other. And we >> expect a display client and an audio client to be peers for each other >> in a system. > > One problem we have at the moment is the order of calling the system > suspend/resume handlers of the display driver wrt. that of the audio > driver. Since the power well control is part of the display HW block, we > need to run the display driver's resume handler first, initialize the > HW, and only then let the audio driver's resume handler run. For similar > reasons we have to call the audio suspend handler first and only then > the display driver resume handler. Currently we solve this using the > display driver's late/early suspend/resume hooks, but we'd need a more > robust solution. > > This seems to be a similar issue to the load time ordering problem that > you describe later. Having a real device for avsync that would be a > child of the display device would solve the ordering issue in both > cases. I admit I haven't looked into it if this is feasible, but I would > like to see some solution to this as part of the plan. Yeah, this is a big reason why I want real devices - we have piles of infrastructure to solve these ordering issues as soon as there's a struct device around. If we don't use that, we need to reinvent all those wheels ourselves. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Re-enable vblank irqs for already active pipes
From: Ville Syrjälä If a pipe is already active when we init/resume there might not be a full modeset afterwards so drm_vblank_on() may not get called. In such a case if someone is holding a vblank reference across a suspend/resume cycle drm_vblank_get() called after resuming won't re-enable the vblank interrupts. So in order to make sure vblank interrupts get re-enabled post-resume, call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already active. v2: Also drm_vblank_off() if the pipe got disabled magically Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9420f4f..2e9f0b0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11708,6 +11708,12 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc) reg = PIPECONF(crtc->config.cpu_transcoder); I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK); + /* restore vblank interrupts to correct state */ + if (crtc->active) + drm_vblank_on(dev, crtc->pipe); + else + drm_vblank_off(dev, crtc->pipe); + /* We need to sanitize the plane -> pipe mapping first because this will * disable the crtc (and hence change the state) if it is wrong. Note * that gen4+ has a fixed plane -> pipe mapping. */ -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: > This RFC is based on previous discussion to set up a generic > communication channel between display and audio driver and > an internal design of Intel MCG/VPG HDMI audio driver. It's still an > initial draft and your advice would be appreciated > to improve the design. > > The basic idea is to create a new avsink module and let both drm and > alsa depend on it. > This new module provides a framework and APIs for synchronization > between the display and audio driver. > > 1. Display/Audio Client > > The avsink core provides APIs to create, register and lookup a > display/audio client. > A specific display driver (eg. i915) or audio driver (eg. HD-Audio > driver) can create a client, add some resources > objects (shared power wells, display outputs, and audio inputs, > register ops) to the client, and then register this > client to avisink core. The peer driver can look up a registered > client by a name or type, or both. If a client gives > a valid peer client name on registration, avsink core will bind the > two clients as peer for each other. And we > expect a display client and an audio client to be peers for each other > in a system. One problem we have at the moment is the order of calling the system suspend/resume handlers of the display driver wrt. that of the audio driver. Since the power well control is part of the display HW block, we need to run the display driver's resume handler first, initialize the HW, and only then let the audio driver's resume handler run. For similar reasons we have to call the audio suspend handler first and only then the display driver resume handler. Currently we solve this using the display driver's late/early suspend/resume hooks, but we'd need a more robust solution. This seems to be a similar issue to the load time ordering problem that you describe later. Having a real device for avsync that would be a child of the display device would solve the ordering issue in both cases. I admit I haven't looked into it if this is feasible, but I would like to see some solution to this as part of the plan. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM
On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrjälä wrote:
> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > > > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > > > don't need any hacks any longer to keep the vblank logic sane when
> > > > all the registers go poof. So let's rip it all out.
> > >
> > > Hmm. drm_update_vblank_count() will now see some kind of diff between
> > > the last and current value when the registers got cloberred. So the
> > > vblank counter reported to userspace will jump. But I guess that's fine
> > > as long as userspace realizes that the counter is not at all reliable
> > > across modesets.
> >
> > I've added checks for this (the rpm varianst) and for the similiar
> > suspend/resume issues (the suspend variants) to kms_flip. It seems to work
> > and we don't actually jump to far. But maybe the tests are horribly
> > broken.
>
> Hmm. If we can force the power well off at the start of the test and then
> set a mode, I'd expect the vblank counter to jump by almost max_vblank_count
> since the hw counter would appear to wrap.
Oh, I think the tests are busted ... Need to look at this again.
-Daniel
>
> >
> > Can you please take a closer look? I've thought that the entire point of
> > this series (well, one of them) was to finally fix this gag and avoid
> > handing totally bogus frame counter values to userspace. Especially for
> > system suspend/resume where userspace might get susprised ...
>
> I was mostly interested in making vblank interrupts work during plane
> enable/disable. Anything else is a bonus.
>
> > -Daniel
> >
> > >
> > > >
> > > > This essentially undoes
> > > >
> > > > commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
> > > > Author: Paulo Zanoni
> > > > Date: Tue Jul 23 10:48:11 2013 -0300
> > > >
> > > > drm/i915: update last_vblank when disabling the power well
> > > >
> > > > Apparently igt/kms_flip is already powerful enough to exercise this
> > > > properly, yay! See the reference regression report for details.
> > > >
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
> > > > Testcase: igt/kms_flip/*-vs-rpm
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/i915/intel_pm.c | 34 --
> > > > 1 file changed, 34 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 75c1c766b507..45fa43f16bb3 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -5423,33 +5423,6 @@ static void hsw_power_well_post_enable(struct
> > > > drm_i915_private *dev_priv)
> > > > }
> > > > }
> > > >
> > > > -static void reset_vblank_counter(struct drm_device *dev, enum pipe
> > > > pipe)
> > > > -{
> > > > - assert_spin_locked(&dev->vbl_lock);
> > > > -
> > > > - dev->vblank[pipe].last = 0;
> > > > -}
> > > > -
> > > > -static void hsw_power_well_post_disable(struct drm_i915_private
> > > > *dev_priv)
> > > > -{
> > > > - struct drm_device *dev = dev_priv->dev;
> > > > - enum pipe pipe;
> > > > - unsigned long irqflags;
> > > > -
> > > > - /*
> > > > -* After this, the registers on the pipes that are part of the
> > > > power
> > > > -* well will become zero, so we have to adjust our counters
> > > > according to
> > > > -* that.
> > > > -*
> > > > -* FIXME: Should we do this in general in
> > > > drm_vblank_post_modeset?
> > > > -*/
> > > > - spin_lock_irqsave(&dev->vbl_lock, irqflags);
> > > > - for_each_pipe(pipe)
> > > > - if (pipe != PIPE_A)
> > > > - reset_vblank_counter(dev, pipe);
> > > > - spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> > > > -}
> > > > -
> > > > static void hsw_set_power_well(struct drm_i915_private *dev_priv,
> > > >struct i915_power_well *power_well, bool
> > > > enable)
> > > > {
> > > > @@ -5478,8 +5451,6 @@ static void hsw_set_power_well(struct
> > > > drm_i915_private *dev_priv,
> > > > I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
> > > > POSTING_READ(HSW_PWR_WELL_DRIVER);
> > > > DRM_DEBUG_KMS("Requesting to disable the power
> > > > well\n");
> > > > -
> > > > - hsw_power_well_post_disable(dev_priv);
> > > > }
> > > > }
> > > > }
> > > > @@ -5646,11 +5617,6 @@ static void
> > > > vlv_display_power_well_disable(struct drm_i915_private *dev_priv,
> > > > valleyview_disable_display_irqs(dev_priv);
> > > > spin_unlock_irq(&dev_priv->irq_lock);
> > > >
> > > > - spin_lock_irq(&dev->vbl_lock);
> > > > - for_each_pipe(pipe)
> > >
[Intel-gfx] [PATCH 1/3] drm: Always reject drm_vblank_get() after drm_vblank_off()
From: Ville Syrjälä
Make sure drm_vblank_get() never succeeds when called between
drm_vblank_off() and drm_vblank_on(). Borrow a trick from the
old drm_vblank_{pre,post}_modeset() functions and just bump
the refcount in drm_vblank_off() and drop it in drm_vblank_on().
Hopefully the use of inmodeset won't conflict badly with
drm_vblank_{pre,post}_modeset().
For i915 there's a window between drm_vblank_off() and marking the
crtc as inactive where the current code still allows drm_vblank_get().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_irq.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index dd786d8..69a2b2a 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -958,6 +958,15 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
}
spin_unlock(&dev->event_lock);
+ /*
+* Prevent subsequent drm_vblank_get() from re-enabling
+* the vblank interrupt by bumping the refcount.
+*/
+ if (!dev->vblank[crtc].inmodeset) {
+ atomic_inc(&dev->vblank[crtc].refcount);
+ dev->vblank[crtc].inmodeset = 1;
+ }
+
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
}
EXPORT_SYMBOL(drm_vblank_off);
@@ -972,6 +981,11 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
unsigned long irqflags;
spin_lock_irqsave(&dev->vbl_lock, irqflags);
+ /* Drop our private "prevent drm_vblank_get" refcount */
+ if (dev->vblank[crtc].inmodeset) {
+ atomic_dec(&dev->vblank[crtc].refcount);
+ dev->vblank[crtc].inmodeset = 0;
+ }
/* re-enable interrupts if there's are users left */
if (atomic_read(&dev->vblank[crtc].refcount) != 0)
WARN_ON(drm_vblank_enable(dev, crtc));
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off()
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index df58afc..9420f4f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1298,6 +1298,17 @@ static void assert_sprites_disabled(struct
drm_i915_private *dev_priv,
}
}
+static void assert_vblank_disabled(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ enum pipe pipe = crtc->pipe;
+
+ if (WARN_ON(drm_vblank_get(dev, pipe) == 0)) {
+ drm_vblank_put(dev, pipe);
+ drm_vblank_off(dev, pipe);
+ }
+}
+
static void ibx_assert_pch_refclk_enabled(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -3863,6 +3874,8 @@ static void intel_crtc_enable_planes(struct drm_crtc
*crtc)
int pipe = intel_crtc->pipe;
int plane = intel_crtc->plane;
+ assert_vblank_disabled(intel_crtc);
+
intel_enable_primary_hw_plane(dev_priv, plane, pipe);
intel_enable_planes(crtc);
/* The fixup needs to happen before cursor is enabled */
@@ -3899,6 +3912,8 @@ static void intel_crtc_disable_planes(struct drm_crtc
*crtc)
intel_crtc_update_cursor(crtc, false);
intel_disable_planes(crtc);
intel_disable_primary_hw_plane(dev_priv, plane, pipe);
+
+ assert_vblank_disabled(intel_crtc);
}
static void ironlake_crtc_enable(struct drm_crtc *crtc)
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915: A few more vblank interrupt fixes
From: Ville Syrjälä We have a few more corner cases with the drm_vblank_on/off stuff. This series aims to fix those. I couldn't think of a good way to write a test case for the drm_vblank_get() issue since it's a transient state that occurs briefly during modeset. So I added asserts for it instead. So far I didn't write a test for the intel_sanitize_crtc() case either. But I can try to think of something for that... Ville Syrjälä (3): drm: Always reject drm_vblank_get() after drm_vblank_off() drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off() drm/i915: Re-enable vblank irqs for already active pipes drivers/gpu/drm/drm_irq.c| 14 ++ drivers/gpu/drm/i915/intel_display.c | 21 + 2 files changed, 35 insertions(+) -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Add a brief description of the VLV display PHY internals
On Fri, Apr 25, 2014 at 7:44 PM, Daniel Vetter wrote: > On Fri, Apr 25, 2014 at 7:14 PM, wrote: >> From: Ville Syrjälä >> >> Document the internal structure of the VLV display PHY a bit to help >> people understand how the different register blocks relate to each >> other. >> >> v2: Add a bit more text >> Make it a DOC: comment, but leave the ascii art out since >> it would get mangled >> >> Signed-off-by: Ville Syrjälä > > Chon can you please review these documentation patches from Ville > quickly? You've done all the chv phy enabling after all. Ping for the review -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 64/71] drm/i915/chv: Don't use PCS group access reads
On Tue, May 20, 2014 at 4:11 PM, Ville Syrjälä wrote: > On Tue, May 20, 2014 at 03:50:02PM +0200, Daniel Vetter wrote: >> On Wed, Apr 09, 2014 at 07:56:50PM +0300, Ville Syrjälä wrote: >> > On Wed, Apr 09, 2014 at 06:18:38PM +0200, Daniel Vetter wrote: >> > > On Wed, Apr 09, 2014 at 01:29:02PM +0300, ville.syrj...@linux.intel.com >> > > wrote: >> > > > From: Ville Syrjälä >> > > > >> > > > All PCS groups access reads return 0x, so we can't use group >> > > > access for RMW cycles. Instead target each spline separately. >> > > >> > > I have no idea what PCS means here and spline ... Can you please expand >> > > for those who haven't yet lost their souls in chv docs? Just so we have a >> > > commonly-understood jargon for talking about this stuff. >> > >> > I guess we should have that somewhere as a comment. The same terminology >> > applies to VLV as well. >> >> Haven't seen the promised patch yet. > > "[PATCH] drm/i915: Add a brief description of the VLV display PHY internals" > & co. Indeed, but fell through the review cracks :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/kms_flip: Add vblank vs. gpu hang testcase
Currently broken :(
Signed-off-by: Daniel Vetter
---
tests/kms_flip.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index f2ec9ef64701..634b6274afae 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -75,6 +75,7 @@
#define TEST_SUSPEND (1 << 26)
#define TEST_TS_CONT (1 << 27)
#define TEST_BO_TOOBIG (1 << 28)
+#define TEST_HANG_ONCE (1 << 29)
#define EVENT_FLIP (1 << 0)
#define EVENT_VBLANK (1 << 1)
@@ -1174,6 +1175,12 @@ static unsigned int wait_for_events(struct test_output
*o)
static unsigned event_loop(struct test_output *o, unsigned duration_ms)
{
unsigned long start, end;
+ uint32_t hang = 0; /* Suppress GCC warning */
+
+ if (o->flags & TEST_HANG_ONCE) {
+ hang = hang_gpu(drm_fd);
+ igt_assert_f(hang, "failed to exercise page flip hang
recovery\n");
+ }
start = gettime_us();
@@ -1192,6 +1199,9 @@ static unsigned event_loop(struct test_output *o,
unsigned duration_ms)
end = gettime_us();
+ if (hang)
+ unhang_gpu(drm_fd, hang);
+
/* Flush any remaining events */
if (o->pending_events)
wait_for_events(o);
@@ -1542,6 +1552,7 @@ int main(int argc, char **argv)
TEST_CHECK_TS, "flip-vs-blocking-wf-vblank" },
{ 30, TEST_FLIP | TEST_MODESET | TEST_HANG | TEST_NOEVENT,
"flip-vs-modeset-vs-hang" },
{ 30, TEST_FLIP | TEST_PAN | TEST_HANG,
"flip-vs-panning-vs-hang" },
+ { 30, TEST_VBLANK | TEST_HANG_ONCE, "vblank-vs-hang" },
{ 1, TEST_FLIP | TEST_EINVAL | TEST_FB_BAD_TILING,
"flip-vs-bad-tiling" },
{ 1, TEST_DPMS_OFF | TEST_MODESET | TEST_FLIP,
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Drop /** */ comments from i915_reg.h
On Fri, Apr 25, 2014 at 08:14:30PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The comments in i915_reg.h aren't proper kernel-doc comments, so replace
> the magic /** with just /*
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_reg.h | 246
>
> 1 file changed, 123 insertions(+), 123 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0eff337..b6d5045 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1516,7 +1516,7 @@ enum punit_power_well {
> # define DPIOUNIT_CLOCK_GATE_DISABLE (1 << 6) /* 915-945 */
> # define OVFUNIT_CLOCK_GATE_DISABLE (1 << 5)
> # define OVBUNIT_CLOCK_GATE_DISABLE (1 << 4)
> -/**
> +/*
> * This bit must be set on the 830 to prevent hangs when turning off the
> * overlay scaler.
> */
> @@ -1536,12 +1536,12 @@ enum punit_power_well {
> # define COLOR_CALCULATOR_CLOCK_GATE_DISABLE (1 << 7)
> # define MOTION_COMP_CLOCK_GATE_DISABLE (1 << 6)
> # define MAG_CLOCK_GATE_DISABLE (1 << 5)
> -/** This bit must be unset on 855,865 */
> +/* This bit must be unset on 855,865 */
> # define MECI_CLOCK_GATE_DISABLE (1 << 4)
> # define DCMP_CLOCK_GATE_DISABLE (1 << 3)
> # define MEC_CLOCK_GATE_DISABLE (1 << 2)
> # define MECO_CLOCK_GATE_DISABLE (1 << 1)
> -/** This bit must be set on 855,865. */
> +/* This bit must be set on 855,865. */
> # define SV_CLOCK_GATE_DISABLE (1 << 0)
> # define I915_MPEG_CLOCK_GATE_DISABLE(1 << 16)
> # define I915_VLD_IP_PR_CLOCK_GATE_DISABLE (1 << 15)
> @@ -1562,14 +1562,14 @@ enum punit_power_well {
> # define I915_BY_CLOCK_GATE_DISABLE (1 << 0)
>
> # define I965_RCZ_CLOCK_GATE_DISABLE (1 << 30)
> -/** This bit must always be set on 965G/965GM */
> +/* This bit must always be set on 965G/965GM */
> # define I965_RCC_CLOCK_GATE_DISABLE (1 << 29)
> # define I965_RCPB_CLOCK_GATE_DISABLE(1 << 28)
> # define I965_DAP_CLOCK_GATE_DISABLE (1 << 27)
> # define I965_ROC_CLOCK_GATE_DISABLE (1 << 26)
> # define I965_GW_CLOCK_GATE_DISABLE (1 << 25)
> # define I965_TD_CLOCK_GATE_DISABLE (1 << 24)
> -/** This bit must always be set on 965G */
> +/* This bit must always be set on 965G */
> # define I965_ISC_CLOCK_GATE_DISABLE (1 << 23)
> # define I965_IC_CLOCK_GATE_DISABLE (1 << 22)
> # define I965_EU_CLOCK_GATE_DISABLE (1 << 21)
> @@ -1635,7 +1635,7 @@ enum punit_power_well {
> /* Memory controller frequency in MCHBAR for Haswell (possible SNB+) */
> #define DCLK (MCHBAR_MIRROR_BASE_SNB + 0x5e04)
>
> -/** 915-945 and GM965 MCH register controlling DRAM channel access */
> +/* 915-945 and GM965 MCH register controlling DRAM channel access */
> #define DCC 0x10200
> #define DCC_ADDRESSING_MODE_SINGLE_CHANNEL (0 << 0)
> #define DCC_ADDRESSING_MODE_DUAL_CHANNEL_ASYMMETRIC (1 << 0)
> @@ -1644,15 +1644,15 @@ enum punit_power_well {
> #define DCC_CHANNEL_XOR_DISABLE (1 << 10)
> #define DCC_CHANNEL_XOR_BIT_17 (1 << 9)
>
> -/** Pineview MCH register contains DDR3 setting */
> +/* Pineview MCH register contains DDR3 setting */
> #define CSHRDDR3CTL0x101a8
> #define CSHRDDR3CTL_DDR3 (1 << 2)
>
> -/** 965 MCH register controlling DRAM channel configuration */
> +/* 965 MCH register controlling DRAM channel configuration */
> #define C0DRB3 0x10206
> #define C1DRB3 0x10606
>
> -/** snb MCH registers for reading the DRAM channel configuration */
> +/* snb MCH registers for reading the DRAM channel configuration */
> #define MAD_DIMM_C0 (MCHBAR_MIRROR_BASE_SNB + 0x5004)
> #define MAD_DIMM_C1 (MCHBAR_MIRROR_BASE_SNB + 0x5008)
> #define MAD_DIMM_C2 (MCHBAR_MIRROR_BASE_SNB + 0x500C)
> @@ -1674,7 +1674,7 @@ enum punit_power_well {
> #define MAD_DIMM_A_SIZE_SHIFT 0
> #define MAD_DIMM_A_SIZE_MASK (0xff << MAD_DIMM_A_SIZE_SHIFT)
>
> -/** snb MCH registers for priority tuning */
> +/* snb MCH registers for priority tuning */
> #define MCH_SSKPD(MCHBAR_MIRROR_BASE_SNB + 0x5d10)
> #define MCH_SSKPD_WM0_MASK 0x3f
> #define MCH_SSKPD_WM0_VAL 0xc
> @@ -2346,7 +2346,7 @@ enum punit_power_well {
> #define SDVO_PIPE_B_SELECT (1 << 30)
> #define SDVO_STALL_SELECT (1 << 29)
> #define SDVO_INTERRUPT_ENABLE (1 << 26)
> -/**
> +/*
> * 915G/GM SDVO pixel multiplier.
> * Programmed value is multiplier - 1, up to 5x.
> * \sa DPLL_MD_UDI_MULTIPLIER_MASK
Re: [Intel-gfx] [PATCH 64/71] drm/i915/chv: Don't use PCS group access reads
On Tue, May 20, 2014 at 03:50:02PM +0200, Daniel Vetter wrote: > On Wed, Apr 09, 2014 at 07:56:50PM +0300, Ville Syrjälä wrote: > > On Wed, Apr 09, 2014 at 06:18:38PM +0200, Daniel Vetter wrote: > > > On Wed, Apr 09, 2014 at 01:29:02PM +0300, ville.syrj...@linux.intel.com > > > wrote: > > > > From: Ville Syrjälä > > > > > > > > All PCS groups access reads return 0x, so we can't use group > > > > access for RMW cycles. Instead target each spline separately. > > > > > > I have no idea what PCS means here and spline ... Can you please expand > > > for those who haven't yet lost their souls in chv docs? Just so we have a > > > commonly-understood jargon for talking about this stuff. > > > > I guess we should have that somewhere as a comment. The same terminology > > applies to VLV as well. > > Haven't seen the promised patch yet. "[PATCH] drm/i915: Add a brief description of the VLV display PHY internals" & co. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM
On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
> > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > > don't need any hacks any longer to keep the vblank logic sane when
> > > all the registers go poof. So let's rip it all out.
> >
> > Hmm. drm_update_vblank_count() will now see some kind of diff between
> > the last and current value when the registers got cloberred. So the
> > vblank counter reported to userspace will jump. But I guess that's fine
> > as long as userspace realizes that the counter is not at all reliable
> > across modesets.
>
> I've added checks for this (the rpm varianst) and for the similiar
> suspend/resume issues (the suspend variants) to kms_flip. It seems to work
> and we don't actually jump to far. But maybe the tests are horribly
> broken.
Hmm. If we can force the power well off at the start of the test and then
set a mode, I'd expect the vblank counter to jump by almost max_vblank_count
since the hw counter would appear to wrap.
>
> Can you please take a closer look? I've thought that the entire point of
> this series (well, one of them) was to finally fix this gag and avoid
> handing totally bogus frame counter values to userspace. Especially for
> system suspend/resume where userspace might get susprised ...
I was mostly interested in making vblank interrupts work during plane
enable/disable. Anything else is a bonus.
> -Daniel
>
> >
> > >
> > > This essentially undoes
> > >
> > > commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
> > > Author: Paulo Zanoni
> > > Date: Tue Jul 23 10:48:11 2013 -0300
> > >
> > > drm/i915: update last_vblank when disabling the power well
> > >
> > > Apparently igt/kms_flip is already powerful enough to exercise this
> > > properly, yay! See the reference regression report for details.
> > >
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
> > > Testcase: igt/kms_flip/*-vs-rpm
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/i915/intel_pm.c | 34 --
> > > 1 file changed, 34 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 75c1c766b507..45fa43f16bb3 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -5423,33 +5423,6 @@ static void hsw_power_well_post_enable(struct
> > > drm_i915_private *dev_priv)
> > > }
> > > }
> > >
> > > -static void reset_vblank_counter(struct drm_device *dev, enum pipe pipe)
> > > -{
> > > - assert_spin_locked(&dev->vbl_lock);
> > > -
> > > - dev->vblank[pipe].last = 0;
> > > -}
> > > -
> > > -static void hsw_power_well_post_disable(struct drm_i915_private
> > > *dev_priv)
> > > -{
> > > - struct drm_device *dev = dev_priv->dev;
> > > - enum pipe pipe;
> > > - unsigned long irqflags;
> > > -
> > > - /*
> > > - * After this, the registers on the pipes that are part of the power
> > > - * well will become zero, so we have to adjust our counters according to
> > > - * that.
> > > - *
> > > - * FIXME: Should we do this in general in drm_vblank_post_modeset?
> > > - */
> > > - spin_lock_irqsave(&dev->vbl_lock, irqflags);
> > > - for_each_pipe(pipe)
> > > - if (pipe != PIPE_A)
> > > - reset_vblank_counter(dev, pipe);
> > > - spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> > > -}
> > > -
> > > static void hsw_set_power_well(struct drm_i915_private *dev_priv,
> > > struct i915_power_well *power_well, bool enable)
> > > {
> > > @@ -5478,8 +5451,6 @@ static void hsw_set_power_well(struct
> > > drm_i915_private *dev_priv,
> > > I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
> > > POSTING_READ(HSW_PWR_WELL_DRIVER);
> > > DRM_DEBUG_KMS("Requesting to disable the power well\n");
> > > -
> > > - hsw_power_well_post_disable(dev_priv);
> > > }
> > > }
> > > }
> > > @@ -5646,11 +5617,6 @@ static void vlv_display_power_well_disable(struct
> > > drm_i915_private *dev_priv,
> > > valleyview_disable_display_irqs(dev_priv);
> > > spin_unlock_irq(&dev_priv->irq_lock);
> > >
> > > - spin_lock_irq(&dev->vbl_lock);
> > > - for_each_pipe(pipe)
> > > - reset_vblank_counter(dev, pipe);
> > > - spin_unlock_irq(&dev->vbl_lock);
> > > -
> > > vlv_set_power_well(dev_priv, power_well, false);
> > > }
> > >
> > > --
> > > 1.8.3.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel OTC
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Ville Syrjälä
Intel OTC
Re: [Intel-gfx] [PATCH 43/71] drm/i915/chv: Add a bunch of pre production workarounds
On Tue, May 20, 2014 at 04:41:13PM +0300, Ville Syrjälä wrote: > On Tue, May 20, 2014 at 02:22:51PM +0100, Damien Lespiau wrote: > > On Wed, Apr 09, 2014 at 01:28:41PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > The following workarounds should be needed for pre-production hardware > > > only: > > > * WaDisablePwrmtrEvent:chv > > > * WaSetMaskForGfxBusyness:chv > > > * WaDisableGunitClockGating:chv > > > * WaDisableFfDopClockGating:chv > > > * WaDisableDopClockGating:chv > > > > > > Signed-off-by: Ville Syrjälä > > > > What about that hunk? > > > > > + I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) | > > > +GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE); > > > > I couldn't find a W/A in the db nor in BSpec. The rest looks good > > though. > > It was mentioned in the hsd for the WaDisableDopClockGating w/a. I think > we already merged the same w/a for bdw but without the tcunit bit even > though I had questioned the fate of the tcunit bit during review. Reviewed-by: Damien Lespiau -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
Date 20.5.2014 14:43, Thierry Reding wrote: > On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote: >> Also adding dri-devel and linux-media. Please don't forget these lists for >> the next round. >> -Daniel >> >> On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote: >>> Adding Greg just as an fyi since we've chatted briefly about the avsink >>> bus. Comments below. >>> -Daniel >>> >>> On Tue, May 20, 2014 at 02:52:19AM +, Lin, Mengdong wrote: This RFC is based on previous discussion to set up a generic communication channel between display and audio driver and an internal design of Intel MCG/VPG HDMI audio driver. It's still an initial draft and your advice would be appreciated to improve the design. The basic idea is to create a new avsink module and let both drm and alsa depend on it. This new module provides a framework and APIs for synchronization between the display and audio driver. 1. Display/Audio Client The avsink core provides APIs to create, register and lookup a display/audio client. A specific display driver (eg. i915) or audio driver (eg. HD-Audio driver) can create a client, add some resources objects (shared power wells, display outputs, and audio inputs, register ops) to the client, and then register this client to avisink core. The peer driver can look up a registered client by a name or type, or both. If a client gives a valid peer client name on registration, avsink core will bind the two clients as peer for each other. And we expect a display client and an audio client to be peers for each other in a system. int avsink_new_client ( const char *name, int type, /* client type, display or audio */ struct module *module, void *context, const char *peer_name, struct avsink_client **client_ret); int avsink_free_client (struct avsink_client *client); >>> >>> >>> Hm, my idea was to create a new avsink bus and let vga drivers register >>> devices on that thing and audio drivers register as drivers. There's a bit >>> more work involved in creating a full-blown bus, but it has a lot of >>> upsides: >>> - Established infrastructure for matching drivers (i.e. audio drivers) >>> against devices (i.e. avsinks exported by gfx drivers). >>> - Module refcounting. >>> - power domain handling and well-integrated into runtime pm. >>> - Allows integration into componentized device framework since we're >>> dealing with a real struct device. >>> - Better decoupling between gfx and audio side since registration is done >>> at runtime. >>> - We can attach drv private date which the audio driver needs. > > I think this would be another case where the interface framework[0] > could potentially be used. It doesn't give you all of the above, but > there's no reason it couldn't be extended. Then again, adding too much > would end up duplicating more of the driver core, so if something really > heavy-weight is required here, then the interface framework is not the > best option. > > [0]: https://lkml.org/lkml/2014/5/13/525 This looks like the right direction. I would go in this way rather than create specific A/V grouping mechanisms. This seems to be applicable to more use cases. Jaroslav -- Jaroslav Kysela Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 64/71] drm/i915/chv: Don't use PCS group access reads
On Wed, Apr 09, 2014 at 07:56:50PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 09, 2014 at 06:18:38PM +0200, Daniel Vetter wrote:
> > On Wed, Apr 09, 2014 at 01:29:02PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > All PCS groups access reads return 0x, so we can't use group
> > > access for RMW cycles. Instead target each spline separately.
> >
> > I have no idea what PCS means here and spline ... Can you please expand
> > for those who haven't yet lost their souls in chv docs? Just so we have a
> > commonly-understood jargon for talking about this stuff.
>
> I guess we should have that somewhere as a comment. The same terminology
> applies to VLV as well.
Haven't seen the promised patch yet.
-Daniel
>
> >
> > Thanks, Daniel
> >
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 14 ++
> > > drivers/gpu/drm/i915/intel_dp.c | 32
> > > drivers/gpu/drm/i915/intel_hdmi.c | 34 +-
> > > 3 files changed, 63 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 4617fb3..ffed03e 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -654,6 +654,13 @@ enum punit_power_well {
> > > #define DPIO_PCS_TX_LANE1_RESET(1<<7)
> > > #define VLV_PCS_DW0(ch) _PORT(ch, _VLV_PCS_DW0_CH0, _VLV_PCS_DW0_CH1)
> > >
> > > +#define _VLV_PCS01_DW0_CH0 0x200
> > > +#define _VLV_PCS23_DW0_CH0 0x400
> > > +#define _VLV_PCS01_DW0_CH1 0x2600
> > > +#define _VLV_PCS23_DW0_CH1 0x2800
> > > +#define VLV_PCS01_DW0(ch) _PORT(ch, _VLV_PCS01_DW0_CH0,
> > > _VLV_PCS01_DW0_CH1)
> > > +#define VLV_PCS23_DW0(ch) _PORT(ch, _VLV_PCS23_DW0_CH0,
> > > _VLV_PCS23_DW0_CH1)
> > > +
> > > #define _VLV_PCS_DW1_CH0 0x8204
> > > #define _VLV_PCS_DW1_CH1 0x8404
> > > #define CHV_PCS_REQ_SOFTRESET_EN (1<<23)
> > > @@ -663,6 +670,13 @@ enum punit_power_well {
> > > #define DPIO_PCS_CLK_SOFT_RESET(1<<5)
> > > #define VLV_PCS_DW1(ch) _PORT(ch, _VLV_PCS_DW1_CH0, _VLV_PCS_DW1_CH1)
> > >
> > > +#define _VLV_PCS01_DW1_CH0 0x204
> > > +#define _VLV_PCS23_DW1_CH0 0x404
> > > +#define _VLV_PCS01_DW1_CH1 0x2604
> > > +#define _VLV_PCS23_DW1_CH1 0x2804
> > > +#define VLV_PCS01_DW1(ch) _PORT(ch, _VLV_PCS01_DW1_CH0,
> > > _VLV_PCS01_DW1_CH1)
> > > +#define VLV_PCS23_DW1(ch) _PORT(ch, _VLV_PCS23_DW1_CH0,
> > > _VLV_PCS23_DW1_CH1)
> > > +
> > > #define _VLV_PCS_DW8_CH0 0x8220
> > > #define _VLV_PCS_DW8_CH1 0x8420
> > > #define VLV_PCS_DW8(ch) _PORT(ch, _VLV_PCS_DW8_CH0, _VLV_PCS_DW8_CH1)
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 079e0e3..cc7bccd3 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1845,13 +1845,21 @@ static void chv_post_disable_dp(struct
> > > intel_encoder *encoder)
> > > mutex_lock(&dev_priv->dpio_lock);
> > >
> > > /* Propagate soft reset to data lane reset */
> > > - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS_DW1(ch));
> > > + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
> > > val |= CHV_PCS_REQ_SOFTRESET_EN;
> > > - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(ch), val);
> > > + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
> > >
> > > - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS_DW0(ch));
> > > + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
> > > + val |= CHV_PCS_REQ_SOFTRESET_EN;
> > > + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
> > > +
> > > + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
> > > + val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
> > > + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
> > > +
> > > + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> > > val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
> > > - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(ch), val);
> > > + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
> > >
> > > mutex_unlock(&dev_priv->dpio_lock);
> > > }
> > > @@ -1983,13 +1991,21 @@ static void chv_pre_enable_dp(struct
> > > intel_encoder *encoder)
> > > mutex_lock(&dev_priv->dpio_lock);
> > >
> > > /* Deassert soft data lane reset*/
> > > - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS_DW1(ch));
> > > + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
> > > val |= CHV_PCS_REQ_SOFTRESET_EN;
> > > - vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(ch), val);
> > > + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
> > > +
> > > + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
> > > + val |= CHV_PCS_REQ_SOFTRESET_EN;
> > > + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_D
Re: [Intel-gfx] [PATCH 43/71] drm/i915/chv: Add a bunch of pre production workarounds
On Tue, May 20, 2014 at 02:22:51PM +0100, Damien Lespiau wrote:
> On Wed, Apr 09, 2014 at 01:28:41PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The following workarounds should be needed for pre-production hardware
> > only:
> > * WaDisablePwrmtrEvent:chv
> > * WaSetMaskForGfxBusyness:chv
> > * WaDisableGunitClockGating:chv
> > * WaDisableFfDopClockGating:chv
> > * WaDisableDopClockGating:chv
> >
> > Signed-off-by: Ville Syrjälä
>
> What about that hunk?
>
> > + I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
> > + GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE);
>
> I couldn't find a W/A in the db nor in BSpec. The rest looks good
> though.
It was mentioned in the hsd for the WaDisableDopClockGating w/a. I think
we already merged the same w/a for bdw but without the tcunit bit even
though I had questioned the fate of the tcunit bit during review.
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 3 +++
> > drivers/gpu/drm/i915/intel_pm.c | 20 +++-
> > 2 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index ac5047b..7587752 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1024,6 +1024,7 @@ enum punit_power_well {
> > #define IMR0x020a8
> > #define ISR0x020ac
> > #define VLV_GUNIT_CLOCK_GATE (VLV_DISPLAY_BASE + 0x2060)
> > +#define GINT_DIS (1<<22)
> > #define GCFG_DIS (1<<8)
> > #define VLV_IIR_RW (VLV_DISPLAY_BASE + 0x2084)
> > #define VLV_IER(VLV_DISPLAY_BASE + 0x20a0)
> > @@ -1154,6 +1155,7 @@ enum punit_power_well {
> >
> > #define GEN6_RC_SLEEP_PSMI_CONTROL 0x2050
> > #define GEN8_RC_SEMA_IDLE_MSG_DISABLE(1 << 12)
> > +#define GEN8_FF_DOP_CLOCK_GATE_DISABLE (1<<10)
> >
> > #define GEN6_BSD_SLEEP_PSMI_CONTROL0x12050
> > #define GEN6_BSD_SLEEP_MSG_DISABLE (1 << 0)
> > @@ -5186,6 +5188,7 @@ enum punit_power_well {
> > #define HSW_EDRAM_PRESENT 0x120010
> >
> > #define GEN6_UCGCTL1 0x9400
> > +# define GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE (1 << 16)
> > # define GEN6_BLBUNIT_CLOCK_GATE_DISABLE (1 << 5)
> > # define GEN6_CSUNIT_CLOCK_GATE_DISABLE(1 << 7)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 60f876c..587d32f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3775,10 +3775,14 @@ static void cherryview_enable_rps(struct drm_device
> > *dev)
> >
> > I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
> >
> > + /* WaDisablePwrmtrEvent:chv (pre-production hw) */
> > + I915_WRITE(0xA80C, I915_READ(0xA80C) & 0x00ff);
> > + I915_WRITE(0xA810, I915_READ(0xA810) & 0xff00);
> > +
> > /* 5: Enable RPS */
> > I915_WRITE(GEN6_RP_CONTROL,
> >GEN6_RP_MEDIA_HW_NORMAL_MODE |
> > - GEN6_RP_MEDIA_IS_GFX |
> > + GEN6_RP_MEDIA_IS_GFX | /* WaSetMaskForGfxBusyness:chv
> > (pre-production hw ?) */
> >GEN6_RP_ENABLE |
> >GEN6_RP_UP_BUSY_AVG |
> >GEN6_RP_DOWN_IDLE_AVG);
> > @@ -5409,6 +5413,20 @@ static void cherryview_init_clock_gating(struct
> > drm_device *dev)
> > /* WaDisableSamplerPowerBypass:chv (pre-production hw) */
> > I915_WRITE(HALF_SLICE_CHICKEN3,
> >_MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS));
> > +
> > + /* WaDisableGunitClockGating:chv (pre-production hw) */
> > + I915_WRITE(VLV_GUNIT_CLOCK_GATE, I915_READ(VLV_GUNIT_CLOCK_GATE) |
> > + GINT_DIS);
> > +
> > + /* WaDisableFfDopClockGating:chv (pre-production hw) */
> > + I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
> > + _MASKED_BIT_ENABLE(GEN8_FF_DOP_CLOCK_GATE_DISABLE));
> > +
> > + /* WaDisableDopClockGating:chv (pre-production hw) */
> > + I915_WRITE(GEN7_ROW_CHICKEN2,
> > + _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
> > + I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
> > + GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE);
> > }
> >
> > static void g4x_init_clock_gating(struct drm_device *dev)
> > --
> > 1.8.3.2
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM
On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
> On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > don't need any hacks any longer to keep the vblank logic sane when
> > all the registers go poof. So let's rip it all out.
>
> Hmm. drm_update_vblank_count() will now see some kind of diff between
> the last and current value when the registers got cloberred. So the
> vblank counter reported to userspace will jump. But I guess that's fine
> as long as userspace realizes that the counter is not at all reliable
> across modesets.
I've added checks for this (the rpm varianst) and for the similiar
suspend/resume issues (the suspend variants) to kms_flip. It seems to work
and we don't actually jump to far. But maybe the tests are horribly
broken.
Can you please take a closer look? I've thought that the entire point of
this series (well, one of them) was to finally fix this gag and avoid
handing totally bogus frame counter values to userspace. Especially for
system suspend/resume where userspace might get susprised ...
-Daniel
>
> >
> > This essentially undoes
> >
> > commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
> > Author: Paulo Zanoni
> > Date: Tue Jul 23 10:48:11 2013 -0300
> >
> > drm/i915: update last_vblank when disabling the power well
> >
> > Apparently igt/kms_flip is already powerful enough to exercise this
> > properly, yay! See the reference regression report for details.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
> > Testcase: igt/kms_flip/*-vs-rpm
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 34 --
> > 1 file changed, 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 75c1c766b507..45fa43f16bb3 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5423,33 +5423,6 @@ static void hsw_power_well_post_enable(struct
> > drm_i915_private *dev_priv)
> > }
> > }
> >
> > -static void reset_vblank_counter(struct drm_device *dev, enum pipe pipe)
> > -{
> > - assert_spin_locked(&dev->vbl_lock);
> > -
> > - dev->vblank[pipe].last = 0;
> > -}
> > -
> > -static void hsw_power_well_post_disable(struct drm_i915_private *dev_priv)
> > -{
> > - struct drm_device *dev = dev_priv->dev;
> > - enum pipe pipe;
> > - unsigned long irqflags;
> > -
> > - /*
> > -* After this, the registers on the pipes that are part of the power
> > -* well will become zero, so we have to adjust our counters according to
> > -* that.
> > -*
> > -* FIXME: Should we do this in general in drm_vblank_post_modeset?
> > -*/
> > - spin_lock_irqsave(&dev->vbl_lock, irqflags);
> > - for_each_pipe(pipe)
> > - if (pipe != PIPE_A)
> > - reset_vblank_counter(dev, pipe);
> > - spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> > -}
> > -
> > static void hsw_set_power_well(struct drm_i915_private *dev_priv,
> >struct i915_power_well *power_well, bool enable)
> > {
> > @@ -5478,8 +5451,6 @@ static void hsw_set_power_well(struct
> > drm_i915_private *dev_priv,
> > I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
> > POSTING_READ(HSW_PWR_WELL_DRIVER);
> > DRM_DEBUG_KMS("Requesting to disable the power well\n");
> > -
> > - hsw_power_well_post_disable(dev_priv);
> > }
> > }
> > }
> > @@ -5646,11 +5617,6 @@ static void vlv_display_power_well_disable(struct
> > drm_i915_private *dev_priv,
> > valleyview_disable_display_irqs(dev_priv);
> > spin_unlock_irq(&dev_priv->irq_lock);
> >
> > - spin_lock_irq(&dev->vbl_lock);
> > - for_each_pipe(pipe)
> > - reset_vblank_counter(dev, pipe);
> > - spin_unlock_irq(&dev->vbl_lock);
> > -
> > vlv_set_power_well(dev_priv, power_well, false);
> > }
> >
> > --
> > 1.8.3.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 51/71] drm/i915/chv: Use valleyview_pipestat_irq_handler() for CHV
On Wed, Apr 09, 2014 at 01:28:49PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 91
> -
> 1 file changed, 17 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 9c18a47..9702fde 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1660,6 +1660,9 @@ static void valleyview_pipestat_irq_handler(struct
> drm_device *dev, u32 iir)
> case PIPE_B:
> iir_bit = I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
> break;
> + case PIPE_C:
> + iir_bit = I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
> + break;
> }
> if (iir & iir_bit)
> mask |= dev_priv->pipestat_irq_mask[pipe];
> @@ -1771,87 +1774,32 @@ static irqreturn_t cherryview_irq_handler(int irq,
> void *arg)
> drm_i915_private_t *dev_priv = dev->dev_private;
> u32 master_ctl, iir;
> irqreturn_t ret = IRQ_NONE;
> - unsigned int pipes = 0;
> -
> - master_ctl = I915_READ(GEN8_MASTER_IRQ);
> -
> - I915_WRITE(GEN8_MASTER_IRQ, 0);
> -
> - ret = gen8_gt_irq_handler(dev, dev_priv, master_ctl);
>
> + master_ctl = I915_READ(GEN8_MASTER_IRQ) & ~DE_MASTER_IRQ_CONTROL;
> iir = I915_READ(VLV_IIR);
>
> - if (iir & (I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT |
> I915_DISPLAY_PIPE_A_EVENT_INTERRUPT))
> - pipes |= 1 << 0;
> - if (iir & (I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT |
> I915_DISPLAY_PIPE_B_EVENT_INTERRUPT))
> - pipes |= 1 << 1;
> - if (iir & (I915_DISPLAY_PIPE_C_VBLANK_INTERRUPT |
> I915_DISPLAY_PIPE_C_EVENT_INTERRUPT))
> - pipes |= 1 << 2;
> -
> - if (pipes) {
> - u32 pipe_stats[I915_MAX_PIPES] = {};
> - unsigned long irqflags;
> - int pipe;
> -
> - spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> - for_each_pipe(pipe) {
> - unsigned int reg;
> -
> - if (!(pipes & (1 << pipe)))
> - continue;
> -
> - reg = PIPESTAT(pipe);
> - pipe_stats[pipe] = I915_READ(reg);
> -
> - /*
> - * Clear the PIPE*STAT regs before the IIR
> - */
> - if (pipe_stats[pipe] & 0x8000) {
> - if (pipe_stats[pipe] &
> PIPE_FIFO_UNDERRUN_STATUS)
> - DRM_DEBUG_DRIVER("pipe %c underrun\n",
> - pipe_name(pipe));
> - I915_WRITE(reg, pipe_stats[pipe]);
> - }
> - }
> - spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> -
> - for_each_pipe(pipe) {
> - if (pipe_stats[pipe] & PIPE_VBLANK_INTERRUPT_STATUS)
> - drm_handle_vblank(dev, pipe);
> + if (master_ctl == 0 && iir == 0)
> + return IRQ_NONE;
>
> - if (pipe_stats[pipe] & PLANE_FLIP_DONE_INT_STATUS_VLV) {
> - intel_prepare_page_flip(dev, pipe);
> - intel_finish_page_flip(dev, pipe);
> - }
> - }
> + I915_WRITE(GEN8_MASTER_IRQ, 0);
>
> - if (pipe_stats[0] & PIPE_GMBUS_INTERRUPT_STATUS)
> - gmbus_irq_handler(dev);
> + gen8_gt_irq_handler(dev, dev_priv, master_ctl);
>
> - ret = IRQ_HANDLED;
> - }
> + valleyview_pipestat_irq_handler(dev, iir);
>
> /* Consume port. Then clear IIR or we'll miss events */
> if (iir & I915_DISPLAY_PORT_INTERRUPT) {
> - u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
> -
> - I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
> -
> - DRM_DEBUG_DRIVER("hotplug event received, stat 0x%08x\n",
> - hotplug_status);
> - if (hotplug_status & HOTPLUG_INT_STATUS_I915)
> - queue_work(dev_priv->wq,
> -&dev_priv->hotplug_work);
> -
> + i9xx_hpd_irq_handler(dev, iir);
Fun conflict here - my version of i9xx_hpd_irq_handler doesn't want an iir
argument. Please sanity-check, thanks.
-Daniel
> ret = IRQ_HANDLED;
> }
>
> -
> I915_WRITE(VLV_IIR, iir);
>
> I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
> POSTING_READ(GEN8_MASTER_IRQ);
>
> + ret = IRQ_HANDLED;
> +
> return ret;
> }
>
> @@ -3526,12 +3474,10 @@ static int cherryview_irq_postinstall(struct
> drm_device *dev)
> drm_i915_private_t *dev_priv = dev->dev_private;
> u32 enable_mask = I915_DISPLAY_PORT_I
Re: [Intel-gfx] [PATCH 52/71] drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed
On Wed, Apr 09, 2014 at 01:28:50PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Same cautious note about conflicts here ...
-Daniel
> ---
> drivers/gpu/drm/i915/i915_irq.c | 29 ++---
> 1 file changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 9702fde..fc9b7e6 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1775,30 +1775,29 @@ static irqreturn_t cherryview_irq_handler(int irq,
> void *arg)
> u32 master_ctl, iir;
> irqreturn_t ret = IRQ_NONE;
>
> - master_ctl = I915_READ(GEN8_MASTER_IRQ) & ~DE_MASTER_IRQ_CONTROL;
> - iir = I915_READ(VLV_IIR);
> + for (;;) {
> + master_ctl = I915_READ(GEN8_MASTER_IRQ) &
> ~GEN8_MASTER_IRQ_CONTROL;
> + iir = I915_READ(VLV_IIR);
>
> - if (master_ctl == 0 && iir == 0)
> - return IRQ_NONE;
> + if (master_ctl == 0 && iir == 0)
> + break;
>
> - I915_WRITE(GEN8_MASTER_IRQ, 0);
> + I915_WRITE(GEN8_MASTER_IRQ, 0);
>
> - gen8_gt_irq_handler(dev, dev_priv, master_ctl);
> + gen8_gt_irq_handler(dev, dev_priv, master_ctl);
>
> - valleyview_pipestat_irq_handler(dev, iir);
> + valleyview_pipestat_irq_handler(dev, iir);
>
> - /* Consume port. Then clear IIR or we'll miss events */
> - if (iir & I915_DISPLAY_PORT_INTERRUPT) {
> + /* Consume port. Then clear IIR or we'll miss events */
> i9xx_hpd_irq_handler(dev, iir);
> - ret = IRQ_HANDLED;
> - }
>
> - I915_WRITE(VLV_IIR, iir);
> + I915_WRITE(VLV_IIR, iir);
>
> - I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
> - POSTING_READ(GEN8_MASTER_IRQ);
> + I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
> + POSTING_READ(GEN8_MASTER_IRQ);
>
> - ret = IRQ_HANDLED;
> + ret = IRQ_HANDLED;
> + }
>
> return ret;
> }
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 43/71] drm/i915/chv: Add a bunch of pre production workarounds
On Wed, Apr 09, 2014 at 01:28:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The following workarounds should be needed for pre-production hardware
> only:
> * WaDisablePwrmtrEvent:chv
> * WaSetMaskForGfxBusyness:chv
> * WaDisableGunitClockGating:chv
> * WaDisableFfDopClockGating:chv
> * WaDisableDopClockGating:chv
>
> Signed-off-by: Ville Syrjälä
What about that hunk?
> + I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
> +GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE);
I couldn't find a W/A in the db nor in BSpec. The rest looks good
though.
--
Damien
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 20 +++-
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ac5047b..7587752 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1024,6 +1024,7 @@ enum punit_power_well {
> #define IMR 0x020a8
> #define ISR 0x020ac
> #define VLV_GUNIT_CLOCK_GATE (VLV_DISPLAY_BASE + 0x2060)
> +#define GINT_DIS (1<<22)
> #define GCFG_DIS (1<<8)
> #define VLV_IIR_RW (VLV_DISPLAY_BASE + 0x2084)
> #define VLV_IER (VLV_DISPLAY_BASE + 0x20a0)
> @@ -1154,6 +1155,7 @@ enum punit_power_well {
>
> #define GEN6_RC_SLEEP_PSMI_CONTROL 0x2050
> #define GEN8_RC_SEMA_IDLE_MSG_DISABLE (1 << 12)
> +#define GEN8_FF_DOP_CLOCK_GATE_DISABLE (1<<10)
>
> #define GEN6_BSD_SLEEP_PSMI_CONTROL 0x12050
> #define GEN6_BSD_SLEEP_MSG_DISABLE (1 << 0)
> @@ -5186,6 +5188,7 @@ enum punit_power_well {
> #define HSW_EDRAM_PRESENT 0x120010
>
> #define GEN6_UCGCTL1 0x9400
> +# define GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE (1 << 16)
> # define GEN6_BLBUNIT_CLOCK_GATE_DISABLE (1 << 5)
> # define GEN6_CSUNIT_CLOCK_GATE_DISABLE (1 << 7)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 60f876c..587d32f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3775,10 +3775,14 @@ static void cherryview_enable_rps(struct drm_device
> *dev)
>
> I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
>
> + /* WaDisablePwrmtrEvent:chv (pre-production hw) */
> + I915_WRITE(0xA80C, I915_READ(0xA80C) & 0x00ff);
> + I915_WRITE(0xA810, I915_READ(0xA810) & 0xff00);
> +
> /* 5: Enable RPS */
> I915_WRITE(GEN6_RP_CONTROL,
> GEN6_RP_MEDIA_HW_NORMAL_MODE |
> -GEN6_RP_MEDIA_IS_GFX |
> +GEN6_RP_MEDIA_IS_GFX | /* WaSetMaskForGfxBusyness:chv
> (pre-production hw ?) */
> GEN6_RP_ENABLE |
> GEN6_RP_UP_BUSY_AVG |
> GEN6_RP_DOWN_IDLE_AVG);
> @@ -5409,6 +5413,20 @@ static void cherryview_init_clock_gating(struct
> drm_device *dev)
> /* WaDisableSamplerPowerBypass:chv (pre-production hw) */
> I915_WRITE(HALF_SLICE_CHICKEN3,
> _MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS));
> +
> + /* WaDisableGunitClockGating:chv (pre-production hw) */
> + I915_WRITE(VLV_GUNIT_CLOCK_GATE, I915_READ(VLV_GUNIT_CLOCK_GATE) |
> +GINT_DIS);
> +
> + /* WaDisableFfDopClockGating:chv (pre-production hw) */
> + I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
> +_MASKED_BIT_ENABLE(GEN8_FF_DOP_CLOCK_GATE_DISABLE));
> +
> + /* WaDisableDopClockGating:chv (pre-production hw) */
> + I915_WRITE(GEN7_ROW_CHICKEN2,
> +_MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
> + I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
> +GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE);
> }
>
> static void g4x_init_clock_gating(struct drm_device *dev)
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 49/71] drm/i915/chv: Add CHV display support
On Mon, Apr 28, 2014 at 02:00:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Rafael Barbalho
>
> Add support for the third pipe in cherrview
>
> v2: Don't use spaces for indentation (Jani)
> Wrap long lines
>
> Reviewed-by: Imre Deak
> Signed-off-by: Rafael Barbalho
> [vsyrjala: slightly massaged the patch]
> Signed-off-by: Ville Syrjälä
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 12
> drivers/gpu/drm/i915/i915_reg.h | 11 ---
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3f57237..0fd3046 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -49,6 +49,17 @@ static struct drm_driver driver;
> .dpll_md_offsets = { DPLL_A_MD_OFFSET, DPLL_B_MD_OFFSET }, \
> .palette_offsets = { PALETTE_A_OFFSET, PALETTE_B_OFFSET }
>
> +#define GEN_CHV_PIPEOFFSETS \
> + .pipe_offsets = { PIPE_A_OFFSET, PIPE_B_OFFSET, \
> + CHV_PIPE_C_OFFSET }, \
> + .trans_offsets = { TRANSCODER_A_OFFSET, TRANSCODER_B_OFFSET, \
> +CHV_TRANSCODER_C_OFFSET, }, \
> + .dpll_offsets = { DPLL_A_OFFSET, DPLL_B_OFFSET, \
> + CHV_DPLL_C_OFFSET }, \
> + .dpll_md_offsets = { DPLL_A_MD_OFFSET, DPLL_B_MD_OFFSET, \
> + CHV_DPLL_C_MD_OFFSET }, \
> + .palette_offsets = { PALETTE_A_OFFSET, PALETTE_B_OFFSET, \
> + CHV_PALETTE_C_OFFSET }
>
> static const struct intel_device_info intel_i830_info = {
> .gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
> @@ -286,6 +297,7 @@ static const struct intel_device_info
> intel_cherryview_info = {
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> .is_valleyview = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> + GEN_CHV_PIPEOFFSETS,
> };
>
> /*
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 74ac1c2..9138eff 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1440,6 +1440,7 @@ enum punit_power_well {
> */
> #define DPLL_A_OFFSET 0x6014
> #define DPLL_B_OFFSET 0x6018
> +#define CHV_DPLL_C_OFFSET 0x6030
> #define DPLL(pipe) (dev_priv->info.dpll_offsets[pipe] + \
> dev_priv->info.display_mmio_offset)
>
> @@ -1531,6 +1532,7 @@ enum punit_power_well {
>
> #define DPLL_A_MD_OFFSET 0x601c /* 965+ only */
> #define DPLL_B_MD_OFFSET 0x6020 /* 965+ only */
> +#define CHV_DPLL_C_MD_OFFSET 0x603c
> #define DPLL_MD(pipe) (dev_priv->info.dpll_md_offsets[pipe] + \
> dev_priv->info.display_mmio_offset)
>
> @@ -1727,6 +1729,7 @@ enum punit_power_well {
> */
> #define PALETTE_A_OFFSET 0xa000
> #define PALETTE_B_OFFSET 0xa800
> +#define CHV_PALETTE_C_OFFSET 0xc000
> #define PALETTE(pipe) (dev_priv->info.palette_offsets[pipe] + \
> dev_priv->info.display_mmio_offset)
>
> @@ -2216,6 +2219,7 @@ enum punit_power_well {
> #define TRANSCODER_A_OFFSET 0x6
> #define TRANSCODER_B_OFFSET 0x61000
> #define TRANSCODER_C_OFFSET 0x62000
> +#define CHV_TRANSCODER_C_OFFSET 0x63000
> #define TRANSCODER_EDP_OFFSET 0x6f000
>
> #define _TRANSCODER2(pipe, reg) (dev_priv->info.trans_offsets[(pipe)] - \
> @@ -3543,9 +3547,10 @@ enum punit_power_well {
> #define PIPESTAT_INT_ENABLE_MASK 0x7fff
> #define PIPESTAT_INT_STATUS_MASK 0x
>
> -#define PIPE_A_OFFSET0x7
> -#define PIPE_B_OFFSET0x71000
> -#define PIPE_C_OFFSET0x72000
> +#define PIPE_A_OFFSET0x7
> +#define PIPE_B_OFFSET0x71000
> +#define PIPE_C_OFFSET0x72000
> +#define CHV_PIPE_C_OFFSET0x74000
> /*
> * There's actually no pipe EDP. Some pipe registers have
> * simply shifted from the pipe to the transcoder, while
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 42/71] drm/i915/chv: Implement WaDisableSamplerPowerBypass for CHV
On Mon, Apr 28, 2014 at 07:19:50PM -0300, Paulo Zanoni wrote: > 2014-04-28 5:23 GMT-03:00 Ville Syrjälä : > > On Fri, Apr 25, 2014 at 05:55:38PM -0300, Paulo Zanoni wrote: > >> 2014-04-09 7:28 GMT-03:00 : > >> > From: Rafael Barbalho > >> > > >> > Cherryview also needs this WA. > >> > >> At least on the chv_rebase tree, this WA is implemented for BDW but it > >> is not documented as pre-prod only, and its name is not there. We > >> should probably add a comment documenting the name and the fact that > >> it is also pre-prod on BDW. > > > > IIRC BDW will need it even on production steppings. > > Hmmm the register documentation says one thing while the WA lists say > others... I'll let you discover which one is correct :) > > > > > I think I have a patch somewhere that add the w/a note for BDW, but I guess > > I didn't post it yet. > > > >> > >> > >> > > >> > Signed-off-by: Rafael Barbalho > >> > [vsyrjala: Looks like it's for pre-prodution hw only] > >> > Signed-off-by: Ville Syrjälä > >> > --- > >> > drivers/gpu/drm/i915/intel_pm.c | 4 > >> > 1 file changed, 4 insertions(+) > >> > > >> > diff --git a/drivers/gpu/drm/i915/intel_pm.c > >> > b/drivers/gpu/drm/i915/intel_pm.c > >> > index 468fe37..60f876c 100644 > >> > --- a/drivers/gpu/drm/i915/intel_pm.c > >> > +++ b/drivers/gpu/drm/i915/intel_pm.c > >> > @@ -5405,6 +5405,10 @@ static void cherryview_init_clock_gating(struct > >> > drm_device *dev) > >> > /* WaDisableSDEUnitClockGating:chv */ > >> > I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) | > >> >GEN8_SDEUNIT_CLOCK_GATE_DISABLE); > >> > + > >> > + /* WaDisableSamplerPowerBypass:chv (pre-production hw) */ > >> > + I915_WRITE(HALF_SLICE_CHICKEN3, > >> > + _MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS)); > >> > >> I could not find information anywhere if this is the correct > >> implementation. Can you please provide me pointers to the doc you > >> used? The links on Collab seem broken. > > > > Just w/a database + bspec are enough for this one. > > Found it :) > > Reviewed-by: Paulo Zanoni Merged up to this patch (except for the rps patches). -Daniel > > > > >> > >> Thanks, > >> Paulo > >> > >> > } > >> > > >> > static void g4x_init_clock_gating(struct drm_device *dev) > >> > -- > >> > 1.8.3.2 > >> > > >> > ___ > >> > Intel-gfx mailing list > >> > Intel-gfx@lists.freedesktop.org > >> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > >> > >> > >> > >> -- > >> Paulo Zanoni > > > > -- > > Ville Syrjälä > > Intel OTC > > > > -- > Paulo Zanoni > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 38/66] drm/i915: s/ironlake_/intel_ for the enable_share_dpll function
On Tue, May 20, 2014 at 11:29:54AM +0100, Damien Lespiau wrote:
> On Thu, Apr 24, 2014 at 11:55:14PM +0200, Daniel Vetter wrote:
> > Besides the fairly useless BUG_ON the logic is completely generic
> > and cane be used on any platform what wants to reuse the shared
> > dpll support code.
> >
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Damien Lespiau
Queued up to this patch, thanks everyone for the review.
-Daniel
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 96bab640399f..1513d9fceebe 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1568,21 +1568,19 @@ static void intel_prepare_shared_dpll(struct
> > intel_crtc *crtc)
> > }
> >
> > /**
> > - * ironlake_enable_shared_dpll - enable PCH PLL
> > + * intel_enable_shared_dpll - enable PCH PLL
> > * @dev_priv: i915 private structure
> > * @pipe: pipe PLL to enable
> > *
> > * The PCH PLL needs to be enabled before the PCH transcoder, since it
> > * drives the transcoder clock.
> > */
> > -static void ironlake_enable_shared_dpll(struct intel_crtc *crtc)
> > +static void intel_enable_shared_dpll(struct intel_crtc *crtc)
> > {
> > struct drm_device *dev = crtc->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(crtc);
> >
> > - /* PCH PLLs only available on ILK, SNB and IVB */
> > - BUG_ON(INTEL_INFO(dev)->gen < 5);
> > if (WARN_ON(pll == NULL))
> > return;
> >
> > @@ -3328,7 +3326,7 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
> > * Note that enable_shared_dpll tries to do the right thing, but
> > * get_shared_dpll unconditionally resets the pll - we need that to have
> > * the right LVDS enable sequence. */
> > - ironlake_enable_shared_dpll(intel_crtc);
> > + intel_enable_shared_dpll(intel_crtc);
> >
> > /* set transcoder timing, panel must allow it */
> > assert_panel_unlocked(dev_priv, pipe);
> > --
> > 1.8.1.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote:
> Also adding dri-devel and linux-media. Please don't forget these lists for
> the next round.
> -Daniel
>
> On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
> > Adding Greg just as an fyi since we've chatted briefly about the avsink
> > bus. Comments below.
> > -Daniel
> >
> > On Tue, May 20, 2014 at 02:52:19AM +, Lin, Mengdong wrote:
> > > This RFC is based on previous discussion to set up a generic
> > > communication channel between display and audio driver and
> > > an internal design of Intel MCG/VPG HDMI audio driver. It's still an
> > > initial draft and your advice would be appreciated
> > > to improve the design.
> > >
> > > The basic idea is to create a new avsink module and let both drm and alsa
> > > depend on it.
> > > This new module provides a framework and APIs for synchronization between
> > > the display and audio driver.
> > >
> > > 1. Display/Audio Client
> > >
> > > The avsink core provides APIs to create, register and lookup a
> > > display/audio client.
> > > A specific display driver (eg. i915) or audio driver (eg. HD-Audio
> > > driver) can create a client, add some resources
> > > objects (shared power wells, display outputs, and audio inputs, register
> > > ops) to the client, and then register this
> > > client to avisink core. The peer driver can look up a registered client
> > > by a name or type, or both. If a client gives
> > > a valid peer client name on registration, avsink core will bind the two
> > > clients as peer for each other. And we
> > > expect a display client and an audio client to be peers for each other in
> > > a system.
> > >
> > > int avsink_new_client ( const char *name,
> > > int type, /* client type, display or audio
> > > */
> > > struct module *module,
> > > void *context,
> > > const char *peer_name,
> > > struct avsink_client **client_ret);
> > >
> > > int avsink_free_client (struct avsink_client *client);
> >
> >
> > Hm, my idea was to create a new avsink bus and let vga drivers register
> > devices on that thing and audio drivers register as drivers. There's a bit
> > more work involved in creating a full-blown bus, but it has a lot of
> > upsides:
> > - Established infrastructure for matching drivers (i.e. audio drivers)
> > against devices (i.e. avsinks exported by gfx drivers).
> > - Module refcounting.
> > - power domain handling and well-integrated into runtime pm.
> > - Allows integration into componentized device framework since we're
> > dealing with a real struct device.
> > - Better decoupling between gfx and audio side since registration is done
> > at runtime.
> > - We can attach drv private date which the audio driver needs.
I think this would be another case where the interface framework[0]
could potentially be used. It doesn't give you all of the above, but
there's no reason it couldn't be extended. Then again, adding too much
would end up duplicating more of the driver core, so if something really
heavy-weight is required here, then the interface framework is not the
best option.
[0]: https://lkml.org/lkml/2014/5/13/525
> > > On system boots, the avsink module is loaded before the display and audio
> > > driver module. And the display and audio
> > > driver may be loaded on parallel.
> > > * If a specific display driver (eg. i915) supports avsink, it can create
> > > a display client, add power wells and display
> > > outputs to the client, and then register the display client to the
> > > avsink core. Then it may look up if there is any
> > > audio client registered, by name or type, and may find an audio client
> > > registered by some audio driver.
> > >
> > > * If an audio driver supports avsink, it usually should look up a
> > > registered display client by name or type at first,
> > > because it may need the shared power well in GPU and check the display
> > > outputs' name to bind the audio inputs. If
> > > the display client is not registered yet, the audio driver can choose
> > > to wait (maybe in a work queue) or return
> > > -EAGAIN for a deferred probe. After the display client is found, the
> > > audio driver can register an audio client with
-EPROBE_DEFER is the correct error code for deferred probing.
> > > 6. Display register operation (optional)
> > >
> > > Some audio driver needs to access GPU audio registers. The register ops
> > > are provided by the peer display client.
> > >
> > > struct avsink_registers_ops {
> > > int (*read_register) (uint32_t reg_addr, uint32_t *data, void
> > > *context);
> > > int (*write_register) (uint32_t reg_addr, uint32_t data, void
> > > *context);
> > > int (*read_modify_register) (uint32_t reg_addr, uint32_t data,
> > > uint32_t mask, void *context);
> > >
> > > int avsink_defin
Re: [Intel-gfx] [PATCH 23/66] drm/i915/dsi: Remove ->mode_set callback
On Tue, May 20, 2014 at 05:29:46PM +0530, Kumar, Shobhit wrote: > On 4/25/2014 3:24 AM, Daniel Vetter wrote: > >Looking at our current dsi driver I note that: > >- We don't have any slave driver right now. > >- There's zero support for the hardware state readout and cross check > > code. > >- All the modeset state seems to be tracked in the intel_dsi structure > > instead of the pipe config. > > > >Given all that I can't properly audit the dsi ->mode_set callback. So > >just do it as the first thing in the ->pre_pll_enable hook and hope > >for the best. > > > > Though this is merged, given the uncertainty around this in absence of panel > driver. > > Verified-by: Shobhit Kumar Yeah we have a bit an ugly situation with dsi :( Thanks for checking. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM
On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> Now that we unconditionally dtrt when disabling/enabling crtcs we
> don't need any hacks any longer to keep the vblank logic sane when
> all the registers go poof. So let's rip it all out.
Hmm. drm_update_vblank_count() will now see some kind of diff between
the last and current value when the registers got cloberred. So the
vblank counter reported to userspace will jump. But I guess that's fine
as long as userspace realizes that the counter is not at all reliable
across modesets.
>
> This essentially undoes
>
> commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
> Author: Paulo Zanoni
> Date: Tue Jul 23 10:48:11 2013 -0300
>
> drm/i915: update last_vblank when disabling the power well
>
> Apparently igt/kms_flip is already powerful enough to exercise this
> properly, yay! See the reference regression report for details.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
> Testcase: igt/kms_flip/*-vs-rpm
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_pm.c | 34 --
> 1 file changed, 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 75c1c766b507..45fa43f16bb3 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5423,33 +5423,6 @@ static void hsw_power_well_post_enable(struct
> drm_i915_private *dev_priv)
> }
> }
>
> -static void reset_vblank_counter(struct drm_device *dev, enum pipe pipe)
> -{
> - assert_spin_locked(&dev->vbl_lock);
> -
> - dev->vblank[pipe].last = 0;
> -}
> -
> -static void hsw_power_well_post_disable(struct drm_i915_private *dev_priv)
> -{
> - struct drm_device *dev = dev_priv->dev;
> - enum pipe pipe;
> - unsigned long irqflags;
> -
> - /*
> - * After this, the registers on the pipes that are part of the power
> - * well will become zero, so we have to adjust our counters according to
> - * that.
> - *
> - * FIXME: Should we do this in general in drm_vblank_post_modeset?
> - */
> - spin_lock_irqsave(&dev->vbl_lock, irqflags);
> - for_each_pipe(pipe)
> - if (pipe != PIPE_A)
> - reset_vblank_counter(dev, pipe);
> - spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> -}
> -
> static void hsw_set_power_well(struct drm_i915_private *dev_priv,
> struct i915_power_well *power_well, bool enable)
> {
> @@ -5478,8 +5451,6 @@ static void hsw_set_power_well(struct drm_i915_private
> *dev_priv,
> I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
> POSTING_READ(HSW_PWR_WELL_DRIVER);
> DRM_DEBUG_KMS("Requesting to disable the power well\n");
> -
> - hsw_power_well_post_disable(dev_priv);
> }
> }
> }
> @@ -5646,11 +5617,6 @@ static void vlv_display_power_well_disable(struct
> drm_i915_private *dev_priv,
> valleyview_disable_display_irqs(dev_priv);
> spin_unlock_irq(&dev_priv->irq_lock);
>
> - spin_lock_irq(&dev->vbl_lock);
> - for_each_pipe(pipe)
> - reset_vblank_counter(dev, pipe);
> - spin_unlock_irq(&dev->vbl_lock);
> -
> vlv_set_power_well(dev_priv, power_well, false);
> }
>
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Replaced Blitter ring based flips with MMIO flips
On Tue, May 20, 2014 at 04:19:46PM +0530, sourab.gu...@intel.com wrote:
> +int i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno);
Be strict and add __must_check
> +static bool intel_use_mmio_flip(struct drm_device *dev)
> +{
> + /* If module parameter is disabled, use CS flips.
> + * Otherwise, use MMIO flips starting from Gen5.
> + * This is not being used for older platforms because of
> + * non-availability of flip done interrupt.
> + */
What? Where is the dependence on flip-done?
> + if (i915.use_mmio_flip == 0)
> + return false;
> +
> + if (INTEL_INFO(dev)->gen >= 5)
> + return true;
> + else
> + return false;
You have not justified the change in default settings for existing hw.
Your argument is based on media power wells which does not support the
general change. It would seem that we may want to mix mmio / CS flips
depending on workload based on your vague statements.
I quite fancy a tristate here for force-CS flips, force-MMIO flips, at
driver discretion. Then enabling it on an architecture as a seperate
patch with justification - it is then easier to do each architecture on
a case-by-case basis and revert if need be.
> +static int intel_postpone_flip(struct drm_i915_gem_object *obj)
> +{
> + int ret;
if (WARN_ON(crtc->mmio_flip_data.seqno)) return -EBUSY;
You need a tiling check here as you do not update dspcntr. Or fix
mmio_done.
> + if (!obj->ring)
> + return 0;
> +
> + if (i915_seqno_passed(obj->ring->get_seqno(obj->ring, true),
> + obj->last_write_seqno))
> + return 0;
> +
> + if (ret = i915_gem_check_olr(obj->ring, obj->last_write_seqno))
> + return ret;
Please don't anger gcc.
> +
> + if (WARN_ON(!obj->ring->irq_get(obj->ring)))
> + return 0;
> +
> + return 1;
> +}
> @@ -11377,6 +11497,9 @@ static void intel_init_display(struct drm_device *dev)
> break;
> }
>
> + if(intel_use_mmio_flip(dev))
Please don't anger checkpatch.
> + dev_priv->display.queue_flip = intel_queue_mmio_flip;
> +
> intel_panel_init_backlight_funcs(dev);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 32a74e1..08d65a4 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -351,6 +351,11 @@ struct intel_pipe_wm {
> bool sprites_scaled;
> };
>
> +struct intel_mmio_flip {
> + u32 seqno;
> + u32 ring_id;
> +};
> +
> struct intel_crtc {
> struct drm_crtc base;
> enum pipe pipe;
> @@ -403,6 +408,7 @@ struct intel_crtc {
> } wm;
>
> wait_queue_head_t vbl_wait;
> + struct intel_mmio_flip mmio_flip_data;
Does _data add anything meaningful here to the description of mmio_flip?
Just mmio_flip will suffice, as pending_mmio_flip is overkill but would
make a useful comment.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/66] drm/i915/dsi: Remove ->mode_set callback
On 4/25/2014 3:24 AM, Daniel Vetter wrote: Looking at our current dsi driver I note that: - We don't have any slave driver right now. - There's zero support for the hardware state readout and cross check code. - All the modeset state seems to be tracked in the intel_dsi structure instead of the pipe config. Given all that I can't properly audit the dsi ->mode_set callback. So just do it as the first thing in the ->pre_pll_enable hook and hope for the best. Though this is merged, given the uncertainty around this in absence of panel driver. Verified-by: Shobhit Kumar Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] tests/drv_hangman: Convert test from shell script to c
Mixing script and standlone tests didn't mix well with the
strict i915_ring_stop flags handling. Also squash drv_missed_irq_hang
to the new test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78322
Suggested-by: Daniel Vetter
Signed-off-by: Mika Kuoppala
---
tests/Makefile.sources|3 +-
tests/drv_hangman | 70 -
tests/drv_hangman.c | 357 +
tests/drv_missed_irq_hang | 70 -
4 files changed, 358 insertions(+), 142 deletions(-)
delete mode 100755 tests/drv_hangman
create mode 100644 tests/drv_hangman.c
delete mode 100755 tests/drv_missed_irq_hang
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index fbf63e9..9f5cd76 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -17,6 +17,7 @@ NOUVEAU_TESTS_M = \
TESTS_progs_M = \
core_get_client_auth \
drv_suspend \
+ drv_hangman \
gem_bad_reloc \
gem_basic \
gem_caching \
@@ -148,8 +149,6 @@ TESTS_scripts_M = \
TESTS_scripts = \
debugfs_emon_crash \
drv_debugfs_reader \
- drv_hangman \
- drv_missed_irq_hang \
drv_module_reload \
kms_sysfs_edid_timing \
sysfs_l3_parity \
diff --git a/tests/drv_hangman b/tests/drv_hangman
deleted file mode 100755
index 6b310bc..000
--- a/tests/drv_hangman
+++ /dev/null
@@ -1,70 +0,0 @@
-#!/bin/bash
-#
-# Testcase: Simulate gpu hang
-#
-# This check uses the stop_rings facility to exercise the gpu hang code.
-# by reading /sys/kernel/debug/dri/0/i915_emon_status too quickly
-#
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-oldpath=`pwd`
-
-cd $i915_dfs_path
-
-if [ ! -f i915_ring_stop ] ; then
- echo "kernel doesn't support ring stopping"
- exit 77
-fi
-
-function check_iface {
-dir="$1"
-file="$2"
-mandatory="$3"
-
-[ -z "$dir" ] && return
-
-path="$dir/$file"
-echo checking ${path}
-
-if [ ! -f "$path" ] ; then
- if [ $mandatory != 0 ] ; then
- echo "'${path}' not found";
- exit 1;
- else
- echo "${path} not mandatory";
- return;
- fi
-fi
-
-if cat "$path" | grep -v "no error state collected" > /dev/null ; then
- echo "gpu hang detected"
- exit 2
-fi
-
-echo 0xf > i915_ring_stop
-echo "rings stopped"
-
-(cd $oldpath; $SOURCE_DIR/gem_exec_big) > /dev/null
-
-if cat "$path" | grep -v "no error state collected" > /dev/null ; then
- echo "gpu hang correctly detected"
-else
- echo "gpu hang not detected"
- exit 3
-fi
-
-# clear error state
-echo > "$path"
-
-if cat "$path" | grep -v "no error state collected" > /dev/null ; then
- echo "gpu hang still present"
- exit 4
-fi
-}
-
-check_iface "$i915_dfs_path" i915_error_state 1
-check_iface "$i915_sfs_path" error 0
-
-exit 0
diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
new file mode 100644
index 000..cf141c6
--- /dev/null
+++ b/tests/drv_hangman.c
@@ -0,0 +1,357 @@
+/*
+ * 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 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.
+ *
+ * Authors:
+ *Mika Kuoppala
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "ioctl_wrappers.h"
+
+static int _read_sysfs(void *dst, int maxlen,
+ const char* path,
+ const char *fname)
+{
+ int fd;
+ char full[PATH_MAX];
+ int r, e;
+
+ igt_assert(snprintf(full, PATH_MAX, "%s/%s", path, fname) < PATH_MAX);
+
+ fd = open(full, O_RDONLY);
+ if (fd == -1)
+ return -errno;
+
+ r = read(fd, dst, maxlen);
+ e = errno;
+ close(fd);
+
+ if (r < 0)
+ return -e;
+
+ return r;
+}
+
+static int read_sysfs(void *dst, int maxle
[Intel-gfx] [PATCH 2/2] tests/drv_hangman: Add subtest for error state capture/dump
Guarantees that error capture works at a very basic level.
v2: Also check that the ring object contains a reloc with MI_BB_START
for the presumed batch object's address.
v3: Chris review comments:
- Move variables to local scope.
- Do not assume there is only one request.
- Some gen encode flags into the BB start address.
Also, use igt_set/get_stop_rings as suggested by Mika Kuoppala.
v4: Make as a subtest of drv_hangman.
Signed-off-by: Oscar Mateo (v3)
Signed-off-by: Mika Kuoppala
---
tests/drv_hangman.c | 152 ++-
1 file changed, 151 insertions(+), 1 deletion(-)
diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index cf141c6..8086573 100644
--- a/tests/drv_hangman.c
+++ b/tests/drv_hangman.c
@@ -22,6 +22,7 @@
*
* Authors:
*Mika Kuoppala
+ *Oscar Mateo
*
*/
@@ -30,6 +31,7 @@
#include
#include
+#include "intel_chipset.h"
#include "drmtest.h"
#include "igt_debugfs.h"
#include "ioctl_wrappers.h"
@@ -222,11 +224,16 @@ static void check_other_clients(void)
igt_assert_f(0, "other clients running\n");
}
+#define MAGIC_NUMBER 0x10001
+const uint32_t batch[] = { MI_NOOP,
+ MI_BATCH_BUFFER_END,
+ MAGIC_NUMBER,
+ MAGIC_NUMBER };
+
static uint64_t submit_batch(int fd, unsigned ring_id, bool stop_ring)
{
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 exec;
- const uint32_t batch[2] = { MI_BATCH_BUFFER_END, 0 };
uint64_t presumed_offset;
gem_require_ring(fd, ring_id);
@@ -333,6 +340,144 @@ static void test_ring_missed_irq(void)
close(fd);
}
+static void check_error_state(const int gen,
+ const char *expected_ring_name,
+ uint64_t expected_offset)
+{
+ FILE *file;
+ int debug_fd;
+ char *line = NULL;
+ size_t line_size = 0;
+ char *ring_name = NULL;
+ bool bb_ok = false, req_ok = false, ringbuf_ok = false;
+
+ debug_fd = igt_debugfs_open("i915_error_state", O_RDONLY);
+ igt_assert(debug_fd >= 0);
+ file = fdopen(debug_fd, "r");
+
+ while (getline(&line, &line_size, file) > 0) {
+ char *dashes = NULL;
+ int bb_matched = 0;
+ uint32_t gtt_offset;
+ int req_matched = 0;
+ int requests;
+ uint32_t tail;
+ int ringbuf_matched = 0;
+ int i, items;
+
+ dashes = strstr(line, "---");
+ if (!dashes)
+ continue;
+
+ ring_name = realloc(ring_name, dashes - line);
+ strncpy(ring_name, line, dashes - line);
+ ring_name[dashes - line - 1] = '\0';
+
+ bb_matched = sscanf(dashes, "--- gtt_offset = 0x%08x\n",
+ >t_offset);
+ if (bb_matched == 1) {
+ char expected_line[32];
+
+ igt_assert(strstr(ring_name, expected_ring_name));
+ igt_assert(gtt_offset == expected_offset);
+
+ for (i = 0; i < sizeof(batch) / 4; i++) {
+ igt_assert(getline(&line, &line_size, file) >
0);
+ snprintf(expected_line, sizeof(expected_line),
"%08x : %08x",
+4*i, batch[i]);
+ igt_assert(strstr(line, expected_line));
+ }
+ bb_ok = true;
+ continue;
+ }
+
+ req_matched = sscanf(dashes, "--- %d requests\n", &requests);
+ if (req_matched == 1) {
+ igt_assert(strstr(ring_name, expected_ring_name));
+ igt_assert(requests > 0);
+
+ for (i = 0; i < requests; i++) {
+ uint32_t seqno;
+ long jiffies;
+
+ igt_assert(getline(&line, &line_size, file) >
0);
+ items = sscanf(line, " seqno 0x%08x, emitted
%ld, tail 0x%08x\n",
+ &seqno, &jiffies, &tail);
+ igt_assert(items == 3);
+ }
+ req_ok = true;
+ continue;
+ }
+
+ ringbuf_matched = sscanf(dashes, "--- ringbuffer = 0x%08x\n",
+>t_offset);
+ if (ringbuf_matched == 1) {
+ unsigned int offset, command, expected_addr = 0;
+
+ if (!strstr(ring_name, expected_ring_name))
+ continue;
+ igt_assert(req_ok);
+
+ for (i = 0; i < tail / 4; i++) {
+
Re: [Intel-gfx] [PATCH 00/66] runtime pm for DPMS
drm/i915: Shovel hw setup code out of i9xx_crtc_mode_set drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_set drm/i915: Shovel hw setup code out of ilk_crtc_mode_set drm/i915: Shovel hw setup code out of hsw_crtc_mode_set drm/i915: Extract i9xx_set_pll_dividers drm/i915: Extract vlv_prepare_pll gmch pll moved out of crtc mode_set callbacks into ->enable hooks Reviewer: Shobhit Kumar Looks good. For patch 30-35 Reviewed-by: Shobhit Kumar Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 65/66] drm/i915: Only touch WRPLL hw state in enable/disable hooks
On Thu, Apr 24, 2014 at 11:55:41PM +0200, Daniel Vetter wrote:
> To be able to do this we need to separately keep track of how many
> crtcs need a given WRPLL and how many actually actively use it. The
> common shared dpll framework already has all this, including massive
> state readout and cross checking. Which allows us to do this switch in
> a fairly small patch.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 12 +---
> drivers/gpu/drm/i915/intel_display.c | 16 +++-
> drivers/gpu/drm/i915/intel_drv.h | 2 --
> 3 files changed, 8 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 7386a1212e71..97f9cd6dbee1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -255,16 +255,6 @@ intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
> return ret;
> }
>
> -void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
> -{
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> -
> - if (intel_crtc_to_shared_dpll(intel_crtc))
> - intel_disable_shared_dpll(intel_crtc);
> -
> - intel_put_shared_dpll(intel_crtc);
> -}
> -
> #define LC_FREQ 2700
> #define LC_FREQ_2K (LC_FREQ * 2000)
>
> @@ -585,7 +575,7 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> int type = intel_encoder->type;
> int clock = intel_crtc->config.port_clock;
>
> - intel_ddi_put_crtc_pll(crtc);
> + intel_put_shared_dpll(intel_crtc);
>
> if (type == INTEL_OUTPUT_HDMI) {
> struct intel_shared_dpll *pll;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2fd77eba57f3..e0bd0f94e43e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3673,6 +3673,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
> if (intel_crtc->active)
> return;
>
> + if (intel_crtc_to_shared_dpll(intel_crtc))
> + intel_enable_shared_dpll(intel_crtc);
> +
> if (intel_crtc->config.has_dp_encoder)
> intel_dp_set_m_n(intel_crtc);
>
> @@ -3846,6 +3849,9 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
> intel_update_fbc(dev);
> intel_edp_psr_update(dev);
> mutex_unlock(&dev->struct_mutex);
> +
> + if (intel_crtc_to_shared_dpll(intel_crtc))
> + intel_disable_shared_dpll(intel_crtc);
> }
>
> static void ironlake_crtc_off(struct drm_crtc *crtc)
> @@ -3854,11 +3860,6 @@ static void ironlake_crtc_off(struct drm_crtc *crtc)
> intel_put_shared_dpll(intel_crtc);
> }
>
> -static void haswell_crtc_off(struct drm_crtc *crtc)
> -{
> - intel_ddi_put_crtc_pll(crtc);
> -}
> -
> static void intel_crtc_dpms_overlay(struct intel_crtc *intel_crtc, bool
> enable)
> {
> if (!enable && intel_crtc->overlay) {
> @@ -7002,9 +7003,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
> if (!intel_ddi_pll_select(intel_crtc))
> return -EINVAL;
>
> - if (intel_crtc_to_shared_dpll(intel_crtc))
> - intel_enable_shared_dpll(intel_crtc);
> -
> intel_crtc->lowfreq_avail = false;
>
> return 0;
> @@ -10904,7 +10902,7 @@ static void intel_init_display(struct drm_device *dev)
> dev_priv->display.crtc_mode_set = haswell_crtc_mode_set;
> dev_priv->display.crtc_enable = haswell_crtc_enable;
> dev_priv->display.crtc_disable = haswell_crtc_disable;
> - dev_priv->display.off = haswell_crtc_off;
> + dev_priv->display.off = ironlake_crtc_off;
> dev_priv->display.update_primary_plane =
> ironlake_update_primary_plane;
> } else if (HAS_PCH_SPLIT(dev)) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index acd32e8e5e13..81a7813fc78b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -683,7 +683,6 @@ void intel_ddi_disable_transcoder_func(struct
> drm_i915_private *dev_priv,
> void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc);
> void intel_ddi_disable_pipe_clock(struct intel_crtc *intel_crtc);
> bool intel_ddi_pll_select(struct intel_crtc *crtc);
> -void intel_ddi_put_crtc_pll(struct drm_crtc *crtc);
> void intel_ddi_set_pipe_settings(struct drm_crtc *crtc);
> void intel_ddi_prepare_link_retrain(struct drm_encoder *encoder);
> void intel_ddi_post_disable(struct intel_encoder *intel_encoder);
> @@ -746,7 +745,6 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
> bool state);
> #define assert_shared_dpll_enabled(d, p) assert_shared_dpll(d, p, true)
> #define assert_shared_dpll_disabled(d, p) assert_shared_dpll(d, p, false)
> -void intel_disable_shared_dpll(struct intel_crtc *crtc);
> struct intel_shared_dpll
Re: [Intel-gfx] [PATCH 64/66] drm/i915: Switch to common shared dpll framework for WRPLLs
On Thu, Apr 24, 2014 at 11:55:40PM +0200, Daniel Vetter wrote:
> Mostly this patch is one big excersize in deleting code and asserts
> which are no longer needed. Note that we still abuse the shared dpll
> framework a bit since we call the enable/disable functions from the
> crtc mode_set and off hooks. But changing the actual hardware sequence
> will be done in the next step.
>
> Note that besides the massive amount of changes in this patch the
> places and order in which the low-level WRPLL code is called is
> absolutely unchanged.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_drv.h | 6 --
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_ddi.c | 142
> ---
> drivers/gpu/drm/i915/intel_display.c | 14 ++--
> drivers/gpu/drm/i915/intel_drv.h | 9 ++-
> 5 files changed, 27 insertions(+), 145 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bebc507f776b..73371161777b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -225,11 +225,6 @@ void intel_link_compute_m_n(int bpp, int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n);
>
> -struct intel_ddi_plls {
> - int wrpll1_refcount;
> - int wrpll2_refcount;
> -};
> -
> /* Interface history:
> *
> * 1.1: Original.
> @@ -1399,7 +1394,6 @@ struct drm_i915_private {
>
> int num_shared_dpll;
> struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
> - struct intel_ddi_plls ddi_plls;
> int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
>
> /* Reclocking support */
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 99051e6348b8..fcb1ca6eadb5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5529,6 +5529,7 @@ enum punit_power_well {
> #define PORT_CLK_SEL_LCPLL_1350 (1<<29)
> #define PORT_CLK_SEL_LCPLL_810 (2<<29)
> #define PORT_CLK_SEL_SPLL (3<<29)
> +#define PORT_CLK_SEL_WRPLL(pll) (((pll)+4)<<29)
> #define PORT_CLK_SEL_WRPLL1 (4<<29)
> #define PORT_CLK_SEL_WRPLL2 (5<<29)
> #define PORT_CLK_SEL_NONE (7<<29)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 21e451ea0c69..7386a1212e71 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -257,31 +257,12 @@ intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
>
> void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
> {
> - struct drm_i915_private *dev_priv = crtc->dev->dev_private;
> - struct intel_ddi_plls *plls = &dev_priv->ddi_plls;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>
> - struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(intel_crtc);
> -
> - switch (intel_crtc->config.ddi_pll_sel) {
> - case PORT_CLK_SEL_WRPLL1:
> - plls->wrpll1_refcount--;
> - if (plls->wrpll1_refcount == 0) {
> - pll->disable(dev_priv, pll);
> - }
> - intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE;
> - break;
> - case PORT_CLK_SEL_WRPLL2:
> - plls->wrpll2_refcount--;
> - if (plls->wrpll2_refcount == 0) {
> - pll->disable(dev_priv, pll);
> - }
> - intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE;
> - break;
> - }
> + if (intel_crtc_to_shared_dpll(intel_crtc))
> + intel_disable_shared_dpll(intel_crtc);
>
> - WARN(plls->wrpll1_refcount < 0, "Invalid WRPLL1 refcount\n");
> - WARN(plls->wrpll2_refcount < 0, "Invalid WRPLL2 refcount\n");
> + intel_put_shared_dpll(intel_crtc);
> }
>
> #define LC_FREQ 2700
> @@ -601,17 +582,14 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> {
> struct drm_crtc *crtc = &intel_crtc->base;
> struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
> - struct drm_i915_private *dev_priv = crtc->dev->dev_private;
> - struct intel_ddi_plls *plls = &dev_priv->ddi_plls;
> int type = intel_encoder->type;
> - enum pipe pipe = intel_crtc->pipe;
> int clock = intel_crtc->config.port_clock;
>
> intel_ddi_put_crtc_pll(crtc);
>
> if (type == INTEL_OUTPUT_HDMI) {
> struct intel_shared_dpll *pll;
> - uint32_t reg, val;
> + uint32_t val;
> unsigned p, n2, r2;
>
> intel_ddi_calculate_wrpll(clock * 1000, &r2, &n2, &p);
> @@ -620,79 +598,21 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
> WRPLL_DIVIDER_POST(p);
>
> - if (val == I915_
Re: [Intel-gfx] [PATCH 62/66] drm/i915: ->disable hook for WRPLLs
On Thu, Apr 24, 2014 at 11:55:38PM +0200, Daniel Vetter wrote:
> Currently still with a redudant WARN_ON in there, the common shared
> dpll code will take care of this in the future.
>
> Also we need to flip the switch for the transitional hack now to make
> sure that we disable the right pll.
>
> Signed-off-by: Daniel Vetter
With the small bikeshed below:
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 27 ---
> drivers/gpu/drm/i915/intel_display.c | 8 +---
> 2 files changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 73875ee4bb68..e7e1a84fe453 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -260,28 +260,21 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc)
> struct drm_i915_private *dev_priv = crtc->dev->dev_private;
> struct intel_ddi_plls *plls = &dev_priv->ddi_plls;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - uint32_t val;
> +
> + struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(intel_crtc);
Spurious new line.
> switch (intel_crtc->config.ddi_pll_sel) {
> case PORT_CLK_SEL_WRPLL1:
> plls->wrpll1_refcount--;
> if (plls->wrpll1_refcount == 0) {
> - DRM_DEBUG_KMS("Disabling WRPLL 1\n");
> - val = I915_READ(WRPLL_CTL1);
> - WARN_ON(!(val & WRPLL_PLL_ENABLE));
> - I915_WRITE(WRPLL_CTL1, val & ~WRPLL_PLL_ENABLE);
> - POSTING_READ(WRPLL_CTL1);
> + pll->disable(dev_priv, pll);
> }
> intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE;
> break;
> case PORT_CLK_SEL_WRPLL2:
> plls->wrpll2_refcount--;
> if (plls->wrpll2_refcount == 0) {
> - DRM_DEBUG_KMS("Disabling WRPLL 2\n");
> - val = I915_READ(WRPLL_CTL2);
> - WARN_ON(!(val & WRPLL_PLL_ENABLE));
> - I915_WRITE(WRPLL_CTL2, val & ~WRPLL_PLL_ENABLE);
> - POSTING_READ(WRPLL_CTL2);
> + pll->disable(dev_priv, pll);
> }
> intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE;
> break;
> @@ -1187,6 +1180,17 @@ int intel_ddi_get_cdclk_freq(struct drm_i915_private
> *dev_priv)
> }
> }
>
> +static void hsw_ddi_pll_disable(struct drm_i915_private *dev_priv,
> + struct intel_shared_dpll *pll)
> +{
> + uint32_t val;
> +
> + val = I915_READ(WRPLL_CTL(pll->id));
> + WARN_ON(!(val & WRPLL_PLL_ENABLE));
> + I915_WRITE(WRPLL_CTL(pll->id), val & ~WRPLL_PLL_ENABLE);
> + POSTING_READ(WRPLL_CTL(pll->id));
> +}
> +
> static bool hsw_ddi_pll_get_hw_state(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll,
>struct intel_dpll_hw_state *hw_state)
> @@ -1217,6 +1221,7 @@ void intel_ddi_pll_init(struct drm_device *dev)
> for (i = 0; i < 2; i++) {
> dev_priv->shared_dplls[i].id = i;
> dev_priv->shared_dplls[i].name = hsw_ddi_pll_names[i];
> + dev_priv->shared_dplls[i].disable = hsw_ddi_pll_disable;
> dev_priv->shared_dplls[i].get_hw_state =
> hsw_ddi_pll_get_hw_state;
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b5086fd83596..b890c97f1312 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4788,9 +4788,11 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
> if (HAS_IPS(dev))
> hsw_compute_ips_config(crtc, pipe_config);
>
> - /* XXX: PCH clock sharing is done in ->mode_set, so make sure the old
> - * clock survives for now. */
> - if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
> + /*
> + * XXX: PCH/WRPLL clock sharing is done in ->mode_set, so make sure the
> + * old clock survives for now.
> + */
> + if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev) || HAS_DDI(dev))
> pipe_config->shared_dpll = crtc->config.shared_dpll;
>
> if (pipe_config->has_pch_encoder)
> --
> 1.8.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 63/66] drm/i915: ->enable hook for WRPLLs
On Thu, Apr 24, 2014 at 11:55:39PM +0200, Daniel Vetter wrote:
> This time around another cute hack to pre-fill the pll->hw_state with
> the right values. And also remove a bunch of checks which will be
> replaced by lots more checks in the common framework.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 51
> +++-
> 1 file changed, 19 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index e7e1a84fe453..21e451ea0c69 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -610,6 +610,7 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> intel_ddi_put_crtc_pll(crtc);
>
> if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_shared_dpll *pll;
> uint32_t reg, val;
> unsigned p, n2, r2;
>
> @@ -654,6 +655,9 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> }
>
> intel_crtc->config.dpll_hw_state.wrpll = val;
> +
> + pll = &dev_priv->shared_dplls[intel_crtc->config.shared_dpll];
> + pll->hw_state.wrpll = val;
> }
>
> return true;
> @@ -668,54 +672,24 @@ void intel_ddi_pll_enable(struct intel_crtc *crtc)
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_ddi_plls *plls = &dev_priv->ddi_plls;
> - int clock = crtc->config.port_clock;
> - uint32_t reg, cur_val, new_val;
> int refcount;
> - const char *pll_name;
> - uint32_t enable_bit = (1 << 31);
> - unsigned int p, n2, r2;
> -
> - BUILD_BUG_ON(enable_bit != SPLL_PLL_ENABLE);
> - BUILD_BUG_ON(enable_bit != WRPLL_PLL_ENABLE);
> + struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(crtc);
>
> switch (crtc->config.ddi_pll_sel) {
> case PORT_CLK_SEL_WRPLL1:
> case PORT_CLK_SEL_WRPLL2:
> if (crtc->config.ddi_pll_sel == PORT_CLK_SEL_WRPLL1) {
> - pll_name = "WRPLL1";
> - reg = WRPLL_CTL1;
> refcount = plls->wrpll1_refcount;
> } else {
> - pll_name = "WRPLL2";
> - reg = WRPLL_CTL2;
> refcount = plls->wrpll2_refcount;
> }
> -
> - intel_ddi_calculate_wrpll(clock * 1000, &r2, &n2, &p);
> -
> - new_val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
> - WRPLL_DIVIDER_REFERENCE(r2) |
> - WRPLL_DIVIDER_FEEDBACK(n2) | WRPLL_DIVIDER_POST(p);
> -
> break;
> -
> - case PORT_CLK_SEL_NONE:
> - WARN(1, "Bad selected pll: PORT_CLK_SEL_NONE\n");
> - return;
> default:
> return;
> }
>
> - cur_val = I915_READ(reg);
> -
> - WARN(refcount < 1, "Bad %s refcount: %d\n", pll_name, refcount);
> if (refcount == 1) {
> - WARN(cur_val & enable_bit, "%s already enabled\n", pll_name);
> - I915_WRITE(reg, new_val);
> - POSTING_READ(reg);
> - udelay(20);
> - } else {
> - WARN((cur_val & enable_bit) == 0, "%s disabled\n", pll_name);
> + pll->enable(dev_priv, pll);
> }
> }
>
> @@ -1180,6 +1154,18 @@ int intel_ddi_get_cdclk_freq(struct drm_i915_private
> *dev_priv)
> }
> }
>
> +static void hsw_ddi_pll_enable(struct drm_i915_private *dev_priv,
> +struct intel_shared_dpll *pll)
> +{
> + uint32_t cur_val;
> +
> + cur_val = I915_READ(WRPLL_CTL(pll->id));
> + WARN(cur_val & WRPLL_PLL_ENABLE, "%s already enabled\n", pll->name);
> + I915_WRITE(WRPLL_CTL(pll->id), pll->hw_state.wrpll);
> + POSTING_READ(WRPLL_CTL(pll->id));
> + udelay(20);
> +}
> +
> static void hsw_ddi_pll_disable(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> @@ -1222,6 +1208,7 @@ void intel_ddi_pll_init(struct drm_device *dev)
> dev_priv->shared_dplls[i].id = i;
> dev_priv->shared_dplls[i].name = hsw_ddi_pll_names[i];
> dev_priv->shared_dplls[i].disable = hsw_ddi_pll_disable;
> + dev_priv->shared_dplls[i].enable = hsw_ddi_pll_enable;
> dev_priv->shared_dplls[i].get_hw_state =
> hsw_ddi_pll_get_hw_state;
> }
> --
> 1.8.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 58/66] drm/i915: Precompute static ddi_pll_sel values in encoders
On Tue, May 20, 2014 at 11:56:28AM +0100, Damien Lespiau wrote: > On Thu, Apr 24, 2014 at 11:55:34PM +0200, Daniel Vetter wrote: > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > @@ -272,6 +272,7 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc) > > I915_WRITE(WRPLL_CTL1, val & ~WRPLL_PLL_ENABLE); > > POSTING_READ(WRPLL_CTL1); > > } > > + intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE; > > break; > > case PORT_CLK_SEL_WRPLL2: > > plls->wrpll2_refcount--; > > @@ -282,13 +283,12 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc) > > I915_WRITE(WRPLL_CTL2, val & ~WRPLL_PLL_ENABLE); > > POSTING_READ(WRPLL_CTL2); > > } > > + intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE; > > break; > > } > > > > WARN(plls->wrpll1_refcount < 0, "Invalid WRPLL1 refcount\n"); > > WARN(plls->wrpll2_refcount < 0, "Invalid WRPLL2 refcount\n"); > > - > > - intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE; > > } > > Who sets config.ddi_pll_sel to NONE for VGA and DP now? We don't care about that any more. The spll handling was completely moved into intel_crt.c with the intermediate patches, and intel DP directly keys off the right clock from config->port_clock. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 57/66] drm/i915: State readout and cross-checking for ddi_pll_sel
On Tue, May 20, 2014 at 11:47:35AM +0100, Damien Lespiau wrote:
> On Thu, Apr 24, 2014 at 11:55:33PM +0200, Daniel Vetter wrote:
> > To make things a bit more manageable extract a new function for
> > reading out common ddi port state. This means a bit of duplication
> > between encoders and the core since both look at the same registers,
> > but doesn't seem worth to make a fuzz about.
> >
> > We can also remove the state readout code in intel_ddi_setup_hw_pll_state.
> > That code is only called from the hardware take over and not the cross
> > check code, and only after the crtc state is reconstructed. So we can
> > rely on an accurate value of crtc->config.ddi_pll_sel already.
> >
> > Compared to the old code also trust the hw state more and don't
> > special-case port A - we want to cross-check the actual-state, not
> > bake in our own assumptions about how this is supposed to all be
> > linked up.
> >
> > v2: Make use of the read-out ddi_pll_sel in intel_ddi_clock_get.
> >
> > Signed-off-by: Daniel Vetter
>
> Moving things out of intel_ddi.c to intel_display.c seems to be the
> opposite of what we want. I don't see why we couldn't leave the DDI
> readout function inside intel_ddi.c?
Fewer forward decls and non-static functions. If you have a file with a
bunch of functions but they're all called from somewhere else, then the
split-up is imo not functionally sound. intel_ddi.c has a bit that taste
for me.
We could fix this I guess by moving a lot more into intel_ddi.c, like all
the hsw+ modeset code.
> Reviewed-by: Damien Lespiau
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_ddi.c | 40 +-
> > drivers/gpu/drm/i915/intel_display.c | 48
> >
> > 3 files changed, 34 insertions(+), 55 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 64d40f22e708..4c1cefb5f3eb 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5366,6 +5366,7 @@ enum punit_power_well {
> > #define TRANS_DDI_FUNC_ENABLE (1<<31)
> > /* Those bits are ignored by pipe EDP since it can only connect to DDI A */
> > #define TRANS_DDI_PORT_MASK (7<<28)
> > +#define TRANS_DDI_PORT_SHIFT 28
> > #define TRANS_DDI_SELECT_PORT(x) ((x)<<28)
> > #define TRANS_DDI_PORT_NONE (0<<28)
> > #define TRANS_DDI_MODE_SELECT_MASK(7<<24)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 2adcc917806e..571cfe431558 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -481,11 +481,10 @@ static void intel_ddi_clock_get(struct intel_encoder
> > *encoder,
> > struct intel_crtc_config *pipe_config)
> > {
> > struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> > - enum port port = intel_ddi_get_encoder_port(encoder);
> > int link_clock = 0;
> > u32 val, pll;
> >
> > - val = I915_READ(PORT_CLK_SEL(port));
> > + val = pipe_config->ddi_pll_sel;
> > switch (val & PORT_CLK_SEL_MASK) {
> > case PORT_CLK_SEL_LCPLL_810:
> > link_clock = 81000;
> > @@ -987,40 +986,6 @@ static bool intel_ddi_get_hw_state(struct
> > intel_encoder *encoder,
> > return intel_ddi_get_port_state(encoder, pipe, port);
> > }
> >
> > -static uint32_t intel_ddi_get_crtc_pll(struct drm_i915_private *dev_priv,
> > - enum pipe pipe)
> > -{
> > - uint32_t temp, ret;
> > - enum port port = I915_MAX_PORTS;
> > - enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
> > - pipe);
> > - int i;
> > -
> > - if (cpu_transcoder == TRANSCODER_EDP) {
> > - port = PORT_A;
> > - } else {
> > - temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > - temp &= TRANS_DDI_PORT_MASK;
> > -
> > - for (i = PORT_B; i <= PORT_E; i++)
> > - if (temp == TRANS_DDI_SELECT_PORT(i))
> > - port = i;
> > - }
> > -
> > - if (port == I915_MAX_PORTS) {
> > - WARN(1, "Pipe %c enabled on an unknown port\n",
> > -pipe_name(pipe));
> > - ret = PORT_CLK_SEL_NONE;
> > - } else {
> > - ret = I915_READ(PORT_CLK_SEL(port));
> > - DRM_DEBUG_KMS("Pipe %c connected to port %c using clock "
> > - "0x%08x\n", pipe_name(pipe), port_name(port),
> > - ret);
> > - }
> > -
> > - return ret;
> > -}
> > -
> > void intel_ddi_setup_hw_pll_state(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -1039,9 +1004,6 @@ void intel_ddi_setup_hw_pll_state(struct drm_device
> > *dev)
> >
Re: [Intel-gfx] [PATCH 36/66] drm/i915: Only update shared dpll state when needed
On Tue, May 20, 2014 at 11:18:54AM +0100, Damien Lespiau wrote:
> On Thu, Apr 24, 2014 at 11:55:12PM +0200, Daniel Vetter wrote:
> > Instead of every time it isn't active: We only need to do that when
> > the pll is currently unused, i.e. when pll->refcount == 0. For
> > paranoia add a warning for the ibx case where plls have a fixed
> > mapping and hence should always be unused after the call to
> > intel_put_shared_dpll.
> >
> > Signed-off-by: Daniel Vetter
>
> - Instead of duplicating the memcpy() I'd add a single path after the
> 'found' label,
> - You could ensure type safety in the copy:
>
> if (pll->refcount == 0)
> pll->hw_state = crtc->config.dpll_hw_state
I like this, so will quickly respin.
-Daniel
>
> Oh well.
>
> Reviewed-by: Damien Lespiau
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 21e20bc495ee..aef869dcc054 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3416,6 +3416,11 @@ static struct intel_shared_dpll
> > *intel_get_shared_dpll(struct intel_crtc *crtc)
> > DRM_DEBUG_KMS("CRTC:%d using pre-allocated %s\n",
> > crtc->base.base.id, pll->name);
> >
> > + WARN_ON(pll->refcount);
> > +
> > + memcpy(&pll->hw_state, &crtc->config.dpll_hw_state,
> > + sizeof(pll->hw_state));
> > +
> > goto found;
> > }
> >
> > @@ -3442,6 +3447,10 @@ static struct intel_shared_dpll
> > *intel_get_shared_dpll(struct intel_crtc *crtc)
> > if (pll->refcount == 0) {
> > DRM_DEBUG_KMS("CRTC:%d allocated %s\n",
> > crtc->base.base.id, pll->name);
> > +
> > + memcpy(&pll->hw_state, &crtc->config.dpll_hw_state,
> > + sizeof(pll->hw_state));
> > +
> > goto found;
> > }
> > }
> > @@ -3454,9 +3463,6 @@ found:
> > pipe_name(crtc->pipe));
> >
> > if (pll->active == 0) {
> > - memcpy(&pll->hw_state, &crtc->config.dpll_hw_state,
> > - sizeof(pll->hw_state));
> > -
> > DRM_DEBUG_DRIVER("setting up %s\n", pll->name);
> > WARN_ON(pll->on);
> > assert_shared_dpll_disabled(dev_priv, pll);
> > --
> > 1.8.1.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 61/66] drm/i915: State readout support for WRPLLs
On Thu, Apr 24, 2014 at 11:55:37PM +0200, Daniel Vetter wrote:
> Still tacked onto the side, but slowly getting there.
>
> v2: Don't forget the debugfs file.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_ddi.c | 16
> drivers/gpu/drm/i915/intel_display.c | 9 +
> 5 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c99951fdc572..a579685348aa 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2389,6 +2389,7 @@ static int i915_shared_dplls_info(struct seq_file *m,
> void *unused)
> seq_printf(m, " dpll_md: 0x%08x\n", pll->hw_state.dpll_md);
> seq_printf(m, " fp0: 0x%08x\n", pll->hw_state.fp0);
> seq_printf(m, " fp1: 0x%08x\n", pll->hw_state.fp1);
> + seq_printf(m, " wrpll: 0x%08x\n", pll->hw_state.wrpll);
> }
> drm_modeset_unlock_all(dev);
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b01ee265310f..bebc507f776b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -188,6 +188,7 @@ struct intel_dpll_hw_state {
> uint32_t dpll_md;
> uint32_t fp0;
> uint32_t fp1;
> + uint32_t wrpll;
> };
>
> struct intel_shared_dpll {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4c1cefb5f3eb..99051e6348b8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5505,6 +5505,7 @@ enum punit_power_well {
> /* WRPLL */
> #define WRPLL_CTL1 0x46040
> #define WRPLL_CTL2 0x46060
> +#define WRPLL_CTL(pll) (pll == 0 ? WRPLL_CTL1 :
> WRPLL_CTL2)
> #define WRPLL_PLL_ENABLE(1<<31)
> #define WRPLL_PLL_SSC (1<<28)
> #define WRPLL_PLL_NON_SSC (2<<28)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8316e0e624a4..73875ee4bb68 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -659,6 +659,8 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_WRPLL2;
> intel_crtc->config.shared_dpll = DPLL_ID_WRPLL2;
> }
> +
> + intel_crtc->config.dpll_hw_state.wrpll = val;
> }
>
> return true;
> @@ -1185,6 +1187,18 @@ int intel_ddi_get_cdclk_freq(struct drm_i915_private
> *dev_priv)
> }
> }
>
> +static bool hsw_ddi_pll_get_hw_state(struct drm_i915_private *dev_priv,
> + struct intel_shared_dpll *pll,
> + struct intel_dpll_hw_state *hw_state)
> +{
> + uint32_t val;
> +
> + val = I915_READ(WRPLL_CTL(pll->id));
> + hw_state->wrpll = val;
> +
> + return val & WRPLL_PLL_ENABLE;
> +}
> +
> static char *hsw_ddi_pll_names[] = {
> "WRPLL 1",
> "WRPLL 2",
> @@ -1203,6 +1217,8 @@ void intel_ddi_pll_init(struct drm_device *dev)
> for (i = 0; i < 2; i++) {
> dev_priv->shared_dplls[i].id = i;
> dev_priv->shared_dplls[i].name = hsw_ddi_pll_names[i];
> + dev_priv->shared_dplls[i].get_hw_state =
> + hsw_ddi_pll_get_hw_state;
> }
>
> /* The LCPLL register should be turned on by the BIOS. For now let's
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fc7cd89b8921..b5086fd83596 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7011,6 +7011,7 @@ static void haswell_get_ddi_port_state(struct
> intel_crtc *crtc,
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_shared_dpll *pll;
> enum port port;
> uint32_t tmp;
>
> @@ -7029,6 +7030,13 @@ static void haswell_get_ddi_port_state(struct
> intel_crtc *crtc,
> break;
> }
>
> + if (pipe_config->shared_dpll >= 0) {
> + pll = &dev_priv->shared_dplls[pipe_config->shared_dpll];
> +
> + WARN_ON(!pll->get_hw_state(dev_priv, pll,
> +&pipe_config->dpll_hw_state));
> + }
> +
> /*
>* Haswell has only FDI/PCH transcoder A. It is which is connected to
>* DDI E. So just check whether this pipe is wired to DDI E and whether
> @@ -9552,6 +9560,7 @@ intel_pipe_config_compare(struct drm_device *dev,
> PIPE_CONF_CHECK_X(dpll_hw_state.dpll_md);
> PIPE_CONF_CHECK_X(dpll_hw_state.fp0);
> PI
Re: [Intel-gfx] [PATCH 60/66] drm/i915: Document that the pll->mode_set hook is optional
On Thu, Apr 24, 2014 at 11:55:36PM +0200, Daniel Vetter wrote:
> The WRPLLs won't use them.
>
> Signed-off-by: Daniel Vetter
/*
* Comments spawning multiple lines are formatted...
* ...this way
*/
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index babeb7e92ee4..b01ee265310f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -198,6 +198,8 @@ struct intel_shared_dpll {
> /* should match the index in the dev_priv->shared_dplls array */
> enum intel_dpll_id id;
> struct intel_dpll_hw_state hw_state;
> + /* The mode_set hook is optional and should be used together with the
> + * intel_prepare_shared_dpll function. */
> void (*mode_set)(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll);
> void (*enable)(struct drm_i915_private *dev_priv,
> --
> 1.8.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 59/66] drm/i915: Basic shared dpll support for WRPLLs
On Thu, Apr 24, 2014 at 11:55:35PM +0200, Daniel Vetter wrote:
> Just filing in names and ids, but not yet officially registering them
> so that the hw state cross checker doesn't completely freak out about
> them. Still since we do already read out and cross check
> config->shared_dpll the basics are now there to flesh out the wrpll
> shared dpll implementation.
>
> The idea is now to roll out all the callbacks step-by-step and then at
> the end switch to the shared dpll framework. This way hw and sw
> changes are clearly separated.
>
> Signed-off-by: Daniel Vetter
With the consts added:
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_drv.h | 6 --
> drivers/gpu/drm/i915/intel_ddi.c | 17 +
> drivers/gpu/drm/i915/intel_display.c | 21 +
> 3 files changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b6eac92e0a22..babeb7e92ee4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -176,8 +176,10 @@ struct drm_i915_private;
> enum intel_dpll_id {
> DPLL_ID_PRIVATE = -1, /* non-shared dpll in use */
> /* real shared dpll ids must be >= 0 */
> - DPLL_ID_PCH_PLL_A,
> - DPLL_ID_PCH_PLL_B,
> + DPLL_ID_PCH_PLL_A = 0,
> + DPLL_ID_PCH_PLL_B = 1,
> + DPLL_ID_WRPLL1 = 0,
> + DPLL_ID_WRPLL2 = 1,
> };
> #define I915_NUM_PLLS 2
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index cc03f0af517b..8316e0e624a4 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -653,9 +653,11 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> if (reg == WRPLL_CTL1) {
> plls->wrpll1_refcount++;
> intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_WRPLL1;
> + intel_crtc->config.shared_dpll = DPLL_ID_WRPLL1;
> } else {
> plls->wrpll2_refcount++;
> intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_WRPLL2;
> + intel_crtc->config.shared_dpll = DPLL_ID_WRPLL2;
> }
> }
>
> @@ -1183,10 +1185,25 @@ int intel_ddi_get_cdclk_freq(struct drm_i915_private
> *dev_priv)
> }
> }
>
> +static char *hsw_ddi_pll_names[] = {
> + "WRPLL 1",
> + "WRPLL 2",
> +};
> +
static const char * const
> void intel_ddi_pll_init(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint32_t val = I915_READ(LCPLL_CTL);
> + int i;
> +
> + /* Dummy setup until everything is moved over to avoid upsetting the hw
> + * state cross checker. */
> + dev_priv->num_shared_dpll = 0;
> +
> + for (i = 0; i < 2; i++) {
> + dev_priv->shared_dplls[i].id = i;
> + dev_priv->shared_dplls[i].name = hsw_ddi_pll_names[i];
> + }
>
> /* The LCPLL register should be turned on by the BIOS. For now let's
>* just check its state and print errors in case something is wrong.
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 1601da1b57a1..fc7cd89b8921 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7019,6 +7019,16 @@ static void haswell_get_ddi_port_state(struct
> intel_crtc *crtc,
> port = (tmp & TRANS_DDI_PORT_MASK) >> TRANS_DDI_PORT_SHIFT;
>
> pipe_config->ddi_pll_sel = I915_READ(PORT_CLK_SEL(port));
> +
> + switch (pipe_config->ddi_pll_sel) {
> + case PORT_CLK_SEL_WRPLL1:
> + pipe_config->shared_dpll = DPLL_ID_WRPLL1;
> + break;
> + case PORT_CLK_SEL_WRPLL2:
> + pipe_config->shared_dpll = DPLL_ID_WRPLL2;
> + break;
> + }
> +
> /*
>* Haswell has only FDI/PCH transcoder A. It is which is connected to
>* DDI E. So just check whether this pipe is wired to DDI E and whether
> @@ -10340,12 +10350,6 @@ static const struct drm_crtc_funcs intel_crtc_funcs
> = {
> .page_flip = intel_crtc_page_flip,
> };
>
> -static void intel_cpu_pll_init(struct drm_device *dev)
> -{
> - if (HAS_DDI(dev))
> - intel_ddi_pll_init(dev);
> -}
> -
> static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll,
> struct intel_dpll_hw_state *hw_state)
> @@ -10433,7 +10437,9 @@ static void intel_shared_dpll_init(struct drm_device
> *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> - if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
> + if (HAS_DDI(dev))
> + intel_ddi_pll_init(dev);
> + else if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
> ibx_pch_dpll_init(dev);
> else
> dev_priv->num_shared_dp
Re: [Intel-gfx] [PATCH 58/66] drm/i915: Precompute static ddi_pll_sel values in encoders
On Thu, Apr 24, 2014 at 11:55:34PM +0200, Daniel Vetter wrote: > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -272,6 +272,7 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc) > I915_WRITE(WRPLL_CTL1, val & ~WRPLL_PLL_ENABLE); > POSTING_READ(WRPLL_CTL1); > } > + intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE; > break; > case PORT_CLK_SEL_WRPLL2: > plls->wrpll2_refcount--; > @@ -282,13 +283,12 @@ void intel_ddi_put_crtc_pll(struct drm_crtc *crtc) > I915_WRITE(WRPLL_CTL2, val & ~WRPLL_PLL_ENABLE); > POSTING_READ(WRPLL_CTL2); > } > + intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE; > break; > } > > WARN(plls->wrpll1_refcount < 0, "Invalid WRPLL1 refcount\n"); > WARN(plls->wrpll2_refcount < 0, "Invalid WRPLL2 refcount\n"); > - > - intel_crtc->config.ddi_pll_sel = PORT_CLK_SEL_NONE; > } Who sets config.ddi_pll_sel to NONE for VGA and DP now? -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, May 20, 2014 at 10:10:00AM +0200, Takashi Iwai wrote:
> > struct avsink_client {
> > const char *name; /* client name */
> > int type; /* client type*/
> > void *context;
> > struct module *module; /* top-level module for locking */
> >
> > struct avsink_client *peer; /* peer client */
> >
> > /* shared power wells */
> > struct avsink_power_well *power_well;
> > int num_power_wells;
>
> The "power well" is Intel-specific things. Better to use a more
> generic term. (And, I'm always confused what "power well disable"
> means :)
Given that runtime pm is a prevalent usage, wouldn't it make sense
to say that I am HDMI client so keep the resources on? This can be easily
managed if we are able to create the audio device as child of display
controller. That would be implementation agnostic and controller can do whatever
(power well or not) to keep it on/off
>
> >
> > /* endpoints, display outputs or audio inputs */
> > struct avsink_endpoint * endpoint;
> > int num_endpints;
> >
> > struct avsink_registers_ops *reg_ops; /* ops to access registers
> > of a client */
>
> Use const for ops pointers in general (also other cases below).
>
>
> > void *private_data;
> > ...
> > };
> >
> > On system boots, the avsink module is loaded before the display and audio
> > driver module. And the display and audio
> > driver may be loaded on parallel.
>
> For HD-audio HDMI, both controller and codec drivers would need the
> avsink access. So, both drivers will register the own client?
that sound logical here..
>
>
> > * If a specific display driver (eg. i915) supports avsink, it can create a
> > display client, add power wells and display
> > outputs to the client, and then register the display client to the avsink
> > core. Then it may look up if there is any
> > audio client registered, by name or type, and may find an audio client
> > registered by some audio driver.
> >
> > * If an audio driver supports avsink, it usually should look up a
> > registered display client by name or type at first,
> > because it may need the shared power well in GPU and check the display
> > outputs' name to bind the audio inputs. If
> > the display client is not registered yet, the audio driver can choose to
> > wait (maybe in a work queue) or return
> > -EAGAIN for a deferred probe. After the display client is found, the
> > audio driver can register an audio client with
> > the display client's name as the peer name, the avsink core will bind the
> > display and audio clients to each other.
>
> There is already "component" framework, BTW. Can we integrate it into
> avsink instead?
>
>
> > Open question:
> > If the display or audio driver is disabled by the black list, shall we
> > introduce a time out to avoid waiting for the
> > other client registered endlessly?
>
> Yes, timeout sounds like a sensible option.
>
>
> > 2. Shared power wells (optional)
> >
> > The audio and display devices, maybe only part of them, may share a common
> > power well (e.g. for Intel Haswell and
> > Broadwell). If so, the driver that controls the power well should define a
> > power well object, implement the get/put ops,
> > and add it to its avsink client before registering the client to avsink
> > core. Then the peer client can look up this
> > power well by its name, and get/put this power well as a user.
> >
> > A client can have multiple power well objects.
> >
> > struct avsink_power_well {
> > const char *name; /* name of the power well */
> > void *context; /* parameter of get/put ops, maybe device pointer
> > for this power well */
> > struct avsink_power_well_ops *ops
> > };
> >
> > struct avsink_power_well_ops {
> > int (*get)(void *context);
> > int (*put)(void *context);
> > };
> >
> > API:
> > int avsink_new_power(struct avsink_client *client,
> >const char *power_name,
> >void * power_context,
> >struct avsink_power_well_ops *ops,
> >struct avsink_power_well **power_ret);
> >
> > struct avsink_power_well *avisnk_lookup_power(const char *name);
> >
> > int avsink_get_power(struct avsink_power_well *power); /* Reqesut the
> > power */
> > int avsink_put_power(struct avsink_power_well *power);/* Release the
> > power */
> >
> > For example, the i915 display driver can create a device for the shared
> > power well in Haswell GPU, implement its PM
> > functions, and use the device pointer as the context when creating the
> > power well object, like below
> >
> > struct avsink_power_well_ops i915_power_well_ops = {
> > .get = pm_runtime_get_sync;
> > .put = pm_runtime_put_sync;
> > };
>
> This needs function pointer cast, and it's not portable although it'd
> work practically.
>
>
> > ...
> > avsink
[Intel-gfx] [PATCH v6 1/3] drm/i915: Replaced Blitter ring based flips with MMIO flips
From: Sourab Gupta
Using MMIO based flips on Gen5+ for Media power well residency optimization.
The blitter ring is currently being used just for command streamer based
flip calls. For pure 3D workloads, with MMIO flips, there will be no use
of blitter ring and this will ensure the 100% residency for Media well.
v2: The MMIO flips now use the interrupt driven mechanism for issuing the
flips when target seqno is reached. (Incorporating Ville's idea)
v3: Rebasing on latest code. Code restructuring after incorporating
Damien's comments
v4: Addressing Ville's review comments
-general cleanup
-updating only base addr instead of calling update_primary_plane
-extending patch for gen5+ platforms
v5: Addressed Ville's review comments
-Making mmio flip vs cs flip selection based on module parameter
-Adding check for DRIVER_MODESET feature in notify_ring before calling
notify mmio flip.
-Other changes mostly in function arguments
v6: -Having a seperate function to check condition for using mmio flips (Ville)
-propogating error code from i915_gem_check_olr (Ville)
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_dma.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 3 +
drivers/gpu/drm/i915/i915_params.c | 4 ++
drivers/gpu/drm/i915/intel_display.c | 123 +++
drivers/gpu/drm/i915/intel_drv.h | 6 ++
7 files changed, 144 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 46f1dec..672c28f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1570,6 +1570,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
spin_lock_init(&dev_priv->backlight_lock);
spin_lock_init(&dev_priv->uncore.lock);
spin_lock_init(&dev_priv->mm.object_stat_lock);
+ spin_lock_init(&dev_priv->mmio_flip_lock);
dev_priv->ring_index = 0;
mutex_init(&dev_priv->dpio_lock);
mutex_init(&dev_priv->modeset_restore_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4006dfe..9f1d042 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1543,6 +1543,8 @@ struct drm_i915_private {
struct i915_ums_state ums;
/* the indicator for dispatch video commands on two BSD rings */
int ring_index;
+ /* protects the mmio flip data */
+ spinlock_t mmio_flip_lock;
};
static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
@@ -2019,6 +2021,7 @@ struct i915_params {
bool reset;
bool disable_display;
bool disable_vtd_wa;
+ bool use_mmio_flip;
};
extern struct i915_params i915 __read_mostly;
@@ -2209,6 +2212,7 @@ bool i915_gem_retire_requests(struct drm_device *dev);
void i915_gem_retire_requests_ring(struct intel_ring_buffer *ring);
int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
bool interruptible);
+int i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno);
static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
{
return unlikely(atomic_read(&error->reset_counter)
@@ -2580,6 +2584,8 @@ int i915_reg_read_ioctl(struct drm_device *dev, void
*data,
int i915_get_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+void intel_notify_mmio_flip(struct intel_ring_buffer *ring);
+
/* overlay */
extern struct intel_overlay_error_state
*intel_overlay_capture_error_state(struct drm_device *dev);
extern void intel_overlay_print_error_state(struct drm_i915_error_state_buf *e,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fa5b5ab..5b4e953 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -975,7 +975,7 @@ i915_gem_check_wedge(struct i915_gpu_error *error,
* Compare seqno against outstanding lazy request. Emit a request if they are
* equal.
*/
-static int
+int
i915_gem_check_olr(struct intel_ring_buffer *ring, u32 seqno)
{
int ret;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b10fbde..31e98e2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1084,6 +1084,9 @@ static void notify_ring(struct drm_device *dev,
trace_i915_gem_request_complete(ring);
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ intel_notify_mmio_flip(ring);
+
wake_up_all(&ring->irq_queue);
i915_queue_hangcheck(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index d05a2af..e0d44df 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_para
[Intel-gfx] [PATCH 2/3] drm/i915: Default to mmio flips on VLV
From: Sourab Gupta
This patch is for using mmio flips by default on VLV.
The module parameter controlling use of MMIO flips allows us to
control the default behaviour, which is set true for VLV and false
elsewhere.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_params.c | 5 +++--
drivers/gpu/drm/i915/intel_display.c | 12 +++-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index e0d44df..a99accc 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -48,7 +48,7 @@ struct i915_params i915 __read_mostly = {
.disable_display = 0,
.enable_cmd_parser = 1,
.disable_vtd_wa = 0,
- .use_mmio_flip = 0,
+ .use_mmio_flip = -1,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -159,4 +159,5 @@ MODULE_PARM_DESC(enable_cmd_parser,
"Enable command parsing (1=enabled [default], 0=disabled)");
module_param_named(use_mmio_flip, i915.use_mmio_flip, bool, 0600);
-MODULE_PARM_DESC(use_mmio_flip, "use MMIO flips (default: false)");
+MODULE_PARM_DESC(use_mmio_flip, "use MMIO page flips "
+ "(default: -1 (use per-chip default))");
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d8bc30b..21f1fa5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9043,10 +9043,20 @@ static bool intel_use_mmio_flip(struct drm_device *dev)
* Otherwise, use MMIO flips starting from Gen5.
* This is not being used for older platforms because of
* non-availability of flip done interrupt.
+* On Valleyview, use MMIO flips by default, for Media Power Well
+* residency optimization. The other alternative of having Render
+* ring based flip calls is not being used, as the performance(FPS)
+* of certain 3D Apps gets severly affected.
*/
+
if (i915.use_mmio_flip == 0)
return false;
-
+ if (i915.use_mmio_flip == -1) {
+ if(IS_VALLEYVIEW(dev))
+ return true;
+ else
+ return false;
+ }
if (INTEL_INFO(dev)->gen >= 5)
return true;
else
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Fix mmio page flip vs mmio set base race
From: Sourab Gupta
This patch fixes the race condition between flip done interrupt
from set base and mmio based page flip.
This patch is dependent on
http://lists.freedesktop.org/archives/intel-gfx/2014-April/043761.html
Also, for the details of the race condition please refer to the mentioned
patch.
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/intel_display.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 21f1fa5..8e85d6c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9073,8 +9073,7 @@ static void intel_do_mmio_flip(struct intel_crtc
*intel_crtc)
intel_mark_page_flip_active(intel_crtc);
- I915_WRITE(DSPSURF(intel_crtc->plane), i915_gem_obj_ggtt_offset(obj) +
- intel_crtc->dspaddr_offset);
+ I915_WRITE(DSPSURF(intel_crtc->plane),
intel_crtc->unpin_work->gtt_offset);
POSTING_READ(DSPSURF(intel_crtc->plane));
}
@@ -9142,6 +9141,9 @@ static int intel_queue_mmio_flip(struct drm_device *dev,
if (ret)
goto err;
+ intel_crtc->unpin_work->gtt_offset =
+ i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
+
ret = intel_postpone_flip(obj);
if (ret < 0) {
goto err_unpin;
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] Replace Blitter ring based flips with MMIO flips
From: Sourab Gupta Using MMIO based flips for Media power well residency optimization. The blitter ring is currently being used just for command streamer based flip calls. For pure 3D workloads, with MMIO flips, there will be no use of blitter ring and this will ensure the 100% residency for Media well. Sourab Gupta (3): drm/i915: Replaced Blitter ring based flips with MMIO flips drm/i915: Default to mmio flips on VLV drm/i915: Fix mmio page flip vs mmio set base race drivers/gpu/drm/i915/i915_dma.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 6 ++ drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 3 + drivers/gpu/drm/i915/i915_params.c | 5 ++ drivers/gpu/drm/i915/intel_display.c | 135 +++ drivers/gpu/drm/i915/intel_drv.h | 6 ++ 7 files changed, 157 insertions(+), 1 deletion(-) -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 57/66] drm/i915: State readout and cross-checking for ddi_pll_sel
On Thu, Apr 24, 2014 at 11:55:33PM +0200, Daniel Vetter wrote:
> To make things a bit more manageable extract a new function for
> reading out common ddi port state. This means a bit of duplication
> between encoders and the core since both look at the same registers,
> but doesn't seem worth to make a fuzz about.
>
> We can also remove the state readout code in intel_ddi_setup_hw_pll_state.
> That code is only called from the hardware take over and not the cross
> check code, and only after the crtc state is reconstructed. So we can
> rely on an accurate value of crtc->config.ddi_pll_sel already.
>
> Compared to the old code also trust the hw state more and don't
> special-case port A - we want to cross-check the actual-state, not
> bake in our own assumptions about how this is supposed to all be
> linked up.
>
> v2: Make use of the read-out ddi_pll_sel in intel_ddi_clock_get.
>
> Signed-off-by: Daniel Vetter
Moving things out of intel_ddi.c to intel_display.c seems to be the
opposite of what we want. I don't see why we couldn't leave the DDI
readout function inside intel_ddi.c?
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_ddi.c | 40 +-
> drivers/gpu/drm/i915/intel_display.c | 48
>
> 3 files changed, 34 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 64d40f22e708..4c1cefb5f3eb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5366,6 +5366,7 @@ enum punit_power_well {
> #define TRANS_DDI_FUNC_ENABLE (1<<31)
> /* Those bits are ignored by pipe EDP since it can only connect to DDI A */
> #define TRANS_DDI_PORT_MASK (7<<28)
> +#define TRANS_DDI_PORT_SHIFT28
> #define TRANS_DDI_SELECT_PORT(x)((x)<<28)
> #define TRANS_DDI_PORT_NONE (0<<28)
> #define TRANS_DDI_MODE_SELECT_MASK (7<<24)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 2adcc917806e..571cfe431558 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -481,11 +481,10 @@ static void intel_ddi_clock_get(struct intel_encoder
> *encoder,
> struct intel_crtc_config *pipe_config)
> {
> struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> - enum port port = intel_ddi_get_encoder_port(encoder);
> int link_clock = 0;
> u32 val, pll;
>
> - val = I915_READ(PORT_CLK_SEL(port));
> + val = pipe_config->ddi_pll_sel;
> switch (val & PORT_CLK_SEL_MASK) {
> case PORT_CLK_SEL_LCPLL_810:
> link_clock = 81000;
> @@ -987,40 +986,6 @@ static bool intel_ddi_get_hw_state(struct intel_encoder
> *encoder,
> return intel_ddi_get_port_state(encoder, pipe, port);
> }
>
> -static uint32_t intel_ddi_get_crtc_pll(struct drm_i915_private *dev_priv,
> -enum pipe pipe)
> -{
> - uint32_t temp, ret;
> - enum port port = I915_MAX_PORTS;
> - enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
> - pipe);
> - int i;
> -
> - if (cpu_transcoder == TRANSCODER_EDP) {
> - port = PORT_A;
> - } else {
> - temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> - temp &= TRANS_DDI_PORT_MASK;
> -
> - for (i = PORT_B; i <= PORT_E; i++)
> - if (temp == TRANS_DDI_SELECT_PORT(i))
> - port = i;
> - }
> -
> - if (port == I915_MAX_PORTS) {
> - WARN(1, "Pipe %c enabled on an unknown port\n",
> - pipe_name(pipe));
> - ret = PORT_CLK_SEL_NONE;
> - } else {
> - ret = I915_READ(PORT_CLK_SEL(port));
> - DRM_DEBUG_KMS("Pipe %c connected to port %c using clock "
> - "0x%08x\n", pipe_name(pipe), port_name(port),
> - ret);
> - }
> -
> - return ret;
> -}
> -
> void intel_ddi_setup_hw_pll_state(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -1039,9 +1004,6 @@ void intel_ddi_setup_hw_pll_state(struct drm_device
> *dev)
> continue;
> }
>
> - intel_crtc->config.ddi_pll_sel =
> intel_ddi_get_crtc_pll(dev_priv,
> - pipe);
> -
> switch (intel_crtc->config.ddi_pll_sel) {
> case PORT_CLK_SEL_WRPLL1:
> dev_priv->ddi_plls.wrpll1_refcount++;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 728b5a25cb80..1601da1b57a1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
