- 26 Jun, 2017 6 commits
-
-
Ralph Metzler authored
campoll and read_data are called very often and the printouts are very annoying and make the driver unusable. They seem to be left over from developing the buffer mode. Original code change by Ralph Metzler, modified by Jasmin Jessich to match current Kernel code. Signed-off-by:
Ralph Metzler <rjkm@metzlerbros.de> Signed-off-by:
Jasmin Jessich <jasmin@anw.at> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Ralph Metzler authored
The buffer mode was already implemented in this driver, but it did not work as expected. This has been fixed now, but it is still deactivated and can be activated by removing a comment at the begin of the file. Original code change by Ralph Metzler, modified by Jasmin Jessich and Daniel Scheller to match Kernel code style. Signed-off-by:
Daniel Scheller <d.scheller@gmx.net> Signed-off-by:
-
Ralph Metzler authored
Some lower level drivers may work better when sending blocks of data instead byte per byte. For this we need new function pointers in the dvb_ca_en50221 protocol structure (read_data, write_data) and the protocol needs to execute them, if they are defined. Block data transmission is done in all states except LINKINIT. Original code change by Ralph Metzler, modified by Jasmin Jessich and Daniel Scheller to match Kernel code style. Signed-off-by:
-
Ralph Metzler authored
Some CAMs do a really slow initialization, which requires a longer timeout for the first response. Original code change by Ralph Metzler, modified by Jasmin Jessich to match Kernel code style. Signed-off-by:
-
Ralph Metzler authored
In case of a linkinit failure change to state UNINITIALISED to re-init the CAM. Original code change by Ralph Metzler, modified by Jasmin Jessich to match Kernel code style. Signed-off-by:
-
Sakari Ailus authored
VIDIOC_S_FMT may return EBUSY if the device is streaming or there are buffers allocated. Document this. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
- 25 Jun, 2017 9 commits
-
-
Mauro Carvalho Chehab authored
A section talking about demod statistics implementation was recently added, but it seemed to start from nowere, without a previous description about how a demod driver would look like. Add such description, for completeness. Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of just start describing the kAPI functions, add an introduction giving a general line about a DVB driver's structure. Signed-off-by: -
Mauro Carvalho Chehab authored
The stv0367 driver provide a lot of status on its state machine. Change the logic to provide more information about frontend locking status. Also, while any detailed status isn't available, provide a more complete FE_STATUS for DVB-T. Signed-off-by:
-
Daniel Scheller authored
Provide QAM/DVB-C signal strength in decibel scale. Values returned from stv0367cab_get_rf_lvl() are good but need to be multiplied as they're in 1dBm precision. Signed-off-by:
-
Daniel Scheller authored
Since the other statistics are read when fe_status conditions are TRUE, change the ucblocks readout logic to match this aswell. Signed-off-by:
-
Mauro Carvalho Chehab authored
While there's a test at the SNR calculus to avoid division by zero, it will still follow the path that would do the division. So, add a missing break there. Signed-off-by: -
Daniel Scheller authored
Add signal-to-noise-ratio as provided by the demodulator in decibel scale. QAM/DVB-C needs some intlog calculation to have usable dB values, OFDM/ DVB-T values from the demod look alright already and are provided as-is. Signed-off-by:
-
Daniel Scheller authored
When the demod driver puts the demod into sleep or shutdown state and it's status is then polled e.g. via "dvb-fe-tool -m", i2c errors are printed to the kernel log. If the last delsys was DVB-T/T2: cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1 cxd2841er: i2c rd failed=-5 addr=6c reg=26 and if it was DVB-C: cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1 cxd2841er: i2c rd failed=-5 addr=6c reg=49 This happens when read_status unconditionally calls into the read_signal_strength() function which triggers the read_agc_gain_*() functions, where these registered are polled. This isn't a critical thing since when the demod is active again, no more such errors are logged, however this might make users suspecting defects. Fix this by requiring STATE_ACTIVE_* in priv->state. If it isn't in any active state, additionally set the strength scale to NOT_AVAILABLE. Signed-off-by:
-
Daniel Scheller authored
Fixup commit d52786dd ("media: ddbridge: make (ddb)readl in while-loops fail-safe") after/wrt commit 11e358bf ("media: ddbridge: use dev_* macros in favor of printk") Signed-off-by:
-
- 24 Jun, 2017 25 commits
-
-
Gustavo A. R. Silva authored
Value assigned to variable _type_ at line 678 is overwritten at line 688 before it can be used. This makes such variable assignment useless. Remove this variable assignment and fix some coding style issues. Addresses-Coverity-ID: 1226968 Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Remove unnecessary variable _ret_ and refactor the code. Addresses-Coverity-ID: 1226934 Signed-off-by:
-
Daniel Scheller authored
The read_snr() functions currently do some magic to return relative scale values when called. Split out register readouts into separate functions so the functionality can be reused in some other way. Signed-off-by:
-
Daniel Scheller authored
This adds the basics to stv0367ddb_read_status() to be able to properly provide signal statistics in DVBv5 format. Also adds UCB readout and provides those values. Also, don't return -EINVAL in ddb_read_status() if active_demod_state indicates no delivery system. Signed-off-by:
-
Daniel Scheller authored
Use dev_dbg() in conjunction with the %*ph format macro to print the vmon status debug, thus hiding continuous hexdumping from default log levels. Also, change the attach success log line from error to info severity. Signed-off-by:
Abylay Ospan <aospan@netup.ru> Signed-off-by:
-
Binoy Jayan authored
The semaphore 'i2c_switch_mutex' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by:
Binoy Jayan <binoy.jayan@linaro.org> Signed-off-by:
-
Binoy Jayan authored
The semaphore 'stream_mutex' is used as a simple mutex, so it should be written as one. Also moving the mutex_[lock/unlock] to the caller as it is anyway locked at the beginning of the callee thus avoiding repetition. Signed-off-by:
-
Binoy Jayan authored
The semaphore 'cmd_mutex' is used as a simple mutex, so it should be written as one. Also, replace down with mutex_destroy to ensure sane state when ngene_stop is called. Signed-off-by:
-
Mauro Carvalho Chehab authored
As such macro will check if the expression is true, it may fall through, as warned: In file included from ./include/uapi/linux/stddef.h:1:0, from ./include/linux/stddef.h:4, from ./include/uapi/linux/posix_types.h:4, from ./include/uapi/linux/types.h:13, from ./include/linux/types.h:5, from ./drivers/media/dvb-core/dvb_frontend.h:35, from drivers/media/tuners/fc0011.h:4, from drivers/media/tuners/fc0011.c:20: drivers/media/tuners/fc0011.c: In function 'fc0011_set_params': ./include/linux/compiler.h:179:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:109:2: note: in expansion of macro 'unlikely' unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/media/tuners/fc0011.c:344:3: note: in expansion of macro 'WARN_ON' WARN_ON(1); ^~~~~~~ drivers/media/tuners/fc0011.c:345:2: note: here case 0: ^~~~ In file included from ./include/uapi/linux/stddef.h:1:0, from ./include/linux/stddef.h:4, from ./include/uapi/linux/posix_types.h:4, from ./include/uapi/linux/types.h:13, from ./include/linux/types.h:5, from ./include/linux/list.h:4, from ./include/linux/module.h:9, from drivers/media/pci/tw5864/tw5864-video.c:17: drivers/media/pci/tw5864/tw5864-video.c: In function 'tw5864_fmt_vid_cap': ./include/linux/compiler.h:179:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:68:2: note: in expansion of macro 'unlikely' unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/media/pci/tw5864/tw5864-video.c:547:3: note: in expansion of macro 'WARN_ON_ONCE' WARN_ON_ONCE(1); ^~~~~~~~~~~~ drivers/media/pci/tw5864/tw5864-video.c:548:2: note: here case STD_NTSC: ^~~~ On both cases, it means an error, so, let's return an error code, to make gcc happy. Signed-off-by:Michael Büsch <m@bues.ch> Signed-off-by:
-
Martin Kepplinger authored
DRX_S9TOS16 and DRX_S24TODRXFREQ are simply not used. Furthermore, sign_extend32() should be used for sign extension. (Also, the comment describing DRX_S24TODRXFREQ was wrong). So remove these macros. Signed-off-by:
Martin Kepplinger <martink@posteo.de> Signed-off-by:
-
Peter Ujfalusi authored
The dmaengine driver for sDMA now have support for interleaved transfer. This trasnfer type was open coded with the legacy omap-dma API, but now we can move it to dmaengine. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
While committing a change on em28xx, I got a warning of a typo there. So, fix it on em28xx and on two other media drivers with the same typo. Signed-off-by: -
Mauro Carvalho Chehab authored
There's a new version of Terratec H6 with uses USB ID 0ccd:10b2. This version is similar to the old one (with is supported via the HTC entry), except that this one has the eeprom on the second bus. On this board, one side of this board is labeled with: dvbc v2.0 The other side with: 94V-0, MO2, RK-4221 with huge digits: 1107 With those patches, the board is properly detected: em28xx 1-1.5:1.0: New device TERRATEC TERRATCE H5 MKII @ 480 Mbps (0ccd:10b2, interface 0, class 0) em28xx 1-1.5:1.0: Audio interface 0 found (Vendor Class) em28xx 1-1.5:1.0: Video interface 0 found: isoc em28xx 1-1.5:1.0: DVB interface 0 found: isoc em28xx 1-1.5:1.0: chip ID is em2884 em28xx eeprom 00000000: 26 00 00 00 02 0b 0f e5 f5 64 01 60 09 e5 f5 64 &........d.`...d em28xx eeprom 00000010: 09 60 03 c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03 .`...".......... em28xx eeprom 00000020: 02 0a b9 e5 f6 b4 93 03 02 09 46 c2 c6 22 c2 c6 ..........F..".. em28xx eeprom 00000030: 22 00 60 00 ef 70 08 85 3d 82 85 3c 83 93 ff ef ".`..p..=..<.... em28xx eeprom 00000040: 60 19 85 3d 82 85 3c 83 e4 93 12 07 a3 12 0a fe `..=..<......... em28xx eeprom 00000050: 05 3d e5 3d 70 02 05 3c 1f 80 e4 22 12 0b 06 02 .=.=p..<...".... em28xx eeprom 00000060: 07 e2 01 00 1a eb 67 95 cd 0c b2 10 f0 13 6b 03 ......g.......k. em28xx eeprom 00000070: 98 22 6a 1c 86 12 27 57 4e 16 29 00 60 00 00 00 ."j...'WN.).`... em28xx eeprom 00000080: 02 00 00 00 5e 00 13 00 f0 10 44 82 82 00 00 00 ....^.....D..... em28xx eeprom 00000090: 5b 81 c0 00 00 00 20 40 20 80 02 20 10 01 00 00 [..... @ .. .... em28xx eeprom 000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ em28xx eeprom 000000b0: c6 40 00 00 81 00 00 00 00 00 00 00 00 c4 00 00 .@.............. em28xx eeprom 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 03 ................ em28xx eeprom 000000d0: 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00 1.2.3.4.5.6.7.8. em28xx eeprom 000000e0: 39 00 41 00 42 00 43 00 44 00 12 03 54 00 45 00 9.A.B.C.D...T.E. em28xx eeprom 000000f0: 52 00 52 00 41 00 54 00 45 00 43 00 22 03 54 00 R.R.A.T.E.C.".T. em28xx 1-1.5:1.0: eeprom 000100: ... (skipped) em28xx 1-1.5:1.0: EEPROM ID = 26 00 00 00, EEPROM hash = 0xbcd5a8cf em28xx 1-1.5:1.0: EEPROM info: em28xx 1-1.5:1.0: microcode start address = 0x0004, boot configuration = 0x00 em28xx 1-1.5:1.0: I2S audio, 5 sample rates em28xx 1-1.5:1.0: 500mA max power em28xx 1-1.5:1.0: Table at offset 0x27, strings=0x2298, 0x1c6a, 0x1286 em28xx 1-1.5:1.0: Identified as Terratec Cinergy H6 rev. 2 (card=101) em28xx 1-1.5:1.0: Currently, V4L2 is not supported on this model em28xx 1-1.5:1.0: dvb set to isoc mode. usbcore: registered new interface driver em28xx em28xx 1-1.5:1.0: Binding audio extension em28xx 1-1.5:1.0: em28xx-audio.c: Copyright (C) 2006 Markus Rechberger em28xx 1-1.5:1.0: em28xx-audio.c: Copyright (C) 2007-2016 Mauro Carvalho Chehab em28xx 1-1.5:1.0: Endpoint 0x83 high-speed on intf 0 alt 7 interval = 8, size 196 em28xx 1-1.5:1.0: Number of URBs: 1, with 64 packets and 192 size em28xx 1-1.5:1.0: Audio extension successfully initialized em28xx: Registered (Em28xx Audio Extension) extension em28xx 1-1.5:1.0: Binding DVB extension drxk: status = 0x639260d9 drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz drxk: DRXK driver version 0.9.4300 drxk: frontend initialized. tda18271 4-0060: creating new instance tda18271: TDA18271HD/C2 detected @ 4-0060 dvbdev: DVB: registering new adapter (1-1.5:1.0) em28xx 1-1.5:1.0: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)... dvbdev: dvb_create_media_entity: media entity 'DRXK DVB-C DVB-T' registered. dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. em28xx 1-1.5:1.0: DVB extension successfully initialized em28xx: Registered (Em28xx dvb Extension) extension em28xx 1-1.5:1.0: Registering input extension rc rc0: 1-1.5:1.0 IR as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/rc/rc0 Registered IR keymap rc-nec-terratec-cinergy-xs input: 1-1.5:1.0 IR as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/rc/rc0/input0 em28xx 1-1.5:1.0: Input extension successfully initalized em28xx: Registered (Em28xx Input Extension) extension tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete Signed-off-by: -
Mauro Carvalho Chehab authored
While testing support for Terratec H6 rev. 2, it was noticed that reading from eeprom there causes a timeout error. Apparently, this is due to the need of properly setting GPIOs. In any case, the driver doesn't really require eeprom reading to succeed, as this is currently used only for debug. So, Ignore such errors. Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Dan Carpenter authored
Mostly this adds some unlocks to error paths. But, if you see where there were "break;" statements before, I changed those paths to return error codes instead of returning success. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
This patch mostly adds unlocks to error paths. But one additional small change is that I made the first "break;" a "goto unlock;" which means that now we return failure instead of success on that path. Signed-off-by:
-
Gustavo A. R. Silva authored
Values assigned to variables Fmax and Fmin at lines 2740 and 2741 are overwritten at lines 2754 and 2755 before they can be used. This makes such variable assignments useless. Addresses-Coverity-ID: 1226952 Addresses-Coverity-ID: 1226953 Signed-off-by:
-
Mauro Carvalho Chehab authored
Avoid the following warning when building documentation: checking consistency... /devel/v4l/patchwork/Documentation/media/v4l-drivers/imx.rst:: WARNING: document isn't included in any toctree While here, avoid placing all driver authors at just one line at the html/pdf output. Acked-by:
Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
It is not trivial to implement the logic that collects DVBv5 statistics. As we're seein lately too many implementations that are not quite right when reviewing patchsets, add a detailed explanation, adding a few examples about the right thing to be done. Signed-off-by: -
Daniel Scheller authored
Signed-off-by:
-
Daniel Scheller authored
Side effect: KERN_DEBUG messages aren't written to the kernel log anymore. This also improves the tda18212_ping reporting a bit so users know that if pinging wasn't successful, bad things will happen. Since in module_init_ddbridge() there's no dev yet, pr_info is used instead. Signed-off-by:
-
Daniel Scheller authored
Reported by smatch: drivers/media/pci/ddbridge/ddbridge-core.c:1246 input_tasklet() warn: this loop depends on readl() succeeding drivers/media/pci/ddbridge/ddbridge-core.c:1768 flashio() warn: this loop depends on readl() succeeding drivers/media/pci/ddbridge/ddbridge-core.c:1788 flashio() warn: this loop depends on readl() succeeding Fix this by introducing safe_ddbreadl() which will wrap ddbreadl and checks for all bits set in the return which indicates failure, and return 0 in that case. Usable as drop-in-replacement in all affected while loops w/o having to change the logic. Signed-off-by:
-
Philipp Zabel authored
I would have liked the the picture run timeout error handler to be renamed to something a bit more descriptive in the original commit fb2be08f ("[media] coda: first step at error recovery"). Somehow v1 [1] was merged instead of v2 [2]. [1] https://patchwork.kernel.org/patch/9663965/ [2] https://patchwork.kernel.org/patch/9774239/Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Colin Ian King authored
The current pre-decrement is incorrect and should be replaced with a post-decrement. Consider the case where the very first clk_prepare_enable fails when i is 0; in this case the error clean up will decrement the unsigned int which wraps to the largest unsigned int value causing an array out of bounds read on core->clks[i]. Detected by CoverityScan, CID#1446590 ("Out-of-bounds read") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Check return value from call to core->write(), so in case of error print error message, jump to goto label fail and eventually return. Addresses-Coverity-ID: 1226943 Signed-off-by:
-
