summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-10-30drm/i915: Rename 'tmp_mask'Ville Syrjälä
Replace this silly tmp_mask with hotplug_trigger/te_trigger where appropriate. 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-16-ville.syrjala@linux.intel.com
2020-10-30drm/i915: Don't enable hpd detection logic from irq_postinstall()Ville Syrjälä
No reason that I can see why we should enable the hpd detection logic already during irq postinstall phase. We don't even do this on all the platforms. We just need it before we actually enable the hotplug interrupts in .hpd_irq_setup(), and in fact we already do it there as well. Let's just eliminate the redundant early setup. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-15-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2020-10-30drm/i915: Split gen11_hpd_detection_setup() into tc vs. tbt variantsVille Syrjälä
No reason to stuff both type-c and tbt into the same function. Let's split this so we may more easily handle platforms that lack the tbt spefific bits. 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-14-ville.syrjala@linux.intel.com
2020-10-30drm/i915: Relocate intel_hpd_{enabled,hotplug}_irqs()Ville Syrjälä
Move intel_hpd_{enabled,hotplug}_irqs() closes to the beginning of the file so we can use them in more places. No functional changes. 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-13-ville.syrjala@linux.intel.com
2020-10-30drm/i915: s/tc_port/hpd_pin/ in icp+ TC hotplug bitsVille Syrjälä
Parametrize the icp+ TC HPD bits using hpd_pin rather than tc_port so it's clear what kind of an animal we're dealing with. 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-12-ville.syrjala@linux.intel.com
2020-10-30drm/i915: s/tc_port/hpd_pin/ in GEN11_{TC,TBT}_HOTPLUG()Ville Syrjälä
Use hpd_pin instead of tc_port in the GEN11_{TC,TBT}_HOTPLUG() to make it clear what they refer to. 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-11-ville.syrjala@linux.intel.com
2020-10-30drm/i915: s/port/hpd_pin/ for icp+ ddi hpd bitsVille Syrjälä
Use hpd_pin instead of port in the parametrized ICP+ DDI HPD macros. Makes it clear what these refer to. v2: Handle 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-10-ville.syrjala@linux.intel.com
2020-10-30drm/i915: Introduce GEN8_DE_PORT_HOTPLUG()Ville Syrjälä
Unify the BDW/BXT hotplug bits. BDW only has port A, but that matches BXT port A so we can shar the same macro for both. v2: Remember the gvt 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-9-ville.syrjala@linux.intel.com
2020-10-30drm/i915: Parametrize BXT_DE_PORT_HP_DDI with hpd_pinVille Syrjälä
Use hpd_pin to parametrize BXT_DE_PORT_HP_DDI() to make it clear these have nothing to do with DDI ports or PHYs as such. The only thing that matters is the HPD pin assignment. v2: Remember the gvt 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-8-ville.syrjala@linux.intel.com
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: Use _MMIO_PIPE3() for ilk+ WM0_PIPE registersVille Syrjälä
Remove the hand rolled array of WM0_PIPE register offsets and use the standard _MMIO_PIPE3() instead. v2: Take care of gvt too Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212211738.27770-1-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2020-10-29drm/i915: Remove unused variable retZou Wei
This patch fixes below warnings reported by coccicheck ./drivers/gpu/drm/i915/i915_debugfs.c:789:5-8: Unneeded variable: "ret". Return "0" on line 1012 Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1603937925-53176-1-git-send-email-zou_wei@huawei.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-28drm/i915: Guard debugfs against invalid access without displayLucas De Marchi
Do not create the display debugfs files when we don't have display. Based on previous patch by José Souza. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201027044618.719064-1-lucas.demarchi@intel.com
2020-10-23drm/i915/dg1: invert HPD pinsClinton A Taylor
HPD pins are inverted for DG1 platform. Bspec: 49956 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Clinton A Taylor <clinton.a.taylor@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021082034.3170478-3-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-22drm/i915: Reset the interrupt mask on disabling interruptsChris Wilson
As we disable the interrupt during suspend, also reset the irq_mask to short-circuit subsystems that later try to turn off their interrupt source. <4>[ 101.816730] i915 0000:00:02.0: drm_WARN_ON(!intel_irqs_enabled(dev_priv)) <4>[ 101.816853] WARNING: CPU: 3 PID: 4241 at drivers/gpu/drm/i915/i915_irq.c:343 ilk_update_display_irq+0xb3/0x130 [i915] v2: Reset irq_mask for i8xx_irq_reset as well, and split patch to focus on only i915->irq_mask Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201022114246.28566-1-chris@chris-wilson.co.uk
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: Clean up the irq enable/disable for ilk rpsVille Syrjälä
Let's unmask the PCU event irq _after_ we've set up the hardware and software to deal with the fallout. We can also drop the PCU event bit from DEIER except when we need it for rps. And on the disable side we replace the hand rolled (and unlocked) DEIER/IIR/IMR frobbing with ilk_disable_display_irq(). Ocd does require me to reorder it to be symmetric with the enable path however. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-5-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-10-21drm/i915: Do gen5_gt_irq_postinstall() before enabling the master interruptVille Syrjälä
Let's make sure the lower level interrupt bits are all lined up before we flip on the master interrupt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-4-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-10-21drm/i915: Fix potential overflows in ilk ips calculationsVille Syrjälä
A bunch of the ips calculations require 64bit math. In particular 'corr' and 'corr2' look like they can overflow on 32bit systems. Switch to explicit u64 for those. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-10-21drm/i915: Read actual GPU frequency from MEMSTAT_ILK on ILKVille Syrjälä
There is no GEN6_RPSTAT1 on ILK. Instead of reading that let's try to get the same information from MEMSTAT_ILK. At least it seems to track MEMSWCTL frequency request perfectly on my ILK. It needs the same invert trick as the request value. We don't want to put the invert thing into intel_gpu_freq() and intel_freq_opcode() because that would incorrectly invert the min/max/etc frequencies also. One day someone might want to reverse engineer the formula for converting these numbers to Hz, but for now we'll just report them raw. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-10-21drm/i915: Restore ILK-M RPS supportVille Syrjälä
Restore RPS for ILK-M. We lost it when an extra HAS_RPS() check appeared in intel_rps_enable(). Unfortunaltey this just makes the performance worse on my ILK because intel_ips insists on limiting the GPU freq to the minimum. If we don't do the RPS init then intel_ips will not limit the frequency for whatever reason. Either it can't get at some required information and thus makes wrong decisions, or we mess up some weights/etc. and cause it to make the wrong decisions when RPS init has been done, or the entire thing is just wrong. Would require a bunch of reverse engineering to figure out what's going on. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 9c878557b1eb ("drm/i915/gt: Use the RPM config register to determine clk frequencies") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-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-21drm/i915: Introduce scaling filter related registers and bit fieldsPankaj Bharadiya
Introduce scaler registers and bit fields needed to configure the scaling filter in prgrammed mode and configure scaling filter coefficients. changes since v3: * None changes since v2: * Change macro names to CNL_* and use +(set)*8 instead of adding another trip through _PICK_EVEN (Ville). changes since v1: * None changes since RFC: * Parametrize scaler coeffient macros by 'set' (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-3-pankaj.laxminarayan.bharadiya@intel.com
2020-10-21drm: Introduce plane and CRTC scaling filter propertiesPankaj Bharadiya
Introduce per-plane and per-CRTC scaling filter properties to allow userspace to select the driver's default scaling filter or Nearest-neighbor(NN) filter for upscaling operations on CRTC and plane. Drivers can set up this property for a plane by calling drm_plane_create_scaling_filter() and for a CRTC by calling drm_crtc_create_scaling_filter(). NN filter works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. NN filter for integer multiple scaling can be particularly useful for for pixel art games that rely on sharp, blocky images to deliver their distinctive look. changes since: v6: * Move property doc to existing "Standard CRTC Properties" and "Plane Composition Properties" doc comments (Simon) changes since v3: * Refactor code, add new function for common code (Ville) changes since v2: * Create per-plane and per-CRTC scaling filter property (Ville) changes since v1: * None changes since RFC: * Add separate properties for plane and CRTC (Ville) Link: https://github.com/xbmc/xbmc/pull/18194 Link: https://github.com/xbmc/xbmc/pull/18567 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Simon Ser <contact@emersion.fr> Acked-by: Daniel Vetter <daniel@ffwll.ch> 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-2-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: Sort the mess around ICP TC hotplugs regsVille Syrjälä
Move the DSC stuff out from the middle of the ICP HPD register definitions. The location seems to have been selected by a dice roll. SHPD_FILTER_CNT addition also went astray due to the DSC mess, so we also fix that vs. ICP_TC_HPD_{SHORT,LONG}_DETECT(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201006143349.5561-2-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@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-20drm/i915: Drop runtime-pm assert from vgpu io accessorsChris Wilson
The "mmio" writes into vgpu registers are simple memory traps from the guest into the host. We do not need to assert in the guest that the device is awake for the io as we do not write to the device itself. However, over time we have refactored all the mmio accessors with the result that the vgpu reuses the gen2 accessors and so inherits the assert for runtime-pm of the native device. The assert though has actually been there since commit 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps"). References: 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200811092532.13753-1-chris@chris-wilson.co.uk
2020-10-20drm/i915: Force VT'd workarounds when running as a guest OSChris Wilson
If i915.ko is being used as a passthrough device, it does not know if the host is using intel_iommu. Mixing the iommu and gfx causes a few issues (such as scanout overfetch) which we need to workaround inside the driver, so if we detect we are running under a hypervisor, also assume the device access is being virtualised. Reported-by: Stefan Fritsch <sf@sfritsch.de> Suggested-by: Stefan Fritsch <sf@sfritsch.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Stefan Fritsch <sf@sfritsch.de> Cc: stable@vger.kernel.org Tested-by: Stefan Fritsch <sf@sfritsch.de> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201019101523.4145-1-chris@chris-wilson.co.uk
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-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: Apply WAC6entrylatency to kbl/cflVille Syrjälä
WAC6entrylatency is trying to fix excessive rc6 entry latency caused by the extra delay from FBC_LLC_READ_CTRL, which is there for some extra sync with uncore for frame buffer caching in LLC. Reading through the hsd the recommendation was to set the FBC_LLC_FULLY_OPEN bit to disable this extra delay entirely. This can be done whenever fb LLC caching is not used. The alternative suggestion was to reduce the delay to eg. 0x5 via updated BIOS programming instructions. But all the kbl/cfl machines I've seen still have the default 0xff programmed. As we never use fb LLC caching let's just apply the w/a to all skl derivatives to get consistent rc6 latencies. I was able to measure the effect of FBC_LLC_READ_CTRL to rc6 latency via forcewake. Here's a graph of some of the results: sleep;fw_req=1;wait fw_ack==1;sleep;fw_req=0;wait fw_ack==0 fw_ack==1 duration 160us +----------------------------------------------------------------+ | + + $$+ + + | | $$ $ $ ******$$ ** $ $**$* #########$$######| 140us |-$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$*$$$$$$$$$$$$$$$$ $$$$$$| | $ * # | | $ * # | 120us |$+ * # +-| |$ * # | |$ * # # | 100us |$+ ************######################## +-| |$ * *# | |$ ***** ######### | 80us |$+ * # #### ## +-| |$ **** ### # # | | ** #### FBC_LLC_READ_CTRL: 0x8000 ******* | 60us |-###### FBC_LLC_READ_CTRL: 0xffff #######-| |## + + FBC_LLC_READ_CTRL: 0x400000ff $$$$$$$ | +----------------------------------------------------------------+ 0ms 10ms 20ms 30ms 40ms 50ms 60ms sleep duration The default FBC_LLC_READ_CTRL value of 0xff is documented to give us a 170usec delay. That tracks well with the knees at 0xffff->~44msec and 0x8000->~22msec we see in the graph. We can see that if we sleep longer than the FBC_LLC_READ_CTRL delay we always observe the full (~145usec) rc6 wakeup latency. But if we sleep for less than the FBC_LLC_READ_CTRL delay we see a quicker fw wakeup, presumably due the hardware not having yet entered rc6 fully. The other plateaus in the graph I suspect correspond to some shallower internal rc states. v2: s/usec/msec/ typo in commit msg Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716190426.17047-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
generated by cgit (git 2.34.1) at 2025-09-08 16:35:08 +0000