Jouni Högander [Tue, 24 Oct 2023 12:40:50 +0000 (15:40 +0300)]
drm/i915/display: Move psr related module parameters under display
Move psr related module parameters under display. Also fix error in
enable_psr2_sel_fetch module parameter descrtiption. It was saying disabled
by default while it's vice versa. Also psr_safest_params was missing
default value in description. This is now added.
v2:
- Fix enable_psr2_sel_fetch description.
- Add default value into psr_safest_params description.
Jouni Högander [Tue, 24 Oct 2023 12:40:48 +0000 (15:40 +0300)]
drm/i915/display: Dump also display parameters
GPU error dump contained all module parameters. If we are moving
display parameters to intel_display_params.[ch] they are not dumped
into GPU error dump. This patch is adding moved display parameters
back to GPU error dump. Display parameters are also included in
i915_capabilities
Jouni Högander [Tue, 24 Oct 2023 12:40:47 +0000 (15:40 +0300)]
drm/i915/display: Add framework to add parameters specific to display
Currently all module parameters are handled by i915_param.c/h. This
is a problem for display parameters when Xe driver is used. Add
a mechanism to add parameters specific to the display. This is mainly
copied from i915_[debugfs]_params.[ch]. Parameters are not yet moved. This
is done by subsequent patches.
v2:
- Drop unused predefinition (dentry)
- Clarify need for empty INTEL_DISPLAY_PARAMS_FOR_EACH in comment
drm/i915/display: debugfs entry to list display capabilities
Create a separate debugfs entry to list the display capabilities
IGT can rely on this debugfs entry for tests that depend on
display device and display runtime info for both xe and i915
drivers.
v2: rename the entry to i915_display_capabilities (Chaitanya)
Jouni Högander [Thu, 12 Oct 2023 07:21:57 +0000 (10:21 +0300)]
drm/i915/display: Move releasing gem object away from fb tracking
As a preparation for Xe we want to remove all i915_gem_object details away
from frontbuffer tacking code. Due to this move releasing gem object
reference to i915_gem_object_set_frontbuffer.
drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake
Meteor Lake has demonstrated consistent stability for some time.
All user-space API modifications tide to its core platform
functions are operational.
The necessary firmware components are set up and comprehensive
testing has been condused over a period.
Given the recent faborable CI results, as well, we believe it's
time to eliminate the 'force_probe' prerequisite and activate the
platform by default.
Signed-off-by: Aditya Chauhan <aditya.chauhan@intel.com> Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Lee Shawn C <shawn.c.lee@intel.com> Tested-by: Lee Shawn C <shawn.c.lee@intel.com> Tested-by: Karthik B S <karthik.b.s@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231008164824.919262-1-andi.shyti@linux.intel.com
Imre Deak [Wed, 11 Oct 2023 17:16:06 +0000 (20:16 +0300)]
drm/i915/dp: Remove unused DSC caps from intel_dp
The previous patches converted all users of the DSC DPCD caps to look
these up from the connector, so remove the version stored in intel_dp.
A follow-up patchset will read out the MST connector specific
capabilities in intel_dp_add_mst_connector() ->
intel_dp_mst_read_decompression_port_dsc_caps().
v2:
- Rebased on intel_edp_get_dsc_sink_cap() addition in the patchset.
v3:
- Rebased on read-out fix for eDP in the patchset.
Imre Deak [Fri, 6 Oct 2023 13:37:13 +0000 (16:37 +0300)]
drm/i915/dp: Use connector DSC DPCD in i915_dsc_fec_support_show()
Use the connector's DSC DPCD capabilities in i915_dsc_fec_support_show()
instead of the version stored in the encoder. Atm the two are identical,
but a follow-up patch will store the (MST) connector specific version
in the connector.
Imre Deak [Tue, 10 Oct 2023 11:25:03 +0000 (14:25 +0300)]
drm/i915/dp_mst: Set connector DSC capabilities and decompression AUX
Similarly to eDP and SST-DP connectors read out the DSC capabilities for
MST connectors as well. Atm these will match the root port's DSC caps
and only used after a follow-up change enables the decompression for
each stream separately (vs. the current way of enabling it only globally
in the first branch device downstream of the root port).
Imre Deak [Wed, 11 Oct 2023 17:16:05 +0000 (20:16 +0300)]
drm/i915/dp: Store DSC DPCD capabilities in the connector
In an MST topology the DSC capabilities are specific to each connector,
retrieved either from the sink if it decompresses the stream, or from a
branch device between the source and the sink in case this branch device
does the decompression. Accordingly each connector needs to cache its
own DSC DPCD and FEC capabilities, along with the AUX device through
which the decompression can be enabled. This patch prepares for that by
storing the capabilities and the DSC AUX device in the connector, for
now these just matching the version stored in intel_dp. The follow-up
patches will convert all users to look up these in the connector instead
of intel_dp, after which the intel_dp copies are removed.
v2:
- Rebased on intel_edp_get_dsc_sink_cap() addition in previous patch.
v3:
- Rebased on read-out fix for eDP in previous patch.
Imre Deak [Wed, 11 Oct 2023 17:16:04 +0000 (20:16 +0300)]
drm/i915/dp: Sanitize DPCD revision check in intel_dp_get_dsc_sink_cap()
Check only the eDP or the DP specific DPCD revision depending on the
sink type. Pass the corresponding revision to the function, which allows
getting the DSC caps of a branch device (in an MST topology, which has
its own DPCD and so DPCD revision).
While at it use DP_DPCD_REV_14 instead of open coding it and for clarity
add a separate function to read out the DSC capability on eDP.
v2:
- Use DP_DPCD_REV_14 instead of open coding it. (Stan)
- Check EDP_DCPD_REV/DPCD_REV in a clearer way. (Ville)
v3:
- Fix the read-out for eDP in intel_dp_detect().
The display engine does not snoop the caches so we should mark
the DSB command buffer as I915_CACHE_NONE.
i915_gem_object_create_internal() always gives us I915_CACHE_LLC
on LLC platforms. And to make things 100% correct we should also
clflush at the end, if necessary.
Note that currently this is a non-issue as we always write the
command buffer through a WC mapping, so a cache flush is not actually
needed. But we might actually want to consider a WB mapping since
we also end up reading from the command buffer (in the indexed
reg write handling). Either that or we should do something else
to avoid those reads (might actually be even more sensible on DGFX
since we end up reading over PCIe). But we should measure the overhead
first...
Anyways, no real harm in adding the belts and suspenders here so
that the code will work correctly regardless of how we map the
buffer. If we do get a WC mapping (as we request)
i915_gem_object_flush_map() will be a nop. Well, apart form
a wmb() which may just flush the WC buffer a bit earlier
than would otherwise happen (at the latest the mmio accesses
would trigger the WC flush).
Ville Syrjälä [Mon, 9 Oct 2023 13:22:01 +0000 (16:22 +0300)]
drm/i915/dsb: Allocate command buffer from local memory
Using system memory for the DSB command buffer doesn't appear to work.
On DG2 it seems like the hardware internally replaces the actual memory
reads with zeroes, and so we end up executing a bunch of NOOPs instead
of whatever commands we put in the buffer. To determine that I measured
the time it takes to execute the instructions, and the results are
always more or less consistent with executing a buffer full of NOOPs
from local memory.
Another theory I considered was some kind of cache coherency issue.
Looks like i915_gem_object_pin_map_unlocked() will in fact give you a
WB mapping for system memory on DGFX regardless of what mapping mode
was requested (WC in case of the DSB code). But clflush did not
change the behaviour at all, so that theory seems moot.
On DG1 it looks like the hardware might actually be fetching data from
system memory as the logs indicate that we just get underruns. But that
is equally bad, so doesn't look like we can really use system memory on
DG1 either.
Thus always allocate the DSB command buffer from local memory on
discrete GPUs.
Hans de Goede [Wed, 20 Sep 2023 19:56:12 +0000 (21:56 +0200)]
drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3 (v2)
On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 issues with the backlight
on/off MIPI sequences:
1. The backlight on sequence has an I2C MIPI sequence element which uses
bus 0, but there is a bogus I2cSerialBus resource under the GPU in
the DSDT which causes i2c_acpi_find_adapter() to pick the wrong bus.
2. There is no backlight off sequence, causing the backlight to stay on.
Add a DMI quirk fixing both issues.
v2:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info
Hans de Goede [Wed, 20 Sep 2023 19:56:11 +0000 (21:56 +0200)]
drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v3)
On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:
1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
which under Linux become bus 0 - 6. And the MIPI sequence reference
to bus 3 is indented for I2C3 which is bus 2 under Linux.
This leads to errors like these:
[ 178.244049] i2c_designware 80860F41:03: controller timed out
[ 178.245703] i915 0000:00:02.0: [drm] *ERROR* Failed to xfer payload of size (1) to reg (169)
There are 3 timeouts when the panel is on, delaying
waking up the screen on a key press by 3 seconds.
Note mipi_exec_i2c() cannot just subtract 1 from the bus
given in the I2C MIPI sequence element. Since on other
devices the I2C bus-numbers used in the MIPI sequences do
actually start at 0.
2. width_/height_mm contain a bogus 192mm x 120mm size. This is
especially a problem on the 8" 830 version which uses a 10:16
portrait screen where as the bogus size is 16:10.
Add a DMI quirk to override the I2C bus and the panel size with
the correct values.
Note both the 10" 1050 models as well as the 8" 830 models use the same
mainboard and thus the same DMI strings. The 10" 1050 uses a 1920x1200
landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen,
so the quirk handling uses the display resolution to detect the model.
v2:
- Also override i2c_bus_num to fix mipi_exec_i2c() timeouts
v3:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info
Hans de Goede [Wed, 20 Sep 2023 19:56:10 +0000 (21:56 +0200)]
drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v3)
Vtotal is wrong in the BIOS supplied modeline for the DSI panel on
the Asus TF103C leading to the last line of the display being shown
as the first line.
The factory installed Android has a hardcoded modeline in its kernel,
causing it to not suffer from this BIOS bug;
and the Android boot-splash which uses the EFI FB which does have this bug
has the last line all black causing the bug to not be visible.
This commit introduces a generic DMI based quirk mechanism to vlv_dsi for
doing various fixups, and uses this to correct the modeline.
v2:
- s/mode_fixup/dmi_quirk/ to make the new DMI quirk mechanism more generic
- Add a comment with the old and new modelines to the patch and commit msg
v3:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info
Suraj Kandpal [Mon, 9 Oct 2023 09:55:37 +0000 (15:25 +0530)]
drm/i915/hdcp: Move common message filling function to its own file
Create a new file intel_hdcp_gsc_message that contain functions
which fill the hdcp messages we send to gsc cs this refactor will
help us reuse code for Xe later on
--v2
-add the missed file for proper build
--v3
-use forward declarations instead of #includes [Jani]
--v4
-move linux/err.h to intel_hdcp_gsc_message.c from
intel_hdcp_gsc_message.h [Jani]
--v5
-move linux include on top of drm includes [Uma]
Jani Nikula [Wed, 11 Oct 2023 07:29:04 +0000 (10:29 +0300)]
drm/i915: enable W=1 warnings by default
We enable a bunch more compiler warnings than the kernel
defaults. However, they've drifted to become a unique set of warnings,
and have increasingly fallen behind from the W=1 set.
Align with the W=1 warnings from scripts/Makefile.extrawarn for clarity,
by copy-pasting them with s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it
easier to compare in the future.
Some of the -Wextra warnings do need to be disabled, just like in
Makefile.extrawarn, but take care to not disable them for W=2 or W=3
builds, depending on the warning.
v2: Add back some -Wextra warning disables (Nathan)
Jani Nikula [Wed, 11 Oct 2023 07:29:03 +0000 (10:29 +0300)]
drm/i915: drop -Wall and related disables from cflags as redundant
The kernel top level Makefile, and recently scripts/Makefile.extrawarn,
have included -Wall, and the disables -Wno-format-security and
$(call cc-disable-warning,frame-address,) for a very long time. They're
redundant in our local subdir-ccflags-y and can be dropped.
drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned
Currently, with MFD/pin assignment D, the driver clears the pipe reset bit
of lane 1 which is not owned by display. This causes the display
to block S0iX.
By not clearing this bit for lane 1 and keeping whatever default, S0ix
started to work. This is already what the driver does at the end
of the phy lane reset sequence (Step#8)
Bspec: 65451 Fixes: 619a06dba6fa ("drm/i915/mtl: Reset only one lane in case of MFD") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231005001310.154396-1-khaled.almahallawy@intel.com
Add a wrapper around intel_step_name that takes in driver data as an
argument. This wrapper will help maintain compatibility with the
proposed xe driver.
Ville Syrjälä [Mon, 9 Oct 2023 14:58:28 +0000 (17:58 +0300)]
drm/i915: Fix VLV color state readout
VLV was missed when the color.get_config() hook was added.
Remedy that.
Not really sure what the final plan here was since a bunch of
color related readout was left in intel_display.c anyway,
but that's for anothr day to figure out...
Remove redundant intel_connector NULL check. Having it here just
creates further confusion and also the variable already gets
dereferenced before the aforementioned NULL check
Ville Syrjälä [Wed, 4 Oct 2023 15:56:03 +0000 (18:56 +0300)]
drm/i915: Simplify snps/c10x DPLL state checker calling convetion
Passing in the atomic state + crtc state is a bit weird. The latter
can be just the crtc (which is the normal calling convention used
in a lot of other places).
Ville Syrjälä [Thu, 5 Oct 2023 12:27:13 +0000 (15:27 +0300)]
drm/i915: Simplify watermark state checker calling convention
There is never any reason to pass in both the crtc and its state
as one can always dig out the crtc from its state. But for more
consistency across the whole state checker let's just pass the
overall atomic state+crtc here as well.
Ville Syrjälä [Wed, 4 Oct 2023 15:55:57 +0000 (18:55 +0300)]
drm/i915: Stop clobbering old crtc state during state check
The state checker overwrites the old crtc state with the
current hardware state. While that does save a kmalloc() it seems
rather dubious as there might still be something that we need
in the old crtc state.
Stop doing that and just allocate a temporary state for the state
checker. Should the extra malloc during the commit phase turn out
too annoying we could of course preallocate one for each crtc, but
let's proceed with the straightforward approch for now.
And while at it let's mark the new crtc state as const to make
sure the state checker doesn't mess it up.
Ville Syrjälä [Wed, 4 Oct 2023 15:55:56 +0000 (18:55 +0300)]
drm/i915/psr: Unify PSR pre/post plane update hooks
intel_psr_pre_plane_update() operates on a per-crtc level, whereas
intel_psr_post_plane_update() operates on the whole atomic commit,
for no real reason that I can see. Adjust intel_psr_post_plane_update()
to match the intel_psr_pre_plane_update() approach.
Ville Syrjälä [Tue, 3 Oct 2023 19:42:51 +0000 (22:42 +0300)]
drm/i915/fbc: Remove ancient 16k plane stride limit
The 16k max plane stride limit seems to be originally from
i965gm, and no explicit limit has been specified since (g4x+).
So let's assume the max plane stride itself is a suitable limit
also for the more recent FBC hardware.
In fact even for i965gm the max X-tiled stride is also 16k so
technically we don't need the check there either, but let's
keep it there anyway since it's explicitly mentioned in the
spec. Gen2/3 have more strict limits checked separately.
drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read
Use local64_try_cmpxchg instead of local64_cmpxchg (*ptr, old, new) == old
in i915_pmu_event_read. x86 CMPXCHG instruction returns success in ZF flag,
so this change saves a compare after cmpxchg (and related move instruction
in front of cmpxchg).
Also, try_cmpxchg implicitly assigns old *ptr value to "old" when cmpxchg
fails. There is no need to re-read the value in the loop.
No functional change intended.
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Uros Bizjak <ubizjak@gmail.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/20230703150859.6176-1-ubizjak@gmail.com
Uma Shankar [Fri, 29 Sep 2023 07:43:06 +0000 (13:13 +0530)]
drm/i915/display: Created exclusive version of vga decode setup
Current vga arbiter implementation in i915 needs a re-design.
The current approach would cause real problems if anyone actually
needs to talk another GPU using legacy VGA resources.
The main issue is that X becomes a slideshow if it thinks there
are multiple GPUs that have VGA decoding enabled as it insists
on adjusting the VGA routing pretty much for every little operation
involving any of the GPUs.
The cleanup will be planned for i915. Meanwhile to focus on Xe
upstreaming and have a cleaner separation, the said functionality
is being moved to a different file exclusive for i915. Xe driver
will re-use rest of the display code from i915.
v2: Addressed Jani Nikula's review comments.
v3: Dropped a duplicate function (Jani)
v4: Updated commit message with reasoning as sugested by Ville.
Imre Deak [Fri, 29 Sep 2023 15:49:29 +0000 (18:49 +0300)]
drm/i915/dp_mst: Make sure pbn_div is up-to-date after sink reconnect
Atm the MST encoder config computation may use an out-of-date pbn_div
value, if the sink is unplugged and a sink is replugged with different
link rate/lane count capabilities. The current way of reinitializing
pbn_div depends on pbn_div getting cleared via intel_atomic_check() ->
drm_dp_mst_atomic_check() ->
drm_dp_mst_atomic_check_payload_alloc_limits(), however the clearing
won't happen if the sink got unplugged (and hence
drm_dp_mst_topology_mgr::mst_state being false).
To fix the above, simply update pbn_div unconditionally during config
computation, making pbn_div always match the link rate and lane count.
This is to eliminate all cases of "*ERROR* LSPCON mode hasn't settled",
followed by link training errors. Intel engineers recommended increasing
this timeout and that does resolve the issue.
On some CometLake-based device designs the Parade PS175 takes more than
400ms to settle in PCON mode. 100 reboot trials on one device resulted
in a median settle time of 440ms and a maximum of 444ms. Even after
increasing the timeout to 500ms, 2% of devices still had this error. So
this increases the timeout to 800ms.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9443 Signed-off-by: Pablo Ceballos <pceballos@google.com> Signed-off-by: Niko Tsirakis <ntsirakis@google.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/20231002204709.761089-1-ntsirakis@google.com
Ville Syrjälä [Tue, 3 Oct 2023 20:06:19 +0000 (23:06 +0300)]
drm/i915: Introduce for_each_shared_dpll()
No one really cares how we store the shared_dplls. Currently
it happens to be an array, but we could change that to a more
flexible scheme at some point. Hide the implementation details
behind an iterator macro.
The slight downside is the pll variable moving out of the
loop scope, but maybe someday soon we'll start to convert
everything over to having declarations within for-statements...
projects / thirdparty / kernel / linux.git / log
