summaryrefslogtreecommitdiff
path: root/drivers/media/i2c
AgeCommit message (Collapse)AuthorFilesLines
2020-10-08media: tvp7002: fix uninitialized variable warningHans Verkuil1-1/+3
tvp7002.c: In function 'tvp7002_g_register': tvp7002.c:691:11: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized] 691 | reg->val = val; | ~~~~~~~~~^~~~~ Just return without setting 'reg' if tvp7002_read returns an error. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-10-08media: s5k5baf: drop 'data' field in struct s5k5baf_fwHans Verkuil1-3/+2
struct s5k5baf_fw ends with this: struct { u16 id; u16 offset; } seq[0]; u16 data[]; }; which is rather confusing and can cause gcc warnings: s5k5baf.c: In function 's5k5baf_load_setfile.isra': s5k5baf.c:390:13: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct <anonymous>[0]' [-Wzero-length-bounds] 390 | if (f->seq[i].offset + d <= end) | ~~~~~~^~~ It turns out that 'data[]' is used in only one place and it can easily be replaced by &fw->seq[0].id and 'seq[0]' can be replaced by 'seq[]'. This is both more readable and solved that warnings. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Sylwester Nawrocki <snawrocki@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-26media: tc358743: cleanup tc358743_cec_isrTom Rix1-5/+7
tc358743_cec_isr is misnammed, it is not the main isr. So rename it to be consistent with its siblings, tc358743_cec_handler. It also does not check if its input parameter 'handled' is is non NULL like its siblings, so add a check. Fixes: a0ec8d1dc42e ("media: tc358743: add CEC support") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-26media: tc358743: initialize variableTom Rix1-1/+1
clang static analysis flags this error tc358743.c:1468:9: warning: Branch condition evaluates to a garbage value return handled ? IRQ_HANDLED : IRQ_NONE; ^~~~~~~ handled should be initialized to false. Fixes: d747b806abf4 ("[media] tc358743: add direct interrupt handling") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: ov8856: Add support for 3264x2448 modeRobert Foss1-0/+215
OV8856 supports 3264x2448 @ 30 FPS, which is added in this commit. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: ov8856: Add support for 1632x1224 modeRobert Foss1-0/+215
OV8856 supports 1632x1224 @ 60 FPS, which is added in this commit. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: max9286: Allocate v4l2_async_subdev dynamicallyLaurent Pinchart1-19/+21
v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the max9286 driver embeds it in the max9286_source structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup(). Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally. A new max9286_asd structure is introduced, to store a pointer to the corresonding max9286_source that needs to be accessed from bound and unbind callbacks. There's no need to take an extra explicit reference to the fwnode anymore as v4l2_async_notifier_add_fwnode_subdev() does so internally. While at it, use %u instead of %d to print the unsigned index in the error message from the v4l2_async_notifier_add_fwnode_subdev() error path. Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Fail probe on unsupported bus_typeLad Prabhakar1-0/+7
Fail probe if unsupported bus_type is detected. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Add support for BT656 modeLad Prabhakar1-12/+34
Enable support for BT656 mode. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Configure HVP lines in s_power callbackLad Prabhakar1-65/+58
Configure HVP lines in s_power callback instead of configuring everytime in ov5640_set_stream_dvp(). Alongside also disable MIPI in DVP mode. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Enable data pins on poweron for DVP modeLad Prabhakar1-33/+40
During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP mode with rcar-vin bridge noticed the capture worked fine for the first run (with yavta), but for subsequent runs the bridge driver waited for the frame to be captured. Debugging further noticed the data lines were enabled/disabled in stream on/off callback and dumping the register contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct values, but yet frame capturing failed. To get around this issue data lines are enabled in s_power callback. (Also the sensor remains in power down mode if not streaming so power consumption shouldn't be affected) Fixes: f22996db44e2d ("media: ov5640: add support of DVP parallel interface") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Separate out mipi configuration from s_powerLad Prabhakar1-56/+60
In preparation for adding DVP configuration in s_power callback move mipi configuration into separate function Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Remain in power down for DVP mode unless streamingLad Prabhakar1-3/+16
Keep the sensor in software power down mode and wake up only in ov5640_set_stream_dvp() callback. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: Remove Alan Chiang's e-mail addressSakari Ailus2-2/+2
Alan Chiang's e-mail address no longer works. Remove it. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-07Merge tag 'v5.9-rc4' into patchworkMauro Carvalho Chehab1-2/+2
Linux 5.9-rc4 * tag 'v5.9-rc4': (1001 commits) Linux 5.9-rc4 io_uring: fix linked deferred ->files cancellation io_uring: fix cancel of deferred reqs with ->files include/linux/log2.h: add missing () around n in roundup_pow_of_two() mm/khugepaged.c: fix khugepaged's request size in collapse_file mm/hugetlb: fix a race between hugetlb sysctl handlers mm/hugetlb: try preferred node first when alloc gigantic page from cma mm/migrate: preserve soft dirty in remove_migration_pte() mm/migrate: remove unnecessary is_zone_device_page() check mm/rmap: fixup copying of soft dirty and uffd ptes mm/migrate: fixup setting UFFD_WP flag mm: madvise: fix vma user-after-free checkpatch: fix the usage of capture group ( ... ) fork: adjust sysctl_max_threads definition to match prototype ipc: adjust proc_ipc_sem_dointvec definition to match prototype mm: track page table modifications in __apply_to_page_range() MAINTAINERS: IA64: mark Status as Odd Fixes only MAINTAINERS: add LLVM maintainers MAINTAINERS: update Cavium/Marvell entries mm: slub: fix conversion of freelist_corrupted() ...
2020-09-03media: rc: harmonize infrared durations to microsecondsSean Young1-1/+1
rc-core kapi uses nanoseconds for infrared durations for receiving, and microseconds for sending. The uapi already uses microseconds for both, so this patch does not change the uapi. Infrared durations do not need nanosecond resolution. IR protocols do not have durations shorter than about 100 microseconds. Some IR hardware offers 250 microseconds resolution, which is sufficient for most protocols. Better hardware has 50 microsecond resolution and is enough for every protocol I am aware off. Unify on microseconds everywhere. This simplifies the code since less conversion between microseconds and nanoseconds needs to be done. This affects: - rx_resolution member of struct rc_dev - timeout member of struct rc_dev - duration member in struct ir_raw_event Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Patrick Lerda <patrick9876@free.fr> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: "David Härdeman" <david@hardeman.nu> Cc: Benjamin Valentin <benpicco@googlemail.com> Cc: Antti Palosaari <crope@iki.fi> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: ov5675: correct the maximum exposure valueBingbu Cao1-5/+10
The unit of exposure value is different from other OmniVision sensors, driver will divide by 2 before set register, the exposure range exposed by v4l2 ctrl to user should be same as others, so the calculation for the maximum exposure value in current driver need be fixed. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: ov7740: use SCCB regmapRaag Jadav2-10/+2
Make use of SCCB APIs for regmap operations. Remove i2c_check_functionality as devm_regmap_init_sccb does it for us. Signed-off-by: Raag Jadav <raagjadav@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: imx274: fix frame interval handlingHans Verkuil1-3/+5
1) the numerator and/or denominator might be 0, in that case fall back to the default frame interval. This is per the spec and this caused a v4l2-compliance failure. 2) the updated frame interval wasn't returned in the s_frame_interval subdev op. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: m5mols: Check function pointer in m5mols_sensor_powerTom Rix1-1/+2
clang static analysis reports this error m5mols_core.c:767:4: warning: Called function pointer is null (null dereference) [core.CallAndMessage] info->set_power(&client->dev, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In other places, the set_power ptr is checked. So add a check. Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: i2c: fix error check on max9286_read callColin Ian King1-1/+2
Currently the error return from the call to max9286_read is masked with 0xf0 so the following check for a negative error return is never true. Fix this by checking for an error first, then masking the return value for subsequent conflink_mask checking. Addresses-Coverity: ("Logically dead code") Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: ov5640: Correct Bit Div register in clock tree diagramPaul Kocialkowski1-1/+1
Although the code is correct and doing the right thing, the clock diagram showed the wrong register for the bit divider, which had me doubting the understanding of the tree. Fix this to avoid doubts in the future. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Fixes: aa2882481cada ("media: ov5640: Adjust the clock based on the expected rate") Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: i2c: ov2740: get OTP data ready before nvmem registrationBingbu Cao1-12/+12
The OTP data was not ready after registered as nvmem device, it is risky as the nvmem read may happen once the device exists, this patch get the OTP data ready before registering the nvmem device. OTP data missing should not break the normal camera sensor probe, so use a warning instead of an error message. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Qingwu Zhang <qingwu.zhang@intel.com> Suggested-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-29media: Use fallthrough pseudo-keywordGustavo A. R. Silva10-18/+18
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-29media: i2c: tda1997x.c: Fix assignment of 0/1 to bool variableDaniel W. S. Almeida1-3/+3
Fix the following coccinelle reports: drivers/media/i2c/tda1997x.c:911:6-21: WARNING: Assignment of 0/1 to bool variable drivers/media/i2c/tda1997x.c:939:2-17: WARNING: Assignment of 0/1 to bool variable drivers/media/i2c/tda1997x.c:947:4-19: WARNING: Assignment of 0/1 to bool variable Replace assignment to 1 with true and assignment to 0 with false. Found using - Coccinelle (http://coccinelle.lip6.fr) Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-29media: i2c: imx219.c: fix assignment of 0/1 to bool variableDaniel W. S. Almeida1-1/+1
Fix the following coccinelle report: drivers/media/i2c/imx219.c:1191:1-18: WARNING: Assignment of 0/1 to bool variable Replace the assignment to 0 with false instead. Found using - Coccinelle (http://coccinelle.lip6.fr) Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-28media: max9286: Depend on OF_GPIOSakari Ailus1-1/+1
The driver expects struct gpio_chip has of_node field and that field is only there if CONFIG_OF_GPIO is defined. Fix this by changing the OF dependency to OF_GPIO. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-28media: i2c: imx214: select V4L2_FWNODEJacopo Mondi1-1/+1
After the recent conversion of the media build infrastructure to select V4L2 components instead of depending on their presence, which took place in: 32a363d0b0b14 ("media: Kconfig files: use select for V4L2 subdevs and MC") imx214 stands out as being the (only?) media I2C driver that still depends on a V4L2 core symbol instead of selecting it. This confuses the build system which claims it has detected a circular dependency when other drivers select the same symbol as the imx214 driver does. drivers/media/i2c/Kconfig:728:error: recursive dependency detected! drivers/media/i2c/Kconfig:728: symbol VIDEO_IMX214 depends on V4L2_FWNODE drivers/media/v4l2-core/Kconfig:71: symbol V4L2_FWNODE is selected by VIDEO_BCM2835_UNICAM drivers/media/platform/bcm2835/Kconfig:3: symbol VIDEO_BCM2835_UNICAM depends on VIDEO_V4L2_SUBDEV_API drivers/media/v4l2-core/Kconfig:19: symbol VIDEO_V4L2_SUBDEV_API depends on MEDIA_CONTROLLER drivers/media/Kconfig:168: symbol MEDIA_CONTROLLER is selected by VIDEO_IMX214 Fix this by making the imx214 driver select V4L2_FWNODE instead of depending on it and align it with all the other drivers. Fixes: 32a363d0b0b14 ("media: Kconfig files: use select for V4L2 subdevs and MC") Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-18media: i2c: adv748x: Implement get_mbus_configJacopo Mondi1-0/+31
Implement the newly introduced get_mbus_config operation to report the number of currently used data lanes on the MIPI CSI-2 interface. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-18media: i2c: adv748x: Adjust TXA data lanes numberJacopo Mondi2-7/+25
When outputting SD-Core output through the TXA MIPI CSI-2 interface, the number of enabled data lanes should be reduced in order to guarantee that the two video formats produced by the SD-Core (480i and 576i) generate a MIPI CSI-2 link clock frequency compatible with the MIPI D-PHY specifications. Limit the number of enabled data lanes to 2, which is guaranteed to support 480i and 576i formats. Cache the number of enabled data lanes to be able to report it through the new get_mbus_config operation. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-18media: i2c: ov6650: Use new [get|set]_mbus_config opsJacopo Mondi1-16/+37
Use the new get_mbus_config and set_mbus_config pad operations in place of the video operations currently in use. Compared to other drivers where the same conversion has been performed, ov6650 proved to be a bit more tricky, as the existing g_mbus_config implementation did not report the currently applied configuration but the set of all possible configuration options. Adapt the driver to support the semantic of the two newly introduced operations: - get_mbus_config reports the current media bus configuration - set_mbus_config applies only changes explicitly requested and updates the provided cfg parameter to report what has actually been applied to the hardware. Compile-tested only. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-18media: i2c: Use the new get_mbus_config pad opJacopo Mondi7-21/+28
Move the existing users of the g_mbus_config video operation to use the newly introduced get_mbus_config pad operations. All the ported drivers report a static media bus configuration and do no support s_mbus_config so the operation implementation has not changed. Bridge drivers needs to call the new pad operation and will receive an -ENOICTLCMD when calling the old g_mbus_config video operation Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-07-19media: i2c: Add RDACM20 driverJacopo Mondi5-0/+1247
The RDACM20 is a GMSL camera supporting 1280x800 resolution images developed by IMI based on an Omnivision 10635 sensor and a Maxim MAX9271 GMSL serializer. The GMSL link carries power, control (I2C) and video data over a single coax cable. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-07-19media: i2c: Add MAX9286 driverKieran Bingham3-0/+1334
The MAX9286 is a 4-channel GMSL deserializer with coax or STP input and CSI-2 output. The device supports multicamera streaming applications, and features the ability to synchronise the attached cameras. CSI-2 output can be configured with 1 to 4 lanes, and a control channel is supported over I2C, which implements an I2C mux to facilitate communications with connected cameras across the reverse control channel. Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-07-19media: i2c: dw9768: Add DW9768 VCM driverDongchun Zhu3-0/+567
Add a V4L2 sub-device driver for DW9768 voice coil motor, providing control to set the desired focus via IIC serial interface. Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-07-19media: i2c: imx290: replace msleep(10) with usleep_range(10000, 11000)Andrey Konovalov1-3/+3
This fixes checkpatch warnings of "msleep < 20ms can sleep for up to 20ms". 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>
2020-07-04media: tvp5150: Add missed media_entity_cleanup()Chuhong Yuan1-2/+6
This driver does not call media_entity_cleanup() in the error handler of tvp5150_registered() and tvp5150_remove(), while it has called media_entity_pads_init() at first. Add the missed calls to fix it. Fixes: 0556f1d580d4 ("media: tvp5150: add input source selection of_graph support") Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-07-04media: ov9640: update MODULE_DESCRIPTIONHans Verkuil1-1/+1
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>
2020-06-23media: ov2740: add NVMEM interface to read customized OTP dataQingwu Zhang1-0/+145
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>
2020-06-23media: i2c: imx290: set bus_type before calling ↵Andrey Konovalov1-19/+19
v4l2_fwnode_endpoint_alloc_parse() 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>
2020-06-23media: i2c: imx290: Move the settle time delay out of loopManivannan Sadhasivam1-3/+3
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>
2020-06-23media: i2c: imx290: Add support to enumerate all frame sizesManivannan Sadhasivam1-0/+23
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>
2020-06-23media: i2c: imx290: Add RAW12 mode supportManivannan Sadhasivam1-3/+33
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>
2020-06-23media: i2c: imx290: Add support for test pattern generationManivannan Sadhasivam1-1/+40
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>
2020-06-23media: i2c: imx290: Add configurable link frequency and pixel rateManivannan Sadhasivam1-39/+109
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>
2020-06-23media: i2c: imx290: Add support for 2 data lanesManivannan Sadhasivam1-14/+133
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>
2020-06-23media: i2c: imx290: fix reset GPIO pin handlingAndrey Konovalov1-3/+4
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>
2020-06-23media: i2c: imx290: fix the order of the args in SET_RUNTIME_PM_OPS()Andrey Konovalov1-1/+1
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>
2020-06-23media: i2c: imx290: set the format before VIDIOC_SUBDEV_G_FMT is calledAndrey Konovalov1-3/+3
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>
2020-06-23media: ov2740: make ov2740 driver only work with ACPIBingbu Cao2-3/+2
As the ACPI id of ov2740 camera sensor was registered as "INT3474", current ov2740 driver is supposed to be working with ACPI only. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-23 13:58:19 +0300