History log of /drivers/media/dvb/frontends/mb86a20s.c
Revision Date Author Comments
82033bc52abeb266cb3403e783a276d4a3d6cf9f 13-Jan-2012 Dan Carpenter <dan.carpenter@oracle.com> [media] mb86a20s: fix off by one checks

Clearly ">=" was intended here instead of ">".

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
ebe967492c681da781dbc0f7c0d6a1b5c1977d45 11-Jan-2012 Mauro Carvalho Chehab <mchehab@redhat.com> mb86a20s: Add a few more register settings at the init seq

Some time ago, Manoel sent us a patch adding more stuff
to the init sequence. However, his patch were also doing
non-related stuff, by changing the init logic without
any good reason. So, it was asked for him to submit a
patch with just the data that has changed, in order to
allow us to better analyze it.

As he didn't what it was requested, I finally found some
time to dig into his init sequence and add it here.

Basically, new stuff is added there. There are a few changes:

1) The removal of the extra (duplicated) logic that puts
the chip into the serial mode;
2) Some Viterbi VBER measurement init data was changed from
0x00 to 0xff for layer A, to match what was done for
layers B and C.

None of those caused any regressions and both make sense
on my eyes.

The other parameters additions actually increased the
tuning quality for some channels. Yet, some channels that
were previously discovered with scan disappered, while
others appeared instead. This were tested in Brasilia,
with an external antena.

At the overall, it is now a little better. So, better to
add these, and then try to figure out a configuration that
would get even better scanning results.

Reported-by: Manoel Pinheiro <pinusdtv@hotmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
a7025edfff2cf46fcbe15254a1718f82721ec2a5 11-Jan-2012 Mauro Carvalho Chehab <mchehab@redhat.com> mb86a20s: Group registers into the same line

On mb86a20s, some registers have sub-addresses, while others not.
In order to make easier to compare different settings, group them.

No functional changes in this patch.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
959a119f86d51085ba4e0ec5a68dee6a21c48dfe 09-Jan-2012 Mauro Carvalho Chehab <mchehab@redhat.com> [media] mb86a20s: implement get_frontend()

Reports the auto-detected parameters to userspace.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
7581e61d8d7a3ed89a3fdac2235231cd36548f78 01-Jan-2012 Mauro Carvalho Chehab <mchehab@redhat.com> [media] dvb: Remove ops->info.type from frontends

Now that this field is deprecated, and core generates it for
DVBv3 calls, remove it from the drivers.

It also adds .delsys on the few drivers where this were missed.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
7c61d80a9bcfc3fdec8ffd75756cad6a64678229 30-Dec-2011 Mauro Carvalho Chehab <mchehab@redhat.com> [media] dvb: don't require a parameter for get_frontend

Just like set_frontend, use the dvb cache properties for get_frontend.
This is more consistent, as both functions are now symetric. Also,
at the places get_frontend is called, it makes sense to update the
cache.

Most of this patch were generated by this small perl script:

while (<>) { $file .= $_; }
if ($file =~ m/\.get_frontend\s*=\s*([\d\w_]+)/) {
my $get = $1;
$file =~ s/($get)(\s*\([^\,\)]+)\,\s*struct\s+dtv_frontend_properties\s*\*\s*([_\d\w]+)\)\s*\{/\1\2)\n{\n\tstruct dtv_frontend_properties *\3 = &fe->dtv_property_cache;/g;
}
print $file;

Of course, the changes at dvb_frontend.[ch] were made by hand,
as well as the changes on a few other places, where get_frontend()
is called internally inside the driver.

On some places, get_frontend() were just a void function. Those
occurrences were removed, as the DVB core handles such cases.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
7e0722215a510921cbb73ab4c37477d4dcb91bf8 26-Dec-2011 Mauro Carvalho Chehab <mchehab@redhat.com> [media] dvb-core: Don't pass DVBv3 parameters on tune() fops

As all parameters are passed via DVBv5 to the frontends, there's
no need to pass them again via fops. Also, most drivers weren't using
it anyway. So, instead, just pass a parameter to indicate if the
hardware algorithm wants the driver to re-tune or not.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2d76e22b704559c111038a81bf52ecf4a127a90e 26-Dec-2011 Mauro Carvalho Chehab <mchehab@redhat.com> [media] mb86a20s: convert set_fontend to use DVBv5 parameters

Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.

Actually, this driver needs to fill/use the ISDB-T proprieties.

