Re: [Intel-gfx] [PATCH] drm/i915: Release power well if load DMC failed
On Wed, 21 Nov 2018, "Jani Nikula" wrote:
>On Wed, 21 Nov 2018, "Lee, Shawn C" wrote:
>> On Tue, 20 Nov 2018, "Jani Nikula" wrote:
>>>On Wed, 21 Nov 2018, "Lee, Shawn C" wrote:
On Tue, 20 Nov 2018, "Jani Nikula" wrote:
>> Driver obtain power well at intel_csr_ucode_init().
>> And release it after load DMC firmware successful.
>
>Correct.
>
>> An issue happened when DMC was not found or failed to load. Power
>> well would not be released and just output some error messages.
>> Driver have to release power well properly to keep put/get balance.
>
>No. We intentionally do not release it until dmc firmware load succeeds.
If load DMC failed, we found DP phy was always on even without
external display connected. So it looks like an expected behavior,
right?
>>>
>>>I'll put it this way, we don't really go out of our way to support
>>>everything without the DMC firmware. Every choice like this doubles the
>>>testing requirements.
>>>
>>
>> Understood. This is not a normal case (without DMC) on customer
>> system. We just think it will be better to release power well if we
>> already got it before.
>
>Why are you supporting a non-DMC setup on a customer system? Don't do it.
>
As we mention before. It is an abnormal case that DMC was lost on customer
system.
Then we got an issue like this. Everything works normally if DMC is available.
Thanks for comments!
>BR,
>Jani.
>
>>
>>>Do you see issues with DMC firmware loaded? Do you have issues with loading
>>>DMC firmware?
>>
>> No issue with DMC firmware loaded. Thanks!
>>
>>>
>>>BR,
>>>Jani.
>>>
>>>
>
>See the comment in intel_csr_ucode_init(), as well as this in the branch
>where dmc load fails:
>
> dev_notice(dev_priv->drm.dev,
> "Failed to load DMC firmware %s."
> " Disabling runtime power management.\n",
> csr->fw_path);
>
>We don't support runtime pm without dmc on platforms with dmc.
>
>BR,
>Jani.
>
>>
>> Cc: Jani Nikula
>> Cc: Rodrigo Vivi
>> Cc: Jose Roberto de Souza
>> Cc: Cooper Chiou
>>
>> Signed-off-by: Lee, Shawn C
>> ---
>> drivers/gpu/drm/i915/intel_csr.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_csr.c
>> b/drivers/gpu/drm/i915/intel_csr.c
>> index a516697bf57d..8d04d7b6f00a 100644
>> --- a/drivers/gpu/drm/i915/intel_csr.c
>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>> @@ -425,8 +425,6 @@ static void csr_load_work_fn(struct work_struct
>> *work)
>> if (dev_priv->csr.dmc_payload) {
>> intel_csr_load_program(dev_priv);
>>
>> -intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
>> -
>> DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
>> dev_priv->csr.fw_path,
>> CSR_VERSION_MAJOR(csr->version), @@ -440,6
>> +438,7 @@ static
>> void csr_load_work_fn(struct work_struct *work)
>> INTEL_UC_FIRMWARE_URL);
>> }
>>
>> +intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
>> release_firmware(fw);
>> }
>
>--
>Jani Nikula, Intel Open Source Graphics Center
>>>
>>>--
>>>Jani Nikula, Intel Open Source Graphics Center
>
>--
>Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse
== Series Details == Series: series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse URL : https://patchwork.freedesktop.org/series/52848/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5183_full -> Patchwork_10883_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10883_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10883_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_10883_full: === IGT changes === Warnings igt@kms_universal_plane@disable-primary-vs-flip-pipe-b: shard-snb: SKIP -> PASS +9 igt@perf_pmu@rc6-runtime-pm-long: shard-kbl: PASS -> SKIP igt@tools_test@tools_test: shard-apl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10883_full that come from known issues: === IGT changes === Issues hit igt@gem_cpu_reloc@full: shard-skl: NOTRUN -> INCOMPLETE (fdo#108073) igt@gem_exec_schedule@pi-ringfull-vebox: shard-skl: NOTRUN -> FAIL (fdo#103158) igt@gem_mmap_gtt@forked-big-copy-odd: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@kms_busy@extended-modeset-hang-newfb-render-a: shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +4 igt@kms_color@pipe-b-degamma: shard-skl: PASS -> FAIL (fdo#104782) igt@kms_cursor_crc@cursor-128x42-sliding: shard-glk: PASS -> FAIL (fdo#103232) igt@kms_cursor_crc@cursor-64x21-random: shard-apl: PASS -> FAIL (fdo#103232) +2 igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#102887, fdo#105363) igt@kms_flip@plain-flip-ts-check: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602, fdo#103313) +4 igt@kms_frontbuffer_tracking@fbc-1p-rte: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#103313) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: shard-glk: PASS -> FAIL (fdo#103167) +3 igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render: shard-skl: PASS -> FAIL (fdo#103167) igt@kms_frontbuffer_tracking@fbcpsr-stridechange: shard-skl: NOTRUN -> FAIL (fdo#105683) igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite: shard-skl: NOTRUN -> FAIL (fdo#103167) igt@kms_plane@pixel-format-pipe-b-planes: shard-skl: NOTRUN -> DMESG-WARN (fdo#106885) igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: shard-skl: NOTRUN -> FAIL (fdo#108145) +1 igt@kms_plane_multiple@atomic-pipe-a-tiling-y: shard-apl: PASS -> FAIL (fdo#103166) +1 igt@kms_plane_multiple@atomic-pipe-b-tiling-x: shard-glk: PASS -> FAIL (fdo#103166) +1 igt@kms_rotation_crc@primary-rotation-90: shard-skl: PASS -> FAIL (fdo#107815, fdo#103925) Possible fixes igt@gem_exec_schedule@preemptive-hang-render: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@kms_cursor_crc@cursor-256x256-onscreen: shard-glk: FAIL (fdo#103232) -> PASS +1 igt@kms_cursor_crc@cursor-64x21-sliding: shard-apl: FAIL (fdo#103232) -> PASS +3 igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled: shard-glk: FAIL (fdo#103184) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: shard-glk: FAIL (fdo#103167) -> PASS +1 igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS igt@kms_plane@plane-position-covered-pipe-c-planes: shard-apl: FAIL (fdo#103166) -> PASS igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: shard-glk: DMESG-WARN (fdo#106538, fdo#105763) -> PASS +4 igt@pm_rpm@universal-planes-dpms: shard-skl: INCOMPLETE (fdo#107807) -> PASS +1 Warnings igt@i915_suspend@shrink: shard-skl: DMESG-WARN (fdo#108784) -> INCOMPLETE (fdo#106886) igt@kms_plane@pixel-format-pipe-a-planes: shard-skl: DMESG-FAIL (fdo#103166, fdo#106885) -> FAIL (fdo#103166) fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184 fdo#103232
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Show waiter's status on engine dump (rev2)
== Series Details ==
Series: drm/i915: Show waiter's status on engine dump (rev2)
URL : https://patchwork.freedesktop.org/series/52825/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5181_full -> Patchwork_10880_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10880_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10880_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_10880_full:
=== IGT changes ===
Warnings
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-blt:
shard-hsw: SKIP -> PASS
igt@pm_rc6_residency@rc6-accuracy:
shard-kbl: SKIP -> PASS
shard-snb: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_10880_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@gem_userptr_blits@readonly-unsync:
shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359)
igt@i915_suspend@shrink:
{shard-iclb}: NOTRUN -> DMESG-WARN (fdo#108784)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
{shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107956)
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +1
igt@kms_color@pipe-a-legacy-gamma:
shard-apl: PASS -> FAIL (fdo#104782, fdo#108145)
igt@kms_cursor_crc@cursor-256x256-offscreen:
shard-skl: PASS -> FAIL (fdo#103232)
igt@kms_cursor_crc@cursor-64x21-sliding:
{shard-iclb}: NOTRUN -> FAIL (fdo#103232) +1
igt@kms_cursor_crc@cursor-64x64-random:
shard-glk: PASS -> FAIL (fdo#103232)
igt@kms_cursor_legacy@flip-vs-cursor-atomic:
{shard-iclb}: PASS -> DMESG-WARN (fdo#107724) +12
igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic:
{shard-iclb}: PASS -> DMESG-WARN (fdo#107724, fdo#108336) +5
igt@kms_fbcon_fbt@psr-suspend:
{shard-iclb}: NOTRUN -> FAIL (fdo#107882)
igt@kms_flip@2x-wf_vblank-ts-check:
shard-hsw: PASS -> DMESG-FAIL (fdo#102614)
igt@kms_flip@flip-vs-modeset-interruptible:
shard-hsw: PASS -> DMESG-WARN (fdo#102614)
igt@kms_flip@plain-flip-fb-recreate-interruptible:
shard-skl: PASS -> FAIL (fdo#100368)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
shard-apl: PASS -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
{shard-iclb}: PASS -> DMESG-FAIL (fdo#107724) +4
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
shard-glk: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite:
{shard-iclb}: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite:
{shard-iclb}: NOTRUN -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@psr-suspend:
{shard-iclb}: PASS -> DMESG-FAIL (fdo#107724, fdo#103167)
igt@kms_hdmi_inject@inject-audio:
{shard-iclb}: NOTRUN -> FAIL (fdo#102370)
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-glk: PASS -> FAIL (fdo#103166)
igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
{shard-iclb}: PASS -> FAIL (fdo#103166) +2
igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
shard-apl: PASS -> FAIL (fdo#103166)
igt@kms_setmode@basic:
shard-kbl: PASS -> FAIL (fdo#99912)
igt@kms_sysfs_edid_timing:
shard-skl: NOTRUN -> FAIL (fdo#100047)
igt@pm_rpm@dpms-non-lpsp:
shard-skl: SKIP -> INCOMPLETE (fdo#107807)
igt@pm_rpm@system-suspend-modeset:
shard-skl: PASS -> INCOMPLETE (fdo#107807, fdo#104108,
fdo#107773)
{igt@runner@aborted}:
{shard-iclb}: NOTRUN -> FAIL (fdo#108315)
Possible fixes
igt@kms_atomic_transition@1x-modeset-transitions:
shard-hsw: DMESG-FAIL (fdo#102614) -> PASS
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
shard-snb: DMESG-WARN (fdo#107956) -> PASS
igt@kms_cursor_crc@cursor-128x42-sliding:
shard-glk: FAIL (fdo#103232) -> PASS
igt@kms_cursor_crc@cursor-256x256-random:
shard-apl: FAIL (fdo#103232) -> PASS +2
igt@kms_cursor_crc@cursor-256x85-random:
shard-hsw: DMESG-FAIL (fdo#103232, fdo#102614) -> PASS
igt@kms_cursor_crc@cursor-64x64-suspend:
shard-skl: INCOMPLETE (fdo#104108) -> PASS
igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic:
shard-hsw:
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add HAS_DISPLAY() and use it
On Tue, Nov 20, 2018 at 02:32:40PM -0800, José Roberto de Souza wrote:
> Right now it is decided if GEN has display by checking the num_pipes,
> so lets make it explicit and use a macro.
>
> Cc: Lucas De Marchi
> Cc: Jani Nikula
> Signed-off-by: José Roberto de Souza
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.c | 10 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_bios.c| 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 4 ++--
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
> drivers/gpu/drm/i915/intel_i2c.c | 2 +-
> 7 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b1d23c73c147..5e2d91f4dd2d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -287,7 +287,7 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
>* Use PCH_NOP (PCH but no South Display) for PCH platforms without
>* display.
>*/
> - if (pch && INTEL_INFO(dev_priv)->num_pipes == 0) {
> + if (pch && !HAS_DISPLAY(dev_priv)) {
> DRM_DEBUG_KMS("Display disabled, reverting to NOP PCH\n");
> dev_priv->pch_type = PCH_NOP;
> dev_priv->pch_id = 0;
> @@ -645,7 +645,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
> if (i915_inject_load_failure())
> return -ENODEV;
>
> - if (INTEL_INFO(dev_priv)->num_pipes) {
> + if (HAS_DISPLAY(dev_priv)) {
> ret = drm_vblank_init(_priv->drm,
> INTEL_INFO(dev_priv)->num_pipes);
> if (ret)
> @@ -696,7 +696,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>
> intel_overlay_setup(dev_priv);
>
> - if (INTEL_INFO(dev_priv)->num_pipes == 0)
> + if (!HAS_DISPLAY(dev_priv))
> return 0;
>
> ret = intel_fbdev_init(dev);
> @@ -1551,7 +1551,7 @@ static void i915_driver_register(struct
> drm_i915_private *dev_priv)
> } else
> DRM_ERROR("Failed to register driver for userspace access!\n");
>
> - if (INTEL_INFO(dev_priv)->num_pipes) {
> + if (HAS_DISPLAY(dev_priv)) {
> /* Must be done after probing outputs */
> intel_opregion_register(dev_priv);
> acpi_video_register();
> @@ -1575,7 +1575,7 @@ static void i915_driver_register(struct
> drm_i915_private *dev_priv)
>* We need to coordinate the hotplugs with the asynchronous fbdev
>* configuration, for which we use the fbdev->async_cookie.
>*/
> - if (INTEL_INFO(dev_priv)->num_pipes)
> + if (HAS_DISPLAY(dev_priv))
> drm_kms_helper_poll_init(dev);
>
> intel_power_domains_enable(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 21e4405e2168..3cdbb3d074db 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2568,6 +2568,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define GT_FREQUENCY_MULTIPLIER 50
> #define GEN9_FREQ_SCALER 3
>
> +#define HAS_DISPLAY(dev_priv) (INTEL_INFO(dev_priv)->num_pipes > 0)
> +
> #include "i915_trace.h"
>
> static inline bool intel_vtd_active(void)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 0694aa8bb9bc..6d3e0260d49c 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1752,7 +1752,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
> const struct bdb_header *bdb;
> u8 __iomem *bios = NULL;
>
> - if (INTEL_INFO(dev_priv)->num_pipes == 0) {
> + if (!HAS_DISPLAY(dev_priv)) {
> DRM_DEBUG_KMS("Skipping VBT init due to disabled display.\n");
> return;
> }
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index ceecb5bd5226..677002a9e893 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -782,7 +782,7 @@ void intel_device_info_runtime_init(struct
> intel_device_info *info)
> if (i915_modparams.disable_display) {
> DRM_INFO("Display disabled (module parameter)\n");
> info->num_pipes = 0;
> - } else if (info->num_pipes > 0 &&
> + } else if (HAS_DISPLAY(dev_priv) &&
> (IS_GEN7(dev_priv) || IS_GEN8(dev_priv)) &&
> HAS_PCH_SPLIT(dev_priv)) {
> u32 fuse_strap = I915_READ(FUSE_STRAP);
> @@ -807,7 +807,7 @@ void intel_device_info_runtime_init(struct
> intel_device_info *info)
> DRM_INFO("PipeC fused off\n");
> info->num_pipes -= 1;
> }
> - } else if (info->num_pipes
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Downgrade unknown CSR firmware warnings
On Wed, Nov 21, 2018 at 11:29:02AM +0200, Jani Nikula wrote:
> On Fri, 16 Nov 2018, Lucas De Marchi wrote:
> > Like it was done in commit 9e180d9991dc ("drm/i915: Downgrade unknown
> > firmware warnings") for huc and guc: downgrade CSR firmware warnings. If
> > we have released no firmware yet for a platform, stop scaring the
> > consumer and merely note its expected absence.
> >
> > By simply removing the warning and early return we hit the condition
> > with the appropriate message.
> >
> > Cc: Chris Wilson
> > Cc: Joonas Lahtinen
> > Signed-off-by: Lucas De Marchi
>
> *sigh*
>
> This patch would not have been needed at all with patch 1/2.
>
> The point was that we shouldn't proceed without the max fw size
> set. Even with the module parameter. Because that would fail at the
> firmware loading stage later.
>
> If the warn was such a big deal, it should've been changed to a debug
> message with an early return, not removed.
This was only done to make the code similar to the huc/guc. As I see
this would only be a problem in case we did pass a firmware via param
and not being gen >= 12.
Otherwise the warning (for !alpha) and debug message is unified in a
single place, down a few lines in the same function.
Lucas De Marchi
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/intel_csr.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index b4476d891fa3..a516697bf57d 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -496,9 +496,6 @@ void intel_csr_ucode_init(struct drm_i915_private
> > *dev_priv)
> > csr->fw_path = BXT_CSR_PATH;
> > csr->required_version = BXT_CSR_VERSION_REQUIRED;
> > csr->max_fw_size = BXT_CSR_MAX_FW_SIZE;
> > - } else {
> > - MISSING_CASE(INTEL_REVID(dev_priv));
> > - return;
> > }
> >
> > if (i915_modparams.dmc_firmware_path) {
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
== Series Details ==
Series: drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
URL : https://patchwork.freedesktop.org/series/52822/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5181_full -> Patchwork_10877_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10877_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10877_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_10877_full:
=== IGT changes ===
Warnings
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-blt:
shard-hsw: SKIP -> PASS
igt@perf_pmu@rc6-runtime-pm-long:
shard-kbl: PASS -> SKIP +1
igt@pm_rc6_residency@rc6-accuracy:
shard-kbl: SKIP -> PASS
shard-snb: PASS -> SKIP
igt@tools_test@tools_test:
{shard-iclb}: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_10877_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@i915_suspend@shrink:
{shard-iclb}: NOTRUN -> DMESG-WARN (fdo#108784)
igt@kms_busy@extended-modeset-hang-newfb-render-b:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
{shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107956)
igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
shard-glk: PASS -> FAIL (fdo#108145)
igt@kms_color@pipe-a-legacy-gamma:
shard-apl: PASS -> FAIL (fdo#108145, fdo#104782)
igt@kms_cursor_crc@cursor-128x128-suspend:
shard-skl: PASS -> FAIL (fdo#103191, fdo#103232)
igt@kms_cursor_crc@cursor-64x21-sliding:
{shard-iclb}: NOTRUN -> FAIL (fdo#103232) +1
igt@kms_cursor_crc@cursor-64x64-onscreen:
shard-skl: PASS -> FAIL (fdo#103232) +1
igt@kms_fbcon_fbt@psr-suspend:
{shard-iclb}: NOTRUN -> FAIL (fdo#107882)
igt@kms_flip@plain-flip-ts-check:
shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#103313,
fdo#105602) +4
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
shard-apl: PASS -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-1p-rte:
shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#103313)
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
shard-glk: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc:
shard-skl: PASS -> FAIL (fdo#103167) +3
igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite:
{shard-iclb}: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
{shard-iclb}: PASS -> FAIL (fdo#105683)
igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite:
{shard-iclb}: NOTRUN -> FAIL (fdo#103167) +3
igt@kms_hdmi_inject@inject-audio:
{shard-iclb}: NOTRUN -> FAIL (fdo#102370)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
shard-skl: PASS -> INCOMPLETE (fdo#107773, fdo#104108)
igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
shard-skl: PASS -> FAIL (fdo#108145, fdo#107815)
igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
shard-glk: PASS -> FAIL (fdo#103166) +2
shard-apl: PASS -> FAIL (fdo#103166)
igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
{shard-iclb}: PASS -> FAIL (fdo#103166) +2
igt@kms_psr@no_drrs:
{shard-iclb}: PASS -> FAIL (fdo#108341)
igt@kms_sysfs_edid_timing:
shard-skl: NOTRUN -> FAIL (fdo#100047)
igt@pm_rpm@fences:
shard-skl: NOTRUN -> INCOMPLETE (fdo#107807)
igt@pm_rpm@modeset-non-lpsp-stress:
shard-skl: SKIP -> INCOMPLETE (fdo#107807)
Possible fixes
igt@kms_atomic_transition@1x-modeset-transitions:
shard-hsw: DMESG-FAIL (fdo#102614) -> PASS
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
shard-hsw: DMESG-WARN (fdo#107956) -> PASS
igt@kms_color@pipe-b-degamma:
shard-skl: FAIL (fdo#104782) -> PASS
igt@kms_cursor_crc@cursor-256x256-random:
shard-apl: FAIL (fdo#103232) -> PASS +2
igt@kms_cursor_crc@cursor-256x85-random:
shard-hsw: DMESG-FAIL (fdo#102614, fdo#103232) -> PASS
igt@kms_cursor_crc@cursor-64x64-suspend:
shard-skl: INCOMPLETE (fdo#104108) -> PASS
igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic:
shard-hsw: DMESG-WARN (fdo#102614) -> PASS +3
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse
== Series Details == Series: series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse URL : https://patchwork.freedesktop.org/series/52848/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5183 -> Patchwork_10883 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/52848/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10883 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-icl-u2: PASS -> DMESG-WARN (fdo#107724) igt@gem_exec_suspend@basic-s3: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) +1 igt@kms_pipe_crc_basic@read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#107362) igt@pm_rpm@module-reload: fi-skl-6770hq: PASS -> DMESG-WARN (fdo#105541) Possible fixes igt@gem_ctx_switch@basic-default: fi-icl-u2: DMESG-WARN (fdo#107724) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cfl-8109u: INCOMPLETE (fdo#106070, fdo#108126) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#105541 https://bugs.freedesktop.org/show_bug.cgi?id=105541 fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724 fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126 == Participating hosts (49 -> 45) == Additional (2): fi-kbl-7560u fi-apl-guc Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 == Build changes == * Linux: CI_DRM_5183 -> Patchwork_10883 CI_DRM_5183: efce77bb4d804788e55a1ceb4386c812857f8cf7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4724: 29ae0925abe1d3a0202059538559468ad947d42d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10883: 085a5d730b4050ef609a71dad16a390c0728512e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 085a5d730b40 drm/i915/hsw: Drop the stereo 3D enabled check in psr_compute_config() e49402338a9e drm/i915: Keep PSR disabled after a driver reload after a PSR error 2d8596c2596a drm/i915: Disable PSR when a PSR aux error happen 479703075ef7 drm/i915: Do not enable PSR in the next modeset after a error 01aa0613cf2a drm/i915: Check PSR errors instead of retrain while PSR is enabled 38e729ea9ec4 drm/i915: Avoid a full port detection in the first eDP short pulse == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10883/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse
== Series Details == Series: series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse URL : https://patchwork.freedesktop.org/series/52848/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Avoid a full port detection in the first eDP short pulse Okay! Commit: drm/i915: Check PSR errors instead of retrain while PSR is enabled Okay! Commit: drm/i915: Do not enable PSR in the next modeset after a error -drivers/gpu/drm/i915/selftests/../i915_drv.h:3567:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3568:16: warning: expression using sizeof(void) Commit: drm/i915: Disable PSR when a PSR aux error happen -drivers/gpu/drm/i915/selftests/../i915_drv.h:3568:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3569:16: warning: expression using sizeof(void) Commit: drm/i915: Keep PSR disabled after a driver reload after a PSR error Okay! Commit: drm/i915/hsw: Drop the stereo 3D enabled check in psr_compute_config() Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse
== Series Details == Series: series starting with [v5,1/6] drm/i915: Avoid a full port detection in the first eDP short pulse URL : https://patchwork.freedesktop.org/series/52848/ State : warning == Summary == $ dim checkpatch origin/drm-tip 38e729ea9ec4 drm/i915: Avoid a full port detection in the first eDP short pulse 01aa0613cf2a drm/i915: Check PSR errors instead of retrain while PSR is enabled 479703075ef7 drm/i915: Do not enable PSR in the next modeset after a error -:26: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/384 #26: FILE: drivers/gpu/drm/i915/i915_drv.h:507: + bool sink_not_reliable; total: 0 errors, 0 warnings, 1 checks, 36 lines checked 2d8596c2596a drm/i915: Disable PSR when a PSR aux error happen -:43: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/384 #43: FILE: drivers/gpu/drm/i915/i915_drv.h:508: + bool irq_aux_error; total: 0 errors, 0 warnings, 1 checks, 78 lines checked e49402338a9e drm/i915: Keep PSR disabled after a driver reload after a PSR error 085a5d730b40 drm/i915/hsw: Drop the stereo 3D enabled check in psr_compute_config() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 4/6] drm/i915: Disable PSR when a PSR aux error happen
While PSR is active hardware will do aux transactions by it self to
wakeup sink to receive a new frame when necessary. If that
transaction is not acked by sink, hardware will trigger this
interruption.
So let's disable PSR as it is a hint that there is problem with this
sink.
The removed FIXME was asking to manually train the link but we don't
need to do that as by spec sink should do a short pulse when it is
out of sync with source, we just need to make sure it is awaken and
the SDP header with PSR inactive set it will trigger the short pulse
with a error set in the link status.
v3: added workarround to fix scheduled work starvation cause by
to frequent PSR error interruption
v4: only setting irq_aux_error as we don't care in clear it and
not using dev_priv->irq_lock as consequence.
v5: rebased: using edp_psr_shift()
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 41
2 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c189c8055b75..3526cedf55cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -505,6 +505,7 @@ struct i915_psr {
ktime_t last_entry_attempt;
ktime_t last_exit;
bool sink_not_reliable;
+ bool irq_aux_error;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index ab527f9a5436..f0bfe0a5ff7c 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -169,6 +169,7 @@ void intel_psr_irq_handler(struct drm_i915_private
*dev_priv, u32 psr_iir)
u32 transcoders = BIT(TRANSCODER_EDP);
enum transcoder cpu_transcoder;
ktime_t time_ns = ktime_get();
+ u32 mask = 0;
if (INTEL_GEN(dev_priv) >= 8)
transcoders |= BIT(TRANSCODER_A) |
@@ -178,10 +179,22 @@ void intel_psr_irq_handler(struct drm_i915_private
*dev_priv, u32 psr_iir)
for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
int shift = edp_psr_shift(cpu_transcoder);
- /* FIXME: Exit PSR and link train manually when this happens. */
- if (psr_iir & EDP_PSR_ERROR(shift))
- DRM_DEBUG_KMS("[transcoder %s] PSR aux error\n",
- transcoder_name(cpu_transcoder));
+ if (psr_iir & EDP_PSR_ERROR(shift)) {
+ DRM_WARN("[transcoder %s] PSR aux error\n",
+transcoder_name(cpu_transcoder));
+
+ dev_priv->psr.irq_aux_error = true;
+
+ /*
+* If this interruption is not masked it will keep
+* interrupting so fast that it prevents the scheduled
+* work to run.
+* Also after a PSR error, we don't want to arm PSR
+* again so we don't care about unmask the interruption
+* or unset irq_aux_error.
+*/
+ mask |= EDP_PSR_ERROR(shift);
+ }
if (psr_iir & EDP_PSR_PRE_ENTRY(shift)) {
dev_priv->psr.last_entry_attempt = time_ns;
@@ -203,6 +216,13 @@ void intel_psr_irq_handler(struct drm_i915_private
*dev_priv, u32 psr_iir)
}
}
}
+
+ if (mask) {
+ mask |= I915_READ(EDP_PSR_IMR);
+ I915_WRITE(EDP_PSR_IMR, mask);
+
+ schedule_work(_priv->psr.work);
+ }
}
static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
@@ -938,6 +958,16 @@ int intel_psr_set_debugfs_mode(struct drm_i915_private
*dev_priv,
return ret;
}
+static void intel_psr_handle_irq(struct drm_i915_private *dev_priv)
+{
+ struct i915_psr *psr = _priv->psr;
+
+ intel_psr_disable_locked(psr->dp);
+ psr->sink_not_reliable = true;
+ /* let's make sure that sink is awaken */
+ drm_dp_dpcd_writeb(>dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
+}
+
static void intel_psr_work(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
@@ -948,6 +978,9 @@ static void intel_psr_work(struct work_struct *work)
if (!dev_priv->psr.enabled)
goto unlock;
+ if (READ_ONCE(dev_priv->psr.irq_aux_error))
+ intel_psr_handle_irq(dev_priv);
+
/*
* We have to make sure PSR is ready for re-enable
* otherwise it keeps disabled until next full enable/disable cycle.
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 5/6] drm/i915: Keep PSR disabled after a driver reload after a PSR error
If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR
will still keep the error set even after the reset done in the
irq_preinstall and irq_uninstall hooks.
And enabling in this situation cause the screen to freeze in the
first time that PSR HW tries to activate so lets keep PSR disabled
to avoid any rendering problems.
v5: rebased: using edp_psr_shift()
v4: Moved handling from intel_psr_compute_config() to
intel_psr_init() to avoid hardware access during compute(Ville)
Cc: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
squash
---
drivers/gpu/drm/i915/intel_psr.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index f0bfe0a5ff7c..c5ab69e6c90b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -,6 +,8 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
*/
void intel_psr_init(struct drm_i915_private *dev_priv)
{
+ u32 val;
+
if (!HAS_PSR(dev_priv))
return;
@@ -1124,6 +1126,22 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) < 9 || !dev_priv->vbt.psr.enable)
i915_modparams.enable_psr = 0;
+ /*
+* If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR
+* will still keep the error set even after the reset done in the
+* irq_preinstall and irq_uninstall hooks.
+* And enabling in this situation cause the screen to freeze in the
+* first time that PSR HW tries to activate so lets keep PSR disabled
+* to avoid any rendering problems.
+*/
+ val = I915_READ(EDP_PSR_IIR);
+ val &= EDP_PSR_ERROR(edp_psr_shift(TRANSCODER_EDP));
+ if (val) {
+ DRM_DEBUG_KMS("PSR interruption error set\n");
+ dev_priv->psr.sink_not_reliable = true;
+ return;
+ }
+
/* Set link_standby x link_off defaults */
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
/* HSW and BDW require workarounds that we don't implement. */
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/6] drm/i915: Avoid a full port detection in the first eDP short pulse
Some eDP panels do not set a valid sink count value and even for the
ones that sets is should always be one for eDP, that is why it is not
cached in intel_edp_init_dpcd().
But intel_dp_short_pulse() compares the old count with the read one
if there is a mistmatch a full port detection will be executed, what
was happening in the first short pulse interruption of eDP panels
that sets sink count.
Instead of just skip the compasison for eDP panels, lets not read
the sink count at all for eDP.
v2: the previous version of this patch it was caching the sink count
in intel_edp_init_dpcd() but I was pointed out by Ville a patch that
handled a case of a eDP panel that do not set sink count and as sink
count is not used to eDP certification was choosed to just not read
it at all.
Cc: Dhinakaran Pandiyan
Reviewed-by: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dp.c | 44 +++--
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7699f9b7b2d2..a6c654e17955 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3936,8 +3936,6 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
- u8 sink_count;
-
if (!intel_dp_read_dpcd(intel_dp))
return false;
@@ -3947,25 +3945,35 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
intel_dp_set_common_rates(intel_dp);
}
- if (drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT, _count) <= 0)
- return false;
-
/*
-* Sink count can change between short pulse hpd hence
-* a member variable in intel_dp will track any changes
-* between short pulse interrupts.
+* Some eDP panels do not set a valid value for sink count, that is why
+* it don't care about read it here and in intel_edp_init_dpcd().
*/
- intel_dp->sink_count = DP_GET_SINK_COUNT(sink_count);
+ if (!intel_dp_is_edp(intel_dp)) {
+ u8 count;
+ ssize_t r;
- /*
-* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
-* a dongle is present but no display. Unless we require to know
-* if a dongle is present or not, we don't need to update
-* downstream port information. So, an early return here saves
-* time from performing other operations which are not required.
-*/
- if (!intel_dp_is_edp(intel_dp) && !intel_dp->sink_count)
- return false;
+ r = drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT, );
+ if (r < 1)
+ return false;
+
+ /*
+* Sink count can change between short pulse hpd hence
+* a member variable in intel_dp will track any changes
+* between short pulse interrupts.
+*/
+ intel_dp->sink_count = DP_GET_SINK_COUNT(count);
+
+ /*
+* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
+* a dongle is present but no display. Unless we require to know
+* if a dongle is present or not, we don't need to update
+* downstream port information. So, an early return here saves
+* time from performing other operations which are not required.
+*/
+ if (!intel_dp->sink_count)
+ return false;
+ }
if (!drm_dp_is_branch(intel_dp->dpcd))
return true; /* native DP sink */
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/6] drm/i915: Do not enable PSR in the next modeset after a error
When we detect a error and disable PSR, it is kept disabled until the
next modeset but as the sink already show signs that it do not
properly work with PSR lets disabled it for good to avoid any
additional flickering.
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 21e4405e2168..c189c8055b75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -504,6 +504,7 @@ struct i915_psr {
u8 sink_sync_latency;
ktime_t last_entry_attempt;
ktime_t last_exit;
+ bool sink_not_reliable;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index ebb255f230b7..ab527f9a5436 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -527,6 +527,11 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
return;
}
+ if (dev_priv->psr.sink_not_reliable) {
+ DRM_DEBUG_KMS("PSR sink implementation is not reliable\n");
+ return;
+ }
+
if (IS_HASWELL(dev_priv) &&
I915_READ(HSW_STEREO_3D_CTL(crtc_state->cpu_transcoder)) &
S3D_ENABLE) {
@@ -1123,6 +1128,7 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR) {
DRM_DEBUG_KMS("PSR sink internal error, disabling PSR\n");
intel_psr_disable_locked(intel_dp);
+ psr->sink_not_reliable = true;
}
if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_ERROR_STATUS, ) != 1) {
@@ -1140,8 +1146,10 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
if (val & ~errors)
DRM_ERROR("PSR_ERROR_STATUS unhandled errors %x\n",
val & ~errors);
- if (val & errors)
+ if (val & errors) {
intel_psr_disable_locked(intel_dp);
+ psr->sink_not_reliable = true;
+ }
/* clear status register */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
exit:
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 6/6] drm/i915/hsw: Drop the stereo 3D enabled check in psr_compute_config()
We should not access hardware while computing config also we don't
support stereo 3D so this test was never true.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c5ab69e6c90b..572e626eadff 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -552,13 +552,6 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
return;
}
- if (IS_HASWELL(dev_priv) &&
- I915_READ(HSW_STEREO_3D_CTL(crtc_state->cpu_transcoder)) &
- S3D_ENABLE) {
- DRM_DEBUG_KMS("PSR condition failed: Stereo 3D is Enabled\n");
- return;
- }
-
if (IS_HASWELL(dev_priv) &&
adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
DRM_DEBUG_KMS("PSR condition failed: Interlaced is Enabled\n");
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/6] drm/i915: Check PSR errors instead of retrain while PSR is enabled
When a PSR error happens sink sets the PSR error register and also
set the link status to a error status.
So in the short pulse handling it was returning earlier and doing a
full detection and attempting to retrain but it fails as PSR HW is
in change of the main-link.
Just call intel_psr_short_pulse() before
intel_dp_needs_link_retrain() is not the right fix as
intel_dp_needs_link_retrain() would return true and trigger a full
detection while PSR HW is still in change of main-link.
Check for PSR active is also not safe as it could be inactive due a
frontbuffer invalidate and still doing the PSR exit sequence.
v3: added comment in intel_dp_needs_link_retrain()
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 15 +++
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a6c654e17955..70ae3d57316b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4383,6 +4383,17 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
if (!intel_dp->link_trained)
return false;
+ /*
+* While PSR source HW is enabled, it will control main-link sending
+* frames, enabling and disabling it so trying to do a retrain will fail
+* as the link would or not be on or it could mix training patterns
+* and frame data at the same time causing retrain to fail.
+* Also when exiting PSR, HW will retrain the link anyways fixing
+* any link status error.
+*/
+ if (intel_psr_enabled(intel_dp))
+ return false;
+
if (!intel_dp_get_link_status(intel_dp, link_status))
return false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a7d9ac912125..a62d77b76291 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2047,6 +2047,7 @@ void intel_psr_irq_handler(struct drm_i915_private
*dev_priv, u32 psr_iir);
void intel_psr_short_pulse(struct intel_dp *intel_dp);
int intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state,
u32 *out_value);
+bool intel_psr_enabled(struct intel_dp *intel_dp);
/* intel_quirks.c */
void intel_init_quirks(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 54fa17a5596a..ebb255f230b7 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1147,3 +1147,18 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
exit:
mutex_unlock(>lock);
}
+
+bool intel_psr_enabled(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ bool ret;
+
+ if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
+ return false;
+
+ mutex_lock(_priv->psr.lock);
+ ret = (dev_priv->psr.dp == intel_dp && dev_priv->psr.enabled);
+ mutex_unlock(_priv->psr.lock);
+
+ return ret;
+}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: merge gen checks to use range
On Tue, Nov 06, 2018 at 01:51:22PM -0800, Lucas De Marchi wrote:
> Instead of using several GT_GEN(), let's pass the range to
> GT_GEN_RANGE(). By code inspection these were the ranges deemed
> necessary for spatch:
>
> @@
> expression e;
> @@
> (
> - GT_GEN(e, 3) || GT_GEN(e, 2)
> + GT_GEN_RANGE(e, 2, 3)
> |
> - GT_GEN(e, 3) || GT_GEN(e, 4)
> + GT_GEN_RANGE(e, 3, 4)
> |
> - GT_GEN(e, 5) || GT_GEN(e, 6)
> + GT_GEN_RANGE(e, 5, 6)
> |
> - GT_GEN(e, 6) || GT_GEN(e, 7)
> + GT_GEN_RANGE(e, 6, 7)
> |
> - GT_GEN(e, 7) || GT_GEN(e, 8)
> + GT_GEN_RANGE(e, 7, 8)
> |
> - GT_GEN(e, 8) || GT_GEN(e, 9)
> + GT_GEN_RANGE(e, 8, 9)
> |
> - GT_GEN(e, 10) || GT_GEN(e, 9)
> + GT_GEN_RANGE(e, 9, 10)
> |
> - GT_GEN(e, 9) || GT_GEN(e, 10)
> + GT_GEN_RANGE(e, 9, 10)
> )
>
> Signed-off-by: Lucas De Marchi
a good start point although I believe we will need to do more
changes later...
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c| 6 +++---
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> drivers/gpu/drm/i915/i915_perf.c | 2 +-
> drivers/gpu/drm/i915/intel_crt.c | 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +-
> drivers/gpu/drm/i915/intel_pipe_crc.c | 4 ++--
> drivers/gpu/drm/i915/intel_uncore.c| 6 +++---
> 11 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index bc79c154391d..692de9b9779b 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -1025,7 +1025,7 @@ static bool vgpu_ips_enabled(struct intel_vgpu *vgpu)
> {
> struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
>
> - if (GT_GEN(dev_priv, 9) || GT_GEN(dev_priv, 10)) {
> + if (GT_GEN_RANGE(dev_priv, 9, 10)) {
> u32 ips = vgpu_vreg_t(vgpu, GEN8_GAMW_ECO_DEV_RW_IA) &
> GAMW_ECO_ENABLE_64K_IPS_FIELD;
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index ec26076aaecc..9ffcf0be0589 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2030,7 +2030,7 @@ static int i915_swizzle_info(struct seq_file *m, void
> *data)
> seq_printf(m, "bit6 swizzle for Y-tiling = %s\n",
> swizzle_string(dev_priv->mm.bit_6_swizzle_y));
>
> - if (GT_GEN(dev_priv, 3) || GT_GEN(dev_priv, 4)) {
> + if (GT_GEN_RANGE(dev_priv, 3, 4)) {
> seq_printf(m, "DDC = 0x%08x\n",
> I915_READ(DCC));
> seq_printf(m, "DDC2 = 0x%08x\n",
> @@ -4262,7 +4262,7 @@ i915_cache_sharing_get(void *data, u64 *val)
> struct drm_i915_private *dev_priv = data;
> u32 snpcr;
>
> - if (!(GT_GEN(dev_priv, 6) || GT_GEN(dev_priv, 7)))
> + if (!(GT_GEN_RANGE(dev_priv, 6, 7)))
> return -ENODEV;
>
> intel_runtime_pm_get(dev_priv);
> @@ -4282,7 +4282,7 @@ i915_cache_sharing_set(void *data, u64 val)
> struct drm_i915_private *dev_priv = data;
> u32 snpcr;
>
> - if (!(GT_GEN(dev_priv, 6) || GT_GEN(dev_priv, 7)))
> + if (!(GT_GEN_RANGE(dev_priv, 6, 7)))
> return -ENODEV;
>
> if (val > 3)
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 0de8ce65053d..e754c0306425 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1673,7 +1673,7 @@ static void capture_reg_state(struct i915_gpu_state
> *error)
> error->ccid = I915_READ(CCID);
>
> /* 3: Feature specific registers */
> - if (GT_GEN(dev_priv, 6) || GT_GEN(dev_priv, 7)) {
> + if (GT_GEN_RANGE(dev_priv, 6, 7)) {
> error->gam_ecochk = I915_READ(GAM_ECOCHK);
> error->gac_eco = I915_READ(GAC_ECO_BITS);
> }
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 5cc1ffa621a7..b5154891e0d7 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -3449,7 +3449,7 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
> dev_priv->perf.oa.ops.read = gen8_oa_read;
> dev_priv->perf.oa.ops.oa_hw_tail_read = gen8_oa_hw_tail_read;
>
> - if (GT_GEN(dev_priv, 8) || GT_GEN(dev_priv, 9)) {
> + if (GT_GEN_RANGE(dev_priv, 8, 9)) {
> dev_priv->perf.oa.ops.is_valid_b_counter_reg =
> gen7_is_valid_b_counter_addr;
> dev_priv->perf.oa.ops.is_valid_mux_reg =
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index dbc97c29f7e5..cbc76b7b8b74 100644
> ---
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: rename IS_GEN9_* to GT_GEN9_*
On Tue, Nov 06, 2018 at 01:51:20PM -0800, Lucas De Marchi wrote:
> Like it was done for the generic IS_GEN -> GT_GEN rename, but since
> the LP/BC variants only exist in gen 9, keep the single macro
> definition. Also move the define to be together with GT_GEN().
>
> Users were converted with:
>
> sed -i 's/IS_GEN9_/GT_GEN9_/g' \
> drivers/gpu/drm/i915/*.{c,h} \
> drivers/gpu/drm/i915/*/*.{c,h}
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 22 ++---
> drivers/gpu/drm/i915/i915_drv.c | 10 +++---
> drivers/gpu/drm/i915/i915_drv.h | 9 ++---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++--
> drivers/gpu/drm/i915/i915_irq.c | 12 +++
> drivers/gpu/drm/i915/i915_reg.h | 4 +--
> drivers/gpu/drm/i915/intel_bios.c| 4 +--
> drivers/gpu/drm/i915/intel_cdclk.c | 10 +++---
> drivers/gpu/drm/i915/intel_color.c | 2 +-
> drivers/gpu/drm/i915/intel_csr.c | 2 +-
> drivers/gpu/drm/i915/intel_ddi.c | 42
> drivers/gpu/drm/i915/intel_device_info.c | 12 +++
> drivers/gpu/drm/i915/intel_display.c | 18 +-
> drivers/gpu/drm/i915/intel_dp.c | 28
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/i915/intel_dpll_mgr.c| 4 +--
> drivers/gpu/drm/i915/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
> drivers/gpu/drm/i915/intel_hdmi.c| 4 +--
> drivers/gpu/drm/i915/intel_i2c.c | 12 +++
> drivers/gpu/drm/i915/intel_mocs.c| 4 +--
> drivers/gpu/drm/i915/intel_panel.c | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 18 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 22 ++---
> drivers/gpu/drm/i915/intel_wopcm.c | 2 +-
> drivers/gpu/drm/i915/intel_workarounds.c | 4 +--
> drivers/gpu/drm/i915/vlv_dsi.c | 40 +++---
> 27 files changed, 150 insertions(+), 149 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 2514ec4d97d4..5e4a934c0dea 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1123,7 +1123,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> int max_freq;
>
> rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
> - if (IS_GEN9_LP(dev_priv)) {
> + if (GT_GEN9_LP(dev_priv)) {
> rp_state_cap = I915_READ(BXT_RP_STATE_CAP);
> gt_perf_status = I915_READ(BXT_GT_PERF_STATUS);
> } else {
> @@ -1230,22 +1230,22 @@ static int i915_frequency_info(struct seq_file *m,
> void *unused)
> seq_printf(m, "Down threshold: %d%%\n",
> rps->power.down_threshold);
>
> - max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
> + max_freq = (GT_GEN9_LP(dev_priv) ? rp_state_cap >> 0 :
> rp_state_cap >> 16) & 0xff;
> - max_freq *= (IS_GEN9_BC(dev_priv) ||
> + max_freq *= (GT_GEN9_BC(dev_priv) ||
>INTEL_GEN(dev_priv) >= 10 ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Lowest (RPN) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
>
> max_freq = (rp_state_cap & 0xff00) >> 8;
> - max_freq *= (IS_GEN9_BC(dev_priv) ||
> + max_freq *= (GT_GEN9_BC(dev_priv) ||
>INTEL_GEN(dev_priv) >= 10 ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
>
> - max_freq = (IS_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
> + max_freq = (GT_GEN9_LP(dev_priv) ? rp_state_cap >> 16 :
> rp_state_cap >> 0) & 0xff;
> - max_freq *= (IS_GEN9_BC(dev_priv) ||
> + max_freq *= (GT_GEN9_BC(dev_priv) ||
>INTEL_GEN(dev_priv) >= 10 ? GEN9_FREQ_SCALER : 1);
> seq_printf(m, "Max non-overclocked (RP0) frequency: %dMHz\n",
> intel_gpu_freq(dev_priv, max_freq));
> @@ -1824,7 +1824,7 @@ static int i915_ring_freq_table(struct seq_file *m,
> void *unused)
>
> min_gpu_freq = rps->min_freq;
> max_gpu_freq = rps->max_freq;
> - if (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) {
> + if (GT_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) {
> /* Convert GT frequency to 50 HZ units */
> min_gpu_freq /= GEN9_FREQ_SCALER;
> max_gpu_freq /= GEN9_FREQ_SCALER;
> @@ -1839,7 +1839,7 @@ static int i915_ring_freq_table(struct seq_file *m,
> void *unused)
> _freq);
>
Re: [Intel-gfx] [PATCH v2 1/7] Revert "drm/i915: Kill GEN_FOREVER"
On Tue, Nov 06, 2018 at 01:51:17PM -0800, Lucas De Marchi wrote: > This reverts commit 5bc0e89ff1bee1566bd2fbd1142dce001c068aeb. > > The macro was added and then never used so it was removed. However > after removal it was noticed that it was actually something that should > indeed be useful to out gen check macros to make use of. > > Let's get the define back and start using it in follow up changes. > > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_drv.h | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 2a88a7eb871b..8839a34f7648 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2360,12 +2360,20 @@ intel_info(const struct drm_i915_private *dev_priv) > #define REVID_FOREVER0xff > #define INTEL_REVID(dev_priv)((dev_priv)->drm.pdev->revision) > > +#define GEN_FOREVER (0) > + > #define INTEL_GEN_MASK(s, e) ( \ > BUILD_BUG_ON_ZERO(!__builtin_constant_p(s)) + \ > BUILD_BUG_ON_ZERO(!__builtin_constant_p(e)) + \ > - GENMASK((e) - 1, (s) - 1)) > + GENMASK((e) != GEN_FOREVER ? (e) - 1 : BITS_PER_LONG - 1, \ > + (s) != GEN_FOREVER ? (s) - 1 : 0) \ As I mentioned before I don't like the forever as start, but this could be removed later so this can be a pure revert?! Reviewed-by: Rodrigo Vivi > +) > > -/* Returns true if Gen is in inclusive range [Start, End] */ > +/* > + * Returns true if Gen is in inclusive range [Start, End]. > + * > + * Use GEN_FOREVER for unbound start and or end. > + */ > #define IS_GEN(dev_priv, s, e) \ > (!!((dev_priv)->info.gen_mask & INTEL_GEN_MASK((s), (e > > -- > 2.19.1.1.g56c4683e68 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: replace IS_GEN with GT_GEN(..., N)
On Tue, Nov 06, 2018 at 01:51:19PM -0800, Lucas De Marchi wrote:
> Define GT_GEN() similarly to our GT_GEN_RANGE() and convert users of
> IS_GEN to pss the gen as parameter. This prepares for the addition
> of display gen checks by renaming the IS_GENx() and using common code
> for all the n gens.
>
> The following spatch was used to convert the users of these macros:
>
> @@
> expression e;
> @@
> (
> - IS_GEN2(e)
> + GT_GEN(e, 2)
> |
> - IS_GEN3(e)
> + GT_GEN(e, 3)
> |
> - IS_GEN4(e)
> + GT_GEN(e, 4)
> |
> - IS_GEN5(e)
> + GT_GEN(e, 5)
> |
> - IS_GEN6(e)
> + GT_GEN(e, 6)
> |
> - IS_GEN7(e)
> + GT_GEN(e, 7)
> |
> - IS_GEN8(e)
> + GT_GEN(e, 8)
> |
> - IS_GEN9(e)
> + GT_GEN(e, 9)
> |
> - IS_GEN10(e)
> + GT_GEN(e, 10)
> |
> - IS_GEN11(e)
> + GT_GEN(e, 11)
> )
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gvt/vgpu.c| 4 +-
> drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c| 16 ++---
> drivers/gpu/drm/i915/i915_drv.c| 18 +++---
> drivers/gpu/drm/i915/i915_drv.h| 29 +++--
> drivers/gpu/drm/i915/i915_gem.c| 12 ++--
> drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
> drivers/gpu/drm/i915/i915_gem_fence_reg.c | 10 +--
> drivers/gpu/drm/i915/i915_gem_gtt.c| 6 +-
> drivers/gpu/drm/i915/i915_gem_stolen.c | 7 +-
> drivers/gpu/drm/i915/i915_gem_tiling.c | 4 +-
> drivers/gpu/drm/i915/i915_gpu_error.c | 18 +++---
> drivers/gpu/drm/i915/i915_irq.c| 24 +++
> drivers/gpu/drm/i915/i915_perf.c | 4 +-
> drivers/gpu/drm/i915/i915_suspend.c| 12 ++--
> drivers/gpu/drm/i915/intel_atomic.c| 2 +-
> drivers/gpu/drm/i915/intel_audio.c | 2 +-
> drivers/gpu/drm/i915/intel_cdclk.c | 10 +--
> drivers/gpu/drm/i915/intel_crt.c | 6 +-
> drivers/gpu/drm/i915/intel_device_info.c | 16 ++---
> drivers/gpu/drm/i915/intel_display.c | 74 +++---
> drivers/gpu/drm/i915/intel_dp.c| 24 +++
> drivers/gpu/drm/i915/intel_engine_cs.c | 4 +-
> drivers/gpu/drm/i915/intel_fbc.c | 22 +++
> drivers/gpu/drm/i915/intel_fifo_underrun.c | 6 +-
> drivers/gpu/drm/i915/intel_guc_fw.c| 2 +-
> drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
> drivers/gpu/drm/i915/intel_lrc.c | 4 +-
> drivers/gpu/drm/i915/intel_lvds.c | 4 +-
> drivers/gpu/drm/i915/intel_mocs.c | 2 +-
> drivers/gpu/drm/i915/intel_overlay.c | 10 +--
> drivers/gpu/drm/i915/intel_panel.c | 8 +--
> drivers/gpu/drm/i915/intel_pipe_crc.c | 8 +--
> drivers/gpu/drm/i915/intel_pm.c| 60 +-
> drivers/gpu/drm/i915/intel_psr.c | 4 +-
> drivers/gpu/drm/i915/intel_ringbuffer.c| 28
> drivers/gpu/drm/i915/intel_ringbuffer.h| 4 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c| 2 +-
> drivers/gpu/drm/i915/intel_sprite.c| 6 +-
> drivers/gpu/drm/i915/intel_uc.c| 2 +-
> drivers/gpu/drm/i915/intel_uncore.c| 18 +++---
> drivers/gpu/drm/i915/intel_wopcm.c | 4 +-
> 43 files changed, 247 insertions(+), 259 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> index c628be05fbfe..ea45b22814a1 100644
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@ -148,10 +148,10 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
> gvt->types[i].avail_instance = min(low_avail /
> vgpu_types[i].low_mm,
> high_avail /
> vgpu_types[i].high_mm);
>
> - if (IS_GEN8(gvt->dev_priv))
> + if (GT_GEN(gvt->dev_priv, 8))
> sprintf(gvt->types[i].name, "GVTg_V4_%s",
> vgpu_types[i].name);
> - else if (IS_GEN9(gvt->dev_priv))
> + else if (GT_GEN(gvt->dev_priv, 9))
> sprintf(gvt->types[i].name, "GVTg_V5_%s",
> vgpu_types[i].name);
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 95478db9998b..2be8c22641b6 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -865,7 +865,7 @@ void intel_engine_init_cmd_parser(struct intel_engine_cs
> *engine)
> int cmd_table_count;
> int ret;
>
> - if (!IS_GEN7(engine->i915))
> + if (!GT_GEN(engine->i915, 7))
> return;
>
> switch (engine->id) {
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index f60485906f7e..2514ec4d97d4 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1064,7 +1064,7 @@
Re: [Intel-gfx] [PATCH v2 0/7] Make GEN macros more similar
On Mon, Nov 19, 2018 at 02:20:55PM -0800, Lucas De Marchi wrote: > On Thu, Nov 08, 2018 at 11:23:46AM +, Tvrtko Ursulin wrote: > > > > On 08/11/2018 00:57, Lucas De Marchi wrote: > > > On Wed, Nov 07, 2018 at 10:05:19AM +, Tvrtko Ursulin wrote: > > > > > > > > On 06/11/2018 21:51, Lucas De Marchi wrote: > > > > > This is the second version of the series trying to make GEN checks > > > > > more similar. These or roughly the changes from v1: > > > > > > > > > > - We don't have a single macro receiving 2 or 3 parameters. Now there > > > > > is GT_GEN_RANGE(), and GT_GEN(). The firs is the conversion from > > > > > IS_GEN() while the second is the conversion from IS_GEN() > > > > > - Bring GEN_FOREVER back to be used with above macros > > > > > - Patch converting <, <=, ==, >, >= checks using INTEL_GEN() to > > > > > use the macros above was added > > > > > - INTEL_GEN() is removed to avoid it being used when we should prefer > > > > > the new macros > > > > > > > > > > The idea of the names is to pave the way for checks of the display > > > > > version, > > > > > which would be named DISPLAY_GEN(), DISPLAY_GEN_RANGE(). > > > > > > > > > > In the commit messages we have the scripts to regenerate the patch to > > > > > make > > > > > it easier to apply after the discussions and also to be able to > > > > > convert > > > > > inflight patches. > > > > > > > > > > Sorry in advance for the noise this causes in the codebase, but > > > > > hopefully > > > > > it is for the greater good. > > > > > > > > > > > > > > > Lucas De Marchi (6): > > > > > Revert "drm/i915: Kill GEN_FOREVER" > > > > > drm/i915: replace IS_GEN with GT_GEN(..., N) > > > > > drm/i915: rename IS_GEN9_* to GT_GEN9_* > > > > > drm/i915: replace gen checks using operators by > > > > > GT_GEN/GT_GEN_RANGE > > > > > > > > I have reservations about this patch, where I think forcing only one > > > > flavour > > > > maybe is not the best thing. Because for plain if-ladder cases it feels > > > > more > > > > readable to stick with the current scheme of arithmetic comparisons. > > > > And it > > > > is more efficient in code as well. > > > > > > > > Range checks are on the other hand useful either when combined in the > > > > same > > > > conditional as some other bitmask based test, or when both ends of the > > > > comparison edge are bound. > > > > > > So are you against changing the == to use the macros, changing the >=, >, > > > <, <=, > > > or all of them? > > > > Definitely not all of them. Just plain if ladders I think are definitely > > more readable in source and result in better code in the normal fashion of: > > > >if (gen >= 11) > >else if (gen >= 9) > >else if (gen >= 7) > >... etc ... > > > > Where I think it makes sense is when either both edges are bound, like: > > > > if (gen < 11 || gen >= 8) > > if (gen >= 10 || gen == 8) > > ok, I will take a look before respinning this. > > > > > But not sure how many of those there are. > > > > What definitely exists in large-ish numbers are: specially on display side... > > > >if (gen >= 11 || IS_PLATFORM) My goal is exactly to organize the gen numbers in a way that we minimize this mix as much as possible. > > > > At some point I had a prototype which puts the gen and platform masks into a > > bag of bits and then, depending on bits locality, this too can be compressed > > to a single bitmask test. However I felt that was going too far, and the > > issue is achieving interesting bits locality for it too work. But I digress. > > > > > Looking at the changes to ==, they seem very reasonable and in a few > > > cases it allowed > > > the next patch to merge them in a GT_GEN_RANGE() -- yes the patch > > > ordering was on > > > purpose to allow that. > > > > Yep those are the good ones. > > > > > The others are indeed debatable. However IMO for the cases it makes sense, > > > there's always the fallback > > > > > > if (dev_priv->info.gen == 10) > > > ... > > > else if (dev_priv->info.gen == 11) > > > ... > > > else if (dev_priv->info.gen < 5) > > > ... > > > > > > We can go on a case by case manner in this patch rather than the mass > > > conversion > > > for these. > > > > > > > > > > > > drm/i915: merge gen checks to use range > > > > > drm/i915: remove INTEL_GEN macro > > > > > > > > I have reservations about this as as well, especially considering the > > > > previous paragraph. But even on it's own I am not sure we want to go > > > > back to > > > > more verbose. > > > > > > see above. IMO it's not actually so verbose as one would think. > > > > > > if (INTEL_GEN(dev_priv) == 11) > > > vs > > > if (dev_priv->info.gen == 11) > > > > I think it should be: > > > >if (INTEL_INFO(dev_priv)->gen == 11) > > > > Which is a tiny bit longer.. > > If it's longer, why bother? We could just as well do for the if ladders: > > gen = dev_priv->info.gen;
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Disable PSR when a PSR aux error happen
On Tue, Nov 20, 2018 at 03:05:07PM -0800, Souza, Jose wrote:
> On Tue, 2018-11-20 at 14:47 -0800, Rodrigo Vivi wrote:
> > On Fri, Nov 09, 2018 at 12:20:13PM -0800, José Roberto de Souza
> > wrote:
> > > While PSR is active hardware will do aux transactions by it self to
> > > wakeup sink to receive a new frame when necessary. If that
> > > transaction is not acked by sink, hardware will trigger this
> > > interruption.
> > >
> > > So let's disable PSR as it is a hint that there is problem with
> > > this
> > > sink.
> > >
> > > The removed FIXME was asking to manually train the link but we
> > > don't
> > > need to do that as by spec sink should do a short pulse when it is
> > > out of sync with source, we just need to make sure it is awaken and
> > > the SDP header with PSR disable will trigger this condition.
> > >
> > > v3: added workarround to fix scheduled work starvation cause by
> > > to frequent PSR error interruption
> > > v4: only setting irq_aux_error as we don't care in clear it and
> > > not using dev_priv->irq_lock as consequence.
> > >
> > > Cc: Dhinakaran Pandiyan
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_psr.c | 41
> > >
> > > 2 files changed, 38 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index e13222518c1b..4022a317cf05 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -642,6 +642,7 @@ struct i915_psr {
> > > ktime_t last_entry_attempt;
> > > ktime_t last_exit;
> > > bool sink_not_reliable;
> > > + bool irq_aux_error;
> > > };
> > >
> > > enum intel_pch {
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index cc738497d551..93d8538a2383 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -152,6 +152,7 @@ void intel_psr_irq_handler(struct
> > > drm_i915_private *dev_priv, u32 psr_iir)
> > > u32 transcoders = BIT(TRANSCODER_EDP);
> > > enum transcoder cpu_transcoder;
> > > ktime_t time_ns = ktime_get();
> > > + u32 mask = 0;
> > >
> > > if (INTEL_GEN(dev_priv) >= 8)
> > > transcoders |= BIT(TRANSCODER_A) |
> > > @@ -159,10 +160,22 @@ void intel_psr_irq_handler(struct
> > > drm_i915_private *dev_priv, u32 psr_iir)
> > > BIT(TRANSCODER_C);
> > >
> > > for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> > > transcoders) {
> > > - /* FIXME: Exit PSR and link train manually when this
> > > happens. */
> > > - if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > > - DRM_DEBUG_KMS("[transcoder %s] PSR aux
> > > error\n",
> > > - transcoder_name(cpu_transcoder));
> > > + if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
> > > + DRM_WARN("[transcoder %s] PSR aux error\n",
> > > + transcoder_name(cpu_transcoder));
> > > +
> > > + dev_priv->psr.irq_aux_error = true;
> > > +
> > > + /*
> > > + * If this interruption is not masked it will
> > > keep
> > > + * interrupting so fast that it prevents the
> > > scheduled
> > > + * work to run.
> > > + * Also after a PSR error, we don't want to arm
> > > PSR
> > > + * again so we don't care about unmask the
> > > interruption
> > > + * or unset irq_aux_error.
> > > + */
> > > + mask |= EDP_PSR_ERROR(cpu_transcoder);
> > > + }
> > >
> > > if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
> > > dev_priv->psr.last_entry_attempt = time_ns;
> > > @@ -184,6 +197,13 @@ void intel_psr_irq_handler(struct
> > > drm_i915_private *dev_priv, u32 psr_iir)
> > > }
> > > }
> > > }
> > > +
> > > + if (mask) {
> > > + mask |= I915_READ(EDP_PSR_IMR);
> > > + I915_WRITE(EDP_PSR_IMR, mask);
> > > +
> > > + schedule_work(_priv->psr.work);
> > > + }
> > > }
> > >
> > > static bool intel_dp_get_colorimetry_status(struct intel_dp
> > > *intel_dp)
> > > @@ -898,6 +918,16 @@ int intel_psr_set_debugfs_mode(struct
> > > drm_i915_private *dev_priv,
> > > return ret;
> > > }
> > >
> > > +static void intel_psr_handle_irq(struct drm_i915_private
> > > *dev_priv)
> > > +{
> > > + struct i915_psr *psr = _priv->psr;
> > > +
> > > + intel_psr_disable_locked(psr->dp);
> > > + psr->sink_not_reliable = true;
> > > + /* let's make sure that sink is awaken */
> > > + drm_dp_dpcd_writeb(>dp->aux, DP_SET_POWER,
> > > DP_SET_POWER_D0);
> >
> > H... my gut feeling and my bad memory about PSR tells this can
> > flicker
> > in some panels. But at least you are disabling PSR for good after
> >
Re: [Intel-gfx] [PATCH v2 08/13] drm/i915: Clean up skl+ vs. icl+ watermark computation
On Wed, Nov 21, 2018 at 09:05:33PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 20, 2018 at 02:44:34PM -0800, Matt Roper wrote:
> > On Wed, Nov 14, 2018 at 11:07:24PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
...snip...
> > > +static int icl_build_plane_wm(struct skl_ddb_allocation *ddb,
> > > + struct skl_pipe_wm *pipe_wm,
> > > + struct intel_crtc_state *crtc_state,
> > > + const struct intel_plane_state *plane_state)
> > > +{
> > > + enum plane_id plane_id = to_intel_plane(plane_state->base.plane)->id;
> > > + int ret;
> > > +
> > > + /* Watermarks calculated in master */
> > > + if (plane_state->slave)
> > > + return 0;
> > > +
> > > + if (plane_state->linked_plane) {
> > > + const struct drm_framebuffer *fb = plane_state->base.fb;
> > > + enum plane_id y_plane_id = plane_state->linked_plane->id;
> > > +
> > > + WARN_ON(!fb->format->is_yuv ||
> > > + fb->format->num_planes == 1);
> > > +
> > > + ret = skl_build_plane_wm_single(ddb, crtc_state, plane_state,
> > > + y_plane_id, 0);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = skl_build_plane_wm_single(ddb, crtc_state, plane_state,
> > > + plane_id, 1);
> > > + if (ret)
> > > + return ret;
> > > + } else if (intel_wm_plane_visible(crtc_state, plane_state)) {
> >
> > Isn't a visibility test also relevant to the nv12 (master plane) case
> > above? I don't understand why we'd only test it for rgb planes.
>
> linked_plane!=NULL implies that the plane is visible (see
> icl_check_nv12_planes()). I should probably add another WARN_ON() for
> that.
Ah, okay. In that case, with or without the WARN_ON(),
Reviewed-by: Matt Roper
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout
== Series Details ==
Series: drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout
URL : https://patchwork.freedesktop.org/series/52820/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5180_full -> Patchwork_10876_full =
== Summary - SUCCESS ==
No regressions found.
== Known issues ==
Here are the changes found in Patchwork_10876_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-kbl: PASS -> INCOMPLETE (fdo#106887, fdo#103665,
fdo#106023)
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
shard-snb: PASS -> DMESG-WARN (fdo#107956)
igt@kms_ccs@pipe-a-bad-aux-stride:
{shard-iclb}: PASS -> DMESG-WARN (fdo#107724) +8
igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-ytiled:
{shard-iclb}: NOTRUN -> WARN (fdo#108336)
igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
shard-glk: PASS -> FAIL (fdo#105363)
igt@kms_flip@flip-vs-expired-vblank-interruptible:
shard-skl: NOTRUN -> FAIL (fdo#105363)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
shard-apl: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
shard-glk: PASS -> FAIL (fdo#103167) +3
igt@kms_frontbuffer_tracking@fbc-stridechange:
{shard-iclb}: PASS -> DMESG-FAIL (fdo#107724) +2
igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack:
{shard-iclb}: NOTRUN -> DMESG-FAIL (fdo#107724) +2
igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen:
{shard-iclb}: PASS -> FAIL (fdo#103167)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
shard-skl: PASS -> INCOMPLETE (fdo#104108, fdo#107773) +1
igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
shard-skl: PASS -> INCOMPLETE (fdo#104108)
igt@kms_plane@plane-position-covered-pipe-a-planes:
shard-apl: PASS -> FAIL (fdo#103166) +1
igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
shard-skl: NOTRUN -> FAIL (fdo#108145)
igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
shard-skl: NOTRUN -> FAIL (fdo#107815, fdo#108145)
igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
{shard-iclb}: PASS -> DMESG-WARN (fdo#107724, fdo#108336) +4
igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
{shard-iclb}: PASS -> FAIL (fdo#103166)
igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format:
{shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107724) +2
igt@pm_rpm@modeset-non-lpsp-stress-no-wait:
shard-skl: SKIP -> INCOMPLETE (fdo#107807)
igt@pm_rpm@universal-planes:
shard-skl: PASS -> INCOMPLETE (fdo#107807) +1
Possible fixes
igt@gem_exec_whisper@normal:
shard-skl: TIMEOUT (fdo#108592) -> PASS
igt@kms_color@pipe-c-ctm-0-75:
shard-skl: FAIL (fdo#108682) -> PASS
igt@kms_cursor_crc@cursor-128x42-onscreen:
shard-apl: FAIL (fdo#103232) -> PASS
igt@kms_cursor_legacy@cursora-vs-flipa-toggle:
shard-glk: DMESG-WARN (fdo#106538, fdo#105763) -> PASS
igt@kms_draw_crc@draw-method-rgb565-blt-ytiled:
shard-glk: FAIL (fdo#103184) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
{shard-iclb}: FAIL (fdo#103167) -> PASS +5
shard-apl: FAIL (fdo#103167) -> PASS +4
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
shard-glk: FAIL (fdo#103167) -> PASS
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-apl: FAIL (fdo#103166) -> PASS
igt@kms_rmfb@rmfb-ioctl:
{shard-iclb}: DMESG-WARN (fdo#107724) -> PASS +1
igt@pm_rpm@dpms-lpsp:
shard-skl: INCOMPLETE (fdo#107807) -> PASS
igt@pm_rpm@gem-execbuf-stress-pc8:
{shard-iclb}: INCOMPLETE -> SKIP
Warnings
igt@i915_suspend@shrink:
shard-skl: INCOMPLETE (fdo#106886) -> DMESG-WARN (fdo#108784)
igt@kms_fbcon_fbt@psr-suspend:
shard-skl: INCOMPLETE (fdo#104108, fdo#107773) -> FAIL
(fdo#107882)
igt@pm_rpm@modeset-stress-extra-wait:
{shard-iclb}: INCOMPLETE -> DMESG-WARN (fdo#107724)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184
fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#104108
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Program SKL+ watermarks/ddb more carefully (rev8)
On Wed, Nov 21, 2018 at 06:05:21AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Program SKL+ watermarks/ddb more carefully (rev8) > URL : https://patchwork.freedesktop.org/series/51878/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_5174_full -> Patchwork_10868_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_10868_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_10868_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_10868_full: > > === IGT changes === > > Possible regressions > > igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: > shard-skl: PASS -> FAIL > > igt@kms_cursor_legacy@nonblocking-modeset-vs-cursor-atomic: > shard-apl: PASS -> FAIL Mysterious and mysteriouser. The test does this: 1. enable_crtc 2. setcursor 3. wait_for_event 4. disable_crtc Apparently we're not getting -EBUSY from step 4. Which would imply that we still have an unifinished commit in the queue. The cursor ioctl should block until everything is done, so I can't see how that is possible. And so far I'm unable to reproduce this locally. > > > Warnings > > igt@pm_rc6_residency@rc6-accuracy: > shard-snb: SKIP -> PASS > > > == Known issues == > > Here are the changes found in Patchwork_10868_full that come from known > issues: > > === IGT changes === > > Issues hit > > igt@gem_exec_schedule@preempt-hang-render: > shard-apl: PASS -> INCOMPLETE (fdo#103927) > > igt@gem_render_copy_redux@normal: > shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106650) > > igt@kms_ccs@pipe-a-crc-sprite-planes-basic: > shard-glk: PASS -> FAIL (fdo#108145) > > igt@kms_chv_cursor_fail@pipe-a-128x128-top-edge: > shard-skl: NOTRUN -> FAIL (fdo#104671) +1 > > igt@kms_cursor_crc@cursor-256x256-suspend: > shard-skl: PASS -> FAIL (fdo#103191, fdo#103232) > > igt@kms_cursor_crc@cursor-256x85-onscreen: > shard-apl: PASS -> FAIL (fdo#103232) > > igt@kms_flip@2x-flip-vs-expired-vblank: > shard-glk: PASS -> FAIL (fdo#105363) > > igt@kms_flip@flip-vs-expired-vblank-interruptible: > shard-skl: PASS -> FAIL (fdo#105363) > > igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-wc: > shard-skl: NOTRUN -> FAIL (fdo#105682) > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: > shard-skl: NOTRUN -> FAIL (fdo#103167) +3 > > igt@kms_frontbuffer_tracking@fbc-modesetfrombusy: > shard-glk: PASS -> FAIL (fdo#103167) +2 > > igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: > shard-skl: PASS -> INCOMPLETE (fdo#107773, fdo#104108) +1 > > igt@kms_plane@plane-position-covered-pipe-a-planes: > shard-skl: NOTRUN -> FAIL (fdo#103166) > > igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: > shard-skl: NOTRUN -> FAIL (fdo#107815, fdo#108145) > > igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: > shard-skl: PASS -> FAIL (fdo#107815) > > igt@kms_plane_multiple@atomic-pipe-c-tiling-y: > shard-apl: PASS -> FAIL (fdo#103166) > > igt@kms_universal_plane@universal-plane-pipe-c-functional: > shard-glk: PASS -> FAIL (fdo#103166) +1 > > igt@perf@oa-exponents: > shard-glk: PASS -> FAIL (fdo#105483) > > > Possible fixes > > igt@gem_ppgtt@blt-vs-render-ctxn: > shard-skl: TIMEOUT (fdo#108039) -> PASS > > igt@gem_pwrite@big-gtt-backwards: > shard-apl: INCOMPLETE (fdo#103927) -> PASS > > igt@kms_cursor_crc@cursor-256x85-sliding: > shard-apl: FAIL (fdo#103232) -> PASS > > igt@kms_cursor_legacy@cursora-vs-flipa-toggle: > shard-glk: DMESG-WARN (fdo#106538, fdo#105763) -> PASS > > igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: > shard-apl: FAIL (fdo#103167) -> PASS +2 > shard-glk: FAIL (fdo#103167) -> PASS +1 > > igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: > shard-skl: FAIL (fdo#107815) -> PASS > > igt@kms_plane_multiple@atomic-pipe-b-tiling-y: > shard-glk: FAIL (fdo#103166) -> PASS +2 > > igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: > shard-apl: FAIL (fdo#103166) -> PASS +1 > > igt@kms_setmode@basic: > shard-hsw: FAIL (fdo#99912) -> PASS > > >
Re: [Intel-gfx] [PATCH v2 03/13] drm/i915: Introduce crtc_state->update_planes bitmask
On Mon, Nov 19, 2018 at 03:14:14PM -0800, Matt Roper wrote:
> On Wed, Nov 14, 2018 at 11:07:19PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Keep track which planes need updating during the commit. For now this
> > is just (was_visible || is_visible) but I'll have need to update
>
> I still think it would be a good idea to mention was_slave || is_slave
> here for completeness, but either way,
Ah, didn't even realize I didn't mention it. I'll add a few choice
words.
>
> Reviewed-by: Matt Roper
>
> > invisible planes later on for skl plane ddbs and for pre-skl pipe
> > gamma/csc control (which lives in the primary plane control register).
> >
> > Reviewed-by: Rodrigo Vivi
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_atomic.c | 1 +
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 8
> > drivers/gpu/drm/i915/intel_display.c | 5 -
> > drivers/gpu/drm/i915/intel_drv.h | 3 +++
> > 4 files changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > b/drivers/gpu/drm/i915/intel_atomic.c
> > index a5a2c8fe58a7..8cb02f28d30c 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -184,6 +184,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > crtc_state->fifo_changed = false;
> > crtc_state->wm.need_postvbl_update = false;
> > crtc_state->fb_bits = 0;
> > + crtc_state->update_planes = 0;
> >
> > return _state->base;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > index 7d3685075201..010269a12390 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > @@ -137,6 +137,9 @@ int intel_plane_atomic_check_with_state(const struct
> > intel_crtc_state *old_crtc_
> > if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
> > crtc_state->nv12_planes |= BIT(intel_plane->id);
> >
> > + if (state->visible || old_plane_state->base.visible)
> > + crtc_state->update_planes |= BIT(intel_plane->id);
> > +
> > return intel_plane_atomic_calc_changes(old_crtc_state,
> >_state->base,
> >old_plane_state,
> > @@ -171,14 +174,11 @@ void intel_update_planes_on_crtc(struct
> > intel_atomic_state *old_state,
> > struct intel_crtc_state *old_crtc_state,
> > struct intel_crtc_state *new_crtc_state)
> > {
> > + u32 update_mask = new_crtc_state->update_planes;
> > struct intel_plane_state *new_plane_state;
> > struct intel_plane *plane;
> > - u32 update_mask;
> > int i;
> >
> > - update_mask = old_crtc_state->active_planes;
> > - update_mask |= new_crtc_state->active_planes;
> > -
> > for_each_new_intel_plane_in_state(old_state, plane, new_plane_state, i)
> > {
> > if (crtc->pipe != plane->pipe ||
> > !(update_mask & BIT(plane->id)))
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 3c760a2eacc8..065c8befc6f8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10808,8 +10808,10 @@ static int icl_check_nv12_planes(struct
> > intel_crtc_state *crtc_state)
> > continue;
> >
> > plane_state->linked_plane = NULL;
> > - if (plane_state->slave && !plane_state->base.visible)
> > + if (plane_state->slave && !plane_state->base.visible) {
> > crtc_state->active_planes &= ~BIT(plane->id);
> > + crtc_state->update_planes |= BIT(plane->id);
> > + }
> >
> > plane_state->slave = false;
> > }
> > @@ -10850,6 +10852,7 @@ static int icl_check_nv12_planes(struct
> > intel_crtc_state *crtc_state)
> > linked_state->slave = true;
> > linked_state->linked_plane = plane;
> > crtc_state->active_planes |= BIT(linked->id);
> > + crtc_state->update_planes |= BIT(linked->id);
> > DRM_DEBUG_KMS("Using %s as Y plane for %s\n",
> > linked->base.name, plane->base.name);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 18b419f7f7fe..b0a24a81780a 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -925,6 +925,9 @@ struct intel_crtc_state {
> > u8 active_planes;
> > u8 nv12_planes;
> >
> > + /* bitmask of planes that will be updated during the commit */
> > + u8 update_planes;
> > +
> > /* HDMI scrambling status */
> > bool hdmi_scrambling;
> >
> > --
> > 2.18.1
> >
> > ___
> > Intel-gfx mailing list
> >
Re: [Intel-gfx] [PATCH v2 05/13] drm/i915: Fix latency==0 handling for level 0 watermark on skl+
On Mon, Nov 19, 2018 at 03:14:34PM -0800, Matt Roper wrote:
> On Wed, Nov 14, 2018 at 11:07:21PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > If the level 0 latency is 0 we can't do anything. Return an error
> > rather than success.
> >
> > While this can't happen due to WaWmMemoryReadLatency, it can
> > happen if the user clears out the level 0 latency via debugfs.
> >
> > v2: Clarify how how we can end here with zero level 0 latency (Matt)
> >
> > Cc: Matt Roper
> > Reviewed-by: Rodrigo Vivi
> > Signed-off-by: Ville Syrjälä
>
> I wonder whether we should really be letting users shoot themselves in
> the foot with debugfs here. Maybe we should pull the sanitization and
> hardware workarounds out of intel_read_wm_latency() and also apply it to
> whatever debugfs gives us.
I've considered that. But OTOH it's rather nice to be able to override
the workarounds and just test exactly what you want. And no normal
user should be poking around in debugfs anyway. It's only for debugging
and as such is generally understood to contain some amount of dragons.
>
> This is good enough for now though.
>
> Reviewed-by: Matt Roper
>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 27498ded4949..25f589c4f68c 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4704,8 +4704,10 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
> > uint32_t min_disp_buf_needed;
> >
> > - if (latency == 0 ||
> > - !intel_wm_plane_visible(cstate, intel_pstate)) {
> > + if (latency == 0)
> > + return level == 0 ? -EINVAL : 0;
> > +
> > + if (!intel_wm_plane_visible(cstate, intel_pstate)) {
> > result->plane_en = false;
> > return 0;
> > }
> > --
> > 2.18.1
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/13] drm/i915: Clean up skl+ vs. icl+ watermark computation
On Tue, Nov 20, 2018 at 02:44:34PM -0800, Matt Roper wrote:
> On Wed, Nov 14, 2018 at 11:07:24PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make a cleaner split between the skl+ and icl+ ways of computing
> > watermarks. This way skl_build_pipe_wm() doesn't have to know any
> > of the gritty details of icl+ master/slave planes.
> >
> > We can also simplify a bunch of the lower level code by pulling
> > the plane visibility checks a bit higher up.
> >
> > Cc: Matt Roper
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 192 +---
> > 1 file changed, 103 insertions(+), 89 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 59c91ec11c60..a743e089ab7d 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4591,9 +4591,6 @@ skl_compute_plane_wm_params(const struct
> > drm_i915_private *dev_priv,
> > to_intel_atomic_state(cstate->base.state);
> > bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
> >
> > - if (!intel_wm_plane_visible(cstate, intel_pstate))
> > - return 0;
> > -
> > /* only NV12 format has two planes */
> > if (plane_id == 1 && fb->format->format != DRM_FORMAT_NV12) {
> > DRM_DEBUG_KMS("Non NV12 format have single plane\n");
> > @@ -4707,9 +4704,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > if (latency == 0)
> > return level == 0 ? -EINVAL : 0;
> >
> > - if (!intel_wm_plane_visible(cstate, intel_pstate))
> > - return 0;
> > -
> > /* Display WA #1141: kbl,cfl */
> > if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> > IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) &&
> > @@ -4832,21 +4826,16 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >
> > static int
> > skl_compute_wm_levels(const struct drm_i915_private *dev_priv,
> > - struct skl_ddb_allocation *ddb,
> > const struct intel_crtc_state *cstate,
> > const struct intel_plane_state *intel_pstate,
> > uint16_t ddb_blocks,
> > const struct skl_wm_params *wm_params,
> > - struct skl_plane_wm *wm,
> > struct skl_wm_level *levels)
> > {
> > int level, max_level = ilk_wm_max_level(dev_priv);
> > struct skl_wm_level *result_prev = [0];
> > int ret;
> >
> > - if (WARN_ON(!intel_pstate->base.fb))
> > - return -EINVAL;
> > -
> > for (level = 0; level <= max_level; level++) {
> > struct skl_wm_level *result = [level];
> >
> > @@ -4864,9 +4853,6 @@ skl_compute_wm_levels(const struct drm_i915_private
> > *dev_priv,
> > result_prev = result;
> > }
> >
> > - if (intel_pstate->base.fb->format->format == DRM_FORMAT_NV12)
> > - wm->is_planar = true;
> > -
> > return 0;
> > }
> >
> > @@ -4904,9 +4890,6 @@ static void skl_compute_transition_wm(const struct
> > intel_crtc_state *cstate,
> > const uint16_t trans_amount = 10; /* This is configurable amount */
> > uint16_t wm0_sel_res_b, trans_offset_b, res_blocks;
> >
> > - if (!cstate->base.active)
> > - return;
> > -
> > /* Transition WM are not recommended by HW team for GEN9 */
> > if (INTEL_GEN(dev_priv) <= 9)
> > return;
> > @@ -4955,97 +4938,134 @@ static void skl_compute_transition_wm(const struct
> > intel_crtc_state *cstate,
> > }
> > }
> >
> > -static int __skl_build_plane_wm_single(struct skl_ddb_allocation *ddb,
> > - struct skl_pipe_wm *pipe_wm,
> > - enum plane_id plane_id,
> > - const struct intel_crtc_state *cstate,
> > - const struct intel_plane_state *pstate,
> > - int color_plane)
> > -{
> > - struct drm_i915_private *dev_priv = to_i915(pstate->base.plane->dev);
> > - struct skl_plane_wm *wm = _wm->planes[plane_id];
> > - enum pipe pipe = to_intel_plane(pstate->base.plane)->pipe;
> > - struct skl_wm_params wm_params;
> > - uint16_t ddb_blocks = skl_ddb_entry_size(>plane[pipe][plane_id]);
> > - int ret;
> > -
> > - ret = skl_compute_plane_wm_params(dev_priv, cstate, pstate,
> > - _params, color_plane);
> > - if (ret)
> > - return ret;
> > -
> > - ret = skl_compute_wm_levels(dev_priv, ddb, cstate, pstate,
> > - ddb_blocks, _params, wm, wm->wm);
> > -
> > - if (ret)
> > - return ret;
> > -
> > - skl_compute_transition_wm(cstate, _params, wm, ddb_blocks);
> > -
> > - return 0;
> > -}
> > -
> > static int skl_build_plane_wm_single(struct skl_ddb_allocation *ddb,
> > -
Re: [Intel-gfx] [PATCH v2 10/13] drm/i915: Move ddb/wm programming into plane update/disable hooks on skl+
On Tue, Nov 20, 2018 at 04:48:39PM -0800, Matt Roper wrote:
> On Wed, Nov 14, 2018 at 11:07:26PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On SKL+ the plane WM/BUF_CFG registers are a proper part of each
> > plane's register set. That means accessing them will cancel any
> > pending plane update, and we would need a PLANE_SURF register write
> > to arm the wm/ddb change as well.
> >
> > To avoid all the problems with that let's just move the wm/ddb
> > programming into the plane update/disable hooks. Now all plane
> > registers get written in one (hopefully atomic) operation.
> >
> > To make that feasible we'll move the plane ddb tracking into
> > the crtc state. Watermarks were already tracked there.
> >
> > v2: Rebase due to input CSC
> > v3: Split out a bunch of junk (Matt)
> >
> > Cc: Matt Roper
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 21 +-
> > drivers/gpu/drm/i915/i915_drv.h | 3 -
> > drivers/gpu/drm/i915/intel_display.c | 16 +-
> > drivers/gpu/drm/i915/intel_display.h | 11 +-
> > drivers/gpu/drm/i915/intel_drv.h | 9 +
> > drivers/gpu/drm/i915/intel_pm.c | 317 ---
> > drivers/gpu/drm/i915/intel_sprite.c | 4 +
> > 7 files changed, 181 insertions(+), 200 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 670db5073d70..f8b2200947cf 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -3437,31 +3437,32 @@ static int i915_ddb_info(struct seq_file *m, void
> > *unused)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > struct drm_device *dev = _priv->drm;
> > - struct skl_ddb_allocation *ddb;
> > struct skl_ddb_entry *entry;
> > - enum pipe pipe;
> > - int plane;
> > + struct intel_crtc *crtc;
> >
> > if (INTEL_GEN(dev_priv) < 9)
> > return -ENODEV;
> >
> > drm_modeset_lock_all(dev);
> >
> > - ddb = _priv->wm.skl_hw.ddb;
> > -
> > seq_printf(m, "%-15s%8s%8s%8s\n", "", "Start", "End", "Size");
> >
> > - for_each_pipe(dev_priv, pipe) {
> > + for_each_intel_crtc(_priv->drm, crtc) {
> > + struct intel_crtc_state *crtc_state =
> > + to_intel_crtc_state(crtc->base.state);
> > + enum pipe pipe = crtc->pipe;
> > + enum plane_id plane_id;
> > +
> > seq_printf(m, "Pipe %c\n", pipe_name(pipe));
> >
> > - for_each_universal_plane(dev_priv, pipe, plane) {
> > - entry = >plane[pipe][plane];
> > - seq_printf(m, " Plane%-8d%8u%8u%8u\n", plane + 1,
> > + for_each_plane_id_on_crtc(crtc, plane_id) {
> > + entry = _state->wm.skl.plane_ddb_y[plane_id];
> > + seq_printf(m, " Plane%-8d%8u%8u%8u\n", plane_id + 1,
> >entry->start, entry->end,
> >skl_ddb_entry_size(entry));
> > }
> >
> > - entry = >plane[pipe][PLANE_CURSOR];
> > + entry = _state->wm.skl.plane_ddb_y[PLANE_CURSOR];
> > seq_printf(m, " %-13s%8u%8u%8u\n", "Cursor", entry->start,
> >entry->end, skl_ddb_entry_size(entry));
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5d686b585a95..89af64fe90a5 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1241,9 +1241,6 @@ static inline bool skl_ddb_entry_equal(const struct
> > skl_ddb_entry *e1,
> > }
> >
> > struct skl_ddb_allocation {
> > - /* packed/y */
> > - struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
> > - struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES];
> > u8 enabled_slices; /* GEN11 has configurable 2 slices */
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 0caba7258fee..2981cea3704a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10083,6 +10083,10 @@ static void i9xx_update_cursor(struct intel_plane
> > *plane,
> > * except when the plane is getting enabled at which time
> > * the CURCNTR write arms the update.
> > */
> > +
> > + if (INTEL_GEN(dev_priv) >= 9)
> > + skl_write_cursor_wm(plane, crtc_state);
> > +
> > if (plane->cursor.base != base ||
> > plane->cursor.size != fbc_ctl ||
> > plane->cursor.cntl != cntl) {
> > @@ -11872,6 +11876,8 @@ static void verify_wm_state(struct drm_crtc *crtc,
> > struct skl_pipe_wm hw_wm, *sw_wm;
> > struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
> > struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
> > + struct skl_ddb_entry hw_ddb_y[I915_MAX_PLANES];
> > + struct skl_ddb_entry hw_ddb_uv[I915_MAX_PLANES];
> >
Re: [Intel-gfx] [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere
For the nouveau and drm core changes
Reviewed-by: Lyude Paul
On Mon, 2018-11-12 at 16:01 +0100, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Eric Anholt
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Tony Cheng
> Cc: Shirish S
> Cc: Mikita Lipski
> Cc: Bhawanpreet Lakha
> Cc: David Francis
> Cc: Anthony Koo
> Cc: Jeykumar Sankaran
> Cc: Jordan Crouse
> Cc: Bruce Wang
> Cc: Sravanthi Kollukuduru
> Cc: Archit Taneja
> Cc: Steve Kowalik
> Cc: Carsten Behling
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Mahesh Kumar
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--
> drivers/gpu/drm/arm/malidp_crtc.c | 5 +--
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 5 +--
> drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +--
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +---
> drivers/gpu/drm/nouveau/dispnv50/head.c | 13 ++--
> drivers/gpu/drm/omapdrm/omap_crtc.c | 7 ++---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 4 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +++--
> drivers/gpu/drm/tegra/dc.c| 5 +--
> drivers/gpu/drm/vc4/vc4_crtc.c| 8 ++---
> drivers/gpu/drm/vkms/vkms_crtc.c | 7 +
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 +-
> include/drm/drm_atomic_state_helper.h | 2 ++
> 18 files changed, 56 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5064768642f3..770a71726cd1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2802,9 +2802,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
> if (WARN_ON(!state))
> return;
>
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> -
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index e1b72782848c..9a924ff27148 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -474,10 +474,7 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
>
> kfree(state);
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 96f4082671fe..8084d549c7d1 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -412,10 +412,7 @@ static void atmel_hlcdc_crtc_reset(struct drm_crtc
> *crtc)
> }
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> diff --git
Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
Hi Ville, Thank you for the patch. On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: > From: Ville Syrjälä > > Make life easier for drivers by simply passing the connector > to drm_hdmi_avi_infoframe_from_display_mode() and > drm_hdmi_avi_infoframe_quant_range(). That way drivers don't > need to worry about is_hdmi2_sink mess. While this is good for display controller drivers, the change isn't great for bridge drivers. Down the road we're looking at moving connector support out of the bridge drivers. Adding an additional dependency to connectors in the bridges will make that more difficult. Ideally bridges should retrieve the information from their sink, regardless of whether it is a connector or another bridge. Please see below for an additional comment. > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc: Archit Taneja > Cc: Andrzej Hajda > Cc: Laurent Pinchart > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Russell King > Cc: CK Hu > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Tomi Valkeinen > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Thierry Reding > Cc: Eric Anholt > Cc: Shawn Guo > Cc: Ilia Mirkin > Cc: amd-...@lists.freedesktop.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-te...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++-- > drivers/gpu/drm/bridge/sii902x.c | 3 ++- > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +-- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++- > drivers/gpu/drm/drm_edid.c| 33 ++- > drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++- > drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++- > drivers/gpu/drm/i915/intel_hdmi.c | 14 +- > drivers/gpu/drm/i915/intel_lspcon.c | 15 ++- > drivers/gpu/drm/i915/intel_sdvo.c | 10 --- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++- > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++-- > drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++-- > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++- > drivers/gpu/drm/sti/sti_hdmi.c| 3 ++- > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++- > drivers/gpu/drm/tegra/hdmi.c | 3 ++- > drivers/gpu/drm/tegra/sor.c | 3 ++- > drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +--- > drivers/gpu/drm/zte/zx_hdmi.c | 4 ++- > include/drm/drm_edid.h| 8 +++--- > 27 files changed, 94 insertions(+), 66 deletions(-) For dw-hdmi and omapdrm, Reviewed-by: Laurent Pinchart -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Downgrade unknown CSR firmware warnings
On Wed, Nov 21, 2018 at 11:29:02AM +0200, Jani Nikula wrote:
> On Fri, 16 Nov 2018, Lucas De Marchi wrote:
> > Like it was done in commit 9e180d9991dc ("drm/i915: Downgrade unknown
> > firmware warnings") for huc and guc: downgrade CSR firmware warnings. If
> > we have released no firmware yet for a platform, stop scaring the
> > consumer and merely note its expected absence.
> >
> > By simply removing the warning and early return we hit the condition
> > with the appropriate message.
> >
> > Cc: Chris Wilson
> > Cc: Joonas Lahtinen
> > Signed-off-by: Lucas De Marchi
>
> *sigh*
ops, I just noticed that I forgot to reply here yesterday after
merging these to dinq. :/
>
> This patch would not have been needed at all with patch 1/2.
>
> The point was that we shouldn't proceed without the max fw size
> set. Even with the module parameter. Because that would fail at the
> firmware loading stage later.
>
> If the warn was such a big deal, it should've been changed to a debug
> message with an early return, not removed.
hmmm... that's a good point...
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/intel_csr.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index b4476d891fa3..a516697bf57d 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -496,9 +496,6 @@ void intel_csr_ucode_init(struct drm_i915_private
> > *dev_priv)
> > csr->fw_path = BXT_CSR_PATH;
> > csr->required_version = BXT_CSR_VERSION_REQUIRED;
> > csr->max_fw_size = BXT_CSR_MAX_FW_SIZE;
> > - } else {
> > - MISSING_CASE(INTEL_REVID(dev_priv));
> > - return;
> > }
> >
> > if (i915_modparams.dmc_firmware_path) {
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix TV encoder support (rev2)
== Series Details == Series: drm/i915: Fix TV encoder support (rev2) URL : https://patchwork.freedesktop.org/series/52378/ State : failure == Summary == Applying: drm/vblank: Allow dynamic per-crtc max_vblank_count error: patch failed: drivers/gpu/drm/i915/i915_irq.c:822 error: drivers/gpu/drm/i915/i915_irq.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_irq.c Patch failed at 0001 drm/vblank: Allow dynamic per-crtc max_vblank_count 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
Re: [Intel-gfx] [PATCH 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count
On Wed, Nov 21, 2018 at 05:22:49PM +0100, Daniel Vetter wrote:
> On Wed, Nov 21, 2018 at 5:16 PM Ville Syrjälä
> wrote:
> >
> > On Wed, Nov 21, 2018 at 04:19:36PM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 21, 2018 at 01:37:51PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Nov 21, 2018 at 10:27:27AM +0100, Daniel Vetter wrote:
> > > > > On Mon, Nov 12, 2018 at 06:59:45PM +0200, Ville Syrjala wrote:
> > > > > > From: Ville Syrjälä
> > > > > >
> > > > > > On i965gm we need to adjust max_vblank_count dynamically
> > > > > > depending on whether the TV encoder is used or not. To
> > > > > > that end add a per-crtc max_vblank_count that takes
> > > > > > precedence over its device wide counterpart. The driver
> > > > > > can now call drm_crtc_set_max_vblank_count() to configure
> > > > > > the per-crtc value before calling drm_vblank_on().
> > > > > >
> > > > > > Also looks like there was some discussion about exynos needing
> > > > > > similar treatment.
> > > > > >
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > Cc: Inki Dae
> > > > > > Cc: Daniel Vetter
> > > > > > Signed-off-by: Ville Syrjälä
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_vblank.c | 39
> > > > > >
> > > > > > include/drm/drm_vblank.h | 8
> > > > > > 2 files changed, 43 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c
> > > > > > b/drivers/gpu/drm/drm_vblank.c
> > > > > > index 98e091175921..c3abbdca8aba 100644
> > > > > > --- a/drivers/gpu/drm/drm_vblank.c
> > > > > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > > > > @@ -105,13 +105,20 @@ static void store_vblank(struct drm_device
> > > > > > *dev, unsigned int pipe,
> > > > > > write_sequnlock(>seqlock);
> > > > > > }
> > > > > >
> > > > > > +static u32 drm_max_vblank_count(struct drm_device *dev, unsigned
> > > > > > int pipe)
> > > > > > +{
> > > > > > + struct drm_vblank_crtc *vblank = >vblank[pipe];
> > > > > > +
> > > > > > + return vblank->max_vblank_count ?: dev->max_vblank_count;
> > > > > > +}
> > > > > > +
> > > > > > /*
> > > > > > * "No hw counter" fallback implementation of
> > > > > > .get_vblank_counter() hook,
> > > > > > * if there is no useable hardware frame counter available.
> > > > > > */
> > > > > > static u32 drm_vblank_no_hw_counter(struct drm_device *dev,
> > > > > > unsigned int pipe)
> > > > > > {
> > > > > > - WARN_ON_ONCE(dev->max_vblank_count != 0);
> > > > > > + WARN_ON_ONCE(drm_max_vblank_count(dev, pipe) != 0);
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > @@ -198,6 +205,7 @@ static void drm_update_vblank_count(struct
> > > > > > drm_device *dev, unsigned int pipe,
> > > > > > ktime_t t_vblank;
> > > > > > int count = DRM_TIMESTAMP_MAXRETRIES;
> > > > > > int framedur_ns = vblank->framedur_ns;
> > > > > > + u32 max_vblank_count = drm_max_vblank_count(dev, pipe);
> > > > > >
> > > > > > /*
> > > > > > * Interrupts were disabled prior to this call, so deal
> > > > > > with counter
> > > > > > @@ -216,9 +224,9 @@ static void drm_update_vblank_count(struct
> > > > > > drm_device *dev, unsigned int pipe,
> > > > > > rc = drm_get_last_vbltimestamp(dev, pipe,
> > > > > > _vblank, in_vblank_irq);
> > > > > > } while (cur_vblank != __get_vblank_counter(dev, pipe) &&
> > > > > > --count > 0);
> > > > > >
> > > > > > - if (dev->max_vblank_count != 0) {
> > > > > > + if (max_vblank_count) {
> > > > > > /* trust the hw counter when it's around */
> > > > > > - diff = (cur_vblank - vblank->last) &
> > > > > > dev->max_vblank_count;
> > > > > > + diff = (cur_vblank - vblank->last) &
> > > > > > max_vblank_count;
> > > > > > } else if (rc && framedur_ns) {
> > > > > > u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank,
> > > > > > vblank->time));
> > > > > >
> > > > > > @@ -258,7 +266,8 @@ static void drm_update_vblank_count(struct
> > > > > > drm_device *dev, unsigned int pipe,
> > > > > > pipe, vblank->count, diff, cur_vblank,
> > > > > > vblank->last);
> > > > > >
> > > > > > if (diff == 0) {
> > > > > > - WARN_ON_ONCE(cur_vblank != vblank->last);
> > > > > > + WARN_ON_ONCE(max_vblank_count &&
> > > > > > +cur_vblank != vblank->last);
> > > > >
> > > > > Unrelated bugfix for this warning? Should be a separate patch I
> > > > > think, or
> > > > > I'm missing something.
> > > >
> > > > Ah, yeah this was due to a quirk of i965gm hardware. The hw counter
> > > > does work until the exact point when we enable TV encoder. Thus we
> > > > will get non-zero values up to that point, and since the TV encoder
> > > > isn't yet throttling the pipe it presumably runs at the oversample
> > > > clock so our timestamp based estimates can give us a diff==0 even
> > > >
Re: [Intel-gfx] [PATCH 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count
On Wed, Nov 21, 2018 at 5:16 PM Ville Syrjälä
wrote:
>
> On Wed, Nov 21, 2018 at 04:19:36PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 21, 2018 at 01:37:51PM +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 21, 2018 at 10:27:27AM +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 12, 2018 at 06:59:45PM +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > On i965gm we need to adjust max_vblank_count dynamically
> > > > > depending on whether the TV encoder is used or not. To
> > > > > that end add a per-crtc max_vblank_count that takes
> > > > > precedence over its device wide counterpart. The driver
> > > > > can now call drm_crtc_set_max_vblank_count() to configure
> > > > > the per-crtc value before calling drm_vblank_on().
> > > > >
> > > > > Also looks like there was some discussion about exynos needing
> > > > > similar treatment.
> > > > >
> > > > > Cc: sta...@vger.kernel.org
> > > > > Cc: Inki Dae
> > > > > Cc: Daniel Vetter
> > > > > Signed-off-by: Ville Syrjälä
> > > > > ---
> > > > > drivers/gpu/drm/drm_vblank.c | 39
> > > > >
> > > > > include/drm/drm_vblank.h | 8
> > > > > 2 files changed, 43 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_vblank.c
> > > > > b/drivers/gpu/drm/drm_vblank.c
> > > > > index 98e091175921..c3abbdca8aba 100644
> > > > > --- a/drivers/gpu/drm/drm_vblank.c
> > > > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > > > @@ -105,13 +105,20 @@ static void store_vblank(struct drm_device
> > > > > *dev, unsigned int pipe,
> > > > > write_sequnlock(>seqlock);
> > > > > }
> > > > >
> > > > > +static u32 drm_max_vblank_count(struct drm_device *dev, unsigned int
> > > > > pipe)
> > > > > +{
> > > > > + struct drm_vblank_crtc *vblank = >vblank[pipe];
> > > > > +
> > > > > + return vblank->max_vblank_count ?: dev->max_vblank_count;
> > > > > +}
> > > > > +
> > > > > /*
> > > > > * "No hw counter" fallback implementation of .get_vblank_counter()
> > > > > hook,
> > > > > * if there is no useable hardware frame counter available.
> > > > > */
> > > > > static u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned
> > > > > int pipe)
> > > > > {
> > > > > - WARN_ON_ONCE(dev->max_vblank_count != 0);
> > > > > + WARN_ON_ONCE(drm_max_vblank_count(dev, pipe) != 0);
> > > > > return 0;
> > > > > }
> > > > >
> > > > > @@ -198,6 +205,7 @@ static void drm_update_vblank_count(struct
> > > > > drm_device *dev, unsigned int pipe,
> > > > > ktime_t t_vblank;
> > > > > int count = DRM_TIMESTAMP_MAXRETRIES;
> > > > > int framedur_ns = vblank->framedur_ns;
> > > > > + u32 max_vblank_count = drm_max_vblank_count(dev, pipe);
> > > > >
> > > > > /*
> > > > > * Interrupts were disabled prior to this call, so deal with
> > > > > counter
> > > > > @@ -216,9 +224,9 @@ static void drm_update_vblank_count(struct
> > > > > drm_device *dev, unsigned int pipe,
> > > > > rc = drm_get_last_vbltimestamp(dev, pipe, _vblank,
> > > > > in_vblank_irq);
> > > > > } while (cur_vblank != __get_vblank_counter(dev, pipe) &&
> > > > > --count > 0);
> > > > >
> > > > > - if (dev->max_vblank_count != 0) {
> > > > > + if (max_vblank_count) {
> > > > > /* trust the hw counter when it's around */
> > > > > - diff = (cur_vblank - vblank->last) &
> > > > > dev->max_vblank_count;
> > > > > + diff = (cur_vblank - vblank->last) & max_vblank_count;
> > > > > } else if (rc && framedur_ns) {
> > > > > u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank,
> > > > > vblank->time));
> > > > >
> > > > > @@ -258,7 +266,8 @@ static void drm_update_vblank_count(struct
> > > > > drm_device *dev, unsigned int pipe,
> > > > > pipe, vblank->count, diff, cur_vblank,
> > > > > vblank->last);
> > > > >
> > > > > if (diff == 0) {
> > > > > - WARN_ON_ONCE(cur_vblank != vblank->last);
> > > > > + WARN_ON_ONCE(max_vblank_count &&
> > > > > +cur_vblank != vblank->last);
> > > >
> > > > Unrelated bugfix for this warning? Should be a separate patch I think,
> > > > or
> > > > I'm missing something.
> > >
> > > Ah, yeah this was due to a quirk of i965gm hardware. The hw counter
> > > does work until the exact point when we enable TV encoder. Thus we
> > > will get non-zero values up to that point, and since the TV encoder
> > > isn't yet throttling the pipe it presumably runs at the oversample
> > > clock so our timestamp based estimates can give us a diff==0 even
> > > though the pipe did indeed pass a vblank already. I forgot to
> > > note this in the commit message.
> > >
> > > I think we can handle this three ways:
> > > 1. do what I do here and just let the mismatch slip through
> > > 2. force i915_get_vblank_counter() to return 0 always when the
> >
Re: [Intel-gfx] [PATCH 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count
On Wed, Nov 21, 2018 at 04:19:36PM +0100, Daniel Vetter wrote:
> On Wed, Nov 21, 2018 at 01:37:51PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 21, 2018 at 10:27:27AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 12, 2018 at 06:59:45PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > On i965gm we need to adjust max_vblank_count dynamically
> > > > depending on whether the TV encoder is used or not. To
> > > > that end add a per-crtc max_vblank_count that takes
> > > > precedence over its device wide counterpart. The driver
> > > > can now call drm_crtc_set_max_vblank_count() to configure
> > > > the per-crtc value before calling drm_vblank_on().
> > > >
> > > > Also looks like there was some discussion about exynos needing
> > > > similar treatment.
> > > >
> > > > Cc: sta...@vger.kernel.org
> > > > Cc: Inki Dae
> > > > Cc: Daniel Vetter
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/drm_vblank.c | 39
> > > > include/drm/drm_vblank.h | 8
> > > > 2 files changed, 43 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > > index 98e091175921..c3abbdca8aba 100644
> > > > --- a/drivers/gpu/drm/drm_vblank.c
> > > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > > @@ -105,13 +105,20 @@ static void store_vblank(struct drm_device *dev,
> > > > unsigned int pipe,
> > > > write_sequnlock(>seqlock);
> > > > }
> > > >
> > > > +static u32 drm_max_vblank_count(struct drm_device *dev, unsigned int
> > > > pipe)
> > > > +{
> > > > + struct drm_vblank_crtc *vblank = >vblank[pipe];
> > > > +
> > > > + return vblank->max_vblank_count ?: dev->max_vblank_count;
> > > > +}
> > > > +
> > > > /*
> > > > * "No hw counter" fallback implementation of .get_vblank_counter()
> > > > hook,
> > > > * if there is no useable hardware frame counter available.
> > > > */
> > > > static u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned
> > > > int pipe)
> > > > {
> > > > - WARN_ON_ONCE(dev->max_vblank_count != 0);
> > > > + WARN_ON_ONCE(drm_max_vblank_count(dev, pipe) != 0);
> > > > return 0;
> > > > }
> > > >
> > > > @@ -198,6 +205,7 @@ static void drm_update_vblank_count(struct
> > > > drm_device *dev, unsigned int pipe,
> > > > ktime_t t_vblank;
> > > > int count = DRM_TIMESTAMP_MAXRETRIES;
> > > > int framedur_ns = vblank->framedur_ns;
> > > > + u32 max_vblank_count = drm_max_vblank_count(dev, pipe);
> > > >
> > > > /*
> > > > * Interrupts were disabled prior to this call, so deal with
> > > > counter
> > > > @@ -216,9 +224,9 @@ static void drm_update_vblank_count(struct
> > > > drm_device *dev, unsigned int pipe,
> > > > rc = drm_get_last_vbltimestamp(dev, pipe, _vblank,
> > > > in_vblank_irq);
> > > > } while (cur_vblank != __get_vblank_counter(dev, pipe) &&
> > > > --count > 0);
> > > >
> > > > - if (dev->max_vblank_count != 0) {
> > > > + if (max_vblank_count) {
> > > > /* trust the hw counter when it's around */
> > > > - diff = (cur_vblank - vblank->last) &
> > > > dev->max_vblank_count;
> > > > + diff = (cur_vblank - vblank->last) & max_vblank_count;
> > > > } else if (rc && framedur_ns) {
> > > > u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank,
> > > > vblank->time));
> > > >
> > > > @@ -258,7 +266,8 @@ static void drm_update_vblank_count(struct
> > > > drm_device *dev, unsigned int pipe,
> > > > pipe, vblank->count, diff, cur_vblank,
> > > > vblank->last);
> > > >
> > > > if (diff == 0) {
> > > > - WARN_ON_ONCE(cur_vblank != vblank->last);
> > > > + WARN_ON_ONCE(max_vblank_count &&
> > > > +cur_vblank != vblank->last);
> > >
> > > Unrelated bugfix for this warning? Should be a separate patch I think, or
> > > I'm missing something.
> >
> > Ah, yeah this was due to a quirk of i965gm hardware. The hw counter
> > does work until the exact point when we enable TV encoder. Thus we
> > will get non-zero values up to that point, and since the TV encoder
> > isn't yet throttling the pipe it presumably runs at the oversample
> > clock so our timestamp based estimates can give us a diff==0 even
> > though the pipe did indeed pass a vblank already. I forgot to
> > note this in the commit message.
> >
> > I think we can handle this three ways:
> > 1. do what I do here and just let the mismatch slip through
> > 2. force i915_get_vblank_counter() to return 0 always when the
> >TV encoder is going to be used
> > 3. don't call drm_crtc_set_max_vblank_count() before drm_vblank_on()
> >and instead delay it until just before we enable the TV encoder
> >
> > I think option 3 is overly complicated to consider seriously. So
> > option 1 or option 2 is
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Another light -fixes pull, either we've really got our act together this release or the hammer is about to drop. I'll go with the optimistic take :-) Hope the time adjustment back to upside-down-time has been smooth for you! drm-misc-fixes-2018-11-21: - vc4: Fix NULL deref in async path (Boris) - vc4: Avoid taking async path for cursor updates when impossible (Boris) - udmabuf: Fix mmap with PROT_WRITE (Gerd) - fb-helper: Don't use writeback connectors for fbdev (Paul) Cc: Boris Brezillon Cc: Gerd Hoffmann Cc: Paul Kocialkowski Cheers, Sean The following changes since commit adf59dd2408c4536d490bee649784f0465562444: drm/meson: venc: dmt mode must use encp (2018-11-13 10:52:33 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-11-21 for you to fetch changes up to 8fd3b90300bec541806dac271de2fd44e2e4e2d2: drm/fb-helper: Blacklist writeback when adding connectors to fbdev (2018-11-21 10:38:19 +0100) - vc4: Fix NULL deref in async path (Boris) - vc4: Avoid taking async path for cursor updates when impossible (Boris) - udmabuf: Fix mmap with PROT_WRITE (Gerd) - fb-helper: Don't use writeback connectors for fbdev (Paul) Cc: Boris Brezillon Cc: Gerd Hoffmann Cc: Paul Kocialkowski Boris Brezillon (2): drm/vc4: Fix NULL pointer dereference in the async update path drm/vc4: Set ->legacy_cursor_update to false when doing non-async updates Gerd Hoffmann (1): udmabuf: set read/write flag when exporting Paul Kocialkowski (1): drm/fb-helper: Blacklist writeback when adding connectors to fbdev drivers/dma-buf/udmabuf.c | 1 + drivers/gpu/drm/drm_fb_helper.c | 3 +++ drivers/gpu/drm/vc4/vc4_kms.c | 6 ++ drivers/gpu/drm/vc4/vc4_plane.c | 15 +-- 4 files changed, 23 insertions(+), 2 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ 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: Show waiter's status on engine dump (rev2)
== Series Details ==
Series: drm/i915: Show waiter's status on engine dump (rev2)
URL : https://patchwork.freedesktop.org/series/52825/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5181 -> Patchwork_10880 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/52825/revisions/2/mbox/
== Known issues ==
Here are the changes found in Patchwork_10880 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_ctx_create@basic-files:
fi-icl-u2: PASS -> DMESG-WARN (fdo#107724)
igt@gem_exec_suspend@basic-s3:
fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718)
{igt@runner@aborted}:
{fi-icl-y}: NOTRUN -> FAIL (fdo#108070)
Possible fixes
igt@gem_exec_suspend@basic-s3:
fi-icl-u2: DMESG-WARN (fdo#107724) -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-b:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
fdo#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724
fdo#108070 https://bugs.freedesktop.org/show_bug.cgi?id=108070
== Participating hosts (50 -> 45) ==
Additional (2): fi-icl-y fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-u3
== Build changes ==
* Linux: CI_DRM_5181 -> Patchwork_10880
CI_DRM_5181: 02b58f1ad4ca6ac69b69d9dbc7ee5043ebd25919 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4724: 29ae0925abe1d3a0202059538559468ad947d42d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10880: f58921f55b140f38d3c2103c1796bb9376d3e946 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f58921f55b14 drm/i915: Show waiter's status on engine dump
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10880/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Show waiter's status on engine dump
On 21/11/2018 15:16, Chris Wilson wrote:
When showing the list of waiters, include the task's status so that we
can tell if they have been woken up and are waiting for the CPU, or if
they are still waiting to be woken.
v2: task_state_to_char()
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 885a901b6e13..99b05fc3bb24 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1562,8 +1562,10 @@ void intel_engine_dump(struct intel_engine_cs *engine,
for (rb = rb_first(>waiters); rb; rb = rb_next(rb)) {
struct intel_wait *w = rb_entry(rb, typeof(*w), node);
- drm_printf(m, "\t%s [%d] waiting for %x\n",
- w->tsk->comm, w->tsk->pid, w->seqno);
+ drm_printf(m, "\t%s [%d] (%c) waiting for %x\n",
+ w->tsk->comm, w->tsk->pid,
+ task_state_to_char(w->tsk),
+ w->seqno);
}
spin_unlock(>rb_lock);
local_irq_restore(flags);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show waiter's status on engine dump
== Series Details == Series: drm/i915: Show waiter's status on engine dump URL : https://patchwork.freedesktop.org/series/52825/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5181 -> Patchwork_10879 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/52825/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10879 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-icl-u2: PASS -> DMESG-WARN (fdo#107724) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) +1 fi-blb-e6850: NOTRUN -> INCOMPLETE (fdo#107718) Possible fixes igt@gem_exec_suspend@basic-s3: fi-icl-u2: DMESG-WARN (fdo#107724) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b: fi-byt-clapper: FAIL (fdo#107362) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724 == Participating hosts (50 -> 44) == Additional (1): fi-pnv-d510 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 == Build changes == * Linux: CI_DRM_5181 -> Patchwork_10879 CI_DRM_5181: 02b58f1ad4ca6ac69b69d9dbc7ee5043ebd25919 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4724: 29ae0925abe1d3a0202059538559468ad947d42d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10879: 4786a3e5f5baae5ac00d368bd54bd2e2b8077e05 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4786a3e5f5ba drm/i915: Show waiter's status on engine dump == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10879/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count
On Wed, Nov 21, 2018 at 01:37:51PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 21, 2018 at 10:27:27AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 12, 2018 at 06:59:45PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > On i965gm we need to adjust max_vblank_count dynamically
> > > depending on whether the TV encoder is used or not. To
> > > that end add a per-crtc max_vblank_count that takes
> > > precedence over its device wide counterpart. The driver
> > > can now call drm_crtc_set_max_vblank_count() to configure
> > > the per-crtc value before calling drm_vblank_on().
> > >
> > > Also looks like there was some discussion about exynos needing
> > > similar treatment.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Cc: Inki Dae
> > > Cc: Daniel Vetter
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_vblank.c | 39
> > > include/drm/drm_vblank.h | 8
> > > 2 files changed, 43 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > index 98e091175921..c3abbdca8aba 100644
> > > --- a/drivers/gpu/drm/drm_vblank.c
> > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > @@ -105,13 +105,20 @@ static void store_vblank(struct drm_device *dev,
> > > unsigned int pipe,
> > > write_sequnlock(>seqlock);
> > > }
> > >
> > > +static u32 drm_max_vblank_count(struct drm_device *dev, unsigned int
> > > pipe)
> > > +{
> > > + struct drm_vblank_crtc *vblank = >vblank[pipe];
> > > +
> > > + return vblank->max_vblank_count ?: dev->max_vblank_count;
> > > +}
> > > +
> > > /*
> > > * "No hw counter" fallback implementation of .get_vblank_counter() hook,
> > > * if there is no useable hardware frame counter available.
> > > */
> > > static u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int
> > > pipe)
> > > {
> > > - WARN_ON_ONCE(dev->max_vblank_count != 0);
> > > + WARN_ON_ONCE(drm_max_vblank_count(dev, pipe) != 0);
> > > return 0;
> > > }
> > >
> > > @@ -198,6 +205,7 @@ static void drm_update_vblank_count(struct drm_device
> > > *dev, unsigned int pipe,
> > > ktime_t t_vblank;
> > > int count = DRM_TIMESTAMP_MAXRETRIES;
> > > int framedur_ns = vblank->framedur_ns;
> > > + u32 max_vblank_count = drm_max_vblank_count(dev, pipe);
> > >
> > > /*
> > >* Interrupts were disabled prior to this call, so deal with counter
> > > @@ -216,9 +224,9 @@ static void drm_update_vblank_count(struct drm_device
> > > *dev, unsigned int pipe,
> > > rc = drm_get_last_vbltimestamp(dev, pipe, _vblank,
> > > in_vblank_irq);
> > > } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
> > >
> > > - if (dev->max_vblank_count != 0) {
> > > + if (max_vblank_count) {
> > > /* trust the hw counter when it's around */
> > > - diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
> > > + diff = (cur_vblank - vblank->last) & max_vblank_count;
> > > } else if (rc && framedur_ns) {
> > > u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
> > >
> > > @@ -258,7 +266,8 @@ static void drm_update_vblank_count(struct drm_device
> > > *dev, unsigned int pipe,
> > > pipe, vblank->count, diff, cur_vblank, vblank->last);
> > >
> > > if (diff == 0) {
> > > - WARN_ON_ONCE(cur_vblank != vblank->last);
> > > + WARN_ON_ONCE(max_vblank_count &&
> > > + cur_vblank != vblank->last);
> >
> > Unrelated bugfix for this warning? Should be a separate patch I think, or
> > I'm missing something.
>
> Ah, yeah this was due to a quirk of i965gm hardware. The hw counter
> does work until the exact point when we enable TV encoder. Thus we
> will get non-zero values up to that point, and since the TV encoder
> isn't yet throttling the pipe it presumably runs at the oversample
> clock so our timestamp based estimates can give us a diff==0 even
> though the pipe did indeed pass a vblank already. I forgot to
> note this in the commit message.
>
> I think we can handle this three ways:
> 1. do what I do here and just let the mismatch slip through
> 2. force i915_get_vblank_counter() to return 0 always when the
>TV encoder is going to be used
> 3. don't call drm_crtc_set_max_vblank_count() before drm_vblank_on()
>and instead delay it until just before we enable the TV encoder
>
> I think option 3 is overly complicated to consider seriously. So
> option 1 or option 2 is what I think we should do. For whatever
> reason I went with option 1 here, but maybe option 2 is better
> since it would be all contained within i915...
Delay drm_crtc_vblank_on until the vblank is stable? That seems like the
semantically clean solution to me, instead of hacking around in core code
when drivers leak garbage out ...
-Daniel
> >
> > > return;
> > > }
> > >
> > > @@ -1204,6 +1213,28 @@ void drm_crtc_vblank_reset(struct drm_crtc *crtc)
> > > }
[Intel-gfx] [PATCH] drm/i915: Show waiter's status on engine dump
When showing the list of waiters, include the task's status so that we
can tell if they have been woken up and are waiting for the CPU, or if
they are still waiting to be woken.
v2: task_state_to_char()
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 885a901b6e13..99b05fc3bb24 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1562,8 +1562,10 @@ void intel_engine_dump(struct intel_engine_cs *engine,
for (rb = rb_first(>waiters); rb; rb = rb_next(rb)) {
struct intel_wait *w = rb_entry(rb, typeof(*w), node);
- drm_printf(m, "\t%s [%d] waiting for %x\n",
- w->tsk->comm, w->tsk->pid, w->seqno);
+ drm_printf(m, "\t%s [%d] (%c) waiting for %x\n",
+ w->tsk->comm, w->tsk->pid,
+ task_state_to_char(w->tsk),
+ w->seqno);
}
spin_unlock(>rb_lock);
local_irq_restore(flags);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Show waiter's status on engine dump
Quoting Tvrtko Ursulin (2018-11-21 15:08:27)
>
> On 21/11/2018 13:09, Chris Wilson wrote:
> > When showing the list of waiters, include the task's status so that we
> > can tell if they have been woken up and are waiting for the CPU, or if
> > they are still waiting to be woken.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index 885a901b6e13..f6554d5eb1cf 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -1562,8 +1562,10 @@ void intel_engine_dump(struct intel_engine_cs
> > *engine,
> > for (rb = rb_first(>waiters); rb; rb = rb_next(rb)) {
> > struct intel_wait *w = rb_entry(rb, typeof(*w), node);
> >
> > - drm_printf(m, "\t%s [%d] waiting for %x\n",
> > -w->tsk->comm, w->tsk->pid, w->seqno);
> > + drm_printf(m, "\t%s [%d] (state:%lx, %s) waiting for %x\n",
> > +w->tsk->comm, w->tsk->pid, w->tsk->state,
> > +w->tsk->state & TASK_NORMAL ? "asleep" :
> > "runnable",
> > +w->seqno);
> > }
> > spin_unlock(>rb_lock);
> > local_irq_restore(flags);
> >
>
> I don't like this low level fishing much. Would task_state_to_char
> helper be sufficient here?
Hah, you just snuck that in right?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Show waiter's status on engine dump
On 21/11/2018 13:09, Chris Wilson wrote:
When showing the list of waiters, include the task's status so that we
can tell if they have been woken up and are waiting for the CPU, or if
they are still waiting to be woken.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 885a901b6e13..f6554d5eb1cf 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1562,8 +1562,10 @@ void intel_engine_dump(struct intel_engine_cs *engine,
for (rb = rb_first(>waiters); rb; rb = rb_next(rb)) {
struct intel_wait *w = rb_entry(rb, typeof(*w), node);
- drm_printf(m, "\t%s [%d] waiting for %x\n",
- w->tsk->comm, w->tsk->pid, w->seqno);
+ drm_printf(m, "\t%s [%d] (state:%lx, %s) waiting for %x\n",
+ w->tsk->comm, w->tsk->pid, w->tsk->state,
+ w->tsk->state & TASK_NORMAL ? "asleep" : "runnable",
+ w->seqno);
}
spin_unlock(>rb_lock);
local_irq_restore(flags);
I don't like this low level fishing much. Would task_state_to_char
helper be sufficient here?
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 drm/i915/execlists: Poison the CSB after use (rev2)
== Series Details ==
Series: drm/i915/execlists: Poison the CSB after use (rev2)
URL : https://patchwork.freedesktop.org/series/51703/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5181 -> Patchwork_10878 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/51703/revisions/2/mbox/
== Known issues ==
Here are the changes found in Patchwork_10878 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_ctx_create@basic-files:
fi-icl-u2: PASS -> DMESG-WARN (fdo#107724)
igt@i915_module_load@reload:
fi-blb-e6850: NOTRUN -> INCOMPLETE (fdo#107718)
igt@i915_selftest@live_hangcheck:
fi-kbl-7560u: PASS -> INCOMPLETE (fdo#108044)
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362)
{igt@runner@aborted}:
{fi-icl-y}: NOTRUN -> FAIL (fdo#108070)
Possible fixes
igt@gem_exec_suspend@basic-s3:
fi-icl-u2: DMESG-WARN (fdo#107724) -> PASS
igt@gem_exec_suspend@basic-s4-devices:
fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-b:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
fdo#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724
fdo#108044 https://bugs.freedesktop.org/show_bug.cgi?id=108044
fdo#108070 https://bugs.freedesktop.org/show_bug.cgi?id=108070
== Participating hosts (50 -> 44) ==
Additional (2): fi-icl-y fi-pnv-d510
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-apl-guc fi-ctg-p8600 fi-icl-u3
== Build changes ==
* Linux: CI_DRM_5181 -> Patchwork_10878
CI_DRM_5181: 02b58f1ad4ca6ac69b69d9dbc7ee5043ebd25919 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4724: 29ae0925abe1d3a0202059538559468ad947d42d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10878: e2893f8cc5820116cf6ef4c4b4f814b2513ec709 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e2893f8cc582 drm/i915/execlists: Poison the CSB after use
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10878/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: avoid rebuilding i915_gpu_error.o on version string updates
== Series Details ==
Series: drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
URL : https://patchwork.freedesktop.org/series/52822/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5181 -> Patchwork_10877 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/52822/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10877 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@read-crc-pipe-a:
fi-byt-clapper: PASS -> FAIL (fdo#107362)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) +2
{igt@runner@aborted}:
{fi-icl-y}: NOTRUN -> FAIL (fdo#108070)
Possible fixes
igt@gem_exec_suspend@basic-s4-devices:
fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-b:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
fdo#108070 https://bugs.freedesktop.org/show_bug.cgi?id=108070
== Participating hosts (50 -> 45) ==
Additional (2): fi-icl-y fi-pnv-d510
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-u3
== Build changes ==
* Linux: CI_DRM_5181 -> Patchwork_10877
CI_DRM_5181: 02b58f1ad4ca6ac69b69d9dbc7ee5043ebd25919 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4724: 29ae0925abe1d3a0202059538559468ad947d42d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10877: a6ae7aabf16739513cb87f86737992801c4bc856 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a6ae7aabf167 drm/i915: avoid rebuilding i915_gpu_error.o on version string
updates
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10877/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 drm/i915: Release power well if load DMC failed
== Series Details ==
Series: drm/i915: Release power well if load DMC failed
URL : https://patchwork.freedesktop.org/series/52805/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5175_full -> Patchwork_10875_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10875_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10875_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_10875_full:
=== IGT changes ===
Warnings
igt@tools_test@sysfs_l3_parity:
shard-hsw: SKIP -> PASS
igt@tools_test@tools_test:
{shard-iclb}: SKIP -> PASS
== Known issues ==
Here are the changes found in Patchwork_10875_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@gem_eio@in-flight-suspend:
shard-glk: PASS -> DMESG-WARN (fdo#107957)
igt@gem_exec_schedule@pi-ringfull-bsd:
shard-skl: NOTRUN -> FAIL (fdo#103158)
igt@gem_userptr_blits@readonly-unsync:
shard-skl: NOTRUN -> INCOMPLETE (fdo#108074)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +1
igt@kms_cursor_crc@cursor-128x42-random:
shard-glk: PASS -> FAIL (fdo#103232) +3
igt@kms_cursor_crc@cursor-64x64-suspend:
shard-skl: PASS -> INCOMPLETE (fdo#104108) +1
igt@kms_draw_crc@draw-method-xrgb-blt-xtiled:
shard-skl: PASS -> FAIL (fdo#107791)
igt@kms_flip@flip-vs-expired-vblank-interruptible:
shard-glk: PASS -> FAIL (fdo#105363)
igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
shard-skl: PASS -> FAIL (fdo#103167) +2
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
shard-apl: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
{shard-iclb}: PASS -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
shard-glk: PASS -> FAIL (fdo#103167) +7
igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack:
shard-skl: PASS -> FAIL (fdo#105682) +1
igt@kms_plane@plane-position-covered-pipe-a-planes:
{shard-iclb}: PASS -> FAIL (fdo#103166) +1
igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
shard-skl: NOTRUN -> FAIL (fdo#108145)
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-apl: PASS -> FAIL (fdo#103166) +2
igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format:
{shard-iclb}: PASS -> DMESG-WARN (fdo#107724) +1
igt@kms_setmode@basic:
shard-hsw: PASS -> FAIL (fdo#99912)
igt@pm_rpm@modeset-non-lpsp-stress-no-wait:
shard-skl: SKIP -> INCOMPLETE (fdo#107807)
Possible fixes
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
shard-hsw: DMESG-WARN (fdo#107956) -> PASS
igt@kms_chv_cursor_fail@pipe-b-256x256-right-edge:
shard-skl: FAIL (fdo#104671) -> PASS
igt@kms_color@pipe-c-ctm-0-75:
shard-skl: FAIL (fdo#108682) -> PASS
igt@kms_cursor_crc@cursor-256x85-onscreen:
shard-glk: FAIL (fdo#103232) -> PASS +2
igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic:
shard-glk: FAIL (fdo#106509, fdo#105454) -> PASS
igt@kms_draw_crc@draw-method-xrgb-render-ytiled:
{shard-iclb}: WARN (fdo#108336) -> PASS +2
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff:
shard-apl: FAIL (fdo#103167) -> PASS +1
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
{shard-iclb}: FAIL (fdo#103167) -> PASS
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
shard-glk: FAIL (fdo#103167) -> PASS +1
igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
{shard-iclb}: DMESG-FAIL (fdo#107724) -> PASS +6
igt@kms_plane@plane-panning-bottom-right-pipe-a-planes:
shard-skl: FAIL (fdo#103166) -> PASS
igt@kms_plane@plane-position-covered-pipe-a-planes:
shard-glk: FAIL (fdo#103166) -> PASS
shard-apl: FAIL (fdo#103166) -> PASS
igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
{shard-iclb}: FAIL (fdo#103166) -> PASS +1
igt@kms_rotation_crc@primary-rotation-180:
{shard-iclb}: DMESG-WARN (fdo#107724, fdo#108336) -> PASS +10
igt@kms_sequence@get-busy:
{shard-iclb}: DMESG-WARN (fdo#107724) -> PASS +9
[Intel-gfx] [PATCH] drm/i915: Show waiter's status on engine dump
When showing the list of waiters, include the task's status so that we
can tell if they have been woken up and are waiting for the CPU, or if
they are still waiting to be woken.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 885a901b6e13..f6554d5eb1cf 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1562,8 +1562,10 @@ void intel_engine_dump(struct intel_engine_cs *engine,
for (rb = rb_first(>waiters); rb; rb = rb_next(rb)) {
struct intel_wait *w = rb_entry(rb, typeof(*w), node);
- drm_printf(m, "\t%s [%d] waiting for %x\n",
- w->tsk->comm, w->tsk->pid, w->seqno);
+ drm_printf(m, "\t%s [%d] (state:%lx, %s) waiting for %x\n",
+ w->tsk->comm, w->tsk->pid, w->tsk->state,
+ w->tsk->state & TASK_NORMAL ? "asleep" : "runnable",
+ w->seqno);
}
spin_unlock(>rb_lock);
local_irq_restore(flags);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Poison the CSB after use
Quoting Chris Wilson (2018-11-21 13:08:23) > After reading the event status from the CSB, write back 0 (an invalid > value) so we can detect if the HW should signal a new event without > writing the event in the future. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108315 > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala Wrong branch, ignore this. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Poison the CSB after use
After reading the event status from the CSB, write back 0 (an invalid value) so we can detect if the HW should signal a new event without writing the event in the future. References: https://bugs.freedesktop.org/show_bug.cgi?id=108315 Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 2fad093d644d..38a6c39ca957 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1222,6 +1222,9 @@ static void process_csb(struct intel_engine_cs *engine) execlists->active); status = buf[2 * head]; + GEM_BUG_ON(!status); + GEM_DEBUG_EXEC(WRITE_ONCE(*(u32 *)(buf + 2 * head), 0)); + if (status & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED)) execlists_set_active(execlists, -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/backlight: Fix backlight takeover on LPT
Am Mi., 21. Nov. 2018 um 11:45 Uhr schrieb Ville Syrjälä
:
>
> On Wed, Nov 21, 2018 at 08:16:06AM +0100, Tolga Cakir wrote:
> > Am Di., 20. Nov. 2018 um 19:51 Uhr schrieb Ville Syrjälä
> > :
> > >
> > > On Tue, Nov 20, 2018 at 11:39:26AM +0100, Maarten Lankhorst wrote:
> > > > On lynxpoint the bios sometimes sets up the backlight using the CPU
> > > > display, but the driver expects using the PWM PCH override register.
> > > >
> > > > Read the value from the CPU register, then convert it to the other
> > > > units by converting from the old duty cycle, to freq, to the new units.
> > > >
> > > > This value is then programmed in the override register, after which
> > > > we set the override and disable the CPU display control. This allows
> > > > us to switch the source without flickering, and make the backlight
> > > > controls work in the driver.
> > > >
> > > > Signed-off-by: Maarten Lankhorst
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108225
> > > > Cc: Basil Eric Rabi
> > > > Cc: Hans de Goede
> > > > Cc: Tolga Cakir
> > > > Tested-by: Tolga Cakir
> > > > ---
> > > > drivers/gpu/drm/i915/intel_panel.c | 34 +++---
> > > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > > b/drivers/gpu/drm/i915/intel_panel.c
> > > > index e6cd7b55c018..3357232f1b0e 100644
> > > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > > @@ -1485,7 +1485,7 @@ static int lpt_setup_backlight(struct
> > > > intel_connector *connector, enum pipe unus
> > > > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > > struct intel_panel *panel = >panel;
> > > > u32 pch_ctl1, pch_ctl2, val;
> > > > - bool alt;
> > > > + bool alt, cpu_mode = false;
> > > >
> > > > if (HAS_PCH_LPT(dev_priv))
> > > > alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> > > > @@ -1507,12 +1507,40 @@ static int lpt_setup_backlight(struct
> > > > intel_connector *connector, enum pipe unus
> > > >
> > > > panel->backlight.min = get_backlight_min_vbt(connector);
> > > >
> > > > - val = lpt_get_backlight(connector);
> > > > + panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> > > > + if (panel->backlight.enabled && HAS_PCH_LPT(dev_priv) &&
> > > > + (I915_READ(BLC_PWM_CPU_CTL2) & BLM_PWM_ENABLE) &&
> > > > + !WARN_ON(pch_ctl1 & BLM_PCH_OVERRIDE_ENABLE)) {
> > > > + u32 freq;
> > > > +
> > > > + cpu_mode = true;
> > > > + /*
> > > > + * We're in cpu mode, convert to PCH units.
> > > > + *
> > > > + * Convert CPU pwm tick back to hz, back to new PCH units
> > > > again.
> > > > + * this is the same formula as pch_hz_to_pwm, but the
> > > > other way
> > > > + * around..
> > > > + */
> > > > + val = pch_get_backlight(connector);
> > > > + freq = DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), val
> > > > * 128);
> > >
> > > The docs are telling me that HSW/BDW use cdclk for the CPU backlight,
> > > and the increment is configurable as well.
> > >
> > > Also what about S4 resume? Don't we need this trick there as well?
> > >
> >
> > Hi,
> >
> > I couldn't test this patch for S4 resume on my Dell M3800 laptop (Core
> > i7-4702HQ, Lynx Point), as fastboot=1 doesn't work for S4 resume, only
> > normal boot. Therefore, there are no issues on S4 wake after
> > hibernate. Backlight controls etc. work as expected; just like
> > fastboot=0.
>
> I think fastboot should work the same for s4 resume as boot, but
> only if your boot kernel doesn't load i915.ko. That way the
> resuming kernel will directly take over from the BIOS programmed
> display configuration. OTOH if the boot kernel loads i915 then
> it will shut down all displays before handing control over to
> the resuming kernel.
>
You're right, fastboot=1 worked for S4 resume, it was GNOME doing the
modeset after S4 resume for whatever reason. I have disabled GNOME for
further testing. Just hibernated from console and S4 resumed back to
console: no flickering. As you already suspected, backlight controls
didn't work, eventhough they worked on normal boot with fastboot=1.
So, this patch also needs to be applied to S4 resume, as you said.
Good catch!
I'm ready to test as soon as the patches are ready.
> >
> > I have applied "[1/2] drm/i915: Enable fastset for non-boot modesets"
> > by Maarten, but that doesn't give me fastboot for S4 resume aswell.
> > Same behavior as unpatched on my system.
> >
> > Please let me know, when there is more I can test.
> >
> > Cheers,
> > Tolga
> >
> > > > +
> > > > + val = lpt_hz_to_pwm(connector, freq);
> > > > + } else
> > > > + val = lpt_get_backlight(connector);
> > > > val = intel_panel_compute_brightness(connector, val);
> > > >
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout
Quoting Patchwork (2018-11-21 12:33:00) > == Series Details == > > Series: drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout > URL : https://patchwork.freedesktop.org/series/52820/ > State : success > > == Summary == > > = CI Bug Log - changes from CI_DRM_5180 -> Patchwork_10876 = > > == Summary - SUCCESS == > > No regressions found. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/52820/revisions/1/mbox/ > > == Known issues == > > Here are the changes found in Patchwork_10876 that come from known issues: > > === IGT changes === > > Issues hit > > igt@gem_ctx_create@basic-files: > fi-icl-u2: PASS -> DMESG-WARN (fdo#107724) > fi-bsw-kefka: PASS -> INCOMPLETE (fdo#108714) > > igt@i915_selftest@live_coherency: > fi-gdg-551: NOTRUN -> DMESG-FAIL (fdo#107164) > > igt@i915_selftest@live_hangcheck: > fi-bwr-2160:PASS -> DMESG-FAIL (fdo#108735) Worrying proved right. Switching to 100ms isn't enough. <0> [311.332381] igt/evic-22020 311291205us : reset_ring: rcs0 request global=1326, current=1325 <0> [311.332524] kworker/-165 1 311394694us : __igt_wedge_me: __igt_reset_evict_vma timed out. 100ms elapsed. Why didn't you wake up? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
Quoting Hans Holmberg (2018-11-21 13:35:19) > On Wed, Nov 21, 2018 at 11:10 AM Joonas Lahtinen > wrote: > > > > Quoting Hans Holmberg (2018-11-21 11:54:23) > > > From: Hans Holmberg > > > > > > There is no need to rebuild i915_gpu_error.o when the version string > > > changes as the version is available in init_utsname()->release. > > > > > > Signed-off-by: Hans Holmberg > > > > Seems reasonable to me. > > > > Reviewed-by: Joonas Lahtinen > > > > Out of curiosity, are you by any chance hashing the i915_gpu_error.o > > file (or the contents elsewhere) for some purpose? > > Oh no, I was just moderately annoyed by the file being rebuilt every > time the version was updated(I use my current branch name as > LOCALVERSION when building). That's a reasonable explanation, too :) I unblocked the message from moderation queue so that our CI picks this up for testing. I will then proceed to merge this once the results are back. Thanks for the patch! Regards, Joonas > > Thanks, > Hans > > > > Regards, Joonas > > > > > --- > > > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > > > b/drivers/gpu/drm/i915/i915_gpu_error.c > > > index 8762d17b6659..958e1484a3dd 100644 > > > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > > > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > > > @@ -27,7 +27,7 @@ > > > * > > > */ > > > > > > -#include > > > +#include > > > #include > > > #include > > > #include > > > @@ -650,7 +650,7 @@ int i915_error_state_to_str(struct > > > drm_i915_error_state_buf *m, > > > > > > if (*error->error_msg) > > > err_printf(m, "%s\n", error->error_msg); > > > - err_printf(m, "Kernel: " UTS_RELEASE "\n"); > > > + err_printf(m, "Kernel: %s\n", init_utsname()->release); > > > ts = ktime_to_timespec64(error->time); > > > err_printf(m, "Time: %lld s %ld us\n", > > >(s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC); > > > -- > > > 2.17.1 > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout
Quoting Mika Kuoppala (2018-11-21 12:26:23) > Chris Wilson writes: > > > Make the wait for the evict kthread use an explicit timeout rather than > > a handwaved jiffie value so it is consistent across all platforms. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735 > > Signed-off-by: Chris Wilson > > Reviewed-by: Mika Kuoppala > > ...there is one left in intel_workarounds.c Fortunately, we haven't yet exceeded it. HZ/5 should be pretty stable, worst case is 20 jiffies. Even HZ/10 at 10 jiffies shouldn't be much of a problem, just worrying about why the kthread didn't wake up. Maybe I should just bump its prio. -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 drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout
== Series Details ==
Series: drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout
URL : https://patchwork.freedesktop.org/series/52820/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5180 -> Patchwork_10876 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/52820/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10876 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_ctx_create@basic-files:
fi-icl-u2: PASS -> DMESG-WARN (fdo#107724)
fi-bsw-kefka: PASS -> INCOMPLETE (fdo#108714)
igt@i915_selftest@live_coherency:
fi-gdg-551: NOTRUN -> DMESG-FAIL (fdo#107164)
igt@i915_selftest@live_hangcheck:
fi-bwr-2160:PASS -> DMESG-FAIL (fdo#108735)
igt@kms_pipe_crc_basic@read-crc-pipe-b:
fi-byt-clapper: PASS -> FAIL (fdo#107362)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) +1
{igt@runner@aborted}:
{fi-icl-y}: NOTRUN -> FAIL (fdo#108070)
Possible fixes
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS +2
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
fdo#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724
fdo#108070 https://bugs.freedesktop.org/show_bug.cgi?id=108070
fdo#108714 https://bugs.freedesktop.org/show_bug.cgi?id=108714
fdo#108735 https://bugs.freedesktop.org/show_bug.cgi?id=108735
== Participating hosts (50 -> 45) ==
Additional (2): fi-icl-y fi-gdg-551
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-u3
== Build changes ==
* Linux: CI_DRM_5180 -> Patchwork_10876
CI_DRM_5180: 95de9a943571204eda4dc3156c3d984ba07c78e4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4723: 53bb24ad410b53cdd96f15ced8fd5921c8ab0eac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10876: ce745cbd4d6a0e3141219c2ffa73395ad57e4084 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ce745cbd4d6a drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms
timeout
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10876/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
From: Hans Holmberg There is no need to rebuild i915_gpu_error.o when the version string changes as the version is available in init_utsname()->release. Signed-off-by: Hans Holmberg --- drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 8762d17b6659..958e1484a3dd 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -27,7 +27,7 @@ * */ -#include +#include #include #include #include @@ -650,7 +650,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf *m, if (*error->error_msg) err_printf(m, "%s\n", error->error_msg); - err_printf(m, "Kernel: " UTS_RELEASE "\n"); + err_printf(m, "Kernel: %s\n", init_utsname()->release); ts = ktime_to_timespec64(error->time); err_printf(m, "Time: %lld s %ld us\n", (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
On Wed, Nov 21, 2018 at 11:10 AM Joonas Lahtinen wrote: > > Quoting Hans Holmberg (2018-11-21 11:54:23) > > From: Hans Holmberg > > > > There is no need to rebuild i915_gpu_error.o when the version string > > changes as the version is available in init_utsname()->release. > > > > Signed-off-by: Hans Holmberg > > Seems reasonable to me. > > Reviewed-by: Joonas Lahtinen > > Out of curiosity, are you by any chance hashing the i915_gpu_error.o > file (or the contents elsewhere) for some purpose? Oh no, I was just moderately annoyed by the file being rebuilt every time the version was updated(I use my current branch name as LOCALVERSION when building). Thanks, Hans > > Regards, Joonas > > > --- > > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > > b/drivers/gpu/drm/i915/i915_gpu_error.c > > index 8762d17b6659..958e1484a3dd 100644 > > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > > @@ -27,7 +27,7 @@ > > * > > */ > > > > -#include > > +#include > > #include > > #include > > #include > > @@ -650,7 +650,7 @@ int i915_error_state_to_str(struct > > drm_i915_error_state_buf *m, > > > > if (*error->error_msg) > > err_printf(m, "%s\n", error->error_msg); > > - err_printf(m, "Kernel: " UTS_RELEASE "\n"); > > + err_printf(m, "Kernel: %s\n", init_utsname()->release); > > ts = ktime_to_timespec64(error->time); > > err_printf(m, "Time: %lld s %ld us\n", > >(s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC); > > -- > > 2.17.1 > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/backlight: Fix backlight takeover on LPT
Am Di., 20. Nov. 2018 um 19:51 Uhr schrieb Ville Syrjälä
:
>
> On Tue, Nov 20, 2018 at 11:39:26AM +0100, Maarten Lankhorst wrote:
> > On lynxpoint the bios sometimes sets up the backlight using the CPU
> > display, but the driver expects using the PWM PCH override register.
> >
> > Read the value from the CPU register, then convert it to the other
> > units by converting from the old duty cycle, to freq, to the new units.
> >
> > This value is then programmed in the override register, after which
> > we set the override and disable the CPU display control. This allows
> > us to switch the source without flickering, and make the backlight
> > controls work in the driver.
> >
> > Signed-off-by: Maarten Lankhorst
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108225
> > Cc: Basil Eric Rabi
> > Cc: Hans de Goede
> > Cc: Tolga Cakir
> > Tested-by: Tolga Cakir
> > ---
> > drivers/gpu/drm/i915/intel_panel.c | 34 +++---
> > 1 file changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index e6cd7b55c018..3357232f1b0e 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -1485,7 +1485,7 @@ static int lpt_setup_backlight(struct intel_connector
> > *connector, enum pipe unus
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > struct intel_panel *panel = >panel;
> > u32 pch_ctl1, pch_ctl2, val;
> > - bool alt;
> > + bool alt, cpu_mode = false;
> >
> > if (HAS_PCH_LPT(dev_priv))
> > alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> > @@ -1507,12 +1507,40 @@ static int lpt_setup_backlight(struct
> > intel_connector *connector, enum pipe unus
> >
> > panel->backlight.min = get_backlight_min_vbt(connector);
> >
> > - val = lpt_get_backlight(connector);
> > + panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> > + if (panel->backlight.enabled && HAS_PCH_LPT(dev_priv) &&
> > + (I915_READ(BLC_PWM_CPU_CTL2) & BLM_PWM_ENABLE) &&
> > + !WARN_ON(pch_ctl1 & BLM_PCH_OVERRIDE_ENABLE)) {
> > + u32 freq;
> > +
> > + cpu_mode = true;
> > + /*
> > + * We're in cpu mode, convert to PCH units.
> > + *
> > + * Convert CPU pwm tick back to hz, back to new PCH units
> > again.
> > + * this is the same formula as pch_hz_to_pwm, but the other
> > way
> > + * around..
> > + */
> > + val = pch_get_backlight(connector);
> > + freq = DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), val *
> > 128);
>
> The docs are telling me that HSW/BDW use cdclk for the CPU backlight,
> and the increment is configurable as well.
>
> Also what about S4 resume? Don't we need this trick there as well?
>
Hi,
I couldn't test this patch for S4 resume on my Dell M3800 laptop (Core
i7-4702HQ, Lynx Point), as fastboot=1 doesn't work for S4 resume, only
normal boot. Therefore, there are no issues on S4 wake after
hibernate. Backlight controls etc. work as expected; just like
fastboot=0.
I have applied "[1/2] drm/i915: Enable fastset for non-boot modesets"
by Maarten, but that doesn't give me fastboot for S4 resume aswell.
Same behavior as unpatched on my system.
Please let me know, when there is more I can test.
Cheers,
Tolga
> > +
> > + val = lpt_hz_to_pwm(connector, freq);
> > + } else
> > + val = lpt_get_backlight(connector);
> > val = intel_panel_compute_brightness(connector, val);
> > panel->backlight.level = clamp(val, panel->backlight.min,
> > panel->backlight.max);
> >
> > - panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> > + if (cpu_mode) {
> > + u32 tmp;
> > +
> > + /* Use PWM mode, instead of cpu clock */
> > + lpt_set_backlight(connector->base.state,
> > panel->backlight.level);
> > + I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1 |
> > BLM_PCH_OVERRIDE_ENABLE);
> > +
> > + tmp = I915_READ(BLC_PWM_CPU_CTL2);
> > + I915_WRITE(BLC_PWM_CPU_CTL2, tmp & ~BLM_PWM_ENABLE);
> > + }
> >
> > return 0;
> > }
> > --
> > 2.19.1
> >
> > ___
> > 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] [PATCH] drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout
Chris Wilson writes: > Make the wait for the evict kthread use an explicit timeout rather than > a handwaved jiffie value so it is consistent across all platforms. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735 > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala ...there is one left in intel_workarounds.c -Mika > --- > drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c > b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c > index defe671130ab..1f76257641f2 100644 > --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c > +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c > @@ -1171,7 +1171,7 @@ static int __igt_reset_evict_vma(struct > drm_i915_private *i915, > struct igt_wedge_me w; > > /* The reset, even indirectly, should take less than 10ms. */ > - igt_wedge_on_timeout(, i915, HZ / 10 /* 100ms timeout*/) > + igt_wedge_on_timeout(, i915, msecs_to_jiffies(100)) > err = kthread_stop(tsk); > > put_task_struct(tsk); > -- > 2.19.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4.20 regression fix] drm/i915: Revert "Fix assert_plane() warning on bootup with external display"
On Mon, Nov 19, 2018 at 11:35:00PM +0100, Hans de Goede wrote:
> Starting with 4.20-rc1 I'm seeing the LCD screen briefly turn mostly purple
> on devices with a DSI panel (seen on 2 different devices with a DSI panel).
>
> This happens both with and without fastboot=1. This is caused by
> commit 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with
> external display").
>
> And a user commenting on fdo bug 108225 has reported a flicker caused by
> the screen briefly turning blank when booting with fastboot=1, which goes
> away when reverting this commit.
>
> I believe a revert of the offending commit is the best solution because
> the commit introduces a drm_atomic_commit() call in the drivers' probe
> path, causing writes to the hardware during probe.
> I believe this goes agains the design of the driver which is to only
> read-back state on probe and only write to the hardware on the first
> commit from the fbcon or userspace.
>
> Instead the assert_plane() problem the commit tried to fix should be fixed
> by fixing the state read-back code.
>
> Related: https://bugs.freedesktop.org/show_bug.cgi?id=108225
> Cc: Azhar Shaikh
> Cc: Ville Syrjälä
> Signed-off-by: Hans de Goede
Fixed with https://patchwork.freedesktop.org/series/52754/
> ---
> drivers/gpu/drm/i915/intel_display.c | 61 +---
> 1 file changed, 2 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2107de6da692..03dec1c05652 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15193,61 +15193,12 @@ static void intel_update_fdi_pll_freq(struct
> drm_i915_private *dev_priv)
> DRM_DEBUG_DRIVER("FDI PLL freq=%d\n", dev_priv->fdi_pll_freq);
> }
>
> -static int intel_initial_commit(struct drm_device *dev)
> -{
> - struct drm_atomic_state *state = NULL;
> - struct drm_modeset_acquire_ctx ctx;
> - struct drm_crtc *crtc;
> - struct drm_crtc_state *crtc_state;
> - int ret = 0;
> -
> - state = drm_atomic_state_alloc(dev);
> - if (!state)
> - return -ENOMEM;
> -
> - drm_modeset_acquire_init(, 0);
> -
> -retry:
> - state->acquire_ctx =
> -
> - drm_for_each_crtc(crtc, dev) {
> - crtc_state = drm_atomic_get_crtc_state(state, crtc);
> - if (IS_ERR(crtc_state)) {
> - ret = PTR_ERR(crtc_state);
> - goto out;
> - }
> -
> - if (crtc_state->active) {
> - ret = drm_atomic_add_affected_planes(state, crtc);
> - if (ret)
> - goto out;
> - }
> - }
> -
> - ret = drm_atomic_commit(state);
> -
> -out:
> - if (ret == -EDEADLK) {
> - drm_atomic_state_clear(state);
> - drm_modeset_backoff();
> - goto retry;
> - }
> -
> - drm_atomic_state_put(state);
> -
> - drm_modeset_drop_locks();
> - drm_modeset_acquire_fini();
> -
> - return ret;
> -}
> -
> int intel_modeset_init(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct i915_ggtt *ggtt = _priv->ggtt;
> enum pipe pipe;
> struct intel_crtc *crtc;
> - int ret;
>
> dev_priv->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
>
> @@ -15319,6 +15270,8 @@ int intel_modeset_init(struct drm_device *dev)
> INTEL_INFO(dev_priv)->num_pipes > 1 ? "s" : "");
>
> for_each_pipe(dev_priv, pipe) {
> + int ret;
> +
> ret = intel_crtc_init(dev_priv, pipe);
> if (ret) {
> drm_mode_config_cleanup(dev);
> @@ -15374,16 +15327,6 @@ int intel_modeset_init(struct drm_device *dev)
> if (!HAS_GMCH_DISPLAY(dev_priv))
> sanitize_watermarks(dev);
>
> - /*
> - * Force all active planes to recompute their states. So that on
> - * mode_setcrtc after probe, all the intel_plane_state variables
> - * are already calculated and there is no assert_plane warnings
> - * during bootup.
> - */
> - ret = intel_initial_commit(dev);
> - if (ret)
> - DRM_DEBUG_KMS("Initial commit in probe failed.\n");
> -
> return 0;
> }
>
> --
> 2.19.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add rotation readout for plane initial config
On Tue, Nov 20, 2018 at 02:20:14PM -0800, Rodrigo Vivi wrote:
> On Tue, Nov 20, 2018 at 03:54:50PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > If we need to force a full plane update before userspace/fbdev
> > have given us a proper plane state we should try to maintain the
> > current plane state as much as possible (apart from the parts
> > of the state we're trying to fix up with the plane update).
> > To that end add basic readout for the plane rotation and
> > maintain it during the initial fb takeover.
> >
> > Cc: Hans de Goede
> > Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with
> > external display")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 27 +++
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > 2 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 60c1e54285c1..4d339f54559c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2831,6 +2831,7 @@ intel_find_initial_plane_obj(struct intel_crtc
> > *intel_crtc,
> > return;
> >
> > valid_fb:
> > + intel_state->base.rotation = plane_config->rotation;
> > intel_fill_fb_ggtt_view(_state->view, fb,
> > intel_state->base.rotation);
> > intel_state->color_plane[0].stride =
> > @@ -7787,8 +7788,15 @@ i9xx_get_initial_plane_config(struct intel_crtc
> > *crtc,
> > plane_config->tiling = I915_TILING_X;
> > fb->modifier = I915_FORMAT_MOD_X_TILED;
> > }
> > +
> > + if (val & DISPPLANE_ROTATE_180)
> > + plane_config->rotation = DRM_MODE_ROTATE_180;
> > }
> >
> > + if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B &&
> > + val & DISPPLANE_MIRROR)
> > + plane_config->rotation |= DRM_MODE_REFLECT_X;
> > +
> > pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
> > fourcc = i9xx_format_to_fourcc(pixel_format);
> > fb->format = drm_format_info(fourcc);
> > @@ -8898,6 +8906,25 @@ skylake_get_initial_plane_config(struct intel_crtc
> > *crtc,
> > goto error;
> > }
> >
> > + switch (val & PLANE_CTL_ROTATE_MASK) {
> > + case PLANE_CTL_ROTATE_0:
> > + plane_config->rotation = DRM_MODE_ROTATE_0;
> > + break;
> > + case PLANE_CTL_ROTATE_90:
> > + plane_config->rotation = DRM_MODE_ROTATE_270;
>
> we should add that comment that DRM_MODE_ROTATE_ is counter clockwise
> to avoid later confusion.
I copied over the comment from the other place, and pushed the series
to dinq. Thanks for the reviews, testing, and tracking down the bug
initially.
>
> Also I wonder if we shouldn't move all the cases to a unique
> map function.
>
> Anyways,
>
>
> Reviewed-by: Rodrigo Vivi
>
>
>
> > + break;
> > + case PLANE_CTL_ROTATE_180:
> > + plane_config->rotation = DRM_MODE_ROTATE_180;
> > + break;
> > + case PLANE_CTL_ROTATE_270:
> > + plane_config->rotation = DRM_MODE_ROTATE_90;
> > + break;
> > + }
> > +
> > + if (INTEL_GEN(dev_priv) >= 10 &&
> > + val & PLANE_CTL_FLIP_HORIZONTAL)
> > + plane_config->rotation |= DRM_MODE_REFLECT_X;
> > +
> > base = I915_READ(PLANE_SURF(pipe, plane_id)) & 0xf000;
> > plane_config->base = base;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index f575ba2a59da..a7d9ac912125 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -572,6 +572,7 @@ struct intel_initial_plane_config {
> > unsigned int tiling;
> > int size;
> > u32 base;
> > + u8 rotation;
> > };
> >
> > #define SKL_MIN_SRC_W 8
> > --
> > 2.18.1
> >
> > ___
> > 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: failure for drm/i915: Synchronize hpd work in i915_hpd_storm_ctl_show()
== Series Details ==
Series: drm/i915: Synchronize hpd work in i915_hpd_storm_ctl_show()
URL : https://patchwork.freedesktop.org/series/52796/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5175_full -> Patchwork_10872_full =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10872_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10872_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_10872_full:
=== IGT changes ===
Possible regressions
igt@drm_import_export@import-close-race-flink:
shard-glk: PASS -> TIMEOUT
Warnings
igt@tools_test@sysfs_l3_parity:
shard-hsw: SKIP -> PASS
igt@tools_test@tools_test:
{shard-iclb}: SKIP -> PASS
== Known issues ==
Here are the changes found in Patchwork_10872_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@gem_exec_schedule@pi-ringfull-bsd:
shard-skl: NOTRUN -> FAIL (fdo#103158)
igt@gem_exec_whisper@normal:
shard-skl: PASS -> TIMEOUT (fdo#108592)
igt@gem_userptr_blits@readonly-unsync:
shard-skl: NOTRUN -> INCOMPLETE (fdo#108074)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +3
igt@kms_cursor_crc@cursor-64x64-random:
shard-glk: PASS -> FAIL (fdo#103232) +1
igt@kms_cursor_legacy@cursora-vs-flipa-toggle:
shard-glk: PASS -> DMESG-WARN (fdo#105763, fdo#106538)
igt@kms_draw_crc@draw-method-rgb565-blt-ytiled:
shard-glk: PASS -> FAIL (fdo#103184)
igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-ytiled:
shard-skl: PASS -> FAIL (fdo#103184)
igt@kms_flip_tiling@flip-to-y-tiled:
shard-skl: PASS -> FAIL (fdo#107931)
igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
shard-skl: PASS -> FAIL (fdo#105682) +3
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
shard-apl: PASS -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
shard-glk: PASS -> FAIL (fdo#103167) +6
igt@kms_frontbuffer_tracking@fbc-farfromfence:
{shard-iclb}: PASS -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
shard-skl: NOTRUN -> FAIL (fdo#105683)
igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-gtt:
shard-skl: PASS -> FAIL (fdo#103167)
igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
shard-skl: NOTRUN -> FAIL (fdo#108145) +1
igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
shard-apl: PASS -> FAIL (fdo#103166) +1
igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format:
{shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107724)
igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format:
{shard-iclb}: PASS -> DMESG-WARN (fdo#107724) +1
igt@kms_setmode@basic:
shard-hsw: PASS -> FAIL (fdo#99912)
shard-kbl: PASS -> FAIL (fdo#99912)
igt@perf@polling:
shard-hsw: PASS -> FAIL (fdo#102252)
igt@pm_rpm@reg-read-ioctl:
shard-skl: NOTRUN -> INCOMPLETE (fdo#107807)
{igt@runner@aborted}:
shard-hsw: NOTRUN -> FAIL (fdo#108770)
Possible fixes
igt@drm_import_export@import-close-race-flink:
shard-skl: TIMEOUT (fdo#108667) -> PASS
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-kbl: INCOMPLETE (fdo#106887, fdo#106023, fdo#103665) ->
PASS
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
shard-kbl: DMESG-WARN (fdo#107956) -> PASS
igt@kms_chv_cursor_fail@pipe-b-256x256-right-edge:
shard-skl: FAIL (fdo#104671) -> PASS
igt@kms_color@pipe-c-ctm-0-75:
shard-skl: FAIL (fdo#108682) -> PASS
igt@kms_cursor_crc@cursor-128x128-suspend:
shard-glk: FAIL (fdo#103232) -> PASS +3
igt@kms_draw_crc@draw-method-xrgb-render-ytiled:
{shard-iclb}: WARN (fdo#108336) -> PASS +2
igt@kms_flip@plain-flip-fb-recreate-interruptible:
shard-skl: FAIL (fdo#100368) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
{shard-iclb}: FAIL (fdo#103167) -> PASS
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
shard-glk: FAIL (fdo#103167) -> PASS +1
igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
{shard-iclb}: DMESG-FAIL (fdo#107724) -> PASS +6
[Intel-gfx] [PATCH] drm/i915/selftests: Use msecs_to_jiffies() for an explicit ms timeout
Make the wait for the evict kthread use an explicit timeout rather than a handwaved jiffie value so it is consistent across all platforms. References: https://bugs.freedesktop.org/show_bug.cgi?id=108735 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c index defe671130ab..1f76257641f2 100644 --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c @@ -1171,7 +1171,7 @@ static int __igt_reset_evict_vma(struct drm_i915_private *i915, struct igt_wedge_me w; /* The reset, even indirectly, should take less than 10ms. */ - igt_wedge_on_timeout(, i915, HZ / 10 /* 100ms timeout*/) + igt_wedge_on_timeout(, i915, msecs_to_jiffies(100)) err = kthread_stop(tsk); put_task_struct(tsk); -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220
Hi! > > My machine locked hard (thinkpad x220). After reboot, I found this in > > syslog: > > > > Sounds like memory corruption..? Does not sound like easy to debug. > > Were you doing something GPU intense when you experienced the hard hang? > > And if so, have you been able to hit the issue more than once? At this > point it doesn't look like anything we've hit previously, so would be > great to have some more insight into how we could reproduce. I seen another crash since that, but I don't think it counts at "easily reproducible". I may have been running flightgear at that point. That's fairly GPU intensive. > There's one similar for nouveau in Bugzilla, but it seems like a genuine > memory corruption (1 bit flipped): > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > Any extra information would be of use :) > > Regards, Joonas > > PS. Could you open a bug to Bugzilla, it'll help to collect the > information in one consolidated place: > > https://01.org/linuxgraphics/documentation/how-report-bugs I prefer email... certainly for bugs that can't be reproduced. Best regards, Pavel > > > > ...otoh, it still looks like an addres, so maybe it is "just" race in > > GPU drivers? > > > > Any ideas? > > Pavel > > > > Nov 8 18:35:01 duo CRON[28511]: (root) CMD (command -v debian-sa1 > > > /dev/null && debian-sa > > 1 1 1) > > Nov 8 18:42:57 duo kernel: list_del corruption. prev->next should be > > 8801742b8178, but > > was c9000192fec8 > > Nov 8 18:42:57 duo kernel: [ cut here ] > > Nov 8 18:42:57 duo kernel: kernel BUG at > > /data/fast/l/k/lib/list_debug.c:53! > > Nov 8 18:42:57 duo kernel: invalid opcode: [#1] SMP PTI > > Nov 8 18:42:57 duo kernel: CPU: 2 PID: 1082 Comm: i915/signal:1 Not > > tainted 4.20.0-rc1+ #3 > > Nov 8 18:42:57 duo kernel: Hardware name: LENOVO 42872WU/42872WU, > > BIOS 8DET74WW (1.44 ) 03 > > /13/2018 > > Nov 8 18:42:57 duo kernel: RIP: > > 0010:__list_del_entry_valid+0x8e/0x90 > > Nov 8 18:42:57 duo kernel: Code: 66 88 d1 ff 0f 0b 48 89 fe 31 c0 48 > > c7 c7 90 74 5e 85 e8 > > 53 88 d1 ff 0f 0b 48 89 fe 31 c0 48 c7 c7 c8 74 5e 85 e8 40 88 d1 ff > > <0f> 0b 55 48 89 d0 48 > > 8b 52 08 48 89 e5 48 39 f2 75 19 48 8b 32 48 > > Nov 8 18:42:57 duo kernel: RSP: :c9000196be78 EFLAGS: > > 00210086 > > Nov 8 18:42:57 duo kernel: RAX: 0054 RBX: > > 8801742b8178 RCX: 00 > > 00 > > Nov 8 18:42:57 duo kernel: RDX: RSI: > > 88019e2a53d8 RDI: 88019e2a53 > > d8 > > Nov 8 18:42:57 duo kernel: RBP: c9000196be78 R08: > > 880196e2cd10 R09: 00 > > 00 > > Nov 8 18:42:57 duo kernel: R10: e7684eb9 R11: > > 3863656632393101 R12: c9000196be > > c8 > > Nov 8 18:42:57 duo kernel: R13: 88019707e000 R14: > > 8801742b8080 R15: c9000192fd > > d0 > > Nov 8 18:42:57 duo kernel: FS: () > > GS:88019e28() knlGS:000 > > 0 > > Nov 8 18:42:57 duo kernel: CS: 0010 DS: ES: CR0: > > 80050033 > > Nov 8 18:42:57 duo kernel: CR2: ed2bf000 CR3: > > 0581e001 CR4: 000606a0 > > Nov 8 18:42:57 duo kernel: Call Trace: > > Nov 8 18:42:57 duo kernel: intel_breadcrumbs_signaler+0x162/0x330 > > Nov 8 18:42:57 duo kernel: kthread+0x116/0x150 > > Nov 8 18:42:57 duo kernel: ? intel_engine_wakeup+0x40/0x40 > > Nov 8 18:42:57 duo kernel: ? kthread_park+0x90/0x90 > > Nov 8 18:42:57 duo kernel: ret_from_fork+0x35/0x40 > > Nov 8 18:42:57 duo kernel: Modules linked in: > > Nov 8 18:42:57 duo kernel: ---[ end trace 2f8da183a56f80f6 ]--- > > Nov 8 18:42:57 duo kernel: RIP: > > 0010:__list_del_entry_valid+0x8e/0x90 > > Nov 8 18:42:57 duo kernel: Code: 66 88 d1 ff 0f 0b 48 89 fe 31 c0 > > 48 c7 c7 90 74 5e 85 e8 53 88 d1 ff 0f 0b 48 89 fe 31 c0 48 c7 c7 c8 > > 74 5e 85 e8 40 88 d1 ff <0f> 0b 55 48 89 d0 48 8b 52 08 48 89 e5 48 > > 39 f2 75 19 48 8b 32 48 > > Nov 8 18:42:57 duo kernel: RSP: :c9000196be78 EFLAGS: > > 00210086 > > Nov 8 18:42:57 duo kernel: RAX: 0054 RBX: > > 8801742b8178 RCX: > > Nov 8 18:42:57 duo kernel: RDX: RSI: > > 88019e2a53d8 RDI: 88019e2a53d8 > > Nov 8 18:42:57 duo kernel: RBP: c9000196be78 R08: > > 880196e2cd10 R09: > > Nov 8 18:42:57 duo kernel: R10: e7684eb9 R11: > > 3863656632393101 R12: c9000196bec8 > > Nov 8 18:42:57 duo kernel: R13: 88019707e000 R14: > > 8801742b8080 R15: c9000192fdd0 > > Nov 8 18:42:57 duo kernel: FS: () > > GS:88019e28() knlGS: > > Nov 8 18:42:57 duo kernel: CS: 0010 DS: ES: CR0: > > 80050033
Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> On Tue, 20 Nov 2018, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier for drivers by simply passing the connector
> > to drm_hdmi_avi_infoframe_from_display_mode() and
> > drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
> > need to worry about is_hdmi2_sink mess.
>
> Overall looks about right and nice,
>
> Reviewed-by: Jani Nikula
>
> But please do take that with a grain of salt for everything outside of
> i915 and drm core.
>
> Please also find a few comments inline below.
>
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: "David (ChunMing) Zhou"
> > Cc: Archit Taneja
> > Cc: Andrzej Hajda
> > Cc: Laurent Pinchart
> > Cc: Inki Dae
> > Cc: Joonyoung Shim
> > Cc: Seung-Woo Kim
> > Cc: Kyungmin Park
> > Cc: Russell King
> > Cc: CK Hu
> > Cc: Philipp Zabel
> > Cc: Rob Clark
> > Cc: Ben Skeggs
> > Cc: Tomi Valkeinen
> > Cc: Sandy Huang
> > Cc: "Heiko Stübner"
> > Cc: Benjamin Gaignard
> > Cc: Vincent Abriou
> > Cc: Thierry Reding
> > Cc: Eric Anholt
> > Cc: Shawn Guo
> > Cc: Ilia Mirkin
> > Cc: amd-...@lists.freedesktop.org
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: freedr...@lists.freedesktop.org
> > Cc: nouv...@lists.freedesktop.org
> > Cc: linux-te...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++-
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++--
> > drivers/gpu/drm/bridge/sii902x.c | 3 ++-
> > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +--
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
> > drivers/gpu/drm/drm_edid.c| 33 ++-
> > drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++-
> > drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++-
> > drivers/gpu/drm/i915/intel_hdmi.c | 14 +-
> > drivers/gpu/drm/i915/intel_lspcon.c | 15 ++-
> > drivers/gpu/drm/i915/intel_sdvo.c | 10 ---
> > drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++-
> > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++-
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++--
> > drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++--
> > drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> > drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++-
> > drivers/gpu/drm/sti/sti_hdmi.c| 3 ++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++-
> > drivers/gpu/drm/tegra/hdmi.c | 3 ++-
> > drivers/gpu/drm/tegra/sor.c | 3 ++-
> > drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +---
> > drivers/gpu/drm/zte/zx_hdmi.c | 4 ++-
> > include/drm/drm_edid.h| 8 +++---
> > 27 files changed, 94 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > index 4cfecdce29a3..1f0426d2fc2a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > @@ -1682,7 +1682,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
> > *encoder,
> > dce_v10_0_audio_write_sad_regs(encoder);
> > dce_v10_0_audio_write_latency_fields(encoder, mode);
> >
> > - err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> > + err = drm_hdmi_avi_infoframe_from_display_mode(, connector, mode);
> > if (err < 0) {
> > DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> > return;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > index 7c868916d90f..2280b971d758 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > @@ -1724,7 +1724,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
> > *encoder,
> > dce_v11_0_audio_write_sad_regs(encoder);
> > dce_v11_0_audio_write_latency_fields(encoder, mode);
> >
> > - err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> > + err = drm_hdmi_avi_infoframe_from_display_mode(, connector, mode);
> > if (err < 0) {
> > DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> > return;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > index 17eaaba36017..db443ec53d3a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > @@ -1423,6 +1423,7 @@ static void dce_v6_0_audio_set_avi_infoframe(struct
> > drm_encoder *encoder,
> > struct amdgpu_device *adev = dev->dev_private;
> > struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
> > struct amdgpu_encoder_atom_dig *dig = amdgpu_encoder->enc_priv;
> > + struct
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Make CHICKEN_TRANS reg not depend on enum value (rev2)
On Tue, Nov 20, 2018 at 01:00:17AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Make CHICKEN_TRANS reg not depend on enum value (rev2)
> URL : https://patchwork.freedesktop.org/series/52700/
> State : success
Pushed to -dinq, thanks for the review.
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_5162_full -> Patchwork_10851_full =
>
> == Summary - WARNING ==
>
> Minor unknown changes coming with Patchwork_10851_full need to be verified
> manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_10851_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_10851_full:
>
> === IGT changes ===
>
> Warnings
>
> igt@pm_rc6_residency@rc6-accuracy:
> shard-kbl: PASS -> SKIP
>
>
> == Known issues ==
>
> Here are the changes found in Patchwork_10851_full that come from known
> issues:
>
> === IGT changes ===
>
> Issues hit
>
> igt@gem_eio@in-flight-1us:
> shard-glk: PASS -> FAIL (fdo#105957)
>
> igt@gem_exec_schedule@pi-ringfull-bsd:
> shard-skl: NOTRUN -> FAIL (fdo#103158)
>
> igt@gem_ppgtt@blt-vs-render-ctxn:
> shard-skl: NOTRUN -> TIMEOUT (fdo#108039)
>
> igt@i915_suspend@shrink:
> shard-snb: NOTRUN -> DMESG-WARN (fdo#102365, fdo#108784)
> {shard-iclb}: NOTRUN -> DMESG-WARN (fdo#108784)
>
> igt@kms_atomic_transition@1x-modeset-transitions-nonblocking:
> shard-skl: PASS -> FAIL (fdo#108228, fdo#108470)
>
> igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
> shard-skl: PASS -> FAIL (fdo#108470, fdo#107815)
>
> igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
> {shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107956) +1
>
> igt@kms_ccs@pipe-a-crc-primary-rotation-180:
> {shard-iclb}: NOTRUN -> FAIL (fdo#107725) +2
>
> igt@kms_chv_cursor_fail@pipe-b-256x256-top-edge:
> shard-skl: PASS -> FAIL (fdo#104671)
>
> igt@kms_chv_cursor_fail@pipe-c-128x128-bottom-edge:
> shard-skl: NOTRUN -> FAIL (fdo#104671)
>
> igt@kms_color@pipe-a-degamma:
> shard-apl: PASS -> FAIL (fdo#108145, fdo#104782)
>
> igt@kms_color@pipe-c-gamma:
> shard-skl: PASS -> FAIL (fdo#108228, fdo#104782)
>
> igt@kms_cursor_crc@cursor-128x128-onscreen:
> shard-apl: PASS -> FAIL (fdo#103232) +3
>
> igt@kms_cursor_crc@cursor-256x256-dpms:
> shard-skl: PASS -> FAIL (fdo#103232) +1
>
> igt@kms_cursor_crc@cursor-64x21-sliding:
> shard-glk: PASS -> FAIL (fdo#103232)
>
> igt@kms_cursor_crc@cursor-64x64-suspend:
> {shard-iclb}: NOTRUN -> FAIL (fdo#103232) +8
> shard-apl: PASS -> FAIL (fdo#103232, fdo#103191)
>
> igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-xtiled:
> shard-skl: PASS -> FAIL (fdo#103184)
>
> igt@kms_draw_crc@draw-method-xrgb-pwrite-xtiled:
> shard-skl: PASS -> FAIL (fdo#107791)
>
> igt@kms_fbcon_fbt@psr:
> {shard-iclb}: NOTRUN -> FAIL (fdo#107882)
>
> igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
> shard-glk: PASS -> FAIL (fdo#105363)
>
> igt@kms_flip@modeset-vs-vblank-race:
> shard-apl: PASS -> FAIL (fdo#103060)
>
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
> shard-apl: PASS -> FAIL (fdo#103167) +2
>
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
> shard-glk: PASS -> FAIL (fdo#103167) +1
>
> igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu:
> shard-skl: PASS -> FAIL (fdo#105682) +1
>
> igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-gtt:
> shard-skl: PASS -> FAIL (fdo#103167) +4
>
> igt@kms_hdmi_inject@inject-audio:
> {shard-iclb}: NOTRUN -> FAIL (fdo#102370)
>
> igt@kms_panel_fitting@legacy:
> shard-skl: NOTRUN -> FAIL (fdo#105456)
>
> igt@kms_plane@plane-panning-bottom-right-pipe-c-planes:
> shard-skl: PASS -> FAIL (fdo#103166)
>
> igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
> shard-glk: PASS -> FAIL (fdo#108145) +1
>
> igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
> shard-skl: PASS -> FAIL (fdo#108145, fdo#107815)
>
> igt@kms_plane_alpha_blend@pipe-b-alpha-7efc:
> shard-kbl: NOTRUN -> FAIL (fdo#108145, fdo#108590)
>
> igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
> shard-skl: NOTRUN -> FAIL (fdo#108145,
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Make pipe/transcoder offsets not depend on enum values
On Tue, Nov 20, 2018 at 01:53:06PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915: Make pipe/transcoder offsets not
> depend on enum values
> URL : https://patchwork.freedesktop.org/series/52742/
> State : success
Pushed to -dinq, thanks for the reviews.
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_5169_full -> Patchwork_10857_full =
>
> == Summary - WARNING ==
>
> Minor unknown changes coming with Patchwork_10857_full need to be verified
> manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_10857_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_10857_full:
>
> === IGT changes ===
>
> Warnings
>
> igt@pm_rc6_residency@rc6-accuracy:
> shard-snb: PASS -> SKIP
>
>
> == Known issues ==
>
> Here are the changes found in Patchwork_10857_full that come from known
> issues:
>
> === IGT changes ===
>
> Issues hit
>
> igt@drm_import_export@import-close-race-flink:
> shard-skl: NOTRUN -> TIMEOUT (fdo#108667)
>
> igt@gem_eio@in-flight-1us:
> shard-glk: PASS -> FAIL (fdo#107799)
>
> igt@gem_exec_schedule@pi-ringfull-bsd:
> {shard-iclb}: NOTRUN -> FAIL (fdo#103158) +2
>
> igt@gem_ppgtt@blt-vs-render-ctxn:
> shard-skl: NOTRUN -> TIMEOUT (fdo#108039)
>
> igt@i915_suspend@shrink:
> {shard-iclb}: NOTRUN -> DMESG-WARN (fdo#108784)
>
> igt@kms_available_modes_crc@available_mode_test_crc:
> {shard-iclb}: NOTRUN -> FAIL (fdo#106641)
>
> igt@kms_busy@extended-modeset-hang-newfb-render-a:
> shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +2
>
> igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
> shard-hsw: PASS -> DMESG-WARN (fdo#107956)
>
> igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
> {shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107956) +5
>
> igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
> {shard-iclb}: NOTRUN -> FAIL (fdo#107725) +4
>
> igt@kms_chv_cursor_fail@pipe-b-256x256-top-edge:
> shard-skl: PASS -> FAIL (fdo#104671)
>
> igt@kms_chv_cursor_fail@pipe-c-128x128-bottom-edge:
> shard-skl: NOTRUN -> FAIL (fdo#104671)
>
> igt@kms_cursor_crc@cursor-128x128-sliding:
> shard-apl: PASS -> FAIL (fdo#103232) +2
>
> igt@kms_cursor_crc@cursor-256x256-random:
> {shard-iclb}: NOTRUN -> FAIL (fdo#103232) +9
>
> igt@kms_cursor_crc@cursor-64x64-suspend:
> shard-skl: PASS -> INCOMPLETE (fdo#104108) +1
>
> igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic:
> shard-glk: PASS -> FAIL (fdo#106509, fdo#105454)
>
> igt@kms_draw_crc@draw-method-xrgb2101010-render-untiled:
> {shard-iclb}: PASS -> WARN (fdo#108336) +3
>
> igt@kms_draw_crc@draw-method-xrgb-pwrite-xtiled:
> {shard-iclb}: NOTRUN -> WARN (fdo#108336)
>
> igt@kms_fbcon_fbt@psr:
> {shard-iclb}: NOTRUN -> FAIL (fdo#107882)
> shard-skl: NOTRUN -> FAIL (fdo#107882)
>
> igt@kms_flip@busy-flip:
> {shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107724) +16
>
> igt@kms_frontbuffer_tracking@basic:
> {shard-iclb}: PASS -> DMESG-WARN (fdo#107724, fdo#108336) +5
>
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move:
> {shard-iclb}: PASS -> DMESG-FAIL (fdo#107724) +4
>
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
> shard-glk: PASS -> FAIL (fdo#103167)
>
> igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt:
> {shard-iclb}: NOTRUN -> DMESG-FAIL (fdo#107724) +4
>
> igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-cpu:
> shard-skl: NOTRUN -> FAIL (fdo#103167)
>
> igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite:
> {shard-iclb}: PASS -> FAIL (fdo#103167) +2
>
> igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt:
> {shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107724, fdo#108336) +6
>
> igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-pwrite:
> {shard-iclb}: NOTRUN -> FAIL (fdo#103167) +4
>
> igt@kms_hdmi_inject@inject-audio:
> {shard-iclb}: NOTRUN -> FAIL (fdo#102370)
>
> igt@kms_panel_fitting@legacy:
> shard-skl: NOTRUN -> FAIL (fdo#105456)
>
> igt@kms_plane@plane-position-covered-pipe-c-planes:
> shard-apl: PASS -> FAIL (fdo#103166) +2
>
> igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force a LUT update in intel_initial_commit()
On Tue, Nov 20, 2018 at 02:25:40PM -0800, Rodrigo Vivi wrote:
> On Tue, Nov 20, 2018 at 03:54:49PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > If we force a plane update to fix up our half populated plane state
> > we'll also force on the pipe gamma for the plane (since we always
> > enable pipe gamma currently). If the BIOS hasn't programmed a sensible
> > LUT into the hardware this will cause the image to become corrupted.
> > Typical symptoms are a purple/yellow/etc. flash when the driver loads.
> >
> > To avoid this let's program something sensible into the LUT when
> > we do the plane update. In the future I plan to add proper plane
> > gamma enable readout so this is just a temporary measure.
>
> Since this is temporary and marked with FIXME and Hans confirmed
> it solves the best behaviour let's move with this.
>
> But I'm wondering if there is no way to minimize this instead of
> forcing this to every commit for each crtc...
It's just for the first commit we do when loading the driver.
>
> Anyway,
>
> Reviewed-by: Rodrigo Vivi
>
> >
> > Cc: Hans de Goede
> > Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with
> > external display")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 132e978227fb..60c1e54285c1 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15011,6 +15011,14 @@ static int intel_initial_commit(struct drm_device
> > *dev)
> > ret = drm_atomic_add_affected_planes(state, crtc);
> > if (ret)
> > goto out;
> > +
> > + /*
> > +* FIXME hack to force a LUT update to avoid the
> > +* plane update forcing the pipe gamma on without
> > +* having a proper LUT loaded. Remove once we
> > +* have readout for pipe gamma enable.
> > +*/
> > + crtc_state->color_mgmt_changed = true;
> > }
> > }
> >
> > --
> > 2.18.1
> >
> > ___
> > 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] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions
On Tue, 20 Nov 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make life easier for drivers by simply passing the connector
> to drm_hdmi_avi_infoframe_from_display_mode() and
> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't
> need to worry about is_hdmi2_sink mess.
Overall looks about right and nice,
Reviewed-by: Jani Nikula
But please do take that with a grain of salt for everything outside of
i915 and drm core.
Please also find a few comments inline below.
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: Archit Taneja
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Russell King
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: Thierry Reding
> Cc: Eric Anholt
> Cc: Shawn Guo
> Cc: Ilia Mirkin
> Cc: amd-...@lists.freedesktop.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 ++--
> drivers/gpu/drm/bridge/sii902x.c | 3 ++-
> drivers/gpu/drm/bridge/sil-sii8620.c | 3 +--
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
> drivers/gpu/drm/drm_edid.c| 33 ++-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++-
> drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++-
> drivers/gpu/drm/i915/intel_hdmi.c | 14 +-
> drivers/gpu/drm/i915/intel_lspcon.c | 15 ++-
> drivers/gpu/drm/i915/intel_sdvo.c | 10 ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++-
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 3 ++-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 +++--
> drivers/gpu/drm/omapdrm/omap_encoder.c| 5 ++--
> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++-
> drivers/gpu/drm/sti/sti_hdmi.c| 3 ++-
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 3 ++-
> drivers/gpu/drm/tegra/hdmi.c | 3 ++-
> drivers/gpu/drm/tegra/sor.c | 3 ++-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 11 +---
> drivers/gpu/drm/zte/zx_hdmi.c | 4 ++-
> include/drm/drm_edid.h| 8 +++---
> 27 files changed, 94 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 4cfecdce29a3..1f0426d2fc2a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1682,7 +1682,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v10_0_audio_write_sad_regs(encoder);
> dce_v10_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> + err = drm_hdmi_avi_infoframe_from_display_mode(, connector, mode);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 7c868916d90f..2280b971d758 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1724,7 +1724,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v11_0_audio_write_sad_regs(encoder);
> dce_v11_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> + err = drm_hdmi_avi_infoframe_from_display_mode(, connector, mode);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index 17eaaba36017..db443ec53d3a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> @@ -1423,6 +1423,7 @@ static void dce_v6_0_audio_set_avi_infoframe(struct
> drm_encoder *encoder,
> struct amdgpu_device *adev = dev->dev_private;
> struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
> struct amdgpu_encoder_atom_dig *dig = amdgpu_encoder->enc_priv;
> + struct drm_connector *connector =
> amdgpu_get_connector_for_encoder(encoder);
> struct hdmi_avi_infoframe frame;
> u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AVI_INFOFRAME_SIZE];
> uint8_t *payload = buffer + 3;
> @@ -1430,7 +1431,7 @@ static void
Re: [Intel-gfx] [PATCH 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count
On Wed, Nov 21, 2018 at 10:27:27AM +0100, Daniel Vetter wrote:
> On Mon, Nov 12, 2018 at 06:59:45PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On i965gm we need to adjust max_vblank_count dynamically
> > depending on whether the TV encoder is used or not. To
> > that end add a per-crtc max_vblank_count that takes
> > precedence over its device wide counterpart. The driver
> > can now call drm_crtc_set_max_vblank_count() to configure
> > the per-crtc value before calling drm_vblank_on().
> >
> > Also looks like there was some discussion about exynos needing
> > similar treatment.
> >
> > Cc: sta...@vger.kernel.org
> > Cc: Inki Dae
> > Cc: Daniel Vetter
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_vblank.c | 39
> > include/drm/drm_vblank.h | 8
> > 2 files changed, 43 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index 98e091175921..c3abbdca8aba 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -105,13 +105,20 @@ static void store_vblank(struct drm_device *dev,
> > unsigned int pipe,
> > write_sequnlock(>seqlock);
> > }
> >
> > +static u32 drm_max_vblank_count(struct drm_device *dev, unsigned int pipe)
> > +{
> > + struct drm_vblank_crtc *vblank = >vblank[pipe];
> > +
> > + return vblank->max_vblank_count ?: dev->max_vblank_count;
> > +}
> > +
> > /*
> > * "No hw counter" fallback implementation of .get_vblank_counter() hook,
> > * if there is no useable hardware frame counter available.
> > */
> > static u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int
> > pipe)
> > {
> > - WARN_ON_ONCE(dev->max_vblank_count != 0);
> > + WARN_ON_ONCE(drm_max_vblank_count(dev, pipe) != 0);
> > return 0;
> > }
> >
> > @@ -198,6 +205,7 @@ static void drm_update_vblank_count(struct drm_device
> > *dev, unsigned int pipe,
> > ktime_t t_vblank;
> > int count = DRM_TIMESTAMP_MAXRETRIES;
> > int framedur_ns = vblank->framedur_ns;
> > + u32 max_vblank_count = drm_max_vblank_count(dev, pipe);
> >
> > /*
> > * Interrupts were disabled prior to this call, so deal with counter
> > @@ -216,9 +224,9 @@ static void drm_update_vblank_count(struct drm_device
> > *dev, unsigned int pipe,
> > rc = drm_get_last_vbltimestamp(dev, pipe, _vblank,
> > in_vblank_irq);
> > } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
> >
> > - if (dev->max_vblank_count != 0) {
> > + if (max_vblank_count) {
> > /* trust the hw counter when it's around */
> > - diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
> > + diff = (cur_vblank - vblank->last) & max_vblank_count;
> > } else if (rc && framedur_ns) {
> > u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
> >
> > @@ -258,7 +266,8 @@ static void drm_update_vblank_count(struct drm_device
> > *dev, unsigned int pipe,
> > pipe, vblank->count, diff, cur_vblank, vblank->last);
> >
> > if (diff == 0) {
> > - WARN_ON_ONCE(cur_vblank != vblank->last);
> > + WARN_ON_ONCE(max_vblank_count &&
> > +cur_vblank != vblank->last);
>
> Unrelated bugfix for this warning? Should be a separate patch I think, or
> I'm missing something.
Ah, yeah this was due to a quirk of i965gm hardware. The hw counter
does work until the exact point when we enable TV encoder. Thus we
will get non-zero values up to that point, and since the TV encoder
isn't yet throttling the pipe it presumably runs at the oversample
clock so our timestamp based estimates can give us a diff==0 even
though the pipe did indeed pass a vblank already. I forgot to
note this in the commit message.
I think we can handle this three ways:
1. do what I do here and just let the mismatch slip through
2. force i915_get_vblank_counter() to return 0 always when the
TV encoder is going to be used
3. don't call drm_crtc_set_max_vblank_count() before drm_vblank_on()
and instead delay it until just before we enable the TV encoder
I think option 3 is overly complicated to consider seriously. So
option 1 or option 2 is what I think we should do. For whatever
reason I went with option 1 here, but maybe option 2 is better
since it would be all contained within i915...
>
> > return;
> > }
> >
> > @@ -1204,6 +1213,28 @@ void drm_crtc_vblank_reset(struct drm_crtc *crtc)
> > }
> > EXPORT_SYMBOL(drm_crtc_vblank_reset);
> >
> > +/**
> > + * drm_crtc_set_max_vblank_count - configure the hw max vblank counter
> > value
> > + * @crtc: CRTC in question
> > + * @max_vblank_count: max hardware vblank counter value
> > + *
> > + * Update the maximum hardware vblank counter value for @crtc. Useful
> > + * for hardware where the operation of the hardware vblank counter
> > + * depends on the active
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add rotation readout for plane initial config
Op 20-11-18 om 23:20 schreef Rodrigo Vivi:
> On Tue, Nov 20, 2018 at 03:54:50PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> If we need to force a full plane update before userspace/fbdev
>> have given us a proper plane state we should try to maintain the
>> current plane state as much as possible (apart from the parts
>> of the state we're trying to fix up with the plane update).
>> To that end add basic readout for the plane rotation and
>> maintain it during the initial fb takeover.
>>
>> Cc: Hans de Goede
>> Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with
>> external display")
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 27 +++
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> 2 files changed, 28 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 60c1e54285c1..4d339f54559c 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -2831,6 +2831,7 @@ intel_find_initial_plane_obj(struct intel_crtc
>> *intel_crtc,
>> return;
>>
>> valid_fb:
>> +intel_state->base.rotation = plane_config->rotation;
>> intel_fill_fb_ggtt_view(_state->view, fb,
>> intel_state->base.rotation);
>> intel_state->color_plane[0].stride =
>> @@ -7787,8 +7788,15 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
>> plane_config->tiling = I915_TILING_X;
>> fb->modifier = I915_FORMAT_MOD_X_TILED;
>> }
>> +
>> +if (val & DISPPLANE_ROTATE_180)
>> +plane_config->rotation = DRM_MODE_ROTATE_180;
>> }
>>
>> +if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B &&
>> +val & DISPPLANE_MIRROR)
>> +plane_config->rotation |= DRM_MODE_REFLECT_X;
>> +
>> pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
>> fourcc = i9xx_format_to_fourcc(pixel_format);
>> fb->format = drm_format_info(fourcc);
>> @@ -8898,6 +8906,25 @@ skylake_get_initial_plane_config(struct intel_crtc
>> *crtc,
>> goto error;
>> }
>>
>> +switch (val & PLANE_CTL_ROTATE_MASK) {
>> +case PLANE_CTL_ROTATE_0:
>> +plane_config->rotation = DRM_MODE_ROTATE_0;
>> +break;
>> +case PLANE_CTL_ROTATE_90:
>> +plane_config->rotation = DRM_MODE_ROTATE_270;
> we should add that comment that DRM_MODE_ROTATE_ is counter clockwise
> to avoid later confusion.
>
> Also I wonder if we shouldn't move all the cases to a unique
> map function.
>
> Anyways,
>
>
> Reviewed-by: Rodrigo Vivi
>
>
>
>> +break;
>> +case PLANE_CTL_ROTATE_180:
>> +plane_config->rotation = DRM_MODE_ROTATE_180;
>> +break;
>> +case PLANE_CTL_ROTATE_270:
>> +plane_config->rotation = DRM_MODE_ROTATE_90;
>> +break;
>> +}
>> +
>> +if (INTEL_GEN(dev_priv) >= 10 &&
>> +val & PLANE_CTL_FLIP_HORIZONTAL)
>> +plane_config->rotation |= DRM_MODE_REFLECT_X;
>> +
>> base = I915_READ(PLANE_SURF(pipe, plane_id)) & 0xf000;
>> plane_config->base = base;
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index f575ba2a59da..a7d9ac912125 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -572,6 +572,7 @@ struct intel_initial_plane_config {
>> unsigned int tiling;
>> int size;
>> u32 base;
>> +u8 rotation;
>> };
>>
>> #define SKL_MIN_SRC_W 8
>> --
>> 2.18.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Not sure if pushed yet.
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220
+ Chris Quoting Pavel Machek (2018-11-08 19:58:03) > Hi! > > My machine locked hard (thinkpad x220). After reboot, I found this in > syslog: > > Sounds like memory corruption..? Does not sound like easy to debug. Were you doing something GPU intense when you experienced the hard hang? And if so, have you been able to hit the issue more than once? At this point it doesn't look like anything we've hit previously, so would be great to have some more insight into how we could reproduce. There's one similar for nouveau in Bugzilla, but it seems like a genuine memory corruption (1 bit flipped): https://bugs.freedesktop.org/show_bug.cgi?id=84880 Any extra information would be of use :) Regards, Joonas PS. Could you open a bug to Bugzilla, it'll help to collect the information in one consolidated place: https://01.org/linuxgraphics/documentation/how-report-bugs > > ...otoh, it still looks like an addres, so maybe it is "just" race in > GPU drivers? > > Any ideas? > Pavel > > Nov 8 18:35:01 duo CRON[28511]: (root) CMD (command -v debian-sa1 > > /dev/null && debian-sa > 1 1 1) > Nov 8 18:42:57 duo kernel: list_del corruption. prev->next should be > 8801742b8178, but > was c9000192fec8 > Nov 8 18:42:57 duo kernel: [ cut here ] > Nov 8 18:42:57 duo kernel: kernel BUG at > /data/fast/l/k/lib/list_debug.c:53! > Nov 8 18:42:57 duo kernel: invalid opcode: [#1] SMP PTI > Nov 8 18:42:57 duo kernel: CPU: 2 PID: 1082 Comm: i915/signal:1 Not > tainted 4.20.0-rc1+ #3 > Nov 8 18:42:57 duo kernel: Hardware name: LENOVO 42872WU/42872WU, > BIOS 8DET74WW (1.44 ) 03 > /13/2018 > Nov 8 18:42:57 duo kernel: RIP: > 0010:__list_del_entry_valid+0x8e/0x90 > Nov 8 18:42:57 duo kernel: Code: 66 88 d1 ff 0f 0b 48 89 fe 31 c0 48 > c7 c7 90 74 5e 85 e8 > 53 88 d1 ff 0f 0b 48 89 fe 31 c0 48 c7 c7 c8 74 5e 85 e8 40 88 d1 ff > <0f> 0b 55 48 89 d0 48 > 8b 52 08 48 89 e5 48 39 f2 75 19 48 8b 32 48 > Nov 8 18:42:57 duo kernel: RSP: :c9000196be78 EFLAGS: > 00210086 > Nov 8 18:42:57 duo kernel: RAX: 0054 RBX: > 8801742b8178 RCX: 00 > 00 > Nov 8 18:42:57 duo kernel: RDX: RSI: > 88019e2a53d8 RDI: 88019e2a53 > d8 > Nov 8 18:42:57 duo kernel: RBP: c9000196be78 R08: > 880196e2cd10 R09: 00 > 00 > Nov 8 18:42:57 duo kernel: R10: e7684eb9 R11: > 3863656632393101 R12: c9000196be > c8 > Nov 8 18:42:57 duo kernel: R13: 88019707e000 R14: > 8801742b8080 R15: c9000192fd > d0 > Nov 8 18:42:57 duo kernel: FS: () > GS:88019e28() knlGS:000 > 0 > Nov 8 18:42:57 duo kernel: CS: 0010 DS: ES: CR0: > 80050033 > Nov 8 18:42:57 duo kernel: CR2: ed2bf000 CR3: > 0581e001 CR4: 000606a0 > Nov 8 18:42:57 duo kernel: Call Trace: > Nov 8 18:42:57 duo kernel: intel_breadcrumbs_signaler+0x162/0x330 > Nov 8 18:42:57 duo kernel: kthread+0x116/0x150 > Nov 8 18:42:57 duo kernel: ? intel_engine_wakeup+0x40/0x40 > Nov 8 18:42:57 duo kernel: ? kthread_park+0x90/0x90 > Nov 8 18:42:57 duo kernel: ret_from_fork+0x35/0x40 > Nov 8 18:42:57 duo kernel: Modules linked in: > Nov 8 18:42:57 duo kernel: ---[ end trace 2f8da183a56f80f6 ]--- > Nov 8 18:42:57 duo kernel: RIP: > 0010:__list_del_entry_valid+0x8e/0x90 > Nov 8 18:42:57 duo kernel: Code: 66 88 d1 ff 0f 0b 48 89 fe 31 c0 > 48 c7 c7 90 74 5e 85 e8 53 88 d1 ff 0f 0b 48 89 fe 31 c0 48 c7 c7 c8 > 74 5e 85 e8 40 88 d1 ff <0f> 0b 55 48 89 d0 48 8b 52 08 48 89 e5 48 > 39 f2 75 19 48 8b 32 48 > Nov 8 18:42:57 duo kernel: RSP: :c9000196be78 EFLAGS: > 00210086 > Nov 8 18:42:57 duo kernel: RAX: 0054 RBX: > 8801742b8178 RCX: > Nov 8 18:42:57 duo kernel: RDX: RSI: > 88019e2a53d8 RDI: 88019e2a53d8 > Nov 8 18:42:57 duo kernel: RBP: c9000196be78 R08: > 880196e2cd10 R09: > Nov 8 18:42:57 duo kernel: R10: e7684eb9 R11: > 3863656632393101 R12: c9000196bec8 > Nov 8 18:42:57 duo kernel: R13: 88019707e000 R14: > 8801742b8080 R15: c9000192fdd0 > Nov 8 18:42:57 duo kernel: FS: () > GS:88019e28() knlGS: > Nov 8 18:42:57 duo kernel: CS: 0010 DS: ES: CR0: > 80050033 > Nov 8 18:42:57 duo kernel: CR2: ed2bf000 CR3: > 0581e001 CR4: 000606a0 > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Do not touch PCH handshake registers if PCH is not present
On Tue, Nov 20, 2018 at 02:32:41PM -0800, José Roberto de Souza wrote:
> If no PCH was detected in intel_detect_pch() don't touch the
> handshake registers.
We are explicitly told to frob this on BXT/GLK. So this doesn't make
sense. What is this supposed to fix?
>
> Cc: Lucas De Marchi
> Cc: Jani Nikula
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 1c2de9b69a19..f33f335d6106 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -3325,6 +3325,9 @@ static void intel_pch_reset_handshake(struct
> drm_i915_private *dev_priv,
> i915_reg_t reg;
> u32 reset_bits, val;
>
> + if (!HAS_PCH_SPLIT(dev_priv))
> + return;
> +
> if (IS_IVYBRIDGE(dev_priv)) {
> reg = GEN7_MSG_CTL;
> reset_bits = WAIT_FOR_PCH_FLR_ACK | WAIT_FOR_PCH_RESET_ACK;
> --
> 2.19.1
>
> ___
> 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] [PATCH] drm/atomic: Fix the early return in drm_atomic_set_mode_for_crtc()
On Wed, Nov 21, 2018 at 10:59:56AM +0100, Daniel Vetter wrote:
> On Tue, Nov 20, 2018 at 07:55:42PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The early return in drm_atomic_set_mode_for_crtc() isn't quite
> > right. It would mistakenly return and fail to update
> > crtc_state->enable if someone actually tried to set a zeroed
> > mode on a currently disabled crtc. I suppose that should never
> > happen but better safe than sorry.
> >
> > Additionally the early return will not be taken if we're trying to
> > disable an already disable crtc. While that is not actually harmful
> > it is inconsistent, so let's handle that case as well.
> >
> > Signed-off-by: Ville Syrjälä
>
> Do we have an igt for this? I.e. trying to set a all-0 mode for a disabled
> CRTC and seeing what happens ...
It should get rejected by drm_mode_convert_umode()->drm_mode_validate_basic()
so presumably you shouldn't be able to do this from userspace. In kernel
users could bypass that check and sneak something like this in however.
But I guess having an igt to verify that we do indeed reject bad modes
would a decent idea. Looks like currently we only have
kms_invalid_dotclock.
>
> Patch itself looks fine, has my r-b if the igt materializes.
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 86ac33922b09..ed0ea82e8a1d 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -68,8 +68,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
> > *state,
> > struct drm_mode_modeinfo umode;
> >
> > /* Early return for no change. */
> > - if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
> > - return 0;
> > + if (state->enable) {
> > + if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
> > + return 0;
> > + } else {
> > + if (!mode)
> > + return 0;
> > + }
> >
> > drm_property_blob_put(state->mode_blob);
> > state->mode_blob = NULL;
> > --
> > 2.18.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix spelling mistake "reserverd" -> "reserved"
On Tue, 20 Nov 2018, Alexandre Belloni wrote:
> Fix a spelling mistake in a comment.
>
> Signed-off-by: Alexandre Belloni
Thanks for the patch, pushed to drm-intel-next-queued.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index f9ce35da4123..742f8ff101e4 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4280,7 +4280,7 @@ static void gen10_sseu_device_status(struct
> drm_i915_private *dev_priv,
> for (s = 0; s < info->sseu.max_slices; s++) {
> /*
>* FIXME: Valid SS Mask respects the spec and read
> - * only valid bits for those registers, excluding reserverd
> + * only valid bits for those registers, excluding reserved
>* although this seems wrong because it would leave many
>* subslices without ACK.
>*/
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Add HAS_DISPLAY() and use it
== Series Details ==
Series: series starting with [1/3] drm/i915: Add HAS_DISPLAY() and use it
URL : https://patchwork.freedesktop.org/series/52790/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5175_full -> Patchwork_10871_full =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10871_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10871_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_10871_full:
=== IGT changes ===
Possible regressions
igt@gem_exec_blt@normal:
shard-skl: NOTRUN -> INCOMPLETE
Warnings
igt@tools_test@sysfs_l3_parity:
shard-hsw: SKIP -> PASS
igt@tools_test@tools_test:
{shard-iclb}: SKIP -> PASS
== Known issues ==
Here are the changes found in Patchwork_10871_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@gem_set_tiling_vs_gtt:
{shard-iclb}: PASS -> INCOMPLETE (fdo#108343)
igt@gem_softpin@noreloc-s3:
shard-skl: NOTRUN -> INCOMPLETE (fdo#107773, fdo#104108)
igt@gem_userptr_blits@readonly-unsync:
shard-skl: NOTRUN -> INCOMPLETE (fdo#108074)
igt@kms_atomic_transition@1x-modeset-transitions:
{shard-iclb}: PASS -> DMESG-WARN (fdo#108336, fdo#107724) +2
igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
shard-skl: PASS -> FAIL (fdo#107815, fdo#108470)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +3
igt@kms_cursor_crc@cursor-256x256-suspend:
shard-skl: PASS -> FAIL (fdo#103191, fdo#103232)
igt@kms_cursor_crc@cursor-64x21-random:
shard-glk: PASS -> FAIL (fdo#103232) +1
igt@kms_cursor_crc@cursor-64x64-dpms:
shard-skl: PASS -> FAIL (fdo#103232) +1
igt@kms_draw_crc@draw-method-rgb565-blt-ytiled:
shard-glk: PASS -> FAIL (fdo#103184)
igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-ytiled:
shard-skl: PASS -> FAIL (fdo#103184)
igt@kms_draw_crc@draw-method-xrgb2101010-render-untiled:
{shard-iclb}: PASS -> WARN (fdo#108336) +2
igt@kms_flip@blocking-wf_vblank:
{shard-iclb}: PASS -> DMESG-WARN (fdo#107724) +11
igt@kms_flip_tiling@flip-to-y-tiled:
shard-skl: PASS -> FAIL (fdo#107931)
igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
shard-skl: PASS -> FAIL (fdo#105682) +3
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
{shard-iclb}: PASS -> DMESG-FAIL (fdo#107720, fdo#107724)
shard-apl: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-blt:
shard-glk: PASS -> FAIL (fdo#103167) +2
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-render:
shard-glk: PASS -> DMESG-FAIL (fdo#106538, fdo#105763)
igt@kms_frontbuffer_tracking@fbc-indfb-scaledprimary:
{shard-iclb}: PASS -> DMESG-FAIL (fdo#107724) +5
igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt:
shard-glk: PASS -> DMESG-WARN (fdo#106538, fdo#105763) +4
igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
shard-skl: NOTRUN -> FAIL (fdo#105683)
igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-gtt:
shard-skl: PASS -> FAIL (fdo#103167)
igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
shard-skl: NOTRUN -> FAIL (fdo#108145) +1
igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
shard-skl: PASS -> FAIL (fdo#107815)
igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
shard-apl: PASS -> FAIL (fdo#103166) +1
igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format:
{shard-iclb}: NOTRUN -> DMESG-WARN (fdo#107724)
igt@kms_setmode@basic:
shard-hsw: PASS -> FAIL (fdo#99912)
shard-kbl: PASS -> FAIL (fdo#99912)
igt@pm_rpm@basic-rte:
shard-skl: PASS -> INCOMPLETE (fdo#107807)
igt@pm_rpm@pm-tiling:
shard-skl: NOTRUN -> INCOMPLETE (fdo#107807)
igt@pm_rpm@universal-planes:
{shard-iclb}: PASS -> DMESG-WARN (fdo#108654, fdo#108756)
{igt@runner@aborted}:
{shard-iclb}: NOTRUN -> FAIL (fdo#108756)
Possible fixes
igt@drm_import_export@import-close-race-flink:
shard-skl: TIMEOUT (fdo#108667) -> PASS
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-kbl: INCOMPLETE (fdo#103665, fdo#106887, fdo#106023) ->
PASS
Re: [Intel-gfx] [PATCH] drm/i915/backlight: Fix backlight takeover on LPT
On Wed, Nov 21, 2018 at 08:16:06AM +0100, Tolga Cakir wrote:
> Am Di., 20. Nov. 2018 um 19:51 Uhr schrieb Ville Syrjälä
> :
> >
> > On Tue, Nov 20, 2018 at 11:39:26AM +0100, Maarten Lankhorst wrote:
> > > On lynxpoint the bios sometimes sets up the backlight using the CPU
> > > display, but the driver expects using the PWM PCH override register.
> > >
> > > Read the value from the CPU register, then convert it to the other
> > > units by converting from the old duty cycle, to freq, to the new units.
> > >
> > > This value is then programmed in the override register, after which
> > > we set the override and disable the CPU display control. This allows
> > > us to switch the source without flickering, and make the backlight
> > > controls work in the driver.
> > >
> > > Signed-off-by: Maarten Lankhorst
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108225
> > > Cc: Basil Eric Rabi
> > > Cc: Hans de Goede
> > > Cc: Tolga Cakir
> > > Tested-by: Tolga Cakir
> > > ---
> > > drivers/gpu/drm/i915/intel_panel.c | 34 +++---
> > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > b/drivers/gpu/drm/i915/intel_panel.c
> > > index e6cd7b55c018..3357232f1b0e 100644
> > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > @@ -1485,7 +1485,7 @@ static int lpt_setup_backlight(struct
> > > intel_connector *connector, enum pipe unus
> > > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > struct intel_panel *panel = >panel;
> > > u32 pch_ctl1, pch_ctl2, val;
> > > - bool alt;
> > > + bool alt, cpu_mode = false;
> > >
> > > if (HAS_PCH_LPT(dev_priv))
> > > alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> > > @@ -1507,12 +1507,40 @@ static int lpt_setup_backlight(struct
> > > intel_connector *connector, enum pipe unus
> > >
> > > panel->backlight.min = get_backlight_min_vbt(connector);
> > >
> > > - val = lpt_get_backlight(connector);
> > > + panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> > > + if (panel->backlight.enabled && HAS_PCH_LPT(dev_priv) &&
> > > + (I915_READ(BLC_PWM_CPU_CTL2) & BLM_PWM_ENABLE) &&
> > > + !WARN_ON(pch_ctl1 & BLM_PCH_OVERRIDE_ENABLE)) {
> > > + u32 freq;
> > > +
> > > + cpu_mode = true;
> > > + /*
> > > + * We're in cpu mode, convert to PCH units.
> > > + *
> > > + * Convert CPU pwm tick back to hz, back to new PCH units
> > > again.
> > > + * this is the same formula as pch_hz_to_pwm, but the other
> > > way
> > > + * around..
> > > + */
> > > + val = pch_get_backlight(connector);
> > > + freq = DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), val *
> > > 128);
> >
> > The docs are telling me that HSW/BDW use cdclk for the CPU backlight,
> > and the increment is configurable as well.
> >
> > Also what about S4 resume? Don't we need this trick there as well?
> >
>
> Hi,
>
> I couldn't test this patch for S4 resume on my Dell M3800 laptop (Core
> i7-4702HQ, Lynx Point), as fastboot=1 doesn't work for S4 resume, only
> normal boot. Therefore, there are no issues on S4 wake after
> hibernate. Backlight controls etc. work as expected; just like
> fastboot=0.
I think fastboot should work the same for s4 resume as boot, but
only if your boot kernel doesn't load i915.ko. That way the
resuming kernel will directly take over from the BIOS programmed
display configuration. OTOH if the boot kernel loads i915 then
it will shut down all displays before handing control over to
the resuming kernel.
>
> I have applied "[1/2] drm/i915: Enable fastset for non-boot modesets"
> by Maarten, but that doesn't give me fastboot for S4 resume aswell.
> Same behavior as unpatched on my system.
>
> Please let me know, when there is more I can test.
>
> Cheers,
> Tolga
>
> > > +
> > > + val = lpt_hz_to_pwm(connector, freq);
> > > + } else
> > > + val = lpt_get_backlight(connector);
> > > val = intel_panel_compute_brightness(connector, val);
> > > panel->backlight.level = clamp(val, panel->backlight.min,
> > > panel->backlight.max);
> > >
> > > - panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> > > + if (cpu_mode) {
> > > + u32 tmp;
> > > +
> > > + /* Use PWM mode, instead of cpu clock */
> > > + lpt_set_backlight(connector->base.state,
> > > panel->backlight.level);
> > > + I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1 |
> > > BLM_PCH_OVERRIDE_ENABLE);
> > > +
> > > + tmp = I915_READ(BLC_PWM_CPU_CTL2);
> > > + I915_WRITE(BLC_PWM_CPU_CTL2, tmp & ~BLM_PWM_ENABLE);
> > > + }
> > >
> > > return 0;
> > > }
> > > --
> > > 2.19.1
> > >
> > >
Re: [Intel-gfx] [PATCH i-g-t 3/4] Add v3d helper library
On Wed, Nov 14, 2018 at 02:28:31PM -0800, Eric Anholt wrote:
> Just a few little ioctl wrappers that v3d tests will use.
>
> Signed-off-by: Eric Anholt
Acked-by: Petri Latvala
> ---
> lib/Makefile.sources | 2 +
> lib/drmtest.c| 3 +
> lib/drmtest.h| 1 +
> lib/igt_v3d.c| 130 +++
> lib/igt_v3d.h| 46 +++
> lib/meson.build | 1 +
> 6 files changed, 183 insertions(+)
> create mode 100644 lib/igt_v3d.c
> create mode 100644 lib/igt_v3d.h
>
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index e98989ff8ed9..808b9617eca2 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -107,6 +107,8 @@ lib_source_list = \
> igt_syncobj.h \
> igt_psr.c \
> igt_psr.h \
> + igt_v3d.c \
> + igt_v3d.h \
> $(NULL)
>
> .PHONY: version.h.tmp
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index fee9d33ad2a5..d2aa1c19154f 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -202,6 +202,7 @@ static const struct module {
> } modules[] = {
> { DRIVER_AMDGPU, "amdgpu" },
> { DRIVER_INTEL, "i915", modprobe_i915 },
> + { DRIVER_V3D, "v3d" },
> { DRIVER_VC4, "vc4" },
> { DRIVER_VGEM, "vgem" },
> { DRIVER_VIRTIO, "virtio-gpu" },
> @@ -340,6 +341,8 @@ static const char *chipset_to_str(int chipset)
> switch (chipset) {
> case DRIVER_INTEL:
> return "intel";
> + case DRIVER_V3D:
> + return "v3d";
> case DRIVER_VC4:
> return "vc4";
> case DRIVER_VGEM:
> diff --git a/lib/drmtest.h b/lib/drmtest.h
> index 949865ee54dd..96ee517e2ec1 100644
> --- a/lib/drmtest.h
> +++ b/lib/drmtest.h
> @@ -43,6 +43,7 @@
> #define DRIVER_VGEM (1 << 2)
> #define DRIVER_VIRTIO(1 << 3)
> #define DRIVER_AMDGPU(1 << 4)
> +#define DRIVER_V3D (1 << 5)
> /*
> * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> * with vgem as well as a supported driver, you can end up with a
> diff --git a/lib/igt_v3d.c b/lib/igt_v3d.c
> new file mode 100644
> index ..1a5ede1bd5fc
> --- /dev/null
> +++ b/lib/igt_v3d.c
> @@ -0,0 +1,130 @@
> +/*
> + * Copyright © 2016 Broadcom
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "drmtest.h"
> +#include "igt_aux.h"
> +#include "igt_core.h"
> +#include "igt_v3d.h"
> +#include "ioctl_wrappers.h"
> +#include "intel_reg.h"
> +#include "intel_chipset.h"
> +#include "v3d_drm.h"
> +
> +#if NEW_CONTEXT_PARAM_NO_ERROR_CAPTURE_API
> +#define LOCAL_CONTEXT_PARAM_NO_ERROR_CAPTURE 0x4
> +#endif
> +
> +/**
> + * SECTION:igt_v3d
> + * @short_description: V3D support library
> + * @title: V3D
> + * @include: igt.h
> + *
> + * This library provides various auxiliary helper functions for writing V3D
> + * tests.
> + */
> +
> +struct v3d_bo *
> +igt_v3d_create_bo(int fd, size_t size)
> +{
> + struct v3d_bo *bo = calloc(1, sizeof(*bo));
> +
> + struct drm_v3d_create_bo create = {
> + .size = size,
> + };
> +
> + do_ioctl(fd, DRM_IOCTL_V3D_CREATE_BO, );
> +
> + bo->handle = create.handle;
> + bo->offset = create.offset;
> + bo->size = size;
> +
> + return bo;
> +}
> +
> +void
> +igt_v3d_free_bo(int fd, struct v3d_bo *bo)
> +{
> + if (bo->map)
> + munmap(bo->map, bo->size);
> + gem_close(fd, bo->handle);
> + free(bo);
> +}
> +
> +uint32_t
> +igt_v3d_get_bo_offset(int fd, uint32_t handle)
> +{
> + struct drm_v3d_get_bo_offset get = {
> + .handle = handle,
> + };
> +
> + do_ioctl(fd, DRM_IOCTL_V3D_GET_BO_OFFSET, );
> +
> + return
Re: [Intel-gfx] [PATCH] drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
Quoting Hans Holmberg (2018-11-21 09:54:23) > From: Hans Holmberg > > There is no need to rebuild i915_gpu_error.o when the version string > changes as the version is available in init_utsname()->release. > > Signed-off-by: Hans Holmberg > --- > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > b/drivers/gpu/drm/i915/i915_gpu_error.c > index 8762d17b6659..958e1484a3dd 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -27,7 +27,7 @@ > * > */ > > -#include > +#include > #include > #include > #include > @@ -650,7 +650,7 @@ int i915_error_state_to_str(struct > drm_i915_error_state_buf *m, > > if (*error->error_msg) > err_printf(m, "%s\n", error->error_msg); > - err_printf(m, "Kernel: " UTS_RELEASE "\n"); > + err_printf(m, "Kernel: %s\n", init_utsname()->release); Should we take some more info from init_utsname, plagiarising dump_stack, err_printf(m, :Kernel: %s %.*s\n", init_utsname()->release, (int)strcspn(init_utsname()->version, " "), init_utsname()->version); -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/4] v3d: Import the V3D DRM UAPI header.
On Wed, Nov 14, 2018 at 02:28:30PM -0800, Eric Anholt wrote:
> Copied from make headers_install at drm-misc-next 783195ec1cad
> ("drm/syncobj: disable the timeline UAPI for now v2")
>
> Signed-off-by: Eric Anholt
Acked-by: Petri Latvala
> ---
> include/drm-uapi/v3d_drm.h | 204 +
> 1 file changed, 204 insertions(+)
> create mode 100644 include/drm-uapi/v3d_drm.h
>
> diff --git a/include/drm-uapi/v3d_drm.h b/include/drm-uapi/v3d_drm.h
> new file mode 100644
> index ..f446656d00b1
> --- /dev/null
> +++ b/include/drm-uapi/v3d_drm.h
> @@ -0,0 +1,204 @@
> +/*
> + * Copyright © 2014-2018 Broadcom
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef _V3D_DRM_H_
> +#define _V3D_DRM_H_
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +#define DRM_V3D_SUBMIT_CL 0x00
> +#define DRM_V3D_WAIT_BO 0x01
> +#define DRM_V3D_CREATE_BO 0x02
> +#define DRM_V3D_MMAP_BO 0x03
> +#define DRM_V3D_GET_PARAM 0x04
> +#define DRM_V3D_GET_BO_OFFSET 0x05
> +
> +#define DRM_IOCTL_V3D_SUBMIT_CL DRM_IOWR(DRM_COMMAND_BASE +
> DRM_V3D_SUBMIT_CL, struct drm_v3d_submit_cl)
> +#define DRM_IOCTL_V3D_WAIT_BO DRM_IOWR(DRM_COMMAND_BASE +
> DRM_V3D_WAIT_BO, struct drm_v3d_wait_bo)
> +#define DRM_IOCTL_V3D_CREATE_BO DRM_IOWR(DRM_COMMAND_BASE +
> DRM_V3D_CREATE_BO, struct drm_v3d_create_bo)
> +#define DRM_IOCTL_V3D_MMAP_BO DRM_IOWR(DRM_COMMAND_BASE +
> DRM_V3D_MMAP_BO, struct drm_v3d_mmap_bo)
> +#define DRM_IOCTL_V3D_GET_PARAM DRM_IOWR(DRM_COMMAND_BASE +
> DRM_V3D_GET_PARAM, struct drm_v3d_get_param)
> +#define DRM_IOCTL_V3D_GET_BO_OFFSET DRM_IOWR(DRM_COMMAND_BASE +
> DRM_V3D_GET_BO_OFFSET, struct drm_v3d_get_bo_offset)
> +
> +/**
> + * struct drm_v3d_submit_cl - ioctl argument for submitting commands to the
> 3D
> + * engine.
> + *
> + * This asks the kernel to have the GPU execute an optional binner
> + * command list, and a render command list.
> + */
> +struct drm_v3d_submit_cl {
> + /* Pointer to the binner command list.
> + *
> + * This is the first set of commands executed, which runs the
> + * coordinate shader to determine where primitives land on the screen,
> + * then writes out the state updates and draw calls necessary per tile
> + * to the tile allocation BO.
> + *
> + * This BCL will block on any previous BCL submitted on the
> + * same FD, but not on any RCL or BCLs submitted by other
> + * clients -- that is left up to the submitter to control
> + * using in_sync_bcl if necessary.
> + */
> + __u32 bcl_start;
> +
> + /** End address of the BCL (first byte after the BCL) */
> + __u32 bcl_end;
> +
> + /* Offset of the render command list.
> + *
> + * This is the second set of commands executed, which will either
> + * execute the tiles that have been set up by the BCL, or a fixed set
> + * of tiles (in the case of RCL-only blits).
> + *
> + * This RCL will block on this submit's BCL, and any previous
> + * RCL submitted on the same FD, but not on any RCL or BCLs
> + * submitted by other clients -- that is left up to the
> + * submitter to control using in_sync_rcl if necessary.
> + */
> + __u32 rcl_start;
> +
> + /** End address of the RCL (first byte after the RCL) */
> + __u32 rcl_end;
> +
> + /** An optional sync object to wait on before starting the BCL. */
> + __u32 in_sync_bcl;
> + /** An optional sync object to wait on before starting the RCL. */
> + __u32 in_sync_rcl;
> + /** An optional sync object to place the completion fence in. */
> + __u32
Re: [Intel-gfx] [PATCH i-g-t 4/4] igt/v3d_*: Add new tests for the V3D UABI.
On Wed, Nov 14, 2018 at 02:28:32PM -0800, Eric Anholt wrote: > These are basic non-rendering tests of the UABI. > > Signed-off-by: Eric Anholt > --- > lib/igt_v3d.c | 4 -- > tests/Makefile.am | 2 + > tests/Makefile.sources| 6 +++ > tests/meson.build | 3 ++ > tests/v3d_ci/README | 26 + > tests/v3d_ci/v3d.testlist | 6 +++ > tests/v3d_get_bo_offset.c | 78 ++ > tests/v3d_get_param.c | 80 +++ > tests/v3d_mmap.c | 55 +++ Do you need a separate directory for v3d or can you use the vc4 directory for v3d as well? Renamed to 'broadcom-ci' maybe? > 9 files changed, 256 insertions(+), 4 deletions(-) > create mode 100644 tests/v3d_ci/README > create mode 100644 tests/v3d_ci/v3d.testlist > create mode 100644 tests/v3d_get_bo_offset.c > create mode 100644 tests/v3d_get_param.c > create mode 100644 tests/v3d_mmap.c > > diff --git a/lib/igt_v3d.c b/lib/igt_v3d.c > index 1a5ede1bd5fc..619c072c0e47 100644 > --- a/lib/igt_v3d.c > +++ b/lib/igt_v3d.c > @@ -40,10 +40,6 @@ > #include "intel_chipset.h" > #include "v3d_drm.h" > > -#if NEW_CONTEXT_PARAM_NO_ERROR_CAPTURE_API > -#define LOCAL_CONTEXT_PARAM_NO_ERROR_CAPTURE 0x4 > -#endif > - > /** > * SECTION:igt_v3d > * @short_description: V3D support library > diff --git a/tests/Makefile.am b/tests/Makefile.am > index 3d1ce0bc1af8..a6b2ba51ea4f 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -14,6 +14,8 @@ if BUILD_VC4 > TESTS_progs += $(VC4_TESTS) > endif > > +TESTS_progs += $(V3D_TESTS) > + > if HAVE_CHAMELIUM > TESTS_progs += \ > kms_chamelium \ > diff --git a/tests/Makefile.sources b/tests/Makefile.sources > index d007ebc74ab9..3ed60e7c30c7 100644 > --- a/tests/Makefile.sources > +++ b/tests/Makefile.sources > @@ -15,6 +15,12 @@ VC4_TESTS = \ > vc4_wait_seqno \ > $(NULL) > > +V3D_TESTS = \ > + v3d_get_bo_offset \ > + v3d_get_param \ > + v3d_mmap \ > + $(NULL) > + > AMDGPU_TESTS = \ > amdgpu/amd_basic \ > amdgpu/amd_cs_nop \ > diff --git a/tests/meson.build b/tests/meson.build > index 3020f7984d7a..4472536aef65 100644 > --- a/tests/meson.build > +++ b/tests/meson.build > @@ -85,6 +85,9 @@ test_progs = [ > 'syncobj_wait', > 'template', > 'tools_test', > + 'v3d_get_bo_offset', > + 'v3d_get_param', > + 'v3d_mmap', > 'vc4_create_bo', > 'vc4_dmabuf_poll', > 'vc4_label_bo', > diff --git a/tests/v3d_ci/README b/tests/v3d_ci/README > new file mode 100644 > index ..e03c552fb972 > --- /dev/null > +++ b/tests/v3d_ci/README > @@ -0,0 +1,26 @@ > +This directory contains test lists to be used for v3d's DRM support. The > files > +are passed to piglit with the --test-list parameter directly. Note to self: Change this piglit reference to igt_runner (or both) in intel-ci/README... -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
Quoting Hans Holmberg (2018-11-21 11:54:23) > From: Hans Holmberg > > There is no need to rebuild i915_gpu_error.o when the version string > changes as the version is available in init_utsname()->release. > > Signed-off-by: Hans Holmberg Seems reasonable to me. Reviewed-by: Joonas Lahtinen Out of curiosity, are you by any chance hashing the i915_gpu_error.o file (or the contents elsewhere) for some purpose? Regards, Joonas > --- > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > b/drivers/gpu/drm/i915/i915_gpu_error.c > index 8762d17b6659..958e1484a3dd 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -27,7 +27,7 @@ > * > */ > > -#include > +#include > #include > #include > #include > @@ -650,7 +650,7 @@ int i915_error_state_to_str(struct > drm_i915_error_state_buf *m, > > if (*error->error_msg) > err_printf(m, "%s\n", error->error_msg); > - err_printf(m, "Kernel: " UTS_RELEASE "\n"); > + err_printf(m, "Kernel: %s\n", init_utsname()->release); > ts = ktime_to_timespec64(error->time); > err_printf(m, "Time: %lld s %ld us\n", >(s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC); > -- > 2.17.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Synchronize hpd work in i915_hpd_storm_ctl_show()
On Tue, Nov 20, 2018 at 07:37:17PM -0500, Lyude Paul wrote: > While trying to add a chamelium test for short HPD IRQs, I ran into > issues where a hotplug storm would be triggered, but the point at which > it would be reported by the kernel would be after igt actually finished > checking i915_hpd_storm_ctl's status. So, fix this by simply > synchronizing our IRQ work, dig_port_work, and hotplug_work before > printing out the HPD storm status in i915_hpd_storm_ctl_show(). > > Signed-off-by: Lyude Paul > Cc: Ville Syrjälä Makes sense. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/i915_debugfs.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 69447c68b9af..af4268a6d2d9 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -4592,6 +4592,13 @@ static int i915_hpd_storm_ctl_show(struct seq_file *m, > void *data) > struct drm_i915_private *dev_priv = m->private; > struct i915_hotplug *hotplug = _priv->hotplug; > > + /* Synchronize with everything first in case there's been an HPD > + * storm, but we haven't finished handling it in the kernel yet > + */ > + synchronize_irq(dev_priv->drm.irq); > + flush_work(_priv->hotplug.dig_port_work); > + flush_work(_priv->hotplug.hotplug_work); > + > seq_printf(m, "Threshold: %d\n", hotplug->hpd_storm_threshold); > seq_printf(m, "Detected: %s\n", > yesno(delayed_work_pending(>reenable_work))); > -- > 2.19.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: avoid rebuilding i915_gpu_error.o on version string updates
On Wed, 21 Nov 2018, Hans Holmberg wrote: > From: Hans Holmberg > > There is no need to rebuild i915_gpu_error.o when the version string > changes as the version is available in init_utsname()->release. > > Signed-off-by: Hans Holmberg Nice! Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > b/drivers/gpu/drm/i915/i915_gpu_error.c > index 8762d17b6659..958e1484a3dd 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -27,7 +27,7 @@ > * > */ > > -#include > +#include > #include > #include > #include > @@ -650,7 +650,7 @@ int i915_error_state_to_str(struct > drm_i915_error_state_buf *m, > > if (*error->error_msg) > err_printf(m, "%s\n", error->error_msg); > - err_printf(m, "Kernel: " UTS_RELEASE "\n"); > + err_printf(m, "Kernel: %s\n", init_utsname()->release); > ts = ktime_to_timespec64(error->time); > err_printf(m, "Time: %lld s %ld us\n", > (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC); -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC 4/5] drm/amdgpu: Add accounting of command submission via DRM cgroup
Am 20.11.18 um 21:57 schrieb Eric Anholt: Kenny Ho writes: Account for the number of command submitted to amdgpu by type on a per cgroup basis, for the purpose of profiling/monitoring applications. For profiling other drivers, I've used perf tracepoints, which let you get useful timelines of multiple events in the driver. Have you made use of this stat for productive profiling? Yes, but this is not related to profiling at all. What we want to do is to limit the resource usage of processes. Regards, Christian. ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC 5/5] drm/amdgpu: Add accounting of buffer object creation request via DRM cgroup
Am 20.11.18 um 19:58 schrieb Kenny Ho:
Account for the total size of buffer object requested to amdgpu by
buffer type on a per cgroup basis.
x prefix in the control file name x.bo_requested.amd.stat signify
experimental.
Change-Id: Ifb680c4bcf3652879a7a659510e25680c2465cf6
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c | 56 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 13 +
include/uapi/drm/amdgpu_drm.h | 24 ++---
4 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
index 853b77532428..e3d98ed01b79 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
@@ -7,6 +7,57 @@
#include "amdgpu_ring.h"
#include "amdgpu_drmcgrp.h"
+void amdgpu_drmcgrp_count_bo_req(struct task_struct *task, struct drm_device *dev,
+ u32 domain, unsigned long size)
+{
+ struct drmcgrp *drmcgrp = get_drmcgrp(task);
+ struct drmcgrp_device_resource *ddr;
+ struct drmcgrp *p;
+ struct amd_drmcgrp_dev_resource *a_ddr;
+int i;
+
+ if (drmcgrp == NULL)
+ return;
+
+ ddr = drmcgrp->dev_resources[dev->primary->index];
+
+ mutex_lock(>ddev->mutex);
+ for (p = drmcgrp; p != NULL; p = parent_drmcgrp(drmcgrp)) {
+ a_ddr = ddr_amdddr(p->dev_resources[dev->primary->index]);
+
+ for (i = 0; i < __MAX_AMDGPU_MEM_DOMAIN; i++)
+ if ( (1 << i) & domain)
+ a_ddr->bo_req_count[i] += size;
+ }
+ mutex_unlock(>ddev->mutex);
+}
+
+int amd_drmcgrp_bo_req_stat_read(struct seq_file *sf, void *v)
+{
+ struct drmcgrp *drmcgrp = css_drmcgrp(seq_css(sf));
+ struct drmcgrp_device_resource *ddr = NULL;
+ struct amd_drmcgrp_dev_resource *a_ddr = NULL;
+ int i, j;
+
+ seq_puts(sf, "---\n");
+ for (i = 0; i < MAX_DRM_DEV; i++) {
+ ddr = drmcgrp->dev_resources[i];
+
+ if (ddr == NULL || ddr->ddev->vid != amd_drmcgrp_vendor_id)
+ continue;
+
+ a_ddr = ddr_amdddr(ddr);
+
+ seq_printf(sf, "card%d:\n", i);
+ for (j = 0; j < __MAX_AMDGPU_MEM_DOMAIN; j++)
+ seq_printf(sf, " %s: %llu\n", amdgpu_mem_domain_names[j],
a_ddr->bo_req_count[j]);
+ }
+
+ return 0;
+}
+
+
+
void amdgpu_drmcgrp_count_cs(struct task_struct *task, struct drm_device *dev,
enum amdgpu_ring_type r_type)
{
@@ -55,6 +106,11 @@ int amd_drmcgrp_cmd_submit_accounting_read(struct seq_file
*sf, void *v)
struct cftype files[] = {
+ {
+ .name = "x.bo_requested.amd.stat",
+ .seq_show = amd_drmcgrp_bo_req_stat_read,
+ .flags = CFTYPE_NOT_ON_ROOT,
+ },
{
.name = "x.cmd_submitted.amd.stat",
.seq_show = amd_drmcgrp_cmd_submit_accounting_read,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
index f894a9a1059f..8b9d61e47dde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
@@ -11,10 +11,13 @@
struct amd_drmcgrp_dev_resource {
struct drmcgrp_device_resource ddr;
u64 cs_count[__MAX_AMDGPU_RING_TYPE];
+ u64 bo_req_count[__MAX_AMDGPU_MEM_DOMAIN];
};
void amdgpu_drmcgrp_count_cs(struct task_struct *task, struct drm_device *dev,
enum amdgpu_ring_type r_type);
+void amdgpu_drmcgrp_count_bo_req(struct task_struct *task, struct drm_device
*dev,
+ u32 domain, unsigned long size);
static inline struct amd_drmcgrp_dev_resource *ddr_amdddr(struct drmcgrp_device_resource *ddr)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 7b3d1ebda9df..339e1d3edad8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -31,6 +31,17 @@
#include
#include "amdgpu.h"
#include "amdgpu_display.h"
+#include "amdgpu_drmcgrp.h"
+
+char const *amdgpu_mem_domain_names[] = {
+ [AMDGPU_MEM_DOMAIN_CPU] = "cpu",
+ [AMDGPU_MEM_DOMAIN_GTT] = "gtt",
+ [AMDGPU_MEM_DOMAIN_VRAM]= "vram",
+ [AMDGPU_MEM_DOMAIN_GDS] = "gds",
+ [AMDGPU_MEM_DOMAIN_GWS] = "gws",
+ [AMDGPU_MEM_DOMAIN_OA] = "oa",
+ [__MAX_AMDGPU_MEM_DOMAIN] = "_max"
+};
void amdgpu_gem_object_free(struct drm_gem_object *gobj)
{
@@ -52,6 +63,8 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev,
unsigned long size,
struct amdgpu_bo_param bp;
int r;
+ amdgpu_drmcgrp_count_bo_req(current, adev->ddev, initial_domain, size);
+
memset(, 0,
Re: [Intel-gfx] [PATCH] drm/atomic: Fix the early return in drm_atomic_set_mode_for_crtc()
On Tue, Nov 20, 2018 at 07:55:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The early return in drm_atomic_set_mode_for_crtc() isn't quite
> right. It would mistakenly return and fail to update
> crtc_state->enable if someone actually tried to set a zeroed
> mode on a currently disabled crtc. I suppose that should never
> happen but better safe than sorry.
>
> Additionally the early return will not be taken if we're trying to
> disable an already disable crtc. While that is not actually harmful
> it is inconsistent, so let's handle that case as well.
>
> Signed-off-by: Ville Syrjälä
Do we have an igt for this? I.e. trying to set a all-0 mode for a disabled
CRTC and seeing what happens ...
Patch itself looks fine, has my r-b if the igt materializes.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 86ac33922b09..ed0ea82e8a1d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -68,8 +68,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
> *state,
> struct drm_mode_modeinfo umode;
>
> /* Early return for no change. */
> - if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
> - return 0;
> + if (state->enable) {
> + if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
> + return 0;
> + } else {
> + if (!mode)
> + return 0;
> + }
>
> drm_property_blob_put(state->mode_blob);
> state->mode_blob = NULL;
> --
> 2.18.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC 4/5] drm/amdgpu: Add accounting of command submission via DRM cgroup
Am 20.11.18 um 19:58 schrieb Kenny Ho:
Account for the number of command submitted to amdgpu by type on a per
cgroup basis, for the purpose of profiling/monitoring applications.
x prefix in the control file name x.cmd_submitted.amd.stat signify
experimental.
Change-Id: Ibc22e5bda600f54fe820fe0af5400ca348691550
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c | 54 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h | 5 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c| 15 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h| 5 +-
5 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 663043c8f0f5..b448160aed89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -33,6 +33,7 @@
#include "amdgpu_trace.h"
#include "amdgpu_gmc.h"
#include "amdgpu_gem.h"
+#include "amdgpu_drmcgrp.h"
static int amdgpu_cs_user_fence_chunk(struct amdgpu_cs_parser *p,
struct drm_amdgpu_cs_chunk_fence *data,
@@ -1275,6 +1276,7 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
union drm_amdgpu_cs *cs = data;
struct amdgpu_cs_parser parser = {};
bool reserved_buffers = false;
+ struct amdgpu_ring *ring;
int i, r;
if (!adev->accel_working)
@@ -1317,6 +1319,9 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
if (r)
goto out;
+ ring = to_amdgpu_ring(parser.entity->rq->sched);
+ amdgpu_drmcgrp_count_cs(current, dev, ring->funcs->type);
+
r = amdgpu_cs_submit(, cs);
out:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
index ed8aac17769c..853b77532428 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
@@ -1,11 +1,65 @@
// SPDX-License-Identifier: MIT
// Copyright 2018 Advanced Micro Devices, Inc.
#include
+#include
#include
#include
+#include "amdgpu_ring.h"
#include "amdgpu_drmcgrp.h"
+void amdgpu_drmcgrp_count_cs(struct task_struct *task, struct drm_device *dev,
+ enum amdgpu_ring_type r_type)
+{
+ struct drmcgrp *drmcgrp = get_drmcgrp(task);
+ struct drmcgrp_device_resource *ddr;
+ struct drmcgrp *p;
+ struct amd_drmcgrp_dev_resource *a_ddr;
+
+ if (drmcgrp == NULL)
+ return;
+
+ ddr = drmcgrp->dev_resources[dev->primary->index];
+
+ mutex_lock(>ddev->mutex);
+ for (p = drmcgrp; p != NULL; p = parent_drmcgrp(drmcgrp)) {
+ a_ddr = ddr_amdddr(p->dev_resources[dev->primary->index]);
+
+ a_ddr->cs_count[r_type]++;
+ }
+ mutex_unlock(>ddev->mutex);
+}
+
+int amd_drmcgrp_cmd_submit_accounting_read(struct seq_file *sf, void *v)
+{
+ struct drmcgrp *drmcgrp = css_drmcgrp(seq_css(sf));
+ struct drmcgrp_device_resource *ddr = NULL;
+ struct amd_drmcgrp_dev_resource *a_ddr = NULL;
+ int i, j;
+
+ seq_puts(sf, "---\n");
+ for (i = 0; i < MAX_DRM_DEV; i++) {
+ ddr = drmcgrp->dev_resources[i];
+
+ if (ddr == NULL || ddr->ddev->vid != amd_drmcgrp_vendor_id)
+ continue;
+
+ a_ddr = ddr_amdddr(ddr);
+
+ seq_printf(sf, "card%d:\n", i);
+ for (j = 0; j < __MAX_AMDGPU_RING_TYPE; j++)
+ seq_printf(sf, " %s: %llu\n", amdgpu_ring_names[j],
a_ddr->cs_count[j]);
+ }
+
+ return 0;
+}
+
+
struct cftype files[] = {
+ {
+ .name = "x.cmd_submitted.amd.stat",
+ .seq_show = amd_drmcgrp_cmd_submit_accounting_read,
+ .flags = CFTYPE_NOT_ON_ROOT,
+ },
{ } /* terminate */
};
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
index e2934b7a49f5..f894a9a1059f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
@@ -5,12 +5,17 @@
#define _AMDGPU_DRMCGRP_H
#include
+#include "amdgpu_ring.h"
/* for AMD specific DRM resources */
struct amd_drmcgrp_dev_resource {
struct drmcgrp_device_resource ddr;
+ u64 cs_count[__MAX_AMDGPU_RING_TYPE];
};
+void amdgpu_drmcgrp_count_cs(struct task_struct *task, struct drm_device *dev,
+ enum amdgpu_ring_type r_type);
+
static inline struct amd_drmcgrp_dev_resource *ddr_amdddr(struct
drmcgrp_device_resource *ddr)
{
return ddr ? container_of(ddr, struct amd_drmcgrp_dev_resource, ddr) :
NULL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index b70e85ec147d..1606f84d2334 100644
---
Re: [Intel-gfx] [PATCH RFC 3/5] drm/amdgpu: Add DRM cgroup support for AMD devices
Am 20.11.18 um 19:58 schrieb Kenny Ho:
Change-Id: Ib66c44ac1b1c367659e362a2fc05b6fbb3805876
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/Makefile | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7
drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c | 37 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h | 19 +++
include/drm/drmcgrp_vendors.h | 1 +
5 files changed, 67 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 138cb787d27e..5cf8048f2d75 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -186,4 +186,7 @@ amdgpu-y += $(AMD_DISPLAY_FILES)
endif
+#DRM cgroup controller
+amdgpu-y += amdgpu_drmcgrp.o
+
obj-$(CONFIG_DRM_AMDGPU)+= amdgpu.o
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 30bc345d6fdf..ad0373f83ed3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2645,6 +2646,12 @@ int amdgpu_device_init(struct amdgpu_device *adev,
goto failed;
}
+ /* TODO:docs */
+ if (drmcgrp_vendors[amd_drmcgrp_vendor_id] == NULL)
+ drmcgrp_register_vendor(_drmcgrp_vendor,
amd_drmcgrp_vendor_id);
+
+ drmcgrp_register_device(adev->ddev, amd_drmcgrp_vendor_id);
+
Well that is most likely racy because it is possible that multiple
instances of the driver initialize at the same time.
Better put the call to drmcgrp_register_vendor() into the module init
section.
Christian.
return 0;
failed:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
new file mode 100644
index ..ed8aac17769c
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: MIT
+// Copyright 2018 Advanced Micro Devices, Inc.
+#include
+#include
+#include
+#include "amdgpu_drmcgrp.h"
+
+struct cftype files[] = {
+ { } /* terminate */
+};
+
+struct cftype *drmcgrp_amd_get_cftypes(void)
+{
+ return files;
+}
+
+struct drmcgrp_device_resource *amd_drmcgrp_alloc_dev_resource(void)
+{
+ struct amd_drmcgrp_dev_resource *a_ddr;
+
+ a_ddr = kzalloc(sizeof(struct amd_drmcgrp_dev_resource), GFP_KERNEL);
+ if (!a_ddr)
+ return ERR_PTR(-ENOMEM);
+
+ return _ddr->ddr;
+}
+
+void amd_drmcgrp_free_dev_resource(struct drmcgrp_device_resource *ddr)
+{
+ kfree(ddr_amdddr(ddr));
+}
+
+struct drmcgrp_vendor amd_drmcgrp_vendor = {
+ .get_cftypes = drmcgrp_amd_get_cftypes,
+ .alloc_dev_resource = amd_drmcgrp_alloc_dev_resource,
+ .free_dev_resource = amd_drmcgrp_free_dev_resource,
+};
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
new file mode 100644
index ..e2934b7a49f5
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drmcgrp.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ */
+#ifndef _AMDGPU_DRMCGRP_H
+#define _AMDGPU_DRMCGRP_H
+
+#include
+
+/* for AMD specific DRM resources */
+struct amd_drmcgrp_dev_resource {
+ struct drmcgrp_device_resource ddr;
+};
+
+static inline struct amd_drmcgrp_dev_resource *ddr_amdddr(struct
drmcgrp_device_resource *ddr)
+{
+ return ddr ? container_of(ddr, struct amd_drmcgrp_dev_resource, ddr) :
NULL;
+}
+
+#endif /* _AMDGPU_DRMCGRP_H */
diff --git a/include/drm/drmcgrp_vendors.h b/include/drm/drmcgrp_vendors.h
index b04d8649851b..6cfbf1825344 100644
--- a/include/drm/drmcgrp_vendors.h
+++ b/include/drm/drmcgrp_vendors.h
@@ -3,5 +3,6 @@
*/
#if IS_ENABLED(CONFIG_CGROUP_DRM)
+DRMCGRP_VENDOR(amd)
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices
Am 20.11.18 um 19:58 schrieb Kenny Ho:
Since many parts of the DRM subsystem has vendor-specific
implementations, we introduce mechanisms for vendor to register their
specific resources and control files to the DRM cgroup subsystem. A
vendor will register itself with the DRM cgroup subsystem first before
registering individual DRM devices to the cgroup subsystem.
In addition to the cgroup_subsys_state that is common to all DRM
devices, a device-specific state is introduced and it is allocated
according to the vendor of the device.
Mhm, it's most likely just a naming issue but I think we should drop the
term "vendor" here and rather use "driver" instead.
Background is that both Intel as well as AMD have multiple drivers for
different hardware generations and we certainly don't want to handle all
drivers from one vendor the same way.
Christian.
Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
Signed-off-by: Kenny Ho
---
include/drm/drm_cgroup.h | 39
include/drm/drmcgrp_vendors.h | 7 +++
include/linux/cgroup_drm.h| 26 +++
kernel/cgroup/drm.c | 84 +++
4 files changed, 156 insertions(+)
create mode 100644 include/drm/drm_cgroup.h
create mode 100644 include/drm/drmcgrp_vendors.h
diff --git a/include/drm/drm_cgroup.h b/include/drm/drm_cgroup.h
new file mode 100644
index ..26cbea7059a6
--- /dev/null
+++ b/include/drm/drm_cgroup.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ */
+#ifndef __DRM_CGROUP_H__
+#define __DRM_CGROUP_H__
+
+#define DRMCGRP_VENDOR(_x) _x ## _drmcgrp_vendor_id,
+enum drmcgrp_vendor_id {
+#include
+ DRMCGRP_VENDOR_COUNT,
+};
+#undef DRMCGRP_VENDOR
+
+#define DRMCGRP_VENDOR(_x) extern struct drmcgrp_vendor _x ## _drmcgrp_vendor;
+#include
+#undef DRMCGRP_VENDOR
+
+
+
+#ifdef CONFIG_CGROUP_DRM
+
+extern struct drmcgrp_vendor *drmcgrp_vendors[];
+
+int drmcgrp_register_vendor(struct drmcgrp_vendor *vendor, enum
drmcgrp_vendor_id id);
+int drmcgrp_register_device(struct drm_device *device, enum drmcgrp_vendor_id
id);
+
+#else
+static int drmcgrp_register_vendor(struct drmcgrp_vendor *vendor, enum
drmcgrp_vendor_id id)
+{
+ return 0;
+}
+
+static int drmcgrp_register_device(struct drm_device *device, enum
drmcgrp_vendor_id id)
+{
+ return 0;
+}
+
+#endif /* CONFIG_CGROUP_DRM */
+#endif /* __DRM_CGROUP_H__ */
diff --git a/include/drm/drmcgrp_vendors.h b/include/drm/drmcgrp_vendors.h
new file mode 100644
index ..b04d8649851b
--- /dev/null
+++ b/include/drm/drmcgrp_vendors.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ */
+#if IS_ENABLED(CONFIG_CGROUP_DRM)
+
+
+#endif
diff --git a/include/linux/cgroup_drm.h b/include/linux/cgroup_drm.h
index 79ab38b0f46d..a776662d9593 100644
--- a/include/linux/cgroup_drm.h
+++ b/include/linux/cgroup_drm.h
@@ -6,10 +6,36 @@
#ifdef CONFIG_CGROUP_DRM
+#include
#include
+#include
+#include
+
+/* limit defined per the way drm_minor_alloc operates */
+#define MAX_DRM_DEV (64 * DRM_MINOR_RENDER)
+
+struct drmcgrp_device {
+ enum drmcgrp_vendor_id vid;
+ struct drm_device *dev;
+ struct mutexmutex;
+};
+
+/* vendor-common resource counting goes here */
+/* this struct should be included in the vendor specific resource */
+struct drmcgrp_device_resource {
+ struct drmcgrp_device *ddev;
+};
+
+struct drmcgrp_vendor {
+ struct cftype *(*get_cftypes)(void);
+ struct drmcgrp_device_resource *(*alloc_dev_resource)(void);
+ void (*free_dev_resource)(struct drmcgrp_device_resource *dev_resource);
+};
+
struct drmcgrp {
struct cgroup_subsys_state css;
+ struct drmcgrp_device_resource *dev_resources[MAX_DRM_DEV];
};
static inline struct drmcgrp *css_drmcgrp(struct cgroup_subsys_state *css)
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index d9e194b9aead..f9630cc389bc 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -1,8 +1,30 @@
// SPDX-License-Identifier: MIT
// Copyright 2018 Advanced Micro Devices, Inc.
+#include
#include
#include
+#include
+#include
+#include
#include
+#include
+#include
+
+/* generate an array of drm cgroup vendor pointers */
+#define DRMCGRP_VENDOR(_x)[_x ## _drmcgrp_vendor_id] = NULL,
+struct drmcgrp_vendor *drmcgrp_vendors[] = {
+#include
+};
+#undef DRMCGRP_VENDOR
+EXPORT_SYMBOL(drmcgrp_vendors);
+
+static DEFINE_MUTEX(drmcgrp_mutex);
+
+/* indexed by drm_minor for access speed */
+static struct drmcgrp_device *known_drmcgrp_devs[MAX_DRM_DEV];
+
+static int max_minor;
+
static u64 drmcgrp_test_read(struct cgroup_subsys_state *css,
struct cftype *cft)
@@ -13,6 +35,12 @@ static u64 drmcgrp_test_read(struct cgroup_subsys_state *css,
static void drmcgrp_css_free(struct cgroup_subsys_state *css)
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging
On 21/11/2018 09:33, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-11-21 09:02:18) On 20/11/2018 18:18, Tvrtko Ursulin wrote: I can certainly send a patch for -DDEBUG, seems like that would be the correct thing to do for all selftests. I've changed my mind - I think it is more desirable to actually just do what this patch did and convert test start messages to pr_info. To enable all pr_debug by default, even if compiled with i915 debugging on, doesn't seem conceptually correct. There might be ones which are prohibitively noisy and in any case it would defeat the point of dynamic debug. Nah, I still consider this to be test infra debug noise, and pr_debug() quite apt for describing that. Shrug. A few lines in the see of noise, I don't see any harm but just bringing it to the same state as IGT run logs. And for the task you have, nothing more than a wild goose chase. That one has been parked for now, these are all just after effects. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging
Quoting Tvrtko Ursulin (2018-11-21 09:02:18) > > On 20/11/2018 18:18, Tvrtko Ursulin wrote: > > I can certainly send a patch for -DDEBUG, seems like that would be the > > correct thing to do for all selftests. > > I've changed my mind - I think it is more desirable to actually just do > what this patch did and convert test start messages to pr_info. > > To enable all pr_debug by default, even if compiled with i915 debugging > on, doesn't seem conceptually correct. There might be ones which are > prohibitively noisy and in any case it would defeat the point of dynamic > debug. Nah, I still consider this to be test infra debug noise, and pr_debug() quite apt for describing that. And for the task you have, nothing more than a wild goose chase. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: Avoid use-after-free iterating the gtt list
On 2018.11.21 09:20:19 +, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-11-21 02:29:21)
> > On 2018.11.20 20:24:38 +, Chris Wilson wrote:
> > > Found by smatch:
> > >
> > > drivers/gpu/drm/i915/gvt/gtt.c:2452 intel_vgpu_destroy_ggtt_mm() error:
> > > dereferencing freed memory 'pos'
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Zhenyu Wang
> > > ---
> > > drivers/gpu/drm/i915/gvt/gtt.c | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c
> > > b/drivers/gpu/drm/i915/gvt/gtt.c
> > > index 58e166effa45..c7103dd2d8d5 100644
> > > --- a/drivers/gpu/drm/i915/gvt/gtt.c
> > > +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> > > @@ -2447,10 +2447,11 @@ static void
> > > intel_vgpu_destroy_all_ppgtt_mm(struct intel_vgpu *vgpu)
> > >
> > > static void intel_vgpu_destroy_ggtt_mm(struct intel_vgpu *vgpu)
> > > {
> > > - struct intel_gvt_partial_pte *pos;
> > > + struct intel_gvt_partial_pte *pos, *next;
> > >
> > > - list_for_each_entry(pos,
> > > - >gtt.ggtt_mm->ggtt_mm.partial_pte_list, list)
> > > {
> > > + list_for_each_entry_safe(pos, next,
> > > +
> > > >gtt.ggtt_mm->ggtt_mm.partial_pte_list,
> > > + list) {
> > > gvt_dbg_mm("partial PTE update on hold 0x%lx : 0x%llx\n",
> > > pos->offset, pos->data);
> > > kfree(pos);
> >
> > Reviewed-by: Zhenyu Wang
>
> I presume you will take it via the gvt tree? Saves a backmerge for you.
Sure, will take it.
thanks
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Release power well if load DMC failed
On Wed, 21 Nov 2018, "Lee, Shawn C" wrote:
> On Tue, 20 Nov 2018, "Jani Nikula" wrote:
>>On Wed, 21 Nov 2018, "Lee, Shawn C" wrote:
>>> On Tue, 20 Nov 2018, "Jani Nikula" wrote:
> Driver obtain power well at intel_csr_ucode_init().
> And release it after load DMC firmware successful.
Correct.
> An issue happened when DMC was not found or failed to load. Power
> well would not be released and just output some error messages.
> Driver have to release power well properly to keep put/get balance.
No. We intentionally do not release it until dmc firmware load succeeds.
>>>
>>> If load DMC failed, we found DP phy was always on even without
>>> external display connected. So it looks like an expected behavior,
>>> right?
>>
>>I'll put it this way, we don't really go out of our way to support everything
>>without the DMC firmware. Every choice like this doubles the testing
>>requirements.
>>
>
> Understood. This is not a normal case (without DMC) on customer
> system. We just think it will be better to release power well if we
> already got it before.
Why are you supporting a non-DMC setup on a customer system? Don't do
it.
BR,
Jani.
>
>>Do you see issues with DMC firmware loaded? Do you have issues with loading
>>DMC firmware?
>
> No issue with DMC firmware loaded. Thanks!
>
>>
>>BR,
>>Jani.
>>
>>
>>>
See the comment in intel_csr_ucode_init(), as well as this in the branch
where dmc load fails:
dev_notice(dev_priv->drm.dev,
"Failed to load DMC firmware %s."
" Disabling runtime power management.\n",
csr->fw_path);
We don't support runtime pm without dmc on platforms with dmc.
BR,
Jani.
>
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Jose Roberto de Souza
> Cc: Cooper Chiou
>
> Signed-off-by: Lee, Shawn C
> ---
> drivers/gpu/drm/i915/intel_csr.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index a516697bf57d..8d04d7b6f00a 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -425,8 +425,6 @@ static void csr_load_work_fn(struct work_struct *work)
> if (dev_priv->csr.dmc_payload) {
> intel_csr_load_program(dev_priv);
>
> - intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
> -
> DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
>dev_priv->csr.fw_path,
>CSR_VERSION_MAJOR(csr->version), @@ -440,6 +438,7 @@
> static
> void csr_load_work_fn(struct work_struct *work)
> INTEL_UC_FIRMWARE_URL);
> }
>
> + intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
> release_firmware(fw);
> }
--
Jani Nikula, Intel Open Source Graphics Center
>>
>>--
>>Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Downgrade unknown CSR firmware warnings
On Fri, 16 Nov 2018, Lucas De Marchi wrote:
> Like it was done in commit 9e180d9991dc ("drm/i915: Downgrade unknown
> firmware warnings") for huc and guc: downgrade CSR firmware warnings. If
> we have released no firmware yet for a platform, stop scaring the
> consumer and merely note its expected absence.
>
> By simply removing the warning and early return we hit the condition
> with the appropriate message.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signed-off-by: Lucas De Marchi
*sigh*
This patch would not have been needed at all with patch 1/2.
The point was that we shouldn't proceed without the max fw size
set. Even with the module parameter. Because that would fail at the
firmware loading stage later.
If the warn was such a big deal, it should've been changed to a debug
message with an early return, not removed.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_csr.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index b4476d891fa3..a516697bf57d 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -496,9 +496,6 @@ void intel_csr_ucode_init(struct drm_i915_private
> *dev_priv)
> csr->fw_path = BXT_CSR_PATH;
> csr->required_version = BXT_CSR_VERSION_REQUIRED;
> csr->max_fw_size = BXT_CSR_MAX_FW_SIZE;
> - } else {
> - MISSING_CASE(INTEL_REVID(dev_priv));
> - return;
> }
>
> if (i915_modparams.dmc_firmware_path) {
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/15] drm/vblank: Allow dynamic per-crtc max_vblank_count
On Mon, Nov 12, 2018 at 06:59:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On i965gm we need to adjust max_vblank_count dynamically
> depending on whether the TV encoder is used or not. To
> that end add a per-crtc max_vblank_count that takes
> precedence over its device wide counterpart. The driver
> can now call drm_crtc_set_max_vblank_count() to configure
> the per-crtc value before calling drm_vblank_on().
>
> Also looks like there was some discussion about exynos needing
> similar treatment.
>
> Cc: sta...@vger.kernel.org
> Cc: Inki Dae
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_vblank.c | 39
> include/drm/drm_vblank.h | 8
> 2 files changed, 43 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 98e091175921..c3abbdca8aba 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -105,13 +105,20 @@ static void store_vblank(struct drm_device *dev,
> unsigned int pipe,
> write_sequnlock(>seqlock);
> }
>
> +static u32 drm_max_vblank_count(struct drm_device *dev, unsigned int pipe)
> +{
> + struct drm_vblank_crtc *vblank = >vblank[pipe];
> +
> + return vblank->max_vblank_count ?: dev->max_vblank_count;
> +}
> +
> /*
> * "No hw counter" fallback implementation of .get_vblank_counter() hook,
> * if there is no useable hardware frame counter available.
> */
> static u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int
> pipe)
> {
> - WARN_ON_ONCE(dev->max_vblank_count != 0);
> + WARN_ON_ONCE(drm_max_vblank_count(dev, pipe) != 0);
> return 0;
> }
>
> @@ -198,6 +205,7 @@ static void drm_update_vblank_count(struct drm_device
> *dev, unsigned int pipe,
> ktime_t t_vblank;
> int count = DRM_TIMESTAMP_MAXRETRIES;
> int framedur_ns = vblank->framedur_ns;
> + u32 max_vblank_count = drm_max_vblank_count(dev, pipe);
>
> /*
>* Interrupts were disabled prior to this call, so deal with counter
> @@ -216,9 +224,9 @@ static void drm_update_vblank_count(struct drm_device
> *dev, unsigned int pipe,
> rc = drm_get_last_vbltimestamp(dev, pipe, _vblank,
> in_vblank_irq);
> } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
>
> - if (dev->max_vblank_count != 0) {
> + if (max_vblank_count) {
> /* trust the hw counter when it's around */
> - diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
> + diff = (cur_vblank - vblank->last) & max_vblank_count;
> } else if (rc && framedur_ns) {
> u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
>
> @@ -258,7 +266,8 @@ static void drm_update_vblank_count(struct drm_device
> *dev, unsigned int pipe,
> pipe, vblank->count, diff, cur_vblank, vblank->last);
>
> if (diff == 0) {
> - WARN_ON_ONCE(cur_vblank != vblank->last);
> + WARN_ON_ONCE(max_vblank_count &&
> + cur_vblank != vblank->last);
Unrelated bugfix for this warning? Should be a separate patch I think, or
I'm missing something.
> return;
> }
>
> @@ -1204,6 +1213,28 @@ void drm_crtc_vblank_reset(struct drm_crtc *crtc)
> }
> EXPORT_SYMBOL(drm_crtc_vblank_reset);
>
> +/**
> + * drm_crtc_set_max_vblank_count - configure the hw max vblank counter value
> + * @crtc: CRTC in question
> + * @max_vblank_count: max hardware vblank counter value
> + *
> + * Update the maximum hardware vblank counter value for @crtc. Useful
> + * for hardware where the operation of the hardware vblank counter
> + * depends on the active display configuration.
> + *
> + * If used, must be called before drm_vblank_on().
I think we should check this at runtime with a WARN_ON. Plus make the
comment here a bit clearer that this is indeed for runtime adjusting of
the max_vblank_count, in cases where that depends upon the connected
outputs.
> + */
> +void drm_crtc_set_max_vblank_count(struct drm_crtc *crtc,
> +u32 max_vblank_count)
> +{
> + struct drm_device *dev = crtc->dev;
> + unsigned int pipe = drm_crtc_index(crtc);
> + struct drm_vblank_crtc *vblank = >vblank[pipe];
> +
> + vblank->max_vblank_count = max_vblank_count;
> +}
> +EXPORT_SYMBOL(drm_crtc_set_max_vblank_count);
> +
> /**
> * drm_crtc_vblank_on - enable vblank events on a CRTC
> * @crtc: CRTC in question
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index 6ad9630d4f48..ecb2cf9913e2 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -128,6 +128,12 @@ struct drm_vblank_crtc {
>* @last: Protected by _device.vbl_lock, used for wraparound
> handling.
>*/
> u32 last;
> + /**
> + * @max_vblank_count: Maximum value of the hardware vblank counter.
> +
Re: [Intel-gfx] [PATCH] drm/i915/ilk: Fix warning when reading emon_status with no output
Quoting Souza, Jose (2018-11-20 22:07:14) > On Mon, 2018-11-19 at 17:05 -0800, Rodrigo Vivi wrote: > > On Mon, Nov 19, 2018 at 03:01:01PM -0800, José Roberto de Souza > > wrote: > > > When there is no output no one will hold a runtime_pm reference > > > causing a warning when trying to read emom_status in debugfs. > > > > > > [22.756480] [ cut here ] > > > [22.756489] RPM wakelock ref not held during HW access > > > [22.756578] WARNING: CPU: 0 PID: 1058 at > > > drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 > > > [i915] > > > [22.756580] Modules linked in: snd_hda_codec_hdmi > > > snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp > > > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel > > > snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me > > > prime_numbers mei lpc_ich > > > [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0- > > > rc1-CI-Trybot_3219+ #1 > > > [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF > > > PC/304Ah, BIOS 786H1 v01.13 07/14/2011 > > > [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915] > > > [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 > > > 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 > > > 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 > > > c2 78 d0 2d > > > [22.756639] RSP: 0018:c9f1fd38 EFLAGS: 00010282 > > > [22.756642] RAX: RBX: 8801f7ab RCX: > > > 0006 > > > [22.756643] RDX: 0006 RSI: 8212886a RDI: > > > 820d6d57 > > > [22.756645] RBP: 00011020 R08: 43e3d1a8 R09: > > > > > > [22.756647] R10: c9f1fd80 R11: R12: > > > 0001 > > > [22.756649] R13: 8801f7ab0068 R14: 0001 R15: > > > 88020d53d188 > > > [22.756651] FS: 7f2878849980() GS:880213a0() > > > knlGS: > > > [22.756653] CS: 0010 DS: ES: CR0: 80050033 > > > [22.756655] CR2: 5638deedf028 CR3: 000203292001 CR4: > > > 000206f0 > > > [22.756657] Call Trace: > > > [22.756689] i915_mch_val+0x1b/0x60 [i915] > > > [22.756721] i915_emon_status+0x45/0xd0 [i915] > > > [22.756730] seq_read+0xdb/0x3c0 > > > [22.756736] ? lockdep_hardirqs_off+0x94/0xd0 > > > [22.756740] ? __slab_free+0x24e/0x510 > > > [22.756746] full_proxy_read+0x52/0x90 > > > [22.756752] __vfs_read+0x31/0x170 > > > [22.756759] ? do_sys_open+0x13b/0x240 > > > [22.756763] ? rcu_read_lock_sched_held+0x6f/0x80 > > > [22.756766] vfs_read+0x9e/0x140 > > > [22.756770] ksys_read+0x50/0xc0 > > > [22.756775] do_syscall_64+0x55/0x190 > > > [22.756781] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > [22.756783] RIP: 0033:0x7f28781dc34e > > > [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 > > > 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 > > > 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 > > > 41 54 55 49 > > > [22.756787] RSP: 002b:7ffd33fa0d08 EFLAGS: 0246 ORIG_RAX: > > > > > > [22.756790] RAX: ffda RBX: RCX: > > > 7f28781dc34e > > > [22.756792] RDX: 0200 RSI: 7ffd33fa0d50 RDI: > > > 0008 > > > [22.756794] RBP: 7ffd33fa0f60 R08: R09: > > > 0020 > > > [22.756796] R10: R11: 0246 R12: > > > 5638de45c2c0 > > > [22.756797] R13: 7ffd33fa14b0 R14: R15: > > > > > > [22.756806] irq event stamp: 47950 > > > [22.756811] hardirqs last enabled at (47949): [] > > > vprintk_emit+0x124/0x320 > > > [22.756813] hardirqs last disabled at (47950): [] > > > trace_hardirqs_off_thunk+0x1a/0x1c > > > [22.756816] softirqs last enabled at (47518): [] > > > __do_softirq+0x33a/0x4b9 > > > [22.756820] softirqs last disabled at (47479): [] > > > irq_exit+0xa9/0xc0 > > > [22.756858] WARNING: CPU: 0 PID: 1058 at > > > drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 > > > [i915] > > > [22.756860] ---[ end trace bf56fa7d6a3cbf7a ] > > > > > > Signed-off-by: José Roberto de Souza > > > > Reviewed-by: Rodrigo Vivi > > Thanks for the review, pushed to drm-intel-next-queued. I have been posting the fix for this for a few years. Cheers. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: Avoid use-after-free iterating the gtt list
Quoting Zhenyu Wang (2018-11-21 02:29:21)
> On 2018.11.20 20:24:38 +, Chris Wilson wrote:
> > Found by smatch:
> >
> > drivers/gpu/drm/i915/gvt/gtt.c:2452 intel_vgpu_destroy_ggtt_mm() error:
> > dereferencing freed memory 'pos'
> >
> > Signed-off-by: Chris Wilson
> > Cc: Zhenyu Wang
> > ---
> > drivers/gpu/drm/i915/gvt/gtt.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> > index 58e166effa45..c7103dd2d8d5 100644
> > --- a/drivers/gpu/drm/i915/gvt/gtt.c
> > +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> > @@ -2447,10 +2447,11 @@ static void intel_vgpu_destroy_all_ppgtt_mm(struct
> > intel_vgpu *vgpu)
> >
> > static void intel_vgpu_destroy_ggtt_mm(struct intel_vgpu *vgpu)
> > {
> > - struct intel_gvt_partial_pte *pos;
> > + struct intel_gvt_partial_pte *pos, *next;
> >
> > - list_for_each_entry(pos,
> > - >gtt.ggtt_mm->ggtt_mm.partial_pte_list, list) {
> > + list_for_each_entry_safe(pos, next,
> > + >gtt.ggtt_mm->ggtt_mm.partial_pte_list,
> > + list) {
> > gvt_dbg_mm("partial PTE update on hold 0x%lx : 0x%llx\n",
> > pos->offset, pos->data);
> > kfree(pos);
>
> Reviewed-by: Zhenyu Wang
I presume you will take it via the gvt tree? Saves a backmerge for you.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Release power well if load DMC failed
On Tue, 20 Nov 2018, "Jani Nikula" wrote:
>On Wed, 21 Nov 2018, "Lee, Shawn C" wrote:
>> On Tue, 20 Nov 2018, "Jani Nikula" wrote:
Driver obtain power well at intel_csr_ucode_init().
And release it after load DMC firmware successful.
>>>
>>>Correct.
>>>
An issue happened when DMC was not found or failed to load. Power
well would not be released and just output some error messages.
Driver have to release power well properly to keep put/get balance.
>>>
>>>No. We intentionally do not release it until dmc firmware load succeeds.
>>
>> If load DMC failed, we found DP phy was always on even without
>> external display connected. So it looks like an expected behavior,
>> right?
>
>I'll put it this way, we don't really go out of our way to support everything
>without the DMC firmware. Every choice like this doubles the testing
>requirements.
>
Understood. This is not a normal case (without DMC) on customer system.
We just think it will be better to release power well if we already got it
before.
>Do you see issues with DMC firmware loaded? Do you have issues with loading
>DMC firmware?
No issue with DMC firmware loaded. Thanks!
>
>BR,
>Jani.
>
>
>>
>>>
>>>See the comment in intel_csr_ucode_init(), as well as this in the branch
>>>where dmc load fails:
>>>
>>> dev_notice(dev_priv->drm.dev,
>>>"Failed to load DMC firmware %s."
>>>" Disabling runtime power management.\n",
>>>csr->fw_path);
>>>
>>>We don't support runtime pm without dmc on platforms with dmc.
>>>
>>>BR,
>>>Jani.
>>>
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jose Roberto de Souza
Cc: Cooper Chiou
Signed-off-by: Lee, Shawn C
---
drivers/gpu/drm/i915/intel_csr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c
b/drivers/gpu/drm/i915/intel_csr.c
index a516697bf57d..8d04d7b6f00a 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -425,8 +425,6 @@ static void csr_load_work_fn(struct work_struct *work)
if (dev_priv->csr.dmc_payload) {
intel_csr_load_program(dev_priv);
- intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
-
DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
dev_priv->csr.fw_path,
CSR_VERSION_MAJOR(csr->version), @@ -440,6 +438,7 @@
static
void csr_load_work_fn(struct work_struct *work)
INTEL_UC_FIRMWARE_URL);
}
+ intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
release_firmware(fw);
}
>>>
>>>--
>>>Jani Nikula, Intel Open Source Graphics Center
>
>--
>Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Release power well if load DMC failed
On Wed, 21 Nov 2018, "Lee, Shawn C" wrote:
> On Tue, 20 Nov 2018, "Jani Nikula" wrote:
>>> Driver obtain power well at intel_csr_ucode_init().
>>> And release it after load DMC firmware successful.
>>
>>Correct.
>>
>>> An issue happened when DMC was not found or failed to load. Power well
>>> would not be released and just output some error messages. Driver have
>>> to release power well properly to keep put/get balance.
>>
>>No. We intentionally do not release it until dmc firmware load succeeds.
>
> If load DMC failed, we found DP phy was always on even without
> external display connected. So it looks like an expected behavior,
> right?
I'll put it this way, we don't really go out of our way to support
everything without the DMC firmware. Every choice like this doubles the
testing requirements.
Do you see issues with DMC firmware loaded? Do you have issues with
loading DMC firmware?
BR,
Jani.
>
>>
>>See the comment in intel_csr_ucode_init(), as well as this in the branch
>>where dmc load fails:
>>
>> dev_notice(dev_priv->drm.dev,
>> "Failed to load DMC firmware %s."
>> " Disabling runtime power management.\n",
>> csr->fw_path);
>>
>>We don't support runtime pm without dmc on platforms with dmc.
>>
>>BR,
>>Jani.
>>
>>>
>>> Cc: Jani Nikula
>>> Cc: Rodrigo Vivi
>>> Cc: Jose Roberto de Souza
>>> Cc: Cooper Chiou
>>>
>>> Signed-off-by: Lee, Shawn C
>>> ---
>>> drivers/gpu/drm/i915/intel_csr.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_csr.c
>>> b/drivers/gpu/drm/i915/intel_csr.c
>>> index a516697bf57d..8d04d7b6f00a 100644
>>> --- a/drivers/gpu/drm/i915/intel_csr.c
>>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>>> @@ -425,8 +425,6 @@ static void csr_load_work_fn(struct work_struct *work)
>>> if (dev_priv->csr.dmc_payload) {
>>> intel_csr_load_program(dev_priv);
>>>
>>> - intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
>>> -
>>> DRM_INFO("Finished loading DMC firmware %s (v%u.%u)\n",
>>> dev_priv->csr.fw_path,
>>> CSR_VERSION_MAJOR(csr->version),
>>> @@ -440,6 +438,7 @@ static void csr_load_work_fn(struct work_struct *work)
>>>INTEL_UC_FIRMWARE_URL);
>>> }
>>>
>>> + intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
>>> release_firmware(fw);
>>> }
>>
>>--
>>Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging
On 20/11/2018 18:18, Tvrtko Ursulin wrote: On 20/11/2018 18:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-11-20 17:58:33) On 20/11/2018 17:33, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-11-20 17:28:39) From: Tvrtko Ursulin Since pr_debug is not printed by default, change both test and subtest log messages to pr_info so they are always logged. I just use the trace... As when the test fails we say which subtest failed, and hopefully include more details in the error message, and recent history is in the trace dumped when considered relevant. Fair. My thinking was simply to leave more breadcrumbs if the machine died in the middle of a subtest. Thinking more about it, the easiest option would be to actually enable pr_debug, iirc a config option. AFAICT we would need to pass -DDEBUG to interesting compilation units. However, the only time we don't get breadcrumbs is if the machine spontaneously combusts, which we are told is a mere figment of our imagination. Most often I wonder if we simply do not get the death throes - adding logging won't help if we don't capture it. For the true spontaneous combustion, it's pretty random and all I can think of suggesting are more sanity checks to try and catch inconsistencies early. Well I was looking at one such log today so hence the patch.. :) <6>[ 491.437102] i915: Performing live selftests with st_random_seed=0x3bd88daf st_timeout=1000 <7>[ 491.438062] [drm:intel_power_well_enable [i915]] enabling always-on <7>[ 491.438121] [drm:intel_power_well_enable [i915]] enabling DC off <7>[ 491.438509] [drm:gen9_set_dc_state [i915]] Setting DC state from 02 to 00 <7>[ 491.541663] [drm:intel_power_well_disable [i915]] disabling DC off <7>[ 491.541722] [drm:skl_enable_dc6 [i915]] Enabling DC6 <7>[ 491.541751] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02 <7>[ 491.542180] [drm:intel_power_well_disable [i915]] disabling always-on <7>[ 495.443505] [drm:intel_power_well_enable [i915]] enabling always-on <7>[ 495.443533] [drm:intel_power_well_enable [i915]] enabling DC off <7>[ 495.443817] [drm:gen9_set_dc_state [i915]] Setting DC state from 02 to 00 <7>[ 499.549369] [drm:intel_power_well_disable [i915]] disabling DC off <7>[ 499.549403] [drm:skl_enable_dc6 [i915]] Enabling DC6 <7>[ 499.549431] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02 <7>[ 499.549863] [drm:intel_power_well_disable [i915]] disabling always-on <6>[ 500.448268] i915_reset_engine(rcs0:idle): 265564 resets <6>[ 501.449250] i915_reset_engine(bcs0:idle): 249487 resets EOF I can certainly send a patch for -DDEBUG, seems like that would be the correct thing to do for all selftests. I've changed my mind - I think it is more desirable to actually just do what this patch did and convert test start messages to pr_info. To enable all pr_debug by default, even if compiled with i915 debugging on, doesn't seem conceptually correct. There might be ones which are prohibitively noisy and in any case it would defeat the point of dynamic debug. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
