- 04 Jul, 2020 28 commits
-
-
Sean Young authored
This function has never been used. Found with clang: drivers/media/dvb-frontends/drxk_hard.c:159:19: warning: unused function 'MulDiv32' [-Wunused-function] static inline u32 MulDiv32(u32 a, u32 b, u32 c) Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
After the removal of the soc_camera driver and the soc_camera.h header the SOC-CAMERA entry in the MAINTAINERS file can also be removed. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Drop all configs with the CONFIG_SOC_CAMERA prefix since those have been removed. SOC_CAMERA support for the sh architecture was removed a long time ago. Drop it from the configs. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Drop all configs with the CONFIG_SOC_CAMERA prefix since those have been removed. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The soc_camera driver has been removed and all board files that used it have been fixed. This header can now be removed altogether. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The soc_camera driver (and related soc_camera-dependent sensor drivers) is obsolete and depends on BROKEN for a long time now. Nobody is using it, so it is time to kill it off. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The soc_camera driver is about to be removed, so drop camera support from this board. Note that the soc_camera driver itself has long since been deprecated and can't be compiled anymore (it depends on BROKEN), so camera support on this board has been broken for a long time (at least since 4.9 when the pxa_camera.c was removed from soc_camera). Note that there is a new pxa_camera.c driver that replaced the old soc_camera based driver, but using that would require these boards to be converted to use the device tree. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The soc_camera driver is about to be removed, so drop camera support from this board. Note that the soc_camera driver itself has long since been deprecated and can't be compiled anymore (it depends on BROKEN), so camera support on this board has been broken for a long time (at least since 4.6 when the omap1_camera.c was removed from soc_camera). Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Tony Lindgren <tony@atomide.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The soc_camera.h header driver is about to be removed, so drop camera support from this board. Note that the soc_camera driver itself has long since been deprecated and can't be compiled anymore (it depends on BROKEN), so camera support on this board has been broken for a long time (at least since 4.6 when the mx2_camera.c was removed from soc_camera). Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Remove the confusing SoC Camera reference. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Remove the confusing SoC Camera reference. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jeff Chase authored
Add a CEC device driver for the Chrontel ch7322 CEC conroller. This is an I2C device capable of sending and receiving CEC messages. Signed-off-by: Jeff Chase <jnchase@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jeff Chase authored
Use of the cec notifier framework is required to support CEC_CAP_CONNECTOR_INFO but some devices do not want physical address updates from the notifier. This adds an option to allow registering with a cec notifier without getting address updates. [hans: document the new adap_controls_phys_addr bool] Signed-off-by: Jeff Chase <jnchase@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jeff Chase authored
The ch7322 is a Chrontel CEC controller. Signed-off-by: Jeff Chase <jnchase@google.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Eugeniu Rosca authored
In commit f3b98e3c ("media: vsp1: Provide support for extended command pools"), the vsp pointer used for referencing the VSP1 device structure from a command pool during vsp1_dl_ext_cmd_pool_destroy() was not populated. Correctly assign the pointer to prevent the following null-pointer-dereference when removing the device: [*] h3ulcb-kf #> echo fea28000.vsp > /sys/bus/platform/devices/fea28000.vsp/driver/unbind Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007318be000 [0000000000000028] pgd=00000007333a1003, pud=00000007333a6003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 486 Comm: sh Not tainted 5.7.0-rc6-arm64-renesas-00118-ge644645a #185 Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT) pstate: 40000005 (nZcv daif -PAN -UAO) pc : vsp1_dlm_destroy+0xe4/0x11c lr : vsp1_dlm_destroy+0xc8/0x11c sp : ffff800012963b60 x29: ffff800012963b60 x28: ffff0006f83fc440 x27: 0000000000000000 x26: ffff0006f5e13e80 x25: ffff0006f5e13ed0 x24: ffff0006f5e13ed0 x23: ffff0006f5e13ed0 x22: dead000000000122 x21: ffff0006f5e3a080 x20: ffff0006f5df2938 x19: ffff0006f5df2980 x18: 0000000000000003 x17: 0000000000000000 x16: 0000000000000016 x15: 0000000000000003 x14: 00000000000393c0 x13: ffff800011a5ec18 x12: ffff800011d8d000 x11: ffff0006f83fcc68 x10: ffff800011a53d70 x9 : ffff8000111f3000 x8 : 0000000000000000 x7 : 0000000000210d00 x6 : 0000000000000000 x5 : ffff800010872e60 x4 : 0000000000000004 x3 : 0000000078068000 x2 : ffff800012781000 x1 : 0000000000002c00 x0 : 0000000000000000 Call trace: vsp1_dlm_destroy+0xe4/0x11c vsp1_wpf_destroy+0x10/0x20 vsp1_entity_destroy+0x24/0x4c vsp1_destroy_entities+0x54/0x130 vsp1_remove+0x1c/0x40 platform_drv_remove+0x28/0x50 __device_release_driver+0x178/0x220 device_driver_detach+0x44/0xc0 unbind_store+0xe0/0x104 drv_attr_store+0x20/0x30 sysfs_kf_write+0x48/0x70 kernfs_fop_write+0x148/0x230 __vfs_write+0x18/0x40 vfs_write+0xdc/0x1c4 ksys_write+0x68/0xf0 __arm64_sys_write+0x18/0x20 el0_svc_common.constprop.0+0x70/0x170 do_el0_svc+0x20/0x80 el0_sync_handler+0x134/0x1b0 el0_sync+0x140/0x180 Code: b40000c2 f9403a60 d2800084 a9400663 (f9401400) ---[ end trace 3875369841fb288a ]--- Fixes: f3b98e3c ("media: vsp1: Provide support for extended command pools") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> 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>
-
Colin Ian King authored
The variable err is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Eizan Miyamoto authored
Since components are registered in a list, the numeric component id that specified a location in an array is not necessary. Signed-off-by: Eizan Miyamoto <eizan@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Eizan Miyamoto authored
The functions mtk_mdp_register/unregister_component have been created to add / remove items from the list of components. This will eventually enable us to specify a list of components in the device tree instead of hardcoding them into this driver. The list is modified by a single thread at driver probe time, and will not be traversed by another thread until the call to pm_runtime_enable at the end of probing. Signed-off-by: Eizan Miyamoto <eizan@chromium.org> Reviewed-by: Enric Balletbo I Serra <enric.balletbo@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Eizan Miyamoto authored
This is a cleanup to better handle errors during MDP probe. Signed-off-by: Eizan Miyamoto <eizan@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Eizan Miyamoto authored
This is a cleanup to better handle errors during MDP probe. Signed-off-by: Eizan Miyamoto <eizan@chromium.org> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Eizan Miyamoto authored
These fields are not used and can be removed. Signed-off-by: Eizan Miyamoto <eizan@chromium.org> Reviewed-by: Enric Balletbo I Serra <enric.balletbo@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Francois Buergisser authored
The mtk-mdp driver uses states to check if the formats have been set on the capture and output when turning the streaming on, setting controls or setting the selection rectangles. Those states are reset when 0 buffers are requested like when checking capabilities. This patch removes all format checks and set one by default as queues in V4L2 are expected to always have a format set. https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-streamon.html https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-ctrl.html https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-selection.htmlSigned-off-by: Francois Buergisser <fbuergisser@chromium.org> Signed-off-by: Eizan Miyamoto <eizan@chromium.org> Reviewed-by: Enric Balletbo I Serra <enric.balletbo@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dan Carpenter authored
If fw_csr_string() returns -ENOENT, then "name" is uninitialized. So then the "strlen(model_names[i]) <= name_len" is true because strlen() is unsigned and -ENOENT is type promoted to a very high positive value. Then the "strncmp(name, model_names[i], name_len)" uses uninitialized data because "name" is uninitialized. Fixes: 92374e88 ("[media] firedtv: drop obsolete backend abstraction") 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>
-
Chen Zhou authored
Fixes coccicheck warning: ./drivers/media/platform/coda/coda-jpeg.c:331:3-31: alloc with no test, possible model on line 354 Add NULL check after kmalloc. Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Eugen Hristev authored
All warnings (new ones prefixed by >>, old ones prefixed by <<): >> drivers/media/platform/atmel/atmel-sama5d2-isc.c:323:34: warning: unused variable 'atmel_isc_of_match' [-Wunused-const-variable] static const struct of_device_id atmel_isc_of_match[] = { ^ 1 warning generated. vim +/atmel_isc_of_match +323 drivers/media/platform/atmel/atmel-sama5d2-isc.c 322 > 323 static const struct of_device_id atmel_isc_of_match[] = { 324 { .compatible = "atmel,sama5d2-isc" }, 325 { } 326 }; 327 MODULE_DEVICE_TABLE(of, atmel_isc_of_match); 328 Fixed warning by guarding the atmel_isc_of_match by CONFIG_OF. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrey Konovalov authored
Currently for msm_csiphy, msm_csid, and msm_ispif subdevices the media entity function field is set to MEDIA_ENT_F_IO_V4L. This is incorrect as MEDIA_ENT_F_IO_V4L implies V4L2 video node. Change it to MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER as this is the best fit from the functions defined in include/uapi/linux/media.h. Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Tested-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Dafna Hirschfeld authored
The rkisp1 supports RGB encoding with 6 bits per color with the following format: - - b5 b4 b3 b2 b1 b0 - - g5 g4 g3 g2 g1 g0 - - r5 r4 r3 r2 r1 r0 - - - - - - - - This is not how V4L2_PIX_FMT_BGR666 is defined, so remove this format from the driver's formats list. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- 23 Jun, 2020 12 commits
-
-
Tuomas Tynkkynen authored
Syzbot reports a NULL-ptr deref in the kref_put() call: BUG: KASAN: null-ptr-deref in media_request_put drivers/media/mc/mc-request.c:81 [inline] kref_put include/linux/kref.h:64 [inline] media_request_put drivers/media/mc/mc-request.c:81 [inline] media_request_close+0x4d/0x170 drivers/media/mc/mc-request.c:89 __fput+0x2ed/0x750 fs/file_table.c:281 task_work_run+0x147/0x1d0 kernel/task_work.c:123 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop arch/x86/entry/common.c:165 [inline] prepare_exit_to_usermode+0x48e/0x600 arch/x86/entry/common.c:196 What led to this crash was an injected memory allocation failure in media_request_alloc(): FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 should_failslab+0x5/0x20 kmem_cache_alloc_trace+0x57/0x300 ? anon_inode_getfile+0xe5/0x170 media_request_alloc+0x339/0x440 media_device_request_alloc+0x94/0xc0 media_device_ioctl+0x1fb/0x330 ? do_vfs_ioctl+0x6ea/0x1a00 ? media_ioctl+0x101/0x120 ? __media_device_usb_init+0x430/0x430 ? media_poll+0x110/0x110 __se_sys_ioctl+0xf9/0x160 do_syscall_64+0xf3/0x1b0 When that allocation fails, filp->private_data is left uninitialized which media_request_close() does not expect and crashes. To avoid this, reorder media_request_alloc() such that allocating the struct file happens as the last step thus media_request_close() will no longer get called for a partially created media request. Reported-by: syzbot+6bed2d543cf7e48b822b@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Fixes: 10905d70 ("media: media-request: implement media requests") Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Qingwu Zhang authored
ov2740 includes 512bytes of one-time programmable memory and 256 bytes are reserved for customers which can be used to store customized information. This patch provide an NVMEM interface to support read out the customized data in OTP. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Qingwu Zhang <qingwu.zhang@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrey Konovalov authored
The bus_type field of v4l2_fwnode_endpoint structure passed as the argument to v4l2_fwnode_endpoint_alloc_parse() function must be initiaized. Set it to V4L2_MBUS_CSI2_DPHY, and check for -ENXIO which is returned when the requested media bus type doesn't match the fwnode. Also remove v4l2_fwnode_endpoint field from struct imx290 as it is only needed in the probe function: use the local variable for this purpose. Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
The 10ms settle time is needed only at the end of all consecutive register writes. So move the delay to outside of the for loop of imx290_set_register_array(). Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
Add support to enumerate all frame sizes supported by IMX290. This is required for using with userspace tools such as libcamera. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
IMX290 is capable of outputting frames in both Raw Bayer (packed) 10 and 12 bit formats. Since the driver already supports RAW10 mode, let's add the missing RAW12 mode as well. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
Add support for generating following test patterns by IMX290: * Sequence Pattern 1 * Horizontal Color-bar Chart * Vertical Color-bar Chart * Sequence Pattern 2 * Gradation Pattern 1 * Gradation Pattern 2 * 000/555h Toggle Pattern Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
IMX290 operates with multiple link frequency and pixel rate combinations. The initial driver used a single setting for both but since we now have the lane count support in place, let's add configurable link frequency and pixel rate. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Manivannan Sadhasivam authored
The IMX290 sensor can output frames with 2/4 CSI2 data lanes. This commit adds support for 2 lane mode in addition to the 4 lane and also configuring the data lane settings in the driver based on system configuration. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrey Konovalov authored
According to https://www.kernel.org/doc/Documentation/gpio/consumer.txt, - all of the gpiod_set_value_xxx() functions operate with the *logical* value. So in imx290_power_on() the reset signal should be cleared (de-asserted) with gpiod_set_value_cansleep(imx290->rst_gpio, 0), and in imx290_power_off() the value of 1 must be used to apply/assert the reset to the sensor. In the device tree the reset pin is described as GPIO_ACTIVE_LOW, and gpiod_set_value_xxx() functions take this into account, - when devm_gpiod_get_optional() is called with GPIOD_ASIS, the GPIO is not initialized, and the direction must be set later; using a GPIO without setting its direction first is illegal and will result in undefined behavior. Fix this by using GPIOD_OUT_HIGH instead of GPIOD_ASIS (this asserts the reset signal to the sensor initially). Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrey Konovalov authored
The macro is defined as SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn), so imx290_power_off must be the 1st arg, and imx290_power_on the 2nd. Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrey Konovalov authored
With the current driver 'media-ctl -p' issued right after the imx290 driver is loaded prints: pad0: Source [fmt:unknown/0x0] The format value of zero is due to the current_format field of the imx290 struct not being initialized yet. As imx290_entity_init_cfg() calls imx290_set_fmt(), the current_mode field is also initialized, so the line which set current_mode to a default value in driver's probe() function is no longer needed. Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-