Fix all other remaining checkpatch.pl compliants on the Siano driver,
except for the 80-cols (soft) limit. Those are harder to fix, and
probably not worth to do right now.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove the remaining CamelCase checkpatch.pl compliants.
There are still a few left, but those are due to USB and
DVB APIs.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix the remaining checkpatch.pl compliants at smscoreapi.h,
except by the "line over 80 characters" on comments. Fixing those
would require more time, as the better is to convert them into the
struct descriptions used inside the kernel, as described at:
Documentation/kernel-doc-nano-HOWTO.txt
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are several structures defined in uppercase. Convert them
to lowercase, and simplify their names, when possible.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is almost impossible to see a compliant with checkpatch.pl
on those Siano drivers, as there are simply too much violations
on it. So, now that a big change was done, the better is to
cleanup the checkpatch compliants.
Let's first replace all CammelCase symbols found at smscoreapi.h
using camel_case namespace. That removed 144 checkpatch.pl
compliants on this file. Of course, the other files need to be
fixed accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are too many firmwares there. As we need to add
MODULE_FIMWARE() macros, the better is to define their names
on just one place and use the macros for both cards/device type
tables and MODULE_FIRMWARE().
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When the driver is tuned into chanel, and it is removed/reinserted,
the message stream data may be arriving during device probe:
[ 5680.162004] smscore_set_device_mode: set device mode to 6
[ 5680.162267] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.162391] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.162641] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.162891] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.163016] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.163266] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.163516] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.163640] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.163891] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.164016] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.164265] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.164515] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.164519] smscore_onresponse: Firmware id 6 prots 0x40 ver 8.1
[ 5680.164766] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.166018] smscore_onresponse: message MSG_SMS_DVBT_BDA_DATA(693) not handled.
[ 5680.166438] DVB: registering new adapter (Siano Rio Digital Receiver)
Instead of complaining, just silently discard those messages, instead of
complaining.
A proper fix is to put the device on suspend/power down mode when the module
is removed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
sms_debug() and sms_info() already adds a '\n' at the printed
strings. No need to add more.
That helps to cleanup stuff like:
[ 4868.205648] smscore_onresponse: message not handled.
[ 4868.205898] smscore_onresponse: message not handled.
and:
[ 5467.959769] smscore_onresponse:
data rate 143069 bytes/secs
While here, provides the message name, when the message is not
handled by the smsmdtv core.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Put this function earlier in the code, to avoid the need of
defining a function stub.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is an special lookup code that is called when
SMS_BOARD_UNKNOWN. The logic there is bogus and will cause
an oops, as .type is SMS_UNKNOWN_TYPE (-1).
As the code would do:
return smscore_fw_lkup[type][mode];
That would mean that it would try to go past the
smscore_fw_lkup table.
So, just remove that bogus code, simplifying the logic.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using a global default_mode, passed via modprobe
parameter, use the one defined inside the cards struct.
That will prevent the need of manually specify it for each
board, except, of course, if the user wants to do something
different, on boards that accept multiple types.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are two ways to specify firmware for siano devices: a
per-device ID and a per-device type.
The per-device type logic is currently made by a 11x9 string
table, sparsely filled. It is very hard to read the table at
the source code, as there are too much "none" filling there
("none" there is a way to tell NULL).
Instead of using such problematic table, convert it into an
easy to read table, where the unused values will be defaulted
to NULL.
While here, also simplifies a little bit the logic and print
a message if an user-selected mode doesn't exist.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Implement poll() method for debugfs and be sure that the
debug_data won't be freed on ir or on read().
With this change, poll() will return POLLIN if either data was
filled or if data was read. That allows read() to return 0
to indicate EOF in the latter case.
As poll() is now provided, fix support for non-block mode.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This seems to be ever broken. That's the status report with
Firmware 2.1, before adding support for sms2270 is:
[22273.787218] smsdvb_onresponse: MSG_SMS_GET_STATISTICS_RES
[22273.792592] IsRfLocked = 1
[22273.792592] IsDemodLocked = 1
...
[22273.792598] TransmissionMode = -64
...
(all unshown fields are filled with zeros)
Of course, transmission mode being a negative number is wrong.
So, we need to take a deeper look on it.
With the debugfs patches applied, it is possible to see that, instead
of filling StatisticsType with 5, and FullSize with the size of the
payload (this is what happens with sms2270 and firmware 8.1),
those fields are also initialized with zero:
StatisticsType = 0 FullSize = 0
IsRfLocked = 1 IsDemodLocked = 1 IsExternalLNAOn = 0
SNR = 0 dB RSSI = 0 dBm InBandPwr = 0 dBm
CarrierOffset = 0 Bandwidth = 0 Frequency = 0 Hz
TransmissionMode = -64 ModemState = 0 GuardInterval = 0
SystemType = 0 PartialReception = 0 NumOfLayers = 0
SmsToHostTxErrors = 0
The data under "TransmissionMode" varies according with the signal,
and it is negative. It also matches the value for InBandPwr when
the tuner is on DVB-T (ok, signal doesn't lock, but the power level
should be about the same with the antena fixed, and measured at about
the same time).
So, there's a very high chance that, when StatisticsType is zero, the
signal strength is at the same position as Transmission Mode.
So, discard all other parameters, and provide only signal/rf lock and
signal strength if StatisticsType is 0, for ISDB-T.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Right now, the driver sends DVB data even before tunning.
It was noticed that this may lead into some mistakes at DVB
decode, as the PIDs from wrong channels may be associated with
another frequency, as they may already be inside the PID buffers.
So, prevent it by not feeding DVB demux with data while there's no
feed or while the device is not tuned.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It was expected that the bandwidth would be following the defines
at smscoreapi.h. However, this doesn't work. Instead, this field
brings just the bandwidth in MHz. Convert it to Hertz.
It should be noticed that, on ISDB, using the _EX request, the
field TuneBW seems to show the value that matches the bandwidth
code.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The check for lock logic is broken. Due to that, no PER/BER
stats will ever be showed, and the DVBV3 events will be wrong.
Also, the per-layer PER/BER stats for ISDB-T are filled with
the wrong index.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are a number of small issues with the stats refactoring:
- InBandPwr better represents the signal strength;
- Don't zero signal strength /cnr if no lock;
- Fix signal strength/cnr scale;
- Don't need to fill PER/BER if not locked, as the
code will disable those stats anyway.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As each DVBv3 call may generate an stats overhead, prevent doing
it too fast. This is specially useful if a burst of get stats
DVBv3 call is sent.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Those fields help to identify the version of the ISDB stats.
Useful while debuging the driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
To avoid mixing two different things at the same place, move the
debugfs code into a separate file.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Outputs the result of the statistics responses via debugfs.
That can help to track bugs at the stats filling.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It seems that the first u32 after the header for some stats are used by
something not documented.
The stats struct starts after it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While this frontend provides a nice set of statistics, the
way it is currently reported to userspace is poor. Worse than
that, instead of using quality indicators that range from 0 to 65535,
as expected by userspace, most indicators range from 0 to 100.
Improve it by using DVBv5 statistics API. The legacy indicators
are still reported using the very same old way, but they're now
using a proper range (0 to 65535 for quality indicadors; 0.1 dB
for SNR).
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is confusing to merge both status updates with debug stuff.
Also, it is a better idea to move those status updates to
debugfs, instead of doing a large amount of printk's like that.
So, break them into a separate block of routines.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of handling both DVB-T and ISDB-T at the same get_frontend
function, break it intow one function per-delivery system.
That makes the code clearer as we start to add support for DVBv5
statistics, and for ISDB-T get frontend stuff.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, every time a message is sent or received, the endiannes
need to be fixed on big endian machines. This is currently done
on every call to the send API, and on every msg reception logic.
Instead of doing that, move it to the send/receive functions.
That simplifies the logic and avoids the risk of forgetting to
fix it somewhere.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The old statistics request don't work with newer firmwares.
Add a logic to use the newer stats if firmware major is 8.
Note that I have only 2 devices here, one with firmware 2.1
(Hauppauge model 55009 Rev B1F7) and another one with
firmware 8.1. We may need to adjust the firmware minimal
version for the *_EX message variants, as we start finding
firmware versions between 2.x and 8.x.
This patch was based on Doron Cohen patch:
http://patchwork.linuxtv.org/patch/7886/
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of re-use tune_done also for stats, the better is to use
a different completion.
Also, it was noticed that sometimes, the driver answers with
MSG_SMS_SIGNAL_DETECTED_IND for status request. Fix the code to
also handle those other signal indicators.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some cleanups at smscoreapi. Most are just CodingStyle.
Also, use kzalloc when allocating a new buffer, as it initializes
the allocated space with zero.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Without smsdvb, the driver actually does nothing, as it
lacks the userspace API.
While I wrote it independently, in order to make a sms2270 board
I have here to work, this patch is functionally identical to this
patch from Doron Cohen:
http://patchwork.linuxtv.org/patch/7894/
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Don't keep in the dark: report the firmware file name after
lookup. That helps to debug what's happening when a firmware is not
found.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are new firmwares for sms2xxx devices. Change the firmware
load logic to handle those newer firmwares and devices.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As there are some changes that seem to be firmware-dependent,
we need to store the firmware version, as we don't want to break
support for existing cards that use a legacy (and sometimes
custom) firmware.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Board #0 is an existing one. Instead of initializing the driver
with it, use a different value to detect if board is unknown.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add the remaining new defines/enums from Doron Cohen's patch:
http://patchwork.linuxtv.org/patch/7882/
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of printing a message for some random messages, print
it for all sent/received ones. That helps a lot to debug
what's going on.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert from #define into an enum and add the newer message
macros as found on this patch from Doron Cohen:
http://patchwork.linuxtv.org/patch/7882/
No messages got supressed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The same GPIO config struct was declared twice at the
driver, with different names and different macros:
struct smscore_config_gpio
struct smscore_config_gpio
Remove the one that uses CamelCase and fix the references to
its attributes/macros.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Those new definitions came from this patch, from Doron Cohen:
http://patchwork.linuxtv.org/patch/7882/
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Siano changed the namespace on more recent API, and re-used some
of the old names. In order to be able to update the API to support
newer chips, the better is to follow this change.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While running checkpatch.pl after the last patch, I noticed
lots of those:
WARNING: please, no space before tabs
#151: FILE: drivers/media/common/tveeprom.c:99:
+^I{ TUNER_ABSENT, ^I^I"None" },$
(together with other checkpatch.pl errors/warnings)
While I won't be fixing everything, as I have already an
script to fix the above, let's do it, in order to clean it
a little bit.
While here, also drop cmacs-specific format text at the end.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The tveeprom module is a helper module for Hauppauge-based eeproms.
It's used by many drivers and the i2c part is actually optional, so this
driver is better placed in the media/common directory.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The btcx-risc module is a helper module for bttv/conexant based TV cards.
It isn't an i2c module at all, instead it should be in common since it is
used by 4 pci drivers.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The cx2341x module is a helper module for conexant-based MPEG encoders.
It isn't an i2c module at all, instead it should be in common since it is
used by 7 pci and usb drivers to handle the MPEG setup.
It also shouldn't be visible in the config menu as it is always
selected automatically by those drivers that need it.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use uninterruptible mutex_lock in the release() file op to make sure all
resources are properly freed when a process is being terminated. Returning
-ERESTARTSYS has no effect for a terminating process and this may cause driver
resources not to be released.
This was found using the following semantic patch (http://coccinelle.lip6.fr/):
<spml>
@r@
identifier fops;
identifier release_func;
@@
static const struct v4l2_file_operations fops = {
.release = release_func
};
@depends on r@
identifier r.release_func;
expression E;
@@
static int release_func(...)
{
...
- if (mutex_lock_interruptible(E)) return -ERESTARTSYS;
+ mutex_lock(E);
...
}
</spml>
Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert drivers using wall clock time (CLOCK_REALTIME) to timestamp from the
monotonic timer (CLOCK_MONOTONIC).
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Stephen:
After merging the v4l-dvb tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "sms_ir_exit" [drivers/media/common/siano/smsmdtv.ko] undefined!
ERROR: "sms_ir_event" [drivers/media/common/siano/smsmdtv.ko] undefined!
ERROR: "sms_ir_init" [drivers/media/common/siano/smsmdtv.ko] undefined!
The smsir file should be part of the smsmdtv core, if RC is defined.
Fix it.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This reverts commit 6ee28d94c9.
The patch got some alien code there, not sure why. Revert it to apply
it properly.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Stephen:
After merging the v4l-dvb tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "sms_ir_exit" [drivers/media/common/siano/smsmdtv.ko] undefined!
ERROR: "sms_ir_event" [drivers/media/common/siano/smsmdtv.ko] undefined!
ERROR: "sms_ir_init" [drivers/media/common/siano/smsmdtv.ko] undefined!
The smsir file should be part of the smsmdtv core, if RC is defined.
Fix it.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Antti and by Stephen:
drivers/built-in.o: In function `sms_ir_event':
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c:48: undefined reference to `ir_raw_event_store'
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c:50: undefined reference to `ir_raw_event_handle'
drivers/built-in.o: In function `sms_ir_init':
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c:56: undefined reference to `smscore_get_board_id'
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c:60: undefined reference to `rc_allocate_device'
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c:72: undefined reference to `sms_get_board'
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c:92: undefined reference to `sms_get_board'
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c:97: undefined reference to `rc_register_device'
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c💯 undefined reference to `rc_free_device'
drivers/built-in.o: In function `sms_ir_exit':
/home/david/checkouts/linux/drivers/media/common/siano/smsir.c:111: undefined reference to `rc_unregister_device'
make: *** [vmlinux] Error 1
Caused by commit fdd1eeb49d "[media] siano: allow compiling it without RC support"
And it happens when CONFIG_SMS_SIANO_RC=y and CONFIG_RC_CORE=m .
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected.
Functions like rc_keydown() and functions which add/remove entries to the
keytable want a single protocol. Future userspace APIs would also
benefit from numeric protocols (rather than bitmap ones). Keytables are
smaller if they can use a small(ish) integer rather than a bitmap.
Other functions or struct members (e.g. allowed_protos,
enabled_protocols, etc) accept multiple protocols and need a bitmap.
Using different types reduces the risk of programmer error. Using a
protocol enum whereever possible also makes for a more future-proof
user-space API as we don't need to worry about a sufficient number of
bits being available (e.g. in structs used for ioctl() calls).
The use of both a number and a corresponding bit is dalso one in e.g.
the input subsystem as well (see all the references to set/clear bit when
changing keytables for example).
This patch separate the different usages in preparation for
upcoming patches.
Where a single protocol is expected, enum rc_type is used; where one or more
protocol(s) are expected, something like u64 is used.
The patch has been rewritten so that the format of the sysfs "protocols"
file is no longer altered (at the loss of some detail). The file itself
should probably be deprecated in the future though.
Signed-off-by: David Härdeman <david@hardeman.nu>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Those items don't have any menu anymore; they're auto-selected by
USB/PCI/MMC drivers. So, there's no sense on keeping any help
there anymore.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remote controller support should be optional on all drivers.
Make it optional at Siano's driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Write-only ioctls should have a const argument in the ioctl op.
Do this conversion for vidioc_s_fbuf.
Adding const for write-only ioctls was decided during the 2012 Media Workshop.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of having 3 options to allow customizing the media
sub-drivers (tuners, I2C drivers, frontends), merge all of
them into just one.
That simplifies the life for users, as they can just keep
this untouched.
Life for developers is also simpler, as there's now just
one Kconfig item to remember, for the ancillary sub-drivers
providing supports for chips that could change from one
board design to another.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On a few places, := were using instead of +=, causing drivers to
not compile.
While here, standardize the usage of += on all cases where multiple
lines are needed, and for obj-y/obj-m targets, and := when just one
line is needed, on <module>-obj rules.
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Identified-by: Antti Polosaari <crope@iki.fi>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
siano is, in fact, 2 drivers: one for MMC and one for USB, plus
a common bus-independent code. Break it accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In order to better organize the directory tree, move the
saa7146 common driver to its own directory.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move the tuners one level up, as the "common" directory will be used
by drivers that are shared between more than one driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
b2c2 is, in fact, 2 drivers: one for PCI and one for USB, plus
a common bus-independent code. Break it accordingly.
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>
just like the V4L2 core, move the DVB core to drivers/media, as the
intention is to get rid of both "video" and "dvb" directories.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
qt1010_init_meas2() returns zero on success and negative error codes on
failure so the return type should be int instead of u8.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The original xc5000c driver support was based on a beta version of the
firmware, and there were no redistribution rights. Change over to using
the release version, for which freely redistributable firmware can be
found here:
http://kernellabs.com/firmware/xc5000/README.xc5000chttp://kernellabs.com/firmware/xc5000/dvb-fe-xc5000c-4.1.30.7.fw
Thanks to Ramon Cazares from Cresta Technology for making the firmware
available as well as working out the licensing issues.
[mchehab@redhat.com: Fix a merge conflict with the patch that added support
for MODULE_FIRMWARE() macro]
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver prints out a dotted version number but it's in hex. As a
result, the version doesn't visibly match the filename for the firmware,
and it caused a bunch of confusion while discussing different versions
with the chip manufacturer.
Change the firmware printout to be in decimal.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The xc5000c and newer versions of the xc5000a firmware need minor revisions
to their initialization process. Add support for validating the firmware
was properly loaded, as well as checking the init status after initialization.
Based on advice from CrestaTech support as well as xc5000 datasheet v2.3.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It's possible for the xc5000 to enter an unknown state such that all
subsequent tuning requests fail. The only way to recover is to reset the
tuner and reload the firmware. This problem was detected after several days
straight of issuing tuning requests every five seconds.
Reset the firmware in the event that the PLL is in an unlocked state. This
solution was provided by the engineer at CrestaTech (the company that acquired
Xceive).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The current code invokes the auto calibration of the tuner whenever the
init routine is called (whenever the DVB frontend opens the device).
However we should really only be invoking the calibration if we actually
did reset the device and reload the firmware.
Rework the routine to only do calibration if reset and firmware load was
performed. Also because the called function is now a no-op if the
firmware is already loaded, the caller no longer needs to invoke
is_firmware_loaded().
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The logic as written would *never* actually return an error condition,
since the loop would run until the counter hit zero but the check was
for a value less than zero.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When debugging is enabled, also show the analog SNR and the total gain
status values.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The quality register only has relevant data in bits 2-0, so discard the
other bits (which results in a value being printed that is consistent
with the expected 0-7 range).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add proper locking to the file operations, allowing for the removal
of the V4L2_FL_LOCK_ALL_FOPS flag.
I also removed some dead code in the form of the saa7146_devices list and
saa7146_devices_lock mutex: these were used once but that was a long time
ago.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This will make modinfo more useful with regard
to discovering necessary firmware files.
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Michael Krufky <mkrufky@kernellabs.com>
Cc: Eddi De Pieri <eddi@depieri.net>
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We need to do a mutex_unlock(&priv->lock) before returning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We intended to do a compare here, not an assignment.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When tuner-xc2028 is not compiled as a module, dracut will
need to copy the firmware inside the initfs image.
So, use MODULE_FIRMWARE() to indicate such need.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the past, it was possible to have either DVB or V4L2 core
as module and the other as builtin. Such config never make much
sense, and created several issues in order to make the Kconfig
dependency to work, as all drivers that depend on both (most
TV drivers) would need to be compiled as 'm'. Due to that,
the VIDEO_MEDIA config option were added.
Instead of such weird approach, let's just use the MEDIA_SUPPORT
=y or =m to select if the media subsystem core will be either
builtin or module, simplifying the building system logic.
Also, fix the tuners configuration, by enabling them only if
a tuner is required. So, if just webcam/grabbers support is
selected, no tuner option will be selected. Also, if only digital
TV is selected, no analog tuner support is selected.
That removes the need of using EXPERT customise options, when
analog TV is not selected.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change the main items to:
<m> Multimedia support --->
[ ] Cameras/video grabbers support
[ ] Analog TV support
[ ] Digital TV support
[ ] AM/FM radio receivers/transmitters support
[ ] Remote Controller support
This provides an interface that is clearer to end users that
are compiling the Kernel, and will allow the building system
to automatically unselect drivers for unused functions.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
xc5000 is just a tuner, not a decoder, so both DMB-TH and ISDB-T should
work properly there: it is just a matter of teaching the driver what
saw filter should be used and how to calculate the center frequency.
Requested-by: Choi Wing Chan <chanchoiwing@gmail.com>
Cc: Steven Toth <stoth@linuxtv.org>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Implement API support to return AFC frequency shift, as this device
supports it. The only other driver that implements it is tda9887,
and the frequency there is reported in Hz. So, use Hz also for this
tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are several bugs at the signal strength algorithm:
- It is using logical OR, instead of bit OR;
- It doesn't wait up to 18 ms as it should;
- the strength range is not ok.
Rework on it, in order to make it work.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change the firmware logic to use request_firmware_nowait(), and
to preserve the loaded firmwares in memory, to reduce the risk
of troubles with buggy userspace apps.
With this change, while the firmware is being loaded, the driver
will return -EAGAIN to any calls. If, for some reason, firmware
failed to be loaded from userspace, it will return -ENODEV.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In function fops_open variable type was set but not used. Tested by compilation only.
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Michael Hunold <michael@mihu.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Changes compared to version 0.1 of driver (sent 6 May):
- Initial implementation of get_rf_strength function.
- Introduction of a warning message
Signed-off-by: Hans-Frieder Vogt <hfvogt@gmx.net>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Common defines for the FC0012 (v0.5) and FC0013 tuner drivers
Signed-off-by: Hans-Frieder Vogt <hfvogt@gmx.net>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Besides the usual inconsistencies in input enumeration there was also a
kernel crash if you tried to poll on a vbi node. The checks for sliced
vbi output vs vbi capture were not complete enough.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The querycap ioctl returned an incorrect version number and incorrect
capabilities (mixing up vbi and video caps).
The reason for that was that video nodes could do vbi activities: that
should be separated between the vbi and video nodes.
There were also a few minor problems with dbg_g/s_register that have
been resolved. The mxb/saa7146 driver now passes the v4l2_compliance tests.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use v4l2_fh which gives you control events and priority handling for free.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was also a vbi_q and video_q in saa7146_fh, so that was confusing.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This information can also be retrieved from struct video_device.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This fields are global and don't belong in a fh struct.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a global structure and does not belong to saa7146_fh.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is global information, not per-filehandle information.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert to the control framework, fix the easy v4l2-compliance failures.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This used to be the default if the lock pointer was set, but now that lock is by
default only used for ioctl serialization. Those drivers that already used
core locking have this flag set explicitly, except for some drivers where
it was obvious that there was no need to serialize any file operations other
than ioctl.
The drivers that didn't need this flag were:
drivers/media/radio/dsbr100.c
drivers/media/radio/radio-isa.c
drivers/media/radio/radio-keene.c
drivers/media/radio/radio-miropcm20.c
drivers/media/radio/radio-mr800.c
drivers/media/radio/radio-tea5764.c
drivers/media/radio/radio-timb.c
drivers/media/video/vivi.c
sound/i2c/other/tea575x-tuner.c
The other drivers that use core locking and where it was not immediately
obvious that this flag wasn't needed were changed so that the flag is set
together with a comment that that driver needs work to avoid having to
set that flag. This will often involve taking the core lock in the fops
themselves.
Eventually this flag should go and it should not be used in new drivers.
There are a few reasons why we want to avoid core locking of non-ioctl
fops: in the case of mmap this can lead to a deadlock in rare situations
since when mmap is called the mmap_sem is held and it is possible for
other parts of the code to take that lock as well (copy_from_user()/copy_to_user()
perform a down_read(&mm->mmap_sem) when a page fault occurs).
It is very unlikely that that happens since the core lock serializes all
fops, but the kernel warns about it if lock validation is turned on.
For poll it is also undesirable to take the core lock as that can introduce
increased latency. The same is true for read/write.
While it was possible to make flags or something to turn on/off taking the
core lock for each file operation, in practice it is much simpler to just
not take it at all except for ioctl and leave it to the driver to take the
lock. There are only a handful fops compared to the zillion ioctls we have.
I also wanted to make it obvious which drivers still take the lock for all
fops, so that's why I chose to have drivers set it explicitly.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rather than loading firmware specific for the xtal frequency, just use
the standard firmware and set the xtal frequency after firmware upload.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that i2c transfers are fixed, 3 retries are enough.
Signed-off-by: Michael Buesch <m@bues.ch>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use usleep_range() instead of msleep() to improve power saving opportunities.
Signed-off-by: Michael Buesch <m@bues.ch>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds support for the Fitipower fc0011 DVB-t tuner.
Signed-off-by: Michael Buesch <m@bues.ch>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Without this we have got the warnings like following if build with "make W=1
O=/var/tmp":
cc1: warning: drivers/media/dvb/dvb-core: No such file or directory [enabled by default]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Commit 99ac541254 removed
the function mt2063_setTune() from mt2063.c. Remove it
also from the header file.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Specify chip revision at attach time rather than a firmware image.
This is a better way to ensure that the correct firmware is loaded
for the correct revision of the chip.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
convert the firmware configuration attach-time parameter from
a pointer to an integer so as to remove the static dependency
created by the previous changesets.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
newer versions of the xc5000 silicon require newer firmware
while remaining 100% driver compatible. original versions
of the xc5000a continue to use the same firmware.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix for some -Wuninitialized compiler warnings.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Increase mt2063 frequency_max to tune to channel 69(858Mhz).
Jose Alberto
Signed-off-by: Jose Alberto Reguero <jareguero@telefonica.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some changes are needed, in order to make az6007 compile with the
upstream tree. Most of the changes are due to the upstream drxk
module.
Even allowing its compilation, the driver is not working yet.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In xc4000 chipsets real signal and noise level is stored in register
0x0A and 0x0B,so we can use those registers to monitor signal strength.
I tested this patch on 2 different cards Leadtek DVR3200 and DTV2000H
Plus, both with same results, I used special antenna hubs (toner 4x, 6x,
8x and 12x) with mesured signal lost, both registers are in dB value,
first represent signal with limit value -113.5dB (should be -114dB) and
exactly match with test results. Second represents noise level also in
dB and there is no maximum value, but from tests we can drop everything
above 32dB which tuner realy can't use, signal was usable till 20dB
noise level.
In digital mode we can take signal strength but sadly noise level is not
relevant and real value is stored in demodulator for now just zl10353,
also digital mode is just for testing, because it needs changing other
parts of code which reads data only from demodulator.
In analog mode I was able to test only FM radio, signal level is not
important, it says something about cable and hub losts, but nothing
about real quality of reception, so even if we have signal level at
minimum 113dB we can still here radio, because of that it is displaied
only in debug mode, but for real signal level is used noise register
which is again very accurate, radio noise level was betwen 6-20dB for
good signal, 20-25dB for medium signal, and above 25dB signal is
unusable.
For now real benefit of this patch is only for FM radio mode.
Signed-off-by: Miroslav Slugen <thunder.mmm@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
DVB-T did not work at all - only 6 MHz was working but it is not
commonly used.
Fix it.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch replaces the previous one proposed in the thread "xc3028:
force reload of DTV7 firmware in VHF band with Zarlink demodulator",
at the linux-media@vger.kernel.org ML.
The problem is that the firmware DTV78 works fine in UHF band (8 MHz
bandwidth) but is not working at all in VHF band (7 MHz bandwidth).
Reading the comments inside the code, I figured out that the real
problem could be connected to the formula used to calculate the center
frequency offset in VHF band.
In fact, removing this adjustment fixes the problem:
if ((priv->cur_fw.type & DTV78) && freq < 470000000)
offset -= 500000;
This is coherent to what was implemented for the DTV7 firmware by an
Australian user:
if (priv->cur_fw.type & DTV7)
offset += 500000;
In the end, now the center frequency is the same for all firmwares
(DTV7, DTV8, DTV78) and doesn't depend on channel bandwidth.
The final code looks clean and simple, and there is no need for any
"magic" adjustment:
if (priv->cur_fw.type & DTV6)
offset = 1750000;
else /* DTV7 or DTV8 or DTV78 */
offset = 2750000;
Signed-off-by: Gianluca Gennari <gennarone@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now, ops->info.type is handled inside the dvb_frontend
core, only for DVBv3 calls, and according with the
delivery system. So, drivers should not care or use it,
otherwise, it may have issues with DVBv5 calls.
The drivers that were still using it were detected via
this small temporary hack:
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -29,13 +29,16 @@
#include <linux/types.h>
typedef enum fe_type {
+#if defined(__DVB_CORE__) || !defined (__KERNEL__)
FE_QPSK,
FE_QAM,
FE_OFDM,
FE_ATSC
+#else
+FE_FOOO
+#endif
} fe_type_t;
-
typedef enum fe_caps {
FE_IS_STUPID = 0,
FE_CAN_INVERSION_AUTO = 0x1,
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The per-delivery system tables are confusing.
Add an extra table that explains them, and some
dprintk calls, that allows to check if mt2063 driver
is working as expected.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of printing it just for debug purposes, outputs the detected
version at the logs. This may be useful if someone wants to report
a problem.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While here, improve a few debug messages that helped to track the
issue and may be useful in the future.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This also helps to identify when a device is not initialized,
if the bridge doesn't return an error for a I2C failed transfer.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Mauro Carvalho Chehab