This was missed - but it needs to be correct for the superblock recovery
tool that scans the start and end of the device for backup superblocks:
we don't want to pick up superblocks that belong to a different
partition that starts at a different offset.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Minor refactoring, so that bch2_sb_validate() can be used in the new
userspace superblock recovery tool.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
If we can't mount because of an incompatibility, print what's supported
and unsupported - to help solve PEBKAC issues.
Reported-by: Roland Vet <vet.roland@protonmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Just use sha256() instead of the clunky crypto API. This is much
simpler.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Since bcachefs does not access crc32c and crc64 through the crypto API,
there is no need to use module softdeps to ensure they are loaded.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This fixes another "rebalance spinning and doing no work" issue;
rebalance was reading extents it wanted to move, but then failing in
bch2_write() -> bch2_alloc_sectors_start() due to being unable to
allocate sufficient replicas.
This was triggered by a user playing with the durability settings, the
foreground device was an NVME device with durability=2, and originally
he'd set the background device to durability=2 as well, but changed it
back to 1 (the default) after seeing IO errors.
That meant that with replicas=2, we want to move data off the NVME
device which satisfies that constraint, but with a single durability=1
device on the background target there's no way to move the extent to
that target while satisfiying the "required replicas" constraint.
The solution for now is for bch2_data_update_init() to check for this,
and return an error - before kicking off the read.
bch2_data_update_init() already had two different checks for "will we be
able to write this extent", with partially duplicated code, so this
patch combines and improves that logic.
Additionally, we now always bail out and return an error if there's
insufficient space on the destination target. Previously, we only did
this for BCH_WRITE_alloc_nowait moves, because it might be the case that
copygc just needs to free up space on the destination target.
But we really shouldn't kick off a move if the destination is full, we
can't currently distinguish between "really full" and "just need to wait
for copygc", and if we are going to wait on copygc it'd be better to do
that before kicking off the move.
This will additionally fix "rebalance spinning" issues caused by a
filesystem that has more data than can fit in background_target - which
is a valid scenario, since we don't exclude foreground/cache devices
when calculating filesystem capacity.
Reported-by: Maël Kerbiriou <mael.kerbiriou@free.fr>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Now there are 16 journal buffers, 8 is too small to be enough.
Signed-off-by: Alan Huang <mmpgouride@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Next patch will be checking if the extent we're reading from matches the
IO failure we saw before marking the failure.
For this to work, __bch2_read() needs to take the same transaction
context that bch2_rbio_retry() uses to do that check.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Read flags are codepath dependent and change as they're passed around,
while the fields in rbio._state are mostly fixed properties of that
particular object.
Losing track of BCH_READ_data_update would be bad, and previously it was
not obvious if it was always correctly set in the rbio, so this is a
safety cleanup.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Merge cpuidle updates for 6.15-rc5, including a menu governor update
that is reported to improve some benchmark results quite significantly:
- Update the handling of the most recent idle intervals in the menu
cpuidle governor to prevent useful information from being discarded
by it in some cases and improve the prediction accuracy (Rafael
Wysocki).
- Make it possible to tell the intel_idle driver to ignore its built-in
table of idle states for the given processor, clean up the handling
of auto-demotion disabling on Baytrail and Cherrytrail chips in it,
and update its MAINTAINERS entry (David Arcari, Artem Bityutskiy,
Rafael Wysocki).
- Make some cpuidle drivers use for_each_present_cpu() instead of
for_each_possible_cpu() during initialization to avoid issues
occurring when nosmp or maxcpus=0 are used (Jacky Bai).
* pm-cpuidle:
cpuidle: Init cpuidle only for present CPUs
cpuidle: intel_idle: Update MAINTAINERS
intel_idle: introduce 'no_native' module parameter
cpuidle: menu: Update documentation after get_typical_interval() changes
cpuidle: menu: Avoid discarding useful information
cpuidle: menu: Eliminate outliers on both ends of the sample set
cpuidle: menu: Tweak threshold use in get_typical_interval()
cpuidle: menu: Use one loop for average and variance computations
cpuidle: menu: Drop a redundant local variable
intel_idle: clean up BYT/CHT auto demotion disable
Merge cpufreq updates for 6.15-rc1:
- Manage sysfs attributes and boost frequencies efficiently from
cpufreq core to reduce boilerplate code from drivers (Viresh Kumar).
- Minor cleanups to cpufreq drivers (Aaron Kling, Benjamin Schneider,
Dhananjay Ugwekar, Imran Shaik, and zuoqian).
- Migrate some cpufreq drivers to using for_each_present_cpu() (Jacky
Bai).
- cpufreq-qcom-hw DT binding fixes (Krzysztof Kozlowski).
- Use str_enable_disable() helper in cpufreq_online() (Lifeng Zheng).
- Optimize the amd-pstate driver to avoid cases where call paths end
up calling the same writes multiple times and needlessly caching
variables through code reorganization, locking overhaul and tracing
adjustments (Mario Limonciello, Dhananjay Ugwekar).
- Make it possible to avoid enabling capacity-aware scheduling (CAS) in
the intel_pstate driver and relocate a check for out-of-band (OOB)
platform handling in it to make it detect OOB before checking HWP
availability (Rafael Wysocki).
- Fix dbs_update() to avoid inadvertent conversions of negative integer
values to unsigned int which causes CPU frequency selection to be
inaccurate in some cases when the "conservative" cpufreq governor is
in use (Jie Zhan).
* pm-cpufreq: (91 commits)
dt-bindings: cpufreq: cpufreq-qcom-hw: Narrow properties on SDX75, SA8775p and SM8650
dt-bindings: cpufreq: cpufreq-qcom-hw: Drop redundant minItems:1
dt-bindings: cpufreq: cpufreq-qcom-hw: Add missing constraint for interrupt-names
dt-bindings: cpufreq: cpufreq-qcom-hw: Add QCS8300 compatible
cpufreq: Init cpufreq only for present CPUs
cpufreq: tegra186: Share policy per cluster
cpufreq/amd-pstate: Drop actions in amd_pstate_epp_cpu_offline()
cpufreq/amd-pstate: Stop caching EPP
cpufreq/amd-pstate: Rework CPPC enabling
cpufreq/amd-pstate: Drop debug statements for policy setting
cpufreq/amd-pstate: Update cppc_req_cached for shared mem EPP writes
cpufreq/amd-pstate: Move all EPP tracing into *_update_perf and *_set_epp functions
cpufreq/amd-pstate: Cache CPPC request in shared mem case too
cpufreq/amd-pstate: Replace all AMD_CPPC_* macros with masks
cpufreq/amd-pstate-ut: Adjust variable scope
cpufreq/amd-pstate-ut: Run on all of the correct CPUs
cpufreq/amd-pstate-ut: Drop SUCCESS and FAIL enums
cpufreq/amd-pstate-ut: Allow lowest nonlinear and lowest to be the same
cpufreq/amd-pstate-ut: Use _free macro to free put policy
cpufreq/amd-pstate: Drop `cppc_cap1_cached`
...
Merge thermal core updates and miscellaneous updates of the thermal
control subsystem for 6.15-rc1:
- Delay exposing thermal zone sysfs interface to prevent user space
from accessing thermal zones that have not been completely
initialized yet (Lucas De Marchi).
- Fix a spelling mistake in a comment in the thermal core (Colin Ian
King).
- Use kcalloc() instead of kzalloc() in some places in the thermal
control subsystem (Lukasz Luba, Ethan Carter Edwards).
- Clean up variable initialization in int340x_thermal_zone_add()
(Christophe JAILLET).
* thermal-core:
thermal: core: Delay exposing sysfs interface
thermal: core: Fix spelling mistake "Occurences" -> "Occurrences"
* thermal-misc:
thermal: intel: Clean up zone_trips[] initialization in int340x_thermal_zone_add()
thermal: hisi: Use kcalloc() instead of kzalloc() with multiplication
thermal: int340x: Use kcalloc() instead of kzalloc() with multiplication
thermal: k3_j72xx_bandgap: Use kcalloc() instead of kzalloc()
thermal/of: Use kcalloc() instead of kzalloc() with multiplication
thermal/debugfs: replace kzalloc() with kcalloc() in thermal_debug_tz_add()
Merge an ACPI CPPC update, ACPI platform-profile driver updates, an ACPI
APEI update and a MAINTAINERS update related to ACPI for 6.15-rc1:
- Add a missing header file include to the x86 arch CPPC code (Mario
Limonciello).
- Rework the sysfs attributes implementation in the ACPI platform-profile
driver and improve the unregistration code in it (Nathan Chancellor,
Kurt Borja).
- Prevent the ACPI HED driver from being built as a module and change
its initcall level to subsys_initcall to avoid initialization ordering
issues related to it (Xiaofei Tan).
- Update a maintainer email address in the ACPI PMIC entry in
MAINTAINERS (Mika Westerberg).
* acpi-x86:
x86/ACPI: CPPC: Add missing include
* acpi-platform-profile:
ACPI: platform_profile: Improve platform_profile_unregister()
ACPI: platform-profile: Fix CFI violation when accessing sysfs files
* acpi-apei:
ACPI: HED: Always initialize before evged
* acpi-misc:
MAINTAINERS: Use my kernel.org address for ACPI PMIC work
There are two panel_replay scenarios fbc wa need to be aware of,
panel replay with and without selective update capability.
Panel replay without selective update don't have any fbc wa.
So keep the fbc psr1 wa as it is.
The current fbc psr2 wa is mainly about selective fetch and we
need to apply the fbc wa if selective fetch is on - irrespective
of panel replay. Hence we can't exclude panel replay from the
fbc psr2 wa.
v1: keep panel_replay exclusion in PSR1 case (Jouni)
Patch description updated
Bspec: 66624, 50442
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321094529.197397-3-vinod.govindapillai@intel.com
FBC was disabled in case PSR2 selective update in display 12 to
14 as part of a wa. From xe2lpd onwards there is a logic to be
implemented to decide between FBC and selective update. Until
that logic is implemented keep FBC disabled in case selective
update is enabled.
v1: updated patch description and some explanation and todo
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321094529.197397-2-vinod.govindapillai@intel.com
Merge five ACPI driver updates for 6.15-rc1:
- Use the str_on_off() helper function instead of hard-coded strings in
the ACPI power resources handling code (Thorsten Blum).
- Add fan speed reporting for ACPI fans that have _FST, but otherwise
do not support the entire ACPI 4 fan interface (Joshua Grisham).
- Fix a stale comment regarding trip points in acpi_thermal_add() that
diverged from the commented code after removing _CRT evaluation from
acpi_thermal_get_trip_points() (xueqin Luo).
- Make ACPI button driver also subscribe to system events (Mario
Limonciello).
- Use the str_yes_no() helper function instead of hard-coded strings in
the ACPI backlight (video) driver (Thorsten Blum).
* acpi-power:
ACPI: power: Use str_on_off() helper function
* acpi-fan:
ACPI: fan: Add fan speed reporting for fans with only _FST
* acpi-thermal:
ACPI: thermal: Fix stale comment regarding trip points
* acpi-button:
ACPI: button: Install notifier for system events as well
* acpi-video:
ACPI: video: Use str_yes_no() helper in acpi_video_bus_add()
Binding AX25 socket by using the autobind feature leads to memory leaks
in ax25_connect() and also refcount leaks in ax25_release(). Memory
leak was detected with kmemleak:
================================================================
unreferenced object 0xffff8880253cd680 (size 96):
backtrace:
__kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43)
kmemdup_noprof (mm/util.c:136)
ax25_rt_autobind (net/ax25/ax25_route.c:428)
ax25_connect (net/ax25/af_ax25.c:1282)
__sys_connect_file (net/socket.c:2045)
__sys_connect (net/socket.c:2064)
__x64_sys_connect (net/socket.c:2067)
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
================================================================
When socket is bound, refcounts must be incremented the way it is done
in ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case of
autobind, the refcounts are not incremented.
This bug leads to the following issue reported by Syzkaller:
================================================================
ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de
------------[ cut here ]------------
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31
Modules linked in:
CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31
...
Call Trace:
<TASK>
__refcount_dec include/linux/refcount.h:336 [inline]
refcount_dec include/linux/refcount.h:351 [inline]
ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236
netdev_tracker_free include/linux/netdevice.h:4302 [inline]
netdev_put include/linux/netdevice.h:4319 [inline]
ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080
__sock_release net/socket.c:647 [inline]
sock_close+0xbc/0x240 net/socket.c:1398
__fput+0x3e9/0x9f0 fs/file_table.c:464
__do_sys_close fs/open.c:1580 [inline]
__se_sys_close fs/open.c:1565 [inline]
__x64_sys_close+0x7f/0x110 fs/open.c:1565
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
</TASK>
================================================================
Considering the issues above and the comments left in the code that say:
"check if we can remove this feature. It is broken."; "autobinding in this
may or may not work"; - it is better to completely remove this feature than
to fix it because it is broken and leads to various kinds of memory bugs.
Now calling connect() without first binding socket will result in an
error (-EINVAL). Userspace software that relies on the autobind feature
might get broken. However, this feature does not seem widely used with
this specific driver as it was not reliable at any point of time, and it
is already broken anyway. E.g. ax25-tools and ax25-apps packages for
popular distributions do not use the autobind feature for AF_AX25.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: syzbot+33841dc6aa3e1d86b78a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=33841dc6aa3e1d86b78a
Signed-off-by: Murad Masimov <m.masimov@mt-integration.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a basic test for checking whether scheduler respects the configured
credit limit.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-7-tvrtko.ursulin@igalia.com
Add a basic test for exercising modifying the entities scheduler list at
runtime.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-6-tvrtko.ursulin@igalia.com
Add some basic tests for exercising entity priority handling.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-5-tvrtko.ursulin@igalia.com
Add a very simple timeout test which submits a single job and verifies
that the timeout handling will run if the backend failed to complete the
job in time.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-4-tvrtko.ursulin@igalia.com
Implement a mock scheduler backend and add some basic test to exercise the
core scheduler code paths.
Mock backend (kind of like a very simple mock GPU) can either process jobs
by tests manually advancing the "timeline" job at a time, or alternatively
jobs can be configured with a time duration in which case they get
completed asynchronously from the unit test code.
Core scheduler classes are subclassed to support this mock implementation.
The tests added are just a few simple submission patterns.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Suggested-by: Philipp Stanner <phasta@kernel.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-3-tvrtko.ursulin@igalia.com
Move some options out into a new debug specific kconfig file in order to
make things a bit cleaner.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250324092633.49746-2-tvrtko.ursulin@igalia.com
It seems there really exists the need for a simple sysfs interface that
can be easily used from minimal initramfs images that don't contain much
more than busybox. However the current interface poses a challenge to
the removal of global GPIO numberspace. Add an item that tracks
extending the existing ABI with a per-chip export/unexport attribute
pair.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250321-gpio-todo-updates-v1-6-7b38f07110ee@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add an item tracking the treewide conversion of GPIO drivers to using
the new line value setter callbacks in struct gpio_chip instead of the
old ones that don't allow drivers to signal failures to callers.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250321-gpio-todo-updates-v1-5-7b38f07110ee@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
While there are surely some arguments in favor of integrating the GPIO
and pinctrl subsystems into one, I believe this is not the right
approach.
The GPIO subsystem uses intricate locking with SRCU to handle the fact
that both consumers and providers may run in different contexts.
Pin-controller drivers are always meant to run in process context. This
alone is a huge obstacle to any attempt at integration as evident by
many problems we already encountered during the hotplug rework.
The current glue code is pretty minimal and for most part already allows
GPIO controllers to query pinctrl about the information they need.
I suggest to drop this task and keep the subsystems separate even if
many pin-controllers implement GPIO functionality in addition to pin
functions.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250321-gpio-todo-updates-v1-3-7b38f07110ee@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The removal of linux/gpio.h is already tracked by the item about
converting drivers to using the descriptor-based API. Remove the
duplicate.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250321-gpio-todo-updates-v1-2-7b38f07110ee@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Failing to set up connector polling is not significant enough to
fail device probing. Print a warning and return nothing from the
init helper.
This only affects the managed init function. The unmanaged init
already never fails with an error.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250303145604.62962-4-tzimmermann@suse.de
Disconnecting a DisplayLink device results in the following kernel
error messages
[ 93.041748] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115
[ 93.055299] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe
[ 93.065363] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115
[ 93.078207] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe
coming from KMS poll helpers. Shutting down poll helpers runs them
one final time when the USB device is already gone.
Run drm_dev_unplug() first in udl's USB disconnect handler. Udl's
polling code already handles disconnects gracefully if the device has
been marked as unplugged.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: b1a981bd55 ("drm/udl: drop drm_driver.release hook")
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.8+
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250303145604.62962-2-tzimmermann@suse.de
Starting from MTL we don't have a platform agnostic way to validate
DC6 state due to dc6 counter has been removed to validate DC state.
The goal is to validate that the display HW can reach the DC6 power
state. There is no HW DC6 residency counter (and there wasn't such
a counter earlier either), so an alternative way is required. According
to the HW team the display driver has programmed everything correctly in
order to allow the DC6 power state if the DC5 power state is reached
(indicated by the HW DC5 residency counter incrementing) and DC6 is
enabled by the driver.
Driver could take a snapshot of the DC5 residency counter right
after it enables DC6 (dc5_residency_start) and increment the SW
DC6 residency counter right before it disables DC6 or when user space
reads the DC6 counter. So the driver would update the counter at these
two points in the following way:
dc6_residency_counter += dc5_current_count - dc5_start_count
v2: Update the discription. (Imre)
Read dc5 count during dc6 enable and disable then and update
dc6 residency counter. (Imre)
Remove variable from dmc structure. (Jani)
Updated the subject title.
v3: Add i915_power_domains lock to updated dc6 count in debugfs. (Imre)
Use flags to check dc6 enable/disable states. (Imre)
Move the display version check and counter read/update to
a helper. (Imre)
Resize the variable length. (Rodrigo)
Use old dc6 debugfs entry for every platform. (Rodrigo)
v4: Remove superfluous whitespace. (Jani)
Read DMC registers in intel_dmc.c (Jani)
Rename dc6_en_dis to dc6_enabled and change its type to bool. (Jani)
Rename update_dc6_count and move it to intel_dmc.c (Jani)
Rename dc6_en_dis to start_tracking. (Imre)
Have lock for dc6 state read aswelll. (Imre)
Keep the existing way print 'DC5 -> DC6 count' along with
new 'DC6 Allowed Count' print. (Imre)
Add counters in intel_dmc struct. (Imre)
Have interface to return dc6 allowed count. (Imre)
Rename dc6_count to dc6_allowed_count. (Rodrigo)
v5: Rename counters and move in to dc6_allowed structure. (Imre)
Order declaration lines in decreasing line length. (Imre)
Update start_tacking logic. (Imre)
Move get couner inside lock and DISPLAY_VER code to helper. (Imre)
v6: Change intel_dmc_get_dc6_allowed_count return type to bool. (Imre)
Update debugfs print to better allien with old print. (Imre)
Remove braces at if/else for signle line statements. (Imre)
v7: Remove in line variable declaration. (Imre)
v8: Rebase the changes.
Signed-off-by: Mohammed Thasleem <mohammed.thasleem@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250321123707.287745-1-mohammed.thasleem@intel.com
Currently, vrr.enable is intended only for variable refresh rate timings.
At this point, we do not set fixed refresh rate timings, but the GOP can,
which creates a problem during the readback of vrr.enable.
The GOP enables the VRR timing generator with fixed timings, while the
driver only recognizes the VRR timing generator as enabled with
variable timings. This discrepancy causes an issue due to the
fixed refresh rate check during readback. Since the VRR timing generator
is enabled and we do not support fixed timings, the readback should set
vrr.enable so that the driver can disable the VRR timing generator.
However, the current check does not allow this.
Therefore, remove the fixed refresh rate check during readback.
Fixes: 27217f9d18 ("drm/i915/vrr: Track vrr.enable only for variable timing")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250322044345.3827137-3-ankit.k.nautiyal@intel.com
Add fixed refresh rate mode in crtc_state dump.
VRR Timing Generator is running in fixed refresh rate mode when
vrr.vmin = vrr.vmax = vrr.flipline.
v2: s/fixed_rr/fixed rr for consistency with the other stuff. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250322044345.3827137-2-ankit.k.nautiyal@intel.com
For flexible routing, eint will be divided into 5 bases,
and it will obtain the operation address through the pins array.
Signed-off-by: Hao Chang <ot_chhao.chang@mediatek.com>
Signed-off-by: Qingliang Li <qingliang.li@mediatek.com>
Link: https://lore.kernel.org/20250322035307.4811-2-ot_chhao.chang@mediatek.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The function worker_thread() is programmed in a way that roughly
doubles the number of expectable context switches, because it enforces
blocking reads:
Performance counter stats for 'perf bench sched pipe':
2,000,004 context-switches
11.859548321 seconds time elapsed
0.674871000 seconds user
8.076890000 seconds sys
The result of this behavior is that the blocking reads by far dominate
the performance analysis of 'perf bench sched pipe':
Samples: 78K of event 'cycles:P', Event count (approx.): 27964965844
Overhead Command Shared Object Symbol
25.28% sched-pipe [kernel.kallsyms] [k] read_hpet
8.11% sched-pipe [kernel.kallsyms] [k] retbleed_untrain_ret
2.82% sched-pipe [kernel.kallsyms] [k] pipe_write
From the code, it is unclear if that behavior is wanted but the log
says that at least Ingo Molnar aims to mimic lmbench's lat_ctx, that
doesn't handle the pipe ends that way
(https://sourceforge.net/p/lmbench/code/HEAD/tree/trunk/lmbench2/src/lat_ctx.c)
Fix worker_thread() by always first feeding the write ends of the pipes
and then trying to read.
This roughly halves the context switches and runtime of pure
'perf bench sched pipe':
Performance counter stats for 'perf bench sched pipe':
1,005,770 context-switches
6.033448041 seconds time elapsed
0.423142000 seconds user
4.519829000 seconds sys
And the blocking reads do no longer dominate the analysis at the above
extreme:
Samples: 40K of event 'cycles:P', Event count (approx.): 14309364879
Overhead Command Shared Object Symbol
12.20% sched-pipe [kernel.kallsyms] [k] read_hpet
9.23% sched-pipe [kernel.kallsyms] [k] retbleed_untrain_ret
3.68% sched-pipe [kernel.kallsyms] [k] pipe_write
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Acked-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20250323140316.19027-2-dirk@gouders.net
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Commit 54f9aa1092 ("tools/perf/powerpc/util: Add support to
handle compatible mode PVR for perf json events") introduced
to select proper JSON events in case of compat mode using
auxiliary vector. But this caused a compilation error in ppc64
Big Endian.
arch/powerpc/util/header.c: In function 'is_compat_mode':
arch/powerpc/util/header.c:20:21: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
20 | if (!strcmp((char *)platform, (char *)base_platform))
| ^
arch/powerpc/util/header.c:20:39: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
20 | if (!strcmp((char *)platform, (char *)base_platform))
|
Commit saved the getauxval(AT_BASE_PLATFORM) and getauxval(AT_PLATFORM)
return values in u64 which causes the compilation error.
Patch fixes this issue by changing u64 to "unsigned long".
Fixes: 54f9aa1092 ("tools/perf/powerpc/util: Add support to handle compatible mode PVR for perf json events")
Signed-off-by: Likhitha Korrapati <likhitha@linux.ibm.com>
Reviewed-by: Athira Rajeev <atrajeev@linux.ibm.com>
Link: https://lore.kernel.org/r/20250321100726.699956-1-likhitha@linux.ibm.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
When enabling the libperl feature the build uses perl's build flags
(ccopts) but filters out various flags, e.g. for LTO.
While this is conceptually correct, it is insufficient in practice,
since only "-flto=auto" is filtered out. When perl itself is built with
"-flto" this can cause parts of perf being built with LTO and others
without, giving exciting build errors like e.g.:
../tools/perf/pmu-events/pmu-events.c:72851:(.text+0xb79): undefined
reference to `strcmp_cpuid_str' collect2: error: ld returned 1 exit status
Fix this by filtering all matching flag values of -flto{=n,auto,..}.
Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Link: https://lore.kernel.org/r/20250321082038.27901-2-holger@applied-asynchrony.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Some DSI panel vendors end up hardcoding PPS params because of which
it does not listen to the params sent from the source. We use the
default config tables for DSI panels when using DSC 1.1 rather than
calculate our own rc parameters.
--v2
-Use intel_crtc_has_type [Jani]
--v4
-Use a function to check Mipi dsi dsc 1.1 condition [Ankit]
-Add documentation for using this condition [Ankit]
-Rebase
--v5
-Pass only the crtc_state [Jani]
-Fixup the comment [Jani]
-Check for dsc major version [Jani]
-Use co-developed-by tag [Jani]
--v6
-Add more definition of the issue and solution in the comment [Ankit]
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13719
Co-developed-by: William Tseng <william.tseng@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228152531.403026-1-suraj.kandpal@intel.com
