- May 17, 2022
-
-
Bryan O'Donoghue authored
The imx412 like many I2C camera sensors has three voltage rails which depending on platform may be necessary to switch power onto directly. Add in as optional rails so as not to break anything for existing users. Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Bryan O'Donoghue authored
The enable path does - gpio - clock The disable path does - gpio - clock Fix the order on the power-off path so that power-off and power-on have the same ordering for clock and gpio. Fixes: 9214e86c ("media: i2c: Add imx412 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by:
Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by:
-
Bryan O'Donoghue authored
The imx412/imx577 sensor has a reset line that is active low not active high. Currently the logic for this is inverted. The right way to define the reset line is to declare it active low in the DTS and invert the logic currently contained in the driver. The DTS should represent the hardware does i.e. reset is active low. So: + reset-gpios = <&tlmm 78 GPIO_ACTIVE_LOW>; not: - reset-gpios = <&tlmm 78 GPIO_ACTIVE_HIGH>; I was a bit reticent about changing this logic since I thought it might negatively impact @intel.com users. Googling a bit though I believe this sensor is used on "Keem Bay" which is clearly a DTS based system and is not upstream yet. Fixes: 9214e86c ("media: i2c: Add imx412 camera sensor driver") Cc: stable@vger.kernel.org Signed-off-by:
-
- May 13, 2022
-
-
Nicolas Dufresne authored
For long term references, frame_num is set to long_term_frame_idx which does not require wrapping. This is fixed by observation, no directly related issue have been found yet. Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by:
Sebastian Fricke <sebastian.fricke@collabora.com> Reviewed-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Nicolas Dufresne authored
If the timestamp of the src buffer differs from the timestamp of a held dst buffer, the held buffer is implicitly removed and marked as done. Add a trace to help debugging if someone hits that case. Signed-off-by:
-
Nicolas Dufresne authored
These two fields need documentation as they have dual meaning. It is also confusing since pic_num is a derived value from frame_num, so this should help application developers. If we ever need to make a V2 of this API, I would suggest to remove pic_num entirely. Signed-off-by:
-
Yunfei Dong authored
Add h264 decode driver to support mt8186. For the architecture is single core, need to add new interface to decode. Signed-off-by:
Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by:
-
Yunfei Dong authored
Adds MT8186's compatible "mediatek,mt8186-vcodec-dec". Adds MT8186's device private data mtk_vdec_single_core_pdata. Signed-off-by:
-
Yunfei Dong authored
Adds decoder dt-bindings for mt8186. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Yunfei Dong authored
If the driver support subdev mode, the parameter "dev->pm.dev" will be NULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmod mtk-vcodec-dec.ko. [ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80 [ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c [ 4380.711509] sp : ffff80000819bc10 [ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000 [ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220 [ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020 [ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976 [ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040 [ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc [ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 [ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208 [ 4380.786031] Call trace: [ 4380.788465] do_raw_spin_trylock+0x4/0x80 [ 4380.792462] __pm_runtime_disable+0x2c/0x1b0 [ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec] [ 4380.802466] platform_remove+0x2c/0x60 [ 4380.806204] __device_release_driver+0x194/0x250 [ 4380.810810] driver_detach+0xc8/0x15c [ 4380.814462] bus_remove_driver+0x5c/0xb0 [ 4380.818375] driver_unregister+0x34/0x64 [ 4380.822288] platform_driver_unregister+0x18/0x24 [ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec] [ 4380.833240] __arm64_sys_delete_module+0x190/0x224 [ 4380.838020] invoke_syscall+0x48/0x114 [ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c [ 4380.846540] do_el0_svc+0x28/0x90 [ 4380.849844] el0_svc+0x4c/0x100 [ 4380.852975] el0t_64_sync_handler+0xec/0xf0 [ 4380.857148] el0t_64_sync+0x190/0x194 [ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004) Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by:
-
Yunfei Dong authored
Add support for VP9 decoding using the stateless API, as supported by MT8192. And the drivers is lat and core architecture. Signed-off-by:
George Sun <george.sun@mediatek.com> Tested-by:
-
Yunfei Dong authored
Add support for VP8 decoding using the stateless API, as supported by MT8192. Signed-off-by:
-
Yunfei Dong authored
Adds h264 lat and core architecture driver for mt8192, and the decode mode is frame based for stateless decoder. Signed-off-by:
-
Yunfei Dong authored
Mt8192 can use some of common code with mt8183. Moves them to a new file in order to reuse. [hverkuil: replaced memcpy_toio by memcpy, was left over from a prev version] Signed-off-by:
-
Yunfei Dong authored
The capture queue format type may be differ depending on platform: for stateless decoder drivers, we need to calculate the capture buffer size according to the capture queue format type in SCP. As a preparation for introducing drivers for stateless decoding, save the current capture queue type on a per vcodec context basis. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by:
-
Yunfei Dong authored
Need to use default pic info when get pic info fail. Signed-off-by:
Steve Cho <stevecho@chromium.org> Tested-by:
-
Yunfei Dong authored
For vp8 not support 4K, need to disable it. Signed-off-by:
-
Yunfei Dong authored
Needs to use mediatek compressed mode for mt8192 decoder. Signed-off-by:
-
Yunfei Dong authored
Getting supported output and capture queue format types according to decoder capability. Signed-off-by:
-
Yunfei Dong authored
Supported output and capture format types for mt8192 are different with mt8183. Redefine parameters to store them. Signed-off-by:
-
Yunfei Dong authored
For lat and core decode in parallel, need to get capture buffer when core start to decode and put capture buffer to display list when core decode done. Signed-off-by:
-
Yunfei Dong authored
call vb2_set_plane_payload to set each plane bytesused in buf prepare, need not to set independently for stateless and statefull architectures. Signed-off-by:
-
Yunfei Dong authored
Supported max resolution for different platforms are not the same: 2K or 4K, getting it according to dec_capability. Signed-off-by:
Tzung-Bi <Shih<tzungbi@google.com> Reviewed-by:
-
Yunfei Dong authored
Different capture buffer format has different buffer size, need to get real buffer size according to buffer type from scp. Signed-off-by:
-
Yunfei Dong authored
MT8173 platform use vpu firmware, mt8183/mt8192 will use scp firmware instead, using chip name is not reasonable to separate different firmware architecture. Using firmware type is much better. Signed-off-by:
-
Yunfei Dong authored
Lock, power and clock are highly coupled operations. Adds vdec enable/disable hardware helpers and uses them. Signed-off-by:
-
Yunfei Dong authored
Will return -EINVAL using standard framework api when test stateless decoder with cmd VIDIOC_(TRY)DECODER_CMD. Disable them to adjust v4l2 compliance test for user driver(GStreamer/Chrome) won't use decoder cmd. Fixes: 8cdc3794 ("media: mtk-vcodec: vdec: support stateless API") Signed-off-by:
-
Hans Verkuil authored
Using an activation counter to decide when the enable or disable the cec adapter is not the best approach and can lead to race conditions. Change this to determining the current status of the adapter, and enable or disable the adapter accordingly. It now only needs to be called whenever there is a chance that the state changes, and it can handle enabling/disabling monitoring as well if needed. This simplifies the code and it should be a more robust approach as well. Signed-off-by:
-
Hans Verkuil authored
If the physical address changes (i.e. becomes invalid, then valid again) while the adapter is still claiming free logical addresses, then trigger a reconfiguration since any claimed LAs may now be stale. Signed-off-by:
-
Hans Verkuil authored
If an adapter is trying to claim a free logical address then it is in the 'is_configuring' state. If during that process the cable is disconnected (HPD goes low, which in turn invalidates the physical address), then cec_adap_unconfigure() is called, and that set the is_configuring boolean to false, even though the thread that's trying to claim an LA is still running. Don't touch the is_configuring bool in cec_adap_unconfigure(), it will eventually be cleared by the thread. By making that change the cec_config_log_addr() function also had to change: it was aborting if is_configuring became false (since that is what cec_adap_unconfigure() did), but that no longer works. Instead check if the physical address is invalid. That is a much more appropriate check anyway. This fixes a bug where the the adapter could be disabled even though the device was still configuring. This could cause POLL transmits to time out. Signed-off-by:
-
Hans Verkuil authored
If, while trying to claim a free logical address, a POLL message times out, then abort this process. A CEC_TX_STATUS_TIMEOUT should be handled the same as a CEC_TX_STATUS_ABORTED. This avoids a situation where transmits time out due to a driver or hardware bug and it takes ages before the attempt to find available free logical addresses finishes. Signed-off-by:
-
Hans Verkuil authored
The __cec_s_log_addrs() function can configure or unconfigure the adapter. The ioctl handler in cec-api.c will prevent it from being called to configure the adapter if it was already configured (or in the process of configuring). But it can still be called to unconfigure an already unconfigured adapter, and it didn't check for that. This can cause cec_activate_cnt_dec() to be called too often, causing a WARN_ON. Instead first check if adap->log_addrs.num_log_addrs == 0 and return since in that case the adapter is already unconfigured. Signed-off-by:
-
Hans Verkuil authored
It's OK to keep the pending pin events when disabling or enabling the 'adapter'. Zeroing this can cause a race condition if this happens when the pin kthread is handling a pin event and calls atomic_dec later, causing work_pin_num_events to become negative. Just leave pending events in the queue, they'll be read eventually. Signed-off-by:
-
Hans Verkuil authored
When the adap_enable callback is called the adap->lock is held. When disabling the adapter it attempts to stop the kthread that deals with receiving and transmitting messages. However, kthread_stop waits for the thread to stop, so all that time adap->lock is held. Unfortunately, the kernel thread itself can call functions that take that same lock, so a deadlock can occur. Change the logic to keep the kernel thread running and instead when disabling the adapter, just set the pin to high, go to idle and then to state OFF and disable the interrupt. Only stop the kernel thread when the adapter is deleted. This way disabling the adapter will not wait for anything and the deadlock is avoided. Signed-off-by:
-
Tetsuo Handa authored
Since usb_register_dev() from imon_init_display() from imon_probe() holds minor_rwsem while display_open() which holds driver_lock and ictx->lock is called with minor_rwsem held from usb_open(), holding driver_lock or ictx->lock when calling usb_register_dev() causes circular locking dependency problem. Since usb_deregister_dev() from imon_disconnect() holds minor_rwsem while display_open() which holds driver_lock is called with minor_rwsem held, holding driver_lock when calling usb_deregister_dev() also causes circular locking dependency problem. Sean Young explained that the problem is there are imon devices which have two usb interfaces, even though it is one device. The probe and disconnect function of both usb interfaces can run concurrently. Alan Stern responded that the driver and USB cores guarantee that when an interface is probed, both the interface and its USB device are locked. Ditto for when the disconnect callback gets run. So concurrent probing/ disconnection of multiple interfaces on the same device is not possible. Therefore, we don't need locks for handling race between imon_probe() and imon_disconnect(). But we still need to handle race between display_open() /vfd_write()/lcd_write()/display_close() and imon_disconnect(), for disconnect event can happen while file descriptors are in use. Since "struct file"->private_data is set by display_open(), vfd_write()/ lcd_write()/display_close() can assume that "struct file"->private_data is not NULL even after usb_set_intfdata(interface, NULL) was called. Replace insufficiently held driver_lock with refcount_t based management. Add a boolean flag for recording whether imon_disconnect() was already called. Use RCU for accessing this boolean flag and refcount_t. Since the boolean flag for imon_disconnect() is shared, disconnect event on either intf0 or intf1 affects both interfaces. But I assume that this change does not matter, for usually disconnect event would not happen while interfaces are in use. Link: https://syzkaller.appspot.com/bug?extid=c558267ad910fc494497 Reported-by:
syzbot <syzbot+c558267ad910fc494497@syzkaller.appspotmail.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Oliver Neukum authored
The point of using get/put_device() is to keep references for as long as the device may be in use. That means dropping them must be the penultimate action right before freeing the memory. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Oliver Neukum authored
The timer will report events for an input device. Reporting events for an unregistered device is bad. Hence the timer must be killed first. Signed-off-by:
-
Oliver Neukum authored
GFP_NOIO is fine here. Signed-off-by:
-
Hans Verkuil authored
Fix smatch warning: drivers/media/i2c/s5k6a3.c:234 __s5k6a3_power_on() warn: 'sensor->clock' from clk_prepare_enable() not released on lines: 234. Signed-off-by:
-
Hans Verkuil authored
Fixes smatch warning: drivers/media/i2c/ccs/ccs-core.c:1676 ccs_power_on() warn: 'sensor->ext_clk' from clk_prepare_enable() not released on lines: 1606. Signed-off-by:
-
