[Intel-gfx] [PATCH v4 1/2] drm: Use srcu to protect drm_device.unplugged
From: Noralf Trønnes
Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing access to device resources that are not available
after the device is gone.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
Tested-by: Oleksandr Andrushchenko
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 54 ++-
include/drm/drm_device.h | 9 +++-
include/drm/drm_drv.h | 15 +
3 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a1b9338736e3..32a83b41ab61 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -75,6 +76,8 @@ static bool drm_core_init_complete = false;
static struct dentry *drm_debugfs_root;
+DEFINE_STATIC_SRCU(drm_unplug_srcu);
+
/*
* DRM Minors
* A DRM device can provide several char-dev interfaces on the DRM-Major. Each
@@ -318,18 +321,51 @@ void drm_put_dev(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_put_dev);
-static void drm_device_set_unplugged(struct drm_device *dev)
+/**
+ * drm_dev_enter - Enter device critical section
+ * @dev: DRM device
+ * @idx: Pointer to index that will be passed to the matching drm_dev_exit()
+ *
+ * This function marks and protects the beginning of a section that should not
+ * be entered after the device has been unplugged. The section end is marked
+ * with drm_dev_exit(). Calls to this function can be nested.
+ *
+ * Returns:
+ * True if it is OK to enter the section, false otherwise.
+ */
+bool drm_dev_enter(struct drm_device *dev, int *idx)
+{
+ *idx = srcu_read_lock(&drm_unplug_srcu);
+
+ if (dev->unplugged) {
+ srcu_read_unlock(&drm_unplug_srcu, *idx);
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_dev_enter);
+
+/**
+ * drm_dev_exit - Exit device critical section
+ * @idx: index returned from drm_dev_enter()
+ *
+ * This function marks the end of a section that should not be entered after
+ * the device has been unplugged.
+ */
+void drm_dev_exit(int idx)
{
- smp_wmb();
- atomic_set(&dev->unplugged, 1);
+ srcu_read_unlock(&drm_unplug_srcu, idx);
}
+EXPORT_SYMBOL(drm_dev_exit);
/**
* drm_dev_unplug - unplug a DRM device
* @dev: DRM device
*
* This unplugs a hotpluggable DRM device, which makes it inaccessible to
- * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
+ * userspace operations. Entry-points can use drm_dev_enter() and
+ * drm_dev_exit() to protect device resources in a race free manner. This
* essentially unregisters the device like drm_dev_unregister(), but can be
* called while there are still open users of @dev.
*/
@@ -338,10 +374,18 @@ void drm_dev_unplug(struct drm_device *dev)
drm_dev_unregister(dev);
mutex_lock(&drm_global_mutex);
- drm_device_set_unplugged(dev);
if (dev->open_count == 0)
drm_dev_put(dev);
mutex_unlock(&drm_global_mutex);
+
+ /*
+* After synchronizing any critical read section is guaranteed to see
+* the new value of ->unplugged, and any critical section which might
+* still have seen the old value of ->unplugged is guaranteed to have
+* finished.
+*/
+ dev->unplugged = true;
+ synchronize_srcu(&drm_unplug_srcu);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7c4fa32f3fc6..3a0eac2885b7 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -46,7 +46,14 @@ struct drm_device {
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
- atomic_t unplugged; /**< Flag whether dev is dead */
+ /**
+* @unplugged:
+*
+* Flag to tell if the device has been unplugged.
+* See drm_dev_enter() and drm_dev_is_unplugged().
+*/
+ bool unplugged;
+
struct inode *anon_inode; /**< inode for private
address-space */
char *unique; /**< unique name of the device
*/
/*@} */
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index d23dcdd1bd95..7e545f5f94d3 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -624,6 +624,8 @@ void drm_dev_get(struct drm_device *dev);
void drm_dev_put(struct drm_device *dev);
void drm_dev_unref(struct drm_device *dev);
void drm_put_dev(struct drm_device *dev);
+bool drm_dev_enter(struct drm_device *dev, int *idx);
+void drm_dev_exit(int idx);
void drm_dev_unplug(struct drm_device *dev);
/**
@@ -635,11 +637,16 @@ void drm_dev_unplug(struct drm_device *dev);
* unplugged, t
[Intel-gfx] [PATCH 5/9] Revert "cpufreq: intel_pstate: Drop ->update_util from pstate_funcs"
This reverts commit c4f3f70cacba2fa19545389a12d09b606d2ad1cf. A
future commit will introduce a new update_util implementation, so the
pstate_funcs table entry is going to be useful.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index ef8f46ff7168..ef699a3a238f 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -267,6 +267,7 @@ static struct cpudata **all_cpu_data;
* @get_scaling: Callback to get frequency scaling factor
* @get_val: Callback to convert P state to actual MSR write value
* @get_vid: Callback to get VID data for Atom platforms
+ * @update_util: Active mode utilization update callback.
*
* Core and Atom CPU models have different way to get P State limits. This
* structure is used to store those callbacks.
@@ -280,6 +281,8 @@ struct pstate_funcs {
int (*get_aperf_mperf_shift)(void);
u64 (*get_val)(struct cpudata*, int pstate);
void (*get_vid)(struct cpudata *);
+ void (*update_util)(struct update_util_data *data, u64 time,
+ unsigned int flags);
};
static struct pstate_funcs pstate_funcs __read_mostly;
@@ -1570,6 +1573,7 @@ static struct pstate_funcs core_funcs = {
.get_turbo = core_get_turbo_pstate,
.get_scaling = core_get_scaling,
.get_val = core_get_val,
+ .update_util = intel_pstate_update_util,
};
static const struct pstate_funcs silvermont_funcs = {
@@ -1580,6 +1584,7 @@ static const struct pstate_funcs silvermont_funcs = {
.get_val = atom_get_val,
.get_scaling = silvermont_get_scaling,
.get_vid = atom_get_vid,
+ .update_util = intel_pstate_update_util,
};
static const struct pstate_funcs airmont_funcs = {
@@ -1590,6 +1595,7 @@ static const struct pstate_funcs airmont_funcs = {
.get_val = atom_get_val,
.get_scaling = airmont_get_scaling,
.get_vid = atom_get_vid,
+ .update_util = intel_pstate_update_util,
};
static const struct pstate_funcs knl_funcs = {
@@ -1600,6 +1606,7 @@ static const struct pstate_funcs knl_funcs = {
.get_aperf_mperf_shift = knl_get_aperf_mperf_shift,
.get_scaling = core_get_scaling,
.get_val = core_get_val,
+ .update_util = intel_pstate_update_util,
};
static const struct pstate_funcs bxt_funcs = {
@@ -1609,6 +1616,7 @@ static const struct pstate_funcs bxt_funcs = {
.get_turbo = core_get_turbo_pstate,
.get_scaling = core_get_scaling,
.get_val = core_get_val,
+ .update_util = intel_pstate_update_util,
};
#define ICPU(model, policy) \
@@ -1705,7 +1713,7 @@ static void intel_pstate_set_update_util_hook(unsigned
int cpu_num)
/* Prevent intel_pstate_update_util() from using stale data. */
cpu->sample.time = 0;
cpufreq_add_update_util_hook(cpu_num, &cpu->update_util,
-intel_pstate_update_util);
+pstate_funcs.update_util);
cpu->update_util_set = true;
}
@@ -2148,6 +2156,7 @@ static void __init copy_cpu_funcs(struct pstate_funcs
*funcs)
pstate_funcs.get_scaling = funcs->get_scaling;
pstate_funcs.get_val = funcs->get_val;
pstate_funcs.get_vid = funcs->get_vid;
+ pstate_funcs.update_util = funcs->update_util;
pstate_funcs.get_aperf_mperf_shift = funcs->get_aperf_mperf_shift;
}
@@ -2278,7 +2287,9 @@ static int __init intel_pstate_init(void)
if (x86_match_cpu(hwp_support_ids)) {
copy_cpu_funcs(&core_funcs);
- if (!no_hwp) {
+ if (no_hwp) {
+ pstate_funcs.update_util = intel_pstate_update_util;
+ } else {
hwp_active++;
intel_pstate.attr = hwp_cpufreq_attrs;
goto hwp_cpu_matched;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] SQUASH: cpufreq/intel_pstate: Enable LP controller based on ACPI FADT profile.
This is provided at Srinivas' request. The LP controller is disabled
for the moment on server FADT profiles in order to avoid disturbing
the performance behavior of small-core servers. In cases where the
default inferred from the BIOS FADT profile is suboptimal, the LP
controller can be forcefully enabled or disabled by passing
"intel_pstate=lp" or "intel_pstate=no_lp" respectively in the kernel
command line.
Signed-off-by: Francisco Jerez
---
Documentation/admin-guide/kernel-parameters.txt | 6 +
Documentation/admin-guide/pm/intel_pstate.rst | 7 ++
drivers/cpufreq/intel_pstate.c | 32 -
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 1d1d53f85ddd..0ba112696938 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1681,6 +1681,12 @@
per_cpu_perf_limits
Allow per-logical-CPU P-State performance control
limits using
cpufreq sysfs interface
+ lp
+ Force use of LP P-state controller. Overrides selection
+ derived from ACPI FADT profile. Has no effect if HWP is
+ available.
+ no_lp
+ Prevent use of LP P-state controller (see "lp"
parameter).
intremap= [X86-64, Intel-IOMMU]
on enable Interrupt Remapping (default)
diff --git a/Documentation/admin-guide/pm/intel_pstate.rst
b/Documentation/admin-guide/pm/intel_pstate.rst
index d2b6fda3d67b..a5885fc4c039 100644
--- a/Documentation/admin-guide/pm/intel_pstate.rst
+++ b/Documentation/admin-guide/pm/intel_pstate.rst
@@ -642,6 +642,13 @@ of them have to be prepended with the ``intel_pstate=``
prefix.
Use per-logical-CPU P-State limits (see `Coordination of P-state
Limits`_ for details).
+``lp``
+ Force use of LP P-state controller. Overrides selection derived
+ from ACPI FADT profile. Has no effect if HWP is available.
+
+``no_lp``
+ Prevent use of LP P-state controller (see "lp" parameter).
+
Diagnostics and Tuning
==
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index d4b5d0aaa282..d0e212387755 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2485,6 +2485,7 @@ static int intel_pstate_update_status(const char *buf,
size_t size)
static int no_load __initdata;
static int no_hwp __initdata;
+static int no_lp __initdata;
static int hwp_only __initdata;
static unsigned int force_load __initdata;
@@ -2507,8 +2508,12 @@ static void __init copy_cpu_funcs(struct pstate_funcs
*funcs)
pstate_funcs.get_scaling = funcs->get_scaling;
pstate_funcs.get_val = funcs->get_val;
pstate_funcs.get_vid = funcs->get_vid;
- pstate_funcs.update_util = funcs->update_util;
pstate_funcs.get_aperf_mperf_shift = funcs->get_aperf_mperf_shift;
+
+ if (no_lp)
+ pstate_funcs.update_util = intel_pstate_update_util;
+ else
+ pstate_funcs.update_util = funcs->update_util;
}
#ifdef CONFIG_ACPI
@@ -2690,6 +2695,25 @@ static int __init intel_pstate_init(void)
}
device_initcall(intel_pstate_init);
+#ifdef CONFIG_ACPI
+static bool __init is_server_acpi_profile(void)
+{
+ switch (acpi_gbl_FADT.preferred_profile) {
+ case PM_ENTERPRISE_SERVER:
+ case PM_SOHO_SERVER:
+ case PM_PERFORMANCE_SERVER:
+ return true;
+ default:
+ return false;
+ }
+}
+#else
+static bool __init is_server_acpi_profile(void)
+{
+ return false;
+}
+#endif
+
static int __init intel_pstate_setup(char *str)
{
if (!str)
@@ -2713,6 +2737,12 @@ static int __init intel_pstate_setup(char *str)
if (!strcmp(str, "per_cpu_perf_limits"))
per_cpu_limits = true;
+ no_lp = is_server_acpi_profile();
+ if (!strcmp(str, "lp"))
+ no_lp = 0;
+ if (!strcmp(str, "no_lp"))
+ no_lp = 1;
+
#ifdef CONFIG_ACPI
if (!strcmp(str, "support_acpi_ppc"))
acpi_ppc = true;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/9] cpufreq: Implement infrastructure keeping track of aggregated IO active time.
This provides an IO activity statistic to cpufreq governors
complementary to the IO wait time currently available to them. An IO
utilization estimated from this statistic which is significantly lower
than 100% can be interpreted as an indication that no IO devices are
utilized to their full throughput yet, and overall system performance
has a good chance of scaling with increasing CPU frequency. An IO
utilization close to 100% indicates that at all times there was at
least one active IO device, in which case the system is not guaranteed
to be able to accomplish more work per unit of time even if the CPU
frequency could be increased further, providing an opportunity for the
cpufreq governor to save energy.
This patch uses a fairly minimal lockless approach to keep track of IO
activity time that only relies on an atomic counter of the number of
IO jobs in flight and another atomic variable that accumulates the
total amount of time spent with at least one active IO job since
system boot. IO utilization can be estimated by the cpufreq governor
by periodically sampling increments of IO active time and dividing
them by the increment of the system monotonic clock.
Under some circumstances it may be more accurate to estimate IO
utilization as the maximum IO utilization across all IO devices, which
could be achieved with a somewhat more complex tree-like data
structure (the present approach is roughly equivalent for IO jobs that
are executed simultaneously, but IO jobs that aren't overlapping in
time will show up as the sum of the individual utilizations of each IO
device, which might be biased towards 100% if the non-overlapping jobs
were actually parallelizable), OTOH in cases where the tasks performed
by different IO devices are interdependent the present approach
provides a more accurate estimate (while the alternative approach
would be biased towards 0% and would likely result in less
energy-efficient behavior of the cpufreq governor).
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/cpufreq.c | 204 ++
include/linux/cpufreq.h | 20 +
2 files changed, 224 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index de33ebf008ad..892709d0722e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2444,6 +2444,210 @@ int cpufreq_boost_enabled(void)
}
EXPORT_SYMBOL_GPL(cpufreq_boost_enabled);
+/*
+ * IO ACTIVE TIME ACCOUNTING *
+ */
+
+/**
+ * Number of times cpufreq_io_active_begin() has been called so far without a
+ * matching cpufreq_io_active_end(), or IOW, the approximate number of IO jobs
+ * currently in flight.
+ */
+static atomic_t io_active_count;
+
+/**
+ * Total aggregated time that io_active_count has been greater than zero since
+ * system boot. Negative values (in two's complement) represent a duration
+ * relative to the current time (typically used to implement the section
+ * between matching cpufreq_io_active_begin() and cpufreq_io_active_end()
+ * calls). Positive values represent absolute durations and are smaller than
+ * IO_ACTIVE_TIME_M in magnitude. In order to prevent the reduced integer
+ * range from introducing more frequent time wraparounds than in the rest of
+ * the kernel, time is represented with slightly lower precision than a
+ * ktime_t, in units of 4 ns.
+ */
+static atomic64_t io_active_time;
+
+/**
+ * Time of system boot, or one plus the maximum encoding of an absolute time
+ * duration. Values greater or equal to this constant in magnitude are used to
+ * represent points in time rather than time durations, this guarantees that
+ * the maximum representable time duration can be subtracted from any point in
+ * time and still give a positive number as result, which is important due to
+ * the somewhat special semantics of the sign of io_active_time.
+ */
+#define IO_ACTIVE_TIME_M ((uint64_t)1 << 62)
+
+/**
+ * Return true if @t is a negative io_active_time value encoding a time
+ * duration relative to the current time.
+ */
+static bool io_active_time_is_relative(uint64_t t)
+{
+ return t >> 63;
+}
+
+/**
+ * Convert a duration or point in time into a scalar value in nanoseconds.
+ */
+static uint64_t io_active_time_to_ns(uint64_t t)
+{
+ return (t & (IO_ACTIVE_TIME_M - 1)) << 2;
+}
+
+/**
+ * Convert a scalar time value in nanoseconds into a point in time.
+ */
+static uint64_t io_active_time_from_ns(uint64_t ns)
+{
+ return IO_ACTIVE_TIME_M + (ns >> 2);
+}
+
+/**
+ * Mark the beginning of the processing of an IO job. Each call of
+ * cpufreq_io_active_begin() must be accompanied by a corresponding call of
+ * cpufreq_io_active_end() after the IO job completes.
+ */
+void cpufreq_io_active_begin(void)
+{
+ /*
+* The body of the conditional below is ex
[Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.
This series attempts to solve an energy efficiency problem of the current active-mode non-HWP governor of the intel_pstate driver used for the most part on low-power platforms. Under heavy IO load the current controller tends to increase frequencies to the maximum turbo P-state, partly due to IO wait boosting, partly due to the roughly flat frequency response curve of the current controller (see [6]), which causes it to ramp frequencies up and down repeatedly for any oscillating workload (think of graphics, audio or disk IO when any of them becomes a bottleneck), severely increasing energy usage relative to a (throughput-wise equivalent) controller able to provide the same average frequency without fluctuation. The core energy efficiency improvement has been observed to be of the order of 20% via RAPL, but it's expected to vary substantially between workloads (see perf-per-watt comparison [2]). One might expect that this could come at some cost in terms of system responsiveness, but the governor implemented in PATCH 6 has a variable response curve controlled by a heuristic that keeps the controller in a low-latency state unless the system is under heavy IO load for an extended period of time. The low-latency behavior is actually significantly more aggressive than the current governor, allowing it to achieve better throughput in some scenarios where the load ping-pongs between the CPU and some IO device (see PATCH 6 for more of the rationale). The controller offers relatively lower latency than the upstream one particularly while C0 residency is low (which by itself contributes to mitigate the increased energy usage while on C0). However under certain conditions the low-latency heuristic may increase power consumption (see perf-per-watt comparison [2], the apparent regressions are correlated with an increase in performance in the same benchmark due to the use of the low-latency heuristic) -- If this is a problem a different trade-off between latency and energy usage shouldn't be difficult to achieve, but it will come at a performance cost in some cases. I couldn't observe a statistically significant increase in idle power consumption due to this behavior (on BXT J3455): package-0 RAPL (W):XX ±0.14% x8 -> XX ±0.15% x9 d=-0.04% ±0.14% p=61.73% [Absolute benchmark results are unfortunately omitted from this letter due to company policies, but the percent change and Student's T p-value are included above and in the referenced benchmark results] The most obvious impact of this series will likely be the overall improvement in graphics performance on systems with an IGP integrated into the processor package (though for the moment this is only enabled on BXT+), because the TDP budget shared among CPU and GPU can frequently become a limiting factor in low-power devices. On heavily TDP-bound devices this series improves performance of virtually any non-trivial graphics rendering by a significant amount (of the order of the energy efficiency improvement for that workload assuming the optimization didn't cause it to become non-TDP-bound). See [1]-[5] for detailed numbers including various graphics benchmarks and a sample of the Phoronix daily-system-tracker. Some popular graphics benchmarks like GfxBench gl_manhattan31 and gl_4 improve between 5% and 11% on our systems. The exact improvement can vary substantially between systems (compare the benchmark results from the two different J3455 systems [1] and [3]) due to a number of factors, including the ratio between CPU and GPU processing power, the behavior of the userspace graphics driver, the windowing system and resolution, the BIOS (which has an influence on the package TDP), the thermal characteristics of the system, etc. Unigine Valley and Heaven improve by a similar factor on some systems (see the J3455 results [1]), but on others the improvement is lower because the benchmark fails to fully utilize the GPU, which causes the heuristic to remain in low-latency state for longer, which leaves a reduced TDP budget available to the GPU, which prevents performance from increasing further. This can be avoided by using the alternative heuristic parameters suggested in the commit message of PATCH 8, which provide a lower IO utilization threshold and hysteresis for the controller to attempt to save energy. I'm not proposing those for upstream (yet) because they would also increase the risk for latency-sensitive IO-heavy workloads to regress (like SynMark2 OglTerrainFly* and some arguably poorly designed IPC-bound X11 benchmarks). Discrete graphics aren't likely to experience that much of a visible improvement from this, even though many non-IGP workloads *could* benefit by reducing the system's energy usage while the discrete GPU (or really, any other IO device) becomes a bottleneck, but this is not attempted in this series, since that would involve making an energy efficiency/latency trade-off that only the maintainers of th
[Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq.
This allows cpufreq governors to realize when the system becomes
non-CPU-bound due to GPU rendering activity, which will cause the
intel_pstate LP controller to behave more conservatively: CPU energy
usage will be reduced when there isn't a good chance for system
performance to scale with CPU frequency. This leaves additional TDP
budget available for the GPU to reach higher frequencies, which is
translated into an improvement in graphics performance to the extent
that the workload remains TDP-limited (Most non-trivial graphics
benchmarks out there improve significantly in TDP-constrained
platforms, see the cover letter for some numbers). If the workload
isn't (anymore) TDP-limited performance should stay roughly constant,
but energy usage will be divided by a similar factor.
The intel_pstate LP controller is only enabled on BXT+ small-core
platforms at this point, so this shouldn't have any effect on other
systems.
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/i915/intel_lrc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3a69b367e565..721f915115bd 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -132,6 +132,7 @@
*
*/
#include
+#include
#include
#include
@@ -379,11 +380,13 @@ execlists_context_schedule_in(struct i915_request *rq)
{
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(rq->engine);
+ cpufreq_io_active_begin();
}
static inline void
execlists_context_schedule_out(struct i915_request *rq)
{
+ cpufreq_io_active_end();
intel_engine_context_out(rq->engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
}
@@ -726,6 +729,7 @@ execlists_cancel_port_requests(struct
intel_engine_execlists * const execlists)
struct i915_request *rq = port_request(port);
GEM_BUG_ON(!execlists->active);
+ cpufreq_io_active_end();
intel_engine_context_out(rq->engine);
execlists_context_status_change(rq,
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] Revert "cpufreq: intel_pstate: Shorten a couple of long names"
This reverts one half of commit
d77d4888cb8458b098accd4d7555c0f7f6399c4e. It moves back to the old
name of get_target_pstate_use_cpu_load(), because a future commit will
introduce a new P-state target calculation function. The shortened
name of INTEL_PSTATE_SAMPLING_INTERVAL is left untouched.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index fe847d086926..e21645f0fd3a 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1442,7 +1442,7 @@ static inline int32_t get_avg_pstate(struct cpudata *cpu)
cpu->sample.core_avg_perf);
}
-static inline int32_t get_target_pstate(struct cpudata *cpu)
+static inline int32_t get_target_pstate_use_cpu_load(struct cpudata *cpu)
{
struct sample *sample = &cpu->sample;
int32_t busy_frac, boost;
@@ -1507,7 +1507,7 @@ static void intel_pstate_adjust_pstate(struct cpudata
*cpu)
update_turbo_state();
- target_pstate = get_target_pstate(cpu);
+ target_pstate = get_target_pstate_use_cpu_load(cpu);
target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
trace_cpu_frequency(target_pstate * cpu->pstate.scaling, cpu->cpu);
intel_pstate_update_pstate(cpu, target_pstate);
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] cpufreq/intel_pstate: Implement variably low-pass filtering controller for small core.
This introduces a controller for low-power parts that takes advantage
of the IO active time statistic introduced earlier in order to adjust
the trade-off between responsiveness and energy efficiency of the
heuristic dynamically. This allows it to achieve lower energy
consumption when the system is far enough from the CPU-bound end of
the IO utilization statistic. In low-latency mode the controller is
actually somewhat more aggressive than the current one due to its use
of the APER/MPERF ratio (particularly if C0 residency is low, which by
itself partly mitigates the lower energy efficiency of the aggressive
heuristic) -- See the comments below for the rationale.
The heuristic is tuned to roughly match the performance numbers of the
current governor (which is rather aggressive) in latency-bound
test-cases, so the energy-saving behavior won't kick in with the
current calibration except when heavily IO-bound for some time. The
RT and DL scheduling flags could potentially provide a useful
additional variable for the heuristic to decide whether the workload
is latency-sensitive, allowing it to save power in other
(non-IO-bound) cases, but this is not attempted in this series since
there would be an increased risk of performance regressions due to
latency-sensitive tasks not marked RT or DL.
For the moment this is only enabled on BXT in order to reduce the
extent of any unexpected fallout, but it should work on other
low-power platforms if it's hooked up to the right pstate_funcs table
(at your own risk).
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 357 -
1 file changed, 353 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index ef699a3a238f..d4b5d0aaa282 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -61,6 +61,11 @@ static inline int32_t mul_fp(int32_t x, int32_t y)
return ((int64_t)x * (int64_t)y) >> FRAC_BITS;
}
+static inline int rnd_fp(int32_t x)
+{
+ return (x + (1 << (FRAC_BITS - 1))) >> FRAC_BITS;
+}
+
static inline int32_t div_fp(s64 x, s64 y)
{
return div64_s64((int64_t)x << FRAC_BITS, y);
@@ -171,6 +176,23 @@ struct vid_data {
int32_t ratio;
};
+/**
+ * struct lp_data - LP controller parameters and state.
+ * @sample_interval_ns: Update interval in ns
+ * @last_io_active_ns: Cumulative IO active time in ns observed at the
+ * last sample.
+ * @setpoint:Target CPU utilization at which the controller is
+ * expected to leave the current P-state untouched, as
+ * a fixed-point fraction.
+ * @p_base: Low-pass filtered P-state as a fixed-point fraction.
+ */
+struct lp_data {
+ s64 sample_interval_ns;
+ uint64_t last_io_active_ns;
+ int32_t setpoint;
+ int32_t p_base;
+};
+
/**
* struct global_params - Global parameters, mostly tunable via sysfs.
* @no_turbo: Whether or not to use turbo P-states.
@@ -234,6 +256,7 @@ struct cpudata {
struct pstate_data pstate;
struct vid_data vid;
+ struct lp_data lp;
u64 last_update;
u64 last_sample_time;
@@ -258,6 +281,28 @@ struct cpudata {
static struct cpudata **all_cpu_data;
+/**
+ * struct lp_params - LP controller static configuration
+ * @sample_interval_ms: Update interval in ms
+ * @setpoint_pml:Target CPU utilization at which the controller is
+ * expected to leave the current P-state untouched,
+ * as an integer per mille.
+ * @p_base_avg_hz: Exponential averaging frequency of the P-state
+ * low-pass filter as an integer in Hz.
+ * @io_active_threshold_pml: IO utilization threshold at which the controller
+ * should transition to a higher latency low-pass
+ * filtering mode, as an integer per mille.
+ * @io_active_avg_hz:Exponential averaging frequency of the IO
+ * utilization statistic as an integer in Hz.
+ */
+struct lp_params {
+ int sample_interval_ms;
+ int setpoint_pml;
+ int p_base_avg_hz;
+ int io_active_threshold_pml;
+ int io_active_avg_hz;
+};
+
/**
* struct pstate_funcs - Per CPU model specific callbacks
* @get_max: Callback to get maximum non turbo effective P state
@@ -286,6 +331,13 @@ struct pstate_funcs {
};
static struct pstate_funcs pstate_funcs __read_mostly;
+static struct lp_params lp_params __read_mostly = {
+ .sample_interval_ms = 10,
+ .setpoint_pml = 700,
+ .p_base_avg_hz = 3,
+ .io_active_threshold_pml = 983,
+ .io_active_avg_hz = 3
+};
static int hwp_active __read_mostly;
static bool per_cpu_limits __read_mostly;
@@ -1483,6 +1535,285 @@ static inline int32_t
get_target_pstate_
[Intel-gfx] [PATCH 2/9] Revert "cpufreq: intel_pstate: Replace bxt_funcs with core_funcs"
This reverts commit dbd49b85eec7eb6d7ae61bad8306d5cdd85c142d. A
future commit will introduce a new update_util implementation for LP
platforms, so the bxt_funcs table comes in handy.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 6d084c61ee25..fe847d086926 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1600,6 +1600,15 @@ static const struct pstate_funcs knl_funcs = {
.get_val = core_get_val,
};
+static const struct pstate_funcs bxt_funcs = {
+ .get_max = core_get_max_pstate,
+ .get_max_physical = core_get_max_pstate_physical,
+ .get_min = core_get_min_pstate,
+ .get_turbo = core_get_turbo_pstate,
+ .get_scaling = core_get_scaling,
+ .get_val = core_get_val,
+};
+
#define ICPU(model, policy) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_APERFMPERF,\
(unsigned long)&policy }
@@ -1623,8 +1632,8 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
ICPU(INTEL_FAM6_BROADWELL_XEON_D, core_funcs),
ICPU(INTEL_FAM6_XEON_PHI_KNL, knl_funcs),
ICPU(INTEL_FAM6_XEON_PHI_KNM, knl_funcs),
- ICPU(INTEL_FAM6_ATOM_GOLDMONT, core_funcs),
- ICPU(INTEL_FAM6_ATOM_GEMINI_LAKE, core_funcs),
+ ICPU(INTEL_FAM6_ATOM_GOLDMONT, bxt_funcs),
+ ICPU(INTEL_FAM6_ATOM_GEMINI_LAKE, bxt_funcs),
ICPU(INTEL_FAM6_SKYLAKE_X, core_funcs),
{}
};
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] OPTIONAL: cpufreq/intel_pstate: Expose LP controller parameters via debugfs.
This is not required for the controller to work but has proven very
useful for debugging and testing of alternative heuristic parameters,
which may offer a better trade-off between energy efficiency and
latency -- The default parameters are rather aggressively
latency-minimizing in order to keep up with the big-core controller
and avoid regressions in latency-sensitive applications, however a
more energy-efficient trade-off may be preferable in practice. E.g.:
{
.sample_interval_ms = 10,
.setpoint_pml = 700,
.p_base_avg_hz = 3,
.io_active_threshold_pml = 950,
.io_active_avg_hz = 10
}
A warning is printed out which should taint the kernel for the
non-standard calibration of the heuristic to be obvious in bug
reports.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 90 ++
1 file changed, 90 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index d0e212387755..7b1666c34273 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -862,6 +862,92 @@ static void intel_pstate_update_policies(void)
cpufreq_update_policy(cpu);
}
+/** debugfs begin /
+static void intel_pstate_lp_reset(struct cpudata *cpu);
+
+static int lp_param_set(void *data, u64 val)
+{
+ unsigned int cpu;
+
+ *(u32 *)data = val;
+ for_each_possible_cpu(cpu) {
+ if (all_cpu_data[cpu])
+ intel_pstate_lp_reset(all_cpu_data[cpu]);
+ }
+
+ WARN_ONCE(1, "Unsupported P-state LP parameter update via debugging
interface");
+
+ return 0;
+}
+
+static int lp_param_get(void *data, u64 *val)
+{
+ *val = *(u32 *)data;
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(fops_lp_param, lp_param_get, lp_param_set, "%llu\n");
+
+static struct dentry *debugfs_parent;
+
+struct lp_param {
+ char *name;
+ void *value;
+ struct dentry *dentry;
+};
+
+static struct lp_param lp_files[] = {
+ {"lp_sample_interval_ms", &lp_params.sample_interval_ms, },
+ {"lp_setpoint_pml", &lp_params.setpoint_pml, },
+ {"lp_p_base_avg_hz", &lp_params.p_base_avg_hz, },
+ {"lp_io_active_threshold_pml", &lp_params.io_active_threshold_pml, },
+ {"lp_io_active_avg_hz", &lp_params.io_active_avg_hz, },
+ {NULL, NULL, }
+};
+
+static void intel_pstate_update_util_lp(struct update_util_data *data,
+ u64 time, unsigned int flags);
+
+static void intel_pstate_debug_expose_params(void)
+{
+ int i;
+
+ if (hwp_active ||
+ pstate_funcs.update_util != intel_pstate_update_util_lp)
+ return;
+
+ debugfs_parent = debugfs_create_dir("pstate_snb", NULL);
+ if (IS_ERR_OR_NULL(debugfs_parent))
+ return;
+
+ for (i = 0; lp_files[i].name; i++) {
+ struct dentry *dentry;
+
+ dentry = debugfs_create_file(lp_files[i].name, 0660,
+debugfs_parent, lp_files[i].value,
+&fops_lp_param);
+ if (!IS_ERR(dentry))
+ lp_files[i].dentry = dentry;
+ }
+}
+
+static void intel_pstate_debug_hide_params(void)
+{
+ int i;
+
+ if (IS_ERR_OR_NULL(debugfs_parent))
+ return;
+
+ for (i = 0; lp_files[i].name; i++) {
+ debugfs_remove(lp_files[i].dentry);
+ lp_files[i].dentry = NULL;
+ }
+
+ debugfs_remove(debugfs_parent);
+ debugfs_parent = NULL;
+}
+
+/** debugfs end /
+
/** sysfs begin /
#define show_one(file_name, object)\
static ssize_t show_##file_name \
@@ -2423,6 +2509,8 @@ static int intel_pstate_register_driver(struct
cpufreq_driver *driver)
global.min_perf_pct = min_perf_pct_min();
+ intel_pstate_debug_expose_params();
+
return 0;
}
@@ -2431,6 +2519,8 @@ static int intel_pstate_unregister_driver(void)
if (hwp_active)
return -EBUSY;
+ intel_pstate_debug_hide_params();
+
cpufreq_unregister_driver(intel_pstate_driver);
intel_pstate_driver_cleanup();
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] Revert "cpufreq: intel_pstate: Simplify intel_pstate_adjust_pstate()"
This reverts commit a891283e56362543d1d276e192266069ef52075b. The
previous approach of taking an explicit P-state target as argument
makes it more easily reusable by a future commit.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index e21645f0fd3a..ef8f46ff7168 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1499,15 +1499,13 @@ static void intel_pstate_update_pstate(struct cpudata
*cpu, int pstate)
wrmsrl(MSR_IA32_PERF_CTL, pstate_funcs.get_val(cpu, pstate));
}
-static void intel_pstate_adjust_pstate(struct cpudata *cpu)
+static void intel_pstate_adjust_pstate(struct cpudata *cpu, int target_pstate)
{
int from = cpu->pstate.current_pstate;
struct sample *sample;
- int target_pstate;
update_turbo_state();
- target_pstate = get_target_pstate_use_cpu_load(cpu);
target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
trace_cpu_frequency(target_pstate * cpu->pstate.scaling, cpu->cpu);
intel_pstate_update_pstate(cpu, target_pstate);
@@ -1557,8 +1555,12 @@ static void intel_pstate_update_util(struct
update_util_data *data, u64 time,
return;
set_pstate:
- if (intel_pstate_sample(cpu, time))
- intel_pstate_adjust_pstate(cpu);
+ if (intel_pstate_sample(cpu, time)) {
+ int target_pstate;
+
+ target_pstate = get_target_pstate_use_cpu_load(cpu);
+ intel_pstate_adjust_pstate(cpu, target_pstate);
+ }
}
static struct pstate_funcs core_funcs = {
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: make drm_core_check_feature() bool that it is
On Tue, 27 Mar 2018, Chris Wilson wrote: > Quoting Jani Nikula (2018-03-27 21:47:22) >> Bool is the more appropriate return type here, use it. >> >> Signed-off-by: Jani Nikula > > All 3, > Reviewed-by: Chris Wilson Thanks, all pushed to drm-misc-next. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm: prefer inline over __inline__
== Series Details == Series: series starting with [1/3] drm: prefer inline over __inline__ URL : https://patchwork.freedesktop.org/series/40760/ State : success == Summary == Known issues: Test kms_cursor_crc: Subgroup cursor-128x128-suspend: dmesg-warn -> PASS (shard-snb) fdo#102365 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race-interruptible: fail -> PASS (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 +1 Subgroup flip-vs-absolute-wf_vblank-interruptible: pass -> FAIL (shard-hsw) fdo#100368 +1 Test kms_rotation_crc: Subgroup sprite-rotation-180: pass -> FAIL (shard-snb) fdo#103925 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3495 pass:1832 dwarn:1 dfail:0 fail:7 skip:1655 time:12938s shard-hswtotal:3495 pass:1781 dwarn:1 dfail:0 fail:3 skip:1709 time:11526s shard-snbtotal:3495 pass:1373 dwarn:1 dfail:0 fail:4 skip:2117 time:6988s Blacklisted hosts: shard-kbltotal:3475 pass:1942 dwarn:2 dfail:1 fail:8 skip:1521 time:9493s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8507/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper
On Tue, 27 Mar 2018, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> As more differentation occurs between DP spec. Its useful to have these
> as macros in a drm_dp_helper.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/amd/display/include/dpcd_defs.h | 8
> include/drm/drm_dp_helper.h | 5 +
> 2 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/include/dpcd_defs.h
> b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
> index d8e52e3..d13e0f4 100644
> --- a/drivers/gpu/drm/amd/display/include/dpcd_defs.h
> +++ b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
> @@ -28,14 +28,6 @@
>
> #include
>
> -enum dpcd_revision {
> - DPCD_REV_10 = 0x10,
> - DPCD_REV_11 = 0x11,
> - DPCD_REV_12 = 0x12,
> - DPCD_REV_13 = 0x13,
> - DPCD_REV_14 = 0x14
> -};
> -
> /* these are the types stored at DOWNSTREAMPORT_PRESENT */
> enum dpcd_downstream_port_type {
> DOWNSTREAM_DP = 0,
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 4de97e9..f77746e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,11 @@
> /* AUX CH addresses */
> /* DPCD */
> #define DP_DPCD_REV 0x000
> +# define DPCD_REV_100x10
> +# define DPCD_REV_110x11
> +# define DPCD_REV_120x12
> +# define DPCD_REV_130x13
> +# define DPCD_REV_140x14
I'm not really sure what these buy us... but no harm done I
guess. Please prefix with DP_ though.
BR,
Jani.
>
> #define DP_MAX_LINK_RATE0x001
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw
== Series Details == Series: series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw URL : https://patchwork.freedesktop.org/series/40759/ State : failure == Summary == Possible new issues: Test drm_mm: Subgroup sanitycheck: pass -> INCOMPLETE (shard-apl) Test drv_hangman: Subgroup error-state-basic: pass -> INCOMPLETE (shard-apl) Subgroup error-state-capture-blt: pass -> INCOMPLETE (shard-apl) Subgroup hangcheck-unterminated: pass -> INCOMPLETE (shard-apl) Test drv_selftest: Subgroup live_guc: pass -> SKIP (shard-apl) Subgroup live_hangcheck: pass -> DMESG-FAIL (shard-apl) Test gem_eio: Subgroup execbuf: pass -> INCOMPLETE (shard-apl) Subgroup in-flight-external: pass -> INCOMPLETE (shard-apl) Test gem_mocs_settings: Subgroup mocs-reset-vebox: pass -> INCOMPLETE (shard-apl) Test gem_ringfill: Subgroup basic-default-hang: pass -> INCOMPLETE (shard-apl) Test kms_cursor_crc: Subgroup cursor-128x128-suspend: dmesg-warn -> PASS (shard-snb) Test kms_flip: Subgroup flip-vs-panning-vs-hang-interruptible: pass -> INCOMPLETE (shard-apl) Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: pass -> SKIP (shard-snb) Test kms_vblank: Subgroup pipe-a-query-idle-hang: pass -> INCOMPLETE (shard-apl) Subgroup pipe-a-wait-forked-busy: pass -> SKIP (shard-snb) Subgroup pipe-c-query-busy-hang: pass -> INCOMPLETE (shard-apl) Subgroup pipe-c-query-forked-hang: pass -> INCOMPLETE (shard-apl) Test perf: Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Test pm_rpm: Subgroup debugfs-read: pass -> DMESG-WARN (shard-apl) Known issues: Test drv_missed_irq: pass -> SKIP (shard-apl) fdo#103199 Test gem_eio: Subgroup in-flight-suspend: pass -> INCOMPLETE (shard-apl) fdo#103375 Subgroup suspend: pass -> INCOMPLETE (shard-apl) fdo#103927 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race-interruptible: fail -> PASS (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-expired-vblank-interruptible: fail -> PASS (shard-hsw) fdo#102887 +1 Subgroup 2x-plain-flip-ts-check: pass -> FAIL (shard-hsw) fdo#100368 Test kms_rotation_crc: Subgroup sprite-rotation-180: pass -> FAIL (shard-snb) fdo#103925 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#103199 https://bugs.freedesktop.org/show_bug.cgi?id=103199 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:2115 pass:1059 dwarn:2 dfail:1 fail:5 skip:1022 time:3044s shard-hswtotal:3495 pass:1782 dwarn:1 dfail:0 fail:2 skip:1709 time:11596s shard-snbtotal:3495 pass:1371 dwarn:1 dfail:0 fail:4 skip:2119 time:6949s Blacklisted hosts: shard-kbltotal:2098 pass:1095 dwarn:3 dfail:1 fail:3 skip:971 time:2232s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8506/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y coordinate requirement
Selective update testing
play a video and check 0x60094 , (03, 06) will indicated that system
is in su state.
-Original Message-
From: Vivi, Rodrigo
Sent: Wednesday, March 28, 2018 3:07 AM
To: Pandiyan, Dhinakaran
Cc: Souza, Jose ; intel-gfx@lists.freedesktop.org;
Nagaraju, Vathsala
Subject: Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y
coordinate requirement
On Fri, Mar 23, 2018 at 07:34:34PM -0700, Pandiyan, Dhinakaran wrote:
>
> On Fri, 2018-03-23 at 23:51 +, Souza, Jose wrote:
> > On Fri, 2018-03-23 at 15:59 -0700, Pandiyan, Dhinakaran wrote:
> > >
> > >
> > > On Thu, 2018-03-22 at 14:48 -0700, José Roberto de Souza wrote:
> > > > Move to only one place the sink requirements that the actual
> > > > driver needs to enable PSR2.
> > > >
> > > > Also intel_psr2_config_valid() is called every time the crtc
> > > > config is computed, wasting some time every time it was checking
> > > > for Y coordinate requirement.
> > > >
> > > > This allow us to nuke y_cord_support and some of VSC setup code
> > > > that was handling a scenario that would never happen(PSR2
> > > > without Y coordinate).
> > > >
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Rodrigo Vivi
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 -
> > > > drivers/gpu/drm/i915/intel_psr.c | 46
> > > > +---
> > > >
> > > > 2 files changed, 19 insertions(+), 28 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h index
> > > > 7fe00509e51a..cce32686fd75 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -603,7 +603,6 @@ struct i915_psr {
> > > > unsigned busy_frontbuffer_bits;
> > > > bool psr2_support;
> > > > bool link_standby;
> > > > - bool y_cord_support;
> > > > bool colorimetry_support;
> > > > bool alpm;
> > > > bool has_hw_tracking;
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index d46320a451d9..23f38ab10636 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct
> > > > intel_dp
> > > > *intel_dp)
> > > > intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
> > > > }
> > > >
> > > > -static bool intel_dp_get_y_cord_status(struct intel_dp
> > > > *intel_dp)
> > > > +static bool intel_dp_get_y_coord_required(struct intel_dp
> > > > *intel_dp)
> > > > {
> > > > uint8_t psr_caps = 0;
> > > >
> > > > @@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp
> > > > *intel_dp)
> > > > drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp-
> > > > >psr_dpcd,
> > > > sizeof(intel_dp->psr_dpcd));
> > > >
> > > > - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > > > + if (intel_dp->psr_dpcd[0]) {
> > > > dev_priv->psr.sink_support = true;
> > > > DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > > > }
> > > >
> > > > if (INTEL_GEN(dev_priv) >= 9 &&
> > > > - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > > > -
> > > > - dev_priv->psr.sink_support = true;
> > > > - dev_priv->psr.psr2_support = true;
> > > > + (intel_dp->psr_dpcd[0] ==
> > > > DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> > > > + /*
> > > > +* All panels that supports PSR version 03h (PSR2
> > > > +
> > > > +* Y-coordinate) can handle Y-coordinates in VSC
> > > > but we are
> > > > +* only sure that it is going to be used when
> > > > required by the
> > > > +* panel. This way panel is capable to do
> > > > selective update
> > > > +* without a aux frame sync.
> > >
> > > Can you cite this from the spec please? just the "panel is capable
> > > to do selective update without a aux frame sync" part. Or you
> > > could just remove that line so that we can get this patch reviewed
> > > and merged.
> >
> > There is no such statement in spec like this, the closest that it
> > have
> > is:
> > "When the Source device includes the optional Y-coordinate in the
> > SDP for PSR2 Operation, as described in Table 6-12, the Sink device
> > can implement a lower-precision GTC Slave function, as described in
> > Table 7-1."
> >
> > But we know that this works by all the previous tests when enabling
> > PSR2 and I also tested it.
>
> Please do update the comment to say so. Do you know if these tests for
> PSR2 selective update are in IGT? Or were these manual tests?
>
> Rodrigo/Vathsala, any idea how selective update was and can be tested?
nope :(
>
> The patch as such makes sense to me
> Reviewed-by: Dhin
Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17
On 2018.03.27 16:42:28 +0300, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2018-03-27 11:39:42)
> >
> > Hi, Joonas
> >
> > Here's this week's gvt-next-fixes queued for 4.17. One notable change
> > is to revert previous workaround for gvt context preemption, now it
> > has full support for preemption now.
>
> I've pulled the patches, but this revert sounds fishy. Is it something
> that should have been done together with a commit in a batch introduced
> to 4.17? To me, this sounds much like a feature patch, "enable
> pre-emption on GVT context" is even written in the tag.
>
> So I'm inclined to drop this patch from -fixes pull.
>
The dependent fix has already been queued for 4.17 as commit 702791f7f204
("drm/i915: add schedule out notification of preempted but completed request"),
and before we could revert previous workaround, we had a regression issue which
was later resolved, so this revert was delayed for regression verification and
validation. And now it has passed our full testing, so I consider to push it for
4.17 instead of still keeping previous workaround...
> Is there some specific reason why you don't use Fixes: tagging to
> make it easier to track which patches the fixes apply to, if there are
> some?
yeah, sorry, that's missed. Will fix that against workaround commit and re-send
this pull. Will that be fine for you?
thanks
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2)
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2) URL : https://patchwork.freedesktop.org/series/40764/ State : success == Summary == Series 40764v2 series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts https://patchwork.freedesktop.org/api/1.0/series/40764/revisions/2/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (fi-cfl-s3) fdo#100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:436s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:443s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:544s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:304s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:515s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:524s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:510s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s3total:285 pass:258 dwarn:0 dfail:0 fail:1 skip:26 time:561s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:517s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:594s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:429s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:321s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:425s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:476s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:432s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:477s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:471s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:662s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:498s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:591s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:523s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:486s 0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC integration manifest f0a06fa9b3f8 drm/i915: Include the HW breadcrumb whenever we trace the global_seqno 46afadd21cba drm/i915/execlists: Delay updating ring register state after resume ef3a65fcec9e drm/i915/execlists: Reset ring registers on rebinding contexts == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8513/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2)
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts (rev2) URL : https://patchwork.freedesktop.org/series/40764/ State : warning == Summary == $ dim checkpatch origin/drm-tip ef3a65fcec9e drm/i915/execlists: Reset ring registers on rebinding contexts -:36: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #36: FILE: drivers/gpu/drm/i915/intel_lrc.c:1275: + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; ^ total: 0 errors, 0 warnings, 1 checks, 7 lines checked 46afadd21cba drm/i915/execlists: Delay updating ring register state after resume -:68: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #68: FILE: drivers/gpu/drm/i915/intel_lrc.c:2566: + ce->lrc_reg_state[CTX_RING_HEAD+1] = 0; ^ -:69: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #69: FILE: drivers/gpu/drm/i915/intel_lrc.c:2567: + ce->lrc_reg_state[CTX_RING_TAIL+1] = 0; ^ total: 0 errors, 0 warnings, 2 checks, 52 lines checked f0a06fa9b3f8 drm/i915: Include the HW breadcrumb whenever we trace the global_seqno ___ 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 [v5,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev5)
== Series Details == Series: series starting with [v5,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev5) URL : https://patchwork.freedesktop.org/series/40503/ State : success == Summary == Series 40503v5 series starting with [v5,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads https://patchwork.freedesktop.org/api/1.0/series/40503/revisions/5/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (fi-snb-2520m) fdo#100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:448s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:545s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:299s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:515s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:530s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:512s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:409s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:569s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:508s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:582s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:428s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:320s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:423s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:473s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:433s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:473s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:471s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:516s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:658s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:444s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:535s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:508s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:445s fi-snb-2520m total:285 pass:244 dwarn:0 dfail:0 fail:1 skip:40 time:552s Blacklisted hosts: fi-cnl-psr total:285 pass:248 dwarn:11 dfail:0 fail:0 skip:26 time:515s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:488s 0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC integration manifest 791751056113 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads 4c68480f0be0 drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8512/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances
Em Ter, 2018-03-27 às 15:42 -0700, Paulo Zanoni escreveu:
> Em Sex, 2018-03-23 às 16:28 +, Lionel Landwerlin escreveu:
> > Hi Mika,
> >
> > Even after this series, we're still missing support for reading
> > the
> > timestamp frequency (read_timestamp_frequency in
> > intel_device_info.c).
> > I'm pretty sure someone wrote a patch for it. Do you any idea?
> >
> > If not, I can send something.
>
> Yes, we have them. I'll see if I missed them while upstreaming and
> resend in that case.
https://patchwork.freedesktop.org/patch/196710/
Hey Lionel, the Reviewed-by stamp you gave on the patch was before we
upstreamed it, so we need you (or someone else) to re-check the patch
and re-issue the reviewed-by tag. We do this because of the rebasing
that happened between the R-B tag and the upstreaming, since issues can
be introduced in between. If you can check the patch again and validate
the r-b tag (or point the issues) then we can move forward and
hopefully merge it.
Thanks,
Paulo
>
> >
> > Thanks,
> >
> > -
> > Lionel
> >
> > On 16/03/18 12:14, Mika Kuoppala wrote:
> > > From: Oscar Mateo
> > >
> > > In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD)
> > > and the
> > > Video Enhancement engines (aka VEBOX, aka VECS) could be fused
> > > off.
> > > Also,
> > > each VDBOX and VEBOX has its own power well, which only exist if
> > > the related
> > > engine exists in the HW.
> > >
> > > Unfortunately, we have a Catch-22 situation going on: we need the
> > > blitter
> > > forcewake to read the register with the fuse info, but we cannot
> > > initialize
> > > the forcewake domains without knowin about the engines present in
> > > the HW.
> > > We workaround this problem by allowing the initialization of all
> > > forcewake
> > > domains and then pruning the fused off ones, as per the fuse
> > > information.
> > >
> > > Bspec: 20680
> > >
> > > v2: We were shifting incorrectly for vebox disable (Vinay)
> > >
> > > v3: Assert mmio is ready and warn if we have attempted to
> > > initialize
> > > forcewake for fused-off engines (Paulo)
> > >
> > > v4:
> > >- Use INTEL_GEN in new code (Tvrtko)
> > >- Shorter local variable (Tvrtko, Michal)
> > >- Keep "if (!...) continue" style (Tvrtko)
> > >- No unnecessary BUG_ON (Tvrtko)
> > >- WARN_ON and cleanup if wrong mask (Tvrtko, Michal)
> > >- Use I915_READ_FW (Michal)
> > >- Use I915_MAX_VCS/VECS macros (Michal)
> > >
> > > v5: Rebased by Rodrigo fixing conflicts on top of:
> > > commit 33def1ff7b0 ("drm/i915: Simplify intel_engines_init")
> > >
> > > v6: Fix v5. Remove info->num_rings. (by Oscar)
> > >
> > > v7: Rebase (Rodrigo).
> > >
> > > v8:
> > >-
> > > s/intel_device_info_fused_off_engines/intel_device_info_init_mmio
> > > (Chris)
> > >- Make vdbox_disable & vebox_disable local variables (Chris)
> > >
> > > v9:
> > >- Move function declaration to intel_device_info.h (Michal)
> > >- Missing indent in bit fields definitions (Michal)
> > >- When RC6 is enabled by BIOS, the fuse register cannot be
> > > read
> > > until
> > > the blitter powerwell is awake. Shuffle where the fuse is
> > > read, prune
> > > the forcewake domains after the fact and change the commit
> > > message
> > > accordingly (Vinay, Sagar, Chris).
> > >
> > > v10:
> > >- Improved commit message (Sagar)
> > >- New line in header file (Sagar)
> > >- Specify the message in fw_domain_reset applies to ICL+
> > > (Sagar)
> > >
> > > Cc: Paulo Zanoni
> > > Cc: Vinay Belgaumkar
> > > Cc: Tvrtko Ursulin
> > > Cc: Michal Wajdeczko
> > > Cc: Chris Wilson
> > > Cc: Daniele Ceraolo Spurio
> > > Cc: Sagar Arun Kamble
> > > Signed-off-by: Rodrigo Vivi
> > > Signed-off-by: Oscar Mateo
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.c | 4 +++
> > > drivers/gpu/drm/i915/i915_reg.h | 5 +++
> > > drivers/gpu/drm/i915/intel_device_info.c | 47
> > > +++
> > > drivers/gpu/drm/i915/intel_device_info.h | 2 ++
> > > drivers/gpu/drm/i915/intel_uncore.c | 56
> > >
> > > drivers/gpu/drm/i915/intel_uncore.h | 1 +
> > > 6 files changed, 115 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 3df5193487f3..83df8e21cec0 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1033,6 +1033,10 @@ static int i915_driver_init_mmio(struct
> > > drm_i915_private *dev_priv)
> > >
> > > intel_uncore_init(dev_priv);
> > >
> > > + intel_device_info_init_mmio(dev_priv);
> > > +
> > > + intel_uncore_prune(dev_priv);
> > > +
> > > intel_uc_init_mmio(dev_priv);
> > >
> > > ret = intel_engines_init_mmio(dev_priv);
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index cf7c837d6a09..982e72e73e99 100644
> > > --- a/
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper
== Series Details == Series: series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper URL : https://patchwork.freedesktop.org/series/40768/ State : success == Summary == Series 40768v1 series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper https://patchwork.freedesktop.org/api/1.0/series/40768/revisions/1/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:542s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:519s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:529s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:514s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:514s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:591s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:423s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:326s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:467s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:431s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:475s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:517s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:668s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:543s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:505s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:495s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:445s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:520s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:485s 0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC integration manifest 553565ba74e0 drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4 d10b9c355a96 drm/dp: Move DPCD_REV_XX to drm_dp_helper == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8511/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.
Quoting Tomasz Lis (2018-03-27 16:17:59)
> The patch adds support of preempt-to-idle requesting by setting a proper
> bit within Execlist Control Register, and receiving preemption result from
> Context Status Buffer.
>
> Preemption in previous gens required a special batch buffer to be executed,
> so the Command Streamer never preempted to idle directly. In Icelake it is
> possible, as there is a hardware mechanism to inform the kernel about
> status of the preemption request.
>
> This patch does not cover using the new preemption mechanism when GuC is
> active.
>
> Bspec: 18922
> Signed-off-by: Tomasz Lis
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_lrc.c | 45
> +++-
> drivers/gpu/drm/i915/intel_lrc.h | 1 +
> 5 files changed, 45 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 800230b..c32580b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2514,6 +2514,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> ((dev_priv)->info.has_logical_ring_elsq)
> #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
> ((dev_priv)->info.has_logical_ring_preemption)
> +#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
> + ((dev_priv)->info.has_hw_preempt_to_idle)
>
> #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 4364922..66b6700 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -595,7 +595,8 @@ static const struct intel_device_info
> intel_cannonlake_info = {
> GEN(11), \
> .ddb_size = 2048, \
> .has_csr = 0, \
> - .has_logical_ring_elsq = 1
> + .has_logical_ring_elsq = 1, \
> + .has_hw_preempt_to_idle = 1
>
> static const struct intel_device_info intel_icelake_11_info = {
> GEN11_FEATURES,
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 933e316..4eb97b5 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -98,6 +98,7 @@ enum intel_platform {
> func(has_logical_ring_contexts); \
> func(has_logical_ring_elsq); \
> func(has_logical_ring_preemption); \
> + func(has_hw_preempt_to_idle); \
> func(has_overlay); \
> func(has_pooled_eu); \
> func(has_psr); \
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ba7f783..1a22de4 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -153,6 +153,7 @@
> #define GEN8_CTX_STATUS_ACTIVE_IDLE(1 << 3)
> #define GEN8_CTX_STATUS_COMPLETE (1 << 4)
> #define GEN8_CTX_STATUS_LITE_RESTORE (1 << 15)
> +#define GEN11_CTX_STATUS_PREEMPT_IDLE (1 << 29)
>
> #define GEN8_CTX_STATUS_COMPLETED_MASK \
> (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
> @@ -183,7 +184,9 @@ static inline bool need_preempt(const struct
> intel_engine_cs *engine,
> const struct i915_request *last,
> int prio)
> {
> - return engine->i915->preempt_context && prio > max(rq_prio(last), 0);
> + return (engine->i915->preempt_context ||
> + HAS_HW_PREEMPT_TO_IDLE(engine->i915)) &&
Well, you haven't actually disabled allocating the preempt_context so...
But at any rate, making this an engine->flag would eliminate one pointer
dance.
> +prio > max(rq_prio(last), 0);
> }
>
> /**
> @@ -535,6 +538,25 @@ static void inject_preempt_context(struct
> intel_engine_cs *engine)
> execlists_set_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT);
> }
>
> +static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
> +{
> + struct intel_engine_execlists *execlists = &engine->execlists;
> +
> + GEM_TRACE("%s\n", engine->name);
> +
> + /*
> +* hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
> +* HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
> +*/
> + GEM_BUG_ON(execlists->ctrl_reg != NULL);
> +
> + /* trigger preemption to idle */
> + writel(EL_CTRL_PREEMPT_TO_IDLE, execlists->ctrl_reg);
Future plans? Because just inserting the branch into the setter of
inject_preempt_context() resolves a lot of conflicts with other work.
> @@ -962,10 +987,13 @@ static void execlists_submission_tasklet(unsigned long
> data)
> status, buf[2*head + 1],
> execlists->active);
>
> - if (status & (GEN8_CTX_STATUS_IDLE_ACTIVE |
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper
== Series Details == Series: series starting with [1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper URL : https://patchwork.freedesktop.org/series/40768/ State : warning == Summary == $ dim checkpatch origin/drm-tip d10b9c355a96 drm/dp: Move DPCD_REV_XX to drm_dp_helper 553565ba74e0 drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4 -:26: WARNING:TYPO_SPELLING: 'seperate' may be misspelled - perhaps 'separate'? #26: V9: Strip out DPCD_REV_XX into seperate patch total: 0 errors, 1 warnings, 0 checks, 43 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Support for Guc responses and requests (rev5)
== Series Details == Series: drm/i915/guc: Support for Guc responses and requests (rev5) URL : https://patchwork.freedesktop.org/series/28393/ State : success == Summary == Series 28393v5 drm/i915/guc: Support for Guc responses and requests https://patchwork.freedesktop.org/api/1.0/series/28393/revisions/5/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-cnl-y3) fdo#104951 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:439s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:543s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:305s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:517s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:523s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:510s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:572s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:512s fi-cnl-y3total:285 pass:258 dwarn:1 dfail:0 fail:0 skip:26 time:586s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:428s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:321s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:412s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:475s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:437s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:476s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:657s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:508s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:504s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:432s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:448s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:584s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:513s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:487s 0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC integration manifest a5e34053ad2d HAX: Enable GuC for CI a87384b1c925 drm/i915/guc: Trace messages from CT while in debug fc751997667a drm/i915/guc: Handle default action received over CT 5f5795f24ab3 drm/i915/guc: Prepare to process incoming requests from CT f631277cfde8 drm/i915/guc: Implement response handling in send_ct() afa15bb29b63 drm/i915/guc: Use better name for helper wait function b7159298221d drm/i915/guc: Prepare to handle messages from CT RECV buffer 58acb5af66e4 drm/i915/guc: Make event handler a virtual function 55dddb9679fe drm/i915/guc: Implement response handling in send_mmio() e0bdc40b09d3 drm/i915/guc: Prepare send() function to accept bigger response 02a3b07b6d97 drm/i915/guc: Add support for data reporting in GuC responses 8da80e5819e2 drm/i915/guc: Add documentation for MMIO based communication == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8510/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
Quoting Zhang, Yunwei (2018-03-27 23:49:27)
>
>
> On 3/27/2018 3:27 PM, Chris Wilson wrote:
> > Quoting Yunwei Zhang (2018-03-27 23:14:16)
> >> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> >> read into Slice/Subslice specific registers, MCR packet control
> >> register(0xFDC) needs to be programmed to point to any enabled
> >> slice/subslice pair. Otherwise, incorrect value will be returned.
> >>
> >> However, that means each subsequent MMIO read will be forwarded to a
> >> specific slice/subslice combination as read is unicast. This is OK since
> >> slice/subslice specific register values are consistent in almost all cases
> >> across slice/subslice. There are rare occasions such as INSTDONE that this
> >> value will be dependent on slice/subslice combo, in such cases, we need to
> >> program 0xFDC and recover this after. This is already covered by
> >> read_subslice_reg.
> >>
> >> Also, 0xFDC will lose its information after TDR/engine reset/power state
> >> change.
> >>
> >> References: HSD#1405586840, BSID#0575
> >>
> >> v2:
> >> - use fls() instead of find_last_bit() (Chris)
> >> - added INTEL_SSEU to extract sseu from device info. (Chris)
> >> v3:
> >> - rebase on latest tip
> >> v5:
> >> - Added references (Mika)
> >> - Change the ordered of passing arguments and etc. (Ursulin)
> >>
> >> Cc: Oscar Mateo
> >> Cc: Michel Thierry
> >> Cc: Joonas Lahtinen
> >> Cc: Chris Wilson
> >> Cc: Mika Kuoppala
> >> Cc: Tvrtko Ursulin
> >> Signed-off-by: Yunwei Zhang
> >> ---
> >> drivers/gpu/drm/i915/intel_engine_cs.c | 39
> >> --
> >> 1 file changed, 37 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> >> b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> index de09fa4..4c78d1e 100644
> >> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> >> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> @@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct
> >> drm_i915_private *i915, int type)
> >> }
> >> }
> >>
> >> +static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
> >> +{
> >> + const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
> >> + u32 slice = fls(sseu->slice_mask);
> >> + u32 subslice = fls(sseu->subslice_mask[slice]);
> >> +
> >> + mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> >> + mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> >> +
> >> + return mcr;
> >> +}
> >> +
> >> +static void wa_init_mcr(struct drm_i915_private *dev_priv)
> >> +{
> >> + u32 mcr;
> >> +
> >> + mcr = I915_READ(GEN8_MCR_SELECTOR);
> >> + mcr = calculate_mcr(dev_priv, mcr);
> >> + I915_WRITE(GEN8_MCR_SELECTOR, mcr);
> >> +}
> >> +
> >> static inline uint32_t
> >> read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> >>int subslice, i915_reg_t reg)
> >> @@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv,
> >> int slice,
> >> intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
> >>
> >> mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> >> +
> >> /*
> >> * The HW expects the slice and sublice selectors to be reset to 0
> >> * after reading out the registers.
> >> */
> >> - WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> >> + WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
> >> +(mcr & mcr_slice_subslice_mask));
> >> mcr &= ~mcr_slice_subslice_mask;
> >> mcr |= mcr_slice_subslice_select;
> >> I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
> >>
> >> ret = I915_READ_FW(reg);
> >>
> >> - mcr &= ~mcr_slice_subslice_mask;
> >> + /*
> >> +* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
> >> +* expects mcr to be programed to a enabled slice/subslice pair
> >> +* before any MMIO read into slice/subslice register
> >> +*/
> > So the read was above, where we did set the subslice_select
> > appropriately. Here we are resetting back to 0 *after* the read, as the
> > comment before indicates.
> >
> > So what are you trying to accomplish with this patch? Other than leaving
> > the code in conflict with itself.
> > -Chris
> Hi Chris,
>
> The comment mentioned 0xFDC needs to be reset to 0 was before this WA
> was introduced, in later HW, this WA requires 0xFDC to be programmed to
> a enabled slice/subslice.
>
> What this patch does it to initialize 0xFDC once at the initialization
> (also it will be called after engine reset/TDR/coming out of c6) and
> make sure every time it is changed, it will be reprogrammed to a enabled
> slice/subslice so that a MMIO
> read will get the correct value. read_subslice_reg changes the 0xFDC
> value and if it is set to 0, it will cause MMIO read to return invalid
> value for s/ss specific registers.
What mmio read? The only accessor should b
[Intel-gfx] [PATCH v2] drm/i915/execlists: Delay updating ring register state after resume
Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.
v2: Handle the perma-pinned contexts.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 654634254b64..2bf5128efb26 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2536,13 +2536,14 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
return ret;
}
-void intel_lr_context_resume(struct drm_i915_private *dev_priv)
+void intel_lr_context_resume(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
enum intel_engine_id id;
- /* Because we emit WA_TAIL_DWORDS there may be a disparity
+ /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
* between our bookkeeping in ce->ring->head and ce->ring->tail and
* that stored in context. As we only write new commands from
* ce->ring->tail onwards, everything before that is junk. If the GPU
@@ -2552,27 +2553,19 @@ void intel_lr_context_resume(struct drm_i915_private
*dev_priv)
* So to avoid that we reset the context images upon resume. For
* simplicity, we just zero everything out.
*/
- list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
- for_each_engine(engine, dev_priv, id) {
- struct intel_context *ce = &ctx->engine[engine->id];
- u32 *reg;
-
- if (!ce->state)
- continue;
+ list_for_each_entry(ctx, &i915->contexts.list, link) {
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce = &ctx->engine[id];
- reg = i915_gem_object_pin_map(ce->state->obj,
- I915_MAP_WB);
- if (WARN_ON(IS_ERR(reg)))
+ if (!ce->ring)
continue;
- reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
- reg[CTX_RING_HEAD+1] = 0;
- reg[CTX_RING_TAIL+1] = 0;
-
- ce->state->obj->mm.dirty = true;
- i915_gem_object_unpin_map(ce->state->obj);
-
intel_ring_reset(ce->ring, 0);
+
+ if (ce->pin_count) { /* otherwise done in context_pin */
+ ce->lrc_reg_state[CTX_RING_HEAD+1] = 0;
+ ce->lrc_reg_state[CTX_RING_TAIL+1] = 0;
+ }
}
}
}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/execlists: Delay updating ring register state after resume
Quoting Chris Wilson (2018-03-27 22:01:56) > Now that we reload both RING_HEAD and RING_TAIL when rebinding the > context, we do not need to scrub those registers immediately on resume. So CI reports that contrary to my belief, we didn't do a i915_gem_contexts_lost() across suspend. Hmm, nope that's definitely there in i915_gem_suspend, so all contexts should have been unpinned. Oh, silly me, that doesn't account for the extra perma-pin we keep on the kernel contexts to avoid them being evicted. Ok, that's annoying and has some ramifications for the first patch if we can contrive a wedging to be injected into the kernel context. Hmm, an outside possibility to be sure as it would need a full device reset at precisely the same time as a i915_gem_switch_to_kernel_context, exceedingly rare. Not so rare as having the kernel context be an innocent victim (the last context on an idle engine) - that's not impacted by this, as there we know the breadcrumb has already been emitted so RING_HEAD will not roll back and reemit on recovery. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Support for Guc responses and requests (rev5)
== Series Details == Series: drm/i915/guc: Support for Guc responses and requests (rev5) URL : https://patchwork.freedesktop.org/series/28393/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/guc: Add documentation for MMIO based communication Okay! Commit: drm/i915/guc: Add support for data reporting in GuC responses Okay! Commit: drm/i915/guc: Prepare send() function to accept bigger response Okay! Commit: drm/i915/guc: Implement response handling in send_mmio() Okay! Commit: drm/i915/guc: Make event handler a virtual function Okay! Commit: drm/i915/guc: Prepare to handle messages from CT RECV buffer Okay! Commit: drm/i915/guc: Use better name for helper wait function Okay! Commit: drm/i915/guc: Implement response handling in send_ct() Okay! Commit: drm/i915/guc: Prepare to process incoming requests from CT Okay! Commit: drm/i915/guc: Handle default action received over CT Okay! Commit: drm/i915/guc: Trace messages from CT while in debug +Error in reading or end of file. Commit: HAX: Enable GuC for CI Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40764/ State : failure == Summary == Series 40764v1 series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts https://patchwork.freedesktop.org/api/1.0/series/40764/revisions/1/mbox/ Possible new issues: Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-bdw-gvtdvm) pass -> INCOMPLETE (fi-bsw-n3050) pass -> INCOMPLETE (fi-bxt-j4205) pass -> INCOMPLETE (fi-cfl-8700k) pass -> INCOMPLETE (fi-cfl-s3) pass -> INCOMPLETE (fi-cfl-u) pass -> INCOMPLETE (fi-glk-1) pass -> INCOMPLETE (fi-kbl-7500u) pass -> INCOMPLETE (fi-kbl-r) Known issues: Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-bdw-5557u) fdo#104311 pass -> INCOMPLETE (fi-cnl-y3) fdo#105086 pass -> INCOMPLETE (fi-kbl-7567u) fdo#103665 pass -> INCOMPLETE (fi-skl-6260u) fdo#104108 +5 fdo#104311 https://bugs.freedesktop.org/show_bug.cgi?id=104311 fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fi-bdw-5557u total:108 pass:104 dwarn:0 dfail:0 fail:0 skip:3 fi-bdw-gvtdvmtotal:108 pass:103 dwarn:0 dfail:0 fail:0 skip:4 fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:299s fi-bxt-j4205 total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:529s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:514s fi-cfl-8700k total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-cfl-s3total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-cfl-u total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-cnl-y3total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:429s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:321s fi-glk-1 total:108 pass:95 dwarn:0 dfail:0 fail:0 skip:12 fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:422s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:469s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:430s fi-kbl-7500u total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-kbl-7567u total:108 pass:104 dwarn:0 dfail:0 fail:0 skip:3 fi-kbl-r total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:658s fi-skl-6260u total:108 pass:104 dwarn:0 dfail:0 fail:0 skip:3 fi-skl-6600u total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-6700k2total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-6770hqtotal:108 pass:104 dwarn:0 dfail:0 fail:0 skip:3 fi-skl-guc total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-gvtdvmtotal:108 pass:103 dwarn:0 dfail:0 fail:0 skip:4 fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:561s Blacklisted hosts: fi-cnl-psr total:108 pass:96 dwarn:0 dfail:0 fail:0 skip:11 fi-glk-j4005 failed to collect. IGT log at Patchwork_8509/fi-glk-j4005/run0.log 0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC integration manifest 515b83d66afc drm/i915: Include the HW breadcrumb whenever we trace the global_seqno a9473b05fca4 drm/i915/execlists: Delay updating ring register state after resume f73f2b30c417 drm/i915/execlists: Reset ring registers on rebinding contexts == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8509/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 10/12] drm/i915/guc: Handle default action received over CT
On 3/27/2018 2:41 PM, Michal Wajdeczko wrote:
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
v2: filter disabled messages (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Reviewed-by: Michel Thierry #1
^ still applies for v2, but I would wait for Daniele's blessing
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc.c| 8
drivers/gpu/drm/i915/intel_guc.h| 1 +
drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..d77dde7 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,14 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc
*guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(&guc->irq_lock);
+ intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
(as I said before, this will need to change later on to receive more
than jut data[1]/payload anyway)
+ /* Make sure to handle only enabled messages */
+ msg &= guc->msg_enabled_mask;
+
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(&guc->log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len,
void intel_guc_to_host_event_handler(struct intel_guc *guc);
void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
static void ct_process_request(struct intel_guc_ct *ct,
u32 action, u32 len, const u32 *payload)
{
+ struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+ case INTEL_GUC_ACTION_DEFAULT:
+ if (unlikely(len < 1))
+ goto fail_unexpected;
+ intel_guc_to_host_process_recv_msg(guc, *payload);
+ break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4 * len, payload);
break;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 3/27/2018 3:27 PM, Chris Wilson wrote:
Quoting Yunwei Zhang (2018-03-27 23:14:16)
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
References: HSD#1405586840, BSID#0575
v2:
- use fls() instead of find_last_bit() (Chris)
- added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Change the ordered of passing arguments and etc. (Ursulin)
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/intel_engine_cs.c | 39 --
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index de09fa4..4c78d1e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type)
}
}
+static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
+{
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+ u32 slice = fls(sseu->slice_mask);
+ u32 subslice = fls(sseu->subslice_mask[slice]);
+
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+ return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+ u32 mcr;
+
+ mcr = I915_READ(GEN8_MCR_SELECTOR);
+ mcr = calculate_mcr(dev_priv, mcr);
+ I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
static inline uint32_t
read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
int subslice, i915_reg_t reg)
@@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int
slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
* The HW expects the slice and sublice selectors to be reset to 0
* after reading out the registers.
*/
- WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+ WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
+(mcr & mcr_slice_subslice_mask));
mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
ret = I915_READ_FW(reg);
- mcr &= ~mcr_slice_subslice_mask;
+ /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+* expects mcr to be programed to a enabled slice/subslice pair
+* before any MMIO read into slice/subslice register
+*/
So the read was above, where we did set the subslice_select
appropriately. Here we are resetting back to 0 *after* the read, as the
comment before indicates.
So what are you trying to accomplish with this patch? Other than leaving
the code in conflict with itself.
-Chris
Hi Chris,
The comment mentioned 0xFDC needs to be reset to 0 was before this WA
was introduced, in later HW, this WA requires 0xFDC to be programmed to
a enabled slice/subslice.
What this patch does it to initialize 0xFDC once at the initialization
(also it will be called after engine reset/TDR/coming out of c6) and
make sure every time it is changed, it will be reprogrammed to a enabled
slice/subslice so that a MMIO
read will get the correct value. read_subslice_reg changes the 0xFDC
value and if it is set to 0, it will cause MMIO read to return invalid
value for s/ss specific registers.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances
Em Sex, 2018-03-23 às 16:28 +, Lionel Landwerlin escreveu:
> Hi Mika,
>
> Even after this series, we're still missing support for reading the
> timestamp frequency (read_timestamp_frequency in
> intel_device_info.c).
> I'm pretty sure someone wrote a patch for it. Do you any idea?
>
> If not, I can send something.
Yes, we have them. I'll see if I missed them while upstreaming and
resend in that case.
>
> Thanks,
>
> -
> Lionel
>
> On 16/03/18 12:14, Mika Kuoppala wrote:
> > From: Oscar Mateo
> >
> > In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD)
> > and the
> > Video Enhancement engines (aka VEBOX, aka VECS) could be fused off.
> > Also,
> > each VDBOX and VEBOX has its own power well, which only exist if
> > the related
> > engine exists in the HW.
> >
> > Unfortunately, we have a Catch-22 situation going on: we need the
> > blitter
> > forcewake to read the register with the fuse info, but we cannot
> > initialize
> > the forcewake domains without knowin about the engines present in
> > the HW.
> > We workaround this problem by allowing the initialization of all
> > forcewake
> > domains and then pruning the fused off ones, as per the fuse
> > information.
> >
> > Bspec: 20680
> >
> > v2: We were shifting incorrectly for vebox disable (Vinay)
> >
> > v3: Assert mmio is ready and warn if we have attempted to
> > initialize
> > forcewake for fused-off engines (Paulo)
> >
> > v4:
> >- Use INTEL_GEN in new code (Tvrtko)
> >- Shorter local variable (Tvrtko, Michal)
> >- Keep "if (!...) continue" style (Tvrtko)
> >- No unnecessary BUG_ON (Tvrtko)
> >- WARN_ON and cleanup if wrong mask (Tvrtko, Michal)
> >- Use I915_READ_FW (Michal)
> >- Use I915_MAX_VCS/VECS macros (Michal)
> >
> > v5: Rebased by Rodrigo fixing conflicts on top of:
> > commit 33def1ff7b0 ("drm/i915: Simplify intel_engines_init")
> >
> > v6: Fix v5. Remove info->num_rings. (by Oscar)
> >
> > v7: Rebase (Rodrigo).
> >
> > v8:
> >-
> > s/intel_device_info_fused_off_engines/intel_device_info_init_mmio
> > (Chris)
> >- Make vdbox_disable & vebox_disable local variables (Chris)
> >
> > v9:
> >- Move function declaration to intel_device_info.h (Michal)
> >- Missing indent in bit fields definitions (Michal)
> >- When RC6 is enabled by BIOS, the fuse register cannot be read
> > until
> > the blitter powerwell is awake. Shuffle where the fuse is
> > read, prune
> > the forcewake domains after the fact and change the commit
> > message
> > accordingly (Vinay, Sagar, Chris).
> >
> > v10:
> >- Improved commit message (Sagar)
> >- New line in header file (Sagar)
> >- Specify the message in fw_domain_reset applies to ICL+ (Sagar)
> >
> > Cc: Paulo Zanoni
> > Cc: Vinay Belgaumkar
> > Cc: Tvrtko Ursulin
> > Cc: Michal Wajdeczko
> > Cc: Chris Wilson
> > Cc: Daniele Ceraolo Spurio
> > Cc: Sagar Arun Kamble
> > Signed-off-by: Rodrigo Vivi
> > Signed-off-by: Oscar Mateo
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 4 +++
> > drivers/gpu/drm/i915/i915_reg.h | 5 +++
> > drivers/gpu/drm/i915/intel_device_info.c | 47
> > +++
> > drivers/gpu/drm/i915/intel_device_info.h | 2 ++
> > drivers/gpu/drm/i915/intel_uncore.c | 56
> >
> > drivers/gpu/drm/i915/intel_uncore.h | 1 +
> > 6 files changed, 115 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 3df5193487f3..83df8e21cec0 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1033,6 +1033,10 @@ static int i915_driver_init_mmio(struct
> > drm_i915_private *dev_priv)
> >
> > intel_uncore_init(dev_priv);
> >
> > + intel_device_info_init_mmio(dev_priv);
> > +
> > + intel_uncore_prune(dev_priv);
> > +
> > intel_uc_init_mmio(dev_priv);
> >
> > ret = intel_engines_init_mmio(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index cf7c837d6a09..982e72e73e99 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2545,6 +2545,11 @@ enum i915_power_well_id {
> > #define GEN10_EU_DISABLE3 _MMIO(0x9140)
> > #define GEN10_EU_DIS_SS_MASK0xff
> >
> > +#define GEN11_GT_VEBOX_VDBOX_DISABLE _MMIO(0x9140)
> > +#define GEN11_GT_VDBOX_DISABLE_MASK 0xff
> > +#define GEN11_GT_VEBOX_DISABLE_SHIFT 16
> > +#define GEN11_GT_VEBOX_DISABLE_MASK (0xff <<
> > GEN11_GT_VEBOX_DISABLE_SHIFT)
> > +
> > #define GEN6_BSD_SLEEP_PSMI_CONTROL _MMIO(0x12050)
> > #define GEN6_BSD_SLEEP_MSG_DISABLE (1 << 0)
> > #define GEN6_BSD_SLEEP_FLUSH_DISABLE(1 << 2)
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index 3dd350f7b8e6..4babfc6ee45b 100644
> > --- a/drivers/gpu/
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40764/ State : warning == Summary == $ dim checkpatch origin/drm-tip f73f2b30c417 drm/i915/execlists: Reset ring registers on rebinding contexts -:36: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #36: FILE: drivers/gpu/drm/i915/intel_lrc.c:1275: + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; ^ total: 0 errors, 0 warnings, 1 checks, 7 lines checked a9473b05fca4 drm/i915/execlists: Delay updating ring register state after resume 515b83d66afc drm/i915: Include the HW breadcrumb whenever we trace the global_seqno ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
Quoting Yunwei Zhang (2018-03-27 23:14:16)
> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> read into Slice/Subslice specific registers, MCR packet control
> register(0xFDC) needs to be programmed to point to any enabled
> slice/subslice pair. Otherwise, incorrect value will be returned.
>
> However, that means each subsequent MMIO read will be forwarded to a
> specific slice/subslice combination as read is unicast. This is OK since
> slice/subslice specific register values are consistent in almost all cases
> across slice/subslice. There are rare occasions such as INSTDONE that this
> value will be dependent on slice/subslice combo, in such cases, we need to
> program 0xFDC and recover this after. This is already covered by
> read_subslice_reg.
>
> Also, 0xFDC will lose its information after TDR/engine reset/power state
> change.
>
> References: HSD#1405586840, BSID#0575
>
> v2:
> - use fls() instead of find_last_bit() (Chris)
> - added INTEL_SSEU to extract sseu from device info. (Chris)
> v3:
> - rebase on latest tip
> v5:
> - Added references (Mika)
> - Change the ordered of passing arguments and etc. (Ursulin)
>
> Cc: Oscar Mateo
> Cc: Michel Thierry
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> Signed-off-by: Yunwei Zhang
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 39
> --
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index de09fa4..4c78d1e 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private
> *i915, int type)
> }
> }
>
> +static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
> +{
> + const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
> + u32 slice = fls(sseu->slice_mask);
> + u32 subslice = fls(sseu->subslice_mask[slice]);
> +
> + mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> + mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> +
> + return mcr;
> +}
> +
> +static void wa_init_mcr(struct drm_i915_private *dev_priv)
> +{
> + u32 mcr;
> +
> + mcr = I915_READ(GEN8_MCR_SELECTOR);
> + mcr = calculate_mcr(dev_priv, mcr);
> + I915_WRITE(GEN8_MCR_SELECTOR, mcr);
> +}
> +
> static inline uint32_t
> read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> int subslice, i915_reg_t reg)
> @@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv,
> int slice,
> intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
>
> mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> +
> /*
> * The HW expects the slice and sublice selectors to be reset to 0
> * after reading out the registers.
> */
> - WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> + WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
> +(mcr & mcr_slice_subslice_mask));
> mcr &= ~mcr_slice_subslice_mask;
> mcr |= mcr_slice_subslice_select;
> I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>
> ret = I915_READ_FW(reg);
>
> - mcr &= ~mcr_slice_subslice_mask;
> + /*
> +* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
> +* expects mcr to be programed to a enabled slice/subslice pair
> +* before any MMIO read into slice/subslice register
> +*/
So the read was above, where we did set the subslice_select
appropriately. Here we are resetting back to 0 *after* the read, as the
comment before indicates.
So what are you trying to accomplish with this patch? Other than leaving
the code in conflict with itself.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
References: HSD#1405586840, BSID#0575
v2:
- use fls() instead of find_last_bit() (Chris)
- added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Change the ordered of passing arguments and etc. (Ursulin)
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/intel_engine_cs.c | 39 --
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index de09fa4..4c78d1e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type)
}
}
+static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
+{
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+ u32 slice = fls(sseu->slice_mask);
+ u32 subslice = fls(sseu->subslice_mask[slice]);
+
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+ return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+ u32 mcr;
+
+ mcr = I915_READ(GEN8_MCR_SELECTOR);
+ mcr = calculate_mcr(dev_priv, mcr);
+ I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
static inline uint32_t
read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
int subslice, i915_reg_t reg)
@@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int
slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
* The HW expects the slice and sublice selectors to be reset to 0
* after reading out the registers.
*/
- WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+ WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
+(mcr & mcr_slice_subslice_mask));
mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
ret = I915_READ_FW(reg);
- mcr &= ~mcr_slice_subslice_mask;
+ /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+* expects mcr to be programed to a enabled slice/subslice pair
+* before any MMIO read into slice/subslice register
+*/
+ if (INTEL_GEN(dev_priv) < 10)
+ mcr &= ~mcr_slice_subslice_mask;
+ else
+ mcr = calculate_mcr(dev_priv, mcr);
+
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
@@ -1307,6 +1339,9 @@ static int cnl_init_workarounds(struct intel_engine_cs
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
+ /* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */
+ wa_init_mcr(dev_priv);
+
/* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
I915_WRITE(GAMT_CHKN_BIT_REG,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.
However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.
References: HSDES#1405586840
v2:
- use fls instead of find_last_bit (Chris)
- use is_power_of_2() instead of counting bit set (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Move local variable into scope where they are used (Ursulin)
- use a new local variable to reduce long line of code (Ursulin)
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/i915_reg.h| 4
drivers/gpu/drm/i915/intel_engine_cs.c | 20
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1bca695f..4f2f5e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2691,6 +2691,10 @@ enum i915_power_well_id {
#define GEN10_F2_SS_DIS_SHIFT18
#define GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT)
+#defineGEN10_MIRROR_FUSE3 _MMIO(0x9118)
+#define GEN10_L3BANK_PAIR_COUNT 4
+#define GEN10_L3BANK_MASK 0x0F
+
#define GEN8_EU_DISABLE0 _MMIO(0x9134)
#define GEN8_EU_DIS0_S0_MASK 0xff
#define GEN8_EU_DIS0_S1_SHIFT24
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4c78d1e..7be7a75 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -811,6 +811,26 @@ static u32 calculate_mcr(struct drm_i915_private
*dev_priv, u32 mcr)
static void wa_init_mcr(struct drm_i915_private *dev_priv)
{
u32 mcr;
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+
+ /* If more than one slice are enabled, L3Banks should be all enabled */
+ if (is_power_of_2(sseu->slice_mask)) {
+ /*
+* WaProgramMgsrForL3BankSpecificMmioReads:
+* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
+* enabled subslice, no need to redirect MCR packet
+*/
+ u32 slice = fls(sseu->slice_mask);
+ u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3);
+ u8 ss_mask = sseu->subslice_mask[slice];
+ /*
+* Production silicon should have matched L3Bank and
+* subslice enabled
+*/
+ WARN_ON(!((fuse3 & GEN10_L3BANK_MASK) &
+ ((ss_mask | ss_mask >> GEN10_L3BANK_PAIR_COUNT) &
+ GEN10_L3BANK_MASK)));
+ }
mcr = I915_READ(GEN8_MCR_SELECTOR);
mcr = calculate_mcr(dev_priv, mcr);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Reset ring registers on rebinding contexts
== Series Details == Series: drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40763/ State : success == Summary == Series 40763v1 drm/i915/execlists: Reset ring registers on rebinding contexts https://patchwork.freedesktop.org/api/1.0/series/40763/revisions/1/mbox/ Known issues: Test kms_chamelium: Subgroup dp-edid-read: pass -> FAIL (fi-kbl-7500u) fdo#102505 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (fi-skl-6770hq) fdo#100368 Test kms_pipe_crc_basic: Subgroup read-crc-pipe-c-frame-sequence: pass -> FAIL (fi-skl-6770hq) fdo#103481 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:432s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:447s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:540s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:522s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:512s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:570s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:590s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:428s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:326s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:425s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:470s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:433s fi-kbl-7500u total:285 pass:259 dwarn:1 dfail:0 fail:1 skip:24 time:472s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:515s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:662s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:534s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:285 pass:263 dwarn:0 dfail:0 fail:2 skip:20 time:492s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:432s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:594s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:544s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:486s 0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC integration manifest ad09e66d7bde drm/i915/execlists: Reset ring registers on rebinding contexts == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8508/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
V8: Style
V9: Strip out DPCD_REV_XX into seperate patch
Signed-off-by: Matt Atwood
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/drm_dp_helper.c | 22 ++
include/drm/drm_dp_helper.h | 1 +
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ffe14ec..f9a8bf9 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,32 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
+ rd_interval);
+
+ if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DPCD_REV_14)
udelay(100);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
- if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+ int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
+ rd_interval);
+
+ if (rd_interval == 0)
udelay(400);
else
- mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+ mdelay(rd_interval * 4);
}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f77746e..c1ba415 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -124,6 +124,7 @@
# define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
#define DP_ADAPTER_CAP 0x00f /* 1.2 */
# define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/dp: Move DPCD_REV_XX to drm_dp_helper
From: Matt Atwood
As more differentation occurs between DP spec. Its useful to have these
as macros in a drm_dp_helper.
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/amd/display/include/dpcd_defs.h | 8
include/drm/drm_dp_helper.h | 5 +
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/include/dpcd_defs.h
b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
index d8e52e3..d13e0f4 100644
--- a/drivers/gpu/drm/amd/display/include/dpcd_defs.h
+++ b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
@@ -28,14 +28,6 @@
#include
-enum dpcd_revision {
- DPCD_REV_10 = 0x10,
- DPCD_REV_11 = 0x11,
- DPCD_REV_12 = 0x12,
- DPCD_REV_13 = 0x13,
- DPCD_REV_14 = 0x14
-};
-
/* these are the types stored at DOWNSTREAMPORT_PRESENT */
enum dpcd_downstream_port_type {
DOWNSTREAM_DP = 0,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4de97e9..f77746e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
/* AUX CH addresses */
/* DPCD */
#define DP_DPCD_REV 0x000
+# define DPCD_REV_100x10
+# define DPCD_REV_110x11
+# define DPCD_REV_120x12
+# define DPCD_REV_130x13
+# define DPCD_REV_140x14
#define DP_MAX_LINK_RATE0x001
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/execlists: Reset ring registers on rebinding contexts
== Series Details == Series: drm/i915/execlists: Reset ring registers on rebinding contexts URL : https://patchwork.freedesktop.org/series/40763/ State : warning == Summary == $ dim checkpatch origin/drm-tip ad09e66d7bde drm/i915/execlists: Reset ring registers on rebinding contexts -:36: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #36: FILE: drivers/gpu/drm/i915/intel_lrc.c:1275: + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; ^ total: 0 errors, 0 warnings, 1 checks, 7 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: prefer inline over __inline__
== Series Details == Series: series starting with [1/3] drm: prefer inline over __inline__ URL : https://patchwork.freedesktop.org/series/40760/ State : success == Summary == Series 40760v1 series starting with [1/3] drm: prefer inline over __inline__ https://patchwork.freedesktop.org/api/1.0/series/40760/revisions/1/mbox/ Known issues: Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-byt-n2820) fdo#104008 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:435s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:545s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:300s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:513s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:529s fi-byt-n2820 total:285 pass:245 dwarn:0 dfail:0 fail:1 skip:39 time:511s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:411s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:569s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:518s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:591s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:322s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:423s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:475s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:430s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:476s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:470s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:517s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:669s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:535s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:501s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:508s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:586s Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:528s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:485s 0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC integration manifest 7c6c58e66770 drm: make drm_core_check_feature() bool that it is 2fd0c80d2347 drm: remove old documentation comment cruft from drmP.h a139c1128af7 drm: prefer inline over __inline__ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8507/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 10/12] drm/i915/guc: Handle default action received over CT
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
v2: filter disabled messages (Daniele)
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Reviewed-by: Michel Thierry #1
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc.c| 8
drivers/gpu/drm/i915/intel_guc.h| 1 +
drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..d77dde7 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,14 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc
*guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(&guc->irq_lock);
+ intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
+ /* Make sure to handle only enabled messages */
+ msg &= guc->msg_enabled_mask;
+
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(&guc->log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len,
void intel_guc_to_host_event_handler(struct intel_guc *guc);
void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
static void ct_process_request(struct intel_guc_ct *ct,
u32 action, u32 len, const u32 *payload)
{
+ struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+ case INTEL_GUC_ACTION_DEFAULT:
+ if (unlikely(len < 1))
+ goto fail_unexpected;
+ intel_guc_to_host_process_recv_msg(guc, *payload);
+ break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4 * len, payload);
break;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y coordinate requirement
On Fri, Mar 23, 2018 at 07:34:34PM -0700, Pandiyan, Dhinakaran wrote:
>
> On Fri, 2018-03-23 at 23:51 +, Souza, Jose wrote:
> > On Fri, 2018-03-23 at 15:59 -0700, Pandiyan, Dhinakaran wrote:
> > >
> > >
> > > On Thu, 2018-03-22 at 14:48 -0700, José Roberto de Souza wrote:
> > > > Move to only one place the sink requirements that the actual driver
> > > > needs to enable PSR2.
> > > >
> > > > Also intel_psr2_config_valid() is called every time the crtc config
> > > > is computed, wasting some time every time it was checking for
> > > > Y coordinate requirement.
> > > >
> > > > This allow us to nuke y_cord_support and some of VSC setup code
> > > > that
> > > > was handling a scenario that would never happen(PSR2 without Y
> > > > coordinate).
> > > >
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Rodrigo Vivi
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 -
> > > > drivers/gpu/drm/i915/intel_psr.c | 46 +---
> > > >
> > > > 2 files changed, 19 insertions(+), 28 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 7fe00509e51a..cce32686fd75 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -603,7 +603,6 @@ struct i915_psr {
> > > > unsigned busy_frontbuffer_bits;
> > > > bool psr2_support;
> > > > bool link_standby;
> > > > - bool y_cord_support;
> > > > bool colorimetry_support;
> > > > bool alpm;
> > > > bool has_hw_tracking;
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index d46320a451d9..23f38ab10636 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp
> > > > *intel_dp)
> > > > intel_display_power_put(dev_priv,
> > > > psr_aux_domain(intel_dp));
> > > > }
> > > >
> > > > -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> > > > +static bool intel_dp_get_y_coord_required(struct intel_dp
> > > > *intel_dp)
> > > > {
> > > > uint8_t psr_caps = 0;
> > > >
> > > > @@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp
> > > > *intel_dp)
> > > > drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp-
> > > > >psr_dpcd,
> > > > sizeof(intel_dp->psr_dpcd));
> > > >
> > > > - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > > > + if (intel_dp->psr_dpcd[0]) {
> > > > dev_priv->psr.sink_support = true;
> > > > DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > > > }
> > > >
> > > > if (INTEL_GEN(dev_priv) >= 9 &&
> > > > - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > > > -
> > > > - dev_priv->psr.sink_support = true;
> > > > - dev_priv->psr.psr2_support = true;
> > > > + (intel_dp->psr_dpcd[0] ==
> > > > DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> > > > + /*
> > > > +* All panels that supports PSR version 03h (PSR2
> > > > +
> > > > +* Y-coordinate) can handle Y-coordinates in VSC
> > > > but we are
> > > > +* only sure that it is going to be used when
> > > > required by the
> > > > +* panel. This way panel is capable to do
> > > > selective update
> > > > +* without a aux frame sync.
> > >
> > > Can you cite this from the spec please? just the "panel is capable to
> > > do
> > > selective update without a aux frame sync" part. Or you could just
> > > remove that line so that we can get this patch reviewed and merged.
> >
> > There is no such statement in spec like this, the closest that it have
> > is:
> > "When the Source device includes the optional Y-coordinate in the SDP
> > for PSR2 Operation, as described in Table 6-12, the Sink device can
> > implement a lower-precision GTC Slave function, as described in Table
> > 7-1."
> >
> > But we know that this works by all the previous tests when enabling
> > PSR2 and I also tested it.
>
> Please do update the comment to say so. Do you know if these tests for
> PSR2 selective update are in IGT? Or were these manual tests?
>
> Rodrigo/Vathsala, any idea how selective update was and can be tested?
nope :(
>
> The patch as such makes sense to me
> Reviewed-by: Dhinakaran Pandiyan if you
> update the comment.
>
>
> >
> > >
> > >
> > > > +*
> > > > +* To support PSR version 02h and PSR version 03h
> > > > without
> > > > +* Y-coordinate requirement panels we would need
> > > > to enable
> > > > +* GTC first.
> > > > +*/
> > > > + dev_priv->psr.psr2_support =
> > > > intel_dp_get_y_coord_required(intel
Re: [Intel-gfx] [PATCH v5 10/12] drm/i915/guc: Handle default action received over CT
On 27/03/18 14:05, Michal Wajdeczko wrote:
On Tue, 27 Mar 2018 22:03:23 +0200, Michel Thierry
wrote:
On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote:
On 26/03/18 12:48, Michal Wajdeczko wrote:
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_guc.c | 5 +
drivers/gpu/drm/i915/intel_guc.h | 1 +
drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void
intel_guc_to_host_event_handler_mmio(struct intel_guc *guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(&guc->irq_lock);
+ intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32
msg)
+{
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(&guc->log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc,
const u32 *action, u32 len,
void intel_guc_to_host_event_handler(struct intel_guc *guc);
void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32
msg);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct
intel_guc_ct *ct, const u32 *msg)
static void ct_process_request(struct intel_guc_ct *ct,
u32 action, u32 len, const u32 *payload)
{
+ struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+ case INTEL_GUC_ACTION_DEFAULT:
+ if (unlikely(len < 1))
+ goto fail_unexpected;
Don't we need to remove the non-enabled messages here? i.e. like we
do for the mmio receive:
msg = *payload & guc->msg_enabled_mask;
otherwise I think we'll try to process log interrupts even if the
relay is not enabled.
In Daniele's specific example, I still think
guc_log_enable_flush_events should have been called (and don't do
anything inside handle_flush_event, the goal was to not serve it).
But it's true that we should filter any unexpected incoming request (&
guc->msg_enabled_mask), and any new user should be calling
intel_guc_enable_msg during its setup.
hmm, my understanding was that purpose of msg_enabled_mask was to:
* Sample the log buffer flush related bits & clear them out now
* itself from the message identity register to minimize the
* probability of losing a flush interrupt, when there are back
* to back flush interrupts.
and is not applicable to messages sent over CTB, as we can't miss msg.
if you still believe that filtering is required, it should not be done
here, as purpose of this function is to verify message completeness and
call actual handler, but in intel_guc_to_host_process_recv_msg(), where
format of received data is known.
/m
The problem is that now we keep the interrupts enabled even if the log
relay is not enabled. If we handle the interrupt anyway and queue the
flush_work (from intel_guc_log_handle_flush_event), we end up hitting:
if (WARN_ON(!intel_guc_log_relay_enabled(log)))
goto out_unlock;
inside guc_read_update_log_buffer.
I don't think that the comment you added above referred to the specific
usage of msg_enabled_mask but more to the fact that we clean the bits
related to the messages we're going to handle.
Daniele
Thanks,
Daniele
+ intel_guc_to_host_process_recv_msg(guc, *payload);
+ break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4 * len, payload);
break;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs
On Tue, 2018-03-27 at 11:26 +0100, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-03-27 02:16:22)
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> >
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> >
> > v2: Unroll loops (Ville)
> > Avoid resetting error mask bits.
> >
> > Cc: Rodrigo Vivi
> > Cc: Ville Syrjälä
> > Cc: Chris Wilson
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_irq.c | 55
> > +++--
> > drivers/gpu/drm/i915/intel_drv.h| 2 ++
> > drivers/gpu/drm/i915/intel_psr.c| 54
> >
> > 5 files changed, 108 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 7816cd53100a..6fd801ef7cbb 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m,
> > void *data)
> > return 0;
> > }
> >
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > + struct drm_i915_private *dev_priv = data;
> > +
> > + if (!CAN_PSR(dev_priv))
> > + return -ENODEV;
> > +
> > + if (val < 0 || val > 1)
> > + return -EINVAL;
> > +
> > + DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" :
> > "Disabling");
> > + intel_psr_debug_control(dev_priv, val);
> > +
> > + return 0;
> > +}
>
> A really useful trick for features like this (that we think should be
> used wherever it can) is just to enable debug while the debugfs file is
> open. igt need only do something like
> openat(debugfs_dir, "i915_edp_psr_debug", O_RDONLY);
That is neat.
We also want to support user enabling/disabling PSR debug via shell. The
semantics get slightly confusing taking that into consideration.
For example,
1) should cat $debugfs/i915_edp_psr_debug
also enable debug or just print the current status of debug
2) if the file is already open (debug enabled), should
echo 0 > $debugfs/i915_edp_psr_debug disable debug or check for the
refcount to drop to zero.
Choosing the correct solution and implementing it correctly feels like
we'd be over-engineering.
> and then it will be automatically released and the system returned to
> default when terminated. You can then enforce exclusive access or keep an
> open count.
> -Chris
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw
== Series Details == Series: series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw URL : https://patchwork.freedesktop.org/series/40759/ State : success == Summary == Series 40759v1 series starting with [v5,1/8] drm/i915: Correctly handle error path in i915_gem_init_hw https://patchwork.freedesktop.org/api/1.0/series/40759/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:446s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:538s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:517s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:523s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:512s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:415s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:568s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:517s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:578s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:430s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:325s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:408s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:420s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:476s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:432s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:477s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:468s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:666s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:444s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:544s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:504s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:498s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:432s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:447s fi-snb-2520m total:242 pass:208 dwarn:0 dfail:0 fail:0 skip:33 Blacklisted hosts: fi-cnl-psr total:285 pass:256 dwarn:3 dfail:0 fail:0 skip:26 time:531s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:489s 0539b52e05cd0abe697d45f2a2373ec42af7ebcb drm-tip: 2018y-03m-27d-18h-45m-40s UTC integration manifest 144a5f9809e1 HAX: Enable GuC for CI d5e88b21ece7 drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c a8b655ca5aa7 drm/i915/uc: Use helper functions to detect fw load status 3217ab178f2a drm/i915/uc: Use correct error code for GuC initialization failure 6eb5c9f7705a drm/i915/uc: Fully sanitize uC in uc_fini_hw 24f107d1ea1f drm/i915/guc: Restore symmetric doorbell cleanup 25a5033a07f3 drm/i915/uc: Disable GuC submission during sanitize 1dd9d26952a0 drm/i915: Correctly handle error path in i915_gem_init_hw == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8506/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 10/12] drm/i915/guc: Handle default action received over CT
On Tue, 27 Mar 2018 22:03:23 +0200, Michel Thierry
wrote:
On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote:
On 26/03/18 12:48, Michal Wajdeczko wrote:
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_guc.c| 5 +
drivers/gpu/drm/i915/intel_guc.h| 1 +
drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct
intel_guc *guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(&guc->irq_lock);
+intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32
msg)
+{
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(&guc->log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc,
const u32 *action, u32 len,
void intel_guc_to_host_event_handler(struct intel_guc *guc);
void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32
msg);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct
*ct, const u32 *msg)
static void ct_process_request(struct intel_guc_ct *ct,
u32 action, u32 len, const u32 *payload)
{
+struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+case INTEL_GUC_ACTION_DEFAULT:
+if (unlikely(len < 1))
+goto fail_unexpected;
Don't we need to remove the non-enabled messages here? i.e. like we do
for the mmio receive:
msg = *payload & guc->msg_enabled_mask;
otherwise I think we'll try to process log interrupts even if the
relay is not enabled.
In Daniele's specific example, I still think guc_log_enable_flush_events
should have been called (and don't do anything inside
handle_flush_event, the goal was to not serve it).
But it's true that we should filter any unexpected incoming request (&
guc->msg_enabled_mask), and any new user should be calling
intel_guc_enable_msg during its setup.
hmm, my understanding was that purpose of msg_enabled_mask was to:
* Sample the log buffer flush related bits & clear them out now
* itself from the message identity register to minimize the
* probability of losing a flush interrupt, when there are back
* to back flush interrupts.
and is not applicable to messages sent over CTB, as we can't miss msg.
if you still believe that filtering is required, it should not be done
here, as purpose of this function is to verify message completeness and
call actual handler, but in intel_guc_to_host_process_recv_msg(), where
format of received data is known.
/m
Thanks,
Daniele
+intel_guc_to_host_process_recv_msg(guc, *payload);
+break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4 * len, payload);
break;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Include the HW breadcrumb whenever we trace the global_seqno
When we include a request's global_seqno in a GEM_TRACE it often helps
to know how that relates to the current breadcrumb as seen by the
hardware.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 28 +---
drivers/gpu/drm/i915/intel_lrc.c| 6 --
2 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 2314a26cd7f8..585242831974 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -214,8 +214,11 @@ static int reset_all_global_seqno(struct drm_i915_private
*i915, u32 seqno)
struct i915_gem_timeline *timeline;
struct intel_timeline *tl = engine->timeline;
- GEM_TRACE("%s seqno %d -> %d\n",
- engine->name, tl->seqno, seqno);
+ GEM_TRACE("%s seqno %d (current %d) -> %d\n",
+ engine->name,
+ tl->seqno,
+ intel_engine_get_seqno(engine),
+ seqno);
if (!i915_seqno_passed(seqno, tl->seqno)) {
/* Flush any waiters before we reuse the seqno */
@@ -386,10 +389,11 @@ static void i915_request_retire(struct i915_request
*request)
struct intel_engine_cs *engine = request->engine;
struct i915_gem_active *active, *next;
- GEM_TRACE("%s(%d) fence %llx:%d, global_seqno %d\n",
- engine->name, intel_engine_get_seqno(engine),
+ GEM_TRACE("%s fence %llx:%d, global_seqno %d, current %d\n",
+ engine->name,
request->fence.context, request->fence.seqno,
- request->global_seqno);
+ request->global_seqno,
+ intel_engine_get_seqno(engine));
lockdep_assert_held(&request->i915->drm.struct_mutex);
GEM_BUG_ON(!i915_sw_fence_signaled(&request->submit));
@@ -508,10 +512,11 @@ void __i915_request_submit(struct i915_request *request)
struct intel_engine_cs *engine = request->engine;
u32 seqno;
- GEM_TRACE("%s fence %llx:%d -> global_seqno %d\n",
- request->engine->name,
+ GEM_TRACE("%s fence %llx:%d -> global_seqno %d, current %d\n",
+ engine->name,
request->fence.context, request->fence.seqno,
- engine->timeline->seqno + 1);
+ engine->timeline->seqno + 1,
+ intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
lockdep_assert_held(&engine->timeline->lock);
@@ -557,10 +562,11 @@ void __i915_request_unsubmit(struct i915_request *request)
{
struct intel_engine_cs *engine = request->engine;
- GEM_TRACE("%s fence %llx:%d <- global_seqno %d\n",
- request->engine->name,
+ GEM_TRACE("%s fence %llx:%d <- global_seqno %d, current %d\n",
+ engine->name,
request->fence.context, request->fence.seqno,
- request->global_seqno);
+ request->global_seqno,
+ intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
lockdep_assert_held(&engine->timeline->lock);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ed2c833a8b20..b5235f52a81b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -454,10 +454,11 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
desc = execlists_update_context(rq);
GEM_DEBUG_EXEC(port[n].context_id =
upper_32_bits(desc));
- GEM_TRACE("%s in[%d]: ctx=%d.%d, seqno=%x, prio=%d\n",
+ GEM_TRACE("%s in[%d]: ctx=%d.%d, seqno=%d (current
%d), prio=%d\n",
engine->name, n,
port[n].context_id, count,
rq->global_seqno,
+ intel_engine_get_seqno(engine),
rq_prio(rq));
} else {
GEM_BUG_ON(!n);
@@ -999,10 +1000,11 @@ static void execlists_submission_tasklet(unsigned long
data)
EXECLISTS_ACTIVE_USER));
rq = port_unpack(port, &count);
- GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x, prio=%d\n",
+ GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%d (current %d),
prio=%d\n",
engine->name,
port->context_id, count,
rq ? rq->global_seqno : 0,
+ intel_engine_get_seqno(engine),
rq ? rq_prio(rq) : 0);
/* Check the context/desc id fo
[Intel-gfx] [PATCH] drm/i915/execlists: Reset ring registers on rebinding contexts
Tvrtko uncovered a fun issue with recovering from a wedge device. In his tests, he wedged the driver by injecting an unrecoverable hang whilst a batch was spinning. As we reset the gpu in the middle of the spinner, when resumed it would continue on from the next instruction in the ring and write it's breadcrumb. However, on wedging we updated our bookkeeping to indicate that the GPU had completed executing and would restart from after the breadcrumb; so the emission of the stale breadcrumb from before the reset came as a bit of a surprise. A simple fix is to when rebinding the context into the GPU, we update the ring register state in the context image to match our bookkeeping. We already have to update the RING_START and RING_TAIL, so updating RING_HEAD as well is trivial. This works because whenever we unbind the context, we keep the bookkeeping in check; and on wedging we unbind all contexts. Testcase: igt/gem_eio Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ba7f7831f934..654634254b64 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine, ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE; ce->lrc_reg_state[CTX_RING_BUFFER_START+1] = i915_ggtt_offset(ce->ring->vma); + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; ce->state->obj->pin_global++; i915_gem_context_get(ctx); -- 2.16.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/execlists: Delay updating ring register state after resume
Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 654634254b64..ed2c833a8b20 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2536,13 +2536,14 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
return ret;
}
-void intel_lr_context_resume(struct drm_i915_private *dev_priv)
+void intel_lr_context_resume(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
enum intel_engine_id id;
- /* Because we emit WA_TAIL_DWORDS there may be a disparity
+ /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
* between our bookkeeping in ce->ring->head and ce->ring->tail and
* that stored in context. As we only write new commands from
* ce->ring->tail onwards, everything before that is junk. If the GPU
@@ -2552,26 +2553,14 @@ void intel_lr_context_resume(struct drm_i915_private
*dev_priv)
* So to avoid that we reset the context images upon resume. For
* simplicity, we just zero everything out.
*/
- list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
- for_each_engine(engine, dev_priv, id) {
- struct intel_context *ce = &ctx->engine[engine->id];
- u32 *reg;
-
- if (!ce->state)
- continue;
+ list_for_each_entry(ctx, &i915->contexts.list, link) {
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce = &ctx->engine[id];
- reg = i915_gem_object_pin_map(ce->state->obj,
- I915_MAP_WB);
- if (WARN_ON(IS_ERR(reg)))
+ GEM_BUG_ON(ce->pin_count);
+ if (!ce->ring)
continue;
- reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
- reg[CTX_RING_HEAD+1] = 0;
- reg[CTX_RING_TAIL+1] = 0;
-
- ce->state->obj->mm.dirty = true;
- i915_gem_object_unpin_map(ce->state->obj);
-
intel_ring_reset(ce->ring, 0);
}
}
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/execlists: Reset ring registers on rebinding contexts
Tvrtko uncovered a fun issue with recovering from a wedge device. In his tests, he wedged the driver by injecting an unrecoverable hang whilst a batch was spinning. As we reset the gpu in the middle of the spinner, when resumed it would continue on from the next instruction in the ring and write it's breadcrumb. However, on wedging we updated our bookkeeping to indicate that the GPU had completed executing and would restart from after the breadcrumb; so the emission of the stale breadcrumb from before the reset came as a bit of a surprise. A simple fix is to when rebinding the context into the GPU, we update the ring register state in the context image to match our bookkeeping. We already have to update the RING_START and RING_TAIL, so updating RING_HEAD as well is trivial. This works because whenever we unbind the context, we keep the bookkeeping in check; and on wedging we unbind all contexts. Testcase: igt/gem_eio Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ba7f7831f934..654634254b64 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1272,6 +1272,7 @@ execlists_context_pin(struct intel_engine_cs *engine, ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE; ce->lrc_reg_state[CTX_RING_BUFFER_START+1] = i915_ggtt_offset(ce->ring->vma); + ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head; ce->state->obj->pin_global++; i915_gem_context_get(ctx); -- 2.16.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: make drm_core_check_feature() bool that it is
Quoting Jani Nikula (2018-03-27 21:47:22) > Bool is the more appropriate return type here, use it. > > Signed-off-by: Jani Nikula All 3, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 00/12] drm/i915/guc: Support for Guc responses and requests
On 3/26/2018 12:48 PM, Michal Wajdeczko wrote: With this series we will be able to receive more data from the Guc. New Guc firmwares will be required to actually use that feature. v4: respin series after 1/2 year break v5: updated after review comments Michal Wajdeczko (12): drm/i915/guc: Add documentation for MMIO based communication drm/i915/guc: Add support for data reporting in GuC responses drm/i915/guc: Prepare send() function to accept bigger response drm/i915/guc: Implement response handling in send_mmio() drm/i915/guc: Make event handler a virtual function drm/i915/guc: Prepare to handle messages from CT RECV buffer drm/i915/guc: Use better name for helper wait function drm/i915/guc: Implement response handling in send_ct() drm/i915/guc: Prepare to process incoming requests from CT drm/i915/guc: Handle default action received over CT drm/i915/guc: Trace messages from CT while in debug HAX: Enable GuC for CI drivers/gpu/drm/i915/Kconfig.debug| 12 + drivers/gpu/drm/i915/i915_params.h| 2 +- drivers/gpu/drm/i915/intel_guc.c | 51 +++- drivers/gpu/drm/i915/intel_guc.h | 29 +- drivers/gpu/drm/i915/intel_guc_ct.c | 503 +++--- drivers/gpu/drm/i915/intel_guc_ct.h | 12 + drivers/gpu/drm/i915/intel_guc_fwif.h | 139 -- drivers/gpu/drm/i915/intel_uc.c | 2 + 8 files changed, 678 insertions(+), 72 deletions(-) Hi, My r-b's still apply after addressing Daniele's comment in [v5,10/12]. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen11: Preempt-to-idle support in execlists.
== Series Details == Series: drm/i915/gen11: Preempt-to-idle support in execlists. URL : https://patchwork.freedesktop.org/series/40747/ State : success == Summary == Known issues: Test kms_cursor_legacy: Subgroup flip-vs-cursor-atomic: fail -> PASS (shard-hsw) fdo#102670 Test kms_flip: Subgroup 2x-dpms-vs-vblank-race-interruptible: pass -> FAIL (shard-hsw) fdo#103060 Subgroup 2x-flip-vs-wf_vblank: fail -> PASS (shard-hsw) fdo#100368 +1 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3495 pass:1831 dwarn:1 dfail:0 fail:7 skip:1655 time:12913s shard-hswtotal:3495 pass:1781 dwarn:1 dfail:0 fail:3 skip:1709 time:11676s shard-snbtotal:3495 pass:1374 dwarn:1 dfail:0 fail:3 skip:2117 time:7015s Blacklisted hosts: shard-kbltotal:3493 pass:1950 dwarn:5 dfail:0 fail:9 skip:1528 time:9549s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8505/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm: make drm_core_check_feature() bool that it is
Bool is the more appropriate return type here, use it.
Signed-off-by: Jani Nikula
---
include/drm/drmP.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b5d52a3d7d19..f5099c12c6a6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -115,9 +115,9 @@ static inline bool drm_drv_uses_atomic_modeset(struct
drm_device *dev)
#define DRM_SWITCH_POWER_CHANGING 2
#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
-static inline int drm_core_check_feature(struct drm_device *dev, int feature)
+static inline bool drm_core_check_feature(struct drm_device *dev, int feature)
{
- return ((dev->driver->driver_features & feature) ? 1 : 0);
+ return dev->driver->driver_features & feature;
}
/* returns true if currently okay to sleep */
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm: prefer inline over __inline__
Remove last users of __inline__.
Signed-off-by: Jani Nikula
---
include/drm/drmP.h | 5 ++---
include/drm/drm_legacy.h | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index ccd09347..4bbef061c9c0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -123,8 +123,7 @@ static inline bool drm_drv_uses_atomic_modeset(struct
drm_device *dev)
#define DRM_SWITCH_POWER_CHANGING 2
#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
-static __inline__ int drm_core_check_feature(struct drm_device *dev,
-int feature)
+static inline int drm_core_check_feature(struct drm_device *dev, int feature)
{
return ((dev->driver->driver_features & feature) ? 1 : 0);
}
@@ -143,7 +142,7 @@ static __inline__ int drm_core_check_feature(struct
drm_device *dev,
/*@}*/
/* returns true if currently okay to sleep */
-static __inline__ bool drm_can_sleep(void)
+static inline bool drm_can_sleep(void)
{
if (in_atomic() || in_dbg_master() || irqs_disabled())
return false;
diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
index cf0e7d89bcdf..8fad66f88e4f 100644
--- a/include/drm/drm_legacy.h
+++ b/include/drm/drm_legacy.h
@@ -194,8 +194,8 @@ void drm_legacy_ioremap(struct drm_local_map *map, struct
drm_device *dev);
void drm_legacy_ioremap_wc(struct drm_local_map *map, struct drm_device *dev);
void drm_legacy_ioremapfree(struct drm_local_map *map, struct drm_device *dev);
-static __inline__ struct drm_local_map *drm_legacy_findmap(struct drm_device
*dev,
- unsigned int token)
+static inline struct drm_local_map *drm_legacy_findmap(struct drm_device *dev,
+ unsigned int token)
{
struct drm_map_list *_entry;
list_for_each_entry(_entry, &dev->maplist, head)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm: remove old documentation comment cruft from drmP.h
Throw out the leftovers.
Signed-off-by: Jani Nikula
---
include/drm/drmP.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 4bbef061c9c0..b5d52a3d7d19 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -95,14 +95,6 @@ struct dma_buf_attachment;
struct pci_dev;
struct pci_controller;
-/***/
-/** \name DRM template customization defaults */
-/*@{*/
-
-/***/
-/** \name Internal types and structures */
-/*@{*/
-
#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
/**
@@ -128,19 +120,6 @@ static inline int drm_core_check_feature(struct drm_device
*dev, int feature)
return ((dev->driver->driver_features & feature) ? 1 : 0);
}
-/**/
-/** \name Internal function definitions */
-/*@{*/
-
- /* Driver support (drm_drv.h) */
-
-/*
- * These are exported to drivers so that they can implement fencing using
- * DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
- */
-
-/*@}*/
-
/* returns true if currently okay to sleep */
static inline bool drm_can_sleep(void)
{
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 4/8] drm/i915/uc: Fully sanitize uC in uc_fini_hw
Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as separate function to maintain symmetry with
uc_init_hw.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uc.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index ec90c81..46c4dc4 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -433,19 +433,9 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
return ret;
}
-void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
+void intel_uc_fini_hw(struct drm_i915_private *i915)
{
- struct intel_guc *guc = &dev_priv->guc;
-
- if (!USES_GUC(dev_priv))
- return;
-
- GEM_BUG_ON(!HAS_GUC(dev_priv));
-
- if (USES_GUC_SUBMISSION(dev_priv))
- intel_guc_submission_disable(guc);
-
- guc_disable_communication(guc);
+ intel_uc_sanitize(i915);
}
int intel_uc_suspend(struct drm_i915_private *i915)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 5/8] drm/i915/uc: Use correct error code for GuC initialization failure
Since commit 6ca9a2beb54a ("drm/i915: Unwind i915_gem_init() failure")
we believed that we correctly handle all errors encountered during
GuC initialization, including special one that indicates request to
run driver with disabled GPU submission (-EIO).
Unfortunately since commit 121981fafe69 ("drm/i915/guc: Combine
enable_guc_loading|submission modparams") we stopped using that
error code to avoid unwanted fallback to execlist submission mode.
In result any GuC initialization failure was treated as non-recoverable
error leading to driver load abort, so we could not even read related
GuC error log to investigate cause of the problem.
Fix that by always returning -EIO on uC hardware related failure.
v2: don't allow -EIO from uc_init
don't call uc_fini[_misc] on -EIO
mark guc fw as failed on hw init failure
prepare uc_fini_hw to run after earlier -EIO
v3: update comments (Sagar)
use sanitize functions on failure in init_hw (Michal)
and also sanitize guc/huc fw in fini_hw (Michal)
v4: rebase
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Michal Winiarski
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_gem.c| 17 ++---
drivers/gpu/drm/i915/intel_guc.h | 5 +
drivers/gpu/drm/i915/intel_uc.c| 17 +
drivers/gpu/drm/i915/intel_uc_fw.h | 5 +
4 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 65ba104..82000bd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5361,8 +5361,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_init_gt_powersave(dev_priv);
ret = intel_uc_init(dev_priv);
- if (ret)
+ if (ret) {
+ GEM_BUG_ON(ret == -EIO);
goto err_pm;
+ }
ret = i915_gem_init_hw(dev_priv);
if (ret)
@@ -5409,7 +5411,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
intel_uc_fini_hw(dev_priv);
err_uc_init:
- intel_uc_fini(dev_priv);
+ if (ret != -EIO)
+ intel_uc_fini(dev_priv);
err_pm:
if (ret != -EIO) {
intel_cleanup_gt_powersave(dev_priv);
@@ -5423,15 +5426,15 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(&dev_priv->drm.struct_mutex);
- intel_uc_fini_misc(dev_priv);
-
- if (ret != -EIO)
+ if (ret != -EIO) {
+ intel_uc_fini_misc(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
+ }
if (ret == -EIO) {
/*
-* Allow engine initialisation to fail by marking the GPU as
-* wedged. But we only want to do this where the GPU is angry,
+* Allow engines or uC initialization to fail by marking the GPU
+* as wedged. But we only want to do this when the GPU is angry,
* for all other failure, such as an allocation failure, bail.
*/
if (!i915_terminally_wedged(&dev_priv->gpu_error)) {
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 13f3d1d..7325b0e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -155,6 +155,11 @@ static inline int intel_guc_sanitize(struct intel_guc *guc)
return 0;
}
+static inline bool intel_guc_is_loaded(struct intel_guc *guc)
+{
+ return intel_uc_fw_is_loaded(&guc->fw);
+}
+
static inline void intel_guc_enable_msg(struct intel_guc *guc, u32 mask)
{
spin_lock_irq(&guc->irq_lock);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 46c4dc4..2d8f5d9 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -426,15 +426,24 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
* Note that there is no fallback as either user explicitly asked for
* the GuC or driver default option was to run with the GuC enabled.
*/
- if (GEM_WARN_ON(ret == -EIO))
- ret = -EINVAL;
-
dev_err(dev_priv->drm.dev, "GuC initialization failed %d\n", ret);
- return ret;
+
+ /* Sanitize GuC/HuC to avoid clean-up on wedged */
+ intel_huc_sanitize(huc);
+ intel_guc_sanitize(guc);
+ GEM_BUG_ON(intel_guc_is_loaded(guc));
+
+ /* We want to disable GPU submission but keep KMS alive */
+ return -EIO;
}
void intel_uc_fini_hw(struct drm_i915_private *i915)
{
+ struct intel_guc *guc = &i915->guc;
+
+ if (!intel_guc_is_loaded(guc))
+ return;
+
intel_uc_sanitize(i915);
}
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h
b/drivers/gpu/drm/i915/intel_uc_fw.h
index dc33b12..77ad2aa 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu
[Intel-gfx] [PATCH v5 3/8] drm/i915/guc: Restore symmetric doorbell cleanup
In commit 9192d4fb811e ("drm/i915/guc: Extract doorbell creation
from client allocation") we introduced asymmetry in doorbell cleanup
to avoid warnings due to failed communication with already reset GuC.
As we improved our reset/unload paths, we can restore symmetry in
doorbell cleanup, as GuC should be still active by now.
Suggested-by: Sagar Arun Kamble
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Michal Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 207cda0..26985d8 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -835,18 +835,9 @@ static int guc_clients_doorbell_init(struct intel_guc *guc)
static void guc_clients_doorbell_fini(struct intel_guc *guc)
{
- /*
-* By the time we're here, GuC has already been reset.
-* Instead of trying (in vain) to communicate with it, let's just
-* cleanup the doorbell HW and our internal state.
-*/
- if (guc->preempt_client) {
- __destroy_doorbell(guc->preempt_client);
- __update_doorbell_desc(guc->preempt_client,
- GUC_DOORBELL_INVALID);
- }
- __destroy_doorbell(guc->execbuf_client);
- __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID);
+ if (guc->preempt_client)
+ destroy_doorbell(guc->preempt_client);
+ destroy_doorbell(guc->execbuf_client);
}
/**
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 6/8] drm/i915/uc: Use helper functions to detect fw load status
We don't have to check load status values. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_huc.c | 2 +- drivers/gpu/drm/i915/intel_uc.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c index 2912852..975ae61 100644 --- a/drivers/gpu/drm/i915/intel_huc.c +++ b/drivers/gpu/drm/i915/intel_huc.c @@ -51,7 +51,7 @@ int intel_huc_auth(struct intel_huc *huc) u32 status; int ret; - if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_uc_fw_is_loaded(&huc->fw)) return -ENOEXEC; vma = i915_gem_object_ggtt_pin(huc->fw.obj, NULL, 0, 0, diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 2d8f5d9..14664fe 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -455,7 +455,7 @@ int intel_uc_suspend(struct drm_i915_private *i915) if (!USES_GUC(i915)) return 0; - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_guc_is_loaded(guc)) return 0; err = intel_guc_suspend(guc); @@ -477,7 +477,7 @@ int intel_uc_resume(struct drm_i915_private *i915) if (!USES_GUC(i915)) return 0; - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) + if (!intel_guc_is_loaded(guc)) return 0; if (i915_modparams.guc_log_level) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 7/8] drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.
v2: don't forget about function descriptions (Sagar)
v3: rebased
Signed-off-by: Michal Wajdeczko
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/intel_uc.c | 87 -
1 file changed, 43 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 14664fe..fec5514 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -50,10 +50,10 @@ static int __intel_uc_reset_hw(struct drm_i915_private
*dev_priv)
return ret;
}
-static int __get_platform_enable_guc(struct drm_i915_private *dev_priv)
+static int __get_platform_enable_guc(struct drm_i915_private *i915)
{
- struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
- struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
+ struct intel_uc_fw *guc_fw = &i915->guc.fw;
+ struct intel_uc_fw *huc_fw = &i915->huc.fw;
int enable_guc = 0;
/* Default is to enable GuC/HuC if we know their firmwares */
@@ -67,11 +67,11 @@ static int __get_platform_enable_guc(struct
drm_i915_private *dev_priv)
return enable_guc;
}
-static int __get_default_guc_log_level(struct drm_i915_private *dev_priv)
+static int __get_default_guc_log_level(struct drm_i915_private *i915)
{
int guc_log_level;
- if (!HAS_GUC(dev_priv) || !intel_uc_is_using_guc())
+ if (!HAS_GUC(i915) || !intel_uc_is_using_guc())
guc_log_level = GUC_LOG_LEVEL_DISABLED;
else if (IS_ENABLED(CONFIG_DRM_I915_DEBUG) ||
IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -86,7 +86,7 @@ static int __get_default_guc_log_level(struct
drm_i915_private *dev_priv)
/**
* sanitize_options_early - sanitize uC related modparam options
- * @dev_priv: device private
+ * @i915: device private
*
* In case of "enable_guc" option this function will attempt to modify
* it only if it was initially set to "auto(-1)". Default value for this
@@ -101,14 +101,14 @@ static int __get_default_guc_log_level(struct
drm_i915_private *dev_priv)
* unless GuC is enabled on given platform and the driver is compiled with
* debug config when this modparam will default to "enable(1..4)".
*/
-static void sanitize_options_early(struct drm_i915_private *dev_priv)
+static void sanitize_options_early(struct drm_i915_private *i915)
{
- struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
- struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
+ struct intel_uc_fw *guc_fw = &i915->guc.fw;
+ struct intel_uc_fw *huc_fw = &i915->huc.fw;
/* A negative value means "use platform default" */
if (i915_modparams.enable_guc < 0)
- i915_modparams.enable_guc = __get_platform_enable_guc(dev_priv);
+ i915_modparams.enable_guc = __get_platform_enable_guc(i915);
DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s)\n",
i915_modparams.enable_guc,
@@ -119,28 +119,28 @@ static void sanitize_options_early(struct
drm_i915_private *dev_priv)
if (intel_uc_is_using_guc() && !intel_uc_fw_is_selected(guc_fw)) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
"enable_guc", i915_modparams.enable_guc,
-!HAS_GUC(dev_priv) ? "no GuC hardware" :
- "no GuC firmware");
+!HAS_GUC(i915) ? "no GuC hardware" :
+ "no GuC firmware");
}
/* Verify HuC firmware availability */
if (intel_uc_is_using_huc() && !intel_uc_fw_is_selected(huc_fw)) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
"enable_guc", i915_modparams.enable_guc,
-!HAS_HUC(dev_priv) ? "no HuC hardware" :
- "no HuC firmware");
+!HAS_HUC(i915) ? "no HuC hardware" :
+ "no HuC firmware");
}
/* A negative value means "use platform/config default" */
if (i915_modparams.guc_log_level < 0)
i915_modparams.guc_log_level =
- __get_default_guc_log_level(dev_priv);
+ __get_default_guc_log_level(i915);
if (i915_modparams.guc_log_level > 0 && !intel_uc_is_using_guc()) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
"guc_log_level", i915_modparams.guc_log_level,
-!HAS_GUC(dev_priv) ? "no GuC hardware" :
- "GuC not enabled");
+!HAS_GUC(i915) ? "no GuC hardware" :
+ "GuC not enabled");
i
[Intel-gfx] [PATCH v5 8/8] HAX: Enable GuC for CI
v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index fec5514..bbb2c36 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -63,6 +63,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *i915) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + enable_guc = 0; return enable_guc; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/8] drm/i915: Correctly handle error path in i915_gem_init_hw
In function gem_init_hw() we are calling uc_init_hw() but in case of error later in function, we missed to call matching uc_fini_hw() Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_gem.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 9650a7b..65ba104 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -5171,9 +5171,15 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv) /* Only when the HW is re-initialised, can we replay the requests */ ret = __i915_gem_restart_engines(dev_priv); + if (ret) + goto cleanup_uc; out: intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); return ret; + +cleanup_uc: + intel_uc_fini_hw(dev_priv); + goto out; } static int __intel_engines_record_defaults(struct drm_i915_private *i915) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/8] drm/i915/uc: Disable GuC submission during sanitize
We should not leave GuC submission enabled after sanitize, as we are going to reset all GuC/HuC hardware. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 4aad844..ec90c81 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -330,6 +330,9 @@ void intel_uc_sanitize(struct drm_i915_private *i915) GEM_BUG_ON(!HAS_GUC(i915)); + if (USES_GUC_SUBMISSION(dev_priv)) + intel_guc_submission_disable(guc); + guc_disable_communication(guc); intel_huc_sanitize(huc); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 09/12] drm/i915/guc: Prepare to process incoming requests from CT
On 3/26/2018 12:48 PM, Wajdeczko, Michal wrote:
Requests are read from CT in the irq handler, but actual processing
will be done in the work thread. Processing of specific actions will
be added in the upcoming patches.
v2: don't use GEM_BUG_ON (Chris)
don't kmalloc too large buffer (Michal)
v3: rebased
v4: don't name it 'dispatch' (Michel) and fix checkpatch
add some documentation (Michal)
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_ct.c | 95 -
drivers/gpu/drm/i915/intel_guc_ct.h | 6 +++
2 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 41b071c..aa810ad 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -32,10 +32,17 @@ struct ct_request {
u32 *response_buf;
};
+struct ct_incoming_request {
+ struct list_head link;
+ u32 msg[];
+};
+
enum { CTB_SEND = 0, CTB_RECV = 1 };
enum { CTB_OWNER_HOST = 0 };
+static void ct_incoming_request_worker_func(struct work_struct *w);
+
/**
* intel_guc_ct_init_early - Initialize CT state without requiring device
access
* @ct: pointer to CT struct
@@ -47,6 +54,8 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
spin_lock_init(&ct->lock);
INIT_LIST_HEAD(&ct->pending_requests);
+ INIT_LIST_HEAD(&ct->incoming_requests);
+ INIT_WORK(&ct->worker, ct_incoming_request_worker_func);
}
static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -682,13 +691,97 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
return 0;
}
+static void ct_process_request(struct intel_guc_ct *ct,
+ u32 action, u32 len, const u32 *payload)
+{
+ switch (action) {
+ default:
+ DRM_ERROR("CT: unexpected request %x %*phn\n",
+ action, 4 * len, payload);
+ break;
+ }
+}
+
+static bool ct_process_incoming_requests(struct intel_guc_ct *ct)
+{
+ unsigned long flags;
+ struct ct_incoming_request *request;
+ u32 header;
+ u32 *payload;
+ bool done;
+
+ spin_lock_irqsave(&ct->lock, flags);
+ request = list_first_entry_or_null(&ct->incoming_requests,
+ struct ct_incoming_request, link);
+ if (request)
+ list_del(&request->link);
+ done = !!list_empty(&ct->incoming_requests);
+ spin_unlock_irqrestore(&ct->lock, flags);
+
+ if (!request)
+ return true;
+
+ header = request->msg[0];
+ payload = &request->msg[1];
+ ct_process_request(ct,
+ ct_header_get_action(header),
+ ct_header_get_len(header),
+ payload);
+
+ kfree(request);
+ return done;
+}
+
+static void ct_incoming_request_worker_func(struct work_struct *w)
+{
+ struct intel_guc_ct *ct = container_of(w, struct intel_guc_ct, worker);
+ bool done;
+
+ done = ct_process_incoming_requests(ct);
+ if (!done)
+ queue_work(system_unbound_wq, &ct->worker);
+}
+
+/**
+ * DOC: CTB GuC to Host request
+ *
+ * Format of the CTB GuC to Host request message is as follows::
+ *
+ * ++-+-+-+-+-+
+ * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
+ * ++-+-+-+-+-+
+ * | MESSAGE | MESSAGE PAYLOAD |
+ * + HEADER +-+-+-+-+-+
+ * ||0|1|2| ... |n|
+ * ++=+=+=+=+=+
+ * | len|request specific data|
+ * +--+-+-+-+-+-+-+
+ *
+ * ^---len---^
+ */
+
static int ct_handle_request(struct intel_guc_ct *ct, const u32 *msg)
{
u32 header = msg[0];
+ u32 len = ct_header_get_len(header);
+ u32 msglen = len + 1; /* total message length including header */
+ struct ct_incoming_request *request;
+ unsigned long flags;
GEM_BUG_ON(ct_header_is_response(header));
- /* XXX */
+ request = kmalloc(sizeof(*request) + 4 * msglen, GFP_ATOMIC);
+ if (unlikely(!request)) {
+ DRM_ERROR("CT: dropping request %*phn\n", 4 * msglen, msg);
+ return 0; /* XXX: -ENOMEM ? */
+ }
+ memcpy(request->msg, msg, 4 * msglen);
+
+ spin_lock_irqsave(&ct->lock, flags);
+ list_add_tail(&request->link, &ct->incoming_requests);
+ spin_unlock_irqrestore(&ct->lock
Re: [Intel-gfx] [PATCH v5 10/12] drm/i915/guc: Handle default action received over CT
On 3/27/2018 11:25 AM, Daniele Ceraolo Spurio wrote:
On 26/03/18 12:48, Michal Wajdeczko wrote:
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_guc.c | 5 +
drivers/gpu/drm/i915/intel_guc.h | 1 +
drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc.c
b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct
intel_guc *guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(&guc->irq_lock);
+ intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(&guc->log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h
b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc,
const u32 *action, u32 len,
void intel_guc_to_host_event_handler(struct intel_guc *guc);
void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct
*ct, const u32 *msg)
static void ct_process_request(struct intel_guc_ct *ct,
u32 action, u32 len, const u32 *payload)
{
+ struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+ case INTEL_GUC_ACTION_DEFAULT:
+ if (unlikely(len < 1))
+ goto fail_unexpected;
Don't we need to remove the non-enabled messages here? i.e. like we do
for the mmio receive:
msg = *payload & guc->msg_enabled_mask;
otherwise I think we'll try to process log interrupts even if the relay
is not enabled.
In Daniele's specific example, I still think guc_log_enable_flush_events
should have been called (and don't do anything inside
handle_flush_event, the goal was to not serve it).
But it's true that we should filter any unexpected incoming request (&
guc->msg_enabled_mask), and any new user should be calling
intel_guc_enable_msg during its setup.
Thanks,
Daniele
+ intel_guc_to_host_process_recv_msg(guc, *payload);
+ break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4 * len, payload);
break;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] The behavior of i915_wait_request() after calling i915_gem_suspend_request()
Hi Chris and Joonas: Thanks for the discussion in the IRC for the suspend/resume request APIs. I just a bit curious about the behavior of i915_wait_request() after a caller suspend an i915 request. Will the caller of i915_wait_request() be woken up at this time? or not? This behavior decides how we are going to use those APIs. :) Thanks again for the discussion and efforts. :) Thanks, Zhi. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_eio: Never re-use contexts which were in the middle of GPU reset
Quoting Tvrtko Ursulin (2018-03-27 17:40:56) > From: Tvrtko Ursulin > > Contexts executing when reset triggers are potentialy corrupt so trying to > use them from a subsequent test (like the default context) can hang the > GPU or even the driver. > > Workaround that by always creating a dedicated context which will be > running when GPU reset happens. Hmm, what CI won't say until it gets around to running on the shards (i.e. post merge) is that the !contexts tests are expected to pass on the older gen. This patch will now fail in gem_context_create(). I was only half jokingly suggesting reopen_device(). As CI is only running each subtest individually, I don't think we are exposed to the issue, that should give us a bit of time to hopefully fix it. So back to the perplexing puzzle. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs
On Tue, 2018-03-27 at 13:24 +0300, Ville Syrjälä wrote:
> On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote:
> > Interrupts other than the one for AUX errors are required only for debug,
> > so unmask them via debugfs when the user requests debug.
> >
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> >
> > v2: Unroll loops (Ville)
> > Avoid resetting error mask bits.
> >
> > Cc: Rodrigo Vivi
> > Cc: Ville Syrjälä
> > Cc: Chris Wilson
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 36 +++-
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_irq.c | 55
> > +++--
> > drivers/gpu/drm/i915/intel_drv.h| 2 ++
> > drivers/gpu/drm/i915/intel_psr.c| 54
> >
> > 5 files changed, 108 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 7816cd53100a..6fd801ef7cbb 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m,
> > void *data)
> > return 0;
> > }
> >
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > + struct drm_i915_private *dev_priv = data;
> > +
> > + if (!CAN_PSR(dev_priv))
> > + return -ENODEV;
> > +
> > + if (val < 0 || val > 1)
> > + return -EINVAL;
>
> Can't be < 0.
>
> > +
> > + DRM_DEBUG_KMS("%s PSR debug\n", val == 1 ? "Enabling" : "Disabling");
>
> ==1 seems pointless
> enableddisabled() could be used perhaps.
>
Will do.
>
> > + intel_psr_debug_control(dev_priv, val);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +i915_edp_psr_debug_get(void *data, u64 *val)
> > +{
> > + struct drm_i915_private *dev_priv = data;
> > +
> > + if (!CAN_PSR(dev_priv))
> > + return -ENODEV;
> > +
> > + *val = READ_ONCE(dev_priv->psr.debug);
> > + return 0;
> > +}
> > +
> > +DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
> > + i915_edp_psr_debug_get, i915_edp_psr_debug_set,
> > + "%llu\n");
> > +
> > static int i915_sink_crc(struct seq_file *m, void *data)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > @@ -4811,7 +4844,8 @@ static const struct i915_debugfs_files {
> > {"i915_guc_log_relay", &i915_guc_log_relay_fops},
> > {"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops},
> > {"i915_ipc_status", &i915_ipc_status_fops},
> > - {"i915_drrs_ctl", &i915_drrs_ctl_fops}
> > + {"i915_drrs_ctl", &i915_drrs_ctl_fops},
> > + {"i915_edp_psr_debug", &i915_edp_psr_debug_fops}
> > };
> >
> > int i915_debugfs_register(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c9c3b2ba6a86..c0224a86344e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -608,6 +608,7 @@ struct i915_psr {
> > bool colorimetry_support;
> > bool alpm;
> > bool has_hw_tracking;
> > + bool debug;
> >
> > void (*enable_source)(struct intel_dp *,
> > const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 8a894adf2ca1..e5aaf805c6a8 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2391,40 +2391,6 @@ static void ilk_display_irq_handler(struct
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> > }
> >
> > -static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
> > -{
> > - u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > - u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
> > - u32 mask = BIT(TRANSCODER_EDP);
> > - enum transcoder cpu_transcoder;
> > -
> > - if (INTEL_GEN(dev_priv) >= 8)
> > - mask |= BIT(TRANSCODER_A) |
> > - BIT(TRANSCODER_B) |
> > - BIT(TRANSCODER_C);
> > -
> > - for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
> > - if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > - DRM_DEBUG_KMS("Transcoder %s PSR error\n",
> > - transcoder_name(cpu_transcoder));
> > -
> > - if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > - DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2
> > vblanks\n",
> > - transcoder_name(cpu_transcoder));
> > - edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
> > - }
> > -
> > - if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
> > - DRM_DEBUG_KMS("Transcoder %s PSR exit completed\n",
> > -
Re: [Intel-gfx] [PATCH v5 10/12] drm/i915/guc: Handle default action received over CT
On 26/03/18 12:48, Michal Wajdeczko wrote:
When running on platform with CTB based GuC communication enabled,
GuC to Host event data will be delivered as CT request message.
However, content of the data[1] of this CT message follows format
of the scratch register used in MMIO based communication, so some
code reuse is still possible.
Signed-off-by: Michal Wajdeczko
Cc: Oscar Mateo
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_guc.c| 5 +
drivers/gpu/drm/i915/intel_guc.h| 1 +
drivers/gpu/drm/i915/intel_guc_ct.c | 9 +
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 118db81..b6d2778 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -416,6 +416,11 @@ void intel_guc_to_host_event_handler_mmio(struct intel_guc
*guc)
I915_WRITE(SOFT_SCRATCH(15), val & ~msg);
spin_unlock(&guc->irq_lock);
+ intel_guc_to_host_process_recv_msg(guc, msg);
+}
+
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)
+{
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(&guc->log);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc109a..f1265e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -163,6 +163,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*action, u32 len,
void intel_guc_to_host_event_handler(struct intel_guc *guc);
void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
+void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
int intel_guc_sample_forcewake(struct intel_guc *guc);
int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index aa810ad..e837084 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -694,8 +694,17 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
static void ct_process_request(struct intel_guc_ct *ct,
u32 action, u32 len, const u32 *payload)
{
+ struct intel_guc *guc = ct_to_guc(ct);
+
switch (action) {
+ case INTEL_GUC_ACTION_DEFAULT:
+ if (unlikely(len < 1))
+ goto fail_unexpected;
Don't we need to remove the non-enabled messages here? i.e. like we do
for the mmio receive:
msg = *payload & guc->msg_enabled_mask;
otherwise I think we'll try to process log interrupts even if the relay
is not enabled.
Daniele
+ intel_guc_to_host_process_recv_msg(guc, *payload);
+ break;
+
default:
+fail_unexpected:
DRM_ERROR("CT: unexpected request %x %*phn\n",
action, 4 * len, payload);
break;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.
On 2018-03-21 20:42, Oscar Mateo wrote: On 3/21/2018 3:16 AM, Chris Wilson wrote: Quoting Oscar Mateo (2018-03-20 18:43:45) On 3/19/2018 7:14 AM, Lis, Tomasz wrote: On 2018-03-19 13:43, Chris Wilson wrote: Quoting Tomasz Lis (2018-03-19 12:37:35) The patch adds a parameter to control the data port coherency functionality on a per-exec call basis. When data port coherency flag value is different than what it was in previous call for the context, a command to switch data port coherency state is added before the buffer to be executed. So this is part of the context? Why do it at exec level? It is part of the context, stored within HDC chicken bit register. The exec level was requested by the OCL team, due to concerns about performance cost of context setparam calls. If exec level is desired, why not whitelist it? -Chris If we have no issue in whitelisting the register, I'm sure OCL will agree to that. I assumed the whitelisting will be unacceptable because of security concerns with some options. The register also changes its position and content between gens, which makes whitelisting hard to manage. I think a security analysis of this register was already done, and the result was that it contains some other bits that could be dangerous. In CNL those bits were moved out of the way and the HDC_CHICKEN0 register can be whitelisted (WaAllowUMDToControlCoherency). In ICL the register should already be non-privileged. The previous alternative to whitelisting was running through a command parser for validation. That's a very general mechanism suitable for a wide range of sins. -Chris Are you suggesting that we enable the cmd parser for every Gen < CNL for this particular usage only? :P It is a solution that would allow to do what we want without any additions to module interface. It may be worth considering if we think the coherency setting will be temporary and removed in future gens, as we wouldn't want to have obsolete flags. I think the setting will stay with us, as it is needed to support CL_MEM_SVM_FINE_GRAIN_BUFFER flag from OpenCL spec. Keeping coherency will always cost performance, so we will likely always have a hardware setting to switch it. But the bspec says coherency override control will be removed in future projects... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Reword warning for missing cases
On Mon, Mar 19, 2018 at 09:41:32PM +, Chris Wilson wrote: > Quoting Lucas De Marchi (2018-03-19 17:37:20) > > In some places we end up converting switch statements to a series of > > if/else, particularly when introducing helper functions to handle a > > group of cases. It's tempting to either leave a wrong warning (since now > > we don't have a switch case anymore) or to convert to WARN(1, ...), > > but we can just provide a better message and avoid the doubt when such > > conversions arrise. > > > > Introducing a warning inside i915_driver_load() just for tests we get: > > > > [ 4535.233717] Missing case (ret == 0) > > [ 4535.233868] WARNING: CPU: 1 PID: 795 at > > drivers/gpu/drm/i915/i915_drv.c:1341 i915_driver_load+0x42/0x10e0 [i915] > > > > which is clear enough. > > > > v2: remove __func__ since this is already on the warning. > > > > Cc: Chris Wilson > > Cc: Ville Syrjälä > > Cc: Daniel Vetter > > Signed-off-by: Lucas De Marchi > Reviewed-by: Chris Wilson pushed to dinq. thanks for patch and reviews. > -Chris > ___ > 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 v2 7/7] drm/i915: reorder dpll_info members
On Fri, Mar 23, 2018 at 06:25:52PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 20, 2018 at 03:06:37PM -0700, Lucas De Marchi wrote:
> > Remove 4-bytes hole in this struct an reorder tables accordingly. This
> > also changes the last element of the tables to be more future-proof.
> >
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/intel_dpll_mgr.c | 48
> > +--
> > drivers/gpu/drm/i915/intel_dpll_mgr.h | 13 ++
> > 2 files changed, 32 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index bda69e1ccd76..d5e114e9660b 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -1908,9 +1908,9 @@ struct intel_dpll_mgr {
> > };
> >
> > static const struct dpll_info pch_plls[] = {
> > - { "PCH DPLL A", DPLL_ID_PCH_PLL_A, &ibx_pch_dpll_funcs, 0 },
> > - { "PCH DPLL B", DPLL_ID_PCH_PLL_B, &ibx_pch_dpll_funcs, 0 },
> > - { NULL, -1, NULL, 0 },
> > + { "PCH DPLL A", &ibx_pch_dpll_funcs, DPLL_ID_PCH_PLL_A, 0 },
> > + { "PCH DPLL B", &ibx_pch_dpll_funcs, DPLL_ID_PCH_PLL_B, 0 },
>
> I usually prefer named initializer to be used pretty much everywhere.
>
> Patches 6-7 are
> Reviewed-by: Ville Syrjälä
> regardless.
pushed to dinq. Thanks for patches and reviews.
>
> > + { },
> > };
> >
> > static const struct intel_dpll_mgr pch_pll_mgr = {
> > @@ -1920,13 +1920,13 @@ static const struct intel_dpll_mgr pch_pll_mgr = {
> > };
> >
> > static const struct dpll_info hsw_plls[] = {
> > - { "WRPLL 1",DPLL_ID_WRPLL1, &hsw_ddi_wrpll_funcs, 0 },
> > - { "WRPLL 2",DPLL_ID_WRPLL2, &hsw_ddi_wrpll_funcs, 0 },
> > - { "SPLL", DPLL_ID_SPLL, &hsw_ddi_spll_funcs, 0 },
> > - { "LCPLL 810", DPLL_ID_LCPLL_810, &hsw_ddi_lcpll_funcs,
> > INTEL_DPLL_ALWAYS_ON },
> > - { "LCPLL 1350", DPLL_ID_LCPLL_1350, &hsw_ddi_lcpll_funcs,
> > INTEL_DPLL_ALWAYS_ON },
> > - { "LCPLL 2700", DPLL_ID_LCPLL_2700, &hsw_ddi_lcpll_funcs,
> > INTEL_DPLL_ALWAYS_ON },
> > - { NULL, -1, NULL, },
> > + { "WRPLL 1",&hsw_ddi_wrpll_funcs, DPLL_ID_WRPLL1, 0 },
> > + { "WRPLL 2",&hsw_ddi_wrpll_funcs, DPLL_ID_WRPLL2, 0 },
> > + { "SPLL", &hsw_ddi_spll_funcs, DPLL_ID_SPLL, 0 },
> > + { "LCPLL 810", &hsw_ddi_lcpll_funcs, DPLL_ID_LCPLL_810,
> > INTEL_DPLL_ALWAYS_ON },
> > + { "LCPLL 1350", &hsw_ddi_lcpll_funcs, DPLL_ID_LCPLL_1350,
> > INTEL_DPLL_ALWAYS_ON },
> > + { "LCPLL 2700", &hsw_ddi_lcpll_funcs, DPLL_ID_LCPLL_2700,
> > INTEL_DPLL_ALWAYS_ON },
> > + { },
> > };
> >
> > static const struct intel_dpll_mgr hsw_pll_mgr = {
> > @@ -1936,11 +1936,11 @@ static const struct intel_dpll_mgr hsw_pll_mgr = {
> > };
> >
> > static const struct dpll_info skl_plls[] = {
> > - { "DPLL 0", DPLL_ID_SKL_DPLL0, &skl_ddi_dpll0_funcs,
> > INTEL_DPLL_ALWAYS_ON },
> > - { "DPLL 1", DPLL_ID_SKL_DPLL1, &skl_ddi_pll_funcs, 0 },
> > - { "DPLL 2", DPLL_ID_SKL_DPLL2, &skl_ddi_pll_funcs, 0 },
> > - { "DPLL 3", DPLL_ID_SKL_DPLL3, &skl_ddi_pll_funcs, 0 },
> > - { NULL, -1, NULL, },
> > + { "DPLL 0", &skl_ddi_dpll0_funcs, DPLL_ID_SKL_DPLL0,
> > INTEL_DPLL_ALWAYS_ON },
> > + { "DPLL 1", &skl_ddi_pll_funcs, DPLL_ID_SKL_DPLL1, 0 },
> > + { "DPLL 2", &skl_ddi_pll_funcs, DPLL_ID_SKL_DPLL2, 0 },
> > + { "DPLL 3", &skl_ddi_pll_funcs, DPLL_ID_SKL_DPLL3, 0 },
> > + { },
> > };
> >
> > static const struct intel_dpll_mgr skl_pll_mgr = {
> > @@ -1950,10 +1950,10 @@ static const struct intel_dpll_mgr skl_pll_mgr = {
> > };
> >
> > static const struct dpll_info bxt_plls[] = {
> > - { "PORT PLL A", DPLL_ID_SKL_DPLL0, &bxt_ddi_pll_funcs, 0 },
> > - { "PORT PLL B", DPLL_ID_SKL_DPLL1, &bxt_ddi_pll_funcs, 0 },
> > - { "PORT PLL C", DPLL_ID_SKL_DPLL2, &bxt_ddi_pll_funcs, 0 },
> > - { NULL, -1, NULL, },
> > + { "PORT PLL A", &bxt_ddi_pll_funcs, DPLL_ID_SKL_DPLL0, 0 },
> > + { "PORT PLL B", &bxt_ddi_pll_funcs, DPLL_ID_SKL_DPLL1, 0 },
> > + { "PORT PLL C", &bxt_ddi_pll_funcs, DPLL_ID_SKL_DPLL2, 0 },
> > + { },
> > };
> >
> > static const struct intel_dpll_mgr bxt_pll_mgr = {
> > @@ -2387,10 +2387,10 @@ static const struct intel_shared_dpll_funcs
> > cnl_ddi_pll_funcs = {
> > };
> >
> > static const struct dpll_info cnl_plls[] = {
> > - { "DPLL 0", DPLL_ID_SKL_DPLL0, &cnl_ddi_pll_funcs, 0 },
> > - { "DPLL 1", DPLL_ID_SKL_DPLL1, &cnl_ddi_pll_funcs, 0 },
> > - { "DPLL 2", DPLL_ID_SKL_DPLL2, &cnl_ddi_pll_funcs, 0 },
> > - { NULL, -1, NULL, },
> > + { "DPLL 0", &cnl_ddi_pll_funcs, DPLL_ID_SKL_DPLL0, 0 },
> > + { "DPLL 1", &cnl_ddi_pll_funcs, DPLL_ID_SKL_DPLL1, 0 },
> > + { "DPLL 2", &cnl_ddi_pll_funcs, DPLL_ID_SKL_DPLL2, 0 },
> > + { },
> > };
> >
> > static const struct intel_dpll_mgr cnl_pll_mgr = {
> > @@ -2430,7 +2430,7 @@ void intel_shared_dpll_init(struct drm_device *dev)
> >
> > dpll_info = dpll_mgr->dpll_inf
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Support for Guc responses and requests (rev4)
== Series Details == Series: drm/i915/guc: Support for Guc responses and requests (rev4) URL : https://patchwork.freedesktop.org/series/28393/ State : failure == Summary == Possible new issues: Test gem_eio: Subgroup execbuf: pass -> INCOMPLETE (shard-apl) Subgroup throttle: pass -> INCOMPLETE (shard-apl) Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite: fail -> PASS (shard-apl) Test perf: Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Known issues: Test drv_missed_irq: pass -> SKIP (shard-apl) fdo#103199 Test kms_flip: Subgroup flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 fdo#103199 https://bugs.freedesktop.org/show_bug.cgi?id=103199 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3483 pass:1819 dwarn:1 dfail:0 fail:11 skip:1650 time:12588s shard-hswtotal:3495 pass:1782 dwarn:1 dfail:0 fail:2 skip:1709 time:11678s shard-snbtotal:3495 pass:1374 dwarn:1 dfail:0 fail:3 skip:2117 time:6962s Blacklisted hosts: shard-kbltotal:3143 pass:1719 dwarn:1 dfail:0 fail:11 skip:1404 time:7156s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8504/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/7] drm/i915/uc: Fully sanitize uC in uc_fini_hw
On Mon, 26 Mar 2018 13:23:21 +0200, Sagar Arun Kamble
wrote:
On 3/23/2018 8:44 PM, Michal Wajdeczko wrote:
Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as separate function to maintain symmetry with
uc_init_hw.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
We should drop call to uc_fini_hw from gem_fini as part of this patch as
GuC won't be available then.
But we will need it in gem_fini to properly finish our cleanup on unload.
Maybe to keep symmetry, we should add i915_gem_fini_hw and call it from
there ? See cleanup inside i915_gem_init_hw.
/m
---
drivers/gpu/drm/i915/intel_uc.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 2389828..9ff0c5a 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -434,19 +434,9 @@ int intel_uc_init_hw(struct drm_i915_private
*dev_priv)
return ret;
}
-void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
+void intel_uc_fini_hw(struct drm_i915_private *i915)
{
- struct intel_guc *guc = &dev_priv->guc;
-
- if (!USES_GUC(dev_priv))
- return;
-
- GEM_BUG_ON(!HAS_GUC(dev_priv));
-
- if (USES_GUC_SUBMISSION(dev_priv))
- intel_guc_submission_disable(guc);
-
- guc_disable_communication(guc);
+ intel_uc_sanitize(i915);
}
int intel_uc_suspend(struct drm_i915_private *i915)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/7] drm/i915/uc: Disable GuC submission during sanitize
On Mon, 26 Mar 2018 12:36:05 +0200, Sagar Arun Kamble wrote: On 3/23/2018 8:44 PM, Michal Wajdeczko wrote: We should not leave GuC submission enabled after sanitize, as we are going to reset all GuC/HuC hardware. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Either we need now destroy the doorbells cleanly or remove the below comment from clients_doorbell_fini: /* * By the time we're here, GuC has already been reset. * Instead of trying (in vain) to communicate with it, let's just * cleanup the doorbell HW and our internal state. */ Good catch! I'll restore symmetric doorbell cleanup in separate patch right after this one. One additional thing I feel we should do now is remove uc_suspend|resume from gem_suspend|resume because we don't want to do any GuC actions once we suspend it. Hmm, I would keep it to maintain symmetry with gem, and in us_resume we already have guard for checking unloaded/sanitized GuC. /m --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 34f8a2c..2389828 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -331,6 +331,9 @@ void intel_uc_sanitize(struct drm_i915_private *i915) GEM_BUG_ON(!HAS_GUC(i915)); + if (USES_GUC_SUBMISSION(dev_priv)) + intel_guc_submission_disable(guc); + guc_disable_communication(guc); intel_huc_sanitize(huc); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/gem_eio: Never re-use contexts which were in the middle of GPU reset
From: Tvrtko Ursulin
Contexts executing when reset triggers are potentialy corrupt so trying to
use them from a subsequent test (like the default context) can hang the
GPU or even the driver.
Workaround that by always creating a dedicated context which will be
running when GPU reset happens.
Signed-off-by: Tvrtko Ursulin
---
tests/gem_eio.c | 96 +++--
1 file changed, 60 insertions(+), 36 deletions(-)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index b824d9d4c9c0..cefe26adf893 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -249,14 +249,34 @@ static int __check_wait(int fd, uint32_t bo, unsigned int
wait)
return ret;
}
+static uint32_t context_create_safe(int i915)
+{
+ struct drm_i915_gem_context_param param;
+
+ memset(¶m, 0, sizeof(param));
+
+ param.ctx_id = gem_context_create(i915);
+ param.param = I915_CONTEXT_PARAM_BANNABLE;
+ gem_context_set_param(i915, ¶m);
+
+ param.param = I915_CONTEXT_PARAM_NO_ERROR_CAPTURE;
+ param.value = 1;
+ gem_context_set_param(i915, ¶m);
+
+ return param.ctx_id;
+}
+
#define TEST_WEDGE (1)
static void test_wait(int fd, unsigned int flags, unsigned int wait)
{
igt_spin_t *hang;
+ uint32_t ctx;
igt_require_gem(fd);
+ ctx = context_create_safe(fd);
+
/*
* If the request we wait on completes due to a hang (even for
* that request), the user expects the return value to 0 (success).
@@ -267,7 +287,7 @@ static void test_wait(int fd, unsigned int flags, unsigned
int wait)
else
igt_require(i915_reset_control(true));
- hang = spin_sync(fd, 0, I915_EXEC_DEFAULT);
+ hang = spin_sync(fd, ctx, I915_EXEC_DEFAULT);
igt_assert_eq(__check_wait(fd, hang->handle, wait), 0);
@@ -276,6 +296,8 @@ static void test_wait(int fd, unsigned int flags, unsigned
int wait)
igt_require(i915_reset_control(true));
trigger_reset(fd);
+
+ gem_context_destroy(fd, ctx);
}
static void test_suspend(int fd, int state)
@@ -309,6 +331,7 @@ static void test_inflight(int fd, unsigned int wait)
for_each_engine(fd, engine) {
struct drm_i915_gem_execbuffer2 execbuf;
+ uint32_t ctx = context_create_safe(fd);
igt_spin_t *hang;
int fence[64]; /* conservative estimate of ring size */
@@ -316,7 +339,7 @@ static void test_inflight(int fd, unsigned int wait)
igt_debug("Starting %s on engine '%s'\n", __func__, e__->name);
igt_require(i915_reset_control(false));
- hang = spin_sync(fd, 0, engine);
+ hang = spin_sync(fd, ctx, engine);
obj[0].handle = hang->handle;
memset(&execbuf, 0, sizeof(execbuf));
@@ -340,6 +363,8 @@ static void test_inflight(int fd, unsigned int wait)
igt_spin_batch_free(fd, hang);
igt_assert(i915_reset_control(true));
trigger_reset(fd);
+
+ gem_context_destroy(fd, ctx);
}
}
@@ -350,17 +375,20 @@ static void test_inflight_suspend(int fd)
uint32_t bbe = MI_BATCH_BUFFER_END;
int fence[64]; /* conservative estimate of ring size */
igt_spin_t *hang;
+ uint32_t ctx;
igt_require_gem(fd);
igt_require(gem_has_exec_fence(fd));
igt_require(i915_reset_control(false));
+ ctx = context_create_safe(fd);
+
memset(obj, 0, sizeof(obj));
obj[0].flags = EXEC_OBJECT_WRITE;
obj[1].handle = gem_create(fd, 4096);
gem_write(fd, obj[1].handle, 0, &bbe, sizeof(bbe));
- hang = spin_sync(fd, 0, 0);
+ hang = spin_sync(fd, ctx, 0);
obj[0].handle = hang->handle;
memset(&execbuf, 0, sizeof(execbuf));
@@ -387,23 +415,8 @@ static void test_inflight_suspend(int fd)
igt_spin_batch_free(fd, hang);
igt_assert(i915_reset_control(true));
trigger_reset(fd);
-}
-
-static uint32_t context_create_safe(int i915)
-{
- struct drm_i915_gem_context_param param;
-
- memset(¶m, 0, sizeof(param));
- param.ctx_id = gem_context_create(i915);
- param.param = I915_CONTEXT_PARAM_BANNABLE;
- gem_context_set_param(i915, ¶m);
-
- param.param = I915_CONTEXT_PARAM_NO_ERROR_CAPTURE;
- param.value = 1;
- gem_context_set_param(i915, ¶m);
-
- return param.ctx_id;
+ gem_context_destroy(fd, ctx);
}
static void test_inflight_contexts(int fd, unsigned int wait)
@@ -411,40 +424,40 @@ static void test_inflight_contexts(int fd, unsigned int
wait)
struct drm_i915_gem_exec_object2 obj[2];
const uint32_t bbe = MI_BATCH_BUFFER_END;
unsigned int engine;
- uint32_t ctx[64];
+ uint32_t ctx[65];
igt_require_gem(fd);
igt_require(gem_has_exec_fence(fd));
gem_require_contexts(fd);
- for (unsigned
Re: [Intel-gfx] [PATCH 1/2] drm/simple-kms-helper: Plumb plane state to the enable hook
On 03/27/2018 05:07 AM, Ville Syrjälä wrote: On Sat, Mar 24, 2018 at 12:26:32PM -0500, David Lechner wrote: On 03/22/2018 03:27 PM, Ville Syrjala wrote: From: Ville Syrjälä We'll need access to the plane state during .atomic_enable(). Some more details in the commit message would be useful. It is not clear to me why this change is being made. "tinydrm enable hook wants to play around with the new fb in .atomic_enable(), thus we'll need access to the plane state." Better? Worse? Better. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915/icl: Add reset control register changes
On 3/16/2018 1:28 PM, Daniele Ceraolo Spurio wrote:
On 16/03/18 05:14, Mika Kuoppala wrote:
From: Michel Thierry
The bits used to reset the different engines/domains have changed in
GEN11, this patch maps the reset engine mask bits with the new bits
in the reset control register.
v2: Use shift-left instead of BIT macro to match the file style (Paulo).
v3: Reuse gen8_reset_engines (Daniele).
v4: Do not call intel_uncore_forcewake_reset after reset, we may be
using the forcewake to read protected registers elsewhere and those
results may be clobbered by the concurrent dropping of forcewake.
bspec: 19212
Cc: Oscar Mateo
Cc: Antonio Argenziano
Cc: Paulo Zanoni
Cc: Daniele Ceraolo Spurio
Acked-by: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_reg.h | 11
drivers/gpu/drm/i915/intel_uncore.c | 53
+++--
2 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 9eaaa96287ec..f3cc77690124 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -301,6 +301,17 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
reg)
#define GEN6_GRDOM_VECS (1 << 4)
#define GEN9_GRDOM_GUC (1 << 5)
#define GEN8_GRDOM_MEDIA2 (1 << 7)
+/* GEN11 changed all bit defs except for FULL & RENDER */
+#define GEN11_GRDOM_FULL GEN6_GRDOM_FULL
+#define GEN11_GRDOM_RENDER GEN6_GRDOM_RENDER
+#define GEN11_GRDOM_BLT (1 << 2)
+#define GEN11_GRDOM_GUC (1 << 3)
+#define GEN11_GRDOM_MEDIA (1 << 5)
+#define GEN11_GRDOM_MEDIA2 (1 << 6)
+#define GEN11_GRDOM_MEDIA3 (1 << 7)
+#define GEN11_GRDOM_MEDIA4 (1 << 8)
+#define GEN11_GRDOM_VECS (1 << 13)
+#define GEN11_GRDOM_VECS2 (1 << 14)
#define RING_PP_DIR_BASE(engine) _MMIO((engine)->mmio_base+0x228)
#define RING_PP_DIR_BASE_READ(engine)
_MMIO((engine)->mmio_base+0x518)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 4c616d074a97..cabbf0e682e7 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1909,6 +1909,50 @@ static int gen6_reset_engines(struct
drm_i915_private *dev_priv,
return gen6_hw_domain_reset(dev_priv, hw_mask);
}
+/**
+ * gen11_reset_engines - reset individual engines
+ * @dev_priv: i915 device
+ * @engine_mask: mask of intel_ring_flag() engines or ALL_ENGINES for
full reset
+ *
+ * This function will reset the individual engines that are set in
engine_mask.
+ * If you provide ALL_ENGINES as mask, full global domain reset will
be issued.
+ *
+ * Note: It is responsibility of the caller to handle the difference
between
+ * asking full domain reset versus reset for all available individual
engines.
+ *
+ * Returns 0 on success, nonzero on error.
+ */
+static int gen11_reset_engines(struct drm_i915_private *dev_priv,
+ unsigned engine_mask)
+{
+ struct intel_engine_cs *engine;
+ const u32 hw_engine_mask[I915_NUM_ENGINES] = {
+ [RCS] = GEN11_GRDOM_RENDER,
+ [BCS] = GEN11_GRDOM_BLT,
+ [VCS] = GEN11_GRDOM_MEDIA,
+ [VCS2] = GEN11_GRDOM_MEDIA2,
+ [VCS3] = GEN11_GRDOM_MEDIA3,
+ [VCS4] = GEN11_GRDOM_MEDIA4,
+ [VECS] = GEN11_GRDOM_VECS,
+ [VECS2] = GEN11_GRDOM_VECS2,
+ };
Just a thought, but since this function is a copy of gen6_reset_engines
with the only difference being the array (GEN11_GRDOM_FULL is also the
same as GEN6_GRDOM_FULL), would it make sense to just add the array to
the gen6 function? e.g.:
There are more changes for gen11 coming (locking/unlocking the shared
SFC units), so I don't think it's a good idea to combine them.
const u32 gen6_hw_engine_mask[] = {
}
const u32 gen11_hw_engine_mask[] = {
}
const u32 *hw_engine_mask = INTEL_GEN(dev_priv) >= 11 ?
gen11_hw_engine_mask : gen6_hw_engine_mask;
My Ack still stands regardless and I also agree with renaming the
defines to be closer to the specs.
Daniele
+ u32 hw_mask;
+
+ BUILD_BUG_ON(VECS2 + 1 != I915_NUM_ENGINES);
+
+ if (engine_mask == ALL_ENGINES) {
+ hw_mask = GEN11_GRDOM_FULL;
+ } else {
+ unsigned int tmp;
+
+ hw_mask = 0;
+ for_each_engine_masked(engine, dev_priv, engine_mask, tmp)
+ hw_mask |= hw_engine_mask[engine->id];
+ }
+
+ return gen6_hw_domain_reset(dev_priv, hw_mask);
+}
+
/**
* __intel_wait_for_register_fw - wait until register matches
expected state
* @dev_priv: the i915 device
@@ -2056,7 +2100,10 @@ static int gen8_reset_engines(struct
drm_i915_private *dev_priv,
if (gen8_reset_engine_start(engine))
goto not_ready;
- return gen6_reset_engines(dev_priv, engine_mask);
+ if (INTEL_GEN(dev_priv) >= 11)
+ return gen11_reset_engines(d
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 3/26/2018 9:57 AM, Tvrtko Ursulin wrote:
On 26/03/2018 17:12, Yunwei Zhang wrote:
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any
MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all
cases
across slice/subslice. There are rare occasions such as INSTDONE that
this
value will be dependent on slice/subslice combo, in such cases, we
need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
Reference: HSD#1405586840 BSID#0575
v2:
- use fls() instead of find_last_bit() (Chris)
- added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
- rebase on latest tip
v4:
- Added references (Mika)
Signed-off-by: Yunwei Zhang
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 39
--
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..2db2a04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2297,6 +2297,7 @@ intel_info(const struct drm_i915_private
*dev_priv)
#define INTEL_GEN(dev_priv) ((dev_priv)->info.gen)
#define INTEL_DEVID(dev_priv) ((dev_priv)->info.device_id)
+#define INTEL_SSEU(dev_priv) ((dev_priv)->info.sseu)
If we add this someone gets the job of converting existing users?
This is suggestion from Chris Wilson, I am new here, but I guess if I am
going to do that, it is better in a separate patch. I will remove this
in next patchset and submit a new patch later.
#define REVID_FOREVER 0xff
#define INTEL_REVID(dev_priv) ((dev_priv)->drm.pdev->revision)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index de09fa4..cc19e0a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct
drm_i915_private *i915, int type)
}
}
+static u32 calculate_mcr(u32 mcr, struct drm_i915_private *dev_priv)
dev_priv first would be more typical function argument order.
+{
+ const struct sseu_dev_info *sseu = &(INTEL_SSEU(dev_priv));
+ u32 slice = fls(sseu->slice_mask);
+ u32 subslice = fls(sseu->subslice_mask[slice]);
+
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+ return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+ u32 mcr;
+
+ mcr = I915_READ(GEN8_MCR_SELECTOR);
+ mcr = calculate_mcr(mcr, dev_priv);
+ I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
static inline uint32_t
read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
int subslice, i915_reg_t reg)
@@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private
*dev_priv, int slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
* The HW expects the slice and sublice selectors to be reset to 0
* after reading out the registers.
*/
- WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+ if (INTEL_GEN(dev_priv) < 10)
+ WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
Can squash to single line WARN_ON_ONCE(INTEL_GEN() < 10 && (mcr &
...)), if it fits.
mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
ret = I915_READ_FW(reg);
- mcr &= ~mcr_slice_subslice_mask;
+ /*
+ * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+ * expects mcr to be programed to a enabled slice/subslice pair
+ * before any MMIO read into slice/subslice register
+ */
+ if (INTEL_GEN(dev_priv) < 10)
+ mcr &= ~mcr_slice_subslice_mask;
+ else
+ mcr = calculate_mcr(mcr, dev_priv);
Does it make sense to move the conditional and comment to
calculate_mcr - so here only a single call to it remains?
I am thinking maybe it is better to save jump/return for GENs that don't
have WA..
+
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
@@ -1307,6 +1339,9 @@ static int cnl_init_workarounds(struct
intel_engine_cs *engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
+ /* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */
+ wa_init_mcr(d
Re: [Intel-gfx] [PATCH 08/11] drm/i915/execlists: Force preemption via reset on timeout
On Mon, Mar 26, 2018 at 12:50:41PM +0100, Chris Wilson wrote:
> Install a timer when trying to preempt on behalf of an important
> context such that if the active context does not honour the preemption
> request within the desired timeout, then we reset the GPU to allow the
> important context to run.
>
> (Open: should not the timer be started from receiving the high priority
> request...)
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 53
> +
> drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +
> 2 files changed, 61 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 50688fc889d9..6da816d23cb3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -533,6 +533,47 @@ static void inject_preempt_context(struct
> intel_engine_cs *engine)
>
> execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
> execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
> +
> + /* Set a timer to force preemption vs hostile userspace */
> + if (execlists->queue_preempt_timeout) {
> + GEM_TRACE("%s timeout=%uns\n",
> + engine->name, execlists->queue_preempt_timeout);
> + hrtimer_start(&execlists->preempt_timer,
> + ktime_set(0, execlists->queue_preempt_timeout),
> + HRTIMER_MODE_REL);
> + }
> +}
> +
> +static enum hrtimer_restart preempt_timeout(struct hrtimer *hrtimer)
> +{
> + struct intel_engine_execlists *execlists =
> + container_of(hrtimer, typeof(*execlists), preempt_timer);
> +
> + GEM_TRACE("%s\n",
> + container_of(execlists,
> +struct intel_engine_cs,
> +execlists)->name);
> +
> + queue_work(system_highpri_wq, &execlists->preempt_reset);
> + return HRTIMER_NORESTART;
> +}
> +
> +static void preempt_reset(struct work_struct *work)
> +{
> + struct intel_engine_cs *engine =
> + container_of(work, typeof(*engine), execlists.preempt_reset);
> +
> + GEM_TRACE("%s\n", engine->name);
> +
> + tasklet_disable(&engine->execlists.tasklet);
> +
> + engine->execlists.tasklet.func(engine->execlists.tasklet.data);
This seems redundant with the execlists_reset_prepare already doing a
process_csb
at a later time to decide whether to execute or abort the reset. In your
previous proposal you suggested tasklet disable and kill here.
> +
> + if (execlists_is_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT))
> + i915_handle_error(engine->i915, BIT(engine->id), 0,
> + "preemption timed out on %s", engine->name);
> +
> + tasklet_enable(&engine->execlists.tasklet);
> }
>
> static void complete_preempt_context(struct intel_engine_execlists
> *execlists)
> @@ -542,6 +583,10 @@ static void complete_preempt_context(struct
> intel_engine_execlists *execlists)
> execlists_cancel_port_requests(execlists);
> execlists_unwind_incomplete_requests(execlists);
>
> + /* If the timer already fired, complete the reset */
> + if (hrtimer_try_to_cancel(&execlists->preempt_timer) < 0)
> + return;
> +
> execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
> }
>
> @@ -708,6 +753,7 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> kmem_cache_free(engine->i915->priorities, p);
> }
> done:
> + execlists->queue_preempt_timeout = 0; /* preemption point passed */
> execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
> execlists->first = rb;
> if (submit)
> @@ -864,6 +910,7 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
>
> /* Remaining _unready_ requests will be nop'ed when submitted */
>
> + execlists->queue_preempt_timeout = 0;
> execlists->queue_priority = INT_MIN;
> execlists->queue = RB_ROOT;
> execlists->first = NULL;
> @@ -1080,6 +1127,7 @@ static void queue_request(struct intel_engine_cs
> *engine,
> static void __submit_queue(struct intel_engine_cs *engine, int prio)
> {
> engine->execlists.queue_priority = prio;
> + engine->execlists.queue_preempt_timeout = 0;
> tasklet_hi_schedule(&engine->execlists.tasklet);
> }
>
> @@ -2270,6 +2318,11 @@ logical_ring_setup(struct intel_engine_cs *engine)
> tasklet_init(&engine->execlists.tasklet,
>execlists_submission_tasklet, (unsigned long)engine);
>
> + INIT_WORK(&engine->execlists.preempt_reset, preempt_reset);
> + hrtimer_init(&engine->execlists.preempt_timer,
> + CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + engine->execlists.preempt_timer.function = preempt_timeout;
> +
> logical_ring_default_vfuncs(engine);
> logical_ring_default_i
Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_ctx_isolation: Reset a scratch context
Quoting Tvrtko Ursulin (2018-03-27 16:41:14) > > [resend for typo in cc] The small advantage in redundancy, I guess. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/i915/execlists: Force preemption via reset on timeout
On Tue, Mar 27, 2018 at 09:51:20AM +0100, Tvrtko Ursulin wrote:
>
> On 26/03/2018 12:50, Chris Wilson wrote:
> >Install a timer when trying to preempt on behalf of an important
> >context such that if the active context does not honour the preemption
> >request within the desired timeout, then we reset the GPU to allow the
> >important context to run.
>
> I suggest renaming patch title to "Implement optional preemption
> delay timeout", or "upper bound", or something, as long as it is not
> "force preemption". :)
>
> >(Open: should not the timer be started from receiving the high priority
> >request...)
>
> If you think receiving as in execbuf I think not - that would be
> something else and not preempt timeout.
>
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/intel_lrc.c| 53
> > +
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +
> > 2 files changed, 61 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 50688fc889d9..6da816d23cb3 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -533,6 +533,47 @@ static void inject_preempt_context(struct
> >intel_engine_cs *engine)
> > execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
> > execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
> >+
> >+/* Set a timer to force preemption vs hostile userspace */
> >+if (execlists->queue_preempt_timeout) {
> >+GEM_TRACE("%s timeout=%uns\n",
>
> preempt-timeout ?
>
> >+ engine->name, execlists->queue_preempt_timeout);
> >+hrtimer_start(&execlists->preempt_timer,
> >+ ktime_set(0, execlists->queue_preempt_timeout),
> >+ HRTIMER_MODE_REL);
> >+}
> >+}
> >+
> >+static enum hrtimer_restart preempt_timeout(struct hrtimer *hrtimer)
> >+{
> >+struct intel_engine_execlists *execlists =
> >+container_of(hrtimer, typeof(*execlists), preempt_timer);
> >+
> >+GEM_TRACE("%s\n",
> >+ container_of(execlists,
> >+ struct intel_engine_cs,
> >+ execlists)->name);
> >+
> >+queue_work(system_highpri_wq, &execlists->preempt_reset);
>
> I suppose indirection from hrtimer to worker is for better than
> jiffie timeout granularity? But then queue_work might introduce some
> delay to defeat that.
>
> I am wondering if simply schedule_delayed_work directly wouldn't be
> good enough. I suppose it is a question for the product group. But
> it is also implementation detail.
>
I started with schedule_delayed_work in my implementation hoping for
at least consistent msec accuracy, but it was all over the place.
We need msec granularity for the automotive use cases.
-Jeff
> >+return HRTIMER_NORESTART;
> >+}
> >+
> >+static void preempt_reset(struct work_struct *work)
> >+{
> >+struct intel_engine_cs *engine =
> >+container_of(work, typeof(*engine), execlists.preempt_reset);
> >+
> >+GEM_TRACE("%s\n", engine->name);
> >+
> >+tasklet_disable(&engine->execlists.tasklet);
> >+
> >+engine->execlists.tasklet.func(engine->execlists.tasklet.data);
>
> Comment on why calling the tasklet directly.
>
> >+
> >+if (execlists_is_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT))
> >+i915_handle_error(engine->i915, BIT(engine->id), 0,
> >+ "preemption timed out on %s", engine->name);
>
> Can this race with the normal reset and we end up wit
> i915_handle_error twice simultaneously?
>
> >+
> >+tasklet_enable(&engine->execlists.tasklet);
> > }
> > static void complete_preempt_context(struct intel_engine_execlists
> > *execlists)
> >@@ -542,6 +583,10 @@ static void complete_preempt_context(struct
> >intel_engine_execlists *execlists)
> > execlists_cancel_port_requests(execlists);
> > execlists_unwind_incomplete_requests(execlists);
> >+/* If the timer already fired, complete the reset */
> >+if (hrtimer_try_to_cancel(&execlists->preempt_timer) < 0)
> >+return;
>
> What about timer which had already fired and queued the worker?
> hrtimer_try_to_cancel will return zero for that case I think.
>
> >+
> > execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
> > }
> >@@ -708,6 +753,7 @@ static void execlists_dequeue(struct intel_engine_cs
> >*engine)
> > kmem_cache_free(engine->i915->priorities, p);
> > }
> > done:
> >+execlists->queue_preempt_timeout = 0; /* preemption point passed */
> > execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
> > execlists->first = rb;
> > if (submit)
> >@@ -864,6 +910,7 @@ static void execlists_cancel_requests(struct
> >intel_engine_cs *engine)
> > /* Remaining _unready_ requests will be nop'ed when submitted */
> >+execlists->queue_preempt_timeout = 0;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Preempt-to-idle support in execlists.
== Series Details == Series: drm/i915/gen11: Preempt-to-idle support in execlists. URL : https://patchwork.freedesktop.org/series/40747/ State : success == Summary == Series 40747v1 drm/i915/gen11: Preempt-to-idle support in execlists. https://patchwork.freedesktop.org/api/1.0/series/40747/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-cnl-y3) fdo#104951 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:451s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:383s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:547s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:302s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:514s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:515s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:529s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:514s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:411s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:573s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:515s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:594s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:430s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:326s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:421s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:476s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:434s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:479s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:471s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:521s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:660s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:456s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:508s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:449s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:584s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:403s Blacklisted hosts: fi-cnl-psr total:285 pass:255 dwarn:3 dfail:0 fail:1 skip:26 time:534s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:495s ff7820832182a0f4bebf9092a74ab17f8b3ae7ef drm-tip: 2018y-03m-27d-14h-31m-00s UTC integration manifest 96268839cd00 drm/i915/gen11: Preempt-to-idle support in execlists. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8505/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Flush pending preemption events during reset
On Tue, Mar 27, 2018 at 12:44:02PM +0100, Chris Wilson wrote:
> Catch up with the inflight CSB events, after disabling the tasklet
> before deciding which request was truly guilty of hanging the GPU.
>
> v2: Restore checking of use_csb_mmio on every loop, don't forget old
> vgpu.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
> CC: Michel Thierry
> Cc: Jeff McGee
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 127
> +++
> 1 file changed, 87 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index cf31b0749023..75dbdedde8b0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -874,34 +874,14 @@ static void execlists_cancel_requests(struct
> intel_engine_cs *engine)
> local_irq_restore(flags);
> }
>
> -/*
> - * Check the unread Context Status Buffers and manage the submission of new
> - * contexts to the ELSP accordingly.
> - */
> -static void execlists_submission_tasklet(unsigned long data)
> +static void process_csb(struct intel_engine_cs *engine)
> {
> - struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
> struct intel_engine_execlists * const execlists = &engine->execlists;
> struct execlist_port * const port = execlists->port;
> - struct drm_i915_private *dev_priv = engine->i915;
> + struct drm_i915_private *i915 = engine->i915;
> bool fw = false;
>
> - /*
> - * We can skip acquiring intel_runtime_pm_get() here as it was taken
> - * on our behalf by the request (see i915_gem_mark_busy()) and it will
> - * not be relinquished until the device is idle (see
> - * i915_gem_idle_work_handler()). As a precaution, we make sure
> - * that all ELSP are drained i.e. we have processed the CSB,
> - * before allowing ourselves to idle and calling intel_runtime_pm_put().
> - */
> - GEM_BUG_ON(!dev_priv->gt.awake);
> -
> - /*
> - * Prefer doing test_and_clear_bit() as a two stage operation to avoid
> - * imposing the cost of a locked atomic transaction when submitting a
> - * new request (outside of the context-switch interrupt).
> - */
> - while (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted)) {
> + do {
Wouldn't it be simpler for process_csb to use a while loop here, and for
callers that need a CSB processing point to just call it without themselves
checking irq_posted? Are we really saving much with the if-do-while approach?
> /* The HWSP contains a (cacheable) mirror of the CSB */
> const u32 *buf =
> &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> @@ -909,28 +889,27 @@ static void execlists_submission_tasklet(unsigned long
> data)
>
> if (unlikely(execlists->csb_use_mmio)) {
> buf = (u32 * __force)
> - (dev_priv->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> - execlists->csb_head = -1; /* force mmio read of CSB
> ptrs */
> + (i915->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> + execlists->csb_head = -1; /* force mmio read of CSB */
> }
>
> /* Clear before reading to catch new interrupts */
> clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> smp_mb__after_atomic();
>
> - if (unlikely(execlists->csb_head == -1)) { /* following a reset
> */
> + if (unlikely(execlists->csb_head == -1)) { /* after a reset */
> if (!fw) {
> - intel_uncore_forcewake_get(dev_priv,
> -
> execlists->fw_domains);
> + intel_uncore_forcewake_get(i915,
> execlists->fw_domains);
> fw = true;
> }
>
> - head = readl(dev_priv->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
> + head = readl(i915->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
> tail = GEN8_CSB_WRITE_PTR(head);
> head = GEN8_CSB_READ_PTR(head);
> execlists->csb_head = head;
> } else {
> const int write_idx =
> - intel_hws_csb_write_index(dev_priv) -
> + intel_hws_csb_write_index(i915) -
> I915_HWS_CSB_BUF0_INDEX;
>
> head = execlists->csb_head;
> @@ -938,8 +917,8 @@ static void execlists_submission_tasklet(unsigned long
> data)
> }
> GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
> engine->name,
> -
Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_ctx_isolation: Reset a scratch context
[resend for typo in cc]
On 27/03/2018 14:59, Chris Wilson wrote:
Quoting Chris Wilson (2018-03-27 14:52:20)
Quoting Chris Wilson (2018-03-27 14:48:43)
If we inject a reset into the target context, there is a risk that the
register state is never saved back to memory. The exact interaction
between reset, the context image and the precise timing of our execution
are not well defined. Since we cannot ensure that the context image
remains valid, force a context switch prior to the reset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105270
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105457
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105545
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
tests/gem_ctx_isolation.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
index d8109aa0..4968e367 100644
--- a/tests/gem_ctx_isolation.c
+++ b/tests/gem_ctx_isolation.c
@@ -522,6 +522,32 @@ static void isolation(int fd,
#define S4 (4 << 8)
#define SLEEP_MASK (0xf << 8)
+static void inject_reset_context(int fd, unsigned int engine)
+{
+ igt_spin_t *spin;
+ uint32_t ctx;
+
+ /*
+* Force a context switch before triggering the reset, or else
+* we risk corrupting the target context and we can't blame the
+* HW for screwing up if the context was already broken.
+*/
+
+ ctx = gem_context_create(fd);
+ if (gem_can_store_dword(fd, engine)) {
+ spin = __igt_spin_batch_new_poll(fd, ctx, engine);
+ igt_spin_busywait_until_running(spin);
+ } else {
+ spin = __igt_spin_batch_new(fd, ctx, engine, 0);
+ usleep(1000); /* better than nothing */
+ }
Tvrtko, maybe we want igt_spin_batch_run()? Not sure though, so far we
have an example where you need precise control and a couple of examples
where we just want a running spinner.
I wasn't sure it is in good taste to put a thing with that usleep in
lib/, since it incurs a delay to unsuspecting callers. And I couldn't
decide how to handle it better - skip from lib/? Not so great. Return
value and make callers handle it - even more cumbersome.
It only affects old gens, but do we want tests there suddenly take much
longer because someone spotted a cool new API and went to use it?
But it is a third user now so not great to copy paste it all around. I
don't know. Make the lib functions skip where unsupported and add double
underscore prefix flavour which sleeps where not supported?
Also this whole function might want to make its way into lib/i915 as the
basis of all hang/reset injection. Some improvement required to set
context parameters (e.g. disabling error state capturing) and skipping
if no reset is available or disabled (although that's the job for the
fixture, so may not be required for the library function). I'm sure
someone will catch me reusing this chunk over and over again...
Sounds OK to me.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_ctx_isolation: Reset a scratch context
[resend for typo in cc]
On 27/03/2018 14:48, Chris Wilson wrote:
If we inject a reset into the target context, there is a risk that the
register state is never saved back to memory. The exact interaction
between reset, the context image and the precise timing of our execution
are not well defined. Since we cannot ensure that the context image
remains valid, force a context switch prior to the reset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105270
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105457
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105545
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
tests/gem_ctx_isolation.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
index d8109aa0..4968e367 100644
--- a/tests/gem_ctx_isolation.c
+++ b/tests/gem_ctx_isolation.c
@@ -522,6 +522,32 @@ static void isolation(int fd,
#define S4 (4 << 8)
#define SLEEP_MASK (0xf << 8)
+static void inject_reset_context(int fd, unsigned int engine)
+{
+ igt_spin_t *spin;
+ uint32_t ctx;
+
+ /*
+* Force a context switch before triggering the reset, or else
+* we risk corrupting the target context and we can't blame the
+* HW for screwing up if the context was already broken.
+*/
+
+ ctx = gem_context_create(fd);
+ if (gem_can_store_dword(fd, engine)) {
+ spin = __igt_spin_batch_new_poll(fd, ctx, engine);
+ igt_spin_busywait_until_running(spin);
+ } else {
+ spin = __igt_spin_batch_new(fd, ctx, engine, 0);
+ usleep(1000); /* better than nothing */
+ }
+
+ igt_force_gpu_reset(fd);
+
+ igt_spin_batch_free(fd, spin);
+ gem_context_destroy(fd, ctx);
+}
+
static void preservation(int fd,
const struct intel_execution_engine2 *e,
unsigned int flags)
@@ -558,7 +584,7 @@ static void preservation(int fd,
igt_spin_batch_free(fd, spin);
if (flags & RESET)
- igt_force_gpu_reset(fd);
+ inject_reset_context(fd, engine);
switch (flags & SLEEP_MASK) {
case NOSLEEP:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gen11: Preempt-to-idle support in execlists.
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists.
URL : https://patchwork.freedesktop.org/series/40747/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
96268839cd00 drm/i915/gen11: Preempt-to-idle support in execlists.
-:97: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"execlists->ctrl_reg"
#97: FILE: drivers/gpu/drm/i915/intel_lrc.c:551:
+ GEM_BUG_ON(execlists->ctrl_reg != NULL);
-:149: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#149: FILE: drivers/gpu/drm/i915/intel_lrc.c:1013:
+ buf[2*head + 1] ==
execlists->preempt_complete_status)) {
^
total: 0 errors, 0 warnings, 2 checks, 114 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling (rev2)
== Series Details == Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling (rev2) URL : https://patchwork.freedesktop.org/series/40665/ State : failure == Summary == Possible new issues: Test gem_ctx_param: Subgroup invalid-param-get: pass -> FAIL (shard-apl) pass -> FAIL (shard-hsw) pass -> FAIL (shard-snb) Subgroup invalid-param-set: pass -> FAIL (shard-apl) pass -> FAIL (shard-hsw) pass -> FAIL (shard-snb) Test kms_cursor_legacy: Subgroup flip-vs-cursor-crc-atomic: fail -> PASS (shard-hsw) Subgroup short-flip-before-cursor-atomic-transitions: skip -> PASS (shard-snb) Known issues: Test kms_flip: Subgroup 2x-plain-flip-fb-recreate: fail -> PASS (shard-hsw) fdo#100368 Subgroup flip-vs-expired-vblank: fail -> PASS (shard-hsw) fdo#102887 +1 Subgroup modeset-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 +2 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-apltotal:3495 pass:1830 dwarn:1 dfail:0 fail:9 skip:1655 time:12892s shard-hswtotal:3495 pass:1778 dwarn:1 dfail:0 fail:6 skip:1709 time:11628s shard-snbtotal:3495 pass:1372 dwarn:1 dfail:0 fail:5 skip:2117 time:6987s Blacklisted hosts: shard-kbltotal:3495 pass:1951 dwarn:1 dfail:0 fail:13 skip:1530 time:9722s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8503/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.
Preemption in previous gens required a special batch buffer to be executed,
so the Command Streamer never preempted to idle directly. In Icelake it is
possible, as there is a hardware mechanism to inform the kernel about
status of the preemption request.
This patch does not cover using the new preemption mechanism when GuC is
active.
Bspec: 18922
Signed-off-by: Tomasz Lis
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 45 +++-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
5 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 800230b..c32580b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2514,6 +2514,8 @@ intel_info(const struct drm_i915_private *dev_priv)
((dev_priv)->info.has_logical_ring_elsq)
#define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+ ((dev_priv)->info.has_hw_preempt_to_idle)
#define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4364922..66b6700 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -595,7 +595,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .has_hw_preempt_to_idle = 1
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 933e316..4eb97b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -98,6 +98,7 @@ enum intel_platform {
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
+ func(has_hw_preempt_to_idle); \
func(has_overlay); \
func(has_pooled_eu); \
func(has_psr); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ba7f783..1a22de4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -153,6 +153,7 @@
#define GEN8_CTX_STATUS_ACTIVE_IDLE(1 << 3)
#define GEN8_CTX_STATUS_COMPLETE (1 << 4)
#define GEN8_CTX_STATUS_LITE_RESTORE (1 << 15)
+#define GEN11_CTX_STATUS_PREEMPT_IDLE (1 << 29)
#define GEN8_CTX_STATUS_COMPLETED_MASK \
(GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
@@ -183,7 +184,9 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
const struct i915_request *last,
int prio)
{
- return engine->i915->preempt_context && prio > max(rq_prio(last), 0);
+ return (engine->i915->preempt_context ||
+ HAS_HW_PREEMPT_TO_IDLE(engine->i915)) &&
+prio > max(rq_prio(last), 0);
}
/**
@@ -535,6 +538,25 @@ static void inject_preempt_context(struct intel_engine_cs
*engine)
execlists_set_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT);
}
+static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *execlists = &engine->execlists;
+
+ GEM_TRACE("%s\n", engine->name);
+
+ /*
+* hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
+* HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
+*/
+ GEM_BUG_ON(execlists->ctrl_reg != NULL);
+
+ /* trigger preemption to idle */
+ writel(EL_CTRL_PREEMPT_TO_IDLE, execlists->ctrl_reg);
+
+ execlists_clear_active(execlists, EXECLISTS_ACTIVE_HWACK);
+ execlists_set_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
+}
+
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -594,7 +616,10 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
goto unlock;
if (need_preempt(engine, last, execlists->queue_priority)) {
- inject_preempt_context(engine);
+ if (HAS_HW_PREEMPT_TO_IDLE(engine->i915))
+ gen11_preempt_to_idle(engine);
+ else
+ inject_preempt_context(engine);
goto unlock;
}
@@ -962,10 +9
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave, Two human-reported bugs to close for display and a more rare fix that could result in GPU hang. There was some unclarity about the GVT pull, so I'm not including it here. Happy Easter holidays! Regards, Joonas drm-intel-next-fixes-2018-03-27: - Display fixes for booting with MST hub lid closed and display freezing after hibernation (fd.o bugs 105470 & 105196) - Fix for a very rare interrupt handling race resulting in GPU hang The following changes since commit 33d009cd889490838c5db9b9339856c9e3d3facc: Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-03-26 10:01:11 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2018-03-27 for you to fetch changes up to 300efa9eea451bdcf3b5a1eb29e06e85bb2c: drm/i915: Fix hibernation with ACPI S0 target state (2018-03-27 11:20:06 +0300) - Display fixes for booting with MST hub lid closed and display freezing after hibernation (fd.o bugs 105470 & 105196) - Fix for a very rare interrupt handling race resulting in GPU hang Chris Wilson (2): drm/i915: Specify which engines to reset following semaphore/event lockups drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt Dhinakaran Pandiyan (1): drm/i915/dp: Write to SET_POWER dpcd to enable MST hub. Imre Deak (1): drm/i915: Fix hibernation with ACPI S0 target state drivers/gpu/drm/i915/i915_drv.c| 22 ++ drivers/gpu/drm/i915/i915_drv.h| 2 +- drivers/gpu/drm/i915/intel_ddi.c | 7 ++- drivers/gpu/drm/i915/intel_hangcheck.c | 4 ++-- drivers/gpu/drm/i915/intel_lrc.c | 21 - 5 files changed, 23 insertions(+), 33 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] overlay: Call setlocale around strtod
On 27/03/2018 15:28, Chris Wilson wrote:
strtod() is locale-dependent. The decimal conversion depends on the radix
character ('.' for some of us like myself) varies by locale. As the
kernel reports its values using the "C" locale, we need to switch to
that when parsing; and switch back before reporting to the user.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105712
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
overlay/power.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/overlay/power.c b/overlay/power.c
index 9ac90fde..0f99e2a4 100644
--- a/overlay/power.c
+++ b/overlay/power.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include "igt_perf.h"
@@ -97,12 +98,18 @@ static uint64_t rapl_gpu_power(void)
static double filename_to_double(const char *filename)
{
- char buf[64];
+ char *oldlocale;
+ char buf[80];
+ double v;
if (filename_to_buf(filename, buf, sizeof(buf)))
return 0;
- return strtod(buf, NULL);
+ oldlocale = setlocale(LC_ALL, "C");
+ v = strtod(buf, NULL);
+ setlocale(LC_ALL, oldlocale);
+
+ return v;
}
static double rapl_gpu_power_scale(void)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17
Quoting Joonas Lahtinen (2018-03-27 16:42:28) > Quoting Zhenyu Wang (2018-03-27 11:39:42) > > > > Hi, Joonas > > > > Here's this week's gvt-next-fixes queued for 4.17. One notable change > > is to revert previous workaround for gvt context preemption, now it > > has full support for preemption now. > > I've pulled the patches, but this revert sounds fishy. Is it something > that should have been done together with a commit in a batch introduced > to 4.17? To me, this sounds much like a feature patch, "enable > pre-emption on GVT context" is even written in the tag. > > So I'm inclined to drop this patch from -fixes pull. On a second thought, I'll drop the whole pull to make it less of a hassle with rebases. Please send and updated pull with just the fix patches. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
Quoting Tvrtko Ursulin (2018-03-26 17:57:38) > > On 26/03/2018 17:12, Yunwei Zhang wrote: > > --- > > drivers/gpu/drm/i915/i915_drv.h| 1 + > > drivers/gpu/drm/i915/intel_engine_cs.c | 39 > > -- > > 2 files changed, 38 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index 800230b..2db2a04 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -2297,6 +2297,7 @@ intel_info(const struct drm_i915_private *dev_priv) > > > > #define INTEL_GEN(dev_priv) ((dev_priv)->info.gen) > > #define INTEL_DEVID(dev_priv) ((dev_priv)->info.device_id) > > +#define INTEL_SSEU(dev_priv) ((dev_priv)->info.sseu) > > If we add this someone gets the job of converting existing users? My bad, I hadn't realised that the INTEL_SSEU conversion was local to my tree. It must have fallen out as part of the static device_info reform. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] overlay: Call setlocale around strtod
strtod() is locale-dependent. The decimal conversion depends on the radix
character ('.' for some of us like myself) varies by locale. As the
kernel reports its values using the "C" locale, we need to switch to
that when parsing; and switch back before reporting to the user.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105712
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
overlay/power.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/overlay/power.c b/overlay/power.c
index 9ac90fde..0f99e2a4 100644
--- a/overlay/power.c
+++ b/overlay/power.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include "igt_perf.h"
@@ -97,12 +98,18 @@ static uint64_t rapl_gpu_power(void)
static double filename_to_double(const char *filename)
{
- char buf[64];
+ char *oldlocale;
+ char buf[80];
+ double v;
if (filename_to_buf(filename, buf, sizeof(buf)))
return 0;
- return strtod(buf, NULL);
+ oldlocale = setlocale(LC_ALL, "C");
+ v = strtod(buf, NULL);
+ setlocale(LC_ALL, oldlocale);
+
+ return v;
}
static double rapl_gpu_power_scale(void)
--
2.16.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
Yunwei Zhang writes:
> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> read into Slice/Subslice specific registers, MCR packet control
> register(0xFDC) needs to be programmed to point to any enabled
> slice/subslice pair. Otherwise, incorrect value will be returned.
>
> However, that means each subsequent MMIO read will be forwarded to a
> specific slice/subslice combination as read is unicast. This is OK since
> slice/subslice specific register values are consistent in almost all cases
> across slice/subslice. There are rare occasions such as INSTDONE that this
> value will be dependent on slice/subslice combo, in such cases, we need to
> program 0xFDC and recover this after. This is already covered by
> read_subslice_reg.
>
> Also, 0xFDC will lose its information after TDR/engine reset/power state
> change.
>
> Reference: HSD#1405586840 BSID#0575
Use plural, and add comma in between.
Move 'References' right before Cc:s after the version log...
>
> v2:
> - use fls() instead of find_last_bit() (Chris)
> - added INTEL_SSEU to extract sseu from device info. (Chris)
> v3:
> - rebase on latest tip
> v4:
> - Added references (Mika)
>
.. in here.
And we usually do put Cc:s before s-o-b.
For example, see commit 465418c6064c88d4af555abe0480c417eb47eae3
Thanks,
-Mika
> Signed-off-by: Yunwei Zhang
> Cc: Oscar Mateo
> Cc: Michel Thierry
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/intel_engine_cs.c | 39
> --
> 2 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 800230b..2db2a04 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2297,6 +2297,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>
> #define INTEL_GEN(dev_priv) ((dev_priv)->info.gen)
> #define INTEL_DEVID(dev_priv)((dev_priv)->info.device_id)
> +#define INTEL_SSEU(dev_priv) ((dev_priv)->info.sseu)
>
> #define REVID_FOREVER0xff
> #define INTEL_REVID(dev_priv)((dev_priv)->drm.pdev->revision)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index de09fa4..cc19e0a 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private
> *i915, int type)
> }
> }
>
> +static u32 calculate_mcr(u32 mcr, struct drm_i915_private *dev_priv)
> +{
> + const struct sseu_dev_info *sseu = &(INTEL_SSEU(dev_priv));
> + u32 slice = fls(sseu->slice_mask);
> + u32 subslice = fls(sseu->subslice_mask[slice]);
> +
> + mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
> + mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
> +
> + return mcr;
> +}
> +
> +static void wa_init_mcr(struct drm_i915_private *dev_priv)
> +{
> + u32 mcr;
> +
> + mcr = I915_READ(GEN8_MCR_SELECTOR);
> + mcr = calculate_mcr(mcr, dev_priv);
> + I915_WRITE(GEN8_MCR_SELECTOR, mcr);
> +}
> +
> static inline uint32_t
> read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
> int subslice, i915_reg_t reg)
> @@ -828,18 +849,29 @@ read_subslice_reg(struct drm_i915_private *dev_priv,
> int slice,
> intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
>
> mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
> +
> /*
>* The HW expects the slice and sublice selectors to be reset to 0
>* after reading out the registers.
>*/
> - WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> + if (INTEL_GEN(dev_priv) < 10)
> + WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
> mcr &= ~mcr_slice_subslice_mask;
> mcr |= mcr_slice_subslice_select;
> I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>
> ret = I915_READ_FW(reg);
>
> - mcr &= ~mcr_slice_subslice_mask;
> + /*
> + * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
> + * expects mcr to be programed to a enabled slice/subslice pair
> + * before any MMIO read into slice/subslice register
> + */
> + if (INTEL_GEN(dev_priv) < 10)
> + mcr &= ~mcr_slice_subslice_mask;
> + else
> + mcr = calculate_mcr(mcr, dev_priv);
> +
> I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
>
> intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
> @@ -1307,6 +1339,9 @@ static int cnl_init_workarounds(struct intel_engine_cs
> *engine)
> struct drm_i915_private *dev_priv = engine->i915;
> int ret;
>
> + /* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */
> + wa_init_mcr(dev_priv);
> +
> /* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
> if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
> I915_WRITE(GAMT_CHKN_BIT_REG,
>
[Intel-gfx] ✓ Fi.CI.IGT: success for trace: Default to using trace_global_clock if sched_clock is unstable
== Series Details == Series: trace: Default to using trace_global_clock if sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40728/ State : success == Summary == Known issues: Test kms_cursor_legacy: Subgroup flip-vs-cursor-atomic: pass -> FAIL (shard-hsw) fdo#102670 Test kms_flip: Subgroup 2x-flip-vs-wf_vblank-interruptible: fail -> PASS (shard-hsw) fdo#100368 Subgroup flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-cur-indfb-draw-blt: pass -> FAIL (shard-apl) fdo#103167 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 shard-apltotal:3495 pass:1830 dwarn:1 dfail:0 fail:8 skip:1655 time:12877s shard-hswtotal:3495 pass:1781 dwarn:1 dfail:0 fail:3 skip:1709 time:11675s shard-snbtotal:3495 pass:1374 dwarn:1 dfail:0 fail:3 skip:2117 time:7068s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8500/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Documentation patch for batchbuffer submission (rev3)
== Series Details == Series: Documentation patch for batchbuffer submission (rev3) URL : https://patchwork.freedesktop.org/series/38433/ State : failure == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc: pass -> FAIL (shard-apl) Known issues: Test drv_selftest: Subgroup live_gtt: pass -> INCOMPLETE (shard-apl) fdo#103927 Test kms_flip: Subgroup 2x-flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 Subgroup 2x-flip-vs-wf_vblank-interruptible: fail -> PASS (shard-hsw) fdo#100368 +2 Subgroup dpms-vs-vblank-race: pass -> FAIL (shard-apl) fdo#103060 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 shard-apltotal:3473 pass:1806 dwarn:1 dfail:0 fail:9 skip:1655 time:12404s shard-hswtotal:3495 pass:1780 dwarn:1 dfail:0 fail:4 skip:1709 time:11507s shard-snbtotal:3495 pass:1374 dwarn:1 dfail:0 fail:3 skip:2117 time:6994s Blacklisted hosts: shard-kbltotal:3495 pass:1956 dwarn:1 dfail:0 fail:9 skip:1529 time:9707s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8499/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
