- 17 Mar, 2023 2 commits
-
-
Ville Syrjälä authored
This PIPEMISC vs. PIPE_MISC inconsitency is ugly. Unify the naming (PIPE_MISC is also what bspec has always called it). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230314130255.23273-3-ville.syrjala@linux.intel.comReviewed-by:
Jouni Högander <jouni.hogander@intel.com>
-
Ville Syrjälä authored
The PIPE_MISC registers don't exist on pre-bdw hardware, so there is no point in using pipe_offsets[] for them. Signed-off-by:
-
- 16 Mar, 2023 3 commits
-
-
Vinod Govindapillai authored
If the ignore long HPD flag is set, ignore the link training failures as well. Because of spurious HPDs, some unexpected link training failures are happening while executing IGT test cases. Ignore the link training failures for the time being if the long HPDs are also ignored in the environments like CI. Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Vinod Govindapillai authored
Some panels generate long HPD events even while connected to the port. This cause some unexpected CI execution issues. A new flag is added to track if such spurious long HPDs can be ignored and are not processed further if the flag is set. Debugfs entry is added to control the ignore long hpd flag. v2: Address patch styling comments (Jani Nikula) v3: Ignoring the HPD moved to hotplug handler and now applies to all types of outputs (Imre Deak) v4: use debugfs_create_bool and squash patches (Jani Nikula) Signed-off-by: -
Imre Deak authored
Add the missing intel_opregion_cleanup() prototype fixing CONFIG_ACPI=n builds. Fixes: 3e226e4a ("drm/i915/opregion: Cleanup opregion after errors during driver loading") Cc: Jani Nikula <jani.nikula@intel.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202303141610.6L1VO7Gw-lkp@intel.com/Signed-off-by:
-
- 15 Mar, 2023 2 commits
-
-
Ville Syrjälä authored
Bspec calls us to select pattern 2 after link training for DP 2.0. Let's do that... by doing nothing because we will be transmitting pattern 2 at the end of the link training already. Reviewed-by:
-
Ville Syrjälä authored
AFAICS Bspec has never asked us to switch to TPS1 when *disabling* DP_TP_CTL. Let's stop doing that in case it confuses something. We do have to switch before we *enable* DP_TP_CTL, but that is already being handled correctly. v2: Do the same for FDI v3: Rebase Reviewed-by: Imre Deak <imre.deak@intel.com> #v1 Signed-off-by:
-
- 14 Mar, 2023 2 commits
-
-
Ankit Nautiyal authored
While computing compressed bpp, maximum value of bits_per_pixel is calculated that can be supported with the given link configuration for a given mode. Avoid rounding up of this max bits_per_pixel. Also improve documentation for computing max bits_per_pixel. Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Jani Nikula authored
Follow the style of placing debugfs next to the implementation. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
- 10 Mar, 2023 7 commits
-
-
Ville Syrjälä authored
The pipe needs a certain amount of time during vblank to prefill sufficiently. If the vblank is too short the relevant watermark level must be disabled. Start implementing the necessary calculations to check this. Scaler and DSC prefill are left out for now as handling those is not entirely trivial. Also the PSR latency reporting override chicken bits would need to be correctly configured based on the results of these calculations. Just add some FIXMEs for now. TODO: bspec isn't exactly crystal clear in its explanations so quite a few open questions remain... v2: Skip inacive pipes Handle SAGV latency v3: Rebase v4: Fix handling of disabled wm levels (latency == 0) Reviewed-by: -
Ville Syrjälä authored
Extract the skl+ wm latency determination into a small helper so that everyone has the same idea what the latency should be. This introduces a slight functional change in that skl_cursor_allocation() will now start to account for the extra 4 usec that the kbk/cfl/cml IPC w/a adds. v2: Rebase Reviewed-by:
-
Imre Deak authored
Move the display debugfs registration later, after initializing steps for opregion/acpi/audio. These latter ones don't depend on the debugfs entries, OTOH some debugfs entries may depend on the initialized state. Reviewed-by:
-
Imre Deak authored
Clean up the opregion state if something fails after intel_opregion_setup() is called. Reviewed-by:
-
Imre Deak authored
Atm, during system resume, the driver updates the display connector information required by the opregion video extensions during system resume, on platforms both with and without display being present. On !HAS_DISPLAY platforms this will result in the crash with the stack trace below, since the driver's connector state is not initialized on those. Bspec doesn't specify when each of the opregion functionality is supported (depending on the presence of display), however we can presume that none of the video extensions, nor the ACPI _DSM functions are supported on !HAS_DISPLAY platforms; accordingly skip the corresponding opregion/ACPI setup on those (also matching the Windows driver in this). Keep sending the opregion notification about suspending/resuming the whole adapter (vs. the display only which is a separate power state notification) on all platforms, similarly to runtime suspend/resume. This fixes the following: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 1443 Comm: kworker/u40:55 Tainted: G U 6.2.0-rc8+ #58 Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW 04/26/2022 Workqueue: events_unbound async_run_entry_fn RIP: 0010:drm_connector_list_iter_next+0x4f/0xb0 Call Trace: <TASK> intel_acpi_device_id_update+0x80/0x160 [i915] intel_opregion_resume+0x2f/0x1e0 [i915] ? dg2_init_clock_gating+0x49/0xf0 [i915] i915_drm_resume+0x137/0x190 [i915] ? __pfx_pci_pm_resume+0x10/0x10 dpm_run_callback+0x47/0x150 Cc: iczero <iczero@hellomouse.net> Reported-and-tested-by:
iczero <iczero@hellomouse.net> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015Reviewed-by:
-
Ville Syrjälä authored
intel_crtc_prepare_cleared_state() is unintentionally losing the "inherited" flag. This will happen if intel_initial_commit() is forced to go through the full modeset calculations for whatever reason. Afterwards the first real commit from userspace will not get forced to the full modeset path, and thus eg. audio state may not get recomputed properly. So if the monitor was already enabled during boot audio will not work until userspace itself does an explicit full modeset. Cc: stable@vger.kernel.org Tested-by:
Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
Stanislav Lisovskiy authored
We currently have an issue with some BPPs when using DSC. According to the HW team, the reason is that a single VDSC engine instance has some BW limitations that must be accounted for. So, whenever we approach around 90% of the CDCLK, a second VDSC engine has to be used. This always means using two slices. However, in our current code, the amount of slices is calculated independently of whether we need to enable the second VDSC engine or not. This leads to some logical issues when, according to the pixel clock needs, we need to enable the second VDSC engine. But as we calculated previously that we can only use a single slice, we can't do that and fail. So, we need to fix that so that the number of VDSC engines enabled should depend on the number of slices, and the number of slices should also depend on BW requirements. Lastly, we didn't have BPP limitation for ADLP/MTL/DG2 implemented, which says that DSC output BPPs can only be chosen within the range of 8 to 27 (BSpec 49259). All of this applied together allows us to fix existing FIFO underruns, which we have in many DSC tests. v2: - Replace min with clamp_t(Jani Nikula) - Fix commit message(Swati Sharma) - Added "Closes"(Swati Sharma) BSpec: 49259 HSDES: 18027167222 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8231Signed-off-by:
-
- 09 Mar, 2023 4 commits
-
-
Madhumitha Tolakanahalli Pradeep authored
Add support to load DMC on MTL. According to the spec and based on tests done on real hardware, 0x7000 is a reasonable size limit that covers each possible payload. v2: - Tighten payload size limit. (Matt, Rodrigo) - Use a better name for the defined payload limit. (Rodrigo) Signed-off-by:
Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Latch reset of phys during DC9 and when driver is unloaded to avoid phy reset. Specification ask us to program it closer to the step that enables DC9 in DC_STATE_EN but doing this way allow us to sanitize the phy latch during driver load. BSpec: 49197 Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301201053.928709-6-radhakrishna.sripada@intel.com
-
Tejas Upadhyay authored
lock the fbdev obj before calling into i915_vma_pin_iomap(). This helps to solve below : <7>[ 93.563308] i915 0000:00:02.0: [drm:intelfb_create [i915]] no BIOS fb, allocating a new one <4>[ 93.581844] ------------[ cut here ]------------ <4>[ 93.581855] WARNING: CPU: 12 PID: 625 at drivers/gpu/drm/i915/gem/i915_gem_pages.c:424 i915_gem_object_pin_map+0x152/0x1c0 [i915] Fixes: f0b6b01b ("drm/i915: Add ww context to intel_dpt_pin, v2.") Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by:
-
Radhakrishna Sripada authored
The commit 2357f2b2 ("drm/i915/mtl: Initial display workarounds") extended the workaround Wa_16015201720 to MTL. However the registers that the original WA implemented moved for MTL. Implement the workaround with the correct register. v3: Skip clock gating for pipe C, D DMC's and fix the title Fixes: 2357f2b2 ("drm/i915/mtl: Initial display workarounds") Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 07 Mar, 2023 4 commits
-
-
Ville Syrjälä authored
The idea that ctg uses different HPD live state bits is total nonsense, at least on my machine (Dell Latitude E5400). The only reason DP-B even works on my ctg is that DP-D live state is stuck high, even though there is no physical DP-D port. So when the detect checks DP-B live state it sees the stuck live state of DP-D instead. If I hack the driver to not register DP-D at all, and thus we never enabe DP-D HPD, DP-B stops working as well. Just to put some conclusive evidence into this mess, here are the actual hotplug register values for each port: Everything disconnected: PORT_HOTPLUG_EN (0x00061110): 0x00000000 PORT_HOTPLUG_STAT (0x00061114): 0x00000000 PORT_HOTPLUG_EN (0x00061110): 0x08000000 PORT_HOTPLUG_STAT (0x00061114): 0x08000000 PORT_HOTPLUG_EN (0x00061110): 0x10000000 PORT_HOTPLUG_STAT (0x00061114): 0x00000000 PORT_HOTPLUG_EN (0x00061110): 0x20000000 PORT_HOTPLUG_STAT (0x00061114): 0x00000000 Only port B connected: PORT_HOTPLUG_EN (0x00061110): 0x00000000 PORT_HOTPLUG_STAT (0x00061114): 0x00000000 PORT_HOTPLUG_EN (0x00061110): 0x08000000 PORT_HOTPLUG_STAT (0x00061114): 0x08000000 PORT_HOTPLUG_EN (0x00061110): 0x10000000 PORT_HOTPLUG_STAT (0x00061114): 0x00000000 PORT_HOTPLUG_EN (0x00061110): 0x20000000 PORT_HOTPLUG_STAT (0x00061114): 0x20000000 Only port C connected: PORT_HOTPLUG_EN (0x00061110): 0x00000000 PORT_HOTPLUG_STAT (0x00061114): 0x00000000 PORT_HOTPLUG_EN (0x00061110): 0x08000000 PORT_HOTPLUG_STAT (0x00061114): 0x08000000 PORT_HOTPLUG_EN (0x00061110): 0x10000000 PORT_HOTPLUG_STAT (0x00061114): 0x10000000 PORT_HOTPLUG_EN (0x00061110): 0x20000000 PORT_HOTPLUG_STAT (0x00061114): 0x00000000 So the enable bit and live state bit always match 1:1. Acked-by: -
Ville Syrjälä authored
SKL doesn't have any north DE hotplug stuff. Currently we're trying to read DDI A live state from the BDW north DE bit, instead of the approproate south DE bit. Fix it. And for good measure clear the pointer to the north hpd pin array, so that we'll actually notice if some other place is also using the wrong thing. Reviewed-by:
-
Ville Syrjälä authored
We'll need dig_port->connected() to be there for a HPD live state check during eDP connector probing. Reorder intel_ddi_init() accordingly. g4x_dp_init() is already fine. v2: Fix comment style while at it Reviewed-by:
-
Ville Syrjälä authored
The most modern VBT I've observed in the wild is version 250. The child dev size hasn't changed since version 216, so bump the version number in the expected child dev size check. Signed-off-by:
-
- 06 Mar, 2023 12 commits
-
-
Jani Nikula authored
Split out the RPS parts so they can be conditionally compiled out later. Signed-off-by:
-
Jani Nikula authored
Follow the contemporary convention for struct drm_i915_private * naming. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Jani Nikula authored
sizeof(struct intel_dmc) > 1024 bytes, allocated on all platforms as part of struct drm_i915_private, whether they have DMC or not. Allocate struct intel_dmc dynamically, and hide all the dmc details behind an opaque pointer in intel_dmc.c. Care must be taken to take into account all cases: DMC not supported on the platform, DMC supported but not initialized, and DMC initialized but not loaded. For the second case, we need to move the wakeref out of struct intel_dmc. v2: - Rebase to kzalloc dmc after runtime pm get (Imre) Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Jani Nikula authored
Start preparing for dynamically allocated struct intel_dmc by adding i915_to_dmc() and dmc->i915, and using them. Take the future NULL dmc pointer into account already now, and add separate logging for initialization in the DMC debugfs. v3: - Obtain runtime pm reference first (Imre) v2: - Don't reduce debugfs output (Imre) Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Jani Nikula authored
This will help in follow-up changes. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Jani Nikula authored
There's only one reference to the struct intel_dmc members dc_state, target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the question why they are under struct intel_dmc to begin with. Moreover, the only references to i915->display.dmc outside of intel_dmc.c are to these members. They don't belong. Move them from struct intel_dmc to struct i915_power_domains, which seems like a more suitable place. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Jani Nikula authored
As intel_pm.[ch] used to contain much more, intel_pm.h was included in a lot of places. Many of them are now unnecessary. Remove. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ab9a7147b0cd63d95b9f27ed40615b9c9be18f84.1677678803.git.jani.nikula@intel.com
-
Jani Nikula authored
All intel_suspend_hw() does is clear PCH_LP_PARTITION_LEVEL_DISABLE bit in SOUTH_DSPCLK_GATE_D for LPT LP. intel_suspend_hw() gets called from i915_drm_suspend(). However, i915_drm_suspend_late() calls intel_display_power_suspend_late(), which in turn calls hsw_enable_pc8() on HSW and BDW. The first thing that does is clear PCH_LP_PARTITION_LEVEL_DISABLE bit in SOUTH_DSPCLK_GATE_D. Remove the duplicated clearing of the bit, effectively delaying it from i915_drm_suspend() to i915_drm_suspend_late(), and remove the unnecessary intel_suspend_hw() function altogether. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Jani Nikula authored
All the init in intel_pm_setup() is related to runtime pm. Move them to intel_runtime_pm_init_early(), and remove intel_pm_setup(). Signed-off-by:
-
Jani Nikula authored
Remove the leftover from moving and renaming the file from driver top level. Signed-off-by:
-
Jani Nikula authored
Relatively few places need the DSC and DSS register definitions. Move them to intel_vdsc_regs.h. Signed-off-by:
-
Jani Nikula authored
On TGL+ the DSS control registers are at different offsets, and there's one per pipe. Fix the offsets to fix dual link DSI for TGL+. There would be helpers for this in the DSC code, but just do the quick fix now for DSI. Long term, we should probably move all the DSS handling into intel_vdsc.c, so exporting the helpers seems counter-productive. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8232 Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- 01 Mar, 2023 4 commits
-
-
Ashutosh Dixit authored
The value shown by power1_max_interval in millisec is essentially: ((1.x * power(2,y)) * 1000) >> 10 Where x and y are read from a HW register. On ATSM, x and y are 0 on power-up so the value shown is 0. Writes of 0 to power1_max_interval had previously been disallowed to avoid computing ilog2(0) but this resulted in the corner-case bug below. Therefore allow writes of 0 now but special case that write to x = y = 0. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7754Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Badal Nilawar <badal.nilawar@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Fix the code to correctly determine whether delayed vblank is used or not. Signed-off-by:
-
Ville Syrjälä authored
The "window2" delay is just the difference of vactive (undelayed vblank) vs. vblank_start (delayed vblank). Just use vblank_start during the VRR calculations so that things work correctly regardless of whether delayed vblank is used or not. Signed-off-by:
-
Ville Syrjälä authored
Grab the HDR DPCD refresh timeout (time we need to wait after writing the sourc OUI before the HDR DPCD registers are ready) from the VBT. Windows doesn't even seem to have any default value for this, which is perhaps a bit weird since the VBT value is documented as TGL+ and I thought the HDR backlight stuff might already be used on earlier platforms. To play it safe I left the old hardcoded 30ms default in place. Digging through some internal stuff that seems to have been a number given by the vendor for one particularly slow TCON. Although I did see 50ms mentioned somewhere as well. Let's also include the value in the debug print to ease debugging, and toss in the customary connector id+name as well. The TGL Thinkpad T14 I have sets this to 0 btw. So the delay is now gone on this machine: [CONNECTOR:308:eDP-1] Detected Intel HDR backlight interface version 1 [CONNECTOR:308:eDP-1] Using Intel proprietary eDP backlight controls [CONNECTOR:308:eDP-1] SDR backlight is controlled through PWM [CONNECTOR:308:eDP-1] Using native PCH PWM for backlight control (controller=0) [CONNECTOR:308:eDP-1] Using AUX HDR interface for backlight control (range 0..496) [CONNECTOR:308:eDP-1] Performing OUI wait (0 ms) Cc: Lyude Paul <lyude@redhat.com> Signed-off-by:
-
