Imre Deak [Mon, 25 Jan 2021 17:36:36 +0000 (19:36 +0200)]
drm/i915: Fix the MST PBN divider calculation
Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit)
value for MST streams if the link parameters (link rate or lane count)
are limited in a way independent of the sink capabilities (reported by
DPCD).
One example of such a limitation is when a MUX between the sink and
source connects only a limited number of lanes to the display and
connects the rest of the lanes to other peripherals (USB).
Another issue is that atm MST core calculates the divider based on the
backwards compatible DPCD (at address 0x0000) vs. the extended
capability info (at address 0x2200). This can result in leaving some
part of the MST BW unused (For instance in case of the WD19TB dock).
Fix the above two issues by calculating the PBN divider value based on
the rate and lane count link parameters that the driver uses for all
other computation.
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977 Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com
Sean Paul [Thu, 21 Jan 2021 17:26:09 +0000 (12:26 -0500)]
drm/i915/hdcp: Disable the QSES check for HDCP 1.4 over MST
The HDCP 1.4 spec does not require the QUERY_STREAM_ENCRYPTION_STATUS
check, it was always a nice-to-have. After deploying this across various
devices, we've determined that some MST bridge chips do not properly
support this call for HDCP 1.4 (namely Synaptics and Realtek).
I had considered creating a quirk for this, but I think it's more
prudent to just disable the check entirely since I don't have an idea
how widespread support is.
drm/i915/display: Prevent double YUV range correction on HDR planes
Prevent the ICL HDR plane pipeline from performing YUV color range
correction twice when the input is in limited range. This is done by
removing the limited-range code from icl_program_input_csc().
Before this patch the following could happen: user space gives us a YUV
buffer in limited range; per the pipeline in [1], the plane would first
go through a "YUV Range correct" stage that expands the range; the plane
would then go through the "Input CSC" stage which would also expand the
range because icl_program_input_csc() would use a matrix and an offset
that assume limited-range input; this would ultimately cause dark and
light colors to appear darker and lighter than they should respectively.
This is an issue because if a buffer switches between being scanned out
and being composited with the GPU, the user will see a color difference.
If this switching happens quickly and frequently, the user will perceive
this as a flickering.
Ville Syrjälä [Fri, 22 Jan 2021 20:56:32 +0000 (22:56 +0200)]
drm/i915: Encapsulate dbuf state handling harder
In order to make the dbuf state computation less fragile
let's make it stand on its own feet by not requiring someone
to peek into a crystall ball ahead of time to figure out
which pipes need to be added to the state under which potential
future conditions. Instead we compute each piece of the state
as we go along, and if any fallout occurs that affects more than
the current set of pipes we add the affected pipes to the state
naturally.
That requires that we track a few extra thigns in the global
dbuf state: dbuf slices for each pipe, and the weight each
pipe has when distributing the same set of slice(s) between
multiple pipes. Easy enough.
We do need to follow a somewhat careful sequence of computations
though as there are several steps involved in cooking up the dbuf
state. Thoguh we could avoid some of that by computing more things
on demand instead of relying on earlier step of the algorithm to
have filled it out. I think the end result is still reasonable
as the entire sequence is pretty much consolidated into a single
function instead of being spread around all over.
The rough sequence is this:
1. calculate active_pipes
2. calculate dbuf slices for every pipe
3. calculate total enabled slices
4. calculate new dbuf weights for any crtc in the state
5. calculate new ddb entry for every pipe based on the sets of
slices and weights, and add any affected crtc to the state
6. calculate new plane ddb entries for all crtcs in the state,
and add any affected plane to the state so that we'll perform
the requisite hw reprogramming
And as a nice bonus we get to throw dev_priv->wm.distrust_bios_wm
out the window.
Ville Syrjälä [Fri, 22 Jan 2021 20:56:31 +0000 (22:56 +0200)]
drm/i915: Extract intel_crtc_dbuf_weights()
Extract the code to calculate the weights used to chunk up the dbuf
between pipes. There's still extra stuff in there that shouldn't be
there and must be moved out, but that requires a bit more state to
be tracked in the dbuf state.
Ville Syrjälä [Fri, 22 Jan 2021 20:56:30 +0000 (22:56 +0200)]
drm/i915: Add pipe ddb entries into the dbuf state
The dbuf state will be where we collect all the inter-pipe dbuf
allocation stuff. Start by adding the actual per-pipe ddb entries
there.
Originally the plan was to move them there outright, but that no longer
works as we're no longer guaranteed to have a dbuf state when it comes
time to sanity check the ddb overlaps in skl_commit_modeset_enables().
I think when I wrote this originally we did the watermark/ddb
calculation last, and so we couldn't have any crtcs in the state w/o
also having the dbuf state. But that has since changed and we do the
watermark/ddb calculation much earlier, and thus it is now possible
to commit crtcs w/o a dbuf state. So we keep another copy of the
information in the crtc state.
v2: Rebase
v3: Duplicate the entries instead of moving
Ville Syrjälä [Fri, 22 Jan 2021 20:56:29 +0000 (22:56 +0200)]
drm/i915: Introduce skl_ddb_entry_for_slices()
Generalize icl_get_first_dbuf_slice_offset() into something that
just gives us the start+end of the dbuf chunk covered by the
specified slices as a standard ddb entry. Initial idea was to use
it during readout as well, but we shall see.
Ville Syrjälä [Fri, 22 Jan 2021 20:56:26 +0000 (22:56 +0200)]
drm/i915: Extract intel_crtc_ddb_weight()
skl_ddb_get_pipe_allocation_limits() doesn't care how the weights
for distributing the ddb are caclculated for each pipe. Put that
calculation into a separate function so that such mundane details
are hidden from view.
Ville Syrjälä [Fri, 22 Jan 2021 23:26:47 +0000 (15:26 -0800)]
drm/i915: Fix vblank evasion with vrr
With vrr enabled the hardware no longer latches the registers
automagically at vblank start. The point at which it will do the
latching even when no push has been sent is the vmax decision
boundary. That is the thing we need to evade to avoid our
register latching to get split between two frames.
Ville Syrjälä [Fri, 22 Jan 2021 23:26:46 +0000 (15:26 -0800)]
drm/i915: Fix vblank timestamps with VRR
To get sensible vblank timestamping behaviour we need to feed
the vmax based timings to the vblank code, otherwise it'll chop
off the scanline counter when it exceeds the minumum vtotal.
Additionally with VRR we have three cases to consider when we
generate the vblank timestamp:
1) we are in vertical active
-> nothing special needs to be done, just return the current
scanout position and the core will calculate the timestamp
corresponding to the past time when the current vertical
active started
2) we are in vertical blank and no push has been sent
-> the hardware will keep extending the vblank presumably
to its maximum length, so we make the timestmap match the
expected time when the max length vblank will end. Since
the timings used for this are now based on vmax nothing
special actually needs to be done
3) we are in vblank and a push has been sent so the vblank is
about to terminate
-> presumably we want the timestmap to accurately reflect
when the vblank will terminate, so we use the sampled
frame timestamp vs. current timestamp to guesstimate
how far along the vblank exit we are, and then we
adjust the reported scanout position accordingly so
that the core will see that the vblank is close to
ending.
v2:
* Fix the else if (use_scanline_Counter) (Manasi)
Ville Syrjälä [Fri, 22 Jan 2021 23:26:44 +0000 (15:26 -0800)]
drm/i915/display: Helpers for VRR vblank min and max start
With VRR the earliest the registers can get latched are at
flipline decision boundary, calculate that as vrr_vmin_vblank_start()
and the latest the regsiters can get latched are vmax decision boundary
calculate that as vrr_vmax_vblank_start()
v2:
* Remove TODO and adjust extra scanline const (Manasi)
Manasi Navare [Fri, 22 Jan 2021 23:26:42 +0000 (15:26 -0800)]
drm/i915/display/vrr: Set IGNORE_MSA_PAR state in DP Sink
If VRR is enabled, the sink should ignore MSA parameters
and regenerate incoming video stream without depending
on these parameters. Hence set the MSA_TIMING_PAR_IGNORE_EN
bit if VRR is enabled.
Reset this bit on VRR disable.
v2:
* ACtually set the dpcd msa ignore bit (Ville)
Manasi Navare [Fri, 22 Jan 2021 23:26:40 +0000 (15:26 -0800)]
drm/i915/display/vrr: Send VRR push to flip the frame
VRR achieves vblank stretching using the HW PUSH functionality.
So once the VRR is enabled during modeset then for each flip
request from userspace, in the atomic tail pipe_update_end()
we need to set the VRR push bit in HW for it to terminate
the vblank at configured flipline or anytime after flipline
or latest at the Vmax.
The HW clears the PUSH bit after the double buffer updates
are completed.
v2:
* Move send push to after irq en (Manasi)
* Call send push unconditionally (Jani N)
Manasi Navare [Fri, 22 Jan 2021 23:26:36 +0000 (15:26 -0800)]
drm/i915/display/dp: Do not enable PSR if VRR is enabled
Even though our HW supports PSR + VRR, the available panels
do not work reliably with PSR and VRR together. So if user
requested VRR and is supported by HW enable that and do not
enable PSR in that case.
Manasi Navare [Fri, 22 Jan 2021 23:26:35 +0000 (15:26 -0800)]
drm/i915/display/dp: Compute VRR state in atomic_check
This forces a complete modeset if vrr drm crtc state goes
from enabled to disabled and vice versa.
This patch also computes vrr state variables from the mode timings
and based on the vrr property set by userspace as well as hardware's
vrr capability.
v2:
*Rebase
v3:
* Vmin = max (vtotal, vmin) (Manasi)
v4:
* set crtc_state->vrr.enable = 0 for disable request
v5:
* drm_dbg_kms, squash crtc states def patch (Jani N)
v6:
* Move vrr modeset check to separate function (Jani N)
v7:
* Ville's fixes - vmin, vmax rename, fix rounding dir
* Add pipeline full, flipline to crtc state
* Pass conn state to vrr_compute_config (Ville)
Ville Syrjälä [Fri, 22 Jan 2021 23:26:33 +0000 (15:26 -0800)]
drm/i915: Extract intel_mode_vblank_start()
We want to calculate the vblank_start for vblank evasion
differently for vrr. To make that nicer lets first extract
the current non-vrr case to a helper.
Ville Syrjälä [Fri, 22 Jan 2021 23:26:32 +0000 (15:26 -0800)]
drm/i915: Store framestart_delay in dev_priv
The vrr calculations will need to know the framestart delay value
we use. Currently we program it always to zero, but should that change
we probably want to stash it somewhere.
Could stick it into the crtc_state I suppose, but since we never
change it let's just stuff it into dev_priv for now.
Aditya Swarup [Fri, 22 Jan 2021 23:26:31 +0000 (15:26 -0800)]
drm/i915/display/dp: Attach and set drm connector VRR property
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v8:
* Use HAS_VRR, remove drm_conn declaration (Jani N)
* Fix typos in Comment (Jani N)
v7:
* Move the helper to separate file (Manasi)
v6:
* Remove unset of prop
v5:
* Fix the vrr prop not being set in kernel (Manasi)
* Unset the prop on connector disconnect (Manasi)
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for debugfs, make it
non static (Manasi)
v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)
Manasi Navare [Mon, 25 Jan 2021 20:08:18 +0000 (12:08 -0800)]
drm/i915/display/vrr: Create VRR file and add VRR capability check
We create a new file for all VRR related helpers.
Also add a function to check vrr capability based on
platform support, DPCD bits and EDID monitor range.
v2:
* Remove author (Jani N)
* Define HAS_VRR (Jani N)
* Ensure intel_dp can be obtained from conn (Jani N)
drm/i915/tgl: Add Clear Color support for TGL Render Decompression
Render Decompression is supported with Y-Tiled main surface. The CCS is
linear and has 4 bits of data for each main surface cache line pair, a
ratio of 1:256. Additional Clear Color information is passed from the
user-space through an offset in the GEM BO. Add a new modifier to identify
and parse new Clear Color information and extend Gen12 render decompression
functionality to the newly added modifier.
v2: Fix has_alpha flag for modifiers, omit CC modifier during initial
plane config(Matt). Fix Lookup error.
v3: Fix the panic while running kms_cube
v4: Add alignment check and reuse the comments for ge12_ccs_formats(Matt)
v5: Fix typos and wrap comments(Matt)
v6:
- Use format block descriptors to get the subsampling calculations for
the CCS surface right.
- Use helpers to convert between main and CCS surfaces.
- Prevent coordinate checks for the CC surface.
- Simplify reading CC value from surface map, add description of CC val
layout.
- Remove redundant ccval variable from skl_program_plane().
v7:
- Move the CC value readout after syncing against any GPU write on the
FB obj (Nanley, Chris)
- Make sure the CC value readout works on platforms w/o struct pages
(dGFX) and other non-coherent platforms wrt. CPU reads (none atm).
(Chris)
v8:
- Rebase on the function param order change of
i915_gem_object_read_from_page().
- Clarify code comment on the clear color value format and the required
FB obj pinning/syncing by the caller.
- Remove redundant variables in
intel_atomic_prepare_plane_clear_colors().
v9:
- Fix s/sizeof(&ccval)/sizeof(ccval)/ typo.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Nanley G Chery <nanley.g.chery@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210115213952.1040398-1-imre.deak@intel.com
Imre Deak [Wed, 20 Jan 2021 21:38:34 +0000 (23:38 +0200)]
drm/i915/gem: Add a helper to read data from a GEM object page
Add a simple helper to read data with the CPU from the page of a GEM
object. Do the read either via a kmap if the object has struct pages
or an iomap otherwise. This is needed by the next patch, reading a u64
value from the object (w/o requiring the obj to be mapped to the GPU).
Suggested by Chris.
v2 (Chris):
- Sanitize the type and order of func params.
- Avoid consts requiring too many casts.
- Use BUG_ON instead of WARN_ON, simplify the conditions.
- Fix __iomem sparse errors.
- Leave locking/syncing/pinning up to the caller, require only that the
caller has pinned the object pages.
- Check for iomem backing store before reading via an iomap.
v3:
- Fix offset passed to io_mapping_map_wc() missing a mem.region.start
delta. (Chris, Matthew)
drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color
Gen12 display can decompress surfaces compressed by render engine with
Clear Color, add a new modifier as the driver needs to know the surface
was compressed by render engine.
V2: Description changes as suggested by Rafael.
V3: Mention the Clear Color size of 64 bits in the comments(DK)
v4: Fix trailing whitespaces
v5: Explain Clear Color in the documentation.
v6: Documentation Nitpicks(Nanley)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Kalyan Kondapally <kalyan.kondapally@intel.com> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Nanley Chery <nanley.g.chery@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210114201314.783648-2-imre.deak@intel.com
Anshuman Gupta [Wed, 20 Jan 2021 10:30:32 +0000 (16:00 +0530)]
drm/i915/hdcp: Fix uninitialized symbol
Move (num_hdcp_streams > 0) condition to stream_encryption()
code block, where it actually belongs.
This fixes the static analysis error of uninitialized symbol 'ret'.
v2:
- return 0 as the return value is already checked. [Ankit]
Initialize no. of streams transmitted on a port to zero
such that intel_hdcp_required_content_stream() can
prepared the content stream after subsequemt attmept to
enable hdcp after a HDCP failure.
v2:
- Initialize k at top level instead of else branch. [Jani]
Lyude Paul [Thu, 21 Jan 2021 18:36:43 +0000 (13:36 -0500)]
drm/i915/dp: Don't use DPCD backlights that need PWM enable/disable
We haven't yet implemented support for backlights that need to be
enabled/disabled via PWM instead of AUX, which means we'll break things if
we enable DPCD backlight control on these machines. Luckily though since
most of these machines work fine just using the plain PWM backlight
controls anyway, there shouldn't be any issue with just leaving DPCD
backlight controls disabled in such situations.
This should fix the issues with PWM being left on that were being observed
on fi-bdw-samus.
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)")
Testcase: igt/gem_exec_suspend/basic-s0 # fi-bdw-samus Cc: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210121183644.2627282-1-lyude@redhat.com
Ville Syrjälä [Mon, 7 Dec 2020 20:35:11 +0000 (22:35 +0200)]
drm/i915: Fix ICL MG PHY vswing handling
The MH PHY vswing table does have all the entries these days. Get
rid of the old hacks in the code which claim otherwise.
This hack was totally bogus anyway. The correct way to handle the
lack of those two entries would have been to declare our max
vswing and pre-emph to both be level 2.
Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Fixes: 9f7ffa297978 ("drm/i915/tc/icl: Update TC vswing tables") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201207203512.1718-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Jani Nikula [Wed, 20 Jan 2021 11:07:08 +0000 (13:07 +0200)]
drm/msm/dp: fix build after dp quirk helper change
Commit 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based
quirks"") removed drm_dp_get_edid_quirks() and changed the signature of
drm_dp_has_quirk() while they were still being used in msm. Fix the
breakage. Functionally, removing the EDID-based quirks has no impact on
msm.
[The above commit was merged to drm-intel-next; make two wrongs a right
by merging this fix through drm-intel-next as well.]
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
References: http://lore.kernel.org/r/20210120105715.4391dd95@canb.auug.org.au Fixes: 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based quirks"") Cc: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Tested-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210120110708.32131-1-jani.nikula@intel.com
Jani Nikula [Wed, 20 Jan 2021 10:18:32 +0000 (12:18 +0200)]
drm/i915/pps: move pps code over from intel_display.c and refactor
intel_display.c has some pps functions that belong to intel_pps.c. Move
them over.
While at it, refactor the duplicate intel_pps_init() in intel_display.c
into an orthogonal intel_pps_setup() in intel_pps.c, and call it earlier
in intel_modeset_init_nogem().
Jani Nikula [Wed, 20 Jan 2021 10:18:31 +0000 (12:18 +0200)]
drm/i915/pps: refactor init abstractions
Once you realize there is no need to hold the pps mutex when calling
pps_init_timestamps() in intel_pps_init(), we can reuse
intel_pps_encoder_reset() which has the same code.
Since intel_dp_pps_init() is only called from one place now, move it
inline to remove one "init" function altogether.
Finally, remove some initialization from
vlv_initial_power_sequencer_setup() and do it in the caller to highlight
the similarity, not the difference, in the platforms.
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.
At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.
As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.
v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
intel_edp_init_connector()
Lyude Paul [Wed, 16 Sep 2020 16:31:37 +0000 (12:31 -0400)]
drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.
So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).
Lyude Paul [Mon, 29 Jun 2020 19:01:49 +0000 (15:01 -0400)]
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.
On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.
For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:
* If the panel's VBT reports VESA backlight support, assume it really
does support it
* If the panel's VBT reports DDI backlight controls:
* First probe for Intel's HDR backlight interface
* If that fails, probe for VESA's backlight interface
* If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
doesn't have DPCD backlight controls
Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
Lyude Paul [Fri, 11 Sep 2020 17:53:05 +0000 (13:53 -0400)]
drm/i915: Keep track of pwm-related backlight hooks separately
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.
So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:
* We now keep track of two separate backlight level ranges, one for the
high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
enablement separately
* Since the currently set backlight level might not be the same as the
currently programmed PWM backlight level, we stop setting
panel->backlight.level with the currently programmed PWM backlight
level in panel->backlight.pwm_funcs->setup(). Instead, we rely
on the higher level backlight control functions to retrieve the
current PWM backlight level (in this case, intel_pwm_get_backlight()).
Note that there are still a few PWM backlight setup callbacks that
do actually need to retrieve the current PWM backlight level, although
we no longer save this value in panel->backlight.level like before.
Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.
v9:
* Drop the intel_panel_invert_pwm_level() call in lpt_setup_backlight()
* Remove leftover detritus from lpt_setup_backlight()
v8:
* Go back to getting initial brightness level with
intel_pwm_get_backlight(), the other fix we had was definitely wrong.
v7:
* Use panel->backlight.pwm_funcs->get() to get the backlight level in
intel_pwm_setup_backlight(), lest we upset lockdep
* Rebase
* Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level()
v6:
* Make sure to grab connection_mutex before calling
intel_pwm_get_backlight() in intel_pwm_setup_backlight()
v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()
Ville Syrjälä [Mon, 11 Jan 2021 16:37:07 +0000 (18:37 +0200)]
drm/i915: Reuse the async_flip() hook for the async flip disable w/a
On some platforms we need to trigger an extra async flip with
the async flip bit disabled, and then wait for the next vblank
until the async flip bit off state will actually latch.
Currently the w/a is just open coded for skl+ universal planes.
Instead of doing that lets reuse the .async_flip() hook for this
purpose since it needs to write the exact same set of registers.
In order to do this we'll just have the caller pass in the state
of the async flip bit explicitly.
Ville Syrjälä [Mon, 11 Jan 2021 16:37:06 +0000 (18:37 +0200)]
drm/i915: Move the async_flip bit setup into the .async_flip() hook
Set up the async flip PLANE_CTL bit directly in the
.async_flip() hook. Neither .update_plane() nor .disable_plane()
ever need to set this so having it done by skl_plane_ctl_crtc()
is rather pointless.
Ville Syrjälä [Mon, 11 Jan 2021 16:37:04 +0000 (18:37 +0200)]
drm/i915: Generalize the async flip capability check
Only assign the plane->async_flip() vfunc when the plane supports
async flips. For now we keep this artificially limited to the primary
plane since thats the only thing the legacy page flip uapi can target
and there is no async flip support in the atomic uapi yet.
Ville Syrjälä [Thu, 14 Jan 2021 20:50:45 +0000 (22:50 +0200)]
drm/i915: Fix the PHY compliance test vs. hotplug mishap
I accidentally added the compliance test hacks only to
intel_dp_hotplug() which doesn't even get used on any DDI
platform. Put the same crap into intel_ddi_hotplug().
Lee Shawn C [Mon, 18 Jan 2021 02:27:53 +0000 (10:27 +0800)]
drm/i915: support two CSC module on gen11 and later
There are two CSC on pipeline on gen11 and later platform.
User space application is allowed to enable CTM and RGB
to YCbCr coversion at the same time now.
v2: check csc capability in {}_color_check function.
v3: can't support two CSC at the same time in {ivb,glk}_color_check.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Shankar Uma <uma.shankar@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210118022753.8798-1-shawn.c.lee@intel.com
Dave Airlie [Thu, 14 Jan 2021 11:13:46 +0000 (13:13 +0200)]
drm/i915: refactor pll code out into intel_dpll.c
This pulls a large chunk of the pll calculation code out of
intel_display.c to a new file.
One function makes sense to be an inline, otherwise this
is pretty much a straight copy cover. Also all the
remaining hooks for g45 and older end up the same now.
Ville Syrjälä [Mon, 11 Jan 2021 16:41:11 +0000 (18:41 +0200)]
drm/i915: Only enable DFP 4:4:4->4:2:0 conversion when outputting YCbCr 4:4:4
Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're
actually outputting YCbCr 4:4:4. It would appear some protocol
converters blindy consult this bit even when the source is outputting
RGB, resulting in a visual mess.
Lyude Paul [Thu, 14 Jan 2021 22:17:05 +0000 (17:17 -0500)]
drm/i915: Pass port to intel_panel_bl_funcs.get()
In the next commit where we split PWM related backlight functions from
higher-level backlight functions, we'll want to be able to retrieve the
backlight level for the current display panel from the
intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since
intel_panel_bl_funcs->setup() is called before we've fully read in the
current hardware state into our atomic state, we can't grab atomic
modesetting locks safely anyway in intel_panel_bl_funcs->setup(), and some
PWM backlight functions (vlv_get_backlight() in particular) require knowing
the currently used pipe we need to be able to discern the current display
pipe through other means. Luckily, we're already passing the current
display pipe to intel_panel_bl_funcs->setup() so all we have to do in order
to achieve this is pass down that parameter to intel_panel_bl_funcs->get().
So, fix this by accepting an additional pipe parameter in
intel_panel_bl_funcs->get(), and leave figuring out the current display
pipe up to the caller.
Zhenyu Wang [Thu, 14 Jan 2021 00:58:19 +0000 (08:58 +0800)]
drm/i915: Try to guess PCH type even without ISA bridge
Some vmm like hyperv and crosvm don't supply any ISA bridge to their guest,
when igd passthrough is equipped on these vmm, guest i915 display may
couldn't work as guest i915 detects PCH_NONE pch type.
When i915 runs as guest, this patch guess pch type through gpu type even
without ISA bridge.
v2: Fix CI warning
v3: Add HAS_DISPLAY()= true condition beforce guessing virt pch, then
refactori.
v4: Fix CI warning
Chris Wilson [Wed, 23 Dec 2020 10:39:17 +0000 (10:39 +0000)]
drm/i915/display: Bitwise or the conversion colour specifier together
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op?
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op?
drivers/gpu/drm/i915/display/intel_dp.c:6923 intel_dp_update_420() warn: should this be a bitwise op?
Inside drm_dp_downstream_rgb_to_ycbcr_conversion(), that parameter
'color_spc' is used as return port_cap[3] & color_spc, implying that it
is indeed a mask and not a boolean value.
Fixes: 522508b665df ("drm/i915/display: Let PCON convert from RGB to YCbCr if it can") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201223103917.14687-1-chris@chris-wilson.co.uk
Dave Airlie [Fri, 15 Jan 2021 05:03:36 +0000 (15:03 +1000)]
Merge tag 'drm-intel-gt-next-2021-01-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
UAPI Changes:
- Deprecate I915_PMU_LAST and optimize state tracking (Tvrtko)
Avoid relying on last item ABI marker in i915_drm.h, add a
comment to mark as deprecated.
Cross-subsystem Changes:
Core Changes:
Driver Changes:
- Restore clear residuals security mitigations for Ivybridge and
Baytrail (Chris)
- Close #1858: Allow sysadmin to choose applied GPU security mitigations
through i915.mitigations=... similar to CPU (Chris)
- Fix for #2024: GPU hangs on HSW GT1 (Chris)
- Fix for #2707: Driver hang when editing UVs in Blender (Chris, Ville)
- Fix for #2797: False positive GuC loading error message (Chris)
- Fix for #2859: Missing GuC firmware for older Cometlakes (Chris)
- Lessen probability of GPU hang due to DMAR faults [reason 7,
next page table ptr is invalid] on Tigerlake (Chris)
- Fix REVID macros for TGL to fetch correct stepping (Aditya)
- Limit frequency drop to RPe on parking (Chris, Edward)
- Limit W/A 1406941453 to TGL, RKL and DG1 (Swathi)
- Make W/A 22010271021 permanent on DG1 (Lucas)
- Implement W/A 16011163337 to prevent a HS/DS hang on DG1 (Swathi)
- Only disable preemption on gen8 render engines (Chris)
- Disable arbitration around Braswell's PDP updates (Chris)
- Disable arbitration on no-preempt requests (Chris)
- Check for arbitration after writing start seqno before busywaiting (Chris)
- Retain default context state across shrinking (Venkata, CQ)
- Fix mismatch between misplaced vma check and vma insert for 32-bit
addressing userspaces (Chris, CQ)
- Propagate error for vmap() failure instead kernel NULL deref (Chris)
- Propagate error from cancelled submit due to context closure
immediately (Chris)
- Fix RCU race on HWSP tracking per request (Chris)
- Clear CMD parser shadow and GPU reloc batches (Matt A)
- Populate logical context during first pin (Maarten)
- Optimistically prune dma-resv from the shrinker (Chris)
- Fix for virtual engine ownership race (Chris)
- Remove timeslice suppression to restore fairness for virtual engines (Chris)
- Rearrange IVB/HSW workarounds properly between GT and engine (Chris)
- Taint the reset mutex with the shrinker (Chris)
- Replace direct submit with direct call to tasklet (Chris)
- Multiple corrections to virtual engine dequeue and breadcrumbs code (Chris)
- Avoid wakeref from potentially hard IRQ context in PMU (Tvrtko)
- Use raw clock for RC6 time estimation in PMU (Tvrtko)
- Differentiate OOM failures from invalid map types (Chris)
- Fix Gen9 to have 64 MOCS entries similar to Gen11 (Chris)
- Ignore repeated attempts to suspend request flow across reset (Chris)
- Remove livelock from "do_idle_maps" VT-d W/A (Chris)
- Cancel the preemption timeout early in case engine reset fails (Chris)
- Code flow optimization in the scheduling code (Chris)
- Clear the execlists timers upon reset (Chris)
- Drain the breadcrumbs just once (Chris, Matt A)
- Track the overall GT awake/busy time (Chris)
- Tweak submission tasklet flushing to avoid starvation (Chris)
- Track timelines created using the HWSP to restore on resume (Chris)
- Use cmpxchg64 for 32b compatilibity for active tracking (Chris)
- Prefer recycling an idle GGTT fence to avoid GPU wait (Chris)
- Restructure GT code organization for clearer split between GuC
and execlists (Chris, Daniele, John, Matt A)
- Remove GuC code that will remain unused by new interfaces (Matt B)
- Restructure the CS timestamp clocks code to local to GT (Chris)
- Fix error return paths in perf code (Zhang)
- Replace idr_init() by idr_init_base() in perf (Deepak)
- Fix shmem_pin_map error path (Colin)
- Drop redundant free_work worker for GEM contexts (Chris, Mika)
- Increase readability and understandability of intel_workarounds.c (Lucas)
- Defer enabling the breadcrumb interrupt to after submission (Chris)
- Deal with buddy alloc block sizes beyond 4G (Venkata, Chris)
- Encode fence specific waitqueue behaviour into the wait.flags (Chris)
- Don't cancel the breadcrumb interrupt shadow too early (Chris)
- Cancel submitted requests upon context reset (Chris)
- Use correct locks in GuC code (Tvrtko)
- Prevent use of engine->wa_ctx after error (Chris, Matt R)
- Fix build warning on 32-bit (Arnd)
- Avoid memory leak if platform would have more than 16 W/A (Tvrtko)
- Avoid unnecessary #if CONFIG_PM in PMU code (Chris, Tvrtko)
- Improve debugging output (Chris, Tvrtko, Matt R)
- Make file local variables static (Jani)
- Avoid uint*_t types in i915 (Jani)
- Selftest improvements (Chris, Matt A, Dan)
- Documentation fixes (Chris, Jose)
Dave Airlie [Thu, 14 Jan 2021 23:05:23 +0000 (09:05 +1000)]
Merge tag 'amd-drm-next-5.12-2021-01-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-next
amd-drm-next-5.12-2021-01-08:
amdgpu:
- Rework IH ring handling on vega and navi
- Rework HDP handling for vega and navi
- swSMU documenation updates
- Overdrive support for Sienna Cichlid and newer asics
- swSMU updates for vangogh
- swSMU updates for renoir
- Enable FP16 on DCE8-11
- Misc code cleanups and bug fixes
radeon:
- Fixes for platforms that can't access PCI resources correctly
- Misc code cleanups
Ville Syrjälä [Mon, 19 Oct 2020 21:43:31 +0000 (00:43 +0300)]
drm/i915: Drop one more useless master_transcoder assignment
We dropped the other redundant master_transcoder assignments
earlier, but this one slipped through. Get rid of it as well.
The crtc state gets fully reset before readout so there is
no point in doing this.
Jani Nikula [Fri, 8 Jan 2021 17:44:20 +0000 (19:44 +0200)]
drm/i915/pps: rename vlv_init_panel_power_sequencer to vlv_pps_init
This function is a bit of an outlier, but try to change to a name that
is more in line with the rest of the intel_pps functions. No functional
changes.
Jani Nikula [Fri, 8 Jan 2021 17:44:16 +0000 (19:44 +0200)]
drm/i915/pps: abstract intel_pps_encoder_reset()
Add an "encoder reset" call to hide some more pps functions, and clean
up the callers. A minor functional change is not holding the pps lock
across the whole operation in intel_dp_encoder_reset, but instead doing
it in two steps.
v2: rename intel_pps_reinit to intel_pps_encoder_reset for clarity
Add a new init call to be called only once, unlike some of the other
various init calls. This lets us hide more functions within
intel_pps.c. No functional changes.
Jani Nikula [Fri, 8 Jan 2021 17:44:13 +0000 (19:44 +0200)]
drm/i915/pps: rename edp_panel_* to intel_pps_*_unlocked
Follow the usual naming pattern for functions, both for the prefix and
the _unlocked suffix for functions that expect the lock to be held when
calling. No functional changes.
In the legacy ringbuffer submission, we still had an open-coded version
of intel_engine_stop_cs() with one additional verification step. Transfer
that verification to intel_engine_stop_cs() itself, and call it.
Chris Wilson [Wed, 13 Jan 2021 16:31:15 +0000 (16:31 +0000)]
drm/i915/selftests: Bump the scheduling error threshold for fast heartbeats
Since we are system_highpri_wq, we expected the heartbeat to be
scheduled promptly. However, we see delays of over 10ms upsetting our
assertions. Accept this as inevitable and bump the minimum error
threshold to 20ms (from 6 jiffies).
Imre Deak [Tue, 29 Dec 2020 17:22:01 +0000 (19:22 +0200)]
drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode
The DP PHY vswing/pre-emphasis level programming the driver does is
related to the DPTX -> first LTTPR link segment only. Accordingly it
should be only programmed when link training the first LTTPR and kept
as-is when training subsequent LTTPRs and the DPRX. For these latter
PHYs the vs/pe levels will be set in response to writing the
DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR
TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY).
The above is also described in DP Standard v2.0 under 3.6.6.1.
While at it simplify and add the LTTPR that is link trained to the debug
message in intel_dp_set_signal_levels().
Initialize all required entries from guc_set_default_submission, instead
of calling the execlists function. The previously inherited setup has
been copied over from the execlist code and simplified by removing the
execlists submission-specific parts.
v2: move setting of relative_mmio flag to engine_setup_common (Chris)
drm/i915/guc: init engine directly in GuC submission mode
Instead of starting the engine in execlists submission mode and then
switching to GuC, start directly in GuC submission mode. The initial
setup functions have been copied over from the execlists code
and simplified by removing the execlists submission-specific parts.
v2: remove unneeded unexpected starting state check (Chris)
drm/i915/guc: do not dump execlists state with GuC submission
GuC owns the execlists state and the context IDs used for submission, so
the status of the ports and the CSB entries are not something we control
or can decode from the i915 side, therefore we can avoid dumping it. A
follow-up patch will also stop setting the csb pointers when using GuC
submission.
GuC dumps all the required events in the GuC logs when verbosity is set
high enough.
Matthew Brost [Wed, 13 Jan 2021 02:12:33 +0000 (18:12 -0800)]
drm/i915/guc: Delete GuC code unused in future patches
Delete GuC code unused in future patches that rewrite the GuC interface
to work with the new firmware. Most of the code deleted relates to
workqueues or execlist port. The code is safe to remove because we still
don't allow GuC submission to be enabled, even when overriding the
modparam, so it currently can't be reached.
The defines + structs for the process descriptor and workqueue remain.
Although the new GuC interface does not require either of these for the
normal submission path multi-lrc submission does. The usage of the
process descriptor and workqueue for multi-lrc will be quite different
from the code that is deleted in this patch. A future patch will
implement multi-lrc submission.
v2: add a code in the commit message about the code being safe to
remove (Chris)
projects / mirror_ubuntu-kernels.git / log