#
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 ...
|