Re: [Intel-gfx] [Nouveau] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_
On Tue, Feb 28, 2017 at 04:55:54AM -0800, Joe Perches wrote: > Use a more common logging style. > > Miscellanea: > > o Coalesce formats and realign arguments > o Neaten a few macros now using pr_ > > Signed-off-by: Joe Perches Plenty acks, also merged for 4.12. Thanks, Daniel > --- > drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 - > drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +- > drivers/gpu/drm/gma500/psb_drv.h | 5 ++--- > drivers/gpu/drm/gma500/psb_intel_lvds.c | 7 +++ > drivers/gpu/drm/i915/i915_sw_fence.c | 8 > drivers/gpu/drm/mgag200/mgag200_mode.c| 2 +- > drivers/gpu/drm/msm/msm_drv.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_acpi.c| 7 --- > drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++-- > drivers/gpu/drm/nouveau/nv50_display.c| 22 +++--- > drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +- > drivers/gpu/drm/omapdrm/dss/dsi.c | 17 - > drivers/gpu/drm/omapdrm/dss/dss.c | 3 +-- > drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++- > drivers/gpu/drm/omapdrm/omap_gem.c| 5 ++--- > drivers/gpu/drm/r128/r128_cce.c | 7 +++ > drivers/gpu/drm/ttm/ttm_bo.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 ++ > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 3 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++-- > 20 files changed, 72 insertions(+), 84 deletions(-) > > diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c > b/drivers/gpu/drm/gma500/cdv_intel_lvds.c > index 5efdb7fbb7ee..e64960db3224 100644 > --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c > +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c > @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder > *encoder, > head) { > if (tmp_encoder != encoder > && tmp_encoder->crtc == encoder->crtc) { > - printk(KERN_ERR "Can't enable LVDS and another " > -"encoder on the same pipe\n"); > + pr_err("Can't enable LVDS and another encoder on the > same pipe\n"); > return false; > } > } > @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev, > > failed_find: > mutex_unlock(&dev->mode_config.mutex); > - printk(KERN_ERR "Failed find\n"); > + pr_err("Failed find\n"); > psb_intel_i2c_destroy(gma_encoder->ddc_bus); > failed_ddc: > - printk(KERN_ERR "Failed DDC\n"); > + pr_err("Failed DDC\n"); > psb_intel_i2c_destroy(gma_encoder->i2c_bus); > failed_blc_i2c: > - printk(KERN_ERR "Failed BLC\n"); > + pr_err("Failed BLC\n"); > drm_encoder_cleanup(encoder); > drm_connector_cleanup(connector); > kfree(lvds_priv); > diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c > b/drivers/gpu/drm/gma500/oaktrail_lvds.c > index f7038f12ac76..e6943fef0611 100644 > --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c > +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c > @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct > drm_device *dev, > ((ti->vblank_hi << 8) | ti->vblank_lo); > mode->clock = ti->pixel_clock * 10; > #if 0 > - printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay); > - printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay); > - printk(KERN_INFO "HSS is %d\n", mode->hsync_start); > - printk(KERN_INFO "HSE is %d\n", mode->hsync_end); > - printk(KERN_INFO "htotal is %d\n", mode->htotal); > - printk(KERN_INFO "VSS is %d\n", mode->vsync_start); > - printk(KERN_INFO "VSE is %d\n", mode->vsync_end); > - printk(KERN_INFO "vtotal is %d\n", mode->vtotal); > - printk(KERN_INFO "clock is %d\n", mode->clock); > + pr_info("hdisplay is %d\n", mode->hdisplay); > + pr_info("vdisplay is %d\n", mode->vdisplay); > + pr_info("HSS is %d\n", mode->hsync_start); > + pr_info("HSE is %d\n", mode->hsync_end); > + pr_info("htotal is %d\n", mode->htotal); > + pr_info("VSS is %d\n", mode->vsync_start); > + pr_info("VSE is %d\n", mode->vsync_end); > + pr_info("vtotal is %d\n", mode->vtotal); > + pr_info("clock is %d\n", mode->clock); > #endif > mode_dev->panel_fixed_mode = mode; > } > diff --git a/drivers/gpu/drm/gma500/psb_drv.h > b/drivers/gpu/drm/gma500/psb_drv.h > index 83e22fd4cfc0..83667087d6e5 100644 > --- a/drivers/gpu/drm/gma500/psb_drv.h > +++ b/drivers/gpu/drm/gma500/psb_drv.h > @@ -905,9 +905,8 @@ static inline void REGISTER_WRITE8(struct drm_device *dev, > #define PSB_RSGX32(_offs)
Re: [Intel-gfx] [PATCH v4 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v2.
Op 01-03-17 om 01:49 schreef Laurent Pinchart: > Hi Maarten, > > Thank you for the patch. > > On Thursday 16 Feb 2017 15:47:06 Maarten Lankhorst wrote: >> There are new iterator macros that annotate whether the new or old >> state should be used. This is better than using a state that depends on >> whether it's called before or after swap. For clarity, also rename the >> variables from $obj_state to (old,new)_$obj_state as well. >> >> Changes since v1: >> - Use old/new_*_state for variable names as much as possible. (pinchartl) >> - Expand commit message. >> >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/drm_atomic_helper.c | 431 + >> 1 file changed, 222 insertions(+), 209 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >> b/drivers/gpu/drm/drm_atomic_helper.c index 9203f3e933f7..7d432d9a18cf >> 100644 >> --- a/drivers/gpu/drm/drm_atomic_helper.c >> +++ b/drivers/gpu/drm/drm_atomic_helper.c > [snip] > >> @@ -1929,11 +1926,21 @@ void drm_atomic_helper_cleanup_planes(struct >> drm_device *dev, struct drm_atomic_state *old_state) >> { >> struct drm_plane *plane; >> -struct drm_plane_state *plane_state; >> +struct drm_plane_state *old_plane_state, *new_plane_state; >> int i; >> >> -for_each_plane_in_state(old_state, plane, plane_state, i) { >> +for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, >> new_plane_state, i) { const struct drm_plane_helper_funcs *funcs; >> +struct drm_plane_state *plane_state; >> + >> +/* >> + * This might be called before swapping when commit is > aborted, >> + * in which case we have to free the new state. > s/free/cleanup/ > > Apart from that, > > Reviewed-by: Laurent Pinchart > > You will however need to rebase the series on top of the latest drm-misc as > it > conflicts (at compile time) with Yeah I noticed, patch 1 and 5 are affected, will resend those. Thanks for the review, ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4.1 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v3.
There are new iterator macros that annotate whether the new or old state should be used. This is better than using a state that depends on whether it's called before or after swap. For clarity, also rename the variables from $obj_state to (old,new)_$obj_state as well. Changes since v1: - Use old/new_*_state for variable names as much as possible. (pinchartl) - Expand commit message. Changes since v2: - Rebase on top of link training patches. - free -> cleanup (pinchartl) Signed-off-by: Maarten Lankhorst Reviewed-by: Laurent Pinchart --- drivers/gpu/drm/drm_atomic_helper.c | 446 +++- 1 file changed, 230 insertions(+), 216 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 6b12396f718b..aa1e7609b024 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -63,14 +63,15 @@ */ static void drm_atomic_helper_plane_changed(struct drm_atomic_state *state, + struct drm_plane_state *old_plane_state, struct drm_plane_state *plane_state, struct drm_plane *plane) { struct drm_crtc_state *crtc_state; - if (plane->state->crtc) { + if (old_plane_state->crtc) { crtc_state = drm_atomic_get_existing_crtc_state(state, - plane->state->crtc); + old_plane_state->crtc); if (WARN_ON(!crtc_state)) return; @@ -92,7 +93,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state *state, static int handle_conflicting_encoders(struct drm_atomic_state *state, bool disable_conflicting_encoders) { - struct drm_connector_state *conn_state; + struct drm_connector_state *new_conn_state; struct drm_connector *connector; struct drm_connector_list_iter conn_iter; struct drm_encoder *encoder; @@ -104,15 +105,15 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state, * part of the state. If the same encoder is assigned to multiple * connectors bail out. */ - for_each_connector_in_state(state, connector, conn_state, i) { + for_each_new_connector_in_state(state, connector, new_conn_state, i) { const struct drm_connector_helper_funcs *funcs = connector->helper_private; struct drm_encoder *new_encoder; - if (!conn_state->crtc) + if (!new_conn_state->crtc) continue; if (funcs->atomic_best_encoder) - new_encoder = funcs->atomic_best_encoder(connector, conn_state); + new_encoder = funcs->atomic_best_encoder(connector, new_conn_state); else if (funcs->best_encoder) new_encoder = funcs->best_encoder(connector); else @@ -166,20 +167,20 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state, goto out; } - conn_state = drm_atomic_get_connector_state(state, connector); - if (IS_ERR(conn_state)) { - ret = PTR_ERR(conn_state); + new_conn_state = drm_atomic_get_connector_state(state, connector); + if (IS_ERR(new_conn_state)) { + ret = PTR_ERR(new_conn_state); goto out; } DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], disabling [CONNECTOR:%d:%s]\n", encoder->base.id, encoder->name, -conn_state->crtc->base.id, conn_state->crtc->name, +new_conn_state->crtc->base.id, new_conn_state->crtc->name, connector->base.id, connector->name); - crtc_state = drm_atomic_get_existing_crtc_state(state, conn_state->crtc); + crtc_state = drm_atomic_get_existing_crtc_state(state, new_conn_state->crtc); - ret = drm_atomic_set_crtc_for_connector(conn_state, NULL); + ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL); if (ret) goto out; @@ -245,22 +246,22 @@ steal_encoder(struct drm_atomic_state *state, { struct drm_crtc_state *crtc_state; struct drm_connector *connector; - struct drm_connector_state *connector_state; + struct drm_connector_state *old_connector_state, *new_connector_state; int i; - for_each_connector_in_state(state, connector, connector_state, i) { + for_each_oldnew_connector_in_state(state, connector, old_connector_state, new_connector_state, i) { struct drm_crtc *en
[Intel-gfx] [PATCH v4.1 4/5] drm/atomic: Convert get_existing_state callers to get_old/new_state, v4.
This is a straightforward conversion that converts all the users of get_existing_state in atomic core to use get_old_state or get_new_state Changes since v1: - Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state. Changes since v2: - Use the correct state in disable_outputs() Changes since v3: - Rebase for link status training. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic.c| 6 ++--- drivers/gpu/drm/drm_atomic_helper.c | 47 + drivers/gpu/drm/drm_blend.c | 3 +-- drivers/gpu/drm/drm_simple_kms_helper.c | 4 +-- 4 files changed, 30 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 236d947011f9..9b892af7811a 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1374,8 +1374,8 @@ drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state, return 0; if (conn_state->crtc) { - crtc_state = drm_atomic_get_existing_crtc_state(conn_state->state, - conn_state->crtc); + crtc_state = drm_atomic_get_new_crtc_state(conn_state->state, + conn_state->crtc); crtc_state->connector_mask &= ~(1 << drm_connector_index(conn_state->connector)); @@ -1492,7 +1492,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state *state, { struct drm_plane *plane; - WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc)); + WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc)); drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) { struct drm_plane_state *plane_state = diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index bc96d31bd388..4e26b73bb0d5 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -70,8 +70,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state *state, struct drm_crtc_state *crtc_state; if (old_plane_state->crtc) { - crtc_state = drm_atomic_get_existing_crtc_state(state, - old_plane_state->crtc); + crtc_state = drm_atomic_get_new_crtc_state(state, + old_plane_state->crtc); if (WARN_ON(!crtc_state)) return; @@ -80,8 +80,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state *state, } if (plane_state->crtc) { - crtc_state = drm_atomic_get_existing_crtc_state(state, - plane_state->crtc); + crtc_state = drm_atomic_get_new_crtc_state(state, plane_state->crtc); if (WARN_ON(!crtc_state)) return; @@ -150,7 +149,7 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state, drm_for_each_connector_iter(connector, &conn_iter) { struct drm_crtc_state *crtc_state; - if (drm_atomic_get_existing_connector_state(state, connector)) + if (drm_atomic_get_new_connector_state(state, connector)) continue; encoder = connector->state->best_encoder; @@ -178,7 +177,7 @@ static int handle_conflicting_encoders(struct drm_atomic_state *state, new_conn_state->crtc->base.id, new_conn_state->crtc->name, connector->base.id, connector->name); - crtc_state = drm_atomic_get_existing_crtc_state(state, new_conn_state->crtc); + crtc_state = drm_atomic_get_new_crtc_state(state, new_conn_state->crtc); ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL); if (ret) @@ -219,7 +218,7 @@ set_best_encoder(struct drm_atomic_state *state, */ WARN_ON(!crtc && encoder != conn_state->best_encoder); if (crtc) { - crtc_state = drm_atomic_get_existing_crtc_state(state, crtc); + crtc_state = drm_atomic_get_new_crtc_state(state, crtc); crtc_state->encoder_mask &= ~(1 << drm_encoder_index(conn_state->best_encoder)); @@ -230,7 +229,7 @@ set_best_encoder(struct drm_atomic_state *state, crtc = conn_state->crtc; WARN_ON(!crtc); if (crtc) { - crtc_state = drm_atomic_get_existing_crtc_state(state, crtc); + crtc_state = drm_atomic_get_new_crtc_state(state, crtc); crtc_state->encoder_mask |= 1 << drm_encode
[Intel-gfx] [PATCH i-g-t v3] Add the new tool for create GVT-g Linux guest based on KVMGT
GVT-g (Intel® Graphics Virtualization Technology) is a full GPU virtualization solution with mediated pass-through support. This tool is for create basic Linux guest based on KVMGT with VFIO framework, it including create vgpu, create guest, check IP address, destroy guest, remove vgpu,check dmesg log, etc functions. v2: Treat this case as a free-standing tool, with detect & skip when it's not running on GVT-g capable platform or running without the required tools. v3: Make some optimizations: like "update the generate mac address scripts", "provide more useful information for end user", etc. Signed-off-by: Terrence Xu Signed-off-by: Benyu Xu --- tools/.gitignore| 1 + tools/Makefile.sources | 1 + tools/intel_gvtg_test.c | 359 3 files changed, 361 insertions(+) create mode 100644 tools/intel_gvtg_test.c diff --git a/tools/.gitignore b/tools/.gitignore index 13825a3..f777f2b 100644 --- a/tools/.gitignore +++ b/tools/.gitignore @@ -30,5 +30,6 @@ intel_reg_checker intel_residency intel_stepping intel_watermark +intel_gvtg_test skl_compute_wrpll skl_ddb_allocation diff --git a/tools/Makefile.sources b/tools/Makefile.sources index e2451ea..5f1e747 100644 --- a/tools/Makefile.sources +++ b/tools/Makefile.sources @@ -30,6 +30,7 @@ tools_prog_lists =\ intel_stepping \ intel_watermark \ intel_gem_info \ + intel_gvtg_test \ $(NULL) dist_bin_SCRIPTS = intel_gpu_abrt diff --git a/tools/intel_gvtg_test.c b/tools/intel_gvtg_test.c new file mode 100644 index 000..ec6dd99 --- /dev/null +++ b/tools/intel_gvtg_test.c @@ -0,0 +1,359 @@ +/* + * Copyright 2016 Intel Corporation + * Terrence Xu + * + * 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 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. + */ + +/* + * This program is intended for testing of validate GVT-g virtual machine + * creation of allow for testing of KVMGT / XenGT (the tool should be root + * privilege only). + * + * TODO: + * Enable more GVT-g related test cases. + */ +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include "igt.h" +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RANDOM(x) (rand() % x) + + +static char uuid[40]; +static char guest_ip[32]; + +static char mac_addr[20] = {0}; +static char qemu_path[PATH_MAX] = {0}; +static char hda_path[PATH_MAX] = {0}; +static char bios_path[PATH_MAX] = {0}; + +static int super_system(const char *cmd, char *retmsg, int msg_len) +{ +FILE *fp; +int res = -1; +if (cmd == NULL || retmsg == NULL || msg_len < 0) { +igt_info("Error: %s system parameter invalid!\n", __func__); +return 1; +} +fp = popen(cmd, "r"); +if (fp == NULL) { +perror("popen"); +igt_info("Error: %s popen error: %s\n", __func__, strerror(errno)); +return 2; +} else { +memset(retmsg, 0, msg_len); +while (fgets(retmsg, msg_len, fp)) { +; +} +res = pclose(fp); +if (res == -1) { +igt_info("Error:%s close popen file pointer fp error!\n", __func__); +return 3; +} +retmsg[strlen(retmsg) - 1] = '\0'; +return 0; +} +} + +static int check_gvtg_support(void) +{ +DIR *mdevdir = opendir("/sys/bus/pci/devices/:00:02.0/" +"mdev_supported_types"); + +if (mdevdir == NULL) { +return 1; +} +closedir(mdevdir); +return 0; +} + +static int check_tools(void) +{ +if (system("which uuidgen > /dev/null") != 0) { +return 1; +} else if (system("which arp-scan > /dev/null") != 0) { +return 2; +} else if (system("which /etc/qemu-ifup > /dev/null") != 0) { +return 3; +} +r
Re: [Intel-gfx] [PATCH] drm/i915: Tighten mmio arrays for MIPI_PORT
On Tue, Feb 28, 2017 at 05:00:28PM +0200, Jani Nikula wrote: > On Tue, 28 Feb 2017, Chris Wilson wrote: > > drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’: > > drivers/gpu/drm/i915/intel_dsi.c:1308:1: error: the frame size of 2488 > > bytes is larger than 2048 bytes [-Werror=frame-larger-than=] > > > > which is caused by the compiling expanding every _MIPI_PORT into an > > on-stack array of u32[3] at every callsite. Not sure why only one > > machine/compiler appears susceptible, but with a minor tweak to _MIPI_PORT > > we can defer the error until later. > > > > This is a partial revert of commit ce64645d86ac ("drm/i915: use variadic > > macros and arrays to choose port/pipe based registers") for a particular > > bad offender. > > > > Signed-off-by: Chris Wilson > > Cc: Jani Nikula > > :( > > Acked-by: Jani Nikula After a night's rest, it still doesn't compile, so pushed. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: use drm_connector_list_iter in intel_opregion.c
One case where I nuked a now unecessary locking, otherwise all just boring stuff. v2: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding Cc: Maarten Lankhorst Cc: Jani Nikula Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_opregion.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index 4a862a358c70..f2a954e1a59e 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -434,6 +434,7 @@ int intel_opregion_notify_adapter(struct drm_i915_private *dev_priv, static u32 asle_set_backlight(struct drm_i915_private *dev_priv, u32 bclp) { struct intel_connector *connector; + struct drm_connector_list_iter conn_iter; struct opregion_asle *asle = dev_priv->opregion.asle; struct drm_device *dev = &dev_priv->drm; @@ -458,8 +459,10 @@ static u32 asle_set_backlight(struct drm_i915_private *dev_priv, u32 bclp) * only one). */ DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp); - for_each_intel_connector(dev, connector) + drm_connector_list_iter_begin(dev, &conn_iter); + for_each_intel_connector_iter(connector, &conn_iter) intel_panel_set_backlight_acpi(connector, bclp, 255); + drm_connector_list_iter_end(&conn_iter); asle->cblv = DIV_ROUND_UP(bclp * 100, 255) | ASLE_CBLV_VALID; drm_modeset_unlock(&dev->mode_config.connection_mutex); @@ -701,6 +704,7 @@ static void intel_didl_outputs(struct drm_i915_private *dev_priv) { struct intel_opregion *opregion = &dev_priv->opregion; struct intel_connector *connector; + struct drm_connector_list_iter conn_iter; int i = 0, max_outputs; int display_index[16] = {}; @@ -714,7 +718,8 @@ static void intel_didl_outputs(struct drm_i915_private *dev_priv) max_outputs = ARRAY_SIZE(opregion->acpi->didl) + ARRAY_SIZE(opregion->acpi->did2); - for_each_intel_connector(&dev_priv->drm, connector) { + drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter); + for_each_intel_connector_iter(connector, &conn_iter) { u32 device_id, type; device_id = acpi_display_type(connector); @@ -729,6 +734,7 @@ static void intel_didl_outputs(struct drm_i915_private *dev_priv) set_did(opregion, i, device_id); i++; } + drm_connector_list_iter_end(&conn_iter); DRM_DEBUG_KMS("%d outputs detected\n", i); @@ -745,6 +751,7 @@ static void intel_setup_cadls(struct drm_i915_private *dev_priv) { struct intel_opregion *opregion = &dev_priv->opregion; struct intel_connector *connector; + struct drm_connector_list_iter conn_iter; int i = 0; /* @@ -757,11 +764,13 @@ static void intel_setup_cadls(struct drm_i915_private *dev_priv) * Note that internal panels should be at the front of the connector * list already, ensuring they're not left out. */ - for_each_intel_connector(&dev_priv->drm, connector) { + drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter); + for_each_intel_connector_iter(connector, &conn_iter) { if (i >= ARRAY_SIZE(opregion->acpi->cadl)) break; opregion->acpi->cadl[i++] = connector->acpi_device_id; } + drm_connector_list_iter_end(&conn_iter); /* If fewer than 8 active devices, the list must be null terminated */ if (i < ARRAY_SIZE(opregion->acpi->cadl)) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: use for_each_intel_connector_iter in intel_display.c
This gets rid of the last users of for_each_intel_connector(), remove that too. At first I wasn't sure whether the 2 loops in the modeset state checker should instead only loop over the connectors in the atomic commit. But we never add connectors to an atomic update if they don't (or won't have) a CRTC assigned, which means there'd be a gap in check coverage. Hence loop over everything on those too. v2: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding Cc: Maarten Lankhorst Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.h | 5 - drivers/gpu/drm/i915/intel_display.c | 20 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index eb670d819134..32a67f438021 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -489,11 +489,6 @@ struct i915_hotplug { &(dev)->mode_config.encoder_list, \ base.head) -#define for_each_intel_connector(dev, intel_connector) \ - list_for_each_entry(intel_connector,\ - &(dev)->mode_config.connector_list, \ - base.head) - #define for_each_intel_connector_iter(intel_connector, iter) \ while ((intel_connector = to_intel_connector(drm_connector_list_iter_next(iter diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0f30362b4ad8..f6560ab3531d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -10977,8 +10977,10 @@ static const struct drm_crtc_helper_funcs intel_helper_funcs = { static void intel_modeset_update_connector_atomic_state(struct drm_device *dev) { struct intel_connector *connector; + struct drm_connector_list_iter conn_iter; - for_each_intel_connector(dev, connector) { + drm_connector_list_iter_begin(dev, &conn_iter); + for_each_intel_connector_iter(connector, &conn_iter) { if (connector->base.state->crtc) drm_connector_unreference(&connector->base); @@ -10994,6 +10996,7 @@ static void intel_modeset_update_connector_atomic_state(struct drm_device *dev) connector->base.state->crtc = NULL; } } + drm_connector_list_iter_end(&conn_iter); } static void @@ -11899,6 +11902,7 @@ verify_encoder_state(struct drm_device *dev) { struct intel_encoder *encoder; struct intel_connector *connector; + struct drm_connector_list_iter conn_iter; for_each_intel_encoder(dev, encoder) { bool enabled = false; @@ -11908,7 +11912,8 @@ verify_encoder_state(struct drm_device *dev) encoder->base.base.id, encoder->base.name); - for_each_intel_connector(dev, connector) { + drm_connector_list_iter_begin(dev, &conn_iter); + for_each_intel_connector_iter(connector, &conn_iter) { if (connector->base.state->best_encoder != &encoder->base) continue; enabled = true; @@ -11917,6 +11922,7 @@ verify_encoder_state(struct drm_device *dev) encoder->base.crtc, "connector's crtc doesn't match encoder crtc\n"); } + drm_connector_list_iter_end(&conn_iter); I915_STATE_WARN(!!encoder->base.crtc != enabled, "encoder's enabled state mismatch " @@ -15009,6 +15015,7 @@ int intel_modeset_init(struct drm_device *dev) static void intel_enable_pipe_a(struct drm_device *dev) { struct intel_connector *connector; + struct drm_connector_list_iter conn_iter; struct drm_connector *crt = NULL; struct intel_load_detect_pipe load_detect_temp; struct drm_modeset_acquire_ctx *ctx = dev->mode_config.acquire_ctx; @@ -15016,12 +15023,14 @@ static void intel_enable_pipe_a(struct drm_device *dev) /* We can't just switch on the pipe A, we need to set things up with a * proper mode and output configuration. As a gross hack, enable pipe A * by enabling the load detect pipe once. */ - for_each_intel_connector(dev, connector) { + drm_connector_list_iter_begin(dev, &conn_iter); + for_each_intel_connector_iter(connector, &conn_iter) { if (connector->encoder->type == INTEL_OUTPUT_ANALOG) { crt = &connector->base; break; } } + drm_connector_list_iter_end(&conn_iter); if (!crt) return; @@ -15267,6 +15276,7 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev) struct intel_crtc *crtc; struct intel_enc
[Intel-gfx] [PATCH 6/6] drm/i915: Fix up verify_encoder_state
The trouble here is that looking at all connector->state in the verifier isn't good, because that's run from the commit work, which doesn't hold the connection_mutex. Which means we're only allowed to look at states in our atomic update. The simple fix for future proofing would be to switch over to drm_for_each_connector_in_state, but that has the problem that the verification then fails if not all connectors are in the state. And we also need to be careful to check both old and new encoders, and not screw things up when an encoder gets reassigned. Note that this isn't the full fix, since we still look at connector->state. To fix that, we need Maarten's patch series to switch over to state pointers within drm_atomic_state, but that's a different series. v2: Use oldnew iterator (Maarten). v3: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding Cc: Maarten Lankhorst Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 28 +--- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f6560ab3531d..958e68430ca3 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11898,31 +11898,37 @@ verify_connector_state(struct drm_device *dev, } static void -verify_encoder_state(struct drm_device *dev) +verify_encoder_state(struct drm_device *dev, struct drm_atomic_state *state) { struct intel_encoder *encoder; - struct intel_connector *connector; - struct drm_connector_list_iter conn_iter; + struct drm_connector *connector; + struct drm_connector_state *old_conn_state, *new_conn_state; + int i; for_each_intel_encoder(dev, encoder) { - bool enabled = false; + bool enabled = false, found = false; enum pipe pipe; DRM_DEBUG_KMS("[ENCODER:%d:%s]\n", encoder->base.base.id, encoder->base.name); - drm_connector_list_iter_begin(dev, &conn_iter); - for_each_intel_connector_iter(connector, &conn_iter) { - if (connector->base.state->best_encoder != &encoder->base) + for_each_oldnew_connector_in_state(state, connector, old_conn_state, + new_conn_state, i) { + if (old_conn_state->best_encoder == &encoder->base) + found = true; + + if (new_conn_state->best_encoder != &encoder->base) continue; - enabled = true; + found = enabled = true; - I915_STATE_WARN(connector->base.state->crtc != + I915_STATE_WARN(new_conn_state->crtc != encoder->base.crtc, "connector's crtc doesn't match encoder crtc\n"); } - drm_connector_list_iter_end(&conn_iter); + + if (!found) + continue; I915_STATE_WARN(!!encoder->base.crtc != enabled, "encoder's enabled state mismatch " @@ -12124,7 +12130,7 @@ static void intel_modeset_verify_disabled(struct drm_device *dev, struct drm_atomic_state *state) { - verify_encoder_state(dev); + verify_encoder_state(dev, state); verify_connector_state(dev, state, NULL); verify_disabled_dpll_state(dev); } -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Make intel_get_pipe_from_connector atomic
Drive-by fixup while looking at all the connector_list walkers - holding connection_mutex does actually _not_ give you locking to look at the legacy drm_connector->encoder->crtc pointer chain. That one is solely owned by the atomic commit workers. Instead we must inspect the atomic state. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7673d5d9e74a..0f30362b4ad8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13875,15 +13875,14 @@ static int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe) enum pipe intel_get_pipe_from_connector(struct intel_connector *connector) { - struct drm_encoder *encoder = connector->base.encoder; struct drm_device *dev = connector->base.dev; WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)); - if (!encoder || WARN_ON(!encoder->crtc)) + if (!connector->base.state->crtc) return INVALID_PIPE; - return to_intel_crtc(encoder->crtc)->pipe; + return to_intel_crtc(connector->base.state->crtc)->pipe; } int intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data, -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: use drm_connector_list_iter in intel_hotplug.c
Nothing special, just rote conversion. v2: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding Cc: Maarten Lankhorst Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_hotplug.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index 0756bdc672b3..95220883ec0f 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -150,16 +150,17 @@ static bool intel_hpd_irq_storm_detect(struct drm_i915_private *dev_priv, static void intel_hpd_irq_storm_disable(struct drm_i915_private *dev_priv) { struct drm_device *dev = &dev_priv->drm; - struct drm_mode_config *mode_config = &dev->mode_config; struct intel_connector *intel_connector; struct intel_encoder *intel_encoder; struct drm_connector *connector; + struct drm_connector_list_iter conn_iter; enum hpd_pin pin; bool hpd_disabled = false; assert_spin_locked(&dev_priv->irq_lock); - list_for_each_entry(connector, &mode_config->connector_list, head) { + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { if (connector->polled != DRM_CONNECTOR_POLL_HPD) continue; @@ -182,6 +183,7 @@ static void intel_hpd_irq_storm_disable(struct drm_i915_private *dev_priv) | DRM_CONNECTOR_POLL_DISCONNECT; hpd_disabled = true; } + drm_connector_list_iter_end(&conn_iter); /* Enable polling and queue hotplug re-enabling. */ if (hpd_disabled) { @@ -197,7 +199,6 @@ static void intel_hpd_irq_storm_reenable_work(struct work_struct *work) container_of(work, typeof(*dev_priv), hotplug.reenable_work.work); struct drm_device *dev = &dev_priv->drm; - struct drm_mode_config *mode_config = &dev->mode_config; int i; intel_runtime_pm_get(dev_priv); @@ -205,13 +206,15 @@ static void intel_hpd_irq_storm_reenable_work(struct work_struct *work) spin_lock_irq(&dev_priv->irq_lock); for_each_hpd_pin(i) { struct drm_connector *connector; + struct drm_connector_list_iter conn_iter; if (dev_priv->hotplug.stats[i].state != HPD_DISABLED) continue; dev_priv->hotplug.stats[i].state = HPD_ENABLED; - list_for_each_entry(connector, &mode_config->connector_list, head) { + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { struct intel_connector *intel_connector = to_intel_connector(connector); if (intel_connector->encoder->hpd_pin == i) { @@ -223,6 +226,7 @@ static void intel_hpd_irq_storm_reenable_work(struct work_struct *work) connector->polled = DRM_CONNECTOR_POLL_HPD; } } + drm_connector_list_iter_end(&conn_iter); } if (dev_priv->display_irqs_enabled && dev_priv->display.hpd_irq_setup) dev_priv->display.hpd_irq_setup(dev_priv); @@ -308,14 +312,14 @@ static void i915_hotplug_work_func(struct work_struct *work) struct drm_i915_private *dev_priv = container_of(work, struct drm_i915_private, hotplug.hotplug_work); struct drm_device *dev = &dev_priv->drm; - struct drm_mode_config *mode_config = &dev->mode_config; struct intel_connector *intel_connector; struct intel_encoder *intel_encoder; struct drm_connector *connector; + struct drm_connector_list_iter conn_iter; bool changed = false; u32 hpd_event_bits; - mutex_lock(&mode_config->mutex); + mutex_lock(&dev->mode_config.mutex); DRM_DEBUG_KMS("running encoder hotplug functions\n"); spin_lock_irq(&dev_priv->irq_lock); @@ -328,7 +332,8 @@ static void i915_hotplug_work_func(struct work_struct *work) spin_unlock_irq(&dev_priv->irq_lock); - list_for_each_entry(connector, &mode_config->connector_list, head) { + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { intel_connector = to_intel_connector(connector); if (!intel_connector->encoder) continue; @@ -342,7 +347,8 @@ static void i915_hotplug_work_func(struct work_struct *work) changed = true; } } - mutex_unlock(&mode_config->mutex); + drm_connector_list_iter_end(&conn_iter); + mutex_unlock(&dev->mode_config.mutex); if (changed) drm_kms_helper_hotplug_event(dev); @@ -490,15 +4
[Intel-gfx] [PATCH 1/6] drm/i915: Use drm_connector_list_iter in debugfs
While at it also try to reduce the locking a bit to what's really just needed instead of everything that we could possibly lock. Added a new for_each_intel_connector_iter which includes the cast to intel_connector. Otherwise just plain transformation with nothing special going on. v2: Review from Maarten: - Stick with modeset_lock_all in sink_crc, it looks at crtc->state. - Fix up early loop exit in i915_displayport_test_active_write. v3: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding Cc: Maarten Lankhorst Reviewed-by: Maarten Lankhorst (v2) Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 59 - drivers/gpu/drm/i915/i915_drv.h | 3 ++ 2 files changed, 42 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 1a28b5279bec..7449458131aa 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2730,12 +2730,14 @@ static int i915_sink_crc(struct seq_file *m, void *data) struct drm_i915_private *dev_priv = node_to_i915(m->private); struct drm_device *dev = &dev_priv->drm; struct intel_connector *connector; + struct drm_connector_list_iter conn_iter; struct intel_dp *intel_dp = NULL; int ret; u8 crc[6]; drm_modeset_lock_all(dev); - for_each_intel_connector(dev, connector) { + drm_connector_list_iter_begin(dev, &conn_iter); + for_each_intel_connector_iter(connector, &conn_iter) { struct drm_crtc *crtc; if (!connector->base.state->best_encoder) @@ -2761,6 +2763,7 @@ static int i915_sink_crc(struct seq_file *m, void *data) } ret = -ENODEV; out: + drm_connector_list_iter_end(&conn_iter); drm_modeset_unlock_all(dev); return ret; } @@ -3197,9 +3200,9 @@ static int i915_display_info(struct seq_file *m, void *unused) struct drm_device *dev = &dev_priv->drm; struct intel_crtc *crtc; struct drm_connector *connector; + struct drm_connector_list_iter conn_iter; intel_runtime_pm_get(dev_priv); - drm_modeset_lock_all(dev); seq_printf(m, "CRTC info\n"); seq_printf(m, "-\n"); for_each_intel_crtc(dev, crtc) { @@ -3207,6 +3210,7 @@ static int i915_display_info(struct seq_file *m, void *unused) struct intel_crtc_state *pipe_config; int x, y; + drm_modeset_lock(&crtc->base.mutex, NULL); pipe_config = to_intel_crtc_state(crtc->base.state); seq_printf(m, "CRTC %d: pipe: %c, active=%s, (size=%dx%d), dither=%s, bpp=%d\n", @@ -3231,15 +3235,19 @@ static int i915_display_info(struct seq_file *m, void *unused) seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n", yesno(!crtc->cpu_fifo_underrun_disabled), yesno(!crtc->pch_fifo_underrun_disabled)); + drm_modeset_unlock(&crtc->base.mutex); } seq_printf(m, "\n"); seq_printf(m, "Connector info\n"); seq_printf(m, "--\n"); - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { + mutex_lock(&dev->mode_config.mutex); + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) intel_connector_info(m, connector); - } - drm_modeset_unlock_all(dev); + drm_connector_list_iter_end(&conn_iter); + mutex_unlock(&dev->mode_config.mutex); + intel_runtime_pm_put(dev_priv); return 0; @@ -3566,13 +3574,16 @@ static void drrs_status_per_crtc(struct seq_file *m, struct i915_drrs *drrs = &dev_priv->drrs; int vrefresh = 0; struct drm_connector *connector; + struct drm_connector_list_iter conn_iter; - drm_for_each_connector(connector, dev) { + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { if (connector->state->crtc != &intel_crtc->base) continue; seq_printf(m, "%s:\n", connector->name); } + drm_connector_list_iter_end(&conn_iter); if (dev_priv->vbt.drrs_type == STATIC_DRRS_SUPPORT) seq_puts(m, "\tVBT: DRRS_type: Static"); @@ -3658,9 +3669,10 @@ static int i915_dp_mst_info(struct seq_file *m, void *unused) struct intel_encoder *intel_encoder; struct intel_digital_port *intel_dig_port; struct drm_connector *connector; + struct drm_connector_list_iter conn_iter; - drm_modeset_lock_all(dev); - drm_for_each_connector(connector, dev) { + drm_connector_list_iter_begin(dev, &conn_iter); + drm_for_each_connector_iter(connector, &conn_iter) { if (connector->connect
Re: [Intel-gfx] [PATCH] #1: test capitalizing PATCH
On Wed, 01 Mar 2017, Hans de Goede wrote: > Hi, > > On 28-02-17 17:31, Jani Nikula wrote: >> >> Cc: Hans, this probably applies to you as well. > > I'm already always using git-send-email, so whatever the > reason why the CI system is not picking up my patches, this > aint it. It doesn't look like your patches match [1], though. Do you have the sendemail.xmailer config option set to false? BR, Jani. > > Regards, > > Hans > >> >> On Tue, 28 Feb 2017, Dan Carpenter wrote: >>> The new version patchwork is filtering out my patches for some reason. >>> Test if it's because it now insists on a capital [PATCH] in the subject. >>> >>> Patchwork should be more version control agnostic than that. >> >> The patchwork flavor at freedesktop.org expects patches are sent using >> git send-email [1]. I hear otherwise there were too many false >> positives. >> >> Please either use git send-email, or add >> >> X-Mailer: git-send-email haha only kidding >> >> header into your patch mails. >> >> I'm sorry for the inconvenience and lack of transparency on >> this. Apparently git send-email is so ubiquitous nowadays that this >> hasn't been much of a problem. >> >> >> BR, >> Jani. >> >> >> [1] >> https://github.com/dlespiau/patchwork/blob/master/patchwork/bin/parsemail.py#L323 >> -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4.1 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v3.
Hi Maarten, Thank you for the resend. For the whole series, Tested-by: Laurent Pinchart On Wednesday 01 Mar 2017 10:21:26 Maarten Lankhorst wrote: > There are new iterator macros that annotate whether the new or old > state should be used. This is better than using a state that depends on > whether it's called before or after swap. For clarity, also rename the > variables from $obj_state to (old,new)_$obj_state as well. > > Changes since v1: > - Use old/new_*_state for variable names as much as possible. (pinchartl) > - Expand commit message. > Changes since v2: > - Rebase on top of link training patches. > - free -> cleanup (pinchartl) > > Signed-off-by: Maarten Lankhorst > Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/drm_atomic_helper.c | 446 - > 1 file changed, 230 insertions(+), 216 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c index 6b12396f718b..aa1e7609b024 > 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -63,14 +63,15 @@ > */ > static void > drm_atomic_helper_plane_changed(struct drm_atomic_state *state, > + struct drm_plane_state *old_plane_state, > struct drm_plane_state *plane_state, > struct drm_plane *plane) > { > struct drm_crtc_state *crtc_state; > > - if (plane->state->crtc) { > + if (old_plane_state->crtc) { > crtc_state = drm_atomic_get_existing_crtc_state(state, > - plane->state- >crtc); > + old_plane_state->crtc); > > if (WARN_ON(!crtc_state)) > return; > @@ -92,7 +93,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state > *state, static int handle_conflicting_encoders(struct drm_atomic_state > *state, bool disable_conflicting_encoders) > { > - struct drm_connector_state *conn_state; > + struct drm_connector_state *new_conn_state; > struct drm_connector *connector; > struct drm_connector_list_iter conn_iter; > struct drm_encoder *encoder; > @@ -104,15 +105,15 @@ static int handle_conflicting_encoders(struct > drm_atomic_state *state, * part of the state. If the same encoder is > assigned to multiple * connectors bail out. >*/ > - for_each_connector_in_state(state, connector, conn_state, i) { > + for_each_new_connector_in_state(state, connector, new_conn_state, i) { > const struct drm_connector_helper_funcs *funcs = > connector->helper_private; struct drm_encoder *new_encoder; > > - if (!conn_state->crtc) > + if (!new_conn_state->crtc) > continue; > > if (funcs->atomic_best_encoder) > - new_encoder = funcs->atomic_best_encoder(connector, conn_state); > + new_encoder = funcs->atomic_best_encoder(connector, new_conn_state); > else if (funcs->best_encoder) > new_encoder = funcs->best_encoder(connector); > else > @@ -166,20 +167,20 @@ static int handle_conflicting_encoders(struct > drm_atomic_state *state, goto out; > } > > - conn_state = drm_atomic_get_connector_state(state, connector); > - if (IS_ERR(conn_state)) { > - ret = PTR_ERR(conn_state); > + new_conn_state = drm_atomic_get_connector_state(state, connector); > + if (IS_ERR(new_conn_state)) { > + ret = PTR_ERR(new_conn_state); > goto out; > } > > DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], disabling > [CONNECTOR:%d:%s]\n", encoder->base.id, encoder->name, > - conn_state->crtc->base.id, conn_state->crtc- >name, > + new_conn_state->crtc->base.id, new_conn_state->crtc->name, >connector->base.id, connector->name); > > - crtc_state = drm_atomic_get_existing_crtc_state(state, conn_state->crtc); > + crtc_state = drm_atomic_get_existing_crtc_state(state, > new_conn_state->crtc); > > - ret = drm_atomic_set_crtc_for_connector(conn_state, NULL); > + ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL); > if (ret) > goto out; > > @@ -245,22 +246,22 @@ steal_encoder(struct drm_atomic_state *state, > { > struct drm_crtc_state *crtc_state; > struct drm_connector *connector; > - struct drm_connector_state *connector_state; > + struct drm_connector_state *old_connector_state, *new_connector_state; > int i; > > - for_each_connector_in_state(state, connector, connector_state, i) { > + for_each_oldnew_connector_in_s
Re: [Intel-gfx] [PATCH] #1: test capitalizing PATCH
Hi, On 01-03-17 10:57, Jani Nikula wrote: On Wed, 01 Mar 2017, Hans de Goede wrote: Hi, On 28-02-17 17:31, Jani Nikula wrote: Cc: Hans, this probably applies to you as well. I'm already always using git-send-email, so whatever the reason why the CI system is not picking up my patches, this aint it. It doesn't look like your patches match [1], though. Do you have the sendemail.xmailer config option set to false? Nope, just send myself a test patch: Date: Wed, 1 Mar 2017 11:05:32 +0100 Message-Id: <20170301100532.26692-1-hdego...@redhat.com> X-Mailer: git-send-email 2.9.3 Result: 250 But indeed the header is gone when it hits my own Inbox, seems this gets stripped by the Red Hat smtp server somehow ? I will file a ticket with our it department for this. Regards, Hans BR, Jani. Regards, Hans On Tue, 28 Feb 2017, Dan Carpenter wrote: The new version patchwork is filtering out my patches for some reason. Test if it's because it now insists on a capital [PATCH] in the subject. Patchwork should be more version control agnostic than that. The patchwork flavor at freedesktop.org expects patches are sent using git send-email [1]. I hear otherwise there were too many false positives. Please either use git send-email, or add X-Mailer: git-send-email haha only kidding header into your patch mails. I'm sorry for the inconvenience and lack of transparency on this. Apparently git send-email is so ubiquitous nowadays that this hasn't been much of a problem. BR, Jani. [1] https://github.com/dlespiau/patchwork/blob/master/patchwork/bin/parsemail.py#L323 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Add a new connector atomic property for link status
On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote: > /** > + * enum drm_link_status - connector's link_status property value > + * > + * This enum is used as the connector's link status property value. > + * It is set to the values defined in uapi. > + */ > +enum drm_link_status { > + DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD, > + DRM_LINK_STATUS_BAD = DRM_MODE_LINK_STATUS_BAD, We now have a new warning here when building docs. Please fix in a follow-up patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/designware-baytrail for 4.12
Hi all, topic/designware-baytrail-2017-03-01: Baytrail PMIC vs. PMU race fixes from Hans de Goede I opted to put all the patches for all subsystems into the topic branches, so that if needed, each subsystem can apply refactorings to the entire thing. Which might be needed since we're very early in the 4.12 cycle. This has baked for a few days in the drm-intel CI and looks good afaics. I'll pull this into drm-intel.git for 4.12, feel free to pull into any other subsystem where needed. Cheers, Daniel The following changes since commit 64a577196d66b44e37384bc5c4d78c61f59d5b2a: lib/Kconfig: make PRIME_NUMBERS not user selectable. (2017-02-24 12:11:21 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/topic/designware-baytrail-2017-03-01 for you to fetch changes up to ca9b131b63aaf21419725bcf90497877d6bf6271: drm/i915: Listen for PMIC bus access notifications (2017-02-26 21:23:13 +0100) Baytrail PMIC vs. PMU race fixes from Hans de Goede Hans de Goede (12): x86/platform/intel/iosf_mbi: Add a mutex for P-Unit access x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier i2c: designware: Rename accessor_flags to flags i2c: designware-baytrail: Pass dw_i2c_dev into helper functions i2c: designware-baytrail: Only check iosf_mbi_available() for shared hosts i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while holding the punit semaphore i2c: designware-baytrail: Fix race when resetting the semaphore i2c: designware-baytrail: Add support for cherrytrail i2c: designware-baytrail: Acquire P-Unit access on bus acquire i2c: designware-baytrail: Call pmic_bus_access_notifier_chain drm/i915: Add intel_uncore_suspend / resume functions drm/i915: Listen for PMIC bus access notifications arch/x86/include/asm/iosf_mbi.h | 85 arch/x86/platform/intel/iosf_mbi.c | 49 drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/i915_drv.c | 6 +- drivers/gpu/drm/i915/i915_drv.h | 7 +-- drivers/gpu/drm/i915/intel_uncore.c | 53 +++-- drivers/i2c/busses/i2c-designware-baytrail.c | 83 +++ drivers/i2c/busses/i2c-designware-core.c | 14 ++--- drivers/i2c/busses/i2c-designware-core.h | 13 - drivers/i2c/busses/i2c-designware-pcidrv.c | 26 ++--- drivers/i2c/busses/i2c-designware-platdrv.c | 8 ++- 11 files changed, 288 insertions(+), 57 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support
On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote: > On 17-02-28 12:18:39, Jason Ekstrand wrote: > >I've said it before but reading through Ben's patches again make me want to > >be peskier about it. I would really like the UABI to treat the CCS as if > >it's Y-tiled with a tile size of 128B x 32 rows. Why? Because this is > >what all the docs say it is. From the display docs for "Color Control > >Surface": > > > >"The Color Control Surface (CCS) contains the compression status of the > >cache-line pairs. The > >compression state of the cache-line pair is specified by 2 bits in the CCS. > >Each CCS cache-line represents > >an area on the main surface of 16 x16 sets of 128 byte Y-tiled > >cache-line-pairs. CCS is always Y tiled." > > > >This contains 95% of the information needed to know the relation between > >the CCS and the main surface. The other 5% (which is badly documented) is > >that cache line pairs are horizontally adjacent. This gives a relationship > >of one cache line in the CCS maps to 32x64 cache lines in the main surface. > > > >But it's not actually Y-tiled? Of course not. I've worked out the exact > >tiling and it looks something like Y but isn't quite the same. However, > >this isn't unique to CCS. Stencil (W-tiled), HiZ, and gen7-8 > >single-sampled MCS also each have their own tiling (Haswell MCS is > >especially exotic) but the docs call all of them Y-tiled and I think the > >hardware internally treats them as Y-tiled with the cache lines shuffled > >around a bit. > > > >Given the fact that they seem to like to change the MCS/CCS tiling around > >on every hardware generation, I'm reluctant to base UABI on the fact that > >the CCS appears to have 64x64 "pixels" per tile with each "pixel" > >corresponding to 16x8 pixels in the color surface. That's not what we had > >on any previous gen and may change on gen10 for no aparent reason. I'd > >much rather base it on Y-tiling and a relationship between cache lines > >which, even if they change the exact swizzle on gen10, will probably remain > >the same. (For the gen7-8 analogue of CCS, they changed the tiling every > >generation but the relationship of one MCS cache line maps to 32x128 color > >cache lines remained the same). > > > >Ok, I've said my peice. If we have to divide by 2 in userspace, we won't > >die, but I'd like to get the UABI right before we chissel it in stone. > > > >--Jason > > > > > > I vote we make the stride in units of tiles when we have the CCS modifier. That won't fly with the KMS API. I suppose I could make the tile 128 bytes wide by swapping the "1 byte == 16x8 pixels" notion with a "1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore, but I guess no one really cares. > > >> + /* fall through */ > >> case I915_FORMAT_MOD_Yf_TILED: > >> /* > >> * Bspec seems to suggest that the Yf tile width would > >> @@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const > >> struct drm_framebuffer *fb, > >> struct drm_i915_private *dev_priv = to_i915(fb->dev); > >> > >> /* AUX_DIST needs only 4K alignment */ > >> - if (fb->format->format == DRM_FORMAT_NV12 && plane == 1) > >> + if (plane == 1) > >> return 4096; > >> > >> switch (fb->modifier) { > >> @@ -2166,6 +2174,8 @@ static unsigned int intel_surf_alignment(const > >> struct drm_framebuffer *fb, > >> if (INTEL_GEN(dev_priv) >= 9) > >> return 256 * 1024; > >> return 0; > >> + case I915_FORMAT_MOD_Y_TILED_CCS: > >> + case I915_FORMAT_MOD_Yf_TILED_CCS: > >> case I915_FORMAT_MOD_Y_TILED: > >> case I915_FORMAT_MOD_Yf_TILED: > >> return 1 * 1024 * 1024; > >> @@ -2472,6 +2482,7 @@ static unsigned int > >> intel_fb_modifier_to_tiling(uint64_t > >> fb_modifier) > >> case I915_FORMAT_MOD_X_TILED: > >> return I915_TILING_X; > >> case I915_FORMAT_MOD_Y_TILED: > >> + case I915_FORMAT_MOD_Y_TILED_CCS: > >> return I915_TILING_Y; > >> default: > >> return I915_TILING_NONE; > >> @@ -2536,6 +2547,35 @@ intel_fill_fb_info(struct drm_i915_private > >> *dev_priv, > >> > >> intel_fb_offset_to_xy(&x, &y, fb, i); > >> > >> + if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS || > >> +fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) && i == > >> 1) { > >> + int main_x, main_y; > >> + int ccs_x, ccs_y; > >> + > >> + /* > >> +* Each byte of CCS corresponds to a 16x8 area of > >> the main surface, and > >> +* each CCS tile is 64x64 bytes. > >> +*/ > >> + ccs_x = (x * 16) % (64 * 16); > >> + ccs_y = (y * 8) % (64 * 8); > >> +
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Use drm_connector_list_iter in debugfs
== Series Details == Series: series starting with [1/6] drm/i915: Use drm_connector_list_iter in debugfs URL : https://patchwork.freedesktop.org/series/20441/ State : failure == Summary == Series 20441v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20441/revisions/1/mbox/ Test gem_ctx_create: Subgroup basic-files: pass -> INCOMPLETE (fi-bdw-5557u) Test kms_busy: Subgroup basic-flip-default-a: fail -> PASS (fi-byt-n2820) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: pass -> DMESG-WARN (fi-byt-n2820) fi-bdw-5557u total:17 pass:16 dwarn:0 dfail:0 fail:0 skip:0 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:246 dwarn:1 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 5e40124690ed25976cb436f1a3f83ba657b8fafb drm-tip: 2017y-03m-01d-09h-46m-54s UTC integration manifest eb43dd1 drm/i915: Fix up verify_encoder_state ea8bbb3 drm/i915: use for_each_intel_connector_iter in intel_display.c 87b27ca drm/i915: Make intel_get_pipe_from_connector atomic d5d4e9b drm/i915: use drm_connector_list_iter in intel_opregion.c ae16a12 drm/i915: use drm_connector_list_iter in intel_hotplug.c 47814de drm/i915: Use drm_connector_list_iter in debugfs == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4013/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH] intel-ci: Add initial generic testlist
Similar to fast-feedback test list. The point of the generic test list is to gather pass-rate when running generic tests - i.e., tests that don't rely on specific GPUs. Again, this test list is dynamic and will either shrink or grow over time. Signed-off-by: Abdiel Janulgue Cc: Petri Latvala Cc: Tomi Sarvela --- tests/intel-ci/README | 6 ++ tests/intel-ci/generic.testlist | 125 2 files changed, 131 insertions(+) create mode 100644 tests/intel-ci/generic.testlist diff --git a/tests/intel-ci/README b/tests/intel-ci/README index dc7e5c8..314b343 100644 --- a/tests/intel-ci/README +++ b/tests/intel-ci/README @@ -32,3 +32,9 @@ test per feature. The string "basic" in a test name means the test probably belongs in this list. + +== +generic.testlist +== + +Generic is the testlist for GPU-agnostic tests. \ No newline at end of file diff --git a/tests/intel-ci/generic.testlist b/tests/intel-ci/generic.testlist new file mode 100644 index 000..433acdf --- /dev/null +++ b/tests/intel-ci/generic.testlist @@ -0,0 +1,125 @@ +igt@core_auth@many-magics +igt@core_auth@basic-auth +igt@core_getclient +igt@core_get_client_auth@master-drop +igt@core_get_client_auth@simple +igt@core_getstats +igt@core_getversion +igt@core_prop_blob@invalid-get-prop +igt@core_prop_blob@blob-prop-lifetime +igt@core_prop_blob@invalid-set-prop-any +igt@core_prop_blob@invalid-set-prop +igt@core_prop_blob@blob-prop-validate +igt@core_prop_blob@blob-multiple +igt@core_prop_blob@blob-prop-core +igt@core_prop_blob@basic +igt@core_prop_blob@invalid-get-prop-any +igt@core_setmaster_vs_auth +igt@drm_read@empty-nonblock +igt@drm_read@short-buffer-block +igt@drm_read@empty-block +igt@drm_read@invalid-buffer +igt@drm_read@short-buffer-nonblock +igt@drm_read@fault-buffer +igt@kms_addfb_basic@no-handle +igt@kms_addfb_basic@bad-pitch-32 +igt@kms_addfb_basic@bad-pitch-999 +igt@kms_addfb_basic@invalid-set-prop-any +igt@kms_addfb_basic@bad-pitch-0 +igt@kms_addfb_basic@bad-pitch-1024 +igt@kms_addfb_basic@bad-pitch-256 +igt@kms_addfb_basic@too-wide +igt@kms_addfb_basic@small-bo +igt@kms_addfb_basic@invalid-get-prop +igt@kms_addfb_basic@basic +igt@kms_addfb_basic@size-max +igt@kms_addfb_basic@bad-pitch-128 +igt@kms_addfb_basic@invalid-get-prop-any +igt@kms_addfb_basic@invalid-set-prop +igt@kms_addfb_basic@bad-pitch-63 +igt@kms_render@direct-render +igt@kms_setmode@invalid-clone-single-crtc-stealing +igt@testdisplay +igt@vgem_basic@mmap +igt@vgem_basic@dmabuf-mmap +igt@vgem_basic@dmabuf-fence-before +igt@vgem_basic@dmabuf-export +igt@vgem_basic@debugfs +igt@vgem_basic@dmabuf-fence +igt@vgem_basic@second-client +igt@vgem_basic@sysfs +igt@vgem_basic@unload +igt@vgem_basic@create +igt@kms_flip@wf_vblank-interruptible +igt@kms_flip@flip-vs-dpms-off-vs-modeset +igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset-interruptible +igt@kms_flip@2x-wf_vblank-ts-check +igt@kms_flip@absolute-wf_vblank +igt@kms_flip@nonexisting-fb-interruptible +igt@kms_flip@2x-flip-vs-rmfb-interruptible +igt@kms_flip@2x-plain-flip-ts-check +igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible +igt@kms_flip@modeset-vs-vblank-race +igt@kms_flip@2x-plain-flip-interruptible +igt@kms_flip@2x-vblank-vs-dpms-suspend +igt@kms_flip@nonexisting-fb +igt@kms_flip@dpms-vs-vblank-race-interruptible +igt@kms_flip@2x-flip-vs-blocking-wf-vblank +igt@kms_flip@2x-modeset-vs-vblank-race-interruptible +igt@kms_flip@2x-plain-flip +igt@kms_flip@wf_vblank-ts-check +igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset +igt@kms_flip@2x-flip-vs-modeset +igt@kms_flip@2x-absolute-wf_vblank-interruptible +igt@kms_flip@absolute-wf_vblank-interruptible +igt@kms_flip@blocking-absolute-wf_vblank +igt@kms_flip@dpms-off-confusion-interruptible +igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-modeset +igt@kms_flip@flip-vs-expired-vblank-interruptible +igt@kms_flip@2x-wf_vblank +igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible +igt@kms_flip@vblank-vs-dpms-suspend-interruptible +igt@kms_flip@flip-vs-modeset-interruptible +igt@kms_flip@dpms-vs-vblank-race +igt@kms_flip@2x-wf_vblank-interruptible +igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-modeset-interruptible +igt@kms_flip@basic-flip-vs-wf_vblank +igt@kms_flip@basic-flip-vs-modeset +igt@kms_flip@blocking-absolute-wf_vblank-interruptible +igt@kms_flip@2x-flip-vs-modeset-interruptible +igt@kms_flip@2x-flip-vs-panning-interruptible +igt@kms_flip@flip-vs-blocking-wf-vblank +igt@kms_flip@2x-dpms-vs-vblank-race-interruptible +igt@kms_flip@flip-vs-panning-interruptible +igt@kms_flip@vblank-vs-dpms-suspend +igt@kms_flip@2x-flip-vs-expired-vblank-interruptible +igt@kms_flip@2x-dpms-vs-vblank-race +igt@kms_flip@2x-flip-vs-rmfb +igt@kms_flip@2x-nonexisting-fb +igt@kms_flip@blocking-wf_vblank +igt@kms_flip@dpms-off-confusion +igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset +igt@kms_flip@flip-vs-panning +igt@kms_flip@modeset-vs-vblank-race-interruptible +igt@kms_flip@2x-
Re: [Intel-gfx] [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable sequence
On Wed, 01 Mar 2017, Madhav Chauhan wrote: > From: Deepak M > > v2: Addressed Jani's Review comments(renamed bit field macros) > v3: Jani's Review comment for aligning code to platforms and added > wrapper functions. > v4: Corrected enable/disable seuqence as per BSPEC > v5: Corrected waiting twice for same bit (Review comments: Jani) > v6: Rebased to Han's patches(dsi restructuring code) > > Signed-off-by: Deepak M > Signed-off-by: Madhav Chauhan Pushed to drm-intel-next-queued, thanks for the patch. BR, Jani. > --- > drivers/gpu/drm/i915/intel_dsi.c | 206 > --- > 1 file changed, 195 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > b/drivers/gpu/drm/i915/intel_dsi.c > index 20ed799..8e97bae3 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.c > +++ b/drivers/gpu/drm/i915/intel_dsi.c > @@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct > intel_encoder *encoder, > return true; > } > > +static void glk_dsi_device_ready(struct intel_encoder *encoder) > +{ > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base); > + enum port port; > + u32 tmp, val; > + > + /* Set the MIPI mode > + * If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting. > + * Power ON MIPI IO first and then write into IO reset and LP wake bits > + */ > + for_each_dsi_port(port, intel_dsi->ports) { > + tmp = I915_READ(MIPI_CTRL(port)); > + I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE); > + } > + > + /* Put the IO into reset */ > + tmp = I915_READ(MIPI_CTRL(PORT_A)); > + tmp &= ~GLK_MIPIIO_RESET_RELEASED; > + I915_WRITE(MIPI_CTRL(PORT_A), tmp); > + > + /* Program LP Wake */ > + for_each_dsi_port(port, intel_dsi->ports) { > + tmp = I915_READ(MIPI_CTRL(port)); > + tmp |= GLK_LP_WAKE; > + I915_WRITE(MIPI_CTRL(port), tmp); > + } > + > + /* Wait for Pwr ACK */ > + for_each_dsi_port(port, intel_dsi->ports) { > + if (intel_wait_for_register(dev_priv, > + MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED, > + GLK_MIPIIO_PORT_POWERED, 20)) > + DRM_ERROR("MIPIO port is powergated\n"); > + } > + > + /* Wait for MIPI PHY status bit to set */ > + for_each_dsi_port(port, intel_dsi->ports) { > + if (intel_wait_for_register(dev_priv, > + MIPI_CTRL(port), GLK_PHY_STATUS_PORT_READY, > + GLK_PHY_STATUS_PORT_READY, 20)) > + DRM_ERROR("PHY is not ON\n"); > + } > + > + /* Get IO out of reset */ > + tmp = I915_READ(MIPI_CTRL(PORT_A)); > + I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED); > + > + /* Get IO out of Low power state*/ > + for_each_dsi_port(port, intel_dsi->ports) { > + if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY)) { > + val = I915_READ(MIPI_DEVICE_READY(port)); > + val &= ~ULPS_STATE_MASK; > + val |= DEVICE_READY; > + I915_WRITE(MIPI_DEVICE_READY(port), val); > + usleep_range(10, 15); > + } > + > + /* Enter ULPS */ > + val = I915_READ(MIPI_DEVICE_READY(port)); > + val &= ~ULPS_STATE_MASK; > + val |= (ULPS_STATE_ENTER | DEVICE_READY); > + I915_WRITE(MIPI_DEVICE_READY(port), val); > + > + /* Wait for ULPS Not active */ > + if (intel_wait_for_register(dev_priv, > + MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, > + GLK_ULPS_NOT_ACTIVE, 20)) > + > + /* Exit ULPS */ > + val = I915_READ(MIPI_DEVICE_READY(port)); > + val &= ~ULPS_STATE_MASK; > + val |= (ULPS_STATE_EXIT | DEVICE_READY); > + I915_WRITE(MIPI_DEVICE_READY(port), val); > + > + /* Enter Normal Mode */ > + val = I915_READ(MIPI_DEVICE_READY(port)); > + val &= ~ULPS_STATE_MASK; > + val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY); > + I915_WRITE(MIPI_DEVICE_READY(port), val); > + > + tmp = I915_READ(MIPI_CTRL(port)); > + tmp &= ~GLK_LP_WAKE; > + I915_WRITE(MIPI_CTRL(port), tmp); > + } > + > + /* Wait for Stop state */ > + for_each_dsi_port(port, intel_dsi->ports) { > + if (intel_wait_for_register(dev_priv, > + MIPI_CTRL(port), GLK_DATA_LANE_STOP_STATE, > + GLK_DATA_LANE_STOP_STATE, 20)) > + DRM_ERROR("Date lane not in STOP state\n"); > + } > + > + /* Wait for AFE LATCH */ > + for_each_dsi_port(port, intel_dsi->ports) { > +
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2)
On Fri, Feb 24, 2017 at 03:52:15PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2) > URL : https://patchwork.freedesktop.org/series/19961/ > State : success > > == Summary == > > Series 19961v2 drm/i915/gen9: Increase PCODE request timeout to 100ms > https://patchwork.freedesktop.org/api/1.0/series/19961/revisions/2/mbox/ > > fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 > fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 > fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 > fi-bxt-t5700 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 > fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 > fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 > fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 > fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 > fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 > fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 > fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 > > 69fbd8896f5f272550747b763068883326962d76 drm-tip: 2017y-02m-24d-14h-04m-04s > UTC integration manifest > 11e17c3 drm/i915/gen9: Increase PCODE request timeout to 50ms I pushed this to -dinq with Chris' ack, thanks for the reviews. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [igt PATCH] configure.ac: require libdrm >= 2.4.75 for I915_EXEC_FENCE_OUT
I915_EXEC_FENCE_OUT was added in libdrm commit a3d715ee14b2 ("Import uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9") and released in libdrm-2.4.75. Signed-off-by: Jani Nikula --- I'm probably doing something wrong. This passes configure for me, but build still fails with: gem_latency.c: In function ‘setup_latency’: gem_latency.c:290:16: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in this function) eb->flags |= I915_EXEC_FENCE_OUT; ^ gem_latency.c:290:16: note: each undeclared identifier is reported only once for each function it appears in gem_latency.c: In function ‘measure_latency’: gem_latency.c:328:44: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in this function) if (!(p->latency_dispatch.execbuf.flags & I915_EXEC_FENCE_OUT)) ^ gem_latency.c: In function ‘producer’: gem_latency.c:364:43: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in this function) if (p->latency_dispatch.execbuf.flags & I915_EXEC_FENCE_OUT) ^ Makefile:767: recipe for target 'gem_latency-gem_latency.o' failed --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 562d5525e894..407fddf5fe2b 100644 --- a/configure.ac +++ b/configure.ac @@ -187,10 +187,10 @@ AC_ARG_ENABLE(intel, AS_HELP_STRING([--disable-intel], [Enable building of intel specific parts (default: auto)]), [INTEL=$enableval], [INTEL=auto]) if test "x$INTEL" = xauto; then - PKG_CHECK_EXISTS([libdrm_intel >= 2.4.74], [INTEL=yes], [INTEL=no]) + PKG_CHECK_EXISTS([libdrm_intel >= 2.4.75], [INTEL=yes], [INTEL=no]) fi if test "x$INTEL" = xyes; then - PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.74]) + PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.75]) AC_DEFINE(HAVE_LIBDRM_INTEL, 1, [Have intel support]) else DRM_INTEL_CFLAGS=-I$\(top_srcdir\)/lib/stubs/drm/ -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt PATCH] configure.ac: require libdrm >= 2.4.75 for I915_EXEC_FENCE_OUT
On 03/01/2017 01:34 PM, Jani Nikula wrote: I915_EXEC_FENCE_OUT was added in libdrm commit a3d715ee14b2 ("Import uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9") and released in libdrm-2.4.75. Signed-off-by: Jani Nikula Reviewed-by: Petri Latvala --- I'm probably doing something wrong. This passes configure for me, but build still fails with: gem_latency.c: In function ‘setup_latency’: gem_latency.c:290:16: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in this function) eb->flags |= I915_EXEC_FENCE_OUT; ^ gem_latency.c:290:16: note: each undeclared identifier is reported only once for each function it appears in gem_latency.c: In function ‘measure_latency’: gem_latency.c:328:44: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in this function) if (!(p->latency_dispatch.execbuf.flags & I915_EXEC_FENCE_OUT)) ^ gem_latency.c: In function ‘producer’: gem_latency.c:364:43: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in this function) if (p->latency_dispatch.execbuf.flags & I915_EXEC_FENCE_OUT) Possibly an old libdrm somewhere in your filesystem, configure finding the new one's .pc file but gcc finding the old one's headers first... -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Move w/a LRI debug message from context-init to driver load
The spam of every context initialisation saying the same thing is annoying me! Move the information to the setup of the engine. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 38 +- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index c4d4698f98e7..c58339b22f6a 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1009,30 +1009,32 @@ static int glk_init_workarounds(struct intel_engine_cs *engine) int init_workarounds_ring(struct intel_engine_cs *engine) { struct drm_i915_private *dev_priv = engine->i915; + int err; WARN_ON(engine->id != RCS); dev_priv->workarounds.count = 0; - dev_priv->workarounds.hw_whitelist_count[RCS] = 0; + dev_priv->workarounds.hw_whitelist_count[engine->id] = 0; if (IS_BROADWELL(dev_priv)) - return bdw_init_workarounds(engine); - - if (IS_CHERRYVIEW(dev_priv)) - return chv_init_workarounds(engine); - - if (IS_SKYLAKE(dev_priv)) - return skl_init_workarounds(engine); - - if (IS_BROXTON(dev_priv)) - return bxt_init_workarounds(engine); - - if (IS_KABYLAKE(dev_priv)) - return kbl_init_workarounds(engine); - - if (IS_GEMINILAKE(dev_priv)) - return glk_init_workarounds(engine); + err = bdw_init_workarounds(engine); + else if (IS_CHERRYVIEW(dev_priv)) + err = chv_init_workarounds(engine); + else if (IS_SKYLAKE(dev_priv)) + err = skl_init_workarounds(engine); + else if (IS_BROXTON(dev_priv)) + err = bxt_init_workarounds(engine); + else if (IS_KABYLAKE(dev_priv)) + err = kbl_init_workarounds(engine); + else if (IS_GEMINILAKE(dev_priv)) + err = glk_init_workarounds(engine); + else + err = 0; + if (err) + return err; + DRM_DEBUG_DRIVER("%s: Number of context specific w/a: %d\n", +engine->name, dev_priv->workarounds.count); return 0; } @@ -1066,8 +1068,6 @@ int intel_ring_workarounds_emit(struct drm_i915_gem_request *req) if (ret) return ret; - DRM_DEBUG_DRIVER("Number of Workarounds emitted: %d\n", w->count); - return 0; } -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/guc: Extract param logic form guc_init_fw()
On ma, 2017-02-27 at 13:50 +0100, Arkadiusz Hiler wrote: > Let intel_guc_init_fw() focus on determining and fetching the correct > firmware. > > This patch introduces intel_uc_sanitize_options() that is called from > intel_sanitize_options(). > > Then, if we have GuC, we can call intel_guc_init_fw() conditionally > and we do not have to do the internal checks. > > v2: fix comment, notify when nuking GuC explicitly enabled (M. Wajdeczko) > v3: fix comment again, change the nuke message (M. Wajdeczko) > v4: update title to reflect new function name + rebase > v5: text && remove 2 uneccessary checks (M. Wajeczko) > > Cc: Michal Winiarski > Cc: Michal Wajdeczko > Cc: Daniele Ceraolo Spurio > Cc: Joonas Lahtinen > Signed-off-by: Arkadiusz Hiler Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4 v2] drm/i915/guc: Add onion teardown to the GuC setup
On pe, 2017-02-24 at 06:01 -0800, Oscar Mateo wrote: > Starting with intel_guc_loader, down to intel_guc_submission > and finally to intel_guc_log. > > v2: > - Null execbuf client outside guc_client_free (Daniele) > - Assert if things try to get allocated twice (Daniele/Joonas) > - Null guc->log.buf_addr when destroyed (Daniele) > - Newline between returning success and error labels (Joonas) > - Remove some unnecessary comments (Joonas) > - Keep guc_log_create_extras naming convention (Joonas) > - Helper function guc_log_has_extras (Joonas) > - No need for separate relay_channel create/destroy. It's just another > extra. > - No need to nullify guc->log.flush_wq when destroyed (Joonas) > - Hoist the check for has_extras out of guc_log_create_extras (Joonas) > - Try to do i915_guc_log_register/unregister calls (kind of) symmetric > (Daniele) > - Make sure initel_guc_fini is not called before init is ever called > (Daniele) > > Cc: Daniele Ceraolo Spurio > Cc: Joonas Lahtinen > Signed-off-by: Oscar Mateo > @@ -404,120 +348,105 @@ static void capture_logs_work(struct work_struct > *work) > guc_log_capture_logs(guc); > } > > +static bool guc_log_has_extras(struct intel_guc *guc) > +{ > + return (guc->log.buf_addr != NULL); > +} brackets not needed. Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/guc: Break out the GuC log "extras"
On pe, 2017-02-24 at 06:01 -0800, Oscar Mateo wrote: > When initializing the GuC log struct, there is an object we need to > allocate always, since the GuC needs its address at fw load time. > The rest are "extras", in the sense that we only need them if we > actually enable GuC logging. Make that distinction explicit by > subdividing further the intel_guc_log struct. > > Cc: Daniele Ceraolo Spurio > Cc: Joonas Lahtinen > Signed-off-by: Oscar Mateo I'm not sure about calling them extras. How about runtime? Also, I'm not quite sure if the abstractions are currently correct (despite the names), logging seems to control overall guc interrups, for example (i915_guc_log_unregister func). Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 10/11] drm/i915/preempt: Emit MI_ARB_CHECK before the start of user batch
On Thu, Feb 23, 2017 at 08:14:20PM +0100, Michał Winiarski wrote: > We should probably do this conditionally, based on whether preemption is > actually enabled. > > Signed-off-by: Michał Winiarski > --- > drivers/gpu/drm/i915/intel_lrc.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 869b96e..972f9bd 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -1418,10 +1418,13 @@ static int gen8_emit_bb_start(struct > drm_i915_gem_request *req, > req->ctx->ppgtt->pd_dirty_rings &= > ~intel_engine_flag(req->engine); > } > > - cs = intel_ring_begin(req, 4); > + cs = intel_ring_begin(req, 6); > if (IS_ERR(cs)) > return PTR_ERR(cs); > > + *cs++ = MI_ARB_CHECK; > + *cs++ = MI_NOOP; > + > /* FIXME(BDW): Address space and security selectors. */ > *cs++ = MI_BATCH_BUFFER_START_GEN8 | (ppgtt << 8) | (dispatch_flags & > I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER : 0); Shouldn't we only enable arbitration across the batch, i.e. add the disable here? The flush and breadcrumb are not worth interrupting and saves us some work if they are not. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 05/11] drm/i915/preempt: Handle preemption event in guc tasklet
On Thu, Feb 23, 2017 at 08:14:15PM +0100, Michał Winiarski wrote: > +static void unsubmit_inflight_requests(struct intel_engine_cs *engine, > + struct list_head *resubmit) > +{ > + struct drm_i915_gem_request *rq, *prev; > + > + assert_spin_locked(&engine->timeline->lock); > + > + list_for_each_entry_safe_reverse(rq, prev, > + &engine->timeline->requests, link) { > + if (!i915_gem_request_completed(rq)) { > + i915_gem_request_get(rq); > + __i915_gem_request_unsubmit(rq); > + list_add(&rq->resubmit_link, resubmit); I was thinking it would be going back to the execlist queue, where it would be priority sorted against later requests. Pro/cons? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Add more OA configs for BDW, CHV, SKL + BXT
On 02/22, Robert Bragg wrote: > These are auto generated from an XML description of metric sets, > currently maintained in gputop, ref: > > https://github.com/rib/gputop > > gputop-data/oa-*.xml > > scripts/i915-perf-kernelgen.py > > $ make -C gputop-data -f Makefile.xml > > Signed-off-by: Robert Bragg > --- > + > +static const struct i915_oa_reg * > +get_compute_extended_mux_config(struct drm_i915_private *dev_priv, > + int *len) > +{ > + if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x01) { > + *len = > ARRAY_SIZE(mux_config_compute_extended_1_0_subslices_0x01); > + return mux_config_compute_extended_1_0_subslices_0x01; > + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x08) { > + *len = > ARRAY_SIZE(mux_config_compute_extended_1_1_subslices_0x08); > + return mux_config_compute_extended_1_1_subslices_0x08; > + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x02) { > + *len = > ARRAY_SIZE(mux_config_compute_extended_1_2_subslices_0x02); > + return mux_config_compute_extended_1_2_subslices_0x02; > + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x10) { > + *len = > ARRAY_SIZE(mux_config_compute_extended_1_3_subslices_0x10); > + return mux_config_compute_extended_1_3_subslices_0x10; > + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x04) { > + *len = > ARRAY_SIZE(mux_config_compute_extended_1_4_subslices_0x04); > + return mux_config_compute_extended_1_4_subslices_0x04; > + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x20) { > + *len = > ARRAY_SIZE(mux_config_compute_extended_1_5_subslices_0x20); > + return mux_config_compute_extended_1_5_subslices_0x20; > + *len = ARRAY_SIZE(mux_config_compute_extended); > + return mux_config_compute_extended; It looks like your script doesn't properly handle the unconditional mux config here. > + > +static const struct i915_oa_reg * > +get_test_oa_mux_config(struct drm_i915_private *dev_priv, > +int *len) > +{ > + *len = ARRAY_SIZE(mux_config_test_oa); > + return mux_config_test_oa; > +} > + > +int i915_oa_select_metric_set_bdw(struct drm_i915_private *dev_priv) > +{ > + dev_priv->perf.oa.mux_regs = NULL; > + dev_priv->perf.oa.mux_regs_len = 0; > + dev_priv->perf.oa.b_counter_regs = NULL; > + dev_priv->perf.oa.b_counter_regs_len = 0; > + dev_priv->perf.oa.flex_regs = NULL; > + dev_priv->perf.oa.flex_regs_len = 0; > + > + switch (dev_priv->perf.oa.metrics_set) { > + case METRIC_SET_ID_RENDER_BASIC: > + dev_priv->perf.oa.mux_regs = > + get_render_basic_mux_config(dev_priv, > + > &dev_priv->perf.oa.mux_regs_len); > + if (!dev_priv->perf.oa.mux_regs) { > + DRM_DEBUG_DRIVER("No suitable MUX config for > \"RENDER_BASIC\" metric set"); Your script also needs to output a newline for DRM_DEBUG_DRIVER. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path
On Tue, Feb 28, 2017 at 04:22:32PM +, Chris Wilson wrote: > No more direct return -EINVAL as we have to unwind the > obj->framebuffer_references. > > Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating > the framebuffer") > Signed-off-by: Chris Wilson > Cc: Ville Syrjälä lgtm Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 10e68dfb7260..77936ddd860a 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14383,7 +14383,7 @@ static int intel_framebuffer_init(struct > intel_framebuffer *intel_fb, > if (INTEL_INFO(dev_priv)->gen < 4 && > tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) { > DRM_DEBUG("tiling_mode must match fb modifier exactly on > gen2/3\n"); > - return -EINVAL; > + goto err; > } > > stride_alignment = intel_fb_stride_alignment(dev_priv, > @@ -14428,7 +14428,7 @@ static int intel_framebuffer_init(struct > intel_framebuffer *intel_fb, > if (INTEL_GEN(dev_priv) > 3) { > DRM_DEBUG("unsupported pixel format: %s\n", > drm_get_format_name(mode_cmd->pixel_format, > &format_name)); > - return -EINVAL; > + goto err; > } > break; > case DRM_FORMAT_ABGR: > @@ -14436,7 +14436,7 @@ static int intel_framebuffer_init(struct > intel_framebuffer *intel_fb, > INTEL_GEN(dev_priv) < 9) { > DRM_DEBUG("unsupported pixel format: %s\n", > drm_get_format_name(mode_cmd->pixel_format, > &format_name)); > - return -EINVAL; > + goto err; > } > break; > case DRM_FORMAT_XBGR: > @@ -14445,14 +14445,14 @@ static int intel_framebuffer_init(struct > intel_framebuffer *intel_fb, > if (INTEL_GEN(dev_priv) < 4) { > DRM_DEBUG("unsupported pixel format: %s\n", > drm_get_format_name(mode_cmd->pixel_format, > &format_name)); > - return -EINVAL; > + goto err; > } > break; > case DRM_FORMAT_ABGR2101010: > if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) { > DRM_DEBUG("unsupported pixel format: %s\n", > drm_get_format_name(mode_cmd->pixel_format, > &format_name)); > - return -EINVAL; > + goto err; > } > break; > case DRM_FORMAT_YUYV: > @@ -14462,13 +14462,13 @@ static int intel_framebuffer_init(struct > intel_framebuffer *intel_fb, > if (INTEL_GEN(dev_priv) < 5) { > DRM_DEBUG("unsupported pixel format: %s\n", > drm_get_format_name(mode_cmd->pixel_format, > &format_name)); > - return -EINVAL; > + goto err; > } > break; > default: > DRM_DEBUG("unsupported pixel format: %s\n", > drm_get_format_name(mode_cmd->pixel_format, > &format_name)); > - return -EINVAL; > + goto err; > } > > /* FIXME need to adjust LINOFF/TILEOFF accordingly. */ > @@ -14481,7 +14481,7 @@ static int intel_framebuffer_init(struct > intel_framebuffer *intel_fb, > > ret = intel_fill_fb_info(dev_priv, &intel_fb->base); > if (ret) > - return ret; > + goto err; > > ret = drm_framebuffer_init(obj->base.dev, > &intel_fb->base, > -- > 2.11.0 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Prevent concurrent tiling/framebuffer modifications
On Tue, Feb 28, 2017 at 04:22:33PM +, Chris Wilson wrote: > Reintroduce a lock around tiling vs framebuffer creation to prevent > modification of the obj->tiling_and_stride whilst the framebuffer is > being created. Rather than use struct_mutex once again, use the > per-object lock - this will also be required in future to prevent > changing the tiling whilst submitting rendering. > > Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating > the framebuffer") > Signed-off-by: Chris Wilson > Cc: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_gem_object.h | 18 +- > drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +- > drivers/gpu/drm/i915/i915_gem_tiling.c | 9 - > drivers/gpu/drm/i915/intel_display.c | 25 - > 4 files changed, 42 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h > b/drivers/gpu/drm/i915/i915_gem_object.h > index ad1bc0b1a0c2..8c02c8ec2a3b 100644 > --- a/drivers/gpu/drm/i915/i915_gem_object.h > +++ b/drivers/gpu/drm/i915/i915_gem_object.h > @@ -169,7 +169,7 @@ struct drm_i915_gem_object { > struct reservation_object *resv; > > /** References from framebuffers, locks out tiling changes. */ > - atomic_t framebuffer_references; > + unsigned int framebuffer_references; > > /** Record of address bit 17 of each page at last unbind. */ > unsigned long *bit_17; > @@ -263,6 +263,16 @@ extern void drm_gem_object_unreference(struct > drm_gem_object *); > __deprecated > extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *); > > +static inline void i915_gem_object_lock(struct drm_i915_gem_object *obj) > +{ > + reservation_object_lock(obj->resv, NULL); > +} > + > +static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj) > +{ > + reservation_object_unlock(obj->resv); > +} > + > static inline bool > i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj) > { > @@ -303,6 +313,12 @@ i915_gem_object_clear_active_reference(struct > drm_i915_gem_object *obj) > > void __i915_gem_object_release_unless_active(struct drm_i915_gem_object > *obj); > > +static inline bool > +i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj) > +{ > + return READ_ONCE(obj->framebuffer_references); > +} > + > static inline unsigned int > i915_gem_object_get_tiling(struct drm_i915_gem_object *obj) > { > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c > b/drivers/gpu/drm/i915/i915_gem_shrinker.c > index 7e3bb48e043e..630697001b38 100644 > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c > @@ -210,7 +210,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv, > > if (!(flags & I915_SHRINK_ACTIVE) && > (i915_gem_object_is_active(obj) || > - atomic_read(&obj->framebuffer_references))) > + i915_gem_object_is_framebuffer(obj))) > continue; > > if (!can_release_pages(obj)) > diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c > b/drivers/gpu/drm/i915/i915_gem_tiling.c > index c1d669e32f41..ad5e05f6b836 100644 > --- a/drivers/gpu/drm/i915/i915_gem_tiling.c > +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c > @@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object > *obj, > if ((tiling | stride) == obj->tiling_and_stride) > return 0; > > - if (atomic_read(&obj->framebuffer_references)) > + if (i915_gem_object_is_framebuffer(obj)) > return -EBUSY; > > /* We need to rebind the object if its current allocation > @@ -258,6 +258,12 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object > *obj, > if (err) > return err; > > + i915_gem_object_lock(obj); > + if (i915_gem_object_is_framebuffer(obj)) { > + i915_gem_object_unlock(obj); > + return -EBUSY; > + } > + > /* If the memory has unknown (i.e. varying) swizzling, we pin the >* pages to prevent them being swapped out and causing corruption >* due to the change in swizzling. > @@ -294,6 +300,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object > *obj, > } > > obj->tiling_and_stride = tiling | stride; > + i915_gem_object_unlock(obj); > > /* Force the fence to be reacquired for GTT access */ > i915_gem_release_mmap(obj); > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 77936ddd860a..62a1e628e399 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14255,7 +14255,10 @@ static void intel_user_framebuffer_destroy(struct > drm_framebuffer *fb) > > drm_framebuffer_cleanup(fb); > > - WARN_ON(atomic_dec_return(&intel_fb->obj->framebuffer_references)
[Intel-gfx] [PATCH RESEND FOR CI 01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec
From: Hans de Goede Document the DSI panel enable / disable sequences from the spec, for easy comparison between the code and the spec. Signed-off-by: Hans de Goede Acked-by: Jani Nikula Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 37 + 1 file changed, 37 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 8e97bae378f1..234592c62141 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -725,6 +725,43 @@ static void intel_dsi_prepare(struct intel_encoder *intel_encoder, struct intel_crtc_state *pipe_config); static void intel_dsi_unprepare(struct intel_encoder *encoder); +/* + * Panel enable/disable sequences from the VBT spec. + * + * Note the spec has AssertReset / DeassertReset swapped from their + * usual naming. We use the normal names to avoid confusion (so below + * they are swapped compared to the spec). + * + * Steps starting with MIPI refer to VBT sequences, note that for v2 + * VBTs several steps which have a VBT in v2 are expected to be handled + * directly by the driver, by directly driving gpios for example. + * + * v2 video mode seq v3 video mode seq command mode seq + * - power on- MIPIPanelPowerOn- power on + * - wait t1+t2- wait t1+t2 + * - MIPIDeassertResetPin- MIPIDeassertResetPin- MIPIDeassertResetPin + * - io lines to lp-11 - io lines to lp-11 - io lines to lp-11 + * - MIPISendInitialDcsCmds - MIPISendInitialDcsCmds - MIPISendInitialDcsCmds + * - MIPITearOn + * - MIPIDisplayOn + * - turn on DPI - turn on DPI - set pipe to dsr mode + * - MIPIDisplayOn - MIPIDisplayOn + * - wait t5 - wait t5 + * - backlight on- MIPIBacklightOn - backlight on + * ... ... ... issue mem cmds ... + * - backlight off - MIPIBacklightOff- backlight off + * - wait t6 - wait t6 + * - MIPIDisplayOff + * - turn off DPI- turn off DPI- disable pipe dsr mode + * - MIPITearOff + * - MIPIDisplayOff - MIPIDisplayOff + * - io lines to lp-00 - io lines to lp-00 - io lines to lp-00 + * - MIPIAssertResetPin - MIPIAssertResetPin - MIPIAssertResetPin + * - wait t3 - wait t3 + * - power off - MIPIPanelPowerOff - power off + * - wait t4 - wait t4 + */ + static void intel_dsi_pre_enable(struct intel_encoder *encoder, struct intel_crtc_state *pipe_config, struct drm_connector_state *conn_state) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915/dsi: the rest of Hans' DSI patches
Resending again to get CI... BR, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 05/10] drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()
From: Hans de Goede Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready state (LP-11), this is the sequence in which things should be done according to the spec. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index da798a579e11..b7b590d78b31 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -808,10 +808,13 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); msleep(intel_dsi->panel_on_delay); - /* put device in ready state */ + /* Deassert reset */ + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); + + /* Put device in ready state (LP-11) */ intel_dsi_device_ready(encoder); - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); + /* Send initialization commands in LP mode */ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); /* Enable port in pre-enable phase itself because as per hw team @@ -915,6 +918,7 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF); + /* Transition to LP-00 */ intel_dsi_clear_device_ready(encoder); if (IS_BROXTON(dev_priv)) { @@ -938,6 +942,7 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, I915_WRITE(DSPCLK_GATE_D, val); } + /* Assert reset */ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); /* Power off, try both CRC pmic gpio and VBT */ -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 06/10] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight
From: Hans de Goede Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as we call intel_panel_enable_backlight() / intel_panel_disable_backlight(). Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index b7b590d78b31..b132841587cc 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -829,12 +829,12 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, msleep(100); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON); - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON); intel_dsi_port_enable(encoder); } intel_panel_enable_backlight(intel_dsi->attached_connector); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON); } static void intel_dsi_enable_nop(struct intel_encoder *encoder, @@ -860,6 +860,7 @@ static void intel_dsi_pre_disable(struct intel_encoder *encoder, DRM_DEBUG_KMS("\n"); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF); intel_panel_disable_backlight(intel_dsi->attached_connector); /* @@ -915,7 +916,6 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, * if disable packets are sent before sending shutdown packet then in * some next enable sequence send turn on packet error is observed */ - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF); /* Transition to LP-00 */ -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 08/10] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable
From: Hans de Goede For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF, v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 5a50645c3a37..7dbef67a5fa0 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -921,6 +921,8 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, * if disable packets are sent before sending shutdown packet then in * some next enable sequence send turn on packet error is observed */ + if (is_cmd_mode(intel_dsi)) + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_OFF); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF); /* Transition to LP-00 */ -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 03/10] drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls
From: Hans de Goede Now that we are no longer bound to the drm_panel_ callbacks, call MIPI_SEQ_POWER_ON/OFF at the proper place. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index f9b0767ef073..ab905474b9dd 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -793,10 +793,10 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, intel_dsi_prepare(encoder, pipe_config); - /* Panel Enable over CRC PMIC */ + /* Power on, try both CRC pmic gpio and VBT */ if (intel_dsi->gpio_panel) gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1); - + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); msleep(intel_dsi->panel_on_delay); if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { @@ -811,7 +811,6 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, /* put device in ready state */ intel_dsi_device_ready(encoder); - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); @@ -940,11 +939,10 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, } intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF); + /* Power off, try both CRC pmic gpio and VBT */ msleep(intel_dsi->panel_off_delay); - - /* Panel Disable over CRC PMIC */ + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF); if (intel_dsi->gpio_panel) gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 02/10] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON
From: Hans de Goede intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET, will always be called at some point before intel_dsi_pre_enable() making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant. In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes against the VBT spec. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 234592c62141..f9b0767ef073 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -811,7 +811,6 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, /* put device in ready state */ intel_dsi_device_ready(encoder); - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 04/10] drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable
From: Hans de Goede Move the DPOunit clock gate workaround to directly after the PLL enable. The exact location of the workaround does not matter and there are 2 reasons to group it with the PLL enable: 1) This moves it out of the middle of the init sequence from the spec, making it easier to follow the init sequence / compare it to the spec 2) It is grouped with the pll disable call in intel_dsi_post_disable, so for consistency it should be grouped with the pll enable in intel_dsi_pre_enable Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index ab905474b9dd..da798a579e11 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -791,14 +791,6 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0); } - intel_dsi_prepare(encoder, pipe_config); - - /* Power on, try both CRC pmic gpio and VBT */ - if (intel_dsi->gpio_panel) - gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1); - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); - msleep(intel_dsi->panel_on_delay); - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { u32 val; @@ -808,6 +800,14 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, I915_WRITE(DSPCLK_GATE_D, val); } + intel_dsi_prepare(encoder, pipe_config); + + /* Power on, try both CRC pmic gpio and VBT */ + if (intel_dsi->gpio_panel) + gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); + msleep(intel_dsi->panel_on_delay); + /* put device in ready state */ intel_dsi_device_ready(encoder); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 09/10] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)
From: Hans de Goede According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON on enable for cmd-mode, just like we already call their counterparts on disable. Note: untested, my panel is a vid-mode panel. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 7dbef67a5fa0..7d5fb9d3fa64 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -822,6 +822,8 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, if (is_cmd_mode(intel_dsi)) { for_each_dsi_port(port, intel_dsi->ports) I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(port), 8 * 4); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_ON); + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON); } else { msleep(20); /* XXX */ for_each_dsi_port(port, intel_dsi->ports) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 07/10] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order
From: Hans de Goede According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN first. Since the v2 order has known issues, we use the v3 order everywhere, add a comment documenting this. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index b132841587cc..5a50645c3a37 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -872,6 +872,11 @@ static void intel_dsi_pre_disable(struct intel_encoder *encoder, I915_WRITE(MIPI_DEVICE_READY(port), 0); } + /* +* According to the spec we should send SHUTDOWN before +* MIPI_SEQ_DISPLAY_OFF only for v3+ VBTs, but field testing +* has shown that the v3 sequence works for v2 VBTs too +*/ if (is_vid_mode(intel_dsi)) { /* Send Shutdown command to the panel in LP mode */ for_each_dsi_port(port, intel_dsi->ports) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI 10/10] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode
From: Hans de Goede For v3 VBTs in vid-mode the delays are part of the VBT sequences, so we should not also delay ourselves otherwise we get double delays. Signed-off-by: Hans de Goede Reviewed-by: Bob Paauwe Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 7d5fb9d3fa64..dd38b6835528 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -725,6 +725,17 @@ static void intel_dsi_prepare(struct intel_encoder *intel_encoder, struct intel_crtc_state *pipe_config); static void intel_dsi_unprepare(struct intel_encoder *encoder); +static void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec) +{ + struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev); + + /* For v3 VBTs in vid-mode the delays are part of the VBT sequences */ + if (is_vid_mode(intel_dsi) && dev_priv->vbt.dsi.seq_version >= 3) + return; + + msleep(msec); +} + /* * Panel enable/disable sequences from the VBT spec. * @@ -806,7 +817,7 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, if (intel_dsi->gpio_panel) gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); - msleep(intel_dsi->panel_on_delay); + intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay); /* Deassert reset */ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); @@ -828,7 +839,7 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, msleep(20); /* XXX */ for_each_dsi_port(port, intel_dsi->ports) dpi_send_cmd(intel_dsi, TURN_ON, false, port); - msleep(100); + intel_dsi_msleep(intel_dsi, 100); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON); @@ -955,7 +966,7 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); /* Power off, try both CRC pmic gpio and VBT */ - msleep(intel_dsi->panel_off_delay); + intel_dsi_msleep(intel_dsi, intel_dsi->panel_off_delay); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF); if (intel_dsi->gpio_panel) gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0); @@ -964,7 +975,7 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, * FIXME As we do with eDP, just make a note of the time here * and perform the wait before the next panel power on. */ - msleep(intel_dsi->panel_pwr_cycle_delay); + intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay); } static bool intel_dsi_get_hw_state(struct intel_encoder *encoder, -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move w/a LRI debug message from context-init to driver load
== Series Details == Series: drm/i915: Move w/a LRI debug message from context-init to driver load URL : https://patchwork.freedesktop.org/series/20452/ State : warning == Summary == Series 20452v1 drm/i915: Move w/a LRI debug message from context-init to driver load https://patchwork.freedesktop.org/api/1.0/series/20452/revisions/1/mbox/ Test gem_exec_fence: Subgroup await-hang-default: incomplete -> PASS (fi-hsw-4770) fdo#99726 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-bxt-t5700) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (fi-bsw-n3050) fdo#99726 https://bugs.freedesktop.org/show_bug.cgi?id=99726 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:278 pass:257 dwarn:1 dfail:0 fail:0 skip:20 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 73ef819d4281caf11663007299032aee4a388ad6 drm-tip: 2017y-03m-01d-11h-16m-44s UTC integration manifest c41c63a drm/i915: Move w/a LRI debug message from context-init to driver load == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4014/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] kbl_guc and bxt_guc firmware missing from linux-firmware
On Wed, 15 Feb 2017, Seth Forshee wrote: > Maybe it would be good to have something like MODULE_OPTIONAL_FIRMWARE > to identify firmware that isn't required but will be used by the driver > if available. Then mkinitramfs can try to copy those files along with > the module but know that there's no need to produce a warning if it's > not present. The documentation for the current MODULE_FIRMWARE already says, "Optional firmware file (or files) needed by the module format is simply firmware file name." BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use BUILD_BUG_ON to ensure platform name has been set up
On Tue, 28 Feb 2017, Chris Wilson wrote: > On Tue, Feb 28, 2017 at 01:11:43PM +0200, Jani Nikula wrote: >> Leave the runtime check in place in case the platform variable itself >> comes from bogus sources. >> >> Signed-off-by: Jani Nikula > > Neat. > Reviewed-by: Chris Wilson Pushed, thanks for the review. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec
== Series Details == Series: series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec URL : https://patchwork.freedesktop.org/series/20456/ State : failure == Summary == Series 20456v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20456/revisions/1/mbox/ Test gem_exec_fence: Subgroup await-hang-default: incomplete -> PASS (fi-hsw-4770) fdo#99726 Test gem_exec_reloc: Subgroup basic-write-gtt-active: pass -> INCOMPLETE (fi-byt-j1900) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (fi-bsw-n3050) fdo#99726 https://bugs.freedesktop.org/show_bug.cgi?id=99726 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 fi-byt-j1900 total:96 pass:86 dwarn:0 dfail:0 fail:0 skip:9 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 73ef819d4281caf11663007299032aee4a388ad6 drm-tip: 2017y-03m-01d-11h-16m-44s UTC integration manifest d7be9a5 drm/i915/dsi: Skip delays for v3 VBTs in vid-mode 64b2987 drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested) 22bb143 drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable e6edb17 drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order 1c58d25f drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight a66cd5f drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready() 7e41705 drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable 26833c8 drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls 17004c5 drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON 579e545 drm/i915/dsi: Document the panel enable / disable sequences from the spec == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4015/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec
On Wed, 01 Mar 2017, Patchwork wrote: > == Series Details == > > Series: series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the > panel enable / disable sequences from the spec > URL : https://patchwork.freedesktop.org/series/20456/ > State : failure > > == Summary == > > Series 20456v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/20456/revisions/1/mbox/ > > Test gem_exec_fence: > Subgroup await-hang-default: > incomplete -> PASS (fi-hsw-4770) fdo#99726 > Test gem_exec_reloc: > Subgroup basic-write-gtt-active: > pass -> INCOMPLETE (fi-byt-j1900) Should not have anything to do with DSI patches. Pushed the lot, thanks for the patches and review. BR, Jani. > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-c: > dmesg-warn -> PASS (fi-bsw-n3050) > > fdo#99726 https://bugs.freedesktop.org/show_bug.cgi?id=99726 > > fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 > fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 > fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 > fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 > fi-byt-j1900 total:96 pass:86 dwarn:0 dfail:0 fail:0 skip:9 > fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 > fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 > fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > fi-kbl-7500u total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 > fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 > fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 > fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 > fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 > > 73ef819d4281caf11663007299032aee4a388ad6 drm-tip: 2017y-03m-01d-11h-16m-44s > UTC integration manifest > d7be9a5 drm/i915/dsi: Skip delays for v3 VBTs in vid-mode > 64b2987 drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode > (untested) > 22bb143 drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable > e6edb17 drm/i915/dsi: Document always using v3 SHUTDOWN / > MIPI_SEQ_DISPLAY_OFF order > 1c58d25f drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with > panel_[en|dis]able_backlight > a66cd5f drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling > device_ready() > 7e41705 drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable > 26833c8 drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic > gpio calls > 17004c5 drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON > 579e545 drm/i915/dsi: Document the panel enable / disable sequences from the > spec > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4015/ -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote: > Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all > 1.1. > > When a sink that supports deep color is connected to the output, the > receiver will send EDIDs that advertise this capability, even if it > isn't possible with HDMI versions earlier than 1.3. > > Currently the kernel is assuming that deep color is possible and the > sink displays an error. > > This quirk will make sure that deep color isn't used with this > particular receiver. > > Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") > References: https://bugs.freedesktop.org/show_bug.cgi?id=99869 > Signed-off-by: Tomeu Vizoso Cc: sta...@vger.kernel.org Cc: Matt Horan Tested-by: Matt Horan Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869 Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_edid.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 24e7b282f16c..d994ccf94f88 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -148,6 +148,9 @@ static const struct edid_quirk { > > /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */ > { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC }, > + > + /* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/ > + { "ETR", 13896, EDID_QUIRK_FORCE_8BPC }, > }; > > /* > -- > 2.9.3 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/8] drm/i915: Pass pipe_config to pch_enable() functions
Using crtc->config directly is being removed in favor of passing a pipe_config. Follow the trend and pass pipe_config to pch_enable() functions. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 45415f0..aea302b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4456,7 +4456,8 @@ intel_trans_dp_port_sel(struct intel_crtc *crtc) * - DP transcoding bits * - transcoder */ -static void ironlake_pch_enable(struct intel_crtc *crtc) +static void ironlake_pch_enable(struct intel_crtc *crtc, + struct intel_crtc_state *pipe_config) { struct drm_device *dev = crtc->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); @@ -4484,7 +4485,7 @@ static void ironlake_pch_enable(struct intel_crtc *crtc) temp = I915_READ(PCH_DPLL_SEL); temp |= TRANS_DPLL_ENABLE(pipe); sel = TRANS_DPLLB_SEL(pipe); - if (crtc->config->shared_dpll == + if (pipe_config->shared_dpll == intel_get_shared_dpll_by_id(dev_priv, DPLL_ID_PCH_PLL_B)) temp |= sel; else @@ -4509,9 +4510,9 @@ static void ironlake_pch_enable(struct intel_crtc *crtc) /* For PCH DP, enable TRANS_DP_CTL */ if (HAS_PCH_CPT(dev_priv) && - intel_crtc_has_dp_encoder(crtc->config)) { + intel_crtc_has_dp_encoder(pipe_config)) { const struct drm_display_mode *adjusted_mode = - &crtc->config->base.adjusted_mode; + &pipe_config->base.adjusted_mode; u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPECONF_BPC_MASK) >> 5; i915_reg_t reg = TRANS_DP_CTL(pipe); temp = I915_READ(reg); @@ -4546,10 +4547,11 @@ static void ironlake_pch_enable(struct intel_crtc *crtc) ironlake_enable_pch_transcoder(dev_priv, pipe); } -static void lpt_pch_enable(struct intel_crtc *crtc) +static void lpt_pch_enable(struct intel_crtc *crtc, + struct intel_crtc_state *pipe_config) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); - enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder; assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A); @@ -5283,7 +5285,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state *pipe_config, intel_enable_pipe(intel_crtc); if (intel_crtc->config->has_pch_encoder) - ironlake_pch_enable(intel_crtc); + ironlake_pch_enable(intel_crtc, pipe_config); assert_vblank_disabled(crtc); drm_crtc_vblank_on(crtc); @@ -5393,7 +5395,7 @@ static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, intel_enable_pipe(intel_crtc); if (intel_crtc->config->has_pch_encoder) - lpt_pch_enable(intel_crtc); + lpt_pch_enable(intel_crtc, pipe_config); if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST)) intel_ddi_set_vc_payload_alloc(crtc, true); -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/8] drm/i915: Pass intel_crtc to intel_lpt_pch_enable()
The function intel_lpt_pch_enable() needs an intel_crtc so pass that instead of the generic crtc type. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c627f7e..45415f0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4250,10 +4250,10 @@ void lpt_disable_iclkip(struct drm_i915_private *dev_priv) } /* Program iCLKIP clock to the desired frequency */ -static void lpt_program_iclkip(struct drm_crtc *crtc) +static void lpt_program_iclkip(struct intel_crtc *crtc) { - struct drm_i915_private *dev_priv = to_i915(crtc->dev); - int clock = to_intel_crtc(crtc)->config->base.adjusted_mode.crtc_clock; + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + int clock = crtc->config->base.adjusted_mode.crtc_clock; u32 divsel, phaseinc, auxdiv, phasedir = 0; u32 temp; @@ -4546,19 +4546,17 @@ static void ironlake_pch_enable(struct intel_crtc *crtc) ironlake_enable_pch_transcoder(dev_priv, pipe); } -static void lpt_pch_enable(struct drm_crtc *crtc) +static void lpt_pch_enable(struct intel_crtc *crtc) { - struct drm_device *dev = crtc->dev; - struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder; + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A); lpt_program_iclkip(crtc); /* Set transcoder timing. */ - ironlake_pch_transcoder_set_timings(intel_crtc, PIPE_A); + ironlake_pch_transcoder_set_timings(crtc, PIPE_A); lpt_enable_pch_transcoder(dev_priv, cpu_transcoder); } @@ -5395,7 +5393,7 @@ static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, intel_enable_pipe(intel_crtc); if (intel_crtc->config->has_pch_encoder) - lpt_pch_enable(crtc); + lpt_pch_enable(intel_crtc); if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST)) intel_ddi_set_vc_payload_alloc(crtc, true); -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/8] drm/i915: Pass intel_crtc to fdi_link_train() hooks
The implementation of the fdi_link_train() hooks need an intel_crtc so just pass that instead of the generic crtc type. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_ddi.c | 13 drivers/gpu/drm/i915/intel_display.c | 63 +--- drivers/gpu/drm/i915/intel_drv.h | 2 +- 4 files changed, 37 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index bc9283b..8b11cdf 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -669,7 +669,7 @@ struct drm_i915_display_funcs { struct intel_encoder *encoder, const struct drm_display_mode *adjusted_mode); void (*audio_codec_disable)(struct intel_encoder *encoder); - void (*fdi_link_train)(struct drm_crtc *crtc); + void (*fdi_link_train)(struct intel_crtc *crtc); void (*init_clock_gating)(struct drm_i915_private *dev_priv); int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc, struct drm_framebuffer *fb, diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a7c08d7..111f660 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -674,15 +674,14 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct intel_shared_dpll *pll) * DDI A (which is used for eDP) */ -void hsw_fdi_link_train(struct drm_crtc *crtc) +void hsw_fdi_link_train(struct intel_crtc *crtc) { - struct drm_device *dev = crtc->dev; + struct drm_device *dev = crtc->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); struct intel_encoder *encoder; u32 temp, i, rx_ctl_val, ddi_pll_sel; - for_each_encoder_on_crtc(dev, crtc, encoder) { + for_each_encoder_on_crtc(dev, &crtc->base, encoder) { WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG); intel_prepare_dp_ddi_buffers(encoder); } @@ -701,7 +700,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) /* Enable the PCH Receiver FDI PLL */ rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE | FDI_RX_PLL_ENABLE | -FDI_DP_PORT_WIDTH(intel_crtc->config->fdi_lanes); +FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes); I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val); POSTING_READ(FDI_RX_CTL(PIPE_A)); udelay(220); @@ -711,7 +710,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val); /* Configure Port Clock Select */ - ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config->shared_dpll); + ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll); I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel); WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL); @@ -731,7 +730,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) * port reversal bit */ I915_WRITE(DDI_BUF_CTL(PORT_E), DDI_BUF_CTL_ENABLE | - ((intel_crtc->config->fdi_lanes - 1) << 1) | + ((crtc->config->fdi_lanes - 1) << 1) | DDI_BUF_TRANS_SELECT(i / 2)); POSTING_READ(DDI_BUF_CTL(PORT_E)); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7673d5d..c627f7e 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3647,12 +3647,11 @@ static void intel_update_pipe_config(struct intel_crtc *crtc, } } -static void intel_fdi_normal_train(struct drm_crtc *crtc) +static void intel_fdi_normal_train(struct intel_crtc *crtc) { - struct drm_device *dev = crtc->dev; + struct drm_device *dev = crtc->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int pipe = intel_crtc->pipe; + int pipe = crtc->pipe; i915_reg_t reg; u32 temp; @@ -3690,12 +3689,11 @@ static void intel_fdi_normal_train(struct drm_crtc *crtc) } /* The FDI link training functions for ILK/Ibexpeak. */ -static void ironlake_fdi_link_train(struct drm_crtc *crtc) +static void ironlake_fdi_link_train(struct intel_crtc *crtc) { - struct drm_device *dev = crtc->dev; + struct drm_device *dev = crtc->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int pipe = intel_crtc->pipe; + int pipe = crtc->pipe; i915_reg_t reg; u32 temp, tries; @@ -3716,7 +3714,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc) reg = FDI_TX_CTL(pip
[Intel-gfx] [PATCH v2 0/8] Try to fix MST regression with DDI IO power domains
Hi, Here's a v2 of the fix for the regression caused by the recent DDI IO power domain changes. This time with moar patches and actual testing. The new patches remove the usage of crtc->config from intel_ddi.c and that also removes the oops with encoder->crtc being NULL. Ander Conselvan de Oliveira (8): drm/i915: Enable DDI IO power domains in the DP MST path drm/i915: Pass intel_crtc to fdi_link_train() hooks drm/i915: Pass intel_crtc to intel_lpt_pch_enable() drm/i915: Pass pipe_config to pch_enable() functions drm/i915: Pass pipe_config to fdi_link_train() functions drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable drm/i915: Remove direct usages of intel_crtc->config from DDI code drm/i915: Remove duplicate DDI enabling logic from MST path drivers/gpu/drm/i915/i915_drv.h | 3 +- drivers/gpu/drm/i915/intel_ddi.c | 103 +-- drivers/gpu/drm/i915/intel_display.c | 100 +- drivers/gpu/drm/i915/intel_dp_mst.c | 20 +-- drivers/gpu/drm/i915/intel_drv.h | 19 +-- 5 files changed, 117 insertions(+), 128 deletions(-) -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/8] drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable
Pass intel_crtc to functions intel_ddi_enable_transcoder_func(), intel_ddi_set_pipe_settings() and intel_ddi_set_vc_payload_alloc(), instead of the generic crtc type. By changing the functions intel_ddi_get_crtc_encoder() so that it receives an intel_crtc parameter, there is no need for the drm_crtc in the callers. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_ddi.c | 62 drivers/gpu/drm/i915/intel_display.c | 8 ++--- drivers/gpu/drm/i915/intel_drv.h | 6 ++-- 3 files changed, 34 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index ccff024..5e21bb5 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -818,21 +818,20 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder) } static struct intel_encoder * -intel_ddi_get_crtc_encoder(struct drm_crtc *crtc) +intel_ddi_get_crtc_encoder(struct intel_crtc *crtc) { - struct drm_device *dev = crtc->dev; - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); + struct drm_device *dev = crtc->base.dev; struct intel_encoder *intel_encoder, *ret = NULL; int num_encoders = 0; - for_each_encoder_on_crtc(dev, crtc, intel_encoder) { + for_each_encoder_on_crtc(dev, &crtc->base, intel_encoder) { ret = intel_encoder; num_encoders++; } if (num_encoders != 1) WARN(1, "%d encoders on crtc for pipe %c\n", num_encoders, -pipe_name(intel_crtc->pipe)); +pipe_name(crtc->pipe)); BUG_ON(ret == NULL); return ret; @@ -1194,12 +1193,11 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc, intel_encoder); } -void intel_ddi_set_pipe_settings(struct drm_crtc *crtc) +void intel_ddi_set_pipe_settings(struct intel_crtc *crtc) { - struct drm_i915_private *dev_priv = to_i915(crtc->dev); - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc); - enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder; + enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; int type = intel_encoder->type; uint32_t temp; @@ -1207,7 +1205,7 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc) WARN_ON(transcoder_is_dsi(cpu_transcoder)); temp = TRANS_MSA_SYNC_CLK; - switch (intel_crtc->config->pipe_bpp) { + switch (crtc->config->pipe_bpp) { case 18: temp |= TRANS_MSA_6_BPC; break; @@ -1227,12 +1225,10 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc) } } -void intel_ddi_set_vc_payload_alloc(struct drm_crtc *crtc, bool state) +void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state) { - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - struct drm_device *dev = crtc->dev; - struct drm_i915_private *dev_priv = to_i915(dev); - enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder; + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; uint32_t temp; temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder)); if (state == true) @@ -1242,14 +1238,12 @@ void intel_ddi_set_vc_payload_alloc(struct drm_crtc *crtc, bool state) I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp); } -void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc) +void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc) { - struct intel_crtc *intel_crtc = to_intel_crtc(crtc); struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc); - struct drm_device *dev = crtc->dev; - struct drm_i915_private *dev_priv = to_i915(dev); - enum pipe pipe = intel_crtc->pipe; - enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder; + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + enum pipe pipe = crtc->pipe; + enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; enum port port = intel_ddi_get_encoder_port(intel_encoder); int type = intel_encoder->type; uint32_t temp; @@ -1258,7 +1252,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc) temp = TRANS_DDI_FUNC_ENABLE; temp |= TRANS_DDI_SELECT_PORT(port); - switch (intel_crtc->config->pipe_bpp) { + switch (crtc->config->pipe_bpp) { case 18: temp |= TRANS_DDI_BPC_6; break; @@ -1275,9 +1269,9 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc)
[Intel-gfx] [PATCH v2 7/8] drm/i915: Remove direct usages of intel_crtc->config from DDI code
Remove direct usages of intel_crtc->config from the DDI code. Functions that didn't yet take a pipe_config as an argument were coverted to do so. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_ddi.c | 61 +++- drivers/gpu/drm/i915/intel_display.c | 12 +++ drivers/gpu/drm/i915/intel_drv.h | 16 +++--- 3 files changed, 49 insertions(+), 40 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 5e21bb5..2f26c75 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1193,11 +1193,12 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc, intel_encoder); } -void intel_ddi_set_pipe_settings(struct intel_crtc *crtc) +void intel_ddi_set_pipe_settings(struct intel_crtc *crtc, +struct intel_crtc_state *pipe_config) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc); - enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder; int type = intel_encoder->type; uint32_t temp; @@ -1205,7 +1206,7 @@ void intel_ddi_set_pipe_settings(struct intel_crtc *crtc) WARN_ON(transcoder_is_dsi(cpu_transcoder)); temp = TRANS_MSA_SYNC_CLK; - switch (crtc->config->pipe_bpp) { + switch (pipe_config->pipe_bpp) { case 18: temp |= TRANS_MSA_6_BPC; break; @@ -1225,10 +1226,12 @@ void intel_ddi_set_pipe_settings(struct intel_crtc *crtc) } } -void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state) +void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, + struct intel_crtc_state *pipe_config, + bool state) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); - enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder; uint32_t temp; temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder)); if (state == true) @@ -1238,12 +1241,13 @@ void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state) I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp); } -void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc) +void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc, + struct intel_crtc_state *pipe_config) { struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc); struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); enum pipe pipe = crtc->pipe; - enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder; enum port port = intel_ddi_get_encoder_port(intel_encoder); int type = intel_encoder->type; uint32_t temp; @@ -1252,7 +1256,7 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc) temp = TRANS_DDI_FUNC_ENABLE; temp |= TRANS_DDI_SELECT_PORT(port); - switch (crtc->config->pipe_bpp) { + switch (pipe_config->pipe_bpp) { case 18: temp |= TRANS_DDI_BPC_6; break; @@ -1269,9 +1273,9 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc) BUG(); } - if (crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC) + if (pipe_config->base.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC) temp |= TRANS_DDI_PVSYNC; - if (crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_PHSYNC) + if (pipe_config->base.adjusted_mode.flags & DRM_MODE_FLAG_PHSYNC) temp |= TRANS_DDI_PHSYNC; if (cpu_transcoder == TRANSCODER_EDP) { @@ -1282,8 +1286,8 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc) * using motion blur mitigation (which we don't * support). */ if (IS_HASWELL(dev_priv) && - (crtc->config->pch_pfit.enabled || -crtc->config->pch_pfit.force_thru)) + (pipe_config->pch_pfit.enabled || +pipe_config->pch_pfit.force_thru)) temp |= TRANS_DDI_EDP_INPUT_A_ONOFF; else temp |= TRANS_DDI_EDP_INPUT_A_ON; @@ -1301,20 +1305,20 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc) } if (type == INTEL_OUTPUT_HDMI) { - if (crtc->config->has_hdmi_sink) + if (pipe_config->has_hd
[Intel-gfx] [PATCH v2 5/8] drm/i915: Pass pipe_config to fdi_link_train() functions
It is preferred to pass pipe_config to functions instead of accessing crtc->config directly. Follow suit and pass pipe_config to the fdi link train functions. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 3 ++- drivers/gpu/drm/i915/intel_ddi.c | 9 + drivers/gpu/drm/i915/intel_display.c | 19 +++ drivers/gpu/drm/i915/intel_drv.h | 3 ++- 4 files changed, 20 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 8b11cdf..82d3d16 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -669,7 +669,8 @@ struct drm_i915_display_funcs { struct intel_encoder *encoder, const struct drm_display_mode *adjusted_mode); void (*audio_codec_disable)(struct intel_encoder *encoder); - void (*fdi_link_train)(struct intel_crtc *crtc); + void (*fdi_link_train)(struct intel_crtc *crtc, + struct intel_crtc_state *pipe_config); void (*init_clock_gating)(struct drm_i915_private *dev_priv); int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc, struct drm_framebuffer *fb, diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 111f660..ccff024 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -674,7 +674,8 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct intel_shared_dpll *pll) * DDI A (which is used for eDP) */ -void hsw_fdi_link_train(struct intel_crtc *crtc) +void hsw_fdi_link_train(struct intel_crtc *crtc, + struct intel_crtc_state *pipe_config) { struct drm_device *dev = crtc->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); @@ -700,7 +701,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc) /* Enable the PCH Receiver FDI PLL */ rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE | FDI_RX_PLL_ENABLE | -FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes); +FDI_DP_PORT_WIDTH(pipe_config->fdi_lanes); I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val); POSTING_READ(FDI_RX_CTL(PIPE_A)); udelay(220); @@ -710,7 +711,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc) I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val); /* Configure Port Clock Select */ - ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll); + ddi_pll_sel = hsw_pll_to_ddi_pll_sel(pipe_config->shared_dpll); I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel); WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL); @@ -730,7 +731,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc) * port reversal bit */ I915_WRITE(DDI_BUF_CTL(PORT_E), DDI_BUF_CTL_ENABLE | - ((crtc->config->fdi_lanes - 1) << 1) | + ((pipe_config->fdi_lanes - 1) << 1) | DDI_BUF_TRANS_SELECT(i / 2)); POSTING_READ(DDI_BUF_CTL(PORT_E)); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index aea302b..16822ef 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3689,7 +3689,8 @@ static void intel_fdi_normal_train(struct intel_crtc *crtc) } /* The FDI link training functions for ILK/Ibexpeak. */ -static void ironlake_fdi_link_train(struct intel_crtc *crtc) +static void ironlake_fdi_link_train(struct intel_crtc *crtc, + struct intel_crtc_state *pipe_config) { struct drm_device *dev = crtc->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); @@ -3714,7 +3715,7 @@ static void ironlake_fdi_link_train(struct intel_crtc *crtc) reg = FDI_TX_CTL(pipe); temp = I915_READ(reg); temp &= ~FDI_DP_PORT_WIDTH_MASK; - temp |= FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes); + temp |= FDI_DP_PORT_WIDTH(pipe_config->fdi_lanes); temp &= ~FDI_LINK_TRAIN_NONE; temp |= FDI_LINK_TRAIN_PATTERN_1; I915_WRITE(reg, temp | FDI_TX_ENABLE); @@ -3789,7 +3790,8 @@ static const int snb_b_fdi_train_param[] = { }; /* The FDI link training functions for SNB/Cougarpoint. */ -static void gen6_fdi_link_train(struct intel_crtc *crtc) +static void gen6_fdi_link_train(struct intel_crtc *crtc, + struct intel_crtc_state *pipe_config) { struct drm_device *dev = crtc->base.dev; struct drm_i915_private *dev_priv = to_i915(dev); @@ -3812,7 +3814,7 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc) reg = FDI_TX_CTL(pipe); temp = I915_READ(reg); temp &= ~FDI_DP_PORT_WIDTH_MASK; - temp |= FDI_DP_PORT_WIDTH(crtc->config->fdi_la
Re: [Intel-gfx] [PATCH i-g-t 3/8] lib: Define a common bit operations library
On 2/27/2017 1:35 AM, Daniel Vetter wrote: On Thu, Feb 09, 2017 at 09:34:49AM +0200, Joonas Lahtinen wrote: On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote: Bring the test/set/clear bit functions we have into a single place. Signed-off-by: Michel Thierry Reviewed-by: Joonas Lahtinen Can we please have docs for this new library? Sure; although they won't be static (or just a .h file) anymore. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] kbl_guc and bxt_guc firmware missing from linux-firmware
On Wed, Mar 01, 2017 at 03:23:06PM +0200, Jani Nikula wrote: > On Wed, 15 Feb 2017, Seth Forshee wrote: > > Maybe it would be good to have something like MODULE_OPTIONAL_FIRMWARE > > to identify firmware that isn't required but will be used by the driver > > if available. Then mkinitramfs can try to copy those files along with > > the module but know that there's no need to produce a warning if it's > > not present. > > The documentation for the current MODULE_FIRMWARE already says, > "Optional firmware file (or files) needed by the module format is simply > firmware file name." That may have been the intention. But since it is the only thing available it has been used for any firmware files, including many which will cause device probe to fail if not present. Userspace tools seem to treat the firmware files in modinfo to mean, "firmware files without which the hardware may fail to function or may not function properly," because in many cases that is true. I'd argue that this is the de facto definition of MODULE_FIRMWARE, and that the comment is at best misleading. Seth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 8/8] drm/i915: Remove duplicate DDI enabling logic from MST path
The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially the same as in intel_ddi_pre_enable_dp(). So reuse the latter function by calling the post_disable hook on the intel_dig_port instead of duplicating that code. v2: Don't oops because of a NULL encoder->crtc. (Ville) Cc: Imre Deak Cc: Ville Syrjälä Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_ddi.c| 2 ++ drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++ 2 files changed, 5 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 2f26c75..208500a 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1714,6 +1714,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, enum port port = intel_ddi_get_encoder_port(encoder); struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base); + WARN_ON(link_mst && port == PORT_A); + intel_dp_set_link_params(intel_dp, link_rate, lane_count, link_mst); if (encoder->type == INTEL_OUTPUT_EDP) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index a8334e1..094cbdc 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links); - if (intel_dp->active_mst_links == 0) { - intel_ddi_clk_select(&intel_dig_port->base, -pipe_config->shared_dpll); - - intel_display_power_get(dev_priv, - intel_dig_port->ddi_io_power_domain); - - intel_prepare_dp_ddi_buffers(&intel_dig_port->base); - intel_dp_set_link_params(intel_dp, -pipe_config->port_clock, -pipe_config->lane_count, -true); - - intel_ddi_init_dp_buf_reg(&intel_dig_port->base); - - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); - - intel_dp_start_link_train(intel_dp); - intel_dp_stop_link_train(intel_dp); - } + if (intel_dp->active_mst_links == 0) + intel_dig_port->base.pre_enable(&intel_dig_port->base, + pipe_config, NULL); ret = drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr, connector->port, -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable sequence
On Wed, 01 Mar 2017, Madhav Chauhan wrote: > From: Deepak M > > v2: Addressed Jani's Review comments(renamed bit field macros) > v3: Jani's Review comment for aligning code to platforms and added > wrapper functions. > v4: Corrected enable/disable seuqence as per BSPEC > v5: Corrected waiting twice for same bit (Review comments: Jani) > v6: Rebased to Han's patches(dsi restructuring code) > > Signed-off-by: Deepak M > Signed-off-by: Madhav Chauhan > --- > drivers/gpu/drm/i915/intel_dsi.c | 206 > --- > 1 file changed, 195 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > b/drivers/gpu/drm/i915/intel_dsi.c > index 20ed799..8e97bae3 100644 > --- a/drivers/gpu/drm/i915/intel_dsi.c > +++ b/drivers/gpu/drm/i915/intel_dsi.c > @@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct > intel_encoder *encoder, > return true; > } > > +static void glk_dsi_device_ready(struct intel_encoder *encoder) > +{ > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base); > + enum port port; > + u32 tmp, val; > + > + /* Set the MIPI mode > + * If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting. > + * Power ON MIPI IO first and then write into IO reset and LP wake bits > + */ > + for_each_dsi_port(port, intel_dsi->ports) { > + tmp = I915_READ(MIPI_CTRL(port)); > + I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE); > + } > + > + /* Put the IO into reset */ > + tmp = I915_READ(MIPI_CTRL(PORT_A)); > + tmp &= ~GLK_MIPIIO_RESET_RELEASED; > + I915_WRITE(MIPI_CTRL(PORT_A), tmp); > + > + /* Program LP Wake */ > + for_each_dsi_port(port, intel_dsi->ports) { > + tmp = I915_READ(MIPI_CTRL(port)); > + tmp |= GLK_LP_WAKE; > + I915_WRITE(MIPI_CTRL(port), tmp); > + } > + > + /* Wait for Pwr ACK */ > + for_each_dsi_port(port, intel_dsi->ports) { > + if (intel_wait_for_register(dev_priv, > + MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED, > + GLK_MIPIIO_PORT_POWERED, 20)) > + DRM_ERROR("MIPIO port is powergated\n"); > + } > + > + /* Wait for MIPI PHY status bit to set */ > + for_each_dsi_port(port, intel_dsi->ports) { > + if (intel_wait_for_register(dev_priv, > + MIPI_CTRL(port), GLK_PHY_STATUS_PORT_READY, > + GLK_PHY_STATUS_PORT_READY, 20)) > + DRM_ERROR("PHY is not ON\n"); > + } > + > + /* Get IO out of reset */ > + tmp = I915_READ(MIPI_CTRL(PORT_A)); > + I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED); > + > + /* Get IO out of Low power state*/ > + for_each_dsi_port(port, intel_dsi->ports) { > + if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY)) { > + val = I915_READ(MIPI_DEVICE_READY(port)); > + val &= ~ULPS_STATE_MASK; > + val |= DEVICE_READY; > + I915_WRITE(MIPI_DEVICE_READY(port), val); > + usleep_range(10, 15); > + } > + > + /* Enter ULPS */ > + val = I915_READ(MIPI_DEVICE_READY(port)); > + val &= ~ULPS_STATE_MASK; > + val |= (ULPS_STATE_ENTER | DEVICE_READY); > + I915_WRITE(MIPI_DEVICE_READY(port), val); > + > + /* Wait for ULPS Not active */ > + if (intel_wait_for_register(dev_priv, > + MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, > + GLK_ULPS_NOT_ACTIVE, 20)) Auch, I missed this. The if statement covers the next line, and my compiler didn't complain. I already pushed this, so please send a follow-up fix on top. BR, Jani. > + > + /* Exit ULPS */ > + val = I915_READ(MIPI_DEVICE_READY(port)); > + val &= ~ULPS_STATE_MASK; > + val |= (ULPS_STATE_EXIT | DEVICE_READY); > + I915_WRITE(MIPI_DEVICE_READY(port), val); > + > + /* Enter Normal Mode */ > + val = I915_READ(MIPI_DEVICE_READY(port)); > + val &= ~ULPS_STATE_MASK; > + val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY); > + I915_WRITE(MIPI_DEVICE_READY(port), val); > + > + tmp = I915_READ(MIPI_CTRL(port)); > + tmp &= ~GLK_LP_WAKE; > + I915_WRITE(MIPI_CTRL(port), tmp); > + } > + > + /* Wait for Stop state */ > + for_each_dsi_port(port, intel_dsi->ports) { > + if (intel_wait_for_register(dev_priv, > + MIPI_CTRL(port), GLK_DATA_LANE_STOP_STATE, > + GLK_DATA_LANE_STOP_STATE, 20)) > + DRM_ERROR("Date lane not in STOP state\n"); > + }
[Intel-gfx] [PATCH v2 1/8] drm/i915: Enable DDI IO power domains in the DP MST path
Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after enabling DPLL") changed how the DDI IO power domains get enabled, but neglected the need to enable those domains when enabling a DP connector with MST enabled, leading to Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler Fixes: 62b695662a24 ("drm/i915: Only enable DDI IO power domains after enabling DPLL") Cc: David Weinehall Cc: Imre Deak Cc: Ander Conselvan de Oliveira Cc: David Weinehall Cc: Daniel Vetter Cc: Jani Nikula Cc: intel-gfx@lists.freedesktop.org Cc: Ville Syrjälä Reported-by: Ville Syrjälä Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_dp_mst.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index d94fd4b..a8334e1 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -163,6 +163,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, intel_ddi_clk_select(&intel_dig_port->base, pipe_config->shared_dpll); + intel_display_power_get(dev_priv, + intel_dig_port->ddi_io_power_domain); + intel_prepare_dp_ddi_buffers(&intel_dig_port->base); intel_dp_set_link_params(intel_dp, pipe_config->port_clock, -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/8] drm/i915: Pass pipe_config to pch_enable() functions
On Wed, Mar 01, 2017 at 04:13:14PM +0200, Ander Conselvan de Oliveira wrote: > Using crtc->config directly is being removed in favor of passing a > pipe_config. Follow the trend and pass pipe_config to pch_enable() > functions. > > Signed-off-by: Ander Conselvan de Oliveira > > --- > drivers/gpu/drm/i915/intel_display.c | 18 ++ > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 45415f0..aea302b 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -4456,7 +4456,8 @@ intel_trans_dp_port_sel(struct intel_crtc *crtc) > * - DP transcoding bits > * - transcoder > */ > -static void ironlake_pch_enable(struct intel_crtc *crtc) > +static void ironlake_pch_enable(struct intel_crtc *crtc, > + struct intel_crtc_state *pipe_config) const Also s/pipe_config/crtc_state/ perhaps? IMO we should try to start unifying our naming convention to reduce the confusion a bit. You could also pass just the state since you can dig up the crtc from there. > { > struct drm_device *dev = crtc->base.dev; > struct drm_i915_private *dev_priv = to_i915(dev); > @@ -4484,7 +4485,7 @@ static void ironlake_pch_enable(struct intel_crtc *crtc) > temp = I915_READ(PCH_DPLL_SEL); > temp |= TRANS_DPLL_ENABLE(pipe); > sel = TRANS_DPLLB_SEL(pipe); > - if (crtc->config->shared_dpll == > + if (pipe_config->shared_dpll == > intel_get_shared_dpll_by_id(dev_priv, DPLL_ID_PCH_PLL_B)) > temp |= sel; > else > @@ -4509,9 +4510,9 @@ static void ironlake_pch_enable(struct intel_crtc *crtc) > > /* For PCH DP, enable TRANS_DP_CTL */ > if (HAS_PCH_CPT(dev_priv) && > - intel_crtc_has_dp_encoder(crtc->config)) { > + intel_crtc_has_dp_encoder(pipe_config)) { > const struct drm_display_mode *adjusted_mode = > - &crtc->config->base.adjusted_mode; > + &pipe_config->base.adjusted_mode; > u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPECONF_BPC_MASK) >> 5; > i915_reg_t reg = TRANS_DP_CTL(pipe); > temp = I915_READ(reg); > @@ -4546,10 +4547,11 @@ static void ironlake_pch_enable(struct intel_crtc > *crtc) > ironlake_enable_pch_transcoder(dev_priv, pipe); > } > > -static void lpt_pch_enable(struct intel_crtc *crtc) > +static void lpt_pch_enable(struct intel_crtc *crtc, > +struct intel_crtc_state *pipe_config) ditto Anyway looks correct, so w/ or w/o the extra ideas this is Reviewed-by: Ville Syrjälä > { > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); > - enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; > + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder; > > assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A); > > @@ -5283,7 +5285,7 @@ static void ironlake_crtc_enable(struct > intel_crtc_state *pipe_config, > intel_enable_pipe(intel_crtc); > > if (intel_crtc->config->has_pch_encoder) > - ironlake_pch_enable(intel_crtc); > + ironlake_pch_enable(intel_crtc, pipe_config); > > assert_vblank_disabled(crtc); > drm_crtc_vblank_on(crtc); > @@ -5393,7 +5395,7 @@ static void haswell_crtc_enable(struct intel_crtc_state > *pipe_config, > intel_enable_pipe(intel_crtc); > > if (intel_crtc->config->has_pch_encoder) > - lpt_pch_enable(intel_crtc); > + lpt_pch_enable(intel_crtc, pipe_config); > > if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST)) > intel_ddi_set_vc_payload_alloc(crtc, true); > -- > 2.9.3 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Fix the kernel doc warning for drm_link_status
This fixes the kernel doc warning that was introduced in the 'commit 40ee6fbef75fe6 ("drm: Add a new connector atomic property for link status")'. Description has been added for the enum values. Signed-off-by: Manasi Navare Cc: Jani Nikula Cc: Daniel Vetter Cc: dri-de...@lists.freedesktop.org --- include/drm/drm_connector.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index ccc0770..fabb35a 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -94,6 +94,11 @@ enum subpixel_order { * * This enum is used as the connector's link status property value. * It is set to the values defined in uapi. + * + * @DRM_LINK_STATUS_GOOD: DP Link is Good as a result of successful + *link training + * @DRM_LINK_STATUS_BAD: DP Link is BAD as a result of link training + * failure */ enum drm_link_status { DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD, -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/6] drm/edid: detect SCDC support in HF-VSDB
On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote: > This patch does following: > - Adds a new structure (drm_hdmi_info) in drm_display_info. > This structure will be used to save and indicate if sink > supports advanced HDMI 2.0 features > - Adds another structure drm_scdc within drm_hdmi_info, to > reflect scdc support and capabilities in connected HDMI 2.0 sink. > - Checks the HF-VSDB block for presence of SCDC, and marks it > in scdc structure > - If SCDC is present, checks if sink is capable of generating > SCDC read request, and marks it in scdc structure. > > V2: Addressed review comments > Thierry: > - Fix typos in commit message and make abbreviation consistent > across the commit message. > - Change structure object name from hdmi_info -> hdmi > - Fix typos and abbreviations in description of structure drm_hdmi_info > end the description with a full stop. > - Create a structure drm_scdc, and keep all information related to SCDC > register set (supported, read request supported) etc in it. > > Ville: > - Change rr -> read_request > - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all > of HF-VSDB parsing can be kept in same function, in incremental > patches. > > V3: Rebase. > V4: Rebase. > V5: Rebase. > > Signed-off-by: Shashank Sharma > Reviewed-by: Thierry Reding > --- > drivers/gpu/drm/drm_edid.c| 33 +++- > drivers/gpu/drm/drm_scdc_helper.c | 111 > ++ > include/drm/drm_connector.h | 19 +++ > include/drm/drm_edid.h| 6 ++- > include/drm/drm_scdc_helper.h | 27 ++ > 5 files changed, 194 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 0881108..e84c5ab 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -37,6 +37,7 @@ > #include > #include > #include > +#include > > #include "drm_crtc_internal.h" > > @@ -3817,13 +3818,43 @@ enum hdmi_quantization_range > static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector, >const u8 *hf_vsdb) > { > - struct drm_hdmi_info *hdmi = &connector->display_info.hdmi; > + struct drm_display_info *display = &connector->display_info; > + struct drm_hdmi_info *hdmi = &display->hdmi; > > if (hf_vsdb[6] & 0x80) { > hdmi->scdc.supported = true; > if (hf_vsdb[6] & 0x40) > hdmi->scdc.read_request = true; > } > + > + /* > + * All HDMI 2.0 monitors must support scrambling at rates > 340 MHz. > + * And as per the spec, three factors confirm this: > + * * Availability of a HF-VSDB block in EDID (check) > + * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check) > + * * SCDC support available (let's check) > + * Lets check it out. > + */ > + > + if (hf_vsdb[5]) { > + /* max clock is 5000 KHz times block value */ > + u32 max_tmds_clock = hf_vsdb[5] * 5000; > + struct drm_scdc *scdc = &hdmi->scdc; > + > + if (max_tmds_clock > 34) { > + display->max_tmds_clock = max_tmds_clock; > + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n", > + display->max_tmds_clock); > + } > + > + if (scdc->supported) { > + scdc->scrambling.supported = true; > + > + /* Few sinks support scrambling for cloks < 340M */ > + if ((hf_vsdb[6] & 0x8)) > + scdc->scrambling.low_rates = true; > + } > + } > } > > static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector, > diff --git a/drivers/gpu/drm/drm_scdc_helper.c > b/drivers/gpu/drm/drm_scdc_helper.c > index c2dd33f..180a7cd 100644 > --- a/drivers/gpu/drm/drm_scdc_helper.c > +++ b/drivers/gpu/drm/drm_scdc_helper.c > @@ -22,8 +22,10 @@ > */ > > #include > +#include > > #include > +#include > > /** > * DOC: scdc helpers > @@ -121,3 +123,112 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 > offset, > return 0; > } > EXPORT_SYMBOL(drm_scdc_write); > + > +/** > + * drm_scdc_check_scrambling_status - what is status of scrambling? > + * @adapter: I2C adapter for DDC channel > + * > + * Reads the scrambler status over SCDC, and checks the > + * scrambling status. > + * > + * Returns: > + * True if the scrambling is enabled, false otherwise. > + */ > + > +bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter) > +{ > + u8 status; > + int ret; > + > + ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status); > + if (ret < 0) { > + DRM_ERROR("Failed to read scrambling status, error %d\n", ret); > + return false; > + } > + > + return status & SCDC_SCRAMBLING_STATUS;
Re: [Intel-gfx] [PATCH] drm: Fix the kernel doc warning for drm_link_status
On Wed, Mar 01, 2017 at 06:45:10AM -0800, Manasi Navare wrote: > This fixes the kernel doc warning that was introduced in > the 'commit 40ee6fbef75fe6 ("drm: Add a new connector > atomic property for link status")'. Description has > been added for the enum values. > > Signed-off-by: Manasi Navare > Cc: Jani Nikula > Cc: Daniel Vetter > Cc: dri-de...@lists.freedesktop.org Thanks for the quick fix, applied. -Daniel > --- > include/drm/drm_connector.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > index ccc0770..fabb35a 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -94,6 +94,11 @@ enum subpixel_order { > * > * This enum is used as the connector's link status property value. > * It is set to the values defined in uapi. > + * > + * @DRM_LINK_STATUS_GOOD: DP Link is Good as a result of successful > + *link training > + * @DRM_LINK_STATUS_BAD: DP Link is BAD as a result of link training > + * failure > */ > enum drm_link_status { > DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD, > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 5/6] drm/i915: enable scrambling
On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the monitor supports scrambling, and if required, > enables it during the modeset. > > V2: Addressed review comments from Ville: > - Do not track scrambling status in DRM layer, track somewhere in > driver like in intel_crtc_state. > - Don't talk to monitor at such a low layer, set monitor scrambling > in intel_enable_ddi() before enabling the port. > > V3: Addressed review comments from Jani > - In comments, function names, use "sink" instead of "monitor", >so that the implementation could be close to the language of >HDMI spec. > > V4: Addressed review comment from Maarten > - scrambling -> hdmi_scrambling >high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio > > V5: Addressed review comments from Ville and Ander > - Do not modifiy the crtc_state after compute_config. Move all >scrambling and tmds_clock_ratio calcutations to compute_config. > - While setting scrambling for source/sink, do not check the >conditions again, just go by the crtc_state flags. This will >simplyfy the condition checks. > > Signed-off-by: Shashank Sharma > --- > drivers/gpu/drm/i915/i915_reg.h | 4 ++ > drivers/gpu/drm/i915/intel_ddi.c | 29 > drivers/gpu/drm/i915/intel_drv.h | 14 ++ > drivers/gpu/drm/i915/intel_hdmi.c | 98 > +++ > 4 files changed, 145 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index ce6f096..1759b64 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -7824,7 +7824,11 @@ enum { > #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_HDMI_SCRAMBLER_CTS_ENABLE (1<<7) > +#define TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6) > #define TRANS_DDI_BFI_ENABLE(1<<4) > +#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4) > +#define TRANS_DDI_HDMI_SCRAMBLING (1<<0) > > /* DisplayPort Transport Control */ > #define _DP_TP_CTL_A 0x64040 > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index a7c08d7..24bc3a8 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc > *crtc) > temp |= TRANS_DDI_MODE_SELECT_HDMI; > else > temp |= TRANS_DDI_MODE_SELECT_DVI; > + > + if (IS_GEMINILAKE(dev_priv)) > + temp = intel_hdmi_handle_source_scrambling( > + intel_encoder, > + intel_crtc->config, temp); > } else if (type == INTEL_OUTPUT_ANALOG) { > temp |= TRANS_DDI_MODE_SELECT_FDI; > temp |= (intel_crtc->config->fdi_lanes - 1) << 1; > @@ -1885,6 +1890,21 @@ static void intel_enable_ddi(struct intel_encoder > *intel_encoder, > struct intel_digital_port *intel_dig_port = > enc_to_dig_port(encoder); > > + if (IS_GEMINILAKE(dev_priv)) { > + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc); > + /* > + * GLK sports a native HDMI 2.0 controller. If required > + * clock rate is > 340 Mhz && scrambling is supported > + * by sink, enable scrambling before enabling the > + * HDMI 2.0 port. The sink can choose to disable the > + * scrambling if it doesn't detect a scrambled within > + * 100 ms. > + */ > + intel_hdmi_handle_sink_scrambling(intel_encoder, > + conn_state->connector, > + crtc->config, true); > + } > + > /* In HDMI/DVI mode, the port width, and swing/emphasis values >* are ignored so nothing special needs to be done besides >* enabling the port. > @@ -1912,11 +1932,20 @@ static void intel_disable_ddi(struct intel_encoder > *intel_encoder, > struct drm_connector_state *old_conn_state) > { > struct drm_encoder *encoder = &intel_encoder->base; > + struct drm_i915_private *dev_priv = encoder->dev->dev_private; > int type = intel_encoder->type; > > if (old_crtc_state->has_audio) > intel_audio_codec_disable(intel_encoder); > > + if ((type == INTEL_OUTPUT_HDMI) && IS_GEMINILAKE(dev_priv)) { ^
Re: [Intel-gfx] [PATCH 18/18] drm/i915: Add FIFO underrun tracepoints
Op 16-02-17 om 19:07 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > Add tracepoints for display FIFO underruns. Makes it more convenient to > correlate the underruns with other display tracepoints. I'm still not sold on how crtc_state->visible_planes deviates from crtc_state->planes_mask and other *_mask's. Should probably rename it to visible_plane_id_mask to make it clear it's a mask not using drm_plane_index. Otherwise looks good, so for the whole series: Reviewed-by: Maarten Lankhorst ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move updating color management to before vblank evasion
On Tue, Feb 28, 2017 at 05:01:25PM +0200, Ville Syrjälä wrote: > On Tue, Feb 28, 2017 at 03:28:47PM +0100, Maarten Lankhorst wrote: > > This cannot be done reliably during vblank evasasion > > since the color management registers are not double buffered. > > > > The original commit that moved it always during vblank evasion was > > wrong, so revert it to before vblank evasion again. > > > > Signed-off-by: Maarten Lankhorst > > Fixes: 20a34e78f0d7 ("drm/i915: Update color management during vblank > > evasion.") > > Cc: sta...@vger.kernel.org # v4.7+ > > Wasn't there a bugzilla + tested-by ? Seems we have two bugzillas now: https://bugs.freedesktop.org/show_bug.cgi?id=91883 https://bugs.freedesktop.org/show_bug.cgi?id=1 First one is about the atomic update fails, the second about the assert_dsi_pll() mutex vs. irq_disabled() warning. No actual t-bs for this specific variant of the patch (yet) from what I can see. Anyways, this is Reviewed-by: Ville Syrjälä > > > --- > > drivers/gpu/drm/i915/intel_display.c | 12 +++- > > 1 file changed, 7 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 3c862d0ab389..a0108041fd4a 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -13301,17 +13301,19 @@ static void intel_begin_crtc_commit(struct > > drm_crtc *crtc, > > to_intel_atomic_state(old_crtc_state->state); > > bool modeset = needs_modeset(crtc->state); > > > > + if (!modeset && > > + (intel_cstate->base.color_mgmt_changed || > > +intel_cstate->update_pipe)) { > > + intel_color_set_csc(crtc->state); > > + intel_color_load_luts(crtc->state); > > + } > > + > > /* Perform vblank evasion around commit operation */ > > intel_pipe_update_start(intel_crtc); > > > > if (modeset) > > goto out; > > > > - if (crtc->state->color_mgmt_changed || > > to_intel_crtc_state(crtc->state)->update_pipe) { > > - intel_color_set_csc(crtc->state); > > - intel_color_load_luts(crtc->state); > > - } > > - > > if (intel_cstate->update_pipe) > > intel_update_pipe_config(intel_crtc, old_intel_cstate); > > else if (INTEL_GEN(dev_priv) >= 9) > > -- > > 2.7.4 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Complain if we take too long under vblank evasion.
On Tue, Feb 28, 2017 at 03:28:48PM +0100, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/intel_sprite.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > b/drivers/gpu/drm/i915/intel_sprite.c > index 27e0752d1578..375ca91b308c 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -65,6 +65,8 @@ int intel_usecs_to_scanlines(const struct drm_display_mode > *adjusted_mode, > 1000 * adjusted_mode->crtc_htotal); > } > > +#define VBLANK_EVASION_TIME_US 100 > + > /** > * intel_pipe_update_start() - start update of a set of display registers > * @crtc: the crtc of which the registers are going to be updated > @@ -92,7 +94,8 @@ void intel_pipe_update_start(struct intel_crtc *crtc) > vblank_start = DIV_ROUND_UP(vblank_start, 2); > > /* FIXME needs to be calibrated sensibly */ > - min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, 100); > + min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, > + VBLANK_EVASION_TIME_US); > max = vblank_start - 1; > > local_irq_disable(); > @@ -191,7 +194,12 @@ void intel_pipe_update_end(struct intel_crtc *crtc, > struct intel_flip_work *work > ktime_us_delta(end_vbl_time, > crtc->debug.start_vbl_time), > crtc->debug.min_vbl, crtc->debug.max_vbl, > crtc->debug.scanline_start, scanline_end); > - } > + } else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) > > +VBLANK_EVASION_TIME_US) > + DRM_WARN("Atomic update on pipe (%c) took %lld us, max time > under evasion is %u us\n", > + pipe_name(pipe), > + ktime_us_delta(end_vbl_time, > crtc->debug.start_vbl_time), > + VBLANK_EVASION_TIME_US); Hmm. Yeah this should make it very likely that we'll catch any potential fails even when they don't happen to hit the actual critical section. Hopefully it won't result in massive amounts of noise. One way to find out ;) Reviewed-by: Ville Syrjälä > } > > static void > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915: Prevent concurrent tiling/framebuffer modifications
Reintroduce a lock around tiling vs framebuffer creation to prevent modification of the obj->tiling_and_stride whilst the framebuffer is being created. Rather than use struct_mutex once again, use the per-object lock - this will also be required in future to prevent changing the tiling whilst submitting rendering. Reported-by: Ville Syrjälä Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the framebuffer") Signed-off-by: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gem_object.h | 18 +- drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/i915_gem_tiling.c | 9 - drivers/gpu/drm/i915/intel_display.c | 25 - 4 files changed, 42 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h index cce63b225746..33b0dc4782a9 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.h +++ b/drivers/gpu/drm/i915/i915_gem_object.h @@ -165,7 +165,7 @@ struct drm_i915_gem_object { struct reservation_object *resv; /** References from framebuffers, locks out tiling changes. */ - atomic_t framebuffer_references; + unsigned int framebuffer_references; /** Record of address bit 17 of each page at last unbind. */ unsigned long *bit_17; @@ -260,6 +260,16 @@ extern void drm_gem_object_unreference(struct drm_gem_object *); __deprecated extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *); +static inline void i915_gem_object_lock(struct drm_i915_gem_object *obj) +{ + reservation_object_lock(obj->resv, NULL); +} + +static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj) +{ + reservation_object_unlock(obj->resv); +} + static inline bool i915_gem_object_is_dead(const struct drm_i915_gem_object *obj) { @@ -306,6 +316,12 @@ i915_gem_object_clear_active_reference(struct drm_i915_gem_object *obj) void __i915_gem_object_release_unless_active(struct drm_i915_gem_object *obj); +static inline bool +i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj) +{ + return READ_ONCE(obj->framebuffer_references); +} + static inline unsigned int i915_gem_object_get_tiling(struct drm_i915_gem_object *obj) { diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c index 8bc515e8b2a2..006a8b908f77 100644 --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c @@ -207,7 +207,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv, if (!(flags & I915_SHRINK_ACTIVE) && (i915_gem_object_is_active(obj) || -atomic_read(&obj->framebuffer_references))) +i915_gem_object_is_framebuffer(obj))) continue; if (!can_release_pages(obj)) diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c b/drivers/gpu/drm/i915/i915_gem_tiling.c index 46ade36dcee6..a0d6d4317a49 100644 --- a/drivers/gpu/drm/i915/i915_gem_tiling.c +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c @@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj, if ((tiling | stride) == obj->tiling_and_stride) return 0; - if (atomic_read(&obj->framebuffer_references)) + if (i915_gem_object_is_framebuffer(obj)) return -EBUSY; /* We need to rebind the object if its current allocation @@ -258,6 +258,12 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj, if (err) return err; + i915_gem_object_lock(obj); + if (i915_gem_object_is_framebuffer(obj)) { + i915_gem_object_unlock(obj); + return -EBUSY; + } + /* If the memory has unknown (i.e. varying) swizzling, we pin the * pages to prevent them being swapped out and causing corruption * due to the change in swizzling. @@ -294,6 +300,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj, } obj->tiling_and_stride = tiling | stride; + i915_gem_object_unlock(obj); /* Force the fence to be reacquired for GTT access */ i915_gem_release_mmap(obj); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f8ef03003a65..99e8d9c8d60b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14186,7 +14186,10 @@ static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb) drm_framebuffer_cleanup(fb); - WARN_ON(atomic_dec_return(&intel_fb->obj->framebuffer_references) < 0); + i915_gem_object_lock(intel_fb->obj); + WARN_ON(!intel_fb->obj->framebuffer_references--); + i915_gem_object_unlock(intel_fb->obj); + i915_gem_object_put(intel_fb-
[Intel-gfx] [CI 1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path
No more direct return -EINVAL as we have to unwind the obj->framebuffer_references. Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the framebuffer") Signed-off-by: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7673d5d9e74a..f8ef03003a65 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14314,7 +14314,7 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, if (INTEL_INFO(dev_priv)->gen < 4 && tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) { DRM_DEBUG("tiling_mode must match fb modifier exactly on gen2/3\n"); - return -EINVAL; + goto err; } stride_alignment = intel_fb_stride_alignment(dev_priv, @@ -14359,7 +14359,7 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, if (INTEL_GEN(dev_priv) > 3) { DRM_DEBUG("unsupported pixel format: %s\n", drm_get_format_name(mode_cmd->pixel_format, &format_name)); - return -EINVAL; + goto err; } break; case DRM_FORMAT_ABGR: @@ -14367,7 +14367,7 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, INTEL_GEN(dev_priv) < 9) { DRM_DEBUG("unsupported pixel format: %s\n", drm_get_format_name(mode_cmd->pixel_format, &format_name)); - return -EINVAL; + goto err; } break; case DRM_FORMAT_XBGR: @@ -14376,14 +14376,14 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, if (INTEL_GEN(dev_priv) < 4) { DRM_DEBUG("unsupported pixel format: %s\n", drm_get_format_name(mode_cmd->pixel_format, &format_name)); - return -EINVAL; + goto err; } break; case DRM_FORMAT_ABGR2101010: if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) { DRM_DEBUG("unsupported pixel format: %s\n", drm_get_format_name(mode_cmd->pixel_format, &format_name)); - return -EINVAL; + goto err; } break; case DRM_FORMAT_YUYV: @@ -14393,13 +14393,13 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, if (INTEL_GEN(dev_priv) < 5) { DRM_DEBUG("unsupported pixel format: %s\n", drm_get_format_name(mode_cmd->pixel_format, &format_name)); - return -EINVAL; + goto err; } break; default: DRM_DEBUG("unsupported pixel format: %s\n", drm_get_format_name(mode_cmd->pixel_format, &format_name)); - return -EINVAL; + goto err; } /* FIXME need to adjust LINOFF/TILEOFF accordingly. */ @@ -14412,7 +14412,7 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, ret = intel_fill_fb_info(dev_priv, &intel_fb->base); if (ret) - return ret; + goto err; ret = drm_framebuffer_init(obj->base.dev, &intel_fb->base, -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement Link Rate fallback on Link training failure
On Fri, Dec 16, 2016 at 12:29:07PM +0200, Jani Nikula wrote: > From: Manasi Navare > > If link training at a link rate optimal for a particular > mode fails during modeset's atomic commit phase, then we > let the modeset complete and then retry. We save the link rate > value at which link training failed, update the link status property > to "BAD" and use a lower link rate to prune the modes. It will redo > the modeset on the current mode at lower link rate or if the current > mode gets pruned due to lower link constraints then, it will send a > hotplug uevent for userspace to handle it. > > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4, > 4.3.1.6. > > v9: > * Use the trimmed max values of link rate/lane count based on > link train fallback (Daniel Vetter) > v8: > * Set link_status to BAD first and then call mode_valid (Jani Nikula) > v7: > Remove the redundant variable in previous patch itself > v6: > * Obtain link rate index from fallback_link_rate using > the helper intel_dp_link_rate_index (Jani Nikula) > * Include fallback within intel_dp_start_link_train (Jani Nikula) > v5: > * Move set link status to drm core (Daniel Vetter, Jani Nikula) > v4: > * Add fallback support for non DDI platforms too > * Set connector->link status inside set_link_status function > (Jani Nikula) > v3: > * Set link status property to BAd unconditionally (Jani Nikula) > * Dont use two separate variables link_train_failed and link_status > to indicate same thing (Jani Nikula) > v2: > * Squashed a few patches (Jani Nikula) > > Acked-by: Tony Cheng > Acked-by: Harry Wentland > Cc: Jani Nikula > Cc: Daniel Vetter > Cc: Ville Syrjala > Signed-off-by: Manasi Navare > Reviewed-by: Jani Nikula > Signed-off-by: Jani Nikula Pushed to drm-misc-next after a quick irc chat with Manasi. Thanks, Daniel > --- > drivers/gpu/drm/i915/intel_dp.c | 27 > +++ > drivers/gpu/drm/i915/intel_dp_link_training.c | 22 -- > drivers/gpu/drm/i915/intel_drv.h | 3 +++ > 3 files changed, 50 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 45ebc9632633..97d1e03d22b8 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -5671,6 +5671,29 @@ static bool intel_edp_init_connector(struct intel_dp > *intel_dp, > return false; > } > > +static void intel_dp_modeset_retry_work_fn(struct work_struct *work) > +{ > + struct intel_connector *intel_connector; > + struct drm_connector *connector; > + > + intel_connector = container_of(work, typeof(*intel_connector), > +modeset_retry_work); > + connector = &intel_connector->base; > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id, > + connector->name); > + > + /* Grab the locks before changing connector property*/ > + mutex_lock(&connector->dev->mode_config.mutex); > + /* Set connector link status to BAD and send a Uevent to notify > + * userspace to do a modeset. > + */ > + drm_mode_connector_set_link_status_property(connector, > + DRM_MODE_LINK_STATUS_BAD); > + mutex_unlock(&connector->dev->mode_config.mutex); > + /* Send Hotplug uevent so userspace can reprobe */ > + drm_kms_helper_hotplug_event(connector->dev); > +} > + > bool > intel_dp_init_connector(struct intel_digital_port *intel_dig_port, > struct intel_connector *intel_connector) > @@ -5683,6 +5706,10 @@ intel_dp_init_connector(struct intel_digital_port > *intel_dig_port, > enum port port = intel_dig_port->port; > int type; > > + /* Initialize the work for modeset in case of link train failure */ > + INIT_WORK(&intel_connector->modeset_retry_work, > + intel_dp_modeset_retry_work_fn); > + > if (WARN(intel_dig_port->max_lanes < 1, >"Not enough lanes (%d) for DP on port %c\n", >intel_dig_port->max_lanes, port_name(port))) > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c > b/drivers/gpu/drm/i915/intel_dp_link_training.c > index 0048b520baf7..955b239e7c2d 100644 > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > @@ -313,6 +313,24 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp) > void > intel_dp_start_link_train(struct intel_dp *intel_dp) > { > - intel_dp_link_training_clock_recovery(intel_dp); > - intel_dp_link_training_channel_equalization(intel_dp); > + struct intel_connector *intel_connector = intel_dp->attached_connector; > + > + if (!intel_dp_link_training_clock_recovery(intel_dp)) > + goto failure_handling; > + if (!intel_dp_link_training_channel_equalization(intel_dp)) > + goto failure_handling; > + > + DRM_DEBUG_KMS("Link Training Passed at Link
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Prevent concurrent tiling/framebuffer modifications
On Wed, Mar 01, 2017 at 03:09:36PM +0200, Ville Syrjälä wrote: > On Tue, Feb 28, 2017 at 04:22:33PM +, Chris Wilson wrote: > > Reintroduce a lock around tiling vs framebuffer creation to prevent > > modification of the obj->tiling_and_stride whilst the framebuffer is > > being created. Rather than use struct_mutex once again, use the > > per-object lock - this will also be required in future to prevent > > changing the tiling whilst submitting rendering. > > > > Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating > > the framebuffer") > > Signed-off-by: Chris Wilson > > Cc: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/i915_gem_object.h | 18 +- > > drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +- > > drivers/gpu/drm/i915/i915_gem_tiling.c | 9 - > > drivers/gpu/drm/i915/intel_display.c | 25 - > > 4 files changed, 42 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h > > b/drivers/gpu/drm/i915/i915_gem_object.h > > index ad1bc0b1a0c2..8c02c8ec2a3b 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_object.h > > +++ b/drivers/gpu/drm/i915/i915_gem_object.h > > @@ -169,7 +169,7 @@ struct drm_i915_gem_object { > > struct reservation_object *resv; > > > > /** References from framebuffers, locks out tiling changes. */ > > - atomic_t framebuffer_references; > > + unsigned int framebuffer_references; > > > > /** Record of address bit 17 of each page at last unbind. */ > > unsigned long *bit_17; > > @@ -263,6 +263,16 @@ extern void drm_gem_object_unreference(struct > > drm_gem_object *); > > __deprecated > > extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *); > > > > +static inline void i915_gem_object_lock(struct drm_i915_gem_object *obj) > > +{ > > + reservation_object_lock(obj->resv, NULL); > > +} > > + > > +static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj) > > +{ > > + reservation_object_unlock(obj->resv); > > +} > > + > > static inline bool > > i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj) > > { > > @@ -303,6 +313,12 @@ i915_gem_object_clear_active_reference(struct > > drm_i915_gem_object *obj) > > > > void __i915_gem_object_release_unless_active(struct drm_i915_gem_object > > *obj); > > > > +static inline bool > > +i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj) > > +{ > > + return READ_ONCE(obj->framebuffer_references); > > +} > > + > > static inline unsigned int > > i915_gem_object_get_tiling(struct drm_i915_gem_object *obj) > > { > > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c > > b/drivers/gpu/drm/i915/i915_gem_shrinker.c > > index 7e3bb48e043e..630697001b38 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c > > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c > > @@ -210,7 +210,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv, > > > > if (!(flags & I915_SHRINK_ACTIVE) && > > (i915_gem_object_is_active(obj) || > > -atomic_read(&obj->framebuffer_references))) > > +i915_gem_object_is_framebuffer(obj))) > > continue; > > > > if (!can_release_pages(obj)) > > diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c > > b/drivers/gpu/drm/i915/i915_gem_tiling.c > > index c1d669e32f41..ad5e05f6b836 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_tiling.c > > +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c > > @@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object > > *obj, > > if ((tiling | stride) == obj->tiling_and_stride) > > return 0; > > > > - if (atomic_read(&obj->framebuffer_references)) > > + if (i915_gem_object_is_framebuffer(obj)) > > return -EBUSY; > > > > /* We need to rebind the object if its current allocation > > @@ -258,6 +258,12 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object > > *obj, > > if (err) > > return err; > > > > + i915_gem_object_lock(obj); > > + if (i915_gem_object_is_framebuffer(obj)) { > > + i915_gem_object_unlock(obj); > > + return -EBUSY; > > + } > > + > > /* If the memory has unknown (i.e. varying) swizzling, we pin the > > * pages to prevent them being swapped out and causing corruption > > * due to the change in swizzling. > > @@ -294,6 +300,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object > > *obj, > > } > > > > obj->tiling_and_stride = tiling | stride; > > + i915_gem_object_unlock(obj); > > > > /* Force the fence to be reacquired for GTT access */ > > i915_gem_release_mmap(obj); > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 77936ddd860a..62a1e628e399 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/i
[Intel-gfx] ✓ Fi.CI.BAT: success for Try to fix MST regression with DDI IO power domains (rev2)
== Series Details == Series: Try to fix MST regression with DDI IO power domains (rev2) URL : https://patchwork.freedesktop.org/series/20345/ State : success == Summary == Series 20345v2 Try to fix MST regression with DDI IO power domains https://patchwork.freedesktop.org/api/1.0/series/20345/revisions/2/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 77db4e1f75f54471bf2fbebf114b2ba9c2d3bca7 drm-tip: 2017y-03m-01d-14h-59m-18s UTC integration manifest b859863 drm/i915: Remove duplicate DDI enabling logic from MST path 881dbd6 drm/i915: Remove direct usages of intel_crtc->config from DDI code 16be05c drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable aa0aa86 drm/i915: Pass pipe_config to fdi_link_train() functions 1f09668 drm/i915: Pass pipe_config to pch_enable() functions ec11fe2 drm/i915: Pass intel_crtc to intel_lpt_pch_enable() ccc54cd drm/i915: Pass intel_crtc to fdi_link_train() hooks c371ce1 drm/i915: Enable DDI IO power domains in the DP MST path == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4016/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] lib: Define a common bit operations library
Bring the test/set/clear bit functions we have into a single place. v2: Add gtk-doc comment blocks (Daniel) Cc: Daniel Vetter Reviewed-by: Joonas Lahtinen (v1) Signed-off-by: Michel Thierry --- .../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + lib/Makefile.sources | 2 + lib/igt.h | 1 + lib/igt_bitops.c | 112 + lib/igt_bitops.h | 46 + lib/igt_primes.c | 25 + 6 files changed, 163 insertions(+), 24 deletions(-) create mode 100644 lib/igt_bitops.c create mode 100644 lib/igt_bitops.h diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml index 990bbb80..0fc51508 100644 --- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml +++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml @@ -25,6 +25,7 @@ + diff --git a/lib/Makefile.sources b/lib/Makefile.sources index 6348487f..801312c6 100644 --- a/lib/Makefile.sources +++ b/lib/Makefile.sources @@ -11,6 +11,8 @@ lib_source_list = \ igt_debugfs.h \ igt_aux.c \ igt_aux.h \ + igt_bitops.c\ + igt_bitops.h\ igt_edid_template.h \ igt_gt.c\ igt_gt.h\ diff --git a/lib/igt.h b/lib/igt.h index 4f54698d..7a8942aa 100644 --- a/lib/igt.h +++ b/lib/igt.h @@ -28,6 +28,7 @@ #include "i915_3d.h" #include "i915_pciids.h" #include "igt_aux.h" +#include "igt_bitops.h" #include "igt_core.h" #include "igt_debugfs.h" #include "igt_draw.h" diff --git a/lib/igt_bitops.c b/lib/igt_bitops.c new file mode 100644 index ..12d8b532 --- /dev/null +++ b/lib/igt_bitops.c @@ -0,0 +1,112 @@ +/* + * Copyright 2017 Intel Corporation + * All Rights Reserved. + * + * 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, sub license, 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. + */ + +#include + +/** + * SECTION:igt_bitops + * @short_description: Useful bit operations, based on kernel functions. + * @title: bitops + * @include: igt.h + * + * This library provides functions to set/clear/test bits in a given memory + * location. + */ + +/** + * set_bit: + * @nr: The bit to set + * @addr: The address to start counting from + * + * Set a bit in memory. + * + */ +void set_bit(unsigned long nr, unsigned long *addr) +{ + addr[nr / BITS_PER_LONG] |= __bit__(nr); +} + +/** + * clear_bit: + * @nr: The bit to clear + * @addr: The address to start counting from + * + * Clear a bit in memory. + * + */ +void clear_bit(unsigned long nr, unsigned long *addr) +{ + addr[nr / BITS_PER_LONG] &= ~__bit__(nr); +} + +/** + * test_bit: + * @nr: The bit to test + * @addr: The address to start counting from + * + * Determine whether a bit is set. + * + * Returns: + * True if bit was set, false otherwise. + */ +bool test_bit(unsigned long nr, const unsigned long *addr) +{ + return addr[nr / BITS_PER_LONG] & __bit__(nr); +} + +/** + * test_and_set_bit: + * @nr: The bit to set + * @addr: The address to start counting from + * + * Set a bit and return its old value. + * + * Returns: + * The bit previous value. + */ +bool test_and_set_bit(unsigned long nr, unsigned long *addr) +{ + bool ret = test_bit(nr, addr); + set_bit(nr, addr); + return ret; +} + +/** + * test_and_clear_bit: + * @nr: The bit to clear + * @addr: The address to start counting from + * + * Clear a bit and return its old value. + * + * Returns: + * The bit previous value. + */ +bool test_and_clear_bit(unsigned long nr, unsigned long *addr) +{ + bool ret = test_bit(nr, addr); + clear_bit(nr, addr); + return ret; +} + diff --git a/lib/igt_bitops.h b/lib/igt_bitops.h new file mode 100644 in
Re: [Intel-gfx] [PATCH] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
On Wed, Mar 01, 2017 at 04:07:02PM +0200, Ville Syrjälä wrote: > On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote: > > Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all > > 1.1. > > > > When a sink that supports deep color is connected to the output, the > > receiver will send EDIDs that advertise this capability, even if it > > isn't possible with HDMI versions earlier than 1.3. > > > > Currently the kernel is assuming that deep color is possible and the > > sink displays an error. > > > > This quirk will make sure that deep color isn't used with this > > particular receiver. > > > > Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") > > References: https://bugs.freedesktop.org/show_bug.cgi?id=99869 > > Signed-off-by: Tomeu Vizoso > > Cc: sta...@vger.kernel.org > Cc: Matt Horan > Tested-by: Matt Horan > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869 > Reviewed-by: Ville Syrjälä And pushed to drm-misc-fixes. Thanks for the patch/testing/bug report etc. > > > --- > > drivers/gpu/drm/drm_edid.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > index 24e7b282f16c..d994ccf94f88 100644 > > --- a/drivers/gpu/drm/drm_edid.c > > +++ b/drivers/gpu/drm/drm_edid.c > > @@ -148,6 +148,9 @@ static const struct edid_quirk { > > > > /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */ > > { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC }, > > + > > + /* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/ > > + { "ETR", 13896, EDID_QUIRK_FORCE_8BPC }, > > }; > > > > /* > > -- > > 2.9.3 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrjälä > Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] lib: Define a common bit operations library
On Wed, Mar 01, 2017 at 07:52:26AM -0800, Michel Thierry wrote: > Bring the test/set/clear bit functions we have into a single place. > > v2: Add gtk-doc comment blocks (Daniel) Hiss, boo! Will someone take gtk-doc and bury it? -flto to save the day? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"
This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c. I assumed it's ok, but really should have double-checked - CI caught tons of fail :( Cc: Jani Nikula Cc: Manasi Navare Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_dp.c | 27 --- drivers/gpu/drm/i915/intel_dp_link_training.c | 22 ++ drivers/gpu/drm/i915/intel_drv.h | 3 --- 3 files changed, 2 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index af07a830fa95..d1670b8afbf5 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5790,29 +5790,6 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp, return false; } -static void intel_dp_modeset_retry_work_fn(struct work_struct *work) -{ - struct intel_connector *intel_connector; - struct drm_connector *connector; - - intel_connector = container_of(work, typeof(*intel_connector), - modeset_retry_work); - connector = &intel_connector->base; - DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id, - connector->name); - - /* Grab the locks before changing connector property*/ - mutex_lock(&connector->dev->mode_config.mutex); - /* Set connector link status to BAD and send a Uevent to notify -* userspace to do a modeset. -*/ - drm_mode_connector_set_link_status_property(connector, - DRM_MODE_LINK_STATUS_BAD); - mutex_unlock(&connector->dev->mode_config.mutex); - /* Send Hotplug uevent so userspace can reprobe */ - drm_kms_helper_hotplug_event(connector->dev); -} - bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port, struct intel_connector *intel_connector) @@ -5825,10 +5802,6 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, enum port port = intel_dig_port->port; int type; - /* Initialize the work for modeset in case of link train failure */ - INIT_WORK(&intel_connector->modeset_retry_work, - intel_dp_modeset_retry_work_fn); - if (WARN(intel_dig_port->max_lanes < 1, "Not enough lanes (%d) for DP on port %c\n", intel_dig_port->max_lanes, port_name(port))) diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c index 955b239e7c2d..0048b520baf7 100644 --- a/drivers/gpu/drm/i915/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c @@ -313,24 +313,6 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp) void intel_dp_start_link_train(struct intel_dp *intel_dp) { - struct intel_connector *intel_connector = intel_dp->attached_connector; - - if (!intel_dp_link_training_clock_recovery(intel_dp)) - goto failure_handling; - if (!intel_dp_link_training_channel_equalization(intel_dp)) - goto failure_handling; - - DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d", - intel_dp->link_rate, intel_dp->lane_count); - return; - - failure_handling: - DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d", - intel_dp->link_rate, intel_dp->lane_count); - if (!intel_dp_get_link_train_fallback_values(intel_dp, -intel_dp->link_rate, -intel_dp->lane_count)) - /* Schedule a Hotplug Uevent to userspace to start modeset */ - schedule_work(&intel_connector->modeset_retry_work); - return; + intel_dp_link_training_clock_recovery(intel_dp); + intel_dp_link_training_channel_equalization(intel_dp); } diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 6c6abc932726..3b797909f631 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -316,9 +316,6 @@ struct intel_connector { void *port; /* store this opaque as its illegal to dereference it */ struct intel_dp *mst_port; - - /* Work struct to schedule a uevent on link train failure */ - struct work_struct modeset_retry_work; }; struct dpll { -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"
On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote: > This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c. > > I assumed it's ok, but really should have double-checked - CI caught > tons of fail :( For the record, the failure comes from the error message in intel_dp_get_link_train_fallback_values() as take the fallback path. As userspace is informed, we don't need an *ERROR* at that point. The really interesting question is why we are seeing link-training failures in CI at all, and whether igt should be checking and reporting link-status=BAD. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"
On Wed, 01 Mar 2017, Chris Wilson wrote: > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote: >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c. >> >> I assumed it's ok, but really should have double-checked - CI caught >> tons of fail :( Considering the velocity of drm-tip, I think any CI results for patches have a rather limited best before date. The patch should've been resent and gone through testing again before merging. > For the record, the failure comes from the error message in > intel_dp_get_link_train_fallback_values() as take the fallback path. As > userspace is informed, we don't need an *ERROR* at that point. > > The really interesting question is why we are seeing link-training > failures in CI at all, and whether igt should be checking and reporting > link-status=BAD. It's possible (I didn't check the logs) this pertains to the failure mode I've sometimes seen, where clock recovery fails, but as we continue with channel equalization anyway (without this patch), everything succeeds there. At worst we need to root cause and fix that issue first. :( BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"
On Wed, 01 Mar 2017, Jani Nikula wrote: > On Wed, 01 Mar 2017, Chris Wilson wrote: >> On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote: >>> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c. >>> >>> I assumed it's ok, but really should have double-checked - CI caught >>> tons of fail :( > > Considering the velocity of drm-tip, I think any CI results for patches > have a rather limited best before date. The patch should've been resent > and gone through testing again before merging. > >> For the record, the failure comes from the error message in >> intel_dp_get_link_train_fallback_values() as take the fallback path. As >> userspace is informed, we don't need an *ERROR* at that point. >> >> The really interesting question is why we are seeing link-training >> failures in CI at all, and whether igt should be checking and reporting >> link-status=BAD. > > It's possible (I didn't check the logs) this pertains to the failure > mode I've sometimes seen, where clock recovery fails, but as we continue > with channel equalization anyway (without this patch), everything > succeeds there. At worst we need to root cause and fix that issue > first. :( Also, possibly to "avoid noise" in CI, the relevant error messages in intel_dp_link_training_clock_recovery() have been brushed under the carpet by demoting them to DRM_DEBUG_KMS, so we don't really see this happening unless we actually eyeball the logs. > > BR, > Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions
Engine related definitions are located in different files and it is easy to break their cross dependency. Additionally use GEM_WARN_ON to catch invalid engine index. v2: compare against array size Signed-off-by: Michal Wajdeczko Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index a238304..c1f58b5 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -84,11 +84,16 @@ static const struct engine_info { static int intel_engine_setup(struct drm_i915_private *dev_priv, - enum intel_engine_id id) + unsigned int id) { const struct engine_info *info = &intel_engines[id]; struct intel_engine_cs *engine; + BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != +ARRAY_SIZE(dev_priv->engine)); + if (GEM_WARN_ON(id >= ARRAY_SIZE(intel_engines))) + return -EINVAL; + GEM_BUG_ON(dev_priv->engine[id]); engine = kzalloc(sizeof(*engine), GFP_KERNEL); if (!engine) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path
== Series Details == Series: series starting with [CI,1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path URL : https://patchwork.freedesktop.org/series/20464/ State : success == Summary == Series 20464v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/20464/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-bxt-t5700) fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:192 dwarn:36 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:216 dwarn:44 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 12f8718b2eefb0b48145ab3f797f6cab46138ddf drm-tip: 2017y-03m-01d-16h-02m-25s UTC integration manifest 8355f20 drm/i915: Prevent concurrent tiling/framebuffer modifications ced8b38 drm/i915: Fix all intel_framebuffer_init failures to take the error path == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4018/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support
On 17-03-01 12:51:17, Ville Syrjälä wrote: On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote: On 17-02-28 12:18:39, Jason Ekstrand wrote: >I've said it before but reading through Ben's patches again make me want to >be peskier about it. I would really like the UABI to treat the CCS as if >it's Y-tiled with a tile size of 128B x 32 rows. Why? Because this is >what all the docs say it is. From the display docs for "Color Control >Surface": > >"The Color Control Surface (CCS) contains the compression status of the >cache-line pairs. The >compression state of the cache-line pair is specified by 2 bits in the CCS. >Each CCS cache-line represents >an area on the main surface of 16 x16 sets of 128 byte Y-tiled >cache-line-pairs. CCS is always Y tiled." > >This contains 95% of the information needed to know the relation between >the CCS and the main surface. The other 5% (which is badly documented) is >that cache line pairs are horizontally adjacent. This gives a relationship >of one cache line in the CCS maps to 32x64 cache lines in the main surface. > >But it's not actually Y-tiled? Of course not. I've worked out the exact >tiling and it looks something like Y but isn't quite the same. However, >this isn't unique to CCS. Stencil (W-tiled), HiZ, and gen7-8 >single-sampled MCS also each have their own tiling (Haswell MCS is >especially exotic) but the docs call all of them Y-tiled and I think the >hardware internally treats them as Y-tiled with the cache lines shuffled >around a bit. > >Given the fact that they seem to like to change the MCS/CCS tiling around >on every hardware generation, I'm reluctant to base UABI on the fact that >the CCS appears to have 64x64 "pixels" per tile with each "pixel" >corresponding to 16x8 pixels in the color surface. That's not what we had >on any previous gen and may change on gen10 for no aparent reason. I'd >much rather base it on Y-tiling and a relationship between cache lines >which, even if they change the exact swizzle on gen10, will probably remain >the same. (For the gen7-8 analogue of CCS, they changed the tiling every >generation but the relationship of one MCS cache line maps to 32x128 color >cache lines remained the same). > >Ok, I've said my peice. If we have to divide by 2 in userspace, we won't >die, but I'd like to get the UABI right before we chissel it in stone. > >--Jason > > I vote we make the stride in units of tiles when we have the CCS modifier. That won't fly with the KMS API. I suppose I could make the tile 128 bytes wide by swapping the "1 byte == 16x8 pixels" notion with a "1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore, but I guess no one really cares. KMS API goes right out the window with modifiers. Isn't that really the whole point of modifiers? >> + /* fall through */ >> case I915_FORMAT_MOD_Yf_TILED: >> /* >> * Bspec seems to suggest that the Yf tile width would >> @@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const >> struct drm_framebuffer *fb, >> struct drm_i915_private *dev_priv = to_i915(fb->dev); >> >> /* AUX_DIST needs only 4K alignment */ >> - if (fb->format->format == DRM_FORMAT_NV12 && plane == 1) >> + if (plane == 1) >> return 4096; >> >> switch (fb->modifier) { >> @@ -2166,6 +2174,8 @@ static unsigned int intel_surf_alignment(const >> struct drm_framebuffer *fb, >> if (INTEL_GEN(dev_priv) >= 9) >> return 256 * 1024; >> return 0; >> + case I915_FORMAT_MOD_Y_TILED_CCS: >> + case I915_FORMAT_MOD_Yf_TILED_CCS: >> case I915_FORMAT_MOD_Y_TILED: >> case I915_FORMAT_MOD_Yf_TILED: >> return 1 * 1024 * 1024; >> @@ -2472,6 +2482,7 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t >> fb_modifier) >> case I915_FORMAT_MOD_X_TILED: >> return I915_TILING_X; >> case I915_FORMAT_MOD_Y_TILED: >> + case I915_FORMAT_MOD_Y_TILED_CCS: >> return I915_TILING_Y; >> default: >> return I915_TILING_NONE; >> @@ -2536,6 +2547,35 @@ intel_fill_fb_info(struct drm_i915_private >> *dev_priv, >> >> intel_fb_offset_to_xy(&x, &y, fb, i); >> >> + if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS || >> +fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) && i == >> 1) { >> + int main_x, main_y; >> + int ccs_x, ccs_y; >> + >> + /* >> +* Each byte of CCS corresponds to a 16x8 area of >> the main surface, and >> +* each CCS tile is 64x64 bytes. >> +*/ >> + ccs_x = (x * 16) % (64 * 16); >> + ccs_y = (y * 8) % (64 * 8); >> + main_x = intel_fb->normal[0].x % (64 * 16); >
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"
On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote: > On Wed, 01 Mar 2017, Chris Wilson wrote: > > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote: > >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c. > >> > >> I assumed it's ok, but really should have double-checked - CI caught > >> tons of fail :( > > Considering the velocity of drm-tip, I think any CI results for patches > have a rather limited best before date. The patch should've been resent > and gone through testing again before merging. > > > For the record, the failure comes from the error message in > > intel_dp_get_link_train_fallback_values() as take the fallback path. As > > userspace is informed, we don't need an *ERROR* at that point. > > > > The really interesting question is why we are seeing link-training > > failures in CI at all, and whether igt should be checking and reporting > > link-status=BAD. > > It's possible (I didn't check the logs) this pertains to the failure > mode I've sometimes seen, where clock recovery fails, but as we continue > with channel equalization anyway (without this patch), everything > succeeds there. At worst we need to root cause and fix that issue > first. :( The skl case seems pretty clear. We register DP for both port A and port E even though we should register it only for port E (I think). They both end up both using AUX A and so we think the same sink is connected to both, and then we try to enable port A which fail for obvious reasons. The culprit is init_vbt_defaults() which always sets .supports_dp=true for port A unless later overridden by the VBT. In this case the VBT has no port A, so we leave the .supports_dp flag set. So presumably we should just nuke this stuff from init_vbt_defaults(). IIRC this was discussed at some point between Imre and Paulo, but I can't remember what the conclusion was, or if in fact there was one. The ilk failure case is a lot less clear. It's one of those cases where the sink just keeps requesting the same vswing/preemph all the time. I've seen it sometime in the past, but I've never been able to figure out what has caused it to happen with any specific sink. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support
On Wed, Mar 01, 2017 at 09:50:56AM -0800, Ben Widawsky wrote: > On 17-03-01 12:51:17, Ville Syrjälä wrote: > >On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote: > >> On 17-02-28 12:18:39, Jason Ekstrand wrote: > > > >> >I've said it before but reading through Ben's patches again make me want > >> >to > >> >be peskier about it. I would really like the UABI to treat the CCS as if > >> >it's Y-tiled with a tile size of 128B x 32 rows. Why? Because this is > >> >what all the docs say it is. From the display docs for "Color Control > >> >Surface": > >> > > >> >"The Color Control Surface (CCS) contains the compression status of the > >> >cache-line pairs. The > >> >compression state of the cache-line pair is specified by 2 bits in the > >> >CCS. > >> >Each CCS cache-line represents > >> >an area on the main surface of 16 x16 sets of 128 byte Y-tiled > >> >cache-line-pairs. CCS is always Y tiled." > >> > > >> >This contains 95% of the information needed to know the relation between > >> >the CCS and the main surface. The other 5% (which is badly documented) is > >> >that cache line pairs are horizontally adjacent. This gives a > >> >relationship > >> >of one cache line in the CCS maps to 32x64 cache lines in the main > >> >surface. > >> > > >> >But it's not actually Y-tiled? Of course not. I've worked out the exact > >> >tiling and it looks something like Y but isn't quite the same. However, > >> >this isn't unique to CCS. Stencil (W-tiled), HiZ, and gen7-8 > >> >single-sampled MCS also each have their own tiling (Haswell MCS is > >> >especially exotic) but the docs call all of them Y-tiled and I think the > >> >hardware internally treats them as Y-tiled with the cache lines shuffled > >> >around a bit. > >> > > >> >Given the fact that they seem to like to change the MCS/CCS tiling around > >> >on every hardware generation, I'm reluctant to base UABI on the fact that > >> >the CCS appears to have 64x64 "pixels" per tile with each "pixel" > >> >corresponding to 16x8 pixels in the color surface. That's not what we had > >> >on any previous gen and may change on gen10 for no aparent reason. I'd > >> >much rather base it on Y-tiling and a relationship between cache lines > >> >which, even if they change the exact swizzle on gen10, will probably > >> >remain > >> >the same. (For the gen7-8 analogue of CCS, they changed the tiling every > >> >generation but the relationship of one MCS cache line maps to 32x128 color > >> >cache lines remained the same). > >> > > >> >Ok, I've said my peice. If we have to divide by 2 in userspace, we won't > >> >die, but I'd like to get the UABI right before we chissel it in stone. > >> > > >> >--Jason > >> > > >> > > >> > >> I vote we make the stride in units of tiles when we have the CCS modifier. > > > >That won't fly with the KMS API. I suppose I could make the tile 128 bytes > >wide by swapping the "1 byte == 16x8 pixels" notion with a > >"1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore, > >but I guess no one really cares. > > > > KMS API goes right out the window with modifiers. Isn't that really the whole > point of modifiers? Not in my opinion. It's just a mild extension. The basics still apply perfectly fine. And I really don't want to add special exceptions for CCS since that'll just mean more code and more bugs. Right now the same code that works for your typical planar formats works for CCS as well. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"
On Wed, 01 Mar 2017, Ville Syrjälä wrote: > On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote: >> On Wed, 01 Mar 2017, Chris Wilson wrote: >> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote: >> >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c. >> >> >> >> I assumed it's ok, but really should have double-checked - CI caught >> >> tons of fail :( >> >> Considering the velocity of drm-tip, I think any CI results for patches >> have a rather limited best before date. The patch should've been resent >> and gone through testing again before merging. >> >> > For the record, the failure comes from the error message in >> > intel_dp_get_link_train_fallback_values() as take the fallback path. As >> > userspace is informed, we don't need an *ERROR* at that point. >> > >> > The really interesting question is why we are seeing link-training >> > failures in CI at all, and whether igt should be checking and reporting >> > link-status=BAD. >> >> It's possible (I didn't check the logs) this pertains to the failure >> mode I've sometimes seen, where clock recovery fails, but as we continue >> with channel equalization anyway (without this patch), everything >> succeeds there. At worst we need to root cause and fix that issue >> first. :( > > The skl case seems pretty clear. We register DP for both port A and port > E even though we should register it only for port E (I think). They > both end up both using AUX A and so we think the same sink is connected > to both, and then we try to enable port A which fail for obvious reasons. > > The culprit is init_vbt_defaults() which always sets .supports_dp=true > for port A unless later overridden by the VBT. In this case the VBT has > no port A, so we leave the .supports_dp flag set. So presumably we > should just nuke this stuff from init_vbt_defaults(). > > IIRC this was discussed at some point between Imre and Paulo, but I > can't remember what the conclusion was, or if in fact there was one. I think one idea was simply diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index e144f033f4b5..0261c841756f 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1377,10 +1377,6 @@ init_vbt_defaults(struct drm_i915_private *dev_priv) &dev_priv->vbt.ddi_port_info[port]; info->hdmi_level_shift = HDMI_LEVEL_SHIFT_UNKNOWN; - - info->supports_dvi = (port != PORT_A && port != PORT_E); - info->supports_hdmi = info->supports_dvi; - info->supports_dp = (port != PORT_E); } } --- but apparently it's problematic for machines without VBT, specifically some Chromebooks [citation needed]. Jani. > > The ilk failure case is a lot less clear. It's one of those cases > where the sink just keeps requesting the same vswing/preemph all > the time. I've seen it sometime in the past, but I've never been > able to figure out what has caused it to happen with any specific > sink. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"
On Wed, Mar 01, 2017 at 08:18:18PM +0200, Jani Nikula wrote: > On Wed, 01 Mar 2017, Ville Syrjälä wrote: > > On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote: > >> On Wed, 01 Mar 2017, Chris Wilson wrote: > >> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote: > >> >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c. > >> >> > >> >> I assumed it's ok, but really should have double-checked - CI caught > >> >> tons of fail :( > >> > >> Considering the velocity of drm-tip, I think any CI results for patches > >> have a rather limited best before date. The patch should've been resent > >> and gone through testing again before merging. > >> > >> > For the record, the failure comes from the error message in > >> > intel_dp_get_link_train_fallback_values() as take the fallback path. As > >> > userspace is informed, we don't need an *ERROR* at that point. > >> > > >> > The really interesting question is why we are seeing link-training > >> > failures in CI at all, and whether igt should be checking and reporting > >> > link-status=BAD. > >> > >> It's possible (I didn't check the logs) this pertains to the failure > >> mode I've sometimes seen, where clock recovery fails, but as we continue > >> with channel equalization anyway (without this patch), everything > >> succeeds there. At worst we need to root cause and fix that issue > >> first. :( > > > > The skl case seems pretty clear. We register DP for both port A and port > > E even though we should register it only for port E (I think). They > > both end up both using AUX A and so we think the same sink is connected > > to both, and then we try to enable port A which fail for obvious reasons. > > > > The culprit is init_vbt_defaults() which always sets .supports_dp=true > > for port A unless later overridden by the VBT. In this case the VBT has > > no port A, so we leave the .supports_dp flag set. So presumably we > > should just nuke this stuff from init_vbt_defaults(). > > > > IIRC this was discussed at some point between Imre and Paulo, but I > > can't remember what the conclusion was, or if in fact there was one. > > I think one idea was simply > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > b/drivers/gpu/drm/i915/intel_bios.c > index e144f033f4b5..0261c841756f 100644 > --- a/drivers/gpu/drm/i915/intel_bios.c > +++ b/drivers/gpu/drm/i915/intel_bios.c > @@ -1377,10 +1377,6 @@ init_vbt_defaults(struct drm_i915_private *dev_priv) > &dev_priv->vbt.ddi_port_info[port]; > > info->hdmi_level_shift = HDMI_LEVEL_SHIFT_UNKNOWN; > - > - info->supports_dvi = (port != PORT_A && port != PORT_E); > - info->supports_hdmi = info->supports_dvi; > - info->supports_dp = (port != PORT_E); > } > } > > --- > > but apparently it's problematic for machines without VBT, specifically > some Chromebooks [citation needed]. I guess the other option would to be split this out and do it only when there's no VBT. Or we could make the VBT parsing code explicitly clear anything not present in the VBT. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Make intel_guc_send a function pointer
On Tue, Feb 07, 2017 at 01:20:35AM -0800, Oscar Mateo wrote: > From: Michal Wajdeczko > > Prepare for an alternate GuC communication interface. > > v2: Make a few functions static and name them correctly while we are at it > (Oscar) > v3: Leave an intel_guc_send_mmio interface for users that require old-style > communication > > Signed-off-by: Michel Thierry > Signed-off-by: Michal Wajdeczko > Signed-off-by: Oscar Mateo > --- > drivers/gpu/drm/i915/intel_uc.c | 25 +++-- > drivers/gpu/drm/i915/intel_uc.h | 10 +- > 2 files changed, 24 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c > index c46bc85..2fa70a9 100644 > --- a/drivers/gpu/drm/i915/intel_uc.c > +++ b/drivers/gpu/drm/i915/intel_uc.c > @@ -98,6 +96,14 @@ int intel_guc_send(struct intel_guc *guc, const u32 > *action, u32 len) > return ret; > } > > +void intel_uc_init_early(struct drm_i915_private *dev_priv) > +{ > + struct intel_guc *guc = &dev_priv->guc; > + > + mutex_init(&guc->send_mutex); > + guc->send = intel_guc_send_mmio; > +} > + As intel_guc_send_mmio() is again public, there is no need to move intel_uc_init_early() down to this place, it can stay at the top of the file. -Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/glk: Fix DSI enable I/O sequence
One of the if statement covers the next line in enable I/O sequence. This patch correct the same by adding error message. Signed-off-by: Madhav Chauhan --- drivers/gpu/drm/i915/intel_dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 8e97bae3..c92004b 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -425,6 +425,7 @@ static void glk_dsi_device_ready(struct intel_encoder *encoder) if (intel_wait_for_register(dev_priv, MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, GLK_ULPS_NOT_ACTIVE, 20)) + DRM_ERROR("ULPS is still active\n"); /* Exit ULPS */ val = I915_READ(MIPI_DEVICE_READY(port)); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable sequence
> -Original Message- > From: Nikula, Jani > Sent: Wednesday, March 1, 2017 7:44 PM > To: Chauhan, Madhav ; intel- > g...@lists.freedesktop.org > Cc: Conselvan De Oliveira, Ander ; > Shankar, Uma ; Mukherjee, Indranil > ; Saarinen, Jani ; > Kamath, Sunil ; Deepak M > ; Chauhan, Madhav > Subject: Re: [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable > sequence > > On Wed, 01 Mar 2017, Madhav Chauhan > wrote: > > From: Deepak M > > > > v2: Addressed Jani's Review comments(renamed bit field macros) > > v3: Jani's Review comment for aligning code to platforms and added > > wrapper functions. > > v4: Corrected enable/disable seuqence as per BSPEC > > v5: Corrected waiting twice for same bit (Review comments: Jani) > > v6: Rebased to Han's patches(dsi restructuring code) > > > > Signed-off-by: Deepak M > > Signed-off-by: Madhav Chauhan > > --- > > drivers/gpu/drm/i915/intel_dsi.c | 206 > > --- > > 1 file changed, 195 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c > > b/drivers/gpu/drm/i915/intel_dsi.c > > index 20ed799..8e97bae3 100644 > > --- a/drivers/gpu/drm/i915/intel_dsi.c > > +++ b/drivers/gpu/drm/i915/intel_dsi.c > > @@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct > intel_encoder *encoder, > > return true; > > } > > > > +static void glk_dsi_device_ready(struct intel_encoder *encoder) { > > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > > + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base); > > + enum port port; > > + u32 tmp, val; > > + > > + /* Set the MIPI mode > > +* If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting. > > +* Power ON MIPI IO first and then write into IO reset and LP wake > bits > > +*/ > > + for_each_dsi_port(port, intel_dsi->ports) { > > + tmp = I915_READ(MIPI_CTRL(port)); > > + I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE); > > + } > > + > > + /* Put the IO into reset */ > > + tmp = I915_READ(MIPI_CTRL(PORT_A)); > > + tmp &= ~GLK_MIPIIO_RESET_RELEASED; > > + I915_WRITE(MIPI_CTRL(PORT_A), tmp); > > + > > + /* Program LP Wake */ > > + for_each_dsi_port(port, intel_dsi->ports) { > > + tmp = I915_READ(MIPI_CTRL(port)); > > + tmp |= GLK_LP_WAKE; > > + I915_WRITE(MIPI_CTRL(port), tmp); > > + } > > + > > + /* Wait for Pwr ACK */ > > + for_each_dsi_port(port, intel_dsi->ports) { > > + if (intel_wait_for_register(dev_priv, > > + MIPI_CTRL(port), > GLK_MIPIIO_PORT_POWERED, > > + GLK_MIPIIO_PORT_POWERED, 20)) > > + DRM_ERROR("MIPIO port is powergated\n"); > > + } > > + > > + /* Wait for MIPI PHY status bit to set */ > > + for_each_dsi_port(port, intel_dsi->ports) { > > + if (intel_wait_for_register(dev_priv, > > + MIPI_CTRL(port), > GLK_PHY_STATUS_PORT_READY, > > + GLK_PHY_STATUS_PORT_READY, 20)) > > + DRM_ERROR("PHY is not ON\n"); > > + } > > + > > + /* Get IO out of reset */ > > + tmp = I915_READ(MIPI_CTRL(PORT_A)); > > + I915_WRITE(MIPI_CTRL(PORT_A), tmp | > GLK_MIPIIO_RESET_RELEASED); > > + > > + /* Get IO out of Low power state*/ > > + for_each_dsi_port(port, intel_dsi->ports) { > > + if (!(I915_READ(MIPI_DEVICE_READY(port)) & > DEVICE_READY)) { > > + val = I915_READ(MIPI_DEVICE_READY(port)); > > + val &= ~ULPS_STATE_MASK; > > + val |= DEVICE_READY; > > + I915_WRITE(MIPI_DEVICE_READY(port), val); > > + usleep_range(10, 15); > > + } > > + > > + /* Enter ULPS */ > > + val = I915_READ(MIPI_DEVICE_READY(port)); > > + val &= ~ULPS_STATE_MASK; > > + val |= (ULPS_STATE_ENTER | DEVICE_READY); > > + I915_WRITE(MIPI_DEVICE_READY(port), val); > > + > > + /* Wait for ULPS Not active */ > > + if (intel_wait_for_register(dev_priv, > > + MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, > > + GLK_ULPS_NOT_ACTIVE, 20)) > > > Auch, I missed this. The if statement covers the next line, and my compiler > didn't complain. I already pushed this, so please send a follow-up fix on top. Done. Thanks for capturing this. > > BR, > Jani. > > > + > > + /* Exit ULPS */ > > + val = I915_READ(MIPI_DEVICE_READY(port)); > > + val &= ~ULPS_STATE_MASK; > > + val |= (ULPS_STATE_EXIT | DEVICE_READY); > > + I915_WRITE(MIPI_DEVICE_READY(port), val); > > + > > + /* Enter Normal Mode */ > > + val = I915_READ(MIPI_DEVICE_READY(port)); > > + val &= ~ULPS_STATE_MASK; > > + val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY); > > + I915_WRITE(MIPI_DEVICE_READY(port), val);
[Intel-gfx] [PATCH] drm/i915: Fix use after free in lpe_audio_platdev_destroy()
[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr 8801f7788358 [31908.547297] Read of size 8 by task drv_selftest/3781 [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: GBU W 4.10.0+ #451 [31908.547553] Hardware name: /, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [31908.547682] Call Trace: [31908.547772] dump_stack+0x68/0x9f [31908.547857] kasan_object_err+0x1c/0x70 [31908.547947] kasan_report_error+0x1f1/0x4f0 [31908.548038] ? kfree+0xaa/0x170 [31908.548121] kasan_report+0x34/0x40 [31908.548211] ? klist_children_get+0x20/0x30 [31908.548472] ? intel_lpe_audio_teardown+0x78/0xb0 [i915] [31908.548567] __asan_load8+0x5e/0x70 [31908.548824] intel_lpe_audio_teardown+0x78/0xb0 [i915] [31908.549080] intel_audio_deinit+0x28/0x80 [i915] [31908.549315] i915_driver_unload+0xe4/0x360 [i915] [31908.549551] ? i915_driver_load+0x1d70/0x1d70 [i915] [31908.549651] ? trace_hardirqs_on+0xd/0x10 [31908.549885] i915_pci_remove+0x23/0x30 [i915] [31908.549978] pci_device_remove+0x5c/0x100 [31908.550069] device_release_driver_internal+0x1db/0x2e0 [31908.550165] driver_detach+0x68/0xc0 [31908.550256] bus_remove_driver+0x8b/0x150 [31908.550346] driver_unregister+0x3e/0x60 [31908.550439] pci_unregister_driver+0x1d/0x110 [31908.550531] ? find_module_all+0x7a/0xa0 [31908.550791] i915_exit+0x1a/0x87 [i915] [31908.550881] SyS_delete_module+0x264/0x2c0 [31908.550971] ? free_module+0x430/0x430 [31908.551064] ? trace_hardirqs_off_caller+0x16/0x110 [31908.551159] ? trace_hardirqs_on_caller+0x16/0x280 [31908.551256] ? trace_hardirqs_on_thunk+0x1a/0x1c [31908.551350] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.551440] RIP: 0033:0x7f1d67312ec7 [31908.551520] RSP: 002b:7ffebe34e888 EFLAGS: 0206 ORIG_RAX: 00b0 [31908.551650] RAX: ffda RBX: 811123f6 RCX: 7f1d67312ec7 [31908.551743] RDX: RSI: 0800 RDI: 560d0af476b8 [31908.551837] RBP: 880233d87f98 R08: R09: 7ffebe34e8b8 [31908.551930] R10: 7f1d68adf8c0 R11: 0206 R12: [31908.552023] R13: 560d0af46440 R14: 0034 R15: 7ffebe34d860 [31908.552121] ? trace_hardirqs_off_caller+0x16/0x110 [31908.552217] Object at 8801f7788000, in cache kmalloc-2048 size: 2048 [31908.552306] Allocated: [31908.552377] PID = 3781 [31908.552456] save_stack_trace+0x16/0x20 [31908.552539] kasan_kmalloc+0xee/0x190 [31908.552627] __kmalloc+0xdb/0x1b0 [31908.552713] platform_device_alloc+0x27/0x90 [31908.552804] platform_device_register_full+0x36/0x220 [31908.553066] intel_lpe_audio_init+0x41e/0x570 [i915] [31908.553320] intel_audio_init+0xd/0x40 [i915] [31908.553552] i915_driver_load+0x13f5/0x1d70 [i915] [31908.553788] i915_pci_probe+0x65/0xe0 [i915] [31908.553881] pci_device_probe+0xda/0x140 [31908.553969] driver_probe_device+0x400/0x660 [31908.554058] __driver_attach+0x11c/0x120 [31908.554147] bus_for_each_dev+0xe6/0x150 [31908.554237] driver_attach+0x26/0x30 [31908.554325] bus_add_driver+0x26b/0x3b0 [31908.554412] driver_register+0xce/0x190 [31908.554502] __pci_register_driver+0xaf/0xc0 [31908.554589] 0xa0550063 [31908.554675] do_one_initcall+0x8b/0x1e0 [31908.554764] do_init_module+0x102/0x325 [31908.554852] load_module+0x3aad/0x45e0 [31908.554944] SyS_finit_module+0x169/0x1a0 [31908.555033] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.555119] Freed: [31908.555188] PID = 3781 [31908.555266] save_stack_trace+0x16/0x20 [31908.555349] kasan_slab_free+0xb0/0x180 [31908.555436] kfree+0xaa/0x170 [31908.20] platform_device_release+0x76/0x80 [31908.555610] device_release+0x45/0xe0 [31908.555698] kobject_put+0x11f/0x260 [31908.555785] put_device+0x12/0x20 [31908.555871] platform_device_unregister+0x1b/0x20 [31908.556135] intel_lpe_audio_teardown+0x5c/0xb0 [i915] [31908.556390] intel_audio_deinit+0x28/0x80 [i915] [31908.556622] i915_driver_unload+0xe4/0x360 [i915] [31908.556858] i915_pci_remove+0x23/0x30 [i915] [31908.556948] pci_device_remove+0x5c/0x100 [31908.557037] device_release_driver_internal+0x1db/0x2e0 [31908.557129] driver_detach+0x68/0xc0 [31908.557217] bus_remove_driver+0x8b/0x150 [31908.557304] driver_unregister+0x3e/0x60 [31908.557394] pci_unregister_driver+0x1d/0x110 [31908.557653] i915_exit+0x1a/0x87 [i915] [31908.557741] SyS_delete_module+0x264/0x2c0 [31908.557834] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.557919] Memory state around the buggy address: [31908.558005] 8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558127] 8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558255] >8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558374] ^ [31908.558467] 8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558595] 8801f7788400:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use BUILD_BUG_ON to detected missing engine definitions (rev2)
== Series Details == Series: drm/i915: Use BUILD_BUG_ON to detected missing engine definitions (rev2) URL : https://patchwork.freedesktop.org/series/20394/ State : success == Summary == Series 20394v2 drm/i915: Use BUILD_BUG_ON to detected missing engine definitions https://patchwork.freedesktop.org/api/1.0/series/20394/revisions/2/mbox/ Test gem_exec_reloc: Subgroup basic-gtt-cpu-active: incomplete -> PASS (fi-byt-j1900) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:192 dwarn:36 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:216 dwarn:44 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 07e9f4ad3a2ca599975099c1fe49189a24be1884 drm-tip: 2017y-03m-01d-18h-00m-03s UTC integration manifest 05b8c8e drm/i915: Use BUILD_BUG_ON to detected missing engine definitions == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4020/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move w/a LRI debug message from context-init to driver load
On 01/03/2017 12:11, Chris Wilson wrote: The spam of every context initialisation saying the same thing is annoying me! Move the information to the setup of the engine. Yes I've noticed this ugly side effect of code consolidation. :) Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 38 +- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index c4d4698f98e7..c58339b22f6a 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1009,30 +1009,32 @@ static int glk_init_workarounds(struct intel_engine_cs *engine) int init_workarounds_ring(struct intel_engine_cs *engine) { struct drm_i915_private *dev_priv = engine->i915; + int err; WARN_ON(engine->id != RCS); dev_priv->workarounds.count = 0; - dev_priv->workarounds.hw_whitelist_count[RCS] = 0; + dev_priv->workarounds.hw_whitelist_count[engine->id] = 0; if (IS_BROADWELL(dev_priv)) - return bdw_init_workarounds(engine); - - if (IS_CHERRYVIEW(dev_priv)) - return chv_init_workarounds(engine); - - if (IS_SKYLAKE(dev_priv)) - return skl_init_workarounds(engine); - - if (IS_BROXTON(dev_priv)) - return bxt_init_workarounds(engine); - - if (IS_KABYLAKE(dev_priv)) - return kbl_init_workarounds(engine); - - if (IS_GEMINILAKE(dev_priv)) - return glk_init_workarounds(engine); + err = bdw_init_workarounds(engine); + else if (IS_CHERRYVIEW(dev_priv)) + err = chv_init_workarounds(engine); + else if (IS_SKYLAKE(dev_priv)) + err = skl_init_workarounds(engine); + else if (IS_BROXTON(dev_priv)) + err = bxt_init_workarounds(engine); + else if (IS_KABYLAKE(dev_priv)) + err = kbl_init_workarounds(engine); + else if (IS_GEMINILAKE(dev_priv)) + err = glk_init_workarounds(engine); + else + err = 0; + if (err) + return err; + DRM_DEBUG_DRIVER("%s: Number of context specific w/a: %d\n", +engine->name, dev_priv->workarounds.count); return 0; } @@ -1066,8 +1068,6 @@ int intel_ring_workarounds_emit(struct drm_i915_gem_request *req) if (ret) return ret; - DRM_DEBUG_DRIVER("Number of Workarounds emitted: %d\n", w->count); - return 0; } Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions
On 01/03/2017 17:39, Michal Wajdeczko wrote: Engine related definitions are located in different files and it is easy to break their cross dependency. Additionally use GEM_WARN_ON to catch invalid engine index. v2: compare against array size Signed-off-by: Michal Wajdeczko Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index a238304..c1f58b5 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -84,11 +84,16 @@ static const struct engine_info { static int intel_engine_setup(struct drm_i915_private *dev_priv, - enum intel_engine_id id) + unsigned int id) { const struct engine_info *info = &intel_engines[id]; struct intel_engine_cs *engine; + BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != +ARRAY_SIZE(dev_priv->engine)); + if (GEM_WARN_ON(id >= ARRAY_SIZE(intel_engines))) + return -EINVAL; + GEM_BUG_ON(dev_priv->engine[id]); engine = kzalloc(sizeof(*engine), GFP_KERNEL); if (!engine) I would add asserts for id >= ARRAY_SIZE(intel_engines) and id >= ARRAY_SIZE(dev_priv->engine). That provides guarantees for no out of bounds access within this function and should be enough for this function. The rest sounds just like trouble for now. Also I am not sure about negative enum, do we elsewhere check for that class of errors? Is it worth it? Maybe then just cast to unsigned in the above mentioned asserts? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't use enums for hardware engine id
On Tue, Feb 28, 2017 at 09:53:37PM +, Chris Wilson wrote: > On Tue, Feb 28, 2017 at 07:07:38PM +0100, Michal Wajdeczko wrote: > > On Tue, Feb 28, 2017 at 04:52:34PM +, Chris Wilson wrote: > > > On Tue, Feb 28, 2017 at 04:43:02PM +, Chris Wilson wrote: > > > > On Tue, Feb 28, 2017 at 02:12:09PM +, Michal Wajdeczko wrote: > > > > > +/* Hardware Engine ID definitions */ > > > > > +#define RCS_HW 0 > > > > > +#define VCS_HW 1 > > > > > +#define BCS_HW 2 > > > > > +#define VECS_HW 3 > > > > > +#define VCS2_HW 4 > > > > > > > > So don't put them in the header if they may have inconsistent meanings. > > > > > > Or if you do want to keep them in a header, either i915_reg.h or > > > intel_engine_reg.h as somewhere out of the way, and clear that they are > > > not meant for the rest of the bookkeeping in intel_ringbuffer.h. > > > > I can't find nice spot for these engine IDs in the i915_reg.h > > > > Can I just move these definitions to the top of this header? > > I would rather we spend a little effort on splitting our driver API from > hw innards. Sounds reasonable. As it looks that engine->hw_id is mostly used in code related to semaphores, I'll move these engine definitions to i915_reg.h near MI_SEMAPHORE_SIGNAL instruction. In case of guc_id, it looks that these engine ids are already defined in intel_guc_fwif.h (see GUC_RENDER_ENGINE..GUC_VIDEO_ENGINE2) For now they are the same, but who knows what the future brings ;) -Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/glk: Fix DSI enable I/O sequence
== Series Details == Series: drm/i915/glk: Fix DSI enable I/O sequence URL : https://patchwork.freedesktop.org/series/20474/ State : warning == Summary == Series 20474v1 drm/i915/glk: Fix DSI enable I/O sequence https://patchwork.freedesktop.org/api/1.0/series/20474/revisions/1/mbox/ Test gem_exec_reloc: Subgroup basic-gtt-cpu-active: incomplete -> PASS (fi-byt-j1900) Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-bxt-t5700) Test gem_flink_basic: Subgroup bad-flink: pass -> DMESG-WARN (fi-skl-6700k) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (fi-bxt-j4205) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:278 pass:258 dwarn:1 dfail:0 fail:0 skip:19 fi-bxt-t5700 total:278 pass:257 dwarn:1 dfail:0 fail:0 skip:20 fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 fi-ilk-650 total:278 pass:192 dwarn:36 dfail:0 fail:0 skip:50 fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 fi-kbl-7500u total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 fi-skl-6700k total:278 pass:215 dwarn:45 dfail:0 fail:0 skip:18 fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 07e9f4ad3a2ca599975099c1fe49189a24be1884 drm-tip: 2017y-03m-01d-18h-00m-03s UTC integration manifest 80faace drm/i915/glk: Fix DSI enable I/O sequence == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4021/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] i915/HuC: Add an extra check for platforms that do not have HUC
Return silently without producing much noise on platforms that have a HuC but the firmware is absent. Cc: Ander Conselvan De Oliveira Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c index c28543d..e660109 100644 --- a/drivers/gpu/drm/i915/intel_huc.c +++ b/drivers/gpu/drm/i915/intel_huc.c @@ -181,12 +181,14 @@ void intel_huc_init(struct drm_i915_private *dev_priv) } huc_fw->path = fw_path; + + if (huc_fw->path == NULL) + return; + huc_fw->fetch_status = INTEL_UC_FIRMWARE_PENDING; DRM_DEBUG_DRIVER("HuC firmware pending, path %s\n", fw_path); - WARN(huc_fw->path == NULL, "HuC present but no fw path\n"); - intel_uc_fw_fetch(dev_priv, huc_fw); } -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions
On Wed, Mar 01, 2017 at 07:29:15PM +, Tvrtko Ursulin wrote: > > On 01/03/2017 17:39, Michal Wajdeczko wrote: > > Engine related definitions are located in different files > > and it is easy to break their cross dependency. > > > > Additionally use GEM_WARN_ON to catch invalid engine index. > > > > v2: compare against array size > > > > Signed-off-by: Michal Wajdeczko > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > > Cc: Chris Wilson > > Cc: Tvrtko Ursulin > > --- > > drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > > b/drivers/gpu/drm/i915/intel_engine_cs.c > > index a238304..c1f58b5 100644 > > --- a/drivers/gpu/drm/i915/intel_engine_cs.c > > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c > > @@ -84,11 +84,16 @@ static const struct engine_info { > > > > static int > > intel_engine_setup(struct drm_i915_private *dev_priv, > > - enum intel_engine_id id) > > + unsigned int id) > > { > > const struct engine_info *info = &intel_engines[id]; > > struct intel_engine_cs *engine; > > > > + BUILD_BUG_ON(ARRAY_SIZE(intel_engines) != > > +ARRAY_SIZE(dev_priv->engine)); > > + if (GEM_WARN_ON(id >= ARRAY_SIZE(intel_engines))) > > + return -EINVAL; > > + > > GEM_BUG_ON(dev_priv->engine[id]); > > engine = kzalloc(sizeof(*engine), GFP_KERNEL); > > if (!engine) > > > > I would add asserts for id >= ARRAY_SIZE(intel_engines) and id >= > ARRAY_SIZE(dev_priv->engine). That provides guarantees for no out of bounds > access within this function and should be enough for this function. True, but then we will loose early (ie. at build time) detection that our engine array definitions are not in sync (which was primary reason for this patch). > > The rest sounds just like trouble for now. I would not call extra check as a trouble. But if you prefer freedom over robustness, then I will step back. > > Also I am not sure about negative enum, do we elsewhere check for that class > of errors? Is it worth it? Maybe then just cast to unsigned in the above > mentioned asserts? Note that the caller function is not using enum at all, this id/index is defined there as plain "unsigned". Then it is promoted in this function only, where we start to use it as index again (except id assignment). IMHO enums are not the best choice for indexing arrays, and if you really want to do so, you should add some guards to prevent unexpected use. Using cast in these two asserts will do the trick. Let's try this as compromise ;) -Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx