Jani Nikula [Mon, 30 Nov 2020 11:16:00 +0000 (13:16 +0200)]
drm/i915/gvt: replace I915_WRITE with intel_uncore_write
Let's avoid adding new I915_WRITE uses while we try to get rid of them.
Fixes: 5f60b12edcd0 ("drm/i915/gvt: Save/restore HW status to support GVT suspend/resume") Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Hang Yuan <hang.yuan@linux.intel.com> Cc: Colin Xu <colin.xu@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130111601.2817-9-jani.nikula@intel.com
Uma Shankar [Mon, 30 Nov 2020 20:47:34 +0000 (02:17 +0530)]
drm/i915/lspcon: Create separate infoframe_enabled helper
Lspcon has Infoframes as well as DIP for HDR metadata(DRM Infoframe).
Create a separate mechanism for lspcon compared to HDMI in order to
address the same and ensure future scalability.
v2: Streamlined this as per Ville's suggestions, making sure that
HDMI infoframe versions are directly returned instead of a redundant
and confusing DIP overhead.
Uma Shankar [Mon, 30 Nov 2020 20:47:31 +0000 (02:17 +0530)]
drm/i915/display: Enable colorspace programming for LSPCON devices
Enable HDMI Colorspace for LSPCON based devices. Sending Colorimetry
data for HDR using AVI infoframe. LSPCON firmware expects this and though
SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
which transfers the same to HDMI sink.
v2: Dropped state managed in drm core as per Jani Nikula's suggestion.
v3: Aligned colorimetry handling for lspcon as per compute_avi_infoframes,
as suggested by Ville.
v4: Finally fixed this with Ville's help, re-phrased the commit header
and description.
v5: Register HDMI colorspace for lspcon and move this to
intel_dp_add_properties as we can't create property at late_register.
Ville Syrjälä [Mon, 30 Nov 2020 20:47:30 +0000 (02:17 +0530)]
drm/i915: Split intel_attach_colorspace_property() into HDMI vs. DP variants
With LSPCON we use the AVI infoframe to convey the colorimetry
information (as opposed to DP MSA/SDP), so the property we expose
should match the values we can stuff into the infoframe. Ie. we
must use the HDMI variant of the property, even though we drive
LSPCON in PCON mode. To that end just split
intel_attach_colorspace_property() into HDMI and DP variants
and let the caller worry about which one it wants to use.
Uma Shankar [Mon, 30 Nov 2020 20:47:25 +0000 (02:17 +0530)]
drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon
Gen9 hardware supports HDMI2.0 through LSPCON chips.
Extending HDR support for MCA LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
Mastering Infoframe (DRM packets) and send it to HDR capable
HDMI sink devices.
v2: Re-used hsw infoframe write implementation for HDR metadata
for LSPCON as per Ville's suggestion.
v3: Addressed Jani Nikula's review comments.
v4: Addressed Ville's review comments, removed redundant wrapper
and checks, passed arguments instead of hardcodings.
Uma Shankar [Mon, 30 Nov 2020 20:47:24 +0000 (02:17 +0530)]
drm/i915/display: Add HDR Capability detection for LSPCON
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
DPCD register. LSPCON implementations capable of supporting
HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
reads the same, detects the HDR capability and adds this to
intel_lspcon struct.
v2: Addressed Jani Nikula's review comment and fixed the HDR
capability detection logic
v3: Deferred HDR detection from lspcon_init (Ville)
v4: Addressed Ville's minor review comments, added his RB.
Add the calculations to set plane selective fetch registers depending
in the value of the area damaged.
It is still using the whole plane area as damaged but that will change
in next patches.
v2:
- fixed new_plane_state->uapi.dst.y2 typo in
intel_psr2_sel_fetch_update()
- do not shifthing new_plane_state->uapi.dst only src is in 16.16 format
BSpec: 55229 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130125750.17820-1-jose.souza@intel.com
Jani Nikula [Mon, 30 Nov 2020 11:15:59 +0000 (13:15 +0200)]
drm/i915/irq: replace I915_READ()/WRITE() with intel_uncore_read()/write()
Arguably some of these should use intel_de_read() or intel_de_write(),
however not all. Prioritize I915_READ() and I915_WRITE() removal in
general over migrating to the pedantically correct replacements right
away.
Jani Nikula [Mon, 30 Nov 2020 11:15:58 +0000 (13:15 +0200)]
drm/i915/pm: replace I915_READ()/WRITE() with intel_uncore_read()/write()
Arguably some of these should use intel_de_read() or intel_de_write(),
however not all. Prioritize I915_READ() and I915_WRITE() removal in
general over migrating to the pedantically correct replacements right
away.
Jani Nikula [Mon, 30 Nov 2020 11:15:56 +0000 (13:15 +0200)]
drm/i915/debugfs: replace I915_READ() with intel_uncore_read()
Another straggler with I915_READ() uses gone.
Arguably some of these should use intel_de_read(), however not
all. Prioritize I915_READ() removal in general over migrating to the
pedantically correct replacement right away.
Chris Wilson [Fri, 27 Nov 2020 21:00:59 +0000 (21:00 +0000)]
drm/i915/display: Suppress "Combo PHY A HW state changed unexpectedly"
We know a problem exists in the ifwi shipped with the early
pre-production Tigerlake and DG1 prototypes, later revisions are fine.
However, CI still relies on the earlier ifwi and we grow tired of
the volume of warnings as we wait for replacements.
Since the warning is a bug, we do not want to lose the warning in its
entirety, so only suppress the warning for the platforms currently
exhibiting the issue.
Suggested-by: José Roberto de Souza <gitlab@gitlab.freedesktop.org> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2411 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201127210059.10702-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 27 Nov 2020 14:57:48 +0000 (14:57 +0000)]
Revert "drm/i915: re-order if/else ladder for hpd_irq_setup"
We now use ilk_hpd_irq_setup for all GMCH platforms that do not have
hotplug. These are early gen3 and gen2 devices that now explode on boot
as they try to access non-existent registers.
Fixes: 794d61a19090 ("drm/i915: re-order if/else ladder for hpd_irq_setup") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201127145748.29491-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 25 Nov 2020 19:30:32 +0000 (19:30 +0000)]
drm/i915/display: Defer initial modeset until after GGTT is initialised
Prior to sanitizing the GGTT, the only operations allowed in
intel_display_init_nogem() are those to reserve the preallocated (and
active) regions in the GGTT leftover from the BIOS. Trying to allocate a
GGTT vma (such as intel_pin_and_fence_fb_obj during the initial modeset)
may then conflict with other preallocated regions that have not yet been
protected.
Move the initial modesetting from the end of init_nogem to the beginning
of init so that any vma pinning (either framebuffers or DSB, for example),
is after the GGTT is ready to handle it.
This will prevent the DSB object from being destroyed too early:
[ 53.449241] BUG: KASAN: use-after-free in i915_init_ggtt+0x324/0x9e0 [i915]
[ 53.449309] Read of size 8 at addr ffff88811b1e8070 by task systemd-udevd/345
Reported-by: Matthew Auld <matthew.auld@intel.com> Fixes: afeda4f3b1c8 ("drm/i915/dsb: Pre allocate and late cleanup of cmd buffer") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Tested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201125193032.29282-1-chris@chris-wilson.co.uk
Julian Stecklina [Wed, 11 Nov 2020 17:28:11 +0000 (18:28 +0100)]
drm/i915/gvt: treat intel_gvt_mpt as const in gvt code
The current interface of intel_gvt_register_hypervisor() expects a
non-const pointer to struct intel_gvt_mpt, even though the mediator
never modifies (or should modifiy) the content of this struct.
Change the function signature and relevant struct members to const to
properly express the API's intent and allow instances of intel_gvt_mpt
to be allocated as const.
While I was here, I also made KVM's instance of this struct const to
reduce the number of writable function pointers in the kernel.
Aditya Swarup [Tue, 17 Nov 2020 08:48:36 +0000 (00:48 -0800)]
drm/i915/dg1: Enable ports
For DG1 we have a little of mix up wrt to DDI/port names and indexes.
Bspec refers to the ports as DDIA, DDIB, DDI USBC1 and DDI USBC2
(besides the DDIA, DDIB, DDIC, DDID), but the previous naming is the
most unambiguous one. This means that for any register on Display Engine
we should use the index of A, B, D and E. However in some places this is
not true:
- VBT: uses C and D and have to be mapped to D/E
- IO/Combo: uses C and D, but we already differentiate those when
we created the phy vs port distinction.
This additional mapping for VBT and phy are already covered in previous
patches, so now we can initialize all the DDIs as A, B, D and E.
v2: Squash previous patch enabling just ports A and B since most of the
pumbling code is already merged now
Lionel Landwerlin [Tue, 17 Nov 2020 13:01:24 +0000 (15:01 +0200)]
drm/i915/perf: workaround register corruption in OATAILPTR
After having written the entire OA buffer with reports, the HW will
write again at the beginning of the OA buffer. It'll indicate it by
setting the WRAP bits in the OASTATUS register.
When a wrap happens and that at the end of the read vfunc we write the
OASTATUS register back to clear the REPORT_LOST bit, we sometimes see
that the OATAILPTR register is reset to a previous position on Gen8/9
(apparently not the case on Gen11+). This leads the next call to the
read vfunc to process reports we've already read. Because we've marked
those as read by clearing the reason & timestamp dwords, they're
discarded and a "Skipping spurious, invalid OA report" message is
emitted.
The workaround to avoid this OATAILPTR value reset seems to be to set
the wrap bits when writing back OASTATUS.
This change has no impact on userspace, it only avoids a bunch of
DRM_NOTE("Skipping spurious, invalid OA report\n") messages.
Ville Syrjälä [Tue, 17 Nov 2020 19:47:16 +0000 (11:47 -0800)]
drm/i915: Fix cursor src/dst rectangle with bigjoiner
We can't call drm_plane_state_src() this late for the slave plane since
it would consult the wrong uapi state. We've alreayd done the correct
uapi->hw copy earlier, so let's just preserve the unclipped src/dst
rects using a temp copy across the intel_atomic_plane_check_clipping()
call.
Maarten Lankhorst [Tue, 17 Nov 2020 19:47:14 +0000 (11:47 -0800)]
drm/i915: Add debugfs dumping for bigjoiner, v3.
Dump debugfs and planar links as well, this will make it easier to debug
when things go wrong.
v4:
* Rebase
Changes since v1:
- Report planar slaves as such, now that we have the plane_state switch.
Changes since v2:
- Rebase on top of the new plane format dumping
We need to look at hw.fb for the framebuffer, and add the translation
for the slave_plane_state. With these changes we set the correct
rectangle on the bigjoiner slave, and don't set incorrect
src/dst/visibility on the slave plane.
v2:
* Manual rebase (Manasi)
v3:
* hw.rotation instead of uapi.rotation (Ville)
Ville Syrjälä [Tue, 17 Nov 2020 19:47:12 +0000 (11:47 -0800)]
drm/i915: Get the uapi state from the correct plane when bigjoiner is used
When using bigjoiner userspace is only controlling the "master"
plane, so use its uapi state for the "slave" plane as well.
hw.crtc needs a bit of magic since we don't want to copy that from
the uapi state (as it points to the wrong pipe for the "slave
" plane). Instead we pass the right crtc in explicitly but only
assign it when the uapi state indicates the plane to be logically
enabled (ie. uapi.crtc != NULL).
Manasi Navare [Tue, 17 Nov 2020 19:47:09 +0000 (11:47 -0800)]
drm/i915: HW state readout for Bigjoiner case
Skip iterating over bigjoiner slaves, only the master has the state we
care about.
Add the width of the bigjoiner slave to the reconstructed fb.
Hide the bigjoiner slave to userspace, and double the mode on bigjoiner
master.
And last, disable bigjoiner slave from primary if reconstruction fails.
v3:
* Fix the ddi_get_config slave error (Ankit Nautiyal)
v2:
* Unsupported bigjoiner config for initial fb (Ville)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
[vsyrjala:
* Don't do any hw->uapi state copy for bigjoiner slave
* We still have hw.mode so no need to pass it in
* Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-7-manasi.d.navare@intel.com
Manasi Navare [Tue, 17 Nov 2020 19:47:08 +0000 (11:47 -0800)]
drm/i915/dp: Master/Slave enable/disable sequence for bigjoiner
Enabling is done in a special sequence and so should plane updates
be. Ideally the end user never notices the second pipe is used.
This way ideally everything will be tear free, and updates are
really atomic as userspace expects it.
This uses generic modeset_enables() calls like trans port sync
but still has special handling for disable since for slave we
should not disable things like encoder, plls that are not enabled
for slave.
Manasi Navare [Tue, 17 Nov 2020 19:47:07 +0000 (11:47 -0800)]
drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave
Make vdsc work when no output is enabled. The big joiner needs VDSC
on the slave, so enable it and set the appropriate bits.
So remove encoder usage from dsc functions.
Maarten Lankhorst [Tue, 17 Nov 2020 19:47:06 +0000 (11:47 -0800)]
drm/i915: Try to make bigjoiner work in atomic check
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
programming is done yet. Blobs are also copied from the master's
crtc_state, so it doesn't depend at commit time on the other
crtc_state.
v6:
* Enable dSC for any mode->hdisplay > 5120
v5:
* Remove intel_dp_max_dotclock (Manasi)
v4:
* Fixes in intel_crtc_compute_config (Ville)
v3:
* Manual Rebase (Manasi)
Changes since v1:
- Rename pipe timings to transcoder timings, as they are now different.
Changes since v2:
- Rework bigjoiner checks; always disable slave when recalculating
master. No need to have a separate bigjoiner pass any more.
- Use pipe_mode instead of transcoder_mode, to clean up the code.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
[vsyrjala:
* hskew isn't a thing
* Do the dsc compute if bigjoiner is enabled, not the other way around] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-4-manasi.d.navare@intel.com
Maarten Lankhorst [Tue, 17 Nov 2020 19:47:05 +0000 (11:47 -0800)]
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
v13:
* Allow bigjoiner if hdisplay >5120
v12:
* slice_count logic simplify (Ville)
* Fix unnecessary changes in downstream_mode_valid (Ville)
v11:
* Make intel_dp_can_bigjoiner non static
so it can be used in intel_display (Manasi)
v10:
* Simplify logic (Ville)
* Allow bigjoiner on edp (Ville)
v9:
* Restric Bigjoiner on PORT A (Ville)
v8:
* use source dotclock for max dotclock (Manasi)
v7:
* Add can_bigjoiner() helper (Ville)
* Pass bigjoiner to plane_size validation (Ville)
v6:
* Rebase after dp_downstream mode valid changes (Manasi)
v5:
* Increase max plane width to support 8K with bigjoiner (Maarten)
v4:
* Rebase (Manasi)
Changes since v1:
- Disallow bigjoiner on eDP.
Changes since v2:
- Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
and split off the downstream and source checking to its own function.
(Ville)
v3:
* Rebase (Manasi)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[vsyrjala:
* Keep bigjoiner disabled until everything is ready
* Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
Ville Syrjälä [Tue, 17 Nov 2020 19:47:04 +0000 (11:47 -0800)]
drm/i915: Copy the plane hw state directly for Y planes
When doing the plane state copy from the UV plane to the Y plane
let's just copy the hw state directly instead of using the original
uapi state. The UV plane has already had its uapi state copied into
its hw state, so this extra detour via the uapi state for the Y plane
is pointless.
Ville Syrjälä [Tue, 17 Nov 2020 15:40:28 +0000 (17:40 +0200)]
drm/i915: Fix the DDI encoder names
I totally fumbled the ?: usage when generating the DDI encoder
names. Reverse the things that need reversing, and to make it
a bit less messy add a few macros to hide the arithmetic on the
port enums.
Bob Paauwe [Tue, 10 Nov 2020 12:17:00 +0000 (17:47 +0530)]
drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms
The WA specifies that we need to toggle a SDE chicken bit on and then
off as the final step in preparation for s0ix entry.
Bspec: 33450
Bspec: 8402
However, something is happening after we toggle the bit that causes
the WA to be invalidated. This makes dispcnlunit1_cp_xosc_clkreq
active being already in s0ix state i.e SLP_S0 counter incremented.
Tweaking the Wa_14010685332 by setting the bit on suspend and clearing
it on resume turns down the dispcnlunit1_cp_xosc_clkreq.
B.Spec has Documented this tweaked sequence of WA as an alternative.
Let keep this tweaked WA for Gen11 platforms and keep untweaked WA for
other platforms which never observed this issue.
v2 (MattR):
- Change the comment on the workaround to give PCH names rather than
platform names. Although the bspec is setup to list workarounds by
platform, the hardware team has confirmed that the actual issue being
worked around here is something that was introduced back in the
Cannon Lake PCH and carried forward to subsequent PCH's.
- Extend the untweaked version of the workaround to include PCH_CNP as
well. Note that since PCH_CNP is used to represent CMP, this will
apply on CML and some variants of RKL too.
- Cap the untweaked version of the workaround so that it won't apply to
"fake" PCH's (i.e., DG1). The issue we're working around really is
an issue in the PCH itself, not the South Display, so it shouldn't
apply when there isn't a real PCH.
Ville Syrjälä [Tue, 10 Nov 2020 21:04:47 +0000 (23:04 +0200)]
drm/i915: Handle max_bpc==16
EDID can declare the maximum supported bpc up to 16,
and apparently there are displays that do so. Currently
we assume 12 bpc is tha max. Fix the assumption and
toss in a MISSING_CASE() for any other value we don't
expect to see.
This fixes modesets with a display with EDID max bpc > 12.
Previously any modeset would just silently fail on platforms
that didn't otherwise limit this via the max_bpc property.
In particular we don't add the max_bpc property to HDMI
ports on gmch platforms, and thus we would see the raw
max_bpc coming from the EDID.
I suppose we could already adjust this to also allow 16bpc,
but seeing as no current platform supports that there is
little point.
Ville Syrjälä [Mon, 9 Nov 2020 23:12:39 +0000 (01:12 +0200)]
drm/i915: Relocate cnl_get_ddi_pll()
Move cnl_get_ddi_pll() into a better spot from between
icl_get_ddi_pll() and dg1_get_ddi_pll(). Also reorder
the calls to the skl and bxt functions because ocd.
Ville Syrjälä [Mon, 9 Nov 2020 23:12:38 +0000 (01:12 +0200)]
drm/i915: Use actual readout results for .get_freq()
Currently the DPLL .get_freq() uses pll->state.hw_state which
is not the thing we actually read out (except during driver
load/resume). Outside of that pll->state.hw_state is just the
thing we committed last time around. During state check we
just read the thing into crtc_state->dpll_hw_state, so that
is what we should use for calculating the DPLL output frequency.
I think we used to do this so that the results of the readout
were actually used, but somehow it got changed when the
.get_freq() refactoring happened.
Ville Syrjälä [Mon, 9 Nov 2020 23:12:37 +0000 (01:12 +0200)]
drm/i915: Move intel_dpll_get_hw_state() into the hsw+ platform specific functions
On icl+ we want to populate both crtc_state.{shared_dpll,dpll_hw_state}
and crtc_state.port_dplls[] during readout, whereas on pre-icl we
want to leave the latter stuff untouched. Rather than adding more ifs
into hsw_get_ddi_port_state() to copy the DPLL hw state around let's
just move the whole dpll readout into hsw_get_ddi_dpll() & co.
Slightly repetitive, but meh.
Ville Syrjälä [Fri, 6 Nov 2020 17:30:41 +0000 (19:30 +0200)]
drm/i915: Store plane relative data rate in crtc_state
Store the relative data rate for planes in the crtc state
so that we don't have to use
intel_atomic_crtc_state_for_each_plane_state() to compute
it even for the planes that are no part of the current state.
Should probably just nuke this stuff entirely an use the normal
plane data rate instead. The two are slightly different since this
relative data rate doesn't factor in the actual pixel clock, so
it's a bit odd thing to even call a "data rate". And since the
watermarks are computed based on the actual data rate anyway
I don't really see what the point of this relative data rate
is. But that's for the future...
Ville Syrjälä [Fri, 6 Nov 2020 17:30:40 +0000 (19:30 +0200)]
drm/i915: Precompute can_sagv for each wm level
In order to remove intel_atomic_crtc_state_for_each_plane_state()
from skl_crtc_can_enable_sagv() we can simply precompute whether
each wm level can tolerate the SAGV block time latency or not.
This has the nice side benefit that we remove the duplicated
wm level latency calculation. In fact the copy of that code
we had in skl_crtc_can_enable_sagv() didn't even handle
WaIncreaseLatencyIPCEnabled/Display WA #1141 whereas the copy
in skl_compute_plane_wm() did. So now we just have the one
copy which handles all the w/as.
Ville Syrjälä [Fri, 6 Nov 2020 17:30:38 +0000 (19:30 +0200)]
drm/i915: Nuke intel_atomic_crtc_state_for_each_plane_state() from skl+ wm code
intel_atomic_crtc_state_for_each_plane_state() peeks at the
plane's current state without holding the plane's mutex, trusting
that the crtc's mutex will protect it. In practice that does work
since our planes can't move between pipes, but it sets a bad
example. intel_atomic_crtc_state_for_each_plane_state() also
relies on crtc_state.uapi.plane_mask which may be full of lies
when it comes to the bigjoiner stuff, so soon we can't use it as
is anyway. So best to just get rid of it entirely. Which we can
easily do by switching to the g4x/vlv "raw" watermark approach.
Later on we should even be able to move the "raw" watermark
computation into the normal .plane_check() code, leaving only
the merging/clamping of the final watermarks to the later
stages. But that will require adjusting the ilk+ wm code
similarly as well.
Manasi Navare [Fri, 13 Nov 2020 15:56:54 +0000 (07:56 -0800)]
drm/i915: Pass intel_atomic_state instead of drm_atomic_state
No functional changes, to align with previous cleanups pass
intel_atomic_state instead of drm_atomic_state.
Also pass this intel_atomic_state with crtc_state to
some of the atomic_check functions.
Maarten Lankhorst [Thu, 12 Nov 2020 19:17:18 +0000 (21:17 +0200)]
drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
With bigjoiner, there will be 2 pipes driving 2 halves of 1 transcoder,
because of this, we need a pipe_mode for various calculations, including
for example watermarks, plane clipping, etc.
v10:
* remove redundant pipe_mode assignment (Ville)
v9:
* pipe_mode in state dump nd state check (Ville)
v8:
* Add pipe_mode in readout in verify_crtc_state (Ville)
v7:
* Remove redundant comment (Ville)
* Just keep mode instead of pipe_mode (Ville)
v6:
* renaming in separate function, only pipe_mode here (Ville)
* Add description (Maarten)
v5:
* Rebase (Manasi)
v4:
* Manual rebase (Manasi)
v3:
* Change state to crtc_state, fix rebase err (Manasi)
v2:
* Manual Rebase (Manasi)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com>
[vsyrjala:
* Fix state checker
* Fix state dump
* Use pipe_mode for linetime watermarks
* Make sure pipe_mode normal timings are correct since the
silly ddb code uses them
* Drop the redundant pipe_mode copies from intel_modeset_pipe_config()
and intel_crtc_copy_uapi_to_hw_state()
* Use drm_mode_copy() all over] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201112191718.16683-7-ville.syrjala@linux.intel.com
Collect up a bunch of derived state "readout" into
a common helper, which we can call from both
intel_encoder_get_config() and intel_crtc_get_pipe_config().
Generalize intel_mode_from_pipe_config() to work on any two
arbitrary modes. Also relocate the code for the future, and
make it static since it's not needed elsewhere.
Ville Syrjälä [Thu, 12 Nov 2020 19:17:15 +0000 (21:17 +0200)]
drm/i915: Move hw.active assignment into intel_crtc_get_pipe_config()
No reason to make the callers of intel_crtc_get_pipe_config()
populate hw.active. Let's do it in intel_crtc_get_pipe_config()
itself. hw.enable we leave up to the callers since it's slightly
different for readout vs. state check.
Manasi Navare [Thu, 12 Nov 2020 19:17:13 +0000 (21:17 +0200)]
drm/i915: Move encoder->get_config to a new function
No functional changes, create a separate intel_encoder_get_config()
function that calls encoder->get_config hook.
This is needed so that later we can add beigjoienr related
readout here.
José Roberto de Souza [Wed, 11 Nov 2020 16:24:07 +0000 (08:24 -0800)]
drm/i915/display: Group DC9 mask set
DC9 has a separate HW flow from the rest of the DC states and it is
available in GEN9 LP platforms and on GEN11 and newer, so here
moving the assignment of the mask to a single conditional block to
simplifly code.
José Roberto de Souza [Fri, 6 Nov 2020 22:55:26 +0000 (14:55 -0800)]
drm/i915/display: Do not reset display when there is none
Display is always disabled and enabled when resetting any engine, but if
there is no display it should not do anything with display and only
reset the needed engines.
Deepak R Varma [Wed, 4 Nov 2020 12:15:32 +0000 (17:45 +0530)]
drm/i915/gvt: replace idr_init() by idr_init_base()
idr_init() uses base 0 which is an invalid identifier. The new function
idr_init_base allows IDR to set the ID lookup from base 1. This avoids
all lookups that otherwise starts from 0 since 0 is always unused.
References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
Colin Xu [Mon, 9 Nov 2020 07:39:22 +0000 (15:39 +0800)]
drm/i915/gvt: Fix virtual display setup for BXT/APL
Program display related vregs to proper value at initialization, setup
virtual monitor and hotplug.
vGPU virtual display vregs inherit the value from pregs. The virtual DP
monitor is always setup on PORT_B for BXT/APL. However the host may
connect monitor on other PORT or without any monitor connected. Without
properly setup PIPE/DDI/PLL related vregs, guest driver may not setup
the virutal display as expected, and the guest desktop may not be
created.
Since only one virtual display is supported, enable PIPE_A only. And
enable transcoder/DDI/PLL based on which port is setup for BXT/APL.
V2:
Revise commit message.
V3:
set_edid should on PORT_B for BXT.
Inject hpd event for BXT.
V4:
Temporarily disable vfio edid on BXT/APL until issue fixed.
V5:
Rebase to use new HPD define GEN8_DE_PORT_HOTPLUG for BXT.
Put vfio edid disabling on BXT/APL to a separate patch.
Colin Xu [Tue, 27 Oct 2020 04:53:08 +0000 (12:53 +0800)]
drm/i915/gvt: Save/restore HW status to support GVT suspend/resume
This patch save/restore necessary GVT info during i915 suspend/resume so
that GVT enabled QEMU VM can continue running.
Only GGTT and fence regs are saved/restored now. GVT will save GGTT
entries on each host_entry update, restore the saved dirty entries
and re-init fence regs in resume routine.
V2:
- Change kzalloc/kfree to vzalloc/vfree since the space allocated
from kmalloc may not enough for all saved GGTT entries.
- Keep gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c and
move the actual implementation to gvt.h/gvt.c. (zhenyu)
- Check gvt config on and active with intel_gvt_active(). (zhenyu)
V3: (zhenyu)
- Incorrect copy length. Should be num entries * entry size.
- Use memcpy_toio()/memcpy_fromio() instead of memcpy for iomem.
- Add F_PM_SAVE flags to indicate which MMIOs to save/restore for PM.
V4:
Rebase.
V5:
Fail intel_gvt_save_ggtt as -ENOMEM if fail to alloc memory to save
ggtt. Free allocated ggtt_entries on failure.
V6:
Save host entry to per-vGPU gtt.ggtt_mm on each host_entry update.
V7:
Restore GGTT entry based on present bit.
Split fence restore and mmio restore in different functions.
Lucas De Marchi [Fri, 6 Nov 2020 21:00:06 +0000 (13:00 -0800)]
drm/i915/dg1: map/unmap pll clocks
DG1 uses 2 registers for the ddi clock mapping, with PHY A and B using
DPCLKA_CFGCR0 and PHY C and D using DPCLKA1_CFGCR0. Hide this behind a
single macro that chooses the correct register according to the phy
being accessed, use the correct bitfields for each pll/phy and implement
separate functions for DG1 since it doesn't share much with ICL/TGL
anymore.
The previous values were correct for PHY A and B since they were using
the same register as before and the bitfields were matching.
v2: Add comment and try to simplify DG1_DPCLKA* macros by reusing
previous ones
v3:
- Fix DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK() after wrong macro reuse
- Move phy -> id map to a separate macro (Aditya)
- Remove DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK where not required
(Aditya)
- Use drm_WARN_ON
Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Aditya Swarup <aditya.swarup@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106210006.837953-1-lucas.demarchi@intel.com
As per W/A implemented for TGL to program half of the nominal
DCO divider fraction value which is also applicable on EHL.
Changes since V2:
- Apply stepping B0 till FOREVER
- B0 - revid update as per Bspec 29153
Changes since V1:
- ehl_ used as to keep earliest platform prefix
- WA required B0 stepping onwards
José Roberto de Souza [Mon, 2 Nov 2020 22:10:48 +0000 (14:10 -0800)]
drm/i915/display: Use initial_fastset_check() to compute and apply the initial PSR state
Replace the previous approach to force compute the initial PSR state
after i915 take over from firmware by the better and recently added
initial_fastset_check() hook.
Imre Deak [Wed, 4 Nov 2020 01:00:00 +0000 (03:00 +0200)]
drm/i915/tgl: Fix typo during output setup
Fix a typo that led to some MST short pulse event handling issue (the
short pulse event was handled for both encoder instances, each having
its own state).
Fixes: 1d8ca002456b6 ("drm/i915: Add PORT_TCn aliases to enum port") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201104010000.4165574-1-imre.deak@intel.com
Dave Airlie [Wed, 4 Nov 2020 00:55:11 +0000 (10:55 +1000)]
Merge tag 'drm-misc-next-2020-10-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.11:
UAPI Changes:
- doc: rules for EBUSY on non-blocking commits; requirements for fourcc
modifiers; on parsing EDID
- fbdev/sbuslib: Remove unused FBIOSCURSOR32
- fourcc: deprecate DRM_FORMAT_MOD_NONE
- virtio: Support blob resources for memory allocations; Expose host-visible
and cross-device features
Cross-subsystem Changes:
- devicetree: Add vendor Prefix for Yes Optoelectronics, Shanghai Top Display
Optoelectronics
- dma-buf: Add struct dma_buf_map that stores DMA pointer and I/O-memory flag;
dma_buf_vmap()/vunmap() return address in dma_buf_map; Use struct_size() macro
Core Changes:
- atomic: pass full state to CRTC atomic enable/disable; warn for EBUSY during
non-blocking commits
- dp: Prepare for DP 2.0 DPCD
- dp_mst: Receive extended DPCD caps
- dma-buf: Documentation
- doc: Format modifiers; dma-buf-map; Cleanups
- fbdev: Don't use compat_alloc_user_space(); mark as orphaned
- fb-helper: Take lock in drm_fb_helper_restore_work_fb()
- gem: Convert implementation and drivers to GEM object functions, remove
GEM callbacks from struct drm_driver (expect gem_prime_mmap)
- panel: Cleanups
- pci: Add legacy infix to drm_irq_by_busid()
- sched: Avoid infinite waits in drm_sched_entity_destroy()
- switcheroo: Cleanups
- ttm: Remove AGP support; Don't modify caching during swapout; Major
refactoring of the implementation and API that affects all depending
drivers; Add ttm_bo_wait_ctx(); Add ttm_bo_pin()/unpin() in favor of
TTM_PL_FLAG_NO_EVICT; Remove ttm_bo_create(); Remove fault_reserve_notify()
callback; Push move() implementation into drivers; Remove TTM_PAGE_FLAG_WRITE;
Replace caching flags with init-time cache setting; Push ttm_tt_bind() into
drivers; Replace move_notify() with delete_mem_notify(); No overlapping memcpy();
no more ttm_set_populated()
- vram-helper: Fix BO top-down placement; TTM-related changes; Init GEM
object functions with defaults; Default placement in system memory; Cleanups
Driver Changes:
- amdgpu: Use GEM object functions
- armada: Use GEM object functions
- aspeed: Configure output via sysfs; Init struct drm_driver with
- ast: Reload LUT after FB format changes
- bridge: Add driver and DT bindings for anx7625; Cleanups
- bridge/dw-hdmi: Constify ops
- bridge/ti-sn65dsi86: Add retries for link training
- bridge/lvds-codec: Add support for regulator
- bridge/tc358768: Restore connector support DRM_GEM_CMA_DRIVEROPS; Cleanups
- display/ti,j721e-dss: Add DT properies assigned-clocks, assigned-clocks-parent and
dma-coherent
- display/ti,am65s-dss: Add DT properies assigned-clocks, assigned-clocks-parent and
dma-coherent
- etnaviv: Use GEM object functions
- exynos: Use GEM object functions
- fbdev: Cleanups and compiler fixes throughout framebuffer drivers
- fbdev/cirrusfb: Avoid division by 0
- gma500: Use GEM object functions; Fix double-free of connector; Cleanups
- hisilicon/hibmc: I2C-based DDC support; Use to_hibmc_drm_device(); Cleanups
- i915: Use GEM object functions
- imx/dcss: Init driver with DRM_GEM_CMA_DRIVER_OPS; Cleanups
- ingenic: Reset pixel clock when parent clock changes; support reserved
memory; Alloc F0 and F1 DMA channels at once; Support different pixel formats;
Revert support for cached mmap buffers
on F0/F1; support 30-bit/24-bit/8-bit-palette modes
- komeda: Use DEFINE_SHOW_ATTRIBUTE
- mcde: Detect platform_get_irq() errors
- mediatek: Use GEM object functions
- msm: Use GEM object functions
- nouveau: Cleanups; TTM-related changes; Use GEM object functions
- omapdrm: Use GEM object functions
- panel: Add driver and DT bindings for Novatak nt36672a; Add driver and DT
bindings for YTC700TLAG-05-201C; Add driver and DT bindings for TDO TL070WSH30;
Cleanups
- panel/mantix: Fix reset; Fix deref of NULL pointer in mantix_get_modes()
- panel/otm8009a: Allow non-continuous dsi clock; Cleanups
- panel/rm68200: Allow non-continuous dsi clock; Fix mode to 50 FPS
- panfrost: Fix job timeout handling; Cleanups
- pl111: Use GEM object functions
- qxl: Cleanups; TTM-related changes; Pin new BOs with ttm_bo_init_reserved()
- radeon: Cleanups; TTM-related changes; Use GEM object functions
- rockchip: Use GEM object functions
- shmobile: Cleanups
- tegra: Use GEM object functions
- tidss: Set drm_plane_helper_funcs.prepare_fb
- tilcdc: Don't keep vblank interrupt enabled all the time
- tve200: Detect platform_get_irq() errors
- vc4: Use GEM object functions; Only register components once DSI is attached;
Add Maxime as maintainer
- vgem: Use GEM object functions
- via: Simplify critical section in via_mem_alloc()
- virtgpu: Use GEM object functions
- virtio: Implement blob resources, host-visible and cross-device features;
Support mapping of host-allocated resources; Use UUID APi; Cleanups
- vkms: Use GEM object functions; Switch to SHMEM
- vmwgfx: TTM-related changes; Inline ttm_bo_swapout_all()
- xen: Use GEM object functions
- xlnx: Use GEM object functions
projects / users / dwmw2 / linux.git / log