History log of /openbmc/linux/drivers/media/platform/qcom/venus/core.c (Results 1 – 25 of 72)
Revision Date Author Comments
# b0686aed 18-Jun-2024 Zheng Wang <zyytlz.wz@163.com>

media: venus: fix use after free bug in venus_remove due to race condition

commit c5a85ed88e043474161bbfe54002c89c1cb50ee2 upstream.

in venus_probe, core->work is bound with venus_sys_error_handler

media: venus: fix use after free bug in venus_remove due to race condition

commit c5a85ed88e043474161bbfe54002c89c1cb50ee2 upstream.

in venus_probe, core->work is bound with venus_sys_error_handler, which is
used to handle error. The code use core->sys_err_done to make sync work.
The core->work is started in venus_event_notify.

If we call venus_remove, there might be an unfished work. The possible
sequence is as follows:

CPU0 CPU1

|venus_sys_error_handler
venus_remove |
hfi_destroy |
venus_hfi_destroy |
kfree(hdev); |
|hfi_reinit
|venus_hfi_queues_reinit
|//use hdev

Fix it by canceling the work in venus_remove.

Cc: stable@vger.kernel.org
Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...


# 3c76db56 11-Jul-2023 Patrick Whewell <patrick.whewell@sightlineapplications.com>

media: venus: Fix firmware path for sm8250

The firmware path for the sm8250 resources is incorrect. This fixes the
path to address the firmware correctly.

Signed-off-by: Patrick Whewell <patrick.wh

media: venus: Fix firmware path for sm8250

The firmware path for the sm8250 resources is incorrect. This fixes the
path to address the firmware correctly.

Signed-off-by: Patrick Whewell <patrick.whewell@sightlineapplications.com>
Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


# dca24b63 15-Jun-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

media: venus: core: Set up secure memory ranges for SC7180

Not all SC7180 devices ship with ChromeOS firmware. WoA devices use
Android-like TZ, which uses PAS for image authentication. That requires

media: venus: core: Set up secure memory ranges for SC7180

Not all SC7180 devices ship with ChromeOS firmware. WoA devices use
Android-like TZ, which uses PAS for image authentication. That requires
the predefined virtual address ranges to be passed via scm calls.
Define them to enable Venus on non-CrOS SC7180 devices.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


# 6513d80e 30-May-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

media: venus: core: Assign registers based on VPU version

The current assumption of IS_V6 is overgeneralized. Adjust the logic
to take the VPU hardware version into account.

Signed-off-by: Konrad D

media: venus: core: Assign registers based on VPU version

The current assumption of IS_V6 is overgeneralized. Adjust the logic
to take the VPU hardware version into account.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


# 9ac60db2 30-May-2023 Konrad Dybcio <konrad.dybcio@linaro.org>

media: venus: Add vpu_version to most SoCs

Add vpu_version where I was able to retrieve the information to
allow for more precise hardware-specific code path matching.

Reviewed-by: Dikshita Agarwal

media: venus: Add vpu_version to most SoCs

Add vpu_version where I was able to retrieve the information to
allow for more precise hardware-specific code path matching.

Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


# 7c7e33b7 14-Jul-2023 Rob Herring <robh@kernel.org>

media: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that m

media: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


# 9283f534 26-Mar-2023 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

media: venus: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error

media: venus: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


# d8025081 26-Mar-2023 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

media: venus: Warn only once about problems in .remove()

The only effect of returning an error code in a remove callback is that
the driver core emits a warning. The device is unbound anyhow.

As th

media: venus: Warn only once about problems in .remove()

The only effect of returning an error code in a remove callback is that
the driver core emits a warning. The device is unbound anyhow.

As the remove callback already emits a (quite verbose) warning when ret
is non-zero, return zero to suppress the additional warning.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


# b228cf38 13-Jul-2022 Vikash Garodia <quic_vgarodia@quicinc.com>

media: venus: set ubwc configuration on specific video hardware

UBWC configuration parameters would vary across video hardware
generations. At the same time, driver is expected to configure these
pa

media: venus: set ubwc configuration on specific video hardware

UBWC configuration parameters would vary across video hardware
generations. At the same time, driver is expected to configure these
parameters, without relying on video firmware to use the default
configurations.
Setting the configuration parameters for sc7280.

Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


# 748b080f 16-Jun-2022 Dikshita Agarwal <quic_dikshita@quicinc.com>

media: venus: Add support for SSR trigger using fault injection

Here we introduce a new fault injection for SSR trigger.