Also, fill the supported delivery systems at dvb_frontend_ops
struct.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
a689e3657d7e82c2271008553c709fc79fb2e038 22-Dec-2011 Mauro Carvalho Chehab <mchehab@redhat.com> [media] dvb-core: add support for a DVBv5 get_frontend() callback

Creates a DVBv5 get_frontend call, renaming the DVBv3 one to
get_frontend_legacy(), while not all frontends are converted.

After the conversion for all drivers, get_frontend_legacy()
will be removed.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
bc9cd2736b34619b58961d506210fe0e6dfaa27d 20-Dec-2011 Mauro Carvalho Chehab <mchehab@redhat.com> [media] Rename set_frontend fops to set_frontend_legacy

Passing DVBv3 parameters to set_frontend is not fun, as the
core doesn't have any way to know if the driver is using the
v3 or v5 parameters. So, rename the callback and add a new
one to allow distinguish between a mixed v3/v5 paramenter call
from a pure v5 call.

After having all frontends to use the new way, the legacy
call can be removed.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
14d24d148c7521b2b88b396652e36f55d061e195 24-Dec-2011 Mauro Carvalho Chehab <mchehab@redhat.com> [media] tuners: remove dvb_frontend_parameters from set_params()

This is a big patch, yet trivial: now that all tuners use the DVBv5
way to pass parameters (e. g. via fe->dtv_property_cache), the
extra parameter can be removed from set_params() call.

After this change, very few DVBv3 specific stuff are left at the
tuners.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
25985edcedea6396277003854657b5f3cb31a628 31-Mar-2011 Lucas De Marchi <lucas.demarchi@profusion.mobi> Fix common misspellings

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
c736a5f28e81299b05ad14e892bdfb414daa9f5f 14-Jan-2011 Mauro Carvalho Chehab <mchehab@redhat.com> [media] mb86a20s: Be sure that device is initialized before starting DVB

Due to a hard to track bug between tda829x/tda18271/saa7134, tda829x
wants to go to analog mode during DVB initialization, causing some
I2C errors.

The analog failure doesn't cause any harm, as the device were already
properly initialized in analog mode. However, the failure at the digital
mode causes the frontend mb86a20s to not initialize. Fortunately, at
least on my tests, it was possible to detect that the device is a
mb86a20s before the failure.

What happens is that tda8290 is a very bad boy: during DVB setup, it
keeps insisting to call tda18271 analog_set_params, that calls
tune_agc code. The tune_agc code calls saa7134 driver, changing the
value of GPIO 27, switching from digital to analog mode and disabling
the access to mb86a20s, as, on Kworld SBTVD, the same GPIO used
to switch the hardware AGC mode seems to be used to enable the I2C
switch that allows access to the frontend (mb86a20s).

So, a call to analog_set_params ultimately disables the access to
the frontend, and causes a failure at the init frontend logic.

This patch is a workaround for this issue: it simply checks if the
frontend init had any failure. If so, it will init the frontend when
some DTV application will try to set DVB mode.

Even being a hack for Kworld SBTVD to work, and assumning that we could
teach tda8290 to be a good boy, this is actually an improvement at the
frontend driver, as it will be more reliable to initialization failures.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
7570800c9de39c718f84ec4ea820a788556cde4b 14-Jan-2011 Mauro Carvalho Chehab <mchehab@redhat.com> [media] mb86a20s: Fix i2c read/write error messages

A script replaced err var to rc. Howerver, this script gambled
"error" string, changing it to "rcor". Revert that bad change.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
68541cdaadecbc280cd50122f11fdbb249a2ae29 03-Oct-2010 Mauro Carvalho Chehab <mchehab@redhat.com> [media] Add support for Kworld SBTVD board

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
7572f9c5575c721f43b575a71fda1ecd896e0327 03-Oct-2010 Mauro Carvalho Chehab <mchehab@redhat.com> [media] mb86a20s: add support for serial streams

By comparing the traffic between Pixelview (cx23102-based and Kworld
(saa7134-based), the only difference is at register 0xd5. After some
tests, It seems that it is used to change mode between serial and parallel.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
b9ede79ada766eec535e1230970bd885489d5990 28-Sep-2010 Mauro Carvalho Chehab <mchehab@redhat.com> [media] add a driver for mb86a20s

This adds the trivial bits to mb86a20s. As the driver won't touch
at the channel/layer parameters, this may not be enough for
receiving all channels, especially ISDB-Tsb, but the driver worked
properly for receiving video channels on my tests.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>