We are meant to be checking the user vm for the bind queue, but actually
we are checking the migrate vm. For various reasons this is not
currently firing but this will likely change in the future.
Now that we have the user_vm attached to the bind queue, we can fix this
by directly checking that here.
Fixes: dba89840a9 ("drm/xe: Add GT TLB invalidation jobs")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Arvind Yadav <arvind.yadav@intel.com>
Link: https://patch.msgid.link/20260120110609.77958-4-matthew.auld@intel.com
(cherry picked from commit 9dd1048bca)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Currently this is very broken if someone attempts to create a bind
queue and share it across multiple VMs. For example currently we assume
it is safe to acquire the user VM lock to protect some of the bind queue
state, but if allow sharing the bind queue with multiple VMs then this
quickly breaks down.
To fix this reject using a bind queue with any VM that is not the same
VM that was originally passed when creating the bind queue. This a uAPI
change, however this was more of an oversight on kernel side that we
didn't reject this, and expectation is that userspace shouldn't be using
bind queues in this way, so in theory this change should go unnoticed.
Based on a patch from Matt Brost.
v2 (Matt B):
- Hold the vm lock over queue create, to ensure it can't be closed as
we attach the user_vm to the queue.
- Make sure we actually check for NULL user_vm in destruction path.
v3:
- Fix error path handling.
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: Carl Zhang <carl.zhang@intel.com>
Cc: <stable@vger.kernel.org> # v6.8+
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Arvind Yadav <arvind.yadav@intel.com>
Acked-by: Michal Mrozek <michal.mrozek@intel.com>
Link: https://patch.msgid.link/20260120110609.77958-3-matthew.auld@intel.com
(cherry picked from commit 9dd08fdecc)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Remove dw_pcie_ep_hide_ext_capability() and replace its usage with
dw_pcie_remove_ext_capability(). Both functions serve the same purpose
of hiding PCIe extended capabilities, but dw_pcie_remove_ext_capability()
provides a cleaner API that doesn't require the caller to specify the
previous capability ID.
Suggested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Tested-by: Niklas Cassel <cassel@kernel.org>
Link: https://patch.msgid.link/20251224-remove_dw_pcie_ep_hide_ext_capability-v1-1-4302c9cdc316@oss.qualcomm.com
Something now detected on fedora 44, where strchr() returns const if it
is passed a const pointer:
util/print-events.c: In function 'print_sdt_events':
util/print-events.c:89:29: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
89 | char *bid = strchr(sdt_name->s, '@');
| ^~~~~~
Fix it by using strchrnul() + strncmp() instead of temporarily scrubbing
it with '\0'.
Reviewed-by: Ian Rogers <irogers@google.com>
Suggested-by: David Laight <david.laight.linux@gmail.com>
Link: https://lore.kernel.org/r/20260121112536.27fd5d11@pumpkin
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In this case its a temp list that is created just for listing events and
will be deleted at the end, so just cast it to get rid of the compiler
warning.
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The VDPU383 decoder is used on the RK3576 SoC and has support for HEVC.
This patch also moves some functions to a common rkvdec-hevc-common.c
file and adds a specific scaling matrix flatten function.
The fluster score for JCT-VC-HEVC_V1 is 146/147.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The VDPU381 supports HEVC decoding up to 7680x4320@30fps.
It could double that when using both decoder cores.
It support YUV420 (8 and 10 bits) as well as AFBC (not implemented
here)
The fluster score is 146/147 for JCT-VC-HEVC_V1, tested on ROCK 5B.
None of the other test suites works.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
This variant is used on the RK3576 SoC.
The moving vectors size requirements are slightly different so support
for a colmv_size function per variant is added.
Also, the link registers are used to start the decoder and read IRQ status.
The fluster score is 128/135 for JVT-AVC_V1, with MPS_MW_A failing in
addition to the usual ones.
The other test suites are not supported yet.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
This decoder variant is found in Rockchip RK3588 SoC family.
Like for rkvdec on rk3399, it supports the NV12, NV15, NV16 and NV20
output formats and level up to 6.0.
The maximum width and height have been significantly increased
supporting up to 65520 pixels for both.
Support for named register sections is added for this variant and future
ones.
Fluster score for JVT-AVC_V1 is 129/135.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Similarly to what is done in Hantro, avoid exposing equal video codecs to
userspace. Equal video codecs allow scheduling work between the cores.
For that kernel support is required, which does not yet exist.
Until that is implemented, avoid exposing each core separately to
userspace so that multicore can be added in the future without breaking
userspace ABI.
This currently applies only to RK3588 which has 2 equal VDPU381 decoders,
but will be applied for all SoC supported by rkvdec that has multiple DTS
nodes with the same compatible.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
For other variants, the clock names and number will differ.
There is no need to keep track of the clock names in the driver so drop
them to avoid having a list for each variant.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Prepare for supporting different variants with different interrupt
managers.
To support other variants specific function type later, introduce the
rkvdec_variant_ops struct.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The RCB (Rows and Cols Buffers) are a set of buffers used by other
variations of the decoder to store temporary data.
Those variation come with a dedicated SRAM area used to store those
buffers for better performances.
The buffer sizes are either the width or height of the frame being
decoded multiplied by a documented factor and can be stored either
in SRAM or RAM.
A fallback to RAM is provided if the SRAM is full (e.g.: multiple
streams are being decoded at the same time).
To manage the different kind of allocation, an enum is added to the
rkvdec_aux_buf struct to specify how the buffer was allocated, and
so, how to free it.
This commit is in preparation of other variants support.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Prepare for adding new variants of the decoder and support specific
formats and format ops per variant.
This removes the need of capability flags for variants, so remove them.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
This is a preparation commit to add support for new variants of the
decoder.
The functions will later be shared with vdpu381 (rk3588) and vdpu383
(rk3576).
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
This is a preparation commit to add support for new variants of the
decoder.
The functions will later be shared with vdpu381 (rk3588) and vdpu383
(rk3576).
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
This is in preparation to add support for other variants of the decoder.
Moving to struct representation is mainly to prepare for multicore
support that is present in e.g. rk3588.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
This is in preparation to add support for new variants that will use the
same tables.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
In an effort to merge the rkvdec2 driver [1] with this one, switch from
writel() calls to using structs to represent the register mappings.
This is done in order to have all supported decoders use the same format
in the future and ease reading of the code.
Using structs also improves stability as the hardware is tested and
validated downstream using a similar method.
It was noticed, on decoders, that:
- Some registers require to be writen in increasing order [2]
- Some registers, even if unrelated, need to be written to their reset
values (it was the case here for axi_ddr_[rw]data).
Using structs can also help improving performance later when, e.g.
multicore support is added on RK3588.
Performance seems to be slightly improved, but at least, not made worse.
Running fluster's JVT-AVC_V1 test suite with GStreamer on the Radxa ROCK
PI 4 SE gives the following times:
Before this patch:
- --jobs 1: Ran 129/135 tests successfully in 77.167 secs
- --jobs 6: Ran 129/135 tests successfully in 23.046 secs
With this patch:
- --jobs 1: Ran 129/135 tests successfully in 70.698 secs
- --jobs 6: Ran 129/135 tests successfully in 22.917 secs
This also shows that the fluster score hasn't changed.
[1]: https://lore.kernel.org/all/20250325213303.826925-1-detlev.casanova@collabora.com/
[2]: https://lore.kernel.org/all/20200127143009.15677-5-andrzej.p@collabora.com/
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Log the recently added v4l2 controls to set HEVC short and long term RPS
sets with 2 new ftrace entries.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The vdpu381 decoder found on newer Rockchip SoC need the information
from the long term and short term ref pic sets from the SPS.
So far, it wasn't included in the v4l2 API, so add it with new dynamic
sized controls.
Each element of the hevc_ext_sps_lt_rps array contains the long term ref
pic set at that index.
Each element of the hevc_ext_sps_st_rps contains the short term ref pic
set at that index, as the raw data.
It is the role of the drivers to calculate the reference sets values.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Some hardware (e.g.: Rockchip's rk3588 hevc decoder) need to fully parse
the slice header, which cannot be passed with the current controls.
There is also no skip method similar as to what can be found in
verisilicon HW.
The SPS is therefore extended through these 2 new controls, providing the
long and short term reference information from the slice header for HEVC
decoding.
These now controls are similar as what is passed in the Vulkan Video API
with the StdVideoH265ShortTermRefPicSet and StdVideoH265LongTermRefPicsSps
structures embedded in the SPS struct.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Each tile info is composed of: row_sb, col_sb, start_pos
and end_pos (4 bytes each). So the total required memory
is AV1_MAX_TILES * 16 bytes.
Use the correct #define to allocate the buffer and avoid
writing tile info in non-allocated memory.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Fixes: 727a400686 ("media: verisilicon: Add Rockchip AV1 decoder")
Cc: stable@vger.kernel.org
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Add a new KUnit test for testing the creation of firmware name
qualifiers in the cs35l56 driver. The initial set of test cases
are for cs35l56_set_fw_suffix().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260121132243.1256019-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Kconfig symbol CONFIG_SND_SOC_CS_AMP_LIB_TEST_HOOKS to enable
calling into functions that would normally abort because of missing
EFI functionality. Before this the code paths were only enabled if
the KUnit test for cs-amp-lib was enabled.
This change allows KUnit tests for clients of cs-amp-lib to install
redirection hooks in cs-amp-lib.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260121132243.1256019-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Adds test cases for getting a Dell SSIDExV2 string by calling
cs_amp_devm_get_vendor_specific_variant_id().
This is a fairly simple test harness, the redirected call to
cs_amp_get_efi_variable() returns a test string to simulate
reading a string from UEFI. The returned string should be
the second field in the SSIDExV2 string (if valid).
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260121132243.1256019-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If cs_amp_devm_get_vendor_specific_variant_id() returns a string, use it
as part of the firmware filename. If this firmware isn't found, fall back
to the standard firmware name.
This re-uses the fwf_suffix fallback mechanism that was introduced in
commit e5d5b3aebd ("ASoC: cs35l56: Use SoundWire address as alternate
firmware suffix on L56 B0").
This is for handling vendors that use the same PCI SSID on systems with
various audio hardware and have a custom vendor-specific way to identify
the hardware variant.
This is currently used on Dell laptops. Dell create a UEFI variable that
indicates varations to the base hardware. This variance can be any part
of the hardware (not necessarily affecting the audio). It would be
impractical to publish many aliases for the same firmware files to match
every possible variance to that base hardware. Hence the fallback to the
standard firmware name. This allows alternate firmware files to be
published only for variants that need it. For all other variants the
fallback will load the firmware for the base SSID.
This is not done for CS35L56 B0 because the fallback mechanism is already
used for a different purpose for these parts. None of the products with
the older L56 B0 silicon revision need the additional vendor-specific
descriptor.
For SoundWire the resulting firmware searches with a variant descriptor
will be:
1. cs35l??-dsp1-misc-SSID-VARIANT-l?u?.wmfw
2. cs35l??-dsp1-misc-SSID-VARIANT.wmfw
3. cs35l??-dsp1-misc-SSID-VARIANT-l?u?.bin
4. cs35l??-dsp1-misc-SSID-VARIANT.bin
If this doesn't find a wmfw and bin file it will then fallback to:
5. cs35l??-dsp1-misc-SSID-l?u?.wmfw
6. cs35l??-dsp1-misc-SSID.wmfw
7. cs35l??-dsp1-misc-SSID-l?u?.bin
8. cs35l??-dsp1-misc-SSID.bin
With the typical published firmware names and qualifiers (a single wmfw but
amp-specific bin file) this will load either:
cs35l??-dsp1-misc-SSID-VARIANT.wmfw
and cs35l??-dsp1-misc-SSID-VARIANT-l?u?.bin
or
cs35l??-dsp1-misc-SSID.wmfw
and cs35l??-dsp1-misc-SSID-l?u?.bin
For non-Soundwire (I2S/TDM) systems the searches and fallbacks are
as above except that the "l?u?" component of the name is instead the
ALSA name prefix, usually of the form "AMPn".
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260121132243.1256019-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a function cs_amp_devm_get_vendor_specific_variant_id() to return
a vendor-specific hardware identifier string (if there is one) and use
it to fetch an identifier from Dell SSIDExV2 UEFI variable content.
Dell use the same PCI SSID on multiple products that might have different
audio hardware and thus need different firmware for the amplifier DSP.
The SSIDExV2 string contains additional system identifiers, and the
second field is a 2-character audio hardware identifier.
There are older Dell models with Cirrus Logic amplifiers that have the
SSIDExV2 UEFI variable but do not have the 2-character audio ID in the
second field. The SSIDExV2 is ignored if the second field is not
2 characters.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260121132243.1256019-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Per the binding, omitting the clock frequency from a Geni I2C controller
node defaults the bus to 100 kHz. But at least in Linux, a friendly info
print highlights the lack of explicitly defined frequency in the
DeviceTree.
Specify the frequency, to give it an explicit value, and to silence the
log print in Linux.
Downstream doesn't define any frequency, thus also using 100 kHz.
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://lore.kernel.org/r/20251130-enchilada-i2c-freq-v1-1-2932480a0261@ixit.cz
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
As per updated bindings, add the clocks for those two interconnects,
which are required to set up QoS correctly.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20251114-sm6350-icc-qos-v2-5-6af348cb9c69@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
When allocating a revocable provider via revocable_provider_alloc(),
there is no revocable consumers (i.e., RCU readers) yet. Remove the
redundant synchronize_srcu() call to save cycles.
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260121040204.2699886-1-tzungbi@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On Agatti platform the ADSP provides FastRPC support. Add corresponding
device node, in order to be able to utilize the DSP offload from the
Linux side.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260113-agatti-fastrpc-v2-1-b66870213f89@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Just toggling the descriptor's "requested" flag is not enough. We need
to properly request it in order to potentially propagate any
configuration to pinctrl via the .request() callback.
We must not take the reference to the device at this point (the device
is not ready but we're also requesting the device's own descriptor) so
make the _commit() variants of request and free functions available to
GPIO core in order to use them instead of their regular counterparts.
This fixes an audio issue reported on one of the Qualcomm platforms.
Fixes: a060b8c511 ("gpiolib: implement low-level, shared GPIO support")
Reviewed-by: Linus Walleij <linusw@kernel.org>
Tested-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260120154913.61991-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
of_drm_find_bridge() is deprecated. Move to its replacement
of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it
is put when done.
Since the companion bridge pointer is used by .atomic_enable, putting its
reference in the remove function would be dangerous. Use .destroy to put it
on final deallocation.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-3-v2-6-8d7a3dbacdf4@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
of_drm_find_bridge() is deprecated. Move to its replacement
of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it
is put when done.
dw_hdmi->bridge is used only in dw_hdmi_top_thread_irq(), so in order to
avoid potential use-after-free ensure the irq is freed before putting the
dw_hdmi->bridge reference.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-3-v2-2-8d7a3dbacdf4@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Since we can only inspect dmabuf by iterating over process FDs or the
dmabuf_list, we need to add our own tracepoints to track its status in
real time in production.
For example:
binder:3016_1-3102 [006] ...1. 255.126521: dma_buf_export: exp_name=qcom,system size=12685312 ino=2738
binder:3016_1-3102 [006] ...1. 255.126528: dma_buf_fd: exp_name=qcom,system size=12685312 ino=2738 fd=8
binder:3016_1-3102 [006] ...1. 255.126642: dma_buf_mmap_internal: exp_name=qcom,system size=28672 ino=2739
kworker/6:1-86 [006] ...1. 255.127194: dma_buf_put: exp_name=qcom,system size=12685312 ino=2738
RenderThread-9293 [006] ...1. 316.618179: dma_buf_get: exp_name=qcom,system size=12771328 ino=2762 fd=176
RenderThread-9293 [006] ...1. 316.618195: dma_buf_dynamic_attach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0
RenderThread-9293 [006] ...1. 318.878220: dma_buf_detach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0
Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260109115411.115270-1-gxxa03070307@gmail.com
As part of removal of EMLSR support from mvm, remove
link_id parameter from time_events. Additionally,
remove link_id parameter from iwl_mvm_protect_assoc
as we can now directly use deflink.
Signed-off-by: Nidhish A N <nidhish.a.n@intel.com>
Reviewed-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.9475bb832db6.I5829b0a2a9a5b56fe885eb0f1e1ad8cd70bc69ff@changeid
While the cluster_id is two bytes long, it is just the last two bytes of
the cluster ID MAC address. This does not really map to a big or little
endian data type. Switch it to use an array to avoid confusion and
adjust all users so that they do the right thing independent of
endianness.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.80921dc7d305.I56c2bbe0bfc6ee02782bc5d69fda2ac77f3502c4@changeid
This command is getting a new field for UNII-9 and ieee80211bn
enablement.
We must read the relevant DSM values and pass them to the firmware,
Remember whether we have ACPI or UEFI available in the firmware runtime
object and remember the DSM function revision.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.9577f0cade21.I82b26f082f152a83eb9990dddf68d7dcc549f227@changeid
Instead of reading the DSM functions on demand, just read them all
when the first DSM function is called and cache the values for all
the other DSM functions. This simplifies the flow.
Since the same will be done for UEFI in the next patch, remove the
ifdef CONFIG_ACPI around the relevant variables.
Once UEFI's cache will be implemented, we'll be able to change
iwl_bios_get_dsm to access the cache directly.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111193638.732ff6856796.Iff844bfbb0fea3c3d9654a53254a5b14dbaec8c1@changeid
