[Intel-gfx] [PATCH] Revert "net/sch_generic: Shut up noise"
This reverts commit c5cab0d5fc9aa1cf14c7bc7ea88c80155e46e22f.
Jani believes the noise is gone, so let's see whether it's really
gone, before we drop this hack.
Cc: "Saarinen, Jani"
Cc: Martin Peres
Signed-off-by: Daniel Vetter
---
net/sched/sch_generic.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index aef2582badc5..39c144b6ff98 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -468,12 +468,7 @@ static void dev_watchdog(struct timer_list *t)
}
}
- /* The noise is pissing off our CI and upstream doesn't
-* move on the bug report:
-*
-* https://bugzilla.kernel.org/show_bug.cgi?id=196399
-*/
- if (some_queue_timedout && 0) {
+ if (some_queue_timedout) {
WARN_ONCE(1, KERN_INFO "NETDEV WATCHDOG: %s
(%s): transmit queue %u timed out\n",
dev->name, netdev_drivername(dev), i);
dev->netdev_ops->ndo_tx_timeout(dev);
--
2.17.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 Revert "net/sch_generic: Shut up noise"
== Series Details == Series: Revert "net/sch_generic: Shut up noise" URL : https://patchwork.freedesktop.org/series/43878/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250 -> Patchwork_9136 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43878/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9136 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) Possible fixes igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> SKIP igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: DMESG-FAIL (fdo#102614, fdo#106103) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (43 -> 39) == Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4250 -> Patchwork_9136 CI_DRM_4250: 01b6423d3fabdb32ac69bc155dd5beb87c6761d8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9136: 0699f83a89c65de3f632478f0faad2a70974738a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0699f83a89c6 Revert "net/sch_generic: Shut up noise" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9136/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 00/41] drm/i915: Implement HDCP2.2
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Tuesday, May 29, 2018 12:27 PM > To: C, Ramalingam > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; > jani.nik...@linux.intel.com; Winkler, Tomas ; > Usyskin, Alexander ; Shankar, Uma > ; Sharma, Shashank > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2 > > On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote: > > The sequence for HDCP2.2 authentication and encryption is implemented > > in I915. Encoder specific implementations are moved into hdcp_shim. > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series introduces > > a client driver for mei bus, so that for HDCP2.2 authentication, > > HDCP2.2 stack in I915 can avail the services from ME FW. > > > > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and > > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI Bus > > then we need an option to disable the HDCP2.2 in I915 (like > > DRM_I915_HDCP2.2!?). Till then they are binded. > > > > Userspace interface remains unchanged as version agnostic. When > > userspace request for HDCP enable, Kernel will detect the HDCP source > > and sink's HDCP version(1.4/2.2)capability and enable the best capable > > version for that combination. > > > > This series enables the HDCP2.2 for Type0 content streams. > > > > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of v3. > > Thanks Daniel vetter for guiding me to test and confirm that there is > > no locking issue with respect to notifier usage between I915 and MEI_HDCP. > > > > Major Changes in v4: > > - GMBus Changes to implement the burst read as generic > > [Jani, Ville and Daniel] > > - Polling is added for extra Notifier notification when I915 and > > MEI_HDCP are modules. > > - Comment and style issues and typos are fixed [Uma and Alexander] > > - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915. > > - Fixed the #if in include/linux/mei_hdcp.h for build issues. > > > > GMBus changes are added here for completeness of the series. They are > > in review at https://patchwork.freedesktop.org/series/41632/ also. > > Please reply with a link to your github here (and include it in your next > cover > letter too). I can't ever find it when I need it :-/ You can find a github repo for HDCP2.2 v4 series at https://github.com/ramalingampc2008/drm-tip Thanks, Ram > > Thanks, Daniel > > > > > Ramalingam C (40): > > drm: hdcp2.2 authentication msg definitions > > drm: HDMI and DP specific HDCP2.2 defines > > misc/mei/hdcp: Client driver for HDCP application > > misc/mei/hdcp: Notifier chain for mei cldev state change > > misc/mei/hdcp: Define ME FW interface for HDCP2.2 > > linux/mei: Header for mei_hdcp driver interface > > misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > > misc/mei/hdcp: Verify Receiver Cert and prepare km > > misc/mei/hdcp: Verify H_prime > > misc/mei/hdcp: Store the HDCP Pairing info > > misc/mei/hdcp: Initiate Locality check > > misc/mei/hdcp: Verify L_prime > > misc/mei/hdcp: Prepare Session Key > > misc/mei/hdcp: Repeater topology verification and ack > > misc/mei/hdcp: Verify M_prime > > misc/mei/hdcp: Enabling the HDCP authentication > > misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > > drm/i915: wrapping all hdcp var into intel_hdcp > > drm/i915: Define HDCP2.2 related variables > > drm/i915: Define Intel HDCP2.2 registers > > drm/i915: Wrappers for mei HDCP2.2 services > > drm/i915: Implement HDCP2.2 receiver authentication > > drm/i915: Implement HDCP2.2 repeater authentication > > drm/i915: Enable and Disable HDCP2.2 port encryption > > drm/i915: Implement HDCP2.2 En/Dis-able > > drm/i915: Implement HDCP2.2 link integrity check > > drm/i915: Handle HDCP2.2 downstream topology change > > drm/i915: Pullout the bksv read and validation > > drm/i915: Initialize HDCP2.2 and its MEI interface > > drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable > > drm/i915: Enable superior HDCP ver that is capable > > drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure > > drm/i915: hdcp_check_link only on CP_IRQ > > drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ > > drm/i915/gmbus: Increase the Bytes per Rd/Wr Op > > drm/i915/gmbus: Enable burst read > > drm/i915: Implement the HDCP2.2 support for DP > > drm/i915: Implement the HDCP2.2 support for HDMI > > drm/i915: Add HDCP2.2 support for DP connectors > > drm/i915: Add HDCP2.2 support for HDMI connectors > > > > Tomas Winkler (1): > > mei: bus: whitelist hdcp client > > > > drivers/gpu/drm/i915/Kconfig |1 + > > drivers/gpu/drm/i915/i915_drv.h |3 + > > drivers/gpu/drm/i915/i915_reg.h | 34 ++ > > drivers/gpu/drm/i915/intel_display.c |7 +- > > drivers/gpu/drm/i915/int
Re: [Intel-gfx] [PATCH 4/9] drm: Begin an API for in-kernel clients
On Mon, May 28, 2018 at 03:26:48PM +0200, Noralf Trønnes wrote:
>
> Den 24.05.2018 10.42, skrev Daniel Vetter:
> > On Wed, May 23, 2018 at 04:34:06PM +0200, Noralf Trønnes wrote:
> > > This the beginning of an API for in-kernel clients.
> > > First out is a way to get a framebuffer backed by a dumb buffer.
> > >
> > > Only GEM drivers are supported.
> > > The original idea of using an exported dma-buf was dropped because it
> > > also creates an anonomous file descriptor which doesn't work when the
> > > buffer is created from a kernel thread. The easy way out is to use
> > > drm_driver.gem_prime_vmap to get the virtual address, which requires a
> > > GEM object. This excludes the vmwgfx driver which is the only non-GEM
> > > driver apart from the legacy ones. A solution for vmwgfx will have to be
> > > worked out later if it wants to support the client API which it probably
> > > will when we have a bootsplash client.
> > >
> > > Signed-off-by: Noralf Trønnes
> > A few small nits below, with those addressed:
> >
> > Reviewed-by: Daniel Vetter
> > > ---
>
> [...]
>
> > > +/**
> > > + * drm_client_new - Create a DRM client
> > > + * @dev: DRM device
> > > + *
> > > + * Returns:
> > > + * Pointer to a client or an error pointer on failure.
> > > + */
> > > +struct drm_client_dev *drm_client_new(struct drm_device *dev)
> > Api nitpick:
> >
> > int drm_client_init(struct drm_device *dev,
> > struct drm_client_dev *client)
> >
> > and dropping the kzalloc from this structure here. This allows users of
> > this to embed the client struct into their own thing, which means the
> > ->private backpointer isn't necessary. Allowing embedding is the preferred
> > interface in the kernel (since it's strictly more powerful, you can always
> > just kzalloc + _init to get the _new behaviour).
> >
> > > +{
> > > + struct drm_client_dev *client;
> > > + int ret;
> > > +
> > > + if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> > > + !dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
> > > + return ERR_PTR(-ENOTSUPP);
> > > +
> > > + client = kzalloc(sizeof(*client), GFP_KERNEL);
> > > + if (!client)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + client->dev = dev;
> > > +
> > > + ret = drm_client_alloc_file(client);
> > > + if (ret) {
> > > + kfree(client);
> > > + return ERR_PTR(ret);
> > > + }
> > > +
> > > + return client;
> > > +}
> > > +EXPORT_SYMBOL(drm_client_new);
> > > +
>
> [...]
>
> > > +static struct drm_client_buffer *
> > > +drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32
> > > height, u32 format)
> > > +{
> > > + struct drm_mode_create_dumb dumb_args = { };
> > > + struct drm_device *dev = client->dev;
> > > + struct drm_client_buffer *buffer;
> > > + struct drm_gem_object *obj;
> > > + void *vaddr;
> > > + int ret;
> > > +
> > > + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> > > + if (!buffer)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + buffer->client = client;
> > > +
> > > + dumb_args.width = width;
> > > + dumb_args.height = height;
> > > + dumb_args.bpp = drm_format_plane_cpp(format, 0) * 8;
> > > + ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
> > > + if (ret)
> > > + goto err_free;
> > > +
> > > + buffer->handle = dumb_args.handle;
> > > + buffer->pitch = dumb_args.pitch;
> > > +
> > > + obj = drm_gem_object_lookup(client->file, dumb_args.handle);
> > > + if (!obj) {
> > > + ret = -ENOENT;
> > > + goto err_delete;
> > > + }
> > > +
> > > + buffer->gem = obj;
> > > +
> > I'm paranoid, I think an
> >
> > if (WARN_ON(!gem_prime_vmap))
> > return -EINVAL;
> >
> > would be cool here.
>
> This is already checked in drm_client_init().
Yeah I noticed later on. I think rechecking for safety here can't hurt,
but up to you.
-Daniel
>
> Noralf.
>
> > Also perhaps the following comment:
> >
> > /*
> > * FIXME: The dependency on GEM here isn't required, we could
> > * convert the driver handle to a dma-buf instead and use the
> > * backend-agnostic dma-buf vmap support instead. This would
> > * require that the handle2fd prime ioctl is reworked to pull the
> > * fd_install step out of the driver backend hooks, to make that
> > * final step optional for internal users.
> > */
> >
> >
> > > + vaddr = dev->driver->gem_prime_vmap(obj);
> > > + if (!vaddr) {
> > > + ret = -ENOMEM;
> > > + goto err_delete;
> > > + }
> > > +
> > > + buffer->vaddr = vaddr;
> > > +
> > > + return buffer;
> > > +
> > > +err_delete:
> > > + drm_client_buffer_delete(buffer);
> > > +err_free:
> > > + kfree(buffer);
> > > +
> > > + return ERR_PTR(ret);
> > > +}
>
>
--
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 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function
On Fri, May 25, 2018 at 02:42:02PM +0200, Noralf Trønnes wrote:
>
> Den 24.05.2018 11.16, skrev Daniel Vetter:
> > On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
> > > This is the first step in getting generic fbdev emulation.
> > > A drm_fb_helper_funcs.fb_probe function is added which uses the
> > > DRM client API to get a framebuffer backed by a dumb buffer.
> > >
> > > A transitional hack for tinydrm is needed in order to switch over all
> > > CMA helper drivers in a later patch. This hack will be removed when
> > > tinydrm moves to vmalloc buffers.
> > >
> > > Signed-off-by: Noralf Trønnes
> > > ---
> > > drivers/gpu/drm/drm_fb_helper.c | 164
> > >
> > > include/drm/drm_fb_helper.h | 26 +++
> > > 2 files changed, 190 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 2ee1eaa66188..444c2b4040ea 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -30,11 +30,13 @@
> > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -2928,6 +2930,168 @@ void drm_fb_helper_output_poll_changed(struct
> > > drm_device *dev)
> > > }
> > > EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
> > > +/* @user: 1=userspace, 0=fbcon */
> > > +static int drm_fbdev_fb_open(struct fb_info *info, int user)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > +
> > > + if (!try_module_get(fb_helper->dev->driver->fops->owner))
> > > + return -ENODEV;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int drm_fbdev_fb_release(struct fb_info *info, int user)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > +
> > > + module_put(fb_helper->dev->driver->fops->owner);
> > > +
> > > + return 0;
> > > +}
> > Hm, I thought earlier versions of your patch series had this separately,
> > for everyone. What's the reasons for merging this into the fb_probe
> > implementation.
>
> This is only necessary when struct fb_ops is defined in a library where
> the owner field is the library module and not the driver module.
> I realised that with this generic version it's highly unlikely that we
> get another library that defines struct fb_ops, so it's only needed here.
Hm, I'm still not 100% convinced we can fully subsume the tinydrm fbdev
code with the generic one, due to the varios slight issues around defio
tracking that we still have.
But it's also easy to export this later on. If you add a comment
explaining what you explained here to the commit message I think this is
all fine with me as-is.
-Daniel
>
> Noralf.
>
> > > +
> > > +/*
> > > + * fb_ops.fb_destroy is called by the last put_fb_info() call at the end
> > > of
> > > + * unregister_framebuffer() or fb_release().
> > > + */
> > > +static void drm_fbdev_fb_destroy(struct fb_info *info)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > + struct fb_ops *fbops = NULL;
> > > +
> > > + DRM_DEBUG("\n");
> > > +
> > > + if (fb_helper->fbdev->fbdefio) {
> > > + fb_deferred_io_cleanup(fb_helper->fbdev);
> > > + fbops = fb_helper->fbdev->fbops;
> > > + }
> > > +
> > > + drm_fb_helper_fini(fb_helper);
> > > + drm_client_framebuffer_delete(fb_helper->buffer);
> > > + drm_client_free(fb_helper->client);
> > > + kfree(fb_helper);
> > > + kfree(fbops);
> > > +}
> > Hm, if we go with the idea that drm_clients could auto-unregister through
> > a callback, then I expect this will lead to some control inversion. But we
> > can fix that later on.
> >
> > > +
> > > +static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct
> > > *vma)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > +
> > > + if (fb_helper->dev->driver->gem_prime_mmap)
> > > + return
> > > fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
> > > + else
> > > + return -ENODEV;
> > > +}
> > > +
> > > +static struct fb_ops drm_fbdev_fb_ops = {
> > > + /* No need to set owner, this module is already pinned by the driver. */
> > I'd still set it, means less thinking since more obviously correct.
> >
> > > + DRM_FB_HELPER_DEFAULT_OPS,
> > > + .fb_open= drm_fbdev_fb_open,
> > > + .fb_release = drm_fbdev_fb_release,
> > > + .fb_destroy = drm_fbdev_fb_destroy,
> > > + .fb_mmap= drm_fbdev_fb_mmap,
> > > + .fb_read= drm_fb_helper_sys_read,
> > > + .fb_write = drm_fb_helper_sys_write,
> > > + .fb_fillrect= drm_fb_helper_sys_fillrect,
> > > + .fb_copyarea= drm_fb_helper_sys_copyarea,
> > > + .fb_imageblit = drm_fb_helper_sys_imageblit,
> > Hm, some drivers require the cfb versions of these. In practice I guess
> > there's not much of a difference really,
Re: [Intel-gfx] [PATCH v4 00/41] drm/i915: Implement HDCP2.2
On Tue, May 29, 2018 at 07:51:56AM +, C, Ramalingam wrote: > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Tuesday, May 29, 2018 12:27 PM > > To: C, Ramalingam > > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > > seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; > > jani.nik...@linux.intel.com; Winkler, Tomas ; > > Usyskin, Alexander ; Shankar, Uma > > ; Sharma, Shashank > > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2 > > > > On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote: > > > The sequence for HDCP2.2 authentication and encryption is implemented > > > in I915. Encoder specific implementations are moved into hdcp_shim. > > > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series introduces > > > a client driver for mei bus, so that for HDCP2.2 authentication, > > > HDCP2.2 stack in I915 can avail the services from ME FW. > > > > > > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and > > > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI Bus > > > then we need an option to disable the HDCP2.2 in I915 (like > > > DRM_I915_HDCP2.2!?). Till then they are binded. > > > > > > Userspace interface remains unchanged as version agnostic. When > > > userspace request for HDCP enable, Kernel will detect the HDCP source > > > and sink's HDCP version(1.4/2.2)capability and enable the best capable > > > version for that combination. > > > > > > This series enables the HDCP2.2 for Type0 content streams. > > > > > > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of v3. > > > Thanks Daniel vetter for guiding me to test and confirm that there is > > > no locking issue with respect to notifier usage between I915 and MEI_HDCP. > > > > > > Major Changes in v4: > > > - GMBus Changes to implement the burst read as generic > > > [Jani, Ville and Daniel] > > > - Polling is added for extra Notifier notification when I915 and > > > MEI_HDCP are modules. > > > - Comment and style issues and typos are fixed [Uma and Alexander] > > > - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915. > > > - Fixed the #if in include/linux/mei_hdcp.h for build issues. > > > > > > GMBus changes are added here for completeness of the series. They are > > > in review at https://patchwork.freedesktop.org/series/41632/ also. > > > > Please reply with a link to your github here (and include it in your next > > cover > > letter too). I can't ever find it when I need it :-/ > > You can find a github repo for HDCP2.2 v4 series at > https://github.com/ramalingampc2008/drm-tip Even nicer if you directly supply what I need to feed to git fetch (like a git pull request over email): https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v4 Then I can do a git fetch && git checkout FETCH_HEAD. Thanks, Daniel > > Thanks, > Ram > > > > > Thanks, Daniel > > > > > > > > Ramalingam C (40): > > > drm: hdcp2.2 authentication msg definitions > > > drm: HDMI and DP specific HDCP2.2 defines > > > misc/mei/hdcp: Client driver for HDCP application > > > misc/mei/hdcp: Notifier chain for mei cldev state change > > > misc/mei/hdcp: Define ME FW interface for HDCP2.2 > > > linux/mei: Header for mei_hdcp driver interface > > > misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > > > misc/mei/hdcp: Verify Receiver Cert and prepare km > > > misc/mei/hdcp: Verify H_prime > > > misc/mei/hdcp: Store the HDCP Pairing info > > > misc/mei/hdcp: Initiate Locality check > > > misc/mei/hdcp: Verify L_prime > > > misc/mei/hdcp: Prepare Session Key > > > misc/mei/hdcp: Repeater topology verification and ack > > > misc/mei/hdcp: Verify M_prime > > > misc/mei/hdcp: Enabling the HDCP authentication > > > misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > > > drm/i915: wrapping all hdcp var into intel_hdcp > > > drm/i915: Define HDCP2.2 related variables > > > drm/i915: Define Intel HDCP2.2 registers > > > drm/i915: Wrappers for mei HDCP2.2 services > > > drm/i915: Implement HDCP2.2 receiver authentication > > > drm/i915: Implement HDCP2.2 repeater authentication > > > drm/i915: Enable and Disable HDCP2.2 port encryption > > > drm/i915: Implement HDCP2.2 En/Dis-able > > > drm/i915: Implement HDCP2.2 link integrity check > > > drm/i915: Handle HDCP2.2 downstream topology change > > > drm/i915: Pullout the bksv read and validation > > > drm/i915: Initialize HDCP2.2 and its MEI interface > > > drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable > > > drm/i915: Enable superior HDCP ver that is capable > > > drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure > > > drm/i915: hdcp_check_link only on CP_IRQ > > > drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ > > > drm/i915/gmbus: Increase the Bytes per Rd/Wr Op > > > drm/i915/gmbus: Enable burst read > > > drm/i915: Implem
Re: [Intel-gfx] [PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface
On Tue, May 29, 2018 at 08:53:37AM +0200, Daniel Vetter wrote:
> On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote:
> >
> >
> > On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
> > > On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
> > > > Initialize HDCP2.2 support. This includes the mei interface
> > > > initialization along with required notifier registration.
> > > >
> > > > v2:
> > > >mei interface handle is protected with mutex. [Chris Wilson]
> > > > v3:
> > > >Notifiers are used for the mei interface state.
> > > > v4:
> > > >Poll for mei client device state
> > > >Error msg for out of mem [Uma]
> > > >Inline req for init function removed [Uma]
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 3 +-
> > > > drivers/gpu/drm/i915/intel_drv.h | 5 +-
> > > > drivers/gpu/drm/i915/intel_hdcp.c | 117
> > > > +-
> > > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
> > > > 4 files changed, 122 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 62f82c4298ac..276eb49113e9 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -6368,7 +6368,8 @@ intel_dp_init_connector(struct intel_digital_port
> > > > *intel_dig_port,
> > > > intel_dp_add_properties(intel_dp, connector);
> > > > if (is_hdcp_supported(dev_priv, port) &&
> > > > !intel_dp_is_edp(intel_dp)) {
> > > > - int ret = intel_hdcp_init(intel_connector,
> > > > &intel_dp_hdcp_shim);
> > > > + int ret = intel_hdcp_init(intel_connector,
> > > > &intel_dp_hdcp_shim,
> > > > + false);
> > > > if (ret)
> > > > DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> > > > }
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index ac943ec73987..750fc19f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -442,7 +442,7 @@ struct intel_hdcp {
> > > > /* mei interface related information */
> > > > struct mei_cl_device *cldev;
> > > > struct mei_hdcp_data mei_data;
> > > > -
> > > > + struct notifier_block mei_cldev_nb;
> > > > struct delayed_work hdcp2_check_work;
> > > > };
> > > > @@ -1940,7 +1940,8 @@ void intel_hdcp_atomic_check(struct drm_connector
> > > > *connector,
> > > > struct drm_connector_state *old_state,
> > > > struct drm_connector_state *new_state);
> > > > int intel_hdcp_init(struct intel_connector *connector,
> > > > - const struct intel_hdcp_shim *hdcp_shim);
> > > > + const struct intel_hdcp_shim *hdcp_shim,
> > > > + bool hdcp2_supported);
> > > > int intel_hdcp_enable(struct intel_connector *connector);
> > > > int intel_hdcp_disable(struct intel_connector *connector);
> > > > int intel_hdcp_check_link(struct intel_connector *connector);
> > > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > > > b/drivers/gpu/drm/i915/intel_hdcp.c
> > > > index f3f935046c31..9948e4b4e203 100644
> > > > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > > > @@ -11,6 +11,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include "intel_drv.h"
> > > > #include "i915_reg.h"
> > > > @@ -25,6 +26,7 @@ static int _intel_hdcp2_enable(struct intel_connector
> > > > *connector);
> > > > static int _intel_hdcp2_disable(struct intel_connector *connector);
> > > > static void intel_hdcp2_check_work(struct work_struct *work);
> > > > static int intel_hdcp2_check_link(struct intel_connector *connector);
> > > > +static int intel_hdcp2_init(struct intel_connector *connector);
> > > > static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> > > > *intel_dig_port,
> > > > const struct intel_hdcp_shim *shim)
> > > > @@ -766,11 +768,15 @@ bool is_hdcp_supported(struct drm_i915_private
> > > > *dev_priv, enum port port)
> > > > }
> > > > int intel_hdcp_init(struct intel_connector *connector,
> > > > - const struct intel_hdcp_shim *hdcp_shim)
> > > > + const struct intel_hdcp_shim *hdcp_shim,
> > > > + bool hdcp2_supported)
> > > > {
> > > > struct intel_hdcp *hdcp = &connector->hdcp;
> > > > int ret;
> > > > + if (!hdcp_shim)
> > > > + return -EINVAL;
> > > > +
> > > > ret = drm_connector_attach_content_protection_property(
> > > > &connector->base);
> > > > if (ret)
> > > > @@ -779,7 +785,12 @@ in
Re: [Intel-gfx] [PATCH 01/11] drm/i915/icl: WaDisableImprovedTdlClkGating
Oscar Mateo writes:
> Revert to the legacy implementation.
>
> v2: GEN7_ROW_CHICKEN2 is masked
> v3:
> - Rebased
> - Renamed to Wa_2006611047
> - A0 and B0 only
> v4:
> - Add spaces around '<<' (and fix the surrounding code as well)
> - Mark the WA as pre-prod
> v5: Rebased on top of the WA refactoring
> v6: Added References (Mika)
> v7: Fixed in B0
>
> References: HSDES#2006611047
> Signed-off-by: Oscar Mateo
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +++--
> drivers/gpu/drm/i915/intel_workarounds.c | 7 +++
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6953419..4eb159f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8328,8 +8328,9 @@ enum {
>
> #define GEN7_ROW_CHICKEN2_MMIO(0xe4f4)
> #define GEN7_ROW_CHICKEN2_GT2_MMIO(0xf4f4)
> -#define DOP_CLOCK_GATING_DISABLE (1<<0)
> -#define PUSH_CONSTANT_DEREF_DISABLE(1<<8)
> +#define DOP_CLOCK_GATING_DISABLE (1 << 0)
> +#define PUSH_CONSTANT_DEREF_DISABLE(1 << 8)
> +#define GEN11_TDL_CLOCK_GATING_FIX_DISABLE (1 << 1)
>
> #define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
> #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index cea5710..04aa885 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -463,6 +463,13 @@ static int icl_ctx_workarounds_init(struct
> drm_i915_private *dev_priv)
>*/
> WA_SET_BIT_MASKED(ICL_HDC_MODE, HDC_FORCE_NON_COHERENT);
>
> + /* Wa_2006611047:icl (pre-prod)
> + * Formerly known as WaDisableImprovedTdlClkGating
> + */
> + if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_A0))
> + WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2,
> + GEN11_TDL_CLOCK_GATING_FIX_DISABLE);
> +
> return 0;
> }
>
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/11] drm/i915/icl: WaEnableStateCacheRedirectToCS
Oscar Mateo writes:
> Redirects the state cache to the CS Command buffer section for
> performance reasons.
>
> v2: Rebased
> v3: Rebased on top of the WA refactoring
> v3: Added References (Mika)
>
> References: HSDES#1604325460
> Cc: Mika Kuoppala
> Signed-off-by: Oscar Mateo
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_workarounds.c | 4
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4eb159f..924b9a6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7227,6 +7227,7 @@ enum {
> #define DISABLE_PIXEL_MASK_CAMMING (1<<14)
>
> #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
> +#define GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11)
>
> #define GEN7_L3SQCREG1 _MMIO(0xB010)
> #define VLV_B0_WA_L3SQCREG1_VALUE 0x00D3
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 04aa885..1d29803 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -470,6 +470,10 @@ static int icl_ctx_workarounds_init(struct
> drm_i915_private *dev_priv)
> WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2,
> GEN11_TDL_CLOCK_GATING_FIX_DISABLE);
>
> + /* WaEnableStateCacheRedirectToCS:icl */
> + WA_SET_BIT_MASKED(GEN9_SLICE_COMMON_ECO_CHICKEN1,
> + GEN11_STATE_CACHE_REDIRECT_TO_CS);
> +
> return 0;
> }
>
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "net/sch_generic: Shut up noise"
== Series Details == Series: Revert "net/sch_generic: Shut up noise" URL : https://patchwork.freedesktop.org/series/43878/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9136_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9136_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9136_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43878/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9136_full: === IGT changes === Warnings igt@kms_busy@basic-flip-a: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9136_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: NOTRUN -> FAIL (fdo#105347) igt@drv_selftest@live_hangcheck: shard-kbl: NOTRUN -> DMESG-FAIL (fdo#106560) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_cursor_crc@cursor-256x256-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#105454, fdo#106509) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) Possible fixes igt@drv_selftest@live_workarounds: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4250 -> Patchwork_9136 CI_DRM_4250: 01b6423d3fabdb32ac69bc155dd5beb87c6761d8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9136: 0699f83a89c65de3f632478f0faad2a70974738a @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9136/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (i386
defconfig) failed like this:
In file included from include/asm-generic/barrier.h:20:0,
from arch/x86/include/asm/barrier.h:86,
from include/linux/nospec.h:8,
from drivers/gpu/drm/i915/i915_query.c:7:
drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl':
include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119'
declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:319:4: note: in definition of macro
'__compiletime_assert'
prefix ## suffix();\
^~
include/linux/compiler.h:339:2: note: in expansion of macro
'_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~
include/linux/build_bug.h:45:37: note: in expansion of macro
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~
include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
^~~~
drivers/gpu/drm/i915/i915_query.c:118:15: note: in expansion of macro
'array_index_nospec'
func_idx = array_index_nospec(func_idx,
^~
Caused by commit
540ead8c5a0e ("drm/i915/query: Protect tainted function pointer lookup")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgp3IzaBGOyxd.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface
On Tuesday 29 May 2018 02:12 PM, Daniel Vetter wrote:
On Tue, May 29, 2018 at 08:53:37AM +0200, Daniel Vetter wrote:
On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote:
On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required notifier registration.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 5 +-
drivers/gpu/drm/i915/intel_hdcp.c | 117
+-
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
4 files changed, 122 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..276eb49113e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6368,7 +6368,8 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp_add_properties(intel_dp, connector);
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
- int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
+ int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim,
+ false);
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ac943ec73987..750fc19f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -442,7 +442,7 @@ struct intel_hdcp {
/* mei interface related information */
struct mei_cl_device *cldev;
struct mei_hdcp_data mei_data;
-
+ struct notifier_block mei_cldev_nb;
struct delayed_work hdcp2_check_work;
};
@@ -1940,7 +1940,8 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *hdcp_shim);
+ const struct intel_hdcp_shim *hdcp_shim,
+ bool hdcp2_supported);
int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
int intel_hdcp_check_link(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f3f935046c31..9948e4b4e203 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -25,6 +26,7 @@ static int _intel_hdcp2_enable(struct intel_connector
*connector);
static int _intel_hdcp2_disable(struct intel_connector *connector);
static void intel_hdcp2_check_work(struct work_struct *work);
static int intel_hdcp2_check_link(struct intel_connector *connector);
+static int intel_hdcp2_init(struct intel_connector *connector);
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
*intel_dig_port,
const struct intel_hdcp_shim *shim)
@@ -766,11 +768,15 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
}
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *hdcp_shim)
+ const struct intel_hdcp_shim *hdcp_shim,
+ bool hdcp2_supported)
{
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
+ if (!hdcp_shim)
+ return -EINVAL;
+
ret = drm_connector_attach_content_protection_property(
&connector->base);
if (ret)
@@ -779,7 +785,12 @@ int intel_hdcp_init(struct intel_connector *connector,
hdcp->hdcp_shim = hdcp_shim;
mutex_init(&hdcp->hdcp_mutex);
INIT_DELAYED_WORK(&hdcp->hdcp_check_work, intel_hdcp_check_work);
+ INIT_DELAYED_WORK(&hdcp->hdcp2_check_work, intel_hdcp2_check_work);
INIT_WORK(&hdcp->hdcp_prop_work, intel_hdcp_prop_work);
+
+ if (hdcp2_supported)
+ intel_hdcp2_init(connector);
+
return 0;
}
@@ -1637,3 +1648,107 @@ static void intel_hdcp2_check_work(struct work_struct
*work)
schedule_delayed_work(&hdcp->hdcp2_check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
}
+
+static int initialize_mei_hdcp_data(struct intel_connector *connector)
+{
+
Re: [Intel-gfx] [PATCH v4 00/41] drm/i915: Implement HDCP2.2
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Tuesday, May 29, 2018 2:01 PM > To: C, Ramalingam > Cc: Daniel Vetter ; intel-gfx@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; seanp...@chromium.org; chris@chris- > wilson.co.uk; jani.nik...@linux.intel.com; Winkler, Tomas > ; Usyskin, Alexander > ; Shankar, Uma ; > Sharma, Shashank > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2 > > On Tue, May 29, 2018 at 07:51:56AM +, C, Ramalingam wrote: > > > -Original Message- > > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of > > > Daniel Vetter > > > Sent: Tuesday, May 29, 2018 12:27 PM > > > To: C, Ramalingam > > > Cc: intel-gfx@lists.freedesktop.org; > > > dri-de...@lists.freedesktop.org; seanp...@chromium.org; > > > dan...@ffwll.ch; ch...@chris-wilson.co.uk; > > > jani.nik...@linux.intel.com; Winkler, Tomas > > > ; Usyskin, Alexander > > > ; Shankar, Uma ; > > > Sharma, Shashank > > > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2 > > > > > > On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote: > > > > The sequence for HDCP2.2 authentication and encryption is > > > > implemented in I915. Encoder specific implementations are moved into > hdcp_shim. > > > > > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series > > > > introduces a client driver for mei bus, so that for HDCP2.2 > > > > authentication, > > > > HDCP2.2 stack in I915 can avail the services from ME FW. > > > > > > > > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and > > > > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI > > > > Bus then we need an option to disable the HDCP2.2 in I915 (like > > > > DRM_I915_HDCP2.2!?). Till then they are binded. > > > > > > > > Userspace interface remains unchanged as version agnostic. When > > > > userspace request for HDCP enable, Kernel will detect the HDCP > > > > source and sink's HDCP version(1.4/2.2)capability and enable the > > > > best capable version for that combination. > > > > > > > > This series enables the HDCP2.2 for Type0 content streams. > > > > > > > > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of > > > > v3. > > > > Thanks Daniel vetter for guiding me to test and confirm that there > > > > is no locking issue with respect to notifier usage between I915 and > MEI_HDCP. > > > > > > > > Major Changes in v4: > > > > - GMBus Changes to implement the burst read as generic > > > > [Jani, Ville and Daniel] > > > > - Polling is added for extra Notifier notification when I915 and > > > > MEI_HDCP are modules. > > > > - Comment and style issues and typos are fixed [Uma and Alexander] > > > > - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915. > > > > - Fixed the #if in include/linux/mei_hdcp.h for build issues. > > > > > > > > GMBus changes are added here for completeness of the series. They > > > > are in review at https://patchwork.freedesktop.org/series/41632/ also. > > > > > > Please reply with a link to your github here (and include it in your > > > next cover letter too). I can't ever find it when I need it :-/ > > > > You can find a github repo for HDCP2.2 v4 series at > > https://github.com/ramalingampc2008/drm-tip > > Even nicer if you directly supply what I need to feed to git fetch (like a > git pull > request over email): > > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v4 > > Then I can do a git fetch && git checkout FETCH_HEAD. Ok. Sure. Thanks, Ram. > > Thanks, Daniel > > > > > Thanks, > > Ram > > > > > > > > Thanks, Daniel > > > > > > > > > > > Ramalingam C (40): > > > > drm: hdcp2.2 authentication msg definitions > > > > drm: HDMI and DP specific HDCP2.2 defines > > > > misc/mei/hdcp: Client driver for HDCP application > > > > misc/mei/hdcp: Notifier chain for mei cldev state change > > > > misc/mei/hdcp: Define ME FW interface for HDCP2.2 > > > > linux/mei: Header for mei_hdcp driver interface > > > > misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > > > > misc/mei/hdcp: Verify Receiver Cert and prepare km > > > > misc/mei/hdcp: Verify H_prime > > > > misc/mei/hdcp: Store the HDCP Pairing info > > > > misc/mei/hdcp: Initiate Locality check > > > > misc/mei/hdcp: Verify L_prime > > > > misc/mei/hdcp: Prepare Session Key > > > > misc/mei/hdcp: Repeater topology verification and ack > > > > misc/mei/hdcp: Verify M_prime > > > > misc/mei/hdcp: Enabling the HDCP authentication > > > > misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > > > > drm/i915: wrapping all hdcp var into intel_hdcp > > > > drm/i915: Define HDCP2.2 related variables > > > > drm/i915: Define Intel HDCP2.2 registers > > > > drm/i915: Wrappers for mei HDCP2.2 services > > > > drm/i915: Implement HDCP2.2 receiver authentication > > > > drm/i915: Implement HDCP2.2 repeater authentication > > > > drm/i915
[Intel-gfx] [PATCH] RFT mm/oomkill: Don't skip the reaper
If we find a task that has already been selected for reaping, consider
that it may still free some memory. Currently, we skip such tasks
believing that we've already extracted as memory free pages as possible
from before hitting a livelock. In practice, at least on single user
systems deliberating exercising oom, such processes have only begun to
recover their pages and are still the worst hogs on the system. If we
skip them, we just select yet more victims, and with sufficient
enthusiasm may end up with all available processes marked for reaping,
panicking in the process.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
---
mm/oom_kill.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 8ba6cb88cf58..2ca231202af9 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -49,6 +49,8 @@
#define CREATE_TRACE_POINTS
#include
+static bool task_will_free_mem(struct task_struct *task);
+
int sysctl_panic_on_oom;
int sysctl_oom_kill_allocating_task;
int sysctl_oom_dump_tasks = 1;
@@ -201,19 +203,27 @@ unsigned long oom_badness(struct task_struct *p, struct
mem_cgroup *memcg,
if (oom_unkillable_task(p, memcg, nodemask))
return 0;
+ /*
+* If we cannot lock the task's mm, it is in the process of being
+* removed, so select it as the target of the repear and see if it
+* recovers enough memory to continue.
+*/
p = find_lock_task_mm(p);
if (!p)
- return 0;
+ return ULONG_MAX;
+
+ if (task_will_free_mem(p)) {
+ task_unlock(p);
+ return ULONG_MAX;
+ }
/*
* Do not even consider tasks which are explicitly marked oom
-* unkillable or have been already oom reaped or the are in
-* the middle of vfork
+* unkillable or are in the middle of vfork (and so still share their
+* parent's mm).
*/
adj = (long)p->signal->oom_score_adj;
- if (adj == OOM_SCORE_ADJ_MIN ||
- test_bit(MMF_OOM_SKIP, &p->mm->flags) ||
- in_vfork(p)) {
+ if (adj == OOM_SCORE_ADJ_MIN || in_vfork(p)) {
task_unlock(p);
return 0;
}
@@ -806,11 +816,12 @@ static bool task_will_free_mem(struct task_struct *task)
return false;
/*
-* This task has already been drained by the oom reaper so there are
-* only small chances it will free some more
+* This task has already been selected for the oom reaper, but
+* the reaper is unable to make progress. Continue to dogpile
+* on top until it succeeds.
*/
if (test_bit(MMF_OOM_SKIP, &mm->flags))
- return false;
+ return true;
if (atomic_read(&mm->mm_users) <= 1)
return true;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v6] intel-gpu-top: Rewrite the tool to be safe to use
On 4 April 2018 at 16:26, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio
> register access. This patch rewrites it to use only PMU.
>
> Only overall command streamer busyness and GPU global data such as power
> and frequencies are included in this new version.
>
> For access to more GPU functional unit level data, an OA metric based tool
> like gpu-top should be used instead.
>
> v2:
> * Sort engines by class and instance.
> * Do not wait for one sampling period to display something on screen.
> * Move code out of the asserts. (Rinat Ibragimov)
> * Continuously adapt to terminal size. (Rinat Ibragimov)
>
> v3:
> * Change layout and precision of some field. (Chris Wilson)
> Eero Tamminen:
> * Use more user friendly engine names.
> * Don't error out if a counter is missing.
> * Add IMC read/write bandwidth.
> * Report minimum required kernel version.
>
> v4:
> * Really support 4.16 by skipping of missing engines.
> * Simpler and less hacky float printing.
> * Preserve copyright header. (Antonio Argenziano)
> * Simplify engines_ptr macro. (Rinat Ibragimov)
>
> v5:
> * Get RAPL unit from sysfs.
> * Consolidate sysfs paths with a macro.
> * Tidy error handling by carrying over and reporting errno.
> * Check against console height on all prints.
> * More readable minimum kernel version message. (Eero Tamminen)
> * Column banner for per engine stats. (Eero Tamminen)
>
> v6:
> * Man page update. (Eero Tamminen)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Lionel Landwerlin
> Cc: Petri Latvala
> Cc: Eero Tamminen
> Cc: Rinat Ibragimov
> Reviewed-by: Lionel Landwerlin # v1
> Reviewed-by: Chris Wilson # v0.5
> ---
> lib/igt_perf.c|6 +
> lib/igt_perf.h|1 +
> man/intel_gpu_top.rst | 41 +-
> tools/Makefile.am |2 +
> tools/intel_gpu_top.c | 1250
> +++--
> tools/meson.build |6 +-
> 6 files changed, 719 insertions(+), 587 deletions(-)
>
> diff --git a/lib/igt_perf.c b/lib/igt_perf.c
> index 99d82ea51c9b..e3dec2cc29c7 100644
> --- a/lib/igt_perf.c
> +++ b/lib/igt_perf.c
> @@ -69,3 +69,9 @@ int igt_perf_open(uint64_t type, uint64_t config)
> return _perf_open(type, config, -1,
> PERF_FORMAT_TOTAL_TIME_ENABLED);
> }
> +
> +int igt_perf_open_group(uint64_t type, uint64_t config, int group)
> +{
> + return _perf_open(type, config, group,
> + PERF_FORMAT_TOTAL_TIME_ENABLED | PERF_FORMAT_GROUP);
> +}
> diff --git a/lib/igt_perf.h b/lib/igt_perf.h
> index 614ea5d23fa6..e00718f4769a 100644
> --- a/lib/igt_perf.h
> +++ b/lib/igt_perf.h
> @@ -55,5 +55,6 @@ uint64_t i915_type_id(void);
> int perf_i915_open(uint64_t config);
> int perf_i915_open_group(uint64_t config, int group);
> int igt_perf_open(uint64_t type, uint64_t config);
> +int igt_perf_open_group(uint64_t type, uint64_t config, int group);
>
> #endif /* I915_PERF_H */
> diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
> index a5f7175bb1a0..19c712307d28 100644
> --- a/man/intel_gpu_top.rst
> +++ b/man/intel_gpu_top.rst
> @@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
> -
> .. include:: defs.rst
> :Author: IGT Developers
> -:Date: 2016-03-01
> +:Date: 2018-04-04
> :Version: |PACKAGE_STRING|
> -:Copyright: 2009,2011,2012,2016 Intel Corporation
> +:Copyright: 2009,2011,2012,2016,2018 Intel Corporation
> :Manual section: |MANUAL_SECTION|
> :Manual group: |MANUAL_GROUP|
>
> @@ -21,42 +21,25 @@ SYNOPSIS
> DESCRIPTION
> ===
>
> -**intel_gpu_top** is a tool to display usage information of an Intel GPU. It
> -requires root privilege to map the graphics device.
> +**intel_gpu_top** is a tool to display usage information on Intel GPU's.
> +
> +The tool gathers data using perf performance counters (PMU) exposed by i915
> and other platform drivers like RAPL (power) and Uncore IMC (memory
> bandwidth).
>
> OPTIONS
> ===
>
> --s SAMPLES
> -Number of samples to acquire per second.
> -
> --o FILE
> -Collect usage statistics to FILE. If file is "-", run non-interactively
> -and output statistics to stdout.
> -
> --e COMMAND
> -Execute COMMAND to profile, and leave when it is finished. Note that the
> -entire command with all parameters should be included as one parameter.
> +-s
> +Refresh period in milliseconds.
>
> -h
> -Show usage notes.
> +Show help text.
>
> -EXAMPLES
> -
> -
> -intel_gpu_top -o "cairo-trace-gvim.log" -s 100 -e "cairo-perf-trace
> /tmp/gvim"
> -Run cairo-perf-trace with /tmp/gvim trace, non-interactively, saving the
> -statistics into cairo-trace-gvim.log file, and collecting 100 samples per
> -second.
> -
> -Note that idle units are not displayed, so an entirely idle GPU will only
> -display the ring status and header.
> +LIMITATIONS
> +
[Intel-gfx] ✓ Fi.CI.BAT: success for RFT mm/oomkill: Don't skip the reaper
== Series Details == Series: RFT mm/oomkill: Don't skip the reaper URL : https://patchwork.freedesktop.org/series/43884/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250 -> Patchwork_9137 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9137 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9137, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43884/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9137: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9137 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: DMESG-FAIL (fdo#102614, fdo#106103) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (43 -> 38) == Missing(5): fi-byt-squawks fi-ilk-m540 fi-glk-j4005 fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4250 -> Patchwork_9137 CI_DRM_4250: 01b6423d3fabdb32ac69bc155dd5beb87c6761d8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9137: c5e1671767b93980bb8d78135b80392d8752 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c5e167176888 RFT mm/oomkill: Don't skip the reaper == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9137/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915/icl: Wa_2006665173
Oscar Mateo writes:
> Disable blend embellishment in RCC.
>
> Also, some other registers style fixed in passing.
>
> v2: Rebased on top of the WA refactoring
> v3: Added References (Mika)
> v4:
> - Fixed in B0
> - Mentioned style fixes in commit message
>
> References: HSDES#2006665173
> Cc: Mika Kuoppala
> Signed-off-by: Oscar Mateo
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 18 +++---
> drivers/gpu/drm/i915/intel_workarounds.c | 5 +
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 924b9a6..6e88c6b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7211,13 +7211,17 @@ enum {
>
> /* GEN7 chicken */
> #define GEN7_COMMON_SLICE_CHICKEN1 _MMIO(0x7010)
> -# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26))
> -# define GEN9_RHWO_OPTIMIZATION_DISABLE (1<<14)
> -#define COMMON_SLICE_CHICKEN2_MMIO(0x7014)
> -# define GEN9_PBE_COMPRESSED_HASH_SELECTION (1<<13)
> -# define GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE (1<<12)
> -# define GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION (1<<8)
> -# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE(1<<0)
> + #define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1 << 10) | (1 << 26))
> + #define GEN9_RHWO_OPTIMIZATION_DISABLE (1 << 14)
> +
> +#define COMMON_SLICE_CHICKEN2
> _MMIO(0x7014)
> + #define GEN9_PBE_COMPRESSED_HASH_SELECTION (1 << 13)
> + #define GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE (1 << 12)
> + #define GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION (1 << 8)
> + #define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1 << 0)
> +
> +#define GEN11_COMMON_SLICE_CHICKEN3 _MMIO(0x7304)
> + #define GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC (1 << 11)
>
> #define HIZ_CHICKEN _MMIO(0x7018)
> # define CHV_HZ_8X8_MODE_IN_1X (1<<15)
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 1d29803..33a1a0c 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -474,6 +474,11 @@ static int icl_ctx_workarounds_init(struct
> drm_i915_private *dev_priv)
> WA_SET_BIT_MASKED(GEN9_SLICE_COMMON_ECO_CHICKEN1,
> GEN11_STATE_CACHE_REDIRECT_TO_CS);
>
> + /* Wa_2006665173:icl (pre-prod) */
> + if (IS_ICL_REVID(dev_priv, ICL_REVID_A0, ICL_REVID_A0))
> + WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
> + GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
> +
> return 0;
> }
>
> --
> 1.9.1
___
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/guc: Don't read SOFT_SCRATCH(15) on MMIO error
== Series Details == Series: drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error URL : https://patchwork.freedesktop.org/series/43865/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250 -> Patchwork_9138 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43865/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9138 that come from known issues: === IGT changes === Issues hit igt@gem_exec_create@basic: fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719) igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL (fdo#100368) igt@kms_flip@basic-plain-flip: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: DMESG-FAIL (fdo#106103, fdo#102614) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (43 -> 39) == Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4250 -> Patchwork_9138 CI_DRM_4250: 01b6423d3fabdb32ac69bc155dd5beb87c6761d8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9138: 4e3d675aa3897bc6b42fb6a3e60639a2bc720bd7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4e3d675aa389 drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9138/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/gem_ctx_isolation: Test INSTPM back to gen6
Lionel pointed out that INSTPM was context saved, at least from gen6,
not from gen9. The only caveat is that INSTPM is a masked register (the
upper 16bits are a write-enable mask, the lower 16bits the value to
change) and also contains a read-only counter bit (which counts flushes,
and so flip flops between batches). Being a non-privileged register that
userspace wants to manipulate, it is writable and readable from a
userspace batch, so we can test whether or not a write from one context
is visible from a second.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
---
tests/gem_ctx_isolation.c | 51 ---
1 file changed, 42 insertions(+), 9 deletions(-)
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
index 4968e3678..fe7d3490c 100644
--- a/tests/gem_ctx_isolation.c
+++ b/tests/gem_ctx_isolation.c
@@ -63,10 +63,12 @@ static const struct named_register {
unsigned int engine_mask;
uint32_t offset;
uint32_t count;
+ uint32_t ignore_bits;
+ bool masked;
} nonpriv_registers[] = {
{ "NOPID", NOCTX, RCS0, 0x2094 },
{ "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
- { "INSTPM", GEN9, RCS0, 0x20c0 },
+ { "INSTPM", GEN6, RCS0, 0x20c0, 1, BIT(8) /* ro counter */, true },
{ "IA_VERTICES_COUNT", GEN4, RCS0, 0x2310, 2 },
{ "IA_PRIMITIVES_COUNT", GEN4, RCS0, 0x2318, 2 },
{ "VS_INVOCATION_COUNT", GEN4, RCS0, 0x2320, 2 },
@@ -167,6 +169,17 @@ static const char *register_name(uint32_t offset, char
*buf, size_t len)
return "unknown";
}
+static const struct named_register *lookup_register(uint32_t offset)
+{
+ for (const struct named_register *r = nonpriv_registers; r->name; r++) {
+ unsigned int width = r->count ? 4*r->count : 4;
+ if (offset >= r->offset && offset < r->offset + width)
+ return r;
+ }
+
+ return NULL;
+}
+
static bool ignore_register(uint32_t offset)
{
for (const struct named_register *r = ignore_registers; r->name; r++) {
@@ -283,7 +296,10 @@ static void write_regs(int fd,
count--; offset += 4) {
*b++ = 0x22 << 23 | 1; /* LRI */
*b++ = offset;
- *b++ = value;
+ if (r->masked)
+ *b++ = value | 0xu << 16;
+ else
+ *b++ = value;
}
}
*b++ = MI_BATCH_BUFFER_END;
@@ -424,14 +440,31 @@ static void compare_regs(int fd, uint32_t A, uint32_t B,
const char *who)
num_errors = 0;
for (unsigned int n = 0; n < NUM_REGS; n++) {
+ const struct named_register *r;
uint32_t offset = n * sizeof(uint32_t);
- if (a[n] != b[n] && !ignore_register(offset)) {
- igt_warn("Register 0x%04x (%s): A=%08x B=%08x\n",
-offset,
-register_name(offset, buf, sizeof(buf)),
-a[n], b[n]);
- num_errors++;
- }
+ uint32_t mask;
+
+ if (a[n] == b[n])
+ continue;
+
+ if (ignore_register(offset))
+ continue;
+
+ mask = ~0u;
+ r = lookup_register(offset);
+ if (r && r->masked)
+ mask >>= 16;
+ if (r && r->ignore_bits)
+ mask &= ~r->ignore_bits;
+
+ if ((a[n] & mask) == (b[n] & mask))
+ continue;
+
+ igt_warn("Register 0x%04x (%s): A=%08x B=%08x\n",
+offset,
+register_name(offset, buf, sizeof(buf)),
+a[n] & mask, b[n] & mask);
+ num_errors++;
}
munmap(b, regs_size);
munmap(a, regs_size);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for RFT mm/oomkill: Don't skip the reaper
== Series Details == Series: RFT mm/oomkill: Don't skip the reaper URL : https://patchwork.freedesktop.org/series/43884/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9137_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9137_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9137_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43884/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9137_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: SKIP -> PASS +2 igt@kms_busy@basic-flip-a: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9137_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_crc@cursor-256x256-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: shard-hsw: PASS -> FAIL (fdo#104873) igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@kms_vblank@pipe-c-query-busy: shard-kbl: PASS -> DMESG-WARN (fdo#106247) Possible fixes igt@drv_selftest@live_hangcheck: shard-apl: DMESG-FAIL (fdo#106560) -> PASS igt@drv_selftest@live_workarounds: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-flip-vs-absolute-wf_vblank: shard-glk: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106247 https://bugs.freedesktop.org/show_bug.cgi?id=106247 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4250 -> Patchwork_9137 CI_DRM_4250: 01b6423d3fabdb32ac69bc155dd5beb87c6761d8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9137: c5e1671767b93980bb8d78135b80392d8752 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9137/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree
Quoting Stephen Rothwell (2018-05-29 12:26:05)
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (i386
> defconfig) failed like this:
Thanks for reporting. I've added a patch to fix the issue now.
I'll talk with our CI team about testing 32-bit building to try to
avoid these in the future.
Regards, Joonas
>
> In file included from include/asm-generic/barrier.h:20:0,
> from arch/x86/include/asm/barrier.h:86,
> from include/linux/nospec.h:8,
> from drivers/gpu/drm/i915/i915_query.c:7:
> drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl':
> include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119'
> declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^
> include/linux/compiler.h:319:4: note: in definition of macro
> '__compiletime_assert'
> prefix ## suffix();\
> ^~
> include/linux/compiler.h:339:2: note: in expansion of macro
> '_compiletime_assert'
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^~~
> include/linux/build_bug.h:45:37: note: in expansion of macro
> 'compiletime_assert'
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~
> include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> ^~~~
> include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON'
> BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
> ^~~~
> drivers/gpu/drm/i915/i915_query.c:118:15: note: in expansion of macro
> 'array_index_nospec'
> func_idx = array_index_nospec(func_idx,
>^~
>
> Caused by commit
>
> 540ead8c5a0e ("drm/i915/query: Protect tainted function pointer lookup")
>
> I have reverted that commit for today.
>
> --
> Cheers,
> Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
== Series Details == Series: drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error URL : https://patchwork.freedesktop.org/series/43865/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4250_full -> Patchwork_9138_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9138_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9138_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43865/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9138_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: SKIP -> PASS +2 igt@gem_mocs_settings@mocs-rc6-bsd2: shard-kbl: PASS -> SKIP igt@kms_busy@basic-flip-a: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9138_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-glk: PASS -> DMESG-FAIL (fdo#106560) igt@kms_cursor_crc@cursor-256x256-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@2x-dpms-vs-vblank-race: shard-glk: PASS -> FAIL (fdo#103060) igt@kms_flip@2x-flip-vs-absolute-wf_vblank: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) +1 igt@kms_flip@2x-wf_vblank-ts-check: shard-hsw: PASS -> FAIL (fdo#103928) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363, fdo#102887) igt@kms_flip@wf_vblank-ts-check: shard-glk: PASS -> FAIL (fdo#100368) +1 igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) Possible fixes igt@drv_selftest@live_hangcheck: shard-apl: DMESG-FAIL (fdo#106560) -> PASS igt@drv_selftest@live_workarounds: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4250 -> Patchwork_9138 CI_DRM_4250: 01b6423d3fabdb32ac69bc155dd5beb87c6761d8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9138: 4e3d675aa3897bc6b42fb6a3e60639a2bc720bd7 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9138/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm/i915/icl: WaEnableFloatBlendOptimization
Oscar Mateo writes:
> Enables blend optimization for floating point RTs
>
> v2: Rebased on top of the WA refactoring
> v3: Added References (Mika)
>
> References: HSDES#1406393558
> Cc: Mika Kuoppala
> Signed-off-by: Oscar Mateo
Let's see if we can get away without whitelisting this,
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6e88c6b..f123c3e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2663,6 +2663,9 @@ enum i915_power_well_id {
> #define GEN8_4x4_STC_OPTIMIZATION_DISABLE (1<<6)
> #define GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE (1<<1)
>
> +#define GEN10_CACHE_MODE_SS _MMIO(0xe420)
> +#define FLOAT_BLEND_OPTIMIZATION_ENABLE(1 << 4)
> +
> #define GEN6_BLITTER_ECOSKPD _MMIO(0x221d0)
> #define GEN6_BLITTER_LOCK_SHIFT16
> #define GEN6_BLITTER_FBC_NOTIFY(1<<3)
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 33a1a0c..e9c00b0 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -479,6 +479,9 @@ static int icl_ctx_workarounds_init(struct
> drm_i915_private *dev_priv)
> WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
> GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
>
> + /* WaEnableFloatBlendOptimization:icl */
> + WA_SET_BIT_MASKED(GEN10_CACHE_MODE_SS, FLOAT_BLEND_OPTIMIZATION_ENABLE);
> +
> return 0;
> }
>
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/i915/icl: Wa_1406463099
Oscar Mateo writes:
> Prevents an error in the GAM unit. Also known as WaGamTlbPendError
>
> References: HSDES#1406463099
> References: HSDES#1406465643
> Signed-off-by: Oscar Mateo
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5 +++--
> drivers/gpu/drm/i915/intel_workarounds.c | 7 +++
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 42835d79..8a18447 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2306,8 +2306,9 @@ enum i915_power_well_id {
> #define GAMW_ECO_ENABLE_64K_IPS_FIELD 0xF
>
> #define GAMT_CHKN_BIT_REG_MMIO(0x4ab8)
> -#define GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1<<28)
> -#define GAMT_CHKN_DISABLE_I2M_CYCLE_ON_WR_PORT (1<<24)
> +#define GAMT_CHKN_DISABLE_L3_COH_PIPE (1 << 31)
> +#define GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1 << 28)
> +#define GAMT_CHKN_DISABLE_I2M_CYCLE_ON_WR_PORT (1 << 24)
>
> #if 0
> #define PRB0_TAIL_MMIO(0x2030)
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 474e498..77929df 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -859,6 +859,13 @@ static void icl_gt_workarounds_apply(struct
> drm_i915_private *dev_priv)
> PMFLUSHDONE_LNICRSDROP |
> PMFLUSH_GAPL3UNBLOCK |
> PMFLUSHDONE_LNEBLK);
> +
> + /* Wa_1406463099:icl
> + * Formerly known as WaGamTlbPendError
> + */
> + I915_WRITE(GAMT_CHKN_BIT_REG,
> +I915_READ(GAMT_CHKN_BIT_REG) |
> +GAMT_CHKN_DISABLE_L3_COH_PIPE);
> }
>
> void intel_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm/i915/icl: WaEnableFloatBlendOptimization
FYI, we're setting this in Mesa :
https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/genX_state.c#n130
https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_state_upload.c#n67
I don't think we realized this was a privileged register.
Anuj: Maybe we can drop it?
-
Lionel
On 29/05/18 13:07, Mika Kuoppala wrote:
Oscar Mateo writes:
Enables blend optimization for floating point RTs
v2: Rebased on top of the WA refactoring
v3: Added References (Mika)
References: HSDES#1406393558
Cc: Mika Kuoppala
Signed-off-by: Oscar Mateo
Let's see if we can get away without whitelisting this,
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6e88c6b..f123c3e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2663,6 +2663,9 @@ enum i915_power_well_id {
#define GEN8_4x4_STC_OPTIMIZATION_DISABLE (1<<6)
#define GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE (1<<1)
+#define GEN10_CACHE_MODE_SS _MMIO(0xe420)
+#define FLOAT_BLEND_OPTIMIZATION_ENABLE (1 << 4)
+
#define GEN6_BLITTER_ECOSKPD _MMIO(0x221d0)
#define GEN6_BLITTER_LOCK_SHIFT 16
#define GEN6_BLITTER_FBC_NOTIFY (1<<3)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 33a1a0c..e9c00b0 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -479,6 +479,9 @@ static int icl_ctx_workarounds_init(struct drm_i915_private
*dev_priv)
WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
+ /* WaEnableFloatBlendOptimization:icl */
+ WA_SET_BIT_MASKED(GEN10_CACHE_MODE_SS, FLOAT_BLEND_OPTIMIZATION_ENABLE);
+
return 0;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 00/11] Workarounds for Icelake
Oscar Mateo writes: > The remaining WA patches that haven't been merged to date, plus > two new ones (WaEnablePreemptionGranularityControlByUMD & > Wa_1406463099). > > Oscar Mateo (11): > drm/i915/icl: WaDisableImprovedTdlClkGating > drm/i915/icl: WaEnableStateCacheRedirectToCS > drm/i915/icl: Wa_2006665173 > drm/i915/icl: WaEnableFloatBlendOptimization Reviewed and pushed all the above and the last one in this series. Thanks for patches! For the whitelisting stuff, I think we need to involve mesa/virtualization folks to see if there is really a need. -Mika > drm/i915/icl: WaSendPushConstantsFromMMIO > drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken2 > drm/i915/icl: WaAllowUMDToModifyHalfSliceChicken7 > drm/i915/icl: WaAllowUmdWriteTRTTRootTable > drm/i915/icl: WaAllowUMDToModifySamplerMode > drm/i915/icl: WaEnablePreemptionGranularityControlByUMD > drm/i915/icl: Wa_1406463099 > > drivers/gpu/drm/i915/i915_reg.h | 37 +++ > drivers/gpu/drm/i915/intel_workarounds.c | 44 > > 2 files changed, 70 insertions(+), 11 deletions(-) > > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Enable P010, P012 and P016 formats for GLK/CNL
These patches enable P010, P012 and P016 formats for GLK and CNL. These formats are similar to NV12 extending from 8 bits per channel to 10, 12 and 16 bits per channel. For user space components there is in IGT kms_available_modes_crc test which can test these new modes, test need to be recompiled with DRM_FORMAT_Pxxx definitions in place. For VLC media player I've made KMS video out plugin which will be able to show these new modes. This vout plugin is still work in progress, first version of my plugin can be seen here: https://mailman.videolan.org/pipermail/vlc-devel/2018-May/119013.html Vidya and Maarten here as CC as you guys were doing lot of NV12 stuff earlier and my patches extend NV12. /Juha-Pekka Juha-Pekka Heikkila (4): drm: Add P010, P012, P016 format definitions and fourcc drm/i915: Add P010, P012, P016 plane control definitions drm/i915: preparations for enabling P010, P012, P016 formats drm/i915: enable P010, P012, P016 formats for primary and sprite planes drivers/gpu/drm/drm_fourcc.c | 3 ++ drivers/gpu/drm/i915/i915_reg.h | 3 ++ drivers/gpu/drm/i915/intel_atomic.c | 3 +- drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 72 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 19 drivers/gpu/drm/i915/intel_sprite.c | 60 +- include/uapi/drm/drm_fourcc.h | 4 ++ 9 files changed, 144 insertions(+), 23 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb doesn't advance
and that the irq hasn't happened on another CPU signaling the request we
believe to be idle.
Fixes: f636edb214a5 ("drm/i915: Make i915_engine_info pretty printer to
standalone")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05f44ca35a06..530d6d0109b4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2972,23 +2972,22 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
struct i915_request *request, *active = NULL;
unsigned long flags;
- /* We are called by the error capture and reset at a random
-* point in time. In particular, note that neither is crucially
-* ordered with an interrupt. After a hang, the GPU is dead and we
-* assume that no more writes can happen (we waited long enough for
-* all writes that were in transaction to be flushed) - adding an
+ /*
+* We are called by the error capture, reset and to dump engine
+* state at random points in time. In particular, note that neither is
+* crucially ordered with an interrupt. After a hang, the GPU is dead
+* and we assume that no more writes can happen (we waited long enough
+* for all writes that were in transaction to be flushed) - adding an
* extra delay for a recent interrupt is pointless. Hence, we do
* not need an engine->irq_seqno_barrier() before the seqno reads.
+* At all other times, we must assume the GPU is still running, but
+* we only care about the snapshot of this moment.
*/
spin_lock_irqsave(&engine->timeline.lock, flags);
list_for_each_entry(request, &engine->timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))
continue;
- GEM_BUG_ON(request->engine != engine);
- GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- &request->fence.flags));
-
active = request;
break;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: "Race-to-idle" after switching to the kernel context
During suspend we want to flush out all active contexts and their
rendering. To do so we queue a request from the kernel's context, once
we know that request is done, we know the GPU is completely idle. To
speed up that switch bump the GPU clocks.
Switching to the kernel context prior to idling is also used to enforce
a barrier before changing OA properties, and when evicting active
rendering from the global GTT. All cases where we do want to
race-to-idle.
v2: Limit the boosting to only the switch before suspend.
v3: Limit it to the wait-for-idle on suspend.
Signed-off-by: Chris Wilson
Cc: David Weinehall
Cc: Mika Kuoppala
Tested-by: David Weinehall #v1
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 27 +--
drivers/gpu/drm/i915/i915_request.h | 1 +
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9eb93ca06309..773a5910cc29 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3703,7 +3703,29 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
static int wait_for_timeline(struct i915_timeline *tl, unsigned int flags)
{
- return i915_gem_active_wait(&tl->last_request, flags);
+ struct i915_request *rq;
+ long ret;
+
+ rq = i915_gem_active_get_unlocked(&tl->last_request);
+ if (!rq)
+ return 0;
+
+ /*
+* "Race-to-idle".
+*
+* Switching to the kernel context is often used a synchronous
+* step prior to idling, e.g. in suspend for flushing all
+* current operations to memory before sleeping. These we
+* want to complete as quickly as possible to avoid prolonged
+* stalls, so allow the gpu to boost to maximum clocks.
+*/
+ if (flags & I915_WAIT_FOR_IDLE_BOOST)
+ gen6_rps_boost(rq, NULL);
+
+ ret = i915_request_wait(rq, flags, MAX_SCHEDULE_TIMEOUT);
+ i915_request_put(rq);
+
+ return ret < 0 ? ret : 0;
}
static int wait_for_engines(struct drm_i915_private *i915)
@@ -4978,7 +5000,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
ret = i915_gem_wait_for_idle(dev_priv,
I915_WAIT_INTERRUPTIBLE |
-I915_WAIT_LOCKED);
+I915_WAIT_LOCKED |
+I915_WAIT_FOR_IDLE_BOOST);
if (ret && ret != -EIO)
goto err_unlock;
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 17a9fa03..491ff81d0fea 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -267,6 +267,7 @@ long i915_request_wait(struct i915_request *rq,
#define I915_WAIT_INTERRUPTIBLEBIT(0)
#define I915_WAIT_LOCKED BIT(1) /* struct_mutex held, handle GPU reset */
#define I915_WAIT_ALL BIT(2) /* used by i915_gem_object_wait() */
+#define I915_WAIT_FOR_IDLE_BOOST BIT(3)
static inline u32 intel_engine_get_seqno(struct intel_engine_cs *engine);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: After reset on sanitization, reset the engine backends
As we reset the GPU on suspend/resume, we also do need to reset the
engine state tracking so call into the engine backends. This is
especially important so that we can also sanitize the state tracking
across resume.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106702
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 773a5910cc29..75bdfafc97a2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4954,7 +4954,22 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
void i915_gem_sanitize(struct drm_i915_private *i915)
{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ GEM_TRACE("\n");
+
mutex_lock(&i915->drm.struct_mutex);
+
+ intel_runtime_pm_get(i915);
+ intel_uncore_forcewake_get(i915, FORCEWAKE_ALL);
+
+ /*
+* As we have just resumed the machine and woken the device up from
+* deep PCI sleep (presumably D3_cold), assume the HW has been reset
+* back to defaults, recovering from whatever wedged state we left it
+* in and so worth trying to use the device once more.
+*/
if (i915_terminally_wedged(&i915->gpu_error))
i915_gem_unset_wedged(i915);
@@ -4969,6 +4984,15 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+ /* Reset the submission backend after resume as well as the GPU reset */
+ for_each_engine(engine, i915, id) {
+ if (engine->reset.reset)
+ engine->reset.reset(engine, NULL);
+ }
+
+ intel_uncore_forcewake_put(i915, FORCEWAKE_ALL);
+ intel_runtime_pm_put(i915);
+
i915_gem_contexts_lost(i915);
mutex_unlock(&i915->drm.struct_mutex);
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Switch to kernel context before idling at runtime
We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through the slow and irregular retire work handler.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 ++--
drivers/gpu/drm/i915/i915_gem.c | 29 -
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a8e7761cdc7d..594ee65a6c06 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4226,8 +4226,12 @@ i915_drop_caches_set(void *data, u64 val)
i915_gem_shrink_all(dev_priv);
fs_reclaim_release(GFP_KERNEL);
- if (val & DROP_IDLE)
- drain_delayed_work(&dev_priv->gt.idle_work);
+ if (val & DROP_IDLE) {
+ do {
+ flush_delayed_work(&dev_priv->gt.retire_work);
+ drain_delayed_work(&dev_priv->gt.idle_work);
+ } while (READ_ONCE(dev_priv->gt.awake));
+ }
if (val & DROP_FREED)
i915_gem_drain_freed_objects(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 530d6d0109b4..9eb93ca06309 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -139,6 +139,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
static u32 __i915_gem_park(struct drm_i915_private *i915)
{
+ GEM_TRACE("\n");
+
lockdep_assert_held(&i915->drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
GEM_BUG_ON(!list_empty(&i915->gt.active_rings));
@@ -193,6 +195,8 @@ void i915_gem_park(struct drm_i915_private *i915)
void i915_gem_unpark(struct drm_i915_private *i915)
{
+ GEM_TRACE("\n");
+
lockdep_assert_held(&i915->drm.struct_mutex);
GEM_BUG_ON(!i915->gt.active_requests);
@@ -3503,6 +3507,21 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (!READ_ONCE(dev_priv->gt.awake))
return;
+ /*
+* Flush out the last user context, leaving only the pinned
+* kernel context resident. When we are idling on the kernel_context,
+* no more new requests (with a context switch) are emitted and we
+* can finally rest. A consequence is that the idle work handler is
+* always called at least twice before idling (and if the system is
+* idle that implies a round trip through the retire worker).
+*/
+ mutex_lock(&dev_priv->drm.struct_mutex);
+ i915_gem_switch_to_kernel_context(dev_priv);
+ mutex_unlock(&dev_priv->drm.struct_mutex);
+
+ GEM_TRACE("active_requests=%d (after switch-to-kernel-context)\n",
+ READ_ONCE(dev_priv->gt.active_requests));
+
/*
* Wait for last execlists context complete, but bail out in case a
* new request is submitted. As we don't trust the hardware, we
@@ -4913,11 +4932,9 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
void i915_gem_sanitize(struct drm_i915_private *i915)
{
- if (i915_terminally_wedged(&i915->gpu_error)) {
- mutex_lock(&i915->drm.struct_mutex);
+ mutex_lock(&i915->drm.struct_mutex);
+ if (i915_terminally_wedged(&i915->gpu_error))
i915_gem_unset_wedged(i915);
- mutex_unlock(&i915->drm.struct_mutex);
- }
/*
* If we inherit context state from the BIOS or earlier occupants
@@ -4929,6 +4946,9 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
*/
if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));
+
+ i915_gem_contexts_lost(i915);
+ mutex_unlock(&i915->drm.struct_mutex);
}
int i915_gem_suspend(struct drm_i915_private *dev_priv)
@@ -4964,7 +4984,6 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
assert_kernel_context_is_current(dev_priv);
}
- i915_gem_contexts_lost(dev_priv);
mutex_unlock(&dev->struct_mutex);
intel_uc_suspend(dev_priv);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Add P010, P012, P016 plane control definitions
Add needed plane control flag definitions for P010, P012 and
P016 formats.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6953419..a7e9316 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6366,8 +6366,11 @@ enum {
#define PLANE_CTL_FORMAT_YUV422 ( 0 << 24)
#define PLANE_CTL_FORMAT_NV12( 1 << 24)
#define PLANE_CTL_FORMAT_XRGB_2101010( 2 << 24)
+#define PLANE_CTL_FORMAT_P010( 3 << 24)
#define PLANE_CTL_FORMAT_XRGB_ ( 4 << 24)
+#define PLANE_CTL_FORMAT_P012( 5 << 24)
#define PLANE_CTL_FORMAT_XRGB_16161616F ( 6 << 24)
+#define PLANE_CTL_FORMAT_P016( 7 << 24)
#define PLANE_CTL_FORMAT_AYUV( 8 << 24)
#define PLANE_CTL_FORMAT_INDEXED ( 12 << 24)
#define PLANE_CTL_FORMAT_RGB_565 ( 14 << 24)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: enable P010, P012, P016 formats for primary and sprite planes
Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_display.c | 24 +-
drivers/gpu/drm/i915/intel_sprite.c | 39 +++-
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 236b83f..44259f6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -104,6 +104,25 @@ static const uint32_t skl_pri_planar_formats[] = {
DRM_FORMAT_NV12,
};
+static const uint32_t glk_primary_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_P010,
+ DRM_FORMAT_P012,
+ DRM_FORMAT_P016,
+};
+
static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13515,7 +13534,10 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->check_plane = intel_check_primary_plane;
if (INTEL_GEN(dev_priv) >= 9) {
- if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+ if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+ intel_primary_formats = glk_primary_formats;
+ num_formats = ARRAY_SIZE(glk_primary_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY))
{
intel_primary_formats = skl_pri_planar_formats;
num_formats = ARRAY_SIZE(skl_pri_planar_formats);
} else {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index c3e654f..cf90ae2 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1209,6 +1209,22 @@ static uint32_t skl_planar_formats[] = {
DRM_FORMAT_NV12,
};
+static uint32_t glk_planar_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_P010,
+ DRM_FORMAT_P012,
+ DRM_FORMAT_P016,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1398,7 +1414,28 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
}
intel_plane->base.state = &state->base;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+ intel_plane->can_scale = true;
+ state->scaler_id = -1;
+
+ intel_plane->update_plane = skl_update_plane;
+ intel_plane->disable_plane = skl_disable_plane;
+ intel_plane->get_hw_state = skl_plane_get_hw_state;
+
+ if (skl_plane_has_planar(dev_priv, pipe,
+PLANE_SPRITE0 + plane)) {
+ plane_formats = glk_planar_formats;
+ num_plane_formats = ARRAY_SIZE(glk_planar_formats);
+ } else {
+ plane_formats = skl_plane_formats;
+ num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+ }
+
+ if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
+ modifiers = skl_plane_format_modifiers_ccs;
+ else
+ modifiers = skl_plane_format_modifiers_noccs;
+ } else if (INTEL_GEN(dev_priv) >= 9) {
intel_plane->can_scale = true;
state->scaler_id = -1;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +-
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 48 ++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 19 ++--
drivers/gpu/drm/i915/intel_sprite.c | 21 +-
6 files changed, 73 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 61ddb58..d42624b 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -332,8 +332,7 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
/* set scaler mode */
if ((INTEL_GEN(dev_priv) >= 9) &&
plane_state && plane_state->base.fb &&
- plane_state->base.fb->format->format ==
- DRM_FORMAT_NV12) {
+ is_planar_yuv_format(plane_state->base.fb->format->format))
{
if (INTEL_GEN(dev_priv) == 9 &&
!IS_GEMINILAKE(dev_priv) &&
!IS_SKYLAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 6d06878..aca3bef 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -188,7 +188,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
- if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+ if (state->visible && is_planar_yuv_format(state->fb->format->format))
crtc_state->nv12_planes |= BIT(intel_plane->id);
else
crtc_state->nv12_planes &= ~BIT(intel_plane->id);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d4c9e2..236b83f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2664,6 +2664,12 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_P010:
+ return DRM_FORMAT_P010;
+ case PLANE_CTL_FORMAT_P012:
+ return DRM_FORMAT_P012;
+ case PLANE_CTL_FORMAT_P016:
+ return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3180,7 +3186,7 @@ int skl_check_plane_surface(const struct intel_crtc_state
*crtc_state,
* Handle the AUX surface first since
* the main surface setup depends on it.
*/
- if (fb->format->format == DRM_FORMAT_NV12) {
+ if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_surface(crtc_state, plane_state);
if (ret)
return ret;
@@ -3496,6 +3502,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_P010:
+ return PLANE_CTL_FORMAT_P010;
+ case DRM_FORMAT_P012:
+ return PLANE_CTL_FORMAT_P012;
+ case DRM_FORMAT_P016:
+ return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -3647,7 +3659,7 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
if (intel_format_is_yuv(fb->format->format)) {
- if (fb->format->format == DRM_FORMAT_NV12) {
+ if (is_planar_yuv_format(fb->format->format)) {
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
goto out;
@@ -4769,8 +4781,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
need_scaling = src_w != dst_w || src_h != dst_h;
if (plane_scaler_check)
- if (pixel_format == DRM_FORMAT_NV12)
- need_scaling = true;
+ need_scaling = is_planar_yuv_format(pixel_format);
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
@@ -4811,7 +4822,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return 0;
}
- if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
+ if (plane_scaler_check && is_planar_yuv_format(pixel_format) &&
(src_h <
[Intel-gfx] [PATCH 5/5] drm/i915: Only sanitize GEM from late suspend
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and
disabling reset (gem_eio/suspend). This results in the device continuing
on without being reset, but since it has gone through HW sanitization to
account for the suspend/resume cycle, we have to assume the device has
been reset to its defaults. A simple way around this is to skip the
sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 22 +-
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8f002ae22e62..0d9b8cc0436d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -636,6 +636,8 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
static void i915_gem_fini(struct drm_i915_private *dev_priv)
{
+ i915_gem_suspend_late(dev_priv);
+
/* Flush any outstanding unpin_work. */
i915_gem_drain_workqueue(dev_priv);
@@ -1611,7 +1613,6 @@ static int i915_drm_suspend(struct drm_device *dev)
opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
intel_opregion_notify_adapter(dev_priv, opregion_target_state);
- intel_uncore_suspend(dev_priv);
intel_opregion_unregister(dev_priv);
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
@@ -1633,7 +1634,10 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
disable_rpm_wakeref_asserts(dev_priv);
+ i915_gem_suspend_late(dev_priv);
+
intel_display_set_init_power(dev_priv, false);
+ intel_uncore_suspend(dev_priv);
/*
* In case of firmware assisted context save/restore don't manually
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 487922f88b76..4257ffc1bae1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3169,6 +3169,7 @@ void i915_gem_cleanup_engines(struct drm_i915_private
*dev_priv);
int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
unsigned int flags);
int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
+void i915_gem_suspend_late(struct drm_i915_private *dev_priv);
void i915_gem_resume(struct drm_i915_private *dev_priv);
int i915_gem_fault(struct vm_fault *vmf);
int i915_gem_object_wait(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 75bdfafc97a2..874ac1a8ec47 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5050,6 +5050,17 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
if (WARN_ON(!intel_engines_are_idle(dev_priv)))
i915_gem_set_wedged(dev_priv); /* no hope, discard everything */
+ intel_runtime_pm_put(dev_priv);
+ return 0;
+
+err_unlock:
+ mutex_unlock(&dev->struct_mutex);
+ intel_runtime_pm_put(dev_priv);
+ return ret;
+}
+
+void i915_gem_suspend_late(struct drm_i915_private *i915)
+{
/*
* Neither the BIOS, ourselves or any other kernel
* expects the system to be in execlists mode on startup,
@@ -5069,16 +5080,9 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
* machines is a good idea, we don't - just in case it leaves the
* machine in an unusable condition.
*/
- intel_uc_sanitize(dev_priv);
- i915_gem_sanitize(dev_priv);
- intel_runtime_pm_put(dev_priv);
- return 0;
-
-err_unlock:
- mutex_unlock(&dev->struct_mutex);
- intel_runtime_pm_put(dev_priv);
- return ret;
+ intel_uc_sanitize(i915);
+ i915_gem_sanitize(i915);
}
void i915_gem_resume(struct drm_i915_private *i915)
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
Add P010 definition, semi-planar yuv format where each component
is 16 bits 10 msb containing color value. First come Y plane [10:6]
followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
Add P012 definition, semi-planar yuv format where each component
is 16 bits 12 msb containing color value. First come Y plane [12:4]
followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
Add P016 definition, semi-planar yuv format where each component
is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
plane [16:16]
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 5ca6395..5bb2641 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d..0b259ad 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -141,6 +141,10 @@ extern "C" {
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane, 10 bit per channel */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane, 12 bit per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane, 16 bit per channel */
+
/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
== Series Details == Series: series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request() URL : https://patchwork.freedesktop.org/series/43892/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Remove stale asserts from i915_gem_find_active_request() Okay! Commit: drm/i915: Switch to kernel context before idling at runtime Okay! Commit: drm/i915: "Race-to-idle" after switching to the kernel context Okay! Commit: drm/i915: After reset on sanitization, reset the engine backends Okay! Commit: drm/i915: Only sanitize GEM from late suspend -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3665:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
== Series Details == Series: series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request() URL : https://patchwork.freedesktop.org/series/43892/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4253 -> Patchwork_9139 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9139 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9139, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43892/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9139: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9139 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-plain-flip: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-y3: NOTRUN -> DMESG-WARN (fdo#104951) Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: DMESG-FAIL (fdo#106103, fdo#102614) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (44 -> 38) == Additional (1): fi-cnl-y3 Missing(7): fi-ilk-m540 fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4253 -> Patchwork_9139 CI_DRM_4253: d0a3423d398934e94a1924daea934b1578588336 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9139: 242530373b1e6f8869530924967851b8b9e50f71 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 242530373b1e drm/i915: Only sanitize GEM from late suspend e9ad0c1a4120 drm/i915: After reset on sanitization, reset the engine backends 6d020d8df475 drm/i915: "Race-to-idle" after switching to the kernel context b3f18b12420e drm/i915: Switch to kernel context before idling at runtime 74726d9e911a drm/i915: Remove stale asserts from i915_gem_find_active_request() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9139/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable P010, P012 and P016 formats for GLK/CNL
== Series Details ==
Series: Enable P010, P012 and P016 formats for GLK/CNL
URL : https://patchwork.freedesktop.org/series/43891/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
28b8b10f6e1d drm: Add P010, P012, P016 format definitions and fourcc
-:28: WARNING:LONG_LINE: line over 100 characters
#28: FILE: drivers/gpu/drm/drm_fourcc.c:176:
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
-:29: WARNING:LONG_LINE: line over 100 characters
#29: FILE: drivers/gpu/drm/drm_fourcc.c:177:
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
-:30: WARNING:LONG_LINE: line over 100 characters
#30: FILE: drivers/gpu/drm/drm_fourcc.c:178:
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
-:42: WARNING:LONG_LINE_COMMENT: line over 100 characters
#42: FILE: include/uapi/drm/drm_fourcc.h:144:
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane, 10 bit per channel */
-:43: WARNING:LONG_LINE_COMMENT: line over 100 characters
#43: FILE: include/uapi/drm/drm_fourcc.h:145:
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane, 12 bit per channel */
-:44: WARNING:LONG_LINE_COMMENT: line over 100 characters
#44: FILE: include/uapi/drm/drm_fourcc.h:146:
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane, 16 bit per channel */
total: 0 errors, 6 warnings, 0 checks, 19 lines checked
042148f25a61 drm/i915: Add P010, P012, P016 plane control definitions
-:19: ERROR:SPACING: space prohibited after that open parenthesis '('
#19: FILE: drivers/gpu/drm/i915/i915_reg.h:6373:
+#define PLANE_CTL_FORMAT_P010( 3 << 24)
-:21: ERROR:SPACING: space prohibited after that open parenthesis '('
#21: FILE: drivers/gpu/drm/i915/i915_reg.h:6375:
+#define PLANE_CTL_FORMAT_P012( 5 << 24)
-:23: ERROR:SPACING: space prohibited after that open parenthesis '('
#23: FILE: drivers/gpu/drm/i915/i915_reg.h:6377:
+#define PLANE_CTL_FORMAT_P016( 7 << 24)
total: 3 errors, 0 warnings, 0 checks, 11 lines checked
0a170b287173 drm/i915: preparations for enabling P010, P012, P016 formats
-:145: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#145: FILE: drivers/gpu/drm/i915/intel_display.c:14366:
+
drm_get_format_name(mode_cmd->pixel_format,
+ &format_name));
-:151: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#151: FILE: drivers/gpu/drm/i915/intel_display.c:14372:
+
drm_get_format_name(mode_cmd->pixel_format,
+ &format_name));
total: 0 errors, 0 warnings, 2 checks, 244 lines checked
a4aeab6bd142 drm/i915: enable P010, P012, P016 formats for primary and sprite
planes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/gem_ctx_isolation: Test INSTPM back to gen6
On 29/05/18 12:16, Chris Wilson wrote:
Lionel pointed out that INSTPM was context saved, at least from gen6,
not from gen9. The only caveat is that INSTPM is a masked register (the
upper 16bits are a write-enable mask, the lower 16bits the value to
change) and also contains a read-only counter bit (which counts flushes,
and so flip flops between batches). Being a non-privileged register that
userspace wants to manipulate, it is writable and readable from a
userspace batch, so we can test whether or not a write from one context
is visible from a second.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Joonas Lahtinen
Reviewed-by: Lionel Landwerlin
---
tests/gem_ctx_isolation.c | 51 ---
1 file changed, 42 insertions(+), 9 deletions(-)
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
index 4968e3678..fe7d3490c 100644
--- a/tests/gem_ctx_isolation.c
+++ b/tests/gem_ctx_isolation.c
@@ -63,10 +63,12 @@ static const struct named_register {
unsigned int engine_mask;
uint32_t offset;
uint32_t count;
+ uint32_t ignore_bits;
+ bool masked;
} nonpriv_registers[] = {
{ "NOPID", NOCTX, RCS0, 0x2094 },
{ "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
- { "INSTPM", GEN9, RCS0, 0x20c0 },
+ { "INSTPM", GEN6, RCS0, 0x20c0, 1, BIT(8) /* ro counter */, true },
{ "IA_VERTICES_COUNT", GEN4, RCS0, 0x2310, 2 },
{ "IA_PRIMITIVES_COUNT", GEN4, RCS0, 0x2318, 2 },
{ "VS_INVOCATION_COUNT", GEN4, RCS0, 0x2320, 2 },
@@ -167,6 +169,17 @@ static const char *register_name(uint32_t offset, char
*buf, size_t len)
return "unknown";
}
+static const struct named_register *lookup_register(uint32_t offset)
+{
+ for (const struct named_register *r = nonpriv_registers; r->name; r++) {
+ unsigned int width = r->count ? 4*r->count : 4;
+ if (offset >= r->offset && offset < r->offset + width)
+ return r;
+ }
+
+ return NULL;
+}
+
static bool ignore_register(uint32_t offset)
{
for (const struct named_register *r = ignore_registers; r->name; r++) {
@@ -283,7 +296,10 @@ static void write_regs(int fd,
count--; offset += 4) {
*b++ = 0x22 << 23 | 1; /* LRI */
*b++ = offset;
- *b++ = value;
+ if (r->masked)
+ *b++ = value | 0xu << 16;
+ else
+ *b++ = value;
}
}
*b++ = MI_BATCH_BUFFER_END;
@@ -424,14 +440,31 @@ static void compare_regs(int fd, uint32_t A, uint32_t B,
const char *who)
num_errors = 0;
for (unsigned int n = 0; n < NUM_REGS; n++) {
+ const struct named_register *r;
uint32_t offset = n * sizeof(uint32_t);
- if (a[n] != b[n] && !ignore_register(offset)) {
- igt_warn("Register 0x%04x (%s): A=%08x B=%08x\n",
-offset,
-register_name(offset, buf, sizeof(buf)),
-a[n], b[n]);
- num_errors++;
- }
+ uint32_t mask;
+
+ if (a[n] == b[n])
+ continue;
+
+ if (ignore_register(offset))
+ continue;
+
+ mask = ~0u;
+ r = lookup_register(offset);
+ if (r && r->masked)
+ mask >>= 16;
+ if (r && r->ignore_bits)
+ mask &= ~r->ignore_bits;
+
+ if ((a[n] & mask) == (b[n] & mask))
+ continue;
+
+ igt_warn("Register 0x%04x (%s): A=%08x B=%08x\n",
+offset,
+register_name(offset, buf, sizeof(buf)),
+a[n] & mask, b[n] & mask);
+ num_errors++;
}
munmap(b, regs_size);
munmap(a, regs_size);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable P010, P012 and P016 formats for GLK/CNL
== Series Details == Series: Enable P010, P012 and P016 formats for GLK/CNL URL : https://patchwork.freedesktop.org/series/43891/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Add P010, P012, P016 format definitions and fourcc Okay! Commit: drm/i915: Add P010, P012, P016 plane control definitions Okay! Commit: drm/i915: preparations for enabling P010, P012, P016 formats -O:drivers/gpu/drm/i915/intel_display.c:13017:21: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_display.c:13017:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:13031:21: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:13031:21: warning: expression using sizeof(void) Commit: drm/i915: enable P010, P012, P016 formats for primary and sprite planes Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable P010, P012 and P016 formats for GLK/CNL
== Series Details == Series: Enable P010, P012 and P016 formats for GLK/CNL URL : https://patchwork.freedesktop.org/series/43891/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4253 -> Patchwork_9140 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9140 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9140, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43891/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9140: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9140 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-skl-guc: PASS -> FAIL (fdo#103191, fdo#104724) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: DMESG-FAIL (fdo#106103, fdo#102614) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (44 -> 39) == Additional (1): fi-cnl-y3 Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4253 -> Patchwork_9140 CI_DRM_4253: d0a3423d398934e94a1924daea934b1578588336 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9140: a4aeab6bd142acc0b0e0043c94006fa898184e0f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a4aeab6bd142 drm/i915: enable P010, P012, P016 formats for primary and sprite planes 0a170b287173 drm/i915: preparations for enabling P010, P012, P016 formats 042148f25a61 drm/i915: Add P010, P012, P016 plane control definitions 28b8b10f6e1d drm: Add P010, P012, P016 format definitions and fourcc == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9140/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
Quoting Michal Wajdeczko (2018-05-28 18:16:18) > SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and > those events are now handled by intel_guc_to_host_event_handler_mmio(). > > We should not try to read it on MMIO action error as 1) we may be using > different set of registers for GuC MMIO communication, and 2) GuC may > use CTB mechanism for sending events to host. Ok. > While here, upgrade error message to DRM_ERROR. Does the error help? What do you want to convey to the user? For error handling, we want to propagate the result back anyway for the caller has to decide what to do next. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915/guc: New interface files for GuC starting in Gen11
Hi,
On Fri, 25 May 2018 23:59:35 +0200, Oscar Mateo
wrote:
GuC interface has been redesigned (or cleaned up, rather) starting
with Gen11, as a stepping stone towards a new branching strategy
that helps maintain backwards compatibility with previous Gens, as
well as sideward compatibility with other OSes.
The interface is split in two header files: one for the KMD and one
for clients of the GuC (which, in our case, happens to be the KMD
as well). SLPC interface files will come at a later date.
Could we get eyes on the new interface header files, to make sure the
GuC team is moving in the right direction?
Signed-off-by: Oscar Mateo
Cc: Joonas Lahtinen
Cc: Kevin Rogovin
Cc: John A Spotswood
Cc: Anusha Srivatsa
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Michel Thierry
Cc: Chris Wilson
Cc: Michał Winiarski
Cc: Tomasz Lis
Cc: Jon Ewins
Cc: Sujaritha Sundaresan
Cc: Jalpa Patel
Cc: Jackie Li
---
drivers/gpu/drm/i915/intel_guc_client_interface.h | 255 +++
drivers/gpu/drm/i915/intel_guc_kmd_interface.h| 847
++
2 files changed, 1102 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_guc_client_interface.h
create mode 100644 drivers/gpu/drm/i915/intel_guc_kmd_interface.h
can we name these files as:
drivers/gpu/drm/i915/intel_guc_interface.h
drivers/gpu/drm/i915/intel_guc_interface_client.h
or
drivers/gpu/drm/i915/intel_guc_defs.h
drivers/gpu/drm/i915/intel_guc_defs_client.h
or
drivers/gpu/drm/i915/guc/guc.h
drivers/gpu/drm/i915/guc/guc_client.h
diff --git a/drivers/gpu/drm/i915/intel_guc_client_interface.h
b/drivers/gpu/drm/i915/intel_guc_client_interface.h
new file mode 100644
index 000..1ef91a7
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_client_interface.h
@@ -0,0 +1,255 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef _INTEL_GUC_CLIENT_INTERFACE_H_
+#define _INTEL_GUC_CLIENT_INTERFACE_H_
+
need to include types.h for u32
+#pragma pack(1)
+
+/*
+ ** Engines
**
+
*/
no fancy markups, please
+
+#define GUC_MAX_ENGINE_INSTANCE_PER_CLASS 4
+#define GUC_MAX_SCHEDULABLE_ENGINE_CLASS 5
+#define GUC_MAX_ENGINE_CLASS_COUNT 6
+#define GUC_ENGINE_INVALID 6
hmm, why not 7 or 127 ?
maybe if we need value for INVALID we should use 0 or -1 (~0)
+
+/* Engine Class that uKernel can schedule on. This is just a SW
enumeration.
+ * HW configuration will depend on the Platform and SKU
+ */
+enum uk_engine_class {
why there is new prefix "uk" ?
+ UK_RENDER_ENGINE_CLASS = 0,
+ UK_VDECENC_ENGINE_CLASS = 1,
+ UK_VE_ENGINE_CLASS = 2,
+ UK_BLT_COPY_ENGINE_CLASS = 3,
+ UK_RESERVED_ENGINE_CLASS = 4,
+ UK_OTHER_ENGINE_CLASS = 5,
either use valid names or drop RESERVED/OTHER as values
from 0 to GUC_MAX_ENGINE_CLASS_COUNT are 'reserved' by
definition unless explicitly defined ;)
+};
as we don't use enum in binary struct definitions, then maybe we
should define all engine classes with #define as:
#define ENGINE_CLASS_INVALID 0
#define ENGINE_CLASS_ALL 0
#define ENGINE_CLASS_RENDER 1
#define ENGINE_CLASS_VDECENC 2
...
#define ENGINE_CLASS_MAX 7
what if future HW will support more than 7 engine classes
or they will be so different that they deserve separate id?
why
+
+/* Engine Instance that uKernel can schedule on */
+enum uk_engine_instance {
+ UK_ENGINE_INSTANCE_0 = 0,
+ UK_ENGINE_INSTANCE_1 = 1,
+ UK_ENGINE_INSTANCE_2 = 2,
+ UK_ENGINE_INSTANCE_3 = 3,
+ UK_INVALID_ENGINE_INSTANCE = GUC_MAX_ENGINE_INSTANCE_PER_CLASS,
+ UK_ENGINE_ALL_INSTANCES = UK_INVALID_ENGINE_INSTANCE
+};
I'm not sure why we would need this enum as we already have
GUC_MAX_ENGINE_INSTANCE_PER_CLASS and can easily identify
instance as [0 ... GUC_MAX_ENGINE_INSTANCE_PER_CLASS), or
maybe more intuitive would be use normal indexing and use 0
to indicate INVALID/AUTO/ALL instance ?
#define ENGINE_INSTANCE_INVALID 0
#define ENGINE_INSTANCE_ALL 0
#define ENGINE_INSTANCE_MAX 4
+
+/* Target Engine field used in WI header and Guc2Host */
+struct guc_target_engine {
+ union {
+ struct {
+ /* One of enum uk_engine_class */
+ u8 engine_class : 3;
enum defines only 0..5 while in these 3 bits we can pass 0..7
+ /* One of enum uk_engine_instance */
+ u8 engine_instance : 4;
again, mismatch between 'enum' and bitfields.
+ /* All enabled engine classes and instances */
+ u8 all_engines : 1;
Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-05-28 18:16:18) SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and those events are now handled by intel_guc_to_host_event_handler_mmio(). We should not try to read it on MMIO action error as 1) we may be using different set of registers for GuC MMIO communication, and 2) GuC may use CTB mechanism for sending events to host. Ok. While here, upgrade error message to DRM_ERROR. Does the error help? What do you want to convey to the user? For error handling, we want to propagate the result back anyway for the caller has to decide what to do next. We are propagating error code to the caller, but since any error from the GuC is unexpected, we should rather always log it and don't rely on the caller or drm debug for that. Note that in case of CTB we also log received errors using DRM_ERROR (see intel_guc_send_ct). Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
Quoting Michal Wajdeczko (2018-05-29 16:10:44) > On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2018-05-28 18:16:18) > >> SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and > >> those events are now handled by intel_guc_to_host_event_handler_mmio(). > >> > >> We should not try to read it on MMIO action error as 1) we may be using > >> different set of registers for GuC MMIO communication, and 2) GuC may > >> use CTB mechanism for sending events to host. > > > > Ok. > > > >> While here, upgrade error message to DRM_ERROR. > > > > Does the error help? What do you want to convey to the user? For error > > handling, we want to propagate the result back anyway for the caller has > > to decide what to do next. > > We are propagating error code to the caller, but since any error from the > GuC is unexpected, we should rather always log it and don't rely on the > caller or drm debug for that. Note that in case of CTB we also log received > errors using DRM_ERROR (see intel_guc_send_ct). But whose error? Ours or the hw? We expect hw errors, or should ;) But mostly from the pov of the message, is this the right information to flag as the error or does the caller have better context? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't read SOFT_SCRATCH(15) on MMIO error
On Tue, 29 May 2018 17:17:02 +0200, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-05-29 16:10:44) On Tue, 29 May 2018 16:54:12 +0200, Chris Wilson wrote: > Quoting Michal Wajdeczko (2018-05-28 18:16:18) >> SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and >> those events are now handled by intel_guc_to_host_event_handler_mmio(). >> >> We should not try to read it on MMIO action error as 1) we may be using >> different set of registers for GuC MMIO communication, and 2) GuC may >> use CTB mechanism for sending events to host. > > Ok. > >> While here, upgrade error message to DRM_ERROR. > > Does the error help? What do you want to convey to the user? For error > handling, we want to propagate the result back anyway for the caller has > to decide what to do next. We are propagating error code to the caller, but since any error from the GuC is unexpected, we should rather always log it and don't rely on the caller or drm debug for that. Note that in case of CTB we also log received errors using DRM_ERROR (see intel_guc_send_ct). But whose error? Ours or the hw? We expect hw errors, or should ;) well, it can be any i915/FW/HW - hard to tell without other full logs.. But mostly from the pov of the message, is this the right information to flag as the error or does the caller have better context? Only caller can easily provide additional info related for failed command (such as index/address that was rejected by FW) that could help diagnose the problem, but in case FW/HW errors it does not matter. At this point, we can only identify request/action ID that has failed. But that's better than nothing. /Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, One potential Spectre vector plugging patch, a NULL deref fix and a DMI info fix reported by user. This is still based on -rc6 as my flight was delayed last week to the extent I missed possibility of sending the PR. For 4.19, Rodrigo will be picking up drm-next after Jani is done with 4.18, while I get to slack off. Regards, Joonas drm-intel-fixes-2018-05-29: - Fix for potential Spectre vector in the new query uAPI - Fix NULL pointer deref (FDO #106559) - DMI fix to hide LVDS for Radiant P845 (FDO #105468) The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11: Linux 4.17-rc6 (2018-05-20 15:31:38 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-05-29 for you to fetch changes up to 65b3bdc807ac7bd83f5b27bc2c29a3c631eed7dd: drm/i915/query: nospec expects no more than an unsigned long (2018-05-29 13:53:07 +0300) - Fix for potential Spectre vector in the new query uAPI - Fix NULL pointer deref (FDO #106559) - DMI fix to hide LVDS for Radiant P845 (FDO #105468) Chris Wilson (3): drm/i915/lvds: Move acpi lid notification registration to registration phase drm/i915/query: Protect tainted function pointer lookup drm/i915/query: nospec expects no more than an unsigned long Ondrej Zary (1): drm/i915: Disable LVDS on Radiant P845 drivers/gpu/drm/i915/i915_query.c | 15 +--- drivers/gpu/drm/i915/intel_lvds.c | 51 ++- 2 files changed, 51 insertions(+), 15 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
Op 29-05-18 om 15:28 schreef Juha-Pekka Heikkila:
> Add P010 definition, semi-planar yuv format where each component
> is 16 bits 10 msb containing color value. First come Y plane [10:6]
> followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
>
> Add P012 definition, semi-planar yuv format where each component
> is 16 bits 12 msb containing color value. First come Y plane [12:4]
> followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
>
> Add P016 definition, semi-planar yuv format where each component
> is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
> plane [16:16]
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/drm_fourcc.c | 3 +++
> include/uapi/drm/drm_fourcc.h | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5ca6395..5bb2641 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> + { .format = DRM_FORMAT_P012,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> + { .format = DRM_FORMAT_P016,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d..0b259ad 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -141,6 +141,10 @@ extern "C" {
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
>
> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
> subsampled Cr:Cb plane, 10 bit per channel */
> +#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2
> subsampled Cr:Cb plane, 12 bit per channel */
> +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
> subsampled Cr:Cb plane, 16 bit per channel */
> +
> /*
> * 3 plane YCbCr
> * index 0: Y plane, [7:0] Y
Hey,
The DRM_FORMAT specifications are a bit unclear. It should be made clear that
P010 = P016, with the lower 6 bits zerod.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes for 4.17
Hi Dave, Although we didn't have anything for you last week, we have a couple of one-liners this week. Tomi is fixing a regression introduced in 4.17, and Dhinakaran added a previously unsupported psr setup time which could be affecting displays in the wild. drm-misc-fixes-2018-05-29: core: Add 220us psr setup time (Dhinakaran) omap: Fix NULL deref (Tomi) Cc: Dhinakaran Pandiyan Cc: Tomi Valkeinen Cheers, Sean The following changes since commit 2b6207291b7b277a5df9d1aab44b56815a292dba: drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl() (2018-05-16 17:56:06 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-05-29 for you to fetch changes up to 2bc5ff0bdc00d81d719dad74589317a260d583ed: drm/omap: fix NULL deref crash with SDI displays (2018-05-24 19:14:46 +0300) core: Add 220us psr setup time (Dhinakaran) omap: Fix NULL deref (Tomi) Cc: Dhinakaran Pandiyan Cc: Tomi Valkeinen Dhinakaran Pandiyan (1): drm/psr: Fix missed entry in PSR setup time table. Tomi Valkeinen (1): drm/omap: fix NULL deref crash with SDI displays drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/omapdrm/dss/sdi.c | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) -- 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] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
== Series Details == Series: series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request() URL : https://patchwork.freedesktop.org/series/43892/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4253_full -> Patchwork_9139_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9139_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9139_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43892/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9139_full: === IGT changes === Possible regressions igt@perf_pmu@busy-hang-rcs0: shard-kbl: PASS -> FAIL +1 shard-glk: PASS -> FAIL +1 igt@perf_pmu@busy-hang-vecs0: shard-apl: PASS -> FAIL +2 Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS +1 igt@gem_mocs_settings@mocs-rc6-bsd1: shard-kbl: PASS -> SKIP igt@kms_chv_cursor_fail@pipe-a-256x256-bottom-edge: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9139_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-apl: PASS -> DMESG-FAIL (fdo#106560) igt@gem_eio@suspend: shard-snb: PASS -> INCOMPLETE (fdo#105411) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: PASS -> FAIL (fdo#105703) Possible fixes igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS igt@kms_cursor_crc@cursor-256x256-suspend: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS igt@kms_vblank@pipe-b-accuracy-idle: shard-hsw: FAIL (fdo#102583) -> PASS fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4253 -> Patchwork_9139 CI_DRM_4253: d0a3423d398934e94a1924daea934b1578588336 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9139: 242530373b1e6f8869530924967851b8b9e50f71 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9139/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm/i915: Remove stale asserts from i915_gem_find_active_request()
Quoting Patchwork (2018-05-29 18:53:25) > == Series Details == > > Series: series starting with [1/5] drm/i915: Remove stale asserts from > i915_gem_find_active_request() > URL : https://patchwork.freedesktop.org/series/43892/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4253_full -> Patchwork_9139_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_9139_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_9139_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/43892/revisions/1/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_9139_full: > > === IGT changes === > > Possible regressions > > igt@perf_pmu@busy-hang-rcs0: > shard-kbl: PASS -> FAIL +1 > shard-glk: PASS -> FAIL +1 > > igt@perf_pmu@busy-hang-vecs0: > shard-apl: PASS -> FAIL +2 These are an issue in the igt not coordinating it's wait-until-idle with the kernel. Simple patch on list. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/gmbus: Enable burst read
On Fri, May 18, 2018 at 02:54:53PM +0530, Ramalingam C wrote:
> Support for Burst read in HW is added for HDCP2.2 compliance
> requirement.
>
> This patch enables the burst read for all the gmbus read of more than
> 511Bytes, on capable platforms.
>
> v2:
> Extra line is removed.
> v3:
> Macro is added for detecting the BURST_READ Support [Jani]
> Runtime detection of the need for burst_read [Jani]
> Calculation enhancement.
> v4:
> GMBUS0 reg val is passed from caller [ville]
> Removed a extra var [ville]
> Extra brackets are removed [ville]
> Implemented the handling of 512Bytes Burst Read.
> v5:
> Burst read max length is fixed at 767Bytes [Ville]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 ++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_i2c.c | 62
> +---
> 3 files changed, 56 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 028691108125..14293fc1a142 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2552,6 +2552,9 @@ intel_info(const struct drm_i915_private *dev_priv)
> */
> #define HAS_AUX_IRQ(dev_priv) true
> #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> +#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
> + IS_GEMINILAKE(dev_priv) || \
> + IS_KABYLAKE(dev_priv))
Note 100% sure about these. The spec say some late stepping SPT has this
already. But I suppose this KBL+ match means just KBP+?
Hmm. Did I ask this already before? Getting some dejavu here.
> /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
> * rows, which changed the alignment requirements and fence programming.
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ebdf7c9d816e..575d9495f3e2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2996,6 +2996,7 @@ enum i915_power_well_id {
> #define GMBUS_RATE_400KHZ (2<<8) /* reserved on Pineview */
> #define GMBUS_RATE_1MHZ(3<<8) /* reserved on Pineview */
> #define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
> +#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
> #define GMBUS_PIN_DISABLED 0
> #define GMBUS_PIN_SSC 1
> #define GMBUS_PIN_VGADDC 2
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 1c0f6b56b209..9e1142a2f81b 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -371,12 +371,30 @@ unsigned int gmbus_max_xfer_size(struct
> drm_i915_private *dev_priv)
> static int
> gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
> unsigned short addr, u8 *buf, unsigned int len,
> - u32 gmbus1_index)
> + u32 gmbus0_reg, u32 gmbus1_index)
> {
> + unsigned int size = len;
> + bool burst_read = len > gmbus_max_xfer_size(dev_priv);
> + bool extra_byte_added = false;
> +
> + if (burst_read) {
> +
Stray newline.
Otherwise this looks good to me.
Reviewed-by: Ville Syrjälä
> + /*
> + * As per HW Spec, for 512Bytes need to read extra Byte and
> + * Ignore the extra byte read.
> + */
> + if (len == 512) {
> + extra_byte_added = true;
> + len++;
> + }
> + size = len % 256 + 256;
> + I915_WRITE_FW(GMBUS0, gmbus0_reg | GMBUS_BYTE_CNT_OVERRIDE);
> + }
> +
> I915_WRITE_FW(GMBUS1,
> gmbus1_index |
> GMBUS_CYCLE_WAIT |
> - (len << GMBUS_BYTE_COUNT_SHIFT) |
> + (size << GMBUS_BYTE_COUNT_SHIFT) |
> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_READ | GMBUS_SW_RDY);
> while (len) {
> @@ -389,17 +407,34 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
>
> val = I915_READ_FW(GMBUS3);
> do {
> + if (extra_byte_added && len == 1)
> + break;
> +
> *buf++ = val & 0xff;
> val >>= 8;
> } while (--len && ++loop < 4);
> +
> + if (burst_read && len == size - 4)
> + /* Reset the override bit */
> + I915_WRITE_FW(GMBUS0, gmbus0_reg);
> }
>
> return 0;
> }
>
> +/*
> + * HW spec says that 512Bytes in Burst read need special treatment.
> + * But it doesn't talk about other multiple of 256Bytes. And couldn't locate
> + * an I2C slave, which supports such a lengthy burst read too for
> experiments.
> + *
> + * So until things get clarified on HW support, to avoid the burst read
[Intel-gfx] [PATCH 3/5] drm/i915: Add basic immutable zpos properties for all planes
From: Ville Syrjälä
Add an immutable zpos property for all planes. The normal order
is (bottom to top): primary,sprite(s),cursor.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 10 --
drivers/gpu/drm/i915/intel_sprite.c | 5 -
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d4c9e249c44..bc3de1b5bb89 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13447,7 +13447,7 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
unsigned int supported_rotations;
unsigned int num_formats;
const uint64_t *modifiers;
- int ret;
+ int ret, zpos;
primary = kzalloc(sizeof(*primary), GFP_KERNEL);
if (!primary) {
@@ -13591,6 +13591,9 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
DRM_COLOR_YCBCR_BT709,
DRM_COLOR_YCBCR_LIMITED_RANGE);
+ zpos = 0;
+ drm_plane_create_zpos_immutable_property(&primary->base, zpos);
+
drm_plane_helper_add(&primary->base, &intel_plane_helper_funcs);
return primary;
@@ -13608,7 +13611,7 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
{
struct intel_plane *cursor = NULL;
struct intel_plane_state *state = NULL;
- int ret;
+ int ret, zpos;
cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
if (!cursor) {
@@ -13665,6 +13668,9 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
DRM_MODE_ROTATE_0 |
DRM_MODE_ROTATE_180);
+ zpos = INTEL_INFO(dev_priv)->num_sprites[pipe] + 1;
+ drm_plane_create_zpos_immutable_property(&cursor->base, zpos);
+
if (INTEL_GEN(dev_priv) >= 9)
state->scaler_id = -1;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index f6be9b1b9c3a..a6f4524adff4 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1421,7 +1421,7 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
const uint64_t *modifiers;
unsigned int supported_rotations;
int num_plane_formats;
- int ret;
+ int ret, zpos;
intel_plane = kzalloc(sizeof(*intel_plane), GFP_KERNEL);
if (!intel_plane) {
@@ -1552,6 +1552,9 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
DRM_COLOR_YCBCR_BT709,
DRM_COLOR_YCBCR_LIMITED_RANGE);
+ zpos = plane + 1;
+ drm_plane_create_zpos_immutable_property(&intel_plane->base, zpos);
+
drm_plane_helper_add(&intel_plane->base, &intel_plane_helper_funcs);
return intel_plane;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Fix sprite destination colorkeying on SKL+
From: Ville Syrjälä
On SKL+ the dst colorkey must be configured on the lower
plane that contains the colorkey. This is in contrast to
most earlier platforms where the dst colorkey is configured
on the plane above.
The hardware will peform dst keying only between two immediately
adjacent (in zorder) planes. Plane 1 will be keyed against plane 0,
plane 2 againts plane 1, and so on. There is no way to key arbitrary
planes against plane 0. Thus offering dst color keying on plane 2+
is pointless. In fact it can be harmful since enabling dst keying on
more than one plane on the same pipe leads to only the top-most of
the planes performing the keying. For any plane lower in zorder the
dst key enable is simply ignored.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 63 +++--
1 file changed, 60 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index ee23613f9fd4..6164c2ca20c3 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1071,6 +1071,36 @@ intel_check_sprite_plane(struct intel_plane *plane,
return 0;
}
+static bool has_dst_key_in_primary_plane(struct drm_i915_private *dev_priv)
+{
+ return INTEL_GEN(dev_priv) >= 9;
+}
+
+static void intel_plane_set_ckey(struct intel_plane_state *plane_state,
+const struct drm_intel_sprite_colorkey *set)
+{
+ struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
+ struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
+
+ *key = *set;
+
+ /*
+* We want src key enabled on the
+* sprite and not on the primary.
+*/
+ if (plane->id == PLANE_PRIMARY &&
+ set->flags & I915_SET_COLORKEY_SOURCE)
+ key->flags = 0;
+
+ /*
+* On SKL+ we want dst key enabled on
+* the primary and not on the sprite.
+*/
+ if (plane->id != PLANE_PRIMARY &&
+ set->flags & I915_SET_COLORKEY_DESTINATION)
+ key->flags = 0;
+}
+
int intel_sprite_set_colorkey_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
@@ -1100,6 +1130,16 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
if (!plane || plane->type != DRM_PLANE_TYPE_OVERLAY)
return -ENOENT;
+ /*
+* SKL+ only plane 1 can do destination keying against plane 0.
+* Also multiple planes can't do destination keying on the same
+* pipe simultaneously.
+*/
+ if (INTEL_GEN(dev_priv) >= 9 &&
+ to_intel_plane(plane)->id >= PLANE_SPRITE1 &&
+ set->flags & I915_SET_COLORKEY_DESTINATION)
+ return -EINVAL;
+
drm_modeset_acquire_init(&ctx, 0);
state = drm_atomic_state_alloc(plane->dev);
@@ -1112,11 +1152,28 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
while (1) {
plane_state = drm_atomic_get_plane_state(state, plane);
ret = PTR_ERR_OR_ZERO(plane_state);
- if (!ret) {
- to_intel_plane_state(plane_state)->ckey = *set;
- ret = drm_atomic_commit(state);
+ if (!ret)
+ intel_plane_set_ckey(to_intel_plane_state(plane_state),
set);
+
+ /*
+* On some platforms we have to configure
+* the dst colorkey on the primary plane.
+*/
+ if (!ret && has_dst_key_in_primary_plane(dev_priv)) {
+ struct intel_crtc *crtc =
+ intel_get_crtc_for_pipe(dev_priv,
+
to_intel_plane(plane)->pipe);
+
+ plane_state = drm_atomic_get_plane_state(state,
+
crtc->base.primary);
+ ret = PTR_ERR_OR_ZERO(plane_state);
+ if (!ret)
+
intel_plane_set_ckey(to_intel_plane_state(plane_state), set);
}
+ if (!ret)
+ ret = drm_atomic_commit(state);
+
if (ret != -EDEADLK)
break;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Make primary/sprite zpos configurable on VLV/CHV
From: Ville Syrjälä
VLV/CHV can change the z order between the primary and sprite planes
freely. Let's expose that capability by making the zpos property
mutable. The cursor plane is always on top, so the cursor zpos is
left as an immutable property.
The way the hardware is configured is a bit awkward. Both sprite planes
have a "bottom" and "zorder" bits, but the way they interact betweens
the sprites doesn't seem entirely logical. The spec doesn't even list
all 16 possible combinations (just 10 are listed), but I've gone through
them all the discovered the following relationship:
sprite 0sprite 1resulting plane order (bottom to top)
B Z B Z
0 0 0 0 P 0 1 d0(see note),d1,d01,d01p
0 0 0 1 P 0 1 *
0 0 1 0 1 P 0 * d0
0 0 1 1 1 P 0
0 1 0 0 P 1 0 *
0 1 0 1 P 0 1
0 1 1 0 1 0 P * dp
0 1 1 1 1 0 P
1 0 0 0 0 P 1 * d1
1 0 0 1 0 1 P * dp
1 0 1 0 P 0 1
1 0 1 1 P 0 1
1 1 0 0 0 P 1
1 1 0 1 0 1 P
1 1 1 0 P 0 1
1 1 1 1 P 0 1
[B=bottom bit Z=zorder bit, 0=sprite 0, 1=sprite 1, P=primary,
d0=sprite 0 disabled, d1=sprite 1 disabled, dp=primary disabled,
d01=both sprites, d01p=both sprites and primary disabled]
Disabling any one or two planes doesn't seem to interfere with the
resulting plane order in an unexpected way. The bottom and zorder
bits of the disabled planes are still effective though, so we must be
careful what we leave in those bits when the plane is disabled.
What we do for enabled sprite planes is set bottom=1 if the plane is
at the bottom, else we set zorder=1 if the plane is just above
the other sprite plane. This will end up picking the configurations
marked with * from the table when both sprite planes are enabled.
For the disabled plane cases we just leave bottom=0 and zorder=0
for any disabled sprite plane. Any enabled sprite plane will still
follow the rule laid out before. For the purposes of that rule,
we'll consider any disabled plane to be stacked on top of the
enabled planes. This will end up picking the configurations marked
d0 when sprite 0 is disabled, d1 when sprite 1 is disabled,
dp when the primary is disabled, and d01 when both sprites are
disabled (and d01p is actually the same thing with just primary
disabled as well).
The use of the 'P 0 1' configuration for the first d0 case doesn't
really make sense based on the above, but given the way the zorder
bits work, there's no nice way to pick the 'P 1 0' (which would be
the logical thing) when sprite 0 is disabled as that would require
setting the zorder bit in the sprite 0 control register, but as
stated we always set both bits to 0 for disabled planes. That way
we don't have to reconfigure already disabled planes to change the
zorder between the currently active planes, and more imporantly we
don't need to consult any plane/crtc state in the .disable_plane()
hook. This slight irregularity doesn't matter in the end as both
of these configuratios will give us the expected visible 'P 1'
result.
v2: Redo the final zpos computation to not require every plane
on the crtc to be part of the state
v3: More polish
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 8 ++
drivers/gpu/drm/i915/intel_display.c | 146 +-
drivers/gpu/drm/i915/intel_display.h | 9 ++
drivers/gpu/drm/i915/intel_drv.h | 7 ++
drivers/gpu/drm/i915/intel_sprite.c | 24 -
6 files changed, 192 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f238b7b33cd9..44eac5ffc2ce 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6265,6 +6265,8 @@ enum {
#define SP_ROTATE_180(1<<15)
#define SP_TILED (1<<10)
#define SP_MIRROR(1<<8) /* CHV pipe B */
+#define SP_BOTTOM(1<<2)
+#define SP_ZORDER(1<<0)
#define _SPALINOFF (VLV_DISPLAY_BASE + 0x72184)
#define _SPASTRIDE (VLV_DISPLAY_BASE + 0x72188)
#define _SPAPOS(VLV_DISPLAY_BASE + 0x7218c)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 6d068786eb41..a5a3123589e7 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -193,6 +193,14 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
else
crtc_state->nv12_planes &= ~BIT(intel_plane->id);
+
[Intel-gfx] [PATCH 2/5] drm/i915: Fix VLV/CHV sprite src colorkey mask
From: Ville Syrjälä
VLV/CHV sprites use the old plane C layout of the colorkey mask
register. Insted of 8 bit masks for each RGB component in the
lower bits, the register only has the per channel src key enable
bits. On g4x+ sprites those bits are 24,25,26 whereas on the
old plane C and VLV/CHV sprites they are bits 0,1,2. Since
userspace assumes the g4x+ layout let's just shift enable
bits down and ignore the full masks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 6164c2ca20c3..f6be9b1b9c3a 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -548,7 +548,7 @@ vlv_update_plane(struct intel_plane *plane,
if (key->flags) {
I915_WRITE_FW(SPKEYMINVAL(pipe, plane_id), key->min_value);
I915_WRITE_FW(SPKEYMAXVAL(pipe, plane_id), key->max_value);
- I915_WRITE_FW(SPKEYMSK(pipe, plane_id), key->channel_mask);
+ I915_WRITE_FW(SPKEYMSK(pipe, plane_id), key->channel_mask >>
24);
}
I915_WRITE_FW(SPSTRIDE(pipe, plane_id), fb->pitches[0]);
I915_WRITE_FW(SPPOS(pipe, plane_id), (crtc_y << 16) | crtc_x);
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Implement dst colorkeying for VLV/CHV sprites
From: Ville Syrjälä
On VLV/CHV we can use the "src key window" bit on the primary plane to
implemnt sprite dst colorkeying. This is exactly the same mechanism that
would be used on gen2-4 for sprite C dst colorkeying as well.
The slight complication with this approach is that we have to adjust the
zpos of the planes since we're still technically doing src color keying
on the primary, hence the primary must sit above the sprites. But since
we now have working zpos controls on VLV/CHV we can do this pretty
easily.
Working dst colorkeying makes for a much nicer sprite Xv experience.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 +++-
drivers/gpu/drm/i915/intel_atomic_plane.c | 3 ++
drivers/gpu/drm/i915/intel_display.c | 89 +--
drivers/gpu/drm/i915/intel_drv.h | 3 ++
drivers/gpu/drm/i915/intel_sprite.c | 21 +---
5 files changed, 113 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 44eac5ffc2ce..07ec95906869 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6000,8 +6000,8 @@ enum {
#define DISPPLANE_SEL_PIPE_SHIFT 24
#define DISPPLANE_SEL_PIPE_MASK (3id] =
intel_plane_raw_zpos(crtc_state, intel_state);
+ crtc_state->raw_dst_colorkey[intel_plane->id] =
+ intel_state->base.visible &&
+ intel_state->ckey.flags & I915_SET_COLORKEY_DESTINATION;
return intel_plane_atomic_calc_changes(old_crtc_state,
&crtc_state->base,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 111cb0c1da54..b9a85bfe5d69 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3314,6 +3314,7 @@ static void i9xx_update_plane(struct intel_plane *plane,
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
+ const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
u32 linear_offset;
u32 dspcntr = plane_state->ctl;
i915_reg_t reg = DSPCNTR(i9xx_plane);
@@ -3329,8 +3330,17 @@ static void i9xx_update_plane(struct intel_plane *plane,
else
dspaddr_offset = linear_offset;
+ if (crtc_state->dst_colorkey[plane->id])
+ dspcntr |= DISPPLANE_SRC_KEY_ENABLE |
+ DISPPLANE_SRC_KEY_WINDOW_ENABLE;
+
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+ if (crtc_state->dst_colorkey[plane->id]) {
+ I915_WRITE_FW(DSPKEYVAL(i9xx_plane), key->min_value);
+ I915_WRITE_FW(DSPKEYMSK(i9xx_plane), key->channel_mask);
+ }
+
if (INTEL_GEN(dev_priv) < 4) {
/* pipesrc and dspsize control the size that is scaled from,
* which should always be the user's requested size.
@@ -10936,6 +10946,7 @@ clear_intel_crtc_state(struct intel_crtc_state
*crtc_state)
struct intel_shared_dpll *shared_dpll;
struct intel_crtc_wm_state wm_state;
u8 raw_zpos[I915_MAX_PLANES];
+ u8 raw_dst_colorkey[I915_MAX_PLANES];
bool force_thru, ips_force_disable;
/* FIXME: before the switch to atomic started, a new pipe_config was
@@ -10952,6 +10963,7 @@ clear_intel_crtc_state(struct intel_crtc_state
*crtc_state)
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
wm_state = crtc_state->wm;
memcpy(raw_zpos, crtc_state->raw_zpos, sizeof(raw_zpos));
+ memcpy(raw_dst_colorkey, crtc_state->raw_dst_colorkey,
sizeof(raw_dst_colorkey));
/* Keep base drm_crtc_state intact, only clear our extended struct */
BUILD_BUG_ON(offsetof(struct intel_crtc_state, base));
@@ -10967,6 +10979,7 @@ clear_intel_crtc_state(struct intel_crtc_state
*crtc_state)
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
crtc_state->wm = wm_state;
memcpy(crtc_state->raw_zpos, raw_zpos, sizeof(raw_zpos));
+ memcpy(crtc_state->raw_dst_colorkey, raw_dst_colorkey,
sizeof(raw_dst_colorkey));
}
static int
@@ -12242,6 +12255,55 @@ static void vlv_normalize_zpos(struct intel_crtc_state
*crtc_state)
}
}
+static int vlv_fixup_colorkey_zpos(struct intel_crtc_state *crtc_state)
+{
+ /* disable dst colorkey if the primary is above the sprite */
+ crtc_state->dst_colorkey[PLANE_SPRITE0] =
+ crtc_state->raw_dst_colorkey[PLANE_SPRITE0] &&
+ crtc_state->zpos[PLANE_SPRITE0] >
crtc_state->zpos[PLANE_PRIMARY];
+
+ crtc_state->dst_colorkey[PLANE_SPRITE1] =
+ crtc_state->raw_dst_colorkey[PLANE_SPRITE1] &&
+ crtc_state->zpos[PLANE_SPRITE1] >
crtc_state
[Intel-gfx] [PATCH xf86-video-intel 1/8] Remove duplicate exa_wm_yuv_rgb.g5a shader source
From: Ville Syrjälä
exa_wm_yuv_rgb.g5a is identical to exa_wm_yuv_rgb.g4a. Just use a
symlink intead of duplicating the whole file.
Signed-off-by: Ville Syrjälä
---
src/render_program/exa_wm_yuv_rgb.g5a | 99 +--
1 file changed, 1 insertion(+), 98 deletions(-)
mode change 100644 => 12 src/render_program/exa_wm_yuv_rgb.g5a
diff --git a/src/render_program/exa_wm_yuv_rgb.g5a
b/src/render_program/exa_wm_yuv_rgb.g5a
deleted file mode 100644
index 4fb2576ab5f9..
--- a/src/render_program/exa_wm_yuv_rgb.g5a
+++ /dev/null
@@ -1,98 +0,0 @@
-/*
- * Copyright © 2006 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- * Authors:
- *Keith Packard
- *Eric Anholt
- *
- */
-
-include(`exa_wm.g4i')
-
-define(`YCbCr_base', `src_sample_base')
-
-define(`Cr', `src_sample_r')
-define(`Cr_01',`src_sample_r_01')
-define(`Cr_23',`src_sample_r_23')
-
-define(`Y',`src_sample_g')
-define(`Y_01', `src_sample_g_01')
-define(`Y_23', `src_sample_g_23')
-
-define(`Cb', `src_sample_b')
-define(`Cb_01',`src_sample_b_01')
-define(`Cb_23',`src_sample_b_23')
-
-define(`Crn', `mask_sample_r')
-define(`Crn_01', `mask_sample_r_01')
-define(`Crn_23', `mask_sample_r_23')
-
-define(`Yn', `mask_sample_g')
-define(`Yn_01',`mask_sample_g_01')
-define(`Yn_23',`mask_sample_g_23')
-
-define(`Cbn', `mask_sample_b')
-define(`Cbn_01', `mask_sample_b_01')
-define(`Cbn_23', `mask_sample_b_23')
-
-/* color space conversion function:
- * R = Clamp ( 1.164(Y-16/255) + 1.596(Cr-128/255), 0, 1)
- * G = Clamp ( 1.164(Y-16/255) - 0.813(Cr-128/255) - 0.392(Cb-128/255), 0,
1)
- * B = Clamp ( 1.164(Y-16/255) + 2.017(Cb-128/255), 0, 1)
- */
-
-/* Normalize Y, Cb and Cr:
- *
- * Yn = (Y - 16/255) * 1.164
- * Crn = Cr - 128 / 255
- * Cbn = Cb - 128 / 255
- */
-add (16)Yn<1>F Y<8,8,1>F -0.0627451F { compr align1 };
-mul (16)Yn<1>F Yn<8,8,1>F 1.164F { compr align1 };
-
-add (16)Crn<1>FCr<8,8,1>F -0.501961F { compr align1 };
-
-add (16)Cbn<1>FCb<8,8,1>F -0.501961F { compr align1 };
-
-/*
- * R = Y + Cr * 1.596
- */
-mov (16)acc0<1>F Yn<8,8,1>F { compr align1 };
-mac.sat(16) src_sample_r<1>F Crn<8,8,1>F 1.596F { compr align1 };
-
-/*
- * G = Crn * -0.813 + Cbn * -0.392 + Y
- */
-mov (16)acc0<1>F Yn<8,8,1>F { compr align1 };
-mac (16)acc0<1>F Crn<8,8,1>F -0.813F { compr align1 };
-mac.sat(16) src_sample_g<1>F Cbn<8,8,1>F -0.392F { compr align1 };
-
-/*
- * B = Cbn * 2.017 + Y
- */
-mov (16)acc0<1>F Yn<8,8,1>F { compr align1 };
-mac.sat(16) src_sample_b<1>F Cbn<8,8,1>F 2.017F { compr align1 };
-
-/*
- * A = 1.0
- */
-mov (16)src_sample_a<1>F 1.0F{ compr align1 };
diff --git a/src/render_program/exa_wm_yuv_rgb.g5a
b/src/render_program/exa_wm_yuv_rgb.g5a
new file mode 12
index ..d34d246d5a9b
--- /dev/null
+++ b/src/render_program/exa_wm_yuv_rgb.g5a
@@ -0,0 +1 @@
+exa_wm_yuv_rgb.g4a
\ No newline at end of file
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 5/8] sna/video/sprite: Query planes for RGB565
From: Ville Syrjälä
Not all sprite planes support RGB565. Insrtead of hardcoding which
platforms have it let's ask the kernel instead.
Signed-off-by: Ville Syrjälä
---
src/sna/sna.h | 1 +
src/sna/sna_display.c | 76 ++
src/sna/sna_video_sprite.c | 2 +-
3 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/src/sna/sna.h b/src/sna/sna.h
index 6fe1f0d252e6..496460ca6a84 100644
--- a/src/sna/sna.h
+++ b/src/sna/sna.h
@@ -636,6 +636,7 @@ extern bool sna_crtc_set_sprite_rotation(xf86CrtcPtr crtc,
unsigned idx, uint32_
extern void sna_crtc_set_sprite_colorspace(xf86CrtcPtr crtc, unsigned idx, int
colorspace);
extern uint32_t sna_crtc_to_sprite(xf86CrtcPtr crtc, unsigned idx);
extern bool sna_crtc_is_transformed(xf86CrtcPtr crtc);
+bool sna_has_sprite_format(struct sna *sna, uint32_t format);
#define CRTC_VBLANK 0x7
#define CRTC_ON 0x8000
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 66a941ae7301..96e7b1bc50d3 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -3560,6 +3560,82 @@ sna_crtc_find_planes(struct sna *sna, struct sna_crtc
*crtc)
free(planes);
}
+static bool plane_has_format(const uint32_t formats[],
+int count_formats,
+uint32_t format)
+{
+ int i;
+
+ for (i = 0; i < count_formats; i++) {
+ if (formats[i] == format)
+ return true;
+ }
+
+ return false;
+}
+
+bool sna_has_sprite_format(struct sna *sna, uint32_t format)
+{
+ xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(sna->scrn);
+ int i;
+
+ if (sna->mode.num_real_crtc == 0)
+ return false;
+
+ for (i = 0; i < sna->mode.num_real_crtc; i++) {
+ struct sna_crtc *sna_crtc = to_sna_crtc(config->crtc[i]);
+ struct plane *plane;
+
+ list_for_each_entry(plane, &sna_crtc->sprites, link) {
+ struct local_mode_get_plane p;
+ uint32_t *formats;
+ int count_formats;
+ bool has_format;
+
+ VG_CLEAR(p);
+ p.plane_id = plane->id;
+ p.count_format_types = 0;
+ if (drmIoctl(sna->kgem.fd,
+LOCAL_IOCTL_MODE_GETPLANE,
+&p))
+ continue;
+ count_formats = p.count_format_types;
+
+ formats = calloc(count_formats, sizeof(formats[0]));
+ if (!formats)
+ continue;
+
+ p.count_format_types = count_formats;
+ p.format_type_ptr = (uintptr_t)formats;
+ if (drmIoctl(sna->kgem.fd,
+LOCAL_IOCTL_MODE_GETPLANE,
+&p)) {
+ free(formats);
+ continue;
+ }
+
+ assert(p.count_format_types == count_formats);
+
+ has_format = plane_has_format(formats,
+ count_formats,
+ format);
+
+ free(formats);
+
+ /*
+* As long as one plane supports the
+* format we declare it as supported.
+* Not all planes may support it, but
+* then the GPU fallback will kick in.
+*/
+ if (has_format)
+ return true;
+ }
+ }
+
+ return false;
+}
+
static void
sna_crtc_init__rotation(struct sna *sna, struct sna_crtc *crtc)
{
diff --git a/src/sna/sna_video_sprite.c b/src/sna/sna_video_sprite.c
index 56391aa6f581..a4f3205b6fc9 100644
--- a/src/sna/sna_video_sprite.c
+++ b/src/sna/sna_video_sprite.c
@@ -754,7 +754,7 @@ void sna_video_sprite_setup(struct sna *sna, ScreenPtr
screen)
adaptor->pAttributes = (XvAttributeRec *)attribs;
adaptor->pImages = (XvImageRec *)images;
adaptor->nImages = 3;
- if (sna->kgem.gen == 071)
+ if (sna_has_sprite_format(sna, DRM_FORMAT_RGB565))
adaptor->nImages = 4;
#if XORG_XV_VERSION < 2
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 6/8] sna/video/sprite: Add NV12 support
From: Ville Syrjälä
Starting from ~KBL planes can do NV12. Let's make use that
capability in the sprite Xv adaptor.
Signed-off-by: Ville Syrjälä
---
src/sna/sna_video_sprite.c | 57 +++---
1 file changed, 49 insertions(+), 8 deletions(-)
diff --git a/src/sna/sna_video_sprite.c b/src/sna/sna_video_sprite.c
index a4f3205b6fc9..f6d6f0b45b6c 100644
--- a/src/sna/sna_video_sprite.c
+++ b/src/sna/sna_video_sprite.c
@@ -46,6 +46,7 @@
#define DRM_FORMAT_XRGB fourcc_code('X', 'R', '2', '4') /* [31:0]
x:R:G:B 8:8:8:8 little endian */
#define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /* [31:0]
Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_UYVY fourcc_code('U', 'Y', 'V', 'Y') /* [31:0]
Y1:Cr0:Y0:Cb0 8:8:8:8 little endian */
+#define DRM_FORMAT_NV12 fourcc_code('N', 'V', '1', '2') /* 2x2
subsampled Cr:Cb plane */
#define has_hw_scaling(sna, video) ((sna)->kgem.gen < 071 || \
((sna)->kgem.gen >= 0110 &&
(video)->AlwaysOnTop))
@@ -72,7 +73,12 @@ struct local_mode_set_plane {
static Atom xvColorKey, xvAlwaysOnTop, xvSyncToVblank, xvColorspace;
static XvFormatRec formats[] = { {15}, {16}, {24} };
-static const XvImageRec images[] = { XVIMAGE_YUY2, XVIMAGE_UYVY, XVMC_RGB888,
XVMC_RGB565 };
+static const XvImageRec images[] = { XVIMAGE_YUY2, XVIMAGE_UYVY,
+XVMC_RGB888 };
+static const XvImageRec images_rgb565[] = { XVIMAGE_YUY2, XVIMAGE_UYVY,
+ XVMC_RGB888, XVMC_RGB565 };
+static const XvImageRec images_nv12[] = { XVIMAGE_YUY2, XVIMAGE_UYVY,
+ XVIMAGE_NV12, XVMC_RGB888,
XVMC_RGB565 };
static const XvAttributeRec attribs[] = {
{ XvSettable | XvGettable, 0, 1, (char *)"XV_COLORSPACE" }, /* BT.601,
BT.709 */
{ XvSettable | XvGettable, 0, 0xff, (char *)"XV_COLORKEY" },
@@ -307,8 +313,6 @@ sna_video_sprite_show(struct sna *sna,
f.width = frame->width;
f.height = frame->height;
f.flags = 1 << 1; /* +modifiers */
- f.handles[0] = frame->bo->handle;
- f.pitches[0] = frame->pitch[0];
switch (frame->bo->tiling) {
case I915_TILING_NONE:
@@ -323,6 +327,18 @@ sna_video_sprite_show(struct sna *sna,
break;
}
+ if (is_nv12_fourcc(frame->id)) {
+ f.handles[0] = frame->bo->handle;
+ f.handles[1] = frame->bo->handle;
+ f.pitches[0] = frame->pitch[1];
+ f.pitches[1] = frame->pitch[0];
+ f.offsets[0] = 0;
+ f.offsets[1] = frame->UBufOffset;
+ } else {
+ f.handles[0] = frame->bo->handle;
+ f.pitches[0] = frame->pitch[0];
+ }
+
switch (frame->id) {
case FOURCC_RGB565:
f.pixel_format = DRM_FORMAT_RGB565;
@@ -332,6 +348,9 @@ sna_video_sprite_show(struct sna *sna,
f.pixel_format = DRM_FORMAT_XRGB;
purged = sna->scrn->depth != 24;
break;
+ case FOURCC_NV12:
+ f.pixel_format = DRM_FORMAT_NV12;
+ break;
case FOURCC_UYVY:
f.pixel_format = DRM_FORMAT_UYVY;
break;
@@ -633,7 +652,7 @@ static int
sna_video_sprite_query(ddQueryImageAttributes_ARGS)
{
struct sna_video *video = port->devPriv.ptr;
struct sna_video_frame frame;
- int size;
+ int size, tmp;
if (*w > video->sna->mode.max_crtc_width)
*w = video->sna->mode.max_crtc_width;
@@ -654,6 +673,21 @@ static int
sna_video_sprite_query(ddQueryImageAttributes_ARGS)
size = 4;
break;
+ case FOURCC_NV12:
+ *h = (*h + 1) & ~1;
+ size = (*w + 3) & ~3;
+ if (pitches)
+ pitches[0] = size;
+ size *= *h;
+ if (offsets)
+ offsets[1] = size;
+ tmp = (*w + 3) & ~3;
+ if (pitches)
+ pitches[1] = tmp;
+ tmp *= (*h >> 1);
+ size += tmp;
+ break;
+
default:
*w = (*w + 1) & ~1;
*h = (*h + 1) & ~1;
@@ -752,10 +786,17 @@ void sna_video_sprite_setup(struct sna *sna, ScreenPtr
screen)
ARRAY_SIZE(formats));
adaptor->nAttributes = ARRAY_SIZE(attribs);
adaptor->pAttributes = (XvAttributeRec *)attribs;
- adaptor->pImages = (XvImageRec *)images;
- adaptor->nImages = 3;
- if (sna_has_sprite_format(sna, DRM_FORMAT_RGB565))
-
[Intel-gfx] [PATCH xf86-video-intel 3/8] sna/video: Add XV_COLORSPACE attribute for the textured Xv adaptor
From: Ville Syrjälä Allow the client to select between BT.601 and BT.709 via the XV_COLORSPACE port attribute with the textured Xv adaptor as well. Since the BT.601 coefficients are currently hardcoded in the yuv->rgb shader, let's just add a mostly duplicated shader with hardcoded BT.709 coefficients instead. Not the most elegant solution but avoids having to touch any state setup etc. Signed-off-by: Ville Syrjälä --- src/render_program/Makefile.am | 11 +++ src/render_program/exa_wm_yuv_rgb_bt601.g4a | 32 -- src/render_program/exa_wm_yuv_rgb_bt601.g8a | 31 -- src/render_program/exa_wm_yuv_rgb_bt709.g4a | 111 + src/render_program/exa_wm_yuv_rgb_bt709.g4b | 12 +++ src/render_program/exa_wm_yuv_rgb_bt709.g4b.gen5 | 12 +++ src/render_program/exa_wm_yuv_rgb_bt709.g5a | 1 + src/render_program/exa_wm_yuv_rgb_bt709.g5b | 12 +++ src/render_program/exa_wm_yuv_rgb_bt709.g6a | 1 + src/render_program/exa_wm_yuv_rgb_bt709.g6b | 12 +++ src/render_program/exa_wm_yuv_rgb_bt709.g7a | 1 + src/render_program/exa_wm_yuv_rgb_bt709.g7b | 12 +++ src/render_program/exa_wm_yuv_rgb_bt709.g8a | 118 +++ src/render_program/exa_wm_yuv_rgb_bt709.g8b | 19 src/sna/gen4_render.c| 67 +++-- src/sna/gen4_render.h| 11 ++- src/sna/gen5_render.c| 67 +++-- src/sna/gen5_render.h| 11 ++- src/sna/gen6_render.c| 67 ++--- src/sna/gen7_render.c| 53 +++--- src/sna/gen8_render.c| 53 +++--- src/sna/gen9_render.c| 53 +++--- src/sna/sna_render.h | 44 ++--- src/sna/sna_video_textured.c | 12 ++- 24 files changed, 724 insertions(+), 99 deletions(-) create mode 100644 src/render_program/exa_wm_yuv_rgb_bt709.g4a create mode 100644 src/render_program/exa_wm_yuv_rgb_bt709.g4b create mode 100644 src/render_program/exa_wm_yuv_rgb_bt709.g4b.gen5 create mode 12 src/render_program/exa_wm_yuv_rgb_bt709.g5a create mode 100644 src/render_program/exa_wm_yuv_rgb_bt709.g5b create mode 12 src/render_program/exa_wm_yuv_rgb_bt709.g6a create mode 100644 src/render_program/exa_wm_yuv_rgb_bt709.g6b create mode 12 src/render_program/exa_wm_yuv_rgb_bt709.g7a create mode 100644 src/render_program/exa_wm_yuv_rgb_bt709.g7b create mode 100644 src/render_program/exa_wm_yuv_rgb_bt709.g8a create mode 100644 src/render_program/exa_wm_yuv_rgb_bt709.g8b diff --git a/src/render_program/Makefile.am b/src/render_program/Makefile.am index 4493673435b6..dc58138f356e 100644 --- a/src/render_program/Makefile.am +++ b/src/render_program/Makefile.am @@ -16,6 +16,7 @@ INTEL_G4A = \ exa_wm_ca_srcalpha.g4a \ exa_wm_write.g4a\ exa_wm_yuv_rgb_bt601.g4a\ + exa_wm_yuv_rgb_bt709.g4a\ exa_wm_xy.g4a \ $(NULL) @@ -46,6 +47,7 @@ INTEL_G4B = \ exa_wm_ca_srcalpha.g4b \ exa_wm_write.g4b\ exa_wm_yuv_rgb_bt601.g4b\ + exa_wm_yuv_rgb_bt709.g4b\ exa_wm_xy.g4b \ $(NULL) @@ -68,6 +70,7 @@ INTEL_G4B_GEN5 = \ exa_wm_ca_srcalpha.g4b.gen5 \ exa_wm_write.g4b.gen5 \ exa_wm_yuv_rgb_bt601.g4b.gen5 \ + exa_wm_yuv_rgb_bt709.g4b.gen5 \ exa_wm_xy.g4b.gen5 \ $(NULL) @@ -89,6 +92,7 @@ INTEL_G5A = \ exa_wm_ca_srcalpha.g5a \ exa_wm_write.g5a\ exa_wm_yuv_rgb_bt601.g5a\ + exa_wm_yuv_rgb_bt709.g5a\ exa_wm_xy.g5a \ $(NULL) @@ -110,6 +114,7 @@ INTEL_G5B = \ exa_wm_ca_srcalpha.g5b \ exa_wm_write.g5b\ exa_wm_yuv_rgb_bt601.g5b\ + exa_wm_yuv_rgb_bt709.g5b\ exa_wm_xy.g5b \ $(NULL) @@ -134,6 +139,7 @@ INTEL_G6A = \ exa_wm_noca.g6a \ exa_wm_write.g6a\ exa_wm_yuv_rgb_bt601.g6a\ + exa_wm_yuv_rgb_bt709.g6a\ $(NULL) INTEL_G6B =\ @@ -152,6 +158,7 @@ INTEL_G6B = \ exa_wm_noca.g6b \ exa_wm_write.g6b\ exa_wm_yuv_rgb_bt601.g6b\ + exa_wm_yuv_rgb_bt709.g6b\ $(NULL) INTEL_G7A =\ @@ -167,6 +174,7 @@ IN
[Intel-gfx] [PATCH xf86-video-intel 4/8] sna/video/sprite: Add sprite planes in order
From: Ville Syrjälä On SKL+ dst color keying only works between the first sprite and the primary. We probably wante the first Xv port to be the first sprite plane so that the user gets working colorkeying for the port that is most likely to be used first. No way to get dst colorkeying with the other ports :( Signed-off-by: Ville Syrjälä --- src/sna/sna_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c index 62cd3ab5b44c..66a941ae7301 100644 --- a/src/sna/sna_display.c +++ b/src/sna/sna_display.c @@ -3475,7 +3475,7 @@ static void add_sprite_plane(struct sna_crtc *crtc, return; memcpy(sprite, details, sizeof(*sprite)); - list_add(&sprite->link, &crtc->sprites); + list_add_tail(&sprite->link, &crtc->sprites); } static void -- 2.16.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 2/8] Rename current yuv->rgb shader sources to exa_wm_yuv_rgb_bt601
From: Ville Syrjälä
Our current yuv->rgb shaders follow the BT.601 conversion formula.
Rename the shader sources to indicate that fact.
Signed-off-by: Ville Syrjälä
---
src/render_program/Makefile.am | 22 +++---
src/render_program/exa_wm_yuv_rgb.g5a | 1 -
src/render_program/exa_wm_yuv_rgb.g6a | 1 -
src/render_program/exa_wm_yuv_rgb.g7a | 1 -
...exa_wm_yuv_rgb.g4a => exa_wm_yuv_rgb_bt601.g4a} | 0
...exa_wm_yuv_rgb.g4b => exa_wm_yuv_rgb_bt601.g4b} | 0
..._rgb.g4b.gen5 => exa_wm_yuv_rgb_bt601.g4b.gen5} | 0
src/render_program/exa_wm_yuv_rgb_bt601.g5a| 1 +
...exa_wm_yuv_rgb.g5b => exa_wm_yuv_rgb_bt601.g5b} | 0
src/render_program/exa_wm_yuv_rgb_bt601.g6a| 1 +
...exa_wm_yuv_rgb.g6b => exa_wm_yuv_rgb_bt601.g6b} | 0
src/render_program/exa_wm_yuv_rgb_bt601.g7a| 1 +
...exa_wm_yuv_rgb.g7b => exa_wm_yuv_rgb_bt601.g7b} | 0
...exa_wm_yuv_rgb.g8a => exa_wm_yuv_rgb_bt601.g8a} | 0
...exa_wm_yuv_rgb.g8b => exa_wm_yuv_rgb_bt601.g8b} | 0
src/sna/brw/brw_test_gen4.c| 4 ++--
src/sna/brw/brw_test_gen5.c| 4 ++--
src/sna/brw/brw_test_gen6.c| 4 ++--
src/sna/brw/brw_test_gen7.c| 4 ++--
src/sna/gen4_render.c | 6 +++---
src/sna/gen5_render.c | 6 +++---
src/sna/gen6_render.c | 6 +++---
src/sna/gen7_render.c | 6 +++---
src/sna/gen8_render.c | 6 +++---
src/sna/gen9_render.c | 6 +++---
src/uxa/i965_video.c | 16
26 files changed, 48 insertions(+), 48 deletions(-)
delete mode 12 src/render_program/exa_wm_yuv_rgb.g5a
delete mode 12 src/render_program/exa_wm_yuv_rgb.g6a
delete mode 12 src/render_program/exa_wm_yuv_rgb.g7a
rename src/render_program/{exa_wm_yuv_rgb.g4a => exa_wm_yuv_rgb_bt601.g4a}
(100%)
rename src/render_program/{exa_wm_yuv_rgb.g4b => exa_wm_yuv_rgb_bt601.g4b}
(100%)
rename src/render_program/{exa_wm_yuv_rgb.g4b.gen5 =>
exa_wm_yuv_rgb_bt601.g4b.gen5} (100%)
create mode 12 src/render_program/exa_wm_yuv_rgb_bt601.g5a
rename src/render_program/{exa_wm_yuv_rgb.g5b => exa_wm_yuv_rgb_bt601.g5b}
(100%)
create mode 12 src/render_program/exa_wm_yuv_rgb_bt601.g6a
rename src/render_program/{exa_wm_yuv_rgb.g6b => exa_wm_yuv_rgb_bt601.g6b}
(100%)
create mode 12 src/render_program/exa_wm_yuv_rgb_bt601.g7a
rename src/render_program/{exa_wm_yuv_rgb.g7b => exa_wm_yuv_rgb_bt601.g7b}
(100%)
rename src/render_program/{exa_wm_yuv_rgb.g8a => exa_wm_yuv_rgb_bt601.g8a}
(100%)
rename src/render_program/{exa_wm_yuv_rgb.g8b => exa_wm_yuv_rgb_bt601.g8b}
(100%)
diff --git a/src/render_program/Makefile.am b/src/render_program/Makefile.am
index 7b835e1a3fde..4493673435b6 100644
--- a/src/render_program/Makefile.am
+++ b/src/render_program/Makefile.am
@@ -15,7 +15,7 @@ INTEL_G4A = \
exa_wm_ca.g4a \
exa_wm_ca_srcalpha.g4a \
exa_wm_write.g4a\
- exa_wm_yuv_rgb.g4a \
+ exa_wm_yuv_rgb_bt601.g4a\
exa_wm_xy.g4a \
$(NULL)
@@ -45,7 +45,7 @@ INTEL_G4B = \
exa_wm_ca.g4b \
exa_wm_ca_srcalpha.g4b \
exa_wm_write.g4b\
- exa_wm_yuv_rgb.g4b \
+ exa_wm_yuv_rgb_bt601.g4b\
exa_wm_xy.g4b \
$(NULL)
@@ -67,7 +67,7 @@ INTEL_G4B_GEN5 = \
exa_wm_ca.g4b.gen5 \
exa_wm_ca_srcalpha.g4b.gen5 \
exa_wm_write.g4b.gen5 \
- exa_wm_yuv_rgb.g4b.gen5 \
+ exa_wm_yuv_rgb_bt601.g4b.gen5 \
exa_wm_xy.g4b.gen5 \
$(NULL)
@@ -88,7 +88,7 @@ INTEL_G5A = \
exa_wm_ca.g5a \
exa_wm_ca_srcalpha.g5a \
exa_wm_write.g5a\
- exa_wm_yuv_rgb.g5a \
+ exa_wm_yuv_rgb_bt601.g5a\
exa_wm_xy.g5a \
$(NULL)
@@ -109,7 +109,7 @@ INTEL_G5B = \
exa_wm_ca.g5b \
exa_wm_ca_srcalpha.g5b \
exa_wm_write.g5b\
- exa_wm_yuv_rgb.g5b \
+ exa_wm_yuv_rgb_bt601.g5b\
exa_wm_xy.g5b \
$(NULL)
@@ -133,7 +133,7 @@ INTEL_G6A = \
exa_wm_ca_srcalpha.g6a \
exa_wm_noca.g6a \
exa_wm_write.g6a\
- exa_wm_yuv_rgb.g6a \
+
[Intel-gfx] [PATCH xf86-video-intel 8/8] sna/video/sprite: Try disabling plane before giving up on colorkey
From: Ville Syrjälä
When we're trying to reinstate the colorkey we might fail on account of
the plane still being enable with a configuration that prevent the
use of colorkey. This happens easily with NV12 since the plane scaler
required by even unscaled NV12 is not compatible with colorkey.
To work around the problem let's try disabling the plane first, then
re-enable the colorkey, and finally we will try to re-enable the plane.
The plane re-enable may fail, in which case we'll head to the GPU
scaling fallback path. The cost is a flash of the colorkey when the
plane blink off and then back on.
Help me atomic ioctl, you're my only hope!
Signed-off-by: Ville Syrjälä
---
src/sna/sna_video_sprite.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/sna/sna_video_sprite.c b/src/sna/sna_video_sprite.c
index 0f52f0328fc0..f713abcb9151 100644
--- a/src/sna/sna_video_sprite.c
+++ b/src/sna/sna_video_sprite.c
@@ -270,9 +270,19 @@ sna_video_sprite_show(struct sna *sna,
if (drmIoctl(sna->kgem.fd,
LOCAL_IOCTL_I915_SET_SPRITE_COLORKEY,
&set)) {
- xf86DrvMsg(sna->scrn->scrnIndex, X_ERROR,
- "failed to update color key, disabling
future updates\n");
- video->has_color_key = false;
+ memset(&s, 0, sizeof(s));
+ s.plane_id = sna_crtc_to_sprite(crtc, video->idx);
+
+ /* try to disable the plane first */
+ if (drmIoctl(video->sna->kgem.fd,
LOCAL_IOCTL_MODE_SETPLANE, &s))
+ xf86DrvMsg(video->sna->scrn->scrnIndex, X_ERROR,
+ "failed to disable plane\n");
+
+ if (drmIoctl(sna->kgem.fd,
LOCAL_IOCTL_I915_SET_SPRITE_COLORKEY, &set)) {
+ xf86DrvMsg(sna->scrn->scrnIndex, X_ERROR,
+ "failed to update color key,
disabling future updates\n");
+ video->has_color_key = false;
+ }
}
video->color_key_changed &= ~(1 << pipe);
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 7/8] sna/video/sprite: Make NV12 take the GPU scaling fallback
From: Ville Syrjälä
Even unscaled NV12 needs the plane scaler on SKL+, so when
unscaled NV12 setplane fails we should still take the GPU
scaling fallback path.
Signed-off-by: Ville Syrjälä
---
src/sna/sna_video_sprite.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/sna/sna_video_sprite.c b/src/sna/sna_video_sprite.c
index f6d6f0b45b6c..0f52f0328fc0 100644
--- a/src/sna/sna_video_sprite.c
+++ b/src/sna/sna_video_sprite.c
@@ -415,6 +415,15 @@ sna_video_sprite_show(struct sna *sna,
return true;
}
+static bool need_scaling(const struct sna_video_frame *frame,
+const BoxRec *dst)
+{
+ /* SKL+ need the plane scaler even for unscaled NV12 */
+ return frame->id == FOURCC_NV12 ||
+ frame->src.x2 - frame->src.x1 != dst->x2 - dst->x1 ||
+ frame->src.y2 - frame->src.y1 != dst->y2 - dst->y1;
+}
+
static int sna_video_sprite_put_image(ddPutImage_ARGS)
{
struct sna_video *video = port->devPriv.ptr;
@@ -562,8 +571,7 @@ off:
}
if (!hw_scaling && sna->render.video &&
- !((frame.src.x2 - frame.src.x1) == (dst.x2 - dst.x1) &&
- (frame.src.y2 - frame.src.y1) == (dst.y2 - dst.y1))) {
+ need_scaling(&frame, &dst)) {
ScreenPtr screen = to_screen_from_sna(sna);
PixmapPtr scaled;
RegionRec r;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+
== Series Details == Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+ URL : https://patchwork.freedesktop.org/series/43902/ State : warning == Summary == $ dim checkpatch origin/drm-tip ab49b9e98274 drm/i915: Fix sprite destination colorkeying on SKL+ b08400aa9188 drm/i915: Fix VLV/CHV sprite src colorkey mask c99414ba31cf drm/i915: Add basic immutable zpos properties for all planes 0a5bc4c8cb26 drm/i915: Make primary/sprite zpos configurable on VLV/CHV -:90: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #90: FILE: drivers/gpu/drm/i915/i915_reg.h:6268: +#define SP_BOTTOM(1<<2) ^ -:91: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #91: FILE: drivers/gpu/drm/i915/i915_reg.h:6269: +#define SP_ZORDER(1<<0) ^ -:336: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__state' - possible side-effects? #336: FILE: drivers/gpu/drm/i915/intel_display.h:336: +#define for_each_oldnew_intel_crtc_in_state(__state, crtc, old_crtc_state, new_crtc_state, __i) \ + for ((__i) = 0; \ +(__i) < (__state)->base.dev->mode_config.num_crtc && \ +((crtc) = to_intel_crtc((__state)->base.crtcs[__i].ptr), \ + (old_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].old_state), \ + (new_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].new_state), 1); \ +(__i)++) \ + for_each_if(crtc) -:336: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'crtc' - possible side-effects? #336: FILE: drivers/gpu/drm/i915/intel_display.h:336: +#define for_each_oldnew_intel_crtc_in_state(__state, crtc, old_crtc_state, new_crtc_state, __i) \ + for ((__i) = 0; \ +(__i) < (__state)->base.dev->mode_config.num_crtc && \ +((crtc) = to_intel_crtc((__state)->base.crtcs[__i].ptr), \ + (old_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].old_state), \ + (new_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].new_state), 1); \ +(__i)++) \ + for_each_if(crtc) -:336: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible side-effects? #336: FILE: drivers/gpu/drm/i915/intel_display.h:336: +#define for_each_oldnew_intel_crtc_in_state(__state, crtc, old_crtc_state, new_crtc_state, __i) \ + for ((__i) = 0; \ +(__i) < (__state)->base.dev->mode_config.num_crtc && \ +((crtc) = to_intel_crtc((__state)->base.crtcs[__i].ptr), \ + (old_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].old_state), \ + (new_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].new_state), 1); \ +(__i)++) \ + for_each_if(crtc) -:340: WARNING:LONG_LINE: line over 100 characters #340: FILE: drivers/gpu/drm/i915/intel_display.h:340: + (old_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].old_state), \ -:341: WARNING:LONG_LINE: line over 100 characters #341: FILE: drivers/gpu/drm/i915/intel_display.h:341: + (new_crtc_state) = to_intel_crtc_state((__state)->base.crtcs[__i].new_state), 1); \ total: 0 errors, 2 warnings, 5 checks, 299 lines checked c844de7ddf13 drm/i915: Implement dst colorkeying for VLV/CHV sprites -:31: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #31: FILE: drivers/gpu/drm/i915/i915_reg.h:6003: +#define DISPPLANE_SRC_KEY_WINDOW_ENABLE (1<<23) /* planes A/B */ ^ total: 0 errors, 0 warnings, 1 checks, 259 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable P010, P012 and P016 formats for GLK/CNL
== Series Details == Series: Enable P010, P012 and P016 formats for GLK/CNL URL : https://patchwork.freedesktop.org/series/43891/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4253_full -> Patchwork_9140_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9140_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9140_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43891/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9140_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP igt@kms_chv_cursor_fail@pipe-a-256x256-bottom-edge: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9140_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_flip@flip-vs-blocking-wf-vblank: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt: shard-glk: PASS -> FAIL (fdo#104724, fdo#103167) Possible fixes igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS igt@kms_cursor_crc@cursor-256x256-suspend: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-hsw: FAIL (fdo#103928) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-y-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS igt@kms_vblank@pipe-b-accuracy-idle: shard-hsw: FAIL (fdo#102583) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4253 -> Patchwork_9140 CI_DRM_4253: d0a3423d398934e94a1924daea934b1578588336 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9140: a4aeab6bd142acc0b0e0043c94006fa898184e0f @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9140/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+
== Series Details == Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+ URL : https://patchwork.freedesktop.org/series/43902/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4254 -> Patchwork_9141 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43902/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9141 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-kbl-7567u: PASS -> DMESG-WARN (fdo#105602) igt@kms_flip@basic-flip-vs-wf_vblank: fi-skl-6770hq: PASS -> FAIL (fdo#103928, fdo#100368) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) fi-glk-j4005: PASS -> FAIL (fdo#104724, fdo#103167) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: DMESG-WARN (fdo#106248) -> PASS igt@gem_exec_fence@await-hang-default: fi-glk-j4005: DMESG-WARN (fdo#105719) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4254 -> Patchwork_9141 CI_DRM_4254: 59d0ee3539be08fb2551cc59719e79305e3115aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9141: c844de7ddf13da9b20987dde73372281747864d0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c844de7ddf13 drm/i915: Implement dst colorkeying for VLV/CHV sprites 0a5bc4c8cb26 drm/i915: Make primary/sprite zpos configurable on VLV/CHV c99414ba31cf drm/i915: Add basic immutable zpos properties for all planes b08400aa9188 drm/i915: Fix VLV/CHV sprite src colorkey mask ab49b9e98274 drm/i915: Fix sprite destination colorkeying on SKL+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9141/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm/i915/icl: WaEnableFloatBlendOptimization
On Tue, May 29, 2018 at 5:47 AM, Lionel Landwerlin
wrote:
> FYI, we're setting this in Mesa :
> https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/vulkan/genX_state.c#n130
> https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_state_upload.c#n67
> I don't think we realized this was a privileged register.
>
No, I didn't.
> Anuj: Maybe we can drop it?
>
Yes, I'll send out patches to remove it from Mesa.
> -
> Lionel
>
>
> On 29/05/18 13:07, Mika Kuoppala wrote:
>>
>> Oscar Mateo writes:
>>
>>> Enables blend optimization for floating point RTs
>>>
>>> v2: Rebased on top of the WA refactoring
>>> v3: Added References (Mika)
>>>
>>> References: HSDES#1406393558
>>> Cc: Mika Kuoppala
>>> Signed-off-by: Oscar Mateo
>>
>> Let's see if we can get away without whitelisting this,
>> Reviewed-by: Mika Kuoppala
>>
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h | 3 +++
>>> drivers/gpu/drm/i915/intel_workarounds.c | 3 +++
>>> 2 files changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index 6e88c6b..f123c3e 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -2663,6 +2663,9 @@ enum i915_power_well_id {
>>> #define GEN8_4x4_STC_OPTIMIZATION_DISABLE (1<<6)
>>> #define GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE (1<<1)
>>> +#define GEN10_CACHE_MODE_SS _MMIO(0xe420)
>>> +#define FLOAT_BLEND_OPTIMIZATION_ENABLE (1 << 4)
>>> +
>>> #define GEN6_BLITTER_ECOSKPD _MMIO(0x221d0)
>>> #define GEN6_BLITTER_LOCK_SHIFT 16
>>> #define GEN6_BLITTER_FBC_NOTIFY (1<<3)
>>> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
>>> b/drivers/gpu/drm/i915/intel_workarounds.c
>>> index 33a1a0c..e9c00b0 100644
>>> --- a/drivers/gpu/drm/i915/intel_workarounds.c
>>> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
>>> @@ -479,6 +479,9 @@ static int icl_ctx_workarounds_init(struct
>>> drm_i915_private *dev_priv)
>>> WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
>>> GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
>>> + /* WaEnableFloatBlendOptimization:icl */
>>> + WA_SET_BIT_MASKED(GEN10_CACHE_MODE_SS,
>>> FLOAT_BLEND_OPTIMIZATION_ENABLE);
>>> +
>>> return 0;
>>> }
>>>
>>> --
>>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 2/8] drm/i915: Record the sseu configuration per-context & engine
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 14 ++
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_gem_context.h | 4
drivers/gpu/drm/i915/i915_request.h | 10 ++
drivers/gpu/drm/i915/intel_lrc.c| 22 +++---
5 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 487922f88b76..62ababfd39aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3427,6 +3427,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)&dev_priv->info;
}
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+ const struct sseu_dev_info *sseu = &INTEL_INFO(i915)->sseu;
+ struct intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 45393f6e0208..ee2ee6b4e5b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -282,6 +282,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = &ctx->__engine[n];
ce->gem_context = ctx;
+ /* Use the whole device by default */
+ ce->sseu = intel_device_default_sseu(dev_priv);
}
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index b116e4942c10..f40d85448a28 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
#include "i915_gem.h"
#include "i915_scheduler.h"
+#include "intel_device_info.h"
struct pid;
@@ -160,6 +161,9 @@ struct i915_gem_context {
int pin_count;
const struct intel_context_ops *ops;
+
+ /** sseu: Control eu/slice partitioning */
+ struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 17a9fa03..82c5dd153bfd 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,16 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 05e069a5c836..8bac0483e784 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2512,8 +2512,8 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu,
+struct intel_sseu ctx_sseu)
{
u32 rpcs = 0;
@@ -2523,24 +2523,23 @@ make_rpcs(struct drm_i915_private *dev_priv)
* must make an explicit request through RPCS for full
* enablement.
*/
- if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+ if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= hweight8(ctx_sseu.slice_mask) <
[Intel-gfx] [PATCH v8 1/8] drm/i915: Program RPCS for Broadwell
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8a6058b4102f..05e069a5c836 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2517,13 +2517,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
{
u32 rpcs = 0;
- /*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
- */
- if (INTEL_GEN(dev_priv) < 9)
- return 0;
-
/*
* Starting in Gen9, render power gating can leave
* slice/subslice/EU in a partially enabled state. We
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 3/8] drm/i915/perf: simplify configure all context function
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4f0eb84b3c00..805dfc732bba 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1762,7 +1762,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
if (ret)
- goto out;
+ return ret;
/*
* The OA register config is setup through the context image. This image
@@ -1779,7 +1779,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
*/
ret = i915_gem_wait_for_idle(dev_priv, wait_flags);
if (ret)
- goto out;
+ return ret;
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
@@ -1791,10 +1791,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
continue;
regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
- if (IS_ERR(regs)) {
- ret = PTR_ERR(regs);
- goto out;
- }
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
@@ -1804,7 +1802,6 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
i915_gem_object_unpin_map(ce->state->obj);
}
- out:
return ret;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 4/8] drm/i915/perf: reuse intel_lrc ctx regs macro
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 805dfc732bba..a5d98bda5c2e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k and 16M, though driver
* is currently generally designed assuming the largest 16M size is used such
@@ -1579,27 +1580,25 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
-(dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
-GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
- for (i = 0; i < ARRAY_SIZE(flex_mmio); i++) {
+ for (i = 0; i < ARRAY_SIZE(flex_regs); i++) {
u32 state_offset = ctx_flexeu0 + i * 2;
- u32 mmio = flex_mmio[i];
+ u32 mmio = i915_mmio_reg_offset(flex_regs[i]);
/*
* This arbitrary default will select the 'EU FPU0 Pipeline
@@ -1619,8 +1618,7 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
}
}
- reg_state[state_offset] = mmio;
- reg_state[state_offset+1] = value;
+ CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 5/8] drm/i915/perf: lock powergating configuration to default when active
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
drivers/gpu/drm/i915/i915_perf.c | 23 ++-
drivers/gpu/drm/i915/intel_lrc.c | 11 +++
drivers/gpu/drm/i915/intel_lrc.h | 3 +++
4 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 62ababfd39aa..25ffadfcd04b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3839,4 +3839,19 @@ static inline int intel_hws_csb_write_index(struct
drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
}
+static inline struct intel_sseu
+intel_engine_prepare_sseu(struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ /*
+* If i915/perf is active, we want a stable powergating configuration
+* on the system. The most natural configuration to take in that case
+* is the default (i.e maximum the hardware can do).
+*/
+ return i915->perf.oa.exclusive_stream ?
+ intel_device_default_sseu(i915) : sseu;
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a5d98bda5c2e..4a62024cbf85 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1574,7 +1574,8 @@ static void hsw_disable_metric_set(struct
drm_i915_private *dev_priv)
*/
static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
u32 *reg_state,
- const struct i915_oa_config
*oa_config)
+ const struct i915_oa_config
*oa_config,
+ struct intel_sseu sseu)
{
struct drm_i915_private *dev_priv = ctx->i915;
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
@@ -1620,6 +1621,9 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(&INTEL_INFO(dev_priv)->sseu, sseu));
}
/*
@@ -1750,6 +1754,7 @@ static int gen8_switch_to_updated_kernel_context(struct
drm_i915_private *dev_pr
static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
const struct i915_oa_config *oa_config)
{
+ struct intel_sseu default_sseu = intel_device_default_sseu(dev_priv);
struct intel_engine_cs *engine = dev_priv->engine[RCS];
struct i915_gem_context *ctx;
int ret;
@@ -1795,7 +1800,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
- gen8_update_reg_state_unlocked(ctx, regs, oa_config);
+ gen8_update_reg_state_unlocked(ctx, regs, oa_config,
+ oa_config ? default_sseu :
ce->sseu);
i915_gem_object_unpin_map(
[Intel-gfx] [PATCH v8 7/8] drm/i915: Expose RPCS (SSEU) configuration to userspace
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
.instance = 0, };
memset(&arg, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) &sseu;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &arg) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &arg);
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
c: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 13 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +
drivers/gpu/drm/i915/i915_gem_context.c | 176
drivers/gpu/drm/i915/i915_request.c | 20 +++
drivers/gpu/drm/i915/intel_lrc.c| 113 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 43 ++
8 files changed, 338 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 25ffadfcd04b..b2386c37437d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2066,6 +2066,12 @@ struct drm_i915_private {
u32 active_requests;
u32 request_serial;
+ /**
+* Global barrier to ensuring ordering of sseu transitions
+* requests.
+*/
+ struct i915_gem_active global_barrier;
+
/**
* Is the GPU currently considered idle, or busy executing
* userspace requests? Whilst idle, we allow runtime power
@@ -3212,6 +3218,13 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
return container_of(vm, struct i915_hw_ppgtt, base);
}
+static inline void i915_gem_set_global_barrier(struct drm_i915_private *i915,
+ struct i915_request *rq)
+{
+ lockdep_assert_held(&i915->drm.struct_mutex);
+ i915_gem_active_set(&i915->gt.global_barrier, rq);
+}
+
/* i915_gem_fence_reg.c */
struct drm_i915_fence_reg *
i915_reserve_fence(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05f44ca35a06..3872e4235258 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -,6 +,8 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
if (!dev_priv->priorities)
goto err_dependencies;
+ init_request_active(&dev_priv->gt.global_barrier, NULL);
+
INIT_LIST_HEAD(&dev_priv->gt.timelines);
INIT_LIST_HEAD(&dev_priv->gt.active_rings);
INIT_LIST_HEAD(&dev_priv->gt.closed_vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ee2ee6b4e5b
[Intel-gfx] [PATCH v8 0/8] drm/i915: per context slice/subslice powergating
Hi all, Another iteration that takes into account : - Tvrtko's nits from v7 on patch 8 - Tvrtko's suggestion not to return EPERM when dynamic sseu is disabled through sysfs. Instead store the requested value and apply it when/if dynamic sseu becomes enabled. - A pretty important fix that prevented the MI_SDRI to be applied. We were writting into a GGTT offset which didn't work (tests have been updated to catch this). To address this, this iteration adds patch 6 that creates a view of the context images into the kernel context's PPGTT so that we can properly modify them from the kernel context. Many thanks to Chris & Tvrtko for review & discussions. Cheers, Chris Wilson (3): drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin (5): drm/i915/perf: simplify configure all context function drm/i915/perf: reuse intel_lrc ctx regs macro drm/i915/perf: lock powergating configuration to default when active drm/i915: create context image vma in kernel context drm/i915: add a sysfs entry to let users set sseu configs drivers/gpu/drm/i915/i915_drv.h | 50 ++ drivers/gpu/drm/i915/i915_gem.c | 2 + drivers/gpu/drm/i915/i915_gem_context.c | 216 drivers/gpu/drm/i915/i915_gem_context.h | 5 + drivers/gpu/drm/i915/i915_perf.c| 68 drivers/gpu/drm/i915/i915_request.c | 20 +++ drivers/gpu/drm/i915/i915_request.h | 10 ++ drivers/gpu/drm/i915/i915_sysfs.c | 40 + drivers/gpu/drm/i915/intel_lrc.c| 146 ++-- drivers/gpu/drm/i915/intel_lrc.h| 3 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + drivers/gpu/drm/i915/intel_ringbuffer.h | 4 + include/uapi/drm/i915_drm.h | 43 + 13 files changed, 530 insertions(+), 79 deletions(-) -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context
We want to be able to modify other context images from the kernel
context in a following commit. To be able to do this we need to map
the context image into the kernel context's ppgtt.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gem_context.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 19 ++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index f40d85448a28..9c313c2edb09 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -155,6 +155,7 @@ struct i915_gem_context {
struct intel_context {
struct i915_gem_context *gem_context;
struct i915_vma *state;
+ struct i915_vma *kernel_state; /**/
struct intel_ring *ring;
u32 *lrc_reg_state;
u64 lrc_desc;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7314e548fb4e..8a49323f6672 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2739,7 +2739,7 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
struct intel_context *ce)
{
struct drm_i915_gem_object *ctx_obj;
- struct i915_vma *vma;
+ struct i915_vma *ggtt_vma, *ppgtt_vma;
uint32_t context_size;
struct intel_ring *ring;
struct i915_timeline *timeline;
@@ -2762,9 +2762,17 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
goto error_deref_obj;
}
- vma = i915_vma_instance(ctx_obj, &ctx->i915->ggtt.base, NULL);
- if (IS_ERR(vma)) {
- ret = PTR_ERR(vma);
+ ggtt_vma = i915_vma_instance(ctx_obj, &ctx->i915->ggtt.base, NULL);
+ if (IS_ERR(ggtt_vma)) {
+ ret = PTR_ERR(ggtt_vma);
+ goto error_deref_obj;
+ }
+
+ ppgtt_vma = i915_vma_instance(ctx_obj,
+ &ctx->i915->kernel_context->ppgtt->base,
+ NULL);
+ if (IS_ERR(ppgtt_vma)) {
+ ret = PTR_ERR(ppgtt_vma);
goto error_deref_obj;
}
@@ -2788,7 +2796,8 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
}
ce->ring = ring;
- ce->state = vma;
+ ce->state = ggtt_vma;
+ ce->kernel_state = ppgtt_vma;
return 0;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 8/8] drm/i915: add a sysfs entry to let users set sseu configs
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
v2: Rename sysfs entry (Tvrtko)
Lock interruptible the device in sysfs (Tvrtko)
Fix dropped error code in getting dynamic sseu value (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
v3: Drop locked function suffix (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 16 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 38 +++
drivers/gpu/drm/i915/i915_sysfs.c | 40 +
3 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b2386c37437d..5aa96a6650b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1842,6 +1842,8 @@ struct drm_i915_private {
struct ida hw_ida;
#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+
+ bool dynamic_sseu;
} contexts;
u32 fdi_rx_config;
@@ -3259,6 +3261,10 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+int i915_gem_contexts_set_dynamic_sseu(struct drm_i915_private *i915,
+ bool allowed);
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915);
+
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
@@ -3859,11 +3865,13 @@ intel_engine_prepare_sseu(struct intel_engine_cs
*engine,
struct drm_i915_private *i915 = engine->i915;
/*
-* If i915/perf is active, we want a stable powergating configuration
-* on the system. The most natural configuration to take in that case
-* is the default (i.e maximum the hardware can do).
+* If i915/perf is active or dynamic sseu configuration is not allowed
+* (through sysfs), we want a stable powergating configuration on the
+* system. The most natural configuration to take in that case is the
+* default (i.e maximum the hardware can do).
*/
- return i915->perf.oa.exclusive_stream ?
+ return (i915->perf.oa.exclusive_stream ||
+ !i915->contexts.dynamic_sseu) ?
intel_device_default_sseu(i915) : sseu;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 79029815c21f..453bdc976be3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1118,6 +1118,44 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
return ret;
}
+int i915_gem_contexts_set_dynamic_sseu(struct drm_i915_private *i915,
+ bool allowed)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+ struct i915_gem_context *ctx;
+ int ret = 0;
+
+ lockdep_assert_held(&i915->drm.struct_mutex);
+
+ if (!engine->emit_rpcs_config)
+ return -ENODEV;
+
+ if (allowed == i915->contexts.dynamic_sseu)
+ return 0;
+
+ i915->contexts.dynamic_sseu = allowed;
+
+ list_for_each_entry(ctx, &i915->contexts.list, link) {
+ struct intel_context *ce = to_intel_context(ctx, engine);
+
+ ret = i915_gem_context_reconfigure_sseu(ctx, engine, ce->sseu);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+
+ if (!engine->emit_rpcs_config)
+ return false;
+
+ return i915->contexts.dynamic_sseu;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_context.c"
#include "selftests/i915_gem_context.c"
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index e5e6f6bb2b05..d895054d245e 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -483,6 +483,44 @@ static ssize_t gt_rp_mhz_show(struct device *kdev, struct
device_attribute *attr
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
+static ssize_t allow_dynamic_sseu_show(struct device *kdev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
+ bool value = i915_gem_contexts_get_dynamic_sseu(i915);
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", value);
+}
+
+static ssize_t allow_dynamic_sseu_store(struct device *kdev,
+
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: per context slice/subslice powergating (rev7)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev7) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim checkpatch origin/drm-tip d23a6b481d4b drm/i915: Program RPCS for Broadwell 6540acb8de8b drm/i915: Record the sseu configuration per-context & engine 503e849565f5 drm/i915/perf: simplify configure all context function dee2b69688ad drm/i915/perf: reuse intel_lrc ctx regs macro 7d7e921f0dda drm/i915/perf: lock powergating configuration to default when active ee4312d23206 drm/i915: create context image vma in kernel context 84fe4b373898 drm/i915: Expose RPCS (SSEU) configuration to userspace -:40: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #40: v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel) total: 0 errors, 1 warnings, 0 checks, 461 lines checked 69235291e987 drm/i915: add a sysfs entry to let users set sseu configs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: per context slice/subslice powergating (rev7)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev7) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Program RPCS for Broadwell Okay! Commit: drm/i915: Record the sseu configuration per-context & engine -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3678:16: warning: expression using sizeof(void) Commit: drm/i915/perf: simplify configure all context function Okay! Commit: drm/i915/perf: reuse intel_lrc ctx regs macro Okay! Commit: drm/i915/perf: lock powergating configuration to default when active Okay! Commit: drm/i915: create context image vma in kernel context Okay! Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace -drivers/gpu/drm/i915/selftests/../i915_drv.h:3678:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3691:16: warning: expression using sizeof(void) Commit: drm/i915: add a sysfs entry to let users set sseu configs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3691:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3697:16: warning: expression using sizeof(void) ___ 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: per context slice/subslice powergating (rev7)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev7) URL : https://patchwork.freedesktop.org/series/42285/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4254 -> Patchwork_9142 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42285/revisions/7/mbox/ == Known issues == Here are the changes found in Patchwork_9142 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL (fdo#100368) igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-glk-j4005: PASS -> FAIL (fdo#103481) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: DMESG-WARN (fdo#106248) -> PASS igt@gem_exec_fence@await-hang-default: fi-glk-j4005: DMESG-WARN (fdo#105719) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4254 -> Patchwork_9142 CI_DRM_4254: 59d0ee3539be08fb2551cc59719e79305e3115aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9142: 69235291e9870310ee5dc401c16b71f4a038c940 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 69235291e987 drm/i915: add a sysfs entry to let users set sseu configs 84fe4b373898 drm/i915: Expose RPCS (SSEU) configuration to userspace ee4312d23206 drm/i915: create context image vma in kernel context 7d7e921f0dda drm/i915/perf: lock powergating configuration to default when active dee2b69688ad drm/i915/perf: reuse intel_lrc ctx regs macro 503e849565f5 drm/i915/perf: simplify configure all context function 6540acb8de8b drm/i915: Record the sseu configuration per-context & engine d23a6b481d4b drm/i915: Program RPCS for Broadwell == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9142/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Set idle frame count based on sink synchronization latency
On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote:
> DPCD 2009h "Synchronization latency in sink" has bits that tell us the
> maximum number of frames sink can take to resynchronize to source timing
> when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum
> number of frames following PSR exit that the Source device needs to
> wait for PSR entry."
>
> We currently use this value only to setup the number frames to wait before
> PSR2 selective update. But, based on the above description it makes more
> sense to use this to configure idle frames for both PSR1 and and PSR2. This
> will ensure we wait the required number of frames before
> activation whether it is PSR1 or PSR2.
>
> The minimum number of idle frames remains 6, while allowing sink
> synchronization latency and VBT to increase this value.
>
> This also solves the flip-flop between sink and source frames that I
> noticed on my Thinkpad X260 during PSR exit. This specific panel has a
> value of 8h, which according to the spec means the "Source device must
> wait for more than eight active frames after PSR exit before initiating PSR
> entry. (In this case, should be provided by the panel supplier.)" VBT
> however has a value of 0.
>
> Cc: Jani Nikula
> Cc: Jose Roberto de Souza
> Cc: Rodrigo Vivi
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/intel_psr.c | 40
>
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index ebc483f06c6f..71dfe541740f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -247,6 +247,8 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> return;
> }
> dev_priv->psr.sink_support = true;
> + dev_priv->psr.sink_sync_latency =
> + intel_dp_get_sink_sync_latency(intel_dp);
>
> if (INTEL_GEN(dev_priv) >= 9 &&
> (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> @@ -272,8 +274,6 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> if (dev_priv->psr.sink_psr2_support) {
> dev_priv->psr.colorimetry_support =
> intel_dp_get_colorimetry_status(intel_dp);
> - dev_priv->psr.sink_sync_latency =
> - intel_dp_get_sink_sync_latency(intel_dp);
> }
> }
> }
> @@ -370,21 +370,21 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct drm_device *dev = dig_port->base.base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> + u32 max_sleep_time = 0x1f;
> + u32 val = EDP_PSR_ENABLE;
>
> - uint32_t max_sleep_time = 0x1f;
> - /*
> - * Let's respect VBT in case VBT asks a higher idle_frame value.
> - * Let's use 6 as the minimum to cover all known cases including
> - * the off-by-one issue that HW has in some cases. Also there are
> - * cases where sink should be able to train
> - * with the 5 or 6 idle patterns.
> + /* Let's use 6 as the minimum to cover all known cases including the
> + * off-by-one issue that HW has in some cases.
>*/
> - uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> - uint32_t val = EDP_PSR_ENABLE;
> + int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>
> - val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> + /* sink_sync_latency of 8 means source has to wait for more than 8
> + * frames, we'll go with 9 frames for now
> + */
> + idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency + 1);
> val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>
> + val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> if (IS_HASWELL(dev_priv))
> val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
>
> @@ -424,15 +424,15 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct drm_device *dev = dig_port->base.base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> - /*
> - * Let's respect VBT in case VBT asks a higher idle_frame value.
> - * Let's use 6 as the minimum to cover all known cases including
> - * the off-by-one issue that HW has in some cases. Also there are
> - * cases where sink should be able to train
> - * with the 5 or 6 idle patterns.
> + u32 val;
> +
> + /* Let's use 6 as the minimum to cover all known cases including the
> + * off-by-one issue that HW has in some cases.
>*/
> - uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> - u32 val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
> + int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> +
> +
Re: [Intel-gfx] [PATCH] drm/i915/psr: Set idle frame count based on sink synchronization latency
On Tue, May 29, 2018 at 12:51:23PM -0700, Rodrigo Vivi wrote:
> On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote:
> > DPCD 2009h "Synchronization latency in sink" has bits that tell us the
> > maximum number of frames sink can take to resynchronize to source timing
> > when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum
> > number of frames following PSR exit that the Source device needs to
> > wait for PSR entry."
> >
> > We currently use this value only to setup the number frames to wait before
> > PSR2 selective update. But, based on the above description it makes more
> > sense to use this to configure idle frames for both PSR1 and and PSR2. This
> > will ensure we wait the required number of frames before
> > activation whether it is PSR1 or PSR2.
> >
> > The minimum number of idle frames remains 6, while allowing sink
> > synchronization latency and VBT to increase this value.
> >
> > This also solves the flip-flop between sink and source frames that I
> > noticed on my Thinkpad X260 during PSR exit. This specific panel has a
> > value of 8h, which according to the spec means the "Source device must
> > wait for more than eight active frames after PSR exit before initiating PSR
> > entry. (In this case, should be provided by the panel supplier.)" VBT
> > however has a value of 0.
> >
> > Cc: Jani Nikula
> > Cc: Jose Roberto de Souza
> > Cc: Rodrigo Vivi
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 40
> >
> > 1 file changed, 20 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index ebc483f06c6f..71dfe541740f 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -247,6 +247,8 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> > return;
> > }
> > dev_priv->psr.sink_support = true;
> > + dev_priv->psr.sink_sync_latency =
> > + intel_dp_get_sink_sync_latency(intel_dp);
> >
> > if (INTEL_GEN(dev_priv) >= 9 &&
> > (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> > @@ -272,8 +274,6 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> > if (dev_priv->psr.sink_psr2_support) {
> > dev_priv->psr.colorimetry_support =
> > intel_dp_get_colorimetry_status(intel_dp);
> > - dev_priv->psr.sink_sync_latency =
> > - intel_dp_get_sink_sync_latency(intel_dp);
> > }
> > }
> > }
> > @@ -370,21 +370,21 @@ static void hsw_activate_psr1(struct intel_dp
> > *intel_dp)
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_device *dev = dig_port->base.base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > + u32 max_sleep_time = 0x1f;
> > + u32 val = EDP_PSR_ENABLE;
> >
> > - uint32_t max_sleep_time = 0x1f;
> > - /*
> > -* Let's respect VBT in case VBT asks a higher idle_frame value.
> > -* Let's use 6 as the minimum to cover all known cases including
> > -* the off-by-one issue that HW has in some cases. Also there are
> > -* cases where sink should be able to train
> > -* with the 5 or 6 idle patterns.
> > + /* Let's use 6 as the minimum to cover all known cases including the
> > +* off-by-one issue that HW has in some cases.
> > */
> > - uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> > - uint32_t val = EDP_PSR_ENABLE;
> > + int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> >
> > - val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> > + /* sink_sync_latency of 8 means source has to wait for more than 8
> > +* frames, we'll go with 9 frames for now
> > +*/
> > + idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency + 1);
> > val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> >
> > + val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> > if (IS_HASWELL(dev_priv))
> > val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
> >
> > @@ -424,15 +424,15 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_device *dev = dig_port->base.base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > - /*
> > -* Let's respect VBT in case VBT asks a higher idle_frame value.
> > -* Let's use 6 as the minimum to cover all known cases including
> > -* the off-by-one issue that HW has in some cases. Also there are
> > -* cases where sink should be able to train
> > -* with the 5 or 6 idle patterns.
> > + u32 val;
> > +
> > + /* Let's use 6 as the minimum to cover all known cases including the
> > +* off-by-one issue that HW has in some cases.
> > */
> > - uint32_t idle_frames = max
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+
== Series Details == Series: series starting with [1/5] drm/i915: Fix sprite destination colorkeying on SKL+ URL : https://patchwork.freedesktop.org/series/43902/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4254_full -> Patchwork_9141_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9141_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9141_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43902/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9141_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-bsd1: shard-kbl: SKIP -> PASS igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9141_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> INCOMPLETE (fdo#103665) shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) igt@kms_flip@flip-vs-expired-vblank: shard-hsw: PASS -> FAIL (fdo#105189) igt@kms_flip@plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_hangcheck: shard-apl: DMESG-FAIL (fdo#106560) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#106509, fdo#105454) -> PASS igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@plain-flip-fb-recreate: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-x-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS +2 igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4254 -> Patchwork_9141 CI_DRM_4254: 59d0ee3539be08fb2551cc59719e79305e3115aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9141: c844de7ddf13da9b20987dde73372281747864d0 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9141/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
On 25/05/18 08:14, Chris Wilson wrote:
We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; flushing it to idle in the
process!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/perf_pmu.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 590e6526b..9af192dd8 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2
*e, unsigned int flags)
/* Check for idle after hang. */
if (flags & FLAG_HANG) {
- /* Sleep for a bit for reset unwind to settle. */
- usleep(500e3);
- /*
-* Ensure batch was executing before reset, meaning it must be
-* idle by now. Unless it did not even manage to start before we
-* triggered the reset, in which case the idleness check below
-* might fail. The latter is very unlikely since there are two
-* sleeps during which it had an opportunity to start.
-*/
+ gem_quiescent_gpu(gem_fd);
igt_assert(!gem_bo_busy(gem_fd, spin->handle));
+
val = pmu_read_single(fd);
slept = measured_usleep(batch_duration_ns / 1000);
val = pmu_read_single(fd) - val;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context
Hi,
On 5/29/2018 12:16 PM, Lionel Landwerlin wrote:
We want to be able to modify other context images from the kernel
context in a following commit. To be able to do this we need to map
the context image into the kernel context's ppgtt.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gem_context.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 19 ++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index f40d85448a28..9c313c2edb09 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -155,6 +155,7 @@ struct i915_gem_context {
struct intel_context {
struct i915_gem_context *gem_context;
struct i915_vma *state;
+ struct i915_vma *kernel_state; /**/
struct intel_ring *ring;
u32 *lrc_reg_state;
u64 lrc_desc;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7314e548fb4e..8a49323f6672 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2739,7 +2739,7 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
struct intel_context *ce)
{
struct drm_i915_gem_object *ctx_obj;
- struct i915_vma *vma;
+ struct i915_vma *ggtt_vma, *ppgtt_vma;
uint32_t context_size;
struct intel_ring *ring;
struct i915_timeline *timeline;
@@ -2762,9 +2762,17 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
goto error_deref_obj;
}
- vma = i915_vma_instance(ctx_obj, &ctx->i915->ggtt.base, NULL);
- if (IS_ERR(vma)) {
- ret = PTR_ERR(vma);
+ ggtt_vma = i915_vma_instance(ctx_obj, &ctx->i915->ggtt.base, NULL);
+ if (IS_ERR(ggtt_vma)) {
+ ret = PTR_ERR(ggtt_vma);
+ goto error_deref_obj;
+ }
+
+ ppgtt_vma = i915_vma_instance(ctx_obj,
+ &ctx->i915->kernel_context->ppgtt->base,
This is dangerous if someone decides to use 'aliasing ppgtt'
(enable_ppgtt=1 is still a valid option).
You'll need something like this,
struct i915_hw_ppgtt *ppgtt = ctx->i915->kernel_context->ppgtt ?:
ctx->i915->mm.aliasing_ppgtt;
+ NULL);
+ if (IS_ERR(ppgtt_vma)) {
+ ret = PTR_ERR(ppgtt_vma);
goto error_deref_obj;
}
@@ -2788,7 +2796,8 @@ static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
}
ce->ring = ring;
- ce->state = vma;
+ ce->state = ggtt_vma;
+ ce->kernel_state = ppgtt_vma;
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: Check for partial PSR dpcd reads
The dpcd read during psr_dpcd_init may not always return the
requested number of bytes. No known cases yet, but good to
put that check in place.
Signed-off-by: Tarun Vyas
---
drivers/gpu/drm/i915/intel_psr.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index ebc483f06c6f..877ed763a12c 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -234,8 +234,11 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
- drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
-sizeof(intel_dp->psr_dpcd));
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd)) !=
sizeof(intel_dp->psr_dpcd)) {
+ DRM_ERROR("PSR DPCD init failed \n");
+ return;
+ }
if (!intel_dp->psr_dpcd[0])
return;
--
2.13.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/psr: Check for partial PSR dpcd reads
== Series Details ==
Series: drm/i915/psr: Check for partial PSR dpcd reads
URL : https://patchwork.freedesktop.org/series/43907/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e77d22f295bc drm/i915/psr: Check for partial PSR dpcd reads
-:23: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#23: FILE: drivers/gpu/drm/i915/intel_psr.c:238:
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd)) !=
sizeof(intel_dp->psr_dpcd)) {
-:24: WARNING:QUOTED_WHITESPACE_BEFORE_NEWLINE: unnecessary whitespace before a
quoted newline
#24: FILE: drivers/gpu/drm/i915/intel_psr.c:239:
+ DRM_ERROR("PSR DPCD init failed \n");
total: 0 errors, 1 warnings, 1 checks, 13 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: per context slice/subslice powergating (rev7)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev7) URL : https://patchwork.freedesktop.org/series/42285/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4254_full -> Patchwork_9142_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9142_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9142_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42285/revisions/7/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9142_full: === IGT changes === Possible regressions igt@gem_ctx_param@invalid-param-get: shard-apl: PASS -> FAIL shard-glk: PASS -> FAIL shard-snb: PASS -> FAIL shard-hsw: PASS -> FAIL shard-kbl: PASS -> FAIL igt@gem_ctx_param@invalid-param-set: shard-kbl: PASS -> DMESG-FAIL shard-hsw: PASS -> DMESG-FAIL shard-snb: PASS -> DMESG-FAIL shard-glk: PASS -> DMESG-FAIL shard-apl: PASS -> DMESG-FAIL Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +1 igt@gem_mocs_settings@mocs-rc6-bsd1: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9142_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560) igt@drv_selftest@live_workarounds: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-glk: PASS -> FAIL (fdo#103060) shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) Possible fixes igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@plain-flip-fb-recreate: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4254 -> Patchwork_9142 CI_DRM_4254: 59d0ee3539be08fb2551cc59719e79305e3115aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9142: 69235291e9870310ee5dc401c16b71f4a038c940 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9142/shards.html ___ 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/psr: Check for partial PSR dpcd reads
== Series Details == Series: drm/i915/psr: Check for partial PSR dpcd reads URL : https://patchwork.freedesktop.org/series/43907/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4255 -> Patchwork_9143 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9143 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9143, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43907/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9143: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9143 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) +1 igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: PASS -> FAIL (fdo#100368) igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) Possible fixes igt@gem_exec_suspend@basic-s3: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS +1 igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@gem_mmap_gtt@basic-wc: fi-glk-j4005: DMESG-WARN (fdo#105719) -> PASS igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: FAIL (fdo#103841) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-glk-j4005: FAIL (fdo#103481) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: DMESG-WARN (fdo#104951) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (45 -> 39) == Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-u2 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4255 -> Patchwork_9143 CI_DRM_4255: 5550ce1b359dcbd8d9387e0501bc372f0c158eaa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9143: e77d22f295bc96c60866ab042867553c9091ee2a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e77d22f295bc drm/i915/psr: Check for partial PSR dpcd reads == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9143/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Set idle frame count based on sink synchronization latency
On Tue, 2018-05-29 at 12:51 -0700, Rodrigo Vivi wrote:
> On Thu, May 24, 2018 at 08:30:47PM -0700, Dhinakaran Pandiyan wrote:
> >
> > DPCD 2009h "Synchronization latency in sink" has bits that tell us
> > the
> > maximum number of frames sink can take to resynchronize to source
> > timing
> > when exiting PSR. More importantly, as per eDP 1.4b, this is the
> > "Minimum
> > number of frames following PSR exit that the Source device needs to
> > wait for PSR entry."
> >
> > We currently use this value only to setup the number frames to wait
> > before
> > PSR2 selective update. But, based on the above description it makes
> > more
> > sense to use this to configure idle frames for both PSR1 and and
> > PSR2. This
> > will ensure we wait the required number of frames before
> > activation whether it is PSR1 or PSR2.
> >
> > The minimum number of idle frames remains 6, while allowing sink
> > synchronization latency and VBT to increase this value.
> >
> > This also solves the flip-flop between sink and source frames that
> > I
> > noticed on my Thinkpad X260 during PSR exit. This specific panel
> > has a
> > value of 8h, which according to the spec means the "Source device
> > must
> > wait for more than eight active frames after PSR exit before
> > initiating PSR
> > entry. (In this case, should be provided by the panel supplier.)"
> > VBT
> > however has a value of 0.
> >
> > Cc: Jani Nikula
> > Cc: Jose Roberto de Souza
> > Cc: Rodrigo Vivi
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 40 --
> > --
> > 1 file changed, 20 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index ebc483f06c6f..71dfe541740f 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -247,6 +247,8 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> > return;
> > }
> > dev_priv->psr.sink_support = true;
> > + dev_priv->psr.sink_sync_latency =
> > + intel_dp_get_sink_sync_latency(intel_dp);
> >
> > if (INTEL_GEN(dev_priv) >= 9 &&
> > (intel_dp->psr_dpcd[0] ==
> > DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> > @@ -272,8 +274,6 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> > if (dev_priv->psr.sink_psr2_support) {
> > dev_priv->psr.colorimetry_support =
> > intel_dp_get_colorimetry_status(in
> > tel_dp);
> > - dev_priv->psr.sink_sync_latency =
> > - intel_dp_get_sink_sync_latency(int
> > el_dp);
> > }
> > }
> > }
> > @@ -370,21 +370,21 @@ static void hsw_activate_psr1(struct intel_dp
> > *intel_dp)
> > struct intel_digital_port *dig_port =
> > dp_to_dig_port(intel_dp);
> > struct drm_device *dev = dig_port->base.base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > + u32 max_sleep_time = 0x1f;
> > + u32 val = EDP_PSR_ENABLE;
> >
> > - uint32_t max_sleep_time = 0x1f;
> > - /*
> > - * Let's respect VBT in case VBT asks a higher idle_frame
> > value.
> > - * Let's use 6 as the minimum to cover all known cases
> > including
> > - * the off-by-one issue that HW has in some cases. Also
> > there are
> > - * cases where sink should be able to train
> > - * with the 5 or 6 idle patterns.
> > + /* Let's use 6 as the minimum to cover all known cases
> > including the
> > + * off-by-one issue that HW has in some cases.
> > */
> > - uint32_t idle_frames = max(6, dev_priv-
> > >vbt.psr.idle_frames);
> > - uint32_t val = EDP_PSR_ENABLE;
> > + int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> >
> > - val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> > + /* sink_sync_latency of 8 means source has to wait for
> > more than 8
> > + * frames, we'll go with 9 frames for now
> > + */
> > + idle_frames = max(idle_frames, dev_priv-
> > >psr.sink_sync_latency + 1);
> > val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> >
> > + val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> > if (IS_HASWELL(dev_priv))
> > val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
> >
> > @@ -424,15 +424,15 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > struct intel_digital_port *dig_port =
> > dp_to_dig_port(intel_dp);
> > struct drm_device *dev = dig_port->base.base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > - /*
> > - * Let's respect VBT in case VBT asks a higher idle_frame
> > value.
> > - * Let's use 6 as the minimum to cover all known cases
> > including
> > - * the off-by-one issue that HW has in some cases. Also
> > there are
> > - * cases where sink should be able to train
> > - * with the 5 or 6 idle patterns.
> > + u32 val;
> > +
> > + /* Let's use 6 as the minimum to cover all known cases
> >
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context
On 29/05/18 21:26, Michel Thierry wrote:
Hi,
On 5/29/2018 12:16 PM, Lionel Landwerlin wrote:
We want to be able to modify other context images from the kernel
context in a following commit. To be able to do this we need to map
the context image into the kernel context's ppgtt.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gem_context.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 19 ++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index f40d85448a28..9c313c2edb09 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -155,6 +155,7 @@ struct i915_gem_context {
struct intel_context {
struct i915_gem_context *gem_context;
struct i915_vma *state;
+ struct i915_vma *kernel_state; /**/
struct intel_ring *ring;
u32 *lrc_reg_state;
u64 lrc_desc;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index 7314e548fb4e..8a49323f6672 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2739,7 +2739,7 @@ static int
execlists_context_deferred_alloc(struct i915_gem_context *ctx,
struct intel_context *ce)
{
struct drm_i915_gem_object *ctx_obj;
- struct i915_vma *vma;
+ struct i915_vma *ggtt_vma, *ppgtt_vma;
uint32_t context_size;
struct intel_ring *ring;
struct i915_timeline *timeline;
@@ -2762,9 +2762,17 @@ static int
execlists_context_deferred_alloc(struct i915_gem_context *ctx,
goto error_deref_obj;
}
- vma = i915_vma_instance(ctx_obj, &ctx->i915->ggtt.base, NULL);
- if (IS_ERR(vma)) {
- ret = PTR_ERR(vma);
+ ggtt_vma = i915_vma_instance(ctx_obj, &ctx->i915->ggtt.base, NULL);
+ if (IS_ERR(ggtt_vma)) {
+ ret = PTR_ERR(ggtt_vma);
+ goto error_deref_obj;
+ }
+
+ ppgtt_vma = i915_vma_instance(ctx_obj,
+ &ctx->i915->kernel_context->ppgtt->base,
This is dangerous if someone decides to use 'aliasing ppgtt'
(enable_ppgtt=1 is still a valid option).
You'll need something like this,
struct i915_hw_ppgtt *ppgtt = ctx->i915->kernel_context->ppgtt ?:
ctx->i915->mm.aliasing_ppgtt;
Thanks a lot of the tip, I'm very much new to this.
Will fix and see if they are tests that can exercise this in igt.
-
Lionel
+ NULL);
+ if (IS_ERR(ppgtt_vma)) {
+ ret = PTR_ERR(ppgtt_vma);
goto error_deref_obj;
}
@@ -2788,7 +2796,8 @@ static int
execlists_context_deferred_alloc(struct i915_gem_context *ctx,
}
ce->ring = ring;
- ce->state = vma;
+ ce->state = ggtt_vma;
+ ce->kernel_state = ppgtt_vma;
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/8] drm/i915: create context image vma in kernel context
Quoting Lionel Landwerlin (2018-05-29 22:35:08)
> On 29/05/18 21:26, Michel Thierry wrote:
> > Hi,
> >
> > On 5/29/2018 12:16 PM, Lionel Landwerlin wrote:
> >> We want to be able to modify other context images from the kernel
> >> context in a following commit. To be able to do this we need to map
> >> the context image into the kernel context's ppgtt.
> >>
> >> Signed-off-by: Lionel Landwerlin
> >> ---
> >> drivers/gpu/drm/i915/i915_gem_context.h | 1 +
> >> drivers/gpu/drm/i915/intel_lrc.c | 19 ++-
> >> 2 files changed, 15 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> >> b/drivers/gpu/drm/i915/i915_gem_context.h
> >> index f40d85448a28..9c313c2edb09 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_context.h
> >> +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> >> @@ -155,6 +155,7 @@ struct i915_gem_context {
> >> struct intel_context {
> >> struct i915_gem_context *gem_context;
> >> struct i915_vma *state;
> >> + struct i915_vma *kernel_state; /**/
It's debatable if we want to keep the pointer around.
We have one for the context state vma and ring vma, because we need to
keep a pointer for the object and so choose to keep the vma instead as
we use that more often than the drm_i915_gem_object and can derive it
from vma->obj.
For this piece of code, which should be run that often I don't see a lot
of advantage over using the rbtree search, and since the number of
objects in that tree will not be large (2 at most), quick.
/* Don't forget to declare the dependency tree! */
prev = i915_gem_active_raw(&ce->ring->timeline->last_request,
&rq->i915->drm.struct_mutex);
if (prev) {
err = i915_sw_fence_await_sw_fence_gfp(&rq->submit,
&prev->submit,
I915_FENCE_GFP);
if (err < 0)
return err;
}
vma = i915_vma_instance(ce->state->obj, my_vm, NULL);
if (IS_ERR(vma)) ...
err = i915_vma_pin(vma, 0, PIN_USER);
if (err) ...
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
i915_vma_unpin(vma);
if (err) ... /* not today, but tomorrow */
Now you can
cs = intel_ring_begin(rq, 4);
...
*cs++ = gen8_canonical_addr(vma->node.state + offset);
...
intel_ring_advance(rq, cs);
On error, you will have to submit the request since it has interacted
with the tracking.
Don't bother pushing this into an engine vfunc, if you don't intend to
have multiple implementations. It's only a SDM, nothing that appears the
need to be specialised. Although you might argue the context layout will
require it later? As for the SDM, Joonas might complain about the
proliferation, but I'm not sure if we have a good repeating pattern yet.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Check for partial PSR dpcd reads
== Series Details == Series: drm/i915/psr: Check for partial PSR dpcd reads URL : https://patchwork.freedesktop.org/series/43907/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4255_full -> Patchwork_9143_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9143_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9143_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43907/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9143_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9143_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560) shard-apl: PASS -> DMESG-FAIL (fdo#106560) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#103928) igt@kms_flip@plain-flip-fb-recreate: shard-hsw: PASS -> FAIL (fdo#100368) +1 igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) +1 Possible fixes igt@kms_cursor_crc@cursor-256x256-suspend: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@2x-modeset-vs-vblank-race: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@wf_vblank-ts-check-interruptible: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS igt@kms_vblank@pipe-a-accuracy-idle: shard-hsw: FAIL (fdo#102583) -> PASS igt@perf_pmu@semaphore-wait-idle-vecs0: shard-glk: FAIL -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4255 -> Patchwork_9143 CI_DRM_4255: 5550ce1b359dcbd8d9387e0501bc372f0c158eaa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4499: f560ae5a464331f03f0a669ed46b8c9e56526187 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9143: e77d22f295bc96c60866ab042867553c9091ee2a @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9143/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/24] drm/i915/icp: Add Interrupt Support
On Thu, May 24, 2018 at 05:43:24PM -0700, Lucas De Marchi wrote:
> On Thu, May 24, 2018 at 05:45:43PM -0700, Dhinakaran Pandiyan wrote:
> > On Thu, 2018-05-24 at 16:53 -0700, Lucas De Marchi wrote:
> > > On Mon, May 21, 2018 at 05:25:39PM -0700, Paulo Zanoni wrote:
> > > >
> > > > From: Anusha Srivatsa
> > > >
> > > > This patch addresses Interrupts from south display engine (SDE).
> > > >
> > > > ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
> > > > Introduce these registers and their intended values.
> > > >
> > > > Introduce icp_irq_handler().
> > > >
> > > > Cc: Paulo Zanoni
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Ville Syrjala
> > > > Signed-off-by: Anusha Srivatsa
> > > > [Paulo: coding style bikesheds and rebases].
> > > > Signed-off-by: Paulo Zanoni
> > > > ---
> > > > drivers/gpu/drm/i915/i915_irq.c | 134
> > > > +++-
> > > > drivers/gpu/drm/i915/i915_reg.h | 40
> > > > 2 files changed, 172 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 9bcec5fdb9d0..6b109991786f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -122,6 +122,15 @@ static const u32 hpd_tc_gen11[HPD_NUM_PINS] =
> > > > {
> > > > [HPD_PORT_F] = GEN11_TC4_HOTPLUG
> > > > };
> > > >
> > > > +static const u32 hpd_icp[HPD_NUM_PINS] = {
> > > > + [HPD_PORT_A] = ICP_DDIA_HOTPLUG,
> > > > + [HPD_PORT_B] = ICP_DDIB_HOTPLUG,
> > > > + [HPD_PORT_C] = ICP_TC1_HOTPLUG,
> > > > + [HPD_PORT_D] = ICP_TC2_HOTPLUG,
> > > > + [HPD_PORT_E] = ICP_TC3_HOTPLUG,
> > > > + [HPD_PORT_F] = ICP_TC4_HOTPLUG
> > > > +};
> > > > +
> > > > /* IIR can theoretically queue up two events. Be paranoid. */
> > > > #define GEN8_IRQ_RESET_NDX(type, which) do { \
> > > > I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> > > > @@ -1586,6 +1595,34 @@ static bool
> > > > bxt_port_hotplug_long_detect(enum port port, u32 val)
> > > > }
> > > > }
> > > >
> > > > +static bool icp_ddi_port_hotplug_long_detect(enum port port, u32
> > > > val)
> > > > +{
> > > > + switch (port) {
> > > > + case PORT_A:
> > > > + return val & ICP_DDIA_HPD_LONG_DETECT;
> > > > + case PORT_B:
> > > > + return val & ICP_DDIB_HPD_LONG_DETECT;
> > > > + default:
> > > > + return false;
> > > > + }
> > > > +}
> > > > +
> > > > +static bool icp_tc_port_hotplug_long_detect(enum port port, u32
> > > > val)
> > > > +{
> > > > + switch (port) {
> > > > + case PORT_C:
> > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
> > > > + case PORT_D:
> > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
> > > > + case PORT_E:
> > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
> > > > + case PORT_F:
> > > > + return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
> > > > + default:
> > > > + return false;
> > > > + }
> > > > +}
> > > > +
> > > > static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
> > > > {
> > > > switch (port) {
> > > > @@ -2377,6 +2414,43 @@ static void cpt_irq_handler(struct
> > > > drm_i915_private *dev_priv, u32 pch_iir)
> > > > cpt_serr_int_handler(dev_priv);
> > > > }
> > > >
> > > > +static void icp_irq_handler(struct drm_i915_private *dev_priv, u32
> > > > pch_iir)
> > > > +{
> > > > + u32 ddi_hotplug_trigger = pch_iir & ICP_SDE_DDI_MASK;
> > > > + u32 tc_hotplug_trigger = pch_iir & ICP_SDE_TC_MASK;
> > > > + u32 pin_mask = 0, long_mask = 0;
> > > > +
> > > > + if (ddi_hotplug_trigger) {
> > > > + u32 dig_hotplug_reg;
> > > > +
> > > > + dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_DDI);
> > > > + I915_WRITE(SHOTPLUG_CTL_DDI, dig_hotplug_reg);
> > > > +
> > > > + intel_get_hpd_pins(dev_priv, &pin_mask,
> > > > &long_mask,
> > > > + ddi_hotplug_trigger,
> > > > + dig_hotplug_reg, hpd_icp,
> > > > + icp_ddi_port_hotplug_long_detec
> > > > t);
> > > > + }
> > > > +
> > > > + if (tc_hotplug_trigger) {
> > > > + u32 dig_hotplug_reg;
> > > > +
> > > > + dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_TC);
> > > > + I915_WRITE(SHOTPLUG_CTL_TC, dig_hotplug_reg);
> > > > +
> > > > + intel_get_hpd_pins(dev_priv, &pin_mask,
> > > > &long_mask,
> > > > + tc_hotplug_trigger,
> > > > + dig_hotplug_reg, hpd_icp,
> > > > + icp_tc_port_hotplug_long_detect
> > > > );
> > > > + }
> > > > +
> > > > + if (pin_mask)
> > > > +
[Intel-gfx] [PATCH i-g-t] [RFC] Add support to force specific module load
This patch adds a new option to force the use of a module specified from
the command line. The force command expects a module name which will be
used on the target test (changing the standard behavior). This feature
can be useful for developers that have to create a new module since it
is possible to use some of the tests already provided by IGT (e.g.,
kms_color, core, etc.) as a start point. Additionally, it can
also be useful for someone that wants to implement a new set of tests
for a specific driver because the developer can first check the behavior
of any test in the target module. It is important to highlight, that a
force option can produce unexpected results and developers should be
aware of that.
Signed-off-by: Rodrigo Siqueira
---
lib/drmtest.c| 19 +--
lib/igt_core.c | 20
lib/igt_core.h | 4
scripts/run-tests.sh | 4 +++-
4 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index fae6f86f..1d2ba178 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -258,6 +258,7 @@ static int __open_device(const char *base, int offset,
unsigned int chipset)
static int __open_driver(const char *base, int offset, unsigned int chipset)
{
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
+ const char* target;
static const struct module {
unsigned int bit;
const char *module;
@@ -276,13 +277,19 @@ static int __open_driver(const char *base, int offset,
unsigned int chipset)
if (fd != -1)
return fd;
+ target = get_target_module();
+
pthread_mutex_lock(&mutex);
- for (const struct module *m = modules; m->module; m++) {
- if (chipset & m->bit) {
- if (m->modprobe)
- m->modprobe(m->module);
- else
- modprobe(m->module);
+ if (target) {
+ modprobe(target);
+ } else {
+ for (const struct module *m = modules; m->module; m++) {
+ if (chipset & m->bit) {
+ if (m->modprobe)
+ m->modprobe(m->module);
+ else
+ modprobe(m->module);
+ }
}
}
pthread_mutex_unlock(&mutex);
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 5092a3f0..ed66eae1 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -286,6 +286,7 @@ enum {
OPT_DESCRIPTION,
OPT_DEBUG,
OPT_INTERACTIVE_DEBUG,
+ OPT_FORCE_MODULE,
OPT_HELP = 'h'
};
@@ -303,6 +304,20 @@ static pthread_mutex_t log_buffer_mutex =
PTHREAD_MUTEX_INITIALIZER;
GKeyFile *igt_key_file;
#endif
+char *target_module;
+
+void set_target_module(char *target)
+{
+ if (!target)
+igt_warn("No module specified, keep default behaviour");
+ target_module = target;
+}
+
+const char *get_target_module(void)
+{
+ return target_module;
+}
+
char *igt_frame_dump_path;
const char *igt_test_name(void)
@@ -555,6 +570,7 @@ static void print_usage(const char *help_str, bool
output_on_stderr)
" --debug[=log-domain]\n"
" --interactive-debug[=domain]\n"
" --help-description\n"
+ " --force-module \n"
" --help\n");
if (help_str)
fprintf(f, "%s\n", help_str);
@@ -666,6 +682,7 @@ static int common_init(int *argc, char **argv,
{"debug", optional_argument, 0, OPT_DEBUG},
{"interactive-debug", optional_argument, 0,
OPT_INTERACTIVE_DEBUG},
{"help", 0, 0, OPT_HELP},
+ {"force-module", required_argument, 0, OPT_FORCE_MODULE},
{0, 0, 0, 0}
};
char *short_opts;
@@ -763,6 +780,9 @@ static int common_init(int *argc, char **argv,
print_test_description();
ret = -1;
goto out;
+ case OPT_FORCE_MODULE:
+ set_target_module(strdup(optarg));
+ break;
case OPT_HELP:
print_usage(help_str, false);
ret = -1;
diff --git a/lib/igt_core.h b/lib/igt_core.h
index bf8cd66c..6d635ebd 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -50,6 +50,10 @@ extern const char* __igt_test_description
__attribute__((weak));
extern bool __igt_plain_output;
extern char *igt_frame_dump_path;
+extern char *target_module;
+void set_target_module(char *target);
+const char *get_target_module(void);
+
/**
* IGT_TEST_DESCRIPTION:
* @str: description string
diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh
index 4209dd8c..c810a8dd 100755
--- a/scripts/run-tests.sh
+++ b/scripts/run-tests.sh
@@ -80,6 +80,7 @@ function print_help {
echo "
[Intel-gfx] [PATCH i-g-t 3/3] Move declaration to the top of the code
This patch fix the following gcc warnings:
warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement] [..]
igt_color_encoding.c:45:2: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement] [..]
igt_color_encoding.c: In function ‘ycbcr_to_rgb_matrix’:
igt_color_encoding.c:72:2: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement] [..]
Signed-off-by: Rodrigo Siqueira
---
lib/igt_color_encoding.c | 16 ++--
tests/kms_frontbuffer_tracking.c | 2 +-
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/lib/igt_color_encoding.c b/lib/igt_color_encoding.c
index b1648a74..1a89bb46 100644
--- a/lib/igt_color_encoding.c
+++ b/lib/igt_color_encoding.c
@@ -36,11 +36,9 @@ static const struct color_encoding
color_encodings[IGT_NUM_COLOR_ENCODINGS] = {
static struct igt_mat4 rgb_to_ycbcr_matrix(const struct color_encoding *e)
{
- float kr, kg, kb;
-
- kr = e->kr;
- kb = e->kb;
- kg = 1.0f - kr - kb;
+ float kr = e->kr;
+ float kb = e->kb;
+ float kg = 1.0f - kr - kb;
struct igt_mat4 ret = {
.d[0 * 4 + 0] = kr,
@@ -63,11 +61,9 @@ static struct igt_mat4 rgb_to_ycbcr_matrix(const struct
color_encoding *e)
static struct igt_mat4 ycbcr_to_rgb_matrix(const struct color_encoding *e)
{
- float kr, kg, kb;
-
- kr = e->kr;
- kb = e->kb;
- kg = 1.0f - kr - kb;
+ float kr = e->kr;
+ float kb = e->kb;
+ float kg = 1.0f - kr - kb;
struct igt_mat4 ret = {
.d[0 * 4 + 0] = 1.0f,
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 8754cc46..dbb8ba62 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -1770,8 +1770,8 @@ static void do_status_assertions(int flags)
static void __do_assertions(const struct test_mode *t, int flags,
int line)
{
- flags = adjust_assertion_flags(t, flags);
bool mandatory_sink_crc = t->feature & FEATURE_PSR;
+ flags = adjust_assertion_flags(t, flags);
igt_debug("checking asserts in line %i\n", line);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/3] Remove extra '\0' in strncpy in igt_save_module_param
This patch fix the following gcc warning: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] strncpy(data->name, name, PARAM_NAME_MAX_SZ); This error happens due to the '\0' character appended by strncpy. Notice that reduces by one in the total of bytes to be copied, in this case, is harmless because the strings received in the parameter already have '\0'. Signed-off-by: Rodrigo Siqueira --- lib/igt_aux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/igt_aux.c b/lib/igt_aux.c index 5dd2761e..06f586d6 100644 --- a/lib/igt_aux.c +++ b/lib/igt_aux.c @@ -1240,7 +1240,7 @@ static void igt_save_module_param(const char *name, const char *file_path) data = calloc(1, sizeof (*data)); igt_assert(data); - strncpy(data->name, name, PARAM_NAME_MAX_SZ); + strncpy(data->name, name, PARAM_NAME_MAX_SZ - 1); // -1 because of '\0' fd = open(file_path, O_RDONLY); igt_assert(fd >= 0); -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/3] Avoid truncate string in __igt_lsof_fds
Note that 'proc_path' parameter in __igt_lsof_fds receives a string
which was initialized with the size of PATH_MAX and the local variable
'path' has the same size, but it also have to append: '/', '\0', and the
directory name. This situation caused the warning described below.
warning: ‘%s’ directive output may be truncated writing up to 255 bytes
into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(path, sizeof(path), "%s/%s", proc_path, d->d_name);
note: ‘snprintf’ output between 2 and 4352 bytes into a destination of
size 4096 [..]
This patch fix the above problem.
Signed-off-by: Rodrigo Siqueira
---
lib/igt_aux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index acafb713..5dd2761e 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -1425,7 +1425,7 @@ __igt_lsof_fds(proc_t *proc_info, int *state, char
*proc_path, const char *dir)
{
struct dirent *d;
struct stat st;
- char path[PATH_MAX];
+ char path[PATH_MAX + NAME_MAX + 2]; // 1 byte for '/' and another for
'\0'
char *fd_lnk;
/* default fds or kernel threads */
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