To trigger the SSR:
echo 100 > /sys/kernel/debug/venus/fail_ssr/probabilit

media: venus: Add support for SSR trigger using fault injection

Here we introduce a new fault injection for SSR trigger.

To trigger the SSR:
echo 100 > /sys/kernel/debug/venus/fail_ssr/probability
echo 1 > /sys/kernel/debug/venus/fail_ssr/times

Co-developed-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


# 8cc7a1b2 19-Aug-2021 Christophe JAILLET <christophe.jaillet@wanadoo.fr>

media: venus: core: Fix a resource leak in the error handling path of 'venus_probe()'

A successful 'of_platform_populate()' call should be balanced by a
corresponding 'of_platform_depopulate()' call

media: venus: core: Fix a resource leak in the error handling path of 'venus_probe()'

A successful 'of_platform_populate()' call should be balanced by a
corresponding 'of_platform_depopulate()' call in the error handling path
of the probe, as already done in the remove function.

A successful 'venus_firmware_init()' call should be balanced by a
corresponding 'venus_firmware_deinit()' call in the error handling path
of the probe, as already done in the remove function.

Update the error handling path accordingly.

Fixes: f9799fcce4bb ("media: venus: firmware: register separate platform_device for firmware loader")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# e4debea9 12-Aug-2021 Christophe JAILLET <christophe.jaillet@wanadoo.fr>

media: venus: core: Fix a potential NULL pointer dereference in an error handling path

The normal path of the function makes the assumption that
'pm_ops->core_power' may be NULL.
We should make the

media: venus: core: Fix a potential NULL pointer dereference in an error handling path

The normal path of the function makes the assumption that
'pm_ops->core_power' may be NULL.
We should make the same assumption in the error handling path or a NULL
pointer dereference may occur.

Add the missing test before calling 'pm_ops->core_power'

Fixes: 9e8efdb57879 ("media: venus: core: vote for video-mem path")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# 57c3b9f5 08-Oct-2021 AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

media: venus: core: Add sdm660 DT compatible and resource struct

Add the SDM660 DT compatible and its resource structure in order
to support the Venus IP in SDM630, SDM636, SDM660 and SDA variants.

media: venus: core: Add sdm660 DT compatible and resource struct

Add the SDM660 DT compatible and its resource structure in order
to support the Venus IP in SDM630, SDM636, SDM660 and SDA variants.

This SoC features Venus 4.4 (HFI3XX) with only one subcore, used
for both encoding and decoding, and switched on with one main and
one subcore dedicated GDSC.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# 3227a8f7 23-Apr-2021 Stanimir Varbanov <stanimir.varbanov@linaro.org>

media: venus: Handle fatal errors during encoding and decoding

According to stateful decoder docs a fatal failure of decoding
(and encoding) could be recover it by closing the corresponding
file han

media: venus: Handle fatal errors during encoding and decoding

According to stateful decoder docs a fatal failure of decoding
(and encoding) could be recover it by closing the corresponding
file handle and open new one or reinitialize decoding (and encoding)
by stop streaming on both queues. In order to satisfy this
requirement we add a mechanism ins sys_error_handler and
corresponding decoder and encoder drivers to wait for sys_error_done
waitqueue in reqbuf.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Tested-by: Vikash Garodia <vgarodia@codeaurora.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# b46ff4eb 23-Apr-2021 Stanimir Varbanov <stanimir.varbanov@linaro.org>

media: venus: Make sys_error flag an atomic bitops

Make the sys_error flag an atomic bitops in order to avoid
locking in sys_error readers.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linar

media: venus: Make sys_error flag an atomic bitops

Make the sys_error flag an atomic bitops in order to avoid
locking in sys_error readers.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Tested-by: Vikash Garodia <vgarodia@codeaurora.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# 920173c7 10-Aug-2021 Dikshita Agarwal <dikshita@codeaurora.org>

media: venus: Add num_vpp_pipes to resource structure

V6 HW can have vpp pipes as 1 or 4, add num_vpp_pipes
to resource struture to differentiate.

Signed-off-by: Dikshita Agarwal <dikshita@codeauro

media: venus: Add num_vpp_pipes to resource structure

V6 HW can have vpp pipes as 1 or 4, add num_vpp_pipes
to resource struture to differentiate.

Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# 275ad3b3 10-Aug-2021 Dikshita Agarwal <dikshita@codeaurora.org>

media: venus: core: Add sc7280 DT compatible and resource data

Adds a sm7280 compatible binding to the venus core.

