[Intel-gfx] ✓ Fi.CI.BAT: success for CI: Revert "net/sch_generic: Shut up noise"
== Series Details == Series: CI: Revert "net/sch_generic: Shut up noise" URL : https://patchwork.freedesktop.org/series/60699/ State : success == Summary == CI Bug Log - changes from CI_DRM_6089 -> Patchwork_13024 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/ Known issues Here are the changes found in Patchwork_13024 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_evict: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([fdo#107709]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/fi-bsw-kefka/igt@i915_selftest@live_evict.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/fi-bsw-kefka/igt@i915_selftest@live_evict.html * igt@i915_selftest@live_hangcheck: - fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/fi-icl-u2/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/fi-icl-u2/igt@i915_selftest@live_hangcheck.html - fi-skl-iommu: [PASS][5] -> [INCOMPLETE][6] ([fdo#108602] / [fdo#108744]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html Possible fixes * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][7] ([fdo#109485]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [DMESG-FAIL][9] ([fdo#110620]) -> [INCOMPLETE][10] ([fdo#103927] / [fdo#110624]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/fi-apl-guc/igt@i915_selftest@live_hangcheck.html * igt@runner@aborted: - fi-apl-guc: [FAIL][11] ([fdo#110622]) -> [FAIL][12] ([fdo#110624]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/fi-apl-guc/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/fi-apl-guc/igt@run...@aborted.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622 [fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624 Participating hosts (52 -> 46) -- Additional (1): fi-pnv-d510 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6089 -> Patchwork_13024 CI_DRM_6089: c7a46913f77868d15ade90846526d7e4cb910637 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4991: 61dd8eec659062eac67823ccd9f2189c3aa36201 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13024: 8fbf6ed5c78a4698353e85b9084616feacd6bea2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8fbf6ed5c78a CI: Revert "net/sch_generic: Shut up noise" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v10 01/12] drm: Add HDR source metadata property
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 16, 2019 12:40 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>maarten.lankho...@linux.intel.com; Sharma, Shashank
>; emil.l.veli...@gmail.com; brian.star...@arm.com;
>dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D
>; jo...@kwiboo.se
>Subject: Re: [v10 01/12] drm: Add HDR source metadata property
>
>On Tue, May 14, 2019 at 11:06:23PM +0530, Uma Shankar wrote:
>> This patch adds a blob property to get HDR metadata information from
>> userspace. This will be send as part of AVI Infoframe to panel.
>>
>> It also implements get() and set() functions for HDR output metadata
>> property.The blob data is received from userspace and saved in
>> connector state, the same is returned as blob in get property call to
>> userspace.
>>
>> v2: Rebase and modified the metadata structure elements as per Ville's
>> POC changes.
>>
>> v3: No Change
>>
>> v4: Addressed Shashank's review comments
>>
>> v5: Rebase.
>>
>> v6: Addressed Brian Starkey's review comments, defined new structure
>> with header for dynamic metadata scalability.
>> Merge get/set property functions for metadata in this patch.
>>
>> v7: Addressed Jonas Karlman review comments and defined separate
>> structure for infoframe to better align with CTA 861.G spec. Added
>> Shashank's RB.
>>
>> v8: Addressed Ville's review comments. Moved sink metadata structure
>> out of uapi headers as suggested by Jonas Karlman.
>>
>> v9: Rebase and addressed Jonas Karlman review comments.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_atomic.c | 2 ++
>> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
>> drivers/gpu/drm/drm_connector.c | 6 ++
>> include/drm/drm_connector.h | 11 +++
>> include/drm/drm_mode_config.h | 7 +++
>> include/linux/hdmi.h | 26 ++
>> include/uapi/drm/drm_mode.h | 23 +++
>> 7 files changed, 88 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index f4924cb..0d27195 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -925,6 +925,8 @@ static void
>> drm_atomic_connector_print_state(struct drm_printer *p,
>>
>> drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector-
>>name);
>> drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
>> "(null)");
>> +drm_printf(p, "\thdr_metadata_changed=%d\n",
>> + state->hdr_metadata_changed);
>>
>> if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>> if (state->writeback_job && state->writeback_job->fb) diff --git
>> a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index 4131e66..4aa82c91 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -676,6 +676,8 @@ static int
>> drm_atomic_connector_set_property(struct drm_connector *connector, {
>> struct drm_device *dev = connector->dev;
>> struct drm_mode_config *config = &dev->mode_config;
>> +bool replaced = false;
>> +int ret;
>>
>> if (property == config->prop_crtc_id) {
>> struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val); @@
>> -726,6 +728,14 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> */
>> if (state->link_status != DRM_LINK_STATUS_GOOD)
>> state->link_status = val;
>> +} else if (property == config->hdr_output_metadata_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +&state->hdr_output_metadata,
>> +val,
>> +-1, sizeof(struct hdr_output_metadata),
>
>Those function arguments are nonsesne for a blob that isn't an array.
Hmm, just to clarify - Since this is a fixed struct being passed. We should make
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->hdr_output_metadata,
val,
sizeof(struct hdr_output_metadata), -1,
&replaced);
Basically have check for expected_size rather expected_elem_size.
Hope this is what you meant.
>> +state->hdr_metadata_changed |= replaced;
>> +return ret;
>> } else if (property == config->aspect_ratio_property) {
>> state->picture_aspect_ratio = val;
>> } else if (property == config->content_type_property) { @@ -814,6
>> +824,9 @@ static int drm_atomic_connector_set_property(struct drm_connector
>*connector,
>> *val = state->colorspace;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->sc
Re: [Intel-gfx] [v10 04/12] drm: Enable HDR infoframe support
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 16, 2019 12:45 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>maarten.lankho...@linux.intel.com; Sharma, Shashank
>; emil.l.veli...@gmail.com; brian.star...@arm.com;
>dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D
>; jo...@kwiboo.se
>Subject: Re: [v10 04/12] drm: Enable HDR infoframe support
>
>On Tue, May 14, 2019 at 11:06:26PM +0530, Uma Shankar wrote:
>> Enable Dynamic Range and Mastering Infoframe for HDR content, which is
>> defined in CEA 861.3 spec.
>>
>> The metadata will be computed based on blending policy in userspace
>> compositors and passed as a connector property blob to driver. The
>> same will be sent as infoframe to panel which support HDR.
>>
>> Added the const version of infoframe for DRM metadata for HDR.
>>
>> v2: Rebase and added Ville's POC changes.
>>
>> v3: No Change
>>
>> v4: Addressed Shashank's review comments and merged the patch making
>> drm infoframe function arguments as constant.
>>
>> v5: Rebase
>>
>> v6: Fixed checkpatch warnings with --strict option. Addressed
>> Shashank's review comments and added his RB.
>>
>> v7: Addressed Brian Starkey's review comments. Merged 2 patches into
>> one.
>>
>> v8: Addressed Jonas Karlman review comments.
>>
>> v9: Addressed Jonas Karlman review comments.
>>
>> Signed-off-by: Uma Shankar
>> Signed-off-by: Ville Syrjälä
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_edid.c | 43 +++
>> drivers/video/hdmi.c | 187
>+
>> include/drm/drm_edid.h | 5 ++
>> include/linux/hdmi.h | 27 +++
>> 4 files changed, 262 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 2e0b5be..73b7905 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -4903,6 +4903,49 @@ static bool is_hdmi2_sink(struct drm_connector
>> *connector) }
>>
>> /**
>> + * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
>> + * HDR metadata from userspace
>> + * @frame: HDMI DRM infoframe
>> + * @hdr_metadata: hdr_source_metadata info from userspace
>> + *
>> + * Return: 0 on success or a negative error code on failure.
>> + */
>> +int
>> +drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
>> +const struct hdr_output_metadata
>*hdr_metadata) {
>> +int err;
>> +
>> +if (!frame || !hdr_metadata)
>> +return -EINVAL;
>> +
>> +err = hdmi_drm_infoframe_init(frame);
>> +if (err < 0)
>> +return err;
>> +
>> +DRM_DEBUG_KMS("type = %x\n", frame->type);
>
>This debug seems pointless.
Ok, will drop this.
>> +
>> +frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
>> +frame->metadata_type =
>> +hdr_metadata->hdmi_metadata_type1.metadata_type;
>> +
>> +memcpy(&frame->display_primaries,
>> + &hdr_metadata->hdmi_metadata_type1.display_primaries, 12);
>
>sizeof() can be used here.
Sure.
>Could also slap on a BUILD_BUG_ON() to make sure both are the same size.
Ok, will addd it.
>
>> +
>> +memcpy(&frame->white_point,
>> + &hdr_metadata->hdmi_metadata_type1.white_point, 4);
>
>ditto.
Sure.
>> +
>> +frame->max_display_mastering_luminance =
>> +hdr_metadata-
>>hdmi_metadata_type1.max_display_mastering_luminance;
>> +frame->min_display_mastering_luminance =
>> +hdr_metadata-
>>hdmi_metadata_type1.min_display_mastering_luminance;
>> +frame->max_fall = hdr_metadata->hdmi_metadata_type1.max_fall;
>> +frame->max_cll = hdr_metadata->hdmi_metadata_type1.max_cll;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
>> +
>> +/**
>> * drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe
>> with
>> * data from a DRM display mode
>> * @frame: HDMI AVI infoframe
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index
>> 799ae49..c5ecd16 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -650,6 +650,147 @@ ssize_t hdmi_vendor_infoframe_pack(struct
>hdmi_vendor_infoframe *frame,
>> return 0;
>> }
>>
>> +/**
>> + * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
>> + * mastering infoframe
>> + * @frame: HDMI DRM infoframe
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame) {
>> +memset(frame, 0, sizeof(*frame));
>> +
>> +frame->type = HDMI_INFOFRAME_TYPE_DRM;
>> +frame->version = 1;
>> +frame->length = HDMI_DRM_INFOFRAME_SIZE;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(hdmi_drm_infoframe_init);
>> +
>> +static int hdmi_drm_infoframe_check_only(const struct
>> +hdmi_drm_i
Re: [Intel-gfx] [v10 12/12] drm/i915: Add state readout for DRM infoframe
>-Original Message- >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >Sent: Thursday, May 16, 2019 1:00 AM >To: Shankar, Uma >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >maarten.lankho...@linux.intel.com; Sharma, Shashank >; emil.l.veli...@gmail.com; brian.star...@arm.com; >dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D >; jo...@kwiboo.se >Subject: Re: [v10 12/12] drm/i915: Add state readout for DRM infoframe > >On Tue, May 14, 2019 at 11:06:34PM +0530, Uma Shankar wrote: >> Added state readout for DRM infoframe and enabled state validation for >> DRM infoframe. >> >> v2: Addressed Ville's review comments and dropped the unused drm >> infoframe read at intel_hdmi_init. >> >> Signed-off-by: Uma Shankar >> --- >> drivers/gpu/drm/i915/intel_ddi.c | 4 >> drivers/gpu/drm/i915/intel_display.c | 1 + >> 2 files changed, 5 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c >> b/drivers/gpu/drm/i915/intel_ddi.c >> index 0af47f3..f574315 100644 >> --- a/drivers/gpu/drm/i915/intel_ddi.c >> +++ b/drivers/gpu/drm/i915/intel_ddi.c >> @@ -3834,6 +3834,10 @@ void intel_ddi_get_config(struct intel_encoder >*encoder, >> intel_read_infoframe(encoder, pipe_config, >> HDMI_INFOFRAME_TYPE_VENDOR, >> &pipe_config->infoframes.hdmi); >> +if ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))) > >Silly extra parens. Actually, I think the check can be removed entirely since >intel_read_infoframe() also checks infoframes.enable. Hmm yeah, will drop this. >> +intel_read_infoframe(encoder, pipe_config, >> + HDMI_INFOFRAME_TYPE_DRM, >> + &pipe_config->infoframes.drm); >> } >> >> static enum intel_output_type >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> b/drivers/gpu/drm/i915/intel_display.c >> index e35ba8d..c89b214 100644 >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -12274,6 +12274,7 @@ static bool fastboot_enabled(struct drm_i915_private >*dev_priv) >> PIPE_CONF_CHECK_INFOFRAME(avi); >> PIPE_CONF_CHECK_INFOFRAME(spd); >> PIPE_CONF_CHECK_INFOFRAME(hdmi); >> +PIPE_CONF_CHECK_INFOFRAME(drm); >> >> #undef PIPE_CONF_CHECK_X >> #undef PIPE_CONF_CHECK_I >> -- >> 1.9.1 > >-- >Ville Syrjälä >Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v10 03/12] drm: Parse HDR metadata info from EDID
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 16, 2019 1:06 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>maarten.lankho...@linux.intel.com; Sharma, Shashank
>; emil.l.veli...@gmail.com; brian.star...@arm.com;
>dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D
>; jo...@kwiboo.se
>Subject: Re: [v10 03/12] drm: Parse HDR metadata info from EDID
>
>On Tue, May 14, 2019 at 11:06:25PM +0530, Uma Shankar wrote:
>> HDR metadata block is introduced in CEA-861.3 spec.
>> Parsing the same to get the panel's HDR metadata.
>>
>> v2: Rebase and added Ville's POC changes to the patch.
>>
>> v3: No Change
>>
>> v4: Addressed Shashank's review comments
>>
>> v5: Addressed Shashank's comment and added his RB.
>>
>> v6: Addressed Jonas Karlman review comments.
>>
>> v7: Adressed Ville's review comments and fixed the issue with length
>> handling.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_edid.c | 49
>> ++
>> 1 file changed, 49 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 852bdd8..2e0b5be 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2852,6 +2852,7 @@ static int drm_cvt_modes(struct drm_connector
>*connector,
>> #define VIDEO_BLOCK 0x02
>> #define VENDOR_BLOCK0x03
>> #define SPEAKER_BLOCK 0x04
>> +#define HDR_STATIC_METADATA_BLOCK 0x6
>> #define USE_EXTENDED_TAG 0x07
>> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
>> #define EXT_VIDEO_DATA_BLOCK_4200x0E
>> @@ -3834,6 +3835,52 @@ static void fixup_detailed_cea_mode_clock(struct
>drm_display_mode *mode)
>> mode->clock = clock;
>> }
>>
>> +static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
>> +if (cea_db_tag(db) != USE_EXTENDED_TAG)
>> +return false;
>> +
>> +if (db[1] != HDR_STATIC_METADATA_BLOCK)
>> +return false;
>> +
>> +return true;
>> +}
>> +
>> +static uint8_t eotf_supported(const u8 *edid_ext) {
>> +return edid_ext[2] &
>> +(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
>> + BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
>> + BIT(HDMI_EOTF_SMPTE_ST2084));
>> +}
>> +
>> +static uint8_t hdr_metadata_type(const u8 *edid_ext) {
>> +return edid_ext[3] &
>> +BIT(HDMI_STATIC_METADATA_TYPE1);
>> +}
>> +
>> +static void
>> +drm_parse_hdr_metadata_block(struct drm_connector *connector, const
>> +u8 *db) {
>> +u16 len;
>> +
>> +len = cea_db_payload_len(db);
>> +if (len >= 3) {
>
>I believe in other cases we've put the length check for the mandatory bytes
>into the
>cea_db_is_foo() function. Would be good to follow the path laid out by
>existing code
>here too.
Ok got it. Will update this.
>> +connector->hdr_sink_metadata.hdmi_type1.eotf =
>> +eotf_supported(db);
>> +connector->hdr_sink_metadata.hdmi_type1.metadata_type =
>> +hdr_metadata_type(db);
>> +}
>> +
>> +if (len >= 4)
>> +connector->hdr_sink_metadata.hdmi_type1.max_cll = db[4];
>> +if (len >= 5)
>> +connector->hdr_sink_metadata.hdmi_type1.max_fall = db[5];
>> +if (len >= 6)
>> +connector->hdr_sink_metadata.hdmi_type1.min_cll = db[6]; }
>> +
>> static void
>> drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8
>> *db) { @@ -4461,6 +4508,8 @@ static void drm_parse_cea_ext(struct
>> drm_connector *connector,
>> drm_parse_y420cmdb_bitmap(connector, db);
>> if (cea_db_is_vcdb(db))
>> drm_parse_vcdb(connector, db);
>> +if (cea_db_is_hdmi_hdr_metadata_block(db))
>> +drm_parse_hdr_metadata_block(connector, db);
>> }
>> }
>>
>> --
>> 1.9.1
>
>--
>Ville Syrjälä
>Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10)
>-Original Message- >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >Sent: Thursday, May 16, 2019 1:02 AM >To: Shankar, Uma >Cc: intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and >handling >in DRM layer (rev10) > >On Wed, May 15, 2019 at 08:59:37AM +, Shankar, Uma wrote: >> >> >> >-Original Message- >> >From: Patchwork [mailto:patchw...@emeril.freedesktop.org] >> >Sent: Wednesday, May 15, 2019 6:54 AM >> >To: Shankar, Uma >> >Cc: intel-gfx@lists.freedesktop.org >> >Subject: ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and >> >handling in DRM layer >> >(rev10) >> > >> >== Series Details == >> > >> >Series: Add HDR Metadata Parsing and handling in DRM layer (rev10) >> >URL : https://patchwork.freedesktop.org/series/25091/ >> >State : failure >> > >> >== Summary == >> > >> >CI Bug Log - changes from CI_DRM_6081_full -> Patchwork_13017_full >> > >> > >> >Summary >> >--- >> > >> > **FAILURE** >> > >> > Serious unknown changes coming with Patchwork_13017_full absolutely >> > need to be verified manually. >> > >> > If you think the reported changes have nothing to do with the >> > changes introduced in Patchwork_13017_full, please notify your bug >> > team to allow them to document this new failure mode, which will reduce >> > false >positives in CI. >> > >> > >> > >> >Possible new issues >> >--- >> > >> > Here are the unknown changes that may have been introduced in >> >Patchwork_13017_full: >> > >> >### IGT changes ### >> > >> > Possible regressions >> > >> > * igt@gem_exec_suspend@basic-s3: >> >- shard-iclb: [PASS][1] -> [SKIP][2] +43 similar issues >> > [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard- >> >iclb6/igt@gem_exec_susp...@basic-s3.html >> > [2]: >> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard- >> >iclb5/igt@gem_exec_susp...@basic-s3.html >> > >> > * igt@kms_prop_blob@invalid-set-prop-any: >> >- shard-iclb: [PASS][3] -> [FAIL][4] >> > [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard- >> >iclb6/igt@kms_prop_b...@invalid-set-prop-any.html >> > [4]: >> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard- >> >iclb5/igt@kms_prop_b...@invalid-set-prop-any.html >> > >> >> Hi Martin, >> These issues are unrelated to the changes made in this series. Can you >> please have a look and confirm. > >The kms_prop fails at least are real. Probably due to the bogus function >arguements >to the replace_blob() thing I pointed out. The CI IGT have a clean PASS now. Will anyways update the function arguments and make it consistent. Regards, Uma Shankar >-- >Ville Syrjälä >Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Reg: igt@kms_pipe_crc_basic@* CRC mismatch test failures
== Series Details == Series: Reg: igt@kms_pipe_crc_basic@* CRC mismatch test failures URL : https://patchwork.freedesktop.org/series/60697/ State : success == Summary == CI Bug Log - changes from CI_DRM_6089_full -> Patchwork_13023_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13023_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_swapping@non-threaded: - shard-hsw: [PASS][1] -> [FAIL][2] ([fdo#108686]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-hsw7/igt@gem_tiled_swapp...@non-threaded.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-hsw4/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@debugfs-forcewake-user: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-skl2/igt@i915_pm_...@debugfs-forcewake-user.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-skl4/igt@i915_pm_...@debugfs-forcewake-user.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-apl7/igt@i915_susp...@debugfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-apl5/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#105767]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#100368]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-skl4/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-skl1/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [fdo#110403]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#108341]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb4/igt@kms_psr@no_drrs.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-iclb4/igt@kms_psr@psr2_sprite_plane_move.html * igt@perf@oa-exponents: - shard-glk: [PASS][19] -> [FAIL][20] ([fdo#105483]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-glk2/igt@p...@oa-exponents.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-glk8/igt@p...@oa-exponents.html * igt@perf_pmu@rc6: - shard-kbl: [PASS][21] -> [SKIP][22] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl6/igt@perf_...@rc6.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-kbl2/igt@perf_...@rc6.html Possible fixes * igt@i915_pm_rpm@gem-execbuf: - shard-apl: [INCOMPLETE][23] ([fdo#103927]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-apl6/igt@i915_pm_...@gem-execbuf.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13023/shard-apl3/igt@i915_pm_...@gem-execbuf.html * igt@i915_pm_rpm@sysfs-read: - shard-skl: [INCOMPLETE][25] ([fdo#107807]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-skl7/igt@i915_pm_...@sysfs-read.html [26]: https://i
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Wed, 15 May 2019 10:24:49 +0200 Daniel Vetter wrote: > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote: > > On Tue, 14 May 2019 16:34:01 +0200 > > Daniel Vetter wrote: > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen > > > wrote: > > > > > > > > On Tue, 14 May 2019 13:02:09 +0200 > > > > Daniel Vetter wrote: > > > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon > > > > > wrote: > > > > > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > > > ... > > > > > > > > > Hi Daniel, > > > > > > > > > > > > > > just to clarify the first case, specific to one very particular > > > > > > > property: > > > > > > > > > > > > > > With HDCP, there is a property that may change dynamically at > > > > > > > runtime > > > > > > > (the undesired/desired/enabled tristate). Userspace must be > > > > > > > notified > > > > > > > when it changes, I do not want userspace have to poll that > > > > > > > property > > > > > > > with a timer. > > > > > > > > > > > > > > When that property alone changes, and userspace is prepared to > > > > > > > handle > > > > > > > that property changing alone, it must not trigger a reprobe of the > > > > > > > connector. There is no reason to reprobe at that point AFAIU. > > > > > > > > > > > > > > How do you ensure that userspace can avoid triggering a reprobe > > > > > > > with the > > > > > > > epoch approach or with any alternate uevent design? > > > > > > > > > > > > > > We need an event to userspace that indicates that re-reading the > > > > > > > properties is enough and reprobe of the connector is not > > > > > > > necessary. > > > > > > > This is complementary to indicating to userspace that only some > > > > > > > connectors need to be reprobed instead of everything. > > > > > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip > > > > > > the > > > > > > reprobing. Would that work? > > > > > > > > Hi, > > > > > > > > yes, that would work, if it was acceptable to DRM upstream. The replies > > > > to Paul seemed to be going south so fast that I thought we wouldn't get > > > > any new uevent fields in favour of "epoch counters". > > > > > > > > > Yes that's the idea, depending upon which property you get you know > > > > > it's a sink change (needs full reprobe) or something else like hdcp > > > > > state machinery update. > > > > > > > > Right. > > > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we should > > > > > indeed decouple that from the per-connector event for sink changes. > > > > > That along is a good win already, since you know for which connector > > > > > you need to call drmGetConnector (which forces the reprobe). It would > > > > > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but > > > > > historically speaking every time we tried to rely on this we ended up > > > > > regretting things. > > > > > > > > What changed? This sounds very much what Paul suggested. Looking at it > > > > from userspace side: > > > > > > This sounds solid, some refinements below: > > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy > > > > > > > > - If yy is "Content Protection", no need to drmModeGetConnector(), just > > > > re-get the connector properties. > > > > > > > > - Kernel probably shouldn't bother sending this for properties where > > > > re-probe could be necessary, and send the below instead. > > > > > > > > > I think we should assert that the kernel can get the new property > > > values using drmModeGetConnectorCurrent for this case, i.e. the kernel > > > does not expect a full reprobe. I.e. upgrade your idea from "should" > > > to "must" > > > > Hi Daniel, > > > > ok, that's good. > > > > > Furthermore different property can indicate different kind of updates, > > > e.g. hdcp vs general sink change vs. whatever else might come in the > > > future. > > > > What do you mean by different kinds of updates? > > Atm we're discussing two: > > - "Content Protection" > - "sink changed, but you don't need to reprobe" this would be quite a bit > a catch all from the output detection. Paul thinks differently, but I'm > not sold on splitting this up more, at least not right now. This would > include connector status (and related things returned by drmGetConnector > which currently aren't a property), EDID, the mst path id, that kind of > stuff. > > Ime once we have 2, there's more bound to come :-) Hi Daniel, I don't understand what the "sink changed" thing could be, but sure, there can be more. > > Btw. I started thinking, maybe we should completely leave out the "If > > yy is "Content Protection"" and require the kernel to guarantee, that > > if PROPERTY is set, then drmModeGetConnector() (probing) must not be > > necessary based on this event alone. > > > > Writing it down again: > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy > > > > - yy denotes which connector xx pro
Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs
On Wed, 15 May 2019, Harish Chegondi wrote:
> display_pipe_crc_irq_handler() skips the first CRC for all GPUs and the
> second CRC for GEN8+ GPUs. The second CRC is invalid even for BYT which
> is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
>
> Cc: Jani Nikula
> Cc: Tomi Sarvela
> Cc: Petri Latvala
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Signed-off-by: Harish Chegondi
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
s/References:/Bugzilla:/
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 233211fde0ea..3809e9f7fae2 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1775,11 +1775,11 @@ static void display_pipe_crc_irq_handler(struct
> drm_i915_private *dev_priv,
>* bonkers. So let's just wait for the next vblank and read
>* out the buggy result.
>*
> - * On GEN8+ sometimes the second CRC is bonkers as well, so
> + * On GEN7+ sometimes the second CRC is bonkers as well, so
>* don't trust that one either.
>*/
> if (pipe_crc->skipped <= 0 ||
> - (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
> + (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped == 1)) {
> pipe_crc->skipped++;
> spin_unlock(&pipe_crc->lock);
> return;
--
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 i-g-t 05/16] i915/gem_ctx_create: Basic checks for constructor properties
On 15/05/2019 20:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-14 11:15:12)
On 08/05/2019 11:09, Chris Wilson wrote:
Check that the extended create interface accepts setparam.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_create.c | 225 ++--
1 file changed, 213 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_ctx_create.c b/tests/i915/gem_ctx_create.c
index a664070db..9b4fddbe7 100644
--- a/tests/i915/gem_ctx_create.c
+++ b/tests/i915/gem_ctx_create.c
@@ -33,6 +33,7 @@
#include
#include "igt_rand.h"
+#include "sw_sync.h"
#define LOCAL_I915_EXEC_BSD_SHIFT (13)
#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
@@ -45,12 +46,33 @@ static unsigned all_nengine;
static unsigned ppgtt_engines[16];
static unsigned ppgtt_nengine;
-static int __gem_context_create_local(int fd, struct drm_i915_gem_context_create *arg)
+static int create_ioctl(int fd, struct drm_i915_gem_context_create *arg)
{
- int ret = 0;
- if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, arg))
- ret = -errno;
- return ret;
+ int err;
+
+ err = 0;
+ if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, arg)) {
+ err = -errno;
+ igt_assert(err);
+ }
+
+ errno = 0;
+ return err;
+}
+
+static int create_ext_ioctl(int i915,
+ struct drm_i915_gem_context_create_ext *arg)
+{
+ int err;
+
+ err = 0;
+ if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
+ err = -errno;
+ igt_assume(err);
+ }
+
+ errno = 0;
+ return err;
}
static double elapsed(const struct timespec *start,
@@ -308,6 +330,187 @@ static void maximum(int fd, int ncpus, unsigned mode)
free(contexts);
}
+static void basic_ext_param(int i915)
+{
+ struct drm_i915_gem_context_create_ext_setparam ext = {
+ { .name = I915_CONTEXT_CREATE_EXT_SETPARAM },
+ };
+ struct drm_i915_gem_context_create_ext create = {
+ .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS
+ };
+ struct drm_i915_gem_context_param get;
+
+ igt_require(create_ext_ioctl(i915, &create) == 0);
+ gem_context_destroy(i915, create.ctx_id);
+
+ create.extensions = -1ull;
+ igt_assert_eq(create_ext_ioctl(i915, &create), -EFAULT);
+
+ create.extensions = to_user_pointer(&ext);
+ igt_assert_eq(create_ext_ioctl(i915, &create), -EINVAL);
+
+ ext.param.param = I915_CONTEXT_PARAM_PRIORITY;
+ if (create_ext_ioctl(i915, &create) != -ENODEV) {
+ gem_context_destroy(i915, create.ctx_id);
+
+ ext.base.next_extension = -1ull;
+ igt_assert_eq(create_ext_ioctl(i915, &create), -EFAULT);
+ ext.base.next_extension = to_user_pointer(&ext);
+ igt_assert_eq(create_ext_ioctl(i915, &create), -E2BIG);
+ ext.base.next_extension = 0;
+
+ ext.param.value = 32;
+ igt_assert_eq(create_ext_ioctl(i915, &create), 0);
+
+ memset(&get, 0, sizeof(get));
+ get.ctx_id = create.ctx_id;
+ get.param = I915_CONTEXT_PARAM_PRIORITY;
+ gem_context_get_param(i915, &get);
+ igt_assert_eq(get.value, ext.param.value);
+
+ gem_context_destroy(i915, create.ctx_id);
+ }
+}
+
+static void check_single_timeline(int i915, uint32_t ctx, int num_engines)
+{
+#define RCS_TIMESTAMP (0x2000 + 0x358)
+ const int gen = intel_gen(intel_get_drm_devid(i915));
+ const int has_64bit_reloc = gen >= 8;
+ struct drm_i915_gem_exec_object2 results = { .handle = gem_create(i915,
4096) };
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ int timeline = sw_sync_timeline_create();
+ uint32_t last, *map;
+
+ {
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&results),
+ .buffer_count = 1,
+ .rsvd1 = ctx,
+ };
+ gem_write(i915, results.handle, 0, &bbe, sizeof(bbe));
+ gem_execbuf(i915, &execbuf);
+ results.flags = EXEC_OBJECT_PINNED;
+ }
+
+ for (int i = 0; i < num_engines; i++) {
+ struct drm_i915_gem_exec_object2 obj[2] = {
+ results, /* write hazard lies! */
+ { .handle = gem_create(i915, 4096) },
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(obj),
+ .buffer_count = 2,
+ .rsvd1 = ctx,
+ .rsvd2 = sw_sync_timeline_create_fence(timeline,
num_engines - i),
+ .flags = i | I915_EXEC_FENCE_IN,
+ };
+ uint64_t offset = results.offset + 4 * i;
+ uint32_t *cs;
+ int j = 0;
+
+ cs = gem_mmap__cpu(i915, obj[1].h
[Intel-gfx] ✓ Fi.CI.IGT: success for CI: Revert "net/sch_generic: Shut up noise"
== Series Details == Series: CI: Revert "net/sch_generic: Shut up noise" URL : https://patchwork.freedesktop.org/series/60699/ State : success == Summary == CI Bug Log - changes from CI_DRM_6089_full -> Patchwork_13024_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13024_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs1-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl3/igt@gem_ctx_isolat...@vcs1-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-kbl7/igt@gem_ctx_isolat...@vcs1-s3.html * igt@gem_tiled_swapping@non-threaded: - shard-hsw: [PASS][3] -> [FAIL][4] ([fdo#108686]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-hsw7/igt@gem_tiled_swapp...@non-threaded.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-hsw5/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-apl7/igt@gem_workarou...@suspend-resume-context.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-apl7/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rpm@dpms-lpsp: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-skl10/igt@i915_pm_...@dpms-lpsp.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-skl10/igt@i915_pm_...@dpms-lpsp.html * igt@kms_flip_tiling@flip-x-tiled: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#108303]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb7/igt@kms_flip_til...@flip-x-tiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-iclb4/igt@kms_flip_til...@flip-x-tiled.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_setmode@basic: - shard-kbl: [PASS][15] -> [FAIL][16] ([fdo#99912]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl2/igt@kms_setm...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-kbl2/igt@kms_setm...@basic.html * igt@perf_pmu@rc6: - shard-kbl: [PASS][17] -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl6/igt@perf_...@rc6.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-kbl7/igt@perf_...@rc6.html Possible fixes * igt@gem_ctx_isolation@bcs0-s3: - shard-kbl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl7/igt@gem_ctx_isolat...@bcs0-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-kbl3/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_tiled_swapping@non-threaded: - shard-iclb: [FAIL][21] ([fdo#108686]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb5/igt@gem_tiled_swapp...@non-threaded.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-iclb8/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@basic-rte: - shard-skl: [INCOMPLETE][23] ([fdo#107807]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-skl3/igt@i915_pm_...@basic-rte.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-skl10/igt@i915_pm_...@basic-rte.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [DMESG-WARN][25] ([fdo#108566]) -> [PASS][26] +4 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-apl8/igt@i915_susp...@fence-restore
Re: [Intel-gfx] [PATCH i-g-t 08/16] i915: Exercise creating context with shared GTT
On 15/05/2019 20:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-15 07:37:18)
On 08/05/2019 11:09, Chris Wilson wrote:
v2: Test each shared context is its own timeline and allows request
reordering between shared contexts.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Michal Wajdeczko
---
lib/i915/gem_context.c| 68 +++
lib/i915/gem_context.h| 13 +
tests/Makefile.sources| 1 +
tests/i915/gem_ctx_shared.c | 856 ++
tests/i915/gem_exec_whisper.c | 32 +-
tests/meson.build | 1 +
6 files changed, 962 insertions(+), 9 deletions(-)
create mode 100644 tests/i915/gem_ctx_shared.c
diff --git a/lib/i915/gem_context.c b/lib/i915/gem_context.c
index f94d89cb4..8fb8984d1 100644
--- a/lib/i915/gem_context.c
+++ b/lib/i915/gem_context.c
@@ -272,6 +272,74 @@ void gem_context_set_priority(int fd, uint32_t ctx_id, int
prio)
igt_assert_eq(__gem_context_set_priority(fd, ctx_id, prio), 0);
}
+int
+__gem_context_clone(int i915,
+ uint32_t src, unsigned int share,
+ unsigned int flags,
+ uint32_t *out)
+{
+ struct drm_i915_gem_context_create_ext_clone clone = {
+ { .name = I915_CONTEXT_CREATE_EXT_CLONE },
+ .clone_id = src,
+ .flags = share,
+ };
+ struct drm_i915_gem_context_create_ext arg = {
+ .flags = flags | I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+ .extensions = to_user_pointer(&clone),
+ };
+ int err = 0;
+
+ if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, &arg))
+ err = -errno;
+
+ *out = arg.ctx_id;
+
+ errno = 0;
+ return err;
+}
+
+static bool __gem_context_has(int i915, uint32_t share, unsigned int flags)
+{
+ uint32_t ctx;
+
+ __gem_context_clone(i915, 0, share, flags, &ctx);
+ if (ctx)
+ gem_context_destroy(i915, ctx);
+
+ errno = 0;
+ return ctx;
+}
+
+bool gem_contexts_has_shared_gtt(int i915)
+{
+ return __gem_context_has(i915, I915_CONTEXT_CLONE_VM, 0);
+}
+
+bool gem_has_queues(int i915)
+{
+ return __gem_context_has(i915,
+ I915_CONTEXT_CLONE_VM,
+ I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE);
+}
+
+uint32_t gem_context_clone(int i915,
+uint32_t src, unsigned int share,
+unsigned int flags)
+{
+ uint32_t ctx;
+
+ igt_assert_eq(__gem_context_clone(i915, src, share, flags, &ctx), 0);
+
+ return ctx;
+}
+
+uint32_t gem_queue_create(int i915)
+{
+ return gem_context_clone(i915, 0,
+ I915_CONTEXT_CLONE_VM,
+ I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE);
+}
+
bool gem_context_has_engine(int fd, uint32_t ctx, uint64_t engine)
{
struct drm_i915_gem_exec_object2 exec = {};
diff --git a/lib/i915/gem_context.h b/lib/i915/gem_context.h
index a052714d4..8043c3401 100644
--- a/lib/i915/gem_context.h
+++ b/lib/i915/gem_context.h
@@ -29,6 +29,19 @@ int __gem_context_create(int fd, uint32_t *ctx_id);
void gem_context_destroy(int fd, uint32_t ctx_id);
int __gem_context_destroy(int fd, uint32_t ctx_id);
+int __gem_context_clone(int i915,
+ uint32_t src, unsigned int share,
+ unsigned int flags,
+ uint32_t *out);
+uint32_t gem_context_clone(int i915,
+uint32_t src, unsigned int share,
+unsigned int flags);
+
+uint32_t gem_queue_create(int i915);
+
+bool gem_contexts_has_shared_gtt(int i915);
+bool gem_has_queues(int i915);
+
bool gem_has_contexts(int fd);
void gem_require_contexts(int fd);
void gem_context_require_bannable(int fd);
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index e1b7feeb2..3552e895b 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -22,6 +22,7 @@ TESTS_progs = \
drm_mm \
drm_read \
i915/gem_ctx_clone \
+ i915/gem_ctx_shared \
i915/gem_vm_create \
kms_3d \
kms_addfb_basic \
diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
new file mode 100644
index 0..0076f5e9d
--- /dev/null
+++ b/tests/i915/gem_ctx_shared.c
@@ -0,0 +1,856 @@
+/*
+ * Copyright © 2017 Intel Corporation
2019
Nah, that would imply I put any thought into touching it since.
+static void exhaust_shared_gtt(int i915, unsigned int flags)
+#define EXHAUST_LRC 0x1
+{
+ i915 = gem_reopen_driver(i915);
+
+ igt_fork(pid, 1) {
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = gem_create(i915, 4096)
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .b
Re: [Intel-gfx] [PATCH i-g-t 10/16] i915/gem_exec_whisper: Fork all-engine tests one-per-engine
On 15/05/2019 20:35, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-14 13:57:26)
On 08/05/2019 11:09, Chris Wilson wrote:
Add a new mode for some more stress, submit the all-engines tests
simultaneously, a stream per engine.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
index d3e0b0ba2..d5afc8119 100644
--- a/tests/i915/gem_exec_whisper.c
+++ b/tests/i915/gem_exec_whisper.c
@@ -88,6 +88,7 @@ static void verify_reloc(int fd, uint32_t handle,
#define SYNC 0x40
#define PRIORITY 0x80
#define QUEUES 0x100
+#define ALL 0x200
struct hang {
struct drm_i915_gem_exec_object2 obj;
@@ -199,6 +200,7 @@ static void whisper(int fd, unsigned engine, unsigned flags)
uint64_t old_offset;
int i, n, loc;
int debugfs;
+ int nchild;
if (flags & PRIORITY) {
igt_require(gem_scheduler_enabled(fd));
@@ -215,6 +217,7 @@ static void whisper(int fd, unsigned engine, unsigned flags)
engines[nengine++] = engine;
}
} else {
+ igt_assert(!(flags & ALL));
igt_require(gem_has_ring(fd, engine));
igt_require(gem_can_store_dword(fd, engine));
engines[nengine++] = engine;
@@ -233,11 +236,22 @@ static void whisper(int fd, unsigned engine, unsigned
flags)
if (flags & HANG)
init_hang(&hang);
+ nchild = 1;
+ if (flags & FORKED)
+ nchild *= sysconf(_SC_NPROCESSORS_ONLN);
+ if (flags & ALL)
+ nchild *= nengine;
+
intel_detect_and_clear_missed_interrupts(fd);
gpu_power_read(&power, &sample[0]);
- igt_fork(child, flags & FORKED ? sysconf(_SC_NPROCESSORS_ONLN) : 1) {
+ igt_fork(child, nchild) {
unsigned int pass;
+ if (flags & ALL) {
+ engines[0] = engines[child % nengine];
Relying on PIDs being sequential feels fragile but suggesting pipes or
shared memory would be overkill. How about another loop:
Where are you getting pid_t from? child is an integer [0, nchild).
Add a core helper to get it?
I am coming from an angle that I remember some time in the past there
was a security thing which randomized pid allocation. TBH I am not sure
if that still exists, but if it does then it would not be good for this
test. May be moot point to think such security hardening measures would
be active on a machine running IGT tests.. hm.. not sure. But it is
still a quite hidden assumption.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 13/16] i915: Add gem_exec_balancer
On 15/05/2019 20:50, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-15 11:49:45)
On 08/05/2019 11:09, Chris Wilson wrote:
Exercise the in-kernel load balancer checking that we can distribute
batches across the set of ctx->engines to avoid load.
Signed-off-by: Chris Wilson
---
tests/Makefile.am |1 +
tests/Makefile.sources |1 +
tests/i915/gem_exec_balancer.c | 1050
tests/meson.build |7 +
4 files changed, 1059 insertions(+)
create mode 100644 tests/i915/gem_exec_balancer.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5097debf6..c6af0aeaf 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -96,6 +96,7 @@ gem_close_race_LDADD = $(LDADD) -lpthread
gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_ctx_thrash_LDADD = $(LDADD) -lpthread
gem_ctx_sseu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
+i915_gem_exec_balancer_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
gem_exec_capture_LDADD = $(LDADD) -lz
gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_exec_parallel_LDADD = $(LDADD) -lpthread
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index e7ee27e81..323b625aa 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -24,6 +24,7 @@ TESTS_progs = \
i915/gem_ctx_clone \
i915/gem_ctx_engines \
i915/gem_ctx_shared \
+ i915/gem_exec_balancer \
i915/gem_vm_create \
kms_3d \
kms_addfb_basic \
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
new file mode 100644
index 0..25195d478
--- /dev/null
+++ b/tests/i915/gem_exec_balancer.c
@@ -0,0 +1,1050 @@
+/*
+ * Copyright © 2018 Intel Corporation
2019 I guess, even though work was started in 2018?
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include
+
+#include "igt.h"
+#include "igt_perf.h"
+#include "i915/gem_ring.h"
+#include "sw_sync.h"
+
+IGT_TEST_DESCRIPTION("Exercise in-kernel load-balancing");
+
+#define INSTANCE_COUNT (1 << I915_PMU_SAMPLE_INSTANCE_BITS)
Hmm.. this is a strange surrogate but I guess it works.
+
+static bool has_class_instance(int i915, uint16_t class, uint16_t instance)
+{
+ int fd;
+
+ fd = perf_i915_open(I915_PMU_ENGINE_BUSY(class, instance));
More work for Andi to replace with real engine discovery. :)
+ if (fd != -1) {
+ close(fd);
+ return true;
+ }
+
+ return false;
+}
+
+static struct i915_engine_class_instance *
+list_engines(int i915, uint32_t class_mask, unsigned int *out)
+{
+ unsigned int count = 0, size = 64;
+ struct i915_engine_class_instance *engines;
+
+ engines = malloc(size * sizeof(*engines));
+ if (!engines) {
+ *out = 0;
+ return NULL;
+ }
+
+ for (enum drm_i915_gem_engine_class class = I915_ENGINE_CLASS_RENDER;
+ class_mask;
+ class++, class_mask >>= 1) {
+ if (!(class_mask & 1))
+ continue;
+
+ for (unsigned int instance = 0;
+ instance < INSTANCE_COUNT;
+ instance++) {
+ if (!has_class_instance(i915, class, instance))
+ continue;
+
+ if (count == size) {
+ struct i915_engine_class_instance *e;
+
+ size *= 2;
+ e = realloc(engines, size*sizeof(*engines));
+ if (!e) {
I'd just assert. On malloc as well.
+ *out = count;
+ return engines;
+ }
+
+ engines = e;
+ }
+
+ engines[count++] = (struct i915_engine_class_instance){
+
Re: [Intel-gfx] [PATCH i-g-t 14/16] i915/gem_exec_balancer: Exercise bonded pairs
On 15/05/2019 21:32, Chris Wilson wrote: Quoting Chris Wilson (2019-05-15 20:57:18) Quoting Tvrtko Ursulin (2019-05-15 11:58:20) On 08/05/2019 11:09, Chris Wilson wrote: + igt_assert_f(load > 0.90, + "engine %d (class:instance %d:%d) was found to be only %.1f%% busy\n", + n, siblings[n].engine_class, siblings[n].engine_instance, + load*100); Master also needs to be checked I think. You have the infrastructure to open two pmus in the previous patch so should be easy. Haven't we checked precisely that in earlier tests? What would perhaps Where? I see one subtest for bonding. be fairer here would be to verify the other engine was idle, otherwise we could say we fluked it. Furthermore, we should repeat a few times with say (0, 1), (0, 1), (1, 0), (1, 0) to further rule out flukes, and then to finish with a random smoketest of some description. Hm maybe gpu idling before each pass is needed in this test. Then I'd be happy if you just measured busyness on a bonded pair. And yeah more permutation would be good for fluke prevention. Perhaps even a test is closer to the typical workload would involve semaphore communication across the bond. But I don't know a way in which I can determine which engine I am on in order to record that from the GPU itself. To remind myself, the importance here is on uABI stressing, it's is much easier to prove the relationship in the kernel and that is where we do. I didn't think it would be hard to read busyness from the master as well but if you insist okay. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Refactor oa object to better manage resources
Hi Umesh,
This v3 looks good to me. I've left some nits below, but with or with
them applied this is :
Reviewed-by: Lionel Landwerlin
On 15/05/2019 19:07, Umesh Nerlige Ramappa wrote:
The oa object manages the oa buffer and must be allocated when the user
intends to read performance counter snapshots. This can be achieved by
making the oa object part of the stream object which is allocated when a
stream is opened by the user.
Attributes in the oa object that are gen-specific are moved to the perf
object so that they can be initialized on driver load.
The split provides a better separation of the objects used in perf
implementation of i915 driver so that resources are allocated and
initialized only when needed.
v2: Fix checkpatch warnings
v3: Addressed Lionel's review comment
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 219 +-
drivers/gpu/drm/i915/i915_oa_bdw.c| 30 +-
drivers/gpu/drm/i915/i915_oa_bxt.c| 30 +-
drivers/gpu/drm/i915/i915_oa_cflgt2.c | 30 +-
drivers/gpu/drm/i915/i915_oa_cflgt3.c | 30 +-
drivers/gpu/drm/i915/i915_oa_chv.c| 30 +-
drivers/gpu/drm/i915/i915_oa_cnl.c| 30 +-
drivers/gpu/drm/i915/i915_oa_glk.c| 30 +-
drivers/gpu/drm/i915/i915_oa_hsw.c| 30 +-
drivers/gpu/drm/i915/i915_oa_icl.c| 30 +-
drivers/gpu/drm/i915/i915_oa_kblgt2.c | 30 +-
drivers/gpu/drm/i915/i915_oa_kblgt3.c | 30 +-
drivers/gpu/drm/i915/i915_oa_sklgt2.c | 30 +-
drivers/gpu/drm/i915/i915_oa_sklgt3.c | 30 +-
drivers/gpu/drm/i915/i915_oa_sklgt4.c | 30 +-
drivers/gpu/drm/i915/i915_perf.c | 583 ++
18 files changed, 629 insertions(+), 599 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 7f448f3bea0b..fa78df39521a 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -32,7 +32,7 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
* cases which disable slices for functional, apart for performance
* reasons. So in this case we select a known stable subset.
*/
- if (!i915->perf.oa.exclusive_stream) {
+ if (!i915->perf.exclusive_stream) {
ctx_sseu = *req_sseu;
} else {
ctx_sseu = intel_sseu_from_device_info(sseu);
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 7ae42f2ebfe8..878e71a927de 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -81,8 +81,8 @@ static void sr_oa_regs(struct intel_vgpu_workload *workload,
u32 *reg_state, bool save)
{
struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
- u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
- u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+ u32 ctx_oactxctrl = dev_priv->perf.ctx_oactxctrl_offset;
+ u32 ctx_flexeu0 = dev_priv->perf.ctx_flexeu0_offset;
int i = 0;
u32 flex_mmio[] = {
i915_mmio_reg_offset(EU_PERF_CNTL0),
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9a634ba57ff9..23778f6299de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1400,6 +1400,86 @@ struct i915_perf_stream {
* @oa_config: The OA configuration used by the stream.
*/
struct i915_oa_config *oa_config;
+
+ /**
+* The OA context specific information.
+*/
+ struct intel_context *pinned_ctx;
+ u32 specific_ctx_id;
+ u32 specific_ctx_id_mask;
+
+ struct hrtimer poll_check_timer;
+ wait_queue_head_t poll_wq;
+ bool pollin;
+
+ bool periodic;
+ int period_exponent;
+
+ /**
+* State of the OA buffer.
+*/
+ struct {
+ struct i915_vma *vma;
+ u8 *vaddr;
+ u32 last_ctx_id;
+ int format;
+ int format_size;
+ int size_exponent;
+
+ /**
+* Locks reads and writes to all head/tail state
+*
+* Consider: the head and tail pointer state needs to be read
+* consistently from a hrtimer callback (atomic context) and
+* read() fop (user context) with tail pointer updates happening
+* in atomic context and head updates in user context and the
+* (unlikely) possibility of read() errors needing to reset all
+* head/tail state.
+*
+* Note: Contention/performance aren't currently a significant
+* concern here considering the relatively low frequency of
+* hrtimer callbacks (5ms period) and that reads typically only
+
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam
On Tue, 14 May 2019, Rodrigo Vivi wrote: > One possibility that just came to my mind now is, what if we make > this only for platforms that are still protected by is_alpha_support=1 > (soon becoming require_force_probe=1) Please don't conflate alpha_support or force_probe with *anything* else. > But this is just one side of the coin... when product is out there > and we want the user to debug the issue to see if it is a RC6 bug > we have no way to verify that. :/ The problem is, if it works with rc6 disabled, it doesn't prove it's an rc6 bug either. 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 2/2] drm/i915: Disable active links before rebooting
On Wed, 15 May 2019, Chris Wilson wrote:
> Certain monitors, e.g. Dell, do not like it when we reboot with an
> active link, leaving them in a confused state where they refuse to
> renegotiate the link after the reboot. If we hook into the reboot
> notifier, we can switch off any active link before rebooting, leaving
> everything in a consistent, hopefully happy, state.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_pci.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 401eb6c71ae1..7b2dc8d66f35 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -26,6 +26,7 @@
> #include
> #include
>
> +#include
> #include
>
> #include "i915_drv.h"
> @@ -909,6 +910,9 @@ static void i915_pci_shutdown(struct pci_dev *pdev)
> /* Cancel any outstanding rendering */
> if (READ_ONCE(i915->gt.awake))
> i915_gem_set_wedged(i915);
> +
> + /* Disable active links to avoid confusing certain (Dell) monitors */
> + drm_atomic_helper_shutdown(&i915->drm);
I think we could use this to replace edp_notify_handler(). But the above
alone is not enough because it won't do the wait, as we do the waits in
enable, and after boot we've lost track of when the last disable was.
BR,
Jani.
> }
>
> static struct pci_driver i915_pci_driver = {
--
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] [v10 09/12] drm/i915:Enabled Modeset when HDR Infoframe changes
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Thursday, May 16, 2019 12:57 AM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; jo...@kwiboo.se; intel-gfx@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org
>Subject: Re: [v10 09/12] drm/i915:Enabled Modeset when HDR Infoframe changes
>
>On Tue, May 14, 2019 at 11:06:31PM +0530, Uma Shankar wrote:
>> This patch enables modeset whenever HDR metadata needs to be updated
>> to sink.
>>
>> v2: Addressed Shashank's review comments.
>>
>> v3: Added Shashank's RB.
>>
>> v4: Addressed Ville's review comments.
>>
>> Signed-off-by: Ville Syrjälä
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c | 14 +-
>> drivers/gpu/drm/i915/intel_hdmi.c | 13 +
>> 2 files changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 58b8049..6b985e8 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -105,6 +105,16 @@ int intel_digital_connector_atomic_set_property(struct
>drm_connector *connector,
>> return -EINVAL;
>> }
>>
>> +static bool blob_equal(const struct drm_property_blob *a,
>> + const struct drm_property_blob *b) {
>> +if (a && b)
>> +return a->length == b->length &&
>> +!memcmp(a->data, b->data, a->length);
>> +
>> +return !a == !b;
>> +}
>> +
>> int intel_digital_connector_atomic_check(struct drm_connector *conn,
>> struct drm_connector_state *new_state)
>> {
>@@ -132,7 +142,9 @@
>> int intel_digital_connector_atomic_check(struct drm_connector *conn,
>> new_conn_state->base.colorspace != old_conn_state->base.colorspace
>> ||
>> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>base.picture_aspect_ratio ||
>> new_conn_state->base.content_type != old_conn_state-
>>base.content_type ||
>> -new_conn_state->base.scaling_mode != old_conn_state-
>>base.scaling_mode)
>> +new_conn_state->base.scaling_mode != old_conn_state-
>>base.scaling_mode ||
>> +!blob_equal(new_conn_state->base.hdr_output_metadata,
>> +old_conn_state->base.hdr_output_metadata))
>> crtc_state->mode_changed = true;
>>
>> return 0;
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index b80406b..e97bf6e 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -806,6 +806,11 @@ void intel_read_infoframe(struct intel_encoder *encoder,
>> return true;
>> }
>>
>> +static inline bool is_eotf_supported(u8 output_eotf, u8 sink_eotf) {
>> +return sink_eotf & BIT(output_eotf); }
>> +
>> static bool
>> intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
>> struct intel_crtc_state *crtc_state, @@ -814,6
>+819,7 @@ void
>> intel_read_infoframe(struct intel_encoder *encoder,
>> struct hdmi_drm_infoframe *frame = &crtc_state->infoframes.drm.drm;
>> struct hdr_output_metadata *hdr_metadata;
>> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> +struct drm_connector *connector = conn_state->connector;
>> int ret;
>>
>> if (!(INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))) @@
>> -828,6 +834,13 @@ void intel_read_infoframe(struct intel_encoder
>> *encoder,
>>
>> hdr_metadata = conn_state->hdr_output_metadata->data;
>>
>> +/* Sink EOTF is Bit map while infoframe is absolute values */
>> +if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
>> +connector->hdr_sink_metadata.hdmi_type1.eotf)) {
>> +DRM_ERROR("EOTF Not Supported\n");
>> +return true;
>> +}
>
>I was going to say that this should probably be in the
>drm_set_hdr_metdata() or whatever it was called.
>
>But now I'm now wondering if we can even have this check here. What happens if
>someone does a display switcheroo while the machine is suspended? Depends on
>when we're going to reprobe the displays I suppose. Hmm. Maybe it's fine. We
>already have a similar issue after all wih the has_hdmi2_sink stuff.
>
>Either way the user triggerable DRM_ERROR()s are at least a nono.
Ok, Will keep the check and move it inside the drm_set_hdr_metdata(). Also
downgrade
the print as INFO instead of ERROR. Hope this is fine.
>> +
>> crtc_state->infoframes.enable |=
>> intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
>>
>> --
>> 1.9.1
>
>--
>Ville Syrjälä
>Intel
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
__
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
Hi Sean,
On Mon, May 13, 2019 at 10:38:58AM -0400, Sean Paul wrote:
> On Sat, May 11, 2019 at 3:12 PM Laurent Pinchart wrote:
> > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> >> From: Sean Paul
> >>
> >> Everyone who implements connector_helper_funcs->atomic_check reaches
> >> into the connector state to get the atomic state. Instead of continuing
> >> this pattern, change the callback signature to just give atomic state
> >> and let the driver determine what it does and does not need from it.
> >>
> >> Eventually all atomic functions should do this, but that's just too much
> >> busy work for me.
> >
> > Given that drivers also access the connector state, isn't this slightly
> > more inefficient ?
>
> Inefficient in terms of what?
In terms of the operation having to lookup the connector state, when the
caller has it and can easily pass it. As Daniel commented, this may be
the price to pay for a cleaner API, but I wonder how much overhead all
the state tracking is costing.
> Agree that in isolation this patch might seem unnecessary, but it ties
> in with the encoder and bridge CLs which accept drm_atomic_state in
CLs ?
> their hooks. In general the idea is to convert all atomic functions to
> take overall atomic state instead of just their object state. Reality
> has proven to be more complicated and we need more access than what
> the current implementation provides.
>
> Sean
>
> >> Changes in v3:
> >> - Added to the set
> >>
> >> Cc: Daniel Vetter
> >> Cc: Ville Syrjälä
> >> Cc: Jani Nikula
> >> Cc: Joonas Lahtinen
> >> Cc: Rodrigo Vivi
> >> Cc: Ben Skeggs
> >> Cc: Laurent Pinchart
> >> Cc: Kieran Bingham
> >> Cc: Eric Anholt
> >> Signed-off-by: Sean Paul
> >> ---
> >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> >> drivers/gpu/drm/i915/intel_atomic.c | 8 +---
> >> drivers/gpu/drm/i915/intel_dp_mst.c | 7 ---
> >> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> >> drivers/gpu/drm/i915/intel_sdvo.c| 9 +
> >> drivers/gpu/drm/i915/intel_tv.c | 8 +---
> >> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
> >> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++-
> >> drivers/gpu/drm/vc4/vc4_txp.c| 7 ---
> >> include/drm/drm_modeset_helper_vtables.h | 2 +-
> >> 10 files changed, 37 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 9d9e47276839..fa5a367507c1 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >> }
> >>
> >> if (funcs->atomic_check)
> >> - ret = funcs->atomic_check(connector,
> >> new_connector_state);
> >> + ret = funcs->atomic_check(connector, state);
> >> if (ret)
> >> return ret;
> >>
> >> @@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >> continue;
> >>
> >> if (funcs->atomic_check)
> >> - ret = funcs->atomic_check(connector,
> >> new_connector_state);
> >> + ret = funcs->atomic_check(connector, state);
> >> if (ret)
> >> return ret;
> >> }
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index b844e8840c6f..e8a5b82e9242 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -103,12 +103,14 @@ int
> >> intel_digital_connector_atomic_set_property(struct drm_connector
> >> *connector,
> >> }
> >>
> >> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> >> - struct drm_connector_state
> >> *new_state)
> >> + struct drm_atomic_state *state)
> >> {
> >> + struct drm_connector_state *new_state =
> >> + drm_atomic_get_new_connector_state(state, conn);
> >> struct intel_digital_connector_state *new_conn_state =
> >> to_intel_digital_connector_state(new_state);
> >> struct drm_connector_state *old_state =
> >> - drm_atomic_get_old_connector_state(new_state->state, conn);
> >> + drm_atomic_get_old_connector_state(state, conn);
> >> struct intel_digital_connector_state *old_conn_state =
> >> to_intel_digital_connector_state(old_state);
> >> struct drm_crtc_state *crtc_state;
> >> @@ -118,7 +120,7 @@ int intel_digital_connector_atomic_check(struct
> >> drm_connector *conn,
> >> if (!new_state->crtc)
> >> return 0;
> >>
> >> - crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> >> new_state->crtc);
> >> + crtc_state = drm_atomic_get_new_crtc_state(state, new_state->c
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
Hi Daniel,
On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote:
> On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote:
> > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> >> From: Sean Paul
> >>
> >> Everyone who implements connector_helper_funcs->atomic_check reaches
> >> into the connector state to get the atomic state. Instead of continuing
> >> this pattern, change the callback signature to just give atomic state
> >> and let the driver determine what it does and does not need from it.
> >>
> >> Eventually all atomic functions should do this, but that's just too much
> >> busy work for me.
> >
> > Given that drivers also access the connector state, isn't this slightly
> > more inefficient ?
>
> It's atomic code, we're trying to optimize for clean code at the expense
> of a bit of runtime overhead due to more pointer chasing. And I agree with
> the general push, the pile of old/new_state pointers of various objects
> we're passing around is confusing. Passing the overall drm_atomic_state
> seems much more reasonable, and with that we can get everything else. Plus
> it's much more obvious whether you have the old/new state (since that's
> explicit when you look it up from the drm_atomic_state).
Yes, I agree it's cleaner. I just hope the atomic state tracking cost
can be kept under control :-)
By the way, this is likely not going to happen as it would be way too
intrusive, but it would be nice to rename drm_atomic_state to
drm_atomic_transaction (or something similar). It doesn't model a state,
but a change between an old state to a new state. This confused me in
the past, and I'm sure it can still be confusing to newcomers.
> If we ever see this show up in profile, and it starts mattering, first
> thing we need is a hashtable I think (atm it's list walking, which is just
> terrible). But thus far no one cares.
>
> >> Changes in v3:
> >> - Added to the set
> >>
> >> Cc: Daniel Vetter
> >> Cc: Ville Syrjälä
> >> Cc: Jani Nikula
> >> Cc: Joonas Lahtinen
> >> Cc: Rodrigo Vivi
> >> Cc: Ben Skeggs
> >> Cc: Laurent Pinchart
> >> Cc: Kieran Bingham
> >> Cc: Eric Anholt
> >> Signed-off-by: Sean Paul
> >> ---
> >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> >> drivers/gpu/drm/i915/intel_atomic.c | 8 +---
> >> drivers/gpu/drm/i915/intel_dp_mst.c | 7 ---
> >> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> >> drivers/gpu/drm/i915/intel_sdvo.c| 9 +
> >> drivers/gpu/drm/i915/intel_tv.c | 8 +---
> >> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
> >> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++-
> >> drivers/gpu/drm/vc4/vc4_txp.c| 7 ---
> >> include/drm/drm_modeset_helper_vtables.h | 2 +-
> >> 10 files changed, 37 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 9d9e47276839..fa5a367507c1 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >>}
> >>
> >>if (funcs->atomic_check)
> >> - ret = funcs->atomic_check(connector,
> >> new_connector_state);
> >> + ret = funcs->atomic_check(connector, state);
> >>if (ret)
> >>return ret;
> >>
> >> @@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> >>continue;
> >>
> >>if (funcs->atomic_check)
> >> - ret = funcs->atomic_check(connector,
> >> new_connector_state);
> >> + ret = funcs->atomic_check(connector, state);
> >>if (ret)
> >>return ret;
> >>}
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index b844e8840c6f..e8a5b82e9242 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -103,12 +103,14 @@ int
> >> intel_digital_connector_atomic_set_property(struct drm_connector
> >> *connector,
> >> }
> >>
> >> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> >> - struct drm_connector_state *new_state)
> >> + struct drm_atomic_state *state)
> >> {
> >> + struct drm_connector_state *new_state =
> >> + drm_atomic_get_new_connector_state(state, conn);
> >>struct intel_digital_connector_state *new_conn_state =
> >>to_intel_digital_connector_state(new_state);
> >>struct drm_connector_state *old_state =
> >> - drm_atomic_get_old_connector_state(new_state->state, conn);
> >> + drm_atomic_get_old_connector_state(state, conn);
> >>struct intel_digital_connector_state *old_conn_state =
> >>to_intel_digital_connector_sta
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
On Thu, May 16, 2019 at 2:02 PM Laurent Pinchart wrote: > > Hi Daniel, > > On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote: > > On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote: > > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote: > > >> From: Sean Paul > > >> > > >> Everyone who implements connector_helper_funcs->atomic_check reaches > > >> into the connector state to get the atomic state. Instead of continuing > > >> this pattern, change the callback signature to just give atomic state > > >> and let the driver determine what it does and does not need from it. > > >> > > >> Eventually all atomic functions should do this, but that's just too much > > >> busy work for me. > > > > > > Given that drivers also access the connector state, isn't this slightly > > > more inefficient ? > > > > It's atomic code, we're trying to optimize for clean code at the expense > > of a bit of runtime overhead due to more pointer chasing. And I agree with > > the general push, the pile of old/new_state pointers of various objects > > we're passing around is confusing. Passing the overall drm_atomic_state > > seems much more reasonable, and with that we can get everything else. Plus > > it's much more obvious whether you have the old/new state (since that's > > explicit when you look it up from the drm_atomic_state). > > Yes, I agree it's cleaner. I just hope the atomic state tracking cost > can be kept under control :-) > > By the way, this is likely not going to happen as it would be way too > intrusive, but it would be nice to rename drm_atomic_state to > drm_atomic_transaction (or something similar). It doesn't model a state, > but a change between an old state to a new state. This confused me in > the past, and I'm sure it can still be confusing to newcomers. Why are you the first to suggest this, this is awesome! drm_atomic_state is indeed not a state, but a transaction representing how we go from the old to the new state. I think this is awesome enough that we should actually try to make it happen. Tree-wide cocci + bribing Dave on St. Patrick's day with lots of beer might be enough :-) -Daniel > > If we ever see this show up in profile, and it starts mattering, first > > thing we need is a hashtable I think (atm it's list walking, which is just > > terrible). But thus far no one cares. > > > > >> Changes in v3: > > >> - Added to the set > > >> > > >> Cc: Daniel Vetter > > >> Cc: Ville Syrjälä > > >> Cc: Jani Nikula > > >> Cc: Joonas Lahtinen > > >> Cc: Rodrigo Vivi > > >> Cc: Ben Skeggs > > >> Cc: Laurent Pinchart > > >> Cc: Kieran Bingham > > >> Cc: Eric Anholt > > >> Signed-off-by: Sean Paul > > >> --- > > >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- > > >> drivers/gpu/drm/i915/intel_atomic.c | 8 +--- > > >> drivers/gpu/drm/i915/intel_dp_mst.c | 7 --- > > >> drivers/gpu/drm/i915/intel_drv.h | 2 +- > > >> drivers/gpu/drm/i915/intel_sdvo.c| 9 + > > >> drivers/gpu/drm/i915/intel_tv.c | 8 +--- > > >> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++-- > > >> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++- > > >> drivers/gpu/drm/vc4/vc4_txp.c| 7 --- > > >> include/drm/drm_modeset_helper_vtables.h | 2 +- > > >> 10 files changed, 37 insertions(+), 27 deletions(-) > > >> > > >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > >> b/drivers/gpu/drm/drm_atomic_helper.c > > >> index 9d9e47276839..fa5a367507c1 100644 > > >> --- a/drivers/gpu/drm/drm_atomic_helper.c > > >> +++ b/drivers/gpu/drm/drm_atomic_helper.c > > >> @@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device > > >> *dev, > > >>} > > >> > > >>if (funcs->atomic_check) > > >> - ret = funcs->atomic_check(connector, > > >> new_connector_state); > > >> + ret = funcs->atomic_check(connector, state); > > >>if (ret) > > >>return ret; > > >> > > >> @@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device > > >> *dev, > > >>continue; > > >> > > >>if (funcs->atomic_check) > > >> - ret = funcs->atomic_check(connector, > > >> new_connector_state); > > >> + ret = funcs->atomic_check(connector, state); > > >>if (ret) > > >>return ret; > > >>} > > >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c > > >> b/drivers/gpu/drm/i915/intel_atomic.c > > >> index b844e8840c6f..e8a5b82e9242 100644 > > >> --- a/drivers/gpu/drm/i915/intel_atomic.c > > >> +++ b/drivers/gpu/drm/i915/intel_atomic.c > > >> @@ -103,12 +103,14 @@ int > > >> intel_digital_connector_atomic_set_property(struct drm_connector > > >> *connector, > > >> } > > >> > > >> int intel_digital_connector_atomic_check(struct drm_connector *conn, > > >> - struct drm_connector_state > > >> *new_state) > >
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote: > On Wed, 15 May 2019 10:24:49 +0200 > Daniel Vetter wrote: > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote: > > > On Tue, 14 May 2019 16:34:01 +0200 > > > Daniel Vetter wrote: > > > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen > > > > wrote: > > > > > > > > > > On Tue, 14 May 2019 13:02:09 +0200 > > > > > Daniel Vetter wrote: > > > > > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > > > > > ... > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > > > > > just to clarify the first case, specific to one very particular > > > > > > > > property: > > > > > > > > > > > > > > > > With HDCP, there is a property that may change dynamically at > > > > > > > > runtime > > > > > > > > (the undesired/desired/enabled tristate). Userspace must be > > > > > > > > notified > > > > > > > > when it changes, I do not want userspace have to poll that > > > > > > > > property > > > > > > > > with a timer. > > > > > > > > > > > > > > > > When that property alone changes, and userspace is prepared to > > > > > > > > handle > > > > > > > > that property changing alone, it must not trigger a reprobe of > > > > > > > > the > > > > > > > > connector. There is no reason to reprobe at that point AFAIU. > > > > > > > > > > > > > > > > How do you ensure that userspace can avoid triggering a reprobe > > > > > > > > with the > > > > > > > > epoch approach or with any alternate uevent design? > > > > > > > > > > > > > > > > We need an event to userspace that indicates that re-reading the > > > > > > > > properties is enough and reprobe of the connector is not > > > > > > > > necessary. > > > > > > > > This is complementary to indicating to userspace that only some > > > > > > > > connectors need to be reprobed instead of everything. > > > > > > > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, > > > > > > > skip the > > > > > > > reprobing. Would that work? > > > > > > > > > > Hi, > > > > > > > > > > yes, that would work, if it was acceptable to DRM upstream. The > > > > > replies > > > > > to Paul seemed to be going south so fast that I thought we wouldn't > > > > > get > > > > > any new uevent fields in favour of "epoch counters". > > > > > > > > > > > Yes that's the idea, depending upon which property you get you know > > > > > > it's a sink change (needs full reprobe) or something else like hdcp > > > > > > state machinery update. > > > > > > > > > > Right. > > > > > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we should > > > > > > indeed decouple that from the per-connector event for sink changes. > > > > > > That along is a good win already, since you know for which connector > > > > > > you need to call drmGetConnector (which forces the reprobe). It > > > > > > would > > > > > > be nice to only call drmGetConnectorCurrent (avoids the reprobe), > > > > > > but > > > > > > historically speaking every time we tried to rely on this we ended > > > > > > up > > > > > > regretting things. > > > > > > > > > > What changed? This sounds very much what Paul suggested. Looking at it > > > > > from userspace side: > > > > > > > > This sounds solid, some refinements below: > > > > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy > > > > > > > > > > - If yy is "Content Protection", no need to drmModeGetConnector(), > > > > > just > > > > > re-get the connector properties. > > > > > > > > > > - Kernel probably shouldn't bother sending this for properties where > > > > > re-probe could be necessary, and send the below instead. > > > > > > > > > > > > I think we should assert that the kernel can get the new property > > > > values using drmModeGetConnectorCurrent for this case, i.e. the kernel > > > > does not expect a full reprobe. I.e. upgrade your idea from "should" > > > > to "must" > > > > > > Hi Daniel, > > > > > > ok, that's good. > > > > > > > Furthermore different property can indicate different kind of updates, > > > > e.g. hdcp vs general sink change vs. whatever else might come in the > > > > future. > > > > > > What do you mean by different kinds of updates? > > > > Atm we're discussing two: > > > > - "Content Protection" > > - "sink changed, but you don't need to reprobe" this would be quite a bit > > a catch all from the output detection. Paul thinks differently, but I'm > > not sold on splitting this up more, at least not right now. This would > > include connector status (and related things returned by drmGetConnector > > which currently aren't a property), EDID, the mst path id, that kind of > > stuff. > > > > Ime once we have 2, there's more bound to come :-) > > Hi Daniel, > > I don't understand what the "sink changed" thing could be, but sure, > there can be mo
Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs
Op 16-05-2019 om 07:58 schreef Harish Chegondi:
> display_pipe_crc_irq_handler() skips the first CRC for all GPUs and the
> second CRC for GEN8+ GPUs. The second CRC is invalid even for BYT which
> is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
>
> Cc: Jani Nikula
> Cc: Tomi Sarvela
> Cc: Petri Latvala
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Signed-off-by: Harish Chegondi
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> ---
> drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 233211fde0ea..3809e9f7fae2 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1775,11 +1775,11 @@ static void display_pipe_crc_irq_handler(struct
> drm_i915_private *dev_priv,
>* bonkers. So let's just wait for the next vblank and read
>* out the buggy result.
>*
> - * On GEN8+ sometimes the second CRC is bonkers as well, so
> + * On GEN7+ sometimes the second CRC is bonkers as well, so
>* don't trust that one either.
>*/
> if (pipe_crc->skipped <= 0 ||
> - (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
> + (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped == 1)) {
> pipe_crc->skipped++;
> spin_unlock(&pipe_crc->lock);
> return;
I would be interested in the results, haswell is different from VLV. Has it
ever been observed on that platform?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs
On Thu, 16 May 2019, Maarten Lankhorst
wrote:
> Op 16-05-2019 om 07:58 schreef Harish Chegondi:
>> display_pipe_crc_irq_handler() skips the first CRC for all GPUs and the
>> second CRC for GEN8+ GPUs. The second CRC is invalid even for BYT which
>> is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
>>
>> Cc: Jani Nikula
>> Cc: Tomi Sarvela
>> Cc: Petri Latvala
>> Cc: Ville Syrjälä
>> Cc: Maarten Lankhorst
>> Signed-off-by: Harish Chegondi
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 233211fde0ea..3809e9f7fae2 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -1775,11 +1775,11 @@ static void display_pipe_crc_irq_handler(struct
>> drm_i915_private *dev_priv,
>> * bonkers. So let's just wait for the next vblank and read
>> * out the buggy result.
>> *
>> - * On GEN8+ sometimes the second CRC is bonkers as well, so
>> + * On GEN7+ sometimes the second CRC is bonkers as well, so
>> * don't trust that one either.
>> */
>> if (pipe_crc->skipped <= 0 ||
>> -(INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
>> +(INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped == 1)) {
>> pipe_crc->skipped++;
>> spin_unlock(&pipe_crc->lock);
>> return;
>
> I would be interested in the results, haswell is different from
> VLV. Has it ever been observed on that platform?
Good point. I looked at [1] which I presumed was on VLV, but it says
nothing about HSW.
BR,
Jani.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=103191#c34
>
--
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 v5 08/11] drm/fb-helper: Remove drm_fb_helper_connector
Hi Noralf.
See few comments in the following.
Sam
On Mon, May 06, 2019 at 08:01:36PM +0200, Noralf Trønnes wrote:
> All drivers add all their connectors so there's no need to keep around an
> array of available connectors.
>
> Rename functions which signature is changed since they will be moved to
> drm_client in a later patch.
>
> Signed-off-by: Noralf Trønnes
> ---
> @@ -1645,8 +1461,9 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> struct drm_client_dev *client = &fb_helper->client;
> int ret = 0;
> int crtc_count = 0;
> - int i;
> + struct drm_connector_list_iter conn_iter;
> struct drm_fb_helper_surface_size sizes;
> + struct drm_connector *connector;
> struct drm_mode_set *mode_set;
> int best_depth = 0;
>
> @@ -1663,11 +1480,11 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> if (preferred_bpp != sizes.surface_bpp)
> sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
>
> - drm_fb_helper_for_each_connector(fb_helper, i) {
> - struct drm_fb_helper_connector *fb_helper_conn =
> fb_helper->connector_info[i];
> + drm_connector_list_iter_begin(fb_helper->dev, &conn_iter);
> + drm_client_for_each_connector_iter(connector, &conn_iter) {
> struct drm_cmdline_mode *cmdline_mode;
I fail to see when to use drm_client_for_each_connector_iter() and when
to use a simple for loop.
In this patch drm_fb_helper_for_each_connector() is here replaced by the
iterator variant and in many other placed a simple for loop.
The old code, in this place, would go through all connectors, but this
code will skip DRM_MODE_CONNECTOR_WRITEBACK conectors.
So it does not like identical code.
>
> - cmdline_mode = &fb_helper_conn->connector->cmdline_mode;
> + cmdline_mode = &connector->cmdline_mode;
>
> if (cmdline_mode->bpp_specified) {
> switch (cmdline_mode->bpp) {
> @@ -1692,6 +1509,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> break;
> }
> }
> + drm_connector_list_iter_end(&conn_iter);
>
> /*
>* If we run into a situation where, for example, the primary plane
> @@ -1876,26 +1694,12 @@ void drm_fb_helper_fill_info(struct fb_info *info,
> }
> EXPORT_SYMBOL(drm_fb_helper_fill_info);
>
> +static void drm_client_connectors_enabled(struct drm_connector **connectors,
> + unsigned int connector_count,
> + bool *enabled)
> {
> bool any_enabled = false;
> struct drm_connector *connector;
> int i = 0;
>
> - drm_fb_helper_for_each_connector(fb_helper, i) {
> - connector = fb_helper->connector_info[i]->connector;
> + for (i = 0; i < connector_count; i++) {
> + connector = connectors[i];
This is for example a place where the drm_fb_helper_for_each_connector()
is replaced by a simple for loop.
The simple for loop is nice and readable - just a comment replated to
the above comment.
> struct drm_display_mode *mode = modes[i];
> struct drm_crtc *crtc = crtcs[i];
> struct drm_fb_offset *offset = &offsets[i];
>
> if (mode && crtc) {
> struct drm_mode_set *modeset =
> drm_client_find_modeset(client, crtc);
> - struct drm_connector *connector =
> - fb_helper->connector_info[i]->connector;
> + struct drm_connector *connector = connectors[i];
>
> DRM_DEBUG_KMS("desired mode %s set on crtc %d
> (%d,%d)\n",
> mode->name, crtc->base.id, offset->x,
> offset->y);
> @@ -2539,6 +2354,10 @@ static void drm_setup_crtcs(struct drm_fb_helper
> *fb_helper,
> kfree(modes);
> kfree(offsets);
> kfree(enabled);
> +free_connectors:
> + for (i = 0; i < connector_count; i++)
> + drm_connector_put(connectors[i]);
This may call drm_connector_put(NULL) as not all connectors are init.
> + kfree(connectors);
> }
>
> /*
> @@ -2551,10 +2370,11 @@ static void drm_setup_crtcs(struct drm_fb_helper
> *fb_helper,
> static void drm_setup_crtcs_fb(struct drm_fb_helper *fb_helper)
> {
> struct drm_client_dev *client = &fb_helper->client;
> + struct drm_connector_list_iter conn_iter;
> struct fb_info *info = fb_helper->fbdev;
> unsigned int rotation, sw_rotations = 0;
> + struct drm_connector *connector;
> struct drm_mode_set *modeset;
> - int i;
>
> mutex_lock(&client->modeset_mutex);
> drm_client_for_each_modeset(modeset, client) {
> @@ -2571,10 +2391,8 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper
> *fb_helper)
> }
> mutex_unlock(&client->modeset_mutex);
>
> - mutex_l
Re: [Intel-gfx] [v10 09/12] drm/i915:Enabled Modeset when HDR Infoframe changes
On Thu, May 16, 2019 at 10:54:14AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Thursday, May 16, 2019 12:57 AM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org; jo...@kwiboo.se; intel-gfx@lists.freedesktop.org;
> >emil.l.veli...@gmail.com; dri-de...@lists.freedesktop.org;
> >seanp...@chromium.org
> >Subject: Re: [v10 09/12] drm/i915:Enabled Modeset when HDR Infoframe changes
> >
> >On Tue, May 14, 2019 at 11:06:31PM +0530, Uma Shankar wrote:
> >> This patch enables modeset whenever HDR metadata needs to be updated
> >> to sink.
> >>
> >> v2: Addressed Shashank's review comments.
> >>
> >> v3: Added Shashank's RB.
> >>
> >> v4: Addressed Ville's review comments.
> >>
> >> Signed-off-by: Ville Syrjälä
> >> Signed-off-by: Uma Shankar
> >> Reviewed-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/i915/intel_atomic.c | 14 +-
> >> drivers/gpu/drm/i915/intel_hdmi.c | 13 +
> >> 2 files changed, 26 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index 58b8049..6b985e8 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -105,6 +105,16 @@ int intel_digital_connector_atomic_set_property(struct
> >drm_connector *connector,
> >>return -EINVAL;
> >> }
> >>
> >> +static bool blob_equal(const struct drm_property_blob *a,
> >> + const struct drm_property_blob *b) {
> >> + if (a && b)
> >> + return a->length == b->length &&
> >> + !memcmp(a->data, b->data, a->length);
> >> +
> >> + return !a == !b;
> >> +}
> >> +
> >> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> >> struct drm_connector_state *new_state)
> >> {
> >@@ -132,7 +142,9 @@
> >> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> >>new_conn_state->base.colorspace != old_conn_state->base.colorspace
> >> ||
> >>new_conn_state->base.picture_aspect_ratio != old_conn_state-
> >>base.picture_aspect_ratio ||
> >>new_conn_state->base.content_type != old_conn_state-
> >>base.content_type ||
> >> - new_conn_state->base.scaling_mode != old_conn_state-
> >>base.scaling_mode)
> >> + new_conn_state->base.scaling_mode != old_conn_state-
> >>base.scaling_mode ||
> >> + !blob_equal(new_conn_state->base.hdr_output_metadata,
> >> + old_conn_state->base.hdr_output_metadata))
> >>crtc_state->mode_changed = true;
> >>
> >>return 0;
> >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> >> b/drivers/gpu/drm/i915/intel_hdmi.c
> >> index b80406b..e97bf6e 100644
> >> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> >> @@ -806,6 +806,11 @@ void intel_read_infoframe(struct intel_encoder
> >> *encoder,
> >>return true;
> >> }
> >>
> >> +static inline bool is_eotf_supported(u8 output_eotf, u8 sink_eotf) {
> >> + return sink_eotf & BIT(output_eotf); }
> >> +
> >> static bool
> >> intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
> >> struct intel_crtc_state *crtc_state, @@ -814,6
> >+819,7 @@ void
> >> intel_read_infoframe(struct intel_encoder *encoder,
> >>struct hdmi_drm_infoframe *frame = &crtc_state->infoframes.drm.drm;
> >>struct hdr_output_metadata *hdr_metadata;
> >>struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >> + struct drm_connector *connector = conn_state->connector;
> >>int ret;
> >>
> >>if (!(INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))) @@
> >> -828,6 +834,13 @@ void intel_read_infoframe(struct intel_encoder
> >> *encoder,
> >>
> >>hdr_metadata = conn_state->hdr_output_metadata->data;
> >>
> >> + /* Sink EOTF is Bit map while infoframe is absolute values */
> >> + if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
> >> + connector->hdr_sink_metadata.hdmi_type1.eotf)) {
> >> + DRM_ERROR("EOTF Not Supported\n");
> >> + return true;
> >> + }
> >
> >I was going to say that this should probably be in the
> >drm_set_hdr_metdata() or whatever it was called.
> >
> >But now I'm now wondering if we can even have this check here. What happens
> >if
> >someone does a display switcheroo while the machine is suspended? Depends on
> >when we're going to reprobe the displays I suppose. Hmm. Maybe it's fine. We
> >already have a similar issue after all wih the has_hdmi2_sink stuff.
> >
> >Either way the user triggerable DRM_ERROR()s are at least a nono.
>
> Ok, Will keep the check and move it inside the drm_set_hdr_metdata(). Also
> downgrade
> the print as INFO instead of ERROR. Hope this is fine.
DEBUG_KMS like everything else.
>
> >> +
> >>crtc_state->infoframes.enable |=
> >>intel_hdmi_inf
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10)
On Thu, May 16, 2019 at 07:28:43AM +, Shankar, Uma wrote: > > > >-Original Message- > >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >Sent: Thursday, May 16, 2019 1:02 AM > >To: Shankar, Uma > >Cc: intel-gfx@lists.freedesktop.org > >Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing > >and handling > >in DRM layer (rev10) > > > >On Wed, May 15, 2019 at 08:59:37AM +, Shankar, Uma wrote: > >> > >> > >> >-Original Message- > >> >From: Patchwork [mailto:patchw...@emeril.freedesktop.org] > >> >Sent: Wednesday, May 15, 2019 6:54 AM > >> >To: Shankar, Uma > >> >Cc: intel-gfx@lists.freedesktop.org > >> >Subject: ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and > >> >handling in DRM layer > >> >(rev10) > >> > > >> >== Series Details == > >> > > >> >Series: Add HDR Metadata Parsing and handling in DRM layer (rev10) > >> >URL : https://patchwork.freedesktop.org/series/25091/ > >> >State : failure > >> > > >> >== Summary == > >> > > >> >CI Bug Log - changes from CI_DRM_6081_full -> Patchwork_13017_full > >> > > >> > > >> >Summary > >> >--- > >> > > >> > **FAILURE** > >> > > >> > Serious unknown changes coming with Patchwork_13017_full absolutely > >> > need to be verified manually. > >> > > >> > If you think the reported changes have nothing to do with the > >> > changes introduced in Patchwork_13017_full, please notify your bug > >> > team to allow them to document this new failure mode, which will reduce > >> > false > >positives in CI. > >> > > >> > > >> > > >> >Possible new issues > >> >--- > >> > > >> > Here are the unknown changes that may have been introduced in > >> >Patchwork_13017_full: > >> > > >> >### IGT changes ### > >> > > >> > Possible regressions > >> > > >> > * igt@gem_exec_suspend@basic-s3: > >> >- shard-iclb: [PASS][1] -> [SKIP][2] +43 similar issues > >> > [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard- > >> >iclb6/igt@gem_exec_susp...@basic-s3.html > >> > [2]: > >> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard- > >> >iclb5/igt@gem_exec_susp...@basic-s3.html > >> > > >> > * igt@kms_prop_blob@invalid-set-prop-any: > >> >- shard-iclb: [PASS][3] -> [FAIL][4] > >> > [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard- > >> >iclb6/igt@kms_prop_b...@invalid-set-prop-any.html > >> > [4]: > >> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard- > >> >iclb5/igt@kms_prop_b...@invalid-set-prop-any.html > >> > > >> > >> Hi Martin, > >> These issues are unrelated to the changes made in this series. Can you > >> please have a look and confirm. > > > >The kms_prop fails at least are real. Probably due to the bogus function > >arguements > >to the replace_blob() thing I pointed out. > > The CI IGT have a clean PASS now. You mean it went from FAIL to PASS on its own? Why did that happen? > Will anyways update the function arguments and make > it consistent. > > Regards, > Uma Shankar > > >-- > >Ville Syrjälä > >Intel -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10)
>> >> >-Original Message- >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >Sent: Thursday, May 16, 2019 1:02 AM >> >To: Shankar, Uma >> >Cc: intel-gfx@lists.freedesktop.org >> >Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata >> >Parsing and handling in DRM layer (rev10) >> > >> >On Wed, May 15, 2019 at 08:59:37AM +, Shankar, Uma wrote: >> >> >> >> >> >> >-Original Message- >> >> >From: Patchwork [mailto:patchw...@emeril.freedesktop.org] >> >> >Sent: Wednesday, May 15, 2019 6:54 AM >> >> >To: Shankar, Uma >> >> >Cc: intel-gfx@lists.freedesktop.org >> >> >Subject: ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and >> >> >handling in DRM layer >> >> >(rev10) >> >> > >> >> >== Series Details == >> >> > >> >> >Series: Add HDR Metadata Parsing and handling in DRM layer (rev10) >> >> >URL : https://patchwork.freedesktop.org/series/25091/ >> >> >State : failure >> >> > >> >> >== Summary == >> >> > >> >> >CI Bug Log - changes from CI_DRM_6081_full -> Patchwork_13017_full >> >> > >> >> > >> >> >Summary >> >> >--- >> >> > >> >> > **FAILURE** >> >> > >> >> > Serious unknown changes coming with Patchwork_13017_full >> >> > absolutely need to be verified manually. >> >> > >> >> > If you think the reported changes have nothing to do with the >> >> > changes introduced in Patchwork_13017_full, please notify your >> >> > bug team to allow them to document this new failure mode, which >> >> > will reduce false >> >positives in CI. >> >> > >> >> > >> >> > >> >> >Possible new issues >> >> >--- >> >> > >> >> > Here are the unknown changes that may have been introduced in >> >> >Patchwork_13017_full: >> >> > >> >> >### IGT changes ### >> >> > >> >> > Possible regressions >> >> > >> >> > * igt@gem_exec_suspend@basic-s3: >> >> >- shard-iclb: [PASS][1] -> [SKIP][2] +43 similar issues >> >> > [1]: >> >> >https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard- >> >> >iclb6/igt@gem_exec_susp...@basic-s3.html >> >> > [2]: >> >> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard- >> >> >iclb5/igt@gem_exec_susp...@basic-s3.html >> >> > >> >> > * igt@kms_prop_blob@invalid-set-prop-any: >> >> >- shard-iclb: [PASS][3] -> [FAIL][4] >> >> > [3]: >> >> >https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard- >> >> >iclb6/igt@kms_prop_b...@invalid-set-prop-any.html >> >> > [4]: >> >> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard- >> >> >iclb5/igt@kms_prop_b...@invalid-set-prop-any.html >> >> > >> >> >> >> Hi Martin, >> >> These issues are unrelated to the changes made in this series. Can >> >> you please have a look and confirm. >> > >> >The kms_prop fails at least are real. Probably due to the bogus >> >function arguements to the replace_blob() thing I pointed out. >> >> The CI IGT have a clean PASS now. > >You mean it went from FAIL to PASS on its own? Why did that happen? It was giving a PASS on earlier version v9 with same changes. But on v10 it gave this error. I was thinking it was re-run, on checking with Jani N he clarified that it was re-reported. >> Will anyways update the function arguments and make it consistent. >> >> Regards, >> Uma Shankar >> >> >-- >> >Ville Syrjälä >> >Intel > >-- >Ville Syrjälä >Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
On Thu, May 16, 2019 at 02:07:34PM +0200, Daniel Vetter wrote: > On Thu, May 16, 2019 at 2:02 PM Laurent Pinchart > wrote: > > > > Hi Daniel, > > > > On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote: > > > On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote: > > > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote: > > > >> From: Sean Paul > > > >> > > > >> Everyone who implements connector_helper_funcs->atomic_check reaches > > > >> into the connector state to get the atomic state. Instead of continuing > > > >> this pattern, change the callback signature to just give atomic state > > > >> and let the driver determine what it does and does not need from it. > > > >> > > > >> Eventually all atomic functions should do this, but that's just too > > > >> much > > > >> busy work for me. > > > > > > > > Given that drivers also access the connector state, isn't this slightly > > > > more inefficient ? > > > > > > It's atomic code, we're trying to optimize for clean code at the expense > > > of a bit of runtime overhead due to more pointer chasing. And I agree with > > > the general push, the pile of old/new_state pointers of various objects > > > we're passing around is confusing. Passing the overall drm_atomic_state > > > seems much more reasonable, and with that we can get everything else. Plus > > > it's much more obvious whether you have the old/new state (since that's > > > explicit when you look it up from the drm_atomic_state). > > > > Yes, I agree it's cleaner. I just hope the atomic state tracking cost > > can be kept under control :-) > > > > By the way, this is likely not going to happen as it would be way too > > intrusive, but it would be nice to rename drm_atomic_state to > > drm_atomic_transaction (or something similar). It doesn't model a state, > > but a change between an old state to a new state. This confused me in > > the past, and I'm sure it can still be confusing to newcomers. > > Why are you the first to suggest this, this is awesome! Can't quite tell if that's irony or not. Anyways, this has been suggested before but no volunteers stepped forward. > drm_atomic_state is indeed not a state, but a transaction representing > how we go from the old to the new state. On a semi-related topic, I've occasionally pondered about moving mode_changed & co. from the obj states to the top level state/transaction (maybe stored as a bitmask). But that would definitely not be a trivial sed job. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs
On Thu, May 16, 2019 at 03:55:25PM +0300, Jani Nikula wrote:
> On Thu, 16 May 2019, Maarten Lankhorst
> wrote:
> > Op 16-05-2019 om 07:58 schreef Harish Chegondi:
> >> display_pipe_crc_irq_handler() skips the first CRC for all GPUs and the
> >> second CRC for GEN8+ GPUs. The second CRC is invalid even for BYT which
> >> is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
> >>
> >> Cc: Jani Nikula
> >> Cc: Tomi Sarvela
> >> Cc: Petri Latvala
> >> Cc: Ville Syrjälä
> >> Cc: Maarten Lankhorst
> >> Signed-off-by: Harish Chegondi
> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> >> ---
> >> drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 233211fde0ea..3809e9f7fae2 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -1775,11 +1775,11 @@ static void display_pipe_crc_irq_handler(struct
> >> drm_i915_private *dev_priv,
> >> * bonkers. So let's just wait for the next vblank and read
> >> * out the buggy result.
> >> *
> >> - * On GEN8+ sometimes the second CRC is bonkers as well, so
> >> + * On GEN7+ sometimes the second CRC is bonkers as well, so
> >> * don't trust that one either.
> >> */
> >>if (pipe_crc->skipped <= 0 ||
> >> - (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
> >> + (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped == 1)) {
> >>pipe_crc->skipped++;
> >>spin_unlock(&pipe_crc->lock);
> >>return;
> >
> > I would be interested in the results, haswell is different from
> > VLV. Has it ever been observed on that platform?
>
> Good point. I looked at [1] which I presumed was on VLV, but it says
> nothing about HSW.
This whole thing is just a pile of duct tape anyway. The reason(s)
for these funky crcs has never been properly analysed.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 06/12] drm/i915: Write HDR infoframe and send to panel
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe calculation in compute config.
v6: Addressed Shashank's review comment. Added HDR metadata
support from GEN10 onwards as per Shashank's recommendation.
v7: Addressed Shashank's review comments
v8: Added Shashank's RB.
v9: Addressed Ville's review comments.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 44 +++
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5258abb..40e2c52 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -910,6 +910,7 @@ struct intel_crtc_state {
union hdmi_infoframe avi;
union hdmi_infoframe spd;
union hdmi_infoframe hdmi;
+ union hdmi_infoframe drm;
} infoframes;
/* HDMI scrambling status */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 92597d8..d3b8e09 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -573,6 +573,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
HDMI_INFOFRAME_TYPE_AVI,
HDMI_INFOFRAME_TYPE_SPD,
HDMI_INFOFRAME_TYPE_VENDOR,
+ HDMI_INFOFRAME_TYPE_DRM,
};
u32 intel_hdmi_infoframe_enable(unsigned int type)
@@ -795,6 +796,41 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static bool
+intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct hdmi_drm_infoframe *frame = &crtc_state->infoframes.drm.drm;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ int ret;
+
+ if (!(INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)))
+ return true;
+
+ if (!crtc_state->has_infoframe)
+ return true;
+
+ if (!conn_state->hdr_output_metadata ||
+ conn_state->hdr_output_metadata->length == 0)
+ return true;
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(frame, conn_state);
+ if (ret < 0) {
+ DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+ return false;
+ }
+
+ ret = hdmi_drm_infoframe_check(frame);
+ if (WARN_ON(ret))
+ return false;
+
+ return true;
+}
+
static void g4x_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -1180,6 +1216,9 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
intel_write_infoframe(encoder, crtc_state,
HDMI_INFOFRAME_TYPE_VENDOR,
&crtc_state->infoframes.hdmi);
+ intel_write_infoframe(encoder, crtc_state,
+ HDMI_INFOFRAME_TYPE_DRM,
+ &crtc_state->infoframes.drm);
}
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
@@ -2386,6 +2425,11 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
return -EINVAL;
}
+ if (!intel_hdmi_compute_drm_infoframe(encoder, pipe_config,
conn_state)) {
+ DRM_DEBUG_KMS("bad DRM infoframe\n");
+ return -EINVAL;
+ }
+
return 0;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 01/12] drm: Add HDR source metadata property
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
It also implements get() and set() functions for HDR output
metadata property.The blob data is received from userspace and
saved in connector state, the same is returned as blob in get
property call to userspace.
v2: Rebase and modified the metadata structure elements
as per Ville's POC changes.
v3: No Change
v4: Addressed Shashank's review comments
v5: Rebase.
v6: Addressed Brian Starkey's review comments, defined
new structure with header for dynamic metadata scalability.
Merge get/set property functions for metadata in this patch.
v7: Addressed Jonas Karlman review comments and defined separate
structure for infoframe to better align with CTA 861.G spec. Added
Shashank's RB.
v8: Addressed Ville's review comments. Moved sink metadata structure
out of uapi headers as suggested by Jonas Karlman.
v9: Rebase and addressed Jonas Karlman review comments.
v10: Addressed Ville's review comments, dropped the metdata_changed
state variable as its not needed anymore.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 12
drivers/gpu/drm/drm_connector.c | 6 ++
include/drm/drm_connector.h | 10 ++
include/drm/drm_mode_config.h | 7 +++
include/linux/hdmi.h | 26 ++
include/uapi/drm/drm_mode.h | 23 +++
6 files changed, 84 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4131e66..eb22e8b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -676,6 +676,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
{
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = &dev->mode_config;
+ bool replaced = false;
+ int ret;
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
@@ -726,6 +728,13 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*/
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+ } else if (property == config->hdr_output_metadata_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->hdr_output_metadata,
+ val,
+ sizeof(struct hdr_output_metadata), -1,
+ &replaced);
+ return ret;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
@@ -814,6 +823,9 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+ } else if (property == config->hdr_output_metadata_property) {
+ *val = state->hdr_output_metadata ?
+ state->hdr_output_metadata->base.id : 0;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 11fcd25..c9ac8b9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1051,6 +1051,12 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "HDR_OUTPUT_METADATA", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.hdr_output_metadata_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index e257b87..f8f4003 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -603,6 +603,12 @@ struct drm_connector_state {
* and the connector bpc limitations obtained from edid.
*/
u8 max_bpc;
+
+ /**
+* @hdr_output_metadata:
+* DRM blob property for HDR output metadata
+*/
+ struct drm_property_blob *hdr_output_metadata;
};
/**
@@ -1237,6 +1243,10 @@ struct drm_connector {
* &drm_mode_config.connector_free_work.
*/
struct llist_node free_node;
+
+ /* HDR metdata */
+ struct hdr_output_metadata hdr_output_metadata;
+ struct hdr_sink_metadata hdr_sink_metadata;
};
#define obj_to_connector(x) container_of(x, str
[Intel-gfx] [v11 04/12] drm: Enable HDR infoframe support
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Added the const version of infoframe for DRM metadata
for HDR.
v2: Rebase and added Ville's POC changes.
v3: No Change
v4: Addressed Shashank's review comments and merged the
patch making drm infoframe function arguments as constant.
v5: Rebase
v6: Fixed checkpatch warnings with --strict option. Addressed
Shashank's review comments and added his RB.
v7: Addressed Brian Starkey's review comments. Merged 2 patches
into one.
v8: Addressed Jonas Karlman review comments.
v9: Addressed Jonas Karlman review comments.
v10: Addressed Ville's review comments.
v11: Added BUILD_BUG_ON and sizeof instead of magic numbers as
per Ville's comments.
Signed-off-by: Uma Shankar
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 72 +
drivers/video/hdmi.c | 190 +
include/drm/drm_edid.h | 5 ++
include/linux/hdmi.h | 28 +++
4 files changed, 295 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a5ef9f4..73560c9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4904,6 +4904,78 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
connector->display_info.color_formats &
DRM_COLOR_FORMAT_YCRCB420;
}
+static inline bool is_eotf_supported(u8 output_eotf, u8 sink_eotf)
+{
+ return sink_eotf & BIT(output_eotf);
+}
+
+/**
+ * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI DRM infoframe with
+ * HDR metadata from userspace
+ * @frame: HDMI DRM infoframe
+ * @hdr_metadata: hdr_source_metadata info from userspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
+ const struct drm_connector_state
*conn_state)
+{
+ struct drm_connector *connector;
+ struct hdr_output_metadata *hdr_metadata;
+ int err;
+
+ if (!frame || !conn_state)
+ return -EINVAL;
+
+ connector = conn_state->connector;
+
+ if (!conn_state->hdr_output_metadata)
+ return -EINVAL;
+
+ hdr_metadata = conn_state->hdr_output_metadata->data;
+
+ if (!hdr_metadata || !connector)
+ return -EINVAL;
+
+ /* Sink EOTF is Bit map while infoframe is absolute values */
+ if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
+ connector->hdr_sink_metadata.hdmi_type1.eotf)) {
+ DRM_DEBUG_KMS("EOTF Not Supported\n");
+ return -EINVAL;
+ }
+
+ err = hdmi_drm_infoframe_init(frame);
+ if (err < 0)
+ return err;
+
+ frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
+ frame->metadata_type = hdr_metadata->hdmi_metadata_type1.metadata_type;
+
+ BUILD_BUG_ON(sizeof(frame->display_primaries) !=
+
sizeof(hdr_metadata->hdmi_metadata_type1.display_primaries));
+ BUILD_BUG_ON(sizeof(frame->white_point) !=
+sizeof(hdr_metadata->hdmi_metadata_type1.white_point));
+
+ memcpy(&frame->display_primaries,
+ &hdr_metadata->hdmi_metadata_type1.display_primaries,
+ sizeof(frame->display_primaries));
+
+ memcpy(&frame->white_point,
+ &hdr_metadata->hdmi_metadata_type1.white_point,
+ sizeof(frame->white_point));
+
+ frame->max_display_mastering_luminance =
+
hdr_metadata->hdmi_metadata_type1.max_display_mastering_luminance;
+ frame->min_display_mastering_luminance =
+
hdr_metadata->hdmi_metadata_type1.min_display_mastering_luminance;
+ frame->max_fall = hdr_metadata->hdmi_metadata_type1.max_fall;
+ frame->max_cll = hdr_metadata->hdmi_metadata_type1.max_cll;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
+
/**
* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe with
* data from a DRM display mode
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 799ae49..481f036 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -650,6 +650,150 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
return 0;
}
+/**
+ * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
+ * mastering infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
+{
+ memset(frame, 0, sizeof(*frame));
+
[Intel-gfx] [v11 11/12] video/hdmi: Add Unpack function for DRM infoframe
Added unpack function for DRM infoframe for dynamic
range and mastering infoframe readout.
v2: Addressed Ville's review comments.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/video/hdmi.c | 67
1 file changed, 67 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 481f036..b99ba01 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1805,6 +1805,70 @@ static int hdmi_audio_infoframe_unpack(struct
hdmi_audio_infoframe *frame,
}
/**
+ * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ * @buffer: source buffer
+ * @size: size of buffer
+ *
+ * Unpacks the information contained in binary @buffer into a structured
+ * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
+ * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
+const void *buffer, size_t size)
+{
+ const u8 *ptr = buffer;
+ const u8 *temp;
+ u8 x_lsb, x_msb;
+ u8 y_lsb, y_msb;
+ int ret;
+ int i;
+
+ if (size < HDMI_INFOFRAME_SIZE(DRM))
+ return -EINVAL;
+
+ if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
+ ptr[1] != 1 ||
+ ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
+ return -EINVAL;
+
+ ret = hdmi_drm_infoframe_init(frame);
+ if (ret)
+ return ret;
+
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ frame->eotf = ptr[0] & 0x7;
+ frame->metadata_type = ptr[1] & 0x7;
+
+ temp = ptr + 2;
+ for (i = 0; i < 3; i++) {
+ x_lsb = *temp++;
+ x_msb = *temp++;
+ frame->display_primaries[i].x = (x_msb << 8) | x_lsb;
+ y_lsb = *temp++;
+ y_msb = *temp++;
+ frame->display_primaries[i].y = (y_msb << 8) | y_lsb;
+ }
+
+ frame->white_point.x = (ptr[15] << 8) | ptr[14];
+ frame->white_point.y = (ptr[17] << 8) | ptr[16];
+
+ frame->max_display_mastering_luminance = (ptr[19] << 8) | ptr[18];
+ frame->min_display_mastering_luminance = (ptr[21] << 8) | ptr[20];
+ frame->max_cll = (ptr[23] << 8) | ptr[22];
+ frame->max_fall = (ptr[25] << 8) | ptr[24];
+
+ return 0;
+}
+
+/**
* hdmi_infoframe_unpack() - unpack binary buffer to a HDMI infoframe
* @frame: HDMI infoframe
* @buffer: source buffer
@@ -1830,6 +1894,9 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
case HDMI_INFOFRAME_TYPE_AVI:
ret = hdmi_avi_infoframe_unpack(&frame->avi, buffer, size);
break;
+ case HDMI_INFOFRAME_TYPE_DRM:
+ ret = hdmi_drm_infoframe_unpack(&frame->drm, buffer, size);
+ break;
case HDMI_INFOFRAME_TYPE_SPD:
ret = hdmi_spd_infoframe_unpack(&frame->spd, buffer, size);
break;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 02/12] drm: Add reference counting on HDR metadata blob
From: Jonas Karlman This adds reference count for HDR metadata blob, handled as part of duplicate and destroy connector state functions. v2: Removed the hdr_metadata_changed initialization as the variable is dropped and not required. Signed-off-by: Jonas Karlman Signed-off-by: Uma Shankar --- drivers/gpu/drm/drm_atomic_state_helper.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c index ac929f6..ec13823 100644 --- a/drivers/gpu/drm/drm_atomic_state_helper.c +++ b/drivers/gpu/drm/drm_atomic_state_helper.c @@ -391,6 +391,9 @@ void drm_atomic_helper_connector_reset(struct drm_connector *connector) drm_connector_get(connector); state->commit = NULL; + if (state->hdr_output_metadata) + drm_property_blob_get(state->hdr_output_metadata); + /* Don't copy over a writeback job, they are used only once */ state->writeback_job = NULL; } @@ -438,6 +441,8 @@ struct drm_connector_state * if (state->writeback_job) drm_writeback_cleanup_job(state->writeback_job); + + drm_property_blob_put(state->hdr_output_metadata); } EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 00/12] Add HDR Metadata Parsing and handling in DRM layer
This patch series enables HDR support in drm. It basically defines HDR metadata structures, property to pass content (after blending) metadata from user space compositors to driver. Dynamic Range and Mastering infoframe creation and sending. ToDo: 1. We need to get the color framework in place for all planes which support HDR content in hardware. This is already in progres and patches are out for review in mailing list. 2. UserSpace/Compositors: Blending policies and metadata blob creation and passing to driver. Work is already in progress by Intel's middleware teams on wayland and the patches for the same are in review. A POC has already been developed by Ville based on wayland. Please refer below link to see the component interactions and usage: https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html v2: Updated Ville's POC changes to the patch series.Incorporated cleanups and fixes from Ville. Rebase on latest drm-tip. v3: Fixed a warning causing builds to break on CI. No major change. v4: Addressed Shashank's review comments. v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non modeset case for HDR metadata update. Dropped a redundant patch. v6: Addressed Shashank's review comments and added RB's received. v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's and Shashank's review comments. v8: Addressed Jonas Karlman review comments. Added Shashank's RB to the series, fixed a WARN_ON on BYT/CHT. v9: Addressed Ville and Jonas Karlman's review comments. Added the infoframe state readout and metadata reference count. v10: Addressed review comments from Jonas and Ville. Dropped one patch related to i915 fastset handling as per Ville's feedback. v11: Addressed Ville's review comments. Note: v9 version is already tested with Kodi and a confirmation from team kodi has been received. Branch details for the same as below: https://github.com/xbmc/xbmc/tree/feature_drmprime-vaapi v9 of this series is: Tested-by: Jonas Karlman Jonas Karlman (1): drm: Add reference counting on HDR metadata blob Uma Shankar (9): drm: Add HDR source metadata property drm: Parse HDR metadata info from EDID drm: Enable HDR infoframe support drm/i915: Attach HDR metadata property to connector drm/i915: Write HDR infoframe and send to panel drm/i915:Enabled Modeset when HDR Infoframe changes drm/i915: Added DRM Infoframe handling for BYT/CHT video/hdmi: Add Unpack function for DRM infoframe drm/i915: Add state readout for DRM infoframe Ville Syrjälä (2): drm: Add HLG EOTF drm/i915: Enable infoframes on GLK+ for HDR drivers/gpu/drm/drm_atomic_state_helper.c | 5 + drivers/gpu/drm/drm_atomic_uapi.c | 12 ++ drivers/gpu/drm/drm_connector.c | 6 + drivers/gpu/drm/drm_edid.c| 124 ++ drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_atomic.c | 14 +- drivers/gpu/drm/i915/intel_ddi.c | 3 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 67 +++- drivers/video/hdmi.c | 257 ++ include/drm/drm_connector.h | 10 ++ include/drm/drm_edid.h| 5 + include/drm/drm_mode_config.h | 7 + include/linux/hdmi.h | 55 +++ include/uapi/drm/drm_mode.h | 23 +++ 16 files changed, 589 insertions(+), 5 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 03/12] drm: Parse HDR metadata info from EDID
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
v5: Addressed Shashank's comment and added his RB.
v6: Addressed Jonas Karlman review comments.
v7: Adressed Ville's review comments and fixed the issue
with length handling.
v8: Put the length check as per the convention followed in
existing code, as suggested by Ville.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 51 ++
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 852bdd8..a5ef9f4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2852,6 +2852,7 @@ static int drm_cvt_modes(struct drm_connector *connector,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
#define EXT_VIDEO_DATA_BLOCK_420 0x0E
@@ -3834,6 +3835,54 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) < 3)
+ return false;
+
+ return true;
+}
+
+static uint8_t eotf_supported(const u8 *edid_ext)
+{
+ return edid_ext[2] &
+ (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
+BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+BIT(HDMI_EOTF_SMPTE_ST2084));
+}
+
+static uint8_t hdr_metadata_type(const u8 *edid_ext)
+{
+ return edid_ext[3] &
+ BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
+{
+ u16 len;
+
+ len = cea_db_payload_len(db);
+
+ connector->hdr_sink_metadata.hdmi_type1.eotf =
+ eotf_supported(db);
+ connector->hdr_sink_metadata.hdmi_type1.metadata_type =
+ hdr_metadata_type(db);
+
+ if (len >= 4)
+ connector->hdr_sink_metadata.hdmi_type1.max_cll = db[4];
+ if (len >= 5)
+ connector->hdr_sink_metadata.hdmi_type1.max_fall = db[5];
+ if (len >= 6)
+ connector->hdr_sink_metadata.hdmi_type1.min_cll = db[6];
+}
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
{
@@ -4461,6 +4510,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_vcdb(db))
drm_parse_vcdb(connector, db);
+ if (cea_db_is_hdmi_hdr_metadata_block(db))
+ drm_parse_hdr_metadata_block(connector, db);
}
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 10/12] drm/i915: Added DRM Infoframe handling for BYT/CHT
BYT/CHT doesn't support DRM Infoframe. This caused a WARN_ON due to a missing CASE while executing intel_hdmi_infoframes_enabled function. This patch fixes the same. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 8bd7c07..90e0587 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -129,6 +129,8 @@ static u32 g4x_infoframe_enable(unsigned int type) return VIDEO_DIP_ENABLE_SPD; case HDMI_INFOFRAME_TYPE_VENDOR: return VIDEO_DIP_ENABLE_VENDOR; + case HDMI_INFOFRAME_TYPE_DRM: + return 0; default: MISSING_CASE(type); return 0; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 08/12] drm/i915: Enable infoframes on GLK+ for HDR
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
v3: Addressed Shashank's review comment.
v4: Added Shashank's RB.
v5: Dropped hdr_metadata_change check while modeset, as per
Ville's suggestion.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47f..d3f5510 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4694,6 +4694,7 @@ enum {
#define VIDEO_DIP_FREQ_MASK (3 << 16)
/* HSW and later: */
#define DRM_DIP_ENABLE (1 << 28)
+#define VIDEO_DIP_ENABLE_DRM_GLK (1 << 28)
#define PSR_VSC_BIT_7_SET(1 << 27)
#define VSC_SELECT_MASK (0x3 << 25)
#define VSC_SELECT_SHIFT 25
@@ -8146,6 +8147,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_A 0x602A0
#define _HSW_VIDEO_DIP_GMP_DATA_A 0x602E0
#define _HSW_VIDEO_DIP_VSC_DATA_A 0x60320
+#define _GLK_VIDEO_DIP_DRM_DATA_A 0x60440
#define _HSW_VIDEO_DIP_AVI_ECC_A 0x60240
#define _HSW_VIDEO_DIP_VS_ECC_A0x60280
#define _HSW_VIDEO_DIP_SPD_ECC_A 0x602C0
@@ -8159,6 +8161,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_B 0x612A0
#define _HSW_VIDEO_DIP_GMP_DATA_B 0x612E0
#define _HSW_VIDEO_DIP_VSC_DATA_B 0x61320
+#define _GLK_VIDEO_DIP_DRM_DATA_B 0x61440
#define _HSW_VIDEO_DIP_BVI_ECC_B 0x61240
#define _HSW_VIDEO_DIP_VS_ECC_B0x61280
#define _HSW_VIDEO_DIP_SPD_ECC_B 0x612C0
@@ -8184,6 +8187,7 @@ enum {
#define HSW_TVIDEO_DIP_SPD_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_GMP_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_VSC_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans,
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_DATA(trans, i) _MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_ECC(trans, i)_MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index d3b8e09..8bd7c07 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -152,6 +152,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_SPD_HSW;
case HDMI_INFOFRAME_TYPE_VENDOR:
return VIDEO_DIP_ENABLE_VS_HSW;
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return VIDEO_DIP_ENABLE_DRM_GLK;
default:
MISSING_CASE(type);
return 0;
@@ -177,6 +179,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_VENDOR:
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return GLK_TVIDEO_DIP_DRM_DATA(cpu_transcoder, i);
default:
MISSING_CASE(type);
return INVALID_MMIO_REG;
@@ -560,10 +564,16 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 val = I915_READ(HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
+ u32 mask;
- return val & (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
- VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
- VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+ mask = (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
+ VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
+ VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ mask |= VIDEO_DIP_ENABLE_DRM_GLK;
+
+ return val & mask;
}
static const u8 infoframe_type_to_idx[] = {
@@ -1193,7 +1203,8 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
-VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+VIDEO_DIP_ENABLE_DRM_GLK);
if (!enable) {
I915_WRITE(reg, val);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
htt
[Intel-gfx] [v11 12/12] drm/i915: Add state readout for DRM infoframe
Added state readout for DRM infoframe and enabled state validation for DRM infoframe. v2: Addressed Ville's review comments and dropped the unused drm infoframe read at intel_hdmi_init. v3: Removed a redundant platform check as per Ville's comment. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_ddi.c | 3 +++ drivers/gpu/drm/i915/intel_display.c | 1 + 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 0af47f3..c789de9 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -3834,6 +3834,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder, intel_read_infoframe(encoder, pipe_config, HDMI_INFOFRAME_TYPE_VENDOR, &pipe_config->infoframes.hdmi); + intel_read_infoframe(encoder, pipe_config, +HDMI_INFOFRAME_TYPE_DRM, +&pipe_config->infoframes.drm); } static enum intel_output_type diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e35ba8d..c89b214 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12274,6 +12274,7 @@ static bool fastboot_enabled(struct drm_i915_private *dev_priv) PIPE_CONF_CHECK_INFOFRAME(avi); PIPE_CONF_CHECK_INFOFRAME(spd); PIPE_CONF_CHECK_INFOFRAME(hdmi); + PIPE_CONF_CHECK_INFOFRAME(drm); #undef PIPE_CONF_CHECK_X #undef PIPE_CONF_CHECK_I -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 09/12] drm/i915:Enabled Modeset when HDR Infoframe changes
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
v3: Added Shashank's RB.
v4: Addressed Ville's review comments.
v5: Addressed Ville's review comments.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 58b8049..6b985e8 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -105,6 +105,16 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
return -EINVAL;
}
+static bool blob_equal(const struct drm_property_blob *a,
+ const struct drm_property_blob *b)
+{
+ if (a && b)
+ return a->length == b->length &&
+ !memcmp(a->data, b->data, a->length);
+
+ return !a == !b;
+}
+
int intel_digital_connector_atomic_check(struct drm_connector *conn,
struct drm_connector_state *new_state)
{
@@ -132,7 +142,9 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
- new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
+ new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode ||
+ !blob_equal(new_conn_state->base.hdr_output_metadata,
+ old_conn_state->base.hdr_output_metadata))
crtc_state->mode_changed = true;
return 0;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 05/12] drm/i915: Attach HDR metadata property to connector
Attach HDR metadata property to connector object. v2: Rebase v3: Updated the property name as per updated name while creating hdr metadata property Signed-off-by: Uma Shankar Reviewed-by: Shashank Sharma --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 2a4086c..92597d8 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2724,6 +2724,8 @@ static void intel_hdmi_destroy(struct drm_connector *connector) drm_connector_attach_content_type_property(connector); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; + drm_object_attach_property(&connector->base, + connector->dev->mode_config.hdr_output_metadata_property, 0); if (!HAS_GMCH(dev_priv)) drm_connector_attach_max_bpc_property(connector, 8, 12); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v11 07/12] drm: Add HLG EOTF
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a logarithmic curve.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Addressed Jonas Karlman's review comment and dropped the i915
tag from header.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 3 ++-
include/linux/hdmi.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 73560c9..262510c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3854,7 +3854,8 @@ static uint8_t eotf_supported(const u8 *edid_ext)
return edid_ext[2] &
(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
-BIT(HDMI_EOTF_SMPTE_ST2084));
+BIT(HDMI_EOTF_SMPTE_ST2084) |
+BIT(HDMI_EOTF_BT_2100_HLG));
}
static uint8_t hdr_metadata_type(const u8 *edid_ext)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index bcf3c6c..ee55ba5 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -162,6 +162,7 @@ enum hdmi_eotf {
HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
HDMI_EOTF_SMPTE_ST2084,
+ HDMI_EOTF_BT_2100_HLG,
};
struct hdmi_avi_infoframe {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 08/11] drm/fb-helper: Remove drm_fb_helper_connector
Den 16.05.2019 15.07, skrev Sam Ravnborg:
> Hi Noralf.
>
> See few comments in the following.
>
> Sam
>
> On Mon, May 06, 2019 at 08:01:36PM +0200, Noralf Trønnes wrote:
>> All drivers add all their connectors so there's no need to keep around an
>> array of available connectors.
I could expand on this text a little:
All drivers add all their connectors so there's no need to keep around an
array of available connectors. Instead we just put the useable (not
writeback) connectors in a temporary array using
drm_client_for_each_connector_iter() everytime we probe the outputs.
Other places where it's necessary to look at the connectors, we just
iterate over them using the same iterator function.
>>
>> Rename functions which signature is changed since they will be moved to
>> drm_client in a later patch.
>>
>> Signed-off-by: Noralf Trønnes
>> ---
>> @@ -1645,8 +1461,9 @@ static int drm_fb_helper_single_fb_probe(struct
>> drm_fb_helper *fb_helper,
>> struct drm_client_dev *client = &fb_helper->client;
>> int ret = 0;
>> int crtc_count = 0;
>> -int i;
>> +struct drm_connector_list_iter conn_iter;
>> struct drm_fb_helper_surface_size sizes;
>> +struct drm_connector *connector;
>> struct drm_mode_set *mode_set;
>> int best_depth = 0;
>>
>> @@ -1663,11 +1480,11 @@ static int drm_fb_helper_single_fb_probe(struct
>> drm_fb_helper *fb_helper,
>> if (preferred_bpp != sizes.surface_bpp)
>> sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
>>
>> -drm_fb_helper_for_each_connector(fb_helper, i) {
>> -struct drm_fb_helper_connector *fb_helper_conn =
>> fb_helper->connector_info[i];
>> +drm_connector_list_iter_begin(fb_helper->dev, &conn_iter);
>> +drm_client_for_each_connector_iter(connector, &conn_iter) {
>> struct drm_cmdline_mode *cmdline_mode;
>
> I fail to see when to use drm_client_for_each_connector_iter() and when
> to use a simple for loop.
> In this patch drm_fb_helper_for_each_connector() is here replaced by the
> iterator variant and in many other placed a simple for loop.
>
When I use a for loop it's in the 'probe for outputs' path where we are
operating on a temporary connector array that is created in
drm_setup_crtcs().
> The old code, in this place, would go through all connectors, but this
> code will skipDRM_MODE_CONNECTOR_WRITEBACK conectors.
> So it does not like identical code.
>
If you look at the removed drm_fb_helper_single_add_all_connectors()
you'll see that it skips writeback connectors.
>>
>> -cmdline_mode = &fb_helper_conn->connector->cmdline_mode;
>> +cmdline_mode = &connector->cmdline_mode;
>>
>> if (cmdline_mode->bpp_specified) {
>> switch (cmdline_mode->bpp) {
>> @@ -1692,6 +1509,7 @@ static int drm_fb_helper_single_fb_probe(struct
>> drm_fb_helper *fb_helper,
>> break;
>> }
>> }
>> +drm_connector_list_iter_end(&conn_iter);
>>
>> /*
>> * If we run into a situation where, for example, the primary plane
>> @@ -1876,26 +1694,12 @@ void drm_fb_helper_fill_info(struct fb_info *info,
>> }
>> EXPORT_SYMBOL(drm_fb_helper_fill_info);
>>
>> +static void drm_client_connectors_enabled(struct drm_connector **connectors,
>> + unsigned int connector_count,
>> + bool *enabled)
>> {
>> bool any_enabled = false;
>> struct drm_connector *connector;
>> int i = 0;
>>
>> -drm_fb_helper_for_each_connector(fb_helper, i) {
>> -connector = fb_helper->connector_info[i]->connector;
>> +for (i = 0; i < connector_count; i++) {
>> +connector = connectors[i];
> This is for example a place where the drm_fb_helper_for_each_connector()
> is replaced by a simple for loop.
Yeah, this is downstream from drm_setup_crtcs() and we're operating on
the temporary 'connectors' array.
> The simple for loop is nice and readable - just a comment replated to
> the above comment.
>
>> struct drm_display_mode *mode = modes[i];
>> struct drm_crtc *crtc = crtcs[i];
>> struct drm_fb_offset *offset = &offsets[i];
>>
>> if (mode && crtc) {
>> struct drm_mode_set *modeset =
>> drm_client_find_modeset(client, crtc);
>> -struct drm_connector *connector =
>> -fb_helper->connector_info[i]->connector;
>> +struct drm_connector *connector = connectors[i];
>>
>> DRM_DEBUG_KMS("desired mode %s set on crtc %d
>> (%d,%d)\n",
>>mode->name, crtc->base.id, offset->x,
>> offset->y);
>> @@ -2539,6 +2354,10 @@ static void drm_setup_crtcs(struct drm_fb_helper
>> *fb_helper,
>> kfree(modes);
>> kfree(offsets);
>> kfree(enabled);
>> +free_connectors:
>> +for (i = 0
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10)
On 16/05/2019 16:18, Shankar, Uma wrote: > > >>> -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Thursday, May 16, 2019 1:02 AM To: Shankar, Uma Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10) On Wed, May 15, 2019 at 08:59:37AM +, Shankar, Uma wrote: > > >> -Original Message- >> From: Patchwork [mailto:patchw...@emeril.freedesktop.org] >> Sent: Wednesday, May 15, 2019 6:54 AM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org >> Subject: ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and >> handling in DRM layer >> (rev10) >> >> == Series Details == >> >> Series: Add HDR Metadata Parsing and handling in DRM layer (rev10) >> URL : https://patchwork.freedesktop.org/series/25091/ >> State : failure >> >> == Summary == >> >> CI Bug Log - changes from CI_DRM_6081_full -> Patchwork_13017_full >> >> >> Summary >> --- >> >> **FAILURE** >> >> Serious unknown changes coming with Patchwork_13017_full >> absolutely need to be verified manually. >> >> If you think the reported changes have nothing to do with the >> changes introduced in Patchwork_13017_full, please notify your >> bug team to allow them to document this new failure mode, which >> will reduce false positives in CI. >> >> >> >> Possible new issues >> --- >> >> Here are the unknown changes that may have been introduced in >> Patchwork_13017_full: >> >> ### IGT changes ### >> >> Possible regressions >> >> * igt@gem_exec_suspend@basic-s3: >>- shard-iclb: [PASS][1] -> [SKIP][2] +43 similar issues >> [1]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard- >> iclb6/igt@gem_exec_susp...@basic-s3.html >> [2]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard- >> iclb5/igt@gem_exec_susp...@basic-s3.html >> >> * igt@kms_prop_blob@invalid-set-prop-any: >>- shard-iclb: [PASS][3] -> [FAIL][4] >> [3]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard- >> iclb6/igt@kms_prop_b...@invalid-set-prop-any.html >> [4]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard- >> iclb5/igt@kms_prop_b...@invalid-set-prop-any.html >> > > Hi Martin, > These issues are unrelated to the changes made in this series. Can > you please have a look and confirm. The kms_prop fails at least are real. Probably due to the bogus function arguements to the replace_blob() thing I pointed out. >>> >>> The CI IGT have a clean PASS now. >> >> You mean it went from FAIL to PASS on its own? Why did that happen? > > It was giving a PASS on earlier version v9 with same changes. But on v10 it > gave > this error. I was thinking it was re-run, on checking with Jani N he > clarified that it > was re-reported. Yeah, I re-report some runs after being told they contain noise :) > >>> Will anyways update the function arguments and make it consistent. >>> >>> Regards, >>> Uma Shankar >>> -- Ville Syrjälä Intel >> >> -- >> Ville Syrjälä >> Intel - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam
On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote: > On Tue, 14 May 2019, Rodrigo Vivi wrote: > > One possibility that just came to my mind now is, what if we make > > this only for platforms that are still protected by > > is_alpha_support=1 > > (soon becoming require_force_probe=1) > > Please don't conflate alpha_support or force_probe with *anything* > else. > > > But this is just one side of the coin... when product is out there > > and we want the user to debug the issue to see if it is a RC6 bug > > we have no way to verify that. :/ > > The problem is, if it works with rc6 disabled, it doesn't prove it's > an > rc6 bug either. Good point. I'm not saying we should enforce a process of disabling RC6 for the platform if enable_rc6=0 results in success. I'm just saying having the option is useful from a debug perspective. We will still need to do the appropriate full analysis, including the normal code review process on a pre-case basis when debug involves this parameter. But the parameter itself is still useful. Thanks, Stuart > > > BR, > Jani. > > smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add HDR Metadata Parsing and handling in DRM layer (rev11)
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev11)
URL : https://patchwork.freedesktop.org/series/25091/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c372f3162e09 drm: Add HDR source metadata property
-:62: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#62: FILE: drivers/gpu/drm/drm_atomic_uapi.c:733:
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->hdr_output_metadata,
total: 0 errors, 0 warnings, 1 checks, 144 lines checked
4d08742fedee drm: Add reference counting on HDR metadata blob
b95d51f65c44 drm: Parse HDR metadata info from EDID
736754715323 drm: Enable HDR infoframe support
-:92: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#92: FILE: drivers/gpu/drm/drm_edid.c:4943:
+ if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
+ connector->hdr_sink_metadata.hdmi_type1.eotf)) {
total: 0 errors, 0 warnings, 1 checks, 379 lines checked
495dfdf065ff drm/i915: Attach HDR metadata property to connector
77b052459da8 drm/i915: Write HDR infoframe and send to panel
538cf737007c drm: Add HLG EOTF
d8c1195d31eb drm/i915: Enable infoframes on GLK+ for HDR
-:57: WARNING:LONG_LINE: line over 100 characters
#57: FILE: drivers/gpu/drm/i915/i915_reg.h:8190:
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans,
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
total: 0 errors, 1 warnings, 0 checks, 72 lines checked
f3797bbcf507 drm/i915:Enabled Modeset when HDR Infoframe changes
d74cf996f1e0 drm/i915: Added DRM Infoframe handling for BYT/CHT
dcd93072f636 video/hdmi: Add Unpack function for DRM infoframe
b7ccb67c3091 drm/i915: Add state readout for DRM infoframe
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
On Thu, May 16, 2019 at 03:00:01PM +0300, Laurent Pinchart wrote:
> Hi Sean,
>
> On Mon, May 13, 2019 at 10:38:58AM -0400, Sean Paul wrote:
> > On Sat, May 11, 2019 at 3:12 PM Laurent Pinchart wrote:
> > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> > >> From: Sean Paul
> > >>
> > >> Everyone who implements connector_helper_funcs->atomic_check reaches
> > >> into the connector state to get the atomic state. Instead of continuing
> > >> this pattern, change the callback signature to just give atomic state
> > >> and let the driver determine what it does and does not need from it.
> > >>
> > >> Eventually all atomic functions should do this, but that's just too much
> > >> busy work for me.
> > >
> > > Given that drivers also access the connector state, isn't this slightly
> > > more inefficient ?
> >
> > Inefficient in terms of what?
>
> In terms of the operation having to lookup the connector state, when the
> caller has it and can easily pass it. As Daniel commented, this may be
> the price to pay for a cleaner API, but I wonder how much overhead all
> the state tracking is costing.
>
It'd be interesting to quantify, but iirc the last time we benchmarked
atomic check commits they were virtually free (~thousands/s).
> > Agree that in isolation this patch might seem unnecessary, but it ties
> > in with the encoder and bridge CLs which accept drm_atomic_state in
>
> CLs ?
Googleism for patches, I usually catch these before sending... guess I missed
one.
Sean
>
> > their hooks. In general the idea is to convert all atomic functions to
> > take overall atomic state instead of just their object state. Reality
> > has proven to be more complicated and we need more access than what
> > the current implementation provides.
> >
> > Sean
> >
> > >> Changes in v3:
> > >> - Added to the set
> > >>
> > >> Cc: Daniel Vetter
> > >> Cc: Ville Syrjälä
> > >> Cc: Jani Nikula
> > >> Cc: Joonas Lahtinen
> > >> Cc: Rodrigo Vivi
> > >> Cc: Ben Skeggs
> > >> Cc: Laurent Pinchart
> > >> Cc: Kieran Bingham
> > >> Cc: Eric Anholt
> > >> Signed-off-by: Sean Paul
> > >> ---
> > >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> > >> drivers/gpu/drm/i915/intel_atomic.c | 8 +---
> > >> drivers/gpu/drm/i915/intel_dp_mst.c | 7 ---
> > >> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> > >> drivers/gpu/drm/i915/intel_sdvo.c| 9 +
> > >> drivers/gpu/drm/i915/intel_tv.c | 8 +---
> > >> drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
> > >> drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++-
> > >> drivers/gpu/drm/vc4/vc4_txp.c| 7 ---
> > >> include/drm/drm_modeset_helper_vtables.h | 2 +-
> > >> 10 files changed, 37 insertions(+), 27 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > >> b/drivers/gpu/drm/drm_atomic_helper.c
> > >> index 9d9e47276839..fa5a367507c1 100644
> > >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> > >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > >> @@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device
> > >> *dev,
> > >> }
> > >>
> > >> if (funcs->atomic_check)
> > >> - ret = funcs->atomic_check(connector,
> > >> new_connector_state);
> > >> + ret = funcs->atomic_check(connector, state);
> > >> if (ret)
> > >> return ret;
> > >>
> > >> @@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device
> > >> *dev,
> > >> continue;
> > >>
> > >> if (funcs->atomic_check)
> > >> - ret = funcs->atomic_check(connector,
> > >> new_connector_state);
> > >> + ret = funcs->atomic_check(connector, state);
> > >> if (ret)
> > >> return ret;
> > >> }
> > >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > >> b/drivers/gpu/drm/i915/intel_atomic.c
> > >> index b844e8840c6f..e8a5b82e9242 100644
> > >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> > >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > >> @@ -103,12 +103,14 @@ int
> > >> intel_digital_connector_atomic_set_property(struct drm_connector
> > >> *connector,
> > >> }
> > >>
> > >> int intel_digital_connector_atomic_check(struct drm_connector *conn,
> > >> - struct drm_connector_state
> > >> *new_state)
> > >> + struct drm_atomic_state *state)
> > >> {
> > >> + struct drm_connector_state *new_state =
> > >> + drm_atomic_get_new_connector_state(state, conn);
> > >> struct intel_digital_connector_state *new_conn_state =
> > >> to_intel_digital_connector_state(new_state);
> > >> struct drm_connector_state *old_state =
> > >> - drm_atomic_get_old_connector_state(new_state->state, conn);
> > >> + drm_atomic_get_old_connector_stat
[Intel-gfx] ✓ Fi.CI.BAT: success for Add HDR Metadata Parsing and handling in DRM layer (rev11)
== Series Details ==
Series: Add HDR Metadata Parsing and handling in DRM layer (rev11)
URL : https://patchwork.freedesktop.org/series/25091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6090 -> Patchwork_13025
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/
Known issues
Here are the changes found in Patchwork_13025 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][1] ([fdo#110235]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-y}: [INCOMPLETE][3] ([fdo#107713] / [fdo#108569]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/fi-icl-y/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (50 -> 44)
--
Additional (3): fi-icl-dsi fi-ivb-3770 fi-apl-guc
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-skl-guc
fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6090 -> Patchwork_13025
CI_DRM_6090: df27ebbc9ec0d8ae42e8cf3d7a3b29fd6baf4940 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4992: 0d488fae6d35c222c8a527c9fb85614800ead646 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13025: b7ccb67c3091f1658e0c3467a535257fd19761c0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b7ccb67c3091 drm/i915: Add state readout for DRM infoframe
dcd93072f636 video/hdmi: Add Unpack function for DRM infoframe
d74cf996f1e0 drm/i915: Added DRM Infoframe handling for BYT/CHT
f3797bbcf507 drm/i915:Enabled Modeset when HDR Infoframe changes
d8c1195d31eb drm/i915: Enable infoframes on GLK+ for HDR
538cf737007c drm: Add HLG EOTF
77b052459da8 drm/i915: Write HDR infoframe and send to panel
495dfdf065ff drm/i915: Attach HDR metadata property to connector
736754715323 drm: Enable HDR infoframe support
b95d51f65c44 drm: Parse HDR metadata info from EDID
4d08742fedee drm: Add reference counting on HDR metadata blob
c372f3162e09 drm: Add HDR source metadata property
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 08/11] drm/fb-helper: Remove drm_fb_helper_connector
Hi Noralf. On Thu, May 16, 2019 at 03:53:07PM +0200, Noralf Trønnes wrote: > > > Den 16.05.2019 15.07, skrev Sam Ravnborg: > > Hi Noralf. > > > > See few comments in the following. > > > > Sam > > > > On Mon, May 06, 2019 at 08:01:36PM +0200, Noralf Trønnes wrote: > >> All drivers add all their connectors so there's no need to keep around an > >> array of available connectors. > > I could expand on this text a little: > > All drivers add all their connectors so there's no need to keep around an > array of available connectors. Instead we just put the useable (not > writeback) connectors in a temporary array using > drm_client_for_each_connector_iter() everytime we probe the outputs. > Other places where it's necessary to look at the connectors, we just > iterate over them using the same iterator function. Better, thanks. After you clarified things looks good to me and you can add my: Reviewed-by: Sam Ravnborg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 10/11] drm/fb-helper: Move out modeset config code
Hi Noralf. After clarifying patch 8 this looks good (moved code touched n patch 8). So I consider this: Reviewed-by: Sam Ravnborg ___ 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: Re-add enable_rc6 modparam
On Thu, 16 May 2019, "Summers, Stuart" wrote: > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote: >> On Tue, 14 May 2019, Rodrigo Vivi wrote: >> > One possibility that just came to my mind now is, what if we make >> > this only for platforms that are still protected by >> > is_alpha_support=1 >> > (soon becoming require_force_probe=1) >> >> Please don't conflate alpha_support or force_probe with *anything* >> else. >> >> > But this is just one side of the coin... when product is out there >> > and we want the user to debug the issue to see if it is a RC6 bug >> > we have no way to verify that. :/ >> >> The problem is, if it works with rc6 disabled, it doesn't prove it's >> an >> rc6 bug either. > > Good point. I'm not saying we should enforce a process of disabling RC6 > for the platform if enable_rc6=0 results in success. I'm just saying > having the option is useful from a debug perspective. We will still > need to do the appropriate full analysis, including the normal code > review process on a pre-case basis when debug involves this parameter. > But the parameter itself is still useful. The trouble starts when users figure out that enable_rc6=0 works around a particular problem they have (likely by way of disabling runtime pm, not directly related to rc6). You could argue this is a good thing, but unfortunately we generally never hear from them again, and the root cause remains unsolved, with degraded user experience wrt power management. 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 v5 00/11] drm/fb-helper: Move modesetting code to drm_client
Hi Noralf. > > drm/fb-helper: Remove drm_fb_helper_crtc > > drm/fb-helper: Prepare to move out commit code > > drm/fb-helper: Move out commit code > > drm/fb-helper: Remove drm_fb_helper_connector > > Patches 5-8 are still in need of review... With the improved changelogs the remaining patches are all good to go as far as I am concerned. (Not the bootsplash hack - but thats kind of obvious) Nice series! Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs
On Thu, 16 May 2019, Ville Syrjälä wrote:
> On Thu, May 16, 2019 at 03:55:25PM +0300, Jani Nikula wrote:
>> On Thu, 16 May 2019, Maarten Lankhorst
>> wrote:
>> > Op 16-05-2019 om 07:58 schreef Harish Chegondi:
>> >> display_pipe_crc_irq_handler() skips the first CRC for all GPUs and the
>> >> second CRC for GEN8+ GPUs. The second CRC is invalid even for BYT which
>> >> is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
>> >>
>> >> Cc: Jani Nikula
>> >> Cc: Tomi Sarvela
>> >> Cc: Petri Latvala
>> >> Cc: Ville Syrjälä
>> >> Cc: Maarten Lankhorst
>> >> Signed-off-by: Harish Chegondi
>> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
>> >> ---
>> >> drivers/gpu/drm/i915/i915_irq.c | 4 ++--
>> >> 1 file changed, 2 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> >> b/drivers/gpu/drm/i915/i915_irq.c
>> >> index 233211fde0ea..3809e9f7fae2 100644
>> >> --- a/drivers/gpu/drm/i915/i915_irq.c
>> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> >> @@ -1775,11 +1775,11 @@ static void display_pipe_crc_irq_handler(struct
>> >> drm_i915_private *dev_priv,
>> >>* bonkers. So let's just wait for the next vblank and read
>> >>* out the buggy result.
>> >>*
>> >> - * On GEN8+ sometimes the second CRC is bonkers as well, so
>> >> + * On GEN7+ sometimes the second CRC is bonkers as well, so
>> >>* don't trust that one either.
>> >>*/
>> >> if (pipe_crc->skipped <= 0 ||
>> >> - (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
>> >> + (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped == 1)) {
>> >> pipe_crc->skipped++;
>> >> spin_unlock(&pipe_crc->lock);
>> >> return;
>> >
>> > I would be interested in the results, haswell is different from
>> > VLV. Has it ever been observed on that platform?
>>
>> Good point. I looked at [1] which I presumed was on VLV, but it says
>> nothing about HSW.
>
> This whole thing is just a pile of duct tape anyway. The reason(s)
> for these funky crcs has never been properly analysed.
I don't disagree. And this is partially why I was so eager to ack the
patch at hand. Another strip of duct tape does no harm when you already
have so much, and we can't hold this particular issue hostage to root
cause the issues.
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 1/2] drm/i915: Re-add enable_rc6 modparam
On Thu, 2019-05-16 at 18:42 +0300, Jani Nikula wrote: > On Thu, 16 May 2019, "Summers, Stuart" > wrote: > > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote: > > > On Tue, 14 May 2019, Rodrigo Vivi wrote: > > > > One possibility that just came to my mind now is, what if we > > > > make > > > > this only for platforms that are still protected by > > > > is_alpha_support=1 > > > > (soon becoming require_force_probe=1) > > > > > > Please don't conflate alpha_support or force_probe with > > > *anything* > > > else. > > > > > > > But this is just one side of the coin... when product is out > > > > there > > > > and we want the user to debug the issue to see if it is a RC6 > > > > bug > > > > we have no way to verify that. :/ > > > > > > The problem is, if it works with rc6 disabled, it doesn't prove > > > it's > > > an > > > rc6 bug either. > > > > Good point. I'm not saying we should enforce a process of disabling > > RC6 > > for the platform if enable_rc6=0 results in success. I'm just > > saying > > having the option is useful from a debug perspective. We will still > > need to do the appropriate full analysis, including the normal code > > review process on a pre-case basis when debug involves this > > parameter. > > But the parameter itself is still useful. > > The trouble starts when users figure out that enable_rc6=0 works > around > a particular problem they have (likely by way of disabling runtime > pm, > not directly related to rc6). You could argue this is a good thing, > but > unfortunately we generally never hear from them again, and the root > cause remains unsolved, with degraded user experience wrt power > management. So I understand the reasoning here, and agree that isn't an ideal situation. I'd also like a way to debug more efficiently. What did you think about the suggestion from Tvrtko to only apply on CONFIG_DRM_I915_DEBUG? Or we could even wrap this entirely with a CONFIG_I915_DEBUG_PM - although I'd like to suggest we still use the module parameter, we could just use the config option to hide the modparam under normal operation. Thanks, Stuart > > BR, > Jani. > > smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 8/8] drm/i915: Bump gen7+ fb size limits to 16kx16k
Op 09-05-2019 om 14:21 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> With gtt remapping in place we can use arbitrarily large
> framebuffers. Let's bump the limits to 16kx16k on gen7+.
> The limit was chosen to match the maximum 2D surface size
> of the 3D engine.
>
> With the remapping we could easily go higher than that for the
> display engine. However the modesetting ddx will blindly assume
> it can handle whatever is reported via kms. The oversized
> buffer dimensions are not caught by glamor nor Mesa until
> finally an assert will trip when genxml attempts to pack the
> SURFACE_STATE. So we pick a safe limit to avoid the X server
> from crashing (or potentially misbehaving if the genxml asserts
> are compiled out).
>
> Reviewed-by: Daniel Vetter
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110187
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a2e4ef938d53..a495fd2dcaa3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15783,16 +15783,22 @@ int intel_modeset_init(struct drm_device *dev)
> }
> }
>
> - /* maximum framebuffer dimensions */
> - if (IS_GEN(dev_priv, 2)) {
> - dev->mode_config.max_width = 2048;
> - dev->mode_config.max_height = 2048;
> + /*
> + * Maximum framebuffer dimensions, chosen to match
> + * the maximum render engine surface size on gen4+.
> + */
> + if (INTEL_GEN(dev_priv) >= 7) {
> + dev->mode_config.max_width = 16384;
> + dev->mode_config.max_height = 16384;
> + } else if (INTEL_GEN(dev_priv) >= 4) {
> + dev->mode_config.max_width = 8192;
> + dev->mode_config.max_height = 8192;
> } else if (IS_GEN(dev_priv, 3)) {
> dev->mode_config.max_width = 4096;
> dev->mode_config.max_height = 4096;
> } else {
> - dev->mode_config.max_width = 8192;
> - dev->mode_config.max_height = 8192;
> + dev->mode_config.max_width = 2048;
> + dev->mode_config.max_height = 2048;
> }
>
> if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
Should be good enough, lets not go too crazy. :)
For whole series:
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
This reverts commit 99b69db57544ec7ed427607f1a2a1858a7d43b61
Core-for-CI:ICL_only Disable ACPI idle driver.
This hack has been provided considering the Bug assessment
that ACPI idle driver page fault causes below bug.
FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
But this bug is still reproducible after disabling ACPI idle driver.
It looks "rcu_preempt self-detected stall on CPU" causes to
hung kworker and followed by panic resulted this bug.
Hence it make sense to revert this patch.
Cc: martin.pe...@intel.com
Cc: daniel.vet...@intel.com
Cc: ville.syrj...@intel.com
Signed-off-by: Anshuman Gupta
---
drivers/acpi/processor_driver.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index ee842a2f..9d6aff2 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -35,12 +35,6 @@
#include
-/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
-#ifdef CONFIG_X86
-#include
-#include
-#endif
-
#include "internal.h"
#define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
@@ -64,13 +58,6 @@ static const struct acpi_device_id processor_device_ids[] = {
};
MODULE_DEVICE_TABLE(acpi, processor_device_ids);
-#define ICPU(model){ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
-static const struct x86_cpu_id intel_cpu_ids[] = {
- ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
- {}
-};
-MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
-
static struct device_driver acpi_processor_driver = {
.name = "processor",
.bus = &cpu_subsys,
@@ -239,7 +226,6 @@ static inline void acpi_pss_perf_exit(struct acpi_processor
*pr,
static int __acpi_processor_start(struct acpi_device *device)
{
struct acpi_processor *pr = acpi_driver_data(device);
- const struct x86_cpu_id *id;
acpi_status status;
int result = 0;
@@ -253,9 +239,7 @@ static int __acpi_processor_start(struct acpi_device
*device)
if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
dev_dbg(&device->dev, "CPPC data invalid or not present\n");
- id = x86_match_cpu(intel_cpu_ids);
- if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
- &acpi_idle_driver))
+ if (!cpuidle_get_driver() || cpuidle_get_driver() == &acpi_idle_driver)
acpi_processor_power_init(pr);
result = acpi_pss_perf_init(pr, device);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "ICL HACK: Disable ACPI idle driver"
== Series Details ==
Series: Revert "ICL HACK: Disable ACPI idle driver"
URL : https://patchwork.freedesktop.org/series/60731/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6091 -> Patchwork_13026
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/
Known issues
Here are the changes found in Patchwork_13026 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_guc:
- fi-apl-guc: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-apl-guc/igt@i915_selftest@live_guc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-apl-guc/igt@i915_selftest@live_guc.html
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [PASS][7] -> [DMESG-FAIL][8] ([fdo#110620])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][9] -> [FAIL][10] ([fdo#103167])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][11] ([fdo#108511]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][13] ([fdo#110235]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][15] ([fdo#102614]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [DMESG-WARN][17] ([fdo#106387]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
Participating hosts (50 -> 44)
--
Additional (2): fi-bsw-n3050 fi-pnv-d510
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-gdg-551 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6091 -> Patchwork_13026
CI_DRM_6091: 0ad895242a8e957336088625a9a6ba48ab838ec9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4994: 555019f862c35f1619627761d6da21385be40920 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13026: 90b04825a71257
[Intel-gfx] [PATCH i-g-t] benchmarks/gem_wsim: Randomise random seed
To avoid hitting the same rut on each benchmark run, start with a new
random seed. To allow hitting the same rut again, let it be specified
by the user.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 48568ce40..cf2a44746 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -2282,8 +2282,9 @@ int main(int argc, char **argv)
igt_require(fd);
init_clocks();
+ srand(time(NULL));
- while ((c = getopt(argc, argv, "hqv2RSHxGdc:n:r:w:W:a:t:b:p:")) != -1) {
+ while ((c = getopt(argc, argv, "hqv2RSHxGdc:n:r:w:W:a:t:b:p:s:")) !=
-1) {
switch (c) {
case 'W':
if (master_workload >= 0) {
@@ -2300,6 +2301,9 @@ int main(int argc, char **argv)
case 'p':
prio = atoi(optarg);
break;
+ case 's':
+ srand(atoi(optarg));
+ break;
case 'a':
if (append_workload_arg) {
if (verbose)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Add HDR Metadata Parsing and handling in DRM layer (rev11)
== Series Details == Series: Add HDR Metadata Parsing and handling in DRM layer (rev11) URL : https://patchwork.freedesktop.org/series/25091/ State : success == Summary == CI Bug Log - changes from CI_DRM_6090_full -> Patchwork_13025_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13025_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html * igt@i915_pm_rpm@legacy-planes-dpms: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-skl6/igt@i915_pm_...@legacy-planes-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-skl1/igt@i915_pm_...@legacy-planes-dpms.html * igt@i915_pm_rpm@system-suspend: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#108840]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-iclb2/igt@i915_pm_...@system-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-iclb7/igt@i915_pm_...@system-suspend.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108] / [fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-skl8/igt@i915_pm_...@system-suspend-execbuf.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-skl10/igt@i915_pm_...@system-suspend-execbuf.html * igt@i915_suspend@sysfs-reader: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-skl9/igt@i915_susp...@sysfs-reader.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-skl4/igt@i915_susp...@sysfs-reader.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-msflip-blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-msflip-blt.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [fdo#110403]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-iclb7/igt@kms_psr@psr2_cursor_plane_onoff.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-kbl: [FAIL][17] ([fdo#110667]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-kbl3/igt@gem_...@in-flight-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-kbl1/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-glk: [FAIL][19] ([fdo#109661]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-glk1/igt@gem_...@unwedge-stress.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-glk6/igt@gem_...@unwedge-stress.html * igt@gem_exec_suspend@basic-s3: - shard-snb: [DMESG-WARN][21] ([fdo#102365]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-snb7/igt@gem_exec_susp...@basic-s3.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-snb7/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rpm@fences: - shard-skl: [INCOMPLETE][23] ([fdo#107807]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-skl2/igt@i915_pm_...@fences.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13025/shard-skl2/igt@i915_pm_...@fences.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [DMESG-WARN][25] ([fdo#108566]) -> [PASS][26] +5 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6090/shard-apl6/igt@i915_susp
Re: [Intel-gfx] [PATCH xf86-video-intel v2 1/2] sna: Refactor property parsing
On Fri, Apr 26, 2019 at 6:32 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Generalize the code that parses the plane properties to be useable
> for crtc (or any kms object) properties as well.
>
> v2: plane 'type' prop is enum not range!
>
> Cc: Mario Kleiner
> Signed-off-by: Ville Syrjälä
> ---
This patch is
Reviewed-and-tested-by: Mario Kleiner
-mario
> src/sna/sna_display.c | 69 ++-
> 1 file changed, 49 insertions(+), 20 deletions(-)
>
> diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
> index 119ea981d243..41edfec12839 100644
> --- a/src/sna/sna_display.c
> +++ b/src/sna/sna_display.c
> @@ -215,6 +215,7 @@ struct sna_crtc {
> uint32_t rotation;
> struct plane {
> uint32_t id;
> + uint32_t type;
> struct {
> uint32_t prop;
> uint32_t supported;
> @@ -3391,33 +3392,40 @@ void sna_crtc_set_sprite_colorspace(xf86CrtcPtr crtc,
> p->color_encoding.values[colorspace]);
> }
>
> -static int plane_details(struct sna *sna, struct plane *p)
> +typedef void (*parse_prop_func)(struct sna *sna,
> + struct drm_mode_get_property *prop,
> + uint64_t value,
> + void *data);
> +static void parse_props(struct sna *sna,
> + uint32_t obj_type, uint32_t obj_id,
> + parse_prop_func parse_prop,
> + void *data)
> {
> #define N_STACK_PROPS 32 /* must be a multiple of 2 */
> struct local_mode_obj_get_properties arg;
> uint64_t stack[N_STACK_PROPS + N_STACK_PROPS/2];
> uint64_t *values = stack;
> uint32_t *props = (uint32_t *)(values + N_STACK_PROPS);
> - int i, type = DRM_PLANE_TYPE_OVERLAY;
> + int i;
>
> memset(&arg, 0, sizeof(struct local_mode_obj_get_properties));
> - arg.obj_id = p->id;
> - arg.obj_type = LOCAL_MODE_OBJECT_PLANE;
> + arg.obj_id = obj_id;
> + arg.obj_type = obj_type;
>
> arg.props_ptr = (uintptr_t)props;
> arg.prop_values_ptr = (uintptr_t)values;
> arg.count_props = N_STACK_PROPS;
>
> if (drmIoctl(sna->kgem.fd, LOCAL_IOCTL_MODE_OBJ_GETPROPERTIES, &arg))
> - return -1;
> + return;
>
> DBG(("%s: object %d (type %x) has %d props\n", __FUNCTION__,
> -p->id, LOCAL_MODE_OBJECT_PLANE, arg.count_props));
> +obj_id, obj_type, arg.count_props));
>
> if (arg.count_props > N_STACK_PROPS) {
> values = malloc(2*sizeof(uint64_t)*arg.count_props);
> if (values == NULL)
> - return -1;
> + return;
>
> props = (uint32_t *)(values + arg.count_props);
>
> @@ -3444,27 +3452,48 @@ static int plane_details(struct sna *sna, struct
> plane *p)
> DBG(("%s: prop[%d] .id=%ld, .name=%s, .flags=%x,
> .value=%ld\n", __FUNCTION__, i,
> (long)props[i], prop.name, (unsigned)prop.flags,
> (long)values[i]));
>
> - if (strcmp(prop.name, "type") == 0) {
> - type = values[i];
> - } else if (prop_is_rotation(&prop)) {
> - parse_rotation_prop(sna, p, &prop, values[i]);
> - } else if (prop_is_color_encoding(&prop)) {
> - parse_color_encoding_prop(sna, p, &prop, values[i]);
> - }
> + parse_prop(sna, &prop, values[i], data);
> }
>
> - p->rotation.supported &= DBG_NATIVE_ROTATION;
> - if (!xf86ReturnOptValBool(sna->Options, OPTION_ROTATION, TRUE))
> - p->rotation.supported = RR_Rotate_0;
> -
> if (values != stack)
> free(values);
>
> - DBG(("%s: plane=%d type=%d\n", __FUNCTION__, p->id, type));
> - return type;
> #undef N_STACK_PROPS
> }
>
> +static bool prop_is_type(const struct drm_mode_get_property *prop)
> +{
> + return prop_has_type_and_name(prop, 3, "type");
> +}
> +
> +static void plane_parse_prop(struct sna *sna,
> +struct drm_mode_get_property *prop,
> +uint64_t value, void *data)
> +{
> + struct plane *p = data;
> +
> + if (prop_is_type(prop))
> + p->type = value;
> + else if (prop_is_rotation(prop))
> + parse_rotation_prop(sna, p, prop, value);
> + else if (prop_is_color_encoding(prop))
> + parse_color_encoding_prop(sna, p, prop, value);
> +}
> +
> +static int plane_details(struct sna *sna, struct plane *p)
> +{
> + parse_props(sna, LOCAL_MODE_OBJECT_PLANE, p->id,
> + plane_parse_prop, p);
> +
> + p->rotation.supported &= DBG_NATIVE_ROTATION;
> + if (!xf86ReturnOptValBool(sna->Options, OPTION_ROTATION, TRUE))
> +
[Intel-gfx] [PATCH i-g-t] benchmarks/gem_wsim: Measure nop latency on all engines
Different engines take different number of cycles for MI_NOOP. As we
specify workloads in us, we need to take into account the different
calibration values so that the workloads behave as expected.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 72 +++
1 file changed, 52 insertions(+), 20 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 9564dcb70..50a062f0e 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -238,7 +238,7 @@ struct workload
};
static const unsigned int nop_calibration_us = 1000;
-static unsigned long nop_calibration;
+static unsigned long nop_calibration[NUM_ENGINES];
static unsigned int context_vcs_rr;
@@ -808,9 +808,9 @@ static unsigned int get_duration(struct w_step *w)
(dur->max + 1 - dur->min);
}
-static unsigned long get_bb_sz(unsigned int duration)
+static unsigned long get_bb_sz(unsigned int engine, unsigned int duration)
{
- return ALIGN(duration * nop_calibration * sizeof(uint32_t) /
+ return ALIGN(duration * nop_calibration[engine] * sizeof(uint32_t) /
nop_calibration_us, sizeof(uint32_t));
}
@@ -818,7 +818,7 @@ static void
init_bb(struct w_step *w, unsigned int flags)
{
const unsigned int arb_period =
- get_bb_sz(w->preempt_us) / sizeof(uint32_t);
+ get_bb_sz(w->engine, w->preempt_us) / sizeof(uint32_t);
const unsigned int mmap_len = ALIGN(w->bb_sz, 4096);
unsigned int i;
uint32_t *ptr;
@@ -1043,10 +1043,10 @@ alloc_step_batch(struct workload *wrk, struct w_step
*w, unsigned int flags)
if (w->unbound_duration)
/* nops + MI_ARB_CHK + MI_BATCH_BUFFER_START */
- w->bb_sz = max(64, get_bb_sz(w->preempt_us)) +
+ w->bb_sz = max(64, get_bb_sz(w->engine, w->preempt_us)) +
(1 + 3) * sizeof(uint32_t);
else
- w->bb_sz = get_bb_sz(w->duration.max);
+ w->bb_sz = get_bb_sz(w->engine, w->duration.max);
w->bb_handle = w->obj[j].handle = gem_create(fd, w->bb_sz +
(w->unbound_duration ? 4096 : 0));
init_bb(w, flags);
terminate_bb(w, flags);
@@ -2300,7 +2300,7 @@ do_eb(struct workload *wrk, struct w_step *w, enum
intel_engine_id engine,
w->eb.batch_start_offset =
w->unbound_duration ?
0 :
- ALIGN(w->bb_sz - get_bb_sz(get_duration(w)),
+ ALIGN(w->bb_sz - get_bb_sz(engine, get_duration(w)),
2 * sizeof(uint32_t));
for (i = 0; i < w->fence_deps.nr; i++) {
@@ -2580,17 +2580,23 @@ static void fini_workload(struct workload *wrk)
free(wrk);
}
-static unsigned long calibrate_nop(unsigned int tolerance_pct)
+static unsigned long calibrate_nop(unsigned int engine, double tolerance_pct)
{
const uint32_t bbe = 0xa << 23;
unsigned int loops = 17;
unsigned int usecs = nop_calibration_us;
struct drm_i915_gem_exec_object2 obj = {};
- struct drm_i915_gem_execbuffer2 eb =
- { .buffer_count = 1, .buffers_ptr = (uintptr_t)&obj};
+ struct drm_i915_gem_execbuffer2 eb = {
+ .buffer_count = 1,
+ .buffers_ptr = (uintptr_t)&obj,
+ .flags = eb_engine_map[engine],
+ };
long size, last_size;
struct timespec t_0, t_end;
+ if (__gem_execbuf(fd, &eb) != -ENOENT)
+ return 0;
+
clock_gettime(CLOCK_MONOTONIC, &t_0);
size = 256 * 1024;
@@ -2803,8 +2809,8 @@ int main(int argc, char **argv)
int master_workload = -1;
char *append_workload_arg = NULL;
struct w_arg *w_args = NULL;
- unsigned int tolerance_pct = 1;
const struct workload_balancer *balancer = NULL;
+ double tolerance_pct = 1;
char *endptr = NULL;
int prio = 0;
double t;
@@ -2852,10 +2858,28 @@ int main(int argc, char **argv)
clients = strtol(optarg, NULL, 0);
break;
case 't':
- tolerance_pct = strtol(optarg, NULL, 0);
+ tolerance_pct = strtod(optarg, NULL);
break;
case 'n':
- nop_calibration = strtol(optarg, NULL, 0);
+ if (strchr(optarg, ',')) {
+ char *ctx = NULL;
+ char *str = optarg;
+ char *token;
+
+ while ((token = strtok_r(str, ",", &ctx)) !=
NULL) {
+ unsigned long nop;
+ int engine;
+
+ str = NULL;
+ if (sscanf(token, "%d:%lu",
+
[Intel-gfx] [RFC 1/3] kbuild: add support for ensuring headers are self-contained
Sometimes it's useful to be able to explicitly ensure certain headers remain self-contained, i.e. that they are compilable as standalone units, by including and/or forward declaring everything they depend on. Add special target header-test-y where individual Makefiles can add headers to be tested if CONFIG_HEADER_TEST is enabled. This will generate a dummy C file per header that gets built as part of extra-y. Cc: Chris Wilson Cc: Masahiro Yamada Cc: Michal Marek Signed-off-by: Jani Nikula --- Documentation/kbuild/makefiles.txt | 7 +++ init/Kconfig | 9 + scripts/Makefile.build | 10 ++ scripts/Makefile.lib | 3 +++ 4 files changed, 29 insertions(+) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 03c065855eaf..73df58e5ea0c 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1036,6 +1036,13 @@ When kbuild executes, the following steps are followed (roughly): In this example, extra-y is used to list object files that shall be built, but shall not be linked as part of built-in.a. +header-test-y + + header-test-y specifies headers (*.h) in the current directory that + should be compile tested to ensure they are self-contained, + i.e. compilable as standalone units. If CONFIG_HEADER_TEST is enabled, + this autogenerates dummy sources to include the headers, and builds them + as part of extra-y. --- 6.7 Commands useful for building a boot image diff --git a/init/Kconfig b/init/Kconfig index 4592bf7997c0..d91b157201b1 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -95,6 +95,15 @@ config COMPILE_TEST here. If you are a user/distributor, say N here to exclude useless drivers to be distributed. +config HEADER_TEST + bool "Compile test headers that should be standalone compilable" + help + Compile test headers listed in header-test-y target to ensure they are + self-contained, i.e. compilable as standalone units. + + If you are a developer or tester and want to ensure the requested + headers are self-contained, say Y here. Otherwise, choose N. + config LOCALVERSION string "Local version - append to kernel release" help diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 76ca30cc4791..4d4bf698467a 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -291,6 +291,16 @@ quiet_cmd_cc_lst_c = MKLST $@ $(obj)/%.lst: $(src)/%.c FORCE $(call if_changed_dep,cc_lst_c) +# Dummy C sources for header test (header-test-y target) +# --- + +quiet_cmd_header_test = HDRTEST $@ + cmd_header_test = echo "\#include \"$( $@ + +# FIXME: would be nice to be able to limit this implicit rule to header-test-y +$(obj)/%.header_test.c: $(src)/%.h FORCE + $(call if_changed,header_test) + # Compile assembler sources (.S) # --- diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 8a1f64f17740..c2839de06485 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -66,6 +66,9 @@ extra-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y)) extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-)) endif +# Test self-contained headers +extra-$(CONFIG_HEADER_TEST) += $(patsubst %.h,%.header_test.o,$(header-test-y)) + # Add subdir path extra-y:= $(addprefix $(obj)/,$(extra-y)) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel v2 2/2] sna: Support 10bpc gamma via the GAMMA_LUT crtc property
On Fri, Apr 26, 2019 at 6:32 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Probe the GAMMA_LUT/GAMMA_LUT_SIZE props and utilize them when
> the running with > 8bpc.
>
> v2: s/sna_crtc_id/__sna_crtc_id/ in DBG since we have a sna_crtc
>
> Cc: Mario Kleiner
> Signed-off-by: Ville Syrjälä
> ---
> src/sna/sna_display.c | 245 +++---
> 1 file changed, 207 insertions(+), 38 deletions(-)
>
> diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
> index 41edfec12839..6d671dce8c14 100644
> --- a/src/sna/sna_display.c
> +++ b/src/sna/sna_display.c
> @@ -127,6 +127,7 @@ struct local_mode_obj_get_properties {
> uint32_t obj_type;
> uint32_t pad;
> };
> +#define LOCAL_MODE_OBJECT_CRTC 0x
> #define LOCAL_MODE_OBJECT_PLANE 0x
>
> struct local_mode_set_plane {
> @@ -229,6 +230,11 @@ struct sna_crtc {
> } primary;
> struct list sprites;
>
> + struct drm_color_lut *gamma_lut;
> + uint64_t gamma_lut_prop;
> + uint64_t gamma_lut_blob;
> + uint32_t gamma_lut_size;
> +
> uint32_t mode_serial, flip_serial;
>
> uint32_t last_seq, wrap_seq;
> @@ -317,6 +323,9 @@ static void __sna_output_dpms(xf86OutputPtr output, int
> dpms, int fixup);
> static void sna_crtc_disable_cursor(struct sna *sna, struct sna_crtc *crtc);
> static bool sna_crtc_flip(struct sna *sna, struct sna_crtc *crtc,
> struct kgem_bo *bo, int x, int y);
> +static void sna_crtc_gamma_set(xf86CrtcPtr crtc,
> + CARD16 *red, CARD16 *green,
> + CARD16 *blue, int size);
>
> static bool is_zaphod(ScrnInfoPtr scrn)
> {
> @@ -3150,11 +3159,9 @@ sna_crtc_set_mode_major(xf86CrtcPtr crtc,
> DisplayModePtr mode,
>mode->VDisplay <= sna->mode.max_crtc_height);
>
> #if HAS_GAMMA
> - drmModeCrtcSetGamma(sna->kgem.fd, __sna_crtc_id(sna_crtc),
> - crtc->gamma_size,
> - crtc->gamma_red,
> - crtc->gamma_green,
> - crtc->gamma_blue);
> + sna_crtc_gamma_set(crtc,
> + crtc->gamma_red, crtc->gamma_green,
> + crtc->gamma_blue, crtc->gamma_size);
> #endif
>
> saved_kmode = sna_crtc->kmode;
> @@ -3212,12 +3219,44 @@ void sna_mode_adjust_frame(struct sna *sna, int x,
> int y)
>
> static void
> sna_crtc_gamma_set(xf86CrtcPtr crtc,
> - CARD16 *red, CARD16 *green, CARD16 *blue, int size)
> + CARD16 *red, CARD16 *green, CARD16 *blue, int size)
> {
> - assert(to_sna_crtc(crtc));
> - drmModeCrtcSetGamma(to_sna(crtc->scrn)->kgem.fd,
> - sna_crtc_id(crtc),
> - size, red, green, blue);
> + struct sna *sna = to_sna(crtc->scrn);
> + struct sna_crtc *sna_crtc = to_sna_crtc(crtc);
> + struct drm_color_lut *lut = sna_crtc->gamma_lut;
> + uint32_t blob_size = size * sizeof(lut[0]);
> + uint32_t blob_id;
> + int ret, i;
> +
> + DBG(("%s: gamma_size %d\n", __FUNCTION__, size));
> +
> + if (!lut) {
> + assert(size == 256);
> +
> + drmModeCrtcSetGamma(to_sna(crtc->scrn)->kgem.fd,
> + sna_crtc_id(crtc),
> + size, red, green, blue);
> + return;
> + }
> +
> + assert(size == sna_crtc->gamma_lut_size);
> +
> + for (i = 0; i < size; i++) {
> + lut[i].red = red[i];
> + lut[i].green = green[i];
> + lut[i].blue = blue[i];
> + }
> +
> + ret = drmModeCreatePropertyBlob(sna->kgem.fd, lut, blob_size,
> &blob_id);
> + if (ret)
> + return;
> +
> + ret = drmModeObjectSetProperty(sna->kgem.fd,
> + sna_crtc->id, DRM_MODE_OBJECT_CRTC,
> + sna_crtc->gamma_lut_prop,
> + blob_id);
> +
> + drmModeDestroyPropertyBlob(sna->kgem.fd, blob_id);
> }
>
> static void
> @@ -3229,6 +3268,8 @@ sna_crtc_destroy(xf86CrtcPtr crtc)
> if (sna_crtc == NULL)
> return;
>
> + free(sna_crtc->gamma_lut);
> +
> list_for_each_entry_safe(sprite, sn, &sna_crtc->sprites, link)
> free(sprite);
>
> @@ -3663,6 +3704,55 @@ bool sna_has_sprite_format(struct sna *sna, uint32_t
> format)
> return false;
> }
>
> +inline static bool prop_is_gamma_lut(const struct drm_mode_get_property
> *prop)
> +{
> + return prop_has_type_and_name(prop, 4, "GAMMA_LUT");
> +}
> +
> +inline static bool prop_is_gamma_lut_size(const struct drm_mode_get_property
> *prop)
> +{
> + return prop_has_type_and_name(prop, 1, "GAMMA_LUT_SIZE");
> +}
> +
> +static void sna_crtc_parse_prop(struct sna *sna,
> +
[Intel-gfx] [RFC 3/3] DO NOT MERGE: drm/i915: add failing header to header-test-y
Demonstrate build failure on a header that is not self-contained. Cc: Chris Wilson Cc: Masahiro Yamada Cc: Michal Marek Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 05d01a3830d0..fcebf453c9ed 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -206,4 +206,5 @@ obj-$(CONFIG_DRM_I915) += i915.o obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o header-test-y := \ + i915_fixed.h \ i915_drv.h -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for benchmarks/gem_wsim: Measure nop latency on all engines
== Series Details == Series: benchmarks/gem_wsim: Measure nop latency on all engines URL : https://patchwork.freedesktop.org/series/60737/ State : failure == Summary == Applying: benchmarks/gem_wsim: Measure nop latency on all engines Patch failed at 0001 benchmarks/gem_wsim: Measure nop latency on all engines 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
[Intel-gfx] [RFC 2/3] drm/i915: ensure headers remain self-contained
Use the new header test facility. Cc: Chris Wilson Cc: Masahiro Yamada Cc: Michal Marek Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 1787e1299b1b..05d01a3830d0 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -204,3 +204,6 @@ i915-y += intel_lpe_audio.o obj-$(CONFIG_DRM_I915) += i915.o obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o + +header-test-y := \ + i915_drv.h -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [RFC,1/3] kbuild: add support for ensuring headers are self-contained
== Series Details == Series: series starting with [RFC,1/3] kbuild: add support for ensuring headers are self-contained URL : https://patchwork.freedesktop.org/series/60738/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: kbuild: add support for ensuring headers are self-contained +Error in reading or end of file. Commit: drm/i915: ensure headers remain self-contained Okay! Commit: DO NOT MERGE: drm/i915: add failing header to header-test-y Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/3] kbuild: add support for ensuring headers are self-contained
== Series Details ==
Series: series starting with [RFC,1/3] kbuild: add support for ensuring headers
are self-contained
URL : https://patchwork.freedesktop.org/series/60738/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6091 -> Patchwork_13027
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_13027:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_basic@basic-blt:
- {fi-cml-u}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-cml-u/igt@gem_exec_ba...@basic-blt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/fi-cml-u/igt@gem_exec_ba...@basic-blt.html
Known issues
Here are the changes found in Patchwork_13027 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: [PASS][3] -> [DMESG-WARN][4] ([fdo#108965])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927] /
[fdo#110624])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][9] ([fdo#108511]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][11] ([fdo#110235]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][13] ([fdo#102614]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [DMESG-WARN][15] ([fdo#106387]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624
Participating hosts (50 -> 43)
--
Additional (1): fi-pnv-d510
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6091 -> Patchwork_13027
CI_DRM_6091: 0ad895242a8e957336088625a9a6ba48ab838ec9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4994: 555019f862c35f1619627761d6da21385be40920 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13027: 01f606aff618932547f3d16320d0334dd8cf2989 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
01f606aff618 DO NOT MERGE: drm/i915: add fa
Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs
On Thu, 2019-05-16 at 15:55 +0300, Jani Nikula wrote:
> On Thu, 16 May 2019, Maarten Lankhorst <
> maarten.lankho...@linux.intel.com> wrote:
> > Op 16-05-2019 om 07:58 schreef Harish Chegondi:
> > > display_pipe_crc_irq_handler() skips the first CRC for all GPUs
> > > and the
> > > second CRC for GEN8+ GPUs. The second CRC is invalid even for BYT
> > > which
> > > is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
> > >
> > > Cc: Jani Nikula
> > > Cc: Tomi Sarvela
> > > Cc: Petri Latvala
> > > Cc: Ville Syrjälä
> > > Cc: Maarten Lankhorst
> > > Signed-off-by: Harish Chegondi
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 233211fde0ea..3809e9f7fae2 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -1775,11 +1775,11 @@ static void
> > > display_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
> > >* bonkers. So let's just wait for the next vblank and read
> > >* out the buggy result.
> > >*
> > > - * On GEN8+ sometimes the second CRC is bonkers as well, so
> > > + * On GEN7+ sometimes the second CRC is bonkers as well, so
> > >* don't trust that one either.
> > >*/
> > > if (pipe_crc->skipped <= 0 ||
> > > - (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
> > > + (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped == 1)) {
> > > pipe_crc->skipped++;
> > > spin_unlock(&pipe_crc->lock);
> > > return;
> >
> > I would be interested in the results, haswell is different from
> > VLV. Has it ever been observed on that platform?
>
> Good point. I looked at [1] which I presumed was on VLV, but it says
> nothing about HSW.
In fdo # 103191, CRC mismatch failures in igt@kms_pipe_crc_basic@*
tests have not been observed on HSW. These tests have been very
consistently failing on CI fi-byt-squawks system which is a chromebook,
sporadically failing on CI fi-byt-clapper system which is also a
chromebook. However the tests are passing on other CI BYT systems like
fi-byt-n2820 and fi-byt-j1900 which are not chromebooks and the display
is not eDP. I haven't seen these failures happening on other GEN7 GPUs.
Instead of skipping the second CRC just for BYT, I thought it may be a
better idea to skip the second CRC on all GEN7 GPUs as the current code
is already skipping the second CRC on all GEN8+ GPUs.
Thanks!
Harish.
>
> BR,
> Jani.
>
>
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=103191#c34
>
>
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: skip the second CRC even for GEN 7 GPUs
On Thu, 2019-05-16 at 16:30 +0300, Ville Syrjälä wrote:
> On Thu, May 16, 2019 at 03:55:25PM +0300, Jani Nikula wrote:
> > On Thu, 16 May 2019, Maarten Lankhorst <
> > maarten.lankho...@linux.intel.com> wrote:
> > > Op 16-05-2019 om 07:58 schreef Harish Chegondi:
> > > > display_pipe_crc_irq_handler() skips the first CRC for all GPUs
> > > > and the
> > > > second CRC for GEN8+ GPUs. The second CRC is invalid even for
> > > > BYT which
> > > > is a GEN7 GPU. So, skip the second CRC even for GEN7 GPUs.
> > > >
> > > > Cc: Jani Nikula
> > > > Cc: Tomi Sarvela
> > > > Cc: Petri Latvala
> > > > Cc: Ville Syrjälä
> > > > Cc: Maarten Lankhorst
> > > > Signed-off-by: Harish Chegondi
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> > > > ---
> > > > drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 233211fde0ea..3809e9f7fae2 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -1775,11 +1775,11 @@ static void
> > > > display_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
> > > > * bonkers. So let's just wait for the next vblank and
> > > > read
> > > > * out the buggy result.
> > > > *
> > > > -* On GEN8+ sometimes the second CRC is bonkers as
> > > > well, so
> > > > +* On GEN7+ sometimes the second CRC is bonkers as
> > > > well, so
> > > > * don't trust that one either.
> > > > */
> > > > if (pipe_crc->skipped <= 0 ||
> > > > - (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped ==
> > > > 1)) {
> > > > + (INTEL_GEN(dev_priv) >= 7 && pipe_crc->skipped ==
> > > > 1)) {
> > > > pipe_crc->skipped++;
> > > > spin_unlock(&pipe_crc->lock);
> > > > return;
> > >
> > > I would be interested in the results, haswell is different from
> > > VLV. Has it ever been observed on that platform?
> >
> > Good point. I looked at [1] which I presumed was on VLV, but it
> > says
> > nothing about HSW.
>
> This whole thing is just a pile of duct tape anyway. The reason(s)
> for these funky crcs has never been properly analysed.
Ville,
Are the patches in your branch :
git://github.com/vsyrjala/linux.git g4x_fixes_4
related to fixing these invalid CRCs ?
Thanks!
Harish
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/7] drm/i915: Remove rpm asserts that use i915
Quite a few of the call points have already switched to the version
working directly on the runtime_pm structure, so let's switch over the
rest and kill the i915-based asserts.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +-
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
drivers/gpu/drm/i915/intel_csr.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 26 ++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 14 ++--
drivers/gpu/drm/i915/intel_uncore.c | 12 +--
9 files changed, 28 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index 1fa2f65c3cd1..7f4e3456ce11 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -131,7 +131,7 @@ void intel_vgpu_write_fence(struct intel_vgpu *vgpu,
struct drm_i915_fence_reg *reg;
i915_reg_t fence_reg_lo, fence_reg_hi;
- assert_rpm_wakelock_held(dev_priv);
+ assert_rpm_wakelock_held(&dev_priv->runtime_pm);
if (WARN_ON(fence >= vgpu_fence_sz(vgpu)))
return;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2fcec1bfb038..5bccf7955285 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1807,7 +1807,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
goto err_fence;
/* Mark as being mmapped into userspace for later revocation */
- assert_rpm_wakelock_held(dev_priv);
+ assert_rpm_wakelock_held(&dev_priv->runtime_pm);
if (!i915_vma_set_userfault(vma) && !obj->userfault_count++)
list_add(&obj->userfault_link, &dev_priv->mm.userfault_list);
GEM_BUG_ON(!obj->userfault_count);
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index 3084f52e3372..50f52264b163 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -354,7 +354,7 @@ i915_vma_pin_fence(struct i915_vma *vma)
/* Note that we revoke fences on runtime suspend. Therefore the user
* must keep the device awake whilst using the fence.
*/
- assert_rpm_wakelock_held(vma->vm->i915);
+ assert_rpm_wakelock_held(&vma->vm->i915->runtime_pm);
/* Just update our place in the LRU if our fence is getting reused. */
if (vma->fence) {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 233211fde0ea..32f56dd68ac9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -588,7 +588,7 @@ void gen6_disable_rps_interrupts(struct drm_i915_private
*dev_priv)
void gen9_reset_guc_interrupts(struct drm_i915_private *dev_priv)
{
- assert_rpm_wakelock_held(dev_priv);
+ assert_rpm_wakelock_held(&dev_priv->runtime_pm);
spin_lock_irq(&dev_priv->irq_lock);
gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
@@ -597,7 +597,7 @@ void gen9_reset_guc_interrupts(struct drm_i915_private
*dev_priv)
void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv)
{
- assert_rpm_wakelock_held(dev_priv);
+ assert_rpm_wakelock_held(&dev_priv->runtime_pm);
spin_lock_irq(&dev_priv->irq_lock);
if (!dev_priv->guc.interrupts_enabled) {
@@ -611,7 +611,7 @@ void gen9_enable_guc_interrupts(struct drm_i915_private
*dev_priv)
void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv)
{
- assert_rpm_wakelock_held(dev_priv);
+ assert_rpm_wakelock_held(&dev_priv->runtime_pm);
spin_lock_irq(&dev_priv->irq_lock);
dev_priv->guc.interrupts_enabled = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index d4d308b6d1d8..07c84b8e2560 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -364,7 +364,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
int err;
/* Access through the GTT requires the device to be awake. */
- assert_rpm_wakelock_held(vma->vm->i915);
+ assert_rpm_wakelock_held(&vma->vm->i915->runtime_pm);
lockdep_assert_held(&vma->vm->i915->drm.struct_mutex);
if (WARN_ON(!i915_vma_is_map_and_fenceable(vma))) {
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 4527b9662330..ade1a3bd75bc 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -273,7 +273,7 @@ void intel_csr_load_program(struct drm_i915_private
*dev_priv)
}
fw_size = dev_priv->csr.dmc_fw_size;
- assert_rpm_wakelock_held(dev_priv);
+ assert_rpm_wakelock_held(&dev_priv->runtime_pm);
pree
[Intel-gfx] [RFC 1/7] drm/i915: prefer i915_runtime_pm in intel_runtime function
As a first step towards updating the code to work on the runtime_pm
structure instead of i915, rework all the internals to use and pass
around that.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_drv.h| 10 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 152
3 files changed, 82 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5801f5407589..474074c7f395 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1177,6 +1177,8 @@ struct skl_wm_params {
*/
struct i915_runtime_pm {
atomic_t wakeref_count;
+ struct device *kdev;
+ bool available;
bool suspended;
bool irqs_enabled;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 30b2d6ed2d53..bd04f394fbd3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1662,13 +1662,17 @@ assert_rpm_wakelock_held(struct i915_runtime_pm
*rpm, int wakeref_count)
}
static inline void
-assert_rpm_raw_wakeref_held(struct drm_i915_private *i915)
+__assert_rpm_raw_wakeref_held(struct i915_runtime_pm *rpm)
{
- struct i915_runtime_pm *rpm = &i915->runtime_pm;
-
assert_rpm_raw_wakeref_held(rpm, atomic_read(&rpm->wakeref_count));
}
+static inline void
+assert_rpm_raw_wakeref_held(struct drm_i915_private *i915)
+{
+ __assert_rpm_raw_wakeref_held(&i915->runtime_pm);
+}
+
static inline void
__assert_rpm_wakelock_held(struct i915_runtime_pm *rpm)
{
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index b4abababdf6c..2e21f562df44 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -60,19 +60,19 @@
* present for a given platform.
*/
-static intel_wakeref_t intel_runtime_pm_get_raw(struct drm_i915_private *i915);
+static intel_wakeref_t intel_runtime_pm_get_raw(struct i915_runtime_pm *rpm);
static void
-__intel_runtime_pm_put(struct drm_i915_private *i915, intel_wakeref_t wref,
+__intel_runtime_pm_put(struct i915_runtime_pm *rpm, intel_wakeref_t wref,
bool wakelock);
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
static void
-intel_runtime_pm_put_raw(struct drm_i915_private *i915, intel_wakeref_t wref);
+intel_runtime_pm_put_raw(struct i915_runtime_pm *rpm, intel_wakeref_t wref);
#else
-static inline void intel_runtime_pm_put_raw(struct drm_i915_private *i915,
+static inline void intel_runtime_pm_put_raw(struct i915_runtime_pm *rpm,
intel_wakeref_t wref)
{
- __intel_runtime_pm_put(i915, -1, false);
+ __intel_runtime_pm_put(rpm, -1, false);
}
#endif
@@ -112,21 +112,18 @@ static void __print_depot_stack(depot_stack_handle_t
stack,
snprint_stack_trace(buf, sz, &trace, indent);
}
-static void init_intel_runtime_pm_wakeref(struct drm_i915_private *i915)
+static void init_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm)
{
- struct i915_runtime_pm *rpm = &i915->runtime_pm;
-
spin_lock_init(&rpm->debug.lock);
}
static noinline depot_stack_handle_t
-track_intel_runtime_pm_wakeref(struct drm_i915_private *i915)
+track_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm)
{
- struct i915_runtime_pm *rpm = &i915->runtime_pm;
depot_stack_handle_t stack, *stacks;
unsigned long flags;
- if (!HAS_RUNTIME_PM(i915))
+ if (!rpm->available)
return -1;
stack = __save_depot_stack();
@@ -153,10 +150,9 @@ track_intel_runtime_pm_wakeref(struct drm_i915_private
*i915)
return stack;
}
-static void untrack_intel_runtime_pm_wakeref(struct drm_i915_private *i915,
+static void untrack_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm,
depot_stack_handle_t stack)
{
- struct i915_runtime_pm *rpm = &i915->runtime_pm;
unsigned long flags, n;
bool found = false;
@@ -274,9 +270,8 @@ dump_and_free_wakeref_tracking(struct
intel_runtime_pm_debug *debug)
}
static noinline void
-__intel_wakeref_dec_and_check_tracking(struct drm_i915_private *i915)
+__intel_wakeref_dec_and_check_tracking(struct i915_runtime_pm *rpm)
{
- struct i915_runtime_pm *rpm = &i915->runtime_pm;
struct intel_runtime_pm_debug dbg = {};
unsigned long flags;
@@ -292,9 +287,8 @@ __intel_wakeref_dec_and_check_tracking(struct
drm_i915_private *i915)
}
static noinline void
-untrack_all_intel_runtime_pm_wakerefs(struct drm_i915_private *i915)
+untrack_all_intel_runtime_pm_wakerefs(struct i915_runtime_pm *rpm)
{
- struct i915_runtime_pm *rpm = &i915->runtime_pm;
struct intel_runtime_pm_debug dbg = {};
unsigned long flags;
@@ -345,61 +339,57 @@ void print_intel_runtime_pm_wakeref(struct
d
[Intel-gfx] [RFC 3/7] drm/i915: make enable/disable rpm assert function use the rpm structure
With this all the rpm assert-related functions consistently work on the i915_runtime_pm structure Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_drv.c | 44 +++-- drivers/gpu/drm/i915/i915_irq.c | 32 ++--- drivers/gpu/drm/i915/intel_drv.h| 12 drivers/gpu/drm/i915/intel_guc.c| 4 +-- drivers/gpu/drm/i915/intel_uncore.c | 12 5 files changed, 53 insertions(+), 51 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 2c7a4318d13c..8b9e5b042e70 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1884,7 +1884,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret < 0) goto out_pci_disable; - disable_rpm_wakeref_asserts(dev_priv); + disable_rpm_wakeref_asserts(&dev_priv->runtime_pm); ret = i915_driver_init_mmio(dev_priv); if (ret < 0) @@ -1900,7 +1900,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) i915_driver_register(dev_priv); - enable_rpm_wakeref_asserts(dev_priv); + enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); i915_welcome_messages(dev_priv); @@ -1911,7 +1911,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) out_cleanup_mmio: i915_driver_cleanup_mmio(dev_priv); out_runtime_pm_put: - enable_rpm_wakeref_asserts(dev_priv); + enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); i915_driver_cleanup_early(dev_priv); out_pci_disable: pci_disable_device(pdev); @@ -1926,7 +1926,7 @@ void i915_driver_unload(struct drm_device *dev) struct drm_i915_private *dev_priv = to_i915(dev); struct pci_dev *pdev = dev_priv->drm.pdev; - disable_rpm_wakeref_asserts(dev_priv); + disable_rpm_wakeref_asserts(&dev_priv->runtime_pm); i915_driver_unregister(dev_priv); @@ -1966,7 +1966,7 @@ void i915_driver_unload(struct drm_device *dev) i915_driver_cleanup_hw(dev_priv); i915_driver_cleanup_mmio(dev_priv); - enable_rpm_wakeref_asserts(dev_priv); + enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); intel_runtime_pm_cleanup(dev_priv); } @@ -2066,7 +2066,7 @@ static int i915_drm_suspend(struct drm_device *dev) struct pci_dev *pdev = dev_priv->drm.pdev; pci_power_t opregion_target_state; - disable_rpm_wakeref_asserts(dev_priv); + disable_rpm_wakeref_asserts(&dev_priv->runtime_pm); /* We do a lot of poking in a lot of registers, make sure they work * properly. */ @@ -2100,7 +2100,7 @@ static int i915_drm_suspend(struct drm_device *dev) intel_csr_ucode_suspend(dev_priv); - enable_rpm_wakeref_asserts(dev_priv); + enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); return 0; } @@ -2123,7 +2123,7 @@ static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation) struct pci_dev *pdev = dev_priv->drm.pdev; int ret; - disable_rpm_wakeref_asserts(dev_priv); + disable_rpm_wakeref_asserts(&dev_priv->runtime_pm); i915_gem_suspend_late(dev_priv); @@ -2164,7 +2164,7 @@ static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation) pci_set_power_state(pdev, PCI_D3hot); out: - enable_rpm_wakeref_asserts(dev_priv); + enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); if (!dev_priv->uncore.user_forcewake.count) intel_runtime_pm_cleanup(dev_priv); @@ -2200,7 +2200,7 @@ static int i915_drm_resume(struct drm_device *dev) struct drm_i915_private *dev_priv = to_i915(dev); int ret; - disable_rpm_wakeref_asserts(dev_priv); + disable_rpm_wakeref_asserts(&dev_priv->runtime_pm); intel_sanitize_gt_powersave(dev_priv); i915_gem_sanitize(dev_priv); @@ -2260,7 +2260,7 @@ static int i915_drm_resume(struct drm_device *dev) intel_power_domains_enable(dev_priv); - enable_rpm_wakeref_asserts(dev_priv); + enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); return 0; } @@ -2315,7 +2315,7 @@ static int i915_drm_resume_early(struct drm_device *dev) pci_set_master(pdev); - disable_rpm_wakeref_asserts(dev_priv); + disable_rpm_wakeref_asserts(&dev_priv->runtime_pm); if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) ret = vlv_resume_prepare(dev_priv, false); @@ -2340,7 +2340,7 @@ static int i915_drm_resume_early(struct drm_device *dev) intel_gt_sanitize(dev_priv, true); - enable_rpm_wakeref_asserts(dev_priv); + enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); return ret; } @@ -2873,6 +2873,7 @@ static int intel_runtime_suspend(struct device *kdev) struct pci_dev *pdev = to_pci_dev(kdev); struct drm_device
[Intel-gfx] [RFC 0/7] Runtime PM encapsulation
While reworking other parts of the code to rely less on i915 and use the new uncore logic for register access, I've noticed that, after the conversion, in a few places the i915 structure is required only for the rpm_get/put calls. We do have a reference to the rpm structure in the uncore one, so, since we're relying on the latter more, having the rpm code work directly on its own sub-structure will allow us to ditch dev_priv in a few more places. Also, having a section of the code work on its own logic sub-structure instead getting it out of dev_priv every time makes the flow generally cleaner IMO. This series grows the code slightly due to flipping all the get/put call points derive the rpm structure from dev_priv, but we should recoup that over time while we complete the rework. While applying the changes I noticed that there is also a lot of potential for refactoring/encapsuliation around the display power functions. I experimented a bit with splitting these functions to their own file and moving most of the logic to work on i915_power_domains since we keep getting that structure out of i915, but the code is not as easy to update due to frequent calls to other areas in the display domain, so I gave up for now. Series very lightly tested. Cc: Imre Deak Cc: Chris Wilson Daniele Ceraolo Spurio (7): drm/i915: prefer i915_runtime_pm in intel_runtime function drm/i915: Remove rpm asserts that use i915 drm/i915: make enable/disable rpm assert function use the rpm structure drm/i915: move and rename i915_runtime_pm drm/i915: move a few more functions to accept the rpm structure drm/i915: update rpm_get/put to use the rpm structure drm/i915: update with_intel_runtime_pm to use the rpm structure drivers/gpu/drm/i915/gt/intel_context.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +- drivers/gpu/drm/i915/gt/intel_hangcheck.c | 4 +- drivers/gpu/drm/i915/gt/intel_reset.c | 6 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 20 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 36 +-- .../gpu/drm/i915/gt/selftest_workarounds.c| 16 +- drivers/gpu/drm/i915/gvt/aperture_gm.c| 17 +- drivers/gpu/drm/i915/gvt/gvt.h| 4 +- drivers/gpu/drm/i915/gvt/sched_policy.c | 4 +- drivers/gpu/drm/i915/gvt/scheduler.c | 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 79 +++ drivers/gpu/drm/i915/i915_drv.c | 57 ++--- drivers/gpu/drm/i915/i915_drv.h | 50 + drivers/gpu/drm/i915/i915_gem.c | 30 +-- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +- drivers/gpu/drm/i915/i915_gem_shrinker.c | 12 +- drivers/gpu/drm/i915/i915_irq.c | 38 ++-- drivers/gpu/drm/i915/i915_perf.c | 6 +- drivers/gpu/drm/i915/i915_pmu.c | 11 +- drivers/gpu/drm/i915/i915_sysfs.c | 14 +- drivers/gpu/drm/i915/i915_vma.c | 2 +- drivers/gpu/drm/i915/intel_csr.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 4 +- drivers/gpu/drm/i915/intel_drv.h | 105 - drivers/gpu/drm/i915/intel_fbdev.c| 6 +- drivers/gpu/drm/i915/intel_guc.c | 4 +- drivers/gpu/drm/i915/intel_guc_log.c | 6 +- drivers/gpu/drm/i915/intel_hotplug.c | 4 +- drivers/gpu/drm/i915/intel_huc.c | 2 +- drivers/gpu/drm/i915/intel_panel.c| 2 +- drivers/gpu/drm/i915/intel_pm.c | 8 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 205 -- drivers/gpu/drm/i915/intel_runtime_pm.h | 185 ++-- drivers/gpu/drm/i915/intel_uc.c | 2 +- drivers/gpu/drm/i915/intel_uncore.c | 26 +-- drivers/gpu/drm/i915/intel_uncore.h | 4 +- drivers/gpu/drm/i915/intel_wakeref.c | 4 +- drivers/gpu/drm/i915/selftests/huge_pages.c | 4 +- drivers/gpu/drm/i915/selftests/i915_active.c | 8 +- drivers/gpu/drm/i915/selftests/i915_gem.c | 10 +- .../drm/i915/selftests/i915_gem_coherency.c | 4 +- .../gpu/drm/i915/selftests/i915_gem_context.c | 18 +- .../gpu/drm/i915/selftests/i915_gem_evict.c | 6 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 8 +- .../gpu/drm/i915/selftests/i915_gem_object.c | 6 +- drivers/gpu/drm/i915/selftests/i915_request.c | 22 +- .../gpu/drm/i915/selftests/i915_timeline.c| 16 +- drivers/gpu/drm/i915/selftests/intel_guc.c| 8 +- drivers/gpu/drm/i915/selftests/intel_uncore.c | 4 +- .../gpu/drm/i915/selftests/mock_gem_device.c | 2 +- 52 files changed, 553 insertions(+), 566 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 4/7] drm/i915: move and rename i915_runtime_pm
Asserts aside, all the code working on this structure is in
intel_runtime_pm.c and uses the intel_ prefix, so move the
structure to intel_runtime_pm.h and adopt the same prefix.
Since all the asserts are now working on the runtime_pm structure,
bring them across as well.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/i915_drv.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 52 +
drivers/gpu/drm/i915/intel_drv.h| 97
drivers/gpu/drm/i915/intel_runtime_pm.c | 58 +-
drivers/gpu/drm/i915/intel_runtime_pm.h | 147
drivers/gpu/drm/i915/intel_uncore.h | 4 +-
7 files changed, 183 insertions(+), 183 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 072464a18050..227a1cdf4f02 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2636,7 +2636,7 @@ static int i915_energy_uJ(struct seq_file *m, void *data)
return 0;
}
-static int i915_runtime_pm_status(struct seq_file *m, void *unused)
+static int intel_runtime_pm_status(struct seq_file *m, void *unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct pci_dev *pdev = dev_priv->drm.pdev;
@@ -4600,7 +4600,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_llc", i915_llc, 0},
{"i915_edp_psr_status", i915_edp_psr_status, 0},
{"i915_energy_uJ", i915_energy_uJ, 0},
- {"i915_runtime_pm_status", i915_runtime_pm_status, 0},
+ {"intel_runtime_pm_status", intel_runtime_pm_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
{"i915_dmc_info", i915_dmc_info, 0},
{"i915_display_info", i915_display_info, 0},
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8b9e5b042e70..7938906f5b1d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2873,7 +2873,7 @@ static int intel_runtime_suspend(struct device *kdev)
struct pci_dev *pdev = to_pci_dev(kdev);
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = to_i915(dev);
- struct i915_runtime_pm *rpm = &dev_priv->runtime_pm;
+ struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
int ret;
if (WARN_ON_ONCE(!(dev_priv->gt_pm.rc6.enabled && HAS_RC6(dev_priv
@@ -2972,7 +2972,7 @@ static int intel_runtime_resume(struct device *kdev)
struct pci_dev *pdev = to_pci_dev(kdev);
struct drm_device *dev = pci_get_drvdata(pdev);
struct drm_i915_private *dev_priv = to_i915(dev);
- struct i915_runtime_pm *rpm = &dev_priv->runtime_pm;
+ struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
int ret = 0;
if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev_priv)))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 474074c7f395..195ba437835f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1152,56 +1152,6 @@ struct skl_wm_params {
u32 dbuf_block_size;
};
-/*
- * This struct helps tracking the state needed for runtime PM, which puts the
- * device in PCI D3 state. Notice that when this happens, nothing on the
- * graphics device works, even register access, so we don't get interrupts nor
- * anything else.
- *
- * Every piece of our code that needs to actually touch the hardware needs to
- * either call intel_runtime_pm_get or call intel_display_power_get with the
- * appropriate power domain.
- *
- * Our driver uses the autosuspend delay feature, which means we'll only really
- * suspend if we stay with zero refcount for a certain amount of time. The
- * default value is currently very conservative (see intel_runtime_pm_enable),
but
- * it can be changed with the standard runtime PM files from sysfs.
- *
- * The irqs_disabled variable becomes true exactly after we disable the IRQs
and
- * goes back to false exactly before we reenable the IRQs. We use this variable
- * to check if someone is trying to enable/disable IRQs while they're supposed
- * to be disabled. This shouldn't happen and we'll print some error messages in
- * case it happens.
- *
- * For more, read the Documentation/power/runtime_pm.txt.
- */
-struct i915_runtime_pm {
- atomic_t wakeref_count;
- struct device *kdev;
- bool available;
- bool suspended;
- bool irqs_enabled;
-
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
- /*
-* To aide detection of wakeref leaks and general misuse, we
-* track all wakeref holders. With manual markup (i.e. returning
-* a cookie to each rpm_get caller which they then supply to their
-* paired rpm_put) we can remove corresponding pairs of and keep
-* the array trimmed to active wakerefs.
-*/
- struct i
[Intel-gfx] [RFC 7/7] drm/i915: update with_intel_runtime_pm to use the rpm structure
Matching the underlying get/put functions.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 24 +--
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++
drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 +++
drivers/gpu/drm/i915/i915_pmu.c | 3 ++-
drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
drivers/gpu/drm/i915/intel_guc_log.c | 6 ++---
drivers/gpu/drm/i915/intel_huc.c | 2 +-
drivers/gpu/drm/i915/intel_panel.c| 2 +-
drivers/gpu/drm/i915/intel_pm.c | 8 +++
drivers/gpu/drm/i915/intel_runtime_pm.h | 12 +-
drivers/gpu/drm/i915/intel_uc.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem.c | 6 ++---
.../gpu/drm/i915/selftests/i915_gem_context.c | 6 ++---
.../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
21 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5b31e1e05ddd..21892683a804 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -52,7 +52,7 @@ int __intel_context_do_pin(struct intel_context *ce)
intel_wakeref_t wakeref;
err = 0;
- with_intel_runtime_pm(ce->engine->i915, wakeref)
+ with_intel_runtime_pm(&ce->engine->i915->runtime_pm, wakeref)
err = ce->ops->pin(ce);
if (err)
goto err;
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ad943810eded..4e0a56c36a2a 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -849,7 +849,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_wakeref_t wakeref;
mutex_lock(&error->wedge_mutex);
- with_intel_runtime_pm(i915, wakeref)
+ with_intel_runtime_pm(&i915->runtime_pm, wakeref)
__i915_gem_set_wedged(i915);
mutex_unlock(&error->wedge_mutex);
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index 6c1db2e403ba..1669f0016893 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -246,7 +246,7 @@ switch_to_scratch_context(struct intel_engine_cs *engine,
GEM_BUG_ON(i915_gem_context_is_bannable(ctx));
rq = ERR_PTR(-ENODEV);
- with_intel_runtime_pm(engine->i915, wakeref)
+ with_intel_runtime_pm(&engine->i915->runtime_pm, wakeref)
rq = igt_spinner_create_request(spin, ctx, engine, MI_NOOP);
kernel_context_close(ctx);
@@ -302,7 +302,7 @@ static int check_whitelist_across_reset(struct
intel_engine_cs *engine,
if (err)
goto out;
- with_intel_runtime_pm(i915, wakeref)
+ with_intel_runtime_pm(&i915->runtime_pm, wakeref)
err = reset(engine);
igt_spinner_end(&spin);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e58a0152b25f..4e8cd1e01e57 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -976,7 +976,7 @@ static int i915_gpu_info_open(struct inode *inode, struct
file *file)
intel_wakeref_t wakeref;
gpu = NULL;
- with_intel_runtime_pm(i915, wakeref)
+ with_intel_runtime_pm(&i915->runtime_pm, wakeref)
gpu = i915_capture_gpu_state(i915);
if (IS_ERR(gpu))
return PTR_ERR(gpu);
@@ -1303,7 +1303,7 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
return 0;
}
- with_intel_runtime_pm(dev_priv, wakeref) {
+ with_intel_runtime_pm(&dev_priv->runtime_pm, wakeref) {
for_each_engine(engine, dev_priv, id)
acthd[id] = intel_engine_get_active_head(engine);
@@ -1562,7 +1562,7 @@ static int i915_drpc_info(struct seq_file *m, void
*unused)
intel_wakeref_t wakeref;
int err = -ENODEV;
- with_intel_runtime_pm(dev_priv, wakeref) {
+ with_intel_runtime_pm(&dev_priv->runtime_pm, wakeref) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
err = vlv_drpc_info(m);
else if (INTEL_GEN(dev_priv) >= 6)
@@ -1729,7 +1729,7 @@ static int i915_emon_status(struct seq_file *m, void
*unused)
if (!IS_GEN(i915, 5))
[Intel-gfx] [RFC 5/7] drm/i915: move a few more functions to accept the rpm structure
Focusing on the functions called in few places.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 17 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 19 ---
drivers/gpu/drm/i915/intel_runtime_pm.h | 12 ++--
.../gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
5 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 227a1cdf4f02..011537632c4f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2663,7 +2663,7 @@ static int intel_runtime_pm_status(struct seq_file *m,
void *unused)
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)) {
struct drm_printer p = drm_seq_file_printer(m);
- print_intel_runtime_pm_wakeref(dev_priv, &p);
+ print_intel_runtime_pm_wakeref(&dev_priv->runtime_pm, &p);
}
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7938906f5b1d..4ce41083313b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -903,7 +903,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
mutex_init(&dev_priv->hdcp_comp_mutex);
i915_memcpy_init_early(dev_priv);
- intel_runtime_pm_init_early(dev_priv);
+ intel_runtime_pm_init_early(&dev_priv->runtime_pm);
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
@@ -1746,7 +1746,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
drm_kms_helper_poll_init(dev);
intel_power_domains_enable(dev_priv);
- intel_runtime_pm_enable(dev_priv);
+ intel_runtime_pm_enable(&dev_priv->runtime_pm);
}
/**
@@ -1755,7 +1755,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
- intel_runtime_pm_disable(dev_priv);
+ intel_runtime_pm_disable(&dev_priv->runtime_pm);
intel_power_domains_disable(dev_priv);
intel_fbdev_unregister(dev_priv);
@@ -1967,7 +1967,7 @@ void i915_driver_unload(struct drm_device *dev)
i915_driver_cleanup_mmio(dev_priv);
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
- intel_runtime_pm_cleanup(dev_priv);
+ intel_runtime_pm_cleanup(&dev_priv->runtime_pm);
}
static void i915_driver_release(struct drm_device *dev)
@@ -2121,9 +2121,10 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct intel_runtime_pm *rpm = &dev_priv->runtime_pm;
int ret;
- disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
+ disable_rpm_wakeref_asserts(rpm);
i915_gem_suspend_late(dev_priv);
@@ -2164,9 +2165,9 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
pci_set_power_state(pdev, PCI_D3hot);
out:
- enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
+ enable_rpm_wakeref_asserts(rpm);
if (!dev_priv->uncore.user_forcewake.count)
- intel_runtime_pm_cleanup(dev_priv);
+ intel_runtime_pm_cleanup(rpm);
return ret;
}
@@ -2928,7 +2929,7 @@ static int intel_runtime_suspend(struct device *kdev)
}
enable_rpm_wakeref_asserts(rpm);
- intel_runtime_pm_cleanup(dev_priv);
+ intel_runtime_pm_cleanup(rpm);
if (intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore))
DRM_ERROR("Unclaimed access detected prior to suspending\n");
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index f669688c32c9..3150dbe4d1c3 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -299,13 +299,12 @@ untrack_all_intel_runtime_pm_wakerefs(struct
intel_runtime_pm *rpm)
dump_and_free_wakeref_tracking(&dbg);
}
-void print_intel_runtime_pm_wakeref(struct drm_i915_private *i915,
+void print_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm,
struct drm_printer *p)
{
struct intel_runtime_pm_debug dbg = {};
do {
- struct intel_runtime_pm *rpm = &i915->runtime_pm;
unsigned long alloc = dbg.count;
depot_stack_handle_t *s;
@@ -5145,7 +5144,7 @@ void intel_runtime_pm_put(struct drm_i915_private *i915,
intel_wakeref_t wref)
/**
* intel_runtime_pm_enable - enable runtime pm
- * @i915: i915 device instance
+ * @rpm: the intel_runtime_pm structure
*
* This function enables runtime pm at the end of the driver load sequence.
*
@@ -5153,9 +5152,8 @@ void intel_runtime_pm_put(
[Intel-gfx] [RFC 6/7] drm/i915: update rpm_get/put to use the rpm structure
The functions are internally already only using the structure, so we
need to just flip the interface.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +--
drivers/gpu/drm/i915/gt/intel_hangcheck.c | 4 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 20
drivers/gpu/drm/i915/gt/selftest_lrc.c| 36 +++---
.../gpu/drm/i915/gt/selftest_workarounds.c| 12 ++---
drivers/gpu/drm/i915/gvt/aperture_gm.c| 15 +++---
drivers/gpu/drm/i915/gvt/gvt.h| 4 +-
drivers/gpu/drm/i915/gvt/sched_policy.c | 4 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 49 ++-
drivers/gpu/drm/i915/i915_gem.c | 26 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 4 +-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 6 +--
drivers/gpu/drm/i915/i915_pmu.c | 8 +--
drivers/gpu/drm/i915/i915_sysfs.c | 12 ++---
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_fbdev.c| 6 +--
drivers/gpu/drm/i915/intel_hotplug.c | 4 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 48 +-
drivers/gpu/drm/i915/intel_runtime_pm.h | 22 -
drivers/gpu/drm/i915/intel_wakeref.c | 4 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 8 +--
drivers/gpu/drm/i915/selftests/i915_gem.c | 4 +-
.../drm/i915/selftests/i915_gem_coherency.c | 4 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 12 ++---
.../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 8 +--
.../gpu/drm/i915/selftests/i915_gem_object.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 20
.../gpu/drm/i915/selftests/i915_timeline.c| 16 +++---
drivers/gpu/drm/i915/selftests/intel_guc.c| 8 +--
drivers/gpu/drm/i915/selftests/intel_uncore.c | 4 +-
35 files changed, 201 insertions(+), 203 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4c3753c1b573..26f3b68ab7d6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1059,7 +1059,7 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
return true;
/* If the whole device is asleep, the engine must be idle */
- wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
+ wakeref = intel_runtime_pm_get_if_in_use(&dev_priv->runtime_pm);
if (!wakeref)
return true;
@@ -1073,7 +1073,7 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
!(ENGINE_READ(engine, RING_MI_MODE) & MODE_IDLE))
idle = false;
- intel_runtime_pm_put(dev_priv, wakeref);
+ intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
return idle;
}
@@ -1487,10 +1487,10 @@ void intel_engine_dump(struct intel_engine_cs *engine,
rcu_read_unlock();
- wakeref = intel_runtime_pm_get_if_in_use(engine->i915);
+ wakeref = intel_runtime_pm_get_if_in_use(&engine->i915->runtime_pm);
if (wakeref) {
intel_engine_print_registers(engine, m);
- intel_runtime_pm_put(engine->i915, wakeref);
+ intel_runtime_pm_put(&engine->i915->runtime_pm, wakeref);
} else {
drm_printf(m, "\tDevice is asleep; skipping register dump\n");
}
diff --git a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
index 3a4d09b80fa0..d5a76b66b91b 100644
--- a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
@@ -273,7 +273,7 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
if (i915_terminally_wedged(dev_priv))
return;
- wakeref = intel_runtime_pm_get_if_in_use(dev_priv);
+ wakeref = intel_runtime_pm_get_if_in_use(&dev_priv->runtime_pm);
if (!wakeref)
return;
@@ -324,7 +324,7 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
if (hung)
hangcheck_declare_hang(dev_priv, hung, stuck);
- intel_runtime_pm_put(dev_priv, wakeref);
+ intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
/* Reset timer in case GPU hangs without another request being added */
i915_queue_hangcheck(dev_priv);
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 464369bc55ad..ad943810eded 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -1242,7 +1242,7 @@ void i915_handle_error(struct drm_i915_private *i915,
* isn't the case at l
Re: [Intel-gfx] [RFC 4/7] drm/i915: move and rename i915_runtime_pm
Quoting Chris Wilson (2019-05-16 23:07:43) > Quoting Daniele Ceraolo Spurio (2019-05-16 22:56:31) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h > > b/drivers/gpu/drm/i915/intel_runtime_pm.h > > index b964ca7af9c8..0e3817f9785e 100644 > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.h > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h > > @@ -6,6 +6,7 @@ > > #ifndef __INTEL_RUNTIME_PM_H__ > > #define __INTEL_RUNTIME_PM_H__ > > > > +#include > > There doesn't seem to be any peeking into struct device, so do we not > just need the struct device forward decl here? And add it to Makefile.headers_test -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: move and rename i915_runtime_pm
Quoting Daniele Ceraolo Spurio (2019-05-16 22:56:31) > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h > b/drivers/gpu/drm/i915/intel_runtime_pm.h > index b964ca7af9c8..0e3817f9785e 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.h > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h > @@ -6,6 +6,7 @@ > #ifndef __INTEL_RUNTIME_PM_H__ > #define __INTEL_RUNTIME_PM_H__ > > +#include There doesn't seem to be any peeking into struct device, so do we not just need the struct device forward decl here? > #include > #include ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Runtime PM encapsulation
== Series Details == Series: Runtime PM encapsulation URL : https://patchwork.freedesktop.org/series/60751/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6abe6de9d69c drm/i915: prefer i915_runtime_pm in intel_runtime function 459ce16ea796 drm/i915: Remove rpm asserts that use i915 3786ba59fb44 drm/i915: make enable/disable rpm assert function use the rpm structure f9fd0f317814 drm/i915: move and rename i915_runtime_pm -:527: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #527: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:62: + spinlock_t lock; total: 0 errors, 0 warnings, 1 checks, 585 lines checked 5fade456b0bf drm/i915: move a few more functions to accept the rpm structure 14c3a5f20ed6 drm/i915: update rpm_get/put to use the rpm structure 2701026b6f98 drm/i915: update with_intel_runtime_pm to use the rpm structure -:399: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'rpm' - possible side-effects? #399: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:253: +#define with_intel_runtime_pm(rpm, wf) \ + for ((wf) = intel_runtime_pm_get(rpm); (wf); \ +intel_runtime_pm_put((rpm), (wf)), (wf) = 0) -:399: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects? #399: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:253: +#define with_intel_runtime_pm(rpm, wf) \ + for ((wf) = intel_runtime_pm_get(rpm); (wf); \ +intel_runtime_pm_put((rpm), (wf)), (wf) = 0) -:406: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'rpm' - possible side-effects? #406: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:257: +#define with_intel_runtime_pm_if_in_use(rpm, wf) \ + for ((wf) = intel_runtime_pm_get_if_in_use(rpm); (wf); \ +intel_runtime_pm_put((rpm), (wf)), (wf) = 0) -:406: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects? #406: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:257: +#define with_intel_runtime_pm_if_in_use(rpm, wf) \ + for ((wf) = intel_runtime_pm_get_if_in_use(rpm); (wf); \ +intel_runtime_pm_put((rpm), (wf)), (wf) = 0) total: 0 errors, 0 warnings, 4 checks, 396 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Runtime PM encapsulation
== Series Details == Series: Runtime PM encapsulation URL : https://patchwork.freedesktop.org/series/60751/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: prefer i915_runtime_pm in intel_runtime function Okay! Commit: drm/i915: Remove rpm asserts that use i915 Okay! Commit: drm/i915: make enable/disable rpm assert function use the rpm structure Okay! Commit: drm/i915: move and rename i915_runtime_pm Okay! Commit: drm/i915: move a few more functions to accept the rpm structure Okay! Commit: drm/i915: update rpm_get/put to use the rpm structure -O:drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'i915_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'i915_reset_trylock' - different lock contexts for basic block Commit: drm/i915: update with_intel_runtime_pm to use the rpm structure Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Expand subslice mask
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -9,16 +9,18 @@
#include
#include
+#include
AFAICS this header is not needed anymore. With it removed:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
struct drm_i915_private;
#define GEN_MAX_SLICES (6) /* CNL upper bound */
#define GEN_MAX_SUBSLICES (8) /* ICL upper bound */
#define GEN_SSEU_STRIDE(max_entries) DIV_ROUND_UP(max_entries, BITS_PER_BYTE)
+#define GEN_MAX_SUBSLICE_STRIDE GEN_SSEU_STRIDE(GEN_MAX_SUBSLICES)
struct sseu_dev_info {
u8 slice_mask;
- u8 subslice_mask[GEN_MAX_SLICES];
+ u8 subslice_mask[GEN_MAX_SLICES * GEN_MAX_SUBSLICE_STRIDE];
u16 eu_total;
u8 eu_per_subslice;
u8 min_eu_in_pool;
@@ -33,6 +35,9 @@ struct sseu_dev_info {
u8 max_subslices;
u8 max_eus_per_subslice;
+ u8 ss_stride;
+ u8 eu_stride;
+
/* We don't have more than 8 eus per subslice at the moment and as we
* store eus enabled using bits, no need to multiply by eus per
* subslice.
@@ -63,12 +68,33 @@ intel_sseu_from_device_info(const struct sseu_dev_info
*sseu)
return value;
}
+static inline bool
+intel_sseu_has_subslice(const struct sseu_dev_info *sseu, int slice,
+ int subslice)
+{
+ u8 mask = sseu->subslice_mask[slice * sseu->ss_stride +
+ subslice / BITS_PER_BYTE];
+
+ return mask & BIT(subslice % BITS_PER_BYTE);
+}
+
+void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices,
+u8 max_subslices, u8 max_eus_per_subslice);
+
unsigned int
intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
unsigned int
intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice);
+void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu, int slice,
+ u8 *to_mask);
+
+u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice);
+
+void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
+ u32 ss_mask);
+
u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
const struct intel_sseu *req_sseu);
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 43e290306551..8437f9d918ec 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -767,7 +767,7 @@ wa_init_mcr(struct drm_i915_private *i915, struct
i915_wa_list *wal)
u32 slice = fls(sseu->slice_mask);
u32 fuse3 =
intel_uncore_read(&i915->uncore, GEN10_MIRROR_FUSE3);
- u8 ss_mask = sseu->subslice_mask[slice];
+ u32 ss_mask = intel_sseu_get_subslices(sseu, slice);
u8 enabled_mask = (ss_mask | ss_mask >>
GEN10_L3BANK_PAIR_COUNT) & GEN10_L3BANK_MASK;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a26015722405..46365ab957e6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1259,6 +1259,7 @@ static void i915_instdone_info(struct drm_i915_private
*dev_priv,
struct seq_file *m,
struct intel_instdone *instdone)
{
+ struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
int slice;
int subslice;
@@ -1274,11 +1275,11 @@ static void i915_instdone_info(struct drm_i915_private *dev_priv,
if (INTEL_GEN(dev_priv) <= 6)
return;
- for_each_instdone_slice_subslice(dev_priv, slice, subslice)
+ for_each_instdone_slice_subslice(dev_priv, sseu, slice, subslice)
seq_printf(m, "\t\tSAMPLER_INSTDONE[%d][%d]: 0x%08x\n",
slice, subslice, instdone->sampler[slice][subslice]);
- for_each_instdone_slice_subslice(dev_priv, slice, subslice)
+ for_each_instdone_slice_subslice(dev_priv, sseu, slice, subslice)
seq_printf(m, "\t\tROW_INSTDONE[%d][%d]: 0x%08x\n",
slice, subslice, instdone->row[slice][subslice]);
}
@@ -4072,7 +4073,7 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
continue;
sseu->slice_mask |= BIT(s);
- sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
+ intel_sseu_copy_subslices(&info->sseu, s, sseu->subslice_mask);
for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
@@ -4123,18 +4124,21 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
if (IS_GEN9_BC(dev_priv))
- sseu->subslice_mask[s] =
- RUNTIME_INFO(dev_
Re: [Intel-gfx] [RFC 4/7] drm/i915: move and rename i915_runtime_pm
Quoting Chris Wilson (2019-05-16 23:10:10) > Quoting Chris Wilson (2019-05-16 23:07:43) > > Quoting Daniele Ceraolo Spurio (2019-05-16 22:56:31) > > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h > > > b/drivers/gpu/drm/i915/intel_runtime_pm.h > > > index b964ca7af9c8..0e3817f9785e 100644 > > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.h > > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h > > > @@ -6,6 +6,7 @@ > > > #ifndef __INTEL_RUNTIME_PM_H__ > > > #define __INTEL_RUNTIME_PM_H__ > > > > > > +#include > > > > There doesn't seem to be any peeking into struct device, so do we not > > just need the struct device forward decl here? > > And add it to Makefile.headers_test Hint: we may need to split out intel_display_power.[ch] -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Runtime PM encapsulation
== Series Details ==
Series: Runtime PM encapsulation
URL : https://patchwork.freedesktop.org/series/60751/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6091 -> Patchwork_13028
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_13028 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_13028, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_13028:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@basic-rte:
- fi-hsw-peppy: [PASS][1] -> [FAIL][2] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-hsw-peppy/igt@i915_pm_...@basic-rte.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-hsw-peppy/igt@i915_pm_...@basic-rte.html
Known issues
Here are the changes found in Patchwork_13028 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_basic@basic-blt:
- fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] /
[fdo#110246])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-icl-u2/igt@gem_exec_ba...@basic-blt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-icl-u2/igt@gem_exec_ba...@basic-blt.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_guc:
- fi-apl-guc: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-apl-guc/igt@i915_selftest@live_guc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-apl-guc/igt@i915_selftest@live_guc.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][9] -> [INCOMPLETE][10] ([fdo#108602] /
[fdo#108744])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
- fi-apl-guc: [PASS][11] -> [DMESG-FAIL][12] ([fdo#110620])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][13] ([fdo#108511]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][15] ([fdo#110235]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][17] ([fdo#102614]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [DMESG-WARN][19] ([fdo#106387]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13028/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108
[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "ICL HACK: Disable ACPI idle driver"
== Series Details == Series: Revert "ICL HACK: Disable ACPI idle driver" URL : https://patchwork.freedesktop.org/series/60731/ State : success == Summary == CI Bug Log - changes from CI_DRM_6091_full -> Patchwork_13026_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13026_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108] / [fdo#107773]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl8/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-skl3/igt@gem_...@in-flight-suspend.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#103167]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#108145] / [fdo#110403]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103166]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-x.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#108341]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb7/igt@kms_psr@no_drrs.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_no_drrs: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb2/igt@kms_psr@psr2_no_drrs.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-iclb7/igt@kms_psr@psr2_no_drrs.html * igt@tools_test@tools_test: - shard-skl: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl6/igt@tools_test@tools_test.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-skl8/igt@tools_test@tools_test.html Possible fixes * igt@i915_pm_rpm@gem-mmap-gtt: - shard-iclb: [INCOMPLETE][17] ([fdo#107713] / [fdo#108840]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb7/igt@i915_pm_...@gem-mmap-gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-iclb8/igt@i915_pm_...@gem-mmap-gtt.html * igt@i915_pm_rpm@reg-read-ioctl: - shard-skl: [INCOMPLETE][19] ([fdo#107807]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl5/igt@i915_pm_...@reg-read-ioctl.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-skl9/igt@i915_pm_...@reg-read-ioctl.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [INCOMPLETE][21] ([fdo#104108] / [fdo#107807]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl5/igt@i915_pm_...@system-suspend-execbuf.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-skl3/igt@i915_pm_...@system-suspend-execbuf.html * igt@i915_suspend@forcewake: - shard-skl: [INCOMPLETE][23] ([fdo#104108] / [fdo#107773]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl9/igt@i915_susp...@forcewake.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13026/shard-skl5/igt@i915_susp...@forcewake.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-iclb: [FAIL][25] ([fdo#103167]) -> [PASS][26] +2 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb2/igt@kms_frontbuffer_trac
Re: [Intel-gfx] [PATCH] drm/i915: Engine relative MMIO
On 5/15/2019 01:52, Tvrtko Ursulin wrote:
On 13/05/2019 20:45, john.c.harri...@intel.com wrote:
From: John Harrison
With virtual engines, it is no longer possible to know which specific
physical engine a given request will be executed on at the time that
request is generated. This means that the request itself must be engine
agnostic - any direct register writes must be relative to the engine
and not absolute addresses.
The LRI command has support for engine relative addressing. However,
the mechanism is not transparent to the driver. The scheme for Gen11
(MI_LRI_ADD_CS_MMIO_START) requires the LRI address to have no
absolute engine base component. The hardware then adds on the correct
engine offset at execution time.
Due to the non-trivial and differing schemes on different hardware, it
is not possible to simply update the code that creates the LRI
commands to set a remap flag and let the hardware get on with it.
Instead, this patch adds function wrappers for generating the LRI
command itself and then for constructing the correct address to use
with the LRI.
v2: Fix build break in GVT. Remove flags parameter [review feedback
from Chris W].
v3: Fix build break in selftest. Rebase to newer base tree and fix
merge conflict.
v4: More rebasing. Rmoved relative addressing support from Gen7-9 only
code paths [review feedback from Chris W].
v5: More rebasing (new 'gt' directory). Fix white space issue. Use
COPY class rather than BCS0 id for checking against BCS engine.
Signed-off-by: John Harrison
CC: Rodrigo Vivi
CC: Tvrtko Ursulin
CC: Wilson, Chris P
---
drivers/gpu/drm/i915/gt/intel_engine.h | 4 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 11 +++
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 6 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 79 ++-
drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 4 +-
drivers/gpu/drm/i915/gt/intel_mocs.c | 17 ++--
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 45 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 +-
.../gpu/drm/i915/gt/selftest_workarounds.c | 9 ++-
drivers/gpu/drm/i915/gvt/mmio_context.c | 16 +++-
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +-
drivers/gpu/drm/i915/i915_gem_context.c | 12 +--
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +-
drivers/gpu/drm/i915/i915_perf.c | 19 +++--
14 files changed, 154 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 9359b3a7ad9c..3506c992182c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -546,4 +546,8 @@ static inline bool inject_preempt_hang(struct
intel_engine_execlists *execlists)
#endif
+bool i915_engine_has_relative_lri(const struct intel_engine_cs
*engine);
+u32 i915_get_lri_cmd(const struct intel_engine_cs *engine, u32
word_count);
+u32 i915_get_lri_reg(const struct intel_engine_cs *engine,
i915_reg_t reg);
+
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4c3753c1b573..233295d689d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -253,6 +253,17 @@ static u32 __engine_mmio_base(struct
drm_i915_private *i915,
return bases[i].base;
}
+bool i915_engine_has_relative_lri(const struct intel_engine_cs
*engine)
+{
+ if (INTEL_GEN(engine->i915) < 11)
+ return false;
+
+ if (engine->class == COPY_ENGINE_CLASS)
+ return false;
+
+ return true;
I think engine->flags would be better. At least it is one conditional
instead of two at runtime, even one too many for something that is
invariant.
+}
+
static void __sprint_engine_name(char *name, const struct
engine_info *info)
{
WARN_ON(snprintf(name, INTEL_ENGINE_CS_MAX_NAME, "%s%u",
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index a34ece53a771..e7784b3fb759 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -123,9 +123,13 @@
* simply ignores the register load under certain conditions.
* - One can actually load arbitrary many arbitrary registers:
Simply issue x
* address/value pairs. Don't overdue it, though, x <= 2^4 must
hold!
+ * - Newer hardware supports engine relative addresses but older
hardware does
+ * not. So never call MI_LRI directly, always use the
i915_get_lri_cmd()
+ * and i915_get_lri_reg() helper functions.
*/
-#define MI_LOAD_REGISTER_IMM(x) MI_INSTR(0x22, 2*(x)-1)
+#define __MI_LOAD_REGISTER_IMM(x) MI_INSTR(0x22, 2*(x)-1)
So we end up with code using __MI_LOAD_REGISTER_IMM for absolute, and
i915_get_lri_cmd for relative addressing. One is a macro, another is a
function call, and naming/case is different.
No. The _
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [RFC,1/3] kbuild: add support for ensuring headers are self-contained
== Series Details == Series: series starting with [RFC,1/3] kbuild: add support for ensuring headers are self-contained URL : https://patchwork.freedesktop.org/series/60738/ State : success == Summary == CI Bug Log - changes from CI_DRM_6091_full -> Patchwork_13027_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13027_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][1] -> [FAIL][2] ([fdo#105363]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-glk9/igt@kms_f...@flip-vs-expired-vblank.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-glk9/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw: - shard-iclb: [PASS][3] -> [FAIL][4] ([fdo#103167]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#108145] / [fdo#110403]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][7] -> [FAIL][8] ([fdo#103166]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-y.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-iclb1/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#108341]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb7/igt@kms_psr@no_drrs.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_no_drrs: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb2/igt@kms_psr@psr2_no_drrs.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-iclb7/igt@kms_psr@psr2_no_drrs.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([fdo#108566]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-apl1/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-apl8/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-kbl1/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-kbl7/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html Possible fixes * igt@i915_pm_rpm@gem-mmap-gtt: - shard-iclb: [INCOMPLETE][17] ([fdo#107713] / [fdo#108840]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb7/igt@i915_pm_...@gem-mmap-gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-iclb6/igt@i915_pm_...@gem-mmap-gtt.html * igt@i915_pm_rpm@reg-read-ioctl: - shard-skl: [INCOMPLETE][19] ([fdo#107807]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl5/igt@i915_pm_...@reg-read-ioctl.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-skl3/igt@i915_pm_...@reg-read-ioctl.html * igt@i915_suspend@forcewake: - shard-skl: [INCOMPLETE][21] ([fdo#104108] / [fdo#107773]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-skl9/igt@i915_susp...@forcewake.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-skl3/igt@i915_susp...@forcewake.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-iclb: [FAIL][23] ([fdo#103167]) -> [PASS][24] +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6091/shard-iclb2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13027/shard-iclb5/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-apl: [DMESG-WARN][25] ([fdo#108566]) -> [PASS][26] +1 similar issue [25]: https://intel-gfx-ci.01
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for CI: Revert "net/sch_generic: Shut up noise"
On Thu, May 16, 2019 at 08:48:53AM -, Patchwork wrote: > == Series Details == > > Series: CI: Revert "net/sch_generic: Shut up noise" > URL : https://patchwork.freedesktop.org/series/60699/ > State : success Hm no boom at all, I'll try the full revert and see what happens. Maybe we hit a few more igt@aborted ... -Daniel > > == Summary == > > CI Bug Log - changes from CI_DRM_6089_full -> Patchwork_13024_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_13024_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_isolation@vcs1-s3: > - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl3/igt@gem_ctx_isolat...@vcs1-s3.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-kbl7/igt@gem_ctx_isolat...@vcs1-s3.html > > * igt@gem_tiled_swapping@non-threaded: > - shard-hsw: [PASS][3] -> [FAIL][4] ([fdo#108686]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-hsw7/igt@gem_tiled_swapp...@non-threaded.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-hsw5/igt@gem_tiled_swapp...@non-threaded.html > > * igt@gem_workarounds@suspend-resume-context: > - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +4 > similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-apl7/igt@gem_workarou...@suspend-resume-context.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-apl7/igt@gem_workarou...@suspend-resume-context.html > > * igt@i915_pm_rpm@dpms-lpsp: > - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#107807]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-skl10/igt@i915_pm_...@dpms-lpsp.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-skl10/igt@i915_pm_...@dpms-lpsp.html > > * igt@kms_flip_tiling@flip-x-tiled: > - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#108303]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb7/igt@kms_flip_til...@flip-x-tiled.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-iclb4/igt@kms_flip_til...@flip-x-tiled.html > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: > - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar > issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html > > * igt@kms_psr@psr2_sprite_plane_move: > - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +3 similar > issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html > > * igt@kms_setmode@basic: > - shard-kbl: [PASS][15] -> [FAIL][16] ([fdo#99912]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl2/igt@kms_setm...@basic.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-kbl2/igt@kms_setm...@basic.html > > * igt@perf_pmu@rc6: > - shard-kbl: [PASS][17] -> [SKIP][18] ([fdo#109271]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl6/igt@perf_...@rc6.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-kbl7/igt@perf_...@rc6.html > > > Possible fixes > > * igt@gem_ctx_isolation@bcs0-s3: > - shard-kbl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-kbl7/igt@gem_ctx_isolat...@bcs0-s3.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-kbl3/igt@gem_ctx_isolat...@bcs0-s3.html > > * igt@gem_tiled_swapping@non-threaded: > - shard-iclb: [FAIL][21] ([fdo#108686]) -> [PASS][22] >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-iclb5/igt@gem_tiled_swapp...@non-threaded.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/shard-iclb8/igt@gem_tiled_swapp...@non-threaded.html > > * igt@i915_pm_rpm@basic-rte: > - shard-skl: [INCOMPLETE][23] ([fdo#107807]) -> [PASS][24] +1 > similar issue >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6089/shard-skl3/igt@i915_pm_...@basic-rte.html >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13024/sh
[Intel-gfx] [PATCH] C: Revert "net/sch_generic: Shut up noise"
This reverts commit a9f840bdd2fd4cb07a669f1c3112b804218b4aba.
A quick test patch didn't seem to have hit this, so let's try what
happens when we reinstate the full WARNING again.
Cc: Martin Peres
---
net/sched/sch_generic.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index cf96149d7b5e..a117d9260558 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -456,12 +456,7 @@ static void dev_watchdog(struct timer_list *t)
}
}
- /* The noise is pissing off our CI and upstream doesn't
-* move on the bug report:
-*
-* https://bugzilla.kernel.org/show_bug.cgi?id=196399
-*/
- if (some_queue_timedout && 0) {
+ if (some_queue_timedout) {
WARN_ONCE(1, KERN_INFO "NETDEV WATCHDOG: %s
(%s): transmit queue %u timed out\n",
dev->name, netdev_drivername(dev), i);
dev->netdev_ops->ndo_tx_timeout(dev);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
