Re: [Intel-gfx] [v5 01/13] drm: Add HDR source metadata property
Hello Uma,
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma
> Subject: [v5 01/13] 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.
>
> 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.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_connector.c | 6 ++
> include/drm/drm_connector.h | 10 ++
> include/drm/drm_mode_config.h | 6 ++
> include/linux/hdmi.h| 10 ++
> include/uapi/drm/drm_mode.h | 16
> 5 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 07d65a1..b031079 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1054,6 +1054,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);
Needs alignment with the line above.
> + 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
> c806199..29388bd 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -561,6 +561,13 @@ struct drm_connector_state {
>* and the connector bpc limitations obtained from edid.
>*/
> u8 max_bpc;
> +
> + /**
> + * @metadata_blob_ptr:
> + * DRM blob property for HDR output metadata
> + */
> + struct drm_property_blob *hdr_output_metadata_blob_ptr;
> + u8 hdr_metadata_changed : 1;
> };
>
> /**
> @@ -1201,6 +1208,9 @@ struct drm_connector {
>* &drm_mode_config.connector_free_work.
>*/
> struct llist_node free_node;
> +
> + /* HDR metdata */
> + struct hdr_static_metadata hdr_metadata;
I was under the assumption that we are not parsing the hdr_metadata from the
EDID, and the userspace needs to parse it from the EDID. If that's the case, we
might not even need this pointer. Are we even using this or am I missing
something here ?
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base) diff
> --git
> a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h index
> 7f60e8e..ef2656b 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -836,6 +836,12 @@ struct drm_mode_config {
>*/
> struct drm_property *writeback_out_fence_ptr_property;
>
> + /*
> + * hdr_metadata_property: Connector property containing hdr metatda
> + * This will be provided by userspace compositors based on HDR content
> + */
> + struct drm_property *hdr_output_metadata_property;
> +
> /* dumb ioctl parameters */
> uint32_t preferred_depth, prefer_shadow;
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index
> 927ad64..a065194
> 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -152,6 +152,16 @@ enum hdmi_content_type {
> HDMI_CONTENT_TYPE_GAME,
> };
>
> +enum hdmi_metadata_type {
> + HDMI_STATIC_METADATA_TYPE1 = 1,
> +};
> +
> +enum hdmi_eotf {
> + HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
> + HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
> + HDMI_EOTF_SMPTE_ST2084,
> +};
> +
> struct hdmi_avi_infoframe {
> enum hdmi_infoframe_type type;
> unsigned char version;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index
> a439c2e..5012af2 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -630,6 +630,22 @@ struct drm_color_lut {
> __u16 reserved;
> };
>
> +/* HDR Metadata */
> +struct hdr_static_metadata {
> + uint8_t eotf;
> + uint8_t metadata_type;
> + struct {
> + uint16_t x, y;
> + } display_primaries[3];
> + struct {
> + uint16_t x, y;
> + } white_point;
> + uint16_t max_mastering_display_luminance;
> + uint16_t min_mastering_display_luminance;
> + uint16_t max_fall;
> + uint16_t max_cll;
> +};
> +
- Shashank
> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://
Re: [Intel-gfx] [PATCH] drm/i915: Drop platform_mask
On 15/03/2019 06:56, Tvrtko Ursulin wrote: On 15/03/2019 00:52, Chris Wilson wrote: Quoting José Roberto de Souza (2019-03-15 00:42:35) We don't have any platform that is composed by 2 or more platforms so we don't need a mask, lets drop it and remove the actual limit of 32 platforms. Platform mask was a nifty trick to compile tests like IS_SKYLAKE || IS_BROADWELL etc into a single conditional. gcc doesn't entirely agree, this is a net loss here (i.e. code size increases). Perhaps the size re-gain of dropping the platform mask could be checked against the size gain of making the mask 64 bit. One possible alternative could be splitting the 64-bit platform mask into two 32-bit dwords. Like: u32 platform_mask[2]; #define IS_PLATFORM(p) (platform_mask[p / 32] & BIT(p % 32)) And a bit of jigging the enum space so that we don't end up with something often tested together on the dword boundary. In fact I had a prototype many months ago which went a step further and interleaved platform with gen mask, in some sized chunks, so even IS_PLATFORM || IS_GEN checks could be merged. This included the sub-platform thing as well with the ULT/ULX/LP stuff I think.. maybe I need to dig this out to see how it worked. 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: bump platform_mask to u64
On Thu, Mar 14, 2019 at 5:19 PM Chris Wilson wrote: > > Quoting Lucas De Marchi (2019-03-15 00:13:31) > > With Elkhart Lake being added to the platforms we are almost on the edge > > of platforms that fits on this 32 bits mask. So bump it to 64 bits to > > have room for new ones. > > > > Cc: José Roberto de Souza > > Signed-off-by: Lucas De Marchi > > Since platform_mask exists as an optimisation for code size, it'll be > useful to track the impact of changes. code size? Moving to u64 for this mask would make almost no difference. Just checking here: $ size drivers/gpu/drm/i915/i915.o* text databssdechexfilename 1836757 40454 41761881387 1cb52b drivers/gpu/drm/i915/i915.o 1836533 40454 41761881163 1cb44b drivers/gpu/drm/i915/i915.o.old So... around 200 bytes. Lucas De Marchi > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 02/13] drm: Parse HDR metadata info from EDID
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma
> Subject: [v5 02/13] 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
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_edid.c | 52
> ++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 5f14253..c5a81b8 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2834,6 +2834,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> #define EXT_VIDEO_DATA_BLOCK_420 0x0E
> @@ -3581,6 +3582,12 @@ static int add_3d_struct_modes(struct drm_connector
> *connector, u16 structure, }
>
> static int
> +cea_db_payload_len_ext(const u8 *db)
> +{
> + return (db[0] & 0x1f) - 1;
You might have already checked with checkpatch, but can we cross check the
space before '-' ?
> +}
> +
> +static int
> cea_db_extended_tag(const u8 *db)
> {
> return db[1];
> @@ -3816,6 +3823,49 @@ 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)
same here, looks like we need spaces around !=, or may be this is due to my
mail client ?
> + 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) |
Again, space before the '|' sign, please excuse me if this is false alarm ...
> + 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) {
Shouldn't this variable go to line above ?
> + uint16_t len;
> +
> + len = cea_db_payload_len_ext(db);
> + connector->hdr_metadata.eotf = eotf_supported(db);
> + connector->hdr_metadata.metadata_type = hdr_metadata_type(db);
> +
> + if (len >= 5)
> + connector->hdr_metadata.max_fall = db[5];
> + if (len >= 4)
> + connector->hdr_metadata.max_cll = db[4]; }
This '}' certainly should not be here.
> +
> static void
> drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db) {
> @@
> -4443,6 +4493,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);
- Shashank
> }
> }
>
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop platform_mask
On Fri, Mar 15, 2019 at 12:13 AM Tvrtko Ursulin wrote: > > > On 15/03/2019 06:56, Tvrtko Ursulin wrote: > > > > On 15/03/2019 00:52, Chris Wilson wrote: > >> Quoting José Roberto de Souza (2019-03-15 00:42:35) > >>> We don't have any platform that is composed by 2 or more platforms so > >>> we don't need a mask, lets drop it and remove the actual limit of 32 > >>> platforms. > > > > Platform mask was a nifty trick to compile tests like IS_SKYLAKE || > > IS_BROADWELL etc into a single conditional. > > > >> gcc doesn't entirely agree, this is a net loss here (i.e. code size > >> increases). > > > > Perhaps the size re-gain of dropping the platform mask could be checked > > against the size gain of making the mask 64 bit. current: text databssdechexfilename 1836533 40454 41761881163 1cb44b drivers/gpu/drm/i915/i915.o.old 64 bit bitmask: 1836757 40454 41761881387 1cb52b drivers/gpu/drm/i915/i915.o no platform_mask: 1837591 40454 41761882221 1cb86d drivers/gpu/drm/i915/i915.o So current situation to "just use a number" we are talking about 1k here, which for me looks acceptable. Alternative is the 64-bit bitmask, with ~200 bytes. Lucas De Marchi > > One possible alternative could be splitting the 64-bit platform mask > into two 32-bit dwords. Like: > >u32 platform_mask[2]; > >#define IS_PLATFORM(p) (platform_mask[p / 32] & BIT(p % 32)) > > And a bit of jigging the enum space so that we don't end up with > something often tested together on the dword boundary. > > In fact I had a prototype many months ago which went a step further and > interleaved platform with gen mask, in some sized chunks, so even > IS_PLATFORM || IS_GEN checks could be merged. This included the > sub-platform thing as well with the ULT/ULX/LP stuff I think.. maybe I > need to dig this out to see how it worked. > > Regards, > > Tvrtko > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 03/13] drm: Parse Colorimetry data block from EDID
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, March 11, 2019 9:28 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Lankhorst, Maarten ; Syrjala, Ville
> ; Sharma, Shashank ;
> emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar,
> Uma
> Subject: [v5 03/13] drm: Parse Colorimetry data block from EDID
>
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from panel.
>
> v2: Rebase
>
> v3: No Change
>
> v4: Addressed Shashank's review comments. Updated colorimetry field to 16 bit
> as
> DCI-P3 got added in CEA 861-G spec, as pointed out by Shashank.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_edid.c | 26 ++
> include/drm/drm_connector.h | 3 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> c5a81b8..0470845 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2834,6 +2834,7 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> +#define COLORIMETRY_DATA_BLOCK 0x5
> #define HDR_STATIC_METADATA_BLOCK0x6
> #define USE_EXTENDED_TAG 0x07
> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00 @@ -3823,6 +3824,29 @@ static
> void fixup_detailed_cea_mode_clock(struct drm_display_mode *mode)
> mode->clock = clock;
> }
>
> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db) {
Same comment for the opening brace above ?
> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> + return false;
> +
> + if (db[1] != COLORIMETRY_DATA_BLOCK)
Space before '!' ?
> + return false;
> +
> + return true;
> +}
> +
> +static void
> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const
> +u8 *db) {
> + struct drm_hdmi_info *info = &connector->display_info.hdmi;
> + uint16_t len;
> +
> + len = cea_db_payload_len_ext(db);
> + /* As per CEA 861-G spec */
> + info->colorimetry = ((db[3] & (0x1 << 7)) << 1) | db[2]; }
This means we are setting the 15th bit for DCI-P3 then there is a gap of 7
bits, and then there are other bits. Do we want to make DCI-P3 as bit 8 ?
Anyways this can be differed for a discussion later.
> +
> +
> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db) {
> if (cea_db_tag(db) != USE_EXTENDED_TAG) @@ -4495,6 +4519,8 @@ static
> void drm_parse_cea_ext(struct drm_connector *connector,
> drm_parse_vcdb(connector, db);
> if (cea_db_is_hdmi_hdr_metadata_block(db))
> drm_parse_hdr_metadata_block(connector, db);
> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> + drm_parse_colorimetry_data_block(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
> 29388bd..94f926e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -206,6 +206,9 @@ struct drm_hdmi_info {
>
> /** @y420_dc_modes: bitmap of deep color support index */
> u8 y420_dc_modes;
> +
> + /* @colorimetry: bitmap of supported colorimetry modes */
> + u16 colorimetry;
- Shashank
> };
>
> /**
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 04/13] drm/i915: Attach HDR metadata property to connector
> -Original Message- > From: Shankar, Uma > Sent: Monday, March 11, 2019 9:28 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Lankhorst, Maarten ; Syrjala, Ville > ; Sharma, Shashank ; > emil.l.veli...@gmail.com; brian.star...@arm.com; liviu.du...@arm.com; Shankar, > Uma > Subject: [v5 04/13] 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 > --- > 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 cd422a7..0952475 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -2719,6 +2719,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); 'connector->dev' should be aligned to the line above, but seems like you have done this to meet the 80 char limit. May be a local ptr variable will help with 80 char. Apart from that, looks good to me, and feel free to use: Reviewed-by: Shashank Sharma > > 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] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/cml: Add CML PCI IDS
== Series Details ==
Series: series starting with [1/2] drm/i915/cml: Add CML PCI IDS
URL : https://patchwork.freedesktop.org/series/58013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5749_full -> Patchwork_12465_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_12465_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12465_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_12465_full:
### IGT changes ###
Warnings
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-iclb: DMESG-WARN [fdo#107956] -> INCOMPLETE
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: SKIP [fdo#109441] -> FAIL
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- shard-iclb: DMESG-FAIL [fdo#106885] -> FAIL
Known issues
Here are the changes found in Patchwork_12465_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_params@no-bsd:
- shard-apl: NOTRUN -> SKIP [fdo#109271] +27
* igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-iclb: PASS -> INCOMPLETE [fdo#109100] / [fdo#109766] /
[fdo#109801]
* igt@gem_pwrite@big-cpu-fbr:
- shard-iclb: PASS -> TIMEOUT [fdo#109673] +2
* igt@i915_pm_rpm@gem-execbuf-stress-extra-wait:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +149
* igt@i915_selftest@live_contexts:
- shard-iclb: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@kms_atomic_transition@1x-modeset-transitions-fencing:
- shard-skl: NOTRUN -> FAIL [fdo#108470]
* igt@kms_atomic_transition@3x-modeset-transitions-fencing:
- shard-hsw: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-snb: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-hang-newfb-render-a:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-hang-newfb-render-e:
- shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107725] / [fdo#108145]
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-iclb: PASS -> FAIL [fdo#107725]
* igt@kms_chamelium@vga-hpd-after-suspend:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +97
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-hsw: NOTRUN -> INCOMPLETE [fdo#103540]
* igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-iclb: PASS -> FAIL [fdo#103355] +1
* igt@kms_draw_crc@draw-method-rgb565-pwrite-ytiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_draw_crc@draw-method-xrgb-blt-untiled:
- shard-skl: NOTRUN -> FAIL [fdo#103232] / [fdo#108472]
* igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled:
- shard-skl: NOTRUN -> FAIL [fdo#108145] / [fdo#108472]
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-skl: NOTRUN -> FAIL [fdo#103833] / [fdo#105682]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: PASS -> FAIL [fdo#105363]
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
- shard-skl: PASS -> INCOMPLETE [fdo#109507]
* igt@kms_flip_tiling@flip-x-tiled:
- shard-skl: NOTRUN -> FAIL [fdo#108145] / [fdo#108303]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-glk: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite:
- shard-skl: NOTRUN -> FAIL [fdo#103167] / [fdo#105682]
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#108040]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt:
- shard-iclb: PASS -> FAIL [fdo#109247] +14
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +5
* igt@kms_frontbu
[Intel-gfx] [RFC] drm/i915: adding state checker for gamma lut values
From: Swati Sharma
Added state checker to validate gamma_lut values. This
reads hardware state, and compares the originally requested
state to the state read from hardware.
This implementation can be used for Gen9+ platforms,
I haven't implemented it for legacy platforms. Just want to get
feedback if this is the right approach to follow.
Also, inverse function of drm_color_lut_extract is missing
to convert hardware read values back to user values.
Thinking for that. I have added all "TODOs" and "Placeholders".
Another approach:
Storing "word" to be written into hardware in dev_priv and
instead of comparing blob, comparing "word"? In dev_priv,
only pointer will be there (something like *gamma_word).
For this too, I will send a patch to make it more clear.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_color.c | 127 +--
drivers/gpu/drm/i915/intel_display.c | 50 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
4 files changed, 173 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c4ffe19..b41bfaa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -334,6 +334,7 @@ struct drm_i915_display_funcs {
* involved with the same commit.
*/
void (*load_luts)(const struct intel_crtc_state *crtc_state);
+ void (*get_config)(struct intel_crtc_state *crtc_state);
};
#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index da7a07d..a515e9f 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -74,6 +74,11 @@
#define ILK_CSC_COEFF_1_0 \
((7 << 12) | ILK_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
+/* Mask to extract RGB values from registers */
+#define COLOR_BLUE_MASK 0x03FF /* 9:0 */
+#define COLOR_GREEN_MASK0x000FFC00 /* 19:10 */
+#define COLOR_RED_MASK 0x3FF0 /* 29:20 */
+
static bool lut_is_legacy(const struct drm_property_blob *lut)
{
return drm_color_lut_size(lut) == LEGACY_LUT_LENGTH;
@@ -672,6 +677,97 @@ static void cherryview_load_luts(const struct
intel_crtc_state *crtc_state)
i9xx_load_luts_internal(crtc_state, NULL);
}
+static void bdw_get_gamma_config(struct intel_crtc_state *crtc_state, u32
offset)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 i, tmp, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob = NULL;
+ struct drm_color_lut *blob_data;
+
+ WARN_ON(offset & ~PAL_PREC_INDEX_VALUE_MASK);
+
+ I915_WRITE(PREC_PAL_INDEX(pipe),
+ (offset ? PAL_PREC_SPLIT_MODE : 0) |
+ PAL_PREC_AUTO_INCREMENT |
+ offset);
+
+ blob = drm_property_create_blob(dev,
+ sizeof(struct drm_color_lut) * lut_size,
+ NULL);
+ if (IS_ERR(blob))
+ return;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < lut_size; i++) {
+ tmp = I915_READ(PREC_PAL_DATA(pipe));
+ /*
+* TODO: convert RGB value read from register into
corresponding user value using
+* some wrapper like drm_color_lut_put() (or)
intel_color_lut_put() so that it
+* can be compared later.
+*/
+ blob_data[i].red = (tmp & COLOR_RED_MASK) >> 20;
+ blob_data[i].green = (tmp & COLOR_GREEN_MASK) >> 10;
+ blob_data[i].blue = tmp & COLOR_BLUE_MASK;
+ }
+
+ I915_WRITE(PREC_PAL_INDEX(pipe), 0);
+
+ crtc_state->base.gamma_lut = blob;
+}
+
+static void i9xx_get_config(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 i, tmp;
+ enum pipe pipe = crtc->pipe;
+ struct drm_property_blob *blob = NULL;
+ struct drm_color_lut *blob_data;
+
+ blob = drm_property_create_blob(dev,
+ sizeof(struct drm_color_lut) * 256,
+ NULL);
+ if (IS_ERR(blob))
+ return;
+
+ blob_data = blob->data;
+
+ for (i = 0; i < 256; i++) {
+ if (HAS_GMCH(dev_priv))
+ tmp = I915_READ(PALETTE(pipe, i));
+ else
+ tmp = I915_READ(LGC_PALETTE(pipe, i));
+ /*
+* TODO: convert RGB v
Re: [Intel-gfx] [PATCH] drm/i915: Drop platform_mask
On 15/03/2019 07:27, Lucas De Marchi wrote: On Fri, Mar 15, 2019 at 12:13 AM Tvrtko Ursulin wrote: On 15/03/2019 06:56, Tvrtko Ursulin wrote: On 15/03/2019 00:52, Chris Wilson wrote: Quoting José Roberto de Souza (2019-03-15 00:42:35) We don't have any platform that is composed by 2 or more platforms so we don't need a mask, lets drop it and remove the actual limit of 32 platforms. Platform mask was a nifty trick to compile tests like IS_SKYLAKE || IS_BROADWELL etc into a single conditional. gcc doesn't entirely agree, this is a net loss here (i.e. code size increases). Perhaps the size re-gain of dropping the platform mask could be checked against the size gain of making the mask 64 bit. current: text databssdechexfilename 1836533 40454 41761881163 1cb44b drivers/gpu/drm/i915/i915.o.old 64 bit bitmask: 1836757 40454 41761881387 1cb52b drivers/gpu/drm/i915/i915.o no platform_mask: 1837591 40454 41761882221 1cb86d drivers/gpu/drm/i915/i915.o So current situation to "just use a number" we are talking about 1k here, which for me looks acceptable. Alternative is the 64-bit bitmask, with ~200 bytes. Maybe yeah, but there was also the second part about per SKU builds. Let me dig out the sub platform patch and modify it to split out the mask into two dwords and see how that would look. Regards, Tvrtko Lucas De Marchi One possible alternative could be splitting the 64-bit platform mask into two 32-bit dwords. Like: u32 platform_mask[2]; #define IS_PLATFORM(p) (platform_mask[p / 32] & BIT(p % 32)) And a bit of jigging the enum space so that we don't end up with something often tested together on the dword boundary. In fact I had a prototype many months ago which went a step further and interleaved platform with gen mask, in some sized chunks, so even IS_PLATFORM || IS_GEN checks could be merged. This included the sub-platform thing as well with the ULT/ULX/LP stuff I think.. maybe I need to dig this out to see how it worked. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 06/13] drm: Enable HDR infoframe support
On 3/11/2019 9:27 AM, 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.
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
Signed-off-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 58
drivers/video/hdmi.c | 129 +
include/drm/drm_edid.h | 4 ++
include/linux/hdmi.h | 22
4 files changed, 213 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0470845..49f8340 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4914,6 +4914,64 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
}
/**
+ * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
+ * HDR metadata from userspace
+ * @frame: HDMI AVI infoframe
+ * @hdr_source_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,
+ void *hdr_metadata)
Alignment with bracket above
+{
+ struct hdr_static_metadata *hdr_source_metadata;
+ int err, i;
+
+ if (!frame || !hdr_metadata)
+ return true;
+
+ err = hdmi_drm_infoframe_init(frame);
+ if (err < 0)
+ return err;
+
+ DRM_DEBUG_KMS("type = %x\n", frame->type);
+
+ hdr_source_metadata = (struct hdr_static_metadata *)hdr_metadata;
+
+ frame->length = sizeof(struct hdr_static_metadata);
+
extra blank line
+
+ frame->eotf = hdr_source_metadata->eotf;
+ frame->metadata_type = hdr_source_metadata->metadata_type;
+
+ for (i = 0; i < 3; i++) {
+ frame->display_primaries[i].x =
+ hdr_source_metadata->display_primaries[i].x;
+ frame->display_primaries[i].y =
+ hdr_source_metadata->display_primaries[i].y;
+ }
memcpy here to avoid loop ?
+
+ frame->white_point.x = hdr_source_metadata->white_point.x;
+ frame->white_point.y = hdr_source_metadata->white_point.y;
+
+ frame->max_mastering_display_luminance =
+ hdr_source_metadata->max_mastering_display_luminance;
+ frame->min_mastering_display_luminance =
+ hdr_source_metadata->min_mastering_display_luminance;
+
+ frame->max_cll = hdr_source_metadata->max_cll;
+ frame->max_fall = hdr_source_metadata->max_fall;
+
In fact the structures look so analogues, can we do a complete memcpy of
one structure to other ? or the sequence of the elements is different ?
+ hdmi_infoframe_log(KERN_CRIT, NULL,
+ (union hdmi_infoframe *)frame);
+
+ 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..7ab8086 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -650,6 +650,93 @@ 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;
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_init);
+
+/**
+ * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
+ * @frame: HDMI DRM infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe *frame, void *buffer,
+ size_t size)
+{
+ u8 *ptr = buffer;
+ size_t length;
+ int i;
+
+ length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: adding state checker for gamma lut values
== Series Details == Series: drm/i915: adding state checker for gamma lut values URL : https://patchwork.freedesktop.org/series/58039/ State : failure == Summary == Applying: drm/i915: adding state checker for gamma lut values Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/intel_color.c M drivers/gpu/drm/i915/intel_display.c M drivers/gpu/drm/i915/intel_drv.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_drv.h Auto-merging drivers/gpu/drm/i915/intel_display.c Auto-merging drivers/gpu/drm/i915/intel_color.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_color.c Auto-merging drivers/gpu/drm/i915/i915_drv.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: adding state checker for gamma lut values When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Drop address size from ppgtt_type
Quoting Rodrigo Vivi (2019-03-15 00:03:43) > On Thu, Mar 14, 2019 at 10:38:37PM +, Chris Wilson wrote: > > With the introduction of the separate addressable bits into the device > > info, we can remove the conflation of the ppgtt size from the ppgtt > > type. > > > > Based on a patch by Bob Paauwe > > > > Signed-off-by: Chris Wilson > > Cc: Bob Paauwe > > Cc: Matthew Auld > > Cc: Joonas Lahtinen > > --- > > drivers/gpu/drm/i915/i915_drv.c | 2 +- > > drivers/gpu/drm/i915/i915_drv.h | 2 -- > > drivers/gpu/drm/i915/i915_pci.c | 4 ++-- > > drivers/gpu/drm/i915/intel_device_info.h| 1 - > > drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +- > > 5 files changed, 4 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index ad695cdc0487..a3b00ecc58c9 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -348,7 +348,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, > > void *data, > > value = HAS_WT(dev_priv); > > break; > > case I915_PARAM_HAS_ALIASING_PPGTT: > > - value = min_t(int, INTEL_PPGTT(dev_priv), > > I915_GEM_PPGTT_FULL); > > + value = INTEL_PPGTT(dev_priv); > > I don't know the users of this param so I'm not 100% confident that this > doesn't break something. The point was that we made the change earlier to define intel_ppgtt_type from the uABI values, of which INTEL_PPGTT_FULL_4LVL was the odd one out for not being exported as it still implied _48b_ (back when it was just a reflection of the modparam). Upon introducing 48b, we added I915_CONTEXT_PARAM_GTT_SIZE precisely for the purpose of reporting the actual GTT size (with the hope that we could one day support dynamic resizing per-context) rather than infer it based on an global enum. -Chris ___ 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/gtt: Refactor common ppgtt initialisation
Quoting Rodrigo Vivi (2019-03-14 22:53:44) > On Thu, Mar 14, 2019 at 10:38:39PM +, Chris Wilson wrote: > > The basic setup of the i915_hw_ppgtt is the same between gen6 and gen8, > > so refactor that into a common routine. > > > > Signed-off-by: Chris Wilson > > Cc: Bob Paauwe > > Cc: Matthew Auld > > Cc: Joonas Lahtinen > > Reviewed-by: Rodrigo Vivi I've pushed this series so that 36 bits should be a nice and simple drop in. Thank you Bob for preparing these, sorry for not being clear enough on the direction I felt the patches should take. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/39] drm/i915/execlists: Virtual engine bonding
Quoting Tvrtko Ursulin (2019-03-14 17:26:19)
>
> On 13/03/2019 14:43, Chris Wilson wrote:
> > Some users require that when a master batch is executed on one particular
> > engine, a companion batch is run simultaneously on a specific slave
> > engine. For this purpose, we introduce virtual engine bonding, allowing
> > maps of master:slaves to be constructed to constrain which physical
> > engines a virtual engine may select given a fence on a master engine.
> >
> > For the moment, we continue to ignore the issue of preemption deferring
> > the master request for later. Ideally, we would like to then also remove
> > the slave and run something else rather than have it stall the pipeline.
> > With load balancing, we should be able to move workload around it, but
> > there is a similar stall on the master pipeline while it may wait for
> > the slave to be executed. At the cost of more latency for the bonded
> > request, it may be interesting to launch both on their engines in
> > lockstep. (Bubbles abound.)
> >
> > Opens: Also what about bonding an engine as its own master? It doesn't
> > break anything internally, so allow the silliness.
> >
> > v2: Emancipate the bonds
> > v3: Couple in delayed scheduling for the selftests
> > v4: Handle invalid mutually exclusive bonding
> > v5: Mention what the uapi does
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 50 +
> > drivers/gpu/drm/i915/i915_request.c | 1 +
> > drivers/gpu/drm/i915/i915_request.h | 1 +
> > drivers/gpu/drm/i915/intel_engine_types.h | 7 +
> > drivers/gpu/drm/i915/intel_lrc.c | 143 ++
> > drivers/gpu/drm/i915/intel_lrc.h | 4 +
> > drivers/gpu/drm/i915/selftests/intel_lrc.c| 185 ++
> > drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 3 +
> > include/uapi/drm/i915_drm.h | 33
> > 9 files changed, 427 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 98763d3f1b12..0ec78c386473 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -1513,8 +1513,58 @@ set_engines__load_balance(struct i915_user_extension
> > __user *base, void *data)
> > return 0;
> > }
> >
> > +static int
> > +set_engines__bond(struct i915_user_extension __user *base, void *data)
> > +{
> > + struct i915_context_engines_bond __user *ext =
> > + container_of_user(base, typeof(*ext), base);
> > + const struct set_engines *set = data;
> > + struct intel_engine_cs *master;
> > + u32 class, instance, siblings;
>
> u16 class, instance for no real gain.
Ah, forgot to change types after we consolidated on using u16 for the
engine class/instance. But as I've discovered, we can just use unsigned
int, the type doesn't have to exactly match the __user :)
> > @@ -3218,12 +3251,35 @@ static void virtual_submission_tasklet(unsigned
> > long data)
> > return;
> >
> > local_irq_disable();
> > +
> > + mask = 0;
> > + spin_lock(&ve->base.timeline.lock);
> > + if (ve->request) {
> > + mask = ve->request->execution_mask;
> > + if (unlikely(!mask))
> > + virtual_submit_error(ve);
>
> What clears the mask? And virtual_submit_error fails it then?
The user may over-constrain the request with multiple submit-fences, and
the intersection of those master:slave may be 0. submit_error marks the
request as invalid, and puts it on a random queue.
(Need to go back and make it an actual skip request so that dependencies
remain correct; just a danger of user deadlock causing a gpu hang, but
that's already beyond repair.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Always kick the execlists tasklet after reset
Chris Wilson writes:
> With direct submission being disabled while the reset in progress, we
> have a small window where we may forgo the submission of a new request
> and not notice its addition during execlists_reset_finish. To close this
> window, always schedule the submission tasklet on coming out of reset to
> catch any residual work.
>
> <6> [333.144082] i915: Running
> intel_hangcheck_live_selftests/igt_reset_engines
> <3> [333.296927] i915_reset_engine(rcs0:idle): failed to idle after reset
> <6> [333.296932] i915 :00:02.0: [drm] rcs0
> <6> [333.296934] i915 :00:02.0: [drm] Hangcheck 0:a9ddf7a5 [4157 ms]
> <6> [333.296936] i915 :00:02.0: [drm] Reset count: 36048 (global 754)
> <6> [333.296938] i915 :00:02.0: [drm] Requests:
> <6> [333.296997] i915 :00:02.0: [drm] RING_START: 0x
> <6> [333.296999] i915 :00:02.0: [drm] RING_HEAD: 0x
> <6> [333.297001] i915 :00:02.0: [drm] RING_TAIL: 0x
> <6> [333.297003] i915 :00:02.0: [drm] RING_CTL: 0x
> <6> [333.297005] i915 :00:02.0: [drm] RING_MODE: 0x0200 [idle]
> <6> [333.297007] i915 :00:02.0: [drm] RING_IMR: feff
> <6> [333.297010] i915 :00:02.0: [drm] ACTHD: 0x_
> <6> [333.297012] i915 :00:02.0: [drm] BBADDR: 0x_
> <6> [333.297015] i915 :00:02.0: [drm] DMA_FADDR: 0x_
> <6> [333.297017] i915 :00:02.0: [drm] IPEIR: 0x
> <6> [333.297019] i915 :00:02.0: [drm] IPEHR: 0x
> <6> [333.297021] i915 :00:02.0: [drm] Execlist status: 0x0001
>
> <6> [333.297023] i915 :00:02.0: [drm] Execlist CSB read 5, write 5
> [mmio:7], tasklet queued? no (enabled)
> <6> [333.297025] i915 :00:02.0: [drm] ELSP[0] idle
> <6> [333.297027] i915 :00:02.0: [drm] ELSP[1] idle
> <6> [333.297028] i915 :00:02.0: [drm] HW active? 0x0
> <6> [333.297044] i915 :00:02.0: [drm] Queue priority hint:
> -8186
> <6> [333.297067] i915 :00:02.0: [drm] Q 2afac:5f2+
> prio=-8186 @ 50ms: (null)
> <6> [333.297068] i915 :00:02.0: [drm] HWSP:
> <6> [333.297071] i915 :00:02.0: [drm] []
>
> <6> [333.297073] i915 :00:02.0: [drm] *
> <6> [333.297075] i915 :00:02.0: [drm] [0040] 0001 0018
> 0002 0001 0018
> <6> [333.297077] i915 :00:02.0: [drm] [0060] 0001 8002
> 0002 0005
> <6> [333.297079] i915 :00:02.0: [drm] [0080]
>
> <6> [333.297081] i915 :00:02.0: [drm] *
> <6> [333.297083] i915 :00:02.0: [drm] [00c0]
> a9ddf7a5
> <6> [333.297085] i915 :00:02.0: [drm] [00e0]
>
> <6> [333.297087] i915 :00:02.0: [drm] *
> <6> [333.297089] i915 :00:02.0: [drm] Idle? no
> <6> [333.297090] i915_reset_engine(rcs0:idle): 3000 resets
> <3> [333.297092] i915/intel_hangcheck_live_selftests: igt_reset_engines
> failed with error -5
> <3> [333.455460] i915 :00:02.0: Failed to idle engines, declaring wedged!
> ...
> <0> [333.491294] i915_sel-49161 333262143us : i915_reset_engine: rcs0
> flags=4
> <0> [333.491328] i915_sel-49161 333262143us :
> execlists_reset_prepare: rcs0: depth<-0
> <0> [333.491362] i915_sel-49161 333262143us : intel_engine_stop_cs:
> rcs0
> <0> [333.491396] i915_sel-49161d..1 333262144us : process_csb: rcs0
> cs-irq head=5, tail=5
> <0> [333.491424] i915_sel-49161 333262145us : intel_gpu_reset:
> engine_mask=1
> <0> [333.491454] kworker/-214 5 333262184us :
> i915_gem_switch_to_kernel_context: awake?=yes
> <0> [333.491487] kworker/-214 5 333262192us : i915_request_add: rcs0
> fence 2afac:1522
> <0> [333.491520] kworker/-214 5 333262193us : i915_request_add:
> marking (null) as active
> <0> [333.491553] i915_sel-49161 333262199us :
> intel_engine_cancel_stop_cs: rcs0
> <0> [333.491587] i915_sel-49161 333262199us : execlists_reset_finish:
> rcs0: depth->0
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.h | 7 ++-
> drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index 74a2ddc1b52f..5c073fe73664 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -82,7 +82,7 @@ void i915_gem_unpark(struct drm_i915_private *i915);
>
> static inline void __tasklet_disable_sync_once(struct tasklet_struct *t)
> {
> - if (atomic_inc_return(&t->count) == 1)
> + if (!
Re: [Intel-gfx] [PATCH] drm/i915: Always kick the execlists tasklet after reset
Quoting Mika Kuoppala (2019-03-15 10:10:20)
> Chris Wilson writes:
> > +static inline bool __tasklet_enable(struct tasklet_struct *t)
> > +{
> > + return atomic_dec_and_test(&t->count);
> > +}
> > +
> > #endif /* __I915_GEM_H__ */
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index dc3de09c7586..b2d0e16645c7 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -2030,7 +2030,8 @@ static void execlists_reset_finish(struct
> > intel_engine_cs *engine)
> > if (!RB_EMPTY_ROOT(&execlists->queue.rb_root))
> > execlists->tasklet.func(execlists->tasklet.data);
> >
> > - tasklet_enable(&execlists->tasklet);
> > + if (__tasklet_enable(&execlists->tasklet))
> > + tasklet_hi_schedule(&execlists->tasklet);
>
> Why not just go fully unconditional, enable and schedule?
If we schedule before we finish the reset, the tasklet busyspins, get's
kicked to ksoftirqd, which then busyspins for its timeslice and gets
bumped around by the scheduler until finally ready.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/cml: Introduce Comet Lake PCH
On Thu, 14 Mar 2019, Rodrigo Vivi wrote:
> On Thu, Mar 14, 2019 at 11:29:18AM -0700, Anusha wrote:
>> From: Anusha Srivatsa
>>
>> Comet Lake PCH is based off of Cannon Point(CNP).
>> Add PCI ID for Comet Lake PCH.
>>
>> v2: Code cleanup (DK)
>>
>> Cc: Dhinakaran Pandiyan
>> Cc: Rodrigo Vivi
>> Signed-off-by: Anusha Srivatsa
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 5 +
>> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>> 2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 0d743907e7bc..b519c3685e80 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -188,6 +188,11 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
>> unsigned short id)
>> DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
>> WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
>> return PCH_CNP;
>> +case INTEL_PCH_CMP_DEVICE_ID_TYPE:
>> +DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
>> +WARN_ON(!IS_COFFEELAKE(dev_priv));
>> +/* CML has same South Display Engine from CNP */
>
> maybe "inherit from" or "same as" ?
>
> but the important is the comment is in place
> and since I'm not native speaker I'm not confident
> to require my bikeshed so with or without change:
All other similar cases above have:
/* FOO is BAR compatible */
Which is essentially all we need to know from driver perspective. We
don't need to know if they're the same or if they inherit or what, if
all we care about is whether we can use the same driver code for both.
BR,
Jani.
>
> Reviewed-by: Rodrigo Vivi
>
>> +return PCH_CNP;
>> case INTEL_PCH_ICP_DEVICE_ID_TYPE:
>> DRM_DEBUG_KMS("Found Ice Lake PCH\n");
>> WARN_ON(!IS_ICELAKE(dev_priv));
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index dccb6006aabf..4090462f591a 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -537,7 +537,7 @@ enum intel_pch {
>> PCH_LPT,/* Lynxpoint/Wildcatpoint PCH */
>> PCH_SPT,/* Sunrisepoint PCH */
>> PCH_KBP,/* Kaby Lake PCH */
>> -PCH_CNP,/* Cannon Lake PCH */
>> +PCH_CNP,/* Cannon/Comet Lake PCH */
>> PCH_ICP,/* Ice Lake PCH */
>> };
>>
>> @@ -2549,6 +2549,7 @@ static inline unsigned int i915_sg_segment_size(void)
>> #define INTEL_PCH_KBP_DEVICE_ID_TYPE0xA280
>> #define INTEL_PCH_CNP_DEVICE_ID_TYPE0xA300
>> #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE 0x9D80
>> +#define INTEL_PCH_CMP_DEVICE_ID_TYPE0x0280
>> #define INTEL_PCH_ICP_DEVICE_ID_TYPE0x3480
>> #define INTEL_PCH_P2X_DEVICE_ID_TYPE0x7100
>> #define INTEL_PCH_P3X_DEVICE_ID_TYPE0x7000
>> --
>> 2.21.0
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Always kick the execlists tasklet after reset
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-03-15 10:10:20)
>> Chris Wilson writes:
>> > +static inline bool __tasklet_enable(struct tasklet_struct *t)
>> > +{
>> > + return atomic_dec_and_test(&t->count);
>> > +}
>> > +
>> > #endif /* __I915_GEM_H__ */
>> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> > b/drivers/gpu/drm/i915/intel_lrc.c
>> > index dc3de09c7586..b2d0e16645c7 100644
>> > --- a/drivers/gpu/drm/i915/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> > @@ -2030,7 +2030,8 @@ static void execlists_reset_finish(struct
>> > intel_engine_cs *engine)
>> > if (!RB_EMPTY_ROOT(&execlists->queue.rb_root))
>> > execlists->tasklet.func(execlists->tasklet.data);
>> >
>> > - tasklet_enable(&execlists->tasklet);
>> > + if (__tasklet_enable(&execlists->tasklet))
>> > + tasklet_hi_schedule(&execlists->tasklet);
>>
>> Why not just go fully unconditional, enable and schedule?
>
> If we schedule before we finish the reset, the tasklet busyspins, get's
> kicked to ksoftirqd, which then busyspins for its timeslice and gets
> bumped around by the scheduler until finally ready.
Hmm stealing the whole timeslice is rude. Just wanted
to weight in the extra trickery. Random thought was
to advocate for execlists_tasklet_enable|disable,
but perhaps we are not there yet.
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Always kick the execlists tasklet after reset
Quoting Mika Kuoppala (2019-03-15 10:39:25)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-03-15 10:10:20)
> >> Chris Wilson writes:
> >> > +static inline bool __tasklet_enable(struct tasklet_struct *t)
> >> > +{
> >> > + return atomic_dec_and_test(&t->count);
> >> > +}
> >> > +
> >> > #endif /* __I915_GEM_H__ */
> >> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >> > b/drivers/gpu/drm/i915/intel_lrc.c
> >> > index dc3de09c7586..b2d0e16645c7 100644
> >> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> >> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >> > @@ -2030,7 +2030,8 @@ static void execlists_reset_finish(struct
> >> > intel_engine_cs *engine)
> >> > if (!RB_EMPTY_ROOT(&execlists->queue.rb_root))
> >> > execlists->tasklet.func(execlists->tasklet.data);
> >> >
> >> > - tasklet_enable(&execlists->tasklet);
> >> > + if (__tasklet_enable(&execlists->tasklet))
> >> > + tasklet_hi_schedule(&execlists->tasklet);
> >>
> >> Why not just go fully unconditional, enable and schedule?
> >
> > If we schedule before we finish the reset, the tasklet busyspins, get's
> > kicked to ksoftirqd, which then busyspins for its timeslice and gets
> > bumped around by the scheduler until finally ready.
>
> Hmm stealing the whole timeslice is rude. Just wanted
> to weight in the extra trickery. Random thought was
> to advocate for execlists_tasklet_enable|disable,
> but perhaps we are not there yet.
Keep sowing those seeds!
By the way, remind yourself on how our execlists submission works...
https://patchwork.freedesktop.org/patch/291941/?series=57942&rev=2
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/5] lib/igt_pm: igt lib helper routines to support DC5/6 tests
On Wed, Mar 13, 2019 at 11:02:18PM +0530, Anshuman Gupta wrote:
> From: Jyoti Yadav
>
> dmc_loaded() will be used by new test i915_pm_dc.c which will validate
> Display C States. So moving the same to igt_pm library.
> Introduced igt_disable_runtime_pm() inorder to disable runtime suspend
> for the function which support dc9.
>
> v2: Simplify the comment section.
> v3: Remove . from the subject line.
> v4: Rebased, resolve conflicts in pm_rpm.c
> Included patch set version change log.
> v5: Listing actual change in patch set changelog to make review easier.
> v6: igt's lib added support for disabling runtime suspend, change in commit
> log.
> rebased due to test name pm_rpm changed to i915_pm_rpm.
>
> Signed-off-by: Jyoti Yadav
> Signed-off-by: Anshuman Gupta
> ---
> lib/igt_pm.c | 47 +++
> lib/igt_pm.h | 2 ++
> tests/i915/i915_pm_rpm.c | 17 +
> 3 files changed, 50 insertions(+), 16 deletions(-)
>
> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> index 4902723..0ed566f 100644
> --- a/lib/igt_pm.c
> +++ b/lib/igt_pm.c
> @@ -38,6 +38,7 @@
> #include "drmtest.h"
> #include "igt_pm.h"
> #include "igt_aux.h"
> +#include "igt_sysfs.h"
>
> /**
> * SECTION:igt_pm
> @@ -486,6 +487,7 @@ void igt_restore_runtime_pm(void)
> igt_pm_audio_restore_runtime_pm();
> }
>
> +
Extra w/s.
> static void __igt_pm_runtime_exit_handler(int sig)
> {
> __igt_restore_runtime_pm();
> @@ -577,6 +579,24 @@ bool igt_setup_runtime_pm(void)
> return true;
> }
>
> +bool igt_disable_runtime_pm(void)
> +{
> + int fd;
> + ssize_t size;
> + char buf[6];
> +
This being a library function it should make sure that the original
value of POWER_DIR/control has been saved. For instance by asserting
that igt_setup_runtime_pm() has been called previously.
> + /* We know we support runtime PM, let's try to disable it now. */
> + fd = open(POWER_DIR "/control", O_RDWR);
> + igt_assert_f(fd >= 0, "Can't open " POWER_DIR "/control\n");
> + size = write(fd, "on\n", 3);
> + igt_assert(size == 3);
> + lseek(fd, 0, SEEK_SET);
> + size = read(fd, buf, ARRAY_SIZE(buf));
> + igt_assert(size == 3);
> + igt_assert(strncmp(buf, "on\n", 3) == 0);
> + close(fd);
> + return true;
> +}
> /**
> * igt_get_runtime_pm_status:
> *
> @@ -620,3 +640,30 @@ bool igt_wait_for_pm_status(enum igt_runtime_pm_status
> status)
> {
> return igt_wait(igt_get_runtime_pm_status() == status, 1, 100);
> }
> +
> +/**
> + * dmc_loaded:
> + * @debugfs: fd to the debugfs dir.
> +
> + * Check whether DMC FW is loaded or not. DMC FW is require for few Display C
> + * states like DC5 and DC6. FW does the Context Save and Restore during
> Display
> + * C States entry and exit.
> + *
> + * Returns:
> + * True if DMC FW is loaded otherwise false.
> + */
> +bool igt_pm_dmc_loaded(int debugfs)
> +{
> + igt_require(debugfs != -1);
> + char buf[15];
> + int len;
> +
> + len = igt_sysfs_read(debugfs, "i915_dmc_info", buf, sizeof(buf) - 1);
> + if (len < 0)
> + return true; /* no CSR support, no DMC requirement */
> +
> + buf[len] = '\0';
> +
> + igt_info("DMC: %s\n", buf);
> + return strstr(buf, "fw loaded: yes");
> +}
> diff --git a/lib/igt_pm.h b/lib/igt_pm.h
> index 10cc679..6c4617a 100644
> --- a/lib/igt_pm.h
> +++ b/lib/igt_pm.h
> @@ -47,8 +47,10 @@ enum igt_runtime_pm_status {
> };
>
> bool igt_setup_runtime_pm(void);
> +bool igt_disable_runtime_pm(void);
> void igt_restore_runtime_pm(void);
> enum igt_runtime_pm_status igt_get_runtime_pm_status(void);
> bool igt_wait_for_pm_status(enum igt_runtime_pm_status status);
> +bool igt_pm_dmc_loaded(int debugfs);
>
> #endif /* IGT_PM_H */
> diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
> index be296f5..2d7cb5e 100644
> --- a/tests/i915/i915_pm_rpm.c
> +++ b/tests/i915/i915_pm_rpm.c
> @@ -710,21 +710,6 @@ static void setup_pc8(void)
> has_pc8 = true;
> }
>
> -static bool dmc_loaded(void)
> -{
> - char buf[15];
> - int len;
> -
> - len = igt_sysfs_read(debugfs, "i915_dmc_info", buf, sizeof(buf) - 1);
> - if (len < 0)
> - return true; /* no CSR support, no DMC requirement */
> -
> - buf[len] = '\0';
> -
> - igt_info("DMC: %s\n", buf);
> - return strstr(buf, "fw loaded: yes");
> -}
> -
> static void dump_file(int dir, const char *filename)
> {
> char *contents;
> @@ -761,7 +746,7 @@ static bool setup_environment(void)
> igt_info("Runtime PM support: %d\n", has_runtime_pm);
> igt_info("PC8 residency support: %d\n", has_pc8);
> igt_require(has_runtime_pm);
> - igt_require(dmc_loaded());
> + igt_require(igt_pm_dmc_loaded(debugfs));
>
> out:
> disable_all_screens(&ms_data);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https:/
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
On Thu, Mar 14, 2019 at 10:52:08AM +0100, John Ogness wrote: > On 2019-03-14, John Ogness wrote: > > On 2019-03-14, Daniel Vetter wrote: > >> That's why we came up with the trylock + immediate bail out design if > >> that fails. Plus really only render the oops int whatever is the > >> current display buffer, so that we don't have to do any hw > >> programming at all. > > > > I think this is your best option. The real work will be identifying > > any/all spin locking that currently exists. For all of those, the code > > needs to change to: > > > > 1. trylock if oops_in_progress, otherwise spinlock > > On second thought, you shouldn't use oops_in_progress. It would be > better if DRM had its own flag to signify that it is currently being > used in kmsg_dump context. We use oops_in_progress because the fbcon design is a terrible layer cake. I agree that for the new code we shouldn't use it: New code paths that do trylock only. > > 2. if trylock fails, the code must have a sane failure > > > > The 2nd point will be the difficult one. For example, you may have > > functions without a return value taking spinlocks. But now those > > functions could fail. Nah, imo no code reuse for the oops path. If you do that you sooner or later end up pulling in the 100kloc of modeset code, and we've been there. Doesn't work. New, absolutely minimal oops code, with as little of it shared with normal kms code. That's also why we absolutely have to be able to test this stuff without a real oops. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
On Thu, Mar 14, 2019 at 12:44:06PM +, Kazlauskas, Nicholas wrote:
> On 3/14/19 5:50 AM, Daniel Vetter wrote:
> > On Wed, Mar 13, 2019 at 05:41:52PM +, Kazlauskas, Nicholas wrote:
> >> On 3/13/19 1:33 PM, Michel Dänzer wrote:
> >>> On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote:
> On 3/13/19 11:54 AM, Christian König wrote:
> > Am 13.03.19 um 16:38 schrieb Michel Dänzer:
> >> On 2019-03-13 2:37 p.m., Christian König wrote:
> >>> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
> On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
> > On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
> >> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> >>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > A kernel message dumper is used to dump the log. The dumper
> > iterates
> > over each DRM device and it's crtc's to find suitable
> > framebuffers.
> >
> > All the other dumpers are run before this one except mtdoops.
> > Only atomic drivers are supported.
> >
> > Signed-off-by: Noralf Trønnes
> > ---
> > [...]
> >
> > diff --git a/include/drm/drm_framebuffer.h
> > b/include/drm/drm_framebuffer.h
> > index f0b34c977ec5..f3274798ecfe 100644
> > --- a/include/drm/drm_framebuffer.h
> > +++ b/include/drm/drm_framebuffer.h
> > @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
> > struct drm_file *file_priv, unsigned flags,
> > unsigned color, struct drm_clip_rect *clips,
> > unsigned num_clips);
> > +
> > + /**
> > + * @panic_vmap:
> > + *
> > + * Optional callback for panic handling.
> > + *
> > + * For vmapping the selected framebuffer in a panic
> > context.
> > Must
> > + * be super careful about locking (only trylocking
> > allowed).
> > + *
> > + * RETURNS:
> > + *
> > + * NULL if it didn't work out, otherwise an opaque cookie
> > which is
> > + * passed to @panic_draw_xy. It can be anything: vmap area,
> > structure
> > + * with more details, just a few flags, ...
> > + */
> > + void *(*panic_vmap)(struct drm_framebuffer *fb);
> FWIW, the panic_vmap hook cannot work in general with the
> amdgpu/radeon
> drivers:
>
> Framebuffers are normally tiled, writing to them with the CPU
> results in
> garbled output.
>
> >> In which case the driver needs to support the ->panic_draw_xy
> >> callback,
> >> or maybe it's possible to make a generic helper for tiled buffers.
> > I'm afraid that won't help, at least not without porting big chunks
> > of
> > https://gitlab.freedesktop.org/mesa/mesa/tree/master/src/amd/addrlib
> > into the kernel, none of which will be used for anything else.
> >
> >
> There would need to be a mechanism for switching scanout to a
> linear,
> CPU accessible framebuffer.
> >>> I suppose panic_vmap() could just provide a linear temp buffer
> >>> to the panic handler, and panic_unmap() could copy the contents
> >>> over to the real fb.
> > Copy how? Using a GPU engine?
> CPU maybe? Though I suppose that won't work if the buffer isn't CPU
> accesible :/
> >>> Well we do have a debug path for accessing invisible memory with the
> >>> CPU.
> >>>
> >>> E.g. three registers: DATA and auto increment OFFSET_LO/HI. So you can
> >>> just read/write DATA over and over again if you want to access some
> >>> memory.
> >> Right. I assume that'll be very slow, but I guess it could do when the
> >> memory isn't directly CPU accessible.
> >
> > Just made a quick test and reading 33423360 bytes (4096x2040x4) using
> > that interfaces takes about 13 seconds.
> >
> > IIRC we don't use the auto increment optimization yet, so that can
> > probably be improved by a factor of 3 or more.
> >>>
> >>> I'd assume only writes are needed, no reads.
> >>>
> >>>
> >>> But turning of tilling etc is still extremely tricky when the system
> >>> is
> >>> already unstable.
> >> Maybe we could add a little hook to the display code, which just
> >> disables tiling for scanout and may
[Intel-gfx] [PATCH i-g-t] igt/i915/i915_pm_lpsp enable pm_lpsp for platforms till Gen11.
Enabling pm_lpsp igt tests for Gen11 as well as for all platforms
at least gen9, earlier these test were enabled only haswell and broadwell
platforms.
Signed-off-by: Anshuman Gupta
---
tests/i915/i915_pm_lpsp.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/tests/i915/i915_pm_lpsp.c b/tests/i915/i915_pm_lpsp.c
index b319dbe..f7037ce 100644
--- a/tests/i915/i915_pm_lpsp.c
+++ b/tests/i915/i915_pm_lpsp.c
@@ -30,18 +30,42 @@
#include
#include
+#define HSW_PW_CTL_IDX_GLOBAL 15
+#define SKL_PW_CTL_IDX_PW_2 15
+#define ICL_PW_CTL_IDX_PW_3 2
+
+#define HSW_PWR_WELL_CTL_REQ(pw_idx) (0x2 << ((pw_idx) * 2))
+#define HSW_PWR_WELL_CTL_STATE(pw_idx)(0x1 << ((pw_idx) * 2))
+
+int no_lpsp_pw_idx;
static bool supports_lpsp(uint32_t devid)
{
- return IS_HASWELL(devid) || IS_BROADWELL(devid);
+ return IS_HASWELL(devid) || IS_BROADWELL(devid) || AT_LEAST_GEN(devid,
9);
+}
+
+static bool get_no_lpsp_pw_idx(uint32_t devid)
+{
+ if (IS_HASWELL(devid) || IS_BROADWELL(devid))
+ no_lpsp_pw_idx = HSW_PW_CTL_IDX_GLOBAL;
+ else if (IS_GEN(devid, 11))
+ no_lpsp_pw_idx = ICL_PW_CTL_IDX_PW_3;
+ else if (AT_LEAST_GEN(devid, 9))
+ no_lpsp_pw_idx = SKL_PW_CTL_IDX_PW_2;
+ else
+ return false;
+
+ return true;
}
static bool lpsp_is_enabled(int drm_fd)
{
uint32_t val;
+ uint32_t mask = HSW_PWR_WELL_CTL_REQ(no_lpsp_pw_idx) |
+ HSW_PWR_WELL_CTL_STATE(no_lpsp_pw_idx);
val = INREG(HSW_PWR_WELL_CTL2);
- return !(val & HSW_PWR_WELL_STATE_ENABLED);
+ return !((val & mask) == mask);
}
/* The LPSP mode is all about an enabled pipe, but we expect to also be in the
@@ -212,6 +236,7 @@ igt_main
intel_register_access_init(intel_get_pci_device(), 0, drm_fd);
+ igt_require(get_no_lpsp_pw_idx(devid));
kmstest_set_vt_graphics_mode();
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h
We want to use intel_engine_mask_t inside i915_request.h, which means
extracting it from the general header file mess and placing it inside a
types.h. A knock on effect is that the compiler wants to warn about
type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
for the worst.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_reset.c | 26 ++---
drivers/gpu/drm/i915/i915_reset.h | 6 +-
drivers/gpu/drm/i915/i915_scheduler.h | 86 +---
drivers/gpu/drm/i915/i915_scheduler_types.h | 98 +++
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/i915_timeline_types.h| 3 +-
drivers/gpu/drm/i915/intel_device_info.h | 3 +-
drivers/gpu/drm/i915/intel_engine_types.h | 10 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 4 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
.../test_i915_scheduler_types_standalone.c| 7 ++
14 files changed, 141 insertions(+), 109 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_scheduler_types.h
create mode 100644 drivers/gpu/drm/i915/test_i915_scheduler_types_standalone.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68fecf355471..197b081769b5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -60,6 +60,7 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
i915-$(CONFIG_DRM_I915_WERROR) += \
test_i915_active_types_standalone.o \
test_i915_gem_context_types_standalone.o \
+ test_i915_scheduler_types_standalone.o \
test_i915_timeline_types_standalone.o \
test_intel_context_types_standalone.o \
test_intel_engine_types_standalone.o \
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index b596cb42e24e..a0d981547c9e 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -311,7 +311,7 @@ static int mul_force_wake_write(struct intel_vgpu *vgpu,
static int gdrst_mmio_write(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
- unsigned int engine_mask = 0;
+ unsigned long engine_mask = 0;
u32 data;
write_vreg(vgpu, offset, p_data, bytes);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c65c2e6649df..b018ebe6c6f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2432,7 +2432,6 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
#define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
-#define ALL_ENGINES(~0u)
#define HAS_ENGINE(dev_priv, id) (INTEL_INFO(dev_priv)->engine_mask & BIT(id))
#define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 861fe083e383..5f40725ca428 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -144,7 +144,7 @@ static void gen3_stop_engine(struct intel_engine_cs *engine)
}
static void i915_stop_engines(struct drm_i915_private *i915,
- unsigned int engine_mask)
+ unsigned long engine_mask)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -165,7 +165,7 @@ static bool i915_in_reset(struct pci_dev *pdev)
}
static int i915_do_reset(struct drm_i915_private *i915,
-unsigned int engine_mask,
+unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = i915->drm.pdev;
@@ -194,7 +194,7 @@ static bool g4x_reset_complete(struct pci_dev *pdev)
}
static int g33_do_reset(struct drm_i915_private *i915,
- unsigned int engine_mask,
+ unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = i915->drm.pdev;
@@ -204,7 +204,7 @@ static int g33_do_reset(struct drm_i915_private *i915,
}
static int g4x_do_reset(struct drm_i915_private *dev_priv,
- unsigned int engine_mask,
+ unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = dev_priv->drm.pdev;
@@ -242,7 +242,7 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
}
static int ironlake_do_reset(struct drm_i915_private *dev_priv,
-unsigned int engine_mask,
+unsigned long engine_mask,
unsigned int retry)
{
int ret;
@@ -299,7 +299,7 @@ s
[Intel-gfx] [PATCH] drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h
We want to use intel_engine_mask_t inside i915_request.h, which means
extracting it from the general header file mess and placing it inside a
types.h. A knock on effect is that the compiler wants to warn about
type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
for the worst.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_reset.c | 26 ++---
drivers/gpu/drm/i915/i915_reset.h | 6 +-
drivers/gpu/drm/i915/i915_scheduler.h | 86 +---
drivers/gpu/drm/i915/i915_scheduler_types.h | 98 +++
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/i915_timeline_types.h| 3 +-
drivers/gpu/drm/i915/intel_device_info.h | 3 +-
drivers/gpu/drm/i915/intel_engine_types.h | 9 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 4 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
.../test_i915_scheduler_types_standalone.c| 7 ++
14 files changed, 140 insertions(+), 109 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_scheduler_types.h
create mode 100644 drivers/gpu/drm/i915/test_i915_scheduler_types_standalone.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68fecf355471..197b081769b5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -60,6 +60,7 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
i915-$(CONFIG_DRM_I915_WERROR) += \
test_i915_active_types_standalone.o \
test_i915_gem_context_types_standalone.o \
+ test_i915_scheduler_types_standalone.o \
test_i915_timeline_types_standalone.o \
test_intel_context_types_standalone.o \
test_intel_engine_types_standalone.o \
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index b596cb42e24e..a0d981547c9e 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -311,7 +311,7 @@ static int mul_force_wake_write(struct intel_vgpu *vgpu,
static int gdrst_mmio_write(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
- unsigned int engine_mask = 0;
+ unsigned long engine_mask = 0;
u32 data;
write_vreg(vgpu, offset, p_data, bytes);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c65c2e6649df..b018ebe6c6f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2432,7 +2432,6 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
#define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
-#define ALL_ENGINES(~0u)
#define HAS_ENGINE(dev_priv, id) (INTEL_INFO(dev_priv)->engine_mask & BIT(id))
#define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 861fe083e383..5f40725ca428 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -144,7 +144,7 @@ static void gen3_stop_engine(struct intel_engine_cs *engine)
}
static void i915_stop_engines(struct drm_i915_private *i915,
- unsigned int engine_mask)
+ unsigned long engine_mask)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -165,7 +165,7 @@ static bool i915_in_reset(struct pci_dev *pdev)
}
static int i915_do_reset(struct drm_i915_private *i915,
-unsigned int engine_mask,
+unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = i915->drm.pdev;
@@ -194,7 +194,7 @@ static bool g4x_reset_complete(struct pci_dev *pdev)
}
static int g33_do_reset(struct drm_i915_private *i915,
- unsigned int engine_mask,
+ unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = i915->drm.pdev;
@@ -204,7 +204,7 @@ static int g33_do_reset(struct drm_i915_private *i915,
}
static int g4x_do_reset(struct drm_i915_private *dev_priv,
- unsigned int engine_mask,
+ unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = dev_priv->drm.pdev;
@@ -242,7 +242,7 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
}
static int ironlake_do_reset(struct drm_i915_private *dev_priv,
-unsigned int engine_mask,
+unsigned long engine_mask,
unsigned int retry)
{
int ret;
@@ -299,7 +299,7 @@ s
Re: [Intel-gfx] [v5 07/13] drm/i915: Write HDR infoframe and send to panel
On 3/11/2019 9:27 AM, Uma Shankar wrote:
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.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 33 +
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 58483f8..a5ee124 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1037,6 +1037,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 0952475..ea7afa0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -555,6 +555,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)
@@ -777,6 +778,30 @@ 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 hdr_static_metadata *hdr_metadata;
+ int ret;
+
Don't we need a GEN/monitor check before going ahead with HDR metadata ?
- Shashank
+ hdr_metadata = (struct hdr_static_metadata *)
+ conn_state->hdr_output_metadata_blob_ptr->data;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
+ if (ret < 0) {
+ DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+ return false;
+ }
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+ return true;
+}
+
static void g4x_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -1175,6 +1200,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)
@@ -2381,6 +2409,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;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v5 09/13] drm/i915: Add HLG EOTF
On 3/11/2019 9:28 AM, Uma Shankar wrote:
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
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 4 ++--
include/linux/hdmi.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 49f8340..4cd22e8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3864,8 +3864,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 33243b2..ad652e6 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -161,6 +161,7 @@ enum hdmi_eotf {
HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
HDMI_EOTF_SMPTE_ST2084,
+ HDMI_EOTF_BT_2100_HLG,
};
Looks good to me,
Feel free to use: Reviewed-by: Shashank Sharma
struct hdmi_avi_infoframe {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: split pll functions (rev3)
== Series Details == Series: drm/i915/icl: split pll functions (rev3) URL : https://patchwork.freedesktop.org/series/57618/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5750_full -> Patchwork_12467_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12467_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12467_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_12467_full: ### IGT changes ### Possible regressions * igt@kms_flip@blocking-wf_vblank: - shard-apl: PASS -> DMESG-WARN Known issues Here are the changes found in Patchwork_12467_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +7 * igt@gem_mmap_gtt@hang: - shard-iclb: PASS -> FAIL [fdo#109677] * igt@gem_pwrite@huge-cpu-forwards: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +43 * igt@gem_pwrite@stolen-snoop: - shard-glk: NOTRUN -> SKIP [fdo#109271] +20 * igt@gem_stolen@stolen-clear: - shard-iclb: NOTRUN -> SKIP [fdo#109277] * igt@gem_workarounds@suspend-resume-context: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@i915_missed_irq: - shard-iclb: NOTRUN -> SKIP [fdo#109503] * igt@i915_pm_rpm@cursor: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@i915_pm_sseu@full-enable: - shard-iclb: NOTRUN -> SKIP [fdo#109288] * igt@kms_atomic_transition@plane-all-modeset-transition: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_busy@basic-modeset-d: - shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_busy@extended-pageflip-hang-newfb-render-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +8 - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] +1 - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-hsw: PASS -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-a-ccs-on-another-bo: - shard-snb: NOTRUN -> SKIP [fdo#109271] +218 * igt@kms_chamelium@hdmi-crc-fast: - shard-skl: NOTRUN -> SKIP [fdo#109271] +107 * igt@kms_chamelium@hdmi-crc-rgb565: - shard-iclb: NOTRUN -> SKIP [fdo#109284] * igt@kms_chv_cursor_fail@pipe-a-64x64-left-edge: - shard-skl: PASS -> FAIL [fdo#104671] * igt@kms_concurrent@pipe-d: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +2 * igt@kms_content_protection@atomic-dpms: - shard-kbl: NOTRUN -> FAIL [fdo#108739] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: PASS -> DMESG-WARN [fdo#108566] * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-sliding: - shard-skl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: PASS -> FAIL [fdo#104873] * igt@kms_cursor_legacy@cursor-vs-flip-varying-size: - shard-iclb: PASS -> FAIL [fdo#103355] +1 * igt@kms_cursor_legacy@cursora-vs-flipb-atomic-transitions: - shard-hsw: PASS -> SKIP [fdo#109271] +1 * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-untiled: - shard-skl: NOTRUN -> FAIL [fdo#103184] * igt@kms_fbcon_fbt@fbc: - shard-iclb: PASS -> DMESG-WARN [fdo#109593] * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: NOTRUN -> FAIL [fdo#105363] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +6 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#109247] +15 * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-shrfb-pgflip-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +6 * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-cpu: - shard-iclb:
[Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consolidate device ids checking into a single function
called during early driver load.
A few low bits in the platform mask are reserved for sub-platform
identification and defined as a per-platform namespace.
At the same time it future proofs the platform_mask handling by preparing
the code for easy extending, and tidies the very verbose WARN strings
generated when IS_PLATFORM macros are embedded into a WARN type
statements.
The approach is also beneficial to driver size, with an combined shrink of
code and strings of around 1.7 kiB.
v2: Fixed IS_SUBPLATFORM. Updated commit msg.
v3: Chris was right, there is an ordering problem.
v4:
* Catch-up with new sub-platforms.
* Rebase for RUNTIME_INFO.
* Drop subplatform mask union tricks and convert platform_mask to an
array for extensibility.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Jose Souza
---
drivers/gpu/drm/i915/i915_drv.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 110 +++
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 79
drivers/gpu/drm/i915/intel_device_info.h | 28 +-
5 files changed, 179 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d743907e7bc..3218350cd225 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -863,6 +863,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
if (i915_inject_load_failure())
return -ENODEV;
+ intel_device_info_subplatform_init(dev_priv);
+
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
mutex_init(&dev_priv->backlight_lock);
@@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
drm_i915_private *dev_priv)
if (drm_debug & DRM_UT_DRIVER) {
struct drm_printer p = drm_debug_printer("i915 device info:");
- drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
+ drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
gen=%i\n",
INTEL_DEVID(dev_priv),
INTEL_REVID(dev_priv),
intel_platform_name(INTEL_INFO(dev_priv)->platform),
+
RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
(BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) -
INTEL_SUBPLATFORM_BITS)],
INTEL_GEN(dev_priv));
intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
@@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
memcpy(device_info, match_info, sizeof(*device_info));
RUNTIME_INFO(i915)->device_id = pdev->device;
- BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
-BITS_PER_TYPE(device_info->platform_mask));
BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
return i915;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dccb6006aabf..34282cf66cb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2281,7 +2281,46 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_REVID(p, since, until) \
(INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
-#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask & BIT(p))
+#define __IS_PLATFORM(dev_priv, p) \
+({ \
+ const unsigned int pbits__ = \
+ BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
+ INTEL_SUBPLATFORM_BITS; \
+ const unsigned int pi__ = (p) / pbits__; \
+ const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
+\
+ BUILD_BUG_ON(!__builtin_constant_p(p)); \
+\
+ (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & BIT(pb__)); \
+})
+
+#define __IS_SUBPLATFORM(dev_priv, p, s) \
+({ \
+ const unsigned int pbits__ = \
+ BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
+ INTEL_SUBPLATFORM_BITS; \
+ const unsigned int pi__ = (p) / pbits__; \
+ const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
+\
+ BUILD_BUG_ON(!__builtin_constant_p(p)); \
+ BUILD_BUG_ON(!__builtin_constant_p(s)); \
+ BUILD_BUG_ON((s) >= INTEL_SUBPLATFORM_BITS); \
+\
+ (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & (BIT(pb__) | BIT(s))); \
+})
+
+static inline bool
+IS_PLATFORM(const struct drm_i915_private *i915, enum intel_platform p)
+{
+ return __IS_PLATFORM(i915, p);
+
Re: [Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
Quoting Tvrtko Ursulin (2019-03-15 12:26:33)
> From: Tvrtko Ursulin
>
> Concept of a sub-platform already exist in our code (like ULX and ULT
> platform variants and similar),implemented via the macros which check a
> list of device ids to determine a match.
>
> With this patch we consolidate device ids checking into a single function
> called during early driver load.
>
> A few low bits in the platform mask are reserved for sub-platform
> identification and defined as a per-platform namespace.
>
> At the same time it future proofs the platform_mask handling by preparing
> the code for easy extending, and tidies the very verbose WARN strings
> generated when IS_PLATFORM macros are embedded into a WARN type
> statements.
>
> The approach is also beneficial to driver size, with an combined shrink of
> code and strings of around 1.7 kiB.
>
> v2: Fixed IS_SUBPLATFORM. Updated commit msg.
> v3: Chris was right, there is an ordering problem.
>
> v4:
> * Catch-up with new sub-platforms.
> * Rebase for RUNTIME_INFO.
> * Drop subplatform mask union tricks and convert platform_mask to an
>array for extensibility.
>
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Chris Wilson
> Cc: Chris Wilson
> Cc: Jani Nikula
> Cc: Lucas De Marchi
> Cc: Jose Souza
> ---
> drivers/gpu/drm/i915/i915_drv.c | 7 +-
> drivers/gpu/drm/i915/i915_drv.h | 110 +++
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 79
> drivers/gpu/drm/i915/intel_device_info.h | 28 +-
> 5 files changed, 179 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 0d743907e7bc..3218350cd225 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -863,6 +863,8 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv)
> if (i915_inject_load_failure())
> return -ENODEV;
>
> + intel_device_info_subplatform_init(dev_priv);
> +
> spin_lock_init(&dev_priv->irq_lock);
> spin_lock_init(&dev_priv->gpu_error.lock);
> mutex_init(&dev_priv->backlight_lock);
> @@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
> drm_i915_private *dev_priv)
> if (drm_debug & DRM_UT_DRIVER) {
> struct drm_printer p = drm_debug_printer("i915 device info:");
>
> - drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
> + drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
> gen=%i\n",
>INTEL_DEVID(dev_priv),
>INTEL_REVID(dev_priv),
>
> intel_platform_name(INTEL_INFO(dev_priv)->platform),
> +
> RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
> (BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) -
> INTEL_SUBPLATFORM_BITS)],
I hope that's a one-off!
>INTEL_GEN(dev_priv));
>
> intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
> @@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> memcpy(device_info, match_info, sizeof(*device_info));
> RUNTIME_INFO(i915)->device_id = pdev->device;
>
> - BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
> -BITS_PER_TYPE(device_info->platform_mask));
> BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
>
> return i915;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dccb6006aabf..34282cf66cb0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2281,7 +2281,46 @@ static inline unsigned int i915_sg_segment_size(void)
> #define IS_REVID(p, since, until) \
> (INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
>
> -#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask &
> BIT(p))
> +#define __IS_PLATFORM(dev_priv, p) \
> +({ \
> + const unsigned int pbits__ = \
> + BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
> + INTEL_SUBPLATFORM_BITS; \
> + const unsigned int pi__ = (p) / pbits__; \
> + const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
Oh, p is a compile time constant, so these can all be evaluated at
compile time. So not a worry.
> +\
> + BUILD_BUG_ON(!__builtin_constant_p(p)); \
> +\
> + (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & BIT(pb__)); \
> +})
> +
> +#define __IS_SUBPLATFORM(dev_priv, p, s) \
> +({ \
> + const unsigned int pbits__ = \
> + BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
> + INTEL_SUBPLATFORM_BITS; \
> + const unsigned int pi__ = (p) / pbits__; \
> + const unsigned int pb__ = (p) % pbits__ + INTE
Re: [Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
On 15/03/2019 13:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-15 12:26:33)
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consolidate device ids checking into a single function
called during early driver load.
A few low bits in the platform mask are reserved for sub-platform
identification and defined as a per-platform namespace.
At the same time it future proofs the platform_mask handling by preparing
the code for easy extending, and tidies the very verbose WARN strings
generated when IS_PLATFORM macros are embedded into a WARN type
statements.
The approach is also beneficial to driver size, with an combined shrink of
code and strings of around 1.7 kiB.
v2: Fixed IS_SUBPLATFORM. Updated commit msg.
v3: Chris was right, there is an ordering problem.
v4:
* Catch-up with new sub-platforms.
* Rebase for RUNTIME_INFO.
* Drop subplatform mask union tricks and convert platform_mask to an
array for extensibility.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Jose Souza
---
drivers/gpu/drm/i915/i915_drv.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 110 +++
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 79
drivers/gpu/drm/i915/intel_device_info.h | 28 +-
5 files changed, 179 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d743907e7bc..3218350cd225 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -863,6 +863,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
if (i915_inject_load_failure())
return -ENODEV;
+ intel_device_info_subplatform_init(dev_priv);
+
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
mutex_init(&dev_priv->backlight_lock);
@@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
drm_i915_private *dev_priv)
if (drm_debug & DRM_UT_DRIVER) {
struct drm_printer p = drm_debug_printer("i915 device info:");
- drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
+ drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
gen=%i\n",
INTEL_DEVID(dev_priv),
INTEL_REVID(dev_priv),
intel_platform_name(INTEL_INFO(dev_priv)->platform),
+
RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
(BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - INTEL_SUBPLATFORM_BITS)],
I hope that's a one-off!
It's indeed horrible. I was thinking of adding a helper but decided to
wait for some general acks first.
INTEL_GEN(dev_priv));
intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
@@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
memcpy(device_info, match_info, sizeof(*device_info));
RUNTIME_INFO(i915)->device_id = pdev->device;
- BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
-BITS_PER_TYPE(device_info->platform_mask));
BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
return i915;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dccb6006aabf..34282cf66cb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2281,7 +2281,46 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_REVID(p, since, until) \
(INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
-#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask & BIT(p))
+#define __IS_PLATFORM(dev_priv, p) \
+({ \
+ const unsigned int pbits__ = \
+ BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
+ INTEL_SUBPLATFORM_BITS; \
+ const unsigned int pi__ = (p) / pbits__; \
+ const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
Oh, p is a compile time constant, so these can all be evaluated at
compile time. So not a worry.
+\
+ BUILD_BUG_ON(!__builtin_constant_p(p)); \
+\
+ (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & BIT(pb__)); \
+})
+
+#define __IS_SUBPLATFORM(dev_priv, p, s) \
+({ \
+ const unsigned int pbits__ = \
+ BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
+ INTEL_SUBPLATFORM_BITS; \
+ const unsigned int pi__ = (p) / pbits__; \
+ const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
+\
+ BUIL
Re: [Intel-gfx] [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
On Thu, Mar 14, 2019 at 06:37:22PM -0700, Vanshidhar Konda wrote:
> On Thu, Mar 14, 2019 at 11:09:38PM +0200, Ville Syrjälä wrote:
> >On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote:
> >> On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote:
> >> >On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote:
> >> >> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
> >> >> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
> >> >> >> The log level for timeout after waiting for a signal on the DP aux
> >> >> >> channel control register is set to DRM_ERROR. But this is timeout
> >> >> >> not a
> >> >> >> fatal error as the driver is expected to retry the command. Failure
> >> >> >> after all retries is already captured as an error. Hence, reducing
> >> >> >> the
> >> >> >> log for a timeout to warning instead of error.
> >> >> >> ---
> >> >> >> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> >> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >> >> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> >> >> index 47857f96c3b1..f51e8b2ccb17 100644
> >> >> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> >> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp
> >> >> >> *intel_dp)
> >> >> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
> >> >> >>
> >> >> >> if (!done)
> >> >> >> -DRM_ERROR("dp aux hw did not signal timeout!\n");
> >> >> >> +DRM_WARN("dp aux hw did not signal timeout!\n");
> >> >> >
> >> >> >IIRC this indicates the hw is broken.
> >> >> >
> >> >> Does this indicate an issue with Intel GFX/display device, or the
> >> >> display/monitor connected to the DP port?
> >> >>
> >> >> FYI, this is for FDO #109982
> >> >> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
> >> >
> >> >There's nothing connected I believe. But in either case I believe
> >>
> >> >From the two logs for the issue, e-DP1 is the only display connected to
> >> the test machine when it generated this error.
> >>
> >> >the aux hw should terminate with a proper timeout. I'm tempted to
> >>
> >> If we think that there should be no timeout, would it make more sense to
> >> return an error to the caller and having the caller handle the error?
> >
> >How would it handle the error?
> >
> >>
> >> >blame the typec/tbt stuff here too.
> Could it be possible that the addition of typec/tbt to ICL has added
> additional latency to the DP register being signaled? Would it make
> sense to increase the 10 ms timeout to something larger?
Imre just told me the hw timeout was increased to 4ms. So 10ms should
still be sufficient I guess. But it wouldn't hurt to at least test
longer timeouts a bit to see if the hw ever gets around to signalling
the timeout.
>
> >> >
> >> >>
> >> >> >From the logs, it seems like this timeout only occurs once. The next
> >> >> >try
> >> >> succeeds without issues.
> >> >>
> >> >> >> #undef C
> >> >> >>
> >> >> >> return status;
> >> >> >> --
> >> >> >> 2.20.1
> >> >> >>
> >> >> >> ___
> >> >> >> Intel-gfx mailing list
> >> >> >> Intel-gfx@lists.freedesktop.org
> >> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >> >> >
> >> >> >--
> >> >> >Ville Syrjälä
> >> >> >Intel
> >> >
> >> >--
> >> >Ville Syrjälä
> >> >Intel
> >
> >--
> >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] drm/i915: Introduce concept of a sub-platform
Quoting Tvrtko Ursulin (2019-03-15 13:32:54)
>
> On 15/03/2019 13:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-15 12:26:33)
> >> From: Tvrtko Ursulin
> >>
> >> Concept of a sub-platform already exist in our code (like ULX and ULT
> >> platform variants and similar),implemented via the macros which check a
> >> list of device ids to determine a match.
> >>
> >> With this patch we consolidate device ids checking into a single function
> >> called during early driver load.
> >>
> >> A few low bits in the platform mask are reserved for sub-platform
> >> identification and defined as a per-platform namespace.
> >>
> >> At the same time it future proofs the platform_mask handling by preparing
> >> the code for easy extending, and tidies the very verbose WARN strings
> >> generated when IS_PLATFORM macros are embedded into a WARN type
> >> statements.
> >>
> >> The approach is also beneficial to driver size, with an combined shrink of
> >> code and strings of around 1.7 kiB.
> >>
> >> v2: Fixed IS_SUBPLATFORM. Updated commit msg.
> >> v3: Chris was right, there is an ordering problem.
> >>
> >> v4:
> >> * Catch-up with new sub-platforms.
> >> * Rebase for RUNTIME_INFO.
> >> * Drop subplatform mask union tricks and convert platform_mask to an
> >> array for extensibility.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> Suggested-by: Chris Wilson
> >> Cc: Chris Wilson
> >> Cc: Jani Nikula
> >> Cc: Lucas De Marchi
> >> Cc: Jose Souza
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.c | 7 +-
> >> drivers/gpu/drm/i915/i915_drv.h | 110 +++
> >> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> >> drivers/gpu/drm/i915/intel_device_info.c | 79
> >> drivers/gpu/drm/i915/intel_device_info.h | 28 +-
> >> 5 files changed, 179 insertions(+), 47 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >> b/drivers/gpu/drm/i915/i915_drv.c
> >> index 0d743907e7bc..3218350cd225 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.c
> >> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >> @@ -863,6 +863,8 @@ static int i915_driver_init_early(struct
> >> drm_i915_private *dev_priv)
> >> if (i915_inject_load_failure())
> >> return -ENODEV;
> >>
> >> + intel_device_info_subplatform_init(dev_priv);
> >> +
> >> spin_lock_init(&dev_priv->irq_lock);
> >> spin_lock_init(&dev_priv->gpu_error.lock);
> >> mutex_init(&dev_priv->backlight_lock);
> >> @@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
> >> drm_i915_private *dev_priv)
> >> if (drm_debug & DRM_UT_DRIVER) {
> >> struct drm_printer p = drm_debug_printer("i915 device
> >> info:");
> >>
> >> - drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s
> >> gen=%i\n",
> >> + drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
> >> gen=%i\n",
> >> INTEL_DEVID(dev_priv),
> >> INTEL_REVID(dev_priv),
> >>
> >> intel_platform_name(INTEL_INFO(dev_priv)->platform),
> >> +
> >> RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
> >> (BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) -
> >> INTEL_SUBPLATFORM_BITS)],
> >
> > I hope that's a one-off!
>
> It's indeed horrible. I was thinking of adding a helper but decided to
> wait for some general acks first.
>
> >> INTEL_GEN(dev_priv));
> >>
> >> intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
> >> @@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const
> >> struct pci_device_id *ent)
> >> memcpy(device_info, match_info, sizeof(*device_info));
> >> RUNTIME_INFO(i915)->device_id = pdev->device;
> >>
> >> - BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
> >> -BITS_PER_TYPE(device_info->platform_mask));
> >> BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
> >>
> >> return i915;
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index dccb6006aabf..34282cf66cb0 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -2281,7 +2281,46 @@ static inline unsigned int
> >> i915_sg_segment_size(void)
> >> #define IS_REVID(p, since, until) \
> >> (INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
> >>
> >> -#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask &
> >> BIT(p))
> >> +#define __IS_PLATFORM(dev_priv, p) \
> >> +({ \
> >> + const unsigned int pbits__ = \
> >> + BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
> >> + INTEL_SUBPLATFORM_BITS; \
> >> + const unsigned int pi__ = (p) / pbits__; \
> >> + const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLA
[Intel-gfx] [PATCH v4 1/3] drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents
Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
define register bitfield masks.
We define the above as wrappers to BIT() and GENMASK() respectively to
force u32 type to go with our register size, and to add compile time
checks on the bit numbers.
The intention is that these are easier to get right and review against
the spec than hand rolled masks.
Convert power sequencer registers as an example.
v4:
- rebase
v3:
- rename macros to REG_BIT() and REG_GENMASK() to avoid underscore
prefix and to be in line with kernel macros (Chris)
- add compile time checks (Mika)
v2:
- rename macros to just _BIT() and _MASK() to reduce verbosity
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
Cc: Mika Kuoppala
Cc: Ville Syrjälä
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 94 +
1 file changed, 61 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9b69cec21f7b..4a025e3c49c4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -25,6 +25,8 @@
#ifndef _I915_REG_H_
#define _I915_REG_H_
+#include
+
/**
* DOC: The i915 register macro definition style guide
*
@@ -59,15 +61,13 @@
* significant to least significant bit. Indent the register content macros
* using two extra spaces between ``#define`` and the macro name.
*
- * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Define bit field
- * contents so that they are already shifted in place, and can be directly
- * OR'd. For convenience, function-like macros may be used to define bit
fields,
- * but do note that the macros may be needed to read as well as write the
- * register contents.
+ * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Use
+ * ``REG_GENMASK()`` to define _MASK. Define bit field contents so that they
are
+ * already shifted in place, and can be directly OR'd. For convenience,
+ * function-like macros may be used to define bit fields, but do note that the
+ * macros may be needed to read as well as write the register contents.
*
- * Define bits using ``(1 << N)`` instead of ``BIT(N)``. We may change this in
- * the future, but this is the prevailing style. Do **not** add ``_BIT`` suffix
- * to the name.
+ * Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the
name.
*
* Group the register and its contents together without blank lines, separate
* from other registers and their contents with one blank line.
@@ -105,8 +105,8 @@
* #define _FOO_A 0xf000
* #define _FOO_B 0xf001
* #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
- * #define FOO_ENABLE(1 << 31)
- * #define FOO_MODE_MASK (0xf << 16)
+ * #define FOO_ENABLEREG_BIT(31)
+ * #define FOO_MODE_MASK REG_GENMASK(19, 16)
* #define FOO_MODE_SHIFT16
* #define FOO_MODE_BAR (0 << 16)
* #define FOO_MODE_BAZ (1 << 16)
@@ -116,6 +116,34 @@
* #define GEN8_BAR_MMIO(0xb888)
*/
+/**
+ * REG_BIT() - Prepare a u32 bit value
+ * @__n: 0-based bit number
+ *
+ * Local wrapper for BIT() to force u32, with compile time checks.
+ *
+ * @return: Value with bit @__n set.
+ */
+#define REG_BIT(__n) \
+ ((u32)(BIT(__n) + \
+ BUILD_BUG_ON_ZERO(__builtin_constant_p(__n) && \
+((__n) < 0 || (__n) > 31
+
+/**
+ * REG_GENMASK() - Prepare a continuous u32 bitmask
+ * @__high: 0-based high bit
+ * @__low: 0-based low bit
+ *
+ * Local wrapper for GENMASK() to force u32, with compile time checks.
+ *
+ * @return: Continuous bitmask from @__high to @__low, inclusive.
+ */
+#define REG_GENMASK(__high, __low) \
+ ((u32)(GENMASK(__high, __low) + \
+ BUILD_BUG_ON_ZERO(__builtin_constant_p(__high) &&\
+__builtin_constant_p(__low) && \
+((__low) < 0 || (__high) > 31 || (__low) >
(__high)
+
typedef struct {
u32 reg;
} i915_reg_t;
@@ -4692,18 +4720,18 @@ enum {
#define _PP_STATUS 0x61200
#define PP_STATUS(pps_idx) _MMIO_PPS(pps_idx, _PP_STATUS)
-#define PP_ON(1 << 31)
+#define PP_ONREG_BIT(31)
#define _PP_CONTROL_1 0xc7204
#define _PP_CONTROL_2 0xc7304
#define ICP_PP_CONTROL(x) _MMIO(((x) == 1) ? _PP_CONTROL_1 : \
_PP_CONTROL_2)
-#define POWER_CYCLE_DELAY_MASK(0x1f << 4)
+#define POWER_CYCLE_DELAY_MASK
[Intel-gfx] [PATCH v4 3/3] drm/i915: use REG_FIELD_PREP() to define register bitfield values
Slightly verbose, but does away with hand rolled shifts. Ties the field
values with the mask defining the field.
Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
to a integer constant expression. But with this, we can ensure the mask
is non-zero, power of 2, fits u32, and the value fits the mask (when the
value is a constant expression).
Convert power sequencer registers as an example.
v4:
- rebase
v3:
- rename the macro to REG_FIELD_PREP to avoid underscore prefix and to
be in line with kernel macros (Chris)
- rename power of 2 check macro (Chris)
v2:
- add build-time checks with BUILD_BUG_ON_ZERO()
- rename to just _FIELD() due to regmap.h REG_FIELD() clash
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
Cc: Mika Kuoppala
Cc: Ville Syrjälä
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 69 +++--
1 file changed, 39 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 31a3020e369d..477dfda38fc7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -62,11 +62,11 @@
* significant to least significant bit. Indent the register content macros
* using two extra spaces between ``#define`` and the macro name.
*
- * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents so
- * that they are already shifted in place, and can be directly OR'd. For
- * convenience, function-like macros may be used to define bit fields, but do
- * note that the macros may be needed to read as well as write the register
- * contents.
+ * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents
+ * using ``REG_FIELD_PREP(mask, value)``. This will define the values already
+ * shifted in place, so they can be directly OR'd together. For convenience,
+ * function-like macros may be used to define bit fields, but do note that the
+ * macros may be needed to read as well as write the register contents.
*
* Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the
name.
*
@@ -108,9 +108,9 @@
* #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
* #define FOO_ENABLEREG_BIT(31)
* #define FOO_MODE_MASK REG_GENMASK(19, 16)
- * #define FOO_MODE_BAR (0 << 16)
- * #define FOO_MODE_BAZ (1 << 16)
- * #define FOO_MODE_QUX_SNB (2 << 16)
+ * #define FOO_MODE_BAR REG_FIELD_PREP(FOO_MODE_MASK, 0)
+ * #define FOO_MODE_BAZ REG_FIELD_PREP(FOO_MODE_MASK, 1)
+ * #define FOO_MODE_QUX_SNB REG_FIELD_PREP(FOO_MODE_MASK, 2)
*
* #define BAR _MMIO(0xb000)
* #define GEN8_BAR_MMIO(0xb888)
@@ -144,17 +144,27 @@
__builtin_constant_p(__low) && \
((__low) < 0 || (__high) > 31 || (__low) >
(__high)
+/*
+ * Local integer constant expression version of is_power_of_2().
+ */
+#define IS_POWER_OF_2(__x) ((__x) && (((__x) & ((__x) - 1)) == 0))
+
/**
* REG_FIELD_PREP() - Prepare a u32 bitfield value
* @__mask: shifted mask defining the field's length and position
* @__val: value to put in the field
- * Local wrapper for FIELD_PREP() to force u32 and for consistency with
- * REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
+ * Local copy of FIELD_PREP() to generate an integer constant expression, force
+ * u32 and for consistency with REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
*
* @return: @__val masked and shifted into the field defined by @__mask.
*/
-#define REG_FIELD_PREP(__mask, __val) ((u32)FIELD_PREP(__mask, __val))
+#define REG_FIELD_PREP(__mask, __val)
\
+ ((u32)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) +
\
+ BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) +
\
+ BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U32_MAX) +
\
+ BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL <<
__bf_shf(__mask + \
+
BUILD_BUG_ON_ZERO(__builtin_choose_expr(__builtin_constant_p(__val),
(~((__mask) >> __bf_shf(__mask)) & (__val)), 0
/**
* REG_FIELD_GET() - Extract a u32 bitfield value
@@ -4764,27 +4774,26 @@ enum {
*/
#define PP_READY REG_BIT(30)
#define PP_SEQUENCE_MASK REG_GENMASK(29, 28)
-#define PP_SEQUENCE_NONE (0 << 28)
-#define PP_SEQUENCE_POWER_UP (1 << 28)
-#define PP_SEQUENCE_POWER_DOWN (2 << 28)
+#define PP_SEQUENCE_NONE REG_FIELD_PREP(PP_SEQUENCE_MASK, 0)
+#define PP_SEQUENCE_POWER_UP REG_FIELD_PREP(PP_SEQUENCE_MASK, 1)
+#define PP_SEQUENCE_POWER_DOWN REG_FIELD_PREP(PP_SEQUENCE_MASK, 2)
#define PP_CYCLE_DELAY_ACTIVEREG_BIT(27)
[Intel-gfx] [PATCH v4 0/3] drm/i915: introduce macros to define register contents
v4 of [1], rebased and very mildly tweaked, with the intention to merge. I added Chris' Reviewed-bys despite the rebase. BR, Jani. [1] cover.1551286447.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1551286447.git.jani.nikula@intel.com Jani Nikula (3): drm/i915: introduce REG_BIT() and REG_GENMASK() to define register contents drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors drm/i915: use REG_FIELD_PREP() to define register bitfield values drivers/gpu/drm/i915/i915_reg.h | 182 +++--- drivers/gpu/drm/i915/intel_dp.c | 42 +++ drivers/gpu/drm/i915/intel_lvds.c | 42 --- 3 files changed, 150 insertions(+), 116 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/3] drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors
bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
bitfields using the mask alone, with no need for separate shift. Indeed,
the shift is redundant.
We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
in part to force u32 and for consistency with REG_BIT() and
REG_GENMASK(), but also as we'll need to redefine REG_FIELD_PREP() in
follow-up work to make it produce integer constant expressions.
For the most part, REG_FIELD_GET() is shorter than masking followed by
shift, and arguably has more clarity.
REG_FIELD_PREP() can get more verbose than simply shifting in place, but
it does provide masking to ensure we don't overflow the mask, something
we usually don't bother with currently.
Convert power sequencer registers as an example.
v3:
- temp variable removal (Chris)
- rebase
v2:
- Add the REG_FIELD_GET() and REG_FIELD_PREP() wrappers to use them
consistently from the start.
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
Cc: Mika Kuoppala
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 45 ---
drivers/gpu/drm/i915/intel_dp.c | 42 ++---
drivers/gpu/drm/i915/intel_lvds.c | 42 +
3 files changed, 63 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4a025e3c49c4..31a3020e369d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -25,6 +25,7 @@
#ifndef _I915_REG_H_
#define _I915_REG_H_
+#include
#include
/**
@@ -61,11 +62,11 @@
* significant to least significant bit. Indent the register content macros
* using two extra spaces between ``#define`` and the macro name.
*
- * For bit fields, define a ``_MASK`` and a ``_SHIFT`` macro. Use
- * ``REG_GENMASK()`` to define _MASK. Define bit field contents so that they
are
- * already shifted in place, and can be directly OR'd. For convenience,
- * function-like macros may be used to define bit fields, but do note that the
- * macros may be needed to read as well as write the register contents.
+ * Define bit fields using ``REG_GENMASK(h, l)``. Define bit field contents so
+ * that they are already shifted in place, and can be directly OR'd. For
+ * convenience, function-like macros may be used to define bit fields, but do
+ * note that the macros may be needed to read as well as write the register
+ * contents.
*
* Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the
name.
*
@@ -107,7 +108,6 @@
* #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
* #define FOO_ENABLEREG_BIT(31)
* #define FOO_MODE_MASK REG_GENMASK(19, 16)
- * #define FOO_MODE_SHIFT16
* #define FOO_MODE_BAR (0 << 16)
* #define FOO_MODE_BAZ (1 << 16)
* #define FOO_MODE_QUX_SNB (2 << 16)
@@ -144,6 +144,30 @@
__builtin_constant_p(__low) && \
((__low) < 0 || (__high) > 31 || (__low) >
(__high)
+/**
+ * REG_FIELD_PREP() - Prepare a u32 bitfield value
+ * @__mask: shifted mask defining the field's length and position
+ * @__val: value to put in the field
+
+ * Local wrapper for FIELD_PREP() to force u32 and for consistency with
+ * REG_FIELD_GET(), REG_BIT() and REG_GENMASK().
+ *
+ * @return: @__val masked and shifted into the field defined by @__mask.
+ */
+#define REG_FIELD_PREP(__mask, __val) ((u32)FIELD_PREP(__mask, __val))
+
+/**
+ * REG_FIELD_GET() - Extract a u32 bitfield value
+ * @__mask: shifted mask defining the field's length and position
+ * @__val: value to extract the bitfield value from
+ *
+ * Local wrapper for FIELD_GET() to force u32 and for consistency with
+ * REG_FIELD_PREP(), REG_BIT() and REG_GENMASK().
+ *
+ * @return: Masked and shifted value of the field defined by @__mask in @__val.
+ */
+#define REG_FIELD_GET(__mask, __val) ((u32)FIELD_GET(__mask, __val))
+
typedef struct {
u32 reg;
} i915_reg_t;
@@ -4727,7 +4751,6 @@ enum {
#define ICP_PP_CONTROL(x) _MMIO(((x) == 1) ? _PP_CONTROL_1 : \
_PP_CONTROL_2)
#define POWER_CYCLE_DELAY_MASKREG_GENMASK(8, 4)
-#define POWER_CYCLE_DELAY_SHIFT 4
#define VDD_OVERRIDE_FORCEREG_BIT(3)
#define BACKLIGHT_ENABLE REG_BIT(2)
#define PWR_DOWN_ON_RESET REG_BIT(1)
@@ -4744,7 +4767,6 @@ enum {
#define PP_SEQUENCE_NONE (0 << 28)
#define PP_SEQUENCE_POWER_UP (1 << 28)
#define PP_SEQUENCE_POWER_DOWN (2 << 28)
-#define PP_SEQUENCE_SHIFT28
#define PP_CYCLE_DELAY_ACTIVEREG_BIT(27)
#define PP_SEQUENCE_STATE_MASK REG_GENMASK(3, 0)
#define PP_SEQUENCE_STATE_OFF_IDLE (0x0 << 0)
@@ -4770,7 +4792,6 @@ enum {
#define _PP_ON_DEL
Re: [Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Concept of a sub-platform already exist in our code (like ULX and ULT
> platform variants and similar),implemented via the macros which check a
> list of device ids to determine a match.
>
> With this patch we consolidate device ids checking into a single function
> called during early driver load.
>
> A few low bits in the platform mask are reserved for sub-platform
> identification and defined as a per-platform namespace.
>
> At the same time it future proofs the platform_mask handling by preparing
> the code for easy extending, and tidies the very verbose WARN strings
> generated when IS_PLATFORM macros are embedded into a WARN type
> statements.
>
> The approach is also beneficial to driver size, with an combined shrink of
> code and strings of around 1.7 kiB.
>
> v2: Fixed IS_SUBPLATFORM. Updated commit msg.
> v3: Chris was right, there is an ordering problem.
>
> v4:
> * Catch-up with new sub-platforms.
> * Rebase for RUNTIME_INFO.
> * Drop subplatform mask union tricks and convert platform_mask to an
>array for extensibility.
>
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Chris Wilson
> Cc: Chris Wilson
> Cc: Jani Nikula
> Cc: Lucas De Marchi
> Cc: Jose Souza
> ---
> drivers/gpu/drm/i915/i915_drv.c | 7 +-
> drivers/gpu/drm/i915/i915_drv.h | 110 +++
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 79
> drivers/gpu/drm/i915/intel_device_info.h | 28 +-
> 5 files changed, 179 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 0d743907e7bc..3218350cd225 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -863,6 +863,8 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv)
> if (i915_inject_load_failure())
> return -ENODEV;
>
> + intel_device_info_subplatform_init(dev_priv);
> +
> spin_lock_init(&dev_priv->irq_lock);
> spin_lock_init(&dev_priv->gpu_error.lock);
> mutex_init(&dev_priv->backlight_lock);
> @@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
> drm_i915_private *dev_priv)
> if (drm_debug & DRM_UT_DRIVER) {
> struct drm_printer p = drm_debug_printer("i915 device info:");
>
> - drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
> + drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
> gen=%i\n",
> INTEL_DEVID(dev_priv),
> INTEL_REVID(dev_priv),
> intel_platform_name(INTEL_INFO(dev_priv)->platform),
> +
> RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
> (BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) -
> INTEL_SUBPLATFORM_BITS)],
> INTEL_GEN(dev_priv));
>
> intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
> @@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> memcpy(device_info, match_info, sizeof(*device_info));
> RUNTIME_INFO(i915)->device_id = pdev->device;
>
> - BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
> - BITS_PER_TYPE(device_info->platform_mask));
> BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
>
> return i915;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dccb6006aabf..34282cf66cb0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2281,7 +2281,46 @@ static inline unsigned int i915_sg_segment_size(void)
> #define IS_REVID(p, since, until) \
> (INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
>
> -#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask &
> BIT(p))
> +#define __IS_PLATFORM(dev_priv, p) \
> +({ \
> + const unsigned int pbits__ = \
> + BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
> + INTEL_SUBPLATFORM_BITS; \
> + const unsigned int pi__ = (p) / pbits__; \
> + const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
> +\
> + BUILD_BUG_ON(!__builtin_constant_p(p)); \
> +\
> + (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & BIT(pb__)); \
> +})
> +
> +#define __IS_SUBPLATFORM(dev_priv, p, s) \
> +({ \
> + const unsigned int pbits__ = \
> + BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
> + INTEL_SUBPLATFORM_BITS; \
> + const unsigned int pi__ = (p) / pbits__; \
> + const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
> +\
> + BUILD_BUG_ON(!__builtin_constant_p(p)); \
> + BUILD_BUG_ON(!__builtin_constant_p(s)); \
> + BUILD_BUG_ON((s) >= INTEL_SUBPLATFORM_BITS);
Re: [Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
On 15/03/2019 14:09, Ville Syrjälä wrote:
On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consolidate device ids checking into a single function
called during early driver load.
A few low bits in the platform mask are reserved for sub-platform
identification and defined as a per-platform namespace.
At the same time it future proofs the platform_mask handling by preparing
the code for easy extending, and tidies the very verbose WARN strings
generated when IS_PLATFORM macros are embedded into a WARN type
statements.
The approach is also beneficial to driver size, with an combined shrink of
code and strings of around 1.7 kiB.
v2: Fixed IS_SUBPLATFORM. Updated commit msg.
v3: Chris was right, there is an ordering problem.
v4:
* Catch-up with new sub-platforms.
* Rebase for RUNTIME_INFO.
* Drop subplatform mask union tricks and convert platform_mask to an
array for extensibility.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Jose Souza
---
drivers/gpu/drm/i915/i915_drv.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 110 +++
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 79
drivers/gpu/drm/i915/intel_device_info.h | 28 +-
5 files changed, 179 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d743907e7bc..3218350cd225 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -863,6 +863,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
if (i915_inject_load_failure())
return -ENODEV;
+ intel_device_info_subplatform_init(dev_priv);
+
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
mutex_init(&dev_priv->backlight_lock);
@@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
drm_i915_private *dev_priv)
if (drm_debug & DRM_UT_DRIVER) {
struct drm_printer p = drm_debug_printer("i915 device info:");
- drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
+ drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
gen=%i\n",
INTEL_DEVID(dev_priv),
INTEL_REVID(dev_priv),
intel_platform_name(INTEL_INFO(dev_priv)->platform),
+
RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
(BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - INTEL_SUBPLATFORM_BITS)],
INTEL_GEN(dev_priv));
intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
@@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
memcpy(device_info, match_info, sizeof(*device_info));
RUNTIME_INFO(i915)->device_id = pdev->device;
- BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
-BITS_PER_TYPE(device_info->platform_mask));
BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
return i915;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dccb6006aabf..34282cf66cb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2281,7 +2281,46 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_REVID(p, since, until) \
(INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
-#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask & BIT(p))
+#define __IS_PLATFORM(dev_priv, p) \
+({ \
+ const unsigned int pbits__ = \
+ BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
+ INTEL_SUBPLATFORM_BITS; \
+ const unsigned int pi__ = (p) / pbits__; \
+ const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
+\
+ BUILD_BUG_ON(!__builtin_constant_p(p)); \
+\
+ (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & BIT(pb__)); \
+})
+
+#define __IS_SUBPLATFORM(dev_priv, p, s) \
+({ \
+ const unsigned int pbits__ = \
+ BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
+ INTEL_SUBPLATFORM_BITS; \
+ const unsigned int pi__ = (p) / pbits__; \
+ const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
+\
+ BUILD_BUG_ON(!__builtin_constant_p(p)); \
+ BUILD_BUG_ON(!__builtin_constant_p(s)); \
+ BUILD_BUG_ON((s) >= INTEL_SUBPLATFORM_BITS); \
+\
+ (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & (BIT(pb__) | BIT(s))); \
+})
+
+static inline bool
+IS_PLATFORM(const struct
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Introduce concept of a sub-platform
== Series Details == Series: drm/i915: Introduce concept of a sub-platform URL : https://patchwork.freedesktop.org/series/58056/ State : failure == Summary == Applying: drm/i915: Introduce concept of a sub-platform Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_pci.c M drivers/gpu/drm/i915/intel_device_info.c M drivers/gpu/drm/i915/intel_device_info.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_device_info.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_device_info.h Auto-merging drivers/gpu/drm/i915/intel_device_info.c Auto-merging drivers/gpu/drm/i915/i915_pci.c Auto-merging drivers/gpu/drm/i915/i915_drv.h Auto-merging drivers/gpu/drm/i915/i915_drv.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: Introduce concept of a sub-platform 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] ✓ Fi.CI.BAT: success for drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h (rev2)
== Series Details ==
Series: drm/i915: Move intel_engine_mask_t around for use by
i915_request_types.h (rev2)
URL : https://patchwork.freedesktop.org/series/58052/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12474
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/58052/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12474 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-kbl-7567u: NOTRUN -> SKIP [fdo#109271] +33
* igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103
* igt@gem_exec_basic@readonly-bsd2:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720]
* igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g: NOTRUN -> SKIP [fdo#109271] +65
* igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +33
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS +1
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
Participating hosts (44 -> 41)
--
Additional (4): fi-kbl-7567u fi-kbl-8809g fi-bwr-2160 fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan
fi-ctg-p8600 fi-icl-u3
Build changes
-
* Linux: CI_DRM_5753 -> Patchwork_12474
CI_DRM_5753: 0eb0838c0c26378949de6816166117c8b2d73caa @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4887: 5a7c7575b5bb9542f722ed6ba095b9d62609cd56 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12474: e779e84e20f333bc006e3f76b94f6d9eb286878c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e779e84e20f3 drm/i915: Move intel_engine_mask_t around for use by
i915_request_types.h
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12474/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/21] drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.h| 5 +
drivers/gpu/drm/i915/i915_gem_context.c| 126 -
drivers/gpu/drm/i915/i915_scheduler.c | 18 +-
drivers/gpu/drm/i915/i915_timeline_types.h | 1 +
drivers/gpu/drm/i915/intel_engine_types.h | 8 +
drivers/gpu/drm/i915/intel_lrc.c | 570 -
drivers/gpu/drm/i915/intel_lrc.h | 11 +
drivers/gpu/drm/i915/selftests/intel_lrc.c | 165 ++
include/uapi/drm/i915_drm.h| 30 ++
9 files changed, 915 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5c073fe73664..3ca855505715 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -96,4 +96,9 @@ static inline bool __tasklet_enable(struct tasklet_struct *t)
return atomic_dec_and_test(&t->count);
}
+static inline bool __tasklet_is_scheduled(struct tasklet_struct *t)
+{
+ return test_bit(TASKLET_STATE_SCHED, &t->state);
+}
+
#endif /* __I915_GEM_H__ */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 4a8437a5b30c..6108695e5fc1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -86,6 +86,7 @@
*/
#include
+#include
#include
@@ -94,6 +95,7 @@
#include "i915_trace.h"
#include "i915_user_extensions.h"
#include "intel_lrc_reg.h"
+#include "intel_lrc.h"
#include "intel_workarounds.h"
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
@@ -241,6 +243,20 @@ static void release_hw_id(struct i915_gem_context *ctx)
mutex_unlock(&i915->contexts.mutex);
}
+static void free_engines(struct intel_engine_cs **engines, int count)
+{
+ int i;
+
+ if (ZERO_OR_NULL_PTR(engines))
+ return;
+
+ /* We own the veng we created; regular engines are ignored */
+ for (i = 0; i < count; i++)
+ intel_virtual_engine_destroy(engines[i]);
+
+ kfree(engines);
+}
+
static void i915_gem_context_free(struct i915_gem_context *ctx)
{
struct intel_context *it, *n;
@@ -251,8 +267,7 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
[Intel-gfx] [PATCH 19/21] drm/i915: Extend execution fence to support a callback
In the next patch, we will want to configure the slave request
depending on which physical engine the master request is executed on.
For this, we introduce a callback from the execute fence to convey this
information.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 84 +++--
drivers/gpu/drm/i915/i915_request.h | 4 ++
2 files changed, 83 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 2382339172b4..0a46f8113f5c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -38,6 +38,8 @@ struct execute_cb {
struct list_head link;
struct irq_work work;
struct i915_sw_fence *fence;
+ void (*hook)(struct i915_request *rq, struct dma_fence *signal);
+ struct i915_request *signal;
};
static struct i915_global_request {
@@ -343,6 +345,17 @@ static void irq_execute_cb(struct irq_work *wrk)
kmem_cache_free(global.slab_execute_cbs, cb);
}
+static void irq_execute_cb_hook(struct irq_work *wrk)
+{
+ struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
+
+ cb->hook(container_of(cb->fence, struct i915_request, submit),
+&cb->signal->fence);
+ i915_request_put(cb->signal);
+
+ irq_execute_cb(wrk);
+}
+
static void __notify_execute_cb(struct i915_request *rq)
{
struct execute_cb *cb;
@@ -369,14 +382,19 @@ static void __notify_execute_cb(struct i915_request *rq)
}
static int
-i915_request_await_execution(struct i915_request *rq,
-struct i915_request *signal,
-gfp_t gfp)
+__i915_request_await_execution(struct i915_request *rq,
+ struct i915_request *signal,
+ void (*hook)(struct i915_request *rq,
+ struct dma_fence *signal),
+ gfp_t gfp)
{
struct execute_cb *cb;
- if (i915_request_is_active(signal))
+ if (i915_request_is_active(signal)) {
+ if (hook)
+ hook(rq, &signal->fence);
return 0;
+ }
cb = kmem_cache_alloc(global.slab_execute_cbs, gfp);
if (!cb)
@@ -386,8 +404,18 @@ i915_request_await_execution(struct i915_request *rq,
i915_sw_fence_await(cb->fence);
init_irq_work(&cb->work, irq_execute_cb);
+ if (hook) {
+ cb->hook = hook;
+ cb->signal = i915_request_get(signal);
+ cb->work.func = irq_execute_cb_hook;
+ }
+
spin_lock_irq(&signal->lock);
if (i915_request_is_active(signal)) {
+ if (hook) {
+ hook(rq, &signal->fence);
+ i915_request_put(signal);
+ }
i915_sw_fence_complete(cb->fence);
kmem_cache_free(global.slab_execute_cbs, cb);
} else {
@@ -790,7 +818,7 @@ emit_semaphore_wait(struct i915_request *to,
return err;
/* Only submit our spinner after the signaler is running! */
- err = i915_request_await_execution(to, from, gfp);
+ err = __i915_request_await_execution(to, from, NULL, gfp);
if (err)
return err;
@@ -910,6 +938,52 @@ i915_request_await_dma_fence(struct i915_request *rq,
struct dma_fence *fence)
return 0;
}
+int
+i915_request_await_execution(struct i915_request *rq,
+struct dma_fence *fence,
+void (*hook)(struct i915_request *rq,
+ struct dma_fence *signal))
+{
+ struct dma_fence **child = &fence;
+ unsigned int nchild = 1;
+ int ret;
+
+ if (dma_fence_is_array(fence)) {
+ struct dma_fence_array *array = to_dma_fence_array(fence);
+
+ /* XXX Error for signal-on-any fence arrays */
+
+ child = array->fences;
+ nchild = array->num_fences;
+ GEM_BUG_ON(!nchild);
+ }
+
+ do {
+ fence = *child++;
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ continue;
+
+ /*
+* We don't squash repeated fence dependencies here as we
+* want to run our callback in all cases.
+*/
+
+ if (dma_fence_is_i915(fence))
+ ret = __i915_request_await_execution(rq,
+to_request(fence),
+hook,
+I915_FENCE_GFP);
+ else
+ ret = i915_sw_fence_await_dma_fence(&rq->submit, fence,
+
[Intel-gfx] [PATCH 06/21] drm/i915: Stop needlessly acquiring wakeref for debugfs/drop_caches_set
We only need to acquire a wakeref for ourselves for a few operations, as
most either already acquire their own wakeref or imply a wakeref. In
particular, it is i915_gem_set_wedged() that needed us to present it
with a wakeref, which is incongruous with its "use anywhere" ability.
Suggested-by: Yokoyama, Caz
Signed-off-by: Chris Wilson
Cc: Yokoyama, Caz
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 12
drivers/gpu/drm/i915/i915_reset.c | 4 +++-
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6a90558de213..08683dca7775 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3888,12 +3888,9 @@ static int
i915_drop_caches_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
- intel_wakeref_t wakeref;
- int ret = 0;
DRM_DEBUG("Dropping caches: 0x%08llx [0x%08llx]\n",
val, val & DROP_ALL);
- wakeref = intel_runtime_pm_get(i915);
if (val & DROP_RESET_ACTIVE &&
wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT))
@@ -3902,9 +3899,11 @@ i915_drop_caches_set(void *data, u64 val)
/* No need to check and wait for gpu resets, only libdrm auto-restarts
* on ioctls on -EAGAIN. */
if (val & (DROP_ACTIVE | DROP_RETIRE | DROP_RESET_SEQNO)) {
+ int ret;
+
ret = mutex_lock_interruptible(&i915->drm.struct_mutex);
if (ret)
- goto out;
+ return ret;
if (val & DROP_ACTIVE)
ret = i915_gem_wait_for_idle(i915,
@@ -3943,10 +3942,7 @@ i915_drop_caches_set(void *data, u64 val)
if (val & DROP_FREED)
i915_gem_drain_freed_objects(i915);
-out:
- intel_runtime_pm_put(i915, wakeref);
-
- return ret;
+ return 0;
}
DEFINE_SIMPLE_ATTRIBUTE(i915_drop_caches_fops,
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 5f40725ca428..6cc40f15fccb 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -863,9 +863,11 @@ static void __i915_gem_set_wedged(struct drm_i915_private
*i915)
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
struct i915_gpu_error *error = &i915->gpu_error;
+ intel_wakeref_t wakeref;
mutex_lock(&error->wedge_mutex);
- __i915_gem_set_wedged(i915);
+ with_intel_runtime_pm(i915, wakeref)
+ __i915_gem_set_wedged(i915);
mutex_unlock(&error->wedge_mutex);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/21] drm/i915/execlists: Virtual engine bonding
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual engine may select given a fence on a master engine.
For the moment, we continue to ignore the issue of preemption deferring
the master request for later. Ideally, we would like to then also remove
the slave and run something else rather than have it stall the pipeline.
With load balancing, we should be able to move workload around it, but
there is a similar stall on the master pipeline while it may wait for
the slave to be executed. At the cost of more latency for the bonded
request, it may be interesting to launch both on their engines in
lockstep. (Bubbles abound.)
Opens: Also what about bonding an engine as its own master? It doesn't
break anything internally, so allow the silliness.
v2: Emancipate the bonds
v3: Couple in delayed scheduling for the selftests
v4: Handle invalid mutually exclusive bonding
v5: Mention what the uapi does
v6: s/nbond/num_bonds/
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 50 +
drivers/gpu/drm/i915/i915_request.c | 1 +
drivers/gpu/drm/i915/i915_request.h | 3 +
drivers/gpu/drm/i915/intel_engine_types.h | 7 +
drivers/gpu/drm/i915/intel_lrc.c | 143 ++
drivers/gpu/drm/i915/intel_lrc.h | 4 +
drivers/gpu/drm/i915/selftests/intel_lrc.c| 185 ++
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 3 +
include/uapi/drm/i915_drm.h | 33
9 files changed, 429 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 6108695e5fc1..efbb07b9af53 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1532,8 +1532,58 @@ set_engines__load_balance(struct i915_user_extension
__user *base, void *data)
return 0;
}
+static int
+set_engines__bond(struct i915_user_extension __user *base, void *data)
+{
+ struct i915_context_engines_bond __user *ext =
+ container_of_user(base, typeof(*ext), base);
+ const struct set_engines *set = data;
+ unsigned int idx, class, instance;
+ struct intel_engine_cs *master;
+ u64 siblings;
+ int err;
+
+ if (get_user(idx, &ext->virtual_index))
+ return -EFAULT;
+
+ if (idx >= set->num_engines)
+ return -EINVAL;
+
+ idx = array_index_nospec(idx, set->num_engines);
+ if (!set->engines[idx])
+ return -EINVAL;
+
+ /*
+* A non-virtual engine has 0 siblings to choose between; and submit
+* fence will always be directed to the one engine.
+*/
+ if (!intel_engine_is_virtual(set->engines[idx]))
+ return 0;
+
+ err = check_user_mbz(&ext->mbz);
+ if (err)
+ return err;
+
+ if (get_user(class, &ext->master_class))
+ return -EFAULT;
+
+ if (get_user(instance, &ext->master_instance))
+ return -EFAULT;
+
+ master = intel_engine_lookup_user(set->ctx->i915, class, instance);
+ if (!master)
+ return -EINVAL;
+
+ if (get_user(siblings, &ext->sibling_mask))
+ return -EFAULT;
+
+ return intel_virtual_engine_attach_bond(set->engines[idx],
+ master, siblings);
+}
+
static const i915_user_extension_fn set_engines__extensions[] = {
[I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE] = set_engines__load_balance,
+ [I915_CONTEXT_ENGINES_EXT_BOND] = set_engines__bond,
};
static int
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0a46f8113f5c..2d209519a6d5 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -743,6 +743,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->batch = NULL;
rq->capture_list = NULL;
rq->waitboost = false;
+ INIT_ALL_ENGINES(rq->execution_mask);
/*
* Reserve space in the ring buffer for all the commands required to
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index d4f6b2940130..5bdab6881b13 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -32,6 +32,8 @@
#include "i915_selftest.h"
#include "i915_sw_fence.h"
+#include "intel_engine_types.h"
+
#include
struct drm_file;
@@ -145,6 +147,7 @@ struct i915_request {
*/
struct i915_sched_node sched;
struct i915_dependency dep;
+ intel_engine_mask_t execution_mask;
/*
* A convenience pointer to
[Intel-gfx] [PATCH 11/21] drm/i915: Introduce the i915_user_extension_method
An idea for extending uABI inspired by Vulkan's extension chains.
Instead of expanding the data struct for each ioctl every time we need
to add a new feature, define an extension chain instead. As we add
optional interfaces to control the ioctl, we define a new extension
struct that can be linked into the ioctl data only when required by the
user. The key advantage being able to ignore large control structs for
optional interfaces/extensions, while being able to process them in a
consistent manner.
In comparison to other extensible ioctls, the key difference is the
use of a linked chain of extension structs vs an array of tagged
pointers. For example,
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
__u32 length_dw;
__u64 chunk_data;
};
struct drm_amdgpu_cs_in {
__u32 ctx_id;
__u32 bo_list_handle;
__u32 num_chunks;
__u32 _pad;
__u64 chunks;
};
allows userspace to pass in array of pointers to extension structs, but
must therefore keep constructing that array along side the command stream.
In dynamic situations like that, a linked list is preferred and does not
similar from extra cache line misses as the extension structs themselves
must still be loaded separate to the chunks array.
v2: Apply the tail call optimisation directly to nip the worry of stack
overflow in the bud.
v3: Defend against recursion.
v4: Fixup local types to match new uabi
Opens:
- do we include the result as an out-field in each chain?
struct i915_user_extension {
__u64 next_extension;
__u64 name;
__s32 result;
__u32 mbz; /* reserved for future use */
};
* Undecided, so provision some room for future expansion.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_user_extensions.c | 61 +
drivers/gpu/drm/i915/i915_user_extensions.h | 20 +++
drivers/gpu/drm/i915/i915_utils.h | 31 +++
include/uapi/drm/i915_drm.h | 22
5 files changed, 135 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_user_extensions.c
create mode 100644 drivers/gpu/drm/i915/i915_user_extensions.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 197b081769b5..1f3e8b145fc0 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -46,6 +46,7 @@ i915-y := i915_drv.o \
i915_sw_fence.o \
i915_syncmap.o \
i915_sysfs.o \
+ i915_user_extensions.o \
intel_csr.o \
intel_device_info.o \
intel_pm.o \
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
b/drivers/gpu/drm/i915/i915_user_extensions.c
new file mode 100644
index ..c822d0aafd2d
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -0,0 +1,61 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "i915_user_extensions.h"
+#include "i915_utils.h"
+
+int i915_user_extensions(struct i915_user_extension __user *ext,
+const i915_user_extension_fn *tbl,
+unsigned int count,
+void *data)
+{
+ unsigned int stackdepth = 512;
+
+ while (ext) {
+ int i, err;
+ u32 name;
+ u64 next;
+
+ if (!stackdepth--) /* recursion vs useful flexibility */
+ return -E2BIG;
+
+ err = check_user_mbz(&ext->flags);
+ if (err)
+ return err;
+
+ for (i = 0; i < ARRAY_SIZE(ext->rsvd); i++) {
+ err = check_user_mbz(&ext->rsvd[i]);
+ if (err)
+ return err;
+ }
+
+ if (get_user(name, &ext->name))
+ return -EFAULT;
+
+ err = -EINVAL;
+ if (name < count) {
+ name = array_index_nospec(name, count);
+ if (tbl[name])
+ err = tbl[name](ext, data);
+ }
+ if (err)
+ return err;
+
+ if (get_user(next, &ext->next_extension) ||
+ overflows_type(next, ext))
+ return -EFAULT;
+
+ ext = u64_to_user_ptr(next);
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.h
b/drivers/gpu/drm/i915/i915_user_extensions.h
new file mode 100644
index ..a14bf6bba9a1
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_user_extensions.h
@@ -0,0 +1,20 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef I915_USER_EXTENSI
[Intel-gfx] [PATCH 09/21] drm/i915: Separate GEM context construction and registration to userspace
In later patches, it became apparent that userspace can see a partially
constructed GEM context and begin using it before it was ready, to much
hilarity. Close this window of opportunity by lifting the registration of
the context with userspace (the insertion of the context into the filp's
idr) to the very end of the CONTEXT_CREATE ioctl.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 143 +++---
drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +-
drivers/gpu/drm/i915/i915_gem_gtt.h | 8 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 12 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/selftests/mock_context.c | 17 ++-
7 files changed, 116 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index d776d43707e0..5df3d423ec6c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -337,15 +337,13 @@ static u32 default_desc_template(const struct
drm_i915_private *i915,
}
static struct i915_gem_context *
-__create_hw_context(struct drm_i915_private *dev_priv,
- struct drm_i915_file_private *file_priv)
+__create_context(struct drm_i915_private *dev_priv)
{
struct i915_gem_context *ctx;
- int ret;
int i;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (ctx == NULL)
+ if (!ctx)
return ERR_PTR(-ENOMEM);
kref_init(&ctx->ref);
@@ -362,29 +360,6 @@ __create_hw_context(struct drm_i915_private *dev_priv,
INIT_LIST_HEAD(&ctx->handles_list);
INIT_LIST_HEAD(&ctx->hw_id_link);
- /* Default context will never have a file_priv */
- ret = DEFAULT_CONTEXT_HANDLE;
- if (file_priv) {
- ret = idr_alloc(&file_priv->context_idr, ctx,
- DEFAULT_CONTEXT_HANDLE, 0, GFP_KERNEL);
- if (ret < 0)
- goto err_lut;
- }
- ctx->user_handle = ret;
-
- ctx->file_priv = file_priv;
- if (file_priv) {
- ctx->pid = get_task_pid(current, PIDTYPE_PID);
- ctx->name = kasprintf(GFP_KERNEL, "%s[%d]/%x",
- current->comm,
- pid_nr(ctx->pid),
- ctx->user_handle);
- if (!ctx->name) {
- ret = -ENOMEM;
- goto err_pid;
- }
- }
-
/* NB: Mark all slices as needing a remap so that when the context first
* loads it will restore whatever remap state already exists. If there
* is no remap info, it will be a NOP. */
@@ -401,25 +376,10 @@ __create_hw_context(struct drm_i915_private *dev_priv,
ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
return ctx;
-
-err_pid:
- put_pid(ctx->pid);
- idr_remove(&file_priv->context_idr, ctx->user_handle);
-err_lut:
- context_close(ctx);
- return ERR_PTR(ret);
-}
-
-static void __destroy_hw_context(struct i915_gem_context *ctx,
-struct drm_i915_file_private *file_priv)
-{
- idr_remove(&file_priv->context_idr, ctx->user_handle);
- context_close(ctx);
}
static struct i915_gem_context *
-i915_gem_create_context(struct drm_i915_private *dev_priv,
- struct drm_i915_file_private *file_priv)
+i915_gem_create_context(struct drm_i915_private *dev_priv)
{
struct i915_gem_context *ctx;
@@ -428,18 +388,18 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
/* Reap the most stale context */
contexts_free_first(dev_priv);
- ctx = __create_hw_context(dev_priv, file_priv);
+ ctx = __create_context(dev_priv);
if (IS_ERR(ctx))
return ctx;
if (HAS_FULL_PPGTT(dev_priv)) {
struct i915_hw_ppgtt *ppgtt;
- ppgtt = i915_ppgtt_create(dev_priv, file_priv);
+ ppgtt = i915_ppgtt_create(dev_priv);
if (IS_ERR(ppgtt)) {
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
PTR_ERR(ppgtt));
- __destroy_hw_context(ctx, file_priv);
+ context_close(ctx);
return ERR_CAST(ppgtt);
}
@@ -475,7 +435,7 @@ i915_gem_context_create_gvt(struct drm_device *dev)
if (ret)
return ERR_PTR(ret);
- ctx = i915_gem_create_context(to_i915(dev), NULL);
+ ctx = i915_gem_create_context(to_i915(dev));
if (IS_ERR(ctx))
goto out;
@@ -511,7 +471,7 @@ i915_gem_context_create_kernel(struct drm_i915_private
*i915, int prio)
struct i915_gem_context *ctx;
[Intel-gfx] [PATCH 15/21] drm/i915: Allow userspace to clone contexts on creation
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient if they were able to just pass in a target context to clone
during creation. This essentially extends the setparam during creation
to pull the details from a target context instead of the user supplied
parameters.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 149
include/uapi/drm/i915_drm.h | 14 +++
2 files changed, 163 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 57b4e760fa4b..1c0861f77dca 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1513,8 +1513,157 @@ static int create_setparam(struct i915_user_extension
__user *ext, void *data)
return ctx_setparam(arg->ctx, &local.param);
}
+static int clone_flags(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ dst->user_flags = src->user_flags;
+ return 0;
+}
+
+static int clone_schedattr(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ dst->sched = src->sched;
+ return 0;
+}
+
+static int clone_sseu(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ const struct intel_sseu default_sseu =
+ intel_device_default_sseu(dst->i915);
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, dst->i915, id) {
+ struct intel_context *ce;
+ struct intel_sseu sseu;
+
+ ce = intel_context_lookup(src, engine);
+ if (!ce)
+ continue;
+
+ sseu = ce->sseu;
+ if (!memcmp(&sseu, &default_sseu, sizeof(sseu)))
+ continue;
+
+ ce = intel_context_pin_lock(dst, engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ ce->sseu = sseu;
+ intel_context_pin_unlock(ce);
+ }
+
+ return 0;
+}
+
+static int clone_timeline(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ if (src->timeline) {
+ GEM_BUG_ON(src->timeline == dst->timeline);
+
+ if (dst->timeline)
+ i915_timeline_put(dst->timeline);
+ dst->timeline = i915_timeline_get(src->timeline);
+ }
+
+ return 0;
+}
+
+static int clone_vm(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ struct i915_hw_ppgtt *ppgtt;
+
+ rcu_read_lock();
+ do {
+ ppgtt = READ_ONCE(src->ppgtt);
+ if (!ppgtt)
+ break;
+
+ if (!kref_get_unless_zero(&ppgtt->ref))
+ continue;
+
+ /*
+* This ppgtt may have be reallocated between
+* the read and the kref, and reassigned to a third
+* context. In order to avoid inadvertent sharing
+* of this ppgtt with that third context (and not
+* src), we have to confirm that we have the same
+* ppgtt after passing through the strong memory
+* barrier implied by a successful
+* kref_get_unless_zero().
+*
+* Once we have acquired the current ppgtt of src,
+* we no longer care if it is released from src, as
+* it cannot be reallocated elsewhere.
+*/
+
+ if (ppgtt == READ_ONCE(src->ppgtt))
+ break;
+
+ i915_ppgtt_put(ppgtt);
+ } while (1);
+ rcu_read_unlock();
+
+ if (ppgtt) {
+ __assign_ppgtt(dst, ppgtt);
+ i915_ppgtt_put(ppgtt);
+ }
+
+ return 0;
+}
+
+static int create_clone(struct i915_user_extension __user *ext, void *data)
+{
+ static int (* const fn[])(struct i915_gem_context *dst,
+ struct i915_gem_context *src) = {
+ [ilog2(I915_CONTEXT_CLONE_FLAGS)] = clone_flags,
+ [ilog2(I915_CONTEXT_CLONE_SCHEDATTR)] = clone_schedattr,
+ [ilog2(I915_CONTEXT_CLONE_SSEU)] = clone_sseu,
+ [ilog2(I915_CONTEXT_CLONE_TIMELINE)] = clone_timeline,
+ [ilog2(I915_CONTEXT_CLONE_VM)] = clone_vm,
+ };
+ struct drm_i915_gem_context_create_ext_clone local;
+ const struct create_ext *arg = data;
+ struct i915_gem_context *dst = arg->ctx;
+ struct i915_gem_context *src;
+ int err, bit;
+
+ if (copy_from_user(&local
[Intel-gfx] [PATCH 17/21] drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[]
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on virtual engines that
are local to the context and do not have a valid global class:instance
lookup.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 24
include/uapi/drm/i915_drm.h | 3 ++-
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 40f1a8fa1a05..4a8437a5b30c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1394,6 +1394,7 @@ static int set_sseu(struct i915_gem_context *ctx,
struct drm_i915_gem_context_param_sseu user_sseu;
struct intel_engine_cs *engine;
struct intel_sseu sseu;
+ unsigned long lookup;
int ret;
if (args->size < sizeof(user_sseu))
@@ -1406,10 +1407,17 @@ static int set_sseu(struct i915_gem_context *ctx,
sizeof(user_sseu)))
return -EFAULT;
- if (user_sseu.flags || user_sseu.rsvd)
+ if (user_sseu.rsvd)
return -EINVAL;
- engine = lookup_user_engine(ctx, 0,
+ if (user_sseu.flags & ~(I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX))
+ return -EINVAL;
+
+ lookup = 0;
+ if (user_sseu.flags & I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX)
+ lookup |= LOOKUP_USER_INDEX;
+
+ engine = lookup_user_engine(ctx, lookup,
user_sseu.engine_class,
user_sseu.engine_instance);
if (!engine)
@@ -1979,6 +1987,7 @@ static int get_sseu(struct i915_gem_context *ctx,
struct drm_i915_gem_context_param_sseu user_sseu;
struct intel_engine_cs *engine;
struct intel_context *ce;
+ unsigned long lookup;
if (args->size == 0)
goto out;
@@ -1989,10 +1998,17 @@ static int get_sseu(struct i915_gem_context *ctx,
sizeof(user_sseu)))
return -EFAULT;
- if (user_sseu.flags || user_sseu.rsvd)
+ if (user_sseu.rsvd)
return -EINVAL;
- engine = lookup_user_engine(ctx, 0,
+ if (user_sseu.flags & ~(I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX))
+ return -EINVAL;
+
+ lookup = 0;
+ if (user_sseu.flags & I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX)
+ lookup |= LOOKUP_USER_INDEX;
+
+ engine = lookup_user_engine(ctx, lookup,
user_sseu.engine_class,
user_sseu.engine_instance);
if (!engine)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 4e67c2395b46..8ef6d60929c6 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1567,9 +1567,10 @@ struct drm_i915_gem_context_param_sseu {
__u16 engine_instance;
/*
-* Unused for now. Must be cleared to zero.
+* Unknown flags must be cleared to zero.
*/
__u32 flags;
+#define I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX (1u << 0)
/*
* Mask of slices to enable for the context. Valid values are a subset
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/21] drm/i915: Extend CONTEXT_CREATE to set parameters upon construction
It can be useful to have a single ioctl to create a context with all
the initial parameters instead of a series of create + setparam + setparam
ioctls. This extension to create context allows any of the parameters
to be passed in as a linked list to be applied to the newly constructed
context.
v2: Make a local copy of user setparam (Tvrtko)
v3: Use flags to detect availability of extension interface
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_gem_context.c | 454 +---
include/uapi/drm/i915_drm.h | 180 +-
3 files changed, 353 insertions(+), 283 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index fa991144e0f2..9a0fa3b21e9d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -3110,7 +3110,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY,
intel_sprite_set_colorkey_ioctl, DRM_MASTER),
DRM_IOCTL_DEF_DRV(I915_GET_SPRITE_COLORKEY, drm_noop, DRM_MASTER),
DRM_IOCTL_DEF_DRV(I915_GEM_WAIT, i915_gem_wait_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE,
i915_gem_context_create_ioctl, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE_EXT,
i915_gem_context_create_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_DESTROY,
i915_gem_context_destroy_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_RESET_STATS,
i915_gem_context_reset_stats_ioctl, DRM_RENDER_ALLOW),
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index c392f7af5546..0d72e0cadde8 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1115,196 +1115,6 @@ static int set_ppgtt(struct i915_gem_context *ctx,
return err;
}
-static bool client_is_banned(struct drm_i915_file_private *file_priv)
-{
- return atomic_read(&file_priv->ban_score) >= I915_CLIENT_SCORE_BANNED;
-}
-
-int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file)
-{
- struct drm_i915_private *i915 = to_i915(dev);
- struct drm_i915_gem_context_create *args = data;
- struct drm_i915_file_private *file_priv = file->driver_priv;
- struct i915_gem_context *ctx;
- int ret;
-
- if (!DRIVER_CAPS(i915)->has_logical_contexts)
- return -ENODEV;
-
- if (args->pad != 0)
- return -EINVAL;
-
- ret = i915_terminally_wedged(i915);
- if (ret)
- return ret;
-
- if (client_is_banned(file_priv)) {
- DRM_DEBUG("client %s[%d] banned from creating ctx\n",
- current->comm,
- pid_nr(get_task_pid(current, PIDTYPE_PID)));
-
- return -EIO;
- }
-
- ret = i915_mutex_lock_interruptible(dev);
- if (ret)
- return ret;
-
- ctx = i915_gem_create_context(i915);
- mutex_unlock(&dev->struct_mutex);
- if (IS_ERR(ctx))
- return PTR_ERR(ctx);
-
- ret = gem_context_register(ctx, file_priv);
- if (ret)
- goto err_ctx;
-
- args->ctx_id = ctx->user_handle;
- DRM_DEBUG("HW context %d created\n", args->ctx_id);
-
- return 0;
-
-err_ctx:
- mutex_lock(&dev->struct_mutex);
- context_close(ctx);
- mutex_unlock(&dev->struct_mutex);
- return ret;
-}
-
-int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file)
-{
- struct drm_i915_gem_context_destroy *args = data;
- struct drm_i915_file_private *file_priv = file->driver_priv;
- struct i915_gem_context *ctx;
-
- if (args->pad != 0)
- return -EINVAL;
-
- if (args->ctx_id == DEFAULT_CONTEXT_HANDLE)
- return -ENOENT;
-
- mutex_lock(&file_priv->context_lock);
- ctx = idr_remove(&file_priv->context_idr, args->ctx_id);
- mutex_lock(&file_priv->context_lock);
- if (!ctx)
- return -ENOENT;
-
- mutex_lock(&dev->struct_mutex);
- context_close(ctx);
- mutex_unlock(&dev->struct_mutex);
-
- return 0;
-}
-
-static int get_sseu(struct i915_gem_context *ctx,
- struct drm_i915_gem_context_param *args)
-{
- struct drm_i915_gem_context_param_sseu user_sseu;
- struct intel_engine_cs *engine;
- struct intel_context *ce;
-
- if (args->size == 0)
- goto out;
- else if (args->size < sizeof(user_sseu))
- return -EINVAL;
-
- if (copy_from_user(&user_sseu, u64_to_user_ptr(args->value),
- sizeof(use
[Intel-gfx] [PATCH 14/21] drm/i915: Allow contexts to share a single timeline across all engines
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the user level the context often
represents a single timeline (e.g. GL contexts) and userspace must
ensure that the individual engines are serialised to present that
ordering to the client (or forgot about this detail entirely and hope no
one notices - a fair ploy if the client can only directly control one
engine themselves ;)
In the next patch, we will want to construct a set of engines that
operate as one, that have a single timeline interwoven between them, to
present a single virtual engine to the user. (They submit to the virtual
engine, then we decide which engine to execute on based.)
To that end, we want to be able to create contexts which have a single
timeline (fence context) shared between all engines, rather than multiple
timelines.
v2: Move the specialised timeline ordering to its own function.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 31 +--
drivers/gpu/drm/i915/i915_gem_context_types.h | 2 +
drivers/gpu/drm/i915/i915_request.c | 80 +--
drivers/gpu/drm/i915/i915_request.h | 5 +-
drivers/gpu/drm/i915/i915_sw_fence.c | 39 +++--
drivers/gpu/drm/i915/i915_sw_fence.h | 13 ++-
drivers/gpu/drm/i915/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/selftests/mock_context.c | 2 +-
include/uapi/drm/i915_drm.h | 3 +-
9 files changed, 138 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 0d72e0cadde8..57b4e760fa4b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -238,6 +238,9 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
rbtree_postorder_for_each_entry_safe(it, n, &ctx->hw_contexts, node)
intel_context_put(it);
+ if (ctx->timeline)
+ i915_timeline_put(ctx->timeline);
+
kfree(ctx->name);
put_pid(ctx->pid);
@@ -403,12 +406,16 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
}
static struct i915_gem_context *
-i915_gem_create_context(struct drm_i915_private *dev_priv)
+i915_gem_create_context(struct drm_i915_private *dev_priv, unsigned int flags)
{
struct i915_gem_context *ctx;
lockdep_assert_held(&dev_priv->drm.struct_mutex);
+ if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
+ !HAS_EXECLISTS(dev_priv))
+ return ERR_PTR(-EINVAL);
+
/* Reap the most stale context */
contexts_free_first(dev_priv);
@@ -431,6 +438,18 @@ i915_gem_create_context(struct drm_i915_private *dev_priv)
i915_ppgtt_put(ppgtt);
}
+ if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
+ struct i915_timeline *timeline;
+
+ timeline = i915_timeline_create(dev_priv, ctx->name, NULL);
+ if (IS_ERR(timeline)) {
+ context_close(ctx);
+ return ERR_CAST(timeline);
+ }
+
+ ctx->timeline = timeline;
+ }
+
trace_i915_context_create(ctx);
return ctx;
@@ -459,7 +478,7 @@ i915_gem_context_create_gvt(struct drm_device *dev)
if (ret)
return ERR_PTR(ret);
- ctx = i915_gem_create_context(to_i915(dev));
+ ctx = i915_gem_create_context(to_i915(dev), 0);
if (IS_ERR(ctx))
goto out;
@@ -495,7 +514,7 @@ i915_gem_context_create_kernel(struct drm_i915_private
*i915, int prio)
struct i915_gem_context *ctx;
int err;
- ctx = i915_gem_create_context(i915);
+ ctx = i915_gem_create_context(i915, 0);
if (IS_ERR(ctx))
return ctx;
@@ -670,7 +689,7 @@ int i915_gem_context_open(struct drm_i915_private *i915,
idr_init_base(&file_priv->vm_idr, 1);
mutex_lock(&i915->drm.struct_mutex);
- ctx = i915_gem_create_context(i915);
+ ctx = i915_gem_create_context(i915, 0);
mutex_unlock(&i915->drm.struct_mutex);
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
@@ -812,7 +831,7 @@ last_request_on_engine(struct i915_timeline *timeline,
rq = i915_active_request_raw(&timeline->last_request,
&engine->i915->drm.struct_mutex);
- if (rq && rq->engine == engine) {
+ if (rq && rq->engine->mask & engine->mask) {
GEM_TRACE("last request for %s on engine %s: %llx:%llu\n",
timeline->name, engine->name,
rq->fence.context, rq->fence.seqno);
@@ -1533,7 +1552,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
[Intel-gfx] [PATCH 04/21] drm/i915: Lock the gem_context->active_list while dropping the link
On unpinning the intel_context, we remove it from the active list
inside the GEM context. This list is supposed to be guarded by the GEM
context mutex, so remember to take it!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_context.c | 15 +++
drivers/gpu/drm/i915/intel_lrc.c | 3 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 ---
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 --
4 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_context.c
b/drivers/gpu/drm/i915/intel_context.c
index 5a16c9bb2778..0ab894a058f6 100644
--- a/drivers/gpu/drm/i915/intel_context.c
+++ b/drivers/gpu/drm/i915/intel_context.c
@@ -165,13 +165,13 @@ intel_context_pin(struct i915_gem_context *ctx,
if (err)
goto err;
+ i915_gem_context_get(ctx);
+ GEM_BUG_ON(ce->gem_context != ctx);
+
mutex_lock(&ctx->mutex);
list_add(&ce->active_link, &ctx->active_engines);
mutex_unlock(&ctx->mutex);
- i915_gem_context_get(ctx);
- GEM_BUG_ON(ce->gem_context != ctx);
-
smp_mb__before_atomic(); /* flush pin before it is visible */
}
@@ -194,9 +194,16 @@ void intel_context_unpin(struct intel_context *ce)
/* We may be called from inside intel_context_pin() to evict another */
mutex_lock_nested(&ce->pin_mutex, SINGLE_DEPTH_NESTING);
- if (likely(atomic_dec_and_test(&ce->pin_count)))
+ if (likely(atomic_dec_and_test(&ce->pin_count))) {
ce->ops->unpin(ce);
+ mutex_lock(&ce->gem_context->mutex);
+ list_del(&ce->active_link);
+ mutex_unlock(&ce->gem_context->mutex);
+
+ i915_gem_context_put(ce->gem_context);
+ }
+
mutex_unlock(&ce->pin_mutex);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5089dec3074e..186a1b9d6014 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1283,9 +1283,6 @@ static void execlists_context_unpin(struct intel_context
*ce)
ce->state->obj->pin_global--;
i915_gem_object_unpin_map(ce->state->obj);
i915_vma_unpin(ce->state);
-
- list_del(&ce->active_link);
- i915_gem_context_put(ce->gem_context);
}
static int __context_pin(struct i915_vma *vma)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ebac752e092d..175070ea0f50 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1434,9 +1434,6 @@ static void ring_context_unpin(struct intel_context *ce)
{
__context_unpin_ppgtt(ce->gem_context);
__context_unpin(ce);
-
- list_del(&ce->active_link);
- i915_gem_context_put(ce->gem_context);
}
static struct i915_vma *
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index 881450c694e9..7641b74ada98 100644
--- a/drivers/gpu/drm/i915/selftests/mock_engine.c
+++ b/drivers/gpu/drm/i915/selftests/mock_engine.c
@@ -126,8 +126,6 @@ static void hw_delay_complete(struct timer_list *t)
static void mock_context_unpin(struct intel_context *ce)
{
mock_timeline_unpin(ce->ring->timeline);
- list_del(&ce->active_link);
- i915_gem_context_put(ce->gem_context);
}
static void mock_context_destroy(struct intel_context *ce)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/21] drm/i915: Hold a reference to the active HW context
For virtual engines, we need to keep the HW context alive while it
remains in use. For regular HW contexts, they are created and kept alive
until the end of the GEM context. For simplicity, generalise the
requirements and keep an active reference to each HW context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/intel_context.c | 6 ++
drivers/gpu/drm/i915/intel_context.h | 11 +++
drivers/gpu/drm/i915/intel_context_types.h | 6 +-
drivers/gpu/drm/i915/intel_lrc.c | 4 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++-
drivers/gpu/drm/i915/selftests/mock_engine.c | 7 ++-
7 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 21208a865380..d776d43707e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -232,7 +232,7 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
i915_ppgtt_put(ctx->ppgtt);
rbtree_postorder_for_each_entry_safe(it, n, &ctx->hw_contexts, node)
- it->ops->destroy(it);
+ intel_context_put(it);
kfree(ctx->name);
put_pid(ctx->pid);
diff --git a/drivers/gpu/drm/i915/intel_context.c
b/drivers/gpu/drm/i915/intel_context.c
index 0ab894a058f6..8931e0fee873 100644
--- a/drivers/gpu/drm/i915/intel_context.c
+++ b/drivers/gpu/drm/i915/intel_context.c
@@ -172,6 +172,7 @@ intel_context_pin(struct i915_gem_context *ctx,
list_add(&ce->active_link, &ctx->active_engines);
mutex_unlock(&ctx->mutex);
+ intel_context_get(ce);
smp_mb__before_atomic(); /* flush pin before it is visible */
}
@@ -192,6 +193,7 @@ void intel_context_unpin(struct intel_context *ce)
return;
/* We may be called from inside intel_context_pin() to evict another */
+ intel_context_get(ce);
mutex_lock_nested(&ce->pin_mutex, SINGLE_DEPTH_NESTING);
if (likely(atomic_dec_and_test(&ce->pin_count))) {
@@ -202,9 +204,11 @@ void intel_context_unpin(struct intel_context *ce)
mutex_unlock(&ce->gem_context->mutex);
i915_gem_context_put(ce->gem_context);
+ intel_context_put(ce);
}
mutex_unlock(&ce->pin_mutex);
+ intel_context_put(ce);
}
static void intel_context_retire(struct i915_active_request *active,
@@ -221,6 +225,8 @@ intel_context_init(struct intel_context *ce,
struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
+ kref_init(&ce->ref);
+
ce->gem_context = ctx;
ce->engine = engine;
ce->ops = engine->cops;
diff --git a/drivers/gpu/drm/i915/intel_context.h
b/drivers/gpu/drm/i915/intel_context.h
index 9546d932406a..ebc861b1a49e 100644
--- a/drivers/gpu/drm/i915/intel_context.h
+++ b/drivers/gpu/drm/i915/intel_context.h
@@ -73,4 +73,15 @@ static inline void __intel_context_pin(struct intel_context
*ce)
void intel_context_unpin(struct intel_context *ce);
+static inline struct intel_context *intel_context_get(struct intel_context *ce)
+{
+ kref_get(&ce->ref);
+ return ce;
+}
+
+static inline void intel_context_put(struct intel_context *ce)
+{
+ kref_put(&ce->ref, ce->ops->destroy);
+}
+
#endif /* __INTEL_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/intel_context_types.h
b/drivers/gpu/drm/i915/intel_context_types.h
index 6dc9b4b9067b..624729a35875 100644
--- a/drivers/gpu/drm/i915/intel_context_types.h
+++ b/drivers/gpu/drm/i915/intel_context_types.h
@@ -7,6 +7,7 @@
#ifndef __INTEL_CONTEXT_TYPES__
#define __INTEL_CONTEXT_TYPES__
+#include
#include
#include
#include
@@ -22,7 +23,8 @@ struct intel_ring;
struct intel_context_ops {
int (*pin)(struct intel_context *ce);
void (*unpin)(struct intel_context *ce);
- void (*destroy)(struct intel_context *ce);
+
+ void (*destroy)(struct kref *kref);
};
/*
@@ -36,6 +38,8 @@ struct intel_sseu {
};
struct intel_context {
+ struct kref ref;
+
struct i915_gem_context *gem_context;
struct intel_engine_cs *engine;
struct intel_engine_cs *active;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 186a1b9d6014..4678d0a924a0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1242,8 +1242,10 @@ static void __execlists_context_fini(struct
intel_context *ce)
i915_gem_object_put(ce->state->obj);
}
-static void execlists_context_destroy(struct intel_context *ce)
+static void execlists_context_destroy(struct kref *kref)
{
+ struct intel_context *ce = container_of(kref, typeof(*ce), ref);
+
GEM_BUG_ON(intel_context_is_pinned(ce));
if (ce->state)
diff --git a/drivers/gpu/drm/i915/intel_r
[Intel-gfx] [PATCH 08/21] drm/i915: Switch to use HWS indices rather than addresses
If we use the STORE_DATA_INDEX function we can use a fixed offset and
avoid having to lookup up the engine HWS address. A step closer to being
able to emit the final breadcrumb during request_add rather than later
in the submission interrupt handler.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_submission.c | 3 ++-
drivers/gpu/drm/i915/intel_lrc.c| 17 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 16 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
4 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 4a5727233419..c4ad73980988 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -583,7 +583,8 @@ static void inject_preempt_context(struct work_struct *work)
} else {
cs = gen8_emit_ggtt_write(cs,
GUC_PREEMPT_FINISHED,
- addr);
+ addr,
+ 0);
*cs++ = MI_NOOP;
*cs++ = MI_NOOP;
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4678d0a924a0..51c2ea164b36 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -173,12 +173,6 @@ static void execlists_init_reg_state(u32 *reg_state,
struct intel_engine_cs *engine,
struct intel_ring *ring);
-static inline u32 intel_hws_hangcheck_address(struct intel_engine_cs *engine)
-{
- return (i915_ggtt_offset(engine->status_page.vma) +
- I915_GEM_HWS_HANGCHECK_ADDR);
-}
-
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
{
return rb_entry(rb, struct i915_priolist, node);
@@ -2213,11 +2207,14 @@ static u32 *gen8_emit_fini_breadcrumb(struct
i915_request *request, u32 *cs)
{
cs = gen8_emit_ggtt_write(cs,
request->fence.seqno,
- request->timeline->hwsp_offset);
+ request->timeline->hwsp_offset,
+ 0);
cs = gen8_emit_ggtt_write(cs,
intel_engine_next_hangcheck_seqno(request->engine),
- intel_hws_hangcheck_address(request->engine));
+ I915_GEM_HWS_HANGCHECK_ADDR,
+ MI_FLUSH_DW_STORE_INDEX);
+
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
@@ -2241,8 +2238,8 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
cs = gen8_emit_ggtt_write_rcs(cs,
intel_engine_next_hangcheck_seqno(request->engine),
-
intel_hws_hangcheck_address(request->engine),
- 0);
+ I915_GEM_HWS_HANGCHECK_ADDR,
+ PIPE_CONTROL_STORE_DATA_INDEX);
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index a021c9545649..9e7ad17b5250 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -43,12 +43,6 @@
*/
#define LEGACY_REQUEST_SIZE 200
-static inline u32 hws_hangcheck_address(struct intel_engine_cs *engine)
-{
- return (i915_ggtt_offset(engine->status_page.vma) +
- I915_GEM_HWS_HANGCHECK_ADDR);
-}
-
unsigned int intel_ring_update_space(struct intel_ring *ring)
{
unsigned int space;
@@ -317,8 +311,8 @@ static u32 *gen6_rcs_emit_breadcrumb(struct i915_request
*rq, u32 *cs)
*cs++ = rq->fence.seqno;
*cs++ = GFX_OP_PIPE_CONTROL(4);
- *cs++ = PIPE_CONTROL_QW_WRITE;
- *cs++ = hws_hangcheck_address(rq->engine) | PIPE_CONTROL_GLOBAL_GTT;
+ *cs++ = PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_STORE_DATA_INDEX;
+ *cs++ = I915_GEM_HWS_HANGCHECK_ADDR | PIPE_CONTROL_GLOBAL_GTT;
*cs++ = intel_engine_next_hangcheck_seqno(rq->engine);
*cs++ = MI_USER_INTERRUPT;
@@ -423,8 +417,10 @@ static u32 *gen7_rcs_emit_breadcrumb(struct i915_request
*rq, u32 *cs)
*cs++ = rq->fence.seqno;
*cs++ = GFX_OP_PIPE_CONTROL(4);
- *cs++ = PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_GLOBAL_GTT_IVB;
- *cs++ = hws_hangcheck_address(rq->engine);
+ *cs++ = (PIPE_CONTROL_QW_WRITE |
+PIPE_CONTROL_STORE_DATA_INDEX |
+PIPE_CONTROL_GLOBAL_GTT_IVB);
+ *cs++ = I915_GEM_HWS_HANGCHECK_ADDR;
[Intel-gfx] [PATCH 21/21] drm/i915: Allow specification of parallel execbuf
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that with all things idle the second execbufs are executed
in parallel with the first. The key difference here between the new
EXEC_FENCE_SUBMIT and the existing EXEC_FENCE_IN is that the in-fence
waits for the completion of the first request (so that all of its
rendering results are visible to the second execbuf, the more common
userspace fence requirement).
Since we only have a single input fence slot, userspace cannot mix an
in-fence and a submit-fence. It has to use one or the other! This is not
such a harsh requirement, since by virtue of the submit-fence, the
secondary execbuf inherit all of the dependencies from the first
request, and for the application the dependencies should be common
between the primary and secondary execbuf.
Suggested-by: Tvrtko Ursulin
Testcase: igt/gem_exec_fence/parallel
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 25 +-
include/uapi/drm/i915_drm.h| 17 ++-
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9a0fa3b21e9d..e7fdd9926266 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -421,6 +421,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
case I915_PARAM_HAS_EXEC_CAPTURE:
case I915_PARAM_HAS_EXEC_BATCH_FIRST:
case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
+ case I915_PARAM_HAS_EXEC_SUBMIT_FENCE:
/* For the time being all of these are always true;
* if some supported hardware does not have one of these
* features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 9e7460dedb38..b9bd303242a1 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2282,6 +2282,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
{
struct i915_execbuffer eb;
struct dma_fence *in_fence = NULL;
+ struct dma_fence *exec_fence = NULL;
struct sync_file *out_fence = NULL;
intel_wakeref_t wakeref;
int out_fence_fd = -1;
@@ -2325,11 +2326,24 @@ i915_gem_do_execbuffer(struct drm_device *dev,
return -EINVAL;
}
+ if (args->flags & I915_EXEC_FENCE_SUBMIT) {
+ if (in_fence) {
+ err = -EINVAL;
+ goto err_in_fence;
+ }
+
+ exec_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
+ if (!exec_fence) {
+ err = -EINVAL;
+ goto err_in_fence;
+ }
+ }
+
if (args->flags & I915_EXEC_FENCE_OUT) {
out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
if (out_fence_fd < 0) {
err = out_fence_fd;
- goto err_in_fence;
+ goto err_exec_fence;
}
}
@@ -2461,6 +2475,13 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_request;
}
+ if (exec_fence) {
+ err = i915_request_await_execution(eb.request, exec_fence,
+ eb.engine->bond_execute);
+ if (err < 0)
+ goto err_request;
+ }
+
if (fences) {
err = await_fence_array(&eb, fences);
if (err)
@@ -2521,6 +2542,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
err_out_fence:
if (out_fence_fd != -1)
put_unused_fd(out_fence_fd);
+err_exec_fence:
+ dma_fence_put(exec_fence);
err_in_fence:
dma_fence_put(in_fence);
return err;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 0d9ca4fb9edb..08f680dd2b1c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -593,6 +593,12 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_MMAP_GTT_COHERENT 52
+/*
+ * Query whether DRM_I915_GEM_EXECBUFFER2 supports coordination of parallel
+ * execution through use of explicit fence support.
+ * See I915_EXEC_FENCE_OUT and I915_EXEC_FENCE_SUBMIT.
+ */
+#define I915_PARAM_HAS_EXEC_SUBMIT_FENCE 53
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
@@ -1115,7 +1121,16 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EXEC_FENCE_ARRAY (1<<19)
-#define _
[Intel-gfx] [PATCH 01/21] drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h
We want to use intel_engine_mask_t inside i915_request.h, which means
extracting it from the general header file mess and placing it inside a
types.h. A knock on effect is that the compiler wants to warn about
type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
for the worst.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_reset.c | 26 ++---
drivers/gpu/drm/i915/i915_reset.h | 6 +-
drivers/gpu/drm/i915/i915_scheduler.h | 86 +---
drivers/gpu/drm/i915/i915_scheduler_types.h | 98 +++
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/i915_timeline_types.h| 3 +-
drivers/gpu/drm/i915/intel_device_info.h | 3 +-
drivers/gpu/drm/i915/intel_engine_types.h | 9 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 4 +-
.../gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
.../test_i915_scheduler_types_standalone.c| 7 ++
14 files changed, 140 insertions(+), 109 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_scheduler_types.h
create mode 100644 drivers/gpu/drm/i915/test_i915_scheduler_types_standalone.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68fecf355471..197b081769b5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -60,6 +60,7 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
i915-$(CONFIG_DRM_I915_WERROR) += \
test_i915_active_types_standalone.o \
test_i915_gem_context_types_standalone.o \
+ test_i915_scheduler_types_standalone.o \
test_i915_timeline_types_standalone.o \
test_intel_context_types_standalone.o \
test_intel_engine_types_standalone.o \
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index b596cb42e24e..a0d981547c9e 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -311,7 +311,7 @@ static int mul_force_wake_write(struct intel_vgpu *vgpu,
static int gdrst_mmio_write(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
- unsigned int engine_mask = 0;
+ unsigned long engine_mask = 0;
u32 data;
write_vreg(vgpu, offset, p_data, bytes);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c65c2e6649df..b018ebe6c6f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2432,7 +2432,6 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
#define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
-#define ALL_ENGINES(~0u)
#define HAS_ENGINE(dev_priv, id) (INTEL_INFO(dev_priv)->engine_mask & BIT(id))
#define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 861fe083e383..5f40725ca428 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -144,7 +144,7 @@ static void gen3_stop_engine(struct intel_engine_cs *engine)
}
static void i915_stop_engines(struct drm_i915_private *i915,
- unsigned int engine_mask)
+ unsigned long engine_mask)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -165,7 +165,7 @@ static bool i915_in_reset(struct pci_dev *pdev)
}
static int i915_do_reset(struct drm_i915_private *i915,
-unsigned int engine_mask,
+unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = i915->drm.pdev;
@@ -194,7 +194,7 @@ static bool g4x_reset_complete(struct pci_dev *pdev)
}
static int g33_do_reset(struct drm_i915_private *i915,
- unsigned int engine_mask,
+ unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = i915->drm.pdev;
@@ -204,7 +204,7 @@ static int g33_do_reset(struct drm_i915_private *i915,
}
static int g4x_do_reset(struct drm_i915_private *dev_priv,
- unsigned int engine_mask,
+ unsigned long engine_mask,
unsigned int retry)
{
struct pci_dev *pdev = dev_priv->drm.pdev;
@@ -242,7 +242,7 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
}
static int ironlake_do_reset(struct drm_i915_private *dev_priv,
-unsigned int engine_mask,
+unsigned long engine_mask,
unsigned int retry)
{
int ret;
@@ -299,7 +299,7 @@ s
[Intel-gfx] [PATCH 07/21] drm/i915/selftests: Provide stub reset functions
If a test fails, we quite often mark the device as wedged. Provide the
stub functions so that we can wedge the mock device, and avoid exploding
on test failures.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109981
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engine.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index 639d36eb904a..61744819172b 100644
--- a/drivers/gpu/drm/i915/selftests/mock_engine.c
+++ b/drivers/gpu/drm/i915/selftests/mock_engine.c
@@ -198,6 +198,37 @@ static void mock_submit_request(struct i915_request
*request)
spin_unlock_irqrestore(&engine->hw_lock, flags);
}
+static void mock_reset_prepare(struct intel_engine_cs *engine)
+{
+}
+
+static void mock_reset(struct intel_engine_cs *engine, bool stalled)
+{
+ GEM_BUG_ON(stalled);
+}
+
+static void mock_reset_finish(struct intel_engine_cs *engine)
+{
+}
+
+static void mock_cancel_requests(struct intel_engine_cs *engine)
+{
+ struct i915_request *request;
+ unsigned long flags;
+
+ spin_lock_irqsave(&engine->timeline.lock, flags);
+
+ /* Mark all submitted requests as skipped. */
+ list_for_each_entry(request, &engine->timeline.requests, sched.link) {
+ if (!i915_request_signaled(request))
+ dma_fence_set_error(&request->fence, -EIO);
+
+ i915_request_mark_complete(request);
+ }
+
+ spin_unlock_irqrestore(&engine->timeline.lock, flags);
+}
+
struct intel_engine_cs *mock_engine(struct drm_i915_private *i915,
const char *name,
int id)
@@ -223,6 +254,11 @@ struct intel_engine_cs *mock_engine(struct
drm_i915_private *i915,
engine->base.emit_fini_breadcrumb = mock_emit_breadcrumb;
engine->base.submit_request = mock_submit_request;
+ engine->base.reset.prepare = mock_reset_prepare;
+ engine->base.reset.reset = mock_reset;
+ engine->base.reset.finish = mock_reset_finish;
+ engine->base.cancel_requests = mock_cancel_requests;
+
if (i915_timeline_init(i915,
&engine->base.timeline,
engine->base.name,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/21] drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
The I915_EXEC_DEFAULT slot is left empty, and invalid for use by
execbuf. It's use will be revealed in the next patch.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 226 +-
drivers/gpu/drm/i915/i915_gem_context_types.h | 21 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c| 19 +-
drivers/gpu/drm/i915/i915_utils.h | 36 +++
include/uapi/drm/i915_drm.h | 42 +++-
5 files changed, 331 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 1c0861f77dca..40f1a8fa1a05 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -86,7 +86,9 @@
*/
#include
+
#include
+
#include "i915_drv.h"
#include "i915_globals.h"
#include "i915_trace.h"
@@ -101,6 +103,21 @@ static struct i915_global_gem_context {
struct kmem_cache *slab_luts;
} global;
+static struct intel_engine_cs *
+lookup_user_engine(struct i915_gem_context *ctx,
+ unsigned long flags, u16 class, u16 instance)
+#define LOOKUP_USER_INDEX BIT(0)
+{
+ if (flags & LOOKUP_USER_INDEX) {
+ if (instance >= ctx->num_engines)
+ return NULL;
+
+ return ctx->engines[instance];
+ }
+
+ return intel_engine_lookup_user(ctx->i915, class, instance);
+}
+
struct i915_lut_handle *i915_lut_handle_alloc(void)
{
return kmem_cache_alloc(global.slab_luts, GFP_KERNEL);
@@ -235,6 +252,8 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
release_hw_id(ctx);
i915_ppgtt_put(ctx->ppgtt);
+ kfree(ctx->engines);
+
rbtree_postorder_for_each_entry_safe(it, n, &ctx->hw_contexts, node)
intel_context_put(it);
@@ -1390,9 +1409,9 @@ static int set_sseu(struct i915_gem_context *ctx,
if (user_sseu.flags || user_sseu.rsvd)
return -EINVAL;
- engine = intel_engine_lookup_user(i915,
- user_sseu.engine_class,
- user_sseu.engine_instance);
+ engine = lookup_user_engine(ctx, 0,
+ user_sseu.engine_class,
+ user_sseu.engine_instance);
if (!engine)
return -EINVAL;
@@ -1410,9 +1429,166 @@ static int set_sseu(struct i915_gem_context *ctx,
args->size = sizeof(user_sseu);
+ return 0;
+};
+
+struct set_engines {
+ struct i915_gem_context *ctx;
+ struct intel_engine_cs **engines;
+ unsigned int num_engines;
+};
+
+static const i915_user_extension_fn set_engines__extensions[] = {
+};
+
+static int
+set_engines(struct i915_gem_context *ctx,
+ const struct drm_i915_gem_context_param *args)
+{
+ struct i915_context_param_engines __user *user;
+ struct set_engines set = { .ctx = ctx };
+ u64 size, extensions;
+ unsigned int n;
+ int err;
+
+ user = u64_to_user_ptr(args->value);
+ size = args->size;
+ if (!size)
+ goto out;
+
+ BUILD_BUG_ON(!IS_ALIGNED(sizeof(*user), sizeof(*user->class_instance)));
+ if (size < sizeof(*user) ||
+ !IS_ALIGNED(size, sizeof(*user->class_instance)))
+ return -EINVAL;
+
+ /* Internal limitation of u64 bitmaps + a few bits of u64 in the uABI */
+ set.num_engines =
+ (size - sizeof(*user)) / sizeof(*user->class_instance);
+ if (set.num_engines > I915_EXEC_RING_MASK + 1)
+ return -EINVAL;
+
+ set.engines = kmalloc_array(set.num_engines,
+ sizeof(*set.engines),
+ GFP_KERNEL);
+ if (!set.engines)
+ return -
[Intel-gfx] [PATCH 10/21] drm/i915: Introduce a mutex for file_priv->context_idr
Define a mutex for the exclusive use of interacting with the per-file
context-idr, that was previously guarded by struct_mutex. This allows us
to reduce the coverage of struct_mutex, with a view to removing the last
bits coordinating GEM context later. (In the short term, we avoid taking
struct_mutex while using the extended constructor functions, preventing
some nasty recursion.)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 43 +++--
2 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b018ebe6c6f4..9d7dfcfab4d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -216,7 +216,9 @@ struct drm_i915_file_private {
*/
#define DRM_I915_THROTTLE_JIFFIES msecs_to_jiffies(20)
} mm;
+
struct idr context_idr;
+ struct mutex context_lock; /* guards context_idr */
unsigned int bsd_engine;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5df3d423ec6c..94c466d4b29e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -579,9 +579,7 @@ void i915_gem_contexts_fini(struct drm_i915_private *i915)
static int context_idr_cleanup(int id, void *p, void *data)
{
- struct i915_gem_context *ctx = p;
-
- context_close(ctx);
+ context_close(p);
return 0;
}
@@ -596,8 +594,10 @@ static int gem_context_register(struct i915_gem_context
*ctx,
ctx->ppgtt->vm.file = fpriv;
/* And (nearly) finally expose ourselves to userspace via the idr */
+ mutex_lock(&fpriv->context_lock);
ret = idr_alloc(&fpriv->context_idr, ctx,
DEFAULT_CONTEXT_HANDLE, 0, GFP_KERNEL);
+ mutex_unlock(&fpriv->context_lock);
if (ret < 0)
goto err_pid;
@@ -616,7 +616,9 @@ static int gem_context_register(struct i915_gem_context
*ctx,
return 0;
err_idr:
+ mutex_lock(&fpriv->context_lock);
idr_remove(&fpriv->context_idr, ctx->user_handle);
+ mutex_unlock(&fpriv->context_lock);
ctx->file_priv = NULL;
err_pid:
put_pid(ctx->pid);
@@ -632,10 +634,11 @@ int i915_gem_context_open(struct drm_i915_private *i915,
int err;
idr_init(&file_priv->context_idr);
+ mutex_init(&file_priv->context_lock);
mutex_lock(&i915->drm.struct_mutex);
-
ctx = i915_gem_create_context(i915);
+ mutex_unlock(&i915->drm.struct_mutex);
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
goto err;
@@ -648,14 +651,14 @@ int i915_gem_context_open(struct drm_i915_private *i915,
GEM_BUG_ON(ctx->user_handle != DEFAULT_CONTEXT_HANDLE);
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
- mutex_unlock(&i915->drm.struct_mutex);
-
return 0;
err_ctx:
+ mutex_lock(&i915->drm.struct_mutex);
context_close(ctx);
-err:
mutex_unlock(&i915->drm.struct_mutex);
+err:
+ mutex_destroy(&file_priv->context_lock);
idr_destroy(&file_priv->context_idr);
return PTR_ERR(ctx);
}
@@ -668,6 +671,7 @@ void i915_gem_context_close(struct drm_file *file)
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
idr_destroy(&file_priv->context_idr);
+ mutex_destroy(&file_priv->context_lock);
}
static struct i915_request *
@@ -850,25 +854,22 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
return ret;
ctx = i915_gem_create_context(i915);
- if (IS_ERR(ctx)) {
- ret = PTR_ERR(ctx);
- goto err_unlock;
- }
+ mutex_unlock(&dev->struct_mutex);
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
ret = gem_context_register(ctx, file_priv);
if (ret)
goto err_ctx;
- mutex_unlock(&dev->struct_mutex);
-
args->ctx_id = ctx->user_handle;
DRM_DEBUG("HW context %d created\n", args->ctx_id);
return 0;
err_ctx:
+ mutex_lock(&dev->struct_mutex);
context_close(ctx);
-err_unlock:
mutex_unlock(&dev->struct_mutex);
return ret;
}
@@ -879,7 +880,6 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
struct drm_i915_gem_context_destroy *args = data;
struct drm_i915_file_private *file_priv = file->driver_priv;
struct i915_gem_context *ctx;
- int ret;
if (args->pad != 0)
return -EINVAL;
@@ -887,21 +887,16 @@ int i915_gem_context_destroy_ioctl(struct drm_device
*dev, void *data,
if (args->ctx_id == DEFAULT_CONTEXT_HANDLE)
return -ENOENT;
- ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
+ mutex_lock(&file_priv->context_l
[Intel-gfx] [PATCH 03/21] drm/i915: Hold a ref to the ring while retiring
As the final request on a ring may hold the reference to this ring (via
retiring the last pinned context), we may find ourselves chasing a
dangling pointer on completion of the list.
A quick solution is to hold a reference to the ring itself as we retire
along it so that we only free it after we stop dereferencing it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 6 +-
drivers/gpu/drm/i915/intel_engine_types.h| 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 13 -
drivers/gpu/drm/i915/selftests/mock_engine.c | 1 +
6 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 9533a85cb0b3..0a3d94517d0a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1332,8 +1332,12 @@ void i915_retire_requests(struct drm_i915_private *i915)
if (!i915->gt.active_requests)
return;
- list_for_each_entry_safe(ring, tmp, &i915->gt.active_rings, active_link)
+ list_for_each_entry_safe(ring, tmp,
+&i915->gt.active_rings, active_link) {
+ intel_ring_get(ring); /* last rq holds reference! */
ring_retire_requests(ring);
+ intel_ring_put(ring);
+ }
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/drivers/gpu/drm/i915/intel_engine_types.h
b/drivers/gpu/drm/i915/intel_engine_types.h
index 79a166b9a81b..549fdfca17aa 100644
--- a/drivers/gpu/drm/i915/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/intel_engine_types.h
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
@@ -58,6 +59,7 @@ struct intel_engine_hangcheck {
};
struct intel_ring {
+ struct kref ref;
struct i915_vma *vma;
void *vaddr;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e54e0064b2d6..5089dec3074e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1236,7 +1236,7 @@ static void execlists_submit_request(struct i915_request
*request)
static void __execlists_context_fini(struct intel_context *ce)
{
- intel_ring_free(ce->ring);
+ intel_ring_put(ce->ring);
GEM_BUG_ON(i915_gem_object_is_active(ce->state->obj));
i915_gem_object_put(ce->state->obj);
@@ -2870,7 +2870,7 @@ static int execlists_context_deferred_alloc(struct
intel_context *ce,
return 0;
error_ring_free:
- intel_ring_free(ring);
+ intel_ring_put(ring);
error_deref_obj:
i915_gem_object_put(ctx_obj);
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index f26f5cc1584c..ebac752e092d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1311,6 +1311,7 @@ intel_engine_create_ring(struct intel_engine_cs *engine,
if (!ring)
return ERR_PTR(-ENOMEM);
+ kref_init(&ring->ref);
INIT_LIST_HEAD(&ring->request_list);
ring->timeline = i915_timeline_get(timeline);
@@ -1335,9 +1336,9 @@ intel_engine_create_ring(struct intel_engine_cs *engine,
return ring;
}
-void
-intel_ring_free(struct intel_ring *ring)
+void intel_ring_free(struct kref *ref)
{
+ struct intel_ring *ring = container_of(ref, typeof(*ring), ref);
struct drm_i915_gem_object *obj = ring->vma->obj;
i915_vma_close(ring->vma);
@@ -1591,7 +1592,7 @@ static int intel_init_ring_buffer(struct intel_engine_cs
*engine)
err_unpin:
intel_ring_unpin(ring);
err_ring:
- intel_ring_free(ring);
+ intel_ring_put(ring);
err:
intel_engine_cleanup_common(engine);
return err;
@@ -1605,7 +1606,7 @@ void intel_engine_cleanup(struct intel_engine_cs *engine)
(I915_READ_MODE(engine) & MODE_IDLE) == 0);
intel_ring_unpin(engine->buffer);
- intel_ring_free(engine->buffer);
+ intel_ring_put(engine->buffer);
if (engine->cleanup)
engine->cleanup(engine);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index e612bdca9fd9..a57489fcb302 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -231,7 +231,18 @@ int intel_ring_pin(struct intel_ring *ring);
void intel_ring_reset(struct intel_ring *ring, u32 tail);
unsigned int intel_ring_update_space(struct intel_ring *ring);
void intel_ring_unpin(struct intel_ring *ring);
-void intel_ring_free(struct intel_ring *ring);
+void intel_ring_free(struct kref *ref);
+
+static inline struct intel_ring *intel_ring_get(struct intel_ring *ring)
+{
+ kref_get(&ring->ref);
+ return ring;
+}
+
+static inline void intel_ring_put(struct in
[Intel-gfx] [PATCH 02/21] drm/i915: Sanity check mmap length against object size
We assumed that vm_mmap() would reject an attempt to mmap past the end of
the filp (our object), but we were wrong.
Reported-by: Antonio Argenziano
Testcase: igt/gem_mmap/bad-size
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b38c9531b5e8..b7086c8d4726 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1639,8 +1639,13 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
* pages from.
*/
if (!obj->base.filp) {
- i915_gem_object_put(obj);
- return -ENXIO;
+ addr = -ENXIO;
+ goto err;
+ }
+
+ if (range_overflows(args->offset, args->size, (u64)obj->base.size)) {
+ addr = -EINVAL;
+ goto err;
}
addr = vm_mmap(obj->base.filp, 0, args->size,
@@ -1654,8 +1659,8 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
struct vm_area_struct *vma;
if (down_write_killable(&mm->mmap_sem)) {
- i915_gem_object_put(obj);
- return -EINTR;
+ addr = -EINTR;
+ goto err;
}
vma = find_vma(mm, addr);
if (vma && __vma_matches(vma, obj->base.filp, addr, args->size))
@@ -1673,12 +1678,10 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
i915_gem_object_put(obj);
args->addr_ptr = (u64)addr;
-
return 0;
err:
i915_gem_object_put(obj);
-
return addr;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/21] drm/i915: Create/destroy VM (ppGTT) for use with contexts
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
v2: Replace global barrier for swapping over the ppgtt and tlbs with a
local context barrier (Tvrtko)
v3: serialise with struct_mutex; it's lazy but required dammit
v4: Rewrite igt_ctx_shared_exec to be more different (aimed to be more
similarly, turned out different!)
v5: Fix up test unwind for aliasing-ppgtt (snb)
v6: Tighten language for uapi struct drm_i915_gem_vm_control.
v7: Patch the context image for runtime ppgtt switching!
Testcase: igt/gem_vm_create
Testcase: igt/gem_ctx_param/vm
Testcase: igt/gem_ctx_clone/vm
Testcase: igt/gem_ctx_shared
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem_context.c | 331 +-
drivers/gpu/drm/i915/i915_gem_context.h | 5 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 19 +-
drivers/gpu/drm/i915/i915_gem_gtt.h | 11 +-
drivers/gpu/drm/i915/selftests/huge_pages.c | 1 -
.../gpu/drm/i915/selftests/i915_gem_context.c | 243 ++---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 -
drivers/gpu/drm/i915/selftests/mock_context.c | 8 +-
include/uapi/drm/i915_drm.h | 43 +++
11 files changed, 586 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a3b00ecc58c9..fa991144e0f2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -3121,6 +3121,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG,
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_VM_CREATE, i915_gem_vm_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl,
DRM_RENDER_ALLOW),
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9d7dfcfab4d5..63904ce70b8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -220,6 +220,9 @@ struct drm_i915_file_private {
struct idr context_idr;
struct mutex context_lock; /* guards context_idr */
+ struct mutex vm_lock;
+ struct idr vm_idr;
+
unsigned int bsd_engine;
/*
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 94c466d4b29e..c392f7af5546 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -90,6 +90,7 @@
#include "i915_drv.h"
#include "i915_globals.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
#include "intel_lrc_reg.h"
#include "intel_workarounds.h"
@@ -120,12 +121,15 @@ static void lut_close(struct i915_gem_context *ctx)
list_del(&lut->obj_link);
i915_lut_handle_free(lut);
}
+ INIT_LIST_HEAD(&ctx->handles_list);
rcu_read_lock();
radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
struct i915_vma *vma = rcu_dereference_raw(*slot);
radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);
+
+ vma->open_count--;
__i915_gem_object_release_unless_active(vma->obj);
}
rcu_read_unlock();
@@ -305,8 +309,6 @@ static void context_close(struct i915_gem_context *ctx)
* the ppgtt).
*/
lut_close(ctx);
- if (ctx->ppgtt)
- i915_ppgtt_close(&ctx->ppgtt->vm);
ctx->file_priv = ERR_PTR(-EBADF);
i915_gem_context_put(ctx);
@@ -378,6 +380,28 @@ __create_context(struct drm_i915_private *dev_priv)
return ctx;
}
+static struct i915_hw_ppgtt *
+__set_ppgtt(struct i915_gem_context *ctx, struct i915_hw_ppgtt *ppgtt)
+{
+ struct i915_hw_ppgtt *old = ctx->ppgtt;
+
+ ctx->ppgtt = i915_ppgtt_get(ppgtt);
+ ctx->desc_template = default_desc_template(ctx->i915, ppgtt);
+
+ return old;
+}
+
+static void __assign_ppgtt(struct i915_gem_context *ctx,
+ struct i915_hw_ppgtt *ppgtt)
+{
+ if (ppgtt == ctx->ppgtt)
+ return;
+
+ ppgtt = __set_ppgtt(ctx, ppgtt);
+ if (ppgtt)
+ i915_ppgtt_put(ppgtt);
+}
+
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *dev_priv)
{
@@ -403,8 +427,8 @@ i915_gem_create_context(struct drm_i915_private *dev_priv)
return ERR_CAST(ppgtt);
}
- ctx->ppgtt = ppgtt;
-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: introduce macros to define register contents (rev4)
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev4)
URL : https://patchwork.freedesktop.org/series/50513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12476
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/50513/revisions/4/mbox/
Known issues
Here are the changes found in Patchwork_12476 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-kbl-7567u: NOTRUN -> SKIP [fdo#109271] +33
* igt@gem_exec_basic@readonly-bsd2:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL [fdo#108511]
* igt@kms_busy@basic-flip-c:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g: NOTRUN -> SKIP [fdo#109271] +65
* igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +33
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS +1
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (44 -> 42)
--
Additional (3): fi-kbl-7567u fi-kbl-8809g fi-pnv-d510
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5753 -> Patchwork_12476
CI_DRM_5753: 0eb0838c0c26378949de6816166117c8b2d73caa @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4887: 5a7c7575b5bb9542f722ed6ba095b9d62609cd56 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12476: 054624c06486283fbfdd7224ea18e881448a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
054624c06486 drm/i915: use REG_FIELD_PREP() to define register bitfield values
a85d9dbaf18f drm/i915: deprecate _SHIFT in favor of _MASK passed to accessors
129656622c9a drm/i915: introduce REG_BIT() and REG_GENMASK() to define register
contents
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12476/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/21] drm/i915: Allow userspace to clone contexts on creation
Quoting Chris Wilson (2019-03-15 15:03:27)
> +static int create_clone(struct i915_user_extension __user *ext, void *data)
> +{
> + static int (* const fn[])(struct i915_gem_context *dst,
> + struct i915_gem_context *src) = {
> + [ilog2(I915_CONTEXT_CLONE_FLAGS)] = clone_flags,
> + [ilog2(I915_CONTEXT_CLONE_SCHEDATTR)] = clone_schedattr,
> + [ilog2(I915_CONTEXT_CLONE_SSEU)] = clone_sseu,
> + [ilog2(I915_CONTEXT_CLONE_TIMELINE)] = clone_timeline,
> + [ilog2(I915_CONTEXT_CLONE_VM)] = clone_vm,
> + };
Should be able to do something like
BUILD_BUG_ON(GENMASK(ARRAY_SIZE(fn)-1, 0) != I915_CONTEXT_CLONE_UNKNOWN);
-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 series starting with [01/21] drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h
== Series Details ==
Series: series starting with [01/21] drm/i915: Move intel_engine_mask_t around
for use by i915_request_types.h
URL : https://patchwork.freedesktop.org/series/58065/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12477
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12477 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12477, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/58065/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12477:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_execlists:
- fi-bdw-gvtdvm: PASS -> DMESG-WARN
- fi-kbl-7567u: NOTRUN -> DMESG-WARN
- fi-skl-gvtdvm: PASS -> DMESG-WARN
- fi-skl-6260u: PASS -> DMESG-WARN
- fi-kbl-7560u: NOTRUN -> DMESG-WARN
- fi-skl-6770hq: PASS -> DMESG-WARN
- fi-bdw-5557u: PASS -> DMESG-WARN
- fi-cfl-8109u: PASS -> DMESG-WARN
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_execlists:
- {fi-skl-lmem}: PASS -> DMESG-WARN
Known issues
Here are the changes found in Patchwork_12477 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-kbl-7567u: NOTRUN -> SKIP [fdo#109271] +33
* igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103
* igt@gem_exec_basic@readonly-bsd2:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: PASS -> SKIP [fdo#109271]
* igt@i915_pm_rpm@basic-rte:
- fi-bsw-kefka: PASS -> FAIL [fdo#108800]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720]
* igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g: NOTRUN -> SKIP [fdo#109271] +65
* igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +33
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS +1
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
Participating hosts (44 -> 41)
--
Additional (4): fi-kbl-7567u fi-kbl-8809g fi-bwr-2160 fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u
fi-bsw-cyan fi-ctg-p8600 fi-icl-y
Build changes
-
* Linux: CI_DRM_5753 -> Patchwork_12477
CI_DRM_5753: 0eb0838c0c26378949de6816166117c8b2d73caa @
git://anongit.freedesktop.org/gfx-c
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/21] drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h
Quoting Patchwork (2019-03-15 15:44:37) > == Series Details == > > Series: series starting with [01/21] drm/i915: Move intel_engine_mask_t > around for use by i915_request_types.h > URL : https://patchwork.freedesktop.org/series/58065/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12477 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_12477 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_12477, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/58065/revisions/1/mbox/ > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_12477: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@live_execlists: > - fi-bdw-gvtdvm: PASS -> DMESG-WARN > - fi-kbl-7567u: NOTRUN -> DMESG-WARN > - fi-skl-gvtdvm: PASS -> DMESG-WARN > - fi-skl-6260u: PASS -> DMESG-WARN > - fi-kbl-7560u: NOTRUN -> DMESG-WARN > - fi-skl-6770hq: PASS -> DMESG-WARN > - fi-bdw-5557u: PASS -> DMESG-WARN > - fi-cfl-8109u: PASS -> DMESG-WARN Sigh, I thought it might be nested with nests. Good news, cmpxchg to the rescue. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Virtual engine bonding
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual engine may select given a fence on a master engine.
For the moment, we continue to ignore the issue of preemption deferring
the master request for later. Ideally, we would like to then also remove
the slave and run something else rather than have it stall the pipeline.
With load balancing, we should be able to move workload around it, but
there is a similar stall on the master pipeline while it may wait for
the slave to be executed. At the cost of more latency for the bonded
request, it may be interesting to launch both on their engines in
lockstep. (Bubbles abound.)
Opens: Also what about bonding an engine as its own master? It doesn't
break anything internally, so allow the silliness.
v2: Emancipate the bonds
v3: Couple in delayed scheduling for the selftests
v4: Handle invalid mutually exclusive bonding
v5: Mention what the uapi does
v6: s/nbond/num_bonds/
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 50 +
drivers/gpu/drm/i915/i915_request.c | 1 +
drivers/gpu/drm/i915/i915_request.h | 3 +
drivers/gpu/drm/i915/intel_engine_types.h | 7 +
drivers/gpu/drm/i915/intel_lrc.c | 147 ++
drivers/gpu/drm/i915/intel_lrc.h | 4 +
drivers/gpu/drm/i915/selftests/intel_lrc.c| 185 ++
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 3 +
include/uapi/drm/i915_drm.h | 33
9 files changed, 433 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b387b71e2cb5..8e3b16462956 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1532,8 +1532,58 @@ set_engines__load_balance(struct i915_user_extension
__user *base, void *data)
return 0;
}
+static int
+set_engines__bond(struct i915_user_extension __user *base, void *data)
+{
+ struct i915_context_engines_bond __user *ext =
+ container_of_user(base, typeof(*ext), base);
+ const struct set_engines *set = data;
+ unsigned int idx, class, instance;
+ struct intel_engine_cs *master;
+ u64 siblings;
+ int err;
+
+ if (get_user(idx, &ext->virtual_index))
+ return -EFAULT;
+
+ if (idx >= set->num_engines)
+ return -EINVAL;
+
+ idx = array_index_nospec(idx, set->num_engines);
+ if (!set->engines[idx])
+ return -EINVAL;
+
+ /*
+* A non-virtual engine has 0 siblings to choose between; and submit
+* fence will always be directed to the one engine.
+*/
+ if (!intel_engine_is_virtual(set->engines[idx]))
+ return 0;
+
+ err = check_user_mbz(&ext->mbz);
+ if (err)
+ return err;
+
+ if (get_user(class, &ext->master_class))
+ return -EFAULT;
+
+ if (get_user(instance, &ext->master_instance))
+ return -EFAULT;
+
+ master = intel_engine_lookup_user(set->ctx->i915, class, instance);
+ if (!master)
+ return -EINVAL;
+
+ if (get_user(siblings, &ext->sibling_mask))
+ return -EFAULT;
+
+ return intel_virtual_engine_attach_bond(set->engines[idx],
+ master, siblings);
+}
+
static const i915_user_extension_fn set_engines__extensions[] = {
[I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE] = set_engines__load_balance,
+ [I915_CONTEXT_ENGINES_EXT_BOND] = set_engines__bond,
};
static int
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0a46f8113f5c..2d209519a6d5 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -743,6 +743,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->batch = NULL;
rq->capture_list = NULL;
rq->waitboost = false;
+ INIT_ALL_ENGINES(rq->execution_mask);
/*
* Reserve space in the ring buffer for all the commands required to
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index d4f6b2940130..5bdab6881b13 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -32,6 +32,8 @@
#include "i915_selftest.h"
#include "i915_sw_fence.h"
+#include "intel_engine_types.h"
+
#include
struct drm_file;
@@ -145,6 +147,7 @@ struct i915_request {
*/
struct i915_sched_node sched;
struct i915_dependency dep;
+ intel_engine_mask_t execution_mask;
/*
* A convenience pointer to
[Intel-gfx] [PATCH] drm/i915: Allow userspace to clone contexts on creation
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient if they were able to just pass in a target context to clone
during creation. This essentially extends the setparam during creation
to pull the details from a target context instead of the user supplied
parameters.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 154
include/uapi/drm/i915_drm.h | 14 +++
2 files changed, 168 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 57b4e760fa4b..1972f112d72b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1513,8 +1513,162 @@ static int create_setparam(struct i915_user_extension
__user *ext, void *data)
return ctx_setparam(arg->ctx, &local.param);
}
+static int clone_flags(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ dst->user_flags = src->user_flags;
+ return 0;
+}
+
+static int clone_schedattr(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ dst->sched = src->sched;
+ return 0;
+}
+
+static int clone_sseu(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ const struct intel_sseu default_sseu =
+ intel_device_default_sseu(dst->i915);
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, dst->i915, id) {
+ struct intel_context *ce;
+ struct intel_sseu sseu;
+
+ ce = intel_context_lookup(src, engine);
+ if (!ce)
+ continue;
+
+ sseu = ce->sseu;
+ if (!memcmp(&sseu, &default_sseu, sizeof(sseu)))
+ continue;
+
+ ce = intel_context_pin_lock(dst, engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ ce->sseu = sseu;
+ intel_context_pin_unlock(ce);
+ }
+
+ return 0;
+}
+
+static int clone_timeline(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ if (src->timeline) {
+ GEM_BUG_ON(src->timeline == dst->timeline);
+
+ if (dst->timeline)
+ i915_timeline_put(dst->timeline);
+ dst->timeline = i915_timeline_get(src->timeline);
+ }
+
+ return 0;
+}
+
+static int clone_vm(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ struct i915_hw_ppgtt *ppgtt;
+
+ rcu_read_lock();
+ do {
+ ppgtt = READ_ONCE(src->ppgtt);
+ if (!ppgtt)
+ break;
+
+ if (!kref_get_unless_zero(&ppgtt->ref))
+ continue;
+
+ /*
+* This ppgtt may have be reallocated between
+* the read and the kref, and reassigned to a third
+* context. In order to avoid inadvertent sharing
+* of this ppgtt with that third context (and not
+* src), we have to confirm that we have the same
+* ppgtt after passing through the strong memory
+* barrier implied by a successful
+* kref_get_unless_zero().
+*
+* Once we have acquired the current ppgtt of src,
+* we no longer care if it is released from src, as
+* it cannot be reallocated elsewhere.
+*/
+
+ if (ppgtt == READ_ONCE(src->ppgtt))
+ break;
+
+ i915_ppgtt_put(ppgtt);
+ } while (1);
+ rcu_read_unlock();
+
+ if (ppgtt) {
+ __assign_ppgtt(dst, ppgtt);
+ i915_ppgtt_put(ppgtt);
+ }
+
+ return 0;
+}
+
+static int create_clone(struct i915_user_extension __user *ext, void *data)
+{
+ static int (* const fn[])(struct i915_gem_context *dst,
+ struct i915_gem_context *src) = {
+#define MAP(x, y) [ilog2(I915_CONTEXT_CLONE_##x)] = y
+ MAP(FLAGS, clone_flags),
+ MAP(SCHEDATTR, clone_schedattr),
+ MAP(SSEU, clone_sseu),
+ MAP(TIMELINE, clone_timeline),
+ MAP(VM, clone_vm),
+#undef MAP
+ };
+ struct drm_i915_gem_context_create_ext_clone local;
+ const struct create_ext *arg = data;
+ struct i915_gem_context *dst = arg->ctx;
+ struct i915_gem_context *src;
+ int err, bit;
+
+ if (copy_from_user(&local, ext, sizeof(local)))
+ return -EFAULT
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h (rev2)
== Series Details == Series: drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h (rev2) URL : https://patchwork.freedesktop.org/series/58052/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5753_full -> Patchwork_12474_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12474_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12474_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_12474_full: ### IGT changes ### Possible regressions * igt@runner@aborted: - shard-apl: NOTRUN -> ( 6 FAIL ) [fdo#109373] Warnings * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: FAIL [fdo#103167] -> INCOMPLETE Known issues Here are the changes found in Patchwork_12474_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_big: - shard-snb: PASS -> INCOMPLETE [fdo#105411] * igt@gem_exec_parallel@bsd1: - shard-skl: NOTRUN -> SKIP [fdo#109271] +78 * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109283] * igt@gem_mmap_gtt@forked-big-copy: - shard-iclb: PASS -> TIMEOUT [fdo#109673] * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-iclb: NOTRUN -> INCOMPLETE [fdo#107713] / [fdo#109766] / [fdo#109801] * igt@gem_pwrite@huge-gtt-random: - shard-iclb: NOTRUN -> SKIP [fdo#109290] * igt@i915_pm_backlight@fade_with_suspend: - shard-iclb: NOTRUN -> FAIL [fdo#107847] * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: PASS -> SKIP [fdo#109271] * igt@i915_pm_rpm@gem-execbuf: - shard-apl: PASS -> DMESG-WARN [fdo#109373] * igt@i915_pm_rps@reset: - shard-iclb: NOTRUN -> FAIL [fdo#108059] +1 * igt@kms_atomic_transition@1x-modeset-transitions-fencing: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_busy@basic-modeset-e: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-hsw: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-render-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-pageflip-hang-oldfb-render-d: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +4 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_ccs@pipe-b-crc-sprite-planes-basic: - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_chamelium@vga-edid-read: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +1 * igt@kms_color@pipe-a-legacy-gamma: - shard-skl: PASS -> FAIL [fdo#104782] / [fdo#108145] * igt@kms_cursor_crc@cursor-128x128-onscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-dpms: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] +1 * igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: - shard-glk: PASS -> FAIL [fdo#105454] / [fdo#106509] * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-skl: NOTRUN -> DMESG-WARN [fdo#105541] * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: NOTRUN -> SKIP [fdo#109349] * igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +1 * igt@kms_flip_tiling@flip-x-tiled: - shard-skl: PASS -> FAIL [fdo#108145] / [fdo#108303] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-pri-indfb-multidraw: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +13 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-snb: NOTRUN -> SKIP [fdo#109271] +44 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#103167] +7 * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt: - s
Re: [Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
On Fri, Mar 15, 2019 at 02:21:57PM +, Tvrtko Ursulin wrote:
>
> On 15/03/2019 14:09, Ville Syrjälä wrote:
> > On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> Concept of a sub-platform already exist in our code (like ULX and ULT
> >> platform variants and similar),implemented via the macros which check a
> >> list of device ids to determine a match.
> >>
> >> With this patch we consolidate device ids checking into a single function
> >> called during early driver load.
> >>
> >> A few low bits in the platform mask are reserved for sub-platform
> >> identification and defined as a per-platform namespace.
> >>
> >> At the same time it future proofs the platform_mask handling by preparing
> >> the code for easy extending, and tidies the very verbose WARN strings
> >> generated when IS_PLATFORM macros are embedded into a WARN type
> >> statements.
> >>
> >> The approach is also beneficial to driver size, with an combined shrink of
> >> code and strings of around 1.7 kiB.
> >>
> >> v2: Fixed IS_SUBPLATFORM. Updated commit msg.
> >> v3: Chris was right, there is an ordering problem.
> >>
> >> v4:
> >> * Catch-up with new sub-platforms.
> >> * Rebase for RUNTIME_INFO.
> >> * Drop subplatform mask union tricks and convert platform_mask to an
> >> array for extensibility.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> Suggested-by: Chris Wilson
> >> Cc: Chris Wilson
> >> Cc: Jani Nikula
> >> Cc: Lucas De Marchi
> >> Cc: Jose Souza
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.c | 7 +-
> >> drivers/gpu/drm/i915/i915_drv.h | 110 +++
> >> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> >> drivers/gpu/drm/i915/intel_device_info.c | 79
> >> drivers/gpu/drm/i915/intel_device_info.h | 28 +-
> >> 5 files changed, 179 insertions(+), 47 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >> b/drivers/gpu/drm/i915/i915_drv.c
> >> index 0d743907e7bc..3218350cd225 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.c
> >> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >> @@ -863,6 +863,8 @@ static int i915_driver_init_early(struct
> >> drm_i915_private *dev_priv)
> >>if (i915_inject_load_failure())
> >>return -ENODEV;
> >>
> >> + intel_device_info_subplatform_init(dev_priv);
> >> +
> >>spin_lock_init(&dev_priv->irq_lock);
> >>spin_lock_init(&dev_priv->gpu_error.lock);
> >>mutex_init(&dev_priv->backlight_lock);
> >> @@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
> >> drm_i915_private *dev_priv)
> >>if (drm_debug & DRM_UT_DRIVER) {
> >>struct drm_printer p = drm_debug_printer("i915 device info:");
> >>
> >> - drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
> >> + drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
> >> gen=%i\n",
> >> INTEL_DEVID(dev_priv),
> >> INTEL_REVID(dev_priv),
> >> intel_platform_name(INTEL_INFO(dev_priv)->platform),
> >> +
> >> RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
> >> (BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) -
> >> INTEL_SUBPLATFORM_BITS)],
> >> INTEL_GEN(dev_priv));
> >>
> >>intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
> >> @@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const
> >> struct pci_device_id *ent)
> >>memcpy(device_info, match_info, sizeof(*device_info));
> >>RUNTIME_INFO(i915)->device_id = pdev->device;
> >>
> >> - BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
> >> - BITS_PER_TYPE(device_info->platform_mask));
> >>BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
> >>
> >>return i915;
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index dccb6006aabf..34282cf66cb0 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -2281,7 +2281,46 @@ static inline unsigned int
> >> i915_sg_segment_size(void)
> >> #define IS_REVID(p, since, until) \
> >>(INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
> >>
> >> -#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask &
> >> BIT(p))
> >> +#define __IS_PLATFORM(dev_priv, p) \
> >> +({ \
> >> + const unsigned int pbits__ = \
> >> + BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
> >> + INTEL_SUBPLATFORM_BITS; \
> >> + const unsigned int pi__ = (p) / pbits__; \
> >> + const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
> >> +\
> >> + BUILD_BUG_ON(!__builtin_constant_p(p)); \
> >> +\
> >> + (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & BIT(pb__)); \
> >> +})
> >> +
> >> +#define __IS_SUBPLATFORM(dev_priv, p, s) \
> >> +({ \
> >> + const unsigned int pbits__ = \
> >> + BITS_P
Re: [Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
On Fri, Mar 15, 2019 at 05:55:19PM +0200, Ville Syrjälä wrote: > On Fri, Mar 15, 2019 at 02:21:57PM +, Tvrtko Ursulin wrote: > > > > On 15/03/2019 14:09, Ville Syrjälä wrote: > > > On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote: > > >> -#define IS_KBL_ULX(dev_priv)(INTEL_DEVID(dev_priv) == 0x590E || \ > > >> - INTEL_DEVID(dev_priv) == 0x5915 || \ > > >> - INTEL_DEVID(dev_priv) == 0x591E) > > >> -#define IS_AML_ULX(dev_priv)(INTEL_DEVID(dev_priv) == 0x591C || \ > > >> - INTEL_DEVID(dev_priv) == 0x87C0) > > >> +#define IS_HSW_ULX(dev_priv) \ > > >> +IS_SUBPLATFORM(dev_priv, INTEL_HASWELL, INTEL_SUBPLATFORM_ULX) > > >> +#define IS_SKL_ULT(dev_priv) \ > > >> +IS_SUBPLATFORM(dev_priv, INTEL_SKYLAKE, INTEL_SUBPLATFORM_ULT) > > >> +#define IS_SKL_ULX(dev_priv) \ > > >> +IS_SUBPLATFORM(dev_priv, INTEL_SKYLAKE, INTEL_SUBPLATFORM_ULX) > > >> +#define IS_KBL_ULT(dev_priv) \ > > >> +IS_SUBPLATFORM(dev_priv, INTEL_KABYLAKE, INTEL_SUBPLATFORM_ULT) > > >> +#define IS_KBL_ULX(dev_priv) \ > > >> +IS_SUBPLATFORM(dev_priv, INTEL_KABYLAKE, INTEL_SUBPLATFORM_ULX) > > >> +#define IS_AML_ULX(dev_priv) \ > > >> +IS_SUBPLATFORM(dev_priv, INTEL_KABYLAKE, > > >> INTEL_SUBPLATFORM_AML_ULX) > > > > > > Why is AML_ULX different from normal ULX? > > > > As far as I could it is a different devid which we officially call > > Amberlake, but did not add it as separate platform. > > > > Given how this macro is used, which is always in conjuction with > > IS_KBL_ULX, I considered just removing it and adding the devid to > > KBL_ULX, but did not want to interferre with other people's ideas. > > This whole AML_ULX makes no sense. The "non-ULX" AML is also > docucemented to be a Y SKU, so AFAICS it should use the exact > same codepaths as KBL Y (aka. KBL_ULX). Cc:ing Jose who added this > second AML variant... Actually cc this time. > > I'm really tempted to just go and nuke all CFL,AML,etc. from the > code to make it actually match the spec. > -- 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] drm/i915/display: Reduce log level for DP command signal timeout
On Fri, Mar 15, 2019 at 03:35:04PM +0200, Ville Syrjälä wrote:
On Thu, Mar 14, 2019 at 06:37:22PM -0700, Vanshidhar Konda wrote:
On Thu, Mar 14, 2019 at 11:09:38PM +0200, Ville Syrjälä wrote:
>On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote:
>> On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote:
>> >On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote:
>> >> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
>> >> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
>> >> >> The log level for timeout after waiting for a signal on the DP aux
>> >> >> channel control register is set to DRM_ERROR. But this is timeout not a
>> >> >> fatal error as the driver is expected to retry the command. Failure
>> >> >> after all retries is already captured as an error. Hence, reducing the
>> >> >> log for a timeout to warning instead of error.
>> >> >> ---
>> >> >> drivers/gpu/drm/i915/intel_dp.c | 2 +-
>> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
>> >> >> index 47857f96c3b1..f51e8b2ccb17 100644
>> >> >> --- a/drivers/gpu/drm/i915/intel_dp.c
>> >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> >> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
>> >> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
>> >> >>
>> >> >> if (!done)
>> >> >> -DRM_ERROR("dp aux hw did not signal timeout!\n");
>> >> >> +DRM_WARN("dp aux hw did not signal timeout!\n");
>> >> >
>> >> >IIRC this indicates the hw is broken.
>> >> >
>> >> Does this indicate an issue with Intel GFX/display device, or the
>> >> display/monitor connected to the DP port?
>> >>
>> >> FYI, this is for FDO #109982
>> >> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
>> >
>> >There's nothing connected I believe. But in either case I believe
>>
>> >From the two logs for the issue, e-DP1 is the only display connected to
>> the test machine when it generated this error.
>>
>> >the aux hw should terminate with a proper timeout. I'm tempted to
>>
>> If we think that there should be no timeout, would it make more sense to
>> return an error to the caller and having the caller handle the error?
>
>How would it handle the error?
>
>>
>> >blame the typec/tbt stuff here too.
Could it be possible that the addition of typec/tbt to ICL has added
additional latency to the DP register being signaled? Would it make
sense to increase the 10 ms timeout to something larger?
Imre just told me the hw timeout was increased to 4ms. So 10ms should
still be sufficient I guess. But it wouldn't hurt to at least test
longer timeouts a bit to see if the hw ever gets around to signalling
the timeout.
Ok. Let me send a patch for that then. I'll cc you and Imre on that
patch. Thank you!
>> >
>> >>
>> >> >From the logs, it seems like this timeout only occurs once. The next try
>> >> succeeds without issues.
>> >>
>> >> >> #undef C
>> >> >>
>> >> >> return status;
>> >> >> --
>> >> >> 2.20.1
>> >> >>
>> >> >> ___
>> >> >> Intel-gfx mailing list
>> >> >> Intel-gfx@lists.freedesktop.org
>> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> >> >
>> >> >--
>> >> >Ville Syrjälä
>> >> >Intel
>> >
>> >--
>> >Ville Syrjälä
>> >Intel
>
>--
>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] drm/i915: Introduce concept of a sub-platform
On 15/03/2019 15:55, Ville Syrjälä wrote:
On Fri, Mar 15, 2019 at 02:21:57PM +, Tvrtko Ursulin wrote:
[snip]
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 047d10bdd455..b03fbd2e451a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -44,7 +44,7 @@ enum intel_platform {
INTEL_I915G,
INTEL_I915GM,
INTEL_I945G,
- INTEL_I945GM,
+ INTEL_I945GM = 8,
INTEL_G33,
INTEL_PINEVIEW,
/* gen4 */
@@ -55,7 +55,7 @@ enum intel_platform {
/* gen5 */
INTEL_IRONLAKE,
/* gen6 */
- INTEL_SANDYBRIDGE,
+ INTEL_SANDYBRIDGE = 16,
/* gen7 */
INTEL_IVYBRIDGE,
INTEL_VALLEYVIEW,
@@ -66,7 +66,7 @@ enum intel_platform {
/* gen9 */
INTEL_SKYLAKE,
INTEL_BROXTON,
- INTEL_KABYLAKE,
+ INTEL_KABYLAKE = 24,
Too much magic. Looks rather fragile.
Imagine these hunks gone. This is not required for this patch at all, or
for anything for that matter. What do you think is magic and fragile?
Who is going to remeber to keep adding those magic numbers
in the future.
They serve no purpose. :) I'll remove them from the next respin. It was
just me counting to see how many fit into one u32 of mask bits if I
reserve N low bits for the subplatform mask.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
On 2019-03-14, Daniel Vetter wrote: > That's why we came up with the trylock + immediate bail out design if > that fails. Plus really only render the oops int whatever is the > current display buffer, so that we don't have to do any hw programming > at all. I think this is your best option. The real work will be identifying any/all spin locking that currently exists. For all of those, the code needs to change to: 1. trylock if oops_in_progress, otherwise spinlock 2. if trylock fails, the code must have a sane failure The 2nd point will be the difficult one. For example, you may have functions without a return value taking spinlocks. But now those functions could fail. John Ogness ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Update render power clock state configuration for given context
Hi Tvrtko,
On Tue, Dec 11, 2018 at 6:06 PM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
> On 11/12/2018 10:14, Ankit Navik wrote:
> > From: Praveen Diwakar
> >
> > This patch will update power clock state register at runtime base on the
> > flag which can set by any governor which computes load and want to update
> > rpcs register.
> > subsequent patches will have a timer based governor which computes
> pending
> > load/request.
> >
> > V2:
> > * Reuse make_rpcs to get rpcs config. (Tvrtko Ursulin)
> >
> > V3:
> > * Rebase.
> >
> > Cc: Aravindan Muthukumar
> > Cc: Kedar J Karanje
> > Cc: Yogesh Marathe
> > Reviewed-by: Tvrtko Ursulin
>
> Again, I did not give an r-b for this!
>
> > Signed-off-by: Praveen Diwakar
> > Signed-off-by: Ankit Navik
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 4
> > drivers/gpu/drm/i915/i915_gem_context.h | 9 +
> > drivers/gpu/drm/i915/intel_lrc.c| 12 +++-
> > 3 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 0bcbe32..d040858 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -388,6 +388,10 @@ i915_gem_create_context(struct drm_i915_private
> *dev_priv,
> >
> > trace_i915_context_create(ctx);
> > atomic_set(&ctx->req_cnt, 0);
> > + ctx->slice_cnt = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
> > + ctx->subslice_cnt = hweight8(
> > + INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
> > + ctx->eu_cnt = INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
> >
> > return ctx;
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> b/drivers/gpu/drm/i915/i915_gem_context.h
> > index e824b15..e000530 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > @@ -199,6 +199,15 @@ struct i915_gem_context {
> >* go for low/medium/high load configuration of the GPU.
> >*/
> > atomic_t req_cnt;
> > +
> > + /** slice_cnt: used to set the # of slices to be enabled. */
> > + u8 slice_cnt;
> > +
> > + /** subslice_cnt: used to set the # of subslices to be enabled. */
> > + u8 subslice_cnt;
> > +
> > + /** eu_cnt: used to set the # of eu to be enabled. */
> > + u8 eu_cnt;
> > };
> >
> > static inline bool i915_gem_context_is_closed(const struct
> i915_gem_context *ctx)
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> > index d33f5ac..a17f676 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -171,6 +171,7 @@ static void execlists_init_reg_state(u32 *reg_state,
> >struct i915_gem_context *ctx,
> >struct intel_engine_cs *engine,
> >struct intel_ring *ring);
> > +static u32 make_rpcs(struct drm_i915_private *dev_priv);
> >
> > static inline struct i915_priolist *to_priolist(struct rb_node *rb)
> > {
> > @@ -417,12 +418,21 @@ execlists_update_context_pdps(struct i915_hw_ppgtt
> *ppgtt, u32 *reg_state)
> >
> > static u64 execlists_update_context(struct i915_request *rq)
> > {
> > + u32 rpcs_config = 0;
>
> Move to if block where it is used.
>
> > struct intel_context *ce = rq->hw_context;
> > + u32 *reg_state = ce->lrc_reg_state;
>
> No need to touch this.
>
> > + struct i915_gem_context *ctx = rq->gem_context;
>
> Can go under the if block as well.
>
> > struct i915_hw_ppgtt *ppgtt =
> > rq->gem_context->ppgtt ?: rq->i915->mm.aliasing_ppgtt;
> > - u32 *reg_state = ce->lrc_reg_state;
> >
> > reg_state[CTX_RING_TAIL+1] = intel_ring_set_tail(rq->ring,
> rq->tail);
> > + /* FIXME: To avoid stale rpcs config, move it to context_pin */
>
> This FIXME remains unresolved by the whole series, so that really cannot
> be like that.
>
> I suggest you add https://patchwork.freedesktop.org/patch/261560/ to
> your series and rebase this on top.
>
> Which would actually make this patch not do very much and you should
> probably squash it with the one which actually uses the added fields.
>
submitted v4 patch and reverted to previous function
i.e., get_context_rpcs_config as make_rpcs is changed in mainline.
Regards, Ankit
>
> > + if (ctx->pid && ctx->name && (rq->engine->id == RCS)) {
>
> Why name and pid? You are using them as proxy for something.. but for
> what and why? The answer may hold a hint to the proper solution.
>
> > + rpcs_config = make_rpcs(ctx->i915);
> > + reg_state[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
> > + CTX_REG(reg_state, CTX_R_PWR_CLK_STATE,
> GEN8_R_PWR_CLK_STATE,
> > + rpcs_config);
> > + }
> >
> > /* True 32b PPGTT with dynamic page allocation: update
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
On 2019-03-14, John Ogness wrote: > On 2019-03-14, Daniel Vetter wrote: >> That's why we came up with the trylock + immediate bail out design if >> that fails. Plus really only render the oops int whatever is the >> current display buffer, so that we don't have to do any hw >> programming at all. > > I think this is your best option. The real work will be identifying > any/all spin locking that currently exists. For all of those, the code > needs to change to: > > 1. trylock if oops_in_progress, otherwise spinlock On second thought, you shouldn't use oops_in_progress. It would be better if DRM had its own flag to signify that it is currently being used in kmsg_dump context. > 2. if trylock fails, the code must have a sane failure > > The 2nd point will be the difficult one. For example, you may have > functions without a return value taking spinlocks. But now those > functions could fail. John Ogness ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Get active pending request for given context
Hi Tvrtko,
On Tue, Nov 6, 2018 at 3:14 PM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
> On 06/11/2018 04:13, Ankit Navik wrote:
> > From: Praveen Diwakar
> >
> > This patch gives us the active pending request count which is yet
> > to be submitted to the GPU
> >
> > Signed-off-by: Praveen Diwakar
> > Signed-off-by: Yogesh Marathe
> > Signed-off-by: Aravindan Muthukumar
> > Signed-off-by: Kedar J Karanje
> > Signed-off-by: Ankit Navik
> > Suggested-by: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_drv.c| 1 +
> > drivers/gpu/drm/i915/i915_drv.h| 5 +
> > drivers/gpu/drm/i915/i915_gem_context.c| 1 +
> > drivers/gpu/drm/i915/i915_gem_context.h| 6 ++
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +
> > drivers/gpu/drm/i915/intel_lrc.c | 6 ++
> > 6 files changed, 24 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> > index f8cfd16..d37c46e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -903,6 +903,7 @@ static int i915_driver_init_early(struct
> drm_i915_private *dev_priv,
> > mutex_init(&dev_priv->av_mutex);
> > mutex_init(&dev_priv->wm.wm_mutex);
> > mutex_init(&dev_priv->pps_mutex);
> > + mutex_init(&dev_priv->pred_mutex);
> >
> > i915_memcpy_init_early(dev_priv);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> > index 4aca534..137ec33 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1609,6 +1609,11 @@ struct drm_i915_private {
> >* controller on different i2c buses. */
> > struct mutex gmbus_mutex;
> >
> > + /** pred_mutex protects against councurrent usage of pending
> > + * request counter for multiple contexts
> > + */
> > + struct mutex pred_mutex;
> > +
> > /**
> >* Base address of the gmbus and gpio block.
> >*/
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> > index b10770c..0bcbe32 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -387,6 +387,7 @@ i915_gem_create_context(struct drm_i915_private
> *dev_priv,
> > }
> >
> > trace_i915_context_create(ctx);
> > + atomic_set(&ctx->req_cnt, 0);
> >
> > return ctx;
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> b/drivers/gpu/drm/i915/i915_gem_context.h
> > index b116e49..04e3ff7 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> > @@ -194,6 +194,12 @@ struct i915_gem_context {
> >* context close.
> >*/
> > struct list_head handles_list;
> > +
> > + /** req_cnt: tracks the pending commands, based on which we decide
> to
> > + * go for low/medium/high load configuration of the GPU, this is
> > + * controlled via a mutex
> > + */
> > + atomic_t req_cnt;
> > };
> >
> > static inline bool i915_gem_context_is_closed(const struct
> i915_gem_context *ctx)
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 3f0c612..8afa2a5 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -2178,6 +2178,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > struct drm_syncobj **fences)
> > {
> > struct i915_execbuffer eb;
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > struct dma_fence *in_fence = NULL;
> > struct sync_file *out_fence = NULL;
> > int out_fence_fd = -1;
> > @@ -2390,6 +2391,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >*/
> > eb.request->batch = eb.batch;
> >
> > + mutex_lock(&dev_priv->pred_mutex);
> > + atomic_inc(&eb.ctx->req_cnt);
>
> Point of going to atomic_t was to remove need for the mutex.
>
> > + mutex_unlock(&dev_priv->pred_mutex);
> > +
> > trace_i915_request_queue(eb.request, eb.batch_flags);
> > err = eb_submit(&eb);
> > err_request:
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> > index 1744792..bcbb66b 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -728,6 +728,12 @@ static void execlists_dequeue(struct
> intel_engine_cs *engine)
> > trace_i915_request_in(rq, port_index(port,
> execlists));
> > last = rq;
> > submit = true;
> > +
> > + mutex_lock(&rq->i915->pred_mutex);
> > + if (atomic_read(&rq->gem_context->req_cnt) > 0)
> > + atomic_dec(&rq->gem_context->req_cnt);
>
> Hitting underflow is a hint accounting does not work as expected. I
> real
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/21] drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h (rev3)
== Series Details == Series: series starting with [01/21] drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h (rev3) URL : https://patchwork.freedesktop.org/series/58065/ State : failure == Summary == Applying: drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h Applying: drm/i915: Sanity check mmap length against object size Applying: drm/i915: Hold a ref to the ring while retiring Applying: drm/i915: Lock the gem_context->active_list while dropping the link Applying: drm/i915: Hold a reference to the active HW context Applying: drm/i915: Stop needlessly acquiring wakeref for debugfs/drop_caches_set Applying: drm/i915/selftests: Provide stub reset functions Applying: drm/i915: Switch to use HWS indices rather than addresses Applying: drm/i915: Separate GEM context construction and registration to userspace Applying: drm/i915: Introduce a mutex for file_priv->context_idr Applying: drm/i915: Introduce the i915_user_extension_method Applying: drm/i915: Create/destroy VM (ppGTT) for use with contexts Applying: drm/i915: Extend CONTEXT_CREATE to set parameters upon construction Applying: drm/i915: Allow contexts to share a single timeline across all engines Applying: drm/i915: Allow userspace to clone contexts on creation Applying: drm/i915: Allow a context to define its set of engines Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_gem_context.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_gem_context.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem_context.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0016 drm/i915: Allow a context to define its set of 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] ✓ Fi.CI.BAT: success for drm/i915: Clean up ilk+ csc stuff (rev2)
== Series Details ==
Series: drm/i915: Clean up ilk+ csc stuff (rev2)
URL : https://patchwork.freedesktop.org/series/56857/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12478
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56857/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12478 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-kbl-7567u: NOTRUN -> SKIP [fdo#109271] +33
* igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103
* igt@gem_exec_basic@readonly-bsd2:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76
* igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u3: PASS -> DMESG-WARN [fdo#109638]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720]
* igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g: NOTRUN -> SKIP [fdo#109271] +65
* igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +33
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-c:
- fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS +1
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109638]: https://bugs.freedesktop.org/show_bug.cgi?id=109638
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
Participating hosts (44 -> 43)
--
Additional (4): fi-kbl-7567u fi-kbl-8809g fi-bwr-2160 fi-pnv-d510
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5753 -> Patchwork_12478
CI_DRM_5753: 0eb0838c0c26378949de6816166117c8b2d73caa @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4887: 5a7c7575b5bb9542f722ed6ba095b9d62609cd56 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12478: ad1b68919282082c87040e7d6bf6697865c23797 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ad1b68919282 drm/i915: Split ilk vs. icl csc matrix handling
a60b33b91254 drm/i915: Clean the csc limited range/identity programming
62a85894dc0d drm/i915: Extract ilk_csc_convert_ctm()
458b09e3c25d drm/i915: Clean up ilk/icl pipe/output CSC programming
7a8744563ab5 drm/i915: Extract ilk_csc_limited_range()
aeb702736320 drm/i915: Preocmpute/readout/check CHV CGM mode
99eabeb8a7fc drm/i915: Readout and check csc_mode
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12478/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix PSR2 selective update corruption after PSR1 setup
On Thu, Mar 14, 2019 at 04:01:13PM -0700, José Roberto de Souza wrote: > There is probably a issue in DMC firmwares(icl_dmc_ver1_07.bin and > kbl_dmc_ver1_04.bin at least) that causes PSR2 SU to fail after > exiting DC6 if EDP_PSR_TP1_TP3_SEL is kept in PSR_CTL, so for now > lets workaround the issue by cleaning PSR_CTL before enable PSR2. > > v2: > - Updated commit description and comment to state that it may be > a DMC firmware issue (Rodrigo) > - No need to RMW, let's write 0 to PSR_CTL(Dhinakaran) > > Cc: Dhinakaran Pandiyan > Cc: Rodrigo Vivi > Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_psr.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index 7d570a45fc17..10bf70e521b6 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -531,6 +531,14 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp) > else > val |= EDP_PSR2_TP2_TIME_2500us; > > + /* > + * FIXME: There is probably a issue in DMC firmwares(icl_dmc_ver1_07.bin > + * and kbl_dmc_ver1_04.bin at least) that causes PSR2 SU to fail after > + * exiting DC6 if EDP_PSR_TP1_TP3_SEL is kept in PSR_CTL, so for now > + * lets workaround the issue by cleaning PSR_CTL before enable PSR2. > + */ > + I915_WRITE(EDP_PSR_CTL, 0); > + > I915_WRITE(EDP_PSR2_CTL, val); > } > > -- > 2.21.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] no-primary
---
drivers/gpu/drm/drm_debugfs.c | 2 +-
drivers/gpu/drm/drm_drv.c | 12
drivers/gpu/drm/drm_prime.c | 2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index f8468eae0503..f7044ff82f9c 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -443,7 +443,7 @@ int drm_debugfs_connector_add(struct drm_connector
*connector)
struct drm_minor *minor = connector->dev->primary;
struct dentry *root, *ent;
- if (!minor->debugfs_root)
+ if (!minor || !minor->debugfs_root)
return -1;
root = debugfs_create_dir(connector->name, minor->debugfs_root);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index adcb437e602d..737ad75597f1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -688,9 +688,11 @@ int drm_dev_init(struct drm_device *dev,
goto err_minors;
}
- ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
- if (ret)
- goto err_minors;
+ if (drm_core_check_feature(dev, DRIVER_LEGACY | DRIVER_MODESET)) {
+ ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
+ if (ret)
+ goto err_minors;
+ }
ret = drm_ht_create(&dev->map_hash, 12);
if (ret)
@@ -1008,7 +1010,9 @@ int drm_dev_register(struct drm_device *dev, unsigned
long flags)
driver->name, driver->major, driver->minor,
driver->patchlevel, driver->date,
dev->dev ? dev_name(dev->dev) : "virtual device",
-dev->primary->index);
+dev->primary ? dev->primary->index :
+dev->render ? dev->render->index :
+-1);
goto out_unlock;
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index dc079efb3b0f..9e821a9c607e 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -676,7 +676,7 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
}
/* Used by drm_gem_mmap() to lookup the GEM object */
- priv->minor = obj->dev->primary;
+ priv->minor = obj->dev->primary ?: obj->dev->render;
fil->private_data = priv;
ret = drm_vma_node_allow(&obj->vma_node, priv);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] no-primary
Wrong branch... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix off-by-one in reporting hanging process
ffs() is 1-indexed, but we want to use it as an index into an array, so
use __ffs() instead.
Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3d8020888604..26bac517e383 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1656,7 +1656,7 @@ error_msg(struct i915_gpu_state *error, unsigned long
engines, const char *msg)
i915_error_generate_code(error, engines));
if (engines) {
/* Just show the first executing process, more is confusing */
- i = ffs(engines);
+ i = __ffs(engines);
len += scnprintf(error->error_msg + len,
sizeof(error->error_msg) - len,
", in %s [%d]",
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix off-by-one in reporting hanging process
On Fri, Mar 15, 2019 at 04:39:33PM +, Chris Wilson wrote:
> ffs() is 1-indexed, but we want to use it as an index into an array, so
> use __ffs() instead.
>
> Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 3d8020888604..26bac517e383 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1656,7 +1656,7 @@ error_msg(struct i915_gpu_state *error, unsigned long
> engines, const char *msg)
> i915_error_generate_code(error, engines));
> if (engines) {
> /* Just show the first executing process, more is confusing */
> - i = ffs(engines);
> + i = __ffs(engines);
> len += scnprintf(error->error_msg + len,
>sizeof(error->error_msg) - len,
>", in %s [%d]",
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915/gtt: Refactor common ppgtt initialisation
On Fri, 15 Mar 2019 09:09:11 + Chris Wilson wrote: > Quoting Rodrigo Vivi (2019-03-14 22:53:44) > > On Thu, Mar 14, 2019 at 10:38:39PM +, Chris Wilson wrote: > > > The basic setup of the i915_hw_ppgtt is the same between gen6 and gen8, > > > so refactor that into a common routine. > > > > > > Signed-off-by: Chris Wilson > > > Cc: Bob Paauwe > > > Cc: Matthew Auld > > > Cc: Joonas Lahtinen > > > > Reviewed-by: Rodrigo Vivi > > I've pushed this series so that 36 bits should be a nice and simple drop > in. > > Thank you Bob for preparing these, sorry for not being clear enough on > the direction I felt the patches should take. > -Chris Thanks Chris, It was helpful to see how you organized and re-wrote the series. This was not code I was familiar with when I started so you're guidance helped a lot. Now I get to fix the EHL patches to take advantage of this. Bob > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- -- Bob Paauwe bob.j.paa...@intel.com IOTG / PED Software Organization Intel Corp. Folsom, CA (916) 356-6193 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: introduce macros to define register contents (rev4)
== Series Details == Series: drm/i915: introduce macros to define register contents (rev4) URL : https://patchwork.freedesktop.org/series/50513/ State : success == Summary == CI Bug Log - changes from CI_DRM_5753_full -> Patchwork_12476_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12476_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@bsd1: - shard-skl: NOTRUN -> SKIP [fdo#109271] +78 * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109283] * igt@gem_ppgtt@blt-vs-render-ctxn: - shard-iclb: NOTRUN -> INCOMPLETE [fdo#107713] / [fdo#109766] / [fdo#109801] * igt@gem_pwrite@huge-gtt-random: - shard-iclb: NOTRUN -> SKIP [fdo#109290] * igt@i915_pm_backlight@fade_with_suspend: - shard-iclb: NOTRUN -> FAIL [fdo#107847] * igt@i915_pm_rpm@gem-execbuf-stress: - shard-skl: PASS -> INCOMPLETE [fdo#107803] / [fdo#107807] * igt@i915_pm_rpm@sysfs-read: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@i915_pm_rps@reset: - shard-iclb: NOTRUN -> FAIL [fdo#108059] +1 * igt@kms_busy@basic-modeset-e: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-hsw: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-oldfb-render-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-pageflip-hang-oldfb-render-d: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +4 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_ccs@pipe-b-crc-sprite-planes-basic: - shard-apl: PASS -> FAIL [fdo#107725] / [fdo#108145] * igt@kms_ccs@pipe-c-crc-sprite-planes-basic: - shard-iclb: NOTRUN -> FAIL [fdo#107725] * igt@kms_chamelium@vga-edid-read: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +1 * igt@kms_color@pipe-b-legacy-gamma: - shard-iclb: NOTRUN -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x128-onscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-128x128-random: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: PASS -> FAIL [fdo#104873] * igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: - shard-glk: PASS -> FAIL [fdo#105454] / [fdo#106509] * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions: - shard-iclb: PASS -> FAIL [fdo#103355] * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: NOTRUN -> SKIP [fdo#109349] * igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +1 * igt@kms_flip@busy-flip: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_flip@flip-vs-suspend: - shard-hsw: PASS -> INCOMPLETE [fdo#103540] * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: NOTRUN -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: - shard-glk: PASS -> FAIL [fdo#103167] - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-pri-indfb-multidraw: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +14 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc: - shard-snb: NOTRUN -> SKIP [fdo#109271] +44 * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-iclb: PASS -> FAIL [fdo#103167] +8 * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-onoff: - shard-iclb: NOTRUN -> FAIL [fdo#109247] +2 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu: - shard-iclb: PASS -> FAIL [fdo#109247] +15 * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format: - shard-iclb: NOTRUN -> FAIL [fdo#109052] * igt@kms_psr@cursor_plane_onoff: - shard
Re: [Intel-gfx] [PATCH 5/5] drm/i915/gtt: Refactor common ppgtt initialisation
On Fri, Mar 15, 2019 at 09:55:47AM -0700, Bob Paauwe wrote: > On Fri, 15 Mar 2019 09:09:11 + > Chris Wilson wrote: > > > Quoting Rodrigo Vivi (2019-03-14 22:53:44) > > > On Thu, Mar 14, 2019 at 10:38:39PM +, Chris Wilson wrote: > > > > The basic setup of the i915_hw_ppgtt is the same between gen6 and gen8, > > > > so refactor that into a common routine. > > > > > > > > Signed-off-by: Chris Wilson > > > > Cc: Bob Paauwe > > > > Cc: Matthew Auld > > > > Cc: Joonas Lahtinen > > > > > > Reviewed-by: Rodrigo Vivi > > > > I've pushed this series so that 36 bits should be a nice and simple drop > > in. > > > > Thank you Bob for preparing these, sorry for not being clear enough on > > the direction I felt the patches should take. > > -Chris > > Thanks Chris, Thanks a lot Chris. > > It was helpful to see how you organized and re-wrote the series. This > was not code I was familiar with when I started so you're guidance > helped a lot. > > Now I get to fix the EHL patches to take advantage of this. cool, so I will split the series into rv-b ones and probably push soon just leaving the ppgt_size one for you to rebase on top... thoughts? > > Bob > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > -- > -- > Bob Paauwe > bob.j.paa...@intel.com > IOTG / PED Software Organization > Intel Corp. Folsom, CA > (916) 356-6193 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915: Introduce concept of a sub-platform
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consolidate device ids checking into a single function
called during early driver load.
A few low bits in the platform mask are reserved for sub-platform
identification and defined as a per-platform namespace.
At the same time it future proofs the platform_mask handling by preparing
the code for easy extending, and tidies the very verbose WARN strings
generated when IS_PLATFORM macros are embedded into a WARN type
statements.
v2: Fixed IS_SUBPLATFORM. Updated commit msg.
v3: Chris was right, there is an ordering problem.
v4:
* Catch-up with new sub-platforms.
* Rebase for RUNTIME_INFO.
* Drop subplatform mask union tricks and convert platform_mask to an
array for extensibility.
v5:
* Fix subplatform check.
* Protect against forgetting to expand subplatform bits.
* Remove platform enum tallying.
* Add subplatform to error state. (Chris)
* Drop macros and just use static inlines.
* Remove redundant IRONLAKE_M. (Ville)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Jose Souza
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 131 ---
drivers/gpu/drm/i915/i915_gpu_error.c| 1 +
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 71
drivers/gpu/drm/i915/intel_device_info.h | 20 +++-
6 files changed, 187 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a3b00ecc58c9..5551695a1db5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -863,6 +863,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
if (i915_inject_load_failure())
return -ENODEV;
+ intel_device_info_subplatform_init(dev_priv);
+
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
mutex_init(&dev_priv->backlight_lock);
@@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
drm_i915_private *dev_priv)
if (drm_debug & DRM_UT_DRIVER) {
struct drm_printer p = drm_debug_printer("i915 device info:");
- drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
+ drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
INTEL_DEVID(dev_priv),
INTEL_REVID(dev_priv),
intel_platform_name(INTEL_INFO(dev_priv)->platform),
+ intel_subplatform(dev_priv),
INTEL_GEN(dev_priv));
intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
@@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
memcpy(device_info, match_info, sizeof(*device_info));
RUNTIME_INFO(i915)->device_id = pdev->device;
- BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
-BITS_PER_TYPE(device_info->platform_mask));
BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
return i915;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c65c2e6649df..ea9fb7967c6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2281,7 +2281,66 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_REVID(p, since, until) \
(INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
-#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask & BIT(p))
+static inline unsigned int
+__platform_mask_index(const struct drm_i915_private *i915,
+ enum intel_platform p)
+{
+ const unsigned int pbits =
+ BITS_PER_TYPE(RUNTIME_INFO(i915)->platform_mask[0]) -
+ INTEL_SUBPLATFORM_BITS;
+
+ /* Expand the platform_mask array if this fails. */
+ BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
+pbits * ARRAY_SIZE(RUNTIME_INFO(i915)->platform_mask));
+
+ return p / pbits;
+}
+
+static inline unsigned int
+__platform_mask_bit(const struct drm_i915_private *i915, enum intel_platform p)
+{
+ const unsigned int pbits =
+ BITS_PER_TYPE(RUNTIME_INFO(i915)->platform_mask[0]) -
+ INTEL_SUBPLATFORM_BITS;
+
+ return p % pbits + INTEL_SUBPLATFORM_BITS;
+}
+
+static inline u32 intel_subplatform(const struct drm_i915_private *i915)
+{
+ const unsigned int pi =
+ __platform_mask_index(i915, INTEL_INFO(i915)->platform);
+
+ return RUNTIME_INFO(i915)->platform_mask[pi] & INTEL_SUBPLATFORM_BITS;
+}
+
+static inli
Re: [Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consolidate device ids checking into a single function
called during early driver load.
A few low bits in the platform mask are reserved for sub-platform
identification and defined as a per-platform namespace.
At the same time it future proofs the platform_mask handling by preparing
the code for easy extending, and tidies the very verbose WARN strings
generated when IS_PLATFORM macros are embedded into a WARN type
statements.
The approach is also beneficial to driver size, with an combined shrink of
code and strings of around 1.7 kiB.
v2: Fixed IS_SUBPLATFORM. Updated commit msg.
v3: Chris was right, there is an ordering problem.
v4:
* Catch-up with new sub-platforms.
* Rebase for RUNTIME_INFO.
* Drop subplatform mask union tricks and convert platform_mask to an
array for extensibility.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Jose Souza
---
drivers/gpu/drm/i915/i915_drv.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 110 +++
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 79
drivers/gpu/drm/i915/intel_device_info.h | 28 +-
5 files changed, 179 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d743907e7bc..3218350cd225 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -863,6 +863,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv)
if (i915_inject_load_failure())
return -ENODEV;
+ intel_device_info_subplatform_init(dev_priv);
+
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
mutex_init(&dev_priv->backlight_lock);
@@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
drm_i915_private *dev_priv)
if (drm_debug & DRM_UT_DRIVER) {
struct drm_printer p = drm_debug_printer("i915 device info:");
- drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
+ drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
gen=%i\n",
INTEL_DEVID(dev_priv),
INTEL_REVID(dev_priv),
intel_platform_name(INTEL_INFO(dev_priv)->platform),
+
RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
(BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - INTEL_SUBPLATFORM_BITS)],
bug here, INTEL_SUBPLATFORM_BITS should be outside of []. Bad things
will happen for platform=32 /o\
INTEL_GEN(dev_priv));
intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
@@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
memcpy(device_info, match_info, sizeof(*device_info));
RUNTIME_INFO(i915)->device_id = pdev->device;
- BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
-BITS_PER_TYPE(device_info->platform_mask));
BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
return i915;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dccb6006aabf..34282cf66cb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2281,7 +2281,46 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_REVID(p, since, until) \
(INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
-#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask & BIT(p))
+#define __IS_PLATFORM(dev_priv, p) \
+({ \
+ const unsigned int pbits__ = \
+ BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
+ INTEL_SUBPLATFORM_BITS; \
+ const unsigned int pi__ = (p) / pbits__; \
+ const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
+\
+ BUILD_BUG_ON(!__builtin_constant_p(p)); \
+\
+ (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & BIT(pb__)); \
Ugh. That double dword fiddling is way too ugly. IMO it is not buying us
anything. Just use a u64 rather than the double dword. Your approach may
have a small benefit on ARCH=i386, but has the burden of carrying all
this forward. The diff below (only build-tested) is on top of yours,
which is basically equivalent to "move to u64 and then add the
subplatform part".
textdata bss dec hex filename
1834620 404544176 1879250 1cacd2 drivers/gpu/drm/i915/i915.o.yours
1834710 404544176 1879340 1cad2c drivers/gpu/drm/i915/i915.o
diff -
Re: [Intel-gfx] [PATCH 5/5] drm/i915/gtt: Refactor common ppgtt initialisation
On Fri, 15 Mar 2019 10:01:51 -0700 Rodrigo Vivi wrote: > On Fri, Mar 15, 2019 at 09:55:47AM -0700, Bob Paauwe wrote: > > On Fri, 15 Mar 2019 09:09:11 + > > Chris Wilson wrote: > > > > > Quoting Rodrigo Vivi (2019-03-14 22:53:44) > > > > On Thu, Mar 14, 2019 at 10:38:39PM +, Chris Wilson wrote: > > > > > The basic setup of the i915_hw_ppgtt is the same between gen6 and > > > > > gen8, > > > > > so refactor that into a common routine. > > > > > > > > > > Signed-off-by: Chris Wilson > > > > > Cc: Bob Paauwe > > > > > Cc: Matthew Auld > > > > > Cc: Joonas Lahtinen > > > > > > > > Reviewed-by: Rodrigo Vivi > > > > > > I've pushed this series so that 36 bits should be a nice and simple drop > > > in. > > > > > > Thank you Bob for preparing these, sorry for not being clear enough on > > > the direction I felt the patches should take. > > > -Chris > > > > Thanks Chris, > > Thanks a lot Chris. > > > > > It was helpful to see how you organized and re-wrote the series. This > > was not code I was familiar with when I started so you're guidance > > helped a lot. > > > > Now I get to fix the EHL patches to take advantage of this. > > cool, so I will split the series into rv-b ones and probably > push soon just leaving the ppgt_size one for you to rebase > on top... > > thoughts? Would it make more sense to drop Patch 8, drm/i915/ehl: ehl has only 36bit extended ppgtt support and update patch 1 with the size added to the device_info? Otherwise, patch 8 becomes just adding the size into the device_info. Either way works for me. > > > > > Bob > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > -- > > -- > > Bob Paauwe > > bob.j.paa...@intel.com > > IOTG / PED Software Organization > > Intel Corp. Folsom, CA > > (916) 356-6193 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- -- Bob Paauwe bob.j.paa...@intel.com IOTG / PED Software Organization Intel Corp. Folsom, CA (916) 356-6193 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Introduce concept of a sub-platform
Quoting Tvrtko Ursulin (2019-03-15 17:09:28)
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 3d8020888604..e3360a31f8d3 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -677,6 +677,7 @@ static void __err_print_to_sgl(struct
> drm_i915_error_state_buf *m,
> err_printf(m, "Reset count: %u\n", error->reset_count);
> err_printf(m, "Suspend count: %u\n", error->suspend_count);
> err_printf(m, "Platform: %s\n",
> intel_platform_name(error->device_info.platform));
> + err_printf(m, "Subplatform: 0x%x\n", intel_subplatform(m->i915));
We didn't take a copy of the runtime_info? Ww should have done at least,
that's even more volatile than device_info.
It'll do for now, but would be nicer if RUNTIME_INFO(i915) wasn't baked
so hard into the subplatform :)
> +void intel_device_info_subplatform_init(struct drm_i915_private *i915)
> +{
> + const unsigned int pi =
> + __platform_mask_index(i915, INTEL_INFO(i915)->platform);
> + const unsigned int pb =
> + __platform_mask_bit(i915, INTEL_INFO(i915)->platform);
> + u16 devid = INTEL_DEVID(i915);
> + u32 mask = 0;
> +
> + RUNTIME_INFO(i915)->platform_mask[pi] = BIT(pb);
> +
> + if (IS_PINEVIEW(i915)) {
> + if (devid == 0xa001)
> + mask |= BIT(INTEL_SUBPLATFORM_PINEVIEW_G);
> + else if (devid == 0xa011)
> + mask |= BIT(INTEL_SUBPLATFORM_PINEVIEW_M);
I take it, leaving is-mobile conversion for the display gurus?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Introduce concept of a sub-platform
On 15/03/2019 17:12, Lucas De Marchi wrote:
On Fri, Mar 15, 2019 at 12:26:33PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Concept of a sub-platform already exist in our code (like ULX and ULT
platform variants and similar),implemented via the macros which check a
list of device ids to determine a match.
With this patch we consolidate device ids checking into a single function
called during early driver load.
A few low bits in the platform mask are reserved for sub-platform
identification and defined as a per-platform namespace.
At the same time it future proofs the platform_mask handling by preparing
the code for easy extending, and tidies the very verbose WARN strings
generated when IS_PLATFORM macros are embedded into a WARN type
statements.
The approach is also beneficial to driver size, with an combined
shrink of
code and strings of around 1.7 kiB.
v2: Fixed IS_SUBPLATFORM. Updated commit msg.
v3: Chris was right, there is an ordering problem.
v4:
* Catch-up with new sub-platforms.
* Rebase for RUNTIME_INFO.
* Drop subplatform mask union tricks and convert platform_mask to an
array for extensibility.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Jose Souza
---
drivers/gpu/drm/i915/i915_drv.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 110 +++
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 79
drivers/gpu/drm/i915/intel_device_info.h | 28 +-
5 files changed, 179 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 0d743907e7bc..3218350cd225 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -863,6 +863,8 @@ static int i915_driver_init_early(struct
drm_i915_private *dev_priv)
if (i915_inject_load_failure())
return -ENODEV;
+ intel_device_info_subplatform_init(dev_priv);
+
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
mutex_init(&dev_priv->backlight_lock);
@@ -1752,10 +1754,11 @@ static void i915_welcome_messages(struct
drm_i915_private *dev_priv)
if (drm_debug & DRM_UT_DRIVER) {
struct drm_printer p = drm_debug_printer("i915 device info:");
- drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s gen=%i\n",
+ drm_printf(&p, "pciid=0x%04x rev=0x%02x platform=%s (%x)
gen=%i\n",
INTEL_DEVID(dev_priv),
INTEL_REVID(dev_priv),
intel_platform_name(INTEL_INFO(dev_priv)->platform),
+
RUNTIME_INFO(dev_priv)->platform_mask[INTEL_INFO(dev_priv)->platform /
(BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) -
INTEL_SUBPLATFORM_BITS)],
bug here, INTEL_SUBPLATFORM_BITS should be outside of []. Bad things
will happen for platform=32 /o\
? [32 / (32 - 3)] = [1], for which there is a BUILD_BUG_ON with a
comment saying to increase size of array.
INTEL_GEN(dev_priv));
intel_device_info_dump_flags(INTEL_INFO(dev_priv), &p);
@@ -1798,8 +1801,6 @@ i915_driver_create(struct pci_dev *pdev, const
struct pci_device_id *ent)
memcpy(device_info, match_info, sizeof(*device_info));
RUNTIME_INFO(i915)->device_id = pdev->device;
- BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
- BITS_PER_TYPE(device_info->platform_mask));
BUG_ON(device_info->gen > BITS_PER_TYPE(device_info->gen_mask));
return i915;
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index dccb6006aabf..34282cf66cb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2281,7 +2281,46 @@ static inline unsigned int
i915_sg_segment_size(void)
#define IS_REVID(p, since, until) \
(INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
-#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask
& BIT(p))
+#define __IS_PLATFORM(dev_priv, p) \
+({ \
+ const unsigned int pbits__ = \
+ BITS_PER_TYPE(RUNTIME_INFO(dev_priv)->platform_mask[0]) - \
+ INTEL_SUBPLATFORM_BITS; \
+ const unsigned int pi__ = (p) / pbits__; \
+ const unsigned int pb__ = (p) % pbits__ + INTEL_SUBPLATFORM_BITS; \
+\
+ BUILD_BUG_ON(!__builtin_constant_p(p)); \
+\
+ (RUNTIME_INFO(dev_priv)->platform_mask[pi__] & BIT(pb__)); \
Ugh. That double dword fiddling is way too ugly. IMO it is not buying us
anything. Just use a u64 rather than the double dword. Your approach may
have a small benefit on ARCH=i386, but has the burden of carrying all
this forward. The diff below (only build-tested) is on top of yours,
which is basically equivalent to "move to u64 and then add the
subplatform part".
text data bss dec hex filename
1834620 40454 4176 1879250 1cacd2 drivers/gpu/drm/i915/i915.o.yours
1834710 40454 4176 1879340 1cad2c drivers/gpu/drm/i915/i915.o
The cost
Re: [Intel-gfx] [PATCH v5] drm/i915: Introduce concept of a sub-platform
On 15/03/2019 17:28, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-15 17:09:28)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3d8020888604..e3360a31f8d3 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -677,6 +677,7 @@ static void __err_print_to_sgl(struct
drm_i915_error_state_buf *m,
err_printf(m, "Reset count: %u\n", error->reset_count);
err_printf(m, "Suspend count: %u\n", error->suspend_count);
err_printf(m, "Platform: %s\n",
intel_platform_name(error->device_info.platform));
+ err_printf(m, "Subplatform: 0x%x\n", intel_subplatform(m->i915));
We didn't take a copy of the runtime_info? Ww should have done at least,
that's even more volatile than device_info.
It'll do for now, but would be nicer if RUNTIME_INFO(i915) wasn't baked
so hard into the subplatform :)
Could do yeah.
+void intel_device_info_subplatform_init(struct drm_i915_private *i915)
+{
+ const unsigned int pi =
+ __platform_mask_index(i915, INTEL_INFO(i915)->platform);
+ const unsigned int pb =
+ __platform_mask_bit(i915, INTEL_INFO(i915)->platform);
+ u16 devid = INTEL_DEVID(i915);
+ u32 mask = 0;
+
+ RUNTIME_INFO(i915)->platform_mask[pi] = BIT(pb);
+
+ if (IS_PINEVIEW(i915)) {
+ if (devid == 0xa001)
+ mask |= BIT(INTEL_SUBPLATFORM_PINEVIEW_G);
+ else if (devid == 0xa011)
+ mask |= BIT(INTEL_SUBPLATFORM_PINEVIEW_M);
I take it, leaving is-mobile conversion for the display gurus?
Ville said it will be hard so I did not even look. :) Okay, it doesn't
seem that hard.. but definitely wouldn't stuff it into this patch.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for no-primary
== Series Details == Series: no-primary URL : https://patchwork.freedesktop.org/series/58072/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5753 -> Patchwork_12480 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12480 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12480, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/58072/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12480: ### IGT changes ### Possible regressions * igt@gem_ringfill@basic-default: - fi-icl-u2: PASS -> SKIP +25 * igt@prime_vgem@basic-busy-default: - fi-icl-u3: PASS -> SKIP +25 Known issues Here are the changes found in Patchwork_12480 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094] * igt@amdgpu/amd_cs_nop@sync-gfx0: - fi-kbl-7567u: NOTRUN -> SKIP [fdo#109271] +59 * igt@gem_exec_basic@gtt-bsd: - fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +121 * igt@gem_exec_basic@readonly-bsd2: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +102 * igt@gem_ringfill@basic-default: - fi-bdw-gvtdvm: PASS -> SKIP [fdo#109271] +25 * igt@gem_ringfill@basic-default-fd: - fi-skl-6700k2: PASS -> SKIP [fdo#109271] +25 * igt@gem_ringfill@basic-default-forked: - fi-skl-gvtdvm: PASS -> SKIP [fdo#109271] +25 - fi-hsw-peppy: PASS -> SKIP [fdo#109271] +24 - fi-kbl-x1275: PASS -> SKIP [fdo#109271] +25 - fi-kbl-7500u: PASS -> SKIP [fdo#109271] +4 * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@kms_busy@basic-flip-c: - fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_force_connector_basic@force-load-detect: - fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +58 * igt@prime_vgem@basic-busy-default: - fi-bsw-n3050: PASS -> SKIP [fdo#109271] +24 * igt@prime_vgem@basic-fence-flip: - fi-hsw-4770r: PASS -> SKIP [fdo#109271] +25 * igt@prime_vgem@basic-fence-read: - fi-bsw-kefka: PASS -> SKIP [fdo#109271] +24 - fi-ilk-650: PASS -> SKIP [fdo#109271] +24 - fi-elk-e7500: PASS -> SKIP [fdo#109271] +24 - fi-skl-6770hq: PASS -> SKIP [fdo#109271] +25 * igt@prime_vgem@basic-fence-wait-default: - fi-cfl-8109u: PASS -> SKIP [fdo#109271] +25 * igt@prime_vgem@basic-sync-default: - fi-byt-n2820: PASS -> SKIP [fdo#109271] +25 - fi-bxt-j4205: PASS -> SKIP [fdo#109271] +25 - fi-skl-6260u: PASS -> SKIP [fdo#109271] +25 - fi-byt-j1900: PASS -> SKIP [fdo#109271] +25 * igt@prime_vgem@basic-wait-default: - fi-kbl-guc: PASS -> SKIP [fdo#109271] +24 - fi-hsw-4770:PASS -> SKIP [fdo#109271] +25 * igt@prime_vgem@basic-write: - fi-skl-6600u: PASS -> SKIP [fdo#109271] +24 * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] * igt@vgem_basic@debugfs: - fi-skl-guc: PASS -> SKIP [fdo#109271] +25 - fi-cfl-guc: PASS -> SKIP [fdo#109271] +25 - fi-whl-u: PASS -> SKIP [fdo#109271] +24 * igt@vgem_basic@dmabuf-export: - fi-apl-guc: PASS -> SKIP [fdo#109271] +25 - fi-cfl-8700k: PASS -> SKIP [fdo#109271] +25 - fi-kbl-r: PASS -> SKIP [fdo#109271] +24 - fi-byt-clapper: PASS -> SKIP [fdo#109271] +24 * igt@vgem_basic@dmabuf-fence: - fi-snb-2600:PASS -> SKIP [fdo#109271] +25 - fi-gdg-551: PASS -> SKIP [fdo#109271] +17 * igt@vgem_basic@mmap: - fi-ivb-3770:PASS -> SKIP [fdo#109271] +25 - fi-snb-2520m: PASS -> SKIP [fdo#109271] +24 * igt@vgem_basic@setversion: - fi-kbl-8809g: NOTRUN -> SKIP [fdo#109271] +92 * igt@vgem_basic@sysfs: - fi-bdw-5557u: PASS -> SKIP [fdo#109271] +25 * igt@vgem_basic@unload: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +74 Possible fixes * igt@gem_ctx_create@basic-files: - fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@kms_busy@basic-flip-a: - fi-gdg-551: FAIL [fdo#103182] -> PASS +1 * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3:
Re: [Intel-gfx] [PATCH] drm/i915: Drop platform_mask
Em sex, 2019-03-15 às 06:56 +, Tvrtko Ursulin escreveu: > On 15/03/2019 00:52, Chris Wilson wrote: > > Quoting José Roberto de Souza (2019-03-15 00:42:35) > > > We don't have any platform that is composed by 2 or more platforms so > > > we don't need a mask, lets drop it and remove the actual limit of 32 > > > platforms. > > Platform mask was a nifty trick to compile tests like IS_SKYLAKE || > IS_BROADWELL etc into a single conditional. > So perhaps the code would benefit from a small comment that says exactly that, so the next person looking at it won't propose its removal again. José, would you volunteer for that patch? > > gcc doesn't entirely agree, this is a net loss here (i.e. code size > > increases). > > Perhaps the size re-gain of dropping the platform mask could be checked > against the size gain of making the mask 64 bit. > > However, one other benefit of the mask will also help with dead code > elimination once per SKU build work is resurfaced. For the single > selected platforms it doesn't matter, but for a subset it still does I > think. > > So I think we got two questions here - checking between size gains of > the two options, and how interesting would multi-platform builds be. > > One use case for the latter I had in mind was legacy vs execlists driver > build but that wasn't based on any formal feature requests as far as I > am aware. > > Regards, > > Tvrtko > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 5/6] drm/i915/ehl: Set proper eu slice/subslice parameters for EHL
From: Bob Paauwe
EHL has a different number of subslices.
Cc: Lucas De Marchi
Signed-off-by: Bob Paauwe
Signed-off-by: Rodrigo Vivi
Reviewed-by: Lucas De Marchi
Link:
https://patchwork.freedesktop.org/patch/msgid/20190313211144.4842-7-rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_device_info.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index db00110cbb2e..e0ac908bb4e9 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -156,9 +156,15 @@ static void gen11_sseu_info_init(struct drm_i915_private
*dev_priv)
u8 eu_en;
int s;
- sseu->max_slices = 1;
- sseu->max_subslices = 8;
- sseu->max_eus_per_subslice = 8;
+ if (IS_ELKHARTLAKE(dev_priv)) {
+ sseu->max_slices = 1;
+ sseu->max_subslices = 4;
+ sseu->max_eus_per_subslice = 8;
+ } else {
+ sseu->max_slices = 1;
+ sseu->max_subslices = 8;
+ sseu->max_eus_per_subslice = 8;
+ }
s_en = I915_READ(GEN11_GT_SLICE_ENABLE) & GEN11_GT_S_ENA_MASK;
ss_en = ~I915_READ(GEN11_GT_SUBSLICE_DISABLE);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/6] drm/i915/ehl: Add EHL platform info and PCI IDs
From: James Ausmus
Add known EHL PCI IDs.
v2 (Rodrigo): Removed x86 early quirk. To be sent in a separated
patch cc'ing the appropriated list and maintainers for proper ack.
Cc: Bob Paauwe
Signed-off-by: James Ausmus
Signed-off-by: Rodrigo Vivi
Reviewed-by: José Roberto de Souza
Link:
https://patchwork.freedesktop.org/patch/msgid/20190313211144.4842-1-rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_pci.c | 9 +
include/drm/i915_pciids.h | 7 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ef7410c492fd..da199125c1e5 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -730,6 +730,14 @@ static const struct intel_device_info
intel_icelake_11_info = {
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
};
+static const struct intel_device_info intel_elkhartlake_info = {
+ GEN11_FEATURES,
+ PLATFORM(INTEL_ICELAKE),
+ .num_pipes = 3,
+ .is_alpha_support = 1,
+ .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0),
+};
+
#undef GEN
#undef PLATFORM
@@ -797,6 +805,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_WHL_U_GT3_IDS(&intel_coffeelake_gt3_info),
INTEL_CNL_IDS(&intel_cannonlake_info),
INTEL_ICL_11_IDS(&intel_icelake_11_info),
+ INTEL_EHL_IDS(&intel_elkhartlake_info),
{0, 0, 0}
};
MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index d20feeaa..a0e409e9e70d 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -472,4 +472,11 @@
INTEL_VGA_DEVICE(0x8A70, info), \
INTEL_VGA_DEVICE(0x8A53, info)
+/* EHL */
+#define INTEL_EHL_IDS(info) \
+ INTEL_VGA_DEVICE(0x4500, info), \
+ INTEL_VGA_DEVICE(0x4571, info), \
+ INTEL_VGA_DEVICE(0x4551, info), \
+ INTEL_VGA_DEVICE(0x4541, info)
+
#endif /* _I915_PCIIDS_H */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/6] drm/i915/ehl: Add ElkhartLake platform
From: Bob Paauwe
Add ElkhartLake as a unique platform as there are some differences
between it and Icelake.
Signed-off-by: Bob Paauwe
Signed-off-by: Rodrigo Vivi
Reviewed-by: Lucas De Marchi
Link:
https://patchwork.freedesktop.org/patch/msgid/20190313211144.4842-2-rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_pci.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
4 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c65c2e6649df..12e430e94ae0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2315,6 +2315,7 @@ static inline unsigned int i915_sg_segment_size(void)
#define IS_COFFEELAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_COFFEELAKE)
#define IS_CANNONLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_CANNONLAKE)
#define IS_ICELAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ICELAKE)
+#define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)
#define IS_MOBILE(dev_priv)(INTEL_INFO(dev_priv)->is_mobile)
#define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index da199125c1e5..b25eaf18d1dc 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -732,7 +732,7 @@ static const struct intel_device_info intel_icelake_11_info
= {
static const struct intel_device_info intel_elkhartlake_info = {
GEN11_FEATURES,
- PLATFORM(INTEL_ICELAKE),
+ PLATFORM(INTEL_ELKHARTLAKE),
.num_pipes = 3,
.is_alpha_support = 1,
.engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0),
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index eddf83807957..db00110cbb2e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -57,6 +57,7 @@ static const char * const platform_names[] = {
PLATFORM_NAME(COFFEELAKE),
PLATFORM_NAME(CANNONLAKE),
PLATFORM_NAME(ICELAKE),
+ PLATFORM_NAME(ELKHARTLAKE),
};
#undef PLATFORM_NAME
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 6234570a9b17..98acefaacec9 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -73,6 +73,7 @@ enum intel_platform {
INTEL_CANNONLAKE,
/* gen11 */
INTEL_ICELAKE,
+ INTEL_ELKHARTLAKE,
INTEL_MAX_PLATFORMS
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/6] drm/i915/ehl: Add dpll mgr
From: Lucas De Marchi
Elkhart Lake has a different set of PLLs as compared to Ice Lake,
although programming them is very similar.
Signed-off-by: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
Reviewed-by: José Roberto de Souza
Link:
https://patchwork.freedesktop.org/patch/msgid/20190313211144.4842-4-rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index b3fb221c2532..a9feb119c19f 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -3246,6 +3246,18 @@ static const struct intel_dpll_mgr icl_pll_mgr = {
.dump_hw_state = icl_dump_hw_state,
};
+static const struct dpll_info ehl_plls[] = {
+ { "DPLL 0", &icl_pll_funcs, DPLL_ID_ICL_DPLL0, 0 },
+ { "DPLL 1", &icl_pll_funcs, DPLL_ID_ICL_DPLL1, 0 },
+ { },
+};
+
+static const struct intel_dpll_mgr ehl_pll_mgr = {
+ .dpll_info = ehl_plls,
+ .get_dpll = icl_get_dpll,
+ .dump_hw_state = icl_dump_hw_state,
+};
+
/**
* intel_shared_dpll_init - Initialize shared DPLLs
* @dev: drm device
@@ -3259,7 +3271,9 @@ void intel_shared_dpll_init(struct drm_device *dev)
const struct dpll_info *dpll_info;
int i;
- if (INTEL_GEN(dev_priv) >= 11)
+ if (IS_ELKHARTLAKE(dev_priv))
+ dpll_mgr = &ehl_pll_mgr;
+ else if (INTEL_GEN(dev_priv) >= 11)
dpll_mgr = &icl_pll_mgr;
else if (IS_CANNONLAKE(dev_priv))
dpll_mgr = &cnl_pll_mgr;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
