- 28 Oct, 2020 1 commit
-
-
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:
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
-
- 24 Oct, 2020 2 commits
-
-
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
-
- 23 Oct, 2020 1 commit
-
-
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:
-
- 22 Oct, 2020 1 commit
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201022114246.28566-1-chris@chris-wilson.co.uk
-
- 21 Oct, 2020 11 commits
-
-
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:
-
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/18567Reviewed-by:
Simon Ser <contact@emersion.fr> Acked-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 20 Oct, 2020 23 commits
-
-
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:
-
Alexei Podtelezhnikov authored
Add three new devices 0x1913, 0x1915, and 0x1917 also known as iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Signed-off-by:
Alexei Podtelezhnikov <apodtele@gmail.com> [vsyrjala: Split separate changes into separate patchs, Sort the IDs] Signed-off-by:
-
Alexei Podtelezhnikov authored
Reclassify 0x1923, 0x1927 according to specifications. Of note, the second to last digit seems to correspond to GT#. Signed-off-by:
-
Alexei Podtelezhnikov authored
Reclassify 0x192A according to specifications. Of note, the second to last digit seems to correspond to GT#. Signed-off-by:
-
Alexei Podtelezhnikov authored
Reclassify 0x0426 as GT3 (GT2+) according to specifications and the second least significant digit. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
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 15239099 ("drm/i915: enable irqs earlier when resuming") on account of moving the irq enable earlier. This then got removed in commit 50c3dc97 ("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 0e32b39c ("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 e8a8fedd ("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:Lyude Paul <lyude@redhat.com>
-
Ville Syrjälä authored
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ä authored
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:
-
Chris Wilson authored
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 3be0bf5a ("drm/i915: Create vGPU specific MMIO operations to reduce traps"). References: 3be0bf5a ("drm/i915: Create vGPU specific MMIO operations to reduce traps") Signed-off-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
-
Chris Wilson authored
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:
-
José Roberto de Souza authored
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 authored
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:
-
- 16 Oct, 2020 1 commit
-
-
Ville Syrjälä authored
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:
-
