[Intel-gfx] ✗ Fi.CI.IGT: failure for Load Guc and huC on Geminilake
== Series Details == Series: Load Guc and huC on Geminilake URL : https://patchwork.freedesktop.org/series/43669/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4227_full -> Patchwork_9101_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9101_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9101_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43669/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9101_full: === IGT changes === Possible regressions igt@debugfs_test@read_all_entries: shard-glk: PASS -> DMESG-WARN +2 igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL +1 shard-apl: PASS -> DMESG-FAIL +1 igt@perf@gen8-unprivileged-single-ctx-counters: shard-apl: PASS -> FAIL shard-glk: PASS -> FAIL igt@pm_rpm@debugfs-read: shard-apl: PASS -> DMESG-WARN igt@prime_busy@hang-vebox: shard-kbl: PASS -> DMESG-WARN +1 igt@prime_busy@wait-hang-render: shard-kbl: PASS -> FAIL +1 Warnings igt@drv_missed_irq: shard-apl: PASS -> SKIP shard-glk: PASS -> SKIP igt@perf_pmu@multi-client-rcs0: shard-kbl: PASS -> SKIP +14 igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9101_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@debugfs-reader: shard-kbl: PASS -> DMESG-WARN (fdo#103313) igt@gem_eio@execbuf: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) +2 shard-apl: PASS -> INCOMPLETE (fdo#103927) +1 igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@prime_busy@wait-hang-vebox: shard-kbl: PASS -> INCOMPLETE (fdo#103665) +5 Possible fixes igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: FAIL (fdo#105707) -> PASS igt@kms_flip@2x-plain-flip-fb-recreate: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible: shard-hsw: FAIL (fdo#103928) -> PASS igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +1 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4227 -> Patchwork_9101 CI_DRM_4227: a8727d3fe03770e4d523468dfbc487dfe01597d3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4495: 71c7a5740913d2618f44bca252669efe8a84f4c9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9101: 53df508ebd8a1a81050fa8fc842dcf06ed690974 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4495: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9101/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm: Make ioctls available for in-kernel clients
On Wed, May 23, 2018 at 04:34:05PM +0200, Noralf Trønnes wrote:
> Make ioctl wrappers for functions that will be used by the in-kernel API.
> The following functions are touched:
> - drm_mode_create_dumb_ioctl()
> - drm_mode_destroy_dumb_ioctl()
> - drm_mode_addfb()
> - drm_mode_rmfb()
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc_internal.h | 19 +
> drivers/gpu/drm/drm_dumb_buffers.c | 33 +++--
> drivers/gpu/drm/drm_framebuffer.c | 42
> -
> drivers/gpu/drm/drm_ioctl.c | 4 ++--
> 4 files changed, 66 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 5d307b23a4e6..c762614af453 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -62,6 +62,12 @@ int drm_mode_getresources(struct drm_device *dev,
>
>
> /* drm_dumb_buffers.c */
> +int drm_mode_create_dumb(struct drm_device *dev,
> + struct drm_mode_create_dumb *args,
> + struct drm_file *file_priv);
> +int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
> + struct drm_file *file_priv);
> +
> /* IOCTLs */
> int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> @@ -163,14 +169,19 @@ int drm_framebuffer_check_src_coords(uint32_t src_x,
> uint32_t src_y,
>const struct drm_framebuffer *fb);
> void drm_fb_release(struct drm_file *file_priv);
>
> +int drm_mode_addfb(struct drm_device *dev, struct drm_mode_fb_cmd *or,
> +struct drm_file *file_priv);
> +int drm_mode_rmfb(struct drm_device *dev, u32 fb_id,
> + struct drm_file *file_priv);
> +
>
> /* IOCTL */
> -int drm_mode_addfb(struct drm_device *dev,
> -void *data, struct drm_file *file_priv);
> +int drm_mode_addfb_ioctl(struct drm_device *dev,
> + void *data, struct drm_file *file_priv);
> int drm_mode_addfb2(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> -int drm_mode_rmfb(struct drm_device *dev,
> - void *data, struct drm_file *file_priv);
> +int drm_mode_rmfb_ioctl(struct drm_device *dev,
> + void *data, struct drm_file *file_priv);
> int drm_mode_getfb(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> b/drivers/gpu/drm/drm_dumb_buffers.c
> index 39ac15ce4702..eed9687b8698 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -53,10 +53,10 @@
> * a hardware-specific ioctl to allocate suitable buffer objects.
> */
>
> -int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> -void *data, struct drm_file *file_priv)
> +int drm_mode_create_dumb(struct drm_device *dev,
> + struct drm_mode_create_dumb *args,
> + struct drm_file *file_priv)
> {
> - struct drm_mode_create_dumb *args = data;
> u32 cpp, stride, size;
>
> if (!dev->driver->dumb_create)
> @@ -91,6 +91,12 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> return dev->driver->dumb_create(file_priv, dev, args);
> }
>
> +int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> +void *data, struct drm_file *file_priv)
> +{
> + return drm_mode_create_dumb(dev, data, file_priv);
> +}
> +
> /**
> * drm_mode_mmap_dumb_ioctl - create an mmap offset for a dumb backing
> storage buffer
> * @dev: DRM device
> @@ -122,17 +128,22 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
> &args->offset);
> }
>
> +int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
> + struct drm_file *file_priv)
> +{
> + if (!dev->driver->dumb_create)
> + return -ENOSYS;
> +
> + if (dev->driver->dumb_destroy)
> + return dev->driver->dumb_destroy(file_priv, dev, handle);
> + else
> + return drm_gem_dumb_destroy(file_priv, dev, handle);
> +}
> +
> int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv)
> {
> struct drm_mode_destroy_dumb *args = data;
>
> - if (!dev->driver->dumb_create)
> - return -ENOSYS;
> -
> - if (dev->driver->dumb_destroy)
> - return dev->driver->dumb_destroy(file_priv, dev, args->handle);
> - else
> - return drm_gem_dumb_destroy(file_priv, dev, args->handle);
> + return drm_mode_destroy_dumb(dev, args->handle, file_priv);
> }
> -
> diff --git a/drivers/gpu/drm/drm_framebuffer.
Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
Hi Benson,
On 24/05/2018 07:47, Benson Leung wrote:
> Hi Neil, Hi Stefan,
>
> On Fri, May 18, 2018 at 03:05:02PM +0200, Neil Armstrong wrote:
>> The EC can expose a CEC bus, this patch adds the CEC related definitions
>> needed by the cros-ec-cec driver.
>> Having a 16 byte mkbp event size makes it possible to send CEC
>> messages from the EC to the AP directly inside the mkbp event
>> instead of first doing a notification and then a read.
>>
>> Signed-off-by: Stefan Adolfsson
>> Signed-off-by: Neil Armstrong
>
> It looks like this change squashes together this chromeos-4.4 CL
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1061879
> and some other new changes to add cec to cros_ec_commands.
>
> Could you separate the two? One patch that's as close to Stefan's
> which introduces the 16 byte mkbp, and a second one that
> adds the HDMI CEC commands?
OK, will split.
Neil
>
> Thanks,
> Benson
>> ---
>> drivers/platform/chrome/cros_ec_proto.c | 40 +
>> include/linux/mfd/cros_ec.h | 2 +-
>> include/linux/mfd/cros_ec_commands.h| 80
>> +
>> 3 files changed, 112 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_proto.c
>> b/drivers/platform/chrome/cros_ec_proto.c
>> index e7bbdf9..c4f6c44 100644
>> --- a/drivers/platform/chrome/cros_ec_proto.c
>> +++ b/drivers/platform/chrome/cros_ec_proto.c
>> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device
>> *ec_dev,
>> }
>> EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>>
>> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
>> + struct cros_ec_command *msg,
>> + int version, uint32_t size)
>> +{
>> +int ret;
>> +
>> +msg->version = version;
>> +msg->command = EC_CMD_GET_NEXT_EVENT;
>> +msg->insize = size;
>> +msg->outsize = 0;
>> +
>> +ret = cros_ec_cmd_xfer(ec_dev, msg);
>> +if (ret > 0) {
>> +ec_dev->event_size = ret - 1;
>> +memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
>> +}
>> +
>> +return ret;
>> +}
>> +
>> static int get_next_event(struct cros_ec_device *ec_dev)
>> {
>> u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>> struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
>> +static int cmd_version = 1;
>> int ret;
>>
>> if (ec_dev->suspended) {
>> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device
>> *ec_dev)
>> return -EHOSTDOWN;
>> }
>>
>> -msg->version = 0;
>> -msg->command = EC_CMD_GET_NEXT_EVENT;
>> -msg->insize = sizeof(ec_dev->event_data);
>> -msg->outsize = 0;
>> +if (cmd_version == 1) {
>> +ret = get_next_event_xfer(ec_dev, msg, cmd_version,
>> +sizeof(struct ec_response_get_next_event_v1));
>> +if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
>> +return ret;
>>
>> -ret = cros_ec_cmd_xfer(ec_dev, msg);
>> -if (ret > 0) {
>> -ec_dev->event_size = ret - 1;
>> -memcpy(&ec_dev->event_data, msg->data,
>> - sizeof(ec_dev->event_data));
>> +/* Fallback to version 0 for future send attempts */
>> +cmd_version = 0;
>> }
>>
>> +ret = get_next_event_xfer(ec_dev, msg, cmd_version,
>> + sizeof(struct ec_response_get_next_event));
>> +
>> return ret;
>> }
>>
>> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
>> index f36125e..32caef3 100644
>> --- a/include/linux/mfd/cros_ec.h
>> +++ b/include/linux/mfd/cros_ec.h
>> @@ -147,7 +147,7 @@ struct cros_ec_device {
>> bool mkbp_event_supported;
>> struct blocking_notifier_head event_notifier;
>>
>> -struct ec_response_get_next_event event_data;
>> +struct ec_response_get_next_event_v1 event_data;
>> int event_size;
>> u32 host_event_wake_mask;
>> };
>> diff --git a/include/linux/mfd/cros_ec_commands.h
>> b/include/linux/mfd/cros_ec_commands.h
>> index f2edd99..16c3a2b 100644
>> --- a/include/linux/mfd/cros_ec_commands.h
>> +++ b/include/linux/mfd/cros_ec_commands.h
>> @@ -804,6 +804,8 @@ enum ec_feature_code {
>> EC_FEATURE_MOTION_SENSE_FIFO = 24,
>> /* EC has RTC feature that can be controlled by host commands */
>> EC_FEATURE_RTC = 27,
>> +/* EC supports CEC commands */
>> +EC_FEATURE_CEC = 35,
>> };
>>
>> #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
>> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
>> /* EC sent a sysrq command */
>> EC_MKBP_EVENT_SYSRQ = 6,
>>
>> +/* Notify the AP that something happened on CEC */
>> +EC_MKBP_CEC_EVENT = 8,
>> +
>> +/* Send an incoming CEC message to the AP */
>> +EC_MKBP_EVENT_CEC_MESSAGE = 9,
>> +
>> /* Number of MKBP events */
>> EC_MKBP_
[Intel-gfx] [PATCH] drm/i915: Look for an active kernel context before switching
We were not very carefully checking to see if an older request on the
engine was an earlier switch-to-kernel-context before deciding to emit a
new switch. The end result would be that we could get into a permanent
loop of trying to emit a new request to perform the switch simply to
flush the existing switch.
What we need is a means of tracking the completion of each timeline
versus the kernel context, that is to detect if a more recent request
has been submitted that would result in a switch away from the kernel
context. To realise this, we need only to look in our syncmap on the
kernel context and check that we have synchronized against all active
rings.
v2: Since all ringbuffer clients currently share the same timeline, we do
have to use the gem_context to distinguish clients.
As a bonus, include all the tracing used to debug the death inside
suspend.
v3: Test, test, test. Construct a selftest to exercise and assert the
expected behaviour that multiple switch-to-contexts do not emit
redundant requests.
Reported-by: Mika Kuoppala
Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
timelines")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 7 +
drivers/gpu/drm/i915/i915_gem.h | 3 +
drivers/gpu/drm/i915/i915_gem_context.c | 86 +--
drivers/gpu/drm/i915/i915_request.c | 5 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 144 ++
.../drm/i915/selftests/i915_mock_selftests.h | 1 +
6 files changed, 231 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 03874b50ada9..05f44ca35a06 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3703,6 +3703,9 @@ static int wait_for_engines(struct drm_i915_private *i915)
int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int flags)
{
+ GEM_TRACE("flags=%x (%s)\n",
+ flags, flags & I915_WAIT_LOCKED ? "locked" : "unlocked");
+
/* If the device is asleep, we have no requests outstanding */
if (!READ_ONCE(i915->gt.awake))
return 0;
@@ -3719,6 +3722,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915,
unsigned int flags)
return err;
}
i915_retire_requests(i915);
+ GEM_BUG_ON(i915->gt.active_requests);
return wait_for_engines(i915);
} else {
@@ -4901,6 +4905,7 @@ static void assert_kernel_context_is_current(struct
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ GEM_BUG_ON(i915->gt.active_requests);
for_each_engine(engine, i915, id) {
GEM_BUG_ON(__i915_gem_active_peek(&engine->timeline.last_request));
GEM_BUG_ON(engine->last_retired_context->gem_context != kctx);
@@ -4932,6 +4937,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
struct drm_device *dev = &dev_priv->drm;
int ret;
+ GEM_TRACE("\n");
+
intel_runtime_pm_get(dev_priv);
intel_suspend_gt_powersave(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5bf24cfc218c..62ee4e385365 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -63,9 +63,12 @@ struct drm_i915_private;
#if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
#define GEM_TRACE_DUMP() ftrace_dump(DUMP_ALL)
+#define GEM_TRACE_DUMP_ON(expr) \
+ do { if (expr) ftrace_dump(DUMP_ALL); } while (0)
#else
#define GEM_TRACE(...) do { } while (0)
#define GEM_TRACE_DUMP() do { } while (0)
+#define GEM_TRACE_DUMP_ON(expr) BUILD_BUG_ON_INVALID(expr)
#endif
#define I915_NUM_ENGINES 8
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b69b18ef8120..45393f6e0208 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -576,30 +576,72 @@ last_request_on_engine(struct i915_timeline *timeline,
{
struct i915_request *rq;
- if (timeline == &engine->timeline)
- return NULL;
+ GEM_BUG_ON(timeline == &engine->timeline);
rq = i915_gem_active_raw(&timeline->last_request,
&engine->i915->drm.struct_mutex);
- if (rq && rq->engine == engine)
+ if (rq && rq->engine == engine) {
+ GEM_TRACE("last request for %s on engine %s: %llx:%d\n",
+ timeline->name, engine->name,
+ rq->fence.context, rq->fence.seqno);
+ GEM_BUG_ON(rq->timeline != timeline);
return rq;
+ }
return NULL;
}
-static bool engine_has_idle_kernel_context(struct intel_engine_cs *engine)
+static bool engine_has_kernel_context_barrie
[Intel-gfx] [PATCH v5 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
---
include/linux/mfd/cros_ec_commands.h | 85
1 file changed, 85 insertions(+)
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index cc0768e..ea9646f 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -804,6 +804,8 @@ enum ec_feature_code {
EC_FEATURE_MOTION_SENSE_FIFO = 24,
/* EC has RTC feature that can be controlled by host commands */
EC_FEATURE_RTC = 27,
+ /* EC supports CEC commands */
+ EC_FEATURE_CEC = 35,
};
#define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
@@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
/* EC sent a sysrq command */
EC_MKBP_EVENT_SYSRQ = 6,
+ /* Notify the AP that something happened on CEC */
+ EC_MKBP_CEC_EVENT = 8,
+
+ /* Send an incoming CEC message to the AP */
+ EC_MKBP_EVENT_CEC_MESSAGE = 9,
+
/* Number of MKBP events */
EC_MKBP_EVENT_COUNT,
};
@@ -2850,6 +2858,83 @@ struct ec_params_reboot_ec {
/*/
/*
+ * HDMI CEC commands
+ *
+ * These commands are for sending and receiving message via HDMI CEC
+ */
+#define MAX_CEC_MSG_LEN 16
+
+/* CEC message from the AP to be written on the CEC bus */
+#define EC_CMD_CEC_WRITE_MSG 0x00B8
+
+/**
+ * struct ec_params_cec_write - Message to write to the CEC bus
+ * @msg: message content to write to the CEC bus
+ */
+struct ec_params_cec_write {
+ uint8_t msg[MAX_CEC_MSG_LEN];
+} __packed;
+
+/* Set various CEC parameters */
+#define EC_CMD_CEC_SET 0x00BA
+
+/**
+ * struct ec_params_cec_set - CEC parameters set
+ * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
+ * @enable: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable CEC
+ * or 1 to enable CEC functionnality
+ * @address: in case cmd is CEC_CMD_LOGICAL_ADDRESS, this field encodes the
+ * requested logical address between 0 and 15 or 0xff to unregister
+ */
+struct ec_params_cec_set {
+ uint8_t cmd; /* enum cec_command */
+ union {
+ uint8_t enable;
+ uint8_t address;
+ };
+} __packed;
+
+/* Read various CEC parameters */
+#define EC_CMD_CEC_GET 0x00BB
+
+/**
+ * struct ec_params_cec_get - CEC parameters get
+ * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
+ */
+struct ec_params_cec_get {
+ uint8_t cmd; /* enum cec_command */
+} __packed;
+
+/**
+ * struct ec_response_cec_get - CEC parameters get response
+ * @enable: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
+ * disabled or 1 if CEC functionnality is enabled
+ * @address: in case cmd was CEC_CMD_LOGICAL_ADDRESS, this will encode the
+ * configured logical address between 0 and 15 or 0xff if unregistered
+ */
+struct ec_response_cec_get {
+ union {
+ uint8_t enable;
+ uint8_t address;
+ };
+} __packed;
+
+/* CEC parameters command */
+enum cec_command {
+ /* CEC reading, writing and events enable */
+ CEC_CMD_ENABLE,
+ /* CEC logical address */
+ CEC_CMD_LOGICAL_ADDRESS,
+};
+
+/* Events from CEC to AP */
+enum mkbp_cec_event {
+ EC_MKBP_CEC_SEND_OK = BIT(0),
+ EC_MKBP_CEC_SEND_FAILED = BIT(1),
+};
+
+/*/
+/*
* Special commands
*
* These do not follow the normal rules for commands. See each command for
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface
On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
> Initialize HDCP2.2 support. This includes the mei interface
> initialization along with required notifier registration.
>
> v2:
> mei interface handle is protected with mutex. [Chris Wilson]
> v3:
> Notifiers are used for the mei interface state.
> v4:
> Poll for mei client device state
> Error msg for out of mem [Uma]
> Inline req for init function removed [Uma]
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dp.c | 3 +-
> drivers/gpu/drm/i915/intel_drv.h | 5 +-
> drivers/gpu/drm/i915/intel_hdcp.c | 117
> +-
> drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
> 4 files changed, 122 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..276eb49113e9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6368,7 +6368,8 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> intel_dp_add_properties(intel_dp, connector);
>
> if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
> - int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
> + int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim,
> + false);
> if (ret)
> DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index ac943ec73987..750fc19f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -442,7 +442,7 @@ struct intel_hdcp {
> /* mei interface related information */
> struct mei_cl_device *cldev;
> struct mei_hdcp_data mei_data;
> -
> + struct notifier_block mei_cldev_nb;
> struct delayed_work hdcp2_check_work;
> };
>
> @@ -1940,7 +1940,8 @@ void intel_hdcp_atomic_check(struct drm_connector
> *connector,
>struct drm_connector_state *old_state,
>struct drm_connector_state *new_state);
> int intel_hdcp_init(struct intel_connector *connector,
> - const struct intel_hdcp_shim *hdcp_shim);
> + const struct intel_hdcp_shim *hdcp_shim,
> + bool hdcp2_supported);
> int intel_hdcp_enable(struct intel_connector *connector);
> int intel_hdcp_disable(struct intel_connector *connector);
> int intel_hdcp_check_link(struct intel_connector *connector);
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index f3f935046c31..9948e4b4e203 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
> @@ -25,6 +26,7 @@ static int _intel_hdcp2_enable(struct intel_connector
> *connector);
> static int _intel_hdcp2_disable(struct intel_connector *connector);
> static void intel_hdcp2_check_work(struct work_struct *work);
> static int intel_hdcp2_check_link(struct intel_connector *connector);
> +static int intel_hdcp2_init(struct intel_connector *connector);
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> const struct intel_hdcp_shim *shim)
> @@ -766,11 +768,15 @@ bool is_hdcp_supported(struct drm_i915_private
> *dev_priv, enum port port)
> }
>
> int intel_hdcp_init(struct intel_connector *connector,
> - const struct intel_hdcp_shim *hdcp_shim)
> + const struct intel_hdcp_shim *hdcp_shim,
> + bool hdcp2_supported)
> {
> struct intel_hdcp *hdcp = &connector->hdcp;
> int ret;
>
> + if (!hdcp_shim)
> + return -EINVAL;
> +
> ret = drm_connector_attach_content_protection_property(
> &connector->base);
> if (ret)
> @@ -779,7 +785,12 @@ int intel_hdcp_init(struct intel_connector *connector,
> hdcp->hdcp_shim = hdcp_shim;
> mutex_init(&hdcp->hdcp_mutex);
> INIT_DELAYED_WORK(&hdcp->hdcp_check_work, intel_hdcp_check_work);
> + INIT_DELAYED_WORK(&hdcp->hdcp2_check_work, intel_hdcp2_check_work);
> INIT_WORK(&hdcp->hdcp_prop_work, intel_hdcp_prop_work);
> +
> + if (hdcp2_supported)
> + intel_hdcp2_init(connector);
> +
> return 0;
> }
>
> @@ -1637,3 +1648,107 @@ static void intel_hdcp2_check_work(struct work_struct
> *work)
> schedule_delayed_work(&hdcp->hdcp2_check_work,
> DRM_HDCP2_CHECK_PERIOD_MS);
> }
> +
> +static int initialize_mei_hdcp_data(struct intel_connector *connector)
> +{
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + struct mei_hdcp_data *data = &hdcp->mei_data;
> + enum por
[Intel-gfx] [PATCH v5 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
Reviewed-by: Hans Verkuil
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel_display.h | 20
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 13 +
4 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd9588..2d65d56 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,7 @@ config DRM_I915
select SYNC_FILE
select IOSF_MBI
select CRC32
+ select CEC_CORE if CEC_NOTIFIER
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
#define port_name(p) ((p) + 'A')
+static inline const char *port_identifier(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return "Port A";
+ case PORT_B:
+ return "Port B";
+ case PORT_C:
+ return "Port C";
+ case PORT_D:
+ return "Port D";
+ case PORT_E:
+ return "Port E";
+ case PORT_F:
+ return "Port F";
+ default:
+ return "";
+ }
+}
+
enum dpio_channel {
DPIO_CH0,
DPIO_CH1
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
/**
* __wait_for - magic wait macro
@@ -1001,6 +1002,7 @@ struct intel_hdmi {
bool has_audio;
bool rgb_quant_range_selectable;
struct intel_connector *attached_connector;
+ struct cec_notifier *notifier;
};
struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1baef4a..d522b5b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
connected = true;
}
+ cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
+
return connected;
}
@@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
{
enum drm_connector_status status;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
@@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
+ if (status != connector_status_connected)
+ cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
+
return status;
}
@@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder,
static void intel_hdmi_destroy(struct drm_connector *connector)
{
+ if (intel_attached_hdmi(connector)->notifier)
+ cec_notifier_put(intel_attached_hdmi(connector)->notifier);
kfree(to_intel_connector(connector)->detect_edid);
drm_connector_cleanup(connector);
kfree(connector);
@@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
+
+ intel_hdmi->notifier = cec_notifier_get_conn(dev->dev,
+port_identifier(port));
+ if (!intel_hdmi->notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/6] media: cec-notifier: Get notifier by device and connector name
On 24/05/18 10:54, Neil Armstrong wrote:
> In non device-tree world, we can need to get the notifier by the driver
> name directly and eventually defer probe if not yet created.
>
> This patch adds a variant of the get function by using the device name
> instead and will not create a notifier if not yet created.
>
> But the i915 driver exposes at least 2 HDMI connectors, this patch also
> adds the possibility to add a connector name tied to the notifier device
> to form a tuple and associate different CEC controllers for each HDMI
> connectors.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/cec/cec-notifier.c | 11 ---
> include/media/cec-notifier.h | 27 ---
> 2 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/cec/cec-notifier.c
> b/drivers/media/cec/cec-notifier.c
> index 16dffa0..dd2078b 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -21,6 +21,7 @@ struct cec_notifier {
> struct list_head head;
> struct kref kref;
> struct device *dev;
> + const char *conn;
> struct cec_adapter *cec_adap;
> void (*callback)(struct cec_adapter *adap, u16 pa);
>
> @@ -30,13 +31,14 @@ struct cec_notifier {
> static LIST_HEAD(cec_notifiers);
> static DEFINE_MUTEX(cec_notifiers_lock);
>
> -struct cec_notifier *cec_notifier_get(struct device *dev)
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
> *conn)
> {
> struct cec_notifier *n;
>
> mutex_lock(&cec_notifiers_lock);
> list_for_each_entry(n, &cec_notifiers, head) {
> - if (n->dev == dev) {
> + if (n->dev == dev &&
> + (!conn || !strcmp(n->conn, conn))) {
> kref_get(&n->kref);
> mutex_unlock(&cec_notifiers_lock);
> return n;
> @@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> if (!n)
> goto unlock;
> n->dev = dev;
> + if (conn)
> + n->conn = kstrdup(conn, GFP_KERNEL);
> n->phys_addr = CEC_PHYS_ADDR_INVALID;
> mutex_init(&n->lock);
> kref_init(&n->kref);
> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> mutex_unlock(&cec_notifiers_lock);
> return n;
> }
> -EXPORT_SYMBOL_GPL(cec_notifier_get);
> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>
> static void cec_notifier_release(struct kref *kref)
> {
> @@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
> container_of(kref, struct cec_notifier, kref);
>
> list_del(&n->head);
> + kfree(n->conn);
> kfree(n);
> }
>
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index cf0add7..814eeef 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -20,8 +20,10 @@ struct cec_notifier;
> #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>
> /**
> - * cec_notifier_get - find or create a new cec_notifier for the given device.
> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
> + * device and connector tuple.
> * @dev: device that sends the events.
> + * @conn: the connector name from which the event occurs
> *
> * If a notifier for device @dev already exists, then increase the refcount
> * and return that notifier.
> @@ -31,7 +33,8 @@ struct cec_notifier;
> *
> * Return NULL if the memory could not be allocated.
> */
> -struct cec_notifier *cec_notifier_get(struct device *dev);
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> +const char *conn);
>
> /**
> * cec_notifier_put - decrease refcount and delete when the refcount reaches
> 0.
> @@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
> struct cec_notifier *notifier);
>
> #else
> -static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> + const char *conn)
> {
> /* A non-NULL pointer is expected on success */
> return (struct cec_notifier *)0xdeadfeed;
> @@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct
> cec_adapter *adap,
> #endif
>
> /**
> + * cec_notifier_get - find or create a new cec_notifier for the given device.
> + * @dev: device that sends the events.
> + *
> + * If a notifier for device @dev already exists, then increase the refcount
> + * and return that notifier.
> + *
> + * If it doesn't exist, then allocate a new notifier struct and return a
> + * pointer to that new struct.
> + *
> + * Return NULL if the memory could not be allocated.
> + */
> +static inline struct cec_notifier *cec_notifier_ge
Re: [Intel-gfx] [PATCH 4/9] drm: Begin an API for in-kernel clients
On Wed, May 23, 2018 at 04:34:06PM +0200, Noralf Trønnes wrote:
> This the beginning of an API for in-kernel clients.
> First out is a way to get a framebuffer backed by a dumb buffer.
>
> Only GEM drivers are supported.
> The original idea of using an exported dma-buf was dropped because it
> also creates an anonomous file descriptor which doesn't work when the
> buffer is created from a kernel thread. The easy way out is to use
> drm_driver.gem_prime_vmap to get the virtual address, which requires a
> GEM object. This excludes the vmwgfx driver which is the only non-GEM
> driver apart from the legacy ones. A solution for vmwgfx will have to be
> worked out later if it wants to support the client API which it probably
> will when we have a bootsplash client.
>
> Signed-off-by: Noralf Trønnes
A few small nits below, with those addressed:
Reviewed-by: Daniel Vetter
> ---
> Documentation/gpu/drm-client.rst | 12 ++
> Documentation/gpu/index.rst | 1 +
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_client.c | 267
> +++
> drivers/gpu/drm/drm_drv.c| 1 +
> include/drm/drm_client.h | 83
> include/drm/drm_device.h | 7 +
> 7 files changed, 372 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/gpu/drm-client.rst
> create mode 100644 drivers/gpu/drm/drm_client.c
> create mode 100644 include/drm/drm_client.h
>
> diff --git a/Documentation/gpu/drm-client.rst
> b/Documentation/gpu/drm-client.rst
> new file mode 100644
> index ..7e672063e7eb
> --- /dev/null
> +++ b/Documentation/gpu/drm-client.rst
> @@ -0,0 +1,12 @@
> +=
> +Kernel clients
> +=
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_client.c
> + :doc: overview
> +
> +.. kernel-doc:: include/drm/drm_client.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_client.c
> + :export:
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index 00288f34c5a6..1fcf8e851e15 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide
> drm-kms
> drm-kms-helpers
> drm-uapi
> + drm-client
> drivers
> vga-switcheroo
> vgaarbiter
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index ef9f3dab287f..8c8045147416 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -18,7 +18,7 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \
> drm_encoder.o drm_mode_object.o drm_property.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> - drm_syncobj.o drm_lease.o
> + drm_syncobj.o drm_lease.o drm_client.o
>
> drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> drm-$(CONFIG_DRM_VM) += drm_vm.o
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> new file mode 100644
> index ..0919aea7
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -0,0 +1,267 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2018 Noralf Trønnes
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "drm_crtc_internal.h"
> +#include "drm_internal.h"
> +
> +/**
> + * DOC: overview
> + *
> + * This library provides support for clients running in the kernel like
> fbdev and bootsplash.
> + * Currently it's only partially implemented, just enough to support fbdev.
> + *
> + * GEM drivers which provide a GEM based dumb buffer with a virtual address
> are supported.
> + */
> +
> +static int drm_client_alloc_file(struct drm_client_dev *client)
> +{
> + struct drm_device *dev = client->dev;
> + struct drm_file *file;
> +
> + file = drm_file_alloc(dev->primary);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + drm_dev_get(dev);
> +
> + mutex_lock(&dev->filelist_mutex);
> + list_add(&file->lhead, &dev->filelist_internal);
> + mutex_unlock(&dev->filelist_mutex);
> +
> + client->file = file;
> +
> + return 0;
> +}
> +
> +static void drm_client_free_file(struct drm_client_dev *client)
> +{
> + struct drm_device *dev = client->dev;
> +
> + mutex_lock(&dev->filelist_mutex);
> + list_del(&client->file->lhead);
> + mutex_unlock(&dev->filelist_mutex);
> +
> + drm_file_free(client->file);
> + drm_dev_put(dev);
> +}
> +
> +/**
> + * drm_client_new - Create a DRM client
> + * @dev: DRM device
> + *
> + * Returns:
> + * Pointer to a client or an error pointer on failure.
> + */
> +struct drm_client_dev *drm_client_new(struct drm_device *dev)
Api nitpick:
int drm_client_init(struct drm_device *dev,
struct drm_client_dev *client)
and dropping the
Re: [Intel-gfx] [PATCH 02/24] drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC
Paulo Zanoni writes:
> From: Dhinakaran Pandiyan
>
> The Graphics System Event(GSE) interrupt bit has a new location in the
> GU_MISC_INTERRUPT_{IIR, ISR, IMR, IER} registers. Since GSE was the only
> DE_MISC interrupt that was enabled, with this change we don't enable/handle
> any of DE_MISC interrupts for gen11. Credits to Paulo for pointing out
> the register change.
>
> Signed-off-by: Dhinakaran Pandiyan
> [Paulo: bikesheds and rebases]
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_irq.c | 38 --
> drivers/gpu/drm/i915/i915_reg.h | 7 +++
> 2 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 2fd92a886789..dde938bbfb0a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2605,7 +2605,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> I915_WRITE(GEN8_DE_MISC_IIR, iir);
> ret = IRQ_HANDLED;
>
> - if (iir & GEN8_DE_MISC_GSE) {
> + if (INTEL_GEN(dev_priv) <= 10 &&
> + (iir & GEN8_DE_MISC_GSE)) {
This bit should not be ever set with gen11 so no need to
add extra guards?
> intel_opregion_asle_intr(dev_priv);
> found = true;
> }
> @@ -2943,6 +2944,30 @@ gen11_gt_irq_handler(struct drm_i915_private * const
> i915,
> spin_unlock(&i915->irq_lock);
> }
>
> +static irqreturn_t
Return is never used for anything, just use void.
> +gen11_gu_misc_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
> +{
> + irqreturn_t ret = IRQ_NONE;
> + u32 iir;
> +
> + if (!(master_ctl & GEN11_GU_MISC_IRQ))
> + return ret;
> +
> + iir = I915_READ(GEN11_GU_MISC_IIR);
This reg seems to out of forcewake domain so
just use raw_reg_read() in here.
> + if (iir) {
just a note that likely(iir) if you want to add emphasis.
> + I915_WRITE(GEN11_GU_MISC_IIR, iir);
raw_reg_write()
-Mika
> + ret = IRQ_HANDLED;
> + if (iir & GEN11_GU_MISC_GSE)
> + intel_opregion_asle_intr(dev_priv);
> + else
> + DRM_ERROR("Unexpected GU Misc interrupt 0x%08x\n", iir);
> + } else {
> + DRM_ERROR("The master control interrupt lied (GU MISC)!\n");
> + }
> +
> + return ret;
> +}
> +
> static irqreturn_t gen11_irq_handler(int irq, void *arg)
> {
> struct drm_i915_private * const i915 = to_i915(arg);
> @@ -2976,6 +3001,8 @@ static irqreturn_t gen11_irq_handler(int irq, void *arg)
> enable_rpm_wakeref_asserts(i915);
> }
>
> + gen11_gu_misc_irq_handler(i915, master_ctl);
> +
> /* Acknowledge and enable interrupts. */
> raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, GEN11_MASTER_IRQ | master_ctl);
>
> @@ -3465,6 +3492,7 @@ static void gen11_irq_reset(struct drm_device *dev)
>
> GEN3_IRQ_RESET(GEN8_DE_PORT_);
> GEN3_IRQ_RESET(GEN8_DE_MISC_);
> + GEN3_IRQ_RESET(GEN11_GU_MISC_);
> GEN3_IRQ_RESET(GEN8_PCU_);
> }
>
> @@ -3908,9 +3936,12 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> uint32_t de_pipe_enables;
> u32 de_port_masked = GEN8_AUX_CHANNEL_A;
> u32 de_port_enables;
> - u32 de_misc_masked = GEN8_DE_MISC_GSE | GEN8_DE_EDP_PSR;
> + u32 de_misc_masked = GEN8_DE_EDP_PSR;
> enum pipe pipe;
>
> + if (INTEL_GEN(dev_priv) <= 10)
> + de_misc_masked |= GEN8_DE_MISC_GSE;
> +
> if (INTEL_GEN(dev_priv) >= 9) {
> de_pipe_masked |= GEN9_DE_PIPE_IRQ_FAULT_ERRORS;
> de_port_masked |= GEN9_AUX_CHANNEL_B | GEN9_AUX_CHANNEL_C |
> @@ -4004,10 +4035,13 @@ static void gen11_gt_irq_postinstall(struct
> drm_i915_private *dev_priv)
> static int gen11_irq_postinstall(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 gu_misc_masked = GEN11_GU_MISC_GSE;
>
> gen11_gt_irq_postinstall(dev_priv);
> gen8_de_irq_postinstall(dev_priv);
>
> + GEN3_IRQ_INIT(GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
> +
> I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE);
>
> I915_WRITE(GEN11_GFX_MSTR_IRQ, GEN11_MASTER_IRQ);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 196a0eb79272..ca474f6f523c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7016,9 +7016,16 @@ enum {
> #define GEN8_PCU_IIR _MMIO(0x444e8)
> #define GEN8_PCU_IER _MMIO(0x444ec)
>
> +#define GEN11_GU_MISC_ISR_MMIO(0x444f0)
> +#define GEN11_GU_MISC_IMR_MMIO(0x444f4)
> +#define GEN11_GU_MISC_IIR_MMIO(0x444f8)
> +#define GEN11_GU_MISC_IER_MMIO(0x444fc)
> +#define GEN11_GU_MISC_GSE (1 << 27)
[Intel-gfx] [PATCH v5 3/6] mfd: cros-ec: Increase maximum mkbp event size
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
---
drivers/platform/chrome/cros_ec_proto.c | 40 +
include/linux/mfd/cros_ec.h | 2 +-
include/linux/mfd/cros_ec_commands.h| 19
3 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_proto.c
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..c4f6c44 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
+static int get_next_event_xfer(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg,
+ int version, uint32_t size)
+{
+ int ret;
+
+ msg->version = version;
+ msg->command = EC_CMD_GET_NEXT_EVENT;
+ msg->insize = size;
+ msg->outsize = 0;
+
+ ret = cros_ec_cmd_xfer(ec_dev, msg);
+ if (ret > 0) {
+ ec_dev->event_size = ret - 1;
+ memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
+ }
+
+ return ret;
+}
+
static int get_next_event(struct cros_ec_device *ec_dev)
{
u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
+ static int cmd_version = 1;
int ret;
if (ec_dev->suspended) {
@@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
return -EHOSTDOWN;
}
- msg->version = 0;
- msg->command = EC_CMD_GET_NEXT_EVENT;
- msg->insize = sizeof(ec_dev->event_data);
- msg->outsize = 0;
+ if (cmd_version == 1) {
+ ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event_v1));
+ if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
+ return ret;
- ret = cros_ec_cmd_xfer(ec_dev, msg);
- if (ret > 0) {
- ec_dev->event_size = ret - 1;
- memcpy(&ec_dev->event_data, msg->data,
- sizeof(ec_dev->event_data));
+ /* Fallback to version 0 for future send attempts */
+ cmd_version = 0;
}
+ ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event));
+
return ret;
}
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index f36125e..32caef3 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -147,7 +147,7 @@ struct cros_ec_device {
bool mkbp_event_supported;
struct blocking_notifier_head event_notifier;
- struct ec_response_get_next_event event_data;
+ struct ec_response_get_next_event_v1 event_data;
int event_size;
u32 host_event_wake_mask;
};
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index f2edd99..cc0768e 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
uint32_t sysrq;
} __packed;
+union ec_response_get_next_data_v1 {
+ uint8_t key_matrix[16];
+
+ /* Unaligned */
+ uint32_t host_event;
+
+ uint32_t buttons;
+ uint32_t switches;
+ uint32_t sysrq;
+ uint32_t cec_events;
+ uint8_tcec_message[16];
+} __packed;
+
struct ec_response_get_next_event {
uint8_t event_type;
/* Followed by event data if any */
union ec_response_get_next_data data;
} __packed;
+struct ec_response_get_next_event_v1 {
+ uint8_t event_type;
+ /* Followed by event data if any */
+ union ec_response_get_next_data_v1 data;
+} __packed;
+
/* Bit indices for buttons and switches.*/
/* Buttons */
#define EC_MKBP_POWER_BUTTON 0
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] drm: Begin an API for in-kernel clients
On 05/24/2018 10:32 AM, Daniel Vetter wrote: On Wed, May 23, 2018 at 11:45:00PM +0200, Thomas Hellstrom wrote: Hi, Noralf. A couple of issues below: On 05/23/2018 04:34 PM, Noralf Trønnes wrote: This the beginning of an API for in-kernel clients. First out is a way to get a framebuffer backed by a dumb buffer. Only GEM drivers are supported. The original idea of using an exported dma-buf was dropped because it also creates an anonomous file descriptor which doesn't work when the buffer is created from a kernel thread. The easy way out is to use drm_driver.gem_prime_vmap to get the virtual address, which requires a GEM object. This excludes the vmwgfx driver which is the only non-GEM driver apart from the legacy ones. A solution for vmwgfx will have to be worked out later if it wants to support the client API which it probably will when we have a bootsplash client. Couldn't you add vmap() and vunmap() to the dumb buffer API for in-kernel use rather than using GEM directly? But the main issue is pinning. It looks like the buffers are going to be vmapped() for a long time, which requires pinning, and that doesn't work for some drivers when they bind the framebuffer to a plane, since that might require pinning in another memory region and the vmap would have to be torn down. Besides, buffer pinning should really be avoided if possible: Since we can't page-fault vmaps, and setting up / tearing down vmaps is potentially an expensive operation, could we perhaps have a mapping api that allows the driver to cache vmaps? vmap() // Indicates that we want to map a bo begin_access() // Returns a virtual address which may vary between calls. Allows access. A fast operation. Behind the lines pins / reserves the bo and returns a cached vmap if the bo didn't move since last begin_access(), which is the typical case. end_access() // Disable access. Unpins / unreserves the bo. vunmap_cached() //Indicates that the map is no longer needed. The driver can release the cached map. The idea is that the API client would wrap all bo map accesses with begin_access() end_access(), allowing for the bo to be moved in between. So originally my ideas for the cpu side dma-buf interfaces where all meant to handle this. But then the first implementations bothered with none of this, but instead expected that stuff is pinned, and vmap Just Works. Which yeah doesn't work for vmwgfx and is a pain in a few other cases. I agree it'd be nice to fix all this, but it's also not a problem that this patch set here started. And since it's all optional (and vmwgfx isn't even using the current fb helper code) I think it's reasonable to address this post-merge (if someone gets around to it ever). What we'd need is is a fallback for when vmap doesn't exist (for fbdev that probably means a vmalloc'ed buffer + manual uploads, because fbdev), plus making sure dma-buf implementations actually implement it. My argument here is that, If I understand Noralf, this is intended to be an API exported outside of drm. In that case we shouldn't replicate the assumed behaviour of incomplete dma-buf implementations in a new API. Also the fact that vmwgfx currently isn't using the fbdev helpers isn't a good argument to design an API so that vmwgfx can _never_ use the fbdev helpers. The reason we aren't using them is that the kms implementation was so old that we didn't implement the necessary helper callbacks... Also, I might be misunderstanding the code a bit, but I doubt that vmwgfx is the only hardware with pinning restrictions on the framebuffer? I was under the assumption that most discrete hardware required the framebuffer to be pinned in VRAM? So the important question is, Is this a set of helpers for shared-memory GEM drivers to implement fbdev? Then I wouldn't bother, If it's intended to become an API for clients outside of DRM, then I would have to insist on the API being changed to reflect that. /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 1d6dc5c..272969e 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev
*ec)
kfree(msg);
}
+static const struct mfd_cell cros_ec_cec_cells[] = {
+ { .name = "cros-ec-cec" }
+};
+
static const struct mfd_cell cros_ec_rtc_cells[] = {
{ .name = "cros-ec-rtc" }
};
@@ -426,6 +430,18 @@ static int ec_device_probe(struct platform_device *pdev)
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
cros_ec_sensors_register(ec);
+ /* Check whether this EC instance has CEC host command support */
+ if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
+ retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
+cros_ec_cec_cells,
+ARRAY_SIZE(cros_ec_cec_cells),
+NULL, 0, NULL);
+ if (retval)
+ dev_err(ec->dev,
+ "failed to add cros-ec-cec device: %d\n",
+ retval);
+ }
+
/* Check whether this EC instance has RTC host command support */
if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
---
include/linux/mfd/cros_ec_commands.h | 81
1 file changed, 81 insertions(+)
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index cc0768e..fe33a81 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -804,6 +804,8 @@ enum ec_feature_code {
EC_FEATURE_MOTION_SENSE_FIFO = 24,
/* EC has RTC feature that can be controlled by host commands */
EC_FEATURE_RTC = 27,
+ /* EC supports CEC commands */
+ EC_FEATURE_CEC = 35,
};
#define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
@@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
/* EC sent a sysrq command */
EC_MKBP_EVENT_SYSRQ = 6,
+ /* Notify the AP that something happened on CEC */
+ EC_MKBP_EVENT_CEC_EVENT = 8,
+
+ /* Send an incoming CEC message to the AP */
+ EC_MKBP_EVENT_CEC_MESSAGE = 9,
+
/* Number of MKBP events */
EC_MKBP_EVENT_COUNT,
};
@@ -2850,6 +2858,79 @@ struct ec_params_reboot_ec {
/*/
/*
+ * HDMI CEC commands
+ *
+ * These commands are for sending and receiving message via HDMI CEC
+ */
+#define EC_MAX_CEC_MSG_LEN 16
+
+/* CEC message from the AP to be written on the CEC bus */
+#define EC_CMD_CEC_WRITE_MSG 0x00B8
+
+/**
+ * struct ec_params_cec_write - Message to write to the CEC bus
+ * @msg: message content to write to the CEC bus
+ */
+struct ec_params_cec_write {
+ uint8_t msg[EC_MAX_CEC_MSG_LEN];
+} __packed;
+
+/* Set various CEC parameters */
+#define EC_CMD_CEC_SET 0x00BA
+
+/**
+ * struct ec_params_cec_set - CEC parameters set
+ * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
+ * @val: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable CEC
+ * or 1 to enable CEC functionnality, in case cmd is
CEC_CMD_LOGICAL_ADDRESS,
+ * this field encodes the requested logical address between 0 and 15
+ * or 0xff to unregister
+ */
+struct ec_params_cec_set {
+ uint8_t cmd; /* enum cec_command */
+ uint8_t val;
+} __packed;
+
+/* Read various CEC parameters */
+#define EC_CMD_CEC_GET 0x00BB
+
+/**
+ * struct ec_params_cec_get - CEC parameters get
+ * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
+ */
+struct ec_params_cec_get {
+ uint8_t cmd; /* enum cec_command */
+} __packed;
+
+/**
+ * struct ec_response_cec_get - CEC parameters get response
+ * @val: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
+ * disabled or 1 if CEC functionnality is enabled,
+ * in case cmd was CEC_CMD_LOGICAL_ADDRESS, this will encode the
+ * configured logical address between 0 and 15 or 0xff if unregistered
+ */
+struct ec_response_cec_get {
+ uint8_t val;
+} __packed;
+
+/* CEC parameters command */
+enum ec_cec_command {
+ /* CEC reading, writing and events enable */
+ CEC_CMD_ENABLE,
+ /* CEC logical address */
+ CEC_CMD_LOGICAL_ADDRESS,
+};
+
+/* Events from CEC to AP */
+enum mkbp_cec_event {
+ /* Outgoing message was acknowledged by a follower */
+ EC_MKBP_CEC_SEND_OK = BIT(0),
+ /* Outgoing message was not acknowledged */
+ EC_MKBP_CEC_SEND_FAILED = BIT(1),
+};
+
+/*/
+/*
* Special commands
*
* These do not follow the normal rules for commands. See each command for
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/6] Add ChromeOS EC CEC Support
Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support through it's Embedded Controller, to enable the Linux CEC Core to communicate with it and get the CEC Physical Address from the correct HDMI Connector, the following must be added/changed: - Add the CEC sub-device registration in the ChromeOS EC MFD Driver - Add the CEC related commands and events definitions into the EC MFD driver - Add a way to get a CEC notifier with it's (optional) connector name - Add the CEC notifier to the i915 HDMI driver - Add the proper ChromeOS EC CEC Driver The CEC notifier with the connector name is the tricky point, since even on Device-Tree platforms, there is no way to distinguish between multiple HDMI connectors from the same DRM driver. The solution I implemented is pretty simple and only adds an optional connector name to eventually distinguish an HDMI connector notifier from another if they share the same device. Feel free to comment this patchset ! Changes since v4: - Split patch 3 to move the mkbp event size change into a separate patch Changes since v3 (incorrectly reported as v2): - Renamed "Chrome OS" to "ChromeOS" - Updated cros_ec_commands.h new structs definitions to kernel doc format - Added Reviwed-By tags Changes since v2: - Add i915 port_identifier() and use this stable name as cec_notifier conn name - Fixed and cleaned up the CEC commands and events handling - Rebased the CEC sub-device registration on top of Enric's serie - Fixed comments typo on cec driver - Protected the DMI match only with PCI and DMI Kconfigs Changes since v1: - Added cec_notifier_put to intel_hdmi - Fixed all small reported issues on the EC CEC driver - Moved the cec_notifier_get out of the #if .. #else .. #endif Changes since RFC: - Moved CEC sub-device registration after CEC commands and events definitions patch - Removed get_notifier_get_byname - Added CEC_CORE select into i915 Kconfig - Removed CEC driver fallback if notifier is not configured on HW, added explicit warn - Fixed CEC core return type on error - Moved to cros-ec-cec media platform directory - Use bus_find_device() to find the pci i915 device instead of get_notifier_get_byname() - Fix Logical Address setup - Added comment about HW support - Removed memset of msg structures Neil Armstrong (6): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Increase maximum mkbp event size mfd: cros-ec: Introduce CEC commands and events definitions. mfd: cros_ec_dev: Add CEC sub-device registration media: platform: Add ChromeOS EC CEC driver drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_display.h | 20 ++ drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 13 + drivers/media/cec/cec-notifier.c | 11 +- drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile | 2 + drivers/media/platform/cros-ec-cec/Makefile | 1 + drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++ drivers/mfd/cros_ec_dev.c| 16 ++ drivers/platform/chrome/cros_ec_proto.c | 40 ++- include/linux/mfd/cros_ec.h | 2 +- include/linux/mfd/cros_ec_commands.h | 104 +++ include/media/cec-notifier.h | 27 +- 14 files changed, 581 insertions(+), 16 deletions(-) create mode 100644 drivers/media/platform/cros-ec-cec/Makefile create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 6/6] media: platform: Add ChromeOS EC CEC driver
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.
The controller will be tied to the HDMI CEC notifier by using the platform
DMI Data and the i915 device name and connector name.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
---
drivers/media/platform/Kconfig | 11 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/cros-ec-cec/Makefile | 1 +
drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++
4 files changed, 361 insertions(+)
create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..bc37ecf 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
if CEC_PLATFORM_DRIVERS
+config VIDEO_CROS_EC_CEC
+ tristate "ChromeOS EC CEC driver"
+ depends on MFD_CROS_EC || COMPILE_TEST
+ select CEC_CORE
+ select CEC_NOTIFIER
+ ---help---
+ If you say yes here you will get support for the
+ ChromeOS Embedded Controller's CEC.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..830696f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
qcom/camss-8x16/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
obj-y += meson/
+
+obj-y += cros-ec-cec/
diff --git a/drivers/media/platform/cros-ec-cec/Makefile
b/drivers/media/platform/cros-ec-cec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
new file mode 100644
index 000..7f897a2
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,347 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for ChromeOS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rx_msg: storage for a received message
+ */
+struct cros_ec_cec {
+ struct cros_ec_device *cros_ec;
+ struct notifier_block notifier;
+ struct cec_adapter *adap;
+ struct cec_notifier *notify;
+ struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+ unsigned int len = cros_ec->event_size;
+
+ cros_ec_cec->rx_msg.len = len;
+ memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+ cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint32_t events = cros_ec->event_data.data.cec_events;
+
+ if (events & EC_MKBP_CEC_SEND_OK)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_OK);
+
+ /* FW takes care of all retries, tell core to avoid more retries */
+ if (events & EC_MKBP_CEC_SEND_FAILED)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_device *cros_ec;
+
+ cros_ec_cec = container_of(nb, struct cros_ec_cec, notifier);
+ cros_ec
Re: [Intel-gfx] [PATCH 4/9] drm: Begin an API for in-kernel clients
On Wed, May 23, 2018 at 11:45:00PM +0200, Thomas Hellstrom wrote: > Hi, Noralf. > > A couple of issues below: > > On 05/23/2018 04:34 PM, Noralf Trønnes wrote: > > This the beginning of an API for in-kernel clients. > > First out is a way to get a framebuffer backed by a dumb buffer. > > > > Only GEM drivers are supported. > > The original idea of using an exported dma-buf was dropped because it > > also creates an anonomous file descriptor which doesn't work when the > > buffer is created from a kernel thread. The easy way out is to use > > drm_driver.gem_prime_vmap to get the virtual address, which requires a > > GEM object. This excludes the vmwgfx driver which is the only non-GEM > > driver apart from the legacy ones. A solution for vmwgfx will have to be > > worked out later if it wants to support the client API which it probably > > will when we have a bootsplash client. > > Couldn't you add vmap() and vunmap() to the dumb buffer API for in-kernel > use rather than using GEM directly? > > But the main issue is pinning. It looks like the buffers are going to be > vmapped() for a long time, which requires pinning, and that doesn't work for > some drivers when they bind the framebuffer to a plane, since that might > require pinning in another memory region and the vmap would have to be torn > down. Besides, buffer pinning should really be avoided if possible: > > Since we can't page-fault vmaps, and setting up / tearing down vmaps is > potentially an expensive operation, could we perhaps have a mapping api that > allows the driver to cache vmaps? > > vmap() // Indicates that we want to map a bo > begin_access() // Returns a virtual address which may vary between calls. > Allows access. A fast operation. Behind the lines pins / reserves the bo and > returns a cached vmap if the bo didn't move since last begin_access(), which > is the typical case. > end_access() // Disable access. Unpins / unreserves the bo. > vunmap_cached() //Indicates that the map is no longer needed. The driver can > release the cached map. > > The idea is that the API client would wrap all bo map accesses with > begin_access() end_access(), allowing for the bo to be moved in between. So originally my ideas for the cpu side dma-buf interfaces where all meant to handle this. But then the first implementations bothered with none of this, but instead expected that stuff is pinned, and vmap Just Works. Which yeah doesn't work for vmwgfx and is a pain in a few other cases. I agree it'd be nice to fix all this, but it's also not a problem that this patch set here started. And since it's all optional (and vmwgfx isn't even using the current fb helper code) I think it's reasonable to address this post-merge (if someone gets around to it ever). What we'd need is is a fallback for when vmap doesn't exist (for fbdev that probably means a vmalloc'ed buffer + manual uploads, because fbdev), plus making sure dma-buf implementations actually implement it. Wrt tying this to gem hooks: I don't think this should be needed, I thought we've discussed a way to get at the handle2fd logic without having to end up with an fd, but directly return the dma-buf instead. Then we could use the dma-buf vmap interfaces instead of the gem ones. But getting there means we need to rework all the dma-buf export functions to move the fd_install into core code, so it's possible to make it optional. Not difficult work, but I think not necessary for the first merged version either since fairly auxiliary. Also right now there's no demand for this, since vmwgfx isn't using the fb helpers (yet). But we do have a solid plan to remove the gem dependency at least. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 6/6] media: platform: Add ChromeOS EC CEC driver
On 24/05/18 10:55, Neil Armstrong wrote:
> The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> The controller will be tied to the HDMI CEC notifier by using the platform
> DMI Data and the i915 device name and connector name.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/Kconfig | 11 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/cros-ec-cec/Makefile | 1 +
> drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347
> +++
> 4 files changed, 361 insertions(+)
> create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
> create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8..bc37ecf 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>
> if CEC_PLATFORM_DRIVERS
>
> +config VIDEO_CROS_EC_CEC
> + tristate "ChromeOS EC CEC driver"
> + depends on MFD_CROS_EC || COMPILE_TEST
> + select CEC_CORE
> + select CEC_NOTIFIER
> + ---help---
> + If you say yes here you will get support for the
> + ChromeOS Embedded Controller's CEC.
> + The CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
> config VIDEO_MESON_AO_CEC
> tristate "Amlogic Meson AO CEC driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515d..830696f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) +=
> qcom/camss-8x16/
> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
> obj-y+= meson/
> +
> +obj-y+= cros-ec-cec/
> diff --git a/drivers/media/platform/cros-ec-cec/Makefile
> b/drivers/media/platform/cros-ec-cec/Makefile
> new file mode 100644
> index 000..9ce97f9
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
> diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> new file mode 100644
> index 000..7f897a2
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> @@ -0,0 +1,347 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CEC driver for ChromeOS Embedded Controller
> + *
> + * Copyright (c) 2018 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "cros-ec-cec"
> +
> +/**
> + * struct cros_ec_cec - Driver data for EC CEC
> + *
> + * @cros_ec: Pointer to EC device
> + * @notifier: Notifier info for responding to EC events
> + * @adap: CEC adapter
> + * @notify: CEC notifier pointer
> + * @rx_msg: storage for a received message
> + */
> +struct cros_ec_cec {
> + struct cros_ec_device *cros_ec;
> + struct notifier_block notifier;
> + struct cec_adapter *adap;
> + struct cec_notifier *notify;
> + struct cec_msg rx_msg;
> +};
> +
> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint8_t *cec_message = cros_ec->event_data.data.cec_message;
> + unsigned int len = cros_ec->event_size;
> +
> + cros_ec_cec->rx_msg.len = len;
> + memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
> +
> + cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
> +}
> +
> +static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint32_t events = cros_ec->event_data.data.cec_events;
> +
> + if (events & EC_MKBP_CEC_SEND_OK)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> + CEC_TX_STATUS_OK);
> +
> + /* FW takes care of all retries, tell core to avoid more retries */
> + if (events & EC_MKBP_CEC_SEND_FAILED)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> + CEC_TX_STATUS_MAX_RETRIES |
> + CEC_TX_STATUS_NACK);
> +}
> +
> +static int
Re: [Intel-gfx] [PATCH 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function
On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
> This is the first step in getting generic fbdev emulation.
> A drm_fb_helper_funcs.fb_probe function is added which uses the
> DRM client API to get a framebuffer backed by a dumb buffer.
>
> A transitional hack for tinydrm is needed in order to switch over all
> CMA helper drivers in a later patch. This hack will be removed when
> tinydrm moves to vmalloc buffers.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 164
>
> include/drm/drm_fb_helper.h | 26 +++
> 2 files changed, 190 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 2ee1eaa66188..444c2b4040ea 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -30,11 +30,13 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2928,6 +2930,168 @@ void drm_fb_helper_output_poll_changed(struct
> drm_device *dev)
> }
> EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
>
> +/* @user: 1=userspace, 0=fbcon */
> +static int drm_fbdev_fb_open(struct fb_info *info, int user)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> +
> + if (!try_module_get(fb_helper->dev->driver->fops->owner))
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> +static int drm_fbdev_fb_release(struct fb_info *info, int user)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> +
> + module_put(fb_helper->dev->driver->fops->owner);
> +
> + return 0;
> +}
Hm, I thought earlier versions of your patch series had this separately,
for everyone. What's the reasons for merging this into the fb_probe
implementation.
> +
> +/*
> + * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
> + * unregister_framebuffer() or fb_release().
> + */
> +static void drm_fbdev_fb_destroy(struct fb_info *info)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct fb_ops *fbops = NULL;
> +
> + DRM_DEBUG("\n");
> +
> + if (fb_helper->fbdev->fbdefio) {
> + fb_deferred_io_cleanup(fb_helper->fbdev);
> + fbops = fb_helper->fbdev->fbops;
> + }
> +
> + drm_fb_helper_fini(fb_helper);
> + drm_client_framebuffer_delete(fb_helper->buffer);
> + drm_client_free(fb_helper->client);
> + kfree(fb_helper);
> + kfree(fbops);
> +}
Hm, if we go with the idea that drm_clients could auto-unregister through
a callback, then I expect this will lead to some control inversion. But we
can fix that later on.
> +
> +static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct
> *vma)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> +
> + if (fb_helper->dev->driver->gem_prime_mmap)
> + return
> fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
> + else
> + return -ENODEV;
> +}
> +
> +static struct fb_ops drm_fbdev_fb_ops = {
> + /* No need to set owner, this module is already pinned by the driver. */
I'd still set it, means less thinking since more obviously correct.
> + DRM_FB_HELPER_DEFAULT_OPS,
> + .fb_open= drm_fbdev_fb_open,
> + .fb_release = drm_fbdev_fb_release,
> + .fb_destroy = drm_fbdev_fb_destroy,
> + .fb_mmap= drm_fbdev_fb_mmap,
> + .fb_read= drm_fb_helper_sys_read,
> + .fb_write = drm_fb_helper_sys_write,
> + .fb_fillrect= drm_fb_helper_sys_fillrect,
> + .fb_copyarea= drm_fb_helper_sys_copyarea,
> + .fb_imageblit = drm_fb_helper_sys_imageblit,
Hm, some drivers require the cfb versions of these. In practice I guess
there's not much of a difference really, at least on x86 and arm.
We might want to document that though.
> +};
> +
> +static struct fb_deferred_io drm_fbdev_defio = {
> + .delay = HZ / 20,
> + .deferred_io= drm_fb_helper_deferred_io,
> +};
> +
> +/*
> + * TODO: Remove this when tinydrm is converted to vmalloc buffers.
> + */
> +static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> + struct vm_area_struct *vma)
> +{
> + fb_deferred_io_mmap(info, vma);
> + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> +
> + return 0;
> +}
> +
Needs kerneldoc here.
> +int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,
> + struct drm_fb_helper_surface_size *sizes)
> +{
> + struct drm_client_dev *client = fb_helper->client;
> + struct drm_client_buffer *buffer;
> + struct drm_framebuffer *fb;
> + struct fb_info *fbi;
> + u32 format;
> + int ret;
> +
> + DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
> + sizes->surface_width, sizes->surface_height,
Re: [Intel-gfx] [PATCH v5 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
On 24/05/2018 11:11, Hans Verkuil wrote:
> On 24/05/18 10:54, Neil Armstrong wrote:
>> The EC can expose a CEC bus, this patch adds the CEC related definitions
>> needed by the cros-ec-cec driver.
>>
>> Signed-off-by: Neil Armstrong
>> Tested-by: Enric Balletbo i Serra
>> ---
>> include/linux/mfd/cros_ec_commands.h | 85
>>
>> 1 file changed, 85 insertions(+)
>>
>> diff --git a/include/linux/mfd/cros_ec_commands.h
>> b/include/linux/mfd/cros_ec_commands.h
>> index cc0768e..ea9646f 100644
>> --- a/include/linux/mfd/cros_ec_commands.h
>> +++ b/include/linux/mfd/cros_ec_commands.h
>> @@ -804,6 +804,8 @@ enum ec_feature_code {
>> EC_FEATURE_MOTION_SENSE_FIFO = 24,
>> /* EC has RTC feature that can be controlled by host commands */
>> EC_FEATURE_RTC = 27,
>> +/* EC supports CEC commands */
>> +EC_FEATURE_CEC = 35,
>> };
>>
>> #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
>> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
>> /* EC sent a sysrq command */
>> EC_MKBP_EVENT_SYSRQ = 6,
>>
>> +/* Notify the AP that something happened on CEC */
>> +EC_MKBP_CEC_EVENT = 8,
>> +
>> +/* Send an incoming CEC message to the AP */
>> +EC_MKBP_EVENT_CEC_MESSAGE = 9,
>> +
>> /* Number of MKBP events */
>> EC_MKBP_EVENT_COUNT,
>> };
>> @@ -2850,6 +2858,83 @@ struct ec_params_reboot_ec {
>>
>>
>> /*/
>> /*
>> + * HDMI CEC commands
>> + *
>> + * These commands are for sending and receiving message via HDMI CEC
>> + */
>> +#define MAX_CEC_MSG_LEN 16
>
> Can you rename this to EC_MAX_CEC_MSG_LEN? It is way too similar to the
> CEC_MAX_MSG_LEN defined in cec.h. Since this is a property of the EC hw/fw
> it makes sense to prefix it accordingly.
Yes, it will make sense.
>
>> +
>> +/* CEC message from the AP to be written on the CEC bus */
>> +#define EC_CMD_CEC_WRITE_MSG 0x00B8
>> +
>> +/**
>> + * struct ec_params_cec_write - Message to write to the CEC bus
>> + * @msg: message content to write to the CEC bus
>> + */
>> +struct ec_params_cec_write {
>> +uint8_t msg[MAX_CEC_MSG_LEN];
>> +} __packed;
>> +
>> +/* Set various CEC parameters */
>> +#define EC_CMD_CEC_SET 0x00BA
>> +
>> +/**
>> + * struct ec_params_cec_set - CEC parameters set
>> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
>> + * @enable: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable
>> CEC
>> + * or 1 to enable CEC functionnality
>> + * @address: in case cmd is CEC_CMD_LOGICAL_ADDRESS, this field encodes the
>> + * requested logical address between 0 and 15 or 0xff to unregister
>> + */
>> +struct ec_params_cec_set {
>> +uint8_t cmd; /* enum cec_command */
>> +union {
>> +uint8_t enable;
>> +uint8_t address;
>> +};
>> +} __packed;
>> +
>> +/* Read various CEC parameters */
>> +#define EC_CMD_CEC_GET 0x00BB
>> +
>> +/**
>> + * struct ec_params_cec_get - CEC parameters get
>> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
>> + */
>> +struct ec_params_cec_get {
>> +uint8_t cmd; /* enum cec_command */
>> +} __packed;
>> +
>> +/**
>> + * struct ec_response_cec_get - CEC parameters get response
>> + * @enable: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
>> + * disabled or 1 if CEC functionnality is enabled
>> + * @address: in case cmd was CEC_CMD_LOGICAL_ADDRESS, this will encode the
>> + * configured logical address between 0 and 15 or 0xff if unregistered
>> + */
>> +struct ec_response_cec_get {
>> +union {
>> +uint8_t enable;
>> +uint8_t address;
>> +};
>> +} __packed;
>> +
>> +/* CEC parameters command */
>> +enum cec_command {
>
> Same here: shouldn't all of this be prefixed with ec_ or EC_?
Exact, I will prefix them.
Thanks,
Neil
>
> Regards,
>
> Hans
>
>> +/* CEC reading, writing and events enable */
>> +CEC_CMD_ENABLE,
>> +/* CEC logical address */
>> +CEC_CMD_LOGICAL_ADDRESS,
>> +};
>> +
>> +/* Events from CEC to AP */
>> +enum mkbp_cec_event {
>> +EC_MKBP_CEC_SEND_OK = BIT(0),
>> +EC_MKBP_CEC_SEND_FAILED = BIT(1),
>> +};
>> +
>> +/*/
>> +/*
>> * Special commands
>> *
>> * These do not follow the normal rules for commands. See each command for
>>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] drm: Add generic fbdev emulation
On Wed, May 23, 2018 at 04:34:02PM +0200, Noralf Trønnes wrote: > This patchset adds generic fbdev emulation for drivers that supports GEM > based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An > API is begun to support in-kernel clients in general. > > The CMA helper drivers is moved as a whole over to this generic fbdev > emulation. I've added patches 8 and 9 to show where it's heading. > tinydrm will be the first driver to use the full emulation when it moves > to vmalloc buffers. The CMA helper drivers will be converted one by one > later. Yeah I think 8&9 are looking like the right direction. I tried to review them, but I bit harder to form an opinion without patch 10 to start making use of the new things. But this is all looking really neat. -Daniel > > This work is based on an idea[1] by Laurent Pinchart: > > Ideally I'd like to remove 100% of fbdev-related > code from drivers. This includes > - initialization and cleanup of fbdev helpers > - fbdev restore in last_close() > - forwarding of hotplug events to fbdev compatibility layer > > Noralf. > > [1] > https://lists.freedesktop.org/archives/dri-devel/2017-September/152612.html > > David Herrmann (1): > drm: provide management functions for drm_file > > Noralf Trønnes (8): > drm/file: Don't set master on in-kernel clients > drm: Make ioctls available for in-kernel clients > drm: Begin an API for in-kernel clients > drm/fb-helper: Add generic fbdev emulation .fb_probe function > drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap > drm/cma-helper: Use the generic fbdev emulation > drm/client: Add client callbacks > drm/fb-helper: Finish the generic fbdev emulation > > Documentation/gpu/drm-client.rst| 12 + > Documentation/gpu/index.rst | 1 + > drivers/gpu/drm/Makefile| 2 +- > drivers/gpu/drm/drm_client.c| 511 > > drivers/gpu/drm/drm_crtc_internal.h | 19 +- > drivers/gpu/drm/drm_debugfs.c | 7 + > drivers/gpu/drm/drm_drv.c | 9 + > drivers/gpu/drm/drm_dumb_buffers.c | 33 ++- > drivers/gpu/drm/drm_fb_cma_helper.c | 365 -- > drivers/gpu/drm/drm_fb_helper.c | 287 > drivers/gpu/drm/drm_file.c | 304 - > drivers/gpu/drm/drm_framebuffer.c | 42 +-- > drivers/gpu/drm/drm_internal.h | 2 + > drivers/gpu/drm/drm_ioctl.c | 4 +- > drivers/gpu/drm/drm_probe_helper.c | 3 + > drivers/gpu/drm/pl111/pl111_drv.c | 2 + > include/drm/drm_client.h| 146 +++ > include/drm/drm_device.h| 21 ++ > include/drm/drm_fb_cma_helper.h | 3 - > include/drm/drm_fb_helper.h | 33 +++ > 20 files changed, 1322 insertions(+), 484 deletions(-) > create mode 100644 Documentation/gpu/drm-client.rst > create mode 100644 drivers/gpu/drm/drm_client.c > create mode 100644 include/drm/drm_client.h > > -- > 2.15.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
On 24/05/18 10:54, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
>
> Signed-off-by: Neil Armstrong
> Tested-by: Enric Balletbo i Serra
> ---
> include/linux/mfd/cros_ec_commands.h | 85
>
> 1 file changed, 85 insertions(+)
>
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index cc0768e..ea9646f 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
> EC_FEATURE_MOTION_SENSE_FIFO = 24,
> /* EC has RTC feature that can be controlled by host commands */
> EC_FEATURE_RTC = 27,
> + /* EC supports CEC commands */
> + EC_FEATURE_CEC = 35,
> };
>
> #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
> /* EC sent a sysrq command */
> EC_MKBP_EVENT_SYSRQ = 6,
>
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
> /* Number of MKBP events */
> EC_MKBP_EVENT_COUNT,
> };
> @@ -2850,6 +2858,83 @@ struct ec_params_reboot_ec {
>
>
> /*/
> /*
> + * HDMI CEC commands
> + *
> + * These commands are for sending and receiving message via HDMI CEC
> + */
> +#define MAX_CEC_MSG_LEN 16
Can you rename this to EC_MAX_CEC_MSG_LEN? It is way too similar to the
CEC_MAX_MSG_LEN defined in cec.h. Since this is a property of the EC hw/fw
it makes sense to prefix it accordingly.
> +
> +/* CEC message from the AP to be written on the CEC bus */
> +#define EC_CMD_CEC_WRITE_MSG 0x00B8
> +
> +/**
> + * struct ec_params_cec_write - Message to write to the CEC bus
> + * @msg: message content to write to the CEC bus
> + */
> +struct ec_params_cec_write {
> + uint8_t msg[MAX_CEC_MSG_LEN];
> +} __packed;
> +
> +/* Set various CEC parameters */
> +#define EC_CMD_CEC_SET 0x00BA
> +
> +/**
> + * struct ec_params_cec_set - CEC parameters set
> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
> + * @enable: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable CEC
> + * or 1 to enable CEC functionnality
> + * @address: in case cmd is CEC_CMD_LOGICAL_ADDRESS, this field encodes the
> + * requested logical address between 0 and 15 or 0xff to unregister
> + */
> +struct ec_params_cec_set {
> + uint8_t cmd; /* enum cec_command */
> + union {
> + uint8_t enable;
> + uint8_t address;
> + };
> +} __packed;
> +
> +/* Read various CEC parameters */
> +#define EC_CMD_CEC_GET 0x00BB
> +
> +/**
> + * struct ec_params_cec_get - CEC parameters get
> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
> + */
> +struct ec_params_cec_get {
> + uint8_t cmd; /* enum cec_command */
> +} __packed;
> +
> +/**
> + * struct ec_response_cec_get - CEC parameters get response
> + * @enable: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
> + * disabled or 1 if CEC functionnality is enabled
> + * @address: in case cmd was CEC_CMD_LOGICAL_ADDRESS, this will encode the
> + * configured logical address between 0 and 15 or 0xff if unregistered
> + */
> +struct ec_response_cec_get {
> + union {
> + uint8_t enable;
> + uint8_t address;
> + };
> +} __packed;
> +
> +/* CEC parameters command */
> +enum cec_command {
Same here: shouldn't all of this be prefixed with ec_ or EC_?
Regards,
Hans
> + /* CEC reading, writing and events enable */
> + CEC_CMD_ENABLE,
> + /* CEC logical address */
> + CEC_CMD_LOGICAL_ADDRESS,
> +};
> +
> +/* Events from CEC to AP */
> +enum mkbp_cec_event {
> + EC_MKBP_CEC_SEND_OK = BIT(0),
> + EC_MKBP_CEC_SEND_FAILED = BIT(1),
> +};
> +
> +/*/
> +/*
> * Special commands
> *
> * These do not follow the normal rules for commands. See each command for
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
Reviewed-by: Hans Verkuil
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel_display.h | 20
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 13 +
4 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd9588..2d65d56 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,7 @@ config DRM_I915
select SYNC_FILE
select IOSF_MBI
select CRC32
+ select CEC_CORE if CEC_NOTIFIER
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
#define port_name(p) ((p) + 'A')
+static inline const char *port_identifier(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return "Port A";
+ case PORT_B:
+ return "Port B";
+ case PORT_C:
+ return "Port C";
+ case PORT_D:
+ return "Port D";
+ case PORT_E:
+ return "Port E";
+ case PORT_F:
+ return "Port F";
+ default:
+ return "";
+ }
+}
+
enum dpio_channel {
DPIO_CH0,
DPIO_CH1
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
/**
* __wait_for - magic wait macro
@@ -1001,6 +1002,7 @@ struct intel_hdmi {
bool has_audio;
bool rgb_quant_range_selectable;
struct intel_connector *attached_connector;
+ struct cec_notifier *notifier;
};
struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1baef4a..d522b5b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
connected = true;
}
+ cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
+
return connected;
}
@@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
{
enum drm_connector_status status;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
@@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
+ if (status != connector_status_connected)
+ cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
+
return status;
}
@@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder,
static void intel_hdmi_destroy(struct drm_connector *connector)
{
+ if (intel_attached_hdmi(connector)->notifier)
+ cec_notifier_put(intel_attached_hdmi(connector)->notifier);
kfree(to_intel_connector(connector)->detect_edid);
drm_connector_cleanup(connector);
kfree(connector);
@@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
+
+ intel_hdmi->notifier = cec_notifier_get_conn(dev->dev,
+port_identifier(port));
+ if (!intel_hdmi->notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function
On Thu, May 24, 2018 at 11:16:05AM +0200, Daniel Vetter wrote:
> On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
> > +int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,
> > + struct drm_fb_helper_surface_size *sizes)
> > +{
> > + struct drm_client_dev *client = fb_helper->client;
> > + struct drm_client_buffer *buffer;
> > + struct drm_framebuffer *fb;
> > + struct fb_info *fbi;
> > + u32 format;
> > + int ret;
> > +
> > + DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
> > + sizes->surface_width, sizes->surface_height,
> > + sizes->surface_bpp);
> > +
> > + format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> > sizes->surface_depth);
> > + buffer = drm_client_framebuffer_create(client, sizes->surface_width,
> > + sizes->surface_height, format);
> > + if (IS_ERR(buffer))
> > + return PTR_ERR(buffer);
> > +
> > + fb_helper->buffer = buffer;
> > + fb_helper->fb = buffer->fb;
> > + fb = buffer->fb;
> > +
> > + fbi = drm_fb_helper_alloc_fbi(fb_helper);
> > + if (IS_ERR(fbi)) {
> > + ret = PTR_ERR(fbi);
> > + goto err_free_buffer;
> > + }
> > +
> > + fbi->par = fb_helper;
> > + fbi->fbops = &drm_fbdev_fb_ops;
> > + fbi->screen_size = fb->height * fb->pitches[0];
> > + fbi->fix.smem_len = fbi->screen_size;
> > + fbi->screen_buffer = buffer->vaddr;
> > + strcpy(fbi->fix.id, "DRM emulated");
> > +
> > + drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
> > + drm_fb_helper_fill_var(fbi, fb_helper, sizes->fb_width,
> > sizes->fb_height);
> > +
> > + if (fb->funcs->dirty) {
> > + struct fb_ops *fbops;
> > +
> > + /*
> > +* fb_deferred_io_cleanup() clears &fbops->fb_mmap so a per
> > +* instance version is necessary.
> > +*/
> > + fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> > + if (!fbops) {
> > + ret = -ENOMEM;
> > + goto err_fb_info_destroy;
> > + }
> > +
> > + *fbops = *fbi->fbops;
> > + fbi->fbops = fbops;
> > +
> > + fbi->fbdefio = &drm_fbdev_defio;
> > +
> > + /* TODO: Remove this when tinydrm is converted to vmalloc
> > buffers. */
> > + fbi->fix.smem_start = page_to_phys(virt_to_page(buffer->vaddr));
> > +
> > + fb_deferred_io_init(fbi);
> > +
> > + /* TODO: Remove this when tinydrm is converted to vmalloc
> > buffers. */
> > + fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
> > + }
>
> Ugh. Yeah defio and generic allocator through dumb buffers don't mix well.
> The only true generic solution for this would be to give userspace (and
> only userspace, for fbcon we can intercept everything) a staging buffer,
> and then upload things using the dirty callback.
>
> But that introduces another copy step, so isn't cool.
>
> I think a check for is_vmalloc_addr and if that's false, not doing any of
> the defio mmap setup would be good. Until we have a better idea. And yes
> that would need to be done after tinydrm is moved over.
Looking at the cma conversion patch, this stuff here is actually required.
Or we'll break cma. I think your TODO comments need to be adjusted to
reflect that.
There's also the problem of how to handle the wc vs cached memory issue,
we might need more flags for that.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/9] drm/client: Add client callbacks
On Wed, May 23, 2018 at 04:34:10PM +0200, Noralf Trønnes wrote:
> Add client callbacks and hook them up.
> Add a list of clients per drm_device.
Patch nit, but I think the debugfs stuff would be nice if split out.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_client.c| 246
> +++-
> drivers/gpu/drm/drm_debugfs.c | 7 +
> drivers/gpu/drm/drm_drv.c | 8 ++
> drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> drivers/gpu/drm/drm_file.c | 3 +
> drivers/gpu/drm/drm_probe_helper.c | 3 +
> include/drm/drm_client.h| 65 +-
> include/drm/drm_device.h| 14 ++
> 8 files changed, 345 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 0919aea7..c495fcee2058 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -66,11 +66,13 @@ static void drm_client_free_file(struct drm_client_dev
> *client)
> /**
> * drm_client_new - Create a DRM client
> * @dev: DRM device
> + * @funcs: DRM client functions
> *
> * Returns:
> * Pointer to a client or an error pointer on failure.
> */
> -struct drm_client_dev *drm_client_new(struct drm_device *dev)
> +struct drm_client_dev *
> +drm_client_new(struct drm_device *dev, const struct drm_client_funcs *funcs)
> {
> struct drm_client_dev *client;
> int ret;
> @@ -84,6 +86,7 @@ struct drm_client_dev *drm_client_new(struct drm_device
> *dev)
> return ERR_PTR(-ENOMEM);
>
> client->dev = dev;
> + client->funcs = funcs;
>
> ret = drm_client_alloc_file(client);
> if (ret) {
> @@ -91,21 +94,231 @@ struct drm_client_dev *drm_client_new(struct drm_device
> *dev)
> return ERR_PTR(ret);
> }
>
> + /*
> + * TODO:
> + * Temporary hack until all CMA drivers have been moved over to using
> + * drm_fbdev_generic_setup().
> + */
I think clients without callbacks make perfect sense, imo no need for a
TODO. Just explain in the kernel-doc that the callbacks are optional.
> + if (!funcs)
> + return client;
> +
> + mutex_lock(&dev->clientlist_mutex);
> + list_add(&client->list, &dev->clientlist);
> + mutex_unlock(&dev->clientlist_mutex);
> +
> return client;
> }
> EXPORT_SYMBOL(drm_client_new);
>
> +/**
> + * drm_client_new_from_id - Create a DRM client from a minor id
> + * @minor_id: DRM minor id
> + * @funcs: DRM client functions
> + *
> + * Returns:
> + * Pointer to a client or an error pointer on failure.
> + */
> +struct drm_client_dev *
> +drm_client_new_from_id(unsigned int minor_id, const struct drm_client_funcs
> *funcs)
> +{
> + struct drm_client_dev *client;
> + struct drm_minor *minor;
> +
> + minor = drm_minor_acquire(minor_id);
> + if (IS_ERR(minor))
> + return ERR_CAST(minor);
> +
> + client = drm_client_new(minor->dev, funcs);
> +
> + drm_minor_release(minor);
> +
> + return client;
> +}
> +EXPORT_SYMBOL(drm_client_new_from_id);
I don't get why we need this new function ...
> +
> /**
> * drm_client_free - Free DRM client resources
> * @client: DRM client
> + *
> + * This is called automatically on client removal unless the client returns
> + * non-zero in the &drm_client_funcs->remove callback. The fbdev client does
> + * this when it can't close &drm_file because userspace has an open fd.
> + *
> + * Note:
> + * If the client can't release it's resources on remove, it needs to hold a
> + * reference on the driver module to prevent the code from going away.
We need a full reference on the drm_device I think, not just the code. I
thought drm_file provides that for any drm_client?
> */
> void drm_client_free(struct drm_client_dev *client)
> {
> + DRM_DEV_DEBUG_KMS(client->dev->dev, "\n");
Both above bits probably should be in the patch that introduces these?
> drm_client_free_file(client);
> kfree(client);
> }
> EXPORT_SYMBOL(drm_client_free);
>
> +static void drm_client_remove_locked(struct drm_client_dev *client)
> +{
> + list_del(&client->list);
> +
> + if (!client->funcs->remove || !client->funcs->remove(client))
> + drm_client_free(client);
Ugh, I don't like this semantics of ->remove. Imo you really only want an
->unregister here, an _not want to automatically free the client.
Automaticlly freeing the client prevents embedded, and all around smells a
bit like midlayer mistake.
Without the automatic freeing you also don't need the return value, and
you can have a more standard void return type for your unregister
function.
We might need to make sure the drm_dev_unregister doesn't free up the
drm_device while we do that, so might need a temporary reference. But I
don't think we need anything else to avoid locking headaches.
> +}
> +
> +static void drm_client_remove_safe(struct drm_device *dev,
> +
Re: [Intel-gfx] [PATCH v6 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
On 24/05/18 11:57, Neil Armstrong wrote:
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
>
> Signed-off-by: Neil Armstrong
> Tested-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
> include/linux/mfd/cros_ec_commands.h | 81
>
> 1 file changed, 81 insertions(+)
>
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index cc0768e..fe33a81 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
> EC_FEATURE_MOTION_SENSE_FIFO = 24,
> /* EC has RTC feature that can be controlled by host commands */
> EC_FEATURE_RTC = 27,
> + /* EC supports CEC commands */
> + EC_FEATURE_CEC = 35,
> };
>
> #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
> /* EC sent a sysrq command */
> EC_MKBP_EVENT_SYSRQ = 6,
>
> + /* Notify the AP that something happened on CEC */
> + EC_MKBP_EVENT_CEC_EVENT = 8,
> +
> + /* Send an incoming CEC message to the AP */
> + EC_MKBP_EVENT_CEC_MESSAGE = 9,
> +
> /* Number of MKBP events */
> EC_MKBP_EVENT_COUNT,
> };
> @@ -2850,6 +2858,79 @@ struct ec_params_reboot_ec {
>
>
> /*/
> /*
> + * HDMI CEC commands
> + *
> + * These commands are for sending and receiving message via HDMI CEC
> + */
> +#define EC_MAX_CEC_MSG_LEN 16
> +
> +/* CEC message from the AP to be written on the CEC bus */
> +#define EC_CMD_CEC_WRITE_MSG 0x00B8
> +
> +/**
> + * struct ec_params_cec_write - Message to write to the CEC bus
> + * @msg: message content to write to the CEC bus
> + */
> +struct ec_params_cec_write {
> + uint8_t msg[EC_MAX_CEC_MSG_LEN];
> +} __packed;
> +
> +/* Set various CEC parameters */
> +#define EC_CMD_CEC_SET 0x00BA
> +
> +/**
> + * struct ec_params_cec_set - CEC parameters set
> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
> + * @val: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable CEC
> + * or 1 to enable CEC functionnality, in case cmd is
> CEC_CMD_LOGICAL_ADDRESS,
> + * this field encodes the requested logical address between 0 and 15
> + * or 0xff to unregister
> + */
> +struct ec_params_cec_set {
> + uint8_t cmd; /* enum cec_command */
> + uint8_t val;
> +} __packed;
> +
> +/* Read various CEC parameters */
> +#define EC_CMD_CEC_GET 0x00BB
> +
> +/**
> + * struct ec_params_cec_get - CEC parameters get
> + * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
> + */
> +struct ec_params_cec_get {
> + uint8_t cmd; /* enum cec_command */
> +} __packed;
> +
> +/**
> + * struct ec_response_cec_get - CEC parameters get response
> + * @val: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
> + * disabled or 1 if CEC functionnality is enabled,
> + * in case cmd was CEC_CMD_LOGICAL_ADDRESS, this will encode the
> + * configured logical address between 0 and 15 or 0xff if unregistered
> + */
> +struct ec_response_cec_get {
> + uint8_t val;
> +} __packed;
> +
> +/* CEC parameters command */
> +enum ec_cec_command {
> + /* CEC reading, writing and events enable */
> + CEC_CMD_ENABLE,
> + /* CEC logical address */
> + CEC_CMD_LOGICAL_ADDRESS,
> +};
> +
> +/* Events from CEC to AP */
> +enum mkbp_cec_event {
> + /* Outgoing message was acknowledged by a follower */
> + EC_MKBP_CEC_SEND_OK = BIT(0),
> + /* Outgoing message was not acknowledged */
> + EC_MKBP_CEC_SEND_FAILED = BIT(1),
> +};
> +
> +/*/
> +/*
> * Special commands
> *
> * These do not follow the normal rules for commands. See each command for
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/6] mfd: cros-ec: Increase maximum mkbp event size
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
---
drivers/platform/chrome/cros_ec_proto.c | 40 +
include/linux/mfd/cros_ec.h | 2 +-
include/linux/mfd/cros_ec_commands.h| 19
3 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_proto.c
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..c4f6c44 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
+static int get_next_event_xfer(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg,
+ int version, uint32_t size)
+{
+ int ret;
+
+ msg->version = version;
+ msg->command = EC_CMD_GET_NEXT_EVENT;
+ msg->insize = size;
+ msg->outsize = 0;
+
+ ret = cros_ec_cmd_xfer(ec_dev, msg);
+ if (ret > 0) {
+ ec_dev->event_size = ret - 1;
+ memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
+ }
+
+ return ret;
+}
+
static int get_next_event(struct cros_ec_device *ec_dev)
{
u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
+ static int cmd_version = 1;
int ret;
if (ec_dev->suspended) {
@@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
return -EHOSTDOWN;
}
- msg->version = 0;
- msg->command = EC_CMD_GET_NEXT_EVENT;
- msg->insize = sizeof(ec_dev->event_data);
- msg->outsize = 0;
+ if (cmd_version == 1) {
+ ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event_v1));
+ if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
+ return ret;
- ret = cros_ec_cmd_xfer(ec_dev, msg);
- if (ret > 0) {
- ec_dev->event_size = ret - 1;
- memcpy(&ec_dev->event_data, msg->data,
- sizeof(ec_dev->event_data));
+ /* Fallback to version 0 for future send attempts */
+ cmd_version = 0;
}
+ ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event));
+
return ret;
}
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index f36125e..32caef3 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -147,7 +147,7 @@ struct cros_ec_device {
bool mkbp_event_supported;
struct blocking_notifier_head event_notifier;
- struct ec_response_get_next_event event_data;
+ struct ec_response_get_next_event_v1 event_data;
int event_size;
u32 host_event_wake_mask;
};
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index f2edd99..cc0768e 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
uint32_t sysrq;
} __packed;
+union ec_response_get_next_data_v1 {
+ uint8_t key_matrix[16];
+
+ /* Unaligned */
+ uint32_t host_event;
+
+ uint32_t buttons;
+ uint32_t switches;
+ uint32_t sysrq;
+ uint32_t cec_events;
+ uint8_tcec_message[16];
+} __packed;
+
struct ec_response_get_next_event {
uint8_t event_type;
/* Followed by event data if any */
union ec_response_get_next_data data;
} __packed;
+struct ec_response_get_next_event_v1 {
+ uint8_t event_type;
+ /* Followed by event data if any */
+ union ec_response_get_next_data_v1 data;
+} __packed;
+
/* Bit indices for buttons and switches.*/
/* Buttons */
#define EC_MKBP_POWER_BUTTON 0
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 7/7] drm/i915: add a sysfs entry to let users set sseu configs
On 24/05/18 11:39, Tvrtko Ursulin wrote:
On 23/05/2018 18:33, Lionel Landwerlin wrote:
On 23/05/18 16:30, Tvrtko Ursulin wrote:
On 22/05/2018 19:00, Lionel Landwerlin wrote:
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +++
drivers/gpu/drm/i915/i915_gem_context.c | 52
-
drivers/gpu/drm/i915/i915_sysfs.c | 30 ++
3 files changed, 86 insertions(+), 1 deletion(-)
[snip]
} contexts;
u32 fdi_rx_config;
@@ -3274,6 +3276,9 @@ i915_gem_context_lookup(struct
drm_i915_file_private *file_priv, u32 id)
return ctx;
}
+int i915_gem_contexts_set_allow_sseu(struct drm_i915_private
*dev_priv, bool allowed);
+bool i915_gem_contexts_get_allow_sseu(struct drm_i915_private
*dev_priv);
+
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5c5a12f1c265..815a9d1c29f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -981,7 +981,8 @@ int i915_gem_context_setparam_ioctl(struct
drm_device *dev, void *data,
break;
}
- if (!capable(CAP_SYS_ADMIN)) {
+ if (!dev_priv->contexts.allow_sseu &&
+ !capable(CAP_SYS_ADMIN)) {
So the thing I mentioned in the previous patch. My thinking was not
to fail it if sysfs toggle is disabled, but just don't do dynamic
switching. That way the software stack works in all cases but user
has the option of tuning his system.
I mean it can still be done but in userspace. Set param fails,
userspace goes for a fall back.
Only difference is I guess whether it is useful to allow switching
at runtime. I am imagining running some 3d and media, and then
toggling the knob to see what happens to power and performance on
the fly. But maybe that is not so interesting.
Along the same lines I was thinking CAP_SYS_ADMIN limitation could
be dropped.
Both points are for a wider discussion I guess.
Okay, let's get Dmitry input on this.
To expand, my thinking is to let media stack configure its contexts
for fewer slices, but let the user/sysadmin decide whether 3d/compute
performance is more important, or media.
Downside is that with this approach you would have to re-configure all
contexts when sysfs toggle is changed from zero to one.
[snip]
Not an issue for me.
Only concern is whether this might make things easier to debug/spot when
sseu configuration requests are silently discarded.
+
+ /*
+ * When we allow each context to configure its powergating
+ * configuration, there is no need to put the configurations
back to
+ * the default, it should already be the case.
+ */
+ if (!allowed) {
+ union intel_sseu default_sseu =
+ intel_sseu_from_device_sseu(&INTEL_INFO(dev_priv)->sseu);
+ struct i915_gem_context *ctx;
+
+ list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
+ ret = i915_gem_context_reconfigure_sseu(ctx, engine,
+ default_sseu);
+ if (ret)
+ break;
+ }
+ }
+
+ dev_priv->contexts.allow_sseu = allowed;
+
+ mutex_unlock(&dev_priv->drm.struct_mutex);
+ return ret;
+}
+
+bool i915_gem_contexts_get_allow_sseu(struct drm_i915_private
*dev_priv)
+{
+ struct intel_engine_cs *engine = dev_priv->engine[RCS];
+ bool ret;
+
+ if (!engine->emit_rpcs_config)
+ return false;
+
+ mutex_lock(&dev_priv->drm.struct_mutex);
+ ret = dev_priv->contexts.allow_sseu;
+ mutex_unlock(&dev_priv->drm.struct_mutex);
I guess this mutex does nothing in this case.
Yeah, I'm not sure whether I can read a boolean or whether it should
be an atomic...
You can just read a boolean.
+ return ret;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_context.c"
#include "selftests/i915_gem_context.c"
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index e5e6f6bb2b05..9fd15b138ac9 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -483,6 +483,34 @@ static ssize_t gt_rp_mhz_show(struct device
*kdev, struct device_attribute *attr
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
+static ssize_t gem_allow_sseu_show(struct device *kdev,
+ struct device_attribute *attr, char *buf)
+{
+ struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
+ int ret = i915_gem_con
[Intel-gfx] [PATCH v6 1/6] media: cec-notifier: Get notifier by device and connector name
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at least 2 HDMI connectors, this patch also
adds the possibility to add a connector name tied to the notifier device
to form a tuple and associate different CEC controllers for each HDMI
connectors.
Signed-off-by: Neil Armstrong
Reviewed-by: Hans Verkuil
---
drivers/media/cec/cec-notifier.c | 11 ---
include/media/cec-notifier.h | 27 ---
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 16dffa0..dd2078b 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -21,6 +21,7 @@ struct cec_notifier {
struct list_head head;
struct kref kref;
struct device *dev;
+ const char *conn;
struct cec_adapter *cec_adap;
void (*callback)(struct cec_adapter *adap, u16 pa);
@@ -30,13 +31,14 @@ struct cec_notifier {
static LIST_HEAD(cec_notifiers);
static DEFINE_MUTEX(cec_notifiers_lock);
-struct cec_notifier *cec_notifier_get(struct device *dev)
+struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
*conn)
{
struct cec_notifier *n;
mutex_lock(&cec_notifiers_lock);
list_for_each_entry(n, &cec_notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(&n->kref);
mutex_unlock(&cec_notifiers_lock);
return n;
@@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
if (!n)
goto unlock;
n->dev = dev;
+ if (conn)
+ n->conn = kstrdup(conn, GFP_KERNEL);
n->phys_addr = CEC_PHYS_ADDR_INVALID;
mutex_init(&n->lock);
kref_init(&n->kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(&cec_notifiers_lock);
return n;
}
-EXPORT_SYMBOL_GPL(cec_notifier_get);
+EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
static void cec_notifier_release(struct kref *kref)
{
@@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
container_of(kref, struct cec_notifier, kref);
list_del(&n->head);
+ kfree(n->conn);
kfree(n);
}
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index cf0add7..814eeef 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -20,8 +20,10 @@ struct cec_notifier;
#if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
/**
- * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * cec_notifier_get_conn - find or create a new cec_notifier for the given
+ * device and connector tuple.
* @dev: device that sends the events.
+ * @conn: the connector name from which the event occurs
*
* If a notifier for device @dev already exists, then increase the refcount
* and return that notifier.
@@ -31,7 +33,8 @@ struct cec_notifier;
*
* Return NULL if the memory could not be allocated.
*/
-struct cec_notifier *cec_notifier_get(struct device *dev);
+struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+ const char *conn);
/**
* cec_notifier_put - decrease refcount and delete when the refcount reaches 0.
@@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
struct cec_notifier *notifier);
#else
-static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+const char *conn)
{
/* A non-NULL pointer is expected on success */
return (struct cec_notifier *)0xdeadfeed;
@@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct
cec_adapter *adap,
#endif
/**
+ * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * @dev: device that sends the events.
+ *
+ * If a notifier for device @dev already exists, then increase the refcount
+ * and return that notifier.
+ *
+ * If it doesn't exist, then allocate a new notifier struct and return a
+ * pointer to that new struct.
+ *
+ * Return NULL if the memory could not be allocated.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
*
* @n: the CEC notifier
--
2.7.4
___
Intel-g
Re: [Intel-gfx] [PATCH v6 6/7] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 24/05/18 11:43, Tvrtko Ursulin wrote: + + /* + * Mask of slices to enable for the context. Valid values are a subset + * of the bitmask value returned for I915_PARAM_SLICE_MASK. + */ + __u8 slice_mask; + + /* + * Mask of subslices to enable for the context. Valid values are a + * subset of the bitmask value return by I915_PARAM_SUBSLICE_MASK. + */ + __u8 subslice_mask; Is this future proof enough, say for Gen11? As far as I can see, this fits. No objection to bump it to 16/32bits if you'd like. Feel like I've asked you this before, sorry - nothing in the future will need per slice subslice mask? As far as I can see this remains the same uniform subslice per slice programming style. We could play it safe and put all the masks in 64bits in the uAPI. What do you think? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 1d6dc5c..272969e 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev
*ec)
kfree(msg);
}
+static const struct mfd_cell cros_ec_cec_cells[] = {
+ { .name = "cros-ec-cec" }
+};
+
static const struct mfd_cell cros_ec_rtc_cells[] = {
{ .name = "cros-ec-rtc" }
};
@@ -426,6 +430,18 @@ static int ec_device_probe(struct platform_device *pdev)
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
cros_ec_sensors_register(ec);
+ /* Check whether this EC instance has CEC host command support */
+ if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
+ retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
+cros_ec_cec_cells,
+ARRAY_SIZE(cros_ec_cec_cells),
+NULL, 0, NULL);
+ if (retval)
+ dev_err(ec->dev,
+ "failed to add cros-ec-cec device: %d\n",
+ retval);
+ }
+
/* Check whether this EC instance has RTC host command support */
if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/6] media: cec-notifier: Get notifier by device and connector name
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at least 2 HDMI connectors, this patch also
adds the possibility to add a connector name tied to the notifier device
to form a tuple and associate different CEC controllers for each HDMI
connectors.
Signed-off-by: Neil Armstrong
---
drivers/media/cec/cec-notifier.c | 11 ---
include/media/cec-notifier.h | 27 ---
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 16dffa0..dd2078b 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -21,6 +21,7 @@ struct cec_notifier {
struct list_head head;
struct kref kref;
struct device *dev;
+ const char *conn;
struct cec_adapter *cec_adap;
void (*callback)(struct cec_adapter *adap, u16 pa);
@@ -30,13 +31,14 @@ struct cec_notifier {
static LIST_HEAD(cec_notifiers);
static DEFINE_MUTEX(cec_notifiers_lock);
-struct cec_notifier *cec_notifier_get(struct device *dev)
+struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
*conn)
{
struct cec_notifier *n;
mutex_lock(&cec_notifiers_lock);
list_for_each_entry(n, &cec_notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(&n->kref);
mutex_unlock(&cec_notifiers_lock);
return n;
@@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
if (!n)
goto unlock;
n->dev = dev;
+ if (conn)
+ n->conn = kstrdup(conn, GFP_KERNEL);
n->phys_addr = CEC_PHYS_ADDR_INVALID;
mutex_init(&n->lock);
kref_init(&n->kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(&cec_notifiers_lock);
return n;
}
-EXPORT_SYMBOL_GPL(cec_notifier_get);
+EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
static void cec_notifier_release(struct kref *kref)
{
@@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
container_of(kref, struct cec_notifier, kref);
list_del(&n->head);
+ kfree(n->conn);
kfree(n);
}
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index cf0add7..814eeef 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -20,8 +20,10 @@ struct cec_notifier;
#if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
/**
- * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * cec_notifier_get_conn - find or create a new cec_notifier for the given
+ * device and connector tuple.
* @dev: device that sends the events.
+ * @conn: the connector name from which the event occurs
*
* If a notifier for device @dev already exists, then increase the refcount
* and return that notifier.
@@ -31,7 +33,8 @@ struct cec_notifier;
*
* Return NULL if the memory could not be allocated.
*/
-struct cec_notifier *cec_notifier_get(struct device *dev);
+struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+ const char *conn);
/**
* cec_notifier_put - decrease refcount and delete when the refcount reaches 0.
@@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
struct cec_notifier *notifier);
#else
-static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+const char *conn)
{
/* A non-NULL pointer is expected on success */
return (struct cec_notifier *)0xdeadfeed;
@@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct
cec_adapter *adap,
#endif
/**
+ * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * @dev: device that sends the events.
+ *
+ * If a notifier for device @dev already exists, then increase the refcount
+ * and return that notifier.
+ *
+ * If it doesn't exist, then allocate a new notifier struct and return a
+ * pointer to that new struct.
+ *
+ * Return NULL if the memory could not be allocated.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
*
* @n: the CEC notifier
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@l
Re: [Intel-gfx] [PATCH 4/9] drm: Begin an API for in-kernel clients
On Thu, May 24, 2018 at 11:25:04AM +0200, Thomas Hellstrom wrote: > On 05/24/2018 10:32 AM, Daniel Vetter wrote: > > On Wed, May 23, 2018 at 11:45:00PM +0200, Thomas Hellstrom wrote: > > > Hi, Noralf. > > > > > > A couple of issues below: > > > > > > On 05/23/2018 04:34 PM, Noralf Trønnes wrote: > > > > This the beginning of an API for in-kernel clients. > > > > First out is a way to get a framebuffer backed by a dumb buffer. > > > > > > > > Only GEM drivers are supported. > > > > The original idea of using an exported dma-buf was dropped because it > > > > also creates an anonomous file descriptor which doesn't work when the > > > > buffer is created from a kernel thread. The easy way out is to use > > > > drm_driver.gem_prime_vmap to get the virtual address, which requires a > > > > GEM object. This excludes the vmwgfx driver which is the only non-GEM > > > > driver apart from the legacy ones. A solution for vmwgfx will have to be > > > > worked out later if it wants to support the client API which it probably > > > > will when we have a bootsplash client. > > > Couldn't you add vmap() and vunmap() to the dumb buffer API for in-kernel > > > use rather than using GEM directly? > > > > > > But the main issue is pinning. It looks like the buffers are going to be > > > vmapped() for a long time, which requires pinning, and that doesn't work > > > for > > > some drivers when they bind the framebuffer to a plane, since that might > > > require pinning in another memory region and the vmap would have to be > > > torn > > > down. Besides, buffer pinning should really be avoided if possible: > > > > > > Since we can't page-fault vmaps, and setting up / tearing down vmaps is > > > potentially an expensive operation, could we perhaps have a mapping api > > > that > > > allows the driver to cache vmaps? > > > > > > vmap() // Indicates that we want to map a bo > > > begin_access() // Returns a virtual address which may vary between calls. > > > Allows access. A fast operation. Behind the lines pins / reserves the bo > > > and > > > returns a cached vmap if the bo didn't move since last begin_access(), > > > which > > > is the typical case. > > > end_access() // Disable access. Unpins / unreserves the bo. > > > vunmap_cached() //Indicates that the map is no longer needed. The driver > > > can > > > release the cached map. > > > > > > The idea is that the API client would wrap all bo map accesses with > > > begin_access() end_access(), allowing for the bo to be moved in between. > > So originally my ideas for the cpu side dma-buf interfaces where all meant > > to handle this. But then the first implementations bothered with none of > > this, but instead expected that stuff is pinned, and vmap Just Works. > > > > Which yeah doesn't work for vmwgfx and is a pain in a few other cases. > > > > I agree it'd be nice to fix all this, but it's also not a problem that > > this patch set here started. And since it's all optional (and vmwgfx isn't > > even using the current fb helper code) I think it's reasonable to address > > this post-merge (if someone gets around to it ever). What we'd need is is > > a fallback for when vmap doesn't exist (for fbdev that probably means a > > vmalloc'ed buffer + manual uploads, because fbdev), plus making sure > > dma-buf implementations actually implement it. > > My argument here is that, If I understand Noralf, this is intended to be an > API exported outside of drm. In that case we shouldn't replicate the assumed > behaviour of incomplete dma-buf implementations in a new API. Also the fact > that vmwgfx currently isn't using the fbdev helpers isn't a good argument to > design an API so that vmwgfx can _never_ use the fbdev helpers. The reason > we aren't using them is that the kms implementation was so old that we > didn't implement the necessary helper callbacks... > > Also, I might be misunderstanding the code a bit, but I doubt that vmwgfx is > the only hardware with pinning restrictions on the framebuffer? I was under > the assumption that most discrete hardware required the framebuffer to be > pinned in VRAM? > > So the important question is, Is this a set of helpers for shared-memory GEM > drivers to implement fbdev? Then I wouldn't bother, If it's intended to > become an API for clients outside of DRM, then I would have to insist on the > API being changed to reflect that. This is definitely not an api for anything outside of drm. Just an attempt to consolidate kernel-internal drm access like fbdev, a simple bootsplash or an emergency console would need to do. Having some limitations in the initial versions, as long as we have some idea how to handle them, seems perfectly fine to me. This isn't meant to be a mandatory replacement for anything - no intentions of exporting this to userspace. And yes the pinning aspect is really ugly, but that's by far not the only annoying aspect of trying to emulate fbdev on top of kms. defio handling is another really problemat
Re: [Intel-gfx] [PATCH v6 4/7] drm/i915/perf: reuse intel_lrc ctx regs macro
On 23/05/2018 16:54, Lionel Landwerlin wrote:
On 23/05/18 15:57, Tvrtko Ursulin wrote:
On 22/05/2018 18:59, Lionel Landwerlin wrote:
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index 805dfc732bba..a5d98bda5c2e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k and 16M,
though driver
* is currently generally designed assuming the largest 16M size is
used such
@@ -1579,27 +1580,25 @@ static void
gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] =
i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
- (dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
- GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
- for (i = 0; i < ARRAY_SIZE(flex_mmio); i++) {
+ for (i = 0; i < ARRAY_SIZE(flex_regs); i++) {
u32 state_offset = ctx_flexeu0 + i * 2;
- u32 mmio = flex_mmio[i];
+ u32 mmio = i915_mmio_reg_offset(flex_regs[i]);
/*
* This arbitrary default will select the 'EU FPU0 Pipeline
@@ -1619,8 +1618,7 @@ static void
gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
}
}
- reg_state[state_offset] = mmio;
- reg_state[state_offset+1] = value;
+ CTX_REG(reg_state, state_offset, flex_regs[i], value);
Does flex_regs[i] needs to be mmio?
Yeah, the macro uses i915_mmio_reg_offset().
In that case:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] drm/cma-helper: Use the generic fbdev emulation
On Wed, May 23, 2018 at 04:34:09PM +0200, Noralf Trønnes wrote:
> This switches the CMA helper drivers that use its fbdev emulation over
> to the generic fbdev emulation. It's the first phase of using generic
> fbdev. A later phase will use DRM client callbacks for the
> lastclose/hotplug/remove callbacks.
>
> There are currently 2 fbdev init/fini functions:
> - drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
> - drm_fbdev_cma_init/drm_fbdev_cma_fini
>
> This is because the work on generic fbdev came up during a fbdev
> refactoring and thus wasn't completed. No point in completing that
> refactoring when drivers will soon move to drm_fb_helper_generic_probe().
>
> tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
>
> Cc: Laurent Pinchart
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 365
> +---
Yay for the diffstat! Has my ack, but would be good to get Laurent's
review.
-Daniel
> include/drm/drm_fb_cma_helper.h | 3 -
> 2 files changed, 47 insertions(+), 321 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 186d00adfb5f..76e2f799 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -18,6 +18,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -26,11 +27,8 @@
> #include
> #include
>
> -#define DEFAULT_FBDEFIO_DELAY_MS 50
> -
> struct drm_fbdev_cma {
> struct drm_fb_helperfb_helper;
> - const struct drm_framebuffer_funcs *fb_funcs;
> };
>
> /**
> @@ -44,36 +42,6 @@ struct drm_fbdev_cma {
> *
> * An fbdev framebuffer backed by cma is also available by calling
> * drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
> - * If the &drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will
> be
> - * set up automatically. &drm_framebuffer_funcs.dirty is called by
> - * drm_fb_helper_deferred_io() in process context (&struct delayed_work).
> - *
> - * Example fbdev deferred io code::
> - *
> - * static int driver_fb_dirty(struct drm_framebuffer *fb,
> - *struct drm_file *file_priv,
> - *unsigned flags, unsigned color,
> - *struct drm_clip_rect *clips,
> - *unsigned num_clips)
> - * {
> - * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
> - * ... push changes ...
> - * return 0;
> - * }
> - *
> - * static struct drm_framebuffer_funcs driver_fb_funcs = {
> - * .destroy = drm_gem_fb_destroy,
> - * .create_handle = drm_gem_fb_create_handle,
> - * .dirty = driver_fb_dirty,
> - * };
> - *
> - * Initialize::
> - *
> - * fbdev = drm_fb_cma_fbdev_init_with_funcs(dev, 16,
> - * dev->mode_config.num_crtc,
> - * dev->mode_config.num_connector,
> - * &driver_fb_funcs);
> - *
> */
>
> static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper
> *helper)
> @@ -131,153 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> drm_framebuffer *fb,
> }
> EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
>
> -static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
> -{
> - return dma_mmap_writecombine(info->device, vma, info->screen_base,
> - info->fix.smem_start, info->fix.smem_len);
> -}
> -
> -static struct fb_ops drm_fbdev_cma_ops = {
> - .owner = THIS_MODULE,
> - DRM_FB_HELPER_DEFAULT_OPS,
> - .fb_fillrect= drm_fb_helper_sys_fillrect,
> - .fb_copyarea= drm_fb_helper_sys_copyarea,
> - .fb_imageblit = drm_fb_helper_sys_imageblit,
> - .fb_mmap= drm_fb_cma_mmap,
> -};
> -
> -static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> - struct vm_area_struct *vma)
> -{
> - fb_deferred_io_mmap(info, vma);
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> -
> - return 0;
> -}
> -
> -static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
> - struct drm_gem_cma_object *cma_obj)
> -{
> - struct fb_deferred_io *fbdefio;
> - struct fb_ops *fbops;
> -
> - /*
> - * Per device structures are needed because:
> - * fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
> - * fbdefio: individual delays
> - */
> - fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
> - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> - if (!fbdefio || !fbops) {
> - kfree(fbdefio);
> - kfree(fbops);
> - return -ENOMEM;
> - }
> -
> - /* can't be offset from vaddr since dirty() uses cma_obj */
> - fbi->screen_buffer = cma_obj->vaddr;
> -
Re: [Intel-gfx] DRM Inquiry
Hi Jani, I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I could see that the kernel is now 4.6. How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure it correctly? It still unclear to me how to follow what you mean by using DRM DP AUX interface and getting /dev/drm_dp_auxN node(s) that allows me to read and write arbitrary DPCD offsets. Please have comments and advice. Regards,John On Thursday, May 24, 2018, 12:19:55 PM GMT+8, John Sledge wrote: Hi Jani, Good day! Thank you for taking the time to point out those information. It’s a great help to me. Also apologies for the late reply, your first reply went to my spam inbox, not sure what happen and I was waiting for replies for days. I'm still new to Linux and to DRM. I also need to investigate and learn more about it. Here's what I have done so far. I was able to work on the modeprint test application from the libdrm package found in the website github.com/grate-driver/libdrm. I need to understand how user space and kernel works and modeprint provided me a simple understanding how it works.The modeprint requires a module name to open and I provided the i915 module. It followed opening the device name then calling ioctl commands to get resources, drm mode get connectors, encoders and crtc. From here, i was able to detect the display device's information successfully. So from here I got stuck and got confused. I only notice that in the drm.h it has limited IOCTL commands which it doesn't reach what i needed like to reach scope in drm_dp_helper.c or intel_dp.c where the dp aux read/write functions. Okay, back to your advice. Correct, I'm trying to access DPCD from the userspace. I haven't tried it and I'm not sure how it will goes out. I will try it now and I will give feedback on this.From what I understand, I need to rebuild the entire kernel with modification to Kconfig file (depends on DRM=y) in linux-4.16\drivers\gpu\drm directory. Then expect /dev/drm_dp_auxN node in the system. config DRM_DP_AUX_CHARDEV bool "DRM DP AUX Interface" depends on DRM=y help Choose this option to enable a /dev/drm_dp_auxN node that allows to read and write values to arbitrary DPCD registers on the DP aux channel. The second advice, I guess your correct since the display device i needed to communicate is under Connector: DP-1 and not in Connector: eDP-1. This is based on the application modeprint result. Regards,John On Friday, May 18, 2018, 5:48:31 PM GMT+8, Jani Nikula wrote: On Thu, 17 May 2018, John Sledge wrote: > I’ve been doing some PTN3460 programming under Linux using C/C++ and I > have some questions regarding on setting the brightness level to my > display device. > > The display device with PTN3460 is connected in DP (display port) to > my computer. Only needs a DisplayPort native AUX command to access > DPCD address from PTN3460. I’m currently looking into the DRM (Direct > Rendering Manager) a subsystem of the Linux kernel. It has a methods > drm_dp_dpcd_readb, drm_dp_dpcd_read and drm_dp_dpcd_write. > > Do you have any suggestions or advice how to use the kernel driver in > DRM in regards to how to implement the method drm_dp_dpcd_readb for > example? I couldn't not find any test tool examples that implement > it. Biggest concern is I don't have sufficient knowledge where to > start what to code using the DRM module. Let me double check, you're talking about doing DPCD access from userspace? The *only* interface that can be recommended for that is the DRM DP AUX interface. If you have kernel config DRM_DP_AUX_CHARDEV=y, you'll get /dev/drm_dp_auxN node(s) that allows you to read and write arbitrary DPCD offsets. It's a chardev; you can use e.g. dd to debug read DPCD. Of course, it would be better to have a generic backlight interface for DPCD based backlight in kernel. We have the basics for that for Intel GPU in i915/intel_dp_aux_backlight.c. Granted, it should be moved to common DRM code, but it also doesn't work for you if you have the chip connected to regular DP. It expects eDP, and somewhat spec compliant eDP DPCD backlight support. HTH, Jani. -- Jani Nikula, Intel Open Source Graphics Center___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 5/6] mfd: cros_ec_dev: Add CEC sub-device registration
On 24/05/18 11:57, Neil Armstrong wrote:
> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Enric Balletbo i Serra
For whatever it is worth:
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/mfd/cros_ec_dev.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 1d6dc5c..272969e 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev
> *ec)
> kfree(msg);
> }
>
> +static const struct mfd_cell cros_ec_cec_cells[] = {
> + { .name = "cros-ec-cec" }
> +};
> +
> static const struct mfd_cell cros_ec_rtc_cells[] = {
> { .name = "cros-ec-rtc" }
> };
> @@ -426,6 +430,18 @@ static int ec_device_probe(struct platform_device *pdev)
> if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
> cros_ec_sensors_register(ec);
>
> + /* Check whether this EC instance has CEC host command support */
> + if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
> + retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
> + cros_ec_cec_cells,
> + ARRAY_SIZE(cros_ec_cec_cells),
> + NULL, 0, NULL);
> + if (retval)
> + dev_err(ec->dev,
> + "failed to add cros-ec-cec device: %d\n",
> + retval);
> + }
> +
> /* Check whether this EC instance has RTC host command support */
> if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
> retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DRM Inquiry
On Thu, 24 May 2018, John Sledge wrote: > I was able to update my kernel to 4.6 which has the DRM_DP_AUX_CHARDEV > in the Kconfig file linux-4.6\drivers\gpu\drm. Though I also > add DRM_DP_AUX_CHARDEV=y in kernel config. When invoke uname -r, I > could see that the kernel is now 4.6. If you're updating kernels, why not update to a recent kernel that's actually supported...? > How can I verify the DRM_DP_AUX_CHARDEV takes effect or got configure > it correctly? Boot the kernel, run 'ls /dev/drm_dp_aux*'. If you see stuff, you got it right. > It still unclear to me how to follow what you mean by using DRM DP AUX > interface and getting /dev/drm_dp_auxN node(s) that allows me to read > and write arbitrary DPCD offsets. The device is a char device you can open, seek to an offset (which would be the DPCD offset), and read. For testing, you can achieve the same using dd. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 7/7] drm/i915: add a sysfs entry to let users set sseu configs
On 23/05/2018 18:33, Lionel Landwerlin wrote:
On 23/05/18 16:30, Tvrtko Ursulin wrote:
On 22/05/2018 19:00, Lionel Landwerlin wrote:
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +++
drivers/gpu/drm/i915/i915_gem_context.c | 52 -
drivers/gpu/drm/i915/i915_sysfs.c | 30 ++
3 files changed, 86 insertions(+), 1 deletion(-)
[snip]
} contexts;
u32 fdi_rx_config;
@@ -3274,6 +3276,9 @@ i915_gem_context_lookup(struct
drm_i915_file_private *file_priv, u32 id)
return ctx;
}
+int i915_gem_contexts_set_allow_sseu(struct drm_i915_private
*dev_priv, bool allowed);
+bool i915_gem_contexts_get_allow_sseu(struct drm_i915_private
*dev_priv);
+
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5c5a12f1c265..815a9d1c29f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -981,7 +981,8 @@ int i915_gem_context_setparam_ioctl(struct
drm_device *dev, void *data,
break;
}
- if (!capable(CAP_SYS_ADMIN)) {
+ if (!dev_priv->contexts.allow_sseu &&
+ !capable(CAP_SYS_ADMIN)) {
So the thing I mentioned in the previous patch. My thinking was not to
fail it if sysfs toggle is disabled, but just don't do dynamic
switching. That way the software stack works in all cases but user has
the option of tuning his system.
I mean it can still be done but in userspace. Set param fails,
userspace goes for a fall back.
Only difference is I guess whether it is useful to allow switching at
runtime. I am imagining running some 3d and media, and then toggling
the knob to see what happens to power and performance on the fly. But
maybe that is not so interesting.
Along the same lines I was thinking CAP_SYS_ADMIN limitation could be
dropped.
Both points are for a wider discussion I guess.
Okay, let's get Dmitry input on this.
To expand, my thinking is to let media stack configure its contexts for
fewer slices, but let the user/sysadmin decide whether 3d/compute
performance is more important, or media.
Downside is that with this approach you would have to re-configure all
contexts when sysfs toggle is changed from zero to one.
[snip]
+
+ /*
+ * When we allow each context to configure its powergating
+ * configuration, there is no need to put the configurations
back to
+ * the default, it should already be the case.
+ */
+ if (!allowed) {
+ union intel_sseu default_sseu =
+ intel_sseu_from_device_sseu(&INTEL_INFO(dev_priv)->sseu);
+ struct i915_gem_context *ctx;
+
+ list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
+ ret = i915_gem_context_reconfigure_sseu(ctx, engine,
+ default_sseu);
+ if (ret)
+ break;
+ }
+ }
+
+ dev_priv->contexts.allow_sseu = allowed;
+
+ mutex_unlock(&dev_priv->drm.struct_mutex);
+ return ret;
+}
+
+bool i915_gem_contexts_get_allow_sseu(struct drm_i915_private
*dev_priv)
+{
+ struct intel_engine_cs *engine = dev_priv->engine[RCS];
+ bool ret;
+
+ if (!engine->emit_rpcs_config)
+ return false;
+
+ mutex_lock(&dev_priv->drm.struct_mutex);
+ ret = dev_priv->contexts.allow_sseu;
+ mutex_unlock(&dev_priv->drm.struct_mutex);
I guess this mutex does nothing in this case.
Yeah, I'm not sure whether I can read a boolean or whether it should be
an atomic...
You can just read a boolean.
+ return ret;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_context.c"
#include "selftests/i915_gem_context.c"
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index e5e6f6bb2b05..9fd15b138ac9 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -483,6 +483,34 @@ static ssize_t gt_rp_mhz_show(struct device
*kdev, struct device_attribute *attr
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
+static ssize_t gem_allow_sseu_show(struct device *kdev,
+ struct device_attribute *attr, char *buf)
+{
+ struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
+ int ret = i915_gem_contexts_get_allow_sseu(dev_priv);
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", ret);
Propagate ENODEV all the way by making
i915_gem_contexts_get_allow_sseu return an int?
Duh! Well spotted.
Re: [Intel-gfx] [PATCH v6 6/7] drm/i915: Expose RPCS (SSEU) configuration to userspace
On 23/05/2018 18:12, Lionel Landwerlin wrote:
On 23/05/18 16:13, Tvrtko Ursulin wrote:
On 22/05/2018 19:00, Lionel Landwerlin wrote:
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
.instance = 0, };
memset(&arg, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) &sseu;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &arg) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &arg);
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities
(Lionel)
v6: Change context powergating settings through MI_SDM on kernel
context (Chris)
v7: Synchronize the requests following a powergating setting change
using a global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
c: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 13 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +
drivers/gpu/drm/i915/i915_gem_context.c | 167
drivers/gpu/drm/i915/i915_request.c | 20 +++
drivers/gpu/drm/i915/intel_lrc.c | 103 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 38 ++
8 files changed, 314 insertions(+), 35 deletions(-)
[snip]
int i915_gem_context_getparam_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file)
{
@@ -767,6 +864,37 @@ int i915_gem_context_getparam_ioctl(struct
drm_device *dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->value = ctx->sched.priority;
break;
+ case I915_CONTEXT_PARAM_SSEU: {
+ struct drm_i915_gem_context_param_sseu param_sseu;
+ struct intel_engine_cs *engine;
+ struct intel_context *ce;
+
+ if (copy_from_user(¶m_sseu, u64_to_user_ptr(args->value),
+ sizeof(param_sseu))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ engine = intel_engine_lookup_user(to_i915(dev),
+ param_sseu.class,
+ param_sseu.instance);
+ if (!engine) {
+ ret = -EINVAL;
+ break;
+ }
+
+ ce = to_intel_context(ctx, engine);
+
+ param_sseu.slice_mask = ce->sseu.slice_mask;
+ param_sseu.subslice_mask = ce->sseu.subslice_mask;
+ param_sseu.min_eus_per_subslice =
ce->sseu.min_eus_per_subslice;
+ param_sseu.max_eus_per_subslice =
ce->sseu.max_eus_per_subslice;
+
+ if (copy_to_user(u64_to_user_ptr(args->value), ¶m_sseu,
+ sizeof(param_sseu)))
+ ret = -EFAULT;
+ break;
Should we think about maybe not implementing the getter? I mean, is it
useful or just code for the driver which could be dropped?
Well, render fd can be transfer between processes, so I think it makes
sense to have a way to tell what is the current configuration.
I was thinking that userspace can already get the default configuration
via existing get params / topology query.
But if you change the ctx sseu config and pass that fd out its a bit
evil. :)
Anyway, no strong feelings to keep it. Was just thinking whether we can
save ourselves adding some code.
[snip]
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i91
[Intel-gfx] [PATCH v6 0/6] Add ChromeOS EC CEC Support
Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support through it's Embedded Controller, to enable the Linux CEC Core to communicate with it and get the CEC Physical Address from the correct HDMI Connector, the following must be added/changed: - Add the CEC sub-device registration in the ChromeOS EC MFD Driver - Add the CEC related commands and events definitions into the EC MFD driver - Add a way to get a CEC notifier with it's (optional) connector name - Add the CEC notifier to the i915 HDMI driver - Add the proper ChromeOS EC CEC Driver The CEC notifier with the connector name is the tricky point, since even on Device-Tree platforms, there is no way to distinguish between multiple HDMI connectors from the same DRM driver. The solution I implemented is pretty simple and only adds an optional connector name to eventually distinguish an HDMI connector notifier from another if they share the same device. Feel free to comment this patchset ! Changes since v5: - Small fixups on include/linux/mfd/cros_ec_commands.h - Fixed on cros-ec-cec driver accordingly - Added Reviewed-By tags Changes since v4: - Split patch 3 to move the mkbp event size change into a separate patch Changes since v3 (incorrectly reported as v2): - Renamed "Chrome OS" to "ChromeOS" - Updated cros_ec_commands.h new structs definitions to kernel doc format - Added Reviewed-By tags Changes since v2: - Add i915 port_identifier() and use this stable name as cec_notifier conn name - Fixed and cleaned up the CEC commands and events handling - Rebased the CEC sub-device registration on top of Enric's serie - Fixed comments typo on cec driver - Protected the DMI match only with PCI and DMI Kconfigs Changes since v1: - Added cec_notifier_put to intel_hdmi - Fixed all small reported issues on the EC CEC driver - Moved the cec_notifier_get out of the #if .. #else .. #endif Changes since RFC: - Moved CEC sub-device registration after CEC commands and events definitions patch - Removed get_notifier_get_byname - Added CEC_CORE select into i915 Kconfig - Removed CEC driver fallback if notifier is not configured on HW, added explicit warn - Fixed CEC core return type on error - Moved to cros-ec-cec media platform directory - Use bus_find_device() to find the pci i915 device instead of get_notifier_get_byname() - Fix Logical Address setup - Added comment about HW support - Removed memset of msg structures Neil Armstrong (6): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Increase maximum mkbp event size mfd: cros-ec: Introduce CEC commands and events definitions. mfd: cros_ec_dev: Add CEC sub-device registration media: platform: Add ChromeOS EC CEC driver drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_display.h | 20 ++ drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 13 + drivers/media/cec/cec-notifier.c | 11 +- drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile | 2 + drivers/media/platform/cros-ec-cec/Makefile | 1 + drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++ drivers/mfd/cros_ec_dev.c| 16 ++ drivers/platform/chrome/cros_ec_proto.c | 40 ++- include/linux/mfd/cros_ec.h | 2 +- include/linux/mfd/cros_ec_commands.h | 100 +++ include/media/cec-notifier.h | 27 +- 14 files changed, 577 insertions(+), 16 deletions(-) create mode 100644 drivers/media/platform/cros-ec-cec/Makefile create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 6/6] media: platform: Add ChromeOS EC CEC driver
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.
The controller will be tied to the HDMI CEC notifier by using the platform
DMI Data and the i915 device name and connector name.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
---
drivers/media/platform/Kconfig | 11 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/cros-ec-cec/Makefile | 1 +
drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++
4 files changed, 361 insertions(+)
create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..bc37ecf 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
if CEC_PLATFORM_DRIVERS
+config VIDEO_CROS_EC_CEC
+ tristate "ChromeOS EC CEC driver"
+ depends on MFD_CROS_EC || COMPILE_TEST
+ select CEC_CORE
+ select CEC_NOTIFIER
+ ---help---
+ If you say yes here you will get support for the
+ ChromeOS Embedded Controller's CEC.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..830696f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
qcom/camss-8x16/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
obj-y += meson/
+
+obj-y += cros-ec-cec/
diff --git a/drivers/media/platform/cros-ec-cec/Makefile
b/drivers/media/platform/cros-ec-cec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
new file mode 100644
index 000..7bc4d8a
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,347 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for ChromeOS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rx_msg: storage for a received message
+ */
+struct cros_ec_cec {
+ struct cros_ec_device *cros_ec;
+ struct notifier_block notifier;
+ struct cec_adapter *adap;
+ struct cec_notifier *notify;
+ struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+ unsigned int len = cros_ec->event_size;
+
+ cros_ec_cec->rx_msg.len = len;
+ memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+ cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint32_t events = cros_ec->event_data.data.cec_events;
+
+ if (events & EC_MKBP_CEC_SEND_OK)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_OK);
+
+ /* FW takes care of all retries, tell core to avoid more retries */
+ if (events & EC_MKBP_CEC_SEND_FAILED)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_device *cros_ec;
+
+ cros_ec_cec = container_of(nb, struct cros_ec_cec,
Re: [Intel-gfx] [PATCH 9/9] drm/fb-helper: Finish the generic fbdev emulation
On Wed, May 23, 2018 at 04:34:11PM +0200, Noralf Trønnes wrote:
> This adds a drm_fbdev_generic_setup() function that sets up generic
> fbdev emulation with client callbacks for lastclose, hotplug and
> remove/unregister.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 123
>
> include/drm/drm_fb_helper.h | 7 +++
> 2 files changed, 130 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 444c2b4040ea..bc826457eb84 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -68,6 +68,9 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
> * helper functions used by many drivers to implement the kernel mode setting
> * interfaces.
> *
> + * Drivers that support a dumb buffer with a virtual address and mmap
> support,
> + * should try and use the generic fbdev emulation using
> drm_fbdev_generic_setup().
> + *
> * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
> * down by calling drm_fb_helper_fbdev_teardown().
> *
> @@ -3092,6 +3095,126 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper
> *fb_helper,
> }
> EXPORT_SYMBOL(drm_fb_helper_generic_probe);
>
> +static const struct drm_fb_helper_funcs drm_fb_helper_generic_funcs = {
> + .fb_probe = drm_fb_helper_generic_probe,
> +};
> +
> +static int drm_fbdev_client_remove(struct drm_client_dev *client)
> +{
> + struct drm_fb_helper *fb_helper = client->private;
> +
> + /* Maybe setup was tried but failed */
> + if (!fb_helper)
> + return 0;
> +
> + /* Maybe drm_fb_helper_fbdev_setup() hasn't run yet */
> + if (!fb_helper->dev) {
> + kfree(fb_helper);
> + return 0;
> + }
> +
> + /* Maybe drm_fb_helper_generic_probe() hasn't run yet */
> + if (!fb_helper->fbdev) {
> + drm_fb_helper_fini(fb_helper);
> + kfree(fb_helper);
> + return 0;
> + }
> +
> + unregister_framebuffer(fb_helper->fbdev);
Hm, I'd expect nice problems with recursion and locking here, since we
clean up a lot of drm stuff from deeply within fbdev callbacks. I think
moving that cleanup code from your fb_destroy callback to here would look
a bit cleaner, and avoids the risk of going boom while holding the
console_lock. Which is always really, really nasty.
> +
> + /*
> + * If userspace is closed the client is now freed by
> drm_fbdev_fb_destroy(),
> + * otherwise it will be freed on the last close.
> + * Return 1 to tell that freeing is taken care of.
> + */
> + return 1;
Yeah that's definitely magic midlayer, we don't want the core to free
stuff for us and then pass around return values to tell it not to.
> +}
> +
> +static int drm_fbdev_client_lastclose(struct drm_client_dev *client)
> +{
> + drm_fb_helper_restore_fbdev_mode_unlocked(client->private);
> +
> + return 0;
> +}
> +
> +static int drm_fbdev_client_hotplug(struct drm_client_dev *client)
> +{
> + struct drm_fb_helper *fb_helper = client->private;
> + struct drm_device *dev = client->dev;
> + int ret;
> +
> + if (dev->fb_helper)
> + return drm_fb_helper_hotplug_event(dev->fb_helper);
> +
> + if (!dev->mode_config.num_connector || !fb_helper)
> + return 0;
> +
> + ret = drm_fb_helper_fbdev_setup(dev, fb_helper,
> &drm_fb_helper_generic_funcs,
> + fb_helper->preferred_bpp, 0);
> + if (ret) {
> + /* Setup is tried only once */
> + client->private = NULL;
> + kfree(fb_helper);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct drm_client_funcs drm_fbdev_client_funcs = {
> + .name = "fbdev",
> + .remove = drm_fbdev_client_remove,
> + .lastclose = drm_fbdev_client_lastclose,
> + .hotplug= drm_fbdev_client_hotplug,
> +};
> +
> +/**
> + * drm_fb_helper_generic_fbdev_setup() - Setup generic fbdev emulation
> + * @dev: DRM device
> + * @preferred_bpp: Preferred bits per pixel for the device.
> + * @dev->mode_config.preferred_depth is used if this is zero.
> + *
> + * This function sets up generic fbdev emulation for drivers that supports
> + * dumb buffers with a virtual address and that can be mmap'ed.
> + *
> + * Restore, hotplug events and teardown are all taken care of. Drivers that
> does
> + * suspend/resume need to call drm_fb_helper_set_suspend_unlocked()
> themselves.
> + * Simple drivers might use drm_mode_config_helper_suspend().
> + *
> + * This function is safe to call even when there are no connectors present.
> + * Setup will be retried on the next hotplug event.
I think we should spend a few more words on the limitations of the generic
fbdev support. Probably best to reference the generic_probe callback for
that (and make sure all the limitations, lik
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
Oscar Mateo Lozano writes:
> On 5/18/2018 3:41 PM, Yunwei Zhang wrote:
>> 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)
>> v6:
>> - Some coding style and use more local variables for clearer
>> logic (Ursulin)
>>
>> Cc: Oscar Mateo
>> Cc: Michel Thierry
>> Cc: Joonas Lahtinen
>> Cc: Chris Wilson
>> Cc: Mika Kuoppala
>> Cc: Tvrtko Ursulin
>> Signed-off-by: Yunwei Zhang
>
> Reviewed-by: Oscar Mateo
1-3 Pushed.
Thanks for patches and review.
-Mika
>
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 4
>> drivers/gpu/drm/i915/intel_workarounds.c | 35
>>
>> 2 files changed, 39 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 196a0eb..9137b1c 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -2709,6 +2709,10 @@ enum i915_power_well_id {
>> #define GEN10_F2_SS_DIS_SHIFT18
>> #define GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT)
>>
>> +#define GEN10_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_workarounds.c
>> b/drivers/gpu/drm/i915/intel_workarounds.c
>> index 2deec58..cea5710 100644
>> --- a/drivers/gpu/drm/i915/intel_workarounds.c
>> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
>> @@ -674,9 +674,44 @@ static void cfl_gt_workarounds_apply(struct
>> drm_i915_private *dev_priv)
>>
>> static void wa_init_mcr(struct drm_i915_private *dev_priv)
>> {
>> +const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
>> u32 mcr;
>> u32 mcr_slice_subslice_mask;
>>
>> +/*
>> + * WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl
>> + * L3Banks could be fused off in single slice scenario. If that is
>> + * the case, we might need to program MCR select to a valid L3Bank
>> + * by default, to make sure we correctly read certain registers
>> + * later on (in the range 0xB100 - 0xB3FF).
>> + * This might be incompatible with
>> + * WaProgramMgsrForCorrectSliceSpecificMmioReads.
>> + * Fortunately, this should not happen in production hardware, so
>> + * we only assert that this is the case (instead of implementing
>> + * something more complex that requires checking the range of every
>> + * MMIO read).
>> + */
>> +if (INTEL_GEN(dev_priv) >= 10 &&
>> +is_power_of_2(sseu->slice_mask)) {
>> +/*
>> + * 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];
>> +
>> +u8 enabled_mask = (ss_mask | ss_mask >>
>> + GEN10_L3BANK_PAIR_COUNT) & GEN10_L3BANK_MASK;
>> +u8 disabled_mask = fuse3 & GEN10_L3BANK_MASK;
>> +
>> +/*
>> + * Production silicon should have matched L3Bank and
>> + * subslice enabled
>> + */
>> +WARN_ON((enabled_mask & disabled_mask) != enabled_mask);
>> +}
>> +
>> mcr = I915_READ(GEN8_MCR_SELECTOR);
>>
>> if (INTEL_GEN(dev_priv) >= 11)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/drv_suspend: Suspend under memory pressure
Recently we discovered that we have a race between swapping and
suspend in our resume path (we might be trying to page in an object
after disabling the block devices). Let's try to exercise that by
exhausting all of system memory before suspend.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106640
Signed-off-by: Chris Wilson
Cc: Tomi Sarvela
---
lib/igt_core.c | 34 --
lib/igt_core.h | 1 +
tests/drv_suspend.c | 42 ++
3 files changed, 63 insertions(+), 14 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index e292ca24c..804ce4578 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1756,20 +1756,7 @@ void igt_child_done(pid_t pid)
test_children[i] = test_children[i + 1];
}
-/**
- * igt_waitchildren:
- *
- * Wait for all children forked with igt_fork.
- *
- * The magic here is that exit codes from children will be correctly propagated
- * to the main thread, including the relevant exit code if a child thread
failed.
- * Of course if multiple children failed with different exit codes the
resulting
- * exit code will be non-deterministic.
- *
- * Note that igt_skip() will not be forwarded, feature tests need to be done
- * before spawning threads with igt_fork().
- */
-void igt_waitchildren(void)
+int __igt_waitchildren(void)
{
int err = 0;
int count;
@@ -1815,6 +1802,25 @@ void igt_waitchildren(void)
}
num_test_children = 0;
+ return err;
+}
+
+/**
+ * igt_waitchildren:
+ *
+ * Wait for all children forked with igt_fork.
+ *
+ * The magic here is that exit codes from children will be correctly propagated
+ * to the main thread, including the relevant exit code if a child thread
failed.
+ * Of course if multiple children failed with different exit codes the
resulting
+ * exit code will be non-deterministic.
+ *
+ * Note that igt_skip() will not be forwarded, feature tests need to be done
+ * before spawning threads with igt_fork().
+ */
+void igt_waitchildren(void)
+{
+ int err = __igt_waitchildren();
if (err)
igt_fail(err);
}
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 3d7b787b2..6d4260403 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -742,6 +742,7 @@ bool __igt_fork(void);
for (int child = 0; child < (num_children); child++) \
for (; __igt_fork(); exit(0))
void igt_child_done(pid_t pid);
+int __igt_waitchildren(void);
void igt_waitchildren(void);
void igt_waitchildren_timeout(int seconds, const char *reason);
diff --git a/tests/drv_suspend.c b/tests/drv_suspend.c
index 2e39f20ae..8f71a81d1 100644
--- a/tests/drv_suspend.c
+++ b/tests/drv_suspend.c
@@ -160,6 +160,45 @@ test_sysfs_reader(bool hibernate)
igt_stop_helper(&reader);
}
+static void
+test_shrink(int fd, unsigned int mode)
+{
+ uint64_t *can_mlock;
+ void *locked;
+ uint64_t pin;
+
+ gem_quiescent_gpu(fd);
+ intel_purge_vm_caches(fd);
+
+ can_mlock = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(can_mlock != MAP_FAILED);
+
+ pin = intel_get_total_ram_mb() << 20;
+
+ igt_debug("Locking %'"PRIu64" MiB\n", pin >> 20);
+ locked = malloc(pin);
+ igt_assert(locked);
+
+ /* Lock all the system memory, forcing the driver into swap and OOM */
+ igt_fork(child, 1) {
+ for (uint64_t bytes = 64 << 20; bytes <= pin; bytes += 64 << 20)
+ if (!mlock(locked, bytes))
+ *can_mlock = bytes;
+ if (!mlock(locked, pin))
+ *can_mlock = pin;
+ }
+ __igt_waitchildren();
+ igt_require(*can_mlock);
+ mlock(locked, *can_mlock);
+ igt_info("Locked %'"PRIu64" MiB\n", *can_mlock >> 20);
+ munmap(can_mlock, 4096);
+
+ intel_purge_vm_caches(fd);
+ igt_system_suspend_autoresume(mode, SUSPEND_TEST_NONE);
+
+ free(locked);
+}
+
static void
test_forcewake(int fd, bool hibernate)
{
@@ -199,6 +238,9 @@ igt_main
igt_subtest("sysfs-reader")
test_sysfs_reader(false);
+ igt_subtest("shrink")
+ test_shrink(fd, SUSPEND_STATE_MEM);
+
igt_subtest("forcewake")
test_forcewake(fd, false);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI
From: Ville Syrjälä
When encountering a connector with the scaling mode property both
intel and modesetting ddxs sometimes add tons of DBLSCAN modes
to the output's mode list. The idea presumably being that since the
output will be going through the panel fitter anyway we can pretend
to use any kind of mode.
Sadly that means we can't reject user modes with the DBLSCAN flag
until we know whether we're going to be using the panel's native
mode or the user mode directly. Doing otherwise means X clients using
xf86vidmode/xrandr will get a protocol error (and often self
terminate as a result) when the kernel refuses to use the requested
mode with the DBLSCAN flag.
To undo the regression we'll move the DBLSCAN checks into the
connector->mode_valid() and encoder->compute_config() hooks.
Cc: Vito Caputo
Reported-by: Vito Caputo
Fixes: e995ca0b8139 ("drm/i915: Provide a device level .mode_valid() hook")
References: https://lkml.org/lkml/2018/5/21/715
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c | 20
drivers/gpu/drm/i915/intel_display.c | 16 +---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
drivers/gpu/drm/i915/intel_dsi.c | 6 ++
drivers/gpu/drm/i915/intel_dvo.c | 6 ++
drivers/gpu/drm/i915/intel_hdmi.c| 6 ++
drivers/gpu/drm/i915/intel_lvds.c| 5 +
drivers/gpu/drm/i915/intel_sdvo.c| 6 ++
drivers/gpu/drm/i915/intel_tv.c | 12 ++--
10 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 211d601cd1b1..95aa29cf2d9c 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -304,6 +304,9 @@ intel_crt_mode_valid(struct drm_connector *connector,
int max_dotclk = dev_priv->max_dotclk_freq;
int max_clock;
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ return MODE_NO_DBLESCAN;
+
if (mode->clock < 25000)
return MODE_CLOCK_LOW;
@@ -337,6 +340,12 @@ static bool intel_crt_compute_config(struct intel_encoder
*encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
+ struct drm_display_mode *adjusted_mode =
+ &pipe_config->base.adjusted_mode;
+
+ if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ return false;
+
return true;
}
@@ -344,6 +353,12 @@ static bool pch_crt_compute_config(struct intel_encoder
*encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
+ struct drm_display_mode *adjusted_mode =
+ &pipe_config->base.adjusted_mode;
+
+ if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ return false;
+
pipe_config->has_pch_encoder = true;
return true;
@@ -354,6 +369,11 @@ static bool hsw_crt_compute_config(struct intel_encoder
*encoder,
struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct drm_display_mode *adjusted_mode =
+ &pipe_config->base.adjusted_mode;
+
+ if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ return false;
pipe_config->has_pch_encoder = true;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8b385176ce3c..02651298a99b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14443,12 +14443,22 @@ static enum drm_mode_status
intel_mode_valid(struct drm_device *dev,
const struct drm_display_mode *mode)
{
+ /*
+* Can't reject DBLSCAN here because Xorg ddxen can add piles
+* of DBLSCAN modes to the output's mode list when they detect
+* the scaling mode property on the connector. And they don't
+* ask the kernel to validate those modes in any way until
+* modeset time at which point the client gets a protocol error.
+* So in order to not upset those clients we silently ignore the
+* DBLSCAN flag on such connectors. For other connectors we will
+* reject modes with the DBLSCAN flag in encoder->compute_config().
+* And we always reject DBLSCAN modes in connector->mode_valid()
+* as we never want such modes on the connector's mode list.
+*/
+
if (mode->vscan > 1)
return MODE_NO_VSCAN;
- if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
- return MODE_NO_DBLESCAN;
-
if (mode->flags & DRM_MODE_FLAG_HSKEW)
return MODE_H_ILLEGAL;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ce07bd794aed..91885f2500a
Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr
On Tue, 22 May 2018, Jani Nikula wrote:
> On Tue, 22 May 2018, vathsala nagaraju wrote:
>> From: Vathsala Nagaraju
>>
>> For psr block #9, the vbt description has moved to options [0-3] for
>> TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
>> structure. Since spec does not mention from which VBT version this
>> change was added to vbt.bsf file, we cannot depend on bdb->version check
>> to change for all the platforms.
>>
>> There is RCR inplace for GOP team to provide the version number
>> to make generic change. Since Kabylake with bdb version 209 is having this
>> change, limiting this change to gen9_bc and version 209+ to unblock google.
>>
>> Tested on skl(bdb version 203,without options) and
>> kabylake(bdb version 209,212) having new options.
>>
>> bspec 20131
>>
>> v2: (Jani and Rodrigo)
>> move the 165 version check to intel_bios.c
>> v3: Jani
>> Move the abstraction to intel_bios.
>> v4: Jani
>> Rename tp*_wakeup_time to have "us" suffix.
>> For values outside range[0-3],default to max 2500us.
>> Old decimal value was wake up time in multiples of 100us.
>> v5: Jani and Rodrigo
>> Handle option 2 in default condition.
>> Print oustide range value.
>> For negetive values default to 2500us.
>> v6: Jani
>> Handle default first and then fall through for case 2.
>> v7: Rodrigo
>> Apply this change for IS_GEN9_BC and vbt version > 209
>> v8: Puthik
>> Add new function vbt_psr_to_us.
>> v9: Jani
>> Change to v7 version as it's more readable.
>> DK
>> add comment /*fall through*/ after case2.
>>
>> Cc: Rodrigo Vivi
>> Cc: Puthikorn Voravootivat
>> Cc: Dhinakaran Pandiyan
>> Cc: Jani Nikula
>> Cc: José Roberto de Souza
>>
>> Signed-off-by: Maulik V Vaghela
>> Signed-off-by: Vathsala Nagaraju
>
> Reviewed-by: Jani Nikula
And pushed to dinq. Thanks for the patch.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 4 ++--
>> drivers/gpu/drm/i915/i915_reg.h | 8 +++
>> drivers/gpu/drm/i915/intel_bios.c | 48
>> +--
>> drivers/gpu/drm/i915/intel_psr.c | 39 +++
>> 4 files changed, 72 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index e33c380..dcfa791 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1078,8 +1078,8 @@ struct intel_vbt_data {
>> bool require_aux_wakeup;
>> int idle_frames;
>> enum psr_lines_to_wait lines_to_wait;
>> -int tp1_wakeup_time;
>> -int tp2_tp3_wakeup_time;
>> +int tp1_wakeup_time_us;
>> +int tp2_tp3_wakeup_time_us;
>> } psr;
>>
>> struct {
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 196a0eb..513b4a4 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -4088,10 +4088,10 @@ enum {
>> #define EDP_Y_COORDINATE_ENABLE (1<<25) /* GLK and CNL+ */
>> #define EDP_MAX_SU_DISABLE_TIME(t)((t)<<20)
>> #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
>> -#define EDP_PSR2_TP2_TIME_500 (0<<8)
>> -#define EDP_PSR2_TP2_TIME_100 (1<<8)
>> -#define EDP_PSR2_TP2_TIME_2500(2<<8)
>> -#define EDP_PSR2_TP2_TIME_50 (3<<8)
>> +#define EDP_PSR2_TP2_TIME_500us (0<<8)
>> +#define EDP_PSR2_TP2_TIME_100us (1<<8)
>> +#define EDP_PSR2_TP2_TIME_2500us (2<<8)
>> +#define EDP_PSR2_TP2_TIME_50us(3<<8)
>> #define EDP_PSR2_TP2_TIME_MASK(3<<8)
>> #define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
>> #define EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf<<4)
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 54270bd..417f656 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -688,8 +688,52 @@ static int intel_bios_ssc_frequency(struct
>> drm_i915_private *dev_priv,
>> break;
>> }
>>
>> -dev_priv->vbt.psr.tp1_wakeup_time = psr_table->tp1_wakeup_time;
>> -dev_priv->vbt.psr.tp2_tp3_wakeup_time = psr_table->tp2_tp3_wakeup_time;
>> +/*
>> + * New psr options 0=500us, 1=100us, 2=2500us, 3=0us
>> + * Old decimal value is wake up time in multiples of 100 us.
>> + */
>> +if (bdb->version >= 209 && IS_GEN9_BC(dev_priv)) {
>> +switch (psr_table->tp1_wakeup_time) {
>> +case 0:
>> +dev_priv->vbt.psr.tp1_wakeup_time_us = 500;
>> +break;
>> +case 1:
>> +dev_priv->vbt.psr.tp1_wakeup_time_us = 100;
>> +break;
>> +case 3:
>> +dev_priv->vbt.psr.tp1_wakeup_time_us = 0;
>> +break;
>> +default:
>> +DRM_DEBUG_KMS("VBT tp1 wakeup time value %d is ou
Re: [Intel-gfx] [PATCH] drm/i915/psr: Nuke PSR support for VLV and CHV
On Mon, 14 May 2018, Dhinakaran Pandiyan wrote:
> On Mon, 2018-05-14 at 12:09 +0300, Jani Nikula wrote:
>> On Fri, 11 May 2018, Dhinakaran Pandiyan > om> wrote:
>> >
>> > PSR hardware and hence the driver code for VLV and CHV deviates a
>> > lot from
>> > their DDI counterparts. While the feature has been disabled for a
>> > long time
>> > now, retaining support for these platforms is a maintenance burden.
>> > There
>> > have been multiple refactoring commits to just keep the existing
>> > code for
>> > these platforms in line with the rest. There are known issues that
>> > need to
>> > be fixed to enable PSR on these platforms, and there is no PSR
>> > capable
>> > platform in CI to ensure the code does not break again if we get
>> > around to
>> > fixing the existing issues. On account of all these reasons, let's
>> > nuke
>> > this code for now and bring it back if a need arises in the future.
>> >
>> > Cc: Jani Nikula
>> > Cc: Rodrigo Vivi
>> > Cc: Ville Syrjälä
>> > Signed-off-by: Dhinakaran Pandiyan
>> Acked-by: Jani Nikula
>>
> Thank you.
>
> Including Rodrigo's ack that was sent internally
> Acked-by: Rodrigo Vivi
Pushed to dinq, thanks for the patch.
BR,
Jani.
>
>
>> >
>> > ---
>> > drivers/gpu/drm/i915/i915_debugfs.c | 42 +-
>> > drivers/gpu/drm/i915/i915_drv.h | 1 -
>> > drivers/gpu/drm/i915/i915_pci.c | 2 -
>> > drivers/gpu/drm/i915/intel_drv.h | 2 -
>> > drivers/gpu/drm/i915/intel_frontbuffer.c | 2 -
>> > drivers/gpu/drm/i915/intel_psr.c | 248 +++--
>> > --
>> > 6 files changed, 27 insertions(+), 270 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> > b/drivers/gpu/drm/i915/i915_debugfs.c
>> > index 13e7b9e4a6e6..0096e209fe04 100644
>> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> > @@ -2630,8 +2630,6 @@ static int i915_edp_psr_status(struct
>> > seq_file *m, void *data)
>> > {
>> > struct drm_i915_private *dev_priv = node_to_i915(m-
>> > >private);
>> > u32 psrperf = 0;
>> > - u32 stat[3];
>> > - enum pipe pipe;
>> > bool enabled = false;
>> > bool sink_support;
>> >
>> > @@ -2652,47 +2650,17 @@ static int i915_edp_psr_status(struct
>> > seq_file *m, void *data)
>> > seq_printf(m, "Re-enable work scheduled: %s\n",
>> > yesno(work_busy(&dev_priv->psr.work.work)));
>> >
>> > - if (HAS_DDI(dev_priv)) {
>> > - if (dev_priv->psr.psr2_enabled)
>> > - enabled = I915_READ(EDP_PSR2_CTL) &
>> > EDP_PSR2_ENABLE;
>> > - else
>> > - enabled = I915_READ(EDP_PSR_CTL) &
>> > EDP_PSR_ENABLE;
>> > - } else {
>> > - for_each_pipe(dev_priv, pipe) {
>> > - enum transcoder cpu_transcoder =
>> > - intel_pipe_to_cpu_transcoder(dev_p
>> > riv, pipe);
>> > - enum intel_display_power_domain
>> > power_domain;
>> > -
>> > - power_domain =
>> > POWER_DOMAIN_TRANSCODER(cpu_transcoder);
>> > - if
>> > (!intel_display_power_get_if_enabled(dev_priv,
>> > - po
>> > wer_domain))
>> > - continue;
>> > -
>> > - stat[pipe] = I915_READ(VLV_PSRSTAT(pipe))
>> > &
>> > - VLV_EDP_PSR_CURR_STATE_MASK;
>> > - if ((stat[pipe] ==
>> > VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
>> > - (stat[pipe] ==
>> > VLV_EDP_PSR_ACTIVE_SF_UPDATE))
>> > - enabled = true;
>> > -
>> > - intel_display_power_put(dev_priv,
>> > power_domain);
>> > - }
>> > - }
>> > + if (dev_priv->psr.psr2_enabled)
>> > + enabled = I915_READ(EDP_PSR2_CTL) &
>> > EDP_PSR2_ENABLE;
>> > + else
>> > + enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
>> >
>> > seq_printf(m, "Main link in standby mode: %s\n",
>> > yesno(dev_priv->psr.link_standby));
>> >
>> > - seq_printf(m, "HW Enabled & Active bit: %s",
>> > yesno(enabled));
>> > -
>> > - if (!HAS_DDI(dev_priv))
>> > - for_each_pipe(dev_priv, pipe) {
>> > - if ((stat[pipe] ==
>> > VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
>> > - (stat[pipe] ==
>> > VLV_EDP_PSR_ACTIVE_SF_UPDATE))
>> > - seq_printf(m, " pipe %c",
>> > pipe_name(pipe));
>> > - }
>> > - seq_puts(m, "\n");
>> > + seq_printf(m, "HW Enabled & Active bit: %s\n",
>> > yesno(enabled));
>> >
>> > /*
>> > - * VLV/CHV PSR has no kind of performance counter
>> > * SKL+ Perf counter is reset to 0 everytime DC state is
>> > entered
>> > */
>> > if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> > b/drivers/gpu/drm/i915/i915_drv.h
>> > index 57fb3aa09db0..7e2a400d33c3 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.h
>> > +++ b/dri
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Look for an active kernel context before switching (rev2)
== Series Details == Series: drm/i915: Look for an active kernel context before switching (rev2) URL : https://patchwork.freedesktop.org/series/43609/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4228 -> Patchwork_9102 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43609/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9102 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 == Participating hosts (44 -> 39) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4228 -> Patchwork_9102 CI_DRM_4228: 8e3e5c1cc5de96c61ff995282ab952ff5d47a211 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9102: 2fa6e902cd0d0a8680a4768a909d5808e23e7017 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2fa6e902cd0d drm/i915: Look for an active kernel context before switching == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9102/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/24] drm/i915/icl: Get DDI clock for ICL based on PLLs.
Patch look ok to me.
Reviewed-by: Mika Kahola
On Wed, 2018-05-23 at 15:44 -0700, Paulo Zanoni wrote:
> From: Manasi Navare
>
> PLLs are the source clocks for the DDIs so in order
> to determine the ddi clock we need to check the PLL
> configuration.
>
> This gets a little tricky for ICL since there is
> no register bit that maps directly to the link clock.
> So this patch creates a separate function in intel_dpll_mgr.c
> to obtain the write array PLL Params and compares the set
> pll_params with the table to get the corresponding link
> clock.
>
> v2:
> - Fix the encoder type check (DK).
> - Improve our error checking, return a sane value (Mika, Paulo).
> - Fix table entries (Paulo).
>
> Cc: Rodrigo Vivi
> Cc: Mika Kahola
> Cc: Paulo Zanoni
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Manasi Navare
> Signed-off-by: Lucas De Marchi
> [Paulo: implement v2]
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 ++
> drivers/gpu/drm/i915/intel_ddi.c | 26 +
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 70
> +++
> drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +
> 4 files changed, 101 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index de6fcdb4948f..7c6346542a52 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9174,13 +9174,16 @@ enum skl_power_gate {
> #define DPLL_CFGCR1_QDIV_RATIO_MASK (0xff << 10)
> #define DPLL_CFGCR1_QDIV_RATIO_SHIFT(10)
> #define DPLL_CFGCR1_QDIV_RATIO(x) ((x) << 10)
> +#define DPLL_CFGCR1_QDIV_MODE_SHIFT (9)
> #define DPLL_CFGCR1_QDIV_MODE(x)((x) << 9)
> #define DPLL_CFGCR1_KDIV_MASK (7 << 6)
> +#define DPLL_CFGCR1_KDIV_SHIFT (6)
> #define DPLL_CFGCR1_KDIV(x) ((x) << 6)
> #define DPLL_CFGCR1_KDIV_1 (1 << 6)
> #define DPLL_CFGCR1_KDIV_2 (2 << 6)
> #define DPLL_CFGCR1_KDIV_4 (4 << 6)
> #define DPLL_CFGCR1_PDIV_MASK (0xf << 2)
> +#define DPLL_CFGCR1_PDIV_SHIFT (2)
> #define DPLL_CFGCR1_PDIV(x) ((x) << 2)
> #define DPLL_CFGCR1_PDIV_2 (1 << 2)
> #define DPLL_CFGCR1_PDIV_3 (2 << 2)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f6b2c0ec4e97..0e0b726e3a49 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1429,6 +1429,30 @@ static void ddi_dotclock_get(struct
> intel_crtc_state *pipe_config)
> pipe_config->base.adjusted_mode.crtc_clock = dotclock;
> }
>
> +static void icl_ddi_clock_get(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
> + enum port port = encoder->port;
> + int link_clock = 0;
> + uint32_t pll_id;
> +
> + pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config-
> >shared_dpll);
> + if (port == PORT_A || port == PORT_B) {
> + if (intel_crtc_has_type(pipe_config,
> INTEL_OUTPUT_HDMI))
> + link_clock = cnl_calc_wrpll_link(dev_priv,
> pll_id);
> + else
> + link_clock =
> icl_calc_dp_combo_pll_link(dev_priv,
> + pll_
> id);
> + } else {
> + /* FIXME - Add for MG PLL */
> + WARN(1, "MG PLL clock_get code not implemented
> yet\n");
> + }
> +
> + pipe_config->port_clock = link_clock;
> + ddi_dotclock_get(pipe_config);
> +}
> +
> static void cnl_ddi_clock_get(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config)
> {
> @@ -1622,6 +1646,8 @@ static void intel_ddi_clock_get(struct
> intel_encoder *encoder,
> bxt_ddi_clock_get(encoder, pipe_config);
> else if (IS_CANNONLAKE(dev_priv))
> cnl_ddi_clock_get(encoder, pipe_config);
> + else if (IS_ICELAKE(dev_priv))
> + icl_ddi_clock_get(encoder, pipe_config);
> }
>
> void intel_ddi_set_pipe_settings(const struct intel_crtc_state
> *crtc_state)
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 383fbc15113d..07bdbf2582ba 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2525,6 +2525,76 @@ static bool icl_calc_dpll_state(struct
> intel_crtc_state *crtc_state,
> return true;
> }
>
> +int icl_calc_dp_combo_pll_link(struct drm_i915_private *dev_priv,
> + uint32_t pll_id)
> +{
> + uint32_t cfgcr0, cfgcr1;
> + uint32_t pdiv, kdiv, qdiv_mode, qdiv_ratio, dco_integer,
> dco_fraction;
> + const struct skl_wrpll_params *params;
> + int index, n_entries, link_clock;
> +
> + /* Read back values from DPLL CFGCR registers */
> + cfgcr0 = I915_READ(IC
Re: [Intel-gfx] [PATCH 2/6] drm/i915/psr: Check for SET_POWER_CAPABLE bit at PSR init time.
On Fri, 11 May 2018, Dhinakaran Pandiyan wrote:
> On Fri, 2018-05-11 at 12:51 -0700, Dhinakaran Pandiyan wrote:
>> By moving the check from psr_compute_config() to psr_init_dpcd(), we
>> get
>> to set the dev_priv->psr.sink_support flag only when the panel is
>> capable of changing power state. An additional benefit is that the
>> check
>> will be performed only at init time instead of every atomic_check.
>>
>> This should change the psr_basic IGT failures on HSW to skips.
>>
>> v2: Return early when SET_POWER_CAPABLE bit is 0 (Jose)
>>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106217
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106346
Pushed to dinq, thanks for the patch and review.
BR,
Jani.
>> Cc: José Roberto de Souza
>> Cc: Ville Syrjälä
>> Signed-off-by: Dhinakaran Pandiyan
>> Reviewed-by: José Roberto de Souza
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 8 ++--
>> drivers/gpu/drm/i915/intel_psr.c | 11 +--
>> 2 files changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index dde92e4af5d3..cfd95eaa0d0d 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -3762,8 +3762,6 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>> dev_priv->no_aux_handshake = intel_dp-
>> >dpcd[DP_MAX_DOWNSPREAD] &
>> DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
>>
>> -intel_psr_init_dpcd(intel_dp);
>> -
>> /*
>> * Read the eDP display control registers.
>> *
>> @@ -3779,6 +3777,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>> DRM_DEBUG_KMS("eDP DPCD: %*ph\n", (int)
>> sizeof(intel_dp->edp_dpcd),
>> intel_dp->edp_dpcd);
>>
>> +/*
>> + * This has to be called after intel_dp->edp_dpcd is filled,
>> PSR checks
>> + * for SET_POWER_CAPABLE bit in intel_dp->edp_dpcd[1]
>> + */
>> +intel_psr_init_dpcd(intel_dp);
>> +
>> /* Read the eDP 1.4+ supported link rates. */
>> if (intel_dp->edp_dpcd[0] >= DP_EDP_14) {
>> __le16 sink_rates[DP_MAX_SUPPORTED_RATES];
>> diff --git a/drivers/gpu/drm/i915/intel_psr.c
>> b/drivers/gpu/drm/i915/intel_psr.c
>> index 8fe6d2f9ab2b..61ade81576f5 100644
>> --- a/drivers/gpu/drm/i915/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>> @@ -252,9 +252,13 @@ void intel_psr_init_dpcd(struct intel_dp
>> *intel_dp)
>>
>> if (!intel_dp->psr_dpcd[0])
>> return;
>> -
>> DRM_DEBUG_KMS("eDP panel supports PSR version %x\n",
>> intel_dp->psr_dpcd[0]);
>> +
>> +if (!(intel_dp->edp_dpcd[1] & DP_EDP_SET_POWER_CAP)) {
>> +DRM_DEBUG_KMS("Panel lacks power state control, PSR
>> cannot be enabled\n");
>> +return;
>> +}
>> dev_priv->psr.sink_support = true;
>>
>> if (INTEL_GEN(dev_priv) >= 9 &&
>> @@ -642,11 +646,6 @@ void intel_psr_compute_config(struct intel_dp
>> *intel_dp,
>> return;
>> }
>>
>> -if (!(intel_dp->edp_dpcd[1] & DP_EDP_SET_POWER_CAP)) {
>> -DRM_DEBUG_KMS("PSR condition failed: panel lacks
>> power state control\n");
>> -return;
>> -}
>> -
>> crtc_state->has_psr = true;
>> crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp,
>> crtc_state);
>> DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2"
>> : "");
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/psr: Avoid DPCD reads when panel does not support PSR
On Thu, 17 May 2018, Tarun Vyas wrote:
> On Fri, May 11, 2018 at 12:51:40PM -0700, Dhinakaran Pandiyan wrote:
>> Ville noticed that we are unncessarily reading DPCD's after knowing
>> panel did not support PSR. Looks like this check that was present
>> earlier got removed unintentionally, let's put it back.
>>
>> While we do this, add the PSR version number in the debug print.
>>
>> Cc: Ville Syrjälä
>> Signed-off-by: Dhinakaran Pandiyan
>> ---
>> drivers/gpu/drm/i915/intel_psr.c | 14 --
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_psr.c
>> b/drivers/gpu/drm/i915/intel_psr.c
>> index db27f2faa1de..8fe6d2f9ab2b 100644
>> --- a/drivers/gpu/drm/i915/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>> @@ -250,10 +250,12 @@ 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]) {
>> -dev_priv->psr.sink_support = true;
>> -DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
>> -}
>> +if (!intel_dp->psr_dpcd[0])
>> +return;
>> +
>> +DRM_DEBUG_KMS("eDP panel supports PSR version %x\n",
>> + intel_dp->psr_dpcd[0]);
>> +dev_priv->psr.sink_support = true;
>>
>> if (INTEL_GEN(dev_priv) >= 9 &&
>> (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
>> @@ -270,8 +272,8 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
>> */
>> dev_priv->psr.sink_psr2_support =
>> intel_dp_get_y_coord_required(intel_dp);
>> -DRM_DEBUG_KMS("PSR2 %s on sink", dev_priv->psr.sink_psr2_support
>> - ? "supported" : "not supported");
>> +DRM_DEBUG_KMS("PSR2 %ssupported\n",
>> + dev_priv->psr.sink_psr2_support ? "" : "not ");
> Would it make sense to make it clearer that PSR2 is not supported b/c of lack
> of y-coordinate support on the sink ?
>
> Reviewed-by: Tarun Vyas
Pushed to dinq, thanks for the patch and review.
BR,
Jani.
>>
>> if (dev_priv->psr.sink_psr2_support) {
>> dev_priv->psr.colorimetry_support =
>> --
>> 2.14.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
On 19/05/2018 10:04, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 15:42:00) On 18/05/2018 15:13, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 13:36:52) On 18/05/2018 13:28, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 12:50:41) On 18/05/2018 12:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 12:05:17) On 18/05/2018 11:09, Chris Wilson wrote: Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[ 239.094848] i915_gem_set_wedged Requests: <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, tail 02a8, batch 0x_] <7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000 <7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8 <7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8 <7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8 <7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10 <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle] <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260 <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002 <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled) <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @ 5164ms: igt/rcs0[5977]/8 <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @ 5165ms: igt/rcs0[5977]/2 <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @ 5165ms: igt/rcs0[5977]/3 <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @ 5164ms: igt/rcs0[5977]/2 <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @ 5165ms: igt/rcs0[5977]/4 <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99 where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! The RING_MODE indicates that is idle and has the STOP_RING bit set, so try clearing it. v2: Only clear the bit on restarting the ring, as we want to be sure the STOP_RING bit is kept if reset fails on wedging. v3: Spot when the ring state doesn't make sense when re-initialising the engine and dump it to the logs so that we don't have to wait for an error later and try to guess what happened earlier. v4: Prepare to print all the unexpected state, not just the first. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3744f5750624..ba8411ba4abf 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1781,6 +1781,9 @@ static void enable_execlists(struct intel_engine_cs *engine) I915_WRITE(RING_MODE_GEN7(engine), _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); + I915_WRITE(RING_MI_MODE(engine->mm
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Look for an active kernel context before switching (rev2)
== Series Details == Series: drm/i915: Look for an active kernel context before switching (rev2) URL : https://patchwork.freedesktop.org/series/43609/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4228_full -> Patchwork_9102_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9102_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9102_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43609/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9102_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP +1 igt@gem_mocs_settings@mocs-rc6-blt: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9102_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@bcs0-s3: shard-kbl: PASS -> INCOMPLETE (fdo#103665) +1 igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@dpms-vs-vblank-race: shard-apl: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS igt@kms_flip_tiling@flip-y-tiled: shard-glk: FAIL (fdo#104724) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4228 -> Patchwork_9102 CI_DRM_4228: 8e3e5c1cc5de96c61ff995282ab952ff5d47a211 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9102: 2fa6e902cd0d0a8680a4768a909d5808e23e7017 @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9102/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
Quoting Tvrtko Ursulin (2018-05-24 14:34:41) > > On 19/05/2018 10:04, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-05-18 15:42:00) > >> > >> On 18/05/2018 15:13, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2018-05-18 13:36:52) > > On 18/05/2018 13:28, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-05-18 12:50:41) > >> > >> On 18/05/2018 12:10, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2018-05-18 12:05:17) > > On 18/05/2018 11:09, Chris Wilson wrote: > > Inside the live_hangcheck (reset) selftests, we occasionally see > > failures like > > > > <7>[ 239.094840] i915_gem_set_wedged rcs0 > > <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, > > last 19a9a, hangcheck 0 [5158 ms] > > <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 > > (global 1) > > <7>[ 239.094848] i915_gem_set_wedged Requests: > > <7>[ 239.095052] i915_gem_set_wedged first 19a99 > > [e8c:5f] prio=1024 @ 5159ms: (null) > > <7>[ 239.095056] i915_gem_set_wedged last 19a9a > > [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 > > <7>[ 239.095059] i915_gem_set_wedged active 19a99 > > [e8c:5f] prio=1024 @ 5159ms: (null) > > <7>[ 239.095062] i915_gem_set_wedged [head 0220, > > postfix 0280, tail 02a8, batch 0x_] > > <7>[ 239.100050] i915_gem_set_wedged ring->start: > > 0x00283000 > > <7>[ 239.100053] i915_gem_set_wedged ring->head: > > 0x01f8 > > <7>[ 239.100055] i915_gem_set_wedged ring->tail: > > 0x02a8 > > <7>[ 239.100057] i915_gem_set_wedged ring->emit: > > 0x02a8 > > <7>[ 239.100059] i915_gem_set_wedged ring->space: > > 0x0f10 > > <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 > > <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 > > <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 > > <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 > > <7>[ 239.100097] i915_gem_set_wedged RING_MODE: > > 0x0300 [idle] > > <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe > > <7>[ 239.100104] i915_gem_set_wedged ACTHD: > > 0x_609c > > <7>[ 239.100108] i915_gem_set_wedged BBADDR: > > 0x_609d > > <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: > > 0x_00283260 > > <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x > > <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 > > <7>[ 239.100120] i915_gem_set_wedged Execlist status: > > 0x00044052 0002 > > <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 > > [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet > > queued? no (enabled) > > <7>[ 239.100128] i915_gem_set_wedged ELSP[0] > > count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ > > 5164ms: (null) > > <7>[ 239.100132] i915_gem_set_wedged ELSP[1] > > count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ > > 5164ms: igt/rcs0[5977]/1 > > <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 > > <7>[ 239.100250] i915_gem_set_wedged E 19a99 > > [e8c:5f] prio=1024 @ 5164ms: (null) > > <7>[ 239.100338] i915_gem_set_wedged E 19a9a > > [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 > > <7>[ 239.100340] i915_gem_set_wedged Queue > > priority: 139 > > <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] > > prio=132 @ 5164ms: igt/rcs0[5977]/8 > > <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] > > prio=121 @ 5165ms: igt/rcs0[5977]/2 > > <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] > > prio=82 @ 5165ms: igt/rcs0[5977]/3 > > <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] > > prio=44 @ 5164ms: igt/rcs0[5977]/2 > > <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] > > prio=20 @ 5165ms: igt/rcs0[5977]/4 > > <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] > > waiting for 19a99 > > > > where the GPU saw an arbitration point and idles; AND HAS NOT BEEN > > RESET! > > The RING_MODE indicates that is id
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add ChromeOS EC CEC Support (rev7)
== Series Details == Series: Add ChromeOS EC CEC Support (rev7) URL : https://patchwork.freedesktop.org/series/43162/ State : failure == Summary == Applying: media: cec-notifier: Get notifier by device and connector name Applying: drm/i915: hdmi: add CEC notifier to intel_hdmi Applying: mfd: cros-ec: Increase maximum mkbp event size Applying: mfd: cros-ec: Introduce CEC commands and events definitions. Applying: mfd: cros_ec_dev: Add CEC sub-device registration error: sha1 information is lacking or useless (drivers/mfd/cros_ec_dev.c). error: could not build fake ancestor Patch failed at 0005 mfd: cros_ec_dev: Add CEC sub-device registration The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/psr: Fix missed entry in PSR setup time table.
On Fri, 11 May 2018, Dhinakaran Pandiyan wrote:
> Entry corresponding to 220 us setup time was missing. I am not aware of
> any specific bug this fixes, but this could potentially result in enabling
> PSR on a panel with a higher setup time requirement than supported by the
> hardware.
>
> I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.
>
> Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä
> Cc: Jose Roberto de Souza
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Dhinakaran Pandiyan
Pushed to drm-misc-fixes with reviews picked up from the earlier posting
[1]. Doesn't look like the function is used by anyone other than i915,
so I didn't bother with further acks from non-Intel devs. Should be a
straightforward fix anyway.
BR,
Jani.
[1]
20180511005419.11199-1-dhinakaran.pandiyan@intel.com">http://mid.mail-archive.com/20180511005419.11199-1-dhinakaran.pandiyan@intel.com
> ---
> drivers/gpu/drm/drm_dp_helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 36c7609a4bd5..a7ba602a43a8 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1159,6 +1159,7 @@ int drm_dp_psr_setup_time(const u8
> psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
> static const u16 psr_setup_time_us[] = {
> PSR_SETUP_TIME(330),
> PSR_SETUP_TIME(275),
> + PSR_SETUP_TIME(220),
> PSR_SETUP_TIME(165),
> PSR_SETUP_TIME(110),
> PSR_SETUP_TIME(55),
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915/psr: Avoid unnecessary DPCD read of DP_PSR_CAPS
On Sun, 20 May 2018, Tarun Vyas wrote:
> On Fri, May 11, 2018 at 12:51:43PM -0700, Dhinakaran Pandiyan wrote:
>> intel_dp->psr_dpcd already has the required values.
>>
>> Cc: Jose Roberto de Souza
>> Signed-off-by: Dhinakaran Pandiyan
>> ---
>> drivers/gpu/drm/i915/intel_psr.c | 11 +--
>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_psr.c
>> b/drivers/gpu/drm/i915/intel_psr.c
>> index 61ade81576f5..381dbdbf30f4 100644
>> --- a/drivers/gpu/drm/i915/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>> @@ -201,15 +201,6 @@ void intel_psr_irq_handler(struct drm_i915_private
>> *dev_priv, u32 psr_iir)
>> }
>> }
>>
>> -static bool intel_dp_get_y_coord_required(struct intel_dp *intel_dp)
>> -{
>> -uint8_t psr_caps = 0;
>> -
>> -if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_CAPS, &psr_caps) != 1)
>> -return false;
>> -return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
>> -}
>> -
>> static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
>> {
>> uint8_t dprx = 0;
>> @@ -275,7 +266,7 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
>> * GTC first.
>> */
>> dev_priv->psr.sink_psr2_support =
>> -intel_dp_get_y_coord_required(intel_dp);
>> +intel_dp->psr_dpcd[1] &
>> DP_PSR2_SU_Y_COORDINATE_REQUIRED;
>> DRM_DEBUG_KMS("PSR2 %ssupported\n",
>>dev_priv->psr.sink_psr2_support ? "" : "not ");
> The drm_dp_dpcd_read itself reads the first 2 PSR DPCD bytes which is what is
> needed. Also, no other callers of intel_dp_get_y_coord_required exist. So,
>
> Reviewed-by: Tarun Vyas
The rest of the patches in the series pushed to dinq as well, thanks for
the patches and review.
BR,
Jani.
>>
>> --
>> 2.14.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
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: Allow DBLSCAN user modes with eDP/LVDS/DSI
== Series Details == Series: drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI URL : https://patchwork.freedesktop.org/series/43698/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4230 -> Patchwork_9104 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43698/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9104 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: fi-skl-6700k2: PASS -> FAIL (fdo#103191, fdo#104724) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-ilk-650: DMESG-WARN -> PASS igt@kms_chamelium@dp-crc-fast: fi-kbl-7500u: DMESG-FAIL (fdo#103841) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-a: fi-skl-6700k2: FAIL (fdo#103191, fdo#104724) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 == Participating hosts (44 -> 39) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4230 -> Patchwork_9104 CI_DRM_4230: 097c5e2d7cf300d1f9855a550bfdd5150410ffc4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9104: 82368323f7e2a1fbe3822bd2da4e1860f8ca418d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 82368323f7e2 drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9104/issues.html ___ 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: Special case kernel_context switch request
Hi Mika,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180517]
[cannot apply to drm-intel/for-linux-next v4.17-rc6 v4.17-rc5 v4.17-rc4
v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Prepare-GEM-for-suspend-earlier/20180524-214128
config: x86_64-randconfig-x015-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu//drm/i915/i915_gem_context.c: In function
'engine_has_idle_kernel_context':
>> drivers/gpu//drm/i915/i915_gem_context.c:608:15: error: 'struct
>> i915_request' has no member named 'gem_context'
if (rq && rq->gem_context != engine->i915->kernel_context)
^~
vim +608 drivers/gpu//drm/i915/i915_gem_context.c
596
597 static bool engine_has_idle_kernel_context(struct intel_engine_cs
*engine)
598 {
599 struct list_head * const active_rings =
&engine->i915->gt.active_rings;
600 struct intel_ring *ring;
601
602 lockdep_assert_held(&engine->i915->drm.struct_mutex);
603
604 list_for_each_entry(ring, active_rings, active_link) {
605 struct i915_request *rq =
606 last_request_on_engine(ring->timeline, engine);
607
> 608 if (rq && rq->gem_context !=
> engine->i915->kernel_context)
609 return false;
610 }
611
612 return intel_engine_has_kernel_context(engine);
613 }
614
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
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: Special case kernel_context switch request
Hi Mika,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20180517]
[cannot apply to drm-intel/for-linux-next v4.17-rc6 v4.17-rc5 v4.17-rc4
v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Prepare-GEM-for-suspend-earlier/20180524-214128
config: i386-randconfig-x071-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/bitops.h:16:0,
from include/linux/bitops.h:38,
from include/linux/log2.h:16,
from drivers/gpu//drm/i915/i915_gem_context.c:88:
drivers/gpu//drm/i915/i915_gem_context.c: In function
'engine_has_idle_kernel_context':
drivers/gpu//drm/i915/i915_gem_context.c:608:15: error: 'struct
i915_request' has no member named 'gem_context'
if (rq && rq->gem_context != engine->i915->kernel_context)
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu//drm/i915/i915_gem_context.c:608:3: note: in expansion of macro
>> 'if'
if (rq && rq->gem_context != engine->i915->kernel_context)
^~
drivers/gpu//drm/i915/i915_gem_context.c:608:15: error: 'struct
i915_request' has no member named 'gem_context'
if (rq && rq->gem_context != engine->i915->kernel_context)
^
include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu//drm/i915/i915_gem_context.c:608:3: note: in expansion of macro
>> 'if'
if (rq && rq->gem_context != engine->i915->kernel_context)
^~
drivers/gpu//drm/i915/i915_gem_context.c:608:15: error: 'struct
i915_request' has no member named 'gem_context'
if (rq && rq->gem_context != engine->i915->kernel_context)
^
include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^~~~
>> drivers/gpu//drm/i915/i915_gem_context.c:608:3: note: in expansion of macro
>> 'if'
if (rq && rq->gem_context != engine->i915->kernel_context)
^~
vim +/if +608 drivers/gpu//drm/i915/i915_gem_context.c
596
597 static bool engine_has_idle_kernel_context(struct intel_engine_cs
*engine)
598 {
599 struct list_head * const active_rings =
&engine->i915->gt.active_rings;
600 struct intel_ring *ring;
601
602 lockdep_assert_held(&engine->i915->drm.struct_mutex);
603
604 list_for_each_entry(ring, active_rings, active_link) {
605 struct i915_request *rq =
606 last_request_on_engine(ring->timeline, engine);
607
> 608 if (rq && rq->gem_context !=
> engine->i915->kernel_context)
609 return false;
610 }
611
612 return intel_engine_has_kernel_context(engine);
613 }
614
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Look for an active kernel context before switching
Chris Wilson writes:
> We were not very carefully checking to see if an older request on the
> engine was an earlier switch-to-kernel-context before deciding to emit a
> new switch. The end result would be that we could get into a permanent
> loop of trying to emit a new request to perform the switch simply to
> flush the existing switch.
>
> What we need is a means of tracking the completion of each timeline
> versus the kernel context, that is to detect if a more recent request
> has been submitted that would result in a switch away from the kernel
> context. To realise this, we need only to look in our syncmap on the
> kernel context and check that we have synchronized against all active
> rings.
>
> v2: Since all ringbuffer clients currently share the same timeline, we do
> have to use the gem_context to distinguish clients.
>
> As a bonus, include all the tracing used to debug the death inside
> suspend.
>
> v3: Test, test, test. Construct a selftest to exercise and assert the
> expected behaviour that multiple switch-to-contexts do not emit
> redundant requests.
>
> Reported-by: Mika Kuoppala
> Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
> timelines")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 7 +
> drivers/gpu/drm/i915/i915_gem.h | 3 +
> drivers/gpu/drm/i915/i915_gem_context.c | 86 +--
> drivers/gpu/drm/i915/i915_request.c | 5 +-
> .../gpu/drm/i915/selftests/i915_gem_context.c | 144 ++
> .../drm/i915/selftests/i915_mock_selftests.h | 1 +
> 6 files changed, 231 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 03874b50ada9..05f44ca35a06 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3703,6 +3703,9 @@ static int wait_for_engines(struct drm_i915_private
> *i915)
>
> int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int flags)
> {
> + GEM_TRACE("flags=%x (%s)\n",
> + flags, flags & I915_WAIT_LOCKED ? "locked" : "unlocked");
> +
> /* If the device is asleep, we have no requests outstanding */
> if (!READ_ONCE(i915->gt.awake))
> return 0;
> @@ -3719,6 +3722,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private
> *i915, unsigned int flags)
> return err;
> }
> i915_retire_requests(i915);
> + GEM_BUG_ON(i915->gt.active_requests);
>
> return wait_for_engines(i915);
> } else {
> @@ -4901,6 +4905,7 @@ static void assert_kernel_context_is_current(struct
> drm_i915_private *i915)
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
>
> + GEM_BUG_ON(i915->gt.active_requests);
> for_each_engine(engine, i915, id) {
>
> GEM_BUG_ON(__i915_gem_active_peek(&engine->timeline.last_request));
> GEM_BUG_ON(engine->last_retired_context->gem_context != kctx);
> @@ -4932,6 +4937,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
> struct drm_device *dev = &dev_priv->drm;
> int ret;
>
> + GEM_TRACE("\n");
> +
> intel_runtime_pm_get(dev_priv);
> intel_suspend_gt_powersave(dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index 5bf24cfc218c..62ee4e385365 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -63,9 +63,12 @@ struct drm_i915_private;
> #if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
> #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
> #define GEM_TRACE_DUMP() ftrace_dump(DUMP_ALL)
> +#define GEM_TRACE_DUMP_ON(expr) \
> + do { if (expr) ftrace_dump(DUMP_ALL); } while (0)
> #else
> #define GEM_TRACE(...) do { } while (0)
> #define GEM_TRACE_DUMP() do { } while (0)
> +#define GEM_TRACE_DUMP_ON(expr) BUILD_BUG_ON_INVALID(expr)
> #endif
>
> #define I915_NUM_ENGINES 8
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index b69b18ef8120..45393f6e0208 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -576,30 +576,72 @@ last_request_on_engine(struct i915_timeline *timeline,
> {
> struct i915_request *rq;
>
> - if (timeline == &engine->timeline)
> - return NULL;
> + GEM_BUG_ON(timeline == &engine->timeline);
>
> rq = i915_gem_active_raw(&timeline->last_request,
>&engine->i915->drm.struct_mutex);
> - if (rq && rq->engine == engine)
> + if (rq && rq->engine == engine) {
> + GEM_TRACE("last request for %s on engine %s: %llx:%d\n",
> + timeline->name, engine->name,
> + rq->fence.context, rq->fence.seqno);
> + GEM_BUG_ON(rq->timeline != timeline);
>
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/mm: Reject over-sized allocation requests early
Quoting Patchwork (2018-05-21 12:15:36) > == Series Details == > > Series: series starting with [v2,1/4] drm/mm: Reject over-sized allocation > requests early > URL : https://patchwork.freedesktop.org/series/43497/ > State : success > > == Summary == > > = CI Bug Log - changes from CI_DRM_4211_full -> Patchwork_9063_full = > > == Summary - WARNING == > > Minor unknown changes coming with Patchwork_9063_full need to be verified > manually. Selftests (including the new subtests) passed and no impacts observed on the driver. I've applied these to the drm-misc-next branch, so hopefully picking the right one. Thanks for the review, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Look for an active kernel context before switching
Quoting Mika Kuoppala (2018-05-24 15:40:47)
> Chris Wilson writes:
>
> > We were not very carefully checking to see if an older request on the
> > engine was an earlier switch-to-kernel-context before deciding to emit a
> > new switch. The end result would be that we could get into a permanent
> > loop of trying to emit a new request to perform the switch simply to
> > flush the existing switch.
> >
> > What we need is a means of tracking the completion of each timeline
> > versus the kernel context, that is to detect if a more recent request
> > has been submitted that would result in a switch away from the kernel
> > context. To realise this, we need only to look in our syncmap on the
> > kernel context and check that we have synchronized against all active
> > rings.
> >
> > v2: Since all ringbuffer clients currently share the same timeline, we do
> > have to use the gem_context to distinguish clients.
> >
> > As a bonus, include all the tracing used to debug the death inside
> > suspend.
> >
> > v3: Test, test, test. Construct a selftest to exercise and assert the
> > expected behaviour that multiple switch-to-contexts do not emit
> > redundant requests.
> >
> > Reported-by: Mika Kuoppala
> > Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
> > timelines")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 7 +
> > drivers/gpu/drm/i915/i915_gem.h | 3 +
> > drivers/gpu/drm/i915/i915_gem_context.c | 86 +--
> > drivers/gpu/drm/i915/i915_request.c | 5 +-
> > .../gpu/drm/i915/selftests/i915_gem_context.c | 144 ++
> > .../drm/i915/selftests/i915_mock_selftests.h | 1 +
> > 6 files changed, 231 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 03874b50ada9..05f44ca35a06 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3703,6 +3703,9 @@ static int wait_for_engines(struct drm_i915_private
> > *i915)
> >
> > int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int
> > flags)
> > {
> > + GEM_TRACE("flags=%x (%s)\n",
> > + flags, flags & I915_WAIT_LOCKED ? "locked" : "unlocked");
> > +
> > /* If the device is asleep, we have no requests outstanding */
> > if (!READ_ONCE(i915->gt.awake))
> > return 0;
> > @@ -3719,6 +3722,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private
> > *i915, unsigned int flags)
> > return err;
> > }
> > i915_retire_requests(i915);
> > + GEM_BUG_ON(i915->gt.active_requests);
> >
> > return wait_for_engines(i915);
> > } else {
> > @@ -4901,6 +4905,7 @@ static void assert_kernel_context_is_current(struct
> > drm_i915_private *i915)
> > struct intel_engine_cs *engine;
> > enum intel_engine_id id;
> >
> > + GEM_BUG_ON(i915->gt.active_requests);
> > for_each_engine(engine, i915, id) {
> >
> > GEM_BUG_ON(__i915_gem_active_peek(&engine->timeline.last_request));
> > GEM_BUG_ON(engine->last_retired_context->gem_context != kctx);
> > @@ -4932,6 +4937,8 @@ int i915_gem_suspend(struct drm_i915_private
> > *dev_priv)
> > struct drm_device *dev = &dev_priv->drm;
> > int ret;
> >
> > + GEM_TRACE("\n");
> > +
> > intel_runtime_pm_get(dev_priv);
> > intel_suspend_gt_powersave(dev_priv);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.h
> > b/drivers/gpu/drm/i915/i915_gem.h
> > index 5bf24cfc218c..62ee4e385365 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.h
> > +++ b/drivers/gpu/drm/i915/i915_gem.h
> > @@ -63,9 +63,12 @@ struct drm_i915_private;
> > #if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
> > #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
> > #define GEM_TRACE_DUMP() ftrace_dump(DUMP_ALL)
> > +#define GEM_TRACE_DUMP_ON(expr) \
> > + do { if (expr) ftrace_dump(DUMP_ALL); } while (0)
> > #else
> > #define GEM_TRACE(...) do { } while (0)
> > #define GEM_TRACE_DUMP() do { } while (0)
> > +#define GEM_TRACE_DUMP_ON(expr) BUILD_BUG_ON_INVALID(expr)
> > #endif
> >
> > #define I915_NUM_ENGINES 8
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index b69b18ef8120..45393f6e0208 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -576,30 +576,72 @@ last_request_on_engine(struct i915_timeline *timeline,
> > {
> > struct i915_request *rq;
> >
> > - if (timeline == &engine->timeline)
> > - return NULL;
> > + GEM_BUG_ON(timeline == &engine->timeline);
> >
> > rq = i915_gem_active_raw(&timeline->last_request,
> >&engine->i915->drm.struct_mutex);
> > - if (rq && rq->engine == engi
[Intel-gfx] [PATCH v7 4/7] drm/i915/perf: reuse intel_lrc ctx regs macro
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 805dfc732bba..a5d98bda5c2e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -210,6 +210,7 @@
#include "i915_oa_cflgt3.h"
#include "i915_oa_cnl.h"
#include "i915_oa_icl.h"
+#include "intel_lrc_reg.h"
/* HW requires this to be a power of two, between 128k and 16M, though driver
* is currently generally designed assuming the largest 16M size is used such
@@ -1579,27 +1580,25 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
/* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
+ i915_reg_t flex_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+ EU_PERF_CNTL2,
+ EU_PERF_CNTL3,
+ EU_PERF_CNTL4,
+ EU_PERF_CNTL5,
+ EU_PERF_CNTL6,
};
int i;
- reg_state[ctx_oactxctrl] = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- reg_state[ctx_oactxctrl+1] = (dev_priv->perf.oa.period_exponent <<
- GEN8_OA_TIMER_PERIOD_SHIFT) |
-(dev_priv->perf.oa.periodic ?
- GEN8_OA_TIMER_ENABLE : 0) |
-GEN8_OA_COUNTER_RESUME;
+ CTX_REG(reg_state, ctx_oactxctrl, GEN8_OACTXCONTROL,
+ (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME);
- for (i = 0; i < ARRAY_SIZE(flex_mmio); i++) {
+ for (i = 0; i < ARRAY_SIZE(flex_regs); i++) {
u32 state_offset = ctx_flexeu0 + i * 2;
- u32 mmio = flex_mmio[i];
+ u32 mmio = i915_mmio_reg_offset(flex_regs[i]);
/*
* This arbitrary default will select the 'EU FPU0 Pipeline
@@ -1619,8 +1618,7 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
}
}
- reg_state[state_offset] = mmio;
- reg_state[state_offset+1] = value;
+ CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 3/7] drm/i915/perf: simplify configure all context function
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 4f0eb84b3c00..805dfc732bba 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1762,7 +1762,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
if (ret)
- goto out;
+ return ret;
/*
* The OA register config is setup through the context image. This image
@@ -1779,7 +1779,7 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
*/
ret = i915_gem_wait_for_idle(dev_priv, wait_flags);
if (ret)
- goto out;
+ return ret;
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
@@ -1791,10 +1791,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
continue;
regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
- if (IS_ERR(regs)) {
- ret = PTR_ERR(regs);
- goto out;
- }
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
@@ -1804,7 +1802,6 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
i915_gem_object_unpin_map(ce->state->obj);
}
- out:
return ret;
}
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/7] drm/i915: Record the sseu configuration per-context & engine
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_gem_context.h | 17 +
drivers/gpu/drm/i915/i915_request.h | 10 ++
drivers/gpu/drm/i915/intel_lrc.c| 22 +++---
4 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b69b18ef8120..c5ad468dae56 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -282,6 +282,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = &ctx->__engine[n];
ce->gem_context = ctx;
+ /* Use the whole device by default */
+ ce->sseu =
intel_sseu_from_device_sseu(&INTEL_INFO(dev_priv)->sseu);
}
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index c3262b4dd2ee..3389b5249342 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -30,6 +30,7 @@
#include
#include "i915_gem.h"
+#include "intel_device_info.h"
struct pid;
@@ -157,6 +158,9 @@ struct i915_gem_context {
int pin_count;
const struct intel_context_ops *ops;
+
+ /** sseu: Control eu/slice partitioning */
+ struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
@@ -335,4 +339,17 @@ static inline void i915_gem_context_put(struct
i915_gem_context *ctx)
kref_put(&ctx->ref, i915_gem_context_release);
}
+static inline struct intel_sseu
+intel_sseu_from_device_sseu(const struct sseu_dev_info *sseu)
+{
+ struct intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
#endif /* !__I915_GEM_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 17a9fa03..82c5dd153bfd 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,16 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c2500c209c63..a8e139f7c337 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2481,8 +2481,8 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu,
+struct intel_sseu ctx_sseu)
{
u32 rpcs = 0;
@@ -2492,24 +2492,23 @@ make_rpcs(struct drm_i915_private *dev_priv)
* must make an explicit request through RPCS for full
* enablement.
*/
- if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+ if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
- GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= hweight8(ctx_sseu.slice_mask) << GEN8_RPCS_S_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
- if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+ if (sseu->has_subslice_pg) {
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]) <<
+ rpcs |= hweight8(ctx_sseu.subslice_mask) <<
GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
[Intel-gfx] [PATCH v7 0/7] drm/i915: per context slice/subslice powergating
Hi all, This iteration addresses the last round of review. The last remaining open is on how to deal contexts setting powergating configurations while the sysfs entry disallow the setting. Tvrtko proposed to just silently ignore it and just set it when the sysfs entry allow it. The currently implementation return EPERM when not allowed. Cheers, Chris Wilson (3): drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin (4): drm/i915/perf: simplify configure all context function drm/i915/perf: reuse intel_lrc ctx regs macro drm/i915/perf: lock powergating configuration to default when active drm/i915: add a sysfs entry to let users set sseu configs drivers/gpu/drm/i915/i915_drv.h | 35 drivers/gpu/drm/i915/i915_gem.c | 2 + drivers/gpu/drm/i915/i915_gem_context.c | 228 drivers/gpu/drm/i915/i915_gem_context.h | 17 ++ drivers/gpu/drm/i915/i915_perf.c| 69 +++ drivers/gpu/drm/i915/i915_request.c | 20 +++ drivers/gpu/drm/i915/i915_request.h | 10 ++ drivers/gpu/drm/i915/i915_sysfs.c | 40 + drivers/gpu/drm/i915/intel_lrc.c| 117 +++- drivers/gpu/drm/i915/intel_lrc.h| 3 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + drivers/gpu/drm/i915/intel_ringbuffer.h | 4 + include/uapi/drm/i915_drm.h | 43 + 13 files changed, 516 insertions(+), 74 deletions(-) -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 7/7] drm/i915: add a sysfs entry to let users set sseu configs
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
v2: Rename sysfs entry (Tvrtko)
Lock interruptible the device in sysfs (Tvrtko)
Fix dropped error code in getting dynamic sseu value (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6
drivers/gpu/drm/i915/i915_gem_context.c | 47 -
drivers/gpu/drm/i915/i915_sysfs.c | 40 +
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 916a301d8c22..3db75c56a9f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1842,6 +1842,8 @@ struct drm_i915_private {
struct ida hw_ida;
#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+
+ bool dynamic_sseu;
} contexts;
u32 fdi_rx_config;
@@ -3275,6 +3277,10 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+int i915_gem_contexts_set_dynamic_sseu_locked(struct drm_i915_private *i915,
+ bool allowed);
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915);
+
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 30736efe0fcd..afb7db95aa3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -983,7 +983,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev,
void *data,
break;
}
- if (!capable(CAP_SYS_ADMIN)) {
+ if (!i915->contexts.dynamic_sseu &&
+ !capable(CAP_SYS_ADMIN)) {
ret = -EPERM;
break;
}
@@ -1065,6 +1066,50 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
return ret;
}
+int i915_gem_contexts_set_dynamic_sseu_locked(struct drm_i915_private *i915,
+ bool allowed)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+ int ret = 0;
+
+ lockdep_assert_held(&i915->drm.struct_mutex);
+
+ if (!engine->emit_rpcs_config)
+ return -ENODEV;
+
+ /*
+* When we allow each context to configure its powergating
+* configuration, there is no need to put the configurations back to
+* the default, it should already be the case.
+*/
+ if (!allowed) {
+ struct intel_sseu default_sseu =
+ intel_sseu_from_device_sseu(&INTEL_INFO(i915)->sseu);
+ struct i915_gem_context *ctx;
+
+ list_for_each_entry(ctx, &i915->contexts.list, link) {
+ ret = i915_gem_context_reconfigure_sseu(ctx, engine,
+ default_sseu);
+ if (ret)
+ break;
+ }
+ }
+
+ i915->contexts.dynamic_sseu = allowed;
+
+ return ret;
+}
+
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+
+ if (!engine->emit_rpcs_config)
+ return false;
+
+ return i915->contexts.dynamic_sseu;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_context.c"
#include "selftests/i915_gem_context.c"
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index e5e6f6bb2b05..c323cab59ec7 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -483,6 +483,44 @@ static ssize_t gt_rp_mhz_show(struct device *kdev, struct
device_attribute *attr
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
+static ssize_t allow_dynamic_sseu_show(struct device *kdev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
+ bool value = i915_gem_contexts_get_dynamic_sseu(i915);
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", value);
+}
+
+static ssize_t allow_dynamic_sseu_store(struct device *kdev,
+ struct device_attribute *attr,
+ const char *buf, s
[Intel-gfx] [PATCH v7 6/7] drm/i915: Expose RPCS (SSEU) configuration to userspace
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.
The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.
We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,
struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
.instance = 0, };
memset(&arg, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) &sseu;
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &arg) == 0) {
sseu.packed.subslice_mask = 0;
drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &arg);
}
could be used to disable all subslices where supported.
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
c: Dmitry Rogozhkin
CC: Tvrtko Ursulin
CC: Zhipeng Gong
CC: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 13 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +
drivers/gpu/drm/i915/i915_gem_context.c | 181
drivers/gpu/drm/i915/i915_request.c | 20 +++
drivers/gpu/drm/i915/intel_lrc.c| 103 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
include/uapi/drm/i915_drm.h | 43 ++
8 files changed, 333 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f491784b2516..916a301d8c22 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2066,6 +2066,12 @@ struct drm_i915_private {
u32 active_requests;
u32 request_serial;
+ /**
+* Global barrier to ensuring ordering of sseu transitions
+* requests.
+*/
+ struct i915_gem_active global_barrier;
+
/**
* Is the GPU currently considered idle, or busy executing
* userspace requests? Whilst idle, we allow runtime power
@@ -3228,6 +3234,13 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
return container_of(vm, struct i915_hw_ppgtt, base);
}
+static inline void i915_gem_set_global_barrier(struct drm_i915_private *i915,
+ struct i915_request *rq)
+{
+ lockdep_assert_held(&i915->drm.struct_mutex);
+ i915_gem_active_set(&i915->gt.global_barrier, rq);
+}
+
/* i915_gem_fence_reg.c */
struct drm_i915_fence_reg *
i915_reserve_fence(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 03874b50ada9..9c2a0d04bd39 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5548,6 +5548,8 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
if (!dev_priv->priorities)
goto err_dependencies;
+ init_request_active(&dev_priv->gt.global_barrier, NULL);
+
INIT_LIST_HEAD(&dev_priv->gt.timelines);
INIT_LIST_HEAD(&dev_priv->gt.active_rings);
INIT_LIST_HEAD(&dev_priv->gt.closed_vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index c5ad468dae56..30736efe0fcd 100644
--- a/drivers/gpu/drm/i915/i915_gem_cont
[Intel-gfx] [PATCH v7 5/7] drm/i915/perf: lock powergating configuration to default when active
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 16
drivers/gpu/drm/i915/i915_perf.c | 24 +++-
drivers/gpu/drm/i915/intel_lrc.c | 11 +++
drivers/gpu/drm/i915/intel_lrc.h | 3 +++
4 files changed, 45 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 487922f88b76..f491784b2516 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2744,6 +2744,22 @@ int intel_engines_init(struct drm_i915_private
*dev_priv);
u32 intel_calculate_mcr_s_ss_select(struct drm_i915_private *dev_priv);
+static inline struct intel_sseu
+intel_engine_prepare_sseu(struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ /*
+* If i915/perf is active, we want a stable powergating configuration
+* on the system. The most natural configuration to take in that case
+* is the default (i.e maximum the hardware can do).
+*/
+ return i915->perf.oa.exclusive_stream ?
+ intel_sseu_from_device_sseu(&INTEL_INFO(i915)->sseu) :
+ sseu;
+}
+
/* intel_hotplug.c */
void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
u32 pin_mask, u32 long_mask);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a5d98bda5c2e..4750a6436737 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1574,7 +1574,8 @@ static void hsw_disable_metric_set(struct
drm_i915_private *dev_priv)
*/
static void gen8_update_reg_state_unlocked(struct i915_gem_context *ctx,
u32 *reg_state,
- const struct i915_oa_config
*oa_config)
+ const struct i915_oa_config
*oa_config,
+ struct intel_sseu sseu)
{
struct drm_i915_private *dev_priv = ctx->i915;
u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
@@ -1620,6 +1621,9 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(&INTEL_INFO(dev_priv)->sseu, sseu));
}
/*
@@ -1751,6 +1755,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
const struct i915_oa_config *oa_config)
{
struct intel_engine_cs *engine = dev_priv->engine[RCS];
+ struct intel_sseu default_sseu =
+ intel_sseu_from_device_sseu(&INTEL_INFO(dev_priv)->sseu);
struct i915_gem_context *ctx;
int ret;
unsigned int wait_flags = I915_WAIT_LOCKED;
@@ -1795,7 +1801,8 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
ce->state->obj->mm.dirty = true;
regs += LRC_STATE_PN * PAGE_SIZE / sizeof(*regs);
- gen8_update_reg_state_unlocked(ctx, regs, oa_config);
+
[Intel-gfx] [PATCH v7 1/7] drm/i915: Program RPCS for Broadwell
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 857ab04452f0..c2500c209c63 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2486,13 +2486,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
{
u32 rpcs = 0;
- /*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
- */
- if (INTEL_GEN(dev_priv) < 9)
- return 0;
-
/*
* Starting in Gen9, render power gating can leave
* slice/subslice/EU in a partially enabled state. We
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/trace: Describe engines as class:instance pairs
From: Tvrtko Ursulin
Instead of using the engine->id, use uabi_class:instance pairs in trace-
points including engine info.
This will be more readable, more future proof and more stable for
userspace consumption.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: svetlana.kukan...@intel.com
---
drivers/gpu/drm/i915/i915_trace.h | 107 ++
1 file changed, 65 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 5d4f78765083..3465cc1f9345 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -591,21 +591,26 @@ TRACE_EVENT(i915_gem_ring_sync_to,
TP_STRUCT__entry(
__field(u32, dev)
-__field(u32, sync_from)
-__field(u32, sync_to)
+__field(u32, from_class)
+__field(u32, from_instance)
+__field(u32, to_class)
+__field(u32, to_instance)
__field(u32, seqno)
),
TP_fast_assign(
__entry->dev = from->i915->drm.primary->index;
- __entry->sync_from = from->engine->id;
- __entry->sync_to = to->engine->id;
+ __entry->from_class = from->engine->uabi_class;
+ __entry->from_instance = from->engine->instance;
+ __entry->to_class = to->engine->uabi_class;
+ __entry->to_instance = to->engine->instance;
__entry->seqno = from->global_seqno;
),
- TP_printk("dev=%u, sync-from=%u, sync-to=%u, seqno=%u",
+ TP_printk("dev=%u, sync-from=%u:%u, sync-to=%u:%u, seqno=%u",
__entry->dev,
- __entry->sync_from, __entry->sync_to,
+ __entry->from_class, __entry->from_instance,
+ __entry->to_class, __entry->to_instance,
__entry->seqno)
);
@@ -616,7 +621,8 @@ TRACE_EVENT(i915_request_queue,
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, hw_id)
-__field(u32, ring)
+__field(u32, class)
+__field(u32, instance)
__field(u32, ctx)
__field(u32, seqno)
__field(u32, flags)
@@ -625,15 +631,17 @@ TRACE_EVENT(i915_request_queue,
TP_fast_assign(
__entry->dev = rq->i915->drm.primary->index;
__entry->hw_id = rq->gem_context->hw_id;
- __entry->ring = rq->engine->id;
+ __entry->class = rq->engine->uabi_class;
+ __entry->instance = rq->engine->instance;
__entry->ctx = rq->fence.context;
__entry->seqno = rq->fence.seqno;
__entry->flags = flags;
),
- TP_printk("dev=%u, hw_id=%u, ring=%u, ctx=%u, seqno=%u, flags=0x%x",
- __entry->dev, __entry->hw_id, __entry->ring, __entry->ctx,
- __entry->seqno, __entry->flags)
+ TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
flags=0x%x",
+ __entry->dev, __entry->hw_id, __entry->class,
+ __entry->instance, __entry->ctx, __entry->seqno,
+ __entry->flags)
);
DECLARE_EVENT_CLASS(i915_request,
@@ -643,7 +651,8 @@ DECLARE_EVENT_CLASS(i915_request,
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, hw_id)
-__field(u32, ring)
+__field(u32, class)
+__field(u32, instance)
__field(u32, ctx)
__field(u32, seqno)
__field(u32, global)
@@ -652,15 +661,17 @@ DECLARE_EVENT_CLASS(i915_request,
TP_fast_assign(
__entry->dev = rq->i915->drm.primary->index;
__entry->hw_id = rq->gem_context->hw_id;
- __entry->ring = rq->engine->id;
+ __entry->class = rq->engine->uabi_class;
+ __entry->instance = rq->engine->instance;
__entry->ctx = rq->fence.context;
__entry->seqno = rq->fence.seqno;
__entry->global = rq->global_seqno;
),
- TP_printk("dev=%u, hw_id=%u, ring=%u, ctx=%u, seqno=%u,
[Intel-gfx] [PATCH 2/2] drm/i915/trace: Remove engine out of the context sandwich
From: Tvrtko Ursulin
In the string tracepoint representation we ended up with the engine
sandwiched between context hardware id and context fence id.
Move the two pieces of context data together and consolidate for
redability using the format of ctx=hw_id:fence_context_id.
Binary records are left as is, that is both fields remaing under the
existing name and ordering.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_trace.h | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 3465cc1f9345..ab67b1661de4 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -638,9 +638,9 @@ TRACE_EVENT(i915_request_queue,
__entry->flags = flags;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
flags=0x%x",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, flags=0x%x",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->flags)
);
@@ -668,9 +668,9 @@ DECLARE_EVENT_CLASS(i915_request,
__entry->global = rq->global_seqno;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
global=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, global=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global)
);
@@ -718,9 +718,9 @@ TRACE_EVENT(i915_request_in,
__entry->port = port;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
prio=%u, global=%u, port=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, prio=%u,
global=%u, port=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->prio, __entry->global_seqno, __entry->port)
);
@@ -750,9 +750,9 @@ TRACE_EVENT(i915_request_out,
__entry->completed = i915_request_completed(rq);
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u,
seqno=%u, global=%u, completed?=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u,
global=%u, completed?=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global_seqno, __entry->completed)
);
@@ -842,9 +842,9 @@ TRACE_EVENT(i915_request_wait_begin,
__entry->flags = flags;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
global=%u, blocking=%u, flags=0x%x",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, global=%u,
blocking=%u, flags=0x%x",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global, !!(__entry->flags & I915_WAIT_LOCKED),
__entry->flags)
);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915: Include i915_scheduler.h from i915_gem_context.h
From: Tvrtko Ursulin struct i915_gem_context embeds structr i915_sched_attr so needs to include the respective header. Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_gem_context.h b/drivers/gpu/drm/i915/i915_gem_context.h index c3262b4dd2ee..84fef3b1e6e4 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.h +++ b/drivers/gpu/drm/i915/i915_gem_context.h @@ -30,6 +30,7 @@ #include #include "i915_gem.h" +#include "i915_scheduler.h" struct pid; -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915: Forward declare struct intel_context
From: Tvrtko Ursulin
This is to avoid an error with structure declared in parameter list if the
include ordering changes.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 84fef3b1e6e4..b116e4942c10 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -46,6 +46,8 @@ struct intel_ring;
#define DEFAULT_CONTEXT_HANDLE 0
+struct intel_context;
+
struct intel_context_ops {
void (*unpin)(struct intel_context *ce);
void (*destroy)(struct intel_context *ce);
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/trace: Describe engines as class:instance pairs
Quoting Tvrtko Ursulin (2018-05-24 16:04:46) > From: Tvrtko Ursulin > > Instead of using the engine->id, use uabi_class:instance pairs in trace- > points including engine info. Should we not pack dev,hw_id,class,instance into u16s? > This will be more readable, more future proof and more stable for > userspace consumption. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson > Cc: svetlana.kukan...@intel.com > --- > @@ -616,7 +621,8 @@ TRACE_EVENT(i915_request_queue, > TP_STRUCT__entry( > __field(u32, dev) > __field(u32, hw_id) > -__field(u32, ring) > +__field(u32, class) > +__field(u32, instance) > __field(u32, ctx) ctx needs u64 :( I've no objection to switching to our hopefully futureproof uabi nomenclature. 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 2/2] drm/i915/trace: Remove engine out of the context sandwich
Quoting Tvrtko Ursulin (2018-05-24 16:04:47) > From: Tvrtko Ursulin > > In the string tracepoint representation we ended up with the engine > sandwiched between context hardware id and context fence id. > > Move the two pieces of context data together and consolidate for > redability using the format of ctx=hw_id:fence_context_id. Grr, bring backs my memory of ctx being the most important! In order of segregation, I think of it as device+context as being the outer container (a user isn't meant to escape their context). The timelines and engines they use are all contained within their context. But what we call ctx here isn't really context, but timeline; how about if we switch to the fence=%llx:%d representation we've mostly settled on for the debug messages? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 7/7] drm/i915: add a sysfs entry to let users set sseu configs
On 24/05/2018 15:54, Lionel Landwerlin wrote:
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
v2: Rename sysfs entry (Tvrtko)
Lock interruptible the device in sysfs (Tvrtko)
Fix dropped error code in getting dynamic sseu value (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6
drivers/gpu/drm/i915/i915_gem_context.c | 47 -
drivers/gpu/drm/i915/i915_sysfs.c | 40 +
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 916a301d8c22..3db75c56a9f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1842,6 +1842,8 @@ struct drm_i915_private {
struct ida hw_ida;
#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+
+ bool dynamic_sseu;
} contexts;
u32 fdi_rx_config;
@@ -3275,6 +3277,10 @@ i915_gem_context_lookup(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+int i915_gem_contexts_set_dynamic_sseu_locked(struct drm_i915_private *i915,
+ bool allowed);
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915);
+
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 30736efe0fcd..afb7db95aa3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -983,7 +983,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev,
void *data,
break;
}
- if (!capable(CAP_SYS_ADMIN)) {
+ if (!i915->contexts.dynamic_sseu &&
+ !capable(CAP_SYS_ADMIN)) {
ret = -EPERM;
break;
}
@@ -1065,6 +1066,50 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev,
return ret;
}
+int i915_gem_contexts_set_dynamic_sseu_locked(struct drm_i915_private *i915,
+ bool allowed)
I think you can drop the _locked suffix since we normally only use it
when there are two flavours of otherwise the same function name. And you
have lockdep_assert_held so that makes it obvious.
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+ int ret = 0;
+
+ lockdep_assert_held(&i915->drm.struct_mutex);
+
+ if (!engine->emit_rpcs_config)
+ return -ENODEV;
+
+ /*
+* When we allow each context to configure its powergating
+* configuration, there is no need to put the configurations back to
+* the default, it should already be the case.
+*/
+ if (!allowed) {
Do you want to optimize with "if (!allowed && i915->context.dynamic_sseu)"?
+ struct intel_sseu default_sseu =
+ intel_sseu_from_device_sseu(&INTEL_INFO(i915)->sseu);
Quick grep around patches tells me this function is always called with
the same parameter. Unless I missed something perhaps it would be more
readable to rename it to something shorter. Like maybe:
default_sseu = intel_device_default_sseu(i915);
Just thinking if that would read nicer than &INTEL_INFO(i915)->sseu
everywhere?
Regards,
Tvrtko
+ struct i915_gem_context *ctx;
+
+ list_for_each_entry(ctx, &i915->contexts.list, link) {
+ ret = i915_gem_context_reconfigure_sseu(ctx, engine,
+ default_sseu);
+ if (ret)
+ break;
+ }
+ }
+
+ i915->contexts.dynamic_sseu = allowed;
+
+ return ret;
+}
+
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+
+ if (!engine->emit_rpcs_config)
+ return false;
+
+ return i915->contexts.dynamic_sseu;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_context.c"
#include "selftests/i915_gem_context.c"
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index e5e6f6bb2b05..c323cab59ec7 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -483,6 +483,44 @@ static ssize_t gt_rp_mh
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: per context slice/subslice powergating (rev6)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev6) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim checkpatch origin/drm-tip 966969f546ac drm/i915: Program RPCS for Broadwell eb3c2a521a10 drm/i915: Record the sseu configuration per-context & engine 16d9bb4e86fc drm/i915/perf: simplify configure all context function 763f9dc06a15 drm/i915/perf: reuse intel_lrc ctx regs macro d099dffee67c drm/i915/perf: lock powergating configuration to default when active 957b375e185c drm/i915: Expose RPCS (SSEU) configuration to userspace -:40: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #40: v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel) total: 0 errors, 1 warnings, 0 checks, 456 lines checked 9873e890b9cd drm/i915: add a sysfs entry to let users set sseu configs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/trace: Describe engines as class:instance pairs
On 24/05/2018 16:29, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-24 16:04:46) From: Tvrtko Ursulin Instead of using the engine->id, use uabi_class:instance pairs in trace- points including engine info. Should we not pack dev,hw_id,class,instance into u16s? Can do. This will be more readable, more future proof and more stable for userspace consumption. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: svetlana.kukan...@intel.com --- @@ -616,7 +621,8 @@ TRACE_EVENT(i915_request_queue, TP_STRUCT__entry( __field(u32, dev) __field(u32, hw_id) -__field(u32, ring) +__field(u32, class) +__field(u32, instance) __field(u32, ctx) ctx needs u64 :( I've no objection to switching to our hopefully futureproof uabi nomenclature. Reviewed-by: Chris Wilson Thanks, I'll grow the series with all of the above. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: per context slice/subslice powergating (rev6)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev6) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Program RPCS for Broadwell Okay! Commit: drm/i915: Record the sseu configuration per-context & engine Okay! Commit: drm/i915/perf: simplify configure all context function Okay! Commit: drm/i915/perf: reuse intel_lrc ctx regs macro Okay! Commit: drm/i915/perf: lock powergating configuration to default when active -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3680:16: warning: expression using sizeof(void) Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace -drivers/gpu/drm/i915/selftests/../i915_drv.h:3680:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3693:16: warning: expression using sizeof(void) Commit: drm/i915: add a sysfs entry to let users set sseu configs -drivers/gpu/drm/i915/selftests/../i915_drv.h:3693:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3699:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/trace: Remove engine out of the context sandwich
On 24/05/2018 16:33, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-24 16:04:47) From: Tvrtko Ursulin In the string tracepoint representation we ended up with the engine sandwiched between context hardware id and context fence id. Move the two pieces of context data together and consolidate for redability using the format of ctx=hw_id:fence_context_id. Grr, bring backs my memory of ctx being the most important! I knew it! :)) In order of segregation, I think of it as device+context as being the outer container (a user isn't meant to escape their context). The timelines and engines they use are all contained within their context. If I move ctx before engine, then seqno is left to hang after the engine. And honestly I forgot all my arguments in this topic. By the virtue of exhaustion I am prepared to give in. :)) But what we call ctx here isn't really context, but timeline; how about if we switch to the fence=%llx:%d representation we've mostly settled on for the debug messages? For the ctx and seqno pair? But here we have the additional issue of hw_id. I think context is better than timeline at this level. Or you mean keep explicit hw_id and join ctx and seqno into fence=%llx:%d? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/trace: Remove engine out of the context sandwich
On 24/05/18 16:04, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the string tracepoint representation we ended up with the engine
sandwiched between context hardware id and context fence id.
Move the two pieces of context data together and consolidate for
redability using the format of ctx=hw_id:fence_context_id.
Arg! Will need to update the tracepoint parser in igt :(
Binary records are left as is, that is both fields remaing under the
existing name and ordering.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_trace.h | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 3465cc1f9345..ab67b1661de4 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -638,9 +638,9 @@ TRACE_EVENT(i915_request_queue,
__entry->flags = flags;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u, flags=0x%x",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, flags=0x%x",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->flags)
);
@@ -668,9 +668,9 @@ DECLARE_EVENT_CLASS(i915_request,
__entry->global = rq->global_seqno;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u, global=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, global=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global)
);
@@ -718,9 +718,9 @@ TRACE_EVENT(i915_request_in,
__entry->port = port;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u, prio=%u, global=%u, port=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, prio=%u,
global=%u, port=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->prio, __entry->global_seqno, __entry->port)
);
@@ -750,9 +750,9 @@ TRACE_EVENT(i915_request_out,
__entry->completed = i915_request_completed(rq);
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u, global=%u, completed?=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, global=%u,
completed?=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global_seqno, __entry->completed)
);
@@ -842,9 +842,9 @@ TRACE_EVENT(i915_request_wait_begin,
__entry->flags = flags;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u, global=%u, blocking=%u, flags=0x%x",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u, global=%u,
blocking=%u, flags=0x%x",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global, !!(__entry->flags & I915_WAIT_LOCKED),
__entry->flags)
);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/trace: Remove engine out of the context sandwich
On 24/05/2018 16:48, Lionel Landwerlin wrote:
On 24/05/18 16:04, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the string tracepoint representation we ended up with the engine
sandwiched between context hardware id and context fence id.
Move the two pieces of context data together and consolidate for
redability using the format of ctx=hw_id:fence_context_id.
Arg! Will need to update the tracepoint parser in igt :(
I'll leave them separate then, was mostly aiming to remove engine out of
the sandwich.
Regards,
Tvrtko
Binary records are left as is, that is both fields remaing under the
existing name and ordering.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_trace.h | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 3465cc1f9345..ab67b1661de4 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -638,9 +638,9 @@ TRACE_EVENT(i915_request_queue,
__entry->flags = flags;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
flags=0x%x",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u,
flags=0x%x",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->flags)
);
@@ -668,9 +668,9 @@ DECLARE_EVENT_CLASS(i915_request,
__entry->global = rq->global_seqno;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
global=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u,
global=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global)
);
@@ -718,9 +718,9 @@ TRACE_EVENT(i915_request_in,
__entry->port = port;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
prio=%u, global=%u, port=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u,
prio=%u, global=%u, port=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->prio, __entry->global_seqno, __entry->port)
);
@@ -750,9 +750,9 @@ TRACE_EVENT(i915_request_out,
__entry->completed = i915_request_completed(rq);
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u,
seqno=%u, global=%u, completed?=%u",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u,
global=%u, completed?=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global_seqno, __entry->completed)
);
@@ -842,9 +842,9 @@ TRACE_EVENT(i915_request_wait_begin,
__entry->flags = flags;
),
- TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
global=%u, blocking=%u, flags=0x%x",
- __entry->dev, __entry->hw_id, __entry->class,
- __entry->instance, __entry->ctx, __entry->seqno,
+ TP_printk("dev=%u, engine=%u:%u, ctx=%u:%u, seqno=%u,
global=%u, blocking=%u, flags=0x%x",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->hw_id, __entry->ctx, __entry->seqno,
__entry->global, !!(__entry->flags & I915_WAIT_LOCKED),
__entry->flags)
);
___
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 1/2] drm/i915/trace: Describe engines as class:instance pairs
On 24/05/18 16:04, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Instead of using the engine->id, use uabi_class:instance pairs in trace-
points including engine info.
This will be more readable, more future proof and more stable for
userspace consumption.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: svetlana.kukan...@intel.com
Don't you want engine->uabi_id instead of engine->instance ?
---
drivers/gpu/drm/i915/i915_trace.h | 107 ++
1 file changed, 65 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 5d4f78765083..3465cc1f9345 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -591,21 +591,26 @@ TRACE_EVENT(i915_gem_ring_sync_to,
TP_STRUCT__entry(
__field(u32, dev)
-__field(u32, sync_from)
-__field(u32, sync_to)
+__field(u32, from_class)
+__field(u32, from_instance)
+__field(u32, to_class)
+__field(u32, to_instance)
__field(u32, seqno)
),
TP_fast_assign(
__entry->dev = from->i915->drm.primary->index;
- __entry->sync_from = from->engine->id;
- __entry->sync_to = to->engine->id;
+ __entry->from_class = from->engine->uabi_class;
+ __entry->from_instance = from->engine->instance;
+ __entry->to_class = to->engine->uabi_class;
+ __entry->to_instance = to->engine->instance;
__entry->seqno = from->global_seqno;
),
- TP_printk("dev=%u, sync-from=%u, sync-to=%u, seqno=%u",
+ TP_printk("dev=%u, sync-from=%u:%u, sync-to=%u:%u, seqno=%u",
__entry->dev,
- __entry->sync_from, __entry->sync_to,
+ __entry->from_class, __entry->from_instance,
+ __entry->to_class, __entry->to_instance,
__entry->seqno)
);
@@ -616,7 +621,8 @@ TRACE_EVENT(i915_request_queue,
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, hw_id)
-__field(u32, ring)
+__field(u32, class)
+__field(u32, instance)
__field(u32, ctx)
__field(u32, seqno)
__field(u32, flags)
@@ -625,15 +631,17 @@ TRACE_EVENT(i915_request_queue,
TP_fast_assign(
__entry->dev = rq->i915->drm.primary->index;
__entry->hw_id = rq->gem_context->hw_id;
- __entry->ring = rq->engine->id;
+ __entry->class = rq->engine->uabi_class;
+ __entry->instance = rq->engine->instance;
__entry->ctx = rq->fence.context;
__entry->seqno = rq->fence.seqno;
__entry->flags = flags;
),
- TP_printk("dev=%u, hw_id=%u, ring=%u, ctx=%u, seqno=%u, flags=0x%x",
- __entry->dev, __entry->hw_id, __entry->ring, __entry->ctx,
- __entry->seqno, __entry->flags)
+ TP_printk("dev=%u, hw_id=%u, engine=%u:%u, ctx=%u, seqno=%u,
flags=0x%x",
+ __entry->dev, __entry->hw_id, __entry->class,
+ __entry->instance, __entry->ctx, __entry->seqno,
+ __entry->flags)
);
DECLARE_EVENT_CLASS(i915_request,
@@ -643,7 +651,8 @@ DECLARE_EVENT_CLASS(i915_request,
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, hw_id)
-__field(u32, ring)
+__field(u32, class)
+__field(u32, instance)
__field(u32, ctx)
__field(u32, seqno)
__field(u32, global)
@@ -652,15 +661,17 @@ DECLARE_EVENT_CLASS(i915_request,
TP_fast_assign(
__entry->dev = rq->i915->drm.primary->index;
__entry->hw_id = rq->gem_context->hw_id;
- __entry->ring = rq->engine->id;
+ __entry->class = rq->engine->uabi_class;
+ __entry->instance = rq->engine->instance;
__entry->ctx = rq->fence.context;
__entry->seqno = rq->fence.seqno;
__entry->global = rq->global_seqno;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: per context slice/subslice powergating (rev6)
== Series Details == Series: drm/i915: per context slice/subslice powergating (rev6) URL : https://patchwork.freedesktop.org/series/42285/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4233 -> Patchwork_9105 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42285/revisions/6/mbox/ == Known issues == Here are the changes found in Patchwork_9105 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_pipe_crc_basic@read-crc-pipe-b: fi-skl-guc: PASS -> FAIL (fdo#104724, fdo#103191) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bsw-n3050: PASS -> DMESG-WARN (fdo#106207) +5 fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-hsw-4200u: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#106207 https://bugs.freedesktop.org/show_bug.cgi?id=106207 == Participating hosts (44 -> 39) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4233 -> Patchwork_9105 CI_DRM_4233: 0b7643db57abff1223f77fb8cbb8dd8a00ca9938 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9105: 9873e890b9cd81024b6b5fb48aeb2377ed6fba8e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9873e890b9cd drm/i915: add a sysfs entry to let users set sseu configs 957b375e185c drm/i915: Expose RPCS (SSEU) configuration to userspace d099dffee67c drm/i915/perf: lock powergating configuration to default when active 763f9dc06a15 drm/i915/perf: reuse intel_lrc ctx regs macro 16d9bb4e86fc drm/i915/perf: simplify configure all context function eb3c2a521a10 drm/i915: Record the sseu configuration per-context & engine 966969f546ac drm/i915: Program RPCS for Broadwell == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9105/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/2] drm/i915/trace: Describe engines as class:instance pairs
== Series Details == Series: series starting with [1/2] drm/i915/trace: Describe engines as class:instance pairs URL : https://patchwork.freedesktop.org/series/43709/ State : warning == Summary == $ dim checkpatch origin/drm-tip 29e13710369f drm/i915/trace: Describe engines as class:instance pairs 4f5293dac612 drm/i915/trace: Remove engine out of the context sandwich -:31: ERROR:CODE_INDENT: code indent should use tabs where possible #31: FILE: drivers/gpu/drm/i915/i915_trace.h:643: +^I __entry->hw_id, __entry->ctx, __entry->seqno,$ total: 1 errors, 0 warnings, 0 checks, 60 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/trace: Remove engine out of the context sandwich
Quoting Tvrtko Ursulin (2018-05-24 16:48:45) > > On 24/05/2018 16:33, Chris Wilson wrote: > > But what we call ctx here isn't really context, but timeline; how about > > if we switch to the fence=%llx:%d representation we've mostly settled on > > for the debug messages? > > For the ctx and seqno pair? But here we have the additional issue of > hw_id. I think context is better than timeline at this level. > > Or you mean keep explicit hw_id and join ctx and seqno into fence=%llx:%d? Right. I think what we call ctx here is very confusing, as it's just the fence.context (i.e timeline id) and not any of the ids we assign to the context (neither hw_id or uabi_id), so I don't think ctx refers to i915_gem_context/intel_context at all and so would rather stop using 'ctx'. Pardon the rambling, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/trace: Describe engines as class:instance pairs
On 24/05/2018 16:53, Lionel Landwerlin wrote: On 24/05/18 16:04, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Instead of using the engine->id, use uabi_class:instance pairs in trace- points including engine info. This will be more readable, more future proof and more stable for userspace consumption. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: svetlana.kukan...@intel.com Don't you want engine->uabi_id instead of engine->instance ? No, class:instance is the new engine identifier - why do you think we would need legacy engine->uabi_id? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 7/7] drm/i915: add a sysfs entry to let users set sseu configs
On 24/05/18 16:35, Tvrtko Ursulin wrote:
On 24/05/2018 15:54, Lionel Landwerlin wrote:
There are concerns about denial of service around the per context sseu
configuration capability. In a previous commit introducing the
capability we allowed it only for capable users. This changes adds a
new debugfs entry to let any user configure its own context
powergating setup.
v2: Rename sysfs entry (Tvrtko)
Lock interruptible the device in sysfs (Tvrtko)
Fix dropped error code in getting dynamic sseu value (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6
drivers/gpu/drm/i915/i915_gem_context.c | 47 -
drivers/gpu/drm/i915/i915_sysfs.c | 40 +
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 916a301d8c22..3db75c56a9f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1842,6 +1842,8 @@ struct drm_i915_private {
struct ida hw_ida;
#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+
+ bool dynamic_sseu;
} contexts;
u32 fdi_rx_config;
@@ -3275,6 +3277,10 @@ i915_gem_context_lookup(struct
drm_i915_file_private *file_priv, u32 id)
return ctx;
}
+int i915_gem_contexts_set_dynamic_sseu_locked(struct
drm_i915_private *i915,
+ bool allowed);
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915);
+
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 30736efe0fcd..afb7db95aa3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -983,7 +983,8 @@ int i915_gem_context_setparam_ioctl(struct
drm_device *dev, void *data,
break;
}
- if (!capable(CAP_SYS_ADMIN)) {
+ if (!i915->contexts.dynamic_sseu &&
+ !capable(CAP_SYS_ADMIN)) {
ret = -EPERM;
break;
}
@@ -1065,6 +1066,50 @@ int i915_gem_context_reset_stats_ioctl(struct
drm_device *dev,
return ret;
}
+int i915_gem_contexts_set_dynamic_sseu_locked(struct
drm_i915_private *i915,
+ bool allowed)
I think you can drop the _locked suffix since we normally only use it
when there are two flavours of otherwise the same function name. And
you have lockdep_assert_held so that makes it obvious.
Okay
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+ int ret = 0;
+
+ lockdep_assert_held(&i915->drm.struct_mutex);
+
+ if (!engine->emit_rpcs_config)
+ return -ENODEV;
+
+ /*
+ * When we allow each context to configure its powergating
+ * configuration, there is no need to put the configurations
back to
+ * the default, it should already be the case.
+ */
+ if (!allowed) {
Do you want to optimize with "if (!allowed &&
i915->context.dynamic_sseu)"?
Yep!
+ struct intel_sseu default_sseu =
+ intel_sseu_from_device_sseu(&INTEL_INFO(i915)->sseu);
Quick grep around patches tells me this function is always called with
the same parameter. Unless I missed something perhaps it would be
more readable to rename it to something shorter. Like maybe:
default_sseu = intel_device_default_sseu(i915);
Just thinking if that would read nicer than &INTEL_INFO(i915)->sseu
everywhere?
Sure.
Regards,
Tvrtko
+ struct i915_gem_context *ctx;
+
+ list_for_each_entry(ctx, &i915->contexts.list, link) {
+ ret = i915_gem_context_reconfigure_sseu(ctx, engine,
+ default_sseu);
+ if (ret)
+ break;
+ }
+ }
+
+ i915->contexts.dynamic_sseu = allowed;
+
+ return ret;
+}
+
+bool i915_gem_contexts_get_dynamic_sseu(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine = i915->engine[RCS];
+
+ if (!engine->emit_rpcs_config)
+ return false;
+
+ return i915->contexts.dynamic_sseu;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_context.c"
#include "selftests/i915_gem_context.c"
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index e5e6f6bb2b05..c323cab59ec7 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -483,6 +483,44 @@ static ssize_t gt_rp_mhz_show(struct device
*kdev, struct device_attribute *attr
return snprintf(buf, PAGE_SIZE, "%d\n", val);
}
+static ssize_t allow_dynamic_sseu_show(struct device *kdev,
+ struct device_attribute *attr,
+
Re: [Intel-gfx] [PATCH 1/2] drm/i915/trace: Describe engines as class:instance pairs
On 24/05/18 17:07, Tvrtko Ursulin wrote: On 24/05/2018 16:53, Lionel Landwerlin wrote: On 24/05/18 16:04, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Instead of using the engine->id, use uabi_class:instance pairs in trace- points including engine info. This will be more readable, more future proof and more stable for userspace consumption. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: svetlana.kukan...@intel.com Don't you want engine->uabi_id instead of engine->instance ? No, class:instance is the new engine identifier - why do you think we would need legacy engine->uabi_id? Maybe I forgot about your engine listing series... I would expect the tracepoint to match the engines listed through that uapi. - Lionel Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/trace: Describe engines as class:instance pairs
== Series Details == Series: series starting with [1/2] drm/i915/trace: Describe engines as class:instance pairs URL : https://patchwork.freedesktop.org/series/43709/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4233 -> Patchwork_9106 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9106 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9106, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43709/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9106: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9106 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-bsw-n3050: PASS -> DMESG-WARN (fdo#106207) igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-hsw-4200u: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#106207 https://bugs.freedesktop.org/show_bug.cgi?id=106207 == Participating hosts (44 -> 39) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4233 -> Patchwork_9106 CI_DRM_4233: 0b7643db57abff1223f77fb8cbb8dd8a00ca9938 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9106: 4f5293dac6122cdcb6456a96f29f8c69c73e0346 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4f5293dac612 drm/i915/trace: Remove engine out of the context sandwich 29e13710369f drm/i915/trace: Describe engines as class:instance pairs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9106/issues.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 drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI
== Series Details == Series: drm/i915: Allow DBLSCAN user modes with eDP/LVDS/DSI URL : https://patchwork.freedesktop.org/series/43698/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4230_full -> Patchwork_9104_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9104_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9104_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43698/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9104_full: === IGT changes === Possible regressions igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: SKIP -> PASS igt@pm_rc6_residency@rc6-accuracy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9104_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hugepages: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) igt@perf_pmu@busy-double-start-vcs0: shard-snb: PASS -> FAIL (fdo#105106) Possible fixes igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS igt@drv_selftest@live_hangcheck: shard-apl: DMESG-FAIL (fdo#106560) -> PASS igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@2x-plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@pm_rpm@modeset-non-lpsp-stress: shard-hsw: DMESG-WARN (fdo#102614) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105106 https://bugs.freedesktop.org/show_bug.cgi?id=105106 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4230 -> Patchwork_9104 CI_DRM_4230: 097c5e2d7cf300d1f9855a550bfdd5150410ffc4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9104: 82368323f7e2a1fbe3822bd2da4e1860f8ca418d @ git://anongit.freedesktop.org/gfx-ci/linux == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9104/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Include i915_scheduler.h from i915_gem_context.h
== Series Details == Series: series starting with [CI,1/2] drm/i915: Include i915_scheduler.h from i915_gem_context.h URL : https://patchwork.freedesktop.org/series/43710/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4233 -> Patchwork_9107 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9107 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9107, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43710/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9107: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9107 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_flip@basic-flip-vs-wf_vblank: fi-skl-6770hq: PASS -> FAIL (fdo#100368) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: fi-skl-6770hq: PASS -> FAIL (fdo#103481) +1 Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-hsw-4200u: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 == Participating hosts (44 -> 39) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4233 -> Patchwork_9107 CI_DRM_4233: 0b7643db57abff1223f77fb8cbb8dd8a00ca9938 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9107: 9524989a00856810365d0c144ce99af8b511c10e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9524989a0085 drm/i915: Forward declare struct intel_context aa0e999e0736 drm/i915: Include i915_scheduler.h from i915_gem_context.h == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9107/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] drm: Begin an API for in-kernel clients
On 05/24/2018 12:14 PM, Daniel Vetter wrote: On Thu, May 24, 2018 at 11:25:04AM +0200, Thomas Hellstrom wrote: On 05/24/2018 10:32 AM, Daniel Vetter wrote: On Wed, May 23, 2018 at 11:45:00PM +0200, Thomas Hellstrom wrote: Hi, Noralf. A couple of issues below: On 05/23/2018 04:34 PM, Noralf Trønnes wrote: This the beginning of an API for in-kernel clients. First out is a way to get a framebuffer backed by a dumb buffer. Only GEM drivers are supported. The original idea of using an exported dma-buf was dropped because it also creates an anonomous file descriptor which doesn't work when the buffer is created from a kernel thread. The easy way out is to use drm_driver.gem_prime_vmap to get the virtual address, which requires a GEM object. This excludes the vmwgfx driver which is the only non-GEM driver apart from the legacy ones. A solution for vmwgfx will have to be worked out later if it wants to support the client API which it probably will when we have a bootsplash client. Couldn't you add vmap() and vunmap() to the dumb buffer API for in-kernel use rather than using GEM directly? But the main issue is pinning. It looks like the buffers are going to be vmapped() for a long time, which requires pinning, and that doesn't work for some drivers when they bind the framebuffer to a plane, since that might require pinning in another memory region and the vmap would have to be torn down. Besides, buffer pinning should really be avoided if possible: Since we can't page-fault vmaps, and setting up / tearing down vmaps is potentially an expensive operation, could we perhaps have a mapping api that allows the driver to cache vmaps? vmap() // Indicates that we want to map a bo begin_access() // Returns a virtual address which may vary between calls. Allows access. A fast operation. Behind the lines pins / reserves the bo and returns a cached vmap if the bo didn't move since last begin_access(), which is the typical case. end_access() // Disable access. Unpins / unreserves the bo. vunmap_cached() //Indicates that the map is no longer needed. The driver can release the cached map. The idea is that the API client would wrap all bo map accesses with begin_access() end_access(), allowing for the bo to be moved in between. So originally my ideas for the cpu side dma-buf interfaces where all meant to handle this. But then the first implementations bothered with none of this, but instead expected that stuff is pinned, and vmap Just Works. Which yeah doesn't work for vmwgfx and is a pain in a few other cases. I agree it'd be nice to fix all this, but it's also not a problem that this patch set here started. And since it's all optional (and vmwgfx isn't even using the current fb helper code) I think it's reasonable to address this post-merge (if someone gets around to it ever). What we'd need is is a fallback for when vmap doesn't exist (for fbdev that probably means a vmalloc'ed buffer + manual uploads, because fbdev), plus making sure dma-buf implementations actually implement it. My argument here is that, If I understand Noralf, this is intended to be an API exported outside of drm. In that case we shouldn't replicate the assumed behaviour of incomplete dma-buf implementations in a new API. Also the fact that vmwgfx currently isn't using the fbdev helpers isn't a good argument to design an API so that vmwgfx can _never_ use the fbdev helpers. The reason we aren't using them is that the kms implementation was so old that we didn't implement the necessary helper callbacks... Also, I might be misunderstanding the code a bit, but I doubt that vmwgfx is the only hardware with pinning restrictions on the framebuffer? I was under the assumption that most discrete hardware required the framebuffer to be pinned in VRAM? So the important question is, Is this a set of helpers for shared-memory GEM drivers to implement fbdev? Then I wouldn't bother, If it's intended to become an API for clients outside of DRM, then I would have to insist on the API being changed to reflect that. This is definitely not an api for anything outside of drm. Just an attempt to consolidate kernel-internal drm access like fbdev, a simple bootsplash or an emergency console would need to do. Having some limitations in the initial versions, as long as we have some idea how to handle them, seems perfectly fine to me. This isn't meant to be a mandatory replacement for anything - no intentions of exporting this to userspace. OK, yeah my concern is really for generic code and that there in the end would be too much code to change if we wanted to support this, but at least the generic code would be somewhat contained. But it seems like we're at least in agreement on the problematic areas, and as long as they are open for change I guess we can live with that. /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: "Race-to-idle" on switching to the kernel context
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180517]
[cannot apply to drm-intel/for-linux-next v4.17-rc6 v4.17-rc5 v4.17-rc4
v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Prepare-GEM-for-suspend-earlier/20180524-224509
config: x86_64-randconfig-x015-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/selftests/igt_flush_test.c: In function
'igt_flush_test':
>> drivers/gpu/drm/i915/selftests/igt_flush_test.c:61:6: error: too few
>> arguments to function 'i915_gem_switch_to_kernel_context'
i915_gem_switch_to_kernel_context(i915)) {
^
In file included from drivers/gpu/drm/i915/selftests/../intel_lrc.h:28:0,
from drivers/gpu/drm/i915/selftests/../i915_drv.h:63,
from drivers/gpu/drm/i915/selftests/igt_flush_test.c:7:
drivers/gpu/drm/i915/selftests/../i915_gem_context.h:297:5: note: declared
here
int i915_gem_switch_to_kernel_context(struct drm_i915_private *i915,
^
vim +/i915_gem_switch_to_kernel_context +61
drivers/gpu/drm/i915/selftests/igt_flush_test.c
98dc0454 Chris Wilson 2018-05-05 48
98dc0454 Chris Wilson 2018-05-05 49 #define wedge_on_timeout(W, DEV, TIMEOUT)
\
98dc0454 Chris Wilson 2018-05-05 50for (__init_wedge((W), (DEV),
(TIMEOUT), __builtin_return_address(0)); \
98dc0454 Chris Wilson 2018-05-05 51 (W)->i915;
\
98dc0454 Chris Wilson 2018-05-05 52 __fini_wedge((W)))
98dc0454 Chris Wilson 2018-05-05 53
98dc0454 Chris Wilson 2018-05-05 54 int igt_flush_test(struct
drm_i915_private *i915, unsigned int flags)
98dc0454 Chris Wilson 2018-05-05 55 {
98dc0454 Chris Wilson 2018-05-05 56struct wedge_me w;
98dc0454 Chris Wilson 2018-05-05 57
98dc0454 Chris Wilson 2018-05-05 58cond_resched();
98dc0454 Chris Wilson 2018-05-05 59
b9777c6f Chris Wilson 2018-05-09 60if (flags & I915_WAIT_LOCKED &&
b9777c6f Chris Wilson 2018-05-09 @61
i915_gem_switch_to_kernel_context(i915)) {
:: The code at line 61 was first introduced by commit
:: b9777c6f86ac8c21f82211ab982ca48302042ede drm/i915/selftests: Only switch
to kernel context when locked
:: TO: Chris Wilson
:: CC: Chris Wilson
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prepare GEM for suspend earlier
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.17-rc6 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Prepare-GEM-for-suspend-earlier/20180524-231951
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x015-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu//drm/i915/i915_drv.c: In function 'i915_drm_suspend':
drivers/gpu//drm/i915/i915_drv.c:1624:1: warning: label 'out' defined but
not used [-Wunused-label]
out:
^~~
>> drivers/gpu//drm/i915/i915_drv.c:1627:9: warning: 'error' is used
>> uninitialized in this function [-Wuninitialized]
return error;
^
vim +/error +1627 drivers/gpu//drm/i915/i915_drv.c
156987f3e drivers/gpu/drm/i915/i915_drv.c Chris Wilson 2018-05-22 1574
5e365c391 drivers/gpu/drm/i915/i915_drv.c Imre Deak 2014-10-23 1575
static int i915_drm_suspend(struct drm_device *dev)
ba8bbcf6f drivers/char/drm/i915_drv.c Jesse Barnes 2007-11-22 1576 {
fac5e23e3 drivers/gpu/drm/i915/i915_drv.c Chris Wilson 2016-07-04 1577
struct drm_i915_private *dev_priv = to_i915(dev);
52a05c302 drivers/gpu/drm/i915/i915_drv.c David Weinehall 2016-08-22 1578
struct pci_dev *pdev = dev_priv->drm.pdev;
e5747e3ad drivers/gpu/drm/i915/i915_drv.c Jesse Barnes 2014-06-12 1579
pci_power_t opregion_target_state;
d58189385 drivers/gpu/drm/i915/i915_drv.c Daniel Vetter 2015-02-23 1580
int error;
61caf87cb drivers/gpu/drm/i915/i915_drv.c Rafael J. Wysocki 2010-02-18 1581
b8efb17b3 drivers/gpu/drm/i915/i915_drv.c Zhang Rui 2013-02-05 1582
/* ignore lid events during suspend */
b8efb17b3 drivers/gpu/drm/i915/i915_drv.c Zhang Rui 2013-02-05 1583
mutex_lock(&dev_priv->modeset_restore_lock);
b8efb17b3 drivers/gpu/drm/i915/i915_drv.c Zhang Rui 2013-02-05 1584
dev_priv->modeset_restore = MODESET_SUSPENDED;
b8efb17b3 drivers/gpu/drm/i915/i915_drv.c Zhang Rui 2013-02-05 1585
mutex_unlock(&dev_priv->modeset_restore_lock);
b8efb17b3 drivers/gpu/drm/i915/i915_drv.c Zhang Rui 2013-02-05 1586
1f814daca drivers/gpu/drm/i915/i915_drv.c Imre Deak 2015-12-16 1587
disable_rpm_wakeref_asserts(dev_priv);
1f814daca drivers/gpu/drm/i915/i915_drv.c Imre Deak 2015-12-16 1588
c67a470b1 drivers/gpu/drm/i915/i915_drv.c Paulo Zanoni 2013-08-19 1589
/* We do a lot of poking in a lot of registers, make sure they work
c67a470b1 drivers/gpu/drm/i915/i915_drv.c Paulo Zanoni 2013-08-19 1590
* properly. */
da7e29bd5 drivers/gpu/drm/i915/i915_drv.c Imre Deak 2014-02-18 1591
intel_display_set_init_power(dev_priv, true);
cb10799c1 drivers/gpu/drm/i915/i915_drv.c Paulo Zanoni 2013-01-25 1592
5bcf719b7 drivers/gpu/drm/i915/i915_drv.c Dave Airlie 2010-12-07 1593
drm_kms_helper_poll_disable(dev);
5bcf719b7 drivers/gpu/drm/i915/i915_drv.c Dave Airlie 2010-12-07 1594
52a05c302 drivers/gpu/drm/i915/i915_drv.c David Weinehall 2016-08-22 1595
pci_save_state(pdev);
ba8bbcf6f drivers/char/drm/i915_drv.c Jesse Barnes 2007-11-22 1596
6b72d4862 drivers/gpu/drm/i915/i915_drv.c Maarten Lankhorst 2015-06-01 1597
intel_display_suspend(dev);
7d708ee40 drivers/gpu/drm/i915/i915_drv.c Imre Deak 2013-04-17 1598
0e32b39ce drivers/gpu/drm/i915/i915_drv.c Dave Airlie 2014-05-02 1599
intel_dp_mst_suspend(dev);
09b64267c drivers/gpu/drm/i915/i915_drv.c Dave Airlie 2014-07-23 1600
b963291cf drivers/gpu/drm/i915/i915_drv.c Daniel Vetter 2014-09-30 1601
intel_runtime_pm_disable_interrupts(dev_priv);
1d0d343ab drivers/gpu/drm/i915/i915_drv.c Imre Deak 2014-08-18 1602
intel_hpd_cancel_work(dev_priv);
0e32b39ce drivers/gpu/drm/i915/i915_drv.c Dave Airlie 2014-05-02 1603
07f9cd0b3 drivers/gpu/drm/i915/i915_drv.c Imre Deak 2014-08-18 1604
intel_suspend_encoders(dev_priv);
07f9cd0b3 drivers/gpu/drm/i915/i915_drv.c Imre Deak 2014-08-18 1605
712bf3644 drivers/gpu/drm/i915/i915_drv.c Ville Syrjälä 2016-10-31 1606
intel_suspend_hw(dev_priv);
5669fcacc drivers/gpu/drm/i915/i915_drv.c Jesse Barnes 2009-02-17 1607
275a991c0 drivers/gpu/drm/i915/i915_drv.c Tvrtko Ursulin2016-11-16 1608
i915_gem_suspend_gtt_mappings(dev_priv);
828c79087 drivers/gpu/drm/i915/i915_drv.c Ben Widawsky 2013-10-16 1609
af6dc7425 drivers/gpu/drm/i915/i915_drv.c Tvrtko Ursulin2016-12-01 1610
i915_save_state(dev_priv);
9e06dd39
Re: [Intel-gfx] [PATCH 4/4] drm/i915: "Race-to-idle" on switching to the kernel context
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20180517]
[cannot apply to drm-intel/for-linux-next v4.17-rc6 v4.17-rc5 v4.17-rc4
v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Prepare-GEM-for-suspend-earlier/20180524-224509
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/selftests/igt_flush_test.c:61:46: sparse: not enough
>> arguments for function i915_gem_switch_to_kernel_context
drivers/gpu/drm/i915/selftests/igt_flush_test.c: In function
'igt_flush_test':
drivers/gpu/drm/i915/selftests/igt_flush_test.c:61:6: error: too few
arguments to function 'i915_gem_switch_to_kernel_context'
i915_gem_switch_to_kernel_context(i915)) {
^
In file included from drivers/gpu/drm/i915/selftests/../intel_lrc.h:28:0,
from drivers/gpu/drm/i915/selftests/../i915_drv.h:63,
from drivers/gpu/drm/i915/selftests/igt_flush_test.c:7:
drivers/gpu/drm/i915/selftests/../i915_gem_context.h:297:5: note: declared
here
int i915_gem_switch_to_kernel_context(struct drm_i915_private *i915,
^
vim +61 drivers/gpu/drm/i915/selftests/igt_flush_test.c
98dc0454 Chris Wilson 2018-05-05 48
98dc0454 Chris Wilson 2018-05-05 49 #define wedge_on_timeout(W, DEV, TIMEOUT)
\
98dc0454 Chris Wilson 2018-05-05 50for (__init_wedge((W), (DEV),
(TIMEOUT), __builtin_return_address(0)); \
98dc0454 Chris Wilson 2018-05-05 51 (W)->i915;
\
98dc0454 Chris Wilson 2018-05-05 52 __fini_wedge((W)))
98dc0454 Chris Wilson 2018-05-05 53
98dc0454 Chris Wilson 2018-05-05 54 int igt_flush_test(struct
drm_i915_private *i915, unsigned int flags)
98dc0454 Chris Wilson 2018-05-05 55 {
98dc0454 Chris Wilson 2018-05-05 56struct wedge_me w;
98dc0454 Chris Wilson 2018-05-05 57
98dc0454 Chris Wilson 2018-05-05 58cond_resched();
98dc0454 Chris Wilson 2018-05-05 59
b9777c6f Chris Wilson 2018-05-09 60if (flags & I915_WAIT_LOCKED &&
b9777c6f Chris Wilson 2018-05-09 @61
i915_gem_switch_to_kernel_context(i915)) {
:: The code at line 61 was first introduced by commit
:: b9777c6f86ac8c21f82211ab982ca48302042ede drm/i915/selftests: Only switch
to kernel context when locked
:: TO: Chris Wilson
:: CC: Chris Wilson
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prepare GEM for suspend earlier
Hi Chris, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.17-rc6 next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Prepare-GEM-for-suspend-earlier/20180524-231951 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-randconfig-x000-201820 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu//drm/i915/i915_drv.c: In function 'i915_drm_suspend': >> drivers/gpu//drm/i915/i915_drv.c:1624:1: error: label 'out' defined but not >> used [-Werror=unused-label] out: ^~~ Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_read Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_write Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:clear_bit Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls Cyclomatic Complexity 1 arch/x86/include/asm/arch_hweight.h:__arch_hweight32 Cyclomatic Complexity 1 arch/x86/include/asm/arch_hweight.h:__arch_hweight8 Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32 Cyclomatic Complexity 1 include/linux/list.h:list_empty Cyclomatic Complexity 1 arch/x86/include/asm/mem_encrypt.h:sme_active Cyclomatic Complexity 1 include/linux/mem_encrypt.h:sme_get_me_mask Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_read Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_inc Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_read Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_inc Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_dec Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR Cyclomatic Complexity 3 include/linux/err.h:IS_ERR_OR_NULL Cyclomatic Complexity 1 include/linux/lockdep.h:lock_is_held Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_irq Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irq Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies Cyclomatic Complexity 3 include/linux/ktime.h:ktime_compare Cyclomatic Complexity 1 include/linux/ktime.h:ktime_after Cyclomatic Complexity 1 include/linux/workqueue.h:queue_delayed_work Cyclomatic Complexity 67 include/linux/slab.h:kmalloc_large Cyclomatic Complexity 3 include/linux/slab.h:kmalloc Cyclomatic Complexity 1 include/linux/slab.h:kzalloc Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata Cyclomatic Complexity 1 include/linux/device.h:dev_pm_set_driver_flags Cyclomatic Complexity 1 include/linux/pci.h:pci_disable_msi Cyclomatic Complexity 1 include/linux/pci.h:pci_enable_msi Cyclomatic Complexity 1 arch/x86/include/asm/pci.h:pci_domain_nr Cyclomatic Complexity 1 include/linux/pci.h:pci_get_drvdata Cyclomatic Complexity 1 include/linux/pci.h:pci_set_drvdata Cyclomatic Complexity 1 arch/x86/include/asm/dma-mapping.h:get_arch_dma_ops Cyclomatic Complexity 4 include/linux/dma-mapping.h:get_dma_ops Cyclomatic Complexity 3 include/linux/dma-mapping.h:dma_check_mask Cyclomatic Complexity 4 include/linux/dma-mapping.h:dma_supported Cyclomatic Complexity 2 include/linux/dma-mapping.h:dma_set_coherent_mask Cyclomatic Complexity 1 include/linux/vgaarb.h:vga_client_register Cyclomatic Complexity 2 include/linux/fb.h:alloc_apertures Cyclomatic Complexity 1 include/linux/vga_switcheroo.h:vga_switcheroo_unregister_client Cyclomatic Complexity 1 include/linux/vga_switcheroo.h:vga_switcheroo_register_client Cyclomatic Complexity 1 include/linux/vga_switcheroo.h:vga_switcheroo_process_delayed_switch Cyclomatic Complexity 1 include/drm/drm_print.h:drm_debug_printer Cyclomatic Complexity 2 drivers/gpu//drm/i915/i915_utils.h:onoff Cyclomatic Complexity 3 drivers/gpu//drm/i915/intel_device_info.h:sseu_subslice_total Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_ringbuffer.h:intel_engine_flag Cyclomatic Complexity 1 drivers/gpu//drm/i915/intel_uncore.h:intel_wait_for_register Cyclomatic Complexity 1 drivers/gpu//drm/i915/i915_gpu_error.
