Depending on the transcoder enum values to translate from transcoder
to pipe/transcoder register addresses can easily break if we add a new
transcoder. So remove the dependency by using named initializers.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181120092325.21249-1-imre.deak@intel.com
Like it was done in commit 9e180d9991 ("drm/i915: Downgrade unknown
firmware warnings") for huc and guc: downgrade CSR firmware warnings. If
we have released no firmware yet for a platform, stop scaring the
consumer and merely note its expected absence.
By simply removing the warning and early return we hit the condition
with the appropriate message.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181117004234.23437-2-lucas.demarchi@intel.com
Before commit d8a5b7d79f ("drm/i915/csr: keep max firmware size together
with firmare name and version") it was possible to load the firmware for
testing purposes via parameter. Let's use the size of the last known
platform to recover that behavior.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181117004234.23437-1-lucas.demarchi@intel.com
Clean up fixed point temp variable initialization, use the more
conventional tmp name for temp variables, add empty lines before
return. No functional changes.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181116120729.7580-5-jani.nikula@intel.com
Under moderate amounts of GPU stress, we can observe on Bearlake and
Pineview (later gen3 models) that we execute the following batch buffer
before the write into the batch is coherent. Adding extra (tested with
upto 32x) MI_FLUSH to either the invalidation, flush or both phases does
not solve the incoherency issue with the relocations, but emitting the
MI_STORE_DWORD_IMM twice does. So be it.
Fixes: 7dd4f6729f ("drm/i915: Async GPU relocation processing")
Testcase: igt/gem_tiled_fence_blits # blb/pnv
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181119154153.15327-1-chris@chris-wilson.co.uk
Since capturing the error state requires fiddling around with the GGTT
to read arbitrary buffers and is itself run under stop_machine(), it
deadlocks the machine (effectively a hard hang) when run in conjunction
with Broxton's VTd workaround to serialize GGTT access.
v2: Store the ERR_PTR in first_error so that the error can be reported
to the user via sysfs.
v3: Mention the quirk in dmesg (using info as per usual)
Fixes: 0ef34ad622 ("drm/i915: Serialize GTT/Aperture accesses on BXT")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: John Harrison <john.C.Harrison@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102161232.17742-5-chris@chris-wilson.co.uk
Hide the enable_gvt modparam in the default scenario where
support has not been compiled in.
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181116144447.7836-1-joonas.lahtinen@linux.intel.com
New features for 4.21:
amdgpu:
- Support for SDMA paging queue on vega
- Put compute EOP buffers into vram for better performance
- Share more code with amdkfd
- Support for scanout with DCC on gfx9
- Initial kerneldoc for DC
- Updated SMU firmware support for gfx8 chips
- Rework CSA handling for eventual support for preemption
- XGMI PSP support
- Clean up RLC handling
- Enable GPU reset by default on VI, SOC15 dGPUs
- Ring and IB test cleanups
amdkfd:
- Share more code with amdgpu
ttm:
- Move global init out of the drivers
scheduler:
- Track if schedulers are ready for work
- Timeout/fault handling changes to facilitate GPU recovery
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114165113.3751-1-alexander.deucher@amd.com
UAPI Changes:
- Add syncobj timeline support to drm.
Cross-subsystem Changes:
- Remove shared fence staging in dma-buf's fence object, and allow
reserving more than 1 fence and add more paranoia when debugging.
- Constify infoframe functions in video/hdmi.
Core Changes:
- Add vkms todo, and a lot of assorted doc fixes.
- Drop transitional helpers and convert drivers to use drm_atomic_helper_shutdown().
- Move atomic state helper functions to drm_atomic_state_helper.[ch]
- Refactor drm selftests, and add new tests.
- DP MST atomic state cleanups.
- Drop EXPORT_SYMBOL from drm leases.
- Lease cleanups and fixes.
- Create render node for vgem.
Driver Changes:
- Fix build failure in imx without fbdev emulation.
- Add rotation quirk for GPD win2 panel.
- Add support for various CDTech panels, Banana Pi Panel, DLC1010GIG,
Olimex LCD-O-LinuXino, Samsung S6D16D0, Truly NT35597 WQXGA,
Himax HX8357D, simulated RTSM AEMv8.
- Add dw_hdmi support to rockchip driver.
- Fix YUV support in vc4.
- Fix resource id handling in virtio.
- Make rockchip use dw-mipi-dsi bridge driver, and add dual dsi support.
- Advertise that tinydrm only supports DRM_FORMAT_MOD_LINEAR.
- Convert many drivers to use atomic helpers, and drm_fbdev_generic_setup().
- Add Mali linear tiled formats, and enable them in the Mali-DP driver.
- Add support for H6 DE3 mixer 0, DW HDMI, HDMI PHY and TCON TOP.
- Assorted driver cleanups and fixes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAlvi0eAACgkQ/lWMcqZw
E8PI3g//TIlMmbrUc6BrWCNnz4YpJ+mC2dq7HMYB4yf5QeXTYrRDqK6syakbGcbe
FGYxt+21REfyQ9IQPdQslmVIUqJZuMBFSvLjXnZvybJSllE23CAXG0hEwHTuPYiF
yzxmYwlYOxVlW0nnB3fEDM8BfbWyMYR03c4sobPgiAGoBd+CJif/BtKEwranYrRx
7rZh8PnrCPGAnewmYux6U4zkOpWyjUp5t3kqpNRJDxPfxpa991yvUJX3DxTFFr9b
nqYNp3F3fkdowYuJj2eH/uBNd17TouzITGQxIZWEsJfFvB+2Awp7KgRCT8nUAt0I
vELbADsy3QwZlQp1F2FaVwfGbmHr41F+Vsq9coUt4vPaiyT3vCW0KGCeal1dKyYf
+S8UXIijkoGXm0RqxkbkJsG7AYSIzG+NQm6W+9tnQg6CwpQb2wqU3YCPQWqtFHqM
Tz/EW+JqG5Wl1aHXVEbnSajtqT2ooskwHfy81iwNqaGwVy+ZSLIZpqC91Hk9SyZ9
HBDuKWSzqEqXWf7nwbOTm0umQ9mk8+I41k+dyqc2fq9z/gySqKd32eC3aLa0/p3y
6bngvu1TT6jNhRdduwxgl/Y5cnQp/Zg9wYRKmAjViZtooaWj8p2o45AufGz1rplR
BdYVUOPofVVD9ShwxayWzuocFW/HbgYc7FHHgKUFgFBO5iC/A2s=
=UV0m
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2018-11-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v4.21, part 1:
UAPI Changes:
- Add syncobj timeline support to drm.
Cross-subsystem Changes:
- Remove shared fence staging in dma-buf's fence object, and allow
reserving more than 1 fence and add more paranoia when debugging.
- Constify infoframe functions in video/hdmi.
Core Changes:
- Add vkms todo, and a lot of assorted doc fixes.
- Drop transitional helpers and convert drivers to use drm_atomic_helper_shutdown().
- Move atomic state helper functions to drm_atomic_state_helper.[ch]
- Refactor drm selftests, and add new tests.
- DP MST atomic state cleanups.
- Drop EXPORT_SYMBOL from drm leases.
- Lease cleanups and fixes.
- Create render node for vgem.
Driver Changes:
- Fix build failure in imx without fbdev emulation.
- Add rotation quirk for GPD win2 panel.
- Add support for various CDTech panels, Banana Pi Panel, DLC1010GIG,
Olimex LCD-O-LinuXino, Samsung S6D16D0, Truly NT35597 WQXGA,
Himax HX8357D, simulated RTSM AEMv8.
- Add dw_hdmi support to rockchip driver.
- Fix YUV support in vc4.
- Fix resource id handling in virtio.
- Make rockchip use dw-mipi-dsi bridge driver, and add dual dsi support.
- Advertise that tinydrm only supports DRM_FORMAT_MOD_LINEAR.
- Convert many drivers to use atomic helpers, and drm_fbdev_generic_setup().
- Add Mali linear tiled formats, and enable them in the Mali-DP driver.
- Add support for H6 DE3 mixer 0, DW HDMI, HDMI PHY and TCON TOP.
- Assorted driver cleanups and fixes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/be7ebd91-edd9-8fa4-4286-1c57e3165113@linux.intel.com
If we have released no firmware yet for a platform, stop scaring the
consumer and merely note its expected absence.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181009111259.20807-1-chris@chris-wilson.co.uk
I have a Thinkpad X220 Tablet in my hands that is losing vblank
interrupts whenever LP3 watermarks are used.
If I nudge the latency value written to the WM3 register just
by one in either direction the problem disappears. That to me
suggests that the punit will not enter the corrsponding
powersave mode (MPLL shutdown IIRC) unless the latency value
in the register matches exactly what we read from SSKPD. Ie.
it's not really a latency value but rather just a cookie
by which the punit can identify the desired power saving state.
On HSW/BDW this was changed such that we actually just write
the WM level number into those bits, which makes much more
sense given the observed behaviour.
We could try to handle this by disallowing LP3 watermarks
only when vblank interrupts are enabled but we'd first have
to prove that only vblank interrupts are affected, which
seems unlikely. Also we can't grab the wm mutex from the
vblank enable/disable hooks because those are called with
various spinlocks held. Thus we'd have to redesigne the
watermark locking. So to play it safe and keep the code
simple we simply disable LP3 watermarks on all SNB machines.
To do that we simply zero out the latency values for
watermark level 3, and we adjust the watermark computation
to check for that. The behaviour now matches that of the
g4x/vlv/skl wm code in the presence of a zeroed latency
value.
v2: s/USHRT_MAX/U32_MAX/ for consistency with the types (Chris)
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114173440.6730-1-ville.syrjala@linux.intel.com
Bspec 21257 says "DDIA PHY is the comp master, so it must
not be un-initialized if other combo PHYs are in use". Here
we are shutting down all phys, so it's not strictly required.
However let's be consistent on deinitializing things in the
reversed order we initialized them.
v2: simplify protection for enum port being unsigned in future
v3: spell out reverse rather than rev
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114011509.3667-2-lucas.demarchi@intel.com
These are the only places that assume ports A and B are the ones with
combo phy. Let's use intel_port_is_combophy() there to make sure
it checks for combo phy ports the same way everywhere.
v2: define for_each_combo_port() helper to check the ports
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114011509.3667-1-lucas.demarchi@intel.com
- Fix Bugzilla #108712: Fix incorrect EU count report from kernel
- Fix to account for scale factor when calculating initial phase on scaled output
- Avoid too trigger-happy HPD storm detection and fix a race and an OOPS for MST systems.
- Relocation race fix for Gen4/5
- A couple ICL fixes and dependencies for above Fixes:.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115164709.GA13430@jlahtine-desk.ger.corp.intel.com
- omap: Instantiate dss children in omapdss instead of mach (Laurent)
Other:
- htmldocs build warning (Sean)
- MST NULL deref fix (Stanislav)
- omap: Various runtime ref gets on probe/bind (Laurent)
- omap: Fix to the above dss children patch (Tony)
Cc: Sean Paul <sean@poorly.run>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Tony Lindgren <tony@atomide.com>
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEfxcpfMSgdnQMs+QqlvcN/ahKBwoFAlvsiL8ACgkQlvcN/ahK
Bwr1AQgAirnD41L7FDT2Y0sEBw2FH7MDlj8jw5Bb3qssaKCF/rqEKSG7Sx89n6os
idnPGonkRw8NOM10RMcSxJsG5PZK3lYzxU4QNrXOx+pqOsO/MUXvzMwSfLOK547s
BJTwIzgwh+ogR5yxH797IVZv1H5+DIavp7DPBc6J7e6ARLwJi5ZNBLVKCskPv8yX
Wvoo+pQFvtj7RCMHowtiiCmd6ryscsupEh3cYlHWxzcxCl0uIPOui9sxpet/60VI
4LgLCjAVd7VdzzQuMBbxkx2vFw9Z542ouBR9hk7WTYgzYt1gK2Xuc6h2fdX1g4Vk
jyhdGCvmhUZtxP96ahAunKxrb6/IjQ==
=f89R
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2018-11-14' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Cross-subsystem:
- omap: Instantiate dss children in omapdss instead of mach (Laurent)
Other:
- htmldocs build warning (Sean)
- MST NULL deref fix (Stanislav)
- omap: Various runtime ref gets on probe/bind (Laurent)
- omap: Fix to the above dss children patch (Tony)
Cc: Sean Paul <sean@poorly.run>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114204542.GA52569@art_vandelay
reorder structure of 297, 594 N values to group Audio Sample Frequencies
together to make updating from HDMI specification easier.
V2: Match patch 1/2 version
V3: Arrange by sample freq, then pixel clock.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541019295-20016-1-git-send-email-clinton.a.taylor@intel.com
To get the initial phase correct we need to account for the scale
factor as well. I forgot this initially and was mostly looking at
heavily upscaled content where the minor difference between -0.5
and the proper initial phase was not readily apparent.
And let's toss in a comment that tries to explain the formula
a little bit.
v2: The initial phase upper limit is 1.5, not 24.0!
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 0a59952b24 ("drm/i915: Configure SKL+ scaler initial phase correctly")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029181820.21956-1-ville.syrjala@linux.intel.com
Tested-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
(cherry picked from commit e7a278a329)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
While removing .palette_offsets, I removed the commas after
.trans_offsets in the macros, but failed to remove the line continuation
backslashes.
While at it, also remove another extra comma to be in line with the
other related macros.
Fixes: 74c1e82642 ("drm/i915: remove palette_offsets from device info in favor of _PICK()")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114112130.22264-1-jani.nikula@intel.com
Use intel_plane_destroy_state in intel_plane_free to free the state.
Also fix intel_plane_alloc() to use __drm_atomic_helper_plane_reset(),
to get sane defaults from the atomic core.
This is needed to get the correct alpha value and blend mode from the
core, and any new default values added from new properties.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: b208152556 ("drm/i915: Add plane alpha blending support, v2.")
[mlankhorst: Update commit description to mention alpha blend support]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181113092804.13304-1-maarten.lankhorst@linux.intel.com
Even though PW#1 and the MISC_IO power wells are managed by the
DMC firmware (toggled dynamically if conditions allow it) from the
driver's POV they are always on if the display core is initialized
(always restored by DMC to the enabled state after exiting from DC5/6
for instance b/c of MMIO access). Accordingly we can just mark them as
always-on and remove the special casing for them during state
verification (thus enabling verification for these power wells too).
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-3-imre.deak@intel.com
We can just use a proper true/false initializer even for bitfields,
which is more descriptive.
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-2-imre.deak@intel.com
A DMC bug on GEN9 big core machines fails to restore the driver's
request bits for the PW1 and MISC_IO power wells after a DC5/6
entry->exit sequence. As a consequence the driver's subsequent check for
the enabled status of these power wells will fail, as the check
considers the power wells being enabled only if both the status and
request bits are set. To work around this borrow the request bits from
BIOS's own request register in which DMC forces on the request bits when
exiting from DC5/6.
This fixes a problem reported by Ramalingam, where HDCP init failed,
since PW1 reported itself as being disabled, while in reality it was
enabled.
Reported-by: Ramalingam C <ramalingam.c@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-1-imre.deak@intel.com
Register DBUF_CTL_S2 is read and it's value is not used. As
there is no explanation why we should prime the hardware with
read, remove it as spurious.
Fixes: aa9664ffe8 ("drm/i915/icl: Enable 2nd DBuf slice only when needed")
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109140924.2663-1-mika.kuoppala@linux.intel.com
(cherry picked from commit 8577c319b6)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
This got duplicated on introducing icl workarounds.
Fix by using the older definition and moving the wa bit
definition there. No functional changes.
v3: avoid fixes tag, whitespace (Chris)
References: 908ae05173 ("drm/i915/icl: WaDisCtxReload")
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145333.10570-1-mika.kuoppala@linux.intel.com
Register DBUF_CTL_S2 is read and it's value is not used. As
there is no explanation why we should prime the hardware with
read, remove it as spurious.
Fixes: aa9664ffe8 ("drm/i915/icl: Enable 2nd DBuf slice only when needed")
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109140924.2663-1-mika.kuoppala@linux.intel.com
I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.
I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.
v2: Switch numerator to 1 from 1000 and adjust calculations
accordingly (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-3-paulo.r.zanoni@intel.com
Although CNP names this field "Counter Fraction", what we write to the
register is really the denominator for the fractional part of the
divider, not the fractional part (and the field description even says
that). The ICP spec renamed the field to "Counter Fraction
Denominator", which makes a lot more sense. Use the more complete ICL
naming because we will merge the CNP and ICP functions into a single
one, which will introduce the concept of the numerator. That will make
a lot more sense when you read the "num/frac = den" calculation.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-2-paulo.r.zanoni@intel.com
BSpec was updated and now there's no more "subtract 1" to the
Microsecond Counter Divider field.
It seems this should help fixing some GMBUS issues. I'm not aware of
any specific open bug that could be solved by this patch.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-1-paulo.r.zanoni@intel.com
We accidentially set the huge flag on the parent instead of the childs.
This caused some VM faults under memory pressure.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
the clk value should be tranferred to MHz first and
then transfer to uint16. otherwise, the clock value
will be truncated.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reported-by: Hersen Wu <hersenxs.wu@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
VBT appears to have two (or possibly three) ways to indicate the panel
rotation. The first is in the MIPI config block, but that apparenly
usually (maybe always?) indicates 0 degrees despite the actual panel
orientation. The second way to indicate this is in the general features
block, which can just indicate whether 180 degress rotation is used.
The third might be a separate rotation data block, but that is not
at all documented so who knows what it may contain.
Let's try the first two. We first try the DSI specicic VBT
information, and it it doesn't look trustworthy (ie. indicates
0 degrees) we fall back to the 180 degree thing. Just to avoid too
many changes in one go we shall also keep the hardware readout path
for now.
If this works for more than just my VLV FFRD the question becomes
how many of the panel orientation quirks are now redundant?
v2: Move the code into intel_dsi.c (Jani)
Cc: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022142015.4026-1-ville.syrjala@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Let's make sure the DSI port is actually on before we go
poking at the plane register to determine which way
it's rotated. Otherwise we could be looking at a plane
that is feeding a HDMI port for instance.
And in order to read the plane register we need the power
well to be on. Make sure that is indeed the case. We'll
also make sure the plane is actually enabled before we
trust the rotation bit to tell us the truth.
v2: s/intel_dsi/vlv_dsi/
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022141953.3889-1-ville.syrjala@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
No point in cluttering the common codepaths with the
skip_intermediate_wm handling. Just move it into
ilk_compute_intermediate_wm() as those are the only
platforms using this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108151013.24064-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
To get the initial phase correct we need to account for the scale
factor as well. I forgot this initially and was mostly looking at
heavily upscaled content where the minor difference between -0.5
and the proper initial phase was not readily apparent.
And let's toss in a comment that tries to explain the formula
a little bit.
v2: The initial phase upper limit is 1.5, not 24.0!
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 0a59952b24 ("drm/i915: Configure SKL+ scaler initial phase correctly")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029181820.21956-1-ville.syrjala@linux.intel.com
Tested-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Reduce the clutter in the sprite update functions by writing
both TILEOFF and LINOFF registers unconditionally. We already
did this for primary planes so might as well do it for the
sprites too.
There is no harm in writing both registers. Which one gets
used depends on the tilimg mode selected in the plane control
registers.
It might even make sense to clear the register that won't
get used. That could make register dumps a little easier to
parse. But I'm not sure it's worth the extra hassle.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108150955.23948-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
The bug limits the IH ring wptr address to 40bit. When the system memory
is bigger than 1TB, the bus address is more than 40bit, this causes the
interrupt cannot be handled and cleared correctly.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We no longer change LSPCON into PCON mode if it boots up in
LS mode. This was broken by some code shuffling in
commit 96e35598ce ("drm/i915: Check LSPCON vendor OUI").
I actually can't see a reason why that code shuffling had
to be done. The commit msg notes it but doesn't justify it
in any way. But I guess we'll keep the code in its current
place anyway and just make the "switch to PCON mode" part
effective once again.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Tested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Fixes: 96e35598ce ("drm/i915: Check LSPCON vendor OUI")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107171821.27862-1-ville.syrjala@linux.intel.com
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
In XGMI configuration, the FB region covers vram region from peer
device, adjust system aperture to cover all of them
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: shaoyunl <shaoyun.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This patch prints the version of SMU firmware.
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This patch refactors smu8_send_msg_to_smc_with_parameter() to include
smu8_send_msg_to_smc_async() so that all the messages sent to SMU can be
profiled and appropriately reported if they fail.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In my haste to remove irq_port[] I accidentally changed the
way we deal with hpd pins that are shared by multiple encoders
(DP and HDMI for pre-DDI platforms). Previously we would only
handle such pins via ->hpd_pulse(), but now we queue up the
hotplug work for the HDMI encoder directly. Worse yet, we now
count each hpd twice and this increment the hpd storm count
twice as fast. This can lead to spurious storms being detected.
Go back to the old way of doing things, ie. delegate to
->hpd_pulse() for any pin which has an encoder with that hook
implemented. I don't really like the idea of adding irq_port[]
back so let's loop through the encoders first to check if we
have an encoder with ->hpd_pulse() for the pin, and then go
through all the pins and decided on the correct course of action
based on the earlier findings.
I have occasionally toyed with the idea of unifying the pre-DDI
HDMI and DP encoders into a single encoder as well. Besides the
hotplug processing it would have the other benefit of preventing
userspace from trying to enable both encoders at the same time.
That is simply illegal as they share the same clock/data pins.
We have some testcases that will attempt that and thus fail on
many older machines. But for now let's stick to fixing just the
hotplug code.
Cc: stable@vger.kernel.org # 4.19+
Cc: Lyude Paul <lyude@redhat.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: b6ca3eee18 ("drm/i915: Nuke dev_priv->irq_port[]")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108200424.28371-1-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
(cherry picked from commit 5a3aeca97a)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To enable DC5/6 power well 2 has to be disabled as for previous
platforms, so fix things up.
Bspec: 4234
Fixes: 67ca07e7ac ("drm/i915/icl: Add power well support")
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102182200.17219-1-imre.deak@intel.com
(cherry picked from commit a33e1ece77)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering the connector but before
having written it's value.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-2-lyude@redhat.com
(cherry picked from commit 66a5ab1034)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Exercising the gpu reloc path strenuously revealed an issue where the
updated relocations (from MI_STORE_DWORD_IMM) were not being observed
upon execution. After some experiments with adding pipecontrols (a lot
of pipecontrols (32) as gen4/5 do not have a bit to wait on earlier pipe
controls or even the current on), it was discovered that we merely
needed to delay the EMIT_INVALIDATE by several flushes. It is important
to note that it is the EMIT_INVALIDATE as opposed to the EMIT_FLUSH that
needs the delay as opposed to what one might first expect -- that the
delay is required for the TLB invalidation to take effect (one presumes
to purge any CS buffers) as opposed to a delay after flushing to ensure
the writes have landed before triggering invalidation.
Testcase: igt/gem_tiled_fence_blits
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105094305.5767-1-chris@chris-wilson.co.uk
(cherry picked from commit 55f99bf2a9)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Pass on the errno all the way from connected_sink_max_bpp(),
and make the base_bpp handling in intel_modeset_pipe_config()
a bit less ugly. We'll also rename connected_sink_max_bpp()
to not give the impression that it return the bpp value,
and we'll pimp up the debug message within to include the
connector name/id.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107213522.17590-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
ironlake_check_fdi_lanes() may try to grab some extra crtc locks.
If that fails we need to propagate the -EDEADLK all the way up,
and we shouldn't dump out the crtc state or other debug messages
either since it wasn't the crtc state that caused the failure.
Just hit this on my IVB:
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 3
[drm:intel_atomic_check [i915]] only 2 lanes on pipe C: required 3 lanes
[drm:intel_atomic_check [i915]] fdi link bw constraint, reducing pipe bpp to 18
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 2
[drm:intel_atomic_check [i915]] CRTC bw constrained, retrying
[drm:intel_dp_compute_config [i915]] DP link computation with max lane count 4 max rate 270000 max bpp 18 pixel clock 185580KHz
[drm:intel_dp_compute_config [i915]] DP lane count 4 clock 162000 bpp 18
[drm:intel_dp_compute_config [i915]] DP link rate required 417555 available 648000
[drm:intel_atomic_check [i915]] checking fdi config on pipe C, lanes 2
WARNING: CPU: 4 PID: 25115 at ../drivers/gpu/drm/drm_modeset_lock.c:241 drm_modeset_lock+0xbc/0xd0 [drm]
...
WARNING: CPU: 4 PID: 25115 at ../drivers/gpu/drm/drm_modeset_lock.c:223 drm_modeset_drop_locks+0x4a/0x50 [drm]
The warnings are from 'WARN_ON(ctx->contended)'.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107213522.17590-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
We're missing a call to of_platform_depopulate() on errors for dsi.
Looks like dss is already doing this.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106152802.38599-1-tony@atomide.com
The internal encoders (DSI, HDMI4, HDMI5 and VENC) runtime PM handlers
attempt to manage the runtime PM state of the connected DISPC, based on
the rationale that the DISPC providing data to the encoders requires
ensuring that the display is active whenever the encoders are active.
While the DISPC provides data to the encoders, it doesn't as such
constitute a resource that encoders require in order to be taken out
of suspend, contrary to for instance a functional clock or a power
supply. Encoders registers can be accessed without the DISPC being
active, and while the encoders will not output any video stream without
being fed by the DISPC, the DISPC PM state doesn't influence the
encoders PM state.
For this reason the DISPC PM state is better managed from the omapdrm
driver, in the CRTC enable and disable operations. This allows the
encoders PM state to be handled separately from the DISPC, and in
particular at times when the DISPC may not be available (for instance at
probe due to the DSS probe being deferred, or at remove time du to the
DISPC being already removed).
Fixes: edb715dffd ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-5-laurent.pinchart@ideasonboard.com
The probe function performs hardware access to read the number of
supported data lanes from a configuration register and thus requires the
device to be active. Ensure this by surrounding the access with
dsi_runtime_get() and dsi_runtime_put() calls.
Fixes: edb715dffd ("drm/omap: dss: dsi: Move initialization code from bind to probe")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-4-laurent.pinchart@ideasonboard.com
The bind function performs hardware access (in hdmi4_cec_init()) and
thus requires the device to be active. Ensure this by surrounding the
bind function by hdmi_runtime_get() and hdmi_runtime_put() calls.
Fixes: 27d624527d ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-3-laurent.pinchart@ideasonboard.com
The DSS DT node contains children that describe the DSS components
(DISPC and internal encoders). Each of those components is handled by a
platform driver, and thus needs to be backed by a platform device.
The corresponding platform devices are created in mach-omap2 code by a
call to of_platform_populate(). While this approach has worked so far,
it doesn't model the hardware architecture very well, as it creates
child devices before the parent is ready to handle them. This would be
akin to creating I2C slaves before the I2C master is available.
The task can be easily performed in the omapdss driver code instead,
simplifying mach-omap2 code. We however can't remove the mach-omap2 code
completely as the omap2fb driver still depends on it, but we can move it
to the omap2fb-specific section, where it can stay until the omap2fb
driver gets removed.
This has the added benefit of not allowing DSS components to probe
before the DSS itself, which led to runtime PM issues when the DSS probe
is deferred.
Fixes: 27d624527d ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110111654.4387-2-laurent.pinchart@ideasonboard.com
To avoid changing the global lbpw module parameter directly.
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/ttm/ttm_execbuf_util.c: In function 'ttm_eu_fence_buffer_objects':
drivers/gpu/drm/ttm/ttm_execbuf_util.c:190:24: warning:
variable 'driver' set but not used [-Wunused-but-set-variable]
It not used any more after
commit f2c24b83ae ("drm/ttm: flip the switch, and convert to dma_fence")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Abstract the function of amdgpu_gfx_rlc_enter/exit_safe_mode and some part of
rlc_init to improve the reusability of RLC.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Separate the function and struct of RLC from the file of GFX.
Abstract the function of amdgpu_gfx_rlc_fini.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Put function rlc_init,rlc_fini,rlc_resume,rlc_stop,rlc_start into structure
amdgpu_rlc_funcs and change the method to call rlc function for each verssion of
GFX.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Driver need to call each psp instance to get topology info before set topology
Signed-off-by: shaoyunl <Shaoyun.Liu@amd.com>
reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We dump the info as an array of u8, so we want to know the length
in number of bytes. Current code is still safe because the
variable we use BITS_PER_TYPE on is a u8.
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109004013.34394-1-daniele.ceraolospurio@intel.com
We have a subslice mask per slice, not per subslice.
MAX_SUBSLICES > MAX_SLICES, so the wrong size didn't cause any issue
apart from using extra memory.
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106182918.5748-1-daniele.ceraolospurio@intel.com
In the past we had hooks to configure HW for VLV/CHV too, in the drop
of VLV/CHV support the intel_psr_disable_source() code was not moved
to the caller, so doing it here.
Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-4-jose.souza@intel.com
All other interruptions gen11 interruptions are reset in
gen11_irq_reset() also it is done for other gens that supports PSR.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-3-jose.souza@intel.com
It should always wait for idle state when disabling PSR because PSR
could be inactive due a call to intel_psr_exit() and while PSR is
still being disabled asynchronously userspace could change the
modeset causing a call to psr_disable() that will not wait for PSR
idle and then PSR will be enabled again while PSR is still not idle.
v2: rebased on top of the patch reusing psr_exit()
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-2-jose.souza@intel.com
Both functions have the same code to disable PSR, so let's reuse that
code instead of duplicate.
Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-1-jose.souza@intel.com
Unfortunately drm_dp_get_mst_branch_device which is called from both
drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely
on that mgr->mst_primary is not NULL, which seem to be wrong as it can be
cleared with simultaneous mode set, if probing fails or in other case.
mgr->lock mutex doesn't protect against that as it might just get
assigned to NULL right before, not simultaneously.
There are currently bugs 107738, 108616 bugs which crash in
drm_dp_get_mst_branch_device, caused by this issue.
v2: Refactored the code, as it was nicely noticed.
Fixed Bugzilla bug numbers(second was 108616, but not 108816)
and added links.
[changed title and added stable cc]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108616
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107738
Link: https://patchwork.freedesktop.org/patch/msgid/20181109090012.24438-1-stanislav.lisovskiy@intel.com
Make skl_ddb_allocation_overlaps() useful for other callers
besides skl_update_crtcs(). We'll need it to do plane updates
as well.
And while we're here we can reduce the stack utilization a
bit by noting that each struct skl_ddb_entry is 4 bytes whereas
a pointer to one is 8 bytes (on 64bit). So we'll switch to an
array of structs from the array of pointers we used before.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-9-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Due to the constant alpha we're going to have to program two of
the the tree keying registers anyway, so might as well always
program all three.
And parametrize the plane constant alpha define while at it.
v2: Rebase due to input CSC
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107184138.31359-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
MST is only supported in DDI ports that have this hook, so the null
check can be dropped.
Suggested-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-3-jose.souza@intel.com
MST ports did not had the post_pll_disable() hook causing the
references get in pre_pll_enable() never being released causing
DDI and AUX CH being enabled all the times.
v2: renamed intel_mst_post_pll_disable_dp() parameters
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-2-jose.souza@intel.com
intel_dp_detect() caches the aux_domain in the beginning of the
function as it is used twice, so lets also use it as the aux_domain
don't change in runtime.
v3: returning intel_dp_retrain_link() error insted of
connector_status_disconnected
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-1-jose.souza@intel.com
IBX has a documented workaround which states that when we disable the
port we must change its transcoder select to A, otherwise it will
prevent the other port (DP vs. HDMI/SDVO) from using transcoder A.
We implement the workaround during encoder disable, but looks like
some BIOSen leave transcoder B selected even when the port wasn't
actually enabled by the BIOS. That will trip up our asserts
that attempt to make sure we never forget this w/a.
Sanitize the transcoder select to A for all disabled PCH
DP/HDMI/SDVO ports. We assume that the port was never enabled
by the BIOS on transcoder B, because if it had we'd actually have
to toggle the port on and back off to properly switch it back to
transcoder A. That would cause some display flicker if transcoder A
is already enabled on some other port, so it's better not to do it
unless absolutely necessary. Since we have no indication that the
transcoder select is misbehaving on the affected machines we can
assume the port was never actually enabled by the BIOS.
This cures warning like this during driver load:
IBX PCH DP C still using transcoder B
WARNING: CPU: 2 PID: 172 at drivers/gpu/drm/i915/intel_display.c:1279 assert_pch_dp_disabled+0x9e/0xb0 [i915]
v2: Add comments to remind the reader that SDVOB==HDMIB (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108143635.9556-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Imre Deak