| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
commit ddbcd0c58a6a53e2f1600b9de0ce6a20667c031c upstream.
Wrong solution of rebase conflict leads to calling twice
v4l2_device_unregister in .venus_remove. Delete the second one.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Martin Faltesek <mfaltesek@google.com>
Cc: Guenter Roeck <groeck@google.com>
Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 549cc89cd09a85aaa16dc07ef3db811d5cf9bcb1 upstream.
PHTW register is selected based on default bit rate from Table[1].
for the bit rates less than or equal to 250. Currently first
value of default bit rate which is greater than or equal to
the caculated mbps is selected. This selection can be further
improved by selecting the default bit rate which is nearest to
the calculated value.
[1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.12]
Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver")
Signed-off-by: Suresh Udipi <sudipi@jp.adit-jv.com>
Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit da6911f330d40cfe115a37249e47643eff555e82 ]
This change fixes two issues with the size constraints for buffers.
- There is no width alignment constraint for RGB formats. Prior to this
change they were treated as YUV and as a result were more restricted
than needed. Add a new check to differentiate between the two.
- The minimum width and height supported is 5x2, not 2x4, this is an
artifact from the driver's soc-camera days. Fix this incorrect
assumption.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
concurrent video sessions
[ Upstream commit 91f2b7d269e5c885c38c7ffa261f5276bd42f907 ]
In existing implementation, core_clk_setrate() is getting called
concurrently in concurrent video sessions. Before the previous call to
core_clk_setrate returns, new call to core_clk_setrate is invoked from
another video session running concurrently. This results in latest
calculated frequency being set (higher/lower) instead of actual frequency
required for that video session. It also results in stability crashes
mention below. These resources are specific to video core, hence keeping
under core lock would ensure that they are estimated for all running video
sessions and called once for the video core.
Crash logs:
[ 1.900089] WARNING: CPU: 4 PID: 1 at drivers/opp/debugfs.c:33 opp_debug_remove_one+0x2c/0x48
[ 1.908493] Modules linked in:
[ 1.911524] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.67 #35 f8edb8c30cf2dd6838495dd9ef9be47af7f5f60c
[ 1.921036] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT)
[ 1.928673] pstate: 60800009 (nZCv daif -PAN +UAO -TCO BTYPE=--)
[ 1.934608] pc : opp_debug_remove_one+0x2c/0x48
[ 1.939080] lr : opp_debug_remove_one+0x2c/0x48
[ 1.943560] sp : ffffffc011d7b7f0
[ 1.946836] pmr_save: 000000e0
[ 1.949854] x29: ffffffc011d7b7f0 x28: ffffffc010733bbc
[ 1.955104] x27: ffffffc010733ba8 x26: ffffff8083cedd00
[ 1.960355] x25: 0000000000000001 x24: 0000000000000000
[ 1.965603] x23: ffffff8083cc2878 x22: ffffff8083ceb900
[ 1.970852] x21: ffffff8083ceb910 x20: ffffff8083cc2800
[ 1.976101] x19: ffffff8083ceb900 x18: 00000000ffff0a10
[ 1.981352] x17: ffffff80837a5620 x16: 00000000000000ec
[ 1.986601] x15: ffffffc010519ad4 x14: 0000000000000003
[ 1.991849] x13: 0000000000000004 x12: 0000000000000001
[ 1.997100] x11: c0000000ffffdfff x10: 00000000ffffffff
[ 2.002348] x9 : d2627c580300dc00 x8 : d2627c580300dc00
[ 2.007596] x7 : 0720072007200720 x6 : ffffff80802ecf00
[ 2.012845] x5 : 0000000000190004 x4 : 0000000000000000
[ 2.018094] x3 : ffffffc011d7b478 x2 : ffffffc011d7b480
[ 2.023343] x1 : 00000000ffffdfff x0 : 0000000000000017
[ 2.028594] Call trace:
[ 2.031022] opp_debug_remove_one+0x2c/0x48
[ 2.035160] dev_pm_opp_put+0x94/0xb0
[ 2.038780] _opp_remove_all+0x7c/0xc8
[ 2.042486] _opp_remove_all_static+0x54/0x7c
[ 2.046796] dev_pm_opp_remove_table+0x74/0x98
[ 2.051183] devm_pm_opp_of_table_release+0x18/0x24
[ 2.056001] devm_action_release+0x1c/0x28
[ 2.060053] release_nodes+0x23c/0x2b8
[ 2.063760] devres_release_group+0xcc/0xd0
[ 2.067900] component_bind+0xac/0x168
[ 2.071608] component_bind_all+0x98/0x124
[ 2.075664] msm_drm_bind+0x1e8/0x678
[ 2.079287] try_to_bring_up_master+0x60/0x134
[ 2.083674] component_master_add_with_match+0xd8/0x120
[ 2.088834] msm_pdev_probe+0x20c/0x2a0
[ 2.092629] platform_drv_probe+0x9c/0xbc
[ 2.096598] really_probe+0x11c/0x46c
[ 2.100217] driver_probe_device+0x8c/0xf0
[ 2.104270] device_driver_attach+0x54/0x78
[ 2.108407] __driver_attach+0x48/0x148
[ 2.112201] bus_for_each_dev+0x88/0xd4
[ 2.115998] driver_attach+0x2c/0x38
[ 2.119534] bus_add_driver+0x10c/0x200
[ 2.123330] driver_register+0x6c/0x104
[ 2.127122] __platform_driver_register+0x4c/0x58
[ 2.131767] msm_drm_register+0x6c/0x70
[ 2.135560] do_one_initcall+0x64/0x23c
[ 2.139357] do_initcall_level+0xac/0x15c
[ 2.143321] do_initcalls+0x5c/0x9c
[ 2.146778] do_basic_setup+0x2c/0x38
[ 2.150401] kernel_init_freeable+0xf8/0x15c
[ 2.154622] kernel_init+0x1c/0x11c
[ 2.158079] ret_from_fork+0x10/0x30
[ 2.161615] ---[ end trace a2cc45a0f784b212 ]---
[ 2.166272] Removing OPP: 300000000
Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
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>
|
|
[ Upstream commit 43f0633f89947df57fe0b5025bdd741768007708 ]
The return value of dma_set_coherent_mask() is not always 0.
To catch the exception in case that dma is not support the mask.
Link: https://lore.kernel.org/linux-media/20211206022201.1639460-1-jiasheng@iscas.ac.cn
Fixes: b0444f18e0b1 ("[media] coda: add i.MX6 VDOA driver")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
'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>
|
|
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>
|
|
[ Upstream commit 08b1cf474b7f72750adebe0f0a35f8e9a3eb75f6 ]
Commit aaaa93eda64b ("media] media: venus: venc: add video encoder files")
is the last in a series of three commits to add core.c vdec.c and venc.c
adding core, encoder and decoder.
The encoder and decoder check for core drvdata as set and return -EPROBE_DEFER
if it has not been set, however both the encoder and decoder rely on
core.v4l2_dev as valid.
core.v4l2_dev will not be valid until v4l2_device_register() has completed
in core.c's probe().
Normally this is never seen however, Dmitry reported the following
backtrace when compiling drivers and firmware directly into a kernel image.
[ 5.259968] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 5.269850] sd 0:0:0:3: [sdd] Optimal transfer size 524288 bytes
[ 5.275505] Workqueue: events deferred_probe_work_func
[ 5.275513] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 5.441211] usb 2-1: new SuperSpeedPlus Gen 2 USB device number 2 using xhci-hcd
[ 5.442486] pc : refcount_warn_saturate+0x140/0x148
[ 5.493756] hub 2-1:1.0: USB hub found
[ 5.496266] lr : refcount_warn_saturate+0x140/0x148
[ 5.500982] hub 2-1:1.0: 4 ports detected
[ 5.503440] sp : ffff80001067b730
[ 5.503442] x29: ffff80001067b730
[ 5.592660] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 5.598478] x28: ffff6c6bc1c379b8
[ 5.598480] x27: ffffa5c673852960 x26: ffffa5c673852000
[ 5.598484] x25: ffff6c6bc1c37800 x24: 0000000000000001
[ 5.810652] x23: 0000000000000000 x22: ffffa5c673bc7118
[ 5.813777] hub 1-1:1.0: USB hub found
[ 5.816108] x21: ffffa5c674440000 x20: 0000000000000001
[ 5.820846] hub 1-1:1.0: 4 ports detected
[ 5.825415] x19: ffffa5c6744f4000 x18: ffffffffffffffff
[ 5.825418] x17: 0000000000000000 x16: 0000000000000000
[ 5.825421] x15: 00000a4810c193ba x14: 0000000000000000
[ 5.825424] x13: 00000000000002b8 x12: 000000000000f20a
[ 5.825427] x11: 000000000000f20a x10: 0000000000000038
[ 5.845447] usb 2-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 5.845904]
[ 5.845905] x9 : 0000000000000000 x8 : ffff6c6d36fae780
[ 5.871208] x7 : ffff6c6d36faf240 x6 : 0000000000000000
[ 5.876664] x5 : 0000000000000004 x4 : 0000000000000085
[ 5.882121] x3 : 0000000000000119 x2 : ffffa5c6741ef478
[ 5.887578] x1 : 3acbb3926faf5f00 x0 : 0000000000000000
[ 5.893036] Call trace:
[ 5.895551] refcount_warn_saturate+0x140/0x148
[ 5.900202] __video_register_device+0x64c/0xd10
[ 5.904944] venc_probe+0xc4/0x148
[ 5.908444] platform_probe+0x68/0xe0
[ 5.912210] really_probe+0x118/0x3e0
[ 5.915977] driver_probe_device+0x5c/0xc0
[ 5.920187] __device_attach_driver+0x98/0xb8
[ 5.924661] bus_for_each_drv+0x68/0xd0
[ 5.928604] __device_attach+0xec/0x148
[ 5.932547] device_initial_probe+0x14/0x20
[ 5.936845] bus_probe_device+0x9c/0xa8
[ 5.940788] device_add+0x3e8/0x7c8
[ 5.944376] of_device_add+0x4c/0x60
[ 5.948056] of_platform_device_create_pdata+0xbc/0x140
[ 5.953425] of_platform_bus_create+0x17c/0x3c0
[ 5.958078] of_platform_populate+0x80/0x110
[ 5.962463] venus_probe+0x2ec/0x4d8
[ 5.966143] platform_probe+0x68/0xe0
[ 5.969907] really_probe+0x118/0x3e0
[ 5.973674] driver_probe_device+0x5c/0xc0
[ 5.977882] __device_attach_driver+0x98/0xb8
[ 5.982356] bus_for_each_drv+0x68/0xd0
[ 5.986298] __device_attach+0xec/0x148
[ 5.990242] device_initial_probe+0x14/0x20
[ 5.994539] bus_probe_device+0x9c/0xa8
[ 5.998481] deferred_probe_work_func+0x74/0xb0
[ 6.003132] process_one_work+0x1e8/0x360
[ 6.007254] worker_thread+0x208/0x478
[ 6.011106] kthread+0x150/0x158
[ 6.014431] ret_from_fork+0x10/0x30
[ 6.018111] ---[ end trace f074246b1ecdb466 ]---
This patch fixes by
- Only setting drvdata after v4l2_device_register() completes
- Moving v4l2_device_register() so that suspend/reume in core::probe()
stays as-is
- Changes pm_ops->core_function() to take struct venus_core not struct
device
- Minimal rework of v4l2_device_*register in probe/remove
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a76f43a490542ecb8c57176730b6eb665d716139 ]
Presently we use device_link to control core power domain. But this
leads to issues because the genpd doesn't guarantee synchronous on/off
for supplier devices. Switch to manually control by pmruntime calls.
Tested-by: Fritz Koenig <frkoenig@chromium.org>
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>
|
|
[ Upstream commit 1a59cd88f55068710f6549bee548846661673780 ]
Stop the CODA960 JPEG encoder from overflowing capture buffers.
The bitstream buffer overflow interrupt doesn't seem to be connected,
so this has to be handled via timeout instead.
Reported-by: Martin Weber <martin.weber@br-automation.com>
Fixes: 96f6f62c4656 ("media: coda: jpeg: add CODA960 JPEG encoder support")
Tested-by: Martin Weber <martin.weber@br-automation.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 9f89c881bffbdffe4060ffaef3489a2830a6dd9c ]
The func v4l2_m2m_ctx_release waits for currently running jobs
to finish and then stop streaming both queues and frees the buffers.
All this should be done before the call to mtk_vcodec_enc_release
which frees the encoder handler. This fixes null-pointer dereference bug:
[ 638.028076] Mem abort info:
[ 638.030932] ESR = 0x96000004
[ 638.033978] EC = 0x25: DABT (current EL), IL = 32 bits
[ 638.039293] SET = 0, FnV = 0
[ 638.042338] EA = 0, S1PTW = 0
[ 638.045474] FSC = 0x04: level 0 translation fault
[ 638.050349] Data abort info:
[ 638.053224] ISV = 0, ISS = 0x00000004
[ 638.057055] CM = 0, WnR = 0
[ 638.060018] user pgtable: 4k pages, 48-bit VAs, pgdp=000000012b6db000
[ 638.066485] [00000000000001a0] pgd=0000000000000000, p4d=0000000000000000
[ 638.073277] Internal error: Oops: 96000004 [#1] SMP
[ 638.078145] Modules linked in: rfkill mtk_vcodec_dec mtk_vcodec_enc uvcvideo mtk_mdp mtk_vcodec_common videobuf2_dma_contig v4l2_h264 cdc_ether v4l2_mem2mem videobuf2_vmalloc usbnet videobuf2_memops videobuf2_v4l2 r8152 videobuf2_common videodev cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf elan_i2c elants_i2c sbs_battery mc cros_usbpd_charger cros_ec_chardev cros_usbpd_logger crct10dif_ce mtk_vpu fuse ip_tables x_tables ipv6
[ 638.118583] CPU: 0 PID: 212 Comm: kworker/u8:5 Not tainted 5.15.0-06427-g58a1d4dcfc74-dirty #109
[ 638.127357] Hardware name: Google Elm (DT)
[ 638.131444] Workqueue: mtk-vcodec-enc mtk_venc_worker [mtk_vcodec_enc]
[ 638.137974] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 638.144925] pc : vp8_enc_encode+0x34/0x2b0 [mtk_vcodec_enc]
[ 638.150493] lr : venc_if_encode+0xac/0x1b0 [mtk_vcodec_enc]
[ 638.156060] sp : ffff8000124d3c40
[ 638.159364] x29: ffff8000124d3c40 x28: 0000000000000000 x27: 0000000000000000
[ 638.166493] x26: 0000000000000000 x25: ffff0000e7f252d0 x24: ffff8000124d3d58
[ 638.173621] x23: ffff8000124d3d58 x22: ffff8000124d3d60 x21: 0000000000000001
[ 638.180750] x20: ffff80001137e000 x19: 0000000000000000 x18: 0000000000000001
[ 638.187878] x17: 000000040044ffff x16: 00400032b5503510 x15: 0000000000000000
[ 638.195006] x14: ffff8000118536c0 x13: ffff8000ee1da000 x12: 0000000030d4d91d
[ 638.202134] x11: 0000000000000000 x10: 0000000000000980 x9 : ffff8000124d3b20
[ 638.209262] x8 : ffff0000c18d4ea0 x7 : ffff0000c18d44c0 x6 : ffff0000c18d44c0
[ 638.216391] x5 : ffff80000904a3b0 x4 : ffff8000124d3d58 x3 : ffff8000124d3d60
[ 638.223519] x2 : ffff8000124d3d78 x1 : 0000000000000001 x0 : ffff80001137efb8
[ 638.230648] Call trace:
[ 638.233084] vp8_enc_encode+0x34/0x2b0 [mtk_vcodec_enc]
[ 638.238304] venc_if_encode+0xac/0x1b0 [mtk_vcodec_enc]
[ 638.243525] mtk_venc_worker+0x110/0x250 [mtk_vcodec_enc]
[ 638.248918] process_one_work+0x1f8/0x498
[ 638.252923] worker_thread+0x140/0x538
[ 638.256664] kthread+0x148/0x158
[ 638.259884] ret_from_fork+0x10/0x20
[ 638.263455] Code: f90023f9 2a0103f5 aa0303f6 aa0403f8 (f940d277)
[ 638.269538] ---[ end trace e374fc10f8e181f5 ]---
[gst-master] root@debian:~/gst-build# [ 638.019193] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001a0
Fixes: 4e855a6efa547 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ed2f97ad4b21072f849cf4ae6645d1f2b1d3f550 ]
After devm_request_threaded_irq() is called there is a chance that an
interrupt may occur before the spinlock is initialized, which will trigger
a kernel oops.
To prevent that, move the initialization of the spinlock prior to
requesting the interrupts.
Fixes: 51abcf7fdb70 ("media: imx-pxp: add i.MX Pixel Pipeline driver")
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit cee44d4fbacbbdfe62697ec94e76c6e4f726c5df ]
hsfreqrange should be chosen based on the calculated mbps which
is closer to the default bit rate and within the range as per
table[1]. But current calculation always selects first value which
is greater than or equal to the calculated mbps which may lead
to chosing a wrong range in some cases.
For example for 360 mbps for H3/M3N
Existing logic selects
Calculated value 360Mbps : Default 400Mbps Range [368.125 -433.125 mbps]
This hsfreqrange is out of range.
The logic is changed to get the default value which is closest to the
calculated value [1]
Calculated value 360Mbps : Default 350Mbps Range [320.625 -380.625 mpbs]
[1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.9]
Please note that According to Renesas in Table 25.9 the range for
220 default value is corrected as below
|Range (Mbps) | Default Bit rate (Mbps) |
-----------------------------------------------
| 197.125-244.125 | 220 |
-----------------------------------------------
Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver")
Signed-off-by: Suresh Udipi <sudipi@jp.adit-jv.com>
Signed-off-by: Kazuyoshi Akiyama <akiyama@nds-osk.co.jp>
Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit af6d1bde395cac174ee71adcd3fa43f6435c7206 ]
If res-chg, VE_INTERRUPT_MODE_DETECT_WD irq will be raised. But
v4l2_input_status won't be updated to no-signal immediately until
aspeed_video_get_resolution() in aspeed_video_resolution_work().
During the period of time, aspeed_video_start_frame() could be called
because it doesn't know signal becomes unstable now. If it goes with
aspeed_video_init_regs() of aspeed_video_irq_res_change()
simultaneously, it will mess up hw state.
To fix this problem, v4l2_input_status is updated to no-signal
immediately for VE_INTERRUPT_MODE_DETECT_WD irq.
Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver")
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 62cea52ad4bead0ae4be2cfe1142eb0aae0e9fbd ]
aspeed_video_get_resolution() will try to do res-detect again if the
timing got in last try is invalid. But it will always time out because
VE_SEQ_CTRL_TRIG_MODE_DET is only cleared after 1st mode-detect.
To fix the problem, just clear VE_SEQ_CTRL_TRIG_MODE_DET before setting
it in aspeed_video_enable_mode_detect().
Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver")
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
'mtk_vpu_probe()'
[ Upstream commit 2143ad413c05c7be24c3a92760e367b7f6aaac92 ]
A successful 'clk_prepare()' call should be balanced by a corresponding
'clk_unprepare()' call in the error handling path of the probe, as already
done in the remove function.
Update the error handling path accordingly.
Fixes: 3003a180ef6b ("[media] VPU: mediatek: support Mediatek VPU")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Houlong Wei <houlong.wei@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit fc41665498332ad394b7db37f23e9394096ddc71 ]
If rcsi2_code_to_fmt() return NULL, then null pointer dereference occurs
in the next cycle. That should not be possible now but adding checking
protects from future bugs.
The patch adds checking if format is NULL.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit cdfaf4752e6915a4b455ad4400133e540e4dc965 ]
If of_device_get_match_data() return NULL,
then null pointer dereference occurs in s5p_mfc_init_pm().
The patch adds checking if dev->variant is NULL.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8515965e5e33f4feb56134348c95953f3eadfb26 ]
The variable pdev is assigned to dev->plat_dev, and dev->plat_dev is
checked in:
if (!dev->plat_dev)
This indicates both dev->plat_dev and pdev can be NULL. If so, the
function dev_err() is called to print error information.
dev_err(&pdev->dev, "No platform data specified\n");
However, &pdev->dev is an illegal address, and it is dereferenced in
dev_err().
To fix this possible null-pointer dereference, replace dev_err() with
mfc_err().
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: Tuo Li <islituo@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 548fa43a58696450c15b8f5564e99589c5144664 ]
At the moment of enabling irq handling:
1922 ret = devm_request_threaded_irq(&pdev->dev, irq, dcmi_irq_callback,
1923 dcmi_irq_thread, IRQF_ONESHOT,
1924 dev_name(&pdev->dev), dcmi);
there is still uninitialized field sd_format of struct stm32_dcmi *dcmi.
If an interrupt occurs in the interval between the installation of the
interrupt handler and the initialization of this field, NULL pointer
dereference happens.
This field is dereferenced in the handler function without any check:
457 if (dcmi->sd_format->fourcc == V4L2_PIX_FMT_JPEG &&
458 dcmi->misr & IT_FRAME) {
The patch moves interrupt handler installation
after initialization of the sd_format field that happens in
dcmi_graph_notify_complete() via dcmi_set_default_fmt().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Dmitriy Ulitin <ulitin@ispras.ru>
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 09ea9719a423fc675d40dd05407165e161ea0c48 ]
Currently the call to find_format can potentially return a NULL to
fmt and the nullpointer is later dereferenced on the assignment of
pixmp->num_planes = fmt->num_planes. Fix this by adding a NULL pointer
check and returning NULL for the failure case.
Addresses-Coverity: ("Dereference null return")
Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
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>
|
|
[ Upstream commit 44693d74f5653f82cd7ca0fe730eed0f6b83306a ]
The frame memory control register value is currently determined
before userspace selects the final capture format and never corrected.
Update ctx->frame_mem_ctrl in __coda_start_decoding() to fix decoding
into YUV420 or YVU420 capture buffers.
Reported-by: Andrej Picej <andrej.picej@norik.com>
Fixes: 497e6b8559a6 ("media: coda: add sequence initialization work")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e58430e1d4fd01b74475d2fbe2e25b5817b729a9 ]
There are a few bugs in this code. 1) No checks for whether
dma_alloc_attrs() or __get_free_pages() failed. 2) If
video_register_device() fails it doesn't clean up the dma attrs or the
free pages. 3) The video_device_release() function frees "vfd" which
leads to a use after free on the next line. The call to
video_unregister_device() is not required so I have just removed that.
Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support")
Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 0314339a0a49f4a128b61e5e1a0af1df6e64a186 ]
Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.
Use the new API, in order to cleanup the error check logic.
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 0a7790be182d32b9b332a37cb4206e24fe94b728 upstream.
The saa6588_ioctl() function expects to get called from other kernel
functions with a 'saa6588_command' pointer, but I found nothing stops it
from getting called from user space instead, which seems rather dangerous.
The same thing happens in the davinci vpbe driver with its VENC_GET_FLD
command.
As a quick fix, add a separate .command() callback pointer for this
driver and change the two callers over to that. This change can easily
get backported to stable kernels if necessary, but since there are only
two drivers, we may want to eventually replace this with a set of more
specialized callbacks in the long run.
Fixes: c3fda7f835b0 ("V4L/DVB (10537): saa6588: convert to v4l2_subdev.")
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 29dd19e3ac7b2a8671ebeac02859232ce0e34f58 upstream.
The usage of pm_runtime_resume_and_get() removed the need of a
temporary integer. So, drop it.
Fixes: 59f96244af94 ("media: exynos4-is: fix pm_runtime_get_sync() usage count")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 95778c2d0979618e3349b1d2324ec282a5a6adbf ]
i.MX6 device tree include files contain dangling endpoints for the
board device tree writers' convenience. These are still included in
many existing device trees.
Treat dangling endpoints as non-existent to support them.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 612b385efb1e ("media: video-mux: Create media links in bound notifier")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c1cf3d896d124e3e00794f9bfbde49f0fc279e3f ]
Change v4l2_async_notifier_add_fwnode_remote_subdev semantics
so it allocates the struct v4l2_async_subdev pointer.
This makes the API consistent: the v4l2-async subdevice addition
functions have now a unified usage model. This model is simpler,
as it makes v4l2-async responsible for the allocation and release
of the subdevice descriptor, and no longer something the driver
has to worry about.
On the user side, the change makes the API simpler for the drivers
to use and less error-prone.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5d11e6aad1811ea293ee2996cec9124f7fccb661 ]
The m2m_ctx resources was allocated by v4l2_m2m_ctx_init() in g2d_open()
should be freed from g2d_release() when it's not used.
Fix it
Fixes: 918847341af0 ("[media] v4l: add G2D driver for s5p device family")
Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 01fe904c9afd26e79c1f73aa0ca2e3d785e5e319 ]
In isp_video_release, file->private_data is freed via
_vb2_fop_release()->v4l2_fh_release(). But the freed
file->private_data is still used in v4l2_fh_is_singular_file()
->v4l2_fh_is_singular(file->private_data), which is a use
after free bug.
My patch uses a variable 'is_singular_file' to avoid the uaf.
v3: https://lore.kernel.org/patchwork/patch/1419058/
Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4cba5473c5ce0f1389d316c5dc6f83a0259df5eb ]
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b7fdd208687ba59ebfb09b2199596471c63b69e3 ]
When ctx_id >= HVA_MAX_INSTANCES in hva_hw_its_irq_thread() it tries to
access fields of ctx that is NULL at that point. The patch gets rid of
these accesses.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 56c1f0876293888f686e31278d183d4af2cac3c3 ]
The right thing to do is to add a new object to the building
system when a certain config option is selected, and *not*
override them.
So, fix obj-$(config) logic at sti makefiles, using "+=",
instead of ":=".
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 59087b66ea6730c130c57d23bd9fd139b78c1ba5 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
As a bonus, as pm_runtime_get_sync() always return 0 on
success, the logic can be simplified.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 59f96244af9403ddf4810ec5c0fbe8920857634e ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
On some places, this is ok, but on others the usage count
ended being unbalanced on failures.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
As a bonus, such function always return zero on success. So,
some code can be simplified.
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c44eac5b72e23c31eefc0e10a71d9650036b8341 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
The bdisp_start_streaming() doesn't take it into account, which
would unbalance PM usage counter at bdisp_stop_streaming().
The logic at bdisp_probe() is correct, but the best is to use
the same call along the driver.
So, replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 9c298f82d8392f799a0595f50076afa1d91e9092 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 10343de268d10cf07b092b8b525e12ad558ead77 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
As a plus, pm_runtime_resume_and_get() doesn't return
positive numbers, so the return code validation can
be removed.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 908711f542c17fe61e5d653da1beb8e5ab5c7b50 ]
Currently, the driver just assumes that PM runtime logic
succeded resuming the device.
That may not be the case, as pm_runtime_get_sync()
can fail (but keeping the usage count incremented).
Replace the code to use pm_runtime_resume_and_get(),
and letting it return the error code.
This way, if mtk_vcodec_dec_pw_on() fails, the logic
under fops_vcodec_open() will do the right thing and
return an error, instead of just assuming that the
device is ready to be used.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6e8b1526db164c9d4b9dacfb9bc48e365d7c4860 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
While here, check if the PM runtime error was caught at open time.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c41e02493334985cca1a22efd5ca962ce3abb061 ]
The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter, avoiding
a potential PM usage counter leak.
While here, ensure that the driver will check if PM runtime
resumed at vpfe_initialize_device().
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
