- 17 Apr, 2023 8 commits
-
-
Jani Nikula authored
High level display functionality only called from driver top level code. Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/11fdd82437370d8f341cd546d546de5e934c000f.1681465222.git.jani.nikula@intel.com
-
Jani Nikula authored
Split out the display reset functionality to a separate file to declutter intel_display.c. Rename the functions accordingly. The minor downside is having to expose __intel_display_resume(). Reviewed-by:
-
Jani Nikula authored
Follow the usual naming conventions. v2: - Also rename references in comments (Gustavo) Reviewed-by:
-
Jani Nikula authored
High level display functionality only called from driver top level code. v2: - Remove unnecessary declarations for intel_sanitize_watermarks() and intel_atomic_check() (Gustavo) Reviewed-by:
-
Jani Nikula authored
Follow the usual naming conventions. Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Jani Nikula authored
High level display functionality only called from driver top level code. Reviewed-by:
-
Jani Nikula authored
The only way to truly clean up intel_display.[ch] is to move stuff out of them until there's absolutely nothing left. Start moving the high level display driver entry points, i.e. functions called from top level driver code only, to a new file, which we'll call intel_display_driver.c. The intention is that there's no low-level display code or details here. This is an in-between layer. Initially, move intel_display_driver_register() and intel_display_driver_unregister() there. Reviewed-by:
-
Jani Nikula authored
This seems like an unnecessary wrapper layer. Removing it will be helpful later. Reviewed-by:
-
- 15 Apr, 2023 1 commit
-
-
Ville Syrjälä authored
intel_{mpllb,c10pll}_state_verify() blows up if you call them for a non-modeset/fastset commit on account of the relevant connector not being part of the overall atomic state. Currently the state checker only runs for modeset/fastset commits, but for testing purposes it is sometimes desirable to run it for other commits too. Check for modeset/fastset in intel_{mpllb,c10pll}_state_verify() itself to make this safe. v2: Give the new intel_c10pll_state_verify() the same treatment Add comment to explain why we do this Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230414190159.7904-1-ville.syrjala@linux.intel.com
-
- 14 Apr, 2023 12 commits
-
-
Ville Syrjälä authored
The point of the WARN was to print something, not oops straight up. Currently that is precisely what happens if we can't find the connector for the crtc in the atomic state. Get the dev pointer from the atomic state instead of the potentially NULL encoder to avoid that. Signed-off-by:
-
Clint Taylor authored
Initialization sequences and C10 phy are in place to be able to enable the first 2 ports of MTL. The other ports use C20 phy that still need to be properly added. Enable the first ports for now, keeping a TODO comment about the others. Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-10-radhakrishna.sripada@intel.com
-
Ankit Nautiyal authored
MTL requires the PORT_CTL_WIDTH, TRANS_DDI_FUNC_CTL and DDI_BUF_CTL to be filled with 4 lanes for TMDS mode. This patch enables D2D link and fills PORT_WIDTH in appropriate registers. v2: - Added fixes from Clint's Add HDMI implementation changes. - Modified commit message. v3: - Use TRANS_DDI_PORT_WIDTH() instead of DDI_PORT_WIDTH() for the value of TRANS_DDI_FUNC_CTL_*. (Gustavo) Cc: Taylor, Clinton A <clinton.a.taylor@intel.com> Signed-off-by:Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-9-radhakrishna.sripada@intel.com
-
Radhakrishna Sripada authored
Like DG2, we still don't have a proper algorithm that can be used for calculating PHY settings, but we do have tables of register values for a handful of the more common link rates. Some support is better than none, so let's go ahead and add/use these tables when we can, and also add some logic to hdmi_port_clock_valid() to filter the modelist to just the modes we can actually support with these link rates. Hopefully we'll have a proper / non-encumbered algorithm to calculate these registers by the time we upstream and we'll be able to replace this patch with something more general purpose. Bspec: 64568 v2: Rebasing with Clint's HDMI C10 PLL tables (Mika) v3: Remove the extra hdmi clock check pruning. Cc: Imre Deak <imre.deak@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
José Roberto de Souza authored
The differences between MTL and TGL DP sequences are big enough to MTL have its own functions. Also it is much easier to follow MTL sequences against spec with its own functions. One change worthy to mention is the move of 'intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain)'. This call is not necessary for MTL but we have _put() counter part in intel_ddi_post_disable_dp() that needs to balanced. We could add a display version check on it but instead here it is moving it to intel_ddi_pre_enable_dp() so it is executed for all platforms in a single place and this will not cause any harm in MTL and newer platforms. v2: - Fix logic to wait for buf idle. - Use the right register to wait for ddi active.(RK) v3: - Increase wait timeout for ddi buf active (Mika) v4: - Increase idle timeout for ddi buf idle (Mika) v5: use rmw in mtl_disable_ddi_buf. Donot clear link training mask(Imre) BSpec: 65448 65505 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Satyeshwar Singh <satyeshwar.singh@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Mika Kahola authored
PICA is used for DP alt mode and TBT modes. Hotplug interruption is routed from PICA chip to south display engine and from there to north display engine. This patch adds functionality to enable hotplug detection for all Type-C ports (4 ports available). Differently from HPD in south display, PICA provides a dedicated HPD control register for each supported port, so we loop over ports ourselves instead of using intel_hpd_hotplug_enables() or intel_get_hpd_pins(). BSpec: 49305, 55726, 65107, 65300 Reviewed-by:
Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by:
-
Mika Kahola authored
C10 phys uses direct mapping internally for voltage and pre-emphasis levels. Program the levels directly to the fields in the VDR Registers. Bspec: 65449 v2: From table "C10: Tx EQ settings for DP 1.4x" it shows level 1 and preemphasis 1 instead of two times of level 1 preemphasis 0. Fix this in the driver code as well. v3: VSwing update (Clint) v4: Add vboost termination ctl programming(Imre) Fix tx llogic and other nits Restrict C10 vdr ctl register access for C10 phy(RK) v5: Program vboots, termination ctl for both lanes(Imre) Cc: Imre Deak <imre.deak@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: -
Radhakrishna Sripada authored
XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy has a dedicated PIPE 5.2 Message bus for configuration. This message bus is used to configure the phy internal registers. XELPDP has C10 phys to drive output to the EDP and the native output from the display engine. Add structures, programming hardware state readout logic. Port clock calculations are similar to DG2. Use the DG2 formulae to calculate the port clock but use the relevant pll signals. Note: PHY lane 0 is always used for PLL programming. Add sequences for C10 phy enable/disable phy lane reset, powerdown change sequence and phy lane programming. Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636 v2: Squash patches related to C10 phy message bus and pll programming support (Jani) Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani) Move macro definitions (Jani) DP rates as separate patch (Jani) Spin out xelpdp register definitions into a separate file (Jani) Replace macro to select registers based on phy lane with function calls (Jani) Fix styling issues (Jani) Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas) v3: Move clear request flag into try-loop v4: On PHY idle change drm_err_once() as drm_dbg_kms() (Jani) use __intel_de_wait_for_register() instead of __intel_wait_for_register and uncomment intel_uncore.h (Jani) Add DP-alt support for PHY lane programming (Khaled) v4: Add tx and cmn on c10mpllb_state (Imre) Add missing waits for pending transactions between two message bus writes (Imre) General cleanups and simplifications (Imre) v5: Few nit cleanups from rev4 (imre) s/dev_priv/i915/ , s/c10mpllb/c10pll/ (RK) Rebase v6: Move the mtl code from intel_c10pll_calc_port_clock to mtl function Fix typo in comment for REG_FIELD_PREP8 definition(Imre) Cc: Mika Kahola <mika.kahola@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: -
Mika Kahola authored
Create a separate file to store registers for PICA chips C10 and C20. v2: Rename file (Jani) v3: Use _PICK_EVEN_2RANGES() macro (Lucas) Coding style fixed (Lucas) v4: Redefine macros (Imre) Reviewed-by:Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by:
-
Mika Kahola authored
Add DP rates for Meteorlake. Reviewed-by:
-
Jani Nikula authored
The goal has been to just make device info a pointer to static const data, i.e. the static const structs in i915_pci.c. See [1]. However, there were issues with intel_device_info_runtime_init() clearing the display sub-struct of device info on the !HAS_DISPLAY() path, which consequently disables a lot of display functionality, like it should. Looks like we'd have to cover all those paths, and maybe sprinkle HAS_DISPLAY() checks in them, which we haven't gotten around to. In the mean time, hide mkwrite_device_info() better within intel_device_info.c by adding a intel_device_info_driver_create() for the very early initialization of the device info and initial runtime info. This also lets us declutter i915_drv.h a bit, and stops promoting mkwrite_device_info() as something that could be used. [1] https://lore.kernel.org/r/a0422f0a8ac055f65b7922bcd3119b180a41e79e.1655712106.git.jani.nikula@intel.comSigned-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411105643.292416-1-jani.nikula@intel.com
-
Bhanuprakash Modem authored
Instead of mixing display & non-display stuff together, move display specific clock info to new debugfs. This patch will create a new debugfs "i915_cdclk_info" to expose Current & Max cdclk and Max pixel clock frequency info. Example: $ cat /sys/kernel/debug/dri/0/i915_cdclk_info Current CD clock frequency: 163200 kHz Max CD clock frequency: 652800 kHz Max pixel clock frequency: 1305600 kHz V2: - s/i915_display_clock_info/i915_cdclk_info/ (Jani) - Move the logic to intel_cdclk.c (Jani) - Don't remove info from i915_frequency_info (Jani) V3: - Drop locking (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:Bhanuprakash Modem <bhanuprakash.modem@intel.com> Reviewed-by:
-
- 13 Apr, 2023 5 commits
-
-
Ville Syrjälä authored
Most places in the vblank code use min() to clamp scanline counters below vtotal. But we missed one in the gen3/4 pixel counter based codepath. Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
-
Ville Syrjälä authored
The transcoder M/N values are double buffered on the transcoder's undelayed vblank. So when doing seamless M/N fastsets we need to evade also that. Note that currently the pipe's delayed vblank == transcoder's undelayed vblank, so this is still a nop change. But in the future when we may have to delay the pipe's vblank to create a register programming window ("window2") for the DSB. Signed-off-by: -
Ville Syrjälä authored
If the panel supports VRR it must be capable of accepting timings with arbitrary vblank length, within the valid VRR range. Use that fact to allow the user to request any refresh rate they like. We simply pick the next highest fixed mode from our list, and adjust the vblank to get the desired refresh rate in the end. Of course currently everything to do with the vrefresh is using 1Hz precision, so might not be exact. But we can improve that in the future by just upping our vrefresh precision. Signed-off-by:
-
Chaitanya Kumar Borah authored
Replace _PLANE_INPUT_CSC_RY_GY_2_* with _PLANE_CSC_RY_GY_2_* for Plane CSC Fixes: 6eba56f6 ("drm/i915/pxp: black pixels on pxp disabled") Cc: <stable@vger.kernel.org> Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230330150104.2923519-1-chaitanya.kumar.borah@intel.com
-
Ville Syrjälä authored
If we have to force the hardware to go through a full modeset due to eg. cdclk reprogramming, we need to preserve crtc_state->inherited for all crtcs that have not otherwise gone through the whole compute_config() stuff after connectors have been detected. Otherwise eg. cdclk induced modeset glk_force_audio_cdclk() will clear the inherited flag, and thus the first real commit coming from userspace later on will not be forced through the full .compute_config() path and so eg. audio state may not get properly recomputed. But instead of adding all kinds of ad-hoc crtc_state->inherited preservation hacks all over, let's change things so that we only clear it for the crtcs directly included in userspace/client initiated commits. Should be far less fragile since now we just need to remember to flag the internal commits, and not worry about where new crtcs might get pulled in. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5260Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
- 12 Apr, 2023 7 commits
-
-
Ville Syrjälä authored
Now that VRR enable/disable are called from convenient places it is trivial to allow it to change state during fastsets. Make it so. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7542Signed-off-by:
-
Ville Syrjälä authored
Move VRR enabling/disabling into a place where it also works for fastsets. With this we always start the transcoder up in non-VRR mode. Granted we already did that but for a very short period of time. But now that we might end up doing a bit more with the transcoder in non-VRR mode it seems prudent to also update the active timings as the transcoder changes its operating mode. crtc_state->vrr.enable still tracks whether VRR is actually enabled or not, but now we configure all the other VRR timing registers whenever VRR is possible (whether we actually enable it or not). crtc_state->vrr.flipline can now serve as our "is VRR possible" bit of state. I decided to leave the MSA timing ignore bit set all the time whether VRR is actually enabled or not. If the sink can figure out the timings with that information when VRR is active then surely it can also do it when VRR is inactive. v2: Protect intel_vrr_set_transcoder_timings() with HAS_VRR() Signed-off-by:
-
Ville Syrjälä authored
In order to move VRR enable/disable to a place where it's also applicable to fastsets we need to be prepared to configure the pipe into non-VRR mode initially, and then later switch to VRR mode. To that end allow the active timings to be configured in non-VRR mode temporarily even when the crtc_state says we're going to be using VRR. Signed-off-by:
-
Ville Syrjälä authored
On adl/dg2 a chicken bit needs to be set for TRANS_SET_CONTENXT_LATENCY to take effect in VRR mode. Can't really think of a reason why we'd ever disable that chicken bit, so let's just always set it. Signed-off-by:
-
Ville Syrjälä authored
Some of the VRR functions take redundant arguments. Get rid of them to make life simpler. Signed-off-by:
-
Ville Syrjälä authored
I want to use the same logic that planes_{enabling,disabling}() are using for other features as well. Generlize the thing into a pair of macros. Signed-off-by: -
Jani Nikula authored
Leftovers from before display debugfs was separated to its own file. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411131922.401602-1-jani.nikula@intel.com
-
- 11 Apr, 2023 7 commits
-
-
Ville Syrjälä authored
Have the state checker validate that the csc matrices look correct when read back from the hardware. Signed-off-by:
-
Ville Syrjälä authored
Include the csc matrices in the state dump. The format being hardware specific we just dump as hex for now. Might have to think of some way to get a bit more human readable output... Signed-off-by:
-
Ville Syrjälä authored
Read out the csc matrix on chv, and stash the result into the correct spot in the crtc state. Signed-off-by:
-
Ville Syrjälä authored
Read out the pipe/output csc matrices on ilk+ and stash the results (in the hardware specific format) into the appropriate place in the crtc state. Note that on skl/glk/icl the pipe csc unit suffers from an issue where *reads* of the coefficient/offset registers also disarm the double buffer update (if currently armed via CSC_MODE write). So it's rather important that the readout only happens after the csc registers have been latched. Fortunately the state checker only runs after the start of vblank where the latching happens. And on skl/glk the DMC + CSC register read has the potential to corrupt the latched CSC register values, so let's add a comment reminding us that the DC states should remain off until the readout has been completed. TODO: maybe we could somehow check to make sure PSR has in fact latched the new register values already, and that DC states have been off all along? Signed-off-by:
-
Ville Syrjälä authored
Make sure the csc enable bit(s) match the way we're about to fill the csc matrices. Signed-off-by:
-
Ville Syrjälä authored
Store the chv cgm csc matrix in the crtc state as well. We shall store it in the same place where we store the ilk+ pipe csc matrix (as opposed to the output csc matrix). Signed-off-by:
-
Ville Syrjälä authored
Embed a pair of intel_csc_matrix structs in the crtc state, and fill them out appropriately during atomic_check(). Since pre-ivb platforms don't have programmable post offsets we shall leave those zeroed, mainly in preparation for state readout+check. Signed-off-by:
-
