[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: split GVT as separated module
== Series Details == Series: drm/i915: split GVT as separated module URL : https://patchwork.freedesktop.org/series/49605/ State : failure == Summary == Applying: drm/i915: split GVT as separated module .git/rebase-apply/patch:102: trailing whitespace. .git/rebase-apply/patch:111: trailing whitespace. .git/rebase-apply/patch:196: trailing whitespace. warning: 3 lines add whitespace errors. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_gem.c M drivers/gpu/drm/i915/i915_gem_context.c M drivers/gpu/drm/i915/i915_gem_gtt.c M drivers/gpu/drm/i915/intel_ringbuffer.c M drivers/gpu/drm/i915/intel_uncore.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_uncore.c Auto-merging drivers/gpu/drm/i915/intel_ringbuffer.c Removing drivers/gpu/drm/i915/intel_gvt.h Removing drivers/gpu/drm/i915/intel_gvt.c Auto-merging drivers/gpu/drm/i915/i915_gem_gtt.c Auto-merging drivers/gpu/drm/i915/i915_gem_context.c Auto-merging drivers/gpu/drm/i915/i915_gem.c Auto-merging drivers/gpu/drm/i915/i915_drv.h Auto-merging drivers/gpu/drm/i915/i915_drv.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.c error: Failed to merge in the changes. Patch failed at 0001 drm/i915: split GVT as separated module Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH] drm/i915: split GVT as separated module
Joonas requested if we could move GVT into separated module.
Then obvious requirement is to export i915 functions that GVT
currently use. So this one blindly trys to export all of them
for people to review. Some of them are already only for GVT now.
But more others might need more thinking on what may better fit.
With separated module, this also changes how GVT module loads with
i915. Initial attempt was to request loading GVT module when i915
init, but as for dependence issue that couldn't work. Then I think we
should just enable GVT when user request to load it. So removed GVT
init from i915, also 'enable_gvt' parameter and call GVT init function
when module load. But for GVT init, we still need struct
drm_i915_private for target device, so this just hacks it to
export..Maybe we can add some interface to get that from i915?
Another problem for separated module is that GVT wants a clean
initial MMIO snapshot for vGPU default state. Now in upstream we
will take that snapshot during GVT init. For separated module, we
might need i915 to dump it for GVT then GVT could get it when init.
This part of change for i915 and GVT is not included in this patch yet.
Cc: Joonas Lahtinen
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/Kconfig | 2 +-
drivers/gpu/drm/i915/Makefile | 3 -
drivers/gpu/drm/i915/gvt/Makefile | 3 +-
drivers/gpu/drm/i915/gvt/gvt.c| 40 +-
drivers/gpu/drm/i915/gvt/gvt.h| 3 +
drivers/gpu/drm/i915/i915_drv.c | 17 +--
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_gem.c | 11 ++
drivers/gpu/drm/i915/i915_gem_context.c | 2 +
drivers/gpu/drm/i915/i915_gem_dmabuf.c| 1 +
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 2 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
drivers/gpu/drm/i915/i915_params.c| 3 -
drivers/gpu/drm/i915/i915_params.h| 3 +-
drivers/gpu/drm/i915/i915_request.c | 3 +
drivers/gpu/drm/i915/i915_vma.c | 2 +
drivers/gpu/drm/i915/intel_gvt.c | 143 --
drivers/gpu/drm/i915/intel_gvt.h | 50
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +
drivers/gpu/drm/i915/intel_uncore.c | 3 +
21 files changed, 82 insertions(+), 219 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/intel_gvt.c
delete mode 100644 drivers/gpu/drm/i915/intel_gvt.h
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 33a458b7f1fc..a05261cabf53 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -96,7 +96,7 @@ config DRM_I915_USERPTR
If in doubt, say "Y".
config DRM_I915_GVT
-bool "Enable Intel GVT-g graphics virtualization host support"
+tristate "Enable Intel GVT-g graphics virtualization host support"
depends on DRM_I915
depends on 64BIT
default n
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5794f102f9b8..b3acd431c35e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -182,10 +182,7 @@ i915-y += i915_perf.o \
i915_oa_cnl.o \
i915_oa_icl.o
-ifeq ($(CONFIG_DRM_I915_GVT),y)
-i915-y += intel_gvt.o
include $(src)/gvt/Makefile
-endif
# LPE Audio for VLV and CHT
i915-y += intel_lpe_audio.o
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index b016dc753db9..a2e1de745d63 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -6,5 +6,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
trace_points.o firmware.o \
fb_decoder.o dmabuf.o page_track.o
ccflags-y += -I$(src) -I$(src)/$(GVT_DIR)
-i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
+i915_gvt-y := $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
+obj-$(CONFIG_DRM_I915_GVT) += i915_gvt.o
obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 6ef5a7fc70df..2a6bbc89e20f 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -30,10 +30,11 @@
*
*/
+#include
#include
#include
#include
-
+#include
#include "i915_drv.h"
#include "gvt.h"
#include
@@ -228,7 +229,6 @@ int intel_gvt_init_host(void)
gvt_dbg_core("Running with hypervisor %s in host mode\n",
supported_hypervisors[intel_gvt_host.hypervisor_type]);
-
intel_gvt_host.initialized = true;
return 0;
}
@@ -467,6 +467,42 @@ int intel_gvt_init_device(struct drm_i915_private
*dev_priv)
return ret;
}
+static int __init i915_gvt_init(void)
+{
+ if (!try_module_get(i915_priv_export->drm.dev->driver->owner)) {
+ gvt_err("get i915 modul
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode
== Series Details == Series: series starting with [v2,1/4] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode URL : https://patchwork.freedesktop.org/series/49596/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813_full -> Patchwork_10163_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10163_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10163 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10163: c20815b7fb4e8a7f36d8f318b5b5090b70ee39ac @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10163/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Balance prepare_fb/cleanup_fb
== Series Details == Series: series starting with [1/2] drm/i915: Balance prepare_fb/cleanup_fb URL : https://patchwork.freedesktop.org/series/49579/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813_full -> Patchwork_10162_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10162_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363, fdo#102887) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10162 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10162: 1cd88e7b6658c837ba56720021f228850b390719 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10162/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915, HDMI/DP audio with multiple monitors
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, September 13, 2018 1:47 AM
>To: Bruno Prémont
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Takashi
>Iwai ; alsa-de...@alsa-project.org; Yang, Libin
>
>Subject: Re: i915, HDMI/DP audio with multiple monitors
>
>On Tue, Sep 11, 2018 at 03:50:13PM +0200, Bruno Prémont wrote:
>> Hi,
>>
>> I have a system with multiple monitors and would like to send
>> notification sounds to the monitor on which corresponding window is
>> visible.
This requirement is reasonable :)
>>
>> For a workstation and a tiny computer things look different:
>> - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz):
>> 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon
>> E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
>> [8086:0412] (rev 06)
>> 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th
>> Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06)
>> 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series
>> Chipset High Definition Audio Controller [8086:8c20] (rev 04)
>>
>> Here alsa show me two cards:
>> - HDA Intel PCH (Realtek ALC671)
>> - HDA Intel HDMI (Intel Generic)
>>
>> List of PLAYBACK Hardware Devices card 0: HDMI [HDA Intel
>> HDMI], device 3: Generic Digital [Generic Digital]
>>Subdevices: 1/1
>>Subdevice #0: subdevice #0
>
>There should normally be multiple HDMI devices (one for each HDMI/DP
>connector more or less). Eg. my hsw shows:
>
>card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
>card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
>
>Looking at the hda_codec.c we see:
> static int audio_idx[HDA_PCM_NTYPES][5] = { ...
>[HDA_PCM_TYPE_HDMI] = { 3, 7, 8, 9, -1 },
>
>So you always get those device numbers, but I don't see an immediate
>relationship between those and the pin numbers (which do have some kind of
>relationship with the HDMI/DP port). I guess if they always get registered in
>order of the pin numbers then those would translate to 3 == port B, 7 == port
>C, etc. And after that the problem is figuring out which port is related to
>which
>connector, for which we have nothing at the moment.
>
>I suppose the ideal solution might be to have a sysfs symlink (or
>something) to connect the two together.
>
>But then there's MST where I think the pcm device correlates with the crtc
>rather than the connector. Maybe. I can't remember anymore, and I'm not
>sure it even works (I've recently heard people saying it doesn't).
Ville is right. For NON-MST (PCM static assignment), the PCM & PORT
mapping is simple and static.
For DP-MST (PCM dynamic assignment), it is a little complicated. In HDMI
audio driver, the per_pin saves all the information.
1. PORT info: per_pin->pin_nid is related to the PORT information.
The mapping information is showed in hdmi audio driver function
intel_pin_eld_notify().
2. PCM info: we can get the PCM with per_pin->pcm_idx.
With these information, we can tell which PCM is mapped to which PORT.
The audio driver can export such information to user space (No sure
if such information is already exported.). And user space, such as
pulseaudio and so on, can use such information automatically choose
which PCM to playback corresponding to the monitor
which active window is in.
Regards,
Libin
>
>> card 1: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog]
>>Subdevices: 1/1
>>Subdevice #0: subdevice #0
>>
>>
>> - tiny computer (Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz):
>> 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
>> Graphics 530 [8086:1912] (rev 06)
>> 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD
>> Audio [8086:a170] (rev 31)
>>
>> Here alsa shows a single card:
>> - HDA Intel PCH (Realtek ALC671)
>>
>> List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel
>> PCH], device 0: ALC671 Analog [ALC671 Analog]
>>Subdevices: 1/1
>>Subdevice #0: subdevice #0
>> card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital]
>>Subdevices: 1/1
>>Subdevice #0: subdevice #0
>>
>>
>> How can I determine/set to which monitor the sound should go, and
>> preferably send different sounds to both monitors at same time?
>>
>>
>> Cheers,
>> Bruno
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Ville Syrjälä
>Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB (rev2)
== Series Details == Series: drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB (rev2) URL : https://patchwork.freedesktop.org/series/49495/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813_full -> Patchwork_10161_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10161_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10161 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10161: 712f10408dd4482a72bf80eebf61d5f63761e8a7 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10161/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Limit the backpressure for i915_request allocation
== Series Details == Series: series starting with [1/3] drm/i915: Limit the backpressure for i915_request allocation URL : https://patchwork.freedesktop.org/series/49572/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813_full -> Patchwork_10160_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10160_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10160_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_10160_full: === IGT changes === Warnings igt@kms_cursor_legacy@cursor-vs-flip-legacy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10160_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions: shard-hsw: PASS -> FAIL (fdo#103355) igt@perf@polling: shard-hsw: PASS -> FAIL (fdo#102252) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10160 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10160: 3f7aff32f54467dfbc1b6bffbe82182eaa3ebcc0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10160/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode
On Wed, Sep 12, 2018 at 3:55 PM Manasi Navare wrote:
>
> This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp:
> Do not do link training fallback or prune modes on EDP") that causes
> a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350)
> where first link training fails and a retraining is required by falling
> back to lower link rate/lane count.
> In case of some panels they advertise higher link rate/lane count
> than whats required for supporting the panel's native mode.
> But we always link train at highest link rate/lane count for eDP
> and if that fails we can still fallback to lower link rate/lane count
> as long as the fallback link BW still fits the native mode to avoid
> pruning the panel's native mode yet retraining at fallback values
> to recover from a blank screen.
I suspect something went bad on my laptop or the cause is something else.
I can't reproduce this problem anymore, even if I go back to old kernels.
And, in contrary to what I had previously, now I have:
# dd if=/dev/drm_dp_aux0 bs=1 | hexdump -C
...
0070 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
...
Lucas De Marchi
>
> v2:
> * Send uevent if link failure on eDP unconditionally
>
> Cc: Clinton Taylor
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Daniel Vetter
> Cc: Lucas De Marchi
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338
> Signed-off-by: Manasi Navare
> Tested-by: Alexander Wilson
> ---
> drivers/gpu/drm/i915/intel_dp.c | 29 +++
> drivers/gpu/drm/i915/intel_dp_link_training.c | 26 ++---
> 2 files changed, 38 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 436c22de33b6..e4de5257cd87 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -557,6 +557,21 @@ static bool intel_dp_link_params_valid(struct intel_dp
> *intel_dp, int link_rate,
> return true;
> }
>
> +static bool intel_dp_can_link_train_fallback_for_edp(struct intel_dp
> *intel_dp,
> +int link_rate,
> +uint8_t lane_count)
> +{
> + struct drm_display_mode *fixed_mode =
> intel_dp->attached_connector->panel.fixed_mode;
> + int mode_rate, max_rate;
> +
> + mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
> + max_rate = intel_dp_max_data_rate(link_rate, lane_count);
> + if (mode_rate > max_rate)
> + return false;
> +
> + return true;
> +}
> +
> int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> int link_rate, uint8_t lane_count)
> {
> @@ -566,9 +581,23 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> intel_dp->num_common_rates,
> link_rate);
> if (index > 0) {
> + if (intel_dp_is_edp(intel_dp) &&
> + !intel_dp_can_link_train_fallback_for_edp(intel_dp,
> +
> intel_dp->common_rates[index - 1],
> + lane_count)) {
> + DRM_DEBUG_KMS("Retrying Link training for eDP with
> same parameters\n");
> + return 0;
> + }
> intel_dp->max_link_rate = intel_dp->common_rates[index - 1];
> intel_dp->max_link_lane_count = lane_count;
> } else if (lane_count > 1) {
> + if (intel_dp_is_edp(intel_dp) &&
> + !intel_dp_can_link_train_fallback_for_edp(intel_dp,
> +
> intel_dp_max_common_rate(intel_dp),
> + lane_count >>
> 1)) {
> + DRM_DEBUG_KMS("Retrying Link training for eDP with
> same parameters\n");
> + return 0;
> + }
> intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> intel_dp->max_link_lane_count = lane_count >> 1;
> } else {
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index a9f40985a621..30be0e39bd5f 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -367,22 +367,14 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> return;
>
> failure_handling:
> - /* Dont fallback and prune modes if its eDP */
> - if (!intel_dp_is_edp(intel_dp)) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link
> rate = %d, lane count = %d",
> -
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Rename full ppgtt configuration to be more generic (rev4)
== Series Details == Series: drm/i915: Rename full ppgtt configuration to be more generic (rev4) URL : https://patchwork.freedesktop.org/series/49021/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813_full -> Patchwork_10159_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10159_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10159 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10159: dcdfffbe599f3e59b296fd9891a9fd36dd9d6104 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10159/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode
== Series Details == Series: series starting with [v2,1/4] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode URL : https://patchwork.freedesktop.org/series/49596/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10163 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49596/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10163 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#107139, fdo#105128) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 45) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10163 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10163: c20815b7fb4e8a7f36d8f318b5b5090b70ee39ac @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c20815b7fb4e drm/i915/dp: Check eDP fallback link BW against downclock mode b0a8b896b0af drm/i915/dp: Validate the downclock mode for eDP if it exists 07fbd2a99d01 drm/i915/dp: Disconnect eDP downclock mode from DRRS fdbd4338b849 drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10163/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for i915/oa: Simplify updating contexts
== Series Details == Series: i915/oa: Simplify updating contexts URL : https://patchwork.freedesktop.org/series/49569/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813_full -> Patchwork_10158_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10158_full that come from known issues: === IGT changes === Issues hit igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge: shard-kbl: PASS -> DMESG-WARN (fdo#103313, fdo#103558, fdo#105602) +12 igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +7 igt@kms_plane_lowres@pipe-a-tiling-y: shard-kbl: PASS -> DMESG-WARN (fdo#103841) +1 Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10158 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10158: 2a916e5572e4e76f7a31d748b15b417b280e8123 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10158/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/dp: Validate the downclock mode for eDP if it exists
With downclock mode and DRRS now operating independently user can request a modeset on downclock mode. In that case intel_dp_mode_valid() should validate the downclock mode as well if that is requested. Cc: Jani Nikula Cc: Ville Syrjala Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_dp.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 30526c02b343..0e400629e85c 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -615,6 +615,8 @@ intel_dp_mode_valid(struct drm_connector *connector, struct intel_dp *intel_dp = intel_attached_dp(connector); struct intel_connector *intel_connector = to_intel_connector(connector); struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode; + struct drm_display_mode *downclock_mode = + intel_connector->panel.downclock_mode; int target_clock = mode->clock; int max_rate, mode_rate, max_lanes, max_link_clock; int max_dotclk; @@ -631,7 +633,10 @@ intel_dp_mode_valid(struct drm_connector *connector, if (mode->vdisplay > fixed_mode->vdisplay) return MODE_PANEL; - target_clock = fixed_mode->clock; + if (target_clock < fixed_mode->clock && downclock_mode) + target_clock = downclock_mode->clock; + else + target_clock = fixed_mode->clock; } max_link_clock = intel_dp_max_link_rate(intel_dp); -- 2.18.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915/dp: Disconnect eDP downclock mode from DRRS
Downclock mode of the panel needs to be set independently
of DRRS so that the user can set the downclock mode on the panel
without enabling DRRS.
This patch sets the downclock mode in edp_init as opposed to
drrs_init to achieve this.
Suggested-by: Jani Nikula
Cc: Jani Nikula
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e4de5257cd87..30526c02b343 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6371,44 +6371,30 @@ void intel_edp_drrs_flush(struct drm_i915_private
*dev_priv,
* This function is called only once at driver load to initialize basic
* DRRS stuff.
*
- * Returns:
- * Downclock mode if panel supports it, else return NULL.
- * DRRS support is determined by the presence of downclock mode (apart
- * from VBT setting).
*/
-static struct drm_display_mode *
+static void
intel_dp_drrs_init(struct intel_connector *connector,
struct drm_display_mode *fixed_mode)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
- struct drm_display_mode *downclock_mode = NULL;
INIT_DELAYED_WORK(&dev_priv->drrs.work, intel_edp_drrs_downclock_work);
mutex_init(&dev_priv->drrs.mutex);
if (INTEL_GEN(dev_priv) <= 6) {
DRM_DEBUG_KMS("DRRS supported for Gen7 and above\n");
- return NULL;
+ return;
}
if (dev_priv->vbt.drrs_type != SEAMLESS_DRRS_SUPPORT) {
DRM_DEBUG_KMS("VBT doesn't support DRRS\n");
- return NULL;
- }
-
- downclock_mode = intel_find_panel_downclock(dev_priv, fixed_mode,
- &connector->base);
-
- if (!downclock_mode) {
- DRM_DEBUG_KMS("Downclock mode is not found. DRRS not
supported\n");
- return NULL;
+ return;
}
dev_priv->drrs.type = dev_priv->vbt.drrs_type;
dev_priv->drrs.refresh_rate_type = DRRS_HIGH_RR;
DRM_DEBUG_KMS("seamless DRRS supported for eDP panel.\n");
- return downclock_mode;
}
static bool intel_edp_init_connector(struct intel_dp *intel_dp,
@@ -6476,8 +6462,13 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
list_for_each_entry(scan, &connector->probed_modes, head) {
if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
fixed_mode = drm_mode_duplicate(dev, scan);
- downclock_mode = intel_dp_drrs_init(
- intel_connector, fixed_mode);
+ downclock_mode = intel_find_panel_downclock(dev_priv,
+ fixed_mode,
+ connector);
+ if (downclock_mode)
+ intel_dp_drrs_init(intel_connector, fixed_mode);
+ else
+ DRM_DEBUG_KMS("Downclock mode is not found.
DRRS not supported\n");
break;
}
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode
This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp:
Do not do link training fallback or prune modes on EDP") that causes
a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350)
where first link training fails and a retraining is required by falling
back to lower link rate/lane count.
In case of some panels they advertise higher link rate/lane count
than whats required for supporting the panel's native mode.
But we always link train at highest link rate/lane count for eDP
and if that fails we can still fallback to lower link rate/lane count
as long as the fallback link BW still fits the native mode to avoid
pruning the panel's native mode yet retraining at fallback values
to recover from a blank screen.
v2:
* Send uevent if link failure on eDP unconditionally
Cc: Clinton Taylor
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Daniel Vetter
Cc: Lucas De Marchi
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338
Signed-off-by: Manasi Navare
Tested-by: Alexander Wilson
---
drivers/gpu/drm/i915/intel_dp.c | 29 +++
drivers/gpu/drm/i915/intel_dp_link_training.c | 26 ++---
2 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22de33b6..e4de5257cd87 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -557,6 +557,21 @@ static bool intel_dp_link_params_valid(struct intel_dp
*intel_dp, int link_rate,
return true;
}
+static bool intel_dp_can_link_train_fallback_for_edp(struct intel_dp *intel_dp,
+int link_rate,
+uint8_t lane_count)
+{
+ struct drm_display_mode *fixed_mode =
intel_dp->attached_connector->panel.fixed_mode;
+ int mode_rate, max_rate;
+
+ mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
+ max_rate = intel_dp_max_data_rate(link_rate, lane_count);
+ if (mode_rate > max_rate)
+ return false;
+
+ return true;
+}
+
int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
int link_rate, uint8_t lane_count)
{
@@ -566,9 +581,23 @@ int intel_dp_get_link_train_fallback_values(struct
intel_dp *intel_dp,
intel_dp->num_common_rates,
link_rate);
if (index > 0) {
+ if (intel_dp_is_edp(intel_dp) &&
+ !intel_dp_can_link_train_fallback_for_edp(intel_dp,
+
intel_dp->common_rates[index - 1],
+ lane_count)) {
+ DRM_DEBUG_KMS("Retrying Link training for eDP with same
parameters\n");
+ return 0;
+ }
intel_dp->max_link_rate = intel_dp->common_rates[index - 1];
intel_dp->max_link_lane_count = lane_count;
} else if (lane_count > 1) {
+ if (intel_dp_is_edp(intel_dp) &&
+ !intel_dp_can_link_train_fallback_for_edp(intel_dp,
+
intel_dp_max_common_rate(intel_dp),
+ lane_count >> 1))
{
+ DRM_DEBUG_KMS("Retrying Link training for eDP with same
parameters\n");
+ return 0;
+ }
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->max_link_lane_count = lane_count >> 1;
} else {
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index a9f40985a621..30be0e39bd5f 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -367,22 +367,14 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
return;
failure_handling:
- /* Dont fallback and prune modes if its eDP */
- if (!intel_dp_is_edp(intel_dp)) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link
rate = %d, lane count = %d",
- intel_connector->base.base.id,
- intel_connector->base.name,
- intel_dp->link_rate, intel_dp->lane_count);
- if (!intel_dp_get_link_train_fallback_values(intel_dp,
-
intel_dp->link_rate,
-
intel_dp->lane_count))
- /* Schedule a Hotplug Uevent to userspace to start
modeset */
- schedule_work(&intel_connector->modeset_retry_work);
- } else {
-
[Intel-gfx] [PATCH v2 4/4] drm/i915/dp: Check eDP fallback link BW against downclock mode
If link training fails on eDP then we fallback to lower link rate
and lane count. If the fallback link BW cannot fit the panel's native
mode and if the downclock mode exists then we should check if the fallback
BW can fit this downclock mode.
Suggested-by: Jani Nikula
Cc: Jani Nikula
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e400629e85c..bfc56e778d0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -562,12 +562,21 @@ static bool
intel_dp_can_link_train_fallback_for_edp(struct intel_dp *intel_dp,
uint8_t lane_count)
{
struct drm_display_mode *fixed_mode =
intel_dp->attached_connector->panel.fixed_mode;
+ struct drm_display_mode *downclock_mode =
+ intel_dp->attached_connector->panel.downclock_mode;
int mode_rate, max_rate;
mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
max_rate = intel_dp_max_data_rate(link_rate, lane_count);
- if (mode_rate > max_rate)
+ if (mode_rate > max_rate) {
+ if (downclock_mode) {
+ mode_rate =
intel_dp_link_required(downclock_mode->clock,
+ 18);
+ if (mode_rate > max_rate)
+ return false;
+ }
return false;
+ }
return true;
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Limit the backpressure for i915_request allocation (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Limit the backpressure for i915_request allocation (rev2) URL : https://patchwork.freedesktop.org/series/49564/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813_full -> Patchwork_10157_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10157_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10157 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10157: c12cc33c9748a36fe40789e18f5ed8e0548b2b63 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10157/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: fix shifting by a negative number of bits
Em Qua, 2018-09-12 às 09:31 -0500, Gustavo A. R. Silva escreveu:
> Function intel_port_to_tc() returns PORT_TC_NONE on error, which is
> a negative value -1. In case PORT_TC_NONE is returned, there is an
> undefined behavior when shifting by a negative number of bits in
> both DP_PHY_MODE_STATUS_NOT_SAFE and P_PHY_MODE_STATUS_COMPLETED
> macros.
>
> Fix this by adding sanity checks on intel_port_to_tc return value,
> before
> using macros DP_PHY_MODE_STATUS_NOT_SAFE and
> P_PHY_MODE_STATUS_COMPLETED.
This was just discussed yesterday in a patch by Rodrigo:
https://patchwork.freedesktop.org/patch/246903/
I would personally prefer his version because it avoids passing -1 to
register macros that Coverity doesn't seem to care about, it's a single
check and it prints WARN() instead of DRM_DEBUG_KMS().
Although I do prefer your commit message explanation :).
Perhaps I should reconsider my vote to not merge it. Or we could
actually go and test what happens when intel_port_to_tc() is broken,
fixing all the issues instead of just the ones reported by Coverity.
Anyway, Rodrigo's patch with an improved commit message could receive
my R-B tag now.
>
> Addresses-Coverity-ID: 1473324 ("Bad bit shift operation")
> Addresses-Coverity-ID: 1473325 ("Bad bit shift operation")
> Fixes: 39d1e234e1e1 ("drm/i915/icl: implement the tc/legacy HPD
> {dis,}connect flows")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/i915/intel_dp.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 436c22d..e34b7b1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4811,6 +4811,11 @@ static bool icl_tc_phy_connect(struct
> drm_i915_private *dev_priv,
> dig_port->tc_type != TC_PORT_TYPEC)
> return true;
>
> + if (tc_port < 0) {
> + DRM_DEBUG_KMS("Bad TC port %d\n", tc_port);
> + return false;
> + }
> +
> val = I915_READ(PORT_TX_DFLEXDPPMS);
> if (!(val & DP_PHY_MODE_STATUS_COMPLETED(tc_port))) {
> DRM_DEBUG_KMS("DP PHY for TC port %d not ready\n",
> tc_port);
> @@ -4857,6 +4862,10 @@ static void icl_tc_phy_disconnect(struct
> drm_i915_private *dev_priv,
> dig_port->tc_type != TC_PORT_TYPEC)
> return;
>
> + if (tc_port < 0) {
> + DRM_DEBUG_KMS("Bad TC port %d\n", tc_port);
> + return;
> + }
> /*
>* This function may be called many times in a row without
> an HPD event
>* in between, so try to avoid the write when we can.
___
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/dp: fix shifting by a negative number of bits
== Series Details == Series: drm/i915/dp: fix shifting by a negative number of bits URL : https://patchwork.freedesktop.org/series/49565/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4812_full -> Patchwork_10156_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10156_full that come from known issues: === IGT changes === Issues hit igt@gem_userptr_blits@dmabuf-sync: shard-snb: PASS -> INCOMPLETE (fdo#105411) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) igt@perf@rc6-disable: shard-kbl: PASS -> FAIL (fdo#103179) Possible fixes igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#103179 https://bugs.freedesktop.org/show_bug.cgi?id=103179 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4812 -> Patchwork_10156 CI_DRM_4812: 7bed140e1a21dc0e04f2fd87d2726f47b845e82f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10156: bfad517ac799fbbfa711620c387d61e645ed8e67 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10156/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915, HDMI/DP audio with multiple monitors
On Wed, Sep 12, 2018 at 3:05 AM Bruno Prémont wrote: > > Hi, > > I have a system with multiple monitors and would like to send > notification sounds to the monitor on which corresponding > window is visible. > > For a workstation and a tiny computer things look different: > - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): > 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 > v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) > 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core > Processor HD Audio Controller [8086:0c0c] (rev 06) > 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset > High Definition Audio Controller [8086:8c20] (rev 04) > > Here alsa show me two cards: > - HDA Intel PCH (Realtek ALC671) > - HDA Intel HDMI (Intel Generic) > > List of PLAYBACK Hardware Devices > card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic Digital] >Subdevices: 1/1 >Subdevice #0: subdevice #0 > card 1: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] >Subdevices: 1/1 >Subdevice #0: subdevice #0 > > > - tiny computer (Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz): > 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 > [8086:1912] (rev 06) > 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio > [8086:a170] (rev 31) > > Here alsa shows a single card: > - HDA Intel PCH (Realtek ALC671) > > List of PLAYBACK Hardware Devices > card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] >Subdevices: 1/1 >Subdevice #0: subdevice #0 > card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital] >Subdevices: 1/1 >Subdevice #0: subdevice #0 > > > How can I determine/set to which monitor the sound should go, and preferably > send > different sounds to both monitors at same time? On AMD systems, there are vendor verbs to do the channel mappings for various configs. http://developer.amd.com/wordpress/media/2013/10/AMD_HDA_verbs_v2.pdf Intel may have something similar. Alex > > > Cheers, > Bruno > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Add POWER_DOMAIN_GT_IRQ to ICL DC_OFF_POWER_DOMAINS
On Wed, 2018-09-12 at 13:55 +0100, Chris Wilson wrote: > Quoting Ville Syrjälä (2018-09-12 13:48:42) > > On Tue, Sep 11, 2018 at 06:19:56PM -0700, José Roberto de Souza > > wrote: > > > Without this gem will not be able to turn off DC states to > > > redunce > > > interruption latency when no sink is being driven by driver. > > > > Do we know that for sure this is still required? Some kind of test > > results to confirm would be nice. I'm not sure if is still needed, I just saw that older platforms have that domain in DC off and it is used by gem but ICL don't have it set. Also we are still not loading DMC firmware for ICL so it will not be reproducible until that but I guess is better already be prepared and keep consistent with other platforms. > > After all it was working around a bug in the dmc that was meant to be > fixed at some point in the future. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Balance prepare_fb/cleanup_fb
== Series Details == Series: series starting with [1/2] drm/i915: Balance prepare_fb/cleanup_fb URL : https://patchwork.freedesktop.org/series/49579/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10162 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49579/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10162 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_coherency: fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614) igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128, fdo#107139) -> PASS igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 46) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10162 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10162: 1cd88e7b6658c837ba56720021f228850b390719 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1cd88e7b6658 drm/i915: Cleanup properly if the implicit fence wait fails c1782795d8bd drm/i915: Balance prepare_fb/cleanup_fb == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10162/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> On Icelake, a separate power well PG2 is created for
> VDSC engine used for eDP/MIPI DSI.
bikeshed: To be more precise the PG2 wasn't *created*
here, but it was reserved only for VDSC on eDP/MIPI use
and everything else that was previously on PG2 on
previous platforms got moved to PG3...
> This patch adds a new
> display power domain for Power well 2.
>
> Cc: Rodrigo Vivi
> Cc: Imre Deak
> Signed-off-by: Manasi Navare
But patches matches my understanding of the spec,
so:
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.h| 1 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 3fe52788b4cf..bef71d27cdfe 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> POWER_DOMAIN_MODESET,
> POWER_DOMAIN_GT_IRQ,
> POWER_DOMAIN_INIT,
> + POWER_DOMAIN_VDSC_EDP_MIPI,
>
> POWER_DOMAIN_NUM,
> };
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 480dadb1047b..146e2d6cf954 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -146,6 +146,8 @@ intel_display_power_domain_str(enum
> intel_display_power_domain domain)
> return "MODESET";
> case POWER_DOMAIN_GT_IRQ:
> return "GT_IRQ";
> + case POWER_DOMAIN_VDSC_EDP_MIPI:
> + return "VDSC_EDP_MIPI";
> default:
> MISSING_CASE(domain);
> return "?";
> @@ -1966,18 +1968,16 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
> BIT_ULL(POWER_DOMAIN_AUDIO) | \
> BIT_ULL(POWER_DOMAIN_INIT))
> /*
> - * - transcoder WD
> - * - KVMR (HW control)
> + * - eDP/MIPI DSI VDSC
>*/
> #define ICL_PW_2_POWER_DOMAINS ( \
> - ICL_PW_3_POWER_DOMAINS |\
> - BIT_ULL(POWER_DOMAIN_INIT))
> + BIT_ULL(POWER_DOMAIN_VDSC_EDP_MIPI))
> /*
> - * - eDP/DSI VDSC
> + * - transcoder WD
>* - KVMR (HW control)
>*/
> #define ICL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> - ICL_PW_2_POWER_DOMAINS |\
> + ICL_PW_3_POWER_DOMAINS |\
> BIT_ULL(POWER_DOMAIN_MODESET) | \
> BIT_ULL(POWER_DOMAIN_AUX_A) | \
> BIT_ULL(POWER_DOMAIN_INIT))
> --
> 2.18.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Add XYUV format support (rev6)
== Series Details == Series: Add XYUV format support (rev6) URL : https://patchwork.freedesktop.org/series/48007/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4810_full -> Patchwork_10154_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10154_full that come from known issues: === IGT changes === Issues hit igt@kms_available_modes_crc@available_mode_test_crc: shard-apl: PASS -> FAIL (fdo#106701) Possible fixes igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106701 https://bugs.freedesktop.org/show_bug.cgi?id=106701 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4810 -> Patchwork_10154 CI_DRM_4810: 4c0e813835d47e6e9285175e7b92e21fe3d4328f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10154: 9490ef9a07aee695e0e1360495c2384ea417ed64 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10154/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Balance prepare_fb/cleanup_fb
From: Ville Syrjälä
intel_prepare_plane_fb() bails early if there is no fb (or rather
no obj, which is the same thing). intel_cleanup_plane_fb() does not.
This means the steps performed by intel_cleanup_plane_fb() aren't
balanced with with what was done intel_prepare_plane_fb() if there
is no fb for the plane. These hooks get called for every plane in
the state regardless of whether they have an fb or not.
Add a matching null obj check to intel_cleanup_plane_fb() to restore
the balance.
Note that intel_cleanup_plane_fb() has sufficient protections
already in place that the imbalance doesn't cause any real problems.
But having things be in balance seems nicer anyway, and might help
avoid some surprises in the future.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6928dcc926ef..1333493c0618 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13231,6 +13231,10 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
struct intel_atomic_state *intel_state =
to_intel_atomic_state(old_state->state);
struct drm_i915_private *dev_priv = to_i915(plane->dev);
+ struct drm_i915_gem_object *obj = intel_fb_obj(old_state->fb);
+
+ if (!obj)
+ return;
if (intel_state->rps_interactive) {
intel_rps_mark_interactive(dev_priv, false);
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Cleanup properly if the implicit fence wait fails
From: Ville Syrjälä
We've already pinned the vma and fence by the time we try to
deal with implicit fencing. Properly unpin the vma and fence
if the fence wait fails instead of just bailing straight out
from .prepare_fb(). As can be expected
drm_atomic_helper_prepare_planes() will not call .cleanup_fb()
for the plane whose .prepare_fb() failed so we must do the
cleanup ourself.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1333493c0618..947301312ea3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13188,7 +13188,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
false, I915_FENCE_TIMEOUT,
GFP_KERNEL);
if (ret < 0)
- return ret;
+ goto unpin_fb;
fence = reservation_object_get_excl_rcu(obj->resv);
if (fence) {
@@ -13213,6 +13213,13 @@ intel_prepare_plane_fb(struct drm_plane *plane,
}
return 0;
+
+unpin_fb:
+ mutex_lock(&dev_priv->drm.struct_mutex);
+ intel_plane_unpin_fb(to_intel_plane_state(new_state));
+ mutex_unlock(&dev_priv->drm.struct_mutex);
+
+ return ret;
}
/**
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats
Swati Sharma kirjoitti 12.9.2018 klo 13.32:
From: Vidya Srinivas
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
drivers/gpu/drm/i915/intel_sprite.c | 3 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2b77d93..7c68a0d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3512,6 +3512,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_Y210:
+ return PLANE_CTL_FORMAT_Y210;
+ case DRM_FORMAT_Y212:
+ return PLANE_CTL_FORMAT_Y212;
+ case DRM_FORMAT_Y216:
+ return PLANE_CTL_FORMAT_Y216;
default:
MISSING_CASE(pixel_format);
}
@@ -4960,6 +4966,9 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format
0x%x\n",
@@ -13422,6 +13431,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
@@ -14551,6 +14563,9 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YVYU:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
drm_get_format_name(mode_cmd->pixel_format,
&format_name));
This is wrong place for these cases. These three new YUV formats are
available on ICL+. You'll need case handling which checks if
INTEL_GEN(dev_priv) < 11.
/Juha-Pekka
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 9600ccf..f7e2768 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1419,6 +1419,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [STABLE v4.18 BACKPORT] drm/i915: set DP Main Stream Attribute for color range on DDI platforms
On Wed, Sep 12, 2018 at 04:59:10PM +0300, Jani Nikula wrote: > commit 6209c285e7a5e68dbcdf8fd2456c6dd68433806b upstream. Thanks for the backport, now queued up. greg k-h ___ 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 a potential integer overflow with framebuffers extending past 4 GiB (rev2)
== Series Details == Series: drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB (rev2) URL : https://patchwork.freedesktop.org/series/49495/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10161 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49495/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_10161 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-skl-guc: PASS -> FAIL (fdo#103191) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128, fdo#107139) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 44) == Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10161 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10161: 712f10408dd4482a72bf80eebf61d5f63761e8a7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 712f10408dd4 drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10161/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
On Wed, 12 Sep 2018 15:18:47 +0200,
Imre Deak wrote:
>
> +Takashi
>
> On Wed, Sep 12, 2018 at 04:18:12PM +0300, Imre Deak wrote:
> > Hi Kumar, Takashi,
> >
> > On Tue, Jun 19, 2018 at 03:01:11PM -0700, Abhay Kumar wrote:
> > > From: Ville Syrjälä
> > >
> > > CDCLK has to be at least twice the BLCK regardless of audio. Audio
> > > driver has to probe using this hook and increase the clock even in
> > > absence of any display.
> > >
> > > v2: Use atomic refcount for get_power, put_power so that we can
> > > call each once(Abhay).
> > > v3: Reset power well 2 to avoid any transaction on iDisp link
> > > during cdclk change(Abhay).
> > > v4: Remove Power well 2 reset workaround(Ville).
> > > v5: Remove unwanted Power well 2 register defined in v4(Abhay).
> > >
> > > Signed-off-by: Ville Syrjälä
> > > Signed-off-by: Abhay Kumar
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > > drivers/gpu/drm/i915/intel_audio.c | 67
> > > +---
> > > drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
> > > drivers/gpu/drm/i915/intel_display.c | 7 +++-
> > > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > > 5 files changed, 83 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 6104d7115054..a4a386a5db69 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1702,6 +1702,7 @@ struct drm_i915_private {
> > > unsigned int hpll_freq;
> > > unsigned int fdi_pll_freq;
> > > unsigned int czclk_freq;
> > > + u32 get_put_refcount;
> > >
> > > struct {
> > > /*
> > > @@ -1719,6 +1720,8 @@ struct drm_i915_private {
> > > struct intel_cdclk_state actual;
> > > /* The current hardware cdclk state */
> > > struct intel_cdclk_state hw;
> > > +
> > > + int force_min_cdclk;
> > > } cdclk;
> > >
> > > /**
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 3ea566f99450..ca8f04c7cbb3 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder
> > > *encoder,
> > >
> > > if (!connector->eld[0])
> > > return;
> > > -
> > > DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
> > >connector->base.id,
> > >connector->name,
> > > @@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private
> > > *dev_priv)
> > > }
> > > }
> > >
> > > +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
> > > + bool enable)
> > > +{
> > > + struct drm_modeset_acquire_ctx ctx;
> > > + struct drm_atomic_state *state;
> > > + int ret;
> > > +
> > > + drm_modeset_acquire_init(&ctx, 0);
> > > + state = drm_atomic_state_alloc(&dev_priv->drm);
> > > + if (WARN_ON(!state))
> > > + return;
> > > +
> > > + state->acquire_ctx = &ctx;
> > > +
> > > +retry:
> > > + to_intel_atomic_state(state)->modeset = true;
> > > + to_intel_atomic_state(state)->cdclk.force_min_cdclk =
> > > + enable ? 2 * 96000 : 0;
> > > +
> > > + /*
> > > + * Protects dev_priv->cdclk.force_min_cdclk
> > > + * Need to lock this here in case we have no active pipes
> > > + * and thus wouldn't lock it during the commit otherwise.
> > > + */
> > > + ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
> > > &ctx);
> > > + if (!ret)
> > > + ret = drm_atomic_commit(state);
> >
> > Ville mentioned a potential dead-lock problem here: a normal modeset
> > enabling an HDMI/DP output with an audio sink will call the
> > drm_audio_component_audio_ops::pin_eld_notify() callback with the
> > connection_mutex already held. This callback in turn could call
> > drm_audio_component_ops::get_power()/put_power() callbacks and
> > dead-lock at the above drm_modeset_lock() call.
> >
> > Looks like that
> >
> >sound/pci/hda/patch_hdmi.c / intel_pin_eld_notify()->
> >check_presence_and_report()->
> >hdmi_present_sense()
> >
> > would prevent this, but for instance
> >
> >sound/soc/codecs/hdac_hdmi.c / hdac_hdmi_eld_notify_cb()->
> >hdac_hdmi_present_sense()->
> >hdac_hdmi_jack_report()->
> >snd_soc_jack_report()->
> >snd_soc_dapm_sync()->
> >snd_soc_dapm_sync_unlocked()->
> >dapm_power_widgets()->
> >dapm_pre_sequence_async()
> >
> > could call pm_runtime_get_sync() and so I guess also the aops
> > get_power() hook.
> >
> > Could someone in your team check if the above can indeed happen?
Through a quick glance, I'm afraid that it's indeed possible. We need
to off-load either the hdac_hdmi jack handling or this new
force_audio_cdclk stuff, I suppose.
thanks,
Takashi
> > > +
> > > + if (ret == -EDEADLK) {
> > > + drm_atomic_state_clear(state);
> >
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB (rev2)
== Series Details == Series: drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB (rev2) URL : https://patchwork.freedesktop.org/series/49495/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB -O:drivers/gpu/drm/i915/intel_display.c:2640:28: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_display.c:2640:28: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:2640:28: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:2640:28: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915, HDMI/DP audio with multiple monitors
On Wed, 12 Sep 2018 19:46:58 +0200, Ville Syrjälä wrote: > > On Tue, Sep 11, 2018 at 03:50:13PM +0200, Bruno Prémont wrote: > > Hi, > > > > I have a system with multiple monitors and would like to send > > notification sounds to the monitor on which corresponding > > window is visible. > > > > For a workstation and a tiny computer things look different: > > - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 > > v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev > > 06) > > 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen > > Core Processor HD Audio Controller [8086:0c0c] (rev 06) > > 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series > > Chipset High Definition Audio Controller [8086:8c20] (rev 04) > > > > Here alsa show me two cards: > > - HDA Intel PCH (Realtek ALC671) > > - HDA Intel HDMI (Intel Generic) > > > > List of PLAYBACK Hardware Devices > > card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic Digital] > >Subdevices: 1/1 > >Subdevice #0: subdevice #0 Is a proper kernel config (CONFIG_SND_HDA_CODEC_HDMI) enabled? The device name looks strange as if it's not properly bound with the HDMI codec driver. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB
From: Ville Syrjälä
If we have framebuffers that are >= 4GiB in size we will overflow
the fb size check in intel_fill_fb_info().
Currently that is only possible with NV12 and CCS as offsets[1]
may be anything between 0 and 0x. offsets[0] is currently
required to be 0 so we can't hit the overflow with any single
plane format (thanks to max fb size of 8kx8k and max stride of
32 KiB).
In the future we may allow almost any framebuffer to exceed 4GiB
in size so we really should fix the overflow. Not that the overflow
is particularly dangerous. It's mostly just a sanity check against
insane userspace. The display engine can't write to memory anyway
so I suppose in the worst case we might anger the hw by attempting
scanout past the end of the ggtt, or we might scan out some data
that we're not supposed to see from other parts of the ggtt.
Note that triggering this overflow depends on the driver
aligning the fb height to the next tile boundary to push the
calculated size above 4GiB. With linear buffers the effective
tile height is one so that never happens, and the core already
has a check for 32bit overflow of offsets[]+pitches[]*height.
v2: Drop the unnecessary cast (Chris)
Testcase: igt/kms_big_fb/x-tiled-addfb-size-offset-overflow
Testcase: igt/kms_big_fb/y-tiled-addfb-size-offset-overflow
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7fbc006be44a..6928dcc926ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2640,9 +2640,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
max_size = max(max_size, offset + size);
}
- if (max_size * tile_size > obj->base.size) {
- DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu
bytes)\n",
- max_size * tile_size, obj->base.size);
+ if (mul_u32_u32(max_size, tile_size) > obj->base.size) {
+ DRM_DEBUG_KMS("fb too big for bo (need %llu bytes, have %zu
bytes)\n",
+ mul_u32_u32(max_size, tile_size), obj->base.size);
return -EINVAL;
}
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 11/13] drm/i915/icl: Add macros for MMIO of DSI transcoder registers
On Wed, Sep 12, 2018 at 03:06:41PM +0530, Madhav Chauhan wrote:
> On 7/19/2018 9:52 PM, Ville Syrjälä wrote:
> > On Tue, Jul 10, 2018 at 03:10:12PM +0530, Madhav Chauhan wrote:
> >> This patch adds _MMIO_DSI and _DSI_TRANS macros for accessing
> >> DSI transcoder registers.
> >>
> >> Credits-to: Jani N
> >>
> >> Cc: Jani Nikula
> >> Signed-off-by: Madhav Chauhan
> >> ---
> >> drivers/gpu/drm/i915/i915_reg.h | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 1d13ba9..62bc76e 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -9576,6 +9576,11 @@ enum skl_power_gate {
> >> #define _MIPI_PORT(port, a, c) (((port) == PORT_A) ? a : c)/*
> >> ports A and C only */
> >> #define _MMIO_MIPI(port, a, c) _MMIO(_MIPI_PORT(port, a, c))
> >>
> >> +/* gen11 DSI */
> >> +#define _DSI_TRANS(tc, dsi0, dsi1)(((tc) == TRANSCODER_DSI_0) ?
> >> \
> >> + (dsi0) : (dsi1))
> > _PIPE() etc. should result in slughtly better code IIRC.
>
> Can you please clarify on this??
Plenty of examples in i915_reg.h for using _PIPE().
>
> Regards,
> Madhav
>
> >
> >> +#define _MMIO_DSI(tc, dsi0, dsi1) _MMIO(_DSI_TRANS(tc, dsi0, dsi1))
> >> +
> >> #define MIPIO_TXESC_CLK_DIV1 _MMIO(0x160004)
> >> #define GLK_TX_ESC_CLK_DIV1_MASK0x3FF
> >> #define MIPIO_TXESC_CLK_DIV2 _MMIO(0x160008)
> >> --
> >> 2.7.4
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915, HDMI/DP audio with multiple monitors
On Tue, Sep 11, 2018 at 03:50:13PM +0200, Bruno Prémont wrote:
> Hi,
>
> I have a system with multiple monitors and would like to send
> notification sounds to the monitor on which corresponding
> window is visible.
>
> For a workstation and a tiny computer things look different:
> - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz):
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200
> v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
> 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core
> Processor HD Audio Controller [8086:0c0c] (rev 06)
> 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset
> High Definition Audio Controller [8086:8c20] (rev 04)
>
> Here alsa show me two cards:
> - HDA Intel PCH (Realtek ALC671)
> - HDA Intel HDMI (Intel Generic)
>
> List of PLAYBACK Hardware Devices
> card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic Digital]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
There should normally be multiple HDMI devices (one for each HDMI/DP
connector more or less). Eg. my hsw shows:
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
Looking at the hda_codec.c we see:
static int audio_idx[HDA_PCM_NTYPES][5] = {
...
[HDA_PCM_TYPE_HDMI] = { 3, 7, 8, 9, -1 },
So you always get those device numbers, but I don't see an immediate
relationship between those and the pin numbers (which do have some
kind of relationship with the HDMI/DP port). I guess if they always
get registered in order of the pin numbers then those would translate
to 3 == port B, 7 == port C, etc. And after that the problem is figuring
out which port is related to which connector, for which we have nothing
at the moment.
I suppose the ideal solution might be to have a sysfs symlink (or
something) to connect the two together.
But then there's MST where I think the pcm device correlates with the
crtc rather than the connector. Maybe. I can't remember anymore, and
I'm not sure it even works (I've recently heard people saying it
doesn't).
> card 1: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
>
>
> - tiny computer (Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz):
> 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530
> [8086:1912] (rev 06)
> 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio
> [8086:a170] (rev 31)
>
> Here alsa shows a single card:
> - HDA Intel PCH (Realtek ALC671)
>
> List of PLAYBACK Hardware Devices
> card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
> card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital]
>Subdevices: 1/1
>Subdevice #0: subdevice #0
>
>
> How can I determine/set to which monitor the sound should go, and preferably
> send
> different sounds to both monitors at same time?
>
>
> Cheers,
> Bruno
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Limit the backpressure for i915_request allocation
== Series Details == Series: series starting with [1/3] drm/i915: Limit the backpressure for i915_request allocation URL : https://patchwork.freedesktop.org/series/49572/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10160 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49572/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10160 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-ilk-650: PASS -> DMESG-WARN (fdo#106387) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#107139, fdo#105128) -> PASS igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106387 https://bugs.freedesktop.org/show_bug.cgi?id=106387 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 46) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10160 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10160: 3f7aff32f54467dfbc1b6bffbe82182eaa3ebcc0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3f7aff32f544 drm/i915: Wait for the previous RCU grace period, not request completion 27b5d3fba477 drm/i915: Restrict wait to client's timeline on i915_request alloc failure 908461b0dad8 drm/i915: Limit the backpressure for i915_request allocation == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10160/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Rename full ppgtt configuration to be more generic (rev4)
== Series Details == Series: drm/i915: Rename full ppgtt configuration to be more generic (rev4) URL : https://patchwork.freedesktop.org/series/49021/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10159 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49021/revisions/4/mbox/ == Known issues == Here are the changes found in Patchwork_10159 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#107139, fdo#105128) -> PASS igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 46) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10159 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10159: dcdfffbe599f3e59b296fd9891a9fd36dd9d6104 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == dcdfffbe599f drm/i915: Make 48bit full ppgtt configuration generic (v4) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10159/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION 4.19-rc2] sometimes hangs with black screen when resuming from suspend or hibernation (was: Re: Linux 4.19-rc2)
On Tue, Sep 11, 2018 at 12:17:05PM +0200, Martin Steigerwald wrote: > Cc´d Intel Gfx mailing list, in case somebody there knows something: > > Cc´d Thorsten for regression tracking… forgot initially. Can also open > bug report at a later time but so far I cannot provide many details > about the issue. > > Rafael J. Wysocki - 11.09.18, 10:17: > > On Tue, Sep 11, 2018 at 10:01 AM Martin Steigerwald > wrote: > > > Hi. > > > > > > Linus Torvalds - 02.09.18, 23:45: > > > > As usual, the rc2 release is pretty small. People are taking a > > > > > > With 4.19-rc2 this ThinkPad T520 with i5 Sandybrdige sometimes hangs > > > with black screen when resuming from suspend or hibernation. With > > > 4.18.1 it did not. Of course there have been userspace related > > > updates that could be related. > > > > > > I currently have no time to dig into this and on this production > > > laptop I generally do not do bisects between major kernel releases. > > > So currently I only answer questions that do not require much time > > > to answer. > > > > > > For now I switched back to 4.18. If that is stable – and thus likely > > > no userspace component is related –, I go with 4.19-rc3 or whatever > > > is most recent version to see if the issue has been fixed already. > > > > There were almost no general changes related to system-wide PM between > > 4.18 and current, so I would suspect one of the device drivers or the > > x86 core. It also may be something like CPU online/offline, however. > > I see. I wondered about intel-gfx driver already. Of course it could > also be something else. > > I forgot to mention: The mouse pointer was visible, but the screen > remained black. Did the mouse cursor still move or not? Could also try suspend without any GUI stuff in the way. Or try the intel ddx instead of the modesetting ddx (assuming that's what you're using now) and no compositor to rule out GPU hangs killing the compositor. The intel ddx can also deal with the GPU not recovering from a hang by switching to software rendering, whereas modesetting cannot. Hmm. Also T520 is an optimus laptop maybe? If there's an nvidia GPU involved it's going to be hard to get anyone to care. Better switch that off in the BIOS if you haven't already. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for i915/oa: Simplify updating contexts
== Series Details == Series: i915/oa: Simplify updating contexts URL : https://patchwork.freedesktop.org/series/49569/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10158 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49569/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10158 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614) igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128, fdo#107139) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 45) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10158 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10158: 2a916e5572e4e76f7a31d748b15b417b280e8123 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2a916e5572e4 i915/oa: Simplify updating contexts == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10158/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Wait for the previous RCU grace period, not request completion
Under mempressure, our goal is to allow ourselves sufficient time to
reclaim the RCU protected slabs without overly penalizing our clients.
Currently, we use a 1 jiffie wait if the client is still active as a
means of throttling the allocations, but we can instead wait for the end
of the RCU grace period of the clients previous allocation.
Suggested-by: Daniel Vetter
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_request.c | 14 ++
drivers/gpu/drm/i915/i915_request.h | 8
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 72bcb4ca0c45..a492385b2089 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -732,17 +732,13 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq = kmem_cache_alloc(i915->requests,
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
+ i915_retire_requests(i915);
+
/* Ratelimit ourselves to prevent oom from malicious clients */
rq = i915_gem_active_raw(&ce->ring->timeline->last_request,
&i915->drm.struct_mutex);
- if (rq && i915_request_wait(rq,
- I915_WAIT_LOCKED |
- I915_WAIT_INTERRUPTIBLE,
- 1) == -EINTR) {
- ret = -EINTR;
- goto err_unreserve;
- }
- i915_retire_requests(i915);
+ if (rq)
+ cond_synchronize_rcu(rq->rcustate);
/*
* We've forced the client to stall and catch up with whatever
@@ -762,6 +758,8 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
}
}
+ rq->rcustate = get_state_synchronize_rcu();
+
INIT_LIST_HEAD(&rq->active_list);
rq->i915 = i915;
rq->engine = engine;
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 9898301ab7ef..7fa94b024968 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -100,6 +100,14 @@ struct i915_request {
struct i915_timeline *timeline;
struct intel_signal_node signaling;
+ /*
+* The rcu epoch of when this request was allocated. Used to judiciously
+* apply backpressure on future allocations to ensure that under
+* mempressure there is sufficient RCU ticks for us to reclaim our
+* RCU protected slabs.
+*/
+ unsigned long rcustate;
+
/*
* Fences for the various phases in the request's lifetime.
*
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Limit the backpressure for i915_request allocation
If we try and fail to allocate a i915_request, we apply some backpressure on the clients to throttle the memory allocations coming from i915.ko. Currently, we wait until completely idle, but this is far too heavy and leads to some situations where the only escape is to declare a client hung and reset the GPU. The intent is to only ratelimit the allocation requests, so we need only wait for a jiffie before using the normal direct reclaim. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 09ed48833b54..588bc5a4d18b 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx) ret = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED | I915_WAIT_INTERRUPTIBLE, -MAX_SCHEDULE_TIMEOUT); +1); if (ret) goto err_unreserve; -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Restrict wait to client's timeline on i915_request alloc failure
Let's try not to overly penalize the unlucky client by making them wait
for others to complete their work, and only apply the ratelimit if they
themselves have outstanding work. Still, we apply global reclaim to the
client (we need to scavenge some memory for it) so it doesn't got away
completely scot free.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_request.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 588bc5a4d18b..72bcb4ca0c45 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -733,12 +733,16 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
/* Ratelimit ourselves to prevent oom from malicious clients */
- ret = i915_gem_wait_for_idle(i915,
-I915_WAIT_LOCKED |
-I915_WAIT_INTERRUPTIBLE,
-1);
- if (ret)
+ rq = i915_gem_active_raw(&ce->ring->timeline->last_request,
+&i915->drm.struct_mutex);
+ if (rq && i915_request_wait(rq,
+ I915_WAIT_LOCKED |
+ I915_WAIT_INTERRUPTIBLE,
+ 1) == -EINTR) {
+ ret = -EINTR;
goto err_unreserve;
+ }
+ i915_retire_requests(i915);
/*
* We've forced the client to stall and catch up with whatever
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Limit the backpressure for i915_request allocation (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Limit the backpressure for i915_request allocation (rev2) URL : https://patchwork.freedesktop.org/series/49564/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10157 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49564/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_10157 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_flip@basic-flip-vs-wf_vblank: fi-ilk-650: PASS -> DMESG-WARN (fdo#106387) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#107139, fdo#105128) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106387 https://bugs.freedesktop.org/show_bug.cgi?id=106387 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 46) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10157 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10157: c12cc33c9748a36fe40789e18f5ed8e0548b2b63 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c12cc33c9748 drm/i915: Restrict wait to client's timeline on i915_request alloc failure 975f8d9dadc6 drm/i915: Limit the backpressure for i915_request allocation == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10157/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Differentiate the lack of an interface from invalid parameter
Am 12.09.2018 um 11:12 schrieb Chris Wilson: Quoting Daniel Vetter (2018-09-12 10:02:47) On Wed, Sep 12, 2018 at 10:50 AM, Chris Wilson wrote: Quoting Daniel Vetter (2018-09-12 09:39:30) On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson wrote: If the ioctl is not supported on a particular piece of HW/driver combination, report ENODEV so that it can be easily distinguished from both the lack of the ioctl and from a regular invalid parameter. Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Ville Syrjälä Hm, I thought the canonical errno for "ioctl doesn't apply to this device" is ENOTTY? That's ioctl doesn't exist. Sometimes it's nice to know the kernel knows about the ioctl but it isn't applicable. Either is fine for my purpose, which is to know the ioctl exists, I just need to distinguish it from EINVAL. And ENODEV means that it applies, but atm nothing plugged in, or device gone already. I found a few more modeset ioctl: - drm_mode_gamma_set_ioctl, drm_mode_gamma_get_ioctl - drm_mode_getconnector - drm_mode_getcrtc, drm_mode_setcrtc - drm_mode_getencoder - drm_mode_create_lease_ioctl, drm_mode_list_lessees_ioctl, ... Ok now I stop looking through the grep thing, looks like we've been using EINVAL consistently. I'm all for switching, it makes sense, but I think we should at least try to be consistent across all kms ioctl. Ah, but we've been consistent on the other side and have been using ENODEV for the better part of a decade for this meaning (that the ioctl doesn't apply to this HW) :) Hm indeed, we've been using either ENODEV or EINVAL for "this ioctl doesn't exist/doesn't apply". ENODEV is clearly used in many places (also outside of drm) for "hw absent/gone/disappeared". And we have very few uses of ENOTTY. So I'm kinda leaning towards starting a new trend here, and using ENOTTY for "this ioctl doesn't apply". I don't think we need to differentiate this from the case of "this kernel has no idea about this ioctl at all", since from a userspace pov there's no difference really: Either way it can't use it. But I'm also fine if we're just sticking to ENODEV, just feels like wasting a perfectly useful errno (and there's not many) if we don't give ENOTTY some more use. In going through the drm_core_checks, I noticed one brave soul used -ENOTSUPP. How about that? +1 for that as well and I'm pretty sure I have seen that in a couple of drivers if an IOCTL isn't supported for a specific device. Christian. -Chris ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION 4.19-rc2] sometimes hangs with black screen when resuming from suspend or hibernation (was: Re: Linux 4.19-rc2)
Cc´d Intel Gfx mailing list, in case somebody there knows something: Cc´d Thorsten for regression tracking… forgot initially. Can also open bug report at a later time but so far I cannot provide many details about the issue. Rafael J. Wysocki - 11.09.18, 10:17: > On Tue, Sep 11, 2018 at 10:01 AM Martin Steigerwald wrote: > > Hi. > > > > Linus Torvalds - 02.09.18, 23:45: > > > As usual, the rc2 release is pretty small. People are taking a > > > > With 4.19-rc2 this ThinkPad T520 with i5 Sandybrdige sometimes hangs > > with black screen when resuming from suspend or hibernation. With > > 4.18.1 it did not. Of course there have been userspace related > > updates that could be related. > > > > I currently have no time to dig into this and on this production > > laptop I generally do not do bisects between major kernel releases. > > So currently I only answer questions that do not require much time > > to answer. > > > > For now I switched back to 4.18. If that is stable – and thus likely > > no userspace component is related –, I go with 4.19-rc3 or whatever > > is most recent version to see if the issue has been fixed already. > > There were almost no general changes related to system-wide PM between > 4.18 and current, so I would suspect one of the device drivers or the > x86 core. It also may be something like CPU online/offline, however. I see. I wondered about intel-gfx driver already. Of course it could also be something else. I forgot to mention: The mouse pointer was visible, but the screen remained black. That may again point away from Intel gfx driver. There has been a MESA update in between in userspace. Currently running 4.18.7 to make sure it is no userspace issue. Thanks, -- Martin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i915, HDMI/DP audio with multiple monitors
Hi, I have a system with multiple monitors and would like to send notification sounds to the monitor on which corresponding window is visible. For a workstation and a tiny computer things look different: - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 04) Here alsa show me two cards: - HDA Intel PCH (Realtek ALC671) - HDA Intel HDMI (Intel Generic) List of PLAYBACK Hardware Devices card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 - tiny computer (Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz): 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31) Here alsa shows a single card: - HDA Intel PCH (Realtek ALC671) List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 How can I determine/set to which monitor the sound should go, and preferably send different sounds to both monitors at same time? Cheers, Bruno ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make 48bit full ppgtt configuration generic (v4)
Quoting Bob Paauwe (2018-09-12 17:04:30) > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > index 43ed8b28aeaa..33d7225edbbb 100644 > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > @@ -181,6 +181,8 @@ struct drm_i915_private *mock_gem_device(void) > I915_GTT_PAGE_SIZE_64K | > I915_GTT_PAGE_SIZE_2M; > > + mkwrite_device_info(i915)->full_ppgtt_bits = 48; Actually the mock ppgtt is 64b. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB
On Wed, Sep 12, 2018 at 09:13:07AM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-09-11 17:54:57)
> > From: Ville Syrjälä
> >
> > If we have framebuffers that are >= 4GiB in size we will overflow
> > the fb size check in intel_fill_fb_info().
> >
> > Currently that is only possible with NV12 and CCS as offsets[1]
> > may be anything between 0 and 0x. ofsets[0] is currently
> > required to be 0 so we can't hit the overflow with any single
> > plane format (thanks to max fb size of 8kx8k and max stride of
> > 32 KiB).
> >
> > In the future we may allow almost any framebuffer to exceed 4GiB
> > in size so we really should fix the overflow. Not that the overflow
> > is particularly dangerous. It's mostly just a sanity check against
> > insane userspace. The display engine can't write to memory anyway
> > so I suppose in the worst case we might anger the hw by attempting
> > scanout past the end of the ggtt, or we might scan out some data
> > that we're not supposed to see from other parts of the ggtt.
> >
> > Note that triggering this overflow depends on the driver
> > aligning the fb height to the next tile boundary to push the
> > calculated size above 4GiB. With linear buffers the effective
> > tile height is one so that never happens, and the core already
> > has a check for 32bit overflow of offsets[]+pitches[]*height.
> >
> > Testcase: igt/kms_big_fb/x-tiled-addfb-size-offset-overflow
> > Testcase: igt/kms_big_fb/y-tiled-addfb-size-offset-overflow
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 2b77d9350a3a..2b474d049074 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2636,9 +2636,10 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
> > max_size = max(max_size, offset + size);
> > }
> >
> > - if (max_size * tile_size > obj->base.size) {
> > - DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu
> > bytes)\n",
> > - max_size * tile_size, obj->base.size);
> > + if (mul_u32_u32(max_size, tile_size) > obj->base.size) {
> > + DRM_DEBUG_KMS("fb too big for bo (need %llu bytes, have %zu
> > bytes)\n",
> > + (unsigned long long) mul_u32_u32(max_size,
> > tile_size),
>
> mul_u32_u32 returns u64 i.e. unsigned long long; %llu is the one true
> format specifier for u64 (Linus decree #103789)
Well whaddyaknow, so it is. Never realized that for some reason.
>
> Reviewed-by: Chris Wilson
> -Chris
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Make 48bit full ppgtt configuration generic (v4)
48 bit ppgtt device configuration is really just extended address
range full ppgtt and may actually be something other than 48 bits.
Change USES_FULL_48BIT_PPGTT() to USES_4LVL_PPGTT() to better
describe that a 4 level walk table extended range PPGTT is being
used. Add a new device info field that specifies the number of
bits to prepare for cases where the range is not 32 or 48 bits.
Also rename other functions and comments from 48bit to 4-level.
v2: keep USES_FULL_PPGTT() unchanged (Chris)
v3: Simplify condition in gen8_ppgtt_create() (Chris)
Remove unnecessary line coninuations (Bob)
Rename functions/defines/comments from 48bit to 4lvl (Rodrigo/Bob)
v4: Rename FULL_4LVL_PPGTT to simply 4LVL_PPGTT (Rodrigo)
Be explised in setting vm.total to 1ULL << 32 (Rodrigo)
Gen 7 is 31 bits, not 32 (Chris)
Signed-off-by: Bob Paauwe
CC: Rodrigo Vivi
CC: Michel Thierry
CC: Chris Wilson
---
Beyond this, there are two follow on patches I'd like to work on:
1) Move parts of gen6_create_ppgtt() and gen8_create_ppgtt() that
are common into a single function. This will make gen6)_create_ppgtt()
use the device_info field for number of address bits.
2) Remove enable_ppgtt module parameter.
drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 24
drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
drivers/gpu/drm/i915/i915_pci.c | 7 +--
drivers/gpu/drm/i915/i915_pvinfo.h | 2 +-
drivers/gpu/drm/i915/i915_vgpu.c | 4 ++--
drivers/gpu/drm/i915/i915_vgpu.h | 2 +-
drivers/gpu/drm/i915/intel_device_info.h | 4 +++-
drivers/gpu/drm/i915/intel_lrc.c | 8
drivers/gpu/drm/i915/selftests/huge_pages.c | 8
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 ++
13 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index a4e8e3cf74fd..ab33208e59d6 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -44,7 +44,7 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
vgpu_vreg_t(vgpu, vgtif_reg(display_ready)) = 0;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_id)) = vgpu->id;
- vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) = VGT_CAPS_FULL_48BIT_PPGTT;
+ vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) = VGT_CAPS_4LVL_PPGTT;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HWSP_EMULATION;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HUGE_GTT;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ea442033a57..ac86000a1027 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2572,7 +2572,7 @@ intel_info(const struct drm_i915_private *dev_priv)
#define USES_PPGTT(dev_priv) (i915_modparams.enable_ppgtt)
#define USES_FULL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
-#define USES_FULL_48BIT_PPGTT(dev_priv)(i915_modparams.enable_ppgtt ==
3)
+#define USES_4LVL_PPGTT(dev_priv) ((dev_priv)->info.full_ppgtt_bits > 32)
#define HAS_PAGE_SIZES(dev_priv, sizes) ({ \
GEM_BUG_ON((sizes) == 0); \
((sizes) & ~(dev_priv)->info.page_sizes) == 0; \
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f772593b99ab..561f8e30ea36 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -307,7 +307,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_48bit(&ppgtt->vm))
+ if (ppgtt && i915_vm_is_4lvl(&ppgtt->vm))
address_mode = INTEL_LEGACY_64B_CONTEXT;
desc |= address_mode << GEN8_CTX_ADDRESSING_MODE_SHIFT;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index eb0e446d6482..561a911d09d2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -137,18 +137,18 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private
*dev_priv,
int enable_ppgtt)
{
bool has_full_ppgtt;
- bool has_full_48bit_ppgtt;
+ bool has_full_4lvl_ppgtt;
if (!dev_priv->info.has_aliasing_ppgtt)
return 0;
has_full_ppgtt = dev_priv->info.has_full_ppgtt;
- has_full_48bit_ppgtt = dev_priv->info.has_full_48bit_ppgtt;
+ has_full_4lvl_ppgtt = USES_4LVL_PPGTT(dev_priv);
if (intel_vgpu_active(dev_priv)) {
/* GVT-g has no support for 32bit ppgtt */
has_full_ppgtt = false;
- has_full_48bit_p
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Limit the backpressure for i915_request allocation
== Series Details == Series: drm/i915: Limit the backpressure for i915_request allocation URL : https://patchwork.freedesktop.org/series/49555/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4809_full -> Patchwork_10153_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10153_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_await@wide-contexts: shard-apl: PASS -> FAIL (fdo#106680) shard-kbl: PASS -> FAIL (fdo#106680) Possible fixes igt@drv_suspend@shrink: shard-kbl: INCOMPLETE (fdo#103665, fdo#106886) -> PASS igt@gem_exec_big: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4809 -> Patchwork_10153 CI_DRM_4809: 398eca316f0ed73de201afc12c4ab1ef3b2890cb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10153: 193b2e33a951f696605d282a49529f35bbb19cb1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10153/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915/oa: Simplify updating contexts
Quoting Tvrtko Ursulin (2018-09-12 16:29:30) > /* > * The OA register config is setup through the context image. This > image > * might be written to by the GPU on context switch (in particular on > @@ -1833,7 +1727,7 @@ static int gen8_configure_all_contexts(struct > drm_i915_private *dev_priv, > * the GPU from any submitted work. > */ > ret = i915_gem_wait_for_idle(dev_priv, > -wait_flags, > +I915_WAIT_LOCKED, > MAX_SCHEDULE_TIMEOUT); Wait until idle includes a wait for the gpu to switch off. At least it does for execlists, not so clear for ringbuffer as there is no explicit idle-event. However, that shouldn't matter as the kernel context doesn't exist for legacy ringbuffer anyway ;) But the reload will be forced on the next actual use. > if (ret) > return ret; > @@ -1859,7 +1753,17 @@ static int gen8_configure_all_contexts(struct > drm_i915_private *dev_priv, > i915_gem_object_unpin_map(ce->state->obj); > } > > - return ret; > + /* > +* Apply the configuration by doing one context restore of the edited > +* context image. > +*/ > + rq = i915_request_alloc(engine, dev_priv->kernel_context); By feeding a request, you ensure the reconfig is loaded again. +1 for having it turn off when idle (and not instrument the kernel context at all)! Still I follow your logic that this should leave the oa config in exactly the same state as before the patch, so Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915/oa: Simplify updating contexts
On 12/09/2018 16:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
We can remove the update-via-batch-buffer code path, which is basically an
effective duplicate of update-via-context-image path, if we notice that
after we have idled the GPU, we can update the context image even of the
kernel context directly. (Update-via-batch-buffer path existed only to
solve the problem of how to update the kernel context image.)
Only additional thing needed is to activate the edited configuration by
sending one empty request down the pipe. This accomplishes context restore
of the updated kernel context and so the OA configuration gets written out
to it's control registers.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Matthew Auld
Cc: Chris Wilson
After the discussion we had on IRC about context save/restore timings,
this looks good to me :
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 122 ---
1 file changed, 13 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ccb20230df2c..3d7a052b4cca 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1679,107 +1679,6 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
}
}
-/*
- * Same as gen8_update_reg_state_unlocked only through the batchbuffer. This
- * is only used by the kernel context.
- */
-static int gen8_emit_oa_config(struct i915_request *rq,
- const struct i915_oa_config *oa_config)
-{
- struct drm_i915_private *dev_priv = rq->i915;
- /* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
- };
- u32 *cs;
- int i;
-
- cs = intel_ring_begin(rq, ARRAY_SIZE(flex_mmio) * 2 + 4);
- if (IS_ERR(cs))
- return PTR_ERR(cs);
-
- *cs++ = MI_LOAD_REGISTER_IMM(ARRAY_SIZE(flex_mmio) + 1);
-
- *cs++ = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- *cs++ = (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
- (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
- GEN8_OA_COUNTER_RESUME;
-
- for (i = 0; i < ARRAY_SIZE(flex_mmio); i++) {
- u32 mmio = flex_mmio[i];
-
- /*
-* This arbitrary default will select the 'EU FPU0 Pipeline
-* Active' event. In the future it's anticipated that there
-* will be an explicit 'No Event' we can select, but not
-* yet...
-*/
- u32 value = 0;
-
- if (oa_config) {
- u32 j;
-
- for (j = 0; j < oa_config->flex_regs_len; j++) {
- if
(i915_mmio_reg_offset(oa_config->flex_regs[j].addr) == mmio) {
- value = oa_config->flex_regs[j].value;
- break;
- }
- }
- }
-
- *cs++ = mmio;
- *cs++ = value;
- }
-
- *cs++ = MI_NOOP;
- intel_ring_advance(rq, cs);
-
- return 0;
-}
-
-static int gen8_switch_to_updated_kernel_context(struct drm_i915_private
*dev_priv,
-const struct i915_oa_config
*oa_config)
-{
- struct intel_engine_cs *engine = dev_priv->engine[RCS];
- struct i915_timeline *timeline;
- struct i915_request *rq;
- int ret;
-
- lockdep_assert_held(&dev_priv->drm.struct_mutex);
-
- i915_retire_requests(dev_priv);
-
- rq = i915_request_alloc(engine, dev_priv->kernel_context);
- if (IS_ERR(rq))
- return PTR_ERR(rq);
-
- ret = gen8_emit_oa_config(rq, oa_config);
- if (ret) {
- i915_request_add(rq);
- return ret;
- }
-
- /* Queue this switch after all other activity */
- list_for_each_entry(timeline, &dev_priv->gt.timelines, link) {
- struct i915_request *prev;
-
- prev = i915_gem_active_raw(&timeline->last_request,
- &dev_priv->drm.struct_mutex);
- if (prev)
- i915_request_await_dma_fence(rq, &prev->fence);
- }
-
- i915_request_add(rq);
-
- return 0;
-}
-
/*
* Manages updating the per-context aspects of the OA stream
* configuration across all contexts.
@@ -1809,16 +1708,11 @@ static int gen8_configure_a
[Intel-gfx] [PATCH] i915/oa: Simplify updating contexts
From: Tvrtko Ursulin
We can remove the update-via-batch-buffer code path, which is basically an
effective duplicate of update-via-context-image path, if we notice that
after we have idled the GPU, we can update the context image even of the
kernel context directly. (Update-via-batch-buffer path existed only to
solve the problem of how to update the kernel context image.)
Only additional thing needed is to activate the edited configuration by
sending one empty request down the pipe. This accomplishes context restore
of the updated kernel context and so the OA configuration gets written out
to it's control registers.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_perf.c | 122 ---
1 file changed, 13 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ccb20230df2c..3d7a052b4cca 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1679,107 +1679,6 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
}
}
-/*
- * Same as gen8_update_reg_state_unlocked only through the batchbuffer. This
- * is only used by the kernel context.
- */
-static int gen8_emit_oa_config(struct i915_request *rq,
- const struct i915_oa_config *oa_config)
-{
- struct drm_i915_private *dev_priv = rq->i915;
- /* The MMIO offsets for Flex EU registers aren't contiguous */
- u32 flex_mmio[] = {
- i915_mmio_reg_offset(EU_PERF_CNTL0),
- i915_mmio_reg_offset(EU_PERF_CNTL1),
- i915_mmio_reg_offset(EU_PERF_CNTL2),
- i915_mmio_reg_offset(EU_PERF_CNTL3),
- i915_mmio_reg_offset(EU_PERF_CNTL4),
- i915_mmio_reg_offset(EU_PERF_CNTL5),
- i915_mmio_reg_offset(EU_PERF_CNTL6),
- };
- u32 *cs;
- int i;
-
- cs = intel_ring_begin(rq, ARRAY_SIZE(flex_mmio) * 2 + 4);
- if (IS_ERR(cs))
- return PTR_ERR(cs);
-
- *cs++ = MI_LOAD_REGISTER_IMM(ARRAY_SIZE(flex_mmio) + 1);
-
- *cs++ = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
- *cs++ = (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
- (dev_priv->perf.oa.periodic ? GEN8_OA_TIMER_ENABLE : 0) |
- GEN8_OA_COUNTER_RESUME;
-
- for (i = 0; i < ARRAY_SIZE(flex_mmio); i++) {
- u32 mmio = flex_mmio[i];
-
- /*
-* This arbitrary default will select the 'EU FPU0 Pipeline
-* Active' event. In the future it's anticipated that there
-* will be an explicit 'No Event' we can select, but not
-* yet...
-*/
- u32 value = 0;
-
- if (oa_config) {
- u32 j;
-
- for (j = 0; j < oa_config->flex_regs_len; j++) {
- if
(i915_mmio_reg_offset(oa_config->flex_regs[j].addr) == mmio) {
- value = oa_config->flex_regs[j].value;
- break;
- }
- }
- }
-
- *cs++ = mmio;
- *cs++ = value;
- }
-
- *cs++ = MI_NOOP;
- intel_ring_advance(rq, cs);
-
- return 0;
-}
-
-static int gen8_switch_to_updated_kernel_context(struct drm_i915_private
*dev_priv,
-const struct i915_oa_config
*oa_config)
-{
- struct intel_engine_cs *engine = dev_priv->engine[RCS];
- struct i915_timeline *timeline;
- struct i915_request *rq;
- int ret;
-
- lockdep_assert_held(&dev_priv->drm.struct_mutex);
-
- i915_retire_requests(dev_priv);
-
- rq = i915_request_alloc(engine, dev_priv->kernel_context);
- if (IS_ERR(rq))
- return PTR_ERR(rq);
-
- ret = gen8_emit_oa_config(rq, oa_config);
- if (ret) {
- i915_request_add(rq);
- return ret;
- }
-
- /* Queue this switch after all other activity */
- list_for_each_entry(timeline, &dev_priv->gt.timelines, link) {
- struct i915_request *prev;
-
- prev = i915_gem_active_raw(&timeline->last_request,
- &dev_priv->drm.struct_mutex);
- if (prev)
- i915_request_await_dma_fence(rq, &prev->fence);
- }
-
- i915_request_add(rq);
-
- return 0;
-}
-
/*
* Manages updating the per-context aspects of the OA stream
* configuration across all contexts.
@@ -1809,16 +1708,11 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
{
struct intel_engine_cs *engine = dev_priv->engine[RCS];
struct i915_gem_context *ctx;
+ struct i915_request *rq;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: fix shifting by a negative number of bits
== Series Details == Series: drm/i915/dp: fix shifting by a negative number of bits URL : https://patchwork.freedesktop.org/series/49565/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4812 -> Patchwork_10156 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49565/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10156 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_guc: fi-skl-guc: NOTRUN -> DMESG-WARN (fdo#107258) igt@kms_pipe_crc_basic@read-crc-pipe-b: fi-byt-clapper: PASS -> FAIL (fdo#107362) +1 igt@kms_psr@primary_page_flip: fi-kbl-7560u: PASS -> FAIL (fdo#107336) Possible fixes igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#107258 https://bugs.freedesktop.org/show_bug.cgi?id=107258 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 == Participating hosts (49 -> 44) == Additional (2): fi-byt-j1900 fi-skl-guc Missing(7): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_4812 -> Patchwork_10156 CI_DRM_4812: 7bed140e1a21dc0e04f2fd87d2726f47b845e82f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10156: bfad517ac799fbbfa711620c387d61e645ed8e67 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == bfad517ac799 drm/i915/dp: fix shifting by a negative number of bits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10156/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for add LG panel to dpcd quirk database (rev2)
== Series Details == Series: add LG panel to dpcd quirk database (rev2) URL : https://patchwork.freedesktop.org/series/49413/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4809_full -> Patchwork_10152_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10152_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) Possible fixes igt@drv_suspend@shrink: shard-kbl: INCOMPLETE (fdo#106886, fdo#103665) -> PASS igt@gem_exec_big: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4809 -> Patchwork_10152 CI_DRM_4809: 398eca316f0ed73de201afc12c4ab1ef3b2890cb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10152: 4947b044fdaf8bac17fdd9c581451e2e0848b9f7 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10152/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/13] drm/i915: Display gtt remapping prep stuff
On Fri, Sep 07, 2018 at 06:24:00PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > A reposting of all the reviewed prep stuff for the gtt remapping. > > Changes since the first posting: > - fix the ilk+ x-tiled stride to be 32k > - split out some unrelated changes (those were already pushed > separately) > - some typos etc. fixed > > Ville Syrjälä (13): > drm/i915: s/tile_offset/aligned_offset/ etc. > drm/i915: Add .max_stride() plane hook > drm/i915: Use pipe A primary plane .max_stride() as the global stride > limit > drm/i915: Rename the plane_state->main/aux to > plane_state->color_plane[] > drm/i915: Store the final plane stride in plane_state > drm/i915: Store ggtt_view in plane_state > drm/i915: s/int plane/int color_plane/ > drm/i915: Nuke plane->can_scale/min_downscale > drm/i915: Extract per-platform plane->check() functions > drm/i915: Move skl plane fb related checks into a better place > drm/i915: Move display w/a #1175 > drm/i915: Move chv rotation checks to plane->check() > drm/i915: Extract intel_cursor_check_surface() Series pushed to dinq. Thanks for the reviews. > > drivers/gpu/drm/i915/intel_atomic_plane.c | 53 --- > drivers/gpu/drm/i915/intel_display.c | 610 > +++--- > drivers/gpu/drm/i915/intel_drv.h | 45 ++- > drivers/gpu/drm/i915/intel_fbc.c | 4 +- > drivers/gpu/drm/i915/intel_fbdev.c| 6 +- > drivers/gpu/drm/i915/intel_sprite.c | 495 +--- > 6 files changed, 700 insertions(+), 513 deletions(-) > > -- > 2.16.4 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Restrict wait to client's timeline on i915_request alloc failure
Let's try not to overly penalize the unlucky client by making them wait
for others to complete their work, and only apply the ratelimit if they
themselves have outstanding work. Still, we apply global reclaim to the
client (we need to scavenge some memory for it) so it doesn't got away
completely scot free.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_request.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 588bc5a4d18b..72bcb4ca0c45 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -733,12 +733,16 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
/* Ratelimit ourselves to prevent oom from malicious clients */
- ret = i915_gem_wait_for_idle(i915,
-I915_WAIT_LOCKED |
-I915_WAIT_INTERRUPTIBLE,
-1);
- if (ret)
+ rq = i915_gem_active_raw(&ce->ring->timeline->last_request,
+&i915->drm.struct_mutex);
+ if (rq && i915_request_wait(rq,
+ I915_WAIT_LOCKED |
+ I915_WAIT_INTERRUPTIBLE,
+ 1) == -EINTR) {
+ ret = -EINTR;
goto err_unreserve;
+ }
+ i915_retire_requests(i915);
/*
* We've forced the client to stall and catch up with whatever
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: fix shifting by a negative number of bits
Function intel_port_to_tc() returns PORT_TC_NONE on error, which is
a negative value -1. In case PORT_TC_NONE is returned, there is an
undefined behavior when shifting by a negative number of bits in
both DP_PHY_MODE_STATUS_NOT_SAFE and P_PHY_MODE_STATUS_COMPLETED
macros.
Fix this by adding sanity checks on intel_port_to_tc return value, before
using macros DP_PHY_MODE_STATUS_NOT_SAFE and P_PHY_MODE_STATUS_COMPLETED.
Addresses-Coverity-ID: 1473324 ("Bad bit shift operation")
Addresses-Coverity-ID: 1473325 ("Bad bit shift operation")
Fixes: 39d1e234e1e1 ("drm/i915/icl: implement the tc/legacy HPD {dis,}connect
flows")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/intel_dp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22d..e34b7b1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4811,6 +4811,11 @@ static bool icl_tc_phy_connect(struct drm_i915_private
*dev_priv,
dig_port->tc_type != TC_PORT_TYPEC)
return true;
+ if (tc_port < 0) {
+ DRM_DEBUG_KMS("Bad TC port %d\n", tc_port);
+ return false;
+ }
+
val = I915_READ(PORT_TX_DFLEXDPPMS);
if (!(val & DP_PHY_MODE_STATUS_COMPLETED(tc_port))) {
DRM_DEBUG_KMS("DP PHY for TC port %d not ready\n", tc_port);
@@ -4857,6 +4862,10 @@ static void icl_tc_phy_disconnect(struct
drm_i915_private *dev_priv,
dig_port->tc_type != TC_PORT_TYPEC)
return;
+ if (tc_port < 0) {
+ DRM_DEBUG_KMS("Bad TC port %d\n", tc_port);
+ return;
+ }
/*
* This function may be called many times in a row without an HPD event
* in between, so try to avoid the write when we can.
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Limit the backpressure for i915_request allocation
Quoting Daniel Vetter (2018-09-12 15:47:21) > On Wed, Sep 12, 2018 at 3:42 PM, Chris Wilson > wrote: > > Quoting Tvrtko Ursulin (2018-09-12 14:34:16) > >> > >> On 12/09/2018 12:11, Chris Wilson wrote: > >> > If we try and fail to allocate a i915_request, we apply some > >> > backpressure on the clients to throttle the memory allocations coming > >> > from i915.ko. Currently, we wait until completely idle, but this is far > >> > too heavy and leads to some situations where the only escape is to > >> > declare a client hung and reset the GPU. The intent is to only ratelimit > >> > the allocation requests, so we need only wait for a jiffie before using > >> > the normal direct reclaim. > >> > > >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 > >> > Signed-off-by: Chris Wilson > >> > Cc: Tvrtko Ursulin > >> > Cc: Joonas Lahtinen > >> > --- > >> > drivers/gpu/drm/i915/i915_request.c | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/drivers/gpu/drm/i915/i915_request.c > >> > b/drivers/gpu/drm/i915/i915_request.c > >> > index 09ed48833b54..588bc5a4d18b 100644 > >> > --- a/drivers/gpu/drm/i915/i915_request.c > >> > +++ b/drivers/gpu/drm/i915/i915_request.c > >> > @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, > >> > struct i915_gem_context *ctx) > >> > ret = i915_gem_wait_for_idle(i915, > >> >I915_WAIT_LOCKED | > >> >I915_WAIT_INTERRUPTIBLE, > >> > - MAX_SCHEDULE_TIMEOUT); > >> > + 1); > >> > if (ret) > >> > goto err_unreserve; > >> > > >> > > >> > >> What is the remaining value of even trying to wait for idle, instead of > >> maybe just i915_request_retire and sleep for a jiffie? The intention > >> would potentially read clearer since it is questionable there is any > >> relationship with idle and rate limiting clients. In fact, now that I > >> think of it, waiting for idle is a nice way to starve an unlucky client > >> forever. > > > > Better to starve the unlucky client, than to allow the entire system to > > grind to a halt. > > > > One caveat to using RCU is that it is our responsibility to apply > > backpressure as none is applied by the vm. > > So instead of 1 jiffie, should we wait for 1 rcu grace period? My > understanding is that under very heavy load these can be extended > (since batching is more effective for throughput, if you don't run out > of memory). Just a random comment from the sidelines really :-) There's (essentially) a wait for that later ;) But a long time ago Paul did write a missive explaining that there should be some use of cond_synchronize_rcu() to provide the rate-limiting, but I've never been sure of a way to plug in the right figures. Do we say if the timeline does more than two RCU allocations within the same grace period it should be throttled? A light allocation failure has always seemed to be a sensible trigger to start worrying. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Limit the backpressure for i915_request allocation
On Wed, Sep 12, 2018 at 3:42 PM, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2018-09-12 14:34:16) >> >> On 12/09/2018 12:11, Chris Wilson wrote: >> > If we try and fail to allocate a i915_request, we apply some >> > backpressure on the clients to throttle the memory allocations coming >> > from i915.ko. Currently, we wait until completely idle, but this is far >> > too heavy and leads to some situations where the only escape is to >> > declare a client hung and reset the GPU. The intent is to only ratelimit >> > the allocation requests, so we need only wait for a jiffie before using >> > the normal direct reclaim. >> > >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 >> > Signed-off-by: Chris Wilson >> > Cc: Tvrtko Ursulin >> > Cc: Joonas Lahtinen >> > --- >> > drivers/gpu/drm/i915/i915_request.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/i915/i915_request.c >> > b/drivers/gpu/drm/i915/i915_request.c >> > index 09ed48833b54..588bc5a4d18b 100644 >> > --- a/drivers/gpu/drm/i915/i915_request.c >> > +++ b/drivers/gpu/drm/i915/i915_request.c >> > @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, >> > struct i915_gem_context *ctx) >> > ret = i915_gem_wait_for_idle(i915, >> >I915_WAIT_LOCKED | >> >I915_WAIT_INTERRUPTIBLE, >> > - MAX_SCHEDULE_TIMEOUT); >> > + 1); >> > if (ret) >> > goto err_unreserve; >> > >> > >> >> What is the remaining value of even trying to wait for idle, instead of >> maybe just i915_request_retire and sleep for a jiffie? The intention >> would potentially read clearer since it is questionable there is any >> relationship with idle and rate limiting clients. In fact, now that I >> think of it, waiting for idle is a nice way to starve an unlucky client >> forever. > > Better to starve the unlucky client, than to allow the entire system to > grind to a halt. > > One caveat to using RCU is that it is our responsibility to apply > backpressure as none is applied by the vm. So instead of 1 jiffie, should we wait for 1 rcu grace period? My understanding is that under very heavy load these can be extended (since batching is more effective for throughput, if you don't run out of memory). Just a random comment from the sidelines really :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Limit the backpressure for i915_request allocation
If we try and fail to allocate a i915_request, we apply some backpressure on the clients to throttle the memory allocations coming from i915.ko. Currently, we wait until completely idle, but this is far too heavy and leads to some situations where the only escape is to declare a client hung and reset the GPU. The intent is to only ratelimit the allocation requests, so we need only wait for a jiffie before using the normal direct reclaim. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 09ed48833b54..588bc5a4d18b 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx) ret = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED | I915_WAIT_INTERRUPTIBLE, -MAX_SCHEDULE_TIMEOUT); +1); if (ret) goto err_unreserve; -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Restrict wait to client's timeline on i915_request alloc failure
Let's try not to overly penalize the unlucky client by making them wait
for others to complete their work, and only apply the ratelimit if they
themselves have outstanding work. Still, we apply global reclaim to the
client (we need to scavenge some memory for it) so it doesn't got away
completely scot free.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_request.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 588bc5a4d18b..4866de572d73 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -733,12 +733,21 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
/* Ratelimit ourselves to prevent oom from malicious clients */
- ret = i915_gem_wait_for_idle(i915,
-I915_WAIT_LOCKED |
-I915_WAIT_INTERRUPTIBLE,
-1);
- if (ret)
- goto err_unreserve;
+ rq = i915_gem_active_raw(&ce->ring->timeline->last_request,
+&i915->drm.struct_mutex);
+ if (rq) {
+ long timeout;
+
+ timeout = i915_request_wait(rq,
+ I915_WAIT_LOCKED |
+ I915_WAIT_INTERRUPTIBLE,
+ 1);
+ if (timeout < 0) {
+ ret = timeout;
+ goto err_unreserve;
+ }
+ }
+ i915_retire_requests(i915);
/*
* We've forced the client to stall and catch up with whatever
--
2.19.0
___
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: Reorder execobject[] to insert non-48b objects into the low 4G
== Series Details == Series: drm/i915: Reorder execobject[] to insert non-48b objects into the low 4G URL : https://patchwork.freedesktop.org/series/49548/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4809_full -> Patchwork_10150_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10150_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10150_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_10150_full: === IGT changes === Warnings igt@kms_cursor_legacy@cursora-vs-flipa-atomic: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10150_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_schedule@preempt-other-chain-vebox: shard-snb: SKIP -> INCOMPLETE (fdo#105411) igt@kms_busy@basic-flip-b: shard-kbl: PASS -> DMESG-WARN (fdo#103313, fdo#103558, fdo#105602) +1 igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +12 igt@kms_plane_scaling@pipe-a-scaler-with-rotation: shard-kbl: PASS -> FAIL (fdo#106026) igt@pm_rpm@system-suspend: shard-kbl: PASS -> DMESG-WARN (fdo#103313) igt@pm_rpm@universal-planes: shard-kbl: PASS -> DMESG-FAIL (fdo#103313, fdo#103558, fdo#105602) Possible fixes igt@drv_suspend@shrink: shard-kbl: INCOMPLETE (fdo#106886, fdo#103665) -> PASS igt@gem_exec_big: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106026 https://bugs.freedesktop.org/show_bug.cgi?id=106026 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4809 -> Patchwork_10150 CI_DRM_4809: 398eca316f0ed73de201afc12c4ab1ef3b2890cb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10150: 6120c5292b7c906538cba66cf5e0e33f16dd49ec @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10150/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 04/25] drm/dp: DRM DP helper/macros to get DP sink DSC parameters
On 9/12/2018 6:25 AM, Manasi Navare wrote:
This patch adds inline functions and helpers for obtaining
DP sink's supported DSC parameters like DSC sink support,
eDP compressed BPP supported, maximum slice count supported
by the sink devices, DSC line buffer bit depth supported on DP sink,
DSC sink maximum color depth by parsing corresponding DPCD registers.
v4:
* Add helper to give line buf bit depth (Manasi)
* Correct the bit masking in color depth helper (manasi)
v3:
* Use SLICE_CAP_2 for DP (Anusha)
v2:
* Add DSC sink support macro (Jani N)
Cc: Gaurav K Singh
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
This patch looks good to me.
Reviewed-by: Gaurav K Singh
---
drivers/gpu/drm/drm_dp_helper.c | 90 +
include/drm/drm_dp_helper.h | 30 +++
2 files changed, 120 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8c6b9fd89f8a..5d5879f115ce 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1337,3 +1337,93 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
drm_dp_desc *desc,
return 0;
}
EXPORT_SYMBOL(drm_dp_read_desc);
+
+/**
+ * DRM DP Helpers for DSC
+ */
+u8 drm_dp_dsc_sink_max_slice_count(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
+ bool is_edp)
+{
+ u8 slice_cap1 = dsc_dpcd[DP_DSC_SLICE_CAP_1 - DP_DSC_SUPPORT];
+
+ if (is_edp) {
+ /* For eDP, register DSC_SLICE_CAPABILITIES_1 gives slice count
*/
+ if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
+ return 4;
+ if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
+ return 2;
+ if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
+ return 1;
+ } else {
+ /* For DP, use values from DSC_SLICE_CAP_1 and DSC_SLICE_CAP2 */
+ u8 slice_cap2 = dsc_dpcd[DP_DSC_SLICE_CAP_2 - DP_DSC_SUPPORT];
+
+ if (slice_cap2 & DP_DSC_24_PER_DP_DSC_SINK)
+ return 24;
+ if (slice_cap2 & DP_DSC_20_PER_DP_DSC_SINK)
+ return 20;
+ if (slice_cap2 & DP_DSC_16_PER_DP_DSC_SINK)
+ return 16;
+ if (slice_cap1 & DP_DSC_12_PER_DP_DSC_SINK)
+ return 12;
+ if (slice_cap1 & DP_DSC_10_PER_DP_DSC_SINK)
+ return 10;
+ if (slice_cap1 & DP_DSC_8_PER_DP_DSC_SINK)
+ return 8;
+ if (slice_cap1 & DP_DSC_6_PER_DP_DSC_SINK)
+ return 6;
+ if (slice_cap1 & DP_DSC_4_PER_DP_DSC_SINK)
+ return 4;
+ if (slice_cap1 & DP_DSC_2_PER_DP_DSC_SINK)
+ return 2;
+ if (slice_cap1 & DP_DSC_1_PER_DP_DSC_SINK)
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
+
+u8 drm_dp_dsc_sink_line_buf_depth(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
+{
+ u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
DP_DSC_SUPPORT];
+
+ switch (line_buf_depth & DP_DSC_LINE_BUF_BIT_DEPTH_MASK) {
+ case DP_DSC_LINE_BUF_BIT_DEPTH_9:
+ return 9;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_10:
+ return 10;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_11:
+ return 11;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_12:
+ return 12;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_13:
+ return 13;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_14:
+ return 14;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_15:
+ return 15;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_16:
+ return 16;
+ case DP_DSC_LINE_BUF_BIT_DEPTH_8:
+ return 8;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dsc_sink_line_buf_depth);
+
+u8 drm_dp_dsc_sink_max_color_depth(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
+{
+ u8 color_depth = dsc_dpcd[DP_DSC_DEC_COLOR_DEPTH_CAP - DP_DSC_SUPPORT];
+
+ if (color_depth & DP_DSC_12_BPC)
+ return 12;
+ if (color_depth & DP_DSC_10_BPC)
+ return 10;
+ if (color_depth & DP_DSC_8_BPC)
+ return 8;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dsc_sink_max_color_depth);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 7f6237cad10d..ce6297908fd6 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1065,6 +1065,36 @@ drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
return dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT;
}
+/* DP/eDP DSC support */
+u8 drm_dp_dsc_sink_max_slice_count(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: set DP Main Stream Attribute for color range on DDI platforms (rev2)
== Series Details == Series: drm/i915: set DP Main Stream Attribute for color range on DDI platforms (rev2) URL : https://patchwork.freedesktop.org/series/48145/ State : failure == Summary == Applying: drm/i915: set DP Main Stream Attribute for color range on DDI platforms Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_reg.h M drivers/gpu/drm/i915/intel_ddi.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_reg.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_reg.h error: Failed to merge in the changes. Patch failed at 0001 drm/i915: set DP Main Stream Attribute for color range on DDI platforms Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [STABLE v4.18 BACKPORT] drm/i915: set DP Main Stream Attribute for color range on DDI platforms
commit 6209c285e7a5e68dbcdf8fd2456c6dd68433806b upstream.
Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.
Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit dae847991a43 ("drm/i915: add
intel_ddi_set_pipe_settings").
Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.
Though not the root cause, the problem was made worse for DDI platforms
with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.
After all these years, the fix boils down to flipping one bit.
[Per testing reports, this fixes DP sinks, but not the LSPCON. My
educated guess is that the LSPCON fails to turn the CEA range MSA into
AVI infoframes for HDMI.]
Reported-by: Michał Kopeć
Reported-by: N. W.
Reported-by: Nicholas Stommel
Reported-by: Tom Yan
Tested-by: Nicholas Stommel
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Cc: # v3.9+
Reviewed-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nik...@intel.com
(cherry picked from commit dc5977da99ea28094b8fa4e9bacbd29bedc41de5)
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7720569f2024..6e048ee88e3f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8825,6 +8825,7 @@ enum skl_power_gate {
#define TRANS_MSA_10_BPC (2<<5)
#define TRANS_MSA_12_BPC (3<<5)
#define TRANS_MSA_16_BPC (4<<5)
+#define TRANS_MSA_CEA_RANGE (1<<3)
/* LCPLL Control */
#define LCPLL_CTL _MMIO(0x130040)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fed26d6e4e27..e195c287c263 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1659,6 +1659,10 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
temp = TRANS_MSA_SYNC_CLK;
+
+ if (crtc_state->limited_color_range)
+ temp |= TRANS_MSA_CEA_RANGE;
+
switch (crtc_state->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Limit the backpressure for i915_request allocation
On 12/09/2018 14:38, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-12 14:34:16) On 12/09/2018 12:11, Chris Wilson wrote: If we try and fail to allocate a i915_request, we apply some backpressure on the clients to throttle the memory allocations coming from i915.ko. Currently, we wait until completely idle, but this is far too heavy and leads to some situations where the only escape is to declare a client hung and reset the GPU. The intent is to only ratelimit the allocation requests, so we need only wait for a jiffie before using the normal direct reclaim. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 09ed48833b54..588bc5a4d18b 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx) ret = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED | I915_WAIT_INTERRUPTIBLE, - MAX_SCHEDULE_TIMEOUT); + 1); if (ret) goto err_unreserve; What is the remaining value of even trying to wait for idle, instead of maybe just i915_request_retire and sleep for a jiffie? There's no point in the wait if actually idle? We just want the retire and kicking of slabs. Why there is no point? If allocation failed and we want to apply backpressure, lets apply it. Why would it matter which client first spotted GPU is idle and skipped the sleep? What would happen if we added a random back-off in this case between some bounds, like Ethernet frames if my memory serves me well. Don't get me wrong, in practice it is minor point, I am purely thinking that the message presence of i915_gem_wait_for_idle is maybe not clear or is misleading. Regards, Tvrtko The intention would potentially read clearer since it is questionable there is any relationship with idle and rate limiting clients. In fact, now that I think of it, waiting for idle is a nice way to starve an unlucky client forever. See i915_gem_shrink. It's a seriously moot point. You can define any pathology you'd like, someone has to lose. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
On Wed, Sep 12, 2018 at 04:18:12PM +0300, Imre Deak wrote:
> Hi Kumar, Takashi,
>
> On Tue, Jun 19, 2018 at 03:01:11PM -0700, Abhay Kumar wrote:
> > From: Ville Syrjälä
> >
> > CDCLK has to be at least twice the BLCK regardless of audio. Audio
> > driver has to probe using this hook and increase the clock even in
> > absence of any display.
> >
> > v2: Use atomic refcount for get_power, put_power so that we can
> > call each once(Abhay).
> > v3: Reset power well 2 to avoid any transaction on iDisp link
> > during cdclk change(Abhay).
> > v4: Remove Power well 2 reset workaround(Ville).
> > v5: Remove unwanted Power well 2 register defined in v4(Abhay).
> >
> > Signed-off-by: Ville Syrjälä
> > Signed-off-by: Abhay Kumar
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > drivers/gpu/drm/i915/intel_audio.c | 67
> > +---
> > drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
> > drivers/gpu/drm/i915/intel_display.c | 7 +++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 5 files changed, 83 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 6104d7115054..a4a386a5db69 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1702,6 +1702,7 @@ struct drm_i915_private {
> > unsigned int hpll_freq;
> > unsigned int fdi_pll_freq;
> > unsigned int czclk_freq;
> > + u32 get_put_refcount;
> >
> > struct {
> > /*
> > @@ -1719,6 +1720,8 @@ struct drm_i915_private {
> > struct intel_cdclk_state actual;
> > /* The current hardware cdclk state */
> > struct intel_cdclk_state hw;
> > +
> > + int force_min_cdclk;
> > } cdclk;
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 3ea566f99450..ca8f04c7cbb3 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder
> > *encoder,
> >
> > if (!connector->eld[0])
> > return;
> > -
> > DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
> > connector->base.id,
> > connector->name,
> > @@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private
> > *dev_priv)
> > }
> > }
> >
> > +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
> > + bool enable)
> > +{
> > + struct drm_modeset_acquire_ctx ctx;
> > + struct drm_atomic_state *state;
> > + int ret;
> > +
> > + drm_modeset_acquire_init(&ctx, 0);
> > + state = drm_atomic_state_alloc(&dev_priv->drm);
> > + if (WARN_ON(!state))
> > + return;
> > +
> > + state->acquire_ctx = &ctx;
> > +
> > +retry:
> > + to_intel_atomic_state(state)->modeset = true;
> > + to_intel_atomic_state(state)->cdclk.force_min_cdclk =
> > + enable ? 2 * 96000 : 0;
> > +
> > + /*
> > +* Protects dev_priv->cdclk.force_min_cdclk
> > +* Need to lock this here in case we have no active pipes
> > +* and thus wouldn't lock it during the commit otherwise.
> > +*/
> > + ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
> > &ctx);
> > + if (!ret)
> > + ret = drm_atomic_commit(state);
>
> Ville mentioned a potential dead-lock problem here: a normal modeset
> enabling an HDMI/DP output with an audio sink will call the
> drm_audio_component_audio_ops::pin_eld_notify() callback with the
> connection_mutex already held. This callback in turn could call
> drm_audio_component_ops::get_power()/put_power() callbacks and
> dead-lock at the above drm_modeset_lock() call.
>
> Looks like that
>
>sound/pci/hda/patch_hdmi.c / intel_pin_eld_notify()->
>check_presence_and_report()->
>hdmi_present_sense()
>
> would prevent this, but for instance
>
>sound/soc/codecs/hdac_hdmi.c / hdac_hdmi_eld_notify_cb()->
>hdac_hdmi_present_sense()->
>hdac_hdmi_jack_report()->
>snd_soc_jack_report()->
>snd_soc_dapm_sync()->
>snd_soc_dapm_sync_unlocked()->
>dapm_power_widgets()->
>dapm_pre_sequence_async()
>
> could call pm_runtime_get_sync() and so I guess also the aops
> get_power() hook.
>
> Could someone in your team check if the above can indeed happen?
>
> > +
> > + if (ret == -EDEADLK) {
> > + drm_atomic_state_clear(state);
> > + drm_modeset_backoff(&ctx);
> > + goto retry;
> > + }
> > +
> > + WARN_ON(ret);
> > +
> > + drm_atomic_state_put(state);
> > +
> > + drm_modeset_drop_locks(&ctx);
> > + drm_modeset_acquire_fini(&ctx);
> > +}
> > +
> > static void i915_audio_component_get_power(struct device *kdev)
> > {
> > - intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
> > + struct drm_i915_private *dev_p
Re: [Intel-gfx] [igt-dev] [PATH i-g-t] igt: Test tagging support
On 12/09/2018 10:07, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-12 09:48:00) On 07/09/2018 12:43, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-07 12:14:20) From: Tvrtko Ursulin Proposal to add test tags as a replacement for separate test list which can be difficult to maintain and get out of date. Putting this maintanenace inline with tests makes it easier to remember to update the (now implicit) lists, and also enables richer test selection possibilities for the test runner. Current method of implying tags from test/subtest names has a couple of problems one of which is where some names can use the same token for different meanings. (One example is the "default" token.) It also creates a name clash between naming and tagging. Test tags are strings of tokens separated by spaces, meaning of which we decide by creating a convetion and helped by the suitable helper macros. For example tags can be things like: gem, kms, basic, guc, flip, semaphore, bz12345678, gt4e, reset, etc.. At runtime this would look something like this (abbreviated for readability): @ tests/gem_sync --list-subtests-with-tags ... forked-each TAGS="gem " forked-store-each TAGS="gem " basic-all TAGS="gem basic " basic-store-all TAGS="gem basic " @ tests/gem_concurrent_blit --list-subtests-with-tags ... 16MiB-swap-gpuX-render-write-read-bcs-bomb TAGS="gem stress " 16MiB-swap-gpuX-render-write-read-rcs-bomb TAGS="gem stress " 16MiB-swap-gpuX-render-gpu-read-after-write-bomb TAGS="gem stress " @ tests/kms_flip --list-subtests-with-tags | grep basic basic-plain-flip TAGS="kms basic " basic-flip-vs-dpms TAGS="kms basic " Test runner could then enable usages like: ./run-tests --include gem --exclude stress Minor comment, I like some basic boolean algebra here --include "gem AND smoketest NOT stress" :) That's what my hypothetical examples showed just with a different syntax! I'd probably tag everything according to which ioctls they use. I feel my endgoal is still to list tests by their kernel functions (which can and should be automatically derived), and their hw function which is the open problem. If we want to do that automatically then tagging in this flavour probably doesn't make sense and it should instead be an external database. If we go on the ioctl granularity it can probably mostly have one version, and it should be static enough to be able to live in the tree, but if we go more granular, like something derived from kcov, then that's out of the window. Since it will be tied both to a platform and kernel version. So I think tagging as proposed here is not appropriate for either, but only if we wanted to tag on coarser functional areas and such. Yeah, I think the same as well, that tags should be "smoke", "stress". (But one man's stress is another's minimal workload :( But both of those are in essence a duration parameter, and I'd prefer if we expressed those as configurable parameters. At which point there is a meta level of test scripts to tag ;) I feel that "gem", "kms" is better expressed in lower level terms, so what's left to tag? Clients? "display", "opencl", "media", "opengl" ? Even using client specs for features (e.g. EGL_IMG_context_priority)? If we overcomplicate and try to change too much at once it is deemed to fail. GEM, KMS, etc, have this advantage of being very established. So I was thinking these basic keywords and then something high level like reset, rps, stolen, and similar. So for instance we can remove the igt_skip_on_simulation, which can be time consuming to answer why it is there, and replace it with --exclude reset,... when running under the simulator. True it is manual work to keep the tags up to date. Is it more work than the current scheme is TBD. Who and why would use those? From a selfish perspective, I want lcov with tests sorted in order of increasing "stress" (start with the precise X does Y test, finish with can it survive pathological client behaviour for 48 hours). Who and why would use which ones? Tags in general, tags in the style the patch proposes, or tags in the flavour you described? My initial idea was that it would make easy for developers to run an approximate sweep when touching a feature. But with good CI and trybot maybe no one would use tags and just rely on "outsourced" test runs? Could be.. but hey, you convinced me to re-send this. Or was it Joonas? :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 02/25] drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT
On 9/12/2018 6:25 AM, Manasi Navare wrote: This patch defines the DP DSC receiver capability size that gives total number of DP DSC DPCD registers. This also adds a missing #defines for DP DSC support missed in the commit id (ab6a46ea6842ce "Add DPCD definitions for DP 1.4 DSC feature") v3: * MIN_SLICE_WIDTH = 2560 (Anusha) * Define DP_DSC_SLICE_WIDTH_MULTIPLIER = 320 v2: * Add SHIFT define and DECOMPRESSION_EN define missed in prev patch Cc: dri-de...@lists.freedesktop.org Cc: Jani Nikula Cc: Ville Syrjala Cc: Anusha Srivatsa Cc: Gaurav K Singh Signed-off-by: Manasi Navare Reviewed-by: Anusha Srivatsa The patch looks good to me. Reviewed-by: Gaurav K Singh --- include/drm/drm_dp_helper.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 698082a02b97..7f6237cad10d 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -231,6 +231,8 @@ #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ +# define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) +# define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 # define DP_DSC_RGB (1 << 0) @@ -279,6 +281,8 @@ # define DP_DSC_THROUGHPUT_MODE_1_1000 (14 << 4) #define DP_DSC_MAX_SLICE_WIDTH 0x06C +#define DP_DSC_MIN_SLICE_WIDTH_VALUE2560 +#define DP_DSC_SLICE_WIDTH_MULTIPLIER 320 #define DP_DSC_SLICE_CAP_2 0x06D # define DP_DSC_16_PER_DP_DSC_SINK (1 << 0) @@ -477,6 +481,7 @@ # define DP_AUX_FRAME_SYNC_VALID (1 << 0) #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ +# define DP_DECOMPRESSION_EN(1 << 0) #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE(1 << 0) @@ -963,6 +968,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 link_status[DP_LINK_STATUS_SI #define DP_BRANCH_OUI_HEADER_SIZE 0xc #define DP_RECEIVER_CAP_SIZE 0xf +#define DP_DSC_RECEIVER_CAP_SIZE0xf #define EDP_PSR_RECEIVER_CAP_SIZE 2 #define EDP_DISPLAY_CTL_CAP_SIZE 3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Limit the backpressure for i915_request allocation
Quoting Tvrtko Ursulin (2018-09-12 14:34:16) > > On 12/09/2018 12:11, Chris Wilson wrote: > > If we try and fail to allocate a i915_request, we apply some > > backpressure on the clients to throttle the memory allocations coming > > from i915.ko. Currently, we wait until completely idle, but this is far > > too heavy and leads to some situations where the only escape is to > > declare a client hung and reset the GPU. The intent is to only ratelimit > > the allocation requests, so we need only wait for a jiffie before using > > the normal direct reclaim. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Joonas Lahtinen > > --- > > drivers/gpu/drm/i915/i915_request.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index 09ed48833b54..588bc5a4d18b 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, > > struct i915_gem_context *ctx) > > ret = i915_gem_wait_for_idle(i915, > >I915_WAIT_LOCKED | > >I915_WAIT_INTERRUPTIBLE, > > - MAX_SCHEDULE_TIMEOUT); > > + 1); > > if (ret) > > goto err_unreserve; > > > > > > What is the remaining value of even trying to wait for idle, instead of > maybe just i915_request_retire and sleep for a jiffie? The intention > would potentially read clearer since it is questionable there is any > relationship with idle and rate limiting clients. In fact, now that I > think of it, waiting for idle is a nice way to starve an unlucky client > forever. Better to starve the unlucky client, than to allow the entire system to grind to a halt. One caveat to using RCU is that it is our responsibility to apply backpressure as none is applied by the vm. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Limit the backpressure for i915_request allocation
Quoting Tvrtko Ursulin (2018-09-12 14:34:16) > > On 12/09/2018 12:11, Chris Wilson wrote: > > If we try and fail to allocate a i915_request, we apply some > > backpressure on the clients to throttle the memory allocations coming > > from i915.ko. Currently, we wait until completely idle, but this is far > > too heavy and leads to some situations where the only escape is to > > declare a client hung and reset the GPU. The intent is to only ratelimit > > the allocation requests, so we need only wait for a jiffie before using > > the normal direct reclaim. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > Cc: Joonas Lahtinen > > --- > > drivers/gpu/drm/i915/i915_request.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index 09ed48833b54..588bc5a4d18b 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, > > struct i915_gem_context *ctx) > > ret = i915_gem_wait_for_idle(i915, > >I915_WAIT_LOCKED | > >I915_WAIT_INTERRUPTIBLE, > > - MAX_SCHEDULE_TIMEOUT); > > + 1); > > if (ret) > > goto err_unreserve; > > > > > > What is the remaining value of even trying to wait for idle, instead of > maybe just i915_request_retire and sleep for a jiffie? There's no point in the wait if actually idle? We just want the retire and kicking of slabs. > The intention > would potentially read clearer since it is questionable there is any > relationship with idle and rate limiting clients. In fact, now that I > think of it, waiting for idle is a nice way to starve an unlucky client > forever. See i915_gem_shrink. It's a seriously moot point. You can define any pathology you'd like, someone has to lose. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Limit the backpressure for i915_request allocation
On 12/09/2018 12:11, Chris Wilson wrote: If we try and fail to allocate a i915_request, we apply some backpressure on the clients to throttle the memory allocations coming from i915.ko. Currently, we wait until completely idle, but this is far too heavy and leads to some situations where the only escape is to declare a client hung and reset the GPU. The intent is to only ratelimit the allocation requests, so we need only wait for a jiffie before using the normal direct reclaim. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 09ed48833b54..588bc5a4d18b 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx) ret = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED | I915_WAIT_INTERRUPTIBLE, -MAX_SCHEDULE_TIMEOUT); +1); if (ret) goto err_unreserve; What is the remaining value of even trying to wait for idle, instead of maybe just i915_request_retire and sleep for a jiffie? The intention would potentially read clearer since it is questionable there is any relationship with idle and rate limiting clients. In fact, now that I think of it, waiting for idle is a nice way to starve an unlucky client forever. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add XYUV format support (rev6)
== Series Details == Series: Add XYUV format support (rev6) URL : https://patchwork.freedesktop.org/series/48007/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4810 -> Patchwork_10154 = == Summary - WARNING == Minor unknown changes coming with Patchwork_10154 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10154, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/48007/revisions/6/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10154: === IGT changes === Warnings igt@pm_rpm@module-reload: fi-hsw-4770r: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_10154 that come from known issues: === IGT changes === Possible fixes igt@drv_hangman@error-state-basic: fi-kbl-7560u: INCOMPLETE -> PASS igt@drv_module_reload@basic-reload-inject: fi-hsw-4770r: DMESG-WARN (fdo#107425) -> PASS igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425 == Participating hosts (50 -> 45) == Additional (1): fi-glk-j4005 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_4810 -> Patchwork_10154 CI_DRM_4810: 4c0e813835d47e6e9285175e7b92e21fe3d4328f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10154: 9490ef9a07aee695e0e1360495c2384ea417ed64 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9490ef9a07ae drm/i915: Adding YUV444 packed format support for skl+ b0a4446bc5d1 drm: Introduce new DRM_FORMAT_XYUV == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10154/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes
On 12.09.2018 13:32, Swati Sharma wrote:
From: Vidya Srinivas
In this patch, a list for icl specific pixel formats is created
in which Y210, Y212 and Y216 pixel formats are added along with
legacy pixel formats for primary and sprite plane.
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_sprite.c | 22 --
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7c68a0d..f341cbd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -105,6 +105,24 @@
DRM_FORMAT_NV12,
};
+static const uint32_t icl_primary_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13725,8 +13743,11 @@ bool skl_plane_has_planar(struct drm_i915_private
*dev_priv,
if (INTEL_GEN(dev_priv) >= 9) {
primary->has_ccs = skl_plane_has_ccs(dev_priv, pipe,
PLANE_PRIMARY);
-
- if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ intel_primary_formats = icl_primary_formats;
+ num_formats = ARRAY_SIZE(icl_primary_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe,
+ PLANE_PRIMARY)) {
Above doesn't look right. I think it could be written "if(gen>=11) {...}
else if(gen>=9){...". Now it looks support for planar formats on ICL is
totally skipped. As is inside skl_plane_has_planar(..) there's check if
running on ICL no planar support is available but it is only until
planar support for ICL is patched in. I suspect you are going to need
icl_primary_formats[] as well as icl_pri_planar_formats[] in similar way
as on SKL. It is similar issue below with changes for intel_sprite.c
/Juha-Pekka
intel_primary_formats = skl_pri_planar_formats;
num_formats = ARRAY_SIZE(skl_pri_planar_formats);
} else {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index f7e2768..2e61fe19 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1281,6 +1281,21 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_NV12,
};
+static uint32_t icl_plane_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1536,8 +1551,11 @@ struct intel_plane *
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
- if (skl_plane_has_planar(dev_priv, pipe,
-PLANE_SPRITE0 + plane)) {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ plane_formats = icl_plane_formats;
+ num_plane_formats = ARRAY_SIZE(icl_plane_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe,
+ PLANE_SPRITE0 + plane)) {
plane_formats = skl_planar_formats;
num_plane_formats = ARRAY_SIZE(skl_planar_formats);
} else {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
+Takashi
On Wed, Sep 12, 2018 at 04:18:12PM +0300, Imre Deak wrote:
> Hi Kumar, Takashi,
>
> On Tue, Jun 19, 2018 at 03:01:11PM -0700, Abhay Kumar wrote:
> > From: Ville Syrjälä
> >
> > CDCLK has to be at least twice the BLCK regardless of audio. Audio
> > driver has to probe using this hook and increase the clock even in
> > absence of any display.
> >
> > v2: Use atomic refcount for get_power, put_power so that we can
> > call each once(Abhay).
> > v3: Reset power well 2 to avoid any transaction on iDisp link
> > during cdclk change(Abhay).
> > v4: Remove Power well 2 reset workaround(Ville).
> > v5: Remove unwanted Power well 2 register defined in v4(Abhay).
> >
> > Signed-off-by: Ville Syrjälä
> > Signed-off-by: Abhay Kumar
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > drivers/gpu/drm/i915/intel_audio.c | 67
> > +---
> > drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
> > drivers/gpu/drm/i915/intel_display.c | 7 +++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 5 files changed, 83 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 6104d7115054..a4a386a5db69 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1702,6 +1702,7 @@ struct drm_i915_private {
> > unsigned int hpll_freq;
> > unsigned int fdi_pll_freq;
> > unsigned int czclk_freq;
> > + u32 get_put_refcount;
> >
> > struct {
> > /*
> > @@ -1719,6 +1720,8 @@ struct drm_i915_private {
> > struct intel_cdclk_state actual;
> > /* The current hardware cdclk state */
> > struct intel_cdclk_state hw;
> > +
> > + int force_min_cdclk;
> > } cdclk;
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 3ea566f99450..ca8f04c7cbb3 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder
> > *encoder,
> >
> > if (!connector->eld[0])
> > return;
> > -
> > DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
> > connector->base.id,
> > connector->name,
> > @@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private
> > *dev_priv)
> > }
> > }
> >
> > +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
> > + bool enable)
> > +{
> > + struct drm_modeset_acquire_ctx ctx;
> > + struct drm_atomic_state *state;
> > + int ret;
> > +
> > + drm_modeset_acquire_init(&ctx, 0);
> > + state = drm_atomic_state_alloc(&dev_priv->drm);
> > + if (WARN_ON(!state))
> > + return;
> > +
> > + state->acquire_ctx = &ctx;
> > +
> > +retry:
> > + to_intel_atomic_state(state)->modeset = true;
> > + to_intel_atomic_state(state)->cdclk.force_min_cdclk =
> > + enable ? 2 * 96000 : 0;
> > +
> > + /*
> > +* Protects dev_priv->cdclk.force_min_cdclk
> > +* Need to lock this here in case we have no active pipes
> > +* and thus wouldn't lock it during the commit otherwise.
> > +*/
> > + ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
> > &ctx);
> > + if (!ret)
> > + ret = drm_atomic_commit(state);
>
> Ville mentioned a potential dead-lock problem here: a normal modeset
> enabling an HDMI/DP output with an audio sink will call the
> drm_audio_component_audio_ops::pin_eld_notify() callback with the
> connection_mutex already held. This callback in turn could call
> drm_audio_component_ops::get_power()/put_power() callbacks and
> dead-lock at the above drm_modeset_lock() call.
>
> Looks like that
>
>sound/pci/hda/patch_hdmi.c / intel_pin_eld_notify()->
>check_presence_and_report()->
>hdmi_present_sense()
>
> would prevent this, but for instance
>
>sound/soc/codecs/hdac_hdmi.c / hdac_hdmi_eld_notify_cb()->
>hdac_hdmi_present_sense()->
>hdac_hdmi_jack_report()->
>snd_soc_jack_report()->
>snd_soc_dapm_sync()->
>snd_soc_dapm_sync_unlocked()->
>dapm_power_widgets()->
>dapm_pre_sequence_async()
>
> could call pm_runtime_get_sync() and so I guess also the aops
> get_power() hook.
>
> Could someone in your team check if the above can indeed happen?
>
> > +
> > + if (ret == -EDEADLK) {
> > + drm_atomic_state_clear(state);
> > + drm_modeset_backoff(&ctx);
> > + goto retry;
> > + }
> > +
> > + WARN_ON(ret);
> > +
> > + drm_atomic_state_put(state);
> > +
> > + drm_modeset_drop_locks(&ctx);
> > + drm_modeset_acquire_fini(&ctx);
> > +}
> > +
> > static void i915_audio_component_get_power(struct device *kdev)
> > {
> > - intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
> > + struct drm_i915_priv
Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
Hi Kumar, Takashi,
On Tue, Jun 19, 2018 at 03:01:11PM -0700, Abhay Kumar wrote:
> From: Ville Syrjälä
>
> CDCLK has to be at least twice the BLCK regardless of audio. Audio
> driver has to probe using this hook and increase the clock even in
> absence of any display.
>
> v2: Use atomic refcount for get_power, put_power so that we can
> call each once(Abhay).
> v3: Reset power well 2 to avoid any transaction on iDisp link
> during cdclk change(Abhay).
> v4: Remove Power well 2 reset workaround(Ville).
> v5: Remove unwanted Power well 2 register defined in v4(Abhay).
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Abhay Kumar
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 ++
> drivers/gpu/drm/i915/intel_audio.c | 67
> +---
> drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
> drivers/gpu/drm/i915/intel_display.c | 7 +++-
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 5 files changed, 83 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6104d7115054..a4a386a5db69 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1702,6 +1702,7 @@ struct drm_i915_private {
> unsigned int hpll_freq;
> unsigned int fdi_pll_freq;
> unsigned int czclk_freq;
> + u32 get_put_refcount;
>
> struct {
> /*
> @@ -1719,6 +1720,8 @@ struct drm_i915_private {
> struct intel_cdclk_state actual;
> /* The current hardware cdclk state */
> struct intel_cdclk_state hw;
> +
> + int force_min_cdclk;
> } cdclk;
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index 3ea566f99450..ca8f04c7cbb3 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder
> *encoder,
>
> if (!connector->eld[0])
> return;
> -
> DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>connector->base.id,
>connector->name,
> @@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private
> *dev_priv)
> }
> }
>
> +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
> + bool enable)
> +{
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_atomic_state *state;
> + int ret;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> + state = drm_atomic_state_alloc(&dev_priv->drm);
> + if (WARN_ON(!state))
> + return;
> +
> + state->acquire_ctx = &ctx;
> +
> +retry:
> + to_intel_atomic_state(state)->modeset = true;
> + to_intel_atomic_state(state)->cdclk.force_min_cdclk =
> + enable ? 2 * 96000 : 0;
> +
> + /*
> + * Protects dev_priv->cdclk.force_min_cdclk
> + * Need to lock this here in case we have no active pipes
> + * and thus wouldn't lock it during the commit otherwise.
> + */
> + ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
> &ctx);
> + if (!ret)
> + ret = drm_atomic_commit(state);
Ville mentioned a potential dead-lock problem here: a normal modeset
enabling an HDMI/DP output with an audio sink will call the
drm_audio_component_audio_ops::pin_eld_notify() callback with the
connection_mutex already held. This callback in turn could call
drm_audio_component_ops::get_power()/put_power() callbacks and
dead-lock at the above drm_modeset_lock() call.
Looks like that
sound/pci/hda/patch_hdmi.c / intel_pin_eld_notify()->
check_presence_and_report()->
hdmi_present_sense()
would prevent this, but for instance
sound/soc/codecs/hdac_hdmi.c / hdac_hdmi_eld_notify_cb()->
hdac_hdmi_present_sense()->
hdac_hdmi_jack_report()->
snd_soc_jack_report()->
snd_soc_dapm_sync()->
snd_soc_dapm_sync_unlocked()->
dapm_power_widgets()->
dapm_pre_sequence_async()
could call pm_runtime_get_sync() and so I guess also the aops
get_power() hook.
Could someone in your team check if the above can indeed happen?
> +
> + if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + }
> +
> + WARN_ON(ret);
> +
> + drm_atomic_state_put(state);
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +}
> +
> static void i915_audio_component_get_power(struct device *kdev)
> {
> - intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
> + struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> +
> + dev_priv->get_put_refcount++;
> +
> + /* Force cdclk to 2*BCLK during first time get power call */
> + if (dev_priv->get_put_refcount == 1)
> + if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_pri
Re: [Intel-gfx] [PATCH] drm/i915/icl: Add POWER_DOMAIN_GT_IRQ to ICL DC_OFF_POWER_DOMAINS
Quoting Ville Syrjälä (2018-09-12 13:48:42) > On Tue, Sep 11, 2018 at 06:19:56PM -0700, José Roberto de Souza wrote: > > Without this gem will not be able to turn off DC states to redunce > > interruption latency when no sink is being driven by driver. > > Do we know that for sure this is still required? Some kind of test > results to confirm would be nice. After all it was working around a bug in the dmc that was meant to be fixed at some point in the future. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Add POWER_DOMAIN_GT_IRQ to ICL DC_OFF_POWER_DOMAINS
On Tue, Sep 11, 2018 at 06:19:56PM -0700, José Roberto de Souza wrote: > Without this gem will not be able to turn off DC states to redunce > interruption latency when no sink is being driven by driver. Do we know that for sure this is still required? Some kind of test results to confirm would be nice. > > Cc: Paulo Zanoni > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 480dadb1047b..af8a0b6ee79b 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -1978,6 +1978,7 @@ void intel_display_power_put(struct drm_i915_private > *dev_priv, >*/ > #define ICL_DISPLAY_DC_OFF_POWER_DOMAINS ( \ > ICL_PW_2_POWER_DOMAINS |\ > + BIT_ULL(POWER_DOMAIN_GT_IRQ) | \ > BIT_ULL(POWER_DOMAIN_MODESET) | \ > BIT_ULL(POWER_DOMAIN_AUX_A) | \ > BIT_ULL(POWER_DOMAIN_INIT)) > -- > 2.18.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Differentiate the lack of an interface from invalid parameter (rev3)
== Series Details == Series: drm: Differentiate the lack of an interface from invalid parameter (rev3) URL : https://patchwork.freedesktop.org/series/49536/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4808_full -> Patchwork_10149_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10149_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_schedule@preempt-hang-blt: shard-snb: NOTRUN -> INCOMPLETE (fdo#105411) igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: shard-glk: PASS -> FAIL (fdo#103167) igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) Possible fixes igt@kms_cursor_crc@cursor-64x64-suspend: shard-snb: INCOMPLETE (fdo#105411) -> PASS +1 igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4808 -> Patchwork_10149 CI_DRM_4808: 1a24d0c172a97f513014071eb0e5532a7d1ccbce @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10149: 5e5ca8579b38a0a7b1757c92ce4be819af472615 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10149/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
On 12.09.2018 13:32, Swati Sharma wrote:
From: Vidya Srinivas
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies a DWORD.
Just to be clear I wouldn't use 'DWORD' here but if it's 64 bits bits
call it so. Not a big issue as its just in the patch comment but still.
Y210:Valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212:Valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216:Valid data occupies 16 bits,
doesn't require any padding bits.
First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.
v2: is_yuv setted to true (mahesh)
different order of yuv samples (mahesh): still update from
hardware team pending
change in comment (alexandru)
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index be1d6aa..143c26a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -190,6 +190,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 139632b..95118cc 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,14 @@
#define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
/*
+ * Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:Cb0:Y1:Cr1 10:10:10:10 little endian */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:Cb0:Y1:Cr1 12:12:12:12 little endian */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
I think what Alexandru-Cosmin Gheorghe meant with earlier review comment
is these defines should be better explained here in part which will be
visible in header file. Looking how other formats have been commented
this would probably be something along the lines of
#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /*
[63:0] Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian */
or something.
/Juha-Pekka
+
+/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
* index 1 = A plane, [7:0] A
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/icl: Add Y210, Y212, Y216 plane control definitions
On 12.09.2018 13:32, Swati Sharma wrote:
From: Vidya Srinivas
Added needed plane control flag definitions for Y210, Y212 and
Y216 formats.
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c80e569..d90d51c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6506,6 +6506,9 @@ enum {
#define PLANE_CTL_FORMAT_RGB_565(14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK (0x1f << 23)
#define PLANE_CTL_PIPE_CSC_ENABLE (1 << 23) /* Pre-GLK */
+#define PLANE_CTL_FORMAT_Y210(1 << 23)
+#define PLANE_CTL_FORMAT_Y212(3 << 23)
+#define PLANE_CTL_FORMAT_Y216(5 << 23)
#define PLANE_CTL_KEY_ENABLE_MASK (0x3 << 21)
#define PLANE_CTL_KEY_ENABLE_SOURCE (1 << 21)
#define PLANE_CTL_KEY_ENABLE_DESTINATION(2 << 21)
Reviewed-by: Juha-Pekka Heikkila
___
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: Limit the backpressure for i915_request allocation
== Series Details == Series: drm/i915: Limit the backpressure for i915_request allocation URL : https://patchwork.freedesktop.org/series/49555/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4809 -> Patchwork_10153 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49555/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10153 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#107139, fdo#105128) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@kms_psr@primary_page_flip: fi-kbl-r: FAIL (fdo#107336) -> PASS fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 == Participating hosts (51 -> 45) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_4809 -> Patchwork_10153 CI_DRM_4809: 398eca316f0ed73de201afc12c4ab1ef3b2890cb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10153: 193b2e33a951f696605d282a49529f35bbb19cb1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 193b2e33a951 drm/i915: Limit the backpressure for i915_request allocation == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10153/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATH i-g-t 1/2] intel: Be consistent with test results on simulation
Quoting Tvrtko Ursulin (2018-09-12 10:33:05) > From: Tvrtko Ursulin > > Tests which call intel_require_memory currently always skip on simulation, > unless they fail first due insufficient memory. This can create different > outcomes depending on the simulation environment so move the simulation > skip to the start of the function for 100% consistency in results. > > Signed-off-by: Tvrtko Ursulin > Cc: Radoslaw Szwichtenberg Makes sense. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATH i-g-t v12 2/2] tests: add slice power programming test
Quoting Tvrtko Ursulin (2018-09-11 15:42:10)
> + last_with_engines = -1;
> + for (class = 0; class < ~0; class++) {
> + for (instance = 0; instance < ~0; instance++) {
> + int ret;
> +
> + sseu.class = class;
> + sseu.instance = instance;
> +
> + ret = __gem_context_set_param(fd, &arg);
> +
> + if (has_engine(fd, class, instance)) {
> + if (engine_supports_sseu(fd, class, instance))
Meh, . I just don't like having hardcoded db on this side of the
ABI. The ABI imo is to ask the kernel if the device/engine is supported,
and should not allow for assumptions.
> +static void
> +test_dynamic(int fd, unsigned int flags)
> +{
> + uint64_t pg_slice_mask = mask_minus_one(__slice_mask__);
> + unsigned int pg_slice_count = __slice_count__ - 1;
> + struct drm_i915_gem_context_param_sseu sseu = { };
> + struct drm_i915_gem_context_param arg =
> + { .param = I915_CONTEXT_PARAM_SSEU,
> + .ctx_id = gem_context_create(fd),
> + .size = sizeof(sseu),
> + .value = to_user_pointer(&sseu) };
> + igt_spin_t *spin = NULL;
> +
> + gem_context_get_param(fd, &arg);
> +
> + /* First set the default mask */
> + if (flags & TEST_BUSY)
> + spin = __spin_sync(fd, arg.ctx_id, I915_EXEC_RENDER);
> +
> + sseu.slice_mask = __slice_mask__;
> + gem_context_set_param(fd, &arg);
I would also suggest a reset test here. Both reset when idle, and by
hangcheck/forced-reset of the spinner & active context.
And across suspend.
> + igt_assert_eq(read_slice_count_busy(fd, arg.ctx_id, 0, spin),
> + __slice_count__);
> + igt_assert_eq(read_slice_count(fd, 0, 0), __slice_count__);
In the read_slice I would suggest having a
igt_assert(gem_bo_busy(spin->handle));
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for add LG panel to dpcd quirk database (rev2)
== Series Details == Series: add LG panel to dpcd quirk database (rev2) URL : https://patchwork.freedesktop.org/series/49413/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4809 -> Patchwork_10152 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49413/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_10152 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_evict: fi-bsw-kefka: PASS -> DMESG-WARN (fdo#107709) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: PASS -> INCOMPLETE (fdo#102657) Possible fixes igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@kms_psr@primary_page_flip: fi-kbl-r: FAIL (fdo#107336) -> PASS fdo#102657 https://bugs.freedesktop.org/show_bug.cgi?id=102657 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107709 https://bugs.freedesktop.org/show_bug.cgi?id=107709 == Participating hosts (51 -> 46) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4809 -> Patchwork_10152 CI_DRM_4809: 398eca316f0ed73de201afc12c4ab1ef3b2890cb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10152: 4947b044fdaf8bac17fdd9c581451e2e0848b9f7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4947b044fdaf drm: add LG eDP panel to quirk database fd3ec3d72559 drm: Change limited M/N quirk to constant N quirk. d9c4e8c40739 drm: Add support for device_id based detection. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10152/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable Y210, Y212, Y216 formats for ICL (rev2)
== Series Details == Series: Enable Y210, Y212, Y216 formats for ICL (rev2) URL : https://patchwork.freedesktop.org/series/48729/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4809 -> Patchwork_10151 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10151 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10151, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/48729/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10151: === IGT changes === Possible regressions igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-icl-u: PASS -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_10151 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) Possible fixes igt@kms_psr@primary_page_flip: fi-kbl-r: FAIL (fdo#107336) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 == Participating hosts (51 -> 46) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4809 -> Patchwork_10151 CI_DRM_4809: 398eca316f0ed73de201afc12c4ab1ef3b2890cb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10151: 8ae9cb919ce46331fe110716ae28db135c8860c8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8ae9cb919ce4 drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes 12f11ab479da drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats 99b3ece40ec8 drm/i915/icl: Add Y210, Y212, Y216 plane control definitions 7d34116618f8 drm: Add Y210, Y212, Y216 format definitions and fourcc == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10151/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/gem_exec_await: Flush vm caches between runs
On allocating a request, we apply some backpressure if we fail to
allocate a request. The backpressure we apply involves waiting for the
device to idle, causing a stall on the clients (trying to throttle heavy
allocators) and as we may be inside a plugged critical section, the only
way to idle the GPU is by waiting for hangcheck to kick in.
Try to avoid the allocation failure by trimming the VM caches between
iterations.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106680
Signed-off-by: Chris Wilson
---
tests/gem_exec_await.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/gem_exec_await.c b/tests/gem_exec_await.c
index 5cfeb8ec8..b9a2c6105 100644
--- a/tests/gem_exec_await.c
+++ b/tests/gem_exec_await.c
@@ -147,6 +147,13 @@ static void wide(int fd, int ring_size, int timeout,
unsigned int flags)
count = 0;
igt_until_timeout(timeout) {
struct timespec start, now;
+
+ /*
+* Flush all caches between runs, we do not want to encounter
+* reclaim in the middle of the plugged critical section.
+*/
+ intel_purge_vm_caches(fd);
+
for (unsigned e = 0; e < nengine; e++) {
uint64_t address;
int i;
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Limit the backpressure for i915_request allocation
If we try and fail to allocate a i915_request, we apply some backpressure on the clients to throttle the memory allocations coming from i915.ko. Currently, we wait until completely idle, but this is far too heavy and leads to some situations where the only escape is to declare a client hung and reset the GPU. The intent is to only ratelimit the allocation requests, so we need only wait for a jiffie before using the normal direct reclaim. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 09ed48833b54..588bc5a4d18b 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -736,7 +736,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx) ret = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED | I915_WAIT_INTERRUPTIBLE, -MAX_SCHEDULE_TIMEOUT); +1); if (ret) goto err_unreserve; -- 2.19.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 Enable Y210, Y212, Y216 formats for ICL (rev2)
== Series Details ==
Series: Enable Y210, Y212, Y216 formats for ICL (rev2)
URL : https://patchwork.freedesktop.org/series/48729/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7d34116618f8 drm: Add Y210, Y212, Y216 format definitions and fourcc
-:38: WARNING:LONG_LINE: line over 100 characters
#38: FILE: drivers/gpu/drm/drm_fourcc.c:193:
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:39: WARNING:LONG_LINE: line over 100 characters
#39: FILE: drivers/gpu/drm/drm_fourcc.c:194:
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:40: WARNING:LONG_LINE: line over 100 characters
#40: FILE: drivers/gpu/drm/drm_fourcc.c:195:
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-:56: WARNING:LONG_LINE_COMMENT: line over 100 characters
#56: FILE: include/uapi/drm/drm_fourcc.h:159:
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:Cb0:Y1:Cr1 10:10:10:10 little endian */
-:57: WARNING:LONG_LINE_COMMENT: line over 100 characters
#57: FILE: include/uapi/drm/drm_fourcc.h:160:
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:Cb0:Y1:Cr1 12:12:12:12 little endian */
-:58: WARNING:LONG_LINE_COMMENT: line over 100 characters
#58: FILE: include/uapi/drm/drm_fourcc.h:161:
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
total: 0 errors, 6 warnings, 0 checks, 23 lines checked
99b3ece40ec8 drm/i915/icl: Add Y210, Y212, Y216 plane control definitions
12f11ab479da drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 48 lines checked
8ae9cb919ce4 drm/i915/icl: Enable Y210, Y212, Y216 format for primary and
sprite planes
___
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: Reorder execobject[] to insert non-48b objects into the low 4G
== Series Details == Series: drm/i915: Reorder execobject[] to insert non-48b objects into the low 4G URL : https://patchwork.freedesktop.org/series/49548/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4809 -> Patchwork_10150 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49548/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10150 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-ilk-650: PASS -> DMESG-WARN (fdo#106387) igt@kms_pipe_crc_basic@read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#107362) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@kms_psr@primary_page_flip: fi-kbl-r: FAIL (fdo#107336) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106387 https://bugs.freedesktop.org/show_bug.cgi?id=106387 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 == Participating hosts (51 -> 46) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4809 -> Patchwork_10150 CI_DRM_4809: 398eca316f0ed73de201afc12c4ab1ef3b2890cb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10150: 6120c5292b7c906538cba66cf5e0e33f16dd49ec @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6120c5292b7c drm/i915: Reorder execobject[] to insert non-48b objects into the low 4G == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10150/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes
From: Vidya Srinivas
In this patch, a list for icl specific pixel formats is created
in which Y210, Y212 and Y216 pixel formats are added along with
legacy pixel formats for primary and sprite plane.
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_sprite.c | 22 --
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7c68a0d..f341cbd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -105,6 +105,24 @@
DRM_FORMAT_NV12,
};
+static const uint32_t icl_primary_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -13725,8 +13743,11 @@ bool skl_plane_has_planar(struct drm_i915_private
*dev_priv,
if (INTEL_GEN(dev_priv) >= 9) {
primary->has_ccs = skl_plane_has_ccs(dev_priv, pipe,
PLANE_PRIMARY);
-
- if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ intel_primary_formats = icl_primary_formats;
+ num_formats = ARRAY_SIZE(icl_primary_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe,
+ PLANE_PRIMARY)) {
intel_primary_formats = skl_pri_planar_formats;
num_formats = ARRAY_SIZE(skl_pri_planar_formats);
} else {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index f7e2768..2e61fe19 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1281,6 +1281,21 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device
*dev, void *data,
DRM_FORMAT_NV12,
};
+static uint32_t icl_plane_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
+};
+
static const uint64_t skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1536,8 +1551,11 @@ struct intel_plane *
intel_plane->disable_plane = skl_disable_plane;
intel_plane->get_hw_state = skl_plane_get_hw_state;
- if (skl_plane_has_planar(dev_priv, pipe,
-PLANE_SPRITE0 + plane)) {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ plane_formats = icl_plane_formats;
+ num_plane_formats = ARRAY_SIZE(icl_plane_formats);
+ } else if (skl_plane_has_planar(dev_priv, pipe,
+ PLANE_SPRITE0 + plane)) {
plane_formats = skl_planar_formats;
num_plane_formats = ARRAY_SIZE(skl_planar_formats);
} else {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/4] Enable Y210, Y212, Y216 formats for ICL
These patches enable packed format YUV422-Y210, Y212 and Y216 for 10, 12 and 16 bit respectively for ICL. For user space component IGT:WIP v2: addressed review comments of mahesh and alexandru hdr handling of these 64 bit pixel format not inscope of this series Vidya Srinivas (4): drm: Add Y210, Y212, Y216 format definitions and fourcc drm/i915/icl: Add Y210, Y212, Y216 plane control definitions drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats drm/i915/icl: Enable Y210, Y212, Y216 format for primary and sprite planes drivers/gpu/drm/drm_fourcc.c | 3 +++ drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_display.c | 40 ++-- drivers/gpu/drm/i915/intel_sprite.c | 25 -- include/uapi/drm/drm_fourcc.h| 8 5 files changed, 75 insertions(+), 4 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915/icl: Add Y210, Y212, Y216 plane control definitions
From: Vidya Srinivas
Added needed plane control flag definitions for Y210, Y212 and
Y216 formats.
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c80e569..d90d51c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6506,6 +6506,9 @@ enum {
#define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
#define ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
#define PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
+#define PLANE_CTL_FORMAT_Y210(1 << 23)
+#define PLANE_CTL_FORMAT_Y212(3 << 23)
+#define PLANE_CTL_FORMAT_Y216(5 << 23)
#define PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
#define PLANE_CTL_KEY_ENABLE_SOURCE (1 << 21)
#define PLANE_CTL_KEY_ENABLE_DESTINATION (2 << 21)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc
From: Vidya Srinivas
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies a DWORD.
Y210:Valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212:Valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216:Valid data occupies 16 bits,
doesn't require any padding bits.
First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.
v2: is_yuv setted to true (mahesh)
different order of yuv samples (mahesh): still update from
hardware team pending
change in comment (alexandru)
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index be1d6aa..143c26a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -190,6 +190,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 139632b..95118cc 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,14 @@
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
/*
+ * Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0]
Y0:Cb0:Y1:Cr1 10:10:10:10 little endian */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0]
Y0:Cb0:Y1:Cr1 12:12:12:12 little endian */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian */
+
+/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
* index 1 = A plane, [7:0] A
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/icl: Preparations for enabling Y210, Y212, Y216 formats
From: Vidya Srinivas
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
drivers/gpu/drm/i915/intel_sprite.c | 3 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2b77d93..7c68a0d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3512,6 +3512,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_Y210:
+ return PLANE_CTL_FORMAT_Y210;
+ case DRM_FORMAT_Y212:
+ return PLANE_CTL_FORMAT_Y212;
+ case DRM_FORMAT_Y216:
+ return PLANE_CTL_FORMAT_Y216;
default:
MISSING_CASE(pixel_format);
}
@@ -4960,6 +4966,9 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format
0x%x\n",
@@ -13422,6 +13431,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
@@ -14551,6 +14563,9 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YVYU:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
drm_get_format_name(mode_cmd->pixel_format, &format_name));
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 9600ccf..f7e2768 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1419,6 +1419,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_Y210:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
case DRM_FORMAT_NV12:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Reorder execobject[] to insert non-48b objects into the low 4G
If the caller supplies more than 4G of objects and than one that has to be in the low 4G, it is possible for the low 4G to be full before we attempt to find room for the last object that must be there. As we don't reorder the two types, every pass hits the same problem and we fail with ENOSPC. However, if we impose a little bit of ordering between the two classes of objects, on the second pass we will be able to fit the special object as we do it first. For setups that only use !48b objects, we now reverse the order between passes, hopefully making the subsequent passes more likely to succeed given that we are trying a different order (rather than repeating the previous pass!) v2: Quick one line explanation for the relative priorities given to reservations. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index aaa8a26aae86..09187286d346 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -693,9 +693,14 @@ static int eb_reserve(struct i915_execbuffer *eb) eb_unreserve_vma(vma, &eb->flags[i]); if (flags & EXEC_OBJECT_PINNED) + /* Pinned must have their slot */ list_add(&vma->exec_link, &eb->unbound); else if (flags & __EXEC_OBJECT_NEEDS_MAP) + /* Map require the lowest 256MiB (aperture) */ list_add_tail(&vma->exec_link, &eb->unbound); + else if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS)) + /* Prioritise 4GiB region for restricted bo */ + list_add(&vma->exec_link, &last); else list_add_tail(&vma->exec_link, &last); } -- 2.19.0 ___ 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: Differentiate the lack of an interface from invalid parameter (rev3)
== Series Details ==
Series: drm: Differentiate the lack of an interface from invalid parameter
(rev3)
URL : https://patchwork.freedesktop.org/series/49536/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4808 -> Patchwork_10149 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49536/revisions/3/mbox/
== Known issues ==
Here are the changes found in Patchwork_10149 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_exec_suspend@basic-s3:
fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718)
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
igt@kms_psr@primary_mmap_gtt:
{fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3
igt@kms_psr@sprite_plane_onoff:
fi-bdw-samus: NOTRUN -> FAIL (fdo#107360, fdo#107383)
igt@pm_rpm@module-reload:
fi-hsw-peppy: NOTRUN -> DMESG-WARN (fdo#107603)
fi-bdw-samus: NOTRUN -> DMESG-WARN (fdo#107603)
Possible fixes
igt@drv_selftest@live_hangcheck:
fi-skl-guc: DMESG-FAIL (fdo#106685) -> PASS
igt@kms_frontbuffer_tracking@basic:
fi-byt-clapper: FAIL (fdo#103167) -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-a:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
igt@kms_psr@primary_page_flip:
fi-whl-u: FAIL (fdo#107336) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#106685 https://bugs.freedesktop.org/show_bug.cgi?id=106685
fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
fdo#107360 https://bugs.freedesktop.org/show_bug.cgi?id=107360
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
fdo#107603 https://bugs.freedesktop.org/show_bug.cgi?id=107603
fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
== Participating hosts (47 -> 46) ==
Additional (4): fi-hsw-peppy fi-cnl-u fi-icl-u fi-bdw-samus
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4808 -> Patchwork_10149
CI_DRM_4808: 1a24d0c172a97f513014071eb0e5532a7d1ccbce @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10149: 5e5ca8579b38a0a7b1757c92ce4be819af472615 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5e5ca8579b38 drm: Differentiate the lack of an interface from invalid parameter
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10149/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/26] drm/i915: Reorder execobject[] to insert non-48b objects into the low 4G
Quoting Chris Wilson (2018-09-11 14:57:46) > If the caller supplies more than 4G of objects and than one that has to > be in the low 4G, it is possible for the low 4G to be full before we > attempt to find room for the last object that must be there. As we don't > reorder the two types, every pass hits the same problem and we fail with > ENOSPC. However, if we impose a little bit of ordering between the two > classes of objects, on the second pass we will be able to fit the > special object as we do it first. For setups that only use !48b objects, > we now reverse the order between passes, hopefully making the subsequent > passes more likely to succeed given that we are trying a different > order (rather than repeating the previous pass!) > > Signed-off-by: Chris Wilson Might be worthy dropping a one-liner comment in the fashion of. /* Avoid congesting 4GB region required for last object. */ Reviewed-by: Joonas Lahtinen Regards, Joonas > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 22b4cb775576..d70d142f5338 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -696,6 +696,8 @@ static int eb_reserve(struct i915_execbuffer *eb) > list_add(&vma->exec_link, &eb->unbound); > else if (flags & __EXEC_OBJECT_NEEDS_MAP) > list_add_tail(&vma->exec_link, &eb->unbound); > + else if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS)) > + list_add(&vma->exec_link, &last); > else > list_add_tail(&vma->exec_link, &last); > } > -- > 2.19.0.rc2 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/ringbuffer: Reload PDs harder on byt/bcs
Quoting Chris Wilson (2018-09-10 14:08:08) > Baytrail takes a little more convincing that it needs to actually reload > its Page Directoy (ppGTT) before the context switch, so repeat it until > it gets the message. Once again the arbitrary values here are > empirically derived. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107861 > Testcase: igt/gem_exec_parallel/fds > Signed-off-by: Chris Wilson From another thread, Reviewed-by: Joonas Lahtinen Ta, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 12/13] drm/i915/icl: Define TRANS_DSI_FUNC_CONF register
On Wed, 12 Sep 2018, Madhav Chauhan wrote: > On 9/12/2018 1:00 AM, Jani Nikula wrote: >> On Tue, 10 Jul 2018, Madhav Chauhan wrote: >> The convention is to define macros for field values that you can OR >> directly in place instead of requiring a shift. Please stick to the >> conventions. Use _SHIFT and _MASK. >> >> We can debate the relative merits of both approaches at some point, but >> this is not the time. > > Just to understand this point correctly, > > #define OP_MODE(x) ((x) << 28) is OK This is acceptable when the values for the field are *not* defined as separate macros. The convention is that the values for fields are defined already shifted in place, and that would conflict. > but > #define OP_MODE_MASK (0x3 << 28) is NOT OK This is okay and recommended. > and should be: > #define OP_MODE_MASK0x3 This is not okay. > #define OP_MODE_SHIFT 28 This is okay. Please read the big comment with examples near the top of i915_reg.h, and let me know which part is not clear from that. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
