While this patch change some things, the updated fields there are
used just on printk, so it shouldn't cause any functional changes.

Yet, this routine is a little complex, so explain a little more
how it works.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of changing the ops.info.type struct, updates only
the data that will be returned to userspace.

Also add some debug messages to help tracking such issues.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

without it, the loop will run forever!
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This var were used during DVBv3 times, in order to keep a copy
of the parameters used by the events. This is not needed anymore,
as the parameters are now dynamically generated from the DVBv5
structure.

So, just get rid of it. That means that a DVBv5 pure call won't
use anymore any DVBv3 parameters.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

using -1 for ISDB-T parameters do the wrong thing. Fix it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

For frontends with ISDB-T, DVB-T2, CMDBTH, etc, some code is
needed, in order to provide emulation. Add such code, and check
if the desired delivery system is supported by the frontend.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Get rid of using ops->info.type defined on DVB drivers,
as it doesn't apply anymore.

Currently, one driver (cxd2820) supports more than one different
info.type, as it can be used for DVB-T/T2 and DVB-C. There are more
drivers like that to come. So, the same frontend will have

different DVBv3 types, depending on the current delivery system.

This breaks the existing logic at dvb_frontend, that assumes that
just one delivery system DVBv3 type is supported by all delsys.

In order to easy the DVBv3->DVBv5 conversion, an ancillary function
that maps DVBv3 delivery systems into DVBv5 were added.

Also, on all places, except for the event logic, the DVBv5 cache
will be used to check parameters, instead of the DVBv5 copy.

This patch simplifies the cache sync logic, and warrants that the
cache will be in a clear state at DVB frontend register. This way,
ops->info.type will be filled to reflect the first delivery system,
providing backward compatibility support for it.

For example, in the cases like cxd2820, where the delivery systems
are defined as:
        .delsys = { SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A },

A pure DVBv3 will be able to use both DVB-T and DVB-T2, as, at
DVB cache clear, the ops->info.type will be equal to FE_OFDM.

However, DVB-C won't be visible. A quick workaround would be to
do a DVBv5 call to set the delivery system to SYS_DVBC_ANNEX_A.

After such call, ops->info.type will be equal to FE_QAM, and a
DVBv3 application will see the frontend as a DVB-C one.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This change is there in order to prepare the code to avoid calling
 dvb_frontend_ioctl_legacy() from FE_SET_PROPERTY.

A call to dvb_frontend_ioctl_legacy() would require to update the
DVBv3 cache without need, mangling calls for newer delivery system
without any reason.

No functional changes here.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to DVB-T2, several new possible values for bandwidth were added.
As the DVBv3 struct were updated to handle them, the core needs to
handle all of them, as a DVBv3 application might try to use it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

By default, initialize the frontend current delivery system with
the first one. This warrants that a DVBv3 application will be able
to tune to it, after the removal of ops->init.type filling at
the drivers.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

On several places inside dvb_frontend, only the DVBv3 parameters
were updated. Change it to be sure that, on all places, the DVBv5
parameters will be changed instead.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Before this patch, a query for the delivery systems were
returned SYS_UNDEFINED.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now that all frontends are implementing DVBv5, don't export the
DVBv3 specific stuff to the drivers. Only the core should be
aware of that, as it will keep providing DVBv3 backward compatibility.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This callback is not used anywhere. Maybe it were used in the
past to optimize the custom algo, but, as it is not used anymore,
let's just remove it.

If later needed, some patch may re-add it with a proper
implementation.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Just like the other DVB algorithms, drivers should use the DVBv5
way to retrieve parameters: via the cache struct.

Actually, several drivers were partially using the DVBv3 struct
and partially using the DVBv5 way, with is confusing and may
lead into troubles.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

In the past, dvb_frontent_parameters were passed inside the
struct where get_tuner_settings should store their result.

This is not needed anymore, as all parameters needed are stored
already at the fe property cache. So, use it, where needed.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now that all drivers were converted, we can get rid of those
emulation calls.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro 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: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of just estimating the bandwidth for DVB-C annex A/C,
also fill it at the core for ATSC and DVB-C annex B. This
simplifies the logic inside the tuners, as all non-satellite
tuners can just use c->bandwidth_hz for all supported
delivery systems.

It could make sense to latter use it also for satellite
systems, as several DVB-S drivers have their own calculus.
However, on DVB-S2 the bw estimation is a little more complex,
and the existing drivers have some optimized calculus for
bandwidth. So, let's not touch on it for now.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

SYS_DVBC_ANNEX_AC is an alias for SYS_DVBC_ANNEX_A. However,
the first one is incorrect, as not all devices support both.
So, replace its occurrences by the proper value (either
SYS_DVBC_ANNEX_A or both SYS_DVBC_ANNEX_A and SYS_DVBC_ANNEX_C).
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are some issues and miss-behaves at the dvb fe thread:

1) dvb_shutdown_timeout should be dvb_shutdown_timeout * HZ
   instead of (dvb_shutdown_timeout * HZ + 1);

2) add a memory barrier to warrant that all CPU's will consider the
   new value for release_jiffies;

3) wake up dvb thread also when fepriv->exit == DVB_FE_NO_EXIT.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of using a roll-off factor, change DRX-K & friends to select
the bandwidth filter and the Nyquist half roll-off via delivery system.

