If stag work is already scheduled and unload is called, it can lead to
issues as unload cleans up the work element. Wait for stag work to get
completed before cleanup during unload.
Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Link: https://lore.kernel.org/r/20240515091101.18754-3-skashyap@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Stag work can cause issues during unload and recovery, hence don't process
it.
Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Link: https://lore.kernel.org/r/20240515091101.18754-2-skashyap@marvell.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Running syzkaller with the newly reintroduced signed integer overflow
sanitizer produces this report:
[ 65.194362] ------------[ cut here ]------------
[ 65.197752] UBSAN: signed-integer-overflow in ../drivers/scsi/sr_ioctl.c:436:9
[ 65.203607] -2147483648 * 177 cannot be represented in type 'int'
[ 65.207911] CPU: 2 PID: 10416 Comm: syz-executor.1 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
[ 65.213585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 65.219923] Call Trace:
[ 65.221556] <TASK>
[ 65.223029] dump_stack_lvl+0x93/0xd0
[ 65.225573] handle_overflow+0x171/0x1b0
[ 65.228219] sr_select_speed+0xeb/0xf0
[ 65.230786] ? __pm_runtime_resume+0xe6/0x130
[ 65.233606] sr_block_ioctl+0x15d/0x1d0
...
Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang. It was re-enabled in the kernel
with Commit 557f8c582a ("ubsan: Reintroduce signed overflow sanitizer").
Firstly, let's change the type of "speed" to unsigned long as
sr_select_speed()'s only caller passes in an unsigned long anyways.
$ git grep '\.select_speed'
| drivers/scsi/sr.c: .select_speed = sr_select_speed,
...
| static int cdrom_ioctl_select_speed(struct cdrom_device_info *cdi,
| unsigned long arg)
| {
| ...
| return cdi->ops->select_speed(cdi, arg);
| }
Next, let's add an extra check to make sure we don't exceed 0xffff/177
(350) since 0xffff is the max speed. This has two benefits: 1) we deal
with integer overflow before it happens and 2) we properly respect the
max speed of 0xffff. There are some "magic" numbers here but I did not
want to change more than what was necessary.
Link: https://github.com/llvm/llvm-project/pull/82432 [1]
Closes: https://github.com/KSPP/linux/issues/357
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20240508-b4-b4-sio-sr_select_speed-v2-1-00b68f724290@google.com
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When a host is configured with a few LUNs and I/O is running, injecting FC
faults repeatedly leads to path recovery problems. The LUNs have 4 paths
each and 3 of them come back active after say an FC fault which makes 2 of
the paths go down, instead of all 4. This happens after several iterations
of continuous FC faults.
Reason here is that we're returning an I/O error whenever we're
encountering sense code 06/04/0a (LOGICAL UNIT NOT ACCESSIBLE, ASYMMETRIC
ACCESS STATE TRANSITION) instead of retrying.
[mwilck: The original patch was developed by Rajashekhar M A and Hannes
Reinecke. I moved the code to alua_check_sense() as suggested by Mike
Christie [1]. Evan Milne had raised the question whether pg->state should
be set to transitioning in the UA case [2]. I believe that doing this is
correct. SCSI_ACCESS_STATE_TRANSITIONING by itself doesn't cause I/O
errors. Our handler schedules an RTPG, which will only result in an I/O
error condition if the transitioning timeout expires.]
[1] https://lore.kernel.org/all/0bc96e82-fdda-4187-148d-5b34f81d4942@oracle.com/
[2] https://lore.kernel.org/all/CAGtn9r=kicnTDE2o7Gt5Y=yoidHYD7tG8XdMHEBJTBraVEoOCw@mail.gmail.com/
Co-developed-by: Rajashekhar M A <rajs@netapp.com>
Co-developed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin Wilck <martin.wilck@suse.com>
Link: https://lore.kernel.org/r/20240514140344.19538-1-mwilck@suse.com
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When building for a 32-bit platform such as ARM or i386, for which size_t
is unsigned int, there is a warning due to using an unsigned long format
specifier:
drivers/scsi/mpi3mr/mpi3mr_transport.c:1370:11: error: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Werror,-Wformat]
1369 | ioc_warn(mrioc, "skipping port %u, max allowed value is %lu\n",
| ~~~
| %u
1370 | i, sizeof(mr_sas_port->phy_mask) * 8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the proper format specifier for size_t, %zu, to resolve the warning for
all platforms.
Fixes: 3668651def ("scsi: mpi3mr: Sanitise num_phys")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20240514-mpi3mr-fix-wformat-v1-1-f1ad49217e5e@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
After ther -u addition, most of the known users are setting it. And
it makes sense, as it adds more information, and inherits the default
setup for the threads - e.g., cgroups configs.
Thus, if the user-space interface is available, enable -u. Otherwise,
use the in-kernel thread.
Add the -k option to allow the user to request kernel-threads.
Link: https://lkml.kernel.org/r/9241d3089de4091b124f780ed832a0e6646cadaa.1713968967.git.bristot@kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
On many cases, the results right after the startup are different
from the rest of the execution, biasing the results. For example,
on osnoise, the scheduler might take some time to adapt to the new
busy-loop workload.
Add the --warm-up <seconds> option, adding a warm-up phase (in
seconds) where the workload is set, but the results are discarded.
Link: https://lkml.kernel.org/r/e682d5ce5af90f123bd13220f63d5c3d118a92be.1713968967.git.bristot@kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
While the per-cpu values are the results to take into consideration, the
overall system values are also useful.
Add a summary at the bottom of rtla timerlat top showing the overall
results. For instance:
Timer Latency
0 00:00:10 | IRQ Timer Latency (us) | Thread Timer Latency (us)
CPU COUNT | cur min avg max | cur min avg max
0 #10003 | 113 19 150 441 | 134 35 170 459
1 #10003 | 63 8 99 462 | 84 15 119 481
2 #10003 | 3 2 89 396 | 21 8 108 414
3 #10002 | 206 11 210 394 | 223 21 228 415
---------------|----------------------------------------|---------------------------------------
ALL #40011 e0 | 2 137 462 | 8 156 481
Link: https://lkml.kernel.org/r/5eb510d6faeb4ce745e09395196752df75a2dd1a.1713968967.git.bristot@kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Suggested-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
timerlat top does some background/font color formatting. While useful
on terminal, it breaks the output on other formats. For example, when
piping the output for pastebin tools, the format strings are printed
as characters. For instance:
[2;37;40m Timer Latency [0;0;0m
0 00:00:01 | IRQ Timer Latency (us) | Thread Timer Latency (us)
[2;30;47mCPU COUNT | cur min avg max | cur min avg max[0;0;0m
0 #1013 | 1 0 1 54 | 5 2 4 57
1 #1013 | 3 0 1 10 | 6 2 4 15
To avoid this problem, do the formatting only if running on a tty,
and in !quiet mode.
Link: https://lkml.kernel.org/r/8288e1544ceab21557d5dda93a0f00339497c649.1713968967.git.bristot@kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
When copying timerlat auto-analysis from a terminal to some web pages or
chats, the \t are being replaced with a single ' ' or ' ', breaking
the output.
For example:
## CPU 3 hit stop tracing, analyzing it ##
IRQ handler delay: 1.30 us (0.11 %)
IRQ latency: 1.90 us
Timerlat IRQ duration: 3.00 us (0.24 %)
Blocking thread: 1223.16 us (99.00 %)
insync:4048 1223.16 us
IRQ interference 4.93 us (0.40 %)
local_timer:236 4.93 us
------------------------------------------------------------------------
Thread latency: 1235.47 us (100%)
Replace \t with spaces to avoid this problem.
Link: https://lkml.kernel.org/r/ec7ed2b2809c22ab0dfc8eb7c805ab9cddc4254a.1713968967.git.bristot@kernel.org
Cc: stable@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Juri Lelli <juri.lelli@redhat.com>
Fixes: 27e348b221 ("rtla/timerlat: Add auto-analysis core")
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Instead of printing three times the same output, print it only once,
reducing lines and being sure that all no values have the same length.
It also fixes an extra '\n' when running the with kernel threads, like
here:
=============== %< ==============
Timer Latency
0 00:00:01 | IRQ Timer Latency (us) | Thread Timer Latency (us)
CPU COUNT | cur min avg max | cur min avg max
2 #0 | - - - - | 161 161 161 161
3 #0 | - - - - | 161 161 161 161
8 #1 | 54 54 54 54 | - - - -'\n'
---------------|----------------------------------------|---------------------------------------
ALL #1 e0 | 54 54 54 | 161 161 161
=============== %< ==============
This '\n' should have been removed with the user-space support that
added another '\n' if not running with kernel threads.
Link: https://lkml.kernel.org/r/0a4d8085e7cd706733a5dc10a81ca38b82bd4992.1713968967.git.bristot@kernel.org
Cc: stable@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Juri Lelli <juri.lelli@redhat.com>
Fixes: cdca4f4e5e ("rtla/timerlat_top: Add timerlat user-space support")
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Having the plane WM/DDB regitster write functions in skl_watermarks.c
is rather annoying when trying to implement DSB based plane updates.
Move them into the respective files that handle all other plane
register writes. Less places where I need to worry about the DSB
vs. MMIO decisions.
The downside is that we spread the wm struct details a bit further
afield. But if that becomes too annoying we can probably abstract
things a bit more with a few extra functions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510152329.24098-17-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Get rid of skl_ddb_entry_write() and skl_write_wm_level() and
just call intel_de_write_fw() directly.
This is prep work towards DSB based plane updates where these
wrappers are more of a hinderance.
Done with cocci mostly:
@@
expression D, R, L;
@@
- skl_write_wm_level(D, R, L)
+ intel_de_write_fw(D, R, skl_plane_wm_reg_val(L))
@@
expression D, R, B;
@@
- skl_ddb_entry_write(D, R, B)
+ intel_de_write_fw(D, R, skl_plane_ddb_reg_val(B))
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510152329.24098-16-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently every skl+ plane register defines some intermediate
macros to calculate the final register offset. Pull all of that
into common macros, simplifying the final register offset stuff
into just five defines:
- raw register offsets for the planes 1 and 2 on pipes A and B
- the final parametrized macro
v2: Rebase
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240513170040.15393-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Rearrange the plane skl+ universal plane register definitions:
- keep everything related to the same register in one place
- sort based on register offset
- unify the whitespace/etc a bit
v2: Define register contents after all offsets (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240513165909.15234-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
On SKL+ the watermark/DDB registers are proper per-plane
registers. Move the definitons to their respective files.
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
CC: Zhi Wang <zhi.wang.linux@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510152329.24098-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Move most of the SKL+ universal plane register definitions
into their own file. Declutters i915_reg.h a bit more.
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
CC: Zhi Wang <zhi.wang.linux@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510152329.24098-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Under some circumstances it may happen that the ks8851 Ethernet driver
stops sending data.
Currently the interrupt handler resets the interrupt status flags in the
hardware after handling TX. With this approach we may lose interrupts in
the time window between handling the TX interrupt and resetting the TX
interrupt status bit.
When all of the three following conditions are true then transmitting
data stops:
- TX queue is stopped to wait for room in the hardware TX buffer
- no queued SKBs in the driver (txq) that wait for being written to hw
- hardware TX buffer is empty and the last TX interrupt was lost
This is because reenabling the TX queue happens when handling the TX
interrupt status but if the TX status bit has already been cleared then
this interrupt will never come.
With this commit the interrupt status flags will be cleared before they
are handled. That way we stop losing interrupts.
The wrong handling of the ISR flags was there from the beginning but
with commit 3dc5d44545 ("net: ks8851: Fix TX stall caused by TX
buffer overrun") the issue becomes apparent.
Fixes: 3dc5d44545 ("net: ks8851: Fix TX stall caused by TX buffer overrun")
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org # 5.10+
Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When running the bridge IGMP/MLD selftests on debug kernels we can get
spurious errors when setting up the IGMP/MLD exclude timeout tests
because the membership interval is just 3 seconds and the setup has 2
seconds of sleep plus various validations, the one second that is left
is not enough. Increase the membership interval from 3 to 5 seconds to
make room for the setup validation and 2 seconds of sleep.
Fixes: 34d7ecb3d4 ("selftests: net: bridge: update IGMP/MLD membership interval value")
Reported-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mediatek LVTS driver (Julien Panis)
- Remove the num_lvts_sensor and cal_offset fields of the
lvts_ctrl_data as they are not used. These are not functional fixes
but slight memory usage fix of the Mediatek LVTS driver (Julien
Panis)
- Fix wrong lvts_ctrl index leading to a NULL pointer dereference in
the Mediatek LVTS driver (Julien Panis)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEGn3N4YVz0WNVyHskqDIjiipP6E8FAmZDL8IACgkQqDIjiipP
6E9IGwgAlzaIbugHk6qgrkC1s6JhxdAay/sUAk4zJ7WYirtykdWS0/56hh2DL/Ub
VttvTWgDf6W4k/+gaV/hVWjEq5og82n249DSFlJmcAAcvTQ0Stk2LG2TTqRBmfb4
qPKqLoVWlMhDUlbhnNZoS04jApowRitgfOvtC1G0owqkmbzIOKryJJIbvK6VRWpm
qPo7aR99DJW7Cm3lLujyIC41PGb4vKGS2jFFFrf/s69vj40IVHw2jAHOkSJDS+H1
Jro7fTHtlf7eskg4abL9zUzDSJMJTNOTyyj8vJ0524V2I7SavZxbUBoWVfYc/OSf
gWqCZFlY6sWX7k331hhxrpWjdALlyA==
=e53Q
-----END PGP SIGNATURE-----
Merge tag 'thermal-v6.10-rc1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux
Merge thermal driver fixes for 6.10-rc1 from Daniel Lezcano:
"- Check for a NULL pointer before using it in the probe routine of the
Mediatek LVTS driver (Julien Panis)
- Remove the num_lvts_sensor and cal_offset fields of the
lvts_ctrl_data as they are not used. These are not functional fixes
but slight memory usage fix of the Mediatek LVTS driver (Julien
Panis)
- Fix wrong lvts_ctrl index leading to a NULL pointer dereference in
the Mediatek LVTS driver (Julien Panis)"
* tag 'thermal-v6.10-rc1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux:
thermal/drivers/mediatek/lvts_thermal: Fix wrong lvts_ctrl index
thermal/drivers/mediatek/lvts_thermal: Remove unused members from struct lvts_ctrl_data
thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data
Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984
based chipsets with on chipset connected led's using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and
can be controlled with various triggers.
Adds also debugfs interface for gpio control.
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
[kvalo: major reorg and cleanup]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[ansuel: rebase and small cleanup]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20230611080505.17393-1-ansuelsmth@gmail.com
Using 'hw_pressure' for local variable name is confusing in regard to the
per-CPU 'hw_pressure' variable that uses the same name:
include/linux/arch_topology.h:DECLARE_PER_CPU(unsigned long, hw_pressure);
... which puts it into a global scope for all code that includes
<linux/topology.h>, shadowing the local variable.
Rename it to avoid compiler confusion & Sparse warnings.
[ mingo: Expanded the changelog. ]
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20240425073709.379016-1-vincent.guittot@linaro.org
Closes: https://lore.kernel.org/oe-kbuild-all/202404250740.VhQQoD7N-lkp@intel.com/
Fixes: d4dbc99171 ("sched/cpufreq: Rename arch_update_thermal_pressure() => arch_update_hw_pressure()")
Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # QC SM8550 QRD
Some MeeGoPad top-set boxes have an ANX7428 Type-C Switch for USB3.1 Gen 1
and DisplayPort over Type-C alternate mode support.
The ANX7428 has a microcontroller which takes care of the PD negotiation
and automatically sets the builtin Crosspoint Switch to send the right
signal to the 4 highspeed pairs of the Type-C connector. It also takes
care of HPD and AUX channel routing for DP alternate mode.
IOW the ANX7428 operates fully autonomous and to the x5-Z8350 SoC
things look like there simple is a USB-3 Type-A connector and a
separate DisplayPort connector. Except that the BIOS does not
power on the ANX7428 at boot (meh).
Add a driver to power on the ANX7428. This driver is added under
drivers/platform/x86 rather than under drivers/usb/typec for 2 reasons:
1. This driver is specifically written to work with how the ANX7428 is
described in the ACPI tables of the MeeGoPad x86 (Cherry Trail) devices.
2. This driver only powers on the ANX7428 and does not do anything wrt
its Type-C functionality. It should be possible to tell the controller
which data- and/or power-role to negotiate and to swap the role(s) after
negotiation but the MeeGoPad top-set boxes always draw their power from
a separate power-connector and they only support USB host-mode. So this
functionality is unnecessary and due to lack of documentation this is
tricky to support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240514180343.70795-1-hdegoede@redhat.com
Add panel replay selective update support to debugfs status interface. In
case of sink supporting panel replay we will print out:
Sink support: PSR = no, Panel Replay = yes, Panel Replay Selective Update = yes
and PSR mode will look like this if printing out enabled panel replay
selective update:
PSR mode: Panel Replay Selective Update Enabled
Current PSR and panel replay printouts remain same.
Cc: Kunal Joshi <kunal1.joshi@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-13-jouni.hogander@intel.com
Part of intel_psr2_config_valid is valid for panel replay. rename it as
intel_sel_update_config_valid. Split psr2 specific part and name it as
intel_psr2_config_valid.
v3:
- move early transport check to psr2 specific check
- check intel_psr2_config_valid only for non-Panel Replay case
v2:
- use psr2_global_enabled for panel replay as well
- goto unsupported instead of return when global enabled check fails
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-12-jouni.hogander@intel.com
We are re-using PSR module parameters for panel replay. Update module
parameter descriptions with panel replay information:
enable_psr:
-1 (default) == follow what is in VBT
0 == disable PSR/PR
1 == Allow PSR1 and PR full frame update
2 == allow PSR1/PSR2 and PR Selective Update
enable_psr2_sel_fetch
0 == disable selective fetch for PSR and PR
1 (default) == allow selective fetch for PSR PR
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-11-jouni.hogander@intel.com
DP Panel replay uses SRD_STATUS to track it's status despite selective
update mode.
Bspec: 53370, 68920
v4:
- use PSR2_STATUS for eDP Panel Replay
- handle intel_psr_wait_exit_locked as well
v3:
- do not use PSR2_STATUS for PSR1
v2:
- use intel_dp_is_edp to differentiate
- modify debugfs status as well
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-9-jouni.hogander@intel.com
Currently intel_dp_get_su_granularity doesn't support panel replay.
This fix modifies it to support panel replay as well.
v4:
- use drm_dp_dpcd_readb instead of drm_dp_dpcd_read
- ensure return value is 0 if drm_dp_dpcd_readb fails
v3: use correct offset for DP_PANEL_PANEL_REPLAY_CAPABILITY
v2: rely on PSR definitions on common bits
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-8-jouni.hogander@intel.com
Add new boolean to store panel replay selective update support of sink into
intel_psr struct. Detect panel replay selective update support and store
it into this new boolean.
v3: Clear sink_panel_replay_su_support in intel_dp_detect
v2: Merge adding new boolean into this patch
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-7-jouni.hogander@intel.com
We are about to enable Panel Replay Selective update mode. Vsc revision 0x6
for Panel Replay no matter if it is selective update or full frame update
mode. Take this into account when preparing VSC SDP package.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-4-jouni.hogander@intel.com
After setting has_psr for panel replay as well crtc state dump is
improperly printing "psr: enabled" for Panel Replay as well. Fix this by
checking also has_panel_replay.
Fixes: 5afa6e4960 ("drm/i915/psr: Set intel_crtc_state->has_psr on panel replay as well")
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-3-jouni.hogander@intel.com
