The hardware is not guaranteed to be enabled during execution of the
tegra_sor_init() function, which can lead to a crash on some Tegra SoCs.
Fix this by moving all register programming into code that is guaranteed
to only be executed when the hardware is enabled.
Signed-off-by: Thierry Reding <treding@nvidia.com>
During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. After
all other drivers have been converted not to use these helpers anymore,
move these helpers into the last remaining user: Tegra DRM.
If at some point these helpers are deemed more widely useful, they can
be moved out into the DRM DP helpers again.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-14-thierry.reding@gmail.com
Use microsecond sleeps for the clock recovery and channel equalization
delays during link training. The duration of these delays can be from
100 us up to 16 ms. It is rude to busy-loop for that amount of time.
While at it, also convert to standard coding style by putting the
opening braces in a function definition on a new line. Also switch to
using an unsigned int for the AUX read interval to match the data type
of the parameters to usleep_range().
v2: use correct multiplier for training delays (Philipp Zabel)
v3: clarify data type change in commit message
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-7-thierry.reding@gmail.com
Parroting Daniel's backmerge justification from
2e79e22e09:
Thierry needs fd70c7755b ("drm/bridge: tc358767: fix max_tu_symbol
value") to be able to merge his dp_link patch series.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Thierry needs fd70c7755b ("drm/bridge: tc358767: fix max_tu_symbol
value") to be able to merge his dp_link patch series.
Some adjacent changes conflicts, plus some clashes in i915 due to
cherry-picking and git trying to be helpful and leaving both versions
in.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is not something we'll fix, because failing to clean up stuff (or
doing it in the wrong order) is a driver bug. The offending FIXME goes
all the way back to the original modeset merge.
We've added a WARN_ON in
commit 2b677e8c08
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Dec 10 21:16:05 2012 +0100
drm: reference framebuffers which are on the idr
including a comment blaming drivers on this. Right thing to do is most
likely drm_atomic_helper_shutdown plus making sure that
drm_mode_config_cleanup is not called too early (i.e. not in driver
unload, but only in the final drm_device release callback).
Cc: Mihail Atanassov <Mihail.Atanassov@arm.com>
Reported-by: Mihail Atanassov <Mihail.Atanassov@arm.com>
Reviewed-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022163717.1064-1-daniel.vetter@ffwll.ch
As per the display enable sequence, we need to follow the enable sequence
for slaves first with DP_TP_CTL set to Idle and configure the transcoder
port sync register to select the corersponding master, then follow the
enable sequence for master leaving DP_TP_CTL to idle.
At this point the transcoder port sync mode is configured and enabled
and the Vblanks of both ports are synchronized so then set DP_TP_CTL
for the slave and master to Normal and do post crtc enable updates.
v11:
* Rebase (Manasi)
v10:
* in trans sync mode, dont stop link train for tgl (Manasi)
v9:
Remove update_scanline_offset to rebase on Maarten's patch (Manasi)
v8:
* Rebase on Maarten's patches (Manasi)
v7:
* Use ffs(slaves) to get slave crtc (Ville)
v6:
* Modeset implies active_changed, remove one condition (Maarten)
v5:
* Fix checkpatch warning (Manasi)
v4:
* Reuse skl_commit_modeset_enables() hook (Maarten)
* Obtain slave crtc and states from master (Maarten)
v3:
* Rebase on drm-tip (Manasi)
v2:
* Create a icl_update_crtcs hook (Maarten, Danvet)
* This sequence only for CRTCs in trans port sync mode (Maarten)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018172725.1338-4-manasi.d.navare@intel.com
After the state is committed, we readout the HW registers and compare
the HW state with the SW state that we just committed.
For Transcdoer port sync, we add master_transcoder and the
salves bitmask to the crtc_state, hence we need to read those during
the HW state readout to avoid pipe state mismatch.
v11:
* Move master trans init to get pipe_Config hooks (Ville)
v10:
* Initialize master_tarnscoder readout for all platforms (Ville)
v9:
* Initialize master_transcoder = INVALID at get config (Ville)
v8:
* Use master_select -1, address TRANS_EDP case (Ville)
* Rename master_transcoder to _readout (Lucas)
v7:
* NDont read HW state for DSI
v6:
* Go through both parts of HW readout (Maarten)
* Add a WARN if the same trans configured as
master and slave (Ville, Maarten)
v5:
* Add return INVALID in defaut case (Maarten)
v4:
* Get power domains in master loop for get_config (Ville)
v3:
* Add TRANSCODER_D (Maarten)
* v3 Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
v2:
* Add Transcoder_D and MISSING_CASE (Maarten)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018172725.1338-3-manasi.d.navare@intel.com
In case of tiled displays where different tiles are displayed across
different ports, we need to synchronize the transcoders involved.
This patch implements the transcoder port sync feature for
synchronizing one master transcoder with one or more slave
transcoders. This is only enbaled in slave transcoder
and the master transcoder is unaware that it is operating
in this mode.
This has been tested with tiled display connected to ICL.
v7:
* Rebase on Maarten's patches
v6:
* Use master_trans +1 and address missing trans_edp case (Ville)
v5:
* Add TRANSCODER_D case and MISSING_CASE (Maarten)
v4:
Rebase
v3:
* Check of DP_MST moved to atomic_check (Maarten)
v2:
* Do not use RMW, just write to the register in commit (Jani N)
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018172725.1338-2-manasi.d.navare@intel.com
In case of tiled displays when the two tiles are sent across two CRTCs
over two separate DP SST connectors, we need a mechanism to synchronize
the two CRTCs and their corresponding transcoders.
So use the master-slave mode where there is one master corresponding
to last horizontal and vertical tile that needs to be genlocked with
all other slave tiles.
This patch identifies saves the master transcoder in all the slave
CRTC states. This is needed to select the master CRTC/transcoder
while configuring transcoder port sync for the corresponding slaves.
v6:
Rebase (manasi)
v5:
* Address Ville's comments
* Just pass crtc_state, no need to check GEN (Ville)
v4:
* Rebase
v3:
* Use master_tramscoder instead of master_crtc for valid
HW state readouts (Ville)
v2:
* Move this to intel_mode_set_pipe_config(Jani N, Ville)
* Use slave_bitmask to save associated slaves in master crtc state (Ville)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018172725.1338-1-manasi.d.navare@intel.com
Commit 2d6f6f359f ("drm/i915: add i915_driver_modeset_remove()")
claimed removal of asymmetry in probe() and remove() calls, however, it
didn't take care of calling intel_irq_uninstall() on driver remove.
That doesn't hurt as long as we still call it from
intel_modeset_driver_remove() but in order to have full symmetry we
should call it again from i915_driver_modeset_remove().
Note that it's safe to call intel_irq_uninstall() twice thanks to
commit b318b82455 ("drm/i915: Nuke drm_driver irq vfuncs"). We may
only want to mention the case we are adding in a related FIXME comment
provided by that commit. While being at it, update the name of
function mentioned as calling it out of sequence as that name has been
changed meanwhile by commit 78dae1ac35 ("drm/i915: Propagate
"_remove" function name suffix down").
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/6250061.7lZMOAyebC@jkrzyszt-desk.ger.corp.intel.com
Extract drm_mode_hdmi_vic() to correctly calculate the final HDMI
VIC for us. Currently this is being done a bit differently between
the AVI and HDMI infoframes. Let's get both to agree on this.
We need to allow the case where a mode is both 3D and has a HDMI
VIC. Currently we'll just refuse to generate the HDMI infoframe when
we really should be setting HDMI VIC to 0 and instead enabling 3D
stereo signalling.
If the sink doesn't even support the HDMI infoframe we should
not be picking the HDMI VIC in favor of the CEA VIC, because then
we'll end up not sending either VIC in the end.
Cc: Wayne Lin <waynelin@amd.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004141914.20600-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
