- 26 Sep, 2020 23 commits
-
-
Dafna Hirschfeld authored
For video capture it is the driver that reports the colorspace, transfer function, Y'CbCr/HSV encoding and quantization range used by the video, and there is no way to request something different, even though many HDTV receivers have some sort of colorspace conversion capabilities. For output video this feature already exists since the application specifies this information for the video format it will send out, and the transmitter will enable any available CSC if a format conversion has to be performed in order to match the capabilities of the sink. For video capture we propose adding new v4l2_pix_format flag: V4L2_PIX_FMT_FLAG_SET_CSC. The flag is set by the application, the driver will interpret the colorspace, xfer_func, ycbcr_enc/hsv_enc and quantization fields as the requested colorspace information and will attempt to do the conversion it supports. Drivers set the flags V4L2_FMT_FLAG_CSC_COLORSPACE, V4L2_FMT_FLAG_CSC_XFER_FUNC, V4L2_FMT_FLAG_CSC_YCBCR_ENC/V4L2_FMT_FLAG_CSC_HSV_ENC, V4L2_FMT_FLAG_CSC_QUANTIZATION, in the flags field of the struct v4l2_fmtdesc during enumeration to indicate that they support colorspace conversion for the respective field. Drivers do not have to actually look at the flags. If the flags are not set, then the fields 'colorspace', 'xfer_func', 'ycbcr_enc/hsv_enc', and 'quantization' are set to the default values by the core, i.e. just pass on the received format without conversion. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Alexandre Courbot authored
Factorize redundant checks into a single code block, remove unneeded checks (a buffer in done_list is necessarily in the DONE or ERROR state), and we end up with a much simpler version of this function. Signed-off-by:
Alexandre Courbot <gnurou@gmail.com> Reviewed-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Alexandre Courbot authored
If poll() is called on a m2m device with the EPOLLOUT event after the last buffer of the CAPTURE queue is dequeued, any buffer available on OUTPUT queue will never be signaled because v4l2_m2m_poll_for_data() starts by checking whether dst_q->last_buffer_dequeued is set and returns EPOLLIN in this case, without looking at the state of the OUTPUT queue. Fix this by not early returning so we keep checking the state of the OUTPUT queue afterwards. Signed-off-by:
-
Dinghao Liu authored
When platform_get_irq() fails, we should release vfd and unregister pcdev->v4l2_dev just like the subsequent error paths. Fixes: d4e192cc ("media: mx2_emmaprp: Check for platform_get_irq() error") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alexandre Courbot authored
The driver requests IRQs to disable them immediately. This is potentially racy, fix this by requesting the IRQs to come disabled instead using the IRQ_NOAUTOEN flag of irq_set_status_flags(). Reported-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
-
Alexandre Courbot authored
v4l2-compliance expects the driver to adjust the time per frame if it is invalid (numerator or denominator set to 0). Adjust it to the default value in these cases. Signed-off-by:
Tiffany Lin <tiffany.lin@mediatek.com> Signed-off-by:
-
Alexandre Courbot authored
The time per frame was left initialized to 0/0, which make the driver fail v4l2-compliance, and also leaves it potentially exposed to doing a division by zero. Signed-off-by:
-
Alexandre Courbot authored
v4l2-compliance requires ENUM_FRAMESIZES to support OUTPUT formats. Reuse mtk_venc_find_format() to make sure both queues are considered when serving an ENUM_FRAMESIZES. [hverkuil: fixed some checkpatch alignment warnings] Signed-off-by:
-
Alexandre Courbot authored
vidioc_enum_framesizes() assumes that all encoders support H.264 and VP8, which is not necessarily true and requires to duplicate information about the supported codecs which is already stored in the platform data. Fix this by referring to the platform data to find out whether a given format is supported. Since the supported sizes are all the same regardless of the format, we can then return a copy of a static value if the format is supported. Signed-off-by:
-
Alexandre Courbot authored
A default value of 0 means V4L2_FIELD_ANY, which is not correct. Reported by v4l2-compliance. Signed-off-by:
-
Alexandre Courbot authored
This control is required by v4l2-compliance for encoders. A value of 1 should be suitable for all scenarios. Signed-off-by:
-
Alexandre Courbot authored
This reverts commit 81735ecb. The hardware needs data to follow the previous alignment, so this extra space was not superfluous after all. Besides, this also made v4l2-compliance's G_FMT and S_FMT tests regress. Signed-off-by:
-
Yunfei Dong authored
Now that all the supporting blocks are present, enable encoder for MT8183. [acourbot: refactor, cleanup and split] Signed-off-by:
Yunfei Dong <yunfei.dong@mediatek.com> Co-developed-by:
-
Alexandre Courbot authored
MT8183's encoder is similar to MT8173's. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Alexandre Courbot authored
Different chips have different supported formats. Move the list of supported formats to the platform data, and split the output and capture formats into two lists to make it easier to find the default format for each queue. [hverkuil: fixed some checkpatch alignment warnings] Signed-off-by:
-
Alexandre Courbot authored
Different chips have different supported bitrate ranges. Move the min and max supported bitrates to the platform data. Signed-off-by:
-
Alexandre Courbot authored
Firmwares for encoders newer than MT8173 will include an ABI version number in their initialization ack message. Add the capacity to manage it and make initialization fail if the firmware ABI is of a version that we don't support. For MT8173, this ABI version field is reserved and thus undefined ; thus ignore it on this chip. There should only be one firmware version available for it anyway. Signed-off-by:
-
Yunfei Dong authored
Support the new extended firmware used by MT8183's encoder. [acourbot: refactor, cleanup and split] [hverkuil: fixed some checkpatch alignment warnings] Signed-off-by:
-
Yunfei Dong authored
Add support for communicating with the SCP firmware, which will be used by MT8183. [acourbot: refactor, cleanup and split] [hverkuil: fixed some checkpatch alignment warnings] Signed-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Alexandre Courbot authored
The mediatek codecs can use either the VPU or the SCP as their interface to firmware. Reflect this in the DT bindings. Signed-off-by:
-
Yunfei Dong authored
MT8183's codec firmware is run by a different remote processor from MT8173. While the firmware interface is basically the same, the way to invoke it differs. Abstract all firmware calls under a layer that will allow us to handle both firmware types transparently. [acourbot: refactor, cleanup and split] [pihsun: fix error path and add mtk_vcodec_fw_release] [hverkuil: fixed some checkpatch alignment warnings] [hverkuil: fixed merge conflicts] Signed-off-by:
Pi-Hsun Shih <pihsun@chromium.org> Reviewed-by:
-
Alexandre Courbot authored
This will improve this driver's build coverage. Reported-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
- 23 Sep, 2020 2 commits
-
-
Mauro Carvalho Chehab authored
There are still some warnings produced by -Wsuggest-attribute=format, like this one: drivers/staging/media/atomisp/pci/runtime/debug/src/ia_css_debug.c: In function ‘dtrace_dot’: drivers/staging/media/atomisp/pci/runtime/debug/src/ia_css_debug.c:2466:2: warning: function ‘dtrace_dot’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] 2466 | ia_css_debug_vdtrace(IA_CSS_DEBUG_INFO, fmt, ap); | ^~~~~~~~~~~~~~~~~~~~ Also, on some places, is is using __atribute, while on others it is using the __printf() macro. Uniform those to always use the __printf() macro, placing it before the function, and fix the logic in order to cleanup all such warnings. Signed-off-by: -
Mauro Carvalho Chehab authored
Depending on the gcc version, after changeset 72a9ff3b ("media: atomisp: get rid of -Wsuggest-attribute=format warnings"), we're now getting two warnings, which are breaking the Jenkins CI instance at https://builder.linuxtv.org: ../drivers/staging/media/atomisp/pci/atomisp_compat_css20.c: In function ‘__set_css_print_env’: ../drivers/staging/media/atomisp/pci/atomisp_compat_css20.c:860:50: error: assignment to ‘int (*)(const char *, char *)’ from incompatible pointer type ‘int (__attribute__((regparm(0))) *)(const char *, char *)’ [-Werror=incompatible-pointer-types] isp->css_env.isp_css_env.print_env.debug_print = vprintk; ^ ../drivers/staging/media/atomisp/pci/atomisp_compat_css20.c: In function ‘atomisp_css_load_firmware’: ../drivers/staging/media/atomisp/pci/atomisp_compat_css20.c:893:49: error: assignment to ‘int (*)(const char *, char *)’ from incompatible pointer type ‘int (__attribute__((regparm(0))) *)(const char *, char *)’ [-Werror=incompatible-pointer-types] isp->css_env.isp_css_env.print_env.error_print = vprintk; ^ cc1: some warnings being treated as errors So, we need to partially revert the patch. Fixes: 72a9ff3b ("media: atomisp: get rid of -Wsuggest-attribute=format warnings") Signed-off-by:
-
- 22 Sep, 2020 6 commits
-
-
Felix Winkler authored
Improved readability by fixing some issues related to maximum line length. Signed-off-by:
Felix Winkler <fxmw.tnt@gmail.com> Signed-off-by:
Niklas Witzel <nik.witzel@horsepower-hannover.de> Signed-off-by:
-
Hans Verkuil authored
strscpy is preferred over strlcpy and is the standard in the media subsystem. Signed-off-by:
-
Xiaoliang Pang authored
modify the return error value is -EDOM Fixes: 2cac05de("drm/amd/powerplay: add the hw manager for vega12 (v4)") Cc: Evan Quan <evan.quan@amd.com> Signed-off-by:
Xiaoliang Pang <dawning.pang@gmail.com> Reviewed-by:
Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by:
-
Cengiz Can authored
commit df561f66 ("treewide: Use fallthrough pseudo-keyword") from Gustavo A. R. Silva replaced and standardized /* fallthrough */ comments with 'fallthrough' pseudo-keyword. However, in one of the switch-case statements, Coverity Static Analyzer throws a warning that 'fallthrough' is unreachable due to the adjacent 'return false' statement. (Coverity ID CID 1466511) In order to fix the unreachable code warning, remove unnecessary fallthrough keyword. Signed-off-by:
Cengiz Can <cengiz@kernel.wtf> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Alex Dewar authored
Address the following issues: * unnecessary comparison to true/false * use of 0/1 instead of bool values * unnecessary conversion to bool These were fixed using the following Coccinelle scripts: * scripts/coccinelle/misc/bool{init,conv,return}.cocci Build-tested with allmodconfig. Signed-off-by:Alex Dewar <alex.dewar90@gmail.com> Signed-off-by:
-
Alex Dewar authored
In a few places in pci/sh_css_params.c, memset is used to zero memory immediately before it is freed. As none of these structs appear to contain sensitive information, just remove the calls to memset. Suggested-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 17 Sep, 2020 9 commits
-
-
Mauro Carvalho Chehab authored
As warned by smatch: drivers/media/test-drivers/vidtv/vidtv_psi.c:93 vidtv_psi_update_version_num() warn: impossible condition '(h->version > 32) => (0-31 > 32)' h_version is declared as: u8 version:5; Meaning that its value ranges from 0 to 31. Incrementing 31 on such data will overflow to zero, as expected. So, just drop the uneeded overflow check. While here, use "foo++" instead of "++foo", as this is a much more common pattern. Signed-off-by: -
Mauro Carvalho Chehab authored
There's no need to use u64 over there. In a matter of fact, the div is not even needed, as it is multiplying by 1000 and dividing by 1000. So, simplify the logic. While here, constrain the buffer size to a certain range (between the current value and 10 times it) Signed-off-by: -
Daniel W. S. Almeida authored
Fix the following error for builds on 32bit architectures: ERROR: modpost: "__udivdi3" [drivers/media/test-drivers/vidtv/dvb-vidtv-bridge.ko] undefined! Which is due to 64bit divisions that did not go through the helpers in linux/math64.h As vidtv_mux_check_mux_rate was not operational in its current form, drop the entire function while it is not fixed properly. For now, call vidtv_mux_pad_with_nulls with a constant number of packets to avoid warnings due to unused functions when building this driver. The 64bit division used in the s302m is not needed, remove them and use a fixed number of frames and a constant PTS increment instead. Fixes: f90cf607 ("media: vidtv: add a bridge driver") Signed-off-by:
Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Keep playing a single tone is not too nice, and prevents checking some weird things. So, instead, implement a simple tone generator, changing the code to play a public domain song (5th Symphony of Beethoven), using sinusoidal waves. Signed-off-by: -
Mauro Carvalho Chehab authored
Instead, use the code from linux/fixp-arith.h. Signed-off-by: -
Mauro Carvalho Chehab authored
A typical digital TV stream has errors that are corrected by Viterbi. While the error rate after Viterbi is usually zero, with good signals, there are some chances of getting random errors before that, which are auto-corrected by the error code algorithm. Add a poor guy's implementation that would show some noise at the pre-BER part of the demod. Signed-off-by: -
Mauro Carvalho Chehab authored
The virtual driver has now a minimal set of frequencies for a single transponder to be found by each DVB standard. Document it, and update related information about the simulated LNBf. Signed-off-by: -
Mauro Carvalho Chehab authored
Satellite setups are different than terrestrial and cable ones, as there is a device coupled at the antenna, called LNBf, which converts the frequency from a GHz range at C-Band or Ku-Band into an intermediate frequency at S-Band (ranging up to ~2GHz). There are several different models of LNBf, with different IF conversions, but the most common nowadays is called Universal LNBf. Those got their frequency ranges extended in the past, when Astra 19.2E sattellite was launched. The universal LNBf has two local oscilators: - 9.75 GHz - 10.6 GHz The first one is used when the frequency is between 10.7 GHz up to 11.7 GHz. The second one is for frequencies between 11.7 GHz to 12.75 GHz. With that, the IF signal will be at 950 MHz to 2,150 MHz range. Add support for doing the above math, and make clear that the frequencies expected by the driver should be at Ku-Band range. Signed-off-by: -
Mauro Carvalho Chehab authored
Those are needed for real applications to work with Satellite systems. Signed-off-by:
-
