Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
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 ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35 |
|
#
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 ...
|
Revision tags: v6.1.34, v6.1.33, v6.1.32, v6.1.31 |
|
#
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 ...
|
Revision tags: v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22 |
|
#
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 ...
|
Revision tags: v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55 |
|
#
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 ...
|
Revision tags: v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48 |
|
#
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 ...
|
#
38a523a2 |
| 27-Jun-2022 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm"
This reverts commit 77515ebaf01920e2db49e04672ef669a7c2907f2 as it causes build problems in linux-next. I
Revert "devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm"
This reverts commit 77515ebaf01920e2db49e04672ef669a7c2907f2 as it causes build problems in linux-next. It needs to be reintroduced in a way that can allow the api to evolve and not require a "flag day" to catch all users.
Link: https://lore.kernel.org/r/20220623160723.7a44b573@canb.auug.org.au Cc: Duoming Zhou <duoming@zju.edu.cn> Cc: Brian Norris <briannorris@chromium.org> Cc: Johannes Berg <johannes@sipsolutions.net> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.47, v5.15.46 |
|
#
77515eba |
| 06-Jun-2022 |
Duoming Zhou <duoming@zju.edu.cn> |
devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm
The dev_coredumpv() and dev_coredumpm() could not be used in atomic context, because they call kvasprintf_const() a
devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm
The dev_coredumpv() and dev_coredumpm() could not be used in atomic context, because they call kvasprintf_const() and kstrdup() with GFP_KERNEL parameter. The process is shown below:
dev_coredumpv(.., gfp_t gfp) dev_coredumpm(.., gfp_t gfp) dev_set_name kobject_set_name_vargs kvasprintf_const(GFP_KERNEL, ...); //may sleep kstrdup(s, GFP_KERNEL); //may sleep
This patch removes gfp_t parameter of dev_coredumpv() and dev_coredumpm() and changes the gfp_t parameter of kzalloc() in dev_coredumpm() to GFP_KERNEL in order to show they could not be used in atomic context.
Fixes: 833c95456a70 ("device coredump: add new device coredump class") Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/df72af3b1862bac7d8e793d1f3931857d3779dfd.1654569290.git.duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61 |
|
#
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 ...
|
Revision tags: v5.10.60 |
|
#
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 ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12 |
|
#
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 ...
|
#
0bc65fcb |
| 19-Aug-2021 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
media: venus: core: Fix a resource leak in the error handling path of 'venus_probe()'
[ Upstream commit 8cc7a1b2aca067397a016cdb971a5e6ad9b640c7 ]
A successful 'of_platform_populate()' call should
media: venus: core: Fix a resource leak in the error handling path of 'venus_probe()'
[ Upstream commit 8cc7a1b2aca067397a016cdb971a5e6ad9b640c7 ]
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> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
4a8a8ff6 |
| 12-Aug-2021 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
media: venus: core: Fix a potential NULL pointer dereference in an error handling path
[ Upstream commit e4debea9be7d5db52bc6a565a4c02c3c6560d093 ]
The normal path of the function makes the assumpt
media: venus: core: Fix a potential NULL pointer dereference in an error handling path
[ Upstream commit e4debea9be7d5db52bc6a565a4c02c3c6560d093 ]
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> Signed-off-by: Sasha Levin <sashal@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 ...
|
Revision tags: v5.10.32, v5.10.31, v5.10.30 |
|
#
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 ...
|