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>

The dvb were originally written for DVB-T/C/S and ATSC. So,
the original frontend struct has fields to describe only those three
standards.

While 2nd gen standards are similar to these, new standards
like DSS, ISDB and CTTB don't fit on any of the above types.

While there's a way for the drivers to explicitly change whatever
default DELSYS were filled inside the core, still a fake value is
needed there, and a "compat" code to allow DVBv3 applications to
work with those delivery systems is needed. This is good for a
short term solution, while applications aren't using DVBv5 directly.

However, at long term, this is bad, as the compat code runs even
if the application is using DVBv5. Also, the compat code is not
perfect, and only works when the frontend is capable of auto-detecting
the parameters that aren't visible by the faked delivery systems.

So, let the frontend fill the supported delivery systems at the
device properties directly.

The future plan is that the drivers will stop filling ops->info.type,
filling, instead, ops->delsys. This will allow multi-frontend
devices like drx-k to use just one frontend structure for all supported
delivery systems.

Of course, the core will keep using it, in order to keep allowing
DVBv3 calls.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

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>

The calc_regs() callback is used by a few frontends (mt352, nxt200x,
digitv and zl10353). On all places it is called, the parameters are
set by DVBv5 way. So, just use the DVBv5 struct and remove the
extra parameter.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

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

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Despite its name, tuner-simple has a complex logic to set freqs ;)

Basically, it can be called by two different ways: via set_params()
or via calc_regs() callbacks. Both are bound to the DVBv3 API.
Also, set_params internally calls calc_regs().

In order to get rid of DVBv3 params at set_params(), it shouldn't
call calc_regs() anymore. The code duplication is very small,
as most of the code there is just to check for invalid parameters.

With regards to calc_regs(), it should still trust on bandwidth and
frequency parameters passed via DVBv3, until a later patch fixes
it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

This standard is not properly documented, but its settings are at
the tda18271dd driver, and are somewhat obvious, as they follow
the same logic as DVB-T 7MHz.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

There is a bug on mxl5005s logic: when the bandwidth changes, but using
the same delivery system, the code discard the set_params()
reconfiguration request.

This was happening because, in the previous coding, the bandwidth
calculus were after the check for delivery system changes.

The previous patch changed the logic to estimate the bandwidth to
happend together with the changes at the delivery system.

So, with a one-statement change, it is possible to make the tuner to
reconfigure, in order to adjust to bandwidth changes. this will
likely fix issues on countries that use 7MHz/8MHz DVB-T channels.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>