summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)Author
2023-04-25drm/i915/mtl: Add PTE encode functionFei Yang
PTE encode functions are platform dependent. This patch implements PTE functions for MTL, and ensures the correct PTE encode function is used by calling pte_encode function pointer instead of the hardcoded gen8 version of PTE encode. Fixes: b76c0deef627 ("drm/i915/mtl: Define MOCS and PAT tables for MTL") Signed-off-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230424182902.3663500-2-fei.yang@intel.com
2023-04-24drm/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> (cherry picked from commit 691248d4135fe3fae64b4ee0676bc96a7fd6950c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.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/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 (cherry picked from commit 27ac123b454417ea92d77c13a5d94655f53b759c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.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-17drm/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> (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.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
2023-04-14drm/i915/mtl: Add C10 phy programming for HDMIRadhakrishna Sripada
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: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-8-radhakrishna.sripada@intel.com
2023-04-14drm/i915/mtl/display: Implement DisplayPort sequencesJosé Roberto de Souza
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: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@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-7-radhakrishna.sripada@intel.com
2023-04-14drm/i915/mtl: Add vswing programming for C10 physMika Kahola
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: Clint Taylor <Clinton.A.Taylor@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>(v3) Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-5-radhakrishna.sripada@intel.com
2023-04-14drm/i915/mtl: Add Support for C10 PHY message bus and pll programmingRadhakrishna Sripada
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: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v4) Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-4-radhakrishna.sripada@intel.com
2023-04-14drm/i915/mtl: Create separate reg file for PICA registersMika Kahola
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: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-3-radhakrishna.sripada@intel.com
2023-04-14drm/i915/mtl: Add DP ratesMika Kahola
Add DP rates for Meteorlake. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-2-radhakrishna.sripada@intel.com
2023-04-14drm/i915/debugfs: New debugfs for display clock frequenciesBhanuprakash Modem
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: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413114502.1105288-1-bhanuprakash.modem@intel.com