aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/stackcollapse.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2025-08-26drm/sysfb: Blit to CRTC destination formatThomas Zimmermann2-11/+20
Use the color format stored in struct drm_sysfb_crtc_state for color-format conversion instead of the scanout-buffer format announced by firmware. Currently, both values are identical. This will allow drivers to modify the CRTC's input format to a certain extend. Specifically, vesadrm will be able to display RGB framebuffers when the scanout buffer is of C8 format. With color- format conversion to RGB332 and correct setup of the C8 palette, displaying XRGB8888-based buffers under C8 can be achieved. v2: - refer to RGB332 as CRTC input format Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-5-tzimmermann@suse.de
2025-08-26drm/sysfb: Find screen_info format with helpersThomas Zimmermann1-12/+9
Convert drm_sysfb_get_format_si() to lookup the screen_info color format as struct pixel_format with screen_info_pixel_format(). Then search the list of given formats for the screen_info format with pixel_format_equal(). Replaces custom code with helpers. The pixel-compare helper pixel_format_equal() also handles indexed color formats. Prepares for sysfb drivers to support color palettes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-4-tzimmermann@suse.de
2025-08-26video: screen_info: Add pixel-format helper for linear framebuffersThomas Zimmermann2-0/+57
Add screen_info_pixel_format(), which converts a screen_info's information about the color format to struct pixel_format. The encoding within the screen_info structure is complex and therefore prone to errors. Later patches will convert callers to use the pixel format. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-3-tzimmermann@suse.de
2025-08-26video: pixel_format: Add compare helpersThomas Zimmermann1-0/+58
Add helpers that compare two pixel-format descriptions against each other. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-2-tzimmermann@suse.de
2025-08-25HID: i2c-hid: Make elan touch controllers power on after panel is enabledPin-yen Lin3-19/+40
Introduce a new HID quirk to indicate that this device has to be enabled after the panel's backlight is enabled, and update the driver data for the elan devices to enable this quirk. This cannot be a I2C HID quirk because the kernel needs to acknowledge this before powering up the device and read the VID/PID. When this quirk is enabled, register .panel_enabled()/.panel_disabling() instead for the panel follower. Also rename the *panel_prepare* functions into *panel_follower* because they could be called in other situations now. Fixes: bd3cba00dcc63 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens") Fixes: d06651bebf99e ("HID: i2c-hid: elan: Add elan-ekth6a12nay timing") Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Pin-yen Lin <treapking@chromium.org> Acked-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250818115015.2909525-2-treapking@chromium.org
2025-08-25drm/panel: Allow powering on panel follower after panel is enabledPin-yen Lin2-11/+76
Some touch controllers have to be powered on after the panel's backlight is enabled. To support these controllers, introduce .panel_enabled() and .panel_disabling() to panel_follower_funcs and use them to power on the device after the panel and its backlight are enabled. Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250818115015.2909525-1-treapking@chromium.org
2025-08-23drm/msm: fix msm_gem_vma_new() allocations for managed GPUVMsDmitry Baryshkov1-6/+7
Since commit 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") MSM driver fails to init, failing with "[drm:msm_gpu_init] *ERROR* could not allocate memptrs: -22" errors. The mentioned commit reworked the function, but didn't take into account that op_map is initialized at the top of the function, while ranges might change if GPUVM is managed by the kernel. Move op_mode initialization after finalizing all addresses and right before the drm_gpuva_init_from_op() call. Reported-by: Danct12 <danct12@disroot.org> Fixes: 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Rob Clark <robin.clark@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250823-msm-fix-gpuvm-init-v1-1-e199cd5b1983@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-22drm/rockchip: dsi2: add support rk3576Guochun Huang1-0/+21
Add the necessary specific bits to support the rk3576-variant of the DW-DSI2 controller. Signed-off-by: Guochun Huang <hero.huang@rock-chips.com> [adapted from the vendor-kernel for mainline] Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-10-heiko@sntech.de
2025-08-22dt-bindings: display: rockchip: Add rk3576 to RK3588 DW DSI2 controller schemaHeiko Stuebner1-0/+1
The rk3576 controller is based on the same newer Synopsis IP as the one found in the rk3588. Its external setting bits in the GRF are different though, so it needs its own distinct compatible. Acked-by: "Rob Herring (Arm)" <robh@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-9-heiko@sntech.de
2025-08-22drm/panel: ilitek-ili9881c: Add Bestar BSD1218-A101KL68 supportHeiko Stuebner1-0/+221
Add support for the Bestar BSD1218-A101KL68 panel. The init table comes from the Firefly BSP ([1]). [1] https://gitlab.com/firefly-linux/kernel/-/blob/rk3588/firefly/arch/arm64/boot/dts/rockchip/aio-3588l-mipi101-BSD1218-A101KL68.dtsi Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-7-heiko@sntech.de
2025-08-22dt-bindings: display: ili9881c: Add Bestar BSD1218-A101KL68 LCD panelHeiko Stuebner1-0/+1
Document the compatible value for Bestar BSD1218-A101KL68 LCD panels that are based around the ili9881c controller. Acked-by: "Rob Herring (Arm)" <robh@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-6-heiko@sntech.de
2025-08-22dt-bindings: vendor-prefixes: Add prefix for Shenzhen Bestar ElectronicHeiko Stuebner1-0/+2
Add the prefix for Bestar, named in full both on Panelook.com and their display datasheets as Shenzhen Bestar Electronic Technology Co., Ltd. which produces at least DSI displays and maybe more. Acked-by: "Rob Herring (Arm)" <robh@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-5-heiko@sntech.de
2025-08-22drm/panel: ilitek-ili9881c: convert (un-)prepare to mipi_dsi_multi_contextHeiko Stuebner1-45/+21
This saves some lines for error handling. For the address mode change, that value is always an u8, so switching to dcs_write_buffer function should be appropriate. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-4-heiko@sntech.de
2025-08-22drm/panel: ilitek-ili9881c: move display_on/_off dcs calls to (un-)prepareHeiko Stuebner1-20/+7
At least for panel-bridges, the atomic_enable call is defined as being called right after the preceding element in the display pipe is enabled. It is also stated that "The bridge can assume that the display pipe (i.e. clocks and timing signals) feeding it is running when this callback is called" This means the DSI controller driving this display would have already switched over to video-mode from command mode and thus dcs functions should not be called anymore at this point. This caused a non-working display for me, when trying to enable the rk3576 dsi controller using a display using this controller. Therefore move the display_on/off calls the more appropriate prepare/unprepare callbacks. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-3-heiko@sntech.de
2025-08-22drm/panel: ilitek-ili9881c: turn off power-supply when init failsHeiko Stuebner1-4/+8
The prepare function turns on the power-supply regulator first, when preparing the display. But in an error case, just returns the error code, but does not power off the regulator again, fix that. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-2-heiko@sntech.de
2025-08-22drm/bridge: simple-bridge: Add support for radxa ra620Andy Yan1-0/+5
The RA620 is an active DP to HDMI converter chip, basically no software is involved to drive it. Add it to simple bridge to make it can be find by the drm bridge chain. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250822063959.692098-7-andyshrk@163.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-22dt-bindings: display: simple-bridge: Add ra620 compatibleAndy Yan1-0/+1
RA620 is a DP to HDMI bridge converter from RADXA, which first found be used on ROCK 5 ITX. This chip can be used without involving software. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250822063959.692098-6-andyshrk@163.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-22drm: re-allow no-op changes on non-primary planes in async flipsXaver Hugl1-11/+12
Commit fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async flip") unintentionally disallowed no-op changes on non-primary planes that the driver doesn't allow async flips on. This broke async flips for compositors that disable the cursor plane in every async atomic commit. To fix that, change drm_atomic_set_property to again only run atomic_async_check if the plane would actually be changed by the atomic commit. Fixes: fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async flip") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263 Signed-off-by: Xaver Hugl <xaver.hugl@kde.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://lore.kernel.org/r/20250822152849.87843-1-xaver.hugl@kde.org [andrealmeid: fix checkpatch warning] Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-08-21Documentation: accel: amdxdna: Update compiler informationLizhi Hou1-5/+5
The compiler information is outdated. Update it to the latest. Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://lore.kernel.org/r/20250820233817.4050006-1-lizhi.hou@amd.com
2025-08-21drm/panel: jdi-lpm102a188a: Fix error code in jdi_panel_prepare()Dan Carpenter1-1/+3
If the mipi_dsi_dual() macro fails, the error code is stored in dsi_ctx.accum_err. Propagate that error back to the caller instead of returning success as the current code does. Fixes: a6adf47d30cc ("drm/panel: jdi-lpm102a188a: Fix bug and clean up driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/aKcRfq8xBrFmhqmO@stanley.mountain
2025-08-21drm: of: fix documentation referenceRaphael Gallais-Pou1-2/+5
Documentation/devicetree/bindings/graph.txt content has move directly to the dt-schema repo in commit 4b52be0ce6ad ("dt-bindings: Remove plain text OF graph binding"). Point to the YAML of the official repo instead of the old file. Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250328114148.260322-1-rgallaispou@gmail.com Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2025-08-21drm/dp: drm_edp_backlight_set_level: do not always send 3-byte commandsVal Packett1-1/+3
At least some panels using the LSB register are not happy with the unconditional increase of the command buffer to 3 bytes. With the BOE NE14QDM in my Dell Latitude 7455, the recent patches for luminance based brightness have introduced a regression: the brightness range stopped being contiguous and became nonsensical (it probably was interpreting the last 2 bytes of the buffer and not the first 2). Change from using a fixed sizeof() to a length variable that's only set to 3 when luminance is used. Let's leave the default as 2 even for the single-byte version, since that's how it worked before. Fixes: f2db78e37fe7 ("drm/dp: Modify drm_edp_backlight_set_level") Signed-off-by: Val Packett <val@packett.cool> Tested-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250706204446.8918-1-val@packett.cool Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-20drm/bridge: anx7625: register content protect propertyHsin-Yi Wang1-0/+1
Set the `support_hdcp` bit to enable the connector to register content protection during initialization. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Fei Shao <fshao@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250812082135.3351172-3-fshao@chromium.org
2025-08-20drm_bridge: register content protect propertyHsin-Yi Wang2-0/+13
Some bridges can update HDCP status based on userspace requests if they support HDCP. The HDCP property is created after connector initialization and before registration, just like other connector properties. Add the content protection property to the connector if a bridge supports HDCP. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Fei Shao <fshao@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250812082135.3351172-2-fshao@chromium.org
2025-08-20drm/panel: panel-samsung-s6e88a0-ams427ap24: Fix includesThomas Zimmermann1-0/+2
Include <linux/property.h> to declare device_property_read_bool() and <linux/mod_devicetable.h> to declare struct of_device_id. Avoids the dependency on the backlight header to include both. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250812082509.227879-1-tzimmermann@suse.de
2025-08-20drm/virtio: clean up minor codestyle issuesAthul Raj Kollareth5-15/+16
Fix codestyle warnings and errors generated by CHECKPATCH in virtio source files. Signed-off-by: Athul Raj Kollareth <krathul3152@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250813062109.5326-1-krathul3152@gmail.com
2025-08-19drm/gpusvm: Make drm_gpusvm_for_each_* macros publicHimal Prasad Ghimiray2-97/+95
The drm_gpusvm_for_each_notifier, drm_gpusvm_for_each_notifier_safe and drm_gpusvm_for_each_range_safe macros are useful for locating notifiers and ranges within a user-specified range. By making these macros public, we enable broader access and utility for developers who need to leverage them in their implementations. v2 (Matthew Brost) - drop inline __drm_gpusvm_range_find - /s/notifier_iter_first/drm_gpusvm_notifier_find Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250819162058.2777306-5-himal.prasad.ghimiray@intel.com
2025-08-19drm/gpuvm: Introduce drm_gpuvm_madvise_ops_createHimal Prasad Ghimiray2-37/+191
This ops is used to iterate over GPUVA's in the user-provided range and split the existing sparse VMA's if the start or end of the input range lies within it. The operations can create up to 2 REMAPS and 2 MAPs. The primary use case is for drivers to assign attributes to GPU VAs in the specified range without performing unmaps or merging mappings, supporting fine-grained control over sparse va's. Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Himal Prasad Ghimiray<himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250819162058.2777306-4-himal.prasad.ghimiray@intel.com
2025-08-19drm/gpuvm: Kill drm_gpuva_init()Boris Brezillon2-12/+11
drm_gpuva_init() only has one internal user, and given we are about to add new optional fields, it only add maintenance burden for no real benefit, so let's kill the thing now. Cc: Danilo Krummrich <dakr@kernel.org> Cc: Rob Clark <robin.clark@oss.qualcomm.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250819162058.2777306-3-himal.prasad.ghimiray@intel.com
2025-08-19drm/gpuvm: Pass map arguments through a structBoris Brezillon7-71/+102
We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](), so, before we do that, let's pass arguments through a struct instead of changing each call site every time a new optional argument is added. Cc: Danilo Krummrich <dakr@kernel.org> Cc: Brendan King <Brendan.King@imgtec.com> Cc: Matt Coster <matt.coster@imgtec.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Caterina Shablia <caterina.shablia@collabora.com> Cc: Rob Clark <robin.clark@oss.qualcomm.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> Co-developed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> # imagination/pvr_vm.c Acked-by: Matt Coster <matt.coster@imgtec.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250819162058.2777306-2-himal.prasad.ghimiray@intel.com
2025-08-20rust: drm: update ARef and AlwaysRefCounted imports from sync::arefShankari Anand3-3/+5
Update call sites in drm to import `ARef` and `AlwaysRefCounted` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Link: https://lore.kernel.org/r/20250815161706.1324860-1-shankari.ak0208@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-18accel/amdxdna: Add a function to walk hardware contextsLizhi Hou8-95/+102
Walking hardware contexts created by a process is duplicated in multiple spots. Add a function, amdxdna_hwctx_walk(), and replace all spots. hwctx_srcu and dev_lock are good enough to protect hardware context list. Remove hwctx_lock. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://lore.kernel.org/r/20250815171634.3417487-1-lizhi.hou@amd.com
2025-08-17Linux 6.17-rc2v6.17-rc2Linus Torvalds1-1/+1
2025-08-15drm/bridge: display-connector: don't set OP_DETECT for DisplayPortsDmitry Baryshkov1-1/+2
Detecting the monitor for DisplayPort targets is more complicated than just reading the HPD pin level: it requires reading the DPCD in order to check what kind of device is attached to the port and whether there is an actual display attached. In order to let DRM framework handle such configurations, disable DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so it is valid for the bridge to report HPD events. Currently inside the kernel there are only two targets which list hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and arm64/qcom/sa8295p-adp. Both should be fine with this change. Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konradybcio@kernel.org> Cc: linux-arm-msm@vger.kernel.org Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-15x86/cpuid: Remove transitional <asm/cpuid.h> headerAhmed S. Darwish1-8/+0
All CPUID call sites were updated at commit: 968e30006807 ("x86/cpuid: Set <asm/cpuid/api.h> as the main CPUID header") to include <asm/cpuid/api.h> instead of <asm/cpuid.h>. The <asm/cpuid.h> header was still retained as a wrapper, just in case some new code in -next started using it. Now that everything is merged to Linus' tree, remove the header. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250815070227.19981-2-darwi@linutronix.de
2025-08-15x86/sev: Ensure SVSM reserved fields in a page validation entry are ↵Tom Lendacky2-0/+3
initialized to zero In order to support future versions of the SVSM_CORE_PVALIDATE call, all reserved fields within a PVALIDATE entry must be set to zero as an SVSM should be ensuring all reserved fields are zero in order to support future usage of reserved areas based on the protocol version. Fixes: fcd042e86422 ("x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Joerg Roedel <joerg.roedel@amd.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/7cde412f8b057ea13a646fb166b1ca023f6a5031.1755098819.git.thomas.lendacky@amd.com
2025-08-15virt: sev-guest: Satisfy linear mapping requirement in get_derived_key()Tom Lendacky1-15/+12
Commit 7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of guest request buffers") added a check that requires the guest request buffers to be in the linear mapping. The get_derived_key() function was passing a buffer that was allocated on the stack, resulting in the call to snp_send_guest_request() returning an error. Update the get_derived_key() function to use an allocated buffer instead of a stack buffer. Fixes: 7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of guest request buffers") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: <stable@kernel.org> Link: https://lore.kernel.org/9b764ca9fc79199a091aac684c4926e2080ca7a8.1752698495.git.thomas.lendacky@amd.com
2025-08-15drm/panfrost: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus1-2/+0
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250704075411.3218059-1-sakari.ailus@linux.intel.com
2025-08-15drm/panthor: Add support for Mali-Gx20 and Mali-Gx25 GPUsKarunika Choo2-0/+20
This patch adds firmware binary and GPU model naming support for Mali-Gx20 and Mali-Gx25 GPUs. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-8-karunika.choo@arm.com
2025-08-15drm/panthor: Make MMU cache maintenance use FLUSH_CACHES commandKarunika Choo1-0/+33
As the FLUSH_MEM and FLUSH_PT MMU_AS commands are deprecated in GPUs from Mali-Gx20 onwards, this patch adds support for performing cache maintenance via the FLUSH_CACHES command in GPU_COMMAND in place of FLUSH_MEM and FLUSH_PT commands. Mali-Gx10 and Mali-Gx15 GPUs also has support for the FLUSH_CACHES command and will also use this by default going forward. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-7-karunika.choo@arm.com
2025-08-15drm/panthor: Serialize GPU cache flush operationsKarunika Choo1-0/+7
In certain scenarios, it is possible for multiple cache flushes to be requested before the previous one completes. This patch introduces the cache_flush_lock mutex to serialize these operations and ensure that any requested cache flushes are completed instead of dropped. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Co-developed-by: Dennis Tsiang <dennis.tsiang@arm.com> Signed-off-by: Dennis Tsiang <dennis.tsiang@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-6-karunika.choo@arm.com
2025-08-15drm/panthor: Add support for Mali-Gx15 family of GPUsKarunika Choo4-0/+22
Mali-Gx15 introduces a new GPU_FEATURES register that provides information about GPU-wide supported features. The register value will be passed on to userspace via gpu_info. Additionally, Mali-Gx15 presents an 'Immortalis' naming variant depending on the shader core count and presence of Ray Intersection feature support. This patch adds: - support for correctly identifying the model names for Mali-Gx15 GPUs. - arch 11.8 FW binary support Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-5-karunika.choo@arm.com
2025-08-15drm/panthor: Add support for Mali-G710, Mali-G510 and Mali-G310Karunika Choo2-0/+8
This patch adds GPU model name and FW binary support for Mali-G710, Mali-G510, and Mali-G310. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-4-karunika.choo@arm.com
2025-08-15drm/panthor: Simplify getting the GPU model nameKarunika Choo1-44/+17
This patch replaces the panthor_model structure with a simple switch case based on the product_id which is in the format of: ((arch_major << 24) | product_major) This simplifies comparison and allows extending of the function to accommodate naming differences based on supported GPU features. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-3-karunika.choo@arm.com
2025-08-15drm/panthor: Add panthor_hw and move gpu_info initialization into itKarunika Choo5-95/+130
This patch introduces panthor_hw and moves the initialization of the gpu_info struct into panthor_hw.c in preparation of handling future GPU register and naming changes. Future GPU support can be added by extending panthor_gpu_info_init() with the necessary register reads behind GPU architecture version guards if the change is minor. For more complex changes, the function can be forked and the appropriate function will need to be called based on the GPU architecture version. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250807162633.3666310-2-karunika.choo@arm.com
2025-08-14drm/panel: novatek-nt35560: Clean up driverBrigham Campbell1-138/+60
Update driver to use the "multi" variants of MIPI functions which facilitate improved error handling and cleaner driver code. Remove information from a comment which was made obsolete by commit 994ea402c767 ("drm/panel: Rename Sony ACX424 to Novatek NT35560"), which determined that this driver supports the Novatek NT35560 panel controller. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Brigham Campbell <me@brighamcampbell.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250731032343.1258366-4-me@brighamcampbell.com
2025-08-14drm: Add MIPI read_multi func and two write macrosBrigham Campbell2-0/+72
Create mipi_dsi_dcs_read_multi(), which accepts a mipi_dsi_multi_context struct for improved error handling and cleaner panel driver code. Create mipi_dsi_dcs_write_var_seq_multi() and mipi_dsi_generic_write_var_seq_multi() macros which allow MIPI panel drivers to write non-constant data to display controllers. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Brigham Campbell <me@brighamcampbell.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250731032343.1258366-3-me@brighamcampbell.com
2025-08-14drm/xe/pf: Set VF LMEM BAR sizeMichał Winiarski2-0/+23
LMEM is partitioned between multiple VFs and we expect that the more VFs we have, the less LMEM is assigned to each VF. This means that we can achieve full LMEM BAR access without the need to attempt full VF LMEM BAR resize via pci_resize_resource(). Always try to set the largest possible BAR size that allows to fit the number of enabled VFs and inform the user in case the resize attempt is not successful. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20250527120637.665506-7-michal.winiarski@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 32a4d1b98e6663101fd0abfaf151c48feea7abb1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-14ata: libata-scsi: Fix CDL controlIgor Pylypiv1-8/+3
Delete extra checks for the ATA_DFLAG_CDL_ENABLED flag that prevent SET FEATURES command from being issued to a drive when NCQ commands are active. ata_mselect_control_ata_feature() sets / clears the ATA_DFLAG_CDL_ENABLED flag during the translation of MODE SELECT to SET FEATURES. If SET FEATURES gets deferred due to outstanding NCQ commands, the original MODE SELECT command will be re-queued. When the re-queued MODE SELECT goes through the ata_mselect_control_ata_feature() translation again, SET FEATURES will not be issued because ATA_DFLAG_CDL_ENABLED has been already set or cleared by the initial translation of MODE SELECT. The ATA_DFLAG_CDL_ENABLED checks in ata_mselect_control_ata_feature() are safe to remove because scsi_cdl_enable() implements a similar logic that avoids enabling CDL if it has been enabled already. Fixes: 17e897a45675 ("ata: libata-scsi: Improve CDL control") Cc: stable@vger.kernel.org Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2025-08-14ata: libata-eh: Fix link state check for IDE/PATA portsDamien Le Moal1-2/+7
Commit 4371fe1ba400 ("ata: libata-eh: Avoid unnecessary resets when revalidating devices") replaced the call to ata_phys_link_offline() in ata_eh_revalidate_and_attach() with the new function ata_eh_link_established() which relaxes the checks on a device link state to account for low power mode transitions. However, this change assumed that the device port has a valid scr_read method to obtain the SStatus register for the port. This is not always the case, especially with older IDE/PATA adapters (e.g. PATA/IDE devices emulated with QEMU). For such adapter, ata_eh_link_established() will always return false, causing ata_eh_revalidate_and_attach() to go into its error path and ultimately to the device being disabled. Avoid this by restoring the previous behavior, which is to assume that the link is online if reading the port SStatus register fails. While at it, also fix the spelling of SStatus in the comment describing the function ata_eh_link_established(). Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Fixes: 4371fe1ba400 ("ata: libata-eh: Avoid unnecessary resets when revalidating devices") Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Reviewed-by: Niklas Cassel <cassel@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-04 05:59:46 +0000