summaryrefslogtreecommitdiffstats
path: root/drivers/media/dvb-frontends/stb0899_drv.c
Commit message (Collapse)AuthorAgeFilesLines
* media: dvb: represent min/max/step/tolerance freqs in HzMauro Carvalho Chehab2018-08-021-4/+2
| | | | | | | | | | | | | | | | Right now, satellite frontend drivers specify frequencies in kHz, while terrestrial/cable ones specify in Hz. That's confusing for developers. However, the main problem is that universal frontends capable of handling both satellite and non-satelite delivery systems are appearing. We end by needing to hack the drivers in order to support such hybrid frontends. So, convert everything to specify frontend frequencies in Hz. Tested-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
* media: replace all <spaces><tab> occurrencesMauro Carvalho Chehab2018-01-041-5/+5
| | | | | | | There are a lot of places where sequences of space/tabs are found. Get rid of all spaces before tabs. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* media: move dvb kAPI headers to include/mediaMauro Carvalho Chehab2017-12-281-1/+1
| | | | | | | | Except for DVB, all media kAPI headers are at include/media. Move the headers to it. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* media: dvb-frontends: fix i2c access helpers for KASANArnd Bergmann2017-12-151-1/+2
| | | | | | | | | | | | | | | | | | | | | A typical code fragment was copied across many dvb-frontend drivers and causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7: drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] gcc-8 now solves this by consolidating the stack slots for the argument variables, but on older compilers we can get the same behavior by taking the pointer of a local variable rather than the inline function argument. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] stb0899: move code to "detach" callbackMax Kellermann2016-11-181-2/+9
| | | | | | | Ensure that STB0899_POSTPROC_GPIO_POWER is set synchronously. Signed-off-by: Max Kellermann <max.kellermann@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] dvb: make DVB frontend *_ops instances "const"Max Kellermann2016-11-181-1/+1
| | | | | | | | | | | | | These are immutable. Making them "const" allows the compiler to move them to the "rodata" section. Note that cxd2841er_t_c_ops cannot be made "const", because cxd2841er_attach() modifies it. Ouch! [mchehab@s-opensource.com: fix merge conflicts] Signed-off-by: Max Kellermann <max.kellermann@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] stb0899_drv: get rid of continuation linesMauro Carvalho Chehab2016-11-181-17/+4
| | | | | | | | | | This driver has printk continuation lines for debugging purposes. Since commit 563873318d32 ("Merge branch 'printk-cleanups'")', this won't work as expected anymore. So, use %*ph and get rid of it. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] dvb_frontend: pass the props cache to get_frontend() as argMauro Carvalho Chehab2016-02-041-2/+2
| | | | | | | | | | | | | | | | | Instead of using the DTV properties cache directly, pass the get frontend data as an argument. For now, everything should remain the same, but the next patch will prevent get_frontend to affect the global cache. This is needed because several drivers don't care enough to only change the properties if locked. Due to that, calling G_PROPERTY before locking on those drivers will make them to never lock. Ok, those drivers are crap and should never be merged like that, but the core should not rely that the drivers would be doing the right thing. Reviewed-by: Michael Ira Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* [media] dvb: Get rid of typedev usage for enumsMauro Carvalho Chehab2015-06-091-3/+5
| | | | | | | | | | | | | | | | | The DVB API was originally defined using typedefs. This is against Kernel CodingStyle, and there's no good usage here. While we can't remove its usage on userspace, we can avoid its usage in Kernelspace. So, let's do it. This patch was generated by this shell script: for j in $(grep typedef include/uapi/linux/dvb/frontend.h |cut -d' ' -f 3); do for i in $(find drivers/media -name '*.[ch]' -type f) $(find drivers/staging/media -name '*.[ch]' -type f); do sed "s,${j}_t,enum $j," <$i >a && mv a $i; done; done While here, make CodingStyle fixes on the affected lines. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> # for drivers/media/firewire/*
* [media] media: stb0899_drv: use time_after()Asaf Vertz2015-01-271-3/+4
| | | | | | | | | To be future-proof and for better readability the time comparisons are modified to use time_after() instead of plain, error-prone math. Signed-off-by: Asaf Vertz <asaf.vertz@tandemg.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* [media] stb0899: don't go past DiSEqC msg bufferMauro Carvalho Chehab2014-11-051-1/+1
| | | | | | | | | | As reported by spatch: drivers/media/dvb-frontends/stb0899_drv.c:720 stb0899_send_diseqc_msg() error: buffer overflow 'cmd->msg' 6 <= 7 The buffer size is 6 and not 8. Anyway, the best is to use sizeof(), to avoid such mistakes. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* [media] stb0899_drv: Don't use dynamic static allocationMauro Carvalho Chehab2013-11-081-1/+11
| | | | | | | | | | | | | | | | | | Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/stb0899_drv.c:540:1: warning: 'stb0899_write_regs' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] stb0899: restore minimal rate to 5MbaudsMauro Carvalho Chehab2013-07-051-1/+1
| | | | | | | | | | | According with Manu Abraham, stb0899 seek algorithm is broken for symbol rates bellow to 5Mbauds. So, revert those patches: 55b3318 [media] stb0899: allow minimum symbol rate of 2000000 2eeed77 [media] stb0899: allow minimum symbol rate of 1000000 Requested-by: Manu Abraham <abraham.manu@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] stb0899: store successful inversion for next runReinhard Nißl2013-06-081-3/+2
| | | | | | | | | Usually, inversion doesn't change in a system. Storing the last successful inversion value speeds up tuning of DVB-S2 transponders. Signed-off-by: Reinhard Nißl <rnissl@gmx.de> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] stb0899: allow minimum symbol rate of 2000000Zoran Turalija2013-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like product datasheets for tuners containing STB0899 are suggesting specification for min. symbol rate of 2MS/s. Some specs found here, all suggesting 2MS/s for min. symbol rate: Comtech DVBS2-6899 http://comtech.sg1002.myweb.hinet.net/pdf/dvbs2-6899.pdf TechniSat SkyStar HD2 http://www.scaistar.com/skystar2/skystarhd2.htm Azurewave AD-SP400 http://www.pulsat.com/products/AzureWave-AD%252dSP400-High-Definition-PC-Card.html New patch: This makes minimum symbol rate driver capabilities on par with some accessible datasheet specifications*, and allows tuning on linux to transponders that have symbol rate between 2000000-5000000, too. Patch was tested successfully on Eutelsat 16A transponders that became reachable with it (2000000 < symbol rate < 5000000): * DVB/S 12507050 V 2532000 3/4 * DVB/S2 12574000 V 4355000 3/4 8PSK * DVB/S 12593000 V 2500000 2/3 * DVB/S 12596940 V 2848000 2/3 * DVB/S 12600750 V 2500000 1/2 * DVB/S 12675590 H 4248000 3/4 (*) Datasheet: http://comtech.sg1002.myweb.hinet.net/pdf/dvbs2-6899.pdf Maximum Symbol Rate QPSK/LDPC/PCH: 20-30Mbps 8PSK/LDPC/BCH: 10-30Mbps DVB: 2-45Mbps ^--------- min. symbol rate Signed-off-by: Zoran Turalija <zoran.turalija@gmail.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] stb0899: allow minimum symbol rate of 1000000Zoran Turalija2013-06-081-1/+1
| | | | | | | | | | | | | | | | | | This makes minimum symbol rate driver capabilities on par with windows driver, and allows tuning on linux to transponders that have symbol rate below 5000000, too. Patch was tested successfully on Eutelsat 16A transponders that became reachable with it (1000000 < symbol rate < 5000000): * DVB/S 12507050 V 2532000 3/4 * DVB/S2 12574000 V 4355000 3/4 8PSK * DVB/S 12593000 V 2500000 2/3 * DVB/S 12596940 V 2848000 2/3 * DVB/S 12600750 V 2500000 1/2 * DVB/S 12675590 H 4248000 3/4 Signed-off-by: Zoran Turalija <zoran.turalija@gmail.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] stb0899_drv: get rid of warning: no previous prototypeMauro Carvalho Chehab2012-10-271-1/+1
| | | | | | drivers/media/dvb-frontends/stb0899_drv.c:1263:5: warning: no previous prototype for 'stb0899_get_dev_id' [-Wmissing-prototypes] Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] stb0899: return internally tuned frequency via get_frontend.Reinhard Nissl2012-09-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Am 14.08.2012 14:05, schrieb Manu Abraham: >> My other device, a STB0899, always reports the set frequency. So it seems >> driver dependent whether it reports the actually locked frequency found by >> the zig-zag-algorithm or just the set frequency to tune to. > > The STV0299 blindly sets the value based on a software zigzag (due to simpler > hardware), but this might not be accurate enough. On the other hand, the > STB0899 internally does zig-zag in hardware for DVB-S2, and partly in > software for DVB-S. > > In any event, the get_frontend callback should return the value that is read > from the demodulator registers, rather than the cached original value that > which was requested to be tuned. > > The stb0899 returns only the cached value IIRC. Maybe I will fix this soon, > or maybe you can send a patch. This is what I get after the patch: Sat. Pol. Band Freq (MHz) Set Freq (MHz) Get Delta (MHz) S19,2E H L 10744 10748,474 4,474 S19,2E H L 10773 10777,944 4,944 S19,2E H L 10832 10836,953 4,953 S19,2E H L 10861 10868,774 7,774 ... Signed-off-by: Reinhard Nißl <rnissl@gmx.de> Cc: Manu Abraham <abraham.manu@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] move the dvb/frontends to drivers/media/dvb-frontendsMauro Carvalho Chehab2012-08-131-0/+1651
Raise the DVB frontends one level up, as the intention is to remove the drivers/media/dvb directory. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
OpenPOWER on IntegriCloud