- 03 Jan, 2020 22 commits
-
-
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 <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 18 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:
-
Hans Verkuil authored
Use debug level 2 to show the low-level Pulse-Eight commands. Also show the message to transmit on debug level 1 and add a debug log to show where the transmit failed. Signed-off-by:
-
Hans Verkuil authored
Drop the write_lock, rename config_lock to plain lock since this now locks access to the adapter. Use 'lock' when transmitting a message, ensuring that nothing interferes with the transmit. Signed-off-by:
-
Hans Verkuil authored
Reorganize the order of the functions in the source, going from low-level to high-level. No functional changes were made. Signed-off-by:
-
Hans Verkuil authored
Add and use pulse8_msgname() to show the message codes as a human readable text instead of a number. Signed-off-by:
-
Nathan Chancellor authored
When building with Clang + -Wtautological-constant-compare, several of the ivtv and cx18 drivers warn along the lines of: drivers/media/pci/cx18/cx18-driver.c:1005:21: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL, ^ drivers/media/pci/cx18/cx18-cards.h:18:37: note: expanded from macro 'CX18_HW_GPIO_RESET_CTRL' #define CX18_HW_GPIO_RESET_CTRL (1 << 6) ^ 1 warning generated. This warning happens because the shift operation is implicitly converted to a boolean in v4l2_device_mask_call_all before being negated. This can be solved by just comparing the mask result to 0 explicitly so that there is no boolean conversion. The ultimate goal is to enable -Wtautological-compare globally because there are several subwarnings that would be helpful to have. For visual consistency and avoidance of these warnings in the future, all of the implicitly boolean conversions in the v4l2_device macros are converted to explicit ones as well. Link: https://github.com/ClangBuiltLinux/linux/issues/752Reviewed-by:Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Ezequiel Garcia authored
The Hantro G1 decoder is able to enable a post-processor on the decoding pipeline, which can be used to perform scaling and color conversion. The post-processor is integrated to the decoder, and it's possible to use it in a way that is completely transparent to the user. This commit enables color conversion via post-processing, which means the driver now exposes YUV packed, in addition to NV12. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
hantro_prepare_run() and hantro_finish_run() are slightly misleading, so let's rename it to something a bit more clear. Signed-off-by:
-
Ezequiel Garcia authored
Format negotiation helpers, hantro_find_format() and hantro_get_default_fmt() can be simplified, making the code a little bit clearer. More importantly, this change is preparation work for the post-processor usage. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
-
Ezequiel Garcia authored
It has been decided to use the ENUM_FMT index value as a hint for driver preference. This is defined purposedly in a very liberal way, letting drivers define what "preference" means. For instance, the Hantro VPU driver indicates additional processing to output a given format, and thus implicates more CPU usage, which is enumerated after native (non-processed) formats. Signed-off-by:
-
