Re: [Intel-gfx] [PATCH v4 0/8] i915 vgpu PV to improve vgpu performance
On 03/30/2019 12:05 AM, Chris Wilson wrote: > Quoting Xiaolin Zhang (2019-03-29 13:32:36) >> To improve vgpu performance, it could implement some PV optimization >> such as to reduce the mmio access trap numbers or eliminate certain piece >> of HW emulation within guest driver to reduce vm exit/vm enter cost. > Where's the CI for this patchset? The lack of interrupts to drive > submission should have shown up, and if not, we need some testcases to > make sure it doesn't happen again. Everytime I see a gvt patch, I ask if > we can get some coverage in intel-gfx-ci :) > -Chris > The CI for this patchset was not generated due to build failure. will try next version to avoid build issue by rebasing to tip of branch. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/8] drm/i915: vgpu context submission pv optimization
On 03/30/2019 03:14 AM, Chris Wilson wrote: > Quoting Xiaolin Zhang (2019-03-29 13:32:40) >> + spin_lock(>i915->vgpu.shared_page_lock); >> + shared_page->ring_id = engine->id; >> + for (n = 0; n < execlists_num_ports(execlists); n++) >> + shared_page->descs[n] = descs[n]; >> + >> + __raw_i915_write32(uncore, vgtif_reg(g2v_notify), >> + VGT_G2V_PV_SUBMISSION); > There's no serialisation with the consumer here. The > shared_page->descs[] will be clobbered by a second engine before they > are read by pv. There should be a wait-for-ack here, or separate > channels for each engine. In execlists, we avoid this by not dequeuing > until after we get a response/ack from HW. > > Preemption? I guess preemption was turned off, or else you have to worry > about the same engine overwriting the desc[] (if no ack). > -Chris > Chris, thanks you to point it out my flaw here. will use the per-engine channel for notification. preemption is turned off and no support in current version. ___ 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: Fix SDVO HDMI audio (rev3)
== Series Details == Series: drm/i915: Fix SDVO HDMI audio (rev3) URL : https://patchwork.freedesktop.org/series/59233/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5901_full -> Patchwork_12758_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12758_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12758_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_12758_full: ### IGT changes ### Possible regressions * igt@kms_frontbuffer_tracking@psr-2p-primscrn-indfb-msflip-blt: - shard-iclb: NOTRUN -> INCOMPLETE * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: PASS -> FAIL +1 * igt@kms_vblank@pipe-b-wait-forked-hang: - shard-apl: PASS -> FAIL Known issues Here are the changes found in Patchwork_12758_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-kbl: PASS -> DMESG-WARN [fdo#108566] +3 * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> SKIP [fdo#109283] * igt@gem_mocs_settings@mocs-reset-ctx-dirty-render: - shard-iclb: NOTRUN -> SKIP [fdo#110206] * igt@gem_softpin@evict-snoop-interruptible: - shard-iclb: NOTRUN -> SKIP [fdo#109312] * igt@gem_stolen@stolen-pwrite: - shard-iclb: NOTRUN -> SKIP [fdo#109277] * igt@i915_pm_rpm@fences: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait: - shard-iclb: NOTRUN -> SKIP [fdo#109308] * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking-fencing: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-modeset-hang-oldfb-render-d: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +10 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-d: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +1 * igt@kms_chamelium@dp-frame-dump: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +2 * igt@kms_color@pipe-a-gamma: - shard-iclb: NOTRUN -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-512x170-onscreen: - shard-iclb: NOTRUN -> SKIP [fdo#109279] * igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +4 * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip@2x-flip-vs-panning-vs-hang-interruptible: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +31 * igt@kms_force_connector_basic@force-edid: - shard-iclb: NOTRUN -> SKIP [fdo#109285] * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: NOTRUN -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +13 * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render: - shard-snb: PASS -> SKIP [fdo#109271] * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] +1 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-onoff: - shard-iclb: NOTRUN -> FAIL [fdo#109247] +2 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu: - shard-iclb: PASS -> FAIL [fdo#109247] +16 * igt@kms_lease@setcrtc_implicit_plane: - shard-iclb: NOTRUN -> FAIL [fdo#110281] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +5 * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc: - shard-apl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-c-alpha-basic: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_scaling@pipe-c-scaler-with-rotation: - shard-iclb: NOTRUN -> FAIL [fdo#109052] * igt@kms_psr@cursor_render: - shard-iclb: NOTRUN -> FAIL [fdo#107383] / [fdo#110215] * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: PASS -> SKIP [fdo#109441] * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: NOTRUN -> SKIP [fdo#109441] +1 *
Re: [Intel-gfx] [PATCH v4 4/8] drm/i915: vgpu context submission pv optimization
On 03/29/2019 11:40 PM, Chris Wilson wrote:
> Quoting Xiaolin Zhang (2019-03-29 13:32:40)
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 2f78829..28e8ee0 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -37,6 +37,7 @@
>> #include "i915_drv.h"
>> #include "i915_trace.h"
>> #include "intel_drv.h"
>> +#include "i915_vgpu.h"
>>
>> /**
>> * DOC: interrupt handling
>> @@ -1470,6 +1471,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine,
>> u32 iir)
>> if (iir & GT_RENDER_USER_INTERRUPT) {
>> intel_engine_breadcrumbs_irq(engine);
>> tasklet |= USES_GUC_SUBMISSION(engine->i915);
>> + tasklet |= USES_PV_SUBMISSION(engine->i915);
> We should move this to an engine->flag.
sure, I will remove this next version.
>
>> }
>>
>> if (tasklet)
>> +static void vgpu_pv_set_default_submission(struct intel_engine_cs *engine)
>> +{
>> + /*
>> +* We inherit a bunch of functions from execlists that we'd like
>> +* to keep using:
>> +*
>> +*engine->submit_request = execlists_submit_request;
>> +*engine->cancel_requests = execlists_cancel_requests;
>> +*engine->schedule = execlists_schedule;
>> +*
>> +* But we need to override the actual submission backend in order
>> +* to talk to the GVT with PV notification message.
>> +*/
>> + intel_execlists_set_default_submission(engine);
>> +
>> + engine->execlists.tasklet.func = vgpu_pv_submission_tasklet;
> You need to pin the breadcrumbs irq, or it will not fire on every
> request.
indeed, I should do. thanks your great point.
> I'd push for this to live in intel_pv_submission.c or
> intel_vgpu_submission.c
this will create new file and make a change in Makefile. if this kind
of change is OK,
I will create one to use intel_pv_submission.c name.
>> @@ -401,6 +551,12 @@ void intel_vgpu_config_pv_caps(struct drm_i915_private
>> *dev_priv,
>> ppgtt->vm.insert_entries = gen8_ppgtt_insert_4lvl_pv;
>> ppgtt->vm.clear_range = gen8_ppgtt_clear_4lvl_pv;
>> }
>> +
>> + if (cap == PV_SUBMISSION) {
>> + engine = (struct intel_engine_cs *)data;
>> + engine->set_default_submission =
>> vgpu_pv_set_default_submission;
>> + engine->set_default_submission(engine);
>> + }
>> }
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> b/drivers/gpu/drm/i915/intel_lrc.c
>> index c1b9780..0a66714 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -2352,6 +2352,9 @@ logical_ring_default_vfuncs(struct intel_engine_cs
>> *engine)
>> */
>> }
>> engine->emit_bb_start = gen8_emit_bb_start;
>> +
>> + if (intel_vgpu_active(engine->i915))
>> + intel_vgpu_config_pv_caps(engine->i915, PV_SUBMISSION,
>> engine);
> That pair is ugly. Should clean up the engine initialisation so that it
> doesn't involve placing a chunk of code in a foreign class.
> -Chris
>
Yep, will move it to other location.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/core-for-CI 15/15] drivers/acpi/processor_driver.c:67:23: error: 'X86_VENDOR_INTEL' undeclared here (not in a function); did you mean 'X86_VENDOR_ANY'?
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: b573fba52f339dc4fadef7282af4a9413fd6173d
commit: b573fba52f339dc4fadef7282af4a9413fd6173d [15/15] ICL HACK: Disable ACPI
idle driver
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b573fba52f339dc4fadef7282af4a9413fd6173d
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=ia64
All errors (new ones prefixed by >>):
>> drivers/acpi/processor_driver.c:67:23: error: 'X86_VENDOR_INTEL' undeclared
>> here (not in a function); did you mean 'X86_VENDOR_ANY'?
#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
^~~~
drivers/acpi/processor_driver.c:69:2: note: in expansion of macro 'ICPU'
ICPU(INTEL_FAM6_ICELAKE_MOBILE), /* ICL */
^~~~
>> drivers/acpi/processor_driver.c:69:7: error: 'INTEL_FAM6_ICELAKE_MOBILE'
>> undeclared here (not in a function); did you mean
>> 'CONFIG_PINCTRL_ICELAKE_MODULE'?
ICPU(INTEL_FAM6_ICELAKE_MOBILE), /* ICL */
^
drivers/acpi/processor_driver.c:67:44: note: in definition of macro 'ICPU'
#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
^
drivers/acpi/processor_driver.c: In function '__acpi_processor_start':
drivers/acpi/processor_driver.c:256:7: error: implicit declaration of
function 'x86_match_cpu'; did you mean 'on_each_cpu'?
[-Werror=implicit-function-declaration]
id = x86_match_cpu(intel_cpu_ids);
^
on_each_cpu
drivers/acpi/processor_driver.c:256:5: warning: assignment to 'const struct
x86_cpu_id *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
id = x86_match_cpu(intel_cpu_ids);
^
cc1: some warnings being treated as errors
vim +67 drivers/acpi/processor_driver.c
66
> 67 #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
68 static const struct x86_cpu_id intel_cpu_ids[] = {
> 69 ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
70 {}
71 };
72 MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
73
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Hexdump enhancements
== Series Details == Series: Hexdump enhancements URL : https://patchwork.freedesktop.org/series/59296/ State : success == Summary == CI Bug Log - changes from CI_DRM_5900_full -> Patchwork_12757_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12757_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@out-order-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +8 * igt@gem_mocs_settings@mocs-reset-ctx-dirty-render: - shard-iclb: NOTRUN -> SKIP [fdo#110206] * igt@gem_pread@stolen-uncached: - shard-iclb: NOTRUN -> SKIP [fdo#109277] * igt@gem_tiled_swapping@non-threaded: - shard-iclb: PASS -> DMESG-WARN [fdo#108686] * igt@gem_userptr_blits@coherency-sync: - shard-iclb: NOTRUN -> SKIP [fdo#109290] * igt@gem_wait@wait-bsd2: - shard-skl: NOTRUN -> SKIP [fdo#109271] +14 * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - shard-iclb: NOTRUN -> SKIP [fdo#109308] * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +4 * igt@kms_chamelium@hdmi-edid-read: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +4 * igt@kms_cursor_crc@cursor-128x42-random: - shard-skl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +7 * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: NOTRUN -> SKIP [fdo#109349] * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_force_connector_basic@prune-stale-modes: - shard-iclb: NOTRUN -> SKIP [fdo#109285] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@fbcpsr-2p-shrfb-fliptrack: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +11 * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +45 * igt@kms_frontbuffer_tracking@psr-2p-primscrn-cur-indfb-move: - shard-glk: NOTRUN -> SKIP [fdo#109271] * igt@kms_frontbuffer_tracking@psr-rgb565-draw-render: - shard-iclb: PASS -> FAIL [fdo#109247] +13 * igt@kms_lease@cursor_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110278] * igt@kms_lease@page_flip_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110281] * igt@kms_pipe_crc_basic@read-crc-pipe-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-apl: NOTRUN -> DMESG-WARN [fdo#108566] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-glk: PASS -> SKIP [fdo#109271] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-apl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: PASS -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4 * igt@kms_psr2_su@frontbuffer: - shard-iclb: NOTRUN -> SKIP [fdo#109642] * igt@kms_psr@basic: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: PASS -> SKIP [fdo#109441] +1 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> FAIL [fdo#109016] * igt@kms_setmode@basic: - shard-apl: PASS -> FAIL [fdo#99912] - shard-iclb: NOTRUN -> FAIL [fdo#99912] * igt@kms_sysfs_edid_timing: - shard-iclb: PASS -> FAIL [fdo#100047] * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3 * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +4 * igt@kms_vrr@flip-suspend: - shard-iclb: NOTRUN -> SKIP [fdo#109502] * igt@prime_nv_test@i915_import_gtt_mmap: - shard-snb: NOTRUN -> SKIP [fdo#109271] +36 * igt@prime_nv_test@nv_i915_sharing: - shard-iclb: NOTRUN -> SKIP [fdo#109291] +1 * igt@prime_vgem@coherency-gtt: - shard-apl: NOTRUN -> SKIP [fdo#109271] +48 Possible fixes * igt@gem_tiled_swapping@non-threaded: - shard-glk:
Re: [Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT
Thanks Ville, I'll backport your patch (drm/i915/vbt: Fix HDMI level shifter and max data rate bitfield sizes) to CrOS kernel for resolving this issue. Please abandon my patch. Best Regards, Cooper ___ 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: Bump ready tasks ahead of busywaits (rev3)
== Series Details == Series: drm/i915: Bump ready tasks ahead of busywaits (rev3) URL : https://patchwork.freedesktop.org/series/59232/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5900_full -> Patchwork_12756_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12756_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12756_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_12756_full: ### IGT changes ### Possible regressions * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL Known issues Here are the changes found in Patchwork_12756_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_bad_reloc@negative-reloc-lut-bsd1: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +12 * igt@gem_mocs_settings@mocs-reset-ctx-dirty-render: - shard-iclb: NOTRUN -> SKIP [fdo#110206] * igt@gem_softpin@noreloc-s3: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +1 * igt@gem_stolen@stolen-fill-purge: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +1 * igt@gem_userptr_blits@coherency-unsync: - shard-iclb: NOTRUN -> SKIP [fdo#109290] +1 * igt@gem_workarounds@suspend-resume-context: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] +2 * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - shard-iclb: NOTRUN -> SKIP [fdo#109308] * igt@i915_pm_rpm@pc8-residency: - shard-iclb: NOTRUN -> SKIP [fdo#109293] * igt@i915_query@query-topology-unsupported: - shard-iclb: NOTRUN -> SKIP [fdo#109302] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +5 * igt@kms_chamelium@hdmi-edid-read: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +6 * igt@kms_cursor_crc@cursor-128x42-random: - shard-skl: PASS -> FAIL [fdo#103232] +1 * igt@kms_cursor_crc@cursor-512x512-onscreen: - shard-iclb: NOTRUN -> SKIP [fdo#109279] * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +7 * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: NOTRUN -> SKIP [fdo#109349] * igt@kms_fbcon_fbt@psr: - shard-iclb: NOTRUN -> FAIL [fdo#103833] * igt@kms_force_connector_basic@prune-stale-modes: - shard-iclb: NOTRUN -> SKIP [fdo#109285] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#103167] +5 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-render: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: NOTRUN -> FAIL [fdo#109247] +1 * igt@kms_frontbuffer_tracking@fbcpsr-2p-shrfb-fliptrack: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +18 * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt: - shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] +1 * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +45 * igt@kms_frontbuffer_tracking@psr-2p-primscrn-cur-indfb-move: - shard-glk: NOTRUN -> SKIP [fdo#109271] * igt@kms_frontbuffer_tracking@psr-slowdraw: - shard-iclb: PASS -> FAIL [fdo#109247] +15 * igt@kms_lease@cursor_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110278] * igt@kms_lease@page_flip_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110281] - shard-iclb: NOTRUN -> FAIL [fdo#110281] * igt@kms_pipe_crc_basic@read-crc-pipe-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-glk: PASS -> SKIP [fdo#109271] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-apl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4 * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: PASS -> FAIL [fdo#108145] +1 * igt@kms_psr2_su@frontbuffer: - shard-iclb: NOTRUN -> SKIP [fdo#109642] * igt@kms_psr@primary_page_flip: - shard-iclb: NOTRUN -> FAIL [fdo#107383] / [fdo#110215] * igt@kms_psr@psr2_cursor_mmap_cpu: -
Re: [Intel-gfx] [PATCH libdrm] headers: Sync with drm-next
On Tue, Apr 9, 2019 at 8:27 AM Eric Engestrom wrote:
>
> On Tuesday, 2019-04-09 12:59:13 +0100, Eric Engestrom wrote:
> > On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> > > Generated using make headers_install from the drm-next
> > > tree - git://anongit.freedesktop.org/drm/drm
> > > branch - drm-next
> > > commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
> > >
> > > The changes were as follows :-
> > >
> > > core: (drm.h, drm_fourcc.h, drm_mode.h)
> > > - Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait'
> > > and 'struct drm_syncobj_timeline_array'
> > > - Added various DRM_IOCTL_SYNCOBJ_ ioctls
> > > - Added some new RGB and YUV formats
> > > - Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
> > > - Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
> > > - Added 'struct drm_mode_rect'
> > >
> > > i915:
> > > - Added struct 'struct i915_user_extension' and various 'struct
> > > drm_i915_gem_context_'
> > > - Added different modes of per-process Graphics Translation Table
> > >
> > > msm:
> > > - Added various get or set GEM buffer info flags
> > > - Added some MSM_SUBMIT_BO_ macros
> > > - Modified 'struct drm_msm_gem_info'
> > >
> > > Signed-off-by: Ayan Kumar halder
> >
> > This looks sane, and applies cleanly :)
> > Acked-by: Eric Engestrom
>
> Actually, revoking that, as this patch breaks the build; see below.
>
> >
> > > ---
> > > include/drm/drm.h| 36 +++
> > > include/drm/drm_fourcc.h | 136 +++
> > > include/drm/drm_mode.h | 23 -
> > > include/drm/i915_drm.h | 237
> > > ---
> > > include/drm/msm_drm.h| 25 +++--
> > > 5 files changed, 415 insertions(+), 42 deletions(-)
> > >
> [snip]
> > > diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
> > > index c06d0a5..91a16b3 100644
> > > --- a/include/drm/msm_drm.h
> > > +++ b/include/drm/msm_drm.h
> > > @@ -105,14 +105,24 @@ struct drm_msm_gem_new {
> > > __u32 handle; /* out */
> > > };
> > >
> > > -#define MSM_INFO_IOVA 0x01
> > > -
> > > -#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
> > > +/* Get or set GEM buffer info. The requested value can be passed
> > > + * directly in 'value', or for data larger than 64b 'value' is a
> > > + * pointer to userspace buffer, with 'len' specifying the number of
> > > + * bytes copied into that buffer. For info returned by pointer,
> > > + * calling the GEM_INFO ioctl with null 'value' will return the
> > > + * required buffer size in 'len'
> > > + */
> > > +#define MSM_INFO_GET_OFFSET0x00 /* get mmap() offset, returned
> > > by value */
> > > +#define MSM_INFO_GET_IOVA 0x01 /* get iova, returned by value */
> > > +#define MSM_INFO_SET_NAME 0x02 /* set the debug name (by pointer) */
> > > +#define MSM_INFO_GET_NAME 0x03 /* get debug name, returned by pointer
> > > */
> > >
> > > struct drm_msm_gem_info {
> > > __u32 handle; /* in */
> > > - __u32 flags; /* in - combination of MSM_INFO_* flags */
> > > - __u64 offset; /* out, mmap() offset or iova */
> > > + __u32 info; /* in - one of MSM_INFO_* */
> > > + __u64 value; /* in or out */
> > > + __u32 len;/* in or out */
> > > + __u32 pad;
>
> freedreno/msm/msm_bo.c needs to be updated to reflect those changes.
I think you can just rename flags->info and offset->value, the rest of
the struct should be zero-initialized.. if in doubt you can check
$mesa/src/freedreno/drm/msm_bo.c
side-note: the libdrm_freedreno code was folded into mesa in 19.0, so
at *some* point we can probably disable libdrm_freedreno build by
default. (I'd kinda still like to keep the code around for some misc
standalone tools I have, but that is the sort of thing where I can fix
libdrm if it gets broken). When to switch to disabled by default I
guess comes down to how long we want to support mesa 18.x with latest
libdrm?? Maybe after 19.1, since (selfishly motivated) that gives me
a long enough window back in case I find myself needing to bisect for
some regression..
BR,
-R
>
> > > };
> > >
> > > #define MSM_PREP_READ0x01
> > > @@ -188,8 +198,11 @@ struct drm_msm_gem_submit_cmd {
> > > */
> > > #define MSM_SUBMIT_BO_READ 0x0001
> > > #define MSM_SUBMIT_BO_WRITE0x0002
> > > +#define MSM_SUBMIT_BO_DUMP 0x0004
> > >
> > > -#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ |
> > > MSM_SUBMIT_BO_WRITE)
> > > +#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ | \
> > > + MSM_SUBMIT_BO_WRITE | \
> > > + MSM_SUBMIT_BO_DUMP)
> > >
> > > struct drm_msm_gem_submit_bo {
> > > __u32 flags; /* in, mask of MSM_SUBMIT_BO_x */
> > > --
> > > 2.7.4
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [drm-intel:topic/core-for-CI 15/15] drivers/acpi/processor_driver.c:69:7: error: 'INTEL_FAM6_ICELAKE_MOBILE' undeclared here (not in a function)
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: b573fba52f339dc4fadef7282af4a9413fd6173d
commit: b573fba52f339dc4fadef7282af4a9413fd6173d [15/15] ICL HACK: Disable ACPI
idle driver
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b573fba52f339dc4fadef7282af4a9413fd6173d
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64
All errors (new ones prefixed by >>):
drivers/acpi/processor_driver.c:67:23: error: 'X86_VENDOR_INTEL' undeclared
here (not in a function); did you mean 'X86_VENDOR_ANY'?
#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
^
drivers/acpi/processor_driver.c:69:2: note: in expansion of macro 'ICPU'
ICPU(INTEL_FAM6_ICELAKE_MOBILE), /* ICL */
^~~~
>> drivers/acpi/processor_driver.c:69:7: error: 'INTEL_FAM6_ICELAKE_MOBILE'
>> undeclared here (not in a function)
ICPU(INTEL_FAM6_ICELAKE_MOBILE), /* ICL */
^
drivers/acpi/processor_driver.c:67:44: note: in definition of macro 'ICPU'
#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
^
drivers/acpi/processor_driver.c: In function '__acpi_processor_start':
>> drivers/acpi/processor_driver.c:256:7: error: implicit declaration of
>> function 'x86_match_cpu'; did you mean 'on_each_cpu'?
>> [-Werror=implicit-function-declaration]
id = x86_match_cpu(intel_cpu_ids);
^
on_each_cpu
drivers/acpi/processor_driver.c:256:5: warning: assignment makes pointer
from integer without a cast [-Wint-conversion]
id = x86_match_cpu(intel_cpu_ids);
^
cc1: some warnings being treated as errors
vim +/INTEL_FAM6_ICELAKE_MOBILE +69 drivers/acpi/processor_driver.c
66
> 67 #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
68 static const struct x86_cpu_id intel_cpu_ids[] = {
> 69 ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
70 {}
71 };
72 MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
73
74 static struct device_driver acpi_processor_driver = {
75 .name = "processor",
76 .bus = _subsys,
77 .acpi_match_table = processor_device_ids,
78 .probe = acpi_processor_start,
79 .remove = acpi_processor_stop,
80 };
81
82 static void acpi_processor_notify(acpi_handle handle, u32 event, void
*data)
83 {
84 struct acpi_device *device = data;
85 struct acpi_processor *pr;
86 int saved;
87
88 if (device->handle != handle)
89 return;
90
91 pr = acpi_driver_data(device);
92 if (!pr)
93 return;
94
95 switch (event) {
96 case ACPI_PROCESSOR_NOTIFY_PERFORMANCE:
97 saved = pr->performance_platform_limit;
98 acpi_processor_ppc_has_changed(pr, 1);
99 if (saved == pr->performance_platform_limit)
100 break;
101
acpi_bus_generate_netlink_event(device->pnp.device_class,
102
dev_name(>dev), event,
103
pr->performance_platform_limit);
104 break;
105 case ACPI_PROCESSOR_NOTIFY_POWER:
106 acpi_processor_power_state_has_changed(pr);
107
acpi_bus_generate_netlink_event(device->pnp.device_class,
108
dev_name(>dev), event, 0);
109 break;
110 case ACPI_PROCESSOR_NOTIFY_THROTTLING:
111 acpi_processor_tstate_has_changed(pr);
112
acpi_bus_generate_netlink_event(device->pnp.device_class,
113
dev_name(>dev), event, 0);
114 break;
115 default:
116 ACPI_DEBUG_PRINT((ACPI_DB_INFO,
117"Unsupported event [0x%x]\n", event));
118 break;
119 }
120
121 return;
122 }
123
124 static int __acpi_processor_start(struct acpi_device *device);
125
126 static int acpi_soft_cpu_online(unsigned int cpu)
127 {
128 struct acpi_processor *pr = per_cpu(processors, cpu);
129 struct acpi_device *device;
130
131 if (!pr || acpi_bus_get_device(pr->handle, ))
132 return 0;
133 /*
134 *
[Intel-gfx] ✓ Fi.CI.BAT: success for IRQ initialization debloat and conversion to uncore (rev2)
== Series Details ==
Series: IRQ initialization debloat and conversion to uncore (rev2)
URL : https://patchwork.freedesktop.org/series/59202/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5904 -> Patchwork_12760
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/59202/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12760 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-compute0:
- fi-icl-y: NOTRUN -> SKIP [fdo#109315] +17
* igt@gem_exec_basic@basic-bsd2:
- fi-icl-y: NOTRUN -> SKIP [fdo#109276] +7
* igt@gem_exec_basic@readonly-bsd1:
- fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] +57
* igt@gem_exec_parse@basic-rejected:
- fi-icl-y: NOTRUN -> SKIP [fdo#109289] +1
* igt@i915_selftest@live_contexts:
- fi-icl-y: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720]
* igt@i915_selftest@live_hangcheck:
- fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@basic-flip-c:
- fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@dp-crc-fast:
- fi-icl-y: NOTRUN -> SKIP [fdo#109284] +8
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-y: NOTRUN -> SKIP [fdo#109285] +3
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191]
* igt@kms_psr@primary_mmap_gtt:
- fi-skl-guc: NOTRUN -> SKIP [fdo#109271] +49
- fi-icl-y: NOTRUN -> SKIP [fdo#110189] +3
* igt@kms_psr@primary_page_flip:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50
* igt@prime_vgem@basic-fence-flip:
- fi-icl-y: NOTRUN -> SKIP [fdo#109294]
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720]
Possible fixes
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] -> PASS
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (45 -> 38)
--
Additional (4): fi-icl-y fi-skl-guc fi-apl-guc fi-snb-2520m
Missing(11): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-glk-dsi
fi-byt-squawks fi-bwr-2160 fi-bsw-cyan fi-ctg-p8600 fi-blb-e6850 fi-bdw-samus
fi-kbl-r
Build changes
-
* Linux: CI_DRM_5904 -> Patchwork_12760
CI_DRM_5904: f0ba5aa7a6ab956f01dbaf1b16720da3ca859230 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4942: ff8929d4d5b57b544e699fa428930f0fd66dd2dc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12760: 84a9eee43744c59bbfca952ea970891ee1076c77 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
84a9eee43744 drm/i915: fully convert the IRQ initialization macros to
intel_uncore
3d688694ded6 drm/i915: convert the IRQ initialization functions to intel_uncore
602a584b8939 drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers
238ca5a190e4 drm/i915: don't specify the IRQ register in the gen2 macros
41f6a743fff7 drm/i915: refactor the IRQ init/reset macros
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12760/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 1/5] drm/i915: refactor the IRQ init/reset macros
The whole point of having macros here is for the token pasting
necessary to automatically have IMR, IIR and IER selected. We don't
really need or want all the inlining that happens as a consequence.
The good thing about the current code is that it works regardless of
the relative offsets between these registers (they change after gen4,
with the usual VLV/CHV exceptions).
One thing which we can do is to split the logic of what we do with
imr/ier/iir to functions separate from the macros that pick them.
That's what we do in this commit. This allows us to get rid of the
gen8 duplicates and also all the inlining:
add/remove: 2/0 grow/shrink: 0/21 up/down: 384/-5949 (-5565)
Function old new delta
gen3_irq_reset - 233+233
gen3_irq_init - 151+151
i8xx_irq_postinstall 459 442 -17
gen11_irq_postinstall804 744 -60
ironlake_irq_postinstall 450 353 -97
vlv_display_irq_postinstall 348 245-103
i965_irq_postinstall 378 272-106
i915_irq_postinstall 333 227-106
gen8_irq_power_well_post_enable 374 240-134
ironlake_irq_reset 397 218-179
vlv_display_irq_reset616 433-183
i965_irq_reset 374 180-194
cherryview_irq_reset 379 185-194
i915_irq_reset 407 209-198
ibx_irq_reset332 133-199
gen5_gt_irq_postinstall 533 332-201
gen8_irq_power_well_pre_disable 434 204-230
gen8_gt_irq_postinstall 469 196-273
gen8_de_irq_postinstall 1200 836-364
gen5_gt_irq_reset471 76-395
gen8_gt_irq_reset775 99-676
gen8_irq_reset 1100 333-767
gen11_irq_reset 1959 686 -1273
Total: Before=2259222, After=2253657, chg -0.25%
v2:
- Make checkpatch happy with a temporary which_ (Checkpatch).
- Reorder the arguments for the INIT macros (Ville).
- Correctly explain when the register offsets change in the commit
message (Ville).
- Use more line breaks in the macro calls to make the arguments look
a little more organized/readable.
- Update the bloat-o-meter output (minor change only).
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 136
1 file changed, 86 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8d8935d71180..60a3f4203ac3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,36 +136,48 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
};
-/* IIR can theoretically queue up two events. Be paranoid. */
-#define GEN8_IRQ_RESET_NDX(type, which) do { \
- I915_WRITE(GEN8_##type##_IMR(which), 0x); \
- POSTING_READ(GEN8_##type##_IMR(which)); \
- I915_WRITE(GEN8_##type##_IER(which), 0); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- POSTING_READ(GEN8_##type##_IIR(which)); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- POSTING_READ(GEN8_##type##_IIR(which)); \
-} while (0)
-
-#define GEN3_IRQ_RESET(type) do { \
- I915_WRITE(type##IMR, 0x); \
- POSTING_READ(type##IMR); \
- I915_WRITE(type##IER, 0); \
- I915_WRITE(type##IIR, 0x); \
- POSTING_READ(type##IIR); \
- I915_WRITE(type##IIR, 0x); \
- POSTING_READ(type##IIR); \
-} while (0)
-
-#define GEN2_IRQ_RESET(type) do { \
- I915_WRITE16(type##IMR, 0x); \
- POSTING_READ16(type##IMR); \
- I915_WRITE16(type##IER, 0); \
- I915_WRITE16(type##IIR, 0x); \
- POSTING_READ16(type##IIR); \
- I915_WRITE16(type##IIR, 0x); \
- POSTING_READ16(type##IIR); \
-} while (0)
+static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+ i915_reg_t iir, i915_reg_t ier)
+{
+ I915_WRITE(imr, 0x);
+ POSTING_READ(imr);
+
+ I915_WRITE(ier, 0);
+
+ /* IIR can theoretically queue up two events. Be paranoid. */
+ I915_WRITE(iir, 0x);
+ POSTING_READ(iir);
+ I915_WRITE(iir, 0x);
+ POSTING_READ(iir);
+}
+
+static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+ i915_reg_t iir, i915_reg_t ier)
+{
+ I915_WRITE16(imr, 0x);
+ POSTING_READ16(imr);
+
+ I915_WRITE16(ier,
[Intel-gfx] [PATCH 5/5] drm/i915: fully convert the IRQ initialization macros to intel_uncore
Make them take the uncore argument from the caller instead of passing
the implicit _priv->uncore directly. This will allow us to finally
pass something that's not dev_priv->uncore in the future, and gets rid
of the implicit variables in register macros.
v2: Rebase on top of the newer patches.
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 144 +++-
1 file changed, 88 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 22b89da25289..f6ab4c4c6388 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -165,18 +165,18 @@ static void gen2_irq_reset(struct intel_uncore *uncore)
intel_uncore_posting_read16(uncore, GEN2_IIR);
}
-#define GEN8_IRQ_RESET_NDX(type, which) \
+#define GEN8_IRQ_RESET_NDX(uncore, type, which) \
({ \
unsigned int which_ = which; \
- gen3_irq_reset(_priv->uncore, GEN8_##type##_IMR(which_), \
+ gen3_irq_reset((uncore), GEN8_##type##_IMR(which_), \
GEN8_##type##_IIR(which_), GEN8_##type##_IER(which_)); \
})
-#define GEN3_IRQ_RESET(type) \
- gen3_irq_reset(_priv->uncore, type##IMR, type##IIR, type##IER)
+#define GEN3_IRQ_RESET(uncore, type) \
+ gen3_irq_reset((uncore), type##IMR, type##IIR, type##IER)
-#define GEN2_IRQ_RESET() \
- gen2_irq_reset(_priv->uncore)
+#define GEN2_IRQ_RESET(uncore) \
+ gen2_irq_reset(uncore)
/*
* We should clear IMR at preinstall/uninstall, and just check at postinstall.
@@ -233,23 +233,23 @@ static void gen2_irq_init(struct intel_uncore *uncore,
intel_uncore_posting_read16(uncore, GEN2_IMR);
}
-#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
+#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \
({ \
unsigned int which_ = which; \
- gen3_irq_init(_priv->uncore, \
+ gen3_irq_init((uncore), \
GEN8_##type##_IMR(which_), imr_val, \
GEN8_##type##_IER(which_), ier_val, \
GEN8_##type##_IIR(which_)); \
})
-#define GEN3_IRQ_INIT(type, imr_val, ier_val) \
- gen3_irq_init(_priv->uncore, \
+#define GEN3_IRQ_INIT(uncore, type, imr_val, ier_val) \
+ gen3_irq_init((uncore), \
type##IMR, imr_val, \
type##IER, ier_val, \
type##IIR)
-#define GEN2_IRQ_INIT(imr_val, ier_val) \
- gen2_irq_init(_priv->uncore, imr_val, ier_val)
+#define GEN2_IRQ_INIT(uncore, imr_val, ier_val) \
+ gen2_irq_init((uncore), imr_val, ier_val)
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
@@ -3349,10 +3349,12 @@ static void i945gm_vblank_work_fini(struct
drm_i915_private *dev_priv)
static void ibx_irq_reset(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = _priv->uncore;
+
if (HAS_PCH_NOP(dev_priv))
return;
- GEN3_IRQ_RESET(SDE);
+ GEN3_IRQ_RESET(uncore, SDE);
if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT(dev_priv))
I915_WRITE(SERR_INT, 0x);
@@ -3380,13 +3382,17 @@ static void ibx_irq_pre_postinstall(struct drm_device
*dev)
static void gen5_gt_irq_reset(struct drm_i915_private *dev_priv)
{
- GEN3_IRQ_RESET(GT);
+ struct intel_uncore *uncore = _priv->uncore;
+
+ GEN3_IRQ_RESET(uncore, GT);
if (INTEL_GEN(dev_priv) >= 6)
- GEN3_IRQ_RESET(GEN6_PM);
+ GEN3_IRQ_RESET(uncore, GEN6_PM);
}
static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = _priv->uncore;
+
if (IS_CHERRYVIEW(dev_priv))
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
else
@@ -3397,12 +3403,14 @@ static void vlv_display_irq_reset(struct
drm_i915_private *dev_priv)
i9xx_pipestat_irq_reset(dev_priv);
- GEN3_IRQ_RESET(VLV_);
+ GEN3_IRQ_RESET(uncore, VLV_);
dev_priv->irq_mask = ~0u;
}
static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = _priv->uncore;
+
u32 pipestat_mask;
u32 enable_mask;
enum pipe pipe;
@@ -3427,7 +3435,7 @@ static void vlv_display_irq_postinstall(struct
drm_i915_private *dev_priv)
dev_priv->irq_mask = ~enable_mask;
- GEN3_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
+ GEN3_IRQ_INIT(uncore, VLV_, dev_priv->irq_mask, enable_mask);
}
/* drm_dma.h hooks
@@ -3435,8 +3443,9 @@ static void vlv_display_irq_postinstall(struct
drm_i915_private *dev_priv)
static void ironlake_irq_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_uncore *uncore = _priv->uncore;
- GEN3_IRQ_RESET(DE);
+
[Intel-gfx] [PATCH 3/5] drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers
This discussion started because we use token pasting in the
GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
empty argument to those macros, making the code a little weird. The
original proposal was to just add a comment as the empty argument, but
Ville suggested we just add a prefix to the registers, and that indeed
sounds like a more elegant solution.
Now doing this is kinda against our rules for register naming since we
only add gens or platform names as register prefixes when the given
gen/platform changes a register that already existed before. On the
other hand, we have so many instances of IIR/IMR in comments that
adding a prefix would make the users of these register more easily
findable, in addition to make our token pasting macros actually
readable. So IMHO opening an exception here is worth it.
Cc: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 52 -
drivers/gpu/drm/i915/i915_reg.h | 8 ++--
drivers/gpu/drm/i915/i915_reset.c | 3 +-
drivers/gpu/drm/i915/intel_overlay.c| 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++---
7 files changed, 44 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 77b3252bdb2e..5823ffb17821 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -833,11 +833,11 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
} else if (!HAS_PCH_SPLIT(dev_priv)) {
seq_printf(m, "Interrupt enable:%08x\n",
- I915_READ(IER));
+ I915_READ(GEN2_IER));
seq_printf(m, "Interrupt identity: %08x\n",
- I915_READ(IIR));
+ I915_READ(GEN2_IIR));
seq_printf(m, "Interrupt mask: %08x\n",
- I915_READ(IMR));
+ I915_READ(GEN2_IMR));
for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat: %08x\n",
pipe_name(pipe),
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 43b68fdc8967..f51ff683dd2e 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1635,9 +1635,9 @@ static void capture_reg_state(struct i915_gpu_state
*error)
error->gtier[0] = I915_READ(GTIER);
error->ngtier = 1;
} else if (IS_GEN(dev_priv, 2)) {
- error->ier = I915_READ16(IER);
+ error->ier = I915_READ16(GEN2_IER);
} else if (!IS_VALLEYVIEW(dev_priv)) {
- error->ier = I915_READ(IER);
+ error->ier = I915_READ(GEN2_IER);
}
error->eir = I915_READ(EIR);
error->pgtbl_er = I915_READ(PGTBL_ER);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1f1db2bd879..2910b06913af 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -153,16 +153,16 @@ static void gen3_irq_reset(struct drm_i915_private
*dev_priv, i915_reg_t imr,
static void gen2_irq_reset(struct drm_i915_private *dev_priv)
{
- I915_WRITE16(IMR, 0x);
- POSTING_READ16(IMR);
+ I915_WRITE16(GEN2_IMR, 0x);
+ POSTING_READ16(GEN2_IMR);
- I915_WRITE16(IER, 0);
+ I915_WRITE16(GEN2_IER, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE16(IIR, 0x);
- POSTING_READ16(IIR);
- I915_WRITE16(IIR, 0x);
- POSTING_READ16(IIR);
+ I915_WRITE16(GEN2_IIR, 0x);
+ POSTING_READ16(GEN2_IIR);
+ I915_WRITE16(GEN2_IIR, 0x);
+ POSTING_READ16(GEN2_IIR);
}
#define GEN8_IRQ_RESET_NDX(type, which) \
@@ -199,17 +199,17 @@ static void gen3_assert_iir_is_zero(struct
drm_i915_private *dev_priv,
static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
{
- u16 val = I915_READ16(IIR);
+ u16 val = I915_READ16(GEN2_IIR);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
-i915_mmio_reg_offset(IIR), val);
- I915_WRITE16(IIR, 0x);
- POSTING_READ16(IIR);
- I915_WRITE16(IIR, 0x);
- POSTING_READ16(IIR);
+i915_mmio_reg_offset(GEN2_IIR), val);
+ I915_WRITE16(GEN2_IIR, 0x);
+ POSTING_READ16(GEN2_IIR);
+ I915_WRITE16(GEN2_IIR, 0x);
+ POSTING_READ16(GEN2_IIR);
}
static void gen3_irq_init(struct drm_i915_private *dev_priv,
@@ -229,9 +229,9 @@ static void gen2_irq_init(struct drm_i915_private *dev_priv,
{
gen2_assert_iir_is_zero(dev_priv);
- I915_WRITE16(IER, ier_val);
-
[Intel-gfx] [PATCH 4/5] drm/i915: convert the IRQ initialization functions to intel_uncore
The IRQ initialization helpers are simple and self-contained. Continue
the transition started in the recent uncore rework to get us rid of
I915_READ/WRITE and the implicit dev_priv variables.
While the implicit dev_priv is removed from the IRQ initialization
helpers, we didn't get rid of them in the macro callers. Doing that
should be very simple now.
v2: Rebase on top of the new patches.
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 97 -
1 file changed, 48 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2910b06913af..22b89da25289 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,121 +136,120 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
};
-static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
i915_reg_t iir, i915_reg_t ier)
{
- I915_WRITE(imr, 0x);
- POSTING_READ(imr);
+ intel_uncore_write(uncore, imr, 0x);
+ intel_uncore_posting_read(uncore, imr);
- I915_WRITE(ier, 0);
+ intel_uncore_write(uncore, ier, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE(iir, 0x);
- POSTING_READ(iir);
- I915_WRITE(iir, 0x);
- POSTING_READ(iir);
+ intel_uncore_write(uncore, iir, 0x);
+ intel_uncore_posting_read(uncore, iir);
+ intel_uncore_write(uncore, iir, 0x);
+ intel_uncore_posting_read(uncore, iir);
}
-static void gen2_irq_reset(struct drm_i915_private *dev_priv)
+static void gen2_irq_reset(struct intel_uncore *uncore)
{
- I915_WRITE16(GEN2_IMR, 0x);
- POSTING_READ16(GEN2_IMR);
+ intel_uncore_write16(uncore, GEN2_IMR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IMR);
- I915_WRITE16(GEN2_IER, 0);
+ intel_uncore_write16(uncore, GEN2_IER, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE16(GEN2_IIR, 0x);
- POSTING_READ16(GEN2_IIR);
- I915_WRITE16(GEN2_IIR, 0x);
- POSTING_READ16(GEN2_IIR);
+ intel_uncore_write16(uncore, GEN2_IIR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IIR);
+ intel_uncore_write16(uncore, GEN2_IIR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IIR);
}
#define GEN8_IRQ_RESET_NDX(type, which) \
({ \
unsigned int which_ = which; \
- gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which_), \
+ gen3_irq_reset(_priv->uncore, GEN8_##type##_IMR(which_), \
GEN8_##type##_IIR(which_), GEN8_##type##_IER(which_)); \
})
#define GEN3_IRQ_RESET(type) \
- gen3_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+ gen3_irq_reset(_priv->uncore, type##IMR, type##IIR, type##IER)
#define GEN2_IRQ_RESET() \
- gen2_irq_reset(dev_priv)
+ gen2_irq_reset(_priv->uncore)
/*
* We should clear IMR at preinstall/uninstall, and just check at postinstall.
*/
-static void gen3_assert_iir_is_zero(struct drm_i915_private *dev_priv,
- i915_reg_t reg)
+static void gen3_assert_iir_is_zero(struct intel_uncore *uncore, i915_reg_t
reg)
{
- u32 val = I915_READ(reg);
+ u32 val = intel_uncore_read(uncore, reg);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
i915_mmio_reg_offset(reg), val);
- I915_WRITE(reg, 0x);
- POSTING_READ(reg);
- I915_WRITE(reg, 0x);
- POSTING_READ(reg);
+ intel_uncore_write(uncore, reg, 0x);
+ intel_uncore_posting_read(uncore, reg);
+ intel_uncore_write(uncore, reg, 0x);
+ intel_uncore_posting_read(uncore, reg);
}
-static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
+static void gen2_assert_iir_is_zero(struct intel_uncore *uncore)
{
- u16 val = I915_READ16(GEN2_IIR);
+ u16 val = intel_uncore_read16(uncore, GEN2_IIR);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
i915_mmio_reg_offset(GEN2_IIR), val);
- I915_WRITE16(GEN2_IIR, 0x);
- POSTING_READ16(GEN2_IIR);
- I915_WRITE16(GEN2_IIR, 0x);
- POSTING_READ16(GEN2_IIR);
+ intel_uncore_write16(uncore, GEN2_IIR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IIR);
+ intel_uncore_write16(uncore, GEN2_IIR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IIR);
}
-static void gen3_irq_init(struct drm_i915_private *dev_priv,
+static void gen3_irq_init(struct intel_uncore *uncore,
i915_reg_t imr, u32
[Intel-gfx] [PATCH 0/5] IRQ initialization debloat and conversion to uncore, v2
The first patch is a simple refactor to try to debloat our IRQ
initialization and the last ones are a tiny conversion to the new
intel_uncore model. I'm not sure how much we want patch 5 right now,
but my understanding is that we want to move in that direction anyway,
so why not now.
New in v2:
- Two additional patches based on the discussion with Ville and Checkpatch.
- No more checkpatch complaints.
Cc: Ville Syrjälä
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Paulo Zanoni (5):
drm/i915: refactor the IRQ init/reset macros
drm/i915: don't specify the IRQ register in the gen2 macros
drm/i915: add GEN2_ prefix to the I{E,I,M,S}R registers
drm/i915: convert the IRQ initialization functions to intel_uncore
drm/i915: fully convert the IRQ initialization macros to intel_uncore
drivers/gpu/drm/i915/i915_debugfs.c | 6 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 298 ++--
drivers/gpu/drm/i915/i915_reg.h | 8 +-
drivers/gpu/drm/i915/i915_reset.c | 3 +-
drivers/gpu/drm/i915/intel_overlay.c| 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
7 files changed, 197 insertions(+), 136 deletions(-)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: don't specify the IRQ register in the gen2 macros
Like the gen3+ macros, the gen2 versions of the IRQ initialization
macros take the register name in the 'type' argument. But gen2 only
has one set of registers, so there's really no need to specify the
type. This commit removes the type argument and uses the registers
directly instead of passing them through variables.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 57 +++--
1 file changed, 25 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 60a3f4203ac3..b1f1db2bd879 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -151,19 +151,18 @@ static void gen3_irq_reset(struct drm_i915_private
*dev_priv, i915_reg_t imr,
POSTING_READ(iir);
}
-static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
- i915_reg_t iir, i915_reg_t ier)
+static void gen2_irq_reset(struct drm_i915_private *dev_priv)
{
- I915_WRITE16(imr, 0x);
- POSTING_READ16(imr);
+ I915_WRITE16(IMR, 0x);
+ POSTING_READ16(IMR);
- I915_WRITE16(ier, 0);
+ I915_WRITE16(IER, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE16(iir, 0x);
- POSTING_READ16(iir);
- I915_WRITE16(iir, 0x);
- POSTING_READ16(iir);
+ I915_WRITE16(IIR, 0x);
+ POSTING_READ16(IIR);
+ I915_WRITE16(IIR, 0x);
+ POSTING_READ16(IIR);
}
#define GEN8_IRQ_RESET_NDX(type, which) \
@@ -176,8 +175,8 @@ static void gen2_irq_reset(struct drm_i915_private
*dev_priv, i915_reg_t imr,
#define GEN3_IRQ_RESET(type) \
gen3_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
-#define GEN2_IRQ_RESET(type) \
- gen2_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+#define GEN2_IRQ_RESET() \
+ gen2_irq_reset(dev_priv)
/*
* We should clear IMR at preinstall/uninstall, and just check at postinstall.
@@ -198,20 +197,19 @@ static void gen3_assert_iir_is_zero(struct
drm_i915_private *dev_priv,
POSTING_READ(reg);
}
-static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv,
- i915_reg_t reg)
+static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
{
- u16 val = I915_READ16(reg);
+ u16 val = I915_READ16(IIR);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
-i915_mmio_reg_offset(reg), val);
- I915_WRITE16(reg, 0x);
- POSTING_READ16(reg);
- I915_WRITE16(reg, 0x);
- POSTING_READ16(reg);
+i915_mmio_reg_offset(IIR), val);
+ I915_WRITE16(IIR, 0x);
+ POSTING_READ16(IIR);
+ I915_WRITE16(IIR, 0x);
+ POSTING_READ16(IIR);
}
static void gen3_irq_init(struct drm_i915_private *dev_priv,
@@ -227,15 +225,13 @@ static void gen3_irq_init(struct drm_i915_private
*dev_priv,
}
static void gen2_irq_init(struct drm_i915_private *dev_priv,
- i915_reg_t imr, u32 imr_val,
- i915_reg_t ier, u32 ier_val,
- i915_reg_t iir)
+ u32 imr_val, u32 ier_val)
{
- gen2_assert_iir_is_zero(dev_priv, iir);
+ gen2_assert_iir_is_zero(dev_priv);
- I915_WRITE16(ier, ier_val);
- I915_WRITE16(imr, imr_val);
- POSTING_READ16(imr);
+ I915_WRITE16(IER, ier_val);
+ I915_WRITE16(IMR, imr_val);
+ POSTING_READ16(IMR);
}
#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
@@ -253,11 +249,8 @@ static void gen2_irq_init(struct drm_i915_private
*dev_priv,
type##IER, ier_val, \
type##IIR)
-#define GEN2_IRQ_INIT(type, imr_val, ier_val) \
- gen2_irq_init(dev_priv, \
- type##IMR, imr_val, \
- type##IER, ier_val, \
- type##IIR)
+#define GEN2_IRQ_INIT(imr_val, ier_val) \
+ gen2_irq_init(dev_priv, imr_val, ier_val)
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
@@ -4247,7 +4240,7 @@ static int i8xx_irq_postinstall(struct drm_device *dev)
I915_MASTER_ERROR_INTERRUPT |
I915_USER_INTERRUPT;
- GEN2_IRQ_INIT(, dev_priv->irq_mask, enable_mask);
+ GEN2_IRQ_INIT(dev_priv->irq_mask, enable_mask);
/* Interrupt setup is already guaranteed to be single-threaded, this is
* just to make the assert_spin_locked check happy. */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Don't disable interrupts independently of the lock
== Series Details == Series: drm/i915: Don't disable interrupts independently of the lock URL : https://patchwork.freedesktop.org/series/59289/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5899_full -> Patchwork_12755_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12755_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12755_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_12755_full: ### IGT changes ### Possible regressions * igt@gem_tiled_swapping@non-threaded: - shard-iclb: NOTRUN -> INCOMPLETE Known issues Here are the changes found in Patchwork_12755_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@close-race: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@gem_exec_basic@basic-bsd1: - shard-snb: NOTRUN -> SKIP [fdo#109271] +35 * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +3 * igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: - shard-iclb: NOTRUN -> SKIP [fdo#110206] * igt@gem_pwrite@stolen-normal: - shard-iclb: NOTRUN -> SKIP [fdo#109277] * igt@gem_softpin@noreloc-s3: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +5 - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@i915_pm_rpm@universal-planes-dpms: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: - shard-apl: PASS -> FAIL [fdo#109660] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@basic-modeset-e: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +1 * igt@kms_busy@extended-modeset-hang-newfb-render-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-modeset-hang-oldfb-render-d: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +8 * igt@kms_chamelium@vga-hpd-fast: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +2 * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +1 * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic: - shard-snb: PASS -> SKIP [fdo#109271] * igt@kms_flip@2x-plain-flip-ts-check: - shard-apl: NOTRUN -> SKIP [fdo#109271] +10 * igt@kms_flip@absolute-wf_vblank-interruptible: - shard-apl: NOTRUN -> INCOMPLETE [fdo#103927] * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_flip@flip-vs-suspend: - shard-kbl: PASS -> DMESG-FAIL [fdo#103375] * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff: - shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +8 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +68 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-gtt: - shard-iclb: PASS -> FAIL [fdo#109247] +11 * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-render: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +3 * igt@kms_lease@atomic_implicit_crtc: - shard-skl: NOTRUN -> FAIL [fdo#110279] * igt@kms_pipe_b_c_ivb@enable-pipe-c-while-b-has-3-lanes: - shard-iclb: NOTRUN -> SKIP [fdo#109289] * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * 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-transparant-fb: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] * igt@kms_plane_alpha_blend@pipe-c-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping:
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for IRQ initialization debloat and conversion to uncore
Em ter, 2019-04-09 às 21:20 +0300, Ville Syrjälä escreveu: > On Tue, Apr 09, 2019 at 10:34:22AM -0700, Paulo Zanoni wrote: > > Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu: > > > == Series Details == > > > > > > Series: IRQ initialization debloat and conversion to uncore > > > URL : https://patchwork.freedesktop.org/series/59202/ > > > State : warning > > > > > > == Summary == > > > > > > $ dim checkpatch origin/drm-tip > > > 7f73d1fe31bb drm/i915: refactor the IRQ init/reset macros > > > -:114: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > > side-effects? > > > #114: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > > > +#define GEN8_IRQ_RESET_NDX(type, which) \ > > > + gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \ > > > +GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > > > > > -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > > side-effects? > > > #172: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > > > +#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \ > > > + gen3_irq_init(dev_priv, GEN8_##type##_IMR(which), \ > > > + GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > > > + imr_val, ier_val) > > > > > > total: 0 errors, 0 warnings, 2 checks, 135 lines checked > > > 82160241d80f drm/i915: convert the IRQ initialization functions to > > > intel_uncore > > > 8c1c76059a41 drm/i915: fully convert the IRQ initialization macros to > > > intel_uncore > > > -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > > side-effects? > > > #24: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > > > +#define GEN8_IRQ_RESET_NDX(uncore, type, which) \ > > > + gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \ > > > GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > > > > > -:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > > side-effects? > > > #46: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > > > +#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \ > > > + gen3_irq_init((uncore), GEN8_##type##_IMR(which), \ > > > GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > > > imr_val, ier_val) > > > > The whiches are not really a regression, but OK we can deal with them > > to make the robots happy. > > > > > -:401: ERROR:SPACING: space prohibited before that close parenthesis ')' > > > #401: FILE: drivers/gpu/drm/i915/i915_irq.c:4228: > > > + GEN2_IRQ_RESET(uncore, ); > > > > > > -:416: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > > #416: FILE: drivers/gpu/drm/i915/i915_irq.c:4252: > > > + GEN2_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > > ^ > > > > > > -:433: ERROR:SPACING: space prohibited before that close parenthesis ')' > > > #433: FILE: drivers/gpu/drm/i915/i915_irq.c:4397: > > > + GEN3_IRQ_RESET(uncore, ); > > > > > > -:448: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > > #448: FILE: drivers/gpu/drm/i915/i915_irq.c:4430: > > > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > > ^ > > > > > > -:464: ERROR:SPACING: space prohibited before that close parenthesis ')' > > > #464: FILE: drivers/gpu/drm/i915/i915_irq.c:4508: > > > + GEN3_IRQ_RESET(uncore, ); > > > > > > -:479: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > > #479: FILE: drivers/gpu/drm/i915/i915_irq.c:4552: > > > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > > > For these ones I really think the spaces help. I would love to read > > some opinions. Perhaps some comment like /* paste token here */ would > > help make the code more readable and could help silence checkpatch. > > Opinions? > > Or maybe rename the registers to eg. I9XX_IIR? That makes more sense. We use these regs on gen2 too, so I suppose I8XX_IIR (or GEN2_IIR) would make more sense. OTOH it would break our current naming rule. I'll submit v2 soon. Thanks. > > > > ^ > > > > > > total: 6 errors, 0 warnings, 2 checks, 432 lines checked > > > > > > ___ > > > 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 > > -- > 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 series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 (rev2)
== Series Details == Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 (rev2) URL : https://patchwork.freedesktop.org/series/59278/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5899_full -> Patchwork_12754_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12754_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12754_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_12754_full: ### IGT changes ### Possible regressions * igt@kms_universal_plane@universal-plane-pipe-c-sanity: - shard-apl: PASS -> DMESG-WARN Known issues Here are the changes found in Patchwork_12754_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +4 * igt@gem_ctx_isolation@vcs0-s3: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@gem_exec_basic@basic-bsd1: - shard-snb: NOTRUN -> SKIP [fdo#109271] +35 * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +9 * igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: - shard-iclb: NOTRUN -> SKIP [fdo#110206] * igt@gem_pread@stolen-normal: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +1 * igt@gem_tiled_swapping@non-threaded: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#108686] * igt@gem_workarounds@suspend-resume: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@i915_pm_lpsp@screens-disabled: - shard-iclb: NOTRUN -> SKIP [fdo#109301] * igt@i915_pm_rpm@cursor-dpms: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-modeset-hang-newfb-render-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-e: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +3 * igt@kms_busy@extended-modeset-hang-oldfb-render-d: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7 * igt@kms_chamelium@vga-hpd-fast: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +2 * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] * igt@kms_cursor_crc@cursor-512x170-sliding: - shard-iclb: NOTRUN -> SKIP [fdo#109279] * igt@kms_cursor_crc@cursor-64x21-onscreen: - shard-skl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: - shard-glk: PASS -> FAIL [fdo#106509] / [fdo#107409] * igt@kms_cursor_legacy@cursorb-vs-flipa-toggle: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +3 * igt@kms_flip@2x-plain-flip-ts-check: - shard-apl: NOTRUN -> SKIP [fdo#109271] +36 * igt@kms_flip@busy-flip: - shard-skl: PASS -> FAIL [fdo#103257] * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_flip@flip-vs-suspend: - shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +68 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-render: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +12 * igt@kms_frontbuffer_tracking@fbcpsr-tilingchange: - shard-iclb: PASS -> FAIL [fdo#109247] +15 * igt@kms_lease@atomic_implicit_crtc: - shard-skl: NOTRUN -> FAIL [fdo#110279] * igt@kms_lease@setcrtc_implicit_plane: - shard-skl: NOTRUN -> FAIL [fdo#110281] * igt@kms_plane_alpha_blend@pipe-a-alpha-basic: - shard-apl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-kbl: NOTRUN -> FAIL [fdo#108145] / [fdo#108590] *
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/icl: Handle rps interrupts without irq lock
== Series Details == Series: series starting with [CI,1/2] drm/i915/icl: Handle rps interrupts without irq lock URL : https://patchwork.freedesktop.org/series/59288/ State : success == Summary == CI Bug Log - changes from CI_DRM_5899_full -> Patchwork_12753_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12753_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_basic@basic-bsd1: - shard-snb: NOTRUN -> SKIP [fdo#109271] +35 * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +9 * igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: - shard-iclb: NOTRUN -> SKIP [fdo#110206] * igt@gem_pread@stolen-normal: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +1 * igt@i915_pm_lpsp@screens-disabled: - shard-iclb: NOTRUN -> SKIP [fdo#109301] * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107807] * igt@i915_suspend@debugfs-reader: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +1 * igt@kms_atomic_transition@6x-modeset-transitions: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-modeset-hang-newfb-render-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-e: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +3 * igt@kms_busy@extended-modeset-hang-oldfb-render-d: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +8 * igt@kms_chamelium@vga-hpd-fast: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +2 * igt@kms_color@pipe-a-ctm-0-25: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_cursor_crc@cursor-512x170-sliding: - shard-iclb: NOTRUN -> SKIP [fdo#109279] * igt@kms_cursor_legacy@cursorb-vs-flipa-toggle: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +3 * igt@kms_flip@2x-plain-flip-ts-check: - shard-apl: NOTRUN -> SKIP [fdo#109271] +10 * igt@kms_flip@absolute-wf_vblank-interruptible: - shard-apl: NOTRUN -> INCOMPLETE [fdo#103927] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: PASS -> FAIL [fdo#102887] / [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +68 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-iclb: PASS -> FAIL [fdo#103167] +3 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: PASS -> FAIL [fdo#109247] +13 * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-render: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +12 * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-cpu: - shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-msflip-blt: - shard-iclb: NOTRUN -> FAIL [fdo#109247] +2 * igt@kms_lease@atomic_implicit_crtc: - shard-skl: NOTRUN -> FAIL [fdo#110279] * igt@kms_lease@setcrtc_implicit_plane: - shard-skl: NOTRUN -> FAIL [fdo#110281] * igt@kms_plane@pixel-format-pipe-a-planes: - shard-iclb: PASS -> INCOMPLETE [fdo#110036 ] * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * 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-transparant-fb: - shard-kbl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-basic: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_psr@cursor_plane_onoff: - shard-iclb: NOTRUN -> FAIL [fdo#107383] / [fdo#110215] * igt@kms_psr@primary_blt: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +2 * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: PASS -> SKIP [fdo#109441] +1 * igt@kms_rotation_crc@bad-pixel-format: - shard-iclb: NOTRUN -> SKIP [fdo#109289] +1 * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] * igt@kms_universal_plane@universal-plane-gen9-features-pipe-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@perf_pmu@busy-accuracy-50-vcs1: - shard-skl: NOTRUN -> SKIP
Re: [Intel-gfx] [PATCH 1/3] drm/i915: refactor the IRQ init/reset macros
Em ter, 2019-04-09 às 21:10 +0300, Ville Syrjälä escreveu:
> On Mon, Apr 08, 2019 at 05:37:27PM -0700, Paulo Zanoni wrote:
> > The whole point of having macros here is for the token pasting
> > necessary to automatically have IMR, IIR and IER selected. We don't
> > really need or want all the inlining that happens as a consequence.
> > The good thing about the current code is that it works regardless of
> > the relative offsets between these registers (they change after gen3).
>
> Did you mean "after gen4"? The DE/GT split happened at ilk, and I
> guess that's when the four registers also got reshuffled for some
> reason. Ignoring the funkyness of vlv/chv or course :)
>
You're right. I'll fix the commit message.
> > One thing which we can do is to split the logic of what we do with
> > imr/ier/iir to functions separate from the macros that pick them.
> > That's what we do in this commit. This allows us to get rid of the
> > gen8 duplicates and also all the inlining:
> >
> > add/remove: 2/0 grow/shrink: 0/21 up/down: 383/-6006 (-5623)
> > Function old new delta
> > gen3_irq_reset - 233+233
> > gen3_irq_init - 150+150
> > i8xx_irq_postinstall 459 442 -17
> > gen11_irq_postinstall804 744 -60
> > ironlake_irq_postinstall 450 353 -97
> > vlv_display_irq_postinstall 348 245-103
> > i965_irq_postinstall 378 275-103
> > i915_irq_postinstall 333 228-105
> > gen8_irq_power_well_post_enable 374 210-164
> > ironlake_irq_reset 397 218-179
> > vlv_display_irq_reset616 433-183
> > i965_irq_reset 374 180-194
> > cherryview_irq_reset 379 185-194
> > i915_irq_reset 407 209-198
> > ibx_irq_reset332 133-199
> > gen5_gt_irq_postinstall 533 332-201
> > gen8_irq_power_well_pre_disable 434 204-230
> > gen8_gt_irq_postinstall 469 196-273
> > gen8_de_irq_postinstall 1200 805-395
> > gen5_gt_irq_reset471 76-395
> > gen8_gt_irq_reset775 99-676
> > gen8_irq_reset 1100 333-767
> > gen11_irq_reset 1959 686 -1273
> > Total: Before=2262051, After=2256428, chg -0.25%
> >
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 123 +++-
> > 1 file changed, 73 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 6454ddc37f8b..a1e7944fb5d0 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -136,36 +136,45 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
> > [HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
> > };
> >
> > -/* IIR can theoretically queue up two events. Be paranoid. */
> > -#define GEN8_IRQ_RESET_NDX(type, which) do { \
> > - I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> > - POSTING_READ(GEN8_##type##_IMR(which)); \
> > - I915_WRITE(GEN8_##type##_IER(which), 0); \
> > - I915_WRITE(GEN8_##type##_IIR(which), 0x); \
> > - POSTING_READ(GEN8_##type##_IIR(which)); \
> > - I915_WRITE(GEN8_##type##_IIR(which), 0x); \
> > - POSTING_READ(GEN8_##type##_IIR(which)); \
> > -} while (0)
> > -
> > -#define GEN3_IRQ_RESET(type) do { \
> > - I915_WRITE(type##IMR, 0x); \
> > - POSTING_READ(type##IMR); \
> > - I915_WRITE(type##IER, 0); \
> > - I915_WRITE(type##IIR, 0x); \
> > - POSTING_READ(type##IIR); \
> > - I915_WRITE(type##IIR, 0x); \
> > - POSTING_READ(type##IIR); \
> > -} while (0)
> > -
> > -#define GEN2_IRQ_RESET(type) do { \
> > - I915_WRITE16(type##IMR, 0x); \
> > - POSTING_READ16(type##IMR); \
> > - I915_WRITE16(type##IER, 0); \
> > - I915_WRITE16(type##IIR, 0x); \
> > - POSTING_READ16(type##IIR); \
> > - I915_WRITE16(type##IIR, 0x); \
> > - POSTING_READ16(type##IIR); \
> > -} while (0)
> > +static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t
> > imr,
> > + i915_reg_t iir, i915_reg_t ier)
> > +{
> > + I915_WRITE(imr, 0x);
> > + POSTING_READ(imr);
> > +
> > + I915_WRITE(ier, 0);
> > +
> > + /* IIR can theoretically queue up two events. Be paranoid. */
> > + I915_WRITE(iir, 0x);
> > + POSTING_READ(iir);
> > + I915_WRITE(iir, 0x);
> > + POSTING_READ(iir);
> > +}
> > +
> > +static void gen2_irq_reset(struct
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only reset the pinned kernel contexts on resume (rev2)
== Series Details == Series: drm/i915: Only reset the pinned kernel contexts on resume (rev2) URL : https://patchwork.freedesktop.org/series/58589/ State : success == Summary == CI Bug Log - changes from CI_DRM_5901 -> Patchwork_12759 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/58589/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12759 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_basic@gtt-bsd2: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +57 * igt@kms_busy@basic-flip-c: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_force_connector_basic@force-edid: - fi-glk-dsi: NOTRUN -> SKIP [fdo#109271] +36 * igt@kms_frontbuffer_tracking@basic: - fi-glk-dsi: NOTRUN -> FAIL [fdo#103167] - fi-byt-clapper: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] Possible fixes * igt@gem_mmap_gtt@basic-copy: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (51 -> 42) -- Additional (1): fi-byt-clapper Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-bsw-kefka fi-skl-lmem fi-bdw-samus Build changes - * Linux: CI_DRM_5901 -> Patchwork_12759 CI_DRM_5901: b98dd01c0ecc2b44c010d0372f35c87abdd4382f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4942: ff8929d4d5b57b544e699fa428930f0fd66dd2dc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12759: 6582fd43ffd2e654cc050aac83f2e13ac58d7189 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6582fd43ffd2 drm/i915: Only reset the pinned kernel contexts on resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12759/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/22] drm/i915: Explicitly pin the logical context for execbuf
Quoting Tvrtko Ursulin (2019-04-02 17:09:18)
>
> On 25/03/2019 09:03, Chris Wilson wrote:
> > @@ -2120,20 +2150,20 @@ eb_select_engine(struct drm_i915_private *dev_priv,
> > } else {
> > DRM_DEBUG("execbuf with unknown bsd ring: %u\n",
> > bsd_idx);
> > - return NULL;
> > + return -EINVAL;
> > }
> >
> > - engine = dev_priv->engine[_VCS(bsd_idx)];
> > + engine = eb->i915->engine[_VCS(bsd_idx)];
> > } else {
> > - engine = dev_priv->engine[user_ring_map[user_ring_id]];
> > + engine = eb->i915->engine[user_ring_map[user_ring_id]];
>
> Cache dev_priv/i915 in a local?
i915_gem_do_execbuffer 47424740 -2
Barely seems worth it this time.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Da.*, Another week, another PR. A bit less to digest this week from last, but still very dense when looking at LoC/patch. drm-misc-next-2019-04-10: drm-misc-next for 5.2: UAPI Changes: - None Cross-subsystem Changes: -MAINTAINERS: Add moderation flag for lima mailing list (Randy) -dt-bindings: Add Mali Bifrost bindings (Neil) -dt-bindings: Add G12A compatibility strings to meson bindings (Neil) Core Changes: -Add a handful of format helpers (Gerd) Driver Changes: -cirrus: Driver rewrite megapatch (Gerd) -meson: Add G12A support to meson driver (Neil) -lima: Couple fixes (Qiang) Cc: Gerd Hoffmann Cc: Randy Dunlap Cc: Neil Armstrong Cc: Qiang Yu Cheers, Sean The following changes since commit f15a3ea80391e83f32d4a23f83b1f02415cd5889: MAINTAINERS: Add ASPEED BMC GFX DRM driver entry (2019-04-04 11:57:34 +1030) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-04-10 for you to fetch changes up to 80bb8d983224337b713a93babfffedb376031034: drm/lima: include used header file explicitly (2019-04-09 19:05:59 +0800) drm-misc-next for 5.2: UAPI Changes: - None Cross-subsystem Changes: -MAINTAINERS: Add moderation flag for lima mailing list (Randy) -dt-bindings: Add Mali Bifrost bindings (Neil) -dt-bindings: Add G12A compatibility strings to meson bindings (Neil) Core Changes: -Add a handful of format helpers (Gerd) Driver Changes: -cirrus: Driver rewrite megapatch (Gerd) -meson: Add G12A support to meson driver (Neil) -lima: Couple fixes (Qiang) Cc: Gerd Hoffmann Cc: Randy Dunlap Cc: Neil Armstrong Cc: Qiang Yu Gerd Hoffmann (5): drm: move tinydrm format conversion helpers to new drm_format_helper.c drm: add drm_fb_memcpy_dstclip() helper drm: add drm_fb_xrgb_to_rgb565_dstclip() drm: add drm_fb_xrgb_to_rgb888_dstclip() drm/cirrus: rewrite and modernize driver. Joe Perches (1): drm/panel: Rocktech jh057n00900: Add terminating newlines to logging Neil Armstrong (14): dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU dt-bindings: display: amlogic, meson-vpu: Add G12A compatible and ports dt-bindings: display: amlogic, meson-dw-hdmi: Add G12A compatible and ports drm/meson: Switch PLL to 5.94GHz base for 297Mhz pixel clock drm/meson: Add registers for G12A SoC drm/meson: Add G12A Support for VPP setup drm/meson: Add G12A Support for VIU setup drm/meson: Add G12A support for OSD1 Plane drm/meson: Add G12A Support for the Overlay video plane drm/meson: Add G12A support for plane handling in CRTC driver drm/meson: Add G12A support for CVBS Encoder drm/meson: Add G12A Video Clock setup drm/meson: Add G12A compatible drm/meson: Add G12A support for the DW-HDMI Glue Qiang Yu (2): drm/lima: add missing Kconfig dependency drm/lima: include used header file explicitly Randy Dunlap (1): MAINTAINERS: mark lima mailing list as moderated Sean Paul (1): Documentation/gpu/meson: Remove link to meson_canvas.c Wen Yang (1): drm/pl111: fix possible object reference leak kbuild test robot (1): drm/vc4: vc4_debugfs_regset32() can be static .../bindings/display/amlogic,meson-dw-hdmi.txt | 4 + .../bindings/display/amlogic,meson-vpu.txt | 4 + .../devicetree/bindings/gpu/arm,mali-bifrost.txt | 92 +++ Documentation/gpu/meson.rst| 6 - MAINTAINERS| 2 +- drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/cirrus/Kconfig | 2 +- drivers/gpu/drm/cirrus/Makefile| 3 - drivers/gpu/drm/cirrus/cirrus.c| 657 + drivers/gpu/drm/cirrus/cirrus_drv.c| 161 - drivers/gpu/drm/cirrus/cirrus_drv.h| 251 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 309 -- drivers/gpu/drm/cirrus/cirrus_main.c | 328 -- drivers/gpu/drm/cirrus/cirrus_mode.c | 617 --- drivers/gpu/drm/cirrus/cirrus_ttm.c| 343 --- drivers/gpu/drm/drm_format_helper.c| 326 ++ drivers/gpu/drm/lima/Kconfig | 3 + drivers/gpu/drm/lima/lima_gem.c| 1 + drivers/gpu/drm/meson/meson_crtc.c | 269 +++-- drivers/gpu/drm/meson/meson_drv.c | 1 + drivers/gpu/drm/meson/meson_drv.h | 4 + drivers/gpu/drm/meson/meson_dw_hdmi.c | 163 +++-- drivers/gpu/drm/meson/meson_dw_hdmi.h | 32 +- drivers/gpu/drm/meson/meson_overlay.c | 10 +- drivers/gpu/drm/meson/meson_plane.c| 15 +-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix SDVO HDMI audio (rev3)
== Series Details ==
Series: drm/i915: Fix SDVO HDMI audio (rev3)
URL : https://patchwork.freedesktop.org/series/59233/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5901 -> Patchwork_12758
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/59233/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_12758 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_basic@gtt-bsd2:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +57
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:PASS -> SKIP [fdo#109271] +3
* igt@i915_selftest@live_hangcheck:
- fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@basic-flip-c:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_force_connector_basic@force-edid:
- fi-glk-dsi: NOTRUN -> SKIP [fdo#109271] +36
* igt@kms_frontbuffer_tracking@basic:
- fi-glk-dsi: NOTRUN -> FAIL [fdo#103167]
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103167]
Possible fixes
* igt@gem_exec_create@basic:
- {fi-icl-u2}:INCOMPLETE -> PASS
* igt@gem_mmap_gtt@basic-copy:
- fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109316]: https://bugs.freedesktop.org/show_bug.cgi?id=109316
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
[fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (51 -> 45)
--
Additional (1): fi-byt-clapper
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5901 -> Patchwork_12758
CI_DRM_5901: b98dd01c0ecc2b44c010d0372f35c87abdd4382f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4942: ff8929d4d5b57b544e699fa428930f0fd66dd2dc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12758: 68a1ff7a23e70b0d053dcddec443ce668395b0cd @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
68a1ff7a23e7 drm/i915/sdvo: Actually print the reason why the SDVO command
failed
30a08be915cd drm/i915/sdvo: Don't write stack garbage into the hbuf
f0553da8c483 drm/i915/sdvo: Don't unpack stack garbage
d7582b927aab drm/i915/sdvo: Check that we have space for the infoframe
1435c2f97a75 drm/i915: Rename SDVO_AUDIO_ENABLE to HDMI_AUDIO_ENABLE
c315b5ed8f4d drm/i915/sdvo: Implement proper HDMI audio support for SDVO
c2d2ff8faada drm/i915/sdvo: Fix AVI infoframe TX rate readout
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12758/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/29] drm/i915: Export intel_context_instance()
Quoting Tvrtko Ursulin (2019-04-10 13:06:04)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > We want to pass in a intel_context into intel_context_pin() and that
> > requires us to first be able to lookup the intel_context!
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c| 37 +++---
> > drivers/gpu/drm/i915/gt/intel_context.h| 19 +++
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 -
> > drivers/gpu/drm/i915/gt/mock_engine.c | 8 -
> > drivers/gpu/drm/i915/gvt/scheduler.c | 7 +++-
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +--
> > drivers/gpu/drm/i915/i915_perf.c | 21
> > drivers/gpu/drm/i915/i915_request.c| 11 ++-
> > 8 files changed, 83 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 6ae6a3f58364..a1267739e369 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -104,7 +104,7 @@ void __intel_context_remove(struct intel_context *ce)
> > spin_unlock(>hw_contexts_lock);
> > }
> >
> > -static struct intel_context *
> > +struct intel_context *
> > intel_context_instance(struct i915_gem_context *ctx,
> > struct intel_engine_cs *engine)
> > {
> > @@ -112,7 +112,7 @@ intel_context_instance(struct i915_gem_context *ctx,
> >
> > ce = intel_context_lookup(ctx, engine);
> > if (likely(ce))
> > - return ce;
> > + return intel_context_get(ce);
> >
> > ce = intel_context_alloc();
> > if (!ce)
> > @@ -125,7 +125,7 @@ intel_context_instance(struct i915_gem_context *ctx,
> > intel_context_free(ce);
> >
> > GEM_BUG_ON(intel_context_lookup(ctx, engine) != pos);
> > - return pos;
> > + return intel_context_get(pos);
> > }
> >
> > struct intel_context *
> > @@ -139,30 +139,30 @@ intel_context_pin_lock(struct i915_gem_context *ctx,
> > if (IS_ERR(ce))
> > return ce;
> >
> > - if (mutex_lock_interruptible(>pin_mutex))
> > + if (mutex_lock_interruptible(>pin_mutex)) {
> > + intel_context_put(ce);
> > return ERR_PTR(-EINTR);
> > + }
> >
> > return ce;
> > }
> >
> > -struct intel_context *
> > -intel_context_pin(struct i915_gem_context *ctx,
> > - struct intel_engine_cs *engine)
> > +void intel_context_pin_unlock(struct intel_context *ce)
> > + __releases(ce->pin_mutex)
> > {
> > - struct intel_context *ce;
> > - int err;
> > -
> > - ce = intel_context_instance(ctx, engine);
> > - if (IS_ERR(ce))
> > - return ce;
> > + mutex_unlock(>pin_mutex);
> > + intel_context_put(ce);
> > +}
> >
> > - if (likely(atomic_inc_not_zero(>pin_count)))
> > - return ce;
> > +int __intel_context_do_pin(struct intel_context *ce)
> > +{
> > + int err;
> >
> > if (mutex_lock_interruptible(>pin_mutex))
> > - return ERR_PTR(-EINTR);
> > + return -EINTR;
> >
> > if (likely(!atomic_read(>pin_count))) {
> > + struct i915_gem_context *ctx = ce->gem_context;
> > intel_wakeref_t wakeref;
> >
> > err = 0;
> > @@ -172,7 +172,6 @@ intel_context_pin(struct i915_gem_context *ctx,
> > goto err;
> >
> > i915_gem_context_get(ctx);
> > - GEM_BUG_ON(ce->gem_context != ctx);
> >
> > mutex_lock(>mutex);
> > list_add(>active_link, >active_engines);
> > @@ -186,11 +185,11 @@ intel_context_pin(struct i915_gem_context *ctx,
> > GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
> >
> > mutex_unlock(>pin_mutex);
> > - return ce;
> > + return 0;
> >
> > err:
> > mutex_unlock(>pin_mutex);
> > - return ERR_PTR(err);
> > + return err;
> > }
> >
> > void intel_context_unpin(struct intel_context *ce)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > b/drivers/gpu/drm/i915/gt/intel_context.h
> > index 9aeef88176b9..da342e9a8c2e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -49,11 +49,7 @@ intel_context_is_pinned(struct intel_context *ce)
> > return atomic_read(>pin_count);
> > }
> >
> > -static inline void intel_context_pin_unlock(struct intel_context *ce)
> > -__releases(ce->pin_mutex)
> > -{
> > - mutex_unlock(>pin_mutex);
> > -}
>
> Could leave this as static inline since the only addition is kref_put so
> compiler could decide what to do? Don't mind either way.
In the next (or two) patch.
> > +void intel_context_pin_unlock(struct intel_context *ce);
> >
> > struct intel_context *
> > __intel_context_insert(struct i915_gem_context *ctx,
> > @@ -63,7 +59,18 @@
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Only reset the pinned kernel contexts on resume (rev2)
== Series Details == Series: drm/i915: Only reset the pinned kernel contexts on resume (rev2) URL : https://patchwork.freedesktop.org/series/58589/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Only reset the pinned kernel contexts on resume -drivers/gpu/drm/i915/selftests/../i915_drv.h:3617:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3616:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/29] drm/i915: Introduce context->enter() and context->exit()
Quoting Tvrtko Ursulin (2019-04-10 12:06:49) > > On 10/04/2019 11:13, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-04-10 11:05:13) > >> And some lockdep_assert_held in all three? > > > > Read on :( > > > > The plan is for intel_context_enter/_exit to be under the > > timeline->mutex, but that isn't realised for about another 30 patches. > > > > mark_active has special protection because it gets used from the > > serialised portion of intel_engine_park. > > Ok, but bug on for zero active_count makes sense right? Maybe even > intel_context_pin_active to signify that it can only act on an already > active context? It get's called on the kernel_context with ce->active_count==0 and not even holding the mutex from inside the wakeref handling code. (On no, I've invented a new BKL --- well a parking brake.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Only reset the pinned kernel contexts on resume
On resume, we know that the only pinned contexts in danger of seeing
corruption are the kernel context, and so we do not need to walk the
list of all GEM contexts as we tracked them on each engine.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 1 -
drivers/gpu/drm/i915/i915_gem.c| 9 ++--
drivers/gpu/drm/i915/intel_context_types.h | 1 +
drivers/gpu/drm/i915/intel_engine_cs.c | 24 +++
drivers/gpu/drm/i915/intel_lrc.c | 49 +++---
drivers/gpu/drm/i915/intel_lrc.h | 1 -
drivers/gpu/drm/i915/intel_ringbuffer.c| 17
drivers/gpu/drm/i915/intel_ringbuffer.h| 3 +-
8 files changed, 60 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 63eca3061d10..35d0782c077e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1995,7 +1995,6 @@ struct drm_i915_private {
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct {
- void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
struct i915_gt_timelines {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bf3d12f94365..0a818a60ad31 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4513,7 +4513,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
* guarantee that the context image is complete. So let's just reset
* it and start again.
*/
- i915->gt.resume(i915);
+ intel_gt_resume(i915);
if (i915_gem_init_hw(i915))
goto err_wedged;
@@ -4853,13 +4853,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
dev_priv->mm.unordered_timeline = dma_fence_context_alloc(1);
- if (HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {
- dev_priv->gt.resume = intel_lr_context_resume;
+ if (HAS_LOGICAL_RING_CONTEXTS(dev_priv))
dev_priv->gt.cleanup_engine = intel_logical_ring_cleanup;
- } else {
- dev_priv->gt.resume = intel_legacy_submission_resume;
+ else
dev_priv->gt.cleanup_engine = intel_engine_cleanup;
- }
i915_timelines_init(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_context_types.h
b/drivers/gpu/drm/i915/intel_context_types.h
index 624729a35875..68b4ca1611e0 100644
--- a/drivers/gpu/drm/i915/intel_context_types.h
+++ b/drivers/gpu/drm/i915/intel_context_types.h
@@ -24,6 +24,7 @@ struct intel_context_ops {
int (*pin)(struct intel_context *ce);
void (*unpin)(struct intel_context *ce);
+ void (*reset)(struct intel_context *ce);
void (*destroy)(struct kref *kref);
};
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index d0427c2e3997..f29a667cad52 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -753,6 +753,30 @@ int intel_engine_init_common(struct intel_engine_cs
*engine)
return ret;
}
+void intel_gt_resume(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /*
+* After resume, we may need to poke into the pinned kernel
+* contexts to paper over any damage caused by the sudden suspend.
+* Only the kernel contexts should remain pinned over suspend,
+* allowing us to fixup the user contexts on their first pin.
+*/
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce;
+
+ ce = engine->kernel_context;
+ if (ce)
+ ce->ops->reset(ce);
+
+ ce = engine->preempt_context;
+ if (ce)
+ ce->ops->reset(ce);
+ }
+}
+
/**
* intel_engines_cleanup_common - cleans up the engine state created by
*the common initiailizers.
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6931dbb2888c..b54dbf36197e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1379,9 +1379,33 @@ static int execlists_context_pin(struct intel_context
*ce)
return __execlists_context_pin(ce, ce->engine);
}
+static void execlists_context_reset(struct intel_context *ce)
+{
+ /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
+* between our bookkeeping in ce->ring->head and ce->ring->tail and
+* that stored in context. As we only write new commands from
+* ce->ring->tail onwards, everything before that is junk. If the GPU
+* starts reading from its RING_HEAD from the context, it may try to
+* execute that junk and die.
+*
+* The
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Simplify some icl pll calculations
On Wed, Apr 10, 2019 at 07:13:48PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2019-04-10 18:59:52)
> > On Mon, Apr 08, 2019 at 06:05:06PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjälä (2019-04-08 17:06:01)
> > > > On Mon, Apr 08, 2019 at 04:49:13PM +0100, Chris Wilson wrote:
> > > > > Quoting Ville Syrjala (2019-04-08 16:27:02)
> > > > > > - /*
> > > > > > -* Adjust the original formula to delay the division by
> > > > > > 2^22 in order to
> > > > > > -* minimize possible rounding errors.
> > > > > > -*/
> > > > > > - tmp = (u64)m1 * m2_int * ref_clock +
> > > > > > - (((u64)m1 * m2_frac * ref_clock) >> 22);
> > > > > > - tmp = div_u64(tmp, 5 * div1 * div2);
> > > > > > -
> > > > > > - return tmp;
> > > > > > + return div_u64(mul_u32_u32(ref_clock * m1, m2),
> > > > > > + (5 * div1 * div2) << 22);
> > > > >
> > > > > You say the denominator here is a u64, so do you not need to cast
> > > > > (u64)(5 * d1 * d2) to ensure it doesn't overflow the shift?
> > > >
> > > > It should fit into u32. The maximum value should be
> > > > <= (5*0xf*0x7)<<22 based on the number of bits available
> > > 3b * 4b * 3b = 10b. So just fits.
> > >
> > > Is it worth asserting those limits? Feels like it is running close, and
> > > will be subject to cargo-culting.
> >
> > I suppose checking for it might be a good idea.
> >
> > Just 'WARN_ON(5 * div1 * div2 >= 1 << 10)' maybe, or were you thinking
> > of something fancier?
>
> How about something like
> struct {
> unsigned int div1 : 3;
> unsigned int div2 : 3;
> } d;
>
> then with a bit of luck smatch will spot an overflow, and people might
> think twice when copying?
>
> Even weirder,
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-29 (-29)
> Function old new delta
> intel_ddi_get_config23772348 -29
>
> I dread to look into the function to see how that changed gcc's mind.
I get 48 bytes with a 32bit build, but only if I let it inline that
function. With noinline there is no change apart from a few registers
getting shuffled around. gcc works in mysterious ways.
--
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/2] drm/i915: Use mul_u32_u32() more
On Mon, Apr 08, 2019 at 04:44:04PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-04-08 16:27:01)
> > From: Ville Syrjälä
> >
> > We have a lot of '(u64)foo * bar' everywhere. Replace with
> > mul_u32_u32() to avoid gcc failing to use a regular 32x32->64
> > multiply for this.
> >
> > Signed-off-by: Ville Syrjälä
>
> As a purely mechanical translation,
> Reviewed-by: Chris Wilson
>
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index e01c057ce50b..29edc369920b 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2741,11 +2741,11 @@ static bool icl_calc_mg_pll_state(struct
> > intel_crtc_state *crtc_state)
> > }
> >
> > if (use_ssc) {
> > - tmp = (u64)dco_khz * 47 * 32;
> > + tmp = mul_u32_u32(dco_khz, 47 * 32);
> > do_div(tmp, refclk_khz * m1div * 1);
> > ssc_stepsize = tmp;
> >
> > - tmp = (u64)dco_khz * 1000;
> > + tmp = mul_u32_u32(dco_khz, 1000);
>
> These caught my eye, wondering if the code was better reduced if the
> constant was first or itself cast to (u64).
Looks like gcc (8.2) handles these two as is actually. Or at least
the generated asm is identical both ways.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Hexdump enhancements
== Series Details == Series: Hexdump enhancements URL : https://patchwork.freedesktop.org/series/59296/ State : success == Summary == CI Bug Log - changes from CI_DRM_5900 -> Patchwork_12757 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59296/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12757 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: - fi-byt-clapper: PASS -> FAIL [fdo#103191] +1 Possible fixes * igt@i915_selftest@live_evict: - fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS * igt@i915_selftest@live_hangcheck: - fi-bxt-dsi: INCOMPLETE [fdo#103927] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-byt-clapper: FAIL [fdo#103191] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 Participating hosts (51 -> 44) -- Missing(7): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-bdw-samus Build changes - * Linux: CI_DRM_5900 -> Patchwork_12757 CI_DRM_5900: 769a8fa8df6608ca386de13871aa789504b16665 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4941: 051ee61cd39a4378eded21e42b6c45e6fdc10d97 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12757: 3470b899c699f157d9a29339a3a37ff9e3fd9575 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3470b899c699 lib/hexdump.c: Allow multiple groups to be separated by lines '|' 560d296fb9d8 lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags 49ccc448ceaa lib/hexdump.c: Optionally suppress lines of filler bytes 4911981b19d1 lib/hexdump.c: Allow 64 bytes per line == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12757/ ___ 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: Simplify some icl pll calculations
Quoting Ville Syrjälä (2019-04-10 18:59:52)
> On Mon, Apr 08, 2019 at 06:05:06PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2019-04-08 17:06:01)
> > > On Mon, Apr 08, 2019 at 04:49:13PM +0100, Chris Wilson wrote:
> > > > Quoting Ville Syrjala (2019-04-08 16:27:02)
> > > > > - /*
> > > > > -* Adjust the original formula to delay the division by 2^22
> > > > > in order to
> > > > > -* minimize possible rounding errors.
> > > > > -*/
> > > > > - tmp = (u64)m1 * m2_int * ref_clock +
> > > > > - (((u64)m1 * m2_frac * ref_clock) >> 22);
> > > > > - tmp = div_u64(tmp, 5 * div1 * div2);
> > > > > -
> > > > > - return tmp;
> > > > > + return div_u64(mul_u32_u32(ref_clock * m1, m2),
> > > > > + (5 * div1 * div2) << 22);
> > > >
> > > > You say the denominator here is a u64, so do you not need to cast
> > > > (u64)(5 * d1 * d2) to ensure it doesn't overflow the shift?
> > >
> > > It should fit into u32. The maximum value should be
> > > <= (5*0xf*0x7)<<22 based on the number of bits available
> > 3b * 4b * 3b = 10b. So just fits.
> >
> > Is it worth asserting those limits? Feels like it is running close, and
> > will be subject to cargo-culting.
>
> I suppose checking for it might be a good idea.
>
> Just 'WARN_ON(5 * div1 * div2 >= 1 << 10)' maybe, or were you thinking
> of something fancier?
How about something like
struct {
unsigned int div1 : 3;
unsigned int div2 : 3;
} d;
then with a bit of luck smatch will spot an overflow, and people might
think twice when copying?
Even weirder,
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-29 (-29)
Function old new delta
intel_ddi_get_config23772348 -29
I dread to look into the function to see how that changed gcc's mind.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for snd/hda: Only get/put display_power once (rev3)
== Series Details == Series: snd/hda: Only get/put display_power once (rev3) URL : https://patchwork.freedesktop.org/series/59267/ State : success == Summary == CI Bug Log - changes from CI_DRM_5898_full -> Patchwork_12752_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12752_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_pread@stolen-snoop: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +2 * igt@gem_pwrite@huge-gtt-fbr: - shard-iclb: NOTRUN -> SKIP [fdo#109290] * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - shard-iclb: NOTRUN -> SKIP [fdo#109308] * igt@i915_pm_rpm@i2c: - shard-skl: PASS -> INCOMPLETE [fdo#107807] +1 * igt@i915_pm_rpm@pm-tiling: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@i915_pm_rps@min-max-config-loaded: - shard-iclb: NOTRUN -> FAIL [fdo#108059] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@kms_atomic_transition@4x-modeset-transitions: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +16 * igt@kms_atomic_transition@plane-toggle-modeset-transition: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_busy@extended-modeset-hang-oldfb-render-e: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3 * igt@kms_busy@extended-pageflip-hang-oldfb-render-d: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +7 * igt@kms_chamelium@hdmi-cmp-nv61: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +4 * igt@kms_color@pipe-a-ctm-max: - shard-iclb: NOTRUN -> FAIL [fdo#108147] * igt@kms_content_protection@legacy: - shard-iclb: NOTRUN -> SKIP [fdo#109300] - shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_cursor_crc@cursor-512x512-sliding: - shard-iclb: NOTRUN -> SKIP [fdo#109279] * igt@kms_cursor_legacy@2x-flip-vs-cursor-legacy: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +4 * igt@kms_fbcon_fbt@psr: - shard-iclb: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: NOTRUN -> FAIL [fdo#105363] - shard-apl: PASS -> FAIL [fdo#102887] / [fdo#105363] * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: PASS -> INCOMPLETE [fdo#109507] * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +24 * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move: - shard-apl: NOTRUN -> SKIP [fdo#109271] +90 * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt: - shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu: - shard-iclb: PASS -> FAIL [fdo#109247] +12 * igt@kms_lease@cursor_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110278] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-kbl: PASS -> DMESG-WARN [fdo#108566] +1 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +2 * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-apl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] * igt@kms_psr2_su@frontbuffer: - shard-iclb: NOTRUN -> SKIP [fdo#109642] * igt@kms_psr@cursor_mmap_gtt: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +3 * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: NOTRUN -> SKIP [fdo#109441] +1 * igt@kms_rotation_crc@bad-pixel-format: - shard-iclb: NOTRUN -> SKIP [fdo#109289] +1 * igt@kms_sysfs_edid_timing: - shard-apl: NOTRUN -> FAIL [fdo#100047] * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +7 * igt@perf_pmu@busy-accuracy-50-vcs1: - shard-skl: NOTRUN -> SKIP [fdo#109271] +78 * igt@perf_pmu@busy-check-all-vecs0: - shard-snb: NOTRUN -> SKIP [fdo#109271] +112 * igt@prime_busy@wait-after-bsd2: - shard-iclb: NOTRUN -> SKIP [fdo#109276] +17 * igt@prime_nv_api@nv_i915_import_twice_check_flink_name: - shard-iclb: NOTRUN -> SKIP [fdo#109291] +3 * igt@tools_test@tools_test:
Re: [Intel-gfx] [PATCH v2] drm/i915/dp: revert back to max link rate and lane count on eDP
On Wed, Apr 10, 2019 at 03:54:23PM +0300, Jani Nikula wrote:
> On Fri, 05 Apr 2019, Rodrigo Vivi wrote:
> > On Fri, Apr 05, 2019 at 10:52:20AM +0300, Jani Nikula wrote:
> >> Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
> >> and narrow") started to optize the eDP 1.4+ link config, both per spec
> >> and as preparation for display stream compression support.
> >>
> >> Sadly, we again face panels that flat out fail with parameters they
> >> claim to support. Revert, and go back to the drawing board.
> >>
> >> v2: Actually revert to max params instead of just wide-and-slow.
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> >> Fixes: 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and
> >> narrow")
> >> Cc: Ville Syrjälä
> >> Cc: Manasi Navare
> >> Cc: Rodrigo Vivi
> >> Cc: Matt Atwood
> >> Cc: "Lee, Shawn C"
> >> Cc: Dave Airlie
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Cc: # v5.0+
> >> Signed-off-by: Jani Nikula
> >
> > I can hear from here your "I told you so"... Sorry!
> >
> > Reviewed-by: Rodrigo Vivi
>
> Thanks, pushed, please cherry-pick this for drm-intel-fixes.
done. going on tomorrow's pull request...
>
> BR,
> Jani.
>
>
>
> >
> >> ---
> >> drivers/gpu/drm/i915/intel_dp.c | 69 +
> >> 1 file changed, 10 insertions(+), 59 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index 72c490..dfa770 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -1856,42 +1856,6 @@ intel_dp_compute_link_config_wide(struct intel_dp
> >> *intel_dp,
> >>return -EINVAL;
> >> }
> >>
> >> -/* Optimize link config in order: max bpp, min lanes, min clock */
> >> -static int
> >> -intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> >> -struct intel_crtc_state *pipe_config,
> >> -const struct link_config_limits *limits)
> >> -{
> >> - struct drm_display_mode *adjusted_mode =
> >> _config->base.adjusted_mode;
> >> - int bpp, clock, lane_count;
> >> - int mode_rate, link_clock, link_avail;
> >> -
> >> - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> >> - mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> >> - bpp);
> >> -
> >> - for (lane_count = limits->min_lane_count;
> >> - lane_count <= limits->max_lane_count;
> >> - lane_count <<= 1) {
> >> - for (clock = limits->min_clock; clock <=
> >> limits->max_clock; clock++) {
> >> - link_clock = intel_dp->common_rates[clock];
> >> - link_avail = intel_dp_max_data_rate(link_clock,
> >> - lane_count);
> >> -
> >> - if (mode_rate <= link_avail) {
> >> - pipe_config->lane_count = lane_count;
> >> - pipe_config->pipe_bpp = bpp;
> >> - pipe_config->port_clock = link_clock;
> >> -
> >> - return 0;
> >> - }
> >> - }
> >> - }
> >> - }
> >> -
> >> - return -EINVAL;
> >> -}
> >> -
> >> static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> >> dsc_max_bpc)
> >> {
> >>int i, num_bpc;
> >> @@ -2028,15 +1992,13 @@ intel_dp_compute_link_config(struct intel_encoder
> >> *encoder,
> >>limits.min_bpp = 6 * 3;
> >>limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
> >>
> >> - if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
> >> + if (intel_dp_is_edp(intel_dp)) {
> >>/*
> >> * Use the maximum clock and number of lanes the eDP panel
> >> - * advertizes being capable of. The eDP 1.3 and earlier panels
> >> - * are generally designed to support only a single clock and
> >> - * lane configuration, and typically these values correspond to
> >> - * the native resolution of the panel. With eDP 1.4 rate select
> >> - * and DSC, this is decreasingly the case, and we need to be
> >> - * able to select less than maximum link config.
> >> + * advertizes being capable of. The panels are generally
> >> + * designed to support only a single clock and lane
> >> + * configuration, and typically these values correspond to the
> >> + * native resolution of the panel.
> >> */
> >>limits.min_lane_count = limits.max_lane_count;
> >>limits.min_clock = limits.max_clock;
> >> @@ -2050,22 +2012,11 @@ intel_dp_compute_link_config(struct intel_encoder
> >> *encoder,
> >> intel_dp->common_rates[limits.max_clock],
> >>
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Simplify some icl pll calculations
On Mon, Apr 08, 2019 at 06:05:06PM +0100, Chris Wilson wrote: > Quoting Ville Syrjälä (2019-04-08 17:06:01) > > On Mon, Apr 08, 2019 at 04:49:13PM +0100, Chris Wilson wrote: > > > Quoting Ville Syrjala (2019-04-08 16:27:02) > > > > - /* > > > > -* Adjust the original formula to delay the division by 2^22 in > > > > order to > > > > -* minimize possible rounding errors. > > > > -*/ > > > > - tmp = (u64)m1 * m2_int * ref_clock + > > > > - (((u64)m1 * m2_frac * ref_clock) >> 22); > > > > - tmp = div_u64(tmp, 5 * div1 * div2); > > > > - > > > > - return tmp; > > > > + return div_u64(mul_u32_u32(ref_clock * m1, m2), > > > > + (5 * div1 * div2) << 22); > > > > > > You say the denominator here is a u64, so do you not need to cast > > > (u64)(5 * d1 * d2) to ensure it doesn't overflow the shift? > > > > It should fit into u32. The maximum value should be > > <= (5*0xf*0x7)<<22 based on the number of bits available > 3b * 4b * 3b = 10b. So just fits. > > Is it worth asserting those limits? Feels like it is running close, and > will be subject to cargo-culting. I suppose checking for it might be a good idea. Just 'WARN_ON(5 * div1 * div2 >= 1 << 10)' maybe, or were you thinking of something fancier? -- 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/ehl: Add support for DPLL4 (v3)
On Tue, Apr 09, 2019 at 05:00:44PM -0700, Vivek Kasireddy wrote:
> On Mon, 8 Apr 2019 12:11:15 +0300
> Ville Syrjälä wrote:
> Hi,
>
> > On Fri, Apr 05, 2019 at 04:33:30PM -0700, Vivek Kasireddy wrote:
> > > On Fri, 5 Apr 2019 21:39:11 +0300
> > > Ville Syrjälä wrote:
> > > Hi Ville,
> > >
> > > > On Fri, Apr 05, 2019 at 09:33:56PM +0300, Ville Syrjälä wrote:
> > > > > On Fri, Apr 05, 2019 at 10:59:53AM -0700, Vivek Kasireddy
> > > > > wrote:
> > > > > > This patch adds support for DPLL4 on EHL that include the
> > > > > > following restrictions:
> > > > > >
> > > > > > - DPLL4 cannot be used with DDIA (combo port A internal eDP
> > > > > > usage). DPLL4 can be used with other DDIs, including DDID
> > > > > > (combo port A external usage).
> > > > > >
> > > > > > - DPLL4 cannot be enabled when DC5 or DC6 are enabled.
> > > > > >
> > > > > > - The DPLL4 enable, lock, power enabled, and power state are
> > > > > > connected to the MGPLL1_ENABLE register.
> > > > > >
> > > > > > v2: (suggestions from Bob Paauwe)
> > > > > > - Rework ehl_get_dpll() function to call
> > > > > > intel_find_shared_dpll() and iterate twice: once for Combo
> > > > > > plls and once for MG plls.
> > > > > >
> > > > > > - Use MG pll funcs for DPLL4 instead of creating new ones and
> > > > > > modify mg_pll_enable to include the restrictions for EHL.
> > > > > >
> > > > > > v3: Fix compilation error
> > > > > >
> > > > > > Cc: Lucas De Marchi
> > > > > > Signed-off-by: Vivek Kasireddy
> > > > > > Reviewed-by: Bob Paauwe
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 60
> > > > > > ++- 1 file changed, 59
> > > > > > insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c index
> > > > > > e01c057ce50b..c3f0b9720c54 100644 ---
> > > > > > a/drivers/gpu/drm/i915/intel_dpll_mgr.c +++
> > > > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c @@ -2870,6 +2870,56 @@
> > > > > > icl_get_dpll(struct intel_crtc_state *crtc_state, return pll;
> > > > > > }
> > > > > >
> > > > > > +static struct intel_shared_dpll *
> > > > > > +ehl_get_dpll(struct intel_crtc_state *crtc_state,
> > > > > > +struct intel_encoder *encoder)
> > > > > > +{
> > > > > > + struct drm_i915_private *dev_priv =
> > > > > > to_i915(crtc_state->base.crtc->dev);
> > > > > > + struct intel_shared_dpll *pll;
> > > > > > + enum port port = encoder->port;
> > > > > > + enum intel_dpll_id min, max;
> > > > > > + bool ret;
> > > > > > +
> > > > > > + if (!intel_port_is_combophy(dev_priv, port)) {
> > > > > > + MISSING_CASE(port);
> > > > > > + return NULL;
> > > > > > + }
> > > > > > +
> > > > > > + min = DPLL_ID_ICL_DPLL0;
> > > > > > + max = DPLL_ID_ICL_DPLL1;
> > > > > > + ret = icl_calc_dpll_state(crtc_state, encoder);
> > > > > > + if (ret) {
> > > > > > + pll = intel_find_shared_dpll(crtc_state, min,
> > > > > > max);
> > > > > > + if (pll) {
> > > > > > + intel_reference_shared_dpll(pll,
> > > > > > crtc_state);
> > > > > > + return pll;
> > > > > > + }
> > > > > > + } else {
> > > > > > + DRM_DEBUG_KMS("Could not calculate PLL
> > > > > > state.\n");
> > > > > > + }
> > > > > > +
> > > > > > + if (encoder->type == INTEL_OUTPUT_EDP) {
> > > > > > + DRM_DEBUG_KMS("Cannot use DPLL4 with
> > > > > > EDP.\n");
> > > > > > + return NULL;
> > > > > > + }
> > > > > > +
> > > > > > + min = max = DPLL_ID_ICL_MGPLL1;
> > > > > > + ret = icl_calc_mg_pll_state(crtc_state);
> > > > > > + if (!ret) {
> > > > > > + DRM_DEBUG_KMS("Could not calculate PLL
> > > > > > state.\n");
> > > > > > + return NULL;
> > > > > > + }
> > > > > > +
> > > > > > + pll = intel_find_shared_dpll(crtc_state, min, max);
> > > > > > + if (!pll) {
> > > > > > + DRM_DEBUG_KMS("No PLL selected\n");
> > > > > > + return NULL;
> > > > > > + }
> > > > > > +
> > > > > > + intel_reference_shared_dpll(pll, crtc_state);
> > > > > > + return pll;
> > > > > > +}
> > > > > > +
> > > > > > static bool mg_pll_get_hw_state(struct drm_i915_private
> > > > > > *dev_priv, struct intel_shared_dpll *pll,
> > > > > > struct intel_dpll_hw_state
> > > > > > *hw_state) @@ -3115,6 +3165,13 @@ static void
> > > > > > mg_pll_enable(struct drm_i915_private *dev_priv, i915_reg_t
> > > > > > enable_reg =
> > > > > > MG_PLL_ENABLE(icl_pll_id_to_tc_port(pll->info->id));
> > > > > > + if (IS_ELKHARTLAKE(dev_priv) &&
> > > > > > + (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5 ||
> > > > > > + I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC6)) {
> > > > > > + DRM_ERROR("Cant enable DPLL4 when DC5 or DC6
> > > > > > are enabled\n");
> > > > > > + return;
> > > > > > + }
> > > > >
> > > > > This looks
Re: [Intel-gfx] [PATCH] drm/i915/dp: Expose force_dsc_enable through debugfs
Pushed to dinq, thanks for the patch and the review Regards Manasi On Fri, Apr 05, 2019 at 03:48:21PM -0700, Manasi Navare wrote: > Currently we use force_dsc_enable to force DSC from IGT, but > we dont expose this value to userspace through debugfs. > This patch exposes this through the same dsc_fec_support > debugfs node per connector so that we can restore its value > back after the tests are completed. > > Suggested-by: Imre Deak > Cc: Imre Deak > Cc: Lyude Paul > Cc: Anusha Srivatsa > Signed-off-by: Manasi Navare > --- > drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index a14a7bccffc1..dbf806908111 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -4814,6 +4814,8 @@ static int i915_dsc_fec_support_show(struct seq_file > *m, void *data) > yesno(crtc_state->dsc_params.compression_enable)); > seq_printf(m, "DSC_Sink_Support: %s\n", > yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))); > + seq_printf(m, "Force_DSC_Enable: %s\n", > +yesno(intel_dp->force_dsc_en)); > if (!intel_dp_is_edp(intel_dp)) > seq_printf(m, "FEC_Sink_Support: %s\n", > > yesno(drm_dp_sink_supports_fec(intel_dp->fec_capable))); > -- > 2.19.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Hexdump enhancements
== Series Details ==
Series: Hexdump enhancements
URL : https://patchwork.freedesktop.org/series/59296/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4911981b19d1 lib/hexdump.c: Allow 64 bytes per line
49ccc448ceaa lib/hexdump.c: Optionally suppress lines of filler bytes
-:50: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#50: FILE: include/linux/printk.h:499:
+extern void print_hex_dump_ext(const char *level, const char *prefix_str,
-:83: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#83: FILE: include/linux/printk.h:529:
+ print_hex_dump_ext(level, prefix_str, prefix_type, rowsize, groupsize,
+ buf, len, ascii ? HEXDUMP_ASCII : 0);
-:86: CHECK:LINE_SPACING: Please don't use multiple blank lines
#86: FILE: include/linux/printk.h:532:
+
+
-:217: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#217: FILE: lib/hexdump.c:338:
+ print_hex_dump_ext(KERN_DEBUG, prefix_str, prefix_type, 16, 1,
+ buf, len, HEXDUMP_ASCII);
total: 0 errors, 0 warnings, 4 checks, 185 lines checked
560d296fb9d8 lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
-:282: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#282: FILE: lib/test_hexdump.c:175:
+ r = hex_dump_to_buffer(data_b, len, rs, gs, buf, buflen,
+ ascii ? HEXDUMP_ASCII : 0);
total: 0 errors, 0 warnings, 1 checks, 195 lines checked
3470b899c699 lib/hexdump.c: Allow multiple groups to be separated by lines '|'
-:125: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#125: FILE: lib/hexdump.c:232:
+ if (line_chars && ((j + 1) < len) &&
+ ((j + 1) % line_chars == 0)) {
total: 0 errors, 0 warnings, 1 checks, 124 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Bump ready tasks ahead of busywaits (rev3)
== Series Details == Series: drm/i915: Bump ready tasks ahead of busywaits (rev3) URL : https://patchwork.freedesktop.org/series/59232/ State : success == Summary == CI Bug Log - changes from CI_DRM_5900 -> Patchwork_12756 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59232/revisions/3/mbox/ Known issues Here are the changes found in Patchwork_12756 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: PASS -> DMESG-FAIL [fdo#110235 ] - fi-skl-gvtdvm: PASS -> DMESG-FAIL [fdo#110235 ] * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: - fi-byt-clapper: PASS -> FAIL [fdo#103191] +2 * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +20 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718] Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-byt-clapper: FAIL [fdo#103191] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (51 -> 41) -- Missing(10): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-hsw-4770 fi-bsw-kefka fi-skl-lmem fi-bdw-samus Build changes - * Linux: CI_DRM_5900 -> Patchwork_12756 CI_DRM_5900: 769a8fa8df6608ca386de13871aa789504b16665 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4941: 051ee61cd39a4378eded21e42b6c45e6fdc10d97 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12756: 990b1cdad6f11865c0d0ac4250296930d6427b0c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 990b1cdad6f1 drm/i915: Bump ready tasks ahead of busywaits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12756/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/7] drm/i915/sdvo: Actually print the reason why the SDVO command failed
From: Ville Syrjälä
It's much easier to figure out why the SDVO encoder refuses to cooperate
if we can see what status we got back.
v2: Zero initialize only the first character, not the whole buffer
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson #v1
---
drivers/gpu/drm/i915/intel_sdvo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 937f9abf8a0a..358ee0065a7e 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -518,6 +518,7 @@ static bool intel_sdvo_read_response(struct intel_sdvo
*intel_sdvo,
#define BUF_LEN 256
char buffer[BUF_LEN];
+ buffer[0] = '\0';
/*
* The documentation states that all commands will be
@@ -581,7 +582,8 @@ static bool intel_sdvo_read_response(struct intel_sdvo
*intel_sdvo,
return true;
log_fail:
- DRM_DEBUG_KMS("%s: R: ... failed\n", SDVO_NAME(intel_sdvo));
+ DRM_DEBUG_KMS("%s: R: ... failed %s\n",
+ SDVO_NAME(intel_sdvo), buffer);
return false;
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/7] drm/i915/sdvo: Check that we have space for the infoframe
From: Ville Syrjälä
Before we go writing the infoframe let's make sure we have
the space for it. Not that it really matters since the write
loop would just terminate early in that case.
v2: Check after the debug print and ++ (Chris)
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_sdvo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 7f64352a3413..14348dfb024a 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -976,6 +976,9 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
*intel_sdvo,
DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
if_index, length, hbuf_size);
+ if (hbuf_size < length)
+ return false;
+
for (i = 0; i < hbuf_size; i += 8) {
memset(tmp, 0, 8);
if (i < length)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
On (04/10/19 13:17), Alastair D'Silva wrote: > With the wider display format, it can become hard to identify how many > bytes into the line you are looking at. > > The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to > print vertical lines to separate every N groups of bytes. > > eg. > buf:: 454d414e 43415053|4e495f45 00584544 NAMESPAC|E_INDEX. > buf:0010: 0002| | What if the output had |-s in it? | -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Hexdump enhancements
From: Alastair D'Silva Apologies for the large CC list, it's a heads up for those responsible for subsystems where a prototype change in generic code causes a change in those subsystems. This series enhances hexdump. These improve the readability of the dumped data in certain situations (eg. wide terminals are available, many lines of empty bytes exist, etc). The default behaviour of hexdump is unchanged, however, the prototype for hex_dump_to_buffer() has changed, and print_hex_dump() has been renamed to print_hex_dump_ext(), with a wrapper replacing it for compatibility with existing code, which would have been too invasive to change. Alastair D'Silva (4): lib/hexdump.c: Allow 64 bytes per line lib/hexdump.c: Optionally suppress lines of filler bytes lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags lib/hexdump.c: Allow multiple groups to be separated by lines '|' drivers/gpu/drm/i915/intel_engine_cs.c| 2 +- drivers/isdn/hardware/mISDN/mISDNisar.c | 6 +- drivers/mailbox/mailbox-test.c| 2 +- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +- .../net/ethernet/synopsys/dwc-xlgmac-common.c | 2 +- drivers/net/wireless/ath/ath10k/debug.c | 3 +- .../net/wireless/intel/iwlegacy/3945-mac.c| 2 +- drivers/platform/chrome/wilco_ec/debugfs.c| 3 +- drivers/scsi/scsi_logging.c | 8 +- drivers/staging/fbtft/fbtft-core.c| 2 +- fs/seq_file.c | 3 +- include/linux/printk.h| 38 - lib/hexdump.c | 143 ++ lib/test_hexdump.c| 5 +- 14 files changed, 168 insertions(+), 53 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
If I go with pre-configured colorkey, do I need port your kernel patch to i915 driver at kernel 3.10.61 ? Thanks, Jim Caterpillar: Confidential Green -Original Message- From: Ville Syrjälä Sent: Tuesday, April 9, 2019 10:02 AM To: Jim Zhang Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver On Tue, Apr 09, 2019 at 02:24:03PM +, Jim Zhang wrote: > What about if I disable interrupt when changing the colorkey? This > will solve the atomic issue. I think we only change colorkey or > enable/disable colorkey once a while. If disabling interrupt work, I > will disable interrupt and change colorkey. That performance affection > could be acceptable Interrupts don't matter for this. > > Thanks > > Jim > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 9, 2019 9:19 AM > To: Jim Zhang > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > On Tue, Apr 09, 2019 at 02:14:49PM +, Jim Zhang wrote: > > Once I pre-configure the colorkey, am I able to enable and disable it? > > If colorkey can be enabled/disabled after that might meet my > > requirement > > Not atomically with other updates. > > > > > Thanks, > > > > Jim > > > > > > Caterpillar: Confidential Green > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, April 9, 2019 8:57 AM > > To: Jim Zhang > > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > > > On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > > > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > > > Villie: > > > > > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan > > > > to review and release? > > > > > > There is no real plan at this time. But if you have a use case for > > > it I can try to harass people until someone reviews it :) > > > > > > > If I go with custom ioctl, and my custom ioctl will only used in > > > > Baytrail product, could it be atomic for Baytrail only? > > > > > > No. We would need to define a new api for it. > > > > I should clarify that you can pre-configure the colorkey before turning on > > the sprite plane(s). So unless you really need to change the colorkey while > > the sprite plane(s) are already enabled you may not even need an atomic api > > for this. > > > > > > > > > > > > > Thanks, > > > > > > > > Jim > > > > > > > > > > > > Caterpillar: Confidential Green > > > > > > > > -Original Message- > > > > From: Ville Syrjälä > > > > Sent: Tuesday, April 2, 2019 7:32 AM > > > > To: Jim Zhang > > > > Cc: dri-de...@lists.freedesktop.org; > > > > intel-gfx@lists.freedesktop.org > > > > Subject: Re: colorkey support for intel i915 gpu driver > > > > > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > > > Hi Sir/Madam: > > > > > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > > > > > Linux kernel version 3.10.61: > > > > > Libdrm package: 2.4.97 > > > > > > > > > > When calling function > > > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > > > > > This property is: > > > > > property->name = "rotation", property->prop_id =4 It looks > > > > > like that the Baytrail gpu drm driver does not support colorkey. > > > > > > > > There are two problems currently: > > > > - Destination colorkey is not implemented on BYT/CHV. I have > > > > patches for it but they have not been reviewed by anyone: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.f > > > > re > > > > ed > > > > esktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9Ol > > > > Gg > > > > -s > > > > Ep8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfg > > > > UC > > > > y9 > > > > ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3p > > > > Xo > > > > 50 > > > > PX79myDO5gEYA= > > > > - Colorkey can only be set via a custom i915 specific ioctl > > > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > > > a generic property based API that never really went anywhere. It's > > > > a rather difficult problem making this generic as each hardware has > > > > its own peculiar way of specifying colorkeying. The main problem > > > > with the custom ioctl is that it's not atomic with other screen > > > > updates. > > > > > > > > So, what kind of use case do you have in mind? > > > > > > > > -- > > > > Ville Syrjälä > > > > Intel > > > > > > -- > > > Ville Syrjälä > > > Intel > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > >
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
Once I pre-configure the colorkey, am I able to enable and disable it? If colorkey can be enabled/disabled after that might meet my requirement Thanks, Jim Caterpillar: Confidential Green -Original Message- From: Ville Syrjälä Sent: Tuesday, April 9, 2019 8:57 AM To: Jim Zhang Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > Villie: > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan to > > review and release? > > There is no real plan at this time. But if you have a use case for it > I can try to harass people until someone reviews it :) > > > If I go with custom ioctl, and my custom ioctl will only used in Baytrail > > product, could it be atomic for Baytrail only? > > No. We would need to define a new api for it. I should clarify that you can pre-configure the colorkey before turning on the sprite plane(s). So unless you really need to change the colorkey while the sprite plane(s) are already enabled you may not even need an atomic api for this. > > > > > Thanks, > > > > Jim > > > > > > Caterpillar: Confidential Green > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, April 2, 2019 7:32 AM > > To: Jim Zhang > > Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > > Subject: Re: colorkey support for intel i915 gpu driver > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > Hi Sir/Madam: > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > Linux kernel version 3.10.61: > > > Libdrm package: 2.4.97 > > > > > > When calling function > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > This property is: > > > property->name = "rotation", property->prop_id =4 It looks like > > > that the Baytrail gpu drm driver does not support colorkey. > > > > There are two problems currently: > > - Destination colorkey is not implemented on BYT/CHV. I have > > patches for it but they have not been reviewed by anyone: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freed > > esktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg-s > > Ep8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUCy9 > > ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo50 > > PX79myDO5gEYA= > > - Colorkey can only be set via a custom i915 specific ioctl > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > a generic property based API that never really went anywhere. It's > > a rather difficult problem making this generic as each hardware has > > its own peculiar way of specifying colorkeying. The main problem > > with the custom ioctl is that it's not atomic with other screen > > updates. > > > > So, what kind of use case do you have in mind? > > > > -- > > Ville Syrjälä > > Intel > > -- > Ville Syrjälä > Intel > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop > .org_mailman_listinfo_intel-2Dgfx=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m > 9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=Oyn > sqGRzmnTMX2pxog1nBd_nnCa413-CM6loSIjLXXo=fjXVFmFDB_LEKe_W5PHzmzkzNPQ > cu3xTPSCqb5Dnpwk= -- 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 4/4] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
> -Original Message- > From: David Laight > Sent: Wednesday, 10 April 2019 6:45 PM > To: 'Alastair D'Silva' ; alast...@d-silva.org > Cc: Jani Nikula ; Joonas Lahtinen > ; Rodrigo Vivi ; > David Airlie ; Daniel Vetter ; Karsten Keil > ; Jassi Brar ; Tom Lendacky > ; David S. Miller ; > Jose Abreu ; Kalle Valo > ; Stanislaw Gruszka ; > Benson Leung ; Enric Balletbo i Serra > ; James E.J. Bottomley > ; Martin K. Petersen ; > Greg Kroah-Hartman ; Alexander Viro > ; Petr Mladek ; Sergey > Senozhatsky ; Steven Rostedt > ; Andrew Morton ; > intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux- > ker...@vger.kernel.org; net...@vger.kernel.org; > ath...@lists.infradead.org; linux-wirel...@vger.kernel.org; linux- > s...@vger.kernel.org; linux-fb...@vger.kernel.org; > de...@driverdev.osuosl.org; linux-fsde...@vger.kernel.org > Subject: RE: [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be > separated by lines '|' > > From: Alastair D'Silva > > Sent: 10 April 2019 04:17 > > With the wider display format, it can become hard to identify how many > > bytes into the line you are looking at. > > > > The patch adds new flags to hex_dump_to_buffer() and > print_hex_dump() > > to print vertical lines to separate every N groups of bytes. > > > > eg. > > buf:: 454d414e 43415053|4e495f45 00584544 > NAMESPAC|E_INDEX. > > buf:0010: 0002| | > > Ugg, that is just horrid. > It is enough to add an extra space if you really need the columns to be more > easily counted. > I did consider that, but it would be a more invasive change, as the buffer length required would differ based on the flags. > I'm not even sure that is needed if you are printing 32bit words. > OTOH 32bit words makes 64bit values really stupid on LE systems. > Bytes with extra spaces every 4 bytes is the format I prefer even for long > lines. > > Oh, and if you are using hexdump() a lot you want a version that never uses > snprintf(). > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > MK1 1PT, UK Registration No: 1397386 (Wales) > > > --- > This email has been checked for viruses by AVG. > https://www.avg.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
From: Alastair D'Silva
With the wider display format, it can become hard to identify how many
bytes into the line you are looking at.
The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
print vertical lines to separate every N groups of bytes.
eg.
buf:: 454d414e 43415053|4e495f45 00584544 NAMESPAC|E_INDEX.
buf:0010: 0002| |
Signed-off-by: Alastair D'Silva
---
include/linux/printk.h | 3 +++
lib/hexdump.c | 50 +-
2 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 82975853c400..d9e407e59059 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -485,6 +485,9 @@ enum {
#define HEXDUMP_SUPPRESS_0XFF (1 << 2)
#define HEXDUMP_SUPPRESS_FIRST (1 << 3)
#define HEXDUMP_SUPPRESS_LAST (1 << 4)
+#define HEXDUMP_2_GRP_LINES(1 << 5)
+#define HEXDUMP_4_GRP_LINES(1 << 6)
+#define HEXDUMP_8_GRP_LINES(1 << 7)
#define HEXDUMP_QUIET (HEXDUMP_SUPPRESS_0X00 | \
HEXDUMP_SUPPRESS_0XFF | \
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 79db784577e7..d42f34b93b2c 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -76,6 +76,20 @@ char *bin2hex(char *dst, const void *src, size_t count)
}
EXPORT_SYMBOL(bin2hex);
+static const char *group_separator(int group, u64 flags)
+{
+ if ((flags & HEXDUMP_8_GRP_LINES) && ((group - 1) % 8))
+ return "|";
+
+ if ((flags & HEXDUMP_4_GRP_LINES) && ((group - 1) % 4))
+ return "|";
+
+ if ((flags & HEXDUMP_2_GRP_LINES) && ((group - 1) % 2))
+ return "|";
+
+ return " ";
+}
+
/**
* hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
* @buf: data blob to dump
@@ -86,6 +100,9 @@ EXPORT_SYMBOL(bin2hex);
* @linebuflen: total size of @linebuf, including space for terminating NUL
* @flags: A bitwise OR of the following flags:
* HEXDUMP_ASCII: include ASCII after the hex output
+ * HEXDUMP_2_GRP_LINES:insert a '|' after every 2 groups
+ * HEXDUMP_4_GRP_LINES:insert a '|' after every 4 groups
+ * HEXDUMP_8_GRP_LINES:insert a '|' after every 8 groups
*
* hex_dump_to_buffer() works on one "line" of output at a time, i.e.,
* 16, 32 or 64 bytes of input data converted to hex + ASCII output.
@@ -116,6 +133,7 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
int j, lx = 0;
int ascii_column;
int ret;
+ int line_chars = 0;
if (rowsize != 16 && rowsize != 32 && rowsize != 64)
rowsize = 16;
@@ -141,7 +159,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
- "%s%16.16llx", j ? " " : "",
+ "%s%16.16llx",
+ j ? group_separator(j, flags) : "",
get_unaligned(ptr8 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -152,7 +171,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
- "%s%8.8x", j ? " " : "",
+ "%s%8.8x",
+ j ? group_separator(j, flags) : "",
get_unaligned(ptr4 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -163,7 +183,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
for (j = 0; j < ngroups; j++) {
ret = snprintf(linebuf + lx, linebuflen - lx,
- "%s%4.4x", j ? " " : "",
+ "%s%4.4x",
+ j ? group_separator(j, flags) : "",
get_unaligned(ptr2 + j));
if (ret >= linebuflen - lx)
goto overflow1;
@@ -193,11 +214,26 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
goto overflow2;
linebuf[lx++] = ' ';
}
+
+ if (flags & HEXDUMP_2_GRP_LINES)
+ line_chars = groupsize * 2;
+ if (flags & HEXDUMP_4_GRP_LINES)
+ line_chars = groupsize * 4;
+ if (flags & HEXDUMP_8_GRP_LINES)
+ line_chars = groupsize * 8;
+
for (j = 0; j < len; j++) {
if (linebuflen < lx + 2)
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
Villie: What is Intel's plan for the colorkey patch? Does Intel have any plan to review and release? If I go with custom ioctl, and my custom ioctl will only used in Baytrail product, could it be atomic for Baytrail only? Thanks, Jim Caterpillar: Confidential Green -Original Message- From: Ville Syrjälä Sent: Tuesday, April 2, 2019 7:32 AM To: Jim Zhang Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org Subject: Re: colorkey support for intel i915 gpu driver On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > Hi Sir/Madam: > > I am using the open source Baytrail gpu drm driver. > > Linux kernel version 3.10.61: > Libdrm package: 2.4.97 > > When calling function > properties = drmModeObjectGetProperties(drmfd, plane_id, > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > This property is: > property->name = "rotation", property->prop_id =4 It looks like that > the Baytrail gpu drm driver does not support colorkey. There are two problems currently: - Destination colorkey is not implemented on BYT/CHV. I have patches for it but they have not been reviewed by anyone: https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUCy9ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo50PX79myDO5gEYA= - Colorkey can only be set via a custom i915 specific ioctl (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at a generic property based API that never really went anywhere. It's a rather difficult problem making this generic as each hardware has its own peculiar way of specifying colorkeying. The main problem with the custom ioctl is that it's not atomic with other screen updates. So, what kind of use case do you have in mind? -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
What about if I disable interrupt when changing the colorkey? This will solve the atomic issue. I think we only change colorkey or enable/disable colorkey once a while. If disabling interrupt work, I will disable interrupt and change colorkey. That performance affection could be acceptable Thanks Jim Caterpillar: Confidential Green -Original Message- From: Ville Syrjälä Sent: Tuesday, April 9, 2019 9:19 AM To: Jim Zhang Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver On Tue, Apr 09, 2019 at 02:14:49PM +, Jim Zhang wrote: > Once I pre-configure the colorkey, am I able to enable and disable it? > If colorkey can be enabled/disabled after that might meet my > requirement Not atomically with other updates. > > Thanks, > > Jim > > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 9, 2019 8:57 AM > To: Jim Zhang > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > > Villie: > > > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan > > > to review and release? > > > > There is no real plan at this time. But if you have a use case for > > it I can try to harass people until someone reviews it :) > > > > > If I go with custom ioctl, and my custom ioctl will only used in Baytrail > > > product, could it be atomic for Baytrail only? > > > > No. We would need to define a new api for it. > > I should clarify that you can pre-configure the colorkey before turning on > the sprite plane(s). So unless you really need to change the colorkey while > the sprite plane(s) are already enabled you may not even need an atomic api > for this. > > > > > > > > > Thanks, > > > > > > Jim > > > > > > > > > Caterpillar: Confidential Green > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, April 2, 2019 7:32 AM > > > To: Jim Zhang > > > Cc: dri-de...@lists.freedesktop.org; > > > intel-gfx@lists.freedesktop.org > > > Subject: Re: colorkey support for intel i915 gpu driver > > > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > > Hi Sir/Madam: > > > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > > > Linux kernel version 3.10.61: > > > > Libdrm package: 2.4.97 > > > > > > > > When calling function > > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > > > This property is: > > > > property->name = "rotation", property->prop_id =4 It looks > > > > like that the Baytrail gpu drm driver does not support colorkey. > > > > > > There are two problems currently: > > > - Destination colorkey is not implemented on BYT/CHV. I have > > > patches for it but they have not been reviewed by anyone: > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.fre > > > ed > > > esktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg > > > -s > > > Ep8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUC > > > y9 > > > ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo > > > 50 > > > PX79myDO5gEYA= > > > - Colorkey can only be set via a custom i915 specific ioctl > > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > > a generic property based API that never really went anywhere. It's > > > a rather difficult problem making this generic as each hardware has > > > its own peculiar way of specifying colorkeying. The main problem > > > with the custom ioctl is that it's not atomic with other screen > > > updates. > > > > > > So, what kind of use case do you have in mind? > > > > > > -- > > > Ville Syrjälä > > > Intel > > > > -- > > Ville Syrjälä > > Intel > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedeskt > > op > > .org_mailman_listinfo_intel-2Dgfx=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r > > 4m > > 9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=O > > yn > > sqGRzmnTMX2pxog1nBd_nnCa413-CM6loSIjLXXo=fjXVFmFDB_LEKe_W5PHzmzkzN > > PQ > > cu3xTPSCqb5Dnpwk= > > -- > Ville Syrjälä > Intel -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
Ville: Yes, if this patch is needed by kernel 3.10.61, please get somebody to review it. What do I need do to speed up the review process? Please generate a patch against kernel 3.10.61 if possible. Thanks, Jim Caterpillar: Confidential Green -Original Message- From: Jim Zhang Sent: Tuesday, April 9, 2019 10:18 AM To: 'Ville Syrjälä' Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: RE: [Intel-gfx] colorkey support for intel i915 gpu driver If I go with pre-configured colorkey, do I need port your kernel patch to i915 driver at kernel 3.10.61 ? Thanks, Jim Caterpillar: Confidential Green -Original Message- From: Ville Syrjälä Sent: Tuesday, April 9, 2019 10:02 AM To: Jim Zhang Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver On Tue, Apr 09, 2019 at 02:24:03PM +, Jim Zhang wrote: > What about if I disable interrupt when changing the colorkey? This > will solve the atomic issue. I think we only change colorkey or > enable/disable colorkey once a while. If disabling interrupt work, I > will disable interrupt and change colorkey. That performance affection > could be acceptable Interrupts don't matter for this. > > Thanks > > Jim > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 9, 2019 9:19 AM > To: Jim Zhang > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > On Tue, Apr 09, 2019 at 02:14:49PM +, Jim Zhang wrote: > > Once I pre-configure the colorkey, am I able to enable and disable it? > > If colorkey can be enabled/disabled after that might meet my > > requirement > > Not atomically with other updates. > > > > > Thanks, > > > > Jim > > > > > > Caterpillar: Confidential Green > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, April 9, 2019 8:57 AM > > To: Jim Zhang > > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > > > On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > > > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > > > Villie: > > > > > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan > > > > to review and release? > > > > > > There is no real plan at this time. But if you have a use case for > > > it I can try to harass people until someone reviews it :) > > > > > > > If I go with custom ioctl, and my custom ioctl will only used in > > > > Baytrail product, could it be atomic for Baytrail only? > > > > > > No. We would need to define a new api for it. > > > > I should clarify that you can pre-configure the colorkey before turning on > > the sprite plane(s). So unless you really need to change the colorkey while > > the sprite plane(s) are already enabled you may not even need an atomic api > > for this. > > > > > > > > > > > > > Thanks, > > > > > > > > Jim > > > > > > > > > > > > Caterpillar: Confidential Green > > > > > > > > -Original Message- > > > > From: Ville Syrjälä > > > > Sent: Tuesday, April 2, 2019 7:32 AM > > > > To: Jim Zhang > > > > Cc: dri-de...@lists.freedesktop.org; > > > > intel-gfx@lists.freedesktop.org > > > > Subject: Re: colorkey support for intel i915 gpu driver > > > > > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > > > Hi Sir/Madam: > > > > > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > > > > > Linux kernel version 3.10.61: > > > > > Libdrm package: 2.4.97 > > > > > > > > > > When calling function > > > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > > > > > This property is: > > > > > property->name = "rotation", property->prop_id =4 It looks > > > > > like that the Baytrail gpu drm driver does not support colorkey. > > > > > > > > There are two problems currently: > > > > - Destination colorkey is not implemented on BYT/CHV. I have > > > > patches for it but they have not been reviewed by anyone: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.f > > > > re > > > > ed > > > > esktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9Ol > > > > Gg > > > > -s > > > > Ep8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfg > > > > UC > > > > y9 > > > > ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3p > > > > Xo > > > > 50 > > > > PX79myDO5gEYA= > > > > - Colorkey can only be set via a custom i915 specific ioctl > > > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > > > a generic property based API that never really went anywhere. It's > > > > a rather difficult problem making this generic as
[Intel-gfx] [PATCH 2/4] lib/hexdump.c: Optionally suppress lines of filler bytes
From: Alastair D'Silva
Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).
This patch introduces flags which allow lines of padding bytes to be
suppressed, making the output easier to interpret: HEXDUMP_SUPPRESS_0X00,
HEXDUMP_SUPPRESS_0XFF
The first and last lines are not suppressed by default, so the function
always outputs something. This behaviour can be further controlled with
the HEXDUMP_SUPPRESS_FIRST & HEXDUMP_SUPPRESS_LAST flags.
An inline wrapper function is provided for backwards compatibility with
existing code, which maintains the original behaviour.
Signed-off-by: Alastair D'Silva
---
include/linux/printk.h | 38 ++
lib/hexdump.c | 72 ++
2 files changed, 89 insertions(+), 21 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index d7c77ed1a4cb..c014e5573665 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -479,13 +479,26 @@ enum {
DUMP_PREFIX_ADDRESS,
DUMP_PREFIX_OFFSET
};
+
+#define HEXDUMP_ASCII (1 << 0)
+#define HEXDUMP_SUPPRESS_0X00 (1 << 1)
+#define HEXDUMP_SUPPRESS_0XFF (1 << 2)
+#define HEXDUMP_SUPPRESS_FIRST (1 << 3)
+#define HEXDUMP_SUPPRESS_LAST (1 << 4)
+
+#define HEXDUMP_QUIET (HEXDUMP_SUPPRESS_0X00 | \
+ HEXDUMP_SUPPRESS_0XFF | \
+ HEXDUMP_SUPPRESS_FIRST | \
+ HEXDUMP_SUPPRESS_LAST)
+
extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
int groupsize, char *linebuf, size_t linebuflen,
bool ascii);
+
#ifdef CONFIG_PRINTK
-extern void print_hex_dump(const char *level, const char *prefix_str,
- int prefix_type, int rowsize, int groupsize,
- const void *buf, size_t len, bool ascii);
+extern void print_hex_dump_ext(const char *level, const char *prefix_str,
+ int prefix_type, int rowsize, int groupsize,
+ const void *buf, size_t len, u64 flags);
#if defined(CONFIG_DYNAMIC_DEBUG)
#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
@@ -494,18 +507,29 @@ extern void print_hex_dump_bytes(const char *prefix_str,
int prefix_type,
const void *buf, size_t len);
#endif /* defined(CONFIG_DYNAMIC_DEBUG) */
#else
-static inline void print_hex_dump(const char *level, const char *prefix_str,
- int prefix_type, int rowsize, int groupsize,
- const void *buf, size_t len, bool ascii)
+static inline void print_hex_dump_ext(const char *level, const char
*prefix_str,
+ int prefix_type, int rowsize,
+ int groupsize, const void *buf,
+ size_t len, u64 flags)
{
}
static inline void print_hex_dump_bytes(const char *prefix_str, int
prefix_type,
const void *buf, size_t len)
{
}
-
#endif
+static __always_inline void print_hex_dump(const char *level,
+ const char *prefix_str,
+ int prefix_type, int rowsize,
+ int groupsize, const void *buf,
+ size_t len, bool ascii)
+{
+ print_hex_dump_ext(level, prefix_str, prefix_type, rowsize, groupsize,
+ buf, len, ascii ? HEXDUMP_ASCII : 0);
+}
+
+
#if defined(CONFIG_DYNAMIC_DEBUG)
#define print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
groupsize, buf, len, ascii)\
diff --git a/lib/hexdump.c b/lib/hexdump.c
index b8a164814744..2f3bafb55a44 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -209,8 +209,21 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
EXPORT_SYMBOL(hex_dump_to_buffer);
#ifdef CONFIG_PRINTK
+
+static bool buf_is_all(const u8 *buf, size_t len, u8 val)
+{
+ size_t i;
+
+ for (i = 0; i < len; i++) {
+ if (buf[i] != val)
+ return false;
+ }
+
+ return true;
+}
+
/**
- * print_hex_dump - print a text hex dump to syslog for a binary blob of data
+ * print_hex_dump_ext: dump a binary blob of data to syslog in hexadecimal
* @level: kernel log level (e.g. KERN_DEBUG)
* @prefix_str: string to prefix each line with;
* caller supplies trailing spaces for alignment if desired
@@ -221,42 +234,73 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
* @buf: data blob to dump
* @len: number of bytes in the @buf
* @ascii: include ASCII after the hex output
+ * @flags: A bitwise OR of the following flags:
+
[Intel-gfx] [PATCH 1/4] lib/hexdump.c: Allow 64 bytes per line
From: Alastair D'Silva
With modern high resolution screens, we can display more data, which makes
life a bit easier when debugging.
Allow 64 bytes to be dumped per line.
Signed-off-by: Alastair D'Silva
---
lib/hexdump.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 81b70ed37209..b8a164814744 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -80,14 +80,14 @@ EXPORT_SYMBOL(bin2hex);
* hex_dump_to_buffer - convert a blob of data to "hex ASCII" in memory
* @buf: data blob to dump
* @len: number of bytes in the @buf
- * @rowsize: number of bytes to print per line; must be 16 or 32
+ * @rowsize: number of bytes to print per line; must be 16, 32 or 64
* @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
* @linebuf: where to put the converted data
* @linebuflen: total size of @linebuf, including space for terminating NUL
* @ascii: include ASCII after the hex output
*
* hex_dump_to_buffer() works on one "line" of output at a time, i.e.,
- * 16 or 32 bytes of input data converted to hex + ASCII output.
+ * 16, 32 or 64 bytes of input data converted to hex + ASCII output.
*
* Given a buffer of u8 data, hex_dump_to_buffer() converts the input data
* to a hex + ASCII dump at the supplied memory location.
@@ -116,7 +116,7 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
int ascii_column;
int ret;
- if (rowsize != 16 && rowsize != 32)
+ if (rowsize != 16 && rowsize != 32 && rowsize != 64)
rowsize = 16;
if (len > rowsize) /* limit to one line at a time */
@@ -216,7 +216,7 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
* caller supplies trailing spaces for alignment if desired
* @prefix_type: controls whether prefix of an offset, address, or none
* is printed (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
- * @rowsize: number of bytes to print per line; must be 16 or 32
+ * @rowsize: number of bytes to print per line; must be 16, 32 or 64
* @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
* @buf: data blob to dump
* @len: number of bytes in the @buf
@@ -227,7 +227,7 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
* leading prefix.
*
* print_hex_dump() works on one "line" of output at a time, i.e.,
- * 16 or 32 bytes of input data converted to hex + ASCII output.
+ * 16, 32 or 64 bytes of input data converted to hex + ASCII output.
* print_hex_dump() iterates over the entire input @buf, breaking it into
* "line size" chunks to format and print.
*
@@ -246,9 +246,9 @@ void print_hex_dump(const char *level, const char
*prefix_str, int prefix_type,
{
const u8 *ptr = buf;
int i, linelen, remaining = len;
- unsigned char linebuf[32 * 3 + 2 + 32 + 1];
+ unsigned char linebuf[64 * 3 + 2 + 64 + 1];
- if (rowsize != 16 && rowsize != 32)
+ if (rowsize != 16 && rowsize != 32 && rowsize != 64)
rowsize = 16;
for (i = 0; i < len; i += rowsize) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
Nice, do you have any sample code for it? Thanks, Jim Caterpillar: Confidential Green -Original Message- From: Ville Syrjälä Sent: Tuesday, April 9, 2019 8:57 AM To: Jim Zhang Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > Villie: > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan to > > review and release? > > There is no real plan at this time. But if you have a use case for it > I can try to harass people until someone reviews it :) > > > If I go with custom ioctl, and my custom ioctl will only used in Baytrail > > product, could it be atomic for Baytrail only? > > No. We would need to define a new api for it. I should clarify that you can pre-configure the colorkey before turning on the sprite plane(s). So unless you really need to change the colorkey while the sprite plane(s) are already enabled you may not even need an atomic api for this. > > > > > Thanks, > > > > Jim > > > > > > Caterpillar: Confidential Green > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, April 2, 2019 7:32 AM > > To: Jim Zhang > > Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > > Subject: Re: colorkey support for intel i915 gpu driver > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > Hi Sir/Madam: > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > Linux kernel version 3.10.61: > > > Libdrm package: 2.4.97 > > > > > > When calling function > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > This property is: > > > property->name = "rotation", property->prop_id =4 It looks like > > > that the Baytrail gpu drm driver does not support colorkey. > > > > There are two problems currently: > > - Destination colorkey is not implemented on BYT/CHV. I have > > patches for it but they have not been reviewed by anyone: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freed > > esktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg-s > > Ep8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUCy9 > > ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo50 > > PX79myDO5gEYA= > > - Colorkey can only be set via a custom i915 specific ioctl > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > a generic property based API that never really went anywhere. It's > > a rather difficult problem making this generic as each hardware has > > its own peculiar way of specifying colorkeying. The main problem > > with the custom ioctl is that it's not atomic with other screen > > updates. > > > > So, what kind of use case do you have in mind? > > > > -- > > Ville Syrjälä > > Intel > > -- > Ville Syrjälä > Intel > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop > .org_mailman_listinfo_intel-2Dgfx=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m > 9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=Oyn > sqGRzmnTMX2pxog1nBd_nnCa413-CM6loSIjLXXo=fjXVFmFDB_LEKe_W5PHzmzkzNPQ > cu3xTPSCqb5Dnpwk= -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
From: Alastair D'Silva
In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 6 --
drivers/mailbox/mailbox-test.c| 2 +-
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 3 ++-
drivers/net/wireless/intel/iwlegacy/3945-mac.c| 2 +-
drivers/platform/chrome/wilco_ec/debugfs.c| 3 ++-
drivers/scsi/scsi_logging.c | 8 +++-
drivers/staging/fbtft/fbtft-core.c| 2 +-
fs/seq_file.c | 3 ++-
include/linux/printk.h| 2 +-
lib/hexdump.c | 15 ---
lib/test_hexdump.c| 5 +++--
14 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 49fa43ff02ba..fb133e729f9a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1318,7 +1318,7 @@ static void hexdump(struct drm_printer *m, const void
*buf, size_t len)
WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
rowsize, sizeof(u32),
line, sizeof(line),
- false) >= sizeof(line));
+ 0) >= sizeof(line));
drm_printf(m, "[%04zx] %s\n", pos, line);
prev = buf + pos;
diff --git a/drivers/isdn/hardware/mISDN/mISDNisar.c
b/drivers/isdn/hardware/mISDN/mISDNisar.c
index 386731ec2489..f13f34db6c17 100644
--- a/drivers/isdn/hardware/mISDN/mISDNisar.c
+++ b/drivers/isdn/hardware/mISDN/mISDNisar.c
@@ -84,7 +84,8 @@ send_mbox(struct isar_hw *isar, u8 his, u8 creg, u8 len, u8
*msg)
while (l < (int)len) {
hex_dump_to_buffer(msg + l, len - l, 32, 1,
- isar->log, 256, 1);
+ isar->log, 256,
+ HEXDUMP_ASCII);
pr_debug("%s: %s %02x: %s\n", isar->name,
__func__, l, isar->log);
l += 32;
@@ -113,7 +114,8 @@ rcv_mbox(struct isar_hw *isar, u8 *msg)
while (l < (int)isar->clsb) {
hex_dump_to_buffer(msg + l, isar->clsb - l, 32,
- 1, isar->log, 256, 1);
+ 1, isar->log, 256,
+ HEXDUMP_ASCII);
pr_debug("%s: %s %02x: %s\n", isar->name,
__func__, l, isar->log);
l += 32;
diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c
index 4e4ac4be6423..2f9a094d0259 100644
--- a/drivers/mailbox/mailbox-test.c
+++ b/drivers/mailbox/mailbox-test.c
@@ -213,7 +213,7 @@ static ssize_t mbox_test_message_read(struct file *filp,
char __user *userbuf,
hex_dump_to_buffer(ptr,
MBOX_BYTES_PER_LINE,
MBOX_BYTES_PER_LINE, 1, touser + l,
- MBOX_HEXDUMP_LINE_LEN, true);
+ MBOX_HEXDUMP_LINE_LEN, HEXDUMP_ASCII);
ptr += MBOX_BYTES_PER_LINE;
l += MBOX_HEXDUMP_LINE_LEN;
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 0cc911f928b1..e954a31cee0c 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -2992,7 +2992,7 @@ void xgbe_print_pkt(struct net_device *netdev, struct
sk_buff *skb, bool tx_rx)
unsigned int len = min(skb->len - i, 32U);
hex_dump_to_buffer(>data[i], len, 32, 1,
- buffer, sizeof(buffer), false);
+ buffer, sizeof(buffer), 0);
netdev_dbg(netdev, " %#06x: %s\n", i, buffer);
}
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index eb1c6b03c329..b80adfa1f890 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -349,7 +349,7 @@ void xlgmac_print_pkt(struct net_device *netdev,
unsigned int len = min(skb->len - i, 32U);
Re: [Intel-gfx] [PATCH 2/4] lib/hexdump.c: Optionally suppress lines of filler bytes
On Wed, 2019-04-10 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Some buffers may only be partially filled with useful data, while the
> rest
> is padded (typically with 0x00 or 0xff).
>
This patch introduces flags which allow lines of padding bytes to be
> suppressed, making the output easier to interpret:
> HEXDUMP_SUPPRESS_0X00,
> HEXDUMP_SUPPRESS_0XFF
>
> The first and last lines are not suppressed by default, so the
> function
> always outputs something. This behaviour can be further controlled
> with
> the HEXDUMP_SUPPRESS_FIRST & HEXDUMP_SUPPRESS_LAST flags.
>
> An inline wrapper function is provided for backwards compatibility
> with
> existing code, which maintains the original behaviour.
>
> Signed-off-by: Alastair D'Silva
> ---
>
> diff --git a/lib/hexdump.c b/lib/hexdump.c
> index b8a164814744..2f3bafb55a44 100644
> --- a/lib/hexdump.c
> +++ b/lib/hexdump.c
> @@ -209,8 +209,21 @@ int hex_dump_to_buffer(const void *buf, size_t
> len, int rowsize, int groupsize,
> EXPORT_SYMBOL(hex_dump_to_buffer);
>
> #ifdef CONFIG_PRINTK
> +
> +static bool buf_is_all(const u8 *buf, size_t len, u8 val)
> +{
> + size_t i;
> +
> + for (i = 0; i < len; i++) {
> + if (buf[i] != val)
> + return false;
> + }
> +
> + return true;
> +}
> +
> /**
> - * print_hex_dump - print a text hex dump to syslog for a binary
> blob of data
> + * print_hex_dump_ext: dump a binary blob of data to syslog in
> hexadecimal
> * @level: kernel log level (e.g. KERN_DEBUG)
> * @prefix_str: string to prefix each line with;
> * caller supplies trailing spaces for alignment if desired
> @@ -221,42 +234,73 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
> * @buf: data blob to dump
> * @len: number of bytes in the @buf
> * @ascii: include ASCII after the hex output
This line should have been removed. I'll address it in V2.
> + * @flags: A bitwise OR of the following flags:
> + * HEXDUMP_ASCII: include ASCII after the hex output
> + * HEXDUMP_SUPPRESS_0X00: suppress lines that are all 0x00
> + * (other than first or last)
> + * HEXDUMP_SUPPRESS_0XFF: suppress lines that are all 0xff
> + * (other than first or last)
> + * HEXDUMP_SUPPRESS_FIRST: allows the first line to be
> suppressed
> + * HEXDUMP_SUPPRESS_LAST: allows the last line to be suppressed
> + * If the first and last line may be
> suppressed,
> + * an empty buffer will not produce any
> output
> *
> * Given a buffer of u8 data, print_hex_dump() prints a hex + ASCII
> dump
> * to the kernel log at the specified kernel log level, with an
> optional
> * leading prefix.
> *
> - * print_hex_dump() works on one "line" of output at a time, i.e.,
> + * print_hex_dump_ext() works on one "line" of output at a time,
> i.e.,
> * 16, 32 or 64 bytes of input data converted to hex + ASCII output.
> - * print_hex_dump() iterates over the entire input @buf, breaking it
> into
> + * print_hex_dump_ext() iterates over the entire input @buf,
> breaking it into
> * "line size" chunks to format and print.
> *
> * E.g.:
> - * print_hex_dump(KERN_DEBUG, "raw data: ", DUMP_PREFIX_ADDRESS,
> - * 16, 1, frame->data, frame->len, true);
> + * print_hex_dump_ext(KERN_DEBUG, "raw data: ",
> DUMP_PREFIX_ADDRESS,
> + * 16, 1, frame->data, frame->len, HEXDUMP_ASCII);
> *
> * Example output using %DUMP_PREFIX_OFFSET and 1-byte mode:
> * 0009ab42: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e
> 4f @ABCDEFGHIJKLMNO
> * Example output using %DUMP_PREFIX_ADDRESS and 4-byte mode:
> * 88089af0: 73727170 77767574 7b7a7978
> 7f7e7d7c pqrstuvwxyz{|}~.
> */
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/29] drm/i915: Switch back to an array of logical per-engine HW contexts
Quoting Tvrtko Ursulin (2019-04-10 16:32:18)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 3f794bc71958..0df3c5238c04 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -716,7 +716,7 @@ static int pin_context(struct i915_gem_context *ctx,
> > struct intel_context *ce;
> > int err;
> >
> > - ce = intel_context_instance(ctx, engine);
> > + ce = i915_gem_context_get_engine(ctx, engine->id);
>
> Staying with intel_context_instance wouldn't help to reduce the churn?
But it takes the GEM context :|
intel_context_lookup() ? But it won't be part of gt/intel_context.h
And I'd like to have 'get' in there for consistency (although other
object lookup functions return a new reference, so that may not be a
solid argument).
It has annoyed me that this does require the GEM context, but that's the
nature of the beast.
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 50266e87c225..21b4a04c424b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4312,8 +4312,9 @@ int i915_gem_init_hw(struct drm_i915_private
> > *dev_priv)
> >
> > static int __intel_engines_record_defaults(struct drm_i915_private *i915)
> > {
> > - struct i915_gem_context *ctx;
> > struct intel_engine_cs *engine;
> > + struct i915_gem_context *ctx;
> > + struct i915_gem_engines *e;
> > enum intel_engine_id id;
> > int err = 0;
> >
> > @@ -4330,18 +4331,26 @@ static int __intel_engines_record_defaults(struct
> > drm_i915_private *i915)
> > if (IS_ERR(ctx))
> > return PTR_ERR(ctx);
> >
> > + e = i915_gem_context_engine_list_lock(ctx);
> > +
> > for_each_engine(engine, i915, id) {
>
> Do we need i915 version of for_each_context_engine? If all call sites
> will doing this "lock ctx" -> "walk physical engines" -> "lookup in
> context" then it seems a bit disconnected.
It's rare, a couple of odd cases imo.
> > + struct intel_context *ce = e->engines[id];
>
> How will index by engine->id work for engine map?
It doesn't, that's the point of these being the odd cases. :)
> > struct i915_request *rq;
> >
> > - rq = i915_request_alloc(engine, ctx);
> > + err = intel_context_pin(ce);
> > + if (err)
> > + goto err_active;
> > +
> > + rq = i915_request_create(ce);
> > + intel_context_unpin(ce);
>
> Kind of verbose, no? Do you want to add some
> middle-ground-between-request-alloc-and-create helper?
There's 2 callers of i915_request_create() in this style.
(Execbuf has a style all of its own.)
At the moment I don't have a good name for the happy middle ground, so
I'm willing to pay the price for forcing control over the pin to the
user.
...
Does it really make any difference for the perma-pinned kernel contexts?
Actually no...
Hmm. The fundamental objective was being able to pass ce and avoid
struct_mutex -- but we already avoid struct_mutex for pinning today as
the context is already pinned.
The downside is that it adds redundant steps to execbuf, and
__i915_request_create() is already taken... And I hope you would say no
if I suggest i915_request_create :)
> > +static struct i915_gem_engines *default_engines(struct i915_gem_context
> > *ctx)
> > +{
> > + struct intel_engine_cs *engine;
> > + struct i915_gem_engines *e;
> > + enum intel_engine_id id;
> > +
> > + e = kzalloc(struct_size(e, engines, I915_NUM_ENGINES), GFP_KERNEL);
> > + if (!e)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + e->i915 = ctx->i915;
> > + for_each_engine(engine, ctx->i915, id) {
> > + struct intel_context *ce;
> >
> > + ce = intel_context_create(ctx, engine);
> > + if (IS_ERR(ce)) {
> > + free_engines_n(e, id);
>
> I dislike piggy-back of n into e. How about:
>
> __free_engines(e, n)
> {
> ...
> }
>
> free_engines(e)
> {
> __fre_engines(e, e->num_engines):
> }
>
> ?
Ok.
> Or even you could e->num_engines++ in the above loop and just have one
> free_engines.
I thought it was cleaner to avoid having multiple counters for the same
loop. free_engines_n() ended up with 5 users.
> > + return ERR_CAST(ce);
> > + }
> > +
> > + e->engines[id] = ce;
>
> Each context would have a sparse array of engines, on most platforms.
> Would it be workable to instead create a compact array per context, and
> just have a per device translation table of idx to engine->id? Or
> vice-versa, I can't figure out straight from the bat which one would you
> need.
As sparse as we do today. I working under the assumption that going
forwards, the default
Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support
On Wed, Apr 10, 2019 at 01:20:44PM +, Shankar, Uma wrote: > > > >-Original Message- > >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf > >Of Ville > >Syrjälä > >Sent: Monday, April 8, 2019 9:38 PM > >To: Shankar, Uma > >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri- > >de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville > >; Lankhorst, Maarten > >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support > > > >On Mon, Apr 08, 2019 at 03:59:51PM +, Shankar, Uma wrote: > >> > >> > >> >-Original Message- > >> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On > >> >Behalf Of Ville Syrjälä > >> >Sent: Monday, April 8, 2019 9:15 PM > >> >To: Shankar, Uma > >> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri- > >> >de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville > >> >; Lankhorst, Maarten > >> > > >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support > >> > > >> >On Mon, Apr 08, 2019 at 03:40:39PM +, Shankar, Uma wrote: > >> >> > >> >> > >> >> >-Original Message- > >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> >> >Sent: Monday, April 8, 2019 8:27 PM > >> >> >To: Shankar, Uma > >> >> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri- > >> >> >de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville > >> >> >; Lankhorst, Maarten > >> >> > > >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support > >> >> > > >> >> >On Mon, Apr 08, 2019 at 02:40:51PM +, Shankar, Uma wrote: > >> >> >> > >> >> >> > >> >> >> >-Original Message- > >> >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >> >> >> >Sent: Monday, April 8, 2019 6:01 PM > >> >> >> >To: Shankar, Uma > >> >> >> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; > >> >> >> >dri- de...@lists.freedesktop.org; seanp...@chromium.org; > >> >> >> >Syrjala, Ville ; Lankhorst, Maarten > >> >> >> > > >> >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma > >> >> >> >Support > >> >> >> > > >> >> >> >On Mon, Apr 08, 2019 at 12:26:23PM +, Shankar, Uma wrote: > >> >> >> >> > >> >> >> >> > >> >> >> >> >-Original Message- > >> >> >> >> >From: dri-devel > >> >> >> >> >[mailto:dri-devel-boun...@lists.freedesktop.org] > >> >> >> >> >On Behalf Of Ville Syrjälä > >> >> >> >> >Sent: Friday, April 5, 2019 9:42 PM > >> >> >> >> >To: Shankar, Uma > >> >> >> >> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; > >> >> >> >> >dri- de...@lists.freedesktop.org; seanp...@chromium.org; > >> >> >> >> >Syrjala, Ville ; Lankhorst, Maarten > >> >> >> >> > > >> >> >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma > >> >> >> >> >Support > >> >> >> >> > > >> >> >> >> >On Mon, Apr 01, 2019 at 11:00:04PM +0530, Uma Shankar wrote: > >> >> >> >> >> This series adds support for programmable gamma modes and > >> >> >> >> >> exposes a property interface for the same. Also added, > >> >> >> >> >> support for multi segment gamma mode introduced in ICL+ > >> >> >> >> >> > >> >> >> >> >> It creates 2 property interfaces : > >> >> >> >> >> 1. GAMMA_MODE_CAPS: This is immutable property and exposes > >> >> >> >> >> the various gamma modes supported and the lut ranges. This > >> >> >> >> >> is an enum property with element as blob id. Getting the > >> >> >> >> >> blob id in userspace, user can get the mode supported and > >> >> >> >> >> also the range of gamma mode supported with number of lut > >coefficients. > >> >> >> >> >> > >> >> >> >> >> 2. GAMMA_MODE: This is for user to set the gamma mode and > >> >> >> >> >> send the lut values for that particular mode. > >> >> >> >> > > >> >> >> >> >I think we should just go for the BLOB_ENUM prop type instead. > >> >> >> >> >Then the possible values and the current value are all part of > >> >> >> >> >the same > >prop. > >> >> >> >> > >> >> >> >> Hi Ville, > >> >> >> >> With the current approach, we have enum property with values > >> >> >> >> as blob_ids (representing platform capabilities). This should > >> >> >> >> not get modified and needs to be immutable. > >> >> >> > > >> >> >> >That's not quite what we want. We want to let the user modify > >> >> >> >the current value so that they can actually select the gamma mode. > >> >> >> >Otherwise we need yet another prop for it, or we have to deduce > >> >> >> >it from the LUT size (that apporach would actually work for > >> >> >> >i915 but may not work for other drivers/hardware). > >> >> >> > > >> >> >> >> > >> >> >> >> Userspace can query the property and get the blob using the > >> >> >> >> blob_ids. > >> >> >> >> Thereby getting all the platform capabilities. > >> >> >> >> > >> >> >> >> Now to set the LUT values, he can use another blob property > >> >> >> >> and pass the luts. This is inline to how gamma/degamma is > >> >> >> >> implemented where we have one immutable
Re: [Intel-gfx] [PATCH 21/29] drm/i915: Switch back to an array of logical per-engine HW contexts
On 08/04/2019 10:17, Chris Wilson wrote:
We switched to a tree of per-engine HW context to accommodate the
introduction of virtual engines. However, we plan to also support
multiple instances of the same engine within the GEM context, defeating
our use of the engine as a key to looking up the HW context. Just
allocate a logical per-engine instance and always use an index into the
ctx->engines[]. Later on, this ctx->engines[] may be replaced by a user
specified map.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 97 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 25 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 3 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 29 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 92 +++---
drivers/gpu/drm/i915/i915_gem_context.h | 42
drivers/gpu/drm/i915/i915_gem_context_types.h | 26 -
drivers/gpu/drm/i915/i915_gem_execbuffer.c| 70 ++---
drivers/gpu/drm/i915/i915_perf.c | 81 +---
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 24 +++--
.../gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/selftests/mock_context.c | 14 ++-
16 files changed, 283 insertions(+), 230 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 46bf8d8fb7e4..803ac9a1dd15 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -17,7 +17,7 @@ static struct i915_global_context {
struct kmem_cache *slab_ce;
} global;
-struct intel_context *intel_context_alloc(void)
+static struct intel_context *intel_context_alloc(void)
{
return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
}
@@ -28,104 +28,17 @@ void intel_context_free(struct intel_context *ce)
}
struct intel_context *
-intel_context_lookup(struct i915_gem_context *ctx,
+intel_context_create(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
- struct intel_context *ce = NULL;
- struct rb_node *p;
-
- spin_lock(>hw_contexts_lock);
- p = ctx->hw_contexts.rb_node;
- while (p) {
- struct intel_context *this =
- rb_entry(p, struct intel_context, node);
-
- if (this->engine == engine) {
- GEM_BUG_ON(this->gem_context != ctx);
- ce = this;
- break;
- }
-
- if (this->engine < engine)
- p = p->rb_right;
- else
- p = p->rb_left;
- }
- spin_unlock(>hw_contexts_lock);
-
- return ce;
-}
-
-struct intel_context *
-__intel_context_insert(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
- struct intel_context *ce)
-{
- struct rb_node **p, *parent;
- int err = 0;
-
- spin_lock(>hw_contexts_lock);
-
- parent = NULL;
- p = >hw_contexts.rb_node;
- while (*p) {
- struct intel_context *this;
-
- parent = *p;
- this = rb_entry(parent, struct intel_context, node);
-
- if (this->engine == engine) {
- err = -EEXIST;
- ce = this;
- break;
- }
-
- if (this->engine < engine)
- p = >rb_right;
- else
- p = >rb_left;
- }
- if (!err) {
- rb_link_node(>node, parent, p);
- rb_insert_color(>node, >hw_contexts);
- }
-
- spin_unlock(>hw_contexts_lock);
-
- return ce;
-}
-
-void __intel_context_remove(struct intel_context *ce)
-{
- struct i915_gem_context *ctx = ce->gem_context;
-
- spin_lock(>hw_contexts_lock);
- rb_erase(>node, >hw_contexts);
- spin_unlock(>hw_contexts_lock);
-}
-
-struct intel_context *
-intel_context_instance(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine)
-{
- struct intel_context *ce, *pos;
-
- ce = intel_context_lookup(ctx, engine);
- if (likely(ce))
- return intel_context_get(ce);
+ struct intel_context *ce;
ce = intel_context_alloc();
if (!ce)
return ERR_PTR(-ENOMEM);
intel_context_init(ce, ctx, engine);
-
- pos = __intel_context_insert(ctx, engine, ce);
- if (unlikely(pos != ce)) /* Beaten! Use their HW context instead */
- intel_context_free(ce);
-
- GEM_BUG_ON(intel_context_lookup(ctx, engine) != pos);
- return
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't disable interrupts independently of the lock
== Series Details == Series: drm/i915: Don't disable interrupts independently of the lock URL : https://patchwork.freedesktop.org/series/59289/ State : success == Summary == CI Bug Log - changes from CI_DRM_5899 -> Patchwork_12755 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59289/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12755 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_basic@readonly-bsd1: - fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] +57 * igt@gem_exec_basic@readonly-bsd2: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76 * igt@kms_busy@basic-flip-c: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-glk-dsi: NOTRUN -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#103191] +1 Possible fixes * igt@i915_selftest@live_evict: - fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: INCOMPLETE [fdo#108602] / [fdo#108744] -> PASS * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] -> PASS [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (48 -> 43) -- Additional (2): fi-snb-2520m fi-pnv-d510 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_5899 -> Patchwork_12755 CI_DRM_5899: dc1c6a83767fa712be1d32b06047f2f2087b9ff1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4939: 64d0ff7247497ae6d726e4535fe74d4bb6ae914a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12755: 04aa9a19a6ead0f0b2c4b6f08630ea4a7f4422d3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 04aa9a19a6ea drm/i915: Don't disable interrupts independently of the lock == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12755/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm v2] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
'struct drm_syncobj_timeline_array'
- Added various DRM_IOCTL_SYNCOBJ_ ioctls
- Added some new RGB and YUV formats
- Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
- Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
- Added 'struct drm_mode_rect'
i915:
- Added struct 'struct i915_user_extension' and various 'struct
drm_i915_gem_context_'
- Added different modes of per-process Graphics Translation Table
Changes from v1:-
- Removed the changes to 'msm_drm.h' as it breaks the build for 'freedreno'
platform.
Signed-off-by: Ayan Kumar halder
/-- Note to reviewer:-
Please ignore the previous patch in this email thread.
--/
---
include/drm/drm.h| 36 +++
include/drm/drm_fourcc.h | 136 +++
include/drm/drm_mode.h | 23 -
include/drm/i915_drm.h | 237 ---
4 files changed, 396 insertions(+), 36 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a..c893f3b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+ __u32 src_handle;
+ __u32 dst_handle;
+ __u64 src_point;
+ __u64 dst_point;
+ __u32 flags;
+ __u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point
to become available */
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,33 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+ __u64 handles;
+ /* wait on specific timeline point for every handles*/
+ __u64 points;
+ /* absolute timeout */
+ __s64 timeout_nsec;
+ __u32 count_handles;
+ __u32 flags;
+ __u32 first_signaled; /* only valid when not waiting all */
+ __u32 pad;
+};
+
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+ __u64 handles;
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +934,11 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 139632b..3feeaa3 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
A:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
A:B:G:R 16:16:16:16 little endian */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
@@ -151,6 +162,52 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define
[Intel-gfx] [PATCH libdrm v2] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
'struct drm_syncobj_timeline_array'
- Added various DRM_IOCTL_SYNCOBJ_ ioctls
- Added some new RGB and YUV formats
- Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
- Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
- Added 'struct drm_mode_rect'
i915:
- Added struct 'struct i915_user_extension' and various 'struct
drm_i915_gem_context_'
- Added different modes of per-process Graphics Translation Table
Changes from v2:-
- Removed the changes to 'msm_drm.h' as it breaks the build for 'freedreno'
platform.
Change-Id: Ibfa8d4ceceae6f5bdc9d5f6b7ac658864ec03fc1
Signed-off-by: Ayan Kumar halder
---
include/drm/drm.h| 36 +++
include/drm/drm_fourcc.h | 136 +++
include/drm/drm_mode.h | 23 -
include/drm/i915_drm.h | 237 ---
4 files changed, 396 insertions(+), 36 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a..c893f3b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+ __u32 src_handle;
+ __u32 dst_handle;
+ __u64 src_point;
+ __u64 dst_point;
+ __u32 flags;
+ __u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point
to become available */
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,33 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+ __u64 handles;
+ /* wait on specific timeline point for every handles*/
+ __u64 points;
+ /* absolute timeout */
+ __s64 timeout_nsec;
+ __u32 count_handles;
+ __u32 flags;
+ __u32 first_signaled; /* only valid when not waiting all */
+ __u32 pad;
+};
+
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+ __u64 handles;
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +934,11 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 139632b..3feeaa3 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
A:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
A:B:G:R 16:16:16:16 little endian */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
@@ -151,6 +162,52 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U',
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 (rev2)
== Series Details == Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 (rev2) URL : https://patchwork.freedesktop.org/series/59278/ State : success == Summary == CI Bug Log - changes from CI_DRM_5899 -> Patchwork_12754 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59278/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12754 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_create@basic-files: - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106 * igt@gem_exec_basic@readonly-bsd1: - fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] +57 * igt@gem_exec_basic@readonly-bsd2: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76 * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: PASS -> FAIL [fdo#108511] * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: PASS -> DMESG-FAIL [fdo#110235 ] * igt@kms_busy@basic-flip-c: - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_force_connector_basic@force-edid: - fi-glk-dsi: NOTRUN -> SKIP [fdo#109271] +26 * igt@kms_frontbuffer_tracking@basic: - fi-glk-dsi: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] Possible fixes * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: INCOMPLETE [fdo#108602] / [fdo#108744] -> PASS * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] -> PASS Warnings * igt@i915_selftest@live_contexts: - fi-icl-y: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569] [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (48 -> 43) -- Additional (3): fi-gdg-551 fi-snb-2520m fi-pnv-d510 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-bsw-kefka fi-bdw-samus Build changes - * Linux: CI_DRM_5899 -> Patchwork_12754 CI_DRM_5899: dc1c6a83767fa712be1d32b06047f2f2087b9ff1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4939: 64d0ff7247497ae6d726e4535fe74d4bb6ae914a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12754: 3ac25ab2e2c8edde0aa38fb2062db0abd7595cb1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3ac25ab2e2c8 drm/i915/icl: Don't warn on spurious interrupts 202c43511515 drm/i915: Use Engine1 instance for gen11 pm interrupts 26aced1cf366 drm/i915/icl: Handle rps interrupts without irq lock 8954dd26252c drm/i915/icl: Disable video turbo mode for rp control fab7a9f30081 drm/i915/icl: Enable media sampler powergate a8f9a680f9cb drm/i915/icl: Apply a recommended rc6 threshold b962927fa121 drm/i915: Use dedicated rc6 enabling sequence for gen11 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12754/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11
== Series Details == Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 URL : https://patchwork.freedesktop.org/series/59278/ State : success == Summary == CI Bug Log - changes from CI_DRM_5898_full -> Patchwork_12751_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_12751_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12751_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_12751_full: ### IGT changes ### Warnings * igt@gem_pwrite_pread@display-pwrite-blt-gtt_mmap-correctness: - shard-snb: PASS -> ( 2 PASS ) +46 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-mmap-gtt: - shard-iclb: SKIP [fdo#109280] -> INCOMPLETE Known issues Here are the changes found in Patchwork_12751_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-kbl: PASS -> DMESG-WARN [fdo#108566] * igt@gem_pread@stolen-snoop: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +2 * igt@gem_pwrite@huge-gtt-fbr: - shard-iclb: NOTRUN -> SKIP [fdo#109290] * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - shard-iclb: NOTRUN -> SKIP [fdo#109308] * igt@i915_pm_rpm@gem-pread: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@i915_pm_rps@min-max-config-loaded: - shard-iclb: NOTRUN -> FAIL [fdo#108059] * igt@i915_pm_rps@waitboost: - shard-apl: PASS -> FAIL [fdo#102250] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@i915_suspend@fence-restore-untiled: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +5 * igt@kms_atomic_transition@4x-modeset-transitions: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +16 * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-e: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6 * igt@kms_busy@extended-pageflip-hang-oldfb-render-d: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +4 * igt@kms_chamelium@vga-hpd: - shard-iclb: NOTRUN -> SKIP [fdo#109284] +2 * igt@kms_content_protection@legacy: - shard-iclb: NOTRUN -> SKIP [fdo#109300] - shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_cursor_crc@cursor-256x85-sliding: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-512x512-sliding: - shard-iclb: NOTRUN -> SKIP [fdo#109279] * igt@kms_cursor_legacy@2x-flip-vs-cursor-legacy: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +3 * igt@kms_fbcon_fbt@psr: - shard-iclb: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: NOTRUN -> FAIL [fdo#105363] * igt@kms_flip@flip-vs-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#109507] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-iclb: PASS -> FAIL [fdo#103167] +7 * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +18 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#109247] +7 * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move: - shard-apl: NOTRUN -> SKIP [fdo#109271] +90 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-iclb: NOTRUN -> FAIL [fdo#109247] +3 * igt@kms_lease@cursor_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110278] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-apl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_psr@cursor_render: - shard-iclb: PASS -> DMESG-WARN [fdo#109960] * igt@kms_psr@psr2_no_drrs: - shard-iclb: PASS -> SKIP [fdo#109441] +1 * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: NOTRUN -> SKIP [fdo#109441] +1 * igt@kms_psr@sprite_plane_onoff: - shard-iclb: NOTRUN -> FAIL [fdo#107383] / [fdo#110215] * igt@kms_psr@sprite_render: - shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] * igt@kms_rotation_crc@bad-pixel-format: - shard-iclb: NOTRUN -> SKIP [fdo#109289]
Re: [Intel-gfx] [PATCH 19/29] drm/i915: Pass intel_context to intel_context_pin_lock()
On 10/04/2019 14:04, Chris Wilson wrote:
Quoting Chris Wilson (2019-04-10 13:49:32)
Quoting Tvrtko Ursulin (2019-04-10 13:45:05)
On 08/04/2019 10:17, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index da342e9a8c2e..4f8ef45e6344 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -39,9 +39,17 @@ intel_context_lookup(struct i915_gem_context *ctx,
* can neither be bound to the GPU or unbound whilst the lock is held, i.e.
* intel_context_is_pinned() remains stable.
*/
-struct intel_context *
-intel_context_pin_lock(struct i915_gem_context *ctx,
-struct intel_engine_cs *engine);
+static inline int intel_context_pin_lock(struct intel_context *ce)
+ __acquires(ce->pin_mutex)
+{
+ return mutex_lock_interruptible(>pin_mutex);
+}
So if this is not getting the kref any more why are the other callers
okay? In previous patch(es) some certainly looked like they assume pin
implies a reference.
This is not 'pin' but locking the pinned state.
Maybe lock_pin and unlock_pin? (I was going to say lock_pin_count, but
it strictly does not prevent updates to pin_count, merely the transition
to/from .pin_count == 0.)
I honestly cannot figure out now what I thought the problem is. Perhaps
I confused it with intel_context_pin.
There is so much churn in intel_context.c, both recent and in this
series, that I struggle to keep with it...
Went with intel_context_lock_pinned() and intel_context_unlock_pinned().
...so this is also okay. Perhaps add an assert that pin count is above
zero as well.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/execlists: Always reset the context's RING registers
Quoting Mika Kuoppala (2019-04-10 15:40:13) > Chris Wilson writes: > > /* Rerun the request; its payload has been neutered (if guilty). */ > > - rq->ring->head = intel_ring_wrap(rq->ring, rq->head); > > - intel_ring_update_space(rq->ring); > > +out_replay: > > + ce->ring->head = > > + rq ? intel_ring_wrap(ce->ring, rq->head) : ce->ring->tail; > > The ce and rq ring should be same with the rq set. I guess > you had a reasons to keep it as ce, perhaps because it is > the culprit. Yes, by this point we know that rq->hw_context == ce, and so rq->ring == ce->ring. I decided that execlists_reset() was now all about the active context, and the request just a hint as how far along that context we had completed -- hence trying to using ce as the primary throughout. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/execlists: Always reset the context's RING registers
Chris Wilson writes: > During reset, we try and stop the active ring. This has the consequence > that we often clobber the RING registers within the context image. When > we find an active request, we update the context image to rerun that > request (if it was guilty, we replace the hanging user payload with > NOPs). However, we were ignoring an active context if the request had > completed, with the consequence that the next submission on that request > would start with RING_HEAD==0 and not the tail of the previous request, > causing all requests still in the ring to be rerun. Rare, but > occasionally seen within CI where we would spot that the context seqno > would reverse and complain that we were retiring an incomplete request. > > <0> [412.390350] -0 3d.s2 408373352us : > __i915_request_submit: rcs0 fence 1e95b:3640 -> current 3638 > <0> [412.390350] -0 3d.s2 408373353us : > __i915_request_submit: rcs0 fence 1e95b:3642 -> current 3638 > <0> [412.390350] -0 3d.s2 408373354us : > __i915_request_submit: rcs0 fence 1e95b:3644 -> current 3638 > <0> [412.390350] -0 3d.s2 408373354us : > __i915_request_submit: rcs0 fence 1e95b:3646 -> current 3638 > <0> [412.390350] -0 3d.s2 408373356us : > __execlists_submission_tasklet: rcs0 in[0]: ctx=2.1, fence 1e95b:3646 > (current 3638), prio=4 > <0> [412.390350] i915_sel-46130 408373374us : > __i915_request_commit: rcs0 fence 1e95b:3648 > <0> [412.390350] i915_sel-46130d..1 408373377us : process_csb: rcs0 > cs-irq head=2, tail=3 > <0> [412.390350] i915_sel-46130d..1 408373377us : process_csb: rcs0 > csb[3]: status=0x0001:0x, active=0x1 > <0> [412.390350] i915_sel-46130d..1 408373378us : > __i915_request_submit: rcs0 fence 1e95b:3648 -> current 3638 > <0> [412.390350] -0 3..s1 408373378us : > execlists_submission_tasklet: rcs0 awake?=1, active=5 > <0> [412.390350] i915_sel-46130d..1 408373379us : > __execlists_submission_tasklet: rcs0 in[0]: ctx=2.2, fence 1e95b:3648 > (current 3638), prio=4 > <0> [412.390350] i915_sel-46130 408373381us : i915_reset_engine: > rcs0 flags=4 > <0> [412.390350] i915_sel-46130 408373382us : > execlists_reset_prepare: rcs0: depth<-0 > <0> [412.390350] -0 3d.s2 408373390us : process_csb: rcs0 > cs-irq head=3, tail=4 > <0> [412.390350] -0 3d.s2 408373390us : process_csb: rcs0 > csb[4]: status=0x8002:0x0002, active=0x1 > <0> [412.390350] -0 3d.s2 408373390us : process_csb: rcs0 > out[0]: ctx=2.2, fence 1e95b:3648 (current 3640), prio=4 > <0> [412.390350] i915_sel-46130 408373401us : > intel_engine_stop_cs: rcs0 > <0> [412.390350] i915_sel-46130d..1 408373402us : process_csb: rcs0 > cs-irq head=4, tail=4 > <0> [412.390350] i915_sel-46130 408373403us : intel_gpu_reset: > engine_mask=1 > <0> [412.390350] i915_sel-46130d..1 408373408us : > execlists_cancel_port_requests: rcs0:port0 fence 1e95b:3648, (current 3648) > <0> [412.390350] i915_sel-46130 408373442us : > intel_engine_cancel_stop_cs: rcs0 > <0> [412.390350] i915_sel-46130 408373442us : > execlists_reset_finish: rcs0: depth->0 > <0> [412.390350] ksoftirq-26 3..s. 408373442us : > execlists_submission_tasklet: rcs0 awake?=1, active=0 > <0> [412.390350] ksoftirq-26 3d.s1 408373443us : process_csb: rcs0 > cs-irq head=5, tail=5 > <0> [412.390350] i915_sel-46130 408373475us : > i915_request_retire: rcs0 fence 1e95b:3640, current 3648 > <0> [412.390350] i915_sel-46130 408373476us : > i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3640, current > 3648 > <0> [412.390350] i915_sel-46130 408373494us : > __i915_request_commit: rcs0 fence 1e95b:3650 > <0> [412.390350] i915_sel-46130d..1 408373496us : process_csb: rcs0 > cs-irq head=5, tail=5 > <0> [412.390350] i915_sel-46130d..1 408373496us : > __i915_request_submit: rcs0 fence 1e95b:3650 -> current 3648 > <0> [412.390350] i915_sel-46130d..1 408373498us : > __execlists_submission_tasklet: rcs0 in[0]: ctx=2.1, fence 1e95b:3650 > (current 3648), prio=6 > <0> [412.390350] i915_sel-46130 408373500us : > i915_request_retire_upto: rcs0 fence 1e95b:3648, current 3648 > <0> [412.390350] i915_sel-46130 408373500us : > i915_request_retire: rcs0 fence 1e95b:3642, current 3648 > <0> [412.390350] i915_sel-46130 408373501us : > i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3642, current > 3648 > <0> [412.390350] i915_sel-46130 408373514us : > i915_request_retire: rcs0 fence 1e95b:3644, current 3648 > <0> [412.390350] i915_sel-46130 408373515us : > i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3644, current > 3648 > <0> [412.390350] i915_sel-46130 408373527us : >
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 (rev2)
== Series Details == Series: series starting with [1/7] drm/i915: Use dedicated rc6 enabling sequence for gen11 (rev2) URL : https://patchwork.freedesktop.org/series/59278/ State : warning == Summary == $ dim checkpatch origin/drm-tip b962927fa121 drm/i915: Use dedicated rc6 enabling sequence for gen11 -:29: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #29: FILE: drivers/gpu/drm/i915/intel_pm.c:7132: +* hasn't enabled a state yet where we need forcewake, BIOS may have.*/ total: 0 errors, 1 warnings, 0 checks, 84 lines checked a8f9a680f9cb drm/i915/icl: Apply a recommended rc6 threshold fab7a9f30081 drm/i915/icl: Enable media sampler powergate 8954dd26252c drm/i915/icl: Disable video turbo mode for rp control 26aced1cf366 drm/i915/icl: Handle rps interrupts without irq lock 202c43511515 drm/i915: Use Engine1 instance for gen11 pm interrupts 3ac25ab2e2c8 drm/i915/icl: Don't warn on spurious interrupts ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/icl: Handle rps interrupts without irq lock
== Series Details == Series: series starting with [CI,1/2] drm/i915/icl: Handle rps interrupts without irq lock URL : https://patchwork.freedesktop.org/series/59288/ State : success == Summary == CI Bug Log - changes from CI_DRM_5899 -> Patchwork_12753 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59288/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12753 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_create@basic-files: - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106 * igt@gem_exec_basic@readonly-bsd1: - fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] +57 * igt@gem_exec_basic@readonly-bsd2: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76 * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@kms_busy@basic-flip-c: - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_force_connector_basic@force-edid: - fi-glk-dsi: NOTRUN -> SKIP [fdo#109271] +26 * igt@kms_frontbuffer_tracking@basic: - fi-glk-dsi: NOTRUN -> FAIL [fdo#103167] Possible fixes * igt@i915_selftest@live_evict: - fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: INCOMPLETE [fdo#108602] / [fdo#108744] -> PASS * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - fi-glk-dsi: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (48 -> 44) -- Additional (3): fi-gdg-551 fi-snb-2520m fi-pnv-d510 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-dsi fi-bdw-samus Build changes - * Linux: CI_DRM_5899 -> Patchwork_12753 CI_DRM_5899: dc1c6a83767fa712be1d32b06047f2f2087b9ff1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4939: 64d0ff7247497ae6d726e4535fe74d4bb6ae914a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12753: 4a8a319db124f9329bc62f981e9006dba79e5623 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4a8a319db124 drm/i915/icl: Don't warn on spurious interrupts e74ab3267e47 drm/i915/icl: Handle rps interrupts without irq lock == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12753/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't disable interrupts independently of the lock
The locks (timeline->lock and rq->lock) need to be taken with disabled interrupts. This is done in __retire_engine_request() by disabling the interrupts independently of the locks itself. While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla it does not on RT. Also, it is not obvious if there is a special reason to why the interrupts are disabled independently of the lock. Enable/disable interrupts as part of the locking instruction. Signed-off-by: Sebastian Andrzej Siewior --- drivers/gpu/drm/i915/i915_request.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index ca95ab2f4cfa3..8744d20ac1681 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -278,9 +278,7 @@ static void __retire_engine_request(struct intel_engine_cs *engine, GEM_BUG_ON(!i915_request_completed(rq)); - local_irq_disable(); - - spin_lock(>timeline.lock); + spin_lock_irq(>timeline.lock); GEM_BUG_ON(!list_is_first(>link, >timeline.requests)); list_del_init(>link); spin_unlock(>timeline.lock); @@ -294,9 +292,7 @@ static void __retire_engine_request(struct intel_engine_cs *engine, GEM_BUG_ON(!atomic_read(>i915->gt_pm.rps.num_waiters)); atomic_dec(>i915->gt_pm.rps.num_waiters); } - spin_unlock(>lock); - - local_irq_enable(); + spin_unlock_irq(>lock); /* * The backing object for the context is done after switching to the -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/icl: Apply a recommended rc6 threshold
On Wed, 10 Apr 2019 12:59:18 +0200, Mika Kuoppala wrote: On gen11 the recommended rc6 threshold differs from previous gens, apply it. Move the write to a correct spot in sequence. v2: do write in 2b, fix bspec ref (Michal) Bspec: 33149 Cc: Michal Wajdeczko Signed-off-by: Mika Kuoppala Full sequence still slightly differs compared to the spec, but that's other story. Reviewed-by: Michal Wajdeczko ~Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: Disable video turbo mode for rp control
Quoting Mika Kuoppala (2019-04-10 14:24:36) > There is no video turbo mode for gen11, so don't set it. > > v2: inline (Chris) > v3: brackets (Chris) > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala Acked-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Use Engine1 instance for gen11 pm interrupts
Quoting Mika Kuoppala (2019-04-10 11:59:22) > With gen11 the interrupt registers are shared between 2 engines, > with Engine1 instance being upper word and Engine0 instance being > lower. Annoyingly gen11 selected the pm interrupts to be in the > Engine1 instance. > > Rectify the situation by shifting the access accordingly, > based on gen. > > v2: comments, warn on overzealous rps_events > > Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=108059 > Testcase: igt/i915_pm_rps@min-max-config-loaded > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala Acked-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915/icl: Enable media sampler powergate
Quoting Mika Kuoppala (2019-04-10 11:59:19) > Enable media sampler powergate as recommended. > > v2: use REG_BIT (Chris) > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala Acked-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/icl: Apply a recommended rc6 threshold
Quoting Mika Kuoppala (2019-04-10 11:59:18) > On gen11 the recommended rc6 threshold differs from previous > gens, apply it. Move the write to a correct spot in sequence. > > v2: do write in 2b, fix bspec ref (Michal) Yes, it does make more sense not to include it as part of the 'rc6 enabling sequence' but as setup. > Bspec: 33149 > Cc: Michal Wajdeczko > Signed-off-by: Mika Kuoppala Acked-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/29] drm/i915: Split engine setup/init into two phases
On 08/04/2019 10:17, Chris Wilson wrote:
In the next patch, we require the engine vfuncs setup prior to
initialising the pinned kernel contexts, so split the vfunc setup from
the engine initialisation and call it earlier.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h| 8 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 99
drivers/gpu/drm/i915/gt/intel_lrc.c | 74 ++
drivers/gpu/drm/i915/gt/intel_lrc.h | 5 +-
drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 232 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 48 ++--
drivers/gpu/drm/i915/gt/mock_engine.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 6 +
.../gpu/drm/i915/selftests/mock_gem_device.c | 12 +-
10 files changed, 245 insertions(+), 244 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index a17152e96bf8..a8dc2740ba2f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -362,14 +362,12 @@ __intel_ring_space(unsigned int head, unsigned int tail,
unsigned int size)
return (head - tail - CACHELINE_BYTES) & (size - 1);
}
-int intel_engine_setup_common(struct intel_engine_cs *engine);
+int intel_engines_setup(struct drm_i915_private *i915);
int intel_engine_init_common(struct intel_engine_cs *engine);
void intel_engine_cleanup_common(struct intel_engine_cs *engine);
-int intel_init_render_ring_buffer(struct intel_engine_cs *engine);
-int intel_init_bsd_ring_buffer(struct intel_engine_cs *engine);
-int intel_init_blt_ring_buffer(struct intel_engine_cs *engine);
-int intel_init_vebox_ring_buffer(struct intel_engine_cs *engine);
+int intel_ring_submission_setup(struct intel_engine_cs *engine);
+int intel_ring_submission_init(struct intel_engine_cs *engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f6828c0276eb..3f794bc71958 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -50,35 +50,24 @@
struct engine_class_info {
const char *name;
- int (*init_legacy)(struct intel_engine_cs *engine);
- int (*init_execlists)(struct intel_engine_cs *engine);
-
u8 uabi_class;
};
static const struct engine_class_info intel_engine_classes[] = {
[RENDER_CLASS] = {
.name = "rcs",
- .init_execlists = logical_render_ring_init,
- .init_legacy = intel_init_render_ring_buffer,
.uabi_class = I915_ENGINE_CLASS_RENDER,
},
[COPY_ENGINE_CLASS] = {
.name = "bcs",
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_blt_ring_buffer,
.uabi_class = I915_ENGINE_CLASS_COPY,
},
[VIDEO_DECODE_CLASS] = {
.name = "vcs",
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_bsd_ring_buffer,
.uabi_class = I915_ENGINE_CLASS_VIDEO,
},
[VIDEO_ENHANCEMENT_CLASS] = {
.name = "vecs",
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_vebox_ring_buffer,
.uabi_class = I915_ENGINE_CLASS_VIDEO_ENHANCE,
},
};
@@ -400,48 +389,39 @@ int intel_engines_init_mmio(struct drm_i915_private
*dev_priv)
/**
* intel_engines_init() - init the Engine Command Streamers
- * @dev_priv: i915 device private
+ * @i915: i915 device private
*
* Return: non-zero if the initialization failed.
*/
-int intel_engines_init(struct drm_i915_private *dev_priv)
+int intel_engines_init(struct drm_i915_private *i915)
{
+ int (*init)(struct intel_engine_cs *engine);
struct intel_engine_cs *engine;
enum intel_engine_id id, err_id;
int err;
- for_each_engine(engine, dev_priv, id) {
- const struct engine_class_info *class_info =
- _engine_classes[engine->class];
- int (*init)(struct intel_engine_cs *engine);
-
- if (HAS_EXECLISTS(dev_priv))
- init = class_info->init_execlists;
- else
- init = class_info->init_legacy;
+ if (HAS_EXECLISTS(i915))
+ init = intel_execlists_submission_init;
+ else
+ init = intel_ring_submission_init;
- err = -EINVAL;
+ for_each_engine(engine, i915, id) {
err_id = id;
- if (GEM_DEBUG_WARN_ON(!init))
- goto cleanup;
-
err = init(engine);
if (err)
[Intel-gfx] [PATCH 4/7] drm/i915/icl: Disable video turbo mode for rp control
There is no video turbo mode for gen11, so don't set it. v2: inline (Chris) v3: brackets (Chris) Cc: Chris Wilson Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 5aac4abb820c..a1ba11f99f58 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -6606,7 +6606,7 @@ static void rps_set_power(struct drm_i915_private *dev_priv, int new_power) ei_down * threshold_down / 100)); I915_WRITE(GEN6_RP_CONTROL, - GEN6_RP_MEDIA_TURBO | + (INTEL_GEN(dev_priv) > 9 ? 0 : GEN6_RP_MEDIA_TURBO) | GEN6_RP_MEDIA_HW_NORMAL_MODE | GEN6_RP_MEDIA_IS_GFX | GEN6_RP_ENABLE | -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] snd/hda: Only get/put display_power once
On Wed, 10 Apr 2019 15:07:28 +0200, Chris Wilson wrote: > > Quoting Takashi Iwai (2019-04-10 12:03:22) > > On Wed, 10 Apr 2019 12:44:49 +0200, > > Takashi Iwai wrote: > > > > > > On Wed, 10 Apr 2019 12:24:24 +0200, > > > Chris Wilson wrote: > > > > > > > > Quoting Takashi Iwai (2019-04-10 11:09:47) > > > > > On Wed, 10 Apr 2019 10:17:33 +0200, > > > > > Chris Wilson wrote: > > > > > > > > > > > > While we only allow a single display power reference, the current > > > > > > acquisition/release is racy and a direct call may run concurrently > > > > > > with > > > > > > a runtime-pm worker. Prevent the double unreference by atomically > > > > > > tracking the display_power_active cookie. > > > > > > > > > > > > Testcase: igt/i915_pm_rpm/module-reload #glk-dsi > > > > > > Signed-off-by: Chris Wilson > > > > > > Cc: Takashi Iwai > > > > > > Cc: Imre Deak > > > > > > > > > > I rather prefer a more straightforward conversion, e.g. something like > > > > > below. Checking the returned cookie as the state flag is not quite > > > > > intuitive, so revive the boolean state flag, and handle it > > > > > atomically. > > > > > > > > Access to the cookie itself is not atomic there, and theoretically > > > > there could be a get/put/get running concurrently. Are you sure don't > > > > want a refcount and lock here? :) > > > > > > The refcount is what we want to reduce, so the suitable option would > > > be a (yet another) mutex although the cmpxchg() should be enough for > > > normal cases. > > > > > > > Your call. For the case CI is hitting, it should do the trick (as we are > > > > only seeing the race on put/put I think). CI will answer in a hour or > > > > two. > > > > > > OK, once when it seems working, I'll respin a patch with a mutex > > > instead. We have already a one that is used for the link state > > > change, and this can be reused. > > > > It's even simpler, so maybe this is a better way to go... > > > > If this is confirmed to work, feel free to queue via drm tree. > > I can't apply this because this is on top of your recent cookie and > > sub-component changes that aren't on sound git tree (yet). > > Success \o/ > Reviewed-by: Chris Wilson > > Ok, we'll plonk it in dinq, but I think it should apply to sound.git? > Looks fairly separate. Indeed, it's applicable, so I'm going to queue via sound tree. I thought it would conflict but that was about the previous version fiddling with cmpxchg(). This one is simpler, yeah. > Anyway that can all be resolved in a later merge if required. Sure, I guess it must be trivial, if any. Thanks! Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support
>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ville >Syrjälä >Sent: Monday, April 8, 2019 9:38 PM >To: Shankar, Uma >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri- >de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville >; Lankhorst, Maarten >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support > >On Mon, Apr 08, 2019 at 03:59:51PM +, Shankar, Uma wrote: >> >> >> >-Original Message- >> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On >> >Behalf Of Ville Syrjälä >> >Sent: Monday, April 8, 2019 9:15 PM >> >To: Shankar, Uma >> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri- >> >de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville >> >; Lankhorst, Maarten >> > >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support >> > >> >On Mon, Apr 08, 2019 at 03:40:39PM +, Shankar, Uma wrote: >> >> >> >> >> >> >-Original Message- >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >> >Sent: Monday, April 8, 2019 8:27 PM >> >> >To: Shankar, Uma >> >> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri- >> >> >de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville >> >> >; Lankhorst, Maarten >> >> > >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support >> >> > >> >> >On Mon, Apr 08, 2019 at 02:40:51PM +, Shankar, Uma wrote: >> >> >> >> >> >> >> >> >> >-Original Message- >> >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >> >> >Sent: Monday, April 8, 2019 6:01 PM >> >> >> >To: Shankar, Uma >> >> >> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; >> >> >> >dri- de...@lists.freedesktop.org; seanp...@chromium.org; >> >> >> >Syrjala, Ville ; Lankhorst, Maarten >> >> >> > >> >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma >> >> >> >Support >> >> >> > >> >> >> >On Mon, Apr 08, 2019 at 12:26:23PM +, Shankar, Uma wrote: >> >> >> >> >> >> >> >> >> >> >> >> >-Original Message- >> >> >> >> >From: dri-devel >> >> >> >> >[mailto:dri-devel-boun...@lists.freedesktop.org] >> >> >> >> >On Behalf Of Ville Syrjälä >> >> >> >> >Sent: Friday, April 5, 2019 9:42 PM >> >> >> >> >To: Shankar, Uma >> >> >> >> >Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; >> >> >> >> >dri- de...@lists.freedesktop.org; seanp...@chromium.org; >> >> >> >> >Syrjala, Ville ; Lankhorst, Maarten >> >> >> >> > >> >> >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma >> >> >> >> >Support >> >> >> >> > >> >> >> >> >On Mon, Apr 01, 2019 at 11:00:04PM +0530, Uma Shankar wrote: >> >> >> >> >> This series adds support for programmable gamma modes and >> >> >> >> >> exposes a property interface for the same. Also added, >> >> >> >> >> support for multi segment gamma mode introduced in ICL+ >> >> >> >> >> >> >> >> >> >> It creates 2 property interfaces : >> >> >> >> >> 1. GAMMA_MODE_CAPS: This is immutable property and exposes >> >> >> >> >> the various gamma modes supported and the lut ranges. This >> >> >> >> >> is an enum property with element as blob id. Getting the >> >> >> >> >> blob id in userspace, user can get the mode supported and >> >> >> >> >> also the range of gamma mode supported with number of lut >coefficients. >> >> >> >> >> >> >> >> >> >> 2. GAMMA_MODE: This is for user to set the gamma mode and >> >> >> >> >> send the lut values for that particular mode. >> >> >> >> > >> >> >> >> >I think we should just go for the BLOB_ENUM prop type instead. >> >> >> >> >Then the possible values and the current value are all part of the >> >> >> >> >same >prop. >> >> >> >> >> >> >> >> Hi Ville, >> >> >> >> With the current approach, we have enum property with values >> >> >> >> as blob_ids (representing platform capabilities). This should >> >> >> >> not get modified and needs to be immutable. >> >> >> > >> >> >> >That's not quite what we want. We want to let the user modify >> >> >> >the current value so that they can actually select the gamma mode. >> >> >> >Otherwise we need yet another prop for it, or we have to deduce >> >> >> >it from the LUT size (that apporach would actually work for >> >> >> >i915 but may not work for other drivers/hardware). >> >> >> > >> >> >> >> >> >> >> >> Userspace can query the property and get the blob using the >> >> >> >> blob_ids. >> >> >> >> Thereby getting all the platform capabilities. >> >> >> >> >> >> >> >> Now to set the LUT values, he can use another blob property >> >> >> >> and pass the luts. This is inline to how gamma/degamma is >> >> >> >> implemented where we have one immutable LUT_SIZE property >> >> >> >> (indicating number of >> >> >> >> luts) and another blob property for actual lut values.. >> >> >> >> >> >> Hi Ville, >> >> >> Just to clarify and clear some doubts :) >> >> >> >> >> >> We should be able to set the gamma mode using the blob enum value. >>
[Intel-gfx] [CI 1/2] drm/i915/icl: Handle rps interrupts without irq lock
Unlike previous gens, we already hold the irq_lock on
entering the rps handler so we can't use it as it is.
Make a gen11 specific rps interrupt handler without
locking.
v2: return early (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6454ddc37f8b..eb0eb96ac751 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1796,6 +1796,25 @@ static void i9xx_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
/* The RPS events need forcewake, so we add them to a work queue and mask their
* IMR bits until the work is done. Other interrupts can be processed without
* the work queue. */
+static void gen11_rps_irq_handler(struct drm_i915_private *i915, u32 pm_iir)
+{
+ struct intel_rps *rps = >gt_pm.rps;
+ const u32 events = i915->pm_rps_events & pm_iir;
+
+ lockdep_assert_held(>irq_lock);
+
+ if (unlikely(!events))
+ return;
+
+ gen6_mask_pm_irq(i915, events);
+
+ if (!rps->interrupts_enabled)
+ return;
+
+ rps->pm_iir |= events;
+ schedule_work(>work);
+}
+
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 pm_iir)
{
struct intel_rps *rps = _priv->gt_pm.rps;
@@ -2949,7 +2968,7 @@ gen11_other_irq_handler(struct drm_i915_private * const
i915,
const u8 instance, const u16 iir)
{
if (instance == OTHER_GTPM_INSTANCE)
- return gen6_rps_irq_handler(i915, iir);
+ return gen11_rps_irq_handler(i915, iir);
WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
instance, iir);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/icl: Don't warn on spurious interrupts
There is a chance we can see spurious interrupts in live
now. We have more engines enabled and that with more elaborate
access patterns with pm and display, increases the chances
hardware just makes a social call, without anything to work on.
Remove the error as we have tests to actually probe if
we really miss interrupt, instead of getting spurious ones.
Note that now we do write to intr_dw even with a zero
value. This is considered advantegous as the write
is an ack that sw is done.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eb0eb96ac751..8d8935d71180 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3025,14 +3025,8 @@ gen11_gt_bank_handler(struct drm_i915_private * const
i915,
intr_dw = raw_reg_read(regs, GEN11_GT_INTR_DW(bank));
- if (unlikely(!intr_dw)) {
- DRM_ERROR("GT_INTR_DW%u blank!\n", bank);
- return;
- }
-
for_each_set_bit(bit, _dw, 32) {
- const u32 ident = gen11_gt_engine_identity(i915,
- bank, bit);
+ const u32 ident = gen11_gt_engine_identity(i915, bank, bit);
gen11_gt_identity_handler(i915, ident);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] snd/hda: Only get/put display_power once
Quoting Takashi Iwai (2019-04-10 12:03:22) > On Wed, 10 Apr 2019 12:44:49 +0200, > Takashi Iwai wrote: > > > > On Wed, 10 Apr 2019 12:24:24 +0200, > > Chris Wilson wrote: > > > > > > Quoting Takashi Iwai (2019-04-10 11:09:47) > > > > On Wed, 10 Apr 2019 10:17:33 +0200, > > > > Chris Wilson wrote: > > > > > > > > > > While we only allow a single display power reference, the current > > > > > acquisition/release is racy and a direct call may run concurrently > > > > > with > > > > > a runtime-pm worker. Prevent the double unreference by atomically > > > > > tracking the display_power_active cookie. > > > > > > > > > > Testcase: igt/i915_pm_rpm/module-reload #glk-dsi > > > > > Signed-off-by: Chris Wilson > > > > > Cc: Takashi Iwai > > > > > Cc: Imre Deak > > > > > > > > I rather prefer a more straightforward conversion, e.g. something like > > > > below. Checking the returned cookie as the state flag is not quite > > > > intuitive, so revive the boolean state flag, and handle it > > > > atomically. > > > > > > Access to the cookie itself is not atomic there, and theoretically > > > there could be a get/put/get running concurrently. Are you sure don't > > > want a refcount and lock here? :) > > > > The refcount is what we want to reduce, so the suitable option would > > be a (yet another) mutex although the cmpxchg() should be enough for > > normal cases. > > > > > Your call. For the case CI is hitting, it should do the trick (as we are > > > only seeing the race on put/put I think). CI will answer in a hour or > > > two. > > > > OK, once when it seems working, I'll respin a patch with a mutex > > instead. We have already a one that is used for the link state > > change, and this can be reused. > > It's even simpler, so maybe this is a better way to go... > > If this is confirmed to work, feel free to queue via drm tree. > I can't apply this because this is on top of your recent cookie and > sub-component changes that aren't on sound git tree (yet). Success \o/ Reviewed-by: Chris Wilson Ok, we'll plonk it in dinq, but I think it should apply to sound.git? Looks fairly separate. Anyway that can all be resolved in a later merge if required. Thanks, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/29] drm/i915: Pass intel_context to intel_context_pin_lock()
Quoting Chris Wilson (2019-04-10 13:49:32)
> Quoting Tvrtko Ursulin (2019-04-10 13:45:05)
> >
> > On 08/04/2019 10:17, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index da342e9a8c2e..4f8ef45e6344 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > > @@ -39,9 +39,17 @@ intel_context_lookup(struct i915_gem_context *ctx,
> > >* can neither be bound to the GPU or unbound whilst the lock is held,
> > > i.e.
> > >* intel_context_is_pinned() remains stable.
> > >*/
> > > -struct intel_context *
> > > -intel_context_pin_lock(struct i915_gem_context *ctx,
> > > -struct intel_engine_cs *engine);
> > > +static inline int intel_context_pin_lock(struct intel_context *ce)
> > > + __acquires(ce->pin_mutex)
> > > +{
> > > + return mutex_lock_interruptible(>pin_mutex);
> > > +}
> >
> > So if this is not getting the kref any more why are the other callers
> > okay? In previous patch(es) some certainly looked like they assume pin
> > implies a reference.
>
> This is not 'pin' but locking the pinned state.
> Maybe lock_pin and unlock_pin? (I was going to say lock_pin_count, but
> it strictly does not prevent updates to pin_count, merely the transition
> to/from .pin_count == 0.)
Went with intel_context_lock_pinned() and intel_context_unlock_pinned().
-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 snd/hda: Only get/put display_power once (rev3)
== Series Details == Series: snd/hda: Only get/put display_power once (rev3) URL : https://patchwork.freedesktop.org/series/59267/ State : success == Summary == CI Bug Log - changes from CI_DRM_5898 -> Patchwork_12752 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/59267/revisions/3/mbox/ Known issues Here are the changes found in Patchwork_12752 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-glk-dsi: NOTRUN -> SKIP [fdo#109271] +17 * igt@gem_exec_basic@gtt-bsd2: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +57 * igt@i915_selftest@live_execlists: - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +48 * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: NOTRUN -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_psr@cursor_plane_move: - fi-skl-6260u: NOTRUN -> SKIP [fdo#109271] +37 * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: DMESG-WARN [fdo#105538] / [fdo#107732] / [fdo#109513] -> PASS * igt@i915_selftest@live_hangcheck: - fi-bxt-dsi: INCOMPLETE [fdo#103927] -> PASS Warnings * igt@i915_selftest@live_contexts: - fi-icl-y: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569] [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105538]: https://bugs.freedesktop.org/show_bug.cgi?id=105538 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109513]: https://bugs.freedesktop.org/show_bug.cgi?id=109513 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 Participating hosts (49 -> 43) -- Additional (2): fi-byt-clapper fi-skl-6260u Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_5898 -> Patchwork_12752 CI_DRM_5898: b7ec63a9ba82930148c90769d04f957f10b6b6da @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4937: 256c6107ee127d2ff07d23dfeb3b8d828cb43b37 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12752: 95d66eed4e0bad29cef567574e82e18dbb3a4d27 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 95d66eed4e0b snd/hda: Only get/put display_power once == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12752/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/dp: revert back to max link rate and lane count on eDP
On Fri, 05 Apr 2019, Rodrigo Vivi wrote:
> On Fri, Apr 05, 2019 at 10:52:20AM +0300, Jani Nikula wrote:
>> Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
>> and narrow") started to optize the eDP 1.4+ link config, both per spec
>> and as preparation for display stream compression support.
>>
>> Sadly, we again face panels that flat out fail with parameters they
>> claim to support. Revert, and go back to the drawing board.
>>
>> v2: Actually revert to max params instead of just wide-and-slow.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
>> Fixes: 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and
>> narrow")
>> Cc: Ville Syrjälä
>> Cc: Manasi Navare
>> Cc: Rodrigo Vivi
>> Cc: Matt Atwood
>> Cc: "Lee, Shawn C"
>> Cc: Dave Airlie
>> Cc: intel-gfx@lists.freedesktop.org
>> Cc: # v5.0+
>> Signed-off-by: Jani Nikula
>
> I can hear from here your "I told you so"... Sorry!
>
> Reviewed-by: Rodrigo Vivi
Thanks, pushed, please cherry-pick this for drm-intel-fixes.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 69 +
>> 1 file changed, 10 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 72c490..dfa770 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1856,42 +1856,6 @@ intel_dp_compute_link_config_wide(struct intel_dp
>> *intel_dp,
>> return -EINVAL;
>> }
>>
>> -/* Optimize link config in order: max bpp, min lanes, min clock */
>> -static int
>> -intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
>> - struct intel_crtc_state *pipe_config,
>> - const struct link_config_limits *limits)
>> -{
>> -struct drm_display_mode *adjusted_mode =
>> _config->base.adjusted_mode;
>> -int bpp, clock, lane_count;
>> -int mode_rate, link_clock, link_avail;
>> -
>> -for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
>> -mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
>> - bpp);
>> -
>> -for (lane_count = limits->min_lane_count;
>> - lane_count <= limits->max_lane_count;
>> - lane_count <<= 1) {
>> -for (clock = limits->min_clock; clock <=
>> limits->max_clock; clock++) {
>> -link_clock = intel_dp->common_rates[clock];
>> -link_avail = intel_dp_max_data_rate(link_clock,
>> -lane_count);
>> -
>> -if (mode_rate <= link_avail) {
>> -pipe_config->lane_count = lane_count;
>> -pipe_config->pipe_bpp = bpp;
>> -pipe_config->port_clock = link_clock;
>> -
>> -return 0;
>> -}
>> -}
>> -}
>> -}
>> -
>> -return -EINVAL;
>> -}
>> -
>> static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
>> dsc_max_bpc)
>> {
>> int i, num_bpc;
>> @@ -2028,15 +1992,13 @@ intel_dp_compute_link_config(struct intel_encoder
>> *encoder,
>> limits.min_bpp = 6 * 3;
>> limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>>
>> -if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
>> +if (intel_dp_is_edp(intel_dp)) {
>> /*
>> * Use the maximum clock and number of lanes the eDP panel
>> - * advertizes being capable of. The eDP 1.3 and earlier panels
>> - * are generally designed to support only a single clock and
>> - * lane configuration, and typically these values correspond to
>> - * the native resolution of the panel. With eDP 1.4 rate select
>> - * and DSC, this is decreasingly the case, and we need to be
>> - * able to select less than maximum link config.
>> + * advertizes being capable of. The panels are generally
>> + * designed to support only a single clock and lane
>> + * configuration, and typically these values correspond to the
>> + * native resolution of the panel.
>> */
>> limits.min_lane_count = limits.max_lane_count;
>> limits.min_clock = limits.max_clock;
>> @@ -2050,22 +2012,11 @@ intel_dp_compute_link_config(struct intel_encoder
>> *encoder,
>>intel_dp->common_rates[limits.max_clock],
>>limits.max_bpp, adjusted_mode->crtc_clock);
>>
>> -if (intel_dp_is_edp(intel_dp))
>> -/*
>> - * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
>> - * section A.1: "It is recommended
Re: [Intel-gfx] [PATCH 19/29] drm/i915: Pass intel_context to intel_context_pin_lock()
Quoting Tvrtko Ursulin (2019-04-10 13:45:05)
>
> On 08/04/2019 10:17, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > b/drivers/gpu/drm/i915/gt/intel_context.h
> > index da342e9a8c2e..4f8ef45e6344 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -39,9 +39,17 @@ intel_context_lookup(struct i915_gem_context *ctx,
> >* can neither be bound to the GPU or unbound whilst the lock is held,
> > i.e.
> >* intel_context_is_pinned() remains stable.
> >*/
> > -struct intel_context *
> > -intel_context_pin_lock(struct i915_gem_context *ctx,
> > -struct intel_engine_cs *engine);
> > +static inline int intel_context_pin_lock(struct intel_context *ce)
> > + __acquires(ce->pin_mutex)
> > +{
> > + return mutex_lock_interruptible(>pin_mutex);
> > +}
>
> So if this is not getting the kref any more why are the other callers
> okay? In previous patch(es) some certainly looked like they assume pin
> implies a reference.
This is not 'pin' but locking the pinned state.
Maybe lock_pin and unlock_pin? (I was going to say lock_pin_count, but
it strictly does not prevent updates to pin_count, merely the transition
to/from .pin_count == 0.)
The usecase example is ctx_sseu that wants to inspect the current status
of the context and operate on pinned/not-pinned safe in the knowledge
that can't change as it does so.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/29] drm/i915: Pass intel_context to intel_context_pin_lock()
On 08/04/2019 10:17, Chris Wilson wrote:
Move the intel_context_instance() to the caller so that we can decouple
ourselves from one context instance per engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 26 --
drivers/gpu/drm/i915/gt/intel_context.h | 14 ++-
drivers/gpu/drm/i915/i915_gem_context.c | 88 +++
.../gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
4 files changed, 64 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index a1267739e369..46bf8d8fb7e4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -128,32 +128,6 @@ intel_context_instance(struct i915_gem_context *ctx,
return intel_context_get(pos);
}
-struct intel_context *
-intel_context_pin_lock(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine)
- __acquires(ce->pin_mutex)
-{
- struct intel_context *ce;
-
- ce = intel_context_instance(ctx, engine);
- if (IS_ERR(ce))
- return ce;
-
- if (mutex_lock_interruptible(>pin_mutex)) {
- intel_context_put(ce);
- return ERR_PTR(-EINTR);
- }
-
- return ce;
-}
-
-void intel_context_pin_unlock(struct intel_context *ce)
- __releases(ce->pin_mutex)
-{
- mutex_unlock(>pin_mutex);
- intel_context_put(ce);
-}
-
int __intel_context_do_pin(struct intel_context *ce)
{
int err;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index da342e9a8c2e..4f8ef45e6344 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -39,9 +39,17 @@ intel_context_lookup(struct i915_gem_context *ctx,
* can neither be bound to the GPU or unbound whilst the lock is held, i.e.
* intel_context_is_pinned() remains stable.
*/
-struct intel_context *
-intel_context_pin_lock(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine);
+static inline int intel_context_pin_lock(struct intel_context *ce)
+ __acquires(ce->pin_mutex)
+{
+ return mutex_lock_interruptible(>pin_mutex);
+}
So if this is not getting the kref any more why are the other callers
okay? In previous patch(es) some certainly looked like they assume pin
implies a reference.
+
+static inline void intel_context_pin_unlock(struct intel_context *ce)
+ __releases(ce->pin_mutex)
+{
+ mutex_unlock(>pin_mutex);
+}
static inline bool
intel_context_is_pinned(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 51c427ac0c21..1e84fe0a4c55 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -141,6 +141,18 @@ static void lut_close(struct i915_gem_context *ctx)
rcu_read_unlock();
}
+static struct intel_context *
+lookup_user_engine(struct i915_gem_context *ctx, u16 class, u16 instance)
+{
+ struct intel_engine_cs *engine;
+
+ engine = intel_engine_lookup_user(ctx->i915, class, instance);
+ if (!engine)
+ return ERR_PTR(-EINVAL);
+
+ return intel_context_instance(ctx, engine);
+}
+
static inline int new_hw_id(struct drm_i915_private *i915, gfp_t gfp)
{
unsigned int max;
@@ -1142,19 +1154,17 @@ gen8_modify_rpcs(struct intel_context *ce, struct
intel_sseu sseu)
}
static int
-__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
- struct intel_sseu sseu)
+__intel_context_reconfigure_sseu(struct intel_context *ce,
+struct intel_sseu sseu)
{
- struct intel_context *ce;
- int ret = 0;
+ int ret;
- GEM_BUG_ON(INTEL_GEN(ctx->i915) < 8);
- GEM_BUG_ON(engine->id != RCS0);
+ GEM_BUG_ON(INTEL_GEN(ce->gem_context->i915) < 8);
+ GEM_BUG_ON(ce->engine->id != RCS0);
- ce = intel_context_pin_lock(ctx, engine);
- if (IS_ERR(ce))
- return PTR_ERR(ce);
+ ret = intel_context_pin_lock(ce);
+ if (ret)
+ return ret;
/* Nothing to do if unmodified. */
if (!memcmp(>sseu, , sizeof(sseu)))
@@ -1170,19 +1180,18 @@ __i915_gem_context_reconfigure_sseu(struct
i915_gem_context *ctx,
}
static int
-i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
- struct intel_sseu sseu)
+intel_context_reconfigure_sseu(struct intel_context *ce, struct intel_sseu
sseu)
{
+ struct drm_i915_private *i915 = ce->gem_context->i915;
int ret;
- ret = mutex_lock_interruptible(>i915->drm.struct_mutex);
+ ret =
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for snd/hda: Only get/put display_power once (rev3)
== Series Details == Series: snd/hda: Only get/put display_power once (rev3) URL : https://patchwork.freedesktop.org/series/59267/ State : warning == Summary == $ dim checkpatch origin/drm-tip 95d66eed4e0b snd/hda: Only get/put display_power once -:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #17: > > > > acquisition/release is racy and a direct call may run concurrently with total: 0 errors, 1 warnings, 0 checks, 38 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for snd/hda: Only get/put display_power once
== Series Details == Series: snd/hda: Only get/put display_power once URL : https://patchwork.freedesktop.org/series/59267/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5897_full -> Patchwork_12749_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12749_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12749_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_12749_full: ### IGT changes ### Possible regressions * igt@kms_plane_lowres@pipe-b-tiling-y: - shard-apl: NOTRUN -> DMESG-WARN Known issues Here are the changes found in Patchwork_12749_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_stolen@stolen-clear: - shard-iclb: NOTRUN -> SKIP [fdo#109277] +1 * igt@gem_workarounds@suspend-resume-context: - shard-apl: NOTRUN -> DMESG-WARN [fdo#108566] +4 * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - shard-iclb: NOTRUN -> SKIP [fdo#109506] * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: - shard-apl: NOTRUN -> FAIL [fdo#109660] * igt@kms_atomic_transition@6x-modeset-transitions: - shard-iclb: NOTRUN -> SKIP [fdo#109278] +1 * igt@kms_atomic_transition@6x-modeset-transitions-nonblocking: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +24 * igt@kms_atomic_transition@plane-all-modeset-transition: - shard-apl: PASS -> INCOMPLETE [fdo#103927] * igt@kms_chamelium@vga-edid-read: - shard-iclb: NOTRUN -> SKIP [fdo#109284] * igt@kms_color@pipe-b-legacy-gamma-reset: - shard-snb: PASS -> SKIP [fdo#109271] * igt@kms_content_protection@atomic: - shard-iclb: NOTRUN -> SKIP [fdo#109300] * igt@kms_content_protection@atomic-dpms: - shard-apl: NOTRUN -> FAIL [fdo#110321] / [fdo#110336] * igt@kms_crtc_background_color: - shard-iclb: NOTRUN -> SKIP [fdo#109305] * igt@kms_cursor_crc@cursor-64x21-random: - shard-glk: NOTRUN -> FAIL [fdo#103232] * igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible: - shard-iclb: NOTRUN -> SKIP [fdo#109274] +2 * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#103167] / [fdo#109960] +1 * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> SKIP [fdo#109271] +172 * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-iclb: PASS -> FAIL [fdo#103167] +5 * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-wc: - shard-iclb: PASS -> FAIL [fdo#109247] +6 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt: - shard-skl: PASS -> FAIL [fdo#105682] / [fdo#108040] * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt: - shard-glk: NOTRUN -> SKIP [fdo#109271] +7 * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-gtt: - shard-iclb: NOTRUN -> SKIP [fdo#109280] +4 * igt@kms_lease@setcrtc_implicit_plane: - shard-apl: NOTRUN -> FAIL [fdo#110281] * igt@kms_panel_fitting@legacy: - shard-skl: NOTRUN -> FAIL [fdo#105456] * igt@kms_pipe_crc_basic@read-crc-pipe-d: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +13 * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping: - shard-glk: PASS -> SKIP [fdo#109271] * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: PASS -> DMESG-WARN [fdo#108566] +3 * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +1 * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: PASS -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-alpha-basic: - shard-apl: NOTRUN -> FAIL [fdo#108145] +7 * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping: - shard-glk: PASS -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_psr@psr2_cursor_render: - shard-iclb: PASS -> SKIP [fdo#109441] +1 * igt@kms_psr@sprite_render: - shard-iclb: PASS -> FAIL
Re: [Intel-gfx] [PATCH 18/29] drm/i915/selftests: Pass around intel_context for sseu
On 08/04/2019 10:17, Chris Wilson wrote:
Combine the (i915_gem_context, intel_engine) into a single parameter,
the intel_context for convenience and later simplification.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 74 +++
1 file changed, 44 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 807644ae6877..8e2a94333559 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -755,8 +755,7 @@ static struct i915_vma *rpcs_query_batch(struct i915_vma
*vma)
static int
emit_rpcs_query(struct drm_i915_gem_object *obj,
- struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
+ struct intel_context *ce,
struct i915_request **rq_out)
{
struct i915_request *rq;
@@ -764,9 +763,9 @@ emit_rpcs_query(struct drm_i915_gem_object *obj,
struct i915_vma *vma;
int err;
- GEM_BUG_ON(!intel_engine_can_store_dword(engine));
+ GEM_BUG_ON(!intel_engine_can_store_dword(ce->engine));
- vma = i915_vma_instance(obj, >ppgtt->vm, NULL);
+ vma = i915_vma_instance(obj, >gem_context->ppgtt->vm, NULL);
if (IS_ERR(vma))
return PTR_ERR(vma);
@@ -784,13 +783,15 @@ emit_rpcs_query(struct drm_i915_gem_object *obj,
goto err_vma;
}
- rq = i915_request_alloc(engine, ctx);
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto err_batch;
}
- err = engine->emit_bb_start(rq, batch->node.start, batch->node.size, 0);
+ err = rq->engine->emit_bb_start(rq,
+ batch->node.start, batch->node.size,
+ 0);
if (err)
goto err_request;
@@ -834,8 +835,7 @@ static int
__sseu_prepare(struct drm_i915_private *i915,
const char *name,
unsigned int flags,
- struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
+ struct intel_context *ce,
struct igt_spinner **spin)
{
struct i915_request *rq;
@@ -853,7 +853,10 @@ __sseu_prepare(struct drm_i915_private *i915,
if (ret)
goto err_free;
- rq = igt_spinner_create_request(*spin, ctx, engine, MI_NOOP);
+ rq = igt_spinner_create_request(*spin,
+ ce->gem_context,
+ ce->engine,
+ MI_NOOP);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
goto err_fini;
@@ -880,8 +883,7 @@ __sseu_prepare(struct drm_i915_private *i915,
static int
__read_slice_count(struct drm_i915_private *i915,
- struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
+ struct intel_context *ce,
struct drm_i915_gem_object *obj,
struct igt_spinner *spin,
u32 *rpcs)
@@ -892,7 +894,7 @@ __read_slice_count(struct drm_i915_private *i915,
u32 *buf, val;
long ret;
- ret = emit_rpcs_query(obj, ctx, engine, );
+ ret = emit_rpcs_query(obj, ce, );
if (ret)
return ret;
@@ -956,29 +958,28 @@ static int
__sseu_finish(struct drm_i915_private *i915,
const char *name,
unsigned int flags,
- struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
+ struct intel_context *ce,
struct drm_i915_gem_object *obj,
unsigned int expected,
struct igt_spinner *spin)
{
- unsigned int slices = hweight32(engine->sseu.slice_mask);
+ unsigned int slices = hweight32(ce->engine->sseu.slice_mask);
u32 rpcs = 0;
int ret = 0;
if (flags & TEST_RESET) {
- ret = i915_reset_engine(engine, "sseu");
+ ret = i915_reset_engine(ce->engine, "sseu");
if (ret)
goto out;
}
- ret = __read_slice_count(i915, ctx, engine, obj,
+ ret = __read_slice_count(i915, ce, obj,
flags & TEST_RESET ? NULL : spin, );
ret = __check_rpcs(name, rpcs, ret, expected, "Context", "!");
if (ret)
goto out;
- ret = __read_slice_count(i915, i915->kernel_context, engine, obj,
+ ret = __read_slice_count(i915, ce->engine->kernel_context, obj,
NULL, );
ret = __check_rpcs(name, rpcs, ret, slices, "Kernel context", "!");
@@ -993,7 +994,7 @@ __sseu_finish(struct drm_i915_private *i915,
if (ret)
return ret;
- ret =
Re: [Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT
On Wed, Apr 10, 2019 at 11:32:47AM +, Chiou, Cooper wrote:
> Hi Ville,
>
>
>
> From BSpec define, HDMI max data rate is “Bits 5-7” not Bits 4-7. And the
> following image is what I captured by latest VBT BMP v2.67 tool to load GLK
> VBT bin file and changed HDMI_MAX_TMDS_Bit_Rate field in 5.94/2.97/1.65Gbps
> different bit-rate.
>
>
>
> A. 5.94Gbps(HDMI_MAX_DATA_RATE_PLATFORM) = 0 is correct, the “HDMI max data
> rate and level shift” value is 0x08 in following highlight block.
>
>
>
> B. 2.97Gbps (HDMI_MAX_DATA_RATE_297) was 1 is wrong, it should be 001x .
> In this case, “HDMI max data rate and level shift value” is “0x28” in
> vbt.bin, so intel_vbt_defs.h HDMI_MAX_DATA_RATE_297=1 is wrong, so it should
> be 2
No. Read the struct definition:
struct child_device_config {
u16 handle;
u16 device_type; /* See DEVICE_TYPE_* above */
union {
u8 device_id[10]; /* ascii string */
struct {
u8 i2c_speed;
u8 dp_onboard_redriver; /* 158 */
u8 dp_ondock_redriver; /* 158 */
u8 hdmi_level_shifter_value:5; /* 169 */
u8 hdmi_max_data_rate:3;/* 204 */
That bitfield matches the spec.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFT i-g-t] tests/prime_vgem/basic-fence-flip: Probe display resolution
On 10/04/2019 12:48, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-10 12:43:22)
@@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem, unsigned hang)
uint32_t offsets[4] = {};
int fd;
- bo[i].width = 1024;
- bo[i].height = 768;
+ bo[i].width = mode->hdisplay;
+ bo[i].height = mode->vdisplay;
bo[i].bpp = 32;
vgem_create(vgem, [i]);
That may not result in a buffer that we are able to flip to. :|
width = ALIGN(hdisplay, 16); vdisplay should be ok.
Oh.. well I don't know. Maarten helpfully described in the BZ that the
skip is due BO being too small for the FB. Aligning width would then
make it too large. Is that OK? Who assigned this display related IGT bug
to me anyway? :))
I would query what happened to the scalers though :)
Are they supposed to automagicaly apply any fb to any output? Or an
explicit step is required? Regardless - it may be better to involve less
of the driver and hardware stack in a simple test.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/29] drm/i915: Export intel_context_instance()
On 08/04/2019 10:17, Chris Wilson wrote:
We want to pass in a intel_context into intel_context_pin() and that
requires us to first be able to lookup the intel_context!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c| 37 +++---
drivers/gpu/drm/i915/gt/intel_context.h| 19 +++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 -
drivers/gpu/drm/i915/gt/mock_engine.c | 8 -
drivers/gpu/drm/i915/gvt/scheduler.c | 7 +++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +--
drivers/gpu/drm/i915/i915_perf.c | 21
drivers/gpu/drm/i915/i915_request.c| 11 ++-
8 files changed, 83 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 6ae6a3f58364..a1267739e369 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -104,7 +104,7 @@ void __intel_context_remove(struct intel_context *ce)
spin_unlock(>hw_contexts_lock);
}
-static struct intel_context *
+struct intel_context *
intel_context_instance(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
@@ -112,7 +112,7 @@ intel_context_instance(struct i915_gem_context *ctx,
ce = intel_context_lookup(ctx, engine);
if (likely(ce))
- return ce;
+ return intel_context_get(ce);
ce = intel_context_alloc();
if (!ce)
@@ -125,7 +125,7 @@ intel_context_instance(struct i915_gem_context *ctx,
intel_context_free(ce);
GEM_BUG_ON(intel_context_lookup(ctx, engine) != pos);
- return pos;
+ return intel_context_get(pos);
}
struct intel_context *
@@ -139,30 +139,30 @@ intel_context_pin_lock(struct i915_gem_context *ctx,
if (IS_ERR(ce))
return ce;
- if (mutex_lock_interruptible(>pin_mutex))
+ if (mutex_lock_interruptible(>pin_mutex)) {
+ intel_context_put(ce);
return ERR_PTR(-EINTR);
+ }
return ce;
}
-struct intel_context *
-intel_context_pin(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine)
+void intel_context_pin_unlock(struct intel_context *ce)
+ __releases(ce->pin_mutex)
{
- struct intel_context *ce;
- int err;
-
- ce = intel_context_instance(ctx, engine);
- if (IS_ERR(ce))
- return ce;
+ mutex_unlock(>pin_mutex);
+ intel_context_put(ce);
+}
- if (likely(atomic_inc_not_zero(>pin_count)))
- return ce;
+int __intel_context_do_pin(struct intel_context *ce)
+{
+ int err;
if (mutex_lock_interruptible(>pin_mutex))
- return ERR_PTR(-EINTR);
+ return -EINTR;
if (likely(!atomic_read(>pin_count))) {
+ struct i915_gem_context *ctx = ce->gem_context;
intel_wakeref_t wakeref;
err = 0;
@@ -172,7 +172,6 @@ intel_context_pin(struct i915_gem_context *ctx,
goto err;
i915_gem_context_get(ctx);
- GEM_BUG_ON(ce->gem_context != ctx);
mutex_lock(>mutex);
list_add(>active_link, >active_engines);
@@ -186,11 +185,11 @@ intel_context_pin(struct i915_gem_context *ctx,
GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
mutex_unlock(>pin_mutex);
- return ce;
+ return 0;
err:
mutex_unlock(>pin_mutex);
- return ERR_PTR(err);
+ return err;
}
void intel_context_unpin(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 9aeef88176b9..da342e9a8c2e 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -49,11 +49,7 @@ intel_context_is_pinned(struct intel_context *ce)
return atomic_read(>pin_count);
}
-static inline void intel_context_pin_unlock(struct intel_context *ce)
-__releases(ce->pin_mutex)
-{
- mutex_unlock(>pin_mutex);
-}
Could leave this as static inline since the only addition is kref_put so
compiler could decide what to do? Don't mind either way.
+void intel_context_pin_unlock(struct intel_context *ce);
struct intel_context *
__intel_context_insert(struct i915_gem_context *ctx,
@@ -63,7 +59,18 @@ void
__intel_context_remove(struct intel_context *ce);
struct intel_context *
-intel_context_pin(struct i915_gem_context *ctx, struct intel_engine_cs
*engine);
+intel_context_instance(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine);
+
+int __intel_context_do_pin(struct intel_context *ce);
+
+static inline int intel_context_pin(struct intel_context *ce)
+{
+ if (likely(atomic_inc_not_zero(>pin_count)))
+ return 0;
+
+ return __intel_context_do_pin(ce);
+}
static inline void
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Rework __kms_addfb() function
Quoting Arkadiusz Hiler (2019-04-10 12:57:03) > On Wed, Apr 10, 2019 at 12:34:07PM +0100, Chris Wilson wrote: > > Quoting Arkadiusz Hiler (2019-04-10 12:28:08) > > > On Wed, Apr 03, 2019 at 07:24:39PM -0300, Rodrigo Siqueira wrote: > > > > The function __kms_addfb() and drmModeAddFB2WithModifiers() have a > > > > similar code. Due to this similarity, this commit replace part of the > > > > code inside __kms_addfb() by using drmModeAddFB2WithModifiers(). > > > > > > igt master % grep '^libdrm_version' meson.build > > > libdrm_version = '>=2.4.82' > > > > Why introduce a dependency? The primary purpose of igt is breaking > > ioctls, and that typically requires avoiding any protective libraries. > > In particular, we want to be very, very clear about what igt is doing > > (in terms of kernel api/abi) and not obfuscate. > > -Chris > > We depend on one additional call from a library that we already use > widely across the whole codebase and it's straight up a simple wrapper. > Which seems to be a pattern - we us those simple wrapper where > available, and write our own if there is nothing suitable. I completely disagree with that assessment, and do not think we should undermine igt so lightly. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Rework __kms_addfb() function
On Wed, Apr 10, 2019 at 12:34:07PM +0100, Chris Wilson wrote: > Quoting Arkadiusz Hiler (2019-04-10 12:28:08) > > On Wed, Apr 03, 2019 at 07:24:39PM -0300, Rodrigo Siqueira wrote: > > > The function __kms_addfb() and drmModeAddFB2WithModifiers() have a > > > similar code. Due to this similarity, this commit replace part of the > > > code inside __kms_addfb() by using drmModeAddFB2WithModifiers(). > > > > igt master % grep '^libdrm_version' meson.build > > libdrm_version = '>=2.4.82' > > Why introduce a dependency? The primary purpose of igt is breaking > ioctls, and that typically requires avoiding any protective libraries. > In particular, we want to be very, very clear about what igt is doing > (in terms of kernel api/abi) and not obfuscate. > -Chris We depend on one additional call from a library that we already use widely across the whole codebase and it's straight up a simple wrapper. Which seems to be a pattern - we us those simple wrapper where available, and write our own if there is nothing suitable. It's ok to have some tests that poke the IOCTL more directly, like we kms_addfb_basic for ADDFB2 (which still uses drmIoctl, so where do we draw a line?). If any of thoe wrappers goes awry we can just drop-in replace it with the original, simple version anyway. -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFT i-g-t] tests/prime_vgem/basic-fence-flip: Probe display resolution
Quoting Tvrtko Ursulin (2019-04-10 12:43:22)
> @@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem, unsigned hang)
> uint32_t offsets[4] = {};
> int fd;
>
> - bo[i].width = 1024;
> - bo[i].height = 768;
> + bo[i].width = mode->hdisplay;
> + bo[i].height = mode->vdisplay;
> bo[i].bpp = 32;
> vgem_create(vgem, [i]);
That may not result in a buffer that we are able to flip to. :|
width = ALIGN(hdisplay, 16); vdisplay should be ok.
I would query what happened to the scalers though :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFT i-g-t] tests/prime_vgem/basic-fence-flip: Probe display resolution
From: Tvrtko Ursulin
Some displays might not support hardcoded 1024x768.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109294
---
tests/prime_vgem.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c
index 60bb951c8cbe..458846add9ee 100644
--- a/tests/prime_vgem.c
+++ b/tests/prime_vgem.c
@@ -744,8 +744,22 @@ static void flip_to_vgem(int i915, int vgem,
static void test_flip(int i915, int vgem, unsigned hang)
{
- struct vgem_bo bo[2];
+ drmModeModeInfo *mode = NULL;
uint32_t fb_id[2], handle[2], crtc_id;
+ igt_display_t display;
+ igt_output_t *output;
+ struct vgem_bo bo[2];
+ enum pipe pipe;
+
+ igt_display_require(, i915);
+ igt_display_require_output();
+
+ for_each_pipe_with_valid_output(, pipe, output) {
+ mode = igt_output_get_mode(output);
+ break;
+ }
+
+ igt_assert(mode);
signal(SIGHUP, sighandler);
@@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem, unsigned hang)
uint32_t offsets[4] = {};
int fd;
- bo[i].width = 1024;
- bo[i].height = 768;
+ bo[i].width = mode->hdisplay;
+ bo[i].height = mode->vdisplay;
bo[i].bpp = 32;
vgem_create(vgem, [i]);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Rework __kms_addfb() function
Quoting Arkadiusz Hiler (2019-04-10 12:28:08) > On Wed, Apr 03, 2019 at 07:24:39PM -0300, Rodrigo Siqueira wrote: > > The function __kms_addfb() and drmModeAddFB2WithModifiers() have a > > similar code. Due to this similarity, this commit replace part of the > > code inside __kms_addfb() by using drmModeAddFB2WithModifiers(). > > igt master % grep '^libdrm_version' meson.build > libdrm_version = '>=2.4.82' Why introduce a dependency? The primary purpose of igt is breaking ioctls, and that typically requires avoiding any protective libraries. In particular, we want to be very, very clear about what igt is doing (in terms of kernel api/abi) and not obfuscate. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC patch 32/41] drm: Simplify stacktrace handling
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
The original code in all printing functions is really wrong. It allocates a
storage array on stack which is unused because depot_fetch_stack() does not
store anything in it. It overwrites the entries pointer in the stack_trace
struct so it points to the depot storage.
Signed-off-by: Thomas Gleixner
Cc: intel-gfx@lists.freedesktop.org
Cc: Joonas Lahtinen
Cc: Maarten Lankhorst
Cc: dri-de...@lists.freedesktop.org
Cc: David Airlie
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rodrigo Vivi
---
drivers/gpu/drm/drm_mm.c| 22 +++---
drivers/gpu/drm/i915/i915_vma.c | 11 ---
drivers/gpu/drm/i915/intel_runtime_pm.c | 21 +++--
3 files changed, 18 insertions(+), 36 deletions(-)
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -106,22 +106,19 @@
static noinline void save_stack(struct drm_mm_node *node)
{
unsigned long entries[STACKDEPTH];
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = STACKDEPTH,
- .skip = 1
- };
+ unsigned int n;
- save_stack_trace();
+ n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
/* May be called under spinlock, so avoid sleeping */
- node->stack = depot_save_stack(, GFP_NOWAIT);
+ node->stack = stack_depot_save(entries, n, GFP_NOWAIT);
}
static void show_leaks(struct drm_mm *mm)
{
struct drm_mm_node *node;
- unsigned long entries[STACKDEPTH];
+ unsigned long *entries;
+ unsigned int nent;
char *buf;
buf = kmalloc(BUFSZ, GFP_KERNEL);
@@ -129,19 +126,14 @@ static void show_leaks(struct drm_mm *mm
return;
list_for_each_entry(node, drm_mm_nodes(mm), node_list) {
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = STACKDEPTH
- };
-
if (!node->stack) {
DRM_ERROR("node [%08llx + %08llx]: unknown owner\n",
node->start, node->size);
continue;
}
- depot_fetch_stack(node->stack, );
- snprint_stack_trace(buf, BUFSZ, , 0);
+ nent = stack_depot_fetch(node->stack, );
+ stack_trace_snprintf(buf, BUFSZ, entries, nent, 0);
DRM_ERROR("node [%08llx + %08llx]: inserted at\n%s",
node->start, node->size, buf);
}
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -36,11 +36,8 @@
static void vma_print_allocator(struct i915_vma *vma, const char *reason)
{
- unsigned long entries[12];
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = ARRAY_SIZE(entries),
- };
+ unsigned long *entries;
+ unsigned int nent;
char buf[512];
if (!vma->node.stack) {
@@ -49,8 +46,8 @@ static void vma_print_allocator(struct i
return;
}
- depot_fetch_stack(vma->node.stack, );
- snprint_stack_trace(buf, sizeof(buf), , 0);
+ nent = stack_depot_fetch(vma->node.stack, );
+ stack_trace_snprint(buf, sizeof(buf), entries, nent, 0);
DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: inserted at %s\n",
vma->node.start, vma->node.size, reason, buf);
}
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -60,27 +60,20 @@
static noinline depot_stack_handle_t __save_depot_stack(void)
{
unsigned long entries[STACKDEPTH];
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = ARRAY_SIZE(entries),
- .skip = 1,
- };
+ unsigned int n;
- save_stack_trace();
- return depot_save_stack(, GFP_NOWAIT | __GFP_NOWARN);
+ n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
+ return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
}
static void __print_depot_stack(depot_stack_handle_t stack,
char *buf, int sz, int indent)
{
- unsigned long entries[STACKDEPTH];
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = ARRAY_SIZE(entries),
- };
+ unsigned long *entries;
+ unsigned int nent;
- depot_fetch_stack(stack, );
- snprint_stack_trace(buf, sz, , indent);
+ nent = stack_depot_fetch(stack, );
+ stack_trace_snprint(buf, sz, entries, nent, indent);
}
static void init_intel_runtime_pm_wakeref(struct drm_i915_private *i915)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
