Re: [Intel-gfx] [PATCH RESEND v11 0/3] Enhancement to intel_dp_aux_backlight driver
On Tue, Jun 20, 2017 at 05:46:03PM +, Pandiyan, Dhinakaran wrote: > > > > On Tue, 2017-06-20 at 11:03 +0200, Daniel Vetter wrote: > > On Mon, Jun 05, 2017 at 02:56:04PM -0700, Puthikorn Voravootivat wrote: > > > This patch set contain 3 patches which are already reviewed by DK. > > > Another 6 patches in previous version was already merged in v7 and v9. > > > - First patch sets the PWM freqency to match data in panel vbt. > > > - Next patch adds heuristic to determine whether we should use AUX > > > or PWM pin to adjust panel backlight brightness. > > > - Last patch adds support for dynamic brightness. > > > > > > Change log: > > > v11: > > > - Reorder patches in v10 to make the last patch come first > > > - Fix nits > > > > > > v10: > > > - Add heuristic in patch #1 > > > - Add _unsafe mod option in patch #1, #2 > > > - handle frequency set error in patch #3 > > > > > > v9: > > > - Fix nits in v8 > > > > > > v8: > > > - Drop 4 patches that was already merged > > > - Move DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check to patch #2 to avoid > > > behavior change if only apply patch #1 > > > - Add TODO to warn about enable backlight twice in patch #2 > > > - Use DIV_ROUND_CLOSEST instead of just "/" in patch #5 > > > - Fix bug calculate pn in patch #5 > > > - Clarify commit message / code comment in patch #5 > > > > > > v7: > > > - Add check in intel_dp_pwm_pin_display_control_capable in patch #4 > > > - Add option in patch #6 to enable DPCD or not > > > - Change definition in patch #8 and implementation in #9 to use Khz > > > - Fix compiler warning from build bot in patch #9 > > > > > > v6: > > > - Address review from Dhinakaran > > > - Make PWM frequency to have highest value of Pn that make the > > > frequency still within 25% of desired frequency. > > > > > > v5: > > > - Split first patch in v4 to 3 patches > > > - Bump priority for "Correctly enable backlight brightness adjustment via > > > DPCD" > > > - Make logic clearer for the case that both PWM pin and AUX are supported > > > - Add more log when write to register fail > > > - Add log when enable DBC > > > > > > v4: > > > - Rebase / minor typo fix. > > > > > > v3: > > > - Add new implementation of PWM frequency patch > > > > > > v2: > > > - Drop PWM frequency patch > > > - Address suggestion from Jani Nikula > > > > > > Puthikorn Voravootivat (3): > > > drm/i915: Set PWM divider to match desired frequency in vbt > > > drm/i915: Add heuristic to determine better way to adjust brightness > > > drm/i915: Add option to support dynamic backlight via DPCD > > > > Random unrelated observation, but shouldn't we have the dp aux backlight > > driver as a generic helper in the drm core dp helper library? Doing sink > > logic like this in drivers is kinda wrong ... > > -Daniel > > > We could definitely move some of the stuff to the core helpers. There is > also a bit of follow-up work needed to optimize DPCD read/writes. They > can be done together after this. > > I don't know if you had a chance to look at this series in detail. But > if you did, do you see any blockers for accepting this series? No, my comment was really just a quick observation. Follow-up for that is perfectly fine. I didn't look at the patches in detail. -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
Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
Hi, > We don't support cursor for console vnc. Ideally console vnc should > be > used by admin for configuration or during maintenance, which refresh > primary surface at low refresh rate, 10 fps. But you surely want a mouse pointer for the admin? You render it directly to the primary surface then I guess? > Right we need to know this at device initialization time for both > cases > to initialize VGACommonState structure for that device Why do you need a VGACommonState? > and also need > NONE to decide whether to init console vnc or not. We have a > mechanism > to disable console vnc path and we recommend to disable it for better > performance. Hmm, maybe we should have a ioctl to configure the refresh rate, or a ioctl to allow qemu ask for a refresh when needed? qemu can throttle the display update rate, which for example happens in case no vnc client is connected. qemu updates the display only once every few seconds then. cheers, Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6] drm/i915: Enable guest i915 48bit full ppgtt functionality
On 2017.06.20 21:12:19 +0800, Tina Zhang wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 4ff854e..d777405 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -141,14 +141,20 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private
> *dev_priv,
>
> has_aliasing_ppgtt = dev_priv->info.has_aliasing_ppgtt;
> has_full_ppgtt = dev_priv->info.has_full_ppgtt;
> - has_full_48bit_ppgtt = dev_priv->info.has_full_48bit_ppgtt;
>
> if (intel_vgpu_active(dev_priv)) {
> - /* emulation is too hard */
> - has_full_ppgtt = false;
> - has_full_48bit_ppgtt = false;
> + has_full_ppgtt = intel_vgpu_has_full_ppgtt(dev_priv);
> + /*
> + * FIXME: There is a limition of vgpu supporting 32bit full
> + * ppgtt.
> + */
> + if (enable_ppgtt == 2)
> + enable_ppgtt = 1;
> }
>
> + has_full_48bit_ppgtt = has_full_ppgtt &&
> + dev_priv->info.has_full_48bit_ppgtt;
> +
Does has_full_ppgtt indicate for generic full ppgtt hw feature or just
mean for legacy 32bit ppgtt? If later, then has_full_48bit_ppgtt is not
requiring has_full_ppgtt, for vgpu they'll be all indicated by caps bits,
so we just need to adjust later code like below?
@@ -180,8 +180,8 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private
*dev_priv,
return 0;
}
- if (INTEL_GEN(dev_priv) >= 8 && i915.enable_execlists && has_full_ppgtt)
- return has_full_48bit_ppgtt ? 3 : 2;
+ if (INTEL_GEN(dev_priv) >= 8 && i915.enable_execlists)
+ return has_full_48bit_ppgtt ? 3 : (has_full_ppgtt ? 2 : 1);
else
return has_aliasing_ppgtt ? 1 : 0;
}
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
Hi,
> We already have VFIO_DEVICE_GET_INFO which returns:
>
> struct vfio_device_info {
> __u32 argsz;
> __u32 flags;
> #define VFIO_DEVICE_FLAGS_RESET (1 << 0)/* Device supports
> reset */
> #define VFIO_DEVICE_FLAGS_PCI (1 << 1)/* vfio-pci device */
> #define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform
> device */
> #define VFIO_DEVICE_FLAGS_AMBA (1 << 3)/* vfio-amba device
> */
> #define VFIO_DEVICE_FLAGS_CCW (1 << 4)/* vfio-ccw device */
> __u32 num_regions;/* Max region index + 1 */
> __u32 num_irqs; /* Max IRQ index + 1 */
> };
>
> We could use two flag bits to indicate dmabuf or graphics region
> support.
That works too.
> > Then this to query the plane:
> >
> > struct vfio_device_gfx_query_plane {
> > __u32 argsz;
> > __u32 flags;
> > struct vfio_device_gfx_plane_info plane_info; /* out */
> > __u32 plane_type; /* in */
> > };
>
> I'm not sure why we're using an enum for something that can currently
> be defined with 2 bits,
We can reuse the DRM_PLANE_TYPE_* then.
> seems like this would be another good use of
> flags. We could even embed an enum into the flags if we want to
> leave some expansion room, 4 bits maybe? Also, I was imagining that
> a
> device could support multiple graphics regions, that's where
> specifying
> the "id" as a region index seemed useful.
Hmm, yes, possibly for multihead configurations. But I guess for
proper multihead support we would need more than just an region id.
Or do you have something else in mind?
> > With the generation we can also do something different: Pass in
> > plane_type and generation, and have VFIO_DEVICE_GET_DMABUF_FD
> > return
> > an error in case the generation doesn't match. In that case it
> > doesn't
> > make much sense any more to have a separate plane_info struct,
> > which
> > was added so we don't have to duplicate things in query-plane and
> > get-
> > dmabuf ioctl structs.
>
> I'm not sure I understand how this works for a region, the region is
> always the current generation, how can the user ever be sure the
> plane_info matches what is exposed in the region?
generation will change each time the plane configuration (not content)
changes. Typically that will be on video mode switches. In the dmabuf
case also on pageflips.
cheers,
Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> totally obsolete.
>
> I think the gamma_store can end up invalid on error. But the way I read
> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
> this pesky legacy fbdev stuff be any better?
>
> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
> it saves it to the gamma_store which should already be up to date with what
> .gamma_get would return and is thus a nop. So, zap it.
Removing drm_fb_helper_save_lut_atomic should be a separate patch I
think.
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_fb_helper.c | 131
>
> 1 file changed, 40 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 574af01..cc2d55d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -229,22 +229,6 @@ int drm_fb_helper_remove_one_connector(struct
> drm_fb_helper *fb_helper,
> }
> EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
>
> -static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct
> drm_fb_helper *helper)
> -{
> - uint16_t *r_base, *g_base, *b_base;
> - int i;
> -
> - if (helper->funcs->gamma_get == NULL)
> - return;
> -
> - r_base = crtc->gamma_store;
> - g_base = r_base + crtc->gamma_size;
> - b_base = g_base + crtc->gamma_size;
> -
> - for (i = 0; i < crtc->gamma_size; i++)
> - helper->funcs->gamma_get(crtc, &r_base[i], &g_base[i],
> &b_base[i], i);
> -}
> -
> static void drm_fb_helper_restore_lut_atomic(struct drm_crtc *crtc)
> {
> uint16_t *r_base, *g_base, *b_base;
> @@ -285,7 +269,6 @@ int drm_fb_helper_debug_enter(struct fb_info *info)
> if (drm_drv_uses_atomic_modeset(mode_set->crtc->dev))
> continue;
>
> - drm_fb_helper_save_lut_atomic(mode_set->crtc, helper);
> funcs->mode_set_base_atomic(mode_set->crtc,
> mode_set->fb,
> mode_set->x,
> @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct
> drm_fb_helper *fb_helper,
> }
> EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>
> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> - u16 blue, u16 regno, struct fb_info *info)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct drm_framebuffer *fb = fb_helper->fb;
> -
> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
This case here seems gone, and it was also the pièce de résistance when I
tried tackling fbdev lut support. As far as I understand this stuff we do
not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
pointless. But I'm honestly not really clear.
I think removing this case should also be a separate patch, and I'd very
much prefer that someone with some fbdev-clue would ack it.
> - u32 *palette;
> - u32 value;
> - /* place color in psuedopalette */
> - if (regno > 16)
> - return -EINVAL;
> - palette = (u32 *)info->pseudo_palette;
> - red >>= (16 - info->var.red.length);
> - green >>= (16 - info->var.green.length);
> - blue >>= (16 - info->var.blue.length);
> - value = (red << info->var.red.offset) |
> - (green << info->var.green.offset) |
> - (blue << info->var.blue.offset);
> - if (info->var.transp.length > 0) {
> - u32 mask = (1 << info->var.transp.length) - 1;
> -
> - mask <<= info->var.transp.offset;
> - value |= mask;
> - }
> - palette[regno] = value;
> - return 0;
> - }
> -
> - /*
> - * The driver really shouldn't advertise pseudo/directcolor
> - * visuals if it can't deal with the palette.
> - */
> - if (WARN_ON(!fb_helper->funcs->gamma_set ||
> - !fb_helper->funcs->gamma_get))
> - return -EINVAL;
> -
> - WARN_ON(fb->format->cpp[0] != 1);
> -
> - fb_helper->funcs->gamma_set(crtc, red, green, blue, regno);
> -
> - return 0;
> -}
> -
> /**
> * drm_fb_helper_setcmap - implementation for &fb_ops.fb_setcmap
> * @cmap: cmap to set
> @@ -1220,51 +1159,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap,
> struct fb_info *info)
> {
> struct drm_fb_helper *fb_helper = info->par;
> struct drm_device *dev = fb_helper->dev;
> - const struct drm_crtc_helper_funcs *crtc_funcs;
> - u16 *red, *green, *blue, *transp;
> + struct drm_modeset_acquire_ctx ctx;
> struct drm_crtc *crtc;
> - int i, j, rc = 0;
> - int
Re: [Intel-gfx] [PATCH 00/11] improve the fb_setcmap helper
On Tue, Jun 20, 2017 at 09:25:24PM +0200, Peter Rosin wrote: > Hi! > > While trying to get CLUT support for the atmel_hlcdc driver, and > specifically for the emulated fbdev interface, I received some > push-back that my feeble in-driver attempts should be solved > by the core. This is my attempt to do it right. > > Boris and Daniel, was this approximately what you had in mind? Yeah, this is awesome. I tried to do it a few times myself, but always failed (also due to lack of real use-case on my side). > I have obviously not tested all of this with more than a compile, > but the first patch is enough to make the atmel-hlcdc driver > do what I need. The rest is just lots of removals and cleanup > made possible by the improved core. If it works for you it's imo good enough. Not sure anyone else really cares about fbdev lut support at all. I have a few comments on the first patch, but once that's sorted, and once we have given driver maintainers enough time to ack I think I'll merge the entire pile into drm-misc. Nice work, thanks for doing it. Cheers, Daniel > Please test, I would not be surprised if I have fouled up some > bit-manipulation somewhere in this mostly mechanical change... > > Cheers, > peda > > Peter Rosin (11): > drm/fb-helper: do a generic fb_setcmap helper in terms of crtc > .gamma_set > drm: amd: remove dead code and pointless local lut storage > drm: ast: remove dead code and pointless local lut storage > drm: cirrus: remove dead code and pointless local lut storage > dmr: gma500: remove dead code and pointless local lut storage > drm: i915: remove dead code and pointless local lut storage > drm: mgag200: remove dead code and pointless local lut storage > drm: nouveau: remove dead code and pointless local lut storage > drm: radeon: remove dead code and pointless local lut storage > drm: stm: remove dead code and pointless local lut storage > drm: remove unused and redundant callbacks > > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 24 - > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 - > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 27 ++ > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 27 ++ > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 27 ++ > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 27 ++ > drivers/gpu/drm/amd/amdgpu/dce_virtual.c| 23 - > drivers/gpu/drm/ast/ast_drv.h | 1 - > drivers/gpu/drm/ast/ast_fb.c| 20 - > drivers/gpu/drm/ast/ast_mode.c | 26 ++ > drivers/gpu/drm/cirrus/cirrus_drv.h | 8 -- > drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 - > drivers/gpu/drm/cirrus/cirrus_mode.c| 71 --- > drivers/gpu/drm/drm_fb_helper.c | 131 > +--- > drivers/gpu/drm/gma500/framebuffer.c| 22 - > drivers/gpu/drm/gma500/gma_display.c| 32 +++ > drivers/gpu/drm/gma500/psb_intel_display.c | 7 +- > drivers/gpu/drm/gma500/psb_intel_drv.h | 1 - > drivers/gpu/drm/i915/intel_drv.h| 1 - > drivers/gpu/drm/i915/intel_fbdev.c | 31 --- > drivers/gpu/drm/mgag200/mgag200_drv.h | 5 -- > drivers/gpu/drm/mgag200/mgag200_fb.c| 2 - > drivers/gpu/drm/mgag200/mgag200_mode.c | 62 - > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 26 ++ > drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 22 - > drivers/gpu/drm/nouveau/nv50_display.c | 39 +++-- > drivers/gpu/drm/radeon/atombios_crtc.c | 1 - > drivers/gpu/drm/radeon/radeon_connectors.c | 7 +- > drivers/gpu/drm/radeon/radeon_display.c | 71 ++- > drivers/gpu/drm/radeon/radeon_fb.c | 2 - > drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 1 - > drivers/gpu/drm/stm/ltdc.c | 12 --- > drivers/gpu/drm/stm/ltdc.h | 1 - > include/drm/drm_fb_helper.h | 32 --- > include/drm/drm_modeset_helper_vtables.h| 16 > 36 files changed, 171 insertions(+), 640 deletions(-) > > -- > 2.1.4 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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] drm: Fix GETCONNECTOR regression
On Tue, Jun 20, 2017 at 05:40:25PM -0400, Sean Paul wrote:
> On Tue, Jun 20, 2017 at 10:28:37PM +0200, Daniel Vetter wrote:
> > In
> >
> > commit 91eefc05f0ac71902906b2058360e61bd25137fe
> > Author: Daniel Vetter
> > Date: Wed Dec 14 00:08:10 2016 +0100
> >
> > drm: Tighten locking in drm_mode_getconnector
> >
> > I reordered the logic a bit in that IOCTL, but that broke userspace
> > since it'll get the new mode list, but not the new property values.
> > Fix that again.
> >
> > v2: Fix up the error path handling when copy_to_user for the modes
> > failes (Dhinakaran).
> >
> > Fixes: 91eefc05f0ac ("drm: Tighten locking in drm_mode_getconnector")
> > Cc: Sean Paul
> > Cc: Daniel Vetter
> > Cc: Jani Nikula
> > Cc: David Airlie
> > Cc: dri-de...@lists.freedesktop.org
> > Reported-by: "H.J. Lu"
> > Tested-by: "H.J. Lu"
> > Cc: # v4.11+
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100576
> > Cc: "H.J. Lu"
> > Cc: "Pandiyan, Dhinakaran"
> > Signed-off-by: Daniel Vetter
>
> Yep, lgtm
>
>
> Reviewed-by: Sean Paul
Pushed to -fixes, thanks for the review.
-Daniel
>
> > ---
> > drivers/gpu/drm/drm_connector.c | 38 --
> > 1 file changed, 20 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 5cd61aff7857..8072e6e4c62c 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1293,21 +1293,6 @@ int drm_mode_getconnector(struct drm_device *dev,
> > void *data,
> > if (!connector)
> > return -ENOENT;
> >
> > - drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> > - encoder = drm_connector_get_encoder(connector);
> > - if (encoder)
> > - out_resp->encoder_id = encoder->base.id;
> > - else
> > - out_resp->encoder_id = 0;
> > -
> > - ret = drm_mode_object_get_properties(&connector->base,
> > file_priv->atomic,
> > - (uint32_t __user *)(unsigned long)(out_resp->props_ptr),
> > - (uint64_t __user *)(unsigned
> > long)(out_resp->prop_values_ptr),
> > - &out_resp->count_props);
> > - drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > - if (ret)
> > - goto out_unref;
> > -
> > for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
> > if (connector->encoder_ids[i] != 0)
> > encoders_count++;
> > @@ -1320,7 +1305,7 @@ int drm_mode_getconnector(struct drm_device *dev,
> > void *data,
> > if (put_user(connector->encoder_ids[i],
> > encoder_ptr + copied)) {
> > ret = -EFAULT;
> > - goto out_unref;
> > + goto out;
> > }
> > copied++;
> > }
> > @@ -1364,15 +1349,32 @@ int drm_mode_getconnector(struct drm_device *dev,
> > void *data,
> > if (copy_to_user(mode_ptr + copied,
> > &u_mode, sizeof(u_mode))) {
> > ret = -EFAULT;
> > + mutex_unlock(&dev->mode_config.mutex);
> > +
> > goto out;
> > }
> > copied++;
> > }
> > }
> > out_resp->count_modes = mode_count;
> > -out:
> > mutex_unlock(&dev->mode_config.mutex);
> > -out_unref:
> > +
> > + drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> > + encoder = drm_connector_get_encoder(connector);
> > + if (encoder)
> > + out_resp->encoder_id = encoder->base.id;
> > + else
> > + out_resp->encoder_id = 0;
> > +
> > + /* Only grab properties after probing, to make sure EDID and other
> > +* properties reflect the latest status. */
> > + ret = drm_mode_object_get_properties(&connector->base,
> > file_priv->atomic,
> > + (uint32_t __user *)(unsigned long)(out_resp->props_ptr),
> > + (uint64_t __user *)(unsigned
> > long)(out_resp->prop_values_ptr),
> > + &out_resp->count_props);
> > + drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > +
> > +out:
> > drm_connector_put(connector);
> >
> > return ret;
> > --
> > 2.11.0
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
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 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
On 21/06/17 04:38 PM, Daniel Vetter wrote:
> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
>> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
>> totally obsolete.
>>
>> I think the gamma_store can end up invalid on error. But the way I read
>> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
>> this pesky legacy fbdev stuff be any better?
>>
>> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
>> it saves it to the gamma_store which should already be up to date with what
>> .gamma_get would return and is thus a nop. So, zap it.
>
> Removing drm_fb_helper_save_lut_atomic should be a separate patch I
> think.
>
>> Signed-off-by: Peter Rosin
[...]
>> @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct
>> drm_fb_helper *fb_helper,
>> }
>> EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>>
>> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>> - u16 blue, u16 regno, struct fb_info *info)
>> -{
>> -struct drm_fb_helper *fb_helper = info->par;
>> -struct drm_framebuffer *fb = fb_helper->fb;
>> -
>> -if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
>
> This case here seems gone, and it was also the pièce de résistance when I
> tried tackling fbdev lut support. As far as I understand this stuff we do
> not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
> pointless. But I'm honestly not really clear.
>
> I think removing this case should also be a separate patch, and I'd very
> much prefer that someone with some fbdev-clue would ack it.
No need for anyone with fbdev-clue, just run fbset -i. :) fbcon uses a
TRUECOLOR visual at depths > 8.
> It's a pre-existing bug, but should we also try to restore the fbdev lut
> in drm_fb_helper_restore_fbdev_mode_unlocked()? Would be yet another bug,
> but might be relevant for your use-case. Just try to run both an fbdev
> application and some kms-native thing, and then SIGKILL the native kms
> app.
>
> But since pre-existing not really required, and probably too much effort.
I suspect something like that indeed needs to be done though. E.g.
killing Xorg results in fbcon continuing to use the LUT set by Xorg.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] edp-DRRS test
Idleness DRRS:
By default the DRRS state will be at DRRS_HIGH_RR. When a Display
content is Idle for more than 1Sec Idleness will be declared and
DRRS_LOW_RR will be invoked, changing the refresh rate to the
lower most refresh rate supported by the panel. As soon as there
is a display content change there will be a DRRS state transition
as DRRS_LOW_RR--> DRRS_HIGH_RR, changing the refresh rate to the
highest refresh rate supported by the panel.
To test this, Idleness DRRS IGT will probe the DRRS state at below
instances and compare with the expected state.
InstanceExpected State
1. Immediately after rendering the still image DRRS_HIGH_RR
2. After a delay of 1.2Sec DRRS_LOW_RR
3. After changing the frame buffer DRRS_HIGH_RR
4. After a delay of 1.2Sec DRRS_LOW_RR
5. After changing the frame buffer DRRS_HIGH_RR
6. After a delay of 1.2Sec DRRS_LOW_RR
The test checks the driver DRRS state from the debugfs entry. To check the
actual refresh-rate, the number of vblanks received per sec.
The refresh-rate calculated is checked against the expected refresh-rate
with a tolerance value of 2.
This patch is a continuation of the earlier work
https://patchwork.freedesktop.org/patch/45472/ towards igt for idleness
DRRS. The code is tested on Broxton BXT_T platform.
v2: Addressed the comments and suggestions from Vlad, Marius.
The signoff details from the earlier work are also included.
v3: Modified vblank rate calculation by using reply-sequence, provided by
drmWaitVBlank, as suggested by Chris Wilson.
v4: As suggested from Chris Wilson and Daniel Vetter
1) Avoided using pthread for calculating vblank refresh rate,
instead used drmWaitVBlank reply sequence.
2) Avoided using kernel-specific info like transitional delays,
instead polling mechanism with timeout is used.
3) Included edp-DRRS as a subtest in kms_frontbuffer_tracking.c,
instead of having a separate test.
This is in continuation of last patch
"https://patchwork.freedesktop.org/patch/117149/";
Signed-off-by: Lohith BS
Signed-off-by: Ramalingam C
Signed-off-by: Vandana Kannan
Signed-off-by: aknautiy
---
tests/kms_frontbuffer_tracking.c | 453 ++-
1 file changed, 452 insertions(+), 1 deletion(-)
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index c24e4a8..4d46e1e 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -32,9 +32,18 @@
#include
#include
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "intel_chipset.h"
+#include "intel_batchbuffer.h"
+#include "ioctl_wrappers.h"
+#include
+#include
+#include
IGT_TEST_DESCRIPTION("Test the Kernel's frontbuffer tracking mechanism and "
-"its related features: FBC and PSR");
+"its related features: DRRS, FBC and PSR");
/*
* One of the aspects of this test is that, for every subtest, we try different
@@ -327,6 +336,41 @@ drmModeModeInfo std_1024_mode = {
.name = "Custom 1024x768",
};
+#define DRRS_TOLERANCE_THRESHOLD 2
+#define DRRS_POLL_TIMEOUT_PERIOD_MS 5000
+#define DRRS_STATUS_BYTES_CNT 1000
+#define DRRS_MAX_ITERATION 3
+
+/*
+ * Struct to hold drrs test related data
+ */
+typedef struct {
+ uint32_t devid;
+ uint32_t handle[2];
+ igt_display_t display;
+ igt_output_t *output;
+ enum pipe pipe;
+ igt_plane_t *primary;
+ struct igt_fb fb[2];
+ uint32_t fb_id[2];
+} drrs_data_t;
+
+/*
+ * Structure to count vblank and note the starting time of the counter
+ */
+typedef struct {
+ unsigned int vbl_count;
+ struct timeval start;
+} vbl_info;
+
+/*
+ * Structure for refresh rate type
+ */
+typedef struct{
+ int rate;
+ const char *name;
+} refresh_rate_t;
+
static drmModeModeInfoPtr get_connector_smallest_mode(drmModeConnectorPtr c)
{
int i;
@@ -3415,6 +3459,410 @@ static const char *flip_str(enum flip_type flip)
#define TEST_MODE_ITER_END } } } } } }
+static inline uint32_t pipe_select(int pipe)
+{
+ if (pipe > 1)
+ return pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
+ else if (pipe > 0)
+ return DRM_VBLANK_SECONDARY;
+ else
+ return DRM_VBLANK_ABSOLUTE;
+}
+
+/*
+ * Calculates the total no. of millisec elapsed since timeval start
+ */
+static double igt_millisec_elapsed(const struct timeval *start)
+{
+ struct timeval curr;
+
+ gettimeofday(&curr, NULL);
+ return (1e3*(curr.tv_sec - start->tv_sec) +
+ (curr.tv_usec - start->tv_usec)/1000.00);
+}
+
+/*
+ * Func to read the DRRS status from debugfs
+ */
+static bool read_drrs_stat
Re: [Intel-gfx] [Nouveau] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
> On 21/06/17 04:38 PM, Daniel Vetter wrote:
> > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> >> totally obsolete.
> >>
> >> I think the gamma_store can end up invalid on error. But the way I read
> >> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
> >> this pesky legacy fbdev stuff be any better?
> >>
> >> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
> >> it saves it to the gamma_store which should already be up to date with what
> >> .gamma_get would return and is thus a nop. So, zap it.
> >
> > Removing drm_fb_helper_save_lut_atomic should be a separate patch I
> > think.
> >
> >> Signed-off-by: Peter Rosin
>
> [...]
>
> >> @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct
> >> drm_fb_helper *fb_helper,
> >> }
> >> EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
> >>
> >> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> >> - u16 blue, u16 regno, struct fb_info *info)
> >> -{
> >> - struct drm_fb_helper *fb_helper = info->par;
> >> - struct drm_framebuffer *fb = fb_helper->fb;
> >> -
> >> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> >
> > This case here seems gone, and it was also the pièce de résistance when I
> > tried tackling fbdev lut support. As far as I understand this stuff we do
> > not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
> > pointless. But I'm honestly not really clear.
> >
> > I think removing this case should also be a separate patch, and I'd very
> > much prefer that someone with some fbdev-clue would ack it.
>
> No need for anyone with fbdev-clue, just run fbset -i. :) fbcon uses a
> TRUECOLOR visual at depths > 8.
Then I understand even less what exactly this code does ... Should we keep
it? Is it just pure cargo-cult? Only needed when we'd change the color
depth of the fbdev buffer, which we never do at runtime?
> > It's a pre-existing bug, but should we also try to restore the fbdev lut
> > in drm_fb_helper_restore_fbdev_mode_unlocked()? Would be yet another bug,
> > but might be relevant for your use-case. Just try to run both an fbdev
> > application and some kms-native thing, and then SIGKILL the native kms
> > app.
> >
> > But since pre-existing not really required, and probably too much effort.
>
> I suspect something like that indeed needs to be done though. E.g.
> killing Xorg results in fbcon continuing to use the LUT set by Xorg.
Ok, the only trouble with that is atomic kms locking, which requires that
we can only do 1 commit per lock-holding time, and also
drm_modeset_lock_all is an evil hack and needs to be phased out. Two
solutions:
- We just update the lut after we've dropped the locks again in
restore_fbdev_mode.
- We need both a legacy path, in restore_fbdev_mode_legacy, and an atomic
path in restore_fbdev_mode_atomic. The latter cannot use the gamme_set
callback, since that would call drm_atomic_helper_legacy_gamma_set for
atomic drivers, which would result in two calls to drm_atomic_commit in
one critical sections. Instead that needs to open-code the logic in
drm_atomic_helper_legacy_gamma_set and integrate it into the overall
fbdev restore commit.
The 2nd option is a bit more typing, but much cleaner. It also fits better
into some of the refactoring plans I have (I want to get rid of
drm_modeset_lock_all in the fbdev emulation). And has the benefit of
giving drivers a bit more complex fbdev emulation atomic commits, which
would be good for testing I think.
Cheers, 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] [PATCH 00/13] RESEND: remove drm_vblank_cleanup from drivers
Hi all, This is the resend of the driver patches which haven't seen and ack/r-b yet and so aren't merged yet. I'd really like to get them all merged. Review/acks very much appreciated. Thanks, Daniel Daniel Vetter (13): drm/amd|radeon: Drop drm_vblank_cleanup drm/hibmc: Drop drm_vblank_cleanup drm/kirin: Drop drm_vblank_cleanup drm/i915: Drop drm_vblank_cleanup drm/mtk: Drop drm_vblank_cleanup drm/mxsfb: Drop drm_vblank_cleanup drm/nouveau: Drop drm_vblank_cleanup drm/rockchip: Drop drm_vblank_cleanup drm/shmob: Drop drm_vblank_cleanup drm/udl: Drop drm_vblank_cleanup drm/vmwgfx: Drop drm_vblank_cleanup drm/zte: Drop drm_vblank_cleanup drm/vblank: Unexport drm_vblank_cleanup drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 1 - drivers/gpu/drm/drm_internal.h | 1 + drivers/gpu/drm/drm_vblank.c| 19 ++--- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 1 - drivers/gpu/drm/i915/i915_drv.c | 6 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 - drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 - drivers/gpu/drm/nouveau/nouveau_display.c | 2 -- drivers/gpu/drm/radeon/radeon_irq_kms.c | 1 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 -- drivers/gpu/drm/shmobile/shmob_drm_drv.c| 4 +--- drivers/gpu/drm/udl/udl_main.c | 2 -- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 -- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 9 - drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 27 + drivers/gpu/drm/zte/zx_drm_drv.c| 2 -- include/drm/drm_vblank.h| 1 - 20 files changed, 11 insertions(+), 87 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/13] drm/hibmc: Drop drm_vblank_cleanup
So this seems to be the first driver that does it the right way round, so fix it up by calling drm_atomic_helper_shutdown instead. We need to do that before the last kms user is gone (fbdev emulation), but before we start shutting down hw stuff like interrupts. Cc: Xinliang Liu Cc: Rongrong Zou Cc: Xinwei Kong Cc: Chen Feng Signed-off-by: Daniel Vetter --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index 2ffdbf9801bd..4d018ca98581 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c @@ -276,11 +276,12 @@ static int hibmc_unload(struct drm_device *dev) hibmc_fbdev_fini(priv); + drm_atomic_helper_shutdown(dev); + if (dev->irq_enabled) drm_irq_uninstall(dev); if (priv->msi_enabled) pci_disable_msi(dev->pdev); - drm_vblank_cleanup(dev); hibmc_kms_fini(priv); hibmc_mm_fini(priv); -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/13] drm/mtk: Drop drm_vblank_cleanup
Seems entirely cargo-culted.
Cc: CK Hu
Cc: Philipp Zabel
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index f6c8ec4c7dbc..56f802d0a51c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -266,7 +266,6 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
{
drm_kms_helper_poll_fini(drm);
- drm_vblank_cleanup(drm);
component_unbind_all(drm->dev, drm);
drm_mode_config_cleanup(drm);
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/13] drm/kirin: Drop drm_vblank_cleanup
Again we probably want a drm_atomic_helper_shutdown somewhere, but that's a bit more analysis. Cc: Xinliang Liu Cc: Rongrong Zou Cc: Xinwei Kong Cc: Chen Feng Signed-off-by: Daniel Vetter --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index 9c903672f582..8065d6cb1d7f 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -41,7 +41,6 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev) } #endif drm_kms_helper_poll_fini(dev); - drm_vblank_cleanup(dev); dc_ops->cleanup(to_platform_device(dev->dev)); drm_mode_config_cleanup(dev); devm_kfree(dev->dev, priv); -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/13] drm/amd|radeon: Drop drm_vblank_cleanup
Both drivers shut down all crtc beforehand already, which will shut up
any pending vblank (the only thing vblank_cleanup really does is
disable the disable timer). Hence we don't need this here and can
remove it.
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 1 -
drivers/gpu/drm/radeon/radeon_irq_kms.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 62da6c5c6095..2480273c1dca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -263,7 +263,6 @@ void amdgpu_irq_fini(struct amdgpu_device *adev)
{
unsigned i, j;
- drm_vblank_cleanup(adev->ddev);
if (adev->irq.installed) {
drm_irq_uninstall(adev->ddev);
adev->irq.installed = false;
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 7aacb44df201..fff0d11b0600 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -324,7 +324,6 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
*/
void radeon_irq_kms_fini(struct radeon_device *rdev)
{
- drm_vblank_cleanup(rdev->ddev);
if (rdev->irq.installed) {
drm_irq_uninstall(rdev->ddev);
rdev->irq.installed = false;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/13] drm/i915: Drop drm_vblank_cleanup
On the load error path we can't have pending vblank interrupts, and on unload we already call drm_atomic_helper_shutdown beforehand! So all good to nuke it. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index d1aa10c9cc5d..eb5e93932caa 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1321,7 +1321,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) ret = i915_load_modeset_init(&dev_priv->drm); if (ret < 0) - goto out_cleanup_vblank; + goto out_cleanup_hw; i915_driver_register(dev_priv); @@ -1338,8 +1338,6 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) return 0; -out_cleanup_vblank: - drm_vblank_cleanup(&dev_priv->drm); out_cleanup_hw: i915_driver_cleanup_hw(dev_priv); out_cleanup_mmio: @@ -1375,8 +1373,6 @@ void i915_driver_unload(struct drm_device *dev) i915_driver_unregister(dev_priv); - drm_vblank_cleanup(dev); - intel_modeset_cleanup(dev); /* -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/13] drm/nouveau: Drop drm_vblank_cleanup
nouveau_display_vblank_fini is called in the load error path (where it
doesn't matter) and module unload (where vblanks have been shut down
correctly already through drm_vblank_off), we can drop it.
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 8d1df5678eaa..b9a109be989c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -159,8 +159,6 @@ nouveau_display_vblank_fini(struct drm_device *dev)
{
struct drm_crtc *crtc;
- drm_vblank_cleanup(dev);
-
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
nvif_notify_fini(&nv_crtc->vblank);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/13] drm/mxsfb: Drop drm_vblank_cleanup
Almost right but still racy, it's called before the interrupts are uninstalled. So let's just drop it. Cc: Marek Vasut Signed-off-by: Daniel Vetter --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index d1b9c34c7c00..1853557fef46 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -256,7 +256,6 @@ static void mxsfb_unload(struct drm_device *drm) drm_kms_helper_poll_fini(drm); drm_mode_config_cleanup(drm); - drm_vblank_cleanup(drm); pm_runtime_get_sync(drm->dev); drm_irq_uninstall(drm); -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/13] drm/udl: Drop drm_vblank_cleanup
udl doesn't shut down the display, so stopping the vblank isn't going
to do much good either. Just drop it.
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/udl/udl_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index a9d93b871a15..0328b2c7b210 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -371,8 +371,6 @@ void udl_driver_unload(struct drm_device *dev)
{
struct udl_device *udl = dev->dev_private;
- drm_vblank_cleanup(dev);
-
if (udl->urbs.count)
udl_free_urb_list(dev);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/13] drm/rockchip: Drop drm_vblank_cleanup
Either not relevant (in the load error paths) or done better already (in the unload code, by calling drm_atomic_helper_shutdown). Drop it. Cc: Mark Yao Signed-off-by: Daniel Vetter --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index c6b1b7f3a2a3..b9fbf4b1e8f0 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -177,7 +177,6 @@ static int rockchip_drm_bind(struct device *dev) rockchip_drm_fbdev_fini(drm_dev); err_kms_helper_poll_fini: drm_kms_helper_poll_fini(drm_dev); - drm_vblank_cleanup(drm_dev); err_unbind_all: component_unbind_all(dev, drm_dev); err_mode_config_cleanup: @@ -200,7 +199,6 @@ static void rockchip_drm_unbind(struct device *dev) drm_kms_helper_poll_fini(drm_dev); drm_atomic_helper_shutdown(drm_dev); - drm_vblank_cleanup(drm_dev); component_unbind_all(dev, drm_dev); drm_mode_config_cleanup(drm_dev); rockchip_iommu_cleanup(drm_dev); -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/13] drm/shmob: Drop drm_vblank_cleanup
It doesn't do anything in the driver load error paths that the drm
core doesn't also do.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 800d1d2c435d..c2ca07357aac 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -277,7 +277,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
ret = drm_irq_install(ddev, platform_get_irq(pdev, 0));
if (ret < 0) {
dev_err(&pdev->dev, "failed to install IRQ handler\n");
- goto err_vblank_cleanup;
+ goto err_modeset_cleanup;
}
/*
@@ -292,8 +292,6 @@ static int shmob_drm_probe(struct platform_device *pdev)
err_irq_uninstall:
drm_irq_uninstall(ddev);
-err_vblank_cleanup:
- drm_vblank_cleanup(ddev);
err_modeset_cleanup:
drm_kms_helper_poll_fini(ddev);
drm_mode_config_cleanup(ddev);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/13] drm/zte: Drop drm_vblank_cleanup
It again looks all cargo-culted for no good reasons. Cc: Shawn Guo Signed-off-by: Daniel Vetter --- drivers/gpu/drm/zte/zx_drm_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c index f46c855d274b..fe1aa5315e19 100644 --- a/drivers/gpu/drm/zte/zx_drm_drv.c +++ b/drivers/gpu/drm/zte/zx_drm_drv.c @@ -149,7 +149,6 @@ static int zx_drm_bind(struct device *dev) out_poll_fini: drm_kms_helper_poll_fini(drm); drm_mode_config_cleanup(drm); - drm_vblank_cleanup(drm); out_unbind: component_unbind_all(dev, drm); out_unregister: @@ -171,7 +170,6 @@ static void zx_drm_unbind(struct device *dev) } drm_kms_helper_poll_fini(drm); drm_mode_config_cleanup(drm); - drm_vblank_cleanup(drm); component_unbind_all(dev, drm); dev_set_drvdata(dev, NULL); drm->dev_private = NULL; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/13] drm/vblank: Unexport drm_vblank_cleanup
There's no reason for drivers to call this, and all the ones I've
removed looked very fishy:
- Proper quiescenting of the vblank machinery should be done by
calling drm_crtc_vblank_off(), which is best done by shutting down
the entire display engine with drm_atomic_helper_shutdown.
- Releasing of allocated memory is done by the core already, it calls
drm_vblank_cleanup as a fallback.
- drm_vblank_cleanup also has checks for drivers which forget to clean
up vblank interrupts.
This essentially reverts
commit e77cef9c2d87db835ad9d70cde4a9b00b0ca2262
Author: Jerome Glisse
Date: Thu Jan 7 15:39:13 2010 +0100
drm: Avoid calling vblank function is vblank wasn't initialized
which was done to fix a bug in radeon code with msi interrupts:
commit 003e69f9862bcda89a75c27750efdbc17ac02945
Author: Jerome Glisse
Date: Thu Jan 7 15:39:14 2010 +0100
drm/radeon/kms: Don't try to enable IRQ if we have no handler installed
Afaict from digging around in old code, this was needed to avoid
blowing up in the ums fallback, and has stopped serving it's purpose
long ago - if irq init fails, the driver fails to load, and there's
really no way to blow up anymore.
Long story short, this was most likely a small ums compat/fallback
hack that became a thing of it's own and got cargo-cult duplicated all
over the drm codebase for essentially no gain at all.
v2: Mention that for drivers with a ->release callback cleanup is
handled by drm_dev_fini() (Thierry).
Cc: Thierry Reding
Acked-by: Thierry Reding
Cc: Jerome Glisse
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_internal.h | 1 +
drivers/gpu/drm/drm_vblank.c | 19 ++-
include/drm/drm_vblank.h | 1 -
3 files changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index f89371e920e6..068b685608cf 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -57,6 +57,7 @@ int drm_gem_name_info(struct seq_file *m, void *data);
/* drm_vblank.c */
extern unsigned int drm_timestamp_monotonic;
void drm_vblank_disable_and_save(struct drm_device *dev, unsigned int pipe);
+void drm_vblank_cleanup(struct drm_device *dev);
/* IOCTLS */
int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7e3f59182571..05d043e9219f 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -394,19 +394,6 @@ static void vblank_disable_fn(unsigned long arg)
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
}
-/**
- * drm_vblank_cleanup - cleanup vblank support
- * @dev: DRM device
- *
- * This function cleans up any resources allocated in drm_vblank_init(). It is
- * called by the DRM core when @dev is finalized.
- *
- * Drivers can call drm_vblank_cleanup() if they need to quiescent the vblank
- * interrupt in their unload code. But in general this should be handled by
- * disabling all active &drm_crtc through e.g. drm_atomic_helper_shutdown,
which
- * should end up calling drm_crtc_vblank_off().
- *
- */
void drm_vblank_cleanup(struct drm_device *dev)
{
unsigned int pipe;
@@ -428,7 +415,6 @@ void drm_vblank_cleanup(struct drm_device *dev)
dev->num_crtcs = 0;
}
-EXPORT_SYMBOL(drm_vblank_cleanup);
/**
* drm_vblank_init - initialize vblank support
@@ -436,9 +422,8 @@ EXPORT_SYMBOL(drm_vblank_cleanup);
* @num_crtcs: number of CRTCs supported by @dev
*
* This function initializes vblank support for @num_crtcs display pipelines.
- * Drivers do not need to call drm_vblank_cleanup(), cleanup is already handled
- * by the DRM core, or through calling drm_dev_fini() for drivers with a
- * &drm_driver.release callback.
+ * Cleanup is handled by the DRM core, or through calling drm_dev_fini() for
+ * drivers with a &drm_driver.release callback.
*
* Returns:
* Zero on success or a negative error code on failure.
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 4ceef128582f..7fba9efe4951 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -168,7 +168,6 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
void drm_crtc_vblank_off(struct drm_crtc *crtc);
void drm_crtc_vblank_reset(struct drm_crtc *crtc);
void drm_crtc_vblank_on(struct drm_crtc *crtc);
-void drm_vblank_cleanup(struct drm_device *dev);
u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/13] drm/vmwgfx: Drop drm_vblank_cleanup
Again stopping the vblank before uninstalling the irq handler is kinda
the wrong way round, but the fb_off stuff should take care of
disabling the dsiplay at least in most cases. So drop the
drm_vblank_cleanup code since it's not really doing anything, it looks
all cargo-culted.
v2: Appease gcc better.
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 --
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 9 -
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 27 +--
5 files changed, 4 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3d94ea67a825..a93c0bb73452 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1658,7 +1658,7 @@ int vmw_kms_init(struct vmw_private *dev_priv)
int vmw_kms_close(struct vmw_private *dev_priv)
{
- int ret;
+ int ret = 0;
/*
* Docs says we should take the lock before calling this function
@@ -1666,11 +1666,8 @@ int vmw_kms_close(struct vmw_private *dev_priv)
* drm_encoder_cleanup which takes the lock we deadlock.
*/
drm_mode_config_cleanup(dev_priv->dev);
- if (dev_priv->active_display_unit == vmw_du_screen_object)
- ret = vmw_kms_sou_close_display(dev_priv);
- else if (dev_priv->active_display_unit == vmw_du_screen_target)
- ret = vmw_kms_stdu_close_display(dev_priv);
- else
+ if (dev_priv->active_display_unit != vmw_du_screen_object &&
+ dev_priv->active_display_unit != vmw_du_screen_target)
ret = vmw_kms_ldu_close_display(dev_priv);
return ret;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 5f8d678ae675..ff9c8389ff21 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -390,7 +390,6 @@ int vmw_kms_update_proxy(struct vmw_resource *res,
* Screen Objects display functions - vmwgfx_scrn.c
*/
int vmw_kms_sou_init_display(struct vmw_private *dev_priv);
-int vmw_kms_sou_close_display(struct vmw_private *dev_priv);
int vmw_kms_sou_do_surface_dirty(struct vmw_private *dev_priv,
struct vmw_framebuffer *framebuffer,
struct drm_clip_rect *clips,
@@ -418,7 +417,6 @@ int vmw_kms_sou_readback(struct vmw_private *dev_priv,
* Screen Target Display Unit functions - vmwgfx_stdu.c
*/
int vmw_kms_stdu_init_display(struct vmw_private *dev_priv);
-int vmw_kms_stdu_close_display(struct vmw_private *dev_priv);
int vmw_kms_stdu_surface_dirty(struct vmw_private *dev_priv,
struct vmw_framebuffer *framebuffer,
struct drm_clip_rect *clips,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index d3987bcf53f8..449ed4fba0f2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -582,13 +582,9 @@ int vmw_kms_ldu_init_display(struct vmw_private *dev_priv)
int vmw_kms_ldu_close_display(struct vmw_private *dev_priv)
{
- struct drm_device *dev = dev_priv->dev;
-
if (!dev_priv->ldu_priv)
return -ENOSYS;
- drm_vblank_cleanup(dev);
-
BUG_ON(!list_empty(&dev_priv->ldu_priv->active));
kfree(dev_priv->ldu_priv);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 8d7dc9def7c2..3b917c9b0c21 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -746,15 +746,6 @@ int vmw_kms_sou_init_display(struct vmw_private *dev_priv)
return 0;
}
-int vmw_kms_sou_close_display(struct vmw_private *dev_priv)
-{
- struct drm_device *dev = dev_priv->dev;
-
- drm_vblank_cleanup(dev);
-
- return 0;
-}
-
static int do_dmabuf_define_gmrfb(struct vmw_private *dev_priv,
struct vmw_framebuffer *framebuffer)
{
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 50be1f034f9e..6aecba6cd5e2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1651,36 +1651,11 @@ int vmw_kms_stdu_init_display(struct vmw_private
*dev_priv)
if (unlikely(ret != 0)) {
DRM_ERROR("Failed to initialize STDU %d", i);
- goto err_vblank_cleanup;
+ return ret;
}
}
DRM_INFO("Screen Target Display device initialized\n");
return 0;
-
-err_vblank_cleanup:
- drm_vblank_cleanup(dev);
- return ret;
-}
-
-
-
-/**
- * vmw_kms_stdu_close_display - Cleans up after vmw_kms_stdu_init_display
- *
- * @dev_priv: VMW DRM
Re: [Intel-gfx] [Nouveau] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set
On 21/06/17 05:14 PM, Daniel Vetter wrote:
> On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
>> On 21/06/17 04:38 PM, Daniel Vetter wrote:
>>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
totally obsolete.
I think the gamma_store can end up invalid on error. But the way I read
it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
this pesky legacy fbdev stuff be any better?
drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
it saves it to the gamma_store which should already be up to date with what
.gamma_get would return and is thus a nop. So, zap it.
>>>
>>> Removing drm_fb_helper_save_lut_atomic should be a separate patch I
>>> think.
>>>
Signed-off-by: Peter Rosin
>>
>> [...]
>>
@@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct
drm_fb_helper *fb_helper,
}
EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
-static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
- u16 blue, u16 regno, struct fb_info *info)
-{
- struct drm_fb_helper *fb_helper = info->par;
- struct drm_framebuffer *fb = fb_helper->fb;
-
- if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
>>>
>>> This case here seems gone, and it was also the pièce de résistance when I
>>> tried tackling fbdev lut support. As far as I understand this stuff we do
>>> not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
>>> pointless. But I'm honestly not really clear.
>>>
>>> I think removing this case should also be a separate patch, and I'd very
>>> much prefer that someone with some fbdev-clue would ack it.
>>
>> No need for anyone with fbdev-clue, just run fbset -i. :)
Adding Bartlomiej and the linux-fbdev list, just in case I'm wrong below.
>> fbcon uses a TRUECOLOR visual at depths > 8.
>
> Then I understand even less what exactly this code does ... Should we keep
> it?
I think we need it. It updates the entries of info->pseudo_palette,
which is kind of a pseudocolor palette mapping 16 indices to pixel
values to write to the framebuffer.
If the setcolreg hook is removed, the setcmap hook needs to do this instead.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for RESEND: remove drm_vblank_cleanup from drivers
== Series Details == Series: RESEND: remove drm_vblank_cleanup from drivers URL : https://patchwork.freedesktop.org/series/26118/ State : warning == Summary == Series 26118v1 RESEND: remove drm_vblank_cleanup from drivers https://patchwork.freedesktop.org/api/1.0/series/26118/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: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test gem_ringfill: Subgroup basic-default: pass -> SKIP (fi-bsw-n3050) Test prime_self_import: Subgroup basic-llseek-bad: pass -> DMESG-WARN (fi-skl-6700hq) fdo#101515 +1 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101515 https://bugs.freedesktop.org/show_bug.cgi?id=101515 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:434s fi-bsw-n3050 total:278 pass:240 dwarn:1 dfail:0 fail:0 skip:37 time:533s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:278 pass:252 dwarn:2 dfail:0 fail:0 skip:24 time:485s fi-byt-n2820 total:278 pass:248 dwarn:2 dfail:0 fail:0 skip:28 time:484s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:586s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:433s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:411s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:495s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:571s fi-kbl-r total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 time:576s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:468s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:340s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:470s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:474s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:431s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:410s 5d186f98ac57d530e6ecd718cdd239cd5ee46803 drm-tip: 2017y-06m-21d-07h-50m-34s UTC integration manifest 594efef drm/vblank: Unexport drm_vblank_cleanup c5731ee8 drm/zte: Drop drm_vblank_cleanup 6bc7bd7 drm/vmwgfx: Drop drm_vblank_cleanup 7b88bbb drm/udl: Drop drm_vblank_cleanup 08eee24 drm/shmob: Drop drm_vblank_cleanup ca887d7 drm/rockchip: Drop drm_vblank_cleanup 5579f50 drm/nouveau: Drop drm_vblank_cleanup 9f8432f drm/mxsfb: Drop drm_vblank_cleanup 0c7fa8d drm/mtk: Drop drm_vblank_cleanup ef21ec4 drm/i915: Drop drm_vblank_cleanup fbb9f8e drm/kirin: Drop drm_vblank_cleanup c2b4518 drm/hibmc: Drop drm_vblank_cleanup c02a28a drm/amd|radeon: Drop drm_vblank_cleanup == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5006/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: select CRC32
On Wed, Jun 21, 2017 at 04:34:20PM +1000, Nicholas Piggin wrote: > kbuild test robot found a build failure when building with thin > archives: > > http://marc.info/?l=linux-kbuild&m=149802285009737&w=2 > > Signed-off-by: Nicholas Piggin Pushed to drm-intel for 4.14, thanks. -Daniel > --- > drivers/gpu/drm/i915/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index a5cd5dacf055..e9e64e8e9765 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -21,6 +21,7 @@ config DRM_I915 > select ACPI_BUTTON if ACPI > select SYNC_FILE > select IOSF_MBI > + select CRC32 > help > Choose this option if you have a system that has "Intel Graphics > Media Accelerator" or "HD Graphics" integrated graphics, > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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] [RFC 1/2] drm/i915: Select engines via class and instance in execbuffer2
From: Tvrtko Ursulin
Building on top of the previous patch which exported the concept
of engine classes and instances, we can also use this instead of
the current awkward engine selection uAPI.
This is primarily interesting for the VCS engine selection which
is a) currently done via disjoint set of flags, and b) the
current I915_EXEC_BSD flags has different semantics depending on
the underlying hardware which is bad.
Proposed idea here is to reserve 8-bits of flags, to pass in the
engine instance, re-use the existing engine selection bits for
the class selection, and a new flag named
I915_EXEC_CLASS_INSTANCE to tell the kernel this new engine
selection API is in use.
The new uAPI also removes access to the weak VCS engine
balancing as currently existing in the driver.
Example usage to send a command to VCS0:
eb.flags = i915_execbuffer2_engine(I915_ENGINE_CLASS_VIDEO_DECODE, 0);
Or to send a command to VCS1:
eb.flags = i915_execbuffer2_engine(I915_ENGINE_CLASS_VIDEO_DECODE, 1);
v2:
* Fix unknown flags mask.
* Use I915_EXEC_RING_MASK for class. (Chris Wilson)
v3:
* Add a map for fast class-instance engine lookup. (Chris Wilson)
v4:
* Update commit to reflect v3.
* Export intel_engine_lookup for other users. (Chris Wilson)
* Split out some warns. (Chris Wilson)
v5:
* Fixed shift and mask logic.
* Rebased to be standalone.
Signed-off-by: Tvrtko Ursulin
Cc: Ben Widawsky
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: "Rogozhkin, Dmitry V"
Cc: Oscar Mateo
Cc: "Gong, Zhipeng"
Cc: intel-vaapi-me...@lists.01.org
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 27 +++
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_engine_cs.c | 20
drivers/gpu/drm/i915/intel_ringbuffer.h| 3 +++
include/uapi/drm/i915_drm.h| 22 +-
6 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30e89456fc61..325e1f325f60 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2137,6 +2137,7 @@ struct drm_i915_private {
struct pci_dev *bridge_dev;
struct i915_gem_context *kernel_context;
struct intel_engine_cs *engine[I915_NUM_ENGINES];
+ struct intel_engine_cs *engine_class[MAX_ENGINE_CLASS +
1][MAX_ENGINE_INSTANCE + 1];
struct i915_vma *semaphore;
struct drm_dma_handle *status_page_dmah;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index b2457556591c..00c363a801cb 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2049,6 +2049,30 @@ gen8_dispatch_bsd_engine(struct drm_i915_private
*dev_priv,
return file_priv->bsd_engine;
}
+static u8 user_class_map[I915_ENGINE_CLASS_MAX] = {
+ [I915_ENGINE_CLASS_OTHER] = OTHER_CLASS,
+ [I915_ENGINE_CLASS_RENDER] = RENDER_CLASS,
+ [I915_ENGINE_CLASS_COPY] = COPY_ENGINE_CLASS,
+ [I915_ENGINE_CLASS_VIDEO] = VIDEO_DECODE_CLASS,
+ [I915_ENGINE_CLASS_VIDEO_ENHANCE] = VIDEO_ENHANCEMENT_CLASS,
+};
+
+static struct intel_engine_cs *
+eb_select_engine_class_instance(struct drm_i915_private *i915,
+ struct drm_i915_gem_execbuffer2 *args)
+{
+ u8 class = args->flags & I915_EXEC_RING_MASK;
+ u8 instance;
+
+ if (class >= ARRAY_SIZE(user_class_map))
+ return NULL;
+
+ instance = (args->flags & I915_EXEC_INSTANCE_MASK) >>
+ I915_EXEC_INSTANCE_SHIFT;
+
+ return intel_engine_lookup(i915, user_class_map[class], instance);
+}
+
#define I915_USER_RINGS (4)
static const enum intel_engine_id user_ring_map[I915_USER_RINGS + 1] = {
@@ -2067,6 +2091,9 @@ eb_select_engine(struct drm_i915_private *dev_priv,
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
struct intel_engine_cs *engine;
+ if (args->flags & I915_EXEC_CLASS_INSTANCE)
+ return eb_select_engine_class_instance(dev_priv, args);
+
if (user_ring_id > I915_USER_RINGS) {
DRM_DEBUG("execbuf with unknown ring: %u\n", user_ring_id);
return NULL;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c8647cfa81ba..834673c9ee6b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -95,6 +95,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define VIDEO_ENHANCEMENT_CLASS2
#define COPY_ENGINE_CLASS 3
#define OTHER_CLASS4
+#define MAX_ENGINE_CLASS 4
+
+#define MAX_ENGINE_INSTANCE1
/* PCI config space */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 3b46c1f7b88b..93466761ebd6 100644
--- a/
[Intel-gfx] [RFC 2/2] drm/i915: Engine capabilities uAPI
From: Tvrtko Ursulin
This is a lighter-weight alternative to the previously posted
RFC titled "drm/i915: Engine discovery uAPI" which still allows
some engine configuration probing without depending on PCI ids.
Signed-off-by: Tvrtko Ursulin
Cc: Ben Widawsky
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: "Rogozhkin, Dmitry V"
Cc: Oscar Mateo
Cc: "Gong, Zhipeng"
Cc: intel-vaapi-me...@lists.01.org
--
Floating as an alternative to the heavier engine discovery API
sent previously which did not manage to gain much interest from
userspace clients.
With this one enumeration and feature discovery would be done by
sending null batches to all engine instances. Downside is less
extensibility if we are using a fixed and smaller number of eb
flags.
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
include/uapi/drm/i915_drm.h| 17 -
4 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 00c363a801cb..d34db9dc5870 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2062,6 +2062,9 @@ eb_select_engine_class_instance(struct drm_i915_private
*i915,
struct drm_i915_gem_execbuffer2 *args)
{
u8 class = args->flags & I915_EXEC_RING_MASK;
+ u8 caps = (args->flags & I915_EXEC_ENGINE_CAP_MASK) >>
+ I915_EXEC_ENGINE_CAP_SHIFT;
+ struct intel_engine_cs *engine;
u8 instance;
if (class >= ARRAY_SIZE(user_class_map))
@@ -2070,7 +2073,12 @@ eb_select_engine_class_instance(struct drm_i915_private
*i915,
instance = (args->flags & I915_EXEC_INSTANCE_MASK) >>
I915_EXEC_INSTANCE_SHIFT;
- return intel_engine_lookup(i915, user_class_map[class], instance);
+ engine = intel_engine_lookup(i915, user_class_map[class], instance);
+
+ if (!engine || ((caps & engine->caps) != caps))
+ return NULL;
+
+ return engine;
}
#define I915_USER_RINGS (4)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 93466761ebd6..77dcc1150f7d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -222,6 +222,9 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->irq_shift = info->irq_shift;
engine->class = info->class;
engine->instance = info->instance;
+ if (INTEL_GEN(dev_priv) >= 8 && engine->class == VIDEO_DECODE_CLASS &&
+ engine->instance == 0)
+ engine->caps = I915_BSD_CAP_HEVC;
engine->context_size = __intel_engine_context_size(dev_priv,
engine->class);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index c408d3d5cc80..19a27b57417d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -196,6 +196,8 @@ struct intel_engine_cs {
u8 class;
u8 instance;
+ u8 caps;
+
u32 context_size;
u32 mmio_base;
unsigned int irq_shift;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 30fec2c8fc95..e473d50cade9 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -933,7 +933,18 @@ struct drm_i915_gem_execbuffer2 {
#define I915_EXEC_INSTANCE_SHIFT (20)
#define I915_EXEC_INSTANCE_MASK(0xff <<
I915_EXEC_INSTANCE_SHIFT)
-#define __I915_EXEC_UNKNOWN_FLAGS (-((1 << 27) << 1))
+/*
+ * Inform the kernel of what engine capabilities this batch buffer
+ * requires. For example only the first VCS engine has the HEVC block.
+ *
+ * We reserve four bits for the capabilities where each can be shared
+ * between different engines. Eg. first bit can mean one feature for
+ * one engine and something else for the other.
+ */
+#define I915_EXEC_ENGINE_CAP_SHIFT (28)
+#define I915_EXEC_ENGINE_CAP_MASK (0xf << I915_EXEC_ENGINE_CAP_SHIFT)
+
+#define __I915_EXEC_UNKNOWN_FLAGS (-((1 << 31) << 1))
#define I915_EXEC_CONTEXT_ID_MASK (0x)
#define i915_execbuffer2_set_context_id(eb2, context) \
@@ -941,6 +952,10 @@ struct drm_i915_gem_execbuffer2 {
#define i915_execbuffer2_get_context_id(eb2) \
((eb2).rsvd1 & I915_EXEC_CONTEXT_ID_MASK)
+#define I915_BSD_CAP_HEVC (1 << 0)
+
+#define I915_ENGINE_CAP_FLAG(v)((v) << I915_EXEC_ENGINE_CAP_SHIFT)
+
enum drm_i915_gem_engine_class {
I915_ENGINE_CLASS_OTHER = 0,
I915_ENGINE_CLASS_RENDER = 1,
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo
Re: [Intel-gfx] [PATCH] drm/i915: select CRC32
Quoting Daniel Vetter (2017-06-21 10:13:41) > On Wed, Jun 21, 2017 at 04:34:20PM +1000, Nicholas Piggin wrote: > > kbuild test robot found a build failure when building with thin > > archives: > > > > http://marc.info/?l=linux-kbuild&m=149802285009737&w=2 > > > > Signed-off-by: Nicholas Piggin > > Pushed to drm-intel for 4.14, thanks. Probably deserves to be in fixes if we identify what introduced the CRC dep. mst-dp? pipe crc? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/atomic-helper: Simplify commit tracking locking
The crtc->commit_lock only protects commit_list and commit_entry. If
we chase the pointer from the drm_atomic_state update structure, then
we don't need any locks (since we hold a reference already).
Simplify the locking accordingly.
Noticed while reviewing a patch from Boris.
Cc: Boris Brezillon
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 86d3093c6c9b..9bf86eb87fe1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1680,9 +1680,7 @@ void drm_atomic_helper_commit_hw_done(struct
drm_atomic_state *old_state)
/* backend must have consumed any event by now */
WARN_ON(new_crtc_state->event);
- spin_lock(&crtc->commit_lock);
complete_all(&commit->hw_done);
- spin_unlock(&crtc->commit_lock);
}
}
EXPORT_SYMBOL(drm_atomic_helper_commit_hw_done);
@@ -1711,7 +1709,6 @@ void drm_atomic_helper_commit_cleanup_done(struct
drm_atomic_state *old_state)
if (WARN_ON(!commit))
continue;
- spin_lock(&crtc->commit_lock);
complete_all(&commit->cleanup_done);
WARN_ON(!try_wait_for_completion(&commit->hw_done));
@@ -1721,8 +1718,6 @@ void drm_atomic_helper_commit_cleanup_done(struct
drm_atomic_state *old_state)
if (try_wait_for_completion(&commit->flip_done))
goto del_commit;
- spin_unlock(&crtc->commit_lock);
-
/* We must wait for the vblank event to signal our completion
* before releasing our reference, since the vblank work does
* not hold a reference of its own. */
@@ -1732,8 +1727,8 @@ void drm_atomic_helper_commit_cleanup_done(struct
drm_atomic_state *old_state)
DRM_ERROR("[CRTC:%d:%s] flip_done timed out\n",
crtc->base.id, crtc->name);
- spin_lock(&crtc->commit_lock);
del_commit:
+ spin_lock(&crtc->commit_lock);
list_del(&commit->commit_entry);
spin_unlock(&crtc->commit_lock);
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Retire the VMA's fence tracker before unbinding
On 20/06/2017 17:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-06-20 16:55:12)
On 20/06/2017 13:43, Chris Wilson wrote:
Since we may track unfenced access (GPU access to the vma that
explicitly requires no fence), vma->last_fence may be set without any
Is this the gen < 4 code path? There is no actual fence in this case?
Yes, this is for old hw that used a fence for GPU access, and in this
case indeed there is no fence and we are tracking the access for when
the fence is not wanted to ensure that don't install a fence before the
GPU finished accessing the region.
attached fence (vma->fence) and so will not be flushed when we call
i915_vma_put_fence(). Since we stopped doing a full retire of the
activity trackers for unbind, we need to explicitly retire each tracker.
Fixes: b0decaf75bd9 ("drm/i915: Track active vma requests")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_vma.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 532c709febbd..1cfe137cdc32 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -672,6 +672,11 @@ int i915_vma_unbind(struct i915_vma *vma)
break;
}
+ if (!ret) {
+ ret = i915_gem_active_retire(&vma->last_fence,
+
&vma->vm->i915->drm.struct_mutex);
+ }
+
__i915_vma_unpin(vma);
if (ret)
return ret;
Looks safe anyway, but I'd like to understand how exactly it happens and
if it is still possible after patch 2/3.
For gen2/3, we still use last_fence. For others it was accidental and
should be no more after patch 2. I considered add a GEM_BUG_ON to
i915_move_to_active but didn't have a convenient i915 pointer, and I
have grander plans :)
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 09/13] drm/shmob: Drop drm_vblank_cleanup
Hi Daniel,
Thank you for the patch.
On Wednesday 21 Jun 2017 10:28:46 Daniel Vetter wrote:
> It doesn't do anything in the driver load error paths that the drm
> core doesn't also do.
If I understand the code correctly, this patch is fine because drm_dev_fini(),
called ultimately from drm_dev_release(), calls drm_vblank_cleanup(). The
commit message could be a bit more explicit. Apart from that,
Acked-by: Laurent Pinchart
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c index 800d1d2c435d..c2ca07357aac
> 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -277,7 +277,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
> ret = drm_irq_install(ddev, platform_get_irq(pdev, 0));
> if (ret < 0) {
> dev_err(&pdev->dev, "failed to install IRQ handler\n");
> - goto err_vblank_cleanup;
> + goto err_modeset_cleanup;
> }
>
> /*
> @@ -292,8 +292,6 @@ static int shmob_drm_probe(struct platform_device *pdev)
>
> err_irq_uninstall:
> drm_irq_uninstall(ddev);
> -err_vblank_cleanup:
> - drm_vblank_cleanup(ddev);
> err_modeset_cleanup:
> drm_kms_helper_poll_fini(ddev);
> drm_mode_config_cleanup(ddev);
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
Thanks for all the comments. I'm planning to cook the next version of this
patch set which I'd like to include all the comments and ideas. Here is the
summary:
1. How to figure the device capabilities
struct vfio_device_info {
__u32 argsz;
__u32 flags;
#define VFIO_DEVICE_FLAGS_RESET (1 << 0)/* Device supports reset */
#define VFIO_DEVICE_FLAGS_PCI (1 << 1)/* vfio-pci device */
#define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform device */
#define VFIO_DEVICE_FLAGS_AMBA (1 << 3)/* vfio-amba device */
#define VFIO_DEVICE_FLAGS_CCW (1 << 4)/* vfio-ccw device */
__u32 num_regions;/* Max region index + 1 */
__u32 num_irqs; /* Max IRQ index + 1 */
};
> We could use two flag bits to indicate dmabuf or graphics region support.
Could the following two works?
#define VFIO_DEVICE_FLAGS_DMABUF (1 << 5)/* vfio-dmabuf device */
#define VFIO_DEVICE_FLAGS_GFX_REGION (1 << 6)/* vfio-gfx-region
device */
2. vfio_device_gfx_plane_info
struct vfio_device_gfx_plane_info {
__u64 start;-> offset
__u64 drm_format_mod;
__u32 drm_format;
__u32 width;
__u32 height;
__u32 stride;
__u32 size;
__u32 x_pos;
__u32 y_pos;
};
> Does it make sense to have a "generation" field in the plane_info struct
> (which gets increased each time the struct changes) ?
Well, Gerd, can you share more details about how to use this field in user
mode, so that we can figure out a way to support it? Thanks.
3. vfio_device_query_gfx_plane
struct vfio_device_query_gfx_plane {
__u32 argsz;
__u32 flags;
#define VFIO_GFX_PLANE_FLAGS_REGION_ID (1 << 0)
#define VFIO_GFX_PLANE_FLAGS_PLANE_ID (1 << 1)
struct vfio_device_gfx_plane_info plane_info;
__u32 id;
__u32 plane_type;
};
So far, dmabuf use id for DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR. If
the newly added plane_type is used for this, the id field may be useless in
dmabuf usage. Do you have any idea about the usage of this id field in dmabuf
usage?
4. Two ioctl commands
VFIO_DEVICE_QUERY_GFX_PLANE
VFIO_DEVICE_GET_FD
5. > Then we should kill off the manager fd unless there are arguments that
still give it value.
Agree.
If there is anything I miss, please tell us.
Thanks.
Tina
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, June 21, 2017 7:22 AM
> To: Zhang, Tina
> Cc: Gerd Hoffmann ; intel-gfx@lists.freedesktop.org;
> linux-ker...@vger.kernel.org; Kirti Wankhede ;
> Chen, Xiaoguang ; intel-gvt-
> d...@lists.freedesktop.org; Lv, Zhiyuan ; Wang, Zhi A
> ; Wang, Zhenyu Z
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
>
> On Tue, 20 Jun 2017 23:01:53 +
> "Zhang, Tina" wrote:
>
> > > -Original Message-
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Tuesday, June 20, 2017 11:00 PM
> > > To: Gerd Hoffmann
> > > Cc: Zhang, Tina ;
> > > intel-gfx@lists.freedesktop.org; linux- ker...@vger.kernel.org;
> > > Kirti Wankhede ; Chen, Xiaoguang
> > > ; intel-gvt-...@lists.freedesktop.org;
> > > Lv, Zhiyuan ; Wang, Zhi A
> > > ; Wang, Zhenyu Z
> > > Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based
> > > dma-buf operations
> > >
> > > On Tue, 20 Jun 2017 12:57:36 +0200
> > > Gerd Hoffmann wrote:
> > >
> > > > On Tue, 2017-06-20 at 08:41 +, Zhang, Tina wrote:
> > > > > Hi,
> > > > >
> > > > > Thanks for all the comments. Here are the summaries:
> > > > >
> > > > > 1. Modify the structures to make it more general.
> > > > > struct vfio_device_gfx_plane_info {
> > > > > __u64 start;
> > > > > __u64 drm_format_mod;
> > > > > __u32 drm_format;
> > > > > __u32 width;
> > > > > __u32 height;
> > > > > __u32 stride;
> > > > > __u32 size;
> > > > > __u32 x_pos;
> > > > > __u32 y_pos;
> > > > > __u32 generation;
> > > > > };
> > > >
> > > > Looks good to me.
> > > >
> > > > > struct vfio_device_query_gfx_plane {
> > > > > __u32 argsz;
> > > > > __u32 flags;
> > > > > #define VFIO_GFX_PLANE_FLAGS_REGION_ID(1 << 0)
> > > > > #define VFIO_GFX_PLANE_FLAGS_PLANE_ID (1 << 1)
> > > > > struct vfio_device_gfx_plane_info plane_info;
> > > > > __u32 id;
> > > > > };
> > > >
> > > > I'm not convinced the flags are a great idea. Whenever dmabufs or
> > > > a region is used is a static property of the device, not of each
> > > > individual plane.
> > > >
> > > >
> > > > I think we should have this for userspace to figure:
> > > >
> > > > enum vfio_device_gfx_type {
> > > > VFIO_DEVICE_GFX_NONE,
> > > > VFIO_DEVICE_GFX_DMABUF,
> > > > VFIO_DEVICE_GFX_REGION,
> > > > };
> > > >
> > > > struct vfio_device_gfx_query_caps {
> > > > __u32 argsz;
> > > > __u32 flags;
> > > >
Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex for per-file stats in debugfs/i915_gem_object
On 17/06/2017 12:57, Chris Wilson wrote:
As we walk the obj->vma_list in per_file_stats(), we need to hold
struct_mutex to prevent alteration of that list.
Fixes: 1d2ac403ae3b ("drm: Protect dev->filelist with its own mutex")
Fixes: c84455b4bacc ("drm/i915: Move debug only per-request pid tracking from
request to ctx")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101460
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4577b0af6886..3f44076ec8a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -292,6 +292,8 @@ static int per_file_stats(int id, void *ptr, void *data)
struct file_stats *stats = data;
struct i915_vma *vma;
+ lockdep_assert_held(&obj->base.dev->struct_mutex);
+
stats->count++;
stats->total += obj->base.size;
if (!obj->bind_count)
@@ -476,6 +478,8 @@ static int i915_gem_object_info(struct seq_file *m, void
*data)
struct drm_i915_gem_request *request;
struct task_struct *task;
+ mutex_lock(&dev->struct_mutex);
Could have put it just before the spin_lock for maximum OCD but doesn't
matter. ;)
+
memset(&stats, 0, sizeof(stats));
stats.file_priv = file->driver_priv;
spin_lock(&file->table_lock);
@@ -487,7 +491,6 @@ static int i915_gem_object_info(struct seq_file *m, void
*data)
* still alive (e.g. get_pid(current) => fork() => exit()).
* Therefore, we need to protect this ->comm access using RCU.
*/
- mutex_lock(&dev->struct_mutex);
request = list_first_entry_or_null(&file_priv->mm.request_list,
struct drm_i915_gem_request,
client_link);
@@ -497,6 +500,7 @@ static int i915_gem_object_info(struct seq_file *m, void
*data)
PIDTYPE_PID);
print_file_stats(m, task ? task->comm : "", stats);
rcu_read_unlock();
+
mutex_unlock(&dev->struct_mutex);
}
mutex_unlock(&dev->filelist_mutex);
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] drm/i915: Hold struct_mutex for per-file stats in debugfs/i915_gem_object
Quoting Tvrtko Ursulin (2017-06-21 10:22:00) > > On 17/06/2017 12:57, Chris Wilson wrote: > > @@ -476,6 +478,8 @@ static int i915_gem_object_info(struct seq_file *m, > > void *data) > > struct drm_i915_gem_request *request; > > struct task_struct *task; > > > > + mutex_lock(&dev->struct_mutex); > > Could have put it just before the spin_lock for maximum OCD but doesn't > matter. ;) I was thinking that because it now covered a couple of locks, it should have some whitespace between itself and those other locks so that it didn't look coupled to either. > > + > > memset(&stats, 0, sizeof(stats)); > > stats.file_priv = file->driver_priv; > > spin_lock(&file->table_lock); > > @@ -487,7 +491,6 @@ static int i915_gem_object_info(struct seq_file *m, > > void *data) > >* still alive (e.g. get_pid(current) => fork() => exit()). > >* Therefore, we need to protect this ->comm access using RCU. > >*/ > > - mutex_lock(&dev->struct_mutex); > > request = > > list_first_entry_or_null(&file_priv->mm.request_list, > > struct > > drm_i915_gem_request, > > client_link); > > @@ -497,6 +500,7 @@ static int i915_gem_object_info(struct seq_file *m, > > void *data) > > PIDTYPE_PID); > > print_file_stats(m, task ? task->comm : "", stats); > > rcu_read_unlock(); > > + > > mutex_unlock(&dev->struct_mutex); > > } > > mutex_unlock(&dev->filelist_mutex); > > > > Reviewed-by: Tvrtko Ursulin Much appreciated, pushed. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/meta_test: Add another test for igt + dmesg warn
When looking at 101518 I've noticed that piglit's html summary correctly
identifies warnings that are from stderr and dmesg. However CI doesn't
handle this correctly yet and doesn't get the dmesg errors.
Cc: Marta Löfstedt
Cc: Petri Latvala
Cc: Martin Peres
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518
Signed-off-by: Maarten Lankhorst
---
tests/intel-ci/meta.testlist | 1 +
tests/meta_test.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/tests/intel-ci/meta.testlist b/tests/intel-ci/meta.testlist
index 2ec3db58a409..6eedf43fd423 100644
--- a/tests/intel-ci/meta.testlist
+++ b/tests/intel-ci/meta.testlist
@@ -1,5 +1,6 @@
igt@meta_test@pass-result
igt@meta_test@warn
+igt@meta_test@igt-warn-and-dmesg-warn
igt@meta_test@fail-result
igt@meta_test@dmesg-pass
igt@meta_test@dmesg-warn
diff --git a/tests/meta_test.c b/tests/meta_test.c
index a67b4c5e113f..7186b408b520 100644
--- a/tests/meta_test.c
+++ b/tests/meta_test.c
@@ -134,6 +134,12 @@ igt_main
test_result(true);
}
+ igt_subtest("igt-warn-and-dmesg-warn") {
+ igt_warn("This is a test with a igt warning that should show a
dmesg warning too.\n");
+
+ test_dmesg(false);
+ }
+
igt_subtest("fail-result")
test_result(false);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Retire the VMA's fence tracker before unbinding
Quoting Tvrtko Ursulin (2017-06-21 10:17:49)
>
> On 20/06/2017 17:05, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-06-20 16:55:12)
> >>
> >> On 20/06/2017 13:43, Chris Wilson wrote:
> >>> Since we may track unfenced access (GPU access to the vma that
> >>> explicitly requires no fence), vma->last_fence may be set without any
> >>
> >> Is this the gen < 4 code path? There is no actual fence in this case?
> >
> > Yes, this is for old hw that used a fence for GPU access, and in this
> > case indeed there is no fence and we are tracking the access for when
> > the fence is not wanted to ensure that don't install a fence before the
> > GPU finished accessing the region.
> >
> >>> attached fence (vma->fence) and so will not be flushed when we call
> >>> i915_vma_put_fence(). Since we stopped doing a full retire of the
> >>> activity trackers for unbind, we need to explicitly retire each tracker.
> >>>
> >>> Fixes: b0decaf75bd9 ("drm/i915: Track active vma requests")
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Joonas Lahtinen
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/i915_vma.c | 5 +
> >>>1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_vma.c
> >>> b/drivers/gpu/drm/i915/i915_vma.c
> >>> index 532c709febbd..1cfe137cdc32 100644
> >>> --- a/drivers/gpu/drm/i915/i915_vma.c
> >>> +++ b/drivers/gpu/drm/i915/i915_vma.c
> >>> @@ -672,6 +672,11 @@ int i915_vma_unbind(struct i915_vma *vma)
> >>>break;
> >>>}
> >>>
> >>> + if (!ret) {
> >>> + ret = i915_gem_active_retire(&vma->last_fence,
> >>> +
> >>> &vma->vm->i915->drm.struct_mutex);
> >>> + }
> >>> +
> >>>__i915_vma_unpin(vma);
> >>>if (ret)
> >>>return ret;
> >>>
> >>
> >> Looks safe anyway, but I'd like to understand how exactly it happens and
> >> if it is still possible after patch 2/3.
> >
> > For gen2/3, we still use last_fence. For others it was accidental and
> > should be no more after patch 2. I considered add a GEM_BUG_ON to
> > i915_move_to_active but didn't have a convenient i915 pointer, and I
> > have grander plans :)
>
> Reviewed-by: Tvrtko Ursulin
Thanks for accepting my poor grammar :)
Pushed the remaining pair,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Addition wrapper for fixed16.16 operation
Mahesh Kumar schreef op wo 21-06-2017 om 11:44 [+0530]: > This patch introduce addition wrapper for fixed point 16.16 > operations. > Which will be used by later patches to avoid direct member variables > access of fixed_16_16_t structure. > > add_fixed16 : takes 2 fixed_16_16_t variable & returns fixed_16_16_t > add_fixed16_u32 : takes fixed_16_16_t & u32 variable & returns > fixed_16_16_t Much easier to review. :) Reviewed-by: Maarten Lankhorst for first 4 patches. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Engine capabilities uAPI
Quoting Tvrtko Ursulin (2017-06-21 10:13:57) > From: Tvrtko Ursulin > > This is a lighter-weight alternative to the previously posted > RFC titled "drm/i915: Engine discovery uAPI" which still allows > some engine configuration probing without depending on PCI ids. > > Signed-off-by: Tvrtko Ursulin > Cc: Ben Widawsky > Cc: Chris Wilson > Cc: Daniel Vetter > Cc: Joonas Lahtinen > Cc: Jon Bloomfield > Cc: "Rogozhkin, Dmitry V" > Cc: Oscar Mateo > Cc: "Gong, Zhipeng" > Cc: intel-vaapi-me...@lists.01.org > -- > Floating as an alternative to the heavier engine discovery API > sent previously which did not manage to gain much interest from > userspace clients. > > With this one enumeration and feature discovery would be done by > sending null batches to all engine instances. Downside is less > extensibility if we are using a fixed and smaller number of eb > flags. But we lose out on features? Just after you convinced me that features was what we wanted! :-p -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt PATCH] igt/pm_rps: Remove remaining assert on CUR <= MAX
On Tue, Jun 20, 2017 at 06:15:52PM +0300, Arkadiusz Hiler wrote: > On Tue, Jun 20, 2017 at 01:54:54PM +, Szwichtenberg, Radoslaw wrote: > > On Wed, 2017-06-14 at 12:44 -0700, jeff.mc...@intel.com wrote: > > > From: Jeff McGee > > > > > > This completes the change started by: > > > > > > commit 39cccab83b7c515a2b57abe679a8cb304c8933ef > > > Author: Chris Wilson > > > Date: Fri May 19 09:41:40 2017 +0100 > > > > > > igt/pm_rps: Allow CUR to be greater than MAX (overclocking) > > > > > > Cc: Chris Wilson > > > Signed-off-by: Jeff McGee > > Reviewed-by: Radoslaw Szwichtenberg > > Pushed. Thanks for the patch and the review. > > Excerpt from CONTRIBUTING: > - > Please use --subject-prefix="PATCH i-g-t" so that i-g-t patches are easily > identified in the massive amount mails on intel-gfx. To ensure this is always > done, autogen.sh will run: > > git config format.subjectprefix "PATCH i-g-t" > > on its first invocation. > - > > Lack of proper prefix breaks filtering / patchwork and makes changes > harder to track, and effectilvely it takes longer to get the patch in. > > The autogen.sh thing is a recent addition. Hey Jeff, The change has been reverted. At first the it looked like a sensible folloup to previous changes and it even got r-bed, but as pointed out by Michal, this constraint still should hold, as it's checked in a non-boost scenario. It hides bug introduced into the kernel by the commit: "drm/i915: Define a separate variable and control for RPS waitboost frequency" for GuC submission path, as the check below always holds true as we have waiters all the time: if (client_boost || any_waiters) max = hw_max; What was the point of this change? Were you aware of the fail in the guc_submission scenario? -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] i915/gvt: Add MIPI DSI support
From: Vivek Kasireddy
In addition to adding the registers asscociated with MIPI DSI
encoder/connector, we also ensure intel_bios_init() function
gets called before intel_gvt_init() so that we can detect the presence
of MIPI DSI from the VBT and decide whether to read the releveant
registers or not. This is needed because if we read MIPI registers
when it is not present, this leads to a hang.
Also, since PIPECONF register reads 0x0 when MIPI DSI is enabled,
we try to augment functions like pipe_is_enabled() to ensure that
Vblank and Flip done events are forwarded to DomU by calling
intel_bios_is_dsi_present(). We do similar thing with plane
surface and MMIO write handler as well.
Signed-off-by: Vivek Kasireddy
Reviewed-by: He, Min
---
drivers/gpu/drm/i915/gvt/display.c | 277 ++--
drivers/gpu/drm/i915/gvt/handlers.c | 1317 ++-
drivers/gpu/drm/i915/i915_drv.c |8 +-
drivers/gpu/drm/i915/i915_irq.c | 17 +-
4 files changed, 1242 insertions(+), 377 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index 6d8fde8..8d9f329 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -55,6 +55,20 @@ static int get_edp_pipe(struct intel_vgpu *vgpu)
return pipe;
}
+int get_dsi_pipe(struct intel_vgpu *vgpu)
+{
+ struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
+ u32 data = vgpu_vreg(vgpu, _MIPIA_CTRL);
+
+ data &= BXT_PIPE_SELECT_MASK;
+ data >>= BXT_PIPE_SELECT_SHIFT;
+
+ if (data > PIPE_C)
+ return -1;
+ else
+ return data;
+}
+
static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
{
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
@@ -80,58 +94,117 @@ static int pipe_is_enabled(struct intel_vgpu *vgpu, int
pipe)
if (edp_pipe_is_enabled(vgpu) &&
get_edp_pipe(vgpu) == pipe)
return 1;
+
+ if (intel_bios_is_dsi_present(dev_priv, NULL) &&
+ get_dsi_pipe(vgpu) == pipe)
+ return 1;
+
return 0;
}
+static unsigned char virtual_dp_monitor_edid[GVT_EDID_NUM][EDID_SIZE] = {
+ {
+/* EDID with 1024x768 as its resolution */
+ /*Header*/
+ 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
+ /* Vendor & Product Identification */
+ 0x22, 0xf0, 0x54, 0x29, 0x00, 0x00, 0x00, 0x00, 0x04, 0x17,
+ /* Version & Revision */
+ 0x01, 0x04,
+ /* Basic Display Parameters & Features */
+ 0xa5, 0x34, 0x20, 0x78, 0x23,
+ /* Color Characteristics */
+ 0xfc, 0x81, 0xa4, 0x55, 0x4d, 0x9d, 0x25, 0x12, 0x50, 0x54,
+ /* Established Timings: maximum resolution is 1024x768 */
+ 0x21, 0x08, 0x00,
+ /* Standard Timings. All invalid */
+ 0x00, 0xc0, 0x00, 0xc0, 0x00, 0x40, 0x00, 0x80, 0x00, 0x00,
+ 0x00, 0x40, 0x00, 0x00, 0x00, 0x01,
+ /* 18 Byte Data Blocks 1: invalid */
+ 0x00, 0x00, 0x80, 0xa0, 0x70, 0xb0,
+ 0x23, 0x40, 0x30, 0x20, 0x36, 0x00, 0x06, 0x44, 0x21, 0x00,
0x00, 0x1a,
+ /* 18 Byte Data Blocks 2: invalid */
+ 0x00, 0x00, 0x00, 0xfd, 0x00, 0x18, 0x3c, 0x18, 0x50, 0x11,
0x00, 0x0a,
+ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+ /* 18 Byte Data Blocks 3: invalid */
+ 0x00, 0x00, 0x00, 0xfc, 0x00, 0x48,
+ 0x50, 0x20, 0x5a, 0x52, 0x32, 0x34, 0x34, 0x30, 0x77, 0x0a,
0x20, 0x20,
+ /* 18 Byte Data Blocks 4: invalid */
+ 0x00, 0x00, 0x00, 0xff, 0x00, 0x43, 0x4e, 0x34, 0x33, 0x30,
0x34, 0x30,
+ 0x44, 0x58, 0x51, 0x0a, 0x20, 0x20,
+ /* Extension Block Count */
+ 0x00,
+ /* Checksum */
+ 0xef,
+ },
+ {
/* EDID with 1920x1200 as its resolution */
-static unsigned char virtual_dp_monitor_edid[] = {
- /*Header*/
- 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
- /* Vendor & Product Identification */
- 0x22, 0xf0, 0x54, 0x29, 0x00, 0x00, 0x00, 0x00, 0x04, 0x17,
- /* Version & Revision */
- 0x01, 0x04,
- /* Basic Display Parameters & Features */
- 0xa5, 0x34, 0x20, 0x78, 0x23,
- /* Color Characteristics */
- 0xfc, 0x81, 0xa4, 0x55, 0x4d, 0x9d, 0x25, 0x12, 0x50, 0x54,
- /* Established Timings: maximum resolution is 1024x768 */
- 0x21, 0x08, 0x00,
- /*
-* Standard Timings.
-* below new resolutions can be supported:
-* 1920x1080, 1280x720, 1280x960, 1280x1024,
-* 1440x900, 1600x1200, 1680x1050
-*/
- 0xd1, 0xc0, 0x81, 0xc0, 0x81, 0x40, 0x81, 0x80, 0x95, 0x00,
- 0xa9, 0x40, 0xb3, 0x00, 0x01, 0x01,
- /* 18 Byte Data Blocks 1: max resolution is 1920x1200
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/2] drm/i915: Select engines via class and instance in execbuffer2
== Series Details == Series: series starting with [RFC,1/2] drm/i915: Select engines via class and instance in execbuffer2 URL : https://patchwork.freedesktop.org/series/26126/ State : success == Summary == Series 26126v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/26126/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-r) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-n2820) fdo#101516 Test prime_busy: Subgroup basic-wait-after-default: pass -> DMESG-WARN (fi-skl-6700hq) fdo#101515 +3 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101516 https://bugs.freedesktop.org/show_bug.cgi?id=101516 fdo#101515 https://bugs.freedesktop.org/show_bug.cgi?id=101515 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:427s fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:521s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-byt-j1900 total:278 pass:252 dwarn:2 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:278 pass:248 dwarn:2 dfail:0 fail:0 skip:28 time:478s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:589s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:437s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:423s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:504s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:568s fi-kbl-r total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:576s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:337s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:465s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:479s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:431s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:401s bc07bd0717fe93acecc098863106b7e29fd84079 drm-tip: 2017y-06m-21d-09h-31m-50s UTC integration manifest 7882c7d drm/i915: Engine capabilities uAPI 6fdc1ca drm/i915: Select engines via class and instance in execbuffer2 == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5007/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Replace execbuf vma ht with an idr
Quoting Tvrtko Ursulin (2017-06-20 12:26:44)
>
> On 16/06/2017 17:02, Chris Wilson wrote:
> > -static void resize_vma_ht(struct work_struct *work)
> > +static void lut_close(struct i915_gem_context *ctx)
> > {
> > - struct i915_gem_context_vma_lut *lut =
> > - container_of(work, typeof(*lut), resize);
> > - unsigned int bits, new_bits, size, i;
> > - struct hlist_head *new_ht;
> > -
> > - GEM_BUG_ON(!(lut->ht_size & I915_CTX_RESIZE_IN_PROGRESS));
> > -
> > - bits = 1 + ilog2(4*lut->ht_count/3 + 1);
> > - new_bits = min_t(unsigned int,
> > - max(bits, VMA_HT_BITS),
> > - sizeof(unsigned int) * BITS_PER_BYTE - 1);
> > - if (new_bits == lut->ht_bits)
> > - goto out;
> > -
> > - new_ht = kzalloc(sizeof(*new_ht)< > __GFP_NOWARN);
> > - if (!new_ht)
> > - new_ht = vzalloc(sizeof(*new_ht)< > - if (!new_ht)
> > - /* Pretend resize succeeded and stop calling us for a bit! */
> > - goto out;
> > + struct i915_lut_handle *lut, *ln;
> > + struct radix_tree_iter iter;
> > + void __rcu **slot;
> >
> > - size = BIT(lut->ht_bits);
> > - for (i = 0; i < size; i++) {
> > - struct i915_vma *vma;
> > - struct hlist_node *tmp;
> > -
> > - hlist_for_each_entry_safe(vma, tmp, &lut->ht[i], ctx_node)
> > - hlist_add_head(&vma->ctx_node,
> > -&new_ht[hash_32(vma->ctx_handle,
> > -new_bits)]);
> > + list_for_each_entry_safe(lut, ln, &ctx->handles_list, ctx_link) {
> > + list_del(&lut->obj_link);
> I assume you deliberately did not bother unlinking from the ctx list
> since all that is getting zapped anyway?
Yes, it is not obvious though. The context is marked as closed so we
should thereafter prevent further usage of the ctx->handles_list.
At the moment, this is governed by struct_mutex but in the future it is
likely to be replaced by file->mutex or ctx->mutex.
If I add a GEM_BUG_ON(eb->ctx->closed) to eb_lookup_vmas that should
help explain the relationship.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND-CI v4 00/15] HDMI YCBCR output handling in DRM layer
This patch series adds support for YCBCR HDMI output handling in DRM layer. The main aim of this patch series was to handle YCBCR 4:2:0 output for HDMI 2.0 displays. But while providing a framework to handle non-RGB outputs, support for YCBCR 4:4:4 and 4:2:2 was also added. First 2 patches, complete the CEA mode-db in drm driver, by adding new 4k modes. Current CEA mode-db contains 64 modes only (VIC 1-64), whereas CEA-861-F defined VICs up to 107, including 4k modes, from VIC range 93-107. First patch makes sure that inclusion of these modes doesn't break existing HDMI 1.4 monitors, across various drivers. Next 3 patches focus on parsing new YCBCR 4:2:0 EDID blocks, and adding YCBCR 4:2:0 modes in connector (only for connectors who declare themselves as HDMI 2.0 compliant during init) Next 6 patch create a property (hdmi_output_format) and add the framework to handle the HDMI output type defined in the property. There are also some helper functions provided, to help with the YCBCR HDMI output, like adding deep color information, set color space and get the appropriate YCBCR output based on source + sink capabilities. A User can set the HDMI output property, and select the desired output from YCBCR 4:4:4, 4:2:2 or 4:2:0. A driver can use framework's helper functions to check if this source + sink + mode combination can drive the desired output, or what would be the best suitable output. By default the value of the property is default RGB, so if you don't set the property, there is no change in the regular functionality of an existing source. More details are available with respective patches. Last 6 patches add the I915 core implementation of the HDMI output handling. This patch series was tested with a GLK device, ACER S277HK monitor and ASTRO VA-1844A HDMI analyzer. V3: Added a new patch to introduce YCBCR_420_allowed identifier. V4: Added a new patch to re-sequence sink info parsing befor CEA modes. V4-RESEND-CI: Added V5 for patch 7, to fix CI regression, no change elsewhere. Shashank Sharma (15): drm: add HDMI 2.0 VIC support for AVI info-frames drm: add YCBCR 420 capability identifier drm/edid: Complete CEA modedb(VIC 1-107) drm/edid: parse YCBCR 420 videomodes from EDID drm/edid: parse ycbcr 420 deep color information drm/edid: parse sink information before CEA blocks drm: create hdmi output property drm: set output colorspace in AVI infoframe drm: add helper functions for YCBCR output handling drm/i915: add compute-config for YCBCR outputs drm/i915: prepare scaler for YCBCR420 modeset drm/i915: prepare pipe for YCBCR output drm/i915: prepare csc unit for YCBCR HDMI output drm/i915: set colorspace for ycbcr outputs drm/i915/glk: set HDMI 2.0 identifier drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/drm_atomic.c | 4 + drivers/gpu/drm/drm_atomic_helper.c | 4 + drivers/gpu/drm/drm_connector.c | 32 +++ drivers/gpu/drm/drm_edid.c| 462 +- drivers/gpu/drm/drm_modes.c | 307 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 3 + drivers/gpu/drm/i915/intel_atomic.c | 6 + drivers/gpu/drm/i915/intel_color.c| 47 ++- drivers/gpu/drm/i915/intel_display.c | 68 + drivers/gpu/drm/i915/intel_drv.h | 13 +- drivers/gpu/drm/i915/intel_hdmi.c | 131 - drivers/gpu/drm/i915/intel_panel.c| 3 +- drivers/gpu/drm/i915/intel_sdvo.c | 3 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +- drivers/gpu/drm/omapdrm/omap_encoder.c| 3 +- drivers/gpu/drm/radeon/radeon_audio.c | 2 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- drivers/gpu/drm/sti/sti_hdmi.c| 2 +- drivers/gpu/drm/tegra/hdmi.c | 2 +- drivers/gpu/drm/tegra/sor.c | 2 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- drivers/gpu/drm/zte/zx_hdmi.c | 2 +- include/drm/drm_connector.h | 50 include/drm/drm_edid.h| 14 +- include/drm/drm_mode_config.h | 5 + include/drm/drm_modes.h | 5 + 34 files changed, 1159 insertions(+), 34 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND-CI v4 03/15] drm/edid: Complete CEA modedb(VIC 1-107)
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).
This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).
The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Andrzej Hajda
Cc: Alex Deucher
Cc: Harry Wentland
V2: Rebase
V3: Rebase
V4: Added native bit handling as per CEA-861-F spec (Ville)
Reviewed-by: Jose Abreu
Reviewed-by: Alex Deucher
Acked-by: Harry Wentland
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 227 -
1 file changed, 226 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d312fe1..e2d1b30 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] =
{
2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 65 - 1280x720@24Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+ 3080, 3300, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 66 - 1280x720@25Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+ 3740, 3960, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 67 - 1280x720@30Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+ 3080, 3300, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 68 - 1280x720@50Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+ 1760, 1980, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 69 - 1280x720@60Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+ 1430, 1650, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 70 - 1280x720@100Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+ 1760, 1980, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 71 - 1280x720@120Hz */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+ 1430, 1650, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 72 - 1920x1080@24Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+ 2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 73 - 1920x1080@25Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+ 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 74 - 1920x1080@30Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+ 2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 75 - 1920x1080@50Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+ 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 76 - 1920x1080@60Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+ 2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+
[Intel-gfx] [RESEND-CI v4 01/15] drm: add HDMI 2.0 VIC support for AVI info-frames
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
As CEA-861-F has already defined VICs for 4K videomodes, this
patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
until the mode is 3D.
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Andrzej Hajda
Cc: Alex Deucher
Cc: Daniel Vetter
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
send only one of it.
Reviewed-by: Andrzej Hajda
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
drivers/gpu/drm/drm_edid.c| 12 +++-
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c | 17 -
drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
drivers/gpu/drm/tegra/hdmi.c | 2 +-
drivers/gpu/drm/tegra/sor.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
include/drm/drm_edid.h| 3 ++-
21 files changed, 50 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 3c62c45..4923ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c8ed0fa..4101684 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3e90c19..a7f6b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
- err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+ err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index 9006578..a083211 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge
*bridg
[Intel-gfx] [RESEND-CI v4 02/15] drm: add YCBCR 420 capability identifier
This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
structure. While handling the EDID from HDMI 2.0 sinks, its important to
know if the source is capable of handling YCBCR 420 outputs or not, so that
a lot of work can be done/bypassed based on this information. One such
example is adding YCBCR420 only modes.
If the driver knows that this source is not HDMI 2.0 capable, it will
not add YCBCR420-only modes while adding EDID modes, and will prevent
any runtime modeset failures.
This variable will be initialized from I915 driver in the next patch
and will be used in the EDID handling for HDMI 2.0 specific features,
in this same series.
V3: introduced the new variable
V4: changed variable name from is_hdmi2_src to ycbcr_420_allowed (Ville)
Signed-off-by: Shashank Sharma
---
include/drm/drm_connector.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index d8bb25f..7493fd3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -728,6 +728,15 @@ struct drm_connector {
bool interlace_allowed;
bool doublescan_allowed;
bool stereo_allowed;
+
+ /**
+* @ycbcr_420_allowed : This bool indicates if this connector is
+* capable of handling YCBCR 420 output. While parsing the EDID
+* blocks, its very helpful to know, if the source is capable of
+* handling YCBCR 420 outputs.
+*/
+ bool ycbcr_420_allowed;
+
/**
* @registered: Is this connector exposed (registered) with userspace?
* Protected by @mutex.
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND-CI v4 09/15] drm: add helper functions for YCBCR output handling
This patch adds set of helper functions for YCBCR HDMI output
handling. These functions provide functionality like:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 mode.
- get the highest subsamled ycbcr output.
- get the lowest subsamled ycbcr output.
- check if a given source and sink combination can support any
YCBCR HDMI output.
- check if a given source and sink combination can support a particular
YCBCR HDMI output.
Currently all these helpers are kept static, and only one wrapper function
is exposed to callers, which is "drm_find_hdmi_output_type". This function
takes inputs as current mode, user preference and src + sink capabilities,
and provides the most suitable HDMI output format to match all of these
inputs.
This wrapper function will be used in next few patches in this
series from I915 driver.
V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.
V4: EXPORT_SYMBOL(drm_find_hdmi_output_type)
Cc: Ville Syrjala
Cc: Jose Abreu
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 2 +-
drivers/gpu/drm/drm_modes.c | 307
include/drm/drm_edid.h | 1 +
include/drm/drm_modes.h | 5 +
4 files changed, 314 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index edba190..2f8810a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2949,7 +2949,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode
*to_match)
}
EXPORT_SYMBOL(drm_match_cea_mode);
-static bool drm_valid_cea_vic(u8 vic)
+bool drm_valid_cea_vic(u8 vic)
{
return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
}
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f2493b9..09e6b10 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1576,3 +1576,310 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
out:
return ret;
}
+
+/**
+ * drm_mode_is_420_only - if a given videomode can be only supported in
YCBCR420
+ * output format
+ *
+ * @connector: drm connector under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can support YCBCR420 output
+ * false if not.
+ */
+static bool drm_mode_is_420_only(struct drm_display_info *display,
+ struct drm_display_mode *mode)
+{
+ u8 vic = drm_match_cea_mode(mode);
+
+ /*
+* Requirements of a 420_only mode:
+* must be a valid cea mode
+* entry in 420_only bitmap
+*/
+ if (!drm_valid_cea_vic(vic))
+ return false;
+
+ return test_bit(vic, display->hdmi.y420_vdb_modes);
+}
+
+/**
+ * drm_mode_is_420_also - if a given videomode can be supported in YCBCR420
+ * output format also (along with RGB/YCBCR444/422)
+ *
+ * @display: display under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can support YCBCR420 output
+ * false if not.
+ */
+static bool drm_mode_is_420_also(struct drm_display_info *display,
+ struct drm_display_mode *mode)
+{
+ u8 vic = drm_match_cea_mode(mode);
+
+ /*
+* Requirements of a 420_also mode:
+* must be a valid cea mode
+* entry in 420_also bitmap
+*/
+ if (!drm_valid_cea_vic(vic))
+ return false;
+
+ return test_bit(vic, display->hdmi.y420_cmdb_modes);
+}
+
+
+static bool drm_mode_is_420(struct drm_display_info *display,
+ struct drm_display_mode *mode)
+{
+ return drm_mode_is_420_only(display, mode) ||
+ drm_mode_is_420_also(display, mode);
+}
+
+/**
+ * drm_can_support_this_ycbcr_output - can a given source and sink combination
+ * support a particular YCBCR output type.
+ *
+ * @display: sink information.
+ * @mode: video mode from modeset
+ * @type: enum indicating YCBCR output type
+ * @source_outputs: bitmap of source supported HDMI output formats.
+ *
+ * Returns:
+ * true on success.
+ * false on failure.
+ */
+static bool drm_can_support_this_ycbcr_output(struct drm_display_info *display,
+ struct drm_display_mode *mode,
+ enum drm_hdmi_output_type type,
+ u32 source_outputs)
+{
+ /* YCBCR420 output support can be per mode basis */
+ if (type == DRM_HDMI_OUTPUT_YCBCR420 &&
+ !drm_mode_is_420(display, mode))
+ return false;
+
+ return display->color_formats & source_outputs & type;
+}
+
+/**
+ * drm_can_support_ycbcr_output - can a given source and sink combination
+ * support any YCBCR outputs ?
+ *
+ * @display: sink information.
+ * @source_outputs: bitmap of source supported HDMI output formats.
+ *
+ * Returns:
+ * true on success.
+ * false on failure.
+
[Intel-gfx] [RESEND-CI v4 10/15] drm/i915: add compute-config for YCBCR outputs
This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
V2: Split the patch into two, kept helper functions in DRM layer.
V3: Changed the compute_config function based on new DRM API.
V4: Rebase
Cc: Ville Syrjala
Cc: Daniel Vetter
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 ++
drivers/gpu/drm/i915/intel_hdmi.c| 93 ++--
3 files changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f9bf0d5..da29536 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+ PIPE_CONF_CHECK_I(hdmi_output);
PIPE_CONF_CHECK_I(has_audio);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1727350..38fe56c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -780,6 +780,9 @@ struct intel_crtc_state {
/* HDMI High TMDS char rate ratio */
bool hdmi_high_tmds_clock_ratio;
+
+ /* HDMI output type */
+ enum drm_hdmi_output_type hdmi_output;
};
struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 170abc4..22da5cd 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1317,7 +1317,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
return status;
}
-static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
+static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
+ enum drm_hdmi_output_type hdmi_out)
{
struct drm_i915_private *dev_priv =
to_i915(crtc_state->base.crtc->dev);
@@ -1329,6 +1330,16 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
if (HAS_GMCH_DISPLAY(dev_priv))
return false;
+ if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
+ /*
+* HDMI spec says YCBCR422 is 12bpc, but its not a deep
+* color format. So respect the spec, and not allow this
+* to be deep color
+*/
+ DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
+ return false;
+ }
+
/*
* HDMI 12bpc affects the clocks, so it's only possible
* when not cloning with other encoder types.
@@ -1342,6 +1353,12 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
if (connector_state->crtc != crtc_state->base.crtc)
continue;
+ if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+ if (!(info->hdmi.y420_dc_modes &
+ DRM_EDID_YCBCR420_DC_36))
+ return false;
+ }
+
if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
return false;
}
@@ -1354,6 +1371,65 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
return true;
}
+static u8
+intel_hdmi_get_src_output_support(struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = connector->dev->dev_private;
+ u8 supported_outputs = DRM_COLOR_FORMAT_RGB444;
+
+ if (dev_priv->info.gen < 7)
+ return supported_outputs;
+
+ /* Gen 7 and above support HDMI 1.4b outputs */
+ supported_outputs |= (DRM_COLOR_FORMAT_YCRCB444 |
+ DRM_COLOR_FORMAT_YCRCB422);
+
+ if (IS_GEMINILAKE(dev_priv))
+ supported_outputs |= DRM_COLOR_FORMAT_YCRCB420;
+
+ return supported_outputs;
+}
+
+static enum drm_hdmi_output_type
+intel_hdmi_compute_ycbcr_config(struct drm_connector_state *conn_state,
+ struct intel_crtc_state *config,
+ int *clock_12bpc, int *clock_8bpc)
+{
+ struct drm_connector *connector = conn_state->connector;
+ struct drm_display_mode *mode = &config->base.adjusted_mode;
+ enum drm_hdmi_output_type type = conn_state->hdmi_output;
+ u8 src_output_cap = intel_hdmi_get_src_output_support(connector);
+
+ /*
+* Can we support any YCBCR output based on these parameters ?
+* current source capabilities +
+* current sink capabilities +
+* give
[Intel-gfx] [RESEND-CI v4 12/15] drm/i915: prepare pipe for YCBCR output
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR outputs.
V2: rebase
V3: rebase
V4: rebase
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Cc: Daniel Vetter
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 88e4707..77921ec 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5196,6 +5196,9 @@ enum {
#define _PIPE_MISC_A 0x70030
#define _PIPE_MISC_B 0x71030
+#define PIPEMISC_YCBCR420_ENABLE (1<<27)
+#define PIPEMISC_YCBCR420_MODE_BLEND (1<<26)
+#define PIPEMISC_OUTPUT_YCBCR(1<<11)
#define PIPEMISC_DITHER_BPC_MASK (7<<5)
#define PIPEMISC_DITHER_8_BPC(0<<5)
#define PIPEMISC_DITHER_10_BPC (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 983f581..71fd19e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8109,6 +8109,15 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
+ if (hdmi_out > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
+ val |= PIPEMISC_OUTPUT_YCBCR;
+
+ if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+ val |= PIPEMISC_YCBCR420_ENABLE |
+ PIPEMISC_YCBCR420_MODE_BLEND;
+ }
+ }
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND-CI v4 06/15] drm/edid: parse sink information before CEA blocks
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the call to drm_add_display_info function, before the mode parsing block. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index b4583f6..42934b2 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4605,6 +4605,13 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) quirks = edid_get_quirks(edid); /* +* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. +* To avoid multiple parsing of same block, lets parse that map +* from sink info, before parsing CEA modes. +*/ + drm_add_display_info(connector, edid); + + /* * EDID spec says modes should be preferred in this order: * - preferred detailed mode * - other detailed modes from base block @@ -4632,8 +4639,6 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) edid_fixup_preferred(connector, quirks); - drm_add_display_info(connector, edid); - if (quirks & EDID_QUIRK_FORCE_6BPC) connector->display_info.bpc = 6; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND-CI v4 05/15] drm/edid: parse ycbcr 420 deep color information
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc_modes into this patch, where its used
(Ville)
Cc: Ville Syrjälä
Cc: Jose Abreu
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 15 +++
include/drm/drm_connector.h | 3 +++
include/drm/drm_edid.h | 5 +
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8c7e73b..b4583f6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4196,6 +4196,19 @@ drm_default_rgb_quant_range(const struct
drm_display_mode *mode)
}
EXPORT_SYMBOL(drm_default_rgb_quant_range);
+static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
+const u8 *db)
+{
+ struct drm_hdmi_info *info = &connector->display_info.hdmi;
+
+ if (db[7] & DRM_EDID_YCBCR420_DC_48)
+ info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_48;
+ if (db[7] & DRM_EDID_YCBCR420_DC_36)
+ info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_36;
+ if (db[7] & DRM_EDID_YCBCR420_DC_30)
+ info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_30;
+}
+
static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
const u8 *hf_vsdb)
{
@@ -4236,6 +4249,8 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
scdc->scrambling.low_rates = true;
}
}
+
+ drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ce2212d..1305fe9 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -156,6 +156,9 @@ struct drm_hdmi_info {
/** @y420_cmdb_map: bitmap of SVD index, to extraxt vcb modes */
unsigned long y420_cmdb_map;
+
+ /** @y420_dc_modes: bitmap of deep color support index */
+ u8 y420_dc_modes;
};
/**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 89c0062..d4ff17c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -213,6 +213,11 @@ struct detailed_timing {
#define DRM_EDID_HDMI_DC_30 (1 << 4)
#define DRM_EDID_HDMI_DC_Y444 (1 << 3)
+/* YCBCR 420 deep color modes */
+#define DRM_EDID_YCBCR420_DC_48 (1 << 6)
+#define DRM_EDID_YCBCR420_DC_36 (1 << 5)
+#define DRM_EDID_YCBCR420_DC_30 (1 << 4)
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND-CI v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Emil Velikov
V2: Addressed
Review comments from Emil:
- Use 1ULL< 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 157 +++-
include/drm/drm_connector.h | 20 ++
2 files changed, 174 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e2d1b30..8c7e73b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420 0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
#define EDID_BASIC_AUDIO (1 << 6)
#define EDID_CEA_YCRCB444 (1 << 5)
#define EDID_CEA_YCRCB422 (1 << 4)
@@ -3153,15 +3155,79 @@ drm_display_mode_from_vic_index(struct drm_connector
*connector,
return newmode;
}
+/*
+ * do_y420vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * Parse the CEA-861-F YCBCR 420 Video Data Block (Y420VDB)
+ * which contains modes which can be supported in YCBCR 420
+ * output format only.
+ */
+static int do_y420vdb_modes(struct drm_connector *connector,
+ const u8 *svds, u8 svds_len)
+{
+ int modes = 0, i;
+ struct drm_device *dev = connector->dev;
+ struct drm_display_info *info = &connector->display_info;
+ struct drm_hdmi_info *hdmi = &info->hdmi;
+
+ for (i = 0; i < svds_len; i++) {
+ u8 vic = svd_to_vic(svds[i]);
+ struct drm_display_mode *newmode;
+
+ newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
+ if (!newmode)
+ break;
+ bitmap_set(hdmi->y420_vdb_modes, vic, 1);
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+
+ if (modes > 0)
+ info->color_formats |= DRM_COLOR_FORMAT_YCRCB420;
+ return modes;
+}
+
+/*
+ * drm_add_cmdb_modes - Add a YCBCR 420 mode into bitmap
+ * @connector: connector correspo
[Intel-gfx] [RESEND-CI v4 08/15] drm: set output colorspace in AVI infoframe
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI infoframes.
V2: Rebase
V3: Rebase
Cc: Ville Syrjala
Cc: Jose Abreu
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 40
include/drm/drm_edid.h | 5 +
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 42934b2..edba190 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4782,6 +4782,46 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
/**
+ * drm_hdmi_avi_infoframe_set_colorspace - fill an HDMI AVI infoframe with
+ * colorspace data of the output type
+ *
+ * @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
+ * @hdmi_output: HDMI output colorspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output)
+{
+ switch (hdmi_output) {
+ case DRM_HDMI_OUTPUT_YCBCR444:
+ frame->colorspace = HDMI_COLORSPACE_YUV444;
+ break;
+ case DRM_HDMI_OUTPUT_YCBCR422:
+ frame->colorspace = HDMI_COLORSPACE_YUV422;
+ break;
+ case DRM_HDMI_OUTPUT_YCBCR420:
+ frame->colorspace = HDMI_COLORSPACE_YUV420;
+ frame->pixel_repeat = 0;
+ break;
+ case DRM_HDMI_OUTPUT_DEFAULT_RGB:
+ frame->colorspace = HDMI_COLORSPACE_RGB;
+ break;
+ case DRM_HDMI_OUTPUT_YCBCR_HQ:
+ case DRM_HDMI_OUTPUT_YCBCR_LQ:
+ case DRM_HDMI_OUTPUT_INVALID:
+ DRM_ERROR("Invalid HDMI output type\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
+
+/**
* drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
*quantization range information
* @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index d4ff17c..3ea833f 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -329,6 +329,7 @@ struct cea_sad {
struct drm_encoder;
struct drm_connector;
struct drm_display_mode;
+enum drm_hdmi_output_type;
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -351,6 +352,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode,
bool is_hdmi2_sink);
int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output);
+int
drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
*frame,
const struct drm_display_mode
*mode);
void
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
scaler framework. This output type is identified using bit
30 of the scaler users bitmap.
V2: rebase
V3: rebase
V4: rebase
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 6 ++
drivers/gpu/drm/i915/intel_display.c | 26 ++
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 3 ++-
5 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e63..a8c9ac5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
/* panel fitter case: assign as a crtc scaler */
scaler_id = &scaler_state->scaler_id;
+ } else if (i == SKL_HDMI_OUTPUT_INDEX) {
+ name = "HDMI-OUTPUT";
+ idx = intel_crtc->base.base.id;
+
+ /* hdmi output case: needs a pipe scaler */
+ scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index da29536..983f581 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
*/
need_scaling = src_w != dst_w || src_h != dst_h;
+ if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
+ && scaler_user == SKL_HDMI_OUTPUT_INDEX)
+ /* YCBCR 444 -> 420 conversion needs a scaler */
+ need_scaling = true;
+
/*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
@@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
}
/**
+ * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
+ * HDMI YCBCR 420 output needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
+{
+ const struct drm_display_mode *mode = &state->base.adjusted_mode;
+
+ return skl_update_scaler(state, !state->base.active,
+ SKL_HDMI_OUTPUT_INDEX, &state->scaler_state.scaler_id,
+ state->pipe_src_w, state->pipe_src_h,
+ mode->crtc_hdisplay, mode->crtc_vdisplay);
+}
+
+/**
* skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
*
* @state: crtc's scaler state
@@ -8058,6 +8083,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 38fe56c..2206aa8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
*
* If a bit is set, a user is using a scaler.
* Here user can be a plane or crtc as defined below:
-* bits 0-30 - plane (bit position is index from drm_plane_index)
+* bits 0-29 - plane (bit position is index from drm_plane_index)
+* bit 30- hdmi output
* bit 31- crtc
*
* Instead of creating a new index to cover planes and crtc, using
@@ -484,6 +485,12 @@ struct intel_crtc_scaler_state {
* avilability.
*/
#define SKL_CRTC_INDEX 31
+
+ /*
+* HDMI YCBCR 420 output consume a scaler. So adding a user
+* for HDMI output 420 requirement.
+*/
+#define SKL_HDMI_OUTPUT_INDEX 30
unsigned scaler_users;
/* scaler used by crtc for panel fitting purpose */
@@ -1481,6 +1488,7 @@ void intel_mode_from_pipe_config(struct drm_display_mode
*mode,
struct intel_crtc_state *pipe_config);
int skl_update_scaler_crtc(struct intel_crtc_state *crtc
[Intel-gfx] [RESEND-CI v4 14/15] drm/i915: set colorspace for ycbcr outputs
When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.
V2: Rebase
V3: Rebase
V4: Rebase
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 8d5aa1e..3bd9af3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -472,6 +472,14 @@ static void intel_hdmi_set_avi_infoframe(struct
drm_encoder *encoder,
return;
}
+ ret = drm_hdmi_avi_infoframe_set_colorspace(&frame.avi,
+ adjusted_mode,
+ crtc_state->hdmi_output);
+ if (ret < 0) {
+ DRM_ERROR("couldn't fill AVI colorspace\n");
+ return;
+ }
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
crtc_state->limited_color_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND-CI v4 13/15] drm/i915: prepare csc unit for YCBCR HDMI output
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, to perform RGB->YCBCR conversion
as per recommended spec values.
V2: Rebase
V3: Rebase
V4: Rebase
Cc: Ville Syrjala
Cc: Daniel Vetter
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_color.c | 47 +++-
drivers/gpu/drm/i915/intel_display.c | 32
2 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 306c6b0..12d5f21 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,19 @@
#define LEGACY_LUT_LENGTH (sizeof(struct drm_color_lut) * 256)
+/* Post offset values for RGB->YCBCR conversion */
+#define POSTOFF_RGB_TO_YUV_HI 0x800
+#define POSTOFF_RGB_TO_YUV_ME 0x100
+#define POSTOFF_RGB_TO_YUV_LO 0x800
+
+/* Direct spec values for RGB->YUV conversion matrix */
+#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
+#define CSC_RGB_TO_YUV_BU 0x37e8
+#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
+#define CSC_RGB_TO_YUV_BY 0xb528
+#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
+#define CSC_RGB_TO_YUV_BV 0x1e08
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -91,6 +104,35 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t
*input)
}
}
+void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+{
+ int pipe = intel_crtc->pipe;
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+
+ /* We don't use high values for conversion */
+ I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+ I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+ I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+ /* Program direct spec values for RGB to YCBCR conversion matrix */
+ I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
+ I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
+
+ I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
+ I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
+
+ I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
+ I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
+
+ /* Spec postoffset values */
+ I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
+ I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
+ I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+
+ /* CSC mode before gamma */
+ I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+}
+
/* Set up the pipe CSC unit. */
static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
{
@@ -101,7 +143,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state
*crtc_state)
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state =
to_intel_crtc_state(crtc_state);
- if (crtc_state->ctm) {
+ if (intel_crtc_state->hdmi_output > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
+ i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+ return;
+ } else if (crtc_state->ctm) {
struct drm_color_ctm *ctm =
(struct drm_color_ctm *)crtc_state->ctm->data;
uint64_t input[9] = { 0, };
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 71fd19e..96ff2a0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6261,6 +6261,29 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
ilk_pipe_pixel_rate(crtc_state);
}
+static int intel_crtc_ycbcr_config(struct intel_crtc_state *state)
+{
+ struct drm_crtc_state *drm_state = &state->base;
+ struct drm_i915_private *dev_priv = to_i915(drm_state->crtc->dev);
+
+ /* YCBCR420 is supported only in HDMI 2.0 controllers */
+ if ((state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420) &&
+ !IS_GEMINILAKE(dev_priv)) {
+ DRM_ERROR("YCBCR420 output is not supported\n");
+ return -EINVAL;
+ }
+
+ /* We need CSC for output conversion from RGB->YCBCR */
+ if (drm_state->ctm) {
+ DRM_ERROR("YCBCR output and CTM is not possible together\n");
+ return -EINVAL;
+ }
+
+ DRM_DEBUG_DRIVER("Output %s can be supported\n",
+drm_get_hdmi_output_name(state->hdmi_output));
+ return 0;
+}
+
static int intel_crtc_compute_config(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_con
[Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property "hdmi_output_format", using which,
a user can specify its preference, for the HDMI output type. The
output type enums are similar to the mentioned outputs above. To
handle various subsampling of YCBCR output types, this property
allows two special cases:
- DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
- ycbcr444
- ycbcr422
- ycbcr420
- DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
- ycbcr420
- ycbcr422
- ycbcr444
Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.
PS: While doing modeset for YCBCR 420 only modes, this property is
ignored, as those timings can be supported only in YCBCR 420
output mode.
V2: Added description for the new variable to address build warning
V3: Rebase
V4: Rebase
V5: Added get_property counterpart to fix IGT BAT failures
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Daniel Vetter
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic.c| 4
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_connector.c | 32
include/drm/drm_connector.h | 18 ++
include/drm/drm_mode_config.h | 5 +
5 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 77dcef0..ea90f8e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+ } else if (property == config->hdmi_output_property) {
+ state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1272,6 +1274,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->picture_aspect_ratio;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+ } else if (property == config->hdmi_output_property) {
+ *val = state->hdmi_output;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 86d3093..1356b3f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -637,6 +637,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->hdmi_output !=
+ new_connector_state->hdmi_output)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..f3c5928 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
config->edid_property,
0);
+ if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
+ drm_object_attach_property(&connector->base,
+ config->hdmi_output_property,
+ 0);
+
drm_object_attach_property(&connector->base,
config->dpms_property, 0);
@@ -617,6 +622,26 @@ static const struct drm_prop_enum_list
drm_link_status_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {
+ { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
+ { DRM_HDMI_OUTPUT_YCBCR444, "output_ycbcr444" },
+ { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
+ { DRM_HDMI_OUTPUT_YCBCR420, "output_ycbcr420" },
+ { DRM_HDMI_OUTPUT_YCBCR_HQ, "output_ycbcr_high_subsampling"
[Intel-gfx] [RESEND-CI v4 15/15] drm/i915/glk: set HDMI 2.0 identifier
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3bd9af3..0d9d088 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1979,6 +1979,9 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
connector->doublescan_allowed = 0;
connector->stereo_allowed = 1;
+ if (IS_GEMINILAKE(dev_priv))
+ connector->ycbcr_420_allowed = true;
+
intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
switch (port) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check context status before looking up our obj/vma
Since we keep the context around across the slow lookup where we may
drop the struct_mutex, we should double check that the context is still
valid upon reacquisition.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index b2457556591c..0ecd2abaef3c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -672,13 +672,6 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(!ctx))
return -ENOENT;
- if (unlikely(i915_gem_context_is_banned(ctx))) {
- DRM_DEBUG("Context %u tried to submit while banned\n",
- ctx->user_handle);
- i915_gem_context_put(ctx);
- return -EIO;
- }
-
eb->ctx = ctx;
eb->vm = ctx->ppgtt ? &ctx->ppgtt->base : &eb->i915->ggtt.base;
@@ -700,6 +693,12 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
int slow_pass = -1;
int err;
+ if (unlikely(i915_gem_context_is_closed(eb->ctx)))
+ return -ENOENT;
+
+ if (unlikely(i915_gem_context_is_banned(eb->ctx)))
+ return -EIO;
+
INIT_LIST_HEAD(&eb->relocs);
INIT_LIST_HEAD(&eb->unbound);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Prevent kernel panic on reading out compliance debugfs files
When reading all debugfs files on a system with DP-MST the kernel panics
on a null pointer dereference because intel_dp is null for a DP-MST
connector. Detect this case and skip those connectors.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1f1176b6400e..30e2e168fe92 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3812,13 +3812,18 @@ static int i915_displayport_test_active_show(struct
seq_file *m, void *data)
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
+ struct intel_encoder *encoder;
+
if (connector->connector_type !=
DRM_MODE_CONNECTOR_DisplayPort)
continue;
- if (connector->status == connector_status_connected &&
- connector->encoder != NULL) {
- intel_dp = enc_to_intel_dp(connector->encoder);
+ encoder = to_intel_encoder(connector->encoder);
+ if (encoder && encoder->type == INTEL_OUTPUT_DP_MST)
+ continue;
+
+ if (encoder && connector->status == connector_status_connected)
{
+ intel_dp = enc_to_intel_dp(&encoder->base);
if (intel_dp->compliance.test_active)
seq_puts(m, "1");
else
@@ -3858,13 +3863,18 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
+ struct intel_encoder *encoder;
+
if (connector->connector_type !=
DRM_MODE_CONNECTOR_DisplayPort)
continue;
- if (connector->status == connector_status_connected &&
- connector->encoder != NULL) {
- intel_dp = enc_to_intel_dp(connector->encoder);
+ encoder = to_intel_encoder(connector->encoder);
+ if (encoder && encoder->type == INTEL_OUTPUT_DP_MST)
+ continue;
+
+ if (encoder && connector->status == connector_status_connected)
{
+ intel_dp = enc_to_intel_dp(&encoder->base);
if (intel_dp->compliance.test_type ==
DP_TEST_LINK_EDID_READ)
seq_printf(m, "%lx",
@@ -3911,13 +3921,18 @@ static int i915_displayport_test_type_show(struct
seq_file *m, void *data)
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
+ struct intel_encoder *encoder;
+
if (connector->connector_type !=
DRM_MODE_CONNECTOR_DisplayPort)
continue;
- if (connector->status == connector_status_connected &&
- connector->encoder != NULL) {
- intel_dp = enc_to_intel_dp(connector->encoder);
+ encoder = to_intel_encoder(connector->encoder);
+ if (encoder && encoder->type == INTEL_OUTPUT_DP_MST)
+ continue;
+
+ if (encoder && connector->status == connector_status_connected)
{
+ intel_dp = enc_to_intel_dp(&encoder->base);
seq_printf(m, "%02lx", intel_dp->compliance.test_type);
} else
seq_puts(m, "0");
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/crc: Handle opening and closing crc better
When I was doing a grep . -r /sys/kernel/debug/dri/0 I noticed a WARN
appearing when I aborted the grep with ^C.
After investigating I've also noticed that the error handling was
lacking and there are race conditions involving multiple calls to
open/close simultaneously.
Fix this by setting the opened flag first and using crc->entries to
decide when crc can be collected.
Also call unset crc source before cleaning up, this way there is
no race with a future open().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_debugfs_crc.c | 46 ++-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 1722d8f21449..d0ea4627a093 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -136,21 +136,38 @@ static int crtc_crc_data_count(struct drm_crtc_crc *crc)
return CIRC_CNT(crc->head, crc->tail, DRM_CRC_ENTRIES_NR);
}
+static void crtc_crc_cleanup(struct drm_crtc_crc *crc)
+{
+ kfree(crc->entries);
+ crc->entries = NULL;
+ crc->head = 0;
+ crc->tail = 0;
+ crc->values_cnt = 0;
+ crc->opened = false;
+}
+
static int crtc_crc_open(struct inode *inode, struct file *filep)
{
struct drm_crtc *crtc = inode->i_private;
struct drm_crtc_crc *crc = &crtc->crc;
struct drm_crtc_crc_entry *entries = NULL;
size_t values_cnt;
- int ret;
+ int ret = 0;
- if (crc->opened)
- return -EBUSY;
+ spin_lock_irq(&crc->lock);
+ if (!crc->opened)
+ crc->opened = true;
+ else
+ ret = -EBUSY;
+ spin_unlock_irq(&crc->lock);
- ret = crtc->funcs->set_crc_source(crtc, crc->source, &values_cnt);
if (ret)
return ret;
+ ret = crtc->funcs->set_crc_source(crtc, crc->source, &values_cnt);
+ if (ret)
+ goto err;
+
if (WARN_ON(values_cnt > DRM_MAX_CRC_NR)) {
ret = -EINVAL;
goto err_disable;
@@ -170,7 +187,6 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
spin_lock_irq(&crc->lock);
crc->entries = entries;
crc->values_cnt = values_cnt;
- crc->opened = true;
/*
* Only return once we got a first frame, so userspace doesn't have to
@@ -182,12 +198,17 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
crc->lock);
spin_unlock_irq(&crc->lock);
- WARN_ON(ret);
+ if (ret)
+ goto err_disable;
return 0;
err_disable:
crtc->funcs->set_crc_source(crtc, NULL, &values_cnt);
+err:
+ spin_lock_irq(&crc->lock);
+ crtc_crc_cleanup(crc);
+ spin_unlock_irq(&crc->lock);
return ret;
}
@@ -197,17 +218,12 @@ static int crtc_crc_release(struct inode *inode, struct
file *filep)
struct drm_crtc_crc *crc = &crtc->crc;
size_t values_cnt;
+ crtc->funcs->set_crc_source(crtc, NULL, &values_cnt);
+
spin_lock_irq(&crc->lock);
- kfree(crc->entries);
- crc->entries = NULL;
- crc->head = 0;
- crc->tail = 0;
- crc->values_cnt = 0;
- crc->opened = false;
+ crtc_crc_cleanup(crc);
spin_unlock_irq(&crc->lock);
- crtc->funcs->set_crc_source(crtc, NULL, &values_cnt);
-
return 0;
}
@@ -334,7 +350,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
spin_lock(&crc->lock);
/* Caller may not have noticed yet that userspace has stopped reading */
- if (!crc->opened) {
+ if (!crc->entries) {
spin_unlock(&crc->lock);
return -EINVAL;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
On Wed, 2017-06-21 at 09:20 +, Zhang, Tina wrote:
> Thanks for all the comments. I'm planning to cook the next version of
> this patch set
How about posting only this patch instead of the whole series until
we've settled the interfaces?
> Could the following two works?
> #define VFIO_DEVICE_FLAGS_DMABUF (1 << 5)/* vfio-dmabuf
> device */
VFIO_DEVICE_FLAGS_GFX_DMABUF?
> 2. vfio_device_gfx_plane_info
> struct vfio_device_gfx_plane_info {
> __u64 start;-> offset
> __u64 drm_format_mod;
> __u32 drm_format;
> __u32 width;
> __u32 height;
> __u32 stride;
> __u32 size;
> __u32 x_pos;
> __u32 y_pos;
> };
> > Does it make sense to have a "generation" field in the plane_info
> > struct (which gets increased each time the struct changes) ?
> Well, Gerd, can you share more details about how to use this field
> in user mode, so that we can figure out a way to support it? Thanks.
generation would be increased each time one of the fields in
vfio_device_gfx_plane_info changes, typically on mode switches
(width/height changes) and pageflips (offset changes). So userspace
can simply compare generation instead of comparing every field to
figure whenever something changed compared to the previous poll.
>
> 3. vfio_device_query_gfx_plane
> struct vfio_device_query_gfx_plane {
> __u32 argsz;
> __u32 flags;
> #define VFIO_GFX_PLANE_FLAGS_REGION_ID(1 << 0)
> #define VFIO_GFX_PLANE_FLAGS_PLANE_ID (1 << 1)
> struct vfio_device_gfx_plane_info plane_info;
> __u32 id;
> __u32 plane_type;
> };
> So far, dmabuf use id for DRM_PLANE_TYPE_PRIMARY or
> DRM_PLANE_TYPE_CURSOR.
> If the newly added plane_type is used for this, the id field may be
> useless in dmabuf usage. Do you have any idea about the usage of this
> id field in dmabuf usage?
plane_type should be DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR
for dmabuf.
Given that nvidia doesn't support a separate cursor plane in their
region they would support DRM_PLANE_TYPE_PRIMARY only.
I can't see yet what id would be useful for.
Likewise I can't see yet what the VFIO_GFX_PLANE_FLAGS_* are good for.
cheers,
Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic-helper: Simplify commit tracking locking
== Series Details == Series: drm/atomic-helper: Simplify commit tracking locking URL : https://patchwork.freedesktop.org/series/26127/ State : success == Summary == Series 26127v1 drm/atomic-helper: Simplify commit tracking locking https://patchwork.freedesktop.org/api/1.0/series/26127/revisions/1/mbox/ Test gem_ringfill: Subgroup basic-default-hang: incomplete -> TIMEOUT(fi-blb-e6850) fdo#99093 +1 Test prime_busy: Subgroup basic-wait-after-default: dmesg-warn -> PASS (fi-skl-6700hq) fdo#101515 +3 fdo#99093 https://bugs.freedesktop.org/show_bug.cgi?id=99093 fdo#101515 https://bugs.freedesktop.org/show_bug.cgi?id=101515 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:426s fi-blb-e6850 total:208 pass:169 dwarn:0 dfail:0 fail:0 skip:37 fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:520s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:502s fi-byt-j1900 total:278 pass:252 dwarn:2 dfail:0 fail:0 skip:24 time:482s fi-byt-n2820 total:278 pass:248 dwarn:2 dfail:0 fail:0 skip:28 time:487s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:587s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:496s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:573s fi-kbl-r total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 time:578s fi-pnv-d510 total:146 pass:112 dwarn:0 dfail:0 fail:0 skip:33 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:459s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:341s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:464s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:477s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:404s 186f6503dc0750d739db5d9301dc9a507eacc6ef drm-tip: 2017y-06m-21d-10h-08m-42s UTC integration manifest 795e2aa drm/atomic-helper: Simplify commit tracking locking == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5008/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Break modeset deadlocks on reset
On 20/06/2017 20:55, Chris Wilson wrote:
Trying to do a modeset from within a reset is fraught with danger. We
can fall into a cyclic deadlock where the modeset is waiting on a
previous modeset that is waiting on a request, and since the GPU hung
that request completion is waiting on the reset. As modesetting doesn't
allow its locks to be broken and restarted, or for its *own* reset
mechanism to take over the display, we have to do something very
evil instead. If we detect that we are stuck waiting to prepare the
display reset (by using a very simple timeout), resort to cancelling all
in-flight requests and throwing the user data into /dev/null, which is
marginally better than the driver locking up and keeping that data to
itself.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 18 --
drivers/gpu/drm/i915/i915_irq.c | 41 -
2 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c2213016fd86..973f4f9e6b84 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3040,7 +3040,8 @@ static void engine_set_wedged(struct intel_engine_cs
*engine)
/* Mark all executing requests as skipped */
spin_lock_irqsave(&engine->timeline->lock, flags);
list_for_each_entry(request, &engine->timeline->requests, link)
- dma_fence_set_error(&request->fence, -EIO);
+ if (!i915_gem_request_completed(request))
+ dma_fence_set_error(&request->fence, -EIO);
spin_unlock_irqrestore(&engine->timeline->lock, flags);
/* Mark all pending requests as complete so that any concurrent
@@ -3079,6 +3080,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ set_bit(I915_WEDGED, &i915->gpu_error.flags);
for_each_engine(engine, i915, id)
engine_set_wedged(engine);
@@ -3087,20 +3089,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
{
- lockdep_assert_held(&dev_priv->drm.struct_mutex);
- set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
-
- /* Retire completed requests first so the list of inflight/incomplete
-* requests is accurate and we don't try and mark successful requests
-* as in error during __i915_gem_set_wedged_BKL().
-*/
- i915_gem_retire_requests(dev_priv);
-
stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
-
- i915_gem_contexts_lost(dev_priv);
-
- mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
What was the purpose of this, since it is now gone?
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
@@ -3155,6 +3144,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
* context and do not require stop_machine().
*/
intel_engines_reset_default_submission(i915);
+ i915_gem_contexts_lost(i915);
smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
clear_bit(I915_WEDGED, &i915->gpu_error.flags);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bce2d1feceb1..6585bcdf61a6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2599,6 +2599,40 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
return ret;
}
+struct wedge_me {
+ struct delayed_work work;
+ struct drm_i915_private *i915;
+ const char *name;
+};
+
+static void wedge_me(struct work_struct *work)
+{
+ struct wedge_me *w = container_of(work, typeof(*w), work.work);
+
+ DRM_ERROR("%s timed out, cancelling all in-flight rendering.\n",
+ w->name);
Do you plan to call this from other places to need the name string?
+ i915_gem_set_wedged(w->i915);
Is it safe to do the execlist_port manipulation at this point? Couldn't
we receive an interrupt for one request completing after we have cleared
it from ports but before the actual reset?
+}
+
+static bool init_wedge_on_timeout(struct wedge_me *w,
+ struct drm_i915_private *i915,
+ long timeout,
+ const char *name)
+{
+ w->i915 = i915;
+ w->name = name;
+ INIT_DELAYED_WORK_ONSTACK(&w->work, wedge_me);
+
+ schedule_delayed_work(&w->work, HZ);
One second is pessimistic enough etc?
+ return true;
Is the return value needed?
+}
+
+static void destroy_wedge_on_timeout(struct wedge_me *w)
+{
+ cancel_delayed_work_sync(&w->work);
+ destroy_delayed_work_on_stack(&w->work);
+}
+
Slight objection to the "on stack" API since it is disconnected from the
allocation so does not directly see w
Re: [Intel-gfx] [PATCH] drm/i915: Break modeset deadlocks on reset
Quoting Tvrtko Ursulin (2017-06-21 12:30:15)
>
> On 20/06/2017 20:55, Chris Wilson wrote:
> > Trying to do a modeset from within a reset is fraught with danger. We
> > can fall into a cyclic deadlock where the modeset is waiting on a
> > previous modeset that is waiting on a request, and since the GPU hung
> > that request completion is waiting on the reset. As modesetting doesn't
> > allow its locks to be broken and restarted, or for its *own* reset
> > mechanism to take over the display, we have to do something very
> > evil instead. If we detect that we are stuck waiting to prepare the
> > display reset (by using a very simple timeout), resort to cancelling all
> > in-flight requests and throwing the user data into /dev/null, which is
> > marginally better than the driver locking up and keeping that data to
> > itself.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Maarten Lankhorst
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 18 --
> > drivers/gpu/drm/i915/i915_irq.c | 41
> > -
> > 2 files changed, 44 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index c2213016fd86..973f4f9e6b84 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3040,7 +3040,8 @@ static void engine_set_wedged(struct intel_engine_cs
> > *engine)
> > /* Mark all executing requests as skipped */
> > spin_lock_irqsave(&engine->timeline->lock, flags);
> > list_for_each_entry(request, &engine->timeline->requests, link)
> > - dma_fence_set_error(&request->fence, -EIO);
> > + if (!i915_gem_request_completed(request))
> > + dma_fence_set_error(&request->fence, -EIO);
> > spin_unlock_irqrestore(&engine->timeline->lock, flags);
> >
> > /* Mark all pending requests as complete so that any concurrent
> > @@ -3079,6 +3080,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
> > struct intel_engine_cs *engine;
> > enum intel_engine_id id;
> >
> > + set_bit(I915_WEDGED, &i915->gpu_error.flags);
> > for_each_engine(engine, i915, id)
> > engine_set_wedged(engine);
> >
> > @@ -3087,20 +3089,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
> >
> > void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
> > {
> > - lockdep_assert_held(&dev_priv->drm.struct_mutex);
> > - set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
> > -
> > - /* Retire completed requests first so the list of inflight/incomplete
> > - * requests is accurate and we don't try and mark successful requests
> > - * as in error during __i915_gem_set_wedged_BKL().
> > - */
> > - i915_gem_retire_requests(dev_priv);
> > -
> > stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
> > -
> > - i915_gem_contexts_lost(dev_priv);
> > -
> > - mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
>
> What was the purpose of this, since it is now gone?
It was to clean up the device after explicitly cancelling everything. In
the pre-reset path, I felt it was overkill and replaced with the retire_work
(which will then call idle_work as required).
Hmm, thinking about the reset cycle, the retirement is forced anyway. My
main concern is that we lose the cleanliness of a "normal" wedging.
> > bool i915_gem_unset_wedged(struct drm_i915_private *i915)
> > @@ -3155,6 +3144,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> > *i915)
> >* context and do not require stop_machine().
> >*/
> > intel_engines_reset_default_submission(i915);
> > + i915_gem_contexts_lost(i915);
> >
> > smp_mb__before_atomic(); /* complete takeover before enabling execbuf
> > */
> > clear_bit(I915_WEDGED, &i915->gpu_error.flags);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index bce2d1feceb1..6585bcdf61a6 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2599,6 +2599,40 @@ static irqreturn_t gen8_irq_handler(int irq, void
> > *arg)
> > return ret;
> > }
> >
> > +struct wedge_me {
> > + struct delayed_work work;
> > + struct drm_i915_private *i915;
> > + const char *name;
> > +};
> > +
> > +static void wedge_me(struct work_struct *work)
> > +{
> > + struct wedge_me *w = container_of(work, typeof(*w), work.work);
> > +
> > + DRM_ERROR("%s timed out, cancelling all in-flight rendering.\n",
> > + w->name);
>
> Do you plan to call this from other places to need the name string?
I was keeping that option open.
>
> > + i915_gem_set_wedged(w->i915);
>
> Is it safe to do the execlist_port manipulation at this point? Couldn't
> we receive an interrupt for one request completing after we have cleared
> it from ports but before the actual rese
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check context status before looking up our obj/vma
== Series Details == Series: drm/i915: Check context status before looking up our obj/vma URL : https://patchwork.freedesktop.org/series/26137/ State : success == Summary == Series 26137v1 drm/i915: Check context status before looking up our obj/vma https://patchwork.freedesktop.org/api/1.0/series/26137/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 +1 Test gem_ringfill: Subgroup basic-default-hang: incomplete -> TIMEOUT(fi-blb-e6850) fdo#99093 +1 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-byt-n2820) fdo#101517 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#99093 https://bugs.freedesktop.org/show_bug.cgi?id=99093 fdo#101517 https://bugs.freedesktop.org/show_bug.cgi?id=101517 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:425s fi-blb-e6850 total:278 pass:114 dwarn:0 dfail:0 fail:0 skip:32 fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:543s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:278 pass:252 dwarn:2 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:278 pass:249 dwarn:1 dfail:0 fail:0 skip:28 time:477s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:587s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:432s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:409s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:499s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:567s fi-kbl-r total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:584s fi-pnv-d510 total:146 pass:112 dwarn:0 dfail:0 fail:0 skip:33 fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:344s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:469s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:472s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:431s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:408s 186f6503dc0750d739db5d9301dc9a507eacc6ef drm-tip: 2017y-06m-21d-10h-08m-42s UTC integration manifest 792cec8 drm/i915: Check context status before looking up our obj/vma == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5010/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/13] drm/zte: Drop drm_vblank_cleanup
On Wed, Jun 21, 2017 at 10:28:49AM +0200, Daniel Vetter wrote: > It again looks all cargo-culted for no good reasons. > > Cc: Shawn Guo > Signed-off-by: Daniel Vetter Acked-by: Shawn Guo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prevent kernel panic on reading out compliance debugfs files
== Series Details == Series: drm/i915: Prevent kernel panic on reading out compliance debugfs files URL : https://patchwork.freedesktop.org/series/26139/ State : success == Summary == Series 26139v1 drm/i915: Prevent kernel panic on reading out compliance debugfs files https://patchwork.freedesktop.org/api/1.0/series/26139/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-r) fdo#100125 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-snb-2600) fdo#100215 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:443s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:433s fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:521s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-byt-j1900 total:278 pass:252 dwarn:2 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:278 pass:248 dwarn:2 dfail:0 fail:0 skip:28 time:481s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:586s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:412s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:426s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:503s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:472s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:462s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:571s fi-kbl-r total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:577s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:455s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:340s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:461s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:477s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:406s 186f6503dc0750d739db5d9301dc9a507eacc6ef drm-tip: 2017y-06m-21d-10h-08m-42s UTC integration manifest f5bba85 drm/i915: Prevent kernel panic on reading out compliance debugfs files == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5011/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/crc: Handle opening and closing crc better
== Series Details == Series: drm/crc: Handle opening and closing crc better URL : https://patchwork.freedesktop.org/series/26140/ State : success == Summary == Series 26140v1 drm/crc: Handle opening and closing crc better https://patchwork.freedesktop.org/api/1.0/series/26140/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test prime_busy: Subgroup basic-wait-after-default: dmesg-warn -> PASS (fi-skl-6700hq) fdo#101515 +3 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101515 https://bugs.freedesktop.org/show_bug.cgi?id=101515 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:450s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:427s fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:530s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:506s fi-byt-j1900 total:278 pass:252 dwarn:2 dfail:0 fail:0 skip:24 time:492s fi-byt-n2820 total:278 pass:248 dwarn:2 dfail:0 fail:0 skip:28 time:480s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:583s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:440s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:409s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:416s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:494s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:577s fi-kbl-r total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 time:579s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:459s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:338s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:472s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:480s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:531s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:407s 186f6503dc0750d739db5d9301dc9a507eacc6ef drm-tip: 2017y-06m-21d-10h-08m-42s UTC integration manifest 4cb07ba drm/crc: Handle opening and closing crc better == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5012/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Break modeset deadlocks on reset
Quoting Chris Wilson (2017-06-21 12:46:51) > Quoting Tvrtko Ursulin (2017-06-21 12:30:15) > > > > On 20/06/2017 20:55, Chris Wilson wrote: > > > + i915_gem_set_wedged(w->i915); > > > > Is it safe to do the execlist_port manipulation at this point? Couldn't > > we receive an interrupt for one request completing after we have cleared > > it from ports but before the actual reset? > > We do the port manipulation and queue cancellation inside stop_machine, > i.e. in complete isolation. That ensures we won't succumb to a race > there, we just have to be careful that the execlists cancellation works > once the machine process the interrupts afterwards. That I'm not sure > about... I got very worried, but then remembered we installed a filter on the intel_lrc_irq_handler; that is we don't call into the irq handler unless port[0] is set. So we should not get an extra call between the stop_machine() and the actual reset, but I suppose we might get a conitinuation of a tasklet? I doubt it, but adding a clear_bit to i915_gem_set_wedged would alleviate that concern. I'm happier, but randomly calling i915_gem_set_wedged() is definitely undertested (just gem_eio tries), it is and always has been meant as a last resort to keep the driver limping along. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Cancel pending execlist tasklet upon wedging
Highly unlikely, but if the stop_machine() did suspend the tasklet, we want to make sure that when it wakes it finds there is nothing to do. Otherwise, it will loudly complain that the ELSP port tracking no longer matches the hardware, and we will be mightly confused. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 1353491c1010..ae3ce1314bd1 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3092,6 +3092,13 @@ static void engine_set_wedged(struct intel_engine_cs *engine) engine->execlist_first = NULL; spin_unlock_irqrestore(&engine->timeline->lock, flags); + + /* The port is checked prior to scheduling a tasklet, but +* just in case we have suspended the tasklet to do the +* wedging make sure that when it wakes, it decides there +* is no work to do by clearing the irq_posted bit. +*/ + clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); } } -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Check for drm_device->dev in drm_set_busid
I've failed to remember that we have virtual drivers like vgem which
have no underlying struct device. Fix this asap.
Reported-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Fixes: 5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook")
Cc: Thierry Reding
Cc: Daniel Vetter
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index b25a00826f59..a1e421616b46 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -143,7 +143,7 @@ static int drm_set_busid(struct drm_device *dev, struct
drm_file *file_priv)
if (master->unique != NULL)
drm_unset_busid(dev, master);
- if (dev_is_pci(dev->dev)) {
+ if (dev->dev && dev_is_pci(dev->dev)) {
ret = drm_pci_set_busid(dev, master);
if (ret) {
drm_unset_busid(dev, master);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Cancel pending execlist tasklet upon wedging
== Series Details == Series: drm/i915: Cancel pending execlist tasklet upon wedging URL : https://patchwork.freedesktop.org/series/26146/ State : success == Summary == Series 26146v1 drm/i915: Cancel pending execlist tasklet upon wedging https://patchwork.freedesktop.org/api/1.0/series/26146/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:427s fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:526s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:512s fi-byt-j1900 total:278 pass:252 dwarn:2 dfail:0 fail:0 skip:24 time:493s fi-byt-n2820 total:278 pass:248 dwarn:2 dfail:0 fail:0 skip:28 time:480s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:585s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:434s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:484s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:465s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:568s fi-kbl-r total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 time:581s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:459s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:337s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:465s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:482s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:432s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:406s 186f6503dc0750d739db5d9301dc9a507eacc6ef drm-tip: 2017y-06m-21d-10h-08m-42s UTC integration manifest fcf0fd0 drm/i915: Cancel pending execlist tasklet upon wedging == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5013/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Check for drm_device->dev in drm_set_busid
== Series Details == Series: drm: Check for drm_device->dev in drm_set_busid URL : https://patchwork.freedesktop.org/series/26149/ State : success == Summary == Series 26149v1 drm: Check for drm_device->dev in drm_set_busid https://patchwork.freedesktop.org/api/1.0/series/26149/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 +1 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-byt-j1900) fdo#101517 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101516 Test prime_busy: Subgroup basic-wait-after-default: dmesg-warn -> PASS (fi-skl-6700hq) fdo#101515 +3 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101517 https://bugs.freedesktop.org/show_bug.cgi?id=101517 fdo#101516 https://bugs.freedesktop.org/show_bug.cgi?id=101516 fdo#101515 https://bugs.freedesktop.org/show_bug.cgi?id=101515 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:443s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:431s fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:530s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-byt-j1900 total:278 pass:253 dwarn:1 dfail:0 fail:0 skip:24 time:485s fi-byt-n2820 total:278 pass:249 dwarn:1 dfail:0 fail:0 skip:28 time:478s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:587s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:437s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:491s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:574s fi-kbl-r total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:572s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:456s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:343s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:464s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:484s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:405s 186f6503dc0750d739db5d9301dc9a507eacc6ef drm-tip: 2017y-06m-21d-10h-08m-42s UTC integration manifest ad040e3 drm: Check for drm_device->dev in drm_set_busid == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5014/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlist tasklet upon wedging
On 21/06/2017 13:48, Chris Wilson wrote: Highly unlikely, but if the stop_machine() did suspend the tasklet, we want to make sure that when it wakes it finds there is nothing to do. Otherwise, it will loudly complain that the ELSP port tracking no longer matches the hardware, and we will be mightly confused. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 1353491c1010..ae3ce1314bd1 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3092,6 +3092,13 @@ static void engine_set_wedged(struct intel_engine_cs *engine) engine->execlist_first = NULL; spin_unlock_irqrestore(&engine->timeline->lock, flags); + + /* The port is checked prior to scheduling a tasklet, but +* just in case we have suspended the tasklet to do the +* wedging make sure that when it wakes, it decides there +* is no work to do by clearing the irq_posted bit. +*/ + clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); } } Or tasklet_kill? Actually I am not sure now how the wedging transition works for request which have pasted the submit callback, but are not in the hardware yet (waiting in the priotree). Can't find at the moment that we have anything dealing with those. 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: Break modeset deadlocks on reset
On 21/06/2017 12:46, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-06-21 12:30:15)
On 20/06/2017 20:55, Chris Wilson wrote:
Trying to do a modeset from within a reset is fraught with danger. We
can fall into a cyclic deadlock where the modeset is waiting on a
previous modeset that is waiting on a request, and since the GPU hung
that request completion is waiting on the reset. As modesetting doesn't
allow its locks to be broken and restarted, or for its *own* reset
mechanism to take over the display, we have to do something very
evil instead. If we detect that we are stuck waiting to prepare the
display reset (by using a very simple timeout), resort to cancelling all
in-flight requests and throwing the user data into /dev/null, which is
marginally better than the driver locking up and keeping that data to
itself.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 18 --
drivers/gpu/drm/i915/i915_irq.c | 41
-
2 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c2213016fd86..973f4f9e6b84 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3040,7 +3040,8 @@ static void engine_set_wedged(struct intel_engine_cs
*engine)
/* Mark all executing requests as skipped */
spin_lock_irqsave(&engine->timeline->lock, flags);
list_for_each_entry(request, &engine->timeline->requests, link)
- dma_fence_set_error(&request->fence, -EIO);
+ if (!i915_gem_request_completed(request))
+ dma_fence_set_error(&request->fence, -EIO);
spin_unlock_irqrestore(&engine->timeline->lock, flags);
/* Mark all pending requests as complete so that any concurrent
@@ -3079,6 +3080,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ set_bit(I915_WEDGED, &i915->gpu_error.flags);
for_each_engine(engine, i915, id)
engine_set_wedged(engine);
@@ -3087,20 +3089,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
{
- lockdep_assert_held(&dev_priv->drm.struct_mutex);
- set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
-
- /* Retire completed requests first so the list of inflight/incomplete
- * requests is accurate and we don't try and mark successful requests
- * as in error during __i915_gem_set_wedged_BKL().
- */
- i915_gem_retire_requests(dev_priv);
-
stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
-
- i915_gem_contexts_lost(dev_priv);
-
- mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
What was the purpose of this, since it is now gone?
It was to clean up the device after explicitly cancelling everything. In
the pre-reset path, I felt it was overkill and replaced with the retire_work
(which will then call idle_work as required).
Hmm, thinking about the reset cycle, the retirement is forced anyway. My
main concern is that we lose the cleanliness of a "normal" wedging.
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
@@ -3155,6 +3144,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
* context and do not require stop_machine().
*/
intel_engines_reset_default_submission(i915);
+ i915_gem_contexts_lost(i915);
smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
clear_bit(I915_WEDGED, &i915->gpu_error.flags);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bce2d1feceb1..6585bcdf61a6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2599,6 +2599,40 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
return ret;
}
+struct wedge_me {
+ struct delayed_work work;
+ struct drm_i915_private *i915;
+ const char *name;
+};
+
+static void wedge_me(struct work_struct *work)
+{
+ struct wedge_me *w = container_of(work, typeof(*w), work.work);
+
+ DRM_ERROR("%s timed out, cancelling all in-flight rendering.\n",
+ w->name);
Do you plan to call this from other places to need the name string?
I was keeping that option open. >
+ i915_gem_set_wedged(w->i915);
Is it safe to do the execlist_port manipulation at this point? Couldn't
we receive an interrupt for one request completing after we have cleared
it from ports but before the actual reset?
We do the port manipulation and queue cancellation inside stop_machine,
i.e. in complete isolation. That ensures we won't succumb to a race
there, we just have to be careful that the execlists cancellation works
once the machine process the interrupts afterwards. That I'm not sure
about...
+static bool init_wedge_on_tim
Re: [Intel-gfx] [PATCH v4 11/11] drm/rockchip: Remove unnecessary NULL check
On Wed, Mar 29, 2017 at 04:44:01PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The expression &private->fbdev_helper can never be NULL, so the check is
> completely unnecessary.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Thierry Reding
I just noticed that these two patches at the end of this series don't
depend upon the core rework, so applied them both.
-Daniel
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 81f9548672b0..df6bceabeca8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -168,10 +168,8 @@ rockchip_user_fb_create(struct drm_device *dev, struct
> drm_file *file_priv,
> static void rockchip_drm_output_poll_changed(struct drm_device *dev)
> {
> struct rockchip_drm_private *private = dev->dev_private;
> - struct drm_fb_helper *fb_helper = &private->fbdev_helper;
>
> - if (fb_helper)
> - drm_fb_helper_hotplug_event(fb_helper);
> + drm_fb_helper_hotplug_event(&private->fbdev_helper);
> }
>
> static void
> --
> 2.12.0
>
> ___
> 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] [RESEND-CI v4 01/15] drm: add HDMI 2.0 VIC support for AVI info-frames
On 06/21/2017 12:33 PM, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch:
> - checks if the connected display is HDMI 2.0.
> - HDMI infoframes carry one of this two type of information:
> - VIC for 4K modes for HDMI 1.4 sinks
> - S3D information for S3D modes
> As CEA-861-F has already defined VICs for 4K videomodes, this
> patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
> until the mode is 3D.
>
> Cc: Ville Syrjala
> Cc: Jose Abreu
> Cc: Andrzej Hajda
> Cc: Alex Deucher
> Cc: Daniel Vetter
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> V2: Rebase, Added r-b from Andrzej
> V3: Addressed review comment from Ville:
> - Do not send VICs in both AVI-IF and HDMI-IF
> send only one of it.
>
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/drm_edid.c| 12 +++-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 17 -
> drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
> drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
> drivers/gpu/drm/tegra/hdmi.c | 2 +-
> drivers/gpu/drm/tegra/sor.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
> include/drm/drm_edid.h| 3 ++-
> 21 files changed, 50 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 3c62c45..4923ddc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v10_0_audio_write_sad_regs(encoder);
> dce_v10_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index c8ed0fa..4101684 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v11_0_audio_write_sad_regs(encoder);
> dce_v11_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index 3e90c19..a7f6b32 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v8_0_audio_write_sad_regs(encoder);
> dce_v8_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-
Re: [Intel-gfx] [RESEND-CI v4 02/15] drm: add YCBCR 420 capability identifier
On 06/21/2017 12:34 PM, Shashank Sharma wrote:
> This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
> structure. While handling the EDID from HDMI 2.0 sinks, its important to
> know if the source is capable of handling YCBCR 420 outputs or not, so that
> a lot of work can be done/bypassed based on this information. One such
> example is adding YCBCR420 only modes.
>
> If the driver knows that this source is not HDMI 2.0 capable, it will
> not add YCBCR420-only modes while adding EDID modes, and will prevent
> any runtime modeset failures.
>
> This variable will be initialized from I915 driver in the next patch
> and will be used in the EDID handling for HDMI 2.0 specific features,
> in this same series.
>
> V3: introduced the new variable
> V4: changed variable name from is_hdmi2_src to ycbcr_420_allowed (Ville)
>
> Signed-off-by: Shashank Sharma
> ---
> include/drm/drm_connector.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index d8bb25f..7493fd3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -728,6 +728,15 @@ struct drm_connector {
> bool interlace_allowed;
> bool doublescan_allowed;
> bool stereo_allowed;
> +
> + /**
> + * @ycbcr_420_allowed : This bool indicates if this connector is
> + * capable of handling YCBCR 420 output. While parsing the EDID
> + * blocks, its very helpful to know, if the source is capable of
> + * handling YCBCR 420 outputs.
> + */
> + bool ycbcr_420_allowed;
> +
> /**
>* @registered: Is this connector exposed (registered) with userspace?
>* Protected by @mutex.
>
Reviewed-by: Neil Armstrong
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 03/15] drm/edid: Complete CEA modedb(VIC 1-107)
On 06/21/2017 12:34 PM, Shashank Sharma wrote:
> CEA-861-F specs defines new video modes to be used with
> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> 1-107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA modes using the existing methods, we have
> to complete the modedb (VIC=65 onwards).
>
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
>
> The patch was originaly discussed and reviewed here:
> https://patchwork.freedesktop.org/patch/135810/
>
> Cc: Ville Syrjala
> Cc: Jose Abreu
> Cc: Andrzej Hajda
> Cc: Alex Deucher
> Cc: Harry Wentland
>
> V2: Rebase
> V3: Rebase
> V4: Added native bit handling as per CEA-861-F spec (Ville)
>
> Reviewed-by: Jose Abreu
> Reviewed-by: Alex Deucher
> Acked-by: Harry Wentland
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 227
> -
> 1 file changed, 226 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d312fe1..e2d1b30 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[]
> = {
> 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080@30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 75 - 1920x1080@50Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 76 - 1920x1080@60Hz */
> + { DRM_
Re: [Intel-gfx] [PATCH] drm: Check for drm_device->dev in drm_set_busid
On Wed, Jun 21, 2017 at 03:04:29PM +0200, Daniel Vetter wrote:
> I've failed to remember that we have virtual drivers like vgem which
> have no underlying struct device. Fix this asap.
>
> Reported-by: Chris Wilson
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson
> Fixes: 5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook")
> Cc: Thierry Reding
> Cc: Daniel Vetter
> Signed-off-by: Daniel Vetter
And pushed after CI approved of it too ...
-Daniel
> ---
> drivers/gpu/drm/drm_ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index b25a00826f59..a1e421616b46 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -143,7 +143,7 @@ static int drm_set_busid(struct drm_device *dev, struct
> drm_file *file_priv)
> if (master->unique != NULL)
> drm_unset_busid(dev, master);
>
> - if (dev_is_pci(dev->dev)) {
> + if (dev->dev && dev_is_pci(dev->dev)) {
> ret = drm_pci_set_busid(dev, master);
> if (ret) {
> drm_unset_busid(dev, master);
> --
> 2.11.0
>
--
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 i-g-t 21/29] igt/perf: make stream_fd a global variable
On 25 April 2017 at 23:32, Lionel Landwerlin
wrote:
> When debugging unstable tests on new platforms we currently we don't
> cleanup everything well in between different tests. Since only a
> single OA stream fd can be opened at a time, having the stream_fd as a
> global variable helps us cleanup the state between tests.
>
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 108
> ---
> 1 file changed, 58 insertions(+), 50 deletions(-)
>
> diff --git a/tests/perf.c b/tests/perf.c
> index f8ac06c3..b7af1c3b 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> @@ -243,6 +243,7 @@ static bool hsw_undefined_a_counters[45] = {
> static bool gen8_undefined_a_counters[45];
>
> static int drm_fd = -1;
> +static int stream_fd = -1;
> static uint32_t devid;
> static int card = -1;
> static int n_eus;
> @@ -264,10 +265,22 @@ static uint32_t (*read_report_ticks)(uint32_t *report,
> static void (*sanity_check_reports)(uint32_t *oa_report0, uint32_t
> *oa_report1,
> enum drm_i915_oa_format format);
>
> +static void
> +__perf_close(int fd)
> +{
> + close(fd);
> + stream_fd = -1;
> +}
> +
> static int
> __perf_open(int fd, struct drm_i915_perf_open_param *param)
> {
> - int ret = igt_ioctl(fd, DRM_IOCTL_I915_PERF_OPEN, param);
> + int ret;
> +
> + if (stream_fd >= 0)
> + __perf_close(stream_fd);
> +
> + ret = igt_ioctl(fd, DRM_IOCTL_I915_PERF_OPEN, param);
>
> igt_assert(ret >= 0);
> errno = 0;
> @@ -918,14 +931,12 @@ test_system_wide_paranoid(void)
> .num_properties = sizeof(properties) / 16,
> .properties_ptr = to_user_pointer(properties),
> };
> - int stream_fd;
> -
> write_u64_file("/proc/sys/dev/i915/perf_stream_paranoid", 0);
>
> igt_drop_root();
>
> stream_fd = __perf_open(drm_fd, ¶m);
> - close(stream_fd);
> + __perf_close(stream_fd);
> }
>
> igt_waitchildren();
> @@ -973,7 +984,6 @@ test_invalid_oa_metric_set_id(void)
> .num_properties = sizeof(properties) / 16,
> .properties_ptr = to_user_pointer(properties),
> };
> - int stream_fd;
>
> do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m, EINVAL);
>
> @@ -983,7 +993,7 @@ test_invalid_oa_metric_set_id(void)
> /* Check that we aren't just seeing false positives... */
> properties[ARRAY_SIZE(properties) - 1] = test_metric_set_id;
> stream_fd = __perf_open(drm_fd, ¶m);
> - close(stream_fd);
> + __perf_close(stream_fd);
>
> /* There's no valid default OA metric set ID... */
> param.num_properties--;
> @@ -1008,7 +1018,6 @@ test_invalid_oa_format_id(void)
> .num_properties = sizeof(properties) / 16,
> .properties_ptr = to_user_pointer(properties),
> };
> - int stream_fd;
>
> do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m, EINVAL);
>
> @@ -1018,7 +1027,7 @@ test_invalid_oa_format_id(void)
> /* Check that we aren't just seeing false positives... */
> properties[ARRAY_SIZE(properties) - 1] = test_oa_format;
> stream_fd = __perf_open(drm_fd, ¶m);
> - close(stream_fd);
> + __perf_close(stream_fd);
>
> /* There's no valid default OA format... */
> param.num_properties--;
> @@ -1046,8 +1055,7 @@ test_missing_sample_flags(void)
> }
>
> static void
> -read_2_oa_reports(int stream_fd,
> - int format_id,
> +read_2_oa_reports(int format_id,
> int exponent,
> uint32_t *oa_report0,
> uint32_t *oa_report1,
> @@ -1181,12 +1189,13 @@ open_and_read_2_oa_reports(int format_id,
> .num_properties = sizeof(properties) / 16,
> .properties_ptr = to_user_pointer(properties),
> };
> - int stream_fd = __perf_open(drm_fd, ¶m);
>
> - read_2_oa_reports(stream_fd, format_id, exponent,
> + stream_fd = __perf_open(drm_fd, ¶m);
> +
> + read_2_oa_reports(format_id, exponent,
> oa_report0, oa_report1, timer_only);
>
> - close(stream_fd);
> + __perf_close(stream_fd);
> }
>
> static void
> @@ -1486,9 +1495,10 @@ test_invalid_oa_exponent(void)
> .num_properties = sizeof(properties) / 16,
> .properties_ptr = to_user_pointer(properties),
> };
> - int stream_fd = __perf_open(drm_fd, ¶m);
>
> - close(stream_fd);
> + stream_fd = __perf_open(drm_fd, ¶m);
> +
> + __perf_close(stream_fd);
>
> for (int i = 32; i < 65; i++) {
> properties[7] = i;
> @@ -1538,12 +1548,10 @@ test_low_oa_exponent_permissions(void)
> properties[7] = ok_exponent;
>
> igt_fork(child, 1) {
> - int stream
Re: [Intel-gfx] [PATCH] drm/i915: Break modeset deadlocks on reset
Quoting Tvrtko Ursulin (2017-06-21 14:37:33) > > On 21/06/2017 12:46, Chris Wilson wrote: > > It's the replacement for the removed idle_work, but now I realise that we > > are guaranteed a i915_gem_retire_requests() as part of the reset procedure. > > So will be respinning with this removed? I will send it on after finishing an oops reproducer (for drm_setversion). Currently I've bdw/bxt doing hang testing just to gain some more confidence -- though by design they shouldn't be hitting this path at all anymore (per-engine lockless resets ftw). pnv now recovers from its struct_mutex deadlock just fine. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlist tasklet upon wedging
Quoting Tvrtko Ursulin (2017-06-21 14:33:59) > > On 21/06/2017 13:48, Chris Wilson wrote: > > Highly unlikely, but if the stop_machine() did suspend the tasklet, we > > want to make sure that when it wakes it finds there is nothing to do. > > Otherwise, it will loudly complain that the ELSP port tracking no longer > > matches the hardware, and we will be mightly confused. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > --- > > drivers/gpu/drm/i915/i915_gem.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 1353491c1010..ae3ce1314bd1 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -3092,6 +3092,13 @@ static void engine_set_wedged(struct intel_engine_cs > > *engine) > > engine->execlist_first = NULL; > > > > spin_unlock_irqrestore(&engine->timeline->lock, flags); > > + > > + /* The port is checked prior to scheduling a tasklet, but > > + * just in case we have suspended the tasklet to do the > > + * wedging make sure that when it wakes, it decides there > > + * is no work to do by clearing the irq_posted bit. > > + */ > > + clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); > > } > > } > > > > > > Or tasklet_kill? Actually I am not sure now how the wedging transition > works for request which have pasted the submit callback, but are not in > the hardware yet (waiting in the priotree). Can't find at the moment > that we have anything dealing with those. We kill the rbtree and the tree itself doesn't hold a reference to the request (just a reference is held for the ports, as prior to submission there is no way we complete the request and so cancel the in-flight reference count). That's the engine->execlist_queue = RB_ROOT; engine->execlist_first = NULL; above. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlist tasklet upon wedging
Quoting Tvrtko Ursulin (2017-06-21 14:33:59)
>
> On 21/06/2017 13:48, Chris Wilson wrote:
> > Highly unlikely, but if the stop_machine() did suspend the tasklet, we
> > want to make sure that when it wakes it finds there is nothing to do.
> > Otherwise, it will loudly complain that the ELSP port tracking no longer
> > matches the hardware, and we will be mightly confused.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 1353491c1010..ae3ce1314bd1 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3092,6 +3092,13 @@ static void engine_set_wedged(struct intel_engine_cs
> > *engine)
> > engine->execlist_first = NULL;
> >
> > spin_unlock_irqrestore(&engine->timeline->lock, flags);
> > +
> > + /* The port is checked prior to scheduling a tasklet, but
> > + * just in case we have suspended the tasklet to do the
> > + * wedging make sure that when it wakes, it decides there
> > + * is no work to do by clearing the irq_posted bit.
> > + */
> > + clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> > }
> > }
> >
> >
>
> Or tasklet_kill?
Hmm, technically not permitted:
void tasklet_kill(struct tasklet_struct *t)
{
if (in_interrupt())
pr_notice("Attempt to kill tasklet from interrupt\n");
while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) {
do {
yield();
} while (test_bit(TASKLET_STATE_SCHED, &t->state));
}
tasklet_unlock_wait(t);
clear_bit(TASKLET_STATE_SCHED, &t->state);
}
Even if we don't trigger the in_interrupt() simply due to having
interrupts disabled, then the potential yield() is illegal from inside
stop_machine().
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlist tasklet upon wedging
On 21/06/2017 14:53, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-06-21 14:33:59) On 21/06/2017 13:48, Chris Wilson wrote: Highly unlikely, but if the stop_machine() did suspend the tasklet, we want to make sure that when it wakes it finds there is nothing to do. Otherwise, it will loudly complain that the ELSP port tracking no longer matches the hardware, and we will be mightly confused. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 1353491c1010..ae3ce1314bd1 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3092,6 +3092,13 @@ static void engine_set_wedged(struct intel_engine_cs *engine) engine->execlist_first = NULL; spin_unlock_irqrestore(&engine->timeline->lock, flags); + + /* The port is checked prior to scheduling a tasklet, but + * just in case we have suspended the tasklet to do the + * wedging make sure that when it wakes, it decides there + * is no work to do by clearing the irq_posted bit. + */ + clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); } } Or tasklet_kill? Actually I am not sure now how the wedging transition works for request which have pasted the submit callback, but are not in the hardware yet (waiting in the priotree). Can't find at the moment that we have anything dealing with those. We kill the rbtree and the tree itself doesn't hold a reference to the request (just a reference is held for the ports, as prior to submission there is no way we complete the request and so cancel the in-flight reference count). That's the engine->execlist_queue = RB_ROOT; engine->execlist_first = NULL; above. Yes of course, don't know where I was looking. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt/vgem_basic: Test DRM_IOCTL_SETVERSION
vgem is a nasty test case for various parts of the core as it is a
virtual device with drm_device.dev == NULL; this includes drm_setversion
for example.
Signed-off-by: Chris Wilson
---
tests/intel-ci/fast-feedback.testlist | 1 +
tests/vgem_basic.c| 31 +++
2 files changed, 32 insertions(+)
diff --git a/tests/intel-ci/fast-feedback.testlist
b/tests/intel-ci/fast-feedback.testlist
index ce7a41f0..abe928d9 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -263,6 +263,7 @@ igt@prime_vgem@basic-read
igt@prime_vgem@basic-sync-default
igt@prime_vgem@basic-wait-default
igt@prime_vgem@basic-write
+igt@vgem_basic@setversion
igt@vgem_basic@create
igt@vgem_basic@debugfs
igt@vgem_basic@dmabuf-export
diff --git a/tests/vgem_basic.c b/tests/vgem_basic.c
index cce9229f..982da73a 100644
--- a/tests/vgem_basic.c
+++ b/tests/vgem_basic.c
@@ -34,6 +34,34 @@
IGT_TEST_DESCRIPTION("Basic sanity check of Virtual GEM module (vGEM).");
+static int __gem_setversion(int fd, drm_set_version_t *sv)
+{
+ int err;
+
+ err = 0;
+ if (igt_ioctl(fd, DRM_IOCTL_SET_VERSION, sv))
+ err = -errno;
+ errno = 0;
+
+ return err;
+}
+
+static void test_setversion(int fd)
+{
+ drm_set_version_t sv;
+
+ memset(&sv, 0, sizeof(sv));
+ sv.drm_di_major = 1; /* must be equal to DRM_IF_MAJOR */
+ sv.drm_di_minor = 4; /* must be less than DRM_IF_MINOR */
+ sv.drm_dd_major = -1; /* don't care */
+ sv.drm_dd_minor = -1; /* don't care */
+ igt_assert_eq(__gem_setversion(fd, &sv), 0);
+
+ igt_info("vgem DRM interface v%d.%d, device v%d.%d\n",
+sv.drm_di_major, sv.drm_di_minor,
+sv.drm_dd_major, sv.drm_dd_minor);
+}
+
static void test_client(int fd)
{
close(drm_open_driver(DRIVER_VGEM));
@@ -381,6 +409,9 @@ igt_main
fd = drm_open_driver(DRIVER_VGEM);
}
+ igt_subtest_f("setversion")
+ test_setversion(fd);
+
igt_subtest_f("second-client")
test_client(fd);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cancel pending execlist tasklet upon wedging
Quoting Tvrtko Ursulin (2017-06-21 15:06:34) > > On 21/06/2017 14:53, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-06-21 14:33:59) > >> > >> On 21/06/2017 13:48, Chris Wilson wrote: > >>> Highly unlikely, but if the stop_machine() did suspend the tasklet, we > >>> want to make sure that when it wakes it finds there is nothing to do. > >>> Otherwise, it will loudly complain that the ELSP port tracking no longer > >>> matches the hardware, and we will be mightly confused. > >>> > >>> Signed-off-by: Chris Wilson > >>> Cc: Tvrtko Ursulin > >>> --- > >>>drivers/gpu/drm/i915/i915_gem.c | 7 +++ > >>>1 file changed, 7 insertions(+) > >>> > >>> diff --git a/drivers/gpu/drm/i915/i915_gem.c > >>> b/drivers/gpu/drm/i915/i915_gem.c > >>> index 1353491c1010..ae3ce1314bd1 100644 > >>> --- a/drivers/gpu/drm/i915/i915_gem.c > >>> +++ b/drivers/gpu/drm/i915/i915_gem.c > >>> @@ -3092,6 +3092,13 @@ static void engine_set_wedged(struct > >>> intel_engine_cs *engine) > >>>engine->execlist_first = NULL; > >>> > >>>spin_unlock_irqrestore(&engine->timeline->lock, flags); > >>> + > >>> + /* The port is checked prior to scheduling a tasklet, but > >>> + * just in case we have suspended the tasklet to do the > >>> + * wedging make sure that when it wakes, it decides there > >>> + * is no work to do by clearing the irq_posted bit. > >>> + */ > >>> + clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); > >>>} > >>>} > >>> > >>> > >> > >> Or tasklet_kill? Actually I am not sure now how the wedging transition > >> works for request which have pasted the submit callback, but are not in > >> the hardware yet (waiting in the priotree). Can't find at the moment > >> that we have anything dealing with those. > > > > We kill the rbtree and the tree itself doesn't hold a reference to the > > request (just a reference is held for the ports, as prior to submission > > there is no way we complete the request and so cancel the in-flight > > reference count). That's the > > > > engine->execlist_queue = RB_ROOT; > > engine->execlist_first = NULL; > > > > above. > > Yes of course, don't know where I was looking. > > Reviewed-by: Tvrtko Ursulin Discussion is always worthwhile, we've caught many little bugs today alone just by asking questions. :) Pushed this little patch as it makes reasoning about i915_gem_set_wedged() a smidgen easier. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Break modeset deadlocks on reset
Trying to do a modeset from within a reset is fraught with danger. We
can fall into a cyclic deadlock where the modeset is waiting on a
previous modeset that is waiting on a request, and since the GPU hung
that request completion is waiting on the reset. As modesetting doesn't
allow its locks to be broken and restarted, or for its *own* reset
mechanism to take over the display, we have to do something very
evil instead. If we detect that we are stuck waiting to prepare the
display reset (by using a very simple timeout), resort to cancelling all
in-flight requests and throwing the user data into /dev/null, which is
marginally better than the driver locking up and keeping that data to
itself.
This is not a fix; this is just a workaround that unbreaks machines
until we can resolve the deadlock in a way that doesn't lose data!
v2: Move the retirement from set-wegded to the i915_reset() error path,
after which we no longer any delayed worker cleanup for
i915_handle_error()
v3: C abuse for syntactic sugar
References: https://bugs.freedesktop.org/show_bug.cgi?id=99093
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_gem.c | 18 -
drivers/gpu/drm/i915/i915_irq.c | 45 -
3 files changed, 49 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d1aa10c9cc5d..1df957b986c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1914,6 +1914,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
error:
i915_gem_set_wedged(dev_priv);
+ i915_gem_retire_requests(dev_priv);
goto finish;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ae3ce1314bd1..36d838677982 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3062,7 +3062,8 @@ static void engine_set_wedged(struct intel_engine_cs
*engine)
/* Mark all executing requests as skipped */
spin_lock_irqsave(&engine->timeline->lock, flags);
list_for_each_entry(request, &engine->timeline->requests, link)
- dma_fence_set_error(&request->fence, -EIO);
+ if (!i915_gem_request_completed(request))
+ dma_fence_set_error(&request->fence, -EIO);
spin_unlock_irqrestore(&engine->timeline->lock, flags);
/* Mark all pending requests as complete so that any concurrent
@@ -3108,6 +3109,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ set_bit(I915_WEDGED, &i915->gpu_error.flags);
for_each_engine(engine, i915, id)
engine_set_wedged(engine);
@@ -3116,20 +3118,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
{
- lockdep_assert_held(&dev_priv->drm.struct_mutex);
- set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
-
- /* Retire completed requests first so the list of inflight/incomplete
-* requests is accurate and we don't try and mark successful requests
-* as in error during __i915_gem_set_wedged_BKL().
-*/
- i915_gem_retire_requests(dev_priv);
-
stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
-
- i915_gem_contexts_lost(dev_priv);
-
- mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
@@ -3184,6 +3173,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
* context and do not require stop_machine().
*/
intel_engines_reset_default_submission(i915);
+ i915_gem_contexts_lost(i915);
smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
clear_bit(I915_WEDGED, &i915->gpu_error.flags);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1c7d1a04612..c948a5bd031c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2599,6 +2599,46 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
return ret;
}
+struct wedge_me {
+ struct delayed_work work;
+ struct drm_i915_private *i915;
+ const char *name;
+};
+
+static void wedge_me(struct work_struct *work)
+{
+ struct wedge_me *w = container_of(work, typeof(*w), work.work);
+
+ dev_err(w->i915->drm.dev,
+ "%s timed out, cancelling all in-flight rendering.\n",
+ w->name);
+ i915_gem_set_wedged(w->i915);
+}
+
+static void __init_wedge(struct wedge_me *w,
+struct drm_i915_private *i915,
+long timeout,
+const char *name)
+{
+ w->i915 = i915;
+ w->name = name;
+
+ INIT_DELAYED_WOR
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Addition wrapper for fixed16.16 operation
Hi, Thanks for review :) -Mahesh On Wednesday 21 June 2017 03:10 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op wo 21-06-2017 om 11:44 [+0530]: This patch introduce addition wrapper for fixed point 16.16 operations. Which will be used by later patches to avoid direct member variables access of fixed_16_16_t structure. add_fixed16 : takes 2 fixed_16_16_t variable & returns fixed_16_16_t add_fixed16_u32 : takes fixed_16_16_t & u32 variable & returns fixed_16_16_t Much easier to review. :) Reviewed-by: Maarten Lankhorst for first 4 patches. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic-helper: Simplify commit tracking locking
On Wed, Jun 21, 2017 at 11:16:27AM +0200, Daniel Vetter wrote:
> The crtc->commit_lock only protects commit_list and commit_entry. If
> we chase the pointer from the drm_atomic_state update structure, then
> we don't need any locks (since we hold a reference already).
>
> Simplify the locking accordingly.
>
> Noticed while reviewing a patch from Boris.
>
> Cc: Boris Brezillon
> Signed-off-by: Daniel Vetter
After reading this over a few times, I've convinced myself that it does
the right thing.
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 86d3093c6c9b..9bf86eb87fe1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1680,9 +1680,7 @@ void drm_atomic_helper_commit_hw_done(struct
> drm_atomic_state *old_state)
>
> /* backend must have consumed any event by now */
> WARN_ON(new_crtc_state->event);
> - spin_lock(&crtc->commit_lock);
> complete_all(&commit->hw_done);
> - spin_unlock(&crtc->commit_lock);
> }
> }
> EXPORT_SYMBOL(drm_atomic_helper_commit_hw_done);
> @@ -1711,7 +1709,6 @@ void drm_atomic_helper_commit_cleanup_done(struct
> drm_atomic_state *old_state)
> if (WARN_ON(!commit))
> continue;
>
> - spin_lock(&crtc->commit_lock);
> complete_all(&commit->cleanup_done);
> WARN_ON(!try_wait_for_completion(&commit->hw_done));
>
> @@ -1721,8 +1718,6 @@ void drm_atomic_helper_commit_cleanup_done(struct
> drm_atomic_state *old_state)
> if (try_wait_for_completion(&commit->flip_done))
> goto del_commit;
>
> - spin_unlock(&crtc->commit_lock);
> -
> /* We must wait for the vblank event to signal our completion
>* before releasing our reference, since the vblank work does
>* not hold a reference of its own. */
> @@ -1732,8 +1727,8 @@ void drm_atomic_helper_commit_cleanup_done(struct
> drm_atomic_state *old_state)
> DRM_ERROR("[CRTC:%d:%s] flip_done timed out\n",
> crtc->base.id, crtc->name);
>
> - spin_lock(&crtc->commit_lock);
> del_commit:
> + spin_lock(&crtc->commit_lock);
> list_del(&commit->commit_entry);
> spin_unlock(&crtc->commit_lock);
> }
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
So back when the i915 power well support landed in
commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
Author: Wang Xingchao
Date: Thu May 30 22:07:10 2013 +0800
ALSA: hda - Add power-welll support for haswell HDA
the logic to handle the cross-module depencies was hand-rolled using a
async work item, and that just doesn't work.
The correct way to handle cross-module deps is either:
- request_module + failing when the other module isn't there
OR
- failing the module load with EPROBE_DEFER.
You can't mix them, if you do then the entire load path just
busy-spins blowing through cpu cycles forever with no way to stop
this.
snd-hda-intel does mix it, because the hda codec drivers are loaded
using request_module, but the i915 depency is handled using
PROBE_DEFER (or well, should be, but I haven't found any code at all).
This is a major pain when trying to debug i915 load failures.
This patch here is a horrible hackish attempt at somewhat correctly
wriing EPROBE_DEFER through. Stuff that's missing:
- Check all the other places where load errors are conveniently
dropped on the floor.
- Also fix up the firmware_cb path.
- Drop the debug noise I've left in to make it clear this isn't
anything for merging.
Cheers, Daniel
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: "GitAuthor: Daniel Vetter"
Cc: Guneshwor Singh
Cc: Hardik T Shah
Cc: Julia Lawall
Cc: Vinod Koul
Cc: "Subhransu S. Prusty"
Cc: Libin Yang
Cc: linux-ker...@vger.kernel.org
---
drivers/base/dd.c | 2 ++
sound/pci/hda/hda_bind.c | 6 +++---
sound/pci/hda/hda_controller.c | 8 +++-
sound/pci/hda/hda_intel.c | 13 +
4 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4882f06d12df..842bc8782124 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -17,6 +17,8 @@
* This file is released under the GPLv2
*/
+#define DEBUG
+
#include
#include
#include
diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c
index 6efadbfb3fe3..0bc164a17493 100644
--- a/sound/pci/hda/hda_bind.c
+++ b/sound/pci/hda/hda_bind.c
@@ -253,7 +253,7 @@ static int codec_bind_generic(struct hda_codec *codec)
request_codec_module(codec);
if (codec_probed(codec))
return 0;
- return -ENODEV;
+ return -EPROBE_DEFER;
}
#if IS_ENABLED(CONFIG_SND_HDA_GENERIC)
@@ -289,8 +289,8 @@ int snd_hda_codec_configure(struct hda_codec *codec)
codec_bind_module(codec);
if (!codec->preset) {
err = codec_bind_generic(codec);
- if (err < 0) {
- codec_err(codec, "Unable to bind the codec\n");
+ if (WARN_ON(err < 0)) {
+ codec_err(codec, "Unable to bind the codec, err=%i\n",
err);
goto error;
}
}
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
index 3715a5725613..4b4262c72327 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -1337,9 +1337,15 @@ EXPORT_SYMBOL_GPL(azx_probe_codecs);
/* configure each codec instance */
int azx_codec_configure(struct azx *chip)
{
+ int ret;
+
struct hda_codec *codec;
list_for_each_codec(codec, &chip->bus) {
- snd_hda_codec_configure(codec);
+ ret = snd_hda_codec_configure(codec);
+ if (ret) {
+ printk("bailing real hard %i\n", ret);
+ return ret;
+ }
}
return 0;
}
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 07ea7f48aa01..8241387cc8ca 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1649,7 +1649,8 @@ static void azx_check_snoop_available(struct azx *chip)
static void azx_probe_work(struct work_struct *work)
{
struct hda_intel *hda = container_of(work, struct hda_intel,
probe_work);
- azx_probe_continue(&hda->chip);
+
+ WARN_ON(1);
}
static int default_bdl_pos_adj(struct azx *chip)
@@ -2158,7 +2159,6 @@ static int azx_probe(struct pci_dev *pci,
azx_firmware_cb);
if (err < 0)
goto out_free;
- schedule_probe = false; /* continued in azx_firmware_cb() */
}
#endif /* CONFIG_SND_HDA_PATCH_LOADER */
@@ -2167,8 +2167,13 @@ static int azx_probe(struct pci_dev *pci,
dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in
CONFIG_SND_HDA_I915\n");
#endif
- if (schedule_probe)
- schedule_work(&hda->probe_work);
+ if (schedule_probe) {
+ err = azx_probe_continue(chip);
+ if (err) {
+ printk("hit the right error return finally! err=%i\n",
err);
+ goto out_free;
+ }
+ }
dev++;
if (chip->disabled)
--
2.5.5
Re: [Intel-gfx] [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
Quoting Daniel Vetter (2017-06-21 16:08:54) > So back when the i915 power well support landed in > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6 > Author: Wang Xingchao > Date: Thu May 30 22:07:10 2013 +0800 > > ALSA: hda - Add power-welll support for haswell HDA > > the logic to handle the cross-module depencies was hand-rolled using a > async work item, and that just doesn't work. > > The correct way to handle cross-module deps is either: > - request_module + failing when the other module isn't there > > OR > > - failing the module load with EPROBE_DEFER. > > You can't mix them, if you do then the entire load path just > busy-spins blowing through cpu cycles forever with no way to stop > this. > > snd-hda-intel does mix it, because the hda codec drivers are loaded > using request_module, but the i915 depency is handled using > PROBE_DEFER (or well, should be, but I haven't found any code at all). > This is a major pain when trying to debug i915 load failures. > > This patch here is a horrible hackish attempt at somewhat correctly > wriing EPROBE_DEFER through. Stuff that's missing: > - Check all the other places where load errors are conveniently > dropped on the floor. > - Also fix up the firmware_cb path. > - Drop the debug noise I've left in to make it clear this isn't > anything for merging. This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was continuously spewing previously, and now the system is usable again. Thanks, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
On Wed, 21 Jun 2017 17:23:57 +0200, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-06-21 16:08:54) > > So back when the i915 power well support landed in > > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6 > > Author: Wang Xingchao > > Date: Thu May 30 22:07:10 2013 +0800 > > > > ALSA: hda - Add power-welll support for haswell HDA > > > > the logic to handle the cross-module depencies was hand-rolled using a > > async work item, and that just doesn't work. > > > > The correct way to handle cross-module deps is either: > > - request_module + failing when the other module isn't there > > > > OR > > > > - failing the module load with EPROBE_DEFER. > > > > You can't mix them, if you do then the entire load path just > > busy-spins blowing through cpu cycles forever with no way to stop > > this. > > > > snd-hda-intel does mix it, because the hda codec drivers are loaded > > using request_module, but the i915 depency is handled using > > PROBE_DEFER (or well, should be, but I haven't found any code at all). > > This is a major pain when trying to debug i915 load failures. > > > > This patch here is a horrible hackish attempt at somewhat correctly > > wriing EPROBE_DEFER through. Stuff that's missing: > > - Check all the other places where load errors are conveniently > > dropped on the floor. > > - Also fix up the firmware_cb path. > > - Drop the debug noise I've left in to make it clear this isn't > > anything for merging. > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was > continuously spewing previously, and now the system is usable again. Could you give a failing scenario? I'm not opposing to the suggested solution, we need to fix the mess in anyway, but I just would like to know how to trigger the problem easily. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Break modeset deadlocks on reset (rev3)
== Series Details == Series: drm/i915: Break modeset deadlocks on reset (rev3) URL : https://patchwork.freedesktop.org/series/26059/ State : success == Summary == Series 26059v3 drm/i915: Break modeset deadlocks on reset https://patchwork.freedesktop.org/api/1.0/series/26059/revisions/3/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-snb-2600) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101516 Test prime_busy: Subgroup basic-wait-after-default: dmesg-warn -> PASS (fi-skl-6700hq) fdo#101515 +3 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101516 https://bugs.freedesktop.org/show_bug.cgi?id=101516 fdo#101515 https://bugs.freedesktop.org/show_bug.cgi?id=101515 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:427s fi-bsw-n3050 total:278 pass:241 dwarn:1 dfail:0 fail:0 skip:36 time:520s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:510s fi-byt-j1900 total:278 pass:253 dwarn:1 dfail:0 fail:0 skip:24 time:491s fi-byt-n2820 total:278 pass:249 dwarn:1 dfail:0 fail:0 skip:28 time:481s fi-glk-2atotal:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:596s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:415s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:497s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:462s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:573s fi-kbl-r total:278 pass:259 dwarn:1 dfail:0 fail:0 skip:18 time:575s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:454s fi-skl-6700hqtotal:278 pass:220 dwarn:3 dfail:0 fail:30 skip:24 time:341s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:464s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:479s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:402s 40b1ea11ae139b383d62f22ed2007db408f42a3e drm-tip: 2017y-06m-21d-14h-16m-17s UTC integration manifest 37a5010 drm/i915: Break modeset deadlocks on reset == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5015/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 10/15] drm/i915: add compute-config for YCBCR outputs
Regards
Shashank
On 6/20/2017 7:50 PM, Ander Conselvan De Oliveira wrote:
On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote:
This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
V2: Split the patch into two, kept helper functions in DRM layer.
V3: Changed the compute_config function based on new DRM API.
V4: Rebase
Cc: Ville Syrjala
Cc: Daniel Vetter
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 ++
drivers/gpu/drm/i915/intel_hdmi.c| 93 ++--
3 files changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f9bf0d5..da29536 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+ PIPE_CONF_CHECK_I(hdmi_output);
PIPE_CONF_CHECK_I(has_audio);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1727350..38fe56c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -780,6 +780,9 @@ struct intel_crtc_state {
/* HDMI High TMDS char rate ratio */
bool hdmi_high_tmds_clock_ratio;
+
+ /* HDMI output type */
+ enum drm_hdmi_output_type hdmi_output;
};
struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 170abc4..22da5cd 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1317,7 +1317,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
return status;
}
-static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
+static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
+ enum drm_hdmi_output_type hdmi_out)
{
struct drm_i915_private *dev_priv =
to_i915(crtc_state->base.crtc->dev);
@@ -1329,6 +1330,16 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
if (HAS_GMCH_DISPLAY(dev_priv))
return false;
+ if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
+ /*
+* HDMI spec says YCBCR422 is 12bpc, but its not a deep
+* color format. So respect the spec, and not allow this
+* to be deep color
+*/
+ DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
+ return false;
+ }
+
I suppose this is about the remark in section 6.2.4 of the HDMI 1.4 spec. If I'm
interpreting that correctly, the relevant information for us is that the TMDS
clock doesn't need to be multiplied by 1.5, unlike other 12 bpc scenarios.
To me it seems misleading to say 12 bpc is not possible in that case. I'm
wondering if it makes more sense to split this in two parts:
(i) What is the TMDS clock scaling for a given output format?
(ii) Is the format and scaled TMDS clock supported by the source and the sink?
My interpretation of the spec was YCBCR422 is a 12 bit encoding scheme,
but its not a deep color mode (I guess that's what Ville also thought)
In I915, 12_bpc is always considered as deep color mode case, whereas I
have seen EDIDs which indicate support for YCBCR422 but they do not
indicate deep color support.
Combining these information above, we thought its safe to consider that
422 is not a deep color mode, and hence this call.
/*
* HDMI 12bpc affects the clocks, so it's only possible
* when not cloning with other encoder types.
@@ -1342,6 +1353,12 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
if (connector_state->crtc != crtc_state->base.crtc)
continue;
+ if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+ if (!(info->hdmi.y420_dc_modes &
+ DRM_EDID_YCBCR420_DC_36))
+ return false;
+ }
+
if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
return false;
}
@@ -1354,6 +1371,65 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
return true;
}
+static u8
+intel_hdmi_get_src_output_support(struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = connector->dev->dev_private;
+ u8 supported_outputs = DRM_COLOR_FORMAT_RGB444;
[Intel-gfx] ✗ Fi.CI.BAT: failure for BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
== Series Details == Series: BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support URL : https://patchwork.freedesktop.org/series/26154/ State : failure == Summary == Series 26154v1 BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support https://patchwork.freedesktop.org/api/1.0/series/26154/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-snb-2520m) pass -> SKIP (fi-snb-2600) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-hsw-4770r) pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-skl-6700hq) pass -> SKIP (fi-skl-6700k) pass -> SKIP (fi-bxt-j4205) pass -> SKIP (fi-kbl-7500u) pass -> SKIP (fi-kbl-r) pass -> SKIP (fi-glk-2a) Test core_prop_blob: Subgroup basic: pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-snb-2520m) pass -> SKIP (fi-snb-2600) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-hsw-4770r) pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-skl-6700hq) pass -> SKIP (fi-skl-6700k) pass -> SKIP (fi-bxt-j4205) pass -> SKIP (fi-kbl-7500u) pass -> SKIP (fi-kbl-r) pass -> SKIP (fi-glk-2a) Test drv_getparams_basic: Subgroup basic-eu-total: pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-snb-2520m) pass -> SKIP (fi-snb-2600) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-hsw-4770r) pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-skl-6700hq) pass -> SKIP (fi-skl-6700k) pass -> SKIP (fi-bxt-j4205) pass -> SKIP (fi-kbl-7500u) pass -> SKIP (fi-kbl-r) pass -> SKIP (fi-glk-2a) Subgroup basic-subslice-total: pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-snb-2520m) pass -> SKIP (fi-snb-2600) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-hsw-4770r) pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-skl-6700hq) pass -> SKIP (fi-skl-6700k) pass -> SKIP (fi-bxt-j4205) pass -> SKIP (fi-kbl-7500u) pass -> SKIP (fi-kbl-r) pass -> SKIP (fi-glk-2a) Test drv_hangman: Subgroup error-state-basic: pass -> SKIP (fi-ilk-650) pass -> SKIP (fi-snb-2520m) pass -> SKIP (fi-snb-2600) pass -> SKIP (fi-ivb-3520m) pass -> SKIP (fi-ivb-3770) pass -> SKIP (fi-byt-j1900) pass -> SKIP (fi-byt-n2820) pass -> SKIP (fi-hsw-4770) pass -> SKIP (fi-hsw-4770r) pass -> SKIP (fi-bdw-5557u) pass -> SKIP (fi-bsw-n3050) pass -> SKIP (fi-skl-6700hq)
Re: [Intel-gfx] [PATCH v2] drm/i915: Break modeset deadlocks on reset
Op 21-06-17 om 16:24 schreef Chris Wilson:
> Trying to do a modeset from within a reset is fraught with danger. We
> can fall into a cyclic deadlock where the modeset is waiting on a
> previous modeset that is waiting on a request, and since the GPU hung
> that request completion is waiting on the reset. As modesetting doesn't
> allow its locks to be broken and restarted, or for its *own* reset
> mechanism to take over the display, we have to do something very
> evil instead. If we detect that we are stuck waiting to prepare the
> display reset (by using a very simple timeout), resort to cancelling all
> in-flight requests and throwing the user data into /dev/null, which is
> marginally better than the driver locking up and keeping that data to
> itself.
>
> This is not a fix; this is just a workaround that unbreaks machines
> until we can resolve the deadlock in a way that doesn't lose data!
>
> v2: Move the retirement from set-wegded to the i915_reset() error path,
> after which we no longer any delayed worker cleanup for
> i915_handle_error()
> v3: C abuse for syntactic sugar
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=99093
> Signed-off-by: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 18 -
> drivers/gpu/drm/i915/i915_irq.c | 45
> -
> 3 files changed, 49 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index d1aa10c9cc5d..1df957b986c7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1914,6 +1914,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
>
> error:
> i915_gem_set_wedged(dev_priv);
> + i915_gem_retire_requests(dev_priv);
> goto finish;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ae3ce1314bd1..36d838677982 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3062,7 +3062,8 @@ static void engine_set_wedged(struct intel_engine_cs
> *engine)
> /* Mark all executing requests as skipped */
> spin_lock_irqsave(&engine->timeline->lock, flags);
> list_for_each_entry(request, &engine->timeline->requests, link)
> - dma_fence_set_error(&request->fence, -EIO);
> + if (!i915_gem_request_completed(request))
> + dma_fence_set_error(&request->fence, -EIO);
> spin_unlock_irqrestore(&engine->timeline->lock, flags);
>
> /* Mark all pending requests as complete so that any concurrent
> @@ -3108,6 +3109,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
>
> + set_bit(I915_WEDGED, &i915->gpu_error.flags);
> for_each_engine(engine, i915, id)
> engine_set_wedged(engine);
>
> @@ -3116,20 +3118,7 @@ static int __i915_gem_set_wedged_BKL(void *data)
>
> void i915_gem_set_wedged(struct drm_i915_private *dev_priv)
> {
> - lockdep_assert_held(&dev_priv->drm.struct_mutex);
> - set_bit(I915_WEDGED, &dev_priv->gpu_error.flags);
> -
> - /* Retire completed requests first so the list of inflight/incomplete
> - * requests is accurate and we don't try and mark successful requests
> - * as in error during __i915_gem_set_wedged_BKL().
> - */
> - i915_gem_retire_requests(dev_priv);
> -
> stop_machine(__i915_gem_set_wedged_BKL, dev_priv, NULL);
> -
> - i915_gem_contexts_lost(dev_priv);
> -
> - mod_delayed_work(dev_priv->wq, &dev_priv->gt.idle_work, 0);
> }
>
> bool i915_gem_unset_wedged(struct drm_i915_private *i915)
> @@ -3184,6 +3173,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> *i915)
>* context and do not require stop_machine().
>*/
> intel_engines_reset_default_submission(i915);
> + i915_gem_contexts_lost(i915);
>
> smp_mb__before_atomic(); /* complete takeover before enabling execbuf */
> clear_bit(I915_WEDGED, &i915->gpu_error.flags);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b1c7d1a04612..c948a5bd031c 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2599,6 +2599,46 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
> return ret;
> }
>
> +struct wedge_me {
> + struct delayed_work work;
> + struct drm_i915_private *i915;
> + const char *name;
> +};
> +
> +static void wedge_me(struct work_struct *work)
> +{
> + struct wedge_me *w = container_of(work, typeof(*w), work.work);
> +
> + dev_err(w->i915->drm.dev,
> + "%s timed out, cancelling all in-flight rendering.\n",
> + w->name);
> + i915_gem_set_wedged(w->i915);
> +}
> +
> +static void __init_wedge(struct wedge_me *w,
> +