This provides a cleaner support for Annex A/C switch.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

 Currently, for any multi-standard frontend it is assumed that it just
 has a single standard capability. This is fine in some cases, but
 makes things hard when there are incompatible standards in conjuction.
 Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold
 the same for DSS. This is not specific to any driver as it is, but a
 generic issue. This was handled correctly in the multiproto tree,
 while such functionality is missing from the v5 API update.

 http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html

 Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this
 issue in the v5 API, but that hack is incapable of addressing the
 issue, as it can be used to simply distinguish between DVB-S and
 DVB-S2 alone, or another X vs X2 modulation. If there are more systems,
 then you have a potential issue.

 An application needs to query the device capabilities before requesting
 any operation from the device.
Signed-off-by: NManu Abraham <abraham.manu@gmail.com>
Acked-by: NAndreas Oberritter <obi@linuxtv.org>
Acked-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

DVB-C, as defined by ITU-T J.83 has 3 annexes. The differences between
Annex A and Annex C is that Annex C uses a subset of the modulation
types, and uses a different rolloff factor. A different rolloff means
that the bandwidth required is slicely different, and may affect the
saw filter configuration at the tuners. Also, some demods have different
configurations, depending on using Annex A or Annex C.

So, allow userspace to specify it, by changing the rolloff factor.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Andreas Oberritter <obi@linuxtv.org> has looked at this and agreed that it is
safe to remove the 'timeout' variable.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  dtv_property_cache_init().
  dtv_property_process_get().
  overwritten with invalid values, leading to partially incorrect
  results when calling FE_GET_PROPERTY.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  identify a satellite receiver by its 'delivery_system' instead of
  'modulation', which may overlap between different delivery systems.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  - fepriv->parameters_out isn't protected by events->mtx, so
    move the call to fe->ops.get_frontend out of the locked area.
  - move the assignment of e->status into the locked area.

  - use direct assignment instead of memcpy.

  - use mutex_lock instead of mutex_lock_interruptible, because
    all code paths protected by this mutex won't block.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  the first event after an attempt to tune.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  enqueued before the frontend thread wakes up.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

  Modify it to use the data given by the user.
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This reverts commit a3e4adf274f86b2363fedaa964297cb38526cef0.

As pointed by Andread Oberritter <obi@linuxtv.org>:

	That's wrong, because the array size is DTV_MAX_COMMAND + 1.
	Using the ARRAY_SIZE macro instead might reduce the confusion.

Also, changeset 3995223038 already fixed this issue.
Reported-by: NAndread Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If the tvp->cmd == DTV_MAX_COMMAND then we read past the end of the
array.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

- Add missing entry to array "dtv_cmds".
- Set array size to DTV_MAX_COMMAND + 1 to avoid future off-by-ones.
Reported-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Attached is a patch which addresses a race condition in the DVB core
related to closing/reopening the DVB frontend device in quick
succession.  This is the reason that devices such as the HVR-1300,
HVR-3000, and HVR-4000 have been failing to scan properly under MythTV
and w_scan.

The gory details of the race are described in the patch.

Devin

There is a race condition exhibited when channel scanners such as w_scan and
MythTV quickly close and then reopen the frontend device node.

Under normal conditions, the behavior is as follows:

1.  Application closes the device node
2.  DVB frontend ioctl calls dvb_frontend_release which sets
    fepriv->release_jiffies
3.  DVB frontend thread *eventually* calls dvb_frontend_is_exiting() which
    compares fepriv->release_jiffies, and shuts down the thread if timeout has
    expired
4.  Thread goes away
5.  Application opens frontend device
6.  DVB frontend ioctl() calls ts_bus_ctrl(1)
7.  DVB frontend ioctl() creates new frontend thread, which calls
    dvb_frontend_init(), which has demod driver init() routine setup initial
    register state for demod chip.
8.  Tuning request is issued.

The race occurs when the application in step 5 performs the new open() call
before the frontend thread is shutdown.  In this case the ts_bus_ctrl() call
is made, which strobes the RESET pin on the demodulator, but the
dvb_frontend_init() function never gets called because the frontend thread
hasn't gone away yet.  As a result, the initial register config for the demod
is *never* setup, causing subsequent tuning requests to fail.

If there is time between the close and open (enough for the dvb frontend
thread to be torn down), then in that case the new frontend thread is created
and thus the dvb_frontend_init() function does get called.

The fix is to set the flag which forces reinitialization if we did in fact
call ts_bus_ctrl().

This problem has been seen on the HVR-1300, HVR-3000, and HVR-4000, and is
likely occuring on other designs as well where ts_bus_ctrl() actually strobes
the reset pin on the demodulator.

Note that this patch should supercede any patches submitted for the
1300/3000/4000 which remove the code that removes GPIO code in
cx8802_dvb_advise_acquire(), which have been circulating by users for some
time now...

Canonical tracking this issue in Launchpad 439163:

Thanks to Jon Sayers from Hauppauge and Florent Audebert from Anevia S.A. for
providing hardware to test/debug with.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Cc: Jon Sayers <j.sayers@hauppauge.co.uk>
Cc: Florent Audebert <florent.audebert@anevia.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>