- 28 Apr, 2023 5 commits
-
-
Mika Kahola authored
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:
-
Mika Kahola authored
As we already do with C10 chip, let's dump the pll hw state for C20 as well. Reviewed-by:
-
Mika Kahola authored
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:Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
-
Mika Kahola authored
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:José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Bhanuprakash Modem <bhanuprakash.modem@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Hans de Goede authored
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 6fdb335f ("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: 6fdb335f ("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
-
- 27 Apr, 2023 1 commit
-
-
Suraj Kandpal authored
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:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418131425.1285088-1-suraj.kandpal@intel.com
-
- 26 Apr, 2023 1 commit
-
-
Radhakrishna Sripada authored
CPU transcoder mask is used to iterate over the available CPU transcoders in the macro for_each_cpu_transcoder(). The macro is broken on MTL and got highlighted when audio state was being tracked for each transcoder added in [1]. Add the missing CPU transcoder mask which is similar to ADL-P mask but without DSI transcoders. [1]: https://patchwork.freedesktop.org/patch/523723/ Fixes: 78353039 ("drm/i915/mtl: Add MeteorLake PCI IDs") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230420221248.2511314-1-radhakrishna.sripada@intel.com
-
- 25 Apr, 2023 1 commit
-
-
Imre Deak authored
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: 88c48793 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2") Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230424200205.1732941-1-imre.deak@intel.com
-
- 21 Apr, 2023 2 commits
-
-
Radhakrishna Sripada authored
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:
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
-
José Roberto de Souza authored
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:
-
- 20 Apr, 2023 20 commits
-
-
Fei Yang authored
On MTL, LLC is not shared between GT and CPU, set has_llc=0. Signed-off-by:
Fei Yang <fei.yang@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Signed-off-by:
-
Ville Syrjälä authored
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:
Jouni Högander <jouni.hogander@intel.com>
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
Replace some hand rolled RMW stuff with intel_de_rmw(). Signed-off-by:
-
Ville Syrjälä authored
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ä authored
Modernize a bunch of display chicken registers by using REG_BIT() & co. Signed-off-by:
-
Ville Syrjälä authored
Fix a bunch of whitespace issues in some display register definitons. Only touching the bits alerayd using REG_BIT() & co. here. The rest will come later. Signed-off-by:
-
Ville Syrjälä authored
ilk_pfit_enable() is defined before the first use. No need for a forwared declaration. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
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ä authored
Give the PFIT_CONTROL bits a consistent namespace. Signed-off-by:
-
Ville Syrjälä authored
Modernize the gmch pfit register definitions using REG_BIT/etc. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
Move intel_atomic_setup_scalers() next to the other scaler code in skl_scaler.c. Signed-off-by:
-
Ville Syrjälä authored
Move the VBLANK_EVASION_TIME_US definition to a slightly better place. Signed-off-by:
-
Ville Syrjälä authored
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/8357Signed-off-by:
-
Jani Nikula authored
An error-valued pointer can handle all in one without the wrapper struct. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417153741.1074692-2-jani.nikula@intel.com
-
Jani Nikula authored
Load detect is shared between tv and crt but otherwise isolated in intel_display.c. Signed-off-by:
-
Jani Nikula authored
The declaration was removed earlier, but got accidentally resurrected in i915xx_wm.[ch] refactoring. Remove harder. Signed-off-by:
-
- 19 Apr, 2023 4 commits
-
-
Matt Roper authored
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:
-
Matt Roper authored
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: -
Jani Nikula authored
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:
-
Imre Deak authored
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: 0f752b21 ("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:
-
- 18 Apr, 2023 5 commits
-
-
Ville Syrjälä authored
Replace the hardcoded masks with just a loop over all hpd pins using the <platform>_hotplug_mask() functions. v2: Deal with mtp Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
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 5a2376d1 ("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 41e35ffb ("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=111966Reviewed-by:
-
Ville Syrjälä authored
Add a mechanism by which we can enable the HPD sense for individual encoders. This will be used during eDP probing to figure out if anything is actually connected. The normal intel_hpd_irq_setup() thing doesn't work since we only do that after probing the outputs, and we only enable HPD sense for encoders that were successfully probed. The other idea that crossed my minds was to just turn on HPD sense for all pins before output probing and let hpd_irq_setup() clean it up afterwards. But that doesn't work for BXT/GLK where the HPD invert information comes from the VBT child device. So looks like this really needs to be per-encoder. v2: Give it a better name (Jani) v3: Deal with mtl Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v2 Signed-off-by:
-
Ville Syrjälä authored
Pair each <platform>_hotplug_enables() function with a corresponding <platform>_hotplug_mask() function so that we can determine right bits to clear on a per hpd_pin basis. We'll need this for turning on HPD sense for a specific encoder rather than just all of them. v2: Drop the unused 'i915' param (Jani) v3: Drop the _foo_hotplug_enables() redirection too v4: Deal with mtp Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v3 Signed-off-by:
-
Jani Nikula authored
Use rmw where needed. Signed-off-by:
-
- 17 Apr, 2023 1 commit
-
-
Jani Nikula authored
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:
-
