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>
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: 28c7afb07c ("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 f0c15b360f ("media: ir_toy: prevent device from hanging during
transmit") removed a cpu_to_be16() cast, which causes a sparse warning.
Fixes: f0c15b360f ("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: 68f5d3f3b6 ("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>
Except for VP8 probability coefficients buffer, all other buffers are
never accessed by CPU. That allows us to mark them with
DMA_ATTR_NO_KERNEL_MAPPING flag. This helps with decoding big (like 4k)
videos on 32-bit ARM platforms where default vmalloc size is relatively
small - 240 MiB. Since auxiliary buffer are not yet efficiently
allocated, this can be easily exceeded. Even if allocation is optimized,
4k videos will still often exceed this limit.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The mem-to-mem stateless decoder API specifies support for dynamic
resolution changes. In particular, the decoder should accept format
changes on the OUTPUT queue even when buffers have been allocated,
as long as it is not streaming.
Relax restrictions for S_FMT as described in the previous paragraph,
and as long as the codec format remains the same. This aligns it with
the Hantro and Cedrus decoders. This change was mostly based on commit
ae02d49493 ("media: hantro: Fix s_fmt for dynamic resolution changes").
Since rkvdec_s_fmt() is now just a wrapper around the output/capture
variants without any additional shared functionality, drop the wrapper
and call the respective functions directly.
Fixes: cd33c83044 ("media: rkvdec: Add the rkvdec driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The rkvdec H.264 decoder currently overrides sizeimage for the output
format. This causes issues when userspace requires and requests a larger
buffer, but ends up with one of insufficient size.
Instead, only provide a default size if none was requested. This fixes
the video_decode_accelerator_tests from Chromium failing on the first
frame due to insufficient buffer space. It also aligns the behavior
of the rkvdec driver with the Hantro and Cedrus drivers.
Fixes: cd33c83044 ("media: rkvdec: Add the rkvdec driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
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>
Jeff is leaving Google so Joe will take over.
Signed-off-by: Jeff Chase <jnchase@google.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Confirmed to work with ADV7610 HDMI receiver.
Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
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>
ADV7610 is another HDMI receiver chip, very similar to
the ADV7611. 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>
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>
I came across a link failure from randconfig builds:
x86_64-linux-ld: drivers/media/i2c/ths8200.o: in function `ths8200_remove':
ths8200.c:(.text+0x491): undefined reference to `v4l2_async_unregister_subdev'
x86_64-linux-ld: drivers/media/i2c/ths8200.o: in function `ths8200_probe':
ths8200.c:(.text+0xe49): undefined reference to `v4l2_async_register_subdev'
x86_64-linux-ld: drivers/media/i2c/tw9910.o: in function `tw9910_remove':
tw9910.c:(.text+0x467): undefined reference to `v4l2_async_unregister_subdev'
x86_64-linux-ld: drivers/media/i2c/tw9910.o: in function `tw9910_probe':
tw9910.c:(.text+0x1123): undefined reference to `v4l2_async_register_subdev'
These clearly lack a 'select' statement, but I don't know why
this started happening only now. I had a bit of a look around to find
other configs that have the same problem, but could not come up with
a reliable way and found nothing else through experimentation.
It is likely that other symbols like these exist that need an extra
select.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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>
Adding kfree(dvb) to vidtv_bridge_remove() will remove the memory
too soon: if an application still has an open filehandle to the device
when the driver is unloaded, then when that filehandle is closed, a
use-after-free access takes place to the freed memory.
Move the kfree(dvb) to vidtv_bridge_dev_release() instead.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 76e21bb8be ("media: vidtv: Fix memory leak in remove")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If v4l2_ctrl_new_custom fails in cedrus_init_ctrls the error path will
free ctx->ctrls, which is also freed in cedrus release. Fix this by
setting ctx->ctrls to NULL instead of inadvertently removing kfree
calls.
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
I have not been able to give dvb the attention it needs, and now I have
even less time. Of course I will continue to maintain rc-core (infrared).
Unfortunately this means that dvb will have maintainance issues.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In dibusb_read_eeprom_byte(), if dibusb_i2c_msg() fails, val gets
assigned an value that's not properly initialized.
Using kzalloc() in place of kmalloc() for the buffer fixes this issue,
as the val can now be set to 0 in the event dibusb_i2c_msg() fails.
Reported-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com
Tested-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com
Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
After freed the dev->urb_list, we should set it to NULL as well as set
counter to zero.
Requested-by: Sean Young <sean@mess.org>
Signed-off-by: Nil Yi <teroincn@163.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
mn88443x_cmn_power_on() did not handle possible errors of
clk_prepare_enable() and always finished successfully so that its caller
mn88443x_probe() did not care about failed preparing/enabling of clocks
as well.
Add missed error handling in both mn88443x_cmn_power_on() and
mn88443x_probe(). This required to change the return value of the former
from "void" to "int".
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 0f408ce894 ("media: dvb-frontends: add Socionext MN88443x ISDB-S/T demodulator driver")
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Don't populate the read-only arrays on the stack but instead them
static const. Also makes the object code smaller by 154 bytes:
Before:
text data bss dec hex filename
42949 22424 0 65373 ff5d media/dvb-frontends/mb86a20s.o
After:
text data bss dec hex filename
42731 22488 0 65219 fec3 media/dvb-frontends/mb86a20s.o
(gcc version 11.2.0)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use v4l2 control API helpers to support the events.
Fixes v4l2-compliance:
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use v4l2 control API helpers to support the events.
Fixes v4l2-compliance:
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use v4l2 control API helpers to support the events.
Fixes v4l2-compliance:
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
bus_info field had a different value for the media entity and the video
device.
Fixes v4l2-compliance:
v4l2-compliance.cpp(637): media bus_info 'PCI:0000:00:05.0' differs from
V4L2 bus_info 'PCI:viewfinder'
Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
For a try_fmt call, the node noes not need to be enabled.
Fixes v4l2-compliance
fail: v4l2-test-formats.cpp(717): Video Output Multiplanar is valid, but
no TRY_FMT was implemented
test VIDIOC_TRY_FMT: FAIL
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The initial format did not have a valid size.
Fixes v4l2-compliance:
fail: v4l2-test-formats.cpp(723): Video Output Multiplanar:
TRY_FMT(G_FMT) != G_FMT
test VIDIOC_TRY_FMT: FAIL
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move the calculation to an inline function, to it can be used by other
parts of the driver.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If num_planes is different than zero num_planes and sizes must be
checked to support the format.
Fix the following v4l2-compliance error:
Buffer ioctls (Input 0):
fail: v4l2-test-buffers.cpp(717): q.create_bufs(node, 1, &fmt) != EINVAL
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a V4L2 driver for Renesas R-Car Image Signal Processor. The driver
supports the R-Car V3U SoC where the ISP IP sits between the R-Car CSI-2
receiver and VIN and filters the CSI-2 data based on VC/DT and directs
the video stream to different VIN IPs.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
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>
The only usage of imgu_subdev_internal_ops is to assign its address to
the internal_ops field in the v4l2_subdev struct, which is a pointer to
const v4l2_subdev_internal_ops. Make it const to allow the compiler to
put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add MIPI CCS compliant devices, a few Sony IMX, Hynix Hi-846 and
Omnivision ov13b10 sensors and the DW9768 lens driver to the list of
supported devices. Also drop SMIA since as a standard it is obsolete.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add the SK Hynix Hi-846 8M Pixel CMOS image sensor to the i2c-cardlist.
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>
The SK Hynix Hi-846 is a 1/4" 8M Pixel CMOS Image Sensor. It supports
usual features like I2C control, CSI-2 for frame data, digital/analog
gain control or test patterns.
This driver supports the 640x480, 1280x720 and 1632x1224 resolution
modes. It supports runtime PM in order not to draw any unnecessary power.
The part is also called YACG4D0C9SHC and a datasheet can be found at
https://product.skhynix.com/products/cis/cis.go
The large sets of partly undocumented register values are for example
found when searching for the hi846_mipi_raw_Sensor.c Android driver.
Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Document the bindings used for the SK Hynix Hi-846 CMOS camera driver.
Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Reviewed-by: Laurent Pinchart <laurent.pinchart@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>
SK Hynix built the already supported hi556 sensor (and probably much
more). For more information, see https://www.skhynix.com/
Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
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>
The sensor orientation is read from the _PLC ACPI buffer and converted to a v4l2
format.
The sensor rotation is read from the SSDB ACPI buffer and converted into
degrees.
Signed-off-by: Fabian Wüthrich <me@fabwu.ch>
Reviewed-by: Daniel Scally <djrscally@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
