- 26 Jul, 2017 8 commits
-
-
henryhsu authored
On Exynos5420, the STREAM_STAT bit raised on the JPGINTST register means there is a syntax error or an unrecoverable error on compressed file when ERR_INT_EN is set to 1. Fix this case and report BUF_STATE_ERROR to videobuf2. Signed-off-by:
Henry-Ruey Hsu <henryhsu@chromium.org> Signed-off-by:
Thierry Escande <thierry.escande@collabora.com> Acked-by:
Andrzej Pietrasiewicz <andrzej.p@samsung.com> Acked-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
henryhsu authored
This patch adds support for resolution change event to notify clients so they can prepare correct output buffer. When resolution change happened, G_FMT for CAPTURE should return old resolution and format before CAPTURE queues streamoff. This event is used in the Chromium browser project by the V4L2 JPEG Decode Accelerator (V4L2JDA) to allocate output buffer. Signed-off-by:
-
Tony K Nadackal authored
This patch adds support for decoding 4:1:1 chroma subsampling in the JPEG header parsing function. Signed-off-by:
Tony K Nadackal <tony.kn@samsung.com> Signed-off-by:
-
Thierry Escande authored
This patch moves the subsampling value decoding read from the JPEG header into its own function. This new function is called s5p_jpeg_subsampling_decode() and returns true if it successfully decodes the subsampling value, false otherwise. Signed-off-by:
-
Thierry Escande authored
If s5p_jpeg_parse_hdr() fails to parse the JPEG header, the passed s5p_jpeg_q_data structure is not modified so there is no need to use a temporary structure and the field-by-field copy can be avoided. Signed-off-by:
-
Thierry Escande authored
This patch modifies the s5p_jpeg_parse_hdr() function so it only modifies the passed s5p_jpeg_q_data structure if the jpeg header parsing is successful. Signed-off-by:
-
Tony K Nadackal authored
Correct the WARN_ON statement for subsampling based on the JPEG hardware version. Signed-off-by:
-
Tony K Nadackal authored
When queuing an OUTPUT buffer for decoder, s5p_jpeg_parse_hdr() function parses the input jpeg file and takes the width and height parameters from its header. These new width/height values will be used for the calculation of stride. HX_JPEG Hardware needs the width and height values aligned on a 16 bits boundary. This width/height alignment is handled in the s5p_jpeg_s_fmt_vid_cap() function during the S_FMT ioctl call. But if user space calls the QBUF of OUTPUT buffer after the S_FMT of CAPTURE buffer, these aligned values will be replaced by the values in jpeg header. If the width/height values of jpeg are not aligned, the decoder output will be corrupted. So in this patch we call jpeg_bound_align_image() to align the width/height values of Capture buffer in s5p_jpeg_buf_queue(). Signed-off-by:
-
- 21 Jul, 2017 3 commits
-
-
Mauro Carvalho Chehab authored
Documentation/media/uapi/cec/cec-api.rst:17: WARNING: uapi/cec/cec-funcs is already assigned section numbers (nested numbered toctree?) Signed-off-by: -
Mauro Carvalho Chehab authored
The kernel-doc tag is wrong there, causing this warning: ./include/media/v4l2-fwnode.h:66: warning: bad line: index (1) Signed-off-by: -
Hans Verkuil authored
Fix this kernel-doc warning: WARNING: kernel-doc 'media-git/scripts/kernel-doc -rst -enable-lineno media-git/drivers/media/dvb-core/demux.h' processing failed with: 'ascii' codec can't decode byte 0xe2 in position 6368: ordinal not in range(128) Caused by using fancy quotes instead of regular quotes. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
- 20 Jul, 2017 29 commits
-
-
Todor Tomov authored
The local pad parameter in media_entity_remote_pad() is not modified. Make that explicit by adding a const modifier. Signed-off-by:
Todor Tomov <todor.tomov@linaro.org> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Nuno Henriques authored
Signed-off-by:
Nuno Henriques <nuno.amhenriques@gmail.com> Signed-off-by:
-
Bhumika Goyal authored
Declare v4l2_file_operations structures as const as they are only stored in the fops field of video_device structures. This field is of type const, so declare v4l2_file_operations structures with similar properties as const. Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Remove useless variables wait_t and wait_sym and code related. Also, fix some coding style issues. Addresses-Coverity-ID: 1226947 Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
This function is used only internally. So, make it static. Shuts up this warning: drivers/media/v4l2-core/v4l2-fwnode.c:153:6: warning: no previous prototype for 'v4l2_fwnode_endpoint_parse_csi1_bus' [-Wmissing-prototypes] void v4l2_fwnode_endpoint_parse_csi1_bus(struct fwnode_handle *fwnode, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: -
Mauro Carvalho Chehab authored
smatch produce this warning: drivers/media/v4l2-core/v4l2-fwnode.c:76 v4l2_fwnode_endpoint_parse_csi_bus() error: buffer overflow 'array' 5 <= u16max That's because, in thesis, the routine might have called with some value at bus->num_data_lanes. That's not the current case. Yet, better to shut up this warning, and make the code more reliable if some future changes might cause a bug. While here, simplify the code a little bit by reading only once from lanes-properties array. Signed-off-by: -
Mauro Carvalho Chehab authored
As reported by this warning: drivers/media/usb/pvrusb2/pvrusb2-encoder.c:263 pvr2_encoder_cmd() warn: continue to end of do { ... } while(0); loop There's an issue at the retry logic there: the current logic is: do { if (need_to_retry) continue; some_code(); } while (0); Well, that won't work, as continue will make it test for zero, and abort the loop. So, change the loop to: while (1) { if (need_to_retry) continue; some_code(); break; }; With seems to be what's actually expected there. Signed-off-by: -
Mauro Carvalho Chehab authored
The atomisp subdev driver hardcodes its version to ATOMISP_CSS_VERSION_21. Yet, it has several tests for versions below 21 internally, with sounds really odd. On all other media drivers, we're just keeping version set to LINUX_VERSION_CODE. So, do the same here, simplifying the code a little bit. Signed-off-by: -
Mauro Carvalho Chehab authored
This is used just for printing a version number. As this is never incremented, it makes no sense to keep it :-) Signed-off-by: -
Mauro Carvalho Chehab authored
This macro is never used. Get rid of it. Signed-off-by: -
Mauro Carvalho Chehab authored
We seldomly increment version numbers on drivers, because... we usually forget ;-) So, instead, just make it identical to the Kernel version, as what we do on all other drivers. Signed-off-by:
Sylwester Nawrocki <snawrocki@kernel.org> Signed-off-by:
-
Prabhakar Lad authored
drop VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from dm355/dm644x following reasons: - This ioctl was never in public api and was only defined in kernel header. - The function set_params constantly mixes up pointers and phys_addr_t numbers. - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is described as an 'experimental ioctl that will change in future kernels'. - The code to allocate the table never gets called after we copy_from_user the user input over the kernel settings, and then compare them for inequality. - We then go on to use an address provided by user space as both the __user pointer for input and pass it through phys_to_virt to come up with a kernel pointer to copy the data to. This looks like a trivially exploitable root hole. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Prabhakar Lad authored
this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works for vpfe_capture driver with a minimal patch suitable for backporting. - This ioctl was never in public api and was only defined in kernel header. - The function set_params constantly mixes up pointers and phys_addr_t numbers. - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is described as an 'experimental ioctl that will change in future kernels'. - The code to allocate the table never gets called after we copy_from_user the user input over the kernel settings, and then compare them for inequality. - We then go on to use an address provided by user space as both the __user pointer for input and pass it through phys_to_virt to come up with a kernel pointer to copy the data to. This looks like a trivially exploitable root hole. Due to these reasons we make sure this ioctl now returns -EINVAL and backport this patch as far as possible. Fixes: 5f15fbb6 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver") Signed-off-by:
-
Stanimir Varbanov authored
In venus_boot(), we pass a pointer to a phys_addr_t into dmam_alloc_coherent, which the compiler warns about: platform/qcom/venus/firmware.c: In function 'venus_boot': platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] To avoid the error refactor venus_boot function by discard dma_alloc_coherent invocation because we don't want to map the memory for the device. Something more, the usage of DMA mapping API is actually wrong and the current implementation relies on several bugs in DMA mapping code. When these bugs are fixed that will break firmware loading, so fix this now to avoid future troubles. The meaning of venus_boot is to copy the content of the firmware buffer into reserved (and memblock removed) block of memory and pass that physical address to the trusted zone for authentication and mapping through iommu form the secure world. After iommu mapping is done the iova is passed as ane entry point to the remote processor. After this change memory-region property is parsed manually and the physical address is memremap to CPU, call mdt_load to load firmware segments into proper places and unmap reserved memory. Fixes: af2c3834 ("[media] media: venus: adding core part and helper functions") Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Rob Clark authored
Not entirely sure what triggers it, but with venus build as kernel module and in initrd, we hit this crash: Unable to handle kernel paging request at virtual address ffff80003c039000 pgd = ffff00000a14f000 [ffff80003c039000] *pgd=00000000bd9f7003, *pud=00000000bd9f6003, *pmd=00000000bd9f0003, *pte=0000000000000000 Internal error: Oops: 96000007 [#1] SMP Modules linked in: qcom_wcnss_pil(E+) crc32_ce(E) qcom_common(E) venus_core(E+) remoteproc(E) snd_soc_msm8916_digital(E) virtio_ring(E) cdc_ether(E) snd_soc_lpass_apq8016(E) snd_soc_lpass_cpu(E) snd_soc_apq8016_sbc(E) snd_soc_lpass_platform(E) v4l2_mem2mem(E) virtio(E) snd_soc_core(E) ac97_bus(E) snd_pcm_dmaengine(E) snd_seq(E) leds_gpio(E) videobuf2_v4l2(E) videobuf2_core(E) snd_seq_device(E) snd_pcm(E) videodev(E) media(E) nvmem_qfprom(E) msm(E) snd_timer(E) snd(E) soundcore(E) spi_qup(E) mdt_loader(E) qcom_tsens(E) qcom_spmi_temp_alarm(E) nvmem_core(E) msm_rng(E) uas(E) usb_storage(E) dm9601(E) usbnet(E) mii(E) mmc_block(E) adv7511(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) qcom_spmi_vadc(E) qcom_vadc_common(PE) industrialio(E) pinctrl_spmi_mpp(E) pinctrl_spmi_gpio(E) rtc_pm8xxx(E) clk_smd_rpm(E) sdhci_msm(E) sdhci_pltfm(E) qcom_smd_regulator(E) drm(E) smd_rpm(E) qcom_spmi_pmic(E) regmap_spmi(E) ci_hdrc_msm(E) ci_hdrc(E) usb3503(E) extcon_usb_gpio(E) phy_msm_usb(E) udc_core(E) qcom_hwspinlock(E) extcon_core(E) ehci_msm(E) i2c_qup(E) sdhci(E) mmc_core(E) spmi_pmic_arb(E) spmi(E) qcom_smd(E) smsm(E) rpmsg_core(E) smp2p(E) smem(E) hwspinlock_core(E) gpio_keys(E) CPU: 2 PID: 551 Comm: irq/150-venus Tainted: P E 4.12.0+ #1625 Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc2-00144-ga97bdbdf72-dirty 07/08/2017 task: ffff800037338000 task.stack: ffff800038e00000 PC is at hfi_sys_init_done+0x64/0x140 [venus_core] LR is at hfi_process_msg_packet+0xcc/0x1e8 [venus_core] pc : [<ffff00000118b384>] lr : [<ffff00000118c11c>] pstate: 20400145 sp : ffff800038e03c60 x29: ffff800038e03c60 x28: 0000000000000000 x27: 00000000000df018 x26: ffff00000118f4d0 x25: 0000000000020003 x24: ffff80003a8d3010 x23: ffff00000118f760 x22: ffff800037b40028 x21: ffff8000382981f0 x20: ffff800037b40028 x19: ffff80003c039000 x18: 0000000000000020 x17: 0000000000000000 x16: ffff800037338000 x15: ffffffffffffffff x14: 0000001000000014 x13: 0000000100001007 x12: 0000000100000020 x11: 0000100e00000000 x10: 0000000000000001 x9 : 0000000200000000 x8 : 0000001400000001 x7 : 0000000000001010 x6 : 0000000000000148 x5 : 0000000000001009 x4 : ffff80003c039000 x3 : 00000000cd770abb x2 : 0000000000000042 x1 : 0000000000000788 x0 : 0000000000000002 Process irq/150-venus (pid: 551, stack limit = 0xffff800038e00000) Call trace: [<ffff00000118b384>] hfi_sys_init_done+0x64/0x140 [venus_core] [<ffff00000118c11c>] hfi_process_msg_packet+0xcc/0x1e8 [venus_core] [<ffff00000118a2b4>] venus_isr_thread+0x1b4/0x208 [venus_core] [<ffff00000118e750>] hfi_isr_thread+0x28/0x38 [venus_core] [<ffff000008161550>] irq_thread_fn+0x30/0x70 [<ffff0000081617fc>] irq_thread+0x14c/0x1c8 [<ffff000008105e68>] kthread+0x138/0x140 [<ffff000008083590>] ret_from_fork+0x10/0x40 Code: 52820125 52820207 7a431820 54000249 (b9400263) ---[ end trace c963460f20a984b6 ]--- The problem is that in the error case, we've incremented the data ptr but not decremented rem_bytes, and keep reading (presumably garbage) until eventually we go beyond the end of the buffer. Instead, on first error, we should probably just bail out. Other option is to increment read_bytes by sizeof(u32) before the switch, rather than only accounting for the ptype header in the non-error case. Note that in this case it is HFI_ERR_SYS_INVALID_PARAMETER, ie. an unrecognized/unsupported parameter, so interpreting the next word as a property type would be bogus. The other error cases are due to truncated buffer, so there isn't likely to be anything valid to interpret in the remainder of the buffer. So just bailing seems like a reasonable solution. Signed-off-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Arnd Bergmann authored
If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into a build error: ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] undefined! ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] undefined! This changes the 'select' statement again, so we only try to enable those symbols when the drivers will actually get built, and explicitly test for QCOM_MDT_LOADER to be enabled before calling into it. Fixes: 76724b30 ("[media] media: venus: enable building with COMPILE_TEST") Signed-off-by:
-
Arnd Bergmann authored
Without PM support, gcc warns about two unused functions: platform/qcom/venus/core.c:146:13: error: 'venus_clks_disable' defined but not used [-Werror=unused-function] platform/qcom/venus/core.c:126:12: error: 'venus_clks_enable' defined but not used [-Werror=unused-function] The problem as usual are incorrect #ifdefs, so the easiest fix is to do away with the #ifdef completely and mark the suspend/resume handlers as __maybe_unused, which they are. Fixes: af2c3834 ("[media] media: venus: adding core part and helper functions") Signed-off-by:
-
Mauro Carvalho Chehab authored
As we're already touching on dvb_ca_en50221 to cleanup checkpatch issues, do that also for its header file, with: $ ./scripts/checkpatch.pl --strict --fix-inplace -f drivers/media/dvb-core/dvb_ca_en50221.h Signed-off-by: -
Jasmin Jessich authored
- Running "checkpatch.pl -strict -f ..." complained * Please don't use multiple blank lines Signed-off-by:
Jasmin Jessich <jasmin@anw.at> Signed-off-by:
-
Jasmin Jessich authored
- Running "checkpatch.pl -strict -f ..." gave more checks to fix. * Blank lines aren't necessary after an open brace '{' * Comparison to NULL written as "!<var>" * CHECK: Blank lines aren't necessary before a close brace '}' Signed-off-by: -
Jasmin Jessich authored
- Added the missing opening empty comment line. Signed-off-by:
-
Jasmin Jessich authored
Some EXPORT_SYMBOL() on this file don't match the name of functions that precedes them. Signed-off-by:
-
Jasmin Jessich authored
- "dont" -> "don't" Signed-off-by:
-
Jasmin Jessich authored
Fixed most of: WARNING: line over 80 characters The remaining lines are printk strings, which should not be split and lines where I thing they should stay as they are. Signed-off-by:
-
Jasmin Jessich authored
- Changed all C++ style comments ("// ..") to C style ones ("/* .. */"). Signed-off-by: -
Jasmin Jessich authored
- The STATUSREG_TXERR definition is not used and it has style problems, too. Removing it seems to solve both issues. Signed-off-by:
-
Jasmin Jessich authored
Fixed all: WARNING: braces {} are not necessary for single statement blocks Signed-off-by: -
Jasmin Jessich authored
Fixed all: WARNING: Missing a blank line after declarations Signed-off-by:
-
Jasmin Jessich authored
Used a helper variable "struct dvb_ca_slot *sl" instead of "ca->slot_info[slot]". This reduces the line length and simplifies code reading. Fixed also "-strict" checks in this patch: - Comparison to NULL written as "!<var>". Signed-off-by:
-
