- 07 Oct, 2019 9 commits
-
-
Colin Ian King authored
Don't populate the array tab on the stack but instead make it static const. Makes the object size smaller by 170 bytes in total. Before: text data bss dec hex filename 7045 1736 0 8781 224d media/dvb-frontends/cxd2820r_c.o 8800 2216 0 11016 2b08 media/dvb-frontends/cxd2820r_t.o 8981 2120 0 11101 2b5d media/dvb-frontends/cxd2820r_t2.o After: text data bss dec hex filename 6896 1832 0 8728 2218 media/dvb-frontends/cxd2820r_c.o 8651 2312 0 10963 2ad3 media/dvb-frontends/cxd2820r_t.o 8853 2184 0 11037 2b1d media/dvb-frontends/cxd2820r_t2.o (gcc version 9.2.1, amd64) 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+samsung@kernel.org>
-
Sean Young authored
Currently the IR receiver is put into idle mode after each interrupt. However longer IR like NEC can be distributed over multiple interrupts, so putting the IR into idle in the middle of such a message will break decoding. Every IR message has a trailing space of 0xbf (one less than IR_IDE_LEN{0,1} which is programmed to 0xc0). So, set the timeout to that value and rc-core will put the IR receiver into idle mode automatically. Thanks to Jan Pieter van Woerkom <jp@jpvw.nl> for providing the hardware. Signed-off-by: -
Sean Young authored
Thanks to Jan Pieter van Woerkom <jp@jpvw.nl> for providing the hardware. Signed-off-by:
-
Flavius Georgescu authored
The device it's an iMON UltraBay (0x98 in config byte) with LCD, IR and dual-knobs front panel. To work properly the device also require its own key table, and repeat suppression for all buttons. Signed-off-by:
Flavius Georgescu <pretoriano.mp@gmail.com> Co-developed-by:
Chris Vandomelen <chris@sightworks.com> Signed-off-by:
-
A Sun authored
Fix multiple cases of out of bounds (OOB) read associated with MCE device receive/input data handling. In reference for the OOB cases below, the incoming/read (byte) data format when the MCE device responds to a command is: { cmd_prefix, subcmd, data0, data1, ... } where cmd_prefix are: MCE_CMD_PORT_SYS MCE_CMD_PORT_IR and subcmd examples are: MCE_RSP_GETPORTSTATUS MCE_RSP_EQIRNUMPORTS ... Response size dynamically depends on cmd_prefix and subcmd. So data0, data1, ... may or may not be present on input. Multiple responses may return in a single receiver buffer. The trigger condition for OOB read is typically random or corrupt input data that fills the mceusb receiver buffer. Case 1: mceusb_handle_command() reads data0 (var hi) and data1 (var lo) regardless of whether the response includes such data. If { cmd_prefix, subcmd } is at the end of the receiver buffer, read past end of buffer occurs. This case was reported by KASAN: slab-out-of-bounds Read in mceusb_dev_recv https://syzkaller.appspot.com/bug?extid=c7fdb6cb36e65f2fe8c9 Fix: In mceusb_handle_command(), change variable hi and lo to pointers, and dereference only when required. Case 2: If response with data is truncated at end of buffer after { cmd_prefix, subcmd }, mceusb_handle_command() reads past end of buffer for data0, data1, ... Fix: In mceusb_process_ir_data(), check response size with remaining buffer size before invoking mceusb_handle_command(). + if (i + ir->rem < buf_len) mceusb_handle_command(ir, &ir->buf_in[i - 1]); Case 3: mceusb_handle_command() handles invalid/bad response such as { 0x??, MCE_RSP_GETPORTSTATUS } of length 2 as a response { MCE_CMD_PORT_SYS, MCE_RSP_GETPORTSTATUS, data0, ... } of length 7. Read OOB occurs for non-existent data0, data1, ... Cause is mceusb_handle_command() does not check cmd_prefix value. Fix: mceusb_handle_command() must test both cmd_prefix and subcmd. Case 4: mceusb_process_ir_data() receiver parser state SUBCMD is possible at start (i=0) of receiver buffer resulting in buffer offset=-1 passed to mceusb_dev_printdata(). Bad offset results in OOB read before start of buffer. [1214218.580308] mceusb 1-1.3:1.0: rx data[0]: 00 80 (length=2) [1214218.580323] mceusb 1-1.3:1.0: Unknown command 0x00 0x80 ... [1214218.580406] mceusb 1-1.3:1.0: rx data[14]: 7f 7f (length=2) [1214218.679311] mceusb 1-1.3:1.0: rx data[-1]: 80 90 (length=2) [1214218.679325] mceusb 1-1.3:1.0: End of raw IR data [1214218.679340] mceusb 1-1.3:1.0: rx data[1]: 7f 7f (length=2) Fix: If parser_state is SUBCMD after processing receiver buffer, reset parser_state to CMD_HEADER. In effect, discard cmd_prefix at end of receiver buffer. In mceusb_dev_printdata(), abort if buffer offset is out of bounds. Case 5: If response with data is truncated at end of buffer after { cmd_prefix, subcmd }, mceusb_dev_printdata() reads past end of buffer for data0, data1, ... while decoding the response to print out. Fix: In mceusb_dev_printdata(), remove unneeded buffer offset adjustments (var start and var skip) associated with MCE gen1 header. Test for truncated MCE cmd response (compare offset+len with buf_len) and skip decoding of incomplete response. Move IR data tracing to execute before the truncation test. Signed-off-by:A Sun <as1033x@comcast.net> Signed-off-by:
-
Sean Young authored
Decoding often fails on e.g. redrat3 devices. The dev_dbg() helps with debugging when decoding does fail. Cc: Patrick Lerda <patrick9876@free.fr> Signed-off-by:
-
Sean Young authored
libinput refuses pointer movement from rc-core, since it believes it's not a pointer-type device: libinput error: event17 - Media Center Ed. eHome Infrared Remote Transceiver (1784:0008): libinput bug: REL_X/Y from a non-pointer device Fixes: 158bc148 ("media: rc: mce_kbd: input events via rc-core's input device") Fixes: 0ac5a603 ("media: rc: imon: report mouse events using rc-core's input device") Cc: stable@vger.kernel.org # 4.20+ Signed-off-by:
-
Sean Young authored
procfs is no longer used anywhere in media. Signed-off-by:
-
Sean Young authored
This moves /proc/saa7164 to /sys/kernel/debug/saa7164. Signed-off-by:
-
- 04 Oct, 2019 3 commits
-
-
Aniket Masule authored
Current clock scaling calculations are same for vpu4 and previous versions. For vpu4, Clock scaling calculations are updated with cycles/mb and bitrate. This helps in getting precise clock required. Signed-off-by:
Aniket Masule <amasule@codeaurora.org> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
-
Aniket Masule authored
Add vpp cycles for different types of codec. It indicates the cycles required by video hardware to process each macroblock. Add vsp cycles, cycles required by stream processor. Initialize the codec data with core resources. Signed-off-by:
-
Stanimir Varbanov authored
Failure to suspend (venus_suspend_3xx) happens when the system is fresh booted and loading venus driver. This happens once and after reload the venus driver modules the problem disrepair. Fix the failure by skipping the check for WFI and IDLE bits if PC_READY is on in control status register. Signed-off-by:
-
- 02 Oct, 2019 2 commits
-
-
Stanimir Varbanov authored
This aims to add a requests for bandwidth scaling depending on the resolution and framerate (macroblocks per second). The exact value of the requested bandwidth is get from a pre-calculated tables for encoder and decoder. Acked-by:
Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
-
Loic Poulain authored
In downstream driver, there are two frequency tables defined, one for the encoder and one for the decoder: /* Encoders / <972000 490000000 0x55555555>, / 4k UHD @ 30 / <489600 320000000 0x55555555>, / 1080p @ 60 / <244800 150000000 0x55555555>, / 1080p @ 30 / <108000 75000000 0x55555555>, / 720p @ 30 */ /* Decoders / <1944000 490000000 0xffffffff>, / 4k UHD @ 60 / < 972000 320000000 0xffffffff>, / 4k UHD @ 30 / < 489600 150000000 0xffffffff>, / 1080p @ 60 / < 244800 75000000 0xffffffff>; / 1080p @ 30 */ It shows that encoder always needs a higher clock than decoder. In current venus driver, the unified frequency table is aligned with the downstream decoder table which causes performance issues in encoding scenarios. Fix that by aligning frequency table on worst case (encoding). Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
- 01 Oct, 2019 26 commits
-
-
Benoit Parrot authored
Switch to SPDX licensing and drop the redundant GPL text. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Acked-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Benoit Parrot authored
The initial registers sequence is only loaded at probe time. Afterward only the resolution and format specific register are modified. Care must be taken to make sure registers modified by one resolution setting are reverted back when another resolution is programmed. This was not done properly for the 720p case. Signed-off-by:
-
Benoit Parrot authored
On some board it is possible that the sensor 'powerdown' and or 'reset' pin might be controlled by gpio instead of being tied. To implement we add pm_runtime support which will handle the power up/down sequence when it is available otherwise the sensor will be powered on at module insertion/probe and powered off at module removal. Now originally the driver assumed that the sensor would always stay powered and keep its register setting. We cannot assume this anymore, so every time we "power up" we need to re-program the initial registers configuration first. This was previously done only at probe time. [Sakari Ailus: Resolve a conflict in Kconfig] Signed-off-by:
-
Benoit Parrot authored
Add powerdown-gpios and reset-gpios to the list of optional properties for the OV2659 camera sensor. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Benoit Parrot authored
In ov2659_s_stream() return value for invoked function should be checked and propagated. Signed-off-by:
-
Benoit Parrot authored
Several of include files listed are not explicitly needed. If they are need then they are implicitly included. Reduce the list of includes to an easier to manage list. Signed-off-by:
-
Benoit Parrot authored
Make sure that if the expected sensor device id register is not recognized properly the failure is propagated up so devices are not left partially initialized. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Acked-by:
-
Benoit Parrot authored
Based on recently found sensor configuration examples, it was discovered that when scaling and binning are used for the lower resolutions (i.e. 640x480, 320x240) the read offset has to be increased otherwise the image appears to be wrapped around. Signed-off-by:
-
Dongchun Zhu authored
This patch adds support for registering a sensor sub-device to the async sub-device framework and parse set up common sensor related devices such as actuator/VCM. [Sakari Ailus: Rewrap commit message] Signed-off-by:
Dongchun Zhu <dongchun.zhu@mediatek.com> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Sakari Ailus authored
Assign vep->link_frequencies to NULL after releasing its memory. Without this change, multiple calls to v4l2_fwnode_endpoint_free() would result in double kfree calls. Signed-off-by:
-
Sakari Ailus authored
Instead of individually depending on MEDIA_CAMERA_SUPPORT (or forgetting it), put all camera sensor, lens and flash drivers under MEDIA_CAMERA_SUPPORT as a whole. The lens VCM devices didn't use to do this, but make them depend on MEDIA_CAMERA_SUPPORT as well since there's no use for these devices without that in practice. Signed-off-by:
-
Janusz Krzysztofik authored
The driver stores crop rectangle settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, crop rectangle width and height settings are not updated correctly when rectangle offset settings are applied on hardware. If an error occurs while the device is updated, the stored settings my no longer reflect hardware state and consecutive calls to .get_selection() as well as .get/set_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informamtion on active frame format returned by .get/set_fmt() is used. Assuming a failed update of the device means its actual settings haven't changed, update crop rectangle width and height settings stored in the device private structure correctly while the rectangle offset is successfully applied on hardware so the stored values always reflect actual hardware state to the extent possible. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
-
Janusz Krzysztofik authored
The driver stores frame format settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, those settings are updated before they are actually applied on hardware. If an error occurs on device update, the stored settings my not reflect hardware state anymore and consecutive calls to .get_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informmation on active frame format returned by .get_fmt() is used. Assuming a failed device update means its state hasn't changed, update frame format related settings stored in the device private structure only after they are successfully applied so the stored values always reflect hardware state as closely as possible. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Janusz Krzysztofik authored
It is not clear what pixel format is actually configured in hardware on reset. MEDIA_BUS_FMT_YUYV8_2X8, assumed on device probe since the driver was intiially submitted, is for sure not the one. Fix it by explicitly applying a known, driver default frame format just after initial device reset. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Janusz Krzysztofik authored
Commit da298c6d ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt") converted a former ov6650_g_fmt() video operation callback to an ov6650_get_fmt() pad operation callback. However, the converted function disregards a format->which flag that pad operations should obey and always returns active frame format settings. That can be fixed by always responding to V4L2_SUBDEV_FORMAT_TRY with -EINVAL, or providing the response from a pad config argument, likely updated by a former user call to V4L2_SUBDEV_FORMAT_TRY .set_fmt(). Since implementation of the latter is trivial, go for it. Fixes: da298c6d ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt") Signed-off-by:
-
Janusz Krzysztofik authored
User arguments passed to .get/set_fmt() pad operation callbacks may contain unsupported values. The driver takes control over frame size and pixel code as well as colorspace and field attributes but has never cared for remainig format attributes, i.e., ycbcr_enc, quantization and xfer_func, introduced by commit 11ff030c ("[media] v4l2-mediabus: improve colorspace support"). Fix it. Set up a static v4l2_mbus_framefmt structure with attributes initialized to reasonable defaults and use it for updating content of user provided arguments. In case of V4L2_SUBDEV_FORMAT_ACTIVE, postpone frame size update, now performed from inside ov6650_s_fmt() helper, util the user argument is first updated in ov6650_set_fmt() with default frame format content. For V4L2_SUBDEV_FORMAT_TRY, don't copy all attributes to pad config, only those handled by the driver, then fill the response with the default frame format updated with resulting pad config format code and frame size. Fixes: 11ff030c ("[media] v4l2-mediabus: improve colorspace support") Signed-off-by:
-
Janusz Krzysztofik authored
Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8. According to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies exclusively to V4L2_PIX_FMT_JPEG. Since the sensor does not support JPEG format, fix it to always select V4L2_COLORSPACE_SRGB. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Janusz Krzysztofik authored
Commit 4f996594 ("[media] v4l2: make vidioc_s_crop const") introduced a writable copy of constified user requested crop rectangle in order to be able to perform hardware alignments on it. Later on, commit 10d5509c ("[media] v4l2: remove g/s_crop from video ops") replaced s_crop() video operation using that const argument with set_selection() pad operation which had a corresponding argument not constified, however the original behavior of the driver was not restored. Since that time, any hardware alignment applied on a user requested crop rectangle is not passed back to the user calling .set_selection() as it should be. Fix the issue by dropping the copy and replacing all references to it with references to the crop rectangle embedded in the user argument. Fixes: 10d5509c ("[media] v4l2: remove g/s_crop from video ops") Signed-off-by:
-
Janusz Krzysztofik authored
Since commit afd9690c ("[media] ov6650: convert to the control framework"), if an error occurs during initialization of a control handler, resources possibly allocated to the handler are not freed before device initialiaton is aborted. Fix it. Fixes: afd9690c ("[media] ov6650: convert to the control framework") Signed-off-by:
-
Janusz Krzysztofik authored
Commit 23a52386 ("media: ov6650: convert to standalone v4l2 subdevice") converted the driver from a soc_camera sensor to a standalone V4L subdevice driver. Unfortunately, module description was not updated to reflect the change. Fix it. While being at it, update email address of the module author. Fixes: 23a52386 ("media: ov6650: convert to standalone v4l2 subdevice") Signed-off-by:
-
YueHaibing authored
If CONFIG_REGMAP_I2C is not set, building fails: drivers/media/i2c/max2175.o: In function `max2175_probe': max2175.c:(.text+0x1404): undefined reference to `__devm_regmap_init_i2c' Select REGMAP_I2C to fix this. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: b47b79d8 ("[media] media: i2c: max2175: Add MAX2175 support") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Hans Verkuil authored
This patch converts the cx231xx driver to the vb2 framework. Since you can't do a partial conversion this is a big-bang patch, i.e. large and hard to review. I never found a way around this. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Co-developed-by:
-
Hans Verkuil authored
Add support for cec-notifier to the cec-gpio driver. This makes it possible to associate the CEC gpio pin with an HDMI connector. This feature was always documented in the cec-gpio bindings: Documentation/devicetree/bindings/media/cec-gpio.txt But support for the hdmi-phandle property was never actually implemented in this driver. This patch adds support for this property. It also fixes a few incorrect error returns in the probe() function, which skipped the call to cec_delete_adapter(). Tested on a Raspberry Pi 3B with a modified vc4 driver. Signed-off-by:
-
Dariusz Marcinkiewicz authored
Document the new CEC_ADAP_G_CONNECTOR_INFO ioctl and the new CEC_CAP_CONNECTOR_INFO capability. Co-developed-by:
Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by:
-
Dariusz Marcinkiewicz authored
Until now the connector info API was a kernel-internal API only. This moves it to the public API and adds the new ioctl to retrieve this information. Signed-off-by:
-
Hans Verkuil authored
CEC_OP_REC_FLAG_NOT_USED is 0 and CEC_OP_REC_FLAG_USED is 1, not the other way around. Signed-off-by:
Jiunn Chang <c0d1n61at3@gmail.com> Cc: <stable@vger.kernel.org> # for v4.10 and up Signed-off-by:
-
