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: 88c4879384 ("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
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>
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
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 5a2376d136 ("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
41e35ffb38 ("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
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ä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-3-ville.syrjala@linux.intel.com
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
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
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
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
