- 26 Sep, 2020 8 commits
-
-
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 <acourbot@chromium.org> Acked-by:
Tiffany Lin <tiffany.lin@mediatek.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
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 <yunfei.dong@mediatek.com> Co-developed-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:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-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:
-
- 14 Sep, 2020 15 commits
-
-
Mauro Carvalho Chehab authored
As reported by gcc: drivers/media/test-drivers/vidtv/vidtv_demod.c: In function 'vidtv_demod_set_frontend': drivers/media/test-drivers/vidtv/vidtv_demod.c:265:42: warning: variable 'cnr2qual' set but not used [-Wunused-but-set-variable] 265 | const struct vidtv_demod_cnr_to_qual_s *cnr2qual = NULL; | ^~~~~~~~ It turns that the var is not needed at all. So, just drop it. Signed-off-by: -
Mauro Carvalho Chehab authored
On real devices, signal strength is always a negative number when represented in dBm. A more interesting range is to use dBmV (which is what Kaffeine does, for example). The conversion from the two units are simple: dBmV = dBm - 108 Usually, signal strength ranges up to 100dBmV. Adjust the maximum value to be around 74 dBmV, when there's no frequency shift, which represents a good signal. With that, Kaffeine displays it a lot better. Signed-off-by: -
Mauro Carvalho Chehab authored
Add support for incrementing DVBv5 stats for block counters and post/pre BER byte counts. For now, the errors won't be incremented yet. Signed-off-by: -
Mauro Carvalho Chehab authored
The dvb_frontend will already call status periodically, when a channel is tuned. So, no need to have a work queue for such purpose. Signed-off-by: -
Mauro Carvalho Chehab authored
The current stats code is broken on so many ways. It ends reporting 0 for signal strengh, and the work queue doesn't run. If it would run, the code would crash. Fix such issues and add the minimum stuff for DVBv5 stats. Right now, only strength and cnr and UCB are implemented. pre/post BER stats will always return zero. Signed-off-by: -
Mauro Carvalho Chehab authored
Right now, the config data passed from the bridge driver is just ignored. Also, let's initialize the delayed work at probing time. Signed-off-by: -
Mauro Carvalho Chehab authored
The code there is already doing the right thing, as it uses value & 0xff, value & 0xff00, which already ensures the expected endiannes. So, it doesn't make any sense to touch the order depending on the CPU endiannes. Yet, as pointed by Daniel at the mailing list: https://lore.kernel.org/linux-media/e614351c-215c-c048-52af-7c200b164f41@xs4all.nl/T/#m8d221684a151833966359c2ed8bdce0f0ee4e5fd The reverse code is needed by the decoder. So, keep it no matter the endiannes. Signed-off-by:
-
Mauro Carvalho Chehab authored
Use 474 MHz frequency for DVB-T/DVB-C, as this is the at the channel range that it is valid on most places for DVB-T. In the case of DVB-S, let's add Astra 19.2E initial frequency at the scan files as the default, e. g. 12.5515 GHz. Signed-off-by: -
Mauro Carvalho Chehab authored
Right now, there are some issues at the tuning logic: 1) the config struct is not copied at the tuner driver. so, it won't use any frequency table at all; 2) the code that checks for frequency shifts is called at set_params. So, lock_status will never be zeroed; 3) the signal strength will also report a strong signal, even if not tuned; 4) the logic is not excluding non-set frequencies. Fix those issues. Signed-off-by: -
Mauro Carvalho Chehab authored
The two places where ENDIAN_BITFIELD is used is for a single 8-bits integer. No need to correct endiannes on such cases. Signed-off-by: -
Mauro Carvalho Chehab authored
Genmask is always highest order to low order. It doesn't make any sense to make it depends on endiannes. Signed-off-by: -
Mauro Carvalho Chehab authored
There are several warnings produced when the driver is built for 32-bit archs. Solve them. Reported-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
It is better to use the higher level dev_foo() than pr_foo() for printks. Change them at vidtv at the more trivial places. Signed-off-by: -
Mauro Carvalho Chehab authored
As this virtual driver is probed manually, add modaliases for this driver. Signed-off-by: -
Stanimir Varbanov authored
In order to boot some of the new Venus firmware versions TZ call to set virtual address ranges is needed. Add virtual address ranges for CP and CP_NONPIX in resource structure and use them when loading and booting the firmware on remote processor. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Reviewed-by:
-
