- Nov 19, 2021
-
-
Similar to other drivers, this should fix a Clang compilar warning when building without CONFIG_OF in which case of_match_ptr() is NULL and the const struct we would use otherwise is unused. Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Include the more portable property.h instead of the OF specific of_graph.h Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- Nov 10, 2021
-
-
When the reply for a non-blocking transmit arrives, the sequence field for that reply was never filled in, so userspace would have no way of associating the reply to the original transmit. Copy the sequence field to ensure that this is now possible. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 0dbacebe ([media] cec: move the CEC framework out of staging and to media) Cc: <stable@vger.kernel.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Commit a4b83deb ("media: videobuf2: rework vb2_mem_ops API") added a new vb member to struct vb2_dma_sg_buf, but it only added code setting this to the vb2_dma_sg_alloc() function and not to the vb2_dma_sg_get_userptr() and vb2_dma_sg_attach_dmabuf() which also create vb2_dma_sg_buf objects. This is causing a crash due to a NULL pointer deref when using libcamera on devices with an Intel IPU3 (qcam app). Fix these crashes by assigning buf->vb in the other 2 functions too, note libcamera tests the vb2_dma_sg_get_userptr() path, the change to the vb2_dma_sg_attach_dmabuf() path is untested. Fixes: a4b83deb ("media: videobuf2: rework vb2_mem_ops API") Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
My previous bugfix addressed an API inconsistency found by syzbot, and it correctly fixed the issue on x86-64 machines, which now behave correctly for both native and compat tasks. Unfortunately, John found that the patch broke compat mode on all other architectures, as they can no longer rely on the VIDIOC_DQEVENT_TIME32 code from the native handler as a fallback in the compat code. The best way I can see for addressing this is to generalize the VIDIOC_DQEVENT32_TIME32 code from x86 and use that for all architectures, leaving only the VIDIOC_DQEVENT32 variant as x86 specific. The original code was trying to be clever and use the same conversion helper for native 32-bit code and compat mode, but that turned out to be too obscure so even I missed that bit I had introduced myself when I made the fix. Fixes: c344f07a ("media: v4l2-core: ignore native time32 ioctls on 64-bit") Reported-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- Nov 09, 2021
-
-
Andy Shevchenko authored
When kernel.h is used in the headers it adds a lot into dependency hell, especially when there are circular dependencies are involved. Replace kernel.h inclusion with the list of what is really being used. [akpm@linux-foundation.org: cxd2880_common.h needs bits.h for GENMASK()] [andriy.shevchenko@linux.intel.com: delay.h: fix for removed kernel.h] Link: https://lkml.kernel.org/r/20211028170143.56523-1-andriy.shevchenko@linux.intel.com [akpm@linux-foundation.org: include/linux/fwnode.h needs bits.h for BIT()] Link: https://lkml.kernel.org/r/20211027150324.79827-1-andriy.shevchenko@linux.intel.com Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Nov 03, 2021
-
-
Rajmohan Mani authored
Tell ACPI device PM code that the driver supports the device being in non-zero ACPI D state when the driver's probe function is entered. Signed-off-by:
Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Reviewed-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Oct 28, 2021
-
-
Jakub Kicinski authored
Commit 406f42fa ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it go through appropriate helpers. Convert media from memcpy(... 6) and memcpy(... addr_len) to eth_hw_addr_set(): @@ expression dev, np; @@ - memcpy(dev->dev_addr, np, 6) + eth_hw_addr_set(dev, np) @@ - memcpy(dev->dev_addr, np, dev->addr_len) + eth_hw_addr_set(dev, np) Make sure we don't cast off const qualifier from dev->dev_addr. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Oct 25, 2021
-
-
Greg Kroah-Hartman authored
In order to better track where in the kernel the dma-buf code is used, put the symbols in the namespace DMA_BUF and modify all users of the symbols to properly import the namespace to not break the build at the same time. Now the output of modinfo shows the use of these symbols, making it easier to watch for users over time: $ modinfo drivers/misc/fastrpc.ko | grep import import_ns: DMA_BUF Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: dri-devel@lists.freedesktop.org Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Christian König <christian.koenig@amd.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20211010124628.17691-1-gregkh@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 21, 2021
-
-
Add the SDM660 DT compatible and its resource structure in order to support the Venus IP in SDM630, SDM636, SDM660 and SDA variants. This SoC features Venus 4.4 (HFI3XX) with only one subcore, used for both encoding and decoding, and switched on with one main and one subcore dedicated GDSC. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
In existing implementation, driver is freeing and un-mapping all the decoded picture buffers(DPB) as part of dynamic resolution change(DRC) handling. As a result, when firmware try to access the DPB buffer, from previous sequence, SMMU context fault is seen due to the buffer being already unmapped. With this change, driver defines ownership of each DPB buffer. If a buffer is owned by firmware, driver would skip from un-mapping the same. Signed-off-by:
Mansur Alisha Shaik <mansur@codeaurora.org> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
According to stateful decoder docs a fatal failure of decoding (and encoding) could be recover it by closing the corresponding file handle and open new one or reinitialize decoding (and encoding) by stop streaming on both queues. In order to satisfy this requirement we add a mechanism ins sys_error_handler and corresponding decoder and encoder drivers to wait for sys_error_done waitqueue in reqbuf. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Tested-by:
Vikash Garodia <vgarodia@codeaurora.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Add a helper to mark source and destination vb2 queues fatal unrecoverable error. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Tested-by:
Vikash Garodia <vgarodia@codeaurora.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Check sys error flag for all hfi_session_xxx functions and exit with EIO in case of an error. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Tested-by:
Vikash Garodia <vgarodia@codeaurora.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Make the sys_error flag an atomic bitops in order to avoid locking in sys_error readers. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Tested-by:
Vikash Garodia <vgarodia@codeaurora.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Migrate encoder to pm-runtime autosuspend. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Tested-by:
Vikash Garodia <vgarodia@codeaurora.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- Oct 20, 2021
-
-
The vui parameters are optional. However, the vui data allows to specify the color space of the encoded video. Write the vui parameters to make sure that decoders are able to pick up the correct color space. Also implement the necessary lookup functions to convert the values from the V4L2 controls to the values specified in the hevc standard. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The NAL unit generator for HEVC does not support the generation of vui parameters. Implement it to allow drivers to set the vui parameters in the coded video stream. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Currently, the driver always writes PAL as video format into the SPS of the encoded stream. Set the video format to the default value 5 (unspecified) and use the color description that is already configured on the channel as color space. This fixes the color space definition in the coded data to reflect the configured color space of the video data that is encoded. Add lookup functions to convert the color primaries, transfer function and matrix coefficients from the V4L2 control values to the values specified in the h.264 standard. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The lookup of the h.264 or hevc values for the respective V4L2 controls is done by the driver that uses the sps/pps generator and not in the generator. Therefore, it is more intuitive to define these functions directly in the header and not in the module. Extract the functions to the headers as static inline functions. Also simplify the function name and add kernel-doc for the hevc functions. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The bit rate in the SPS can be scaled by an exponent, which allows to reduce the number of bits in the SPS in case of high bit rates. The driver did not scale the bitrate, but used a scaling exponent of 0. Fix this by properly calculating the scaling factor and writing the bit rate as value and scaling factor into the SPS. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The VCU allows to specify the QP per frame and coding unit. A buffer that specifies the QP is passed via the ep2 field in the ENCODE_FRAME message. The driver currently does not support the external QP table. Simplify the driver by not setting the ep2 fields at all. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The fields for the number of rows and columns in the encode frame response message are switched. This causes broken PPS, if the encoder uses tiles for encoding and the number of rows and columns differ. Write the fields of the response message into the correct fields of the the internal data structure when parsing the response message. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The encoder buffer can have a negative impact on the quality of the encoded video. Add a control to allow user space to disable the encoder buffer per channel if the VCU supports the encoder buffer but the quality is not sufficient. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The encoder buffer serves as a cache for reference frames during the encoding process. The encoder buffer significantly reduces the bandwidth requirement for read accesses on the AXI ports of the VCU, but slightly reduces the quality of the encoded video. The encoder buffer must be configured as a whole during the firmware initialization and later explicitly enabled for every channel that shall use the encoder buffer. Prior to firmware version 2019.2, it was necessary to explicitly set the size of the encoder buffer for every channel. Since 2019.2 it is sufficient to enable the encoder buffer and leave the rest to the firmware. Therefore, only support the encoder buffer for firmware 2019.2 and later. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The allegro driver must ensure that the mcu and core clocks are enabled and set to the expected clock rate before trying to load the firmware and to reset the MCU. Up until now, the driver assumed that the clocks are always enabled in the PL (programming logic), because the xlnx_vcu driver did not export the clocks to other drivers. This has changed and by explicitly enabling the clocks in the driver, this assumption can be dropped. It might even be possible to disable the clocks for the encoder if the encoder is not used. However, the behavior is not documented and it might be necessary to reinitialize the encoder after deactivating the clocks. Play it safe by sticking to the current behavior. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The VCU provides information about its configuration in a dedicated register space. These settings include, for example, the expected clock rates and the configuration of the encoder buffer. In the device tree, the settings are described by the "xlnx,vcu-settings" compatible. The settings are needed to correctly configure the clocks and the encoder buffer. Lookup the VCU settings in the device tree and make it accessible to the driver via a regmap. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
If the module probe finished, but the firmware initialization failed, removing the module must not revert the firmware initialization. Add a field to track the status of the firmware initialization and only roll it back, if the firmware was successfully initialized. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The mailbox is initialized after the interrupt handler is installed. As the firmware is loaded and started even later, it should not happen that the interrupt occurs without the mailbox being initialized. As the Linux Driver Verification project (linuxtesting.org) keeps reporting this as an error, add a check to ignore interrupts before the mailbox is initialized to fix this potential null pointer dereference. Reported-by:
Yuri Savinykh <s02190703@gse.cs.msu.ru> Reported-by:
Nadezda Lutovinova <lutovinova@ispras.ru> Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
- Oct 19, 2021
-
-
On an Intel NUC6iSYK, no IR is reported after a receive overflow. When a receiver overflow occurs, this condition is only cleared by reading the fifo. Make sure we read anything in the fifo. Fixes: 28c7afb0 ("media: ite-cir: check for receive overflow") Suggested-by:
Bryan Pass <bryan.pass@gmail.com> Tested-by:
Bryan Pass <bryan.pass@gmail.com> Cc: stable@vger.kernel.org> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
This driver is a port of the lirc_sir driver to rc-core. However, for this driver I could not find any hardware to test, so it was done without testing. This is a mistake. There are clear bugs in the code. For example the two arguments to ktime_us_delta() are reversed, which means the result is garbage. The driver has been in the kernel for four years, and noone has ever reported an issue. So, remove this driver. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
commit f0c15b36 ("media: ir_toy: prevent device from hanging during transmit") removed a cpu_to_be16() cast, which causes a sparse warning. Fixes: f0c15b36 ("media: ir_toy: prevent device from hanging during transmit") Reported-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Prevent the use of page table macros and types from 2 conflicting places. This fixes multiple build errors and warnings, e.g.: ../arch/x86/include/asm/pgtable_64_types.h:21:34: error: conflicting types for ‘pte_t’ typedef struct { pteval_t pte; } pte_t; ^~~~~ In file included from ../include/linux/mm_types_task.h:16:0, from ../include/linux/mm_types.h:5, from ../include/linux/buildid.h:5, from ../include/linux/module.h:14, from ../drivers/media/pci/ivtv/ivtv-driver.h:40, from ../drivers/media/pci/ivtv/ivtvfb.c:29: ../arch/um/include/asm/page.h:57:39: note: previous declaration of ‘pte_t’ was here typedef struct { unsigned long pte; } pte_t; ../arch/x86/include/asm/pgtable_types.h:284:43: error: expected ‘)’ before ‘prot’ static inline pgprot_t pgprot_nx(pgprot_t prot) ^ ../include/linux/pgtable.h:914:26: note: in definition of macro ‘pgprot_nx’ #define pgprot_nx(prot) (prot) ^~~~ In file included from ../arch/x86/include/asm/memtype.h:6:0, from ../drivers/media/pci/ivtv/ivtvfb.c:40: ../arch/x86/include/asm/pgtable_types.h:288:0: warning: "pgprot_nx" redefined #define pgprot_nx pgprot_nx ../arch/x86/include/asm/page_types.h:11:0: warning: "PAGE_SIZE" redefined #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) In file included from ../include/linux/mm_types_task.h:16:0, from ../include/linux/mm_types.h:5, from ../include/linux/buildid.h:5, from ../include/linux/module.h:14, from ../drivers/media/pci/ivtv/ivtv-driver.h:40, from ../drivers/media/pci/ivtv/ivtvfb.c:29: ../arch/um/include/asm/page.h:14:0: note: this is the location of the previous definition #define PAGE_SIZE (_AC(1, UL) << PAGE_SHIFT) Fixes: 68f5d3f3 ("um: add PCI over virtio emulation driver") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Andy Walls <awalls@md.metrocast.net> Cc: linux-um@lists.infradead.org Cc: Richard Weinberger <richard@nod.at> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Save some power by disabling/enabling the jpeg clocks with every stream stop/start. Do not use DL_FLAG_RPM_ACTIVE in mxc_jpeg_attach_pm_domains, to ensure power domains are off after probe. Signed-off-by:
Mirela Rabulea <mirela.rabulea@oss.nxp.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
ADV7610 is another HDMI receiver chip, very similar to the ADV7611. Also: print chip names in upper case. Fix an error message claiming that no ADV761x has been found, while in reality a chip different than requested (though still supported) may have been found. Tested on TinyRex BaseBoard Lite. Signed-off-by:
Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
The TDA1997x (HDMI receiver) driver currently uses a specific video format detection scheme. The frame (or field in interlaced mode), line and HSync pulse durations are compared to those of known, standard video modes. If a match is found, the mode is assumed to be detected, otherwise -ERANGE is returned (then possibly ignored). This means that: - another mode with similar timings will be detected incorrectly (e.g. 2x faster clock and lines twice as long) - non-standard modes will not work. This patch replaces this scheme with a direct read of geometry registers. This way all modes recognized by the chip are supported. In interlaced modes, the code assumes the V sync signal has the same duration for both fields. While this may be not necessarily true, I can't see any way to get the "other" V sync width. This is most probably harmless. All tests have been performed on Gateworks' Ventana GW54xx board, with a TDA19971 chip. Signed-off-by:
Krzysztof Hałasa <khalasa@piap.pl> Tested-by:
Tim Harvey <tharvey@gateworks.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Newer clang versions are suspicious of definitions that mix concatenated strings with comma-separated arrays of strings, this has found real bugs elsewhere, but this seems to be a false positive: drivers/media/usb/gspca/gl860/gl860-mi1320.c:62:37: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation] "\xd3\x02\xd4\x28\xd5\x01\xd0\x02" "\xd1\x18\xd2\xc1" ^ , drivers/media/usb/gspca/gl860/gl860-mi1320.c:62:2: note: place parentheses around the string literal to silence warning "\xd3\x02\xd4\x28\xd5\x01\xd0\x02" "\xd1\x18\xd2\xc1" Replace the string literals by compound initializers, using normal hex numbers. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Similar configuration to Kworld PC150-U. Tested: Composite, S-Video, NTSC, ATSC Unsupported: IR remote Signed-off-by:
Scott K Logan <logans@cottsay.net> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
To show video real-time information as below: Capture: Signal : Unlock Width : 1920 Height : 1080 FRC : 30 Performance: Frame# : 0 Frame Duration(ms) : Now : 0 Min : 0 Max : 0 FPS : 0 [hverkuil: make aspeed_video_proc_open() static, fixes sparse warning] Signed-off-by:
Jammy Huang <jammy_huang@aspeedtech.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
We need to always link allocated vb2_dc_buf back to vb2_buffer because we dereference vb2 in prepare() and finish() callbacks. Signed-off-by:
Sergey Senozhatsky <senozhatsky@chromium.org> Tested-by:
Chen-Yu Tsai <wenst@chromium.org> Acked-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-