Re: [Intel-gfx] [PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer
On 11/30/16 at 03:25pm, Ville Syrjälä wrote:
> On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote:
> > On 11/24/16 at 10:53am, Jani Nikula wrote:
> > > On Thu, 24 Nov 2016, Dave Young wrote:
> > > > I see a lot of below warning:
> > >
> > > No, we must not hide this under the carpet. There's a bug at fdo about
> > > this, and we need to fix it.
> >
> > It is not hiding it, just not repeating the warnings. But anyway I do
> > not have strong opinion. I'm building my kernel with this patch until
> > there is a real fix in upstream.
>
> We already have a patch to reduce it a single WARN:
> d4cb3fd9b548 ("drm/i915/dp: add lane_count check in
> intel_dp_check_link_status")
It works for me, thanks
>
> Do we need to get that backported to stable?
Personally I think it should but I'm not sure the policy of stable for i915
though.
Thanks
Dave
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: use platform enum instead of duplicating PCI ID if possible
On ke, 2016-11-30 at 17:43 +0200, Jani Nikula wrote: > Duplicating the PCI ID for IS_FOO checks is redundant for a bunch of > platforms. Simplify. > > Signed-off-by: Jani Nikula This should do pure good when optimizing the checks. Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer
On 12/01/16 at 04:00pm, Dave Young wrote:
> On 11/30/16 at 03:25pm, Ville Syrjälä wrote:
> > On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote:
> > > On 11/24/16 at 10:53am, Jani Nikula wrote:
> > > > On Thu, 24 Nov 2016, Dave Young wrote:
> > > > > I see a lot of below warning:
> > > >
> > > > No, we must not hide this under the carpet. There's a bug at fdo about
> > > > this, and we need to fix it.
> > >
> > > It is not hiding it, just not repeating the warnings. But anyway I do
> > > not have strong opinion. I'm building my kernel with this patch until
> > > there is a real fix in upstream.
> >
> > We already have a patch to reduce it a single WARN:
> > d4cb3fd9b548 ("drm/i915/dp: add lane_count check in
> > intel_dp_check_link_status")
>
> It works for me, thanks
>
> >
> > Do we need to get that backported to stable?
>
> Personally I think it should but I'm not sure the policy of stable for i915
> though.
>
Hmm, I can not recall when I had such issue in which version of kernel
because I just pull and rebuild very often, so I should say I have no
idea ..
> Thanks
> Dave
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: add some more "i" in platform names for consistency
On ke, 2016-11-30 at 17:43 +0200, Jani Nikula wrote: > Consistency FTW. > > Signed-off-by: Jani Nikula Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces
From: Swati Dhingra The patch introduces a new pseudo filesystem type, named 'drmfs' which is intended to house the files for the data generated by drm subsystem that cannot be accommodated by any of the existing filesystems. The filesystem is modelled on the lines of existing pseudo-filesystems such as debugfs/tracefs, and borrows ideas from their implementation. This filesystem will be appearing at sys/kernel/drm. A new config 'CONFIG_DRMFS' is introduced to enable/disable the filesystem, which is dependent on CONFIG_DRM. The filesystem will not be registered standalone during kernel init time, instead it is intended to be initialized/registered during drm initialization. The intent for introduction of the filesystem is to act as a location to hold various kinds of data output from Linux DRM subsystems, which can't really fit anywhere else into the existing filesystems such as debugfs/sysfs etc. All these filesystems have their own constraints and are intended to output a particular type of data such as attributes and small debug parameter data. Due to these constraints, there is a need for a new pseudo filesytem, customizable to DRM specific requirements and catering to the needs to DRM subsystem components Signed-off-by: Sourab Gupta Signed-off-by: Swati Dhingra --- drivers/gpu/drm/drm_drv.c | 1 + fs/Kconfig | 9 + fs/Makefile| 1 + fs/drmfs/Makefile | 3 + fs/drmfs/inode.c | 561 + include/linux/drmfs.h | 56 + include/uapi/linux/magic.h | 3 + 7 files changed, 634 insertions(+) create mode 100644 fs/drmfs/Makefile create mode 100644 fs/drmfs/inode.c create mode 100644 include/linux/drmfs.h diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 6dbb986..84fcfcb 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -27,6 +27,7 @@ */ #include +#include #include #include #include diff --git a/fs/Kconfig b/fs/Kconfig index 4bd03a2..7d0ac20 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -200,6 +200,15 @@ config HUGETLBFS config HUGETLB_PAGE def_bool HUGETLBFS +config DRMFS + bool "Drmfs file system support" + depends on DRM + help + Drmfs is a pseudo file system for drm subsystem output data. + + drmfs is a filesystem to hold miscellaneous output data from drm + subsystems. + config ARCH_HAS_GIGANTIC_PAGE bool diff --git a/fs/Makefile b/fs/Makefile index ed2b632..b34a96e 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -120,6 +120,7 @@ obj-$(CONFIG_BEFS_FS) += befs/ obj-$(CONFIG_HOSTFS) += hostfs/ obj-$(CONFIG_CACHEFILES) += cachefiles/ obj-$(CONFIG_DEBUG_FS) += debugfs/ +obj-$(CONFIG_DRMFS)+= drmfs/ obj-$(CONFIG_TRACING) += tracefs/ obj-$(CONFIG_OCFS2_FS) += ocfs2/ obj-$(CONFIG_BTRFS_FS) += btrfs/ diff --git a/fs/drmfs/Makefile b/fs/drmfs/Makefile new file mode 100644 index 000..ac87e497 --- /dev/null +++ b/fs/drmfs/Makefile @@ -0,0 +1,3 @@ +drmfs-objs := inode.o + +obj-$(CONFIG_DRMFS)+= drmfs.o diff --git a/fs/drmfs/inode.c b/fs/drmfs/inode.c new file mode 100644 index 000..9220705 --- /dev/null +++ b/fs/drmfs/inode.c @@ -0,0 +1,561 @@ +/* + * Copyright © 2014 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING 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: + * Swati Dhingra + * Sourab Gupta + * Akash Goel + */ + +/* + * drmfs is the filesystem used for output of drm subsystem data + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRMFS_DEFAULT_MODE 0700 + +static struct vfsmount *drmfs_mount; +static int drmfs_mount_count; +static bool drmfs_registered; + +static ssize_t default_read_file(struct file *file, char __user *buf,
[Intel-gfx] [RFC 0/3] Introduce drmfs pseudo filesystem for drm subsystem
From: Swati Dhingra Currently, for the purpose of providing output debug/loggging/crc and various other kinds of data from DRM layer to userspace, we don't have a standard filesystem, which would suffice for all the usecases. The filesystems used currently such as debugfs/sysfs have their own constraints and are intended to output a particular type of data. For instance, sysfs is suitable for exporting only small data in form of attributes, thus not suitable to export large data such as error states/logs/crc etc. Likewise for debugfs, which is not available in production kernels, and may not be best place to hold certain kinds of data. As a result, we currently are creating certain files in these filesystems, which are not particularly suited there (For, i915, guc_log is a case in point, which is currently created in debugfs, but not particularly suited there). Due to these constraints, there is a need for a new pseudo filesytem, customizable to DRM specific requirements and catering to the needs to DRM subsystem components. This will provide a unified location to hold various kinds of data from Linux DRM subsystems, for the files which can't really fit anywhere else into the existing filesystems. In this patch series, we have introduced a pseudo filesystem named as 'drmfs' for now. The filesystem is introduced in the first patch, and the subsequent patches make use of the filesystem interfaces, in drm driver, and making them available for use by the drm subsystem components, one of which is i915. We've moved the location of i915 GuC logs from debugfs to drmfs in the third patch. Subsequently, more such files such as pipe_crc, error states, memory stats, etc. can be move to this filesystem, if the idea introduced here is acceptable per se. The filesystem introduced is being used to house the data generated by i915 driver in this patch series, but will hopefully be generic enough to provide scope for usage by any other drm subsystem component. The patch series is being floated as RFC to gather feedback on the idea and infrastructure proposed here and it's suitability to address the specific problem statement/use case. v2: fix the bat failures caused due to missing config check Swati Dhingra (3): fs: Introduce drmfs pseudo filesystem interfaces drm: Register drmfs filesystem from drm init drm/i915: Creating guc log file in drmfs instead of debugfs drivers/gpu/drm/drm_drv.c | 23 ++ drivers/gpu/drm/i915/i915_guc_submission.c | 31 +- fs/Kconfig | 9 + fs/Makefile| 1 + fs/drmfs/Makefile | 4 + fs/drmfs/inode.c | 561 + include/drm/drm_drv.h | 3 + include/linux/drmfs.h | 56 +++ include/uapi/linux/magic.h | 3 + 9 files changed, 670 insertions(+), 21 deletions(-) create mode 100644 fs/drmfs/Makefile create mode 100644 fs/drmfs/inode.c create mode 100644 include/linux/drmfs.h -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/3] drm: Register drmfs filesystem from drm init
From: Swati Dhingra
During drm module initialization, drm_core_init initializes the drmfs
filesystem and register this with kernel. A driver specific directory is created
inside drmfs root, and dentry of this directory is saved for subsequent use
by the driver (e.g. i915). The driver can then create files/directories inside
this root directory directly.
In case of i915 driver, the top directory is created at '/sys/kernel/drm/i915'.
Signed-off-by: Sourab Gupta
Signed-off-by: Swati Dhingra
---
drivers/gpu/drm/drm_drv.c | 22 ++
include/drm/drm_drv.h | 3 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 84fcfcb..ead360bd 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -688,6 +688,14 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
{
int ret;
+#ifdef CONFIG_DRMFS
+ dev->driver->drmfs_root = drmfs_create_dir(dev->driver->name, NULL);
+ if (IS_ERR(dev->driver->drmfs_root)) {
+ DRM_ERROR("Failed to get drmfs root dentry\n");
+ return PTR_ERR(dev->driver->drmfs_root);
+ }
+#endif
+
mutex_lock(&drm_global_mutex);
ret = drm_minor_register(dev, DRM_MINOR_CONTROL);
@@ -758,6 +766,9 @@ void drm_dev_unregister(struct drm_device *dev)
drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
drm_minor_unregister(dev, DRM_MINOR_RENDER);
drm_minor_unregister(dev, DRM_MINOR_CONTROL);
+#ifdef CONFIG_DRMFS
+ drmfs_remove(dev->driver->drmfs_root);
+#endif
}
EXPORT_SYMBOL(drm_dev_unregister);
@@ -825,6 +836,9 @@ static void drm_core_exit(void)
{
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
+#ifdef CONFIG_DRMFS
+ drmfs_fini();
+#endif
drm_sysfs_destroy();
idr_destroy(&drm_minors_idr);
drm_connector_ida_destroy();
@@ -845,6 +859,14 @@ static int __init drm_core_init(void)
goto error;
}
+#ifdef CONFIG_DRMFS
+ ret = drmfs_init();
+ if (ret < 0) {
+ DRM_ERROR("Cannot create DRM FS: %d\n", ret);
+ goto error;
+ }
+#endif
+
drm_debugfs_root = debugfs_create_dir("dri", NULL);
if (!drm_debugfs_root) {
ret = -ENOMEM;
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index aad8bba..34804de 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -403,6 +403,9 @@ struct drm_driver {
/* List of devices hanging off this driver with stealth attach. */
struct list_head legacy_dev_list;
+
+ /* drmfs parent directory dentry for this driver */
+ struct dentry *drmfs_root;
};
extern __printf(6, 7)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/3] drm/i915: Creating guc log file in drmfs instead of debugfs
From: Swati Dhingra
In the current scenario, the relay API fit well only with debugfs, due to
availability of parent dentry. Any other existing filesystem was not feasible
for
holding guc logs, due to incompatibility with relay. But this makes the guc_log
file unavailable on the production kernels.
GuC log file can therefore be one of candidates for movement to the drmfs
filesystem, which can satisfy all the requirements needed by relay API, and can
house any relayfs based output file.
The patch moves the parent directory of guc 'log_dir' from debugfs_root to
drmfs_root, while using the drmfs api's to create the requisite files.
Signed-off-by: Sourab Gupta
Signed-off-by: Swati Dhingra
---
drivers/gpu/drm/i915/i915_guc_submission.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4462112..cd2e8ed 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include "i915_drv.h"
#include "intel_guc.h"
@@ -923,7 +924,7 @@ static int subbuf_start_callback(struct rchan_buf *buf,
}
/*
- * file_create() callback. Creates relay file in debugfs.
+ * file_create() callback. Creates relay file.
*/
static struct dentry *create_buf_file_callback(const char *filename,
struct dentry *parent,
@@ -949,17 +950,26 @@ static struct dentry *create_buf_file_callback(const char
*filename,
* dentry of the file associated with the channel buffer and that file's
* name need not be same as the filename passed as an argument.
*/
+#if defined(CONFIG_DRMFS)
+ buf_file = drmfs_create_file("guc_log", mode,
+ parent, buf, &relay_file_operations);
+#else
buf_file = debugfs_create_file("guc_log", mode,
parent, buf, &relay_file_operations);
+#endif
return buf_file;
}
/*
- * file_remove() default callback. Removes relay file in debugfs.
+ * file_remove() default callback. Removes relay file.
*/
static int remove_buf_file_callback(struct dentry *dentry)
{
+#if defined(CONFIG_DRMFS)
+ drmfs_remove(dentry);
+#else
debugfs_remove(dentry);
+#endif
return 0;
}
@@ -1009,6 +1019,10 @@ static int guc_log_create_relay_file(struct intel_guc
*guc)
struct dentry *log_dir;
int ret;
+#if defined(CONFIG_DRMFS)
+ /* Create the log file in drmfs dir: /sys/kernel/drm/i915/ */
+ log_dir = dev_priv->drm.driver->drmfs_root;
+#else
/* For now create the log file in /sys/kernel/debug/dri/0 dir */
log_dir = dev_priv->drm.primary->debugfs_root;
@@ -1021,10 +1035,12 @@ static int guc_log_create_relay_file(struct intel_guc
*guc)
* relay channel.
* ii) Should be able to use 'relay_file_operations' fops for the file.
* iii) Set the 'i_private' field of file's inode to the pointer of
-* relay channel buffer.
+* relay channel buffer.
*/
+#endif
+
if (!log_dir) {
- DRM_ERROR("Debugfs dir not available yet for GuC log file\n");
+ DRM_ERROR("Root dir not available yet for GuC log file\n");
return -ENODEV;
}
@@ -1265,7 +1281,7 @@ static int guc_log_create_extras(struct intel_guc *guc)
if (!guc->log.relay_chan) {
/* Create a relay channel, so that we have buffers for storing
* the GuC firmware logs, the channel will be linked with a file
-* later on when debugfs is registered.
+* later on when debugfs/drmfs is registered.
*/
ret = guc_log_create_relay_channel(guc);
if (ret)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: rename BROADWATER and CRESTLINE to I965G and I965GM, respectively
On ke, 2016-11-30 at 17:43 +0200, Jani Nikula wrote: > Add more consistency to our naming. Pineview remains the outlier. Keep > using code names for gen5+. > > Signed-off-by: Jani Nikula Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces
On Thu, Dec 01, 2016 at 12:32:31PM +0530, swati.dhin...@intel.com wrote:
> +int drmfs_init(void)
> +{
> + int retval;
> +
> + retval = sysfs_create_mount_point(kernel_kobj, "drm");
> + if (retval)
> + return -EINVAL;
> +
> + retval = register_filesystem(&drm_fs_type);
> + if (!retval)
> + drmfs_registered = true;
> +
> + return retval;
> +}
> +EXPORT_SYMBOL(drmfs_init);
> +
> +int drmfs_fini(void)
> +{
> + int retval;
> +
> + retval = unregister_filesystem(&drm_fs_type);
> + if (retval)
> + return retval;
> +
> + drmfs_registered = false;
> +
> + sysfs_remove_mount_point(kernel_kobj, "drm");
> +}
> +EXPORT_SYMBOL(drmfs_fini);
This needs to act like a singleton for multiple DRM drivers, i.e.
add a mutex and use drmfs_registered as a reference count (also then
don't call the entrypoint init/fini). Or alternatively (and probably
better?), simply do init/fini from the DRM module init.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm-intel split-up and new dim script
Ok, transition is over, old drm-intel-nightly and rerere-cache is removed. I hope that's enough of a hint to everyone else who missed the memo ;-) -Daniel On Thu, Nov 24, 2016 at 11:48:47AM +0100, Daniel Vetter wrote: > Hi all, > > So it's finally done, drm-misc is split out into a separate repo: > > https://cgit.freedesktop.org/drm-misc > > The integration tree and rerere-cache was also split out, so that both > groups can update it: > > https://cgit.freedesktop.org/drm-tip > > To get there you need to update dim and re-run the setup steps: > > 1. Grab latest dim (if you have already, just update the maintainer-tools > checkout) and store it somewhere temporarily. 2. Delete the old auxiliary > directories: > > $ cd $DIM_PREFIX $ rm drm-intel-rerere drm-intel-nightly maintainer-tools > -Rf > > 3. Make sure you have a recent enough git with worktree support. It's not > required, but if you have one it's automatically used, and it save a pile > of disk space. > > 4. Re-run > > $ dim setup > > Note that for those who start fresh with dim, there's manpages and > quickstart guides in dim itself, just run > > $ dim help > > from a checkout of the maintainer-tools branch from > > https://cgit.freedesktop.org/drm-intel > > Or take a look at > https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html > > For drm-misc the new branch is drm-misc-next, topic/drm-misc is dead > effective immediate (and I'll ping people on irc who still push patches). > The other tree that changes is drm-intel-nightly, new drm-tip, and I plan > to keep both places roughly in sync for at least a week. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces
On Thu, Dec 01, 2016 at 12:32:31PM +0530, swati.dhin...@intel.com wrote: > diff --git a/fs/Kconfig b/fs/Kconfig > index 4bd03a2..7d0ac20 100644 > --- a/fs/Kconfig > +++ b/fs/Kconfig > @@ -200,6 +200,15 @@ config HUGETLBFS > config HUGETLB_PAGE > def_bool HUGETLBFS > > +config DRMFS > + bool "Drmfs file system support" > + depends on DRM > + help > + Drmfs is a pseudo file system for drm subsystem output data. > + > + drmfs is a filesystem to hold miscellaneous output data from drm > + subsystems. > + > config ARCH_HAS_GIGANTIC_PAGE > bool > > diff --git a/fs/Makefile b/fs/Makefile > index ed2b632..b34a96e 100644 > --- a/fs/Makefile > +++ b/fs/Makefile > @@ -120,6 +120,7 @@ obj-$(CONFIG_BEFS_FS) += befs/ > obj-$(CONFIG_HOSTFS) += hostfs/ > obj-$(CONFIG_CACHEFILES) += cachefiles/ > obj-$(CONFIG_DEBUG_FS) += debugfs/ > +obj-$(CONFIG_DRMFS) += drmfs/ A filesystem does not have to live under fs/. Since this is dedicated and tied to the lifetime of drivers/gpu/drm/drm.ko, we will be happier with not adding a new MAINTAINERS entry. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/3] drm: Register drmfs filesystem from drm init
On Thu, Dec 01, 2016 at 12:32:32PM +0530, swati.dhin...@intel.com wrote:
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 84fcfcb..ead360bd 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -688,6 +688,14 @@ int drm_dev_register(struct drm_device *dev, unsigned
> long flags)
> {
> int ret;
>
> +#ifdef CONFIG_DRMFS
Rule of thumb: avoid #ifdeffry in the body of the code, use headers to
hide conditional compilation.
> + dev->driver->drmfs_root = drmfs_create_dir(dev->driver->name, NULL);
> + if (IS_ERR(dev->driver->drmfs_root)) {
> + DRM_ERROR("Failed to get drmfs root dentry\n");
> + return PTR_ERR(dev->driver->drmfs_root);
> + }
Considering use of drmfs is optional, should an error here prevent the
driver from loading?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces
On Thu, 2016-12-01 at 00:07 -0800, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 12:32:31PM +0530, swati.dhin...@intel.com wrote:
> > +int drmfs_init(void)
> > +{
> > + int retval;
> > +
> > + retval = sysfs_create_mount_point(kernel_kobj, "drm");
> > + if (retval)
> > + return -EINVAL;
> > +
> > + retval = register_filesystem(&drm_fs_type);
> > + if (!retval)
> > + drmfs_registered = true;
> > +
> > + return retval;
> > +}
> > +EXPORT_SYMBOL(drmfs_init);
> > +
> > +int drmfs_fini(void)
> > +{
> > + int retval;
> > +
> > + retval = unregister_filesystem(&drm_fs_type);
> > + if (retval)
> > + return retval;
> > +
> > + drmfs_registered = false;
> > +
> > + sysfs_remove_mount_point(kernel_kobj, "drm");
> > +}
> > +EXPORT_SYMBOL(drmfs_fini);
>
> This needs to act like a singleton for multiple DRM drivers, i.e.
> add a mutex and use drmfs_registered as a reference count (also then
> don't call the entrypoint init/fini). Or alternatively (and probably
> better?), simply do init/fini from the DRM module init.
> -Chris
>
Hi Chris,
In the second patch, drmfs_init is called by drm_core_init, which should
thus be called only once (i.e. during drm module init), and likewise for
drmfs_fini which is called during drm_core_exit.
Am I missing something here?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces
On Thu, 2016-12-01 at 00:11 -0800, Chris Wilson wrote: > On Thu, Dec 01, 2016 at 12:32:31PM +0530, swati.dhin...@intel.com wrote: > > diff --git a/fs/Kconfig b/fs/Kconfig > > index 4bd03a2..7d0ac20 100644 > > --- a/fs/Kconfig > > +++ b/fs/Kconfig > > @@ -200,6 +200,15 @@ config HUGETLBFS > > config HUGETLB_PAGE > > def_bool HUGETLBFS > > > > +config DRMFS > > + bool "Drmfs file system support" > > + depends on DRM > > + help > > + Drmfs is a pseudo file system for drm subsystem output data. > > + > > + drmfs is a filesystem to hold miscellaneous output data from drm > > + subsystems. > > + > > config ARCH_HAS_GIGANTIC_PAGE > > bool > > > > diff --git a/fs/Makefile b/fs/Makefile > > index ed2b632..b34a96e 100644 > > --- a/fs/Makefile > > +++ b/fs/Makefile > > @@ -120,6 +120,7 @@ obj-$(CONFIG_BEFS_FS) += befs/ > > obj-$(CONFIG_HOSTFS) += hostfs/ > > obj-$(CONFIG_CACHEFILES) += cachefiles/ > > obj-$(CONFIG_DEBUG_FS) += debugfs/ > > +obj-$(CONFIG_DRMFS)+= drmfs/ > > A filesystem does not have to live under fs/. Since this is dedicated > and tied to the lifetime of drivers/gpu/drm/drm.ko, we will be happier > with not adding a new MAINTAINERS entry. > -Chris > Ok, agreed. So, should we have the drmfs/ source directory (with its associated files) under drivers/gpu/drm/? Can you please suggest where should the associated 'DRMFS' config be defined? Should drm/Kconfig be a good place? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/3] drm: Register drmfs filesystem from drm init
On Thu, 2016-12-01 at 00:15 -0800, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 12:32:32PM +0530, swati.dhin...@intel.com wrote:
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 84fcfcb..ead360bd 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -688,6 +688,14 @@ int drm_dev_register(struct drm_device *dev, unsigned
> > long flags)
> > {
> > int ret;
> >
> > +#ifdef CONFIG_DRMFS
>
> Rule of thumb: avoid #ifdeffry in the body of the code, use headers to
> hide conditional compilation.
Ok. Will do the requisite changes.
>
> > + dev->driver->drmfs_root = drmfs_create_dir(dev->driver->name, NULL);
> > + if (IS_ERR(dev->driver->drmfs_root)) {
> > + DRM_ERROR("Failed to get drmfs root dentry\n");
> > + return PTR_ERR(dev->driver->drmfs_root);
> > + }
>
> Considering use of drmfs is optional, should an error here prevent the
> driver from loading?
> -Chris
Ok. Will remove the return on the error here.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce drmfs pseudo filesystem for drm subsystem (rev2)
== Series Details == Series: Introduce drmfs pseudo filesystem for drm subsystem (rev2) URL : https://patchwork.freedesktop.org/series/16203/ State : success == Summary == Series 16203v2 Introduce drmfs pseudo filesystem for drm subsystem https://patchwork.freedesktop.org/api/1.0/series/16203/revisions/2/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 fi-bxt-t5700 failed to connect after reboot 7fb9612344bbf021a5a3589df82077023dae5e1d drm-tip: 2016y-12m-01d-07h-38m-22s UTC integration manifest 2e85dc9 drm/i915: Creating guc log file in drmfs instead of debugfs 9a06379 drm: Register drmfs filesystem from drm init 69e3465 fs: Introduce drmfs pseudo filesystem interfaces == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3158/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces
On Thu, Dec 01, 2016 at 02:01:59PM +0530, sourab gupta wrote:
> On Thu, 2016-12-01 at 00:07 -0800, Chris Wilson wrote:
> > On Thu, Dec 01, 2016 at 12:32:31PM +0530, swati.dhin...@intel.com wrote:
> > > +int drmfs_init(void)
> > > +{
> > > + int retval;
> > > +
> > > + retval = sysfs_create_mount_point(kernel_kobj, "drm");
> > > + if (retval)
> > > + return -EINVAL;
> > > +
> > > + retval = register_filesystem(&drm_fs_type);
> > > + if (!retval)
> > > + drmfs_registered = true;
> > > +
> > > + return retval;
> > > +}
> > > +EXPORT_SYMBOL(drmfs_init);
> > > +
> > > +int drmfs_fini(void)
> > > +{
> > > + int retval;
> > > +
> > > + retval = unregister_filesystem(&drm_fs_type);
> > > + if (retval)
> > > + return retval;
> > > +
> > > + drmfs_registered = false;
> > > +
> > > + sysfs_remove_mount_point(kernel_kobj, "drm");
> > > +}
> > > +EXPORT_SYMBOL(drmfs_fini);
> >
> > This needs to act like a singleton for multiple DRM drivers, i.e.
> > add a mutex and use drmfs_registered as a reference count (also then
> > don't call the entrypoint init/fini). Or alternatively (and probably
> > better?), simply do init/fini from the DRM module init.
> > -Chris
> >
> Hi Chris,
>
> In the second patch, drmfs_init is called by drm_core_init, which should
> thus be called only once (i.e. during drm module init), and likewise for
> drmfs_fini which is called during drm_core_exit.
> Am I missing something here?
Nope, that was me missing the change from driver registration to core
between chunks. The only thing missing here then are the __init,
__exit markers, and to make it perfectly clear that this is a distinct
phase move the calls to init/exit into their own patch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/3] Introduce drmfs pseudo filesystem for drm subsystem
On Thu, 01 Dec 2016, swati.dhin...@intel.com wrote: > Currently, for the purpose of providing output debug/loggging/crc and various > other kinds of data from DRM layer to userspace, we don't have a standard > filesystem, which would suffice for all the usecases. The filesystems used > currently such as debugfs/sysfs have their own constraints and are intended > to output a particular type of data. For instance, sysfs is suitable for > exporting only small data in form of attributes, thus not suitable to export > large data such as error states/logs/crc etc. Likewise for debugfs, which is > not available in production kernels, and may not be best place to hold certain > kinds of data. As a result, we currently are creating certain files in these > filesystems, which are not particularly suited there (For, i915, guc_log is a > case in point, which is currently created in debugfs, but not particularly > suited there). > > Due to these constraints, there is a need for a new pseudo filesytem, > customizable to DRM specific requirements and catering to the needs to DRM > subsystem components. This will provide a unified location to hold various > kinds of data from Linux DRM subsystems, for the files which can't really fit > anywhere else into the existing filesystems. I don't think you properly describe the problems you have with the current interfaces. You need to be very specific here. I don't think having one "standard filesystem" for drm that would cover all use cases is going to work out. We will need to combine several interfaces for our needs. Do you realize that you can't really remove anything from the current ABI? You can't move stuff from, say, sysfs to your new drmfs, you'd only be able to duplicate the API... Did you notice that a new interface for CRCs was recently introduced? Did you look at all options, such as adding a new device node for the guc logging needs, instead of adding a whole new filesystem? What is wrong with that? Where does it fall short? My first impression here is that you think this will make things easier, but eventually you'll notice you've ended up with all the same problems as before, but with an additional filesystem to maintain to the end of time. I'm not a fan unless you come up with much more compelling reasons. BR, Jani. PS. Needs to be posted to dri-devel. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/3] fs: Introduce drmfs pseudo filesystem interfaces
On Thu, Dec 01, 2016 at 02:07:19PM +0530, sourab gupta wrote: > On Thu, 2016-12-01 at 00:11 -0800, Chris Wilson wrote: > > On Thu, Dec 01, 2016 at 12:32:31PM +0530, swati.dhin...@intel.com wrote: > > > diff --git a/fs/Kconfig b/fs/Kconfig > > > index 4bd03a2..7d0ac20 100644 > > > --- a/fs/Kconfig > > > +++ b/fs/Kconfig > > > @@ -200,6 +200,15 @@ config HUGETLBFS > > > config HUGETLB_PAGE > > > def_bool HUGETLBFS > > > > > > +config DRMFS > > > + bool "Drmfs file system support" > > > + depends on DRM > > > + help > > > + Drmfs is a pseudo file system for drm subsystem output data. > > > + > > > + drmfs is a filesystem to hold miscellaneous output data from drm > > > + subsystems. > > > + > > > config ARCH_HAS_GIGANTIC_PAGE > > > bool > > > > > > diff --git a/fs/Makefile b/fs/Makefile > > > index ed2b632..b34a96e 100644 > > > --- a/fs/Makefile > > > +++ b/fs/Makefile > > > @@ -120,6 +120,7 @@ obj-$(CONFIG_BEFS_FS) += befs/ > > > obj-$(CONFIG_HOSTFS) += hostfs/ > > > obj-$(CONFIG_CACHEFILES) += cachefiles/ > > > obj-$(CONFIG_DEBUG_FS) += debugfs/ > > > +obj-$(CONFIG_DRMFS) += drmfs/ > > > > A filesystem does not have to live under fs/. Since this is dedicated > > and tied to the lifetime of drivers/gpu/drm/drm.ko, we will be happier > > with not adding a new MAINTAINERS entry. > > -Chris > > > Ok, agreed. > So, should we have the drmfs/ source directory (with its associated > files) under drivers/gpu/drm/? If it sticks to one file, drmfs.c. (Slightly breaks the trend, but still consistent as we are using the drmfs_ prefix.) If we follow the pattern of having mount.c, file.c, dir.c etc, then drivers/gpu/drm/drmfs/ > Can you please suggest where should the associated 'DRMFS' config be > defined? Should drm/Kconfig be a good place? Yes, drivers/gpu/drm/Kconfig. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/3] Introduce drmfs pseudo filesystem for drm subsystem
On Thu, Dec 01, 2016 at 10:48:31AM +0200, Jani Nikula wrote: > On Thu, 01 Dec 2016, swati.dhin...@intel.com wrote: > > Currently, for the purpose of providing output debug/loggging/crc and > > various > > other kinds of data from DRM layer to userspace, we don't have a standard > > filesystem, which would suffice for all the usecases. The filesystems used > > currently such as debugfs/sysfs have their own constraints and are intended > > to output a particular type of data. For instance, sysfs is suitable for > > exporting only small data in form of attributes, thus not suitable to export > > large data such as error states/logs/crc etc. Likewise for debugfs, which is > > not available in production kernels, and may not be best place to hold > > certain > > kinds of data. As a result, we currently are creating certain files in these > > filesystems, which are not particularly suited there (For, i915, guc_log is > > a > > case in point, which is currently created in debugfs, but not particularly > > suited there). > > > > Due to these constraints, there is a need for a new pseudo filesytem, > > customizable to DRM specific requirements and catering to the needs to DRM > > subsystem components. This will provide a unified location to hold various > > kinds of data from Linux DRM subsystems, for the files which can't really > > fit > > anywhere else into the existing filesystems. > > I don't think you properly describe the problems you have with the > current interfaces. You need to be very specific here. > > I don't think having one "standard filesystem" for drm that would cover > all use cases is going to work out. We will need to combine several > interfaces for our needs. The only thing that DRM is registering is a filesystem to manage a canonical mountpoint. That does not limit everyone to only using that psuedofs underneath. > Do you realize that you can't really remove anything from the current > ABI? You can't move stuff from, say, sysfs to your new drmfs, you'd only > be able to duplicate the API... Exactly, why we wanted an ABI kernfs in the first place. sysfs is not compatible, debugfs is not ABI. > Did you notice that a new interface for CRCs was recently introduced? > > Did you look at all options, such as adding a new device node for the > guc logging needs, instead of adding a whole new filesystem? What is > wrong with that? Where does it fall short? Adding a device node was pretty ugly in comparison and would be less transferrable/sharable to similar situations in future, or between DRM drivers. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Create a common GEN9_LP_FEATURE.
From: Rodrigo Vivi
The following LP platform inherits a lot of this platform
So let's simplify here to re-use this later.
v2: Keep ddb_size out of the new macro.
v3: Rebase (has_decoupled_mmio). (Imre)
Signed-off-by: Rodrigo Vivi
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_pci.c | 47 ++---
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fce8e19..2797dec 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -343,31 +343,34 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
};
+#define GEN9_LP_FEATURES \
+ .gen = 9, \
+ .has_hotplug = 1, \
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
+ .num_pipes = 3, \
+ .has_64bit_reloc = 1, \
+ .has_ddi = 1, \
+ .has_fpga_dbg = 1, \
+ .has_fbc = 1, \
+ .has_runtime_pm = 1, \
+ .has_pooled_eu = 0, \
+ .has_csr = 1, \
+ .has_resource_streamer = 1, \
+ .has_rc6 = 1, \
+ .has_dp_mst = 1, \
+ .has_gmbus_irq = 1, \
+ .has_hw_contexts = 1, \
+ .has_logical_ring_contexts = 1, \
+ .has_guc = 1, \
+ .has_decoupled_mmio = 1, \
+ GEN_DEFAULT_PIPEOFFSETS, \
+ IVB_CURSOR_OFFSETS, \
+ BDW_COLORS
+
static const struct intel_device_info intel_broxton_info = {
.is_broxton = 1,
- .gen = 9,
- .has_hotplug = 1,
- .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
- .num_pipes = 3,
- .has_64bit_reloc = 1,
- .has_ddi = 1,
- .has_fpga_dbg = 1,
- .has_fbc = 1,
- .has_runtime_pm = 1,
- .has_pooled_eu = 0,
- .has_csr = 1,
- .has_resource_streamer = 1,
- .has_rc6 = 1,
- .has_dp_mst = 1,
- .has_gmbus_irq = 1,
- .has_hw_contexts = 1,
- .has_logical_ring_contexts = 1,
- .has_guc = 1,
- .has_decoupled_mmio = 1,
+ GEN9_LP_FEATURES,
.ddb_size = 512,
- GEN_DEFAULT_PIPEOFFSETS,
- IVB_CURSOR_OFFSETS,
- BDW_COLORS,
};
static const struct intel_device_info intel_kabylake_info = {
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: Invalidate the guc ggtt TLB upon insertion
Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
modification rather than proliferate it into all the callers of the
insert (which may or may not in fact have to do the insertion).
v2: Just do the guc invalidate unconditionally, (afaict) it has no impact
without the guc loaded on gen8+
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter # v1
Reviewed-by: Daniel Vetter # v1
---
drivers/gpu/drm/i915/i915_gem_gtt.c| 12
drivers/gpu/drm/i915/i915_guc_submission.c | 3 ---
drivers/gpu/drm/i915/intel_guc_loader.c| 3 ---
drivers/gpu/drm/i915/intel_lrc.c | 6 --
4 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 02fb063302bf..dccc4d0eef88 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2387,6 +2387,12 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t
pte)
writeq(pte, addr);
}
+static void gen8_ggtt_invalidate(struct drm_i915_private *dev_priv)
+{
+ I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+ I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+}
+
static void gen8_ggtt_insert_page(struct i915_address_space *vm,
dma_addr_t addr,
uint64_t offset,
@@ -2400,8 +2406,7 @@ static void gen8_ggtt_insert_page(struct
i915_address_space *vm,
gen8_set_pte(pte, gen8_pte_encode(addr, level));
- I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
- POSTING_READ(GFX_FLSH_CNTL_GEN6);
+ gen8_ggtt_invalidate(dev_priv);
}
static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
@@ -2438,8 +2443,7 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
* want to flush the TLBs only after we're certain all the PTE updates
* have finished.
*/
- I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
- POSTING_READ(GFX_FLSH_CNTL_GEN6);
+ gen8_ggtt_invalidate(dev_priv);
}
struct insert_entries {
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 58413803ba3c..ef8c18d61a0f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -589,9 +589,6 @@ static struct i915_vma *guc_allocate_vma(struct intel_guc
*guc, u32 size)
goto err;
}
- /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
- I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
-
return vma;
err:
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index a330fa499384..4fb1037faad1 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -366,9 +366,6 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)
return PTR_ERR(vma);
}
- /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
- I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
-
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
/* init WOPCM */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b2c0d509e191..48fc93dadb40 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -874,12 +874,6 @@ static int intel_lr_context_pin(struct i915_gem_context
*ctx,
ce->state->obj->mm.dirty = true;
- /* Invalidate GuC TLB. */
- if (i915.enable_guc_submission) {
- struct drm_i915_private *dev_priv = ctx->i915;
- I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
- }
-
i915_gem_context_get(ctx);
return 0;
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] HAX drm/i915: Enable guc submission
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 0e280fbd52f1..ef1e9921a2af 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_loading = 0,
- .enable_guc_submission = 0,
+ .enable_guc_loading = -1,
+ .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
--
2.10.2
___
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, presumably final fixes for 4.9. BR, Jani. The following changes since commit e5517c2a5a49ed5e99047008629f1cd60246ea0e: Linux 4.9-rc7 (2016-11-27 13:08:04 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2016-12-01 for you to fetch changes up to e411072d5740a49cdc9d0713798c30440757e451: drm/i915: drop the struct_mutex when wedged or trying to reset (2016-11-30 12:09:26 +0200) Chris Wilson (1): drm/i915: Don't touch NULL sg on i915_gem_object_get_pages_gtt() error Matthew Auld (1): drm/i915: drop the struct_mutex when wedged or trying to reset drivers/gpu/drm/i915/i915_gem.c | 5 +++-- drivers/gpu/drm/i915/intel_display.c | 3 ++- 2 files changed, 5 insertions(+), 3 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Invalidate the guc ggtt TLB upon insertion
On 01/12/2016 09:46, Chris Wilson wrote:
Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
modification rather than proliferate it into all the callers of the
insert (which may or may not in fact have to do the insertion).
v2: Just do the guc invalidate unconditionally, (afaict) it has no impact
without the guc loaded on gen8+
Why do you find it tempting to do it unconditionally? I would rather not
touch it on gen8 at all and would also prefer the conditional flush in gen9.
Regards,
Tvrtko
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter # v1
Reviewed-by: Daniel Vetter # v1
---
drivers/gpu/drm/i915/i915_gem_gtt.c| 12
drivers/gpu/drm/i915/i915_guc_submission.c | 3 ---
drivers/gpu/drm/i915/intel_guc_loader.c| 3 ---
drivers/gpu/drm/i915/intel_lrc.c | 6 --
4 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 02fb063302bf..dccc4d0eef88 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2387,6 +2387,12 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t
pte)
writeq(pte, addr);
}
+static void gen8_ggtt_invalidate(struct drm_i915_private *dev_priv)
+{
+ I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+ I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+}
+
static void gen8_ggtt_insert_page(struct i915_address_space *vm,
dma_addr_t addr,
uint64_t offset,
@@ -2400,8 +2406,7 @@ static void gen8_ggtt_insert_page(struct
i915_address_space *vm,
gen8_set_pte(pte, gen8_pte_encode(addr, level));
- I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
- POSTING_READ(GFX_FLSH_CNTL_GEN6);
+ gen8_ggtt_invalidate(dev_priv);
}
static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
@@ -2438,8 +2443,7 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
* want to flush the TLBs only after we're certain all the PTE updates
* have finished.
*/
- I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
- POSTING_READ(GFX_FLSH_CNTL_GEN6);
+ gen8_ggtt_invalidate(dev_priv);
}
struct insert_entries {
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 58413803ba3c..ef8c18d61a0f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -589,9 +589,6 @@ static struct i915_vma *guc_allocate_vma(struct intel_guc
*guc, u32 size)
goto err;
}
- /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
- I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
-
return vma;
err:
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index a330fa499384..4fb1037faad1 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -366,9 +366,6 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)
return PTR_ERR(vma);
}
- /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
- I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
-
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
/* init WOPCM */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b2c0d509e191..48fc93dadb40 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -874,12 +874,6 @@ static int intel_lr_context_pin(struct i915_gem_context
*ctx,
ce->state->obj->mm.dirty = true;
- /* Invalidate GuC TLB. */
- if (i915.enable_guc_submission) {
- struct drm_i915_private *dev_priv = ctx->i915;
- I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
- }
-
i915_gem_context_get(ctx);
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Invalidate the guc ggtt TLB upon insertion
On Thu, Dec 01, 2016 at 10:06:25AM +, Tvrtko Ursulin wrote: > > On 01/12/2016 09:46, Chris Wilson wrote: > >Move the GuC invalidation of its ggtt TLB to where we perform the ggtt > >modification rather than proliferate it into all the callers of the > >insert (which may or may not in fact have to do the insertion). > > > >v2: Just do the guc invalidate unconditionally, (afaict) it has no impact > >without the guc loaded on gen8+ > > Why do you find it tempting to do it unconditionally? I would rather > not touch it on gen8 at all and would also prefer the conditional > flush in gen9. Because if I add a conditional here, I end up wanting writing a new vfunc for invalidate (if I can coax the gmch / gen6 / guc usage into something consistent). And I'm lazy. :) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 11/14] HACK drm/i915/scheduler: emulate a scheduler for guc
On 14/11/2016 08:57, Chris Wilson wrote:
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).
As it is starting to sink in we'll have to do add this hack sooner or
later, review comments below.
Also, would you be OK to rebase this or would prefer to delegate it?
---
drivers/gpu/drm/i915/i915_guc_submission.c | 85 +-
drivers/gpu/drm/i915/i915_irq.c| 4 +-
drivers/gpu/drm/i915/intel_lrc.c | 3 --
3 files changed, 76 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4462112725ef..088f5a99ecfc 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -469,7 +469,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request
*request)
u32 freespace;
int ret;
- spin_lock(&gc->wq_lock);
+ spin_lock_irq(&gc->wq_lock);
freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
freespace -= gc->wq_rsvd;
if (likely(freespace >= wqi_size)) {
@@ -479,7 +479,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request
*request)
gc->no_wq_space++;
ret = -EAGAIN;
}
- spin_unlock(&gc->wq_lock);
+ spin_unlock_irq(&gc->wq_lock);
return ret;
}
@@ -491,9 +491,9 @@ void i915_guc_wq_unreserve(struct drm_i915_gem_request
*request)
GEM_BUG_ON(READ_ONCE(gc->wq_rsvd) < wqi_size);
- spin_lock(&gc->wq_lock);
+ spin_lock_irq(&gc->wq_lock);
gc->wq_rsvd -= wqi_size;
- spin_unlock(&gc->wq_lock);
+ spin_unlock_irq(&gc->wq_lock);
}
/* Construct a Work Item and append it to the GuC's Work Queue */
@@ -644,7 +644,7 @@ static void i915_guc_submit(struct drm_i915_gem_request *rq)
rq->previous_context = engine->last_context;
engine->last_context = rq->ctx;
- i915_gem_request_submit(rq);
+ __i915_gem_request_submit(rq);
spin_lock(&client->wq_lock);
guc_wq_item_append(client, rq);
@@ -665,6 +665,70 @@ static void i915_guc_submit(struct drm_i915_gem_request
*rq)
spin_unlock(&client->wq_lock);
}
Confused me at first here until I noticed engine->submit_request will be
the execlist_submit_request later. Perhaps it would be good to rename a
lot of things now, like engine->request_queue,
intel_engine_submit_request and maybe more?
+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
+{
+ struct execlist_port *port = engine->execlist_port;
+ struct drm_i915_gem_request *last = port[0].request;
+ unsigned long flags;
+ struct rb_node *rb;
+ bool submit = false;
+
+ spin_lock_irqsave(&engine->timeline->lock, flags);
+ rb = engine->execlist_first;
+ while (rb) {
+ struct drm_i915_gem_request *cursor =
+ rb_entry(rb, typeof(*cursor), priotree.node);
+
+ if (last && cursor->ctx != last->ctx) {
Not sure if GVT comes into the picture here, but it does not sounds like
it would harm to use can_merge_ctx here?
+ if (port != engine->execlist_port)
+ break;
It may be an overkill for the first version, but I was thinking that we
don't have to limit it to two at a time. And it would depend on
measuring of course. But perhaps it would make sense to do the
generalisation of the number of supported ports straight away.
+
+ i915_gem_request_assign(&port->request, last);
+ dma_fence_enable_sw_signaling(&last->fence);
+ port++;
+ }
+
+ rb = rb_next(rb);
+ rb_erase(&cursor->priotree.node, &engine->execlist_queue);
+ RB_CLEAR_NODE(&cursor->priotree.node);
+ cursor->priotree.priority = INT_MAX;
+
+ i915_guc_submit(cursor);
+ last = cursor;
+ submit = true;
+ }
+ if (submit) {
+ i915_gem_request_assign(&port->request, last);
+ dma_fence_enable_sw_signaling(&last->fence);
+ engine->execlist_first = rb;
+ }
+ spin_unlock_irqrestore(&engine->timeline->lock, flags);
+
+ return submit;
+}
We could theoretically share most of the execlist_dequeue and just do a
couple things differently depending on the mode.
Looks like one could be a new engine->submit_ports vfunc. And there is
also the lite restore WA and sw signalling to design in nicely, but it
may be worth sharing the code. It would be renamed to sometihng like
scheduler_dequeue or something.
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Invalidate the guc ggtt TLB upon insertion
On 01/12/2016 10:26, Chris Wilson wrote: On Thu, Dec 01, 2016 at 10:06:25AM +, Tvrtko Ursulin wrote: On 01/12/2016 09:46, Chris Wilson wrote: Move the GuC invalidation of its ggtt TLB to where we perform the ggtt modification rather than proliferate it into all the callers of the insert (which may or may not in fact have to do the insertion). v2: Just do the guc invalidate unconditionally, (afaict) it has no impact without the guc loaded on gen8+ Why do you find it tempting to do it unconditionally? I would rather not touch it on gen8 at all and would also prefer the conditional flush in gen9. Because if I add a conditional here, I end up wanting writing a new vfunc for invalidate (if I can coax the gmch / gen6 / guc usage into something consistent). And I'm lazy. :) To make sure I fully understand - just because you would not like to see the conditional in gen8_ggtt_invalidate? So you would add gen8_ggtt_invalidate and gen9_ggtt_invalidate with a GuC flush? I would have thought conditional is less bothersome than making the unused piece of the GPU (on gen8) do stuff. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Invalidate the guc ggtt TLB upon insertion
On Thu, Dec 01, 2016 at 10:49:31AM +, Tvrtko Ursulin wrote: > > On 01/12/2016 10:26, Chris Wilson wrote: > >On Thu, Dec 01, 2016 at 10:06:25AM +, Tvrtko Ursulin wrote: > >> > >>On 01/12/2016 09:46, Chris Wilson wrote: > >>>Move the GuC invalidation of its ggtt TLB to where we perform the ggtt > >>>modification rather than proliferate it into all the callers of the > >>>insert (which may or may not in fact have to do the insertion). > >>> > >>>v2: Just do the guc invalidate unconditionally, (afaict) it has no impact > >>>without the guc loaded on gen8+ > >> > >>Why do you find it tempting to do it unconditionally? I would rather > >>not touch it on gen8 at all and would also prefer the conditional > >>flush in gen9. > > > >Because if I add a conditional here, I end up wanting writing a new vfunc > >for invalidate (if I can coax the gmch / gen6 / guc usage into something > >consistent). And I'm lazy. :) > > To make sure I fully understand - just because you would not like to > see the conditional in gen8_ggtt_invalidate? So you would add > gen8_ggtt_invalidate and gen9_ggtt_invalidate with a GuC flush? gen9_guc_ggtt_invalidate. Because I don't like the conditional in i915_ggtt_flush() - and that shows we have another place missing the guc invalidate. And also because at one point, I was toying with the idea of pushing the flush out to the caller of ->insert_page() in case they wanted to manipulate multiple pages. (However, that looks like it will remain single pages only.) I > I would have thought conditional is less bothersome than making the > unused piece of the GPU (on gen8) do stuff. I thought you wouldn't want to punch a bit on the register if it wasn't being used at all. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 1/2] igt_dummyload: clear signal handler on the desructor
Fixes an issue when calling igt_spin_batch_set_timeout and then
tearing down the spinner right away before it has the chance
to timeout, causes the associated signal handler to linger. Make
sure to remove the handler on the destructor as well.
Signed-off-by: Abdiel Janulgue
---
lib/igt_dummyload.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 99515ea..b201af0 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -169,9 +169,17 @@ igt_spin_batch_new(int fd, int engine, unsigned int
dep_handle)
return spin;
}
-static void sig_handler(int sig, siginfo_t *info, void *arg)
+static void clear_sig_handler(int sig)
{
struct sigaction act;
+
+ memset(&act, 0, sizeof(act));
+ act.sa_handler = SIG_DFL;
+ igt_assert(sigaction(sig, &act, NULL) == 0);
+}
+
+static void sig_handler(int sig, siginfo_t *info, void *arg)
+{
struct igt_spin *iter;
igt_list_for_each(iter, &spin_list, link) {
@@ -181,9 +189,7 @@ static void sig_handler(int sig, siginfo_t *info, void *arg)
}
}
- memset(&act, 0, sizeof(act));
- act.sa_handler = SIG_DFL;
- igt_assert(sigaction(info->si_signo, &act, NULL) == 0);
+ clear_sig_handler(info->si_signo);
}
/**
@@ -248,6 +254,7 @@ void igt_spin_batch_end(igt_spin_t *spin)
*spin->batch = MI_BATCH_BUFFER_END;
__sync_synchronize();
+ clear_sig_handler(spin->signo);
}
/**
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 2/2] igt/kms_flip: Fix set_dpms called with an idle bo
Signed-off-by: Abdiel Janulgue
---
tests/kms_flip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 289335a..f744b3d 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -757,9 +757,9 @@ static unsigned int run_test_step(struct test_output *o)
if (o->flags & TEST_DPMS) {
if (spin_rcs)
- igt_spin_batch_end(spin_rcs);
+ igt_spin_batch_set_timeout(spin_rcs, NSEC_PER_SEC);
if (spin_bcs)
- igt_spin_batch_end(spin_bcs);
+ igt_spin_batch_set_timeout(spin_bcs, NSEC_PER_SEC);
set_dpms(o, DRM_MODE_DPMS_ON);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] CentOS and Skylake
Hello, I'm really enjoying the Intel Skylake graphics in Fedora 24/25 and Archlinux; thanks for all of the great work. I remember the old XIG AcceleratedX drivers from years ago... I would rather get back to using CentOS on my Skylake development laptop; Fedora 25 has failed on my twice in two weeks. And I understand that the latest Intel graphics stack requires a very recent kernel/libdrm/mesa/cairo, etc to make that happen. I was wondering if anyone on this list has any knowledge of: 1. if it is even possible for Red Hat to back-port support for Skylake graphics in rhel 7.x? 2. and if it is possible, is anyone here privy to a time line? There is one "bug" report pending at R.H. stating that Skylake graphics are not working, so at least they are aware. They hinted at the 7.3 release; but that didn't seem to happen. I know it is easy to install a mainline kernel in CentOS, but that still leaves the other dependencies to contend with. So should I hold my breath with R.H.? Or do you think the rhel 7.x series is just too far behind to be an option with Skylake graphics? Thank you, Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] igt/kms_flip.c: Fix timings check
Adjust the description and constants in the timing check to match each other.
Relax the timing constraint to prevent false positives in vblank interval
checking.
---
tests/kms_flip.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 289335a..53b0b10 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1206,9 +1206,12 @@ static void calibrate_ts(struct test_output *o, int
crtc_idx)
stddev = igt_stats_get_std_deviation(&stats);
igt_info("Expected frametime: %.0fus; measured %.1fus +- %.3fus
accuracy %.2f%%\n",
-expected, mean, stddev, 100 * 6 * stddev / mean);
- igt_assert(6 * stddev / mean < 0.005); /* 99% accuracy within 0.5% */
-
+expected, mean, stddev, 100 * 3 * stddev / mean);
+ /* 99.7% samples within 0.5% of the mean */
+ igt_assert(3 * stddev / mean < 0.005);
+ /* 84% samples within 0.5% of the expected value.
+* See comments in check_timings() in kms_setmode.c
+*/
if (fabs(mean - expected) > 2*stddev) {
igt_warn("vblank interval differs from modeline! expected
%.1fus, measured %1.fus +- %.3fus, difference %.1fus (%.1f sigma)\n",
expected, mean, stddev,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] igt/kms_setmode.c: Tweak timings check constants
Add explanations of the checks and note the way the constants were derived.
Tweak the constants to reflect their purpose better.
---
tests/kms_setmode.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 4031d81..74eed88 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -474,18 +474,48 @@ static void check_timings(int crtc_idx, const
drmModeModeInfo *kmode)
mean = igt_stats_get_mean(&stats);
stddev = igt_stats_get_std_deviation(&stats);
- accuracy = 3.090 * stddev; /* 2-tailed 99% confidence */
+
+ /* 99.7% samples fall within `accuracy` on both sides of mean in normal
+* distribution if `accuracy = 3 * sigma`.
+* https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule
+*
+* The value of 99.7% was chosen to suit requirements of test cases
+* which depend on timing, giving the lowest acceptable MTBF of 5.6s
+* for 60Hz sampling rate.
+*/
+ accuracy = 3. * stddev;
igt_info("Expected frametime: %.0fus; measured %.1fus +- %.3fus
accuracy %.2f%% [%.2f scanlines]\n",
expected, mean, stddev,
100 * accuracy / mean, accuracy / line_time(kmode));
- /* 99% accuracy within one scanline */
+ /* 99.7% samples within one scanline on each side of mean */
igt_assert_f(accuracy < line_time(kmode),
"vblank accuracy (%.3fus, %.1f%%) worse than a scanline
(%.3fus)\n",
accuracy, 100 * accuracy / mean, line_time(kmode));
- igt_assert_f(fabs(mean - expected) < 2*stddev,
+ /* At least 90% of frame times fall within the one scanline on each
+* side of expected mean.
+*
+* Expected scanline duration:
+* (expected - accuracy, expected + accuracy).
+* Assuming maximum difference allowed:
+* expected = mean + n * sigma
+* the scanline duration becomes:
+* (mean - accuracy + n * sigma, mean + accuracy + n * sigma)
+* The expected scanline captures the following number of samples
+* from each side of expected:
+* (erf(abs(-(accuracy/sigma) + n) / sqrt(2))
+* + erf((accuracy/sigma) + n) / sqrt(2))) / 2
+* = samples
+*
+* Solving for samples = 0.9:
+* n = 1.718
+*
+* See:
+*
https://en.wikipedia.org/wiki/Standard_deviation#Rules_for_normally_distributed_data
+*/
+ igt_assert_f(fabs(mean - expected) < 1.718 * stddev,
"vblank interval differs from modeline! expected %.1fus,
measured %1.fus +- %.3fus, difference %.1fus (%.1f sigma)\n",
expected, mean, stddev,
fabs(mean - expected), fabs(mean - expected) / stddev);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: problems fetching the drm-intel, etc trees
Hi guys,
On Nov 30 2016, at 10:49 pm, Rob Clark wrote:
> yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh
git urls for folks who have push access work fine).. although it has
worked for me a couple times today, given enough time.
>
> (not sure if we have github/etc mirrors somewhere? I do have a github
clone of mesa which is up to date as of ~10min ago.. I could do the
same for other git trees if someone somewhere is stuck)
Sorry about this, it is quite bad. I think having mirrors for the key DRM
trees on GitHub is a good idea though, and I can get to setting that up.
Stephen, you need DRM (airlied), drm-misc, drm-panel, drm-intel, drm-tegra,
drm-exynos and drm-msm, right?
Though, whilst you're at it, I noticed that the drm-misc tree needs updating:
it's now at git://anongit.freedesktop.org/drm/drm-misc, rather than a branch
of drm-intel.
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/8] drm/i915/bxt: IPC WA for Broxton
Hey, Mahesh Kumar schreef op ma 28-11-2016 om 18:37 [+0530]: > Hi, > > Will keep WA number in commit message/WA location. > thanks, Sounds good, with that fixed patches 1-5 and 7 look good to me. I think patch 6 will no longer be required since the workaround status will also be kept inside intel_state. ~Maarten - Intel International B.V. Registered in The Netherlands under number 34098535 Statutory seat: Haarlemmermeer Registered address: Capronilaan 37, 1119NG Schiphol-Rijk This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Invalidate the guc ggtt TLB upon insertion
On 01/12/2016 10:57, Chris Wilson wrote: On Thu, Dec 01, 2016 at 10:49:31AM +, Tvrtko Ursulin wrote: On 01/12/2016 10:26, Chris Wilson wrote: On Thu, Dec 01, 2016 at 10:06:25AM +, Tvrtko Ursulin wrote: On 01/12/2016 09:46, Chris Wilson wrote: Move the GuC invalidation of its ggtt TLB to where we perform the ggtt modification rather than proliferate it into all the callers of the insert (which may or may not in fact have to do the insertion). v2: Just do the guc invalidate unconditionally, (afaict) it has no impact without the guc loaded on gen8+ Why do you find it tempting to do it unconditionally? I would rather not touch it on gen8 at all and would also prefer the conditional flush in gen9. Because if I add a conditional here, I end up wanting writing a new vfunc for invalidate (if I can coax the gmch / gen6 / guc usage into something consistent). And I'm lazy. :) To make sure I fully understand - just because you would not like to see the conditional in gen8_ggtt_invalidate? So you would add gen8_ggtt_invalidate and gen9_ggtt_invalidate with a GuC flush? gen9_guc_ggtt_invalidate. Because I don't like the conditional in i915_ggtt_flush() - and that shows we have another place missing the guc invalidate. And also because at one point, I was toying with the idea of pushing the flush out to the caller of ->insert_page() in case they wanted to manipulate multiple pages. (However, that looks like it will remain single pages only.) I I would have thought conditional is less bothersome than making the unused piece of the GPU (on gen8) do stuff. I thought you wouldn't want to punch a bit on the register if it wasn't being used at all. Yes I wouldn't, and not only unused but not validated probably. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake enabling (rev8)
== Series Details == Series: Geminilake enabling (rev8) URL : https://patchwork.freedesktop.org/series/15118/ State : success == Summary == Series 15118v8 Geminilake enabling https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/8/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 ae97fd2e43ca3693dbd127f51b9bba1c2dd1d37d drm-tip: 2016y-12m-01d-10h-10m-46s UTC integration manifest 69d83f8 drm/i915/glk: Add Geminilake PCI IDs e30b2e3 drm/i915/glk: Introduce Geminilake platform definition cd83440 drm/i915: Create a common GEN9_LP_FEATURE. == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3159/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] CentOS and Skylake
On Thu, 01 Dec 2016, Chris Pemberton wrote: > Hello, > > I'm really enjoying the Intel Skylake graphics in Fedora 24/25 and > Archlinux; thanks for all of the great work. I remember the old XIG > AcceleratedX drivers from years ago... > > I would rather get back to using CentOS on my Skylake development > laptop; Fedora 25 has failed on my twice in two weeks. And I > understand that the latest Intel graphics stack requires a very recent > kernel/libdrm/mesa/cairo, etc to make that happen. > > I was wondering if anyone on this list has any knowledge of: > > 1. if it is even possible for Red Hat to back-port support for Skylake > graphics in rhel 7.x? > > 2. and if it is possible, is anyone here privy to a time line? > > There is one "bug" report pending at R.H. stating that Skylake graphics > are not working, so at least they are aware. They hinted at the 7.3 > release; but that didn't seem to happen. > > I know it is easy to install a mainline kernel in CentOS, but that > still leaves the other dependencies to contend with. So should I hold > my breath with R.H.? Or do you think the rhel 7.x series is just too > far behind to be an option with Skylake graphics? Frankly it sounds like you should be talking to Red Hat / CentOS folks rather than drm/i915 upstream... BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 11/14] HACK drm/i915/scheduler: emulate a scheduler for guc
On Thu, Dec 01, 2016 at 10:45:51AM +, Tvrtko Ursulin wrote:
>
> On 14/11/2016 08:57, Chris Wilson wrote:
> >This emulates execlists on top of the GuC in order to defer submission of
> >requests to the hardware. This deferral allows time for high priority
> >requests to gazump their way to the head of the queue, however it nerfs
> >the GuC by converting it back into a simple execlist (where the CPU has
> >to wake up after every request to feed new commands into the GuC).
>
> As it is starting to sink in we'll have to do add this hack sooner
> or later, review comments below.
>
> Also, would you be OK to rebase this or would prefer to delegate it?
It's been very easy to keep it current.
> >@@ -665,6 +665,70 @@ static void i915_guc_submit(struct drm_i915_gem_request
> >*rq)
> > spin_unlock(&client->wq_lock);
> > }
>
> Confused me at first here until I noticed engine->submit_request
> will be the execlist_submit_request later. Perhaps it would be good
> to rename a lot of things now, like engine->request_queue,
> intel_engine_submit_request and maybe more?
Looking at the lifecycle of the request and getting clear names for the
phases and their vfuncs would be sensible. It may also be worthwhile to
decide that some are not engine tasks and belong to a new entity
(dev_priv->gt.X ?)
> >+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
> >+{
> >+struct execlist_port *port = engine->execlist_port;
> >+struct drm_i915_gem_request *last = port[0].request;
> >+unsigned long flags;
> >+struct rb_node *rb;
> >+bool submit = false;
> >+
> >+spin_lock_irqsave(&engine->timeline->lock, flags);
> >+rb = engine->execlist_first;
> >+while (rb) {
> >+struct drm_i915_gem_request *cursor =
> >+rb_entry(rb, typeof(*cursor), priotree.node);
> >+
> >+if (last && cursor->ctx != last->ctx) {
>
> Not sure if GVT comes into the picture here, but it does not sounds
> like it would harm to use can_merge_ctx here?
I wasn't sure what path GVT would take either. So just went with the
simple version that looked as similar to the current guc submission as
possible. Also offloading the scheduling to the guc via semaphores will
likely make this whole chain look completely different.
> >+if (port != engine->execlist_port)
> >+break;
>
> It may be an overkill for the first version, but I was thinking that
> we don't have to limit it to two at a time. And it would depend on
> measuring of course. But perhaps it would make sense to do the
> generalisation of the number of supported ports straight away.
Definitely. I was just looking at a minimal conversion, hence reusing
the existing tracking, and limits.
> We could theoretically share most of the execlist_dequeue and just
> do a couple things differently depending on the mode.
Yes, there were just a couple of intrusive warts that I felt justified
in keeping the routines separate. But mostly it was the merge_ctx
decision that looked to be backend specific.
> Looks like one could be a new engine->submit_ports vfunc. And there
> is also the lite restore WA and sw signalling to design in nicely,
> but it may be worth sharing the code. It would be renamed to
> sometihng like scheduler_dequeue or something.
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >b/drivers/gpu/drm/i915/i915_irq.c
> >index cb8a75f6ca16..18dce4c66d56 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++ b/drivers/gpu/drm/i915/i915_irq.c
> >@@ -1341,8 +1341,10 @@ static void snb_gt_irq_handler(struct
> >drm_i915_private *dev_priv,
> > static __always_inline void
> > gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
> > {
> >-if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
> >+if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
> >+tasklet_schedule(&engine->irq_tasklet);
>
> This would be better made conditional on GuC submission just to
> calling tasklet_schedule twice (occasionally) in execlist mode.
It's not a huge cost if we do schedule the tasklet twice (in the same
interrupt context at least). Otherwise, yes we are incurring more mmio
reads to determine that the CSB didn't advance. On the other hand, I
really don't want to have if (i915.enable_guc_submission) here. Maybe
if (engine->user_irq_tasklet) tasklet_schedule(engine->user_irq_tasklet)
?
Speaking of CSB, the spec keeps hinting that "CSB occupies a whole
cacheline, making the read cheap". I'm not aware of how we can do a UC
to cacheline read in a single transfer. Ideas? movntdqa I thought was
specifically WC.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH 1/2] igt_dummyload: clear signal handler on the desructor
On Thu, Dec 01, 2016 at 12:58:45PM +0200, Abdiel Janulgue wrote:
> Fixes an issue when calling igt_spin_batch_set_timeout and then
> tearing down the spinner right away before it has the chance
> to timeout, causes the associated signal handler to linger. Make
> sure to remove the handler on the destructor as well.
>
> Signed-off-by: Abdiel Janulgue
> ---
> lib/igt_dummyload.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index 99515ea..b201af0 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -169,9 +169,17 @@ igt_spin_batch_new(int fd, int engine, unsigned int
> dep_handle)
> return spin;
> }
>
> -static void sig_handler(int sig, siginfo_t *info, void *arg)
> +static void clear_sig_handler(int sig)
> {
> struct sigaction act;
> +
> + memset(&act, 0, sizeof(act));
> + act.sa_handler = SIG_DFL;
> + igt_assert(sigaction(sig, &act, NULL) == 0);
> +}
> +
> +static void sig_handler(int sig, siginfo_t *info, void *arg)
> +{
> struct igt_spin *iter;
>
> igt_list_for_each(iter, &spin_list, link) {
> @@ -181,9 +189,7 @@ static void sig_handler(int sig, siginfo_t *info, void
> *arg)
> }
> }
>
> - memset(&act, 0, sizeof(act));
> - act.sa_handler = SIG_DFL;
> - igt_assert(sigaction(info->si_signo, &act, NULL) == 0);
> + clear_sig_handler(info->si_signo);
> }
>
> /**
> @@ -248,6 +254,7 @@ void igt_spin_batch_end(igt_spin_t *spin)
>
> *spin->batch = MI_BATCH_BUFFER_END;
> __sync_synchronize();
Newline here since these are two different phases.
> + clear_sig_handler(spin->signo);
I was also thinking about decoupling from the list of spinners here as
well. Just looked like some more work to use safe iterators and
list_del_init().
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i-g-t PATCH 2/2] igt/kms_flip: Fix set_dpms called with an idle bo
On Thu, Dec 01, 2016 at 12:58:46PM +0200, Abdiel Janulgue wrote:
> Signed-off-by: Abdiel Janulgue
> ---
> tests/kms_flip.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> index 289335a..f744b3d 100644
> --- a/tests/kms_flip.c
> +++ b/tests/kms_flip.c
> @@ -757,9 +757,9 @@ static unsigned int run_test_step(struct test_output *o)
>
> if (o->flags & TEST_DPMS) {
> if (spin_rcs)
> - igt_spin_batch_end(spin_rcs);
> + igt_spin_batch_set_timeout(spin_rcs, NSEC_PER_SEC);
> if (spin_bcs)
> - igt_spin_batch_end(spin_bcs);
> + igt_spin_batch_set_timeout(spin_bcs, NSEC_PER_SEC);
> set_dpms(o, DRM_MODE_DPMS_ON);
> }
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake enabling (rev8)
On Thu, 2016-12-01 at 11:15 +, Patchwork wrote: > == Series Details == > > Series: Geminilake enabling (rev8) > URL : https://patchwork.freedesktop.org/series/15118/ > State : success I pushed up to patch 4. Thanks for the reviews so far. Ander > > == Summary == > > Series 15118v8 Geminilake enabling > https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/8/mbox/ > > > fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 > fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 > fi-bxt-t5700 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 > fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 > fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 > fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 > fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 > fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 > fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 > fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 > fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 > > ae97fd2e43ca3693dbd127f51b9bba1c2dd1d37d drm-tip: 2016y-12m-01d-10h-10m-46s > UTC integration manifest > 69d83f8 drm/i915/glk: Add Geminilake PCI IDs > e30b2e3 drm/i915/glk: Introduce Geminilake platform definition > cd83440 drm/i915: Create a common GEN9_LP_FEATURE. > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3159/ > ___ > 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 08/15] drm/i915: Pass around dev_priv in vlv wm functions
Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Pasing dev_priv instead of dev is the future. Let's make the vlv/chv wm
> functions respect that idea.
^Passing
With that fixed, patch 1-10
Reviewed-by: Maarten Lankhorst
When I was looking at converting VLV/CHV watermarks to atomic, I came up with a
lot of these fixes too, so they just make sense. :)
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index c955ee6341a1..e3ee07007fa2 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1067,9 +1067,9 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
> int level;
>
> for (level = 0; level < wm_state->num_levels; level++) {
> - struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> const int sr_fifo_size =
> - INTEL_INFO(to_i915(dev))->num_pipes * 512 - 1;
> + INTEL_INFO(dev_priv)->num_pipes * 512 - 1;
> struct intel_plane *plane;
>
> wm_state->sr[level].plane =
> @@ -1079,7 +1079,7 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
> vlv_invert_wm_value(wm_state->sr[level].cursor,
> 63);
>
> - for_each_intel_plane_on_crtc(dev, crtc, plane) {
> + for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
> wm_state->wm[level].plane[plane->id] =
>
> vlv_invert_wm_value(wm_state->wm[level].plane[plane->id],
> plane->wm.fifo_size);
> @@ -1089,8 +1089,7 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
>
> static void vlv_compute_wm(struct intel_crtc *crtc)
> {
> - struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct vlv_wm_state *wm_state = &crtc->wm_state;
> struct intel_plane *plane;
> int level;
> @@ -1107,7 +1106,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
> if (wm_state->num_active_planes != 1)
> wm_state->cxsr = false;
>
> - for_each_intel_plane_on_crtc(dev, crtc, plane) {
> + for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
> struct intel_plane_state *state =
> to_intel_plane_state(plane->base.state);
> int level;
> @@ -1253,16 +1252,16 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
> *crtc)
>
> #undef VLV_FIFO
>
> -static void vlv_merge_wm(struct drm_device *dev,
> +static void vlv_merge_wm(struct drm_i915_private *dev_priv,
>struct vlv_wm_values *wm)
> {
> struct intel_crtc *crtc;
> int num_active_crtcs = 0;
>
> - wm->level = to_i915(dev)->wm.max_level;
> + wm->level = dev_priv->wm.max_level;
> wm->cxsr = true;
>
> - for_each_intel_crtc(dev, crtc) {
> + for_each_intel_crtc(&dev_priv->drm, crtc) {
> const struct vlv_wm_state *wm_state = &crtc->wm_state;
>
> if (!crtc->active)
> @@ -1281,7 +1280,7 @@ static void vlv_merge_wm(struct drm_device *dev,
> if (num_active_crtcs > 1)
> wm->level = VLV_WM_LEVEL_PM2;
>
> - for_each_intel_crtc(dev, crtc) {
> + for_each_intel_crtc(&dev_priv->drm, crtc) {
> struct vlv_wm_state *wm_state = &crtc->wm_state;
> enum pipe pipe = crtc->pipe;
>
> @@ -1301,13 +1300,12 @@ static void vlv_merge_wm(struct drm_device *dev,
>
> static void vlv_update_wm(struct intel_crtc *crtc)
> {
> - struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
> struct vlv_wm_values wm = {};
>
> vlv_compute_wm(crtc);
> - vlv_merge_wm(dev, &wm);
> + vlv_merge_wm(dev_priv, &wm);
>
> if (memcmp(&dev_priv->wm.vlv, &wm, sizeof(wm)) == 0) {
> /* FIXME should be part of crtc atomic commit */
___
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 [v2,1/2] HAX drm/i915: Enable guc submission
== Series Details == Series: series starting with [v2,1/2] HAX drm/i915: Enable guc submission URL : https://patchwork.freedesktop.org/series/16210/ State : success == Summary == Series 16210v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16210/revisions/1/mbox/ fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 ae97fd2e43ca3693dbd127f51b9bba1c2dd1d37d drm-tip: 2016y-12m-01d-10h-10m-46s UTC integration manifest 73d6e51 drm/i915: Invalidate the guc ggtt TLB upon insertion c268ef0 HAX drm/i915: Enable guc submission == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3160/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Protect DSPARB registers with a spinlock
Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Each DSPARB register can house bits for two separate pipes, hence
> we must protect the registers during reprogramming so that parallel
> FIFO reconfigurations happening simultaneosly on multiple pipes won't
> corrupt each others values.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 6 ++
> 3 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 0fba4bb5655e..c98032e9112b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -811,6 +811,7 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv,
> spin_lock_init(&dev_priv->uncore.lock);
> spin_lock_init(&dev_priv->mm.object_stat_lock);
> spin_lock_init(&dev_priv->mmio_flip_lock);
> + spin_lock_init(&dev_priv->wm.dsparb_lock);
Can we make sure all wm updates are done with dev_priv->wm.wm_mutex held
instead?
gen9 wm's and ilk wm's use that mutex, for similar reasons.
> mutex_init(&dev_priv->sb_lock);
> mutex_init(&dev_priv->modeset_restore_lock);
> mutex_init(&dev_priv->av_mutex);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9d808b706824..75439e9a67f7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2169,6 +2169,9 @@ struct drm_i915_private {
> } sagv_status;
>
> struct {
> + /* protects DSPARB registers on pre-g4x/vlv/chv */
> + spinlock_t dsparb_lock;
> +
> /*
>* Raw watermark latency values:
>* in 0.1us units for WM0,
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 24d85a4e4ed3..9f25f2195a6a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1215,6 +1215,8 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
> *crtc)
> pipe_name(crtc->pipe), sprite0_start,
> sprite1_start, fifo_size);
>
> + spin_lock(&dev_priv->wm.dsparb_lock);
> +
> switch (crtc->pipe) {
> uint32_t dsparb, dsparb2, dsparb3;
> case PIPE_A:
> @@ -1271,6 +1273,10 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
> *crtc)
> default:
> break;
> }
> +
> + POSTING_READ(DSPARB);
> +
> + spin_unlock(&dev_priv->wm.dsparb_lock);
> }
>
> #undef VLV_FIFO
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst
On Wed, 30 Nov 2016, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 05:00:55PM +, Robert Bragg wrote: >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> + :functions: i915_perf_init >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> + :functions: i915_perf_fini >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> + :functions: i915_perf_register >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> + :functions: i915_perf_unregister >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> + :functions: i915_perf_open_ioctl >> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c >> + :functions: i915_perf_release > > One potential issue with listing everything explicitly is that if someone > ever (and this is bound to happen) adds a new function, they'll forget to > add it. Hence we just pull them all in, and if you want to refernce some > specifically, do that in the overview sections. One real issue with listing everything separately is that kernel-doc parses the source file once per every kernel-doc directive. Also, doesn't Sphinx complain about not having a blank line to end the indented block after the directive? It might not, but I thought it might. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/4 v7] tests/drv_module_reload: Convert sh script to C version.
v5:
- reword gem_info to gem_sanitychecks (Chris Wilson)
- remove subgroups/subtests for gem_exec_store and gem_sanitycheck
(Chris Wilson)
v4:
- adjust test to make use of lib/igt_kmod
- replaced SW_FINISH with SET_CACHEING (Chris Wilson)
v3:
- fix passing boolean value as flags to igt_kmod_unload().
v2:
- embedded gem_alive and gem_exec_store into test (Chris Wilson)
- int main() to igt_main (Chris Wilson)
- moved tests/gem_alive -> tools/gem_info (Chris Wilson)
- added to intel-ci/fast-feedback.testlist (Petri Latvala)
- added hda_dynamic_debug() (Petri Latvala)
- renamed from tests/drv_module_reload_basic to tests/drv_module_reload
(all subtests are basic and have been added to fast-feedback.testlist)
Signed-off-by: Marius Vlad
---
tests/Makefile.am | 1 -
tests/Makefile.sources| 2 +-
tests/drv_module_reload.c | 332 ++
tests/drv_module_reload_basic | 111
tests/gem_alive.c | 35
tests/intel-ci/fast-feedback.testlist | 4 +-
tools/Makefile.sources| 1 +
tools/intel_gem_info.c| 35
8 files changed, 372 insertions(+), 149 deletions(-)
create mode 100644 tests/drv_module_reload.c
delete mode 100755 tests/drv_module_reload_basic
delete mode 100644 tests/gem_alive.c
create mode 100644 tools/intel_gem_info.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a408126..14a41ae 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -26,7 +26,6 @@ noinst_PROGRAMS = \
$(NULL)
pkglibexec_PROGRAMS = \
- gem_alive \
gem_stress \
$(TESTS_progs) \
$(TESTS_progs_M) \
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 65e0792..2d6ed8d 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -214,6 +214,7 @@ TESTS_progs = \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
+ drv_module_reload \
$(NULL)
# IMPORTANT: The ZZ_ tests need to be run last!
@@ -224,7 +225,6 @@ TESTS_scripts_M = \
TESTS_scripts = \
debugfs_emon_crash \
drv_debugfs_reader \
- drv_module_reload_basic \
kms_sysfs_edid_timing \
sysfs_l3_parity \
test_rte_check \
diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
new file mode 100644
index 000..31ec2ec
--- /dev/null
+++ b/tests/drv_module_reload.c
@@ -0,0 +1,332 @@
+/*
+ * Copyright © 2016 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.
+ */
+#include "igt.h"
+#include "igt_debugfs.h"
+#include "igt_aux.h"
+#include "igt_kmod.h"
+#include "igt_sysfs.h"
+#include "igt_core.h"
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define LOCAL_I915_EXEC_BSD_SHIFT (13)
+#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
+
+#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+
+static void store_dword(int fd, unsigned ring)
+{
+ const int gen = intel_gen(intel_get_drm_devid(fd));
+ struct drm_i915_gem_exec_object2 obj[2];
+ struct drm_i915_gem_relocation_entry reloc;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ uint32_t batch[16];
+ int i;
+
+ if (!gem_has_ring(fd, ring))
+ return;
+
+ if (gen == 6 && (ring & ~(3<<13)) == I915_EXEC_BSD)
+ return;
+
+ intel_detect_and_clear_missed_interrupts(fd);
+ memset(&execbuf, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = (uintptr_t)obj;
+ execbuf.buffer_count = 2;
+ execbuf.flags = ring;
+ if (gen < 6)
+ execbuf.flags |= I915_EXEC_SECURE;
+
+ memset(obj, 0, sizeof(obj));
+ obj[0].handle = gem_create(fd, 4096);
+ obj[1].handle = gem_create(fd, 4096);
+
+ memset(&reloc, 0, sizeof(reloc));
+ rel
[Intel-gfx] [PATCH i-g-t 0/4 v7] Convert sh scripts to C variants.
Latest changes include addressing comments from previous version and include
some notes about driver loading/unloading when using in combination to
drm_open_driver().
This series adds some library support to help converting sh scripts to C
version. Based on that I've converted drv_module_reload_basic and
kms_sysfs_edid_timing. Other tests should follow. drv_module_reload requires
the most boilerplate code.
The reason for so many changes is the fact that some code got moved so other
users can use it. Secondly wrappers around libkmod in lib/igt_kmod and procps
in lib/igt_aux. Thirdly drv_module_reload has embedded tools/gem_info and
tests/gem_exec_store in it, with minor modifications to allow running them as
subtests. Finally, C is more verbose than sh.
Changes since v6:
- addressed comments (Chris Wilson)
- document the fact that driver loading/unloading used in combination with
drm_open_driver() would fail
- print also opened fd from /dev/dri in case driver unloading fails
- minor changes to igt_lsof()
Changes since v5:
- new helper in lib/igt_aux to display info about opened files by processes
and a new function to show a list of loaded modules (Petri Latvala)
Changes since v4:
- rebased to include unbinding snd_hda_intel
- added igt_i915_driver_load/unload so it can used in lib/igt_gvt
and tests/drv_module_reload (Cris Wilson)
- do not hard fail when loading/reloading in lib/igt_gvt (Chris Wilson)
- remove subgroups in tests/drv_module_reload (Chris Wilson)
- make tests/kms_sysfs_edid_timing intel-agnostic when searching
for connectors and use igt_mean (Chris Wilson)
Changes since v3:
- lib/igt_kmod: added libkmod helpers into their own file. There seems to be
another user for it: lib/igt_gvt. Fixed a issue with lib/igt_gvt while at
it and converted to make use of lib/igt_kmod.
- lib/{igt_kmod, igt_aux}: Fixed gtk-doc documentation formatting (Daniel
Vetter)
- tests/drv_module_reload: Re-worked reload() method by splitting into
load() and unload() and asserting more.
- replaced SW_FINISH with SET_CACHEING in tests/drv_module_reload (Chris Wilson)
Changes since v2:
- lib/igt_aux: Addressed comments from Chris Wilson
- tests/drv_module_reload: Passed incorrectly boolean instead of uint as flags
to
igt_kmod_unload().
Changes since v1:
- lib/igt_aux: Addressed comments from Chris Wilson
- tests/drv_module_reload: Addressed comments from Chris Wilson and Petri
Latvala
- tests/kms_sysfs_edid_timing: Addressed comments from Chris Wilson
- (Hopefully): Addressed comments from Jani Nikula.
Marius Vlad (4):
lib/igt_kmod: New library to support driver loading/unloading and
additional helpers.
lib/igt_gvt: Make use of libkmod helpers and fix reading gvt
parameter.
tests/drv_module_reload: Convert sh script to C version.
tests/kms_sysfs_edid_timing: Convert sh to C version.
configure.ac | 2 +
.../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 +
lib/Makefile.am| 5 +-
lib/Makefile.sources | 2 +
lib/igt_aux.c | 260
lib/igt_aux.h | 3 +
lib/igt_gvt.c | 78 ++---
lib/igt_kmod.c | 328
lib/igt_kmod.h | 39 +++
lib/igt_sysfs.c| 106 +++
lib/igt_sysfs.h| 3 +
tests/Makefile.am | 1 -
tests/Makefile.sources | 4 +-
tests/drv_module_reload.c | 332 +
tests/drv_module_reload_basic | 111 ---
tests/gem_alive.c | 35 ---
tests/gvt_basic.c | 2 +-
tests/intel-ci/fast-feedback.testlist | 4 +-
tests/kms_sysfs_edid_timing| 25 --
tests/kms_sysfs_edid_timing.c | 97 ++
tools/Makefile.sources | 1 +
tools/intel_gem_info.c | 35 +++
22 files changed, 1238 insertions(+), 236 deletions(-)
create mode 100644 lib/igt_kmod.c
create mode 100644 lib/igt_kmod.h
create mode 100644 tests/drv_module_reload.c
delete mode 100755 tests/drv_module_reload_basic
delete mode 100644 tests/gem_alive.c
delete mode 100755 tests/kms_sysfs_edid_timing
create mode 100644 tests/kms_sysfs_edid_timing.c
create mode 100644 tools/intel_gem_info.c
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/4 v7] lib/igt_kmod: New library to support driver loading/unloading and additional helpers.
lib/igt_aux: Added igt_pkill and igt_lsof helper.
lib/igt_kmod: Added load/unload kmod helpers.
v7:
- document the case where leaving stray fd from drm_open_driver()
might fail reloading the driver.
- list also current opened files from /dev/dri in case we could not
unload the driver.
- convert igt_info to igt_warn (Chris Wilson)
- added KMOD_|PROCPS CFLAGS (Chris Wilson)
v6:
- include latest modifications from tests/drv_module_reload:
display all loaded modules and list information about opened
files by processes (Petri Latvala)
v5:
- added igt_i915_driver_{load/unload}.
- added kick_snd_hda_intel() to match current
tests/drv_module_reload_basic and integrated into
igt_i915_driver_load/unload.
- added gtk-doc section for lib/igt_kmod
v4:
- decided to split libkmod helpers into their own file as there's
another user lib/igt_gvt or tests/gvt_basic.
- fixed some gtk-doc documentation.
v3:
- return -errno (igt_pkill()) in case of failure (Cris Wilson)
- return bool for igt_kmod_is_loaded(), replaced strncasecmp with strncmp
(Chris Wilson)
- use igt_debug() instead of igt_info() for igt_kmod_load()/
igt_kmod_unload() and return -err directly from libkmod (Chris Wilson)
v2:
- Renamed libkmod helpers (Chris Wilson)
- Removed SIGTERM/SIGKILL case where we repeatedly tried to terminate the
process: just call kill(2) once (Chris Wilson)
- Removed redundant check in igt_kmod_unload(), igt_module_in_use() (Chris
Wilson)
- Pass flags to igt_kmod_unload() from the caller (Chris Wilson)
- Removed useless function igt_kill() which acts just as kill(2) (Chris
Wilson)
Signed-off-by: Marius Vlad
---
configure.ac | 2 +
.../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 +
lib/Makefile.am| 5 +-
lib/Makefile.sources | 2 +
lib/igt_aux.c | 260
lib/igt_aux.h | 3 +
lib/igt_gvt.c | 43 +--
lib/igt_kmod.c | 328 +
lib/igt_kmod.h | 39 +++
lib/igt_sysfs.c| 106 +++
lib/igt_sysfs.h| 3 +
11 files changed, 750 insertions(+), 42 deletions(-)
create mode 100644 lib/igt_kmod.c
create mode 100644 lib/igt_kmod.h
diff --git a/configure.ac b/configure.ac
index e181c83..cba312f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -121,6 +121,8 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
PKG_CHECK_MODULES(DRM, [libdrm])
PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
+PKG_CHECK_MODULES(KMOD, [libkmod])
+PKG_CHECK_MODULES(PROCPS, [libprocps])
case "$target_cpu" in
x86*|i?86)
diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index c862f2a..39061a8 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -22,6 +22,7 @@
+
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 4c0893d..5eec207 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -23,7 +23,8 @@ if !HAVE_LIBDRM_INTEL
endif
AM_CPPFLAGS = -I$(top_srcdir)
-AM_CFLAGS = $(CWARNFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS)
$(LIBUNWIND_CFLAGS) $(DEBUG_CFLAGS) \
+AM_CFLAGS = $(CWARNFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS)
$(LIBUNWIND_CFLAGS) \
+ $(DEBUG_CFLAGS) $(KMOD_CFLAGS) $(PROCPS_CFLAGS) \
-DIGT_SRCDIR=\""$(abs_top_srcdir)/tests"\" \
-DIGT_DATADIR=\""$(pkgdatadir)"\" \
-DIGT_LOG_DOMAIN=\""$(subst _,-,$*)"\" \
@@ -34,6 +35,8 @@ AM_CFLAGS += $(CAIRO_CFLAGS)
libintel_tools_la_LIBADD = \
$(DRM_LIBS) \
$(PCIACCESS_LIBS) \
+ $(PROCPS_LIBS) \
+ $(KMOD_LIBS) \
$(CAIRO_LIBS) \
$(LIBUDEV_LIBS) \
$(LIBUNWIND_LIBS) \
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index e8e277b..2205c86 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -77,6 +77,8 @@ lib_source_list = \
igt_pm.h\
uwildmat/uwildmat.h \
uwildmat/uwildmat.c \
+ igt_kmod.c \
+ igt_kmod.h \
$(NULL)
.PHONY: version.h.tmp
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 421f6d4..a4ac44b 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -51,6 +51,8 @@
#include
#include
+#include
+
#include "drmtest.h"
#include "i915_drm.h"
#include "intel_chipset.h"
@@ -65,6 +67,10 @@
#include "igt_stats.h"
#include "igt_sysfs.h"
+#ifdef HAVE_LIBGEN_H
+#include/* for dirname() */
+#endif
+
/**
* SECTION:igt_aux
* @short_description: Auxiliary libraries and support functions
@@ -1193,6 +1199,260 @@ void igt_set_module_param_int(const char *name, int val)
igt_set_module_param(name,
[Intel-gfx] [PATCH i-g-t 2/4 v7] lib/igt_gvt: Make use of libkmod helpers and fix reading gvt parameter.
v2:
- use igt_sysfs_get_boolean() to get gvt status (Chris Wilson)
- do not hard-fail when i915 module could not be loaded/unloaded (Chris
Wilson)
Signed-off-by: Marius Vlad
---
lib/igt_gvt.c | 37 ++---
tests/gvt_basic.c | 2 +-
2 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/lib/igt_gvt.c b/lib/igt_gvt.c
index 8bbf9bd..4ab7433 100644
--- a/lib/igt_gvt.c
+++ b/lib/igt_gvt.c
@@ -24,35 +24,30 @@
#include "igt.h"
#include "igt_gvt.h"
#include "igt_sysfs.h"
+#include "igt_kmod.h"
+#include
#include
#include
#include
static bool is_gvt_enabled(void)
{
- FILE *file;
- int value;
bool enabled = false;
+ int dir, fd;
- file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
- if (!file)
+ fd = __drm_open_driver(DRIVER_INTEL);
+ dir = igt_sysfs_open_parameters(fd);
+ if (dir < 0)
return false;
- if (fscanf(file, "%d", &value) == 1)
- enabled = value;
- fclose(file);
+ enabled = igt_sysfs_get_boolean(dir, "enable_gvt");
- errno = 0;
- return enabled;
-}
+ close(dir);
+ close(fd);
-static void unload_i915(void)
-{
- kick_fbcon(false);
- /* pkill alsact */
+ return enabled;
- igt_ignore_warn(system("/sbin/modprobe -s -r i915"));
}
bool igt_gvt_load_module(void)
@@ -60,8 +55,11 @@ bool igt_gvt_load_module(void)
if (is_gvt_enabled())
return true;
- unload_i915();
- igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=1"));
+ if (igt_i915_driver_unload())
+ return false;
+
+ if (igt_i915_driver_load("enable_gvt=1"))
+ return false;
return is_gvt_enabled();
}
@@ -71,8 +69,9 @@ void igt_gvt_unload_module(void)
if (!is_gvt_enabled())
return;
- unload_i915();
- igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=0"));
+ igt_i915_driver_unload();
+
+ igt_i915_driver_load(NULL);
igt_assert(!is_gvt_enabled());
}
diff --git a/tests/gvt_basic.c b/tests/gvt_basic.c
index 48b853a..4e909a5 100644
--- a/tests/gvt_basic.c
+++ b/tests/gvt_basic.c
@@ -32,7 +32,7 @@ igt_main
igt_fixture {
igt_require(igt_gvt_load_module());
- fd = drm_open_driver(DRIVER_INTEL);
+ fd = __drm_open_driver(DRIVER_INTEL);
}
igt_subtest_f("invalid-placeholder-test");
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/4 v7] tests/kms_sysfs_edid_timing: Convert sh to C version.
The debug output for a HSW machine with two connectors (VGA and HDMI):
DEBUG: card0-VGA-1: mean.max 12896229,00ns, 12896,23us, 12,90ms, mean.avg
12785055,80ns, 12785,06us, 12,79ms
WARNING: card0-VGA-1: probe time exceed 10ms, max=12,90ms, avg=12,79ms
DEBUG: card0-HDMI-A-1: mean.max 781433,00ns, 781,43us, 0,78ms, mean.avg
706643,20ns, 706,64us, 0,71ms
v4:
- do not include the time opening the fd (Chris Wilson)
- include output from debug (Chris Wilson)
v3:
- use igt_mean for accounting (Chris Wilson)
- make it Intel-agnostic when searching for connectors (Chris Wilson)
v2:
- don't read cached values (Chris Wilson)
- warn on per connector, and fail per mean (Chris Wilson)
These are synthetic: 10ms per connector, and 50ms for all.
Signed-off-by: Marius Vlad
---
tests/Makefile.sources| 2 +-
tests/kms_sysfs_edid_timing | 25 ---
tests/kms_sysfs_edid_timing.c | 97 +++
3 files changed, 98 insertions(+), 26 deletions(-)
delete mode 100755 tests/kms_sysfs_edid_timing
create mode 100644 tests/kms_sysfs_edid_timing.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2d6ed8d..f835726 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -215,6 +215,7 @@ TESTS_progs = \
kms_sink_crc_basic \
prime_udl \
drv_module_reload \
+ kms_sysfs_edid_timing \
$(NULL)
# IMPORTANT: The ZZ_ tests need to be run last!
@@ -225,7 +226,6 @@ TESTS_scripts_M = \
TESTS_scripts = \
debugfs_emon_crash \
drv_debugfs_reader \
- kms_sysfs_edid_timing \
sysfs_l3_parity \
test_rte_check \
tools_test \
diff --git a/tests/kms_sysfs_edid_timing b/tests/kms_sysfs_edid_timing
deleted file mode 100755
index 46ea540..000
--- a/tests/kms_sysfs_edid_timing
+++ /dev/null
@@ -1,25 +0,0 @@
-#!/bin/bash
-#
-# This check the time we take to read the content of all the possible
connectors.
-# Without the edid -ENXIO patch
(http://permalink.gmane.org/gmane.comp.video.dri.devel/62083),
-# we sometimes take a *really* long time. So let's just check for some
reasonable timing here
-#
-
-DRM_LIB_ALLOW_NO_MASTER=1
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-TIME1=$(date +%s%N)
-cat $(find /sys/devices/|grep drm | grep /status) > /dev/null
-TIME2=$(date +%s%N)
-
-# time in ms
-RES=$(((TIME2 - TIME1) / 100))
-
-if [ $RES -gt 600 ]; then
- echo "Talking to outputs took ${RES}ms, something is wrong"
- exit $IGT_EXIT_FAILURE
-fi
-
-exit $IGT_EXIT_SUCCESS
diff --git a/tests/kms_sysfs_edid_timing.c b/tests/kms_sysfs_edid_timing.c
new file mode 100644
index 000..1201388
--- /dev/null
+++ b/tests/kms_sysfs_edid_timing.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright © 2016 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.
+ */
+#include "igt.h"
+
+#include
+#include
+#include
+
+#define THRESHOLD_PER_CONNECTOR10
+#define THRESHOLD_TOTAL50
+#define CHECK_TIMES15
+
+IGT_TEST_DESCRIPTION("This check the time we take to read the content of all "
+"the possible connectors. Without the edid -ENXIO patch "
+
"(http://permalink.gmane.org/gmane.comp.video.dri.devel/62083), "
+"we sometimes take a *really* long time. "
+"So let's just check for some reasonable timing here");
+
+
+igt_simple_main
+{
+ DIR *dirp;
+ struct dirent *de;
+
+ dirp = opendir("/sys/class/drm");
+ igt_assert(dirp != NULL);
+
+ while ((de = readdir(dirp))) {
+ struct igt_mean mean = {};
+ struct stat st;
+ char path[PATH_MAX];
+ int i;
+
+ if (*de->d_name == '.')
+ continue;;
+
+ snprintf(path, sizeof(path), "/sys/class/drm/%s/status",
+
Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC
On Wed, Nov 30, 2016 at 03:31:28PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> HuC firmware css header has almost exactly same definition as GuC
> firmware except for the sw_version. Also, add a new member fw_type
> into intel_uc_fw to indicate what kind of fw it is. So, the loader
> will pull right sw_version from header.
>
> v2: rebased on-top of drm-intel-nightly
> v3: rebased on-top of drm-intel-nightly (again).
> v4: rebased + spaces.
> v7: rebased.
> v8: rebased.
> v9: rebased. Rename device_id to guc_branch_client_version,
> make guc_sw_version a union. . Put UC_FW_TYPE_GUC
> and UC_FW_TYPE_HUC into an enum.
> v10: rebased.
> v11: rebased.
> v12: rebased on top of drm-tip.
>
> Tested-by: Xiang Haihao
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Alex Dai
> Signed-off-by: Peter Antoine
> Reviewed-by: Dave Gordon
> Reviewed-by: Jeff McGee
> ---
> drivers/gpu/drm/i915/intel_guc_fwif.h | 21 +
> drivers/gpu/drm/i915/intel_guc_loader.c | 41
> ++---
> drivers/gpu/drm/i915/intel_uc.h | 5
> 3 files changed, 50 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index 00ca0df..c07d9da 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -154,7 +154,7 @@
> * The GuC firmware layout looks like this:
> *
> * +---+
> - * |guc_css_header |
> + * | uc_css_header |
> * | |
> * | contains major/minor version |
> * +---+
> @@ -181,9 +181,16 @@
> * 3. Length info of each component can be found in header, in dwords.
> * 4. Modulus and exponent key are not required by driver. They may not
> appear
> *in fw. So driver will load a truncated firmware in this case.
> + *
> + * HuC firmware layout is same as GuC firmware.
> + *
> + * HuC firmware css header is different. However, the only difference is
> where
> + * the version information is saved. The uc_css_header is unified to support
> + * both. Driver should get HuC version from uc_css_header.huc_sw_version,
> while
> + * uc_css_header.guc_sw_version for GuC.
> */
>
> -struct guc_css_header {
> +struct uc_css_header {
I think we should either move most of this stuff to intel_uc.{c,h} or
rename the file to intel_uc_fwif.h.
Anyway, this file contains information on top that this is automatically
generated and your changes might be lost...
The file was introduced and then *manually edited* *multiple times* by
*many people*, without any signs of changes lost or file being
regenerated.
I think we can, at least, drop the warning. I am in favor of drooping
the file completely though.
If something would change, we can assume it would be done by hand anyway.
Jeff, Sagar: any thought on that?
> uint32_t module_type;
> /* header_size includes all non-uCode bits, including css_header, rsa
>* key, modulus key and exponent data. */
> @@ -214,8 +221,14 @@ struct guc_css_header {
>
> char username[8];
> char buildnumber[12];
> - uint32_t device_id;
> - uint32_t guc_sw_version;
> + union {
> + uint32_t guc_branch_client_version;
> + uint32_t huc_sw_version;
> + };
> + union {
> + uint32_t guc_sw_version;
> + uint32_t huc_reserved;
> + };
> uint32_t prod_preprod_fw;
> uint32_t reserved[12];
> uint32_t header_info;
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index e55ec2c..557d4b4 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -593,7 +593,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct
> intel_uc_fw *uc_fw)
> struct pci_dev *pdev = dev->pdev;
> struct drm_i915_gem_object *obj;
> const struct firmware *fw = NULL;
> - struct guc_css_header *css;
> + struct uc_css_header *css;
> size_t size;
> int err;
>
> @@ -610,19 +610,19 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct
> intel_uc_fw *uc_fw)
> uc_fw->uc_fw_path, fw);
>
> /* Check the size of the blob before examining buffer contents */
> - if (fw->size < sizeof(struct guc_css_header)) {
> + if (fw->size < sizeof(struct uc_css_header)) {
> DRM_NOTE("Firmware header is missing\n");
> goto fail;
> }
>
> - css = (struct guc_css_header *)fw->data;
> + css = (struct uc_css_header *)fw->data;
>
> /* Firmware bits always start from header */
> uc_fw->header_offset = 0;
> uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
> css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
>
> - if (uc_fw->header_size != sizeof(struct guc
Re: [Intel-gfx] [PATCH v3 11/14] HACK drm/i915/scheduler: emulate a scheduler for guc
On 01/12/2016 11:18, Chris Wilson wrote:
On Thu, Dec 01, 2016 at 10:45:51AM +, Tvrtko Ursulin wrote:
On 14/11/2016 08:57, Chris Wilson wrote:
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).
As it is starting to sink in we'll have to do add this hack sooner
or later, review comments below.
Also, would you be OK to rebase this or would prefer to delegate it?
It's been very easy to keep it current.
@@ -665,6 +665,70 @@ static void i915_guc_submit(struct drm_i915_gem_request
*rq)
spin_unlock(&client->wq_lock);
}
Confused me at first here until I noticed engine->submit_request
will be the execlist_submit_request later. Perhaps it would be good
to rename a lot of things now, like engine->request_queue,
intel_engine_submit_request and maybe more?
Looking at the lifecycle of the request and getting clear names for the
phases and their vfuncs would be sensible. It may also be worthwhile to
decide that some are not engine tasks and belong to a new entity
(dev_priv->gt.X ?)
Like submit_request? Makes sense yes.
+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
+{
+ struct execlist_port *port = engine->execlist_port;
+ struct drm_i915_gem_request *last = port[0].request;
+ unsigned long flags;
+ struct rb_node *rb;
+ bool submit = false;
+
+ spin_lock_irqsave(&engine->timeline->lock, flags);
+ rb = engine->execlist_first;
+ while (rb) {
+ struct drm_i915_gem_request *cursor =
+ rb_entry(rb, typeof(*cursor), priotree.node);
+
+ if (last && cursor->ctx != last->ctx) {
Not sure if GVT comes into the picture here, but it does not sounds
like it would harm to use can_merge_ctx here?
I wasn't sure what path GVT would take either. So just went with the
simple version that looked as similar to the current guc submission as
possible. Also offloading the scheduling to the guc via semaphores will
likely make this whole chain look completely different.
Hmm I am not up to speed with that. So you are saying it doesn't make
sense to unify this?
+ if (port != engine->execlist_port)
+ break;
It may be an overkill for the first version, but I was thinking that
we don't have to limit it to two at a time. And it would depend on
measuring of course. But perhaps it would make sense to do the
generalisation of the number of supported ports straight away.
Definitely. I was just looking at a minimal conversion, hence reusing
the existing tracking, and limits.
Definitely leave it for later, or definitely it makes sense to
generalise right now? I was just thinking that when someone goes to test
this and finds the throughput regresses, that it might be easier to just
say please try i915.guc_submit_ports=8 or something.
We could theoretically share most of the execlist_dequeue and just
do a couple things differently depending on the mode.
Yes, there were just a couple of intrusive warts that I felt justified
in keeping the routines separate. But mostly it was the merge_ctx
decision that looked to be backend specific.
Cool.
Looks like one could be a new engine->submit_ports vfunc. And there
is also the lite restore WA and sw signalling to design in nicely,
but it may be worth sharing the code. It would be renamed to
sometihng like scheduler_dequeue or something.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index cb8a75f6ca16..18dce4c66d56 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1341,8 +1341,10 @@ static void snb_gt_irq_handler(struct drm_i915_private
*dev_priv,
static __always_inline void
gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int test_shift)
{
- if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
+ if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
+ tasklet_schedule(&engine->irq_tasklet);
This would be better made conditional on GuC submission just to
calling tasklet_schedule twice (occasionally) in execlist mode.
It's not a huge cost if we do schedule the tasklet twice (in the same
interrupt context at least). Otherwise, yes we are incurring more mmio
reads to determine that the CSB didn't advance. On the other hand, I
really don't want to have if (i915.enable_guc_submission) here. Maybe
if (engine->user_irq_tasklet) tasklet_schedule(engine->user_irq_tasklet)
?
Hm, I don't know. One conditional plus a redundant engine struct member
or just one conditional. Maybe dev_priv->gt.handle_user_interrupt and
dev_priv->gt.handle_ctx_switch_interrupt? You won't like the indirection
I am sure
[Intel-gfx] [PATCH v3] drm/i915: replace platform flags with a platform enum
The platform flags in device info are (mostly) mutually
exclusive. Replace the flags with an enum. Add the platform enum also
for platforms that previously didn't have a flag, and give them codename
logging in dmesg.
Pineview remains an exception, the platform being G33 for that.
v2: Sort enum by gen and date
v3: rebase on geminilake enabling
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 80 +++-
drivers/gpu/drm/i915/i915_gpu_error.c| 1 +
drivers/gpu/drm/i915/i915_pci.c | 57 +--
drivers/gpu/drm/i915/intel_device_info.c | 41 +++-
5 files changed, 122 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2434130087be..15fb97dd9ed3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -77,6 +77,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
const struct intel_device_info *info = INTEL_INFO(dev_priv);
seq_printf(m, "gen: %d\n", INTEL_GEN(dev_priv));
+ seq_printf(m, "platform: %s\n", intel_platform_name(info->platform));
seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev_priv));
#define PRINT_FLAG(x) seq_printf(m, #x ": %s\n", yesno(info->x))
DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 34f2b0da6a81..7fd0279af635 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -686,25 +686,8 @@ struct intel_csr {
};
#define DEV_INFO_FOR_EACH_FLAG(func) \
- /* Keep is_* in chronological order */ \
func(is_mobile); \
- func(is_i85x); \
- func(is_i915g); \
- func(is_i945gm); \
- func(is_g33); \
- func(is_g4x); \
func(is_pineview); \
- func(is_broadwater); \
- func(is_crestline); \
- func(is_ivybridge); \
- func(is_valleyview); \
- func(is_cherryview); \
- func(is_haswell); \
- func(is_broadwell); \
- func(is_skylake); \
- func(is_broxton); \
- func(is_geminilake); \
- func(is_kabylake); \
func(is_lp); \
func(is_alpha_support); \
/* Keep has_* in alphabetical order */ \
@@ -755,6 +738,35 @@ static inline unsigned int sseu_subslice_total(const
struct sseu_dev_info *sseu)
return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
}
+/* Keep in gen based order, and chronological order within a gen */
+enum intel_platform {
+ INTEL_PLATFORM_UNINITIALIZED = 0,
+ INTEL_I830,
+ INTEL_I845G,
+ INTEL_I85X,
+ INTEL_I865G,
+ INTEL_I915G,
+ INTEL_I915GM,
+ INTEL_I945G,
+ INTEL_I945GM,
+ INTEL_G33,
+ INTEL_PINEVIEW,
+ INTEL_BROADWATER,
+ INTEL_CRESTLINE,
+ INTEL_G4X,
+ INTEL_IRONLAKE,
+ INTEL_SANDYBRIDGE,
+ INTEL_IVYBRIDGE,
+ INTEL_VALLEYVIEW,
+ INTEL_HASWELL,
+ INTEL_BROADWELL,
+ INTEL_CHERRYVIEW,
+ INTEL_SKYLAKE,
+ INTEL_BROXTON,
+ INTEL_KABYLAKE,
+ INTEL_GEMINILAKE,
+};
+
struct intel_device_info {
u32 display_mmio_offset;
u16 device_id;
@@ -762,6 +774,7 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u16 gen_mask;
+ enum intel_platform platform;
u8 ring_mask; /* Rings supported by the HW */
u8 num_rings;
#define DEFINE_FLAG(name) u8 name:1
@@ -2499,33 +2512,33 @@ intel_info(const struct drm_i915_private *dev_priv)
#define IS_I830(dev_priv) (INTEL_DEVID(dev_priv) == 0x3577)
#define IS_845G(dev_priv) (INTEL_DEVID(dev_priv) == 0x2562)
-#define IS_I85X(dev_priv) ((dev_priv)->info.is_i85x)
+#define IS_I85X(dev_priv) ((dev_priv)->info.platform == INTEL_I85X)
#define IS_I865G(dev_priv) (INTEL_DEVID(dev_priv) == 0x2572)
-#define IS_I915G(dev_priv) ((dev_priv)->info.is_i915g)
+#define IS_I915G(dev_priv) ((dev_priv)->info.platform == INTEL_I915G)
#define IS_I915GM(dev_priv)(INTEL_DEVID(dev_priv) == 0x2592)
#define IS_I945G(dev_priv) (INTEL_DEVID(dev_priv) == 0x2772)
-#define IS_I945GM(dev_priv)((dev_priv)->info.is_i945gm)
-#define IS_BROADWATER(dev_priv)((dev_priv)->info.is_broadwater)
-#define IS_CRESTLINE(dev_priv) ((dev_priv)->info.is_crestline)
+#define IS_I945GM(dev_priv)((dev_priv)->info.platform == INTEL_I945GM)
+#define IS_BROADWATER(dev_priv)((dev_priv)->info.platform ==
INTEL_BROADWATER)
+#define IS_CRESTLINE(dev_priv) ((dev_priv)->info.platform == INTEL_CRESTLINE)
#define IS_GM45(dev_priv) (INTEL_DEVID(dev_priv) == 0x2A42)
-#define IS_G4X(dev_priv) ((dev_priv)->info.is_g4x)
+#define IS_G4X(dev_priv) ((dev_priv)->info.platform == INTEL_G4X)
#define IS_PINEVIEW_G(dev_priv)(INTEL_DEVID(dev_priv) == 0xa001)
#define IS
Re: [Intel-gfx] [PATCH v3 11/14] HACK drm/i915/scheduler: emulate a scheduler for guc
On Thu, Dec 01, 2016 at 12:45:18PM +, Tvrtko Ursulin wrote:
>
> On 01/12/2016 11:18, Chris Wilson wrote:
> >On Thu, Dec 01, 2016 at 10:45:51AM +, Tvrtko Ursulin wrote:
> >>
> >>On 14/11/2016 08:57, Chris Wilson wrote:
> >>>+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
> >>>+{
> >>>+ struct execlist_port *port = engine->execlist_port;
> >>>+ struct drm_i915_gem_request *last = port[0].request;
> >>>+ unsigned long flags;
> >>>+ struct rb_node *rb;
> >>>+ bool submit = false;
> >>>+
> >>>+ spin_lock_irqsave(&engine->timeline->lock, flags);
> >>>+ rb = engine->execlist_first;
> >>>+ while (rb) {
> >>>+ struct drm_i915_gem_request *cursor =
> >>>+ rb_entry(rb, typeof(*cursor), priotree.node);
> >>>+
> >>>+ if (last && cursor->ctx != last->ctx) {
> >>
> >>Not sure if GVT comes into the picture here, but it does not sounds
> >>like it would harm to use can_merge_ctx here?
> >
> >I wasn't sure what path GVT would take either. So just went with the
> >simple version that looked as similar to the current guc submission as
> >possible. Also offloading the scheduling to the guc via semaphores will
> >likely make this whole chain look completely different.
>
> Hmm I am not up to speed with that. So you are saying it doesn't
> make sense to unify this?
Just not sure yet. Too much duplication, too much engineering are both
traps we may make for ourselves.
> >>>+ if (port != engine->execlist_port)
> >>>+ break;
> >>
> >>It may be an overkill for the first version, but I was thinking that
> >>we don't have to limit it to two at a time. And it would depend on
> >>measuring of course. But perhaps it would make sense to do the
> >>generalisation of the number of supported ports straight away.
> >
> >Definitely. I was just looking at a minimal conversion, hence reusing
> >the existing tracking, and limits.
>
> Definitely leave it for later, or definitely it makes sense to
> generalise right now? I was just thinking that when someone goes to
> test this and finds the throughput regresses, that it might be
> easier to just say please try i915.guc_submit_ports=8 or something.
It was "definitely not worth it in this patch and definitely makes sense
to investigate". Very rapid diminishing returns, it comes down to how
many requests will complete in the service time of the first irq. You'll
be looking at the no-op switching workloads that stress the driver,
rather than the actual workloads that stress the system. The cheapest
typical ping-pong is GL client -> display server -> GL client, though
OpenCL may beat that, but for that GL sequence, 3 ports would easily
cover us. [1 active, 2 pending slots really.]
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication
On Wed, Nov 30, 2016 at 03:31:33PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
>
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: rebased on top of drm-intel-nightly.
> v4: changed wait_for_automic to wait_for
> v5: rebased.
> v7: rebased.
> v8: rebased.
> v9: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
> and place the prototype in intel_guc.h,correct the comments.
> v10: rebased.
> v11: rebased.
> v12: rebased on top of drm-tip
>
> Tested-by: Xiang Haihao
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Alex Dai
> Signed-off-by: Peter Antoine
> Reviewed-by: Dave Gordon
> Reviewed-by: Jeff McGee
> ---
> drivers/gpu/drm/i915/i915_guc_submission.c | 63
> ++
> drivers/gpu/drm/i915/intel_guc_fwif.h | 1 +
> drivers/gpu/drm/i915/intel_guc_loader.c| 2 +
> 3 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 4bae8e4..d5c205d 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -26,6 +26,7 @@
> #include
> #include "i915_drv.h"
> #include "intel_uc.h"
> +#include "intel_huc.h"
>
> /**
> * DOC: GuC-based command submission
> @@ -1638,3 +1639,65 @@ int i915_guc_log_control(struct drm_i915_private
> *dev_priv, u64 control_val)
>
> return ret;
> }
> +
> +/**
> + * intel_guc_auth_huc() - authenticate ucode
> + * @dev: the drm device
> + *
> + * Triggers a HuC fw authentication request to the GuC via host-2-guc
> + * interface.
> + */
> +void intel_guc_auth_huc(struct drm_device *dev)
This should belong to intel_uc.c
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_guc *guc = &dev_priv->guc;
> + struct intel_huc *huc = &dev_priv->huc;
> + struct i915_vma *vma;
> + int ret;
> + u32 data[2];
> +
> + /* Bypass the case where there is no HuC firmware */
> + if (huc->huc_fw.fetch_status == UC_FIRMWARE_NONE ||
> + huc->huc_fw.load_status == UC_FIRMWARE_NONE)
> + return;
> +
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) {
> + DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate");
> + return;
> + }
> +
> + if (huc->huc_fw.load_status != UC_FIRMWARE_SUCCESS) {
> + DRM_ERROR("HuC: fw wasn't loaded. Nothing to authenticate");
> + return;
> + }
> +
> + vma = i915_gem_object_ggtt_pin(huc->huc_fw.uc_fw_obj, NULL, 0, 0, 0);
> + if (IS_ERR(vma)) {
> + DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma));
> + return;
> + }
> +
> +
> + /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
> + I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> +
> + /* Specify auth action and where public signature is. */
> + data[0] = HOST2GUC_ACTION_AUTHENTICATE_HUC;
s/HOST2GUC/INTEL_GUC/
> + data[1] = i915_ggtt_offset(vma) + huc->huc_fw.rsa_offset;
> +
> + ret = host2guc_action(guc, data, ARRAY_SIZE(data));
s/host2guc_action/intel_guc_send/
> + if (ret) {
> + DRM_ERROR("HuC: GuC did not ack Auth request\n");
> + goto out;
> + }
> +
> + /* Check authentication status, it should be done by now */
> + ret = wait_for((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) > 0, 50);
> + if (ret) {
> + DRM_ERROR("HuC: Authentication failed\n");
> + goto out;
> + }
> +
> +out:
> + i915_vma_unpin(vma);
> +}
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index c07d9da..e51e063 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -513,6 +513,7 @@ enum intel_guc_action {
> INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
> INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
> INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
> + HOST2GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
s/HOST2GUC/INTEL_GUC/
> INTEL_GUC_ACTION_LIMIT
> };
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 7ca5556..31d09f8 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -529,6 +529,8 @@ int intel_guc_setup(struct drm_device *dev)
> intel_uc_fw_status_repr(guc_fw->fetch_status),
> intel_uc_fw_status_repr(guc_fw->load_status));
>
> + intel_guc_auth_huc(dev);
> +
You do not have this symbol declared in any header, it's not visible in
this compilation unit.
> if (i915.enable_guc_submission) {
> if (i915.guc_log_level >= 0)
> gen9_enable_guc_interrupts(dev_priv);
> --
> 2.7.4
>
> ___
Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams
On Wed, Nov 30, 2016 at 03:31:34PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to be validated by the GuC this patch uses the validated
> status to show when the HuC is loaded and ready for use. You cannot use
> the loaded status as with the GuC as the HuC is verified after it is
> loaded and is not usable until it is verified.
>
> v2: removed the forewakes as the registers are already force-woken.
> (T.Ursulin)
> v4: rebased.
> v5: rebased on top of drm-tip.
>
> Signed-off-by: Peter Antoine
Reviewed-by: Arkadiusz Hiler
> ---
> drivers/gpu/drm/i915/i915_drv.c | 5 +
> drivers/gpu/drm/i915/intel_huc.h| 1 +
> drivers/gpu/drm/i915/intel_huc_loader.c | 12
> include/uapi/drm/i915_drm.h | 1 +
> 4 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 075d9ce..75a3e24 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -49,6 +49,8 @@
> #include "i915_trace.h"
> #include "i915_vgpu.h"
> #include "intel_drv.h"
> +#include "intel_uc.h"
> +#include "intel_huc.h"
>
> static struct drm_driver driver;
>
> @@ -350,6 +352,9 @@ static int i915_getparam(struct drm_device *dev, void
> *data,
>*/
> value = 1;
> break;
> + case I915_PARAM_HAS_HUC:
> + value = intel_is_huc_valid(dev_priv);
> + break;
> default:
> DRM_DEBUG("Unknown parameter %d\n", param->param);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/i915/intel_huc.h
> b/drivers/gpu/drm/i915/intel_huc.h
> index 1dd18c5..1b67311 100644
> --- a/drivers/gpu/drm/i915/intel_huc.h
> +++ b/drivers/gpu/drm/i915/intel_huc.h
> @@ -39,4 +39,5 @@ struct intel_huc {
> void intel_huc_init(struct drm_device *dev);
> void intel_huc_fini(struct drm_device *dev);
> int intel_huc_load(struct drm_device *dev);
> +int intel_is_huc_valid(struct drm_i915_private *dev_priv);
> #endif
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 20526a4..e18de0f6 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -292,3 +292,15 @@ void intel_huc_fini(struct drm_device *dev)
> huc_fw->fetch_status = UC_FIRMWARE_NONE;
> }
>
> +/**
> + * intel_is_huc_valid() - Check to see if the HuC is fully loaded.
> + * @dev_priv:drm device to check.
> + *
> + * This function will return true if the guc has been loaded and
> + * has valid firmware. The simplest way of doing this is to check
> + * if the HuC has been validated, if so it must have been loaded.
> + */
> +int intel_is_huc_valid(struct drm_i915_private *dev_priv)
> +{
> + return ((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) != 0);
> +}
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index bdfc688..397b47d 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -395,6 +395,7 @@ typedef struct drm_i915_irq_wait {
> * priorities and the driver will attempt to execute batches in priority
> order.
> */
> #define I915_PARAM_HAS_SCHEDULER 41
> +#define I915_PARAM_HAS_HUC42
>
> typedef struct drm_i915_getparam {
> __s32 param;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support
On 30/11/2016 23:31, Anusha Srivatsa wrote:
This patch adds the HuC Loading for the BXT by using
the updated file construction.
Version 1.7 of the HuC firmware.
v2: rebased.
v3: rebased on top of drm-tip
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/intel_huc_loader.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 663fcc4..6357c19 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -40,6 +40,10 @@
* Note that HuC firmware loading must be done before GuC loading.
*/
+#define BXT_FW_MAJOR 01
+#define BXT_FW_MINOR 07
+#define BXT_BLD_NUM 1398
+
#define SKL_FW_MAJOR 01
#define SKL_FW_MINOR 07
#define SKL_BLD_NUM 1398
@@ -52,6 +56,9 @@
SKL_FW_MINOR, SKL_BLD_NUM)
MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
+#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
+ BXT_FW_MINOR, BXT_BLD_NUM)
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
/**
* huc_ucode_xfer() - DMA's the firmware
* @dev_priv: the drm device
@@ -159,6 +166,10 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_SKL_HUC_UCODE;
huc_fw->major_ver_wanted = SKL_FW_MAJOR;
huc_fw->minor_ver_wanted = SKL_FW_MINOR;
+ } else if (IS_BROXTON(dev_priv)) {
+ fw_path = I915_BXT_HUC_UCODE;
+ huc_fw->major_ver_wanted = BXT_FW_MAJOR;
+ huc_fw->minor_ver_wanted = BXT_FW_MINOR;
}
huc_fw->uc_fw_path = fw_path;
Build number in the file name still worries me. Last time I've asked
about it the thread kind of died off so I will re-state it.
My concern is that if we will be getting firmware releases with the same
major-minor but different build numbers, then embedding the build number
into the driver prevents loading of a newer firmware unless the kernel
is also updated.
I am not sure if that is what we want. Perhaps it is not expected at all
that will happen in production so it is not a concern?
Or if it could happen, perhaps we should either push back on the scheme
- drop the build number and bump the minor in all cases, or
alternatively for our purposes drop the build number from the driver and
have a symlinked scheme on disk?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH alternative #1] drm/i915/bxt: add bxt dsi gpio element support
On Tue, 2016-11-15 at 14:08 +0200, Jani Nikula wrote:
> Request the GPIO by index through the consumer API. For now, use a
> quick
> hack to store the already requested ones, simply because I have no
> idea
> whether this actually works or not, and I have no way to test it.
>
> Cc: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 38
> +-
> 1 file changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 9f279a3d0f74..41e0eeac97f4 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -304,19 +305,44 @@ static void chv_exec_gpio(struct
> drm_i915_private *dev_priv,
> mutex_unlock(&dev_priv->sb_lock);
> }
>
> +static void bxt_exec_gpio(struct drm_i915_private *dev_priv,
> + u8 gpio_source, u8 gpio_index, bool value)
> +{
> + /* XXX: this table is a quick ugly hack. */
> + static struct gpio_desc *bxt_gpio_table[U8_MAX + 1];
> + struct gpio_desc *gpio_desc = bxt_gpio_table[gpio_index];
> +
> + if (!gpio_desc) {
> + gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
> + NULL, gpio_index,
This patch works better with *NULL* replaced by *"panel"*. With this
change we can access GPIO's without GPIO index request failures.
> + value ?
> GPIOD_OUT_LOW :
> + GPIOD_OUT_HIGH);
> +
> + if (IS_ERR_OR_NULL(gpio_desc)) {
> + DRM_ERROR("GPIO index %u request failed
> (%ld)\n",
> + gpio_index, PTR_ERR(gpio_desc));
> + return;
> + }
> +
> + bxt_gpio_table[gpio_index] = gpio_desc;
> + }
> +
> + gpiod_set_value(gpio_desc, value);
> +}
> +
> static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const
> u8 *data)
> {
> struct drm_device *dev = intel_dsi->base.base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> - u8 gpio_source, gpio_index;
> + u8 gpio_source, gpio_index = 0, gpio_number;
> bool value;
>
> DRM_DEBUG_KMS("\n");
>
> if (dev_priv->vbt.dsi.seq_version >= 3)
> - data++;
> + gpio_index = *data++;
>
> - gpio_index = *data++;
> + gpio_number = *data++;
>
> /* gpio source in sequence v2 only */
> if (dev_priv->vbt.dsi.seq_version == 2)
> @@ -328,11 +354,11 @@ static const u8 *mipi_exec_gpio(struct
> intel_dsi *intel_dsi, const u8 *data)
> value = *data++ & 1;
>
> if (IS_VALLEYVIEW(dev_priv))
> - vlv_exec_gpio(dev_priv, gpio_source, gpio_index,
> value);
> + vlv_exec_gpio(dev_priv, gpio_source, gpio_number,
> value);
> else if (IS_CHERRYVIEW(dev_priv))
> - chv_exec_gpio(dev_priv, gpio_source, gpio_index,
> value);
> + chv_exec_gpio(dev_priv, gpio_source, gpio_number,
> value);
> else
> - DRM_DEBUG_KMS("GPIO element not supported on this
> platform\n");
> + bxt_exec_gpio(dev_priv, gpio_source, gpio_index,
> value);
>
> return data;
> }
--
Mika Kahola - Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Protect DSPARB registers with a spinlock
On Thu, Dec 01, 2016 at 12:56:16PM +0100, Maarten Lankhorst wrote:
> Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > Each DSPARB register can house bits for two separate pipes, hence
> > we must protect the registers during reprogramming so that parallel
> > FIFO reconfigurations happening simultaneosly on multiple pipes won't
> > corrupt each others values.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 1 +
> > drivers/gpu/drm/i915/i915_drv.h | 3 +++
> > drivers/gpu/drm/i915/intel_pm.c | 6 ++
> > 3 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 0fba4bb5655e..c98032e9112b 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -811,6 +811,7 @@ static int i915_driver_init_early(struct
> > drm_i915_private *dev_priv,
> > spin_lock_init(&dev_priv->uncore.lock);
> > spin_lock_init(&dev_priv->mm.object_stat_lock);
> > spin_lock_init(&dev_priv->mmio_flip_lock);
> > + spin_lock_init(&dev_priv->wm.dsparb_lock);
> Can we make sure all wm updates are done with dev_priv->wm.wm_mutex held
> instead?
We can't grab a mutex from the vblank evade critical section. We'd have
to hold the mutex across the whole thing then. Not sure if that would be
a good or a bad thing.
>
> gen9 wm's and ilk wm's use that mutex, for similar reasons.
> > mutex_init(&dev_priv->sb_lock);
> > mutex_init(&dev_priv->modeset_restore_lock);
> > mutex_init(&dev_priv->av_mutex);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 9d808b706824..75439e9a67f7 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2169,6 +2169,9 @@ struct drm_i915_private {
> > } sagv_status;
> >
> > struct {
> > + /* protects DSPARB registers on pre-g4x/vlv/chv */
> > + spinlock_t dsparb_lock;
> > +
> > /*
> > * Raw watermark latency values:
> > * in 0.1us units for WM0,
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 24d85a4e4ed3..9f25f2195a6a 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -1215,6 +1215,8 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
> > *crtc)
> > pipe_name(crtc->pipe), sprite0_start,
> > sprite1_start, fifo_size);
> >
> > + spin_lock(&dev_priv->wm.dsparb_lock);
> > +
> > switch (crtc->pipe) {
> > uint32_t dsparb, dsparb2, dsparb3;
> > case PIPE_A:
> > @@ -1271,6 +1273,10 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
> > *crtc)
> > default:
> > break;
> > }
> > +
> > + POSTING_READ(DSPARB);
> > +
> > + spin_unlock(&dev_priv->wm.dsparb_lock);
> > }
> >
> > #undef VLV_FIFO
>
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: introduce platform enum (rev2)
== Series Details == Series: drm/i915: introduce platform enum (rev2) URL : https://patchwork.freedesktop.org/series/16170/ State : success == Summary == Series 16170v2 drm/i915: introduce platform enum https://patchwork.freedesktop.org/api/1.0/series/16170/revisions/2/mbox/ Test gem_exec_flush: Subgroup basic-uc-pro-default: incomplete -> PASS (fi-byt-j1900) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: dmesg-warn -> PASS (fi-ilk-650) fi-bdw-5557u total:245 pass:226 dwarn:0 dfail:0 fail:4 skip:15 fi-bsw-n3050 total:245 pass:203 dwarn:0 dfail:0 fail:2 skip:40 fi-bxt-t5700 total:245 pass:213 dwarn:0 dfail:0 fail:4 skip:28 fi-byt-j1900 total:245 pass:214 dwarn:0 dfail:0 fail:3 skip:28 fi-byt-n2820 total:245 pass:210 dwarn:0 dfail:0 fail:3 skip:32 fi-hsw-4770 total:245 pass:221 dwarn:0 dfail:0 fail:4 skip:20 fi-hsw-4770r total:245 pass:221 dwarn:0 dfail:0 fail:4 skip:20 fi-ilk-650 total:245 pass:189 dwarn:0 dfail:0 fail:3 skip:53 fi-ivb-3520m total:245 pass:219 dwarn:0 dfail:0 fail:4 skip:22 fi-ivb-3770 total:245 pass:219 dwarn:0 dfail:0 fail:4 skip:22 fi-kbl-7500u total:245 pass:219 dwarn:0 dfail:0 fail:4 skip:22 fi-skl-6260u total:245 pass:227 dwarn:0 dfail:0 fail:4 skip:14 fi-skl-6700hqtotal:245 pass:220 dwarn:0 dfail:0 fail:4 skip:21 fi-skl-6700k total:245 pass:219 dwarn:1 dfail:0 fail:4 skip:21 fi-skl-6770hqtotal:245 pass:227 dwarn:0 dfail:0 fail:4 skip:14 fi-snb-2520m total:245 pass:210 dwarn:0 dfail:0 fail:3 skip:32 fi-snb-2600 total:245 pass:209 dwarn:0 dfail:0 fail:3 skip:33 36f5ccaf209f6b34f905f5ba957114132b333ca8 drm-tip: 2016y-12m-01d-11h-42m-17s UTC integration manifest dfc6311 drm/i915: use platform enum instead of duplicating PCI ID if possible ed56530 drm/i915: give G45 and GM45 their own platform enums 94e600a drm/i915: add some more "i" in platform names for consistency fe293b5 drm/i915: rename BROADWATER and CRESTLINE to I965G and I965GM, respectively 173f96d drm/i915: keep intel device info structs in gen based order 6a7e01b drm/i915: replace platform flags with a platform enum == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3161/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/lspcon: Enable AUX interrupts for resume time initialization
On Tue, Nov 29, 2016 at 09:40:29PM +0200, Imre Deak wrote:
> For LSPCON initialization during system resume we need AUX
> functionality, but we call the corresponding encoder reset hook with all
> interrupts disabled. Without interrupts we'll do a poll-wait for AUX
> transfer completions, which adds a significant delay if the transfers
> timeout/need to be retried for some reason.
>
> Fix this by enabling interrupts before calling the reset hooks. Note
> that while this will enable AUX interrupts it will keep HPD interrupts
> disabled, in a similar way to the init time output setup code.
>
> This issue existed since LSPCON support was added.
>
> v2:
> - Rebased on drm-tip.
>
> Cc: Shashank Sharma
> Signed-off-by: Imre Deak
Tested-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_drv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8dac298..2cea2ef 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1582,18 +1582,21 @@ static int i915_drm_resume(struct drm_device *dev)
> intel_opregion_setup(dev_priv);
>
> intel_init_pch_refclk(dev_priv);
> - drm_mode_config_reset(dev);
>
> /*
>* Interrupts have to be enabled before any batches are run. If not the
>* GPU will hang. i915_gem_init_hw() will initiate batches to
>* update/restore the context.
>*
> + * drm_mode_config_reset() needs AUX interrupts.
> + *
>* Modeset enabling in intel_modeset_init_hw() also needs working
>* interrupts.
>*/
> intel_runtime_pm_enable_interrupts(dev_priv);
>
> + drm_mode_config_reset(dev);
> +
> mutex_lock(&dev->struct_mutex);
> if (i915_gem_init_hw(dev)) {
> DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
> --
> 2.5.0
>
> ___
> 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 3/8] drm/i915/huc: Add HuC fw loading support
Hi,
On 30/11/2016 23:31, Anusha Srivatsa wrote:
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon)
update huc_version number of format.
v3: rebased to drm-intel-nightly, changed the file name format to
match the one in the huc package.
Changed dev->dev_private to to_i915()
v4: moved function back to where it was.
change wait_for_atomic to wait_for.
v5: rebased + comment changes.
v7: rebased.
v8: rebased.
v9: rebased. Changed the year in the copyright message to reflect
the right year.Correct the comments,remove the unwanted WARN message,
replace drm_gem_object_unreference() with i915_gem_object_put().Make the
prototypes in intel_huc.h non-extern.
v10: rebased. Update the file construction done by HuC. It is similar to
GuC.Adopted the approach used in-
https://patchwork.freedesktop.org/patch/104355/
v11: Fix warnings remove old declaration
v12: Change dev to dev_priv in macro definition.
Corrected comments.
v13: rebased.
v14: rebased on top of drm-tip
I thought we basically agreed to add i915.enable_huc (default=yes) and
hide i915.enable_guc_loading, making it automatically turn on if either
huc or guc submission are enabled?
Regards,
Tvrtko
Cc: Tvrtko Ursulin
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave Gordon
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_guc_reg.h | 3 +
drivers/gpu/drm/i915/intel_guc_loader.c | 6 +-
drivers/gpu/drm/i915/intel_huc.h| 42 +
drivers/gpu/drm/i915/intel_huc_loader.c | 267
drivers/gpu/drm/i915/intel_uc.h | 2 +
8 files changed, 324 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_huc.h
create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3c30916..01d4f4b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -57,6 +57,7 @@ i915-y += i915_cmd_parser.o \
# general-purpose microcontroller (GuC) support
i915-y += intel_uc.o \
intel_guc_loader.o \
+ intel_huc_loader.o \
i915_guc_submission.o
# autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8dac298..075d9ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -603,6 +603,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
+ intel_huc_init(dev);
intel_guc_init(dev);
ret = i915_gem_init(dev);
@@ -630,6 +631,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
cleanup_irq:
+ intel_huc_fini(dev);
intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
@@ -1326,7 +1328,7 @@ void i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
-
+ intel_huc_fini(dev);
intel_guc_fini(dev);
i915_gem_fini(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 297ad03..8edfae6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -56,6 +56,7 @@
#include "intel_bios.h"
#include "intel_dpll_mgr.h"
#include "intel_uc.h"
+#include "intel_huc.h"
#include "intel_lrc.h"
#include "intel_ringbuffer.h"
@@ -1933,6 +1934,7 @@ struct drm_i915_private {
struct intel_gvt *gvt;
+ struct intel_huc huc;
struct intel_guc guc;
struct intel_csr csr;
@@ -2698,7 +2700,7 @@ intel_info(const struct drm_i915_private *dev_priv)
#define HAS_GUC(dev_priv) ((dev_priv)->info.has_guc)
#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-
+#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
#define HAS_RESOURCE_STREAMER(dev_priv)
((dev_priv)->info.has_resource_streamer)
#define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 5e638fc..f9829f6 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
#define DMA_ADDRESS_SPACE_GTT (8 << 16)
#define DMA_COPY_SIZE _MMIO(0xc310)
#defi
[Intel-gfx] [PATCH i-g-t 2/3] tests/gem_reset_stats: test no progress detection
If seqno is not incrementing but head is moving,
we declare hang but much slower. Add test to check
that this mechanism is working properly.
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 75 +
1 file changed, 75 insertions(+)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
index 2718a33..669a30a 100644
--- a/tests/gem_reset_stats.c
+++ b/tests/gem_reset_stats.c
@@ -711,6 +711,75 @@ static void defer_hangcheck(const struct
intel_execution_engine *engine)
close(fd);
}
+static void test_no_seqno_progress(const struct intel_execution_engine *engine,
+ const bool use_ctx)
+{
+ struct drm_i915_gem_relocation_entry reloc;
+ struct drm_i915_gem_execbuffer2 eb;
+ struct drm_i915_gem_exec_object2 exec;
+ struct local_drm_i915_reset_stats before, after;
+ int len = 0, ctx, fd;
+ uint32_t batch[16*1024];
+ struct timespec ts_start;
+
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ memset(&reloc, 0, sizeof(reloc));
+memset(&exec, 0, sizeof(exec));
+memset(&eb, 0, sizeof(eb));
+ memset(&batch, 0, sizeof(batch));
+
+ exec.handle = gem_create(fd, sizeof(batch));
+ exec.relocation_count = 1;
+exec.relocs_ptr = (uintptr_t)&reloc;
+
+ igt_assert((int)exec.handle > 0);
+
+ if (use_ctx)
+ ctx = gem_context_create(fd);
+ else
+ ctx = 0;
+
+ len = 2;
+ if (intel_gen(intel_get_drm_devid(fd)) >= 8)
+ len++;
+
+ batch[sizeof(batch)/sizeof(uint32_t) - len] = MI_BATCH_BUFFER_START |
(len - 2);
+gem_write(fd, exec.handle, 0, batch, sizeof(batch));
+
+reloc.offset = sizeof(batch) - ((len-1) * 4);
+reloc.delta = 0;
+reloc.target_handle = exec.handle;
+reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
+
+ eb.buffers_ptr = (uintptr_t)&exec;
+ eb.buffer_count = 1;
+ eb.flags = engine->exec_id;
+if (ctx)
+ i915_execbuffer2_set_context_id(eb, ctx);
+
+ igt_assert_eq(gem_reset_stats(fd, ctx, &before), 0);
+
+ clock_gettime(CLOCK_MONOTONIC, &ts_start);
+
+ igt_assert_eq(0, __gem_execbuf(fd, &eb));
+ igt_assert_lte(0, noop(fd, ctx, engine));
+ gem_sync(fd, exec.handle);
+
+ igt_assert_lte(0, noop(fd, ctx, engine));
+ igt_assert_eq(gem_reset_stats(fd, ctx, &after), 0);
+
+ sync_gpu();
+
+ igt_assert(after.batch_active == before.batch_active + 1);
+
+ gem_close(fd, exec.handle);
+ close(fd);
+
+ igt_assert(igt_seconds_elapsed(&ts_start) > 5);
+ igt_assert(igt_seconds_elapsed(&ts_start) < 15);
+}
+
static bool gem_has_reset_stats(int fd)
{
struct local_drm_i915_reset_stats rs;
@@ -798,5 +867,11 @@ igt_main
igt_subtest_f("defer-hangcheck-%s", e->name)
RUN_TEST(defer_hangcheck(e));
+
+ igt_subtest_f("no-progress-%s", e->name)
+ RUN_TEST(test_no_seqno_progress(e, false));
+
+ igt_subtest_f("no-progress-ctx-%s", e->name)
+ RUN_CTX_TEST(test_no_seqno_progress(e, true));
}
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/3] tests/gem_reset_stats: Add test to check client bans
Client will get banned from creating new context
if it has managed to get > 3 context banned.
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 47 ++-
1 file changed, 42 insertions(+), 5 deletions(-)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
index 669a30a..1b9b5cd 100644
--- a/tests/gem_reset_stats.c
+++ b/tests/gem_reset_stats.c
@@ -327,15 +327,15 @@ static void test_rs_ctx(const struct
intel_execution_engine *e,
}
}
-static void test_ban_ctx(const struct intel_execution_engine *e,
-const bool ban_default)
+static void __test_ban_ctx(int fd_bad,
+ const struct intel_execution_engine *e,
+ const bool ban_default)
{
struct local_drm_i915_reset_stats rs_bad, rs_good;
- int fd_bad, fd_good, i;
+ int fd_good, i;
uint32_t ctx_good, ctx_bad;
int active_count = 0, pending_count = 0;
- fd_bad = drm_open_driver(DRIVER_INTEL);
fd_good = drm_open_driver(DRIVER_INTEL);
ctx_good = gem_context_create(fd_bad);
@@ -401,10 +401,44 @@ static void test_ban_ctx(const struct
intel_execution_engine *e,
igt_assert_eq(rs_good.batch_active, 0);
igt_assert_eq(rs_good.batch_pending, 0);
- close(fd_bad);
close(fd_good);
}
+static void test_ban_ctx(const struct intel_execution_engine *e, bool
ban_default)
+{
+ int fd;
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ __test_ban_ctx(fd, e, ban_default);
+
+ close(fd);
+}
+
+static void test_ban_client(const struct intel_execution_engine *e)
+{
+ struct drm_i915_gem_context_create create;
+ int fd;
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ __test_ban_ctx(fd, e, false);
+ igt_assert_lt(0, noop(fd, 0, e));
+
+ __test_ban_ctx(fd, e, false);
+ igt_assert_lt(0, noop(fd, 0, e));
+
+ __test_ban_ctx(fd, e, false);
+ igt_assert_lt(0, noop(fd, 0, e));
+
+ __test_ban_ctx(fd, e, false);
+
+ memset(&create, 0, sizeof(create));
+ igt_assert_eq(-1, igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE,
&create));
+ igt_assert_eq(-EIO, -errno);
+ igt_assert_lt(0, noop(fd, 0, e));
+
+ close(fd);
+}
+
static void test_unrelated_ctx(const struct intel_execution_engine *e)
{
int fd1,fd2;
@@ -844,6 +878,9 @@ igt_main
igt_subtest_f("ban-ctx-%s", e->name)
RUN_CTX_TEST(test_ban_ctx(e, false));
+ igt_subtest_f("ban-client-%s", e->name)
+ RUN_CTX_TEST(test_ban_client(e));
+
igt_subtest_f("reset-count-%s", e->name)
RUN_TEST(test_reset_count(e, false));
--
2.7.4
___
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] tests/gem_reset_stats: Change pending/active assertions
Now that we replay the non guilty contexts and always replay
the default ctx, even when guilty, the assumptions of how many
active and pending batches there was in the time of reset has
changed.
Driver doesn't increment pending counts for contexts that it
considered unaffected by reset. Because it can now replay the
queued requests.
For contexts, guilty of reset, we replay the request envelopes,
but nop the batchbuffer starts. This changes of how many 'hangs'
we think there were queued. As future queued hangs are now NOPed
out, we need to change the assumption of active counts also.
Adapt to these changes of how the replaying of batches affect
the assertions in pending/active counting and banning tests.
While doing this, throw out the retrying to be more strict about
the determinism we want to achieve.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 154 ++--
1 file changed, 56 insertions(+), 98 deletions(-)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
index 3de74af..2718a33 100644
--- a/tests/gem_reset_stats.c
+++ b/tests/gem_reset_stats.c
@@ -152,7 +152,7 @@ static struct timespec ts_injected;
#define BAN HANG_ALLOW_BAN
#define ASYNC 2
-static void inject_hang(int fd, uint32_t ctx,
+static bool inject_hang(int fd, uint32_t ctx,
const struct intel_execution_engine *e,
unsigned flags)
{
@@ -163,6 +163,8 @@ static void inject_hang(int fd, uint32_t ctx,
hang = igt_hang_ctx(fd, ctx, e->exec_id | e->flags, flags & BAN, NULL);
if ((flags & ASYNC) == 0)
igt_post_hang_ring(fd, hang);
+
+ return hang.handle >= 0;
}
static const char *status_to_string(int x)
@@ -239,7 +241,7 @@ static void test_rs(const struct intel_execution_engine *e,
if (i == hang_index)
assert_reset_status(i, fd[i], 0, RS_BATCH_ACTIVE);
if (i > hang_index)
- assert_reset_status(i, fd[i], 0, RS_BATCH_PENDING);
+ assert_reset_status(i, fd[i], 0, RS_NO_ERROR);
}
igt_assert(igt_seconds_elapsed(&ts_injected) <= 30);
@@ -312,10 +314,10 @@ static void test_rs_ctx(const struct
intel_execution_engine *e,
RS_BATCH_ACTIVE);
if (i == hang_index && j > hang_context)
assert_reset_status(i, fd[i], ctx[i][j],
- RS_BATCH_PENDING);
+ RS_NO_ERROR);
if (i > hang_index)
assert_reset_status(i, fd[i], ctx[i][j],
- RS_BATCH_PENDING);
+ RS_NO_ERROR);
}
}
@@ -325,128 +327,84 @@ static void test_rs_ctx(const struct
intel_execution_engine *e,
}
}
-static void test_ban(const struct intel_execution_engine *e)
+static void test_ban_ctx(const struct intel_execution_engine *e,
+const bool ban_default)
{
struct local_drm_i915_reset_stats rs_bad, rs_good;
- int fd_bad, fd_good;
- int ban, retry = 10;
+ int fd_bad, fd_good, i;
+ uint32_t ctx_good, ctx_bad;
int active_count = 0, pending_count = 0;
fd_bad = drm_open_driver(DRIVER_INTEL);
fd_good = drm_open_driver(DRIVER_INTEL);
- assert_reset_status(fd_bad, fd_bad, 0, RS_NO_ERROR);
+ ctx_good = gem_context_create(fd_bad);
+ if (!ban_default)
+ ctx_bad = gem_context_create(fd_bad);
+ else
+ ctx_bad = 0;
+
+ assert_reset_status(fd_bad, fd_bad, ctx_bad, RS_NO_ERROR);
+ assert_reset_status(fd_bad, fd_bad, ctx_good, RS_NO_ERROR);
assert_reset_status(fd_good, fd_good, 0, RS_NO_ERROR);
- noop(fd_bad, 0, e);
- noop(fd_good, 0, e);
+ igt_assert_lt(0, noop(fd_bad, ctx_bad, e));
+ igt_assert_lt(0, noop(fd_bad, ctx_good, e));
+ igt_assert_lt(0, noop(fd_good, 0, e));
- assert_reset_status(fd_bad, fd_bad, 0, RS_NO_ERROR);
+ assert_reset_status(fd_bad, fd_bad, ctx_bad, RS_NO_ERROR);
+ assert_reset_status(fd_bad, fd_bad, ctx_good, RS_NO_ERROR);
assert_reset_status(fd_good, fd_good, 0, RS_NO_ERROR);
- inject_hang(fd_bad, 0, e, BAN | ASYNC);
- active_count++;
+ inject_hang(fd_bad, ctx_bad, e, BAN | ASYNC);
+ /* The next synced ban below ban will get nopped if default ctx */
+ if (!ctx_bad)
+ active_count++;
- noop(fd_good, 0, e);
- noop(fd_good, 0, e);
+ igt_assert_lt(0, noop(fd_good, 0, e));
+ /* We don't skip requests for default ctx, so no
+* pending change as they will be replayed */
+ igt_assert_lt(0, noop(fd_bad, 0, e));
+ igt_assert_lt(0,
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lspcon: Enable AUX interrupts for resume time initialization (rev2)
On ti, 2016-11-29 at 21:53 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/lspcon: Enable AUX interrupts for resume time initialization > (rev2) > URL : https://patchwork.freedesktop.org/series/16106/ > State : success > > == Summary == > > Series 16106v2 drm/i915/lspcon: Enable AUX interrupts for resume time > initialization > https://patchwork.freedesktop.org/api/1.0/series/16106/revisions/2/mbox/ I pushed the patch to -dinq, thanks for the testing and review. --Imre > > > fi-bdw-5557u total:245 pass:230 dwarn:0 dfail:0 fail:0 skip:15 > fi-bsw-n3050 total:245 pass:205 dwarn:0 dfail:0 fail:0 skip:40 > fi-byt-j1900 total:245 pass:217 dwarn:0 dfail:0 fail:0 skip:28 > fi-byt-n2820 total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 > fi-hsw-4770 total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 > fi-hsw-4770r total:245 pass:225 dwarn:0 dfail:0 fail:0 skip:20 > fi-ilk-650 total:245 pass:192 dwarn:0 dfail:0 fail:0 skip:53 > fi-ivb-3520m total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-ivb-3770 total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-kbl-7500u total:245 pass:223 dwarn:0 dfail:0 fail:0 skip:22 > fi-skl-6260u total:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 > fi-skl-6700hqtotal:245 pass:224 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6700k total:245 pass:223 dwarn:1 dfail:0 fail:0 skip:21 > fi-skl-6770hqtotal:245 pass:231 dwarn:0 dfail:0 fail:0 skip:14 > fi-snb-2520m total:245 pass:213 dwarn:0 dfail:0 fail:0 skip:32 > fi-snb-2600 total:245 pass:212 dwarn:0 dfail:0 fail:0 skip:33 > > 41799fbb771e82427273492bfad8f2e2ae3027ef drm-tip: 2016y-11m-29d-20h-54m-07s > UTC integration manifest > d61aedb drm/i915/lspcon: Enable AUX interrupts for resume time initialization > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3147/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/3] tests/gem_reset_stats: Change pending/active assertions
How about a patch 0 to enable hang testing contexts on all rings now?
Then exploration of how one ring affects another...
You will want to use busy batches to load the engines without hanging,
that will be tricky...
On Thu, Dec 01, 2016 at 03:31:43PM +0200, Mika Kuoppala wrote:
> Now that we replay the non guilty contexts and always replay
> the default ctx, even when guilty, the assumptions of how many
> active and pending batches there was in the time of reset has
> changed.
>
> Driver doesn't increment pending counts for contexts that it
> considered unaffected by reset. Because it can now replay the
> queued requests.
>
> For contexts, guilty of reset, we replay the request envelopes,
> but nop the batchbuffer starts. This changes of how many 'hangs'
> we think there were queued. As future queued hangs are now NOPed
> out, we need to change the assumption of active counts also.
>
> Adapt to these changes of how the replaying of batches affect
> the assertions in pending/active counting and banning tests.
> While doing this, throw out the retrying to be more strict about
> the determinism we want to achieve.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> tests/gem_reset_stats.c | 154
> ++--
> 1 file changed, 56 insertions(+), 98 deletions(-)
>
> diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
> index 3de74af..2718a33 100644
> --- a/tests/gem_reset_stats.c
> +++ b/tests/gem_reset_stats.c
> @@ -152,7 +152,7 @@ static struct timespec ts_injected;
>
> #define BAN HANG_ALLOW_BAN
> #define ASYNC 2
> -static void inject_hang(int fd, uint32_t ctx,
> +static bool inject_hang(int fd, uint32_t ctx,
> const struct intel_execution_engine *e,
> unsigned flags)
> {
> @@ -163,6 +163,8 @@ static void inject_hang(int fd, uint32_t ctx,
> hang = igt_hang_ctx(fd, ctx, e->exec_id | e->flags, flags & BAN, NULL);
> if ((flags & ASYNC) == 0)
> igt_post_hang_ring(fd, hang);
> +
> + return hang.handle >= 0;
Never returns false. Future patch?
> static const char *status_to_string(int x)
> @@ -239,7 +241,7 @@ static void test_rs(const struct intel_execution_engine
> *e,
> if (i == hang_index)
> assert_reset_status(i, fd[i], 0, RS_BATCH_ACTIVE);
> if (i > hang_index)
> - assert_reset_status(i, fd[i], 0, RS_BATCH_PENDING);
> + assert_reset_status(i, fd[i], 0, RS_NO_ERROR);
> }
>
> igt_assert(igt_seconds_elapsed(&ts_injected) <= 30);
> @@ -312,10 +314,10 @@ static void test_rs_ctx(const struct
> intel_execution_engine *e,
> RS_BATCH_ACTIVE);
> if (i == hang_index && j > hang_context)
> assert_reset_status(i, fd[i], ctx[i][j],
> - RS_BATCH_PENDING);
> + RS_NO_ERROR);
> if (i > hang_index)
> assert_reset_status(i, fd[i], ctx[i][j],
> - RS_BATCH_PENDING);
> + RS_NO_ERROR);
> }
> }
>
> @@ -325,128 +327,84 @@ static void test_rs_ctx(const struct
> intel_execution_engine *e,
> }
> }
>
> -static void test_ban(const struct intel_execution_engine *e)
> +static void test_ban_ctx(const struct intel_execution_engine *e,
> + const bool ban_default)
> {
> struct local_drm_i915_reset_stats rs_bad, rs_good;
> - int fd_bad, fd_good;
> - int ban, retry = 10;
> + int fd_bad, fd_good, i;
> + uint32_t ctx_good, ctx_bad;
> int active_count = 0, pending_count = 0;
>
> fd_bad = drm_open_driver(DRIVER_INTEL);
> fd_good = drm_open_driver(DRIVER_INTEL);
>
> - assert_reset_status(fd_bad, fd_bad, 0, RS_NO_ERROR);
> + ctx_good = gem_context_create(fd_bad);
> + if (!ban_default)
> + ctx_bad = gem_context_create(fd_bad);
> + else
> + ctx_bad = 0;
> +
> + assert_reset_status(fd_bad, fd_bad, ctx_bad, RS_NO_ERROR);
> + assert_reset_status(fd_bad, fd_bad, ctx_good, RS_NO_ERROR);
> assert_reset_status(fd_good, fd_good, 0, RS_NO_ERROR);
>
> - noop(fd_bad, 0, e);
> - noop(fd_good, 0, e);
> + igt_assert_lt(0, noop(fd_bad, ctx_bad, e));
> + igt_assert_lt(0, noop(fd_bad, ctx_good, e));
> + igt_assert_lt(0, noop(fd_good, 0, e));
Yuck.
__noop();
noop() { igt_assert_eq(__noop, 0));
(Or better names than noop? )
Otherwise, lgtm. R-b if you feel so inclined.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/gem_reset_stats: test no progress detection
On Thu, Dec 01, 2016 at 03:31:44PM +0200, Mika Kuoppala wrote:
> If seqno is not incrementing but head is moving,
> we declare hang but much slower. Add test to check
> that this mechanism is working properly.
>
> Signed-off-by: Mika Kuoppala
> ---
> tests/gem_reset_stats.c | 75
> +
> 1 file changed, 75 insertions(+)
>
> diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
> index 2718a33..669a30a 100644
> --- a/tests/gem_reset_stats.c
> +++ b/tests/gem_reset_stats.c
> @@ -711,6 +711,75 @@ static void defer_hangcheck(const struct
> intel_execution_engine *engine)
> close(fd);
> }
>
> +static void test_no_seqno_progress(const struct intel_execution_engine
> *engine,
> +const bool use_ctx)
> +{
> + struct drm_i915_gem_relocation_entry reloc;
> + struct drm_i915_gem_execbuffer2 eb;
> + struct drm_i915_gem_exec_object2 exec;
I would advise using obj instead of exec
> + struct local_drm_i915_reset_stats before, after;
> + int len = 0, ctx, fd;
> + uint32_t batch[16*1024];
Not needed, see later.
#define BATCH_SIZE (16 << 10)
> + struct timespec ts_start;
> +
> + fd = drm_open_driver(DRIVER_INTEL);
> +
> + memset(&reloc, 0, sizeof(reloc));
> +memset(&exec, 0, sizeof(exec));
> +memset(&eb, 0, sizeof(eb));
> + memset(&batch, 0, sizeof(batch));
> +
> + exec.handle = gem_create(fd, sizeof(batch));
> + exec.relocation_count = 1;
> +exec.relocs_ptr = (uintptr_t)&reloc;
> +
> + igt_assert((int)exec.handle > 0);
Already asserted for you.
> +
> + if (use_ctx)
> + ctx = gem_context_create(fd);
> + else
> + ctx = 0;
> +
> + len = 2;
> + if (intel_gen(intel_get_drm_devid(fd)) >= 8)
> + len++;
> +
> + batch[sizeof(batch)/sizeof(uint32_t) - len] = MI_BATCH_BUFFER_START |
> (len - 2);
> +gem_write(fd, exec.handle, 0, batch, sizeof(batch));
gem_write(fd, exec.handle, BATCH_SIZE - 16, &cmd, sizeof(cmd));
> +
> +reloc.offset = sizeof(batch) - ((len-1) * 4);
reloc.offset = BATCH_SIZE - 16 + sizeof(cmd);
> +reloc.delta = 0;
> +reloc.target_handle = exec.handle;
> +reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
> + eb.buffers_ptr = (uintptr_t)&exec;
> + eb.buffer_count = 1;
> + eb.flags = engine->exec_id;
> +if (ctx)
> + i915_execbuffer2_set_context_id(eb, ctx);
eb.rsvd1 = ctx; It's perfectly fine to set it to zero.
> + igt_assert_eq(gem_reset_stats(fd, ctx, &before), 0);
> +
> + clock_gettime(CLOCK_MONOTONIC, &ts_start);
struct timespec ts = {};
igt_seconds_elapsed(&ts_start)
> +
> + igt_assert_eq(0, __gem_execbuf(fd, &eb));
gem_execbuf();
> + igt_assert_lte(0, noop(fd, ctx, engine));
See earlier comments about noop.
> + gem_sync(fd, exec.handle);
> +
> + igt_assert_lte(0, noop(fd, ctx, engine));
> + igt_assert_eq(gem_reset_stats(fd, ctx, &after), 0);
> +
> + sync_gpu();
> +
> + igt_assert(after.batch_active == before.batch_active + 1);
igt_assert_eq(after, before + 1);
> + gem_close(fd, exec.handle);
> + close(fd);
> +
> + igt_assert(igt_seconds_elapsed(&ts_start) > 5);
You really want to demand a minimum time?
> + igt_assert(igt_seconds_elapsed(&ts_start) < 15);
Play state thy sources. Upper bound should be closer to 120s.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/3] tests/gem_reset_stats: Add test to check client bans
On Thu, Dec 01, 2016 at 03:31:45PM +0200, Mika Kuoppala wrote: > Client will get banned from creating new context > if it has managed to get > 3 context banned. I'm not thrilled about baking that magic number into an ABI requirement. Just make it N bans, test timing out after say 120s of happiness (with skip)? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: Make GEM object create and create from data take dev_priv
From: Tvrtko Ursulin
Makes all GEM object constructors consistent.
v2: Fix compilation in GVT code.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson (v1)
Reviewed-by: Joonas Lahtinen (v1)
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h| 9 +
drivers/gpu/drm/i915/i915_gem.c| 20 ++--
drivers/gpu/drm/i915/i915_gem_context.c| 5 +++--
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 5 +++--
drivers/gpu/drm/i915/intel_lrc.c | 4 ++--
drivers/gpu/drm/i915/intel_overlay.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c| 4 ++--
12 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index d26a092c70e8..9a4b23c3ee97 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1602,7 +1602,7 @@ static int perform_bb_shadow(struct parser_exec_state *s)
return -ENOMEM;
entry_obj->obj =
- i915_gem_object_create(&(s->vgpu->gvt->dev_priv->drm),
+ i915_gem_object_create(s->vgpu->gvt->dev_priv,
roundup(bb_size, PAGE_SIZE));
if (IS_ERR(entry_obj->obj)) {
ret = PTR_ERR(entry_obj->obj);
@@ -2665,14 +2665,13 @@ int intel_gvt_scan_and_shadow_workload(struct
intel_vgpu_workload *workload)
static int shadow_indirect_ctx(struct intel_shadow_wa_ctx *wa_ctx)
{
- struct drm_device *dev = &wa_ctx->workload->vgpu->gvt->dev_priv->drm;
int ctx_size = wa_ctx->indirect_ctx.size;
unsigned long guest_gma = wa_ctx->indirect_ctx.guest_gma;
struct drm_i915_gem_object *obj;
int ret = 0;
void *map;
- obj = i915_gem_object_create(dev,
+ obj = i915_gem_object_create(wa_ctx->workload->vgpu->gvt->dev_priv,
roundup(ctx_size + CACHELINE_BYTES,
PAGE_SIZE));
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65d7a7811236..8b725d13d24e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2985,10 +2985,11 @@ void *i915_gem_object_alloc(struct drm_i915_private
*dev_priv);
void i915_gem_object_free(struct drm_i915_gem_object *obj);
void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops);
-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- u64 size);
-struct drm_i915_gem_object *i915_gem_object_create_from_data(
- struct drm_device *dev, const void *data, size_t size);
+struct drm_i915_gem_object *
+i915_gem_object_create(struct drm_i915_private *dev_priv, u64 size);
+struct drm_i915_gem_object *
+i915_gem_object_create_from_data(struct drm_i915_private *dev_priv,
+const void *data, size_t size);
void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
void i915_gem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab75d27b74d5..10c3b505f49a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -635,7 +635,7 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj)
static int
i915_gem_create(struct drm_file *file,
- struct drm_device *dev,
+ struct drm_i915_private *dev_priv,
uint64_t size,
uint32_t *handle_p)
{
@@ -648,7 +648,7 @@ i915_gem_create(struct drm_file *file,
return -EINVAL;
/* Allocate the new object */
- obj = i915_gem_object_create(dev, size);
+ obj = i915_gem_object_create(dev_priv, size);
if (IS_ERR(obj))
return PTR_ERR(obj);
@@ -670,7 +670,7 @@ i915_gem_dumb_create(struct drm_file *file,
/* have to work out size/pitch and return them */
args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
args->size = args->pitch * args->height;
- return i915_gem_create(file, dev,
+ return i915_gem_create(file, to_i915(dev),
args->size, &args->handle);
}
@@ -684,11 +684,12 @@ int
i915_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
+ struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_create *args = data;
- i915_gem_flush_free_objects(to_i915(dev));
+ i915_gem_flush_free_objects(dev_priv);
- return i915_gem
[Intel-gfx] [PATCH 01/10] drm/i915: Make GEM object alloc/free and stolen created take dev_priv
From: Tvrtko Ursulin
Where it is more appropriate and also to be consistent with
the direction of the driver.
v2: Leave out object alloc/free inlining. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 5 ++---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/i915_gem_internal.c | 2 +-
drivers/gpu/drm/i915/i915_gem_stolen.c | 21 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
drivers/gpu/drm/i915/intel_overlay.c | 3 +--
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
12 files changed, 24 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 34f2b0da6a81..65d7a7811236 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2981,7 +2981,7 @@ void i915_gem_load_init_fences(struct drm_i915_private
*dev_priv);
int i915_gem_freeze(struct drm_i915_private *dev_priv);
int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
-void *i915_gem_object_alloc(struct drm_device *dev);
+void *i915_gem_object_alloc(struct drm_i915_private *dev_priv);
void i915_gem_object_free(struct drm_i915_gem_object *obj);
void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops);
@@ -3366,9 +3366,9 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*dev_priv,
int i915_gem_init_stolen(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_stolen(struct drm_device *dev);
struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u32 size);
+i915_gem_object_create_stolen(struct drm_i915_private *dev_priv, u32 size);
struct drm_i915_gem_object *
-i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
+i915_gem_object_create_stolen_for_preallocated(struct drm_i915_private
*dev_priv,
u32 stolen_offset,
u32 gtt_offset,
u32 size);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ebefb6f6cf2..ab75d27b74d5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -622,9 +622,8 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
return ret;
}
-void *i915_gem_object_alloc(struct drm_device *dev)
+void *i915_gem_object_alloc(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
return kmem_cache_zalloc(dev_priv->objects, GFP_KERNEL);
}
@@ -3990,7 +3989,7 @@ i915_gem_object_create(struct drm_device *dev, u64 size)
if (overflows_type(size, obj->base.size))
return ERR_PTR(-E2BIG);
- obj = i915_gem_object_alloc(dev);
+ obj = i915_gem_object_alloc(dev_priv);
if (obj == NULL)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 5e38299b5df6..d037adcda6f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -278,7 +278,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
get_dma_buf(dma_buf);
- obj = i915_gem_object_alloc(dev);
+ obj = i915_gem_object_alloc(to_i915(dev));
if (obj == NULL) {
ret = -ENOMEM;
goto fail_detach;
diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 4b3ff3e5b911..08d26306d40e 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -155,7 +155,7 @@ i915_gem_object_create_internal(struct drm_i915_private
*i915,
{
struct drm_i915_gem_object *obj;
- obj = i915_gem_object_alloc(&i915->drm);
+ obj = i915_gem_object_alloc(i915);
if (!obj)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index ebaa941c83af..b3bac2557665 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -579,22 +579,21 @@ static const struct drm_i915_gem_object_ops
i915_gem_object_stolen_ops = {
};
static struct drm_i915_gem_object *
-_i915_gem_object_create_stolen(struct drm_device *dev,
+_i915_gem_object_create_stolen(struct drm_i915_private *dev_priv,
struct drm_mm_node *stolen)
{
struct drm_i915_gem_object *obj;
- obj = i915_gem_object_alloc(dev);
+ obj = i915_gem_objec
[Intel-gfx] [PATCH v2 00/10] GEM object create and driver init dev_priv cleanups
From: Tvrtko Ursulin Autumn of churn continues. :) This series tidies GEM object construction to take dev_priv instead of dev in all cases and also does a bit of random tidy in the driver load/init code. Basically functions which only need dev_priv are changed to take dev_priv instead of dev. There is often a cascade effect and the end result is a saving in lines of code. And even in binary occasionally but not worth much mention. v2: Review feedback. Tvrtko Ursulin (10): drm/i915: Make GEM object alloc/free and stolen created take dev_priv drm/i915: Make GEM object create and create from data take dev_priv drm/i915: Make various init functions take dev_priv drm/i915: More GEM init dev_priv cleanup drm/i915: dev_priv cleanup in bridge/bar/mmio init code drm/i915: Unexport VGA switcheroo functions drm/i915: Make gmbus setup take dev_priv drm/i915: Make i915_destroy_error_state take dev_priv drm/i915: Make i915_save/restore_state and intel_i2c_reset take dev_priv drm/i915: Make intel_pm_setup take dev_priv drivers/gpu/drm/i915/i915_debugfs.c| 8 +-- drivers/gpu/drm/i915/i915_drv.c| 108 + drivers/gpu/drm/i915/i915_drv.h| 63 + drivers/gpu/drm/i915/i915_gem.c| 72 --- drivers/gpu/drm/i915/i915_gem_context.c| 39 +-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +- drivers/gpu/drm/i915/i915_gem_internal.c | 2 +- drivers/gpu/drm/i915/i915_gem_stolen.c | 21 +++--- drivers/gpu/drm/i915/i915_gem_userptr.c| 2 +- drivers/gpu/drm/i915/i915_gpu_error.c | 5 +- drivers/gpu/drm/i915/i915_guc_submission.c | 12 ++-- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_suspend.c| 22 +++--- drivers/gpu/drm/i915/i915_sysfs.c | 4 +- drivers/gpu/drm/i915/intel_display.c | 6 +- drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_engine_cs.c | 7 +- drivers/gpu/drm/i915/intel_fbdev.c | 4 +- drivers/gpu/drm/i915/intel_guc_loader.c| 36 +- drivers/gpu/drm/i915/intel_i2c.c | 16 ++--- drivers/gpu/drm/i915/intel_lrc.c | 4 +- drivers/gpu/drm/i915/intel_lrc.h | 2 +- drivers/gpu/drm/i915/intel_mocs.c | 5 +- drivers/gpu/drm/i915/intel_mocs.h | 2 +- drivers/gpu/drm/i915/intel_overlay.c | 5 +- drivers/gpu/drm/i915/intel_pm.c| 8 +-- drivers/gpu/drm/i915/intel_ringbuffer.c| 6 +- drivers/gpu/drm/i915/intel_uc.h| 10 +-- 28 files changed, 214 insertions(+), 261 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: Make gmbus setup take dev_priv
From: Tvrtko Ursulin
Simplify the code by passing the right argument in.
v2: Commit message. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_i2c.c | 8 +++-
4 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 362c8baef640..fee0b46a04bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -592,7 +592,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_csr;
- intel_setup_gmbus(dev);
+ intel_setup_gmbus(dev_priv);
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
@@ -629,7 +629,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
cleanup_irq:
intel_guc_fini(dev_priv);
drm_irq_uninstall(dev);
- intel_teardown_gmbus(dev);
+ intel_teardown_gmbus(dev_priv);
cleanup_csr:
intel_csr_ucode_fini(dev_priv);
intel_power_domains_fini(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6cb4bb349c89..44aecad47b21 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3478,8 +3478,8 @@ void i915_setup_sysfs(struct drm_i915_private *dev_priv);
void i915_teardown_sysfs(struct drm_i915_private *dev_priv);
/* intel_i2c.c */
-extern int intel_setup_gmbus(struct drm_device *dev);
-extern void intel_teardown_gmbus(struct drm_device *dev);
+extern int intel_setup_gmbus(struct drm_i915_private *dev_priv);
+extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
unsigned int pin);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2785c619fa55..16fb90964a64 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -17162,7 +17162,7 @@ void intel_modeset_cleanup(struct drm_device *dev)
intel_cleanup_gt_powersave(dev_priv);
- intel_teardown_gmbus(dev);
+ intel_teardown_gmbus(dev_priv);
}
void intel_connector_attach_encoder(struct intel_connector *connector,
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 83f260bb4eef..85faba415633 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -617,11 +617,10 @@ static const struct i2c_algorithm gmbus_algorithm = {
/**
* intel_gmbus_setup - instantiate all Intel i2c GMBuses
- * @dev: DRM device
+ * @dev_priv: i915 device private
*/
-int intel_setup_gmbus(struct drm_device *dev)
+int intel_setup_gmbus(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
struct intel_gmbus *bus;
unsigned int pin;
@@ -724,9 +723,8 @@ void intel_gmbus_force_bit(struct i2c_adapter *adapter,
bool force_bit)
mutex_unlock(&dev_priv->gmbus_mutex);
}
-void intel_teardown_gmbus(struct drm_device *dev)
+void intel_teardown_gmbus(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_gmbus *bus;
unsigned int pin;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: More GEM init dev_priv cleanup
From: Tvrtko Ursulin
Simplifies the code to pass the right parameter in.
v2: Commit message. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 8
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/i915_gem.c | 10 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 5 ++---
4 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7f85bdf8d66..383bf1ac1bdd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -544,8 +544,8 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
static void i915_gem_fini(struct drm_i915_private *dev_priv)
{
mutex_lock(&dev_priv->drm.struct_mutex);
- i915_gem_cleanup_engines(&dev_priv->drm);
- i915_gem_context_fini(&dev_priv->drm);
+ i915_gem_cleanup_engines(dev_priv);
+ i915_gem_context_fini(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
rcu_barrier();
@@ -833,7 +833,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
- ret = i915_gem_load_init(&dev_priv->drm);
+ ret = i915_gem_load_init(dev_priv);
if (ret < 0)
goto err_gvt;
@@ -861,7 +861,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
i915_perf_fini(dev_priv);
- i915_gem_load_cleanup(&dev_priv->drm);
+ i915_gem_load_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bbc6d0f2d8bf..20bc0aef656a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2975,8 +2975,8 @@ int i915_gem_get_aperture_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv);
int i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-int i915_gem_load_init(struct drm_device *dev);
-void i915_gem_load_cleanup(struct drm_device *dev);
+int i915_gem_load_init(struct drm_i915_private *dev_priv);
+void i915_gem_load_cleanup(struct drm_i915_private *dev_priv);
void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
int i915_gem_freeze(struct drm_i915_private *dev_priv);
int i915_gem_freeze_late(struct drm_i915_private *dev_priv);
@@ -3180,7 +3180,7 @@ void i915_gem_clflush_object(struct drm_i915_gem_object
*obj, bool force);
int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
-void i915_gem_cleanup_engines(struct drm_device *dev);
+void i915_gem_cleanup_engines(struct drm_i915_private *dev_priv);
int __must_check 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);
@@ -3269,7 +3269,7 @@ void i915_gem_object_save_bit_17_swizzle(struct
drm_i915_gem_object *obj,
/* i915_gem_context.c */
int __must_check i915_gem_context_init(struct drm_i915_private *dev_priv);
void i915_gem_context_lost(struct drm_i915_private *dev_priv);
-void i915_gem_context_fini(struct drm_device *dev);
+void i915_gem_context_fini(struct drm_i915_private *dev_priv);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
int i915_switch_context(struct drm_i915_gem_request *req);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b2a2e5843dc8..59065ae0b153 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4480,9 +4480,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
}
void
-i915_gem_cleanup_engines(struct drm_device *dev)
+i915_gem_cleanup_engines(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -4522,9 +4521,8 @@ i915_gem_load_init_fences(struct drm_i915_private
*dev_priv)
}
int
-i915_gem_load_init(struct drm_device *dev)
+i915_gem_load_init(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
int err = -ENOMEM;
dev_priv->objects = KMEM_CACHE(drm_i915_gem_object, SLAB_HWCACHE_ALIGN);
@@ -4593,10 +4591,8 @@ i915_gem_load_init(struct drm_device *dev)
return err;
}
-void i915_gem_load_cleanup(struct drm_device *dev)
+void i915_gem_loa
[Intel-gfx] [PATCH 03/10] drm/i915: Make various init functions take dev_priv
From: Tvrtko Ursulin
Like GEM init, GUC init, MOCS init and context creation.
Enables them to lose dev_priv locals.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c| 31 ++--
drivers/gpu/drm/i915/i915_drv.h| 10 -
drivers/gpu/drm/i915/i915_gem.c| 28 -
drivers/gpu/drm/i915/i915_gem_context.c| 31 +---
drivers/gpu/drm/i915/i915_guc_submission.c | 10 -
drivers/gpu/drm/i915/intel_engine_cs.c | 5 ++---
drivers/gpu/drm/i915/intel_guc_loader.c| 33 ++
drivers/gpu/drm/i915/intel_lrc.h | 2 +-
drivers/gpu/drm/i915/intel_mocs.c | 5 ++---
drivers/gpu/drm/i915/intel_mocs.h | 2 +-
drivers/gpu/drm/i915/intel_uc.h| 10 -
11 files changed, 77 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 89af78eb5c32..a7f85bdf8d66 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -603,9 +603,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
- intel_guc_init(dev);
+ intel_guc_init(dev_priv);
- ret = i915_gem_init(dev);
+ ret = i915_gem_init(dev_priv);
if (ret)
goto cleanup_irq;
@@ -626,11 +626,11 @@ static int i915_load_modeset_init(struct drm_device *dev)
return 0;
cleanup_gem:
- if (i915_gem_suspend(dev))
+ if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
cleanup_irq:
- intel_guc_fini(dev);
+ intel_guc_fini(dev_priv);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
cleanup_csr:
@@ -1283,7 +1283,7 @@ void i915_driver_unload(struct drm_device *dev)
intel_fbdev_fini(dev);
- if (i915_gem_suspend(dev))
+ if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
@@ -1320,7 +1320,7 @@ void i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
- intel_guc_fini(dev);
+ intel_guc_fini(dev_priv);
i915_gem_fini(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
@@ -1425,14 +1425,14 @@ static int i915_drm_suspend(struct drm_device *dev)
pci_save_state(pdev);
- error = i915_gem_suspend(dev);
+ error = i915_gem_suspend(dev_priv);
if (error) {
dev_err(&pdev->dev,
"GEM idle failed, resume might fail\n");
goto out;
}
- intel_guc_suspend(dev);
+ intel_guc_suspend(dev_priv);
intel_display_suspend(dev);
@@ -1568,7 +1568,7 @@ static int i915_drm_resume(struct drm_device *dev)
intel_csr_ucode_resume(dev_priv);
- i915_gem_resume(dev);
+ i915_gem_resume(dev_priv);
i915_restore_state(dev);
intel_pps_unlock_regs_wa(dev_priv);
@@ -1591,13 +1591,13 @@ static int i915_drm_resume(struct drm_device *dev)
drm_mode_config_reset(dev);
mutex_lock(&dev->struct_mutex);
- if (i915_gem_init_hw(dev)) {
+ if (i915_gem_init_hw(dev_priv)) {
DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
i915_gem_set_wedged(dev_priv);
}
mutex_unlock(&dev->struct_mutex);
- intel_guc_resume(dev);
+ intel_guc_resume(dev_priv);
intel_modeset_init_hw(dev);
@@ -1770,11 +1770,10 @@ static void enable_engines_irq(struct drm_i915_private
*dev_priv)
*/
void i915_reset(struct drm_i915_private *dev_priv)
{
- struct drm_device *dev = &dev_priv->drm;
struct i915_gpu_error *error = &dev_priv->gpu_error;
int ret;
- lockdep_assert_held(&dev->struct_mutex);
+ lockdep_assert_held(&dev_priv->drm.struct_mutex);
if (!test_and_clear_bit(I915_RESET_IN_PROGRESS, &error->flags))
return;
@@ -1814,7 +1813,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
* was running at the time of the reset (i.e. we weren't VT
* switched away).
*/
- ret = i915_gem_init_hw(dev);
+ ret = i915_gem_init_hw(dev_priv);
if (ret) {
DRM_ERROR("Failed hw init on reset %d\n", ret);
goto error;
@@ -2328,7 +2327,7 @@ static int intel_runtime_suspend(struct device *kdev)
*/
i915_gem_runtime_suspend(dev_priv);
- intel_guc_suspend(dev);
+ intel_guc_suspend(dev_priv);
intel_runtime_pm_disable_interrupts(dev_priv);
@@ -2413,7 +2412,7 @@ static int intel_runtime_resume(struct device *kdev
[Intel-gfx] [PATCH 08/10] drm/i915: Make i915_destroy_error_state take dev_priv
From: Tvrtko Ursulin
Since it does not need dev at all.
Also change the stored pointer in struct i915_error_state_file_priv
to i915.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 8
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
drivers/gpu/drm/i915/i915_gpu_error.c | 5 ++---
drivers/gpu/drm/i915/i915_sysfs.c | 4 ++--
5 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2434130087be..d006ed131a54 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -946,7 +946,7 @@ i915_error_state_write(struct file *filp,
struct i915_error_state_file_priv *error_priv = filp->private_data;
DRM_DEBUG_DRIVER("Resetting error state\n");
- i915_destroy_error_state(error_priv->dev);
+ i915_destroy_error_state(error_priv->i915);
return cnt;
}
@@ -960,7 +960,7 @@ static int i915_error_state_open(struct inode *inode,
struct file *file)
if (!error_priv)
return -ENOMEM;
- error_priv->dev = &dev_priv->drm;
+ error_priv->i915 = dev_priv;
i915_error_state_get(&dev_priv->drm, error_priv);
@@ -988,8 +988,8 @@ static ssize_t i915_error_state_read(struct file *file,
char __user *userbuf,
ssize_t ret_count = 0;
int ret;
- ret = i915_error_state_buf_init(&error_str,
- to_i915(error_priv->dev), count, *pos);
+ ret = i915_error_state_buf_init(&error_str, error_priv->i915,
+ count, *pos);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index fee0b46a04bc..809315cad316 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1307,7 +1307,7 @@ void i915_driver_unload(struct drm_device *dev)
/* Free error state after interrupts are fully disabled. */
cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work);
- i915_destroy_error_state(dev);
+ i915_destroy_error_state(dev_priv);
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 44aecad47b21..2006ea033354 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1459,7 +1459,7 @@ struct drm_i915_error_state_buf {
};
struct i915_error_state_file_priv {
- struct drm_device *dev;
+ struct drm_i915_private *i915;
struct drm_i915_error_state *error;
};
@@ -3434,7 +3434,7 @@ void i915_capture_error_state(struct drm_i915_private
*dev_priv,
void i915_error_state_get(struct drm_device *dev,
struct i915_error_state_file_priv *error_priv);
void i915_error_state_put(struct i915_error_state_file_priv *error_priv);
-void i915_destroy_error_state(struct drm_device *dev);
+void i915_destroy_error_state(struct drm_i915_private *dev_priv);
#else
@@ -3444,7 +3444,7 @@ static inline void i915_capture_error_state(struct
drm_i915_private *dev_priv,
{
}
-static inline void i915_destroy_error_state(struct drm_device *dev)
+static inline void i915_destroy_error_state(struct drm_i915_private *dev_priv)
{
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 82458ea60150..a14f7badc337 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -514,7 +514,7 @@ static void err_print_capabilities(struct
drm_i915_error_state_buf *m,
int i915_error_state_to_str(struct drm_i915_error_state_buf *m,
const struct i915_error_state_file_priv *error_priv)
{
- struct drm_i915_private *dev_priv = to_i915(error_priv->dev);
+ struct drm_i915_private *dev_priv = error_priv->i915;
struct pci_dev *pdev = dev_priv->drm.pdev;
struct drm_i915_error_state *error = error_priv->error;
struct drm_i915_error_object *obj;
@@ -1644,9 +1644,8 @@ void i915_error_state_put(struct
i915_error_state_file_priv *error_priv)
kref_put(&error_priv->error->ref, i915_error_state_free);
}
-void i915_destroy_error_state(struct drm_device *dev)
+void i915_destroy_error_state(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_error_state *error;
spin_lock_irq(&dev_priv->gpu_error.lock);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 47590ab08d7e..b99fd9668317 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -535,7 +535,7 @@ static ssize_t error_state_read(struct file *filp, struct
kobject *kobj,
i
[Intel-gfx] [PATCH 06/10] drm/i915: Unexport VGA switcheroo functions
From: Tvrtko Ursulin
They are only used in i915_drv.c so a forward declaration is enough.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
drivers/gpu/drm/i915/i915_drv.h | 3 ---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1312cd5e4465..362c8baef640 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -497,6 +497,9 @@ static unsigned int i915_vga_set_decode(void *cookie, bool
state)
return VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM;
}
+static int i915_resume_switcheroo(struct drm_device *dev);
+static int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state);
+
static void i915_switcheroo_set_state(struct pci_dev *pdev, enum
vga_switcheroo_state state)
{
struct drm_device *dev = pci_get_drvdata(pdev);
@@ -1710,7 +1713,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
return ret;
}
-int i915_resume_switcheroo(struct drm_device *dev)
+static int i915_resume_switcheroo(struct drm_device *dev)
{
int ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 20bc0aef656a..6cb4bb349c89 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2759,9 +2759,6 @@ static inline bool intel_scanout_needs_vtd_wa(struct
drm_i915_private *dev_priv)
return false;
}
-extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state);
-extern int i915_resume_switcheroo(struct drm_device *dev);
-
int intel_sanitize_enable_ppgtt(struct drm_i915_private *dev_priv,
int enable_ppgtt);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Make intel_pm_setup take dev_priv
From: Tvrtko Ursulin
Function actually wants dev_priv so give it to it.
v2: Commit message. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 4 +---
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bd8994d02813..ace9be8f6ff9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -822,7 +822,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
- intel_pm_setup(&dev_priv->drm);
+ intel_pm_setup(dev_priv);
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
intel_irq_init(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 460f3742ebd7..1d126c29598f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1724,7 +1724,7 @@ int ilk_wm_max_level(const struct drm_i915_private
*dev_priv);
void intel_update_watermarks(struct intel_crtc *crtc);
void intel_init_pm(struct drm_i915_private *dev_priv);
void intel_init_clock_gating_hooks(struct drm_i915_private *dev_priv);
-void intel_pm_setup(struct drm_device *dev);
+void intel_pm_setup(struct drm_i915_private *dev_priv);
void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
void intel_gpu_ips_teardown(void);
void intel_init_gt_powersave(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ca31cdd82ebd..c45ee1732715 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7955,10 +7955,8 @@ void intel_queue_rps_boost_for_request(struct
drm_i915_gem_request *req)
queue_work(req->i915->wq, &boost->work);
}
-void intel_pm_setup(struct drm_device *dev)
+void intel_pm_setup(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
-
mutex_init(&dev_priv->rps.hw_lock);
spin_lock_init(&dev_priv->rps.client_lock);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915: dev_priv cleanup in bridge/bar/mmio init code
From: Tvrtko Ursulin
dev_priv is more appropriate for these so converting saves
some lines of source.
v2: Commit message and keep the pdev local variable. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson (v1)
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 45 -
1 file changed, 17 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 383bf1ac1bdd..1312cd5e4465 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -142,9 +142,8 @@ static enum intel_pch intel_virt_detect_pch(struct
drm_i915_private *dev_priv)
return ret;
}
-static void intel_detect_pch(struct drm_device *dev)
+static void intel_detect_pch(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pch = NULL;
/* In all current cases, num_pipes is equivalent to the PCH_NOP setting
@@ -361,10 +360,8 @@ static int i915_getparam(struct drm_device *dev, void
*data,
return 0;
}
-static int i915_get_bridge_dev(struct drm_device *dev)
+static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
-
dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
if (!dev_priv->bridge_dev) {
DRM_ERROR("bridge device not found\n");
@@ -375,9 +372,8 @@ static int i915_get_bridge_dev(struct drm_device *dev)
/* Allocate space for the MCH regs if needed, return nonzero on error */
static int
-intel_alloc_mchbar_resource(struct drm_device *dev)
+intel_alloc_mchbar_resource(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
int reg = INTEL_GEN(dev_priv) >= 4 ? MCHBAR_I965 : MCHBAR_I915;
u32 temp_lo, temp_hi = 0;
u64 mchbar_addr;
@@ -421,9 +417,8 @@ intel_alloc_mchbar_resource(struct drm_device *dev)
/* Setup MCHBAR if possible, return true if we should disable it again */
static void
-intel_setup_mchbar(struct drm_device *dev)
+intel_setup_mchbar(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
int mchbar_reg = INTEL_GEN(dev_priv) >= 4 ? MCHBAR_I965 : MCHBAR_I915;
u32 temp;
bool enabled;
@@ -445,7 +440,7 @@ intel_setup_mchbar(struct drm_device *dev)
if (enabled)
return;
- if (intel_alloc_mchbar_resource(dev))
+ if (intel_alloc_mchbar_resource(dev_priv))
return;
dev_priv->mchbar_need_disable = true;
@@ -461,9 +456,8 @@ intel_setup_mchbar(struct drm_device *dev)
}
static void
-intel_teardown_mchbar(struct drm_device *dev)
+intel_teardown_mchbar(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
int mchbar_reg = INTEL_GEN(dev_priv) >= 4 ? MCHBAR_I965 : MCHBAR_I915;
if (dev_priv->mchbar_need_disable) {
@@ -493,9 +487,9 @@ intel_teardown_mchbar(struct drm_device *dev)
/* true = enable decode, false = disable decoder */
static unsigned int i915_vga_set_decode(void *cookie, bool state)
{
- struct drm_device *dev = cookie;
+ struct drm_i915_private *dev_priv = cookie;
- intel_modeset_vga_set_state(to_i915(dev), state);
+ intel_modeset_vga_set_state(dev_priv, state);
if (state)
return VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM |
VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM;
@@ -574,7 +568,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- ret = vga_client_register(pdev, dev, NULL, i915_vga_set_decode);
+ ret = vga_client_register(pdev, dev_priv, NULL, i915_vga_set_decode);
if (ret && ret != -ENODEV)
goto out;
@@ -823,7 +817,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
goto err_workqueues;
/* This must be called before any calls to HAS_PCH_* */
- intel_detect_pch(&dev_priv->drm);
+ intel_detect_pch(dev_priv);
intel_pm_setup(&dev_priv->drm);
intel_init_dpio(dev_priv);
@@ -865,9 +859,8 @@ static void i915_driver_cleanup_early(struct
drm_i915_private *dev_priv)
i915_workqueues_cleanup(dev_priv);
}
-static int i915_mmio_setup(struct drm_device *dev)
+static int i915_mmio_setup(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
int mmio_bar;
int mmio_size;
@@ -893,17 +886,16 @@ static int i915_mmio_setup(struct drm_device *dev)
}
/* Try to make sure MCHBAR is enabled before poking at it */
- intel_setup_mchbar(dev);
+ intel_setup_mchbar(dev_priv);
[Intel-gfx] [PATCH 09/10] drm/i915: Make i915_save/restore_state and intel_i2c_reset take dev_priv
From: Tvrtko Ursulin
dev_priv is more appropriate since it is used much more in these.
v2: Commit message and keep the local pdev variable. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
drivers/gpu/drm/i915/i915_suspend.c | 16 +++-
drivers/gpu/drm/i915/intel_i2c.c| 8 +++-
4 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 809315cad316..bd8994d02813 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1439,7 +1439,7 @@ static int i915_drm_suspend(struct drm_device *dev)
i915_gem_suspend_gtt_mappings(dev_priv);
- i915_save_state(dev);
+ i915_save_state(dev_priv);
opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
intel_opregion_notify_adapter(dev_priv, opregion_target_state);
@@ -1562,7 +1562,7 @@ static int i915_drm_resume(struct drm_device *dev)
i915_gem_resume(dev_priv);
- i915_restore_state(dev);
+ i915_restore_state(dev_priv);
intel_pps_unlock_regs_wa(dev_priv);
intel_opregion_setup(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2006ea033354..90ef5a09b40d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3470,8 +3470,8 @@ extern void i915_perf_register(struct drm_i915_private
*dev_priv);
extern void i915_perf_unregister(struct drm_i915_private *dev_priv);
/* i915_suspend.c */
-extern int i915_save_state(struct drm_device *dev);
-extern int i915_restore_state(struct drm_device *dev);
+extern int i915_save_state(struct drm_i915_private *dev_priv);
+extern int i915_restore_state(struct drm_i915_private *dev_priv);
/* i915_sysfs.c */
void i915_setup_sysfs(struct drm_i915_private *dev_priv);
@@ -3491,7 +3491,7 @@ static inline bool intel_gmbus_is_forced_bit(struct
i2c_adapter *adapter)
{
return container_of(adapter, struct intel_gmbus, adapter)->force_bit;
}
-extern void intel_i2c_reset(struct drm_device *dev);
+extern void intel_i2c_reset(struct drm_i915_private *dev_priv);
/* intel_bios.c */
int intel_bios_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index b0e1e7ca75da..5c86925a0294 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -56,13 +56,12 @@ static void i915_restore_display(struct drm_i915_private
*dev_priv)
i915_redisable_vga(dev_priv);
}
-int i915_save_state(struct drm_device *dev)
+int i915_save_state(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
int i;
- mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev_priv->drm.struct_mutex);
i915_save_display(dev_priv);
@@ -97,18 +96,17 @@ int i915_save_state(struct drm_device *dev)
dev_priv->regfile.saveSWF3[i] = I915_READ(SWF3(i));
}
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev_priv->drm.struct_mutex);
return 0;
}
-int i915_restore_state(struct drm_device *dev)
+int i915_restore_state(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
int i;
- mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev_priv->drm.struct_mutex);
i915_gem_restore_fences(dev_priv);
@@ -145,9 +143,9 @@ int i915_restore_state(struct drm_device *dev)
I915_WRITE(SWF3(i), dev_priv->regfile.saveSWF3[i]);
}
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev_priv->drm.struct_mutex);
- intel_i2c_reset(dev);
+ intel_i2c_reset(dev_priv);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 85faba415633..62fe529516b1 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -111,10 +111,8 @@ to_intel_gmbus(struct i2c_adapter *i2c)
}
void
-intel_i2c_reset(struct drm_device *dev)
+intel_i2c_reset(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
-
I915_WRITE(GMBUS0, 0);
I915_WRITE(GMBUS4, 0);
}
@@ -211,7 +209,7 @@ intel_gpio_pre_xfer(struct i2c_adapter *adapter)
adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
- intel_i2c_reset(&dev_priv->drm);
+ intel_i2c_reset(dev_priv);
intel_i2c_quirk_set(dev_priv, true);
set_data(bus, 1);
set_clock(bus, 1);
@@ -677,7 +675,7 @@ int intel_setup_gmbus(struct drm_i915_p
Re: [Intel-gfx] [PATCH 12/15] drm/i915: Zero out HOWM registers before writing new WM/HOWM register values
Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > On VLV/CHV some of the watermark values are split across two registers: > low order bits in one, and high order bits in another. So we may not be > able to update a single watermark value atomically, and thus we must be > careful that we don't temporarily introduce out of bounds values during > the reprogramming. To prevent this we can simply zero out all the high > order bits initially, then we update the low order bits, and finally > we update the high order bits with the final value. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_pm.c | 17 +++-- > 1 file changed, 11 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 9f25f2195a6a..8a3441bbff30 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -877,6 +877,17 @@ static void vlv_write_wm_values(struct intel_crtc *crtc, > (wm->ddl[pipe].plane[PLANE_SPRITE0] << DDL_SPRITE_SHIFT(0)) | > (wm->ddl[pipe].plane[PLANE_PRIMARY] << DDL_PLANE_SHIFT)); > > + /* > + * Zero the (unused) WM1 watermarks, and also clear all the > + * high order bits so that there are no out of bounds values > + * present in the registers during the reprogramming. > + */ > + I915_WRITE(DSPHOWM, 0); > + I915_WRITE(DSPHOWM1, 0); > + I915_WRITE(DSPFW4, 0); > + I915_WRITE(DSPFW5, 0); > + I915_WRITE(DSPFW6, 0); Watermarks for DSPHOWM are inverted right? And lower values just mean more wakeups? Should be harmless then. Reviewed-by: Maarten Lankhorst > I915_WRITE(DSPFW1, > FW_WM(wm->sr.plane, SR) | > FW_WM(wm->pipe[PIPE_B].plane[PLANE_CURSOR], CURSORB) | > @@ -924,12 +935,6 @@ static void vlv_write_wm_values(struct intel_crtc *crtc, > FW_WM(wm->pipe[PIPE_A].plane[PLANE_PRIMARY] >> 8, > PLANEA_HI)); > } > > - /* zero (unused) WM1 watermarks */ > - I915_WRITE(DSPFW4, 0); > - I915_WRITE(DSPFW5, 0); > - I915_WRITE(DSPFW6, 0); > - I915_WRITE(DSPHOWM1, 0); > - > POSTING_READ(DSPFW1); > } > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Protect DSPARB registers with a spinlock
Op 01-12-16 om 14:13 schreef Ville Syrjälä:
> On Thu, Dec 01, 2016 at 12:56:16PM +0100, Maarten Lankhorst wrote:
>> Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> Each DSPARB register can house bits for two separate pipes, hence
>>> we must protect the registers during reprogramming so that parallel
>>> FIFO reconfigurations happening simultaneosly on multiple pipes won't
>>> corrupt each others values.
>>>
>>> Signed-off-by: Ville Syrjälä
>>> ---
>>> drivers/gpu/drm/i915/i915_drv.c | 1 +
>>> drivers/gpu/drm/i915/i915_drv.h | 3 +++
>>> drivers/gpu/drm/i915/intel_pm.c | 6 ++
>>> 3 files changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>>> b/drivers/gpu/drm/i915/i915_drv.c
>>> index 0fba4bb5655e..c98032e9112b 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.c
>>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>>> @@ -811,6 +811,7 @@ static int i915_driver_init_early(struct
>>> drm_i915_private *dev_priv,
>>> spin_lock_init(&dev_priv->uncore.lock);
>>> spin_lock_init(&dev_priv->mm.object_stat_lock);
>>> spin_lock_init(&dev_priv->mmio_flip_lock);
>>> + spin_lock_init(&dev_priv->wm.dsparb_lock);
>> Can we make sure all wm updates are done with dev_priv->wm.wm_mutex held
>> instead?
> We can't grab a mutex from the vblank evade critical section. We'd have
> to hold the mutex across the whole thing then. Not sure if that would be
> a good or a bad thing.
Ah right, I missed that part since it didn't happen in the patches yet, might
be worth pointing out in the commit message.
Will vlv_wm_values also be updated with that lock in the future? Looks like it
could be a fun race otherwise.
>> gen9 wm's and ilk wm's use that mutex, for similar reasons.
>>> mutex_init(&dev_priv->sb_lock);
>>> mutex_init(&dev_priv->modeset_restore_lock);
>>> mutex_init(&dev_priv->av_mutex);
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index 9d808b706824..75439e9a67f7 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -2169,6 +2169,9 @@ struct drm_i915_private {
>>> } sagv_status;
>>>
>>> struct {
>>> + /* protects DSPARB registers on pre-g4x/vlv/chv */
>>> + spinlock_t dsparb_lock;
>>> +
>>> /*
>>> * Raw watermark latency values:
>>> * in 0.1us units for WM0,
>>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index 24d85a4e4ed3..9f25f2195a6a 100644
>>> --- a/drivers/gpu/drm/i915/intel_pm.c
>>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>>> @@ -1215,6 +1215,8 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
>>> *crtc)
>>> pipe_name(crtc->pipe), sprite0_start,
>>> sprite1_start, fifo_size);
>>>
>>> + spin_lock(&dev_priv->wm.dsparb_lock);
>>> +
>>> switch (crtc->pipe) {
>>> uint32_t dsparb, dsparb2, dsparb3;
>>> case PIPE_A:
>>> @@ -1271,6 +1273,10 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc
>>> *crtc)
>>> default:
>>> break;
>>> }
>>> +
>>> + POSTING_READ(DSPARB);
>>> +
>>> + spin_unlock(&dev_priv->wm.dsparb_lock);
>>> }
>>>
>>> #undef VLV_FIFO
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for GEM object create and driver init dev_priv cleanups (rev2)
== Series Details == Series: GEM object create and driver init dev_priv cleanups (rev2) URL : https://patchwork.freedesktop.org/series/16162/ State : warning == Summary == Series 16162v2 GEM object create and driver init dev_priv cleanups https://patchwork.freedesktop.org/api/1.0/series/16162/revisions/2/mbox/ Test kms_pipe_crc_basic: Subgroup bad-nb-words-1: pass -> DMESG-WARN (fi-ivb-3770) fi-bdw-5557u total:245 pass:226 dwarn:0 dfail:0 fail:4 skip:15 fi-bsw-n3050 total:245 pass:203 dwarn:0 dfail:0 fail:2 skip:40 fi-bxt-t5700 total:245 pass:213 dwarn:0 dfail:0 fail:4 skip:28 fi-byt-j1900 total:245 pass:214 dwarn:0 dfail:0 fail:3 skip:28 fi-byt-n2820 total:245 pass:210 dwarn:0 dfail:0 fail:3 skip:32 fi-hsw-4770 total:245 pass:221 dwarn:0 dfail:0 fail:4 skip:20 fi-hsw-4770r total:245 pass:221 dwarn:0 dfail:0 fail:4 skip:20 fi-ilk-650 total:245 pass:189 dwarn:0 dfail:0 fail:3 skip:53 fi-ivb-3520m total:245 pass:219 dwarn:0 dfail:0 fail:4 skip:22 fi-ivb-3770 total:245 pass:218 dwarn:1 dfail:0 fail:4 skip:22 fi-kbl-7500u total:245 pass:219 dwarn:0 dfail:0 fail:4 skip:22 fi-skl-6260u total:245 pass:227 dwarn:0 dfail:0 fail:4 skip:14 fi-skl-6700hqtotal:245 pass:220 dwarn:0 dfail:0 fail:4 skip:21 fi-skl-6700k total:245 pass:219 dwarn:1 dfail:0 fail:4 skip:21 fi-skl-6770hqtotal:245 pass:227 dwarn:0 dfail:0 fail:4 skip:14 fi-snb-2600 total:245 pass:209 dwarn:0 dfail:0 fail:3 skip:33 15f4397c9b50b0212dcb99fb2b5b8a3867133e81 drm-tip: 2016y-12m-01d-13h-26m-26s UTC integration manifest a6838f4 drm/i915: Make intel_pm_setup take dev_priv f2ef943 drm/i915: Make i915_save/restore_state and intel_i2c_reset take dev_priv 065196e drm/i915: Make i915_destroy_error_state take dev_priv 5e5a2ec drm/i915: Make gmbus setup take dev_priv 81ddb80 drm/i915: Unexport VGA switcheroo functions b8756a6 drm/i915: dev_priv cleanup in bridge/bar/mmio init code e74be3e drm/i915: More GEM init dev_priv cleanup 3f48e34 drm/i915: Make various init functions take dev_priv c6faec2 drm/i915: Make GEM object create and create from data take dev_priv b75f2e6 drm/i915: Make GEM object alloc/free and stolen created take dev_priv == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3162/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] drm/i915: Pass crtc state to vlv_compute_wm_level()
Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Rather than accessing crtc->config in vlv_compute_wm_level() let's
> pass in the crtc state explicitly. One step closer to atomic.
>
> Signed-off-by: Ville Syrjälä
Yay. All users of intel_crtc->config have to die in the future, but this is
temporarily a legit use for it.
For patch 13, 14 and 15
Reviewed-by: Maarten Lankhorst
> drivers/gpu/drm/i915/intel_pm.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 291843c2b61b..2a2aa8968b93 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -978,24 +978,26 @@ static void vlv_setup_wm_latency(struct
> drm_i915_private *dev_priv)
> }
> }
>
> -static uint16_t vlv_compute_wm_level(struct intel_plane *plane,
> - struct intel_crtc *crtc,
> - const struct intel_plane_state *state,
> +static uint16_t vlv_compute_wm_level(const struct intel_crtc_state
> *crtc_state,
> + const struct intel_plane_state
> *plane_state,
>int level)
> {
> + struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + const struct drm_display_mode *adjusted_mode =
> + &crtc_state->base.adjusted_mode;
> int clock, htotal, cpp, width, wm;
>
> if (dev_priv->wm.pri_latency[level] == 0)
> return USHRT_MAX;
>
> - if (!state->base.visible)
> + if (!plane_state->base.visible)
> return 0;
>
> - cpp = drm_format_plane_cpp(state->base.fb->pixel_format, 0);
> - clock = crtc->config->base.adjusted_mode.crtc_clock;
> - htotal = crtc->config->base.adjusted_mode.crtc_htotal;
> - width = crtc->config->pipe_src_w;
> + cpp = drm_format_plane_cpp(plane_state->base.fb->pixel_format, 0);
> + clock = adjusted_mode->crtc_clock;
> + htotal = adjusted_mode->crtc_htotal;
> + width = crtc_state->pipe_src_w;
> if (WARN_ON(htotal == 0))
> htotal = 1;
>
> @@ -1145,7 +1147,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
>
> /* normal watermarks */
> for (level = 0; level < wm_state->num_levels; level++) {
> - int wm = vlv_compute_wm_level(plane, crtc, state,
> level);
> + int wm = vlv_compute_wm_level(crtc->config, state,
> level);
> int max_wm = plane->wm.fifo_size;
>
> /* hack */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET
Hi, On 29-11-16 14:06, Hans de Goede wrote: p.s. I'm also trying to come up with some patches which properly integrate pwm-lpss with the i915 driver instead of it throwing a "Failed to own the pwm chip" error. But as soon as I hook up things so that pwm_get() returns the pwm-lpss pwm0 I hit: https://bugs.freedesktop.org/show_bug.cgi?id=97330 I get the same pipe-a stuck (or not seeing vblank irqs?) problems sometimes without the pwm-lpss driver in the loop but then only sometimes and with pwm-lpss I get this problem when loading the i915 driver most of the time (but not all the time). I've been debugging this a couple of evenings in a row now, but no luck sofar. Ok, a couple of more evenings of debugging + working on this today has finally resulted in me finding a fix :) The problem is that on driver load we call chv_pipe_power_well_ops.enable() which calls vlv_init_display_clock_gating() which clears the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D while the DSI panel is being driven by PIPE-A, as already documented in intel_dsi_pre_enable() allowing the DPOUNIT to get gated while DSI active will result in a stuck PIPE-A. I've written a patch for this, I'll send this right after this mail, and attach it to bug: https://bugs.freedesktop.org/show_bug.cgi?id=97330 Which I believe is the same issue. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 4.8.6, NULL pointer in __wake_up_common / drm / i915
On Wed, Nov 16, Olaf Hering wrote: > During boot into a current openSUSE Tumbleweed 20161108 this laptop > starts to hang sometimes with 4.8.x. Today I was able to catch this > crash in __wake_up_common caused by i915 or drm or whatever: > > ... > [ 69.851635] BUG: unable to handle kernel NULL pointer dereference at > (null) > [ 69.851754] IP: [] __wake_up_common+0x25/0x80 This still happens with 4.8.10. Any idea how to fix it? Olaf [0.00] microcode: microcode updated early to revision 0xa4, date = 2010-10-02 [0.00] Linux version 4.8.10-1-default (geeko@buildhost) (gcc version 6.2.1 20160830 [gcc-6-branch revision 239856] (SUSE Linux) ) #1 SMP PREEMPT Mon Nov 21 13:50:28 UTC 2016 (d1ec066) [0.00] Command line: BOOT_IMAGE=(lvm/sd240_crypt_lvm-sd240_btrfs)/tw_xfce/boot/vmlinuz quiet panic=9 net.ifnames=0 rootflags=subvol=/tw_xfce,noatime plymouth.enable=0 resume=/dev/disk/by-label/SD240_CRYPT_SWP [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'eager' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbf67] usable [0.00] BIOS-e820: [mem 0xbf68-0xbf690fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbf691000-0xbfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: FUJITSU SIEMENS ESPRIMO Mobile M9400/M11D, BIOS 1.06 - R059 - 1566 04/22/2008 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0C000 mask FC000 uncachable [0.00] 1 base 0 mask F write-back [0.00] 2 base 1 mask FC000 write-back [0.00] 3 base 0BF70 mask 0 uncachable [0.00] 4 base 0BF80 mask FFF80 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] e820: update [mem 0xbf70-0x] usable ==> reserved [0.00] e820: last_pfn = 0xbf680 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f77a0-0x000f77af] mapped at [8801c00f77a0] [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [8801c0099000] 99000 size 24576 [0.00] BRK [0x108262000, 0x108262fff] PGTABLE [0.00] BRK [0x108263000, 0x108263fff] PGTABLE [0.00] BRK [0x108264000, 0x108264fff] PGTABLE [0.00] BRK [0x108265000, 0x108265fff] PGTABLE [0.00] BRK [0x108266000, 0x108266fff] PGTABLE [0.00] BRK [0x108267000, 0x108267fff] PGTABLE [0.00] BRK [0x108268000, 0x108268fff] PGTABLE [0.00] BRK [0x108269000, 0x108269fff] PGTABLE [0.00] RAMDISK: [mem 0x35b33000-0x36d90fff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F7710 24 (v02 PTLTD ) [0.00] ACPI: XSDT 0xBF688021 8C (v01 FSCPC 0604 LTP ) [0.00] ACPI: FACP 0xBF68FD0C F4 (v03 INTEL CRESTLNE 0604 ALAN 0001) [0.00] ACPI: DSDT 0xBF689526 006772 (v02 IEC___ M11_ 0604 INTL 20050624) [0.00] ACPI: FACS 0xBF690FC0 40 [0.00] ACPI: FACS 0xBF690FC0 40 [0.00] ACPI: APIC 0xBF68FE00 68 (v01 INTEL CRESTLNE 0604 LOHR 005A) [0.00] ACPI: HPET 0xBF68FE68 38 (v01 INTEL CRESTLNE 0604 LOHR 005A) [0.00] ACPI: MCFG 0xBF68FEA0 3C (v01 INTEL CRESTLNE 0604 L
[Intel-gfx] [PATCH] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.
The getting stuck is caused by vlv_init_display_clock_gating() clearing
the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
chv_pipe_power_well_ops.enable() on driver load, while PIPE-A is enabled
driving the DSI LCD by the BIOS.
Clearing this bit while DSI is in use is a known issue and
intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
as appropriate.
This commit modifies vlv_init_display_clock_gating() to leave the
DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing PIPE-A getting stuck.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 356c662..b5ce7cb 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct
drm_i915_private *dev_priv,
static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
{
- I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
+ u32 val;
+
+ /*
+* When on driver load, PIPE A may be active and driving a DSI display.
+* Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid PIPE A getting stuck
+* (and never recovering) in this case. intel_dsi_post_disable() will
+* clear it when we turn off the display.
+*/
+ val = I915_READ(DSPCLK_GATE_D);
+ val &= DPOUNIT_CLOCK_GATE_DISABLE;
+ val |= VRHUNIT_CLOCK_GATE_DISABLE;
+ I915_WRITE(DSPCLK_GATE_D, val);
/*
* Disable trickle feed and enable pnd deadline calculation
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 1/8] drm/i915/skl: Add variables to check x_tile and y_tile
This patch adds variable to check for X_tiled & y_tiled planes, instead
of always checking against framebuffer-modifiers.
Changes:
- Created separate patch as per Paulo's comment
- Added x_tiled variable as well
Changes since V2:
- Incorporate Paulo's comments
- Rebase
Signed-off-by: Mahesh Kumar
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 29b6653..a467ffe 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3579,13 +3579,18 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
+ bool y_tiled, x_tiled;
if (latency == 0 || !cstate->base.active ||
!intel_pstate->base.visible) {
*enabled = false;
return 0;
}
- if (apply_memory_bw_wa && fb->modifier == I915_FORMAT_MOD_X_TILED)
+ y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED;
+ x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
+
+ if (apply_memory_bw_wa && x_tiled)
latency += 15;
width = drm_rect_width(&intel_pstate->base.src) >> 16;
@@ -3624,16 +3629,15 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
y_min_scanlines *= 2;
plane_bytes_per_line = width * cpp;
- if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+ if (y_tiled) {
plane_blocks_per_line =
DIV_ROUND_UP(plane_bytes_per_line * y_min_scanlines, 512);
plane_blocks_per_line /= y_min_scanlines;
- } else if (fb->modifier == DRM_FORMAT_MOD_NONE) {
+ } else if (x_tiled) {
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ } else {
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512)
+ 1;
- } else {
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
}
method1 = skl_wm_method1(plane_pixel_rate, cpp, latency);
@@ -3644,8 +3648,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
- if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+ if (y_tiled) {
selected_result = max(method2, y_tile_minimum);
} else {
if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
@@ -3661,8 +3664,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
res_lines = DIV_ROUND_UP(selected_result, plane_blocks_per_line);
if (level >= 1 && level <= 7) {
- if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
- fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+ if (y_tiled) {
res_blocks += y_tile_minimum;
res_lines += y_min_scanlines;
} else {
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 5/8] drm/i915/skl+: change WM calc to fixed point 16.16
This patch changes Watermak calculation to fixed point calculation.
Problem with current calculation is during plane_blocks_per_line
calculation we divide intermediate blocks with min_scanlines and
takes floor of the result because of integer operation.
hence we end-up assigning less blocks than required. Which leads to
flickers.
Changes since V1:
- Add fixed point data type as per Paulo's review
Changes since V2:
- use fixed_point instead of fp_16_16
Changes since V3:
- rebase
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 84 +
drivers/gpu/drm/i915/intel_pm.c | 69 +++--
2 files changed, 124 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64b0c90..b78dc9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -119,6 +119,90 @@ bool __i915_inject_load_failure(const char *func, int
line);
#define i915_inject_load_failure() \
__i915_inject_load_failure(__func__, __LINE__)
+typedef struct {
+ uint32_t val;
+} uint_fixed_16_16_t;
+
+#define FP_16_16_MAX ({ \
+ uint_fixed_16_16_t fp; \
+ fp.val = UINT_MAX; \
+ fp; \
+})
+
+static inline uint_fixed_16_16_t u32_to_fixed_point(uint32_t val)
+{
+ uint_fixed_16_16_t fp;
+
+ WARN_ON(val >> 16);
+
+ fp.val = val << 16;
+ return fp;
+}
+
+static inline uint32_t fixed_point_to_u32_round_up(uint_fixed_16_16_t fp)
+{
+ return DIV_ROUND_UP(fp.val, 1 << 16);
+}
+
+static inline uint32_t fixed_point_to_u32(uint_fixed_16_16_t fp)
+{
+ return (fp.val / (1 << 16));
+}
+
+static inline uint_fixed_16_16_t min_fixed_point(uint_fixed_16_16_t min1,
+ uint_fixed_16_16_t min2)
+{
+ uint_fixed_16_16_t min;
+
+ min.val = min(min1.val, min2.val);
+ return min;
+}
+
+static inline uint_fixed_16_16_t max_fixed_point(uint_fixed_16_16_t max1,
+ uint_fixed_16_16_t max2)
+{
+ uint_fixed_16_16_t max;
+
+ max.val = max(max1.val, max2.val);
+ return max;
+}
+
+static inline uint_fixed_16_16_t fixed_point_div_round_up(uint32_t val,
+ uint32_t d)
+{
+ uint_fixed_16_16_t fp, res;
+
+ fp = u32_to_fixed_point(val);
+ res.val = DIV_ROUND_UP(fp.val, d);
+ return res;
+}
+
+static inline uint_fixed_16_16_t fixed_point_div_round_up_u64(uint32_t val,
+ uint32_t d)
+{
+ uint_fixed_16_16_t res;
+ uint64_t interm_val;
+
+ interm_val = (uint64_t)val << 16;
+ interm_val = DIV_ROUND_UP_ULL(interm_val, d);
+ WARN_ON(interm_val >> 32);
+ res.val = (uint32_t) interm_val;
+
+ return res;
+}
+
+static inline uint_fixed_16_16_t mul_fixed_point_u32(uint32_t val,
+ uint_fixed_16_16_t mul)
+{
+ uint64_t intermediate_val;
+ uint_fixed_16_16_t fp;
+
+ intermediate_val = (uint64_t) val * mul.val;
+ WARN_ON(intermediate_val >> 32);
+ fp.val = (uint32_t) intermediate_val;
+ return fp;
+}
+
static inline const char *yesno(bool v)
{
return v ? "yes" : "no";
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8f0e6f5..cc8fc84 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3503,32 +3503,35 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
* should allow pixel_rate up to ~2 GHz which seems sufficient since max
* 2xcdclk is 1350 MHz and the pixel rate should never exceed that.
*/
-static uint32_t skl_wm_method1(uint32_t pixel_rate, uint8_t cpp, uint32_t
latency)
+static uint_fixed_16_16_t skl_wm_method1(uint32_t pixel_rate, uint8_t cpp,
+uint32_t latency)
{
- uint32_t wm_intermediate_val, ret;
+ uint32_t wm_intermediate_val;
+ uint_fixed_16_16_t ret;
if (latency == 0)
- return UINT_MAX;
-
- wm_intermediate_val = latency * pixel_rate * cpp / 512;
- ret = DIV_ROUND_UP(wm_intermediate_val, 1000);
+ return FP_16_16_MAX;
+ wm_intermediate_val = latency * pixel_rate * cpp;
+ ret = fixed_point_div_round_up_u64(wm_intermediate_val, 1000 * 512);
return ret;
}
-static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
- uint32_t latency, uint32_t plane_blocks_per_line)
+static uint_fixed_16_16_t skl_wm_method2(uint32_t pixel_rate,
+ uint32_t pipe_htotal,
+ uint32_t latency,
+ uint_fixed_16_16_t plane_blocks_per_line)
{
- uint32_t ret;
uint32_t wm_intermediate_val;
+ uint_fixed_16_16_t ret;
if (latency == 0)
- return UINT_MA
[Intel-gfx] [PATCH v7 4/8] drm/i915/bxt: Enable IPC support
This patch adds IPC support for platforms. This patch enables IPC
only for BXT/KBL platform as for SKL recommendation is to keep is disabled.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controles the memory read priority of Display.
When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.
Changes since V1:
- Remove commandline parameter to disable ipc
- Address Paulo's comments
Changes since V2:
- Address review comments
- Set ipc_enabled flag
Changes since V3:
- move ipc_enabled flag assignment inside intel_ipc_enable function
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 16
4 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f27e4bd..1c689b6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1251,7 +1251,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
intel_runtime_pm_enable(dev_priv);
- dev_priv->ipc_enabled = false;
+ intel_enable_ipc(dev_priv);
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6747d68..649319d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6418,6 +6418,7 @@ enum {
#define DISP_FBC_WM_DIS (1<<15)
#define DISP_ARB_CTL2 _MMIO(0x45004)
#define DISP_DATA_PARTITION_5_6 (1<<6)
+#define DISP_IPC_ENABLE (1<<3)
#define DBUF_CTL _MMIO(0x45008)
#define DBUF_POWER_REQUEST(1<<31)
#define DBUF_POWER_STATE (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9bbe5c5..3069512 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1755,6 +1755,7 @@ bool skl_ddb_allocation_overlaps(const struct
skl_ddb_entry **entries,
uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
bool ilk_disable_lp_wm(struct drm_device *dev);
int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
static inline int intel_enable_rc6(void)
{
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3650c74..8f0e6f5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4655,6 +4655,22 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
}
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ dev_priv->ipc_enabled = false;
+ if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
+ return;
+
+ val = I915_READ(DISP_ARB_CTL2);
+
+ val |= DISP_IPC_ENABLE;
+
+ I915_WRITE(DISP_ARB_CTL2, val);
+ dev_priv->ipc_enabled = true;
+}
+
/*
* Lock protecting IPS related data structures
*/
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC
This series implements following set of functionality Implement IPC WA's for Broxton/KBL Enable IPC in supported platforms Convert WM calculation to fixed point calculation Calculation of System memory Bandwidth for SKL/KBL/BXT Implementation of Arbitrated memory Bandwidth related WM WA's Mahesh Kumar (8): drm/i915/skl: Add variables to check x_tile and y_tile drm/i915/bxt: IPC WA for Broxton drm/i915/kbl: IPC workaround for kabylake drm/i915/bxt: Enable IPC support drm/i915/skl+: change WM calc to fixed point 16.16 drm/i915: Add intel_atomic_get_existing_crtc_state function drm/i915: Decode system memory bandwidth drm/i915/gen9: WM memory bandwidth related workaround drivers/gpu/drm/i915/i915_drv.c | 175 ++ drivers/gpu/drm/i915/i915_drv.h | 109 ++ drivers/gpu/drm/i915/i915_reg.h | 38 + drivers/gpu/drm/i915/intel_display.c | 24 drivers/gpu/drm/i915/intel_drv.h | 15 ++ drivers/gpu/drm/i915/intel_pm.c | 272 +-- 6 files changed, 586 insertions(+), 47 deletions(-) -- 2.10.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 7/8] drm/i915: Decode system memory bandwidth
This patch adds support to decode system memory bandwidth
which will be used for arbitrated display memory percentage
calculation in GEN9 based system.
Changes from v1:
- Address comments from Paulo
- implement decode function for SKL/KBL also
Changes from v2:
- Rewrite the code as per HW team inputs
- Addresses review comments
Changes from v3:
- Fix compilation warning
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 173
drivers/gpu/drm/i915/i915_drv.h | 12 +++
drivers/gpu/drm/i915/i915_reg.h | 37 +
3 files changed, 222 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1c689b6..0ac7122 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -979,6 +979,173 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
DRM_DEBUG_DRIVER("use GPU sempahores? %s\n", yesno(i915.semaphores));
}
+static inline enum rank skl_memdev_get_channel_rank(uint32_t val)
+{
+ uint8_t l_rank, s_rank;
+ uint8_t l_size, s_size;
+ enum rank ch_rank = DRAM_RANK_SINGLE;
+
+ l_size = (val >> SKL_DRAM_SIZE_L_SHIFT) & SKL_DRAM_SIZE_MASK;
+ s_size = (val >> SKL_DRAM_SIZE_S_SHIFT) & SKL_DRAM_SIZE_MASK;
+ l_rank = (val >> SKL_DRAM_RANK_L_SHIFT) & SKL_DRAM_RANK_MASK;
+ s_rank = (val >> SKL_DRAM_RANK_S_SHIFT) & SKL_DRAM_RANK_MASK;
+
+ /*
+* If any of the slot has dual rank memory consider
+* dual rank memory channel
+*/
+ if (l_rank == SKL_DRAM_RANK_DUAL || s_rank == SKL_DRAM_RANK_DUAL)
+ ch_rank = DRAM_RANK_DUAL;
+
+ /*
+* If both the slot has single rank memory then configuration
+* is dual rank memory
+*/
+ if ((l_size && l_rank == SKL_DRAM_RANK_SINGLE) &&
+ (s_size && s_rank == SKL_DRAM_RANK_SINGLE))
+ ch_rank = DRAM_RANK_DUAL;
+ return ch_rank;
+}
+
+static int
+skl_get_memdev_info(struct drm_i915_private *dev_priv)
+{
+ struct memdev_info *memdev_info = &dev_priv->memdev_info;
+ uint32_t mem_freq_khz;
+ uint32_t val;
+ enum rank ch0_rank = DRAM_RANK_INVALID, ch1_rank = DRAM_RANK_INVALID;
+
+ val = I915_READ(SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
+ mem_freq_khz = (val & SKL_REQ_DATA_MASK) *
+ SKL_MEMORY_FREQ_MULTIPLIER_KHZ;
+
+ val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
+ if (val != 0x0) {
+ memdev_info->num_channels++;
+ ch0_rank = skl_memdev_get_channel_rank(val);
+ }
+
+ val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
+ if (val != 0x0) {
+ memdev_info->num_channels++;
+ ch1_rank = skl_memdev_get_channel_rank(val);
+ }
+
+ if (memdev_info->num_channels == 0) {
+ DRM_ERROR("Number of mem channels are zero\n");
+ return -EINVAL;
+ }
+
+ memdev_info->bandwidth_kbps = (memdev_info->num_channels *
+ mem_freq_khz * 8);
+
+ if (memdev_info->bandwidth_kbps == 0) {
+ DRM_ERROR("Couldn't get system memory bandwidth\n");
+ return -EINVAL;
+ }
+ memdev_info->valid = true;
+
+ /*
+* If any of channel is single rank channel,
+* consider single rank memory
+*/
+ if (ch0_rank == DRAM_RANK_SINGLE || ch1_rank == DRAM_RANK_SINGLE)
+ memdev_info->rank = DRAM_RANK_SINGLE;
+ else
+ memdev_info->rank = max(ch0_rank, ch1_rank);
+
+ return 0;
+}
+
+static int
+bxt_get_memdev_info(struct drm_i915_private *dev_priv)
+{
+ struct memdev_info *memdev_info = &dev_priv->memdev_info;
+ uint32_t dram_channels;
+ uint32_t mem_freq_khz, val;
+ uint8_t num_active_channels;
+ int i;
+
+ val = I915_READ(BXT_P_CR_MC_BIOS_REQ_0_0_0);
+ mem_freq_khz = ((val & BXT_REQ_DATA_MASK) *
+ BXT_MEMORY_FREQ_MULTIPLIER_KHZ);
+
+ dram_channels = (val >> BXT_DRAM_CHANNEL_ACTIVE_SHIFT) &
+ BXT_DRAM_CHANNEL_ACTIVE_MASK;
+ num_active_channels = hweight32(dram_channels);
+
+ memdev_info->bandwidth_kbps = (mem_freq_khz * num_active_channels * 4);
+
+ if (memdev_info->bandwidth_kbps == 0) {
+ DRM_ERROR("Couldn't get system memory bandwidth\n");
+ return -EINVAL;
+ }
+ memdev_info->valid = true;
+
+ /*
+* Now read each DUNIT8/9/10/11 to check the rank of each dimms.
+*/
+ for (i = 0; i < BXT_D_CR_DRP0_DUNIT_MAX; i++) {
+ val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
+ if (val != 0x) {
+ uint8_t rank;
+ enum rank ch_rank;
+
+ memdev_info->num_channels++;
+
[Intel-gfx] [PATCH v7 3/8] drm/i915/kbl: IPC workaround for kabylake
Display Workarounds #1141 IPC (Isoch Priority Control) may cause underflows. KBL WA: When IPC is enabled, watermark latency values must be increased by 4us across all levels. This brings level 0 up to 6us. Changes since V1: - Add Workaround number in commit & code Signed-off-by: Mahesh Kumar Reviewed-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 89d8a28..3650c74 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3590,6 +3590,10 @@ static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv, fb->modifier == I915_FORMAT_MOD_Yf_TILED; x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED; + /* IPC WA for kabylake Display WA #1141 */ + if (IS_KABYLAKE(dev_priv) && dev_priv->ipc_enabled) + latency += 4; + if (apply_memory_bw_wa && x_tiled) latency += 15; -- 2.10.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/8] drm/i915/bxt: IPC WA for Broxton
Display Workarounds #1135
If IPC is enabled in BXT, display underruns are observed.
WA: The Line Time programmed in the WM_LINETIME register should be
half of the actual calculated Line Time.
Programmed Line Time = 1/2*Calculated Line Time
Changes since V1:
- Add Workaround number in commit & code
Signed-off-by: Mahesh Kumar
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b893e67..f27e4bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1251,6 +1251,8 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
intel_runtime_pm_enable(dev_priv);
+ dev_priv->ipc_enabled = false;
+
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver.name, driver.major, driver.minor, driver.patchlevel,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ec9619..64b0c90 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2306,6 +2306,8 @@ struct drm_i915_private {
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
+ bool ipc_enabled;
+
/* Used to save the pipe-to-encoder mapping for audio */
struct intel_encoder *av_enc_map[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a467ffe..89d8a28 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3755,7 +3755,10 @@ skl_compute_wm_level(const struct drm_i915_private
*dev_priv,
static uint32_t
skl_compute_linetime_wm(struct intel_crtc_state *cstate)
{
+ struct drm_atomic_state *state = cstate->base.state;
+ struct drm_i915_private *dev_priv = to_i915(state->dev);
uint32_t pixel_rate;
+ uint32_t linetime_wm;
if (!cstate->base.active)
return 0;
@@ -3765,8 +3768,13 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
if (WARN_ON(pixel_rate == 0))
return 0;
- return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
- pixel_rate);
+ linetime_wm = DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal *
+ 1000, pixel_rate);
+ /* Display WA #1135 for BXT:All */
+ if (IS_BROXTON(dev_priv) && dev_priv->ipc_enabled)
+ linetime_wm = DIV_ROUND_UP(linetime_wm, 2);
+
+ return linetime_wm;
}
static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 6/8] drm/i915: Add intel_atomic_get_existing_crtc_state function
This patch Adds a function to extract intel_crtc_state from the
atomic_state, if not available it returns NULL.
Signed-off-by: Mahesh Kumar
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_drv.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3069512..dbee392 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1804,6 +1804,20 @@ intel_atomic_get_crtc_state(struct drm_atomic_state
*state,
return to_intel_crtc_state(crtc_state);
}
+static inline struct intel_crtc_state *
+intel_atomic_get_existing_crtc_state(struct drm_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state, &crtc->base);
+
+ if (crtc_state)
+ return to_intel_crtc_state(crtc_state);
+ else
+ return NULL;
+}
+
static inline struct intel_plane_state *
intel_atomic_get_existing_plane_state(struct drm_atomic_state *state,
struct intel_plane *plane)
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 8/8] drm/i915/gen9: WM memory bandwidth related workaround
This patch implemnets Workariunds related to display arbitrated memory
bandwidth. These WA are applicabe for all gen-9 based platforms.
Changes since v1:
- Rebase on top of Paulo's patch series
Changes since v2:
- Address review comments
- Rebase/rework as per other patch changes in series
Changes since v3:
- Rework based on Maarten's comments
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 11 +++
drivers/gpu/drm/i915/intel_display.c | 24 ++
drivers/gpu/drm/i915/intel_pm.c | 155 +--
3 files changed, 181 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69213a4..3126259 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1216,6 +1216,13 @@ enum intel_sbi_destination {
SBI_MPHY,
};
+/* SKL+ Watermark arbitrated display bandwidth Workarounds */
+enum watermark_memory_wa {
+ WATERMARK_WA_NONE,
+ WATERMARK_WA_X_TILED,
+ WATERMARK_WA_Y_TILED,
+};
+
#define QUIRK_PIPEA_FORCE (1<<0)
#define QUIRK_LVDS_SSC_DISABLE (1<<1)
#define QUIRK_INVERT_BRIGHTNESS (1<<2)
@@ -1788,6 +1795,10 @@ struct skl_ddb_allocation {
struct skl_wm_values {
unsigned dirty_pipes;
+ /* any WaterMark memory workaround Required */
+ enum watermark_memory_wa mem_wa;
+ uint32_t pipe_bw_kbps[I915_MAX_PIPES];
+ bool pipe_ytiled[I915_MAX_PIPES];
struct skl_ddb_allocation ddb;
};
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5d11002..f8da488 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14574,6 +14574,28 @@ static void intel_atomic_track_fbs(struct
drm_atomic_state *state)
to_intel_plane(plane)->frontbuffer_bit);
}
+static void
+intel_update_wm_bw_wa(struct drm_atomic_state *state)
+{
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_i915_private *dev_priv = to_i915(state->dev);
+ const struct drm_crtc *crtc;
+ const struct drm_crtc_state *cstate;
+ struct skl_wm_values *results = &intel_state->wm_results;
+ struct skl_wm_values *hw_vals = &dev_priv->wm.skl_hw;
+ int i;
+
+ if (!IS_GEN9(dev_priv))
+ return;
+
+ for_each_crtc_in_state(state, crtc, cstate, i) {
+ hw_vals->pipe_bw_kbps[i] = results->pipe_bw_kbps[i];
+ hw_vals->pipe_ytiled[i] = results->pipe_ytiled[i];
+ }
+
+ hw_vals->mem_wa = results->mem_wa;
+}
+
/**
* intel_atomic_commit - commit validated state object
* @dev: DRM device
@@ -14614,6 +14636,8 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_commit(state);
intel_atomic_track_fbs(state);
+ intel_update_wm_bw_wa(state);
+
if (intel_state->modeset) {
memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
sizeof(intel_state->min_pixclk));
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cc8fc84..fda6e1e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2878,11 +2878,7 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
#define SKL_SAGV_BLOCK_TIME30 /* µs */
-/*
- * FIXME: We still don't have the proper code detect if we need to apply the
WA,
- * so assume we'll always need it in order to avoid underruns.
- */
-static bool skl_needs_memory_bw_wa(struct intel_atomic_state *state)
+static bool intel_needs_memory_bw_wa(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
@@ -3056,7 +3052,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
latency = dev_priv->wm.skl_latency[level];
- if (skl_needs_memory_bw_wa(intel_state) &&
+ if (intel_needs_memory_bw_wa(intel_state) &&
plane->base.state->fb->modifier ==
I915_FORMAT_MOD_X_TILED)
latency += 15;
@@ -3584,7 +3580,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint32_t y_min_scanlines;
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
- bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
+ enum watermark_memory_wa mem_wa;
bool y_tiled, x_tiled;
if (latency == 0 || !cstate->base.active ||
!intel_pstate->base.visible) {
@@ -3600,7 +3596,8 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if (IS_KABYLAKE(dev_priv) && dev_priv->ipc_enabled)
latency += 4;
- if (apply_memory_bw_wa && x_tiled)
+ mem_wa = state->wm_results.mem_wa;
+ if (mem_wa != WATERMARK_WA_NONE && x_tiled)
latency += 15;
width =
[Intel-gfx] ✓ Fi.CI.BAT: success for GEN-9 Arbitrated Bandwidth WM WA's & IPC (rev3)
== Series Details == Series: GEN-9 Arbitrated Bandwidth WM WA's & IPC (rev3) URL : https://patchwork.freedesktop.org/series/15562/ State : success == Summary == Series 15562v3 GEN-9 Arbitrated Bandwidth WM WA's & IPC https://patchwork.freedesktop.org/api/1.0/series/15562/revisions/3/mbox/ fi-bdw-5557u total:245 pass:226 dwarn:0 dfail:0 fail:4 skip:15 fi-bsw-n3050 total:245 pass:203 dwarn:0 dfail:0 fail:2 skip:40 fi-bxt-t5700 total:245 pass:213 dwarn:0 dfail:0 fail:4 skip:28 fi-byt-j1900 total:245 pass:214 dwarn:0 dfail:0 fail:3 skip:28 fi-byt-n2820 total:245 pass:210 dwarn:0 dfail:0 fail:3 skip:32 fi-hsw-4770 total:245 pass:221 dwarn:0 dfail:0 fail:4 skip:20 fi-hsw-4770r total:245 pass:221 dwarn:0 dfail:0 fail:4 skip:20 fi-ilk-650 total:245 pass:189 dwarn:0 dfail:0 fail:3 skip:53 fi-ivb-3520m total:245 pass:219 dwarn:0 dfail:0 fail:4 skip:22 fi-ivb-3770 total:245 pass:219 dwarn:0 dfail:0 fail:4 skip:22 fi-kbl-7500u total:245 pass:219 dwarn:0 dfail:0 fail:4 skip:22 fi-skl-6260u total:245 pass:227 dwarn:0 dfail:0 fail:4 skip:14 fi-skl-6700hqtotal:245 pass:220 dwarn:0 dfail:0 fail:4 skip:21 fi-skl-6700k total:245 pass:219 dwarn:1 dfail:0 fail:4 skip:21 fi-skl-6770hqtotal:245 pass:227 dwarn:0 dfail:0 fail:4 skip:14 fi-snb-2520m total:245 pass:210 dwarn:0 dfail:0 fail:3 skip:32 fi-snb-2600 total:245 pass:209 dwarn:0 dfail:0 fail:3 skip:33 15f4397c9b50b0212dcb99fb2b5b8a3867133e81 drm-tip: 2016y-12m-01d-13h-26m-26s UTC integration manifest b0ac9a9 drm/i915/gen9: WM memory bandwidth related workaround f84d26c drm/i915: Decode system memory bandwidth 338d933 drm/i915: Add intel_atomic_get_existing_crtc_state function 2b11985b drm/i915/skl+: change WM calc to fixed point 16.16 8e23bea drm/i915/bxt: Enable IPC support fcc35ec drm/i915/kbl: IPC workaround for kabylake 31150d7 drm/i915/bxt: IPC WA for Broxton c11e0c0 drm/i915/skl: Add variables to check x_tile and y_tile == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3163/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
