- 20 Apr, 2023 15 commits
-
-
Ville Syrjälä authored
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.comReviewed-by:
Jouni Högander <jouni.hogander@intel.com>
-
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:
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
-
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:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230419094243.366821-1-jani.nikula@intel.com
-
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:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230414173800.590790-1-imre.deak@intel.com
-
- 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:
Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-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:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
-
- 17 Apr, 2023 10 commits
-
-
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:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
Jani Nikula authored
Follow the usual naming conventions. Switch to i915 arguments and naming while at it. Reviewed-by:
-
Jani Nikula authored
High level display functionality only called from driver top level code. Reviewed-by:
-
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:
-
- 14 Apr, 2023 5 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:
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:
-
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:
-
