Depending on the transcoder enum values to translate from transcoder to
the corresponding CHICKEN_TRANS register can easily break if we add a
new transcoder. Add an explicit mapping instead, by using helpers to
look up the register instance either by transcoder or port (since
unconveniently the registers have both port and transcoder specific
bits).
While at it also check for the correctness of GEN, port, transcoder. I
wasn't sure if psr2_enabled can only be set for GEN9+, but that seems to
be the case indeed (see setting of sink_psr2_support in
intel_psr_init_dpcd()).
v2 (Ville):
- Make gen9_chicken_trans_reg() internal to intel_psr.c.
- s/trans/cpu_transcoder/
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Mika Kahola <mika.kahola@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/20181119180021.370-1-imre.deak@intel.com
Add a comment to the pipe and transcoder enum definitions about our
assumption in the code about enum values for pipes and transcoders
with a 1:1 transcoder -> pipe mapping.
v2:
- Clarify more what are the assumptions about the enum values. (Ville)
v3: (Lucas)
- s/->/ -> / so it looks less like pointer dereferencing.
- Use pipe enums as initializers in the transcoder enum definition.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
Link: https://patchwork.freedesktop.org/patch/msgid/20181120092325.21249-3-imre.deak@intel.com
Depending on the transcoder enum values to translate from transcoder
to EDP PSR flags can easily break if we add a new transcoder. So remove
the dependency by using an explicit mapping.
While at it also add a WARN for unexpected trancoders.
v2:
- Simplify things by defining flag shift values instead of indices.
- s/trans/cpu_transcoder/ (Ville)
v3:
- Define flags to look like separate bits instead of the values of
the same bitfield. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Mika Kahola <mika.kahola@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-2-imre.deak@intel.com
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
Found by smatch:
drivers/gpu/drm/i915/gvt/gtt.c:2452 intel_vgpu_destroy_ggtt_mm() error: dereferencing freed memory 'pos'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.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
(cherry picked from commit 7fa28e1469)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.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
(cherry picked from commit fb6f0b64e4)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
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
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
(cherry picked from commit 03981c6ebe)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
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
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
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
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
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>
drm-next is forwarded to v4.20-rc1, and we need this to make
a patch series apply.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
We need to include the revert of commit 783195ec1c ("drm/syncobj:
disable the timeline UAPI for now v2") along with undoing the change to
drm/i915.
Fixes: 131280a162 ("drm: Revert syncobj timeline changes.")
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chunming Zhou <david1.zhou@amd.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112152130.12275-1-chris@chris-wilson.co.uk
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>
Commit e61d98d8da ("x64, x2apic/intr-remap: Intel vt-d, IOMMU
code reorganization") moved dma_remapping.h from drivers/pci/ to
current place. It is entirely VT-d specific, but uses a generic
name. This merges dma_remapping.h with include/linux/intel-iommu.h
and removes dma_remapping.h as the result.
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Sohil Mehta <sohil.mehta@intel.com>
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Liu, Yi L <yi.l.liu@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
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>
Some engines are not available for all Gens. eg, Gen11 introduced
VCS3/VCS4/VECS2, and VCS2 is not supported on some Gen9 machines. So need to
add check before access them.
Signed-off-by: Xinyun Liu <xinyun.liu@intel.com>
Signed-off-by: Yakui Zhao <Yakui.Zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.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
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>
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>
We shouldn't consider an encoder inactive if it doesn't have a CRTC
linked, but has virtual MST encoders with a crtc linked. Fix this.
Also we should not sanitize the mapping for MST encoders, as it's always
their primary encoder (which could be even in SST mode) whose active
state determines if we need the clock being enabled for the
corresponding physical port. Fix this too.
This fixes at least an existing breakage where we incorrectly disabled
the clock for an active DP encoder when sanitizing its MST virtual
encoders. Not sure if there are BIOSes that enable an output in MST
mode, but our HW readout is mostly missing for it anyway, so just warn
for that case.
Fixes: 70332ac539 ("drm/i915/icl+: Sanitize port to PLL mapping")
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reported-by: Antonio Argenziano <antonio.argenziano@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107200836.10191-2-imre.deak@intel.com
Check for reserved register field values and conflicting
transcoder->port mappings (both MST and non-MST mappings or multiple SST
mappings).
This is also needed for the next patch to determine if a port is in MST
mode during sanitization after HW readout.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107200836.10191-1-imre.deak@intel.com
While our little rcu worker might be able to be replaced now by the
dedicated rcu_work, in the meantime we should mark up the rcu_head for
correct debugobjects tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108092101.27598-2-chris@chris-wilson.co.uk
All other overlay functions(almost all other functions in i915)
follow intel_overlay_verb, so renaming overlay ones that do not match
that.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-4-jose.souza@intel.com
IPC is a display feature, so i915_load_modeset_init() is the right
place to initialize it.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-3-jose.souza@intel.com
Although FBC helps save power it do not belongs to power management
also the cleanup was placed in i915_driver_unload() also not a good
place. intel_modeset_init()/intel_modeset_cleanup() are better places
also this will help make easy disable features that depends in
display being enabled in driver.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-2-jose.souza@intel.com
i915_load_modeset_init() is a more suitable place than
i915_driver_load() as vblank is part of modeset.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-1-jose.souza@intel.com
This reduces the size of struct skl_wm_level from 6 to 4, which
reduces the size of struct skl_plane_wm from 104 to 70, which reduces
the size of struct skl_pipe_wm from 524 to 356. A reduction of 168
padding bytes per pipe. This will increase even more the next time we
bump I915_MAX_PLANES.
v2: Paste the pahole output provided by Lucas:
$ pahole -s -C skl_wm_level drivers/gpu/drm/i915/i915.o
struct skl_wm_level {
bool plane_en; /* 0 1 */
/* XXX 1 byte hole, try to pack */
uint16_t plane_res_b; /* 2 2 */
uint8_t plane_res_l; /* 4 1 */
/* size: 6, cachelines: 1, members: 3 */
/* sum members: 4, holes: 1, sum holes: 1 */
/* padding: 1 */
/* last cacheline: 6 bytes */
};
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016220133.26991-3-paulo.r.zanoni@intel.com
We have multiple instances of VCS but only remember to invalidate the
BSD caches on the first, ignoring the stale caches of any other engine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181108140039.12254-1-chris@chris-wilson.co.uk
On ICL DMC/PCODE retains the HW context only for port A across DC
transitions, for the other port B combo PHY, it doesn't. So we need to
do this manually after exiting from DC6. Do the reinit even after
exiting from DC5, it won't hurt since we only reinit the PHY in case
it's needed (in case it was disabled to begin with).
As can be guessed from the bugzilla report leaving the PHY uninited will
lead to a later timeout during the port B specific AUX and DDI_IO power
well enabling.
v2:
- Apply the fix on all GEN>=11 platforms. (Rodrigo)
Bspec: 21257
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-6-imre.deak@intel.com
Bspec says we should skip the initialization of combo PHYs that are
already initialized. We'll need to reinit the PHYs more frequently
when exiting from DC6 (after the next patch), so let's make sure the
uninit sequence complies with the spec. For safety skip the init only if
all the PHY register fields have their expected values.
v2:
- Print 'Port X' as we do elsewhere instead of 'Port-X'. (Jose)
Bspec: 21257
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-5-imre.deak@intel.com
Verify on CNL, ICL that the combo PHY HW state stayed intact after PHY
initialization.
v2:
- Print 'Port X' as we do elsewhere instead of 'Port-X'. (Jose)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-4-imre.deak@intel.com
Similarly to the GEN9_LP DPIO PHY code keep the CNL+ combo PHY code in a
separate file.
No functional change.
v2:
- Use SPDX license tag instead of boilerplate. (Rodrigo)
v3:
- Use MIT instead of GPL-2.0 license. (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-3-imre.deak@intel.com
BSpec says to clear the comp init HW flag too during combo PHY uninit,
so do that. The lack of this could badly interact with the PHY reinit
after a DC6/9 transition at least, where (after a follow-up patch fixing
the init code) we'd skip the initialization incorrectly due to this flag
being set.
BSpec: 21257
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-2-imre.deak@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
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0
[ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0
[ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected
[ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event.
[ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085
[ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
[ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä
Signed-off-by: Lyude Paul <lyude@redhat.com>
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
This is rather confusing to look at as-is:
dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler()
handles disabling the actual HPD IRQ, while
intel_hpd_irq_storm_disable() handles moving the HPD pin state over from
MARK_DISABLED to DISABLED along with enabling polling for it.
Changes since v3:
- Rename i915_hpd_irq_storm_disable() to
i915_hpd_irq_storm_switch_to_polling() - Rodrigo Vivi
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-5-lyude@redhat.com
Currently in intel_hpd_irq_storm_detect() when we detect that the last
recorded hotplug wasn't within the period defined by
HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count
to 0 without incrementing it. This results in us only enabling storm
detection when we go +2 above the threshold, e.g. an HPD threshold of 5
would not trigger a storm until we reach a total of 7 hotplugs.
So: rework the code a bit so we reset the HPD count when
HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards.
Also, clean things up a bit to make it easier to undertand.
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-4-lyude@redhat.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
No need for the posting reads in the plane update/disable hooks.
If we need a posting read for something then a single one at the
very end would be sufficient. We have that anyway in the form
of eg. scanline/frame counter reads.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-2-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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
The i915 driver uses shmemfs to allocate backing storage for gem
objects. These shmemfs pages can be pinned (increased ref count) by
shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan
wastes a lot of time scanning these pinned pages. In some extreme case,
all pages in the inactive anon lru are pinned, and only the inactive
anon lru is scanned due to inactive_ratio, the system cannot swap and
invokes the oom-killer. Mark these pinned pages as unevictable to speed
up vmscan.
Export pagevec API check_move_unevictable_pages().
This patch was inspired by Chris Wilson's change [1].
[1]: https://patchwork.kernel.org/patch/9768741/
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Kuo-Hsin Yang <vovoy@chromium.org>
Acked-by: Michal Hocko <mhocko@suse.com> # mm part
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gvt-fixes-2018-11-07
- Fix invalidate of old ggtt entry (Hang)
- Fix partial ggtt entry update in any order (Hang)
- Fix one mask setting for chicken reg (Xinyun)
- Fix eDP warning in guest (Longhe)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107023137.GO25194@zhen-hp.sh.intel.com
We're no longer programming any watermarks when we're disabling
a pipe. That means ilk_wm_merge() & co. will keep considering
the any pipe that is getting disabled as still enabled. Thus we
either get no LP1+ watermakrs (ilk-ivb), or we get suboptimal
ones (hsw-bdw).
This seems to have been broken by commit b6b178a772 ("drm/i915:
Calculate ironlake intermediate watermarks correctly, v2."). Before
that we apparently had some difference between the intermediate
and optimal watermarks and so we would program the optiomal ones.
Now intermediate and optimal are identical for disabled pipes
and so we don't program either.
Fix this by programming the intermediate watermarks even for
disabled pipes. We were already doing that for skl+. We'll
leave out gmch platforms for now since those do the merging
in a different manner and should work as is. We'll want to
unify this eventually, but play it safe for now and just put
in a FIXME.
Cc: stable@vger.kernel.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: b6b178a772 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025130536.29024-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
(cherry picked from commit a748faea3b)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already be gone when it comes time to shut down the crtc.
As we don't know when the last reference to the platform
device gets dropped by the audio driver we can't assume that
the device and its data are still around when turning off the
crtc. Mark the platform device as gone as soon as we do the
audio deinit.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105194604.6994-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit f45a7977d1)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Since the flags are being used to operate on a u64 variable, they too
need to be marked as such so that the inverses are full width (and not
zero extended on 32b kernels and bdw+).
Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102161232.17742-2-chris@chris-wilson.co.uk
(cherry picked from commit 83b466b1dc)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
This patch fixes the macros used for defining the DFLEXDPMLE
register bit fields. This accounts for changes in the spec.
Fixes: a2bc69a1a9 ("drm/i915/icl: Add register definition for DFLEXDPMLE")
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023191248.26418-1-manasi.d.navare@intel.com
(cherry picked from commit b4335ec0a3)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Let's not leak obj->framebuffer_references when we decide that
the framebuffer domensions are not suitable for NV12.
Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Fixes: e44134f267 ("drm/i915: Add NV12 support to intel_framebuffer_init")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029140031.11765-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit 3b90946fcb)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
While checking the opportunity to add a display_gen
check to allow glk and cnl to be on same bucket I noticed
these FIXME cases here.
So I got the confirmation from HW architect that we actually
never needed this workaround.
"GLK supports 2 pixel per clock, so pixel clock can be up to 2 * cdclk."
So, this reverts commit 97f55ca5b6 ("drm/i915/glk: limit pixel
clock to 99% of cdclk workaround")
Fixes: 97f55ca5b6 ("drm/i915/glk: limit pixel clock to 99% of cdclk workaround")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Arthur J Runyan <arthur.j.runyan@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/20181026005636.22274-1-rodrigo.vivi@intel.com
(cherry picked from commit 42882336e6)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Since we use a 64b virtual GTT irrespective of the system, we want to
ensure that the GTT computations remains 64b even on 32b systems,
including treatment of huge virtual pages.
No code generation changes on 64b:
Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108282
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025091823.20571-1-chris@chris-wilson.co.uk
(cherry picked from commit 9125963a94)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to
the appropriate platforms.
This was especially harsh on GLK since we don't even try to read
the DIMM information on that platforms, hence valid_dimm was
always false and thus we always tried to apply the w/a.
Furthermore the w/a pushed the level 0 latency above the
level 1 latency, which doesn't really make sense.
v2: Do the check when populating is_16gb_dimm (Mahesh)
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 86b592876c ("drm/i915: Implement 16GB dimm wa for latency level-0")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023182102.31549-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
(cherry picked from commit 5d6f36b27d)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
We deinit the lpe audio device before we call
drm_atomic_helper_shutdown(), which means the platform device
may already be gone when it comes time to shut down the crtc.
As we don't know when the last reference to the platform
device gets dropped by the audio driver we can't assume that
the device and its data are still around when turning off the
crtc. Mark the platform device as gone as soon as we do the
audio deinit.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105194604.6994-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may have to iterate a few thousand elements to acquire and release
the shmemfs backing storage for a GPU object, we need to break up the
long loop with cond_resched() to retain a modicum of low latency for
other processes.
Testcase: igt/benchmarks/gem_syslatency
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kuo-Hsin Yang <vovoy@chromium.org>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105170640.26905-1-chris@chris-wilson.co.uk
Plane input CSC needs to be enabled to convert frambuffers from
YUV to RGB. This is needed for bottom 3 planes on ICL, rest of
the planes have hardcoded conversion and taken care by the legacy
code.
This patch defines the co-efficient values for YUV to RGB conversion
in BT709 and BT601 formats. It programs the coefficients and enables
the plane input csc unit in hardware.
This has been verified and tested by Maarten and the change is working
as expecpted.
v2: Addressed Maarten's and Ville's review comments and added the
coefficients in a 2D array instead of independent Macros.
v3: Added individual coefficient matrix (9 values) instead of 6
register values as per Maarten's comment. Also addresed a shift
issue with B channel coefficient.
v4: Added support for Limited Range Color Handling
v5: Fixed Matt and Maarten's review comments.
v6: Added human readable matrix values for YUV to RGB Conversion along
with just the bspec register values, as per Matt's suggestion.
v7: Refactored the code, move csc coefficient programming function to
intel_sprite.c and made it static as per Ville's review comment.
v8: Addressed Ville's review comment. Called the coefficient programming
from within the skl_program_plane and used I915_WRITE_FW instead of
I915_WRITE.
v9: Fixed Ville's review comments.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541099420-12419-3-git-send-email-uma.shankar@intel.com
Defined the plane input csc coefficient registers and macros.
6 registers are used to program a total of 9 coefficients,
added macros to define each of them for all the planes
supporting the feature on pipes. On ICL, bottom 3 planes
have this capability.
v2: Segregated the register macro definition as separate patch
as per Maarten's suggestion.
v3: Removed a redundant 3rd Pipe register definition and
simplified the equally spaced register definition by adding an
offset as per Matt's comment.
v4: No Change
v5: Renamed the register Macro as per Matt's suggestion.
v6: No Change
v7: No Change
v8: No Change
v9: No Change
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541099420-12419-2-git-send-email-uma.shankar@intel.com
We're no longer programming any watermarks when we're disabling
a pipe. That means ilk_wm_merge() & co. will keep considering
the any pipe that is getting disabled as still enabled. Thus we
either get no LP1+ watermakrs (ilk-ivb), or we get suboptimal
ones (hsw-bdw).
This seems to have been broken by commit b6b178a772 ("drm/i915:
Calculate ironlake intermediate watermarks correctly, v2."). Before
that we apparently had some difference between the intermediate
and optimal watermarks and so we would program the optiomal ones.
Now intermediate and optimal are identical for disabled pipes
and so we don't program either.
Fix this by programming the intermediate watermarks even for
disabled pipes. We were already doing that for skl+. We'll
leave out gmch platforms for now since those do the merging
in a different manner and should work as is. We'll want to
unify this eventually, but play it safe for now and just put
in a FIXME.
Cc: stable@vger.kernel.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: b6b178a772 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025130536.29024-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
On GEN9 LP (BXT/GLK) DC6 is not supported, so don't print the counter
on those platforms. So far we did this on GLK too.
While at it warn if we forgot to adjust the printout properly for a
new platform. (Rodrigo)
Testcase: igt/pm_dc/dc6-dpms
Cc: Jyoti Yadav <jyoti.r.yadav@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031200220.11608-1-imre.deak@intel.com
The MG DP mode needs to be configured for Type C static/fixed/legacy
HDMI ports too, the same way as it's configured for Type C
static/fixed/legacy, fix this.
Bspec: 4232, 21735
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102192656.4472-3-imre.deak@intel.com
The MG PHY clock gating needs to be configured for Type C
static/fixed/legacy HDMI ports the same way it's configured for Type C
static/fixed/legacy and aternate mode DP ports, fix this.
Bspec: 4232, 21735
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102192656.4472-2-imre.deak@intel.com
Similar to DSC DPCD registers, let us cache
FEC_CAPABLE register to avoid using stale
values. With this we can avoid aux reads
everytime and instead read the cached values.
v2: Avoid using memset and array for a single
field. (Manasi,Jani)
v3: Print FEC CAPABILITY value. (Manasi)
Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102041455.15818-1-anusha.srivatsa@intel.com
Since the flags are being used to operate on a u64 variable, they too
need to be marked as such so that the inverses are full width (and not
zero extended on 32b kernels and bdw+).
Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102161232.17742-2-chris@chris-wilson.co.uk
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJb2+C2AAoJEAx081l5xIa+tUYP/060xa9VeKe0M11fMCCkchNV
TQfPQ8avy2/Tt9Mlly/XPMuBZ6FCTVBsseCxIdzl4rZAfm0SDVaTB4Z7XBBplXkv
R50Je95Fyv0/lnUbagI5qRtc+O6xdkuNIMHWlRRWGlCEbFE2atey9R2yiq/1q2J9
4NcGjykJ7d1vCgMm/9/iV4pLrxrRSxvizO4mS+SQpJ/0fEwJSZSvKdKp9LU/LTgx
qZGSBegPkR+j6znsMkuPYxQtMrhz+Pr49qp7Qm6wQV/K2Y0z7CoHZFikvpMp38i5
MQfYE0yDN3pKm5THt+RjV8laPIpnh2z8bcotUCGcjFWtGHQBfyQ4IaXkDPujcD6m
vRm4hhxP9DvNCq5eWFz3vU2n8NWf54BYFF8dPxcoghRkE6VB2CGpr+o9dzxX16QJ
oEi2Ak3G7RXa8Hn/C9EOSs7yijjKD8GZ8gR5osmI10EitIH7mrG9Xghts5XlcIJj
Ls30t0jPavO+t8V2/1HYP2vfSNvi/X953+pQIdN8Rk2vp0ziFdstzLg6ai8E1Hvl
jyvOF3/xstwIP8nFvYaNHkly2iVRC3rgj4GDncSe2U6kt8N4/aA+FemUwXJKBbFN
hVwPZuSlrCw5TE7tO3ulJon4uAWH5WO/gIOMn0+e+pBLJtUXQtWAR+JC2D+RDZO9
V+V7GuHIbIV6xarCwLjx
=5lmL
-----END PGP SIGNATURE-----
Merge tag 'drm-next-2018-11-02' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Pretty much a normal fixes pull pre-rc1, mostly amdgpu fixes, one i915
link training regression fix, and a couple of minor panel/bridge fixes
and a panel quirk"
* tag 'drm-next-2018-11-02' of git://anongit.freedesktop.org/drm/drm: (37 commits)
drm/amdgpu: revert "enable gfxoff in non-sriov and stutter mode by default"
drm/amd/pp: Print warning if od_sclk/mclk out of range
drm/amd/pp: Fix pp_sclk/mclk_od not work on Vega10
drm/amd/pp: Fix pp_sclk/mclk_od not work on smu7
drm/amd/powerplay: no MGPU fan boost enablement on DPM disabled
drm/amdgpu: Fix skipping hangged job reset during gpu recover.
drm/amd/powerplay: revise Vega20 pptable version check
drm/amd/display: set backlight level limit to 1
drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1
drm/bridge: ti-sn65dsi86: Remove the mystery delay
drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM
drm/panel: simple: Support panels with HPD where HPD isn't connected
dt-bindings: drm/panel: simple: Add no-hpd property
drm/edid: Add 6 bpc quirk for BOE panel.
drm/amdgpu: fix reporting of failed msg sent to SMU (v2)
drm/amdgpu: Fix compute ring 1.0.0 failure after reset
drm/amdgpu: fix VM leaf walking
drm/amdgpu: fix amdgpu_vm_fini
drm/amd/powerplay: commonize the API for retrieving current clocks
...
The registers DPCSSS,DPSP,DPMLE1 and DPPMS are all at an offset
from the base - which is the FLexi IO Adaptor. Lets follow the
offset calculation while accessing these registers.
v2:
- Follow spec for numbering - s/0/1(Lucas)
- s/FIA_1/FIA1_BASE (Anusha)
v3:
- Remove register offset defines. (Jani)
- Update comment. (Anusha)
v4: rebase. Remove comment.(Lucas)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101185557.29585-1-anusha.srivatsa@intel.com
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
V12: Fix debug message(Ville)
V13: Remove the redundant check and simplify the check logic(Stan)
V14: Fix the check in connected_sink_max_bpp(Stan)
v15 (From Manasi): Add missing break (Stan)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Kishore Kadiyala <kishore.kadiyala@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023014400.16055-1-manasi.d.navare@intel.com
Although there's nothing crucial missing, it's been a long time since
the last backmerge. Catch up with drm-next.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This patch fixes the naming of the registers:
s/PIPE_DSS_CTL/ICL_PIPE_DSS_CTL
And also fix the hex values to lower case, to match
rest of the definitions.
Manasi noticed this with the patch that was merged.
v2: fix "Fixes" tag.
Fixes: 8b1b558d69 ("drm/i915/icl: Add DSS_CTL Registers")
Suggested-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101214216.8958-1-anusha.srivatsa@intel.com
BIOS can leave the PLL to port mapping enabled, even if the
corresponding encoder is disabled. Disable the port mapping in this
case.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-9-imre.deak@intel.com
Most of the AUX_CH_CTL flags are concerned with DP AUX transfer
parameters. As opposed to this the flag specifying the thunderbolt vs.
non-thunderbolt mode of the port is not related to AUX transfers at all
(rather it's repurposed to enable either TBT or non-TBT PHY HW blocks).
The programming has to be done before enabling the corresponding AUX
power well, so make it part of the power well code.
v3:
- Use existing enable/disable helpers instead of opencoding. (Jose)
- Fix type of is_tc_tbt to remain a bitfield. (Lucas)
- Add comment describing the is_tc_tbt power well flag. (Lucas)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108548
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-8-imre.deak@intel.com
DDI/TypeC ports need the AUX power domain for main link functionality
even when they operate in HDMI static mode, so enable the power domain
for these ports too.
v4:
- Rebase on the upstream ICL pre_pll_enable change.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-7-imre.deak@intel.com
For DDI/TypeC ports the AUX power domain needs to be enabled before the
port's PLL is enabled, so move the enabling earlier accordingly.
v2:
- Preserve the pre_pll hook for GEN9_LP. (Ville)
v3:
- Add related BSpec entries to commit log. (Jose)
v4:
- Rebase on the upstream ICL pre_pll_enable change.
BSpec: 21750, 22243
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-6-imre.deak@intel.com
From ICL onwards the AUX power domain may change dynamically based on
whether a DDI/TypeC port is in thunderbolt or non-thunderbolt mode, so
use a helper function instead of a static field to get the current
domain.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-5-imre.deak@intel.com
From ICL onwards DDI/TypeC ports - even in HDMI static mode - need to know
which AUX CH belongs to them, so initialize aux_ch for those ports too.
For consistency do this for all HDMI ports, not only for DDI/TypeC ones.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-4-imre.deak@intel.com
From ICL onwards all DDI/TypeC ports - even working in HDMI mode - need
to know their corresponding AUX CH, so move the field to a common
struct.
No functional change.
v3:
- Add code comment about which ports aux_ch is used for. (Jose)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-3-imre.deak@intel.com
From ICL onwards all the DDI/TypeC ports - even working in HDMI mode -
need to know their corresponding AUX channel, so move the corresponding
helper to a common place.
No functional change.
v4:
- Fix 'no space is necessary after a cast' checkpatch warn.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-2-imre.deak@intel.com
Gen11 Display suports 32 planes in total. Enable the new format in context
status to be used and expanded to 32 planes.
V2: Move the WA to display WA's(Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030084504.21537-1-radhakrishna.sripada@intel.com
CNL A stepping was the only affected there.
But also it is time to clean old pre-production
CNL Workarounds, so let's just remove and clean
this W/A.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031162845.12419-4-rodrigo.vivi@intel.com
Let's introduce the WA number that is the
cause of having NV12 disabled on both SLK and BXT.
According to Spec:
WA 0870: "Display flickers with NV12 video playback in
Y tiling mode.
WA: Use YUV422 surface format instead of NV12."
v2: remove the useless dead code and consequently
avoiding device info flag. (Ville)
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/20181031162845.12419-3-rodrigo.vivi@intel.com
According to BSpec this is not needed anymore:
"This workaround is no longer needed since NV12
support is dropped for the affected projects.
"
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
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/20181031162845.12419-2-rodrigo.vivi@intel.com
First of all I believe this WA as written here was wrong.
Because it is listed on BSpec only for SKL and BXT, exactly
the only 2 platforms skipped here.
But also it is written there that we don't need this WA
anymore:
"This workaround is no longer needed since NV12 support is
dropped for the affected projects in #0870."
SO, let's kill it.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Vidya Srinivas <vidya.srinivas@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/20181031162845.12419-1-rodrigo.vivi@intel.com
Add missing block that takes care of inline intel_suspend_complete
for DC9 on ICL.
Daniele noticed this was part of original patch but missed on
on merged commit ("drm/i915/icl: Enable DC9 as lowest possible
state during screen-off").
Fixes: 3e68928b7d ("drm/i915/icl: Enable DC9 as lowest possible state during screen-off")
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo added a commit message while merging]
Link: https://patchwork.freedesktop.org/patch/msgid/20181031202726.4021-1-anusha.srivatsa@intel.com
This patch detects DSI presence for ICL platform
by reading VBT. DSI detection is done while initializing
DSI using newly added function intel_gen11_dsi_init.
v2 by Jani:
- Preserve old behavour of intel_bios_is_dsi_present()
- s/intel_gen11_dsi_init/icl_dsi_init/g
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2324cdfc8918bda3165354e5e0d15053b1074f14.1540900289.git.jani.nikula@intel.com
In case of Legacy DP connector on TypeC port, the
flex IO DPMLE register is set to number of lanes configured
by the display driver which will be programmed into DDI_BUF_CTL
PORT_WIDTH_SELECTION.
This needs to be programmed before enabling the shared PLLs hence
add a pre_pll_enable hook for ICL and add this programming in that hook.
v2:
* Remove the check for combophy port (Jose)
* Simplify the port reversal check logic (Jose)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023191248.26418-2-manasi.d.navare@intel.com
This patch fixes the macros used for defining the DFLEXDPMLE
register bit fields. This accounts for changes in the spec.
Fixes: a2bc69a1a9 ("drm/i915/icl: Add register definition for DFLEXDPMLE")
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023191248.26418-1-manasi.d.navare@intel.com
Otherwise it would be in a inconsistent state as port is disconnected
but with a valid tc type.
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>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030215750.28213-3-jose.souza@intel.com
Otherwise it would be in a inconsistent state as port is disconnected
but with a valid tc type.
Also setting it to unknown will earlier return
icl_tc_phy_disconnect() for any future calls to
intel_digital_port_connected(), this way we don't need to check if
port is marked as safe everytime.
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>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030215750.28213-2-jose.souza@intel.com
Besides of give the expected output of i915_display_info it will also
avoid some aux ch transactions that would timeout by obvious reasons.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030215750.28213-1-jose.souza@intel.com
Let's not leak obj->framebuffer_references when we decide that
the framebuffer domensions are not suitable for NV12.
Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Vidya Srinivas <vidya.srinivas@intel.com>
Fixes: e44134f267 ("drm/i915: Add NV12 support to intel_framebuffer_init")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029140031.11765-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Use intel_panel_actually_set_backlight() instead of a direct
call to pwm_config() in pwm_disable_backlight().
The main benefit is consistent debug logging when we turn off the
backlight. Currently we see nothing in dmesg which made me wonder
whether the backlight was even getting turned off properly.
The second benefit is consistency; This is what we do for all
the other backlight implementations.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024155208.18987-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jani Nikula <jani.nikula@intel.com>
When DSC is supported we need to validate the modes based on the
maximum supported compressed BPP and maximum supported slice count.
This allows us to allow the modes with pixel clock greater than the
available link BW as long as it meets the compressed BPP
and slice count requirements.
v3:
* Use the macro for dsc sink support (Jani N)
v2:
* Properly comment why we are right shifting the bpp value (Anusha)
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031001923.31442-6-manasi.d.navare@intel.com
This patch adds helpers for calculating the maximum compressed BPP
supported with small joiner.
This also adds a helper for calculating the slice count in case
of small joiner.
These are inside intel_dp since they take into account hardware
limitations.
v6:
* Take mode_clock and mode_hdisplay as input arguments
so that this can be called in intel_dp_mode_valid (Manasi)
v5:
* Get the max slice width from DPCD
* Check against Min_Slice_width of 2560 (Anusha)
v4:
* #defines for PPR in slice count helper (Gaurav)
v3:
* Simply logic for bpp (DK)
* Limit the valid slice count by max supported by Sink (Manasi)
v2:
* Change the small joiner RAM buffer constant as bspec changed (Manasi)
* rename it as SMALL_JOINER since we are not enabling
big joiner yet (Anusha)
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031001923.31442-5-manasi.d.navare@intel.com
DSC is supported on eDP starting GEN 10 display (on GLK) and on DP starting
GEN 11.
This patch implements the discovery phase of DSC. On hotplug,
source reads the DSC DPCD register set (0x00060 - 0x0006F) to
read the decompression capabilities of the sink device.
This entire block of registers is cached in intel_dp so that
capability information can be used during DSC configuration
phase during compute_config phase of the modeset.
For eDP, this caching happens during the eDP initialization.
This caching is done only for eDP and DP rev >= 1.4
v5:
* Fix the block comment (Gaurav)
* Fix the commit message DSC DPCD addresses (Gaurav)
* Use DRM_ERROR for dpcd_read fail (Gaurav,Anusha)
v4:
* Cache these only for Gen >= 11
v3:
* Remove the dsc_sink_support field in intel_dp (Jani N)
v2:
* Clear the cached registers on hotplug always (Jani N)
* Combine the eDP and DP caching in same function (Jani N)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031001923.31442-3-manasi.d.navare@intel.com
Add the newly added slice_row_per_frame parameter
in the Picture Parameter Set registers.
This defines the number of vertically stacked slices
in a frame.
Credits to Manasi for noticing bSpec change.
Suggested-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031001923.31442-1-manasi.d.navare@intel.com
Program the timeout values (in escape clock) for HS TX, LP RX and TA
timeout.
HX TX: Ensure that host does not continuously transmit in the HS
state. If this timer expires, then host will gracefully end its HS
transmission and allow the link to enter into LP state.
LP RX: Monitor the length of LP receptions from Peripheral. If timeout
happens then host will drive the stop state onto all data lanes (only
Data Lane 0 should be receiving anything from the Peripheral). This
effectively takes back ownership of the bus transmit in the HS state.
TA timeout: Timeout valuefor monitoring Bus Turn-Around (BTA) sequence.
BTA sequence should complete within a bounded amount of time, with
peripheral acknowledging BTA by driving the stop state.
v2 by Jani:
- Rebase
- Use intel_dsi_bitrate() and intel_dsi_tlpx_ns(intel_dsi)
- Squash HX TX, LP RX and TA timeout into one patch
- Fix bspec mode set sequence reference
- Add FIXME about two timeouts
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/60e610ccffe5f8c09dee1c65828f28f25227efce.1540900289.git.jani.nikula@intel.com
This patch sends command and executes display off,
assert reset, power off VBT seqeuences to power
down DSI panel. Patch also adds high level function
to wrap all the panel sepcific programming during
DSI disabling.
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/efdafbf6b4d31123738b87b2d8264a9b5553eb32.1540900289.git.jani.nikula@intel.com
Driver needs payload/header credits for sending any command
and data over DSI link. These credits are released once command
or data sent to link. This patch adds functions to wait for releasing
of payload and header credits.
As per BSPEC, driver needs to ensure that all of commands/data
has been dispatched to panel before the transcoder is enabled.
This patch implement those steps i.e. sending NOP DCS command,
wait for header/payload credit to be released etc.
v2 by Jani:
- squash the credit wait helpers patch with the first user
- pass dev_priv to the credit wait helpers
- bikeshed credit helper names
- wait for *at least* the current maximum number of credits
- indentation fix
- add helpers for credits available
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/84bc509beabf2a2d1324a9f2a67ab4ebe05b10a6.1540900289.git.jani.nikula@intel.com
Commit b24413180f ("License cleanup: add SPDX GPL-2.0 license
identifier to files with no license") added "SPDX-License-Identifier:
GPL-2.0" to files which previously had no license, change this to MIT
for intel_ringbuffer.h matching the license text of intel_ringbuffer.c.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181031005331.20775-1-jsg@jsg.id.au
GVT-g only simulates DP port for guest and leaves EDP_PSR_IMR
and EDP_PSR_IIR registers as default MMIO read/write.
So guest won't get expected initial values of these registers when
initializing the gpu driver, which results in following warning and logs.
--------
Interrupt register 0x64838 is not zero: 0xffffffff
WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/i915/i915_irq.c:177
gen3_assert_iir_is_zero+0x38/0xa0
Call Trace:
gen8_de_irq_postinstall+0xa7/0x400
gen8_irq_postinstall+0x27/0x80
drm_irq_install+0xbc/0x140
i915_driver_load+0xa9d/0xd50
--------
Because GVT-g does not handle EDP(embedded DP) simulation for guests,
always set EDP_PSR_IMR and EDP_PSR_IIR to value 0.
Signed-off-by: Longhe Zheng <longhe.zheng@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
CSFE_CHICKEN1(0x20d4) needs access with mask. This is caught in AcrnGT
conformance check test:
[drm:intel_gvt_vgpu_conformance_check]
*ERROR* gvt: vgpu1 unconformance mmio 0x20d4:0x40004,0x4
Signed-off-by: Xinyun Liu <xinyun.liu@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Previously we assumed two 4-byte writes to the same PTE coming in sequence.
But recently we observed inconsecutive partial write happening as well. So
this patch enhances the previous solution. It now uses a list to save more
partial writes. If one partial write can be combined with another one in
the list to construct a full PTE, update its shadow entry. Otherwise, save
the partial write in the list.
v2: invalidate old entry and flush ggtt (Zhenyu)
v3: split old ggtt page unmap to another patch (Zhenyu)
v4: refine codes (Zhenyu)
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Cc: Yan Zhao <yan.y.zhao@intel.com>
Cc: Xiaolin Zhang <xiaolin.zhang@intel.com>
Cc: Zhenyu Wang <zhenyu.z.wang@intel.com>
Reviewed-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
When using softpin it's not enough to just pad the vma size, we also
need to ensure the vma offset is at the start of the pt boundary, if we
plan to utilize 64K pages. Therefore to improve test coverage we should
use both aligned and unaligned gtt offsets in igt_write_huge.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029203734.21936-1-matthew.auld@intel.com
This reverts commit c9e666880d.
Checked GVT codes that guest PPGTT PTE flag bits are propagated
to shadow PTE. Read/write bit is not changed. Further tested by
i915 self-test case "igt_ctx_readonly". No error or GPU hang was
detected. So enable read-only support under GVT.
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1540883281-11359-1-git-send-email-hang.yuan@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
ICL supports DC5, DC6, and DC9. Enable DC9 during screen-off, and enable
DC5/6 when appropriate.
v2: (James Ausmus)
- Also handle ICL as GEN9_LP in i915_drm_suspend_late and
i915_drm_suspend_early
- Add DC9 to gen9_dc_mask for ICL
- Re-order GEN checks for newest platform first
- Use INTEL_GEN instead of INTEL_INFO->gen
- Use INTEL_GEN >= 11 instead of IS_ICELAKE
- Consolidate GEN checks
v3: (James Ausmus)
- Also allow DC6 for ICL (Imre, Art)
- Simplify !(GEN >= 11) to GEN < 11 (Imre)
v4: (James Ausmus)
- Don't call intel_power_sequencer_reset after DC9 for Gen11+, as the
PPS regs are Always On
- Rebase against upstream changes
v5: (Anusha Srivatsa)
- rebased against the latest upstream changes.
v6: (Anusha Srivatsa)
- rebased.Use INTEL_GEN consistently.
- Simplify the code (Rodrigo)
v7: rebased. Change order according to platforms(Jyoti)
v8: rebased. Change the check from platform specific to
HAS_PCH_SPLIT(). Add comment in code to be more clear.(Rodrigo)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Tested-by: Jyoti Yadav <jyoti.r.yadav@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/20181029221410.4423-1-anusha.srivatsa@intel.com
If we reduce the suspend function for intel_opregion to do the minimum
required, the resume function can also do the simple task of notifier
the ACPI bios that we are back. This avoid some nasty restrictions on
the likes of register_acpi_notifier() that are not allowed during the
early phase of resume.
v2: Keep the order of acpi notify vs turning off ardy/drdy the same.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181030110554.4111-1-chris@chris-wilson.co.uk
If we can prevent stray writes from landing in the scratch page, we can
reuse the same page and same scratch PT for all contexts without fear of
information leaks and side-channels.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029182721.29568-2-chris@chris-wilson.co.uk
Record the scratch PTE encoding upon creation rather than recomputing
the bits everytime. This is important for the next patch where we forgo
having a valid scratch page with which we may compute the bits and so
require keeping the PTE value instead.
v2: Fix up scrub_64K to use scratch_pte as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029182721.29568-1-chris@chris-wilson.co.uk
intel_fb_pitch_limit() has the parameters pixel_format and fb_modifier
switched in their positions. The parameters are however used correctly,
but change the order for consistency.
Also use kernel data types for both parameters.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026195342.16828-1-dhinakaran.pandiyan@intel.com
The PLANE_AUX_OFFSET mmio does not exist on ICL, do not program it. We'll
still calculate the aux offset as it is required for adjusing x-y offsets.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026193805.11077-2-dhinakaran.pandiyan@intel.com
A framebuffer can comprise surfaces with distinct tiling formats,
making checks against modifier alone insufficient. Make use of a
function to identify a linear surface based on both modifier and color
plane.
v2: Typo fix
v3: remove 'inline' from function definition (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026193805.11077-1-dhinakaran.pandiyan@intel.com
The specially case for SKL for not controlled sagv
is already taken care inside intel_enable_sagv, so there's
no need to duplicate the check here.
v2: Go one step further and remove skl special case. (Jani)
v3: Separate runtime status handle from has_sagv flag.
v4: Go back and accept simple Jani proposed solution.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026200317.21726-1-rodrigo.vivi@intel.com
The vm of two contexts are supposed to be independent, such that a stray
write by one cannot be detected by another. Normally the GTT is filled
explicitly by userspace, but the space in between objects is filled with
a scratch page -- and that scratch page should not be able to form an
inter-context backchannel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029172925.10159-1-chris@chris-wilson.co.uk
While checking the opportunity to add a display_gen
check to allow glk and cnl to be on same bucket I noticed
these FIXME cases here.
So I got the confirmation from HW architect that we actually
never needed this workaround.
"GLK supports 2 pixel per clock, so pixel clock can be up to 2 * cdclk."
So, this reverts commit 97f55ca5b6 ("drm/i915/glk: limit pixel
clock to 99% of cdclk workaround")
Fixes: 97f55ca5b6 ("drm/i915/glk: limit pixel clock to 99% of cdclk workaround")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Arthur J Runyan <arthur.j.runyan@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/20181026005636.22274-1-rodrigo.vivi@intel.com
commit ac657f6461 ("drm/i915: Introduce IS_GEN macro") introduced
GEN_FOREVER that was never used.
My first attempt was to rename it to FOREVER since GEN is
already part of the macro. Then I used coccinelle to change all
-INTEL_GEN(e1) >= e2
+INTEL_GEN_RANGE(e1, e2, FOREVER)
-INTEL_GEN(e1) <= e2
+INTEL_GEN_RANGE(e1, 0, e2)
and I liked it.
However I didn't like very much the remaining
INTEL_GEN(dev_priv) < n
and:
INTEL_GEN(e1) < n
INTEL_GEN_RANGE(e1, 0, n - 1)
didn't make much sense either.
So INTEL_GEN use for > or < seems a better unified way for unlimited
bounds. So, no reason to keep GEN_FOREVER here.
Let's kill before someone start using it.
v2: Remove remaining GEN_FOREVER forgotten in a comment. (Daniel)
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026195143.20353-2-rodrigo.vivi@intel.com
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
v4:
%s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma]
v5:
Added parentheses for the parameters of macro.
v6:
No changes
v7:
No changes
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540806351-7137-7-git-send-email-ramalingam.c@intel.com
Considering significant number of HDCP specific variables, it will
be clean to have separate struct for HDCP.
New structure called intel_hdcp is added within intel_connector.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
No Changes.
v4:
Commit msg is rephrased [Uma]
v5:
Comment for mutex definition.
v6:
hdcp_ prefix from all intel_hdcp members are removed [Sean Paul]
inline function intel_hdcp_to_connector is defined [Sean Paul]
v7:
%s/uint64_t/u64
v8:
Rebased
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540806351-7137-2-git-send-email-ramalingam.c@intel.com
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJbz8FfAAoJEAx081l5xIa+t8AQAJ6KaMM7rYlRDzIr1Vuh0++2
kFmfEQnSZnOWxO+zpyQpCJQr+/1aAHQ6+QzWq+/fX/bwH01H1Q4+z6t+4QoPqYlw
rUYXZYRxnqGVPYx8hwNLmRbJcsXMVKly1SemBXIoabKkEtPNX5AZ4FXCR2WEbsV3
/YLxsYQv2KMd8aoeC9Hupa07Jj9GfOtEo0a9B1hKmo+XiF9HqPadxaofqOpQ6MCh
54itBgP7Kj4mwwr8KxG2JCNJagG5aG8q3yiEwaU5b0KzWya4o1wrOAJcBaEAIxpj
JAgPde+f2L6w9dQbBBWeVFYKNn0jJqJdmbPs5Ek3i/NNFyx01Mn/3vlTZoRUqJN7
TGXwOI/BWz1iTaHyFPqVH6RPQAoUUDeCwgHkXonogFxvQLpiFG+dRNqxue0XVUMX
9tDSdZefWPoH3n9J/gDhwbV2Qbw/2n6yzCRYCb8HkqX1Y1JTmdYVgKvcnOwyYwsJ
QzcVkWUJ31UAaZcTLCEW6SVqcUR0mso3LJAPSKp2NJiVLL8mSd/ViUTUbxRNkkXf
H0abVGDjWAAZaT5uqNVqg4kV1Vc4Kj+/9QtspW4ktGezOz9DsctwJtfhTgOmT8Fx
zlEwWmAbf1iJP9UgqI7r4+Nq24saqUYmIX0bowEasLIRO+l14Pf9mQJjgKRcMs/j
SK4W5EreSFosKsxtQU4H
=3yxi
-----END PGP SIGNATURE-----
Merge tag 'drm-next-2018-10-24' of git://anongit.freedesktop.org/drm/drm
Pull drm updates from Dave Airlie:
"This is going to rebuild more than drm as it adds a new helper to
list.h for doing bulk updates. Seemed like a reasonable addition to
me.
Otherwise the usual merge window stuff lots of i915 and amdgpu, not so
much nouveau, and piles of everything else.
Core:
- Adds a new list.h helper for doing bulk list updates for TTM.
- Don't leak fb address in smem_start to userspace (comes with EXPORT
workaround for people using mali out of tree hacks)
- udmabuf device to turn memfd regions into dma-buf
- Per-plane blend mode property
- ref/unref replacements with get/put
- fbdev conflicting framebuffers code cleaned up
- host-endian format variants
- panel orientation quirk for Acer One 10
bridge:
- TI SN65DSI86 chip support
vkms:
- GEM support.
- Cursor support
amdgpu:
- Merge amdkfd and amdgpu into one module
- CEC over DP AUX support
- Picasso APU support + VCN dynamic powergating
- Raven2 APU support
- Vega20 enablement + kfd support
- ACP powergating improvements
- ABGR/XBGR display support
- VCN jpeg support
- xGMI support
- DC i2c/aux cleanup
- Ycbcr 4:2:0 support
- GPUVM improvements
- Powerplay and powerplay endian fixes
- Display underflow fixes
vmwgfx:
- Move vmwgfx specific TTM code to vmwgfx
- Split out vmwgfx buffer/resource validation code
- Atomic operation rework
bochs:
- use more helpers
- format/byteorder improvements
qxl:
- use more helpers
i915:
- GGTT coherency getparam
- Turn off resource streamer API
- More Icelake enablement + DMC firmware
- Full PPGTT for Ivybridge, Haswell and Valleyview
- DDB distribution based on resolution
- Limited range DP display support
nouveau:
- CEC over DP AUX support
- Initial HDMI 2.0 support
virtio-gpu:
- vmap support for PRIME objects
tegra:
- Initial Tegra194 support
- DMA/IOMMU integration fixes
msm:
- a6xx perf improvements + clock prefix
- GPU preemption optimisations
- a6xx devfreq support
- cursor support
rockchip:
- PX30 support
- rgb output interface support
mediatek:
- HDMI output support on mt2701 and mt7623
rcar-du:
- Interlaced modes on Gen3
- LVDS on R8A77980
- D3 and E3 SoC support
hisilicon:
- misc fixes
mxsfb:
- runtime pm support
sun4i:
- R40 TCON support
- Allwinner A64 support
- R40 HDMI support
omapdrm:
- Driver rework changing display pipeline ordering to use common code
- DMM memory barrier and irq fixes
- Errata workarounds
exynos:
- out-bridge support for LVDS bridge driver
- Samsung 16x16 tiled format support
- Plane alpha and pixel blend mode support
tilcdc:
- suspend/resume update
mali-dp:
- misc updates"
* tag 'drm-next-2018-10-24' of git://anongit.freedesktop.org/drm/drm: (1382 commits)
firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake.
drm/i915/icl: Fix signal_levels
drm/i915/icl: Fix DDI/TC port clk_off bits
drm/i915/icl: create function to identify combophy port
drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
drm/i915: Large page offsets for pread/pwrite
drm/i915/selftests: Disable shrinker across mmap-exhaustion
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode
drm/i915: Fix intel_dp_mst_best_encoder()
drm/i915: Skip vcpi allocation for MSTB ports that are gone
drm/i915: Don't unset intel_connector->mst_port
drm/i915: Only reset seqno if actually idle
drm/i915: Use the correct crtc when sanitizing plane mapping
drm/i915: Restore vblank interrupts earlier
drm/i915: Check fb stride against plane max stride
drm/amdgpu/vcn:Fix uninitialized symbol error
drm: panel-orientation-quirks: Add quirk for Acer One 10 (S1003)
drm/amd/amdgpu: Fix debugfs error handling
drm/amdgpu: Update gc_9_0 golden settings.
drm/amd/powerplay: update PPtable with DC BTC and Tvr SocLimit fields
...
- Remove unused fallback for BUILD_BUG_ON (which technically contains a VLA)
- Lift -Wvla to the top-level Makefile
-----BEGIN PGP SIGNATURE-----
Comment: Kees Cook <kees@outflux.net>
iQJKBAABCgA0FiEEpcP2jyKd1g9yPm4TiXL039xtwCYFAlvV7jMWHGtlZXNjb29r
QGNocm9taXVtLm9yZwAKCRCJcvTf3G3AJkUwD/46aPTmVXQqzVr1QxRC087Aou5H
hCMaUSG0mSuinhIpB398xh58imTqz48n44gf8yrBgittecV+g8cQ3TJZBp8fSbj4
zyuSy0xlghxqNYhsirMPdN61A8qOS/F7i60XFBXSKpdzKorUUsqlP6paDg1CWslB
KWIOr2aHxvQk93pHFsWjOeM7CGqQIq1brKKDPAL+R4zj8EzXfi0s1sOR4tHCXRZP
sTsuHysAjsBlaw54tvbCA5SIyABzZK5xsQoeChSKMoCDQb8TOQK4j8f78470/nmk
lFWZWGKFr2sPUPcuf1casL5Cp57ycjwi4qTzKX2Qa1hhEhrYTIvcOwzOWdc0AY+6
Fttbopla1QmrGndLtm8FOJRGWiCAzhiSpV9vk1VDaP2jeCc6MEvTC0shsAgxSfsr
JRIHqq37w3TBr78qeNuxOaSEkoqtjTVYug2aq7kefG66DGGChzCTVNQrLVNei3Qg
ZdamzUZz7FVV6WmXlWsBfbm14sIRd02r7XORm0cJdIVvIwqJ9QIGJigR/Sfc4Qdi
pXuuE3TNSfArACXlCkaBfqMYAhWO35qy41TerRlRDkri89DNHPY8RAVV0GpNSp7q
kPaPBHZRKXAjHPnnypXz3A/zQoqJ7uWRG5msethAWtEXJBQ4qQWVhjTNmV7tkOkr
HIaJFTb03LLIcuv23Q==
=Vnw8
-----END PGP SIGNATURE-----
Merge tag 'vla-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull VLA removal from Kees Cook:
"Globally warn on VLA use.
This turns on "-Wvla" globally now that the last few trees with their
VLA removals have landed (crypto, block, net, and powerpc).
Arnd mentioned that there may be a couple more VLAs hiding in
hard-to-find randconfigs, but nothing big has shaken out in the last
month or so in linux-next.
We should be basically VLA-free now! Wheee. :)
Summary:
- Remove unused fallback for BUILD_BUG_ON (which technically contains
a VLA)
- Lift -Wvla to the top-level Makefile"
* tag 'vla-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
Makefile: Globally enable VLA warning
compiler.h: give up __compiletime_assert_fallback()
Pull XArray conversion from Matthew Wilcox:
"The XArray provides an improved interface to the radix tree data
structure, providing locking as part of the API, specifying GFP flags
at allocation time, eliminating preloading, less re-walking the tree,
more efficient iterations and not exposing RCU-protected pointers to
its users.
This patch set
1. Introduces the XArray implementation
2. Converts the pagecache to use it
3. Converts memremap to use it
The page cache is the most complex and important user of the radix
tree, so converting it was most important. Converting the memremap
code removes the only other user of the multiorder code, which allows
us to remove the radix tree code that supported it.
I have 40+ followup patches to convert many other users of the radix
tree over to the XArray, but I'd like to get this part in first. The
other conversions haven't been in linux-next and aren't suitable for
applying yet, but you can see them in the xarray-conv branch if you're
interested"
* 'xarray' of git://git.infradead.org/users/willy/linux-dax: (90 commits)
radix tree: Remove multiorder support
radix tree test: Convert multiorder tests to XArray
radix tree tests: Convert item_delete_rcu to XArray
radix tree tests: Convert item_kill_tree to XArray
radix tree tests: Move item_insert_order
radix tree test suite: Remove multiorder benchmarking
radix tree test suite: Remove __item_insert
memremap: Convert to XArray
xarray: Add range store functionality
xarray: Move multiorder_check to in-kernel tests
xarray: Move multiorder_shrink to kernel tests
xarray: Move multiorder account test in-kernel
radix tree test suite: Convert iteration test to XArray
radix tree test suite: Convert tag_tagged_items to XArray
radix tree: Remove radix_tree_clear_tags
radix tree: Remove radix_tree_maybe_preload_order
radix tree: Remove split/join code
radix tree: Remove radix_tree_update_node_t
page cache: Finish XArray conversion
dax: Convert page fault handlers to XArray
...
HDMI 2.0 monitors may not support SCDC and still be able to accept VICs
above 63. Use multiple EDID capbilities to determine if the SINK is
actually an HDMI 2.0 device. The QD980B HDMI 2.0 Analyzer generates unique
EDIDs during CTS tests that don't contain a HDMI Forum VSDB if the block is
not used during the test. The current HDMI AVI infoframe code only uses the
SCDC supported information in the HDMI Forum VSDB to determine if the sink
is HDMI 2.0. This patch adds a check for YCbCr420 present in the EDID
supported formats as well as the existing SCDC supported check.
HDMI 2.0 CTS HF1-51 test fails on the QD980B.
V2: Make check for display_info->color formats == YCbCR420 and SCDC
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107894
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1540415073-5102-1-git-send-email-clinton.a.taylor@intel.com
Use the live_test struct to record the reset count before and compare it
at the end of the test to assert that no mystery hang occurred during the
test.
v2: Check per-engine resets as well
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181012122404.10874-1-chris@chris-wilson.co.uk
Upcoming GuC code will need to read the fused off engine masks as well,
and will also want to have them as enabled instead of disabled masks.
To consolidate the read-out place we can store them in this fashion inside
INTEL_INFO so they can be easily referenced in the future.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018104106.30147-1-tvrtko.ursulin@linux.intel.com
In order to ensure that our system suspend and resume callbacks are
called in the correct order wrt. those of the HDA driver add a device
link to the HDA driver during audio component binding time. With i915 as
the supplier and HDA as the consumer the PM framework will guarantee
the HDA->i915 suspend (and shutdown) and i915->HDA resume order.
Atm, the lack of this ordering is not a problem, since all the i915
suspend/resume steps that need to be ordered wrt. the HDA driver's
suspend/resume steps are separated out to the i915
suspend_late/resume_early hooks. That will change in a follow-up
patchset where we'll need this ordering guarantee for steps that are in
the i915 suspend/resume hooks (and which can't be moved to
suspend_late/resume_early for other reasons). So this patch is a
preparation for that follow-up patchset.
The change also allows us to move towards removing the i915
suspend_late/resume_early hooks alltogether.
Since we only need to ensure the ordering during suspend/resume and not
during driver probing create the link with DL_FLAG_STATELESS. Since the
probe time ordering has to be optional we use the component framework
for that.
Similarly for runtime PM we depend on the audio driver getting/putting
an i915 runtime PM reference whenever it needs it (along with the proper
i915 display power domain) via the audio component ops get_power /
put_power hooks. So we create the device link without
DL_FLAG_PM_RUNTIME.
v2: (Ville)
- Add a note to the commit message about not using the device link
runtime PM ordering.
- Handle the error return from device_link_add().
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Lukas Wunner <lukas@wunner.de>
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/20181023144310.8272-1-imre.deak@intel.com
Let's support simultaneous submissions to multiple engines.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Link: https://patchwork.kernel.org/patch/10626149/
4.19 is out, Lyude asked for a backmerge, and it's been a while. All
very good reasons on their own :-)
Signed-off-by: Sean Paul <seanpaul@chromium.org>
make W=1 caught the implicit prototypes (as would sparse):
drivers/gpu/drm/i915/intel_sprite.c:462:1: error: no previous prototype for ‘skl_update_plane’ [-Werror=missing-prototypes]
skl_update_plane(struct intel_plane *plane,
^~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/intel_sprite.c:487:1: error: no previous prototype for ‘skl_disable_plane’ [-Werror=missing-prototypes]
skl_disable_plane(struct intel_plane *plane, struct intel_crtc *crtc)
^~~~~~~~~~~~~~~~~
Fixes: 1e364f9008 ("drm/i915/gen11: Program the Y and UV plane for planar mode correctly, v3.")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024105402.18915-1-chris@chris-wilson.co.uk
Forgot to add the description of this option in a previous commit.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: cd956bfcd0 ("drm/i915/perf: add a parameter to control the size of OA buffer")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024105158.4732-1-lionel.g.landwerlin@intel.com
The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to
the appropriate platforms.
This was especially harsh on GLK since we don't even try to read
the DIMM information on that platforms, hence valid_dimm was
always false and thus we always tried to apply the w/a.
Furthermore the w/a pushed the level 0 latency above the
level 1 latency, which doesn't really make sense.
v2: Do the check when populating is_16gb_dimm (Mahesh)
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 86b592876c ("drm/i915: Implement 16GB dimm wa for latency level-0")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023182102.31549-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
Commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check,
unconditionally during long pulse"")' applies a work around for sinks
that don't signal link loss. The work around does not need to have to be
that broad as the issue was seen with only one particular monitor; limit
this only for external displays as eDP features like PSR turn off the link
and the driver ends up retraining the link seeeing that link is not
synchronized.
Cc: Lyude Paul <lyude@redhat.com>
Cc: Jan-Marek Glogowski <glogow@fbihome.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
References: 3cf71bc990 ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-2-dhinakaran.pandiyan@intel.com
(cherry picked from commit f24f6eb958)
Fixes: 399334708b ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")
Cc: stable@vger.kernel.org
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Comment claims link needs to be retrained because the connected sink raised
a long pulse to indicate link loss. If the sink did so,
intel_dp_hotplug() would have handled link retraining. Looking at the
logs in Bugzilla referenced in commit '3cf71bc9904d ("drm/i915: Re-apply
Perform link quality check, unconditionally during long pulse"")', the
issue is that the sink does not trigger an interrupt. What we want is
->detect() from user space to check link status and retrain. Ville's
review for the original patch also indicates the same root cause. So,
rewrite the comment.
v2: Patch split and rewrote comment.
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jan-Marek Glogowski <glogow@fbihome.de>
References: 3cf71bc990 ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-1-dhinakaran.pandiyan@intel.com
(cherry picked from commit 9ebd820239)
Fixes: 399334708b ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")
Cc: stable@vger.kernel.org
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Now that we implemented support for planar formats on gen11, we can
finally advertise it.
Changes since v1:
- Re-add change to skl_plane_has_planar(), was lost in rebase noise.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022134514.14756-1-maarten.lankhorst@linux.intel.com
The UV plane is the master plane that does all color correction etc.
It needs to be programmed with the dimensions for color plane 1 (UV).
The Y plane just feeds the Y pixels to it. Program the scaler from the
master only, and set PLANE_CTL_YUV420_Y_PLANE on the slave plane.
Changes since v1:
- Make a common skl_program_plane, and use it for both plane updates.
Changes since v2:
- Make color_plane explicit, to clarify skl_update_plane(). (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018115134.9061-8-maarten.lankhorst@linux.intel.com
We configure the chroma upsampler with the same chroma siting as
used by the scaler for consistency, the chroma upsampler is used
instead of the scaler for YUV 4:2:0 on ICL's HDR planes.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018115134.9061-7-maarten.lankhorst@linux.intel.com
The first 3 planes (primary, sprite 0 and 1) have a dedicated chroma
upsampler to upscale YUV420 to YUV444 and the scaler should only be
used for upscaling. Because of this we shouldn't program the scalers
in planar mode if NV12 and the chroma upsampler are used. Instead
program the scalers like on normal planes.
Sprite 2 and 3 have no dedicated scaler, and need to program the
selected Y plane in the scaler mode.
Changes since v1:
- Make the comment less confusing.
Changes since v2:
- Fix checkpatch warning (Matt)
- gen10- -> Pre-gen11 (Ville)
- PS_SCALER_MODE_PACKED -> PS_SCALER_MODE_NORMAL. (Matt)
- Add comment about scaler mode in intel_atomic_setup_scaler(). (Matt)
- Rename need_scaling to need_scaler. (Matt)
- Move the crtc need_scaling check to skl_update_scaler_crtc().
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018115134.9061-6-maarten.lankhorst@linux.intel.com
Skylake style watermarks program the UV parameters into wm->uv_wm,
and have a separate DDB allocation for UV blocks into the same plane.
Gen11 watermarks have a separate plane for Y and UV, with separate
mechanisms. The simplest way to make it work is to keep the current
way of programming watermarks and calculate the Y and UV plane
watermarks from the master plane.
Changes since v1:
- Constify crtc_state where possible.
- Make separate paths for planar formats in skl_build_pipe_wm() (Matt)
- Make separate paths for calculating total data rate. (Matt)
- Make sure UV watermarks are unused on gen11+ by adding a WARN. (Matt)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018115134.9061-5-maarten.lankhorst@linux.intel.com
To make NV12 working on icl, we need to update 2 planes simultaneously.
I've chosen to do this in the CRTC step after plane validation is done,
so we know what planes are (in)visible. The linked Y plane will get
updated in intel_plane_update_planes_on_crtc(), by the call to
update_slave, which gets the master's plane_state as argument.
The link requires both planes for atomic_update to work,
so make sure skl_ddb_add_affected_planes() adds both states.
Changes since v1:
- Introduce icl_is_nv12_y_plane(), instead of hardcoding sprite numbers.
- Put all the state updating login in intel_plane_atomic_check_with_state().
- Clean up changes in intel_plane_atomic_check().
Changes since v2:
- Fix intel_atomic_get_old_plane_state() to actually return old state.
- Move visibility changes to preparation patch.
- Only try to find a Y plane on gen11, earlier platforms only require
a single plane.
Changes since v3:
- Fix checkpatch warning about to_intel_crtc() usage.
- Add affected planes from icl_add_linked_planes() before check_planes(),
it's a cleaner way to do this. (Ville)
Changes since v4:
- Clear plane links in icl_check_nv12_planes() for clarity.
- Only pass crtc_state to icl_check_nv12_planes().
- Use for_each_new_intel_plane_in_state() in icl_check_nv12_planes.
- Rename aux to linked. (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022135152.15324-1-maarten.lankhorst@linux.intel.com
[mlankhorst: Change bool slave to u32, to satisfy checkpatch]
[mlankhorst: Add WARN_ON's based on Ville's suggestion]
When a HDCP authentication is in progress, if the display sink is
hot unplugged, all DDC/AUX transaction related to the HDCP
authentication will fail.
This patch moves those kind of HDCP DDC/AUX failures into the debug
logs instead of errors.
v2:
Bksv invalid state is provided as debug msg
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540291288-22185-1-git-send-email-ramalingam.c@intel.com
Add a debugfs entry for providing the hdcp capabilities of the sink
connected to the HDCP capable connectors.
v2:
Squashed the sink's hdcp capability into this patch. [Daniel]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540286550-20399-4-git-send-email-ramalingam.c@intel.com
HDCP check link is invoked only on CP_IRQ detection, instead of all
short pulses.
v3:
No Changes.
v4:
Added sean in cc and collected the reviewed-by received.
v5:
No Change.
v6:
No Change.
v7:
No Change.
v8:
Rebased.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540286550-20399-3-git-send-email-ramalingam.c@intel.com
For reusability purpose, this patch implements the hdcp1.4 bksv's
read and validation as a functions.
For detecting the HDMI panel's HDCP capability this fucntions will be
used.
v2:
Rebased.
v3:
No Changes.
v4:
inline tag is removed with modified error msg.
v5:
No Changes.
v6:
No Changes.
v7:
Realigned the code.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1540286550-20399-2-git-send-email-ramalingam.c@intel.com
Propagate the timeout on transferring the fw back to the caller where it
may act upon it, usually by restarting the xfer before failing.
v2: Simplify the wait to only wait upon the guc signaling completion,
with an assertion that the fw xfer must have completed for it to be
ready!
Testcase: igt/drv_selftest/live_hangcheck
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018195536.11522-1-chris@chris-wilson.co.uk
Let's run through the entire plane check even when the plane
is invisible due to zero constant alpha. This makes for more
consistent behaviour since we check the src/dst coordinates,
stride etc. against the hardware limits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018195921.9898-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
The SKL+ NV12 src width alignment w/a is still living in an odd place.
Everything else was already relocated closer to the main plane check
function. Move this workaround as well.
As a bonus we avoid the funky rotated vs. not mess with the src
coordinates as this now gets checked before we rotate the coordinates.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018195921.9898-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
The way our hardware is designed doesn't seem to let us use the
MI_RECORD_PERF_COUNT command without setting up a circular buffer.
In the case where the user didn't request OA reports to be available
through the i915 perf stream, we can set the OA buffer to the minimum
size to avoid consuming memory which won't be used by the driver.
v2: Simplify oa buffer size exponent selection (Chris)
Reuse vma size field (Lionel)
v3: Restrict size opening parameter to values supported by HW (Chris)
v4: Drop out of date comment (Matt)
Add debug message when buffer size is rejected (Matt)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023100707.31738-5-lionel.g.landwerlin@intel.com
We initialize the OA buffer everytime we enable the OA unit (first call in
gen[78]_oa_enable), so we don't need to initialize when preparing the metric
set.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023100707.31738-3-lionel.g.landwerlin@intel.com
commit e346a991f4 ("drm/i915/guc: drop negative doorbell alloc
selftest") removed the negative case from the selftest and left no
code between the goto from the positive case of the test and the label
itself, so we can get rid of it.
Reported-by: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022230427.5616-5-daniele.ceraolospurio@intel.com
We stopped supporting fallback to execlists in commit 121981fafe
(drm/i915/guc: Combine enable_guc_loading|submission modparams). We
do instead reset and retry in some cases, depending on the workarounds
required by the platform.
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20181022230427.5616-4-daniele.ceraolospurio@intel.com
A collection of very small cleanups/improvements around doorbell checking
that do not deserve their own patch:
- Move doorbell-related HW defs to intel_guc_reg.h
- use GUC_NUM_DOORBELLS instead of GUC_DOORBELL_INVALID where
appropriate
- do not stop on error in guc_verify_doorbells
- do not print drbreg on error: the only content of the register
apart from the valid bit is the lower part of the physical memory
address, which we can't use even if valid because we don't know
which descriptor it came from (since the doorbell is in an unexpected
state)
- Move the checking of doorbell valid bit to a common helper.
v2: add more cleanups (move defs, use GUC_NUM_DOORBELLS, don't stop in
guc_verify_doorbells) (Michal)
v3: move more things to intel_guc_reg, redefine
GUC_DOORBELL_INVALID (Michal), drop guc_doorbell_qw since it just
duplicates guc_doorbell_info
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20181022230427.5616-3-daniele.ceraolospurio@intel.com
Cacheline selection is only needed if we actually manage to reserve a
doorbell.
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022230427.5616-2-daniele.ceraolospurio@intel.com
The 2 functions don't create or destroy anything, they just update the
doorbell state in memory. Use init and fini instead for clarity.
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181022230427.5616-1-daniele.ceraolospurio@intel.com
Just sorting this "if" block from newer to older platform.
The main difference here is the addition of a
missing case with return false that should never occur.
And if it occurs it is better than to raise a warn
than use the icl one.
The gen >= 11 was already present in the previous logic,
although hidden.
So, in summary no real functional change.
Cc: Jani Nikula <jani.nikula@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/20181022171526.15641-3-rodrigo.vivi@intel.com
No functional change.
Just sorting this "if" block from newer to older platform.
v2: Invert gen9_bc and gen9_lp (Ville)
Cc: Jani Nikula <jani.nikula@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/20181022171526.15641-1-rodrigo.vivi@intel.com
This patch defines TRANS_CONF registers for DSI ports
0 and 1. Bitfields of these registers used for enabling
and reading the current state of transcoder.
v2: Add blank line before comment
v3 by Jani:
- Move DSI specific .pipe_offsets to GEN11_FEATURES
- Macro placement and comment juggling
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3aa11e41ea0d4eb434423cc5ddf0a63b19d54deb.1539613303.git.jani.nikula@intel.com
As part of DSI enable sequence, transcoder timings
(horizontal & vertical) need to be set so that transcoder
will generate the stream output as per those timings.
This patch set required transcoder timings as per BSPEC.
v2: Remove TRANS_TIMING_SHIFT usage
v3 by Jani:
- Rebase
- Reduce temp variable use
- Checkpatch fix
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/525949ae4e919a4f2b807d606234322534656048.1539613303.git.jani.nikula@intel.com
This patch defines TRANS_DDI_FUNC_CTL and TRANS_DDI_FUNC_CTL2
registers and their bitfields for DSI. These registers are used
for enabling port sync mode, input pipe select, data lane width
configuration etc.
v2: Changes:
- Remove redundant extra line
- Correct some of bitfield definition
v3 by Jani:
- Move DSI transcoder offsets to GEN11_FEATURES
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6b2d87db82660320be10e423742cbf5a31e18037.1539613303.git.jani.nikula@intel.com
We wrongly assumed that GuC is only using last scratch register
for G2H messages, but in fact it is also using register [14] to
report sleep state status. Remove that register from our H2G
send registers pool.
v2: No message from host to GuC uses more than 8 registers and
the GuC FW itself uses an 8-element array to store the H2G message,
so we may reduce our send array to just 8 registers (Daniele)
v3: use explicit define (Daniele)
v4: and explicit comment (Daniele)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181019101725.14024-1-michal.wajdeczko@intel.com
This patch programs DSI operation mode, pixel format,
BGR info, link calibration etc for the DSI transcoder.
This patch also extract BGR info of the DSI panel from
VBT and save it inside struct intel_dsi which used for
configuring DSI transcoder.
v2: Rebase
v3: Use newly defined bitfields.
v4 by Jani:
- Use intel_dsi_bitrate()
- Make bgr_enabled bool
- Use 0 instead of 0x0
- Replace DRM_ERROR() with MISSING_CASE() on pixel format and video mode
- Use is_vid_mode()
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7de4e39a4b2a18e53a2b9d9cea5b5b4c9d6eeb34.1539613303.git.jani.nikula@intel.com
This patch defines transcoder function configuration
registers and its bitfields for both DSI ports.
Used while programming/enabling DSI transcoder.
v2: Changes (Jani N)
- Define _SHIFT and _MASK for bitfields
- Define values for fields already shifted in place
v3 by Jani:
- Fix _SHIFT fields copy-pasted from _MASK
- Indentation fixes
- Reduce S3D orientation to single macro
- Wrap a macro parameter in parens
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f188d3e59f27cbcac87d331af3d0222249db7fe4.1539613303.git.jani.nikula@intel.com
This patch programs D-PHY timing parameters for the
bus turn around flow(in escape clocks) only if dsi link
frequency <=800 MHz using DPHY_TA_TIMING_PARAM and its
identical register DSI_TA_TIMING_PARAM (inside DSI
Controller within the Display Core).
v2: Changes
- Don't use KHz() macro (Ville/Jani N)
- Use newly defined bitfields
v3 by Jani:
- Use intel_dsi_bitrate() in favor of a new field
- Remove redundant parens
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2c777092a748dfc973714399d8c19ed7a8c31a10.1539613303.git.jani.nikula@intel.com
This patch programs D-PHY timing parameters for the
clock and data lane (in escape clocks) of DSI
controller (DSI port 0 and 1).
These programmed timings would be used by DSI Controller
to calculate link transition latencies of the data and
clock lanes.
v2: Use newly defined bitfields for data and clock lane
v3 by Jani:
- Rebase on dphy abstraction
- Reduce local variables
- Remove unrelated comment changes (Ville)
- Use the same style for range checks as VLV (Ville)
- Assign, don't OR dphy_reg contents
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/70d491e2357f328a63b67ea3c43cb57a1d469c15.1539613303.git.jani.nikula@intel.com
Currently the guest couldn't boot up under GVT-g environment as the
following call trace exists:
[ 272.504762] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
[ 272.504834] Call Trace:
[ 272.504852] execlists_context_pin+0x2b2/0x520 [i915]
[ 272.504869] intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
[ 272.504887] intel_vgpu_create_workload+0x3e2/0x570 [i915]
[ 272.504901] intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
[ 272.504916] elsp_mmio_write+0xc7/0x130 [i915]
[ 272.504930] intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
[ 272.504944] intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
[ 272.504947] intel_vgpu_rw+0x22d/0x270 [kvmgt]
[ 272.504949] intel_vgpu_write+0x164/0x1f0 [kvmgt]
GVT GEM context is created by i915_gem_context_create_gvt() which
doesn't allocate ppgtt. So GVT GEM context structure doesn't have
a valid i915_hw_ppgtt.
This patch create ppgtt table at GVT GEM context creation, then assign
shadow ppgtt's root table address to this ppgtt when shadow ppgtt will
be used on GPU. So GVT GEM context has valid ppgtt address. But note
that this ppgtt only contain valid ppgtt root table address, the table
entry in this ppgtt structure are invalid.
Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for execlists")
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1539841231-3157-1-git-send-email-xiong.y.zhang@intel.com
Unfortunately, it appears our fix in:
commit b5d29843d8 ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976 ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976 ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
(cherry picked from commit 39b50c6038)
Fixes: e96550956f ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Fixes: 34ca26a98a ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: stable@vger.kernel.org
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Replace the kvmalloc_array() with i915_gem_object_get_dma_address() when
populating rotated vmas. One random access mechanism ought to be enough
for everyone?
To calculate the size of the radix tree I think we can do
something like this (assuming 64bit pointers):
num_pages = obj_size / 4096
tree_height = ceil(log64(num_pages))
num_nodes = sum(64^n, n, 0, tree_height-1)
tree_size = num_nodes * 576
If we compare that with the object size we should get a relative
overhead of around .2% to 1% for reasonable sized objects,
which framebuffers tend to be.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Suggested-by: 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/20181016150413.11577-1-ville.syrjala@linux.intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Use single exit point to drop rpm wakeref in case of an error.
Fixes: 9d3eb2c33f ("drm/i915: Hold rpm wakeref for debugfs/i915_drop_caches_set")
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018092025.24076-1-joonas.lahtinen@linux.intel.com
The test requires driver tweaks to avoid causing error messages
on intentionally-triggered errors and to stop accessing non
existing register. However, this is a pure GuC FW interface test
and should be covered by FW validation, so it isn't really worth
tweaking the driver for it and we're better off dropping it instead.
Testing the driver running out of doorbells is already covered by
igt_guc_doorbells
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20181018004610.22895-1-daniele.ceraolospurio@intel.com
intel_dsi_vbt_init() has grown too unwieldy, and it's about to be
modified due to ICL DSI. Abstract out the VLV specific dphy param
init. No functional changes. Intentionally no stylistic changes during
code movement.
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/96d15760db027a137f298ec330520ef8ec6474b0.1539613303.git.jani.nikula@intel.com
Encoders are not alike, make enable and disable hooks optional like
other hooks. Utilize this in DSI code, and remove the silly nop hook.
v2: Add the check also to intel_sanitize_encoder() (Madhav)
Reviewed-by: Madhav Chauhan <madhav.chauhan@intel.com>
Acked-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016124134.10257-1-jani.nikula@intel.com
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline syncobj.
* CPU wait - A host operation that allows a blocking wait for a
timeline syncobj to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline syncobj to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline syncobj to a specified value.
v1:
Since it's a timeline, that means the front time point(PT) always is signaled before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline value, then wait PT will be
signaled, otherwise keep in list. syncobj wait operation can wait on any point of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch. (Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt list.
b. normal syncobj wait op will create a wait pt with last signal point, and this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
v5: (Christian)
1. semaphore is called syncobj in kernel side.
2. don't need 'timeline' characters in some function name.
3. keep syncobj cb.
v6: (Christian)
1. merge syncobj_timeline to syncobj structure.
2. simplify some check sentences.
3. some misc change.
4. fix CTS failed issue.
v7: (Christian)
1. error handling when creating signal pt.
2. remove timeline naming in func.
3. export flags in find_fence.
4. allow reset timeline.
v8:
1. use wait_event_interruptible without timeout
2. rename _TYPE_INDIVIDUAL to _TYPE_BINARY
v9:
1. rename signal_pt->base to signal_pt->fence_array to avoid misleading
2. improve kerneldoc
individual syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: Christian Konig <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Rakos <Daniel.Rakos@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/257258/
In response for I915_PARAM_HAS_HUC we are returning value that
indicates if HuC firmware was loaded and verified. However, our
previously used positive value was based on specific register bit
which is about to change on future platform. Let's normalize our
return values to 0 and 1 before clients will start to use Gen9 value.
v2: use bool for implicit conversion (Chris)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Haihao Xiang <haihao.xiang@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> #1
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20181017195245.39644-1-michal.wajdeczko@intel.com
GEM_WARN_ON currently has dangerous semantics where it is completely
compiled out on !GEM_DEBUG builds. This can leave users who expect it to
be more like a WARN_ON, just without a warning in non-debug builds, in
complete ignorance.
Another gotcha with it is that it cannot be used as a statement. Which is
again different from a standard kernel WARN_ON.
This patch fixes both problems by making it behave as one would expect.
It can now be used both as an expression and as statement, and also the
condition evaluates properly in all builds - code under the conditional
will therefore not unexpectedly disappear.
To satisfy call sites which really want the code under the conditional to
completely disappear, we add GEM_DEBUG_WARN_ON and convert some of the
callers to it. This one can also be used as both expression and statement.
>From the above it follows GEM_DEBUG_WARN_ON should be used in situations
where we are certain the condition will be hit during development, but at
a place in code where error can be handled to the benefit of not crashing
the machine.
GEM_WARN_ON on the other hand should be used where condition may happen in
production and we just want to distinguish the level of debugging output
emitted between the production and debug build.
v2:
* Dropped BUG_ON hunk.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181012063142.16080-1-tvrtko.ursulin@linux.intel.com
Since when it was introduced we forgot to add
this case so ICL was using a wrong signal_levels
as reference.
Fixes: fb5c8e9d43 ("drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181017215652.26841-1-rodrigo.vivi@intel.com
(cherry picked from commit 61cdfb9e19)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
DDI/TC clock-off bits are not equally distanced. TC1-3 bits are
from offset 12 & TC4 is at offset 21.
Create a function to choose correct clk-off bit.
v2: Add fixes tag (Lucas)
Fixes: c27e917e2b ("drm/i915/icl: add basic support for the ICL clocks")
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016023752.9285-1-lucas.demarchi@intel.com
(cherry picked from commit bb1c7edc6d)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
This patch creates a function/wrapper to check if port is combophy port
instead of explicitly comparing ports.
Changes since V1:
- keep all intel_port_is_* helper together (Lucas)
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181004085043.10154-1-mahesh1.kumar@intel.com
(cherry picked from commit 176597a12d)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb54 ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: <ronald@innovation.ch>
Cc: <stable@vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reported-by: <ronald@innovation.ch>
Tested-by: <ronald@innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffac ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
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/20181016160011.28347-1-imre.deak@intel.com
(cherry picked from commit 914a4fd8cd)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
