Some devices can implement a physical switch to disable the input of the
camera on demand. Think of it like an elegant privacy sticker.
The system can read the status of the privacy switch via a GPIO.
It is important to know the status of the switch, e.g. to notify the
user when the camera will produce black frames and a videochat
application is used.
In some systems, the GPIO is connected to the main SoC instead of the
camera controller, with the connection reported by the system firmware
(ACPI or DT). In that case, the UVC device isn't aware of the GPIO. We
need to implement a virtual entity to handle the GPIO fully on the
driver side.
For example, for ACPI-based systems, the GPIO is reported in the USB
device object:
Scope (\_SB.PCI0.XHCI.RHUB.HS07)
{
/.../
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.PCI0.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0064
}
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"privacy-gpio",
Package (0x04)
{
\_SB.PCI0.XHCI.RHUB.HS07,
Zero,
Zero,
One
}
}
}
})
}
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Allows controls to get their properties and current value
from an entity-defined function instead of via a query to the USB
device.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Split the functionality of void uvc_ctrl_status_event_work in two, so it
can be called by functions outside interrupt context and not part of an
URB.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Increase the size of the id, to avoid collisions with entities
implemented by the driver that are not part of the UVC device.
Entities exposed by the UVC device use IDs 0-255, extra entities
implemented by the driver (such as the GPIO entity) use IDs 256 and
up.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The Renkforce RF AC4K 300 Action Cam 4K reports invalid bFormatIndex and
bFrameIndex values when negotiating the video probe and commit controls.
The UVC descriptors report a single supported format and frame size,
with bFormatIndex and bFrameIndex both equal to 2, but the video probe
and commit controls report bFormatIndex and bFrameIndex set to 1.
The device otherwise operates correctly, but the driver rejects the
values and fails the format try operation. Fix it by ignoring the
invalid indices, and assuming that the format and frame requested by the
driver are accepted by the device.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=210767
Fixes: 8a652a17e3 ("media: uvcvideo: Ensure all probed info is returned to v4l2")
Reported-by: Till Dörges <doerges@pre-sense.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The Shenzhen Aoni Electronic Co.,Ltd 2K FHD camera reports a UVC 1.10
version, but implements UVC 1.0a as shown by the UVC probe control being
26 bytes long. Force the UVC version for that device.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: Doncho Minkov <donchominkov@gmail.com>
Tested-by: Doncho Minkov <donchominkov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Syzbot discovered that the probe error handling doesn't clean up the
resources allocated in zr364xx_board_init(). There are several
related bugs in this code so I have re-written the error handling.
1) Introduce a new function zr364xx_board_uninit() which cleans up
the resources in zr364xx_board_init().
2) In zr364xx_board_init() if the call to zr364xx_start_readpipe()
fails then release the "cam->buffer.frame[i].lpvbits" memory
before returning. This way every function either allocates
everything successfully or it cleans up after itself.
3) Re-write the probe function so that each failure path goto frees
the most recent allocation. That way we don't free anything
before it has been allocated and we can also verify that
everything is freed.
4) Originally, in the probe function the "cam->v4l2_dev.release"
pointer was set to "zr364xx_release" near the start but I moved
that assignment to the end, after everything had succeeded. The
release function was never actually called during the probe cleanup
process, but with this change I wanted to make it clear that we
don't want to call zr364xx_release() until everything is
allocated successfully.
Next I re-wrote the zr364xx_release() function. Ideally this would
have been a simple matter of copy and pasting the cleanup code from
probe and adding an additional call to video_unregister_device(). But
there are a couple quirks to note.
1) The probe function does not call videobuf_mmap_free() and I don't
know where the videobuf_mmap is allocated. I left the code as-is to
avoid introducing a bug in code I don't understand.
2) The zr364xx_board_uninit() has a call to zr364xx_stop_readpipe()
which is a change from the original behavior with regards to
unloading the driver. Calling zr364xx_stop_readpipe() on a stopped
pipe is not a problem so this is safe and is potentially a bugfix.
Reported-by: syzbot+b4d54814b339b5c6bbd4@syzkaller.appspotmail.com
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently, the CSI2 subdevice is using the data-lanes from the
neareast endpoint to config the CSI2 lanes.
While this may work, the proper way to configure the hardware is
to obtain the remote subdevice in v4l2_async_notifier_operations.bound(),
and then call get_mbus_config using the remote subdevice to get
the active lanes.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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>
Current link died, according to Wayback Machine, back in 2017. And the
website is completely down since 2019. Moreover, there was a custom
cover on that PDF, i.e. it was modified.
According to HDMI licence agreement (LA), HDMI specification and technical
information are supposed to be hosted on www.hdmi.org exclusively, and not
redistributed by third-parties.
Sure, there are still many more or less reliable "mirrors" out there with
a direct download straight from a search engine's page. However, for
example, from FPGA4fun[1] website it was removed "per HDMI LA request".
Unfortunately, the official download page is protected by email CAPTCHA,
but that seems to be the only legit way to obtain a copy.
[1] https://www.fpga4fun.com/HDMI.html
Signed-off-by: ivan tkachenko <me@ratijas.tk>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The event route for VIN running with a media controller (Gen3) is
incorrect as all events are only routed to the video device that are
used to register the async notifier.
Remedy this be examining which subdevice generated the event and route
it to all VIN(s) that are connected to that subdevice.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-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>
When DEBUG is defined this error occurs
drivers/media/platform/pxa_camera.c:1410:7: error:
‘i’ undeclared (first use in this function)
for (i = 0; i < vb->num_planes; i++)
^
The variable 'i' is missing, so declare it.
Fixes: 6f28435d1c ("[media] media: platform: pxa_camera: trivial move of functions")
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>
When DEBUG is defined this error occurs
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c:306:41:
error: ‘i’ undeclared (first use in this function)
mtk_v4l2_debug(2, "reg[%d] base=0x%p", i, dev->reg_base[VENC_SYS]);
Reviewing the old line
mtk_v4l2_debug(2, "reg[%d] base=0x%p", i, dev->reg_base[i]);
All the i's need to be changed to VENC_SYS.
Fix a similar error for VENC_LT_SYS.
Fixes: 0dc4b32861 ("media: mtk-vcodec: venc: support SCP firmware")
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>
This function looks like a realloc.
However, if 'risc->cpu != NULL', the memory will be freed, but never
reallocated with the bigger 'size'.
Explicitly set 'risc->cpu' to NULL, so that the reallocation is
correctly performed a few lines below.
[hverkuil: NULL != risc->cpu -> risc->cpu]
Fixes: 5ede94c705 ("[media] cx25821: remove bogus btcx_risc dependency)
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
A number of remote control drivers require the bitreverse
helper, and run into a link error when it is disabled:
arm-linux-gnueabi-ld: drivers/media/rc/img-ir/img-ir-nec.o: in function `img_ir_nec_scancode':
img-ir-nec.c:(.text+0x10c): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: drivers/media/rc/img-ir/img-ir-nec.o: in function `img_ir_nec_filter':
img-ir-nec.c:(.text+0x2dc): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: drivers/media/usb/cx231xx/cx231xx-input.o: in function `get_key_isdbt':
cx231xx-input.c:(.text+0x38c): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: drivers/media/usb/em28xx/em28xx-input.o: in function `em28xx_get_key_em_haup':
em28xx-input.c:(.text+0x1704): undefined reference to `byte_rev_table'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sean Young <sean@mess.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix to return a negative error code from the error handling case
instead of 0 in function qm1d1c0042_init(), as done elsewhere
in this function.
Fixes: ab4d14528f ("[media] em28xx: add support for PLEX PX-BCUD (ISDB-S)")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Luo Meng <luomeng12@huawei.com>
Acked-by: Akihiro Tsukada <tskd08@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The "pad" variable is a user controlled string and we haven't properly
clamped it at this point so the debug code could print from beyond the
of the array.
Fixes: a49d25364d ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
According to v4l2 request api specifications, it's allowed to skip
control if its content isn't changed for performance reasons. Cedrus
driver predates that, so it has implemented mechanism to check if all
required controls are included in one request.
Conform to specifications with removing that mechanism.
Note that this mechanism with static required flag isn't very good
anyway because need for control is usually signaled in other controls.
Fixes: 50e761516f ("media: platform: Add Cedrus VPU decoder driver")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Print a message when the driver is removed so that we get some
visual confirmation when unbinding vidtv.
Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Change from "vidtv_bridge" to simply "vidtv" so that vidtv looks
more similar to the other media virtual drivers in /sys/bus/platform.
Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reinstate sysfs bind attrs so that vidtv can be bound and unbound
via sysfs. This is useful for automated regression testing in
userspace.
Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add media controller support when CONFIG_MEDIA_CONTROLLER_DVB is set
so that, in the future, a test sequence in v4l-utils can be written
without having to know which /dev/fooX device should be used.
[mchehab: avoided usage of C99 comments]
Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Commit 3d1387b3b8 ("media: vidtv: fix some warnings") replaced
the unused flexible array member at the end of struct vidtv_mpeg_ts
with a pointer. This broke the 188-byte alignment since the struct
no longer was 4 bytes in size.
Fix this by removing this field entirely.
Fixes: 3d1387b3b8 ("media: vidtv: fix some warnings")
Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The PMT write function was refactored and this broke the CRC computation.
Fix it.
Fixes: db9569f67e ("media: vidtv: cleanup PMT write table function")
Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
By adding this cast '(__force __le16)' this sparse warning
is fixed:
drivers/media/i2c/ov02a10.c:391:19: warning: cast to restricted __le16
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix two smatch warnings:
drivers/staging/media/atomisp//pci/ia_css_firmware.h:52:29: warning: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration
drivers/staging/media/atomisp//pci/ia_css_control.h:49:24: warning: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration
Add '#include <linux/device.h>' to ia_css_firmware.h so struct device is defined.
ia_css_control.h includes ia_css_firmware.h, so it is sufficient to
just modify ia_css_firmware.h.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fixes this smatch warning:
drivers/media/dvb-frontends/rtl2832.c:702 rtl2832_read_status() warn: missing error code 'ret'
'ret' is indeed not set, so set it to -EINVAL so a proper error
code is returned.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
