[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix per-pixel alpha with CCS
== Series Details == Series: drm/i915: Fix per-pixel alpha with CCS URL : https://patchwork.freedesktop.org/series/61526/ State : success == Summary == CI Bug Log - changes from CI_DRM_6182_full -> Patchwork_13160_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13160_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@hang: - shard-iclb: [PASS][1] -> [FAIL][2] ([fdo#109677]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-iclb3/igt@gem_mmap_...@hang.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-iclb2/igt@gem_mmap_...@hang.html * igt@gem_tiled_swapping@non-threaded: - shard-kbl: [PASS][3] -> [FAIL][4] ([fdo#108686]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-kbl4/igt@gem_tiled_swapp...@non-threaded.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-kbl6/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-apl4/igt@gem_workarou...@suspend-resume-context.html * igt@i915_suspend@debugfs-reader: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-skl10/igt@i915_susp...@debugfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-skl7/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#110741]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_legacy@cursor-vs-flip-atomic: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#103355]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-hsw4/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-hsw5/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html * igt@kms_flip@dpms-vs-vblank-race-interruptible: - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#103060]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-glk1/igt@kms_f...@dpms-vs-vblank-race-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-glk8/igt@kms_f...@dpms-vs-vblank-race-interruptible.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-skl8/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-skl5/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-render.html * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108] / [fdo#106978]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-skl2/igt@kms_frontbuffer_track...@psr-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-skl5/igt@kms_frontbuffer_track...@psr-suspend.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/shard-iclb5/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_setmode@basic: - shard-apl: [PASS][25] -> [FAIL][26] ([fdo#99912]) [25]:
Re: [Intel-gfx] [PATCH] drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15
On 5/30/19 2:20 PM, Manasi Navare wrote:
On Thu, May 30, 2019 at 12:33:40PM -0700, Almahallawy, Khaled wrote:
On Wed, 2019-05-22 at 12:25 -0700, Manasi Navare wrote:
On Tue, May 21, 2019 at 04:24:58PM +0300, Ville Syrjälä wrote:
On Mon, May 20, 2019 at 04:25:41PM -0700, Khaled Almahallawy wrote:
According to DP 1.4 standard, if the source supports four pre-
emphasis levels, then the source shall set the bit MAX_PRE-
EMPHASIS_REACHED = 1 only when trasmitter programmed PRE-
EMPHASIS_SET field (bits 4:3) to 11b (Level 3). Pre-emphasis
level 3 is the maximum pre-emphasis level that the source
supports.
Currently the MAX_PRE-EMPHASIS_REACHED bit is interpreted as the
Max Pre-Emphasis level for certain Swing Level. This
interpretation fails Link Layer compliance test 400.3.1.15 step
17 according to the following Fail condition:
TRAINING_LANEx_SET.MAX_PRE-EMPHASIS_REACHED = 1 (check all active
lanes) and the Source DUT supports pre-emphasis level 3 (9.5db).
Hmm. I guess that's correct. The spec doesn't say anything about
per-vswing pre-emphasis when talking about the 'max reached' bit.
Cc: Clint Taylor
Cc: Manasi Navare
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/intel_ddi.c | 20
drivers/gpu/drm/i915/intel_dp.c | 2 +-
2 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 0af47f343faa..6540c979c098 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2239,26 +2239,6 @@ u8 intel_ddi_dp_voltage_max(struct
intel_encoder *encoder)
DP_TRAIN_VOLTAGE_SWING_MASK;
}
-/*
- * We assume that the full set of pre-emphasis values can be
- * used on all DDI platforms. Should that change we need to
- * rethink this code.
- */
-u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder,
u8 voltage_swing)
-{
- switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
- return DP_TRAIN_PRE_EMPH_LEVEL_3;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
- return DP_TRAIN_PRE_EMPH_LEVEL_2;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
- return DP_TRAIN_PRE_EMPH_LEVEL_1;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
- default:
- return DP_TRAIN_PRE_EMPH_LEVEL_0;
- }
-}
-
static void cnl_ddi_vswing_program(struct intel_encoder
*encoder,
int level, enum intel_output_type
type)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 77ba4da6b981..f94759e45862 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3541,7 +3541,7 @@ intel_dp_pre_emphasis_max(struct intel_dp
*intel_dp, u8 voltage_swing)
enum port port = encoder->port;
if (HAS_DDI(dev_priv)) {
- return intel_ddi_dp_pre_emphasis_max(encoder,
voltage_swing);
+ return DP_TRAIN_PRE_EMPH_LEVEL_3;
We're going to have to change this for all platforms.
Yes, I'm going to change for all platforms in intel_dp_pre_emphasis_max
function. I will also add the missing condition:
else if (HAS_PCH_CPT(dev_priv) && port != PORT_A)
similar to intel_dp_voltage_max function
Also we need to update the code to pick the correct swing/pre-
emphasis
when we can't do what is being requested.
This check will need to be added in adjust_train() function
sure, I will implement this logic in intel_get_adjust_train
The spec says:
"When the combination of the requested pre-emphasis level and
voltage
swing exceeds the capability of a DPTX, the DPTX shall set the
pre-emphasis
level according to the request and use the highest voltage swing
it can
output with the given pre-emphasis level."
and
"When a DPTX reads a request beyond the limits of this Standard,
the
DPTX shall set the pre-emphasis level according to the request and
set
the highest voltage swing level it can output with the given pre-
emphasis
level. If a DPTX is requested for 9.5dB of pre-emphasis level (may
be
supported for a DPTX) and cannot support that level, it shall set
the
pre-emphasis level to the next highest level, 6dB."
So my interpretation of this is :
In adjust_train() function:
vswing_max = intel_dp_voltage_max() which is set per platform
pre_emphasis_max = set to level 3
pre_emphasis_max = intel_dp_pre_emphasis_max
because it is set per platfrom as well, similar to vswing_max
v = get_requested_voltage_swing() - Limit this to vmax
p = get_requested_pre_emphasis() - Limit this to pmax
Now rewrite the intel_ddi_dp_pre_emphasis_max() function to call it
intel_ddi_dp_pre_emphasis_max is needed to determine the max pre-
emphasis level per platform.
What I meant was that define another function that will return a
pre_emphasis_max
per platform but independent of the vswing values.
Makes sense?
Manasi
Yes that make sense.
I thought of modifying
Re: [Intel-gfx] [RFC 1/3] kbuild: add support for ensuring headers are self-contained
Hi Sam, Jani, On Tue, Jun 4, 2019 at 2:33 AM Sam Ravnborg wrote: > > Hi Masahiro/Jani. > > > > > Following the obj-y pattern, > > I want to make header-test-y relative to $(obj). > > I also considered this and agree this is better. > > Otherwise we end up with a spaghetti of dependencies across the tree. > > What I made just fit the purpose I had that day, > which is no excuse for bad design. > > > I prefer this: > > > > quiet_cmd_header_test = HDRTEST $@ > > cmd_header_test = echo "\#include \"$*.h\"" > $@ > > > > $(obj)/%.header_test.c: > > $(call cmd,header_test) > > Even better - good. > > We call it HDRTEST - so why not just go for that name: > > hdrtest-y += headerfile.h > > ?? > > The current proposal with "header-test-y" hurts the eye a little with > two '-', and all other variables uses only one '-' as is today. > (generic-y, obj-y etc). > > This is bikeshedding but is was itcing me a little. I do not have a strong opinion. I leave it to Jani. Either is fine with me. There are variables that contain two '-'. 'no-clean-files', 'subdir-ccflags-y', etc. -- Best Regards Masahiro Yamada ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Correctly advertise HBR3 for GEN11+
On Mon, Jun 03, 2019 at 02:49:40PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
> use before encoder_type is set. This caused GEN11+ to incorrectly strip
> HBR3 from source rates. Move intel_dp_set_source_rates() to after
> encoder_type is set. Add comment to intel_dp_is_edp() describing unsafe
> usages.
May be also add a WARN_ON inside intel_dp_is_edp() for encoder->type
still set to INTEL_OUTPUT_DDI
>
> Fixes: b265a2a6255f5 ("drm/i915/icl: combo port vswing programming
> changes per BSPEC")
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/intel_dp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 24b56b2a76c8..a4490bcad684 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -141,6 +141,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> *
> * If a CPU or PCH DP output is attached to an eDP panel, this function
> * will return true, and false otherwise.
> + *
> + * This function is not safe to use prior to encoder type being set.
> */
> bool intel_dp_is_edp(struct intel_dp *intel_dp)
IMHO, this comment and WARN_ON like I mentioned above should be a separate
patch since its just a cleanup and no functional change.
Manasi
> {
> @@ -7342,8 +7344,6 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
>intel_dig_port->max_lanes, port_name(port)))
> return false;
>
> - intel_dp_set_source_rates(intel_dp);
> -
> intel_dp->reset_link_params = true;
> intel_dp->pps_pipe = INVALID_PIPE;
> intel_dp->active_pipe = INVALID_PIPE;
> @@ -7388,6 +7388,8 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> port_name(port));
>
> + intel_dp_set_source_rates(intel_dp);
> +
> drm_connector_init(dev, connector, _dp_connector_funcs, type);
> drm_connector_helper_add(connector, _dp_connector_helper_funcs);
>
> --
> 2.17.2
>
___
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: add i2c symlink under hdmi connector (rev3)
== Series Details == Series: drm/i915: add i2c symlink under hdmi connector (rev3) URL : https://patchwork.freedesktop.org/series/60866/ State : success == Summary == CI Bug Log - changes from CI_DRM_6180_full -> Patchwork_13159_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13159_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@forked-big-copy: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#109100]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb4/igt@gem_mmap_...@forked-big-copy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-iclb3/igt@gem_mmap_...@forked-big-copy.html * igt@gem_pwrite@big-cpu-random: - shard-hsw: [PASS][3] -> [INCOMPLETE][4] ([fdo#103540]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-hsw5/igt@gem_pwr...@big-cpu-random.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-hsw2/igt@gem_pwr...@big-cpu-random.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-apl3/igt@gem_workarou...@suspend-resume.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-apl8/igt@gem_workarou...@suspend-resume.html - shard-kbl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103665]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-kbl6/igt@gem_workarou...@suspend-resume.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-kbl2/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_rpm@cursor: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713] / [fdo#108840]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb6/igt@i915_pm_...@cursor.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-iclb2/igt@i915_pm_...@cursor.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-modeset-vs-hang-interruptible: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([fdo#103359] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-glk3/igt@kms_f...@flip-vs-modeset-vs-hang-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-glk2/igt@kms_f...@flip-vs-modeset-vs-hang-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-msflip-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-msflip-blt.html * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108] / [fdo#106978]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-skl4/igt@kms_frontbuffer_track...@psr-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-skl4/igt@kms_frontbuffer_track...@psr-suspend.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb2/igt@kms_psr2...@frontbuffer.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-iclb5/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/shard-iclb5/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-glk:
Re: [Intel-gfx] question about i915 GPU driver in VM
On Sun, Jun 2, 2019 at 6:52 PM Zhang, Xiong Y wrote: > > > Hi, > > > > I'm trying to get iGPU passthrough working in a VM running on a Chrome OS > > "7th Generation (Kaby Lake) Intel Core i5-7Y57 with HD Graphics 615" device. > > I'm able to pass the iGPU through to the VM and execute the i915 driver, but > > the driver doesn't succeed in getting the system to the point where the > > screen works. > > > > With physical access to the iGPU from inside the guest, is it reasonable to > > just run the same kernel/driver that works on the host and expect it to > > work? > > Or are there often extra hoops to jump through even with > > physical/unemulated access to the host GPU and CPU? > [Zhang, Xiong Y] yes, both host and guest use the same kernel/driver. > > > > On a higher level, it would help if anyone had an idea from the logs below > > if > > I'm "close" to getting this to work? Or maybe its hard to say? > [Zhang, Xiong Y] it is close to work. > > > > NOTE: I totally avoid touching the GPU in the host, and have verified that > > the > > i915 driver in the guest should have all the info (e.g. > > OpRegion tables) it needs to drive the GPU. Interestingly, running > > i915 in the VM causes the VM kernel to crash at random code paths unless I > > wait until after system startup to modprobe i915. The VM doesn't crash at > > all > > if I disable i915. These crashes happen well after i915 is done trying to > > initialize the GPU, so not sure if i915 is touching memory it shouldn't be > > or > > what.. > [Zhang, Xiong Y] Please check whether intel_iommu is enabled on host or not. > If it isn't , please add intel_iommu=on to host grub. IOMMUs are enabled and working in the host i.e. localhost ~ # dmesg | grep -i iommu [0.109311] iommu: Adding device :00:00.0 to group 0 [0.109319] iommu: Adding device :00:02.0 to group 1 [0.109327] iommu: Adding device :00:04.0 to group 2 [0.109336] iommu: Adding device :00:08.0 to group 3 [0.109350] iommu: Adding device :00:14.0 to group 4 [0.109357] iommu: Adding device :00:14.2 to group 4 [0.109374] iommu: Adding device :00:15.0 to group 5 [0.109382] iommu: Adding device :00:15.1 to group 5 [0.109389] iommu: Adding device :00:15.2 to group 5 [0.109403] iommu: Adding device :00:19.0 to group 6 [0.109412] iommu: Adding device :00:19.2 to group 6 [0.109429] iommu: Adding device :00:1c.0 to group 7 [0.109446] iommu: Adding device :00:1e.0 to group 8 [0.109455] iommu: Adding device :00:1e.2 to group 8 [0.109464] iommu: Adding device :00:1e.4 to group 8 [0.109487] iommu: Adding device :00:1f.0 to group 9 [0.109496] iommu: Adding device :00:1f.2 to group 9 [0.109505] iommu: Adding device :00:1f.3 to group 9 [0.109514] iommu: Adding device :00:1f.4 to group 9 [0.109523] iommu: Adding device :00:1f.5 to group 9 [0.109542] iommu: Adding device :01:00.0 to group 10 > > is the dmesg from host or guest ? guest > If it is guest, this message shouldn't appear according to your qemu boot > parameter. > > [0.475961] [drm:i915_ggtt_probe_hw] GTT stolen size = 64M > > [0.476927] [drm:i915_gem_init_stolen] Memory reserved for graphics > > device: 65536K, usable: 64512K > Please paste qemu output. Not sure what you mean by the boot parameter or qemu output comments. Do you want to see guest SeaBIOS output or kernel console output? Or messages logged by qemu in the host? > > thanks > > > > Thanks, > > Micah > > > > KERNEL CONSOLE (modified for brevity): > > localhost ~ # qemu-system-x86_64 -serial mon:stdio -m 2G -smp 2 -M pc -vga > > none -usbdevice tablet -cpu host,-invpcid,-tsc-deadline,check -drive > > 'file=/mnt/stateful_partition/chromiumos_test_image.bin,index=0,media=dis > > k,cache=unsafe,format=raw' > > -enable-kvm -device > > vfio-pci,x-igd-opregion=on,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2,ro > > mbar=0 > > -device 'virtio-net,netdev=eth0' -netdev > > 'user,id=eth0,net=10.0.2.0/27,hostfwd=tcp:127.0.0.1:9222-:22' > > qemu-system-x86_64: -usbdevice tablet: '-usbdevice' is deprecated, please > > use '-device usb-...' instead > > qemu-system-x86_64: -device > > vfio-pci,x-igd-opregion=on,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2,ro > > mbar=0: > > IGD device :00:02.0 has no ROM, legacy mode disabled VNC server > > running on 127.0.0.1:5900 > > [0.00] Linux version 4.14.114 > > (mort...@mortonm2.mtv.corp.google.com) (Chromium OS > > 9.0_pre353983_p20190325-r11 clang version 9.0.0 > > (/var/cache/chromeos-cache/distfiles/host/egit-src/clang.git > > 171531e31716e2db2c372cf8b57220ddf9e721d8) > > (/var/cache/chromeos-cache/distfiles/host/egit-src/llvm.git > > 5077597e0d5b86d9f9c27286d8b28f8b3645a74c) (based on LLVM 9.0.0svn)) > > #14 SMP PREEMPT Fri May 31 09:50:35 PDT 2019 > > [0.00] Command line: BOOT_IMAGE=vmlinuz.A init=/sbin/init > > boot=local rootwait ro noresume noswap
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Correctly advertise HBR3 for GEN11+
== Series Details ==
Series: drm/i915/dp: Correctly advertise HBR3 for GEN11+
URL : https://patchwork.freedesktop.org/series/61546/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6182 -> Patchwork_13164
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/
Known issues
Here are the changes found in Patchwork_13164 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-small-copy:
- fi-icl-dsi: [PASS][1] -> [DMESG-WARN][2] ([fdo#106107])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-dsi/igt@gem_mmap_...@basic-small-copy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/fi-icl-dsi/igt@gem_mmap_...@basic-small-copy.html
* igt@gem_mmap_gtt@basic-write:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-u3/igt@gem_mmap_...@basic-write.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/fi-icl-u3/igt@gem_mmap_...@basic-write.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][5] -> [FAIL][6] ([fdo#108511])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([fdo#107709])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bsw-kefka/igt@i915_selftest@live_evict.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/fi-bsw-kefka/igt@i915_selftest@live_evict.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [PASS][9] -> [INCOMPLETE][10] ([fdo#107718])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* {igt@i915_selftest@live_mman}:
- fi-bxt-j4205: [TIMEOUT][11] ([fdo#110818 ]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bxt-j4205/igt@i915_selftest@live_mman.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/fi-bxt-j4205/igt@i915_selftest@live_mman.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][15] ([fdo#103167]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
{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#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109673]: https://bugs.freedesktop.org/show_bug.cgi?id=109673
[fdo#110818 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110818
Participating hosts (50 -> 45)
--
Additional (1): fi-bsw-n3050
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-kbl-7560u
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6182 -> Patchwork_13164
CI_DRM_6182: 63e1cb5d17f931ee65e93fe45d593b45b5c863f5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5029: 5aeacd5cc3fc37ff9e5dccb9e8ae63acdc12e521 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13164: 4a63660fc510da8f3945a4086d6cd340980fe5a9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4a63660fc510 drm/i915/dp: Correctly advertise HBR3 for GEN11+
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13164/
___
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Make the semaphore saturation mask global (rev2)
== Series Details == Series: drm/i915: Make the semaphore saturation mask global (rev2) URL : https://patchwork.freedesktop.org/series/61522/ State : success == Summary == CI Bug Log - changes from CI_DRM_6180_full -> Patchwork_13158_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13158_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@forked-big-copy: - shard-iclb: [PASS][1] -> [TIMEOUT][2] ([fdo#109673]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb4/igt@gem_mmap_...@forked-big-copy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-iclb1/igt@gem_mmap_...@forked-big-copy.html * igt@gem_mmap_gtt@hang: - shard-iclb: [PASS][3] -> [FAIL][4] ([fdo#109677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb6/igt@gem_mmap_...@hang.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-iclb7/igt@gem_mmap_...@hang.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +6 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-apl1/igt@i915_susp...@sysfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-apl7/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#110741]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-skl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_frontbuffer_tracking@fbc-badstride: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb1/igt@kms_frontbuffer_track...@fbc-badstride.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-iclb6/igt@kms_frontbuffer_track...@fbc-badstride.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109642]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb2/igt@kms_psr2...@frontbuffer.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-iclb6/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-iclb6/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@tools_test@tools_test: - shard-glk: [PASS][17] -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-glk6/igt@tools_test@tools_test.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-glk7/igt@tools_test@tools_test.html Possible fixes * igt@gem_eio@unwedge-stress: - shard-snb: [FAIL][19] ([fdo#109661]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-snb6/igt@gem_...@unwedge-stress.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-snb5/igt@gem_...@unwedge-stress.html * igt@i915_pm_rpm@gem-evict-pwrite: - shard-iclb: [INCOMPLETE][21] ([fdo#107713] / [fdo#108840]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb7/igt@i915_pm_...@gem-evict-pwrite.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-iclb2/igt@i915_pm_...@gem-evict-pwrite.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [SKIP][23] ([fdo#109349]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-iclb6/igt@kms_dp_...@basic-dsc-enable-edp.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-skl: [INCOMPLETE][25] ([fdo#104108]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/shard-skl2/igt@kms_fbcon_...@fbc-suspend.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/shard-skl4/igt@kms_fbcon_...@fbc-suspend.html *
[Intel-gfx] [PATCH] drm/i915/dp: Correctly advertise HBR3 for GEN11+
From: Matt Atwood
intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
use before encoder_type is set. This caused GEN11+ to incorrectly strip
HBR3 from source rates. Move intel_dp_set_source_rates() to after
encoder_type is set. Add comment to intel_dp_is_edp() describing unsafe
usages.
Fixes: b265a2a6255f5 ("drm/i915/icl: combo port vswing programming
changes per BSPEC")
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 24b56b2a76c8..a4490bcad684 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -141,6 +141,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
*
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
+ *
+ * This function is not safe to use prior to encoder type being set.
*/
bool intel_dp_is_edp(struct intel_dp *intel_dp)
{
@@ -7342,8 +7344,6 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dig_port->max_lanes, port_name(port)))
return false;
- intel_dp_set_source_rates(intel_dp);
-
intel_dp->reset_link_params = true;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
@@ -7388,6 +7388,8 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
port_name(port));
+ intel_dp_set_source_rates(intel_dp);
+
drm_connector_init(dev, connector, _dp_connector_funcs, type);
drm_connector_helper_add(connector, _dp_connector_helper_funcs);
--
2.17.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: Update MOCS table for EHL
On Sat, Jun 01, 2019 at 06:22:53AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/ehl: Update MOCS table for EHL > URL : https://patchwork.freedesktop.org/series/61409/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_6171_full -> Patchwork_13142_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_13142_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_13142_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_13142_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_cursor_crc@pipe-b-cursor-suspend: > - shard-snb: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6171/shard-snb1/igt@kms_cursor_...@pipe-b-cursor-suspend.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13142/shard-snb4/igt@kms_cursor_...@pipe-b-cursor-suspend.html > This seems to be unrelated; some kind of problem reading and then writing to MSR_IA32_ENERGY_PERF_BIAS in the general x86 cpu code during system resume: <4> [748.616267] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0x8103391f (intel_epb_restore+0xf/0xa0) <4> [748.616269] Call Trace: <4> [748.616274] syscore_resume+0x5b/0x290 <4> [748.616278] suspend_devices_and_enter+0x977/0xbb0 <4> [748.616285] pm_suspend+0x3e1/0x870 <4> [748.616290] state_store+0x78/0xe0 <4> [748.616296] kernfs_fop_write+0x104/0x190 <4> [748.616302] vfs_write+0xbd/0x1b0 <4> [748.616306] ksys_write+0x8f/0xe0 <4> [748.616311] do_syscall_64+0x55/0x1c0 <4> [748.616315] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [748.616318] RIP: 0033:0x7f15ac65c154 <4> [748.616321] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 b1 07 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 <4> [748.616323] RSP: 002b:7ffcf5447988 EFLAGS: 0246 ORIG_RAX: 0001 <4> [748.616325] RAX: ffda RBX: 0004 RCX: 7f15ac65c154 <4> [748.616327] RDX: 0004 RSI: 564540e265b0 RDI: 000d <4> [748.616328] RBP: 564540e265b0 R08: 564540e235e0 R09: 7f15acb4a540 <4> [748.616330] R10: 564540e21010 R11: 0246 R12: 564540e23500 <4> [748.616332] R13: 0004 R14: 7f15ac9342a0 R15: 7f15ac933760 <4> [748.616344] unchecked MSR access error: WRMSR to 0x1b0 (tried to write 0x0006) at rIP: 0x81033953 (intel_epb_restore+0x43/0xa0) <4> [748.616345] Call Trace: <4> [748.616348] syscore_resume+0x5b/0x290 <4> [748.616351] suspend_devices_and_enter+0x977/0xbb0 <4> [748.616358] pm_suspend+0x3e1/0x870 <4> [748.616363] state_store+0x78/0xe0 <4> [748.616367] kernfs_fop_write+0x104/0x190 <4> [748.616372] vfs_write+0xbd/0x1b0 <4> [748.616376] ksys_write+0x8f/0xe0 <4> [748.616381] do_syscall_64+0x55/0x1c0 <4> [748.616384] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [748.616385] RIP: 0033:0x7f15ac65c154 <4> [748.616387] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 b1 07 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 <4> [748.616389] RSP: 002b:7ffcf5447988 EFLAGS: 0246 ORIG_RAX: 0001 <4> [748.616391] RAX: ffda RBX: 0004 RCX: 7f15ac65c154 <4> [748.616393] RDX: 0004 RSI: 564540e265b0 RDI: 000d <4> [748.616394] RBP: 564540e265b0 R08: 564540e235e0 R09: 7f15acb4a540 <4> [748.616396] R10: 564540e21010 R11: 0246 R12: 564540e23500 <4> [748.616397] R13: 0004 R14: 7f15ac9342a0 R15: 7f15ac933760 This patch only changes gen11 MOCS table, so it shouldn't have any impact on a SNB system. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: fix whitelist on Gen10+
On Saturday, June 1, 2019 3:58:45 PM PDT Lionel Landwerlin wrote:
> Gen10 added an additional NOA_WRITE register (high bits) and we forgot
> to whitelist it for userspace.
>
> Fixes: 95690a02fb5d96 ("drm/i915/perf: enable perf support on CNL")
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/i915_perf.c | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 2 insertions(+)
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/7] drm/i915: prefer i915_runtime_pm in intel_runtime function
On Fri, 31 May 2019, Daniele Ceraolo Spurio
wrote:
> On 5/21/19 1:45 AM, Jani Nikula wrote:
>> On Thu, 16 May 2019, Daniele Ceraolo Spurio
>> wrote:
>>> As a first step towards updating the code to work on the runtime_pm
>>> structure instead of i915, rework all the internals to use and pass
>>> around that.
>>>
>>> Signed-off-by: Daniele Ceraolo Spurio
>>> ---
>>> drivers/gpu/drm/i915/i915_drv.h | 2 +
>>> drivers/gpu/drm/i915/intel_drv.h| 10 +-
>>> drivers/gpu/drm/i915/intel_runtime_pm.c | 152
>>> 3 files changed, 82 insertions(+), 82 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index 5801f5407589..474074c7f395 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -1177,6 +1177,8 @@ struct skl_wm_params {
>>>*/
>>> struct i915_runtime_pm {
>>> atomic_t wakeref_count;
>>> + struct device *kdev;
>>
>> This could use a small comment to say what device this is.
>>
>
> Would something like:
>
> /* the intel gpu we're loaded on */
I meant more literally something like "set to
i915->drm->pdev->dev". (With . instead of -> in some places...)
BR,
Jani.
> work? Or should I just rename it to i915_kdev like we use in other parts
> of the driver?
>
> Thanks,
> Daniele
>
>> BR,
>> Jani.
>>
>>> + bool available;
>>> bool suspended;
>>> bool irqs_enabled;
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index 30b2d6ed2d53..bd04f394fbd3 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -1662,13 +1662,17 @@ assert_rpm_wakelock_held(struct i915_runtime_pm
>>> *rpm, int wakeref_count)
>>> }
>>>
>>> static inline void
>>> -assert_rpm_raw_wakeref_held(struct drm_i915_private *i915)
>>> +__assert_rpm_raw_wakeref_held(struct i915_runtime_pm *rpm)
>>> {
>>> - struct i915_runtime_pm *rpm = >runtime_pm;
>>> -
>>> assert_rpm_raw_wakeref_held(rpm, atomic_read(>wakeref_count));
>>> }
>>>
>>> +static inline void
>>> +assert_rpm_raw_wakeref_held(struct drm_i915_private *i915)
>>> +{
>>> + __assert_rpm_raw_wakeref_held(>runtime_pm);
>>> +}
>>> +
>>> static inline void
>>> __assert_rpm_wakelock_held(struct i915_runtime_pm *rpm)
>>> {
>>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>>> index b4abababdf6c..2e21f562df44 100644
>>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>>> @@ -60,19 +60,19 @@
>>>* present for a given platform.
>>>*/
>>>
>>> -static intel_wakeref_t intel_runtime_pm_get_raw(struct drm_i915_private
>>> *i915);
>>> +static intel_wakeref_t intel_runtime_pm_get_raw(struct i915_runtime_pm
>>> *rpm);
>>> static void
>>> -__intel_runtime_pm_put(struct drm_i915_private *i915, intel_wakeref_t wref,
>>> +__intel_runtime_pm_put(struct i915_runtime_pm *rpm, intel_wakeref_t wref,
>>>bool wakelock);
>>>
>>> #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
>>> static void
>>> -intel_runtime_pm_put_raw(struct drm_i915_private *i915, intel_wakeref_t
>>> wref);
>>> +intel_runtime_pm_put_raw(struct i915_runtime_pm *rpm, intel_wakeref_t
>>> wref);
>>> #else
>>> -static inline void intel_runtime_pm_put_raw(struct drm_i915_private *i915,
>>> +static inline void intel_runtime_pm_put_raw(struct i915_runtime_pm *rpm,
>>> intel_wakeref_t wref)
>>> {
>>> - __intel_runtime_pm_put(i915, -1, false);
>>> + __intel_runtime_pm_put(rpm, -1, false);
>>> }
>>> #endif
>>>
>>> @@ -112,21 +112,18 @@ static void __print_depot_stack(depot_stack_handle_t
>>> stack,
>>> snprint_stack_trace(buf, sz, , indent);
>>> }
>>>
>>> -static void init_intel_runtime_pm_wakeref(struct drm_i915_private *i915)
>>> +static void init_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm)
>>> {
>>> - struct i915_runtime_pm *rpm = >runtime_pm;
>>> -
>>> spin_lock_init(>debug.lock);
>>> }
>>>
>>> static noinline depot_stack_handle_t
>>> -track_intel_runtime_pm_wakeref(struct drm_i915_private *i915)
>>> +track_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm)
>>> {
>>> - struct i915_runtime_pm *rpm = >runtime_pm;
>>> depot_stack_handle_t stack, *stacks;
>>> unsigned long flags;
>>>
>>> - if (!HAS_RUNTIME_PM(i915))
>>> + if (!rpm->available)
>>> return -1;
>>>
>>> stack = __save_depot_stack();
>>> @@ -153,10 +150,9 @@ track_intel_runtime_pm_wakeref(struct drm_i915_private
>>> *i915)
>>> return stack;
>>> }
>>>
>>> -static void untrack_intel_runtime_pm_wakeref(struct drm_i915_private *i915,
>>> +static void untrack_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm,
>>> depot_stack_handle_t stack)
>>> {
>>> - struct
Re: [Intel-gfx] [PATCH 0/2] split out intel_display_power
On Sat, 01 Jun 2019, Chris Wilson wrote: > Quoting Daniele Ceraolo Spurio (2019-05-31 23:24:07) >> Separate the display PM from the PCI-level runtime PM. >> I'll follow this up with v2 of the rpm encapsulation series [1], but >> I'd like to get this in before that to avoid having to carry this >> big dumb diff in that series. > > With RUNTIME_PM_DEBUG disabled, > > add/remove: 3/1 grow/shrink: 6/8 up/down: 396/-393 (3) > Function old new delta > intel_runtime_pm_release - 274+274 > intel_runtime_pm_put_raw - 45 +45 > intel_runtime_pm_put_unchecked10 48 +38 > intel_display_power_put_async_work 179 192 +13 > intel_display_power_flush_work 117 126 +9 > __intel_display_power_put_async 193 199 +6 > intel_runtime_pm_get_raw - 4 +4 > intel_display_power_grab_async_put_ref 117 121 +4 > __warned 469 472 +3 > intel_runtime_pm_get 10 7 -3 > intel_power_domains_enable38 33 -5 > intel_display_power_put_unchecked 23 18 -5 > intel_display_power_get_if_enabled 143 138 -5 > intel_display_power_get 84 79 -5 > intel_power_domains_suspend 490 480 -10 > intel_power_domains_fini_hw 116 106 -10 > release_async_put_domains220 203 -17 > __intel_runtime_pm_put.constprop 333 --333 > Total: Before=23394388, After=23394391, chg +0.00% > > which is my biggest worry when meddling with these, that we accidentally > explode production code with unused debugging (all those wakerefs). > > Lgtm, I would like Jani to indicate that he's happy with this split as > well since he has been looking at very similar ideas. I might bikeshed the naming, from the POV that functions would be nice to be (eventually) named based on the name of the file they reside in. But I guess intel_display_power.[ch] is as good as any I could come up with, and not everything is going to follow the naming pattern anyway. I'd still like to get an ack from Imre before merging, but from my side this is, Acked-by: Jani Nikula Thanks for doing this. > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915: Combine unbound/bound list tracking for objects
== Series Details == Series: series starting with [1/7] drm/i915: Combine unbound/bound list tracking for objects URL : https://patchwork.freedesktop.org/series/61537/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6182 -> Patchwork_13163 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13163 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13163, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13163: ### IGT changes ### Possible regressions * igt@core_auth@basic-auth: - fi-blb-e6850: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-blb-e6850/igt@core_a...@basic-auth.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-blb-e6850/igt@core_a...@basic-auth.html * igt@gem_close_race@basic-threads: - fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bsw-kefka/igt@gem_close_r...@basic-threads.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-bsw-kefka/igt@gem_close_r...@basic-threads.html * igt@gem_ctx_create@basic-files: - fi-hsw-peppy: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-hsw-peppy/igt@gem_ctx_cre...@basic-files.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-hsw-peppy/igt@gem_ctx_cre...@basic-files.html * igt@gem_exec_fence@basic-await-default: - fi-snb-2520m: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-snb-2520m/igt@gem_exec_fe...@basic-await-default.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-snb-2520m/igt@gem_exec_fe...@basic-await-default.html * igt@gem_exec_fence@basic-busy-default: - fi-skl-gvtdvm: [PASS][9] -> [TIMEOUT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-skl-gvtdvm/igt@gem_exec_fe...@basic-busy-default.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-skl-gvtdvm/igt@gem_exec_fe...@basic-busy-default.html * igt@gem_exec_reloc@basic-cpu-gtt: - fi-bsw-n3050: NOTRUN -> [DMESG-FAIL][11] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-bsw-n3050/igt@gem_exec_re...@basic-cpu-gtt.html * igt@gem_exec_reloc@basic-gtt-noreloc: - fi-bwr-2160:[PASS][12] -> [FAIL][13] +7 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bwr-2160/igt@gem_exec_re...@basic-gtt-noreloc.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-bwr-2160/igt@gem_exec_re...@basic-gtt-noreloc.html * igt@gem_exec_suspend@basic-s3: - fi-elk-e7500: [PASS][14] -> [FAIL][15] +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-elk-e7500/igt@gem_exec_susp...@basic-s3.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-elk-e7500/igt@gem_exec_susp...@basic-s3.html * igt@gem_sync@basic-all: - fi-bsw-n3050: NOTRUN -> [FAIL][16] +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-bsw-n3050/igt@gem_s...@basic-all.html * igt@i915_selftest@live_gem: - fi-gdg-551: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-gdg-551/igt@i915_selftest@live_gem.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-gdg-551/igt@i915_selftest@live_gem.html * igt@i915_selftest@live_gtt: - fi-bwr-2160:[PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bwr-2160/igt@i915_selftest@live_gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-bwr-2160/igt@i915_selftest@live_gtt.html - fi-kbl-8809g: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-kbl-8809g/igt@i915_selftest@live_gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-kbl-8809g/igt@i915_selftest@live_gtt.html - fi-bdw-gvtdvm: [PASS][23] -> [INCOMPLETE][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bdw-gvtdvm/igt@i915_selftest@live_gtt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13163/fi-bdw-gvtdvm/igt@i915_selftest@live_gtt.html - fi-kbl-r: [PASS][25] -> [INCOMPLETE][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-kbl-r/igt@i915_selftest@live_gtt.html [26]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915: Combine unbound/bound list tracking for objects
== Series Details == Series: series starting with [1/7] drm/i915: Combine unbound/bound list tracking for objects URL : https://patchwork.freedesktop.org/series/61537/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Combine unbound/bound list tracking for objects -./include/linux/mm.h:652:13: error: undefined identifier '__builtin_mul_overflow' -./include/linux/mm.h:652:13: warning: call with no type! Commit: drm/i915: Propagate fence errors Okay! Commit: drm/i915: Allow page pinning to be in the background Okay! Commit: drm/i915/gtt: Replace struct_mutex serialisation for allocation -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1372:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1372:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1409:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1409:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1460:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1460:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1389:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1389:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1437:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1437:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1507:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1507:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1759:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1759:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1826:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1826:9: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:3538:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:3538:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:3538:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:3538:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:848:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:848:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:890:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:890:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:939:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:939:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:842:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:842:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:892:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:892:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:948:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:948:9: warning: expression using sizeof(void) Commit: drm/i915: Pull kref into i915_address_space -O:drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1265:41: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1265:41: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1261:38: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1261:38: warning: expression using sizeof(void) Commit: drm/i915: Rename i915_hw_ppgtt to i915_ppgtt Okay! Commit: drm/i915: Allow vma binding to occur asynchronously -drivers/gpu/drm/i915/i915_gem_gtt.c:355:14: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:355:14: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:355:14: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:355:14: warning: expression using sizeof(void) +./include/linux/reservation.h:220:20: warning: dereference of noderef expression +./include/linux/reservation.h:220:45: warning: dereference of noderef expression ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow vma binding to occur asynchronously
Quoting Chris Wilson (2019-06-03 18:49:35) > If we let pages be allocated asynchronously, we also then want to push > the binding process into an asynchronous task. Make it so, utilising the > recent improvements to fence error tracking and struct_mutex reduction. Caveat emptor. Definitely missing something here, so more eyes the merrier. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/22] gpu: i915.rst: Fix references to renamed files
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with
return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical
Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c'
failed with return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/gpu/i915.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 055df45596c1..38fefeb99bba 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
Workarounds
---
-.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/selftest_workarounds.c
:doc: Hardware workarounds
Display Hardware Handling
@@ -379,10 +379,10 @@ User Batchbuffer Execution
Logical Rings, Logical Ring Contexts and Execlists
--
-.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
:doc: Logical Rings, Logical Ring Contexts and Execlists
-.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
:internal:
Global GTT views
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915: Combine unbound/bound list tracking for objects
== Series Details == Series: series starting with [1/7] drm/i915: Combine unbound/bound list tracking for objects URL : https://patchwork.freedesktop.org/series/61537/ State : warning == Summary == $ dim checkpatch origin/drm-tip df5d9cb2c640 drm/i915: Combine unbound/bound list tracking for objects -:167: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #167: FILE: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:396: + available = unevictable = 0; total: 0 errors, 0 warnings, 1 checks, 554 lines checked 3fb949471c05 drm/i915: Propagate fence errors 4f547153696c drm/i915: Allow page pinning to be in the background 85b352e0e15f drm/i915/gtt: Replace struct_mutex serialisation for allocation -:495: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #495: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:259: + spinlock_t lock; -:503: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #503: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:266: + spinlock_t lock; -:509: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #509: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:272: + spinlock_t lock; total: 0 errors, 0 warnings, 3 checks, 463 lines checked 676075f6caa4 drm/i915: Pull kref into i915_address_space f815e434b98f drm/i915: Rename i915_hw_ppgtt to i915_ppgtt -:548: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'base' - possible side-effects? #548: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:438: +#define __to_gen6_ppgtt(base) container_of(base, struct gen6_ppgtt, base) total: 0 errors, 0 warnings, 1 checks, 553 lines checked 4f66be6165f6 drm/i915: Allow vma binding to occur asynchronously ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Rename i915_hw_ppgtt to i915_ppgtt
Keeping the _hw_ in there does not help to distinguish it from its
brethren i915_ggtt, so drop it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 12 +--
.../gpu/drm/i915/gem/selftests/mock_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +-
drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 5 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 78 +--
drivers/gpu/drm/i915/i915_gem_gtt.h | 28 +++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 6 +-
drivers/gpu/drm/i915/selftests/mock_gtt.c | 7 +-
drivers/gpu/drm/i915/selftests/mock_gtt.h | 4 +-
12 files changed, 78 insertions(+), 84 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 2ec31b99ec82..fb9a09b78e02 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -496,7 +496,7 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
unsigned int flags)
return ctx;
if (HAS_FULL_PPGTT(dev_priv)) {
- struct i915_hw_ppgtt *ppgtt;
+ struct i915_ppgtt *ppgtt;
ppgtt = i915_ppgtt_create(dev_priv);
if (IS_ERR(ppgtt)) {
@@ -805,7 +805,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_vm_control *args = data;
struct drm_i915_file_private *file_priv = file->driver_priv;
- struct i915_hw_ppgtt *ppgtt;
+ struct i915_ppgtt *ppgtt;
int err;
if (!HAS_FULL_PPGTT(i915))
@@ -1020,7 +1020,7 @@ static int emit_ppgtt_update(struct i915_request *rq,
void *data)
int i;
if (i915_vm_is_4lvl(vm)) {
- struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+ struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
const dma_addr_t pd_daddr = px_dma(>pml4);
cs = intel_ring_begin(rq, 6);
@@ -1037,7 +1037,7 @@ static int emit_ppgtt_update(struct i915_request *rq,
void *data)
*cs++ = MI_NOOP;
intel_ring_advance(rq, cs);
} else if (HAS_LOGICAL_RING_CONTEXTS(engine->i915)) {
- struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+ struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
cs = intel_ring_begin(rq, 4 * GEN8_3LVL_PDPES + 2);
if (IS_ERR(cs))
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 232d5cf4396c..73e667b31cc4 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -368,7 +368,7 @@ static int igt_check_page_sizes(struct i915_vma *vma)
static int igt_mock_exhaust_device_supported_pages(void *arg)
{
- struct i915_hw_ppgtt *ppgtt = arg;
+ struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
unsigned int saved_mask = INTEL_INFO(i915)->page_sizes;
struct drm_i915_gem_object *obj;
@@ -447,7 +447,7 @@ static int igt_mock_exhaust_device_supported_pages(void
*arg)
static int igt_mock_ppgtt_misaligned_dma(void *arg)
{
- struct i915_hw_ppgtt *ppgtt = arg;
+ struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
unsigned long supported = INTEL_INFO(i915)->page_sizes;
struct drm_i915_gem_object *obj;
@@ -575,7 +575,7 @@ static int igt_mock_ppgtt_misaligned_dma(void *arg)
}
static void close_object_list(struct list_head *objects,
- struct i915_hw_ppgtt *ppgtt)
+ struct i915_ppgtt *ppgtt)
{
struct drm_i915_gem_object *obj, *on;
@@ -595,7 +595,7 @@ static void close_object_list(struct list_head *objects,
static int igt_mock_ppgtt_huge_fill(void *arg)
{
- struct i915_hw_ppgtt *ppgtt = arg;
+ struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
unsigned long max_pages = ppgtt->vm.total >> PAGE_SHIFT;
unsigned long page_num;
@@ -716,7 +716,7 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
static int igt_mock_ppgtt_64K(void *arg)
{
- struct i915_hw_ppgtt *ppgtt = arg;
+ struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
struct drm_i915_gem_object *obj;
const struct object_info {
@@ -1683,7 +1683,7 @@ int i915_gem_huge_page_mock_selftests(void)
SUBTEST(igt_mock_ppgtt_64K),
};
struct drm_i915_private *dev_priv;
- struct i915_hw_ppgtt *ppgtt;
+ struct i915_ppgtt *ppgtt;
int err;
dev_priv =
[Intel-gfx] [PATCH 7/7] drm/i915: Allow vma binding to occur asynchronously
If we let pages be allocated asynchronously, we also then want to push
the binding process into an asynchronous task. Make it so, utilising the
recent improvements to fence error tracking and struct_mutex reduction.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 14 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 4 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 29 ++-
drivers/gpu/drm/i915/i915_vma.c | 170 +++---
drivers/gpu/drm/i915/i915_vma.h | 9 +
drivers/gpu/drm/i915/selftests/i915_vma.c | 4 +-
6 files changed, 191 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6513ee4bcedb..6f188166f4a6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -580,6 +580,15 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
u64 pin_flags;
int err;
+ /*
+* If we load the pages asynchronously, then the user *must*
+* obey the reservation_object and not bypass waiting on it.
+* On the positive side, if the vma is not yet bound (no pages!),
+* then it should not have any annoying implicit fences.
+*/
+ if (exec_flags & EXEC_OBJECT_ASYNC && !vma->pages)
+ *vma->exec_flags &= ~EXEC_OBJECT_ASYNC;
+
pin_flags = PIN_USER | PIN_NONBLOCK;
if (exec_flags & EXEC_OBJECT_NEEDS_GTT)
pin_flags |= PIN_GLOBAL;
@@ -1236,8 +1245,9 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
goto skip_request;
i915_vma_lock(batch);
- GEM_BUG_ON(!reservation_object_test_signaled_rcu(batch->resv, true));
- err = i915_vma_move_to_active(batch, rq, 0);
+ err = i915_request_await_object(rq, batch->obj, false);
+ if (err == 0)
+ err = i915_vma_move_to_active(batch, rq, 0);
i915_vma_unlock(batch);
if (err)
goto skip_request;
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 25a7eb12d339..d1123dfbfb0e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -295,6 +295,10 @@ static int gpu_fill(struct drm_i915_gem_object *obj,
goto err_batch;
}
+ err = i915_request_await_object(rq, batch->obj, false);
+ if (err)
+ goto err_request;
+
flags = 0;
if (INTEL_GEN(vm->i915) <= 5)
flags |= I915_DISPATCH_SECURE;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2765f3848cb1..d50da5dbf4fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
@@ -135,14 +136,14 @@ static inline void i915_ggtt_invalidate(struct
drm_i915_private *i915)
static int ppgtt_bind_vma(struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
+ struct i915_address_space *vm = vma->vm;
u32 pte_flags;
int err;
- if (!(vma->flags & I915_VMA_LOCAL_BIND)) {
- err = vma->vm->allocate_va_range(vma->vm,
-vma->node.start, vma->size);
+ if (flags & I915_VMA_ALLOC_BIND) {
+ err = vm->allocate_va_range(vm, vma->node.start, vma->size);
if (err)
return err;
}
@@ -152,20 +153,26 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
if (i915_gem_object_is_readonly(vma->obj))
pte_flags |= PTE_READ_ONLY;
- vma->vm->insert_entries(vma->vm, vma, cache_level, pte_flags);
+ vm->insert_entries(vm, vma, cache_level, pte_flags);
return 0;
}
static void ppgtt_unbind_vma(struct i915_vma *vma)
{
- vma->vm->clear_range(vma->vm, vma->node.start, vma->size);
+ struct i915_address_space *vm = vma->vm;
+
+ vm->clear_range(vm, vma->node.start, vma->size);
}
static int ppgtt_set_pages(struct i915_vma *vma)
{
GEM_BUG_ON(vma->pages);
+ wait_for_completion(>obj->mm.completion);
+ if (IS_ERR(vma->obj->mm.pages))
+ return PTR_ERR(vma->obj->mm.pages);
+
vma->pages = vma->obj->mm.pages;
vma->page_sizes = vma->obj->mm.page_sizes;
@@ -2686,6 +2693,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
* upgrade to both bound if we bind either to avoid double-binding.
*/
vma->flags |= I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND;
+ dma_fence_signal(vma->async.dma);
return 0;
}
@@ -2715,7 +2723,7 @@ static int aliasing_gtt_bind_vma(struct
[Intel-gfx] [PATCH 5/7] drm/i915: Pull kref into i915_address_space
Make the kref common to both derived structs (i915_ggtt and i915_ppgtt)
so that we can safely reference count an abstract ctx->vm address space.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 132 +-
.../gpu/drm/i915/gem/i915_gem_context_types.h | 6 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 6 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_context.c | 36 +++--
.../gpu/drm/i915/gem/selftests/mock_context.c | 3 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +-
drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 26 ++--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 7 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 10 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 8 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 6 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 35 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 27 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 10 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 3 +-
drivers/gpu/drm/i915/selftests/i915_vma.c | 4 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 5 +-
drivers/gpu/drm/i915/selftests/mock_gtt.c | 1 -
26 files changed, 188 insertions(+), 192 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 4899ca1dd76c..f253ec5765ad 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -250,13 +250,11 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_gem_context *ctx = ce->gem_context;
- struct i915_address_space *vm;
+ struct i915_address_space *vm = ctx->vm ?: >ggtt.vm;
struct clear_pages_work *work;
struct i915_sleeve *sleeve;
int err;
- vm = ctx->ppgtt ? >ppgtt->vm : >ggtt.vm;
-
sleeve = create_sleeve(vm, obj, pages, page_sizes);
if (IS_ERR(sleeve))
return PTR_ERR(sleeve);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 08721ef62e4e..2ec31b99ec82 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -294,7 +294,8 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
release_hw_id(ctx);
- i915_ppgtt_put(ctx->ppgtt);
+ if (ctx->vm)
+ i915_vm_put(ctx->vm);
free_engines(rcu_access_pointer(ctx->engines));
mutex_destroy(>engines_mutex);
@@ -379,7 +380,7 @@ static void context_close(struct i915_gem_context *ctx)
}
static u32 default_desc_template(const struct drm_i915_private *i915,
-const struct i915_hw_ppgtt *ppgtt)
+const struct i915_address_space *vm)
{
u32 address_mode;
u32 desc;
@@ -387,7 +388,7 @@ static u32 default_desc_template(const struct
drm_i915_private *i915,
desc = GEN8_CTX_VALID | GEN8_CTX_PRIVILEGE;
address_mode = INTEL_LEGACY_32B_CONTEXT;
- if (ppgtt && i915_vm_is_4lvl(>vm))
+ if (vm && i915_vm_is_4lvl(vm))
address_mode = INTEL_LEGACY_64B_CONTEXT;
desc |= address_mode << GEN8_CTX_ADDRESSING_MODE_SHIFT;
@@ -403,7 +404,7 @@ static u32 default_desc_template(const struct
drm_i915_private *i915,
}
static struct i915_gem_context *
-__create_context(struct drm_i915_private *dev_priv)
+__create_context(struct drm_i915_private *i915)
{
struct i915_gem_context *ctx;
struct i915_gem_engines *e;
@@ -415,8 +416,8 @@ __create_context(struct drm_i915_private *dev_priv)
return ERR_PTR(-ENOMEM);
kref_init(>ref);
- list_add_tail(>link, _priv->contexts.list);
- ctx->i915 = dev_priv;
+ list_add_tail(>link, >contexts.list);
+ ctx->i915 = i915;
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
mutex_init(>mutex);
@@ -435,14 +436,14 @@ __create_context(struct drm_i915_private *dev_priv)
/* 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. */
- ctx->remap_slice = ALL_L3_SLICES(dev_priv);
+ ctx->remap_slice = ALL_L3_SLICES(i915);
[Intel-gfx] [PATCH 3/7] drm/i915: Allow page pinning to be in the background
Assume that pages may be pinned in a background task and use a
completion event to synchronise with callers that must access the pages
immediately.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h| 7 +--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 ++
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 53 +++
4 files changed, 52 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 2702e060102e..2c5a02274170 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -79,6 +79,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
obj->mm.madv = I915_MADV_WILLNEED;
INIT_RADIX_TREE(>mm.get_page.radix, GFP_KERNEL | __GFP_NOWARN);
mutex_init(>mm.get_page.lock);
+ init_completion(>mm.completion);
}
/**
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7cb1871d7128..194e4fb6a259 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -240,7 +240,7 @@ int i915_gem_object_get_pages(struct
drm_i915_gem_object *obj);
int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
static inline int __must_check
-i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+i915_gem_object_pin_pages_async(struct drm_i915_gem_object *obj)
{
might_lock(>mm.lock);
@@ -250,6 +250,9 @@ i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
return __i915_gem_object_get_pages(obj);
}
+int __must_check
+i915_gem_object_pin_pages(struct drm_i915_gem_object *obj);
+
static inline bool
i915_gem_object_has_pages(struct drm_i915_gem_object *obj)
{
@@ -273,9 +276,7 @@ i915_gem_object_has_pinned_pages(struct drm_i915_gem_object
*obj)
static inline void
__i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
{
- GEM_BUG_ON(!i915_gem_object_has_pages(obj));
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
-
atomic_dec(>mm.pages_pin_count);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 41d2e7c8e332..615a59b927d6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -7,6 +7,7 @@
#ifndef __I915_GEM_OBJECT_TYPES_H__
#define __I915_GEM_OBJECT_TYPES_H__
+#include
#include
#include
@@ -211,6 +212,8 @@ struct drm_i915_gem_object {
*/
struct list_head link;
+ struct completion completion;
+
/**
* Advice: are the backing pages purgeable?
*/
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 7868dd48d931..68262231f56f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -72,21 +72,18 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
*obj,
spin_unlock(>mm.obj_lock);
}
+
+ complete_all(>mm.completion);
}
int i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
{
- int err;
-
if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
DRM_DEBUG("Attempting to obtain a purgeable object\n");
return -EFAULT;
}
- err = obj->ops->get_pages(obj);
- GEM_BUG_ON(!err && !i915_gem_object_has_pages(obj));
-
- return err;
+ return obj->ops->get_pages(obj);
}
/* Ensure that the associated pages are gathered from the backing storage
@@ -104,7 +101,7 @@ int __i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
if (err)
return err;
- if (unlikely(!i915_gem_object_has_pages(obj))) {
+ if (!obj->mm.pages) {
GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
err = i915_gem_object_get_pages(obj);
@@ -120,6 +117,32 @@ int __i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
return err;
}
+int i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
+{
+ int err;
+
+ err = i915_gem_object_pin_pages_async(obj);
+ if (err)
+ return err;
+
+ err = wait_for_completion_interruptible(>mm.completion);
+ if (err)
+ goto err_unpin;
+
+ if (IS_ERR(obj->mm.pages)) {
+ err = PTR_ERR(obj->mm.pages);
+ goto err_unpin;
+ }
+
+ GEM_BUG_ON(!i915_gem_object_has_pages(obj));
+ return 0;
+
+err_unpin:
+ GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
+ atomic_dec(>mm.pages_pin_count);
+ return err;
+}
+
/* Immediately discard the backing storage */
void i915_gem_object_truncate(struct
[Intel-gfx] [PATCH 1/7] drm/i915: Combine unbound/bound list tracking for objects
With async binding, we don't want to manage a bound/unbound list as we
may end up running before we even acquire the pages. All that is
required is keeping track of shrinkable objects, so reduce it to the
minimum list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 12 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 13 +-
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 3 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 30 ++-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 189 +-
drivers/gpu/drm/i915/i915_drv.h | 14 +-
drivers/gpu/drm/i915/i915_gem.c | 22 +-
drivers/gpu/drm/i915/i915_vma.c | 30 +--
.../gpu/drm/i915/selftests/i915_gem_evict.c | 16 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
13 files changed, 67 insertions(+), 272 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index e5deae62681f..6115109a2810 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -219,7 +219,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
* rewrite the PTE in the belief that doing so tramples upon less
* state and so involves less work.
*/
- if (obj->bind_count) {
+ if (atomic_read(>bind_count)) {
/* Before we change the PTE, the GPU must not be accessing it.
* If we wait upon the object, we know that all the bound
* VMA are no longer active.
@@ -475,14 +475,10 @@ static void i915_gem_object_bump_inactive_ggtt(struct
drm_i915_gem_object *obj)
}
mutex_unlock(>ggtt.vm.mutex);
- if (i915_gem_object_is_shrinkable(obj) &&
- obj->mm.madv == I915_MADV_WILLNEED) {
- struct list_head *list;
-
+ if (i915_gem_object_is_shrinkable(obj)) {
spin_lock(>mm.obj_lock);
- list = obj->bind_count ?
- >mm.bound_list : >mm.unbound_list;
- list_move_tail(>mm.link, list);
+ if (obj->mm.madv == I915_MADV_WILLNEED)
+ list_move_tail(>mm.link, >mm.shrink_list);
spin_unlock(>mm.obj_lock);
}
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index b840cf179bbe..2702e060102e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -206,7 +206,7 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
mutex_unlock(>drm.struct_mutex);
- GEM_BUG_ON(obj->bind_count);
+ GEM_BUG_ON(atomic_read(>bind_count));
GEM_BUG_ON(obj->userfault_count);
GEM_BUG_ON(atomic_read(>frontbuffer_bits));
GEM_BUG_ON(!list_empty(>lut_list));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 67a992d6ee0c..41d2e7c8e332 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -156,7 +156,7 @@ struct drm_i915_gem_object {
#define STRIDE_MASK (~TILING_MASK)
/** Count of VMA actually bound by this object */
- unsigned int bind_count;
+ atomic_t bind_count;
unsigned int active_count;
/** Count of how many global VMA are currently pinned for use by HW */
unsigned int pin_global;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 7e64fd6bc19b..7868dd48d931 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -57,10 +57,19 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
*obj,
GEM_BUG_ON(!HAS_PAGE_SIZES(i915, obj->mm.page_sizes.sg));
if (i915_gem_object_is_shrinkable(obj)) {
+ struct list_head *list;
+
spin_lock(>mm.obj_lock);
+
i915->mm.shrink_count++;
i915->mm.shrink_memory += obj->base.size;
- list_add(>mm.link, >mm.unbound_list);
+
+ if (obj->mm.madv != I915_MADV_WILLNEED)
+ list = >mm.purge_list;
+ else
+ list = >mm.shrink_list;
+ list_add_tail(>mm.link, list);
+
spin_unlock(>mm.obj_lock);
}
}
@@ -185,7 +194,7 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object
*obj,
if (i915_gem_object_has_pinned_pages(obj))
return -EBUSY;
- GEM_BUG_ON(obj->bind_count);
+ GEM_BUG_ON(atomic_read(>bind_count));
/* May be called by
[Intel-gfx] [PATCH 2/7] drm/i915: Propagate fence errors
Errors spread like wildfire, and must eventually be returned to the
user. They need to be captured and passed along the flow of fences,
infecting each in turn with the existing error, until finally they fall
out of a user visible result.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 8 +++
drivers/gpu/drm/i915/i915_sw_fence.c | 23 +++
drivers/gpu/drm/i915/i915_sw_fence.h | 7 ++
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 1 +
4 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index da1e6984a8cc..ac834b3878b3 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -568,6 +568,10 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
switch (state) {
case FENCE_COMPLETE:
trace_i915_request_submit(request);
+
+ if (unlikely(fence->error))
+ i915_request_skip(request, fence->error);
+
/*
* We need to serialize use of the submit_request() callback
* with its hotplugging performed during an emergency
@@ -1117,6 +1121,9 @@ void i915_request_skip(struct i915_request *rq, int error)
GEM_BUG_ON(!IS_ERR_VALUE((long)error));
dma_fence_set_error(>fence, error);
+ if (rq->infix == rq->postfix)
+ return;
+
/*
* As this request likely depends on state from the lost
* context, clear out all the user operations leaving the
@@ -1128,6 +1135,7 @@ void i915_request_skip(struct i915_request *rq, int error)
head = 0;
}
memset(vaddr + head, 0, rq->postfix - head);
+ rq->infix = rq->postfix;
}
static struct i915_request *
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 5387aafd3424..dedacafc9442 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -157,8 +157,11 @@ static void __i915_sw_fence_wake_up_all(struct
i915_sw_fence *fence,
LIST_HEAD(extra);
do {
- list_for_each_entry_safe(pos, next, >head, entry)
- pos->func(pos, TASK_NORMAL, 0, );
+ list_for_each_entry_safe(pos, next, >head, entry) {
+ pos->func(pos,
+ TASK_NORMAL, fence->error,
+ );
+ }
if (list_empty())
break;
@@ -219,6 +222,8 @@ void __i915_sw_fence_init(struct i915_sw_fence *fence,
__init_waitqueue_head(>wait, name, key);
atomic_set(>pending, 1);
+ fence->error = 0;
+
fence->flags = (unsigned long)fn;
}
@@ -230,6 +235,8 @@ void i915_sw_fence_commit(struct i915_sw_fence *fence)
static int i915_sw_fence_wake(wait_queue_entry_t *wq, unsigned mode, int
flags, void *key)
{
+ i915_sw_fence_set_error_once(wq->private, flags);
+
list_del(>entry);
__i915_sw_fence_complete(wq->private, key);
@@ -302,8 +309,10 @@ static int __i915_sw_fence_await_sw_fence(struct
i915_sw_fence *fence,
debug_fence_assert(fence);
might_sleep_if(gfpflags_allow_blocking(gfp));
- if (i915_sw_fence_done(signaler))
+ if (i915_sw_fence_done(signaler)) {
+ i915_sw_fence_set_error_once(fence, signaler->error);
return 0;
+ }
debug_fence_assert(signaler);
@@ -319,6 +328,7 @@ static int __i915_sw_fence_await_sw_fence(struct
i915_sw_fence *fence,
return -ENOMEM;
i915_sw_fence_wait(signaler);
+ i915_sw_fence_set_error_once(fence, signaler->error);
return 0;
}
@@ -337,7 +347,7 @@ static int __i915_sw_fence_await_sw_fence(struct
i915_sw_fence *fence,
__add_wait_queue_entry_tail(>wait, wq);
pending = 1;
} else {
- i915_sw_fence_wake(wq, 0, 0, NULL);
+ i915_sw_fence_wake(wq, 0, signaler->error, NULL);
pending = 0;
}
spin_unlock_irqrestore(>wait.lock, flags);
@@ -372,6 +382,7 @@ static void dma_i915_sw_fence_wake(struct dma_fence *dma,
{
struct i915_sw_dma_fence_cb *cb = container_of(data, typeof(*cb), base);
+ i915_sw_fence_set_error_once(cb->fence, dma->error);
i915_sw_fence_complete(cb->fence);
kfree(cb);
}
@@ -391,6 +402,7 @@ static void timer_i915_sw_fence_wake(struct timer_list *t)
cb->dma->seqno,
i915_sw_fence_debug_hint(fence));
+ i915_sw_fence_set_error_once(fence, -ETIMEDOUT);
i915_sw_fence_complete(fence);
}
@@ -480,6
[Intel-gfx] [PATCH 4/7] drm/i915/gtt: Replace struct_mutex serialisation for allocation
Instead of relying on the caller holding struct_mutex across the
allocation, push the allocation under a tree of spinlocks stored inside
the page tables. Not only should this allow us to avoid struct_mutex
here, but it will allow multiple users to lock independent ranges for
concurrent allocations, and operate independently. This is vital for
pushing the GTT manipulation into a background thread where dependency
on struct_mutex is verboten, and for allowing other callers to avoid
struct_mutex altogether.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 212 +++-
drivers/gpu/drm/i915/i915_gem_gtt.h | 9 +-
2 files changed, 152 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ca8a69e8b098..5000a990ddf3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -655,7 +655,7 @@ static struct i915_page_table *alloc_pt(struct
i915_address_space *vm)
return ERR_PTR(-ENOMEM);
}
- pt->used_ptes = 0;
+ atomic_set(>used_ptes, 0);
return pt;
}
@@ -690,7 +690,8 @@ static struct i915_page_directory *alloc_pd(struct
i915_address_space *vm)
return ERR_PTR(-ENOMEM);
}
- pd->used_pdes = 0;
+ atomic_set(>used_pdes, 0);
+ spin_lock_init(>lock);
return pd;
}
@@ -721,6 +722,8 @@ static int __pdp_init(struct i915_address_space *vm,
memset_p((void **)pdp->page_directory, vm->scratch_pd, pdpes);
+ atomic_set(>used_pdpes, 0);
+ spin_lock_init(>lock);
return 0;
}
@@ -775,11 +778,8 @@ static void free_pdp(struct i915_address_space *vm,
static void gen8_initialize_pdp(struct i915_address_space *vm,
struct i915_page_directory_pointer *pdp)
{
- gen8_ppgtt_pdpe_t scratch_pdpe;
-
- scratch_pdpe = gen8_pdpe_encode(px_dma(vm->scratch_pd), I915_CACHE_LLC);
-
- fill_px(vm, pdp, scratch_pdpe);
+ fill_px(vm, pdp,
+ gen8_pdpe_encode(px_dma(vm->scratch_pd), I915_CACHE_LLC));
}
static void gen8_initialize_pml4(struct i915_address_space *vm,
@@ -788,6 +788,7 @@ static void gen8_initialize_pml4(struct i915_address_space
*vm,
fill_px(vm, pml4,
gen8_pml4e_encode(px_dma(vm->scratch_pdp), I915_CACHE_LLC));
memset_p((void **)pml4->pdps, vm->scratch_pdp, GEN8_PML4ES_PER_PML4);
+ spin_lock_init(>lock);
}
/*
@@ -811,17 +812,12 @@ static bool gen8_ppgtt_clear_pt(const struct
i915_address_space *vm,
unsigned int num_entries = gen8_pte_count(start, length);
gen8_pte_t *vaddr;
- GEM_BUG_ON(num_entries > pt->used_ptes);
-
- pt->used_ptes -= num_entries;
- if (!pt->used_ptes)
- return true;
-
vaddr = kmap_atomic_px(pt);
memset64(vaddr + gen8_pte_index(start), vm->scratch_pte, num_entries);
kunmap_atomic(vaddr);
- return false;
+ GEM_BUG_ON(num_entries > atomic_read(>used_ptes));
+ return !atomic_sub_return(num_entries, >used_ptes);
}
static void gen8_ppgtt_set_pde(struct i915_address_space *vm,
@@ -831,8 +827,6 @@ static void gen8_ppgtt_set_pde(struct i915_address_space
*vm,
{
gen8_pde_t *vaddr;
- pd->page_table[pde] = pt;
-
vaddr = kmap_atomic_px(pd);
vaddr[pde] = gen8_pde_encode(px_dma(pt), I915_CACHE_LLC);
kunmap_atomic(vaddr);
@@ -846,19 +840,28 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space
*vm,
u32 pde;
gen8_for_each_pde(pt, pd, start, length, pde) {
+ bool free = false;
+
GEM_BUG_ON(pt == vm->scratch_pt);
if (!gen8_ppgtt_clear_pt(vm, pt, start, length))
continue;
- gen8_ppgtt_set_pde(vm, pd, vm->scratch_pt, pde);
- GEM_BUG_ON(!pd->used_pdes);
- pd->used_pdes--;
+ spin_lock(>lock);
+ if (!atomic_read(>used_ptes)) {
+ gen8_ppgtt_set_pde(vm, pd, vm->scratch_pt, pde);
+ pd->page_table[pde] = vm->scratch_pt;
- free_pt(vm, pt);
+ GEM_BUG_ON(!atomic_read(>used_pdes));
+ atomic_dec(>used_pdes);
+ free = true;
+ }
+ spin_unlock(>lock);
+ if (free)
+ free_pt(vm, pt);
}
- return !pd->used_pdes;
+ return !atomic_read(>used_pdes);
}
static void gen8_ppgtt_set_pdpe(struct i915_address_space *vm,
@@ -868,7 +871,6 @@ static void gen8_ppgtt_set_pdpe(struct i915_address_space
*vm,
{
gen8_ppgtt_pdpe_t *vaddr;
- pdp->page_directory[pdpe] = pd;
if (!i915_vm_is_4lvl(vm))
return;
@@ -888,19 +890,28 @@ static bool gen8_ppgtt_clear_pdp(struct
i915_address_space
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: Replace struct_mutex serialisation for allocation
== Series Details == Series: drm/i915/gtt: Replace struct_mutex serialisation for allocation URL : https://patchwork.freedesktop.org/series/61533/ State : success == Summary == CI Bug Log - changes from CI_DRM_6182 -> Patchwork_13162 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13162/ Known issues Here are the changes found in Patchwork_13162 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_evict: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([fdo#107709]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bsw-kefka/igt@i915_selftest@live_evict.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13162/fi-bsw-kefka/igt@i915_selftest@live_evict.html * igt@vgem_basic@mmap: - fi-icl-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-dsi/igt@vgem_ba...@mmap.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13162/fi-icl-dsi/igt@vgem_ba...@mmap.html Possible fixes * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy: - fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13162/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 Participating hosts (50 -> 44) -- Additional (1): fi-bsw-n3050 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6182 -> Patchwork_13162 CI_DRM_6182: 63e1cb5d17f931ee65e93fe45d593b45b5c863f5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5029: 5aeacd5cc3fc37ff9e5dccb9e8ae63acdc12e521 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13162: d6226b7f19188796b08ee3e4216fe906c078ce5d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d6226b7f1918 drm/i915/gtt: Replace struct_mutex serialisation for allocation == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13162/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [RFC 1/3] kbuild: add support for ensuring headers are self-contained
Hi Masahiro/Jani. > > Following the obj-y pattern, > I want to make header-test-y relative to $(obj). I also considered this and agree this is better. Otherwise we end up with a spaghetti of dependencies across the tree. What I made just fit the purpose I had that day, which is no excuse for bad design. > I prefer this: > > quiet_cmd_header_test = HDRTEST $@ > cmd_header_test = echo "\#include \"$*.h\"" > $@ > > $(obj)/%.header_test.c: > $(call cmd,header_test) Even better - good. We call it HDRTEST - so why not just go for that name: hdrtest-y += headerfile.h ?? The current proposal with "header-test-y" hurts the eye a little with two '-', and all other variables uses only one '-' as is today. (generic-y, obj-y etc). This is bikeshedding but is was itcing me a little. Sam
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gtt: Replace struct_mutex serialisation for allocation
== Series Details == Series: drm/i915/gtt: Replace struct_mutex serialisation for allocation URL : https://patchwork.freedesktop.org/series/61533/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/gtt: Replace struct_mutex serialisation for allocation -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1372:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1372:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1409:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1409:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1460:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1460:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1389:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1389:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1437:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1437:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1507:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1507:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1759:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1759:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1826:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1826:9: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:3538:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_gem_gtt.c:3538:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:3538:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:3538:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:848:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:848:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:890:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:890:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:939:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:939:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:842:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:842:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:892:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:892:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:948:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:948:9: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gtt: Replace struct_mutex serialisation for allocation
== Series Details == Series: drm/i915/gtt: Replace struct_mutex serialisation for allocation URL : https://patchwork.freedesktop.org/series/61533/ State : warning == Summary == $ dim checkpatch origin/drm-tip d6226b7f1918 drm/i915/gtt: Replace struct_mutex serialisation for allocation -:495: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #495: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:259: + spinlock_t lock; -:503: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #503: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:266: + spinlock_t lock; -:509: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #509: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:272: + spinlock_t lock; total: 0 errors, 0 warnings, 3 checks, 463 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/15] drm/i915: Make the semaphore saturation mask global
== Series Details ==
Series: series starting with [01/15] drm/i915: Make the semaphore saturation
mask global
URL : https://patchwork.freedesktop.org/series/61524/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6182 -> Patchwork_13161
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/
Known issues
Here are the changes found in Patchwork_13161 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([fdo#107709])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bsw-kefka/igt@i915_selftest@live_evict.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/fi-bsw-kefka/igt@i915_selftest@live_evict.html
Possible fixes
* {igt@i915_selftest@live_mman}:
- fi-bxt-dsi: [TIMEOUT][3] ([fdo#110818 ]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bxt-dsi/igt@i915_selftest@live_mman.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/fi-bxt-dsi/igt@i915_selftest@live_mman.html
- fi-icl-u3: [TIMEOUT][5] ([fdo#110818 ]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-u3/igt@i915_selftest@live_mman.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/fi-icl-u3/igt@i915_selftest@live_mman.html
- fi-bxt-j4205: [TIMEOUT][7] ([fdo#110818 ]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bxt-j4205/igt@i915_selftest@live_mman.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/fi-bxt-j4205/igt@i915_selftest@live_mman.html
- fi-glk-dsi: [TIMEOUT][9] ([fdo#110818 ]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-glk-dsi/igt@i915_selftest@live_mman.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/fi-glk-dsi/igt@i915_selftest@live_mman.html
- {fi-apl-guc}: [TIMEOUT][11] ([fdo#110818 ]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-apl-guc/igt@i915_selftest@live_mman.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/fi-apl-guc/igt@i915_selftest@live_mman.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [FAIL][15] ([fdo#103167]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13161/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
{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#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#110818 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110818
Participating hosts (50 -> 44)
--
Additional (1): fi-bsw-n3050
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-byt-clapper
fi-kbl-7560u fi-icl-dsi fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6182 -> Patchwork_13161
CI_DRM_6182: 63e1cb5d17f931ee65e93fe45d593b45b5c863f5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5029: 5aeacd5cc3fc37ff9e5dccb9e8ae63acdc12e521 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13161: fb14188d4b6e98d8b412cde6f2347ccf2b35951e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fb14188d4b6e drm/i915: Add a label for config DRM_I915_SPIN_REQUEST
2b1890df5891 drm/i915/execlists: Force preemption
db2939f074b6 drm/i915/execlists: Minimalistic timeslicing
687140deab24 drm/i915/execlists: Preempt-to-busy
a3bd899e85cb drm/i915: Flush the execution-callbacks on retiring
5c83798408f4 drm/i915: Replace engine->timeline with a plain list
4f00dab1b645 drm/i915: Stop retiring along engine
b875658ce204 drm/i915: Keep contexts pinned until after the next kernel context
switch
0505eaa83ac9 drm/i915: Move object close under its own lock
fb725e75a68e drm/i915: Report an earlier wedged event when suspending the
engines
88a48ffab798 drm/i915: Use unchecked unccore writes to flush the GTT
5518d5a5bcf1 drm/i915: Use unchecked writes for setting up the fences
bef084dfd0fc
Re: [Intel-gfx] [RFC 1/3] kbuild: add support for ensuring headers are self-contained
Hi Jani, On Mon, May 20, 2019 at 6:16 PM Jani Nikula wrote: > > > > > I will take a little time to considier > > how far we can extend the idea about > > "headers should be self-contained". > > Thanks! Please let me know if/when you need further action from me, I > won't post new versions until then. Could you send v2 with the following changes ? [1] Could you rename *.header_test.c to *.hdrtest.c ? (I just thought .header_test.c was a bit too long.) [2] %.hdrtest.c should not depend on the header This will avoid unnecessary regeneration of *.hdrtest.c quiet_cmd_header_test = HDRTEST $@ cmd_header_test = echo "\#include \"$*.h\"" > $@ $(obj)/%.hdrtest.c: $(call cmd,header_test) [3] Please add '*.hdrtest.c' to .gitignore, Documentation/dontdiff [4] Please add '*.hdrtest.c' to 'make clean' (around line 1640 of top Makefile) -- Best Regards Masahiro Yamada
[Intel-gfx] [PATCH] drm/i915/gtt: Replace struct_mutex serialisation for allocation
Instead of relying on the caller holding struct_mutex across the
allocation, push the allocation under a tree of spinlocks stored inside
the page tables. Not only should this allow us to avoid struct_mutex
here, but it will allow multiple users to lock independent ranges for
concurrent allocations, and operate independently. This is vital for
pushing the GTT manipulation into a background thread where dependency
on struct_mutex is verboten, and for allowing other callers to avoid
struct_mutex altogether.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 212 +++-
drivers/gpu/drm/i915/i915_gem_gtt.h | 9 +-
2 files changed, 152 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ca8a69e8b098..5000a990ddf3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -655,7 +655,7 @@ static struct i915_page_table *alloc_pt(struct
i915_address_space *vm)
return ERR_PTR(-ENOMEM);
}
- pt->used_ptes = 0;
+ atomic_set(>used_ptes, 0);
return pt;
}
@@ -690,7 +690,8 @@ static struct i915_page_directory *alloc_pd(struct
i915_address_space *vm)
return ERR_PTR(-ENOMEM);
}
- pd->used_pdes = 0;
+ atomic_set(>used_pdes, 0);
+ spin_lock_init(>lock);
return pd;
}
@@ -721,6 +722,8 @@ static int __pdp_init(struct i915_address_space *vm,
memset_p((void **)pdp->page_directory, vm->scratch_pd, pdpes);
+ atomic_set(>used_pdpes, 0);
+ spin_lock_init(>lock);
return 0;
}
@@ -775,11 +778,8 @@ static void free_pdp(struct i915_address_space *vm,
static void gen8_initialize_pdp(struct i915_address_space *vm,
struct i915_page_directory_pointer *pdp)
{
- gen8_ppgtt_pdpe_t scratch_pdpe;
-
- scratch_pdpe = gen8_pdpe_encode(px_dma(vm->scratch_pd), I915_CACHE_LLC);
-
- fill_px(vm, pdp, scratch_pdpe);
+ fill_px(vm, pdp,
+ gen8_pdpe_encode(px_dma(vm->scratch_pd), I915_CACHE_LLC));
}
static void gen8_initialize_pml4(struct i915_address_space *vm,
@@ -788,6 +788,7 @@ static void gen8_initialize_pml4(struct i915_address_space
*vm,
fill_px(vm, pml4,
gen8_pml4e_encode(px_dma(vm->scratch_pdp), I915_CACHE_LLC));
memset_p((void **)pml4->pdps, vm->scratch_pdp, GEN8_PML4ES_PER_PML4);
+ spin_lock_init(>lock);
}
/*
@@ -811,17 +812,12 @@ static bool gen8_ppgtt_clear_pt(const struct
i915_address_space *vm,
unsigned int num_entries = gen8_pte_count(start, length);
gen8_pte_t *vaddr;
- GEM_BUG_ON(num_entries > pt->used_ptes);
-
- pt->used_ptes -= num_entries;
- if (!pt->used_ptes)
- return true;
-
vaddr = kmap_atomic_px(pt);
memset64(vaddr + gen8_pte_index(start), vm->scratch_pte, num_entries);
kunmap_atomic(vaddr);
- return false;
+ GEM_BUG_ON(num_entries > atomic_read(>used_ptes));
+ return !atomic_sub_return(num_entries, >used_ptes);
}
static void gen8_ppgtt_set_pde(struct i915_address_space *vm,
@@ -831,8 +827,6 @@ static void gen8_ppgtt_set_pde(struct i915_address_space
*vm,
{
gen8_pde_t *vaddr;
- pd->page_table[pde] = pt;
-
vaddr = kmap_atomic_px(pd);
vaddr[pde] = gen8_pde_encode(px_dma(pt), I915_CACHE_LLC);
kunmap_atomic(vaddr);
@@ -846,19 +840,28 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space
*vm,
u32 pde;
gen8_for_each_pde(pt, pd, start, length, pde) {
+ bool free = false;
+
GEM_BUG_ON(pt == vm->scratch_pt);
if (!gen8_ppgtt_clear_pt(vm, pt, start, length))
continue;
- gen8_ppgtt_set_pde(vm, pd, vm->scratch_pt, pde);
- GEM_BUG_ON(!pd->used_pdes);
- pd->used_pdes--;
+ spin_lock(>lock);
+ if (!atomic_read(>used_ptes)) {
+ gen8_ppgtt_set_pde(vm, pd, vm->scratch_pt, pde);
+ pd->page_table[pde] = vm->scratch_pt;
- free_pt(vm, pt);
+ GEM_BUG_ON(!atomic_read(>used_pdes));
+ atomic_dec(>used_pdes);
+ free = true;
+ }
+ spin_unlock(>lock);
+ if (free)
+ free_pt(vm, pt);
}
- return !pd->used_pdes;
+ return !atomic_read(>used_pdes);
}
static void gen8_ppgtt_set_pdpe(struct i915_address_space *vm,
@@ -868,7 +871,6 @@ static void gen8_ppgtt_set_pdpe(struct i915_address_space
*vm,
{
gen8_ppgtt_pdpe_t *vaddr;
- pdp->page_directory[pdpe] = pd;
if (!i915_vm_is_4lvl(vm))
return;
@@ -888,19 +890,28 @@ static bool gen8_ppgtt_clear_pdp(struct
i915_address_space
Re: [Intel-gfx] [RFC 1/3] kbuild: add support for ensuring headers are self-contained
Hi Sam, On Sat, May 25, 2019 at 2:40 AM Sam Ravnborg wrote: > > Hi Jani > > > Sometimes it's useful to be able to explicitly ensure certain headers > > remain self-contained, i.e. that they are compilable as standalone > > units, by including and/or forward declaring everything they depend on. > > > > Add special target header-test-y where individual Makefiles can add > > headers to be tested if CONFIG_HEADER_TEST is enabled. This will > > generate a dummy C file per header that gets built as part of extra-y. > > Very useful, thanks. > I have cooked up something ad-hoc a couple of times but having it as a > standard feature in the build system is much better. > The we can let some of our infrastructure pick up an issues > automatically. > > > > > Cc: Chris Wilson > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Signed-off-by: Jani Nikula > > --- > > Documentation/kbuild/makefiles.txt | 7 +++ > > init/Kconfig | 9 + > > scripts/Makefile.build | 10 ++ > > scripts/Makefile.lib | 3 +++ > > 4 files changed, 29 insertions(+) > > > > diff --git a/Documentation/kbuild/makefiles.txt > > b/Documentation/kbuild/makefiles.txt > > index 03c065855eaf..73df58e5ea0c 100644 > > --- a/Documentation/kbuild/makefiles.txt > > +++ b/Documentation/kbuild/makefiles.txt > > @@ -1036,6 +1036,13 @@ When kbuild executes, the following steps are > > followed (roughly): > > In this example, extra-y is used to list object files that > > shall be built, but shall not be linked as part of built-in.a. > > > > +header-test-y > > + > > + header-test-y specifies headers (*.h) in the current directory that > > + should be compile tested to ensure they are self-contained, > > + i.e. compilable as standalone units. If CONFIG_HEADER_TEST is enabled, > > + this autogenerates dummy sources to include the headers, and builds > > them > > + as part of extra-y. > Do we want to restrict this to current directory only? > Sometimes we could use this for headers in include/ but let it > trigger for the relevant subsystem. > So for example drivers/gpu/drm/Makefile will include the rules > for all headers in include/drm/* > > The alternative would be Makefiles (of Kbuild files) > scattered in the directories with headers and then some > infrastructure to visit those. > > Follow patch extend the header-test feature to work with > headers in include/ Following the obj-y pattern, I want to make header-test-y relative to $(obj). > Example: > # Header files from this directory > header-test-y += drm_crtc_helper_internal.h > header-test-y += drm_crtc_internal.h These are described in drivers/gpu/drm/Makefile. > .. > . > # Header files from include/drm > header-test-y += drm/amd_asic_type.h > header-test-y += drm/ati_pcigart.h These are described in $(srctree)/include/Makefile. > ... > > > In the patch $* is used to get the "stem" from the pattern. > This is the filname of the header file without extension. > > > Sam > > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index 4d4bf698467a..ca132ab3a551 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -295,11 +295,10 @@ $(obj)/%.lst: $(src)/%.c FORCE > # --- > > quiet_cmd_header_test = HDRTEST $@ > - cmd_header_test = echo "\#include \"$( $@ > + cmd_header_test = echo "\#include <$(2).h>" > $@ > > -# FIXME: would be nice to be able to limit this implicit rule to > header-test-y > -$(obj)/%.header_test.c: $(src)/%.h FORCE > - $(call if_changed,header_test) > +$(obj)/%.header_test.c: > + $(call cmd,header_test,$*) > > # Compile assembler sources (.S) > # --- > Agree, this is much better, and it is what scripts/Makefile.asm-generic does. But, you do not need to pass '$*' via the argument. I prefer this: quiet_cmd_header_test = HDRTEST $@ cmd_header_test = echo "\#include \"$*.h\"" > $@ $(obj)/%.header_test.c: $(call cmd,header_test) -- Best Regards Masahiro Yamada ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/15] drm/i915: Make the semaphore saturation mask global
== Series Details == Series: series starting with [01/15] drm/i915: Make the semaphore saturation mask global URL : https://patchwork.freedesktop.org/series/61524/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Make the semaphore saturation mask global Okay! Commit: drm: Flush output polling on shutdown Okay! Commit: drm/i915/selftests: Flush partial-tiling object once -./include/linux/reservation.h:220:20: warning: dereference of noderef expression -./include/linux/reservation.h:220:45: warning: dereference of noderef expression Commit: drm/i915: Use unchecked writes for setting up the fences Okay! Commit: drm/i915: Use unchecked unccore writes to flush the GTT Okay! Commit: drm/i915: Report an earlier wedged event when suspending the engines Okay! Commit: drm/i915: Move object close under its own lock +./include/linux/reservation.h:220:20: warning: dereference of noderef expression +./include/linux/reservation.h:220:45: warning: dereference of noderef expression Commit: drm/i915: Keep contexts pinned until after the next kernel context switch Okay! Commit: drm/i915: Stop retiring along engine Okay! Commit: drm/i915: Replace engine->timeline with a plain list Okay! Commit: drm/i915: Flush the execution-callbacks on retiring Okay! Commit: drm/i915/execlists: Preempt-to-busy -drivers/gpu/drm/i915/selftests/../i915_utils.h:220:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_utils.h:232:16: warning: expression using sizeof(void) Commit: drm/i915/execlists: Minimalistic timeslicing +drivers/gpu/drm/i915/gt/intel_lrc.c:876:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gt/intel_lrc.c:876:16: warning: expression using sizeof(void) Commit: drm/i915/execlists: Force preemption + +drivers/gpu/drm/i915/i915_utils.h:232:16: warning: expression using sizeof(void) +Error in reading or end of file. Commit: drm/i915: Add a label for config DRM_I915_SPIN_REQUEST Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/15] drm/i915: Make the semaphore saturation mask global
== Series Details ==
Series: series starting with [01/15] drm/i915: Make the semaphore saturation
mask global
URL : https://patchwork.freedesktop.org/series/61524/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
73098627036b drm/i915: Make the semaphore saturation mask global
03932e224987 drm: Flush output polling on shutdown
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
<4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103
mutex_destroy+0x49/0x50
total: 0 errors, 1 warnings, 0 checks, 21 lines checked
bef084dfd0fc drm/i915/selftests: Flush partial-tiling object once
5518d5a5bcf1 drm/i915: Use unchecked writes for setting up the fences
88a48ffab798 drm/i915: Use unchecked unccore writes to flush the GTT
fb725e75a68e drm/i915: Report an earlier wedged event when suspending the
engines
0505eaa83ac9 drm/i915: Move object close under its own lock
b875658ce204 drm/i915: Keep contexts pinned until after the next kernel context
switch
4f00dab1b645 drm/i915: Stop retiring along engine
5c83798408f4 drm/i915: Replace engine->timeline with a plain list
-:180: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#180: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:292:
+ spinlock_t lock;
total: 0 errors, 0 warnings, 1 checks, 968 lines checked
a3bd899e85cb drm/i915: Flush the execution-callbacks on retiring
687140deab24 drm/i915/execlists: Preempt-to-busy
-:1494: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p_ptr' - possible
side-effects?
#1494: FILE: drivers/gpu/drm/i915/i915_utils.h:134:
+#define ptr_count_dec(p_ptr) do { \
+ typeof(p_ptr) __p = (p_ptr);\
+ unsigned long __v = (unsigned long)(*__p); \
+ *__p = (typeof(*p_ptr))(--__v); \
+} while (0)
-:1500: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p_ptr' - possible
side-effects?
#1500: FILE: drivers/gpu/drm/i915/i915_utils.h:140:
+#define ptr_count_inc(p_ptr) do { \
+ typeof(p_ptr) __p = (p_ptr);\
+ unsigned long __v = (unsigned long)(*__p); \
+ *__p = (typeof(*p_ptr))(++__v); \
+} while (0)
-:1783: WARNING:LINE_SPACING: Missing a blank line after declarations
#1783: FILE: drivers/gpu/drm/i915/intel_guc_submission.c:820:
+ int rem = ARRAY_SIZE(execlists->inflight) - idx;
+ memmove(execlists->inflight, port, rem * sizeof(*port));
total: 0 errors, 1 warnings, 2 checks, 1682 lines checked
db2939f074b6 drm/i915/execlists: Minimalistic timeslicing
-:345: WARNING:LONG_LINE: line over 100 characters
#345: FILE: drivers/gpu/drm/i915/gt/selftest_lrc.c:211:
+ 2 * RUNTIME_INFO(outer->i915)->num_engines *
(count + 2) * (count + 3)) < 0) {
total: 0 errors, 1 warnings, 0 checks, 426 lines checked
2b1890df5891 drm/i915/execlists: Force preemption
-:51: WARNING:LONG_LINE: line over 100 characters
#51: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1224:
+ jiffies +
msecs_to_jiffies_timeout(CONFIG_DRM_I915_PREEMPT_TIMEOUT));
total: 0 errors, 1 warnings, 0 checks, 87 lines checked
fb14188d4b6e drm/i915: Add a label for config DRM_I915_SPIN_REQUEST
___
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: add syncobj timeline support
On 23/05/2019 16:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-23 14:46:42)
On 23/05/2019 12:52, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-23 12:46:20)
- syncobj = drm_syncobj_find(file, fence.handle);
- if (!syncobj) {
- DRM_DEBUG("Invalid syncobj handle provided\n");
- err = -ENOENT;
- goto err;
+ if (user_fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS)
{
+ err = -EINVAL;
+ goto err;
+ }
+
+ if (user_fence.flags & I915_EXEC_FENCE_WAIT) {
+ err = drm_syncobj_find_fence(
+ file, user_fence.handle,
user_fence.value,
+ DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
+ , );
Is this still a synchronous wait? That would be an unfortunate change in
behaviour and antithesis to having a scheduler.
-Chris
Not sure what you mean by synchronous wait.
drm_syncobj_find_fence() has an open-coded wait_event loop. That is
synchronous and inconsistent with using a scheduler; where one only need
to return a proxy fence that will be populated when the syncpt is known,
and be signaled as a result of that syncpt.
-Chris
Just to confirm, are you fine with the submission path of i915 doing the
wait?
We have support for doing in Anv so that's an option if you prefer.
I don't have a preference :)
Thanks,
-Lionel
___
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: Fix per-pixel alpha with CCS
== Series Details ==
Series: drm/i915: Fix per-pixel alpha with CCS
URL : https://patchwork.freedesktop.org/series/61526/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6182 -> Patchwork_13160
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/
Known issues
Here are the changes found in Patchwork_13160 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][1] -> [FAIL][2] ([fdo#109635 ])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* {igt@i915_selftest@live_mman}:
- fi-bxt-j4205: [TIMEOUT][3] ([fdo#110818 ]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-bxt-j4205/igt@i915_selftest@live_mman.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/fi-bxt-j4205/igt@i915_selftest@live_mman.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6182/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/fi-icl-u3/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#109673]: https://bugs.freedesktop.org/show_bug.cgi?id=109673
[fdo#110818 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110818
Participating hosts (50 -> 46)
--
Additional (2): fi-ilk-650 fi-bsw-n3050
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-kbl-7560u
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6182 -> Patchwork_13160
CI_DRM_6182: 63e1cb5d17f931ee65e93fe45d593b45b5c863f5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5029: 5aeacd5cc3fc37ff9e5dccb9e8ae63acdc12e521 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13160: 5e0dcf38e382bf5338b9414e66ce0936ff19f62c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5e0dcf38e382 drm/i915: Fix per-pixel alpha with CCS
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13160/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/15] drm/i915/execlists: Preempt-to-busy
When using a global seqno, we required a precise stop-the-workd event to
handle preemption and unwind the global seqno counter. To accomplish
this, we would preempt to a special out-of-band context and wait for the
machine to report that it was idle. Given an idle machine, we could very
precisely see which requests had completed and which we needed to feed
back into the run queue.
However, now that we have scrapped the global seqno, we no longer need
to precisely unwind the global counter and only track requests by their
per-context seqno. This allows us to loosely unwind inflight requests
while scheduling a preemption, with the enormous caveat that the
requests we put back on the run queue are still _inflight_ (until the
preemption request is complete). This makes request tracking much more
messy, as at any point then we can see a completed request that we
believe is not currently scheduled for execution. We also have to be
careful not to rewind RING_TAIL past RING_HEAD on preempting to the
running context, and for this we use a semaphore to prevent completion
of the request before continuing.
To accomplish this feat, we change how we track requests scheduled to
the HW. Instead of appending our requests onto a single list as we
submit, we track each submission to ELSP as its own block. Then upon
receiving the CS preemption event, we promote the pending block to the
inflight block (discarding what was previously being tracked). As normal
CS completion events arrive, we then remove stale entries from the
inflight tracker.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +
drivers/gpu/drm/i915/gt/intel_engine.h| 61 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 61 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 52 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 671 --
drivers/gpu/drm/i915/i915_gpu_error.c | 19 +-
drivers/gpu/drm/i915/i915_request.c | 6 +
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_scheduler.c | 3 +-
drivers/gpu/drm/i915/i915_utils.h | 12 +
drivers/gpu/drm/i915/intel_guc_submission.c | 175 ++---
drivers/gpu/drm/i915/selftests/i915_request.c | 8 +-
13 files changed, 465 insertions(+), 611 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 116f0e55308e..632b9c93dee7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -640,7 +640,7 @@ static void init_contexts(struct drm_i915_private *i915)
static bool needs_preempt_context(struct drm_i915_private *i915)
{
- return HAS_EXECLISTS(i915);
+ return USES_GUC_SUBMISSION(i915);
}
int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 08049ee91cee..4c0e211c715d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -13,6 +13,7 @@
#include
#include "i915_active_types.h"
+#include "i915_utils.h"
#include "intel_engine_types.h"
#include "intel_sseu.h"
@@ -38,6 +39,10 @@ struct intel_context {
struct i915_gem_context *gem_context;
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
+#define intel_context_inflight(ce) ptr_mask_bits((ce)->inflight, 2)
+#define intel_context_inflight_count(ce) ptr_unmask_bits((ce)->inflight, 2)
+#define intel_context_inflight_inc(ce) ptr_count_inc(&(ce)->inflight)
+#define intel_context_inflight_dec(ce) ptr_count_dec(&(ce)->inflight)
struct list_head signal_link;
struct list_head signals;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 6815df30f4d2..bc371eab4ee5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -106,71 +106,26 @@ hangcheck_action_to_str(const enum
intel_engine_hangcheck_action a)
void intel_engines_set_scheduler_caps(struct drm_i915_private *i915);
-static inline void
-execlists_set_active(struct intel_engine_execlists *execlists,
-unsigned int bit)
-{
- __set_bit(bit, (unsigned long *)>active);
-}
-
-static inline bool
-execlists_set_active_once(struct intel_engine_execlists *execlists,
- unsigned int bit)
-{
- return !__test_and_set_bit(bit, (unsigned long *)>active);
-}
-
-static inline void
-execlists_clear_active(struct intel_engine_execlists *execlists,
- unsigned int bit)
-{
- __clear_bit(bit, (unsigned long *)>active);
-}
-
-static inline void
-execlists_clear_all_active(struct intel_engine_execlists *execlists)
+static inline unsigned int
+execlists_num_ports(const struct intel_engine_execlists *
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote: > On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote: > > On 2019-05-21 9:52 a.m., Daniel Vetter wrote: > > > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen > > > wrote: > > > > On Mon, 20 May 2019 18:11:07 +0200 > > > > Daniel Vetter wrote: > > > > > > > > > There's also a fairly easy fix for that -modesetting issue: We don't > > > > > expose atomic if the compositor has a process name of "Xserver". > > > > > Brutal, > > > > > but gets the job done. Once X is fixed, we can give a new "I'm not > > > > > totally > > > > > broken anymore" interface to get back at atomic. > > > > > > > > You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you > > > > check against the process issuing ioctl by ioctl, or the process that > > > > opened the device? Which would be logind? What about DRM leasing? ... > > > > > > In the Get/SetCaps ioctl we can do the check, which is called from X, > > > not logind. We just need some way to tell -modesetting apart from > > > everything else, and luckily there's not any other atomic X drivers. > > > > Not yet... > > > > As for a "I'm not totally broken anymore" interface, we did something > > like that (though kind of in the other direction) with > > RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to > > be added, because the former claimed acceleration was "working" in cases > > where it really wasn't... That kind of thing could become ugly in the > > long run if other Xorg driver start using atomic, and they'll inevitably > > be broken in different ways. > > It's definitely a very suboptimal situation. Not sure there's a good way > out. The trouble here is that i915 ended up configuring crtc/connectors > differently than -modesetting (to allow fastboot, which I think is still > i915 exclusive). This then highlighted that modesetting can't do atomic > modesets if you try to reassign connectors. > > One idea I have is that vgms would help compositors to play out a bunch of Just so people aren't confused: I think Daniel meant "vkms" here :P > standard scenarios, even automated. But that's not there yet, and every > compositor project needs to care beyond "boots on my laptop, ship it". No > idea that's even possible. Having documentation for userspace is also important IMHO. Regarding automated compositor testing, it's probably not possible to have a single place where all compositors are tested: vkms should probably be included as part of their CI. Thoughts? Anyway, we could start a discussion to see if compositor people are interested. Or have you already talked to some compositor maintainers? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix per-pixel alpha with CCS
Op 03-06-2019 om 16:25 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> We forgot to set .has_alpha=true for the A+CCS formats when the code
> started to consult .has_alpha. This manifests as A+CCS being treated
> as X+CCS which means no per-pixel alpha blending. Fix the format
> list appropriately.
>
> Cc: sta...@vger.kernel.org
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Cc: Heinrich Fink
> Reported-by: Heinrich Fink
> Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c3e2b1178d55..67d796f4747e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2463,10 +2463,14 @@ static unsigned int intel_fb_modifier_to_tiling(u64
> fb_modifier)
> * main surface.
> */
> static const struct drm_format_info ccs_formats[] = {
> - { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
> 4, 1, }, .hsub = 8, .vsub = 16, },
> - { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
> 4, 1, }, .hsub = 8, .vsub = 16, },
> - { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
> 4, 1, }, .hsub = 8, .vsub = 16, },
> - { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
> 4, 1, }, .hsub = 8, .vsub = 16, },
> + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
> + .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
> + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
> + .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
> + { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
> + .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, .has_alpha = true, },
> + { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
> + .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, .has_alpha = true, },
> };
>
> static const struct drm_format_info *
Makes sense..
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote: > On 2019-05-21 9:52 a.m., Daniel Vetter wrote: > > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote: > >> On Mon, 20 May 2019 18:11:07 +0200 > >> Daniel Vetter wrote: > >> > >>> There's also a fairly easy fix for that -modesetting issue: We don't > >>> expose atomic if the compositor has a process name of "Xserver". Brutal, > >>> but gets the job done. Once X is fixed, we can give a new "I'm not totally > >>> broken anymore" interface to get back at atomic. > >> > >> You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you > >> check against the process issuing ioctl by ioctl, or the process that > >> opened the device? Which would be logind? What about DRM leasing? ... > > > > In the Get/SetCaps ioctl we can do the check, which is called from X, > > not logind. We just need some way to tell -modesetting apart from > > everything else, and luckily there's not any other atomic X drivers. > > Not yet... > > As for a "I'm not totally broken anymore" interface, we did something > like that (though kind of in the other direction) with > RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to > be added, because the former claimed acceleration was "working" in cases > where it really wasn't... That kind of thing could become ugly in the > long run if other Xorg driver start using atomic, and they'll inevitably > be broken in different ways. It's definitely a very suboptimal situation. Not sure there's a good way out. The trouble here is that i915 ended up configuring crtc/connectors differently than -modesetting (to allow fastboot, which I think is still i915 exclusive). This then highlighted that modesetting can't do atomic modesets if you try to reassign connectors. One idea I have is that vgms would help compositors to play out a bunch of standard scenarios, even automated. But that's not there yet, and every compositor project needs to care beyond "boots on my laptop, ship it". No idea that's even possible. -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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add i2c symlink under hdmi connector (rev3)
== Series Details ==
Series: drm/i915: add i2c symlink under hdmi connector (rev3)
URL : https://patchwork.freedesktop.org/series/60866/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6180 -> Patchwork_13159
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/
Known issues
Here are the changes found in Patchwork_13159 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#108569])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_exec_reloc@basic-write-gtt-noreloc:
- fi-icl-u3: [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [FAIL][7] ([fdo#103167]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
{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#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110818 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110818
Participating hosts (51 -> 45)
--
Additional (1): fi-skl-6770hq
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ilk-650 fi-kbl-7560u
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6180 -> Patchwork_13159
CI_DRM_6180: e724dd1cacd9da18b18808880a13b0cb33ddd3d7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5027: c998ca40a12933a0cefbe6b99c916eae32846919 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13159: e5f7c2de7b3d721dfa8af56c3f0b24209d3ea1a9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e5f7c2de7b3d drm/i915: add i2c symlink under hdmi connector
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13159/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: unable to fetch the drm-intel-fixes tree
Hi Daniel, On Mon, 3 Jun 2019 19:50:18 +1000 Stephen Rothwell wrote: > > On Mon, 3 Jun 2019 09:31:03 +0200 Daniel Vetter wrote: > > > > drm.git too I guess? > > No, I fetch that from git://git.freedesktop.org/ which seems to answer. > > > But yeah fd.o anongit keeled over over the w/e :-( Admins not yet awake, > > so can't tell you what's up. > > No worries, I will just keep using what I have previously fetched. And they all look good now. -- Cheers, Stephen Rothwell pgp8R0pcwjAEt.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make the semaphore saturation mask global (rev2)
== Series Details == Series: drm/i915: Make the semaphore saturation mask global (rev2) URL : https://patchwork.freedesktop.org/series/61522/ State : success == Summary == CI Bug Log - changes from CI_DRM_6180 -> Patchwork_13158 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/ Known issues Here are the changes found in Patchwork_13158 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_create@basic: - fi-cml-u: [PASS][1] -> [INCOMPLETE][2] ([fdo#110566]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-cml-u/igt@gem_exec_cre...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/fi-cml-u/igt@gem_exec_cre...@basic.html * igt@gem_mmap_gtt@basic: - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-u3/igt@gem_mmap_...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/fi-icl-u3/igt@gem_mmap_...@basic.html * igt@i915_selftest@live_hangcheck: - fi-icl-dsi: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#108569]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html Possible fixes * igt@gem_exec_reloc@basic-write-gtt-noreloc: - fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html Warnings * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: [FAIL][11] ([fdo#103167]) -> [DMESG-FAIL][12] ([fdo#103167] / [fdo#107724]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566 Participating hosts (51 -> 46) -- Additional (1): fi-skl-6770hq Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6180 -> Patchwork_13158 CI_DRM_6180: e724dd1cacd9da18b18808880a13b0cb33ddd3d7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5027: c998ca40a12933a0cefbe6b99c916eae32846919 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13158: d984edcb24a71640436c7e39b046e9e9620a8d4c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d984edcb24a7 drm/i915: Make the semaphore saturation mask global == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13158/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix per-pixel alpha with CCS
From: Ville Syrjälä
We forgot to set .has_alpha=true for the A+CCS formats when the code
started to consult .has_alpha. This manifests as A+CCS being treated
as X+CCS which means no per-pixel alpha blending. Fix the format
list appropriately.
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Heinrich Fink
Reported-by: Heinrich Fink
Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c3e2b1178d55..67d796f4747e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2463,10 +2463,14 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
* main surface.
*/
static const struct drm_format_info ccs_formats[] = {
- { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 8, .vsub = 16, },
- { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 8, .vsub = 16, },
- { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 8, .vsub = 16, },
- { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 8, .vsub = 16, },
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, .has_alpha = true, },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, .has_alpha = true, },
};
static const struct drm_format_info *
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/15] drm/i915/execlists: Minimalistic timeslicing
If we have multiple contexts of equal priority pending execution,
activate a timer to demote the currently executing context in favour of
the next in the queue when that timeslice expires. This enforces
fairness between contexts (so long as they allow preemption -- forced
preemption, in the future, will kick those who do not obey) and allows
us to avoid userspace blocking forward progress with e.g. unbounded
MI_SEMAPHORE_WAIT.
For the starting point here, we use the jiffie as our timeslice so that
we should be reasonably efficient wrt frequent CPU wakeups.
Testcase: igt/gem_exec_scheduler/semaphore-resolve
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 111 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 223 +++
drivers/gpu/drm/i915/i915_scheduler.c| 1 +
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 342 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index ce0ade3f5cad..1cbe10a0fec7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include "i915_gem.h"
@@ -137,6 +138,11 @@ struct intel_engine_execlists {
*/
struct tasklet_struct tasklet;
+ /**
+* @timer: kick the current context if its timeslice expires
+*/
+ struct timer_list timer;
+
/**
* @default_priolist: priority list for I915_PRIORITY_NORMAL
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1a12d03f2c8e..63a3d9583878 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -255,6 +255,7 @@ static int effective_prio(const struct i915_request *rq)
prio |= I915_PRIORITY_NOSEMAPHORE;
/* Restrict mere WAIT boosts from triggering preemption */
+ BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
return prio | __NO_PREEMPTION;
}
@@ -811,6 +812,81 @@ last_active(const struct intel_engine_execlists *execlists)
return *last;
}
+static void
+defer_request(struct i915_request * const rq, struct list_head * const pl)
+{
+ struct i915_dependency *p;
+
+ /*
+* We want to move the interrupted request to the back of
+* the round-robin list (i.e. its priority level), but
+* in doing so, we must then move all requests that were in
+* flight and were waiting for the interrupted request to
+* be run after it again.
+*/
+ list_move_tail(>sched.link, pl);
+
+ list_for_each_entry(p, >sched.waiters_list, wait_link) {
+ struct i915_request *w =
+ container_of(p->waiter, typeof(*w), sched);
+
+ /* Leave semaphores spinning on the other engines */
+ if (w->engine != rq->engine)
+ continue;
+
+ /* No waiter should start before the active request completed */
+ GEM_BUG_ON(i915_request_started(w));
+
+ GEM_BUG_ON(rq_prio(w) > rq_prio(rq));
+ if (rq_prio(w) < rq_prio(rq))
+ continue;
+
+ if (list_empty(>sched.link))
+ continue; /* Not yet submitted; unready */
+
+ /*
+* This should be very shallow as it is limited by the
+* number of requests that can fit in a ring (<64) and
+* the number of contexts that can be in flight on this
+* engine.
+*/
+ defer_request(w, pl);
+ }
+}
+
+static void defer_active(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ rq = __unwind_incomplete_requests(engine);
+ if (!rq)
+ return;
+
+ defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
+}
+
+static bool
+need_timeslice(struct intel_engine_cs *engine, const struct i915_request *rq)
+{
+ int hint;
+
+ if (list_is_last(>sched.link, >active.requests))
+ return false;
+
+ hint = max(rq_prio(list_next_entry(rq, sched.link)),
+ engine->execlists.queue_priority_hint);
+
+ return hint >= rq_prio(rq);
+}
+
+static bool
+enable_timeslice(struct intel_engine_cs *engine)
+{
+ struct i915_request *last = last_active(>execlists);
+
+ return last && need_timeslice(engine, last);
+}
+
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
@@ -904,6 +980,27 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
*/
last->hw_context->lrc_desc |= CTX_DESC_FORCE_RESTORE;
[Intel-gfx] [PATCH 15/15] drm/i915: Add a label for config DRM_I915_SPIN_REQUEST
If we don't give it a label, it does not appear as a configuration option. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/Kconfig.profile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kconfig.profile index 613b753cb27a..8273d3baafe4 100644 --- a/drivers/gpu/drm/i915/Kconfig.profile +++ b/drivers/gpu/drm/i915/Kconfig.profile @@ -13,7 +13,7 @@ config DRM_I915_USERFAULT_AUTOSUSPEND runtime pm autosuspend delay tunable. config DRM_I915_SPIN_REQUEST - int + int "Busywait for request completion (us)" default 5 # microseconds help Before sleeping waiting for a request (GPU operation) to complete, -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/i915: Make the semaphore saturation mask global
The idea behind keeping the saturation mask local to a context backfired
spectacularly. The premise with the local mask was that we would be more
proactive in attempting to use semaphores after each time the context
idled, and that all new contexts would attempt to use semaphores
ignoring the current state of the system. This turns out to be horribly
optimistic. If the system state is still oversaturated and the existing
workloads have all stopped using semaphores, the new workloads would
attempt to use semaphores and be deprioritised behind real work. The
new contexts would not switch off using semaphores until their initial
batch of low priority work had completed. Given sufficient backload load
of equal user priority, this would completely starve the new work of any
GPU time.
To compensate, remove the local tracking in favour of keeping it as
global state on the engine -- once the system is saturated and
semaphores are disabled, everyone stops attempting to use semaphores
until the system is idle again. One of the reason for preferring local
context tracking was that it worked with virtual engines, so for
switching to global state we could either do a complete check of all the
virtual siblings or simply disable semaphores for those requests. This
takes the simpler approach of disabling semaphores on virtual engines.
The downside is that the decision that the engine is saturated is a
local measure -- we are only checking whether or not this context was
scheduled in a timely fashion, it may be legitimately delayed due to user
priorities. We still have the same dilemma though, that we do not want
to employ the semaphore poll unless it will be used.
Fixes: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated
systems")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Dmitry Rogozhkin
Cc: Dmitry Ermilov
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 --
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 --
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 4 ++--
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index c78ec0b58e77..7e2b18ddda19 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -118,7 +118,6 @@ intel_context_init(struct intel_context *ce,
ce->engine = engine;
ce->ops = engine->cops;
ce->sseu = engine->sseu;
- ce->saturated = 0;
INIT_LIST_HEAD(>signal_link);
INIT_LIST_HEAD(>signals);
@@ -161,7 +160,6 @@ void intel_context_enter_engine(struct intel_context *ce)
void intel_context_exit_engine(struct intel_context *ce)
{
- ce->saturated = 0;
intel_engine_pm_put(ce->engine);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 825fcf0ac9c4..e47d5b7af5d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -53,8 +53,6 @@ struct intel_context {
atomic_t pin_count;
struct mutex pin_mutex; /* guards pinning and associated on-gpuing */
- intel_engine_mask_t saturated; /* submitting semaphores too late? */
-
/**
* active_tracker: Active tracker for the external rq activity
* on this intel_context object.
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index ccf034764741..7bffa0c6f5a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -98,6 +98,8 @@ static int __engine_park(struct intel_wakeref *wf)
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
+ engine->saturated = 0;
+
/*
* If one and only one request is completed between pm events,
* we know that we are inside the kernel context and it is
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 01223864237a..d2dff9056ea0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -292,6 +292,8 @@ struct intel_engine_cs {
struct intel_context *kernel_context; /* pinned */
struct intel_context *preempt_context; /* pinned; optional */
+ intel_engine_mask_t saturated; /* submitting semaphores too late? */
+
unsigned long serial;
unsigned long wakeref_serial;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index fed704802c57..9ba14fa7b7fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3144,7 +3144,6 @@ static void virtual_context_exit(struct intel_context *ce)
[Intel-gfx] [PATCH 04/15] drm/i915: Use unchecked writes for setting up the fences
As the fence registers are not part of the engine powerwells, we do not
need to fiddle with forcewake in order to update a fence. Avoid using
the heavyweight debug checking normal mmio writes as the checking
dominates the selftest runtime and is superfluous!
In the process, retire the I915_WRITE() implicit macro with the new
intel_uncore_write interface.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 123 --
1 file changed, 68 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index 2e9e32330aaa..c68730fb21e6 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -94,9 +94,10 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg
*fence,
}
if (!pipelined) {
- struct drm_i915_private *dev_priv = fence->i915;
+ struct intel_uncore *unc = >i915->uncore;
- /* To w/a incoherency with non-atomic 64-bit register updates,
+ /*
+* To w/a incoherency with non-atomic 64-bit register updates,
* we split the 64-bit update into two 32-bit writes. In order
* for a partial fence not to be evaluated between writes, we
* precede the update with write to turn off the fence register,
@@ -105,12 +106,12 @@ static void i965_write_fence_reg(struct
drm_i915_fence_reg *fence,
* For extra levels of paranoia, we make sure each step lands
* before applying the next step.
*/
- I915_WRITE(fence_reg_lo, 0);
- POSTING_READ(fence_reg_lo);
+ intel_uncore_write_fw(unc, fence_reg_lo, 0);
+ intel_uncore_posting_read_fw(unc, fence_reg_lo);
- I915_WRITE(fence_reg_hi, upper_32_bits(val));
- I915_WRITE(fence_reg_lo, lower_32_bits(val));
- POSTING_READ(fence_reg_lo);
+ intel_uncore_write_fw(unc, fence_reg_hi, upper_32_bits(val));
+ intel_uncore_write_fw(unc, fence_reg_lo, lower_32_bits(val));
+ intel_uncore_posting_read_fw(unc, fence_reg_lo);
}
}
@@ -146,11 +147,11 @@ static void i915_write_fence_reg(struct
drm_i915_fence_reg *fence,
}
if (!pipelined) {
- struct drm_i915_private *dev_priv = fence->i915;
+ struct intel_uncore *unc = >i915->uncore;
i915_reg_t reg = FENCE_REG(fence->id);
- I915_WRITE(reg, val);
- POSTING_READ(reg);
+ intel_uncore_write_fw(unc, reg, val);
+ intel_uncore_posting_read_fw(unc, reg);
}
}
@@ -178,18 +179,19 @@ static void i830_write_fence_reg(struct
drm_i915_fence_reg *fence,
}
if (!pipelined) {
- struct drm_i915_private *dev_priv = fence->i915;
+ struct intel_uncore *unc = >i915->uncore;
i915_reg_t reg = FENCE_REG(fence->id);
- I915_WRITE(reg, val);
- POSTING_READ(reg);
+ intel_uncore_write_fw(unc, reg, val);
+ intel_uncore_posting_read_fw(unc, reg);
}
}
static void fence_write(struct drm_i915_fence_reg *fence,
struct i915_vma *vma)
{
- /* Previous access through the fence register is marshalled by
+ /*
+* Previous access through the fence register is marshalled by
* the mb() inside the fault handlers (i915_gem_release_mmaps)
* and explicitly managed for internal users.
*/
@@ -201,7 +203,8 @@ static void fence_write(struct drm_i915_fence_reg *fence,
else
i965_write_fence_reg(fence, vma);
- /* Access through the fenced region afterwards is
+ /*
+* Access through the fenced region afterwards is
* ordered by the posting reads whilst writing the registers.
*/
@@ -308,11 +311,11 @@ int i915_vma_put_fence(struct i915_vma *vma)
return fence_update(fence, NULL);
}
-static struct drm_i915_fence_reg *fence_find(struct drm_i915_private *dev_priv)
+static struct drm_i915_fence_reg *fence_find(struct drm_i915_private *i915)
{
struct drm_i915_fence_reg *fence;
- list_for_each_entry(fence, _priv->mm.fence_list, link) {
+ list_for_each_entry(fence, >mm.fence_list, link) {
GEM_BUG_ON(fence->vma && fence->vma->fence != fence);
if (fence->pin_count)
@@ -322,7 +325,7 @@ static struct drm_i915_fence_reg *fence_find(struct
drm_i915_private *dev_priv)
}
/* Wait for completion of pending flips which consume fences */
- if (intel_has_pending_fb_unpin(dev_priv))
+ if (intel_has_pending_fb_unpin(i915))
return ERR_PTR(-EAGAIN);
return ERR_PTR(-EDEADLK);
@@ -353,7 +356,8 @@ i915_vma_pin_fence(struct
[Intel-gfx] [PATCH 09/15] drm/i915: Stop retiring along engine
We no longer track the execution order along the engine and so no longer
need to enforce ordering of retire along the engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 128 +++-
1 file changed, 52 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index be830f0ea76d..5423ec9eaf72 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -183,72 +183,23 @@ static void free_capture_list(struct i915_request
*request)
}
}
-static void __retire_engine_request(struct intel_engine_cs *engine,
- struct i915_request *rq)
-{
- GEM_TRACE("%s(%s) fence %llx:%lld, current %d\n",
- __func__, engine->name,
- rq->fence.context, rq->fence.seqno,
- hwsp_seqno(rq));
-
- GEM_BUG_ON(!i915_request_completed(rq));
-
- local_irq_disable();
-
- spin_lock(>timeline.lock);
- GEM_BUG_ON(!list_is_first(>link, >timeline.requests));
- list_del_init(>link);
- spin_unlock(>timeline.lock);
-
- spin_lock(>lock);
- i915_request_mark_complete(rq);
- if (!i915_request_signaled(rq))
- dma_fence_signal_locked(>fence);
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
- i915_request_cancel_breadcrumb(rq);
- if (rq->waitboost) {
- GEM_BUG_ON(!atomic_read(>i915->gt_pm.rps.num_waiters));
- atomic_dec(>i915->gt_pm.rps.num_waiters);
- }
- spin_unlock(>lock);
-
- local_irq_enable();
-}
-
-static void __retire_engine_upto(struct intel_engine_cs *engine,
-struct i915_request *rq)
-{
- struct i915_request *tmp;
-
- if (list_empty(>link))
- return;
-
- do {
- tmp = list_first_entry(>timeline.requests,
- typeof(*tmp), link);
-
- GEM_BUG_ON(tmp->engine != engine);
- __retire_engine_request(engine, tmp);
- } while (tmp != rq);
-}
-
-static void i915_request_retire(struct i915_request *request)
+static bool i915_request_retire(struct i915_request *rq)
{
struct i915_active_request *active, *next;
- GEM_TRACE("%s fence %llx:%lld, current %d\n",
- request->engine->name,
- request->fence.context, request->fence.seqno,
- hwsp_seqno(request));
+ lockdep_assert_held(>i915->drm.struct_mutex);
+ if (!i915_request_completed(rq))
+ return false;
- lockdep_assert_held(>i915->drm.struct_mutex);
- GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
- GEM_BUG_ON(!i915_request_completed(request));
+ GEM_TRACE("%s fence %llx:%lld, current %d\n",
+ rq->engine->name,
+ rq->fence.context, rq->fence.seqno,
+ hwsp_seqno(rq));
- trace_i915_request_retire(request);
+ GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
+ trace_i915_request_retire(rq);
- advance_ring(request);
- free_capture_list(request);
+ advance_ring(rq);
/*
* Walk through the active list, calling retire on each. This allows
@@ -260,7 +211,7 @@ static void i915_request_retire(struct i915_request
*request)
* pass along the auxiliary information (to avoid dereferencing
* the node after the callback).
*/
- list_for_each_entry_safe(active, next, >active_list, link) {
+ list_for_each_entry_safe(active, next, >active_list, link) {
/*
* In microbenchmarks or focusing upon time inside the kernel,
* we may spend an inordinate amount of time simply handling
@@ -276,18 +227,39 @@ static void i915_request_retire(struct i915_request
*request)
INIT_LIST_HEAD(>link);
RCU_INIT_POINTER(active->request, NULL);
- active->retire(active, request);
+ active->retire(active, rq);
+ }
+
+ local_irq_disable();
+
+ spin_lock(>engine->timeline.lock);
+ list_del(>link);
+ spin_unlock(>engine->timeline.lock);
+
+ spin_lock(>lock);
+ i915_request_mark_complete(rq);
+ if (!i915_request_signaled(rq))
+ dma_fence_signal_locked(>fence);
+ if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+ i915_request_cancel_breadcrumb(rq);
+ if (rq->waitboost) {
+ GEM_BUG_ON(!atomic_read(>i915->gt_pm.rps.num_waiters));
+ atomic_dec(>i915->gt_pm.rps.num_waiters);
}
+ spin_unlock(>lock);
+
+ local_irq_enable();
- i915_request_remove_from_client(request);
+ intel_context_exit(rq->hw_context);
+ intel_context_unpin(rq->hw_context);
- __retire_engine_upto(request->engine, request);
+
[Intel-gfx] [PATCH 03/15] drm/i915/selftests: Flush partial-tiling object once
We only need to flush the object once prior to starting the partial
tiling test as inside the test we explicitly maintain coherency.
Signed-off-by: Chris Wilson
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 21 ---
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5db3327958fb..b92809418729 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -98,6 +98,14 @@ static int check_partial_mapping(struct drm_i915_gem_object
*obj,
GEM_BUG_ON(i915_gem_object_get_tiling(obj) != tile->tiling);
GEM_BUG_ON(i915_gem_object_get_stride(obj) != tile->stride);
+ i915_gem_object_lock(obj);
+ err = i915_gem_object_set_to_gtt_domain(obj, true);
+ i915_gem_object_unlock(obj);
+ if (err) {
+ pr_err("Failed to flush to GTT write domain; err=%d\n", err);
+ return err;
+ }
+
for_each_prime_number_from(page, 1, npages) {
struct i915_ggtt_view view =
compute_partial_view(obj, page, MIN_CHUNK_PAGES);
@@ -110,15 +118,6 @@ static int check_partial_mapping(struct
drm_i915_gem_object *obj,
GEM_BUG_ON(view.partial.size > nreal);
cond_resched();
- i915_gem_object_lock(obj);
- err = i915_gem_object_set_to_gtt_domain(obj, true);
- i915_gem_object_unlock(obj);
- if (err) {
- pr_err("Failed to flush to GTT write domain; err=%d\n",
- err);
- return err;
- }
-
vma = i915_gem_object_ggtt_pin(obj, , 0, 0, PIN_MAPPABLE);
if (IS_ERR(vma)) {
pr_err("Failed to pin partial view: offset=%lu;
err=%d\n",
@@ -144,9 +143,7 @@ static int check_partial_mapping(struct drm_i915_gem_object
*obj,
if (offset >= obj->base.size)
continue;
- i915_gem_object_lock(obj);
- i915_gem_object_flush_write_domain(obj, ~I915_GEM_DOMAIN_CPU);
- i915_gem_object_unlock(obj);
+ i915_gem_flush_ggtt_writes(to_i915(obj->base.dev));
p = i915_gem_object_get_page(obj, offset >> PAGE_SHIFT);
cpu = kmap(p) + offset_in_page(offset);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] drm/i915: Keep contexts pinned until after the next kernel context switch
We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each engine, and so to remove that presumption we need to identify a
request/context-switch we know must occur after our completion. Any
request queued after the signal must imply a context switch, for
simplicity we use a fresh request from the kernel context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 ++
drivers/gpu/drm/i915/gem/i915_gem_context.h | 1 -
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 20 -
drivers/gpu/drm/i915/gt/intel_context.c | 80 +++---
drivers/gpu/drm/i915/gt/intel_context.h | 3 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 +-
drivers/gpu/drm/i915/gt/intel_engine.h| 2 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 23 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 13 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 62 ++
drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 44 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 11 +--
drivers/gpu/drm/i915/i915_active.c| 81 ++-
drivers/gpu/drm/i915/i915_active.h| 5 ++
drivers/gpu/drm/i915/i915_active_types.h | 3 +
drivers/gpu/drm/i915/i915_gem.c | 4 -
drivers/gpu/drm/i915/i915_request.c | 15
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
19 files changed, 215 insertions(+), 185 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fb03a19932cf..116f0e55308e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -686,17 +686,6 @@ int i915_gem_contexts_init(struct drm_i915_private
*dev_priv)
return 0;
}
-void i915_gem_contexts_lost(struct drm_i915_private *dev_priv)
-{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- lockdep_assert_held(_priv->drm.struct_mutex);
-
- for_each_engine(engine, dev_priv, id)
- intel_engine_lost_context(engine);
-}
-
void i915_gem_contexts_fini(struct drm_i915_private *i915)
{
lockdep_assert_held(>drm.struct_mutex);
@@ -1181,10 +1170,6 @@ gen8_modify_rpcs(struct intel_context *ce, struct
intel_sseu sseu)
if (ret)
goto out_add;
- ret = gen8_emit_rpcs_config(rq, ce, sseu);
- if (ret)
- goto out_add;
-
/*
* Guarantee context image and the timeline remains pinned until the
* modifying request is retired by setting the ce activity tracker.
@@ -1192,9 +1177,12 @@ gen8_modify_rpcs(struct intel_context *ce, struct
intel_sseu sseu)
* But we only need to take one pin on the account of it. Or in other
* words transfer the pinned ce object to tracked active request.
*/
- if (!i915_active_request_isset(>active_tracker))
- __intel_context_pin(ce);
- __i915_active_request_set(>active_tracker, rq);
+ GEM_BUG_ON(i915_active_is_idle(>active));
+ ret = i915_active_ref(>active, rq->fence.context, rq);
+ if (ret)
+ goto out_add;
+
+ ret = gen8_emit_rpcs_config(rq, ce, sseu);
out_add:
i915_request_add(rq);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 630392c77e48..9691dd062f72 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -134,7 +134,6 @@ static inline bool i915_gem_context_is_kernel(struct
i915_gem_context *ctx)
/* i915_gem_context.c */
int __must_check i915_gem_contexts_init(struct drm_i915_private *dev_priv);
-void i915_gem_contexts_lost(struct drm_i915_private *dev_priv);
void i915_gem_contexts_fini(struct drm_i915_private *dev_priv);
int i915_gem_context_open(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index f40f13c0b8b7..59b6d45b1936 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -10,6 +10,22 @@
#include "i915_drv.h"
#include "i915_globals.h"
+static void call_idle_barriers(struct intel_engine_cs *engine)
+{
+ struct llist_node *node, *next;
+
+ llist_for_each_safe(node, next, llist_del_all(>barrier_tasks)) {
+ struct i915_active_request *active =
+ container_of((struct list_head *)node,
+typeof(*active), link);
+
+ INIT_LIST_HEAD(>link);
+ RCU_INIT_POINTER(active->request, NULL);
+
+
[Intel-gfx] [PATCH 02/15] drm: Flush output polling on shutdown
We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:c96cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: RBX: 88826759a168 RCX: <4> [341.846589] RDX: 0002 RSI: RDI: 8112844c <4> [341.846595] RBP: 8882708fa548 R08: R09: 00039600 <4> [341.846601] R10: R11: 0ce4 R12: a07de1e0 <4> [341.846607] R13: R14: R15: a07de2d0 <4> [341.846613] FS: 7f62b5ae0e40() GS:88827638() knlGS: <4> [341.846620] CS: 0010 DS: ES: CR0: 80050033 <4> [341.846626] CR2: 55a4e064f4a0 CR3: 000266b16006 CR4: 003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:7ffe7a227138 EFLAGS: 0206 ORIG_RAX: 00b0 <4> [341.846904] RAX: ffda RBX: 7ffe7a2272b0 RCX: 7f62b51871b7 <4> [341.846910] RDX: 0001 RSI: 0800 RDI: 557cd6b55948 <4> [341.846916] RBP: 557cd6b558e0 R08: 557cd6b5594c R09: 7ffe7a227160 <4> [341.846922] R10: 7ffe7a226134 R11: 0206 R12: <4> [341.846927] R13: 7ffe7a227820 R14: R15: <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware
[Intel-gfx] [PATCH 05/15] drm/i915: Use unchecked unccore writes to flush the GTT
As the GTT is outside of the powerwell, we can simplify flushing the
GGTT writes by using an unchecked mmio write and post.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ca8a69e8b098..d7572055ce6c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -108,22 +108,26 @@
static int
i915_get_ggtt_vma_pages(struct i915_vma *vma);
-static void gen6_ggtt_invalidate(struct drm_i915_private *dev_priv)
+static void gen6_ggtt_invalidate(struct drm_i915_private *i915)
{
+ struct intel_uncore *unc = >uncore;
+
/*
* Note that as an uncached mmio write, this will flush the
* WCB of the writes into the GGTT before it triggers the invalidate.
*/
- I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+ intel_uncore_write_fw(unc, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
}
-static void guc_ggtt_invalidate(struct drm_i915_private *dev_priv)
+static void guc_ggtt_invalidate(struct drm_i915_private *i915)
{
- gen6_ggtt_invalidate(dev_priv);
- I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ struct intel_uncore *unc = >uncore;
+
+ gen6_ggtt_invalidate(i915);
+ intel_uncore_write_fw(unc, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
}
-static void gmch_ggtt_invalidate(struct drm_i915_private *dev_priv)
+static void gmch_ggtt_invalidate(struct drm_i915_private *i915)
{
intel_gtt_chipset_flush();
}
@@ -1347,10 +1351,10 @@ static void gen8_ppgtt_cleanup_4lvl(struct
i915_hw_ppgtt *ppgtt)
static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
{
- struct drm_i915_private *dev_priv = vm->i915;
+ struct drm_i915_private *i915 = vm->i915;
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
- if (intel_vgpu_active(dev_priv))
+ if (intel_vgpu_active(i915))
gen8_ppgtt_notify_vgt(ppgtt, false);
if (i915_vm_is_4lvl(vm))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/15] drm/i915: Replace engine->timeline with a plain list
To continue the onslaught of removing the assumption of a global
execution ordering, another casualty is the engine->timeline. Without an
actual timeline to track, it is overkill and we can replace it with a
much less grand plain list. We still need a list of requests inflight,
for the simple purpose of finding inflight requests (for retiring,
resetting, preemption etc).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h| 6 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 62 ++--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 95 ++-
drivers/gpu/drm/i915/gt/intel_reset.c | 10 +-
drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 15 ++-
drivers/gpu/drm/i915/gt/mock_engine.c | 18 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 5 +-
drivers/gpu/drm/i915/i915_request.c | 43 +++--
drivers/gpu/drm/i915/i915_request.h | 2 +-
drivers/gpu/drm/i915/i915_scheduler.c | 38
drivers/gpu/drm/i915/i915_timeline.c | 1 -
drivers/gpu/drm/i915/i915_timeline.h | 19
drivers/gpu/drm/i915/i915_timeline_types.h| 4 -
drivers/gpu/drm/i915/intel_guc_submission.c | 16 ++--
.../gpu/drm/i915/selftests/mock_timeline.c| 1 -
16 files changed, 153 insertions(+), 188 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index fe9454faac70..6815df30f4d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -546,4 +546,10 @@ static inline bool inject_preempt_hang(struct
intel_engine_execlists *execlists)
#endif
+void intel_engine_init_active(struct intel_engine_cs *engine,
+ unsigned int subclass);
+#define ENGINE_PHYSICAL0
+#define ENGINE_MOCK1
+#define ENGINE_VIRTUAL 2
+
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 98b217621475..0287c3b094a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -617,14 +617,7 @@ static int intel_engine_setup_common(struct
intel_engine_cs *engine)
if (err)
return err;
- err = i915_timeline_init(engine->i915,
->timeline,
-engine->status_page.vma);
- if (err)
- goto err_hwsp;
-
- i915_timeline_set_subclass(>timeline, TIMELINE_ENGINE);
-
+ intel_engine_init_active(engine, ENGINE_PHYSICAL);
intel_engine_init_breadcrumbs(engine);
intel_engine_init_execlists(engine);
intel_engine_init_hangcheck(engine);
@@ -637,10 +630,6 @@ static int intel_engine_setup_common(struct
intel_engine_cs *engine)
intel_sseu_from_device_info(_INFO(engine->i915)->sseu);
return 0;
-
-err_hwsp:
- cleanup_status_page(engine);
- return err;
}
/**
@@ -797,6 +786,27 @@ static int pin_context(struct i915_gem_context *ctx,
return 0;
}
+void
+intel_engine_init_active(struct intel_engine_cs *engine, unsigned int subclass)
+{
+ INIT_LIST_HEAD(>active.requests);
+
+ spin_lock_init(>active.lock);
+ lockdep_set_subclass(>active.lock, subclass);
+
+ /*
+* Due to an interesting quirk in lockdep's internal debug tracking,
+* after setting a subclass we must ensure the lock is used. Otherwise,
+* nr_unused_locks is incremented once too often.
+*/
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ local_irq_disable();
+ lock_map_acquire(>active.lock.dep_map);
+ lock_map_release(>active.lock.dep_map);
+ local_irq_enable();
+#endif
+}
+
/**
* intel_engines_init_common - initialize cengine state which might require hw
access
* @engine: Engine to initialize.
@@ -860,6 +870,8 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
*/
void intel_engine_cleanup_common(struct intel_engine_cs *engine)
{
+ GEM_BUG_ON(!list_empty(>active.requests));
+
cleanup_status_page(engine);
intel_engine_fini_breadcrumbs(engine);
@@ -874,8 +886,6 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
intel_context_unpin(engine->kernel_context);
GEM_BUG_ON(!llist_empty(>barrier_tasks));
- i915_timeline_fini(>timeline);
-
intel_wa_list_free(>ctx_wa_list);
intel_wa_list_free(>wa_list);
intel_wa_list_free(>whitelist);
@@ -1481,16 +1491,6 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "\tRequests:\n");
- rq = list_first_entry(>timeline.requests,
- struct i915_request, link);
- if (>link != >timeline.requests)
- print_request(m, rq, "\t\tfirst ");
-
- rq = list_last_entry(>timeline.requests,
-
[Intel-gfx] [PATCH 11/15] drm/i915: Flush the execution-callbacks on retiring
In the unlikely case the request completes while we regard it as not even
executing on the GPU (see the next patch!), we have to flush any pending
execution callbacks at retirement and ensure that we do not add any
more.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 93 +++--
1 file changed, 49 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 72d920dcb31a..26bd45f11dc5 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -119,6 +119,50 @@ const struct dma_fence_ops i915_fence_ops = {
.release = i915_fence_release,
};
+static void irq_execute_cb(struct irq_work *wrk)
+{
+ struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
+
+ i915_sw_fence_complete(cb->fence);
+ 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),
+>signal->fence);
+ i915_request_put(cb->signal);
+
+ irq_execute_cb(wrk);
+}
+
+static void __notify_execute_cb(struct i915_request *rq)
+{
+ struct execute_cb *cb;
+
+ lockdep_assert_held(>lock);
+
+ if (list_empty(>execute_cb))
+ return;
+
+ list_for_each_entry(cb, >execute_cb, link)
+ irq_work_queue(>work);
+
+ /*
+* XXX Rollback on __i915_request_unsubmit()
+*
+* In the future, perhaps when we have an active time-slicing scheduler,
+* it will be interesting to unsubmit parallel execution and remove
+* busywaits from the GPU until their master is restarted. This is
+* quite hairy, we have to carefully rollback the fence and do a
+* preempt-to-idle cycle on the target engine, all the while the
+* master execute_cb may refire.
+*/
+ INIT_LIST_HEAD(>execute_cb);
+}
+
static inline void
i915_request_remove_from_client(struct i915_request *request)
{
@@ -246,6 +290,11 @@ static bool i915_request_retire(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(>i915->gt_pm.rps.num_waiters));
atomic_dec(>i915->gt_pm.rps.num_waiters);
}
+ if (!test_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags)) {
+ set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
+ __notify_execute_cb(rq);
+ }
+ GEM_BUG_ON(!list_empty(>execute_cb));
spin_unlock(>lock);
local_irq_enable();
@@ -285,50 +334,6 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (i915_request_retire(tmp) && tmp != rq);
}
-static void irq_execute_cb(struct irq_work *wrk)
-{
- struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
-
- i915_sw_fence_complete(cb->fence);
- 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),
->signal->fence);
- i915_request_put(cb->signal);
-
- irq_execute_cb(wrk);
-}
-
-static void __notify_execute_cb(struct i915_request *rq)
-{
- struct execute_cb *cb;
-
- lockdep_assert_held(>lock);
-
- if (list_empty(>execute_cb))
- return;
-
- list_for_each_entry(cb, >execute_cb, link)
- irq_work_queue(>work);
-
- /*
-* XXX Rollback on __i915_request_unsubmit()
-*
-* In the future, perhaps when we have an active time-slicing scheduler,
-* it will be interesting to unsubmit parallel execution and remove
-* busywaits from the GPU until their master is restarted. This is
-* quite hairy, we have to carefully rollback the fence and do a
-* preempt-to-idle cycle on the target engine, all the while the
-* master execute_cb may refire.
-*/
- INIT_LIST_HEAD(>execute_cb);
-}
-
static int
__i915_request_await_execution(struct i915_request *rq,
struct i915_request *signal,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/15] drm/i915/execlists: Force preemption
If the preempted context takes too long to relinquish control, e.g. it
is stuck inside a shader with arbitration disabled, evict that context
with an engine reset. This ensures that preemptions are reasonably
responsive, providing a tighter QoS for the more important context at
the cost of flagging unresponsive contexts more frequently (i.e. instead
of using an ~10s hangcheck, we now evict at ~10ms). The challenge of
lies in picking a timeout that can be reasonably serviced by HW for
typical workloads, balancing the existing clients against the needs for
responsiveness.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Kconfig.profile | 12 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 49 ++--
2 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 4fd1ea639d0f..613b753cb27a 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -25,3 +25,15 @@ config DRM_I915_SPIN_REQUEST
May be 0 to disable the initial spin. In practice, we estimate
the cost of enabling the interrupt (if currently disabled) to be
a few microseconds.
+
+config DRM_I915_PREEMPT_TIMEOUT
+ int "Preempt timeout (ms)"
+ default 10 # milliseconds
+ help
+ How long to wait (in milliseconds) for a preemption event to occur
+ when submitting a new context via execlists. If the current context
+ does not hit an arbitration point and yield to HW before the timer
+ expires, the HW will be reset to allow the more important context
+ to execute.
+
+ May be 0 to disable the timeout.
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 63a3d9583878..58fd32dd302e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1218,6 +1218,11 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
*port = execlists_schedule_in(last, port - execlists->pending);
memset(port + 1, 0, (last_port - port) * sizeof(*port));
execlists_submit_ports(engine);
+
+ if (CONFIG_DRM_I915_PREEMPT_TIMEOUT) {
+ mod_timer(>timer,
+ jiffies +
msecs_to_jiffies_timeout(CONFIG_DRM_I915_PREEMPT_TIMEOUT));
+ }
}
}
@@ -1373,13 +1378,48 @@ static void process_csb(struct intel_engine_cs *engine)
invalidate_csb_entries([0], [num_entries - 1]);
}
-static void __execlists_submission_tasklet(struct intel_engine_cs *const
engine)
+static bool __execlists_submission_tasklet(struct intel_engine_cs *const
engine)
{
lockdep_assert_held(>active.lock);
process_csb(engine);
- if (!engine->execlists.pending[0])
+ if (!engine->execlists.pending[0]) {
execlists_dequeue(engine);
+ return true;
+ }
+
+ return false;
+}
+
+static void preempt_reset(struct intel_engine_cs *engine)
+{
+ const unsigned int bit = I915_RESET_ENGINE + engine->id;
+ unsigned long *lock = >i915->gpu_error.flags;
+
+ if (test_and_set_bit(bit, lock))
+ return;
+
+ tasklet_disable_nosync(>execlists.tasklet);
+ spin_unlock(>active.lock);
+
+ i915_reset_engine(engine, "preemption time out");
+
+ spin_lock(>active.lock);
+ tasklet_enable(>execlists.tasklet);
+
+ clear_bit(bit, lock);
+ wake_up_bit(lock, bit);
+}
+
+static bool preempt_timeout(struct intel_engine_cs *const engine)
+{
+ if (!CONFIG_DRM_I915_PREEMPT_TIMEOUT)
+ return false;
+
+ if (!intel_engine_has_preemption(engine))
+ return false;
+
+ return !timer_pending(>execlists.timer);
}
/*
@@ -1392,7 +1432,10 @@ static void execlists_submission_tasklet(unsigned long
data)
unsigned long flags;
spin_lock_irqsave(>active.lock, flags);
- __execlists_submission_tasklet(engine);
+
+ if (!__execlists_submission_tasklet(engine) && preempt_timeout(engine))
+ preempt_reset(engine);
+
spin_unlock_irqrestore(>active.lock, flags);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915: Report an earlier wedged event when suspending the engines
On i915_gem_load_power_context() we do care whether or not we succeed in
completing the switch back to the kernel context (via idling the
engines). Currently, we detect if an error occurs while we wait, but we
do not report one if it occurred beforehand (and the status of the
switch is undefined). Check the current terminally wedged status on
entering the wait, and report it after flushing the requests, as if it
had occurred during our own wait.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 89bb6d822f6e..f40f13c0b8b7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -90,7 +90,7 @@ static int pm_notifier(struct notifier_block *nb,
static bool switch_to_kernel_context_sync(struct drm_i915_private *i915)
{
- bool result = true;
+ bool result = !i915_terminally_wedged(i915);
do {
if (i915_gem_wait_for_idle(i915,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/15] drm/i915: Move object close under its own lock
Use i915_gem_object_lock() to guard the LUT and active reference to
allow us to break free of struct_mutex for handling GEM_CLOSE.
Testcase: igt/gem_close_race
Testcase: igt/gem_exec_parallel
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 75 ++-
.../gpu/drm/i915/gem/i915_gem_context_types.h | 12 +--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 25 +--
drivers/gpu/drm/i915/gem/i915_gem_object.c| 38 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 -
.../gpu/drm/i915/gem/selftests/mock_context.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
drivers/gpu/drm/i915/i915_timeline.c | 13 ++--
drivers/gpu/drm/i915/i915_vma.c | 42 +++
drivers/gpu/drm/i915/i915_vma.h | 17 ++---
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
13 files changed, 131 insertions(+), 100 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 08721ef62e4e..fb03a19932cf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -95,24 +95,40 @@ void i915_lut_handle_free(struct i915_lut_handle *lut)
static void lut_close(struct i915_gem_context *ctx)
{
- struct i915_lut_handle *lut, *ln;
struct radix_tree_iter iter;
void __rcu **slot;
- list_for_each_entry_safe(lut, ln, >handles_list, ctx_link) {
- list_del(>obj_link);
- i915_lut_handle_free(lut);
- }
- INIT_LIST_HEAD(>handles_list);
+ lockdep_assert_held(>mutex);
rcu_read_lock();
radix_tree_for_each_slot(slot, >handles_vma, , 0) {
struct i915_vma *vma = rcu_dereference_raw(*slot);
+ struct drm_i915_gem_object *obj = vma->obj;
+ struct i915_lut_handle *lut;
+
+ rcu_read_unlock();
+ i915_gem_object_lock(obj);
+ list_for_each_entry(lut, >lut_list, obj_link) {
+ if (lut->ctx != ctx)
+ continue;
- radix_tree_iter_delete(>handles_vma, , slot);
+ if (lut->handle != iter.index)
+ continue;
- vma->open_count--;
- i915_vma_put(vma);
+ list_del(>obj_link);
+ break;
+ }
+ i915_gem_object_unlock(obj);
+ rcu_read_lock();
+
+ if (>obj_link != >lut_list) {
+ i915_lut_handle_free(lut);
+ radix_tree_iter_delete(>handles_vma, , slot);
+ if (atomic_dec_and_test(>open_count) &&
+ !i915_vma_is_ggtt(vma))
+ i915_vma_close(vma);
+ i915_gem_object_put(obj);
+ }
}
rcu_read_unlock();
}
@@ -250,15 +266,9 @@ static void free_engines(struct i915_gem_engines *e)
__free_engines(e, e->num_engines);
}
-static void free_engines_rcu(struct work_struct *wrk)
+static void free_engines_rcu(struct rcu_head *rcu)
{
- struct i915_gem_engines *e =
- container_of(wrk, struct i915_gem_engines, rcu.work);
- struct drm_i915_private *i915 = e->i915;
-
- mutex_lock(>drm.struct_mutex);
- free_engines(e);
- mutex_unlock(>drm.struct_mutex);
+ free_engines(container_of(rcu, struct i915_gem_engines, rcu));
}
static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx)
@@ -271,7 +281,7 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
if (!e)
return ERR_PTR(-ENOMEM);
- e->i915 = ctx->i915;
+ init_rcu_head(>rcu);
for_each_engine(engine, ctx->i915, id) {
struct intel_context *ce;
@@ -359,7 +369,10 @@ void i915_gem_context_release(struct kref *ref)
static void context_close(struct i915_gem_context *ctx)
{
+ mutex_lock(>mutex);
+
i915_gem_context_set_closed(ctx);
+ ctx->file_priv = ERR_PTR(-EBADF);
/*
* This context will never again be assinged to HW, so we can
@@ -374,7 +387,7 @@ static void context_close(struct i915_gem_context *ctx)
*/
lut_close(ctx);
- ctx->file_priv = ERR_PTR(-EBADF);
+ mutex_unlock(>mutex);
i915_gem_context_put(ctx);
}
@@ -429,7 +442,6 @@ __create_context(struct drm_i915_private *dev_priv)
RCU_INIT_POINTER(ctx->engines, e);
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
- INIT_LIST_HEAD(>handles_list);
INIT_LIST_HEAD(>hw_id_link);
/* NB: Mark all slices as needing a remap so that when the context first
@@ -772,9 +784,7 @@ int i915_gem_context_open(struct
[Intel-gfx] ✗ Fi.CI.BAT: failure for Document fixes for DRM UAPI and HDR (rev2)
== Series Details ==
Series: Document fixes for DRM UAPI and HDR (rev2)
URL : https://patchwork.freedesktop.org/series/61349/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6180 -> Patchwork_13157
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_13157 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_13157, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13157/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_13157:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_evict:
- fi-bsw-n3050: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-bsw-n3050/igt@i915_selftest@live_evict.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13157/fi-bsw-n3050/igt@i915_selftest@live_evict.html
Known issues
Here are the changes found in Patchwork_13157 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_basic@create-close:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-u3/igt@gem_ba...@create-close.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13157/fi-icl-u3/igt@gem_ba...@create-close.html
Possible fixes
* igt@gem_exec_reloc@basic-write-gtt-noreloc:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13157/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt-noreloc.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6180/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13157/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#109673]: https://bugs.freedesktop.org/show_bug.cgi?id=109673
[fdo#110818 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110818
Participating hosts (51 -> 45)
--
Additional (1): fi-skl-6770hq
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-byt-clapper
fi-kbl-7560u fi-icl-dsi fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6180 -> Patchwork_13157
CI_DRM_6180: e724dd1cacd9da18b18808880a13b0cb33ddd3d7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5027: c998ca40a12933a0cefbe6b99c916eae32846919 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13157: 55290c7783043233509a583b5ef3bcea07ae89d1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
55290c778304 video/hdmi: Dropped static functions from kernel doc
6e17572de21e drm: Fix docbook warnings in hdr metadata helper structures
45a1461523e7 drm: ADD UAPI structure definition section in kernel doc
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13157/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: add i2c symlink under hdmi connector
On Mon, Jun 03, 2019 at 10:09:30AM +, Vasilev, Oleg wrote:
> Hi,
>
> Can this be reviewed, please?
It looks good to me. But the test results are horrible, due to the ext4
fail I think. I've hit retest to get new results.
>
> On Mon, 2019-05-20 at 18:06 +0300, Oleg Vasilev wrote:
> > Currently, the i2c adapter is available only under DP connectors.
> >
> > Add i2c symlink under hdmi connector pointing to i2c adapter in order
> > to
> > make this behaviour consistent.
> >
> > The initial motivation was to make igt i2c subtest
> > patch [1] work on all connectors.
> >
> > [1]: https://patchwork.freedesktop.org/series/60357/
> >
> > v2:
> > - Moved symlink remove to unregister (Ville)
> > - Clarified commit message (Jani)
> > - Changed WARN to DRM_ERROR (Jani)
> > - Minor codestyle changes proposed by Jani
> >
> > v3: added blank line
> >
> > Cc: Arkadiusz Hiler
> > Cc: Imre Deak
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Signed-off-by: Oleg Vasilev
> > ---
> > drivers/gpu/drm/i915/intel_hdmi.c | 41
> > ++-
> > 1 file changed, 40 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 2a4086cf2692..a51d1408db7f 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -2658,6 +2658,36 @@ static void chv_hdmi_pre_enable(struct
> > intel_encoder *encoder,
> > chv_phy_release_cl2_override(encoder);
> > }
> >
> > +static struct i2c_adapter *
> > +intel_hdmi_get_i2c_adapter(struct drm_connector *connector)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> > +
> > + return intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> > +}
> > +
> > +static void intel_hdmi_create_i2c_symlink(struct drm_connector
> > *connector)
> > +{
> > + struct i2c_adapter *adapter =
> > intel_hdmi_get_i2c_adapter(connector);
> > + struct kobject *i2c_kobj = >dev.kobj;
> > + struct kobject *connector_kobj = >kdev->kobj;
> > + int ret;
> > +
> > + ret = sysfs_create_link(connector_kobj, i2c_kobj, i2c_kobj-
> > >name);
> > + if (ret)
> > + DRM_ERROR("Failed to create i2c symlink (%d)\n", ret);
> > +}
> > +
> > +static void intel_hdmi_remove_i2c_symlink(struct drm_connector
> > *connector)
> > +{
> > + struct i2c_adapter *adapter =
> > intel_hdmi_get_i2c_adapter(connector);
> > + struct kobject *i2c_kobj = >dev.kobj;
> > + struct kobject *connector_kobj = >kdev->kobj;
> > +
> > + sysfs_remove_link(connector_kobj, i2c_kobj->name);
> > +}
> > +
> > static int
> > intel_hdmi_connector_register(struct drm_connector *connector)
> > {
> > @@ -2669,6 +2699,8 @@ intel_hdmi_connector_register(struct
> > drm_connector *connector)
> >
> > i915_debugfs_connector_add(connector);
> >
> > + intel_hdmi_create_i2c_symlink(connector);
> > +
> > return ret;
> > }
> >
> > @@ -2680,6 +2712,13 @@ static void intel_hdmi_destroy(struct
> > drm_connector *connector)
> > intel_connector_destroy(connector);
> > }
> >
> > +static void intel_hdmi_connector_unregister(struct drm_connector
> > *connector)
> > +{
> > + intel_hdmi_remove_i2c_symlink(connector);
> > +
> > + intel_connector_unregister(connector);
> > +}
> > +
> > static const struct drm_connector_funcs intel_hdmi_connector_funcs =
> > {
> > .detect = intel_hdmi_detect,
> > .force = intel_hdmi_force,
> > @@ -2687,7 +2726,7 @@ static const struct drm_connector_funcs
> > intel_hdmi_connector_funcs = {
> > .atomic_get_property =
> > intel_digital_connector_atomic_get_property,
> > .atomic_set_property =
> > intel_digital_connector_atomic_set_property,
> > .late_register = intel_hdmi_connector_register,
> > - .early_unregister = intel_connector_unregister,
> > + .early_unregister = intel_hdmi_connector_unregister,
> > .destroy = intel_hdmi_destroy,
> > .atomic_destroy_state =
> > drm_atomic_helper_connector_destroy_state,
> > .atomic_duplicate_state =
> > intel_digital_connector_duplicate_state,
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel, Missed last week's window of opportunity due to trouble getting CI results for Icelake. So this is against -rc2 still to avoid re-doing the GVT pull third time. Just a single Icelake W/A for i915. For GVT a fix for recently seen arbitrary DMA map fault and more enforcement fixes. I'll be on my summer vacation starting end of this week, so Jani/Rodrigo will cover for the rest of the -rcs. Regards, Joonas *** drm-intel-fixes-2019-06-03: - Add missing Icelake W/A to disable GPU hang on cache ECC error The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-06-03 for you to fetch changes up to afb286bcae85ee816e8497596bf8e7f83347f47b: Merge tag 'gvt-fixes-2019-05-30' of https://github.com/intel/gvt-linux into drm-intel-fixes (2019-05-31 10:51:59 +0300) - Add missing Icelake W/A to disable GPU hang on cache ECC error Colin Xu (3): drm/i915/gvt: Update force-to-nonpriv register whitelist drm/i915/gvt: Fix GFX_MODE handling drm/i915/gvt: Fix vGPU CSFE_CHICKEN1_REG mmio handler Gao, Fred (1): drm/i915/gvt: Fix cmd length of VEB_DI_IECP Joonas Lahtinen (1): Merge tag 'gvt-fixes-2019-05-30' of https://github.com/intel/gvt-linux into drm-intel-fixes Tina Zhang (1): drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack Tvrtko Ursulin (1): drm/i915/icl: Add WaDisableBankHangMode Xiong Zhang (1): drm/i915/gvt: refine ggtt range validation drivers/gpu/drm/i915/gvt/cmd_parser.c| 2 +- drivers/gpu/drm/i915/gvt/gtt.c | 26 +++ drivers/gpu/drm/i915/gvt/handlers.c | 36 +++- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_workarounds.c | 6 ++ 5 files changed, 62 insertions(+), 11 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Make the semaphore saturation mask global
The idea behind keeping the saturation mask local to a context backfired
spectacularly. The premise with the local mask was that we would be more
proactive in attempting to use semaphores after each time the context
idled, and that all new contexts would attempt to use semaphores
ignoring the current state of the system. This turns out to be horribly
optimistic. If the system state is still oversaturated and the existing
workloads have all stopped using semaphores, the new workloads would
attempt to use semaphores and be deprioritised behind real work. The
new contexts would not switch off using semaphores until their initial
batch of low priority work had completed. Given sufficient backload load
of equal user priority, this would completely starve the new work of any
GPU time.
To compensate, remove the local tracking in favour of keeping it as
global state on the engine -- once the system is saturated and
semaphores are disabled, everyone stops attempting to use semaphores
until the system is idle again. One of the reason for preferring local
context tracking was that it worked with virtual engines, so for
switching to global state we could either do a complete check of all the
virtual siblings or simply disable semaphores for those requests. This
takes the simpler approach of disabling semaphores on virtual engines.
The downside is that the decision that the engine is saturated is a
local measure -- we are only checking whether or not this context was
scheduled in a timely fashion, it may be legitimately delayed due to user
priorities. We still have the same dilemma though, that we do not want
to employ the semaphore poll unless it will be used.
Fixes: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated
systems")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Dmitry Rogozhkin
Cc: Dmitry Ermilov
---
Grammar fixes in commitmsg.
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 --
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 --
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 4 ++--
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index c78ec0b58e77..7e2b18ddda19 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -118,7 +118,6 @@ intel_context_init(struct intel_context *ce,
ce->engine = engine;
ce->ops = engine->cops;
ce->sseu = engine->sseu;
- ce->saturated = 0;
INIT_LIST_HEAD(>signal_link);
INIT_LIST_HEAD(>signals);
@@ -161,7 +160,6 @@ void intel_context_enter_engine(struct intel_context *ce)
void intel_context_exit_engine(struct intel_context *ce)
{
- ce->saturated = 0;
intel_engine_pm_put(ce->engine);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 825fcf0ac9c4..e47d5b7af5d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -53,8 +53,6 @@ struct intel_context {
atomic_t pin_count;
struct mutex pin_mutex; /* guards pinning and associated on-gpuing */
- intel_engine_mask_t saturated; /* submitting semaphores too late? */
-
/**
* active_tracker: Active tracker for the external rq activity
* on this intel_context object.
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index ccf034764741..7bffa0c6f5a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -98,6 +98,8 @@ static int __engine_park(struct intel_wakeref *wf)
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
+ engine->saturated = 0;
+
/*
* If one and only one request is completed between pm events,
* we know that we are inside the kernel context and it is
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 01223864237a..d2dff9056ea0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -292,6 +292,8 @@ struct intel_engine_cs {
struct intel_context *kernel_context; /* pinned */
struct intel_context *preempt_context; /* pinned; optional */
+ intel_engine_mask_t saturated; /* submitting semaphores too late? */
+
unsigned long serial;
unsigned long wakeref_serial;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index fed704802c57..9ba14fa7b7fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3144,7 +3144,6 @@ static void
[Intel-gfx] [PATCH] drm/i915: Make the semaphore saturation mask global
The idea behind keeping the saturation mask local to a context backfired
spectaculary. The premise with the local mask was that we would be more
proactive in attempting to use semaphores everytime after each time th
context idled, and that all new contexts would attempt to use semaphores
ignoring the current state of the system. This turns out to be horribly
optimistic if the system state is still oversaturated and the existing
workloads have all stopped using semaphores. The new workloads would
attempt to use semaphores and be deprioritised behind real work, and
would not switch off using semaphores until their initial batch of
work had completed. Given sufficient backload load of equal user priority,
this would completely starve the new work of any GPU time.
To compensate, remove the local tracking in favour of keeping it as
global state on the engine -- once the system is saturated and
semaphores are disabled, everyone stops attempting to use semaphores
until the system is idle again. One of the reason for preferring local
context tracking was that it worked with virtual engines, so for
switching to global state we could either do a complete check of all the
virtual siblings or simply disable semaphores for those requests. This
takes the simpler approach of disabling semaphores on virtual engines.
The downside is that the decision that the engine is saturated is a
local measure -- we are only checking whether or not this context was
scheduled in a timely fashion, it may be legitimately delayed due to user
priorities. We still have the same dilemma though, that we do not want
to employ the semaphore poll unless it will be used.
Fixes: ca6e56f654e7 ("drm/i915: Disable semaphore busywaits on saturated
systems")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Dmitry Rogozhkin
Cc: Dmitry Ermilov
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 --
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 --
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 4 ++--
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index c78ec0b58e77..7e2b18ddda19 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -118,7 +118,6 @@ intel_context_init(struct intel_context *ce,
ce->engine = engine;
ce->ops = engine->cops;
ce->sseu = engine->sseu;
- ce->saturated = 0;
INIT_LIST_HEAD(>signal_link);
INIT_LIST_HEAD(>signals);
@@ -161,7 +160,6 @@ void intel_context_enter_engine(struct intel_context *ce)
void intel_context_exit_engine(struct intel_context *ce)
{
- ce->saturated = 0;
intel_engine_pm_put(ce->engine);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 825fcf0ac9c4..e47d5b7af5d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -53,8 +53,6 @@ struct intel_context {
atomic_t pin_count;
struct mutex pin_mutex; /* guards pinning and associated on-gpuing */
- intel_engine_mask_t saturated; /* submitting semaphores too late? */
-
/**
* active_tracker: Active tracker for the external rq activity
* on this intel_context object.
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index ccf034764741..7bffa0c6f5a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -98,6 +98,8 @@ static int __engine_park(struct intel_wakeref *wf)
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
+ engine->saturated = 0;
+
/*
* If one and only one request is completed between pm events,
* we know that we are inside the kernel context and it is
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 01223864237a..d2dff9056ea0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -292,6 +292,8 @@ struct intel_engine_cs {
struct intel_context *kernel_context; /* pinned */
struct intel_context *preempt_context; /* pinned; optional */
+ intel_engine_mask_t saturated; /* submitting semaphores too late? */
+
unsigned long serial;
unsigned long wakeref_serial;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index fed704802c57..9ba14fa7b7fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3144,7 +3144,6 @@ static void virtual_context_exit(struct intel_context *ce)
struct
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] benchmarks/gem_wsim: Tidy manual sizeof VLA calculations
On 27/05/2019 10:46, Chris Wilson wrote:
We can use offsetof for the same effect, much tidier with no dummy
locals.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index db19925b1..a76fdbfe2 100644
--- a/benchmarks/gem_wsim.c
+++ b/benchmarks/gem_wsim.c
@@ -1443,23 +1443,20 @@ set_ctx_sseu(struct ctx *ctx, uint64_t slice_mask)
static size_t sizeof_load_balance(int count)
{
- struct i915_context_engines_load_balance *ptr;
-
- return sizeof(*ptr) + count * sizeof(ptr->engines[0]);
+ return offsetof(struct i915_context_engines_load_balance,
+ engines[count]);
}
static size_t sizeof_param_engines(int count)
{
- struct i915_context_param_engines *ptr;
-
- return sizeof(*ptr) + count * sizeof(ptr->engines[0]);
+ return offsetof(struct i915_context_param_engines,
+ engines[count]);
}
static size_t sizeof_engines_bond(int count)
{
- struct i915_context_engines_bond *ptr;
-
- return sizeof(*ptr) + count * sizeof(ptr->engines[0]);
+ return offsetof(struct i915_context_engines_bond,
+ engines[count]);
}
#define alloca0(sz) ({ size_t sz__ = (sz); memset(alloca(sz__), 0, sz__); })
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ppgtt: Remove defunct test
On 02/06/2019 09:53, Chris Wilson wrote:
i915_gem_gtt_info has been removed and so flink-and-exit-vma-leak is
defunct.
Signed-off-by: Chris Wilson
Cc: Matt since he would know he reviewed the corresponding i915 patch.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
---
tests/i915/gem_ppgtt.c | 43 --
1 file changed, 43 deletions(-)
diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
index b905ea559..0d40a7b78 100644
--- a/tests/i915/gem_ppgtt.c
+++ b/tests/i915/gem_ppgtt.c
@@ -289,46 +289,6 @@ static void flink_and_close(void)
close(fd2);
}
-static void flink_and_exit(void)
-{
- uint32_t fd, fd2, fd3;
- uint32_t bo, flinked_bo, name;
- char match[20];
-
- fd = drm_open_driver(DRIVER_INTEL);
- igt_require(gem_uses_full_ppgtt(fd));
-
- bo = gem_create(fd, 4096);
- name = gem_flink(fd, bo);
- snprintf(match, sizeof(match), "(name: %u)", name);
-
- fd2 = drm_open_driver(DRIVER_INTEL);
- flinked_bo = gem_open(fd2, name);
-
- /* Verify VMA is not there yet. */
- igt_assert(!igt_debugfs_search(fd, "i915_gem_gtt", match));
-
- exec_and_get_offset(fd2, flinked_bo);
-
- /* Verify VMA has been created. */
- igt_assert(igt_debugfs_search(fd, "i915_gem_gtt", match));
-
- /* Close the context. */
- close(fd2);
-
- /* Execute a different and unrelated (wrt object sharing) context to
-* ensure engine drops its last context reference.
-*/
- fd3 = drm_open_driver(DRIVER_INTEL);
- exec_and_get_offset(fd3, gem_create(fd3, 4096));
- close(fd3);
-
- igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE | DROP_IDLE);
- igt_assert(!igt_debugfs_search(fd, "i915_gem_gtt", match));
-
- close(fd);
-}
-
#define N_CHILD 8
igt_main
{
@@ -364,7 +324,4 @@ igt_main
igt_subtest("flink-and-close-vma-leak")
flink_and_close();
-
- igt_subtest("flink-and-exit-vma-leak")
- flink_and_exit();
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Fix intel_get_current_physical_engine() iterator
On 03/06/2019 12:19, Petri Latvala wrote: On Mon, Jun 03, 2019 at 11:39:25AM +0100, Tvrtko Ursulin wrote: On 03/06/2019 11:32, Petri Latvala wrote: On Mon, Jun 03, 2019 at 11:19:48AM +0100, Tvrtko Ursulin wrote: On 29/05/2019 14:24, Chris Wilson wrote: If we run out of engines, intel_get_current_physical_engine() degrades into an infinite loop as although it advanced the iterator, it did not update its local engine pointer. We had one infinite loop in there already.. AFAIR it was on one engine platforms. Does the new incarnation happen actually via the __for_each_physical_engine iterator or perhaps only when calling intel_get_current_physical_engine after loop end? Why it wasn't seen in testing? The new incarnation happens with a wedged GPU. That's a case that's hard to come by in testing. 1. Colour me confused. :) How does a wedged GPU affect this loop? Wedging could be a red herring, but regardless the GPU was in a funky state. An easy reproduction method is just # ./perf_pmu (as normal user, not root!) See it now, so the problem is code is not capable of handling zero engines (which it happens if no access to drm master like in your example). As such, Chris' patch looks okay to me. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2 0/3] Document fixes for DRM UAPI and HDR
This series adds DRM UAPI header structure documentation to kernel docs. Fixes issues with existing structure documentation in drm uapi header. This also fixes warnings in HDR doc and addresses suggestions from Daniel Vetter. v2: 2 patches from v1 are merged. This series version adds remaining on top of that. Addressed review comments from Daniel Vetter. Uma Shankar (3): drm: ADD UAPI structure definition section in kernel doc drm: Fix docbook warnings in hdr metadata helper structures video/hdmi: Dropped static functions from kernel doc Documentation/gpu/drm-uapi.rst | 9 + drivers/gpu/drm/drm_connector.c | 37 + drivers/video/hdmi.c| 30 - include/drm/drm_connector.h | 1 + include/drm/drm_mode_config.h | 4 +-- include/linux/hdmi.h| 12 +++ include/uapi/drm/drm_mode.h | 74 - 7 files changed, 134 insertions(+), 33 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2 3/3] video/hdmi: Dropped static functions from kernel doc
Dropped static functions from kernel documentation. v2: Dropped the comments altogether for static functions, as the definitions seems self explanatory. Suggested-by: Daniel Vetter Signed-off-by: Uma Shankar --- drivers/video/hdmi.c | 30 -- 1 file changed, 30 deletions(-) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index b99ba01..b939bc2 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -1191,12 +1191,6 @@ static const char *hdmi_nups_get_name(enum hdmi_nups nups) return "Invalid"; } -/** - * hdmi_avi_infoframe_log() - log info of HDMI AVI infoframe - * @level: logging level - * @dev: device - * @frame: HDMI AVI infoframe - */ static void hdmi_avi_infoframe_log(const char *level, struct device *dev, const struct hdmi_avi_infoframe *frame) @@ -1268,12 +1262,6 @@ static const char *hdmi_spd_sdi_get_name(enum hdmi_spd_sdi sdi) return "Reserved"; } -/** - * hdmi_spd_infoframe_log() - log info of HDMI SPD infoframe - * @level: logging level - * @dev: device - * @frame: HDMI SPD infoframe - */ static void hdmi_spd_infoframe_log(const char *level, struct device *dev, const struct hdmi_spd_infoframe *frame) @@ -1404,12 +1392,6 @@ static void hdmi_spd_infoframe_log(const char *level, return "Reserved"; } -/** - * hdmi_audio_infoframe_log() - log info of HDMI AUDIO infoframe - * @level: logging level - * @dev: device - * @frame: HDMI AUDIO infoframe - */ static void hdmi_audio_infoframe_log(const char *level, struct device *dev, const struct hdmi_audio_infoframe *frame) @@ -1437,12 +1419,6 @@ static void hdmi_audio_infoframe_log(const char *level, frame->downmix_inhibit ? "Yes" : "No"); } -/** - * hdmi_drm_infoframe_log() - log info of HDMI DRM infoframe - * @level: logging level - * @dev: device - * @frame: HDMI DRM infoframe - */ static void hdmi_drm_infoframe_log(const char *level, struct device *dev, const struct hdmi_drm_infoframe *frame) @@ -1500,12 +1476,6 @@ static void hdmi_drm_infoframe_log(const char *level, return "Reserved"; } -/** - * hdmi_vendor_infoframe_log() - log info of HDMI VENDOR infoframe - * @level: logging level - * @dev: device - * @frame: HDMI VENDOR infoframe - */ static void hdmi_vendor_any_infoframe_log(const char *level, struct device *dev, -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2 2/3] drm: Fix docbook warnings in hdr metadata helper structures
Fixes the following warnings:
./include/drm/drm_mode_config.h:841: warning: Incorrect use of
kernel-doc format: * hdr_output_metadata_property: Connector
property containing hdr
./include/drm/drm_mode_config.h:918: warning: Function parameter or member
'hdr_output_metadata_property' not described in 'drm_mode_config'
./include/drm/drm_connector.h:1251: warning: Function parameter or member
'hdr_output_metadata' not described in 'drm_connector'
./include/drm/drm_connector.h:1251: warning: Function parameter or member
'hdr_sink_metadata' not described in 'drm_connector'
Also adds some property documentation for HDR Metadata Connector
Property in connector property create function.
v2: Fixed Sean Paul's review comments.
v3: Fixed Daniel Vetter's review comments, added the UAPI structure
definition section in kernel docs.
v4: Fixed Daniel Vetter's review comments.
Cc: Shashank Sharma
Cc: Ville Syrjä
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: "Ville Syrjä"
Cc: Hans Verkuil
Cc: dri-de...@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Sean Paul
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 37 +
include/drm/drm_connector.h | 1 +
include/drm/drm_mode_config.h | 4 +--
include/linux/hdmi.h| 12 +++
include/uapi/drm/drm_mode.h | 74 -
5 files changed, 125 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c9ac8b9..c445d57 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -956,6 +956,43 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
*
+ * HDR_OUTPUT_METADATA:
+ * Connector property to enable userspace to send HDR Metadata to
+ * driver. This metadata is based on the composition and blending
+ * policies decided by user, taking into account the hardware and
+ * sink capabilities. The driver gets this metadata and creates a
+ * Dynamic Range and Mastering Infoframe (DRM) in case of HDMI,
+ * SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then
+ * sent to sink. This notifies the sink of the upcoming frame's Color
+ * Encoding and Luminance parameters.
+ *
+ * Userspace first need to detect the HDR capabilities of sink by
+ * reading and parsing the EDID. Details of HDR metadata for HDMI
+ * are added in CTA 861.G spec. For DP , its defined in VESA DP
+ * Standard v1.4. It needs to then get the metadata information
+ * of the video/game/app content which are encoded in HDR (basically
+ * using HDR transfer functions). With this information it needs to
+ * decide on a blending policy and compose the relevant
+ * layers/overlays into a common format. Once this blending is done,
+ * userspace will be aware of the metadata of the composed frame to
+ * be send to sink. It then uses this property to communicate this
+ * metadata to driver which then make a Infoframe packet and sends
+ * to sink based on the type of encoder connected.
+ *
+ * Userspace will be responsible to do Tone mapping operation in case:
+ * - Some layers are HDR and others are SDR
+ * - HDR layers luminance is not same as sink
+ * It will even need to do colorspace conversion and get all layers
+ * to one common colorspace for blending. It can use either GL, Media
+ * or display engine to get this done based on the capabilties of the
+ * associated hardware.
+ *
+ * Driver expects metadata to be put in _output_metadata structure
+ * from userspace. It parses EDID and saves the sink metadata in
+ * _sink_metadata. Driver uses _hdmi_infoframe_set_hdr_metadata
+ * helper to set the HDR metadata, _drm_infoframe_pack to pack the
+ * infoframe as per spec, in case of HDMI encoder.
+ *
* max bpc:
* This range property is used by userspace to limit the bit depth. When
* used the driver would limit the bpc in accordance with the valid range
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5476561..47e749b 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1244,6 +1244,7 @@ struct drm_connector {
*/
struct llist_node free_node;
+ /** @hdr_sink_metadata: HDR Metadata Information read from sink */
struct hdr_sink_metadata hdr_sink_metadata;
};
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4f88cc9..759d462 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -837,8 +837,8 @@ struct drm_mode_config {
struct drm_property *writeback_out_fence_ptr_property;
/**
-
[Intel-gfx] [v2 1/3] drm: ADD UAPI structure definition section in kernel doc
Add a new section for UAPI structure and helper definitions in kernel docbook. Suggested-by: Daniel Vetter Signed-off-by: Uma Shankar --- Documentation/gpu/drm-uapi.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index f368e58..94f9052 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -329,3 +329,12 @@ DRM_IOCTL_MODESET_CTL mode setting, since on many devices the vertical blank counter is reset to 0 at some point during modeset. Modern drivers should not call this any more since with kernel mode setting it is a no-op. + +Userspace API Structures + + +.. kernel-doc:: include/uapi/drm/drm_mode.h + :doc: overview + +.. kernel-doc:: include/uapi/drm/drm_mode.h + :internal: -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm: Fix docbook warnings in hdr metadata helper structures
>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Daniel >Vetter >Sent: Monday, June 3, 2019 1:53 PM >To: Shankar, Uma >Cc: Sean Paul ; linux-fb...@vger.kernel.org; >dcasta...@chromium.org; jo...@kwiboo.se; Maxime Ripard >; intel-gfx@lists.freedesktop.org; Bartlomiej >Zolnierkiewicz ; emil.l.veli...@gmail.com; dri- >de...@lists.freedesktop.org; Hans Verkuil ; David Airlie >; seanp...@chromium.org >Subject: Re: [PATCH 2/4] drm: Fix docbook warnings in hdr metadata helper >structures > >On Thu, May 30, 2019 at 01:29:02AM +0530, Uma Shankar wrote: >> Fixes the following warnings: >> ./include/drm/drm_mode_config.h:841: warning: Incorrect use of >> kernel-doc format: * hdr_output_metadata_property: Connector >> property containing hdr >> ./include/drm/drm_mode_config.h:918: warning: Function parameter or member >'hdr_output_metadata_property' not described in 'drm_mode_config' >> ./include/drm/drm_connector.h:1251: warning: Function parameter or member >'hdr_output_metadata' not described in 'drm_connector' >> ./include/drm/drm_connector.h:1251: warning: Function parameter or member >'hdr_sink_metadata' not described in 'drm_connector' >> >> Also adds some property documentation for HDR Metadata Connector >> Property in connector property create function. >> >> v2: Fixed Sean Paul's review comments. >> >> v3: Fixed Daniel Vetter's review comments, added the UAPI structure >> definition section in kernel docs. >> >> Cc: Shashank Sharma >> Cc: Ville Syrjälä >> Cc: Maarten Lankhorst >> Cc: Maxime Ripard >> Cc: Sean Paul >> Cc: David Airlie >> Cc: Daniel Vetter >> Cc: Bartlomiej Zolnierkiewicz >> Cc: "Ville Syrjälä" >> Cc: Hans Verkuil >> Cc: dri-de...@lists.freedesktop.org >> Cc: linux-fb...@vger.kernel.org >> Reviewed-by: Sean Paul >> Signed-off-by: Uma Shankar >> --- >> Documentation/gpu/drm-uapi.rst | 9 + >> drivers/gpu/drm/drm_connector.c | 31 +++ >> include/drm/drm_connector.h | 1 + >> include/drm/drm_mode_config.h | 4 ++-- >> include/linux/hdmi.h| 1 + >> include/uapi/drm/drm_mode.h | 37 >- >> 6 files changed, 80 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/gpu/drm-uapi.rst >> b/Documentation/gpu/drm-uapi.rst index 05874d0..6b39e2c 100644 >> --- a/Documentation/gpu/drm-uapi.rst >> +++ b/Documentation/gpu/drm-uapi.rst >> @@ -329,3 +329,12 @@ DRM_IOCTL_MODESET_CTL >> mode setting, since on many devices the vertical blank counter is >> reset to 0 at some point during modeset. Modern drivers should not >> call this any more since with kernel mode setting it is a no-op. >> + >> +Userspace API Structures >> + >> + >> +.. kernel-doc:: include/uapi/drm/drm_mode.h >> + :doc: overview >> + >> +.. kernel-doc:: include/uapi/drm/drm_mode.h >> + :internal: >> diff --git a/drivers/gpu/drm/drm_connector.c >> b/drivers/gpu/drm/drm_connector.c index c9ac8b9..6a93527 100644 >> --- a/drivers/gpu/drm/drm_connector.c >> +++ b/drivers/gpu/drm/drm_connector.c >> @@ -956,6 +956,37 @@ int drm_display_info_set_bus_formats(struct >drm_display_info *info, >> *is no longer protected and userspace should take appropriate action >> *(whatever that might be). >> * >> + * HDR_OUTPUT_METADATA: >> + * Connector property to enable userspace to send HDR Metadata to >> + * driver. This metadata is based on the composition and blending >> + * policies decided by user, taking into account the hardware and >> + * sink capabilities. The driver gets this metadata and creates a >> + * Dynamic Range and Mastering Infoframe (DRM) in case of HDMI, >> + * SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then >> + * sent to sink. This notifies the sink of the upcoming frame's Color >> + * Encoding and Luminance parameters. >> + * >> + * Userspace first need to detect the HDR capabilities of sink by >> + * reading and parsing the EDID. Details of HDR metadata for HDMI >> + * are added in CTA 861.G spec. For DP , its defined in VESA DP >> + * Standard v1.4. It needs to then get the metadata information >> + * of the video/game/app content which are encoded in HDR (basically >> + * using HDR transfer functions). With this information it needs to >> + * decide on a blending policy and compose the relevant >> + * layers/overlays into a common format. Once this blending is done, >> + * userspace will be aware of the metadata of the composed frame to >> + * be send to sink. It then uses this property to communicate this >> + * metadata to driver which then make a Infoframe packet and sends >> + * to sink based on the type of encoder connected. >> + * >> + * Userspace will be responsible to do Tone mapping operation in case: >> + * - Some layers are HDR and others are SDR >> + * - HDR layers luminance is not same as sink >> + * It will even need to do
[Intel-gfx] [PATCH i-g-t 3/4] i915/gem_create: use __atomic_* instead of __sync_*
Replace calls to the older __sync_* functions with the new __atomic_*
standard ones. This fixes builds on some architectures, in particular
MIPS which doesn't have __sync_add_and_fetch_8 and
__sync_val_compare_and_swap_8 for 64-bit variable handling.
Signed-off-by: Guillaume Tucker
---
tests/Makefile.am | 2 +-
tests/i915/gem_create.c | 12 ++--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5097debf629c..18a0f1f20592 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -90,7 +90,7 @@ AM_LDFLAGS = -Wl,--as-needed
drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
drm_import_export_LDADD = $(LDADD) -lpthread
gem_create_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
-gem_create_LDADD = $(LDADD) -lpthread
+gem_create_LDADD = $(LDADD) -lpthread -latomic
gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_close_race_LDADD = $(LDADD) -lpthread
gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
index 43cbf45f289b..a4aeb94b3f93 100644
--- a/tests/i915/gem_create.c
+++ b/tests/i915/gem_create.c
@@ -156,6 +156,14 @@ static void invalid_nonaligned_size(int fd)
gem_close(fd, create.handle);
}
+static uint64_t atomic_compare_swap_u64(uint64_t *ptr, uint64_t oldval,
+ uint64_t newval)
+{
+ __atomic_compare_exchange_n(ptr, , newval, 0,
+ __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
+ return oldval;
+}
+
static uint64_t get_npages(uint64_t *global, uint64_t npages)
{
uint64_t try, old, max;
@@ -165,7 +173,7 @@ static uint64_t get_npages(uint64_t *global, uint64_t
npages)
old = max;
try = 1 + npages % (max / 2);
max -= try;
- } while ((max = __sync_val_compare_and_swap(global, old, max)) != old);
+ } while ((max = atomic_compare_swap_u64(global, old, max)) != old);
return try;
}
@@ -202,7 +210,7 @@ static void *thread_clear(void *data)
}
gem_close(i915, create.handle);
- __sync_add_and_fetch(>max, npages);
+ __atomic_add_fetch(>max, npages, __ATOMIC_SEQ_CST);
}
return NULL;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/4] tests/sw_sync: use __atomic_* instead of __sync_*
Replace calls to the older __sync_* functions with the new __atomic_*
standard ones to be consistent with other tests and improve
portability across CPU architectures.
Signed-off-by: Guillaume Tucker
---
tests/Makefile.am | 1 +
tests/sw_sync.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 18a0f1f20592..71514d4d2e5a 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -121,6 +121,7 @@ prime_self_import_LDADD = $(LDADD) -lpthread
gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_userptr_blits_LDADD = $(LDADD) -lpthread
perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
+sw_sync_LDADD = $(LDADD) -latomic
kms_flip_LDADD = $(LDADD) -lpthread
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 950b8b614759..2ee1e1c60b32 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -517,7 +517,7 @@ static void test_sync_multi_consumer(void)
{
sem_wait();
- __sync_fetch_and_add(, 1);
+ __atomic_fetch_add(, 1, __ATOMIC_SEQ_CST);
sw_sync_timeline_inc(timeline, 1);
}
@@ -554,7 +554,8 @@ static void * test_sync_multi_consumer_producer_thread(void
*arg)
if (sync_fence_wait(fence, 1000) < 0)
return (void *) 1;
- if (__sync_fetch_and_add(data->counter, 1) != next_point)
+ if (__atomic_fetch_add(data->counter, 1, __ATOMIC_SEQ_CST) !=
+ next_point)
return (void *) 1;
/* Kick off the next thread. */
@@ -900,4 +901,3 @@ igt_main
igt_subtest("sync_random_merge")
test_sync_random_merge();
}
-
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/4] gitlab-ci: add libatomic to Fedora docker image
Add libatomic to the Fedora docker image so it can link binaries that use __atomic_* functions. Signed-off-by: Guillaume Tucker --- Dockerfile.fedora | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Dockerfile.fedora b/Dockerfile.fedora index 6686e587613d..c84b412b0723 100644 --- a/Dockerfile.fedora +++ b/Dockerfile.fedora @@ -1,7 +1,7 @@ FROM fedora:30 RUN dnf install -y \ - gcc flex bison meson ninja-build xdotool \ + gcc flex bison libatomic meson ninja-build xdotool \ 'pkgconfig(libdrm)' \ 'pkgconfig(pciaccess)' \ 'pkgconfig(libkmod)' \ -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/4] tests: add libatomic dependency
Add dependency to libatomic in order to be able to use the __atomic_*
functions instead of the older __sync_* ones. This is to enable
atomic operations on a wider number of architectures including MIPS.
Signed-off-by: Guillaume Tucker
---
meson.build | 1 +
tests/meson.build | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 6268c58d3634..4e5bb323fa49 100644
--- a/meson.build
+++ b/meson.build
@@ -179,6 +179,7 @@ math = cc.find_library('m')
realtime = cc.find_library('rt')
dlsym = cc.find_library('dl')
zlib = cc.find_library('z')
+libatomic = cc.find_library('atomic')
if cc.has_header('linux/kd.h')
config.set('HAVE_LINUX_KD_H', 1)
diff --git a/tests/meson.build b/tests/meson.build
index 806766e51667..6877ccd59235 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -233,7 +233,7 @@ i915_progs = [
'i915_suspend',
]
-test_deps = [ igt_deps ]
+test_deps = [ igt_deps, libatomic ]
if libdrm_nouveau.found()
test_progs += [
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] video/hdmi: Dropped static functions from kernel doc
>-Original Message- >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter >Sent: Monday, June 3, 2019 1:55 PM >To: Shankar, Uma >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >maarten.lankho...@linux.intel.com; ville.syrj...@linux.intel.com; Sharma, >Shashank >; emil.l.veli...@gmail.com; brian.star...@arm.com; >dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D >; jo...@kwiboo.se; dan...@ffwll.ch >Subject: Re: [PATCH 4/4] video/hdmi: Dropped static functions from kernel doc > >On Thu, May 30, 2019 at 01:29:04AM +0530, Uma Shankar wrote: >> Dropped static functions from kernel documentation. >> >> Suggested-by: Daniel Vetter >> Signed-off-by: Uma Shankar >> --- >> drivers/video/hdmi.c | 32 >> 1 file changed, 16 insertions(+), 16 deletions(-) >> >> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index >> b99ba01..72c654b 100644 >> --- a/drivers/video/hdmi.c >> +++ b/drivers/video/hdmi.c >> @@ -1191,11 +1191,11 @@ static const char *hdmi_nups_get_name(enum >hdmi_nups nups) >> return "Invalid"; >> } >> >> -/** >> +/* >> * hdmi_avi_infoframe_log() - log info of HDMI AVI infoframe >> - * @level: logging level >> - * @dev: device >> - * @frame: HDMI AVI infoframe >> + * level: logging level >> + * dev: device >> + * frame: HDMI AVI infoframe >> */ >> static void hdmi_avi_infoframe_log(const char *level, >> struct device *dev, >> @@ -1268,11 +1268,11 @@ static const char *hdmi_spd_sdi_get_name(enum >hdmi_spd_sdi sdi) >> return "Reserved"; >> } >> >> -/** >> +/* >> * hdmi_spd_infoframe_log() - log info of HDMI SPD infoframe >> - * @level: logging level >> - * @dev: device >> - * @frame: HDMI SPD infoframe >> + * level: logging level >> + * dev: device >> + * frame: HDMI SPD infoframe >> */ > >For internal functions I think there's not really any value in documenting >this. The >variable names are obvious enough. Imo better to ditch this outright. Ok, will drop the comments from all these static functions. Regards, Uma Shankar >-Daniel > >> static void hdmi_spd_infoframe_log(const char *level, >> struct device *dev, >> @@ -1404,11 +1404,11 @@ static void hdmi_spd_infoframe_log(const char *level, >> return "Reserved"; >> } >> >> -/** >> +/* >> * hdmi_audio_infoframe_log() - log info of HDMI AUDIO infoframe >> - * @level: logging level >> - * @dev: device >> - * @frame: HDMI AUDIO infoframe >> + * level: logging level >> + * dev: device >> + * frame: HDMI AUDIO infoframe >> */ >> static void hdmi_audio_infoframe_log(const char *level, >> struct device *dev, >> @@ -1437,11 +1437,11 @@ static void hdmi_audio_infoframe_log(const char >*level, >> frame->downmix_inhibit ? "Yes" : "No"); } >> >> -/** >> +/* >> * hdmi_drm_infoframe_log() - log info of HDMI DRM infoframe >> - * @level: logging level >> - * @dev: device >> - * @frame: HDMI DRM infoframe >> + * level: logging level >> + * dev: device >> + * frame: HDMI DRM infoframe >> */ >> static void hdmi_drm_infoframe_log(const char *level, >> struct device *dev, >> -- >> 1.9.1 >> > >-- >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 3/4] drm: Fixed doc warnings in drm uapi header
>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, June 3, 2019 1:56 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>maarten.lankho...@linux.intel.com; ville.syrj...@linux.intel.com; Sharma,
>Shashank
>; emil.l.veli...@gmail.com; brian.star...@arm.com;
>dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D
>; jo...@kwiboo.se; dan...@ffwll.ch
>Subject: Re: [PATCH 3/4] drm: Fixed doc warnings in drm uapi header
>
>On Thu, May 30, 2019 at 01:29:03AM +0530, Uma Shankar wrote:
>> Fixed doc warnings in drm uapi header. All the UAPI structures are now
>> documented in kernel doc.
>>
>> Signed-off-by: Uma Shankar
>
>Applied, thanks for the patch.
>
>Long-term there's obviously a lot more to do here, but this at least gets us
>started.
>
>Btw I think it'd be good to split out the "add new uapi ioctl structures
>section" part
>from the previous patch, and merge that separately.
Ok, will do the same.
Regards,
Uma Shankar
>Thanks, Daniel
>
>> ---
>> include/uapi/drm/drm_mode.h | 22 ++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 5d3964f..02b2a2b 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -861,6 +861,10 @@ struct drm_format_modifier { };
>>
>> /**
>> + * struct drm_mode_create_blob - Create New block property
>> + * @data: Pointer to data to copy.
>> + * @length: Length of data to copy.
>> + * @blob_id: new property ID.
>> * Create a new 'blob' data property, copying length bytes from data
>> pointer,
>> * and returning new blob ID.
>> */
>> @@ -874,6 +878,8 @@ struct drm_mode_create_blob { };
>>
>> /**
>> + * struct drm_mode_destroy_blob - Destroy user blob
>> + * @blob_id: blob_id to destroy
>> * Destroy a user-created blob property.
>> */
>> struct drm_mode_destroy_blob {
>> @@ -881,6 +887,12 @@ struct drm_mode_destroy_blob { };
>>
>> /**
>> + * struct drm_mode_create_lease - Create lease
>> + * @object_ids: Pointer to array of object ids.
>> + * @object_count: Number of object ids.
>> + * @flags: flags for new FD.
>> + * @lessee_id: unique identifier for lessee.
>> + * @fd: file descriptor to new drm_master file.
>> * Lease mode resources, creating another drm_master.
>> */
>> struct drm_mode_create_lease {
>> @@ -898,6 +910,10 @@ struct drm_mode_create_lease { };
>>
>> /**
>> + * struct drm_mode_list_lessees - List lessees
>> + * @count_lessees: Number of lessees.
>> + * @pad: pad.
>> + * @lessees_ptr: Pointer to lessess.
>> * List lesses from a drm_master
>> */
>> struct drm_mode_list_lessees {
>> @@ -918,6 +934,10 @@ struct drm_mode_list_lessees { };
>>
>> /**
>> + * struct drm_mode_get_lease - Get Lease
>> + * @count_objects: Number of leased objects.
>> + * @pad: pad.
>> + * @objects_ptr: Pointer to objects.
>> * Get leased objects
>> */
>> struct drm_mode_get_lease {
>> @@ -938,6 +958,8 @@ struct drm_mode_get_lease { };
>>
>> /**
>> + * struct drm_mode_revoke_lease - Revoke lease
>> + * @lessee_id: Unique ID of lessee.
>> * Revoke lease
>> */
>> struct drm_mode_revoke_lease {
>> --
>> 1.9.1
>>
>
>--
>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 1/4] drm: Drop a redundant unused variable
>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, June 3, 2019 1:42 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>maarten.lankho...@linux.intel.com; ville.syrj...@linux.intel.com; Sharma,
>Shashank
>; emil.l.veli...@gmail.com; brian.star...@arm.com;
>dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D
>; jo...@kwiboo.se; dan...@ffwll.ch
>Subject: Re: [PATCH 1/4] drm: Drop a redundant unused variable
>
>On Thu, May 30, 2019 at 01:29:01AM +0530, Uma Shankar wrote:
>> Drop a redundant and unused variable "hdr_output_metadata" from
>> drm_connector.
>>
>> Suggested-by: Daniel Vetter
>> Signed-off-by: Uma Shankar
>
>For next time around: Please add Fixes: lines to indicate which already merged
>commit you're improving.
Thanks Daniel. Sure, will take care of that in future.
Regards,
Uma Shankar
>Patch merged, thanks.
>-Daniel
>
>> ---
>> include/drm/drm_connector.h | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index f8f4003..5476561 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -1244,8 +1244,6 @@ struct drm_connector {
>> */
>> struct llist_node free_node;
>>
>> -/* HDR metdata */
>> -struct hdr_output_metadata hdr_output_metadata;
>> struct hdr_sink_metadata hdr_sink_metadata; };
>>
>> --
>> 1.9.1
>>
>
>--
>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] [igt-dev] [PATCH i-g-t] lib: Fix intel_get_current_physical_engine() iterator
On Mon, Jun 03, 2019 at 11:39:25AM +0100, Tvrtko Ursulin wrote: > > On 03/06/2019 11:32, Petri Latvala wrote: > > On Mon, Jun 03, 2019 at 11:19:48AM +0100, Tvrtko Ursulin wrote: > > > > > > On 29/05/2019 14:24, Chris Wilson wrote: > > > > If we run out of engines, intel_get_current_physical_engine() degrades > > > > into an infinite loop as although it advanced the iterator, it did not > > > > update its local engine pointer. > > > > > > We had one infinite loop in there already.. AFAIR it was on one engine > > > platforms. Does the new incarnation happen actually via the > > > __for_each_physical_engine iterator or perhaps only when calling > > > intel_get_current_physical_engine after loop end? Why it wasn't seen in > > > testing? > > > > > > The new incarnation happens with a wedged GPU. That's a case that's > > hard to come by in testing. > > 1. > Colour me confused. :) How does a wedged GPU affect this loop? Wedging could be a red herring, but regardless the GPU was in a funky state. An easy reproduction method is just # ./perf_pmu (as normal user, not root!) -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Fix intel_get_current_physical_engine() iterator
On Mon, Jun 03, 2019 at 11:19:48AM +0100, Tvrtko Ursulin wrote: > > On 29/05/2019 14:24, Chris Wilson wrote: > > If we run out of engines, intel_get_current_physical_engine() degrades > > into an infinite loop as although it advanced the iterator, it did not > > update its local engine pointer. > > We had one infinite loop in there already.. AFAIR it was on one engine > platforms. Does the new incarnation happen actually via the > __for_each_physical_engine iterator or perhaps only when calling > intel_get_current_physical_engine after loop end? Why it wasn't seen in > testing? The new incarnation happens with a wedged GPU. That's a case that's hard to come by in testing. -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Fix intel_get_current_physical_engine() iterator
On 03/06/2019 11:32, Petri Latvala wrote: On Mon, Jun 03, 2019 at 11:19:48AM +0100, Tvrtko Ursulin wrote: On 29/05/2019 14:24, Chris Wilson wrote: If we run out of engines, intel_get_current_physical_engine() degrades into an infinite loop as although it advanced the iterator, it did not update its local engine pointer. We had one infinite loop in there already.. AFAIR it was on one engine platforms. Does the new incarnation happen actually via the __for_each_physical_engine iterator or perhaps only when calling intel_get_current_physical_engine after loop end? Why it wasn't seen in testing? The new incarnation happens with a wedged GPU. That's a case that's hard to come by in testing. 1. Colour me confused. :) How does a wedged GPU affect this loop? 2. Are we missing a test? Wedge-do-stuff-unwedge should be easy to write. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Fix intel_get_current_physical_engine() iterator
On 29/05/2019 14:24, Chris Wilson wrote:
If we run out of engines, intel_get_current_physical_engine() degrades
into an infinite loop as although it advanced the iterator, it did not
update its local engine pointer.
We had one infinite loop in there already.. AFAIR it was on one engine
platforms. Does the new incarnation happen actually via the
__for_each_physical_engine iterator or perhaps only when calling
intel_get_current_physical_engine after loop end? Why it wasn't seen in
testing?
Regards,
Tvrtko
Reported-by: Petri Latvala
Fixes: 17c77e7b0c3c ("lib/i915: add gem_engine_topology library and for_each loop
definition")
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: Petri Latvala
---
lib/i915/gem_engine_topology.c | 49 +-
lib/i915/gem_engine_topology.h | 36 -
2 files changed, 29 insertions(+), 56 deletions(-)
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index fdd1b9516..17f67786f 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -81,11 +81,10 @@ static void ctx_map_engines(int fd, struct
intel_engine_data *ed,
struct drm_i915_gem_context_param *param)
{
struct i915_context_param_engines *engines =
- from_user_pointer(param->value);
+ from_user_pointer(param->value);
int i = 0;
- for (typeof(engines->engines[0]) *p =
->engines[0];
+ for (struct i915_engine_class_instance *p = >engines[0];
i < ed->nengines; i++, p++) {
p->engine_class = ed->engines[i].class;
p->engine_instance = ed->engines[i].instance;
@@ -136,7 +135,7 @@ static void query_engine_list(int fd, struct
intel_engine_data *ed)
{
uint8_t buff[SIZEOF_QUERY] = { };
struct drm_i915_query_engine_info *query_engine =
- (struct drm_i915_query_engine_info *) buff;
+ (struct drm_i915_query_engine_info *)buff;
int i;
query_engines(fd, query_engine, SIZEOF_QUERY);
@@ -149,41 +148,6 @@ static void query_engine_list(int fd, struct
intel_engine_data *ed)
ed->nengines = query_engine->num_engines;
}
-struct intel_execution_engine2 *
-intel_get_current_engine(struct intel_engine_data *ed)
-{
- if (!ed->n)
- ed->current_engine = >engines[0];
- else if (ed->n >= ed->nengines)
- ed->current_engine = NULL;
-
- return ed->current_engine;
-}
-
-void intel_next_engine(struct intel_engine_data *ed)
-{
- if (ed->n + 1 < ed->nengines) {
- ed->n++;
- ed->current_engine = >engines[ed->n];
- } else {
- ed->n = ed->nengines;
- ed->current_engine = NULL;
- }
-}
-
-struct intel_execution_engine2 *
-intel_get_current_physical_engine(struct intel_engine_data *ed)
-{
- struct intel_execution_engine2 *e;
-
- for (e = intel_get_current_engine(ed);
-e && e->is_virtual;
-intel_next_engine(ed))
- ;
-
- return e;
-}
-
static int gem_topology_get_param(int fd,
struct drm_i915_gem_context_param *p)
{
@@ -197,10 +161,9 @@ static int gem_topology_get_param(int fd,
return 0;
/* size will store the engine count */
- p->size = (p->size - sizeof(struct i915_context_param_engines)) /
- (offsetof(struct i915_context_param_engines,
- engines[1]) -
- sizeof(struct i915_context_param_engines));
+ igt_assert(p->size >= sizeof(struct i915_context_param_engines));
+ p->size -= sizeof(struct i915_context_param_engines);
+ p->size /= sizeof(struct i915_engine_class_instance);
igt_assert_f(p->size <= GEM_MAX_ENGINES, "unsupported engine count\n");
diff --git a/lib/i915/gem_engine_topology.h b/lib/i915/gem_engine_topology.h
index 2415fd1e3..a1018afca 100644
--- a/lib/i915/gem_engine_topology.h
+++ b/lib/i915/gem_engine_topology.h
@@ -30,9 +30,7 @@
#define GEM_MAX_ENGINES I915_EXEC_RING_MASK + 1
struct intel_engine_data {
- uint32_t nengines;
- uint32_t n;
- struct intel_execution_engine2 *current_engine;
+ uint32_t nengines, cur;
struct intel_execution_engine2 engines[GEM_MAX_ENGINES];
};
@@ -40,31 +38,43 @@ bool gem_has_engine_topology(int fd);
struct intel_engine_data intel_init_engine_list(int fd, uint32_t ctx_id);
/* iteration functions */
-struct intel_execution_engine2 *
-intel_get_current_engine(struct intel_engine_data *ed);
-
-struct intel_execution_engine2 *
-intel_get_current_physical_engine(struct intel_engine_data *ed);
-
-void intel_next_engine(struct intel_engine_data *ed);
-
int gem_context_lookup_engine(int fd, uint64_t engine, uint32_t ctx_id,
struct intel_execution_engine2 *e);
void
Re: [Intel-gfx] [PATCH v3] drm/i915: add i2c symlink under hdmi connector
Hi,
Can this be reviewed, please?
On Mon, 2019-05-20 at 18:06 +0300, Oleg Vasilev wrote:
> Currently, the i2c adapter is available only under DP connectors.
>
> Add i2c symlink under hdmi connector pointing to i2c adapter in order
> to
> make this behaviour consistent.
>
> The initial motivation was to make igt i2c subtest
> patch [1] work on all connectors.
>
> [1]: https://patchwork.freedesktop.org/series/60357/
>
> v2:
> - Moved symlink remove to unregister (Ville)
> - Clarified commit message (Jani)
> - Changed WARN to DRM_ERROR (Jani)
> - Minor codestyle changes proposed by Jani
>
> v3: added blank line
>
> Cc: Arkadiusz Hiler
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Signed-off-by: Oleg Vasilev
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 41
> ++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 2a4086cf2692..a51d1408db7f 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -2658,6 +2658,36 @@ static void chv_hdmi_pre_enable(struct
> intel_encoder *encoder,
> chv_phy_release_cl2_override(encoder);
> }
>
> +static struct i2c_adapter *
> +intel_hdmi_get_i2c_adapter(struct drm_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> +
> + return intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> +}
> +
> +static void intel_hdmi_create_i2c_symlink(struct drm_connector
> *connector)
> +{
> + struct i2c_adapter *adapter =
> intel_hdmi_get_i2c_adapter(connector);
> + struct kobject *i2c_kobj = >dev.kobj;
> + struct kobject *connector_kobj = >kdev->kobj;
> + int ret;
> +
> + ret = sysfs_create_link(connector_kobj, i2c_kobj, i2c_kobj-
> >name);
> + if (ret)
> + DRM_ERROR("Failed to create i2c symlink (%d)\n", ret);
> +}
> +
> +static void intel_hdmi_remove_i2c_symlink(struct drm_connector
> *connector)
> +{
> + struct i2c_adapter *adapter =
> intel_hdmi_get_i2c_adapter(connector);
> + struct kobject *i2c_kobj = >dev.kobj;
> + struct kobject *connector_kobj = >kdev->kobj;
> +
> + sysfs_remove_link(connector_kobj, i2c_kobj->name);
> +}
> +
> static int
> intel_hdmi_connector_register(struct drm_connector *connector)
> {
> @@ -2669,6 +2699,8 @@ intel_hdmi_connector_register(struct
> drm_connector *connector)
>
> i915_debugfs_connector_add(connector);
>
> + intel_hdmi_create_i2c_symlink(connector);
> +
> return ret;
> }
>
> @@ -2680,6 +2712,13 @@ static void intel_hdmi_destroy(struct
> drm_connector *connector)
> intel_connector_destroy(connector);
> }
>
> +static void intel_hdmi_connector_unregister(struct drm_connector
> *connector)
> +{
> + intel_hdmi_remove_i2c_symlink(connector);
> +
> + intel_connector_unregister(connector);
> +}
> +
> static const struct drm_connector_funcs intel_hdmi_connector_funcs =
> {
> .detect = intel_hdmi_detect,
> .force = intel_hdmi_force,
> @@ -2687,7 +2726,7 @@ static const struct drm_connector_funcs
> intel_hdmi_connector_funcs = {
> .atomic_get_property =
> intel_digital_connector_atomic_get_property,
> .atomic_set_property =
> intel_digital_connector_atomic_set_property,
> .late_register = intel_hdmi_connector_register,
> - .early_unregister = intel_connector_unregister,
> + .early_unregister = intel_hdmi_connector_unregister,
> .destroy = intel_hdmi_destroy,
> .atomic_destroy_state =
> drm_atomic_helper_connector_destroy_state,
> .atomic_duplicate_state =
> intel_digital_connector_duplicate_state,
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
On Monday, June 3, 2019 9:28:18 AM CEST Daniel Vetter wrote:
> On Thu, May 30, 2019 at 10:40:09AM +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-05-30 10:24:26)
> > > In order to support driver hot unbind, some cleanup operations, now
> > > performed on PCI driver remove, must be called later, after all device
> > > file descriptors are closed.
> > >
> > > Split out those operations from the tail of pci_driver.remove()
> > > callback and put them into drm_driver.release() which is called as soon
> > > as all references to the driver are put. As a result, those cleanups
> > > will be now run on last drm_dev_put(), either still called from
> > > pci_driver.remove() if all device file descriptors are already closed,
> > > or on last drm_release() file operation.
> > >
> > > Signed-off-by: Janusz Krzysztofik
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.c | 17 +
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/i915_gem.c | 10 +-
> > > 3 files changed, 23 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/
i915_drv.c
> > > index 83d2eb9e74cb..8be69f84eb6d 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device
*dev)
> > >
> > > cleanup_gem:
> > > i915_gem_suspend(dev_priv);
> > > + i915_gem_fini_hw(dev_priv);
> > > i915_gem_fini(dev_priv);
> > > cleanup_modeset:
> > > intel_modeset_cleanup(dev);
> > > @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct
drm_i915_private *dev_priv)
> > > pci_disable_msi(pdev);
> > >
> > > pm_qos_remove_request(_priv->pm_qos);
> > > - i915_ggtt_cleanup_hw(dev_priv);
> > > }
> > >
> > > /**
> > > @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const
struct pci_device_id *ent)
> >
> > Would it make sense to rename load/unload from the legacy drm stubs over
> > to match the pci entry points?
>
> +1 on that rename, load/unload is really terribly confusing and has
> horrible semantics in the dri1 shadow attach world ...
> -Daniel
I've not responded to that comment, sorry, but I agree too. I've assumed
that's a candidate for a separate patch or series. I'm willing to work on
that as time permits.
Thanks,
Janusz
> >
> > > out_cleanup_hw:
> > > i915_driver_cleanup_hw(dev_priv);
> > > + i915_ggtt_cleanup_hw(dev_priv);
> > > out_cleanup_mmio:
> > > i915_driver_cleanup_mmio(dev_priv);
> > > out_runtime_pm_put:
> > > @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
> > > cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> > > i915_reset_error_state(dev_priv);
> > >
> > > - i915_gem_fini(dev_priv);
> > > + i915_gem_fini_hw(dev_priv);
> > >
> > > intel_power_domains_fini_hw(dev_priv);
> > >
> > > i915_driver_cleanup_hw(dev_priv);
> > > - i915_driver_cleanup_mmio(dev_priv);
> > >
> > > enable_rpm_wakeref_asserts(dev_priv);
> > > - intel_runtime_pm_cleanup(dev_priv);
> > > }
> > >
> > > static void i915_driver_release(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(dev);
> > >
> > > + disable_rpm_wakeref_asserts(dev_priv);
> > > +
> > > + i915_gem_fini(dev_priv);
> > > +
> > > + i915_ggtt_cleanup_hw(dev_priv);
> > > + i915_driver_cleanup_mmio(dev_priv);
> > > +
> > > + enable_rpm_wakeref_asserts(dev_priv);
> > > + intel_runtime_pm_cleanup(dev_priv);
> >
> > We should really propagate the release nomenclature down and replace our
> > mixed fini/cleanup. Consistency is helpful when trying to work out which
> > phase the code is in.
> >
> > > i915_driver_cleanup_early(dev_priv);
> > > i915_driver_destroy(dev_priv);
> > > }
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/
i915_drv.h
> > > index a2664ea1395b..d08e7bd83544 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private
*i915);
> > > int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
> > > int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
> > > void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
> > > +void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
> > > void i915_gem_fini(struct drm_i915_private *dev_priv);
> > > int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
> > >unsigned int flags, long timeout);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/
i915_gem.c
> > > index 7cafd5612f71..c6a8e665a6ba 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
[Intel-gfx] ✓ Fi.CI.IGT: success for i915 vgpu PV to improve vgpu performance
== Series Details ==
Series: i915 vgpu PV to improve vgpu performance
URL : https://patchwork.freedesktop.org/series/61493/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6179_full -> Patchwork_13156_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_13156_full:
### Piglit changes ###
Possible regressions
* spec@glsl-1.30@execution@tex-miplevel-selection texturelod 1d (NEW):
- {pig-snb-2600}: NOTRUN -> [FAIL][1]
[1]: None
New tests
-
New tests have been introduced between CI_DRM_6179_full and
Patchwork_13156_full:
### New Piglit tests (1) ###
* spec@glsl-1.30@execution@tex-miplevel-selection texturelod 1d:
- Statuses : 1 fail(s)
- Exec time: [7.69] s
Known issues
Here are the changes found in Patchwork_13156_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@rcs0-s3:
- shard-apl: [PASS][2] -> [DMESG-WARN][3] ([fdo#108566]) +5
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html
* igt@gem_tiled_swapping@non-threaded:
- shard-iclb: [PASS][4] -> [FAIL][5] ([fdo#108686])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-iclb3/igt@gem_tiled_swapp...@non-threaded.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-iclb1/igt@gem_tiled_swapp...@non-threaded.html
* igt@kms_flip@2x-flip-vs-absolute-wf_vblank:
- shard-hsw: [PASS][6] -> [SKIP][7] ([fdo#109271]) +16 similar
issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-hsw4/igt@kms_flip@2x-flip-vs-absolute-wf_vblank.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-hsw1/igt@kms_flip@2x-flip-vs-absolute-wf_vblank.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][8] -> [FAIL][9] ([fdo#103167]) +5 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-pgflip-blt:
- shard-skl: [PASS][10] -> [FAIL][11] ([fdo#108040])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-skl10/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-pgflip-blt.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-skl10/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu:
- shard-skl: [PASS][12] -> [FAIL][13] ([fdo#103167])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-kbl: [PASS][14] -> [DMESG-WARN][15] ([fdo#108566]) +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-kbl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][16] -> [FAIL][17] ([fdo#108145])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
* igt@kms_psr@no_drrs:
- shard-iclb: [PASS][18] -> [FAIL][19] ([fdo#108341])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-iclb6/igt@kms_psr@no_drrs.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-iclb1/igt@kms_psr@no_drrs.html
* igt@kms_psr@psr2_no_drrs:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +2 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/shard-iclb6/igt@kms_psr@psr2_no_drrs.html
* igt@perf_pmu@rc6-runtime-pm-long:
- shard-kbl: [PASS][22] -> [FAIL][23] ([fdo#105010])
[22]:
Re: [Intel-gfx] linux-next: unable to fetch the drm-intel-fixes tree
Hi Daniel, On Mon, 3 Jun 2019 09:31:03 +0200 Daniel Vetter wrote: > > drm.git too I guess? No, I fetch that from git://git.freedesktop.org/ which seems to answer. > But yeah fd.o anongit keeled over over the w/e :-( Admins not yet awake, > so can't tell you what's up. No worries, I will just keep using what I have previously fetched. -- Cheers, Stephen Rothwell pgpiFHnhhCRAa.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On 2019-05-21 9:52 a.m., Daniel Vetter wrote: > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote: >> On Mon, 20 May 2019 18:11:07 +0200 >> Daniel Vetter wrote: >> >>> There's also a fairly easy fix for that -modesetting issue: We don't >>> expose atomic if the compositor has a process name of "Xserver". Brutal, >>> but gets the job done. Once X is fixed, we can give a new "I'm not totally >>> broken anymore" interface to get back at atomic. >> >> You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you >> check against the process issuing ioctl by ioctl, or the process that >> opened the device? Which would be logind? What about DRM leasing? ... > > In the Get/SetCaps ioctl we can do the check, which is called from X, > not logind. We just need some way to tell -modesetting apart from > everything else, and luckily there's not any other atomic X drivers. Not yet... As for a "I'm not totally broken anymore" interface, we did something like that (though kind of in the other direction) with RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to be added, because the former claimed acceleration was "working" in cases where it really wasn't... That kind of thing could become ugly in the long run if other Xorg driver start using atomic, and they'll inevitably be broken in different ways. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm: Fixed doc warnings in drm uapi header
On Thu, May 30, 2019 at 01:29:03AM +0530, Uma Shankar wrote:
> Fixed doc warnings in drm uapi header. All the UAPI
> structures are now documented in kernel doc.
>
> Signed-off-by: Uma Shankar
Applied, thanks for the patch.
Long-term there's obviously a lot more to do here, but this at least gets
us started.
Btw I think it'd be good to split out the "add new uapi ioctl structures
section" part from the previous patch, and merge that separately.
Thanks, Daniel
> ---
> include/uapi/drm/drm_mode.h | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5d3964f..02b2a2b 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -861,6 +861,10 @@ struct drm_format_modifier {
> };
>
> /**
> + * struct drm_mode_create_blob - Create New block property
> + * @data: Pointer to data to copy.
> + * @length: Length of data to copy.
> + * @blob_id: new property ID.
> * Create a new 'blob' data property, copying length bytes from data pointer,
> * and returning new blob ID.
> */
> @@ -874,6 +878,8 @@ struct drm_mode_create_blob {
> };
>
> /**
> + * struct drm_mode_destroy_blob - Destroy user blob
> + * @blob_id: blob_id to destroy
> * Destroy a user-created blob property.
> */
> struct drm_mode_destroy_blob {
> @@ -881,6 +887,12 @@ struct drm_mode_destroy_blob {
> };
>
> /**
> + * struct drm_mode_create_lease - Create lease
> + * @object_ids: Pointer to array of object ids.
> + * @object_count: Number of object ids.
> + * @flags: flags for new FD.
> + * @lessee_id: unique identifier for lessee.
> + * @fd: file descriptor to new drm_master file.
> * Lease mode resources, creating another drm_master.
> */
> struct drm_mode_create_lease {
> @@ -898,6 +910,10 @@ struct drm_mode_create_lease {
> };
>
> /**
> + * struct drm_mode_list_lessees - List lessees
> + * @count_lessees: Number of lessees.
> + * @pad: pad.
> + * @lessees_ptr: Pointer to lessess.
> * List lesses from a drm_master
> */
> struct drm_mode_list_lessees {
> @@ -918,6 +934,10 @@ struct drm_mode_list_lessees {
> };
>
> /**
> + * struct drm_mode_get_lease - Get Lease
> + * @count_objects: Number of leased objects.
> + * @pad: pad.
> + * @objects_ptr: Pointer to objects.
> * Get leased objects
> */
> struct drm_mode_get_lease {
> @@ -938,6 +958,8 @@ struct drm_mode_get_lease {
> };
>
> /**
> + * struct drm_mode_revoke_lease - Revoke lease
> + * @lessee_id: Unique ID of lessee.
> * Revoke lease
> */
> struct drm_mode_revoke_lease {
> --
> 1.9.1
>
--
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 4/4] video/hdmi: Dropped static functions from kernel doc
On Thu, May 30, 2019 at 01:29:04AM +0530, Uma Shankar wrote: > Dropped static functions from kernel documentation. > > Suggested-by: Daniel Vetter > Signed-off-by: Uma Shankar > --- > drivers/video/hdmi.c | 32 > 1 file changed, 16 insertions(+), 16 deletions(-) > > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c > index b99ba01..72c654b 100644 > --- a/drivers/video/hdmi.c > +++ b/drivers/video/hdmi.c > @@ -1191,11 +1191,11 @@ static const char *hdmi_nups_get_name(enum hdmi_nups > nups) > return "Invalid"; > } > > -/** > +/* > * hdmi_avi_infoframe_log() - log info of HDMI AVI infoframe > - * @level: logging level > - * @dev: device > - * @frame: HDMI AVI infoframe > + * level: logging level > + * dev: device > + * frame: HDMI AVI infoframe > */ > static void hdmi_avi_infoframe_log(const char *level, > struct device *dev, > @@ -1268,11 +1268,11 @@ static const char *hdmi_spd_sdi_get_name(enum > hdmi_spd_sdi sdi) > return "Reserved"; > } > > -/** > +/* > * hdmi_spd_infoframe_log() - log info of HDMI SPD infoframe > - * @level: logging level > - * @dev: device > - * @frame: HDMI SPD infoframe > + * level: logging level > + * dev: device > + * frame: HDMI SPD infoframe > */ For internal functions I think there's not really any value in documenting this. The variable names are obvious enough. Imo better to ditch this outright. -Daniel > static void hdmi_spd_infoframe_log(const char *level, > struct device *dev, > @@ -1404,11 +1404,11 @@ static void hdmi_spd_infoframe_log(const char *level, > return "Reserved"; > } > > -/** > +/* > * hdmi_audio_infoframe_log() - log info of HDMI AUDIO infoframe > - * @level: logging level > - * @dev: device > - * @frame: HDMI AUDIO infoframe > + * level: logging level > + * dev: device > + * frame: HDMI AUDIO infoframe > */ > static void hdmi_audio_infoframe_log(const char *level, >struct device *dev, > @@ -1437,11 +1437,11 @@ static void hdmi_audio_infoframe_log(const char > *level, > frame->downmix_inhibit ? "Yes" : "No"); > } > > -/** > +/* > * hdmi_drm_infoframe_log() - log info of HDMI DRM infoframe > - * @level: logging level > - * @dev: device > - * @frame: HDMI DRM infoframe > + * level: logging level > + * dev: device > + * frame: HDMI DRM infoframe > */ > static void hdmi_drm_infoframe_log(const char *level, > struct device *dev, > -- > 1.9.1 > -- 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 2/4] drm: Fix docbook warnings in hdr metadata helper structures
On Thu, May 30, 2019 at 01:29:02AM +0530, Uma Shankar wrote: > Fixes the following warnings: > ./include/drm/drm_mode_config.h:841: warning: Incorrect use of > kernel-doc format: * hdr_output_metadata_property: Connector > property containing hdr > ./include/drm/drm_mode_config.h:918: warning: Function parameter or member > 'hdr_output_metadata_property' not described in 'drm_mode_config' > ./include/drm/drm_connector.h:1251: warning: Function parameter or member > 'hdr_output_metadata' not described in 'drm_connector' > ./include/drm/drm_connector.h:1251: warning: Function parameter or member > 'hdr_sink_metadata' not described in 'drm_connector' > > Also adds some property documentation for HDR Metadata Connector > Property in connector property create function. > > v2: Fixed Sean Paul's review comments. > > v3: Fixed Daniel Vetter's review comments, added the UAPI structure > definition section in kernel docs. > > Cc: Shashank Sharma > Cc: Ville Syrjälä > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: Bartlomiej Zolnierkiewicz > Cc: "Ville Syrjälä" > Cc: Hans Verkuil > Cc: dri-de...@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Reviewed-by: Sean Paul > Signed-off-by: Uma Shankar > --- > Documentation/gpu/drm-uapi.rst | 9 + > drivers/gpu/drm/drm_connector.c | 31 +++ > include/drm/drm_connector.h | 1 + > include/drm/drm_mode_config.h | 4 ++-- > include/linux/hdmi.h| 1 + > include/uapi/drm/drm_mode.h | 37 - > 6 files changed, 80 insertions(+), 3 deletions(-) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 05874d0..6b39e2c 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -329,3 +329,12 @@ DRM_IOCTL_MODESET_CTL > mode setting, since on many devices the vertical blank counter is > reset to 0 at some point during modeset. Modern drivers should not > call this any more since with kernel mode setting it is a no-op. > + > +Userspace API Structures > + > + > +.. kernel-doc:: include/uapi/drm/drm_mode.h > + :doc: overview > + > +.. kernel-doc:: include/uapi/drm/drm_mode.h > + :internal: > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index c9ac8b9..6a93527 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -956,6 +956,37 @@ int drm_display_info_set_bus_formats(struct > drm_display_info *info, > * is no longer protected and userspace should take appropriate action > * (whatever that might be). > * > + * HDR_OUTPUT_METADATA: > + * Connector property to enable userspace to send HDR Metadata to > + * driver. This metadata is based on the composition and blending > + * policies decided by user, taking into account the hardware and > + * sink capabilities. The driver gets this metadata and creates a > + * Dynamic Range and Mastering Infoframe (DRM) in case of HDMI, > + * SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then > + * sent to sink. This notifies the sink of the upcoming frame's Color > + * Encoding and Luminance parameters. > + * > + * Userspace first need to detect the HDR capabilities of sink by > + * reading and parsing the EDID. Details of HDR metadata for HDMI > + * are added in CTA 861.G spec. For DP , its defined in VESA DP > + * Standard v1.4. It needs to then get the metadata information > + * of the video/game/app content which are encoded in HDR (basically > + * using HDR transfer functions). With this information it needs to > + * decide on a blending policy and compose the relevant > + * layers/overlays into a common format. Once this blending is done, > + * userspace will be aware of the metadata of the composed frame to > + * be send to sink. It then uses this property to communicate this > + * metadata to driver which then make a Infoframe packet and sends > + * to sink based on the type of encoder connected. > + * > + * Userspace will be responsible to do Tone mapping operation in case: > + * - Some layers are HDR and others are SDR > + * - HDR layers luminance is not same as sink > + * It will even need to do colorspace conversion and get all layers > + * to one common colorspace for blending. It can use either GL, Media > + * or display engine to get this done based on the capabilties of the > + * associated hardware. I think it'd be good to add 1-2 sentences here about what this looks like for the driver side. E.g. which function drivers need to call to set up hdr, how to get at the metadata and whether there's any helpers for these. Here I'd point at hdr_output_metadata, hdr_sink_metadata, and drm_add_display_info() for filling in the former. I think with that this is a solid doc patch. > + * >
[Intel-gfx] ✓ Fi.CI.BAT: success for i915 vgpu PV to improve vgpu performance
== Series Details ==
Series: i915 vgpu PV to improve vgpu performance
URL : https://patchwork.freedesktop.org/series/61493/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6179 -> Patchwork_13156
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/
Known issues
Here are the changes found in Patchwork_13156 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_basic@bad-close:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-icl-u2/igt@gem_ba...@bad-close.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/fi-icl-u2/igt@gem_ba...@bad-close.html
* igt@gem_ctx_exec@basic:
- fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-icl-y/igt@gem_ctx_e...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/fi-icl-y/igt@gem_ctx_e...@basic.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][5] -> [FAIL][6] ([fdo#103167])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_basic@create-close:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-icl-u3/igt@gem_ba...@create-close.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/fi-icl-u3/igt@gem_ba...@create-close.html
* {igt@i915_selftest@live_blt}:
- fi-skl-iommu: [INCOMPLETE][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-skl-iommu/igt@i915_selftest@live_blt.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/fi-skl-iommu/igt@i915_selftest@live_blt.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-bxt-dsi: [INCOMPLETE][11] ([fdo#103927]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-bxt-dsi/igt@kms_f...@basic-flip-vs-modeset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/fi-bxt-dsi/igt@kms_f...@basic-flip-vs-modeset.html
{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#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
Participating hosts (51 -> 46)
--
Additional (2): fi-bsw-n3050 fi-pnv-d510
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-byt-clapper
fi-kbl-7560u fi-icl-dsi fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6179 -> Patchwork_13156
CI_DRM_6179: 9a30aa526df5b04037ec56abbe568efed126d7e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5026: 4108c74c3b15460de25ab989f4e2031594559dfc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13156: fa6226cbb01317edd7fc30b64ab414f092c05ef3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fa6226cbb013 drm/i915/gvt: GVTg support context submission pv optimization
3626e6547796 drm/i915/gvt: GVTg support ppgtt pv optimization
4becca4775d1 drm/i915/gvt: GVTg handle shared_page setup
40ce001e1ce8 drm/i915/gvt: GVTg handle pv_caps PVINFO register
f1b3f498ebea drm/i915: vgpu context submission pv optimization
61bce586be7a drm/i915: vgpu ppgtt update pv optimization
8f6296420e40 drm/i915: vgpu shared memory setup for pv optimization
b84d8b472a53 drm/i915: introduced vgpu pv capability
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13156/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm: Drop a redundant unused variable
On Thu, May 30, 2019 at 01:29:01AM +0530, Uma Shankar wrote:
> Drop a redundant and unused variable "hdr_output_metadata" from
> drm_connector.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Uma Shankar
For next time around: Please add Fixes: lines to indicate which already
merged commit you're improving.
Patch merged, thanks.
-Daniel
> ---
> include/drm/drm_connector.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index f8f4003..5476561 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1244,8 +1244,6 @@ struct drm_connector {
>*/
> struct llist_node free_node;
>
> - /* HDR metdata */
> - struct hdr_output_metadata hdr_output_metadata;
> struct hdr_sink_metadata hdr_sink_metadata;
> };
>
> --
> 1.9.1
>
--
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
5.2: display corruption on X60, X220
Hi! In recent kernels (5.2.0-rc1-next-20190522, 5.2-rc2) I'm getting display corruption in X. Usually in terminals, but also in title bars etc. Black areas with white lines in them, usually... Same configuration worked properly in ... probably 4.19? Then I got some graphics-crashes on X220 that prevented me from testing :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [Intel-gfx] linux-next: unable to fetch the drm-intel-fixes tree
On Mon, Jun 03, 2019 at 11:04:03AM +1000, Stephen Rothwell wrote: > Hi Stephen, > > On Mon, 3 Jun 2019 08:20:51 +1000 Stephen Rothwell > wrote: > > > > Hi all, > > > > Trying to fetch the drm-intel-fixes tree today gives me this error: > > > > - > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > - > > > > The same for drm-misc-fixes, drm-intel and drm-misc. These are all > > hosted on git://anongit.freedesktop.org/ . > > Also the drm-tegra tree. drm.git too I guess? But yeah fd.o anongit keeled over over the w/e :-( Admins not yet awake, so can't tell you what's up. -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] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
On Thu, May 30, 2019 at 03:31:05PM +0200, Janusz Krzysztofik wrote:
> In order to support driver hot unbind, some cleanup operations, now
> performed on PCI driver remove, must be called later, after all device
> file descriptors are closed.
>
> Split out those operations from the tail of pci_driver.remove()
> callback and put them into drm_driver.release() which is called as soon
> as all references to the driver are put. As a result, those cleanups
> will be now run on last drm_dev_put(), either still called from
> pci_driver.remove() if all device file descriptors are already closed,
> or on last drm_release() file operation.
>
> Signed-off-by: Janusz Krzysztofik
> Reviewed-by: Chris Wilson
> ---
> Changelog:
> v1 -> v2:
> - defer intel_engines_cleanup() as well. (Chris)
Just an aside, we generally keep the changelog in the commit message on
dri-devel, it's occasionally useful to reference in the future. Yes that's
different from some other areas of the kernel.
-Daniel
>
> drivers/gpu/drm/i915/i915_drv.c | 17 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> 3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 83d2eb9e74cb..8be69f84eb6d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>
> cleanup_gem:
> i915_gem_suspend(dev_priv);
> + i915_gem_fini_hw(dev_priv);
> i915_gem_fini(dev_priv);
> cleanup_modeset:
> intel_modeset_cleanup(dev);
> @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct
> drm_i915_private *dev_priv)
> pci_disable_msi(pdev);
>
> pm_qos_remove_request(_priv->pm_qos);
> - i915_ggtt_cleanup_hw(dev_priv);
> }
>
> /**
> @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>
> out_cleanup_hw:
> i915_driver_cleanup_hw(dev_priv);
> + i915_ggtt_cleanup_hw(dev_priv);
> out_cleanup_mmio:
> i915_driver_cleanup_mmio(dev_priv);
> out_runtime_pm_put:
> @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
> cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> i915_reset_error_state(dev_priv);
>
> - i915_gem_fini(dev_priv);
> + i915_gem_fini_hw(dev_priv);
>
> intel_power_domains_fini_hw(dev_priv);
>
> i915_driver_cleanup_hw(dev_priv);
> - i915_driver_cleanup_mmio(dev_priv);
>
> enable_rpm_wakeref_asserts(dev_priv);
> - intel_runtime_pm_cleanup(dev_priv);
> }
>
> static void i915_driver_release(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
>
> + disable_rpm_wakeref_asserts(dev_priv);
> +
> + i915_gem_fini(dev_priv);
> +
> + i915_ggtt_cleanup_hw(dev_priv);
> + i915_driver_cleanup_mmio(dev_priv);
> +
> + enable_rpm_wakeref_asserts(dev_priv);
> + intel_runtime_pm_cleanup(dev_priv);
> +
> i915_driver_cleanup_early(dev_priv);
> i915_driver_destroy(dev_priv);
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a2664ea1395b..d08e7bd83544 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private *i915);
> int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
> int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
> void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
> +void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
> void i915_gem_fini(struct drm_i915_private *dev_priv);
> int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
> unsigned int flags, long timeout);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7cafd5612f71..20d3f7532cef 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> return ret;
> }
>
> -void i915_gem_fini(struct drm_i915_private *dev_priv)
> +void i915_gem_fini_hw(struct drm_i915_private *dev_priv)
> {
> GEM_BUG_ON(dev_priv->gt.awake);
>
> @@ -4680,6 +4680,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
> mutex_lock(_priv->drm.struct_mutex);
> intel_uc_fini_hw(dev_priv);
> intel_uc_fini(dev_priv);
> + mutex_unlock(_priv->drm.struct_mutex);
> +
> + i915_gem_drain_freed_objects(dev_priv);
> +}
> +
> +void i915_gem_fini(struct drm_i915_private *dev_priv)
> +{
> + mutex_lock(_priv->drm.struct_mutex);
> intel_engines_cleanup(dev_priv);
> i915_gem_contexts_fini(dev_priv);
> i915_gem_fini_scratch(dev_priv);
> --
> 2.21.0
>
--
Daniel Vetter
Software Engineer,
Re: [Intel-gfx] [RFC PATCH 1/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
On Thu, May 30, 2019 at 10:40:09AM +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-30 10:24:26)
> > In order to support driver hot unbind, some cleanup operations, now
> > performed on PCI driver remove, must be called later, after all device
> > file descriptors are closed.
> >
> > Split out those operations from the tail of pci_driver.remove()
> > callback and put them into drm_driver.release() which is called as soon
> > as all references to the driver are put. As a result, those cleanups
> > will be now run on last drm_dev_put(), either still called from
> > pci_driver.remove() if all device file descriptors are already closed,
> > or on last drm_release() file operation.
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 17 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_gem.c | 10 +-
> > 3 files changed, 23 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 83d2eb9e74cb..8be69f84eb6d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device
> > *dev)
> >
> > cleanup_gem:
> > i915_gem_suspend(dev_priv);
> > + i915_gem_fini_hw(dev_priv);
> > i915_gem_fini(dev_priv);
> > cleanup_modeset:
> > intel_modeset_cleanup(dev);
> > @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct
> > drm_i915_private *dev_priv)
> > pci_disable_msi(pdev);
> >
> > pm_qos_remove_request(_priv->pm_qos);
> > - i915_ggtt_cleanup_hw(dev_priv);
> > }
> >
> > /**
> > @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const
> > struct pci_device_id *ent)
>
> Would it make sense to rename load/unload from the legacy drm stubs over
> to match the pci entry points?
+1 on that rename, load/unload is really terribly confusing and has
horrible semantics in the dri1 shadow attach world ...
-Daniel
>
> > out_cleanup_hw:
> > i915_driver_cleanup_hw(dev_priv);
> > + i915_ggtt_cleanup_hw(dev_priv);
> > out_cleanup_mmio:
> > i915_driver_cleanup_mmio(dev_priv);
> > out_runtime_pm_put:
> > @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev)
> > cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
> > i915_reset_error_state(dev_priv);
> >
> > - i915_gem_fini(dev_priv);
> > + i915_gem_fini_hw(dev_priv);
> >
> > intel_power_domains_fini_hw(dev_priv);
> >
> > i915_driver_cleanup_hw(dev_priv);
> > - i915_driver_cleanup_mmio(dev_priv);
> >
> > enable_rpm_wakeref_asserts(dev_priv);
> > - intel_runtime_pm_cleanup(dev_priv);
> > }
> >
> > static void i915_driver_release(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >
> > + disable_rpm_wakeref_asserts(dev_priv);
> > +
> > + i915_gem_fini(dev_priv);
> > +
> > + i915_ggtt_cleanup_hw(dev_priv);
> > + i915_driver_cleanup_mmio(dev_priv);
> > +
> > + enable_rpm_wakeref_asserts(dev_priv);
> > + intel_runtime_pm_cleanup(dev_priv);
>
> We should really propagate the release nomenclature down and replace our
> mixed fini/cleanup. Consistency is helpful when trying to work out which
> phase the code is in.
>
> > i915_driver_cleanup_early(dev_priv);
> > i915_driver_destroy(dev_priv);
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index a2664ea1395b..d08e7bd83544 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private
> > *i915);
> > int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
> > int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
> > void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
> > +void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
> > void i915_gem_fini(struct drm_i915_private *dev_priv);
> > int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
> >unsigned int flags, long timeout);
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 7cafd5612f71..c6a8e665a6ba 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> > return ret;
> > }
> >
> > -void i915_gem_fini(struct drm_i915_private *dev_priv)
> > +void i915_gem_fini_hw(struct drm_i915_private *dev_priv)
> > {
> > GEM_BUG_ON(dev_priv->gt.awake);
> >
> > @@ -4681,6 +4681,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
> > intel_uc_fini_hw(dev_priv);
> >
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915 vgpu PV to improve vgpu performance
== Series Details == Series: i915 vgpu PV to improve vgpu performance URL : https://patchwork.freedesktop.org/series/61493/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: introduced vgpu pv capability Okay! Commit: drm/i915: vgpu shared memory setup for pv optimization Okay! Commit: drm/i915: vgpu ppgtt update pv optimization Okay! Commit: drm/i915: vgpu context submission pv optimization +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915/gvt: GVTg handle pv_caps PVINFO register Okay! Commit: drm/i915/gvt: GVTg handle shared_page setup Okay! Commit: drm/i915/gvt: GVTg support ppgtt pv optimization +./include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:666:13: warning: call with no type! Commit: drm/i915/gvt: GVTg support context submission pv optimization Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915 vgpu PV to improve vgpu performance
== Series Details ==
Series: i915 vgpu PV to improve vgpu performance
URL : https://patchwork.freedesktop.org/series/61493/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b84d8b472a53 drm/i915: introduced vgpu pv capability
-:90: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#90: FILE: drivers/gpu/drm/i915/i915_vgpu.c:89:
+ DRM_INFO("Virtual GPU for Intel GVT-g detected with pv_caps 0x%x.\n",
+ dev_priv->vgpu.pv_caps);
total: 0 errors, 0 warnings, 1 checks, 99 lines checked
8f6296420e40 drm/i915: vgpu shared memory setup for pv optimization
-:113: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#113: FILE: drivers/gpu/drm/i915/i915_vgpu.c:318:
+ __raw_uncore_write32(uncore, vgtif_reg(g2v_notify),
+ VGT_G2V_SHARED_PAGE_SETUP);
total: 0 errors, 0 warnings, 1 checks, 132 lines checked
61bce586be7a drm/i915: vgpu ppgtt update pv optimization
-:41: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
previous line
#41: FILE: drivers/gpu/drm/i915/i915_gem.c:1511:
+ if ((intel_vgpu_active(dev_priv) && !intel_vgpu_has_huge_gtt(dev_priv))
+ || intel_vgpu_enabled_pv_caps(dev_priv, PV_PPGTT_UPDATE))
-:55: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#55: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:930:
+void gen8_ppgtt_clear_4lvl(struct i915_address_space *vm,
u64 start, u64 length)
-:64: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#64: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:1169:
+void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
struct i915_vma *vma,
-:73: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#73: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:1451:
+int gen8_ppgtt_alloc_4lvl(struct i915_address_space *vm,
u64 start, u64 length)
-:95: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#95: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:650:
+void gen8_ppgtt_clear_4lvl(struct i915_address_space *vm,
+ u64 start, u64 length);
-:97: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#97: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:652:
+void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
+ struct i915_vma *vma,
-:100: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#100: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:655:
+int gen8_ppgtt_alloc_4lvl(struct i915_address_space *vm,
+ u64 start, u64 length);
-:138: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#138: FILE: drivers/gpu/drm/i915/i915_vgpu.c:296:
+static void gen8_ppgtt_clear_4lvl_pv(struct i915_address_space *vm,
+ u64 start, u64 length)
-:157: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#157: FILE: drivers/gpu/drm/i915/i915_vgpu.c:315:
+static void gen8_ppgtt_insert_4lvl_pv(struct i915_address_space *vm,
+ struct i915_vma *vma,
-:176: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#176: FILE: drivers/gpu/drm/i915/i915_vgpu.c:334:
+static int gen8_ppgtt_alloc_4lvl_pv(struct i915_address_space *vm,
+u64 start, u64 length)
-:203: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#203: FILE: drivers/gpu/drm/i915/i915_vgpu.c:361:
+void intel_vgpu_config_pv_caps(struct drm_i915_private *dev_priv,
+ enum pv_caps cap, void *data)
-:245: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#245: FILE: drivers/gpu/drm/i915/i915_vgpu.h:91:
+intel_vgpu_enabled_pv_caps(struct drm_i915_private *dev_priv,
+ enum pv_caps cap)
-:248: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
previous line
#248: FILE: drivers/gpu/drm/i915/i915_vgpu.h:94:
+ return intel_vgpu_active(dev_priv) && intel_vgpu_has_pv_caps(dev_priv)
+ && (dev_priv->vgpu.pv_caps & cap);
-:257: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#257: FILE: drivers/gpu/drm/i915/i915_vgpu.h:103:
+void intel_vgpu_config_pv_caps(struct drm_i915_private *dev_priv,
+ enum pv_caps cap, void *data);
total: 0 errors, 0 warnings, 14 checks, 193 lines checked
f1b3f498ebea drm/i915: vgpu context submission pv optimization
-:132: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#132:
new file mode 100644
-:152: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV)
#152: FILE: drivers/gpu/drm/i915/intel_pv_submission.c:16:
+ reg_state[CTX_RING_TAIL+1] = intel_ring_set_tail(rq->ring, rq->tail);
^
total: 0 errors, 1 warnings, 1 checks, 237 lines checked
40ce001e1ce8 drm/i915/gvt: GVTg
[Intel-gfx] [PATCH v6 8/8] drm/i915/gvt: GVTg support context submission pv optimization
implemented context submission pv optimizaiton within GVTg.
GVTg to read context submission data (elsp_data) from the shared_page
directly without trap cost and eliminate execlist HW behavior emulation
without injecting context switch interrupt to guest under PV
submisison mechanism.
v0: RFC.
v1: rebase.
v2: rebase.
v3: report pv context submission cap and handle VGT_G2V_ELSP_SUBMIT
g2v pv notification.
v4: eliminate execlist HW emulation and don't inject context switch
interrupt to guest under PV submisison mechanism.
v5: rebase.
v6: rebase.
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/execlist.c | 6 ++
drivers/gpu/drm/i915/gvt/handlers.c | 29 -
drivers/gpu/drm/i915/gvt/vgpu.c | 1 +
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c
b/drivers/gpu/drm/i915/gvt/execlist.c
index f21b8fb..e52bfd6 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -382,6 +382,9 @@ static int prepare_execlist_workload(struct
intel_vgpu_workload *workload)
int ring_id = workload->ring_id;
int ret;
+ if (VGPU_PVCAP(vgpu, PV_SUBMISSION))
+ return 0;
+
if (!workload->emulate_schedule_in)
return 0;
@@ -429,6 +432,9 @@ static int complete_execlist_workload(struct
intel_vgpu_workload *workload)
goto out;
}
+ if (VGPU_PVCAP(vgpu, PV_SUBMISSION))
+ goto out;
+
ret = emulate_execlist_ctx_schedule_out(execlist, >ctx_desc);
out:
intel_vgpu_unpin_mm(workload->shadow_mm);
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 1e09c23..9cff9396 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1692,6 +1692,31 @@ static int mmio_read_from_hw(struct intel_vgpu *vgpu,
return intel_vgpu_default_mmio_read(vgpu, offset, p_data, bytes);
}
+static int handle_pv_submission(struct intel_vgpu *vgpu, int ring_id)
+{
+ struct intel_vgpu_execlist *execlist;
+ u32 hw_id = vgpu->gvt->dev_priv->engine[ring_id]->hw_id;
+ u32 pv_elsp_off = offsetof(struct gvt_shared_page, buf.pv_elsp);
+ u32 submitted_off = offsetof(struct gvt_shared_page, buf.submitted);
+ bool submitted = true;
+ int ret;
+
+ execlist = >submission.execlist[ring_id];
+
+ pv_elsp_off += hw_id * sizeof(struct pv_submission);
+ if (intel_gvt_read_shared_page(vgpu, pv_elsp_off,
+ >elsp_dwords.data, sizeof(struct pv_submission)))
+ return -EINVAL;
+
+ ret = intel_vgpu_submit_execlist(vgpu, ring_id);
+ if (ret)
+ submitted = false;
+
+ submitted_off += hw_id;
+ ret = intel_gvt_write_shared_page(vgpu, submitted_off, , 1);
+ return ret;
+}
+
static int elsp_mmio_write(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
@@ -1703,8 +1728,10 @@ static int elsp_mmio_write(struct intel_vgpu *vgpu,
unsigned int offset,
if (WARN_ON(ring_id < 0 || ring_id >= I915_NUM_ENGINES))
return -EINVAL;
- execlist = >submission.execlist[ring_id];
+ if (VGPU_PVCAP(vgpu, PV_SUBMISSION) && VGT_G2V_PV_SUBMISSION == data)
+ return handle_pv_submission(vgpu, ring_id);
+ execlist = >submission.execlist[ring_id];
execlist->elsp_dwords.data[3 - execlist->elsp_dwords.index] = data;
if (execlist->elsp_dwords.index == 3) {
ret = intel_vgpu_submit_execlist(vgpu, ring_id);
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 57eaf56..debdb88 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -51,6 +51,7 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
if (!intel_vtd_active())
vgpu_vreg_t(vgpu, vgtif_reg(pv_caps)) = PV_PPGTT_UPDATE;
+ vgpu_vreg_t(vgpu, vgtif_reg(pv_caps)) |= PV_SUBMISSION;
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base)) =
vgpu_aperture_gmadr_base(vgpu);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
