- 13 Feb, 2021 4 commits
-
-
Lucas De Marchi authored
intel_gt_driver_register() may be called earlier than intel_opregion_register() and acpi_video_register(), so move it up. intel_display_debugfs_register() may be called later, together with the other display-related initializations. There is a slight change in behavior that sysfs files will show up before the display-related debugfs files, but that shouldn't be a problem - userspace shouldn't be relying in debugfs. This allows us to group all the display-related calls under a single check for "HAS_DISPLAY()" that can be later moved to a better place. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210213042756.953007-2-lucas.demarchi@intel.com
-
Lucas De Marchi authored
If drm_dev_register() fails there is no reason to continue registering the driver and initializing. Signed-off-by:
-
Matt Roper authored
In rare circumstances bugs in PCI programming, broken BIOS, or failing hardware can cause the CPU to lose access to the MMIO BAR on dgfx platforms. This is a pretty catastrophic failure since all register reads come back with values of 0xFFFFFFFF. Let's check for this special case while doing our usual checks for unclaimed registers; the FPGA_DBG register we use for those checks on modern platforms has some unused bits that will always read back as 0 when things are behaving properly; we can use them as canaries to detect when MMIO itself has suddenly broken and try to print a more informative error message in the logs. v2: Let the detection function still return 'true' if we've lost our MMIO access. We'll still get an extra false positive message about an unclaimed register access, but we'll still honor the 'mmio_debug' limit and not spam the log. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210212211925.3418280-2-matthew.d.roper@intel.comReviewed-by:
-
Matt Roper authored
Although the bspec's description doesn't make it very clear, the hardware architects have confirmed that the FPGA_DBG register that we use to check for unclaimed MMIO accesses is display-specific and will only properly flag unclaimed MMIO transactions for registers in the display range. If a platform doesn't have display, FPGA_DBG itself will not be available and should not be checked. Let's move the feature flag into intel_device_info.display to more accurately reflect this. Given that we now know FPGA_DBG is display-specific, it could be argued that we should only check it on out intel_de_*() functions. However let's not make that change right now; keeping the checks in all of the existing locations still helps us catch cases where regular intel_uncore_*() functions use bad MMIO offset math / base addresses and accidentally wind up landing within an unused area within the display MMIO range. It will also help catch cases where userspace-initiated MMIO (e.g., IGT's intel_reg tool) attempt to read bad offsets within the display range. v2: Add missing hunk with the update to the HAS_FPGA_DBG_UNCLAIMED macro. (CI) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 12 Feb, 2021 5 commits
-
-
Lyude Paul authored
Apparently the new gen9_bc platforms that Intel has introduced don't provide us with a STRAP config register to read from for initializing DDI B, C, and D detection. So, workaround this by hard-coding our strap config in intel_setup_outputs(). Changes since v4: * Split this into it's own commit Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> [originally from Tejas's work] Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-5-lyude@redhat.com
-
Lyude Paul authored
Next, let's start introducing the HPD pin mappings for Intel's new gen9_bc platform in order to make hotplugging display connectors work. Since gen9_bc is just a TGP PCH along with a CML CPU, except with the same HPD mappings as ICL, we simply add a skl_hpd_pin function that is shared between gen9 and gen9_bc which handles both the traditional gen9 HPD pin mappings and the Icelake HPD pin mappings that gen9_bc uses. Changes since v4: * Split this into its own commit * Introduce skl_hpd_pin() like vsyrjala suggested and use that instead of sticking our HPD pin mappings in TGP code Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> [originally from Tejas's work] Signed-off-by:
-
Umesh Nerlige Ramappa authored
After fixing the OA_TAIL_PTR corruption, there are no more reports with reason field of zero. Drop the check for report reason. Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Anshuman Gupta authored
DP-MST connector encoder initializes at modeset Adding a connector->encoder NULL check in order to avoid any NULL pointer dereference. intel_hdcp_enable() already handle this but debugfs can also invoke the intel_{hdcp,hdcp2_capable}. Handling it gracefully. v2: - Use necessary lock and NULL check in i915_hdcp_sink_capability_show. [Imre] Reviewed-by:Imre Deak <imre.deak@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210211140502.22786-1-anshuman.gupta@intel.com
-
Lucas De Marchi authored
We are not checking for specific SKUs and feedback from HW team is that it may not work since it was supposed to be fixed by the same time straps stopped to be used. So, just update comment. v2: Instead of removing the check, just update the comment since feedback from HW team was that it actually may not work Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200625001120.22810-3-lucas.demarchi@intel.com
-
- 11 Feb, 2021 3 commits
-
-
Lyude Paul authored
With the introduction of gen9_bc, where Intel combines Cometlake CPUs with a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this platform in order to make all of the display connectors work. So, let's do that. Changes since v4: * Split this into it's own patch - vsyrjala Changes since v5: * Rename gen9bc_port_to_ddc_pin() to gen9bc_tgp_port_to_ddc_pin() Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> [originally from Tejas's work] Signed-off-by:
-
Lyude Paul authored
Since Intel has introduced the gen9_bc platform, a combination of Tigerpoint PCHs and CML CPUs, let's recognize such platforms as valid and avoid WARNing on them. Changes since v4: * Split this into it's own patch - vsyrjala Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> [originally from Tejas's work] Signed-off-by:
-
Uma Shankar authored
Lane Reversal is required for some of the DDI ports. This information is populated in VBT and driver should read the same and set the polarity while enabling the port. This patch handles the same. It helps fix a display blankout issue on DP ports on certain platforms. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210211114209.23866-1-uma.shankar@intel.com
-
- 10 Feb, 2021 1 commit
-
-
José Roberto de Souza authored
Set the right BW buddy page mask for new memory types. BSpec: 49218 Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
- 09 Feb, 2021 7 commits
-
-
Ville Syrjälä authored
Let's scream if we are about to release a frontbuffer which is still in use. Signed-off-by:
-
Ville Syrjälä authored
We don't have a persistent fb holding a reference to the frontbuffer object, so every time we do the get+put we throw the frontbuffer object immediately away. And so the next time around we get a pristine frontbuffer object with bits==0 even for the old vma. This confuses the frontbuffer tracking code which understandably expects the old frontbuffer to have the overlay's bit set. Fix this by hanging on to the frontbuffer reference until the next flip. And just to make this a bit more clear let's track the frontbuffer explicitly instead of just grabbing it via the old vma. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136Signed-off-by:
-
Ville Syrjälä authored
ilk+ planes get notably unhappy when the plane x+w exceeds the stride. This wasn't a problem previously because we always aligned SURF to the closest tile boundary so the x offset never got particularly large. But now with async flips we have to align to 256KiB instead and thus this becomes a real issue. On ilk/snb/ivb it looks like the accesses just wrap early to the next tile row when scanout goes past the SURF+n*stride boundary, hsw/bdw suffer more heavily and start to underrun constantly. i965/g4x appear to be immune. vlv/chv I've not yet checked. Let's borrow another trick from the skl+ code and search backwards for a better SURF offset in the hopes of getting the x offset below the limit. IIRC when I ran into a similar issue on skl years ago it was causing the hardware to fall over pretty hard as well. And let's be consistent and include i965/g4x in the check as well, just in case I just got super lucky somehow when I wasn't able to reproduce the issue. Not that it really matters since we still use 4k SURF alignment for i965/g4x anyway. Fixes: 6ede6b06 ("drm/i915: Implement async flips for vlv/chv") Fixes: 4bb18054 ("drm/i915: Implement async flip for ilk/snb") Fixes: 2a636e24 ("drm/i915: Implement async flip for ivb/hsw") Fixes: cda195f1 ("drm/i915: Implement async flips for bdw") Signed-off-by:
-
Imre Deak authored
The TypeC FIA can be powered down if the TC-COLD power state is allowed, so block the TC-COLD state when initializing the FIA. Note that this isn't needed on ICL where the FIA is never modular and which has no generic way to block TC-COLD (except for platforms with a legacy TypeC port and on those too only via these legacy ports, not via a DP-alt/TBT port). Cc: <stable@vger.kernel.org> # v5.10+ Cc: José Roberto de Souza <jose.souza@intel.com> Reported-by:
Paul Menzel <pmenzel@molgen.mpg.de> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3027Signed-off-by:
-
Umesh Nerlige Ramappa authored
Gen12 supports additional OA formats as compared to what was added earlier. Include the additional OA formats. Signed-off-by:
-
Umesh Nerlige Ramappa authored
Variations in OA formats in the different gens has led to creation of several sparse arrays to store the formats. Move oa formats into a single array and format_mask to check for platform specific oa formats. Signed-off-by:
-
Umesh Nerlige Ramappa authored
Validity of an OA format is checked by using a sparse array of formats per gen. Instead maintain a mask of supported formats for a platform in the perf object. v2: Use set_bit and test_bit style for the format_mask (Chris) Signed-off-by:
-
- 08 Feb, 2021 9 commits
-
-
Tejas Upadhyay authored
Removing force probe protection from RKL platform. Did not observe warnings, errors, flickering or any visual defects while doing ordinary tasks like browsing and editing documents in a two monitor setup. Signed-off-by:
-
Ankit Nautiyal authored
Legacy LSPCON chip from MCA and Parade is only used for platforms between GEN9 and GEN10. Fixing the HAS_LSPCON macro to reflect the same. Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Dave Airlie authored
This moves the code from various places and consolidates it into one new file. v2: - rename skl_program_plane -> skl_program_plane_scaler (Ville) - also move skl_pfit_enable, and consequently make some skl_scaler_* functions static to skl_scaler.c (Ville) Signed-off-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
-
Dave Airlie authored
Migrate this code out like the skylake code. Signed-off-by:
-
Dave Airlie authored
This moves the older i9xx/vlv/chv enable/disable to dpll file. Signed-off-by:
-
Dave Airlie authored
There is no need for this to be out of line. Reviewed-by:
-
Dave Airlie authored
This just cleans these up a bit. Signed-off-by:
-
Dave Airlie authored
Daniel suggested this should move here. v2: move vrr code. Signed-off-by:
-
Dave Airlie authored
Rework the plane init calls to do the gen test one level higher. Rework some of the plane helpers so they can live in new file, there is still some scope to clean up the plane/fb interactions later. v2: drop atomic code back, rename file to Ville suggestions, add header file. v3: move scaler bits back v4: drop wrong new includes (Ville) v5: integrate the ccs gen12 changes v6: fix unrelated code movement (Ville) Signed-off-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
- 05 Feb, 2021 10 commits
-
-
Ville Syrjälä authored
Replace the hand rolled intel_hdmi_port_clock() stuff with the real thing. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
min_cdclk[] and min_voltage_level[] are supposed to be indexed with the pipe. Fix up a few cases where we index via the crtc index (via the atomic iterators) instead. Signed-off-by:
-
Dave Airlie authored
Daniel asked for this, but it's a bit messy and I'm not sure how best to clean it up yet. Signed-off-by:
-
Dave Airlie authored
Ville suggested this, these tables are probably better being standalone. This fixes up the cnl/bxt interfaces to be like the others, the intel one I left alone since it has a few extra entrypoints. v2: add back missing rocketlake bits. Reviewed-by:
-
José Roberto de Souza authored
By mistake those 2 parameters were defined as read and write in the .h file while in the .c file it is read only. The intention here was to be read only to avoid the need of additional handling. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204153357.39681-1-jose.souza@intel.com
-
Edmund Dea authored
While JSL and EHL eDP transcoder supports PSR2, the phy of this platforms only supports eDP 1.3, so removing PSR2 support as this feature was added in eDP 1.4. Signed-off-by:
Edmund Dea <edmund.j.dea@intel.com> Signed-off-by:
-
Gwan-gyeong Mun authored
In order to support the PSR state of each transcoder, it adds i915_psr_status to sub-directory of each transcoder. v2: Change using of Symbolic permissions 'S_IRUGO' to using of octal permissions '0444' v5: Addressed JJani Nikula's review comments - Remove checking of Gen12 for i915_psr_status. - Add check of HAS_PSR() - Remove meaningless check routine. Signed-off-by: -
Gwan-gyeong Mun authored
It is a preliminary work for supporting multiple EDP PSR and DP PanelReplay. And it refactors singleton PSR to Multi Transcoder supportable PSR. And this moves and renames the i915_psr structure of drm_i915_private's to intel_dp's intel_psr structure. It also causes changes in PSR interrupt handling routine for supporting multiple transcoders. But it does not change the scenario and timing of enabling and disabling PSR. And it not support multiple pipes with a single transcoder PSR case yet. v2: Fix indentation and add comments v3: Remove Blank line v4: Rebased v5: Rebased and Addressed Anshuman's review comment. - Move calling of intel_psr_init() to intel_dp_init_connector() v6: Address Anshuman's review comments - Remove wrong comments and add comments for a limit of supporting of a single pipe PSR v7: Update intel_psr_compute_config() for supporting multiple transcoder PSR on BDW+ v8: Address Anshuman's review comments - Replace DRM_DEBUG_KMS with drm_dbg_kms() / DRM_WARN with drm_warn() v9: Fix commit message v10: Rebased v11: Address Jose's review comment. - Reorder calling order of intel_psr2_program_trans_man_trk_ctl(). - In order to reduce changes keep the old name for drm_i915_private. - Change restrictions of multiple instances of PSR. v12: Address Jose's review comment. - Change the calling of intel_psr2_program_trans_man_trk_ctl() into commit_pipe_config(). - Change a checking order of CAN_PSR() and connector_status to original on i915_psr_sink_status_show(). - Drop unneeded intel_dp_update_pipe() function. - In order to wait a specific encoder which belong to crtc_state on intel_psr_wait_for_idle(), add checking of encoder. - Add an whitespace to comments. v13: Rebased and Address Jose's review comment. - Add and use for_each_intel_psr_enabled_encoder() macro. - In order to use correct frontbuffer_bit for each pipe, fix intel_psr_invalidate() and intel_psr_flush(). - Remove redundant or unneeded codes. - Update comments. v14: Address Jose's review comment - Add and use for_each_intel_encoder_can_psr() macro and for_each_intel_encoder_mask_can_psr() macro. - Add source_support member variable into intel_psr structure. - Update CAN_PSR() macro that checks source_support. - Move encoder's PSR availity check to psr_init() from psr_compute_config(). - Remove redundant or unneeded codes. v15: Remove wrong mutex lock/unlock of PSR from intel_psr2_program_trans_man_trk_ctl() Signed-off-by: -
Clint Taylor authored
Add DDR5 and LPDDR5 return values from punit fw. BSPEC: 54023 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by:
-
Ville Syrjälä authored
The BXT/GLK DPLL can't generate certain frequencies. We already reject the 233-240MHz range on both. But on GLK the DPLL max frequency was bumped from 300MHz to 594MHz, so now we get to also worry about the 446-480MHz range (double the original problem range). Reject any frequency within the higher problematic range as well. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000Signed-off-by:
-
- 04 Feb, 2021 1 commit
-
-
Imre Deak authored
At least on some TGL platforms PUNIT wants to access some display HW registers, but it doesn't handle display power management (disabling DC states as required) and so this register access will lead to a hang. To prevent this disable runtime power management for poweroff and reboot. v2: - Add code comment clarifying the requirement of display power states. (Ville) Reported-and-tested-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by:
-
