- Oct 30, 2020
-
-
Ville Syrjälä authored
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
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
- Oct 29, 2020
-
-
Ville Syrjälä authored
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:
-
Zou Wei authored
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:
-
Imre Deak authored
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
-
- Oct 28, 2020
-
-
Lucas De Marchi authored
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:Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201027044618.719064-2-lucas.demarchi@intel.com
-
Lucas De Marchi authored
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:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201027044618.719064-1-lucas.demarchi@intel.com
-
- Oct 24, 2020
-
-
Clinton A Taylor authored
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 authored
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:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021082034.3170478-2-lucas.demarchi@intel.com
-
José Roberto de Souza authored
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:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
- Oct 23, 2020
-
-
Chris Wilson authored
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:
-
- Oct 22, 2020
-
-
Chris Wilson authored
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:
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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: 9c878557 ("drm/i915/gt: Use the RPM config register to determine clk frequencies") Signed-off-by:
-
- Oct 21, 2020
-
-
Pankaj Bharadiya authored
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:
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:
-
Pankaj Bharadiya authored
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:
-
Pankaj Bharadiya authored
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:
-
Pankaj Bharadiya authored
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:
Simon Ser <contact@emersion.fr> Acked-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Manasi Navare authored
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ä authored
Sort the ICL PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com>
-
Ville Syrjälä authored
Sort the CNL PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sort the CFL PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sort the CML PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sort the KBL PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sort the SKL PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sort the HSW PCI IDs numerically. Some order seems better than randomness. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Most of the HSW PCI IDs are upper case hex numbers, but a few are lower case. Make it consistent so these don't stick out like a sore thumb. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Bunch of the SKL SKUs currently documented as GT3/4 seem to actually be GT3e/4e. Fix up the comments. Cc: Alexei Podtelezhnikov <apodtele@gmail.com> Signed-off-by:
-
