Nobody is maintaining this driver. The project started by a
developer that used to work at Hauppauge. A Siano developer
assumed its maintainership after that, but he left the company.
Another Siano developer sent several patches updating it, but,
after upstream feedback, it seems he gave up merging the driver,
as he never answered back to the received feedbacks.
As I have a few siano devices here that work with ISDB-T, I
can help to keep it into a good shape. So, better to take its
maintainership.
I don't have any siano SDIO setup here, trough. So, I'll just
apply without any test any patch that looks sane and touches
only drivers/media/mmc/siano. So, let's tag it as "Odd fixes".
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>
Instead of using hardcoded descriptors, detect them from the
USB descriptors.
This patch is rebased form Doron Cohen's patch:
http://patchwork.linuxtv.org/patch/7883/
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>
The use of V4L2_IN/OUT_CAP_CUSTOM_TIMINGS is obsolete, use DV_TIMINGS instead.
Note that V4L2_IN/OUT_CAP_CUSTOM_TIMINGS is just a #define for
V4L2_IN/OUT_CAP_DV_TIMINGS.
At some point in the future these CUSTOM_TIMINGS defines might be removed.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/platform/davinci/dm644x_ccdc.c: In function ‘validate_ccdc_param’:
drivers/media/platform/davinci/dm644x_ccdc.c:233:32: warning: comparison between ‘enum ccdc_gama_width’ and ‘enum ccdc_data_size’ [-Wenum-compare]
It took a bit of work, see this thread of an earlier attempt to fix this:
https://patchwork.kernel.org/patch/1923091/
I've chosen not to follow the suggestions in that thread since gamma_width is
really a different property from data_size. What you really want is to know if
gamma_width fits inside data_size and for that you need to translate each
enum into a maximum bit number so you can safely compare the two.
So I put in two static inline translation functions instead, keeping the rest
of the code the same (except for fixing the 'gama' typo).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since vpfe_capture already provided a g_std op setting current_norm
does not actually do anything. Remove it.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since vpbe_display already provides a g_std op setting current_norm
didn't do anything. Remove that code.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
