summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-05-02pwm: add support for NXPs high-side switch MC33XS2410Dimitri Fedrau
The MC33XS2410 is a four channel high-side switch. Featuring advanced monitoring and control function, the device is operational from 3.0 V to 60 V. The device is controlled by SPI port for configuration. Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Link: https://lore.kernel.org/r/20250407-mc33xs2410-v9-2-57adcb56a6e4@liebherr.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-05-02Merge tag 'pinctrl-v6.15-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Fix potential NULL dereference in the i.MX driver - Fix the pull up/down resistor values in the Meson driver - Fix the mapping of the PHY LED pins in the Airhoa driver - Fix EINT interrupts on older controllers and a debounce value issue in the Mediatek driver - Fix an erronoeus PINGROUP define in the Qualcomm driver * tag 'pinctrl-v6.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: qcom: Fix PINGROUP definition for sm8750 pinctrl: mediatek: common-v1: Fix error checking in mtk_eint_init() pinctrl: mediatek: Fix new design debounce issue pinctrl: mediatek: common-v1: Fix EINT breakage on older controllers pinctrl: airoha: fix wrong PHY LED mapping and PHY2 LED defines pinctrl: meson: define the pull up/down resistor value as 60 kOhm pinctrl: imx: Return NULL if no group is matched and found
2025-05-02Merge tag 'iommu-fixes-v6.15-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull iommu fixes from Joerg Roedel: "ARM-SMMU fixes: - Fix broken detection of the S2FWB feature - Ensure page-size bitmap is initialised for SVA domains - Fix handling of SMMU client devices with duplicate Stream IDs - Don't fail SMMU probe if Stream IDs are aliased across clients Intel VT-d fixes: - Add quirk for IGFX device - Revert an ATS change to fix a boot failure AMD IOMMU: - Fix potential buffer overflow Core: - Fix for iommu_copy_struct_from_user()" * tag 'iommu-fixes-v6.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommu/vt-d: Apply quirk_iommu_igfx for 8086:0044 (QM57/QS57) iommu/vt-d: Revert ATS timing change to fix boot failure iommu: Fix two issues in iommu_copy_struct_from_user() iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid iommu/arm-smmu-v3: Fail aliasing StreamIDs more gracefully iommu/arm-smmu-v3: Fix iommu_device_probe bug due to duplicated stream ids iommu/arm-smmu-v3: Fix pgsize_bit for sva domains iommu/arm-smmu-v3: Add missing S2FWB feature detection
2025-05-02ublk: store request pointer in ublk_ioCaleb Sander Mateos
A ublk_io is converted to a request in several places in the I/O path by using blk_mq_tag_to_rq() to look up the (qid, tag) on the ublk device's tagset. This involves a bunch of dereferences and a tag bounds check. To make this conversion cheaper, store the request pointer in ublk_io. Overlap this storage with the io_uring_cmd pointer. This is safe because the io_uring_cmd pointer is only valid if UBLK_IO_FLAG_ACTIVE is set on the ublk_io, the request pointer is valid if UBLK_IO_FLAG_OWNED_BY_SRV, and these flags are mutually exclusive. Suggested-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250430225234.2676781-10-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02ublk: check UBLK_IO_FLAG_OWNED_BY_SRV in ublk_abort_queue()Caleb Sander Mateos
ublk_abort_queue() currently checks whether the UBLK_IO_FLAG_ACTIVE flag is cleared to tell whether to abort each ublk_io in the queue. But it's possible for a ublk_io to not be ACTIVE but also not have a request in flight, such as when no fetch request has yet been submitted for a tag or when a fetch request is cancelled. So ublk_abort_queue() must additionally check for an inflight request. Simplify this code by checking for UBLK_IO_FLAG_OWNED_BY_SRV instead, which indicates precisely whether a request is currently inflight. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250430225234.2676781-9-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02ublk: don't call ublk_dispatch_req() for NEED_GET_DATACaleb Sander Mateos
ublk_dispatch_req() currently handles 3 different cases: incoming ublk requests that don't need to wait for a data buffer, incoming requests that do need to wait for a buffer, and resuming those requests once the buffer is provided. But the call site that provides a data buffer (UBLK_IO_NEED_GET_DATA) is separate from those for incoming requests. So simplify the function by splitting the UBLK_IO_NEED_GET_DATA case into its own function ublk_get_data(). This avoids several redundant checks in the UBLK_IO_NEED_GET_DATA case, and streamlines the incoming request cases. Don't call ublk_fill_io_cmd() for UBLK_IO_NEED_GET_DATA, as it's no longer necessary to set io->cmd or the UBLK_IO_FLAG_ACTIVE flag for ublk_dispatch_req(). Since UBLK_IO_NEED_GET_DATA no longer relies on ublk_dispatch_req() calling io_uring_cmd_done(), return the UBLK_IO_RES_OK status directly from the ->uring_cmd() handler. If ublk_start_io() fails, don't complete the UBLK_IO_NEED_GET_DATA command, matching the existing behavior. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250430225234.2676781-8-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02ublk: factor out ublk_start_io() helperCaleb Sander Mateos
In preparation for calling it from outside ublk_dispatch_req(), factor out the code responsible for setting up an incoming ublk I/O request. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250430225234.2676781-7-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02ublk: don't log uring_cmd cmd_op in ublk_dispatch_req()Caleb Sander Mateos
cmd_op is either UBLK_U_IO_FETCH_REQ, UBLK_U_IO_COMMIT_AND_FETCH_REQ, or UBLK_U_IO_NEED_GET_DATA. Which one isn't particularly interesting and is already recorded by the log line in __ublk_ch_uring_cmd(). Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250430225234.2676781-6-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02ublk: take const ubq pointer in ublk_get_iod()Caleb Sander Mateos
ublk_get_iod() doesn't modify the struct ublk_queue it is passed. Clarify that by making the argument a const pointer. Move the function definition earlier in the file so it doesn't need a forward declaration. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250430225234.2676781-5-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02ublk: remove misleading "ubq" in "ubq_complete_io_cmd()"Caleb Sander Mateos
ubq_complete_io_cmd() doesn't interact with a ublk queue, so "ubq" in the name is confusing. Most likely "ubq" was meant to be "ublk". Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250430225234.2676781-4-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02ublk: fix "immepdately" typo in commentCaleb Sander Mateos
Looks like "immediately" was intended. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250430225234.2676781-3-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02ublk: factor out ublk_commit_and_fetchUday Shankar
Move the logic for the UBLK_IO_COMMIT_AND_FETCH_REQ opcode into its own function. This also allows us to mark ublk_queue pointers as const for that operation, which can help prevent data races since we may allow concurrent operation on one ublk_queue in the future. Also open code ublk_commit_completion in ublk_commit_and_fetch to reduce the number of parameters/avoid a redundant lookup. [Restore __ublk_ch_uring_cmd() req variable used in commit d6aa0c178bf8 ("ublk: call ublk_dispatch_req() for handling UBLK_U_IO_NEED_GET_DATA")] Suggested-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Uday Shankar <ushankar@purestorage.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Link: https://lore.kernel.org/r/20250430225234.2676781-2-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-05-02i2c: atr: Fix end of loop test in i2c_atr_find_mapping_by_addr()Dan Carpenter
When the list_for_each_entry_reverse() exits without hitting a break then the list cursor points to invalid memory. So this check for if (c2a->fixed) is checking bogus memory. Fix it by using a "found" variable to track if we found what we were looking for or not. The list head (i2c_atr_chan.alias_pairs) is not a full entry, it's just a struct list_head. When the for loop runs to completion, c2a doesn't point to a struct i2c_atr_alias_pair, so you can't access c2a->fixed. Fixes: c3f55241882b ("i2c: Support dynamic address translation") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Romain Gantois <romain.gantois@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-05-02counter: interrupt-cnt: Convert atomic_t -> atomic_long_tAlexander Sverdlin
Convert the internal counter type to atomic_long_t, which: - doesn't change much for existing in-tree users as they are 32-bit anyway (stm32/i.MX6) - doesn't introduce performace penalty on 32-bit platforms - provides 64-bit resolution on 64-bit platforms with virtually no preformance penalty Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20250331152222.2263776-1-alexander.sverdlin@siemens.com Signed-off-by: William Breathitt Gray <wbg@kernel.org>
2025-05-02drm: Fix potential overflow issue in event_string arrayFeng Jiang
When calling scnprintf() to append recovery method to event_string, the second argument should be `sizeof(event_string) - len`, otherwise there is a potential overflow problem. Fixes: b7cf9f4ac1b8 ("drm: Introduce device wedged event") Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn> Reviewed-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250409014633.31303-1-jiangfeng@kylinos.cn Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-02Drivers: hv: Make the sysfs node size for the ring buffer dynamicNaman Jain
The ring buffer size varies across VMBus channels. The size of sysfs node for the ring buffer is currently hardcoded to 4 MB. Userspace clients either use fstat() or hardcode this size for doing mmap(). To address this, make the sysfs node size dynamic to reflect the actual ring buffer size for each channel. This will ensure that fstat() on ring sysfs node always returns the correct size of ring buffer. Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Link: https://lore.kernel.org/r/20250502074811.2022-3-namjain@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-02uio_hv_generic: Fix sysfs creation path for ring bufferNaman Jain
On regular bootup, devices get registered to VMBus first, so when uio_hv_generic driver for a particular device type is probed, the device is already initialized and added, so sysfs creation in hv_uio_probe() works fine. However, when the device is removed and brought back, the channel gets rescinded and the device again gets registered to VMBus. However this time, the uio_hv_generic driver is already registered to probe for that device and in this case sysfs creation is tried before the device's kobject gets initialized completely. Fix this by moving the core logic of sysfs creation of ring buffer, from uio_hv_generic to HyperV's VMBus driver, where the rest of the sysfs attributes for the channels are defined. While doing that, make use of attribute groups and macros, instead of creating sysfs directly, to ensure better error handling and code flow. Problematic path: vmbus_process_offer (A new offer comes for the VMBus device) vmbus_add_channel_work vmbus_device_register |-> device_register | |... | |-> hv_uio_probe | |... | |-> sysfs_create_bin_file (leads to a warning as | the primary channel's kobject, which is used to | create the sysfs file, is not yet initialized) |-> kset_create_and_add |-> vmbus_add_channel_kobj (initialization of the primary channel's kobject happens later) Above code flow is sequential and the warning is always reproducible in this path. Fixes: 9ab877a6ccf8 ("uio_hv_generic: make ring buffer attribute for primary channel") Cc: stable@kernel.org Suggested-by: Saurabh Sengar <ssengar@linux.microsoft.com> Suggested-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Link: https://lore.kernel.org/r/20250502074811.2022-2-namjain@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-02drm/panic: Use a decimal fifo to avoid u64 by u64 divideJocelyn Falempe
On 32bits ARM, u64/u64 is not supported [1], so change the algorithm to use a simple fifo with decimal digits as u8 instead. This is slower but should compile on all architecture. Link: https://lore.kernel.org/dri-devel/CANiq72ke45eOwckMhWHvmwxc03dxr4rnxxKvx+HvWdBLopZfrQ@mail.gmail.com/ [1] Reported-by: Miguel Ojeda <ojeda@kernel.org> Closes: https://lore.kernel.org/dri-devel/CANiq72ke45eOwckMhWHvmwxc03dxr4rnxxKvx+HvWdBLopZfrQ@mail.gmail.com/ Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7") Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250418165059.560503-1-jfalempe@redhat.com Acked-by: Javier Martinez Canillas <javierm@redhat.com>
2025-05-02pmdomain: core: Use genpd->opp_table to simplify error/remove pathUlf Hansson
While we add an OF-provider we may, based upon a specific condition, also assign genpd->opp_table. Rather using the same specific condition in the error/remove path, let's check genpd->opp_table instead as it makes the code easier. Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250417142513.312939-4-ulf.hansson@linaro.org
2025-05-02pmdomain: core: Simplify return statement in genpd_power_off()Ulf Hansson
Rather than using two if-clauses immediately after each to check for similar reasons to prevent the power-off, let's combine them into one if-clause to simplify the code. Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250417142513.312939-3-ulf.hansson@linaro.org
2025-05-02pmdomain: core: Convert genpd_power_off() to voidUlf Hansson
At some point it made sense to have genpd_power_off() to return an error code. That hasn't been the case for quite some time, so let's convert it into a static void function and simplify some of the corresponding code. Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250417142513.312939-2-ulf.hansson@linaro.org
2025-05-02drm/i915/hdcp: drop unnecessary include from intel_hdcp_gsc.hJani Nikula
Nothing in intel_hdcp_gsc.c needs linux/err.h. Remove it. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/26ae2c04554fc8dd76d2fdb0f2b0a63cb1fed98f.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: pass struct drm_device to driver specific HDCP GSC codeJani Nikula
The driver specific HDCP GSC code will eventually be part of the driver cores rather than display. Remove the struct intel_display references from them, and pass struct drm_device instead. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/bf9aa8e44e18eef41e3077a2966935b4e2649b62.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: simplify HDCP GSC firmware usage selectionJani Nikula
Just localize the GSC decision inside intel_hdcp.c, and deduplicate the conditions. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/a1d031bfbff7073e576dfe8d3d3d5a28d7bb2c15.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: switch the HDCP GSC message interface from u8* to void*Jani Nikula
The in/out buffers are just opaque data, and don't need to be considered u8*. Switching to void* lets us drop a ton of unnecessary casts. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/ea005adb713e85b797d83204c80de0a2a8e5ab47.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: pass the context to the HDCP GSC message interfaceJani Nikula
The opaque HDCP GSC context nicely abstracts the differences between drivers. Pass that instead of struct drm_i915_private or struct xe_device to intel_hdcp_gsc_msg_send(). We can store the driver specific data in the context. This lets us drop the dependency on i915_drv.h from intel_hdcp_gsc_message.c. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/df1653212f9014e717701b017e78e0017884b870.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: rename HDCP GSC context alloc/free functionsJani Nikula
Name the functions intel_hdcp_gsc_context_alloc() and intel_hdcp_gsc_context_free() for consistency. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/c6e25686ed20b5fdea9a59faf6a64a7312a075b0.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: rename struct intel_hdcp_gsc_message to intel_hdcp_gsc_contextJani Nikula
It's really about the context more than about the message. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/ca0a802a81ba4e96e7c40646a32386d4351d6ff4.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: split HDCP GSC message alloc/save responsibilitiesJani Nikula
Allocate and initialize the HDCP GSC message in intel_hdcp_gsc_hdcp2_init() as before, but store the pointer to display->hdcp.hdcp_message in the caller. Similarly, pass in the pointer to intel_hdcp_gsc_free_message(). Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/a74fcc941126bf92d12115b5faf4f75099e26242.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: deduplicate and refactor HDCP GSC ops initializationJani Nikula
The gsc_hdcp_ops is duplicated and initialized exactly the same way in two different places (for i915 and xe), and requires forward declarations for all the hooks. Deduplicate, and make the functions static. There are slight differences in the i915 and xe implementations of intel_hdcp_gsc_init() and intel_hdcp_gsc_fini(). Take the best of both, and improve. We need to expose intel_hdcp_gsc_hdcp2_init() and intel_hdcp_gsc_free_message() for this, and create the latter for xe. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/21e7871b35d4c7d13f016b5ecb4f10e5be72c531.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/hdcp: remove duplicate declarationsJani Nikula
intel_hdcp_gsc_msg_send() and intel_hdcp_gsc_check_status() are declared in intel_hdcp_gsc.h. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/f300d7cdb2af681291df938194f575f05c2c41bc.1745524803.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/display: Implement wa_14024400148Nemesa Garg
Workaround recommend use polling method for pm_demand to finish as to avoid timeout. v2: Add polling method within pmdemand_wait. Update error message[Jani] Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://lore.kernel.org/r/20250416152044.2668249-1-nemesa.garg@intel.com
2025-05-02drm/i915/error: drop dmesg suggestion to file bugs on GPU hangsJani Nikula
We haven't updated the DRIVER_TIMESTAMP since commit 3570bd989acc ("drm/i915: Update DRIVER_DATE to 20230929") 1½ years ago. Before then, the previous update was commit 139caf7ca286 ("drm/i915: Update DRIVER_DATE to 20201103") 4+ years ago. The DRIVER_DATE has also been removed altogether. We've used the DRIVER_TIMESTAMP to log suggestions to file bugs on GPU hangs when they happen on a driver less than six months old. Combined with the sporadic DRIVER_TIMESTAMP updates, we really haven't logged the suggestions for years. Just stop logging the suggestion to file bugs altogether, and remove DRIVER_TIMESTAMP. This doesn't really change anything wrt to logging GPU errors or how we handle bugs. And effectively we already stopped logging the message a year ago when we stopped updating DRIVER_TIMESTAMP. Instead, add an unconditional message about the GPU error state location. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250429115055.2133143-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm/i915/backlight: drop dmesg suggestion to file bugsJani Nikula
Drop the FDO_BUG_URL from the source, and stop suggesting to file bugs on DPCD backlight issues. We don't do this anywhere else in display, this isn't a special snowflake. As a consequence, also drop the dependency on i915_utils.h from intel_dp_aux_backlight.c. Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250429112534.2121656-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-02drm: Remove unused function rcar_cmm_writeJiapeng Chong
The function are defined in the rcar_cmm.c file, but not called elsewhere, so delete the unused function. drivers/gpu/drm/renesas/rcar-du/rcar_cmm.c:35:19: warning: unused function 'rcar_cmm_read'. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9364 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20240619075436.86407-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
2025-05-02drm: rcar-du: Fix memory leak in rcar_du_vsps_init()Biju Das
The rcar_du_vsps_init() doesn't free the np allocated by of_parse_phandle_with_fixed_args() for the non-error case. Fix memory leak for the non-error case. While at it, replace the label 'error'->'done' as it applies to non-error case as well and update the error check condition for rcar_du_vsp_init() to avoid breakage in future, if it returns positive value. Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same VSP") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20231116122424.80136-1-biju.das.jz@bp.renesas.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
2025-05-02x86/msr: Add explicit includes of <asm/msr.h>Xin Li (Intel)
For historic reasons there are some TSC-related functions in the <asm/msr.h> header, even though there's an <asm/tsc.h> header. To facilitate the relocation of rdtsc{,_ordered}() from <asm/msr.h> to <asm/tsc.h> and to eventually eliminate the inclusion of <asm/msr.h> in <asm/tsc.h>, add an explicit <asm/msr.h> dependency to the source files that reference definitions from <asm/msr.h>. [ mingo: Clarified the changelog. ] Signed-off-by: Xin Li (Intel) <xin@zytor.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Brian Gerst <brgerst@gmail.com> Cc: Juergen Gross <jgross@suse.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Uros Bizjak <ubizjak@gmail.com> Link: https://lore.kernel.org/r/20250501054241.1245648-1-xin@zytor.com
2025-05-02media: renesas: vsp1: Expose color space through the DRM APILaurent Pinchart
Now that the VSP1 driver supports color spaces, expose them through the API used by the DU driver. This allows configuring the YCbCr encoding and quantization used by each plane, ensuring correct color rendering. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-9-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Name nested structure in vsp1_drmLaurent Pinchart
The vsp1_drm structure defines an anonymous nested structure to store per-input data. In preparation for extending that structure, give it a name and is it through the driver. This improves code readability. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-8-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Allow setting encoding and quantizationLaurent Pinchart
The RPF and WPF support different encodings and quantizations when converting between RGB and YUV formats. Allow setting the corresponding format parameters from userspace, and configure the hardware accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-7-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Report colour space information to userspaceLaurent Pinchart
The vsp1 driver implements very partial colour space support: it hardcodes the colorspace field on all video devices and subdevices to V4L2_COLORSPACE_SRGB, regardless of the configured format. The xfer_func, ycbcr_enc and quantization fields are not set (except for hsv_enc for HSV formats on video devices). This doesn't match the hardware configuration, which handles YUV data as encoding in BT.601 with limited range. As a first step towards colour space configuration, keep the colour space fields hardcoded, but set them based on the selected format type (RGB, YUV or HSV). While at it, remove an extra blank line. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-6-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Fix media bus code setup on RWPF source padLaurent Pinchart
The RWPF source pad media bus code can only be different from the sink pad code when enabling color space conversion, which can only convert between RGB and YUV. If the sink pad code is HSV, no conversion is possible. Fix the pad set format handler to reflect this hardware limitation. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-5-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Fix HSV format enumerationLaurent Pinchart
The HSV formats are not restricted to Gen2 platforms, but to VSP instances that implement the HSI and HST modules. Make it conditional to the VSP1_HAS_HSIT feature flag. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-4-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Make HSI and HST modules optionalLaurent Pinchart
Not all VSP instance incorporate the HSI and HST modules. Add a VSP1_HAS_HSIT feature flag, and create the modules only on VSP instances that implement them. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-3-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Implement pixel format enumerationLaurent Pinchart
The VSP1 driver is missing the ability to enumerate pixel formats on its video nodes, which is supposed to be supported according to the V4L2 API. Implement the enumeration to fix this issue. As the device is media controller-centric, also implement the ability to filter pixel formats by media bus code, and report the missing V4L2_CAP_IO_MC capability. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-2-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Use %p4cc printk modifier to print FourCC codesBiju Das
Replace '%08x->%p4cc' printk modifier to print FourCC codes for pixel formats. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250330091738.27052-1-biju.das.jz@bp.renesas.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: rwpf: Support operations with IIFJacopo Mondi
When the RPF/WPF units are used for ISP interfacing through the IIF, the set of accessible registers is limited compared to the regular VSPD operations. Support ISP interfacing in the rpf and wpf entities by checking if the pipe features an IIF instance and writing only the relevant registers. Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250401-v4h-iif-v7-4-cc547c0bddd5@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: wpf: Propagate vsp1_rwpf_init_ctrls()Jacopo Mondi
vsp1_wpf.c calls vsp1_rwpf_init_ctrls() to initialize controls that are common between RPF and WPF. However, the vsp1_wpf.c implementation does not check for the function call return value. Fix this by propagating to the caller the return value. While at it, drop a duplicated error message in wpf_init_controls() as the caller already report it. Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20250401-v4h-iif-v7-3-cc547c0bddd5@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: dl: Use singleshot DL for VSPXJacopo Mondi
The vsp1_dl library allows to program a display list and feed it continuously to the VSP2. As an alternative operation mode, the library allows to program the VSP2 in 'single shot' mode, where a display list is submitted to the VSP on request only. Currently the 'single shot' mode is only available when the VSP2 is controlled by userspace, while it works in continuous mode when driven by DRM, as frames have to be submitted to the display continuously. For the VSPX use case, where there is no uapi support, we should however work in single-shot mode as the ISP driver programs the VSPX on request. Initialize the display lists in single shot mode in case the VSP1 is controlled by userspace or in case the pipeline features an IIF entity, as in the VSPX case. Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250401-v4h-iif-v7-2-cc547c0bddd5@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Add support IIF ISP InterfaceJacopo Mondi
The IIF (ISP InterFace) is a VSP2 function that transfers data to the ISP by reading from external memory through two RPF instances. Add support for it in the vsp1 driver by introducing a new entity type. The sole required operation is to enable the IIF function during configure_stream(). Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250401-v4h-iif-v7-1-cc547c0bddd5@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
generated by cgit v1.3 (git 2.53.0) at 2026-11-15 19:33:23 +0000