Co-developed-by: Mansur Alisha Shaik <mansur@codeaurora.org>
Signed-off-by: Mansur

media: venus: core: Add sc7280 DT compatible and resource data

Adds a sm7280 compatible binding to the venus core.

Co-developed-by: Mansur Alisha Shaik <mansur@codeaurora.org>
Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# b4dac22d 01-Sep-2021 Cai Huoqing <caihuoqing@baidu.com>

media: venus: core : Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_reso

media: venus: core : Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately

Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# 4cba5473 27-Apr-2021 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: Rework error fail recover logic

The Venus code has a sort of watchdog that attempts to recover
from IP errors, implemented as a delayed work job, which
calls venus_sys_error_handler().

media: venus: Rework error fail recover logic

The Venus code has a sort of watchdog that attempts to recover
from IP errors, implemented as a delayed work job, which
calls venus_sys_error_handler().

Right now, it has several issues:

1. It assumes that PM runtime resume never fails

2. It internally runs two while() loops that also assume that
PM runtime will never fail to go idle:

while (pm_runtime_active(core->dev_dec) || pm_runtime_active(core->dev_enc))
msleep(10);

...

while (core->pmdomains[0] && pm_runtime_active(core->pmdomains[0]))
usleep_range(1000, 1500);

3. It uses an OR to merge all return codes and then report to the user

4. If the hardware never recovers, it keeps running on every 10ms,
flooding the syslog with 2 messages (so, up to 200 messages
per second).

Rework the code, in order to prevent that, by:

1. check the return code from PM runtime resume;
2. don't let the while() loops run forever;
3. store the failed event;
4. use warn ratelimited when it fails to recover.

Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# fb2b008b 08-Apr-2021 Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

media: venus: core: correct firmware name for sm8250

Firmware name for venus should be qcom/vpu-1.0/venus.mdt, not
qcom/sm8250/venus.mdt.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.or

media: venus: core: correct firmware name for sm8250

Firmware name for venus should be qcom/vpu-1.0/venus.mdt, not
qcom/sm8250/venus.mdt.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# b6f13994 08-Apr-2021 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: use NULL instead of zero for pointers

As reported by sparse:

drivers/media/platform/qcom/venus/core.c:227:41: warning: Using plain integer as NULL pointer
drivers/media/platform/qco

media: venus: use NULL instead of zero for pointers

As reported by sparse:

drivers/media/platform/qcom/venus/core.c:227:41: warning: Using plain integer as NULL pointer
drivers/media/platform/qcom/venus/core.c:228:34: warning: Using plain integer as NULL pointer

Two vars are using zero instead of NULL for pointers. Not really
an issue, but using NULL makes it clearer that the init data is
expecting a pointer.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# 3f9acde8 02-Apr-2021 Bryan O'Donoghue <bryan.odonoghue@linaro.org>

media: venus: core: Hook to V6 base registers when appropriate

This commit points the IO base registers 6xx offsets when probing for 6xx
hardware.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@l

media: venus: core: Hook to V6 base registers when appropriate

This commit points the IO base registers 6xx offsets when probing for 6xx
hardware.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# e6dd8c3a 02-Apr-2021 Bryan O'Donoghue <bryan.odonoghue@linaro.org>

media: venus: core: Add an io base for AON regs

6xx silicon needs to access registers from a AON base address range.
This commit defines the necessary variable for later use.

Signed-off-by: Bryan O

media: venus: core: Add an io base for AON regs

6xx silicon needs to access registers from a AON base address range.
This commit defines the necessary variable for later use.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# 94e6ed2b 02-Apr-2021 Bryan O'Donoghue <bryan.odonoghue@linaro.org>

media: venus: core: Add an io base for TZ wrapper regs

6xx silicon needs to access registers from a wrapper trust-zone base
address range.
This commit defines the necessary variable for later use.

media: venus: core: Add an io base for TZ wrapper regs

6xx silicon needs to access registers from a wrapper trust-zone base
address range.
This commit defines the necessary variable for later use.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


# b4053a20 02-Apr-2021 Bryan O'Donoghue <bryan.odonoghue@linaro.org>

media: venus: core: Add io base variables for each block

New silicon means that the pre-determined offsets we have been using
in this driver no longer hold. Existing blocks of registers can exist at

media: venus: core: Add io base variables for each block

New silicon means that the pre-determined offsets we have been using
in this driver no longer hold. Existing blocks of registers can exist at
different offsets relative to the IO base address.

This commit adds a routine to assign the IO base hooks a subsequent commit
will convert from absolute to relative addressing.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

show more ...


123