summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-03-10drm/i915/opregion: Fix opregion setup during system resume on platforms ↵Imre Deak
without display 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/8015 Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230308162503.3219200-1-imre.deak@intel.com
2023-03-10drm/i915: Preserve crtc_state->inherited during state clearingVille Syrjälä
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230223152048.20878-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2023-03-10drm/i915: Ensure DSC has enough BW and stays within HW limitsStanislav Lisovskiy
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/8231 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230306080401.22552-1-stanislav.lisovskiy@intel.com
2023-03-09drm/i915/dmc: Load DMC on MTLMadhumitha Tolakanahalli Pradeep
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: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230307195111.90767-1-gustavo.sousa@intel.com
2023-03-09drm/i915/display/mtl: Program latch to phy resetJosé Roberto de Souza
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: Matt Roper <matthew.d.roper@intel.com> Signed-off-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
2023-03-09drm/i915/fbdev: lock the fbdev obj before vma pinTejas Upadhyay
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: f0b6b01b3efe ("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 <radhakrishna.sripada@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301201053.928709-5-radhakrishna.sripada@intel.com
2023-03-09drm/i915/mtl: Fix Wa_16015201720 implementationRadhakrishna Sripada
The commit 2357f2b271ad ("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: 2357f2b271ad ("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: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301201053.928709-2-radhakrishna.sripada@intel.com
2023-03-07drm/i915: Get rid of the gm45 HPD live state nonsenseVille Syrjälä
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: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230302161013.29213-4-ville.syrjala@linux.intel.com
2023-03-07drm/i915: Fix SKL DDI A digital port .connected()Ville Syrjälä
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: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230302161013.29213-3-ville.syrjala@linux.intel.com
2023-03-07drm/i915: Populate dig_port->connected() before connector initVille Syrjälä
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: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230302161013.29213-2-ville.syrjala@linux.intel.com
2023-03-07drm/i915: Bump VBT version for expected child dev size checkVille Syrjälä
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230306154419.23207-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-03-06drm/i915/rps: split out display rps parts to a separate fileJani Nikula
Split out the RPS parts so they can be conditionally compiled out later. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230302164936.3034161-1-jani.nikula@intel.com
2023-03-06drm/i915/dmc: mass rename dev_priv to i915Jani Nikula
Follow the contemporary convention for struct drm_i915_private * naming. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-5-jani.nikula@intel.com
2023-03-06drm/i915/dmc: allocate dmc structure dynamicallyJani Nikula
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: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-4-jani.nikula@intel.com
2023-03-06drm/i915/dmc: add i915_to_dmc() and dmc->i915 and use themJani Nikula
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: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-3-jani.nikula@intel.com
2023-03-06drm/i915/dmc: use has_dmc_id_fw() instead of poking dmc->dmc_info directlyJani Nikula
This will help in follow-up changes. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-2-jani.nikula@intel.com
2023-03-06drm/i915/power: move dc state members to struct i915_power_domainsJani Nikula
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: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301122944.1298929-1-jani.nikula@intel.com
2023-03-06drm/i915: remove unnecessary intel_pm.h includesJani Nikula
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: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ab9a7147b0cd63d95b9f27ed40615b9c9be18f84.1677678803.git.jani.nikula@intel.com
2023-03-06drm/i915/pm: drop intel_suspend_hw()Jani Nikula
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 <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f732a7922c2450b41169c9b79a80fba97ab00592.1677678803.git.jani.nikula@intel.com
2023-03-06drm/i915/pm: drop intel_pm_setup()Jani Nikula
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 <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b01f9bf0afa9abaece5d0f76aecde69e2679f662.1677678803.git.jani.nikula@intel.com
2023-03-06drm/i915/wm: remove display/ prefix from includeJani Nikula
Remove the leftover from moving and renaming the file from driver top level. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f11cbbdb5a5c8961fcae0b3f6c87860ee00f8c26.1677678803.git.jani.nikula@intel.com
2023-03-06drm/i915/display: split out DSC and DSS registersJani Nikula
Relatively few places need the DSC and DSS register definitions. Move them to intel_vdsc_regs.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301151949.1591501-1-jani.nikula@intel.com
2023-03-06drm/i915/dsi: fix DSS CTL register offsets for TGL+Jani Nikula
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: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230301151409.1581574-1-jani.nikula@intel.com
2023-03-01drm/i915/hwmon: Accept writes of value 0 to power1_max_intervalAshutosh Dixit
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/7754 Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230228044334.3630391-1-ashutosh.dixit@intel.com
2023-03-01drm/i915/psr: Fix the delayed vblank w/aVille Syrjälä
Fix the code to correctly determine whether delayed vblank is used or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127173044.24108-3-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-03-01drm/i915/vrr: Fix "window2" handlingVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127173044.24108-2-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-03-01drm/i915: Get HDR DPCD refresh timeout from VBTVille Syrjälä
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230220164718.23117-1-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-02-27drm/i915/gen12: Update combo PHY init sequenceMatt Roper
The bspec was updated with a minor change to the 'DCC mode select' setting to be programmed during combo PHY initialization. v2: - Keep the opencoded rmw behavior instead of switching to intel_de_rmw(). We need to read from a _LN register, but write to the _GRP register to update all lanes. Bspec: 49291 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230221201836.2886794-1-matthew.d.roper@intel.com
2023-02-25drm/i915: Move MCR_REG define to i915_reg_defs.hLucas De Marchi
Define MCR_REG() in the same header where i915_mcr_reg_t is defined, like i915_reg_t and _MMIO(). It's a more natural place for such a definition so it's not mixed with the registers for the platforms. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230224211221.1557268-1-lucas.demarchi@intel.com
2023-02-24drm/i915: Remove unused tmp assignment.Rodrigo Vivi
These are left overs from the conversion towards intel_de_rmw. Fixes: aa80b2b12b89 ("drm/i915/display/panel: use intel_de_rmw if possible in panel related code") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230224153707.813953-1-rodrigo.vivi@intel.com
2023-02-24drm/i915/dg2: Add HDMI pixel clock frequencies 267.30 and 319.89 MHzAnkit Nautiyal
Add snps phy table values for HDMI pixel clocks 267.30 MHz and 319.89 MHz. Values are based on the Bspec algorithm for PLL programming for HDMI. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8008 Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230223043619.3941382-1-ankit.k.nautiyal@intel.com
2023-02-24drm/i915/psr: Use calculated io and fast wake linesJouni Högander
Currently we are using hardcoded 7 for io and fast wake lines. According to Bspec io and fast wake times are both 42us for DISPLAY_VER >= 12 and 50us and 32us for older platforms. Calculate line counts for these and configure them into PSR2_CTL accordingly Use 45 us for the fast wake calculation as 42 seems to be too tight based on testing. Bspec: 49274, 4289 Cc: Mika Kahola <mika.kahola@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: 64cf40a125ff ("drm/i915/psr: Program default IO buffer Wake and Fast Wake") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7725 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230221085304.3382297-1-jouni.hogander@intel.com
2023-02-23drm/i915: Drop useless intel_dp_has_audio() argumentVille Syrjälä
intel_dp_has_audio() has no need for the crtc_state, so don't pass it in. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230220151731.6852-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2023-02-23drm/i915: Fix audio ELD handling for DP MSTVille Syrjälä
I forgot to call intel_audio_compute_config() on DP MST, which means ELD doesn't get populated and passed to the audio driver. References: https://gitlab.freedesktop.org/drm/intel/-/issues/8097 Fixes: 5d986635e296 ("drm/i915/audio: Precompute the ELD") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230220151731.6852-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2023-02-23drm/i915: Mask page table errors on gen2/3 with FBCVille Syrjälä
FBC on gen2/3 seems to trigger page table errors. No visual artifacts are visible, and essentially the same FBC code works on gen4 so these seem entirely spurious. There are also hints in gen3 bspec indicating that certain bits in PGTBL_ER are just not wired up correctly in the hardware. Ideally we'd want to mask out only the bogus bits, but sadly there is no mask for PGTBL_ER, and instead we are forced to mask out all page table errors via EMR :( Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-6-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2023-02-23drm/i915: Extract {i9xx,i965)_error_mask()Ville Syrjälä
Pull the EMR calculation into small helpers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-5-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2023-02-23drm/i915: Dump PGTBL_ER on gen2/3/4 error interruptVille Syrjälä
PGTBL_ER contains the individual reasons for the page table error interrupt. Dump it out. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-4-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2023-02-23drm/i915: Undo rmw damage to gen3 error interrupt handlerVille Syrjälä
The gen2/gen3 irq code is supposed to be identical apart from the 32bit vs. 16bit access width. The recent change to intel_de_rmw() ruined that symmetry. Restore it to avoid needless mental gymnastics when comparing the two codepaths. And while at it remove the extra eir!=0 check that somehow ended up in the gen2 codepath only. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-3-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2023-02-23drm/i915: Mark FIFO underrun disabled earlierVille Syrjälä
At least on some platforms (tested on ctg) the way vgacon does screen blanking seems to flag constant FIFO underruns, which means we have to be prepared for them while the driver is loading. Currently there is a time window between drm_crtc_init() and intel_sanitize_fifo_underrun_reporting() during which FIFO underrun reporting is in fact marked as enabled. Thus we may end up mistakenly detecting these bogus underruns during driver init. Close the race by marking FIFO underrun reporting as disabled prior to even registering the crtc. intel_sanitize_fifo_underrun_reporting()/etc. will re-enable it later if needed. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-2-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2023-02-23drm/i915/audio: Track audio state per-transcoderVille Syrjälä
The audio logic lives in the transcoder rather than the pipe, so start tracking it like that. This is only really important for bigjoiner cases where tracking by pipe doesn't work at all since intel_audio_codec_{enable,disable}() won't even be called for the slave pipe. This means the state checker won't find the ELD for the slave pipe and gets upset. The PD->has_audio readout does currently work since that gets read out from the same transcoder for both pipes. For other cases this doesn't actually matter since it's only the normal pipe transcoders that are audio capable, whereas the more special transcoders (EDP/DSI) are not. v2: Fix kernel docs Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230222151454.24888-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8222
2023-02-21drm/i915/display/power: use intel_de_rmw if possibleAndrzej Hajda
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230217111836.864959-1-andrzej.hajda@intel.com
2023-02-20drm/i915: Remove pointless register readVille Syrjälä
We just wrote the EDP transcoder's VTOTAL register a few lines earlier, so instead of reading it back out again let's just generate the same value for the transocder B/C register. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-20drm/i915: Sprinkle some FIXMEs about TGL+ DSI transcoder timing messVille Syrjälä
The DSI code has some local hacks to program TRANS_VBLANK on TGL+ (ICL DSI transcoders didn't have this register). That will not work when we need to start using the delayed vblank (for DSB purposes). Too lazy to figure out what the is going on there, so just sprinkle FIXMEs in the hopes someone else will spot them eventually. v2: Only TRANS_{HBLANK,SET_CONTEXT_LATENCY} still no not exist for DSI transcoders, only TRANS_VBLANK Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-12-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2023-02-20drm/i915: Configure TRANS_SET_CONTEXT_LATENCY correctly on ADL+Ville Syrjälä
On TGL VBLANK.VBLANK_START was the mechanism by which we can delay the pipe's internal vblank in relation to the transcoder's vblank. On ADL+ that no longer does anything. Instead we must now use the new TRANS_SET_CONTEXT_LATENCY register. Program it accordingly. And since VBLANK.VBLANK_START is no longer used by the hardware on ADL+ let's just zero it out to make it stand out in register dumps. Seeing the zeroed value should hopefully remind people to check the other register instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-11-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2023-02-20drm/i915/dsb: Skip DSB command buffer setup if we have no LUTsVille Syrjälä
If we have no LUTs to load there is no point in setting up the DSB command buffer. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-9-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-20drm/i915/dsb: Nuke the DSB debugVille Syrjälä
We'll be wanting to start the DSB from the vblank evasion critical section so printk()s are a big nono. Get rid of the debug print. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-8-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-20drm/i915/dsb: Allow vblank synchronized DSB executionVille Syrjälä
Allow the caller to ask for the DSB commands to execute during vblank. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-7-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-20drm/i915/dsb: Define more DSB registersVille Syrjälä
Add definitions for more DSB registers. Less annoying spec trawling when working on the DSB code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-2-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-20drm/i915/psr: Stop clobbering TRANS_SET_CONTEXT_LATENCYVille Syrjälä
The PSR code has no business mucking around with the vblank delay. Currently nothing that depends on knowing the exact vblank start scanline (eg. vblank evasion) is aware of this and so will not work correctly. The w/a seems to be for pre-production hw only, so let's just nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-17drm/i915: Define transcoder timing register bitmasksVille Syrjälä
Define the contents of the transcoder timing registers using REG_GENMASK() & co. For ease of maintenance let's just define the bitmasks with the full 16bit width (also used by the current hand rolled stuff) even though not all bits are actually used. None of the unsued bits have ever contained anything. Jani spotted that the CRT load detection code did use narrower bitmasks, so that is now going to change. But that is fine since any garbage in the high bits would have been caught by the state checker that always used the full 16bit masks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit (git 2.34.1) at 2025-07-16 01:21:53 +0000