- 16 Feb, 2021 3 commits
-
-
Ville Syrjälä authored
Yank out the HSW/BDW code from intel_ddi_clk_{select,disable}() and put it into the new encoder .{enable,disable}_clock() vfuncs. v2: s/dev_priv/i915/ (Lucas) v3: Deal with FDI Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2 Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-4-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
The current code dealing with the clock routing for DDI encoders is a maintenance nightmare. Let's start cleaning it up by allowing the encoder to provide vfuncs for enablign/disabling the clock. We leave them initially unimplemented, falling back to the old if-else approach. v2: Convert the FDI enable sequence Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2 Signed-off-by:
-
Ville Syrjälä authored
We want to put all DDI clock routing code into one place. Unify the FDI enable sequence to use the standard function instead of hand rolling its own. The disable sequence already uses the normal thing. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
- 13 Feb, 2021 6 commits
-
-
Lucas De Marchi authored
intel_init_audio_hooks() sets up hooks in the display struct and only makes sense when we have display. Move it inside intel_init_display_hooks() so it isn't called when we don't have display. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210213042756.953007-4-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Now that all display-related functions are grouped in i915_driver_register(), move them to display/ so we reduce the amount of display calls from the rest of the driver. Signed-off-by:
-
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 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:
-
- 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 6 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:
-
