summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)Author
2020-11-12drm/i915/display: Make get_allowed_dc_mask().max_dc set a chain of if and elsesJosé Roberto de Souza
Just following what we do in many other places, DG1 is a exception so move it to the top instead of add it inside of INTEL_GEN(dev_priv) >= 12. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201111162408.98002-2-jose.souza@intel.com
2020-11-12drm/i915/display: Group DC9 mask setJosé Roberto de Souza
DC9 has a separate HW flow from the rest of the DC states and it is available in GEN9 LP platforms and on GEN11 and newer, so here moving the assignment of the mask to a single conditional block to simplifly code. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201111162408.98002-1-jose.souza@intel.com
2020-11-11drm/i915/display: return earlier from intel_modeset_init() without displayJani Nikula
!HAS_DISPLAY() implies !HAS_OVERLAY(), skipping overlay setup anyway, so return earlier from intel_modeset_init() for clarity. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-4-lucas.demarchi@intel.com
2020-11-11drm/i915/display: Do not reset display when there is noneJosé Roberto de Souza
Display is always disabled and enabled when resetting any engine, but if there is no display it should not do anything with display and only reset the needed engines. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-3-lucas.demarchi@intel.com
2020-11-11drm/i915/display: add namespace to intel_finish_resetLucas De Marchi
Rename intel_finish_reset to intel_display_finish_reset, so it's clear from gt/ that we are calling out the display code. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-2-lucas.demarchi@intel.com
2020-11-11drm/i915/display: add namespace to intel_prepare_resetLucas De Marchi
Rename intel_prepare_reset to intel_display_prepare_reset, so it's clear from gt/ that we are calling out the display code. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-1-lucas.demarchi@intel.com
2020-11-10drm/i915: Add plane .{min,max}_width() and .max_height() vfuncsVille Syrjälä
Reduce this maintenance nightmare a bit by converting the plane min/max width/height stuff into vfuncs. Now, if I could just think of a nice way to also use this for intel_mode_valid_max_plane_size()... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924185113.30849-1-ville.syrjala@linux.intel.com Reviewed-by: Aditya Swarup <aditya.swarup@intel.com>
2020-11-09drm/i915/edp/jsl: Update vswing table for HBR and HBR2Tejas Upadhyay
JSL has update in vswing table for eDP. BSpec: 21257 Changes since V1: - Fixed few checkpatch errors Cc: Souza Jose <jose.souza@intel.com> Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020053657.99890-1-tejaskumarx.surendrakumar.upadhyay@intel.com
2020-11-09drm/i915/dg1: map/unmap pll clocksLucas De Marchi
DG1 uses 2 registers for the ddi clock mapping, with PHY A and B using DPCLKA_CFGCR0 and PHY C and D using DPCLKA1_CFGCR0. Hide this behind a single macro that chooses the correct register according to the phy being accessed, use the correct bitfields for each pll/phy and implement separate functions for DG1 since it doesn't share much with ICL/TGL anymore. The previous values were correct for PHY A and B since they were using the same register as before and the bitfields were matching. v2: Add comment and try to simplify DG1_DPCLKA* macros by reusing previous ones v3: - Fix DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK() after wrong macro reuse - Move phy -> id map to a separate macro (Aditya) - Remove DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK where not required (Aditya) - Use drm_WARN_ON Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Aditya Swarup <aditya.swarup@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106210006.837953-1-lucas.demarchi@intel.com
2020-11-06drm/i915: Include fb modifier in state dumpsVille Syrjälä
To help diagnose modifier related issues let's include that information in the various state dumps. Cc: Simon Ser <contact@emersion.fr> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201103153026.16566-1-ville.syrjala@linux.intel.com Acked-by: Simon Ser <contact@emersion.fr>
2020-11-05drm/i915/ehl: Implement W/A 22010492432Tejas Upadhyay
As per W/A implemented for TGL to program half of the nominal DCO divider fraction value which is also applicable on EHL. Changes since V2: - Apply stepping B0 till FOREVER - B0 - revid update as per Bspec 29153 Changes since V1: - ehl_ used as to keep earliest platform prefix - WA required B0 stepping onwards Cc: Deak Imre <imre.deak@intel.com> Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201104050655.171185-1-tejaskumarx.surendrakumar.upadhyay@intel.com
2020-11-05drm/i915/display: Use initial_fastset_check() to compute and apply the ↵José Roberto de Souza
initial PSR state Replace the previous approach to force compute the initial PSR state after i915 take over from firmware by the better and recently added initial_fastset_check() hook. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201102221048.104294-1-jose.souza@intel.com
2020-11-05Merge drm/drm-next into drm-intel-next-queuedJani Nikula
Catch up with v5.10-rc2 and drm-misc-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2020-11-04drm/i915/tgl: Fix typo during output setupImre Deak
Fix a typo that led to some MST short pulse event handling issue (the short pulse event was handled for both encoder instances, each having its own state). Fixes: 1d8ca002456b6 ("drm/i915: Add PORT_TCn aliases to enum port") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201104010000.4165574-1-imre.deak@intel.com
2020-11-04Merge tag 'drm-intel-next-queued-2020-11-03' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 features for v5.11 Highlights: - More DG1 enabling (Lucas, Matt, Aditya, Anshuman, Clinton, Matt, Stuart, Venkata) - Integer scaling filter support (Pankaj Bharadiya) - Asynchronous flip support (Karthik) Generic: - Fix gen12 forcewake tables (Matt) - Haswell PCI ID updates (Alexei Podtelezhnikov) Display: - ICL+ DSI command mode enabling (Vandita) - Shutdown displays grafecully on reboot/shutdown (Ville) - Don't register display debugfs when there is no display (Lucas) - Fix RKL CDCLK table (Matt) - Limit EHL/JSL eDP to HBR2 (José) - Handle incorrectly set (by BIOS) PLLs and DP link rates at probe (Imre) - Fix mode valid check wrt bpp for "YCbCr 4:2:0 only" modes (Ville) - State checker and dump fixes (Ville) - DP AUX backlight updates (Aaron Ma, Sean Paul) - Add DP LTTPR non-transparent link training mode (Imre) - PSR2 selective fetch enabling (José) - VBT updates (José) - HDCP updates (Ramalingam) Cleanups and refactoring: - HPD pin, AUX channel, and Type-C port identifier cleanup (Ville) - Hotplug and irq refactoring (Ville) - Better DDI encoder and AUX channel names (Ville) - Color LUT code cleanups (Ville) - Combo PHY code cleanups (Ville) - LSPCON code cleanups (Ville) - Documentation fixes (Mauro, Chris) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87o8kehbaj.fsf@intel.com
2020-11-03drm/i915: Fix encoder lookup during PSR atomic checkImre Deak
The atomic check hooks must look up the encoder to be used with a connector from the connector's atomic state, and not assume that it's the connector's current attached encoder. The latter one can change under the atomic check func, or can be unset yet as in the case of MST connectors. This fixes [ 7.940719] Oops: 0000 [#1] SMP NOPTI [ 7.944407] CPU: 2 PID: 143 Comm: kworker/2:2 Not tainted 5.6.0-1023-oem #23-Ubuntu [ 7.952102] Hardware name: Dell Inc. Latitude 7320/, BIOS 88.87.11 09/07/2020 [ 7.959278] Workqueue: events output_poll_execute [drm_kms_helper] [ 7.965511] RIP: 0010:intel_psr_atomic_check+0x37/0xa0 [i915] [ 7.971327] Code: 80 2d 06 00 00 20 74 42 80 b8 34 71 00 00 00 74 39 48 8b 72 08 48 85 f6 74 30 80 b8 f8 71 00 00 00 74 27 4c 8b 87 80 04 00 00 <41> 8b 78 78 83 ff 08 77 19 31 c9 83 ff 05 77 19 48 81 c1 20 01 00 [ 7.977541] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input5 [ 7.990154] RSP: 0018:ffffb864c073fac8 EFLAGS: 00010202 [ 7.990155] RAX: ffff8c5d55ce0000 RBX: ffff8c5d54519000 RCX: 0000000000000000 [ 7.990155] RDX: ffff8c5d55cb30c0 RSI: ffff8c5d89a0c800 RDI: ffff8c5d55fcf800 [ 7.990156] RBP: ffffb864c073fac8 R08: 0000000000000000 R09: ffff8c5d55d9f3a0 [ 7.990156] R10: ffff8c5d55cb30c0 R11: 0000000000000009 R12: ffff8c5d55fcf800 [ 7.990156] R13: ffff8c5d55cb30c0 R14: ffff8c5d56989cc0 R15: ffff8c5d56989cc0 [ 7.990158] FS: 0000000000000000(0000) GS:ffff8c5d8e480000(0000) knlGS:0000000000000000 [ 8.047193] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.052970] CR2: 0000000000000078 CR3: 0000000856500005 CR4: 0000000000760ee0 [ 8.060137] PKRU: 55555554 [ 8.062867] Call Trace: [ 8.065361] intel_digital_connector_atomic_check+0x53/0x130 [i915] [ 8.071703] intel_dp_mst_atomic_check+0x5b/0x200 [i915] [ 8.077074] drm_atomic_helper_check_modeset+0x1db/0x790 [drm_kms_helper] [ 8.083942] intel_atomic_check+0x92/0xc50 [i915] [ 8.088705] ? drm_plane_check_pixel_format+0x4f/0xb0 [drm] [ 8.094345] ? drm_atomic_plane_check+0x7a/0x3a0 [drm] [ 8.099548] drm_atomic_check_only+0x2b1/0x450 [drm] [ 8.104573] drm_atomic_commit+0x18/0x50 [drm] [ 8.109070] drm_client_modeset_commit_atomic+0x1c9/0x200 [drm] [ 8.115056] drm_client_modeset_commit_force+0x55/0x160 [drm] [ 8.120866] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper] [ 8.128415] drm_fb_helper_set_par+0x34/0x50 [drm_kms_helper] [ 8.134225] drm_fb_helper_hotplug_event.part.0+0xb4/0xe0 [drm_kms_helper] [ 8.141150] drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper] [ 8.147481] intel_fbdev_output_poll_changed+0x6f/0xa0 [i915] [ 8.153287] drm_kms_helper_hotplug_event+0x2c/0x40 [drm_kms_helper] [ 8.159709] output_poll_execute+0x1aa/0x1c0 [drm_kms_helper] [ 8.165506] process_one_work+0x1e8/0x3b0 [ 8.169561] worker_thread+0x4d/0x400 [ 8.173249] kthread+0x104/0x140 [ 8.176515] ? process_one_work+0x3b0/0x3b0 [ 8.180726] ? kthread_park+0x90/0x90 [ 8.184416] ret_from_fork+0x1f/0x40 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2361 References: https://gitlab.freedesktop.org/drm/intel/-/issues/2486 Reported-by: William Tseng <william.tseng@intel.com> Reported-by: Cooper Chiou <cooper.chiou@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201027160928.3665377-1-imre.deak@intel.com (cherry picked from commit 00e5deb5c4f5fe367311465e720e65cfa1178792) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-10-30drm/i915: Reduce severity for fixing up mistaken VBT tc->legacy_portChris Wilson
If the VBT assigned tc->legacy_port mismatches the live_status indicator for the connector, we ignore the VBT directive and switch over to the HW setting. This is not a driver error, unless we happen to misparse the VBT or the live_status registers. However, for the system in CI where the error is only reported on 1 port out of 4, the evidence indicates the VBT is wrong. Stop flaging this as an error since the cause is beyond our control, fixup the mistake and continue on. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201030153209.14808-1-chris@chris-wilson.co.uk
2020-10-30drm/i915: Use AUX_CH_USBCn for the RKL VBT AUX CH setupVille Syrjälä
As with the VBT DVO port, RKL uses PHY based mapping for the VBT AUX CH. Adjust the code to use the new AUX_USBCn names and add a comment to explain the situation. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-7-ville.syrjala@linux.intel.com
2020-10-30drm/i915: Pimp AUX CH namesVille Syrjälä
Let's make the AUX CH names match the spec (AUX A-F for pre-tgl, AUX A-C or AUX USBC1-6 for tgl+). And while at it let's include the full encoder name in the AUX CH name as well (as opposed to just using port_name() which wouldn't give us the right thing on tgl+). Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-6-ville.syrjala@linux.intel.com
2020-10-30drm/i915: Introduce AUX_CH_USBCnVille Syrjälä
Just like with the DDIs tgl+ renamed the AUX CHs to reflect the type of the DDI. Let's add the aliasing enum values for the type-C AUX CHs. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-5-ville.syrjala@linux.intel.com
2020-10-30drm/i915: Give DDI encoders even better namesVille Syrjälä
Let's pimp the DDI encoder->name to reflect what the spec calls them. Ie. on pre-tgl DDI A-F, on tgl+ DDI A-C or DDI TC1-6. Also since each encoder is really a combination of the DDI and the PHY we include the PHY name as well. ICL is a bit special since it already has the two different types of DDIs (combo or TC) but it still calls them just DDI A-F regarless of the type. For that let's add an extra "(TC)" note to remind is which type of DDI it really is. The code is darn ugly, but not sure there's much we can do about it. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-4-ville.syrjala@linux.intel.com
2020-10-30drm/i915: Add PORT_TCn aliases to enum portVille Syrjälä
Since tgl the DDIs have been named A,B,C,TC1,TC2,TC3... Add the appropriate enum values for the TC DDIs to enum port. v2: Deal with rkl and dg1 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-3-ville.syrjala@linux.intel.com
2020-10-30drm/i915: s/PORT_TC/TC_PORT_/Ville Syrjälä
Make the namespacing for enum tc_port better by adding the TC_ to the actual enum values. v2: Drop the extra TC (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-2-ville.syrjala@linux.intel.com
2020-10-29drm/i915: Reject 90/270 degree rotated initial fbsVille Syrjälä
We don't currently handle the initial fb readout correctly for 90/270 degree rotated scanout. Reject it. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020194330.28568-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit a40a8305a732f4ecc2186ac7ca132ba062ed770d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-10-28drm/i915: Fix encoder lookup during PSR atomic checkImre Deak
The atomic check hooks must look up the encoder to be used with a connector from the connector's atomic state, and not assume that it's the connector's current attached encoder. The latter one can change under the atomic check func, or can be unset yet as in the case of MST connectors. This fixes [ 7.940719] Oops: 0000 [#1] SMP NOPTI [ 7.944407] CPU: 2 PID: 143 Comm: kworker/2:2 Not tainted 5.6.0-1023-oem #23-Ubuntu [ 7.952102] Hardware name: Dell Inc. Latitude 7320/, BIOS 88.87.11 09/07/2020 [ 7.959278] Workqueue: events output_poll_execute [drm_kms_helper] [ 7.965511] RIP: 0010:intel_psr_atomic_check+0x37/0xa0 [i915] [ 7.971327] Code: 80 2d 06 00 00 20 74 42 80 b8 34 71 00 00 00 74 39 48 8b 72 08 48 85 f6 74 30 80 b8 f8 71 00 00 00 74 27 4c 8b 87 80 04 00 00 <41> 8b 78 78 83 ff 08 77 19 31 c9 83 ff 05 77 19 48 81 c1 20 01 00 [ 7.977541] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input5 [ 7.990154] RSP: 0018:ffffb864c073fac8 EFLAGS: 00010202 [ 7.990155] RAX: ffff8c5d55ce0000 RBX: ffff8c5d54519000 RCX: 0000000000000000 [ 7.990155] RDX: ffff8c5d55cb30c0 RSI: ffff8c5d89a0c800 RDI: ffff8c5d55fcf800 [ 7.990156] RBP: ffffb864c073fac8 R08: 0000000000000000 R09: ffff8c5d55d9f3a0 [ 7.990156] R10: ffff8c5d55cb30c0 R11: 0000000000000009 R12: ffff8c5d55fcf800 [ 7.990156] R13: ffff8c5d55cb30c0 R14: ffff8c5d56989cc0 R15: ffff8c5d56989cc0 [ 7.990158] FS: 0000000000000000(0000) GS:ffff8c5d8e480000(0000) knlGS:0000000000000000 [ 8.047193] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.052970] CR2: 0000000000000078 CR3: 0000000856500005 CR4: 0000000000760ee0 [ 8.060137] PKRU: 55555554 [ 8.062867] Call Trace: [ 8.065361] intel_digital_connector_atomic_check+0x53/0x130 [i915] [ 8.071703] intel_dp_mst_atomic_check+0x5b/0x200 [i915] [ 8.077074] drm_atomic_helper_check_modeset+0x1db/0x790 [drm_kms_helper] [ 8.083942] intel_atomic_check+0x92/0xc50 [i915] [ 8.088705] ? drm_plane_check_pixel_format+0x4f/0xb0 [drm] [ 8.094345] ? drm_atomic_plane_check+0x7a/0x3a0 [drm] [ 8.099548] drm_atomic_check_only+0x2b1/0x450 [drm] [ 8.104573] drm_atomic_commit+0x18/0x50 [drm] [ 8.109070] drm_client_modeset_commit_atomic+0x1c9/0x200 [drm] [ 8.115056] drm_client_modeset_commit_force+0x55/0x160 [drm] [ 8.120866] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper] [ 8.128415] drm_fb_helper_set_par+0x34/0x50 [drm_kms_helper] [ 8.134225] drm_fb_helper_hotplug_event.part.0+0xb4/0xe0 [drm_kms_helper] [ 8.141150] drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper] [ 8.147481] intel_fbdev_output_poll_changed+0x6f/0xa0 [i915] [ 8.153287] drm_kms_helper_hotplug_event+0x2c/0x40 [drm_kms_helper] [ 8.159709] output_poll_execute+0x1aa/0x1c0 [drm_kms_helper] [ 8.165506] process_one_work+0x1e8/0x3b0 [ 8.169561] worker_thread+0x4d/0x400 [ 8.173249] kthread+0x104/0x140 [ 8.176515] ? process_one_work+0x3b0/0x3b0 [ 8.180726] ? kthread_park+0x90/0x90 [ 8.184416] ret_from_fork+0x1f/0x40 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2361 References: https://gitlab.freedesktop.org/drm/intel/-/issues/2486 Reported-by: William Tseng <william.tseng@intel.com> Reported-by: Cooper Chiou <cooper.chiou@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201027160928.3665377-1-imre.deak@intel.com
2020-10-28drm/i915/display: remove debug message from error pathLucas De Marchi
First check in the function is if swsci() is supported. All the error paths are easy to figure out the reason, so remove the extra debug message: it's normal not to support swsci() e.g. in dgfx. v2: Rather than special case dgfx, just remove the debug message (from Ville) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201027044618.719064-2-lucas.demarchi@intel.com
2020-10-23drm/i915/dg1: add hpd interrupt handlingLucas De Marchi
DG1 has one more combo phy port, no TC and all irq handling goes through SDE, like for MCC. v2: Also change intel_hpd_pin_default() to include DG1 mapping v3, v4: Rebase on hpd refactor Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021082034.3170478-2-lucas.demarchi@intel.com
2020-10-23drm/i915/tgl/psr: Fix glitches when doing frontbuffer modificationsJosé Roberto de Souza
Writes to CURSURFLIVE in TGL are causing IOMMU errors and visual glitches that are often reproduced when executing CPU intensive workloads while a eDP 4K panel is attached. Manually exiting PSR causes the frontbuffer to be updated without glitches and the IOMMU errors are also gone but this comes at the cost of less time with PSR active. So using this workaround until this issue is root caused and a better fix is found. The current code is already ready to enable PSR after this exit if there is not other frontbuffer modifications. Adding a new if block in psr_force_hw_tracking_exit() instead of reuse the else/gen8- block because the plan is to revert this workaround as soon as a better solution is found. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201002231627.24528-1-jose.souza@intel.com
2020-10-23Merge tag 'drm-intel-next-fixes-2020-10-22' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Tweak initia DPCD backlight.enabled value (Sean) - Initialize reserved MOCS indices (Ayaz) - Mark initial fb obj as WT on eLLC machines to avoid rcu lockup (Ville) - Support parsing of oversize batches (Chris) - Delay execlists processing for TGL (Chris) - Use the active reference on the vma during error capture (Chris) - Widen CSB pointer (Chris) - Wait for CSB entries on TGL (Chris) - Fix unwind for scratch page allocation (Chris) - Exclude low patches of stolen memory (Chris) - Force VT'd workarounds when running as a guest OS (Chris) - Drop runtime-pm assert from vpgu io accessors (Chris) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201022205613.GA3469192@intel.com
2020-10-21drm/i915/display: Unkerneldoc cnl_program_nearest_filter_coefsChris Wilson
The block comment for cnl_program_nearest_filter_coefs() has a wonderful diagram, but although it is marked up as kerneldoc does not use the markup for providing the function definition. drivers/gpu/drm/i915/display/intel_display.c:6341: warning: Function parameter or member 'dev_priv' not described in 'cnl_program_nearest_filter_coefs' drivers/gpu/drm/i915/display/intel_display.c:6341: warning: Function parameter or member 'pipe' not described in 'cnl_program_nearest_filter_coefs' drivers/gpu/drm/i915/display/intel_display.c:6341: warning: Function parameter or member 'id' not described in 'cnl_program_nearest_filter_coefs' drivers/gpu/drm/i915/display/intel_display.c:6341: warning: Function parameter or member 'set' not described in 'cnl_program_nearest_filter_coefs' Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021185649.17759-1-chris@chris-wilson.co.uk
2020-10-21drm/i915: Reject 90/270 degree rotated initial fbsVille Syrjälä
We don't currently handle the initial fb readout correctly for 90/270 degree rotated scanout. Reject it. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020194330.28568-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-10-21drm/i915: Enable scaling filter for plane and CRTCPankaj Bharadiya
GEN >= 10 hardware supports the programmable scaler filter. Attach scaling filter property for CRTC and plane for GEN >= 10 hardwares and program scaler filter based on the selected filter type. changes since v3: * None changes since v2: * Use updated functions * Add ps_ctrl var to contain the full PS_CTRL register value (Ville) * Duplicate the scaling filter in crtc and plane hw state (Ville) changes since v1: * None Changes since RFC: * Enable properties for GEN >= 10 platforms (Ville) * Do not round off the crtc co-ordinate (Danial Stone, Ville) * Add new functions to handle scaling filter setup (Ville) * Remove coefficient set 0 hardcoding. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-5-pankaj.laxminarayan.bharadiya@intel.com
2020-10-21drm/i915/display: Add Nearest-neighbor based integer scaling supportPankaj Bharadiya
Integer scaling (IS) is a nearest-neighbor upscaling technique that simply scales up the existing pixels by an integer (i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Both IS and NN preserve the clarity of the original image. Integer scaling is particularly useful for pixel art games that rely on sharp, blocky images to deliver their distinctive look. Introduce functions to configure the scaler filter coefficients to enable nearest-neighbor filtering. Bspec: 49247 changes since v6: * Trust compiler, remove pointless inline keyword from cnl_coef_tap() & cnl_nearest_filter_coef() functions (Ville) changes since v4: * Make cnl_coef_tap(), cnl_nearest_filter_coef() inline (Uma) changes since v3: * None changes since v2: * Move APIs from 5/5 into this patch. * Change filter programming related function names to cnl_*, move filter select bits related code into inline function (Ville) changes since v1: * Rearrange skl_scaler_setup_nearest_neighbor_filter() to iterate the registers directly instead of the phases and taps (Ville) changes since RFC: * Refine the skl_scaler_setup_nearest_neighbor_filter() logic (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-4-pankaj.laxminarayan.bharadiya@intel.com
2020-10-20drm/i915/display: Rename pipe_timings to transcoder_timingsManasi Navare
No functional changes in this patch. With Bigjoiner, there are 2 pipes driving 2 halfs of 1 transcoder. The transcoder_mode has the full timings, and is used for configuring the transcoder with the intended mode after joining the 2 halves. To clear the confusion, we rename intel_set_pipe_timings to intel_set_transcoder_timings v2: * Split the renaming into separate patch (Ville) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201008214535.22942-2-manasi.d.navare@intel.com
2020-10-20drm/i915: Refactor .hpd_irq_setup() calls a bitVille Syrjälä
Add a small wrapper for .hpd_irq_setup() which does the "do we even have the hook?" and "are display interrupts enabled?" checks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201006185809.4655-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-10-20drm/i915: Reorder hpd init vs. display resumeVille Syrjälä
Currently we call .hpd_irq_setup() directly just before display resume, and follow it with another call via intel_hpd_init() just afterwards. Assuming the hpd pins are marked as enabled during the open-coded call these two things do exactly the same thing (ie. enable HPD interrupts). Which even makes sense since we definitely need working HPD interrupts for MST sideband during the display resume. So let's nuke the open-coded call and move the intel_hpd_init() call earlier. However we need to leave the poll_init_work stuff behind after the display resume as that will trigger display detection while we're resuming. We don't want that trampling over the display resume process. To make this a bit more symmetric we turn this into a intel_hpd_poll_{enable,disable}() pair. So we end up with the following transformation: intel_hpd_poll_init() -> intel_hpd_poll_enable() lone intel_hpd_init() -> intel_hpd_init()+intel_hpd_poll_disable() .hpd_irq_setup()+resume+intel_hpd_init() -> intel_hpd_init()+resume+intel_hpd_poll_disable() If we really would like to prevent all *long* HPD processing during display resume we'd need some kind of software mechanism to simply ignore all long HPDs. Currently we appear to have that just for fbdev via ifbdev->hpd_suspended. Since we aren't exploding left and right all the time I guess that's mostly sufficient. For a bit of history on this, we first got a mechanism to block hotplug processing during suspend in commit 15239099d7a7 ("drm/i915: enable irqs earlier when resuming") on account of moving the irq enable earlier. This then got removed in commit 50c3dc970a09 ("drm/fb-helper: Fix hpd vs. initial config races") because the fdev initial config got pushed to a later point. The second ad-hoc hpd_irq_setup() for resume was added in commit 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)") to be able to do MST sideband during the resume. And finally we got a partial resurrection of the hpd blocking mechanism in commit e8a8fedd57fd ("drm/i915: Block fbdev HPD processing during suspend"), but this time it only prevent fbdev from handling hpd while resuming. v2: Leave the poll_init_work behind v3: Remove the extra intel_hpd_poll_disable() from display reset (Lyude) Add the missing intel_hpd_poll_disable() to display init (Imre) Cc: Lyude Paul <lyude@redhat.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201013181137.30560-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-10-20drm/i915: s/intel_dp_sink_dpms/intel_dp_set_power/Ville Syrjälä
Rename intel_dp_sink_dpms() to intel_dp_set_power() so one doesn't always have to convert from the DPMS enum values to the actual DP D-states. Also when dealing with a branch device this has nothing to do with any sink, so the old name was nonsense anyway. Also adjust the debug message accordingly, and pimp it with the standard encoder id+name thing. Trivial bits done with cocci: @@ expression DP; @@ ( - intel_dp_sink_dpms(DP, DRM_MODE_DPMS_OFF) + intel_dp_set_power(DP, DP_SET_POWER_D3) | - intel_dp_sink_dpms(DP, DRM_MODE_DPMS_ON) + intel_dp_set_power(DP, DP_SET_POWER_D0) ) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201016194800.25581-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-10-20drm/i915: Move the lspcon resume from .reset() to intel_dp_sink_dpms()Ville Syrjälä
Rather that try to trick LSPCON back into PCON mode from the .reset() hook let's just do that as a regular part of the normal modeset sequence, which is going to take care of the system resume case. During a normal modeset this should normally be a nop as the mode should have already been switched by .detect(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201016194800.25581-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-10-19drm/i915/display/fbc: Implement WA 22010751166José Roberto de Souza
Underruns happens when plane height + y offset is not a modulo of 4 when FBC is enabled. It happens when scanline is at vactive - 10 but that is not feasible to do from the software side so here completely disabling FBC when height + y offset matches to avoid visual glitches. Specification says that it only affects TGL display C stepping and newer but to simply the check and as TGL is already in final costumers hands, pre-production display stepping A and B was also included. BSpec: 52887 ICL BSpec: 52888 EHL/JSL BSpec: 52890/55378 TGL BSpec: 53508 DG1 BSpec: 53273 RKL Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201019175609.28715-1-jose.souza@intel.com
2020-10-19drm/i915/display: Program DBUF_CTL tracker state serviceJosé Roberto de Souza
This sequence is not part of "Sequences to Initialize Display" but as noted in the MBus page the DBUF_CTL.Tracker_state_service needs to be set to 8. BSpec: 49213 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201019173906.18892-1-jose.souza@intel.com
2020-10-19drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup ↵Ville Syrjälä
during fbdev init Currently we leave the cache_level of the initial fb obj set to NONE. This means on eLLC machines the first pin_to_display() will try to switch it to WT which requires a vma unbind+bind. If that happens during the fbdev initialization rcu does not seem operational which causes the unbind to get stuck. To most appearances this looks like a dead machine on boot. Avoid the unbind by already marking the object cache_level as WT when creating it. We still do an excplicit ggtt pin which will rewrite the PTEs anyway, so they will match whatever cache level we set. Cc: <stable@vger.kernel.org> # v5.7+ Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201007120329.17076-1-ville.syrjala@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20201015122138.30161-1-chris@chris-wilson.co.uk (cherry picked from commit d46b60a2e8d246f1f0faa38e52f4f5a73858c338) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-10-19drm/i915/dp: Tweak initial dpcd backlight.enabled valueSean Paul
In commit 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD control mode"), we fixed the brightness level when DPCD control was not active to max brightness. This is as good as we can guess since most backlights go on full when uncontrolled. However in doing so we changed the semantics of the initial 'backlight.enabled' value. At least on Pixelbooks, they were relying on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on boot such that enabled would be false. This causes the device to be enabled when the brightness is set. Without this, brightness control doesn't work. So by changing brightness to max, we also flipped enabled to be true on boot. To fix this, make enabled a function of brightness and backlight control mechanism. Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD control mode") Cc: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Kevin Chowski <chowski@chromium.org>> Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200918002845.32766-1-sean@poorly.run (cherry picked from commit 4ade8f31c25bef7ce7ed4d7cbac17df7c4bad850) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-10-19Merge tag 'drm-intel-next-fixes-2020-10-15' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Set all unused color plane offsets to ~0xfff again (Ville) - Fix TGL DKL PHY DP vswing handling (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201015181453.GA2905280@intel.com
2020-10-16drm/i915: Inline intel_dp_ycbcr420_config()Ville Syrjälä
intel_dp_ycbcr420_config() is rather pointless. Just inline it directly into intel_dp_compute_config(). This gets rid of the ugly double assignment of output_format. Not really sure what the best policy would be when the user supplies a mode classified by the display as "YCbCr 4:2:0 only", but we know that we can't do YCbCr 4:2:0 output. For now keep the current behaviour of just silently upgrade it to RGB 4:4:4. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924184156.24491-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2020-10-16drm/i915: Nuke lspcon_ycbcr420_config()Ville Syrjälä
Remove the lspcon special case from intel_dp_compute_config() and just treat it like any other DFP than can do 4:4:4->4:2:0 conversion. The only difference between the two codepaths was that the lspcon code tried to already halve port_clock. That was just total nonsense as we hadn't even computed the base port_clock at that time. All that stuff happens intel_dp_compute_link_config*() and it already takes care of the 4:2:0 clock reduction. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924184156.24491-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2020-10-16drm/i915: Nuke lspcon_downsamplingVille Syrjälä
crtc_state->lspcon_downsampling isn't particularly useful at the moment since we can't even do proper readout for it. Let's get rid of it. Will help with unifying the LSPCON with the regular DFP YCbCr output support. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924184156.24491-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2020-10-16drm/i915: Mark initial fb obj as WT on eLLC machines to avoid rcu lockup ↵Ville Syrjälä
during fbdev init Currently we leave the cache_level of the initial fb obj set to NONE. This means on eLLC machines the first pin_to_display() will try to switch it to WT which requires a vma unbind+bind. If that happens during the fbdev initialization rcu does not seem operational which causes the unbind to get stuck. To most appearances this looks like a dead machine on boot. Avoid the unbind by already marking the object cache_level as WT when creating it. We still do an excplicit ggtt pin which will rewrite the PTEs anyway, so they will match whatever cache level we set. Cc: <stable@vger.kernel.org> # v5.7+ Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007120329.17076-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-10-16drm/i915/rkl: Add new cdclk tableMatt Roper
A recent bspec update has provided a new cdclk table for RKL. All of the cdclk values are the same as those we've been using on ICL, TGL, etc., but we obtain them by doubling both the PLL ratio and CD2X divider numbers. Bspec: 49202 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201015220038.271740-1-matthew.d.roper@intel.com
2020-10-15drm/i915/dg1: Update DMC_DEBUG registerAnshuman Gupta
Update the DMC_DEBUG_DC5 register to its new location and do not try reading the DC6 counter since DG1 doesn't support DC6. v2: Use IS_DGFX() instead of IS_DG1(). Even if not having DC6 is not directly related to DGFX, the register move to a new location is. So in future, if there is one supporting DC6, it would just need to add the other register rather than fixing the case of a wrong register being read (Matt) Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-10-lucas.demarchi@intel.com
2020-10-15drm/i915/dg1: DG1 does not support DC6Anshuman Gupta
DC6 is not supported on DG1, so change the allowed DC mask for DG1. This is not yet on bspec, but it has been confirmed by HW engineers. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201014191937.1266226-9-lucas.demarchi@intel.com
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-07-27 01:42:41 +0000