- 11 Mar, 2021 40 commits
-
-
Dafna Hirschfeld authored
There is a repeating code pattern: if (a || b) { if (a) ... if (b) ... } In this pattern, the first 'if' is redundant. The code can be replaced with: if (a) ... if (b) ... Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Arnd Bergmann authored
The mtk-smi driver can now be built as a loadable module, but this leads to a build time regression when the drivers that depend on it are built-in: aarch64-linux-ld: drivers/media/platform/mtk-mdp/mtk_mdp_comp.o: in function `mtk_mdp_comp_clock_on': mtk_mdp_comp.c:(.text.mtk_mdp_comp_clock_on+0x54): undefined reference to `mtk_smi_larb_get' aarch64-linux-ld: drivers/media/platform/mtk-mdp/mtk_mdp_comp.o: in function `mtk_mdp_comp_clock_off': mtk_mdp_comp.c:(.text.mtk_mdp_comp_clock_off+0x12c): undefined reference to `mtk_smi_larb_put' Add a dependency on the interface, but keep allowing compile-testing without that driver, as it was originally intended. Fixes: 50fc8d92 ("memory: mtk-smi: Allow building as module") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Julian Braha authored
When STA2X11_VIP is enabled, and GPIOLIB is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for VIDEO_ADV7180 Depends on [n]: MEDIA_SUPPORT [=y] && GPIOLIB [=n] && VIDEO_V4L2 [=y] && I2C [=y] Selected by [y]: - STA2X11_VIP [=y] && MEDIA_SUPPORT [=y] && MEDIA_PCI_SUPPORT [=y] && MEDIA_CAMERA_SUPPORT [=y] && PCI [=y] && VIDEO_V4L2 [=y] && VIRT_TO_BUS [=y] && I2C [=y] && (STA2X11 [=n] || COMPILE_TEST [=y]) && MEDIA_SUBDRV_AUTOSELECT [=y] This is because STA2X11_VIP selects VIDEO_ADV7180 without selecting or depending on GPIOLIB, despite VIDEO_ADV7180 depending on GPIOLIB. Signed-off-by: Julian Braha <julianbraha@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
dingsenjie authored
Remove superfluous "breaks", as there is a "return" before them. Signed-off-by: dingsenjie <dingsenjie@yulong.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
dingsenjie authored
Remove superfluous "breaks", as there is a "return" before them. Signed-off-by: dingsenjie <dingsenjie@yulong.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
zuoqilin authored
remove unneeded variable: "ret" Signed-off-by: zuoqilin <zuoqilin@yulong.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Yang Li authored
fixed the following coccicheck: ./drivers/media/pci/solo6x10/solo6x10-core.c:371:60-61: WARNING opportunity for kobj_to_dev() Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Vladimir Lypak authored
Because of u32 type being used to store pixel clock rate, expression used to calculate pipeline clocks (pixel_clock * bpp) produces wrong value due to integer overflow. This patch changes data type used to store, pass and retrieve pixel_clock from u32 to u64 to make this mistake less likely to be repeated in the future. Signed-off-by: Vladimir Lypak <junak.pub@gmail.com> Acked-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrey Konovalov authored
There are places in the camss driver where camss_get_pixel_clock() is called to get the pixel rate (using V4L2_CID_PIXEL_RATE control) and to calculate the link frequency from it. There is a case when this would not work: when V4L2_CID_PIXEL_RATE gets the rate at which the pixels are read (sampled) from the sensor's pixel array, and this rate is different from the pixel transmission rate over the CSI link, the link frequency value can't be calculated from the pixel rate. One needs to use V4L2_CID_LINK_FREQ to get the link frequency in this case. Replace such calls to camss_get_pixel_clock() with calls to a wrapper around v4l2_get_link_freq(). v4l2_get_link_freq() tries V4L2_CID_LINK_FREQ first, and if it is not implemented by the camera sensor driver, falls back to V4L2_CID_PIXEL_RATE to calculate the link frequency value from. Calls to camss_get_pixel_clock() from vfe_[check,set]_clock_rates() are left intact as it looks like this VFE clock does depend on the rate the pixel samples comes out of the camera sensor, not on the frequency at which the link between the sensor and the CSI receiver operates. Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Acked-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrey Konovalov authored
Print a warning if V4L2_CID_LINK_FREQ control is not implemented. Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bhaskar Chowdhury authored
s/minimze/minimize/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bhaskar Chowdhury authored
s/minimze/minimize/ s/initallize/initialize/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bhaskar Chowdhury authored
s/minimze/minimize/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Julia Lawall authored
Use getter and setter functions, for a variety of data types. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Nicolas Dufresne authored
As some hardware have a knob to enable or disable emulation prevention bytes removal, driver writers ended up wondering what exactly the START_CODE_NONE modes meant in this regards. This patch clarify what is expected with a reference to the specification. Reported-by: John Cox <jc@kynesim.co.uk> Signed-off-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>
-
Rikard Falkeborn authored
Constify two static structs which are never modified to allow the compiler to put them in read-only memory. The only usage of norm_params is only read from it in usbtv_configure_for_norm(). Making it const shrinks the resulting ko-file with 300 bytes (tested with gcc 10). The only usage of usbtv_ioctl_ops is to put its address to the ioctl_ops field in the video_device struct. Making it const moves ~1kb to read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bhaskar Chowdhury authored
Several spelling fixes throughout the file. Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Colin Ian King authored
Don't populate the const arrays on the stack but instead it static. Makes the object code smaller by 8 bytes: Before: text data bss dec hex filename 12504 4568 0 17072 42b0 media/platform/sti/hva/hva-h264.o After: text data bss dec hex filename 12272 4792 0 17064 42a8 media/platform/sti/hva/hva-h264.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andrzej Pietrasiewicz authored
struct v4l2_ctrl_h264_pps members obviously match picture parameter syntax, not sequence parameter syntax. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Bastien Nocera authored
Captured using a raw IR receiver. Manual linked in the remote definition itself. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Takashi Iwai authored
dvb_usb_device_init() copies the properties to the own data, so that the callers can release the original properties later (as done in the commit 299c7007 ("media: dw2102: Fix memleak on sequence of probes")). However, it also stores dev->desc pointer that is a reference to the original properties data. Since dev->desc is referred later, it may result in use-after-free, in the worst case, leading to a kernel Oops as reported. This patch addresses the problem by allocating and copying the properties at first, then get the desc from the copied properties. Reported-and-tested-by: Stefan Seyfried <seife+kernel@b1-systems.com> BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1181104Reviewed-by: Robert Foss <robert.foss@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Takashi Iwai authored
dvb_usb_device_init() allocates a dvb_usb_device object, but it doesn't release the object by itself even at errors. The object is released in the callee side (dvb_usb_init()) in some error cases via dvb_usb_exit() call, but it also missed the object free in other error paths. And, the caller (it's only dvb_usb_device_init()) doesn't seem caring the resource management as well, hence those memories are leaked. This patch assures releasing the memory at the error path in dvb_usb_device_init(). Now dvb_usb_init() frees the resources it allocated but leaves the passed dvb_usb_device object intact. In turn, the dvb_usb_device object is released in dvb_usb_device_init() instead. We could use dvb_usb_exit() function for releasing everything in the callee (as it was used for some error cases in the original code), but releasing the passed object in the callee is non-intuitive and error-prone. So I took this approach (which is more standard in Linus kernel code) although it ended with a bit more open codes. Along with the change, the patch makes sure that USB intfdata is reset and don't return the bogus pointer to the caller of dvb_usb_device_init() at the error path, too. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Brad Love authored
Manufacturing has switched from ISOC to bulk transport, the pid has accordingly changed to signify this. 0x2013:0x0461 is an ISOC 461e v2 0x2013:0x8461 is a bulk transport 461e v2 Signed-off-by: Brad Love <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Brad Love authored
Manufacturing has switched from ISOC to bulk transport, the pid has accordingly changed to signify this. 0x2013:0x0258 is an ISOC 461e 0x2013:0x8258 is a bulk transport 461e Signed-off-by: Brad Love <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Christian Hewitt authored
Add a keymap and bindings for the simple IR (NEC) remote used with Minix 'NEO' branded Android STB devices. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
The in_use variable is set to true when a lirc file is opened, and ir transmit can only be done by writing to a lirc file descriptor. As a result when in_use is read, it is always true, so we might as well remove it. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
It's best if this condition is reported. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
The carrier, duty cycle etc are not device dependent, and they can be changed at runtime. By moving them into the allocated struct, we can make the device specific structures smaller, and we no longer need to copy the struct. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
The lirc ioctls should be used for this, not module parameters. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
Remove lots of superfluous debug messages which just log the function name. Also, there is no need to announce the various parameters of the device. This can be discovered via lirc ioctl if needed. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
This ensure that the rc device shows up correctly in sysfs. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
These fields are not referenced anywhere. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Daode Huang authored
It is redundant to do irqsave and irqrestore in hardIRQ context. Signed-off-by: Daode Huang <huangdaode@huawei.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Sphinx doesn't allow placing those cross-reference identifies everywhere. Misplacing them cause those warnings: Documentation/userspace-api/media/v4l/hist-v4l2.rst:818: WARNING: undefined label: control-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/hist-v4l2.rst:853: WARNING: undefined label: reserved-formats (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst:47: WARNING: undefined label: reserved-formats (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/subdev-formats.rst:39: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/subdev-formats.rst:53: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/subdev-formats.rst:67: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/subdev-formats.rst:83: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/subdev-formats.rst:97: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/subdev-formats.rst:140: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-decoder-cmd.rst:75: WARNING: undefined label: decoder-cmds (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-dqevent.rst:234: WARNING: undefined label: control-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-g-dv-timings.rst:156: WARNING: undefined label: dv-bt-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst:41: WARNING: undefined label: ctrl-class (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst:246: WARNING: undefined label: ctrl-class (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst:269: WARNING: undefined label: ctrl-class (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-g-modulator.rst:100: WARNING: undefined label: modulator-txsubchans (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-g-tuner.rst:119: WARNING: undefined label: tuner-rxsubchans (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst:167: WARNING: undefined label: control-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst:245: WARNING: undefined label: control-flags (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst:396: WARNING: undefined label: ctrl-class (if the link has no caption the label must precede a section header) Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst:73: WARNING: undefined label: v4l2-subdev-mbus-code-flags (if the link has no caption the label must precede a section header) Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
At least at pdf output, part of the VBI drawings are not visible. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
It makes more sense to place the xvideo example at the body, keeping the footnote only to justify the design decision. While this makes the text better, it also fixes the PDF output. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
There are lots of tables that are not properly displayed in LaTeX/PDF. Fix the tablecolumns, add longtable where needed and LaTeX formatting macros, in order to address such issues. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Add missing format macros for the tables there to be properly output. While here, also remove the empty ".. note::" markup. It should be noticed that ".. [1]" markups will generate footnotes, and not a note within the main text body. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
The Picture Parameter Set Flags table for H-264 doesn't output well on PDF. There are missing format instructions for LaTeX, and the columns are too long. Reduce the size of the second column, as 16 bits is more than enough for the current flags usage, and add the needed bits for it to be properly output in PDF format. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Sphinx/LaTeX doesn't work well with literal blocks. Due to that, V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF ends being writing outside the table (and even outside the page). We need to not only change the table size and font size, but also to change the message, in order to avoid this bug. So, improve the text a little bit, while ensuring that the literal will be written at the beginning of the second line. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-