summaryrefslogtreecommitdiff
path: root/init/Makefile
diff options
context:
space:
mode:
authorImre Deak <imre.deak@intel.com>2017-10-02 16:53:07 +0300
committerRodrigo Vivi <rodrigo.vivi@intel.com>2017-10-03 13:47:29 -0700
commit71300132975f364a0d3ebf68671a2ce4923191db (patch)
tree6d2dd3ee346b079b98a941b9a558d209eb20770d /init/Makefile
parent2ba7d7e0437127314864238f8bfcb8369d81075c (diff)
drm/i915: Fix DDI PHY init if it was already on
The common lane power down flag of a DPIO PHY has a funky semantic: after the initial enabling of the PHY (so from a disabled state) this flag will be clear. It will be set only after the PHY will be used for the first time (for instance due to enabling the corresponding pipe) and then become unused (due to disabling the pipe). During the initial PHY enablement we don't know which of the above phases we are in, so move the check for the flag where this is known, the HW readout code. This is where the rest of lane power down status checks are done anyway. This fixes at least a problem on GLK where after module reloading, the common lane power down flag of PHY1 is set, but the PHY is actually powered-on and properly set up. The GRC readout code for other PHYs will hence think that PHY1 is not powered initially and disable it after the GRC readout. This will cause the AUX power well related to PHY1 to get disabled in a stuck state, timing out when we try to enable it later. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Fixes: e93da0a0137b ("drm/i915/bxt: Sanitiy check the PHY lane power down status") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102777 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171002135307.26117-1-imre.deak@intel.com (cherry picked from commit e19c1eb885ac4186e64c7e484424124f3145318e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Diffstat (limited to 'init/Makefile')
0 files changed, 0 insertions, 0 deletions