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 6fdb335f1c ("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: 6fdb335f1c ("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
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
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
