In case we have multiple modesets for different connectors
happening in parallel we could have a race on the RMW on these
shared registers.
This possibility was initially raised by Paulo when reviewing
commit '555e38d27317 ("drm/i915/cnl: DDI - PLL mapping")'
but the original possibility comes from commit '5416d871136d
("drm/i915/skl: Set the eDP link rate on DPLL0")'. Or maybe
later when atomic commits entered into picture.
Apparently the discussion around this topic showed that the
right solution would be on serializing the atomic commits in
a way that we don't have the possibility of races here since
if that parallel modeset happenings apparently many other
things will be on fire.
Code is there since SKL and there was no report of issue,
but since we never looked back to that serialization possibility,
and also we don't have an igt case for that it is better to at
least protect this corner.
Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Fixes: 555e38d273 ("drm/i915/cnl: DDI - PLL mapping")
Fixes: 5416d87113 ("drm/i915/skl: Set the eDP link rate on DPLL0")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20171215224310.19103-1-rodrigo.vivi@intel.com
(cherry picked from commit 8edcda1266)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
SKL DDI B/C/D only have 9 usable buf trans registers for DP/eDP. That
matches the normal DP buf trans tables, but the low vswing eDP tables
have 10 entries. Thus the eDP tables can only be used safely with DDI A
and E.
We try to catch cases where DDI B/C/D gets used with the wrong number of
entires in some parts of the code, but not everywhere. Let's move the
code to deal with that deeper into intel_ddi_get_buf_trans_edp(). And
for sake of symmetry do the same in intel_ddi_get_buf_trans_dp(). That
would also avoid explosions in the rather unlikely case that the DP
tables would get revised to 10 entries as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-9-ville.syrjala@linux.intel.com
Reviewed-by: James Ausmus <james.ausmus@intel.com>
One of the recent changes introduced a warning about
undefined behavior in the sanity checking:
drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_ddi_hdmi_level':
drivers/gpu/drm/i915/intel_ddi.c:654:6: error: 'n_hdmi_entries' may be used uninitialized in this function [-Werror=maybe-uninitialized]
It seems that the new cnl specific get_buf_trans functions
can return uninitialized data if the voltage level is set
to an unexpected value. This changes the code to always return
'1' in that error case, which seems like the safest choice
as we use one less than the number as an array index later on.
Fixes: cc9cabfdec ("drm/i915/cnl: Move voltage check into ddi buf trans functions.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[danvet: shut up gcc comment added.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171005120835.437022-1-arnd@arndb.de
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: e93da0a013 ("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
Sequences for DisplayPort asks us to
" Configure voltage swing and related IO settings.
Refer to DDI Buffer section."
before "Configure and enable DDI_BUF_CTL"
On BXT and CNL this means to execute the ddi vswing sequences.
At this point these sequences calls are getting duplicated for DP
because they are all called from DP link trainning sequences.
However this patch is not yet removing it before a futher discussion
since spec also allows that during link training without disabling
anything:
"
Notes
Changing voltage swing during link training:
Change the swing setting following the DDI Buffer section.
The port does not need to be disabled.
"
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-4-rodrigo.vivi@intel.com
The enable/disable/etc. encoder hooks aren't supposed to alter the
state(s), so pass them as const. Unfortunately C lacks any kind of deep
const thingy, so this can't catch all abuses. But at least it acts as a
hint to the reader telling them not to mess about with the state(s).
v2: Update intel_tv_mode_find() and ironlake_edp_pll_on() as well
v3: Deal with intel_sdvo_connector_state
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-9-ville.syrjala@linux.intel.com
Disabling the video DIP when shutting the port down seems like a good
idea.
Bspec says:
"When disabling both the DIP port and DIP transmission,
first disable the port and then disable DIP."
and
"Restriction : GCP is only supported with HDMI when the bits per color is
not equal to 8. GCP must be enabled prior to enabling TRANS_DDI_FUNC_CTL
for HDMI with bits per color not equal to 8 and disabled after disabling
TRANS_DDI_FUNC_CTL"
So let's do it in the .post_disable() hook.
v2: Remove double "dpms off" caused by rebase fail
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170822140914.24413-1-ville.syrjala@linux.intel.com
For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
Use the correct table.
The error was pointed out by this clang warning:
drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
static const struct cnl_ddi_buf_trans cnl_ddi_translations_edp_0_85V[] = {
Fixes: cf54ca8bc5 ("drm/i915/cnl: Implement voltage swing sequence.")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170717195854.192139-1-mka@chromium.org
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR420 outputs.
- Adds readouts to compare HW and SW states.
V2: rebase
V3: rebase
V4: rebase
V5: added r-b from Ander
V6: Handle only YCBCR420 outputs (ville)
V7: rebase
V8: Addressed review comments from Ville
- Add readouts for state->ycbcr420 and 420 pixel_clock.
- Handle warning due to mismatch in clock for ycbcr420 clock.
- Rename PIPEMISC macros to match the Bspec.
- Add a debug print stating if YCBCR 4:2:0 output enabled.
Added r-b from Ville
V9: Addressed review comments from Imre:
- Add 420 mode clock adjustment in intel_hdmi_mode_valid to
prevent 420_only modes getting rejected for high clock.
- Add port clock adjustment for ycbcr420 modes in ddi_get_clock
- Rename macros as per Ville's suggestion.
- Remove unnecessary wl changes.
V10: Added r-b from Imre
V11: Fixed faulty dotclock handling, and addressed missing comment
from previous set of review comments (Imre)
V12: Fixed dotclock for 12bpc too, removed 420 check for GEN < 10
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500904172-31717-1-git-send-email-shashank.sharma@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
