summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)Author
2023-04-28drm/i915/mtl: Readout Thunderbolt HW stateMika Kahola
Readout hw state for Thunderbolt. Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-9-mika.kahola@intel.com
2023-04-28drm/i915/mtl: Enabling/disabling sequence Thunderbolt pllMika Kahola
Enabling and disabling sequence for Thunderbolt PLL. Bspec: 64568 v2: Use intel_de_wait_for_register() (RK) Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-8-mika.kahola@intel.com
2023-04-28drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLAMika Kahola
Use MPLLA for DP2.0 rates 10G and 20G, when ssc is enabled. v2: Fix typo in commit message (Animesh) Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-7-mika.kahola@intel.com
2023-04-28drm/i915/mtl: Add voltage swing sequence for C20Mika Kahola
DP1.4 and DP20 voltage swing sequence for C20 phy. Bspec: 65449, 67636, 67610 Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-6-mika.kahola@intel.com
2023-04-28drm/i915/mtl: C20 port clock calculationMika Kahola
Calculate port clock with C20 phy. BSpec: 64568 Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-5-mika.kahola@intel.com
2023-04-28drm/i915/mtl: Dump C20 pll hw stateMika Kahola
As we already do with C10 chip, let's dump the pll hw state for C20 as well. Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-4-mika.kahola@intel.com
2023-04-28drm/i915/mtl: C20 HW readoutMika Kahola
Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates. The PLL settings are based on table, not for algorithmic alternative. For DP 1.4 only MPLLB is in use. Once register settings are done, we read back C20 HW state. BSpec: 64568 v2: Updated pll tables (RK) MPLLB selection fix (RK) Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-3-mika.kahola@intel.com
2023-04-28drm/i915/mtl: C20 PLL programmingMika Kahola
C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add 4 lane support for c20. v2: Add 6.48Gbps and 6.75Gbps modes for eDP (RK) Fix lane check (RK) Fix multiline commenting (Arun) use usleep_range() instead of msleep() (Andi) Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-2-mika.kahola@intel.com
2023-04-28drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep()Hans de Goede
The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have a version of 3 or newer and the panel is in vid-mode. This is based on the big comment around line 730 which starts with "Panel enable/disable sequences from the VBT spec.", where the "v3 video mode seq" column does not have any wait t# entries. Checking the Windows driver shows that it does always honor the VBT delays independent of the version of the VBT sequences. Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence") switched to a direct msleep() instead of intel_dsi_msleep() when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix the panel on an Acer Aspire Switch 10 E SW3-016 not turning on. And now testing on a Nextbook Ares 8A shows that panel_on_delay must always be honored otherwise the panel will not turn on. Instead of only always using regular msleep() for panel_on_delay do as Windows does and always use regular msleep() everywhere were intel_dsi_msleep() is used and drop the intel_dsi_msleep() helper. Changes in v2: - Replace all intel_dsi_msleep() calls instead of just the intel_dsi_msleep(panel_on_delay) call Cc: stable@vger.kernel.org Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230425194441.68086-1-hdegoede@redhat.com
2023-04-27drm/i915/display: Increase AUX timeout for Type-CSuraj Kandpal
Type-C PHYs are taking longer than expected for Aux IO Power Enabling. Workaround: Increase the timeout. ---v2 -change style on how we mention WA [Ankit] -fix bat error by creating new func that is only called for aux power well scenarios so we can avoid null pointer error as it is called everywhere. --v3 -Add non-default enable_timeout to power well descriptor which avoids adding more platform checks [Imre] --v4 -Remove Bspec link from top to bottom remove WA link from commit put it on comment [Jani] -enable_timeout in ms and add .fixed_enable_delay too [Imre] --v5 -move power_wells instead of duplicating them [Imre] Bspec: 55480 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418131425.1285088-1-suraj.kandpal@intel.com
2023-04-25drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUXImre Deak
On ADLP+ Bspec allows DC5/6 to be enabled while power well 2 is enabled. Since the AUX and DDI power wells (except for port A/B) are also backed by power well 2, this would suggest that DC5/6 can be enabled while any of these AUX or DDI port functionalities are used. As opposed to this AUX transfers will time out on ADLP TypeC ports while DC6 is enabled. Until the restriction for DC5/6 is clarified in Bspec let's assume that the intention is to allow for using these power states while pipe A/B is enabled, but only for combo ports which can be used with eDP outputs. Similarly assume that AUX transaction initiated by the driver on any port requires DC states to be disabled. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Fixes: 88c487938414 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230424200205.1732941-1-imre.deak@intel.com
2023-04-21drm/i915/mtl: Skip pcode qgv restrictions for MTLRadhakrishna Sripada
Communicating QGV points restriction to PUnit happens via PM Demand instead of the Pcode mailbox in the previous platforms. GV point restriction is handled by the PM demand code. Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230318005852.2303937-5-radhakrishna.sripada@intel.com
2023-04-20drm/i915: Initialize dkl_phy spin lock from display code pathJosé Roberto de Souza
drm/i915: Initialize dkl_phy spin lock from display code path Start moving the initialization of display locks from i915_driver_early_probe(). Display locks should be initialized from display-only code paths. It was also agreed that if a variable is only used in one file, it should be initialized only in that file, so intel_dkl_phy_init() was added. v2: - added intel_display_locks_init() v3: - rebased v4: - dropped intel_display_locks_init() v5: - moved intel_dkl_phy_init() to the beginning of file Cc: intel-gfx@lists.freedesktop.org Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230420170558.35398-1-jose.souza@intel.com
2023-04-20drm/i915/psr: Sprinkle cpu_transcoder variables aroundVille Syrjälä
Reduce the 'intel_dp' stuff a bit by introducing local cpu_transcoder variables. Ideally I'd like the whole PSR code to stop using intel_dp except during a full modeset, but dunno yet if that's possible. But the less 'intel_dp' we have sprad around the easier that should be to figure out eventually. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-9-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-04-20drm/i915/psr: Include PSR_PERF_CNT in debugfs output on all platformsVille Syrjälä
The fact that DC states reset the PSR perofrmance counter is no reason not to include it in the debug output. But let's keep the comment there to remind people about that caveat. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-8-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-04-20drm/i915/psr: Add a FIXME for the PSR vs. AUX usage conflictVille Syrjälä
We need to disable PSR when we are doing AUX by hand, otherwise it's possible that the PSR hardware could be using the AUX CH while we try to do our manual stuff. Add a FIXME for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-7-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-04-20drm/i915/psr: Define more PSR mask bitsVille Syrjälä
Define more of the PSR mask bits, and describe in detail what some of them do. Even if we don't set them all from the driver they can be very useful during PSR debugging. Having to trawl through bspec every time to find them is not fun, and re-reverse engineering the behaviour every time is time consuming (even if a bit more fun than spec trawling). v2: Moar bits Put the description into a comment to be easily available v2: Fix the BDW_UNMASK_VBL_TO_REGS_IN_SRD/HSW_UNMASK_VBL_TO_REGS_IN_SRD description Rebase due to intel_psr_regs.h Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-6-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-04-20drm/i915/psr: Use intel_de_rmw()Ville Syrjälä
Replace some hand rolled RMW stuff with intel_de_rmw(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-5-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-04-20drm/i915/psr: Clean up PSR register defininitionsVille Syrjälä
Use REG_BIT() & co. to make the PSR register definitions nicer. v2: Rebase due to intel_psr_regs.h Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-4-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-04-20drm/i915: Drop a useless forward declararionVille Syrjälä
ilk_pfit_enable() is defined before the first use. No need for a forwared declaration. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915: Use REG_BIT() & co. for ilk+ pfit registersVille Syrjälä
Polish the ilk+ pfit registers with REG_BIT() & co., and also take the opportunity to unify the ivb/hsw vs. not checks in ilk_pfit_enable() and ilk_get_pfit_config(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915: Namespace pfit registers properlyVille Syrjälä
Give the PFIT_CONTROL bits a consistent namespace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915: Use REG_BIT() & co for the pre-ilk pfit registersVille Syrjälä
Modernize the gmch pfit register definitions using REG_BIT/etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915: Relocate skl_get_pfit_config()Ville Syrjälä
Move skl_get_pfit_config() next to the other skl+ scaler code and rename it to skl_scaler_get_config() so that it has a consistnet namespace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915: Relocate intel_atomic_setup_scalers()Ville Syrjälä
Move intel_atomic_setup_scalers() next to the other scaler code in skl_scaler.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915: Relocate VBLANK_EVASION_TIME_USVille Syrjälä
Move the VBLANK_EVASION_TIME_US definition to a slightly better place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915: Check pipe source size when using skl+ scalersVille Syrjälä
The skl+ scalers only sample 12 bits of PIPESRC so we can't do any plane scaling at all when the pipe source size is >4k. Make sure the pipe source size is also below the scaler's src size limits. Might not be 100% accurate, but should at least be safe. We can refine the limits later if we discover that recent hw is less restricted. Cc: stable@vger.kernel.org Tested-by: Ross Zwisler <zwisler@google.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8357 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-20drm/i915/display: throw out struct intel_load_detect_pipeJani Nikula
An error-valued pointer can handle all in one without the wrapper struct. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417153741.1074692-2-jani.nikula@intel.com
2023-04-20drm/i915/display: split out load detect to a separate fileJani Nikula
Load detect is shared between tv and crt but otherwise isolated in intel_display.c. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417153741.1074692-1-jani.nikula@intel.com
2023-04-20drm/i915/wm: remove stale and unused ilk_wm_max_level() declarationJani Nikula
The declaration was removed earlier, but got accidentally resurrected in i915xx_wm.[ch] refactoring. Remove harder. 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/20230419115449.422214-1-jani.nikula@intel.com
2023-04-19drm/i915/mtl: Re-use ADL-P's "DC off" power wellMatt Roper
As with ADL-P, MTL's "DC off" power well should be a dependency of the PGC and PGD power wells, not the entire PG2 well. In fact, the DC5/DC6 requirements between the two platforms are the same, so the Xe_LPD "DC off" well definition can just be re-used for Xe_LPD+. Bspec: 49193 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418220446.2205509-3-radhakrishna.sripada@intel.com
2023-04-19drm/i915: Use separate "DC off" power well for ADL-P and DG2Matt Roper
Although ADL-P and DG2 both use the same general power well setup, the DC5/DC6 requirements are slightly different which means each platform should have its own "DC off" power well. DG2 (i.e., Xe_HPD IP) requires that DC5 be disabled whenever PG2 is active. However ADL-P (i.e., Xe_LPD IP) only requires DC5/DC6 to be disabled when the PGC or PGD subwells are active; we should be able to remain in these DC states when PGB and general PG2 functionality is in use. v2: Use dc_of as power well name. Move xehpd power domain definitions near power well definition.(Imre) Bspec: 49193 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418220446.2205509-2-radhakrishna.sripada@intel.com
2023-04-19drm/i915: use explicit includes for i915_reg.h and i915_irq.hJani Nikula
A lot of places include i915_reg.h implicitly via i915_irq.h, which gets included implicitly via intel_display_trace.h. Remove the includes from the headers, and include i915_reg.h and i915_irq.h explicitly where needed. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230419094243.366821-1-jani.nikula@intel.com
2023-04-19drm/i915/dp_mst: Fix active port PLL selection for secondary MST streamsImre Deak
The port PLL selection needs to be up-to-date in the CRTC state of both the primary and all secondary MST streams. The commit removing the encoder update_prepare/complete hooks (see Fixes: below), stopped doing this for secondary streams, fix this up. Fixes: 0f752b2178c9 ("drm/i915: Remove the encoder update_prepare()/complete() hooks") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8336 Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230414173800.590790-1-imre.deak@intel.com
2023-04-18drm/i915: Check HPD live state during eDP probeVille Syrjälä
We need to untangle the mess where some SKL machines (at least) declare both DDI A and DDI E to be present in their VBT, and both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a real DP->VGA converter. Currently that is handled by checking the VBT child devices for conflicts before output probing. But that kind of solution will not work for the ADL phantom dual eDP VBTs. I think on those we just have to probe the eDP first. And would be nice to use the same probe scheme for everything. On these SKL systems if we probe DDI A first (which is only natural given it's declared by VBT first) we will get an answer via AUX, but it came from the DP->VGA converter hooked to the DDI E, not DDI A. Thus we mistakenly register eDP on DDI A and screw up the real DP device in DDI E. To fix this let's check the HPD live state during the eDP probe. If we got an answer via DPCD but HPD is still down let's assume we got the answer from someone else. Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and I also tested turning off all HPD hardware prior to loading i915 to make sure it all comes up properly. And I simulated the failure path too by not turning on HPD sense and that correctly gave up on eDP. I *think* Windows might just fully depend on HPD here. I couldn't really find any other way they probe displays. And I did find code where they also check the live state prior to AUX transfers (something Imre and I have also talked about perhaps doing). That would also solve this as we'd not succeed in the eDP probe DPCD reads. Other solutions I've considered: - Reintrduce DDI strap checks on SKL. Unfortunately we just don't have any idea how reliable they are on real production hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A") does suggest that not very. Sadly that commit is very poor in details :/ Also the systems (Asrock B250M-HDV at least) fixed by commit 41e35ffb380b ("drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin") might still not work since we don't know what their straps indicate. Stupid me for not asking the reporter to check those at the time :( We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k both MS-7B54/Z370M) that also declare both DDI A and DDI E in VBT to use AUX A, and on these the DDI A strap is also set. There doesn't seem to be anything hooked up to either DDI however. But given the DDI A strap is wrong on these it might well be wrong on the Asrock too. Most other CI machines seem to have straps that generally match the VBT. fi-kbl-soraka is an exception though as DDI D strap is not set, but it is declared in VBT as a DP++ port. No idea if there's a real physical port to go with it or not. - Some kind of quirk just for the cases where both DDI A and DDI E are present in VBT. Might be feasible given we've ignored DDI A in these cases up to now successfully. But feels rather unsatisfactory, and not very future proof against funny VBTs. References: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-4-ville.syrjala@linux.intel.com
2023-04-18drm/i915/pps: use intel_de_rmw() for panel unlockJani Nikula
Use rmw where needed. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417085742.793379-1-jani.nikula@intel.com
2023-04-17drm/i915/display: add intel_display_driver_early_probe()Jani Nikula
Add intel_display_driver_early_probe() as the early probe call to replace intel_init_display_hooks(). The latter will be "demoted" to setting up hooks in intel_display.c only. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0b02311e5343527b501b44671d2188f2a1b30a7d.1681465222.git.jani.nikula@intel.com
2023-04-17drm/i915/display: rename intel_display_driver_suspend/resume functionsJani Nikula
Follow the usual naming conventions. Switch to i915 arguments and naming while at it. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cdd4228337678609967ed176dcfc9690de5d490b.1681465222.git.jani.nikula@intel.com
2023-04-17drm/i915/display: move display suspend/resume to intel_display_driver.[ch]Jani Nikula
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
2023-04-17drm/i915/display: add intel_display_reset.[ch]Jani Nikula
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: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5e98e2fc5f0c09490e02d22250c8201342852288.1681465222.git.jani.nikula@intel.com
2023-04-17drm/i915/display: rename intel_display_driver_* functionsJani Nikula
Follow the usual naming conventions. v2: - Also rename references in comments (Gustavo) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6ff7b76018bf4cf611037d7bf027c975cddfe2af.1681465222.git.jani.nikula@intel.com
2023-04-17drm/i915/display: move modeset probe/remove functions to intel_display_driver.cJani Nikula
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: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c00df5cfc233520bc28dd972296197a8a619a6a0.1681465222.git.jani.nikula@intel.com
2023-04-17drm/i915/display: rename intel_modeset_probe_defer() -> ↵Jani Nikula
intel_display_driver_probe_defer() Follow the usual naming conventions. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ab5023570d8ae55c0d9c98c78f588e51c0790b6c.1681465222.git.jani.nikula@intel.com
2023-04-17drm/i915/display: move intel_modeset_probe_defer() to intel_display_driver.[ch]Jani Nikula
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/831ed4d0356b51526704269038a6d2d72739e779.1681465222.git.jani.nikula@intel.com
2023-04-17drm/i915/display: start high level display driver fileJani Nikula
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: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e42cc037881a4c6042948a34bd4a9698f9e8487c.1681465222.git.jani.nikula@intel.com
2023-04-17drm/i915/display: remove intel_display_commit_duplicated_state()Jani Nikula
This seems like an unnecessary wrapper layer. Removing it will be helpful later. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a38f08e259221d71314ce6d764431147b0fba218.1681465222.git.jani.nikula@intel.com
2023-04-15drm/i915: Make intel_{mpllb,c10pll}_state_verify() saferVille Syrjälä
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
2023-04-14drm/i915: Make intel_get_crtc_new_encoder() less oopsyVille Syrjälä
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413200602.6037-2-ville.syrjala@linux.intel.com Fixes: 3a47ae201e07 ("drm/i915/display: Make WARN* drm specific where encoder ptr is available") Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-04-14drm/i915/mtl: Initial DDI port setupClint Taylor
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-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
2023-04-14drm/i915/display/mtl: Fill port width in ↵Ankit Nautiyal
DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI 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: Radhakrishna Sripada <radhakrishna.sripada@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
generated by cgit (git 2.34.1) at 2025-05-12 15:29:04 +0000