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>
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>
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>
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>
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>
This driver has printk continuation lines for debugging purposes.
Since commit 563873318d ("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>
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>
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/*
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>
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>
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>
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>
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>
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>
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>
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>
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>
Mauro Carvalho Chehab