- 04 Jan, 2020 8 commits
-
-
Chen-Yu Tsai authored
The CSI0 block in the Allwinner R40 SoC looks to be the same as the one in the A20. The register maps line up, and they support the same features. The R40 appears to support BT.1120 based on the feature overview, but it is not mentioned anywhere else. Also like the A20, the ISP is not mentioned, but the CSI special clock needs to be enabled for the hardware to function. The manual does state that the CSI special clock is the TOP clock for all CSI hardware, but currently no hardware exists for us to test if CSI1 also depends on it or not. Add a compatible string for the CSI0 block in the R40, with the A20 compatible string as a fallback. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <mripard@kernel.org> Acked-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>
-
Chen-Yu Tsai authored
The CSI1 block has the same structure and layout as the CSI0 block. Differences include: - Only one channel in BT.656 instead of four in CSI0 - 10-bit raw data input vs 8-bit in CSI0 - 24-bit RGB888/YUV444 input vs 16-bit RGB565/YUV422 in CSI0 - No ISP hardware The hardware found in the A20 is the same as in the A10. Signed-off-by:
-
Bingbu Cao authored
Currently, the imgu running mode need user to set by v4l2 ctrl. However, imgu only support 2 pipes and 2 operation modes - video and still. This patch make the first imgu subdev running as video and second one running as still, it will make the user understand easily, it can also cover current camera use cases requirement. The running mode is set during subdev registering, no race-condition after change, so it is safe to change the mode data type to integer. Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Bingbu Cao authored
From firmware perspective, the main output for each pipe is mandatory and must be enabled. This patch set the link between imgu subdev and main output as IMMUTABLE by default. Signed-off-by:
-
Eugen Hristev authored
This driver supports both the mt9v032 (color) and the mt9v022 (mono) sensors. Depending on which sensor is used, the format from the sensor is different. The format.code inside the dev struct holds this information. The enum mbus and enum frame sizes need to take into account both type of sensors, not just the color one. To solve this, use the format.code in these functions instead of the hardcoded bayer color format (which is only used for mt9v032). [Sakari Ailus: rewrapped commit message] Suggested-by:
Wenyou Yang <wenyou.yang@microchip.com> Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Jules Irenge authored
Replace 0 with false to clear warning of assignment of 0/1 to bool variable. Issue detected by coccinelle tool. Signed-off-by:
Jules Irenge <jbi.octave@gmail.com> Signed-off-by:
-
Adam Ford authored
The variable _rate is by ov5640_compute_sys_clk() which returns zero if the PLL exceeds 1GHz. Unfortunately, the check to see if the max PLL1 output is checking 'rate' and not '_rate' and 'rate' does not ever appear to be 0. This patch changes the check against the returned value of '_rate' to determine if the PLL1 output exceeds 1GHz. Fixes: aa288248 ("media: ov5640: Adjust the clock based on the expected rate") Signed-off-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
-
Adam Ford authored
Currently the various modes are placed into a table, but when ov5640_find_mode is called, it has to double check whether or not the requested framerate is tolerated by the mode. The determination is based on checking hact, vact, and frame rate. Only 640x480 is allowed at 60fps and QSXGA is limited to 15fps, but as the number of permitted frame rates change, this will begin to add more and more complexity to the check. This patch simplifies the check by adding the max framerate allowed for each mode into the table of modes. It then compares the requested framerate to the max permitted in the mode's table. This reduces the number of comparisions to one down from three at run-time. Signed-off-by:
-
- 03 Jan, 2020 23 commits
-
-
Sakari Ailus authored
If there was an error in starting streaming, put the runtime usage count of the device. Signed-off-by:
-
Sakari Ailus authored
Instead of keeping track of the power state ourselves, let runtime PM handle it. This also splits handling controls between side effect management and writing the new configuration to the sensor's registers. Signed-off-by:
-
Sakari Ailus authored
The omap3isp driver set the new buffer and enabled the CCDC in a situation a new buffer was available but streaming was about to be stopped on the CCDC. This lead to frequent system crashes in case there were buffers queued when streming was being stopped. Fix this by first checking whether there's an intent to stop streaming and if there isn't, then set the new buffer and re-enable CCDC. Signed-off-by:
-
Sakari Ailus authored
The isp was marked to have failed to stop if stopping streaming on an external subdev failed. The return value from the external subdev should be ignored instead as it is not part of the ISP and thus the ISP does not need to be reset for that reason. Signed-off-by:
-
Tomasz Maciej Nowak authored
Seems to be a clone of Logilink VG0022A. Supports DVB-C, DVB-T and DVB-T2. Only terrestrial reception was tested on Polish and Czech multiplexes. Signed-off-by:
Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Bodo Eggert authored
At least on my system with a self-made IR receiver, my kernel log is filled with: serial_ir serial_ir.0: ignoring spike: 1 1 1419988034627194ns 1419956080709377ns These messages happen at random and do not prevent the receiver from working. Also I cannot change the features of the IC, therefore they are not useful. Probably they are not useful at all. However they fill the console, they accumulate and fill the dmesg log, by doing this, they prevent me from seeing important message. Signed-off-by:
Bodo Eggert <7eggert@gmx.de> Signed-off-by:
-
James Hogan authored
I haven't been active for 18 months, and don't have the hardware set up to test the img-ir driver, so mark it as orphaned and remove myself as maintainer. I used to test this driver using a Minimorph board with Meta based TZ1090 SoC, but the Meta arch port is long gone from the kernel. The only remaining platform in-tree using this driver is the Imagination Pistachio SoC, and the only Pistachio based board with DTS in-tree (MIPS Creator Ci40) doesn't bring the IR out. However I presume the IP persists under the guardianship of Sondrel, and its possible current & future SoCs/boards may continue to use this IP. Signed-off-by:
James Hogan <jhogan@kernel.org> Cc: James Hartley <james.hartley@sondrel.com> Cc: Paul Burton <paulburton@kernel.org> Cc: linux-mips@vger.kernel.org Signed-off-by:
-
David J. Fiddes authored
This adds support for the PROlectrix DV107669 DVT-T dongle which uses an RTL2832 and FC0012 tuner. Tests: - Verified correct operation of DVB-T reception with VLC across several UK multiplexes Signed-off-by:
David J. Fiddes <D.J@fiddes.net> Signed-off-by:
-
Daniel W. S. Almeida authored
Fix checkpatch.pl error by adding a blank line Signed-off-by:
Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by:
-
Daniel W. S. Almeida authored
dvb_dummy_fe.c had all its EXPORT_SYMBOL macros located at the end of the file. Now these are located directly below the symbol they are exporting for increased readability. Suggested-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Sean Young authored
Once rc_open is called on the input device, lirc events can be delivered. Ensure lirc is ready to do so else we might get this: Registered IR keymap rc-hauppauge rc rc0: Hauppauge WinTV PVR-350 as /devices/pci0000:00/0000:00:1e.0/0000:04:00.0/i2c-0/0-0018/rc/rc0 input: Hauppauge WinTV PVR-350 as /devices/pci0000:00/0000:00:1e.0/0000:04:00.0/i2c-0/0-0018/rc/rc0/input9 BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.3.11-300.fc31.x86_64 #1 Hardware name: /DG43NB, BIOS NBG4310H.86A.0096.2009.0903.1845 09/03/2009 Workqueue: events ir_work [ir_kbd_i2c] RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 Code: a6 b4 07 00 00 49 81 c6 b8 07 00 00 55 53 e8 ba a7 9d ff 4c 89 e7 49 89 45 00 e8 5e 7a 25 00 49 8b 1e 48 89 c5 4c 39 f3 74 58 <8b> 43 38 8b 53 40 89 c1 2b 4b 3c 39 ca 72 41 21 d0 49 8b 7d 00 49 RSP: 0018:ffffaae2000b3d88 EFLAGS: 00010017 RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000019 RDX: 0000000000000001 RSI: 006e801b1f26ce6a RDI: ffff9e39797c37b4 RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: ffff9e39797c37b4 R13: ffffaae2000b3db8 R14: ffff9e39797c37b8 R15: ffff9e39797c33d8 FS: 0000000000000000(0000) GS:ffff9e397b680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000035844000 CR4: 00000000000006e0 Call Trace: ir_do_keydown+0x8e/0x2b0 rc_keydown+0x52/0xc0 ir_work+0xb8/0x130 [ir_kbd_i2c] process_one_work+0x19d/0x340 worker_thread+0x50/0x3b0 kthread+0xfb/0x130 ? process_one_work+0x340/0x340 ? kthread_park+0x80/0x80 ret_from_fork+0x35/0x40 Modules linked in: rc_hauppauge tuner msp3400 saa7127 saa7115 ivtv(+) tveeprom cx2341x v4l2_common videodev mc i2c_algo_bit ir_kbd_i2c ip_tables firewire_ohci e1000e serio_raw firewire_core ata_generic crc_itu_t pata_acpi pata_jmicron fuse CR2: 0000000000000038 ---[ end trace c67c2697a99fa74b ]--- RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 Code: a6 b4 07 00 00 49 81 c6 b8 07 00 00 55 53 e8 ba a7 9d ff 4c 89 e7 49 89 45 00 e8 5e 7a 25 00 49 8b 1e 48 89 c5 4c 39 f3 74 58 <8b> 43 38 8b 53 40 89 c1 2b 4b 3c 39 ca 72 41 21 d0 49 8b 7d 00 49 RSP: 0018:ffffaae2000b3d88 EFLAGS: 00010017 RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000019 RDX: 0000000000000001 RSI: 006e801b1f26ce6a RDI: ffff9e39797c37b4 RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: ffff9e39797c37b4 R13: ffffaae2000b3db8 R14: ffff9e39797c37b8 R15: ffff9e39797c33d8 FS: 0000000000000000(0000) GS:ffff9e397b680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000035844000 CR4: 00000000000006e0 rc rc0: lirc_dev: driver ir_kbd_i2c registered at minor = 0, scancode receiver, no transmitter tuner-simple 0-0061: creating new instance tuner-simple 0-0061: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles)) ivtv0: Registered device video0 for encoder MPG (4096 kB) ivtv0: Registered device video32 for encoder YUV (2048 kB) ivtv0: Registered device vbi0 for encoder VBI (1024 kB) ivtv0: Registered device video24 for encoder PCM (320 kB) ivtv0: Registered device radio0 for encoder radio ivtv0: Registered device video16 for decoder MPG (1024 kB) ivtv0: Registered device vbi8 for decoder VBI (64 kB) ivtv0: Registered device vbi16 for decoder VOUT ivtv0: Registered device video48 for decoder YUV (1024 kB) Cc: stable@vger.kernel.org Tested-by:
Nick French <nickfrench@gmail.com> Reported-by:
-
Sean Young authored
This solves the following compiler warnings: drivers/media/usb/dvb-usb/cxusb.c: In function ‘cxusb_gpio_tuner’: drivers/media/usb/dvb-usb/cxusb.c:128:35: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 128 | deb_info("gpio_write failed.\n"); | ^ drivers/media/usb/dvb-usb/cxusb.c: In function ‘cxusb_bluebird_gpio_rw’: drivers/media/usb/dvb-usb/cxusb.c:145:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 145 | deb_info("bluebird_gpio_write failed.\n"); | ^ drivers/media/usb/dvb-usb/cxusb.c: In function ‘cxusb_i2c_xfer’: drivers/media/usb/dvb-usb/cxusb.c:251:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 251 | deb_i2c("i2c read may have failed\n"); | ^ drivers/media/usb/dvb-usb/cxusb.c:274:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 274 | deb_i2c("i2c write may have failed\n"); | ^ Signed-off-by: -
Sean Young authored
It is not a fatal error if reading the mac address or the remote control decoder state fails. Reported-by: syzbot+ec869945d3dde5f33b43@syzkaller.appspotmail.com Signed-off-by:
-
Sean Young authored
If usb_bulk_msg() fails, actual_length can be uninitialized. Reported-by: syzbot+9d42b7773d2fecd983ab@syzkaller.appspotmail.com Signed-off-by:
-
Sean Young authored
This results in an uninitialized variable read. Reported-by: syzbot+6bf9606ee955b646c0e1@syzkaller.appspotmail.com Signed-off-by:
-
Arnd Bergmann authored
Add support for the four new variants of ioctl commands for 64-bit time_t in v4l2_buffer. The existing v4l2_buffer32 structure for the traditional format gets changed to match the new v4l2_buffer format, and the old layout is now called v4l2_buffer32_time32. Neither of these matches the native 64-bit architecture format of v4l2_buffer, so both require special handling in compat code. Duplicating the existing handlers for the new types is a safe conversion for now, but unfortunately this may turn into a maintenance burden later. A larger-scale rework of the compat code might be a better alternative, but is out of scope of the y2038 work. Note: x32 support for v4l2_buffer32 has always been broken and remains so after this change, fixing it would have required even more duplication, and apparently nobody has cared so far. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil-cisco@xs4all.nl: remove spurious newline] Signed-off-by:
-
Arnd Bergmann authored
The native code supports the variant of struct v4l2_event for 64-bit time_t, so add the compat version as well. Here, a new incompatibility arises: while almost all 32-bit architectures now use the same layout as 64-bit architectures and the commands can simply be passed through, on x86 the internal alignment of v4l2_event is different because of the 64-bit member in v4l2_event_ctrl. To handle all architectures, this now requires defining four different versions of the structure to cover all possible combinations. The compat handling for VIDIOC_DQEVENT32 and VIDIOC_DQEVENT32_TIME32 is now inside of an #ifdef so it does not get used on architectures other than x86. Signed-off-by:
-
Arnd Bergmann authored
The v4l2_buffer structure contains a 'struct timeval' member that is defined by the user space C library, creating an ABI incompatibility when that gets updated to a 64-bit time_t. As in v4l2_event, handle this with a special case in video_put_user() and video_get_user() to replace the memcpy there. Since the structure also contains a pointer, there are now two native versions (on 32-bit systems) as well as two compat versions (on 64-bit systems), which unfortunately complicates the compat handler quite a bit. Duplicating the existing handlers for the new types is a safe conversion for now, but unfortunately this may turn into a maintenance burden later. A larger-scale rework of the compat code might be a better alternative, but is out of scope of the y2038 work. Sparc64 needs a special case because of their special suseconds_t definition. Signed-off-by:
-
Arnd Bergmann authored
The v4l2_event structure contains a 'struct timespec' member that is defined by the user space C library, creating an ABI incompatibility when that gets updated to a 64-bit time_t. While passing a 32-bit time_t here would be sufficient for CLOCK_MONOTONIC timestamps, simply redefining the structure to use the kernel's __kernel_old_timespec would not work for any library that uses a copy of the linux/videodev2.h header file rather than including the copy from the latest kernel headers. This means the kernel has to be changed to handle both versions of the structure layout on a 32-bit architecture. The easiest way to do this is during the copy from/to user space. Signed-off-by:
-
Arnd Bergmann authored
The copy-in/out portions of video_usercopy() are about to get more complex, so turn then into separate functions as a cleanup first. Signed-off-by:
-
Arnd Bergmann authored
The do_video_ioctl() compat handler converts the compat command codes into the native ones before processing further, but this causes problems for 32-bit user applications that pass a command code that matches a 64-bit native number, which will then be handled the same way. Specifically, this breaks VIDIOC_DQEVENT_TIME from user space applications with 64-bit time_t, as the structure layout is the same as the native 64-bit layout on many architectures (x86 being the notable exception). Change the handler to use the converted command code only for passing into the native ioctl handler, not for deciding on the conversion, in order to make the compat behavior match the native behavior. Actual support for the 64-bit time_t version of VIDIOC_DQEVENT_TIME and other commands still needs to be added in a separate patch. Cc: stable@vger.kernel.org Signed-off-by:
-
Arnd Bergmann authored
As a preparation for adding 64-bit time_t support in the uapi, change the drivers to no longer care about the format of the timestamp field in struct v4l2_buffer. The v4l2_timeval_to_ns() function is no longer needed in the kernel after this, but there is userspace code relying on it to be part of the uapi header. Signed-off-by:
-
Arnd Bergmann authored
The type for the timestamp in video_event was changed to 'long' a long time ago, change the documentation to match. Signed-off-by:
-
- 16 Dec, 2019 9 commits
-
-
Hans Verkuil authored
The v4l2-compliance tests failed with the touch device when multiplanar was enabled in vivid. Since it is perfectly fine to support the multiplanar API for touch, add support for this in vivid. Signed-off-by:
-
Hans Verkuil authored
There is no reason to prohibit multiplanar support for touch devices, so just allow it. Signed-off-by:
-
Hans Verkuil authored
The v4l2_buffer's 'field' value was never initialized in vivid for the touch capture device, causing v4l2-compliance errors. Set it to NONE. Signed-off-by:
-
Hans Verkuil authored
Log (if debug > 0) when a CEC message is received. This is done for transmits already, so it makes sense to do the same for receives. Signed-off-by:
-
Hans Verkuil authored
Don't schedule the next ping before the current ping is sent, schedule it after. Signed-off-by:
-
Hans Verkuil authored
Don't free everything in the disconnect callback, instead use the adap_free callback, which is called when the last open filehandle is closed. Signed-off-by:
-
Hans Verkuil authored
It turns out that received CEC messages can arrive faster than can be processed by the CEC framework, resulting in lost messages. Instead of storing only one CEC message, store up to 8. Also fix a bug where the EOM bit wasn't checked for a received message of length 1, so POLL messages weren't properly reported. Signed-off-by:
-
Hans Verkuil authored
Instead of adap_transmit waiting until the full message is transmitted (and thus hoarding the adap->lock mutex), have it kick off a transmit workqueue. This prevents adap->lock from being locked for a very long time. Also skip FAILED_ACK reports for broadcast messages: this makes no sense, and it seems a spurious message coming from the Pulse-Eight, since some time later I see the SUCCEEDED message. Signed-off-by:
-
Hans Verkuil authored
Instead of translating work_result to a transmit_done status in pulse8_irq_work_handler(), pass the CEC_TX_STATUS via a new tx_done_status field. Signed-off-by:
-
